Download The Database Environment

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Big data wikipedia , lookup

Extensible Storage Engine wikipedia , lookup

Relational model wikipedia , lookup

Database wikipedia , lookup

Functional Database Model wikipedia , lookup

Clusterpoint wikipedia , lookup

Database model wikipedia , lookup

Transcript
Unit 1:
Background and Terminology
Chapters 1 + 2:
Modern Database Management
9th Edition
Jeffrey A. Hoffer, Mary B. Prescott,
Heikki Topi
© 2009 Pearson Education, Inc. Publishing as Prentice Hall
1
Definitions


Database: organized collection of logically
related data
Data: stored representations of meaningful
objects and events




Structured: numbers, text, dates
Unstructured: images, video, documents
Information: data processed to increase
knowledge in the person using the data
Metadata: data that describes the properties and
context of user data
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
2
Figure 1-1a Data in context
Context helps users understand data
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
3
Figure 1-1b Summarized data
Graphical displays turn data into useful
information that managers can use for
decision making and interpretation
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
4
Descriptions of the properties or characteristics of the
data, including data types, field sizes, allowable
values, and data context
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
5
Figure 11-6
Example of DBMS
log entry
Data Characteristics
Status vs. Event Data
Status
Event =
a database action
(create/update/delete) that
results from a transaction
Status
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
6
Figure 11-7
Transient
operational data
Data Characteristics
Transient vs. Periodic Data
With
transient
data,
changes
to existing
records
are
written
over
previous
records,
thus
destroying
the
previous
data
content7
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Figure 11-8
Periodic
warehouse data
Data Characteristics
Transient vs. Periodic Data
Periodic
data are
never
physically
altered or
deleted
once they
have
been
added to
the store
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
8
Derived Data


Data that can be computed as opposed to
stored facts.
Objectives





Ease of use for decision support applications
Fast response to predefined user queries
Customized data for particular target audiences
Ad-hoc query support
Data mining capabilities
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
9
Duplicate Data
10
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Disadvantages of File Processing

Program-Data Dependence


Duplication of Data


No centralized control of data
Lengthy Development Times


Different systems/programs have separate copies of the same data
Limited Data Sharing


All programs maintain metadata for each file they use
Programmers must design their own file formats
Excessive Program Maintenance

80% of information systems budget
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
11
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 data
Lack of coordination and central control
Non-standard file formats
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
12
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
inconsistencies
 Compromises in data integrity

Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
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)
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
14
Database Management System

A software system that is used to create, maintain, and provide
controlled access to user databases
Order Filing
System
Invoicing
System
Payroll
System
DBMS
Central database
Contains employee,
order, inventory,
pricing, and
customer data
DBMS manages data resources like an operating system manages hardware resources
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
15
Advantages of the Database Approach










Program-data independence
Planned data redundancy
Improved data consistency
Improved data sharing
Increased application development productivity
Enforcement of standards
Improved data quality
Improved data accessibility and responsiveness
Reduced program maintenance
Improved decision support
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
16
Costs and Risks of the Database
Approach





New, specialized personnel
Installation and management cost and
complexity
Conversion costs
Need for explicit backup and recovery
Organizational conflict
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
17
Elements of the Database Approach

Data models




Relational Databases


Database technology involving tables (relations) representing
entities and primary/foreign keys representing relationships
Use of Internet Technology


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
Networks and telecommunications, distributed databases, clientserver, and 3-tier architectures
Database Applications

Application programs used to perform database activities
(create, read, update, and delete) for database users
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
18
Figure 1-5 Components of the Database Environment
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
19
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
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
20
The Range of Database Applications




Personal databases
Workgroup databases
Departmental/divisional databases
Enterprise database


Enterprise resource planning (ERP) systems
Data warehousing implementations
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
21
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
22
Figure 1-7 Workgroup database with wireless
local area network
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
23
Enterprise Database Applications

Enterprise Resource Planning (ERP)


Integrate all enterprise functions
(manufacturing, finance, sales, marketing,
inventory, accounting, human resources)
Data Warehouse

