DATABASE TECHNOLOGY. Spring An introduction to database systems

Transcription

1 1 DATABASE TECHNOLOGY Spring 2007 An introduction to database systems Kjell Orsborn Uppsala Database Laboratory Department of Information Technology, Uppsala University, Uppsala, Sweden

2 2 Introduction to Database Design Using Entity-Relationship Modeling Elmasri/Navathe chs 3-4 Kjell Orsborn Department of Information Technology Uppsala University, Uppsala, Sweden

3 3 ER-modeling Aims at defining a high-level specification of the information content in the database. History Chen, P. P. S., The entity-relationship model: towards a unified view of data, ACM TODS, 1, , p Why ER-models? High-level description - easier to understand for non-technicians More formal than natural language - avoid misconceptions and multiple interpretations Implementation independent (of DBMS) - less technical details Documentation Model transformation to an implementation data model

4 4 Entity type and entity An entity type represents a physical or abstract concept with some sort of identity. The individual instances of the concept are members of a set of entities that have the same set of attributes. Entity types express the intention, i.e. the meaning of the concept whereas the set of entities represents the extension of that type. Names of entity types are given in singular form. The description of an entity type is called its schema. PERSON name, ssn, address, phoneno Each attribute in an entity type is associated with a domain that indicates the allowed values of that attribute.

5 Attribute An attribute is a characteristic or aspect that describe an entity (and is defined on entity types). Every attribute has a domain (or value set). A domain specifies the set of allowed values each individual attribute can be assigned. There is (at least) six different types of values for attributes: simple/ sex: M or F composite name: (Ior, Karlsson) single-valued/ name: Ior Karlsson multivalued friends: {Nasse, Puh,...} stored/ birthdate: derived age : 0 null ER-diagram Simple Composite Multivalued Derived 5 Note!

6 6 Attribute cont... Key: an attribute that has unique values for every instance of an entity type is called a key attribute. Sometimes several attributes are used together to get a unique key. An entity type can have more than one key. key hello

7 7 Relationship type and relationship A relationship type represents a relationship (or relation/connection), between a number of entity types. A relationship type R is a set of relationships (i.e. relational instances) or tuples. A relationship type, R, can mathematically be defined as: R E 1 E 2 E n where each E j is a entity type. A tuple (or an instance) t R is written as (e 1, e 2,..., e n ) or <e 1, e 2,..., e n > where e j E j.

8 8 Structural constraints for relationship types Cardinality ratio constraint specifies the number of relational instances that an entity can take part in. For binary relationship types: one-to-one (1:1) one-to-many (1:N) many-to-many (M:N) N M N

9 9 Structural constraints cont.... Partial Total Participation constraint specifies whether the entity existence is dependent of another entity via a relationship type. E.g. can an employee exist without working for a department? Partial participation: the entity can exist without this relationship Total participation: the entity requires this relationship in order to exist. employee works_for department manages

10 10 Roles of relationship types A role name specifies what role an entity type plays in a specific relationship Role names are sometimes used in ER-diagrams to clarify the roles of the participating entity types. Employee manager 1 N worker Supervision

11 11 Attributes for relationship types Also a relationship type can have attributes. E.g. in the case where the weekly number of hours an employee works on a project should be kept, that can be represented for each instance of the relation works-on. If the relation is a 1:1 or 1:N relation, the attribute can be stored at one of the participating entities. When the relation is of the type M:N one must store the attributes with the instance of the relation.

12 12 Weak entity types Weak entity types are those that are meaningless without an owner entity type. Weak entities are uniquely identified in the extension with their owner s key attributes together with its own (broken) underlined attribute. The relationship to the owner is called the identifying relationship.

13 13 ER-notation (Elmasri/Navathe fig. 3.14)

14 14 Example ER-modeling An enterprise consists of a number of departments. Each department has a name, a number, a manager, and a number of employees. The starting date for every department manager should also be registered. A department can have several office rooms. Every department finances a number of projects. Each project has a name, a number and an office room. For each employee, the following information is kept: name, social security number, address, salary and sex. An employee works for only one department but can work with several projects that can be related to different departments. Information about the number of hours (per week) that an employee work with a project should be stored. Information about the employees manager should also be stored.

15 15 The Relational Model The relational model was introduced by Dr. Edgar (Ted) F. Codd ( ) in Dr. Codd. a mathematician from Oxford (UK), was at that time working as an IBM researcher in the IBM San Jose Research Laboratory (USA). Many DBMS s are based on the relational data model. It support simple declarative, but yet powerful, languages for describing operations on data. Operations in the relational model applies to relations (tables) and produce new relations. This means that an operation can be applied to the result of another operation and that several different operations can be combined. Operations are described in an algebraic notation that is based on relational algebra.

