Database Systems Conceptual Database Design SL04

Transcription

1 Informatik für Ökonomen II Fall 2010 Database Systems Conceptual Database Design SL04 Basic Entity-Relationship (ER) Model Concepts Entities and attributes, entity types, entity sets Relationships and relationship types Weak entity types Roles and attributes in relationship types ER-to-Relational mapping algorithm Illustration of Evaluation of SQL Statements/1 1. FROM: form the cross product of the tables in the from clause FROM 2. WHERE: eliminate tuples that do not satisfy the where clause... WHERE 3. GROUP BY: group tuples according to the group clause GROUP BY... Inf4Oec10, SL04 1/57 M. Böhlen, Illustration of Evaluation of SQL Statements/2 Inf4Oec10, SL04 2/57 M. Böhlen, Checking HAVING: eliminate groups that do not satisfy the having clause HAVING 5. SELECT: evaluate the expressions in the select clause and produce one result tuple for each group SELECT 1. Translate the relational algebra expression π X (r σ U=12 (s)) into SQL. select X select X from r, ( select * from r, s from s where s.u = 12 where U = 12) 2. What is the result of the following SQL query select min(x), sum(x), max(y), Z from r group by Z? r X Y Z Result min(x) sum(x) max(y) Z Inf4Oec10, SL04 3/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 4/57 M. Böhlen, ifi@uzh

2 Checking... Overview of Database Design Process 3. What is the result of the following SQL statement: select * from r where X > 10 or X <= 10 All tuples from r where attribute X is not null 4. What is the result of the following SQL statement: select * from r where X <> null An empty relation with the schema of r Inf4Oec10, SL04 5/57 M. Böhlen, ifi@uzh Example COMPANY Database Inf4Oec10, SL04 6/57 M. Böhlen, ifi@uzh ER Model Concepts We need to create a database schema design based on the following requirements of the COMPANY database: The company is organized into departments. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of projects. Each project has a unique name, unique number and is located at a single location. We store each employee s social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of dependents. For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee. Entities and Attributes Entities are specific objects or things in the mini-world that are represented in the database. For example the employee John Smith, the Research department, the project ProductX Attributes are properties used to describe an entity. For example an employee entity may have the attributes Name, SSN, Address, Sex, BirthDate A specific entity will have a value for each of its attributes. For example a specific employee entity may have Name = John Smith, SSN = , Address = 731, Fondren, Houston, TX, Sex = M, BirthDate = 09-JAN-55 Each attribute has a domain (value set, data type) associated with it, e.g., enumerated type, integer, string, subrange,... Inf4Oec10, SL04 7/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 8/57 M. Böhlen, ifi@uzh

