ER Diagram

Notes of ENTITY RELATIONSHIP Modelling

1 Mrs Mousmi Ajay Chaurasia,Lect. Deptt. Of Information Technology, BIT DURG

Entity – Relationship(ER) Modelling

ER Model Concepts --Entities and Attributes -- Entity Types, Value Sets, and Key Attributes --Relationships and Relationship Types -- Weak Entity Types

1

--Roles and Attributes in Relationship Types A database can be modeled as: – a collection of entities,

– relationships among entities.

Entity/Relationship approach - one of the most well known modeling methods

Developed by P.Chen in 1976 - many variations since then Entity:A real-world object that can be distinctly identified may represent some real physical object. E.g., Satish is a government employee; Kareena Kapoor is an actress; my car is a Honda City May represent some conceptual idea E.g., SC304 is a course; Semester 1 2001/2002 is a semester

An entity is an object that exists and is distinguishable from other objects. Example: specific person, company, event, plant

An entity set is a set of entities of the same type that share the same properties. Example: set of all persons, companies, trees, holidays. An Entity should be:

• An Object that will have many instances in the DB

• An Object that will have multiple attributes

• An Object that v r trying to model An Entity should not be:

• User of the DB

• An O/P of the DB(eg. Report)

Attributes: An entity is represented by a set of attributes, that is,descriptive properties possessed by all members

of an entity set.(value from corresponding entity) Example: customer = (customer-name, social-security, customer-street, customer-city) account = (account-number, balance) Domain – the set of permitted values for each attribute

Attribute types: • Simple and composite attributes.

• Single-valued and multi-valued attributes

• Null attributes

• Derived attributes

• Identifiers(Key) attributes



Simple versus composite

Simple attributes are atomic.E.g. tel_ph; house color; basic-salary;

Composite attributes made up of simple attributes. E.g., address = (St_add,city,state, postal code)

Composite Simple Key is underlined Single valued versus multivalued Single valued: single value associated with an attribute Multivalued: may have more than one values. E.g., University degree attribute may contain B.Eng., M.Eng., or Ph.D.

• Composite attributes b/w ( ) and separating with commas and multivalued b/w { }. Such attributes r called COMPOSITE ATTRIBUTES

Stored versus derived Most attribute values are stored eg birthdate. BUT Derived from stored value. E.g., age from birth date Null : An attribute takes a null value when an entity does not have a value for it. eg house_no Height of a person attribute is missing n homephone attribute is not known attribute. IIddeennttiiffiieerrss ((KKeeyyss)): An attribute(or combination of attributes) that uniquely identifies the instances of an entity type. Identifiers will not change in value,will not be null.No intelligent Identifiers( containing people or locations that might change).

Derived Identifier Multivalued (from date_employ& current date) (employee can have more than 1 skill)



Summary of ER diagram ,Notation of ER Schemas

Symbol Meaning

ENTITY TYPE WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

PRIMARY KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

TOTAL PARTICIPATION OF E2 IN R

CARDINALITY RATIO 1:N FOR E1:E2 IN R ENTITY TYPE

GENERALIZATION OR SPECIALIZATION

PARTIAL KEY (WEAK ENTITY)

ROLE INDICATOR

RELATIONSHIP SETS: An association among entities.(set of relationship of the same type)

A relationship set is a mathematical relation among n >= 2 entities, each taken from entity sets { (e1, e2, ..., en) | e1 E1, e2 E2, ..., en En}

where (e1, e2, ..., en) is a relationship – Example: (Hayes, A-102) depositor An attribute can also be a property of a relationship set. For instance, the depositor relationship set between entity sets customer and account may have the attribute access-date.



Degree of the relationship sets: Refers to number of entity sets that participate in a relationship set. Relationship sets that involve two entity sets are binary (or degree two). Generally, most relationship sets in a database system are binary. Relationship sets may involve more than two entity sets. The entity sets customer, loan, and branch may be linked by the ternary (degree three) relationship set. Or may say: Urnary Relationship, Binary relationship, Ternary Relationship

One entity related Entities of two different types Entities of three different to another of the same entity type related to each other types related to each other

Roles: Entity sets of a relationship need not be distinct.

The labels “manager” and “worker” are called roles; they specify how employee entities interact via the works-for relationship set. Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to rectangles. Role labels are optional, and are used to clarify semantics of the relationship.



Cardinality of Relationship:(Structural Constraints) Express the number of entities to which another entity can be associated via a relationship set.

