Lecture 3

Database Development Process

 Objectives

Definition of terms

Describe system development life cycle

Describing data modeling

1-2
Systems Development Life Cycle
Project Identification
and Selection

Project Initiation
and Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance

1-3
Systems Development Life Cycle (cont.)
Project Identification
and Selection

Project Initiation Purpose --preliminary understanding

and Planning Deliverable –request for project

Analysis

Logical Design

Physical Design

Database activity – enterprise modeling Implementation

Maintenance

1-4
Systems Development Life Cycle (cont.)
Project Identification
and Selection Purpose – state business situation and solution
Deliverable – request for analysis
Project
Project Initiation
Initiation
and
and Planning
Planning

Analysis

Logical Design

Physical Design

Database activity – conceptual data modeling

Implementation

Maintenance

1-5
 Systems Development Life Cycle (cont.)
Project Identification
and Selection Purpose – thorough analysis
Project Initiation
Deliverable – functional system specifications
and Planning

Analysis
Analysis

Logical Design

Physical Design

Database activity – conceptual data modeling

Implementation

Maintenance

1-6
Systems Development Life Cycle (cont.)
Project Identification
and Selection
Purpose – information requirements structure
Project Initiation Deliverable – detailed design specifications
and Planning

Analysis

Logical Design
Logical Design

Physical Design

Database activity –logical database design Implementation

Maintenance

1-7
 Systems Development Life Cycle (cont.)
Project Identification
and Selection

Project Initiation
Purpose – develop technology specs
and Planning Deliverable – program/data structures, technology
purchases, organization redesigns
Analysis

Logical Design

Physical Design

Database activity – physical database design Implementation

Maintenance

1-8
 Systems Development Life Cycle (cont.)
Project Identification Purpose – programming, testing, training, installation,
and Selection documenting
Deliverable – operational programs, documentation,
Project Initiation training materials
and Planning

Analysis

Logical Design

Physical Design

Database activity –database implementation Implementation

Maintenance

1-9
 Systems Development Life Cycle (cont.)
Project Identification
and Selection
Purpose – monitor, repair, enhance
Project Initiation Deliverable – periodic audits
and Planning

Analysis

Logical Design

Physical Design

Database activity – database maintenance Implementation

Maintenance

1 - 10
 Database Design Process

Requirement collection and analysis
DB requirements and functional requirements.
Collects information about users’ needs with
respect to the database system

1 - 11
 Database Design Process

Conceptual DB design using a high-level model
Process of describing the data, relationships between the data, and
the constraints on the data.
After analysis - Gather all the essential data required and understand
how the data are related.
The focus is on the data, rather than on the processes.
Builds a user-oriented representation of the database without any
implementation considerations.
Easier to understand and communicate with others.
The output of the conceptual database design is a Conceptual Data
Model (+ Data Dictionary)

1 - 12
 Database Design Process

