Entity-Relationship Modeling

Before building a database, we must identify its components. An Entity is a 'thing' or 'object' in the real world that is distinguishable from all other objects (the 'noun'). For example, in a school, Student and Course are entities. Attributes are the properties that describe an entity (the 'adjectives'). A Student entity might have attributes like $Student\_ID$, $Name$, and $Email$. To keep data organized, every entity needs a Primary Key—a unique attribute, like an ID number, that ensures no two records are identical. We represent entities as rectangles and attributes as ovals in our diagrams.

Entities don't exist in isolation; they interact. A Relationship is the association between entities (the 'verb'). We represent these with diamond shapes. The most critical part of a relationship is Cardinality, which defines the numerical constraints of the link. - One-to-One (1:1): One instance of Entity A relates to exactly one of Entity B (e.g., one Citizen has one Social Security Number). - One-to-Many (1:N): One instance of Entity A relates to many of Entity B (e.g., one Customer places many Orders). - Many-to-Many (M:N): Many instances of Entity A relate to many of Entity B (e.g., many Students enroll in many Courses).

In advanced data modeling, Many-to-Many (M:N) relationships are complex because computers struggle to link them directly. In a school, many Students take many Classes. To solve this, we often use an Associative Entity (or junction table). Instead of a direct link, we create a 'Registration' entity that sits between them. This breaks the $M:N$ into two $1:N$ relationships: $Student (1) \rightarrow (N) Registration (N) \leftarrow (1) Class$. This structure ensures that we can track specific data for that connection, such as the Grade a student received in a specific class.