mod8

Object-Oriented and Object-Relational

Databases
Object-Oriented Databases (OODBMS)
The Object-Oriented Database Management System (OODBMS) emerged from the need
to handle more complex, interrelated data than traditional relational databases could
comfortably represent. As modern applications began demanding the storage of structured,
hierarchical, and often multimedia data—such as in CAD/CAM, simulation systems, or
multimedia applications—it became increasingly difficult to model such data using
traditional flat relational tables.

Core Philosophy
An OODBMS adopts the principles of object-oriented programming—specifically, the
encapsulation of state and behavior within objects—and brings them into the realm of
persistent storage. That is, objects created in an OOP language can be stored and retrieved
directly from the database, maintaining their identity, structure, and behavior.
Objects are instances of classes, and classes define both the data (attributes) and the
methods (operations) that can be performed on the data. In an OODBMS, these objects are
not transient—meaning they do not cease to exist once the application terminates. Rather,
the system manages their persistence, supporting operations such as object creation,
deletion, updates, and queries.

Characteristics
1. Object Identity: Unlike relational databases where identity is based on primary key
values, OODBMS supports intrinsic object identity. Every object has a unique object
identifier (OID) that remains constant throughout its lifetime.

2. Encapsulation: Objects encapsulate both data and behavior. Access to object state is
ideally only via defined methods.

3. Complex Objects: The system can manage arbitrarily complex data structures,
including sets, lists, nested records, and user-defined types.

4. Inheritance: OODBMS supports both single and multiple inheritance. This allows
classes to inherit properties and behaviors from other classes, encouraging reuse and
polymorphism.

mod8 1
 5. Persistence: Objects can be made persistent without requiring conversion to tables or
flat files. This aligns well with applications built in OOP languages.

6. Programming Language Integration: Many OODBMSs are tightly coupled with object-
oriented programming languages (e.g., C++, Java), reducing the impedance mismatch
between the programming model and the data model.

Limitations and Challenges

Despite their theoretical strength, OODBMSs faced practical challenges. Query optimization
was difficult due to the lack of a declarative query language as expressive and
standardized as SQL. Indexing complex objects also proved challenging. Moreover, industry
adoption remained limited due to lack of standardization and the strong dominance of the
relational model in enterprise environments.

Object-Relational Databases (ORDBMS)

The Object-Relational Database Management System (ORDBMS) represents an
evolutionary step aimed at bridging the gap between the relational model and the object-
oriented paradigm, combining the best of both worlds. While OODBMS rethinks storage
from an object-centric perspective, ORDBMS maintains the foundational relational
structure but enhances it to support object-like features.

Conceptual Foundation
In an ORDBMS, data is still represented in terms of tables (relations), but these tables can
now contain complex data types, user-defined types (UDTs), and inheritance structures.
Rather than breaking complex objects down into multiple flat tables, ORDBMS allows these
objects to be represented more natively, while still supporting SQL-based operations.

This system retains the declarative querying power of SQL, and incorporates object-
oriented modeling constructs such as encapsulation, polymorphism, and extensibility into
the relational framework.

Key Features
1. Extended Type System: ORDBMS introduces abstract data types (ADTs) or user-
defined types (UDTs) that can encapsulate structure and behavior. These are more
expressive than primitive data types.

2. Inheritance and Polymorphism: Tables (or types) can inherit from one another. This
allows for schema evolution and reuse. Queries on parent types can automatically
include data from all subtypes.

mod8 2
 3. Encapsulated Methods: Methods can be defined alongside UDTs. These methods are
typically written in external languages (e.g., PL/SQL, Java, C) and can be invoked from
within SQL.

4. Complex Structures: ORDBMS supports arrays, sets, nested tables, and even
multimedia objects (images, audio, video) as columns in a relational schema.

5. Enhanced Query Capabilities: SQL in ORDBMS is extended to operate on these

complex types. For instance, dot notation ( object.attribute ) or method invocations can be
part of a SQL query.

6. Backward Compatibility: An ORDBMS is backward compatible with standard RDBMS

usage. That is, existing relational tables and queries continue to function normally.

