The document discusses database management systems (DBMS). It covers: 1. The evolution of DBMS from monolithic to client/server architectures. 2. Data models including conceptual, logical, and physical models. Conceptual models are independent of implementation while physical models describe how data is stored. 3. Database schemas define the structure, while instances represent the current data state. Schemas can evolve independently of instances.

2. Overview of Databases and Data Modelling
(Part – 2)
Presented by:
Mr. S. Christalin Nelson
2/20/2024 Christalin Nelson | Systems Cluster | SoCS

3. At a Glance
• Data Models, Schemas, and Instances
• Three-Schema Architecture and Data Independence
• Database Languages and Interfaces
• The Database System Environment
• Centralized and Client/Server Architectures for DBMSs
• Classification of Database Management Systems
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
3 of 76

4. DBMS Evolution
• Monolithic Systems
– Whole DBMS software package was in one integrated system
• Modern DBMS packages
– Modular in design
– Replaced large Mainframe computers to computers (workstations & PC) connected via
networks to servers (like Web servers, DB servers, File servers, Application servers)
• i.e. Basic client/server DBMS architecture
– Client module
» Application programs and user interfaces (form/menu -based GUIs) that access DB
» Run on a user workstation or PCs
– Server module
» Handles data storage, access, search, and other functions
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
4 of 76

5. Data Models (1/2)
• Data abstraction
– Suppression of details of data organization and storage & highlighting of the essential
features for an improved understanding of data
– Different users can perceive data at their preferred level of detail
• Data Model
– Provides means to achieve data abstraction
– Collection of concepts that describe DB structure
• i.e. Data types, relationships, and constraints that apply to the data
– Basic operations
• Example: Insert, delete, modify, or retrieve operations on any kind of object
– Include dynamic aspects or behavior of DB application
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
5 of 76

6. Data Models (2/2)
• Dynamic aspects or behavior of DB application (contd.)
– DB designer can specify user-defined operations on DB objects.
• E.g. COMPUTE_GPA
– Fundamental to OO Data Models
– It can be incorporated into more traditional data models
• Example
– The basic relational data model has a provision to attach behavior to the relations in the form of
persistent stored modules known as stored procedures
– Object-relational models can extend the basic relational model
No longer part of
Software Design alone
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
6 of 76

7. Categories of Data Models (1/7)
• Categorization is based on the type of concepts the model uses to describe DB
• Categories
– High Level (or) Conceptual data model
– Representational (or) Implementation data model
– Low Level (or) Physical data model
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
7 of 76

8. Categories of Data Models (2/7)
• High-level (or) Conceptual data models
– Independent of any specific technology or implementation details
– Example: Entity-Relationship (ER) model
– Concepts used (Entity, Attribute & Relationship)
• Entity: Represents a real-world object with physical or conceptual existence
– Example: An employee or a project in the table
• Attribute: Property that describes an entity
– Example: Employee’s name, salary
• Relationship: Association among the entities
– Example: “works-on” relationship between an employee and a project
– Few additional abstractions used for advanced modeling
• Generalization, Specialization, and Categories (union types)
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
8 of 76

9. 2/20/2024
Categories of Data Models (3/7)
• High-level (or) Conceptual data models (contd.)
– Example: Conceptual data model for a university
• Entity: Student
– Attributes: StudentID, Name, DateOfBirth
– Relationships: EnrollsIn (with Course entity)
• Entity: Course
– Attributes: CourseID, Title, Credits
– Relationships: Teaches (with Professor entity)
• Entity: Professor
– Attributes: ProfessorID, Name, Department
– Relationships: Teaches (with Course entity)
– Conceptual model focuses on the entities and their relationships without concerning
itself with how these entities are stored or accessed in a database
Christalin Nelson | Systems Cluster | SoCS
9 of 76

10. Categories of Data Models (4/7)
• Representational (or) Implementation (or) Logical data models
– Translate conceptual model into a format that can be implemented in a specific DBMS
• It involves defining tables, columns, keys, and relationships
• i.e. Represent data using record structures. Also called record-based data models
– Used most frequently in traditional commercial DBMSs
– Example: Relational data model, Legacy data models (network & hierarchical models)
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
10 of 76

11. 2/20/2024
Categories of Data Models (5/7)
• Representational data model (contd.)
– Example: Logical data model based on conceptual model (slide-9) for a relational DB
• Table: Student
– Columns: StudentID (Primary Key), Name, DateOfBirth
• Table: Course
– Columns: CourseID (Primary Key), Title, Credits
• Table: Professor
– Columns: ProfessorID (Primary Key), Name, Department
• Table: Enrollment
– Columns: StudentID (Foreign Key), CourseID (Foreign Key)
– Entities are translated into tables, and relationships are represented using foreign keys
Christalin Nelson | Systems Cluster | SoCS
11 of 76

