Chapter 2: Database System Concepts and Architecture · 2014-02-02 · Chapter 2: Database System...

2/2/14

1

Slides from textbook Fundamentals of Database Systems, 6th Edition by Elmasri/Navathe (c) Pearson Education - Addison-Wesley, 2011

2-Feb-14

Chapter 2: Database System Concepts and Architecture

Anis Koubaa

Advanced Databases (SE487) Prince Sultan University

College of Computer and Information Sciences

SE487: Advanced Databases by Dr. Anis Koubaa Textbook: Fundamentals of Database Systems, 6th Edition Elmasri & Navathe, (c) Pearson Education - Addison-Wesley, 2011 2

Chapter 2 Outline

}  Data Models, Schemas, and Instances }  Three-Schema Architecture and Data Independence }  Database Languages and Interfaces }  The Database System Environment }  Database Architectures

for DBMSs }  Classi!cation of Database Management Systems

2/2/14

2

Data Models, Schemas and Instances

Data Abstraction

2/2/14

3


Data Models, Schemas, and Instances

}  One fundamental characteristic of the database approach is that it provides some level of data abstraction.

}  Data abstraction }  Suppression of details of data organization and storage }  Highlighting of the essential features for an improved

understanding of data }  The system hides certain details of how data is stored and

created and maintained }  Users can perceive data at their preferred level of detail. }  Allows program-data independence and program-

operation independence


Data Abstraction Levels

}  Physical Level: describes how the data is actually stored }  Describes low level data

structures

}  Logical Level: describes what data are stored in the database and what relationships exist between data

}  View Level: describes only part of the entire database

How to store

What to store

2/2/14

4


Data Models

Data Abstraction

Data Models

2/2/14

5


Data Models Definition

}  The Data Model: a collection of conceptual tools for describing }  Data }  Data relationship }  Data semantics }  Consistency constraints

}  A data model provide a way to describe the design of a database at the }  Physical level }  Logical level }  view level


Data Models, Schemas, and Instances (cont'd.)

} Data model }  Collection of concepts that describe the structure

of a database (data types, relationships, constraints, …)

}  Provides means to achieve data abstraction }  Popular Data Models

} E-R model } Relational model, } Object-oriented model, } Semi-Structured Data Models (XML)

2/2/14

6


Data Models, Schemas, and Instances (cont'd.)

}  Data model includes: }  Basic operations

}  Specify retrievals and updates on the database (SELECT, INSERT, DELETE, …)

}  Dynamic aspect or behavior of a database application }  Allows the database designer to specify a set of valid

operations allowed on database objects (example: COMPUTE_GPA operation on object STUDENT table)

}  Usually defined for object-oriented data models (but being incorporate in traditional databases)


Categories of Data Models

Data Model Categories

High Level Conceptual Models

E-R Model

Entities

Attributes

relationships

Low-Level Physical Models

Access Path

Indexing

Representational Models

Relational Data Model

Object Data Model

2/2/14

7


Categories of Data Models }  High-level or conceptual data models

}  Close to the way many users perceive data }  It is a map of concepts and their relationships used for

databases. }  Describes the semantics of an organization and represents a

series of assertions about its nature

}  Low-level or physical data models }  Describe the details of how data is stored on computer

storage media (meant for computer specialists)

}  Representational (implementation) data models }  Easily understood by end users }  Similar to how data organized in computer storage

Example of Data Models

Logical/Conceptual Data Model

2/2/14

8


Data Models The Entity-Relationship Model

}  Entity-Relationship (E-R) Model }  it is based on the perception of a real world that consists of a

collection basic objects called entities and of relationships among those objects.

}  An entity is a “thing” or “object” from the real world that is distinguishable from other objects }  e.g. customers, accounts, bank branch

}  A relationship is an association among several entities }  e.g. the account Ac1234 is held by the customer Mr. Abdullah

}  This model is also widely used in database design


Data Models The Entity-Relationship Model

•  Rectangles: represent the set of entities •  Ellipses: represent the attributes of an entity •  Diamonds: represent the set of relationships among a member from each of several entity sets •  Lines: link the attributes to entity sets and entity sets to relationships

entity

Relationship entity

Attributes

2/2/14

9


Categories of Data Models (cont'd.)

}  Entity-Relationship model }  Entity

}  Represents a real-world object or concept

}  Attribute }  Represents some property of

