Databases and Database Management Systems

1
Databases and Database Management Systems

• Based on Chapters 1-2 in Fundamentals of
  Database Systems
• by Elmasri and Navathe, Ed. 4

2
NOTES

• 1 Basic Definitions
• 2 Example of a Database
• 3 Main Characteristics of Database Technology
• 4 Additional Benefits of Database Technology
• 5 When Not to Use a DBMS
• 6 Data Models6A. History of data Models

• 7 Schemas versus Instances
• 8 Three-Schema Architecture
• 9 Data Independence
• 10 DBMS Languages
• 11 DBMS Interfaces
• 12 DBMS Component Modules
  13 Database System Utilities
• 14 Classification of DBMSs

3
Types of Databases and Database Applications

• Numeric and Textual Databases
• Multimedia Databases
• Geographic Information Systems (GIS)
• Data Warehouses
• Real-time and Active Databases
• A number of these databases and applications are
  described later in the book (see Chapters
  24,28,29)

4
1.Basic Definitions

• Database
• A collection of related data.
• Data
• Known facts that can be recorded and have an
  implicit meaning.

5
Basic Definitions

• Mini-world
• Some part of the real world about which data is
  stored in a database.
• For example, student grades and transcripts at a
  university.

6
Basic Definitions

• Database Management System (DBMS)
• A software package/ system to facilitate the
  creation and maintenance of a computerized
  database.

7
Basic Definitions

• Database System
• The DBMS software together with the data itself.
  
• Sometimes, the applications are also included.

• Database System
• Data DBMS (Program)

8
A simplified database system environment.
9
Typical DBMS Functionality (1/2)

• Define a database
• in terms of data types, structures and
  constraints
• Construct or Load the Database on a secondary
  storage medium
• Manipulating the database
• querying, generating reports, insertions,
  deletions and modifications to its content
• Concurrent Processing and Sharing by a set of
  users and programs yet, keeping all data valid
  and consistent

10
Typical DBMS Functionality (2/2)

• Other features
• Protection or Security measures to prevent
  unauthorized access
• Active processing to take internal actions on
  data
• Presentation and Visualization of data

11
2. Example of a Database(with a Conceptual Data
Model)  

• Mini-world for the example
• Part of a UNIVERSITY environment.
• Entities
• Relationships

12
2. Example of a Database(with a Conceptual Data
Model)

• Some mini-world entities
• STUDENTs
• COURSEs
• SECTIONs (of COURSEs)
• (academic) DEPARTMENTs
• INSTRUCTORs

13
2. Example of a Database(with a Conceptual Data
Model)

• Some mini-world relationships
• SECTIONs are of specific COURSEs
• STUDENTs take SECTIONs
• COURSEs have prerequisite COURSEs
• INSTRUCTORs teach SECTIONs
• COURSEs are offered by DEPARTMENTs
• STUDENTs major in DEPARTMENTs

14
NOTE

• The above could be expressed in the
  ENTITY-RELATIONSHIP data model.

15
3. Main Characteristics of Database Technology

• Self-contained nature of a database system
• Insulation(??) between programs and data
• Data Abstraction
• Support of multiple views of the data
• Sharing of data and multiuser transaction
  processing

16
Self-contained nature of a database system

• A DBMS catalog stores the description of the
  database.
• The description is called meta-data.
• This allows the DBMS software to work with
  different databases.

17
Insulation between programs and data

• Called program-data independence.
• Allows changing data storage structures and
  operations without having to change the DBMS
  access programs.

18
Data Abstraction

• A data model is used to hide storage details and
  present the users with a conceptual view of the
  database.

19
Support of multiple views of the data

• Each user may see a different view of the
  database, which describes only the data of
  interest to that user.

20
The STUDENT TRANSCRIPT view.
21
University database
22
Internal storage format for a STUDENT record
23
Sharing of data and multiuser transaction
processing

• allowing a set of concurrent users to retrieve
  and to update the database.
• Concurrency control within the DBMS guarantees
  that each transaction is correctly executed or
  completely aborted.
• OLTP (Online Transaction Processing) is a major
  part of database applications.

24
4. Additional Benefits of Database Technology

• Controlling redundancy in data storage and in
  development and maintenance efforts.
• Sharing of data among multiple users.
• Restricting unauthorized access to data.
• Providing multiple interfaces to different
  classes of users.
