A Comprehensive Approach for Graph Data Warehouse Design: A Case
Study for Learning Path Recommendation Based on Career Goals
Viet Nguyen
1,2
, Vu Bui
1,2
and Thu Nguyen
1,2 a,b
1
Faculty of Information Technology, University of Science, Ho Chi Minh City, Vietnam
2
Viet Nam National University, Ho Chi Minh City, Vietnam
Keywords:
Data Warehouse, NoSQL Databases, Graph Data Warehouse, NoSQL-Based Data Warehouse Modeling,
Methodology.
Abstract:
Today, organizations leverage big data analytics for insights and decision-making, handling vast amounts of
structured and unstructured data. Traditional data warehouses (TDW) are suboptimal for such analytics, creat-
ing a demand for NoSQL-based modern data warehouses (DWs) that offer improved storage, scalability, and
unstructured data processing. Graph-based data models (GDMs), a common NoSQL data model, are consid-
ered the next frontier in big data modeling. They organize complex data points based on relationships, enabling
analysts to see connections between entities and draw new conclusions. This paper provides a comprehensive
methodology for graph-based data warehouse (GDW) design, encompassing conceptual, logical, and physical
phases. In the conceptual stage, we propose a high-abstraction data model for NoSQL DW, suitable for GDM
and other NoSQL models. During the logical phase, GDM is used as the logical DW model, with a solution
for mapping the conceptual DW model to GDW. We illustrate the GDW design phases with a use case for
learning path recommendations based on career goals. Finally, we carried out the physical implementation of
the logical DW model on the Neo4j platform to demonstrate its efficiency in managing complex queries and
relationships, and showcase the applicability of the proposed model.
1 INTRODUCTION
The proliferation of social networks, cloud comput-
ing, and IoT devices has precipitated the generation of
vast amounts of data, heralding the era of ’big data.’
This surge in data volume presents significant chal-
lenges for TDW systems, which increasingly strug-
gle with scalability and the management of unstruc-
tured data Oussous et al. (2017). Although once ef-
ficient, TDWs are now inadequate in addressing the
growing demands for speed and complexity in data
processing Bhogal and Choksi (2015). In response to
these limitations, NoSQL databases have emerged as
a critical solution, offering enhanced flexibility, scal-
ability, schemalessness, high availability, and cost-
effectiveness in data storage and analysis Bhogal and
Choksi (2015).
Among the various NoSQL data models, GDMs
stand out for their capability to manage large-scale
data and represent complex relationships, making
a
https://orcid.org/0009-0009-6961-3976
b
Corresponding author
them particularly suited for applications such as rec-
ommendation systems and social networks Akid and
Ayed (2016); Sellami et al. (2019). Consequently, a
growing number of researchers and organizations are
transitioning from Relational Online Analytical Pro-
cessing (ROLAP) to NoSQL DW, despite the tech-
nical challenges that accompany this shift Banerjee
et al. (2021). This transition necessitates not only
technological adaptations but also a thorough design
process that spans from conceptual to physical mod-
els Abdelh
´
edi et al. (2017); Banerjee et al. (2021).
Nevertheless, a significant research gap persists in
the absence of a unified conceptual model specifically
designed for NoSQL DW Banerjee et al. (2021). Ad-
dressing this gap is crucial for ensuring the effective
design and efficient implementation of NoSQL DW
across various organizational contexts. This study
contributes to the field by proposing:
• A novel symbolic system for conceptual modeling
in NoSQL DW, building on prior research Baner-
jee et al. (2021).
• A comprehensive NoSQL DW design methodol-
230
Nguyen, V., Bui, V. and Nguyen, T.
A Comprehensive Approach for Graph Data Warehouse Design: A Case Study for Learning Path Recommendation Based on Career Goals.
DOI: 10.5220/0012945100003838
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 16th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2024) - Volume 3: KMIS, pages 230-237
ISBN: 978-989-758-716-0; ISSN: 2184-3228
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.

