0% found this document useful (0 votes)
24 views9 pages

Chapter 3 and 4 Database

Chapter 3 discusses various multi-user DBMS architectures, including teleprocessing, file-server, two-tier, three-tier, and n-tier architectures, highlighting their structures, advantages, and disadvantages. It also covers middleware types that facilitate communication between applications and databases. Chapter 4 introduces the relational data structure, detailing key concepts like relations, attributes, and integrity constraints essential for managing data in relational databases.

Uploaded by

Areesha Tahir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views9 pages

Chapter 3 and 4 Database

Chapter 3 discusses various multi-user DBMS architectures, including teleprocessing, file-server, two-tier, three-tier, and n-tier architectures, highlighting their structures, advantages, and disadvantages. It also covers middleware types that facilitate communication between applications and databases. Chapter 4 introduces the relational data structure, detailing key concepts like relations, attributes, and integrity constraints essential for managing data in relational databases.

Uploaded by

Areesha Tahir
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

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

You might also like