Yunsheng Liu

Yunsheng LiuYunsheng Liu

College of Software, HUSTCollege of Software, HUST2008.112008.11

22Yunsheng LiuYunsheng Liu

7.1 Introduction7.1 Introduction7.1 Introduction7.1 Introduction

1. Generic Objective Data characteristics, application properties and DBMS features are integrated into a DBS by effectively using alternative DB design approaches, techniques and tools

7.1.1 Problems in DB Design7.1.1 Problems in DB Design


Determination and representation of requirements Translation of the requirements into an effective

DB structure Implementation of the DB structure on a particular

computer system Consideration on the implementation in evolution

2. The Main Tasks

7.1.1 Problems in DB Design7.1.1 Problems in DB Design2


3. Design principles1). Matching the application properties and data 1). Matching the application properties and data characteristics with the DBMS features characteristics with the DBMS features 2). Cost/performance tradeoff 2). Cost/performance tradeoff 3). Data integration and structure flexibility3). Data integration and structure flexibility

Information changes Process changes Performance changes System SW/HW changes

Central control of data Sharing data Data availability Data non-redundancy

7.1.1 Problems in DB Design7.1.1 Problems in DB Design


7.1.2 Database Design Methodologies7.1.2 Database Design Methodologies

1. Concept

A methodology is a combination of an

organizational framework/serial steps for

successive DB structure development

projects and a set of techniques and tools

used in the framework /steps sequentially.


Function-based Methodology Data-based Methodology Object-Oriented Methodology

3. Criteria

2. Classification

availability, generality and flexibility, reproducibility

7.1.2 Database Design Methodologies7.1.2 Database Design Methodologies


7.1.3 Generic DB Design Process7.1.3 Generic DB Design Process

1. Overview of DB Design1. Overview of DB Design

Application

Environment

Database Design

Database Design

System Environment

properties

System Environment

propertiesConstraintsConstraints

DBSDB struc.

Appl. guide

Control procedureOp Requi.

Proc. Requi.

Infor. Requi.

Methodologies:Tech. Toots.

Methodologies:Tech. Toots.

Sys. spec.Sys. spec.

Sys. impl.Sys. impl.

DBMS OS


2. Technology Flow2. Technology Flow

AnalysisAnalysis ModelingModeling DesignDesign Implem.Implem.

User’sRequirements

Organization’sInfo. Stru.

DB Data Model

DB Structure

PhysicalDB

Data Relatio

n Theory

Data Relatio

n Theory

Data Modeling Tech.

Data Modeling Tech.

DBMSFeature

s

DBMSFeature

s

Data Organizing

Access



3. Considerations

3). Tech., tools and methods, and evolution

Performance, System environment, Techniques availability Organization (politic, bureaucratic etc)

2). Constraints in aspects:

1). Requirements formulation: Information Function/Process Operation



7.1.4 The DB Design Steps7.1.4 The DB Design Steps

Appli. EnviProperties

ConceptualModeling

Techniques

DBMS Features

Design Tools,Technologies

OS, HWSupport

Appl. Analy&Requi. Determi.

Conceptual Design

Implem. Design

Physical Design

Implementation

Requi. Spec.

Conceptual (E-R) Model

Logical DB Stru., Appl. Spec.

Stored DB stru. Access Methods.Running DBS

Running DBS


1. Data requirementsData in ISP —Information Structure Perspective,

- describing all the natural and conceptual data and the relationships of them in the DB, not just bounded to any processes or applications

- providing flexibility and adaptability

Data in UP —Usage Perspective

- describing all the data and the relationships used in applications, current and estimated known future applications

- providing efficiency

7.2 Requirements Analysis & 7.2 Requirements Analysis & FormulationFormulation7.2 Requirements Analysis & 7.2 Requirements Analysis & FormulationFormulation7.2.1 Types of Requirements


2. Functional/Processing requirements

3. Operational requirements

