Lecture 2.

Data Models and the Entity-Relationship Data Model Usually, a DBMS is used to store a large amount of data about many different things that are somehow related to each other. We have to be careful how we organize this data, so that we are sure to capture (a) all the information, (b) all the relationships between the data. A very simple example: Student Grade for each course in a DB carried by Academic Records Dept must be one of {A+, A, A, , F, I, PP}. If the clerk types G+ by mistake, the system should disallow that entry.

The Three-Layers of Data Models:

Conceptual Level An organized description of the data, and relationship between data. Examples: ER Models, UML

Representational level Depending on what type of DBMS we need to use, the design of the DB will be different Examples: Relational model, Network/Distributed model

Physical level Where and how will the data be stored physically (e.g. how large is the DB file, which operating system is used)

Steps in the Design of a Data Base:

1. Requirements Collection and Analysis Database Requirements (what information needs to be stored, how much data etc). Functional requirements o o o o Who will access what data (what operations are required, e.g. can we change some data?) Constraints between data; How often will the data be accessed; Security requirements (who can access what part of the data).

2. Conceptual Design & Functional Analysis Conceptual design (e.g. E-R model) High level transaction specification

3. Logical Design Conceptual design is used to construct the actual DB design as it will stored ER Model will be used to design the data storage tables, the queries, views, etc.

4. Physical Design Internal storage structures and file organization are specified

5. Application Program Design and Transactions Design Application development, GUI, FORMS...

EXAMPLE: DB for a small company

The company is organized into departments. Each department has a name, number, and a manager. Each department is located in one or more places. We also store the start date of the department manager.

Each department controls a number of projects. Each project has a name, a number, and is located in a single place.

Employee information: social security number, address, salary, sex, and birth date. Each employee works for one department, but may work on many projects. We allocate the number of hours an employee works on a given project per week. We also record the supervisor of each employee.

Each employee may have a number of dependents. For each dependent, we store: name, where they work, sex, birth date, and relationship to the employee.

Entities and Attributes Most of the data we store describes something: some thing some entity

Thus we first look for each identifiable entity to begin constructing our conceptual model. 1. Entities are specific objects or things in the model space (called Universe of Discourse).

Examples: Employee, Company, Note that Employee is an entity type; each particular employee (e.g. the employee called John Smith) is an instance of the entity type Employee.

2. Attributes: For each entity of a particular type, we can store different types of information. These are called attributes of the entity type. All objects of the same entity type must have the same attributes. Examples: An employee may have attributes such as Name, Address,

In ER Models: each entity must have a value for each of its Attributes.

Entity type

Instance of Entity

Name Address Employee Age Phone

John Smith 55 2311, Kirby, Houston, Texas 713-749-2630

Types of Attributes 1. Simple:The attribute has a single, ATOMIC value Example: SID of a student in a department database; Last name of a person in Personnel records.

2. Composite: The attribute value is composed of several components.

Example: Address

Address Street Address Number

City Apt No

State

Street

KEY ATTRIBUTE: An attribute of an entity type for which the entity must have a UNIQUE value Example: Vehicle ID for a car. A key attribute can be composite. Example: Car-Registration( License Plate Number, State) An entity type may have more than one key Example: The entity CAR: VehicleID, and Registration( License Plate Number, State).

Relationships Often, there are relationships between attributes of different entity types. The design of a Database depends on correctly identifying all such relationships. 1. A relationship relates two or more distinct entities with a specific meaning Example: James Wong manages the Research dept From the relationship, we can infer relationships between entity types. What are the entities in the above example?

What are the corresponding entity types? What is the relationship between the entities?

Relationships of the same type are grouped into a relationship type.

2. The degree of the relationship type is the number of participating entity types.

3. More than one relationship type can exist between same participating entity types. Example: Employee X manages Project Y, and Employee E works-on Project P.

Relationships can have their own attributes.

Employee e1 e2 e3 e4

Works On r1 (5d/wk) r2 (2 d/wk) r3 (3d/wk) r4(1d/wk) r5 (3d/wk)

Project p1 p2 p3 p4

Role: Relationship between entities of same type

Entity: Employee John is the supervisor of Doug Relation: supervises

Supervises

e1 e2 e3

r1 r2 r3

Employee

e4

Structural constraints on Relationships

a. Cardinality ratio: A binary relationship can be 1:1, 1:N, N:1, or N:M

Company

Publishes

Book

- Each book has exactly one publisher - A company may publish 1 or more books

Student

member of

Society

- A student may join one or more societies - A society may have one or more members

b. Participation constraint: Total or partial participation

Student stu1 stu2 stu3 stu4

member of

Society

r1 r2 r3)

soc1 soc2

- some student(s) do not join any society partial participation - each society must have at least one member total participation

Weak Entity Types: Usually, each entity type has some attribute (or combination of attributes) that can uniquely identify each instance. For example, each student in a university has a unique Student ID number (SID), so the SID is a key attribute. Sometimes, an entities type may have no key attributes -- i.e. no combination of attributes can uniquely identify an entity of this type. Such entities are called weak entities. In an ER model, such entities must participate in an identifying relationship type, with an identifying entity type.

Conceptual design of DB: Convert the text description of the information into an ER model. The ER model is a graphical model ( picture); the notations used in ER diagram are as follows:
Symbol Meaning Entity Weak entity Relationship type Identifying relationship type Attribute Key attribute Multi-valued attribute Derived attribute Composite attribute

E1 E1 1

R R N

E2 E2

Total participation E2 in R Cardinality ratio 1:N for E1:E2 in R

Using this notation, we can draw the ER diagram of our simple company DB example (see figure below)

Fname

NoOfEmployees Minit Name Lname Sex N Address Name Salary 1 WORKS_FOR

Number Locations

Bdate SSN

EMPLOYEE

DEPARTMENT

supervisor 1 N SUPERVISION

StartDate 1 1 MANAGES 1 CONTROLS N M WORKS_ON Hrs 1 DEPENDENTS_OF N N

PROJECT
Name Number Location

DEPENDENT

Name

Sex

BirthDate

Relationship

Relationships with Higher Degrees Consider the following example: the DB stores information about how much quantity of what part was supplied by which supplier, to which project. One possibility is to model a ternary (3-ary) relationship as follows:

ProjName

Quantity

SName SUPPLIER

PROJECT

SUPPLY

PART

PartNo
It may be tempting to construct an ER diagram for this information using binary relations:

ProjName
M N

SName
SUPPLIES

PROJECT

SUPPLIER
N

N CAN_SUPPLY USES M M

PART

PartNo

But these two models are not equivalent ! Why ? Theexistence of three pairs, (s1, p1), (j1, s1) and (j1, p1) does not imply an instance of type SUPPLY( s1, p1, j1).