1. ITEC 3220A Using and Designing Database Systems
Instructor: Prof. Z. Yang
Course Website:
Office: DB 3049

2. Chapter 9
Database Design

3. The Information System
Provides for data collection, storage, and retrieval
Composed of people, hardware, software, database(s), application programs, and procedures
Systems analysis
Process that establishes need for and extent of an information system
Systems development
Process of creating an information system

4. The Information System (Cont’d.)
Performance depends on:
Database design and implementation
Application design and implementation
Administrative procedures
Database development
Process of database design and implementation
Primary objective is to create complete, normalized, nonredundant (to the extent possible), and fully integrated conceptual, logical, and physical database models

5. Database Lifecycle (DBLC)

6. Phase 1: Database Initial Study
Overall purpose:
Analyze the company situation
Define problems and constraints
Define objectives
Define scope and boundaries
Interactive and iterative processes required to complete the first phase of the DBLC successfully

7. Phase 2: Database Design
Supports company’s operations and objectives
Most critical phase
Ensures final product meets user and system requirements
Points for examining completion procedures
Data component is an element of whole system
System analysts/programmers design procedures to convert data into information
Database design is an iterative process

8. Two Views of Data

9. Procedure Flow in the Database Design

10. Conceptual Design
Data modeling used to create an abstract database structure that represents real-world objects in the most realistic way possible
Must embody a clear understanding of the business and its functional areas
Ensure that all data needed are in the model, and that all data in the model are needed
Requires four steps

11. Data Analysis and Requirements
First step is to discover data element characteristics
Obtains characteristics from different sources
Must take into account business rules
Derived from description of operations
Document that provides precise, detailed, up-to-date, and thoroughly reviewed description of activities that define an organization’s operating environment

12. Entity Relationship (ER) Modeling and Normalization
Designer must communicate and enforce appropriate standards to be used in the documentation of design
Use of diagrams and symbols
Documentation writing style
Layout
Other conventions to be followed during documentation

13. ER Modeling Is an Iterative Process Based on Many Activities

14. Data Dictionary
Defines all objects (entities, attributes, relations, views, and so on)
Used with the normalization process to help eliminate data anomalies and redundancy problems

15. Data Model Verification
Verified against proposed system processes
Module: Information system component that handles specific business function
Better if modules’ ER fragments are merged into a single enterprise ER model which triggers
Careful reevaluation of entities
Detailed examination of attributes describing entities
Resulting model verified against each of the module’s processes

16. Verification Process Select the central (most important) entity
Defined in terms of its participation in most of the model’s relationships
Identify the module or subsystem to which the central entity belongs and define boundaries and scope
Place central entity within the module’s framework

17. Cohesivity and Module Coupling
Cohesivity: Strength of the relationships among the module’s entities
Module coupling: Extent to which modules are independent to one another
Low coupling decreases unnecessary intermodule dependencies

18. Distributed Database Design
Portions of database may reside in different physical locations
Database fragment: Subset of a database stored at a given location
Ensures database integrity, security, and performance

19. DBMS Software Selection
Critical to the information system’s smooth operation
Advantages and disadvantages should be carefully studied

20. Logical and Physical Design
Logical design: Designs an enterprise-wide database that is based on a specific data model but independent of physical-level details
Validates logical model:
Using normalization
Integrity constraints
Against user requirements
Physical design: Process of data storage organization and data access characteristics of the database

21. Implementation and Loading
Install the DBMS
Virtualization: Creates logical representations of computing resources independent of underlying physical computing resources
Create the databases
Requires the creation of special storage-related constructs to house the end-user tables
Load or convert the data
Requires aggregating data from multiple sources

22. Testing and Evaluation
Physical security
Password security
Access rights
Audit trails
Data encryption
Diskless workstations
Optimization

23. Levels of Database Backups
Full backup/dump: All database objects are backed up in their entirety
Differential backup: Only modified/updated objects since last full backup are backed up
Transaction log backup: Only the transaction log operations that are not reflected in a previous backup are backed up
Backups are provided with high security

24. Maintenance and Evolution
Preventive maintenance (backup)
Corrective maintenance (recovery)
Adaptive maintenance
Assignment of access permissions and their maintenance for new and old users
Generation of database access statistics
Periodic security audits
Periodic system-usage summaries

25. A Special Note about Database Design Strategies
Two classical approaches to database design:
Top-down design
Identifies data sets
Defines data elements for each of those sets
Bottom-up design
Identifies data elements (items)
Groups them together in data sets

26. Top-Down vs. Bottom-Up Design Sequencing

27. Centralized vs. Decentralized Design
Database design may be based on two very different design philosophies:
Centralized design
Productive when the data component is composed of a relatively small number of objects and procedures
Decentralized design
Used when the data component of system has considerable number of entities and complex relations on which very complex operations are performed

28. Case Study
Please download the case study from the course website.