Chapter 7:

Modeling Data in the Organization

Dr. Taysir Hassan Abdel Hamid

IS Department

Faculty of Computer and Information

Assiut University

March 8, 2015

Outline

More on ERD

An Example Database Application

1. The company database keeps track of a company’s employees, departments, and projects.

2. The company is organized into departments: Each department has a unique number, a unique name, and an employee who manages the department.

3. A department controls a number of projects, each of which has a unique names, a unique number, and a single location.

4. We store each employee’s name, social security number, address, salary, gender and birth date.

5. Keep track of dependents of each employee for insurance purposes.

Phases of Database Design (Cont.)

Physical Design

Logical (Conceptual) Schema (In the

data model of a specific DBMS)

Conceptual Schema

(in high-level data model)

Application Program

Design

High-level Transaction Specification

Logical Design

(Data Model Mapping)

DBMS-independent

DBMS-specific

Internal Schema Transaction Implementation

Application Programs

Keys

Primary Key: The primary key of a relational table uniquely identifies each record in the table.

It can either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a table with no more than one record per person) or it can be generated by the DBMS (such as a globally unique identifier, or GUID, in Microsoft SQL Server).

Keys (Cont…)

Foreign Key: A foreign key is a field in a relational table that matches the primary key column of another table.

The foreign key can be used to cross-reference tables.

Candidate Key: A candidate key is a combination of attributes that can be uniquely used to identify a database record without any extraneous data.

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

An Entity I.e. An object

With a physical existence

Or a conceptual existence

Part of the ER Model

College

Degree

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

Part of the ER Model

College

Degree

See Fig. 3.2

An Attribute

Each Entity has its own attributes that describe its properties

Entity Types, Entity Sets, Attributes, and Keys (Cont.)

Types of Attributes:1. Composite versus Simple (Atomic) Attributes

2. Single-Valued versus Multivalued Attributes

3. Stored versus Derived Attributes

4. Null Values

5. Complex Attributes

1. Composite versus Simple Attributes

Number

Address

StreetAddress City

Street Apartment_Number

State Zip

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

2. Single-Valued vs Multivalued Attributes

College

Degree

Multivalued

One person can have:

No degree

More than 2 degrees

Single-Valued

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

3. Stored vs Derived Attributes

College

Degree

Stored

Value of Age (derived attribute) can be determined

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

College

Degree

Key attribute

Key attribute can be a combination of attribute values

4. Null Values

A particular entity may not have an application value for an attribute.

For example,

Address

StreetAddress City

Street Apartment_Number

State Zip

Number ????

Composite attributes and multivalued attributes can be nested arbitrarily.

Example: AddressPhone

{AddressPhone ( { Phone (AreaCode, PhoneNumber) },

Address (StreetAddress(Number, Street, ApartmentNumber), City, State, Zip) ) }

() A Composite attribute

{ } Displaying multivalued attributes

Example: A person can have more than one residence and each residence can have multiple phones, an attribute AddressPhone for a person.

5. A Complex Attribute:

Entity Types, Entity Sets, Keys, and Value Sets

An Entity Type: defines a collection (or set) of entities that have the same attributes

Employee

E1

Ahmed, 55, 30k

E2

Amr, 45, 20k

Entity Sets

c1ITWORKS, Cairo

C2

Sakhr, Alex

CompanyEntity Names

Entity Sets: The collection of all entities of a particular entity type in the database at any point in time is called an entity set.

Example: EMPLOYEE refers to both a type of entity as well as the current set of all employee entities in the database.

Entity Types, Entity Sets, Keys, and Value Sets (Cont.)

Key Attributes of an Entity Type: An important constraint on the entities of an entity type is the key or uniqueness constraint on attributes

A Key attribute has its values that can be used to identify each identity uniquely.

Sometimes several attributes form a key. An entity type that has no key is called a

weak entity type

Entity Types, Entity Sets, Keys, and Value Sets (Cont.)

CAR

Vehicleid

Registration

Number State

Year

Color

Model

Make

CAR entity type with two key attributes

CAR1

((ABC 123, Cairo), Cairo123, Fiat128, 2003 {white, blue})

Initial Conceptual Design of the COMPANY Database

Department Name, Number, {Locations}, manager, ManagerStartDate

Project Name, Number, Location, ControllingDept

Employee Name(Fname, Minit, Lname), SSN, Gender, Address, Salary

BirthDate, Department, Supervisor, {WorksOn(Project, Hours)}

Dependent Employee, DependentName, Gender, BirthDate, Relationship

Fig. 1

Multivalued

Composite Attribute

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

Supervisor

Works_on

Project Hours

Dependent

Relationship Gender

Employee

Ssn

Bdate NumberName

Controll_dept

Location Project

Department

Number Name

Locations

Manager_sd

Relationship Types, Sets, and Instances

A relationship type R among n entity types E1

, E2, …, En defines a set of associations or a relationship set – among entities from these entity types.

The relationship R is a set of relationship instances ri , where each ri associates n individual entities (e1, e2, …, en ) and each entity ej in ri is a member of entity type Ej ,