12. Categories of Data Models (6/7)
• Low Level or Physical data model
– Describe the details of how data is stored as files in the computer storage media
• i.e. By representing information such as record formats, record orderings, and access paths
– Access paths
• A structure that makes the search for a particular DB record more efficient
• Example: Index
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
12 of 76

13. Categories of Data Models (7/7)
• Object data model
– A new family of higher-level implementation data models (closer to conceptual data
models) – used in Software engineering
– Object Data Management Group (ODMG)
• Defined the standard for object databases called ODMG object model
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
13 of 76

14. Schemas (1/5)
• Database Schema
– Database description specified during DB design (Does not change frequently)
• Schema diagram
– Displays the structure of each record type and not actual instances of record
– Shows selected aspects of the schema
• Example: Data type of each attribute and Relationships among various files are not shown
– Can show some type of constraints
• Example: A constraint “students majoring in computer science must take CS1310 before the
end of their 1st year” cannot be shown
– Many constructed DB states can correspond to a DB schema
• Schema construct
– Each object in the schema
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
14 of 76

15. University Database that stores student and course information
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
15 of 76

16. Schema Diagram for the database
2/20/2024
Schema
Construct
Christalin Nelson | Systems Cluster | SoCS
16 of 76

17. Schemas (4/5)
• Database state (or) Snapshot
– Data in DB at a particular moment in time
• Also called the current set of occurrences (or) Instance
– Different possible states include
• Empty State: Define a new database – Specify database schema to the DBMS
• Initial State: Populate or load initial data
• Current State: State at any point in time
• Valid State: Satisfies the structure and constraints specified in the schema
– In a given DB state, each schema construct has its own current set of instances
• Example:
– STUDENT construct will contain the set of individual student entities (records) as its instances
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
17 of 76

18. Schemas (5/5)
• DBMS stores the descriptions of schema constructs and constraints (i.e. metadata)
in the DBMS catalog
• Intension (Schema) & Extension (DB state)
• Schema evolution
– Schema changes are less frequent
– Changes applied to the schema as application requirements change
– Example:
• Add Date_of_birth to STUDENT schema
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
18 of 76

19. 2/20/2024
Three-Schema Architecture (1/9)
• Also known as ANSI/SPARC architecture
– Proposed by Tsichritzis and Klug (1978)
• Framework for DBMS that separates DB's
structure and user views into three levels
of abstraction
– External or user view (External schema)
– Conceptual schema
– Internal schema
• Goal
– Separate user applications from physical DB
• Allows flexibility, security, and efficient
management of complex databases
Christalin Nelson | Systems Cluster | SoCS
19 of 76

20. Three-Schema Architecture (2/9)
• Internal Schema
– Lowest level of data abstraction
– Describes how data is physically stored and organized within the DB system
– It includes data structures, storage organization, indexing techniques, and access
methods optimized for efficient data retrieval and manipulation
• i.e. Storage of data on a storage medium (disk or memory)
• Can also include Data Compression and Encryption techniques
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
20 of 76

21. 2/20/2024
Three-Schema Architecture (3/9)
• Example
– Internal Schema for a RDBMS, focusing on storage of a single table representing
employee information
• Table: Employee
– Columns: EmployeeID, Name, Department, Salary
– In the internal schema, this table might be represented as follows:
• (1) Data Storage
– The data for the Employee table is stored in a file or set of files on disk
– Common File organization techniques: heap files, sorted files, or hashed files
• (2) Buffer Management
– DBMS manages a buffer pool in memory to cache frequently accessed data pages from the disk
– Buffer management algorithms (like LRU or clock replacement) are used to determine
» Pages to be kept in memory
» Pages to be evicted when the buffer is full
Christalin Nelson | Systems Cluster | SoCS
21 of 76

22. 2/20/2024
Three-Schema Architecture (4/9)
• Example (contd.)
• (3) Data Structures
– Depending on data types and storage requirements, data for each record is stored in a fixed or
variable-length format
» Fixed-length format might allocate a fixed no. of bytes for each field
» Variable-length format might use pointers or delimiters to indicate start & end of each
field's data
• (4) Indexing
– Indexes can be created on one/more columns to improve data retrieval performance
– Indexes are stored separately from the data file & contain sorted lists of key values and pointers
to the corresponding records in data file
– Common indexing techniques: B-tree indexes, hash indexes, and bitmap indexes
Christalin Nelson | Systems Cluster | SoCS
22 of 76

