Chapter Three Data Modeling Using The 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.

The Main Phases of Database Design

The 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 (or transactions). 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, and Constraints.

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.

Mini World Requirement Collection And Analysis

Functional Requirements
Functional Analysis High-Level Transaction Specification
DBMS-independent DBMS-specific

Data Requirements
Conceptual Design Conceptual Schema (Ina high-level data model) Logical Design (Data Model Mapping) Logical (Conceptual) Schema

Application Program Design

(In the Data Model of a specific DBMS)

Transaction Implementation Application Programs

Physical Design Internal Schema

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 with

a 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's name, 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.

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.
Address

Street Address City State

ZIP

Number

Street Apartment Number

2- Simple (Atomic) Attributes: that are not divisible are called simple or atomic attributes. For example, City, Number.

Types of Attributes [Continue]

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.

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.

Key Attributes of an Entity Type

An 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 the entity 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 the combination 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.

Value Sets of Attributes

Each 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.

Example of Company Database Design

Mini-world = Company The Database Designers got the Requirements Collection and Analysis: following information after

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 employee
works 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.

10

Entity Weak Entity Relationship

Summary of the Notation for ER Diagrams

Names in ER - Diagram One should choose Names that Convey. We choose 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 in Uppercase Letters, Attribute Names are Capitalized, and Role Names are in Lowercase

Identifying Relationship Attribute Key Attribute

Derived Attribute
Multivalued Attribute

Letters.
Composite Attribute E1 1

R
N
(min, max)

E2

Total Participation of E2 IN R

E1

R R

E2

Cardinality Ratio 1: N for E1:E2 IN R Structural Constraint (min, max) on Participation of E in R

11

An ER Schema Diagram for the COMPANY Database 12

Relationship Types and Sets

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. 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. Employee e1 Works_For r1 r2 r3 r4 r5 r6 d1 d2 d3 . . . . . Department

e2
e3 e4 e5 e6 . .

.
.

13

Relationship Degree
The 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.

14

Supplier s1

An Example of Ternary Relationship

Project j1 j2 r1 r2 r3 j3 . . . . .

s2
s3 s4

Supply

Part

r4 r5 r6

p1 p2 p3

.
.

15

Role Names and Recursive Relationships

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 cases the 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. Employee e1 2 2 1 1 Supervision r1 r2 1 2 1 r3 r4 r5

e2
e3 e4 e5 e6 e7

1 2
2

r6
. .

16

Cardinality Ratios for Binary Relationships

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. 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) but an employee can be related to (work for) only One

17

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.

18

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

Attributes of Relationship Types

Hours per Week for the WORKS_ON relationship type. Another

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

Weak Entity Types

Entity 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.

19