Chapter 6

Database Design

In this chapter, you will learn:

That successful database design must reflect the information system of which the database is a part That successful information systems are subject to frequent evaluation and revision within a framework known as the Systems Development Life Cycle (SDLC)

In this chapter, you will learn:

Within the information system, the most successful databases are subject to frequent evaluation and revision within a framework known as the Database Life Cycle (DBLC) How to conduct evaluation and revision within the SDLC and DBLC frameworks What database design strategies exist:

top-down vs. bottom-up design centralized vs. decentralized design

3

Data

Changing Data into Information

Raw facts stored in databases Seldom immediately useful to a decision maker Need additional processing to become useful information

Changing Data into Information

Information
Required by decision maker Data must be put together or transformed to produce information that can create insight Data processed and presented in a meaningful form

Tabulating data (cross-clasification table) Plotting data Reporting data

Changing Data into Information

Information

Data transformation: process that changes data into information

Simple tabulation Detailed report Statistical procedure Graphic presentation

Provide the basis for decision making, which is a driving force

7

Changing Data into Information

Information
Without enough and reliable data, one can not obtain information Without information, one can not make great decision

The Information System

Database
Carefully designed and constructed repository of facts Fact repository is a part of larger system called information system Database is a part of an information system

The Information System

Information System
Provides data collection, storage, and retrieval Also facilitates data transformation of data into information Manages both data and information

10

The Information System

Information System

It has several components including:

People Hardware Software Databases Application program procedures

11

The Information System (Cont.)

Building an information system has two processes

Systems analysis Systems development

12

The Information System (Cont.)

Systems Analysis

Establishes the need for and the extent of an information system

Systems development
Process of creating information system Within systems development, it has application transformation data into information in terms of formal report, tabulations, and graphic displays

13

14

The Information System (Cont.)

Performance of an information system depends on

Database design and implementation (it is called database development) Application design and implementation Administrative procedures Both Systems analysis and systems development require much careful planning

15

The Information System (Cont.)

Database development
Process of database design and implementation Primary objective of database design: to create complete, normalized, non-redundant and fully integrated conceptual, logical, and physical database models Implementation

Creating storage structure Loading data into database Providing for data management

16

The Information System (Cont.)

Detailed procedure of how to build an information system Detailed procedure of how to build database system Keep as general as possible

17

Systems Development Life Cycle (SDLC)

Procedure (history) of an information system Important to system designer Big frame within which the database design and application development can be mapped out and evaluated In other words, database design and application development take place within the confines of an information system
18

Systems Development Life Cycle (SDLC)

Information system Database design Application development

19

Systems Development Life Cycle (SDLC)

SDLC is divided into five phases based on time or procedure order

Planning Analysis Detailed systems design Implementation Maintenance

It is an iterative procedure rather than sequential procedure (contains refining)

20

Systems Development Life Cycle

Figure 6.2
21

Systems Development Life Cycle (SDLC)

SDLCs planning phase

General overview of organization and its objective Initial assessment must be made Such assessments:

Should the existing system be continue? Should the existing system be modified Should the existing system be replace

22

Systems Development Life Cycle (SDLC)

SDLCs planning phase

Study existing system Explore alternative solutions Feasibility study:

Technical (Technical aspects of hardware and software requirement) Financial (System cost, labor cost, )

23

Systems Development Life Cycle (SDLC)

SDLCs analysis phase

Great detail examination based on the previous phase (planning phase) Address both individual (user) needs or organizational needs Existing hardware and software systems are studied to find out current systems performance, functionality, and potential problem, as well as future opportunities

24

Systems Development Life Cycle (SDLC)

SDLCs analysis phase

Require end-user and system designers to gather together. Study carefully about relationships and database models Create logical design using various tools Define the logical systems Provide functional descriptions Define data transformation and documentation
25

Systems Development Life Cycle (SDLC)

SDLCs detailed system design phase

Complete the design of the system processes

All technical specifications Menus Reports Devices Conversion from old system Training Methodologies

26

