• Proceedings of the Korean Institute of Information and Commucation Sciences Conference
• /
• 2022.05a
• /
• pp.22-24
• /
• 2022

Recently, Graph Database (GDB) is being used in wide range of industrial fields. GDB is a database system which adopts graph structure for storing the information. GDB handles the information in the form of a graph which consists of vertices and edges. In contrast to the relational database system which requires pre-defined table schema, GDB doesn't need a pre-defined structure for storing data, allowing a very flexible way of thinking about and using the data. With GDB, we can handle a large volume of heavily interconnected data. A network service provider provides its services based on the heavily interconnected communication network facilities. In many cases, their information is hosted in relational database, where it is not easy to process a query that requires recursive graph traversal operation. In this study, we suggest a way to store an example set of interconnected network facilities in GDB, then show how to graph-query them efficiently.

• The Journal of the Korea Contents Association
• /
• v.21 no.12
• /
• pp.84-94
• /
• 2021

Graph databases have been developed to efficiently store and query graph data composed of vertices and edges to express relationships between objects. Since the query types of graph database show very different characteristics from traditional NoSQL databases, benchmarking tools suitable for graph databases to verify the performance of the graph database are needed. In this paper, we propose an efficient graph database benchmarking system that supports diversity in graph inputs and queries. The proposed system utilizes OrientDB to conduct benchmarking for graph databases. In order to support the diversity of input graphs and query graphs, we use LDBC that is an existing graph data generation tool. We demonstrate the feasibility and effectiveness of the proposed scheme through analysis of benchmarking results. As a result of performance evaluation, it has been shown that the proposed system can generate customizable synthetic graph data, and benchmarking can be performed based on the generated graph data.

• Journal of the Korea Institute of Information and Communication Engineering
• /
• v.6 no.5
• /
• pp.653-660
• /
• 2002

This paper proposes a method for storing graphs and defining graph algorithms based on the well-developed relational database. In this method, graphs are represented in the form of relations. Each vertex and edge of a graph is represented as tuples of the table and saved in a database. We developed a library of graph operations for the storage and management of graphs and the development of graph applications. Furthermore, we defined graph algorithms in terms of relational algebraic operations such as projection, selection, and join. They can be implemented with the database language such as SQL. This database approach provides an efficient methodology to deal with very large-scale graphs and to support the development of graph applications.

• Journal of the Korean Association of Geographic Information Studies
• /
• v.25 no.4
• /
• pp.163-180
• /
• 2022

Real estate data can be big data. Because the amount of real estate data is growing rapidly and real estate data interacts with various fields such as the economy, law, and crowd psychology, yet is structured with complex data layers. The existing Relational Database tends to show difficulty in handling various relationships for managing real estate big data, because it has a fixed schema and is only vertically extendable. In order to improve such limitations, this study constructs the real estate data in a Graph Database and verifies its usefulness. For the research method, we modeled various real estate data on MySQL, one of the most widely used Relational Databases, and Neo4j, one of the most widely used Graph Databases. Then, we collected real estate questions used in real life and selected 9 different questions to compare the query times on each Database. As a result, Neo4j showed constant performance even in queries with multiple JOIN statements with inferences to various relationships, whereas MySQL showed a rapid increase in its performance. According to this result, we have found out that a Graph Database such as Neo4j is more efficient for real estate big data with various relationships. We expect to use the real estate Graph Database in predicting real estate price factors and inquiring AI speakers for real estate.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2000.10b
• /
• pp.1289-1292
• /
• 2000

그래프는 실세계의 많은 문제를 푸는데 아주 강력한 방법을 제공한다. 이와 같은 그래프를 효율적으로 표현하기 위한 자료구조와 그래프 연산에 대한 알고리즘이 개발되어 왔다. 본 논문에서는 그래프를 관계형 테이블로 표현하고, 그래프에 대한 연산과 알고리즘을 라이브러리화 하는 방법을 제안한다. 제안한 방법은 관계형 데이터베이스를 이용하여 개발할 수 있으며, 개발된 라이브러리는 그래프로 모델링되는 실세계의 많은 문제를 푸는데 손쉽게 활용할 수 있을 것이다. 또한, 방대한 양의 그래프를 효율적으로 관리할 수 있으며 다수의 사용자가 공유할 수도 있을 것이다.

