This document discusses relational and non-relational databases. It begins by introducing NoSQL databases and some of their key characteristics like not requiring a fixed schema and avoiding joins. It then discusses why NoSQL databases became popular for companies dealing with huge data volumes due to limitations of scaling relational databases. The document covers different types of NoSQL databases like key-value, column-oriented, graph and document-oriented databases. It also discusses concepts like eventual consistency, ACID properties, and the CAP theorem in relation to NoSQL databases.

1. Relational and Non-
Relational Database
Dr. Zainab Namh
Lect. 9
Relational vs
Non –
Relational
Database

2. Introduction to NoSQL?
2

3. NoSQL
• NoSQL is a non-relational DMS, that does not require a
fixed schema, avoids joins, and is easy to scale.
• NoSQL database is used 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, Google that
collect terabytes of user data every single day.
• NoSQL database stands for "Not Only SQL" or "Not SQL“
Though a better term would NoREL.
• Carl Strozz introduced the NoSQL concept in 1998.
3

4. What is Big Data?
• A term for data sets that are so large that traditional
methods storage and processing are inadequate.
• Massive increase in data volume within the last decade or
so
• Social networks, search engines, etc.
• Challenges in storage, capture, analysis, transfer, etc.
4

5. Advantages and Limitations of
RDBMS
• Better for relational data
• Normalization
• Well known standard language (SQL)
• ACID Compliance
However
• No flexibility in choosing the right DB for the right
application
• Expensive if runs across a cluster
• Integrity is more important than availability and low
latency 5

6. 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."
6

7. Horizontal vs Vertical scaling
7

8. 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
• Doesn't require data normalization
• No complex features like query languages, referential integrity
joins and 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
8

9. NoSQL – Data Structure
9

10. Features of NoSQL
• 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
10

11. What is the CAP Theorem?
• CAP theorem is also called brewer's theorem. It states
that is impossible for a distributed data store to offer more
than two out of three guarantees:
• Consistency
• Availability
• Partition Tolerance
• As soon as you partition a DB
the data might either:
• Become inconsistent –
one replication holds different data from another
• Become unavailable – to keep consistency, we must propagate
updates, which takes time
11

12. What is the CAP Theorem?
• Consistency:
• The data should remain consistent even after the execution of an
operation.
• This means once data is written, any future read request should
contain that data.
• For example, after updating the order status, all the clients
should be able to see the same data.
12

13. What is the CAP Theorem?
• Availability:
• The database should always be available and responsive. It
should not have any downtime.
• Partition Tolerance:
• Partition Tolerance means that the system should continue to
function even if the communication among the servers is not
stable.
• For example, the servers can be partitioned into multiple groups
which may not communicate with each other.
• Here, if part of the database is unavailable, other parts are
always unaffected.
13

14. Eventual Consistency - BASE
• BASE: Basically Available, Soft state, Eventual
consistency
• Basically available means DB is available all the time as
per CAP theorem
• Soft state means even without an input; the system state
may change
• Eventual consistency means that the system will become
consistent over time
14

15. Eventual Consistency Example
• If you pay some money into your bank account, you don’t
want some cash machines to know its there and others not
to
• But if you post something on Facebook, you might put up
with the fact that a friend in the UK can see it for a
moment while an American friend, looking at a slightly
older replication cannot. He’ll see it eventually
15

16. ACID vs BASE
16

17. NoSQL database types
• There are mainly four categories of NoSQL databases.
Each of these categories has its unique attributes and
limitations:
1. Key-value Pair Based
2. Column-oriented
3. Graphs based
4. Document-oriented
• No specific database is better to solve all problems. You
should select a database based on your product needs.
17

18. Key Value Store NoSQL Database
• Data is stored in key/value pairs. It is designed in such a
way to handle lots of data and heavy load.
• Key-value pair storage databases store data as a hash
table where each key is unique, and the value can be a
JSON (JavaScript Object Notation), BLOB(Binary Large
Objects), string, etc.
• For example, a key-value pair may contain a key like
"Website" associated with a value like "Guru99".
• When we try and reflect back on the CAP theorem, it
becomes quite clear that key value stores are great around
the Availability and Partition aspects but definitely lack
in Consistency.
18

19. Example
19

