Entity-Relationship Model

Data ModelA data model is a collection of conceptual tools for describing data, data relationship, data semantics and consistency constraints.

Entity-Relationship Model: This is a higher-level data model. It is based on a perception of a real world that consists of a collection of basic objects, called entities and the relationship among these objects.

Relational Model: This is a lower level model. It uses a collection of tables to represent both data and relationships among those data.

Designers often formulate database schema design by first modeling data at a high level, using E-R model and then translating it into the relational model.

Entity

An entity is a “thing” or “object” in the real world that is distinguishable from all other objects. An entity has a set of properties and the values for some set of properties may uniquely identify an entity. An entity may be concrete, such as a person or a book, or it may be abstract, such as loan, or a holiday, or a concept.

Entity Set

An entity set is a set of entities of the same type that share the same properties, or attributes.

Customer – The set of all persons who are customers at a given bankLoan – The set of all loans awarded by a particular bank

Attributes: An entity is represented by a set of attributes. Attributes are descriptive properties possessed by each member of the entity set. The designation of an attribute for an entity set expresses that the database stores similar information concerning each entity in the entity set; however, each entity may have its own value for each attribute.

customer- customer-id, customer-name, customer-street, customer-cityloan – loan-number, amount

Domain or value set: For each attribute, there is set of permitted values, called the domain or value set.

customer-name – Set of all text strings of a certain lengthloan-number – Set of all strings of the form “L-n”, where n is a positive integer

A database thus includes a collection of entity sets, each of which contains any number of entities of same type.

Attribute Types: Simple and Composite

Simple – When an attribute is not possible to divided into subparts, customer city, countryComposite – Composite attributes can be divided into subparts i.e. other attributes. Composite attributes help us to group together the related attributes, making the modeling cleaner.name – first-name, middle-name, last-nameaddress – street, city, state, zip-code (postal code)street – street-number, street-name, apartment-number Single-valued and multi-valued

Single-valued – when there exist a single value for a particular entity, loan-numberMulti-valued – When there exist a set of values for a specific entity, phone-number, dependent-name of the employee entity set Boundary can be assigned for a multi-valued attribute

Derived – The value of this type of attribute can be derived from the values of other related attributes or entities.

loans-held attribute in customer entity set - How many loans a customer has from a bank

age attribute in customer entity set where there is a attribute named date-of-birth. date-of-birth may be referred to as a base attribute, or a stored attribute. The value of a derived attribute is not stored, but is computed when required.

Null Value: An attribute can take a null value when an entity does not have a value for it.

1. Not applicable – middle name2. Unknown – a. missing – the value does exist but we do not have that information - name

– b. not known – do not know whether or not the value actually existCommon Example: apartment no.

RelationshipA relationship is an association among several entities

Relationship SetA relationship set is a set of relationships of the same type.

Formally it is a mathematical relation on n>= 2 (possibly non-distinct) entity sets. If E1, E2, ….., En are entity sets, then a relationship set R is a subset of{(e1, e2,…., en) | e1 E1, e2 E3, ………., en En }Where (e1, e2, ……, en) is a relationship.

borrower – association between customer and loanloan-branch – association between loan and branchdepositor – association between customer and account

Participation: The association between entity sets is referred to as participation, i.e. the entity sets E1, E2, ……., En participate in relationship set R.

Descriptive Attribute: A relationship may also have attributes called descriptive attributes.