Systems Development Life Cycle (SDLC)

SDLCs implementation phase

Hardware, DBMS software, and application programs are installed Database design is implemented Actual database is created Tables, views, user authorization

27

Systems Development Life Cycle (SDLC)

SDLCs implementation phase

Database contents

Customized user programs Database interface programs Conversion programs

Documentation User training Refining and evaluation

28

Systems Development Life Cycle (SDLC)

SDLCs maintenance phase

After system operation End-user begin to request changes in it, which generate system maintenance activities

Corrective maintenance due to system errors Adaptive maintenance due to changes in business environment Perfective maintenance to enhance the system

29

Database Lifecycle (SDLC)

Within the large information system, the database is subject to a life cycle Database lifecycle contains six phases

Database initial study Database design Implementation and loading Testing and evaluation Operation Maintenance and evolution
30

Database Lifecycle (DBLC)

Figure 6.3
31

Phase 1: Database Initial Study

Determine how and why the current system fails Require to have strong communication skill and interpersonal skills

32

Phase 1: Database Initial Study

Alone or team (project leader, senior system analyst, ) project, depend on the scale of the system

33

Phase 1: Database Initial Study

Purposes

Analyze company situation

Operating environment Organizational structure

Define problems and constraints Define database system specification

Determine objectives Determine scope Determine boundaries

34

Initial Study Activities

Figure 6.4

35

Initial Study Activities: Analysis of companys situation

Analysis: to break up any whole into its parts so as to find out their nature, function, and so on Company situation: describes the general conditions in which a company operates, its organizational structure, and its mission

36

Initial Study Activities: Analysis of companys situation

Designer must discover what the companys operational components are, and how they function, and how they interact

37

Initial Study Activities: Analysis of companys situation

Issues:
What is the organizations general operating environment? What is its mission within that environment? What is the organizations structure?

38

Initial Study Activities: Define problems and constrains

Find existing system (functions, operations, system requirement, people) Collect very broad problem descriptions from people at different levels Distinct the major problems Study the possible constraints
39

Initial Study Activities: Define objectives

Basic on the major problem, define objectives

What is the proposed systems initial objective? Will the system interface with other existing or future systems in the company? Will the system share with the data with other systems or users?

40

Initial Study Activities: Define scope and boundary

Scope: define the extend of the design, according to the operational requirement (whole departments, partial departments, individual department) Scope helps define the required data structure, type, and number of entities, physical size of the database
41

Initial Study Activities: Define scope and boundary

Boundary: external to the system Imposed by hardware and software

42

Phase 2: Database Design

Focus on the design of database model to support operations and objectives Most Critical DBLC phase Makes sure final product meets requirements

43

Phase 2: Database Design

Focus on the requirements of data characteristics Two view of data