Most useful in describing binary relationship sets.For a binary relationship set the mapping cardinality must be

one of the following types: – One to one: Each entity in the relationship must have exactly one related entity. – One to many (many to one): An entity in the relationship on one side can have many related entities but on the other side will have maximum of one related entity. – Many to many: Entities on both the sides can have many related entities on the other side. We distinguish among these types by drawing either a directed line ( ), signifying “one,” or an undirected line (—), signifying many,” between the relationship set and the entity set.

Unary Relationships:

Binary Relationships:

Ternary Relationships: Note: Relationships can have Attributes of their own.



Example of Binary Relationship: works_for relationship b/w EMPLOYEE entity type and DEPARTMENT entity type

Each instance ‘r’ must relate one employee to one dept.

Example for Ternary Relationship:

Each instance of ‘r’ must be associated with three objects

Example of 1:1 Relationship:

DDL: customer(ssn,cust_nm,cust_st,cust_city)

Loan( Loan_nmbr,amt) Borrower(ssn,loan_nmbr) OR

customer(ssn,cust_nm,cust_st,cust_city)

Loan( Loan_nmbr,amt) A customer is associated with at most one loan via the relationship borrower and a loan is associated with at most one customer via borrower. If borrower also has attributes(say: amount,date) then DDL : borrower(amt,dt#)

Employee WORKS_FORDepartment

d1

d2

d3

r1

r2

r3

r4

r5

emp1

emp2

emp3

emp4

emp5



Example of 1:M and M:1 Relationship:

In the one-to-many relationship, a loan is associated with at most one customer via borrower; a customer is associated with several (including 0) loans via borrower

In the many-to-one relationship, a loan is associated with several (including 0) customers via borrower; a customer is associated with at most one loan via borrower. Example of M:M Relationship:

A customer is associated with several (possibly 0) loans via borrower. A loan is associated with several (possibly 0) customers via borrower. Each entity may result in a relation whose attributes are the properties for the entity .Each relationship may result in a relation whose attributes link the entities described in the relationship

Weak Entity Sets: A weak entity is an entity that cannot be uniquely identified by its own attributes alone.

An entity set that does not have a primary key is referred to as a weak entity set.Has no key attributes. � The existence of a weak entity set depends on the existence of a strong entity set; it must relate to the strong set via a one-to-many relationship set.

� The discriminator (or partial key) of a weak entity set is the set of attributes that distinguishes among all the entities of a weak entity set.(or Set of attributes that uniquely identify weak entities related to same owner entity).

� The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set is existence dependent, plus the weak entity set’s discriminator.(Primary key of weak entity: identifying owner’s primary key + partial key)

We depict a weak entity set by double rectangles. We underline the discriminator of a weak entity set with a dashed line.



Eg. payment-number – discriminator of the payment entity set Primary key for payment – (loan-number, payment-number)

Identifing Relationship(i.e. weak)

Strong vs. Weak Entities, and Identifying Relationships

Strong: � exists independently of other types of entities � has its own identifier � represented in a single line rectangle

Weak: � dependent on a strong entity……………cannot exits on its own � does not have a unique identifier � represented in a double line rectangle

Identifying Relationships: � links strong entities to weak entities � represented with double line diamond

Example:

Primary Key Strong Entity Identifying relationship Partial Key Weak Entity DDL: emp (emp_id,emp_nm) Dependent (dep_nm,DOB,emp_id) Dep_nm ( f_nm,m_nm,L_nm)



EXAMPLES OF E-R RELATIONSHIPS MODELS:

I] E-R diagram for a COMPANY SCHEMA

• Organization made up of various departments, each having a name, identifying no., and an employee who is the

manager. A department may be located in different places.(A) • Information about employees include name, identification number, birthdate, address, sex, and salary. Each employee is assigned to one department.The date the manager is appointed to a department is also tracked.

Employees may be directly supervised by another employee.(B)

• Each project within the organisation is controlled by a department. Employees (not necessarily from the controlling

dept.) are assigned to projects.( C) • Information about projects include project name, no., and location. Hours spent by employees on each project are

also kept.( D)

• Information about employees’ dependents are kept. These include name, sex, birthdate and relationship(E)



II] E-R diagram for a BANK DATABASE

III] A publishing company produces scientific books on various subjects. The books are written by authors who specialize in

