Database Systems: Design, Implementation, and Management CHAPTER 6 Database Design 1

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

SDLC Enterprise-wide requirement assessment Identification of IS projects Feasibility assessment and prioritization Planning User requirement analysis for a specific project Requirement modeling (conceptual) Analysis Detailed design Specification development Design Coding, testing and evaluation Installation Implementation Daily operation and maintenance Enhancements Maintenance

Database Life Cycle 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 Database Initial study Database Design Implementation and loading Testing and evaluation Operation and maintenance This is also an iterative process like SDLC

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

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

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

Conceptual Design Data model verification Distributed database design 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 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 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

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

Logical Design 1 1 Employee May be a Driver (0,1) (1,1) Primary and Foreign Key Employee Driver 1 1 Emp_Id Emp_Name Emp_Salary Emp_Id License Nbr Lic Exprn. Date Example of translating a 1:1 relationship into a relational schema

Logical 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. Example: Professor Class teaches 1 M (0,N) (1,1) Professor Prof_Id Prof_Lname Prof_Phone Class Class_Code Class_Section Class_Days Class_Time 1 M Foreign Key

Example - Logical Design

Example - Logical Design

Physical 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