depositor : customer – account, access-date (the most recent date on which a customer accessed an account.

Degree of Relationship set: The number of entity set that participate in the relationship set is called the degree of the relationship set. A binary relationship is of degree 2; a ternary relationship set is of degree 3.

Constraints

An E-R enterprise schema may define certain constraints to which the contents of a database must conform. Two of the most important constraints are:

A. Mapping Cardinalities or cardinality ratios

Mapping cardinalities express the number of entities to which another entity can be associated via a relationship set. For a binary relationship set R between entity sets A and B the mapping cardinality must be one of the following:

1. One to one2. One to many3. Many to one4. Many to many

One to one – An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A One to many - An entity in A is associated with any number (zero or more) entities in B. An entity in B, however, can be associated with at most one entity in A

Many to one - An entity in A is associated with at most one entity in B. An entity in B, however, can be associated with any number (zero or more) entities in A.

Many to many - An entity in A is associated with any number (zero or more) entities in B and An entity in B can be associated with any number (zero or more) entities in A.

B. Participation Constraints

The participation of an entity set E in a relationship set R is said to be total if every entity in E participates in at least one relationship in R. If only some entities in E participate in relationships in R, the participation of entity set E in relationship R is said to be partial.

Keys

The values of the attributes of an entity must be such that they can uniquely identify the entity from the entity set. In other words, no two entities in an entity set are allowed to have exactly the same value for all attributes.

A key allows us to identify a set of attributes that suffice to distinguish entities from each other. Keys also help uniquely identify relationships, and thus distinguish relationships from each other.

A. Entity Sets

1. Superkey – A superkey is a set of one or more attributes that, taken collectively, allow identifying uniquely an entity in the entity set. A superkey may contain extraneous attributes. customer – {customer-id}, {customer-name, customer-id}, {all attribute}customer-name is not a superkey

2. Candidate Key – The superkey for which no proper subset is a superkey is a candidate key. So the minimul superkeys are called is candidate keys. It is possible that several distinct sets of attributes could serve as a candidate key.{customer-name, customer-street}, {customer-id}{customer-id, customer-name} is not a candidate key because customer-id itself is a super key/candidate key.

3. Primary Key – The primary key is to denote a candidate key that is chosen by the database designer as the principal means of identifying entities within the entity set. A key (primary, candidate and super) is the property of the entity set, rather than of the individual entities.

So, Primary key Candidate Key Super key

B. Relationship Sets

SuperkeyLet R be a relationship set involving entity sets E1, E2, ….., En. Let Primary Key (Ei ) denote the set of attributes that forms the primary key for entity set Ei. Assume for now that the attribute names of all the primary keys are unique, and each entity set participates only ones in the relationship. The composition of the primary key for a relationship set depends on the set of attributes associated with the relationship set R.

i) If the relationship set R has no attributes associated with it (descriptive attribute/s), then the set of attributes Primary Key (E1 ) U Primary Key (E2 ) U…..U Primary Key (En )describes an individual relationship in set R.

ii) If the relationship set R has attributes a1, a2, ……, am associated with it, then the set of attributes Primary Key (Ei ) U Primary Key (E2 ) U…..U Primary Key (En ) U { a1, a2, ……, am }describes an individual relationship in set R.

iii) In both the above cases, the set of attributesPrimary Key (Ei ) U Primary Key (E2 ) U…..U Primary Key (En )forms the superkey for the relationship set.

Primary Key: The structure of the primary key for the relationship set depends on the mapping cardinalities of the relationship set.

Depositor – customer and account with attribute access-date

1. many to many – the primary key of depositor consists of the union of the primary keys of customer and account

2. many to one from customer to account - the primary key of depositor is simply the primary key of customer (many sided)

3. one to many from customer to account - the primary key of depositor is simply the primary key of account (many sided) 4. one to one from customer to account - the primary key of depositor is either of the entity set (customer or account)

Weak Entity Sets and Strong Entity Sets

Strong Entity Set: An entity set that has a primary key is termed as strong entity set.

Weak Entity Set: An entity set may not have sufficient attributes to form a primary key. Such an entity set is termed as weak entity set.Payment = (payment-number, payment-date, payment-amount)

Identifying or Owner entity set: For a weak entity set to be meaningful, it must be associated with another entity set, called the Identifying or Owner entity set Every weak entity must be associated with an identifying entity, i.e., the weak entity set is said to be existence dependent on identifying entity set.

The identifying entity set is said to own the weak entity set that it identifies.

Identifying Relationship: The relationship associating the weak entity set with the identifying entity set is called the identifying relationship.

The identifying relationship is one to many from the identifying entity set to weak entity set and the participation of weak entity set in the relationship is total.