Conceptual design: (ER Model is used at this stage.)
What are the entities and relationships in the enterprise?
What information about these entities and relationships
should we store in the database?
What are the integrity constraints or business rules that
hold?
A database `schema’ in the ER Model can be
represented pictorially (ER diagrams).
An ER diagram can be mapped into a relational schema.

1 - 13
 Database Design Process


Logical DB design (data model mapping)
Conceptual schema is transformed from a high-level data
model into implementation data model.
Translates the conceptual schema from the previous phase
into an implementation model common to several DBMSs,
e.g., relational or object-relational

1 - 14
 Database Design Process

Physical DB design

Internal data structures and file organizations for DB are specified.

Customizes the logical schema from the previous phase to a
particular platform, e.g., Oracle or SQL Server.

Specifies how database records are stored, accessed, and related
in order to ensure adequate performance of a database
application

Requires to know the specificities of an application, properties of
data, and usage patterns

1 - 15
 Database Modeling

1 - 16
 Objectives

Definition of terms

Importance of data modeling

Write good names and definitions for entities, relationships,
and attributes

Distinguish unary, binary, and ternary relationships

Model different types of attributes, entities, relationships, and
cardinalities

Draw E-R diagrams for common business situations

1 - 17
 Business Rules

Statements that define or constrain some aspect of the
business

State business structure

Control/influence business behavior

Expressed in terms familiar to end users

Automated through DBMS software

1 - 18
 Scope of Business Rules


We are only concerned with business rules that impact only
organization’s databases

1 - 19
Compare these two rules

Saturday is business casual dress day


An account should have a minimum balance of Tshs ???


Which one will have impact on the database???

1 - 20
 A Good Business Rule is:

Declarative–what, not how

Precise–clear, agreed-upon meaning

Atomic–one statement

Consistent–internally and does not conflict other rules

Expressible–structured, natural language

Distinct–non-redundant

Business-oriented–understood by business people

1 - 21
 Gathering Business Rules

Business rules appear in description of business functions,
events, policies, units, stakeholders and other objects

These descriptions can be found in interview notes, system
requirements collection session, organizational documents
(personnel manuals, policies, contracts, marketing manuals
and technical instructions) and other sources

1 - 22
 Data Definitions


Explanation of a term or fact

Term–word or phrase with specific meaning
e.g. course, section, hostel!!!

Fact–association between two or more terms
e.g. A student may take one or more courses.

1 - 23
 Guidelines for good data definition

Gathered in conjunction with systems requirements

Accompanied by diagrams

Iteratively created and refined

Achieved by consensus

1 - 24
 Systems Modeling
Data Modeling
o One way to structure unstructured problems is to draw models.

o A model is a representation of reality.

o Just as a picture is worth a thousand words, most system

models are pictorial representations of reality.

o Models can be built for existing systems as a way to better

understand those systems.

o For proposed systems as a way to document business

requirements or technical designs.

1 - 25
 Data Modeling
• Data modeling is a technique for defining business requirements for a
database.
• Data modeling is a technique for organizing and documenting a system’s
data.
• Data modeling is sometimes called database modeling because a data
model is usually implemented as a database. It is sometimes called
information modeling.
• Many experts consider data modeling to be the most important of the
modeling techniques.
1 - 26
 Data Models

A data model is a collection of concepts for describing data (precise
description of the data content in a system)

.A schema is a description of a particular collection of data, using a
given data model.

The relational model of data is the most widely used model today.

Main concept: relation, basically a table with rows and columns.

Every relation has a schema, which describes the columns, or
fields.

1 - 27
Types of Data Model

Data model: precise description of the data content in a
system


Types of data models:
1. Conceptual: describes WHAT the system contains
2. Logical: describes HOW the system will be implemented,
regardless of the DBMS
3. Physical: describes HOW the system will be implemented
using a specific DBMS

1 - 28
 Why data model

To aid in the development of a sound database design that
does not allow anomalies or inconsistencies


Goal: to create database tables that do not contain duplicate
data values that can become inconsistent

1 - 29
 Creating an Entity-Relationship Model

1. Identify entities

2. Identify entity attributes and primary keys

3. Specify relationships

1 - 30
 Data Entities

1. Entity

A "thing" about which you want to store data in an application

Multiple examples (instances) of the entity must exist

Goal:
 Store data about each entity in a separate table

 Do not store duplicate data in multiple tables or records


Examples: CUSTOMER, PRODUCT

1 - 31
 Data Model Naming Conventions


Entity names are short, descriptive, compound
word singular nouns

UWEC_STUDENT, CANDY_PRODUCT,

Entity names will ultimately correspond to table names

Why singular?
 Makes more sense when you start talking about

relationships

1 - 32
 Data Entity Instances

Entity instance

A specific occurrence (data value) of an entity

An entity must have multiple entity instances or it is
not really an entity!

Examples: Davey Jones, Celestial Cashew Crunch

1 - 33
 ER Model Attributes
2. Attribute

A characteristic (data field) of an entity that you want
to store in the database
 Examples: CUST_ID, PROD_DESC

Attribute value

The value of a particular attribute for a particular entity
instance

Examples: 42, "Nuts Not Nachos"

1 - 34
 Data Model Naming Conventions (continued)

Attribute names are descriptive compound
words that correspond to the entity name

Attribute names will ultimately correspond to field
names

Every attribute name within the database should
be unique

1 - 35
 Data Model Relationships
3. Relationships


Specify the number of instances of one entity that
can be associated with instances of a related entity

Types:

1:M

1:1

M:M


“M” denotes some value greater than 1 whose
upper bound is undetermined

This is called relationship cardinality
1 - 36
 Example 1:M Relationship

Store Store_ID Store_Name Store_Address

Store_ID 1 Northside 3233 Wisconsin St.
Store_Name 2 Southside 4211 Golf Road
Store_Address

Rents
Video_ID Video_Title Video_Format
Video
1000 The Princess Bride DVD
Video_ID
Video_Title 1001 Sideways Bluray
Video_Format
1002 Just Visiting DVD
1003 Crash Bluray

1 - 37
 Example 1:1 Relationship

Spouse Spouse_ID Spouse_Name

Spouse_ID
52 Ryan, Judy
Spouse_Name
53 Redmann, Rudy
Has

Customer Customer_ Customer_ Customer_Address

Customer_ID ID Name
Customer_Name
1 Ryan, Paul 5454 Hyde Court
Customer_Address
2 Myers, Mary 112 Birch Place

1 - 38
 Example M:M Relationship

Video
Video_ID
Video_Title

Rents

Customer
Customer_ID
Customer_Name
Customer_Address

1 - 39
 Example ER Model

UniversityInstructor ServiceProject
PK InstructorID PK ProjectID

InstructorLastName ProjectDescription
InstructorFirstName ProjectStartDate
InstructorOffice

Advises
Completes

UniversityStudent UniversityCourse
PK StudentID PK CourseID
EnrollsIn
StudentLastName CourseName
StudentFirstName CourseTitle
StudentMI
StudentDOB

1 - 40
 Summary: The Data Modeling Process


Define entities


Define attributes


Define relationships

Identify relationship cardinality (1:1, 1:M, M:M)

1 - 41
Levels of Abstraction
1 - 43
 Data Independence

1 - 44
 ER-Model
• What is systems modeling and what is the difference
between logical and physical system models?
• What is data modeling and what are its benefits?
• Can you recognize and understand the basic concepts and
constructs of a data model?
• Can you read and interpret a entity relationship data model?
• When in a project are data models constructed and where
are they stored?
• Can you discover entities and relationships?
• Can you construct an entity-relationship context diagram?
1 - 45
Entity-Relationship (ER) Modeling.
E-R Model Constructs

Entities:

An entity is a person, place, object, event or
concept in the user environment about which
organization wishes to maintain data

Relationships:

Relationship link between entities


Attribute–property or characteristic of an entity or
relationship type

1 - 46
 Entity-Relationship (ER) Modeling.

Relationship (ER) Diagram


A detailed, logical representation of the entities, associations
and data elements for an organization or business

Notation uses three main constructs


Data entities

Relationships

Attributes

1 - 47
 Entities
Examples of entities:

Person: Employee, Student, Patient

Place: Store, Warehouse

Object: Machine, Product, Car

Event: Sale, Registration, Renewal

Concept: Account, Course
Guidelines for naming and defining entity types:

An entity type name is a singular noun

An entity type should be descriptive and specific

An entity name should be concise

Event entity types should be named for the result of the event,
not the activity or process of the event.
1 - 48
butes
Example of entity types and associated attributes:
STUDENT (Student_ID, Student_Name, Home_Address,
Phone_Number, Major)

Guidelines for naming attributes:


An attribute name is a noun.

An attribute name should be unique

To make an attribute name unique and clear, each attribute
name should follow a standard format

Similar attributes of different entity types should use similar but

1 - 49
distinguishing names.
 Identifier Attributes
Candidate key

Attribute (or combination of attributes) that uniquely identifies
each instance of an entity type

Some entities may have more than one candidate key
 A candidate key for EMPLOYEE is Employee_ID, a second is

the combination of Employee_Name and Address.

 If there is more than one candidate key, need to make a

choice.

Identifier

A candidate key that has been selected as the unique identifying
characteristic for an entity type

1 - 50
 Relationships
• A relationship is a natural business association that exists
between one or more entities.
• The relationship may represent an event that links the entities.
• Conceptually, entities and attributes do not exist in isolation.
• Entities interact with, and impact one another via relationships
to support the business mission.
• A connecting line between two entities on an ERD represents a
relationship.
• A verb phrase describes the relationship.
• All relationships are implicitly bidirectional, meaning that they
can interpreted in both directions.
1 - 51
Degree of Relationships

Degree: number of entity types that participate in a relationship

Three cases

Unary: between two instances of one entity type

Binary: between the instances of two entity types

Ternary: among the instances of three entity types

1 - 52
1 - 53
 ER Model Basics

Key and key attributes:

Key: a unique value for an entity

Key attributes: a group of one or more attributes that uniquely
identify an entity in the entity set

Super key, candidate key, and primary key
Super key: a set of attributes that allows to identify an entity uniquely
in the entity set
Candidate key: minimal super key

There can be many candidate keys

Primary key: a candidate key chosen by the designer

Denoted by underlining in ER attributes

1 - 54
 Sample E-R Diagram

1 - 55
1 - 56
 Basic E-R notation

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
1 - 57
 What Should an Entity Be?


SHOULD BE:

An object that will have many instances in the database

An object that will be composed of multiple attributes

An object that we are trying to model

SHOULD NOT BE:

A user of the database system

An output of the database system (e.g., a report)

1 - 58
 Figure Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

1 - 59
 Classifications of attributes:

Required versus Optional Attributes

Simple versus Composite Attribute

Single-Valued versus Multivalued Attribute

Stored versus Derived Attributes

Identifier Attributes

1 - 60
 Keys

Key–An attribute (or combination of attributes) that
uniquely identifies individual instances of an entity
type

Simple versus Composite key

Candidate Key–an attribute that could be a key…
satisfies the requirements for being an identifier

1 - 61
 Keys

A key is a data item that allows us to uniquely identify individual
occurrences or an entity type.

A candidate key is an attribute or set of attributes that uniquely
identifies individual occurrences or an entity type.

An entity type may have one or more possible candidate keys, the
one which is selected is known as the primary key.

A composite key is a candidate key that consists of two or more
attributes

The name of each primary key attribute is underlined.

1 - 62
 Characteristics of Keys


Will not change in value

Will not be null

No intelligent keys (e.g., containing locations or
people that might change)

Substitute new, simple keys for long, composite keys

1 - 63
 Figure A composite attribute

An attribute
broken into
component parts

Figure Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed
and current
date
1 - 64
 Figure Simple and composite key attributes

The key is boldfaced and underlined

1 - 65
 Relationships

A relationship type is a meaningful association
between entity types

A relationship is an association of entities where
the association includes one entity from each
participating entity type.

Relationship types are represented on the ER
diagram by a series of lines.

As always, there are many notations in use today...

1 - 66
 More on Relationships

Relationship Types vs. Relationship Instances

The relationship type is modeled as lines between entity
types…the instance is between specific entity instances

Relationships can have attributes

These describe features pertaining to the association between
the entities in the relationship

Two entities can have more than one type of relationship between
them (multiple relationships)

Associative Entity–combination of relationship and entity

1 - 67
 Figure Relationship types and instances

a) Relationship type

b)
Relationship
instances

Employee may complete any number of courses and a given course may
be completed by any number of employees
1 - 68
 Degree of Relationships

Degree of a relationship is the number
of entity types that participate in it

Unary Relationship

Binary Relationship

Ternary Relationship

1 - 69
 Degree of relationships

Entities of two
One entity different types
related to related to
another of the each other Entities of three
same entity different types
type related to each
other
1 - 70
Degree of a Relationship cont...

It is possible to have a n-ary relationship (e.g. quaternary or unary).

Unary relationships are also known as a recursive relationship.

m a na g es

E m p lo yee

It is a relationship where the same entity participates more than once in different
roles.

In the example above we are saying that employees are managed by employees.

If we wanted more information about who manages whom, we could introduce a
second entity type called manager.
 Degree of a Relationship cont...


If there are two entity types involved it is a binary relationship type

manage s
M anage r Employe e


If there are three entity types involved it is a ternary relationship
type
Sale s s e lls
A s s is tant Pro duct

C us to me r
Replacing ternary relationships

When ternary relationships occurs in an ER model they should

always be removed before finishing the model. Sometimes the
relationships can be replaced by a series of binary relationships that
link pairs of the original ternary relationship.

Sales sells
A ssistant Product

assists C ustomer buys

Replacing ternary relationships

This can result in the loss of some information - It is no longer
clear which sales assistant sold a customer a particular product.

Try replacing the ternary relationship with an entity type and a
set of binary relationships.
Replacing Ternary relationships
cont...
Relationships are usually verbs, so name the new entity type by the
relationship verb rewritten as a noun.

The relationship sells can become the entity type sale.

Sales Sale Product

Assistant m akes involves

requests Custom er


So a sales assistant can be linked to a specific customer and both of
them to the sale of a particular product.

This process also works for higher order relationships.
 Cardinality

Most relationships are not one-to-one

For example, a manager usually manages more than one
employee

This is described by the cardinality of the relationship, for which
there are four possible categories.

One to one (1:1) relationship

One to many (1:m) relationship

Many to one (m:1) relationship

Many to many (m:n) relationship

On an ER diagram, if the end of a relationship is straight, it
represents 1, while a "crow’s foot" end represents many.

1 - 76
 Cardinality of Relationships

One-to-One

Each entity in the relationship will have exactly one related entity

One-to-Many

An entity on one side of the relationship can have many related
entities, but an entity on the other side will have a maximum of
one related entity

Many-to-Many

Entities on both sides of the relationship can have many related
entities on the other side

1 - 77
Cardinality Constraints

Cardinality: refers to minimum and maximum number of times that the
entity may participate in the relationship type

Cardinality Constraints - the number of instances of one entity that can or
must be associated with each instance of another entity

Minimum Cardinality

If zero, then optional

If one or more, then mandatory

Maximum Cardinality

The maximum number

1 - 78
 Figure Examples of relationships of different degrees (cont.)

b) Binary relationships

1 - 79
 Figure Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have

recorded for one and recorded at least one
only one patient history, and can have
1 - 80 many
Figure Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be

assigned to at least one assigned to any number of
employee, and may be projects, or may not be
assigned to many assigned to any at all

1 - 81
 Figure Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is married
to at most one other
person, or may not
be married at all

1 - 82
 Figure Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

1 - 83
 Strong vs. Weak Entities, and
Identifying Relationships

Strong entities

exist independently of other types of entities

has its own unique key

key underlined with single-line

Weak entity

dependent on a strong entity (identifying owner)…cannot
exist on its own

does not have a unique key (only a partial key)

Partial key underlined with double-line

Entity box has double line

Identifying relationship

1 - 84

links strong entities to weak entities
 Weak Entities

A weak entity can be identified uniquely only by considering the primary
key of another (owner) entity.
 Owner entity set and weak entity set must participate in a one-to-many
relationship set (one owner, many weak entities).
 Weak entity set must have total participation in this identifying relationship set.

1 - 85
 Identifying relationship

Strong entity Weak entity

• A weak entity is one that can only exist when owned by another one. For example: a
ROOM can only exist in a BUILDING. On the other hand, a TIRE might be considered
as a strong entity because it also can exist without being attached to a CAR.
 Associative Entities

An entity–has attributes

A relationship–links entities together

When should a relationship with attributes instead be an associative
entity?

All relationships for the associative entity should be many

The associative entity could have meaning independent of the other
entities

The associative entity preferably has a unique key, and should also
have other attributes

The associative entity may participate in other relationships other than
the entities of the associated relationship

Ternary relationships should be converted to associative entities
1 - 87
 Figure A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the relationship

1 - 88
 Figure An associative entity (CERTIFICATE )

Associative entity is like a relationship with an attribute, but it is also

considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in Figure has

been replaced by two one-to-many relationships with the associative
entity.
1 - 89
 Figure Ternary relationship as
an associative entity

1 - 90