interest }  Further describes an entity

}  Relationship among two or more entities }  Represents an association among

the entities



2/2/14

10



}  Relational data model }  Used most frequently in traditional commercial DBMSs }  Representational data model category

}  Object data model }  New family of higher-level implementation data models }  Closer to conceptual data models


Data Models The Relational Model

}  Relational Model: }  uses a collection of tables to represent both data and the

relationship among those data. }  Each table has multiple column and each column has a unique

name (Attribute) }  The most widely used as a data model for databases }  Vast majority of current database systems are based on the

relational model

2/2/14

11


Data Models The Relational Model


Object-Oriented Data Model

2/2/14

12

Example of Data Models

Physical Data Model



} Physical data models }  Describe how data is stored as files in the

computer }  Access path

•  Structure that makes the search for particular database records efficient

}  Index •  Example of an access path •  Allows direct access to data using an index term

or a keyword

2/2/14

13


Storing Record Models

598 Chapter 17 Disk Storage, Basic File Structures, and Hashing

Record 1Block i Record 2 Record 3 Record 4 P

Record 4 (rest)Block i + 1 Record 5 Record 6 Record 7 P

Record 1Block i

(b)

(a) Record 2 Record 3

Record 4Block i + 1 Record 5 Record 6

Figure 17.6Types of record organization.(a) Unspanned. (b) Spanned.

each record start at a known location in the block, simplifying record processing. Forvariable-length records, either a spanned or an unspanned organization can be used.If the average record is large, it is advantageous to use spanning to reduce the lostspace in each block. Figure 17.6 illustrates spanned versus unspanned organization.

For variable-length records using spanned organization, each block may store a dif-ferent number of records. In this case, the blocking factor bfr represents the averagenumber of records per block for the file. We can use bfr to calculate the number ofblocks b needed for a file of r records:

b = !(r/bfr)" blocks

where the !(x)" (ceiling function) rounds the value x up to the next integer.

17.4.4 Allocating File Blocks on DiskThere are several standard techniques for allocating the blocks of a file on disk. Incontiguous allocation, the file blocks are allocated to consecutive disk blocks. Thismakes reading the whole file very fast using double buffering, but it makes expand-ing the file difficult. In linked allocation, each file block contains a pointer to thenext file block. This makes it easy to expand the file but makes it slow to read thewhole file. A combination of the two allocates clusters of consecutive disk blocks,and the clusters are linked. Clusters are sometimes called file segments or extents.Another possibility is to use indexed allocation, where one or more index blockscontain pointers to the actual file blocks. It is also common to use combinations ofthese techniques.

17.4.5 File HeadersA file header or file descriptor contains information about a file that is needed bythe system programs that access the file records. The header includes information todetermine the disk addresses of the file blocks as well as to record format descrip-tions, which may include field lengths and the order of fields within a record forfixed-length unspanned records and field type codes, separator characters, andrecord type codes for variable-length records.

To search for a record on disk, one or more blocks are copied into main memorybuffers. Programs then search for the desired record or records within the buffers,using the information in the file header. If the address of the block that contains thedesired record is not known, the search programs must do a linear search through


Storage Format Examples

Name = Smith, John Ssn = 123456789 DEPARTMENT = Computer

Smith, John

Name

1

(a)

(b)

(c)

1 12 21 25 29

Name Ssn Salary Job_code Department Hire_date

31 40 44 48 68

Ssn Salary Job_code Department

Separator Characters123456789 XXXX XXXX Computer

Separator Characters

Separates field name from field value

Separates fields

Terminates record

=

596 Chapter 17 Disk Storage, Basic File Structures, and Hashing

Figure 17.5Three record storage formats. (a) A fixed-length record with sixfields and size of 71 bytes. (b) A record with two variable-lengthfields and three fixed-length fields. (c) A variable-field record withthree types of separator characters.

! The file contains records of different record types and hence of varying size(mixed file). This would occur if related records of different types wereclustered (placed together) on disk blocks; for example, the GRADE_REPORTrecords of a particular student may be placed following that STUDENT’srecord.

The fixed-length EMPLOYEE records in Figure 17.5(a) have a record size of 71 bytes.Every record has the same fields, and field lengths are fixed, so the system can iden-tify the starting byte position of each field relative to the starting position of therecord. This facilitates locating field values by programs that access such files. Noticethat it is possible to represent a file that logically should have variable-length recordsas a fixed-length records file. For example, in the case of optional fields, we couldhave every field included in every file record but store a special NULL value if no valueexists for that field. For a repeating field, we could allocate as many spaces in eachrecord as the maximum possible number of occurrences of the field. In either case,space is wasted when certain records do not have values for all the physical spacesprovided in each record. Now we consider other options for formatting records of afile of variable-length records.