23. 2/20/2024
Three-Schema Architecture (5/9)
• Example (contd.)
• (5) Access Methods
– Used to retrieve and manipulate data in table efficiently
– They are optimized for different types of queries & operations
– Common Access Methods: sequential scanning, index scans, and hash joins
Christalin Nelson | Systems Cluster | SoCS
23 of 76

24. 2/20/2024
Three-Schema Architecture (6/9)
• Conceptual Schema
– Represents the global view of the entire DB, independent of any specific user's view
• i.e. It describes the structure of the whole DB for a community of users
• It provides a unified and consistent representation of data model shared by all users and
applications interacting with the DB
– Defines logical structure of DB, including all entities, attributes, relationships, and
constraints
– Example
• Entity: Employee
– Attributes: EmployeeID, Name, Department, Salary
• Entity: FinancialTransaction
– Attributes: TransactionID, Date, Amount, Description
Christalin Nelson | Systems Cluster | SoCS
24 of 76

25. Three-Schema Architecture (7/9)
• External schema
– Has multiple External schemas or user Views
• Each user or application may have its own view of the data (external schema), tailored to
its specific needs and requirements
– Each external schema corresponds to a specific user group or application and defines
the subset of data and operations relevant to their tasks.
– Example
• External View 1 (HR Department)
– Displays employee information such as name, department, and salary.
– Allows for updating employee records and querying payroll data.
• External View 2 (Finance Department)
– Focuses on financial transactions, including invoices, payments, and expenses.
– Provides tools for generating financial reports and analyzing cash flows.
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
25 of 76

26. 2/20/2024
Three-Schema Architecture (8/9)
• Mappings
– Processes of transforming requests and results between levels
– DBMS uses additional software to accomplish these mappings by referring to the
mapping information in the catalog
– In most DBMSs that support user views, the external and conceptual schemas are both
specified using the same data model
• Example: RDBMS like Oracle uses SQL
– Some DBMSs allow different data models to be used at conceptual and external levels
• Example: Universal Database (UDB), a DBMS from IBM uses a relational model to describe
conceptual schema & uses an OO model to describe an external schema
– Some DBMSs (especially those that support small DBs) do not support user views to
reduce the time consumed in mapping
Christalin Nelson | Systems Cluster | SoCS
26 of 76

27. 2/20/2024
Christalin Nelson | Systems Cluster | SoCS
External Schema
(User View)
Conceptual Schema
Internal Schema
(Physical storage)
SELECT Name FROM Employee;
Entity: Employee
Attributes: EmployeeID, Name
Entity: Department
Attributes: DepartmentID, Name
HR's query is mapped by identifying
the relevant entities and attributes.
Example: "Name" maps to "Name"
attribute of the "Employee" entity.
Conceptual schema's entities &
relationships are mapped to Physical
storage structures.
Example: "Employee" entity is
mapped to table named "Employee"
with columns for "EmployeeID" and
"Name“.
Conceptual schema's entities &
attributes are mapped to External
schema's view.
Example: "Employee" entity's
attributes "Name” is presented in the
HR's query result.
When data is retrieved from physical
storage, it needs to be mapped back
to the Conceptual schema for
interpretation.
Example: The retrieved data from the
"Employee" table is mapped to the
"Employee" entity with the attribute
"Name“.
27 of 76

28. Data Independence
• Schema at one level of a DB system can be changed without having to change the
Schema at the other level
• Whenever we have a multiple-level DBMS, its catalog must be expanded to
include information on how to map requests and data among the various levels
• Types
– Logical Data Independence
– Physical Data Independence
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
28 of 76

29. 2/20/2024
Logical Data Independence (1/2)
• Change Conceptual schema without changing External schemas or Application
programs
– i.e. After the logical reorganization of Conceptual schema, application programs that
reference the External schema constructs must work as before
– Example
• Expand/reduce DB (add/delete a record type or data item)
• Change constraints
• Note
– Allowing structural and constraint changes without affecting application programs is a
much stricter requirement
Christalin Nelson | Systems Cluster | SoCS
29 of 76

30. 2/20/2024
Logical Data Independence (2/2)
Christalin Nelson | Systems Cluster | SoCS
Transcript View
View definition & mapping
should be modified
Change
Transcript View is not
affected
30 of 76

