Unit IV

Document Oriented Database

1
Object Oriented Database
 Object-oriented databases (OODB) are databases
that represent data in the form of objects and classes.
In object-oriented terminology, an object is a real-
world entity, and a class is a collection of objects.

 Object-oriented databases follow the fundamental

principles of object-oriented programming (OOP).
The combination of relational model features
(concurrency, transaction, and recovery) with object-
oriented principles results in an object-oriented
database model.
2
WHY OBJECT ORIENTED DATABASE?
 An object oriented database is used for complex
databases. Such database applications require complex
interrelationships among object hierarchies to be
represented in database systems.
 These interrelationships are difficult to be implement
in relational systems.
 A. Limitation of Relational Databases
 Relational database technology was not able to handle
complex application systems such as Computer Aided
Design (CAD), Computer Aided Manufacturing
(CAM), and Computer Integrated Manufacturing
(CIM), Computer Aided Software Engineering (CASE)
etc
3
 The limitation for relational databases is that, they
have been designed to represent entities and
relationship in the form of two-dimensional tables.
Any complex interrelationship like, multi-valued
attributes or composite attribute may result in the
decomposition of a table into several tables, similarly,
complex interrelationships result in a number of tables
being created.
 Thus, the main asset of relational databases viz., its
simplicity for such applications, is also one of its
weaknesses, in the case of complex applications.

4
 The data domains in a relational system can be represented
in relational databases as standard data types defined in
the SQL. However, the relational model does not allow
extending these data types or creating the user’s own data
types. Thus, limiting the types of data that may be
represented using relational databases.
 Another major weakness of the RDBMS is that, concepts
like inheritance/hierarchy need to be represented with a
series of tables with the required referential constraint.
Thus they are not very natural for objects requiring
inheritance or hierarchy.

5
B. The Need for Object Oriented Databases
1. The objects may be complex, or they may consists of
low-level object
 However, to represent the data of these complex objects
through relational database models you would require
many tables – at least one each for each inherited class
and a table for the base class.
 In order to ensure that these tables operate correctly we
would need to set up referential integrity constraints as
well.
 On the other hand, object oriented models would
represent such a system Object Oriented Database very
naturally through, an inheritance hierarchy. Thus, it is a
very natural choice for such complex objects.

6
2. Consider a situation where you want to design a class,
(let us say a Date class), the advantage of object oriented
database management for such situations would be that
they allow representation of not only the structure but
also the operation on newer user defined database type
such as finding the difference of two dates.
 Thus, object oriented database technologies are ideal
for implementing such systems that support complex
inherited objects, user defined data types

7
3. Another major reason for the need of object oriented
database system would be the seamless integration of this
database technology with object-oriented applications.
Software design is now, mostly based on object oriented
technologies. Thus, object oriented database may provide a
seamless interface for combining the two technologies.

4. The Object oriented databases are also required to manage

complex, highly interrelated information. They provide
solution in the most natural and easy way that is closer to our
understanding of the system. Michael Brodie related the
object oriented system to human conceptualisation of a
problem domain which enhances communication among the
system designers, domain experts and the system end users

8
5. An object oriented database is presently being used
for various applications in areas such as, e-commerce,
engineering product data management; and special
purpose databases in areas such as, securities and
medicine.
6. Some of the major concerns of object oriented
database technologies include access optimization,
integrity enforcement, archive, backup and recovery
operations etc.

9
10
11
Differentiate OBJECT ORIENTED DATABASE and
Traditional Database?
BASIS RDBMS OODBMS
Stands for Relational Database Stands for Object Oriented
Long Form
Management System. Database Management System.

Stores data in Entities, defined as

Way of storing data Stores data as Objects.
tables hold specific information.

Handles larger and complex data

Data Complexity Handles comparatively simpler data.
than RDBMS.

Class describes a group of objects

Entity type refers to the collection of that have common relationships,
Grouping
entity that share a common definition. behaviors, and also have similar
properties.

Stores data as well as methods to

Data Handling RDBMS stores only data.
use it.

Data Independence from application

Main Objective Data Encapsulation.
program.