Conclusion
Object-Oriented and Object-Relational databases address the limitations of the flat
relational model in different ways. OODBMS is more aligned with pure object-oriented
applications, while ORDBMS extends the relational paradigm with object-oriented
capabilities to support more complex data modeling without abandoning SQL. Both have
their place in database history, but ORDBMS has found broader commercial acceptance
due to its backward compatibility, extensibility, and standardization.

Logical Databases – A Detailed Explanation

1. Introduction
In database systems, the term "logical database" refers to the logical view or schema-
level representation of a database. It focuses on the structure, organization, and
relationships of data from the user's or application’s perspective—without concern for how
the data is physically stored on disk.

A logical database defines what data is stored and how it is related, while remaining
independent of storage mechanisms, access paths, and indexing methods.

2. Position in the Three-Level Architecture

Logical databases are best understood within the context of the ANSI/SPARC three-
schema architecture, which includes:

1. External Schema (View Level) – User-specific views

2. Logical Schema (Conceptual Level) – Logical database

mod8 3
 3. Internal Schema (Physical Level) – Storage structures

The logical schema (or logical database) exists at the middle level, providing a unified and
abstract description of the entire database, which is independent of physical storage and
specific application requirements.

3. Characteristics of Logical Databases

1. Data Abstraction
Logical databases offer data independence, abstracting the application from physical
storage details. This means changes in the storage format or indexing techniques do not
affect the logical view.

2. Schema Definition
A logical database includes:

Entity and attribute definitions

Data types

Keys (primary, foreign)

Integrity constraints (e.g., NOT NULL, UNIQUE)

Relationships among entities (1:N, M:N)

3. Relational or Object Models

Logical databases are often expressed using relational models (tables, tuples, attributes),
but can also represent object-oriented models depending on the DBMS.

4. Independence from Storage Details

Logical databases do not deal with file formats, block sizes, buffer management, or
physical address pointers.

5. Support for Multiple External Views

A single logical schema can support multiple external schemas (views) tailored for
different users or applications, without redundancy.

4. Logical vs Physical Database

Aspect Logical Database Physical Database

mod8 4
 Level Conceptual level (middle) Internal level (lowest)

Focus Data structure and relationships Data storage and access

Concerned With Tables, keys, constraints File organization, indexing, memory

Changes Impact Transparent to users/applications Requires DBA intervention

Describes What data is stored How data is stored

5. Logical Data Modeling

Logical databases are typically designed using logical data models, which act as blueprints
for the data structure. The Entity-Relationship (E-R) model is the most common modeling
tool used at this level. Once the ER model is complete, it is translated into relational
schema (tables with primary and foreign keys).

Example:
An E-R diagram may define:

Entities: Student, Course

Attributes: Student_ID, Name, Course_Code

Relationships: Enrolls (between Student and Course)

This would be translated into a relational schema like:

STUDENT(Student_ID, Name, Department)

COURSE(Course_Code, Title, Credits)
ENROLLMENT(Student_ID, Course_Code, Semester)

This schema represents the logical database — it defines the data and its structure, but not
how it is stored or accessed.

6. Importance of Logical Databases

1. Data Independence
Applications can function regardless of changes in storage mechanisms, promoting
modularity and maintainability.

2. Portability
The same logical schema can be mapped to different physical architectures or storage
systems.

mod8 5
 3. Centralized Design
Acts as a unified blueprint for managing data across different applications and user
interfaces.

4. Efficient Query Planning

The query optimizer uses the logical schema to generate execution plans before translating
them into physical access paths.

7. Role in DBMS Design and Development

During database development, logical design follows conceptual modeling and
precedes physical design.

Logical design is DBMS-independent and focuses on business rules, data flow, and
structural constraints.

A well-structured logical database design simplifies application development and

improves system reliability.

8. Real-World Relevance
Logical databases are widely used in:

Database design tools (e.g., ER/Studio, Oracle Designer)

Data warehouses, where logical schemas are mapped to star/snowflake physical

schemas

Application frameworks that generate database access layers from logical models

9. Limitations
Logical databases do not account for performance optimization — those concerns are
addressed during physical schema design.

In some cases, logical abstraction may hide important hardware constraints that affect
design decisions (e.g., storage size limits, disk layout).

