PATTERNS OF DATA MODELING- P13 potx

3.2 Structured Directed Graph Template 41 in Figure 3.7a) can have child nodes each of which in turn can be a leaf node or a further branch node. The distinction between parent and child causes the sense of direction that ef- fects directed edges. Note that with this template there can be at most one coupling between a pair of nodes. Figure 3.9 adds the constraint that each node has a parent except for root nodes. (The template itself is more permissive and lacks this constraint.) In general, a directed graph may have cycles but this template disallows them. (A cycle starts at a node and after traversing a series of edges reaches the starting node.) Since this template is based on a tree template, it doesn’t make sense to permit cycles. Each node may have a name. As Figure 3.10 shows, node names can be globally unique (left template) or unique within a context (right template). 3.2.2 IDEF1X Template Figure 3.11 restates Figure 3.10 with the IDEF1X notation. The following are foreign keys: dgID references DG, rootID references Node, parentID references Branch, childID referenc- es Node, leafID references Node, and branchID references Node. The generalization is ex- haustive—every Node record must have a corresponding Leaf record or Branch record. The nodeDiscrim field is an enumeration with values “Leaf” and “Branch” indicating the subtype record. Figure 3.11b defines parentID + nodeName as the Node_Branch primary key, but par- entID + childID could be the primary key instead. Node_Branch defines node names for all nodes except for the roots. The root nodes obtain their name from the combination of dgID + nodeName. Once again the choice of primary key is arbitrary for DG_Node and could have been the alternate key instead. 3.2.3 SQL Queries Figure 3.12 and Figure 3.13 show SQL queries for common traversals of the template. The colon prefix denotes variable values that must be provided for each query. Figure 3.10 Structured directed graph: UML template, with node names. There are two variations of the template—globally unique names and unique names within a context. (a) Globally unique node name (b) Unique node name within a context <Branch><Leaf> <DG> parent root 0 1 * <Node> nodeName {unique} child * * <Branch> <Node> <Leaf> <DG> child parent root 0 1 0 1 nodeName * nodeName 0 1 42 Chapter 3 / Directed Graph Template (a) Globally unique node name (b) Unique node name within a context Figure 3.11 Structured directed graph: IDEF1X template. nodeID nodeDiscrim dgID (FK) Node nodeDiscrim Leaf leafID (FK) Branch branchID (FK) nodeName (AK1.1) dgID DG Node_Branch parentID (FK) childID (FK) dgID nodeID nodeDiscrim DG Node nodeDiscrim Leaf leafID (FK) Branch branchID (FK) Node_Branch parentID (FK) {AK1.1} nodeName childID (FK) (AK1.2) DG_Node rootID (FK) dgID (FK) (AK1.1) nodeName (AK1.2) Figure 3.12 Structured directed graph: SQL query. Find the parents for a child node. SELECT Parent.nodeID AS parentNodeID, Parent.nodeName AS parentNodeName FROM Node AS Child INNER JOIN Node_Branch AS NB ON Child.nodeID = NB.childID INNER JOIN Branch AS B ON NB.parentID = B.branchID INNER JOIN Node AS Parent ON B.branchID = Parent.nodeID WHERE Child.nodeID = :aChildNodeID ORDER BY Parent.nodeName; Figure 3.13 Structured directed graph: SQL query. Find the children for a parent node. SELECT Child.nodeID AS childNodeID, Child.nodeName AS childNodeName FROM Node AS Child INNER JOIN Node_Branch AS NB ON Child.nodeID = NB.childID INNER JOIN Branch AS B ON NB.parentID = B.branchID INNER JOIN Node AS Parent ON B.branchID = Parent.nodeID WHERE Parent.nodeID = :aParentNodeID ORDER BY Child.nodeName; 3.2 Structured Directed Graph Template 43 3.2.4 Sample Populated Tables Figure 3.14 shows structured directed graph tables populated with data. The ID values are arbitrary, but internally consistent. In accordance with the template, there are no explicit edg- es; edges are represented via the coupling between nodes. The populated tables use different data than Figure 3.1 because the premise of the template is a tree that is generalized to having multiple parents. Figure 3.14 Structured directed graph: Populated tables. Leaf table leafID 4 5 6 Node table node ID node Discrim dgID node Name 1 branch 1 J 2 branch 1 K 3 branch 1 L 4 leaf 1 M 5 leaf 1 X 6 leaf 1 N Node_Branch table parent ID child ID 12 13 24 25 35 36 Branch table branchID 1 2 3 (a) Globally unique node name (b) Unique node name within a context NM LK J NXM LK J YX Leaf table leafID 4 5 6 Node table node ID node Discrim 1 branch 2 branch 3 branch 4 leaf 5 leaf 6 leaf Node_Branch table parent ID node Name child ID 1K2 1L3 2M4 2X5 3Y5 3N6 Branch table branchID 1 2 3 DG_Node table root ID dg ID node Name 1 1J 44 Chapter 3 / Directed Graph Template 3.2.5 Examples Directed graphs often arise in applications and sometimes the structured directed graph is a good choice. Figure 3.15 revisits the file directory model of Figure 2.26. With a UNIX TM file direc- tory a hierarchy no longer suffices because a file can belong to multiple directories via sym- bolic links. A file may have a different name in each directory where it is referenced. In Figure 3.15 a File may be a DataFile or a DirectoryFile. Directories contain multiple files, some or all of which may be subdirectories. The combination of a DirectoryFile and a fileName yields a specific File—file names are unique within the context of a directory. All Files belong to one or more directories except for the root File. Directories can be nested to an arbitrary depth, with DataFiles and empty DirectoryFiles terminating the recursion. Files require an acyclic graph, so the model has an added constraint. (The term “acyclic” means that you cannot start with a file and traverse some sequence of files and reach the starting file.) Web email services (such as Yahoo, Google, and Hotmail) let users define lists that group together email addresses. Although most services don’t support it, there is no reason why a list could not contain lesser lists. In Figure 3.16 the friends list contains the family list, the colleagues list, and additional email addresses. Bill P and Paul B belong to both the friends and colleagues lists. Figure 3.17 models nested email address lists. For this example, names are globally unique and do not vary by context. FileSystem root DirectoryFile File DataFile fileName {All files have one or more parent directories except the root file.} {The file graph must be acyclic.} 0 1 1 0 1 * Figure 3.15 Structured directed graph: File system directory model. Figure 3.16 Sample data for email address lists. friends list family list colleagues list Mike E Ed S Mark L Bill P Paul B family list Jim B Barb B Ron B Karen B Jean B colleagues list Bill P Paul B Serge T Neil C 3.3 Node and Edge Directed Graph Template 45 3.3 Node and Edge Directed Graph Template 3.3.1 UML Template A third template for directed graphs has explicit edges (Figure 3.18). Nodes and the edges that connect them can both bear information. Figure 3.2 and Figure 3.9 describe directed graphs with at most one edge between nodes; edges are implicitly represented by parent–child relationships. Figure 3.18 is more powerful and can describe any directed graph. A DG (directed graph) is a set of nodes and a set of directed edges that connect nodes. (Note: in a directed graph all nodes do not have to be connected.) You need not show DG in a use of the template. A Node is an entity type whose records are organized as a directed graph. An Edge is a coupling from a source Node to a sink Node. Coupled nodes and edges must belong to the same directed graph. Note that this template permits cycles. In practice, some applications of the template permit cycles and others do not. With this template the names of nodes and edges are globally unique. There is no context to provide an alternative approach to naming. 3.3.2 IDEF1X Template Figure 3.19 restates Figure 3.18 with the IDEF1X notation. The following are foreign keys: dgID references DG, sourceNodeID references Node, and sinkNodeID references Node. Figure 3.17 Structured directed graph: Nested email address list model. ListEmailAddress parent root 0 1 * Entry name child * * EmailAccount userName password <DG> <Edge><Node> source sink 0 1 0 1 ** * * 1 1 Figure 3.18 Node– and edge–directed graph: UML template. Use when there is data for edges as well as nodes. {Coupled nodes and edges must belong to the same DG.} . referenced. In Figure 3.15 a File may be a DataFile or a DirectoryFile. Directories contain multiple files, some or all of which may be subdirectories. The combination of a DirectoryFile and a fileName. (directed graph) is a set of nodes and a set of directed edges that connect nodes. (Note: in a directed graph all nodes do not have to be connected.) You need not show DG in a use of the template. A. represented via the coupling between nodes. The populated tables use different data than Figure 3.1 because the premise of the template is a tree that is generalized to having multiple parents. Figure