Finding the Transitive Closure of Functional Dependencies using Strategic Port Graph Rewriting

TL;DR

This paper introduces a novel method using strategic port graph rewriting to compute the transitive closure of functional dependencies in relational database schemas, ensuring correctness and termination under certain conditions.

Contribution

It presents a new graph-based approach for logical database design, modeling schemas as attributed port graphs and providing rewriting rules for dependency computations.

Findings

The method is sound, complete, and terminating without cyclical dependencies.

It effectively models relational schemata as port graphs.

Provides a strategic graph program for transitive closure computation.

Abstract

We present a new approach to the logical design of relational databases, based on strategic port graph rewriting. We show how to model relational schemata as attributed port graphs and provide port graph rewriting rules to perform computations on functional dependencies. Using these rules we present a strategic graph program to find the transitive closure of a set of functional dependencies. This program is sound, complete and terminating, assuming that there are no cyclical dependencies in the schema.

Figures

Full text

1 Introduction

Traditionally, steps of relational database design include Conceptual, Logical and Physical modelling. The theory behind these steps is well-understood and is part of the syllabus of many databases courses. Yet, database professionals often consider Logical Design (normalisation) too cumbersome and do not apply normalisation theory, despite the clear advantages of normalised database designs. Badia and Lemire [5] also highlight that conceptual and logical models do not always carry enough information about database semantics thereby leading the architect to a sub-optimal design.

We use attributed port graphs to represent a relational schema and its semantics. Port graphs are graphs where edges are connected to nodes at specific points, called ports. In port graphs, nodes, edges and ports can have attributes, which are used to represent properties of the system modelled. In this paper we focus on using port graphs in the logical phase of database design. We show that port graphs are a good choice of data structure to store relational metadata and can be transformed without the loss of metadata.

To specify the transformations applied to relational schemata, we use port graph rewriting systems, a general class of graph rewriting systems [11]. The implementation framework we use is Porgy [13] – a visual, interactive tool for the specification, simulation and analysis of systems based on port graph rewriting. Porgy provides a graphical interface, where users can define a system and specify its dynamics by means of port graph rewrite rules and strategies. Port graphs have node, port and edge attributes, whose values are taken into account in port graph morphisms (used to define rewriting steps) and in strategy expressions (to control the application of rules). Strategic graph programs [13], consisting of an initial port graph and a set of rewrite rules controlled by a strategy, are the essence of Porgy. The strategy language offers separate primitives to select subgraphs of the model as focusing positions for rewriting and to select the rewrite rules to be applied, following the separation of concerns principle which makes programs easier to maintain and adapt. The strategy language also allows users to define strategies using not only operators to combine graph rewriting rules but also operators to deal with graph traversal and management of rewriting positions in a graph. Porgy provides a visual representation of the set of rewrite derivations (a derivation tree) and includes features such as cycle detection, to facilitate debugging.

We extend the rule language by adding the possibility to specify application conditions for a rule. That is, as part of a rewrite step, in the rule editor, users can define a set of conditions which are evaluated after a morphism has been found. The rewrite step is applied only if the rule condition evaluates to true. As a use-case we provide a set of port graph rewriting rules and a strategy to calculate the transitive closure of a set of functional dependencies. Although there are a number of tools already available to do the same, a distinctive advantage of our implementation is that it is visual and backtrackable (thanks to the derivation tree feature of Porgy). Our strategy is sound, complete and terminating, given the restriction that there are no cyclical dependencies in the schema.

Summarising, our contributions are:

a new visual language, based on port graphs, for logical design of relational schemata, 2. 2.

generic application conditions for rules (a port graph rewriting language extension), 3. 3.

a strategic graph program to find the transitive closure of a set of functional dependencies.

This last contribution is a key step towards building strategic graph programs to find minimal covers, candidate keys and Third Normal Form (3NF) relation schemata.