Discriminator: The discriminator in the weak entity set is a set of attributes that distinguish entities in the weak entity set that depend on one particular strong entity. This is also called the partial key of the entity set.Payment no. of weak entity set payment is the discriminator

The primary key of the identifying entity set plus the discriminator of the weak entity set forms the primary key of a weak entity set.

{loan no., payment no.} is the primary key of weak entity set payment where loan no. is the primary key of the identifying entity set loan

The identifying relationship set should have no descriptive attributes, since any required attributes can be associated with the weak entity set.

1. A weak entity set can participate in relationships other than the identifying relationship.

2. A weak entity set may participate as owner in an identifying relationship with another weak entity set.

3. It is possible to have a weak entity set with more than one identifying entity set. The primary key of the weak entity set would consist of the union of the primary keys of the identifying entity sets plus the discriminator of the weak entity set.

Entity-Relationship Diagram: The E-R diagram can express the overall logical structure of a database graphically. Such a diagram consists of the following major components:

1. Rectangles, which represent entity sets2. Ellipses, which represent attributes3. Diamonds, which represent relationship sets4. Lines, which link attributes to entity sets and entity sets to relationship sets5. Double ellipses, which represent multivalued attributes6. Dashed ellipses, which denote derived attributes7. Double lines, which indicate total participation of an entity in a relationship set8. Double rectangles, which represent weak entity set9. Double diamond, identifying relationship set for weak entity set

Note: See symbols used in E-R notation (Figure 2.20)

Design Issues

1. Use of Entity Sets Vs Attributes - What constitutes an attribute and what constitutes an entity set? 2. Use of Entity Sets Vs Relationship Sets3. Binary Vs n-ary Relationship Sets4. Placement of Relationship Attributes

a) Attributes of a one to many relationship set can be repositioned to only the entity set on the many side of the relationship

b) For one to one relationship sets, the relationship attribute can be associated with either one of the participating entity sets.

c) When an attribute is determined by the combination on participating entity sets, rather than by either entity separately, that attribute must be associated with the many to many relationship set.

2.9 Reduction of an E-R Schema to Tables

Primary keys allow entity sets and relationship sets to be expressed uniformly as tables which represent the contents of the database.

A database which conforms to an E-R diagram can be represented by a collection of tables.

For each entity set and relationship set there is a unique table which is assigned the name of the corresponding entity set or relationship set.

Each table has a number of columns (generally corresponding to attributes), which have unique names.

Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram.

Tabular Representation of Strong Entity Sets

Let E be a strong entity set with descriptive attributes a1, a2,….,an. We represent this entity by a table called E with n distinct columns, each of which corresponds to one of the attributes of E. Each row in this table corresponds to one entity of the entity set E.

Example: loan: loan-number, amountcustomer: customer-id, customer-name, customer-street, customer-city

Tabular Representation of Weak Entity Sets

Let A be a weak entity set with attributes a1, a2,….,am. Let B be a strong set on which A depends. Let the primary key of the B consists of b1, b2,….,bn. We represent the entity set A by a table called A for each attribute of the set:

{a1, a2,….,am } U { b1, b2,….,bn }

Example: payment: loan-number, payment-number, payment-date, payment-amount

Tabular Representation of Relationship Sets

Let R be a relationship set, let a1, a2,….,am be the set of attributes formed by the union of the primary keys of each of the entity set participating in R, and let the descriptive attributes (if any) of R be b1, b2,….,bn .We represent the relationship set R by a table called R for each attribute of the set:{a1, a2,….,am } U { b1, b2,….,bn }

Example: Entity set loan: loan-number, amountEntity set customer: customer-id, customer-name, customer-street, customer-cityRelationship set borrower: customer-id, loan-no

Redundancy of Tables

1. A relationship set linking a weak entity set to the corresponding strong entity set is many to one relationship set and has no descriptive attributes.

2. The primary key of a weak entity set includes the primary key of strong entity set.

Example:

Strong Entity set loan: loan-number, amountWeak Entity set payment: loan-number, payment-number, payment-date, payment-amountIdentifying Relationship set loan-payment: loan-number, payment-no

