Introduction to Database Design

UVic C SC 370

Dr. Daniel M. German Department of Computer Science

May 5, 2004 Version: 1.1.1
2–1 Introduction to Database Design (1.1.1) CSC 370 dmgerman@uvic.ca

Overview
What are the steps in designing a database? What is the entity-relationship (ER) model? How does UML related to the ER model? Chapter 2 of textbook

2–2 Introduction to Database Design (1.1.1)

CSC 370 dmgerman@uvic.ca

ER Model
The Entity-Relationship data model allows us to describe the data involved in a real-world system in terms of objects and their relationships It is widely used in database design

2–3 Introduction to Database Design (1.1.1)

CSC 370 dmgerman@uvic.ca

ca .1) CSC 370 dmgerman@uvic.1.Database Design Database design can be divided in six major steps: Requirements analysis Conceptual Database design (mostly done using the ER model) Logical Database design Schema refinement Physical Database Design Application and Security Design 2–4 Introduction to Database Design (1.

constructed through a subjective evaluation of the information. 2–5 Introduction to Database Design (1.1.1) CSC 370 dmgerman@uvic.ER diagram ER Diagram: an approximate description of the data. that was collected through the requirements analysis phase.ca .

ca .1) CSC 370 dmgerman@uvic.Entities Entity: is an object in the real world that is distinguishable from other objects Entity Set: collection of similar objects An entity is described using a set of attributes Each attribute has a domain of possible values. we should select a key A key is a minimal set of attributes that uniquely identify an entity in a set 2–6 Introduction to Database Design (1.1. For each entity set.

1) CSC 370 dmgerman@uvic.1.Example of an Entity name ssn lot Employees 2–7 Introduction to Database Design (1.ca .

.. ..... en ∈ En } Each n-tuple denotes a relationship involving n entities (e1 ..ca . . ..1) CSC 370 dmgerman@uvic.1. en ) where ei is in the entity set Ei A relationship can also include its own attributes (called descriptive attributes A relationship must be uniquely identified by its participating entities 2–8 Introduction to Database Design (1. en )|e1 ∈ E1 ..Relationships A relationship is an association among two or more entities A set of similar relationships is called a relationship set: {(e1 .

ca .1) CSC 370 dmgerman@uvic.Example of a Relationship name dname Since lot did budget ssn Employees WorksIn Departments 2–9 Introduction to Database Design (1.1.

Example of a Ternary Relationship name dname Since lot did budget ssn Employees WorksIn2 Departments address Locations capacity 2–10 Introduction to Database Design (1.ca .1) CSC 370 dmgerman@uvic.1.

1.Role Indicators name ssn lot Employees supervisor subordinate ReportsTo 2–11 Introduction to Database Design (1.1) CSC 370 dmgerman@uvic.ca .

1) CSC 370 dmgerman@uvic.ca . but each of these entities can only be related to one entity Many-to-many: an entity is related to many other entities. and vice-versa 2–12 Introduction to Database Design (1.Key Constraints One-to-many: an entity is related to many other entities.1.

1) CSC 370 dmgerman@uvic.ca .Key Constraint on Manages name dname Since lot did budget ssn Employees Manages Departments 2–13 Introduction to Database Design (1.1.

Key Constraint on a Ternary Rel.1) CSC 370 dmgerman@uvic.1.ca . name dname Since lot did budget ssn Employees WorksIn3 Departments address Locations capacity 2–14 Introduction to Database Design (1.

1.Participation Constraints There are two types of participation constraints for an entity in a relationship: Total: Every instance of the entity is present in the relationship (represent it by a thick line) Partial: Not every instance of the entity is present in the relationship represented 2–15 Introduction to Database Design (1.1) CSC 370 dmgerman@uvic.ca .

1) CSC 370 dmgerman@uvic.Total participation name Since lot did dname ssn budget Employees Manages Departments WorksIn Since 2–16 Introduction to Database Design (1.ca .1.

ca .1) CSC 370 dmgerman@uvic.Weak Entities Sometimes the attributes associated with an entity set do not include a key A weak entity can be identified uniquely only by considering some of its attributes in conjunction with the primary key of another entity (called identifying owner entity) The following restrictions must hold: ! The owner entity set is a one-to-many to the weak entity (identifying relationship set) ! The weak entity set should have total participation in the identifying relationship set.1. Represented by drawing the relation and the weak entity in thick lines 2–17 Introduction to Database Design (1.

A Weak Entity Set name cost lot pname age ssn Employees Policy Dependents 2–18 Introduction to Database Design (1.1.ca .1) CSC 370 dmgerman@uvic.

1) CSC 370 dmgerman@uvic.Class Hierarchies Sometimes we need to define entities as “derivations” of others (ISA) That is.1.ca . 2–19 Introduction to Database Design (1. the attributes of an entity are those of another entity (its parent) plus other ones A class hierarchy can be seen in two different ways: ! Specialization: identify subsets of an entity that share some distinguishing characteristics ! Generalization: An entity is created that includes several characteristics common to different entity sets.

A Class Hierarchy name ssn lot Employees hoursWorked hourlyWages ISA contractId HourlyEmps ContractEmps 2–20 Introduction to Database Design (1.1.ca .1) CSC 370 dmgerman@uvic.

1) CSC 370 dmgerman@uvic.ca .. Why do we subclass? ! We might want to include attributes that only make sense for the subclass (specialization) ! We might want to identify a set of entities that participate in a given relation (generalization) 2–21 Introduction to Database Design (1.1..Class hierarchies.

Illustrated by drawing a dashed box around the set of related entities and relationships.1.1) CSC 370 dmgerman@uvic. 2–22 Introduction to Database Design (1.Aggregation Sometimes a relationship needs to relate one relationship with a collection of entities or other relationships Aggregation allows us to indicate that a relationship set participates in another relationship set.ca .

name ssn lot Employees Monitors until startedOn since pid pbudget did dname budget Projects Sponsors Departments 2–23 Introduction to Database Design (1.Aggregation.1) CSC 370 dmgerman@uvic.1..ca ..

ca .1.1) CSC 370 dmgerman@uvic.Conceptual Design with the ER Model Developing an ER diagram presents several choices: Should a concept be modelled as an entity or an attribute? Should a concept be modelled as an entity or a relationship? What are the relationship sets and their participating entity sets? Should we use binary or ternary relationships? Should we use aggregation? 2–24 Introduction to Database Design (1.

ca . an attribute should not be an entity unless: ! We need to record the same attribute(s) for more than one entity ! We want to capture the structure of this “attribute” in our ER-diagram 2–25 Introduction to Database Design (1.1) CSC 370 dmgerman@uvic.Entity vs. Attribute It is not always clear what should be an attribute of an entity and what should be moved to a new entity set In general.1.

1) CSC 370 dmgerman@uvic.1. name from lot to did dname ssn budget Employees WorksIn4 Departments 2–26 Introduction to Database Design (1. Attribute..Entity vs..ca .

name dname ssn lot did budget Employees WorksIn4 Departments from Duration to 2–27 Introduction to Database Design (1..Entity vs.ca .1) CSC 370 dmgerman@uvic.1.. Attribute.

Entity vs. Relationship The imprecise nature of ER modelling makes it difficult to recognize when to define an attribute as part of an entity or as part of a relationship The only solution (at this point) is to apply common sense: is the attribute part of the relation.ca . or is it part of the entity? In general.1.1) CSC 370 dmgerman@uvic. a mistake in this stage will lead to wasted storage We will fix this in the future (normalization) 2–28 Introduction to Database Design (1.

Relationship.1.ca .Entity vs.1) CSC 370 dmgerman@uvic... name since lot dbudget did dname ssn budget Employees Manages2 Departments 2–29 Introduction to Database Design (1.

ca .Binary vs.1. the decision is usually determined by any restrictions (integrity constraints) on the relationship that we are trying to model and if we can or cannot do it with a ternary relationship 2–30 Introduction to Database Design (1. Ternary Relationships In cases where we can use either a binary or ternary relationship.1) CSC 370 dmgerman@uvic.

Ternary.1) CSC 370 dmgerman@uvic.1.Binary vs.. name ssn lot pname age Employees Covers Dependents Policies policyId cost • A policy cannot be owned jointly by two or more employees • Every policy must be owned by some employee • Dependents is a weak entity (uniquely identified by policyid and pname) 2–31 Introduction to Database Design (1..ca .

name pname ssn lot age Employees Purchaser Beneficiary Dependents Policies policyId cost 2–32 Introduction to Database Design (1. Ternary.ca .1) CSC 370 dmgerman@uvic.Binary vs..1..

the choice depends on integrity constraints 2–33 Introduction to Database Design (1.1.ca . Ternary Relationships Again.1) CSC 370 dmgerman@uvic.Aggregation vs.

name ssn lot Employees startedOn dname pid pbudget did budget Project Sponsors2 Departments 2–34 Introduction to Database Design (1.1) CSC 370 dmgerman@uvic.1... Ternary.ca .Aggregation vs.