Related Work. Graph theory and graph rewriting is by no means a new addition to the set of tools that have been used for relational database design. In [12] hypergraphs are used and their well-formed property (called a canonical hypergraph) determines the quality of design they represent. The authors of [17] used directed graphs to find all candidate keys of a relation in polynomial time. A special family of labelled graphs, FD-graphs, were introduced in [3] to obtain meaningful closures of a set of functional dependencies. In terms of graph transformations and rewriting we highlight two works. Hypergraph rewriting was used in [6] for the manipulation of functional dependencies and Triple Graph Grammars were used in [14] to optimize an already existing schema. Section 3 translates the work presented in [3] to port graphs and extends it.

Organization. This paper is organised as follows. We briefly review relational database theory and port graph rewriting background in Section 2. We present our port graph visual language for logical design of relation schemata in Section 3. In Section 4 we define the syntax of the language for generic rule application conditions. Section 5 illustrates how the visual language and the generic rule application conditions can be used to find the transitive closure of a set of FDs. We then conclude in Section 6 by highlighting how these results can be used in future work.

2 Background

In this section we will review the definitions and background in relational databases and port graph rewriting that we are going to use throughout this paper. Due to space constraints, for formal definitions and proofs, this section will refer the reader to the relevant works rather than recalling them. We will also briefly review related work that used graphs to represent or transform relational schemata.

2.1 Relational Database Design

We assume that the reader is familiar with the theory of logical design of relational databases [9, 10]. In particular, the definitions of: relation schema, attribute, candidate key and functional dependency (FD) [9, 10]. We refer to a single attribute with letters from the beginning of the alphabet $A,B,\ldots$ and to attribute sets with letters from the end of the alphabet $X,Y,Z$. This paper will denote the set of all FDs of a relation schema $\Sigma_{\_}R$ or just $\Sigma$, where appropriate. We also assume familiarity with the inference rules of functional dependencies, also known as Armstrong’s Axioms [7]: Transitivity, Trivial Dependency, Augmentation, Union, Decomposition, Pseudotransitivity. We call the set of all FDs that can be inferred from $\Sigma$, using Armstrong’s Axioms, the syntactic closure $\Sigma^{+}$. It was shown that Armstrong’s Axioms are sound and complete, which means that they find only and all (respectively) semantically correct dependencies. This work assumes that a) FDs are in canonical form ie. only single attributes appear on the right-hand sides of the FDs and b) there are no cyclical dependencies.

2.2 Port Graph Rewriting

An attributed port graph is a labelled attributed graph where nodes have specific points-of-connection called ports, and edges that are attached to ports. In this subsection we recall the most important port graph rewriting constructs from Sections 2 and 3 of [13], where the full formal definitions can also be found.

A port graph rewrite rule is a port graph $L\Rightarrow_{\_}CR$ consisting of two subgraphs $L$ and $R$ together with an arrow node that links them. Each rule is characterised by its arrow node, which has a unique name (the rule’s label), a condition Where restricting the rule’s matching, and ports to control the rewiring operations when rewriting steps are computed. Edges that run between ports of $L$, $R$ and the arrow node are coloured red by Porgy to distinguish them from normal edges. We recall the definition of the matching morphism that states that a match $g(L)$ of the left-hand side is found in $G$ if there is a total port graph morphism $g$ from $L$ to $G$ such that if the arrow node has an attribute Where with value $C$, then $g(C)$ is true in $G$. $C$ is of the form $\textit{saturated}(p_{\_}1)\wedge...\wedge\textit{saturated}(p_{\_}n)\wedge B$. The predicate $\textit{saturated}(g(p_{\_}i))$ is true if there are no edges between $g(p_{\_}i)$ and ports outside $g(L)$ in $G$ – this ensures that no edges will be left dangling in rewriting steps. $B$ is a Boolean expression such that all its variables occur in $L$. To aid visual design of rewrite rules, Porgy allows us to name nodes in $L$ and $R$ but these are treated by the system as node name variables. This means that node name variables identify the nodes on both sides of the rule but are instantiated when $g(L)$ is found using actual values from the matching nodes.

Our contribution to the rewrite rule language is to provide the functionality of generic application conditions. This task was two-fold: we created a grammar for $B$ and implemented a Porgy Rule Editor plug-in (called Rule Conditions).

We also recall here that a strategic graph program consists of a located graph (a port graph with two distinguished subgraphs that specify the locations where rewriting should take place or not), a set of located rewrite rules, and a strategy expression. In a located graph $G_{\_}{P}^{Q}$, $P$ represents the position subgraph of $G$ where rewriting steps may take place and $Q$ represents the banned subgraph of $G$ where rewriting steps are forbidden. A located rewrite rule $L\Rightarrow_{\_}CR_{\_}{M}^{N}$ can update $P$ and $Q$ in a rewrite step such that $P^{\prime}=(P\setminus g(L))\cup g(M)$ and $Q^{\prime}=(Q\setminus g(L))\cup g(N)$.

Our work to find the transitive closure is implemented in the form of a strategic graph program.

2.3 Abstract Reduction Systems

We use the theoretical framework of Abstract Reduction Systems (ARS) [4, Chapter 2] to prove termination. Various techniques to construct termination proofs have been published and we shall recall one here. This technique requires the embedding of the ARS $(A,\longrightarrow)$ into another ARS $(B,>)$ of which we know that it terminates. Our choice, $(\mathbb{N},>)$ terminates because every descending chain $a_{\_}0>a_{\_}1>\ldots$ is finite.

Definition 1** (Monotone mapping).**

The mapping $\varphi:A\longrightarrow B$ is monotone if $x\longrightarrow x^{\prime}\Rightarrow\varphi(x)>\varphi(x^{\prime})$. $\varphi$ is also known as the measure function.

It does not automatically follow from the above that to prove termination of an abstract reduction system it suffices to find a measure function $\varphi$ to embed the system into, for example, $(\mathbb{N},>)$. But if we can prove that the ARS is finitely branching then we can make use of the following lemma:

Lemma 2**.**

A finitely branching reduction terminates iff there is a monotone embedding into $(\mathbb{N},>)$.

3 A Visual Language for Relational Schema Design

We now show how relational schemata (using functional dependencies only) can be modelled as attributed port graphs. We use the ${}^{\prime}.^{\prime}$ (dot, member-of) operator to refer to a particular port of a node.

We define relation schema attributes and FDs as nodes. The fact that an attribute belongs to the right- or left-hand side of a FD is represented by edges. However, when adding FDs to the visual language, we face a challenge. Because of the semantics of a FD (i.e. LHS determines RHS), strategic graph programs executed on this visual language have to be able to distinguish between LHS and RHS attributes of FDs. A non-trivial FD must have at least one attribute on both sides where (RHS $\not\subseteq$ LHS). Also, as per the separation of concerns principle, a FD has to be aware of the list of attributes on its sides, not the other way around. Formally, we say that:

Definition 3** (Functional Dependency Port Graph, FDPG).**

Let $R$ be a relation schema and $\Sigma$ its set of functional dependencies. A Funtional Dependency Port Graph representing $\Sigma$ is an attributed port graph [13] $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$ and is defined as:

• •

$V=V_{\_}A\cup V_{\_}{FD}$* is a union of two disjoint sets of nodes:*

• –

$V_{\_}A$: set of Attribute nodes, one node for every attribute in $R$;

• –

$V_{\_}{FD}$: set of Functional Dependency nodes, one node for every functional dependency in $\Sigma$;

• •

$P=P_{\_}A\cup P_{\_}{FD}$* is a union of two defined sets of ports:*

• –

$P_{\_}A=\{pFD\}$* and*

• –

