What is NoSQL?

NoSQL means “Not only SQL.”

• It’s more than rows in tables—NoSQL systems store and retrieve data from many formats:
key-value stores, graph databases, column-family (Bigtable) stores, document stores, and
even rows in tables.
• It’s free of joins—NoSQL systems allow you to extract your data using simple interfaces
without joins.
• It’s schema-free—NoSQL systems allow you to drag-and-drop your data into a folder and
then query it without creating an entity-relational model.
• It works on many processors—NoSQL systems allow you to store your database on
multiple processors and maintain high-speed performance.
• It uses shared-nothing commodity computers—Most (but not all) NoSQL systems leverage
low-cost commodity processors that have separate RAM and disk.
• It supports linear scalability—When you add more processors, you get a consistent
increase in performance.
• It’s innovative—NoSQL offers options to a single way of storing, retrieving, and
manipulating data.
what NoSQL is not
• It’s not about the SQL language—The definition of NoSQL isn’t an application that uses a
language other than SQL. SQL as well as other query languages are used with NoSQL
databases.
• It’s not only open source—Although many NoSQL systems have an open source model,
commercial products use NOSQL concepts as well as open source initiatives.
• It’s not only big data—Many, but not all, NoSQL applications are driven by the inability of a
current application to efficiently scale when big data is an issue. Though volume and velocity
are important, NoSQL also focuses on variability and agility.
• It’s not about cloud computing—Many NoSQL systems reside in the cloud to take advantage
of its ability to rapidly scale when the situation dictates. NoSQL systems can run in the cloud
as well as in your corporate data center.
• It’s not about a clever use of RAM and SSD—Many NoSQL systems focus on the efficient use
of RAM or solid state disks to increase performance. Though this is important, NoSQL
systems can run on standard hardware.
NoSQL limitations
• ACID transactions can be done only within a document at the
database level. Other transactions must be done at the application
level.
• Document stores don’t provide fine-grained security at the element
level.
• NoSQL systems are new and additional training may be required.
• The document store has its own proprietary nonstandard query
language, which prohibits portability.
• The document store won’t work with existing reporting and OLAP
tools.
Non-RDBMS transaction control
using BASE
• Basic availability allows systems to be temporarily inconsistent so
that transactions are manageable. In BASE systems, the information
and service capability are “basically available.”
• Soft-state recognizes that some inaccuracy is temporarily allowed
and data may change while being used to reduce the amount of
consumed resources.
• Eventual consistency means eventually, when all service logic is
executed, the system is left in a consistent state.
In NoSQL databases, BASE is a consistency model that is different from the traditional
ACID model used in relational databases.

Basically Available
• The system guarantees availability.
• It will always respond to a request (success or failure).
• Even if some nodes fail, the system still works.
Soft State
• The system state may change over time, even without new input.
• Because of data replication, different nodes may temporarily have different values.
• The system does not require immediate consistency.
Eventual Consistency
• If no new updates are made, the system will eventually become consistent.
• After some time, all replicas will contain the same data.
• Unlike RDBMSs that focus on consistency, BASE systems focus on
availability.
• They relax the rules and allow reports to run even if not all portions of
the database are synchronized.
• BASE systems are considered optimistic in that they assume that
eventually all systems will catch up and become consistent.
• BASE systems tend to be simpler and faster because they don’t have
to write code that deals with locking and unlocking resources. Their
mission is to keep the process moving and deal with broken parts at a
later time.
• BASE systems are ideal for web storefronts, where filling a shopping
cart and placing an order is the main priority.
ACID Vs BASE

•Database systems traditionally support ACID requirements:

– Atomicity, Consistency, Isolation, Durability

•In a distributed web applications the focus shifts to:

– Consistency, Availability, Partition tolerance

• Thus, distributed NoSQL systems are typically said to