An object identifier (OID) is an

A Primary key distinctively identifies
Key unambiguous, long-term name for
an object in a table..
any type of object or entity.
12
Impedance Matching (Paradigm Mistach) Problem
between OO Languages and Relational Database

 The object-relational impedance mismatch is basically the set of

difficulties that arises when you try to combine (loading and
storing graph of object using RDBMS) an object-oriented code
with a relational database.
 1. Relations vs object references
 The first difference between OOP and relational databases is in
how they represent connections between separate concepts.
 In OOP, those connections are direct references from one
concept to another. They can be of various cardinality: a class
may either reference a single instance of another class or a whole
collection of them.
 They also can be of various parity: uni- or bi-directional. If latter,
classes connect to each other simultaneously, thereby forming
two references, one at each side of the connection.

13
 In relational databases, connections between concepts
are represented by relations. There’s no
inherent notion of cardinality in databases.
 A link between two tables is just that - a link. There’s
nothing in that link telling us whether it is a one-to-
many, many-to-many, or some other relationship.
 It is us who put a meaning into it and interpret that
link one way or another depending on the context.

14
2. Flat vs hierarchical structure
 In the OO world, the fact that you operate direct
references often leads to hierarchical data structures.
 In OO there are clusters of classes: a root, the main
class so to speak, and some number of descendants.
Moreover, this hierarchy may be a cycled graph. A
structure where some group of classes reference each
other forming a cycle.
 In relational databases, the situation is different. As
there’s no such things as uni- or bi-directional
relationships and no inherent notion of cardinality, a
relational model tends to result in a flat structure
where each table is of the same rank as any other one.
Cycles can occur in databases too but they are not as
common and generally are frown upon.

15
 In OOP, you can choose to declare a particular cluster
of classes a single thing, an aggregate, and then decide
to operate that thing transactionally.
 The problem here is that in the relational data store,
there’s nothing we can do to enforce this kind of
separation. All tables are made equal, so any
transaction can update any number of tables at once.
Because of that, it’s easy to introduce a race condition.
A situation where one transaction updates two tables
and another transaction updates one of those tables as
part of another routine, leaving an inconsistency
between the two.
16
 3. Encapsulation
 In the relational modeling, there’s just no such
notion. Encapsulation is not something you worry
about when trying to come up with a database
scheme.
 On the other hand, encapsulation is huge when it
comes to objects. You usually want to hide as much
information as possible by default and reveal it
only when necessary. And even then probably
change the form of that information to something
customer-friendly and not expose its underlying
structure.

17
loading and storing graph of object
using RDBMS
 Granularity problem
 OODBMS: various levels like Coarse and fine grained
 ORDBMS: 2 levels only (table and record)
 Subtypes
 OODBMS: inheritance
 ORDBMS: no
 Identity
 OODBMS: object identity and object equality
 ORDBMS:
 Associations
 OODBMS: object references (bidirectional)
 ORDBMS: foreign key (not directional)
 Data Navigation
 OODBMS: obj1.getbar().getv(); or obj1.getbar().getv().getz();
 ORDBMS: joins

18
Document Oriented Database
 A document-oriented database is a specific kind of
database that works on the principle of dealing with
'documents’ rather than strictly defined tables of
information.
 The document-oriented database plays an important
role is aggregating data from documents and getting
them into a searchable, organized form.
 A document-oriented database, as a particular kind of
NoSQL database, is able to 'parse’ data from
documents that store that data under certain 'keys,’
with sophisticated support for retrieval.

19
 For example, suppose one document has two names,
one address, and a list of ages of a home’s occupants. A
second document might have four names, two
addresses, and no age information. A document-
oriented database will take the data in both and store
them according to type, able to handle non-fixed
length data sets.

 Different document-oriented database products are

available, some of them with free Apache licensing and
other with proprietary licensing.

20
Need of Document Oriented
Database
 A Document Data Model is a lot different than other data
models because it stores data in JSON, BSON, or XML
documents.
 In this data model, we can move documents under one
document and apart from this, any particular elements
can be indexed to run queries faster.
 Often documents are stored and retrieved in such a way
that it becomes close to the data objects which are used
in many applications which means very less translations
are required to use data in applications.
 JSON is a native language that is often used to store and
query data too.
So in the document data model, each document has a key-value pair below is an
example for the same.

{
"Name" : "Yashodhra",
"Address" : "Near Patel Nagar",
"Email" : "[email protected]",
"Contact" : "12345"
}
 Features:
• Document Type Model: As we all know data is stored in
documents rather than tables or graphs, so it becomes
easy to map things in many programming languages.
• Flexible Schema: Overall schema is very much flexible
to support this statement one must know that not all
documents in a collection need to have the same fields.
• Distributed and Resilient: Document data models are
very much dispersed which is the reason behind
horizontal scaling and distribution of data.
• Manageable Query Language: These data models are
the ones in which query language allows the developers
to perform CRUD (Create Read Update Destroy)
operations on the data model.
Difference between Document
Oriented Database and Traditional
database
1. Relational Model:

Relational model is a model for the management of the database. It is called so

because the data is stored in the form of relations i.e., in the form of tables. Every
row consists of related data. These row in the table depict a real-world entity. To
work with python and the Relational data model we need a prerequisite knowledge
of – SQL and Pandas. Pandas is a library of Python.

2. Document Model:

In the document model, the data is stored in the form of documents. The documents
consist of the records which describe the actual and data of the document. A nested
document can be used to provide information about subcategories of the data.
Document can also be used to represent real-world objects.
S. No. Relational Model Document Model

1. It is row-based. It is document-based.

Not suitable for hierarchical data Generally used for hierarchical data
2.
storage. storage.

3. It consists of a predefined schema. It consists a dynamic schema.

ACID properties are followed by this CAP theorem are followed by this
4. model. (Atomicity, Consistency, model. (Consistency, Availability,
Isolation, and Durability). and Partition tolerance).
5. It is slower . It is faster than Relational Model.

6. Supports complex joins. Does Not support for complex joins.

7. It is column-based. It is field-based.

8. They are vertically scalable They are horizontally scalable

9. Fast replication support is not provided. They provide easy replication support

It is more used now-a-days to store data in

10. It is comparatively less used.
database.

To add attributes in a relational model,

In a document-based database, you need
database schema needs to be modified for
11. to add additional key-value pairs in the
including additional columns and their
document for representing new fields.
data types.
Definition of XML Encoding
 XML Encoding is defined as the process of converting
Unicode characters into binary format and in XML
when the processor reads the document it mandatorily
encodes the statement to the declared type of
encodings, the character encodings are specified
through the attribute ‘encoding’.
 Encoding plays a role in XML as the user needs to
provide a correct encoding while transferring XML
Documents on different platforms.
 With respective to XML 1.0 specification, the two
Unicode UTF -8 and 16 must be supported in the
processor automatically.
 XML parser encodes the document properly and
translate them into standard Unicode internally.
27
Syntax of XML Encoding
 This Unicode character set has a universal character
that covers a major part of the world languages.
 To lead a better interaction with methods of encoding
characters this Unicode gives us the specification.
 The encoding part is declared in the section of the
XML document LINE1. The general Syntax of Unicode
is given below:
<?xml version="1.0" encoding="encoding-name”?>

UTF-8 Syntax
<?xml version = "1.0" encoding = "UTF-8" standalone =
"no" ?>
28
 UTF-16 Syntax
If suppose a document includes a Unicode like (0XX…)
they are considered to be UTF-16 encodings with 16bits.

<?xml version = "1.0" encoding = "UTF-16" standalone =

"no" ?>

The encoding attribute names are not case-sensitive as

they proceed ISO and IANA standards.

29
 Types of Encoding in XML
 ?xml version="1.0" encoding="UTF-8"
standalone="no" ?>
<?xml-stylesheet href="clock.css"
type="text/css"?>
<Clocks timezone="GMT">
<timehour>11</timehour>
<timeminute>50</timeminute>
<timesecond>40</timesecond>
<timemeridian>p.m.</timemeridian>
</Clocks>
<?xml version="1.0" encoding="UTF-16"?>
<college>
<Professor>
<fullname>Evangeline MAC</fullname>
<Dept>Science-1</Dept>
</Professor>
<!--
<Professor>
<fullname>Antony Jay</fullname>
<Dept>Mathematics</Dept>
</Professor>
-->
</college>

30
1. UTF-8
 For specific Document types, certain detections rules
are given one such rule is for XML, DTD If no
character encoding is specified then UTF-8 is used and
java, SQL, XQuery uses this encoding as they have
compression format.
 For numeric character reference in XML, this UTF-8 is
been assigned with variable-length encoding. The
BYTE ORDER MASKS for UTF-8 is EF BB BF.
 It is said that for languages like Chinese scripts the
good choice is to use UTF-16 as there is a trouble with
UTF-8 is as they make larger files yet not a universal
solution. The significant bit of UTF-8 is defined as 7,
11,16,21 as they are encoded as one to four bytes.
31
Example
 <?xml version="1.0" encoding="UTF-8"
standalone="no" ?>
<?xml-stylesheet href="clock.css" type="text/css"?>
<Clocks timezone="GMT">
<timehour>11</timehour>
<timeminute>50</timeminute>
<timesecond>40</timesecond>
<timemeridian>p.m.</timemeridian>
</Clocks>
 O/P

32
2. UTF-16
 This type takes two bytes for each character and
should be smaller also incompatible with ASCII. UTF-
16 doesn’t follow uniform width which may use 2 or 4
bytes.
 It faces some issues while processing in older
programming languages like C version as they process
zero-harder machine address.
 Here the significant bit is represented as 16, 20. But
UTF-16 supports only for selected specification by xml
parser.
 For national data items (COBOL) parsed in XML
documents, it is suggested to prefer UTF-16. They are
used mostly in java and windows.
33
Example
 <?xml version="1.0" encoding="UTF-16"?>
<college>
<Professor>
<fullname>Evangeline MAC</fullname>
<Dept>Science-1</Dept>
</Professor>
<!--
<Professor>
<fullname>Antony Jay</fullname>
<Dept>Mathematics</Dept>
</Professor>
-->
</college>
34
O/p

35
 UTF 8 UTF 16
Definition A variable length character A variable length character
encoding for Unicode that uses encoding for Unicode that uses
8-bit, 16-bit, 24-bit, 32-bit 16-bit or 32-bit encoding
encoding depending on the depending on the character
character
length UTF-8 uses a byte at the UTF-16 uses 2 byte at the
minimum in encoding the minimum in encoding the
characters characters
encoded file size A UTF-8 encoded file tends UTF-16 encoded file tends
to be smaller to be bigger than UTF-8
Compatibility with ASCII UTF-8 is compatible with UTF-16 is incompatible
ASCII with ASCII
Byte oriented UTF-8 is byte oriented while UTF-16 is not
Error recovery UTF-8 is better in UTF-16 is not better in
recovering from errors recovering from errors
compared to UTF-16 compared to UTF-8

36
JSON - Introduction
 JSON stands for JavaScript Object Notation
 JSON is a text format for storing and transporting data
 JSON is "self-describing" and easy to understand
 This example is a JSON string:
 '{"name":"John", "age":30, "car":null}'
 It defines an object with 3 properties:
• name
• age
• car
 Each property has a value.
 If you parse the JSON string with a JavaScript
program, you can access the data as an object:
 let personName = obj.name;
let personAge = obj.age; 37
JSON
 JSON (short for JavaScript Object Notation) is yet another text-based data-interchange
format which uses text and number data types to represent objects. It’s an open-standard
format based on the subset of JavaScript programming language and is completely
language-independent.
 It’s a way to transmit data objects consisting of array data types and attribute-value
pairs between a server and the web browser. It uses a human-readable format to
represent simple data structures in web application-based code.
 Because of its flexibility, JSON is better suited for data-interchange between web
applications and web services. As a markup language, XML only adds extra
information to a plain text, whereas JSON, as the name suggests, is a way of representing
data objects.
 It is also used in desktop as well as server-side programming environments. Unlike
