An identifying relationship “describes a situation in which the existence of a row in the child table depends on a row in the parent table.”
“if a child identifies its parent, it is an identifying relationship.”
The technical definition of an identifying relationship is that a child’s foreign key is part of its primary key.
CREATE TABLE AuthoredBook ( author_id INT NOT NULL, book_id INT NOT NULL, PRIMARY KEY (author_id, book_id), FOREIGN KEY (author_id) REFERENCES Authors(author_id), FOREIGN KEY (book_id) REFERENCES Books(book_id) );
book_id is a foreign key, but it’s also one of the columns in the primary key. So this table has an identifying relationship with the referenced table
Books. Likewise it has an identifying relationship with
A comment on a YouTube video has an identifying relationship with the respective video. The
video_id should be part of the primary key of the
CREATE TABLE Comments ( video_id INT NOT NULL, user_id INT NOT NULL, comment_dt DATETIME NOT NULL, PRIMARY KEY (video_id, user_id, comment_dt), FOREIGN KEY (video_id) REFERENCES Videos(video_id), FOREIGN KEY (user_id) REFERENCES Users(user_id) );
It may be hard to understand this because it’s such common practice these days to use only a serial surrogate key instead of a compound primary key:
CREATE TABLE Comments ( comment_id SERIAL PRIMARY KEY, video_id INT NOT NULL, user_id INT NOT NULL, comment_dt DATETIME NOT NULL, FOREIGN KEY (video_id) REFERENCES Videos(video_id), FOREIGN KEY (user_id) REFERENCES Users(user_id) );
This can obscure cases where the tables have an identifying relationship.
I would not consider SSN to represent an identifying relationship. Some people exist but do not have an SSN. Other people may file to get a new SSN. So the SSN is really just an attribute, not part of the person’s primary key.
You can take a look at MySQL Manual, explaining how to add Foreign Keys on MySQL Workbench as well.
The vertical toolbar on the left side of an EER Diagram has six foreign key tools:
one-to-one non-identifying relationship
one-to-many non-identifying relationship
one-to-one identifying relationship
one-to-many identifying relationship
many-to-many identifying relationship
Place a Relationship Using Existing Columns
An identifying relationship is one where the child table cannot be uniquely identified without its parent. Typically this occurs where an intermediary table is created to resolve a many-to-many relationship. In such cases, the primary key is usually a composite key made up of the primary keys from the two original tables. An identifying relationship is indicated by a solid line between the tables and a nonidentifying relationship is indicated by a broken line.
Create or drag and drop the tables that you wish to connect. Ensure that there is a primary key in the table that will be on the “one” side of the relationship. Click on the appropriate tool for the type of relationship you wish to create. If you are creating a one-to-many relationship, first click the table that is on the “many” side of the relationship, then on the table containing the referenced key. This creates a column in the table on the many side of the relationship. The default name of this column is
table_name_key_name where the table name and the key name both refer to the table containing the referenced key.
When the many-to-many tool is active, double-clicking a table creates an associative table with a many-to-many relationship. For this tool to function there must be a primary key defined in the initial table.
Use the Model menu, Menu Options menu item to set a project-specific default name for the foreign key column (see Section 184.108.40.206.4, “The Relationship Notation Submenu”). To change the global default, see Section 6.4.5, “The Model Tab”.
To edit the properties of a foreign key, double-click anywhere on the connection line that joins the two tables. This opens the relationship editor.
Mousing over a relationship connector highlights the connector and the related keys as shown in the following figure. The
film and the
film_actor tables are related on the
film_id field and these fields are highlighted in both tables. Since the
film_id field is part of the primary key in the
film_actor table, a solid line is used for the connector between the two tables.