support some form of BASE:
– Basic Availability
– Soft state
– Eventual consistency*
Some Terminologies
Some Terminologies
• Each independent computer is called a node. Each node has its own
local RAM and disk.
• Nodes are grouped together in racks that have high-bandwidth
connections between all the nodes within a rack.
• Racks are grouped together to form a database cluster within a data
center.
• A single data center location may contain many database clus ters.
Brewer’s CAP theorem
• The CAP theorem states that any distributed database system can have at
most two of the following three desirable properties:
• Consistency—Having a single, up-to-date, readable version of your data
available to all clients. Consistency here is concerned with multiple clients
reading the same items from replicated partitions and getting consistent
results.
• High availability—Knowing that the distributed database will always allow
data base clients to update items without delay. Internal communication
failures between replicated data shouldn’t prevent updates.
• Partition tolerance—The ability of the system to keep responding to client
requests even if there’s a communication failure between database
partitions.
Consistency (C)
• Every read receives the most recent write.
• All clients see the same data at the same time.
• Similar to strong consistency in ACID systems.
• If one client updates a value, all other clients immediately see the updated value.
Availability (A)
• Every request receives a response (success/failure).
• The system does not reject requests.
• The database remains operational.
• Even if some servers fail, the system continues serving requests.
Partition Tolerance (P)
• A partition means a network failure that breaks communication between two or more
nodes in a distributed system.
• The system continues to function even if there is a network failure between nodes.
• Communication between partitions may fail, but the system still responds.
• Very important in distributed systems across data centers.
CAP
CAP theorem says that in a distributed system, when a network
partition (failure) happens, you cannot have both:
• Consistency (C) – all clients see the same, latest data
• Availability (A) – every request gets a response
• Partition tolerance (P) – system continues despite network failure

In real systems, Partition (P) is unavoidable, so the real choice is:

Consistency vs Availability
NOSQL
NoSQL databases shine when you need:
• Massive scalability
• High availability
• Flexible / evolving schemas
• Fast reads & writes
• Distributed systems (CAP trade-offs)
Major Use Cases of NoSQL
• Big Data & Real-Time Analytics
• Web & Mobile Applications
• High-Availability Systems
• Caching & Session Management
• Social Networks
• Graph-Based Applications
• IoT & Time-Series Data
• Content Delivery & Media Storage
What is NoSQL?
• NoSQL database stands for “Not Only SQL” or “Not SQL.”
• It is a non-relational Data Management System, that does not require a
fixed schema.
• It avoids joins, and is easy to scale. The major purpose of using a NoSQL
database is for distributed data stores with humongous data storage
needs.
• NoSQL is used for Big data and real-time web apps.
• For example, companies like Twitter, Facebook and Google collect
terabytes of user data every single day.
What is NoSQL?
Why NoSQL?
► The concept of NoSQL databases became popular with Internet giants
like Google, Facebook, Amazon, etc. who deal with huge volumes of
data.
► The system response time becomes slow when you use RDBMS for
massive volumes of data.
► To resolve this problem, we could “scale up” our systems by upgrading
our existing hardware. This process is expensive.
► The alternative for this issue is to distribute database load on multiple
hosts whenever the load increases. This method is known as “scaling
out.”
► NoSQL database is non-relational, so it scales out better than relational
databases as they are designed with web applications in mind.
Brief History of NoSQL
Databases
• 1998- Carlo Strozzi use the term NoSQL for his lightweight, open-source
relational database
• 2000- Graph database Neo4j is launched
• 2004- Google BigTable is launched
• 2005- CouchDB is launched
• 2007- The research paper on Amazon Dynamo is released
• 2008- Facebooks open sources the Cassandra project
• 2009- The term NoSQL was reintroduced
Characteristics of NOSQL

1. Scalability: In NOSQL systems horizontal

scalability is generally used where the distributed
system is expanded by adding more nodes for data
storage and processing as the volume
of data grows.
2. Availability, Replication and Eventual
Consistency:
Features of NoSQL
► Non-relational
► NoSQL databases never follow the relational model
► Never provide tables with flat fixed-column records
► Work with self-contained aggregates or BLOBs
► Doesn’t require object-relational mapping and data normalization
► No complex features like query languages, query planners,referential
integrity joins, ACID
► Schema-free
► NoSQL databases are either schema-free or have relaxed schemas
► Do not require any sort of definition of the schema of the data
► Offers heterogeneous structures of data in the same domain
Features of NoSQL
► Simple API
► Offers easy to use interfaces for storage and querying data provided
► APIs allow low-level data manipulation & selection methods
► Text-based protocols mostly used with HTTP REST with JSON
► Mostly used no standard based NoSQL query language
► Web-enabled databases running as internet-facing services
► Distributed
► Multiple NoSQL databases can be executed in a distributed fashion
► Offers auto-scaling and fail-over capabilities
► Often ACID concept can be sacrificed for scalability and throughput
► Mostly no synchronous replication between distributed nodes
Asynchronous Multi- Master Replication, peer-to-peer, HDFS Replication
► Only providing eventual consistency
► Shared Nothing Architecture. This enables less coordination and higher
Types of NoSQL Databases
► NoSQL Databases are mainly categorized into four types:
► Key-value Pair Based
► Column-oriented
► Graphs based
► Document-oriented
KEY_VALUE DATABASE
► A key-value database (sometimes called a key-value store) uses a simple
key-value method to store data.
► These databases contain a simple string (the key) that is always unique and an
arbitrary large data field (the value).
► They are easy to design and implement.
KEY_VALUE DATABASE
► As the name suggests, this type of NoSQL database implements a hash
table to store unique keys along with the pointers to the corresponding
data values.
► The values can be of scalar data types such as integers or complex
structures such as JSON, lists, BLOB, and so on.
► A value can be stored as an integer, a string, JSON, or an array—with a
key
used to reference that value.
► It typically offers excellent performance and can be optimized to fit an
organization’s needs.
► Key-value stores have no query language but they do provide a way to add and
remove key-value pairs.
► Values cannot be queried or searched upon. Only the key can be queried.
KEY_VALUE DATABASE
KEY_VALUE DATABASE
Primary operations:
– insert(key,value)
– delete(key)
– update(key,value)
– lookup(key)

•Additional operations:
– variations on the above, e.g., reverse lookup
(REVERSE INDEX)
– iterators
When to use a Key_Value
Database
► When your application needs to handle lots of small continuous reads and
writes, that may be volatile. Key-value databases offer fast in-memory access.
► When storing basic information, such as customer details; storing webpages
with the URL as the key and the webpage as the value; storing shopping-cart
contents, product categories, e-commerce product details
► For applications that don’t require frequent updates or need to support
complex queries.
Use cases for Key_Value
Databases
► Session management on a large scale.
► Using cache to accelerate application responses.
► Storing personal data on specific users.
► Product recommendations, storing personalized lists of items for
individual customers.
► Managing each player’s session in massive multiplayer online games.
► Redis, Dynamo, Riak are some NoSQL examples of key-value store
DataBases.
REmote DIctionary Server-Redis

Redis is an advanced key-value store that can function

as a NoSQL database or as a memory-cache store to
improve performance when serving data that is stored
in system memory.
Logical Data Model
What is a key-value store?
• A key-value store is a simple database that when presented with a simple
string (the key) returns an arbitrary large BLOB of data (the value).
• Key-value stores have no query language; they provide a way to add and
remove key-value pairs (a combination of key and value where the key is
bound to the value until a new value is assigned) into/from a database.
• A key-value store is like a dictionary. The dictionary is a simple key-value
store where word entries represent keys and definitions represent values.
• Like the dictionary, a key-value store is also indexed by the key; the key
points directly to the value, resulting in rapid retrieval, regardless of the
number of items in your store.
Benefits of using a key-value

• Their simplicity and generality save you time and money by mov ing
your focus from architectural design to reducing your data services
costs through
• Precision service levels
• Precision service monitoring and notification
• Scalability and reliability
• Portability and lower operational costs
Key Valu Stores
Instead of using a query language, application developers access and
manipulate a key-value store with the put, get, and delete functions,
• put($key as xs:string, $value as item()) adds a new key-value pair to
the table and will update a value if this key is already present.
• get($key as xs:string) as item() returns the value for any given key, or
it may return an error message if there’s no key in the key-value store.
• delete($key as xs:string) removes a key and its value from the table,
or it many return an error message if there’s no key in the key-value
store.
Simple Application in Redis
• CREATE
HSET student:101 name "Ann" age 21 branch "CSE" marks 90
• READ – Retrieve Student Details
HGETALL student:101
HGET student:101 name
• UPDATE – Modify Student Marks
HSET student:101 marks 95
• DELETE – Remove Student Record
DEL student:101
COLUMN-ORIENTED DATABASE
► While a relational database stores data in rows and reads data row by row, a
column store is organized as a set of columns.
► When you want to run analytics on a small number of columns, you can
read those columns directly without consuming memory with the unwanted
data.
► Columns are often of the same type and benefit from more efficient
compression, making reads even faster.
► Columnar databases can quickly aggregate the value of a given column
(adding up the total sales for the year, for example). Use cases include
analytics.
COLUMN-ORIENTED DATABASE
COLUMN-ORIENTED DATABASE
► Column databases use the concept of keyspace, which is sort of like a
schema in relational models.
► This keyspace contains all the column families, which then contain rows, which
then contain columns.
COLUMN-ORIENTED DATABASE
► If we take a specific row as an example:

► The Row Key is exactly that: the specific identifier of that row and is always
unique.
► The column contains the name, value, and timestamp, so that’s straightforward.
The name/value pair is also straight forward, and the timestamp is the date and
time the data was entered into the database.
► Some examples of column-store databases include Casandra, CosmoDB,
Bigtable, and HBase.
COLUMN-ORIENTED DATABASE
Cassandra- Column Database
Cluster

● Cassandra database is distributed over several machines that operate together.

● The outermost container is known as the Cluster.
● For failure handling, every node contains a replica, and in case of a failure, the
replica takes charge.
● Cassandra arranges the nodes in a cluster, in a ring format, and assigns data to
them.
Keyspace

● Keyspace is the outermost container for data in Cassandra

Column Family

● A column family is a container for an ordered collection of rows.

Column Database

•The basic data model:

– Database is a collection of key/value pairs
– Key consists of 3 parts – a row key, a column
key, and a time-stamp (i.e., the version)
– Flexible schema - the set of columns is not
fixed, and may differ from row-to-row

•One last column detail:

– Column key consists of two parts – a column
 f.e. Cassandra Row
(Facebook, Netflix, spotify)
• the value of a row is
itself a sequence of
key-value pairs
• such nested key-value
pairs are columns
• key = column name
• a row must contain at
least 1 column
Examples of Columns
 • creating tables:

Cassandra CREATE TABLE users(

CREATE TABLE tweets(
email varchar,
Query bio varchar,
email varchar,

Language - birthday timestamp,

time_posted timestamp,

CQL active boolean,

tweet varchar,

PRIMARY KEY (email,

time_posted));
PRIMARY KEY (email));
 • inserting data
INSERT INTO users (email, bio, birthday, active)
Cassandra VALUES (‘[Link]@[Link]’, ‘BT360
Teammate’,

Query 516513600000, true);

Language - ○ ** timestamp fields are

specified in milliseconds since
CQL epoch
 • querying tables
• SELECT expression reads one or more
records from Cassandra column family
Cassandra and returns a result-set of rows

Query SELECT * FROM users;

Language - SELECT email FROM users WHERE active = true;

CQL
Use cases for Column-Oriented
Databases
► Developers mainly use column databases in:
► Content management systems
► Blogging platforms
► Systems that maintain counters
► Services that have expiring usage
► Systems that require heavy write requests (like log aggregators)
Benefits of Column-Oriented Databases
► There are several benefits that go along with columnar databases:
► Column stores are excellent at compression and therefore are efficient in
terms of
storage.
► You can reduce disk resources while holding massive amounts of
information in a single column
► Since a majority of the information is stored in a column, aggregation
queries are quite fast, which is important for projects that require large
amounts of queries in a small amount of time.
► Scalability is excellent with column-store databases.
► They can be expanded nearly infinitely, and are often spread across large clusters
of
machines, even numbering in thousands.
► That also means that they are great for Massive Parallel Processing
Benefits of Column-Oriented Databases
► Load times are similarly excellent, as you can easily load a billion-
row table in a few seconds.
► You can load and query nearly instantly.
► Large amounts of flexibility as columns do not necessarily have to
look like each other.
► You can add new and different columns without disrupting the whole
database.
 RDBMS Cassandra
RDBMS deals with structured data. Cassandra deals with unstructured data.

It has a fixed schema. Cassandra has a flexible schema.

In RDBMS, a table is an array of arrays. (ROW x In Cassandra, a table is a list of “nested key-
COLUMN) value pairs”. (ROW x COLUMN key x COLUMN
value)

Database is the outermost container that Keyspace is the outermost container that
contains data corresponding to an application. contains data corresponding to an application.

