FDatabase-Ch3

8/3/2019 FDatabase-Ch3

1/19

Chapter Three

Data Modeling UsingThe Entity-Relationship

Model

Outlines:-

1) Using High-Level Conceptual Data Models for Database Design.

2) Entity Types, Entity sets, Attributes, and Keys.

3) Relationship Types, Relationship Sets, Roles, and Structural

Constraints.

4) ER Diagrams, Naming conventions, and Design Issues. 1


2/19

The Main Phases of Database DesignThe First Step is requirements collection and analysis. In Parallel

with this, it is useful to specify the known functional requirements of

the application. These consist of the user-defined operations (ortransactions).

The Next Step is called Conceptual Design. The conceptual schema is a

concise description of the data requirements of the users and includes

detailed descriptions of the Entity Types, Relationships, andConstraints.

The Next Step is called Logical Design by using a commercial DBMS.

So the conceptual schema is transformed from the high-level data

model into the implementation data model.The Last Step is the physical design , during which the internal

storage structures, indexes, access paths, and file organizations for the

database files are specified. In parallel with these activities,

application programs are designed and implemented. 2


3/19

3

MiniWorld

Requirement Collection

And Analysis

Data RequirementsFunctional Requirements

Conceptual DesignFunctional Analysis

Logical Design(Data Model Mapping)

Conceptual Schema(Ina high-level data model)

High-Level TransactionSpecification

Logical (Conceptual) Schema(In the Data Model of a specific DBMS)

Physical Design

Internal Schema

Application Program

Design

TransactionImplementation

Application Programs

DBMS-independent

DBMS-specific


4/19

Entities and Attributes

The Entity-Relationship (ER) model use to design Conceptual Schema

and describes data as entities, relationships, and attributes.Entities: The basic object that the ER model represents is an entity,

which is a "thing" in the real world with an independent existence. An

entity may be an object with a physical existence (for example, a

particular person, car, house, or employee) or it may be an object witha conceptual existence (for example, a company, a job, or a university

course).

Each entity has Attributes-the particular properties that describe it.

For example, an Employee Entity may be described by the employee'sname, age, address, salary, and job.

A particular entity will have a value for each of its attributes. The

attribute values that describe each entity become a major part of the

data stored in the database. 4


5/19

5

Types of Attributes

1- Composite Attributes: can be divided into smaller subparts, which

represent more basic attributes with independent meanings.

For example, the Address attribute can be subdivided into Street

Address, City, State, and Zip with the values "2311 Kirby,. The value of

a composite attribute is the concatenation of the values of its

constituent simple attributes. Composite attributes can form a

hierarchy.

2- Simple (Atomic) Attributes: that are not divisible are called simple

or atomic attributes. For example, City, Number.

Address

Street Address City State ZIP

Number Street Apartment Number


6/19

Types of Attributes [Continue]

6

3- Single-Valued Attributes: Most attributes have a single value for

a particular entity; such attributes are called single-valued. For

example, SSN, Age are a single-valued attributes of a person.

4- Multivalued Attributes: In some cases an attribute can have a set

of values for the same entity-for example, a Colors attribute for a

car, or a College Degrees attribute for a person. Cars with one color

have a single value, whereas two-tone cars have two values for Colors.

5- Stored Attributes : The attribute value that related with another

attribute value and can be derive this attribute. For example Birth

date.

6-Derived Attributes: In some cases, two (or more) attribute values

are related-for example, the Age and Birth date attributes of a

person. For a particular person entity, the value of Age can be

