Date post: | 29-Dec-2015 |
Category: |
Documents |
Upload: | clarissa-wiggins |
View: | 222 times |
Download: | 0 times |
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