This is the draft section on relationships1. 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
Keep reading with a 7-day free trial
Subscribe to Practical Data Modeling to keep reading this post and get 7 days of free access to the full post archives.