Assume there is an entity type called person , and entity subtypes called customer and employee . When a person is created, the designer of the database has two options:
He/she can demand that the person be classified as one of the subtypes.
He/she can allow a person to be created without classifying the person as any subtype.
OPTİONAL VERSUS MANDATORY Neither one is preferable to the other. The proper one to choose depends on the business situation. Mandatory sub-typing is represented by creating a double line from the super-type ( person in the following ER diagram) to the circle. Optional sub-typing is represented by leaving a single line from the super-type to the circle.
AGGREGATİON OF ENTİTY TYPES
Subtypes are generally thought of in terms of X is a Y (which is why these are commonly referred to as is-a relationships). Another type of relationship that needs to be represented in a database is the part of relationship, more formally called aggregation . When an entity is made up of several different types of other entities, an aggregation relationship may be called for.
AGGREGATİON OF ENTİTY TYPES Consider the relationship between a car and its engine and body. The engine and body are both part of the car. The relationship is represented as follows in an ER diagram.
Two entities can have more than one type of relationship. This is not surprising; further, it is not difficult to represent in a database or in an ER diagram. Consider the entity types person and insurance policy and the relationships between them of pays for and is insured under.
PARALLEL RELATİONSHİPS A person pays for zero or more insurance policies. An insurance policy is paid for by exactly one person. A person is insured by zero or more insurance policies. An insurance policy insures one or more persons.
The existence of an entity depends on the existence of another entity
Customer Loan loan borrow CusNo LoanNo A loan cannot exist if there is no borrower.
A weak entity cannot be identified with its own attributes no key
A weak entity implies existence dependency but NOT vice versa
LoanNo Amount Date_pay PaymentNo Payment
A loan may have 240 payments, each identified by a payment no 1 - 240.
The PaymentNo is unique given a particular loan but not unique globally
PaymentNo is called partial key
The primary key of Payment is the combination of LoanNo and PaymentNo .
Loan payment Question: Why not combine loan and payment into one entity type? Amount Loan
WEAK ENTİTY VS EXİSTENCE CONSTRAİNTS
In the existence constraint example, LoanNo can uniquely identify a Loan in the database so it is not a weak entity.
The existence constraint means that you cannot create a Loan record without first knowing who borrowed the loan.
ANOTHER EXAMPLE OF WEAK ENTİTY TYPE
A child may not be old enough to have a HKID number
Even if he/she has a HKID number, the company may not be interested in keeping it in the database.
EmpNo Name Dependent Emp_Dep Age Employee
TERNARY RELATİONSHİPS Customer Loan Borrow Branch A customer borrows a loan from a branch. Customer Loan Borrow Branch Issue A customer borrows a loan. A loan is issued from a branch.
WHAT ARE THE DİFFERENCES? A customer borrows a loan from a branch. A customer borrows a loan. A loan is issued from a branch.
Imagine a bank allows borrowers of the same loan to go to difference branches for signing documents, deposit payments, etc.
The two schemes are not the same. The binary relationships capture less information.
Adding a third relationship won’t help .
Customer Loan Borrow Branch Issue Cus_Br
Customer, Loan and Branch have a N:M:P relationship
N:N:1 relationship can be decomposed (A loan is issued by ONE BRANCH ONLY)
John borrows a loan which is issued from Wanchai branch
A12345 B56789 A12345 A12345 L-001
BİNARY RELATİONSHİPS TO TERNARY?
Binary relationships may have different meanings so that they can’t be combined into ternary relationships .
You may have a ternary relationship Customer-Loan-Branch and other binary relationships between Customer, Loan and Branch
Customer Loan Borrow Branch Issue Buy_stock
A CASE STUDY A primary school student writes a composition about a picnic: Today is Sep 9, the weather is fine. My classmates, John, Mary and I go to a picnic in Sai Kung. Our teacher is Ms Wong Initial Design: Picnic weather destination date Students Name Teacher Name
Why “John”, “Mary”, “Miss Wong” are not in the ER diagram ?
What do these names tell us ?
What are the keys of Student, Picnic & Teacher ?
What are the cardinalities of the relationships ?
Every student has an ID number, it is better to keep it in the database and use it as a key
I bet that there won’t be teachers with the same name; otherwise, I’ll add employee number and use it as a key
goes is N:M, why ? A picnic has more than one student participating; also, a student can go to more than 1 picnic. However, this N:M relationship allows a student to go to more than one picnic on the same date
leading is N:1 , why? Depends on your assumptions
I assume a teacher can only lead 1 picnic on a certain date, so given the teacher name and the date, I can identify a picnic
Picnic is made a weak entity. I could have added a PicnicNo, but it would be very awkward.
My solution Question: How to record number of students in a picnic? Student StudentNo Name weather date destination Picnic goes leading Teacher Name
E-R DESİGN DECİSİONS
The use of an attribute or entity set to represent an object.
Should an address be an attribute or entity?
Whether a real-world concept is best expressed by an entity set or a relation set.
Should marriage be an entity or relationship?
Should picnic be an entity or relationship?
The use of a ternary relationship versus a pair of binary relationships.
See the borrow-loan-branch example
The use of a strong or weak entity set.
See the employee-dependent example
E-R DİAGRAM FOR COMPANY DATABASE EMPLOYEE WORKS_FOR MANAGES CONTROLS Startdate DEPARTMENT WORKS_ON PROJECT Hours DEPENDENTS_OF DEPENDENT SUPERVISION supervisee supervisor Fname Minit Lname Name Sex Address Salary Ssn Bdate Number Of Employees Locations Can you translate it back into English? Name Number Name Number Location Relationship Birthdate Sex Name
LİMİTATİONS OF ER MODEL
Consider representing Part-time and Full-time employees in the company database:
Either you have two entity types will lots of similarity
Or you have a single entity type with redundancy for most of the entities within it
ER model is extended to support other features such as generalization
REDUCTİON 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. Always!
Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram.
REPRESENTİNG ENTİTY SETS AS TABLES
A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set
A strong/regular entity set reduces to a table with the same attributes.
Composite key payment loan-no payment-date payment-no payment-amount L-17 L-15 L-23 5 22 11 10 May 1999 23 May 1999 17 May 1999 50 300 75 customer customer-name customer-street customer-id Jones Hayes Smith 321-12-3123 677-89-9011 019-28-3746 Main Main North customer-city Harrison Rye Harrison
REPRESENTİNG RELATİONSHİP SETS AS TABLES depositor
A many-to-many relationship set is represented as table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set.
customer borrow loan loan-no cust-no share% date cust-name
For 1:N and 1:1 relationships, you can create a table for each relationship
But it is more concise to merge the relationship-table with the entity-table on the “N” side
customer cust-no cust-name A12345 B56789 Peter Wong Mary Cheung loan loan-no L-001 L-002 date Sep 2000 Aug 2001 customer borrow loan cust-no cust-name date loan-no cust-no A12345 B56789 indicates who borrowed the loan
Since a weak entity has to include the primary key of the identifying entity, the 1:N relationship is already captured. E.g., The payment table already contains information about the Loan (I.e., loan_no)
Already indicates the 1:N relationship between loan-no and payment-no payment loan-no payment-date payment-no payment-amount L-17 L-17 L-17 5 7 6 10 May 1999 23 May 1999 17 May 1999 50 300 75