LEC-2: DBMS Architecture

1. View of Data (Three Schema Architecture)

a. The major purpose of a DBMS is to provide users with an abstract view of the data. That is, the system
hides certain details of how the data is stored and maintained.

Abstraction has two main purposes:

To provide simplicity by hiding unnecessary implementation details. The user is only concerned
with the functionality, which is provided as simply as possible through abstraction.
To provide security. For example, Amazon stores all customer data in a database. Internally,
different departments such as logistics and finance access only the relevant parts of the data. The
logistics department may only see the address information, while the finance department may not
need the address. Although all information is stored in the database, only a certain view is
displayed to each concerned department.

b. To simplify user interaction with the system, abstraction is applied through several levels.

c. The main objective of the three-level architecture is to enable multiple users to access the same data
with personalized views while storing the underlying data only once.

d. Physical level / Internal level schema:

The lowest level of abstraction describing how the data is stored.

Uses low-level data structures.
Contains the physical schema which describes the physical storage structure of the database.
Covers storage allocation (e.g., N-ary trees), data compression, encryption, etc.
Goal: Define algorithms that allow efficient access to data.

e. Logical level / Conceptual level schema:

Maps physical level content to the conceptual or logical level.

The conceptual schema describes the design of the database at the conceptual level, including what
data are stored and the relationships among those data. For example, it defines tables such as student,
customer, courses, and their relationships.
Users at the logical level do not need to be aware of physical-level structures.
The DBA uses the logical level of abstraction to decide what information to keep in the database.
Goal: Ease of use.

f. View level / External level schema:

Provides different views to different end-users, simplifying their interaction with the system.
Each view schema describes the part of the database a particular user group is interested in and hides
the rest.
At the external level, a database contains several schemas called subschemas, which define different
views.
Views also provide a security mechanism to prevent users from accessing certain parts of the
database.
2. Instances and Schemas
a. The collection of information stored in the database at a particular moment is called an instance of the
database.

b. The overall design of the database is called the database schema.

c. A schema is a structural description of data and does not change frequently, whereas data may change
frequently.

d. The database schema corresponds to variable declarations (along with types) in a program.

e. There are three types of schemas: physical, logical, and several view schemas called subschemas.

f. The logical schema is the most important in terms of its effect on application programs, as programmers
construct applications using the logical schema.

g. Physical data independence: Changes in the physical schema should not affect the logical schema or
application programs.

By default, when we talk about schema, we refer to the logical schema, which is also called the
database schema or simply schema.
The logical schema has these main components:
Attributes of tables.
Consistency constraints such as data types, primary keys, and not-null constraints.
Relationships between different entities, tables, or collections.

3. Data Models
a. Provide a way to describe the design of a database at the logical level.

b. Underlying the structure of the database is the data model: a collection of conceptual tools for
describing data, data relationships, data semantics, and consistency constraints.

c. Examples include the ER model, relational model, object-oriented model, and object-relational data
model (a mixture of object-oriented and relational).

4. Database Languages (for interacting with the database)

a. Data Definition Language (DDL): Used to specify the database schema.

b. Data Manipulation Language (DML): Used to express database queries and updates.

c. Practically, both language features are present in a single database language, e.g., SQL.

d. DDL:

Specifies the database schema.

Specifies consistency constraints that must be checked every time the database is updated (e.g.,
phone number must be 10 digits, name should be a string, age should be greater than five, etc.).
e. DML:

Data manipulation involves:

i. Retrieval of information stored in the database.
ii. Insertion of new information into the database.
iii. Deletion of information from the database.
iv. Updating existing information stored in the database.
Query language, a part of DML, specifies statements requesting the retrieval of information.

5. How is Database Accessed from Application Programs?

a. Applications (written in host languages like C/C++, Java) interact with the database.

b. For example, a banking system’s payroll module accesses the database by executing DML statements
from the host language.

c. APIs are provided to send DML/DDL statements to the database and retrieve results. These APIs act as
two-way interfaces between the database and the host language.

Open Database Connectivity (ODBC) for C/C++.

Java Database Connectivity (JDBC) for Java.

JDBC and ODBC are APIs that allow typing SQL or specific query language code, enabling
communication and execution.

6. ODM and ORM

ODM (Object Document Mapper) and ORM (Object Relational Mapper) are tools/libraries that help you
interact with databases using objects in your programming language (like JavaScript, Python, etc.), but
they are used for different types of databases.

Comparison: JDBC/ODBC vs ODM/ORM

Feature JDBC / ODBC ORM / ODM

Type Low-level database API High-level abstraction layer / library