XML, JSON takes a simple approach to represent structure data without complex
mathematical notation and algorithms, plus it’s easy to learn which makes it an ideal way
to create more interactive pages.
 As they say, problem of one is the advantage of other. XML syntax is semantics-free, but
it’s verbose which means its complexity makes it hard to be used for every
application.
 XML was designed to improve readability, but not to be efficient. JSON syntax is much
more compact with its established semantics which makes it a preferred data format over
XML.

38
What is JSON?

• JSON stands for JavaScript Object Notation

• JSON is a lightweight data-interchange format
• JSON is plain text written in JavaScript object
notation
• JSON is used to send data between computers
• JSON is language independent .
 The JSON syntax is derived from JavaScript object
notation, but the JSON format is text only.
 Code for reading and generating JSON exists in
many programming languages.

39
Why Use JSON?
 The JSON format is syntactically similar to the code for creating
JavaScript objects. Because of this, a JavaScript program can
easily convert JSON data into JavaScript objects.

 Since the format is text only, JSON data can easily be sent
between computers, and used by any programming language.

 JavaScript has a built in function for converting JSON strings into

JavaScript objects:

JSON.parse()

 JavaScript also has a built in function for converting an object

into a JSON string:

JSON.stringify()
40
Storing Data

 When storing data, the data has to be a certain

format, and regardless of where you choose to
store it, text is always one of the legal formats.
 JSON makes it possible to store JavaScript objects
as text.

41
JSON - Objects
 Creating Simple Objects
 JSON objects can be created with JavaScript.
 Let us see the various ways of creating JSON objects using
JavaScript −

 Creation of an empty Object

var JSONObj = {};
 Creation of a new Object −
var JSONObj = new Object();
 Creation of an object with attribute bookname with value in
string, attribute price with numeric value. Attribute is
accessed by using '.' Operator −

var JSONObj = { "bookname ":"VB BLACK BOOK",

"price":500 };
42
 This is an example that shows creation of an object in javascript using JSON,
save the below code as json_object.htm

