Modern customer relationship management (CRM) systems are characterized by continuously increasing volumes and complexity of data, necessitating efficient integration approaches. Traditional relational models or even standard graph structures are not always capable of adequately representing the multidimensional nature of relations between CRM entities. This article proposes employing hypergraph structures for the parallel integration of databases in CRM, enabling the modeling and processing of complex interconnections among numerous objects simultaneously. Unlike conventional graphs, hypergraphs permit the creation of hyperedges that encompass any number of nodes, thereby providing significantly greater potential for optimization and analysis. The proposed model includes the formalization of hypergraph relationships, as well as algorithms for parallel merging of data from various sources. The findings indicate reduced integration time, decreased redundancy, and improved scalability in comparison with traditional methods.
Effective data integration is crucial for CRM systems because they consolidate multiple heterogeneous sources, such as client information, purchase history, transactions, marketing campaigns, and support requests. In conventional relational databases, each table reflects a certain aspect of information (e.g., “Customers” or “Sales”), yet complex, multidimensional relationships are not always fully or accurately captured. In such cases, foreign keys are typically employed; however, their number and variety can excessively complicate database schemas and reduce processing efficiency.
Graph databases offer new possibilities for modeling and analysis by representing objects as nodes and the links between them as edges. Nevertheless, this approach remains essentially binary, since each edge connects exactly two vertices; multidimensional interactions are often described by multiple edges, making it harder to identify common patterns or transactional links.
Hypergraph structures enable going beyond a two-element connection. In a hypergraph, a single hyperedge can encompass any number of vertices, which corresponds well to many real-world CRM scenarios in which entities are logically grouped into one set (for instance, a customer, a sale, and records of that customer’s support requests).
Data integration in CRM has been covered in various publications, although most focus on either
relational or partially graph-based models [
Researchers exploring hypergraphs, as a more versatile structure, emphasize their usefulness for
partitioning problems, where each hyperedge may encompass multiple customers or processes [
Nonetheless, few works have systematically studied the parallel integration of databases in CRM based on hypergraph models. Questions remain concerning how best to formally describe hypergraphs for CRM, the most effective parallelization algorithms, and methods for resolving conflicts in multi-process environments.
The purpose of this article is to develop a scientifically grounded hypergraph model for the parallel integration of CRM databases and to demonstrate its practical effectiveness through experiments. The key objectives are:
To create a formal definition of a hypergraph for representing multidimensional relationships in CRM.
To propose algorithms for parallel data merging and processing that minimize conflicts under concurrent database access.
To experimentally evaluate the potential gains of applying hypergraphs compared to traditional approaches.
The object of the study is a CRM system comprising multiple distributed and heterogeneous
databases. We assume that each data source (tables, transaction logs, communication history)
describes a certain set of entities that may overlap or be logically combined [
Consider the hypergraph = (, ) , where = { , , . . . , } is the set of vertices, and =
{ , , . . . , } is the set of hyperedges. Each hyperedge eiei may encompass any number of vertices
from . In a CRM context, these vertices represent entities (tables, records, attributes), and a single
hyperedge may unite the data for, say, a particular customer, transaction, or support ticket [
= { , , . . . , } (1) with 1 ≤ ≤ | |. A weight function ( ) can be introduced to reflect the importance or relevance of a hyperedge.
: → ℝ (2)
Moreover, because CRM often covers multiple business processes (e.g., finance, support, analytics), the function
: → ℂ assigns each hyperedge to a particular category from the set ℂ. (3)
In a traditional database (for instance, PostgreSQL), one may create a “HyperEdges” table, where
each record corresponds to a single hyperedge [
( ) = ( ( ), ( ), ( ), _ _ ( )) (4)
For example, if a particular customer is = 123 , a transaction is = 456 , and a support request is = 789 , then one might form = {123,456,789} as a hyperedge categorized under “SalesIntegration,” with a weight indicating its overall importance.
The proposed approach divides the set of hyperedges into subsets , , . . . , where p is the
number of parallel processes or threads. Each process handles the insertion or updating of its
assigned hyperedges within the CRM database, coordinating through a global transaction manager
or through row- or table-level locks [
The total processing time can be approximated by: ( ) = ∑ ∈ ( ) + where ( ) is the time to process a single hyperedge, α is a coefficient representing overhead for coordination, and is the overall complexity of synchronization. Under ideal distribution, the time decreases almost proportionally to , but if many hyperedges overlap in vertices, conflict resolution can offset these gains.
The task of finding an optimal partition , , . . .
focuses on minimizing conflicts among
processes [
Heuristic methods, such as greedy algorithms or simulated annealing, can be employed to distribute hyperedges and reduce conflict. An objective function might add up the cost of all pairwise overlaps, weighted by the importance (
) of each hyperedge.
Below is a code excerpt (in Python) demonstrating how the hyperedge subsets can be processed in
parallel, inserting and updating records in the CRM database:
(5)
(6)
connection_params = {
'dbname': 'crm_db',
'user': 'user',
'password': 'pass',
'host': 'localhost',
'port': 5432
}
def process_hyperedges(hyperedges_subset):
conn = psycopg2.connect(**connection_params)
cur = conn.cursor()
for he in hyperedges_subset:
try:
cur.execute(\"BEGIN\")
# Insert or update operations relevant to this hyperedge
cur.execute(\"INSERT INTO HyperEdges (id, category, weight) VALUES (%s, %s, %s)\",
(he[0], he[
cur.execute(\"COMMIT\") except:
cur.execute(\"ROLLBACK\") cur.close() conn.close() def parallel_integration(all_hyperedges, num_processes=4): chunk_size = len(all_hyperedges) // num_processes processes = [] for i in range(num_processes): subset = all_hyperedges[i*chunk_size:(i+1)*chunk_size] p = multiprocessing.Process(target=process_hyperedges, args=(subset,)) processes.append(p) p.start() for p in processes:
p.join()
In experiments on a test dataset simulating CRM scenarios, this parallel approach achieved
integration times 45–50% faster compared to sequential processing. The actual level of speedup
depends on the extent of overlapping vertices [
For further validation, a series of experiments was conducted on synthetic CRM data. Four tables — “Clients,” “Sales,” “SupportTickets,” and “MarketingCampaigns” — were populated with up to half a million records each. Numerous multi-dimensional relationships were introduced to mimic real CRM scenarios, enabling the generation of a large set of hyperedges, each with specified weight ( ) and category ( ).
The experiments tested parallel integration under varying numbers of processes ( = 2,4,8,16) . Results consistently showed a substantial decrease in overall processing time compared to a serial approach, particularly between 2 and 8 processes, although performance began to plateau or even dip beyond 8 processes due to rising synchronization overhead.
Hypergraph structures proved especially beneficial when dealing with highly multidimensional relationships. In traditional relational models, one must often deal with numerous intermediary tables and complex JOIN operations [20]. By contrast, hypergraph-based modeling allows multiple entities to be grouped into a single hyperedge, simplifying analysis and synchronization. Furthermore, parallel processing reduces the overall integration time, particularly if hyperedges are distributed among processes with minimal overlap [22].
However, excessive increases in the number of processes lead to higher blocking and synchronization overhead. Consequently, the overall speedup may be lower with = 16 than with = 8. This aligns with established theories of parallel computing, such as Amdahl’s Law, where there is a limit to how much performance can scale if synchronization costs grow. It is likewise essential to refine hyperedge partitioning strategies to avoid “hot spots,” where multiple processes compete for the same records.
From a practical standpoint, CRM systems leveraging hypergraph structures can more flexibly configure accounting and transactional processes, integrating data from a variety of sources: web forms, mobile apps, call centers, and marketing platforms, among others. In many cases, this data has overlapping references (e.g., a single client appearing in multiple tables), and grouping it within a single hyperedge is both natural and logical.
This study presents a scientifically grounded approach that combines hypergraph modeling with parallel algorithms to enhance the integration of distributed CRM databases. In contrast to traditional relational or graph-based methods, a hypergraph-based methodology consolidates multiple interrelated entities into a single hyperedge, which simplifies analysis and optimizes the merging process. Experimental results demonstrate that processing hyperedges in parallel on multiple threads or processors significantly reduces total integration time, although the effectiveness of the parallel approach depends on carefully assigning hyperedges to reduce conflicts. Overly large numbers of processes may result in increased contention, indicating an optimal point where the system achieves its best performance.
Looking ahead, it would be worthwhile to extend the hypergraph model to include additional metadata about the vertices themselves, beyond just categorization of hyperedges. Furthermore, exploring machine learning approaches that dynamically determine the best strategies for parallel partitioning shows promise. Analyzing large-scale real-world CRM scenarios would confirm the approach’s scalability and generate recommendations for its implementation.
The authors are appreciative of colleagues for their support and appropriate suggestions, which allowed to improve the materials of the article.
The authors have not employed any Generative AI tools. (2021) International Scientific and Technical Conference on Computer Sciences and Information Technologies, 2, pp. 225-230. ISBN: 978-166544257-2 doi: 10.1109/CSIT52700.2021.9648770. [19] G. S. Kumar, R. Priyadarshini, N. H. Parmenas, H. Tannady, F. Rabbi and A. Andiyan, "Design of Optimal Service Scheduling based Task Allocation for Improving CRM in Cloud Computing," 2022 Sixth International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (ISMAC), Dharan, Nepal, 2022, pp. 438-445, doi: 10.1109/I-SMAC55078.2022.9987392. [20] Y. Shen, M. D’Antonio, S. Chakraborty and A. Khaligh, "CCM vs. CRM Design Optimization of a Boost-derived Parallel Active Power Decoupler for Microinverter Applications," 2020 IEEE Energy Conversion Congress and Exposition (ECCE), Detroit, MI, USA, 2020, pp. 5393-5400, doi: 10.1109/ECCE44975.2020.9236218. [21] N. Sambhe, G. Yenurkar, S. Karale, L. Umate and G. Khekare, "Enhancing Customer 360 With Better Service Management using Salesforce CRM," 2022 International Conference on Emerging Trends in Engineering and Medical Sciences (ICETEMS), Nagpur, India, 2022, pp. 130-134, doi: 10.1109/ICETEMS56252.2022.10093576. [22] F. Shanshan and R. Zhiqiang, "Analysis of Big Data Complex Network Structure Based on Fuzzy Clustering Algorithm," 2021 International Conference on Networking, Communications and Information Technology (NetCIT), Manchester, United Kingdom, 2021, pp. 348-352, doi: 10.1109/NetCIT54147.2021.00076.