How to model a database for a small school portal Good day,
My problem is how to model databases.
I most times get confused, not knowing what table to create or what will be needed.

Is there like a standard someone can take to get things working?

My current project is a simple University Staff management application,
to help the School Admin:


See the distribution of staff arranged by rank in every unit of the 
university(programme, dept and faculty).
Carry out transfer of staff
Carry out promotion of staff
Carry out removal of staff
Carry out addition of staff
Answer simple queries, e.g, display professors in faculty of Arts by dept, etc.
I think the way I would tackle a problem like this is to examine it through three lenses (although more may be appropriate in your case).


Objects (usually the nouns in your problem statement)
Relationships (how the nouns interact)
Actions (usually the verbs in your problem statement)


Before I get too much further into this - if you don't mind duplicate data (or potential data-entry errors in your database) then this could be created as a simple flat table with each of the items like programme, department, and facility being text fields associated with each staff member. This, however as I mention, is prone to data entry errors although it makes updating data far simpler.

I am going to propose having several tables which provide you with a hierarchical view of the data. In this case, I'll try to walk through each and explain how I would tackle it:

Objects

I see a few objects that you might want to incorporate in your database:


Staff
Programme
Department
Facility
Position / Role


Each of these will very likely become individual tables in your database. It is best practice to identify these objects with a primary key and a unique identifier (often times an incremental Id column in each table. This, then, allows you to take the next step ...

Relationships

Next, you identify what the relationships are between the objects you've defined. For example, a position / role may "belong to" (be associated with) one department or programme - depending upon how you define those (e.g., an Assistant Professor of Database Design might belong to the Software Department which belongs to the Management Information Sciences programme or vice-versa). A staff member would generally hold only one position / role. If this were the case you would have a tree like this: Staff -> Position -> Department -> Programme (or Staff -> Position -> Programme -> Department depending upon what each means). 

If the first is the case, you would likely have a Staff table with a foreign key column called PositionId (or something similar). This PositionId would link in a one-to-many relationship from the Position table to the Staff table. The same would apply for the Position table, which would have a foreign key column called DepartmentId (or ProgrammeId) that had a similar relationship link to the Position table.

One kink in this logic is that it is sometimes possible for a staff person to hold more than one position. This would require a many-to-many relationship which requires a junction table in the middle. For example, if a staff person could hold multiple positions then you would create a new junction table called something like StaffPosition which would have a StaffId and PositionId column in it. This table, then would have one-to-many relationships between it and Staff (on StaffId) and Position (on PositionId). This would make updating the data more complicated, but walking through that is slightly out of the scope of this response.

Actions

Finally, the actions that you define would impact how you are going to interact with these tables. Going through each of your items, I'll give you my best guess on what those would look like (assuming that a Staff person can only hold one position).


Not an action
Not an action
Carry out transfer of staff - perform an UPDATE on the Staff table that changes the PositionId to the new position.
Carry out promotion of staff - perform an UPDATE on the Staff table that changes the PositionId to the new position.
Carry out removal of staff - in this case you might want to do two things: (1) Add a boolean / bit field to the Staff table that indicates whether the staff person is currently employed - you would turn that to OFF in this case and (2) set the PositionId to NULL. You could also, of course, delete the row in the Staff table, but you may need to access this data later (or they may be rehired).
Carry out addition of staff - this would be a simple INSERT into the Staff table, assigning the appropriate PositionId as applicable.
Answer simple queries - the basic schema I've proposed would allow that through some simple INNER JOINS on the proposed tables.


One thing I would mention is that in this configuration, you will need to have additional administrative functions to allow users to not only add Staff persons, but also add / delete Positions, Programmes, Departments, and Facilities (or you can use SQL to do that yourself).

Conclusion
This is a very simple overview and I could see the data model getting pretty complex in your situation. But hopefully this will give you and idea of where to start and how to do so.