<html>
<head>
<title>Creating Object JSON with JavaScript</title>
<script language = "javascript" >
var JSONObj = { "name" : “RCPIT", "year" : 2005 };

document.write("<h1>JSON with JavaScript example</h1>");

document.write("<br>");
document.write("<h3>Website Name = "+JSONObj.name+"</h3>");
document.write("<h3>Year = "+JSONObj.year+"</h3>");
</script>
</head>

<body>
</body>
</html>

43
O/p
JSON with JavaScript example

Website Name = RCPIT

Year = 2005

44

Creating Array Objects
The following example shows creation of an array object in javascript using JSON, save the below code as json_array_object.htm
<html>
<head>
<title>Creation of array object in javascript using JSON</title>
<script language = "javascript" >
document.writeln("<h2>JSON array object</h2>");
var books = { "Pascal" : [
{ "Name" : "Pascal Made Simple", "price" : 700 },
{ "Name" : "Guide to Pascal", "price" : 400 }],

"Scala" : [
{ "Name" : "Scala for the Impatient", "price" : 1000 },
{ "Name" : "Scala in Depth", "price" : 1300 }]
}
var i = 0
document.writeln("<table border = '2'><tr>");

for(i = 0;i<books.Pascal.length;i++) {
document.writeln("<td>");
document.writeln("<table border = '1' width = 100 >");
document.writeln("<tr><td><b>Name</b></td><td width = 50>" + books.Pascal[i].Name+"</td></tr>");
document.writeln("<tr><td><b>Price</b></td><td width = 50>" + books.Pascal[i].price +"</td></tr>");
document.writeln("</table>");
document.writeln("</td>");
}
45
for(i = 0;i<books.Scala.length;i++) {
document.writeln("<td>");
document.writeln("<table border = '1' width = 100 >");
document.writeln("<tr><td><b>Name</b></td><td width = 50>" +
books.Scala[i].Name+"</td></tr>");
document.writeln("<tr><td><b>Price</b></td><td width = 50>" +
books.Scala[i].price+"</td></tr>");
document.writeln("</table>");
document.writeln("</td>");
}

document.writeln("</tr></table>");
</script>
</head>

<body>
</body>
</html>

46
47
 XML JSON
Definition XML is a simplified version of the SGML JSON, on the other hand, is a lightweight
(standard generalized markup language) used data-interchange format used to represent
to store and represent structured data in a format hierarchical data and is based on JavaScript
that is both machine-readable and human- object syntax.
readable. It’s designed to improve readability as
it’s a markup language which adds extra
information to plain text.
Meaning XML is short for “Extensive Markup Language” JSON stands for “JavaScript Object Notation”
and is a document-oriented technology used to and as the name suggests, it’s based on the
encode data in a human-readable format. It’s a JavaScript programming language.
flexible file format suitable for web use.

Purpose XML was developed by the World Wide Web JSON was developed by Douglas Crockford
Consortium as a well-documented open standard
format containing a set of rules on how to encode as a simple, lightweight file format for data
documents in both human-readable and interchange.
machine-readable format.

Syntax XML, on the other hand, takes more characters to JSON has no start and end tags and the
represent same data. It’s not as lightweight as syntax is lighter than XML as it’s data-
JSON. oriented with less redundancy which makes
it an ideal alternative for interchanging data
over XML.
Data Type XML has no direct support for array type but it JSON supports text and number data type
supports many data types such as number, text, including integer and strings. Structured
images, graphs, charts, etc. data is represented using arrays and objects.

48
What is BSON ?
 BSON stands for Binary JSON.
 It is a binary file format that is used to store
serialized JSON documents in a binary-encoded format.
 It was developed in 2009 by MongoDB.
 The MongoDB database had several scalar data formats that
were of special interest only for MongoDB, hence they
developed the BSON data format to be used while
transferring files over the network.
 It has several similarities with JSON for instance BSON too
supports nested documents and arrays within other
documents, but yet has a lot of striking differences.

49
Sample BSON document
• Consider the following JSON document:

{ "hello" : "world" }
 It’s BSON equivalent will be:
\x16\x00\x00\x00 // Size of the Document
\x02 // 0x02 = type String
hello\x00 // field name
\x06\x00\x00\x00world\x00 // field value
\x00 // Used to represent end of object

where “\x01” is used to represent 0000 0001 50

Characteristics of BSON Documents:
Following are the three main characteristics of BSON documents-

 Lightweight – The term overhead during data transmission refers to

the extra bits that are not necessary for transmission (like checksum,
parity etc.). These bits are transferred along with data usually as a part
of headers. BSON keeps spatial overhead to a bare minimum which
allows it to be lightweight during transfer over any network.

 Traversable – BSON was designed to be highly traversable in nature. It

can be parsed easily and very quickly because it supports type and
length encoding, thanks to its binary structure.

 Efficient – BSON supports efficient data encoding and decoding. Data

can be both encoded to and decoded from BSON very easily and
quickly.

51
Data Types supported by BSON:
Following are the data types supported by BSON –
S No Data Type Size (bytes)

1 byte 1

2 int32 4

3 int64 8

4 uint64 8

5 double 8

6 decimal128 16

7 date 8

8 objectId 12

9 array Based on data (For ex – A byte array uses 1 byte)

52
Why BSON?
Following are the advantages of using BSON during data
transfer –
 BSON can be parsed easily and very quickly because it
supports type and length encoding, thanks to its binary
structure.
 BSON objects are designed to be highly traversable and
lightweight in nature, which makes it a better option for
data transfer.
 It takes up less space and offers faster scan speed as
compared to JSON objects.
 It offers a wide range of data types, like – date type, etc.),
many of which are not supported by JSON.
53
Disadvantages of using BSON:
 BSON supports fast traversal of the BSON document.
In order to support it, BSON adds extra information
(like the length of subobjects, etc.) to the document.
In some cases, this leads to increase in the size of the
document and decreases the efficiency when
compared to JSON

54
The basis Of
Comparison
JSON BSON

Type Standard file format Binary file format

