First things first, let's understand what we're talking about.

Key Players

Entities

An Entity is a real world object. For example a dog is an entity, and it is described by its attributes: a name, a breed, toys, a birthday, an age, an address, and an owner. Together these attributes make up an Entity Set. We can define constraints on these attributes, maybe every name has to be a string.

These attributes can be multivalued (more than one possible value), for example breed could be Terrier, Retriever, etc. Or these attributes could be composite, for example the address is made up of a street, apartment, city, state, and zip code. Or they could be derived, like age, which is a function of the difference between the current date and the birth date.

We also need to give each entity set a primary key, which is a unique identifier for entity.

Hmmm. So in our dog example, let's say we have a dog named Spot, should we make Spot our primary key? Probably not, because there's a good chance there's more than one dog with that name. In cases like this, where we can't figure out a good natural unique identifier, we can use a generated id number as our primary key.

Here's a picture of Spot. Because puppies are cute.

Okay, now back to database design.

Note: A lot of database management systems, like MySQL, have their own strategy for primary key generation.

Ok great, so now we know what an entity is. What's next?

Relationships

Let's talk about relationships, i.e. associations or connections between two or more entity sets. Lets's go back to Spot, our dog Spot has a breed, and that breed is one of many. So maybe we make an entity set of different breed types. There's a relationship where a dog is a certain breed, and there are many different breeds of dogs.

We may want to collect a set of relationships that are similar into a relationship set. For example, we can have a dogs relationship set involving dogs, and breeds. There are different cardinalities to relationships, like one to one, one to many, and many to many. For example every dog has one breed (1:1), but a dog can have have many toys (1:M), and a toy can have zero dogs associated (1:0).

But what's an instance? It's kind of like a snapshot of an entity at one instant, so Spot is an instance of our entity set.

Cool, we're almost there. So far, we've assumed that in an entity set, one of the attributes always includes a key, but that's not always true. A set without a key is called a weak entity, and it has to belong to an owner entity set. Maybe dog toys is a weak entity set, where it is identified only in relation to a dog set.

Subclasses

Alright, now what's a subclass? When we have a Is a relationship, like a Yorkshire Terrier is a type of dog, we have a subclass hierarchy. Subclasses have all the attributes of the superclass, in this case, breed has every attribute of the dog class, but it can also have its own attributes and relationships.

Done Already?

Good job, you're ready to talk about entities and relationships now — you're well on your way to understanding how databases are designed.