Entity-Relationship Model

Reshma Dayma
 Design Process
 Task of database creation involves design of database schema, design of program
that access and update the program and design of security schema to control
access to data.

 For small application, designer can directly decide on what relations, attributes and
constraints will be required.

 But for such direct process is difficult for real world applications which are large in
scale.

 For large scale application, no single person can understand the complete
requirement, so designer must interact with user of application.

 After understanding user requirement, designer crates high level model that can be
understood by user and then it is converted into low level design.
Design Process
1. First phase is to interact with user and domain expert to understand the requirement
of the application.

2. Designer choses data model, applies the concepts of data model on requirement
translates the requirement into conceptual schema of the database.

The schema developed at this conceptual design phase provides detail overview of
the system.

entity-relationship model is used to represent conceptual design.

3. A fully developed conceptual schema also indicates the functional requirement of

enterprise. Functional requirement specifies kind of operations that will be performed
on the data.

4. Moving from data model to implementation of database is two phases design.

1. logical design phase.

2. physical design phase.
Design Process
 Logical design phase: designer converts high level conceptual model to data
model that will be used for implementation.
ER model of the enterprise will be converted into relational schema.

 Physical Design phase: physical features of the database are specified. These
features are form of file, index etc.
Design Process
 Database Design Process

Requirement
gathering E R Diagram

Relational Schema
Database Design
 While designing database schema, two issues must be avoided.

1. Redundancy: a bad design may repeat information. For example with each
student roll number, if name of student is also included in every relation.

2. Incompleteness: bad design may make certain aspect of enterprise difficult to

model.
for example: if students detail is directly stored with result then it would make
impossible to store students details until result is generated.
Entity Relationship Model
 E-R model is used to map requirement of organization onto conceptual schema.
 E-R model is basically having three concepts:
1. entity set
2. relationship set
3. attributes
Entity Relationship Model
Entity Sets:

An Entity is a thing or object in real world that is distinguishable from all other objects.
For example: each student in university is an entity.

Entity has a set of properties and values of some set of properties may uniquely identify
an entity.
Properties of entity is describe by attributes.

For example: students have id, name, address, phone number, DOB etc. id can be
used to identify student uniquely.

Entity set is set of entities of same type that shares the same properties or attributes.
For example: student is entity set.
Entity set Student

student-ID student_name
Relationship
 A relationship is association between two entities.
for example: teaches is relation that associates student with teacher.

44553 (Katz) Teaches 22222 (Shankar)

Teacher entity relationship student entity

 Relationship set is set of relations of same type.

Teacher
Relationship
 A relationship may also have attributes called descriptive attribute.
 For instance, the Teaches relationship set between entity sets teacher and student
may have the attribute date which tracks when the student started being
associated with the teacher.

Teacher
Degree of Relationship
 binary relationship
 Relationship that involve two entity sets is called binary relationship.
 Number of entity involved in relationship is called degree of relationship.
 Binary relationships are having degree 2.
 Most relationship sets in a database system are binary.

 Relationships between more than two entity sets are rare. Most relationships are
binary.
 Example: students work on research projects under the guidance of an instructor.
 relationship proj_guide is a ternary relationship between instructor, student, and project
 Attributes
 An entity is represented by a set of attributes, that is descriptive properties possessed by all
members of an entity set.
 Example:
Teacher = (ID, name, street, city, salary )
course = (course_id, title, credits)
 Domain – the set of permitted values for each attribute
 Types of attributes:
1. composite: attributes which can be divided into sub parts are called composite
attributes.
 Attributes
2. Simple: attributes which can not be divided into sub parts is called simple attribute.
for example: roll number, age, weight etc.

3. Single valued attribute: attributes for which only single value exist for every entity.

student id, age, date of birth, weight etc.

4. Multivalued attribute: attributes for which multiple values are possible for every entity.

address, phone number, email address etc.

5. Derived attribute: attributes whose value can be derived from another attribute.

age can be derived from date of birth, age is derived attribute.

Mapping Cardinalities
 Mapping cardinalities or cardinalities ratios express number of entities to which
another entities can be associated via relationship set.
 For binary relationship R between entities A and B, mapping cardinalities can be
one of the following.
 One to one:
one teacher teaches one subject.

Teacher Subject
Mapping Cardinalities
 One to Many:
for example: one teacher guides many subjects.

Teacher Students
Mapping Cardinalities
 Many to One:
for example: Many teachers belongs to one department

Teacher Department
Mapping Cardinalities
 Many to Many:
for example: one teacher is working in many projects.
in one project, many teachers are working.

Teacher Project
Exercise.
 A company database needs to store information about employees, departments,
and children of employees.

 Employees work in departments; a child must be identified uniquely by name when

the parent (who is an employee; assume that only one parent works for the
company) is known.

 Decide entity, attributes, relationship in these given requirement.

Solution dname
salary
phone dno
ssn budget

Employees Departments

Dependent
Works_In

Child

name age
Participation Constraints
 Participation of an entity set in relationship is called total if all the entities in set
participates in at least one relationship.
students belongs to department.

• Student entity set is having total participation as all of the students belongs to one of the
department.

• Department entity set is having

partial participation as all of the
departments may not have students.

Student Department
E R Diagram
Notations for E-R diagram:

entity - rectangle
attribute - ellipse connected to rectangle
multi-valued attribute – double ellipse
composite attribute - ellipse connected to ellipse
derived attribute - dashed ellipse
Primary key - underline
Relationship - diamond
E-R Diagram
 Customer Entity
E-R Diagram
E-R Diagram
 Relationship Set with Attributes
Another Notation for E-R Diagram
 Rectangles represent entity sets.
 Diamonds represent relationship sets.
 Attributes listed inside entity rectangle
 Underline indicates primary key attributes
Another Notation for E-R Diagram
 Relationship set with attributes
Keys
 A super key of an entity set is a set of one or more attributes whose values uniquely
determine each entity.
 A candidate key of an entity set is a minimal super key
 Customer_id is candidate key of customer
 account_number is candidate key of account
 Although several candidate keys may exist, one of the candidate keys is selected
to be the primary key.
Keys for Relationship Sets
 Let R be a relationship that involves entity set E1, E2…..En.

 Let primary key(Ei) denotes primary key of entity Ei.

 If there are no other attribute in R, then set of attributes

primary key(E1) U primary key(E2)…….. U primary key(En) describes individual
relationship in R.

 If relationship set R has its attributes a1,a2…..an then

primary key(E1) U primary key(E2)…….. U primary key(En) U {a1, a2……..an}
describes individual relationship.

 in both above case, primary key(E1) U primary key(E2)…….. U primary key(En)

will form super key for relationship set R.
Keys for Relationship Sets
 In both above case, primary key(E1) U primary key(E2)…….. U primary key(En) will
form super key for relationship set R.
• (customer_id, account_number) is the super key of depositor

• NOTE: this means a pair of entity sets can have at most one relationship in a
particular relationship set.
Example: if we wish to track all access_dates to each account by each
customer, we cannot assume a relationship for each access. We can use a
multivalued attribute though
Mapping Cardinality
 Cardinality constraints is expressed by drawing either a directed line (), signifying
“one”, or an undirected line (—), signifying “many”, between the relationship set
and the entity set.
 One-to-one relationship:
• A customer is associated with at most one loan via the relationship borrower
• A loan is associated with at most one customer via borrower

1 1
Mapping Cardinality
 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

1 M
Mapping Cardinality
 In a 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

M 1
Mapping Cardinality
 A customer is associated with several (possibly 0) loans via borrower
 A loan is associated with several (possibly 0) customers via borrower

M N
Notation for Cardinality Limits
 Cardinality limits is used to indicated number of times each entity from entity set
participates in relationship set.
 It is indicated by l..h, where ‘l’ is minimum and ‘h’ is maximum cardinality.
 Each student must have only one advisor.
 Each teacher can have zero or more student to mentor.

T_ID Name Salary S_ID Name Age

0..* 1..1
Teacher Advisor Student
Roles
 Entity sets that are associated via relationship need not be distinct means same
entity set can participate in relationship more than once.
 In works_for relationship, one entity is manager, second entity is worker, both
are of type employee.
 So one employee entity is connected with another employee entity via
different role.
 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
Weak Entity
 Entity set that does not have sufficient attribute to form a primary key is termed as
weak entity.

 Weak entity’s primary key can not be formed by its own attribute so it requires
another entity’s called identifying or owner entity’s attribute to create its primary
key.

 For a weak to be meaningful, it must be associated with another entity set called
