IST 210 Database Design Process IST 210 Todd S. Bacastow
Slide 2
IST 210 2
Slide 3
3 Key points Database design must reflect the information
system of which the database is a part Information systems undergo
evaluation and revision within a framework known as the Systems
Development Life Cycle (SDLC) Databases also undergo evaluation and
revision within a framework known as the Database Life Cycle (DBLC)
There are two general design strategies exist: top-down vs.
bottom-up design centralized vs. decentralized design
Slide 4
IST 210 4 References STANDISH GROUP (1995): The CHAOS Report
into Project Failure, The Standish Group International Inc.
STANDISH GROUP (1996): Unfinished Voyages, The Standish Group
International Inc. Croswell, P., 1991. "Obstacles to GIS
implementation and guidelines to increase the opportunity for
success," Journal of the Urban and Regional Information Systems
Association, 3(1):43-56.
Slide 5
IST 210 5 Lessons from Business Automation Era of finance and
operations: 60s - 70s Business accounting systems Manufacturing
software: 70s - 80s Separate applications for inventory, ordering,
forecasting, shop floor operations, logistics, etc. Era of the
business enterprise: 90s - 00s Separate applications get rolled
into enterprise resource planning system Sales force automation,
customer service center, campaign management, automated email
response, etc. get rolled into customer relationship
management.
Slide 6
IST 210 6 User (Someone doing real work ) Infrastructure
(Computer and Human) Management (Organization) Successful
automation requires an interlocking of the:
Slide 7
IST 210 7 American Airlines American Airlines settled a lawsuit
with Budget Rent-A-Car, Marriott Corp. and Hilton Hotels after the
$165 million CONFIRM car rental and hotel reservation system
project collapsed into chaos.
Slide 8
IST 210 8 84% of all automation projects have significant or
major problems STANDISH GROUP (1995): The CHAOS Report into Project
Failure, The Standish Group International Inc.
Slide 9
IST 210 9 Percent Over Budget 53% of all automation projects
are more than 50% over budget 23% of all automation projects are
more than 100% over budget STANDISH GROUP (1995): The CHAOS Report
into Project Failure, The Standish Group International Inc.
Slide 10
IST 210 10 49% of all automation projects take twice as long to
complete as planned Percent of Time Under Estimated STANDISH GROUP
(1995): The CHAOS Report into Project Failure, The Standish Group
International Inc.
Slide 11
IST 210 11 Percent Planned Functionality 54% of all automation
projects deliver less than half of the promised functionality
STANDISH GROUP (1995): The CHAOS Report into Project Failure, The
Standish Group International Inc.
Slide 12
IST 210 12
Slide 13
IST 210 13 Most problems are non-technical Poorly selected data
Badly organized data Incorrect data models Software has limited
capability (oversell) Systems managers underestimate time
requirements Systems can be underutilized Systems can be (and have
been) abandoned Personnel problems
Slide 14
IST 210 14 Data Raw facts stored in databases Need additional
processing to become useful Information Required by decision maker
Data processed and presented in a meaningful form Transformation
Changing Data into Information
Slide 15
IST 210 15 Database Carefully designed and constructed
repository of facts Part of an information system Information
System Provides data collection, storage, and retrieval Facilitates
data transformation Includes people, hardware, and software
Software: Database(s), Application programs, and Procedures The
Information System
Slide 16
IST 210 16 System Analysis Establishes need and extent of an
information system Refer to Recommended Requirements Gathering
Practices We are NOT DOING A SYSTEM REQT ANALYSIS!! Systems
development Process of creating information system Database
development Process of database design and implementation Creation
of database models Implementation Creating storage structure
Loading data into database Providing for data management The
Information System (Cont.)
Slide 17
IST 210 17 Systems Development Life Cycle System Analysis
Database Organization (IST 210)
IST 210 19 Phase 1: Database Initial Study Purposes Analyze
company situation Operating environment Organizational structure
Define problems and constraints Define objectives Define scope and
boundaries
Slide 20
IST 210 20 Initial Study Activities
Slide 21
IST 210 21 Phase 2: Database Design Most Critical DBLC phase
Makes sure final product meets requirements Focus on data
requirements Subphases I. Create conceptual design II. DBMS
software selection III. Create logical design IV. Create physical
design
Slide 22
IST 210 22 Two Views of Data
Slide 23
IST 210 23 I. Conceptual Design Data modeling creates abstract
data structure to represent real-world items High level of
abstraction Four steps Data analysis and requirements *Entity
relationship modeling and normalization* *Data model
verification*
Slide 24
IST 210 24 Data analysis and Requirements Focus on: Information
needs Information users Information sources Data sources Developing
and gathering end-user data views Direct observation of current
system Interfacing with systems design group Business rules
Slide 25
IST 210 25 Entity Relationship Modeling and Normalization
Slide 26
IST 210 26 E-R Modeling is Iterative
Slide 27
IST 210 27 Concept Design: Tools and Sources
Slide 28
IST 210 28 Data Model Verification E-R model is verified
against proposed system processes End user views and required
transactions Access paths, security, concurrency control
Business-imposed data requirements and constraints Reveals
additional entity and attribute details
Slide 29
IST 210 29 E-R Model Verification Process
Slide 30
IST 210 30 Iterative Process of Verification
Slide 31
IST 210 31 II. DBMS Software Selection DBMS software selection
is critical Advantages and disadvantages need study Factors
affecting purchasing decision Cost DBMS features and tools
Underlying model Portability DBMS hardware requirements
Slide 32
IST 210 32 III. Logical Design Translates conceptual design
into internal model Maps objects in model to specific DBMS
constructs Design components Tables Indexes Views Transactions
Access authorities Others
Slide 33
IST 210 33 IV. Physical Design Selection of data storage and
access characteristics Very technical More important in older
hierarchical and network models Becomes more complex for
distributed systems Designers favor software that hides physical
details
Slide 34
IST 210 34 Phase 3: Implementation and Loading Creation of
special storage-related constructs to house end-user tables Data
loaded into tables Other issues Performance Security Backup and
recovery Integrity Company standards Concurrency controls
Slide 35
IST 210 35 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
Actions taken if tests fail Fine-tuning based on reference manuals
Modification of physical design Modification of logical design
Upgrade or change DBMS software or hardware
Slide 36
IST 210 36 Phase 5: Operation Database considered operational
Starts process of system evaluation Unforeseen problems may surface
Demand for change is constant
Slide 37
IST 210 37 Phase 6: Maintenance and Evaluation Preventative
maintenance Corrective maintenance Adaptive maintenance Assignment
of access permissions Generation of database access statistics to
monitor performance Periodic security audits based on system-
generated statistics Periodic system usage-summaries
Slide 38
IST 210 38 DB 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
Slide 39
IST 210 39 Top-Down vs. Bottom-Up
Slide 40
IST 210 40 Centralized vs. Decentralized Design Centralized
design Typical of simple databases Conducted by single person or
small team Decentralized design Larger numbers of entities and
complex relations Spread across multiple sites Developed by
teams
