1

CSBP430 – Database Systems

Chapter 16: Practical Database Design and Tuning

Elarbi BadidiCollege of Information TechnologyUnited Arab Emirates Universityebadidi@uaeu.ac.ae

2

The Information System

Database Carefully designed and constructed repository of facts Part of an information system

Information SystemProvides data collection, storage, and retrievalFacilitates data transformationComponents include:

– People– Hardware– Software

– Database(s)– Application programs– Procedures

3

Information System Life CycleSystem Development Life Cycle (Macro Life Cycle)

Feasibility analysis: This phase is concerned with analyzing potential application areas, identifying the economics of information gathering and dissemination, performing preliminary cost-benefit studies, and determining the complexity of data and processes. Requirements collection and analysis: Detailed requirements are collected by interacting with potential users and user groups to identify their particular problems and needs. Design: This phase has two aspects: the design of the database system, and the design of the application systems (programs) that use and process the database. Implementation: The information system is implemented, the database is loaded, and the database transactions are implemented and tested. Validation and acceptance testing: The system is tested against performance criteria and behavior specifications. Deployment, operation and maintenance: The operational phase starts when all system functions are operational and have been validated. Monitoring of system performance and system maintenance are important activities during the operational phase.

4

Database Lifecycle (DBLC) Micro Life Cycle

5

Overview of the Methodology

AnalysisSpecificationDesignImplementation

1

2

3

4

InformationFlow

Diagram1

2b 3b 4b

2a 3a 4a

Tasks

ERDiagram

RelationalSchema

AbstractCode

w/SQL

RelationalPlatform

3GL Codew/SQL

6

Phase 1: Database Initial Study

(Requirements Collection and Analysis)

7

Phase 1: Database Initial Study

Purposes

Analyze company situation• Operating environment• Organizational structure

Define problems and constraintsAnalyze and study existing documentation concerning the application (forms, reports, policy manual).Analyze the expectations of the usersDetermine system requirementsDefine objectivesDefine scope and boundariesAnalyze flow of information

8

Phase 1: Database Initial Study

Analysis

Input:descriptions of documents and tasks; scenarios; usage statistics; plans for the future system; relevant laws, constraints, and policies

Output:Information Flow Diagram (IFD) modeling, external documents, internal documents, tasks, and system boundary.

Techniques:interviews with people at all levels of the enterpriseanalysis of documents, scenarios, tasksreviews of short and long-term plans, manuals, files, and formsabstraction

Tools:Information Flow Diagrams

9

Information Flow Diagram

D1

T1

T2T3

Database

D2

D6

D3

D5

D4

T4

documentname

taskname information

flowsystem boundary

10

Example: Information Flow Diagram

ProcessCheck-in

Check-In Reservation/CancellationTicket

Assign Planes

BoardingPass

Create Flight Inst

FlightSchedule

Airplanes

Airports

Inquiry

MakeReservation/Cancellation

AnswerInquiry

EnterAirports

CreateFlight Inst

Enter FlightSchedule

AssignPlanes

EnterPlanes

DB

Passengerlist

11

Phase 2: Database Design

12

Phase 2: Database Design

Database Design

Most Critical DBLC phaseMakes sure final product meets requirementsFocus on data requirementsSubphases

Create conceptual database designCreate logical database design (Data Model Mapping)Create physical database designDBMS software selection

13

Phase 2: Database Design

Database Design (Con’t.)

Purpose:create detailed design of normalized relational database schemacreate detailed design of tasks using abstract code with embedded SQLidentify need for views

Input:Analysis Report, IFD.

Output:relational schema w/primary and foreign keys, constraint definitions in SQL, abstract code w/SQL, view definitions

Techniques:database normalization; abstract coding

Tools:mapping: ER-Model Relational Modelabstract code; SQL; views

14

Database Design (Con’t.)

15

Phase 2: Database Design

I. Conceptual Database Design

Conceptual schema design:Data modeling creates abstract data structure to represent real-world itemsHigh level of abstractionThree steps• Data analysis and requirements• Entity relationship modeling and normalization• Data model verification

transaction design: Design the database transaction• Retrieval transaction, update transaction, mixed

transaction

16

Phase 2: Database Design

Data analysis and Requirements

Focus on:Information needsInformation usersInformation sourcesInformation constitution

Data sourcesDeveloping and gathering end-user data viewsDirect observation of current systemInterfacing with systems design group

Business rules

I. Conceptual Database Design

17

Phase 2: Database Design

Entity Relationship Modeling and Normalization

I. Conceptual Database Design

18

Phase 2: Database Design

Example ER-Diagram

City Airport

Name

State

AirportCode

AirportsAirport Code Name City State

- - - - - - - -

I. Conceptual Database Design

19

City Airport

Name

State

AirportCode From

To

Flt Schedule

Flt Instance

Atime

Date

DtimeAirline

Price

Miles

Flt#

Assigned

Customer

Airplane

Plane# PlaneType

Weekday

InstanceOf

Total#Seats

Reser-Vation

#AvailSeats

CustomerAddress

Street

State

City

Zip

CustomerName

Middle

First

Last Cust#Phone#

Check-InStatus

Seat#

1

1

1

1

n

n

n

n

n

n

Example ER-Diagram

Ticket#

20

E-R Modeling is Iterative

21

Phase 2: Database Design

DB Design Strategy Notes

Top-down (Fig 16.2 page 540)1) Identify data sets2) Define data elements