determined from the current (today's) date and the value of that

person's Birth Date.


7/197

Entity Types and Entity Sets

A database usually contains groups of entities that are similar. These

entities share the same attributes, but each entity has its own value(s)

for each attribute. An Entity Type defines a collection (or set) of

entities that have the same attributes. Each entity type in the database

is described by its name and attributes.

The collection of all entities of a particular entity type in the database at

any point in time is called an Entity Set; the entity set is usually

referred to using the same name as the entity type.

An entity type describes the schema or intension. The collection of

entities of a particular entity type are grouped into an entity set, which is

also called the Extension of the entity type.


8/198

Key Attributes of an Entity TypeAn important constraint on the entities of an entity type is the key

or uniqueness constraint on attributes. An entity type usually has an

attribute whose values are distinct for each individual entity in theentity set. Such an attribute is called a key attribute, and its values can

be used to identify each entity uniquely.

For the PERSON entity type, a typical key attribute is SSN.

Sometimes, several attributes together form a key, meaning that thecombination of the attribute values must be distinct for each entity.

Some entity types have more than one key attribute. For example, each

of the Vehicle ID and Registration attributes of the entity type CAR is

a key in its own right:CAR Entity

Registration(RegistrationNumber, State), VehiclelD, Make, Model, Year,{Color}

An entity type may also have no key, in which case it is called a weak

entity type.


9/199

Value Sets of AttributesEach simple attribute of an entity type is associated with a value set ,

which specifies the set of values that may be assigned to that attribute

for each individual entity.Value sets are typically specified using the basic data types available in

most programming languages, such as integer, Character, float, date,

currency and others.

Null Values: In some cases a particular entity may not have an applicable

value for an attribute. For example, if the Home phone attribute of a

person is null.


10/1910

1-The company is organized into Departments. Each department has a Unique

name, a Unique number, and a particular employee who manages the department.

We keep track of the Start date when that employee began managing the

department. A department may have several Locations.

2- A department controls a number of Projects, each of which has a Unique

name, a Unique number, and a Single location.

3- We store each Employee's name, Social security number, Address, Salary,

Gender, and Birth date. An employee is assigned to one department but may work

on several projects, which are not necessarily controlled by the same

department. We keep track of the Number of hours per week that an employeeworks on each project. We also keep track of the direct supervisor of each

employee.

4- We want to keep track of the Dependents of each employee for insurance

purposes. We keep each dependent's First name, Gender, Birth date, and

Relationship to the employee.

Example of Company Database DesignMini-world = CompanyThe Database Designers got the following information afterRequirements Collection and Analysis:


11/19

11

Entity

Weak Entity

Relationship

Identifying Relationship

Attribute

Key Attribute

Derived Attribute

Multivalued Attribute

Composite Attribute

RE1 E2 Total Participation of E2 IN R

RE1 E2 Cardinality Ratio 1: N for E1:E2 IN R

R E Structural Constraint (min, max)on Participation of E in R

1 N

(min, max)

Summary of the Notation forER Diagrams

Names in ER - Diagram

One should choose Names that Convey. Wechoose to use Singular Names for entity types,

because the entity type name applies to each

individual entity belonging to that entity type.

In ER diagrams, we will use the convention that

entity type and relationship type names are inUppercase Letters, Attribute Names are

Capitalized, and Role Names are in Lowercase

Letters.


12/19

12An ER Schema Diagram for the COMPANY Database


13/19

13

Relationship Types and Sets

A Relationship Type Ramong nentity types E1, E2,, Endefines a

set of associations or a Relationship Set-among entities from these

entity types. As for the case of entity types and entity sets, a

relationship type and its corresponding relationship set are customarily

referred to by the same name, R.

e1

e2

e3

e4

e5

e6

.

.

Employee

r1

r2

r3

r4

r5

r6

.

.

Works_For

d1

d2

d3

.

.

.

.

.

Department


14/19

14

Relationship DegreeThe number of entity sets that participate in a relationship is called the

degree of the relationship. The three most common degrees of a

relationship in a database are:

1-Unary Relationship (Degree 1): is an association between two

instances of the same entity type. For example relationship between

Employees and Manager.

2-Binary Relationship (Degree 2): is an association between two

instances of two different types. For example relationship between

Employees and Departments.

3-Ternary Relationship (Degree 3): is an association between three

instances of Three different entity types. For example relationship

among Suppliers Projects and Parts.


15/19

15

s1

s2

s3

s4

Supplier

r1

r2

r3

r4

r5

r6

.

.

Supply j1

j2

j3

.

.

.

.

.

Project

p1

p2

p3

.

Part

An Example of Ternary Relationship


16/19

16

Role names are not technically necessary in relationship types where all

the participating entity types are distinct, since each participating

entity type name can be used as the role name. However, in some casesthe same entity type participates more than once in a relationship type

in different roles. In such cases the role name becomes essential for

distinguishing the meaning of each participation. Such relationship types

are called Recursive Relationships.

Role Names and Recursive Relationships

e1

e2

e3

e4

e5

e6

e7

Employee r1

r2

r3

r4

r5

r6

.

.

Supervision

2

1

2

22

22

11

1

1

1


17/19

17

The cardinality ratio for a binary relationship specifies the maximum

number of relationship instances that an entity can participate in.

For example, in the WORKS_FOR binary relationship type,

DEPARTMENT: EMPLOYEE is of cardinality ratio 1:N, meaning that

each department can be related to (that is, employs) any number of

employees. but an employee can be related to (work for) only One

department.

The possible cardinality ratios for binary relationship types are:

(1:1) means (One to One)

(1:N) means (One to Many)

(N:1) means (Many to One)

(M:N) means (Many to Many)

Cardinality Ratios for Binary Relationships


18/19

18

Participation Constraints and Existence Dependencies

The participation constraint specifies whether the existence of an

entity depends on its being related to another entity via the relationship

type. This constraint specifies the minimum number of relationship

instances that each entity can participate in, and is sometimes called the

minimum cardinality constraint.

There are two types of participation constraints (total and partial).

An example for Total participation, An employee entity can exist only if

it participates in at least one WORKS_FOR relationship instance. Total

participation is also called existence dependency.

An example for Partial Participation, some or "part of the set of"employee entities are related to some department entity via MANAGES,

but not necessarily all.

We will refer to the Cardinality Ratio and Participation Constraints,

taken together, as the Structural Constraints of a relationship type.

Att ib t f R l ti hi T


19/19

19

Attributes of Relationship TypesRelationship types can also have attributes. For example, An attribute

Hours per Week for the WORKS_ON relationship type. Another

example, An attribute Start Date for the MANAGES relationship type.

Weak Entity TypesEntity types that do not have key attributes of their own are called

Weak Entity Types. In contrast, regular entity types that do have a

key attribute are called Strong Entity Types.

For example the Dependent is weak entity type in Company database.

we call the relationship type that relates a weak entity type to its

owner the Identifying Relationship of the weak entity type.

A weak entity type always has a total participation constraint (existence

dependency) with respect to its identifying relationship, because a weak

entity cannot be identified without an owner entity.

A weak entity type normally has a Partial Key, which is the set of

attributes that can uniquely identify weak entities that are related to

the same owner entity

Documents

FDatabase-Ch3