1. Chapter 1 The Database Environment and Development Process
Jason C. H. Chen, Ph.D.
Professor of MIS
School of Business Administration
Gonzaga University
Spokane, WA 99258

2. Importance of Information
Information (and energy) are at the core of everything around us. Our entire existence (including businesses) is a process of gathering, analyzing, understanding, and acting on the information.
Modern organizations are said to be drowning in data but starving for information.

3. CAREER EARNING POTENTIAL
Employment for Computer Systems Analysts is expected to grow much faster than average. Jobs in this area are expected to increase by 25% between 2012 and With a Bachelor's degree -- the median salary per year for this occupation is $79,680. It is expected that 127,000 new jobs will be created in this area by 2020.
Source: U.S. Bureau of Labor Statistics.

4. Objectives Define terms
Name limitations of conventional file processing
Explain advantages of databases
Identify costs and risks of databases
List components of database environment
Identify categories of database applications
Describe database system development life cycle
Explain prototyping and agile development approaches
Explain roles of individuals
Explain the three-schema architecture for databases

5. Definitions
Data: Meaningful facts, text, graphics, images, sound, video segments.
Database: An organized collection of logically related data.
Information: Data processed to be useful in decision making.
Metadata: Data that describes data
(Data about the data).

6. Business and Modeling Environment
Examples:
Model
Meta-Data
Invoice
Core/Essence
Data
Debt, Revenue
Furniture Store
Business
Reality

7. Business and Modeling Environment
Examples:
Model
Meta-Data
Invoice
Core/Essence
Data
Debt, Revenue
Furniture Store
Business
Reality

8. Types of Data Processing
Two types of data processing
File-based data processing
e.g., applications developed by Java
Data-based data processing
e.g, applications developed by Oracle or MS/Access)

9. Figure 1-2: Old file processing systems at Pine Valley Furniture
What is the main problem in the company’s processing systems?
Duplicate Data

10. Disadvantages of File Processing
Program-Data Dependence
All programs maintain metadata for each file they use
Data Redundancy (Duplication of data)
Different systems/programs have separate copies of the same data
Limited Data Sharing
No centralized control of data
Lengthy Development Times
Programmers must design their own file formats
Excessive Program Maintenance
80% of of information systems budget

11. Problems with Data Dependency
Each application programmer must maintain their own data
Each application program needs to include code for the metadata of each file
Each application program must have its own processing routines for reading, inserting, updating and deleting data
Lack of coordination and central control
Non-standard file formats

12. Problems with Data Redundancy (conti.)
Waste of space to have duplicate data
Causes more maintenance headaches
The biggest Problem:
When data changes in one file, could cause inconsistencies
Compromises data integrity

13. SOLUTION: The DATABASE Approach Central repository of shared data
Data is managed by a controlling agent
Stored in a standardized, convenient form
Requires a Database Management System (DBMS)

14. Database Management System
A software system that is used to create, maintain, and provide controlled access to user databases
Database
containing
centralized
shared data
Application #1
(Order Filing) #2
(Invoicing Sys) #3
(Payroll Sys.)
DBMS
DBMS manages data resources like an operating system manages hardware resources

15. Database Management System
A DBMS is a data storage and retrieval system which permits data to be stored non-redundantly while making it appear to the user as if the data is well-integrated.
In short, a DBMS is a software package that manages a data base.

16. Advantages of Database Approach
Program-Data Independence
Metadata stored in DBMS, so applications don’t need to worry about data formats (you will know this when you learn Oracle)
Data queries/updates managed by DBMS so programs don’t need to process data access routines
Results in: increased application development and maintenance productivity
Minimal Data Redundancy
Leads to increased data integrity/consistency

17. Advantages of Database Approach
Program-data independence
Planned data redundancy
Improved data consistency
Improved Data Sharing
Different users get different views of the data
Improved productivity of application development
Enforcement of Standards
All data access is done in the same way
Improved Data Quality
Constraints, data validation rules
Improved data accessibility and responsiveness
Use of standard data query language (SQL)
Reduced program maintenance
Improved decision support
Security, Backup/Recovery, Concurrency (not in Table 1-3)
Disaster recovery is easier

18. Costs and Risks of the Database Approach
New specialized personnel
Up-front costs:
Installation Management Cost and Complexity
Conversion Costs
Ongoing Costs
Requires New, Specialized Personnel
Need for Explicit Backup and Recovery
Organizational Conflict
Old habits die hard
Other hidden costs