Bottom-up (Fig 16.3 page 541)1) Identify data elements2) Group them into data sets

I. Conceptual Database Design

22

Phase 2: Database Design

Top-Down vs. Bottom-Up

I. Conceptual Database Design

23

Phase 2: Database Design

II. DBMS Software Selection

DBMS software selection is critical Advantages and disadvantages need studyFactors affecting purchasing decision

Cost (software, maintenance, hardware, training, etc)DBMS features and toolsUnderlying modelPortabilityDBMS hardware requirements

24

Phase 2: Database Design

III. Logical Design (Data Model Mapping)

Translates conceptual design into internal model Maps objects in model to specific DBMS constructsDesign components

TablesIndexes ViewsTransactionsAccess authoritiesOthers

25

Phase 2: Database Design

IV. Physical Design

Choose specific storage structure and access paths

Very technicalMore important in older hierarchical and network modelsIndexing, clustering of related records on disk, linking related records via pointers.

Designers favor software that hides physical details

26

Phase 3: Implementation and Loading

27

Phase3: Implementation and Loading

Implementation and Loading

Creation of special storage-related constructs to house end-user tablesData loaded into tablesOther issues

PerformanceSecurityBackup and recoveryIntegrityCompany standardsConcurrency controls

28

Phase3: Implementation and Loading

Implementation

Input:relational schema w/primary and foreign keys, data representation, constraints in SQL, abstract code w/SQL, task decompositions, view definitions

Output:conceptual schema, internal schema, host-language code w/embedded SQL

Tools:SQL, host-languagerelational database management system, pre-compilerhost-language compiler

29

Example Conceptual Schema Implementation

CREATE DOMAIN AIRPORT-CODE CHAR(3)CREATE DOMAIN FLIGHTNUMBER CHAR(5);CREATE DOMAIN WEEKDAY CHAR(2)

CONSTRAINT DAYS CHECK ( VALUE IN(‘MO’,’TU’,’WE’,’TH’,’FR’,’SA’,’SU’));

CREATE TABLE FLT-SCHEDULE(FLT# FLIGHTNUMBER NOT NULL,AIRLINE VARCHAR(25),DTIME TIME,FROM-AIRPORTCODE AIRPORT-CODE,ATIME TIME,TO-AIRPORTCODE AIRPORT-CODE,MILES SMALLINT,PRICE DECIMAL(7,2),PRIMARY KEY (FLT#),FOREIGN KEY (FROM-AIRPORTCODE) REFERENCES AIRPORT(AIRPORTCODE),FOREIGN KEY (TO_AIRPORTCODE) REFERENCES AIRPORT(AIRPORTCODE));

30

Example Conceptual Schema Implementation CREATE TABLE FLT-WEEKDAY(FLT# FLIGHTNUMBER NOT NULL,WEEKDAY WEEKDAY,UNIQUE(FLT#, WEEKDAY),FOREIGN KEY (FLT#) REFERENCES

FLT-SCHEDULE(FLT#));

CREATE TABLE FLT-INSTANCE(FLT# FLIGHTNUMBER NOT NULL,DATE DATE NOT NULL,PLANE# INTEGER,PRIMARY KEY(FLT#, DATE),FOREIGN KEY FLT# REFERENCES

FLT-SCHEDULE(FLT#),FOREIGN KEY PLANE# REFERENCES AIRPLANE(PLANE#));

31

Example Task Implementation some C code

Direct-Flights T1.1/* read(Inquiry, :Departure-Airport, :Arrival-Airport,:Date); *//* convert :Date to :Weekday; */ more C code

EXEC SQL WHENEVER NOT FOUND GOTO endloop; more C code

EXEC SQL DECLARE DIRECT-FLIGHTS CURSOR FOR SELECT FROM-AIRPORTCODE, TO-AIRPORTCODE, FLT-SCHEDULE.FLT#, DTIME, ATIME FROM FLT-SCHEDULE, FLT-WEEKDAY WHERE FLT-SCHEDULE.FLT#=FLT-WEEKDAY.FLT# AND FROM-AIRPORTCODE=:Departure-Airport AND TO-AIRPORTCODE=:Arrival-Airport AND WEEKDAY=:Weekday ORDER BY DTIME; more C code

EXEC SQL OPEN DIRECT-FLIGHTS;while EXEC SQL FETCH DIRECT-FLIGHTS INTO :From, :To, :Flt#, :Dtime, :Atime; write(Inquiry, :From, :To, :Flt#, :Date, :Dtime, :Atime) endwhile; more C code

endloop:Exec SQL CLOSE DIRECT-FLIGHTS;

32

Phase 4: Testing and Evaluation

33

Testing and Evaluation

Database is tested and fine-tuned for performance, integrity, concurrent access, and security constraintsDone in parallel with application programmingActions taken if tests fail

Fine-tuning based on the DBMS reference manualsModification of physical designModification of logical designUpgrade or change DBMS software or hardware

34

Phase 5: Operation

35

Operation

Database considered operationalStarts process of system evaluationUnforeseen problems may surfaceDemand for change is constant

36

Phase 6: Maintenance and Evaluation

37

Maintenance and Evaluation

Preventative maintenanceCorrective maintenance Adaptive maintenanceAssignment of access permissions Generation of database access statistics to monitor performancePeriodic security audits based on system-generated statisticsPeriodic system usage-summaries