16 16 Relation schema and instance A 1, A 2,..., A n are attributes represented by a column in the table R = (A 1, A 2,..., A n ) is a relation schema Customer-schema(customer-name, customer-street, customer-city) r(r) is a relation on the relation schema R customer(customer-schema) an attribute The current values (relation instance) of a relation are specified by a table. An element t of r is a tuple - represented by a row in a table customer customer customer-name customer-street customer-city Jones M ain Harrison a relation Smith North Rye Curry North Rye Lindsay Park Pittsfield a tuple

17 17 First Normal Form Only simple or atomic values are allowed in the relational model. Attributes is not allowed to have composite or multiple values. The theory for the relational model is based on these assumptions which is called: The first normal form assumption

18 18 Keys Because relations are sets, all tuples in the relation are different. There is usually a subset k of the attributes in a relation schema R, i.e. k R, that has the characteristic that if the tuples t1, t2 r(r) and t1 t2, the following holds: t1[k] t2[k] (i.e. the value of k in t1 the value of k in t2) Every such subset k is called a superkey for R. A superkey k is minimal if there is no other superkey k' such that k' k. Every minimal superkey (NOTE! there can be more than one) is called a candidate key for R. The candidate key chosen by the database designer as the key for R is called R:s primary key or just key.

19 19 1. Domain constraint Integrity constraints for a relational database schema attribute values for attribute A shall be atomic values from dom(a) 2. Key constraint candidate keys for a relation must be unique 3. Entity integrity constraint no primary key is allowed to have a null value 4. Referential integrity constraint a tuple that refers to another tuple in another relation must refer to an existing tuple 5. Semantic integrity constraint e.g. an employee s total work time per week can not exceed 40 hours for all projects taken all together

20 20 From E-R to relational model The basic procedure defines a set of relational schemas that represent entity and relationship types in the E-R model. This model should further with integrity constraints. Primary keys allow entity types and relationship types 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. For each entity type and relationship type there is a unique table which is assigned the name of the corresponding entity type or relationship type. Each table has a number of columns (generally corresponding to attributes), which have unique names. Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram.

21 21 Summary Entity types and their attributes Step 1) Entity types Each entity gets a corresponding table, with the primary key column set to its key attribute. Step 2) Weak entity types The primary key of a weak entity type table has the primary key of the owner table as a component. Relationships Step 3) 1-1 Relationship 4 alternatives: fk in E1 or E2, separate R table, common table for E1 & E2 Step 4) 1-N Relationship fk i entity on the N-side, separate R table Step 5) M-N Relationship separate R table

22 22 Summary cont... Multivalued attributes and relationships Step 6) Multivalued attributes Separate table for the attribute with its pk composed of the owner pk and the value column. Step 7) Multivalued relationships Separate R table. N-N-N: pk composed of all fk s. 1-N-N: pk is fk to the E1- table.

23 23 Translating entity types and their attributes pk Step 1: Entity types - a strong entity type reduces to a table with the same attributes. Key attributes (primary key - pk) is made the primary key column(s) for the table. Each attribute gets their own column. Composite attributes are normally represented by their simple components. Example customer schema and table: Customer(social-security, customer-name, c-street, c-city) social-security customer-name c-street c-city Jones M ain Harrison Smith North Rye Hayes M ain Harrison

24 24 Translating entity types cont... Step 2: Weak entity types - a weak entity type becomes a table that includes a column for the primary key of the identifying strong entity type. pk E1 1 N R E2 k a1 a2 pk a1 pk k a2

25 25 Translating entity types cont... The table corresponding to a relationship type linking a weak entity type to its identifying strong entity type is redundant. Example of the payment schema and table: The payment table already contains the information that would appear in the loanpayment table (i.e., the columns loan-number and payment-no). Payment(loan-number, payment-no, pay-date, amount) loan-number payment-no pay-date amount L M ay L M ay L M ay

26 26 Translating relationship types Step 3: 1-1 Relationship types The foreign key column (fk) is a copy of the other entity s primary key column (pk). The values in a fk-column point to unique row in the other table, and thus implement the relationship. pk1 E1 1 1 R E2 pk2 a1 a2 Alt 1: pk1 a1 pk2 a2 f k1 Alt 2: pk1 a1 f k2 pk2 a2

27 27 Translating 1-1 relationship types cont... E1 R E2 Alt 3: pk1 a1 f k1 f k2 pk2 a2 E1 E2 Alt 4: pk1 a1 pk2 a2

28 28 Translating relationship... cont... Step 4: 1-N Relationship types Include the primary key of the 1-side as a foreign key on the N-side, (i.e. the foreign key column is placed on the entity on the N-side). Alternatively, an extra table (R) is created whose primary key is a foreign key composed by the primary key from the N-side. pk1 E1 1 N R E2 pk2 a1 a2 Alt 1: pk1 a1 pk2 a2 f k1 Alt 2: pk1 a1 f k1 f k2 pk2 a2