Conclusion
A logical database is a crucial abstraction layer in DBMS that defines the structure,
constraints, and relationships of data independently of how data is physically stored. It
provides the foundation for data independence, system modularity, and application-

mod8 6
 agnostic database access. Mastery of logical schema design is essential for any database
designer or architect aiming for scalable and maintainable systems.

Web Databases – A Detailed Explanation

1. Introduction
With the advent of the internet and the growth of web applications, traditional database
systems evolved to support online, interactive, and remote access to data. A web database
refers to a database that is designed to be accessed and managed through the web, often
in conjunction with dynamic websites and internet-based applications.

Web databases are integral to modern computing ecosystems, powering online banking,
social media platforms, e-commerce systems, content management systems, and virtually
all interactive websites.

2. Definition
A Web Database is a database system that is accessible over the internet or an intranet
through web technologies such as HTTP, server-side scripting languages (like PHP, Python,
Node.js), and client-server communication protocols.

It typically works behind the scenes of dynamic websites, handling data retrieval,
manipulation, and storage operations requested via web interfaces.

3. Architecture of Web Databases

Web databases operate within a multi-tier architecture, usually based on the three-tier
model:

1. Client Tier (Presentation Layer)

The user interface typically rendered in a web browser.

Built using HTML, CSS, JavaScript, etc.

Communicates with the web server via HTTP or asynchronous technologies like AJAX.

2. Middle Tier (Application Layer)

Acts as a bridge between the client and the database.

Implements business logic and handles data processing.

mod8 7
 Uses server-side technologies such as PHP, Django (Python), Express (Node.js),
ASP.NET, Java Servlets, etc.

3. Database Tier (Data Layer)

Stores and manages application data.

Typically powered by RDBMS (like MySQL, PostgreSQL, Oracle) or NoSQL databases

(like MongoDB, Firebase).

Interacts with the application tier via SQL or database APIs.

This layered architecture promotes modularity, scalability, and separation of concerns.

4. Characteristics of Web Databases

Remotely Accessible: Users can access the database through a web browser, mobile
app, or API from any geographical location.

Concurrent Multi-user Support: Can handle simultaneous access from thousands or

millions of users.

Platform Independent: Accessible from various devices and operating systems using
standard internet protocols.

Dynamic Content Delivery: Supports real-time content generation based on database

queries.

Security Measures: Must implement robust access control, authentication, and

protection against threats like SQL injection and cross-site scripting (XSS).

5. Technologies Used in Web Databases

Component Technologies

Frontend (Client) HTML, CSS, JavaScript, AJAX

Backend (Server) PHP, Python (Django/Flask), Node.js, Java (Spring), .NET

Database MySQL, PostgreSQL, MongoDB, SQLite, Firebase

APIs RESTful APIs, GraphQL, WebSockets

Hosting Apache, Nginx, IIS, cloud platforms (AWS, Azure, Heroku)

These technologies work in tandem to enable seamless communication between the user
and the database.

mod8 8
 6. Use Cases and Applications
E-commerce Websites (e.g., Amazon): To manage product catalogs, orders, users,
payments

Social Media Platforms (e.g., Facebook): To handle profiles, posts, interactions, and
feeds

Online Banking Systems: Securely store and manage financial transactions and
customer data

Educational Platforms (e.g., Moodle): Store student information, course materials,

grades

Government Portals: Deliver public services and information dynamically

Content Management Systems (e.g., WordPress): Power blogs and websites with
dynamic content

7. Advantages of Web Databases

1. Ubiquitous Access: Available from any internet-connected device, increasing reach
and flexibility.

2. Real-Time Data Interaction: Immediate data retrieval and updates.

3. Cost Efficiency: No need for specialized client software; browsers act as universal
frontends.

4. Scalability: Can be scaled vertically and horizontally to handle growing user bases.

5. Ease of Integration: Can be connected with third-party APIs, payment gateways, social
login systems, etc.

8. Challenges and Limitations

1. Security Risks: Prone to attacks such as SQL injection, CSRF, session hijacking.

2. Concurrency Management: Must handle race conditions and maintain ACID properties
under load.

3. Latency: Dependent on internet bandwidth; high latency can degrade user experience.

4. Complex Configuration: Requires proper backend configuration, load balancing, and

performance tuning.

5. Downtime Risk: Server or network failures can make the application inaccessible.

mod8 9
 9. Example Scenario
Consider a web-based learning management system (LMS):

A student logs in using a browser.

The client sends credentials to the server (application tier).

The server queries the user table in the database.

Upon successful authentication, the student’s dashboard is rendered with data from
multiple tables: courses, assignments, notifications.

Every interaction (submitting assignments, posting to forums, updating profile) triggers

further interactions with the web database.

10. Web Database vs Traditional Database

Aspect Web Database Traditional Database

Access Mode Via browser/web interface Typically via desktop apps or command line

Deployment Over the internet Local or private network

Interaction Style Client-server Often standalone or LAN-based

Scalability High Limited

Example Online portals, websites Standalone apps, offline systems

Conclusion
Web databases have become the backbone of modern, data-driven web applications. By
enabling persistent, dynamic interaction between users and content via browsers, they
revolutionize how data is stored, accessed, and manipulated. As web technologies evolve,
web databases continue to be central to digital communication, commerce, education,
governance, and virtually all aspects of online life. Their power lies in their ability to
combine the structure and robustness of traditional databases with the interactivity and
accessibility of the web.

Distributed Databases – A Detailed Explanation

1. Introduction
As data volume and application complexity have grown, centralized database systems
began facing limitations in scalability, fault tolerance, and access speed. To overcome

mod8 10
 these limitations, database systems evolved into distributed database systems, which
distribute data across multiple physical sites but maintain logical consistency and unified
access.
A Distributed Database (DDB) is a type of database system in which data is logically
related but physically stored at multiple locations, often connected via a network. These
locations could be on different servers, within different geographical regions, or even
spread across cloud environments.

2. Definition
A Distributed Database System (DDBS) is a collection of multiple, logically interrelated
databases distributed over a computer network, where each site is capable of processing
part of the database independently. Despite the distribution, the system appears as a
single unified database to the user.

3. Architecture of Distributed Databases

3.1 Client-Server Architecture
The client sends requests for data.

The server(s) store and manage the distributed data and respond with the requested
results.

3.2 Peer-to-Peer Architecture

All nodes act as both clients and servers.

Data and control are decentralized.

3.3 Multilevel Architecture

Combines centralized and decentralized elements.

Local sites manage their own data and participate in global transactions coordinated by
a central site.

4. Types of Distributed Databases

1. Homogeneous Distributed Database
All sites use the same DBMS software.

Uniform data models and query languages (e.g., all use PostgreSQL).

mod8 11
 Easier to manage and integrate.

2. Heterogeneous Distributed Database

Sites may use different DBMS software or data models.

Greater flexibility but adds complexity in translation, query processing, and integration.

5. Data Distribution Strategies

1. Fragmentation
The database is divided into fragments (subsets of data), and each fragment is stored
at a different site.

Horizontal Fragmentation: Rows are distributed (e.g., customers in different

countries).

Vertical Fragmentation: Columns are distributed (e.g., separating personal info and
financial info).

Mixed Fragmentation: Combination of both.

2. Replication
Copies of the same data are stored at multiple sites.

Full replication: Entire database is copied at each site.

Partial replication: Only frequently accessed data is copied.

Improves availability and reliability, but adds synchronization overhead.

3. Allocation
Decides where to place data or fragments — based on access patterns, costs, and
constraints.

6. Key Features
1. Location Transparency

Users can query data without knowing the physical location of data.

2. Replication Transparency

The system hides the fact that data is replicated across sites.

3. Fragmentation Transparency

mod8 12
 Users are unaware of how data is divided or fragmented.

4. Concurrency Control

Mechanisms to ensure consistent concurrent access across multiple sites.

5. Fault Tolerance

System can continue functioning even if one or more sites fail.

6. Distributed Query Processing

Queries can involve data from multiple sites and must be optimized accordingly.

7. Autonomy

Local databases may operate independently or be loosely coupled to the global

schema.

7. Distributed Transactions
A distributed transaction is one that accesses or modifies data at multiple sites. It must
satisfy the ACID properties:

Atomicity: All parts of the transaction must complete or none at all.

Consistency: Must leave the system in a valid state.

Isolation: Concurrent transactions should not interfere.

Durability: Once committed, the changes must persist.

To achieve this, protocols like Two-Phase Commit (2PC) are used.

Two-Phase Commit Protocol:

1. Phase 1 (Prepare): Coordinator sends prepare requests to all participants.

2. Phase 2 (Commit/Abort): If all respond with "ready", it sends commit; else, it sends
abort.

8. Advantages of Distributed Databases

1. Improved Reliability and Availability

System continues operating even if one or more nodes fail.

Data replication supports disaster recovery.

2. Scalability

mod8 13
 Easily scale out by adding new nodes and redistributing data.

3. Local Autonomy

Sites can operate independently, improving modularity.

4. Faster Access

Users can access data stored at nearby sites, reducing response time.

5. Reduced Network Traffic

Local processing reduces the need to transfer large amounts of data across the
network.

9. Disadvantages and Challenges

1. Complexity

Managing multiple sites, synchronizing data, and ensuring consistency is complex.

2. Distributed Query Optimization

Query planning must account for network latency, data location, and fragmentation.

3. Data Security

Ensuring secure access and transmission across sites requires advanced

techniques.

4. Concurrency Control

Coordinating access to shared data in real-time across sites is difficult.

5. Higher Maintenance Cost

Requires skilled administration and configuration.

10. Real-World Applications

Banking Systems: Branches in different locations manage customer accounts but rely
on centralized consistency.

Telecom Networks: Call records and user data stored across regional servers.

E-commerce: Data centers in multiple regions store product and customer data close to
the users.

Cloud Databases: Systems like Google Spanner or Amazon Aurora replicate and
partition data across multiple zones.

mod8 14
 Conclusion
A Distributed Database offers a robust, scalable, and fault-tolerant alternative to
centralized systems, especially for modern applications that demand global access, high
availability, and low latency. While it introduces complexity in terms of query processing,
concurrency, and system management, it significantly enhances the performance,
modularity, and flexibility of enterprise-scale database systems. Mastery of distributed
database concepts is essential for building resilient, large-scale information systems in
today’s interconnected digital world.

1. Data Warehousing – A Detailed Explanation

1.1 Introduction
In large organizations, data is typically scattered across various operational systems, often
stored in inconsistent formats, and updated in real-time. While such systems are optimized
for transactional processing (OLTP), they are not suitable for analytical tasks such as trend
analysis, forecasting, or decision support.

To address this, the concept of a Data Warehouse was developed. A Data Warehouse is a
centralized repository that stores integrated, subject-oriented, time-variant, and non-
volatile data from multiple sources, optimized for querying and analysis rather than
transaction processing.

1.2 Definition
A Data Warehouse is a large, centralized system that collects data from various
heterogeneous sources, transforms it into a consistent format, and stores it for analytical
querying and decision-making. It acts as the foundation of business intelligence (BI)
systems.

1.3 Characteristics of Data Warehousing

1. Subject-Oriented
Organized around major subjects such as sales, inventory, customers, etc., rather than
application functions.

2. Integrated

mod8 15
 Consolidates data from multiple sources (e.g., relational databases, flat files, legacy
systems), resolving naming conflicts and data format inconsistencies.

3. Time-Variant
Maintains historical data to support trend analysis and forecasting. Each record is time-
stamped or associated with a period.

4. Non-Volatile
Once data is loaded into the warehouse, it is not updated or deleted through typical
transactional operations. It is read-only for analysis purposes.

1.4 Data Warehouse Architecture

1. Data Sources
Operational databases, ERP systems, external data, flat files, etc.

2. ETL Process (Extract, Transform, Load)

Extract: Data is pulled from multiple source systems.

Transform: Data is cleaned, integrated, and converted to a common format.

Load: Transformed data is loaded into the warehouse.

3. Data Storage
Centralized data warehouse or data marts (smaller, department-specific warehouses).

Commonly structured using star schema, snowflake schema, or galaxy schema.

4. Metadata Repository
Stores information about the data such as its origin, transformations, and structure.

