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.
Related
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.
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.
What i know about weak entity is that they cannot exist without strong entity:-
i.e there must be a strong entity from which key(foreign key) has to be taken by weak entity.
example : a HOTEL(strong entity) and ROOM(weak entity),
HOTEL is strong entity because they can have their existence by their own (independently) while ROOM is weak entity as they always need HOTEL without it (HOTEL) room cannot exists.
But while reading book i came across a statement which states that "However not every existence dependency results in weak entity type ".For example a DRIVER_LICENCE entity cannot exist unless it is related to a PERSON entity ,even though it has its own key (licence_number) and hence it is not a weak entity .
My question is how an entity depending upon strong entity cannot be a weak entity?
Weak entities aren't defined as being dependent on another for existence, but as being dependent on another for identity.
Quoting from Peter Chen's 1976 paper "The Entity-Relationship Model - Toward a Unified View of Data":
...we have two forms of entity relations. If relationships are used
for identifying the entities, we shall call it a weak entity relation.
If relationships are not used for identifying the entities, we shall
call it a regular entity relation. Similarly, we also have two forms
of relationship relations. If all entities in the relationship are
identified by their own attribute values, we shall call it a regular
relationship relation. If some entities in the relationship are
identified by other relationships, we shall call it a weak
relationship relation. For example, any relationships between
DEPENDENT entities and other entities will result in weak relationship
relations, since a DEPENDENT entity is identified by its name and its
relationship with an EMPLOYEE entity. The distinction between regular
(entity/relationship) relations and weak (entity/relationship)
relations will be useful in maintaining data integrity.
Thus, an entity that is identified by its own attributes is called a regular entity, regardless of whether it can exist independently or only in relation to another entity.
An entity that is identified by its relationship with another entity is necessarily dependent on it for existence, but that argument doesn't work the other way around. If it rains, the ground is wet, but just because the ground is wet doesn't mean it rained.
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.