31. 2/20/2024
Physical Data Independence (1/2)
• Change Internal schema without having to change Conceptual schema (External
schemas need not be changed as well)
– i.e. Some physical files are reorganized (by creating additional access structures to
improve the performance of retrieval or update)
– The same data as before remains in the DB
• Example
– Providing an access path to improve retrieval speed of section records by semester
and year should not require a query such as “list all sections offered in fall 2008” to be
changed, although the query would be executed more efficiently by the DBMS by
utilizing the new access path.
Christalin Nelson | Systems Cluster | SoCS
31 of 76

32. 2/20/2024
Physical Data Independence (2/2)
• Examples of Physical details that can be hidden from user
– Exact location of data on disk
– Hardware details of storage encoding, placement, compression, splitting, merging of
records
Christalin Nelson | Systems Cluster | SoCS
32 of 76

33. DBMS Languages (1/6)
• (1) DB Design
• (2) Select DBMS to implement DB
• (3) Specify Conceptual and Physical Schemas, Mappings
– Case-1: No strict separation of conceptual and internal levels is maintained
• Data definition language (DDL) is used to specify both schemas and mapping
– DDL compiler processes DDL statements, identifies descriptions of schema constructs & store
schema descriptions in the DBMS catalog
– Case-2: Clear separation is maintained between conceptual and internal levels
• DDL is used to specify conceptual schema
• Storage definition language (SDL) is used to specify internal schema
– Note: In most RDBMSs, SDL is absent. So, internal schema is specified by the combination of
functions, parameters & specifications related to storage. This allows to control indexing choices
& mapping of data to storage.
• DDL or SDL is used to specify mappings
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
33 of 76

34. DBMS Languages (2/6)
– Case-3: True three-schema architecture is maintained
• View definition language (VDL) specifies user views/mappings to Conceptual schema
• Note:
– In most DBMS: DDL is used to define both conceptual and external schemas
– In RDBMS: SQL is used instead of VDL to define user/application views as results of predefined
queries
• (4) DB schemas are compiled
• (5) DB is populated with data
• (6) DB manipulation
– Data manipulation language (DML)
• Retrieval, insertion, deletion & modification
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
34 of 76

35. DBMS Languages (3/6)
• Comprehensive relational DB language (SQL)
– Combination of DDL, VDL, DML, constraint specification, schema evolution, and other
features
• SDL was a component in early versions of SQL
• SDL is removed from SQL to keep it at conceptual & external levels only
– Includes statements for constraint specification, schema evolution, and other features
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
35 of 76

36. 2/20/2024
DBMS Languages (4/6)
• Types of DML
– High-level (or) non-procedural DML
– Low-level (or) procedural DML
• Low-level DML
• Must be embedded in a general-purpose programming language (Host language)
• To be precompiled & then processed by DBMS
• Also called Data sublanguage
• Processed Record-at-a-time
– Example: DL/1 for Hierarchical model
• GET UNIQUE, GET NEXT, GET NEXT WITHIN PARENT
Christalin Nelson | Systems Cluster | SoCS
36 of 76

37. 2/20/2024
DBMS Languages (5/6)
• High-level DML
• Used to specify complex DB operations concisely
• Entered interactively from a display monitor/terminal (or) embedded in a general-
purpose programming language
• Known as a Query Language
• Also called as a Declarative Language
• Specifies which data to retrieve, does not specify how to retrieve it
• Processed Set-at-a-time or set-oriented
• Example: SQL
Christalin Nelson | Systems Cluster | SoCS
37 of 76

38. 2/20/2024
DBMS Languages (6/6)
• How do different users use DML?
• Casual end users: Use a high-level query language to specify their requests
• Programmers: Use DML in its embedded form
• Naive and parametric users: Use GUIs for interacting with DB
• Can also be used by casual users or others who do not want to learn the details of a high-
level query language
Christalin Nelson | Systems Cluster | SoCS
38 of 76

39. DBMS Interfaces (1/2)
• Menu-based interfaces for Web clients or browsing
– Drop-down menus in Web-based UI and Browsing IF
• Forms-based interfaces
– Auto populated forms
– Used by Naive users for canned transactions
– Form Specification language
• SQL*Forms also known as Oracle Forms
– Tool for building data entry and manipulation forms for Oracle databases
• GUIs
– Displays a schema to the user in diagrammatic form. The user then can specify a query
by manipulating the diagram
– Can use menu and forms
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
39 of 76