Tables are the entities of a database. Tables or column families are the entity of a
keyspace.

Row is an individual record in RDBMS. Row is a unit of replication in Cassandra.

Column represents the attributes of a relation. Column is a unit of storage in Cassandra.

DOCUMENT-ORIENTED
DATABASES
► Is a modernized way of storing data as JSON rather than basic
columns/rows — i.e. storing data in its native form.
► This storage system lets you retrieve, store, and manage document-
oriented information
► It’s a very popular category of modern NoSQL databases, used by the likes of
MongoDB, Cosmos DB, DocumentDB, SimpleDB, PostgreSQL, OrientDB,
Elasticsearch and RavenDB.

► This is an example of a document that might appear

in a
document database like MongoDB.
► This sample document represents a company
contact card, describing an employee called
Sammy:
 Document Store
The basic data model:
● The general notion of a document – words, phrases, sentences, paragraphs,
sections,
subsections, footnotes, etc.
● Flexible schema – subcomponent structure may be nested, and vary from
document-to-document.
● Metadata – title, author, date, embedded tags, etc.
● Key/identifier.
● Formats vary greatly – PDF, XML, JSON, BSON, plain text, various binary,
scanned image.
 RDBMS MongoDB
Database ➜ Database
Table ➜ Collection
Row ➜ Document
Index ➜ Index
Join ➜ Embedded
Document
Foreign Key ➜ Reference
 There are some patterns
●Embedding

●Linking
Embedding & Linking
 JSON
🠶 “JavaScript Object Notation”
🠶 Easy for humans to write/read, easy for computers
to parse/generate
🠶 Objects can be nested
🠶 Built on
🠶 name/value pairs
🠶 Ordered list of values

[Link]
 BSON
• “Binary JSON”
• Binary-encoded serialization of JSON-like docs
• Also allows “referencing”
• Embedded structure reduces need for joins
• Goals
– Lightweight
– Traversable
– Efficient (decoding and encoding)
[Link]
{ BSON Example
"_id" : "37010"
"city" : "ADAMS",
"pop" : 2660,
"state" : "TN",
“councilman” : {
name: “John Smith”
address: “13 Scenic Way”
}
}
CRUD Query Language
Create, Read, Update, Delete
 CRUD: Using the Shell
To insert documents into a collection/make a new collection:

db.<collection>.insert(<document>)
<=>
INSERT INTO <table>
VALUES(<attributevalues>);
 CRUD: Inserting Data
Insert one document
db.<collection>.insert({<field>:<value>})

Inserting a document with a field name new to the collection is inherently

supported by the BSON model.

To insert multiple documents, use an array.

 CRUD: Querying
🠶 Done on collections.
🠶 Get all docs: db.<collection>.find()
🠶 Returns a cursor, which is iterated over shell to display first 20 results.
🠶 Add .limit(<number>) to limit results
🠶 SELECT * FROM <table>;

🠶 Get one doc: db.<collection>.findOne()

 CRUD: Querying
To match a specific value:
db.<collection>.find({<field>:<value>})
“AND”
db.<collection>.find({<field1>:<value1>,
<field2>:<value2>
})
SELECT *
FROM <table>
WHERE <field1> = <value1> AND <field2> = <value2>;
 CRUD: Querying
OR
db.<collection>.find({ $or: [
<field>:<value1>
<field>:<value2> ]
})
SELECT *
FROM <table>
WHERE <field> = <value1> OR <field> = <value2>;

Checking for multiple values of same field

db.<collection>.find({<field>: {$in [<value>, <value>]}})
 CRUD:
Including/excluding document fields
Querying
db.<collection>.find({<field1>:<value>}, {<field2>: 0})

SELECT field1
FROM <table>;

db.<collection>.find({<field>:<value>}, {<field2>: 1})

Find documents with or w/o field
db.<collection>.find({<field>: { $exists: true}})
 CRUD: Updating
db.<collection>.update(
{<field1>:<value1>}, //all docs in which field = value
{$set: {<field2>:<value2>}}, //set field to value
{multi:true} ) //update multiple docs

upsert: if true, creates a new doc when none matches search

criteria.

UPDATE <table>
SET <field2> = <value2>
WHERE <field1> = <value1>;
 CRUD: Updating
To remove a field
db.<collection>.update({<field>:<value>},
{ $unset: { <field>: 1}})

Replace all field-value pairs

db.<collection>.update({<field>:<value>},
{ <field>:<value>,
<field>:<value>})
*NOTE: This overwrites ALL the contents of a document,
even removing fields.
 CRUD: Removal
Remove all records where field = value
db.<collection>.remove({<field>:<value>})

DELETE FROM <table>

WHERE <field> = <value>;
As above, but only remove first document

db.<collection>.remove({<field>:<value>}, true)
DOCUMENT-ORIENTED
DATABASES

► Notice that the document is written as a JSON object.

► JSON is a human-readable data format that has become quite popular in recent
years.
► While many different formats can be used to represent data within a
document database, such as XML or YAML, JSON is one of the most
common choices.
► For example, MongoDB adopted JSON as the primary data format to
define and
Relational Document Database
Benefits of Document Databases
► A few of the most important benefits are:
► Flexibility and adaptability: with a high level of control over the data
structure, document databases enable experimentation and adaptation
to new emerging requirements.
► New fields can be added right away and existing ones can be changed
any time.
► It’s up to the developer to decide whether old documents must be
amended or the
change can be implemented only going forward.
► Ability to manage structured and unstructured data: Document
databases can be used to handle structured data as well, but they’re also
quite useful for storing unstructured data where necessary.
► Scalability by design: Conversely, document databases are designed as
distributed systems that instead allow you to scale horizontally (meaning
that you split a single database up across multiple servers).
GRAPH_BASED NoSQL
► Graph databases are generally straightforward in how they’re
structured though. They primarily are composed of two
components:
► The Node
► This is the actual piece of data itself.
► It can be the number of viewers of a youtube video, the number of people
who have read a tweet, or it could even be basic information such as
people’s names, addresses, and so forth.
► The Edge
► This explains the actual relationship between two nodes.
► Interestingly enough, edges can also have their own pieces of information,
such as the nature of the relation between two nodes. Similarly, edges
might also have directions describing the flow of said data.
 Graph Databases
● We propose a new kind of Database: Graph Databases (GDB)
as a solution to Problems [P1],[P2] and [P3].
● In order to define the GDB we will specify:
○ The Data Definition Language (DDL)
○ The Query Language (more generally DML)
○ Informal Semantics of the above languages
● We will also show how to convert existing DBs (RDBMS) into the GDB
DDL to facilitate the transition to GDBs
 Goals and Design Choice

● Goals
○ Declarativity
○ Change
● Design Choice : Have unique instance identifiers vs. having
foreign keys
○ Close in Spirit to OO
○ Will allow us to cope easier with Change
○ Declarativity is an issue in OO, but not for GDB as we will show
 Database Representation
● Sailors(sid:integer, sname:char(10), rating: integer, age:real)
● Boats(bid:integer, bname:char(10), color:char(10))
● Reserve(sid:integer, bid:integer, day:date)

Sailors Reserves Boats

sid sname rating age sid bid day bid bname color

22 dustin 7 45.0 101 Interlake red

22 101 10/10/96
31 lubber 8 55.5 102 Clipper green
58 103 11/12/96
58 rusty 10 35.0 103 Marine red
 22
Graph Representation sid

name dustin
IOF ID1
rating 7

IOF Sailor age 45.0

TBL s

sid 31

IOF
IOF lubber
name
IOF ID2
Boats
rating 8
Reserves
IOF IOF age 55.5

IOF ID8
ID6 ID3
…
ID4 ID5 : ID7 :
: :
Foreign Keys
sid 22

name dustin
ID1
rating 7

age 45.0
Sailor

sid 22

day 10/10/96
ID4
bid 101
Boat
bid 101
ID6
bname Interlake

color red
 Data Representation in the GDB DDL
Name1 Val1

Name2 Val2
ID
……
NameN ValN

● ID:(Name1=Val1,…,NameN=ValN)
Examples:
ID1:(sid=22, name=“Dustin”, rating=7, age=45.0)
ID4:(sailor=ID1, day=“10/10/96”, boat=ID6)
ID6:(bid=101, bname=“Interlake”, color=“red”)
 Defining New Concepts in GDB DDL– Grandson
