KÁIXAR: A Horizontal Fragmentation Method for Medical Databases Considering DICOM Data and Content-Based Queries

Abstract

The accelerated growth of medical databases, particularly those storing images in DICOM (Digital Imaging and Communications in Medicine) format, has increased the need for efficient strategies to optimize the retrieval and querying of medical information. This work presents KÁIXAR, a horizontal fragmentation method for medical databases that integrates workload analysis, DICOM images, and content-based retrieval. The proposed method employs operation records (logs) to identify access patterns and, through the Pareto principle (80/20), selects the most representative queries for generating the fragmentation scheme. Subsequently, KÁIXAR proposes and allocates fragments by considering the hardware characteristics of servers located at the sites where the recorded queries originated. As a verification mechanism, the system enables the visualization of fragmented DICOM images and their associated metadata. Experimental evaluation showed scenario-dependent performance benefits. In an additional physical-site validation under a high-workload scenario, KÁIXAR reduced mean query latency from 108.735 ms to 15.062 ms relative to XAMANA, corresponding to an 86.15% reduction and a 7.22× speedup; the paired latency difference was statistically significant ($p<0.001$). These results support KÁIXAR as an efficient alternative for horizontal fragmentation in medical databases.

1. Introduction

Medical institutions generate and store large volumes of digital images on a daily basis, including computed tomography (CT), magnetic resonance imaging (MRI), ultrasound, and other studies commonly represented using the DICOM standard [1]. The continuous growth of these repositories has increased the demand for efficient storage, retrieval, and management mechanisms capable of supporting both traditional metadata-based queries and Content-Based Image Retrieval (CBIR) operations [2,3,4]. As the volume of medical information grows, centralized database architectures may experience performance degradation due to increased storage requirements, higher query processing costs, and network bottlenecks [3,5,6].

CBIR techniques have emerged as a valuable alternative for retrieving medical images according to their visual characteristics rather than relying exclusively on metadata [7,8]. Advances in deep learning and computer vision have enabled the extraction of representative image features through convolutional neural networks such as ResNet50 [7] and local feature extraction algorithms such as ORB (Oriented FAST and Rotated BRIEF) [8]. More recent research has extended medical CBIR toward increasingly complex and clinically oriented scenarios. Ben Abacha et al. [9] introduced benchmarks and retrieval methods for three-dimensional medical imaging, encompassing image-to-image and text-to-image retrieval and modern representation-learning approaches at clinically realistic scale. Similarly, Lee et al. [10] developed and validated a deep learning-based content-based medical image retrieval approach integrated with a Picture Archiving and Communication System (PACS), illustrating the practical incorporation of CBIR into medical imaging infrastructures. These developments reinforce the need for data-management mechanisms that efficiently organize not only medical images and metadata, but also the visual representations required by content-based retrieval.

However, CBIR operations often involve processing large collections of image descriptors, which increases data-access and query-processing costs as repositories grow to thousands or millions of images [8,11]. Consequently, efficient data organization and distribution mechanisms become essential for supporting content-based queries at scale. Within this context, KÁIXAR addresses the data-organization layer of the CBIR problem rather than the development of a new image-retrieval model. The proposed method organizes and distributes the underlying medical database according to workload characteristics and prepares its physical and logical structure to support queries involving visual information derived from ResNet50, ORB, and texture descriptors. Therefore, KÁIXAR does not aim to improve the discriminative accuracy of the CBIR algorithms themselves; instead, it targets the efficient storage, distribution, and access of the data required to execute such queries. Accordingly, the experimental evaluation focuses on database-oriented metrics, including query latency, data coverage, and fragment behavior. Retrieval-effectiveness measures such as Precision@K, Recall@K, mean Average Precision (mAP), and Normalized Discounted Cumulative Gain (NDCG) evaluate the quality of the retrieval model and constitute a complementary evaluation dimension beyond the fragmentation contribution investigated in this study.

Horizontal fragmentation divides a relation or data collection into smaller subsets according to selection predicates and workload access patterns, with the objective of increasing data locality and reducing unnecessary data access and communication among distributed sites [12]. For example, Arsov et al. [13] formulated horizontal partitioning as a workload execution-cost minimization problem, deriving candidate fragments from query predicates and using a genetic algorithm together with the PostgreSQL query optimizer to identify a suitable partitioning scheme. Likewise, Amer et al. [14] addressed fragmentation and allocation as interdependent design problems by combining horizontal fragmentation, fragment allocation, and site clustering in a heuristic strategy aimed at reducing transmission costs. More recently, Shoaib et al. [15] introduced an MCRUD (Modified Create, Read, Update, and Delete Matrix)-based derived horizontal fragmentation approach that incorporates attribute locality and access frequency into fragment generation and placement. At the physical-design level, Abebe et al. [16] proposed MorphoSys, which dynamically adjusts partitioning, replication, and data placement according to workload behavior through a learned cost model. In contrast, Singh et al. [17] focused specifically on non-redundant fragment allocation after fragmentation, whereas Kishore et al. [11] investigated traffic-aware partitioning and aggregation mechanisms for improving query efficiency in scalable distributed environments. Other approaches specialize fragmentation according to the characteristics of the workload: Drissi et al. [18] designed horizontal fragmentation and query-execution strategies for fuzzy-query databases, while Ahmed and Alhenshiri [19] combined query-driven horizontal and derived fragmentation with a genetic algorithm to adapt the fragmentation scheme to frequently executed queries.

Despite these advances, most existing methods primarily address conventional relational or distributed workloads and optimize fragmentation according to execution cost, access frequency, locality, or communication overhead. Research focused on medical data has addressed related distribution problems from different perspectives. Sri and Vemuru [4] combined data replication and partitioning for cloud-based medical applications, whereas Lebre and Costa [3] investigated a non-relational distributed architecture for medical imaging databases. However, these approaches do not center the fragmentation process on workloads that incorporate content-based medical image retrieval operations and their associated visual information.

To address these challenges, this work presents KÁIXAR, a workload-driven horizontal fragmentation method for medical databases contemplating CBIR. The proposed method analyzes workload logs to identify representative access patterns through the construction of the MCRUD matrix together with the Attribute Locality Precedence (ALP) structures. When content-based queries are present, visual descriptors extracted from DICOM images are incorporated into the fragmentation process. Subsequently, the method generates a horizontal fragmentation scheme and evaluates fragment allocation costs to determine the most suitable distributed site for each fragment.

The main contributions of this work are: (1) a workload-driven horizontal fragmentation method capable of considering both traditional and CBIR queries; (2) the integration of visual descriptors obtained from DICOM medical images into the fragmentation process; (3) a fragmentation scheme generation strategy supported by MCRUD analysis, ALP construction, and the Pareto principle; (4) a cost-based fragment allocation mechanism for distributed environments; and (5) the implementation of these components within KÁIXAR, a web-based platform designed for the fragmentation of medical databases.

The remainder of this article is organized as follows. Section 2 reviews the literature related to horizontal fragmentation. Section 3 presents the proposed method in detail. Section 4 describes the experimental evaluation and discusses the results. Section 5 addresses relevant considerations regarding the applicability and implementation of the proposed method. Finally, Section 6 summarizes the main conclusions and outlines directions for future research.

2. Related Work

To introduce this section, the works that laid the foundations for the development of this research are presented. These studies address challenges related to distributed database fragmentation, workload analysis, fragment allocation, multimedia data management, Not Only SQL (NoSQL) technologies, and CBIR queries. Together, they provide the theoretical and methodological basis upon which the proposed KÁIXAR approach is built. Particular attention is given to approaches supporting multimedia information, medical data management, and query optimization, as these characteristics are directly related to the objectives of this work.

Several studies have focused on the management of large-scale medical datasets and medical imaging repositories. Sinha and Raamana [2] proposed MRDataset, a unified framework for accessing heterogeneous medical imaging datasets stored in formats such as DICOM and Neuroimaging Informatics Technology Initiative (NIfTI). Similarly, Sri and Vemuru [4] addressed the secure and scalable management of distributed medical data through a multi-user replication and fragmentation strategy supported by cloud computing, machine learning, and blockchain technologies. In the context of medical imaging repositories, Lebre and Costa [3] developed a non-relational architecture based on MongoDB and CouchDB for DICOM data management, demonstrating improved scalability compared with traditional relational databases. These studies highlight the growing need for scalable and efficient architectures capable of supporting large volumes of medical information.

A second group of studies has focused on improving horizontal fragmentation and fragment allocation strategies in distributed databases. Amer et al. [14] proposed a simultaneous fragmentation and allocation method based on access patterns, retrieval frequencies, and cost models. Singh et al. [17] introduced a biogeography-based optimization approach for non-redundant fragment allocation, reducing communication costs among distributed sites. Castro-Medina et al. [20] proposed an enhanced allocation mechanism that incorporates predicate costs into the fragment selection process, while Ahmed and Alhenshiri [19] presented an adaptive fragmentation strategy guided by real query workloads and genetic optimization techniques. These approaches demonstrate the importance of workload-aware fragmentation and allocation mechanisms for improving query performance.

Dynamic and workload-driven fragmentation has also received considerable attention. MorphoSys, proposed by Abebe et al. [16], dynamically modifies the physical design of distributed databases using machine learning, replication, and partitioning strategies. Boissier and Kurzynski [21] developed a workload-oriented partitioning approach for Hybrid Transactional and Analytical Processing (HTAP) environments, improving analytical query performance through selective tuple pruning. Farchan et al. [5] demonstrated the benefits of horizontal fragmentation and replication using PostgreSQL and Citus in distributed environments. Likewise, Diaz et al. [22] experimentally evaluated several partitioning and sharding strategies, concluding that adaptive sharding techniques provide superior scalability and fault tolerance. These studies confirm the relevance of workload characteristics when designing fragmentation schemes.

Other works have addressed complementary aspects of distributed database fragmentation. Arsov et al. [13] proposed a predictive approach for selecting horizontal partitioning schemes based on query execution cost estimation. Drissi et al. [18] incorporated fuzzy similarity measures into horizontal fragmentation to improve the execution of imprecise queries. Laouir and Imine [23] investigated privacy-preserving approximate queries over horizontally distributed federated datasets using differential privacy techniques. Furthermore, Salmi et al. [24] formalized horizontal fragmentation using the Isabelle/HOL proof assistant, mathematically verifying correctness properties such as completeness, reconstruction, and disjointness. Together, these studies demonstrate the importance of cost estimation, privacy preservation, and formal validation in modern distributed database systems.

Castro-Medina et al. [25] proposed a dynamic horizontal fragmentation method for multimedia databases contemplating CBIR queries. Their approach adapts fragmentation schemes according to workload variations and aims to reduce query response times while improving data availability. The method was implemented in Java using JavaServer Faces (JSF) and evaluated with database management systems such as MySQL and MongoDB. This work represents one of the closest antecedents to the proposed method, since it incorporates multimedia data, dynamic fragmentation, and CBIR queries. However, unlike KÁIXAR, it does not focus specifically on DICOM medical databases, does not integrate a medical image visualization mechanism, and does not incorporate a hardware-aware fragment allocation model based on server scoring and penalty functions.

Recent studies have continued exploring fragmentation and partitioning strategies aimed at improving the performance of distributed database systems. Kishore et al. [11] proposed a traffic-aware partitioning and aggregation mechanism capable of monitoring query patterns and dynamically redistributing data to reduce inter-node communication. Their results demonstrated significant improvements in latency, throughput, and resource utilization in large-scale distributed environments. Similarly, Soltanmohammadi et al. [6] developed a partitioning technique for healthcare data based on hash functions applied to patient identifiers, achieving improvements in retrieval performance and scalability when managing large medical datasets. Furthermore, Shoaib et al. [15] introduced a derived horizontal fragmentation method based on MCRUD matrices and the ALP model, obtaining improvements in query response time, throughput, and reduction in remote accesses through locality-aware fragment allocation.

Although these approaches provide valuable contributions to distributed database fragmentation, none simultaneously integrates NoSQL database support, DICOM-based medical information, content-based queries, workload optimization through a Top 20% strategy, and hardware-aware fragment allocation mechanisms. These limitations motivate the development of KÁIXAR, which aims to provide a unified horizontal fragmentation solution for medical databases by considering both workload characteristics and distributed infrastructure capabilities.

To provide a structured and objective comparison of the reviewed approaches, a set of eleven evaluation criteria was defined based on the functional, technical, and methodological characteristics commonly reported in distributed database fragmentation studies. These criteria cover aspects such as fragment allocation mechanisms, cost models, NoSQL database support, medical data management, DICOM compliance, scalability, query performance, CBIR capabilities, solution completeness, ease of implementation, and the use of CRUD operations during the fragmentation process. Table 1 summarizes the evaluation of the reviewed studies according to these criteria, providing a consolidated view of their capabilities and highlighting the research gap addressed by the proposed KÁIXAR method.

Table 1. Comparison of related works.

Article	1	2	3	4	5	6	7	8	9	10	11
Sinha and Raamana [2]	X	X		X	X	X	X	X	X	X
Lebre and Costa [3]		X	X	X	X	X	X		X	X
Sri and Vemuru [4]	X	X		X		X	X	X	X	X
Farchan et al. [5]	X	X				X	X		X	X
Soltanmohammadi et al. [6]	X			X		X	X		X	X	X
Kishore et al. [11]	X					X	X		X
Arsov et al. [13]	X					X	X		X
Amer et al. [14]	X	X				X	X		X	X
Shoaib et al. [15]	X	X				X	X		X	X	X
Abebe et al. [16]	X					X	X		X
Singh et al. [17]	X					X	X		X
Drissi et al. [18]	X						X		X
Ahmed and Alhenshiri [19]		X				X	X		X	X
Castro-Medina et al. [20]	X	X				X	X		X	X	X
Boissier and Kurzynski [21]	X	X				X	X		X	X
Diaz et al. [22]	X		X			X	X		X
Laouir and Imine [23]						X	X		X
Salmi et al. [24]									X
Castro-Medina et al. [25]	X	X	X			X	X	X	X	X	X
This Work	X	X	X	X	X	X	X	X	X	X	X

(1) Fragment Allocation, (2) Cost Model, (3) NoSQL Database, (4) Medical Data, (5) DICOM Support, (6) Scalability, (7) Query Efficiency, (8) CBIR, (9) Completeness, (10) Ease of Implementation, (11) CRUD Support. Note: An “X” indicates that the corresponding study satisfies the criterion specified in the respective column. Bold formatting highlights the proposed work (This Work), which satisfies all eleven comparison criteria.

The reviewed studies demonstrate that horizontal fragmentation remains an active research area, with recent advances focusing on workload awareness, cost-based allocation, healthcare data management, and scalable distributed architectures.

Completeness refers to whether a work provides the necessary elements for replication, such as algorithms, architectural descriptions, mathematical models, experimental validation, or implementation details. Ease of implementation evaluates whether the proposed approach can be reproduced using commonly available technologies and resources. Fragment allocation and cost model criteria assess whether the work includes mechanisms for allocating fragments to distributed sites and formal models for evaluating fragmentation alternatives, respectively. The remaining criteria analyze the suitability of each approach for modern medical database environments, including support for NoSQL technologies, management of medical data, compliance with the DICOM standard, scalability, query performance, CBIR capabilities, and the consideration of CRUD operations during the fragmentation process.

As shown in Table 1, most existing approaches focus on specific aspects of distributed database fragmentation, such as scalability, query optimization, or fragment allocation. However, no work simultaneously addresses fragmentation, CRUD-oriented workload analysis, medical data management, DICOM support, and CBIR functionality. In contrast, the proposed KÁIXAR fragmentation method satisfies all eleven evaluation criteria considered in this study, providing an integrated solution for medical databases supporting DICOM data and content-based queries.

As shown in Table 1, most existing approaches address only a subset of the evaluated criteria. Several studies focus on medical data management and DICOM repositories, such as those proposed by Sinha and Raamana [2] and Lebre and Costa [3]. Other works emphasize workload-driven fragmentation, query optimization, and fragment allocation, including the approaches of Amer et al. [14], Abebe et al. [16], and Singh et al. [17]. Similarly, Castro-Medina et al. [25] incorporated CBIR functionality into a dynamic fragmentation strategy for multimedia databases, representing one of the closest antecedents to the proposed work.

Among the reviewed studies, the approaches of Castro-Medina et al. [20,25], Ahmed and Alhenshiri [19], Amer et al. [14], and Lebre and Costa [3] exhibit the highest similarity to KÁIXAR because they simultaneously consider multiple aspects related to fragmentation, cost model, scalability, query performance, and medical or multimedia data management. However, none of these approaches integrates all the evaluated criteria within a single framework.

