All the time! In fact, I learned about dbdiagram.io from a colleague on the diabetes project.
It's a good graphical way to display the relationships, instead of having to infer them from foreign keys
Sure. A key for an entity set is a unique identifier. People have SSN, B-number, email address, etc. Cars have a VIN. Movies have a TT.
The key constraint is that the key is unique. So, if you try to insert a movie and the TT already exists, you'll get a key constraint error.
Sure. The TT is a foreign key in the credit
table, because it's a key in the movie
table.
The foreign key constraint is that every TT in the credit
table is a valid key in the movie
table.
No really. Consider an entity set of Person
(people). What relationships could we have between people? (1) Friends, (2) siblings, (3) enemies, (4) employer/employee, (5) colleague, (6) teammmate (7) ...
We could have lots
Nope. The only issue is naming them. Dbdiagram.io can create one
called person_person
, but you'll be better off naming
them yourselt if there are lots.
The credit
table is our prototypical example. It's how
we represent the many-to-many actor relationship between
Person and Movie.
We could also have intermediate tables for all of the inter-personal relationship examples above.
I like to cling to
director
as a prototypical
example of a one-to-many relationship: one director and many movies,
and
credit
as a prototypical example of a
many-to-many relationship: each person can act in many movies and each
movie can have many actors.
Relationships that are one-to-one are less common, because typically we would just make more attributes of our entity. One exception is when we want the data in a different table for reasons of privacy or security. For example, we might have a one-to-one relationship between accounts and passwords. Or a one-to-one relationship between people and medical information.
"Barbie" is an entity, while movie
is an entity set.
"Greta Gerwig" is an entity, while person
is an entity set.
directs("Greta Gerwig","Barbie")
is a relationship, while directs
is a relationship set.
Yes, and sure, make as many as you need.
We often create subtypes when the subtype participates in a relationship that the parent type doesn't. Say, international students have a relationship with the Slater Center and with the visa people and such, that US students don't. So, in some cases, we create subtypes to illustrate those.
Unfortunately, AFAIK, dbdiagram doesn't do that (yet).
Whether to create different tables or not is a judgment call.
yes
AFAIK, it can't change the primary key. But it can add/remove columns, indexes, and constraints. So, it can do a lot.
We will!
Yes. You can scp
the downloaded SQL code to the server and use/adapt it to create your tables, say in your projects.