From the course: Practical Database Design: Implementing Responsible Data Solutions with SQL Querying

Entities and relationships

- [Instructor] Databases have come a long way since they were created in the 1960s and SQL was invented in the early 1970s. We have document databases, graph databases, cloud databases, relational databases, and so much more. Regardless of the database type, the building blocks of a useful database starts with well-constructed business rules. These business rules are easily converted into a clear set of entities and relationships. An entity in a database represents a single person label, place type, object or event. For example, in The Brainery, a social media platform for educators, we'll need to represent the Brainery users. Let's call them brainiacs. We'll also need to represent other types of users, like friends and followers, and we can't forget about creating entities that represent brainiacs' posts and direct messages. Entities are powerful digital structures to organize data. They help us not commingle different objects. We don't want to confuse a post with a direct message, for instance. The context of how entities are related or not related to each other is needed. That's where the concept of a relationship fills that gap. A database relationship indicates how many instances of an entity are associated with how many instances of another entity. It's easier to explain this when you know the relationship type between entities. The one-to-many relationship specifies that one instance from an entity is associated with many instances from the other entity. Now, one-to-many relationships are very popular, so you'll see them most often. Let me share an example. In The Brainery, a brainiac makes many posts, and lastly, there are many-to-many relationships. They specify that many instances from an entity are associated with many instances from another entity. For example, in the Brainery, brainiacs have many followers. When we try to implement the many-to-many relationship inside a real database, we actually run into a problem. That is, how do we create an entity with both sides needing to denote many instances from the other side? But we're getting ahead of ourselves. Next up, we'll clarify the minimum requirement options for each of these relationships.

Contents