2/2/14

14


Indexing Examples 634 Chapter 18 Indexing Structures for Files

Index file(<K(i), P(i)> entries)

Block anchorprimary key

valueBlock

pointer

(Primarykey field)

Name

Aaron, EdAbbot, Diane

...

...

...

...

...

Acosta, Marc

Adams, John

Adams, Robin

Akers, Jan

Alexander, Ed

Alfred, Bob

Allen, Sam

Allen, Troy

Anders, Keith

Anderson, Rob

Anderson, Zach

Angel, Joe

Archer, Sue

Arnold, Mack

Arnold, Steven

Atkins, Timothy

Wong, James

Wood, Donald

Woods, Manny

Wright, Pam

Wyatt, Charles

Zimmer, Byron

Aaron, EdAdams, JohnAlexander, EdAllen, TroyAnderson, ZachArnold, Mack

Wong, JamesWright, Pam

...

...

...

. . .

. . .

Ssn Birth_date Job Salary Sex

Figure 18.1Primary index on the ordering key field ofthe file shown in Figure 17.7.

18.1 Types of Single-Level Ordered Indexes 637

Data file(Clustering

field)Dept_number

1112

Name Ssn Birth_date SalaryJob

2

333

3

3

44

55

55

66

66

6888

1234568

Index file(<K(i), P(i)> entries)

Clusteringfield value

Blockpointer

Figure 18.2A clustering index on the Dept_number orderingnonkey field of an EMPLOYEE file.

Again we refer to the two field values of index entry i as <K(i), P(i)>. The entries areordered by value of K(i), so we can perform a binary search. Because the records ofthe data file are not physically ordered by values of the secondary key field, we cannotuse block anchors. That is why an index entry is created for each record in the data

Data Models Languages

2/2/14

15


DBMS Languages

}  Data definition language (DDL) •  Defines both schemas (conceptual and internal)

}  Storage definition language (SDL) •  Specifies the internal schema

}  View definition language (VDL) •  Specifies user views/mappings to conceptual schema

}  Data manipulation language (DML) •  Allows retrieval, insertion, deletion, modification


DBMS Languages (cont'd.)

}  High-level or nonprocedural DML •  Can be used on its own to specify complex database

operations concisely •  Example: SQL •  Set-at-a-time or set-oriented

}  Low-level or procedural DML •  Must be embedded in a general-purpose programming language •  Record-at-a-time

2/2/14

16


DBMS Interfaces

}  Menu-based interfaces for Web clients or browsing }  Forms-based interfaces }  Graphical user interfaces }  Natural language interfaces }  Speech input and output }  Interfaces for parametric users }  Interfaces for the DBA


Data Language Definition

}  A database system provides }  A Data Definition Language to specify the database schema }  A Data Manipulation Language to express database

queries and update

}  In practice, both languages are not separate }  e.g. SQL (Structured Query Language)

2/2/14

17


Data Definition Language (DDL)

}  Data Definition Language: }  specifies the notation for defining the database schema }  e.g. create table account ( account-number char (10), balance integer"

)"

}  DDL compiler generates a set of tables stored in a data dictionary


Data Definition Language (DDL)

}  Data dictionary }  contains metadata (i.e., data about data) }  The schema of a table is an example of metadata }  Data storage and definition language

}  Usually an extension of the data definition language }  Language in which the storage structure and access methods used by

the database system are specified }  Hidden from the user of the database

2/2/14

18


Data Manipulation Language (DML)

}  Language for accessing and manipulating the data organized by the appropriate data model }  DML also known as query language

}  Data manipulation is: }  The retrieval of information stored in the database }  The insertion of new information into the database }  The deletion of the information from the database }  The modification (update) of the information from the

database


Data Manipulation Language (DML)

}  Two classes of languages }  Procedural – user specifies what data is required and how to

get those data (PL/SQL from Oracle) }  Declarative (Nonprocedural) – user specifies what data is

required without specifying how to get those data (e.g. SQL) }  Easy to learn and to use }  The database system has to figure out an efficient means of accessing

