How do weak attributes convert from ER diagram to relational schema? - database

I am creating an ER diagram and relational schema for a school project. In my ER diagram, I have shown attributes like "street name" and "city" as weak attributes of another attribute "address." How would I convert this to a relational schema? Do weak attributes even appear in my relational schema?
Part of my ER Diagram

I prefer to call Billing Address a composite attribute, and City a component attribute.
The term "weak" is used in ER diagrams to describe entity sets that include another entity set's key as part of its own. For example, if an Invoice is identified by an Invoice_ID, and contains LineItems that are identified by Invoice_ID, Line_Number, that would make LineItem a weak entity set, and Line_Number would be its weak key.
When converting composite/component attributes to a relational schema, the simplest approach is to use only the component attributes. This means the composite attributes are nothing more than a visual aid.

Related

relating entities in an ER diagram

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.

ERM: Key attribute for relation

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.

Weak entity dbms

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.

Inheritance relationship in ERD diagrams

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.

Convert from ER to Relational Database - Mapping Weak entity types

I am trying to map the weak entity CatalogueEntry into a relational schema, and I am unsure which of the entities are the owner of this weak entity type. So, I don't know what the primary key of the relation in the relational schema is.
Anyone have any ideas? I have added an image below, thanks.
What is a Catalogue? Why doesn't catalogue appear on the diagram?
Sorry to ask stupid questions, but you learn to do that when you do data analysis.
It's useful to understand the data pretty well at the conceptal (ER) level, before switching to the relational level.
From the figure it shows that the weak entity CatelogueEntry depends on the Album strong entity by an identifying relationship (HasEntry).
For each catelogueEntry there must be an albumid. So here there are two tables. One is for Album and another table is for catelogueEntry. The catelogueEntry must contain a foreign key from album entry.

Resources