• Representing complex relationships among data.
• Enforcing integrity constraints on the database.
• Providing backup and recovery services.
• Potential for enforcing standards.
• Flexibility to change data structures.
• Reduced application development time.
• Availability of up-to-date information.
• Economies of scale.

25
Redundant storage of StudentName and CourseNumber
in GRADE_REPORT.
(a) Consistent data.
(b) Inconsistent record.
26
Historical Development of Database Technology

• Early Database Applications
• The Hierarchical and Network Models were
  introduced in mid 1960s and dominated during the
  seventies.
• A bulk of the worldwide database processing still
  occurs using these models.

27
Historical Development of Database Technology

• Relational Model based Systems
• The model that was originally introduced in 1970
  was heavily researched and experimented with in
  IBM and the universities.
• Relational DBMS Products emerged in the 1980s.

28
Historical Development of Database Technology

• Object-oriented applications
• OODBMSs were introduced in late 1980s and early
  1990s to cater to the need of complex data
  processing in CAD and other applications.
• Their use has not taken off much.

29
Historical Development of Database Technology

• Data on the Web and E-commerce Applications
• Web contains data in HTML (Hypertext markup
  language) with links among pages.
• This has given rise to a new set of applications
  and E-commerce is using new standards like XML
  (eXtended Markup Language).

30
Extending Database capabilities

• New functionality is being added to DBMSs in the
  following areas
• Scientific Applications
• Image Storage and Management
• Audio and Video data management
• Data Mining
• Spatial data management
• Time Series and Historical Data Management

31
5 When not to use a DBMS

• Main inhibitors (costs) of using a DBMS
• When a DBMS may be unnecessary
• When no DBMS may suffice

32
Main inhibitors (costs) of using a DBMS

• High initial investment and possible need for
  additional hardware.
• Overhead for providing generality, security,
  recovery, integrity, and concurrency control.

33
When a DBMS may be unnecessary

• If the database and applications are simple, well
  defined, and not expected to change.
• If there are stringent real-time requirements
  that may not be met because of DBMS overhead.
• If access to data by multiple users is not
  required.

34
When no DBMS may suffice

• If the database system is not able to handle the
  complexity of data because of modeling
  limitations
• If the database users need special operations not
  supported by the DBMS.

35
6. Data Models

• Data Model
• A set of concepts to describe the structure of a
  database, and certain constraints that the
  database should obey.

36
6. Data Models

• Data Model Operations
• Operations for specifying database retrievals and
  updates by referring to the concepts of the data
  model.
• Operations on the data model may include basic
  operations and user-defined operations

37
Categories of data models

• Conceptual data models
• (high-level, semantic)
• Physical data models
• (low-level, internal)
• Logical (representational, Implementation) data
  models
• (record-oriented)

38
Conceptual data models

• Provide concepts that are close to the way many
  users perceive data.
• Also called entity-based or object-based data
  models.

39
Physical data models

• Provide concepts that describe details of how
  data is stored in the computer.
• storage structure
• Access path

40
Implementation data models

• Also called logical data model
• Provide concepts that fall between the above two,
  balancing user views with some computer storage
  details.

41
6A. HISTORY OF DATA MODELS