the data

}  SQL is the most widely used query language }  A Query is a statement requesting the retrieval of the

information

2/2/14

19

Schemas, Instances, and Database State

Schema


Database Schemas

•  Description of a database •  Is not expected to change frequently

Database schema

•  Displays selected aspects of schema •  Displays the structure of each record but not actual

instances of records (e.g. Relational Model)

Schema diagram

•  Each object in the schema Schema construct

•  Data in database at a particular moment in time Database state or snapshot

2/2/14

20


Schema Diagram Example

32 Chapter 2 Database System Concepts and Architecture

2.1.2 Schemas, Instances, and Database StateIn any data model, it is important to distinguish between the description of the data-base and the database itself. The description of a database is called the databaseschema, which is specified during database design and is not expected to changefrequently.6 Most data models have certain conventions for displaying schemas asdiagrams.7 A displayed schema is called a schema diagram. Figure 2.1 shows aschema diagram for the database shown in Figure 1.2; the diagram displays thestructure of each record type but not the actual instances of records. We call eachobject in the schema—such as STUDENT or COURSE—a schema construct.

A schema diagram displays only some aspects of a schema, such as the names ofrecord types and data items, and some types of constraints. Other aspects are notspecified in the schema diagram; for example, Figure 2.1 shows neither the data typeof each data item, nor the relationships among the various files. Many types of con-straints are not represented in schema diagrams. A constraint such as studentsmajoring in computer science must take CS1310 before the end of their sophomore yearis quite difficult to represent diagrammatically.

The actual data in a database may change quite frequently. For example, the data-base shown in Figure 1.2 changes every time we add a new student or enter a newgrade. The data in the database at a particular moment in time is called a databasestate or snapshot. It is also called the current set of occurrences or instances in the

Section_identifier SemesterCourse_number InstructorYearSECTION

Course_name Course_number Credit_hours DepartmentCOURSE

Name Student_number Class MajorSTUDENT

Course_number Prerequisite_numberPREREQUISITE

Student_number GradeSection_identifierGRADE_REPORT

Figure 2.1Schema diagram for thedatabase in Figure 1.2.

6Schema changes are usually needed as the requirements of the database applications change. Newerdatabase systems include operations for allowing schema changes, although the schema changeprocess is more involved than simple database updates.7It is customary in database parlance to use schemas as the plural for schema, even though schemata isthe proper plural form. The word scheme is also sometimes used to refer to a schema.

32 Chapter 2 Database System Concepts and Architecture

2.1.2 Schemas, Instances, and Database StateIn any data model, it is important to distinguish between the description of the data-base and the database itself. The description of a database is called the databaseschema, which is specified during database design and is not expected to changefrequently.6 Most data models have certain conventions for displaying schemas asdiagrams.7 A displayed schema is called a schema diagram. Figure 2.1 shows aschema diagram for the database shown in Figure 1.2; the diagram displays thestructure of each record type but not the actual instances of records. We call eachobject in the schema—such as STUDENT or COURSE—a schema construct.

A schema diagram displays only some aspects of a schema, such as the names ofrecord types and data items, and some types of constraints. Other aspects are notspecified in the schema diagram; for example, Figure 2.1 shows neither the data typeof each data item, nor the relationships among the various files. Many types of con-straints are not represented in schema diagrams. A constraint such as studentsmajoring in computer science must take CS1310 before the end of their sophomore yearis quite difficult to represent diagrammatically.

The actual data in a database may change quite frequently. For example, the data-base shown in Figure 1.2 changes every time we add a new student or enter a newgrade. The data in the database at a particular moment in time is called a databasestate or snapshot. It is also called the current set of occurrences or instances in the

Section_identifier SemesterCourse_number InstructorYearSECTION

Course_name Course_number Credit_hours DepartmentCOURSE

Name Student_number Class MajorSTUDENT

Course_number Prerequisite_numberPREREQUISITE

Student_number GradeSection_identifierGRADE_REPORT

Figure 2.1Schema diagram for thedatabase in Figure 1.2.

6Schema changes are usually needed as the requirements of the database applications change. Newerdatabase systems include operations for allowing schema changes, although the schema changeprocess is more involved than simple database updates.7It is customary in database parlance to use schemas as the plural for schema, even though schemata isthe proper plural form. The word scheme is also sometimes used to refer to a schema.


Database Schemas

}  Define a new database }  Specify database schema to the DBMS

}  Initial state }  Populated or loaded with the initial data

}  Valid state }  Satisfies the structure and constraints specified in the schema