identifying or owner entity.

 Existence of weak entity depends on identifying entity.

 Relationship that associates weak entity with identifying entity is called identifying
relationship.

 Entity set that has a primary key is termed as strong entity set.
Weak Entity
Weak Entity
 Participation of weak entity in relation is total, means every weak entity will have
one identifying entity.

 Identifying relationship will be one to many.

 Many weak entity will be associated with one identifying entity.

 Discriminator attribute is attribute of weak entity that allows distinction to be made

among weak entity.

 Weak entity set can participate in relationship other than identifying relationship.

 Weak entity set may depend on more than one identifying entity.
Weak Entity
Weak Entity
E R Diagram for Banking Enterprise
Exercise

 Create ER DIAGRAM for library management system.

 This system keeps details about books, publishers, members, books borrowed, book
published by publisher.

 Create E R diagram for EXAM Management System which keeps details about
different exams, students, results and paper setters.
Reduction of E-R to Relational Schema
 We can not store data in ER Diagram, we have to translate ER diagram in relational
schema.
 While converting ER diagram into relational schema each and every entity and
relationship are mapped onto relations.

 For each entity set and relationship set there is a unique schema that is assigned
the name of the corresponding entity set or relationship set.

 Each schema has a number of columns (generally corresponding to attributes),

which have unique names.
Reduction of E-R to Relational Schema
Representing Entity Sets as Relational Schemas
 Strong entity is converted to schema using same name and all simple and single
valued attributes of entity becomes attributes of relation.

 In case of composite attribute, each of the component will be added as one

attribute in relation but main attribute will not be added.

 Primary Key of the relation will be same as primary key of entity.

 For multivalued attribute, a separate relation will be formed that will have primary
key of original entity and multivalued attribute as member.

 Derived attribute will not be created in relation as attribute rather it will created as
function on relation, which will calculate value of derived attribute.
Representing Entity Sets as Schemas

customer( customer_id, first_name,middle_name,last_name,apartment_number,

street_number, street_name, city, state, zip_code, date_of_birth)
Customer_contact( customer_id, phone_number)
Representing Weak set as Relation
 Let A be a weak entity with attribute {a1,a2….an} and B is a strong entity on which A
is dependent.

 Let primary key of B is consist of {b1, b2….bn} then relation for entity will consist of
attributes of A and primary key of B

 Relation of A= {a1,a2….an} U {b1, b2….bn}.

 Here primary key is= (primary key of B) U {discriminator attribute of A}

 Weak entity relation will also have foreign key.

Representing Weak set as Relation

 Installment( Loan_no, Ins_no, pay_date, amount)

Representing Relationship set as Relation
 Let R be a relationship set, {a1, a2, ….an} is set of attributes formed by primary key
of entities participating in relation and let {b1, b2 ……bn} is set of descriptive
attributes.
 For relationship R, relation will include following attributes.
• (primary key of participating entity) U (descriptive attribute of relationship)
• = {a1, a2, ….an} U {b1, b2 ……bn}

Depositor=(customer_id, account_number, access_date)

Representing Relationship set as Relation
 Formation of primary key depends on cardinality of relation.

Borrower=(customer_id, Loan_number, Borrow_date)

One to One
 One to one: one customer can borrow one loan only.

Customer_id Loan_number Borrow_date

012 A111 21/04/2015
099 A109 23/03/2015
101 B125 29/06/2015
456 C784 11/01/2015
983 B156 24/03/2015
Borrower Table
 Here every customer_id will come only once as one customer can borrow only one loan.
 Similarly, every loan_number will also come only once as one loan can be borrow by
one person only.
 As a result every customer_id and every loan_number will be unique, so any one of the
attribute can be chosen as primary key.
 so, primary key will be either customer_id or loan_number.
 One to Many
 One to Many: one customer can borrow multiple loan but one loan can be borrowed by
one customer only.

Customer_id Loan_number Borrow_date

012 A111 21/04/2015
012 A109 23/03/2015
101 B125 29/06/2015
101 C784 11/01/2015
983 B156 24/03/2015
Borrower Table
 Here customer_id will come many times as one customer can borrow multiple loan. only
once as one customer can borrow only one.
 But every loan_number will comes only once as one loan can be borrow by one person