one particular subject. The company employs editors who, not necessarily being specialists in a particular area, each take sole responsibility for editing one or more publications. A publication covers essentially one of the specialist subjects and is normally written by a single author. When writing a particular book, each author works with on editor, but may submit another work for publication to be supervised by other editors. To improve their competitiveness, the company tries to employ a variety of authors, more than one author being a specialist in a particular subject.



IV] A General Hospital consists of a number of specialized wards (such as Maternity, Paediatry, Oncology, etc). Each ward hosts a number of patients, who were admitted on the recommendation of their own GP and confirmed by a consultant employed by the Hospital. On admission, the personal details of every patient are recorded. A separate register is to be held to store the information of the tests undertaken and the results of a prescribed treatment. A number of tests may be conducted for each patient. Each patient is assigned to one leading consultant but may be examined by another doctor, if required. Doctors are specialists in some branch of medicine and may be leading consultants for a number of patients, not necessarily from the same ward. Partial Answer

FULL ANSWER



V] A database is to be designed for a Car Rental Co. (CRC). The information required includes a description of cars,

subcontractors (i.e. garages), company expenditures, company revenues and customers. Cars are to be described by such data as: make, model, year of production, engine size, fuel type, number of passengers, registration number, purchase price, purchase date, rent price and insurance details. It is the company policy not to keep any car for a period exceeding one year. All major repairs and maintenance are done by subcontractors (i.e. franchised garages), with whom CRC has long-term agreements. Therefore the data about garages to be kept in the database includes garage names, addressees, range of services and the like. Some garages require payments immediately after a repair has been made; with others CRC has made arrangements for credit facilities. Company expenditures are to be registered for all outgoings connected with purchases, repairs, maintenance, insurance etc. Similarly the cash inflow coming from all sources - car hire, car sales, insurance claims - must be kept of file.CRC maintains a reasonably stable client base. For this privileged category of customers special credit card facilities are provided. These customers may also book in advance a particular car. These reservations can be made for any period of time up to one month. Casual customers must pay a deposit for an estimated time of rental, unless they wish to pay by credit card. All major credit cards care accepted. Personal details (such as name, address, telephone number, driving licence, number) about each customer are kept in the database.

VI] A database is to be designed for a college to monitor students' progress throughout their course of study. The students are reading for a degree (such as BA, BA(Hons) MSc, etc) within the framework of the modular system. The college provides a number of module, each being characterised by its code , title, credit value, module leader, teaching staff and the department they come from. A module is co-ordinated by a module leader who shares teaching duties with one or more lecturers. A lecturer may teach (and be a module leader for) more than one module. Students are free to choose any module they wish but the following rules must be observed: some modules require pre-requisites modules and some degree programmes have compulsory modules. The database is also to contain some information about students including their numbers, names, addresses, degrees they read for, and their past performance (i.e. modules taken and examination results).



VII] A relational database is to be designed for a medium sized Company dealing with industrial applications of computers. The Company delivers various products to its customers ranging from a single application program through to complete installation of hardware with customized software. The Company employs various experts, consultants and supporting staff. All personnel are employed on long-term basis, i.e. there are no short-term or temporary staff. Although the Company is somehow structured for administrative purposes (that is, it is divided into departments headed by department managers) all projects are carried out in an inter-disciplinary way. For each project a project team is selected, grouping employees from different departments, and a Project Manager (also an employee of the Company) is appointed who is entirely and exclusively responsible for the control of the project, quite independently of the Company's hierarchy. The following is a brief statement of some facts and policies adopted by the Company.

ENHANCED E-R MODELLING

ALTERNATIVE DIAGRAMMATIC NOTATIONS



Things to be covererd in EER Model

� Superclasses/subclasses, attribute inheritance � Generalization/specialization � Membership Constraints � Specialization hierarchies, specialization lattices, single & multiple inheritance � Aggregation

It is used to model applications more completely and accurately if needed.It includes some

object-oriented concepts, such as inheritance .

Superclasses/Subclasses and Attribute Inheritance:

An entity type (set) may have additional sub-groups that are meaningful and need be represented

explicitly because of their significance to the database application. Example: Superclass: Employee Subclass: Administrative Officers, Lecturers, Technicians, Clerical Officers, Cleaners.

Superclass/subclass relationship called an IS-A relationship E.g., Lecturer IS-A Employee Notation used is subset symbol ‘ ‘on connecting line from superclass to subclass. “d” within circle indicates ‘disjoint’ and double line between superclass and circle indicates TOTAL participation