2/2/14

21


Schemas, Instances, and Database State (cont'd.)

}  Schema evolution }  Changes applied to schema as application requirements change

Three-Schema Architecture and Data Independence

2/2/14

22


DATABASE SCHEMAS

}  External Schema (Level) }  Describes part of the database that a particular user group is interested

in (User Views) }  Subsets of Conceptual Schema }  Can be determined from business-function/data entity matrices }  DBA determines schema for different users

}  Conceptual Schema (Level) }  Describes structure of the whole database for a community of users

(e.g. E-R models)

}  Internal Schema (Level) }  Describes physical storage structure of the database }  Physical structures

43


Three-schema architecture

44

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

The internal schema is the underlying design and implementation

44

2/2/14

23


Three-Schema Architecture and Data Independence (cont'd.)


Three-Schema Architecture

46

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

The internal schema is the underlying design and implementation

46

2/2/14

24


Data Independence

}  Capacity to change the schema at one level of a database system }  Without having to change the schema at the next higher level

}  Logical Data Independence: the capacity to change the conceptual schema without having to change external schemas or application programs. }  Adding constraints, new attributes, does not impact external

views

}  Physical Data Independence: the capacity to change the internal schema without having to change the conceptual schema

}  for example, by creating additional access structures—to improve the performance of retrieval or update.

The Database System Environment

2/2/14

25


The Database System Environment

}  DBMS component modules }  Buffer Management }  Stored Data Manager }  DDL Compiler }  Interactive Query Interface

•  Query compiler •  Query optimizer

}  Precompiler


Buffer Management Module }  Schedule disk read/write, because

this has a considerable effect on performance.

}  Reducing disk read/write improves performance considerably.

}  the runtime database processor executes (1) the privileged commands, (2) the executable query plans, and (3) the canned transactions with runtime parameters.

2/2/14

26


Stored Data Manager }  controls access to DBMS

information that is stored on disk, whether it is part of the database or the catalog.

}  uses basic operating system services for carrying out low-level input/output (read/write) operations between the disk and main memory.

}  the runtime database processor executes (1) the privileged commands, (2) the executable query plans, and (3) the canned transactions with runtime parameters.


Interactive Query Interface

}  Interfaces used by Casual users and persons with occasional need for information to interact with the database

}  queries are parsed and validated for correctness of the query syntax, the names of files and data elements, and so on by a query compiler that compiles them into an internal form.

}  The pre-compiler extracts DML commands from an application program written in a host programming language. }  These commands are sent to the DML compiler for compilation into

object code for database access.

2/2/14

27


DDL Compiler }  DDL Compiler processes schema definitions, specified in

the DDL, and stores descriptions of the schemas (meta-data) in the DBMS catalog.

}  The catalog includes information such as the names and sizes of files, names and data types of data items, storage details of each file, mapping information among schemas, and constraints.

}  The query optimizer is concerned with the rearrangement and possible reordering of operations, elimination of redundancies, and use of correct algorithms and indexes during execution.


2/2/14

28


The Database System Environment (cont'd.)

}  DBMS component modules }  Runtime database processor }  System catalog }  Concurrency control system }  Backup and recovery system

Database Systems Utilities

In addition to possessing the software modules just described, most DBMSs have database utilities that help the DBA manage the database system. Common utilities have the following types of functions:

2/2/14

29


Database System Utilities

}  Loading }  A loading utility is used to load existing data files—such as text

files or sequential files—into the database.

}  Backup }  A backup utility creates a backup copy of the database, usually

by dumping the entire database onto tape or other mass storage medium.

}  The backup copy can be used to restore the database in case of catastrophic disk failure.

}  Incremental backups are also often used, where only changes since the previous backup are recorded.


Database System Utilities (cont'd.)

}  Database storage reorganization }  Reorganize a set of database files into different file

organizations }  Create new access paths to improve performance.

}  Performance monitoring }  Monitors database usage and provides statistics to the DBA }  he DBA uses the statistics in making decisions such as whether

or not to reorganize files or whether to add or drop indexes to improve performance.

2/2/14

30


Tools, Application Environments, and Communications Facilities

}  CASE Tools }  Data dictionary (data repository) system

}  Stores design decisions, usage standards, application program descriptions, and user information

}  Application development environments }  Communications software

Database Architecture