only.
 As a result, primary key of relationship will be primary key of entity that on many side.
 Here loan entity set is on many side so its primary key will be primary key of relationship.
 Same rule is applicable for many to one relationship.
 Many to Many
 Many to Many: one customer can borrow multiple loan and one loan can be borrowed
by multiple customer.
Customer_id Loan_number Borrow_date
012 A111 21/04/2015
012 A109 23/03/2015
101 A111 29/06/2015
101 C784 11/01/2015
983 C784 24/03/2015
Borrower Table
 Here customer_id will come many times as one customer can borrow multiple loan. only
once as one customer can borrow only one.
 loan_number will also come many times as one loan can be borrow by multiple
customer.
 But the combination of cutomer_id and loan_number will be unique.
 As a result, primary key of relationship will be union of primary keys from participating
entity sets.
 Here primary key will be (Customer_id, Loan_number).
Foreign key
 For every entity set associated via relation, there will be one foreign key from
relation R.
 This foreign key will refer primary key of every participating entity.

Customer_id Loan_number Borrow_date

012 A111 21/04/2015
012 A109 23/03/2015
101 A111 29/06/2015
101 C784 11/01/2015
983 C784 24/03/2015
Borrower Table
 In above case, customer_id and loan_number will become foreign key which will
be referenced from Customer and Loan entity respectively.
Redundancy of Schema
 A relationship that links weak entity to its strong entity is treated specially while
converting into relation.

 Such identifying relationship have no descriptive attribute.

 Relation for weak entity includes primary key of strong entity.

 And a relation for identifying relationship includes primary key of strong entity and
discriminator key of weak entity.
Redundancy of Schema

 Installment( Loan_no, Ins_no, pay_date, amount)

 Loan_inst (Loan_no, Ins_no)
 Here, every combination of (Loan_no, Ins_no) will also present in installment thus
lona_inst relation is redundant.
 In general, relation schema for relationship that links weak entity to its strong entity is
redundant and does not need to present in relation database design.
Combination of Schema
 Relation schema of relationship cab be combined with the relation schema of
one of the participating entity.

 In this way, number of the relations will be reduced.

 Consider in one to many relationship set AB that associated entity set A and
entity set B.

 As a general rule, we will have three relations corresponding to entity A, entity B,

and relationship AB.

 Suppose the participation of entity set B is total, means every entity ‘bi’ in entity
set must be participating in relationship.
 Combination of Schema
 There is one relationship institute_dept between institute entity set and department entity
set.
 Here mapping is one to many cardinality, one institute have many department but one
department is related with one institute only.
 Participation constraints of department is total. Means every department must be
related to one institute.
 Tables of the above relations are as given below.

Inst_no Name Dept_id name

Institute Department
1 CSPIT 101 CE
2 PDPIS 102 IT
3 II2IM 201 Physics

As every department entity will present Dept_no Inst_no So instead of creating separate
in relationship. 101 1 schema for relationship, inst_no
The relation schema of relationship can be included in department
includes every department entity. 102 1 relation.
201 2
Inst_Dept
Combination of Schema
 So the final relations after merging of relationship relation into entity will be as given
below.

Inst_no Name Dept_id Inst_no Name

1 CSPIT 1 101 CE
2 PDPIS 1 102 IT
3 II2IM 2 201 Physics
Institute Department
 Primary key of combined relation schema will be primary key entity set in whose relation
schema relationship’s relation schema is combined.
 In case of one to one relationship and total participation of both entity set, relation
schema of the relationship can be combined with any of the entity set’s relation
schema.
 For example: relationship teaches between faculty and subject.
every faculty teaches only one subject.
every subject is taught by one faculty only.
 In this case, either faculty relation can include subject_code or subject relation can
include faculty_id to show the relationship.
Combination of Schema
 Relations can also be combined even if participation is partial.

 In case of institute_dept, if department entity set have partial participation, means

some of the department does not belongs to any of the institute then for that
department null value of inst_id will be stored.

Dept_id Inst_no Name

1 101 CE
1 102 IT
2 Mathematics

Department
 There would be foreign key referencing each of participating entities from its base
relation.
E-R Design Issues
Use of Entity sets versus attributes

Case 1 case 2
 In case 1, phone number is one attribute and in case 2, phone number is an entity
that stores more information about every phone number.
 In case 2, every phone is modeled as one real one entity and one instructor can be
