My question is the following: Can relations have key attributes like shown in the following figure?
For me it doesn't make sense, however I have found them like in 1. If it is possilbe, how should I "resolve" them in the relational schema?
I found a similar the question on [2] but it seems to focus on how to handle attributes during the transformation of the ERM to the relational schema.
1 https://www.wu.ac.at/fileadmin/wu/processed/csm_erm_cardinalities2_84a65dbc2b.png
[2] relationship attributes in ER diagrams
According to Chen in The Entity-Relationship Model - Toward a Unified View of Data, a relationship set is an association among entity sets, while an attribute is a mapping from an entity set or relationship set to a value set. This means the entities that make up the relationship must be the determinant of the attribute, so a relationship can't depend on its own attributes.
The situation is complicated by common language use - people tend to use attribute to mean a column, which conflates attributes with value sets. Tables that represent relationship sets do have key columns, and those columns do represent attributes of the specific entity sets they represent, but they don't represent attributes of the relationship set.
Note that in your example [1], the key "attribute" on the relationship represents a composition of the keys of ABC and XYZ, so it isn't really a distinct attribute. Normally, in ER diagrams we understand that the keys of the associated entities determine the relationship, so there's no need to indicate a key directly on the relationship shape.
Related
Problem description
I am currently working on a project which requires a relational database for storage.
After thinking about the data and its relations for a while I ran into a quite repetitive problem:
I encountered a common data schema for entity A which contains some fields e.g. name, description, value. This entity is connected with entity B in multiple n-1 relations. So entity B has n entities A in relation rel1 and n entities A in relation rel2.
Now I am trying to break down this datamodel into a schema for a relational database (e.g. Postgres, MySQL).
After some research, I have not really found "the best" solution for this particular problem.
Some similar questions I have found so far:
Stackoverflow
DBA Stackexchange
My ideas
So I have thought about possible solutions which I am going to present here:
1. Duplicate table
The relationship from entity B to entity A has a certain meaning to it. So it is possible to create multiple tables (1 per relationship). This would solve all immediate problems but essentially duplicate the tables which means that changes now have to be reflected to multiple tables (e.g. a new column).
2. Introduce a type column
Instead of multiple relationships, I could just say "Entity B is connected with n entity A". Additionally, I would add a type column that then tells me to which relation entity A belongs. I am not exactly sure how this is represented with common ORMs like Spring-Hibernate and if this introduces additional problems that I am currently unaware of.
3. Abstract the common attributes of entity A
Another option is to create a ADetails entity, which bundles all attributes of entity A.
Then I would create two entities that represent each relationship and which are connected to the ADetails entity in a 1-to-1 relationship. This would solve the interpretation problem of the foreign key but might be too much overhead.
My Question
In the context of a medium-large-sized project, are any of these solutions viable?
Are there certain Cons that rule out one particular approach?
Are there other (better) options I haven't thought about?
I appreciate any help on this matter.
Edit 1 - PPR (Person-Party-Role)
Thanks for the suggestion from AntC. PPR Description
I think the described situation matches my problem.
Let's break it down:
Entity B is an event. There exists only one event for the given participants to make this easier. So the relationship from event to participant is 1-n.
Entity A can be described as Groups, People, Organization but given my situation they all have the same attributes. Hence, splitting them up into separate tables felt like the wrong idea.
To explain the situation with the class diagram:
An Event (Entity B) has a collection of n Groups (Entity A), n People (Entity A) and n Organizations (Entity A).
If I understand correctly the suggestion is the following:
In my case the relationship between Event and Participant is 1-n
The RefRoles table represents the ParticipantType column that descibes to which relationship the Participant belongs (is it a customer or part of the service for the event for example)
Because all my Groups, People and Organizations have the same attributes the only table required at this point is the Participant table
If there are individual attributes in the future I would introduce a new table (e.g. People) that references the Participant in a 1-1 relationship.
If there are multiple tables going to be added, the foreign key of the multiple 1-1 relationship is mutually exclusive (so there can only be one Group/Person/Organization for a participant)
Solution suggested by AntC and Christian Beikov
Splitting up the tables does make sense while keeping the common attributes in one table.
At the moment there are no individual attributes but the type column is not required anymore because the foreign keys can be used to see which relationship the entity belongs to.
I have created a small example for this:
There exist 3 types (previously type column) of people for an event: Staff, VIP, Visitor
The common attributes are mapped in a 1-1-relationship to the person table.
To make it simple: Each Person (Staff, VIP, Visitor) can only participate in one event. (Would be n-m-relationship in a more advanced example)
The database schema would be the following:
This approach is better than the type column in my opinion.
It also solves having to interprete the entity based on its type in the application later on. It is also possible to resolve a type column in an ORM (see this question) but this approach avoids the struggle if the ORM you are using does not support resolving it.
IMO since you already use dedicated terms for these objects, they probably will diverge and splitting up a table afterwards is quite some work, also on the code side, so I would suggest you map dedicated entities/tables from the beginning.
can i relate an entity with three other entities(weak) over an identifying relationship. For example, an entity item is related to three other entities book_item,cd_item and magazine_item over a "is a" relationship.(book_item,cd_item and magazine_item are weak entities)is this possible ?
While subtyping can be represented as an identifying relationship without a weak key in classic ER diagrams, it's best to distinguish the concepts. A subtype is a subset, meaning identity isn't changed in the process. A subtype of a regular entity set is still regular, a subtype of a weak entity set is weak.
This is different from parent/child entity sets wherein children are identified via the parent identifier and a weak key. Weak children are a different entity set from their parents, whereas subtypes are a subset of the same entity set.
I suggest you use one of the subtyping notations of EER diagrams, and don't mix identifying/weak terminology with subtyping/supertyping, unless for an academic exercise in classic ER.
In ER diagrams, is it possible to relate two weak entities each other? If possible, how can uniquely identify records in them?
It's certainly possible. Consider the following ER diagram in which invoices are composed of lines, and receipts are decomposed into corresponding lines which are allocated to invoice lines. Multiple receipt lines can be allocated to the same InvoiceLine. It's perhaps a bit contrived but it'll serve as an example.
The InvoiceLine entity set is identified by (InvoiceNumber, LineNumber). Similarly, the ReceiptLine entity set is identified by (ReceiptNumber, LineNumber).
The determinant of a relationship between any entity sets is a combination of the determinants of the entity sets in many-roles. It doesn't matter whether the entity sets are weak or regular, or whether you have two or more entity sets involved in the relationship. In the case of 1:1 (or 1:1:1, etc) relationship, any of the entity sets involved can be used as a determinant.
In our example, ReceiptLine is the only entity set in a many-role (indicated by an N next to the Paid relationship diamond). This means the relationship is determined by the determinant of ReceiptLine, which is (ReceiptNumber, LineNumber).
If we translate our ER diagram to a tabular model, we get the following:
I translated it directly to help you see the correspondence between the diagrams, but in practice we could denormalize the Paid relationship relation into the ReceiptLine entity relation for a simpler physical model. That can only be done for relationships with a single determining entity set, so it's important that you understand the general approach first.
I want to know whether I can connect a ternary relationship to a another entity without that forming an n-ary relationship. To describe in terms of tables, I want to get a reference in the ternary relationship table to another (entity's) table.
Conceptually and generally, yes.
It can reasonably be called a binary relationship between the other and the associative entity, and a 4-way relationship among/over the other and the entities that form the associative entity.
But what exactly your terms mean and how you are allowed to design depends on your particular information modeling method and/or tool.
Eg your method/tool might or might not require that you add an identifier to an association type and use that in other tables rather than just the 3 columns.
Eg E-R Modeling distinguishes between "entity" and "relationship" types (each type having a corresponding table with other columns for "properties"). But this isn't actually necessary in informaton modeling since an "entity" could just be considered a 1-ary "association" and a "property" could just be considered an "entity". (Is a "marriage" a "relationship" between spouses and/or an "entity" with an anniversary and/or "property" of a family or wedding?) Also, any columns that are unique in any table or query result identify some "thing" type whether or not it is one of the base (non-associative or associative) "entity" types.
(More here.)
I have question about inheritance representation in ERD-diagram.
The following example:
I have plane, and I have also two types of planes
1-PersonsPlane
2-CargoPlane
I am confused about which relationship to use ( 1-to-1 OR 1-to-Many). My DB teacher told me that I should use a 1-to-1 relationship, But I have found on the internet many examples use (1-to-Many) relationship instead of (1-to-1).
Check these images:
One-to-One relationship
One-to-Many relationship
Which one is correct??
inheritance relationship in ERD should be represented as One-To-One relationship or One or Zero-to-One relationship depending on the case.
1) 0..1-1 : If there could be an entity of plane since plane can exist without having child entity like cargo or personal but cargo and personal cannot exist without having a parent plane entity.
2) 1-1: If each entity cannot exist by it self. The PK in plane is the foreign key and primary key in cargo and personal child tables.
I don't think that in any case it is a one-to-many and I will give you an example: a db record of plane pk=1. Two db record of personal plane with foreign key=1 referencing one record in parent plane table. This means that there are two children entities with same key which is wrong. There must be only one referenced record in the child table thus 0..1-1 or 1-1 relationship.
ER modeling (or, more precisely, EER modeling) has a way to represent inheritance in the diagram. It goes by the name "generalization/specialization". You can find a number of good articles on the web by searching on this.
The diagramming technique doesn't tell you how to design relational tables that reflect this inheritance situation. That's really more a matter of database design than ER diagramming. If you look up Martin Fowler's treatment of "class table inheritance" or "single table inheritance", you'll get a good presentation of some design patterns.
There are tags with those names here in SO, and the info under those tags is helpful, as well as the questions that have been tagged with them.