Object Database Definition

An object database is managed by an object-oriented database management system (OODBMS). The

database combines object-oriented programming concepts with relational database principles.

 Objects are the basic building block and an instance of a class, where the type is either built-
in or user-defined.

 Classes provide a schema or blueprint for objects, defining the behavior.

 Methods determine the behavior of a class.

 Pointers help access elements of an object database and establish relations between
objects.

The main characteristic of objects in OODBMS is the possibility of user-constructed types. An object
created in a project or application saves into a database as is.

Object-oriented databases directly deal with data as complete objects. All the information comes in
one instantly available object package instead of multiple tables.

In contrast, the basic building blocks of relational databases, such as PostgreSQL or MySQL, are tables
with actions based on logical connections between the table data.
These characteristics make object databases suitable for projects with complex data which require an
object-oriented approach to programming. An object-oriented management system provides supported
functionality catered to object-oriented programming where complex objects are central. This
approach unifies attributes and behaviors of data into one entity.

The four main ideas of object-oriented programming are:

 Polymorphism
 Inheritance
 Encapsulation
 Abstraction

These four attributes describe the critical characteristics of object-oriented management

systems.

Polymorphism
Polymorphism is the capability of an object to take multiple forms. This ability allows the
same program code to work with different data types. Both a car and a bike are able to break,
but the mechanism is different. In this example, the action break is a polymorphism. The
defined action is polymorphic — the result changes depending on which vehicle performs.

Inheritance
Inheritance creates a hierarchical relationship between related classes while making parts of
code reusable. Defining new types inherits all the existing class fields and methods plus
further extends them. The existing class is the parent class, while the child class extends the
parent.

For example, a parent class called Vehicle will have child classes Car and Bike. Both child
classes inherit information from the parent class and extend the parent class with new
information depending on the vehicle type.

Encapsulation
Encapsulation is the ability to group data and mechanisms into a single object to provide
access protection. Through this process, pieces of information and details of how an object
works are hidden, resulting in data and function security. Classes interact with each other
through methods without the need to know how particular methods work.
As an example, a car has descriptive characteristics and actions. You can change the color of
a car, yet the model or make are examples of properties that cannot change. A
class encapsulates all the car information into one entity, where some elements are
modifiable while some are not.

Abstraction
Abstraction is the procedure of representing only the essential data features for the
needed functionality. The process selects vital information while unnecessary information
stays hidden. Abstraction helps reduce the complexity of modeled data and allows reusability.

For example, there are different ways for a computer to connect to the network. A web
browser needs an internet connection. However, the connection type is irrelevant. An
established connection to the internet represents an abstraction, whereas the various types of
connections represent different implementations of the abstraction.

What is Database Design?

Database design can be generally defined as a collection of tasks or processes that enhance the
designing, development, implementation, and maintenance of enterprise data management system.
Designing a proper database reduces the maintenance cost thereby improving data consistency and
the cost-effective measures are greatly influenced in terms of disk storage space. Therefore, there
has to be a brilliant concept of designing a database. The designer should follow the constraints and
decide how the elements correlate and what kind of data must be stored.

The main objectives behind database designing are to produce physical and logical design models of
the proposed database system. To elaborate this, the logical model is primarily concentrated on the
requirements of data and the considerations must be made in terms of monolithic considerations
and hence the stored physical data must be stored independent of the physical conditions. On the
other hand, the physical database design model includes a translation of the logical design model of
the database by keep control of physical media using hardware resources and software systems such
as Database Management System (DBMS).
Why is Database Design important?

The important consideration that can be taken into account while emphasizing the importance of
database design can be explained in terms of the following points given below.

1. Database designs provide the blueprints of how the data is going to be stored in a system. A
proper design of a database highly affects the overall performance of any application.

2. The designing principles defined for a database give a clear idea of the behavior of any
application and how the requests are processed.

3. Another instance to emphasize the database design is that a proper database design meets
all the requirements of users.

4. Lastly, the processing time of an application is greatly reduced if the constraints of designing
a highly efficient database are properly implemented.

Life Cycle

Although, the life cycle of a database is not an important discussion that has to be taken forward in
this article because we are focused on the database design. But, before jumping directly on the
designing models constituting database design it is important to understand the overall workflow
and life-cycle of the database.

Requirement Analysis

First of all, the planning has to be done on what are the basic requirements of the project under
which the design of the database has to be taken forward. Thus, they can be defined as:-

Planning - This stage is concerned with planning the entire DDLC (Database Development Life Cycle).
The strategic considerations are taken into account before proceeding.

System definition - This stage covers the boundaries and scopes of the proper database after
planning.

Database Designing

The next step involves designing the database considering the user-based requirements and splitting
them out into various models so that load or heavy dependencies on a single aspect are not
imposed. Therefore, there has been some model-centric approach and that's where logical and
physical models play a crucial role.

Physical Model - The physical model is concerned with the practices and implementations of the
logical model.
Logical Model - This stage is primarily concerned with developing a model based on the proposed
requirements. The entire model is designed on paper without any implementation or adopting DBMS
considerations.

Implementation

The last step covers the implementation methods and checking out the behavior that matches our
requirements. It is ensured with continuous integration testing of the database with different data
sets and conversion of data into machine understandable language. The manipulation of data is
primarily focused on these steps where queries are made to run and check if the application is
designed satisfactorily or not.

Data conversion and loading - This section is used to import and convert data from the old to the
new system.

Testing - This stage is concerned with error identification in the newly implemented system. Testing is
a crucial step because it checks the database directly and compares the requirement specifications.

Database Design Process

The process of designing a database carries various conceptual approaches that are needed to be
kept in mind. An ideal and well-structured database design must be able to:

1. Save disk space by eliminating redundant data.

2. Maintains data integrity and accuracy.

3. Provides data access in useful ways.

4. Comparing Logical and Physical data model

*nested relations and collections

(spatial database components and objects, dimensions relations SQL queries)

 Type Typical usage Examples
Key-value store—A simple  Image stores  Berkeley DB
data storage system that  Key-based  Memcache
uses a key to access a value filesystems  Redis
 Object cache  Riak
 Systems designed to  DynamoDB
scale
Column family store—A  Web crawler results  Apache HBase
 Type Typical usage Examples
sparse matrix system that  Big data problems  Apache Cassandra
uses a row and a column as that can relax  Hypertable
keys consistency rules  Apache Accumulo
Graph store—For  Social networks  Neo4j
relationship-intensive  Fraud detection  AllegroGraph
problems  Relationship-heavy  Bigdata (RDF data
data store)
 InfiniteGraph
(Objectivity)
Document store—Storing  High-variability data  MongoDB (10Gen)
hierarchical data structures  Document search  CouchDB
directly in the database  Integration hubs  Couchbase
 Web content  MarkLogic
management  eXist-db
 Publishing  Berkeley DB XML

NOsql business drivers:

1.2.1. VOLUME

Without a doubt, the key factor pushing organizations to look at alternatives to their current
RDBMSs is a need to query big data using clusters of commodity processors. Until around
2005, performance concerns were resolved by purchasing faster processors. In time, the
ability to increase processing speed was no longer an option. As chip density increased, heat
could no longer dissipate fast enough without chip overheating. This phenomenon, known as
the power wall, forced systems designers to shift their focus from increasing speed on a
single chip to using more processors working together. The need to scale out (also known
as horizontal scaling), rather than scale up (faster processors), moved organizations from
serial to parallel processing where data problems are split into separate paths and sent to
separate processors to divide and conquer the work.

1.2.2. VELOCITY

Though big data problems are a consideration for many organizations moving away from
RDBMSs, the ability of a single processor system to rapidly read and write data is also key.
Many single-processor RDBMSs are unable to keep up with the demands of real-time inserts
and online queries to the database made by public-facing websites. RDBMSs frequently
index many columns of every new row, a process which decreases system performance.
When single-processor RDBMSs are used as a back end to a web store front, the random
bursts in web traffic slow down response for everyone, and tuning these systems can be
costly when both high read and write throughput is desired.

1.2.3. VARIABILITY

Companies that want to capture and report on exception data struggle when attempting to use
rigid database schema structures imposed by RDBMSs. For example, if a business unit wants
to capture a few custom fields for a particular customer, all customer rows within the
database need to store this information even though it doesn’t apply. Adding new columns to
an RDBMS requires the system be shut down and ALTER TABLE commands to be run.
When a database is large, this process can impact system availability, costing time and
money.

1.2.4. AGILITY

The most complex part of building applications using RDBMSs is the process of putting data
into and getting data out of the database. If your data has nested and repeated subgroups of
data structures, you need to include an object-relational mapping layer. The responsibility of
this layer is to generate the correct combination of INSERT, UPDATE, DELETE, and
SELECT SQL statements to move object data to and from the RDBMS persistence layer.
This process isn’t simple and is associated with the largest barrier to rapid change when
developing new or modifying existing applications.

Generally, object-relational mapping requires experienced software developers who are

familiar with object-relational frameworks such as Java Hibernate (or NHibernate for .Net
systems). Even with experienced staff, small change requests can cause slowdowns in
development and testing schedules.

You can see how velocity, volume, variability, and agility are the high-level drivers most
frequently associated with the NoSQL movement. Now that you’re familiar with these
drivers, you can look at your organization to see how NoSQL solutions might impact these
drivers in a positive way to help your business meet the changing demands of today’s
competitive marketplace.

AD Theory 3:

Characteristic Operational Support Decision Support System

System

Data Currency Current operations Real- Historic data,Snapshot,of company data

time data Timecomponent(week/month/year)

Granularity Atomic detailed data Summarized data

Summarization Low: some aggregate High: many aggregation levels

level yields

Data model Highly normalized mostly Nonnormalized Complex structures Some relational, but
relationl DBMS mostly multidimensional DBMS

Transaction type Mostly updates Mostly query

Transaction High update volumes Periodic loads and summary calculations

volumes
 Characteristic Operational Support Decision Support System
System

Transaction Updates are critical Retrievals are critical

speed

Query activity Low to medium High

Query scope Narrow range Broad range

Query Simple to medium Very complex

complexity

Need for Data Warehouse

Data Warehouse is needed for the following reasons:

1. 1) Business User: Business users require a data warehouse to view

summarized data from the past. Since these people are non-technical, the
data may be presented to them in an elementary form.
2. 2) Store historical data: Data Warehouse is required to store the time variable
data from the past. This input is made to be used for various purposes.
 3. 3) Make strategic decisions: Some strategies may be depending upon the
data in the data warehouse. So, data warehouse contributes to making
strategic decisions.
4. 4) For data consistency and quality: Bringing the data from different sources
at a commonplace, the user can effectively undertake to bring the uniformity
and consistency in data.
5. 5) High response time: Data warehouse has to be ready for somewhat
unexpected loads and types of queries, which demands a significant degree of
flexibility and quick response time.

What is a Data Warehouse?

A Data Warehouse (DW) is a relational database that is designed for query and
analysis rather than transaction processing. It includes historical data derived from
transaction data from single and multiple sources.

A Data Warehouse provides integrated, enterprise-wide, historical data and focuses

on providing support for decision-makers for data modeling and analysis.

A Data Warehouse is a group of data specific to the entire organization, not only to a
particular group of users.

It is not used for daily operations and transaction processing but used for making
decisions.

A Data Warehouse can be viewed as a data system with the following attributes:

o It is a database designed for investigative tasks, using data from various

applications.
o It supports a relatively small number of clients with relatively long interactions.
o It includes current and historical data to provide a historical perspective of
information.
o Its usage is read-intensive.
o It contains a few large tables.

"Data Warehouse is a subject-oriented, integrated, and time-variant store of

information in support of management's decisions."

Features of Data Warehousing

Data warehousing is essential for modern data management, providing a
strong foundation for organizations to consolidate and analyze data
strategically. Its distinguishing features empower businesses with the
tools to make informed decisions and extract valuable insights from their
data.
 Centralized Data Repository: Data warehousing provides a
centralized repository for all enterprise data from various sources, such
as transactional databases, operational systems, and external sources.
This enables organizations to have a comprehensive view of their data,
which can help in making informed business decisions.
 Data Integration: Data warehousing integrates data from different
sources into a single, unified view, which can help in eliminating data
silos and reducing data inconsistencies.
 Historical Data Storage: Data warehousing stores historical data,
which enables organizations to analyze data trends over time. This can
help in identifying patterns and anomalies in the data, which can be
used to improve business performance.
 Query and Analysis: Data warehousing provides powerful query and
analysis capabilities that enable users to explore and analyze data in
different ways. This can help in identifying patterns and trends, and can
also help in making informed business decisions.
 Data Transformation: Data warehousing includes a process of data
transformation, which involves cleaning, filtering, and formatting data
from various sources to make it consistent and usable. This can help in
improving data quality and reducing data inconsistencies.
 Data Mining: Data warehousing provides data mining capabilities,
which enable organizations to discover hidden patterns and
relationships in their data. This can help in identifying new
opportunities, predicting future trends, and mitigating risks.
 Data Security: Data warehousing provides robust data security
features, such as access controls, data encryption, and data backups,
which ensure that the data is secure and protected from unauthorized
access.

Role of Metadata

Metadata has a very important role in a data warehouse. The role

of metadata in a warehouse is different from the warehouse data,
yet it plays an important role. The various roles of metadata are
explained below.


 Metadata acts as a directory.


This directory helps the decision support system to locate
the contents of the data warehouse.


Metadata helps in decision support system for mapping of
data when data is transformed from operational
environment to data warehouse environment.


Metadata helps in summarization between current detailed
data and highly summarized data.


Metadata also helps in summarization between lightly
detailed data and highly summarized data.


Metadata is used for query tools.


Metadata is used in extraction and cleansing tools.


Metadata is used in reporting tools.


Metadata is used in transformation tools.


Metadata plays an important role in loading functions.


The following diagram shows the roles of metadata.

Categories of Metadata

Metadata can be broadly categorized into three categories −


Business Metadata − It has the data ownership
information, business definition, and changing policies.


Technical Metadata − It includes database system names,
table and column names and sizes, data types and allowed
values. Technical metadata also includes structural
information such as primary and foreign key attributes and
indices.


Operational Metadata − It includes currency of data and
data lineage. Currency of data means whether the data is
active, archived, or purged. Lineage of data means the
history of data migrated and transformation applied on it.

What is Metadata?

Metadata is simply defined as data about data. The data that is

used to represent other data is known as metadata. For example,
the index of a book serves as a metadata for the contents in the
book. In other words, we can say that metadata is the
summarized data that leads us to detailed data. In terms of data
warehouse, we can define metadata as follows.


Metadata is the road-map to a data warehouse.


Metadata in a data warehouse defines the warehouse
objects.


Metadata acts as a directory. This directory helps the
decision support system to locate the contents of a data
warehouse.


Sl.N Data Warehouse Data Mart

o

Data warehouse is a Centralised While it is a decentralised

1.
system. system.

In data warehouse, lightly While in Data mart, highly

2.
denormalization takes place. denormalization takes place.

3. Data warehouse is top-down model. While it is a bottom-up model.

4. To built a warehouse is difficult. While to build a mart is easy.

In data warehouse, Fact While in this, Star schema and

5.
constellation schema is used. snowflake schema are used.

6. Data Warehouse is flexible. While it is not flexible.

Data Warehouse is the data- While it is the project-oriented in

7.
oriented in nature. nature.

While data-mart has short life

8. Data Ware house has long life.
than warehouse.
Sl.N Data Warehouse Data Mart
o

In Data Warehouse, Data are While in this, data are contained

9.
contained in detail form. in summarized form.

While data mart is smaller than

10. Data Warehouse is vast in size.
warehouse.

The Data Warehouse might be

The Size of Data Mart is less
11. somewhere between 100 GB and 1
than 100 GB.
TB+ in size.

The time it takes to implement a The Data Mart deployment

12. data warehouse might range from procedure is time-limited to a
months to years. few months.

It uses a lot of data and has Operational data are not

13.
comprehensive operational data. present in Data Mart.

It collects data from various data It generally stores data from a

14.
sources. data warehouse.

Less time for processing the

Long time for processing the data
15. data because of handling only a
because of large data.
small amount of data.

Complicated design process of Easy design process of creating

16.
creating schemas and views. schemas and views.