← Business and Systems Analysis from Scratch
Lesson
Data basics: entities, relationships, cardinality, keys
The learner can build a conceptual ER model: identify entities and attributes, define relationships with correct cardinality (1:1 / 1:N / M:N), and explain primary and foreign keys.
Entity-Relationship Modelling Essentials
Entity-Relationship Modelling Essentials
An Entity-Relationship (ER) model is a conceptual blueprint of the data a system needs to store. An entity is a distinct type of thing about which we store data — for example, Customer, Order, or Product. An attribute is a property of an entity (Customer has Name, Email, Date of Birth). A relationship describes how two entities are associated (a Customer places Orders).
Cardinality specifies how many instances of one entity can relate to how many instances of another. There are three fundamental patterns. One-to-One (1:1): each instance of A relates to exactly one instance of B and vice versa — e.g. a Person has one Passport. One-to-Many (1:N): one instance of A relates to many instances of B, but each B belongs to exactly one A — e.g. one Customer can have many Orders, but each Order belongs to one Customer. Many-to-Many (M:N): many instances of A relate to many instances of B — e.g. a Student enrols in many Courses, and each Course has many Students.
Keys enforce uniqueness and link tables together. A Primary Key (PK) is a column (or set of columns) that uniquely identifies every row in a table — no two rows can share the same PK value. A Foreign Key (FK) is a column in one table that references the PK of another table, creating the link. In a 1:N relationship, the FK goes on the 'many' side: the Orders table stores a Customer_ID column that references the Customers table. An M:N relationship cannot be stored directly; it must be resolved using a junction table (also called an associative or bridge table) that holds two FKs — one for each side of the relationship.
Lesson notes
Entity-Relationship Modelling Essentials
An Entity-Relationship (ER) model is a conceptual blueprint of the data a system needs to store. An entity is a distinct type of thing about which we store data — for example, Customer, Order, or Product. An attribute is a property of an entity (Customer has Name, Email, Date of Birth). A relationship describes how two entities are associated (a Customer places Orders).
Cardinality specifies how many instances of one entity can relate to how many instances of another. There are three fundamental patterns. One-to-One (1:1): each instance of A relates to exactly one instance of B and vice versa — e.g. a Person has one Passport. One-to-Many (1:N): one instance of A relates to many instances of B, but each B belongs to exactly one A — e.g. one Customer can have many Orders, but each Order belongs to one Customer. Many-to-Many (M:N): many instances of A relate to many instances of B — e.g. a Student enrols in many Courses, and each Course has many Students.
Keys enforce uniqueness and link tables together. A Primary Key (PK) is a column (or set of columns) that uniquely identifies every row in a table — no two rows can share the same PK value. A Foreign Key (FK) is a column in one table that references the PK of another table, creating the link. In a 1:N relationship, the FK goes on the 'many' side: the Orders table stores a Customer_ID column that references the Customers table. An M:N relationship cannot be stored directly; it must be resolved using a junction table (also called an associative or bridge table) that holds two FKs — one for each side of the relationship.