19. Why Do We Still Learn File Processing Systems?
File processing systems are still widely used today, especially for backing up database systems.
Understanding the problems and limitations inherent in file processing systems can help us avoid these same problems when designing database.

20. Elements of the Database Approach
Data models
Graphical system capturing nature and relationship of data
Enterprise Data Model–high-level entities and relationships for the organization
Project Data Model–more detailed view, matching data structure in database or data warehouse
Entities
Noun form describing a person, place, object, event, or concept
Composed of attributes
Relationships
Between entities
Usually one-to-many (1:M) or many-to-many (M:N)
Relational Databases
Database technology involving tables (relations) representing entities and primary/foreign keys representing relationships

21. How about the relationship between ORDER and PRODUCT?
A Data Model on Customer and Order
Segment of an Enterprise Data Model
CUSTOMER
ORDER M
Q1. One CUSTOMER normally places ___ ORDER? 1
Q2. One ORDER normally is placed by __ CUSTOMER?
How about the relationship between ORDER and PRODUCT?
(see next slide)

22. How about the relationship between ORDER and PRODUCT?
A Data Model on Customer and Order
Segment of an Enterprise Data Model
CUSTOMER
ORDER M
Q1. One CUSTOMER normally places ___ ORDER? 1
Q2. One ORDER normally is placed by __ CUSTOMER?
How about the relationship between ORDER and PRODUCT?
(see next slide)

23. Figure 1-3: Comparison of enterprise and project level data models
ORDER
ORDER_NUMBER
Customer_ID
Order_Date
Q3. One PRODUCT normally is contained in __ ORDER? M
Q4. One ORDER normally contains __ PRODUCT? M

24. Figure 1-3: Comparison of enterprise and project level data models
ORDER
ORDER_NUMBER
Customer_ID
Order_Date
Q3. One PRODUCT normally is contained in __ ORDER? M
Q4. One ORDER normally contains __ PRODUCT? M

25. Q: what are two major differences between (a) & (b)?
Figure 1-3: Comparison of enterprise and project level data models
(a) Segment of an Enterprise Data Model
Q: what are two major differences between (a) & (b)?
(b) Segment of a Project-Level Data Model
Q: what are major differences between (a) & (b)?
In (a) high-level (entities only); in (b) with fields
M -> M was broken into two 1 -> M

26. Figure 3 Figure 1-3 Segment from Enterprise Data Model
Enterprise data model is a graphical model that shows the high-level entities for the organization and the relationship among these entities. (E/R Diagram)

27. Figure 1-3 Segment from enterprise data model
One customer may place many orders, but each order is placed by a single customer
 One-to-many relationship

28. Figure 1-3 Segment from enterprise data model
One order has many order lines; each order line is associated with a single order
 One-to-many relationship

29. Figure 1-3 Segment from enterprise data model
One product can be in many order lines, each order line refers to a single product
 One-to-many relationship

30. Figure 1-3 Segment from enterprise data model
Therefore, one order involves many products and one product is involved in many orders
 Many-to-many relationship

31. Figure 1-4 Enterprise data model for Figure 1-3 segments

32. Figure 1-5 Components of the Database Environment

33. Components of the Database Environment
CASE Tools–computer-aided software engineering
Repository–centralized storehouse of metadata
Database Management System (DBMS) –software for managing the database
Database–storehouse of the data
Application Programs–software using the data
User Interface–text and graphical displays to users
Data/Database Administrators–personnel responsible for maintaining the database
System Developers–personnel responsible for designing databases and software
End Users–people who use the applications and databases

34. Evolution of Database Technologies
Flat files s s
Hierarchical – 1970s s
Network – 1970s s
Relational – 1980s - present
Object-oriented – 1990s - present
Object-relational – 1990s - present
Data warehousing – 1980s - present

35. Figure 1-10a Evolution of Database Technologies

36. Figure 1-10b Database architecture

37. Figure 1-10b Database architecture

38. The Range of Database Applications
Personal databases
Two-tier Client/Server databases
Multitier/N Client/Server (or called web-enabled) databases
Enterprise applications
Enterprise resource planning (ERP) systems
Data warehousing implementations
(Web-enabled Database )
(Wide Area Network)
(WAN)
(Local Area Network)

39. Figure 1-11 Two-tier database with local
area network
Chapter 1

40. Figure 1-12 Three-tiered client/server database architecture
Chapter 1

41. Muti/N-tier: Web-Enabled Databases
Web applications requiring databases
Customer relationship management (CRM)
Business-to-consumer (B2C)
Electronic data interchange (EDI)
Private intranets
XML-defined Web services 41

