Some more types of databases

1
Chapter 2

• Some more types of databases
• Some more levels of abstraction/layering
• Data models
• DBMS languages
• Types of interfaces
• Database Tools
• DBMS modules
• Software Design vs. Database Design

2
Types of Databases

• Based on
• Application (déjà vu)
• Data models (déjà vu)
• Number of users (Single/Multiple AT A TIME)
• Cost (10K to 100K Geo Metro to Small House)
• Number of sites
• Type of access path

3
Types of Data Models

• Based on
• Data model Conceptual description of the
  structure (data types, relationships and
  constraints) and behavior of a database
• Relational
• Object-oriented
• Object-relational/Extended relational
• Network
• Hierarchical

4
Types of Data Models

• Based on
• Application
• General Purpose
• Specialized
• E.g., Online transaction Processing (OLTP)

5
Types of Data Models

• Based on
• Number of sites
• Centralized (BUT Distributed interfaces)
• Distributed databases (NOT merely distributed
  interfaces). Automation of distributed human
  system. Client-server architecture.
• Homogeneous
• Same DBMS software at each site
• Heterogeneous (Federated, Multidatabase
  system)
• More than one kind of DBMS software in the
  distributed system

6
Types of Data Models

• Based on
• Access Path
• Physical storage model

7
Data Models

• Structure may be considered at different levels
• High level/Conceptual (similar to users
  viewpoint)
• Architects view
• Mid-level/Representational/Implementational
• Civil Engineers view
• Low-level/Physical (details of storage)
• Contractors view

Abstraction
8
Conceptual Data Models

• Capture real world
• ER (Entity Relationship) models
• Entity (Real world object - tangible or abstract,
  i.e., concept), e.g., Instructor, Student.
• Has attributes (relevant properties)
• E.g., Instructor (IQ, dorkiness), Student
  (frequency of cell phone use, seating preference)
• Relationship (specifies type of interaction)
• E.g., Instructor (Excites/Teaches/Bores/Confuses/T
  ortures/) Student

9
Representational Data Models

• Conforms to conceptual model
• E.g., Relational (Table/Record based models),
  Object-oriented (Object data models)
• This level is a good compromise between actual
  (real) physical model and conceptual models.
  Hence also called implementational.
• Analogous to using source code (easily mapped to
  compiled code, fairly lucid) versus assembly
  language (laborious to write programs) to write a
  program.

10
Physical Data Models

• Close to bits and bytes
• Record formats, ordering, access paths
• Issues are efficiency of storage, performance,
  and access
• Reason for knowledge of Data Structures being a
  pre-requisite for this course

11
Specifying Data Models

• Data Model Intension Extension
• Schema (Figure 2.1) Database
  State
• Scheme Snapshot
• Scheme Set of Instances
• Database State highly dynamic
• Scheme evolves
• Newly formed database Schema Empty State
• Schema constructs and constraints Meta-Data
  (DBMS catalog)

12
N-Schemal Architecture (Figure 2.2)

• External level (External/End-user view) (VDL)
• Conceptual level (DDL)
• Internal level (SDL)
• Mapping promotes data independence, but implies
  overhead in translation.
• Note that Conceptual level here corresponds to
  Implementational in the Model hierarchy !!??

Mapping
Abstraction
Mapping
13
Data Independence

• Protection of higher levels from being affected
  by changes in lower levels
• Logical data independence
• Change in conceptual schema without concomitant
  changes in external schemas
• Physical data independence
• Change in internal schema without concomitant
  changes in conceptual/external schemas
• Note, however, this implies need to keep mappings
  updated

14
DBMS Languages

• Definition Languages are used to specify schemas
  and mappings
• Ideally,
• View Definition Language (VDL) for external
  schema
• Data Definition Language (DDL) for conceptual
  schema
• Storage Definition Language (SDL) for internal
  schema
• In reality,
• DDL includes SDL and VDL functionality
• Best to think of the ideal classification as
  being the different kinds of functionality
• Mapping is often implicit

15
DBMS Languages

• Data Manipulation Languages are used to retrieve
  or change data
• High-level/Non-procedural DML
• Set oriented
• Interactive or embedded in programming languages
• Declarative Focus on what/which rather than
  exactly how
• Low-level/Procedural DML
• Record at a time, needs supporting programming
  language loop statements etc.
• Therefore, always embedded in language

16
Embedded DML

• DML (Data sublanguage) embedded in a programming
  language (host language)
• E.g., Embedded SQL
• Stand-alone DML Query language
• Query is a misnomer. In practice more than a
  query
• Who are the students with purple hair?
• Change grade of all students who can stand on
  their heads to A
• Includes commands to change (Updates, as well as
  retrievals)

17
User friendly interfaces

• Variety of interfaces for users with no knowledge
  of query languages
• Menu (Browsing, No modification)
• Forms (Partial/Full, Retrieval/Modification)
• Forms specification languages for programmers
• Interactive form generation by end-users
• GUI
• Diagrammatic exploration
• May include features of Menus and Forms
• Natural Language
• I am looking for a date who will help me get an
  A
• E.g. Ask Jeeves

18
User friendly interfaces

• Parametric Users
• Minimizing keystrokes for high throughput
• Minimal mouse use
• Programmed Function keys
• The reason why Check-out lines get held up in
  Wal-Mart when Cashier screws up
• DBA interfaces
• Privileged commands
• Managing access, tuning performance, changing
  schema at multiple levels
• Make life even easier for the DBA

19
Database Tools Utilities

• DBA
• Conversion tools for loading (interchange data
  format from one database to another)
• Backup
• File reorganization
• Performance monitoring
• Computer Aided Software Engineering (CASE) tools
• Data dictionary (Information repository)
• User accessible version of DBMS catalog

20
Database Tools

• Application development environments
• Database Design
• GUI development
• Querying
• Application development
• e.g., Powerbuilder
• Communications Software
• Networking the DBMS
• DB/DC integrated systems

21
Database Design vs. Software Engineering

• Fuzzy boundaries
• Database design is a prominent part of many
  software engineering projects
• CASE tools are most effective for database based
  products
• Similar project models are used by both
  (Object-oriented paradigm, Software development
  life-cycle)

See Figure 2.3 for Database modules
22
New terms

• Access Path
• Attributes
• CASE tools
• Centralized Database
• Conceptual Model
• Controlled Redundancy
• Conversion Tools
• Data Model
• Database State
• Data Dictionary
• Data Independence
• DDBMS
• DDL

23

• DML
• Empty State
• Entity
• Extension
• Federated Databases
• Implementational Data Model
• Instance
• Intension
• Mapping
• Meta-data
• Miniworld
• Object-oriented Database
• Object-Relational Database

24

• OLTP
• OLAP
• Parametric
• Procedural vs. Non-procedural DML
• Relational Database
• Relationship
• Representational Data Model
• Schema
• SDL
• Snapshot
• VDL