- representing goal related to the running environment and performance

Consistency and security constraints

Response time constraints

Recovery time constraints

Number of applications supported in simultaneity

7.2.1 Types of Requirements


7.2.2 Tasks and Goals of Requirements Analysis

1. The Main Tasks

Appl. Enviro.AnalysisMetadataCollection

EnterpriseModeling

Appl. Funct.Analysis

RequirementsSpecification


2. The Overall Goals

- Analyzing info. structures and decision process to understand:

(1). The organization’s mechanisms

(2). The scope of the system to be designed

(3). User views of data (business dept.) and data elements in the views

(4). Relationships among the elements

(5). Characteristics and the primary keys of the data



(6). Data processing functions and properties (business activities or applications)(7). Relationships between the functions and the data(8). Operational requirements:

Integrity, Consistency and Security constraints Query modes Response time requests …


2. The Overall Goals


Review the previous developmentsAnalyze existing reports, files,

documents,

display, etc.Questionnaire Interview with all kinds of key users Look into work fields

The Approaches

7.2.3 Application Environment Analysis


7.2.4 Metadata Collection 7.2.4 Metadata Collection

1. Metadata concept

2. Static metadata

- The information of data structure, i.e. definitions

and descriptions of data Naming Constructions Formats Types and lengths

3. Dynamic metadata


Operational requirements Integrity, Consistency and Security Constraints Query modes Response time constraints DB changes in volume and structure

Behavior Usage modes: interactive or preprogramming Operation types and frequencies Interactions among data Message switches etc.

7.2.4 Metadata Collection 7.2.4 Metadata Collection

Two aspects of dynamic metadata


7.2.5 Application Analysis7.2.5 Application Analysis

1. Objectives to determine a variety of applications with their data, and data usages in the applications2. Tasks Analysis Hierarchically to decompose the

applications into function modules . Be performed within one area of business Be authorized as a whole at the same level Be performed as a whole, and no different parts of a task can be performed by different callers or triggering conditions, or within different time slice Utilize the same set of data uniformly



3. Data Analysis —Hierarchically to decompose the data

according to the applications decompositions - Data elements definitions: names, types, lengths, pictures etc. DD - Documenting data structures and formats - Relationships between data E-R-A model4. Identifying —the relationships between the processes and data objects - Operation types, frequencies and data volumes


5. Integrating —respectively, the decomposed data and functions in the different parts are integrated into a completed database structure and an application systematic module structure


● Removing the inconsistencies, such as the same name with different meanings and the same meaning with different names ● Removing the redundancies


7.2.6 Enterprise Modeling7.2.6 Enterprise Modeling

1. Describing the organizational model of the

enterprise—Indicating the system scope

2. Representing a Syst./info. Flows Chart (SFC)

3. Developing a logical model of the system Physical procedures logical processes Human being actions abstract processes Particular implementations of an algorithm the description/representation of the algorithm Operational objectives computations for achieving the objectives


1. Specifying the logical model of the system

with:

7.2.7 System/Requirements 7.2.7 System/Requirements SpecificationSpecification

DFD DD Task IPO chart Data usage matrix

2. DFD Data Flow Diagram

Hierarchy


A Hierarchical DFD SampleA Hierarchical DFD SampleA Hierarchical DFD SampleA Hierarchical DFD Sample

P2

p1

sourceP3 printer

a

b

c d

e

f

g Level 1

D2

D1

h

Level 2d

P3.1

P3.2

P3.3D1 printer

x

yz

g

h D2f


A collection of the information on definitions,

structures and usages of data elements in an DBThe contents: typically

1). General: name, aliases, or synonyms, description

2). Format: type, length, domain, format or picture

3). Structure: parent/subsidiary, location (file, record..)

4). Usage: range of values, frequency of uses, kind

( I/O, global, local)

5). Control: origin, users, authorizations (C, Q, D, I…)