40. DBMS Interfaces (2/2)
• Natural language interfaces
– Contains its schema (similar to DB conceptual schema) & dictionary (important words)
• The IF interprets and generates a high-level query
– Keyword-based querying for relational DB
• Speech input and output
– Library of predefined words
• Interfaces for parametric users
– Use single function keys to invoke routine and repetitive transactions with minimal
keystrokes
• Interfaces for DBA
– Privileged commands
• Creating accounts, setting system parameters, granting account authorization, changing a
schema, and reorganizing the storage structures of a DB
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
40 of 76

41. 2/20/2024
Database System Environment (1/7)
• Consists of
– DBMS Component Modules
– Database System Utilities
– Tools, Application Environments, and Communications Facilities
• DBMS Component Modules
– Has two main parts
• Various users of DB environment & their interfaces
• Internals of DBMS responsible for data storage & transaction processing
Christalin Nelson | Systems Cluster | SoCS
41 of 76

42. Component Modules
of a DBMS and their
Interactions
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
Various users of DB
environment & their
interfaces
Internals of DBMS
responsible for data
storage & transaction
processing
42 of 76

43. Database System Environment (3/7)
• DDL compiler
– Processes schema definitions, specified in the DDL, and stores descriptions of the
schemas (meta-data) in the DBMS catalog
• Catalog includes information such as
– Names and sizes of files, names and data types of data items, storage details of each
file, mapping information among schemas, and constraints
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
43 of 76

44. Database System Environment (4/7)
• Query Compiler
– Interactive Queries are parsed and validated for correctness of the query syntax, the
names of files and data elements & converted to Internal Query
• Query Optimizer
– Performs rearrangement/reordering of operations, elimination of redundancies, and
use of correct algorithms and indexes during execution
– Consults System catalog (for statistical & other physical information about stored data)
– Generates executable code (that performs necessary operations for Query)
– Makes calls on the runtime processor
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
44 of 76

45. Database System Environment (5/7)
• Pre-compiler
– Extracts DML commands from an application program (submitted by Application
Programmers) written in a host programming language (Java, C, or C++) and sends to
the DML compiler
– The rest of the program is sent to the host language compiler
• DML compiler
– Compiles DML command into object code for database access
• Linking & Execution
– Object codes for DML commands & rest of program are linked to form a canned
transaction
– Parametric users supply parameters to the canned transactions
– The executable code includes calls to the runtime DB processor
– Each execution is considered to be a separate transaction
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
45 of 76

46. Database System Environment (6/7)
• Runtime DB processor
– Executes Privileged commands, Executable query plans, and Canned transactions with
runtime parameters
– It works with
• System catalog and may update it with statistics
• Stored data manager
• Concurrency control & Backup/Recovery systems are integrated into working of runtime DB
processor for purposes of transaction management
– It handles other aspects of data transfer. E.g. Buffer management in main memory
(though R/W is controlled by OS)
• Stored Data Manager
– DB & Catalog are stored in disk
– It uses basic OS services for carrying out low-level I/O (i.e. R/W) operations between
the disk and main memory
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
46 of 76

47. Database System Environment (7/7)
• Client (Runs DBMS client software)  Application server  DB server (runs DB)
• Note:
– If the computer system is shared by many users
• OS will schedule DBMS disk access requests and DBMS processing along with other
processes.
– If the computer system is mainly dedicated to run DB server
• DBMS will control the main memory buffering of disk pages
• DBMS also interfaces with
– Compilers for general-purpose host programming languages
– Application servers & Client programs running on separate machines through system-network
interface
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
47 of 76

48. Database System Utilities (1/2)
• Loading
– Load existing data files into the DB (or) transfer in between different DBMSs
• Conversion tools
– Vendor tools for Hierarchical DBMS (E.g. IMS of IBM) and Network DBMSs (E.g. IDMS of
Computer Associates, SUPRA of Cincom, and IMAGE of HP) for conversion to RDBMS
• Backup
– Create DB backup onto tape or other mass storage media (used to restore during
catastrophic disk failures)
– Incremental backup (record changes made in DB since last backup)
• Database storage reorganization
– Reorganize a set of DB files into different file organizations & create new access paths
for increased performance
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
48 of 76

49. Database System Utilities (2/2)
• Performance monitoring
– Monitors DB usage and provides statistics to DBA to make decisions to increase
performance (reorganizing files, and adding/drop index)
• Other utilities
– Sorting files
– Handling data compression
– Monitoring user access
– Interfacing with the network
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
49 of 76

