Circular Incremental Update Mechanism

• Circular Incremental Update Mechanism is an algorithm that maintains cyclic association rules by updating supports over specified periodicity windows in transactional databases.
• IUPCAR classifies itemsets into frequent, pseudo-cyclic, and non-frequent groups, and uses a weighted updating scheme to integrate incremental data without full database rescans.
• Empirical evaluations show significant runtime improvements over full re-mining methods, though the approach is limited to additive updates and requires careful parameter tuning.

A circular incremental update mechanism is an algorithmic paradigm for efficiently maintaining cyclic association rules within a temporal, transactional database subject to incremental insertions. It leverages periodic patterns (cycles) inherent in the data, such that rule mining and updates are performed relative to specific periodicity windows rather than the entire dataset, and does so without redundant full scans on updates. The IUPCAR algorithm (Incremental UPdate of Cyclic Association Rules), introduced by Ben Ahmed and Gouidder, embodies this principle and achieves significant efficiency advantages over full re-mining schemes in practical settings (Ahmed et al., 2010).

1. Formalization of Cyclic Association Rules

A temporal transactional database is denoted as $DB = \{t_1, t_2, \dots, t_N\}$, where transaction $t_i \subseteq \mathcal{I}$, $\mathcal{I}$ being the item universe. A user-specified cycle is parameterized by a length $l \in \mathbb{N}^+$ and offset $o \in \{0, 1, \dots, l-1\}$, with each cycle $c = (l, o)$ inducing a periodicity window:

$P_c = \{ t_{o+1}, t_{o+1+l}, t_{o+1+2l}, \dots \}$

The cyclic support of an itemset $X \subseteq \mathcal{I}$ for a cycle $c$ is:

$\mathit{supp}_c(X) = \frac{\#_c(X)}{|P_c|}$

where $\#_c(X) = |\{k \ge 0 : X \subseteq t_{o+1+kl}\}|$.

A cyclic association rule is an implication $X \Longrightarrow Y$, $X \cap Y = \emptyset$, such that for a selected cycle $c$:

• $\mathit{supp}_c(X \cup Y) \ge \mathit{MinSup}$
• $$\mathit{conf}_c(X \rightarrow Y) = \frac{\mathit{supp}_c(X \cup Y)}{\mathit{supp}_c(X)} \ge \mathit{MinConf}$$

2. Structure and Workflow of the IUPCAR Algorithm

IUPCAR operates in phased workflow over an initial database $DB$ and an incremental batch $db$. For given thresholds $(\mathit{MinSup}, \mathit{MinConf})$ and cycle $(l, o)$, it maintains the set of frequent cyclic itemsets and rules over $DB' = DB \cup db$:

• Phase 1: Initial Scan and Classification
  • $FC$: Frequent Cyclic ($\mathit{supp}_c(X) \ge \mathit{MinSup}$)
  • $FPC$: Frequent Pseudo-Cyclic ($$\mathit{MinFPC} \le \mathit{supp}_c(X) < \mathit{MinSup}$$)
  • $NFC$: Non-Frequent Cyclic ($\mathit{supp}_c(X) < \mathit{MinFPC}$)
  • $\mathit{MinFPC}$ is established to eliminate certain unfruitful candidates.
• Phase 2: Incremental Scan The new batch $db$ is scanned, and for every itemset its frequency and class in $db$ (w.r.t. the same thresholds and cyclic definition) are computed.
• Phase 3: Weight-Based Update For each itemset $X$ in either $DB$ or $db$, cyclic supports in each batch, $a$ and $b$ respectively, are calculated:

$$a = \frac{\#_c^{DB}(X)}{\lfloor (|DB| - o)/l \rfloor }, \quad b = \frac{\#_c^{db}(X)}{\lfloor (|db| - o)/l \rfloor }$$

If the class is unchanged after incorporating $db$, the new support is the weighted average:

$$\mathcal{W}(X) = \frac{a \cdot |DB| + b \cdot |db|}{|DB| + |db|}$$

Otherwise, the change is quantified by the difference ($a-b$ or $b-a$), and the dominant class is assigned.

• Phase 4: Rule Generation All itemsets with updated class $FC$ generate cyclic rules via confidence-based methods on the new database $DB'$.

Key data structures include hash tables for counters $\#_c^{DB}(X)$ and $\#_c^{db}(X)$, and labeled lists (or hash maps) for the three class partitions. A cyclic-pattern tree is mentioned as an optional optimization.

3. Mathematical Properties of Incremental Updates

IUPCAR’s update model is driven by precise support aggregation mechanics. The weighting scheme behaves as a convex interpolation between old and new support estimates if the itemset’s class remains stable, and as an absolute support difference otherwise. Only itemsets where $|a-b|$ exceeds a specified threshold or with a class label change (among all nine possible transitions) are eligible for subsequent rule generation or pruning. This property sharply localizes the computational response to incremental insertions and harnesses the periodic structure for early pruning (Ahmed et al., 2010).

4. Computational Complexity

The initial level-wise mining of $DB$ is $O(\sum_{k=1}^m \binom{n}{k} |DB|)$ (Apriori’s asymptotics), but incremental phases avoid this cost:

• Scanning $db$ for update: $O(\sum_k \#\text{candidates}_k \cdot |db|)$
• Status and weight update across $\mathcal{C}$ candidates: $O(|\mathcal{C}|)$
• Rule generation: $O(|FC|^2)$ in the worst case

Total worst-case complexity:

$$O(\text{Cost}_{\text{Apriori}(DB)} + \text{Cost}_{\text{Apriori}(db)} + |\mathcal{C}|^2)$$

In the typical regime ($|db| \ll |DB|$), the incremental phase dominates the run time:

$$O(\text{scan}(db) + |\mathcal{C}| ) \approx O(|db| \times \text{avg-cand-size} + |\mathcal{C}| )$$

Compared to full re-mining (e.g. PCAR), which always triggers a full pass over $DB \cup db$, and to FUP/BORDERS methods that do not exploit cyclicity, IUPCAR localizes work to the small increment and exploits early pruning by class (Ahmed et al., 2010).

5. Empirical Evaluation

Experiments employ UCI repository datasets, with key parameters summarized as follows:

Database	#Trans.	#Items	Avg. trans. size	Size (KB)
T10I4D100K	100,000	1,000	10	3,830
T40I10D100K	100,000	775	40	15,038
Retail	88,162	16,470	10	4,070

Performance is benchmarked by runtime, memory usage, and number of resulting rules. For $DB:db = 90:10$ and $\mathit{MinSup} = 1\%$, strong runtime reductions are observed:

Dataset	PCAR (sec)	IUPCAR (sec)	Speed-up (%)
T10I4D100K	511.4	288.6	43.6
T40I10D100K	1,776.1	686.9	61.3
Retail	1,894.4	791.9	58.2

As $\mathit{MinSup}$ increases, both methods accelerate, but IUPCAR consistently holds a roughly $2\times$ efficiency advantage. As $|db|$ decreases from $30\%$ down to $10\%$ of $DB$, incremental costs decrease nearly linearly. Memory consumption is dominated by candidate storage and is similar between the methods (Ahmed et al., 2010).

6. Limitations and Prospective Extensions

The circular incremental update approach is constrained in several notable respects:

• All candidates must be stored through both phases, imposing memory overhead for dense datasets or low $\mathit{MinSup}$.
• Only additive (insert-only) updates are supported; deletions or sliding window scenarios require re-mining or algorithmic augmentation.
• The efficacy of early pruning depends on the setting of $\mathit{MinFPC}$, which can affect completeness and computational savings.

Proposed extensions include adoption of vertical data representations (Eclat-style) for faster cycle support calculation, incremental support for decremental/removal updates via inverse weights, adaptation to multiple simultaneous cycle lengths, and dynamic adjustment of $\mathit{MinSup}$ or $\mathit{MinFPC}$ during increments to reflect evolving data distributions or concept drift (Ahmed et al., 2010).

---

The IUPCAR framework defines the current state-of-the-art for efficiently maintaining cyclic association rules in append-only temporal databases by exploiting cycle-aligned counting and incremental aggregation, while minimizing unnecessary rescans of the historical database.