Chapter 2: Entity-Relationship Model. Entity Sets Relationship Sets Mapping Constraints Keys Participation Constraints E-R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to Tables Objective: conceptual DB design using ER diagrams. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Chapter 2: Entity-Relationship ModelChapter 2: Entity-Relationship Model
Entity Sets Relationship Sets Mapping Constraints Keys Participation Constraints E-R Diagram Extended E-R Features Design of an E-R Database Schema Reduction of an E-R Schema to Tables
A super key of an entity set A set of one or more attributes whose values uniquely
determine each entity E.g. customer id & customer name
A candidate key 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. The DB designer has chosen to identify entities Can customer id be the primary key in customer entity? Can customer name be the primary key?
Keys for Relationship SetsKeys for Relationship Sets
The combination of primary keys of the participating entity sets forms a super key of a relationship set. (customer-id, account-number) is the super key of depositor
Primary-key(E1) U primary-key(E2) … U primary-key(En) A pair of entity sets can have at most one relationship in a particular
relationship set. E.g. 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.
Primary-key(E1) U … primary-key(En) U {A1, A2, …, An} when the relationship set has attributes A1, A2, … An
Given a relationship set borrower, defined between customer and loan, do you expect every loan entity to be related to at least one customer? Total participation of loan in the relationship set borrower
Is each customer related to a loan entity through the borrower relationship? Partial participation
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 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
Converting Non-Binary Relationships to Converting Non-Binary Relationships to Binary FormBinary Form
In general, any non-binary relationship can be represented using binary relationships by creating an artificial entity set. Replace R between entity sets A, B and C by an entity set E, and three relationship
sets:
1. RA, relating E and A 2.RB, relating E and B
3. RC, relating E and C Create a special identifying attribute for E Add any attributes of R to E For each relationship (ai , bi , ci) in R, create
1. a new entity ei in the entity set E 2. add (ei , ai ) to RA
Weak Entity Sets (Cont.)Weak Entity Sets (Cont.) Double rectangles Underline the discriminator with a dashed line. payment-number – discriminator of the payment entity set Primary key for payment – (loan-number, payment-number)
Design Constraints on a Specialization Design Constraints on a Specialization (Contd.)(Contd.)
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 Double line
Partial An entity need not belong to one of the lower-level entity sets Default
Used when we have to model a relationship involving (entitity sets and) a relationship set. Aggregation allows us to treat a relationship set as an entity set for purposes of
Several kinds of integrity constraints can be expressed in the ER model: key constraints, participation constraints, and disjoint/overlapping constraints for ISA hierarchies.
Some constraints (notably, functional dependencies) cannot be expressed in the ER model. Constraints play an important role in determining the best
ER design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include:
Entity vs. attribute, entity vs. relationship, binary or n-ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation.
Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful.