ORDBMS
Object-Relational Data Models (ORDMs) in a DBMS offer a bridge between
relational database functionality and object-oriented programming concepts,
supporting advanced features like user-defined types and inheritance.
Key Features of Object-Relational Data Models
ORDMs extend the standard relational model to manage more complex data
types and relationships. Key features include:
Complex Data Types: ORDMs allow columns to contain complex structures,
such as nested records, arrays, and other composite types, providing a richer
way to represent real-world entities [1].
Object Identity (OID): Every object (row) within the database has a unique,
system-generated identifier, independent of its physical location or attribute
values. This OID allows objects to reference each other directly, facilitating
complex relationships and data retrieval [1, 2].
Encapsulation: Similar to object-oriented programming, data and the
methods (functions/procedures) that operate on that data can be bound
together into a single unit. This promotes data integrity and modularity [1].
Object-Oriented Query Language: ORDMs often support enhanced query
languages (like object-oriented SQL, or SQL:1999/SQL:2003 standards) that
can navigate complex object relationships and invoke methods directly within
queries [1, 2].
Late Binding: The specific implementation of a method to be executed can
be determined at runtime rather than compile time, enabling polymorphism
(see below) [2].
User-Defined Types (UDTs)
UDTs (also known as abstract data types or ADTs) are a cornerstone of the
ORDM, enabling developers to create custom data types that better model
application domains [1].
Definition: Users can define new data types beyond the built-in ones (like
integer, string, date). These custom types can include both data structures
(attributes) and associated behaviors (methods/functions) [1, 2].
Functionality: For example, a user could define a Point type with X and Y
coordinates, and associated functions like distance() or move() . This allows the
database to store and operate on application-specific logic directly [1].
Reusability: Once defined, UDTs can be used as column types in multiple
tables, promoting consistency and reducing data redundancy [2].
Inheritance
Inheritance is another crucial ORDM feature that models "is-a" relationships
between entities, organizing data in a hierarchical manner [2].
Structure: Inheritance allows a subtype (child) to inherit the attributes and
methods of a supertype (parent). The subtype can also have its own unique
attributes and methods, or override the parent's methods [2].
Polymorphism: This feature allows objects of different types to be treated as
objects of a common supertype. A single query or function call can potentially
operate on data across the entire hierarchy [2].
Querying: The database engine can automatically manage the hierarchy,
allowing queries on the supertype to retrieve relevant data from all inheriting
subtypes efficiently [2
OODBMS
oodbms Objects, encapsulation, persistence, OODBMS architecture
An
Object-Oriented Database Management System (OODBMS) integrates
database capabilities with object-oriented programming language (OOPL)
features, allowing data to be stored and managed as objects.
1. Objects
In an OODBMS, the fundamental unit of data is the object, which represents
a real-world entity.
State and Behaviour: Unlike relational entities that only have state (data),
objects contain both state (attributes) and behaviour (methods/operations).
Object Identity (OID): Every object has a unique, system-generated, and
invariant identifier (OID) that is independent of its attribute values.
Complex Objects: OODBMS natively supports complex data structures like
sets, lists, and nested objects without needing to "flatten" them into tables.
2. Encapsulation
Encapsulation is the mechanism of bundling data and the methods that
operate on that data into a single unit.
Information Hiding: It hides the internal implementation details of an object
from the outside world, exposing only a public interface.
Data Integrity: By restricting direct access to data, encapsulation ensures
that object states can only be modified through predefined methods,
maintaining consistency.
3. Persistence
Persistence refers to the ability of an object to exist beyond the execution of
the program that created it.
Transient vs. Persistent: Objects in standard OOPLs are typically transient
(lost when the program ends). An OODBMS makes these
objects persistent by saving them to secondary storage.
Persistence by Reachability: Often, objects become persistent automatically
if they are referenced (reachable) by another persistent object.
4. OODBMS Architecture
The architecture of an OODBMS is designed to provide seamless integration
between the database and the programming environment.
Core Layers: A common model includes six
layers: Interaction, Application, Administration, Security, Paging,
and Virtual layers.
Persistent Programming Languages: The architecture often extends a
language like C++, Java, or Smalltalk with database capabilities
(e.g., GemStone for Smalltalk).
Object Store & Manager: The architecture includes an Object Store for
physical storage and a Persistence Manager to maintain object states
between sessions.
Query Engine: Supports specialized languages like Object Query Language
(OQL) to retrieve data as objects rather than rows.
Data Models in DBMS
A Data Model in Database Management System (DBMS) is the concept of
tools that are developed to summarize the description of the
database. Data Models provide us with a transparent picture of data
which helps us in creating an actual database. It shows us from the design
of the data to its proper implementation of data.
Types of Relational Models
1. Conceptual Data Model
2. Representational Data Model
3. Physical Data Model
It is basically classified into 3 types:-
Data Models
1. Conceptual Data Model
The conceptual data model describes the database at a very high level
and is useful to understand the needs or requirements of the database. It
is this model, that is used in the requirement-gathering process i.e. before
the Database Designers start making a particular database. One such
popular model is the entity/relationship model (ER model). The E/R model
specializes in entities, relationships, and even attributes that are used by
database designers. In terms of this concept, a discussion can be made
even with non-computer science(non-technical) users and stakeholders,
and their requirements can be understood.
Entity-Relationship Model( ER Model): It is a high-level data model which
is used to define the data and the relationships between them. It is
basically a conceptual design of any database which is easy to design the
view of data.
Components of ER Model:
1. Entity: An entity is referred to as a real-world object. It can be a name,
place, object, class, etc. These are represented by a rectangle in an ER
Diagram.
2. Attributes: An attribute can be defined as the description of the entity.
These are represented by Ellipse in an ER Diagram. It can be Age, Roll
Number, or Marks for a Student.
3. Relationship: Relationships are used to define relations among
different entities. Diamonds and Rhombus are used to show
Relationships.
Characteristics of a conceptual data model
Offers Organization-wide coverage of the business concepts.
This type of Data Models are designed and developed for a business
audience.
The conceptual model is developed independently of hardware
specifications like data storage capacity, location or software
specifications like DBMS vendor and technology. The focus is to
represent data as a user will see it in the “real world.”
Conceptual data models known as Domain models create a common
vocabulary for all stakeholders by establishing basic concepts and scope
2. Representational Data Model
This type of data model is used to represent only the logical part of the
database and does not represent the physical structure of the database.
The representational data model allows us to focus primarily, on the
design part of the database. A popular representational model is
a Relational model. The relational Model consists of Relational
Algebra and Relational Calculus. In the Relational Model, we basically use
tables to represent our data and the relationships between them. It is a
theoretical concept whose practical implementation is done in Physical
Data Model.
The advantage of using a Representational data model is to provide a
foundation to form the base for the Physical model.
Characteristics of Representational Data Model
Represents the logical structure of the database.
Relational models like Relational Algebra and Relational Calculus are
commonly used.
Uses tables to represent data and relationships.
Provides a foundation for building the physical data model.
3. Physical Data Model
The physical Data Model is used to practically implement Relational Data
Model. Ultimately, all data in a database is stored physically on a
secondary storage device such as discs and tapes. This is stored in the
form of files, records, and certain other data structures. It has all the
information on the format in which the files are present and the structure
of the databases, the presence of external data structures, and their
relation to each other. Here, we basically save tables in memory so they
can be accessed efficiently. In order to come up with a good physical
model, we have to work on the relational model in a better
way. Structured Query Language (SQL) is used to practically implement
Relational Algebra.
This Data Model describes HOW the system will be implemented using a
specific DBMS system. This model is typically created by DBA and
developers. The purpose is actual implementation of the database.
Characteristics of a physical data model:
The physical data model describes data need for a single project or
application though it maybe integrated with other physical data
models based on project scope.
Data Model contains relationships between tables that which
addresses cardinality and nullability of the relationships.
Developed for a specific version of a DBMS, location, data storage or
technology to be used in the project.
Columns should have exact datatypes, lengths assigned and default
values.
Primary and Foreign keys, views, indexes, access profiles, and
authorizations, etc. are defined
Some Other Data Models
1. Hierarchical Model
The hierarchical Model is one of the oldest models in the data model
which was developed by IBM, in the 1950s. In a hierarchical model, data
are viewed as a collection of tables, or we can say segments that form a
hierarchical relation. In this, the data is organized into a tree-like
structure where each record consists of one parent record and many
children. Even if the segments are connected as a chain-like structure by
logical associations, then the instant structure can be a fan structure with
multiple branches. We call the illogical associations as directional
associations.
2. Network Model
The Network Model was formalized by the Database Task group in the
1960s. This model is the generalization of the hierarchical model. This
model can consist of multiple parent segments and these segments are
grouped as levels but there exists a logical association between the
segments belonging to any level. Mostly, there exists a many-to-many
logical association between any of the two segments.
3. Object-Oriented Data Model
In the Object-Oriented Data Model, data and their relationships are
contained in a single structure which is referred to as an object in this
data model. In this, real-world problems are represented as objects with
different attributes. All objects have multiple relationships between them.
Basically, it is a combination of Object Oriented programming and a
Relational Database Model.
4. Float Data Model
The float data model basically consists of a two-dimensional array of data
models that do not contain any duplicate elements in the array. This data
model has one drawback it cannot store a large amount of data that is the
tables can not be of large size.
5. Context Data Model
The Context data model is simply a data model which consists of more
than one data model. For example, the Context data model consists of ER
Model, Object-Oriented Data Model, etc. This model allows users to do
more than one thing which each individual data model can do.
6. Semi-Structured Data Model
Semi-Structured data models deal with the data in a flexible way. Some
entities may have extra attributes and some entities may have some
missing attributes. Basically, you can represent data here in a flexible way.
Advantages of Data Models
1. Data Models help us in representing data accurately.
2. It helps us in finding the missing data and also in minimizing Data
Redundancy.
3. Data Model provides data security in a better way.
4. The data model should be detailed enough to be used for building the
physical database.
5. The information in the data model can be used for defining the
relationship between tables, primary and foreign keys, and stored
procedures.
Disadvantages of Data Models
1. In the case of a vast database, sometimes it becomes difficult to
understand the data model.
2. You must have the proper knowledge of SQL to use physical models.
3. Even smaller change made in structure require modification in the
entire application.
4. There is no set data manipulation language in DBMS.
5. To develop Data model one should know physical data stored
characteristics.