The Database Environment and Development Process An Overview

Outline  Basic concepts and definitions  Benefits of Database Management Systems (DBMS)  A brief look at the Relational DBMS  Types of Database Applications  Database Development Process

Basic Concepts and Definitions  Database An organized collection of logically related data  a list of clients, or customer orders  organized in a way that enables fast and efficient storage, access and manipulation  Data Facts that can be recorded and stored using computer media  traditionally this included text and numbers  modern usage now includes objects such as sounds, images, and video clips

Database System  The application of technology to business processes, gathering data and creating information that is valuable to managers who make decisions N. Caroline Daniels, IT: The Management Challenge  A model of an enterprise that captures the information structure and content which describes and operationalizes the function of the enterprise. Les Waguespack

Information Data that has been processed in such a way that it can increase the knowledge of the person who uses it Examples are data that has been:  placed in a context (see next slide)  summarized (e.g., as in a graph)

Raw Data How to interpret this?

Metadata Data that describes the properties or characteristics of other data (a means of providing context for data) See Table 1-1 in textbook

Figure 1-1a Data in Context Even when the context is provided, large volume of facts is difficult to analyze or make decisions based on. ……………

Figure 1-1b Summarized data

Outline  Basic concepts and definitions  Benefits of Database Management Systems (DBMS)  A brief look at the Relational DBMS  Types of Database Applications  Database Development Process

Traditional File Processing  Date back to before we had databases  Still in use today, including backup of database systems

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

Problems with Data Redundancy  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

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

Database Management System DBMS manages data resources like an operating system manages hardware resources DBMS Database containing centralized shared data Application #1 Application #2 Application #3

Database Management Systems (DBMS)  DBMS: General-purpose software system which permits data to be stored non-redundantly and facilitates the processes of defining, creating, using and maintaining databases  Database and Repository: Includes data and metadata that describes the database  data - the actual values of interest  metadata - descriptions of the characteristics of the stored data Data and metadata are stored in one place, outside of the application program (decoupled from the code).

Advantages of Database Approach  Program-Data Independence Metadata stored in DBMS, so applications don’t need to worry about data formats 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

Advantages of Database Approach  Improved Data Sharing Different users get different views of the data  Enforcement of Standards All data access is done in the same way  Improved Data Quality Constraints, data validation rules  Better Data Accessibility/ Responsiveness Use of standard data query language (SQL)  Security, Backup/Recovery, Concurrency Disaster recovery is easier

Costs and Risks of the Database Approach  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

Evolution of DB Systems  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  Web-enabled – 1990s - present

Outline  Basic concepts and definitions  Benefits of Database Management Systems (DBMS)  A brief look at the Relational DBMS  Types of Database Applications  Database Development Process

Relational Databases Organize Data in Tables Each column represents a Field (a.k.a attribute, characteristic) Each row represents a Record (a.k.a instance, tuple)

May seem simple, but… Example: poorly designed database. The purpose of this table is to keep track of students, their majors, advisors and their addresses. ST_ID ST_FIRST ST_LAST ST_MAJOR ADV_FIRST ADV_LAST ADV_ ADV_ID Consider what would happen when the table has to be updated to reflect the following events: 1.Sandra Smith graduates. 2.Galilei’s has changed 3.A new professor is hired and has to be assigned an ID but has not yet been assigned any students to advise.

The Database Design Process  Conceptual Database Design Entity-Relationship Diagrams (ERDs)  Logical Database Design Translate the conceptual model into files, tables, or objects (depending on type of DBMS)  Physical Database Design Lay out the actual DBMS architecture

Figure 1-3 Conceptual data model (ERD)

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

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

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

Figure 1-4 Order, Order_Line, Customer, and Product tables Relationships established in special columns (or tables) that provide links between tables representing the entities.

Data Tables (Relations)

Relationships

Outline  Basic concepts and definitions  Benefits of Database Management Systems (DBMS)  A brief look at the Relational DBMS  Types of Database Applications  Database Development Process

The Range of Database Applications  Personal Database – standalone desktop database  Workgroup Database – local area network (<25 users)  Department Database – local area network ( users)  Enterprise Database – wide-area network (hundreds or thousands of users)

Components of the Database Environment  CASE Tools – Computer-Aided Software Engineering tools  Database Management System (DBMS) – software for managing the database Database – storehouse of the data Repository – centralized storehouse of metadata  Application Programs – software using the data User Interface – text and graphical displays to users