Speed Comparatively less fast Faster
Space Consumes comparatively less space. More space is consumed.
Usage Transmission of data. Storage of data.
Encoding and
Decoding No such technique. Faster encoding and decoding technique.
technique
Key-value pair only used for
Characteristics Lightweight, fast and traversable.
transmission of data.
Language independent format used Binary JSON which consist of a list of ordered
Structure for asynchronous server browser elements containing a field name, type, and
communication. value. Field name types are typically a string.
BSON, on the other hand, just indexes on the
JSON doesn’t skip rather skims
Traversal relevant content and skips all the content which
through all the content.
does not have to be in use.
JSON formats need not be parsed as BSON, on the other hand, needs to be parsed as
Parse they are in a human-readable format they are easy for machines to parse and
already. generate.
The binary encoding technique consists of
Broadly JSON consists of an object
additional information such as lengths of
and an array where the object is a
Creation type strings and the object subtypes. Moreover,
collection of key-value pairs, and the
BinData and Date data types are the data
array is an ordered list of values.
types that are not supported in JSON.
55
Case study on Doc Oriented
Based such a Mariadb
 MariaDB is an open-source RDBMS that works on
ANSI SQL to analyze data. MariaDB is created by
forking the MSQL and is available as free and open-
source software.
 It is available in various languages such as Perl, C++,
Python, etc.
 Users can use MariaDB in all Windows, Mac, and
Linux OS systems.
 MariaDB has many inbuilt features, storage engines,
improved security systems, and more.
56
Key Features of MariaDB
 Enhanced Security Measures: MariaDB has stringent
security measures involving database encryption, Password
checks, LDAP authentication, user roles, and many more.

 Efficient Performance: MariaDB enables caching,

threading, and encryptions over the data, making it more
performant than MySQL. MariaDB’s performance in
fetching the result is exceptional.

 Efficient User Support: MariaDB has excellent user

support for mission-critical production systems around the
year. There are also various forums for discussion, chat
support, and many more.

57
MariaDB : Database Model

 MariaDB has a Relational Database model that

requires a pre-defined schema for data to ingest.

The above picture is from a sample table in MariaDB. As

you can see, it contains Rows and Columns which hold
the data in a particular fashion(schema), and the entire
table is locked to that schema.
58
MariaDB: Replication Methods
 MariaDB supports the Master-Slave replication
method, and there are four different types of
Replication in MariaDB :
 Standard Replication
 Infinite read scale-out is provided.
 By converting a replica to a primary, high availability is
achieved.

59
 Ring Replication
 Scales read and write operations.
 Doesn’t know how to deal with disagreements.
 Replication is halted if one of the primary servers fails.

60
 Star Replication
 Read and write scaling is available.
 Doesn’t seem to be able to deal with disagreements.
 To prevent data duplication, replication filters must be
used.

61
MultiSource Replication
 It is possible to combine data from various sources.
 On all replicas, various domains ran in parallel.

62
MariaDB : SQL Syntax
 MariaDB is based on ANSI SQL, and hence its syntax
is traditional SQL syntax to query and analyze the
data.
 For example, to query the data from a sample
employee table, the user can run the following
command to get the data –
 SELECT * FROM employee;
 MariaDB: Referential Integrity
 MariaDB is an RDBMS system, and the concept of
Foreign key exists. Hence, different tables are very well
linked together, which helps to grab the data from any
table
63
 MariaDB : Programming Language
 MariaDB had support for only a few languages, and hence
sometimes, it isn’t easy to interact with every system. The
programming language MariaDB supports is Python, Java,
and C/C++.

 MariaDB Vs MongoDB: Cloud Support

 MariaDB has only compatible with Azure cloud systems.
Recently, MariaDB upgrades to MariaDB SkySQL cloud
database, which includes expanded support for Amazon
Web Services (AWS).

 MariaDB Vs MongoDB: Data Format

 MariaDB is a relational database, and hence it doesn’t
support schema-less data. MariaDB has excellent support
for structured data. To define a table in MariaDB user
needs to provide the complete schema for that table which
must contain column names with datatypes and any
constraint.
64