Integrated decision support system derived
from various operational databases
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
24
Data Warehousing

Data Warehouse:






A subject-oriented, integrated, time-variant, nonupdatable collection of data used in support of
management decision-making processes
Subject-oriented: e.g. customers, patients,
students, products
Integrated: Consistent naming conventions,
formats, encoding structures; from multiple data
sources
Time-variant: Can study trends and changes
Non-updatable: Read-only, periodically
refreshed
Data Mart:

A data warehouse that is limited in scope
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
25
Need for Data Warehousing


Integrated, company-wide view of high-quality
information (from disparate databases)
Separation of operational and informational systems
and data (for improved performance)
Table 11-1 – Comparison of Operational and Informational Systems
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
26
Figure 1-8 An enterprise data warehouse
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
27
Figure 11-2 Independent data mart
data warehousing architecture
Data marts:
Mini-warehouses, limited in scope
L
T
E
Data access complexity
Separate ETL for each
independent data mart due to multiple data marts
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
28
Figure 11-3 Dependent data mart with
operational data store: a three-level architecture
ODS provides option for
obtaining current data
L
T
E
Single ETL for
enterprise data warehouse (EDW)
Simpler data access
Dependent data marts
loaded from EDW
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
29
Figure 11-4 Logical data mart and real
time warehouse architecture
ODS and data warehouse
are one and the same
L
T
E
Chapter 1
Data marts are NOT separate databases,
Near real-time ETL for but logical views of the data warehouse
Data Warehouse
 Easier to create new data marts
© 2009 Pearson Education, Inc. Publishing as Prentice Hall
30
Application Logic in C/S Systems
Presentation Logic


Input–keyboard/mouse
Output–monitor/printer
GUI Interface
Processing Logic



I/O processing
Business rules
Data management
Procedures, functions,
programs
Storage Logic

Data storage/retrieval
DBMS activities
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
31
Client/Server Architectures
Client does
extensive processing

File Server Architecture

Database Server Architecture

Three-tier Architecture
Client does little
processing
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
32
File Server Architecture



All processing is done at the PC that requested
the data
FAT CLIENT
Entire files are transferred from the server to the
client for processing
Problems:


Huge amount of data transfer on the network
Each client must contain full DBMS


Heavy resource demand on clients
Client DBMSs must recognize shared locks, integrity checks,
etc.
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
33
Figure 9-2 File server model
FAT CLIENT
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
34
Two-Tier Database Server
Architectures

Client is responsible for
I/O processing logic
 Some business rules logic


Server performs all data storage and
access processing
 DBMS is only on server
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
35
Three-Tier Architectures
GUI interface
(I/O processing)
Client
Application server
Database server
Business rules
Data storage
Browser
Web Server
DBMS
Thin Client

PC just for user interface and a little application
processing. Limited or no data storage (sometimes no
hard drive)
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
36
Figure 9-4a Generic three-tier architecture
Thinnest
clients
Business rules
on separate
server
DBMS only on
DB server
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
37
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
38
Common Logic Distributions
Figure 9-5a Two-tier clientserver environments
Processing logic could be
at client, server, or both
Figure 9-5b n-tier clientserver environment
Processing logic
will be at
application server
or Web server
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
39
Middleware



Software that allows an application to
interoperate with other software
No need for programmer/user to
understand internal processing
Accomplished via Application Program
Interface (API)
The “glue” that holds client/server applications together
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
40
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
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
41
Web-Enabled Databases (cont.)

Issues to consider




Which technologies to use?
Security/privacy protection
Managing huge volumes of data from Internet
transactions
Maintaining data quality
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
42
Figure 10-1 Database-enabled intranet/internet environment
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
43
Server-Side Extensions


Programs that interact directly with Web
servers to handle requests
e.g. database-request handling middleware
Figure 10-2 Web-to-database middleware
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
44
Figure 10-7 Web services deployment
(adapted from Newcomer, 2002)
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
45
Table 1-6 Summary of Database Applications
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
46
All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher. Printed in the United States of America.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
Chapter 1 © 2009 Pearson Education, Inc. Publishing as Prentice Hall
47