50. Tools, Application Environments, and Communications Facilities
• CASE Tools (Design phase)
• Expanded data dictionary or Information Repository
– Stores design decisions, usage standards, application program descriptions, and user
information in addition to storing catalog information (about schemas and constraints)
• Application development environments
– Provide an environment for developing DB applications
– Include facilities that help in many facets of DB systems
• i.e. DB design, GUI development, querying & updating, and application program development
– Common Examples: PowerBuilder (Sybase), JBuilder (Borland)
• Communications software
– Remote users (from DB system site) can access DB through terminals, workstations, or PCs
– DB/DC system (integrated DBMS & Data communications system)
– Distributed DBMSs
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
50 of 76

51. Architectures for DBMS (1/4)
• Centralized DBMSs Architecture
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
Early Architectures with Mainframe Computers
• Support all system functions (including DBMS functionality) of terminals
Centralized DBMS functionality
• User interface programs and application programs in user PC or workstation
• DB operations on Centralized machine
Client/server DBMS architectures
• DBMS systems at user side
51 of 76

52. 2/20/2024
Physical Centralized
Architecture
Christalin Nelson | Systems Cluster | SoCS
52 of 76

53. Architectures for DBMS (3/4)
• Basic Client/Server Architecture
– DBMS systems use the available processing power of client PCs
– Computing environment
• Large number of PCs and workstations
• Servers with specific functionalities
– i.e. File servers, database servers, web servers, e-mail servers, printer server
• Other software
• Connected via a network
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
53 of 76

54. Architectures for DBMS (4/4)
• Client
– User machine that provides UI capabilities and local processing
• Server
– A high-end system containing sophisticated hardware and software
– Provide services to client machines
• Includes file access, printing, archiving, or DB access
• Types of DBMS Client-Server Architecture
– 2-tier
• Software components are distributed over two systems: client and server
– 3-tier
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
54 of 76

55. 2/20/2024
2-Tier Client-Server DBMS Architecture (1/5)
• Client Tier
– User Interface (UI)
• User interacts with the application (desktop application, a web browser, or a mobile app)
– Presentation Logic
• Handles data presentation and user interaction
• May include UI components (such as forms, buttons, and menus)
• Server Tier
– Database Server
• The DBMS resides here. Manages storage, retrieval, and manipulation of data.
– Application or Business Logic
• Tightly coupled with Presentation logic on client side
– However, some basic validation and processing may occur on the server side
Christalin Nelson | Systems Cluster | SoCS
55 of 76

56. 2-Tier Client-Server DBMS Architecture (2/5)
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
Physical 2-tier client/server
Architecture
Logical 2-tier client/server Architecture
56 of 76

57. 2/20/2024
2-Tier Client-Server DBMS Architecture (3/5)
• Example Architecture-1
– Server (Query server or Transaction server)
• Handles Query and transaction functionality related to SQL processing
• Called SQL server in RDBMS
– Client
• Handles UI programs and application programs
• Database Connectivity
– ODBC
» Provides APIs (used by Clients to establish a connection with DB)
» ODBC drivers are provided by vendors
– JDBC
» Java client programs can access one/more DBMSs through standard interface
Christalin Nelson | Systems Cluster | SoCS
57 of 76

58. 2/20/2024
• Example Architecture-2
– Client/server interaction is more tightly coupled & done internally by DBMS modules
– Server (Data Server)
• Includes data storage on disk, provides data in disk pages to the client, local concurrency
control and recovery, buffering and caching of disk pages
– Client
• Includes UI, structuring of complex objects from data in buffers, concurrency control and
recovery across multiple servers, DBMS interactions with programming language compilers,
data dictionary functions, and global query optimization
Christalin Nelson | Systems Cluster | SoCS
2-Tier Client-Server DBMS Architecture (4/5)
58 of 76

59. 2/20/2024
2-Tier Client-Server DBMS Architecture (5/5)
• Pros
– Simplicity and seamless compatibility with existing systems
– Suitable for simpler small-scale applications
• Cons
– Limited scalability
– Limited flexibility
• Change/update to application & maintenance is challenging as business logic is tightly
coupled with presentation layer (client side)
– Security concerns
– Unsuitable for modern web applications
Christalin Nelson | Systems Cluster | SoCS
59 of 76

60. 2/20/2024
3-Tier Client-Server DBMS Architecture (1/3)
• Presentation Tier (Client Tier)
– Responsible for presenting information to the user and collecting user inputs
– It includes UI (such as web browsers, mobile apps, or desktop applications)
• Application Tier (Middle Tier or Business Logic Tier)
– Contains the application logic that processes user requests, executes business rules,
and interacts with Data tier
– May include web servers, application servers, and other middleware components
• Data Tier (Server Tier or Database tier)
– Stores and manages the data used by the application
– Includes DB servers (such as Oracle, MySQL, SQL Server) or other data storage systems
Christalin Nelson | Systems Cluster | SoCS
60 of 76