ogy, with a particular focus on GDM.
• A case study that demonstrates the application
of the proposed system within GDW tailored for
learning path recommendations.
The paper is structured as follows: Section 1
introduces the context and objectives of the study.
Section 2 reviews the relevant literature. Section 3
presents the symbolic system and the proposed con-
ceptual DW model. Section 4 elaborates on the con-
version process to GDM, supported by a case study.
Section 5 discusses deployment results and perfor-
mance analysis. Finally, Section 6 concludes the pa-
per and explores future research directions.
2 RELATED WORKS
In NoSQL DW research, implementations have pre-
dominantly focused on the logical level, targeting spe-
cific NoSQL types. Yangui et al. (2016) proposed
a method for transforming multidimensional con-
ceptual models into column- and document-oriented
NoSQL models. Chevalier et al. (2015) introduced
three conversion strategies for document-oriented
models, and their study rigorously evaluated the per-
formance and memory utilization of these strategies.
Recent studies highlight the superior performance
of GDW compared to traditional DWs. For instance,
Akid et al. (2022) demonstrated GDW’s efficiency in
handling OLAP queries, while Nguyen et al. (2022)
explored the practical applications of GDM in com-
plex scenarios, including learning path consultancy.
However, as Banerjee et al. (2021) points out,
there remains a significant gap due to the absence of a
unified conceptual model for NoSQL DW. Their pro-
posed symbolic system and model, despite its novel
approach, has constraints, particularly in depicting
many-to-many relationships and defining dimension
table attributes.
Building on these studies, our research proposes a
novel symbolic system for constructing a conceptual
DW model for NoSQL DW, applicable across various
NoSQL databases, with a focus on GDM. We also
offer transformation rules and a case study to illus-
trate the practical application, culminating in a physi-
cal implementation on the Neo4j platform.
3 A SYMBOL SYSTEM FOR
CONCEPTUAL DW MODELING
This section introduces a set of symbols and rules
for conceptual NoSQL DW modeling, using Crow’s
Foot notation for relationships and tabular symbols
for facts and dimensions, ensuring clarity in repre-
senting attributes of fact and dimension tables.
Before presenting the symbol system, fundamen-
tal concepts from the multidimensional model, as de-
tailed by Sellami et al. (2019), are adapted. This
model focuses on a business-centric view of data, em-
phasizing facts, dimensions, measures, and their inter-
relationships.
3.1 Conceptual Multidimensional
Model
A conceptual multidimensional model denoted MDM
is defined by the triplet (FT s,DT s,Star
MDM
), where:
• FT s = {FT
1
,FT
2
,. .. ,FT
n
} is a set of fact tables.
• DT s = {DT
1
,DT
2
,. .. ,DT
m
} is a set of dimension
tables.
• Star
MDM
: F
MDM
→ 2
DT s
is a function that asso-
ciates each fact table FT
i
∈ FT s with the set of
dimension tables DT
i
∈ DT s, and 2
DT s
is a set of
all combinations of the dimension tables.
A fact table, denoted FT
i
∈ FT s, is defined by the
pair (F
name
,F
measures
), where:
• F
name
represents the name of the fact table.
• F
measures
= {m
1
,m
2
,. .. ,m
k
} is the set of measures
of the fact table.
A dimension table, denoted DT
i
∈ DT s, is defined
by the pair (D
name
,D
attributes
), where:
• D
name
represents the name of the dimension table.
• D
attributes
= {a
1
,a
2
,. .. ,a
k
} is a collection of di-
mension table attributes.
3.2 The Set of Symbols for Conceptual
NoSQL DW Representation
In this section, we propose a refined set of symbols,
building upon previous research of Banerjee et al.
(2021), to effectively represent the conceptual model
of a NoSQL DW. This enhanced set of symbols aim to
address and overcome the limitations identified in ear-
lier studies, providing a robust framework for model-
ing DW at the conceptual level.
3.2.1 The Refined Set of Symbols
The Crow’s Foot notation is widely recognized for
its simplicity and clarity in Entity-Relationship (ER)
modeling, making it particularly effective for concep-
tual database representation Puja et al. (2019). This
notation intuitively depicts relationships, including
A Comprehensive Approach for Graph Data Warehouse Design: A Case Study for Learning Path Recommendation Based on Career Goals
231