conditions of use( key, Consistency constraints…),

3. DD Data Dictionary


An Example - for defining or finding a data item, you may need to use more than one entry in the DD.

BATCH_STATUS_FILE = {BATCH_JOB_STATUS} BATCH_JOB_STATUS = JOB_ID_NUMBER + JOB_STATUS JOB_ID_NUMBER = JOB_ID + JOB_NUMBER JOB_ID = Char(2), JOB_NUMBER = Number(4) : SALARY = Real(5.2) MEETING_TIME = YY:MM:DD + HH:MN:SS


Local data:Local data:

Input:Input: Output:Output:

Caller:Caller:Called by:Called by:

Process:Process:

IPO CHART-iDIPO CHART-iD

SYSTEM

DESIGNER AUTHORIZER

SUBSYSTEM MODUL

DATE

Notes:Notes:

4. Application spec. Input-Process-Output Chart


D1 D2 Dj Dn

T1 I5, U, Q12, Not Q3, U2

T2 C,

Ti All C, I2, D, U6, Q15

Tm

5. Task-Data Usage Matrix

C, I, D, U, Q — Create, Insert, Delete, Update Q12 —12 times performing Q per time unit


Create Query Insert Update Deiete

D1 V1c N1c V1i N1ii

D2

Di Vic Nic Viu Niu

Dm

6. Data-Operation Relationship Matrix


7.3 Conceptual Design Overview7.3 Conceptual Design Overview

7.3.1 Introduction

1. Concept

- a process to develop a conceptual DB

structure, which is independent of

system specifics, with modeling user

views and then integrating them


2. The Main Tasks

— analyzing and modeling data based on the data

requirements

conceptual data modeling

3. The Objective

— an abstract data representation that is

comprehensible to both users and designers

E-R

7.3.1 Introduction


Management perspective —management view of dataOperation and transaction perspective —processing view of dataStructure perspective —intra- and inter- structures of dataEvent perspective —requirements on time and scheduling of applications

4. Design Considerations

7.3.1 Introduction


Modeling management user views Modeling operation/transaction user views Modeling hierarchical structures and relationships

among data elements Modeling application events—“Wh” ： when, wh

at( tran./op.), which( data),

7.3.2 Approaches and Techniques7.3.2 Approaches and Techniques

1. Entity Analysis —top-down design

1). Modeling the user’s views of data as follows:


2). Modeling entities - Formulating E/R/A 3). Consolidating the user’s views into an integrated conceptual view

2. Attributes Synthesis —bottom-up - Classifying items: Identity (E, R) Description - FD sets

Requirements

Entitiesformulation

Entity-Attr.analysis

Graphicalrepresentation

Classifyingitems

Composingentities

Formulatingrelationships

Relationshipcreation

Entity Modeling

Attributes Synthesis

7.3.2 Approaches and Techniques7.3.2 Approaches and Techniques


7.3.3 Conceptual Design Steps7.3.3 Conceptual Design Steps

Modeling User Views

IntegratingThe Views

Conceptual Model

Development

Conceptual DesignReview

Data Requi. Spec.

1. Steps

2. User views modeling - Based on individual user perspectives: Identify data elements Identify data groups Form relationships among the data elements, intra-groups and inter-groups


3. Views integration - Synthesizing the views into global single structure Remove redundancies Coordinate inconsistencies

4. Conceptual model components Logical data constructs—intra-structures of entities Logical data relationships—inter-structures of entities Logical access map—logical access patches of appli. 5. Conceptual review —for correctness, consistency,

completeness, un-redundancy

7.3.3 Conceptual Design Steps7.3.3 Conceptual Design Steps


Real world

SemanticData ModelsSemantic

Data Models

DBData Models

DBData Models

Computerworld

2. The design process: Semantic modeling Rrelational analysis Logical conversion (to target DM)

1. What

7.4 Semantic Data Analysis and Modeling7.4 Semantic Data Analysis and Modeling

