The Next Step: Designing DB Schema. Chapter 6: Entity-Relationship Model. The E-R Model. Identifying Entities and their Attributes.

Size: px

Start display at page:

Download "The Next Step: Designing DB Schema. Chapter 6: Entity-Relationship Model. The E-R Model. Identifying Entities and their Attributes."

Randall Logan
5 years ago
Views:

1 Chapter 6: Entity-Relationship Model Our Story So Far: Relational Tables Databases are structured collections of organized data The Relational model is the most common data organization model The Relational model uses relations sets of tuples which act like tables Relational algebra offers a mathematically rigorous approach to relational data operations SQL, modeled on relational algebra but with its own syntax, offers a high-level approach to defining, querying, and modifying a database. What s next? The Next Step: Designing DB Schema Issues How do I go about understanding my enterprise? How to I parcel up all the possible data into tables? What should the attributes be? What s the primary key? How should the tables be related to one another? Are some designs better than others? How do I notate and communicate my design? What types of data constraints are possible? How do I notate and then implement constraints? Technique: Entity-Relationship Modeling 1 2 The E-R Model Identifying Entities and their Attributes A database can be modeled as: a collection of entities, and relationships among entities. An entity is an identifiable object Ex: a person, company, event, plant We expect to have collections of similar entities (Ex: several people) A relationship is an association between one entity and another Ex: a person works for a company. Attributes are characteristic properties of a thing Ex: people have names and addresses Entities always possess attributes; relationships sometimes do. So, a database table is analogous to which of these? Identify all the nameable things/objects Each thing will either be An Entity (noun) An Attribute (noun or adjective class) A Relationship (noun or verb) Entities Have a individual existence and are distinguishable from one another A table is a set of entities. Attributes Are a property or descriptor of an entity Have a domain of possible values Fits the form, An entity X has this attribute Y. Sometimes, attributes also are or could be entities (foreign key) 3 4 Varieties of Attributes Weak Entity Sets Single-valued and multi-valued Example: multi-valued attribute: phone_numbers Derived Can be computed from other attributes Example: age, given date_of_birth Composite Can be broken down into subdivided into component attributes An entity set with a primary key is a strong entity set. An entity set with insufficient attributes to form a primary key is a weak entity set. A weak entity set depends on an identifying entity set. partial key ( or discriminator ) = set of attributes that nearly distinguishes among all the entities of a weak entity set. A primary key is formed by compositing the primary key of the identifying strong entity set with the weak entity set s partial key 5 6

Weak Entity Set Examples Bank Loans and Loan Payments Payment (payment_number, payment_date, payment_amount) is a weak entity set, depending on Loan It is weak because payment_number is not unique