Level of High – You define models/classes and

Low – You write raw SQL queries
abstraction mostly avoid raw SQL

Establish connection and run SQL Map programming objects to database

Purpose
commands manually tables/documents

Database Manual queries, result sets, connection Automatic query generation, data
Interaction management mapping, and validation

Database ORM → SQL DBs, ODM → NoSQL DBs (like

Relational (SQL) – Not for NoSQL
Type MongoDB)
 ORM: Hibernate, Sequelize; ODM:
Examples JDBC (Java), ODBC (Windows apps)
Mongoose, MongoEngine

Analogy:
JDBC/ODBC is like a steering wheel and pedals: you control everything in your car, but you must know
how to drive it yourself (write SQL, handle connections).
ORM/ODM is like an autopilot system: you just tell it where to go (define a model or call .save() ), and
it handles the internal SQL/MongoDB queries and data handling for you.

ORM (Object Relational Mapping)

Used for: Relational databases like MySQL, PostgreSQL, SQLite, etc.
Maps: Objects in your code to rows in relational tables.
Example ORMs:
Sequelize ([Link] + SQL)
Hibernate (Java)
SQLAlchemy ORM (Python)
Entity Framework (C#)

Pros:

Abstracts away complex SQL queries.

Allows defining models/classes which map to database tables.
Supports joins, transactions, constraints, etc.

Example (Using Sequelize):

// Define a User model

const User = [Link]("User", {
name: [Link],
email: [Link],
});

This corresponds to a SQL table like:

CREATE TABLE Users (

name VARCHAR(255),
email VARCHAR(255)
);

ODM (Object Document Mapping)

Used for: Document-based NoSQL databases like MongoDB.
Maps: Objects in your code to documents in a collection.
Example ODMs:
 Mongoose ([Link] + MongoDB)
Morphia (Java + MongoDB)
MongoEngine (Python + MongoDB)

Pros:

Provides schema and validation even though MongoDB is schema-less.

Helps in querying and manipulating MongoDB data as objects.

Example (Using Mongoose):

const userSchema = new [Link]({

name: String,
email: String,
});

const User = [Link]("User", userSchema);

This would store documents like:

{ "name": "Alice", "email": "alice@[Link]" }

Summary Table:

Feature ORM ODM

Used With Relational DBs (SQL) Document DBs (NoSQL like MongoDB)

Maps To Tables and Rows Collections and Documents

Example Tool Sequelize, Hibernate Mongoose, MongoEngine

Schema Enforcement Strict schema via DB Optional (handled in code)

Query Language SQL or abstracted SQL MongoDB queries

7. Database Administrator (DBA)

The DBA works mostly at the logical level (developers and DBAs collaborate at the physical level).

a. A person who has central control of both the data and the programs that access those data.

b. Functions of a DBA:

i. Schema definition (e.g., defining the student schema at a school).

ii. Storage structure and access methods (at the physical level).
iii. Schema and physical organization modifications (both physical and logical levels).
iv. Authorization control (which department or person has access to which attributes or
sections of the database, i.e., views or subschemas).
v. Routine maintenance: 1. Periodic backups. 2. Security patches. 3. Any upgrades.
8. DBMS Application Architectures
Client machines, on which remote database users work, and server machines on which the DB system runs.

a. T1 (Tier-1) Architecture:
The client, server, and database all reside on the same machine.
Example: A local website deployed in local mode.

b. T2 (Two-Tier) Architecture:

i. Application is split into 2 components – Client and Server.

ii. Client machine sends queries directly to the DB Server using query languages like SQL.
iii. APIs such as ODBC (Open Database Connectivity) and JDBC (Java Database Connectivity) are
used for interaction between client and server.
iv. Business logic is present at client side, which directly interacts with the database.
v. Suitable for small-scale applications with few users.

Drawbacks:

Scalability issues as number of clients increase.

Tight coupling between client and DB.
Less secure – client has direct access to the database.

c. T3 (Three-Tier) Architecture:

i. Application is split into 3 logical components – Client, Application Server, and Database
Server.
ii. Client machine is a frontend-only interface, with no direct DB interaction.
iii. Client sends requests to Application Server, which processes logic and communicates with
Database Server.
iv. All business logic resides in Application Server – it decides what action to perform based
on client input.
v. Ideal for web-based (WWW) applications with many users.

Advantages:

Scalability – multiple app servers can serve multiple clients efficiently.

Data integrity – App server validates requests before sending to DB, reducing data corruption risk.
Security – DB is protected behind app server, no direct access from client.
Maintainability – changes in business logic require updates only in App server, not client.