20. Column-based NoSQL Database
• Column stores in NoSQL are similar at first appearance to
traditional relational DBMS. The concepts of rows and
columns are still there. You also define column families
before loading data into the database, meaning that the
structure of data must be known in advance.
• However, column stores organize data differently than
relational databases do. Instead of storing data in a row
for fast access, data is organized for fast column
operations.
• They deliver high performance on aggregation queries like
SUM, COUNT, AVG, MIN etc. as the data is readily
available in a column.
20

21. Column-based NoSQL Database
21

22. Document Store NoSQL Database
• Document-Oriented NoSQL DB stores and retrieves data
as a key value pair but the value part is stored as a
document. The document is stored in JSON or XML
formats.
22

23. NoSQL - Example
23

24. NoSQL - Example
24

25. Graph-Based NoSQL Database
• A graph type database stores entities as well the relations
amongst those entities. The entity is stored as a node with
the relationship as edges. An edge gives a relationship
between nodes. Every node and edge has a unique
identifier.
25

26. Disadvantages of NoSQL
• No standardization rules
• Limited query capabilities
• RDBMS databases and tools are comparatively mature
• It does not offer any traditional database capabilities, like
consistency when multiple transactions are performed
simultaneously.
• When the volume of data increases it is difficult to
maintain unique values as keys become difficult
• Doesn't work as well with relational data
26

27. NoSQL Example – Review DB
Product: iPhone 5
Price: £500
Camera: Fine
Screen: Very good
Accessories: Headphone, Case, ....
Product: iPhone 5
Price: £500
Camera: Excellent
Screen: Poor in sunshine
Operating system: Easy to use
27

28. Example Review in JSON
{
Id:847543,
Name:iPhone5,
Features:[GPS,Retina Display,Siri],
Reviews:[
{Reviewer:458743,Date:12.4.1013,Speed:Slow},
{Reviewer:636534,Date:2.5.1013,Camera:Great},
]
}
28

29. Possible Review DB Design
• For our product review database, potential units to
aggregate are:
– Users – keep all a person’s reviews together
– Products – keep all the reviews of a product together
29

30. Review Queries?
• What are Common Queries?
• Which design you choose depends on a few things, for
example, what is the most common query?
– List all reviews from a given customer
– List all reviews of a given product
– Find all products that are ‘fast’
30

31. Transaction
Concurrency
ACID
Recovery
31

32. ACID- Atomic, Consistent, Isolated,
Durable
• Atomicity: A transaction is an atomic unit of processing; it
is either performed in its entirety or not performed at all.
• Consistency preservation: A transaction is consistency
preserving if its complete execution take(s) the database
from one consistent state to another.
• Isolation: A transaction should appear as though it is
being executed in isolation from other transactions. That
is, the execution of a transaction should not be interfered
with by any other transactions executing concurrently.
• Durability or permanency: The changes applied to the
database by a committed transaction must persist in the
database. These changes must not be lost because of any
failure. 32

33. What is a Transaction?
• A transaction is a logical unit of database processing (or a
logical unit of work on the database) that includes one or
more database access operations:
– insertion,
– deletion,
– modification, or
– retrieval operations.
33

34. What is a Transaction?
• If the database operations in a transaction do not update
the database but only retrieve data, the transaction is
called a read-only transaction.
• Read-only transaction - do not changes the state of a
database, only retrieves data.
• A database system interprets a transaction not as an
application program but a logical sequence of read and
write operations.
34

35. Concurrent and Interleaving
• Multiprogramming operating systems execute some
commands from one process, then suspend this process
and execute some commands from the next process, and so
on. This type of process execution is called interleaving.
• After a while, the execution of the first process is resumed
at the point where it was suspended.
• Interleaving keeps the CPU busy when a process requires
an input or output operation. The CPU is switched to
execute another process rather than remaining idle during
I/O time.
• Interleaving also prevents a long process from delaying
other processes.
35

36. Why Interleave?
36

37. Why concurrency control is needed?
37

38. Why Recovery Is Needed?
• Whenever a transaction is submitted to a DBMS for
execution, the system is responsible for making sure that
either
(1) all the operations in the transaction are completed
successfully and their effect is recorded permanently in the
database, or
(2) the transaction has no effect whatsoever on the
database or on any other transactions.
• For the purpose of recovery and concurrency control, we
are mainly interested in the read_item and write_item
operations of the transactions, as well as the commit and
abort operations.
38

39. Successful Schedule
39

40. References
• https://www.guru99.com/nosql-tutorial.html
• Introduction to NoSQL – Kevin Swingler – 2017.
• Advanced Database Lectures – Prof. Musbah Aqel – 2011.
40