Transcript of IST 210 Database Design Process IST 210 Todd S. Bacastow.
- Slide 1
- 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)
- Slide 18
- IST 210 18 Phase 2 Phase 1 Phase 3 Phase 4 Phase 5 Phase 6
Database Lifecycle (DBLC) Database Organization (IST 210)
- Slide 19
- 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
- Slide 41
- IST 210 41 Decentralized Design