P P
er er
Person so
so
nI nI
IOF O O
F F
_I S _I S _I
D GrSon _ID2 :- _ID1 o D o D
1 n 3 n 2

GrSon
_ID1:(GrSon=_ID2) :- _ID1:
(IOF=“Person”,Son=_ID3),
_ID3:(IOF=“Person”, Son=_ID2),
_ID2:(IOF=“Person”).
 [DML-QL] Writing simple queries:
•The names of all sailors who have reserved a red boat

Sailor
_X _X Boats
s

Name IOF Name IOF

_ID :- _ID Boat _ID1 Color Red

_ID:(Name = _X) :-
_ID:(IOF = Sailors, Boat = _ID1, Name = _X),
_ID1:(IOF = Boats, Color = Red).
 Informal Semantics

● Three kinds of Definitions

○ Facts:
■ G1. [Extensional definition]
○ Definitions:
■ G1 :- G2. [Intensional definition]
■ G1 :- PROC f(x1,…,xn). [Procedural definition]
● Queries = Graphs to be Matched = QG
○ The same as a definition: Query :- QG.
Informal Semantics - Picture Query

Query match

Facts
Extended Graph
 RDBMS => GDB
● Sailors(sid:integer, sname:char(10), rating: integer, age:real)
● Boats(bid:integer, bname:char(10), color:char(10))
● Reserve(sid:integer, bid:integer, day:date)

Sailors Reserves Boats

sid sname rating age sid bid day bid bname color

22 dustin 7 45.0 101 Interlake red

22 101 10/10/96
31 lubber 8 55.5 102 Clipper green
58 103 11/12/96
58 rusty 10 35.0 103 Marine red
 DML - Updates
● Inline Query
○ _X : [ _ID: (IOF = Sailor, sname = lubber, rating = _X)]
● Updates: MODIFY (QryGraph, UpdList)
○ Add to all GrandSons the money of the Grandparent as a potential
inheritance.
○ MODIFY ( _ID : (GrSon = _ID1), (=> NEWID:(IOF
= POT_INHER, BENFICIARY = _ID1, AMOUNT = _AMNT: [ _ID:
(Money = _AMNT )]) ))
○.
 Change

Boo
k

IOF
Titl Database
e s
_ID
Aut Ramakris
hor han

Aut
Gehrke
hor
G
en
Change
e_
ex
I
O
F
va
_I 0. I _I va
lu x
D 7 O D lu
e 1
E FI 1_I eva
x x
O D lu
p 2:
FI 2
_I e
va
x
O D lu
N
F n e
Aggregate
Operation
 High Order Queries

Find all the fields from Tables that contain the name John.

_ID:(Name=_X) :-
_ID1:(IOF=Tables),
_ID2:(IOF=_ID1, _X=“John”).
 GDB vs. OO, XML, OR, CG, …
● GDB are close in spirit to OO but not the same (GDB : no
encapsulation + more IDs).
● Close To Datalog but with IDs(links) vs foreign keys
● The same for ORDBMs and somewhat XML
● Close to Conceptual Graphs But CG do not have IDs
● We can also use foreign keys: _ID:[ _ID(IOF =
Sailors, sname = lubber)].
 OO vs. GDB

OO GDB
P
er
ID
so
1 nI
Class: Person O ag 4 C
age: 42 F
I e 2 ar
name: john na Jo
D I
car m h
ID 1 O
e n FI
2 ca
Class: Car r
D
color: red 2
co
lo
r
re
d
Translating NoSQL Knowledge to Graph
► With the advent of the NoSQL movement, businesses of all sizes
have a variety of modern options from which to build solutions
relevant to their use cases.
► Calculating average income? Ask a relational database.
► Building a shopping cart? Use a key-value Store.
► Storing structured product information? Store as a document.
► Describing how a user got from point A to point B? Follow a graph.
► Examples of Graph Databases
► Neo4j, ArangoDB
GRAPH_BASED NoSQL
 ArangoDB[graph data model]
ArangoDB's, - requires two kinds of collections
— the first is the document collections (known as vertices collections in
group-theoretic language),
— the second is the edge collections.
—-- Edge collections also store documents, but they are characterized by
including two unique attributes, _from and _to for creating relations
between documents.
In practice, a document (read edge) links two documents (read vertices),
both stored in their respective collections.
This architecture is derived from the graph-theoretic concept of a
labeled, directed graph, excluding edges that can have not only labels,
but can be a complete JSON like document in itself.
Key-value vs. Graph: Data Model
Differences