$P_{\_}{FD}=\{pFDLHS,pFDRHS\}$;

• •

$E$* is a finite set of edges between ports; two ports may be connected by only one edge;*

• •

$D$* a set of records [13];*

and a set ${{\cal F}}$ of functions $Connect$, $Attach$ and ${\cal L}$ such that:

• •

Connect: for each edge $e\in E$, $Connect(e)$ is the pair $(p_{\_}1,p_{\_}2)$ of ports connected by $e$ where the only allowed pairs are (pFD, pFDLHS) and (pFDRHS, pFD). For every dependency $\varphi\in\Sigma:X\to A$ the pFD port of every attribute node corresponding to $X$ will be connected to the pFDLHS port of the dependency node corresponding to $\varphi$ and the pFDRHS port of the FD node $\varphi$ will be connected to the pFD port of the attribute node representing $A$.

• •

Attach:

• –

for each port $p\in P_{\_}A$, $Attach(p)$ is the node $n\in V_{\_}A$ to which the port belongs;

• –

for each port $p\in P_{\_}{FD}$, $Attach(p)$ is the node $n\in V_{\_}{FD}$ to which the port belongs;

• •

${\cal L}$* a labelling function [13].*

The following properties directly follow from Definition 3.

Property 4** (Cardinality of set $V$).**

In a FDPG $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$, $|V|=|V_{\_}A|+|V_{\_}{FD}|=|R|+|\Sigma|$.

Proof.

The mappings $R\to V_{\_}A$ and $\Sigma\to V_{\_}{FD}$ are bijections. ∎

Property 5** (Cardinality of set $E$).**

Given the set of functional dependencies $\Sigma=\{\varphi_{\_}1,\ldots,\varphi_{\_}k\}$ and a FDPG $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$, $|E|=|\Sigma|+\sum_{\_}{i=1}^{k}|LHS(\varphi_{\_}i)|$.

Proof.

Number of edges = one right-hand side edge per dependency + sum of the sizes of the left-hand side of each functional dependency. ∎

We implement FDPGs in PORGY. Firstly, using the set $D$ of records, we introduce an attribute called RelDbType which denotes the role of the node in the relational context. Every new node and port created in a FDPG-based logical model have to have a constant RelDbType value, placing it in the appropriate set of $V_{\_}A,V_{\_}{FD},P_{\_}A$ or $P_{\_}{FD}$. Attribute nodes have RelDbType = ATTR, FD nodes have RelDbType = FD. The port of an attribute that handles the connection to either side of a FD has RelDbType = pFD. The LHS and RHS connection ports of a FD node have RelDbType = FDLHS and FDRHS, respectively. Both FDLHS and FDRHS ports have an integer attribute FunctionalArity defined that allows the system to store the number of attributes on each side. This is required because the matching algorithm does not enforce exact arity since a particular port can be connected to other ports outside the match found, however, when matching on FDs and their LHSs, every single LHS attribute has to be in the matching subgraph.

Both FD and ATTR nodes have an integer UID attribute that allows the rules to assign a numeric identity value to them. This is useful when a rule adds a new FD and we want control over the value of the unique identifier. We make use of the built-in viewLabel attribute to assign meaningful node name constants (in models) and variables (in rules) to nodes. Figure 1 shows a functional dependency $A\to C$ as a port graph, with the relevant attribute values.

Based on the FD-path definition of Ausiello et al. [3] we define an FDPG-path as follows:

Definition 6** (FDPG-Path).**

Given an FDPG $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$, an attribute node set $X\subseteq V_{\_}A$ and an attribute node $j\in V_{\_}A$, a (directed) FDPG-Path $\langle X,j\rangle$ from $X$ to $j$ is a minimal subgraph $G_{\_}\Sigma^{\prime}=(V^{\prime},P^{\prime},E^{\prime},D^{\prime})_{\_}{{\cal F}^{\prime}}$ of $G_{\_}\Sigma$ such that $X\cup\{j\}\subseteq V_{\_}A^{\prime}$ and one of the following conditions holds:

there exists $v\in V_{\_}{FD}^{\prime}$ such that for all $x_{\_}i\in X,(x_{\_}i.pFD,v.pFDLHS)\in E^{\prime}$ and $(v.pFDRHS,j.pFD)\in E^{\prime}$, i.e. there exists $v\in V_{\_}{FD}^{\prime}$ such that $X$ is the set of all left-hand side attributes and $j$ is the right-hand side attribute of the functional dependency represented by $v$; 2. 2.

there exist $v\in V_{\_}{FD}^{\prime}$ and $k\in V_{\_}A^{\prime}$ such that $(k.pFD,v.pFDLHS)\in E^{\prime}$ and $(v.pFDRHS,j.pFD)\in E^{\prime}$ and there is an FDPG-Path $\langle X,k\rangle$ included in $G_{\_}\Sigma^{\prime}$; 3. 3.

*there exist $v\in V_{\_}{FD}^{\prime}$ and $K\subseteq V_{\_}A^{\prime}$ such that for all $k_{\_}i\in K,(k_{\_}i.pFD,v.pFDLHS)\in E^{\prime}$ *

and $(v.pFDRHS,j.pFD)\in E^{\prime}$ and $n$ FDPG-Paths $\langle X,k_{\_}1\rangle,\ldots\langle X,K_{\_}n\rangle$ are included in $G_{\_}\Sigma^{\prime}$.

Property 7** (Transitivity).**

Condition 2 of Definition 6 represents Armstrong’s Transitivity axiom.

Proof.

An FDPG-Path $\langle X,k\rangle$ represents FD $X\to k$.

Edges $(k.pFD,v.pFDLHS)\in E$ and $(v.pFDRHS,j.pFD)\in E$ represent FD $k\to j$. The fact that there is an FDPG-Path $\langle X,j\rangle$ means the FD $X\to j$ exists. ∎

Property 8** (Union).**

Condition 3 of Definition 6 represents Armstrong’s Union axiom.

Proof.

The $n$ FDPG-Paths $\langle X,k_{\_}1\rangle,\ldots,\langle X,k_{\_}n\rangle$ represent FDs $X\to k_{\_}1,\ldots,X\to k_{\_}n$.

Edges $k_{\_}i\in K,(k_{\_}i.pFD,v.pFDLHS)\in E$ and $(v.pFDRHS,j.pFD)\in E$ represent FDs $k_{\_}1\to j,\ldots,k_{\_}n\to j$. The fact that $n$ FDPG-Paths $\langle X,j\rangle$ exist means that $X\to k_{\_}1,\ldots,X\to k_{\_}n$ can be unified into $X\to K$. ∎

We now turn our attention to extending the port graph rewriting language so that strategic graph programs can be created to find the transitive closure of a Functional Dependency Port Graph.

4 Generic Rule Application Conditions

We recall the structure of the arrow node Where attribute defined in Section 2.2. In this section we extend the rewrite rule language to provide the functionality of generic application conditions. Firstly, we define the context-free grammar for $B$, secondly, we present the Porgy Rule Editor plug-in (called Rule Conditions).

The EBNF grammar for $B$ is defined in Figure 2. The structure of the grammar was inspired by C++ and follows the operator precedence of C++, too. \grammarindent1.5in

We point out that when referring to a node or edge the user has to use its internally assigned id. Also, due to the implementation of Porgy, there is no port construct in the grammar – they have to be referred to as node. This is because the underlying graph engine (Tulip) processes ports as nodes. Terminal number can be any integer or floating-point number and quotedstring is an arbitrary-length string made up of letters, digits and symbols in double quotes. Similarly, quotedattributename is a valid name of an attribute of node, edge or port.