3 Types of Attributes/1 Simple attribute Each entity has a single atomic value for the attribute. For example, SSN or Sex. Composite attribute The attribute may be composed of several components. For example: Address(Apt#, House#, Street, City, State, ZipCode, Country), or Name(FirstName, MiddleName, LastName). Multi-valued attribute An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}. Derived attribute Attributes can be derived (computed) rather than stored. Attribute Number of employees is a derived attribute of DEPARTMENT. Types of Attributes/2 Composite and multi-valued attributes may be nested arbitrarily to any number of levels. For example, PreviousDegrees of a student is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)} Multiple PreviousDegrees values can exist Each has four subcomponent attributes: College, Year, Degree, Field A hierarchy of composite attributes: Address Street address City State Zip Number Street Apartment number Inf4Oec10, SL04 9/57 M. Böhlen, ifi@uzh Entity Types and Key Attributes Entities with the same basic attributes are grouped or typed into an entity type. For example, the entity type EMPLOYEE and PROJECT. An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE. A key attribute may be composite. VehicleTagNumber is a key of the CAR entity type with components (Number, State). An entity type may have more than one key. The CAR entity type may have two keys: VehicleIdentificationNumber (popularly called VIN) VehicleTagNumber (Number, State), aka license plate number. Each key is underlined. Inf4Oec10, SL04 10/57 M. Böhlen, ifi@uzh Displaying an Entity type In ER diagrams, an entity type is displayed in a rectangular box Attributes are displayed in ovals Each attribute is connected to its entity type Components of a composite attribute are connected to the oval representing the composite attribute Each key attribute is underlined Multivalued attributes are displayed in double ovals Derived attributes are displayed in dashed ovals Entity type CAR with attributes Registration(Number, State), Vehicle id, Make, Model, Year, {Color} Inf4Oec10, SL04 11/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 12/57 M. Böhlen, ifi@uzh

4 Entity Set Entity Types for the COMPANY Database/1 The collection of all entities of a particular entity type in the database is called the entity set. The same name (e.g., CAR) is used to refer to both the entity type and the entity set. The entity set is the current state of the entities of that type that are stored in the database. Entity set CAR: Based on the requirements, we can identify four initial entity types in the COMPANY database: DEPARTMENT PROJECT EMPLOYEE DEPENDENT The initial attributes are derived from the requirements description Guidelines for determining entity types and attributes: The nouns in a descriptions translate to entity types Nouns that describe nouns of entity types translate to attributes. Inf4Oec10, SL04 13/57 M. Böhlen, ifi@uzh Entity Types for the COMPANY Database/2 Inf4Oec10, SL04 14/57 M. Böhlen, ifi@uzh Relationships and Relationship Types/1 The initial design is typically not complete. The schema design process is an iterative refinement process. The initial design is created and iteratively refined. Some aspects in the requirements will be represented as relationships. ER model has three main concepts: Entities (and their entity types and entity sets) Attributes (simple, composite, multivalued) Relationships (and their relationship types and relationship sets) Inf4Oec10, SL04 15/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 16/57 M. Böhlen, ifi@uzh

5 Relationships and Relationship Types/2 Relationships and Relationship Types/3 A relationship relates two or more distinct entities with a specific meaning. For example, EMPLOYEE John Smith works on PROJECT ProductX, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS ON are binary relationships. Relationship type: Schema description of a relationship Identifies the relationship name and the participating entity types Identifies relationship constraints Relationship set: The current set of relationship instances represented in the database The current state of a relationship type Each instance in the set relates individual participating entities one from each participating entity type Inf4Oec10, SL04 17/57 M. Böhlen, ifi@uzh WORKS FOR relationship Inf4Oec10, SL04 18/57 M. Böhlen, ifi@uzh Relationships for the COMPANY database/1 entity: e 1 relationship: r 1 = WORKS FOR(e 1,d 1 ) entity set: EMPLOYEE relationship set: WORKS FOR By examining the requirements, six relationship types are identified All are binary relationships (degree 2) Listed below with their participating entity types: WORKS FOR (between EMPLOYEE and DEPARTMENT) MANAGES (also between EMPLOYEE and DEPARTMENT) CONTROLS (between DEPARTMENT and PROJECT) WORKS ON (between EMPLOYEE and PROJECT) SUPERVISION (between EMPLOYEE (as subordinate) and EMPLOYEE (as supervisor)) DEPENDENTS OF (between EMPLOYEE and DEPENDENT) In ER diagrams, we represent the relationship type as follows: Diamond-shaped box is used to display a relationship type Connected to the participating entity types via straight lines Inf4Oec10, SL04 19/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 20/57 M. Böhlen, ifi@uzh

6 Relationships for the COMPANY database/2 Discussion of Relationship Types/1 In the refined design, some attributes from the initial entity types are refined into relationships: Manager of DEPARTMENT -> MANAGES Works on of EMPLOYEE -> WORKS ON Department of EMPLOYEE -> WORKS FOR etc More than one relationship type can exist between the same participating entity types: MANAGES and WORKS FOR are distinct relationship types between EMPLOYEE and DEPARTMENT These relationship types have different meanings and different relationship instances. Inf4Oec10, SL04 21/57 M. Böhlen, Discussion of Relationship Types/2 Inf4Oec10, SL04 22/57 M. Böhlen, Structural Constraints on Relationships In a recursive relationship type the same participating entity type occurs in distinct roles Example: the SUPERVISION relationship EMPLOYEE participates twice in two distinct roles: supervisor (or boss) role supervisee (or subordinate) role Each relationship instance relates two distinct EMPLOYEE entities: One employee in supervisor role One employee in supervisee role Structural constraints on relationship types limit the possible combinations of entities in relationship sets. A cardinality constraint specifies maximum participation One-to-one (1:1) One-to-many (1:N) or Many-to-one (N:1) Many-to-many (M:N) A participation constraint specifies minimum participation (also called existence dependency) zero (optional participation, not existence-dependent) one or more (mandatory participation, existence-dependent) Inf4Oec10, SL04 23/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 24/57 M. Böhlen, ifi@uzh

7 Many-to-one (N:1) Relationship Many-to-many (M:N) Relationship EMPLOYEE:DEPARTMENT = N:1 An employee works for at most 1 department A department employs at most N employees Inf4Oec10, SL04 25/57 M. Böhlen, ifi@uzh Recursive Relationships/1 EMPLOYEE:PROJECT = M:N An employee works on at most N projects A project is assigned to at most M employees Inf4Oec10, SL04 26/57 M. Böhlen, ifi@uzh Recursive Relationships/2 In a recursive relationship type: The same entity type participates in different roles. For example, SUPERVISION relationships between an EMPLOYEE in role of supervisor (or boss) and another EMPLOYEE in role of subordinate (or worker). In ER diagrams we need to display role names to distinguish participations. label 1 stands for supervisor role label 2 stand for subordinate role e 1 is the supervisor of e 2 e 1 is supervised by e 5 Inf4Oec10, SL04 27/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 28/57 M. Böhlen, ifi@uzh

8 Attributes of Relationship types Notation for Constraints on Relationships A relationship type can have attributes: For example, HoursPerWeek of WORKS ON Its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT. A value of HoursPerWeek depends on a particular (employee, project) combination Most relationship attributes are used with M:N relationships In 1:N relationships, they can be transferred to the entity type on the N-side of the relationship Cardinality constraints (of a binary relationship): 1:1, 1:N, N:1, or M:N Shown by placing appropriate numbers on the relationship edges. Participation constraint on each participating entity type: total (called existence dependency) or partial. Total shown by double line, partial by single line. Structural constraints are easy to specify for binary relationship types but get more subtle for higher order relationship types. Inf4Oec10, SL04 29/57 M. Böhlen, ifi@uzh Weak Entity Types Inf4Oec10, SL04 30/57 M. Böhlen, ifi@uzh Alternative Diagrammatic Notation A weak entity type is an entity type that does not have a key attribute. A weak entity must participate in an identifying relationship type with an owner or identifying entity type. Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type Example: A DEPENDENT entity is identified by the dependent s first name, and the specific EMPLOYEE with whom the dependent is related Name of DEPENDENT is the partial key DEPENDENT is a weak entity type EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT OF ER diagrams is one popular example for displaying database schemas. Many other notations exist in the literature and in various database design and modeling tools. UML class diagrams are another way of displaying ER concepts. Inf4Oec10, SL04 31/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 32/57 M. Böhlen, ifi@uzh

9 Summary of Notation for ER Diagrams Relationships of Higher Degree/1 Relationship types of degree 2 are called binary Relationship types of degree 3 are called ternary and of degree n are called n-ary Constraints are harder to specify for higher-degree relationships (n>2) than for binary relationships In an n-ary relationship a cardinality constraint specifies how often an entity may occur for one specific instance of all other entities. In general, an n-ary relationship is not equivalent to n binary relationships If needed, the binary and n-ary relationships can all be included in the schema design Inf4Oec10, SL04 33/57 M. Böhlen, ifi@uzh Relationships of Higher Degree/2 Inf4Oec10, SL04 34/57 M. Böhlen, ifi@uzh Relationships of Higher Degree/3 In some cases, a ternary relationship can be represented as a weak entity if the data model allows a weak entity type to have multiple identifying relationships (and hence multiple owner entity types) Inf4Oec10, SL04 35/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 36/57 M. Böhlen, ifi@uzh

10 Relationships of Higher Degree/4 If a particular binary relationship can be derived from a higher-degree relationship at all times, then it is redundant. For example, the TAUGHT DURING binary relationship can be derived from the ternary relationship OFFERS (based on the meaning of the relationships) Data Modeling Tools A number of popular tools that conceptual modeling and mapping into relational schema design. Examples: ERWin, S-Designer (Enterprise Application Suite), ER-Studio, etc. Pros: Serves as documentation of application requirements Easy user interface: mostly graphics editor support Simple graphical models are very intuitive Cons: Graphical models easily get complex and ambiguous Most tools lack a proper distinct notation for relationships with relationship attributes Mostly represent a relational design in a diagrammatic form rather than a conceptual ER-based design Inf4Oec10, SL04 37/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/1 Inf4Oec10, SL04 38/57 M. Böhlen, ifi@uzh The ER Schema for the COMPANY Database Algorithm to map a conceptual database design to a relational database design. ER-to-Relational Mapping Algorithm Step 1: Mapping of Regular Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary 1:1 Relation Types Step 4: Mapping of Binary 1:N Relationship Types Step 5: Mapping of Binary M:N Relationship Types Step 6: Mapping of Multivalued attributes Step 7: Mapping of N-ary Relationship Types Inf4Oec10, SL04 39/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 40/57 M. Böhlen, ifi@uzh

11 ER-to-Relational Mapping Algorithm/2 ER-to-Relational Mapping Algorithm/3 Step 1: Mapping of Regular Entity Types. For each regular (strong) entity type E in the ER schema, create a relation R that includes all the simple attributes of E. Choose one of the key attributes of E as the primary key for R. If the chosen key of E is composite, the set of simple attributes that form it will together form the primary key of R. Example: We create the relations EMPLOYEE, DEPARTMENT, and PROJECT in the relational schema corresponding to the regular entities in the ER diagram. SSN, DNUMBER, and PNUMBER are the primary keys for the relations EMPLOYEE, DEPARTMENT, and PROJECT as shown. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary) DEPARTMENT(DName, DNumber) PROJECT(PName, PNumber, PLocation) Inf4Oec10, SL04 41/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/4 Inf4Oec10, SL04 42/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/5 Step 2: Mapping of Weak Entity Types For each weak entity type W in the ER schema with owner entity type E, create a relation R and include all simple attributes (or simple components of composite attributes) of W as attributes of R. Also, include as foreign key attributes of R the primary key attributes of the relations that correspond to the owner entity types. The primary key of R is the combination of the primary keys of the owners and the partial key of the weak entity type W, if any. Example: Create the relation DEPENDENT in this step to correspond to the weak entity type DEPENDENT. Include the primary key SSN of the EMPLOYEE relation as a foreign key attribute of DEPENDENT (renamed to ESSN). The primary key of the DEPENDENT relation is the combination ESSN, DepName because DepName is the partial key of DEPENDENT. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary) DEPARTMENT(DName, DNumber) PROJECT(PName, PNumber, PLocation) DEPENDENT(ESSN, DepName, Sex, BDate, Relationship) Inf4Oec10, SL04 43/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 44/57 M. Böhlen, ifi@uzh