In contrast, KÁIXAR incorporates fragment allocation, cost-based evaluation, NoSQL database support, medical data management, DICOM compliance, scalability, query efficiency, CBIR functionality, completeness properties, ease of implementation, and CRUD workload analysis. Furthermore, KÁIXAR introduces a allocation strategy based on server scoring and penalty functions, allowing fragment placement decisions to consider the computational capabilities of each site. This combination of features enables KÁIXAR to provide a unified solution for the horizontal fragmentation of medical databases contemplating DICOM data and content-based queries.

3. KÁIXAR: A Horizontal Fragmentation Method for Medical Databases Contemplating CBIR

This section presents KÁIXAR, a workload-driven horizontal fragmentation method designed for medical databases that incorporate CBIR queries. The proposed method combines workload analysis, visual descriptor management, fragmentation scheme generation, and cost-based fragment allocation to improve data distribution and query performance in distributed environments. The following subsections describe the general workflow of the method, the cost models employed for fragment allocation, the server evaluation and penalty mechanisms, the generation of fragmentation schemes, and the correctness properties that guarantee the validity of the proposed fragmentation process.

3.1. General Workflow of the Proposed Method

To introduce the proposed method, a brief description of the implementation environment and supporting technologies is presented. KÁIXAR is a web application developed in Java [26] using the JavaServer Faces (JSF) [27] and PrimeFaces [28] frameworks. Its purpose is to support the design and implementation of horizontal fragmentation schemes for medical databases that incorporate CBIR.

Figure 1 presents the architectural organization of KÁIXAR, structured into three main layers: presentation, business logic, and storage. The presentation layer provides the interaction mechanisms for fragmentation management and DICOM image visualization, supported by PrimeFaces and Cornerstone. The business logic layer integrates the Payara application server, JSF-based services, Java Database Connectivity (JDBC), the Java synchronous driver, and the fragmentation algorithm responsible for generating and allocating the fragmentation scheme. Finally, the storage layer separates the application-related data managed by MySQL from the medical image repository implemented in MongoDB, where the resulting horizontal fragments are physically stored. This layered organization clearly separates user interaction, fragmentation processing, and data persistence, facilitating the implementation and maintenance of the proposed method.

Figure 1. Architectural organization of KÁIXAR. Dashed arrows indicate UML usage dependencies («use») between architectural elements, whereas solid lines represent structural connections and communication interfaces.

Figure 2 illustrates the overall workflow of the proposed method. Initially, the user provides the database connection parameters, the target collection or table, and the workload log file. After validating the input data, the fragmentation process is initialized.

Figure 2. Workflow of the proposed KÁIXAR horizontal fragmentation method. Dashed lines indicate associations between input parameters and their corresponding database or table resources, whereas solid arrows represent the control flow and transitions between activities.

Subsequently, the method determines whether the workload contains content-based queries. When CBIR queries are present, the database administrator selects the descriptor attribute used to group documents with similar characteristics. Otherwise, KÁIXAR analyzes the workload log by constructing the ALP table in order to identify the most suitable attribute for horizontal fragmentation.

Based on the selected attribute, the corresponding horizontal fragmentation scheme is generated. Subsequently, the fragment allocation cost is evaluated considering the characteristics of the available distributed sites. Finally, the fragments are materialized and allocated according to the cost evaluation results, selecting the distributed site that minimizes the estimated execution cost.

After determining whether the workload contains content-based queries, the method proceeds with the identification of the fragmentation attribute. When CBIR queries are present, KÁIXAR employs visual descriptors extracted from medical images stored in the DICOM format [1]. To this end, the images are processed using the ResNet50 model [7], a deep convolutional neural network widely adopted for high-level feature extraction. Additionally, the ORB algorithm [8] is used to extract local features that are robust to scale and rotation variations. The generation of these descriptors was implemented in Python (version 3.13.3) using specialized computer vision and deep learning libraries, including OpenCV [29]. The resulting feature vectors are stored in the database and subsequently employed during content-based retrieval operations, enabling the identification of medical images with similar visual characteristics. In this scenario, the database administrator selects the descriptor attribute used to group documents with similar characteristics. Otherwise, KÁIXAR analyzes the workload log to identify the most representative access patterns. Based on this information, an MCRUD matrix is constructed to determine the frequency and distribution of operations performed on the attributes of the analyzed collection or table. Subsequently, the obtained information is used to build the ALP table, whose purpose is to identify the most relevant attribute for horizontal fragmentation.

When the workload log contains one hundred or more operations, KÁIXAR applies a Pareto-based Top 20% workload reduction strategy, considering only the twenty percent most frequent queries for the construction of the fragmentation scheme. This strategy is motivated by the skewed access patterns commonly observed in database workloads [30]. Under this assumption, the most frequent queries are expected to capture the dominant workload behavior while reducing the amount of data that must be analyzed. As a result, the generated fragmentation scheme focuses on the most representative access patterns, reducing analysis complexity and improving the efficiency of the fragmentation process.

Once the fragmentation attribute has been identified, the corresponding horizontal fragmentation scheme is generated, consisting of fragmentation predicates and the resulting fragments. Subsequently, KÁIXAR evaluates the allocation cost of each fragment by considering both the characteristics of the generated fragments and the capabilities of the available distributed sites. Finally, the fragments are materialized and allocated according to the cost evaluation results, selecting the site that minimizes the estimated execution cost and optimizes data distribution across the distributed environment.

3.2. Fragment Allocation Cost Model

The proposed method contemplates two horizontal fragmentation approaches: horizontal fragmentation without CBIR and horizontal fragmentation contemplating CBIR. Each approach employs a specific cost model to determine the most appropriate fragment allocation strategy according to workload characteristics and available hardware resources. The objective of these models is to minimize execution costs while improving the performance of distributed medical databases.

Horizontal Fragmentation Without CBIR

The horizontal fragmentation process without CBIR consists of two main stages: the construction of the operation cost matrix and the generation of the ALP table.

The operation cost matrix estimates the cost associated with operations executed at a given site under a specific predicate. The operation cost is defined by Equation (1).

$$Ho{r}_i=Serve{r}_{Penalt{y}_i}\times {\displaystyle \sum _{j=1}^N}\left(F_j\times Ntuple{s}_j\times VD{O}_j\times V{R}_j\right)$$

(1)

where i represents each fragmentation predicate, j corresponds to an operation recorded in the workload log, N denotes the total number of operations, $F_j$ is the frequency of the predicate in the workload, $Ntuple{s}_j$ represents the number of tuples affected by operation j, $VD{O}_j$ corresponds to the operation value described in Table 2, $V{R}_j$ is the remote value factor, and $Serve{r}_{Penalt{y}_i}$ is the penalty associated with the evaluated server.

Table 2. Operation values used in the proposed cost models.

Operation	Value
Read	1
Create	2
Delete	2
Update	3

Table 2 presents the operation values employed in all cost models proposed in this work.

The remote value factor ($VR$) takes the value 1 when the operation is performed locally and 2 when it originates from a different site.

To determine the optimal distribution of fragments, KÁIXAR evaluates the available servers according to their hardware and network characteristics. The total server score is calculated using Equation (2).

$$\begin{array}{cc}\hfill Tota{l}_{Score}=& (CP{U}_{Score}\times 0.25)+(RA{M}_{Score}\times 0.20)\hfill \\ \hfill & +(Storag{e}_{Score}\times 0.20)+(Networ{k}_{Score}\times 0.15)\hfill \\ \hfill & +(Chipse{t}_{Score}\times 0.20)\hfill \end{array}$$

(2)

The weighting factors assigned to each hardware component were defined according to their relative impact on the storage, processing, and retrieval of medical data. CPU resources received the highest weight (25%) due to their direct influence on query execution, descriptor processing, and fragment management tasks. RAM, storage, and chipset capabilities were assigned weights of 20% each, reflecting their importance in supporting large in-memory operations, storing DICOM images and descriptors, and providing high-throughput communication between hardware components. Network bandwidth received a weight of 15%, as its impact is primarily associated with remote operations and inter-site communication. These values were established considering both the technical relevance of each component and their relative acquisition costs in enterprise-grade server infrastructures, where memory and high-performance storage devices often represent a substantial portion of the overall hardware investment. Consequently, the proposed scoring model favors servers that provide a balanced combination of computational power, storage capacity, memory resources, and communication capabilities.

The CPU score is obtained using Equation (3).

$$CP{U}_{Score}=\min \left({\displaystyle \frac{CP{U}_{Cores}}{64}}\times 100,100\right)$$

(3)

where $CP{U}_{Cores}$ represents the number of physical processor cores.

The RAM score is calculated according to Equation (4).

$$RA{M}_{Score}=\min \left({\displaystyle \frac{RA{M}_{GB}}{512}}\times 100,100\right)$$

(4)

where $RA{M}_{GB}$ represents the installed memory capacity expressed in gigabytes.

The storage score is calculated as follows:

$$Storag{e}_{Score}=Typ{e}_{Score}+Capacit{y}_{Score}$$

(5)

The storage capacity score is obtained using Equation (6).

$$Capacit{y}_{Score}=\min \left({\displaystyle \frac{Storag{e}_{TB}}{50}}\times 20,20\right)$$

(6)

where $Storag{e}_{TB}$ denotes the available storage capacity measured in terabytes (TB). The normalization threshold is set at 50 TB, allocating a maximum of 20 points for capacity. This score is designed to be aggregated with a discrete storage type score—assigned as 80 for NVMe SSD, 70 for SAS SSD, 60 for SATA SSD, 40 for Hybrid, and 30 for HDD—yielding a maximum combined storage score of 100 points.

The network score is calculated according to Equation (7).

$$Networ{k}_{Score}=\min \left({\displaystyle \frac{Networ{k}_{Gbps}}{40}}\times 100,100\right)$$

(7)

where $Networ{k}_{Gbps}$ corresponds to the server’s available network bandwidth. The denominator serves as an upper normalization bound of 40 Gbps, which represents the optimal throughput required to minimize latency during remote content-based Image Retrieval (CBIR) operations, thereby capping the maximum metric at 100 points.

The chipset score evaluates the architectural capabilities of the node to support high-throughput environments, determined by Equation (8).

$$Chipse{t}_{Score}=PCI{e}_{Version}+PCI{e}_{Lanes}+Features$$

(8)

where the variables are quantified based on the hardware specifications as follows:

• $PCIeVersion$ represents the baseline performance associated with the PCI Express generation and is mapped to discrete values: 40 points for PCIe 5.0, 30 points for PCIe 4.0, 15 points for PCIe 3.0, and 10 points for other generations.
• $PCIeLanes$ represents the available PCI Express lane capacity and is evaluated using discrete ranges. Systems with 128 or more lanes receive 30 points, systems with 48–127 lanes receive 25 points, systems with 16–47 lanes receive 15 points, and systems with fewer than 16 lanes receive 10 points.
• $Features$ is a binary metric that assigns 20 points when at least one enterprise-grade capability is available, such as Error-Correcting Code (ECC) memory, Single Root Input/Output Virtualization (SR-IOV), Intel Virtualization Technology for Directed Input/Output (VT-d), or Reliability, Availability, and Serviceability (RAS) features; otherwise, it assigns 0 points.

The use of discrete scores for PCIe generation and lane capacity avoids assuming a strictly linear relationship between these hardware characteristics and server performance, while providing a consistent ranking of heterogeneous server configurations.

The resulting server score is transformed into a penalty value through linear interpolation.

$$Serve{r}_{Penalty}=-{\displaystyle \frac{1}{10}}\times Tota{l}_{Score}+10$$

(9)

This function assigns a penalty value of 10 to the lowest-performing server and a penalty value of 1 to the highest-performing server.

To provide greater flexibility in heterogeneous computing environments, a quadratic penalty function is also proposed. Equation (9) presents a baseline linear transformation of the server score into a penalty value. However, the proposed allocation method ultimately employs the quadratic penalty function defined in Equation (10), which preserves a minimum penalty value of 1 for the highest-performing server while enabling a more flexible penalty distribution across heterogeneous computing environments.

$$Serve{r}_{Penalty}\left(S\right)=a(S-S_{min})(S-S_{max})-{\displaystyle \frac{9}{S_{max}-S_{min}}}(S-S_{min})+10$$

(10)

where S represents the server score, $S_{min}$ and $S_{max}$ correspond to the minimum and maximum scores observed in the evaluated environment, respectively, and a controls the curvature of the function.

Expanding Equation (10) yields:

$$\begin{array}{cc}\hfill Serve{r}_{Penalty}\left(S\right)=& a{S}^2-\left[a(S_{min}+S_{max})+{\displaystyle \frac{9}{S_{max}-S_{min}}}\right]S\hfill \\ \hfill & +\left[a{S}_{min}{S}_{max}+{\displaystyle \frac{9S_{min}}{S_{max}-S_{min}}}+10\right]\hfill \end{array}$$

(11)

Based on the hardware characteristics of the three experimental sites described in Section 4.2, the server scores were computed using Equations (2)–(8). The resulting scores were 45.50 for Site 2 (192.168.0.96), 23.64 for Site 3 (192.168.0.97), and 15.91 for Site 1 (127.0.0.1). These values were subsequently used as inputs to the quadratic penalty function defined in Equation (10). To evaluate the sensitivity of the allocation model to the curvature parameter a, six representative values were analyzed over the interval $[-0.002,0.005]$, including $a=0$ as the linear reference case and $a=0.001$ as the nominal value adopted in KÁIXAR. Table 3 reports the resulting penalties for each experimental site and the corresponding preference order, where a lower penalty indicates a more suitable destination for fragment allocation. Across the entire evaluated interval, the preference order remained unchanged, with Site 2 consistently receiving the lowest penalty, followed by Site 3 and Site 1. Figure 3 provides a graphical representation of this behavior, showing that variations in a modify only the magnitude of the penalty associated with the intermediate server score, while the extreme scores remain anchored at penalties of 1 and 10 due to the boundary conditions embedded in Equation (10). This result indicates that the allocation preference is stable under substantial perturbations of the curvature parameter and is therefore not dependent on a narrowly tuned value of a.

Table 3. Sensitivity analysis of the quadratic penalty parameter a for the experimental sites.

a	Site 2	Site 3	Site 1	Preference Order
	192.168.0.96	192.168.0.97	127.0.0.1
	$\mathit{S}\mathbf{=}\mathbf{45.50}$	$\mathit{S}\mathbf{=}\mathbf{23.64}$	$\mathit{S}\mathbf{=}\mathbf{15.91}$
−0.002	1.00	7.99	10.00	Site 2 → Site 3 → Site 1
−0.001	1.00	7.82	10.00	Site 2 → Site 3 → Site 1
0.000	1.00	7.65	10.00	Site 2 → Site 3 → Site 1
0.001	1.00	7.48	10.00	Site 2 → Site 3 → Site 1
0.003	1.00	7.14	10.00	Site 2 → Site 3 → Site 1
0.005	1.00	6.80	10.00	Site 2 → Site 3 → Site 1

Figure 3. Sensitivity of the quadratic server penalty to variations in the curvature parameter a for the three experimental sites.

The case $a=0$ corresponds to the linear component of Equation (10), whereas $a=0.001$ represents the nominal configuration employed by KÁIXAR.

It should be noted that the hardware coefficients used in the server-score model were defined as engineering weights for representing the relative contribution of heterogeneous resource categories and were not fitted to the query-latency results reported in this study. The sensitivity analysis therefore focuses on the curvature parameter a, which directly controls the nonlinear transformation from server score to allocation penalty. Within the evaluated interval, variations in a altered the penalty magnitudes but did not change the resulting destination-site preference order.

3.3. Cost Model for Horizontal Fragmentation Contemplating CBIR

When CBIR queries are present, the workload characteristics differ from those of traditional database operations. In this scenario, KÁIXAR evaluates fragment allocation according to the descriptors associated with medical images and the amount of information processed during retrieval operations.

The descriptors employed by KÁIXAR are extracted from DICOM medical images using the ResNet50 deep learning model and the ORB feature extraction algorithm. These descriptors are stored in the database and subsequently used during similarity retrieval operations.

The cost model for horizontal fragmentation contemplating CBIR is defined by Equation (12).

$$HorCBI{R}_i={\displaystyle \sum _{j=1}^N}\left(Ntuple{s}_j\times VD{O}_j\right)$$

(12)

where $HorCBI{R}_i$ represents the performance cost associated with fragment i, $Ntuple{s}_j$ denotes the number of tuples involved in operation j, $VD{O}_j$ corresponds to the operation value described in Table 2, and N represents the total number of operations associated with the evaluated fragment.

By reducing the number of descriptors contained within each fragment, CBIR queries are executed over smaller subsets of visual information. Consequently, the proposed approach reduces processing costs and improves retrieval performance when handling large-scale medical image repositories.

3.4. Fragmentation Correctness Properties

A fundamental requirement of any fragmentation strategy is the preservation of the semantics of the original database after the fragmentation process. According to the principles of distributed database design described by Özsu and Valduriez [12], a valid horizontal fragmentation scheme must satisfy three fundamental properties: completeness, reconstruction, and disjointness. These properties guarantee that the generated fragments preserve the information contained in the original relation and allow distributed query execution without altering the semantics of the database.

3.4.1. Completeness

The completeness property guarantees that every tuple contained in the original relation is represented in at least one fragment. Let R be a relation decomposed into a set of fragments $FR=R_1,R_2,\dots ,R_n$. Completeness is satisfied when every tuple belonging to R can be found in one or more fragments of $FR$.

In KÁIXAR, completeness is guaranteed through the generation of fragmentation predicates that collectively cover the tuples contained in the original relation. Additionally, when tuples do not satisfy any generated predicate, a residual fragment is created to preserve such tuples and ensure that no information is lost during the fragmentation process.

3.4.2. Reconstruction

The reconstruction property ensures that the original relation can be recovered from its fragments without loss of information. Formally, if a relation R is horizontally decomposed into a set of fragments $FR=R_1,R_2,\dots ,R_n$, the original relation must be recoverable through the union of all generated fragments:

$$R={\displaystyle \bigcup _{i=1}^n}{R}_i$$

(13)

The reconstruction property guarantees that all information contained in the original database remains accessible after fragmentation. Since KÁIXAR generates fragmentation schemes whose predicates collectively represent the original workload, the union of all fragments, including the residual fragment when required, reconstructs the original relation completely.

3.4.3. Disjointness

The disjointness property ensures that each tuple belongs to only one fragment. Formally, if $R_i$ and $R_j$ are two fragments of relation R, then:

$$R_i\cap R_j=\varnothing ,\forall i\ne j$$

(14)

This property prevents data redundancy and guarantees that a tuple is not simultaneously stored in multiple fragments. KÁIXAR satisfies this property by generating mutually exclusive fragmentation predicates. Consequently, each tuple is assigned to a single fragment, avoiding overlaps between fragments and ensuring consistent fragment allocation across distributed sites.

The proposed method guarantees the three previous properties through the generation of mutually exclusive predicates, the incorporation of residual fragments when necessary, and the preservation of all tuples contained in the original relation. Therefore, the generated fragmentation schemes remain semantically equivalent to the original database while improving query performance and supporting efficient distributed data management.

3.5. Algorithms of the Proposed Method

The proposed method is composed of three algorithms. Algorithm 1 describes the overall workflow of KÁIXAR. Algorithm 2 performs workload optimization through the analysis of workload logs, MCRUD construction, ALP calculation, and attribute selection. Finally, Algorithm 3 generates the fragmentation scheme and assigns the resulting fragments to the distributed sites according to the proposed cost models.

Algorithm 1 General Workflow of KÁIXAR.

1 input: Database D, Workload Log L, Available Sites S 2 output: Fragmentation Scheme $FS$, Allocation Plan $AP$ 3 Connect to database D 4 $C\leftarrow$ Get target collection from D 5 Load workload log L 6 $(A,M)\leftarrow$Workload Optimization$(L,C)$ 7 $(FS,AP)\leftarrow$ Fragmentation and Allocation $(A,M,C,S)$ 8 Materialize Fragments $(FS,AP)$ 9 Return $FS$ and $AP$

Algorithm 2 Workload Optimization.

1 input: Workload Log L, Collection C  2 output: Fragmentation Attribute A, MCRUD Matrix M  3 $n\leftarrow$ NumberOfOperations($L,C$)  4 If $n\ge 100$  5      Sort queries of C according to frequency  6      Apply Pareto Principle  7      Select Top 20% most frequent queries  8      Generate Filtered Log $L_f$  9 Else 10      $L_f\leftarrow$ FilterByCollection($L,C$) 11 End If 12 Initialize MCRUD Matrix M 13 For each operation $o_i\in L_f$ 14      Extract predicate 15      Extract operation type 16      Extract originating site 17      Update MCRUD Matrix M 18 End For 19 Initialize ALP Table 20 For each attribute $a_i$ 21      Compute ALP Score 22 End For 23 Sort attributes according to ALP score 24 $A\leftarrow$ Highest ALP Attribute 25 Return A and M

Algorithm 3 Fragmentation and Allocation.

1 input: Fragmentation Attribute A, MCRUD Matrix M, Collection C, Available Sites S  2 output: Fragmentation Scheme $FS$, Allocation Plan $AP$  3 $AP\leftarrow \varnothing$  4 $P\leftarrow$ ExtractPredicates($A,M$)  5 NormalizePredicates(P)  6 RemoveDuplicatePredicates(P)  7 $F\leftarrow \varnothing$  8 $PreviousPredicates\leftarrow \varnothing$  9 $OriginalCount\leftarrow CountDocuments\left(C\right)$ 10 For each predicate $p_i\in P$ 11      $ExclusivePredicate\leftarrow BuildExclusivePredicate(p_i,PreviousPredicates)$ 12      $FragmentCount\leftarrow CountDocuments(C,ExclusivePredicate)$ 13      If $FragmentCount>0$ 14         $f_i\leftarrow CreateFragment\left(ExclusivePredicate\right)$ 15         $f_i.Count\leftarrow FragmentCount$ 16         Add $f_i$ to F 17         Add $p_i$ to $PreviousPredicates$ 18      End If 19 End For 20 $ResidualPredicate\leftarrow Negation\left(PreviousPredicates\right)$ 21 $ResidualCount\leftarrow CountDocuments(C,ResidualPredicate)$ 22 If $ResidualCount>0$ 23      $f_r\leftarrow CreateResidualFragment\left(\right)$ 24      $f_r.Count\leftarrow ResidualCount$ 25      Add $f_r$ to F 26 End If 27 $FragmentTotal\leftarrow \sum Count\left(f_i\right)$ 28 VerifyCompleteness($FragmentTotal$, $OriginalCount$) 29 For each site $s_j\in S$ 30      $CP{U}_j\leftarrow CalculateCPUScore\left(\right)$ 31      $RA{M}_j\leftarrow CalculateRAMScore\left(\right)$ 32      $Storag{e}_j\leftarrow CalculateStorageScore\left(\right)$ 33      $Networ{k}_j\leftarrow CalculateNetworkScore\left(\right)$ 34      $Chipse{t}_j\leftarrow CalculateChipsetScore\left(\right)$ 35      $Scor{e}_j\leftarrow ComputeTotalScore\left(\right)$ 36      $Penalt{y}_j\leftarrow QuadraticPenalty\left(Scor{e}_j\right)$ 37 End For 38 For each fragment $f_i\in F$ 39      For each site $s_j\in S$ 40         $Cos{t}_{ij}\leftarrow HORI(f_i,s_j,M,Penalt{y}_j)$ 41         Store ${\mathrm{Cost}}_{ij}$ in CostMatrix 42      End For 43      $BestSite\leftarrow MinCostSite\left(f_i\right)$ 44      $AP\left[f_i\right]\leftarrow BestSite$ 45 End For 46 $FS\leftarrow F$ 47 Return $FS$ and $AP$

3.5.1. Algorithm 1: General Workflow of KÁIXAR

Algorithm 1 presents the overall workflow of KÁIXAR. The process begins by establishing a connection to the target database and loading the workload log. Subsequently, workload optimization is performed to identify the most representative access patterns and determine the most suitable fragmentation attribute. Based on this information, the fragmentation scheme is generated and evaluated using the proposed allocation cost models. Finally, the generated fragments are materialized across the distributed environment according to the allocation plan that minimizes the estimated allocation cost.

Rather than representing a simple sequence of operations, Algorithm 1 summarizes the interaction among the main modules implemented in KÁIXAR. The workload optimization module analyzes the workload log to identify the most representative access patterns using the Top 20% strategy. The fragmentation module then constructs the MCRUD matrix, computes the ALP values, and determines the most suitable fragmentation attribute. Subsequently, the allocation module evaluates fragment placement costs using the model defined in Equation (1), considering hardware characteristics, locality, and access frequency. Finally, the generated fragments are materialized in the distributed environment according to the allocation plan with the minimum estimated cost.

At the methodological level, the algorithms that constitute KÁIXAR are not restricted to a particular database management system or data model. The workload-analysis, attribute-selection, predicate-generation, fragmentation, and allocation stages operate on logical information such as queries, attributes, predicates, access frequencies, and destination site characteristics. Consequently, the same workflow can be adapted to both NoSQL and relational environments, provided that the corresponding data-access and fragment-materialization operations are implemented for the target system. In a relational database, each horizontal fragment can be represented as a subset of tuples satisfying a fragmentation predicate, i.e., $F_i={\sigma }_{p_i}\left(R\right)$, where R is the original relation and $p_i$ is the predicate associated with fragment $F_i$. Fragment reconstruction can then be performed through the union of the resulting relations, while the completeness and disjointness properties considered by KÁIXAR remain applicable at the logical level. Therefore, a relational implementation could use systems such as PostgreSQL without modifying the core decision process of the proposed method, although the physical materialization, indexing, query execution, and reconstruction mechanisms would need to be adapted to the corresponding relational engine.

MongoDB was selected for the current implementation because its document model is particularly convenient for representing heterogeneous DICOM metadata, nested attributes, CBIR-related descriptors, and references to binary medical-image objects without requiring an extensive normalization process. In addition, the implementation can preserve related metadata and derived descriptors in separate collections while maintaining direct references between them, which facilitates the experimental manipulation and materialization of fragments. Thus, the use of MongoDB should be understood as an implementation decision motivated by the characteristics of the evaluated medical dataset rather than as a methodological requirement of KÁIXAR. Porting the method to a relational DBMS would primarily require replacing the persistence and query-execution layer, while preserving the workload-driven fragmentation logic, the MCRUD and ALP analyses, the fragmentation predicates, and the hardware-aware allocation procedure.

3.5.2. Algorithm 2: Workload Optimization

Algorithm 2 details the workload optimization stage implemented in KÁIXAR. The process begins by analyzing the workload log and determining the total number of recorded operations. When the workload contains more than 100 operations, the Top 20% optimization strategy is automatically activated. Queries are grouped according to their predicate, operation type, and originating site, and then sorted by frequency of occurrence. The most representative queries are selected to generate a reduced workload log while preserving the dominant access patterns observed in the original workload.

Once the filtered workload has been obtained, KÁIXAR constructs the MCRUD matrix by extracting the predicate, operation type, and source site associated with each recorded operation. The resulting matrix captures the distribution of CREATE, READ, UPDATE, and DELETE operations across the analyzed attributes. Subsequently, the ALP values are computed for each candidate attribute using the workload access frequencies. The attributes are then ranked according to their ALP scores, and the attribute with the highest locality relevance is selected as the fragmentation attribute used during the fragmentation scheme generation stage.

Algorithm 2 formalizes the workload-driven attribute selection process implemented in KÁIXAR. The first stage (Lines 3–11) reduces workload complexity through the Pareto-based Top 20% optimization strategy, enabling the analysis to focus on the most representative queries when processing large workload logs. The second stage (Lines 12–18) transforms the filtered workload into a structured MCRUD representation by identifying predicates, operation types, and originating sites associated with each recorded query. This representation captures the dominant access behavior of the system and provides the basis for fragmentation analysis. The third stage (Lines 19–25) computes the ALP values, ranks candidate attributes according to their locality relevance, and selects the attribute with the highest priority. By integrating workload reduction, access pattern modeling, and locality-based attribute evaluation, Algorithm 2 enables KÁIXAR to identify fragmentation attributes that accurately represent workload behavior while significantly reducing the computational effort required for workload analysis.

3.5.3. Algorithm 3: Fragmentation and Allocation

Algorithm 3 describes the generation of the horizontal fragmentation scheme and the subsequent fragment allocation process. First, the predicates associated with the selected fragmentation attribute are extracted and used to generate mutually exclusive fragments together with a residual fragment that guarantees completeness. Next, each available site is evaluated according to its hardware and network characteristics, including CPU, memory, storage, network bandwidth, and chipset capabilities. These characteristics are used to calculate the server score and the corresponding quadratic penalty. Subsequently, the proposed allocation cost model is evaluated for each fragment–site pair, producing a cost matrix. Finally, each fragment is assigned to the site that minimizes the estimated allocation cost and the fragments are materialized in the distributed environment.

Algorithm 3 formalizes the generation, allocation, and materialization of the fragmentation scheme proposed in KÁIXAR. The first stage (Lines 3–27) constructs the horizontal fragmentation scheme using the attribute selected by Algorithm 2. During this process, mutually exclusive predicates are generated and evaluated to create non-overlapping fragments while preserving completeness through the generation of a residual fragment when required. The resulting fragments collectively represent the original collection through the generation of mutually exclusive predicates and a residual fragment, ensuring completeness and preventing data loss during fragmentation.

The second stage (Lines 28–37) evaluates the available destination sites according to their hardware and network characteristics. CPU capacity, RAM size, storage resources, network bandwidth, and chipset capabilities are normalized and integrated into a composite server score. Subsequently, the quadratic penalty model defined in Equation (10) is applied to estimate the suitability of each site for fragment allocation.

The third stage (Lines 38–45) computes the allocation cost matrix by evaluating every fragment–site pair using the proposed cost model. For each fragment, the destination site with the minimum estimated cost is selected as the allocation target. Finally, Lines 46–47 materialize the generated fragments in the distributed environment and return the final allocation plan. By integrating fragmentation generation, hardware-aware cost evaluation, and automated allocation, Algorithm 3 enables KÁIXAR to produce deployment schemes that adapt to both workload characteristics and infrastructure capabilities.

Algorithmic limitations. Although the proposed algorithms provide a complete workflow for workload analysis, fragmentation, and fragment allocation, their behavior depends on several characteristics of the input workload and deployment environment. First, the fragmentation decisions are workload-driven and therefore depend on the representativeness of the operation log. If access patterns change substantially over time, the MCRUD and ALP analyses may need to be recomputed and the fragmentation scheme reevaluated. Likewise, workload reduction based on the Pareto criterion prioritizes the most representative operations; consequently, in highly diverse workloads, infrequent but semantically relevant access patterns may receive less influence during fragmentation design. The sensitivity analysis presented in Section 5 evaluates this behavior for different workload-retention rates.

A second limitation concerns fragment generation and allocation. Increasing the number of relevant attributes and predicates can increase the number of candidate fragments and, consequently, the computational and materialization costs of the method. In addition, the hardware-aware allocation stage relies on the server characteristics and scoring parameters available at the time of execution; substantial changes in CPU, memory, storage, or network conditions may therefore require the allocation decision to be reevaluated. The current implementation uses MongoDB for fragment materialization and query execution, although the core workload-analysis and fragmentation logic is independent of the database management system. Adapting KÁIXAR to another DBMS therefore requires implementation of the corresponding persistence, query-execution, and fragment-reconstruction operations.

Beyond these practical limitations, the computational cost of the proposed workflow depends primarily on workload size, the number of candidate fragmentation attributes, the generated predicates, and the number of available destination sites. The following analysis summarizes the computational complexity of the method.

The computational cost of data partitioning is particularly relevant in large-scale multimedia environments, where both data distribution and workload characteristics directly affect system scalability. Pereira et al. [31] showed that distributed multimedia retrieval performance is strongly influenced by data locality and load imbalance, demonstrating that partitioning strategies that jointly consider these factors can maintain performance improvements even at billion-scale data volumes. These findings reinforce the importance of evaluating not only the effectiveness of a fragmentation strategy but also its computational behavior as the collection size, workload, number of fragments, and available sites increase. Accordingly, the computational complexity of the fragmentation and allocation procedure implemented by KÁIXAR is analyzed below.

The computational complexity of Algorithm 3 can be characterized directly in terms of the structures and operations defined in the method. Let $\left|C\right|$ denote the number of documents in the original collection C, $\left|P\right|$ the number of distinct fragmentation predicates contained in P, $\left|F\right|$ the number of generated fragments in F, $\left|S\right|$ the number of available sites in S, and $\left|\mathrm{MCRUD}\right|$ the number of workload operations represented in the input MCRUD matrix. During fragment generation, each exclusive predicate may incorporate the predicates previously processed; therefore, constructing all exclusive predicates requires $O\left(\right|P{|}^2)$ time in the worst case. In addition, CountDocuments is executed for each exclusive predicate and for the residual predicate. Under the conservative assumption that no supporting indexes are available, each predicate evaluation may require a complete scan of C, resulting in a worst-case cost of $O\left(\right|P\left|\right|C\left|\right)$ for fragment-cardinality estimation, with the additional residual evaluation bounded by $O\left(\right|C\left|\right)$. Server characterization, score computation, and quadratic-penalty calculation are linear in the number of available sites and consequently require $O\left(\right|S\left|\right)$ time.

During cost evaluation, KÁIXAR considers the workload operations applicable to each generated fragment. In the current implementation, each query–fragment cardinality required by the HORI cost model is obtained once from the original collection and subsequently reused when calculating the corresponding costs for the available sites. Consequently, the conservative worst-case cost of obtaining these cardinalities is $O\left(\right|F\left|\right|\mathrm{MCRUD}\left|\right|C\left|\right)$, whereas constructing and evaluating the fragment–site cost matrix requires $O\left(\right|F\left|\right|S\left|\right)$ additional time. The subsequent assignment stage also requires at most $O\left(\right|F\left|\right|S\left|\right)$, because the allocation decision for each fragment considers no more than the available sites. Finally, the generated fragments are mutually exclusive and the residual fragment contains only the documents not included in the primary fragments; therefore, each document belongs to at most one materialized fragment.

Nevertheless, if the documents associated with each fragment must be located independently and no supporting indexes are available, the retrieval component of materialization is conservatively bounded by $O\left(\right|F\left|\right|C\left|\right)$, while at most $\left|C\right|$ documents are written. Combining these stages and omitting lower-order duplicated terms, the overall worst-case time complexity of Algorithm 3 is $O\left({\left|P\right|}^2+\left|C\right|\left(\left|P\right|+\left|F\right|\left(\left|\mathrm{MCRUD}\right|+1\right)\right)+\left|F\right|\left|S\right|\right)$. Furthermore, since each distinct fragmentation predicate can generate at most one nonempty primary fragment and an additional residual fragment may be produced, $\left|F\right|\le \left|P\right|+1$. Excluding the storage occupied by the original collection and the materialized fragments themselves, the main auxiliary structures comprise the generated-fragment metadata, the previously processed predicates, the query–fragment cardinalities, and the fragment–site cost matrix; therefore, a conservative auxiliary-space complexity is $O\left(\left|P\right|+\left|F\right|+\left|F\right|\left|\mathrm{MCRUD}\right|+\left|F\right|\left|S\right|\right)$. These bounds intentionally describe the conservative worst case.

When appropriate indexes are available for the attributes involved in the fragmentation and workload predicates, MongoDB can avoid complete collection scans for many evaluations and substantially reduce the practical execution cost; however, no tighter indexed bound is assumed because such a bound depends on the index structure, predicate selectivity, and output cardinality. Thus, the dominant computational component of KÁIXAR is the evaluation of workload predicates and query–fragment cardinalities over the original collection, whereas server scoring and destination-site selection scale only with the numbers of generated fragments and available sites.

4. Results

This section presents the results obtained from the experimental evaluation of the proposed KÁIXAR method. First, the characteristics of the MEDIFRAG database and the distributed environment used during the experiments are described. Next, the fragmentation schemes generated by KÁIXAR are analyzed under three workload scenarios of increasing complexity. Finally, the performance of the proposed method is compared against the XAMANA system [25] using the same workload logs and execution environment in order to assess fragmentation quality, fragment allocation decisions, and query execution performance.

4.1. Experimental Dataset

To evaluate the proposed method, a medical multimedia database named MEDIFRAG was developed and implemented in MongoDB. MEDIFRAG is a NoSQL database specifically designed for the validation of horizontal fragmentation strategies in medical environments. The database integrates medical imaging datasets obtained from Kaggle [32,33,34], DICOM Library [35], Saga IT [36], and Grassroots DICOM (GDCM) Data [37], including DICOM studies and associated metadata, and occupies approximately 1.8 GB of storage.

The database is composed of four main collections: dicom_instances, dicom_files.files, dicom_files.chunks, and cbir_descriptors. The dicom_instances collection stores the metadata associated with each medical image, including identifiers such as studyInstanceUID, seriesInstanceUID, and sopInstanceUID, as well as clinically relevant attributes including imaging modality (CT, MR, among others), study date, image dimensions (rows and columns), and additional CBIR-related characteristics such as image area, aspect ratio, resolution class, slice category, and complexity index.

Binary DICOM files are managed through MongoDB GridFS using the collections dicom_files.files and dicom_files.chunks. This mechanism enables the efficient storage and retrieval of large medical imaging files while maintaining a direct relationship with their associated metadata stored in dicom_instances.

The cbir_descriptors collection stores the visual descriptors employed for CBIR queries. Each document contains deep descriptors extracted using the ResNet50 convolutional neural network model, represented as feature vectors of 2,048 dimensions, together with local descriptors generated using ORB. Additionally, texture-based descriptors such as contrast, homogeneity, energy, and correlation are stored to provide complementary visual information.

Table 4, Table 5 and Table 6 summarize the main attributes stored in MEDIFRAG; this experimental database contains approximately 4468 medical studies represented in the dicom_instances collection, 4468 CBIR descriptor records stored in the cbir_descriptors collection, more than 2300 DICOM files managed through GridFS, and over 7000 binary chunks distributed across the dicom_files.files and dicom_files.chunks collections. The collected studies include DICOM images from different clinical domains and imaging modalities, providing a heterogeneous environment suitable for evaluating workload-driven horizontal fragmentation strategies in medical repositories [32].

Table 4. Main attributes of the dicom_instances collection.

Attribute	Datatype
_id	ObjectId
gridfsFileId	ObjectId
dicom.studyInstanceUID	String
dicom.seriesInstanceUID	String
dicom.sopInstanceUID	String
dicom.modality	String
dicom.studyDate	String
dicom.seriesNumber	Integer
dicom.instanceNumber	Integer
dicom.rows	Integer
dicom.columns	Integer
cbir.imageArea	Integer
cbir.aspectRatio	Double
cbir.resolutionClass	String
cbir.sliceCategory	String
cbir.complexityIndex	Integer
ingestedAt	Date

Table 5. Main attributes of the cbir_descriptors collection.

Attribute	Datatype
_id	ObjectId
instanceId	ObjectId
gridfsFileId	ObjectId
descriptors.cnn.model	String
descriptors.cnn.vector	Array[2048]
descriptors.cnn.dim	Integer
descriptors.orb.n_features	Integer
descriptors.orb.descriptors	Array
descriptors.texture.contrast	Double
descriptors.texture.homogeneity	Double
descriptors.texture.energy	Double
descriptors.texture.correlation	Double
cbirSnapshot.imageArea	Integer
cbirSnapshot.aspectRatio	Double
cbirSnapshot.resolutionClass	String
cbirSnapshot.sliceCategory	String
cbirSnapshot.complexityIndex	Integer
createdAt	Date

Table 6. Main attributes of the GridFS collections.

Collection	Attribute	Datatype
dicom_files.files	_id	ObjectId
	filename	String
	length	Long
	chunkSize	Integer
	uploadDate	Date
	metadata.sopInstanceUID	String
dicom_files.chunks	_id	ObjectId
	files_id	ObjectId
	n	Integer
	data	Binary

The attributes shown in Table 4, Table 5 and Table 6 represent the subset of metadata and descriptors used during workload analysis, predicate generation, fragment construction, and allocation processes. Since MEDIFRAG was implemented using MongoDB, its scheme remains extensible and can incorporate additional metadata, imaging modalities, and CBIR descriptors as new medical datasets are integrated. Consequently, the proposed method is not restricted to the attributes presented in this study and is adaptable to evolving medical repositories without requiring structural modifications to the database scheme.

In addition to the structural description of the database, the experimental dataset was characterized according to the imaging modalities stored in MEDIFRAG. The database contains 4468 DICOM instances distributed across five modalities represented in MEDIFRAG: computed tomography (CT), magnetic resonance (MR), external-camera photography (XC), ophthalmic tomography (OPT), and ophthalmic photography (OP). Among them, CT is the dominant modality with 3880 instances, followed by MR with 560 instances, whereas XC, OPT, and OP are represented by smaller subsets of 16, 8, and 4 instances, respectively. This distribution provides a heterogeneous experimental environment that comprises highly represented modalities alongside under-represented categories, which is useful for evaluating workload-driven fragmentation schemes under imbalanced data distributions. The modalities exhibit differences in spatial characteristics. CT images present average dimensions of 514 rows and 513 columns, while MR images average 467 rows and 463 columns. XC images are characterized by larger dimensions, with fixed values of 1152 rows and 1536 columns, whereas OPT images average 1024 rows and 768 columns, and OP images average 664 rows and 512 columns. Figure 4 shows one representative example of each modality included in MEDIFRAG, while Table 7 summarizes their main statistical properties. This characterization improves the reproducibility of the experimental setup by providing both a structural and descriptive account of the data used to validate the proposed method. Listing 1 complements this characterization by exposing the DICOM metadata fields from the dicom_instances collection that participate in workload analysis, predicate generation, and fragment construction. In parallel, cbir_descriptors stores ResNet50 feature vectors, ORB local descriptors, and GLCM texture features, linking visual representations with their corresponding medical-image records.

Figure 4. Representative medical imaging modalities in MEDIFRAG supported by KÁIXAR: CT, MR, XC, OPT, and OP. Author-compiled figure using images sourced from Kaggle [32,34], DICOM Library [35], Saga IT [36], and GDCM Data [37].

Table 7. Statistical summary of imaging modalities stored in MEDIFRAG.

Modality	Count	Avg. Rows	Avg. Columns	Avg. Area	Row Range	Column Range
CT	3880	514	513	264,524	512–1595	512–888
MR	560	467	463	227,277	256–896	256–732
XC	16	1152	1536	1,769,472	1152–1152	1536–1536
OPT	8	1024	768	786,432	1024–1024	512–1024
OP	4	664	512	339,968	664–664	512–512
Total	4468	–	–	–	–	–

To illustrate the actual structure of the experimental data, Listing 1 presents a representative document extracted from the dicom_instances collection. The document contains the identifiers required to associate the metadata with the corresponding DICOM file stored in GridFS, together with acquisition information, image dimensions, and the CBIR-related attributes used during workload analysis and fragment generation.

Listing 1. Representative document from the dicom_instances collection of MEDIFRAG.

1  {  2   _id: ObjectId(‘693dcfbaec5a304296a0f06d’),  3   gridfsFileId: ObjectId(‘693dcfbaec5a304296a0f061’),  4   dicom: {  5    studyInstanceUID:  6    ‘1.3.6.1.4.1.44316.6.102.1.20250704114423696.61158672119535771932’,  7    seriesInstanceUID:  8    ‘1.3.6.1.4.1.44316.6.102.2.20250704114429771.63133867861500115690’,  9    sopInstanceUID: 10    ‘1.3.6.1.4.1.44316.6.102.3.20250704114423666.30394198594456817768’, 11    modality: ‘CT’, 12    studyDate: ‘20151207’, 13    seriesNumber: NumberInt(‘1’), 14    instanceNumber: NumberInt(‘2’), 15    rows: NumberInt(‘1595’), 16    columns: NumberInt(‘888’) 17   }, 18   cbir: { 19    imageArea: NumberInt(‘1416360’), 20    aspectRatio: Double(‘0.56’), 21    resolutionClass: ‘HIGH’, 22    sliceCategory: ‘AXIAL’, 23    complexityIndex: NumberInt(‘1416360’) 24   }, 25   ingestedAt: ISODate(‘2025-12-13T20:42:34.500Z’) 26  }

In this example, the stored instance corresponds to a CT image with a resolution of $1595\times 888$ pixels, classified as HIGH resolution and AXIAL orientation. The document also stores its calculated image area and aspect ratio, which are available as candidate attributes during the fragmentation process. The cbir object contained in dicom_instances stores lightweight derived image attributes that can be directly employed during workload analysis and predicate generation, including image area, aspect ratio, resolution class, slice category, and complexity index. High-dimensional visual representations are not duplicated in this document. Instead, they are maintained in the cbir_descriptors collection, which references the corresponding medical image through instanceId and gridfsFileId. This separation keeps frequently queried metadata close to the DICOM instance while isolating computationally intensive visual descriptors in a dedicated collection.

4.2. Experimental Environment

The experimental evaluation was initially conducted using three distributed sites. Site 1 corresponded to a physical workstation running Windows 11 and equipped with an AMD Ryzen 7000 Series processor, an NVIDIA GeForce RTX graphics card, 23 GB of RAM, 0.5 TB of NVMe SSD storage, and a network interface with a nominal capacity of 10 Gbps. This workstation hosted the original MEDIFRAG database and served as the primary orchestration node during the fragmentation process.

Sites 2 and 3 were deployed as independent virtual machines using Oracle VirtualBox (version 7.2.4). Both sites ran Ubuntu Server 22.04 LTS and MongoDB as the database management system. Each virtual machine was configured with 5 virtual CPU cores, 2 GB of RAM, and a 10 GB virtual storage device. These sites were used as candidate destinations for fragment allocation and materialization.

The original experimental environment combined actual distributed execution with controlled heterogeneous hardware profiles. These profiles allowed the proposed cost model to represent differences in processing capacity, memory resources, storage characteristics, network capabilities, PCIe resources, and enterprise-oriented features. The resulting descriptors were subsequently incorporated into the server-scoring model and the quadratic penalty function proposed in this work, enabling KÁIXAR to rank the candidate destination sites for each generated fragment.

Table 8 summarizes the hardware and software configuration of the infrastructure used in the original experimental evaluation.

Table 8. Experimental environment used for the original evaluation of KÁIXAR.

Site	IP	OS	CPU	RAM	Storage	Role
1	127.0.0.1	Windows 11	Ryzen 7000 + RTX	23 GB	0.5 TB SSD	Original DB
2	192.168.0.96	Ubuntu 22.04 LTS (VM)	5 vCPU	2 GB	10 GB	Destination Site
3	192.168.0.97	Ubuntu 22.04 LTS (VM)	5 vCPU	2 GB	10 GB	Destination Site

The loopback address 127.0.0.1 shown for Site 1 represents the local endpoint through which the orchestration process accessed the centralized MEDIFRAG database. It should therefore not be interpreted as a routable address belonging to the network segment used by the virtual destination sites.

Unlike fragmentation approaches based exclusively on workload information, the proposed method additionally incorporates hardware-aware allocation criteria. Accordingly, server descriptors representing CPU resources, memory capacity, storage characteristics, network connectivity, and other hardware-related capabilities were considered when estimating the relative suitability of candidate destination sites. In the original evaluation, MEDIFRAG was hosted on Site 1, whereas Sites 2 and 3 were used as fragment destinations. This configuration enabled the analysis of fragmentation quality and fragment-placement decisions under controlled distributed execution conditions.

The original evaluation therefore combined an actual distributed testbed with controlled synthetic hardware profiles. The physical workstation and the two virtual machines described in Table 8 were used for database deployment, workload execution, predicate evaluation, document counting, fragment generation and materialization, and execution-time measurement. However, because enterprise-grade heterogeneous servers were not available in the laboratory during the initial experiments, the hardware descriptors required by the server-scoring model—including CPU cores, RAM, storage technology and capacity, network bandwidth, PCIe capabilities, and enterprise-oriented features—were represented through controlled synthetic profiles.

These synthetic descriptors were used exclusively by the hardware-aware allocation component to calculate server scores, quadratic penalty values, and fragment-destination rankings. They did not modify the execution times measured on the actual testbed, the number of documents satisfying each query predicate, the contents of the generated fragments, or the corresponding materialization results. Consequently, the performance values reported for the original experiment correspond to measurements obtained from the actual workstation and virtual machines, whereas the hardware-aware allocation component of that experiment represents a controlled simulation of heterogeneous server capabilities.

Additional physical-site validation. To complement the original virtualized evaluation, an additional experiment was conducted using two independent physical sites with different hardware characteristics. This experiment constituted a separate validation scenario and did not replace or modify the results obtained from the original environment.

The physical environment consisted of SRV-006 (192.168.68.96), equipped with 8 CPU cores, 24 GB of RAM, 0.5 TB of NVMe SSD storage, and PCIe 3.0 with 48 lanes, and SRV-009 (192.168.68.97), equipped with 2 CPU cores, 12 GB of RAM, 0.256 TB of NVMe SSD storage, and PCIe 3.0 with 4 lanes. Therefore, the additional experiment provided an actual heterogeneous physical deployment.

The physical validation was deployed on the 192.168.68.0/24 network, independently from the 192.168.0.0/24 segment used in the original virtualized environment.