many-to-many connections, using Crow’s Foot sym-
bols, while tabular symbols represent facts and di-
mensions along with their attributes and measures.
This dual-notation approach ensures clear expression
of fact and dimension table attributes, as summarized
in Table 1.
The conceptual model for a NoSQL DW will be
constructed using these symbols, with definitions of
model components and relationships detailed in the
next section.
Table 1: Proposed symbol system based on Banerjee et al.
(2021).
Shape Symbol Significance
Rectangle
Components within the
Collection layer
Tabular
Table of facts or table
of dimensions
Ellipse
The optional attribute
for a dimension table
Arrow
Indicates a relationship
in which a component
of one layer encapsu-
lates a component of
another layer
Crow’s
Foot
Nota-
tion
Indicates the relation-
ship between a dimen-
sion table and a fact ta-
ble, or a dimension ta-
ble and another dimen-
sion table
3.2.2 Conceptual NoSQL DW Model
Consistent with the symbol set presented in Table 1,
this section presents a conceptual DW model specif-
ically designed for NoSQL DW that can be applied
to different kinds of NoSQL data models. Particu-
lar guidelines for conceptual information representa-
tion are included in this model. In-depth information
about the elements and how they interact with one an-
other in the model will also be supplied. The sug-
gested conceptual DW model is shown in Figure 1,
which provides a clear and organized representation
of these elements and their relationships. The model
is explained in depth in the following:
Components of the Model
This section presents comprehensively information
regarding the components of the model, which is
structured into three distinct layers, namely the Col-
lection layer, Family layer, and Optional attribute
layer.
a. Collection Layer (CL): The topmost layer of the
model is defined by its primary component, col.
CL comprises one or more col:
CL = {col
1
,. .. ,col
q
}
b. Family Layer (FL): The middle layer of the con-
ceptual DW model is represented by this. The
field of FL encompasses two distinct categories,
namely Fact Family (FF) and Dimension Family
(DF). Fact tables and dimension tables are the pri-
mary components of FF and DF, respectively.
• Fact Family (FF): The components of FF con-
sist of fact tables (FT), denoted as:
FF = {FT
1
,. .. ,FT
n
}
• Dimension Family (DF): The components of
DF consist of dimension tables (DT), denoted
as:
DF = {DT
1
,. .. ,DT
n
}
c. Optional Attribute Layer (OAL): This layer is
the last layer of the model and includes optional
attributes that can be present or absent between
instances of dimension tables DT ∈ DF. The key
component of this class is OAT, which is defined
by several pairs (D
name
,OA), where:
• D
name
represents the name of DT.
• OA is the optional attribute name of the DT
OAT = {(D
name
1
,OA
1
),. .. ,(D
name
k
,OA
k
)}
Relationship
This section will deal with the relationships between
the components identified in the above section. Re-
lationships within the model can be classified into
two fundamental types: internal and external relation-
ships. Internal relationships indicate relationships in-
side the same component, whereas external links il-
lustrate interactions between distinct components.
External Relationship: According to Figure 1,
these following relationships are considered external
relationships:
a) Component FF – Component DF (FactDim-
Rel): the FactDimRel relationship is a mapping
f : FF → P (DF)\{
/
0} where P (DF) is the power
set of DF. In this relationship, each FT ∈ FF is
KMIS 2024 - 16th International Conference on Knowledge Management and Information Systems
232

Figure 1: Proposed conceptual DW model for NoSQL DW.
mapped to a non-empty collection of dimension
tables DT s ⊆ DF. This can be represented by the
function f as follows:
f (FT ) = DT s with DT s = {DT
1
,..., DT
m
}
b) Component DF – Component OAT (DimOAt-
trRel): The DimOAttrRel relationship is a map-
ping f : DF → P (OAT ) where P (OAT ) is the
power set of OAT . In the DimOAttrRel relation-
ship, each DT (D
name
,D
attributes
) ∈ DF is mapped
to a set of optional attributes oat ⊆ OAT. This can
be represented by the function f as follows:
f (DT ) = oat, where oat = {(D
name
,OA
1
),
(D
name
,OA
2
),..., (D
name
,OA
m
)}
c) Component Col – Component FF (CLFFRel):
The CLFFRel relationship is a mapping f : Col →
P (FF) \ {
/
0} where P (FF) is the power set of
FF. In the CLFFRel relationship, each Col ∈ CL
is mapped to a non-empty set of fact tables FT
s
⊆
FF. This can be represented by the function f as
follows:
f (Col) = FT
s
with FT
s
= {FT
1
,..., FT
m
}
Internal Relationships: According to Figure 3.1,
internal relationships occur within the DF compo-
nent. There are two types: hierarchical relationships
(many-to-one) and semantic relationships (many-to-
many).
a) Hierarchical Relationships (HierarRel): Rep-
resenting many-to-one relationships between two
dimensions DT
1
and DT
2
of DF, this is a map-
ping: f : DT
1
→ DT
2
such that each element in
DT
1
(child) is mapped to a unique element in DT
2
(parent).
f : DT
1
→ DT
2
∀y ∈ DT
1
,∃! x ∈ DT
2
such that f (y) = x.
b) Semantic Relationships (SemanRel): Repre-
senting many-to-many relationships between two
dimensions DT
1
and DT
2
of DF. To represent
this SemanRel, an intermediate structure M is re-
quired. In this structure:
• M is the intermediate set containing pairs of
mappings between elements in DT
1
and DT
2
along with the set of attributes RA derived from
their relationship.
• M ⊆ DT
1
× DT
2
× P (RA) where P (RA) is the
power set of the set of attributes derived from
RA.
• Each element of M can be represented as a tuple
(d
1
,d
2
,ra) where d
1
∈ DT
1
,d
2
∈ DT
2
and ra ⊆
RA.
4 CONVERTING CONCEPTUAL
NOSQL DW MODEL TO
GRAPH-BASED LOGICAL
MODEL RULES
In this section, we propose rules to convert the con-
ceptual DW model to a logical DW model, which
uses a graph-based data model. Our rules are stated
based on Sellami et al. (2019), a study about rules for
mapping a multidimensional model to a graph-based
logical DW model. Before delving into the conver-
sion rules, we will mention the foundation of a graph-
based data model, laying the groundwork for the con-
version.
4.1 Graph-Based Data Model
Foundation
Information about the concept of the GDM is in-
herited from reference Sellami et al. (2019), with
A Comprehensive Approach for Graph Data Warehouse Design: A Case Study for Learning Path Recommendation Based on Career Goals
233