• Relational Model
• Network Model
• Hierarchical Data Model
• Object-oriented Data Model(s
• Object-Relational Models

42
Relational Model

• proposed in 1970 by E.F. Codd (IBM), first
  commercial system in 1981-82.
• Now in several commercial products
• DB2,
• ORACLE,
• SQL Server,
• SYBASE,
• INFORMIX.

43
Object-Relational Models

• Most Recent Trend.
• Started with Informix Universal Server.
• Exemplified in the latest versions of Oracle-10g,
  DB2, and SQL Server etc. systems.

44
7. Schemas versus Instances

• Database Schema
• The description of a database.
• Includes
• descriptions of the database structure and
• the constraints that should hold on the database.
• Schema Diagram
• A diagrammatic display of (some aspects of) a
  database schema.

45
Schema diagram for University database
46
7. Schemas versus Instances

• Database Instance
• The actual data stored in a database at a
  particular moment in time .
• Also called database state (or occurrence).

47
7. Schemas versus Instances

• Database State
• Refers to the content of a database at a moment
  in time.
• Initial Database State
• Refers to the database when it is loaded
• Valid State
• A state that satisfies the structure and
  constraints of the database.

48
7. Schemas versus Instances

• Distinction
• The database schema changes very infrequently.
• The database state changes every time the
  database is updated.
• Schema is also called intension, whereas state is
  called extension.

49
8. Three-Schema Architecture

• Proposed to support DBMS characteristics of
• Program-data independence.
• Support of multiple views of the data.

50
8. Three-Schema Architecture

• Defines DBMS schemas at three levels
• Internal schema
• Conceptual schema
• External schemas

51
The three-schema architecture.
52
Internal schema

• Internal schema at the internal level to describe
  data storage structures and access paths.
• Typically uses a physical data model.

53
Conceptual schema

• Conceptual schema at the conceptual level to
  describe the structure and constraints for the
  whole database.
• Uses a conceptual or an implementation data
  model.

54
External schemas

• External schemas at the external level to
  describe the various user views.
• Usually uses the same data model as the
  conceptual level.

55
Three-Schema Architecture

• Mappings among schema levels are also needed.
• Programs refer to an external schema, and are
  mapped by the DBMS to the internal schema for
  execution.

56
9 Data Independence

• Logical Data Independence
• The capacity to change the conceptual schema
  without having to change the external schemas and
  their application programs.
• Physical Data Independence
• The capacity to change the internal schema
  without having to change the conceptual schema.

57
Data Independence

• When a schema at a lower level is changed, only
  the mappings between this schema and higher-level
  schemas need to be changed in a DBMS that fully
  supports data independence.
• The higher-level schemas themselves are
  unchanged.
• Hence, the application programs need not be
  changed since the refer to the external schemas.

58
10. DBMS Languages

• Data Definition Language (DDL)
• Data Manipulation Language (DML)
• Data Control Language (DCL)

59
Data Definition Language (DDL)

• Used by the DBA and database designers to specify
  the conceptual schema of a database.
• In many DBMSs, the DDL is also used to define
  internal and external schemas (views).
• In some DBMSs, separate storage definition
  language (SDL) and view definition language (VDL)
  are used to define internal and external schemas.

60
Data Manipulation Language (DML)

• Used to specify database retrievals and updates.
• DML commands (data sublanguage) can be embedded
  in a general-purpose programming language (host
  language), such as C, COBOL, PL/1 or PASCAL.
• Alternatively, stand-alone DML commands can be
  applied directly (query language).

61
DBMS Languages

• High Level or Non-procedural Languages
• e.g., SQL, are set-oriented and specify what
  data to retrieve than how to retrieve. Also
  called declarative languages.
• Low Level or Procedural Languages
• record-at-a-time they specify how to retrieve
  data and include constructs such as looping.

62
11. DBMS Interfaces

• Stand-alone query language interfaces.
• Programmer interfaces for embedding DML in
  programming languages
• Pre-compiler Approach
• Procedure (Subroutine) Call Approach
• User-friendly interfaces
• Web Browser as an interface
• Parametric interfaces (e.g., bank tellers) using
  function keys.

63
DBMS Interfaces

• Interfaces for the DBA
• Creating accounts, granting authorizations
• Setting system parameters
• Changing schemas or access path

64
Component modules of a DBMS and their
interactions.
65
13. Database System Utilities

• To perform certain functions such as
• Loading data stored in files into a database.
• Backing up the database periodically on tape.
• Reorganizing database file structures.
• Report generation utilities.
• Performance monitoring utilities.
• Other functions, such as sorting , user
  monitoring , data compression , etc.

66
Data dictionary / repository

• Used to store schema descriptions and other
  information such as design decisions, application
  program descriptions, user information, usage
  standards, etc.
• Active data dictionary is accessed by DBMS
  software and users/DBA.
• Passive data dictionary is accessed by users/DBA
  only.

67
14. Classification of DBMSs

• Based on data model
• Other classifications

68
Based on the data model used

• Traditional
• Relational,
• Network,
• Hierarchical.
• Emerging
• Object-oriented,
• Object-relational.

69
Other classifications

• Single-user (typically used with micro-
  computers) vs. multi-user (most DBMSs).
• Centralized (uses a single computer with one
  database) vs. distributed (uses multiple
  computers, multiple databases)
• Distributed Database Systems have now come to be
  known as client server based database systems
  because they do not support a totally distributed
  environment, but rather a set of database servers
  supporting a set of clients.

70
Example of a Database(with a Logical Data Model)