• Proceedings of the Korea Information Processing Society Conference
• /
• 2023.11a
• /
• pp.314-316
• /
• 2023

최근 수많은 오픈소스로 공개되면서, 대부분의 소프트웨어가 오픈소스를 활용하여 구현되고 있다. 하지만, 오픈소스에 적용되어 있는 라이선스 간의 충돌 문제가 발생하면서, 라이선스 위반 문제가 지속적으로 발생하고 있다. 이러한 문제를 사전에 방지하기 위해 소스코드 분석이 필수적이지만, 다양한 기능이 실행되는 소스코드 특성 상 소스코드만 봤을 경우 직관적으로 분석이 어렵다는 문제점이 있다. 최근 소스코드의 효과적인 분석을 도와주는 다양한 도구들이 개발되었고, 그 중 한 가지 방법은 소스코드를 그래프로 변환하여 시각적인 편의성을 제공하는 방법이다. 그래프로 변환된 소스코드는 해당 시점에는 분석이 가능하지만, 분석이 필요할 때마다 변환을 해야 하는 문제점이 존재한다. 따라서 소스코드를 변환한 그래프 데이터를 저장하는 방법이 요구되었는데, 그래프 데이터베이스의 경우 특정 파일 형식만 지원하기 때문에 그래프 데이터 저장에 어려움이 존재한다. 본 제안방식에서는 소스코드를 변환한 그래프 데이터를 그래프 데이터베이스에 효과적으로 저장하고, 분석이 요구될 때마다 데이터베이스 상에서 즉각적으로 분석이 가능한 방법을 제안한다.

• Journal of the Korea Society of Computer and Information
• /
• v.25 no.4
• /
• pp.123-131
• /
• 2020

The pattern query in graph database has advantages of easy query expression and high query processing performance compared to relational database SQL. However, unlike the relational database, the graph database may not utilize the advantages of pattern query depending on modeling because the methodology for building the logical data model is not defined. In this study, in the is-a node modeling method that appears during the graph modeling process, we experiment that there is a difference in performance between graph pattern query when designing with a generalization model and designing with a specialization model. As a result of the experiment, it was shown that better performance can be obtained when the is-a node is designed as a specialization model. In addition, when writing a pattern query, we show that if a variable is bound to a node or edge, performance may be better than that of the variable of not bounded. The experimental results can be presented as an is-a node modeling method for pattern query and a graph query writing method in the graph database.

• Proceedings of the Korean Institute of Navigation and Port Research Conference
• /
• 2022.11a
• /
• pp.224-226
• /
• 2022

다양한 소스로부터 수집되고 연동되는 데이터를 모델링하는 기술로 그래프 데이터베이스를 활용한 분석 기법이 각광받고 있다. 이 연구에서는 항로표지에서 관측되는 상태 및 주변 정보를 모델링하고, 고장진단 및 예측에 적용할 수 있는 기계학습 기법을 소개한다.

• Proceedings of the Korean Institute of Navigation and Port Research Conference
• /
• 2021.11a
• /
• pp.54-56
• /
• 2021

다양한 소스로부터 수집되고 연동되는 데이터를 모델링하는 기술로 그래프 데이터베이스를 활용한 분석 기법이 각광받고 있다. 이 연구에서는 항로표지에서 관측되는 상태 및 주변 정보를 모델링하고, 고장진단 및 예측에 적용할 수 있는 기계학습 기법을 소개한다.

• The KIPS Transactions:PartD
• /
• v.15D no.1
• /
• pp.15-22
• /
• 2008

In this paper, we propose an efficient algorithm using only one-time database scan. The proposed algorithm creates the bipartite graph which indicates relationship of large items and transactions including the large items. And then we can find large itemsets using the bipartite graph. The bipartite graph is generated when database is scanned to find large items. We can't easily find transactions which include large items in the large database. In the bipartite graph, large items and transactions are linked each other. So, we can trace the transactions which include large items through the link information. Therefore the bipartite graph is a indexed database which indicates inclusion relationship of large items and transactions. We can fast find large itemsets because proposed method conducts only one-time database scan and scans indexed the bipartite graph. Also, it don't generate candidate itemsets.