29 29 Translating relationship... cont... Step 5: M-N Relationship types Always a separate table with columns for the primary keys of the two participating entity types, and any descriptive attributes of the relationship type. pk1 E1 M R N E2 pk2 a1 a2 pk1 a1 f k1 f k2 pk2 a2

30 30 Translating relationship... cont... Step 6: Multivalued attributes A separate table is created for the multivalued attribute. Its primary key is composed of the owning entity s primary key, and the attribute value itself. a pk E mva E E-MVA pk a pk mva

31 31 Translating relationship... cont... Step 7: Multivalued relationship types First try to remove multivalued relationships on the E-R model level by model transformation. A separate table is created, with foreign keys to all tables that are included in the relationship. Its primary key is composed of all foreign keys. pk1 E1 N R N E2 pk2 N a pk3 E3 R f k1 f k2 f k3 a

32 32 Translating relationship... cont... Step 7: Multivalued relationship types continued In the case where R is 1-N-N, the primary key on R shall not include the fk for the table with cardinality 1. pk1 E1 1 N R E2 pk2 N a pk3 E3 R f k1 f k2 f k3 a

33 33 Example E-R to relational model translation ename EMPLOYEE salary N 1 WORKS_IN 1 1 MANAGES sname saddr dname DEPARTMENT SUPPLIER dno 1 CARRIES N M N SUPPLIES price date iname ITEM ino N M ono ORDER INCLUDE quantity N PLACED_BY CUSTOMER cname 1 balance caddr

34 34 Entity and relationship types in the example (see figures in Elmasri/Navathe) Entity types: EMPLOYEE(name(fstname,famname), ssn, address, sex, salary) DEPARTMENT( name, number, {room}) PROJECT( name, number, room, department) Relationsship types: An employee MANAGES a department 1:1 Every department FINANCES at least one project 1:N Every employee WORKS-FOR a department N:1 Every employee WORKS -WITH one (or several) project(s) M:N An employee IS-MANAGER over several employees 1:N

35 35 ER-diagram for the example enamn fnamn JOBBAR-ÅT namn nummer lokal namn kön lön AVDELNING persnr adress ANSTÄLLD LEDER FINANSIERAR startdatum ÄR-CHEF JOBBAR-MED PROJEKT namn nummer lokal timmar

36 36 ER-diagram for the example fstname famname WORKS-FOR name number room name sex salary DEPARTMENT ssn address EMPLOYEE MANAGES FINANCES startdate IS-MANAGER WORKS-WITH PROJECT name number room hours

37 37 ER-diagram for the example

38 38 Entity types in the example EMPLOYEE name(fstname,famname), ssn, address, sex, salary, department, manager, {works-on(project, hours)} DEPARTMENT name, number, {room}, dmanager, startdate PROJECT name, number, room, department

39 39 Relationship types in the example Every department is led (managed) by a manager Every department finances at least one project Every employee works for a department Every employee works with one (or several) project(s) Every employee has a manager employee MANAGES department 1:1 department FINANCES project 1:N employee WORKS-FOR department N:1 employee WORKS -WITH project M:N employee IS-MANAGER employee 1:N (See figures in Elmasri/Navathe)

40 40 A simple ER-diagram example Customer(customer-id, customer-name, customer-street, customer-city) Account(account-number, balance) A customer is a depositor of money in an account.

41 41 Relational schemas for the example Schemas for the entity types in the example above EMPLOYEE(ENAME, SALARY, DEPT) DEPARTMENT(DNO, DNAME, MGR) SUPPLIER(SNAME, SADDR) ITEM(INO, INAME, DNO) ORDER(ONO, DATE, CUST) CUSTOMER(CNAME, CADDR, BALANCE) Schemas for relationship types (M:N) SUPPLIES(SNAME, INO, PRICE) INCLUDE(ONO, INO, QUANTITY)

42 42 An example relation If customer-name = {Jones, Smith, Curry, Lindsay } customer-street = { Main, North, Park } customer-city = { Harrison, Rye, Pittsfield } Then r = {(Jones, Main, Harrison), (Smith, North, Rye), (Curry, North, Rye), (Lindsay, Park, Pittsfield)} is a relation over customer-name customer-street customercity

43 43 Key examples Example superkey: {customer-name, customer- street} and {customer- name} are both superkeys of Customer, if no two customers can possibly have the same name. Example candidate key: {customer- name} is a candidate key for Customer, since it is a superkey (assuming no two customers can possibly have the same name), and no subset of it is a superkey.