12 ER-to-Relational Mapping Algorithm/6 Step 3: Mapping of Binary 1:1 Relation Types For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. There are three possible approaches: 1. Foreign Key approach: Choose one of the relations, say S, and include as foreign key in S the primary key of T. It is better to choose an entity type with total participation in R in the role of S. 2. Merged relation option: An alternate mapping of a 1:1 relationship type is possible by merging the two entity types and the relationship into a single relation. This may be appropriate when both participations are total. 3. Cross-reference or relationship relation option: The third alternative is to set up a third relation R for the purpose of cross-referencing the primary keys of the two relations S and T representing the entity types. ER-to-Relational Mapping Algorithm/7 Example: The 1:1 relation MANAGES is mapped by choosing the participating entity type DEPARTMENT to serve in the role of S, because its participation in the MANAGES relationship type is total. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary) DEPARTMENT(DName, DNumber, MgrSSN, MgrStartDate) PROJECT(PName, PNumber, PLocation) DEPENDENT(ESSN, DepName, Sex, BDate, Relationship) Inf4Oec10, SL04 45/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/8 Inf4Oec10, SL04 46/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/9 Step 4: Mapping of Binary 1:N Relationship Types For each binary 1:N relationship type R in the ER schema, identify the relations S and T that correspond to the entity types participating in R. S is the N-side. Include as foreign key in S the primary key of relation T that represents the other entity type participating in R. Include simple attributes of the 1:N relation type as attributes of S. Example: 1:N relationship types WORKS FOR, CONTROLS, and SUPERVISION. For example for WORKS FOR we include the primary key DNUMBER of the DEPARTMENT relation as foreign key in the EMPLOYEE relation and call it DNO. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary, SuperSSN, DNo) DEPARTMENT(DName, DNumber, MgrSSN, MgrStartDate) PROJECT(PName, PNumber, PLocation, DNum) DEPENDENT(ESSN, DepName, Sex, BDate, Relationship) Inf4Oec10, SL04 47/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 48/57 M. Böhlen, ifi@uzh