Human Resources Needed  Systems Analysts  Database Analysts/Designers  Data/Database Administrators  Programmers

Database Responsibilities  Responsibilities Data planning for the long term Define standards Conceptual and logical design (ERDs and LDMs) Physical design Data integrity and working with other departments  Responsibilities Data security Database performance Backup/recovery Business rules Determine user requirements (interviewing users) Design database applications Program database applications

Outline  Basic concepts and definitions  Benefits of Database Management Systems (DBMS)  A brief look at the Relational DBMS  Types of Database Applications  Database Development within IS Development Process

Information Systems Architecture “A conceptual blueprint or plan that expresses the desired future structure for the information systems in an organization.”

Information Systems Architecture  Key components: data processes which manipulate data network which transports data people who perform processes and send and receive data events and points in time when processes are performed reasons for events and rules which govern data processing

Information Engineering “An Information Systems Architecture is developed by IS planners following a particular methodology such as Information Engineering.”

Information Engineering  A data-oriented methodology to create and maintain information systems  Uses top-down planning in which specific information systems are deduced from a broad understanding of organizational information needs, rather than relying on specific user information requests  Offers perspective on relationship of information systems to business objectives

Top-Down vs. Bottom-Up Top-Down Planning: “A methodology that attempts to gain a broad understanding of the information system needs of the entire organization” Bottom-Up Planning: “A methodology that identifies and defines IS development projects based upon solving operational business problems or taking advantage of business opportunities”

Information Engineering Planning  Identify strategic planning factors Goals Critical success factors Problem areas  Identify corporate planning objects Organizational units Locations Business functions Entity types  Develop enterprise model Process decomposition Enterprise data model (e.g., ERD)

Figure Example of process decomposition of an order fulfillment function (Pine Valley Furniture) Decomposition -- breaking large tasks into smaller tasks in a hierarchical structure chart

Enterprise Data Modeling “The first step in database development, in which the scope and general contents of organizational databases are specified.”

Enterprise Data Model  A model which includes: overall range of organizational databases general contents of organizational databases  Built as part of IS planning for the organization and not the design of a particular database  One part of an organization’s overall information systems architecture (ISA)

Figure 2-1 Segment from enterprise data model (Pine Valley Furniture Company) [simplified E-R diagram, repeat of figure 1.3] Enterprise data model describes the entities in an organization and the relationship between these entities

Example business function-to-data entity matrix (fig. 2.3) Business PlanningX X X X Product Development X X X X Materials Management X X X X X X Order FulfillmentX X X X X X X X X Order ShipmentX X X X X X Sales SummarizationX X X X X Production Operations X X X X X X X Finance and AccountingX X X X X X X X Customer Product Raw Material Order Work Center Work Order Invoice Equipment Employee Business Function (users) Data Entity Types

Alternative Approaches to Database and IS Development  SDLC System Development Life cycle Detailed, well-planned 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. Especially useful for extending the IS functionality.

Systems Development Life Cycle (SDLC) (figures 2.4, 2.5) Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design

Database development within SDLC Identify Project Initiate and Plan Analyze Logical Design Physical Design Implementation Maintenance Enterprise Data Modeling Conceptual Data Modeling Logical DB Design Physical DB Design/Creation DB Implementation DB Maintenance Database Development Activities SDLC

Enterprise Modeling Conceptual Data Modeling Logical DB Design Physical DB Design/Creation DB Implementation DB Maintenance Enterprise Data Model  First step in database development  Specifies scope and general content  Overall picture of organizational data, not specific design  Entity-relationship diagram Descriptions of entity types Relationships between entities Business rules

 Determine user requirements  Determine business rules  Build conceptual data model outcome is an entity-relationship diagram or similar communication tool Conceptual Database Modeling Enterprise Modeling Conceptual Data Modeling Logical DB Design Physical DB Design/Creation DB Implementation DB Maintenance

Logical Database Design  Select logical database model  Map Entity-Relationship Diagrams  Normalize data structures  Specify business rules Enterprise Modeling Conceptual Data Modeling Logical DB Design Physical DB Design/Creation DB Implementation DB Maintenance

Physical Database Design  Select DBMS  Select storage devices  Determine access methods  Design files and indexes  Determine database distribution  Specify update strategies Enterprise Modeling Conceptual Data Modeling Logical DB Design Physical DB Design/Creation DB Implementation DB Maintenance

The Prototyping Approach Identify User Needs Develop Prototype Evaluate Prototype Prototype Acceptable? Implement Prototype Rev iseRev ise