2 Weak Entity Set Examples Bank Loans and Loan Payments Payment (payment_number, payment_date, payment_amount) is a weak entity set, depending on Loan It is weak because payment_number is not unique across all payments for all loans (e.g. many loans have a payment # 1) payment_number is the partial key (loan_number, payment_number) is the primary key University courses and course offerings a course is a strong entity and a course_offering can be modeled as a weak entity The discriminator of course_offering would be semester (including year) and section_number (if there is more than one section) If we model course_offering as a strong entity we would model course_number as an attribute. Then the relationship with course would be implicit in the course_number attribute 7 Relationships vs. Entities Many relationships can be expressed as an action: A Person has a Pet A Salesperson sells a Product A Recording Artist records an Album An entity performs a role in a relationship: The Person is the Pet s Owner The Salesperson is the Product s Seller The Recording Artist is the Album s Performer Relationship Attributes vs. Entity Attributes An attribute can belong to an Entity or a Relation. What about these? A Pet Owner has a Pet rabbit A Customer takes out a Loan on June 6, 2007 A Salesperson sells a Product on commission A Recording Artist records an Album in a studio Understanding the semantics of your relationships is imperative 8 Mathematical Reflections on Relationships Entities and Relationships A set of relationships is a mathematical relation Recall: relation R over the domains D 1,, D k is defined as R D 1 D k Previously, we talked about relations as tables, where each domain pertained to an individual attribute: Internal relations Now, we are talking about something between tables, where each domain pertains to an entire table: External relations Relations vs. Functions Function Y = f(x) : a value of X maps to at most one value of Y. Relation r(x, Y) : is a set of tuples of the form (X, Y). For a given X, there may be multiple associated Y s, and vice versa. Functions are a special case of Relations What are the entities? The entity sets? What are the relationships? The relationship set? 9 10 Entities and Relationships Each line connecting a customer to a loan is a relationship. Relationship Attributes Generally, attributes belong to entities. Sometimes, relationships have attributes also. For instance, the depositor relationship set between entity sets customer and account may have the attribute access-date The Customer entity set. Each row is one entity (one customer). The Loan entity set. Each row is one entity (one loan)

Example: Suppose we wish to track all access_dates to each account by each customer. If a depositor has N access_date values, we cannot create N relationships.

3 Keys 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 NOTE: this means a pair of entities can have at most one relationship in a particular relationship set. Example: Suppose we wish to track all access_dates to each account by each customer. If a depositor has N access_date values, we cannot create N relationships. We can, however, make access_date a multi-valued attribute within the single relationship per depositor To choose candidate keys: consider the cardinality of the relationship set (more later) To choose the primary key: consider the semantics Relationship Set Degree Degree The number of entity sets participating in a relationship Usually 2 (binary) Binary degree is the easiest to deal with in a database Example of degree of 3 (ternary) relationship: Suppose employees of a bank may have jobs (responsibilities) at multiple branches, with different jobs at different branches. Then there is a ternary relationship set between entity sets employee, job, and branch Converting Non-Binary Relationships to Binary 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. R A, relating E and A 2.R B, relating E and B 3. R C, relating E and C Create a special identifying attribute for E Add any attributes of R to E For each relationship (a i, b i, c i ) in R, create 1. a new entity e i in the entity set E 2. add (e i, a i ) to R A 3. add (e i, b i ) to R B 4. add (e i, c i ) to R C Relationship Set Cardinality Constraints Cardinality Quantity of each type of entity that participates in one relationship Constraints The semantics of the relationship constrain the cardinality For a binary relationship set, the mapping cardinality must be one of the following types: One to one One to many Many to one Many to many Person Soc. Sec. Number Country Cities Cities Country Actor(s) Film(s) Relationship Set Cardinality Constraints Diagramming an E-R Model One to one One to many Many to one Many to many Note: Some elements in A and B may not be mapped to any elements in the other set 17 18

Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to rectangles.

21 22 Review Specialization and Generalization Entities Strong (has a primary key) Weak (incomplete key, must have relationship to a a strong entity) Attributes Primary key (uniquely identifies each

4 Diagramming an E-R Model (Cont.) Example: E-R Diagram With Composite, Multivalued, and Derived Attributes Notating Relationship Cardinality Example 1: a loan is associated with at most one customer via borrower, but a customer could have several loans. 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, used to clarify semantics of the relationship Example 2: a customer is associated with at most one loan via borrower, but a loan could have several customers Review Specialization and Generalization Entities Strong (has a primary key) Weak (incomplete key, must have relationship to a a strong entity) Attributes Primary key (uniquely identifies each entity or relationship) Single-valued Multi-valued Composite a cluster of multiple attributes Relationships Degree (number of entity sets per relationship, usually 2) Cardinality (number of entities from each entity set in a relationship), 1-to-1, 1-to-many, many-to-1, or many-many Role (semantic description, useful when the relationship is recursive) Hierarchical Entity Sets Definition Designate distinctive subgroups within an entity set Analogous to Object-Oriented subclasses A subgroup becomes a distinct entity set May have its own attributes May participate in relationships that do not apply to the higher-level entity set. Inheritance a lower-level entity set inherits all the attributes and relationship participation of the higher-level entity set to which it is linked. Depicted by a triangle component labeled IS_A (E.g. customer is a person) 23 24

Specialization/Generalization Example Properties of Subclasses Membership determination How do you determine subclass membership? Could it be determined by an attribute value in the superclass?

5 Specialization/Generalization Example Properties of Subclasses Membership determination How do you determine subclass membership? Could it be determined by an attribute value in the superclass? Membership cardinality Disjoint: an entity may be in multiple subclasses Overlapping: an entity may not be in multiple subclasses Completeness Total : every entity must belong to a subclass Partial: an entity need not belong to a subclass E-R Design Decisions and Guidelines Use of entity sets vs. attributes If an attribute possesses attributes of its own, it may be an entity set Use of entity sets vs. relationship sets Guideline: relationship set describes an action between entities. Suggestion: form a sentence, Entity X relationship to entity Y. Relationship cardinality How many entities could be involved? Double-check your understanding with your test sentence above. Binary versus N-ary relationship sets Check that an N-ary relationship set isn t actually a misstated transitive relationship, Entity X relationship1 to Entity Y, which relationship2 to Entity Z. That is really a set of binary relationships. The use of specialization/generalization contributes to modularity in the design. Victor Lee CS 4/53005, Fall 2007, UML: Unified Modeling Language Comparing E-R and UML Class Diagrams Comprehensive graphical notation to model different aspects of an entire software system Newer and Cleaner than E-R Notation A subset of UML works well for E-R modeling Entity sets - boxes Attributes - listed within the entity set s box Binary relationship sets - a line connecting the two entity sets The role of a entity set in a relationship set written on the line If a relationship set has its own attributes, then its role name and attributes are given their own box connected by a dotted line to the line of the relationship set. E-R Notation Equivalent UML 29 30

6 Comparing E-R and UML Class Diagrams UML Relationship Cardinality Constraints Notation: written as L..H, where L = the minimum and H = the maximum number of relationships an entity can participate in Position Beware: the positioning of the constraints is exactly the reverse of the positioning of constraints in E-R diagrams. E-R Notation *Note reversal of position in cardinality constraint depiction *Generalization can use merged or separate arrows independent of disjoint/overlapping 31 Equivalent UML Interpretation The constraint 0..* on the E2 side and 0..1 on the E1 side means The relationship is many-to-one from E2 to E1. Each E2 entity can participate in at most one relationship Each E1 entity can participate in many relationships. Q: What do the minimum values of 0 mean? 32 Reducing E-R Models to Relation Schemas Entity Set Reduction A database which conforms to an E-R diagram can be represented by a collection of schemas. For each entity set and relationship set, there is a unique schema Each schema has a set of columns (generally corresponding to attributes) E-R Elements that lead to Relation Schemas (Tables): Strong Entity Sets, Weak Entity Sets Many-to-Many Relationship Sets Multi-valued Attributes E-R Elements that are merged into other Relation Schema: One-to-many, Many-to-one, One-to-One Relationship Sets E-R Element Strong entity set Weak entity set Weak entity set example: Relation Schema Element Table w/ same attributes & primary key Table w/ added column for primary key of the identifying strong entity set Payment is a weak entity set with Loan as its identifying strong entity set payment = ( loan_number, payment_number, payment_date, payment_amount ) Schema s primary key is the combined primary keys of the two entity sets Other attributes of the weak entity set Relationship Sets Reduction Example of Many-to-One Redundancy The transformation depends on the cardinality constraint. Many-to-many: Represented as a schema with attributes for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set. Example: schema for relationship set borrower borrower = (customer_id, loan_number ) Many-to-one or one-to-many: The schema can often be eliminated as redundant. Add the primary key of the one entity schema to the many entity schema, as a foreign key. Add any attributes of the relationship to the many entity schema. If the relationship isn t total, null values are possible. One-to-one: Same as one-to-many, choosing either side to act as many account_branch is a many-to-one relationship set, so we do not need to create a schema for it. Instead, add an attribute branch_name to the schema arising from entity set account 35 36

7 Composite and Multi-valued Attributes Composite attributes: replace with a separate attribute for each component attribute Example: attribute name has components first_name and last_name. Replace name with first_name and last_name A multi-valued attribute M of an entity E is represented by a separate schema EM Schema EM has attributes corresponding to the primary key of E and an attribute corresponding to multi-valued attribute M Example: Multi-valued attribute dependent_names of employee is represented by a schema: employee_dependent_names = ( employee_id, dname) Each value of the multi-valued attribute maps to a separate tuple of the relation on schema EM For example, an employee entity with primary key and dependents Jack and Jane maps to two tuples: ( , Jack) and ( , Jane) Representing Specialization via Schemas 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 schema person customer employee attributes name, street, city name, credit_rating name, salary Drawback: getting information about, an employee requires accessing two relations, the one corresponding to the lowlevel schema and the one corresponding to the high-level schema Representing Specialization as Schemas, 2 Method 2: Form a schema for each entity set with all local and inherited attributes schema attributes person name, street, city customer name, street, city, credit_rating employee name, street, city, salary Alternative E-R Notations Figure 6.24 If specialization is total, the schema for the generalized entity set (person) is redundant Can be defined as a view relation containing union of specialization relations But explicit schema may still be needed for foreign key constraints Drawback: street and city may be stored redundantly for people who are both customers and employees 39 40

Chapter 6: Entity-Relationship Model. The Next Step: Designing DB Schema. Identifying Entities and their Attributes. The E-R Model.

Chapter 6: Entity-Relationship Model The Next Step: Designing DB Schema Our Story So Far: Relational Tables Databases are structured collections of organized data The Relational model is the most common