Chapter 3Database Design:

Conceptual Design

Introduction

SYS. PLANNING

SYS. ANALYSIS

SYS. DESIGN

SYS. IMPLEMENTATION

Information Gathering

Project Mgt

Feasibility

AnalyzeInformationProces

sModel

sLogical DFD

current & new system

Decision table, decision trees, etc

WFD, AD, etc

Data Model

Input Design

Output Design

Database Design

Process Design

Program Design

PDReport

DSpecReport

E-R Diagram

DFD

DFD

Conceptual Design > Logical Design > Physical

Design

E-R Diagram

Database Design

PhysicalDesign

PhysicalDesign

Conceptual Design

Conceptual Design

Logical Design

Logical Design

Real World Data

DesignDesign

Requirement Analysis

Implementation

abstract

concreate

Make use of:

abstraction mechanism

design methodologies

Mapping

Mapping

Phases of Database Design

Requirements Analysis

Conceptual Design

Logical Design

Physical Design

Application Domain

Database Requirements

Conceptual Schema

Implementation Schema

Physical Schema

DBMSIndependent

DBMSDependent

ANSI-SPARC Three-Level Architecture

DBA should be able to change database storage structures without affecting the users’views.

Internal structure of database should be unaffected by changes to physical aspects of storage.

DBA should be able to change conceptual structure of database without affecting all users.

Differences between Three Levels of ANSI-SPARC Architecture

Database Design & ANSI-SPARC Architecture

Subschema 2

ViewUser 1

ViewUser 2

ViewUser n

Conceptual Schema

Subschema nSubschema 1

Logical Data Model

Conceptual Design

…..

…..

Externallevel

Conceptuallevel

Internallevel

Internal Schema

Logical Design

Physical Design

Conceptual Data Model

Physical Data Model

Steps For Designing Database

Conceptual Design

Logical Design

Physical Design

STEP 1

STEP 2

STEP 3

STEP 4

STEP 5

STEP 6

STEP 7

STEP 8

STEP 9

Methodology Overview -Conceptual Database Design

Step 1 Build local conceptual data model for each user view

Step 1.1 Identify entity typesStep 1.2 Identify relationship typesStep 1.3 Identify and associate attributes with entity or relationship typesStep 1.4 Determine attribute domainsStep 1.5 Determine candidate and primary key attributesStep 1.6 Consider use of enhanced modeling concepts (optional step)Step 1.7 Check model for redundancyStep 1.8 Validate local conceptual model against user transactionsStep 1.9 Review local conceptual data model with user

Methodology Overview - Logical Database Design for Relational

Model (cont)

Step 2 Build and validate local logical data model for each view

Step 2.1 Remove features not compatible with the relational model (optional step)

Step 2.2 Derive relations for local logical data model

Step 2.3 Validate relations using normalization

Step 2.4 Validate relations against user transactions

Step 2.5 Define integrity constraints

Step 2.6 Review local logical data model with user

Step 3 Build and validate global logical data model

Step 3.1 Merge local logical data models into global model

Step 3.2 Validate global logical data model

Step 3.3 Check for future growth

Step 3.4 Review global logical data model with users

Methodology Overview - Logical Database Design for Relational

Model (cont)

Methodology Overview - Physical Database Design for Relational

Databases

Step 4 Translate global logical data model for target DBMS

Step 4.1 Design base relationsStep 4.2 Design representation of derived data Step 4.3 Design enterprise constraints

Step 5 Design physical representationStep 5.1 Analyze transactionsStep 5.2 Choose file organizationStep 5.3 Choose indexesStep 5.4 Estimate disk space requirements

Methodology Overview - Physical Database Design for Relational

Databases (cont)

Step 6 Design user views

Step 7 Design security mechanisms

Step 8 Consider the introduction of controlled redundancy

Step 9 Monitor and tune the operational system

Database Design

The process of creating a design for a database that will support the enterprise’s operations and objectives.

Conceptual Database

Design

The process of constructing a model of the information used in an enterprise, independent of all physical considerations. It includes identification of the important entities, relationships, and attributes.

Logical Database

Design

The process of constructing a model of the information used in an enterprise based on a specific data model, but independent of a particular DBMS and other physical considerations. It translate the conceptual model to the logical structure of the database, which includes designing the relations.(e.g relational model)

PhysicalDatabase

Design

The process of constructing a model of the information used in an enterprise based on a specific data model, but independent of a particular DBMS and other physical considerations. It decide how the logical structure is to be physically implemented (as relations) in the target DBMS.

Conceptual Design

Similar to the analysis phase in software development

produce a description of the data

capture the semantics of the data

Description in a high-level modelclose to the user’s view of the world

abstract concepts

means of communication between the user and the developer

Reasons for Conceptual Design

Independent of DBMS.Allows for easy communication between end-users and developers.Has a clear method to convert from high-level model to relational model.Conceptual schema is a permanent description of the database requirements.

Entity-Relationship Diagram (E-R Diagram)

Entity-Relationship Model

Most popular conceptual model for database design.

Basis for many other models.

Describes the data in a system and how that data is related.

Describes data as entities, attributesand relationships

Database Requirements

We must convert the written database requirements into an E-R diagram

Need to determine the entities, attributes and relationships.

nouns = entities

adjectives = attributes

verbs = relationships

Entities

Entity – basic object of the E-R modelRepresents a “thing” with an independent existence

Can exist physically or conceptuallya professor, a student, a course

Entity type – used to define a set of entities with the same properties.

Entity Type

