1

Database Systems: Design, Implementation, and Management

Database Systems: Design, Implementation, and Management

CHAPTER 6

Database Design

2The 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

3

Figure 6.2

Systems Development Life Cycle

4

Figure 6.3

Database Lifecycle (DBLC)

This is also an iterative process like SDLC

5Database 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

6Conceptual 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

7Conceptual DesignConceptual 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.

8Conceptual DesignConceptual Design

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

9Conceptual DesignConceptual Design

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

10DBMS 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.

11Logical 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

12Logical DesignLogical Design 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.

13Logical DesignLogical Design

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

14Logical DesignLogical Design

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

15Example - 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

16Example - 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

17Physical 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

18Physical Organization

Figure 6.12

19DB Design Strategy Notes

Top-down 1) Identify data sets 2) Define data elements

Bottom-up 1) Identify data elements 2) Group them into data sets Figure 6.14