61. 2/20/2024
3-Tier Client-Server DBMS Architecture (2/3)
• Example Architecture-1
– Tier-1 (UI)
• GUI, additional application-specific business rules
– Tier-2 (Application rules)
• Runs application programs
• Stores business rules (procedures and constraints)
• Improve DB security (check client’s credentials)
• Partial data processing
– Example: Web Server retrieves query results from
Tier-3 (DB server) => Format into dynamic Web
pages that are viewed by the user in Tier-1 (Web
browser)
– Tier-3 (Data Access)
Christalin Nelson | Systems Cluster | SoCS
61 of 76

62. 2/20/2024
3-Tier Client-Server DBMS Architecture (3/3)
• Example Architecture-2
– Tier-1
• Data Entry and information display
– Tier-2
• Handles intermediate rules and constraints
• Pass information to upper/lower tiers
• Can be a Web Server
– Tier-3
• All DB management services
Christalin Nelson | Systems Cluster | SoCS
62 of 76

63. 2/20/2024
n-Tier Client-Server DBMS Architecture (1/3)
• 4-tier Client-Server Architecture
– Presentation Tier (Client)
• Includes UI components (web browsers, mobile apps, or desktop applications) for user
interaction with the application
– Application Tier (Client-Side Application)
• Contain client-side application logic (may include client-side frameworks & validation logic)
– Business Logic Tier (Server) or middle tier or application server
• Contains core business logic of the application
• May consist of web servers, application servers (E.g. Apache Tomcat, Jboss, IBM
Websphere), or microservices (E.g. Spring Boot, Node.js, or Docker containers)
– Data Tier (Database Server)
• Manage and store data. Ensures data integrity, security, and availability
• May involve relational DBs, NoSQL DBs, or other data storage solutions
Christalin Nelson | Systems Cluster | SoCS
63 of 76

64. 2/20/2024
n-Tier Client-Server DBMS Architecture (2/3)
• 5-tier Client-Server Architecture
– Presentation Tier (Tier 1)
– Client Application Logic (Tier 2)
• Handles client-side application logic
• May include client-side scripting languages like JavaScript
– Web Server (Tier 3)
• Hosts web applications (serves static and dynamic content)
• Handles HTTP requests from clients
– Application Server (Tier 4)
• Contains core business logic and application services
• May include middleware components, application frameworks, and services like APIs
– Database Server (Tier 5)
Christalin Nelson | Systems Cluster | SoCS
64 of 76

65. 2/20/2024
n-Tier Client-Server DBMS Architecture (3/3)
• 6-tier Client-Server Architecture
– Presentation Layer
– Application Layer
• Contains the business logic and processing logic of the system
• It may include application servers, middleware, or microservices
– Session Layer
• Handles session establishment, maintenance, and termination
• It may include protocols such as HTTP, WebSocket, or custom session management protocols
– Logic Layer
• Contains the core business logic and rules of the application
• It may include business logic components, workflow engines (E.g. Apache Airflow), or rule
engines (E.g. Drools)
– Data Access Layer
• Handles tasks such as data retrieval, storage, and manipulation
• It may include ORM (Object-Relational Mapping) frameworks, database drivers, or APIs
– Data Storage Layer
Christalin Nelson | Systems Cluster | SoCS
65 of 76

66. 2/20/2024
Classification of DBMS (1/7)
• Based on the structure of the Data model (1/4)
– Hierarchical DBMS
• Organizes data in a tree-like structure with parent-child relationships
• Examples: IMS (IBM), System 2000 (SAS Inc.), TDMS
– Network DBMS
• Extends hierarchical model. Each record can have multiple parent/child records.
• Examples:
– IDMS – Tag Data Management Software – Used in industrial automation and control systems
– DMS 1100 – Digital Multiplex System 100 – Used in telecom networks
– IMAGE, VAXDBMS, SUPRA, VSAM file system
Christalin Nelson | Systems Cluster | SoCS
Legacy DBMS?
66 of 76

67. 2/20/2024
Classification of DBMS (2/7)
Christalin Nelson | Systems Cluster | SoCS
Database Schema in
Network Model
Hierarchical Model
67 of 76