For this validation, the fragmentation schemes generated by KÁIXAR and XAMANA were physically materialized across the two sites and evaluated using the same set of 200 high-workload queries. Each query was preceded by three warm-up executions and subsequently measured ten times per method. The execution order of KÁIXAR and XAMANA was alternated across repetitions to reduce systematic ordering and cache effects.

Distributed result reconstruction was performed during the actual execution and was therefore included in the measured latency. For the statistical analysis, one mean latency value per query and method was used as the experimental unit, yielding 200 paired observations and avoiding pseudoreplication. Result completeness was also verified against the expected selectivity of each query predicate.

4.3. Evaluation of KÁIXAR Against the Centralized Database

The fragmentation schemes generated by KÁIXAR are analyzed under three workload scenarios of increasing complexity, considering low-, medium-, and high-workload conditions. For each scenario, the generated MCRUD matrices, ALP values, fragmentation predicates, fragment allocation decisions, and query execution results are presented and compared against the original centralized database.

4.3.1. Scenario 1: Low Workload (12 Operations)

In this case study, the behavior of the proposed method is evaluated under a low-workload scenario composed of a set of queries executed on the dicom_instances collection of the MEDIFRAG database. The workload was generated using the KÁIXAR SimulQuery tool, which allows the simulation of FIND, UPDATE, INSERT, and DELETE operations over structured attributes derived from the DICOM standard. This scenario was designed to assess the ability of the proposed method to identify relevant fragmentation attributes, generate fragmentation schemes, and allocate fragments efficiently when the number of recorded operations is limited.

Figure 5 shows the KÁIXAR configuration used for the low-workload scenario. Since the workload contains fewer than 100 operations, the Top 20% workload optimization strategy is not applied. Therefore, the complete workload log is considered during the fragmentation process, allowing the baseline behavior of the proposed method to be evaluated.

Figure 5. Configuration of KÁIXAR without Top 20% workload optimization for the low-workload scenario.

From the generated workload log, KÁIXAR constructs the MCRUD matrix shown in Figure 6. This matrix summarizes the frequency and type of operations associated with each candidate attribute, providing the basis for identifying the most relevant fragmentation attributes.

Figure 6. MCRUD matrix generated from the workload analyzed in the low-workload scenario. Blue (R), orange (U), and red (D) indicate read, update, and delete operations, respectively.

Based on the MCRUD matrix, KÁIXAR computes the ALP values shown in Figure 7. These values indicate the relevance of each attribute according to the access patterns observed in the workload. Table 9 presents the numerical ALP values used to select the fragmentation attribute.

Figure 7. ALP values obtained for the low-workload scenario. The yellow highlighting indicates the attribute with the highest value, selected for horizontal fragmentation.

Table 9. ALP value calculation for each candidate fragmentation attribute in Case 1.

Attribute	ALP Calculation	ALP Value
dicom.modality	$\begin{array}{cc}& (1\times 3880\times 1\times 2)+(1\times 3880\times 3\times 2)\hfill \\ & +(1\times 3880\times 1\times 2)+(1\times 560\times 1\times 2)\hfill \end{array}$	39,920
cbir.resolutionClass	$\begin{array}{cc}& (1\times 4352\times 1\times 2)+(1\times 4352\times 3\times 2)\hfill \\ & +(1\times 0\times 2\times 2)+(1\times 0\times 1\times 2)\hfill \end{array}$	34,816
cbir.sliceCategory	$(1\times 4468\times 1\times 2)$	8936
dicom.rows	$(1\times 4308\times 1\times 2)$	8616
dicom.studyDate	$(1\times 3880\times 1\times 2)$	7760
dicom.seriesNumber	$(1\times 144\times 3\times 2)$	864

Note: Bold values indicate the final calculated ALP scores for each candidate fragmentation attribute.

For the ALP calculation, KÁIXAR distinguishes between simple and compound predicates according to the semantic role of the attributes involved in each workload operation. In a simple predicate, the queried attribute is directly considered the driving attribute because it constitutes the only criterion used to define the corresponding data access. Therefore, its contribution is assigned entirely to that attribute. Examples include queries based exclusively on dicom.modality, cbir.resolutionClass, cbir.sliceCategory, dicom.studyDate, or dicom.seriesNumber. This direct association allows the ALP table to reflect the relevance of attributes that independently determine the selection of medical records in the observed workload.

For compound predicates, KÁIXAR distinguishes between the driving attribute and the auxiliary attributes used to further restrict the result set. The driving attribute represents the primary semantic criterion that motivates the query, whereas the remaining attributes act as complementary filtering conditions. The complete predicate is preserved during query evaluation so that all of its conditions contribute to determining the actual set of matching documents. However, the resulting workload contribution is assigned only to the driving attribute. For instance, in a query combining dicom.modality and cbir.resolutionClass, modality represents the primary access criterion, while resolution class refines the resulting subset. Likewise, when dicom.rows and dicom.columns occur together, both conditions participate in evaluating the predicate, but only the attribute identified as the driving criterion contributes to the corresponding ALP entry.

This distinction prevents the relevance of auxiliary attributes from being artificially inflated merely because they repeatedly occur as secondary restrictions within compound predicates. Such behavior is particularly important in medical databases, where attributes such as dicom.modality may convey a more meaningful organizational criterion than structural properties such as image dimensions. Consequently, the ALP values reported in Figure 7 and Table 9 represent the predominant access semantics of the workload rather than a simple accumulation of every attribute appearing in each predicate. This treatment provides a more coherent basis for selecting the fragmentation attribute while preserving the full filtering semantics of both simple and compound queries.

The ALP values were calculated using only the workload-dependent component represented by the summation term in Equation (1), namely, $F_j\times Ntuple{s}_j\times VD{O}_j\times V{R}_j$. For each candidate attribute, the contributions of the workload operations whose predicates were associated with that attribute were accumulated. The $ServerPenalt{y}_i$ term was not considered in the ALP calculation because it represents the hardware and network characteristics of the evaluated server and is subsequently used to estimate fragment allocation costs. In the low-workload scenario, each operation occurred once in the workload log; therefore, $F_j=1$. The CRUD weights were defined as $R=1$, $C=2$, $U=3$, and $D=2$, while a locality factor of $V{R}_j=2$ was assigned to remote accesses. The attribute dicom.modality obtained the highest ALP value, with 39,920, followed by cbir.resolutionClass, with 34,816. Consequently, dicom.modality was selected as the primary fragmentation attribute for the low-workload scenario.

After identifying the fragmentation attribute through the ALP model, KÁIXAR evaluates the available destination sites using the proposed server penalty model. This analysis considers hardware characteristics such as CPU resources, memory capacity, storage technology, network bandwidth, and PCIe bus capabilities. The resulting penalty value is incorporated into the cost model to estimate the suitability of each candidate site for fragment allocation.

Figure 8 presents the server penalty analysis performed for the evaluated environment. Lower penalty values indicate more capable servers and therefore more favorable destinations for fragment materialization. This approach allows the allocation process to consider not only workload characteristics but also the underlying hardware infrastructure.

Figure 8. Server penalty analysis used by KÁIXAR during fragment allocation. Hardware characteristics such as CPU, memory, storage, network bandwidth, and PCIe capabilities are evaluated to estimate the penalty associated with each candidate site. Green indicates the lowest penalty, while red indicates the highest penalty.

The penalty values reported in Table 10 were obtained in two stages. First, the CPU, RAM, storage, network, and chipset scores were calculated using Equations (3)–(8). These component scores were subsequently combined using Equation (2), resulting in total server scores of 45.50 for 192.168.0.96, 23.64 for 192.168.0.97, and 15.91 for 127.0.0.1.

Table 10. Quadratic penalty values calculated for the evaluated sites.

Site	Score	Penalty Function Evaluation	Penalty
192.168.0.96	45.50	$0.001(45.50-15.91)(45.50-45.50)-\left({\displaystyle \frac{9}{45.50-15.91}}\right)(45.50-15.91)+10$	1.00
192.168.0.97	23.64	$0.001(23.64-15.91)(23.64-45.50)-\left({\displaystyle \frac{9}{45.50-15.91}}\right)(23.64-15.91)+10$	7.48
127.0.0.1	15.91	$0.001(15.91-15.91)(15.91-45.50)-\left({\displaystyle \frac{9}{45.50-15.91}}\right)(15.91-15.91)+10$	10.00

Note: Bold values indicate the minimum and maximum server penalties among the evaluated sites.

The total server score was obtained by first calculating the individual hardware-component scores using Equations (3)–(8) and subsequently combining them according to the weighting scheme defined in Equation (2). For instance, for Site 192.168.0.96, Equations (3) and (4) produced a $CPUScore$ of 25.00 and a $RAMScore$ of 12.50, respectively. The storage configuration, consisting of an NVMe SSD with 50 TB of capacity, yielded a $StorageScore$ of 100.00 according to Equations (5) and (6), whereas the 10 Gbps network connection resulted in a $NetworkScore$ of 25.00 using Equation (7). Finally, the PCIe 4.0 configuration with 32 lanes and enterprise-grade features produced a $ChipsetScore$ of 65.00 according to Equation (8). Substituting these values into Equation (2) gives $(25.00\times 0.25)+(12.50\times 0.20)+(100.00\times 0.20)+(25.00\times 0.15)+(65.00\times 0.20)=45.50$. Following the same procedure, Site 192.168.0.97 obtained component scores of 18.75, 9.375, 46.00, 12.50, and 30.00 for CPU, RAM, storage, network, and chipset, respectively, resulting in a $TotalScore$ of 23.64. Likewise, the local site 127.0.0.1 obtained scores of 12.50, 6.25, 30.80, 2.50, and 25.00, producing a $TotalScore$ of 15.91. These resulting scores are subsequently used as the input values of the quadratic penalty function defined in Equation (10).

Each total score was then substituted into the quadratic penalty function defined in Equation (10), using $a=0.001$, $S_{\min }=15.91$, and $S_{\max }=45.50$. For example, the penalty for Site 192.168.0.96 was obtained as $0.001(45.50-15.91)(45.50-45.50)-{\displaystyle \frac{9}{45.50-15.91}}(45.50-15.91)+10$, which yields 1.00 after rounding to two decimal places. Applying the same procedure to the remaining sites produced penalty values of 7.48 for 192.168.0.97 and 10.00 for 127.0.0.1. Lower penalty values indicate more favorable hardware and network characteristics for fragment allocation.

As shown in Table 10, Site 2 (192.168.0.96) obtained the lowest penalty value (1.00), indicating the highest processing capability among the evaluated servers. In contrast, the local database server (127.0.0.1) obtained the highest penalty value (10.00), reflecting less favorable hardware characteristics according to the proposed evaluation model. These penalty values are subsequently incorporated into the allocation cost model to determine the most suitable destination site for each generated fragment.

The fragment allocation process is performed using the cost model defined in Equation (1). For each generated fragment, KÁIXAR evaluates the candidate destination sites and constructs a cost matrix containing the estimated allocation costs. When a fragment is required by multiple sites, the destination is selected according to the minimum cost obtained from the evaluated alternatives. Conversely, if only one site requires the fragment, the allocation is performed directly to that site after cost evaluation. Residual fragments are not relocated and therefore remain stored at the original database site, producing an allocation cost equal to zero.

While the ALP model determines the most representative attribute for fragmentation, the server penalty model is subsequently used to identify the most suitable destination site for each generated fragment. Therefore, the fragmentation decision and the allocation decision are treated as independent optimization stages within KÁIXAR.

Table 11 summarizes the fragment allocation costs obtained for the low-workload scenario.

Table 11. Fragment allocation cost evaluation for the low-workload scenario.

Frag.	Orig. Site	Selected Cost Evaluation	Assigned Site	Selected Cost
F1	192.168.0.96	$\begin{array}{cc}\hfill 1.00\times & [(1\times 3880\times 1\times 1)\hfill \\ & +(1\times 3880\times 3\times 1)\hfill \\ & +(1\times 3880\times 1\times 1)\hfill \\ & +(1\times 3880\times 1\times 2)\hfill \\ & +(1\times 3880\times 3\times 2)\hfill \\ & +(1\times 3880\times 1\times 2)\hfill \\ & +(1\times 3872\times 1\times 2)\hfill \\ & +(1\times 3880\times 1\times 1)\hfill \\ & +(1\times 8\times 3\times 1)]\hfill \end{array}$	192.168.0.96	69,848.00
F2	192.168.0.97	$\begin{array}{cc}\hfill 7.4807\times & \left[\right(1\times 444\times 1\times 1)\hfill \\ & +(1\times 444\times 3\times 1)\hfill \\ & +(1\times 560\times 1\times 1)\hfill \\ & +(1\times 560\times 1\times 1)\hfill \\ & +(1\times 436\times 1\times 1)\hfill \\ & +(1\times 108\times 3\times 2)]\hfill \end{array}$	192.168.0.97	29,773.19
Residual	127.0.0.1	No reallocation	127.0.0.1	0.00

Note: Bold values indicate the final selected allocation costs for each fragment, including the residual fragment.

As shown in Table 11, fragment F1 was allocated to Site 192.168.0.96, while fragment F2 was assigned to Site 192.168.0.97, corresponding in both cases to the locations that produced the lowest estimated allocation cost according to the proposed model. Since only one destination site required each fragment in this scenario, the allocation process was performed directly after evaluating the corresponding cost. The residual fragment remained stored at its original location because no relocation was required, resulting in an allocation cost of zero. These results illustrate how KÁIXAR combines workload characteristics and hardware-aware server evaluation to determine the most suitable destination for each generated fragment.

Using the selected attribute and the estimated allocation costs, KÁIXAR generates the horizontal fragmentation scheme shown in Figure 9. The scheme includes the generated fragments, their predicates, overlap predicates, destination sites, number of tuples, and performance values. Based on the selected attribute (dicom.modality), KÁIXAR generated two primary fragments and one residual fragment. The fragments were distributed across the evaluated sites according to the minimum-cost allocation strategy. The residual fragment remained at the original database site because no reallocation was required.

Figure 9. Horizontal fragmentation scheme generated by KÁIXAR for the low-workload scenario. The green highlighted areas and stars indicate the assigned site for each fragment.

To formally describe the workload, the set of queries is defined as:

$$Q=\{q_1,q_2,q_3,\dots ,q_n\}$$

Here, each query $q_i$ consists of a predicate, an operation type, and an expected result set.

The performance evaluation considers the following metrics:

• $T_{total}$: total query execution time.
• $T_{avg}$: average query execution time.
• $T_{95}$: execution time adjusted to the 95th percentile.
• $Cov$: result coverage, $Obs/Exp$ for $Exp>0$, and 1 when $Obs=Exp=0$.
• $Obs$: number of observed results.
• $Exp$: number of expected results.

The use of the 95th percentile ($T_{95}$) provides a more robust estimate of response time by reducing the influence of outliers and transient execution fluctuations, thereby offering a more representative measure of system behavior under realistic operating conditions.

The generated fragmentation scheme is then materialized in the distributed environment. Figure 10 shows the materialization process performed by KÁIXAR, confirming that the generated fragments are physically created according to the selected allocation plan.

Figure 10. Materialization of the fragmentation scheme generated by KÁIXAR for the low-workload scenario.

Figure 11 and Figure 12 validate the creation of the fragmented collections in the distributed sites using MongoDB Compass. These figures confirm that the fragments were correctly deployed in Sites 2 and 3 according to the allocation plan generated by KÁIXAR.

Figure 11. Fragmented collections materialized in Site 2 for the low-workload scenario.

Figure 12. Fragmented collections materialized in Site 3 for the low-workload scenario.

Finally, Figure 13 shows the DICOM visualization module integrated into KÁIXAR. This viewer allows the user to inspect medical images and associated metadata after the fragmentation process, providing visual validation of the medical content managed by the system.

Figure 13. DICOM image visualization module integrated into KÁIXAR for inspecting medical images and associated metadata.

The workload queries used in this scenario are summarized in Table 12. The execution results obtained using the fragmentation scheme generated by KÁIXAR and the centralized database are presented in Table 13. Finally, Table 14 reports the adjusted results considering complete coverage ($Cov=1$).

Table 12. Workload queries used in the low-workload scenario.

Query	Origin Site	Predicate	Operation
$q_1$	192.168.0.96	modality = CT	FIND
$q_2$	192.168.0.96	modality = CT	UPDATE
$q_3$	192.168.0.96	modality = CT AND resolutionClass = HIGH	FIND
$q_4$	192.168.0.97	resolutionClass = HIGH	FIND
$q_5$	192.168.0.97	resolutionClass = HIGH	UPDATE
$q_6$	192.168.0.97	sliceCategory = AXIAL	FIND
$q_7$	192.168.0.97	modality = MR	FIND
$q_8$	192.168.0.97	rows = 512 AND columns = 512	FIND
$q_9$	192.168.0.97	resolutionClass = LOW	DELETE
$q_{10}$	192.168.0.97	resolutionClass = LOW AND sliceCategory = AXIAL	FIND
$q_{11}$	192.168.0.96	studyDate = 20151207	FIND
$q_{12}$	192.168.0.96	seriesNumber = 1	UPDATE

