ER Diagram Assignment Help UK, India, Australia, Canada etc. From Native Experts | Realcode4you

What is ER Diagram?

The original E-R model is drawn using:

- Rectangles for entities

- Diamonds for relationship

- Connected ellipses for attribute

Variations of the E-R Model

- At least three different versions of E-R model are in use today.

 Information Engineering (IE) Crow’s Foot model

 Integrated Definition 1, Extended (IDE1X)

 Unified Modeling Language (UML)

E-R Diagram – IDEF1X

- IDEF1X standard E-R modeling incorporates the basic ideas of the E-R model but uses different graphical symbols.

- IDEF1X is complex and unwieldy and is not very popular.

- IDEF1X is a national standard but it is very difficult to understand and use.

E-R Diagram – UML

- To add further complications, a newer object-oriented development methodology is introduced called Unified Modeling Language (UML).

- UML adopted E-R model but introduced its own symbols while adding an object-oriented programming spin on it.

- It is beginning to see widespread use among Objected-oriented practitioners.

E-R Diagram – IE Crow’s Foot

Crow’s Foot modeling uses slightly different symbols for showing the relationships (both maximum and minimum cardinalities) between entities:

- Instead of a diamond box for specifying maximum cardinality relationship, it use a

( | ) symbol (vertical hash mark) for 1 relationship and a ( < ) crow’s foot for many

relationship.

- For minimum cardinality, O (circle) symbol is used for optional relationship and ( |

) symbol (vertical hash mark) is used for mandatory relationship.

- Symbols that are next (closer) to the entities are used for maximum cardinality.

Crow’s Foot modeling Symbols

E-R Diagram – Strong / Weak Entity

 Strong Entity:

- An entity that represents something that can exist on its own.

- Example: PERSON, AUTOMOBILE, BUILDING

- Strong entities are called Non ID-Dependent entities.

Weak Entity:

- An entity whose existence depends on the presence of another entity.

- Example: APARTMENT depends on existence of BUILDING

- Part of the primary key for a weak entity is borrowed from the primary key of the

strong entity.

- Weak entities are called ID-Dependent entities.

- So, ID-dependent entity is a weak entity whose identifier includes the identifier of

another entity.

Relationship between a Strong Entity and a Strong Entity:

- A relationship between two strong entities is a strong relationship.

- Strong relationships are also called non identifying relationships.

- Strong relationships are drawn using dashed (----) line between the entities.

Relationship between a Strong Entity and a Weak Entity:

- A relationship between a strong entity and a weak entity is a weak relationship.

- Weak relationships are called identifying relationship.

- Because weak entity carries the identifier (primary key) from the strong entity, in a weak relationship, strong entity is always considered as a parent entity and the weak entity is considered as a child entity.

- Weak relationship is drawn using a solid line between the entities.

- In this examples, PHONE is a weak entity with part of the identifier is a primary key of the entity, COMPANY.

 Super-type & Subtype Entities:

- Another type of weak entity is a subtype entity.

- A subtype is a sub-grouping of the entities in an entity type that shares common attributes or relationships distinct from other subgroups.

- Subtypes inherit all super-type attributes.

- Super-type is an entity type that has a parent/child relationship with one or more subtypes with attributes that are shared with its subtypes.

- Super-types are parents entities while sub-types are considered as child entities.

There are two types of Sub-types entities:

- Exclusive Sub-types: one super-type relates to at most one sub type. Exclusive

subtypes are drawn using a circle with filled in X.

- Inclusive Sub-types: one super-type can relates to one or more sub-types.

Inclusive subtypes are drawn using open circle.

- All sub-type entities have the same identifier (primary key) as their super-type

entity.

- Relationships connecting super-type and sub-types are weak relationship.

- Thus, super-type entity is the parent entity and subtype entities are considered

children

E-R Diagram - Relationships

Crow’s Foot E-R Data Model

E-R Diagram – Best Practices

Entity Rules:

- Every entity table must have attribute(s). If you do not have any attribute, you do not need an entity with just PK.

- You cannot have a stand-alone entity in a database. Every entity table must be connected to at least one other table.

- Do not include foreign key in your E-R model.

- You cannot have the same PK as another entity’s PK unless it is a supertype/subtype relationship.

- When Composite PK borrowed from another entity. The entity must be a weak entity. Alternatively, you can use a Surrogate key to keep it as a strong entity.

Relationship Rules:

- A relationship between two strong entities must be strong.

- A relationship between a strong entity and a weak entity must be a weak relationship.

- Avoid having circular relationships. If you have a circular relationship between a, b, and c, you should be able to remove one of the three relationships and still be able to access each other information.

- Avoid having M-M relationships. Why do you need them?

- Minimum cardinality for the one side cannot be optional while many side is mandatory. Always make many side optional.

- If they have 1:1 relationship with same PK in the both table, why do you need two tables? You might as well place all attributes in one.

Super-type & Subtype Entities Rules:

- Subtypes must be weak entities.

- You must have at least two subtypes to create supertype/subtype relationships.

- Each subtype entity must have a PK that is same as the PK of the supertype.

- Supertype/Subtype relationships must be specific (inclusive or exclusive).

- Cardinalities are not needed for Supertype/Subtype relationships.

- Avoid having relationship with subtype entities. Instead, the relationship should be with their supertype.

- If attributes for each subtypes are same, there is no need for the subtypes. The rule is all subtypes must have different set of attributes.