7.4.1 Introduction7.4.1 Introduction


7.4.2 Data Abstractions7.4.2 Data Abstractions

Products

P-name P-typeP-factory

F-name F-address F-phone

Products

P10001 TV LG BT-49’

P21888 T-Shirt XYZ Playboy

2. Classification

- The relationship:

Is-Instance-of

- The relationship: Is-Part-of

1. Aggregation


Products

Machine FabricElectric

Computer TV Refrigerator

Products

Wasteproducts

Excellentproducts

Substandardproducts

Qualifiedproducts

Standardproducts

4. Association

- The relationship: Is-Member-of

- The relationship: Is-a

3. Generalization

7.4.2 Data Abstractions7.4.2 Data Abstractions


7.4.3 E-R Modeling 7.4.3 E-R Modeling

1. Representations of objects in a real world Sometimes, an object in real-world may be represented an entity, a relationship, or even an attributes, depending on designer’s views. Example:

Suppliers

Items

supply

Supply

supplieritem

Items

supplier

Suppliers

item


2. E/R/A selection“noun, verb and adjective” principlePractical rules:

Identifier entity typeProperty if “A is a property of B”, B is an entity

type and A is an attribute of BEvent/action the subjects and objects in an

event or action corresponds to entity types, and

its behavior relates to a relationship type



Optional - General Dependent - Weak entity Conditional - Normalization!

Employee Enterpriseemploy

Employee Honoraward

managerEmployee appoint

3. Relationships Analysis 1). Memberships


2). Identifying — both of the two E’s keys


4. Multi-value relationships: - How to identify? Create a dependent entity type or give a special Id

Teacher Courselecture Teacher Courselecture

5. N-ary relationships: replaced with a “relationship entity”

Supplier

Project

supplyPart

Supplier

Project

SupplyPart



1. General rule: E relation, R relation, A attribute, Id key

2. Conversions of nondeterministic entity types - An entity type with an attribute of repeating group - The repeating group attribute must be converted into a dependent entity for normalization

3. Minimizing the number of relations

7.4.4 Conversion from E-RM to RM


Relations which have a common key should be

merged into a single relationA relation corresponding to an 1:1 relationship type

should be merged into one of the two entity relationsA relation corresponding to an 1:M relationship type

should be merged into the relation corresponding to the entity at M side of the relationship

- Because there exist superfluous attributes in the key, and after removing the superfluous attributes from the key, the relationship relation has the same key as one of the entity at M side of the relationship

7.4.4 Conversion from E-RM to RM


7.5 Relational Analysis7.5 Relational Analysis

7.5.1 Introduction

3. Normal Forms

NF2 1NF 2NF 3NF BCNF

1. What constitute a bad DB design? Redundancies Null values Operation anomalies

2. How to avoid a bad DB design? Normalization

How to normalize? Decompositions


7.5.2 Functional Dependencies7.5.2 Functional Dependencies

1. FD Concepts

Def.: Let R(A) be a relation and X, YA be two attribute sets of R(A). If for any given X-value in R(A), there exists only one corresponding Y-value in R(A), then we say that X functionally determines Y in R(A), notated by XY. And XY is called a functional dependence (FD) of R(A).

● X: determinator of the FD

● Y: dependent of the FD, respectively.


Example

EMPLOYEE#

PROJECT#

WORK-TIME

P-BUDGET

P-NAME



Def.: Let R(A) be a relation and XA be an attribute set of R(A). X is referred as a key of R(A) if the following two predicates are held:

● Ai A ( X∈ Ai )