Note: For readability purposes, predicates are presented in a simplified notation. Internally, KÁIXAR translates each predicate into its corresponding MongoDB JSON query representation during workload execution and fragmentation analysis.

Table 13. Query execution results for the low-workload scenario using KÁIXAR and the centralized database.

	KÁIXAR						Centralized Database
Query	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$	Cov	Obs	Exp	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$
$q_1$	131.101	26.220	37.994	1.000	3880	3880	694.914	138.983	177.886
$q_2$	113.697	22.739	23.206	1.000	3880	3880	26.648	5.330	6.035
$q_3$	118.325	23.665	26.458	1.000	3880	3880	559.468	111.894	128.072
$q_4$	133.270	26.654	32.625	0.128	560	4352	629.094	125.819	137.306
$q_5$	107.151	21.430	23.251	0.128	560	4352	30.239	6.048	7.699
$q_6$	109.695	21.939	24.658	0.125	560	4468	660.456	132.091	143.863
$q_7$	68.809	13.762	15.322	1.000	560	560	89.335	17.867	20.842
$q_8$	129.567	25.913	30.108	1.000	560	560	584.924	116.985	134.314
$q_9$	44.648	8.930	10.494	1.000	0	0	11.335	2.267	3.111
$q_{10}$	44.252	8.850	10.057	1.000	0	0	9.772	1.954	2.188
$q_{11}$	80.704	16.141	17.198	1.000	3880	3880	568.040	113.608	117.374
$q_{12}$	59.576	11.915	56.597	0.806	116	144	32.931	6.586	7.316

Note: Bold values indicate the lowest execution time obtained for each query and metric.

Table 14. Coverage-adjusted execution results ($Cov=1$) for the low-workload scenario using KÁIXAR.

	KÁIXAR (Adjusted)			Centralized Database
Query	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$
$q_4$	134.074	26.815	32.820	629.094	125.819	137.306
$q_5$	107.798	21.559	23.391	30.239	6.048	7.699
$q_6$	110.357	22.071	24.807	660.456	132.091	143.863
$q_{12}$	73.916	14.783	70.220	32.931	6.586	7.316

Note: Bold values indicate the lowest execution time obtained for each query and metric. Only queries with coverage values lower than 1.0 in Table 13 are included. The reported KÁIXAR execution times were adjusted to incorporate the measured cost of retrieving the missing tuples required to achieve complete coverage ($Cov=1$). This adjustment includes the additional overhead actually measured during inter-fragment operations required to reconstruct the complete result set.

The results presented in Table 14 show that, even after adjusting the execution times to account for complete result reconstruction, KÁIXAR maintains a substantial performance advantage over the centralized database for retrieval operations. Queries $q_4$ and $q_6$ continue to exhibit significantly lower response times, while the increase observed in $q_{12}$ reflects the additional overhead associated with recovering tuples distributed across multiple fragments. These results indicate that the proposed fragmentation scheme preserves high query performance while maintaining result completeness.

4.3.2. Scenario 2: Medium Workload (146 Operations)

In this second case study, the behavior of the proposed method is evaluated under a workload composed of 146 operations. This scenario enables the application of the workload optimization strategy based on selecting the 20% most representative queries (Top 20%). Unlike the previous case study, where all recorded operations were considered during the fragmentation process, this experiment focuses only on the queries with the highest frequency of occurrence. As a result, the workload analysis is simplified while preserving the most relevant access patterns, allowing the fragmentation scheme to be generated from the operations that have the greatest impact on system performance.

This approach follows the Pareto principle, assuming that a reduced subset of highly frequent operations captures most of the workload behavior and therefore provides sufficient information to generate an effective fragmentation scheme.

Figure 14 shows the configuration used for this scenario. Since the workload contains more than 100 operations, the Top 20% optimization mechanism is enabled and only the most representative queries are considered during workload analysis.

Figure 14. KÁIXAR configuration for the medium-workload scenario using the Top 20% workload optimization strategy.

As shown in Table 15, the selected workload contains the queries with the highest execution frequency. Consequently, the resulting workload preserves the dominant access patterns observed in the original workload log while reducing the amount of information processed during workload analysis.

Table 15. Workload queries used in the medium-workload scenario considering the Top 20% most frequent queries.

Query	Origin Site	Predicate	Operation
$q_1$	192.168.0.96	modality = CT AND rows ≥ 512	FIND
$q_2$	192.168.0.97	resolutionClass = HIGH	UPDATE
$q_3$	192.168.0.97	seriesNumber = 0	DELETE
$q_4$	192.168.0.97	rows = 512 AND columns = 512	FIND
$q_5$	192.168.0.97	seriesNumber = 1	FIND
$q_6$	192.168.0.97	modality = MR	FIND
$q_7$	192.168.0.96	modality = XC	FIND
$q_8$	192.168.0.96	Composite query (DICOM + CBIR)	FIND
$q_9$	192.168.0.96	Composite query (MR + Resolution)	FIND
$q_{10}$	192.168.0.96	Composite query (CT + CBIR + AXIAL)	FIND
$q_{11}$	192.168.0.96	CBIR query (MEDIUM + AXIAL)	FIND
$q_{12}$	192.168.0.96	OPT + HIGH query	FIND
$q_{13}$	192.168.0.96	OP + HIGH + AXIAL query	FIND
$q_{14}$	192.168.0.96	Columns + MEDIUM query	FIND
$q_{15}$	192.168.0.96	Columns + HIGH + AXIAL query	FIND
$q_{16}$	192.168.0.96	Columns + Study query	FIND
$q_{17}$	192.168.0.97	CBIR HIGH + AXIAL query	FIND
$q_{18}$	192.168.0.96	High-resolution query	FIND
$q_{19}$	192.168.0.96	Rows/Columns + HIGH query	FIND
$q_{20}$	192.168.0.96	MEDIUM + Area query	FIND
$q_{21}$	192.168.0.96	modality = CT AND rows ≥ 100	FIND
$q_{22}$	192.168.0.96	modality = CT AND rows ≥ 11	FIND
$q_{23}$	192.168.0.96	modality = CT AND rows ≥ 12	FIND
$q_{24}$	192.168.0.97	modality = CT AND rows ≥ 13	FIND
$q_{25}$	192.168.0.96	modality = CT AND rows ≥ 14	FIND
$q_{26}$	192.168.0.96	modality = CT AND rows ≥ 15	FIND
$q_{27}$	192.168.0.96	modality = CT AND rows ≥ 16	FIND
$q_{28}$	192.168.0.96	modality = CT AND rows ≥ 17	FIND
$q_{29}$	192.168.0.96	modality = CT AND rows ≥ 18	FIND
$q_{30}$	192.168.0.96	modality = CT AND rows ≥ 19	FIND

Note: For readability purposes, predicates are presented using a simplified notation. Internally, KÁIXAR translates each predicate into its corresponding MongoDB JSON query representation during workload processing and fragmentation analysis.

Table 16 presents the fragmentation scheme generated by KÁIXAR after applying the Top 20% workload optimization strategy. The resulting scheme is based on the attribute dicom.modality, which exhibited the highest locality precedence value during workload analysis. Five fragments were generated, including a residual fragment. The allocation process assigned each fragment to the site with the lowest estimated execution cost according to the proposed hardware-aware cost model. Compared with the low-workload scenario, the resulting fragmentation scheme is more compact and better aligned with the dominant access patterns extracted from the workload log.

Table 16. Fragmentation scheme generated by KÁIXAR for the medium-workload scenario.

Fragment	Predicate	Original Site	Assigned Site	Min Cost	Tuples
DICOM_INSTANCES_F1	{“dicom.modality”:“CT”}	192.168.0.96	192.168.0.96	85,344.00	3880
DICOM_INSTANCES_F2	{“dicom.modality”:“MR”}	192.168.0.97	192.168.0.97	28,187.28	560
DICOM_INSTANCES_F3	{“dicom.modality”:“XC”}	192.168.0.96	192.168.0.96	160.00	16
DICOM_INSTANCES_F4	{“dicom.modality”:“OPT”}	192.168.0.96	192.168.0.96	84.00	8
DICOM_INSTANCES_F5	{“dicom.modality”:“OP”}	192.168.0.96	192.168.0.96	36.00	4

The fragmentation scheme generated for the medium-workload scenario consists of five fragments derived from the attribute dicom.modality, which obtained the highest locality precedence value during workload analysis. Compared with the low-workload scenario, the resulting scheme exhibits a more consolidated structure, where the dominant imaging modalities are clearly separated into independent fragments. This behavior indicates that the increased workload volume allows KÁIXAR to identify access patterns with greater confidence and generate more representative fragmentation decisions.

Table 17 presents the execution results obtained using the fragmentation scheme generated by KÁIXAR and the original centralized database. The results indicate that the proposed method achieves competitive execution times while analyzing only a reduced subset of the original workload. This behavior demonstrates that the Top 20% optimization strategy preserves the most representative access patterns required to generate an effective fragmentation scheme. An important observation is that the fragmentation scheme was generated using only 20% of the original workload. Despite this reduction, the resulting fragments preserved the dominant access patterns of the system and achieved competitive execution times across most evaluated queries. This result suggests that analyzing the complete workload is not always necessary to obtain effective fragmentation decisions.

Table 17. Query execution results for the medium-workload scenario considering the Top 20% most frequent queries using KÁIXAR and the centralized database.

	KÁIXAR						Centralized Database
Query	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$	Cov	Obs	Exp	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$
$q_1$	129.362	25.872	26.776	1.000	3880	3880	589.838	117.968	126.122
$q_2$	111.227	22.245	24.723	0.128	560	4352	20.048	4.010	4.842
$q_3$	94.146	18.829	20.611	1.000	0	0	23.744	4.749	5.029
$q_4$	149.549	29.910	31.567	0.129	560	4308	1115.496	223.099	308.644
$q_5$	36.464	7.293	8.842	0.250	36	144	119.851	23.970	27.480
$q_6$	30.114	6.023	7.268	1.000	560	560	170.072	34.014	37.316
$q_7$	31.745	6.349	8.741	1.000	16	16	187.925	37.585	41.853
$q_8$	90.478	18.096	22.191	1.000	0	0	7.096	1.419	1.626
$q_9$	90.975	18.195	20.988	0.000	0	8	8.939	1.788	2.044
$q_{10}$	23.169	4.634	5.203	1.000	0	0	102.136	20.427	22.792
$q_{11}$	84.666	16.933	18.167	0.000	0	8	8.698	1.740	2.242
$q_{12}$	92.061	18.412	19.716	1.000	8	8	6.207	1.241	1.437
$q_{13}$	98.048	19.610	22.769	1.000	0	0	6.669	1.334	1.856
$q_{14}$	87.375	17.475	19.725	1.000	0	0	6.461	1.292	1.500
$q_{15}$	98.893	19.779	22.465	1.000	20	20	7.033	1.407	1.681
$q_{16}$	183.634	36.727	38.941	0.000	0	432	29.710	5.942	7.368
$q_{17}$	133.460	26.692	28.510	0.129	560	4308	620.851	124.170	131.200
$q_{18}$	91.999	18.400	19.734	1.000	0	0	6.784	1.357	1.711
$q_{19}$	84.900	16.980	17.847	1.000	12	12	6.212	1.242	1.553
$q_{20}$	73.125	14.625	15.760	1.000	0	0	7.293	1.459	2.028
$q_{21}$	130.599	26.120	27.193	1.000	3880	3880	618.414	123.683	128.634
$q_{22}$	133.714	26.743	29.191	1.000	3880	3880	612.914	122.583	130.765
$q_{23}$	136.691	27.338	28.673	1.000	3880	3880	635.820	127.164	136.939
$q_{24}$	130.111	26.022	26.791	1.000	3880	3880	627.310	125.462	127.811
$q_{25}$	133.232	26.646	28.295	1.000	3880	3880	625.433	125.087	132.979
$q_{26}$	137.952	27.590	32.524	1.000	3880	3880	636.782	127.356	139.869
$q_{27}$	129.125	25.825	26.940	1.000	3880	3880	656.404	131.281	140.801
$q_{28}$	136.149	27.230	28.382	1.000	3880	3880	631.437	126.287	132.807
$q_{29}$	139.670	27.934	29.525	1.000	3880	3880	640.556	128.111	131.965
$q_{30}$	135.751	27.150	28.053	1.000	3880	3880	652.291	130.458	137.374

Note: Bold values indicate the lowest execution time obtained for each query and metric. The query predicates associated with each $q_i$ are described in Table 15.

From a practical perspective, workload reduction decreases the computational cost associated with workload analysis, MCRUD construction, ALP calculation, and fragmentation generation. Consequently, KÁIXAR is capable of producing representative fragmentation schemes while reducing preprocessing effort, which becomes increasingly relevant as workload size grows.

Furthermore, the obtained results indicate that the proposed method maintains high levels of result coverage and execution stability. Even when complete coverage reconstruction is considered, the additional overhead remains limited for most queries. These findings demonstrate that the workload optimization strategy preserves the essential workload characteristics required to generate efficient and scalable fragmentation schemes.

To provide a more conservative evaluation, Table 18 reports the adjusted execution results considering complete coverage ($Cov=1$). The reported values estimate the additional cost associated with reconstructing the complete result set when inter-fragment operations are required. The adjusted results remain stable across most queries, indicating that the fragmentation scheme maintains its effectiveness even when complete result reconstruction is considered.

Table 18. Coverage-adjusted execution-time estimates ($Cov=1$) for the medium-workload scenario using KÁIXAR.

	KÁIXAR (Adjusted)			Centralized Database
Query	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$
$q_2$	123.861	24.772	27.531	20.048	4.010	4.842
$q_4$	166.350	33.270	35.113	1115.496	223.099	308.644
$q_5$	145.854	29.171	35.368	119.851	23.970	27.480
$q_{11}$	94.539	18.908	20.211	8.698	1.740	2.242
$q_{16}$	195.807	39.161	42.275	29.710	5.942	7.368
$q_{17}$	148.454	29.691	31.713	620.851	124.170	131.200

Note: Only queries with coverage values lower than 1.0 in Table 17 are included. The reported KÁIXAR execution times were adjusted to incorporate the additional measured cost required to retrieve the missing tuples and achieve complete coverage ($Cov=1$). Bold values indicate the lowest execution time obtained for each query and metric.

Figure 15 and Figure 16 validate the physical deployment of the fragmentation scheme generated for the medium-workload scenario. The screenshots obtained from MongoDB Compass confirm that the fragments were successfully materialized and allocated according to the assignment strategy defined by KÁIXAR. This validation demonstrates the consistency between the generated fragmentation scheme and its implementation within the distributed environment.

Figure 15. Fragmented collections materialized in Site 2 for the medium-workload scenario.

Figure 16. Fragmented collections materialized in Site 3 for the medium-workload scenario.

Overall, the medium-workload scenario demonstrates that the Top 20% workload optimization strategy significantly reduces the amount of information required during workload analysis while preserving the dominant access patterns of the system. The resulting fragmentation scheme maintains competitive execution times and high coverage levels, confirming that representative workload subsets are effectively used to generate efficient fragmentation decisions in medical databases.

4.3.3. Scenario 3: High Workload (1000 Operations)

In this third case study, a high-workload scenario is analyzed using a log file containing 1000 operations executed on the dicom_instances collection of the MEDIFRAG database. Due to the large number of recorded operations, KÁIXAR automatically activates its workload optimization mechanism based on the Top 20% strategy. This mechanism reduces the analysis space by selecting only the most representative queries according to their frequency of occurrence, while preserving the access patterns that have the greatest impact on system performance. The optimization process is performed transparently to the user and follows the Pareto principle, assuming that a reduced subset of highly frequent operations captures most of the workload behavior.

In this scenario, the workload optimization strategy is automatically enabled because the analyzed log contains more than 100 recorded operations. Figure 17 shows the KÁIXAR interface after processing the workload file. The system indicates that the Top 20% strategy was applied, selecting 200 representative queries from the original set of 1000 operations. This mechanism reduces the amount of information analyzed while preserving the most significant access patterns observed in the workload.

Figure 17. KÁIXAR configuration for the high-workload scenario using the Top 20% workload optimization strategy.