some adjustments for higher clarity and consistency.
Specifically:
A graph-oriented database G is defined by
(V
G
,E
G
,P
G
), where:
• V
G
= {V
1
,V
2
,. .. ,V
n
} is the set of nodes.
• E
G
= {E
1
,E
2
,. .. ,E
m
} is the set of edges denoting
relationships between nodes.
• P
G
is the set of nodes’ properties in the graph.
An attribute is defined by a key-value pair.
Node: A node V consists of properties and labels,
identified by (id
V
,P
V
,L
V
), where:
• id
V
is the identifier of the node.
• P
V
is the set of properties of the node.
• L
V
is the set of labels of the node, each label l
shows meaning to the node, helping in identifying
the roles for each node.
Relationship: A relationship R is defined as a link
connecting two nodes, which represent two entities
that interact or relate to one another. Each relation-
ship might contain more information through addi-
tional properties. A relationship can be identified by
(id
R
,sourceNodeID,targetNodeID,T
R
,P
R
), where:
• id
R
is the identifier of the relationship.
• sourceNodeID is the identifier of the source node.
• targetNodeID is the identifier of the target node.
• T
R
denotes the relationship type, helping deter-
mine which relationship is linking the two nodes.
• P
R
is a set of properties representing additional
information about it.
4.2 Rules for Mapping Components
We will offer the conversion rules in the respec-
tive components, taking into account the attributes
of the components given in the suggested conceptual
DW model and the symbols of the graph-based data
model described above. There are two main groups
into which these rules fall: relationships and entities.
Here, we will offer greater detail about these guide-
lines.
4.2.1 Rules for Mapping Entities
Rule 1: Mapping col and FT. Each fact ta-
ble FT(F
name
,F
measures
) of the specified conceptual
DW (via CLFRFel relationship) will become a node
V (id
V
,P
V
,L
V
) where:
• Label l
1
represents the table type: l
1
=
{ f act}/L
V
= {l
1
}
• Label l
2
represents the table name: l
2
=
F
name
/L
V
= L
V
∪ l
2
• Label l
3
represents the related collection name:
l
3
= col/L
V
= L
V
∪ l
3
(optional)
• Each measure m
i
∈ F
measures
will be converted into
a property p ← m
i
/P
V
= P
V
∪ p
Rule 2: Mapping DT. Each dimension table
DT(D
name
,D
attributes
) of the DF will become a node
V (id
V
,P
V
,L
V
) where:
• Label l
1
represents the table type, which can be
dimension or parameter depending on the follow-
ing cases:
– If DT is related to a fact table via the Fact-
DimRel relationship or is related to another di-
mension via the SemanRel relationship, then
l
1
= {dimension}/L
V
= {l
1
}
– If DT is related to a dimension table via the Hi-
erarRel relationship and is a parent, then l
1
=
{parameter}/L
V
= {l
1
}
• Label l
2
represents the table name: l
2
=
D
name
/L
V
= L
V
∪ l
2
• Each identifier a
w
(if any) will be converted into a
property p ← a
w
/P
V
= P
V
∪ p
• Each attribute a
i
∈ D
attributes
will be converted into
a property p ← a
i
/P
V
= P
V
∪ p
Rule 3: Mapping OA. Each optional attribute
a
k
∈ oa
Att
(oa
Att
⊆ OA
Att
) of DT via DimOAttrRel
relationship will be converted into a properties p ←
a
i
/P
V
= P
V
∪ p in dimension node.
4.2.2 Rules for Mapping Relationships
Rule 4: Mapping FactDimRel Relationship. Each
FactDimRel relationship will be transformed into a
relationship R(id
R
,sourceNode,targetNode,T
R
,P
R
):
• sourceNode represents the fact;
• targetNode represents the dimension.
• t
1
denotes the relationship type, t
1
= {link f act −
dimension}/T R = {t
1
}
Rule 5: Mapping HierarRel Relationship. Each
HierarRel relationship will be transformed into a re-
lationship R(id
R
,sourceNode,targetNode,T
R
,P
R
):
• sourceNode represents the child.
• targetNode represents the parent.
• t
1
denotes the relationship type, t
1
=
{Precede}/T R = {t
1
}
Rule 6: Mapping SemanRel Relationship. Each
SemanRel relationship will be transformed into a re-
lationship R(id
R
,sourceNode,targetNode,T
R
,P
R
):
KMIS 2024 - 16th International Conference on Knowledge Management and Information Systems
234

