The lines between entities within an Entity-Relationship Diagram [ERD] represent an interdependency between the involved entities. In a normalized designed, this interdependency is both semantic and functional, as in, “a HOUSE has one-or-more DOORs,” “an ORDER has one-or-more ORDER LINEs,” or “a STUDENT enrolls in zero-to-many CLASSes.” These object pairings would have a line drawn between them in an ERD representation. There also would be markings from whatever notation one is employing, designating the “one” side of the relationship and the “many” side of the relationship.
To expand on our first example, “a HOUSE has one-or-more DOORs,” the HOUSE is the one-side and DOOR would be the many-side. And since each relationship may be expressed in either direction, while a HOUSE may have one-to-many DOORs, an individual DOOR is within one-and-only-one HOUSE. Both statements reflect the single line between HOUSE and DOOR. Regardless of the objects involved, these semantic descriptions should be stated in a fashion that is both logical and meaningful to the organization. These object-pair relationships are more than just a line on a drawing, because they also represent business rules that must be true of the data ultimately contained within these structures.
The lines inside an ERD have even more instrumentality beyond the business rules. The ERD relationship lines also represent a foreign key. The concept of a foreign key starts seeping into a few other items that are foundational within relational theory.
The first is the primary key concept. A primary key is the attribute, or group of attributes, that can be used to uniquely identify an individual row within an Entity/Table. Examples might be—an Employee Identifier to represent an Employee, an Order Number to represent an Order that has been placed. Every object within our data model should have something that can uniquely identify a specific instance within it, while all the other attributes are just descriptors providing details about that object instance.
Next, the first rule of normalization says that an entity should not contain any repeating groups. The foreign key represented by the ERD line is actually taking the primary key from one side of the relationship and placing it onto the entity/table on the other side. Which goes where? To prevent creating one of those not allowed repeating groups, design-wise, the primary key from the entity on the one-side of the relationship is placed within the entity on the many-side. This “other object’s primary key” is why it is called “foreign.” Therefore, instead of placing a long list of Door Identifiers within a HOUSE object, we place the single House Identifier within each Door instance that is within the HOUSE instance. This foreign key is linked with the other table’s primary key to successfully join these tables in an SQL query that retrieves the data. If there is no primary key that query cannot perform properly.
If one has an unusual circumstance, such as two HOUSEs sharing a wall where that wall contains a DOOR going between them, then you would model this situation differently, but that would be a bit unique. And just as a mention, uniqueness is why we have so much data modeling work. Organizations inside the same industry have many things that are the same, but they are guaranteed to also have many things that are unique. Even objects that are named the same across businesses may not exactly equate. As humans, uniqueness is our trademark, and that trait is one of the contributing factors to the number of languages spoken across the globe. Consequently, data models need to express the individual business, so even when starting with an industry-specific data model, one must customize that data model for the organization at hand.