1 ≤ j ≤ n.

Relationship between Employee and Department

d1

d2

e1

e2

e3

r1

r2

r3

Works_FORDepartment

Employee

Degree of a Relationship Type

The degree of a relationship type is the number of participating entity types

e1

e2

e3

Employee

r1

r2

r3

Works_FOR

d1

d2

Department

Binary Degree

s1

s2

s3

Supplier

r1

r2

r3

Supply

d1

d2

Project

Ternary Degree

p1

p2

p3

PART

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

2. Recursive Relationships

College

Degree

SupervisionSupervisee

Supervisor

Relationships as attributes:

e1

e2

e3

Employee

r1

r2

r3

Works_FOR

d1

d2

Department

Constraints on Relationship Types

Cardinality ratios for binary relationships: specifies the maximum number of relationship instances that an entity can participate in.

e1

e2

e3

Employee

r1

r2

r3

Works_FOR

d1

d2

Department

A 1:N cardinality ratio

Constraints on Relationship Types (Cont.)

e1

e2

e3

Employee

r1

r2

r3

MANAGES

d1

d2

d3

Department

A 1:1 cardinality ratio

Constraints on Relationship Types (Cont.)

e1

e2

e3

Employee

r1

r2

r3

WORKS_ON

p1

p2

p3

Project

A M:N cardinality ratio

Employee

Salary Address Gender

Name

Lname Minit

Fname

Ssn

Bdate

Recursive Relationships

College

Degree

SupervisionSupervisee

Supervisor N1

Initial Conceptual Design of the COMPANY Database

Department Name, Number, {Locations}, manager, ManagerStartDate

Project Name, Number, Location, ControllingDept

Employee Name(Fname, Minit, Lname), SSN, Gender, Address, Salary

BirthDate, Department, Supervisor, {WorksOn(Project, Hours)}

Dependent Employee, DependentName, Gender, BirthDate, Relationship

Fig. 1

Refining the ER Design for the COMPANY Database

Change attributes that represent relationships into relationship types:

1. MANAGES, a 1:1 relationship type between Employee and Department.

2. Works_FOR, a 1:N relationship between Employee and Department

3. CONTROLS, a 1:N relationship type between Department and Project.

4. SUPERVISION, a 1:N relationship type between Employee and Employee.

5. Works_ON, a M:N relationship type with attribute Hours.

6. Dependents_of, a 1:N relationship type between Employee and Dependent.

The numbers mean that for each entity e in E, e must participate in at least min and at most max relationship instances in R at any point in time.

UML will be discussed later in details

Summary of Notations Used

Entity

Weak Entity

Relationship

Identifying relationship

Attribute

Summary of Notations Used (Cont.)

Key Attribute

Multivalued Attribute

Derived Attribute

Composite Attribute

Design Techniques

1. Avoid redundancy.

2. Limit the use of weak entity sets.

3. Don’t use an entity set when an attribute will do.

Avoiding Redundancy

Redundancy = saying the same thing in two (or more) different ways.

Wastes space and (more importantly) encourages inconsistency. Two representations of the same fact become

inconsistent if we change one and forget to change the other.

Recall anomalies due to FD’s.

Consider a hospital:

Patients are treated in a single ward by the doctors assigned to them. Usually each patient will be assigned a single doctor, but in rare cases they will have two.

Heathcare assistants also attend to the patients, a number of these are associated with each ward.

Initially the system will be concerned solely with drug treatment. Each patient is required to take a variety of drugs a certain number of times per day and for varying lengths of time.

Consider a hospital: (Cont…)

The system must record details concerning patient treatment and staff payment. Some staff are paid part time and doctors and care assistants work varying amounts of overtime at varying rates (subject to grade).

The system will also need to track what treatments are required for which patients and when and it should be capable of calculating the cost of treatment per week for each patient (though it is currently unclear to what use this information will be put).

How do we start an ERD?

1. Define Entities: these are usually nouns used in descriptions of the system, in the discussion of business rules, or in documentation;

2. Define Relationships: these are usually verbs used in descriptions of the system or in discussion of the business rules

3. Add attributes to the relations; these are determined by the queries,and may also suggest new entities, e.g. grade; or they may suggest the need for keys or identifiers.

What questions can we ask?

a. Which doctors work in which wards?

b. How much will be spent in a ward in a given week?

c. How much will a patient cost to treat?

d. How much does a doctor cost per week?

e. Which assistants can a patient expect to see?

f. Which drugs are being used?

4. Add cardinality to the relations Many-to-Many must be resolved to two

one-to-manys with an additional entity Usually automatically happens Sometimes involves introduction of a link

entity (which will be all foreign key) Examples: Patient-Drug

5. This flexibility allows us to consider a variety of questions such as:

a. Which beds are free?

b. Which assistants work for Dr. X?

c. What is the least expensive prescription?

d. How many doctors are there in the hospital?

e. Which patients are family related?

6. Represent that information with symbols. Generally E-R Diagrams require the use of the following symbols: