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

Relational Keys in a Database

In relational databases, keys are crucial for uniquely identifying tuples (rows) in relations
(tables). This section introduces the key concepts that are essential for ensuring that each tuple
can be uniquely identified and relationships between different relations can be established.

Superkey
 • Definition: A superkey is an attribute or a set of attributes that uniquely identifies each
tuple in a relation.
• A superkey may contain extra attributes that are not needed to uniquely identify a tuple.
• Example: In the Branch relation, a superkey could be a combination of branchNo and
postcode. However, if branchNo alone is sufficient to uniquely identify the branch, it
would be a candidate key (as explained below).

Candidate Key

• Definition: A candidate key is a superkey for which no proper subset is a superkey.

• It has two essential properties:
1. Uniqueness: The combination of values in the candidate key must uniquely
identify each tuple in the relation.
2. Irreducibility: No smaller subset of the candidate key can still uniquely identify
tuples.
• If a candidate key consists of more than one attribute, it is called a composite key.
• Example: In the Viewing relation, the combination of clientNo and propertyNo forms
a composite candidate key because no single attribute (like clientNo or propertyNo
alone) can uniquely identify a tuple, but the combination can.
• A candidate key must be selected based on semantic understanding of the real-world
entities represented by the data. For instance, surname (IName) could be mistakenly
considered a candidate key for the Staff relation, but multiple employees could share the
same surname, meaning it wouldn't be a valid key.

Primary Key

• Definition: The primary key is the candidate key that is selected to uniquely identify
tuples in a relation.
• A relation always has a primary key, and typically, it is a minimal set of attributes (often
just one attribute, but it can be a composite key).
• Example: For the Branch relation, if branchNo is selected as the primary key, it means
branchNo uniquely identifies each branch.
• Candidate keys that are not selected as the primary key are called alternate keys.

Foreign Key

• Definition: A foreign key is an attribute or set of attributes in one relation that refers to
the primary key of another relation. This establishes a relationship between the two
relations.
• The foreign key can be in the same relation (self-referencing) or in a different relation.
Foreign keys enable referential integrity, ensuring that a relationship between tables is
consistent.
• Example: In the Staff relation, branchNo is a foreign key. It refers to the primary key
branchNo in the Branch relation. This relationship links each staff member to their
branch office.
Integrity Constraints

Integrity constraints are rules that ensure the accuracy, consistency, and validity of data within a
relational database. These constraints help to maintain data integrity and ensure that the data
adheres to the business rules and logical structure of the database. The relational model includes
several types of integrity constraints, including domain constraints, entity integrity, referential
integrity, and general constraints.

Nulls in the Relational Model

Before diving into the main integrity constraints, it is important to understand the concept of
nulls in the relational model. Null represents a value for an attribute that is currently unknown,
not applicable, or not yet supplied.

• A null is different from a zero value or an empty string. Zero and spaces are actual
values, whereas a null indicates the absence of a value.
• Nulls are used to handle incomplete or exceptional data. For example, in the Viewing
relation, the comment attribute may be null until a renter submits a comment.

The use of nulls can complicate database operations because relational databases are traditionally
based on two-valued logic (true/false). Incorporating nulls means dealing with multi-valued
logic, which can create challenges in data manipulation and query processing.

4.3.2 Entity Integrity

Entity integrity is a rule that applies to primary keys in a database. It ensures that each tuple
(row) in a base relation can be uniquely identified by its primary key.

• Entity Integrity Rule: In a base relation, no attribute of a primary key can be null.
• A primary key is a minimal set of attributes that uniquely identifies each tuple in the
relation. If part of the primary key is null, it would violate the uniqueness requirement, as
it would suggest that not all attributes are necessary to distinguish between tuples.

Example:

• In the Branch relation, branchNo is the primary key. A tuple should not be allowed if the
branchNo attribute is null.
• In the Viewing relation, the composite primary key is made up of clientNo and
propertyNo. Both of these attributes must have non-null values to maintain entity
integrity.

4.3.3 Referential Integrity

Referential integrity is a rule that applies to foreign keys, ensuring that the relationship between
tables is valid and consistent.

• Referential Integrity Rule: If a foreign key exists in a relation, it must either match a
candidate key value in the referenced (home) relation or be null.
• A foreign key is an attribute in a relation that refers to the primary key of another (or the
same) relation. This ensures that the foreign key's value must exist in the referenced table
or be null if no relevant record is available.

Example:

• In the Staff relation, branchNo is a foreign key that references branchNo in the Branch
relation. If you attempt to add a staff record with a branchNo that does not exist in the
Branch relation, the database would reject this insertion.
• However, you can insert a staff record with a null branchNo if the staff member has not
yet been assigned to a branch.

General Constraints

General constraints are additional rules that are defined by users or database administrators to
enforce business logic or other constraints specific to the enterprise.

• General Constraints: These are user-defined rules that restrict data in ways beyond
entity and referential integrity. For example, constraints may specify limits on the number
of records, data ranges, or specific conditions that must be met for certain actions.

Example:

• If a business rule states that no more than 20 staff members can work at a single branch, a
general constraint could be applied to prevent the insertion of more staff records at a
branch if it already has 20 members.

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