Strong Entity Type

Entity type that is not existence-dependent on some other entity type.

Weak Entity Type

Entity type that is existence-dependent on some other entity type.

Section CoursePart of

Client PreferenceStates1..1 1..1

ER Diagram of Staff andBranch Entity Types

Entity and Entity Types

EntityNumber: 1123Name: Computer Programming 2Topic: Computer Programming

Entity TypeCourse

NumberNameTopic

Attributes

Each entity has a set of associated properties that describes the entity. These properties are known as attributes.

Attributes can be:

Simple or Composite

Single or Multi-valued

Stored or Derived

NULL

Cont…

NumberNameTopic

Course

AttributesAttribute

Property of an entity or a relationship type.

Attribute Domain

Set of allowable values for one or more attributes.

Simple Attribute

Attribute composed of a single component with an independent existence.

Composite Attribute

Attribute composed of multiple components, each with an independent existence.

Single-valued Attribute

Attribute that holds a single value for each occurrence of an entity type.

Multi-valued Attribute

Attribute that holds multiple values for each occurrence of an entity type.

Derived Attribute

Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity type.

NULL attributes have no valuenot 0 (zero) not a blank stringAttributes can be “nullable” where a null value is allowed, or “not nullable” where they must have a value.

Cont…

Attributes

Simple Composite

Single

Multi-Valued

ProfessorName

First

Last

ProfessorStart_Date

ProfessorEmployeeID#{PK}

ProfessorTel_No [1…3]

Derived Professor/Years_Teaching

Keys

Candidate KeyMinimal set of attributes that uniquely identifies each occurrence of an entity type.

Primary KeyCandidate key selected to uniquely identify each occurrence of an entity type.

Composite KeyA candidate key that consists of two or more attributes.

ER Diagram of Staff and BranchEntities and their Attributes

Relationships

Defines a set of associations between various entitiesCan have attributes to define themAre limited by (constraint in relationship):

ParticipationDetermines whether all or only some entity occurrences participate in a relationship.

Cardinality RatioDescribes maximum number of possible relationship occurrences for an entity participating in a given relationship type.

Cardinality

The number of relationships that an entity may participate in.

Multiplicity as Cardinality and Participation Constraints

Multiplicity of Staff Manages Branch(1:1) Relationship Type

Multiplicity of Staff OverseesPropertyForRent (1:*) Relationship Type

Multiplicity of Newspaper AdvertisesPropertyForRent (*:*) Relationship

ExtendedEntity-Relationship

Diagram (EER Diagram)

Limitations of basic concepts of the ER model and requirements to represent more complex applications using additional data modelingconcepts.

Most useful additional data modelingconcepts of Enhanced ER (EER) model called:

specialization/generalization; aggregation;composition.

Extended E-R Model

Extended E-R Model(cont)

E-R model is sufficient for traditional database applications

Nontraditional applications (CAD, multimedia) have more complex requirements

Can extend traditional E-R diagrams with semantic data modelingconcepts

Specialization / Generalization

SpecializationProcess of maximizing differences between members of an entity by identifying their distinguishing characteristics.

GeneralizationProcess of minimizing differences between entities by identifying their common characteristics.

Specialization Constraints

Disjointness constraint –Describes relationship between members of the subclasses and indicates whether member of a superclass can be a member of one, or more than one, subclass.

May be disjoint or nondisjoint.

Participation constraint –Determines whether every member in superclass must participate as a member of a subclass.

May be mandatory or optional.

Constraints on Specialization / Generalization

There are four categories of constraints of specialization and generalization:

mandatory and disjoint; {mandatory, and }optional and disjoint; {optional, and }mandatory and nondisjoint; {mandatory, or }optional and nondisjoint; {optional, or }

Specialization/Generalization of StaffEntity into Subclasses Representing

Job Roles

Total or Partial ?

disjoint or overlap ?

Specialization/Generalization of StaffEntity into Job Roles and Contracts of

Employment

EER Diagram with Shared Subclass and Subclass with its own Subclass

DreamHome Worked Example - StaffSuperclass with Supervisor and

Manager Subclasses

DreamHome Worked Example -Owner Superclass with PrivateOwner

and BusinessOwner Subclasses

DreamHome Worked Example - PersonSuperclass with Staff, PrivateOwner,

and Client Subclasses

External Level, External Schema,

Conceptual Design, Conceptual Data Model

CASE 1

DreamHome Case Study – An Overview

Pls refer to Connolly, T., Begg, C.(2002).“Database System: A Practical

Approach to Design, Implementation, and Management”, Addision Wesley, USA

Chapter 10, Section 10.4.1, pp 309

First-cut ER diagram for Staff View of DreamHome

Extract from Data Dictionary for Staff View of DreamHome Showing

Description of Relationships

Extract from Data Dictionary for Staff View of DreamHome

Showing Description of Attributes

ER Diagram for Staff View of DreamHome with Primary Keys

Added

Revised ER Diagram for Staff View of DreamHome with Specialization

/ Generalization

Example of a Non-Redundant Relationship FatherOf

Using Pathways to Check that the Conceptual Model Supports the

User Transactions

Questions

Acadia Teaching Database

Design an E-R schema for a database to store info aboutprofessors, courses and course sections indicating thefollowing:

The name and employee ID number of each professorThe salary and email address(es) for each professorHow long each professor has been at the universityThe course sections each professor teachesThe name, number and topic for each course offeredThe section and room number for each course sectionEach course section must have only one professorEach course can have multiple sections