associated as multiple phone.
 Here the issue is what constitutes an attributes and what constitutes an entity set.
 The answer is not simple, it depends on requirement of organization.
E-R Design Issues
Use of entity sets vs. relationship sets
 It is not clear in every case whether object is best expressed by an entity set
or relationship set.
 Loan is modeled as entity but it can also be modeled as relationship
between customer and branch.
E-R Design Issues
Use of entity sets vs. relationship sets

 If every loan is taken by only one customer and one branch then loan as a
relationship will work fine.
 In case where one loan can be taken by many customer, there will be many row
with different customer_no and same branch_no, loan_number and amont.
 So there will be replication of data.
 Possible guideline is to decide whether to use entity set or relationship set is to
designate a relationship set to describe an action that occurs between entities
E-R Design Issues
Binary versus n-ary relationship sets
 Although it is possible to replace any nonbinary (n-ary, for n > 2) relationship set by
a number of distinct binary relationship sets.
 A n-ary relationship set shows more clearly that several entities participate in a
single relationship.
 It is possible to replace non binary relationship set by binary relationship sets.
 For example, for ternary relationship R, relating entity A,B and C.
replace relationship set R by an entity set E, and create relationship as follows.
• RA relating E to A
• RB relating E to B
• RC relating E to C
E-R Design Issues
Binary versus n-ary relationship sets

Quantity ProjName
SName

SUPPLIER SUPPLY PROJECT

PART PartNo
E-R Design Issues
Binary versus n-ary relationship sets

Quantity ProjName
SName

1 N N 1
SUPPLIER SS SUPPLY SPJ PROJECT
N

SP
1

PART PartNo
E-R Design Issues
Placement of Relationship Attributes:
 Cardinality of relationship affects placement of relationship attributes.
 Attributes of one to one OR one to many relationship set can be associated with
one of the participating entity rather than with relationship set.
 The decision of where to place attributes should reflect characteristics of enterprise
being modeled.
 For example, in relationship advisor, faculty and students are involved.
 Relationship advisor have one descriptive attribute date, which gives date, on
which faculty became advisor of student.
 If the cardinality is one to one then relationship’s relation schema can be
combined with either of the entity.
 If the cardinality is one to many, one faculty- many student.
one student one faculty.
 In this case, date can be placed in student entity.
 In this case, date may indicate date when student join university rather date on
which faculty is assigned to student as advisor.
E-R Design Issues
Placement of Relationship Attributes:
 In case of many to many, choice is very clear for descriptive attribute.
 If one faculty advises  many students and
one student have  many advisor.
 Then date attribute must be attribute of advisor relationship set, because one
student have many advisor means many dates on which faculty is assign as advisor,
similarly one faculty have many student means many dates on which students
joined.
 Date attribute must be placed in relationship along with combination of student_id
and faculty_id.
Extended ER Features
Specialization: Entity set may have subgroup among entities that are distinct in some
way from other entities of same set.
 Subgroup of entity may have some attributes which are not shared by all the
entities of entity set.
 For example: an entity set Person in organization can be further classified as
Employee and Customer.
 Person entity have attribute like ID, Name Address.
 While employee entity have extra attribute Salary along with all the attributes of
person.
 Customer entity have credit_rating attribute apart from attribute of person.
 The process of designating subgroup within an entity set is called specialization.
 Specialization can be applied repeatedly.
 For example: employee can be further classified as Officer, Teller and secretary.
Specialization & Generalization
Specialization
 Specialization can be done by more than one distinguishing feature.

 For example: Employees can be also classified as permanent and temporary.

 In such case, an entity can belong multiple specialization, employee may be permanent
employee who is officer.

 Specialization is depicted by triangle. This relationship is called ISA, which stand for “is a”. It
represents like ‘officer is a employee’.

 If entity can belong to multiple specialization, it is called overlapping specialization.

 If entity can belong to at most only one specialization, it is called disjoint specialization.

 Specialization is top down design process.

 Specialization relationship may also referred as superclass- subclass relationship.

Generalization
 It is Bottom Up process that combines entity set that share some common attribute.
 For example: database designer first identifies employee with attributes emp_id,
name, address, salary and customer entity set with attributes cust_id, name,
address, ratings.
 As there are similarities between employee and customer, this similarity can be
