0% found this document useful (0 votes)
55 views46 pages

DBMS Lec 03 & 04

The document discusses the database environment and development process. It begins with definitions of key terms like database, data, information, and metadata. It then covers topics such as the costs and risks of a database approach, database management systems, different types of database architectures including personal databases, client-server databases, and enterprise applications. The document also discusses distributed databases and data warehouses. It concludes with an overview of the database development life cycle.

Uploaded by

agha ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
55 views46 pages

DBMS Lec 03 & 04

The document discusses the database environment and development process. It begins with definitions of key terms like database, data, information, and metadata. It then covers topics such as the costs and risks of a database approach, database management systems, different types of database architectures including personal databases, client-server databases, and enterprise applications. The document also discusses distributed databases and data warehouses. It concludes with an overview of the database development life cycle.

Uploaded by

agha ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 46

The Database Environment

and Development
Process

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 2
Figure 1-1a Data in context

Context helps users understand data

3
Figure 1-1b Summarized data

Graphical displays turn data into useful


information that managers can use for
decision making and interpretation

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

5
Database Management System
 A software system that is used to create, maintain, and provide
controlled access to user databases

Order Filing
System

Invoicing Central database


DBMS
System Contains employee,
order, inventory,
pricing, and
Payroll
customer data
System

DBMS manages data resources like an operating system manages hardware


resources
6
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

7
Elements of the Database Approach
 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:M)
 Relational Databases
 Database technology involving tables (relations) representing
entities and primary/foreign keys representing relationships

8
Figure 1-3 Comparison of enterprise and project level data models
Segment of an enterprise data model

Segment of a project-level data model

9
An Enterprise Data Model is an integrated view of the data
produced and consumed across an entire organization.
It is independent of “how” the data is physically sourced,
stored, processed or accessed. The model unites, formalizes
and represents the things important to an organization, as well
as the rules governing them

A Project Model uses a framework or formula for a project


with user-defined variables to create an accurate project plan
and cost estimate. Once the model is configured and inserted,
little to no further editing is required.
One customer
may place many
orders, but each
order is placed by
a single
customer
 One-to-many
relationship

11
One order has
many order lines;
each order line
is associated
with a single
order
 One-to-many
relationship

12
One product can
be in many
order lines, each
order line
refers to a
single product
 One-to-many
relationship

13
Three Level Architecture Database
Physical Level
• The physical level describes how data is
actually stored in the database.
• The data is stored in the external hard drives in
the form of bits and at a little high level
• The physical level also discusses compression
and encryption techniques.
Conceptual Level
• It describes how the database appears to the
users conceptually and the relationships
between various data tables
• The conceptual level does not care for how the
data in the database is actually stored.
External level
• It only shows the relevant database content to
the users in the form of views and hides the
rest of the data.
• Different users can see the database as a
different view as per their individual
requirements.
Data Independence

• Data Independence is defined as a property of DBMS that


helps you to change the Database schema at one level of a
database system without requiring to change the schema at the
next higher level.

• Data independence helps you to keep data separated from all


programs that make use of it.

• In many systems, data independence is an essential function


for components of the system.
The Range of Database Applications

 Personal databases
 Two-tier Client/Server databases
 Multitier Client/Server databases
 Enterprise applications
 Enterprise resource planning (ERP) systems
 Data warehousing implementations

16
17
Personal Databases
A personal database is one that is designed for a single person. It is
typically stored on a personal computer and has a very simple design,
consisting of only a few tables. Personal databases are not typically
suitable for complex operations, large amounts of data or business
operations.

2-Tier Architecture
A 2 Tier Architecture in DBMS is a Database architecture where the
presentation layer runs on a client (PC, Mobile, Tablet, etc.), and
data is stored on a server called the second tier. Two tier
architecture provides added security to the DBMS as it is not
exposed to the end-user directly. It also provides direct and faster
communication.
Figure 1-6 Two-tier database with local
area network

19
3-Tier Architecture
A 3 Tier Architecture in DBMS is the most popular client server
architecture in DBMS in which the development and maintenance of
functional processes, logic, data access, data storage, and user interface is
done independently as separate modules.
Three Tier architecture contains a presentation layer, an application layer,
and a database server.

1.Presentation layer (your PC, Tablet, Mobile, etc.)


2.Application layer (server)
3.Database Serve
The Application layer resides between the user and the DBMS,
which is responsible for communicating the user’s request to the
DBMS system and send the response from the DBMS to the user.

The application layer (business logic layer) also processes


functional logic, constraint, and rules before passing data to the
user or down to the DBMS.
Distributed DBMSs
In a distributed database, there are a number of databases that may
be geographically distributed all over the world.

A distributed DBMS manages the distributed database in a manner so


that it appears as one single database to users

It is a collection of multiple interconnected databases, which are


spread physically across various locations that communicate via a
computer network

A centralized distributed database management system (DDBMS)


manages the distributed data as if it were stored in one physical
location.

DDBMS synchronizes all data operations among databases and


ensures that the updates in one database automatically reflect on
databases in other sites.
Data Warehouse
A Data Warehouse consists of data from multiple
heterogeneous data sources and is used for analytical
reporting and decision making. Data Warehouse is a central
place where data is stored from different data sources and
applications.
Difference Between Distributed
database and Data Warehouse
They are two very different things:

A distributed database is a system where different parts of


the database are distributed at different locations. You need
some clever technology to keep the parts of the database
synchronized across locations.

A data warehouse is a complex business system that includes


a database for storing data, and also a means of pulling in the
data from an outside source and doing something with it
before storing it.
Database Development Life Cycle

A database is usually a fundamental component of


information system, especially in business oriented
systems. Thus database design is part of system
development.

The database development life cycle is a process of


designing, implementing and mainting a database
system to meet strategic or operational information
needs of an organization or enterprise.
Database Planning
The very first step in database planning is to define the mission
statement and objectives for the database system. That is the
definition of:

- The major aims of the database system


- The purpose of the database system
- The supported tasks of the database system.
- The resources of the database system
Systems Definition
The description includes:
• Links with the other information systems of the organization
• What the planned systems is going to do now and in the future
• Who the users are now and in the future.

The major user views are also described i.e. what is required of a
database system from the perspectives of particular job roles or
enterprise application areas.

Requirement Collection and Analysis

The results may include e.g.:


• The description of the data used or generated
• The details how the data is to be used or generated
• Any additional requirements for the new database system
Database Design
The database design phase is divided into three steps:
• Conceptual database design:
The model of data to be used independent of all physical considerations. The
model is based on the requirements specification of the system.
• Logical database design:
The model of the data to be used is based on a specific data model, but
independent of a particular database management system is constructed.
• Physical database design
The description of the implementation of the database on secondary storage
is created. The base relations, indexes, integrity constraints, security etc and
defined using the SQL language.

Database Management system Selection:


• When there is need for new database management system (Access, SQL
Server, My SQL, Oracle), this phase is done.
• The serval products are evaluated according to the criteria and finally the
recommendation for the selection is decided.
Application Design
The design of user interface and the application programs that use and
process the database are defined and designed.

Prototyping
The purpose of a prototype is to allow the users to use the prototype to
identify the features of the system using the computer.

There are horizontal and vertical prototypes.


A horizontal prototype has many features (e.g. user interfaces) but they
are not working.
A vertical prototype has a very few feature but they are working.
Implementation
The programming phase of the systems development.

Data Conversion and Loading:


This phase is needed when new database is replacing an old system. During this
phase the existing data will be transferred into new database.

Testing
System should be thoroughly tested. The goal of testing is to find errors. The
goal is not to prove the software is working well.

Operational Maintenance
The process of monitoring and miniating the database system. Monitoring
means that the system is observed. Maintaining and upgrading the database
system means that when new requirements arises the new development lifecycle
will be done.
Two 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)
 Quick attempt at conceptual data modeling
 Define database during development of
initial prototype
 Repeat implementation and maintenance activities
with new prototype versions
31
Systems Development Life
Cycle (see also Figure 1-
Planning
10)

Analysis

Logical Design

Physical Design

Implementation

Maintenance

32
Systems Development Life Cycle
(see also Figure 1-10)
(cont.) Purpose–preliminary understanding
Planning
Plannin
g Deliverable–request for study
Analysis

Logical Design

Physical Design

Database activity– Implementation


enterprise modeling and
early conceptual data
Maintenance
modeling

33
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–thorough requirements analysis and
Plannin structuring
g
Deliverable–functional
Analysis system specifications

Logical Design

Physical Design

Database activity–thorough Implementation


and integrated conceptual
data modeling
Maintenance

34
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–information requirements elicitation
Plannin and structure
g Deliverable–detailed design
Analysis specifications

LogicalDesign
Logical
Design

Physical Design

Database activity– Implementation


logical database
design (transactions,
Maintenance
forms, displays, views,
data integrity and
security)
35
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–develop technology
Plannin and
organizational specifications
g
Deliverable–program/data
Analysis structures, technology purchases,
organization redesigns
Logical
Design
Physical
Design
Database activity– Implementation
physical database design (define
database to DBMS, physical
Maintenance
data organization, database
processing programs)

36
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–programming, testing,
Plannin training, installation,
g documenting
Analysis Deliverable–operational programs,
documentation, training materials

Logical
Design
Physical Design

Database activity–
database implementation, Implementation
including coded programs,
documentation, Maintenan
installation and conversion ce

37
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–monitor, repair, enhance
Plannin
g
Deliverable–periodic audits
Analysis

Logical Design

Physical Design

Database activity–
database Implementation
maintenance,
performance analysis Maintenan
Maintenance
and tuning, error ce
corrections
38
Prototyping Database Methodology
(Figure 1-11)

39
Prototyping Database Methodology
(Figure 1-11) (cont.)

40
Prototyping Database Methodology
(Figure 1-11) (cont.)

41
Prototyping Database Methodology
(Figure 1-11) (cont.)

42
Prototyping Database Methodology
(Figure 1-11) (cont.)

43
Database Schema
 External Schema
 User Views
 Subsets of Conceptual Schema
 Can be determined from business-function/data
entity matrices
 DBA determines schema for different users
 Conceptual Schema
 E-R models
 Internal Schema
 Logical structures
 Physical structures

45
Managing Projects: People Involved
 Business analysts
 Systems analysts
 Database analysts and data modelers
 Users
 Programmers
 Database architects
 Data administrators
 Project managers
 Other technical experts

46

You might also like