We highlight the NotNode() operator: it iterates all nodes of $G$ and checks if there exists a node with an attribute quotedattributename and if the comparison on them evaluates to true. Intuitively, if at least one such node is found in $G$, NotNode() returns false. It is very important to note here that this check is performed on the entire graph $G$, not just in $g(L)$. This is fundamentally different from the rest of the rule application condition grammar, which only applies to $g(L)$. This is a consequence of the definition of the port graph rewrite rule which states that all variables in the Boolean expression of the Where attribute have to occur in $L$, so that the matching algorithm can work with them. When a match $g(L)$ is found, all variables of $B$ are mapped so that their actual values can be found. However, when checking the absence of a node, we are not constrained by this, because we are not specifying a node in NotNode()– we are only specifying an attribute comparison that must evaluate to false on all nodes of $G$.

Porgy offers a modular plug-in system allowing developers to create Python/C++ plug-ins. We implemented an LL-parser for the above detailed context-free grammar in C++ using the Boost Spirit Parser Framework. This framework generates and executes the parser design-time and builds and evaluates an abstract syntax tree run-time. When evaluated, the Boolean result is ANDed to the rest of the arrow node Where attribute by the matching algorithm. The parser ensures that all nodes, edges, ports and attributes referred to in the conditions exist on the LHS of the rule.

We also added a UI extension to Porgy that allows users to specify and parse/check the rule conditions. A screenshot of PORGY with the Conditions editor is presented in Figure 3. Examples of rule conditions can be found in Section 5.

5 Transitive Closure Strategy

In this section we present the strategy to find the transitive closure of a set of FDs using the previously introduced visual language and rule conditions.

In PORGY, the starting point of port graph rewriting, the original model, is referred to as G0. In our case, G0 is a Functional Dependency Port Graph, as defined in Section 3. The task is to find a relational transitive closure of G0, i.e. to generate all the transitive dependencies.

Inspired by the Chase Algorithm [2, 16] we iterate every FD in G0 (and also those added by the rules), apply the rules that detect a transitive dependency pattern and create the new FD. Once we have every possible new transitive dependency that goes through the iterated FD, we mark it visited. We define two new Boolean node attributes: iter to flag the node currently being iterated and visit to permanently flag the node as visited. The two rules controlling the iteration are IterOn and IterOff (omitted). IterOn randomly selects a node with attribute values RelDbType=FD, iter=false, visit=false and sets the two flags: iter=true, visit=true. IterOff rule selects the currently iterated FD node RelDbType=FD, iter=true, visit=true and turns the iteration flag off: iter=false, visit=true.

The first two rules we created can be seen on Figures 4 and 5. These rules detect FDPG-Paths representing transitive functional dependency chains e.g. $X\to Y\to A$ which, per Armstrong’s Transitivity Axiom, means that $X\to A$ holds. Red edges in the rules go through the bridge arrow node ports. These edges mean that all edges from outside the matching subgraph into the port on the LHS end of the red edge are to be copied to connect to the port on the RHS end of the red edge. For example, the red edges running between the pFDLHS ports of nodes F2 in both rules and of node F3 in Transitivity2 rule ensure that

• •

the pFDLHS port of the newly created dependency will be connected to all attributes that were on the LHS of F2 (and F3);

• •

the pFDLHS port of the new instance of F2 (and F3) will be connected to all attributes that were on the LHS of F2 (and F3) (the original dependency is preserved).

To offer extra, context-specific backtracking functionality, we assign prime number values to the UID attribute of every FD. When a new FD is created by any transitivity rule, the UID of the new FD is the product of the UIDs of the FDs that lead to the new FD. This is calculated and assigned by the Rule Algorithm feature of Porgy. We use the Rule Condition functionality specified in Section 4 to control the applicability of the Transitivity rules. For example, the condition NotNode(UID==F1.UID*F2.UID) means that if there is a node in the entire graph being rewritten (not only the matching subgraph) with a value in UID equal to the product of the UIDs of F1 and F2 (meaning the transitive dependency has already been found) then the rule shouldn’t apply.

Finally, the strategy that uses the above defined rules is Strategy 1. The ResetVisitedFlags rule sets the flags visit=F, to allow for a whole new loop to run on all FD nodes.

Note that the node being iterated (node name variable: F1) plays a pivotal role in the matching and its LHS subgraph increases in size as the FunctionalArity of its FDLHS port increases.

The Transitive Closure Strategy is explained as follows:

For as long as there is at least one FD node the strategy hasn’t visited and iterated, do

1. (a)

Pick one such FD at random (with equal probabilites) and mark it visited and iterated, 2. (b)

Find and apply all possible applications of the rule Transitivity1 with the FD node picked in the previous step as the pivotal node F1, 3. (c)

Mark F1 visited but not iterated; 2. 2.

Mark all FD nodes not visited; 3. 3.

For as long as there is at least one FD node the strategy hasn’t visited and iterated, do

1. (a)

Pick one such FD at random (with equal probabilites) and mark it visited and iterated, 2. (b)

Find and apply all possible applications of the rule Transitivity2 with the FD node picked in the previous step as the pivotal node F1, 3. (c)

Mark F1 visited but not iterated;

Property 9** (Derivation Tree of Strategy 1).**

Every non-leaf node in the Derivation Tree of Strategy 1 has only one child node. Conversely, there is only one leaf node.

Proof.

From the semantics of strategic port graph programs [13] we know that strategy constructs we use (match(), while(), repeat(one()) and one()) will not branch the Derivation Tree at all. The loop constructs we use execute their arguments sequentially as many times as they apply. ∎

Rules IterOn, IterOff and ResetVisitedFlags are omitted due to space constraints. We discuss the semantic and rewriting characteristics of Strategy 1 in Theorems 10, 11 and 12.

Theorem 10**.**

The Transitive Closure Strategy is sound. That is, it only finds functional dependencies that can be inferred from the original set of FDs using Armstrong’s Axioms but ignoring the meaningless dependencies that would be generated by the Reflexivity axiom.

Proof.

Let $\Sigma$ be a set of functional dependencies and $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$ the FDPG representing $\Sigma$. Let $K,L\subset V_{\_}A$ be attribute node sets representing attribute sets $X,Y$ (resp.) and $n\in V_{\_}A$ an attribute node representing attribute $A$. We want to show that, after executing the Transitive Closure Strategy on $G_{\_}\Sigma$ obtaining $G_{\_}\Sigma^{\prime}$, an FDPG-Path $\langle K,n\rangle$ exists in $G_{\_}\Sigma^{\prime}$ only if the functional dependency $X\to A$ can be inferred from $\Sigma$ using Armstrong’s axioms.

It follows from Definition 6 and Properties 7 and 8 that the existence of FDPG-Path $\langle X,Y,A\rangle$ in a leaf node of the Derivation Tree means that either $\Sigma$ contained the explicit dependency $X\to A$ or that the Transitive Closure Strategy added it. Our rules and strategies (in fact, Porgy itself) follow the rewriting principle that only rules can change the structure of the graph, strategy expressions can not. We ignore rules IterOn and IterOff because they only affect values of node attributes iter and visit and not alter FDPG-Paths in the graph. This means we have to show that Transitivity1..k rules create only valid FDPG-Paths. These rules detect FDPG-Paths $\langle K,L,n\rangle$, add a new Functional Dependency node to represent the transitive dependency $X\to A$, and (using plain and red edges) ensure that all LHS and RHS attributes are connected to the ports of the new dependency node. This creates the direct path $\langle K,n\rangle$. According to Definitions 3 and 6 this new path is valid. ∎

Theorem 11**.**

The Transitive Closure Strategy is complete. That is, it finds all functional dependencies that can be inferred from the original set of FDs using Armstrong’s Axioms but ignoring the meaningless dependencies that would be generated by the Reflexivity axiom.