expressed by Generalization.
 Here higher level entity set person is synthesized from lower level entity set,
employee and customer.
 Higher level entity is also called super class and lower level entity is called sub
class.
 generalization is inverse of specialization.
 Generalization is used to emphasize similarity among entity sets.
Attribute Inheritance
 Attributes of higher level entity set is inherited by lower level entity sets.
 For example: attributes of person entity set is inherited by employee and customer.
 Thus employee entity set will have id, name, street, city attribute along with salary,
similarly for customer entity set, attributes will be id, name, street, city and rating.
 Officer which is subclass of employee inherits id, name, street, city from person and
salary from employee.
 Like attributes, lower level entity also inherits relationship in which higher level entity
participates.
 For example: person entity have relationship with phone entity set, all the lower level
entity of person will also have same relationship with phone entity set.
 Single Inheritance: if the lower level entity is involved in only one ISA relationship
then it is called single inheritance.
 Multiple Inheritance: if the lower level entity is involved in more than one ISA
relationship then it is called multiple inheritance.
Attribute Inheritance
Constraints on Specialization/Generalization
 Constraint on which entities can be members of a given lower-level entity set.

 condition-defined: in condition defined lower level entity set, membership is

evaluated on basis of whether or not entity satisfies a condition or not.

 Example: all customers over age of 65 years are members of senior-citizen

entity set; here condition is based on age attribute of person entity set.

 user-defined: here membership is decided on base of some condition, rather

database user assigns entity to given lower level entity set.

This assignment is implemented by operation that add entity to given entity set.
Constraints on Specialization/Generalization
 Constraint on whether or not entities may belong to more than one lower-level entity
set within a single generalization.
 Disjoint
 an entity can belong to only one lower-level entity set
 Noted in E-R diagram by writing disjoint next to the ISA triangle
 Overlapping
 an entity can belong to more than one lower-level entity set

 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 a
generalization.

 total : an entity must belong to one of the lower-level entity sets

 partial: an entity need not belong to one of the lower-level entity sets
Aggregation
 Consider the ternary relationship works_on, between employee, job and branch.
 Suppose we want to record managers to monitor job performed by an employee at a
branch.
Aggregation
 Relationship sets works_on and manages represent overlapping information.
 Works_on relationship keep record of employee_id, job_id and branch_id, while
manages also keep record of employee_id, job_id, branch_id and manager_id.
 Here there is redundancy of information.
 We can not eliminate relationship works_on because it will keep information of all
the employee’s job irrespective of whether they have manager or not.
 it is possible that some employee do not have manager, so such employees job
detail will not be entered in manages.
 So if the works_on is removed, then details of those employee who does not have
manager can not be inserted into manages table.

 This redundancy can be eliminated via aggregation.

 Treat relationship as an abstract entity
 Allows relationships between relationships
 Aggregation is an abstraction through which relationship are treated as higher level entities.
Aggregation
 Without introducing redundancy, the following diagram represents:
 An employee works on a particular job at a particular branch
 An employee, branch, job combination may have an associated manager

Ternary Relationship
that will be treated
as entity set.

Binary
Relationship
between entity
works_on and
manager
Reduction to Relation Schema
There are two methods for designing relation schema for ER diagram that includes
generalization and specialization.

Method 1:
 Form a schema for the higher-level entity
 Form a schema for each lower-level entity set, include primary key of higher-level entity
set and local attributes.
 Primary key of higher level entity set will become primary key of lower level entity set.
 Foreign is created from lower level entity set to higher level entity set.
person(ID, name, street, city)
employee (ID, salary)
customer (ID, credit rating)
Reduction to Relation Schema
Method 2:
 If the generalization is disjoint and complete, means higher level entity belongs to
only one lower level entity set, and every higher level entity belongs to one lower
level entity set then relation schema for higher level entity can be removed.

employee (ID, name, street, city, salary)

customer (ID, name, street, city, credit rating)

 One drawback over here is foreign key, here we do not have table from where
data of the person can be verified.
Aggregation
 To represent aggregation, create a schema containing
 primary key of the aggregated relationship that is used as entity set,
 the primary key of the associated entity set
 any descriptive attributes
 For example, to represent aggregation manages between relationship works_on
and entity set manager, create a schema

manages (employee_id, branch_name, title, manager_id)

Primary key of works_for Primary key of Manager