Let's assume we have 2 ERD entities connected with 1 relationship. Visual Paradigm allows to mark such a relationship as "Subtype" and "Identifying" at the same time. And I just fail to imagine any case where such a combination could make sense.
Is that actually legal? If yes I would appreciate some example and a procedure of translating it to the relational model (what are the changes in comparison to only-"Subtype" or only-"Identifying" case?).
What Visual Paradigm calls an ERD is in fact a table diagram. Diagrams that don't use shapes for relationships don't support attributes and relationships on relationships, nor ternary and higher order relationships. If a diagramming notation doesn't support all the concepts of the Entity-Relationship model, we can't call its diagrams Entity-Relationship diagrams.
From an ER point of view, all subtype relationships are identifying relationships, since the parent entity set's identity is a component of the child entity set's identity. However, all identifying relationships aren't subtype relationships. The difference between a subtype and a weak entity set is that the latter uses an additional weak key component to distinguish multiple children of a parent. Subtypes depend only on the supertype for identity and so each instance of the supertype can have only instance per subtype.
For example, an entity set Person (identified by person_id) may have a subtype Employee (which is also identified by person_id). Compare this with an Invoice (identified by invoice_id) and LineItem (identified by invoice_id and line_number).
The ERD (conceptual model) translates into the following tables (physical model):
Related
Obviously a weak entity must be involved (as the child) in one or more identifying relationships, otherwise it would not be weak.
But can it, at the same time, also be the child in a non-identifying relationship?
Yes, weak entity sets can participate in non-identifying relationships with other entities. By "child", I suppose you mean relationships in which the weak entity set is on the determining (many) side of the relationship. There is no restriction on the kinds of relationships in which weak entity sets may participate.
However, watch out for multiple identifying relationships. While a weak entity set can easily be the descendant of a chain of identifying relationships, multiple independent identifying relationships on the same weak entity set are unusual, and challenges the very notion of an entity set. See my answer to this question.
Note that your question title mentions relationships between tables, which confuses conceptual (ER) and physical (tabular) models. Entity relations are represented by tables, but so are relationship relations in general (only one-to-one and one-to-many relationships can be denormalized into the entity relation of a/the determining entity set, many-to-many and ternary and higher relationships still require their own tables).
The ER diagram for a database is given below:
Now, what's the relationship between planes and flights entities?
I'd say one to many, but that'd be wrong because while one plane can have more than one flights, many flights can't have one (single) plane simultaneously.
So, what exactly is the relationship?
I'm new to databases. Please tell me if I'm wrong.
First, your diagram isn't an ER diagram, it's a table diagram. ER diagrams must be able to represent the ER model, which supports ternary and higher relationships, weak entity sets and identifying relationships, and other concepts for which table diagrams don't have notation. Proper ER diagram notation is generally referred to as Chen's notation.
Now, ER relationships are easily identified by looking for entity domains (columns that identify entity sets) that appear in the same table. These are usually indicated by PK and/or FK, but they need not be.
When you have a binary relationship (two entity domains in the same table), look at the unique constraints on these domains:
One-to-one relationships require two separate unique constraints, one for each domain.
One-to-many relationships require a unique constraint on the domain on the many side.
Many-to-many relationships require a composite unique constraint on both domains together.
One-to-many relationships can be denormalized into the entity relation of the entity on the many side, since the unique constraint required for the relationship matches the PK for the entity relation. One-to-one relationships can be denormalized into either entity relation. A many-to-many relationship requires a composite key, and must be represented as a separate relation since the composite key doesn't match either entity relation's PK.
In your example, (flight_num, planeID) represents the relationship, and since only flight_num is uniquely constrained (due to being the PK of the flights relation), this is a many-to-one relationship: each flight is associated with exactly one plane, while each plane can be involved in many flights.
Here's a visual reference in which unique constraints are indicated with underlining:
Many people still use terminology and concepts from the old network data model, such as conflating relationships with FK constraints and entity sets with tables (which is why table diagrams are often mistakenly called ERDs). I highly recommend reading Codd's paper "A Relational Model of Data for Large Shared Data Banks" and Chen's paper "The Entity-Relationship Model - Toward a Unified View of Data".
As you said the relation is One-To-Many because if it is a Many-To-Many relation it must have a junction table between these 2 tables (Tbl_Plane_Flight) , another thing is that Plane_Id is referenced in Flights table.
But there must be a validation rule (or a constraint in flights table) for this relation, that a plane cannot have many flight as the same time
Between two entities is a 1 to many relationship but this relationship has an attribute of its own.
When converting these entities to a relational schema what will happen to this attribute? Does it get joined into the entity on the many side of the relationship like a foreign key does? I don't think it should be another separate relation because that is like saying it's an associative entity which it's not.
Any help is greatly appreciated.
In ER as described by Chen, each entity relation and each relationship relation would map to a separate table (except weak entities/identifying relationships). However, one-to-one and one-to-many relationships commonly get denormalized to reduce the number of tables. In this case, attributes of the relationship become attributes of the determining entity.
Associative entities occur when a relationship is the subject of a relationship. Recording a relationship in a separate table doesn't make it an associative entity. Nor do attributes make a relationship into an entity. Attributes on relationships are quite normal in the ER model.
I have the following as my ER Diagram. I am still learning DBMS, and trying to translate this ER Diagram to a Relational Schema. I know that each entity in the ER Diagram will have a separate table. However, I am not sure what to do about the relationship for this particular ER Diagram. We were told that each relationship between the entities will have a table too. Therefore, do I need to make separate for relationships in this ER Diagram as well? But, there are no attributes of the relationship. Also, I am having a confusion in what sort of relationship is this exactly? Is this one to many?
I am attaching the link to the picture of the ER Diagram. Please guide me in the right direction. Thanks!
Your diagram isn't an ER diagram in the original sense of that term. In the entity-relationship model, relationships are associations among entity sets and were meant to be implemented as tables. For example, your AUTHOR_BOOK, CAST and PURCHASE tables are relationship tables that associate two entity sets each (keep in mind that relationships aren't limited to just two entity sets). Note how the relationships are represented using the keys of the entity sets e.g. (actorID, inventID). The same pattern can be found in some of your other tables, i.e. (inventID, publisher), (inventID, director), (inventoryID, genre), (inventoryID, supplier), (receiptID, inventID) and (receiptID, customerID). These are your relationships - not the crow's foot lines which are just foreign key constraints. In Chen's original notation, the relationships would be indicated using diamond shapes between and connected to the two entity types. Also, Chen would've made a separate relationship table (aka junction table) for each of these relationships.
Your table diagram shows 14 tables. Following Chen's method, there would be 19 tables:
Your title references a relational schema. Note that relational schemas are not restricted to the entity-relationship model, but can represent any set of normalized tables (1NF or higher). The number of tables would partially depend on the level of normalization.
But, there are no attributes of the relationship.
This is not correct. Your Purchase relationship shows two attributes - quantity and amountPaid. Note that an attribute is a mapping from an entity or relationship set to a value set. Thus, I'm not counting the entity keys as attributes of the relationship. I also modeled Book's pubYear as an attribute of the relationship between Book and Publisher.
In practice, I would probably denormalize relations with the same determinant, which give a physical schema similar to your original diagram, though implementing every relationship table separately does have some advantage in easing schema changes when relationship cardinalities change.
I was only able to find the following two differences:
The relationships in an E-R model are explicitly defined, while they are implicit in a relational model.
Relational models require an intermediate table (often called a "junction table") to hold two foreign keys that implement the many-to-many relationship.
And why do we use the relational model, when we have an E-R diagram ?
You have it backwards.
The relationships in an E-R model are explicitly defined, while they
are implicit in a relational model.
No. Each Relational Model (RM) database base table and query result represents an application relationship. Entity-Relationship Modeling (E-RM) schemas are just a way of organizing (but under-using and under-specifying) (but with misunderstanding) relational tables and constraints.
Relational models require an intermediate table (often called a "junction table") to hold two foreign keys that implement the
many-to-many relationship.
No. It is Object-Relational Mapping (ORM) approaches that obscure their underlying straightforward relational application relationships, tables and constraints. The notion of "junction table" arose from ORM misunderstandings of confused presentations of the E-RM which itself misunderstands the RM.
As C J Date put it An Introduction to Database Systems, 8th ed:
a charitable reading of [Chen's original paper] would suggest that the E/R model is indeed a data model, but one that is essentially just a thin layer on top of the basic relational model [p 426]
It is a sad comment on the state of the IT field that simple solutions
are popular even when they are too simple. [p 427]
The Relational Model
Every relational table represents an application relationship.
-- employee EID has name NAME and ...
E(EID,NAME,...)
The mathematical term for such a thing, and also for a mathematical ordered-tuple set representing one, is a "relation". Hence the "Relational Model" (and "Entity-Relationship Modeling"). In mathematics relations are frequently described by parameterized statement templates for which one mathematical term is "characteristic predicate". The parameters of the predicate are columns of the table. In the RM a DBA gives a predicate for each base table and users put the rows that make a true statement from column values and the predicate into the table and leave the rows that make a false statement out.
/* now also employee 717 has name 'Smith' and ...
AND employee 202 has name 'Doodle' and ...
*/
INSERT INTO E VALUES (EID,NAME,...)
(717,'Smith',...),(202,'Doodle',...)
A query expression also has a predicate built from the relation operators and logic operators (in conditions) in it. Its value also holds the rows that make its predicate true and leaves out the ones that make it false.
/* rows where
FOR SOME E.*, M.*,
EID = E.EID AND ... AND MID = M.MID
AND employee E.EID has name E.NAME and ...
AND manager M.MID has
AND E.DEPT = M.DEPT AND E.NAME = 'Smith'
/*
SELECT E.*, M.MID
FROM E JOIN M ON E.DEPT = M.DEPT
WHERE E.NAME = 'Smith'
Present rows of tables making true statements and absent rows making false statements is how we record about the application situation in the database and how we interpret what the database is saying about the application situation. One can't use or interpret the database without having and understanding the predicates ie application relationships.
Entity-Relationship Modeling
E-RM (which does not really understand the RM) is essentially a(n unnecessary, restricted and restrictive) diagramming notation for describing (some parts of) (limited forms of) relational databases. Originally there were "entity (class)" icons/relations where the candidate key (CK) values were 1:1 with application entities plus other columns ("properties" of the "entity") and there were "relationship (class)" icons/tables which had foreign keys (FKs) to entity tables representing application relationships on multiple entities plus other things ("properties" of the "association"). An application relationship was represented by an icon with lines to the various entity icons that participated in it. (Ie the lines represented FKs. Which are not relationships but statements about constraints on tables.)
E-RM doesn't understand the relational model. It makes a pointless and misleading distinction between application entities and relationships. After all, every superkey (unique column set) of every base table or query result is in 1:1 correspondence with some application entity, not just the ones that have entity tables. Eg people can be associated by being married; but each such association is 1:1 with an entity called a marriage. This leads to inadequate normalization and constraints, hence redundancy and loss of integrity. Or when those steps are adequately done it leads to the E-R diagram not actually describing the application, which is actually described by the relational database predicates, tables and constraints. Then the E-R diagram is both vague, redundant and wrong.
Shorthand E-RM and ORMs
A lot of presentations and products claiming to be E-RM warp the E-RM, let alone the RM. They use the word "relationship" to mean a FK constraint. This arises as follows. When an E-RM relationship is binary it is a symbol with two lines to its FKs. So those three things can be replaced by one line between FKs. This kind of line represents that particular binary relationship and its FKs but now the E-R relationship is not explicit in the diagram although the E-R relationship is explicit in the longhand version and it is reflected by a table in what the diagrams are pictures of, namely the relational database they are describing. This gets called a "junction table". And people talk about that line/table being/representing "an X:Y relationship" between entities and/or associations without actually ever noticing that it's a particular application relationship. And there can be many such application relationships between the same two entities and/or associations.
ORMs do this too but also replace n-ary associations by just their FKs so that the associated application relationship and table are further obscured. Active Records goes even further by defining several shorthand relationships and their tables at once, equivalent to a chain of FK lines and association icons in the longhand E-RM diagram. This is exacerbated by many modeling techniques, including versions of E-RM and ORMs, also thinking that application relationships can only be binary. Again, this arose historically from lack of understanding of the RM.
They are two different things per se. A relational model represents information as tuples, directly mapped to a relational schema. The guidelines stem from relational algebra.
Meanwhile, an ER diagram models the relationships between the users and their underlying data in a system using entities. An ER diagram can be mapped to a relational model, and finally to a working schema.