42. Enterprise Applications
Enterprise Resource Planning (ERP)
Integrate all enterprise functions (manufacturing, finance, sales, marketing, inventory, accounting, human resources)
Data Warehousing implementation
Integrated decision support system derived from various operational databases

43. Break ! (Ch. 1) Exercise #1 (p.44)
Homework: 1. Complete chapter1 quiz by Sunday evening. 2. HW#12 (a) only (homework assignment high-level (no attributes) draw by Visio clearly turn in a hardcopy next class

44. Be Prepared for ...

45. Discuss HW
HW#12 (a)
Volunteer?

46. Enterprise Data Model
Enterprise data model is a graphical model that shows the high-level entities for the organization and the relationship among these entities. (E/R Diagram)
Enterprise data modeling is the first step in database development, in which the scope and general contents of organizational databases are specified.
Descriptions of entity types
Relationships between entities
Business rules
Is EDA (Enterprise Data Modeling) a top-down or bottom-up approach? (top-down; p.24)
Q: Is ER/M a top-down or bottom-up approach?

47. Steps in the Database Development Process
Enterprise Modeling
Conceptual Data Modeling
Cuts across Project Initiation and Planning & Analysis phases of SDLC
Logical Database Design (E/R)
Physical Database Design and Creation
Database Implementation
Database Maintenance

48. Life Cycle Phases of DA and DBA (Ch.11)
Database Planning
Database Analysis
Database Design
Database Implementation
Operations and Maintenance
Growth and Change

49. Two Approaches to Database and IS Development
SDLC
System Development Life Cycle
Detailed, well-planned (and structured) development process
Time-consuming, but comprehensive
Long development cycle
Prototyping
Rapid application development (RAD)
Cursory attempt at conceptual data modeling
Define database during development of initial prototype
Repeat implementation and maintenance activities with new prototype versions
Tool: Oracle Designer

50. Database Design Systems Development Life Cycle (SDLC)
Entity-relationship model (E-R model)
Normalization

51. Systems Development Life Cycle
Systems Implementation
Product:
Operational System
Systems Investigation
(Definition) Product:
Feasibility Study
Systems Analysis
Functional Requirements
Systems Design
System Specifications
Systems Maintenance
Improved System
Understand the
Business
Problem or
Opportunity
Develop an
Information
System
Solution
The traditional information systems development cycle is based upon the stages in the systems approach to problem solving, where each step is interdependent on the previous step:
Systems Investigation. This stage may begin with a formal information systems planning process to help sort out choices from many opportunities. Typically, due to the expense associated with information systems development this stage includes a cost/benefit analysis as part of a feasibility study.
Systems Analysis. This stage includes an analysis of the information needs of end users, the organizational environment, and any system currently used to develop the functional requirements of a new system.
Systems Design. This stage develops specifications for the hardware, software, people, network, and data resources of the system. The information products the system is expected to produce are also designated.
Systems Implementation. Here the organization develops or acquires the hardware and software needed to implement the system design. Testing of the system and training of people to operate and use the system are also part of this stage. Finally, the organization converts to the new system.
Systems Maintenance. In this stage, management uses a postimplementation review process to monitor, evaluate, and modify the system as needed.
Implement
the Information
System
Solution
2000 McGraw-Hill Companies

52. Prototyping
Prototpying is one of the most popular rapid application development (RAD) methods.
It is an iterative process of system development in which requirements are converted to a working system that is continually revised through close work between analysts and users.
A prototype is a small, but working system that contains only those important (not complete) features.

53. Systems Development Life Cycle (see also Figure 1-7)
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Physical Design
Implementation
Maintenance
Logical Design

54. Systems Development Life Cycle (see also Figure 1.7)
Project Identification
and Selection
Purpose --preliminary understanding
Deliverable –request for project
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
enterprise modeling
Implementation
Maintenance

55. Systems Development Life Cycle (see also Figure 1.7)
Project Identification
and Selection
Purpose – state business situation and solution
Deliverable – request for analysis
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
conceptual data modeling
Implementation
Maintenance

56. Systems Development Life Cycle (see also Figure 1.7)
Project Identification
and Selection
Purpose –thorough analysis
Deliverable – functional system specifications
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
conceptual data modeling
Implementation
Maintenance

57. Systems Development Life Cycle (see also Figure 1.7)
Project Identification
and Selection
Purpose –information requirements structure
Deliverable – detailed design specifications
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
logical database design
Implementation
Maintenance

