Relationships

Ch 7

This is the draft section on relationships¹. It takes the same theme as the prior two sections on entities and attributes and extends them to semi-structured and unstructured data.

To do:

• Add graphics for table joins and maybe unstructured examples.

• I’m unsure if the unstructured examples are complete, so I’ll likely add more detail and clarity.

• I might cover graphs as well?

• Considerations

As always, please leave your comments here. Thanks a ton for your candid feedback and commentary.

Thanks,

Joe Reis

---

You learned about entities and attributes. Now, it’s time to look at relationships. A relationship describes how different entities associate with and depend on each other. Traditionally, the treatment of relationships focuses on relationships between database tables, which we’ll undoubtedly cover. However, like many things in this book, we will also expand the traditional orthodoxy of data modeling to cover newer areas.

Getting relationships right is crucial to data modeling. Datasets rarely exist in isolation. They’re combined and integrated with other datasets. Without relationships, you have disparate entities and attributes. The power of relationships is integrating different pieces into a meaningful and structured representation of whatever you’re modeling. Get it wrong, and you’ve got an inconsistent mess of data.

Let’s first look at relationships with structured data.

Structured Data Relationships

Let’s look at a simple example relating two tables you saw earlier—Orders and Customers. In this example, we’ll focus on the relationships between the keys of the tables. The tables will be abbreviated for clarity in this example.

Orders

------

OrderID (Primary Key)

CustomerID (Foreign Key referencing Customer.CustomerID)

OrderDate

OrderStatus

Customers

--------

CustomerID (Primary Key)

FirstName

LastName

Email