Chapter 1: The Database Environment and Development Process - PowerPoint Presentation

Slide1

Chapter 1:The Database Environment and Development Process

Modern Database Management

12

th

Edition

Jeff Hoffer, Ramesh

Venkataraman

,

Heikki

Topi

Slide2

Objectives / Self-study outline

Define

terms (Slides #3-6)

Name limitations of conventional file processingExplain advantages of databasesIdentify costs and risks of databases Elements of the Database Approach (Slides #12-20) List components of database environment (Slide #24) Enterprise data model (Slides #25-26) Identify categories of database applicationsDescribe database system development life cycleExplain prototyping and agile development approachesExplain roles of individualsExplain the three-schema architecture (Slides #40-41) Running example in the book (Slides #53-55)

2Slide3

Definitions

Database: organized collection of logically related data

Data: stored

representations of meaningful objects and eventsStructured: numbers, text, datesUnstructured: images, video, documentsInformation: data processed to increase knowledge of the person using the dataMetadata: data that describes the properties and context of user data – P.7 @ top3Slide4

Figure 1-1a Data in context

Context helps users understand dataSlide5

Graphical displays turn data into useful information that managers can use for decision making and interpretation

Figure 1-1b Summarized dataSlide6

Descriptions of the properties or characteristics of the data, including data types, field sizes, allowable values, and data contextSlide7

Disadvantages of File Processing

Program-Data Dependence

All programs maintain metadata for each file they use

Duplication of DataDifferent systems/programs have separate copies of the same dataLimited Data SharingNo centralized control of dataLengthy Development TimesProgrammers must design their own file formatsExcessive Program Maintenance80% of information systems budgetSlide8

Problems with Data Dependency

Each application programmer must maintain his/her 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 dataLack of coordination and central controlNon-standard file formatsSlide9

Duplicate DataSlide10

Problems with Data Redundancy

Waste of space to have duplicate data

Causes more maintenance headaches

The biggest problem: Data changes in one file could cause inconsistenciesCompromises in data integritySlide11

SOLUTION: The DATABASE Approach

Central repository of shared data

Data is managed by a controlling agent

Stored in a standardized, convenient formRequires a Database Management System (DBMS)Slide12

Database Management System

DBMS manages data resources

like an operating system manages hardware resourcesA software system that is used to create, maintain, and provide controlled access to user databasesOrder Filing System

Invoicing

System

Payroll

System

DBMS

Central database

Contains employee,

order, inventory,

pricing, and

customer dataSlide13

Elements of the Database Approach (1)

Data models

Graphical system capturing

nature and relationship of dataEnterprise Data Model–high-level entities and relationships for the organizationProject Data Model–more detailed view, matching data structure in database or data warehouse Entities – we met these concepts Week 1Noun form describing a person, place, object, event, or conceptComposed of attributesUnderstand entity type vs entity instanceSlide14

Elements of the Database Approach (2)

Relationships

Between entities

Usually one-to-many (1:M) or many-to-many (M:N)Relational DatabasesDatabase technology involving tables (relations) representing entities, and primary/foreign keys representing relationshipsSlide15

Segment of an

enterprise

data model

Segment of a project-level data modelFig 1-3 Comparison of enterprise and project level data models

15

high-level entities and relationships

detailed view, matching data structure Slide16

One customer

may place

many orders

, but each order is placed by a single customer One-to-many relationshipNote the expression of the relationshipSlide17

One order

has

many order lines

; each order line is associated with a single order One-to-many relationshipNote the expression of the relationshipSlide18

One product

can be in

many order lines

, each order line refers to a single product One-to-many relationshipSlide19

Therefore, one order involves many products and one product is involved in many orders

 Many-to-many relationship

A many-to-many relationship can be “decomposed” to two 1-M relationshipsSlide20
Slide21

Advantages of THE DatabaSE APPROACH

Program-data independence

Planned data redundancy

Improved data consistencyImproved data sharingIncreased application development productivityEnforcement of standardsImproved data qualityImproved data accessibility and responsivenessReduced program maintenanceImproved decision supportSlide22

Costs and Risks of the Database Approach

New, specialized personnel

Installation and management cost and complexity

Conversion costsNeed for explicit backup and recoveryOrganizational conflicton data definitions, formats and coding, rights to update…Slide23

Figure 1-5 Components of the

database environmentSlide24

Components of the Database Environment

Data modeling and design

tools

-- automated tools used to design databases and application programsRepository–centralized storehouse of metadataDatabase Management System (DBMS) –software for managing the databaseDatabase–storehouse of the dataApplication Programs–software using the dataUser Interface–text, graphical displays, menus, etc. for user Data/Database Administrators–personnel responsible for maintaining the databaseSystem Developers–personnel responsible for designing databases and softwareEnd Users–people who use the applications and databasesSlide25

Enterprise Data Model

First step in the database development process

Specifies scope and general content

Overall picture of organizational data at high level of abstractionEntity-relationship diagram (ERD)Descriptions of entity typesRelationships between entitiesBusiness rulesSlide26

FIGURE 1-6

Example business function-to-data entity matrixSlide27

Two Approaches to Database and IS Development

SDLC

System Development Life Cycle

Detailed, well-planned development processTime-consuming, but comprehensiveLong development cyclePrototypingRapid application development (RAD)Cursory attempt at conceptual data modelingDefine database during development of initial prototypeRepeat implementation and maintenance activities with new prototype versionsSlide28

Systems Development Life Cycle(see also Figure 1-7)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical DesignSlide29

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Planning

Purpose

–

preliminary understanding

Deliverable

–

request for study

Database activity

–

enterprise modeling and early conceptual data modelingSlide30

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Analysis

Purpose–thorough requirements analysis and structuring

Deliverable–functional system specifications

Database activity–thorough and integrated conceptual data modelingSlide31

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Logical Design

Purpose–information requirements elicitation and structure

Deliverable–detailed design specifications

Database activity–

logical database design (transactions, forms, displays, views, data integrity and security)Slide32

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Physical Design

Purpose–develop technology and organizational specifications

Deliverable–program/data structures, technology purchases, organization redesigns

Database activity–

physical database design (define database to DBMS, physical data organization, database processing programs)Slide33

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Implementation

Purpose–programming, testing, training, installation, documenting

Deliverable–operational programs, documentation, training materials

Database activity–

database implementation, including coded programs, documentation, installation and conversionSlide34

Systems Development Life Cycle(see also Figure 1-7) (cont.)

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Maintenance

Purpose–monitor, repair, enhance

Deliverable–periodic audits

Database activity–

database maintenance, performance analysis and tuning, error correctionsSlide35

Prototyping Database Methodology(Figure 1-8)

Prototyping is a classical Rapid Application Development (RAD) approachSlide36

Prototyping Database Methodology

(Figure 1-8) Slide37

Prototyping Database Methodology

(Figure 1-8) Slide38

Prototyping Database Methodology

(Figure 1-8) Slide39

Prototyping Database Methodology

(Figure 1-8) Slide40

Database Schema

External Schema

Can be determined from business-function/data entity

matrices (Fig 1-6)Enterprise model + User ViewsDuring the Analysis and Logical Design phasesConceptual SchemaE-R models–covered in Chapters 2 and 3A single, coherent definition of enterprise’s dataThe view of data architect or data adminDuring the Analysis phaseInternal Schema Logical structures–covered in Chapter 4Physical structures–covered in Chapter 5Slide41

Different people have different views of the database…these are the external schema

The internal schema is the underlying design and implementation

Figure 1-9 Three-schema architectureSlide42

Managing People and 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 implementationClosed at the end of implementationSlide43

Managing Projects: People Involved

Business analysts

Systems analysts

Database analysts and data modelersUsersProgrammersDatabase architectsData administratorsProject managersOther technical expertsSlide44

Figure 1-10a Evolution of database technologiesSlide45

Evolution of Database Systems

Driven by four main objectives:

Need for program-data independence

 reduced maintenanceDesire to manage more complex data types and structuresEase of data access for less technical personnelNeed for more powerful decision support platformsSlide46

Figure 1-10b Database architecturesSlide47

Figure 1-10b Database architectures (cont.)Slide48

Figure 1-10b Database architectures (cont.)Slide49

The Range of Database Applications

Personal databases

Two-tier and N-tier Client/Server databases

Enterprise applicationsEnterprise resource planning (ERP) systemsData warehousing implementationsSlide50

Figure

1-11 Multi-tiered

client/server database architectureSlide51

Enterprise Database Applications

Enterprise Resource Planning (ERP)

Integrate all enterprise functions (manufacturing, finance, sales, marketing, inventory, accounting, human resources)

Data WarehouseIntegrated decision support system derived from various operational databasesSlide52

FIGURE 1-13 Computer

System for Pine Valley

Furniture CompanySlide53

53

Fig 1-14 Preliminary data modelSlide54
Slide55

FIGURE

1-15

Project data model for Home Office product line marketing support system