• sourceNode represents the source node.
• targetNode represents the target node.
• For each attribute a
i
∈ ra
m
⊆ RA
M
it will be trans-
formed into a property p ← a
i
/P
R
= P
R
∪ p
• t
1
denotes the relationship type, t
1
= {dim − to −
dim}/T R = {t
1
}
5 CASE STUDY
This section presents the development of a person-
alized learning path recommendation system (LPRS)
based on career goals, showcasing our graph-based
NoSQL DW. We provide a practical example of ap-
plying the conceptual, logical, and physical design
phases for NoSQL DW to validate our conceptual
DW model and highlight graph databases’ strengths
in handling complex relationships and queries in rec-
ommendation systems.
Graph NoSQL databases outperform in com-
plex relationship modeling Fernandes and Bernardino
(2018); Sellami et al. (2019), making them ideal
for LPRS that analyze relationships between courses,
learning objectives (LO), and job positions. While
previous studies have focused on graph databases
Beutling and Spahic-Bogdanovic (2024); Nguyen
et al. (2022), we emphasize GDW’s scalable data in-
tegration and advanced analytics for personalized rec-
ommendations. Based on our previous Knowledge
Graph (KG) architecture Nguyen et al. (2022) links
educational resources with career objectives across
three layers: Career Concept, Course Concept, and
Competency Concept. We then create a GDW using
this KG to enhance data-driven recommendations for
LPRS.
The following subsections detail the next three
phases of NoSQL DW design, involving conceptual,
logical, and physical design.
5.1 Conceptual DW Model Design
In the conceptual DW model design process, we use
a top-down approach to identify essential data com-
ponents and their relationships, ensuring alignment
with problem requirements. For this case, we fo-
cus on addressing learning path recommendation is-
sues based on users’ existing skills and career goals.
We identify the main entity groups: Courses, Ca-
reers, Users, and Skills. Skills encompass various en-
tities such as Programming Languages, Frameworks,
Platforms, Knowledge Areas, and Tools, forming the
”Family Layer.” Within this layer, we define two types
of tables: ”Fact Family” and ”Dimension Family.”
The ”Fact Family” includes fact tables like job post-
ings and course enrollments, along with related mea-
sures. The ”Dimension Family” supports each fact
table with detailed data. For example, the job posting
fact table has dimensions like posting location, time,
career, website, and organization, while the course en-
rollment fact table includes course name, instructor,
website, and training organization.
We also identify optional attributes for dimen-
sions, such as skill requirements, proficiency levels
for courses, certifications for instructors, and phone
numbers for users, to optimize data querying and sup-
port advising. The complete conceptual DW model is
presented in Figure 2.
5.2 Mapping Logical DW Model Design
After designing the conceptual NoSQL DW model,
transitioning to a logical GDW model is crucial for
simplifying deployment and enhancing efficiency on
specific database types. This section outlines how to
map the conceptual NoSQL DW model to the logi-
cal GDW model using the mapping rules from sec-
tion 4. We’ll apply these rules to transform the LPRS
problem’s conceptual NoSQL DW model into a com-
plete logical GDW model, focusing on mapping en-
tities and relationships to corresponding components,
thereby streamlining deployment on graph databases.
The process involves two main steps:
Entity Mapping: Each entity identified in the
conceptual DW model, such as courses and websites,
is mapped to a separate node in the graph database.
The names and types of these entities are transformed
into corresponding labels, ensuring clear node identi-
fication. Attributes are also mapped to the properties
of corresponding nodes.
Relationship Conversion: The relationships be-
tween entities, depicted by crow’s foot symbols in the
conceptual DW model, are converted into edges con-
necting the corresponding nodes in the graph. This
step elucidates relationships, enabling a comprehen-
sive and interconnected representation of nodes in the
graph database. Figure 3 illustrates the logical graph
model after conversion.
5.3 Building LPRS Solution Based on
GDW
Based on the proposed logical GDW model, we de-
ployed it using the Neo4j platform, incorporating data
from 4,000 course records and 2,000 job postings
sourced from public job websites. In this GDW, data
entities are represented as nodes, and relationships are
effectively modeled.
A Comprehensive Approach for Graph Data Warehouse Design: A Case Study for Learning Path Recommendation Based on Career Goals
235

Figure 2: Proposed conceptual DW model for the LPRS problem.
Figure 3: Logic model for the LPRS problem.
Two graph mining algorithms were developed for
the Learning Path Recommendation System (LPRS).
The first algorithm identifies critical competencies for
a career and filters them based on the user’s existing
skills to recommend appropriate competencies. The
second algorithm uses these competencies to find rel-
evant courses, building a personalized learning path-
way for the user based on course prerequisites and
KMIS 2024 - 16th International Conference on Knowledge Management and Information Systems
236