5. Query and Reporting Tools

OLAP tools, dashboards, visualization platforms (e.g., Tableau, Power BI).

1.5 Benefits of Data Warehousing

Supports strategic decision-making

Enables multi-dimensional analysis using OLAP

mod8 16
 Improves data quality through integration and cleaning

Facilitates historical trend analysis

Provides a single version of the truth across the organization

1.6 Challenges
High cost of setup and maintenance

Complex ETL process

Requires data governance and quality control

May become obsolete if not updated with business changes

2. Data Mining – A Detailed Explanation

2.1 Introduction
Once the data is collected, cleaned, and stored (often in a warehouse), the next step is to
extract useful patterns or knowledge from that data. This process is known as Data
Mining.
Data Mining is the computational process of discovering interesting, non-trivial,
previously unknown, and potentially useful patterns or knowledge from large datasets.
It forms a key component of Knowledge Discovery in Databases (KDD).

2.2 Definition
Data Mining is the process of automatically discovering patterns, trends, correlations, or
anomalies in large datasets using techniques from statistics, machine learning, and
database systems.

2.3 Goals of Data Mining

Prediction (e.g., predicting customer churn, stock prices)

Classification (e.g., spam detection, fraud detection)

Clustering (e.g., market segmentation)

Association Rule Mining (e.g., market basket analysis)

Anomaly Detection (e.g., identifying fraudulent transactions)

mod8 17
 2.4 Data Mining Process (Part of KDD)
1. Data Selection: Identify relevant data from the warehouse

2. Data Preprocessing: Clean and normalize the data

3. Transformation: Convert data into suitable format for mining (e.g., feature extraction)

4. Data Mining: Apply algorithms to extract patterns

5. Evaluation: Assess the discovered patterns for usefulness

6. Knowledge Presentation: Visualize and interpret the results

2.5 Techniques of Data Mining

1. Classification
Assigning items to predefined categories.

Algorithms: Decision Trees, Naive Bayes, Support Vector Machines.

2. Clustering
Grouping similar data without predefined labels.

Algorithms: K-Means, DBSCAN, Hierarchical Clustering.

3. Association Rule Mining

Discovering relationships among items.

Output: Rules like {Bread, Butter} → {Milk}

Algorithm: Apriori, FP-Growth

4. Regression
Predicting a continuous numeric value.

Algorithms: Linear Regression, Random Forest Regressors.

5. Anomaly Detection
Identifying data points that deviate significantly from the norm.

6. Sequential Pattern Mining

Discovering patterns where the order of events matters (e.g., user clickstreams).

mod8 18
 2.6 Applications of Data Mining
Marketing: Customer segmentation, recommendation engines

Finance: Credit scoring, fraud detection

Healthcare: Disease prediction, patient clustering

Telecom: Churn analysis

E-commerce: Product recommendation

Manufacturing: Defect detection and process optimization

2.7 Challenges in Data Mining

Data Quality: Incomplete or noisy data affects model accuracy

Scalability: Mining petabyte-scale datasets is computationally intensive

Privacy and Security: Sensitive information must be protected

Interpretability: Complex models (e.g., neural networks) are hard to explain

Bias and Fairness: Data mining systems may unintentionally reinforce societal biases

3. Relationship Between Data Warehousing and Data Mining

Aspect Data Warehousing Data Mining

Purpose Storage and organization of data Discovery of patterns and knowledge

Focus Integration, summarization Prediction, pattern recognition

Users Data analysts, BI developers Data scientists, analysts

Technology ETL, SQL, OLAP AI, ML, statistics

Output Structured, queryable datasets Rules, clusters, classifications, forecasts

In essence:

Data Warehousing prepares and organizes data

Data Mining extracts insights and patterns from that data

Conclusion
Data warehousing and data mining form two crucial pillars of modern data-driven decision-
making systems. A data warehouse enables the efficient collection, storage, and

mod8 19
 management of vast volumes of organizational data, while data mining leverages that
stored data to derive actionable insights, patterns, and predictions. Together, they support
strategic planning, operational efficiency, and a deeper understanding of business and user
behavior in nearly every sector.

mod8 20