Business view of data as a source of information Designers view of data structure (access and activities required ro transform the data into information

44

Two Views of Data

Figure 6.5
45

Phase 2: Database Design

Sub-components
Create conceptual design DBMS software selection Create logical design Create physical design

Procedure flow in the database design

46

47

I. Conceptual Design

Data modeling creates abstract data structure to represent real-world items Must embody a clear understanding of the business and its functional areas High level of abstraction
Hardware and software or database model might not be identified (hardware and software independent) All that is needed is there, and all that is there is needed

48

I. Conceptual Design

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

49

Data analysis and Requirements

First step in conceptual design is to discover the data element characteristics Appropriate data element characteristics are those that can be transformed into appropriate information

50

Data analysis and Requirements

Designers efforts are focused on:

Information needs

What kind of information needed? what kind of information the current system provides? what kind of new information we need to obtain? Who will use the information? how is the information to be used what is the end-users interface?

Information users

51

Data analysis and Requirements

Designers efforts are focused on:

Information sources

Where is the information to be found? how to extract the information from? What data elements are needed to product the information? what are the attributes, what relationships exist among the data? what is the data volume? how frequently are the data used,? What data transformations are to be used to generate the required information? 52

Information constitution

Data analysis and Requirements

Data sources
Developing and gathering end-user data views Direct observation of current system Interfacing with systems design group

Business rules

A brief and precise description of a policy, procedures, or principle within a specific organizations environment
53

Data analysis and Requirements

Business rules help designer to define entity, attributes, relationships, connectivities, cardinalities, and constraints Made by policy makers or managers Documented as companys procedures, standards, and operation manuals

54

Data analysis and Requirements

Business rules yields several important benefits in the design of new system
Help standardize the companys view of data Constitute a communications tools between users and designers Allow the designer to understand the nature, role, and scope of the data

55

Data analysis and Requirements

Business rules yields several important benefits in the design of new system
Allow the designer to understand business processes Allow the designer to develop appropriate relationship participation rules and foreign key constraints

56

Entity Relationship Modeling and Normalization

Must communicate and enforce appropriate standards to be used in the documentation of the design Standards: use of diagram and symbols, documentation writing style, layout, and any conventions

57

Entity Relationship Modeling and Normalization

Business rules usually define the nature of relationship(s) among the entities The process of defining business rules and developing the conceptual model using ERD is summarized

58

Entity Relationship Modeling and Normalization

Table 6.2
59

E-R Modeling is Iterative

Figure 6.8
60

Concept Design: Tools and Sources

61

Entity Relationship Modeling and Normalization

During E-R model, designer must

Define entities, attributes, primary keys, and foreign keys Make decision about adding new primary key attributes in order to satisfy end-user and/or processing requirements Make decision about treatment of multivalued attribute Make decision about adding derived attributes to satisfy processing requirement Make decision about placement of foreign keys in 1:1 relationships
62

Entity Relationship Modeling and Normalization

During E-R model, designer must

Avoid unnecessary ternary relationships Draw the corresponding E-R diagram Normalize the data model Include all the data element definitions in the data dictionary Make decision about standard naming conventions

63

Data Model Verification

E-R model is verified against proposed system processes Verification requires that the model be run through a series of tests against:
End user views and required transactions Access paths, security, concurrency control Business-imposed data requirements and constraints

64

Data Model Verification

Revision of original database design with a careful reevaluation of entities Followed by detailed examination of the attributes The process serves several important purposes

Emergence of the attribute details may lead a revision of the entities

65

Data Model Verification

Focus on attribute details can provide clues about the nature of relationships Satisfy processing and/or end-user requirements, possible create a new primary key to replace existing primary key Normalization helps guard against undesirable redundancies Meet the end-user requirement

66

Data Model Verification

Module: an information system component that handle a specific function, such inventory, payroll, orders, Create and use modules accomplish several important ends
Easily ad and delete within a team work Simplify design work Prototype quickly Reuse

67

Data Model Verification

Modules represent E-R model fragments Each module or fragment must be verified against the complete E-T model The verification process is detailed in the following Table

68

E-R Model Verification Process

Table 6.4
69

Data Model Verification

Verification process requires the continuous verification of business transaction as well as system and user requirement It is a repeated process for each of the systems modules

70

Iterative Process of Verification

Figure 6.10

71

Data Model Verification

Define major components as modules Verification starts with the central (most important) entity Central entity is defined as a entity which has most of the models relationships (involved in the greatest number of relationships) Identify module (sub-system) to which the central entity belongs, and define modules scope and boundary
72

Data Model Verification

Within the central entity/module framework, we must

Ensure the modules cohesivity: strength of the relationships found among the module entities Analyze relationships between modules, in terms of module coupling: extent to which modules are independent of one another. The lower coupling the better.

73

Data Model Verification

Processes often classified into

Frequency (daily, weekly, monthly, yearly, and exceptions) Operational type (INSERT, ADD, UPDATE, CHANGE, DELKETE, queries and reports, batches, maintenance and backups)

All identified processes must be verified against the E-R model

74

Distributed Database Design

Design portions in different physical locations Development of data distribution and allocation strategies

75

II. DBMS Software Selection

DBMS software selection is critical Advantages and disadvantages of each DBMS should be carefully studied Factors affecting purchasing decision
Cost DBMS features and tools Underlying model Portability DBMS hardware requirements

76

III. Logical Design

Logical design follows the decision to use a specific database model (hierarchy, network, relation, or object-oriented models) Once the database model is selected, we can map the conceptual design onto a logical design It is software-dependent but hardware independent
77

III. Logical Design

Translates conceptual design into internal model Maps objects in model to specific DBMS constructs (DB2, SQL Server, Oracle, IMS, Infomax, Access, MySQL, Ingress, ) For relational DBMS, logical design include the design of tables, indexes, views, transactions, access authorities,
78

III. Logical Design

Design components in relational DBMS

Tables Indexes Views Transactions Access authorities Others

79

IV. Physical Design

Selection of data storage and access characteristics Storage characteristics are a function of the types of devices supported by the hardware, the type of data access methods supported y the system and DBMS selected. It affects the location of data and performance of the system
80

IV. Physical Design

Very technical and hardware dependent (experience required) More important in older hierarchical and network models Becomes more complex for distributed systems Designers favor software that hides physical details
81

Physical Organization

Figure 6.12
82

Phase 3: Implementation and Loading

Creation of special storage-related constructs to house end-user tables Data loaded into tables Design rights to use the database administrator Create the table spaces within the database Create the table within table space
83

Phase 3: Implementation and Loading

Assign access rights to the table space .

84

Phase 3: Implementation and Loading

Other issues need to be addressed in this phase

Performance:
important fact, monitoring evaluation issue

85

Phase 3: Implementation and Loading

Other issues need to be addressed in this phase

Security
Physical security Password security Access rights Audit trails Data encryption

Backup and recovery

86

Phase 3: Implementation and Loading

Other issues need to be addressed in this phase

Integrity: enforced through the proper use of primary and foreign key rules Company standards Concurrency controls

87

Phase 3: Implementation and Loading

Concurrency controls

Simultaneously access a database while preserving data integrity is concurrency control Example

88

89

Phase 4: Testing and Evaluation

Database is tested and fine-tuned for performance, integrity, concurrent access, and security constraints Done in parallel with application programming

90

Phase 4: Testing and Evaluation

Actions taken if tests fail

For performance, designer should consider finetuning based on reference manuals Modification of physical design Modification of logical design Upgrade or change DBMS software or hardware

91

Phase 5: Operation

Database considered operational Starts process of system evaluation Unforeseen problems may surface Demand for change is constant

92

Phase 6: Maintenance and Evaluation

Preventative maintenance (backup) Corrective maintenance (recover) Adaptive maintenance (enhancing performance, adding entities and attributes) Assignment of access permissions Generation of database access statistics to improve efficiency and usefulness of system audits, and monitor performance

93

Phase 6: Maintenance and Evaluation

Periodic security audits based on systemgenerated statistics Periodic system usage-summaries

94

DB Design Strategy Notes

Two classical approaches to the database design Top-down design

1) Identify data sets (entities) 2) Define data elements (attributes)

1) Identify data elements (attributes) 2) Group them into data sets (entities)

Bottom-up

95

Top-Down vs. Bottom-Up

Figure 6.14

96

Centralized vs. Decentralized Design

Depends on the scope and size, the design approaches can also be classified into Centralized design
Typical of simple databases Conducted by single person or small team

97

98

Centralized vs. Decentralized Design

Decentralized design
Larger numbers of entities and complex relations Design may divided into several modules Spread across multiple sites Developed by teams

99

Decentralized Design

Figure 6.16
100

Decentralized Design

Definition of boundary and interrelation among data subsets must be very precise All the independently-designed modules will integrated together Aggregate sub-conceptual model into a large conceptual model, it must be verified the combination and transactions
101

Decentralized Design

Aggregation process requires the designer to create a single model in which various aggregation problems must be addressed

Synonyms (same object by different name) and homonyms problems (same name to address different object) Entity and entity subtypes Conflicting objects definition (different data types, different domain definition fro the same attributes)
102

103