● ∄X’ X ( Ai A(∈ X’ Ai ） )

2. An alternative definition of a key of a relation



3. Full FD

For R(A), if XY and X’ X ( X’∀ ⊂ ↛KY ), then XY is called a full FD.


WORK-TIME

P-BUDGET

P-NAME EMPLOYEE#

PROJECT#

Example:Example:


A1. If Y X, then X Y. Reflexivity A2. If XY and ZW, then XWYZ Augmentation A3. If XY and YZ, then XZ Transitivity B1. If XY and WYZ, then WXZ pseudotransitivity B2, If XY and WZ, then WXYZ Union B3. If XYZ then XY and XZ decomposition

4. Natures of FDs —Armstrong Beeri Axioms



Example: Let F= {Z↛A ， B↛X ， AX↛Y, ZB↛Y} be a FDS.

Ask if the FD ZB↛Y is redundant ?Yes! Because:

Z↛A ，∴ ZB↛AB （ A2 ）； B↛X and AX↛Y ， ∴ AB↛Y （ B1 ）； ZB↛AB and AB↛Y ， ∴ ZB↛Y （ A3 ）

That is ZB↛Y can be derived by the other FDs in F



1. Definitions: For a relation R(A), 1NF: if AiA (Domain(Ai ) is elementary) hold, then R

is said to be in the first normal form(1NF) 2NF: if R is in 1NF and if every non-prime attribute is fu

lly FD keys of R, then R is said to be in the second normal form(2NF)

3NF: if R is in 2NF and there not exists any FD between non-prime attributes.

BCNF(R. F. Boyce, E. F. Codd): if (XY)SFDC, the smallest closure of FDs over R, X is a superkey of R

7.5.3 Normal Forms7.5.3 Normal Forms


GRADEI-ADDRI-NAMEC-TITLECOUR#MAJORS-NAMESTUD#

92

84

96

68

83

70

…

XYZ1

XYZ2

XYZ3

XYZ2

XYZ1

XYZ3

…

刘军王明华张继业王明华刘军张继业

…

PL

DS

OS

DB

PL

OS

…

CS200

CS360

CS420

CS460

CS200

SF420

….

CST

CST

CST

CST

ISYS

SOFT

…

李文明李文明李文明李文明赵大元刘蓉润

…

2006030074

2006030074

2006030074

2006030074

2007100125

2007110103

…

GRADE-REPORT

Example:Example:



2. Trivial FD: for a FD XY, it is trivial if YX. - The FDs met Reflexivity is trivial3. Lemma: BCFN is stronger than 3NF Proof: Rewrite BCNF: XYSFDCR, one of the followings is true: YX, that is, it is a trivial FD, or K X (K is a key of R) held Rewrite 3NF: XYFDSR, one of the followings is true: YX, that is, it is a trivial FD, or KX ( K is a key of R) held or KY ( K is a key of R) held



3NF

2NF1NF

Removing FD between PA’s

BCNF

Removing partial FD on key

Removing FD between non-PA’s

Removing repeating groups

Non-NF

44. The relationships between NFs. The relationships between NFs



Omission— currently unknownInapplicability—never existing propertyException—un-applicable in a particular case

1. Null values — an operation anomaly - The sources:

7.5.4 Anomalies of DB operations

- The effects: Bring about undefined relational operationsRequiring special processing softwareWasting spaceConvenient to represent record


250

103

24

Price

5800200P-1008181818

158026P-1003133452

190056P-0001123456

BudgetNumberPart#Proj#R:

2. Insertion anomalies Insert( R, 10000, - , - , - , 2000 )

Insert( R, 133452, P-0001, 42, 17 , 2000 )

??

133452 P-0001 42 17 2000

100000 - - - 2000



3. Deletion anomalies Delete( R, 181818, P1008 ) The intention is going to cancel the part p1008. What will be happened ?4. Update anomalies Update( R, 123456, -, -, -, -, budget + 200 ) The intention is going to add 200 to the budget of project 123456 How can we do ? 5. Eliminating the operation anomalies —Decompositions



7.5.5 Decomposition Concept7.5.5 Decomposition Concept

1. Why: Removing redundancy and Normalization

2. What: The process replacing a relation schema R(A) with a collection of subsets Ri (Xi)’s of R(A)

Def.: Let R(A) be a relation schema and Xi⊆A (i=1,2,…,k ） be subsets of the attributes of R. If

R(A)={ R∪ i(Xi) | i=1,2,…,k}

where it is unnecessary that Ri’s be disjoint, then ρ=（ R1, R2, … ， Rk ） is called a decomposition of R.


3. Problems related to decomposition For a relations, we need decompose it ?

- considering the NF of the relation schema What problems does a decomposition cause?

- Lossless-join - Dependency-preservation

Queries may require to join decomposed relations - Trade-off the number of this kinds of queries with potential impacts caused be not decomposing

7.5.5 Decomposition Concept7.5.5 Decomposition Concept


1. Lossless-Join Decomposition(LJ-decomposition)

Def.: If R is a relation schema decomposed into schemas Ri(i=1,2,…,k) and F is an FDS over R, the decomposition is said to be in lossless join (with respect to F) or is a LJ-decomposition (wrt. F) if for any instance r of R, the following format is held:

r = R1(r )⋈R2

(r )⋈…⋈Rk(r )

7.5.6 Lossless Decomposition 7.5.6 Lossless Decomposition


d1p1s3

d3p1s1

d3p1s3

d2p2s2

d1p1s1

DPS

d3p1s3

d2p2s2

d1p1s1

DPSInstance r of RInstance r of R

p1s3

p2s2

p1s1

PS

S,P (r)

d3P1

d2p2

d1p1

DP

P,D (r)

2. Examples

S# Sname phone# city

1000 Smith 12345 Wuhan

1200 John 21434 Beijing

S# Sname Phone#

1000 Smith 12345

1200 John 21434

S# city

1000 Wuhan

1200 Beijing

⋈⋈==

⋈⋈ ==

7.5.6 Lossless Decomposition7.5.6 Lossless Decomposition


3. Theorem: Let ρ=(R1, R2) be a decomposition of R

and F be a FDS over R. ρ is a LJ-decomposition wrt. F iff (R1∩R2)R1 or (R1∩R2)R2 .

4. Rule: For an FD XY over R(A), if X∩Y=, then the decomposition of R into R(A-Y) and R(X,Y) is in lossless join.

5. The existence of LJ-Decompositions For any R(A), there always exists LJ-decomposition

of R(A) into 3NF.

7.5.6 Lossless Decomposition7.5.6 Lossless Decomposition


1. Concepts

- For a R(A) and its FDS, a decomposition of R(A) into two R1(X) and R2(Y) with respect to FDS is Dependency-preserving (DP) if

(FDSX∪FDSY )+ = FDS+

2. For any R(A), there always exists LJ- and DP-de there always exists LJ- and DP-decomposition into 3NF.composition into 3NF.

3.3. For any R(A), there always exists a LJ-decompoFor any R(A), there always exists a LJ-decomposition into BCNF, but it is not ensured that the dsition into BCNF, but it is not ensured that the decomposition is DP ecomposition is DP

7.5.7 Dependency-Preserving Decomposition7.5.7 Dependency-Preserving Decomposition


7615345676李卫国PLC005CS王大国S010

8812345678刘厚DBSC004CS赵一清S003

5122345678纪严明DSC003CS刘华明S001

6512345679张扬名OSC002CS刘华明S001

98

Grade

12345678

Tphone

刘厚Tname

DBDC001CS刘华明S001

CnameC#DeptSname S#

( NF2

)

CS王大国S010

CS赵一清S003

CS刘华明S001

DeptSname S# (3NF )

7615345676李卫国PLC005S010

C004

C003

C002

C001

C#

S003

S001

S001

S001

S#

8812345678刘厚DBS

5122345678纪严明DS

6512345679张扬名OS

9812345678刘厚DBD

GradeTphoneTnameCname

(1NF )

7.5.8 Relation Decompositions


7615345676李卫国PLC005S010

C004

C003

C002

C001

C#

S003

S001

S001

S001

S#

8812345678刘厚DBS

5122345678纪严明DS

6512345679张扬名OS

9812345678刘厚DBD

GradeTphoneTnameCname

( 1NF )

76C001S010

88

51

65

98

Grade

C001S003

C003S001

C002S001

C001S001

C#S#

( 3NF )

12345678刘厚DBSC004

15345676李卫国PLC005

22345678纪严明DSC003

12345679张扬名OSC002

12345678刘厚DBDC001

TphoneTnameCnameC#

( 2NF )


12345678刘厚DBSC004

15345676李卫国PLC005

22345678李事DSC003

12345679张扬名OSC002

12345678刘厚DBDC001

TphoneTnameCnameC#

( 2NF )

李卫国PLC005

刘厚

纪严明张扬名刘厚

Tname

DBSC004

DSC003

OSC002

DBDC001

CnameC#

( 3NF )

15345676李卫国

22345678纪严明12345679张扬名12345678刘厚TphoneTname

( 3NF )



7.6.1 The Objectives and Tasks

7.6 Implementation Design7.6 Implementation Design

1. The overall objective - Mapping the conceptual DB model into a DBMS- processible logical DB structure2. The main tasks Transforming the conceptual DB model into a RDM Normalizing the RDM to avoid to get a bad DB design Developing the schema, subschemas in the DDL of th

e DBMS chosen Developing an application program design guidance


3. Components of Implementation Design

Requi. formulation, Conceptual design

Implementationdesign

Conceptual DB model

Conceptual DB model Access

Requi. spec.Access

Requi. spec.OperationalRequi. spec.OperationalRequi. spec.

Consistencyconstraints

Consistencyconstraints

Volume &Usagequantification


Sys. Envir.Char.

Sys. Envir.Char.DBMS

FeaturesDBMS

Features

Operationalguidance

Operationalguidance DB

SchemaDB

SchemaAppl. Design

guidanceAppl. Design

guidance

Spec. forphysical des.

Spec. forphysical des. SubschemasSubschemas


7.6.2 Steps of Implementation Design7.6.2 Steps of Implementation Design

Logical conversion

Logical DBStructures

Logical DBStructures User-view

StructuresUser-viewStructures

Sub-modelsdesign

DBMSFeaturesDBMS

Features

Applicationsdesign

Defining DB



OperationalRequi. spec.OperationalRequi. spec.

Sys. Envir. Char.

Sys. Envir. Char.

AccessRequi. spec.

AccessRequi. spec.

Conceptual DB modelConceptual DB model

DB Schemaanalysis

Operationalguidance

Operationalguidance

Appl. Designguidance

Appl. Designguidance

DBSchema

DBSchema SubschemasSubschemas



Normalizing


1. Sub-models Design transforming the user views

into data sub-structures. They are: interfaces between the DB and the applications; consistent with the logical DB structures

2. Applications Design developing a specification

for major DB transactions: to support to the applications to outline processes to access required data in the

sub-structures


3. Schema Analysis analyzing and improving the

schema and the subschemas Evaluation on quantitative information the average number of records of each type the frequencies of transactions the average numbers of operations in a transaction the average volume of data accessed in an operation

Performance estimation response time I/O service time


Total bytes in the DB Total bytes transferred by each application

match with the features of the chosen DBMS meet the user’s requirements have any inconsistencies, omissions, errors and

violations of the constraints have a reasonable performance

Review — evaluating whether the schema


- The main tasks and stepsStored records formats designStored records clusteringAccess methods design—selecting suitable AM’sSystem performance estimation

7.7 Physical Design7.7 Physical Design

Query response time Update transaction cost Report generation cost Reorganization frequency and cost Memory and secondary storage space cost

Documents

Yunsheng Liu