An entity that is member of a subclass represents the same real-world entity as some member of the superclass .The Subclass member is the same entity in a distinct specific role :-

1. An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of the superclass

2. A member of the superclasscan be optionally included as a member of any number of its subclasses Example: A salaried employee who is also an engineer belongs to the two subclasses ENGINEER and SALARIED_EMPLOYEE (It is not necessary that every entity in a superclass be a member of some subclass). Attribute inheritance in supreclass/subclass relationships:

- An entity in a subclass inherits(apply) all attributes of its superclass.It inherits all relationships. a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked. Generally,disjoint relationships can be drawn in GENERALIZATION N SPECIALIZATION. Example:



Example:

SPECIALIZATION:

Specialization is process of defining a set of subclasses of an entity type.It’s a set of subclasses form a specialization on the basis of some distinguishing characteristic(s). Top-down design process; we designate subgroupings within an entity set that are distinctive from other entities in the set.These subgroupings become lower-level entity sets that have attributes or participate in relationships that do not apply to the higher-level entity set. Define different roles for different entities of same entity type. Associate additional specific attributes to subclass. Depicted by a triangle component labeled ISA (i.e., savings-account “is an” account)

GENERALIZATION:

Specialization and generalization are simple inversions of each other; they are represented in an E-R diagram in the same way. A bottom-up design process:A combine a number of entity sets that share the same features into a higher-level entity set.To generalize a set of entity types into a single superclass .Identify common features. Generalize into a superclass; original entity types become subclasses.



Example involves two entity types: CAR and TRUCK which are generalized to form a superclass VEHICLE

Membership Constraint:

Determine which entity belong to specific subclass using condition (predicate) on attribute of superclass. Condition is a constraint specifying subclass membership. Predicate-defined (or condition-defined) subclasses: All subclasses have membership condition on same attribute of superclass E.g., attribute JobType added to EMPLOYEE can be used to specify membership condition

Disjointness/Overlapping constraint

� Disjoint: Entity can be a member of at most one subclass of specialization (“d” in circle) � Overlapping: Entity can be a member of more than subclass(default; some notations depict this as “o” in circle)

Total/Partial constraint

� Total specialization: Every entity in superclass must be a member of some subclass (double-line) � Partial specialization: Some entities in superclass may not be a member of subclasses (single-line)

Independence of completeness and disjointness constraints; hence 4 constraints on specialization



Specialization Hierarchies, Lattices & Multiple Inheritance

Subclass may have further subclasses. Specialization hierarchy: Every subclass participates in one class/subclass relationship.

Specialization Lattice: A subclass may participate in more than one class/subclass relationship.One subclass can have more than one superclass

Hierarchy(ladder) has a constraint that every subclass has only one superclass(called single inheritance) In a lattice(web,network,pattern), a subclass can be subclass of more than one superclass(called multiple inheritance) (two superclass can have one common subclass)



Specialization / Generalization Lattice Example (UNIVERSITY)

AGGREGATION In E-R, a relationship type cannot be connected directly to another relationship type. To overcome this, aggregates are used. Example:



Example: Loan customer may be advised by a loan-officer.

Relationship sets borrower and loan-officer represent the same information. We can Eliminate this redundancy via aggregation by taking following actions:

• Treat relationship as an abstract entity

• Allows relationships between relationships

• Abstraction of relationship into new entity Without introducing redundancy, the following diagram represents that:

• A customer takes out a loan

• An employee may be a loan officer for a customer-loan pair.



Example of aggregation:

Some more examples to practice:

1) Some Institute of Technology (SIT) is considering to modernize its administrative functions including is campus-wide information database. Since SIT is in the same financial shape as all universities are, it was decided to collect many free designs and evaluate them.Requiremnts are: Academic Structure:

• Colleges – containing many departments, head by a Dean, etc.

• Departments – containing many labs, faculty, courses, students, head by a Chair, etc. Classes:

• Locations, prerequisites, offerings, professors Personnel:

• Names, social security numbers, children, offices, phone numbers, email addresses, salary, etc. Cafeteria Offerings:

• Prices, item selection based on meal (breakfast,lunch,&dinner),purchases(date & cost),location,manager, etc.



DDL Statements are:

(Prereqs:- prerequisition of courses)



2) Example of ternary Relationship

3) Weak Entity

4) M:M

5) 1:1



6) 1:M and M:1

(i)

(ii)

Documents

ER Diagram