Professional Documents
Culture Documents
Data Management Evolution
Data Management Evolution
State
Real world entity
Behavior
1
© e-Learning Centre, UCSC
3
Object Databases - Overview of Object Database
Concepts
1
© e-Learning Centre, UCSC
4
Object Databases - Overview of Object Database
Concepts
1
© e-Learning Centre, UCSC
5
Object Databases - Overview of Object Database
Concepts
• Object Identity
• Database objects needs to have coherence with real-world
objects in order to preserve their integrity and identity. It will
make easy to identify objects and operate on. Therefore, a
unique identity is assigned to each independent object
stored in the database known as Object Identifier (OID).
• OID generally is system generated.
• The value of the OID might be hidden from external users.
However, it is used inside the system to uniquely identify the
objects and to create and manage inter-object references.
1
© e-Learning Centre, UCSC
6
Object Databases - Overview of Object Database
Concepts
• Object Identifier (OID)
• Main properties of OID,
‒ Immutable - value of OID does not change
‒ Unique - used only once. OID of deleted object will
not be assigned to a new object in the future.
• According to these two properties of OID, OID is independent
from any attribute value of an object. (because attribute value
may change over time)
• Object database systems must have mechanism to generate
OID and preserve immutability. Since an object retains its
identifier over its lifetime, the object remains the same despite
changes in its state.
• OID is similar to the primary key attribute in relational
databases, which is used to uniquely identify the tuples.
1
© e-Learning Centre, UCSC
7
Object Databases - Overview of Object Database
Concepts
Literals
• The Object Model supports different literal types, which are
considered as attribute values.
• Literals are embedded inside objects and the object model
facilitates to define complex structured literals within an object.
• Literals do not have identifiers (OIDs) and, therefore, cannot be
individually referenced like objects from other objects.
1
© e-Learning Centre, UCSC
8
Object Databases - Overview of Object Database
Concepts
Literals
The literal types supported by the Object Model are
– Single-valued or atomic types where each value of the
type is considered as an atomic (indivisible) single value.
– Struct (or tuple) constructor which is used to create
standard structured types, such as the tuples (record types)
in the basic relational model.
– Collection (or multivalued) type constructors which
include the set(T), list(T), bag(T), array(T), and
dictionary(K,T) type constructors.
1
© e-Learning Centre, UCSC
9
Object Databases - Overview of Object Database
Concepts
2
© e-Learning Centre, UCSC
0
Object Databases - Overview of Object Database
Concepts
2
© e-Learning Centre, UCSC
1
Object Databases - Overview of Object Database
Concepts
2
© e-Learning Centre, UCSC
2
Object Databases - Overview of Object Database
Concepts
2
© e-Learning Centre, UCSC
3
Object Databases - Overview of Object Database
Concepts
Complex Object
The literal types supported
by the object model enables
to define complex objects
Set Primitive
which may consist of other Obj Obj
List Primitive
objects as illustrated by the Obj Obj
following Department
example..
define type DEPARTMENT
tuple ( Dname: string; Atomic Type
Tuple Type
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
Locations: set(string); Set Type
Employees: set(EMPLOYEE);
Projects: set(PROJECT); ); 2
© e-Learning Centre, UCSC
4
Activity
2
© e-Learning Centre, UCSC
5
Object Databases - Overview of Object Database
Concepts
Encapsulation
• The concept of encapsulation is applied to database objects
and it is the mechanism that binds together code and the data it
manipulates.
• Thus, encapsulation defines the behavior of a type of object
based on the operations that can be externally applied to
objects of that type.
• Encapsulation can bring a form of data and operation
independence. Therefore, encapsulation is encouraged by
defining the operation in two parts namely signature and
method.
2
© e-Learning Centre, UCSC
6
Object Databases - Overview of Object Database
Concepts
Encapsulation
‒ Signature/Interface of the operation - Specifies the name of
the operations and its arguments (parameters).
‒ Method/Body - Specifies the implementation of the
operation.
• External programs pass messages to the objects, to invoke
operations which includes the operation name and the
parameters.
• Thus, encapsulation restricts the direct access to the values of an
object as the values are required to be accessed through the pre-
defined methods.
2
© e-Learning Centre, UCSC
7
Object Databases - Overview of Object Database
Concepts
Encapsulation
• For database applications, the requirement that all objects be
completely encapsulated is too strict.
• This requirement is relaxed by dividing the structure of an object
into visible and hidden attributes (instance variables).
• Visible attributes can be seen by and are directly accessible to
the database users and programmers via the query language.
• The hidden attributes of an object are completely encapsulated
and can be accessed only through predefined operations.
2
© e-Learning Centre, UCSC
8
Object Databases - Overview of Object Database
Concepts
Class
2
© e-Learning Centre, UCSC
9
Object Databases - Overview of Object Database
Concepts
Class
• The operations which would be defined in a class may include
the
– object constructor operation (often called new), which is
used to create a new object
– destructor operation, which is used to destroy (delete) an
object.
– A number of object modifier operations can also be
declared to modify the states (values) of various attributes of
an object.
– Additional operations can retrieve information about the
object.
3
© e-Learning Centre, UCSC
0
Object Databases - Overview of Object Database
Concepts
The following example shows how the type definitions can be
extended with operations to define classes.
define class DEPARTMENT
type tuple ( Dname: string;
Dnumber: integer;
Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
An operation is applied Locations: set (string);
to an object by using
Employees: set (EMPLOYEE);
the dot notation. For
example, if d is a Projects set(PROJECT); );
reference to a operations no_of_emps: integer;
DEPARTMENT object, create_dept: DEPARTMENT;
an operation such as delete_dept: boolean;
no_of_emps can be assign_emp(e: EMPLOYEE): boolean;
invoked by writing (* adds an employee to the department *)
d.no_of_emps. remove_emp(e: EMPLOYEE): boolean;
(* removes an employee from the
department *)
end DEPARTMENT;
3
© e-Learning Centre, UCSC
1
Object Databases - Overview of Object Database
Concepts
• Encapsulation of Operations
define class Student
type tuple ( Firstname: string;
Lname: string;
NIC: string;
Birth_date: DATE;
Address: string;
Gender: char;
Dept: DEPARTMENT; );
operations age: integer;
create_stue: Student;
destroy_stu: Boolean;
end Student;
3
© e-Learning Centre, UCSC
2
Activity
3
© e-Learning Centre, UCSC
3
Object Databases - Overview of Object Database
Concepts
• Persistence of Objects
• Transient objects - in OOPL, objects only exist while the
program is running. Hence, these objects are known as
transient objects.
• Persistent objects - objects that are exist even after the
termination of the program.
• There are two mechanism to make an object persistence.
i) Naming Mechanism
ii) Reachability Mechanism
3
© e-Learning Centre, UCSC
4
Object Databases - Overview of Object Database
Concepts
Persistence of Objects
i) Naming Mechanism
• This mechanism assigns a name to an object which is
unique within database. An operation or a statement can be
used to specify the name.
• Users and applications perform database access through
the named persistent objects which are used as entry points
to the database.
• However, it is not practical to name all objects in a large
database that includes thousands of objects. Therefore,
most objects are made persistent by using the second
mechanism, called reachability.
3
© e-Learning Centre, UCSC
5
Object Databases - Overview of Object Database
Concepts
Persistence of Objects
ii) Reachability Mechanism
• The reachability mechanism works by making the object
reachable from some other persistent object.
3
© e-Learning Centre, UCSC
6
Object Databases - Overview of Object Database
Concepts
3
© e-Learning Centre, UCSC
7
Class DEPARTMENT_SET is
defined as a collection of
define class DEPARTMENT_SET DEPARTMENT objects.
type set (DEPARTMENT);
operations add_dept(d: DEPARTMENT): boolean;
(* adds a department to the
DEPARTMENT_SET object *)
define class DEPARTMENT
remove_dept(d: DEPARTMENT): boolean; type tuple ( Dname: string;
(* removes a department from the Dnumber: integer;
DEPARTMENT_SET object *) Mgr: tuple ( Manager: EMPLOYEE;
Start_date: DATE; );
create_dept_set: DEPARTMENT_SET; Locations: set (string);
destroy_dept_set: boolean; Employees: set (EMPLOYEE);
Projects set(PROJECT); );
end Department_Set; persistent collection of objects of
Operations
… class DEPARTMENT known as
no_of_emps: integer;
Extent
create_dept: DEPARTMENT;
persistent name ALL_DEPARTMENTS: destroy_dept: boolean;
DEPARTMENT_SET; assign_emp(e: EMPLOYEE): boolean;
(* ALL_DEPARTMENTS is a persistent named object of (* adds an employee to the department *)
type DEPARTMENT_SET *) remove_emp(e: EMPLOYEE): boolean;
(* removes an employee from the department *)
…
end DEPARTMENT;
d:= create_dept;
(* create a new DEPARTMENT object in the variable d *)
DEPARTMENT object d is added to the set of
… ALL_DEPARTMENTS by using the add_dept
b:= ALL_DEPARTMENTS.add_dept(d); operation.
38
Object Databases - Overview of Object Database
Concepts
3
© e-Learning Centre, UCSC
9
Object Databases - Overview of Object Database
Concepts
4
© e-Learning Centre, UCSC
0
Object Databases - Overview of Object Database
Concepts
Type Hierarchies and Inheritance
• Type/class Hierarchies and Inheritance are two key features in
Object database. Inheritance direct to type/class hierarchies.
• Inheritance is a key concept in Object model which allows to
inherit structure and/or operations of previously defined classes.
• Inheritance promotes the reuse of existing type definitions and
ease the incremental development of data types.
Rectangle Triangle
Length:int Base:int
Width:int Height:int
4
© e-Learning Centre, UCSC
1
Object Databases - Overview of Object Database
Concepts
4
© e-Learning Centre, UCSC
2
Object Databases - Overview of Object Database
Concepts
4
© e-Learning Centre, UCSC
3
Object Databases - Overview of Object Database
Concepts
NIC, Name,
Address, Birthdate
STUDENT EMPLOYEE
Attributes of Attributes of
Student Employee
(NIC, Name, (NIC, Name,
Address, Address,
Birthdate, Birthdate,
RegNo, Empid, Salary,
IndexNo, Gpa) RegNo, IndexNo, Empid, Salary, Hire_date)
Gpa Hire_date
4
© e-Learning Centre, UCSC
5
Object Databases - Overview of Object Database
Concepts
4
© e-Learning Centre, UCSC
7
Object Databases - Overview of Object Database
Concepts
Geometric_Obj
Name, Colour, Area,
Cal_area
Circle_Obj Rectangle_Obj :
Radius width, height
GetRadius GetWidth(w:float)
(rad:float) Getheight(h:float)
4
© e-Learning Centre, UCSC
8
Activity
4
© e-Learning Centre, UCSC
9
Object Databases - Overview of Object Database
Concepts
Multiple Inheritance
• Multiple inheritance takes place when a subtype inherits
from two or more supertypes. In such cases, the subtype
may inherit all the functions of all it’s supertypes.
• A subtype ENGINEERING_MANAGER that is a subtype of
both MANAGER and ENGINEER.
• A type lattice is created as a result of multiple inheritance
rather than a type hierarchy.
5
© e-Learning Centre, UCSC
0
Object Databases - Overview of Object Database
Concepts
EMPLOYEE
ENGINEERING-MANAGER
5
© e-Learning Centre, UCSC
1
Object Databases - Overview of Object Database
Concepts
5
© e-Learning Centre, UCSC
2
Object Databases - Overview of Object Database
Concepts
5
© e-Learning Centre, UCSC
3
Object Databases - Overview of Object Database
Concepts
Selective inheritance
• Selective inheritance enables subtype to inherit only some of
the functions of a supertype. Other functions are not inherited.
• The functions in a supertype that are not to be inherited by the
subtype are defined through EXCEPT clause .
• The mechanism of selective inheritance is not facilitated in
ODBs, but it is used more frequently in artificial intelligence
applications.
5
© e-Learning Centre, UCSC
4
Object Databases - Overview of Object Database
Concepts
5
© e-Learning Centre, UCSC
5
Object Databases - Overview of Object Database
Concepts
5
© e-Learning Centre, UCSC
6
Object Databases - Overview of Object Database
Concepts
Geometric_Obj
Name, Colour, Area,
Cal_area
Circle_Obj Rectangle_Obj
Radius width, height
GetRadius GetWidth(width:float)
(radius:float) Getheight(height:float)
Cal_area Cal_area
(radius: float) (width : float, height: float)
5
© e-Learning Centre, UCSC
7
Object Databases - Overview of Object Database
Concepts
5
© e-Learning Centre, UCSC
8
Activity
5
© e-Learning Centre, UCSC
9
XML Databases - Reason for the Origination of XML
6
© e-Learning Centre, UCSC
0
XML Databases - Reason for the Origination of XML
6
© e-Learning Centre, UCSC
1
XML Databases - Reason for the Origination of XML
Different
output
with Interactive
User Input
Output
different
input
6
© e-Learning Centre, UCSC
2
Activity
6
© e-Learning Centre, UCSC
3
XML Databases - Structured, Semi - Structured and
Unstructured Data
Structured Data
• Information in Relational Databases - Structured Data
• Each Data Record in the database follows the same
structure
6
© e-Learning Centre, UCSC
4
XML Databases - Structured, Semi - Structured and
Unstructured Data
Semi - Structured Data
• Some data is collected in unplanned situations. Therefore,
all the data may not have the same format.
• Data may have a certain structure. However, not all the
data has the same structure
E.g: Some have additional attributes; Some
attributes maybe present only in some data.
• No predefined schema
• Data model to represent semi - structured data
- Tree data structure
- Graph data structure
6
© e-Learning Centre, UCSC
5
XML Databases - Structured, Semi - Structured and
Unstructured Data
Pick &
Ride P001 Colombo
6
© e-Learning Centre, UCSC
6
XML Databases - Structured, Semi - Structured and
Unstructured Data
6
© e-Learning Centre, UCSC
7
XML Databases - Structured, Semi - Structured and
Unstructured Data
Internal Nodes
Pick &
Ride P001 Colombo
Labels / Tags
Leaf Nodes
6
© e-Learning Centre, UCSC
8
XML Databases - Structured, Semi - Structured and
Unstructured Data
6
© e-Learning Centre, UCSC
9
XML Databases - Structured, Semi - Structured and
Unstructured Data
Unstructured Data
• Almost has no specification of the type of data
eg: Web pages designed using HTML
• <p></p> - Outputs whatever data inside the two tags
regardless of the meaning of them.
• <p><b></b></p> - Data formatting is also mixed with data
values.
7
© e-Learning Centre, UCSC
0
XML Databases - Structured, Semi - Structured and
Unstructured Data
7
© e-Learning Centre, UCSC
1
XML Databases - Structured, Semi - Structured and
Unstructured Data
• Unstructured Data
• HTML documents are harder to analyze and interpret
using software since they do not have schema information
on the type of data.
• However, with the shifting of the human needs to an
online environment, it is required to have correct
interpretations on data presented online and exchange
these data.
• This need gave rise to the use of XML in online data
manipulation environments.
7
© e-Learning Centre, UCSC
2
Activity
7
© e-Learning Centre, UCSC
3
XML Databases - XML Hierarchical (Tree) Data Model
– Attributes
<book>
<title>Gamperaliya </title>
<author id="ABC"> Martin Wickramasinghe </author>
</book>
<book>
<title>Siyalanga Ruu Soba </title>
Element <author id="ABC"> J. B. Dissanayake </author>
Attribute
</book>
7
© e-Learning Centre, UCSC
5
XML Databases - XML Hierarchical (Tree) Data Model
• Constructing an XML Document
7
© e-Learning Centre, UCSC
6
XML Databases - XML Hierarchical (Tree) Data Model
7
© e-Learning Centre, UCSC
7
XML Databases - XML Hierarchical (Tree) Data Model
Complex Elements
Simple Elements
7
© e-Learning Centre, UCSC
8
XML Databases - XML Hierarchical (Tree) Data Model
7
© e-Learning Centre, UCSC
9
XML Databases - XML Hierarchical (Tree) Data Model
8
© e-Learning Centre, UCSC
0
XML Databases - XML Hierarchical (Tree) Data Model
8
© e-Learning Centre, UCSC
1
XML Databases - XML Hierarchical (Tree) Data Model
8
© e-Learning Centre, UCSC
2
XML Databases - XML Hierarchical (Tree) Data Model
8
© e-Learning Centre, UCSC
3
XML Databases - XML Hierarchical (Tree) Data Model
8
© e-Learning Centre, UCSC
4
Activity
8
© e-Learning Centre, UCSC
5
NoSQL Databases - Origins of NoSQL
8
© e-Learning Centre, UCSC
6
NoSQL Databases - Origins of NoSQL
Impedance Mismatch
• Impedance mismatch is the term used to refer to the
dissimilarity between the relational database model and the
programming language model (data structures in-memory).
• Although relational data model represents data as relations
in tabular format which is simple, it introduces certain
limitations. In particular, tabular representation cannot
contain any structure, such as a nested record or a list.
8
© e-Learning Centre, UCSC
7
NoSQL Databases - Origins of NoSQL
Impedance Mismatch
There are no such limitations for in-memory data structures,
which can take on much richer structures than relations.
Consequently, a richer in-memory data structure is required to be
translated into a relational representation to store it on disk.
These two different representations would cause the impedance
mismatch which require translation from one representation to the
other.
8
© e-Learning Centre, UCSC
8
NoSQL Databases - Origins of NoSQL
Orders
ID: 0001
Customer: Kamal
Customers
8
© e-Learning Centre, UCSC
9
NoSQL Databases - Origins of NoSQL
Impedance Mismatch
• Impedance mismatch is made much easier with the object-
relational mapping frameworks, such as Hibernate that
implement well-known mapping patterns.
• Although these mapping frameworks remove a lot of tedious
work the mapping problem is still an issue since the problems
in representing the in-memory data structures from
the database perspective is not taken into consideration. This
would hinder the query performance.
9
© e-Learning Centre, UCSC
0
NoSQL Databases - Origins of NoSQL
9
© e-Learning Centre, UCSC
1
NoSQL Databases - Origins of NoSQL
Drawbacks of Shared Database Integration
The drawbacks of Database Integration are as given below:
• A structure that is designed to integrate many applications
often become more complex than any single application
needs.
• If an application requires to make changes to its data storage, it
needs to coordinate with all the other applications using the
database.
• Since different applications have different structural and
performance needs, an index required by one application may
hinder the performance of insert operations of another
application.
• Usually, a separate team is responsible for each application.
This means that the database cannot trust applications to
update the data in a way that preserves database integrity.
Thus, the responsibility of preserving database integrity is
within the database itself.
9
© e-Learning Centre, UCSC
2
NoSQL Databases - Origins of NoSQL
• Since the application team takes care of both the database and
the application code, the responsibility for database integrity
can be passed onto the application code.
• Web services (where applications would communicate over
HTTP) enabled a new form of a widely used communication
mechanism which challenged the use of SQL with shared
databases.
9
© e-Learning Centre, UCSC
3
NoSQL Databases - Origins of NoSQL
Sales system
Sales
Application
database Database
Shared
Web service
Database Common
Integration database
integration
Inventory system
Application
Inventory system Database
Inventory
system
9
© e-Learning Centre, UCSC
4
NoSQL Databases - Origins of NoSQL
9
© e-Learning Centre, UCSC
5
NoSQL Databases - Origins of NoSQL
9
© e-Learning Centre, UCSC
6
NoSQL Databases - Origins of NoSQL
9
© e-Learning Centre, UCSC
7
NoSQL Databases - Origins of NoSQL
NoSQL databases emerged mainly to provide the following
advantages
a) Flexible data modeling: NoSQL emerged as a solution to the
impedance mismatch problem between relational data models and
object-oriented data models. NoSQL covers four different data
organization models as given below which are highly-customizable
to different businesses' needs.
i) Document databases: store data as documents similar to
JSON (JavaScript Object Notation) objects. Each document has
pairs of fields and values.
ii) Key-Value databases: represent a simpler type of database
where each item contains keys and values. A value can only be
retrieved by referencing its key and thus querying for a specific
key-value pair is simple.
iii) Column-Family databases: store data in tables, rows, and
in dynamic columns. This data model provides a lot of flexibility
over relational databases because each row is not required to
have the identical columns.
9
© e-Learning Centre, UCSC
8
NoSQL Databases - Origins of NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Origins of NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Origins of NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 0
NoSQL Databases - Data models in NoSQL: Sample
of data stored in the tables
Customer Order
1 Shantha 99 1 77
27 Laptop 55 1 77
Order Payment
33 99 34-886-89 55 act-564 1
© e-Learning Centre, UCSC 0
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 1
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 1
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 1
NoSQL Databases - Data models in NoSQL
<Bucket = userData>
<Key = sessionID>
<Value = object>
UserProfile
SessionData
shopping Cart
CartItem
CartItem
1
© e-Learning Centre, UCSC 1
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 1
NoSQL Databases - Data models in NoSQL
Key
111-444-3333 222-555-7777 222-555-777
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
Document Data Model Example
Relational Document
model model
Tables Collections
Rows Documents
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
Column
Column-Family Example Column
value
key
6783
ORDER1 data...
ORDER2 data...
row key
ORDER3 data...
Orders
ORDER4 data...
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
1
© e-Learning Centre, UCSC 2
NoSQL Databases - Data models in NoSQL
Rows Vertices
Krishna
Columns Key/value pairs
Joins Edges
Fathima Chamal
1 1
© e-Learning Centre, UCSC 2 2
Activity
Match the most relevant description, with the data models given.
1
© e-Learning Centre, UCSC 3
Activity
You have given a set of NoSQL databases and data models. Drop the
databases in left hand side to its relevant data model in right hand side.
Key-value
HBase Neo4j
HyperTable Redis
Document
CouchDB MongoDB
What is the most suitable NoSQL database model for the above use
case?
Drag and drop the correct answer to the blanks from the given list.
(Consistency, Availability, Partition Tolerance, master-slave,
Replication, replica sets, column, memtable)
The CAP theorem states that we can ensure only two features
of_______, _________, and ________________. In Document
databases, availability is improved by data replication using the
______ setup. With __________, we can access data stored in
multiple nodes and the clients do not have to worry about the failure
of the primary node since data is available in other nodes as well. In
MongoDB, availability is achieved using ___________. Cassandra
is a column-family database which uses _____ as the basic unit of
storage. The procedure of receiving a write by Cassandra is as
follows. Data is stored into memory only after stored in a commit log.
The term used to describe that in-memory structure is ________.
Drag and drop the correct answer to the blanks from the given list.
(aggregate , unit, ACID, aggregate-oriented, clusters)
• Handling Relationships
• In ODBs, features of a relationship which is also called
reference attributes are used to manage relationships
between the objects. In relational DBs, attributes with
matching values are used to specify the relationship
among the tuples(records). Foreign keys are used for
referencing relation in relational DBs.
• Single reference or collection of references can be used
in ODBs, but the basic relational model only support
single valued references. Hence, representation of many
to many relationships are not straight forward in relational
model, a separate relation should be created to represent
M:N relationships.
• However, mapping of binary relationships in ODBs is not
a direct process. Therefore, designer should specify
which side should possess the attributes.
1
© e-Learning Centre, UCSC 3
Object databases and Relational databases
• Handling Inheritance
• In ODB a construct is already available in the inner-
workings for handling inheritance. But basic relational
model does not have such options to handle inheritance.
• Specifying Operations
• In ODB, operations should be designed during the design,
as a part of class specification. Relational model does not
require the designed to specify the operations during the
design phase.
• Relational model supports ad-hoc queries while ad-hoc
queries will violate the encapsulation in ODBs.
1
© e-Learning Centre, UCSC 3
XML and Relational databases
• Relationships
• XML databases follow a hierarchical tree structure with
simple and composite elements and attributes
representing relationships. But relational databases have
relationships among tables where one table is the parent
table, and the other table is the dependent table.
• Self - Describing Data
• In XML databases, the tags define both the meaning and
explanation of the data items together with the data
values. Hence different data types are possible within a
single document. In relational databases, data in a single
column should be of the same type and column definition
defines the data definition.
1
© e-Learning Centre, UCSC 4
XML and Relational databases
Inherent Ordering
• In XML databases, the order of the data items is defined
by the ordering of the tags. The document does not
include any other type of ordering. But in relational
databases, unless an order by clause is given, the
ordering of the data rows is according to the row ordering
inside tables.
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
Customer
BELONGS_TO
BILLED_TO
PURCHASED
Address OrderPayment
Product
PAID_WITH
SHIPPED_TO PART_OF
Order
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
Schemalessness in NoSQL
• NoSQL databases have no schema; useful when we have
to work with nonuniform data.
• A key is used to store data in a key-value store.
• Since a document database achieves the same and
therefore, we have no restrictions on the document
structure.
• We can store data in columns in Column-family databases.
1
© e-Learning Centre, UCSC 4
NoSQL and Relational databases
In relational databases all the data items need to be of the same data
type while in XML databases, different data types are allowed.
Statement True/False
A view is not like a relational table
Since NoSQL databases don’t have views, they
cannot have precomputed and cached queries
Graph databases organise data into node and
edge graphs
Storage model describes how the database stores
and manipulates the data internally
An aggregate is a unit for data manipulation and
management of consistency.
1
© e-Learning Centre, UCSC 5
Summary
Major concepts of object-oriented, XML, and NoSQL
databases
Origins of NoSQL
NoSQL Databases
Data models in NoSQL
1
© e-Learning Centre, UCSC 5
Summary
Contrast and compare relational databases concepts
and non-relational databases
Object DB and
Relational DB
1
© e-Learning Centre, UCSC 5