2/2/14

31


Database System Concepts and Architecture

}  Evolution of DBMS from monolithic systems to modular client/server systems

}  Basic client/server DBMS architecture }  Client module: runs on PC and handle user interaction with

DB through forms, or GUIs }  Server module: handles data storage, access, search and

other functions


Centralized and Client/Server Architectures for DBMSs

}  Centralized DBMSs Architecture }  All DBMS functionality, application program execution, and user

interface processing carried out on one machine

2/2/14

32



Basic Client/Server Architectures

}  Servers with specific functionalities }  File server

•  Maintains the files of the client machines.

}  Printer server •  Connected to various printers; all print requests by the clients are

forwarded to this machine

}  Web servers or e-mail servers

2/2/14

33


Basic Client/Server Architectures (cont'd.)

}  Client machines }  Provide user with:

•  Appropriate interfaces to utilize these servers •  Local processing power to run local applications


2/2/14

34


Basic Client/Server Architectures (cont'd.)

}  Client }  User machine that provides user interface capabilities and local

processing

}  Server }  System containing both hardware and software }  Provides services to the client machines

•  Such as file access, printing, archiving, or database access


Two-Tier Client/Server Architectures for DBMSs

}  Server handles }  Query and transaction functionality related to SQL processing

}  Client handles }  User interface programs and application programs

2/2/14

35


Two-Tier Client/Server Architectures (cont'd.)

}  Open Database Connectivity (ODBC) }  Provides application programming interface (API) }  Allows client-side programs to call the DBMS

•  Both client and server machines must have the necessary software installed

}  JDBC }  Allows Java client programs to access one or more DBMSs

through a standard interface


Three-Tier and n-Tier Architectures for Web Applications

}  Application server or Web server }  Adds intermediate layer between client and the database

server }  Runs application programs and stores business rules

}  N-tier }  Divide the layers between the user and the stored data further

into finer components

2/2/14

36



Three-tiered client/server database architecture

2/2/14

37

Enterprise Data Model


ENTERPRISE DATA MODEL

}  Enterprise Data Modeling is the practice of creating a graphical model of the data used by an enterprise or company.

}  Producing such a model allows for a business to get a 'helicopter' view of their enterprise.

}  Data Modeling Tools for Entity Relationship Diagrams that also allow the user to create a data dictionary are usually used to aid in the development of an EDM

74

2/2/14

38


ENTERPRISE DATA MODEL

}  First step in the database development process }  Specifies scope and general content }  Overall picture of organizational data at high level of

abstraction }  Entity-relationship diagram }  Descriptions of entity types }  Relationships between entities }  Business rules

75

SE487: Advanced Databases by Dr. Anis Koubaa Textbook: Fundamentals of Database Systems, 6th Edition Elmasri & Navathe, (c) Pearson Education - Addison-Wesley, 2011 76 76

FIGURE 1-6 Example business function-to-data entity matrix

76

2/2/14

39


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) }  Cursory attempt at conceptual data modeling }  Define database during development of initial prototype }  Repeat implementation and maintenance activities with new

prototype versions

77


SYSTEMS DEVELOPMENT LIFE CYCLE (SEE ALSO FIGURE 1-7)

78

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

2/2/14

40


SYSTEMS DEVELOPMENT LIFE CYCLE (SEE ALSO FIGURE 1-7) (CONT.)

79

Planning

Analysis

Physical Design

Implementation

Maintenance

Logical Design

Planning Purpose–preliminary understanding Deliverable–request for study

Database activity– enterprise modeling and early conceptual data modeling



80

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 modeling

2/2/14

41



81

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)



82

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)

2/2/14

42



83

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 conversion



84

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 corrections

2/2/14

43


85

Prototyping Database Methodology (Figure 1-8)

85 Chapter 1 © 2013 Pearson Education, Inc. Publishing as Prentice Hall


Prototyping Database Methodology (Figure 1-8) (cont.)


2/2/14

44






2/2/14

45





Summary

}  Concepts used in database systems }  Main categories of data models }  Types of languages supported by DMBSs }  Interfaces provided by the DBMS }  DBMS classification criteria:

}  Data model, number of users, number of sties, access paths, cost

Date post:	25-Jun-2020
Category:	Documents
Upload:	others
View:	14 times
Download:	0 times

Chapter 2: Database System Concepts and Architecture · 2014-02-02 · Chapter 2: Database System...

Documents