So loan-payment table is redundant. In general, the table for the relationship set linking a weak entity set to its corresponding strong entity set is redundant.

Combination of Tables

If there are two entity sets A and B and there exist relationship set R between them, 3 tables A, B, R can be generated using table construction scheme.

1. one to one relationship from A to B - the primary key of R is either of the entity set (A or B)

These can be combined into 2 tables: AR, B or A, BR

2. one to many from A to B - the primary key of R is simply the primary key of B

These can be combined into 2 tables: A, BR

3. many to one from A to B - the primary key of R is simply the primary key of A

These can be combined into 2 tables: AR, B

4. many to many – the primary key of R consists of the union of the primary keys of A and B

There is no other alternative but to keep all the 3 tables.

For all the above cases there should be total participation of the entity sets in the relationship set. Combination of tables works nicely in case of total participation. If there exists partial participation and we combine the tables there will be null values for some entities those do not participate in relationship.

Composite Attributes

Composite attributes are handled by creating a separate attribute for each of the component attribute and there should not be a separate column for the composite attribute itself.

Entity set customer: customer-id, name having composite attribute name with component attributes first-name, middle-initial, last-nameTable customer : customer-id, first-name, middle-name, last-name

Multivalued Attributes

For a multivalued attribute M, we create a table T with a column C that corresponds to M and columns corresponding to primary key of the entity set or relationship set of which M is an attribute.

Entity set employee: employee-id, employee-name, dependent-nameTable employee: employee-id, employee-nameTable dependent-name: employee-id, dname

Entity set customer: customer-id, date-of-birth, phone-no.Table customer: customer-id, date-of-birthTable cust-phone: customer-id, phone-no.

Extended E-R Features

1. Specialization2. Generalization3. Attribute Inheritance4. Aggregation

Specialization: An entity set may include sub-grouping of entities that are distinct some way from other entities of the entity set. The process of designating sub-grouping within an entity set is called specialization.

person = {name, street, city}customer = {name, street, city, customer-id}employee = { name, street, city, employee-id, salary}

account = {account-no., balance}savings-account ={ account-no., balance, interest rate}checking-account ={ account-no., balance, overdraft-amount}

Higher and lower level entity set or Super class and subclass

Generalization

The refinement of initial entity set into successive levels of entity sub-groupings represents a top-down design process in which distinctions are made explicit.

The design process may also proceed in a bottom-up manner, in which multiple entity sets are synthesized into a higher level entity set on the basis of common features. This commonality can be expressed by generalization. Generalization is used to emphasize the similarities among the lower level entity sets and to hide the differences; it also permits an economy of representation in that shared attributes are not repeated.

customer = {name, street, city, customer-id}employee = { name, street, city, employee-id, salary}person = {name, street, city}

savings-account ={ account-no., balance, interest rate}checking-account ={ account-no., balance, overdraft-amount}account = {account no., balance}

Constraints on Generalizations/Specialization

A. Type1: Constraint on which entities can be members of a given lower-level entity set.

1. Condition-defined: In condition-defined lower-level entity sets, membership is defined on the basis of whether or not an entity satisfies an explicit condition or predicate. It is also called attribute-defined generalization.Example: Saving account and Checking account

2. User-defined: Used-defined lower-level entity sets are not constrained by a membership condition; rather, the database user assigns to a given entity set. Example: Employee and Team

B. Type2: Constraint on whether or not entities may belong to more than one lower-level entity set within a single generalization.

1. Disjoint: A disjointness constraint requires that an entity belong to no more than one lower-level entity set.Example: Saving account and Checking account

2. Overlapping: In overlapping generalizations, the same entity may belong to more than one lower-level entity sets within a single generalization.Example: Employee and Team

C. Completeness constraint: specifies whether or not an entity in the higher-level entity set must belong to at least one of the lower-level entity sets within the generalization/ specialization.

1. Total generalization or specialization: Each higher-level entity must belong to a lower-level entity set.Example: Saving account and Checking account

2. Partial generalization or specialization: Some higher-level entities may not belong to any lower-level entity set.Example: Employee and Team