13 ER-to-Relational Mapping Algorithm/10 ER-to-Relational Mapping Algorithm/11 Step 5: Mapping of Binary M:N Relationship Types. For each regular binary M:N relationship type R, create a new relation S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types; their combination will form the primary key of S. Also include any simple attributes of the M:N relationship type (or simple components of composite attributes) as attributes of S. Example: The M:N relationship type WORKSON from the ER diagram is mapped by creating a relation WORKSON in the relational database schema. The primary keys of the PROJECT and EMPLOYEE relations are included as foreign keys in WORKSON and renamed PNo and ESSN, respectively. Attribute Hours in WORKSON represents the Hours attribute of the relation type. The primary key of the WORKSON relation is the combination of the foreign key attributes ESSN, PNo. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary, SuperSSN, DNo) DEPARTMENT(DName, DNumber, MgrSSN, MgrStartDate) PROJECT(PName, PNumber, PLocation, DNum) DEPENDENT(ESSN, DepName, Sex, BDate, Relationship) WORKSON(ESSN, PNo, Hours) Inf4Oec10, SL04 49/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/12 Inf4Oec10, SL04 50/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/13 Step 6: Mapping of Multivalued attributes. For each multivalued attribute A, create a new relation R. This relation R will include an attribute corresponding to A, plus the primary key attribute K of the relation that represents the entity or relationship type that has A as an attribute. The primary key of R is the combination of A and K. If the multivalued attribute is composite, we include its simple components. Example: The relation DEPTLOC is created. The attribute DLocation represents the multivalued attribute Locations of DEPARTMENT, while DNumber, as foreign key, represents the primary key of the DEPARTMENT relation. The primary key of R is the combination of DNumber, DLocation. EMPLOYEE(FName, MInit, LName, SSN, BDate, Address, Sex, Salary, SuperSSN, DNo) DEPARTMENT(DName, DNumber, MgrSSN, MgrStartDate) PROJECT(PName, PNumber, PLocation, DNum) DEPENDENT(ESSN, DepName, Sex, BDate, Relationship) WORKSON(ESSN, PNo, Hours) DEPTLOC(DNumber, DLocation) Inf4Oec10, SL04 51/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 52/57 M. Böhlen, ifi@uzh

