Chapter 3

Multi-User DBMS Architectures

Teleprocessing Architecture

Teleprocessing is an older architecture for multi-user systems where a central computer (with a
single CPU) serves multiple "dumb" terminals. In this architecture:

• Centralized Processing: All data processing occurs within the central computer, which
handles the application programs and the Database Management System (DBMS).
• Terminals: User terminals are simple devices connected to the central computer, sending
and receiving messages via the operating system’s communications control subsystem.
• Limited Terminal Functionality: The terminals cannot perform any significant
processing on their own. They rely entirely on the central computer for processing tasks,
including formatting data for display.

Disadvantages:

• High Burden on Central Computer: The central computer is responsible for running
both the application programs and the DBMS, along with performing additional tasks like
data formatting for the terminals.

Evolution:

• Downsizing Trend: With the rise of high-performance personal computers and networks,
industries have started moving away from large mainframe computers to more cost-
effective networks of personal computers. This shift led to the development of file-server
and client-server architectures.

File-Server Architecture

In file-server architecture, a computer (the file-server) provides shared storage for files, such as
documents, spreadsheets, images, and databases. It typically operates within a Local Area
Network (LAN), where each workstation has its own application and database management
system (DBMS) but relies on the file-server for file storage and data access.

How It Works:

• Workstations run their own applications and DBMS.

• These DBMSs send requests to the file-server for the files needed to process data.
• The file-server acts as a shared hard disk, storing data and responding to file requests
from DBMSs on the workstations.
Disadvantages of File-Server Architecture:

1. High Network Traffic: File requests, such as fetching data for queries, create significant
network traffic, potentially leading to performance issues.
2. Multiple DBMS Installations: Each workstation needs its own copy of the DBMS,
increasing complexity and resource usage.
3. Complexity in Concurrency, Recovery, and Integrity Control: Since multiple DBMSs
may access the same files simultaneously, managing concurrency, recovery, and data
integrity becomes more difficult.

Two-Tier Client–Server Architecture

The two-tier client–server architecture separates system components into:

1. Client (Tier 1) – Handles the user interface, processes user input, and generates database
queries.
2. Server (Tier 2) – Manages database operations, processes requests, enforces security,
ensures data integrity, and returns results to the client.

How It Works:

• The client sends a request to the server (e.g., an SQL query).

• The server processes the request, retrieves the data, and sends the response back to the
client.
• The client then formats and presents the response to the user.

Advantages:

✅ Wider access to databases from various locations.

✅ Improved performance by allowing parallel processing on separate machines.
✅ Lower hardware costs since only the server needs high processing power.
✅ Reduced network traffic by sending only necessary data requests.
✅ Better consistency as integrity constraints are handled centrally.
✅ Compatibility with open system architectures.

The three-tier client-server architecture emerged in the mid-1990s to address the scalability
challenges of the two-tier model, which required “fat” clients with high resource demands and
extensive administration.

Structure of Three-Tier Architecture:

 1. User Interface Layer (Client): Runs on the end-user’s device and handles UI and basic
logic (e.g., input validation).
2. Business Logic Layer (Application Server): Processes data and manages business
rules, reducing client-side load.
3. Data Storage Layer (Database Server): Stores and retrieves data.

Advantages Over Two-Tier Architecture:

• Reduces client hardware costs by using a “thin” client.

• Centralized maintenance, reducing software distribution issues.
• Modularity, allowing easier updates or replacements of individual layers.
• Improved load balancing by separating business logic from database functions.
• Natural compatibility with web environments, where a web browser serves as the
client, and a web server acts as the application server

N-Tier Architecture – Extends the three-tier model by adding more layers, such as separate web
and application servers, enabling better load balancing and failover capabilities. N-tier
architecture extends the traditional three-tier model by adding more layers to improve
flexibility, scalability, and performance. One common approach is splitting the middle tier
into multiple layers, such as a separate Web server and application server.

Features.

• Web servers can be replaced with multiple servers (Web farm) for load balancing in
high-throughput environments.
• Application servers handle critical tasks like:
o Concurrency & network management
o Database access & connection pooling
o Legacy database support
o Clustering, load balancing & failover

Popular Application Servers:

1. Java EE (JEE) Application Servers:

o Provide transaction management, security, and scalability.
o Examples: WebLogic (Oracle), JBoss (Red Hat), WebSphere (IBM), Glassfish
(Open-source).
2. .NET Framework (Microsoft):
o Supports middle-tier application development for enterprise solutions.
3. Oracle Application Server:
o Helps build scalable multi-tier infrastructures for e-Business applications
 Middleware

Middleware is software that connects different applications or components, enabling

communication and data exchange in heterogeneous distributed systems. It provides a common
interface to manage complexity and allows flexibility for frequent modifications.

Types of Middleware (Hurwitz, 1998):

1. Asynchronous Remote Procedure Call (RPC):

o Allows a client to request a service from another system without waiting for a
response.
o Highly scalable but has low recoverability if the connection fails.
2. Synchronous Remote Procedure Call (RPC):
o Similar to asynchronous RPC, but the client must wait for a response before
continuing.
o Less scalable but offers better recoverability.
o Examples: Java RMI, XML-RPC, .NET Remoting, CORBA, Thrift
(Facebook).
3. Publish/Subscribe:
o An asynchronous messaging system where publishers send messages, and
subscribers receive only relevant ones.
o Enhances scalability and dynamic network topologies.
o Examples: TIBCO Rendezvous, Ice (ZeroC Inc.).
4. Message-Oriented Middleware (MOM):
o Uses message queues to store messages temporarily if the destination is busy.
o Supports asynchronous client-server communication.
o Examples: IBM WebSphere MQ, Microsoft MSMQ, Java JMS, Oracle
MessageQ.
5. Object Request Broker (ORB):
o Facilitates communication between distributed objects from different vendors.
o Uses CORBA (Common Object Request Broker Architecture) to integrate
multiple programming languages.
o Example: Orbix (Progress Software).
6. SQL-Oriented Data Access:
o Connects applications with databases across networks, translating SQL queries for
different databases.
o Examples: ODBC (Microsoft), JDBC (Java), database gateways (Oracle, IBM
DB2, Microsoft SQL Server OQL).

Chapter 4

. Relational Data Structure

A relational database consists of structured tables (relations) with rows (tuples) and columns
(attributes) to store and manage data efficiently. The key concepts of the relational model
include:
 • Relation (Table) – A structured collection of data presented as a two-dimensional table.
• Attribute (Column) – A named characteristic of a relation representing specific data.
• Tuple (Row) – A single record within a relation.
• Domain – A set of allowable values for an attribute.
• Degree – The number of attributes in a relation. For example, a table with four attributes
has a degree of four.
• Cardinality – The number of tuples (rows) in a relation, which changes over time as data
is added or removed

Mathematical Relations

In mathematics, a relation is a subset of the Cartesian product of two or more sets. The
Cartesian product of two sets, D₁ and D₂, is the set of all ordered pairs (x, y) where x is from D₁
and y is from D₂.

For example:

• If D₁ = {2, 4} and D₂ = {1, 3, 5}, the Cartesian product is:

D₁ × D₂ = {(2,1), (2,3), (2,5), (4,1), (4,3), (4,5)}
• A relation (R) is any subset of this Cartesian product. For example:
R = {(2,1), (4,1)}

Relations can also be defined based on conditions. For example:

• If y = 1, then R = {(x, y) | x ∈ D₁, y ∈ D₂, and y = 1}

• If x = 2y, then S = {(x, y) | x ∈ D₁, y ∈ D₂, and x = 2y}, which gives S = {(2,1)}

This concept can be extended to three or more sets. The Cartesian product of three sets D₁, D₂,
and D₃ is the set of all ordered triples (x, y, z), and any subset of this product forms a relation.

For example, if:

• D₁ = {1, 3}, D₂ = {2, 4}, and D₃ = {5, 6}, then the Cartesian product is:
D₁ × D₂ × D₃ = {(1,2,5), (1,2,6), (1,4,5), (1,4,6), (3,2,5), (3,2,6), (3,4,5), (3,4,6)}
• Any subset of these ordered triples is a relation.

Database Relations

In database systems, a relation schema defines a named relation as a set of attribute and
domain name pairs.

1. Relation Schema

A relation schema specifies attributes and their associated domains. If A₁, A₂, ..., Aₙ are attributes
with domains D₁, D₂, ..., Dₙ, then a relation schema is:
{A1:D1,A2:D2,...,An:Dn}\{A_1:D_1, A_2:D_2, ..., A_n:D_n\}{A1:D1,A2:D2,...,An:Dn}

A relation (R) based on this schema is a set of n-tuples, where each element consists of an
attribute and a value from its corresponding domain:

(A1:d1,A2:d2,...,An:dn)such thatd1∈D1,d2∈D2,...,dn∈Dn(A_1:d_1, A_2:d_2, ..., A_n:d_n)

\quad \text{such that} \quad d_1 \in D_1, d_2 \in D_2, ..., d_n \in D_n(A1:d1,A2:d2,...,An:dn
)such thatd1∈D1,d2∈D2,...,dn∈Dn

2. Representation as a Table

• Each attribute corresponds to a column in a table.

• Each n-tuple (set of values) is a row in the table.
• The table is a physical representation of the relation.

Example: Branch Relation

• Attributes: branchNo, street, city, postcode

• One possible tuple:

{(branchNo:B005,street:22DeerRd,city:London,postcode:SW14EH)}\{(branchNo: B005,
street: 22 Deer Rd, city: London, postcode: SW1
4EH)\}{(branchNo:B005,street:22DeerRd,city:London,postcode:SW14EH)}

• The Branch table contains multiple such four-tuples, representing different branches.

3. Relational Database Schema

A relational database schema consists of multiple relation schemas, each uniquely named. If
R₁, R₂, ..., Rₙ are relation schemas, the database schema R is:

R={R1,R2,...,Rn}R = \{R_1, R_2, ..., R_n\}R={R1,R2,...,Rn}

Properties of Relations in a Relational Database

A relation in a relational database has the following fundamental properties:

1. Unique Relation Name

• Each relation must have a distinct name within the database schema to avoid confusion.

2. Atomicity of Values

• Each cell (intersection of a row and column) contains exactly one atomic (single) value.
• No multiple values or repeating groups in a single cell.
• Relations that satisfy this property are in First Normal Form (1NF).
3. Distinct Attribute Names

• Every attribute (column name) must be unique within a relation.

4. Consistent Attribute Domains

• All values in a column must come from the same domain (e.g., branchNo values must be
valid branch numbers).
• A postcode value cannot appear in the branchNo column.

5. Uniqueness of Tuples

• Each tuple (row) in a relation must be unique—there are no duplicate rows.

6. Insignificance of Attribute Order

• The order of attributes (columns) does not affect the meaning of the relation.
• The relation remains the same even if we rearrange the columns, as long as attribute
names stay with their values.

7. Insignificance of Tuple Order

• The order of tuples (rows) does not matter in theory.

• In practice, database systems may arrange tuples for performance optimization, but the
logical structure remains unchanged.

Mathematical Justification

Many of these properties are derived from mathematical relations:

• Atomic values: Similar to elements in a set, each cell contains a single value.
• Attribute domain enforcement: Values must come from predefined sets (domains).
• No duplicate tuples: Like a set, where elements do not repeat.
• Tuple order irrelevance: In a set, order does not matter, so rows can be in any order.
• Attribute order irrelevance: Unlike mathematical relations where order matters,
relational databases define attributes by column names, making order irrelevant

• The relational schema defines the structure of the relations (tables) in the database,
including the attributes and primary keys.

• The conceptual schema is a set of these relation schemas, which represent the entire logical
view of the database
Key Types

1. Superkey: Any attribute set that uniquely identifies a tuple (may contain extra attributes).
2. Candidate Key: A minimal superkey (cannot have any redundant attributes).
3. Primary Key: The candidate key selected to identify tuples uniquely.
4. Foreign Key: An attribute in one relation that points to the primary key of another
relation, establishing a link

integrity constraints ensure data accuracy and consistency in a relational database. These include:

1. Nulls: Represent the absence of a value, used for incomplete or unknown data. Nulls
differ from zero or empty strings.
2. Entity Integrity: Ensures that no part of a primary key can be null, as it uniquely
identifies each tuple. For example, a branchNo in the Branch relation cannot be null.
3. Referential Integrity: Ensures that foreign keys either match a primary key in another
table or are null. For instance, branchNo in the Staff relation must exist in the Branch
relation or be null.
4. General Constraints: User-defined rules that enforce business logic, like limiting the
number of staff at a branch.

Terminology

1. Base Relation: A named relation corresponding to an entity in the conceptual schema,

with tuples physically stored in the database.
2. View: A virtual, dynamic relation derived from one or more base relations via relational
operations. It does not necessarily exist in storage but can be produced on request. Any
operations on a view are translated into operations on the base relations, and changes to
base relations are reflected in the view.

Purpose of Views

• Security: Views hide parts of the database from certain users, ensuring data access is
restricted.
• Customization: Different users can see the same data in different ways, tailored to their
needs.
• Simplification: Views can simplify complex operations, like joins, into more
straightforward queries for users.
• Logical Data Independence: Changes to the database schema (like adding new
attributes) do not affect users' views, preserving their familiar interface.
Examples:

• A view can combine Branch and Staff to show managers' names.

• A view can hide sensitive information, like salaries, from some staff.

Updating Views

• Updates to base relations are reflected in all views.

• Restrictions on updates through views include:
o Updates are allowed if the view is based on a single base relation with a primary
or candidate key.
o Updates are not allowed through views based on multiple base relations or
involving aggregation/grouping operations.

Thank you so much yehan se parhne ke lie

insha allah hum sab zarooor pass honge