68. 2/20/2024
Classification of DBMS (3/7)
• Based on the structure of the Data model (3/4)
– Relational DBMS
• Represents data as tables (relations) consisting of rows (tuples) and columns (attributes)
• Relationships between tables are defined by keys
• Examples: Oracle DB, MySQL, Microsoft SQL Server
– Object-Oriented DBMS
• Extends relational model by incorporating OO concepts. Data is organized into objects with
properties and behaviors
• Examples: db4o, GemStone/S, ObjectDB
– Object-Relational DBMS
• Examples: Oracle DB, IBM Db2, Microsoft SQL Server
Christalin Nelson | Systems Cluster | SoCS
68 of 76

69. 2/20/2024
Classification of DBMS (4/7)
• Based on the structure of the Data model (4/4)
– NoSQL DBMS
• Includes various non-relational DBMS designed to handle diverse data types and use cases
• Examples: MongoDB (document-oriented), Cassandra (wide-column), Neo4j (graph)
– Document DBMS
• Stores data in flexible, semi-structured document formats such as JSON (JavaScript Object
Notation), BSON or XML (Native XML DBMS)
• Examples (Native XMS DBMS): MarkLogic, BaseX
– Graph DBMS
• Represents data as nodes (entities) and edges (relationships between entities)
• It is well-suited for modeling complex networks and relationships
• Example: Neo4j
Christalin Nelson | Systems Cluster | SoCS
69 of 76

70. Classification of DBMS (5/7)
• Based on the number of users supported by the system
• Single-user
• Multi-user
• Based on Architecture
– Centralized
– Distributed (Apache Cassandra, MongoDB)
• Homogeneous
• Heterogeneous (use different data models, query languages, or storage mechanisms)
– Middleware could support different DBMS
– Federated DBMS (or multi-DB system with a single unified view)
» Different DBMSs are loosely coupled and exhibit autonomy, distribution transparency, etc.
– P2P (CouchDB, HyperDex)
– Client-Server
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
70 of 76

71. Classification of DBMS (6/7)
• Based on Cost
• Open source (MySQL, MariaDB, PostgreSQL)
• Different types of licensing
• Proprietary DBMS, Open Source, Freemium (MongoDB), Community Edition, Enterprise
Edition
• Based on Deployment Models
– On-premises DBMS
– Cloud DBMS (Amazon RDS, Google Cloud SQL, Azure SQL Database)
– Hybrid DBMS (Apache Trafodion)
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
71 of 76

72. Classification of DBMS (7/7)
• Based on Usage
– Operational DBMS
– Analytical DBMS (Apache Hive)
• Other Classifications
– Based on the types of access path options for storing files
– General or special-purpose
• Designed and built for a specific application
• Cannot be used for other applications without major changes
– Example: Airline reservations, Telephone directory systems
2/20/2024
Christalin Nelson | Systems Cluster | SoCS
72 of 76

73. 2/20/2024
Codd’s Rules (1/3)
• Information Rule
– Data is stored in tables (relations) containing rows (tuples) and columns (attributes)
• Guaranteed Access Rule
– Data should be accessible by specifying table name, primary key, and column name
• Systematic Treatment of Null Values
– Null values are considered as a valid data value, distinct from zero or empty string
• Dynamic Online Catalog Based on the Relational Model
– DB schema (catalog) is stored & managed using same relational model as regular data
• Comprehensive Data Sublanguage Rule
– DB supports a DML that is used to define, query, and manipulate data in DB
Christalin Nelson | Systems Cluster | SoCS
73 of 76

74. 2/20/2024
Codd’s Rules (2/3)
• Physical Data Independence
– Changes to the physical storage structure of DB should not affect the logical schema,
application programs, or end-users
• Logical Data Independence
– Changes to the logical schema (tables, views, etc.) should not require changes to the
application programs or end-user queries
• Integrity Independence
– Integrity constraints (such as primary key, foreign key, and domain constraints) should
be separate from application programs and stored as part of the catalog
• Distribution Independence
– DB should be able to distribute portions of itself to different locations without
affecting the application programs or end-user queries
Christalin Nelson | Systems Cluster | SoCS
74 of 76

75. 2/20/2024
Codd’s Rules (3/3)
• View Updation Rule
– Views (virtual relations) are updatable through the same DML as base tables if the
updates do not violate integrity constraints
• High-Level Insert, Update, and Delete
– DB supports high-level operations for inserting, updating, and deleting data without
requiring users to specify low-level access paths
• Non-Subversion Rule
– If DB system provides a low-level interface (e.g., allowing direct access to storage), it
should not be possible to bypass the integrity rules and security constraints defined in
the higher-level relational language
Christalin Nelson | Systems Cluster | SoCS
75 of 76

76. Christalin Nelson | Systems Cluster | SoCS
2/20/2024
76 of 76