Key-Value
Key-Value as
Model
Graph
Document vs. Graph: Data Model
Differences

Document as
Document Model Graph
References
► [Link]
► [Link]
► [Link]
► [Link]
atabase- [Link]
► [Link]
etailed- overview

► Also refer to the web links provided in google classroom

What is a Graph store ?
• A graph store is a system that contains a sequence of nodes and
relationships that, when combined, create a graph.
• A graph store has three data fields: nodes, relationships, and
properties.
• Graph stores are ideal when you have many items that are related to
each other in complex ways and these relationships have properties
• A graph database stores data as nodes, relationships,
and properties instead of in tables or documents.
• Graph databases are structured through nodes and relationships.
• Nodes are entities in the graph Relationships provide named
connections between two nodes
• Graph nodes are usually representations of real-world objects like
nouns. Nodes can be people, organizations, telephone numbers, web
pages, computers on a network.
• The relationships can be thought of as connections between these
objects and are typically represented as arcs (lines that connect)
between circles in diagrams.
Simple Graph Store Example-Neo4j

• Create Nodes
CREATE (s1:Student {name:"Anu", age:21})
CREATE (s2:Student {name:"Rahul", age:22})
CREATE (c1:Course {name:"DBMS"})
• Create Relationship
MATCH (s:Student {name:"Anu"}), (c:Course {name:"DBMS"}) CREATE (s)-[:ENROLLED_IN]->(c)
• Read (Find Courses of Anu)
MATCH (s:Student {name:"Anu"})-[:ENROLLED_IN]->(c) RETURN c
• Update
MATCH (s:Student {name:"Anu"}) SET [Link] = 23

Delete
MATCH (s:Student {name:"Rahul"}) DELETE s
What is a Column family store ?
• Column family systems are important NoSQL data architecture
patterns because they can scale to manage large volumes of data
Columns store databases use a concept called
a keyspace. A keyspace is kind of like a schema
in the relational model. The keyspace contains
all the column families (kind of like tables in the
relational model), which contain rows, which
contain columns.
•A column family consists of multiple rows.

•Each row can contain a different number of

columns to the other rows. And the columns
don’t have to match the columns in the
other rows (i.e. they can have different
column names, data types, etc).

•Each column is contained to its row. It

doesn’t span all rows like in a relational
database. Each column contains a
name/value pair, along with a timestamp.
•Row Key. Each row has a unique key,
which is a unique identifier for that row.

•Column. Each column contains a name,

a value, and timestamp.

•Name. This is the name of the name/value

pair.

•Value. This is the value of the name/value

pair.

•Timestamp. This provides the date and

time that the data was inserted. This can
be used to determine the most recent
version of data.
Simple Application in Apache
Cassandra
• Create Keyspace
CREATE KEYSPACE collegeWITH replication = { 'class': 'SimpleStrategy',
'replication_factor': 1
};
USE college;
CREATE TABLE student (roll INT PRIMARY KEY,name TEXT,branch TEXT,marks INT);
INSERT INTO student (roll, name, branch, marks)VALUES (101, 'Anu', 'CSE', 90);

SELECT * FROM student;

SELECT * FROM student WHERE roll = 101;
UPDATE student SET marks = 95WHERE roll = 101;
SELECT * FROM student WHERE roll = 101;
DELETE FROM student WHERE roll = 102;
TRUNCATE student;
ALTER TABLE student ADD email TEXT;
DROP TABLE student;
What is a Document Database?

• Document database (also known as a document-oriented database or

a document store) is a database that stores information in
documents.
• A document is a record in a document database. A document typically
stores information about one object and any of its related metadata.
• Documents store data in field-value pairs. The values can be a variety
of types and structures, including strings, numbers, dates, arrays, or
objects.
• Documents can be stored in formats like JSON, BSON, and XML.
Simple Application in MongoDB

db = client["college"]

collection = db["students"]

student1 = {"roll": 101,"name": "Anu","branch": "CSE","marks": 90}

collection.insert_one(student1)

collection.update_one({"roll": 101},{"$set": {"marks": 95}})

collection.delete_one({"roll": 101})