Embed Size (px)
DESCRIPTION
CS 2: Chapter 3
Citation preview
Chapter 3:CONCEPTUAL
DESIGN-ER-MODEL
(Entity-Relational)
The Entity Relationship Model
Perspective
Organisation Information System
RelationalModel
Physicaldatastorage
ERM
Conceptual Model Logical Model Physical Model
Steps in Database Design
Requirements Analysis user needs; what must database do?
Conceptual (Database) Design high level (or semantic) description. often done with the ER model
Logical (Database) Design translate ER into DBMS data model (e.g., Relational Model)
Schema Refinement consistency, normalization
Physical (Database) Design - indexes, disk layout Security Design - who accesses what, and how
Identify the entities, its attributes and the relationships between entities. Identify entities
For the list of activities, identify the subject areas you need to maintain information about. These will become tables. An entity may be an object with a physical existence - a particular person, car, house, or employee – or it may be an object with a conceptual existence - a company, a job, or a university course.
For example, to develop a company's database for maintaining information on employees, the application should be able to store and provide data on employee such as when was the employee was hired; is the employee still with the company; if the employee has left the company when did he leave the company; which department does employee work for; who is his/her manager; what is his/her skill level etc.
In this example, the entities are company, department, employee, manager.
An Attribute is a property that describes an entity.
In the above example,Entity : employee Attribute: employee’s name, age, address, salary and job etc
So the concepts we want you to learn today are:
The basics of Entity-Relationship modelling
Entities
Relationships
Attributes
6
Entities
Entity - distinguishable “thing” in the real world – Strong entity - entities have an independent
existence
– Weak entity - existence dependent on some other entity
E n tityNa m e
space for attributes
Entity
Notation for attributes
Primary Keymarked {PK}
Multi-Valued Attribute(number of values in [ ] brackets)
Derived Attribute
Composite attribute
Partial Key- part of composite PK- or of a weak entity
{PPK}
EntityName
ke yAttribute {PK}
composite Attribute
partOne
partTwo
/ de riv e dAttribute
multiValue d [min..max]
Relationships
A relationship is “.. An association among entities (the participants)..”
Relationships link entities with each other
Concept of Entity and Relationship:
The entity set which does not have sufficient attributes to form a primary key is called as Weak entity set.
A member of a strong entity set is called dominant entity and member of weak entity set is called as subordinate entity.
The primary key of a weak entity set is formed by the primary key of the strong entity set .
The relationship between weak entity and strong entity set is called as Identifying Relationship.
For example, payment_number acts as discriminator for payment entity set. It is also called as the Partial key of the entity set.
In the above example {loan_number, payment_number} acts as primary key for payment entity set.
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 sets discriminator.
Here double lines indicate total participation of weak entity in strong entity set it means that every payment must be related via loan-payment to some account.
The discriminator of a weak entity set is underlined with dashed lines rather than solid line.
Weak Entities
• A weak entity can be identified uniquely only by considering the primary key of another (owner) entity.
– Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities).
– Weak entity sets must have total participation in this identifying relationship set.
– Trans_no is a discriminator within a group of transactions in an ATM.
since
address
amountTrans_no
TransactionsATM
atmID
type
15
Attributes
Entity types have Attributes (or properties) which associate each entity with a value from a domain of values for that attribute
Attributes can be– simple (atomic) e.g. license_no– composite e.g. address (street, town, postcode)– multi-valued e.g. phone number– derived e.g. D.O.B. ; age– Null– Single valued e.g. name
Relationship types can also have attributes!
Types of attributes:
Simple attribute:Simple attributes are atomic values, which cannot be divided further.
Composite attribute:Composite attributes are made of more than one simple attribute. For example, a student's complete name may have first_name and last__name.
Derived attribute:Derived attributes are attributes, which do not exist physical in the database, but there values are derived from other attributes presented in the database. For example,age can be derived from data_of_birth.
Single-valued attribute:Single valued attributes contain on single value. For example: Social_Security_Number.
Multi-value attribute:Multi-value attribute may contain more than one values. For example, a person can have more than one phone numbers, email_addresses etc.
Keys
Key is an attribute or collection of attributes that uniquely identifies an entity among entity set.
For example, roll_number of a student makes her/him identifiable among students.
Degree of relationship
The number of participating entities in an relationship defines the degree of the relationship.
Unary=degree 1Binary = degree 2
Ternary = degree 3n-ary = degree n
19
Relationships: constraints
The degree of a relationship type– binary (connects 2 entity types)– unary/ recursive (connects 1 entity type with itself)– Ternary (connects 3)– complex (connects 3 or more entity types)
Relationship constraints - cardinality – one to one (1:1)– one to many (1:m)– many to many (m:n)
Relationship constraints – participation– full/mandatory– or partial/optional
Degree
Entity1 Entity3
Entity2
Te rnaryRe lationship
Relationships: Degree
Entity1 Entity2HasLinkWith
Entity1Staff
Supe rv ise sSu p e rv iso r
Su p e rv ise e
Binary relationship
Complex relationship –here ternary
Recursive (Unary) relationship - example
21
Relationships example
Manager DepartmentManages
responsibility]
dateAllocated
Each department is managed by ONE manager
Each manager manages departments Relationshi
p attributes
Unary Example with Data
Staff
supervisesA member of staff may supervise another staff
member, but a staff member may be
supervised by one or more staff members
STAFFMember Age SupervisorA 43 CB 27 BC 35 DD 33 A
In a one-one relationship an entity of either entity set can be connected to at most one entity of the other set.
24
Ternary Diagram
registers
Try to determine participation/cardinality by operating in pairs
“a client at a branch will be registered by one
member of staff”
“a member of staff will register a client at one
branch”
“a member of staff at a branch may register many
clients”
Staff Branch
Client
the Works_In Relationship Set
lot
name
Employees
ssn
Works_In
sincedname
budgetdid
Departments
A Ternary Relationship Set:Works_In2
Key Constraints(ternary relationships)
dname
budgetdid
name
lot
name
ssn
works_InEmployees Departments
Location
12-233
12-243
12-354
12-299 Rome
Paris
London
D10
D13
D12• • • •
Each employee can work atmost in one department ata single location
ER Model…..
Relationship: Association among two or more entities. E.g., Peter works in Pharmacy
department. Relationship sets can also have descriptive attributes (e.g., the since
attribute of Works_In).
subor-dinate
super-visor
Reports_To
since
Works_In
dname
budgetdid
Departments
lot
name
Employees
ssn
Participation Constraints The participation of the
entity set Departments in the relationship set Manages is said to be total if we assume every department have a manager. Connect Departments and
Manages by a thick line.
The participation of the entity set Employees in Manages is partial.
Participation Constraints• Does every department have a manager?
– If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial).
• Every Department MUST have at least an employee• Every employee MUST work at least in one department
lot
name dnamebudgetdid
sincename dname
budgetdid
since
Manages
since
DepartmentsEmployees
ssn
Works_In
Mapping Cardinalities:Cardinality defines the number of entities in one entity set which can be associated to the number of entities of other set via relationship set.
One-to-one: one entity from entity set A can be associated with at most one entity of entity set B and vice versa.
One-to-one relation]
Many-to-one:
More than one entities from entity set A can be associated with at most one entity of entity set B but one entity from entity set B can be associated with more than one entity from entity set A.
Many-to-one relation]
Many-to-many:
one entity from A can be associated with more than one entity from B and vice versa.
Many-to-many relation]
•One-to-many:
One entity from entity set A can be associated with more than one entities of entity set B but from entity set B one entity can be associated with at most one entity.
One-to-many relation]
CASE STUDY:
“Yatra company” has branches situated all over Maharashtra.• Each branch is treated as an independent travelling agency• Each such agency arranges tours.• For each tour they have schedule of buses.• Each bus is allocated a team of workers:
Driver, cleaner, conductor, helper.
• Passenger book the tour by booking a specific schedule and bus.• The agency has many employee working as:
Clearks,agents,stenos.
• Each of the tour have many Schedules based on time of departure and similarly Many buses for one tour but each schedule can
have one bus only.
Entity Primary KeyBranch Br_no
Tours T_no
Buses Bus_no
Employees Emp_id
Pasengers P_no
Scheduledby T_no,Bus_no
Allocated Emp_id,Bus_no
Bookedby P_no,Bus_no
Physical entity
relationship
Branch
Relational Model with all entity:• Tours (tno, title, no_of_days, capacity ,departure,date)• Branch(________________)• Buses(_________________)• passenger(________________)• Employee(__________________________)
Relationship(AS per E-R-D)
• One branch of YATRA COMPANY forms many tours• Many tours scheduled as many buses.• Many passenger booked many buses.• Many buses allocates many employees.
ISA Hierarchies
Contract_Emps
namessn
Employees
lot
hourly_wages
Hourly_Emps
contractid
hours_worked
If we declare A ISA B, every A entity is also considered to be a B entity.
» Reasons for using ISA: To add descriptive attributes specific to a subclass.To identify entities that participate in a relationship.
ISA
Aggregation
– Aggregation allows us to treat a relationship set as an entity set for purposes of participation in (other) relationships.
– Employees are assigned to monitor SPONSORSHIPS.
budgetdidpid
started_on
pbudgetdname
until
DepartmentsProjects Sponsors
Employees
Monitors
lotname
ssn
since
Aggregation vs. ternary relationship: Monitors and Sponsors are distinct relationships, with descriptive attributes of their own.
Also, can say that each sponsorship is monitored by at most one employee (which we cannot do with a ternary relationship).
Design choices:
• Should a concept be modeled as an entity or an attribute?
• Should a concept be modeled as an entity or a relationship?
• Identifying relationships: Binary or ternary? Aggregation?
CASE STUDY:
• Design Database for banking enterprise, with record information about CUSTOMER ,EMPLOYEES of the bank.
• A customer can be a DEPOSITOR OR BORROWER,• A EMPLOYEE of the bank can be CUSTOMER of the bank.• There are two types of account SAVING or CURRENT account.• Questions:(***Hint: Use unary relationship, specialization, generalization)
• Identify all entities.• Identify all attributes.• Identify all relations.• Draw E-R-Diagram.• Relational data model.
Customer_no
Account_no Customer_no
Primary key
Foreign keyPrimary key