Proof.

We know that Armstrong’s Reflexivity, Transitivity and Union rules, together, form a complete system of inference rules. We have to show that these three rules can be deduced from the Transitive Closure Strategy, or more precisely, from rules Transitivity1..k. As noted earlier, a repeating pattern forms on the left-hand side of F1 in our Transitivity rules as $k$ increases. A $k$-ary Armstrong’s Union operation is performed by Transitivityk. For example, Transitivity2: if the left-hand sides of F2 and F3 are the same attribute set, and the rule simply copies those edges (which it does), then the system behaves as if it performed the Union operation. It is obvious from the structure of the FDPG-Rules that they perform what Armstrong’s Transitivity rule does. ∎

Theorem 12**.**

Let $\Sigma$ be a set of functional dependencies and $G_{\_}\Sigma=(V,P,E,D)_{\_}{{\cal F}}$ the FDPG representing $\Sigma$. The Transitive Closure Strategy (TCS) is a terminating program that never fails. That is, assuming that there are no cyclical dependencies in $\Sigma$, there is no infinite descending chain in the Derivation Tree.

Proof.

Never fails. We know from the semantics set out in [13] that the expressions ${\tt while(}C{\tt)do(}S{\tt)}$ and ${\tt repeat(}S{\tt)}$ never fail. ${\tt one(}IterOn{\tt)}$ will also never fail because ${\tt while(}{\tt match(}IterOn{\tt)}{\tt)}$ will check if it is possible to execute it at all. ${\tt one(}IterOff{\tt)}$ will always apply because every execution of it is preceded by an execution of IterOn and Transitivityk rules do not change the iter and visited values of any pre-existing nodes.

Finitely branching. It follows from Property 9 that the Derivation Tree of the strategic graph program $(G_{\_}\Sigma$, TCS$)$ is finitely branching.

Embedding. We want to find an embedding of $(G_{\_}\Sigma$, TCS$)$ into $(\mathbb{N},>)$. We do this by defining a measure for every loop in the strategy. For ${\tt repeat(}{\tt one(}Transitivity_{\_}k{\tt)}{\tt)}$, the measure is the number of possible matches of the LHS subgraph of F1. This is a good measure because a) the Rule Condition on UID prevents re-application of the rule and b) even though the NEW node is added, it is not part of the LHS subgraph of F1. For ${\tt while(}{\tt match(}IterOn{\tt)}{\tt)do(}...{\tt)}$ the measure is $|V_{\_}{FD}|_{\_}{G0}+|\Sigma^{+}|-|V_{\_}{FD}|_{\_}{Gi}$. That is, the initial number of FD nodes in $G_{\_}\Sigma$ plus the size of the transitive closure of $\Sigma$ less the number of FD nodes after the $i$th application of the loop. With one successful application of Transitivityk the number of FD nodes increases therefore the measure decreases. Note that neither of these measures can be 0 or less. From these it follows that the above detailed measure provides a good monotone mapping into $(\mathbb{N},>)$.

Then from Lemma 2 it follows that the strategy terminates. ∎

6 Conclusion

Our results can be used to build a strategic graph program that takes the transitive closure as input and finds a minimal cover [3, 15]. From a minimal cover, all candidate keys of a relation schema can be found [17]. The minimal cover and the set of candidate keys can then be used as inputs to Bernstein’s Synthesis Algorithm to synthesize Third Normal Form [8] schemata.

Future Work Definition 3 may be generalized such that the Attribute nodes have a list of dependency ports, each element of the list corresponding to a type of data dependency that can exist in a database (e.g. multi-valued dependency). Converesely, each dependency type requires the introduction of its own Dependency node type. Each new Dependency node type may represent bilateral dependencies (LHS and RHS) or multilateral ones. Each new dependency type will require its own Path definition.