UNIT III DATA MODELS AND QUERY LANGUAGES 6

Relational Model, Document Model, Key-Value Pairs,

NoSQL, Object-Relational Mismatch, Many-to-One and
Many-to-Many Relationships, Network data models,
Schema Flexibility, Structured Query Language, Data
Locality for Queries, Declarative Queries, Graph Data
models, Cypher Query Language, Graph Queries in SQL,
The Semantic Web, CODASYL, SPARQL
Many-to-One
&
Many-to-Many
Relationships
Many-to-Many Relationships
This type of relationship exists when each of the records of the
first table can be associated with one or more records of the
second table, as well as a single record of the second table may
be related to one or more records of the first table.
A writer can write many books and one book can be written by
many writers.
Writer ID is a primary key of writer table and book ID is a primary
key of book table.
Both tables get linked by using the primary key.
Foreign key is not used in many-to-many relationships.
Many-to-One Relationships
When one or more entries in one table may be linked to
each record in the other table, this is known as a Many-
to-One relationship.
Network data model
 Network Data Model
Network data models are a way of representing data that can be
used for organizing and managing complex relationships
between various entities.
A network data model provides a dynamic framework for
understanding the intricate web of relationships within a system.
At its core, a network data model organizes data in a way that
reflects the inherent relationships between entities. Unlike the
more traditional hierarchical and relational data models, where
data is structured in tables or trees, the network model allows
for a more flexible and interconnected representation.
 Nodes and Edges
The fundamental components of a network data model are nodes and
edges.
Nodes represent entities, while edges define the relationships or
connections between these entities.
Each node can have attributes that provide additional information about
the entity it represents, and each edge can have properties describing the
nature of the relationship.
For example, a social network data model represents individuals as nodes,
and connections between them (e.g., friendship, family, professional
relationships) are depicted as edges. Each individual node might have
attributes like “Name,” “Age,” and “Location,” providing additional details
about the person.
Benefits of Network Data Model
1. Flexibility In Data Relationships
A key benefit of the network data model is its flexibility in
representing complex relationships. Unlike traditional
models that may struggle with many-to-many
relationships, the network model excels at capturing
intricate connections between entities. This flexibility is
particularly valuable in scenarios where relationships are
dynamic and evolve over time.
Benefits of Network Data Model
2. Intuitive Representation
The visual representation of a network data model is
often more intuitive for users to understand. With nodes
representing entities and edges denoting relationships,
the model mirrors real-world connections. This makes it
easier for stakeholders, including business analysts and
developers, to grasp the structure of the data and how
different elements relate to each other.
Benefits of Network Data Model
3. Efficient Query Performance
The network data model provides more efficient query
performance in scenarios where relationships play a
crucial role. Traversing relationships in a graph is a
natural operation and (in most cases) a trivial affair; the
same cannot be said about other types of data model
relationships. Graph databases optimized for network
models can deliver fast query responses for complex
relationship-based queries.
Benefits of Network Data Model
4. Better Support For Evolving Data Structures
As data requirements evolve, the network data model
provides better support for changing structures. Adding
or modifying relationships is often more straightforward
in a network model than in traditional models, allowing
organizations to adapt to new business requirements
more seamlessly.
Challenges of Network Data Model
1. Complexity In Modeling
Constructing a network data model can be complex,
especially when dealing with a large number of entities
and intricate relationships.
Effective network data model design requires careful
consideration of the relationships between nodes,
potential redundancy, and the overall structure of the
graph.
Challenges of Network Data Model
2. Performance Scaling
While network data models excel in handling
relationships, their performance can degrade when
dealing with large datasets or complex graphs. Scaling a
network model to accommodate growing amounts of
data requires thoughtful database design and
optimization strategies to maintain query performance.
Challenges of Network Data Model
3. Lack Of Standardization
Unlike relational databases with their standardized,
structured query language (SQL), network databases lack
a universally accepted query language. This lack of
standardization can pose challenges when working with
different graph database systems, as users may need to
adapt to the specific query language supported by the
chosen database.
CYPHER QUERY LANGUAGE
 CYPHER QUERY LANGUAGE
Cypher is Neo4j’s graph query language that lets you
retrieve data from the graph.
It is like SQL for graphs, and was inspired by SQL so it lets
you focus on what data you want out of the graph (not
how to go get it).
It is the easiest graph language to learn by far because of
its similarity to other languages and intuitiveness.
Cypher is unique because it provides a visual way of
matching patterns and relationships.
 CYPHER QUERY LANGUAGE
The Neo4j has its own query language called Cypher
Language.
It is similar to SQL, remember one thing Neo4j does not
work with tables, row or columns it deals with nodes.
It is more satisfied to see the data in a graph format
rather than in a table format.
 Cypher Query
MATCH (G:Company { name:"GeeksforGeeks" })
RETURN G

SQL Query
SELECT * FROM Company WHERE name =
"GeeksforGeeks";
Cypher was inspired by an ASCII-art type of syntax where
(nodes)-[:ARE_CONNECTED_TO]->(otherNodes) using rounded
brackets for circular (nodes), and -[:ARROWS]-> for
relationships.
When you write a query, you draw a graph pattern through your
data.
Neo4j users use Cypher to construct expressive and efficient
queries to do any kind of create, read, update, or delete (CRUD)
on their graph, and Cypher is the primary interface for Neo4j.
 CYPHER QUERY LANGUAGE
Pattern recognition is fundamental to the way that the
brain works.
Because of this, humans are very good at working with
patterns (think of visual diagrams or even memory-
matching games).
Cypher is also heavily based on patterns and is designed
to recognize various versions of these patterns in data,
making it a simple and logical language for users to learn.
 How would you represent the below data in
English?

Sally likes Graphs. Sally is friends with John. Sally works for Neo4j.
 BENEFITS OF CYPHER QUERY LANGUAGE

1. Easy to Learn
A Cypher statement is quite compact.
It expresses references between nodes as visual
patterns, which makes them easy to understand.
Cypher has a low-learning curve, which helps users
quickly write expressive, intuitive queries to
retrieve results faster.
 BENEFITS OF CYPHER QUERY LANGUAGE
2. Secure, Reliable, and Data-Rich
Cypher is well-suited for application development
and data analytics.
It reduces repeated calls to the database and
expresses use-case specific data needs in single,
compact queries.
Neo4j drivers use reactive programming
approaches that save cloud computing resources
and manage back-pressure.
 BENEFITS OF CYPHER QUERY LANGUAGE
3. Visual and Logical
Match patterns of nodes and relationships in the
graph using ASCII-Art syntax.
These patterns map directly to the domain model
drawn in diagrams or on whiteboards.
As a result, there is no impedance mismatch
between the model, the database, and the query
language.
 BENEFITS OF CYPHER QUERY LANGUAGE

4. Open and Flexible

Cypher is an open data query language, based on
the openCypher initiative.
It is extensible with user-defined functions and
procedures.
The Neo4j implementation of the Cypher parser,
planner, and runtime is open source.