CS2 Current Technologies Lecture 5: Data Modelling and Design

Transcription

1 T E H U N I V E R S I T Y O H F R G E D I N B U CS2 Current Technologies Lecture 5: Data odelling and Design Chris Walton (cdw@dcs.ed.ac.uk) 25 February 2002

2 Conceptual odelling 1 Designg effective database systems can be a difficult process. The idea behind conceptual modelling is to allow the designer to concentrate on a good representation of the system, ignoring (to some extent) implementation details and efficiency considerations. There are many techques for conceptual modelling, the most common of which is the entity-relationship (ER) techque [Chen 1976]. The ER model is an informal representation based on diagrams. ER models are typically used for modelling business processes. We can easily translate ER models into relational schemas.

3 Entities 2 Defition: an entity is a real-world object distinguishable from other objects. Entities are classified as follows: 1. Weak Entities - existence-dependent on other entities (e.g. parent/child). 2. Strong Entities - non dependent on other entities. Entities have properties, which may be: 1. Simple or composite (e.g. first, itial, sur or full ) 2. Key - uque in some context (e.g. reference number) 3. Single or multi-valued (e.g. location, locations) 4. issing (e.g. unknown or non-applicable) 5. Base or derived (e.g. individual quantity or total number)

4 Entity Sets 3 An entity set is a collection of similar entities, e.g. all employees. 1. All entities in the set have the same set of properties (for now). 2. Each entity set has a key. 3. Each property has a domain (type). We can easily map an entity set to a relation: lot (Key) lot JA D Lesar 48 JX A cdouglas 22 JA B Smiley 35

5 apping Properties 4 The main kinds of properties are: simple, composite, key, and multi-valued. Each of these kinds of properties is represented and translated as follows: Composite first sur Lots Key lot ulti Valued Primary Key first sur lot1 Primary Key lot2

6 Relationships 5 A relationship is an association between two or more entities. There are three different kinds of (binary) relationships: 1. 1-to-1 - e.g. one manager per department to-many - e.g. employees are assigned to one department. 3. many-to-many - e.g. several departments involved in several projects many many many Relationships can be partial or total with respect to entity sets.

7 Relationship Sets 6 A relationship set is a collection of similar relationships. an 1 1 arried Woman an 1 Son Woman an Likes Woman The same entity may participate in different relationship sets, or in different roles in the same set. Relationship sets can also have properties.

8 7 apping Relationships to Relations lot did d budget Works_In did since JA D 51 1/1/99 1 supervisor subordinate Works_In 1 Departments Primary Keys JX A JA B Reports_To subordinate 56 2/5/ /7/92 supervisor Reports_To since JA D JA B JX A JX A Translation of relationships: 1. For a one-many relationship, the many side of the relationship should be a primary key. 2. For a many-many relationship, the composition of keys is the primary key. 3. For a one-one relationship, just combine the tables.

9 Weak Entities 8 The owner entity set and the weak entity set participate in a one-to-many relationship set. Weak entity set must have total participation in this relationship set. The entity set and relationship set are translated into a single relation, e.g: lot p age Dependents 1 Policy Dependents p age cost shares JA517453D cost

10 Entity Subtypes and Supertypes 9 Any entity is of at least one entity type, but an entity can be of more than one type simultaneously. For example, some may be Programmers: 1. The entity type Programmer is a subtype of entity type Employee. 2. The entity type Employee is a supertype of entity type Programmer. Properties and relationships which apply to a supertype are inherited by a subtype, but not vice versa. This is called an entity-type hierarchy (or ISA hierarchy). office anagers Database Programmers Programmers Web Programmers platform language

11 apping Subtypes and Supertypes to Relations 10 The supertype is mapped onto a relation as before. Subtypes are also mapped with a primary key the same as the supertype. We create a separate view from a join of the supertype to each subtype. View 1 Join anagers Programmers office platform office platform anagers Programmers

12 An Expanded Example 11 The following example illustrates how to describe an application in the ER model and implement it as a relational database. The example constructs a small database for representing students, lecturers and courses. The database will have the following entity sets: 1. Person with properties Id#, Name, Office with properties Room# and Phone. 3. Lecturer with property Salary. 4. Student. 5. Course with properties Code#, Name, Year.

13 Example: The ER Diagram 12 Relationship Sets (many-many): 1. A Has relationship between Person and Office. 2. A Took relationship between Student and Course. 3. A Taught relationship between Lecturer and Course. Grade Id Name Room Phone Person Has Office Student Lecturer Salary Took Taught Subtypes: Course 1. Student is a subtype of Person 2. Lecturer is a subtype of Person. Code Name Year

14 Example: Translation into Relations 13 The resulting database will have the following relations: 1. Person(Id#, Name, ) 2. Office(Room, Phone) 3. Course(Code#, Name, Year) 4. Lect(Id#, Salary) 5. Std(Id#) 6. Has(Id#, Room) 7. Took(Student.Id#, Code, Grade) 8. Taught(Professor.Id#, Code) And the following views: 1. Lecturer = Join(Person, Lect) 2. Student = Join(Person, Std)

15 Entity vs Property 14 It is often difficult to decide whether a concept should be modelled as an entity or a property. Example: should an address be a property of or a separate entity connected by a relationship? Choice of entity or property is entirely dependent on the use we want to make of the information, e.g.: 1. If an employee can have several addresses, then we must use an entity (properties cannot be set-valued). 2. If the structure of the address is important (e.g. city, street, post-code) we must use an entity (properties are atomic).

16 Strengths and Weaknesses of ER modelling 15 Strengths: 1. Intuitive and easy to use! 2. Frequently used in modeeling business processes. 3. Easily convertible into actual database models. Weaknesses: 1. Does not deal well with hierarchical structures. 2. anual refinement of the resulting relational schema is often required. 3. Cannot specify certain constraints: General constraints, e.g. there are at most 1000 students. Inclusion dependencies, e.g. at least 1 person must report to a manager. Functional dependencies, e.g. can t order two parts from the same supplier.