levels. Figure 4 provides an example of the input and
output for these algorithms.
Figure 4: An example of the results of LPRS.
The implementation of LPRS on Neo4j under-
scores its efficiency and scalability, particularly in
managing complex queries with intricate relation-
ships. The GDW enables rapid and precise course
recommendations tailored to user profiles, showcas-
ing its capability to handle complex data models.
6 CONCLUSIONS
This study presents a comprehensive methodology
for GDW design and implementation, introducing
new symbols system and transformation rules that en-
hance the efficiency of model conversion. Through
the Neo4j-based LPRS case study, we demonstrated
GDW’s ability to effectively manage complex data re-
lationships, offering enhanced flexibility and perfor-
mance in analyzing intricate data structures. GDW’s
strengths make it particularly valuable in Business In-
telligence applications, such as recommendation sys-
tems and real-time analytics, where accurate and in-
sightful decision-making is critical. Looking ahead,
our future work will involve experimenting with large
datasets (big data), exploring other NoSQL types
like document, key-value, and column stores, and
further refining GDW’s performance and scalability.
These efforts will help to validate GDW’s benefits and
broaden its applicability across diverse data manage-
ment scenarios.
ACKNOWLEDGEMENTS
This research is partially supported by research fund-
ing from the Faculty of Information Technology, Uni-
versity of Science, Ho Chi Minh City, Vietnam. This
research is funded by the Faculty of Information
Technology, University of Science, VNU-HCM, Viet-
nam, Grant number CNTT 2023-15.
REFERENCES
Abdelh
´
edi, F. et al. (2017). Logical unified modeling for
nosql databases. In 2017.
Akid, H. and Ayed, M. B. (2016). Towards nosql graph data
warehouse for big social data analysis. In 2016.
Akid, H. et al. (2022). Performance of nosql graph imple-
mentations of star vs. snowflake schemas. IEEE Ac-
cess, 10:48603–48614.
Banerjee, S. et al. (2021). A unified conceptual model for
data warehouses. Annals of Emerging Technologies in
Computing (AETiC), 5(5):162–169.
Beutling, N. and Spahic-Bogdanovic, M. (2024). Person-
alised course recommender: Linking learning objec-
tives and career goals through competencies. In Pro-
ceedings of the AAAI Symposium Series, volume 3,
page 72–81.
Bhogal, J. and Choksi, I. (2015). Handling big data using
nosql. In 2015 IEEE 29th International Conference on
Advanced Information Networking and Applications
Workshop.
Chevalier, M. et al. (2015). Implementation of multidi-
mensional databases with document-oriented nosql.
In Big Data Analytics and Knowledge Discovery:
17th International Conference, DaWaK 2015, Valen-
cia, Spain, September 1-4, 2015, Proceedings, vol-
ume 17. Springer International Publishing.
Fernandes, D. L. and Bernardino, J. (2018). Graph
databases comparison: Allegrograph, arangodb, in-
finitegraph, neo4j, and orientdb. Information Sci-
ences.
Nguyen, T., Vu, N., and Ly, B. (2022). An approach to
constructing a graph data repository for course rec-
ommendation based on it career goals in the context
of big data. In 2022 IEEE International Conference
on Big Data (Big Data). IEEE.
Oussous, A. et al. (2017). Nosql databases for big data. In
2017 IEEE World Congress on Services.
Puja, I., Poscic, P., and Jaksic, D. (2019). Overview and
comparison of several relational database modelling
methodologies and notations. In International Con-
vention on Information and Communication Technol-
ogy, Electronics and Microelectronics (MIPRO).
Sellami, A., Nabli, A., and Gargouri, F. (2019). Trans-
formation of data warehouse schema to nosql graph
database. In Advances in Intelligent Systems and
Computing, page 410–420.
Yangui, R., Nabli, A., and Gargouri, F. (2016). Automatic
transformation of data warehouse schema to nosql
database: comparative study. Procedia Computer Sci-
ence, 96:255–264.
A Comprehensive Approach for Graph Data Warehouse Design: A Case Study for Learning Path Recommendation Based on Career Goals
237