Database Development

Process
 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

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

3
 The Information System
 Information System
 It has several components including:
• People
• Hardware
• Software
• Databases
• Application program
• procedures

4
The Information System (Con’t.)
 Building an information system has two
processes
 Systems analysis
 Systems development

5
The Information System (Con’t.)
 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

6
7
The Information System (Con’t.)
 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

8
The Information System (Con’t.)
 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

9
The Information System (Con’t.)
 Detailed procedure of how to build an
information system
 Detailed procedure of how to build
database system
 Keep as general as possible

10
Systems Development Life Cycle
(SDLC)
 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

11
Systems Development Life Cycle
(SDLC)
Information
system
Database design

Application development

12
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)

13
Systems Development Life Cycle

Figure 6.2

14
Systems Development Life Cycle
(SDLC)
 SDLC’s 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

15
Systems Development Life Cycle
(SDLC)
 SDLC’s planning phase
 Study existing system
 Explore alternative solutions
 Feasibility study:
 Technical (Technical aspects of hardware and software
requirement)
 Financial (System cost, labor cost, …)

16
Systems Development Life Cycle
(SDLC)
 SDLC’s 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

17
Systems Development Life Cycle
(SDLC)
 SDLC’s 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

18
Systems Development Life Cycle
(SDLC)
 SDLC’s detailed system design phase
 Complete the design of the system processes
 All technical specifications
 Menus
 Reports
 Devices
 Conversion from old system
 Training
 Methodologies

19
Systems Development Life Cycle
(SDLC)
 SDLC’s implementation phase
 Hardware, DBMS software, and application
programs are installed
 Database design is implemented
 Actual database is created
 Tables, views, user authorization

20
Systems Development Life Cycle
(SDLC)
 SDLC’s implementation phase
 Database contents
 Customized user programs
 Database interface programs
 Conversion programs
 Documentation
 User training
 Refining and evaluation

21
Systems Development Life Cycle
(SDLC)
 SDLC’s 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

22
 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

23
Database Lifecycle (DBLC)

Figure 6.3

24
Phase 1: Database Initial Study
 Determine how and why the current
system fails
 Require to have strong
communication skill and
interpersonal skills

25
Phase 1: Database Initial Study
 Purposes
 Analyze company situation
 Operating environment
 Organizational structure

 Define problems and constraints

 Determine boundaries

26
Initial Study Activities
Figure 6.4

27
Initial Study Activities: Analysis of
company’s 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

28
Initial Study Activities: Analysis of
company’s situation
 Designer must discover what the
company’s operational components
are, and how they function, and how
they interact

29
Initial Study Activities: Analysis of
company’s situation
 Issues:
 What is the organization’s general
operating environment?
 What is its mission within that
environment?
 What is the organization’s structure?

30
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

31
Initial Study Activities: Define
objectives
 Basic on the major problem, define
objectives
 What is the proposed system’s 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?

32
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

33
Initial Study Activities: Define
scope and boundary
 Boundary: external to the system
 Imposed by hardware and software

34
 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

35
 Phase 2: Database Design
 Focus on the requirements of data
characteristics
 Two view of data
 Business view of data as a source of
information
 Designer’s view of data structure (access and
activities required ro transform the data into
information

36
 Two Views of Data

Figure 6.5

37
 Phase 2: Database Design
 Sub-components
 Create conceptual design
 DBMS software selection

 Create logical design

 Create physical design

 Procedure flow in the database design

38
39
 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

40
 I. Conceptual Design
 Four steps
 Data analysis and requirements
 Entity relationship modeling and normalization

 Data model verification

 Distributed database design

41
 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

42
 Data analysis and
Requirements
 Designer’s 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?
 Information users
 Who will use the information? how is the
information to be used what is the end-user’s
interface?

43
 Data analysis and
Requirements
 Designer’s efforts are focused on:
 Information sources
 Where is the information to be found? how to extract
the information from?
 Information constitution
 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?
44
 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
organization’s environment
45
 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 company’s procedures,
standards, and operation manuals

46
 Data analysis and
Requirements
 Business rules yields several important
benefits in the design of new system
 Help standardize the company’s view of data
 Constitute a communications tools between
users and designers
 Allow the designer to understand the nature,
role, and scope of the data

47
 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

48
 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

49
 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 E-RD is summarized

50
 Entity Relationship
Modeling and Normalization

Table 6.2

51
 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

52
 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

53
 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

54
 Distributed Database Design

 Design portions in different physical

55
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

56
 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
57
 III. Logical Design
 Translates conceptual design into internal
model
 Maps objects in model to specific DBMS
constructs (DB2, SQL Server, Oracle,
Infomax, Access, MySQL, Ingress, …)
 For relational DBMS, logical design
include the design of tables, indexes,
views, transactions, access authorities, …
58
 III. Logical Design
 Design components in relational DBMS
 Tables
 Indexes

 Views

 Transactions

 Access authorities

 Others

59
 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

60
 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

61
Physical Organization

Figure 6.12
62
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

63
Phase 3: Implementation and
Loading
 Assign access rights to the table space
 ….

64
Phase 3: Implementation and
Loading
 Other issues need to be addressed in this
phase
 Performance:
 important fact,
 monitoring

 evaluation issue

65
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

66
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

67
 Phase 3: Implementation and
Loading
 Concurrency controls
 Simultaneously access a database while preserving
data integrity is concurrency control

68
 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

69
 Phase 4: Testing and
Evaluation
 Actions taken if tests fail
 For performance, designer should consider
fine-tuning based on reference manuals
 Modification of physical design

 Modification of logical design

 Upgrade or change DBMS software or

70
 Phase 5: Operation
 Database considered operational
 Starts process of system evaluation
 Unforeseen problems may surface
 Demand for change is constant

71
 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 72
 Phase 6: Maintenance and
Evaluation
 Periodic security audits based on system-
generated statistics
 Periodic system usage-summaries

73
 DB Design Strategy Notes
 Two classical approaches to the
database design
 Top-down design
 1) Identify data sets (entities)
 2) Define data elements (attributes)
 Bottom-up
 1) Identify data elements (attributes)
 2) Group them into data sets (entities)

74
Top-Down vs. Bottom-Up

Figure 6.14

75
76