14 ER-to-Relational Mapping Algorithm/14 ER-to-Relational Mapping Algorithm/15 Example: The relationship type SUPPLY Step 7: Mapping of N-ary Relationship Types. For each n-ary relationship type R, where n>2, create a new relationship S to represent R. Include as foreign key attributes in S the primary keys of the relations that represent the participating entity types. Also include any simple attributes of the n-ary relationship type (or simple components of composite attributes) as attributes of S. This can be mapped to the relation SUPPLY shown in the relational schema, whose primary key is the combination of the three foreign keys SName, PartNo, ProjName SUPPLIER(SName,...) PROJECT(ProjName,...) PART(PartNo,...) SUPPLY(SName, ProjName, PartNo, Quantity) Inf4Oec10, SL04 53/57 M. Böhlen, ifi@uzh ER-to-Relational Mapping Algorithm/16 Inf4Oec10, SL04 54/57 M. Böhlen, ifi@uzh Summary of Mapping Constructs and Constraints Correspondence between ER and Relational Models ER Model Relational Model Entity type Entity relation 1:1 or 1:N relationship type Foreign key (or relationship relation) M:N relationship type Relationship relation and two foreign keys n-ary relationship type Relationship relation and n foreign keys Simple attribute Attribute Composite attribute Set of simple component attributes Multivalued attribute Relation and foreign key Key attribute Primary (or secondary) key Inf4Oec10, SL04 55/57 M. Böhlen, ifi@uzh Inf4Oec10, SL04 56/57 M. Böhlen, ifi@uzh

15 Summary ER model concepts: entity type, entity set, entity attribute, attribute value relationship type, relationship set, relationship structural constraints: cardinality, participation ER-to-Relational Mapping Algorithm Step 1: Mapping of Regular Entity Types Step 2: Mapping of Weak Entity Types Step 3: Mapping of Binary 1:1 Relation Types Step 4: Mapping of Binary 1:N Relationship Types. Step 5: Mapping of Binary M:N Relationship Types. Step 6: Mapping of Multivalued attributes. Step 7: Mapping of N-ary Relationship Types. Inf4Oec10, SL04 57/57 M. Böhlen,