There are a lot of potential design options for schema
They are chosen based on what makes the most sense for the data and application
Examples of database schema design options:
Flat model schema
This is basically like a single table
Very simple
Doesn't model all the data needs for more complex situations
Likely only useful if you could do a spreadsheet instead of a database
Might be used for a small company with only a few employees that need an employee database
Hierarchical model schema
Looks like a tree structure like you might see in programming data structures
Contains a root node where the information is starting from
Used for things like nested data because it's the parent/child model
An example use case for a school might be a database of employees and students
Network model schema
Similar to the hierarchal schema
This allows many-to-many relationships to be illustrated, whereas networking only allows one-to-many
Network model schema means you can include workflows and paths to the data
Example use case might be a restaurant chain where you need to keep track of inventory and employees but you also want to model workflows for cash and food delivery
Relational model schema
Mostly used in relational databases
Used to keep track of the table and relationships
Some say it's better for object-oriented design
Example use case in a school we have classes, faculty and students, departments and divisions, or other data that is related
Has the general appearance of a star, where there is a central table called the fact table, and connected to that are the dimension tables that describe other important info
The relationships are described using foreign key relationships
Snowflake model schema
Snowflake is an adaptation of the star schema
Like the star style, there is a central table that stores datapoints and references to dimensional tables
However it expands on star by allowing multiple dimensional tables to include even more information