58. Systems Development Life Cycle (see also Figure 1.7)
Purpose –develop technology specs
Deliverable – program/data structures, technology purchases, organization redesigns
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
physical database design
Implementation
Maintenance

59. Systems Development Life Cycle (see also Figure 1.7)
Purpose –programming, testing, training, installation, documenting
Deliverable – operational programs, documentation, training materials
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
database implementation
Implementation
Maintenance

60. Systems Development Life Cycle (see also Figure 1.7)
Project Identification
and Selection
Purpose –monitor, repair, enhance
Deliverable – periodic audits
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Database activity –
database maintenance
Implementation
Maintenance

61. Figure 1-7: Database development activities during the systems development life cycle (SDLC)
Planning (Enterprise modeling)
Project Identification
and Selection
Conceptual data modeling
Project Initiation
and Planning
Analysis
Integrate database views
and perform normalization
Upper
CASE tool
(Front-end)
Logical Design
Physical Design
Implementation
Lower CASE tool
(Back-end)
Maintenance
Growth and Change

62. Figure 1-8The prototyping methodology and database development process62 62

63. Figure 1-8 The prototyping methodology and database development process (cont.)63 63

64. Figure 1-8 The prototyping methodology and database development process (cont.)64 64

65. Figure 1-8 The prototyping methodology and database development process (cont.)65 65

66. Figure 1-8 The prototyping methodology and database development process (cont.)66 66

67. Managing Projects
Project–a planned undertaking of related activities to reach an objective that has a beginning and an end
Initiated and planned in planning stage of SDLC
Executed during analysis, design, and implementation
Closed at the end of implementation

68. Managing Projects: People Involved
Project is a planned undertaking of related activities to reach an objective that has a beginning and an end
People involved:
Business analysts – work with management and users to analyze business
Systems analysts - business situation and IS needs
Database analysts and modelers - requirements and design for the database component of the IS
Users - assessment of their information needs and monitor the developed system meet their needs
Programmers – design and write computer programs
Database architects – establish standards
Database and data administrators - ensure database consistency, integrity and provide consulting, training etc..
Project managers – oversees assigned projects
Other technical experts - network administrators, testers, technical writers

69. The Technology Level of Models
Conceptual models focus on the underlying content of an information system with no assumptions about technology
Logical models assume a general class of technology (H/S W independent) – a relational database
Internal models assume specific technologies – for example, an Oracle database engine

70. Database Schema
External Schema (during the analysis and logical design phases)
User Views
Subsets of Conceptual Schema
Can be determined from business-function/data entity matrices
DBA determines schema for different users
This is part of people-management in databases
Conceptual Schema
ER models (during the analysis phase)– covered in chapters 2 and 3
Internal Schema
Logical structures–covered in Chapter 4
Physical structures–covered in Chapter 5

71. Figure 1-9 Three-schema architecture
Different people have different views of the database…these are the external schema
The internal schema is the underlying design and implementation` 71 71

72. External Schema E/R, OO … Relations Database Internal Schema
Figure 1-9: Three-schema database architecture
External
Schema
Ch. 4
E/R, OO …
Relations
Database
Ch. 2,3,4
Meta-data/
Repository/
D.D.
All good (database) things comes in threes!!!
The pictures at the top level indicate that some views are for users, some for reports and some for application programs.
The logical level is where the data is seen as being composed of tables.
At the physical level, files are stored on disk.
The mappings are specified by developers and because of the capabilities of DBMSs, no programs must be written to support these levels.
What is the “Three-schema Architecture” for?
Help to identify user requirements in an efficient, correct way (systematically).
- iterative process
- systematical way
Ch. 5
Internal
Schema N

73. Levels of database schemas
Different schemas are presented to different users
All good (database) things comes in threes!!!
The pictures at the top level indicate that some views are for users, some for reports and some for application programs.
The logical level is where the data is seen as being composed of tables.
At the physical level, files are stored on disk.
The mappings are specified by developers and because of the capabilities of DBMSs, no programs must be written to support these levels.
What is the “Three-schema Architecture” for?
Help to identify user requirements in an efficient, correct way (systematically).
- iterative process
- systematical way N

74. Exercise/Homework Homework (1) #17 ; p.45; three views with E/R
- Statement View
- Deposit View
- Conceptual View (an integrated view the
above two views)
Hint: account/customer is one of common entity
(Draw by Visio/Word, turn in hardcopy, due next class)
(2) Online Quiz#1 (due date, midnight Sunday)

75. FIGURE 1-15 (a): Preliminary data model for Home Office product line marketing support system

76. FIGURE 1-15: Project data model for Home Office product line marketing support system