Database Systems: Design, Implementation, and Management

Chapter 6DatabaseDesign

DatabaseSystems:Design, Implementation,AndManagement

Peter Rob &Carlos Coronel 1

Database Systems: Design, Implementation, and Management

Database Systems: Design, Implementation, and Management

CHAPTER 6

Database Design




The Systems Development Life CycleThe Systems Development Life Cycle

The Systems Development Life Cycle (SDLC) provides a methodology for developing an IS.

Database design takes place within the confines of an IS.

Five phases of SDLC: Planning Analysis Design Implementation Maintenance

SDLC is an iterative process




SDLCSDLC

Planning

Analysis

Design

Implementation

Maintenance

• Enterprise-wide requirement assessment• Identification of IS projects• Feasibility assessment and prioritization

• User requirement analysis for a specific project• Requirement modeling (conceptual)

• Detailed design • Specification development

• Coding, testing and evaluation• Installation

• Daily operation and maintenance• Enhancements




Database Life CycleDatabase Life Cycle

Database Initialstudy

Database Design

Implementationand loading

Testing andevaluation

Operation andmaintenance

• Analyze company situation• Define problem• Define objectives• Define scope and boundaries

• Conceptual design• DBMS software selection, if required• Logical design• Physical design

• Install DBMS, if new• Create databases• Load data

• Test the database• Evaluate performance and fine-tune

• Daily operation and maintenance• Enhancements

This is also an iterative process like SDLC




Database DesignDatabase Design

Divided into four tasks Conceptual design DBMS software selection (if required) Logical design Physical design

Conceptual design is independent of software and hardware

Logical design is DBMS (software) dependent Physical design is dependent on both software and

hardware




Conceptual DesignConceptual Design

The goal is to capture and model user requirements Four Steps:

Data analysis and requirements Entity relationship modeling and normalization Data model verification Distributed database design





Data analysis and requirements The focus is on identifying user requirements This can be gathered through various mean

observing and analyzing the current system user interviews questionnaire surveys

Capture and document user data views and business rules. User data views describe the data used by the user

Example Business rules describe policies and procedures followed by the

company Example: (EZS)

An item may be procured from many vendors Purchase price of an item is negotiated with each supplier.





ER Modeling and Normalization User requirements are modeled using E-R diagrams

Identify main entities based on user requirements data Define relationships between the entities Define attributes, primary keys, and foreign keys for each of

the entities. Normalize the entities. Complete the initial E-R diagram. Verify the E-R model against the data, information, and

processing requirements. Modify the E-R diagram, if necessary

Documentation process must be standardized to avoid miscommunication





Data model verification Ensure that user data views can be supported by the

data model All business transactions (select, insert, update,

delete, user queries) can be supported by the model Distributed database design

Data requirements and processing requirements may vary from one location to another

Decision may be made about allocating data to different locations




DBMS SelectionDBMS Selection

This step is required only if you plan to acquire a new DBMS

Common factors affecting the decision: Cost -- Purchase, maintenance, operational, license,

installation, training, and conversion costs. DBMS features and tools. Underlying model. Portability -- Platforms, systems, and languages. DBMS hardware requirements.




Logical DesignLogical Design

Logical design translates the conceptual design into the internal model for a selected DBMS.

It includes the design of tables, indexes, views, transactions

Access authorities (who can access what) are also decided.

The ER model is translated into relational schema





Translating ER Model into Relational Schema After normalizing the E-R diagram we are left with

only two types of relationships One-to-one One-to-Many

For every one-to-one relationship, reexamine the possibility of merging the two entities into a single entity by combining their attributes.

Entities participating in a one-to-one relationship are linked through a foreign key.

Supertype-subtype relationships are usually implemented as one-to-one relationships. Both entities share a common primary key, which also becomes a foreign key in the subtype entity.





Employee DriverMay be a

1 1

(0,1) (1,1)

Employee

Emp_IdEmp_NameEmp_Salary

Driver

Emp_IdLicense NbrLic Exprn. Date

1 1

Example of translating a 1:1 relationship into a relational schema

Primary and ForeignKey





Translating ER Model into Relational Schema One-to-many relationships are implemented by

adding the primary key of the first entity as the foreign key of the second (many side) entity.

Professor Classteaches

1 M

(0,N) (1,1)

Professor

Prof_IdProf_LnameProf_Phone

Class

Class_CodeClass_SectionClass_DaysClass_TimeProf_Id

1

M

Example:

Foreign Key




Example - Logical DesignExample - Logical Design

PROF_ID Is a valid professor identification number.Type: numericRange: low value = 1,000 high value =2,000Display format: 9999Length: 4

PROF_LNAME Is a valid professor last name.Type: characterDisplay format: XXXXXXXXXXXXXXXLength: 15

PROF_PHONE Is a valid phone number.Type: characterDisplay format: 999-999-9999Length: 12

CLASS_CODE Is a valid class code.Type: numericRange: low value = 1,000 high value =1,999Display format: 9999Length: 4




Example - Logical DesignExample - Logical Design

CLASS_SECTION Is a valid is a valid class section number.Type: numericRange: low value = 10 high value = 99Display format: 99Length: 2

CLASS_DAYS Is a valid day code.Type: characterValid entries: MWF, TTh, M, T, W, Th, FDisplay format: XXXLength: 3

CLASS_TIME Is a valid time.Type: characterDisplay format: 99:99 (24-hour clock)Display range: 00:01 to 24:00Length: 5




Physical DesignPhysical Design

Select data storage and data access characteristics (indexes) of the database.

It affects location of the data in the storage device(s) and system performance.

Physical design is more complex with distributed databases.

Relational databases are more insulated from physical layer details than hierarchical and network models.

Chapters 7 and 8 describe an excellent case study of database design

Database Systems: Design, Implementation, and Management

Documents

Transcript of Database Systems: Design, Implementation, and Management