The representative workload selected through the Top 20% strategy is presented in Table 19. The selected queries correspond to the most frequently executed operations identified in the original workload log and constitute the basis for the fragmentation process performed by KÁIXAR.

Table 19. Representative workload queries used in the high-workload scenario considering the Top 20% most frequent queries.

Query	Origin Site	Predicate	Operation
$q_1$	192.168.0.96	modality = CT	FIND
$q_2$	192.168.0.96	seriesNumber $=1$	FIND
$q_3$	192.168.0.96	rows $\ge 256$ AND columns $\ge 256$ AND resolutionClass = HIGH AND sliceCategory = AXIAL	FIND
$q_4$	192.168.0.96	columns $\ge 512$ AND $18293\le \mathrm{imageArea}\le 603968$	FIND
$q_5$	192.168.0.97	modality = MR AND studyInstanceUID = 1.3.6.1.4.1.44316.6.102.1. 2023091383923657.429661656218407401559	FIND
$q_6$	192.168.0.96	modality = XC AND studyInstanceUID = 1.3.6.1.4.1.44316.6.102.1. 2023091383923657.429661656218407401559	FIND
$q_7$	192.168.0.96	rows $\ge 1024$	FIND
$q_8$	192.168.0.96	columns $\ge 1024$	FIND
$q_9$	192.168.0.96	modality = CT AND rows $\ge 512$	FIND
$q_{10}$	192.168.0.96	modality = MR AND columns $\ge 512$	FIND
⋮	⋮	⋮	⋮
$q_{200}$	192.168.0.96/97	Representative Top 20% query	FIND

Note: The original workload consisted of 1000 operations. Following the workload optimization strategy described in Section 3, KÁIXAR automatically selected the 20% most representative queries according to their frequency of occurrence, resulting in a subset of 200 operations. Only representative examples are shown for readability purposes. Predicates are presented using a simplified notation; internally, KÁIXAR translates them into their corresponding MongoDB JSON query representation.

The representative workload obtained from the original log was used to generate the fragmentation scheme. Unlike the previous scenarios, the larger workload size provides a more stable representation of the dominant access patterns observed in the MEDIFRAG database. Consequently, the generated fragmentation scheme reflects the attributes and predicates that most frequently appear in the analyzed workload.

Table 20 presents the fragmentation scheme generated by KÁIXAR for the high-workload scenario. The resulting scheme was obtained using the proposed workload-driven fragmentation strategy and allocated according to the cost model described previously.

Table 20. Fragmentation scheme generated by KÁIXAR for the high-workload scenario.

Fragment	Predicate	Original Site	Assigned Site	Min Cost	Tuples
DICOM_INSTANCES_F1	{“dicom.modality”:“CT”}	192.168.0.96	192.168.0.96	209,529.00	3880
DICOM_INSTANCES_F2	{“dicom.modality”:“XC”}	192.168.0.96	192.168.0.96	134.00	16
DICOM_INSTANCES_F3	{“dicom.modality”:“OP”}	192.168.0.97	192.168.0.97	71.82	4
DICOM_INSTANCES_F4	{“dicom.modality”:“MR”}	192.168.0.96	192.168.0.96	3230.00	560
DICOM_INSTANCES_F5	{“dicom.modality”:“OPT”}	192.168.0.96	192.168.0.96	734.00	8

Note: Bold values indicate the minimum allocation cost selected for each fragment.

The generated fragmentation scheme consists of a reduced number of fragments associated with the most representative workload predicates. As workload size increases, the fragmentation process becomes more selective, concentrating data distribution decisions on the dominant access patterns. This behavior contributes to generating compact and efficient fragmentation schemes while reducing the complexity associated with workload analysis.

The results presented in Table 21 show that KÁIXAR maintains stable execution times even under a workload originally composed of 1000 operations. Since the evaluated queries correspond to the most representative operations extracted through the Top 20% strategy, the generated fragmentation scheme remains aligned with the dominant workload behavior while significantly reducing the amount of information processed during workload analysis.

Table 21. Query execution results for the high-workload scenario considering the Top 20% most frequent queries using KÁIXAR and the centralized database.

	KÁIXAR						Centralized Database
Query	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$	Cov	Obs	Exp	${\mathit{T}}_{\mathit{total}}$	${\mathit{T}}_{\mathit{avg}}$	${\mathit{T}}_{\mathbf{95}}$
$q_1$	44.789	8.958	11.322	1.000	3880	3880	12.903	2.581	4.467
$q_2$	105.799	21.160	24.217	1.000	4464	4464	552.120	110.424	122.014
$q_3$	46.059	9.212	9.285	1.000	0	0	13.573	2.715	3.575
$q_4$	46.682	9.336	10.901	1.000	8	8	10.362	2.072	2.555
$q_5$	43.651	8.730	9.332	1.000	0	0	10.124	2.025	2.718
$q_6$	47.935	9.587	10.663	1.000	0	0	12.154	2.431	2.975
$q_7$	140.022	28.004	30.349	1.000	3880	3880	10.052	2.010	2.762
$q_8$	57.233	11.447	15.067	1.000	8	8	693.297	138.659	148.090
$q_9$	47.811	9.562	10.749	1.000	8	8	14.300	2.860	3.804
$q_{10}$	48.175	9.635	10.109	1.000	20	20	14.563	2.913	3.327
⋮	⋮	⋮	⋮	⋮	⋮	⋮	⋮	⋮	⋮
$q_{100}$	96.018	19.203	21.027	1.000	4468	4468	608.931	121.786	136.820
$q_{150}$	96.703	19.340	20.813	1.000	4468	4468	515.782	103.156	114.131
$q_{200}$	97.236	19.447	23.572	1.000	4468	4468	673.224	134.645	163.403

Note: Bold values indicate the lowest execution time obtained for each query and metric. The workload corresponds to the 200 most representative operations automatically selected from the original log containing 1000 operations.

To validate the generated fragmentation scheme, the resulting collections were materialized within the distributed environment. Figure 18 and Figure 19 show the fragmented collections deployed in MongoDB Compass. The screenshots confirm that the fragments were successfully created and distributed according to the allocation plan generated by KÁIXAR.

Figure 18. Fragmented collections materialized in Site 2 for the high-workload scenario.

Figure 19. Fragmented collections materialized in Site 3 for the high-workload scenario.

The high-workload scenario demonstrates the scalability of the proposed fragmentation strategy. Although the original workload contained 1000 operations, only 200 representative queries were required to construct the fragmentation scheme. Despite this reduction, the generated scheme maintained complete coverage and competitive execution times across the evaluated queries.

An important observation is that the workload is predominantly composed of FIND operations, which is consistent with the behavior commonly observed in DICOM-based medical information systems. Consequently, prioritizing the most representative retrieval operations enables KÁIXAR to generate fragmentation schemes that are better aligned with real-world access patterns.

Overall, the obtained results indicate that the Top 20% workload optimization strategy reduces workload analysis complexity while preserving fragmentation quality, query performance, and data availability under intensive operating conditions.

4.4. Comparative Evaluation Against XAMANA

Finally, the performance of KÁIXAR is compared with the XAMANA system, a web application developed by Castro-Medina et al. [25] that implements a horizontal fragmentation method for multimedia databases supporting CBIR queries. The comparison is conducted using identical workload logs and execution environments to ensure a fair evaluation of both approaches with respect to fragmentation quality, query execution performance, and adaptation to workload characteristics. To evaluate the behavior of the fragmentation approaches under different workload conditions, three experimental scenarios were defined: a low-workload scenario composed of 12 operations, a medium-workload scenario containing 146 operations, and a high-workload scenario based on a workload log of 1000 operations. In all scenarios, the same set of queries was executed over the fragmentation schemes generated by both systems. Each query was executed five times to obtain representative performance metrics, including total execution time ($T_{total}$) and average execution time ($T_{avg}$).

Figure 20, Figure 21, Figure 22, Figure 23 and Figure 24 present the fragmentation schemes generated by XAMANA for each evaluated scenario. In the low-workload scenario, XAMANA produces a larger number of fragments due to the limited amount of workload information available during scheme generation. As the workload size increases, the generated schemes become progressively more consolidated, reflecting a better adaptation to the observed access patterns. These schemes provide the baseline used to compare the proposed KÁIXAR method in terms of fragmentation quality, data distribution, and workload adaptation.

Figure 20. Fragmentation scheme generated by XAMANA for the low-workload scenario (Case 1, Part 1).

Figure 21. Fragmentation scheme generated by XAMANA for the low-workload scenario (Case 1, Part 2).

Figure 22. Fragmentation scheme generated by XAMANA for the low-workload scenario (Case 1, Part 3).

Figure 23. Fragmentation scheme generated by XAMANA for the medium-workload scenario (Case 2). The larger workload allows the fragmentation process to better identify dominant access patterns, resulting in a more structured scheme.

Figure 24. Fragmentation scheme generated by XAMANA for the high-workload scenario (Case 3).

Figure 20, Figure 21 and Figure 22 present the fragmentation scheme generated by XAMANA for the low-workload scenario (Case 1). Due to the limited number of operations available in the workload log, the generated scheme contains a larger number of fragments distributed across multiple sites. The resulting fragmentation strategy is therefore more granular and less consolidated than those obtained under larger workloads.

The fragmentation schemes generated by XAMANA demonstrate the direct influence of workload size on the resulting fragmentation strategy. In the low-workload scenario, the limited number of operations leads to a highly granular scheme composed of numerous fragments distributed across multiple sites. As the workload becomes more representative, the fragmentation process identifies more stable access patterns, producing a more compact distribution strategy with fewer but more relevant predicates. This behavior suggests that XAMANA benefits from larger workload logs, allowing the generation of fragmentation schemes that more accurately reflect the dominant access characteristics of the database.

4.4.1. Scenario 1: Low Workload (12 Operations)

In the low-workload scenario, corresponding to a workload containing fewer than 100 operations, no workload optimization mechanisms were applied. Consequently, both KÁIXAR and XAMANA generated their fragmentation schemes using the complete set of recorded queries. This configuration allows the baseline behavior of both approaches to be evaluated under identical conditions, without the influence of workload reduction strategies such as the Top 20% optimization. The results obtained for Case 1 are presented in Table 22.

Table 22. Comparison of KÁIXAR and XAMANA under the low-workload scenario (Case 1).

Query	Operation	KÁIXAR ${\mathit{T}}_{\mathit{avg}}$ (ms)	XAMANA ${\mathit{T}}_{\mathit{avg}}$ (ms)
$q_1$	FIND	26.220	83.615
$q_2$	UPDATE	22.739	89.625
$q_3$	FIND	23.665	100.372
$q_4$	FIND	26.815	75.321
$q_5$	UPDATE	21.559	76.251
$q_6$	FIND	22.071	69.576
$q_7$	FIND	13.762	31.354
$q_8$	FIND	25.913	82.022
$q_9$	DELETE	8.930	28.663
$q_{10}$	FIND	8.850	31.065
$q_{11}$	FIND	16.141	64.694
$q_{12}$	UPDATE	14.783	27.648

Note: The predicates associated with each query are described in Table 12. Bold values indicate the lowest average execution time.

Table 22 shows that KÁIXAR consistently outperforms XAMANA in all evaluated operations under the low-workload scenario. The proposed method achieves lower average execution times for both retrieval and update operations, with improvements particularly noticeable in queries involving DICOM metadata and CBIR attributes. These results suggest that the workload-driven fragmentation strategy implemented in KÁIXAR provides a more efficient distribution of data, reducing unnecessary accesses and minimizing the amount of information processed during query execution.

In contrast, XAMANA exhibits higher execution times across all evaluated queries, indicating a greater processing overhead when accessing fragmented data. Although both approaches satisfy the fragmentation correctness properties, the results demonstrate that KÁIXAR is able to exploit workload characteristics more effectively, leading to improved query performance even in scenarios where workload optimization techniques are not applied. Consequently, the proposed method provides a more efficient baseline fragmentation scheme for medical multimedia databases.

4.4.2. Scenario 2: Medium Workload (146 Operations)

In the medium-workload scenario, 30 representative queries extracted from the workload log were evaluated, corresponding to the Top 20% workload retained by KÁIXAR. The results obtained for Case 2 are presented in Table 23.

Table 23. Comparison of KÁIXAR and XAMANA under the medium-workload scenario (Case 2).

Query	Operation	KÁIXAR ${\mathit{T}}_{\mathit{avg}}$ (ms)	XAMANA ${\mathit{T}}_{\mathit{avg}}$ (ms)
$q_1$	FIND	25.872	15.107
$q_2$	UPDATE	22.245	13.402
$q_3$	DELETE	18.829	6.169
$q_4$	FIND	29.910	15.584
$q_5$	FIND	7.293	6.988
$q_6$	FIND	6.023	7.962
$q_7$	FIND	6.349	5.822
$q_8$	FIND	18.096	7.700
$q_9$	FIND	18.195	5.693
$q_{10}$	FIND	4.634	8.604
$q_{11}$	FIND	16.933	5.615
$q_{12}$	FIND	18.412	6.353
$q_{13}$	FIND	19.610	8.571
$q_{14}$	FIND	17.475	5.791
$q_{15}$	FIND	19.779	7.747
$q_{16}$	FIND	36.727	7.840
$q_{17}$	FIND	26.692	15.620
$q_{18}$	FIND	18.400	8.007
$q_{19}$	FIND	16.980	6.442
$q_{20}$	FIND	14.625	6.283
$q_{21}$	FIND	26.120	11.992
$q_{22}$	FIND	26.743	12.053
$q_{23}$	FIND	27.338	11.776
$q_{24}$	FIND	26.022	12.565
$q_{25}$	FIND	26.646	12.494
$q_{26}$	FIND	27.590	14.070
$q_{27}$	FIND	25.825	11.966
$q_{28}$	FIND	27.230	12.359
$q_{29}$	FIND	27.934	10.533
$q_{30}$	FIND	27.150	11.154

Note: The predicates associated with each query are described in Table 15. Bold values indicate the lowest average execution time obtained for each query.

As shown in Table 23, XAMANA achieved lower mean execution time for 28 of 30 queries. This behavior differs from that observed in the high-workload scenario and illustrates the scenario-dependent nature of the comparative performance of both fragmentation approaches. Whereas XAMANA constructs its fragmentation scheme from the complete workload, KÁIXAR deliberately reduces the workload representation before generating the fragmentation scheme.

To investigate this behavior without introducing an additional experimental configuration, the frequency distribution of the original medium-workload log was analyzed. The workload contained 130 distinct aggregated access patterns representing 146 recorded operations. Of these patterns, 123 (94.6%) occurred only once, six occurred twice, and only one pattern exhibited a substantially higher frequency (11 occurrences). Therefore, the workload presents a weakly concentrated frequency distribution with a pronounced long tail of infrequent access patterns.

As illustrated in Figure 25, the 20% most frequent distinct access patterns account for only approximately 28.8% of the recorded operations, while approximately 77.7% of the distinct patterns are required to represent 80% of the workload. This distribution differs from a strongly concentrated Pareto-like workload and indicates that a considerable amount of workload information is distributed among low-frequency access patterns.

Figure 25. Cumulative concentration of access-pattern frequencies in the medium-workload scenario. Patterns are ordered from highest to lowest frequency. The low concentration of the curve indicates a workload dominated by a long tail of infrequent access patterns. The dashed blue vertical and horizontal lines indicate the 20% access-pattern reference and the 80% cumulative-operation threshold, respectively.

This workload structure provides a plausible explanation for the performance observed in Table 23. KÁIXAR prioritizes the most representative workload information and ultimately selects dicom.modality as the dominant fragmentation attribute, producing five modality-based fragments. In contrast, XAMANA processes the complete workload and generates a fragmentation scheme containing predicates associated with several access dimensions, including modality, resolution class, and slice category. Under a workload in which most access patterns occur with very low frequency, retaining the complete log can preserve information about a larger number of infrequent predicates that may remain relevant to individual queries.

Accordingly, the lower latency obtained by XAMANA in this scenario should not be interpreted as a contradiction of the workload-reduction strategy, but as evidence of its trade-off. KÁIXAR reduces the amount of workload information used during fragmentation design and emphasizes dominant access patterns, whereas a complete-log approach may be advantageous when the workload is highly diverse and no small subset strongly dominates the access distribution. This observation is consistent with the workload-retention analysis discussed in Section 5, which indicates that the benefits of workload reduction depend on the concentration and diversity of the evaluated access patterns.

4.4.3. Scenario 3: High Workload (1000 Operations)

Finally, in the high-workload scenario (Case 3), a total of 200 representative queries were evaluated. These queries correspond to the Top 20% most frequent operations automatically selected by KÁIXAR from an original workload log containing 1000 operations. Since the selected workload is predominantly composed of FIND operations, this scenario provides a suitable environment for evaluating the scalability and query-processing capabilities of the proposed fragmentation strategy under intensive access conditions.

Due to the large number of evaluated queries, the results are presented in summarized form in Table 24. The reported values correspond to the execution times obtained after five repetitions per query, allowing the effects of temporal fluctuations and transient system conditions to be reduced.

Table 24. Comparison of KÁIXAR and XAMANA under the high-workload scenario in the original virtualized environment (Case 3).

Metric	KÁIXAR	XAMANA
Number of Queries	200	200
Average Query Time (ms)	27.551	38.979
Sum of Average Times (ms)	5510.200	7795.800
Total Accumulated Time (ms)	27,551.000	38,979.000

Note: Results correspond to the execution of 200 representative queries selected through the Top 20% workload optimization strategy. Each query was executed five times and the reported values represent aggregated execution statistics. Bold values highlight the execution-time results achieved by KÁIXAR.

As shown in Table 24 and Figure 26, the original high-workload experiment favored KÁIXAR over XAMANA. Mean query execution time decreased from 38.979 ms to 27.551 ms, corresponding to a reduction of approximately 29.32%. The accumulated execution-time measures showed the same direction because they were derived from the same workload execution set. This result motivated an additional validation to determine whether the observed advantage persisted when both fragmentation schemes were deployed on physically heterogeneous sites.

Figure 26. Performance comparison between KÁIXAR and XAMANA under the high-workload scenario in the original virtualized environment.

Additional physical-site validation. To complement the original high-workload comparison and evaluate whether the observed performance advantage persisted beyond the virtualized environment, KÁIXAR and XAMANA were subsequently evaluated using two physically heterogeneous sites. This experiment constituted an independent validation of the high-workload scenario and did not replace or modify the measurements reported above. The results of this additional physical-site validation are presented in Figure 27.

Figure 27. Performance comparison between KÁIXAR and XAMANA under the high-workload scenario using physical sites. Mean query latency was computed from 200 paired queries, each measured ten times after three warm-up executions.

In the physical deployment, KÁIXAR achieved a mean query latency of 15.062 ms, whereas XAMANA required 108.735 ms, corresponding to an 86.15% reduction in mean latency and a 7.22× speedup. KÁIXAR exhibited lower mean latency in 199 of the 200 paired queries, while XAMANA achieved lower latency in one query. No ties were observed. The detailed statistical comparison is presented in Table 25.

Table 25. Statistical comparison of KÁIXAR and XAMANA under the high-workload scenario using physical sites.

Metric	KÁIXAR	XAMANA	Comparative Result
Experimental configuration
Number of evaluated queries	200	200	Same paired workload
Measured repetitions per query	10	10	Same protocol
Warm-up executions per query	3	3	Same protocol
Number of fragments	5	3	Method-specific schemes
Unique dataset documents	4468	4468	Complete physical dataset
Execution-time performance
Mean query latency (ms)	15.062	108.735	86.15% reduction
Sum of query mean times (ms)	3012.306	21,747.059	–
Total accumulated measured time (ms)	30,123.060	217,470.592	–
Speedup	7.22×	1.00×	KÁIXAR relative to XAMANA
Queries with lower mean latency	199	1	0 ties
Paired statistical analysis of latency
Mean paired difference, XAMANA–KÁIXAR (ms)	93.674		Favors KÁIXAR
95% CI of paired difference (ms)	[69.709, 117.638]		Does not include zero
Shapiro–Wilk test	$p<0.001$		Non-normal paired differences
Primary inferential test	Wilcoxon signed-rank		Paired non-parametric test
Wilcoxon signed-rank	$p<0.001$		Statistically significant
Cohen’s $d_z$	0.545		Moderate standardized effect
Rank-biserial correlation	0.985		Strong directional effect

Note: Bold formatting identifies the main metric categories and highlights the key performance results achieved by KÁIXAR, including lower execution times, latency reduction, speedup, and the number of queries with lower latency.

The paired statistical analysis provides additional evidence that the latency difference observed in the physical deployment was not limited to a difference between aggregate means. Because the paired latency differences did not satisfy the normality assumption according to the Shapiro–Wilk test ($p<0.001$), the Wilcoxon signed-rank test was adopted as the primary inferential test. The difference between KÁIXAR and XAMANA was statistically significant ($p<0.001$), with a mean paired difference of 93.674 ms and a 95% confidence interval of [69.709, 117.638] ms.

The rank-biserial correlation ($r_{rb}=0.985$) indicated a strong directional effect in favor of KÁIXAR, whereas Cohen’s $d_z=0.545$ indicated a moderate standardized effect. KÁIXAR achieved lower mean latency in 199 of the 200 paired queries.

An important distinction between the original and physical experiments is that the latter incorporated actual distributed result reconstruction and duplicate elimination within the measured execution path. No analytical coverage penalties or estimated reconstruction times were used. Consequently, the latency values reported for the physical validation correspond to measured distributed execution rather than analytically adjusted estimates.

The magnitude of the performance advantage differed between the two high-workload evaluations. In the original virtualized experiment, KÁIXAR reduced mean query execution time by approximately 29.32% relative to XAMANA, whereas the additional physical deployment yielded an 86.15% reduction and a 7.22× speedup. These values should not be interpreted as directly interchangeable effect estimates, because the experiments were conducted under different deployment conditions and execution protocols. Rather, the relevant observation is that the direction of the high-workload performance advantage was reproduced under the independent physical deployment and, in that scenario, was additionally supported by paired statistical inference.

5. Discussion

The experimental results indicate that KÁIXAR can generate horizontal fragmentation schemes that reflect the dominant access patterns observed in the workload. The combined use of the MCRUD matrix and the ALP model enabled the identification of fragmentation attributes with high workload relevance, while the incorporation of hardware-related criteria extended the method beyond fragment generation by also considering the allocation of the resulting fragments.

However, the comparative results also demonstrate that the performance advantage of KÁIXAR is scenario-dependent. In the original experiments, the high-workload scenario favored KÁIXAR over XAMANA, whereas XAMANA achieved lower execution times in 28 of the 30 evaluated queries in the medium-workload scenario. These findings establish that neither approach exhibits universal superiority; instead, workload-aware fragmentation can deliver substantial performance benefits under specific workload distributions and deployment conditions.

This interpretation is reinforced by the additional physical-site validation. When both KÁIXAR and XAMANA were evaluated using the same 200 paired high-workload queries on physically heterogeneous sites, KÁIXAR achieved a mean query latency of 15.062 ms compared with 108.735 ms for XAMANA, corresponding to an 86.15% reduction and a 7.22× speedup. KÁIXAR exhibited lower mean latency in 199 of the 200 paired queries.

Because the paired latency differences did not satisfy the normality assumption according to the Shapiro–Wilk test ($p<0.001$), the Wilcoxon signed-rank test was used as the primary inferential test. The latency difference was statistically significant ($p<0.001$), with a mean paired difference of 93.674 ms and a 95% confidence interval of [69.709, 117.638] ms. The rank-biserial correlation ($r_{rb}=0.985$) further indicated a strong directional effect in favor of KÁIXAR. These results provide statistical support for the performance advantage observed in this particular physical high-workload scenario.

Importantly, the magnitude of the improvement observed in the physical experiment should not be directly equated with that obtained in the original virtualized experiments. The two evaluations were conducted under different deployment conditions and therefore represent complementary rather than directly interchangeable measurements. Nevertheless, the direction of the performance advantage observed in the original high-workload experiment was reproduced under the additional physical deployment.

Although KÁIXAR was designed and evaluated in the context of medical databases, its core workload-driven fragmentation workflow is not inherently restricted to this application domain. The workload-analysis, attribute-selection, predicate-generation, fragmentation, and allocation stages operate on generic elements such as attributes, query predicates, access frequencies, and destination-site characteristics. Therefore, the method could be adapted to other data-intensive domains in which representative workload logs and fragmentable attributes are available. In such cases, domain-specific components—such as DICOM metadata and CBIR descriptors in the present implementation—would need to be replaced by the corresponding metadata, descriptors, or application- specific attributes of the target domain. Such an extension would require adaptation of the data representation and persistence components while preserving the core workload-driven fragmentation and allocation logic.

The experimental evidence also highlights several limitations. The evaluation was conducted using a specific DICOM dataset and a limited number of distributed sites; therefore, the results should not be generalized to large-scale clinical infrastructures without further validation. Future work should evaluate larger datasets, additional physical sites, dynamic workloads, different network conditions, and additional medical imaging repositories. Such experiments would allow the scalability and robustness of the proposed method to be assessed under deployment conditions closer to production medical environments.

Discussion of the Top-20% Workload-Retention Strategy

To evaluate the sensitivity of the workload-reduction strategy, retention rates of 10%, 20%, 30%, and 50% were compared against the complete workload. Each configuration was executed ten times after three warm-up executions. All evaluated retention rates selected dicom.modality as the dominant fragmentation attribute and generated the same five-fragment logical scheme obtained from the complete workload, corresponding to CT, MR, XC, OPT, and OP. Therefore, varying the retained workload proportion did not alter the resulting fragmentation decision in the evaluated workload. The nominal 20% configuration reduced the MCRUD and ALP analysis time from $14.579\pm 0.824$ ms for the complete workload to $4.579\pm 0.567$ ms, corresponding to a 68.59% reduction, while preserving the fragmentation attribute and scheme. Similar reductions of 80.73%, 60.57%, and 43.64% were observed for retention rates of 10%, 30%, and 50%, respectively. These results indicate that the workload-reduction parameter primarily affects the amount of information processed during workload analysis rather than the resulting fragmentation structure for the evaluated workload. To evaluate the sensitivity of the workload-reduction strategy, retention rates of 10%, 20%, 30%, and 50% were compared against the complete workload. Each configuration was executed ten times after three warm-up executions. The results are presented in Table 26. All evaluated retention rates selected dicom.modality as the dominant fragmentation attribute and generated the same five-fragment logical scheme obtained from the complete workload, corresponding to CT, MR, XC, OPT, and OP. Therefore, varying the retained workload proportion did not alter the resulting fragmentation decision in the evaluated workload. The nominal 20% configuration reduced the MCRUD and ALP analysis time from $14.579\pm 0.824$ ms for the complete workload to $4.579\pm 0.567$ ms, corresponding to a 68.59% reduction, while preserving the fragmentation attribute and scheme. Similar reductions of 80.73%, 60.57%, and 43.64% were observed for retention rates of 10%, 30%, and 50%, respectively. These results indicate that the workload-reduction parameter primarily affects the amount of information processed during workload analysis rather than the resulting fragmentation structure for the evaluated workload.

Table 26. Sensitivity analysis of workload-retention rates and their effect on fragmentation decisions and processing time.

Retention	Selected	MCRUD+ALP	Reduction	Mean Total Preprocessing Time	SD	Attribute	Fragments	Same Scheme
(%)	Operations	(ms)	vs. 100%	(ms)	(ms)			as 100%
10	100	$2.809\pm 0.349$	80.73%	44.211	2.662	dicom.modality	5	Yes
20	200	$\mathbf{4}.\mathbf{579}\pm \mathbf{0}.\mathbf{567}$	68.59%	47.018	7.653	dicom.modality	5	Yes
30	300	$5.748\pm 0.834$	60.57%	42.421	4.522	dicom.modality	5	Yes
50	500	$8.216\pm 1.001$	43.64%	41.925	4.365	dicom.modality	5	Yes
100	Full	$14.579\pm 0.824$	0.00%	38.756	3.405	dicom.modality	5	Baseline

Note: SD denotes standard deviation. Bold values highlight the 20% workload-retention configuration adopted by KÁIXAR for workload optimization.

It is important to distinguish the time required for workload analysis from the total preprocessing time. Although reducing the retained workload decreases the computational cost of the MCRUD and ALP stages, the reduced-workload configurations introduce an additional preprocessing step for ranking, filtering, and selecting the retained operations. The 100% baseline does not incur this workload-reduction overhead because the complete log is processed directly. Consequently, the baseline exhibited a lower total preprocessing time (38.756 ms) than the 20% configuration (47.018 ms), despite requiring substantially more time for the MCRUD+ALP analysis itself (14.579 ms versus 4.579 ms). Therefore, the observed 68.59% reduction refers specifically to workload-analysis time and should not be interpreted as an equivalent reduction in end-to-end preprocessing time.

The sensitivity analysis also shows that the 20% retention rate should not be interpreted as an empirically optimal value. In the evaluated workload, retention rates of 10%, 20%, 30%, and 50% selected the same dominant fragmentation attribute and generated the same five-fragment logical scheme as the complete workload. In particular, the 10% configuration achieved the lowest MCRUD+ALP analysis time while preserving the same fragmentation decision. Nevertheless, the 20% value was retained as the nominal configuration of KÁIXAR because it corresponds to the original Pareto-based design criterion and preserves a larger fraction of workload information than the 10% alternative. Thus, the present experiment validates the robustness of the fragmentation decision across the evaluated retention rates, rather than establishing 20% as a universally optimal threshold.

6. Conclusions

This work presented KÁIXAR, a workload-driven horizontal fragmentation method and web-based framework for medical databases containing DICOM metadata, medical images, and CBIR-related descriptors. Unlike approaches based exclusively on workload information, KÁIXAR integrates workload analysis, attribute selection through the ALP model, hardware-aware server evaluation, and cost-based fragment allocation within a unified fragmentation workflow.

The experimental results demonstrated that KÁIXAR effectively identifies workload-relevant attributes and constructs horizontal fragmentation schemes, providing empirical evidence of the interplay between workload characteristics, query coverage, and fragmentation effectiveness while highlighting the importance of workload-aware optimization in distributed medical database environments. However, the comparative evaluation also demonstrated that performance is scenario-dependent. The original high-workload experiment favored KÁIXAR over XAMANA, whereas the medium-workload scenario included multiple queries for which XAMANA achieved lower execution times. Therefore, the results do not support a claim of universal superiority, but rather indicate that the benefits of workload-aware fragmentation depend on workload characteristics and deployment conditions.

This interpretation was strengthened by the additional physical-site validation. Under the evaluated high-workload scenario, KÁIXAR achieved a mean query latency of 15.062 ms compared with 108.735 ms for XAMANA, corresponding to an 86.15% reduction and a 7.22× speedup. KÁIXAR exhibited lower mean latency in 199 of the 200 paired queries. The paired latency difference was statistically significant according to the Wilcoxon signed-rank test ($p<0.001$). These measurements included actual distributed result reconstruction and therefore provide complementary evidence beyond the original virtualized evaluation.

The sensitivity analysis of the workload-retention strategy further showed that retention rates of 10%, 20%, 30%, and 50% produced the same dominant fragmentation attribute and the same five-fragment logical scheme as the complete workload. In particular, the nominal 20% configuration reduced MCRUD+ALP analysis time by 68.59% relative to processing the complete workload while preserving the fragmentation decision. This result supports the robustness of the fragmentation decision for the evaluated workload, although the 20% retention rate should not be interpreted as a universally optimal threshold.

Beyond the experimental results, KÁIXAR integrates workload analysis, MCRUD construction, ALP calculation, hardware-aware allocation, fragment materialization, distributed deployment, and DICOM visualization within a single environment. Although the current implementation uses MongoDB, the core fragmentation logic operates on workload predicates, attributes, access frequencies, and destination-site characteristics and can therefore be adapted to other database paradigms by modifying the corresponding persistence and execution layers. Under the evaluated conditions, KÁIXAR thus represents a competitive approach for workload-aware horizontal fragmentation of medical databases.

Overall, the results indicate that KÁIXAR should be understood as a scenario-dependent fragmentation framework rather than as a universally superior alternative. Its main contribution lies in reducing and analyzing representative workload information, generating and allocating horizontal fragments under heterogeneous deployment conditions, and preserving the data structures required for subsequent medical-image retrieval. In the CBIR context, KÁIXAR contributes at the data-organization layer by leaving the fragmented database prepared to support content-based retrieval operations without modifying or claiming improvements to the underlying retrieval algorithm itself.

Future work will focus on evaluating larger datasets and additional physical sites, dynamic workloads, controlled hardware variations, and other database paradigms, including relational and distributed NoSQL systems. As a prospective continuation of this research line, the designation VAYRON Medical System is introduced for a future research platform envisioned to extend the concepts developed in KÁIXAR toward adaptive fragmentation, distributed execution, and medical-image retrieval in heterogeneous environments. The development, implementation, and evaluation of such extensions remain subjects for future research. These studies will allow the scalability, robustness, and applicability of the proposed approach to be evaluated under increasingly diverse deployment conditions.