PATTERNS OF DATA MODELING- P8 potx

parent 0..1 * child Figure 2.11 Sample tree with node names that are unique within a context.. a Globally unique node name b Unique node name within a context nodeName AK1.1 treeID rootI

Trang 1

16 Chapter 2 / Tree Template

2.2.2 IDEF1X Template

Figure 2.12 restates Figure 2.10 with the IDEF1X notation The following are foreign keys:

rootID references Node and parentID references Node.

Figure 2.12 uses existence-based identity which is my preferred approach for database

design (See Chapter 16.) Existence-based identity means that each entity has its own

artifi-cial identifier (such as an Oracle sequence or a SQL Server identity field) as a primary key

Thus the primary key of Node is nodeID and not, for example, nodeName (Figure 2.12a) or

<Tree> root

0 1 1

(a) Globally unique node name (b) Unique node name within a context

<Node>

nodeName {unique}

<Node>

<Tree>

child parent

root 0 1 1

0 1

0 1 nodeName

Figure 2.10 Simple tree: UML template, with node names There are two variations

of the template—globally unique names and names within a context parent 0 1 * child

Figure 2.11 Sample tree with node names that are unique within a context.

ch02 ch01

ch01 ch02 review1 review2

patterns

treeID

rootID (FK) (AK1.1) nodeID

parentID (FK)

Tree

Node

Figure 2.12 Simple tree: IDEF1X template.

nodeName (AK1.1)

treeID rootID (FK) (AK1.1) nodeID

parentID (FK) (AK1.1)

Tree

Node

nodeName (AK1.2)

Trang 2

parentID + nodeName (Figure 2.12b) Although I favor existence-based identity, the tem-plates in this book do not require it

In Figure 2.12 the AK notation denotes a candidate key, that is a combination of

attri-butes that is unique for each record in a table No attribute in a candidate key can be null All candidate key attributes are required for uniqueness

Figure 2.12b defines parentID + nodeName as a candidate key, but one record is an ex-ception The root node for a tree has a null parentID and a candidate key cannot involve a

null Most relational DBMSs treat NULL as just another value and do not strictly enforce

candidate keys, so the definition of a unique key for parentID + nodeName does work (I

ver-ified this for SQL Server and expect that it would work for most relational DBMSs.) Alter-natively, you can forego the unique key and check the constraint with application code

2.2.3 SQL Queries

Figure 2.13 and Figure 2.14 show SQL queries for common traversals of the template The colon prefix denotes variable values that must be provided

2.2.4 Sample Populated Tables

Figure 2.15 shows sample simple tree tables populated with data The ID values are arbitrary, but internally consistent

2.2.5 Examples

Simple trees also arise in many applications

In Figure 2.16 a manager has many subordinates Each subordinate reports to at most one manager: The CEO reports to no manager, and all others report to one manager The

management hierarchy can be arbitrarily deep

Figure 2.13 Simple tree: SQL query Find the parent for a child node.

SELECT Parent.nodeID AS parentNodeID,

Parent.nodeName AS parentNodeName

FROM Node AS Child

INNER JOIN Node AS Parent ON Child.parentID = Parent.nodeID WHERE Child.nodeID = :aChildNodeID;

Figure 2.14 Simple tree: SQL query Find the children for a parent node.

SELECT Child.nodeID AS childNodeID,

Child.nodeName AS childNodeName

FROM Node AS Child

WHERE Child.parentID = :aParentNodeID

ORDER BY Child.nodeName;

Trang 3

In Figure 2.17 formal requests for proposals (RFPs), such as government projects, often involve extensive requirements that are captured with an indented list Level 0 is the ment for the RFP as a whole that elaborates into levels 1, 2, 3, and so forth A level 1 require-ment can have sub requirerequire-ments such as 1.1 and 1.2 These sub requirerequire-ments can have further detail such as 1.1.1, 1.1.2, and 1.2.1 The nesting can be arbitrarily deep depending on the desired level of detail The RFP yields a tree of requirements

A

Node table

nodeID parentID nodeName

Figure 2.15 Simple tree: Populated tables.

Node table nodeID parentID nodeName

R Q

P

Person

manager subordinate

{Every person has a manager, except the CEO.}

0 1 *

Figure 2.16 Simple tree: Management hierarchy model.

{The management hierarchy must be acyclic.}

Trang 4

2.3 Structured Tree Template

2.3.1 UML Template

Figure 2.18 shows the UML template for structured trees when there is a need to differentiate

leaf nodes from branch nodes A Tree is a hierarchy of nodes and has one node as the root.

A particular node may, or may not, be the root You need not show Tree in a use of the

tem-plate

A Node is either a leaf node or a branch node A Leaf node (such as D, E, and F in Figure 2.1) terminates the tree recursion A Branch node (such as A, B, and C in Figure 2.1) can have child nodes each of which, in turn, can be a leaf node or a further branch node Figure 2.18 adds the constraint that a tree cannot have any cycles (See Section 2.2.1 for

an explanation of cycles.) Similarly each node must have a parent, except for the root node

— the template alone is more lax

As with simple trees, the node names in Figure 2.19 can be globally unique (left tem-plate) or unique within a context (right temtem-plate)

2.3.2 IDEF1X Template

Figure 2.20 restates Figure 2.19 with the IDEF1X notation The following are foreign keys:

rootID references Node, parentID references Branch, leafID references Node, and branchID

references Node The generalization is exhaustive—every Node record must have a corre-sponding Leaf record or Branch record The nodeDiscriminator field is an enumeration with

values “Leaf” and “Branch” indicating the appropriate subtype record

Figure 2.17 Simple tree: Nested requirements for RFPs model.

parent child

{Every requirement has a parent, except for level 0.}

0 1 *

RFP

0 1 1

Requirement

name level {The requirement hierarchy must be acyclic.}

<Branch>

<Node>

<Leaf>

parent

root

{All nodes have a parent except the root node.}

0 1 1

0 1

*

Figure 2.18 Structured tree: UML template Use when branch nodes and leaf

nodes have different attributes, relationships, and/or semantics

{There cannot be any cycles.}

Trang 5

As with Figure 2.12b, Figure 2.20b defines parentID + nodeName as a candidate key, but one record is an exception The root node for a tree has a null parentID and a candidate

key cannot involve a null Since most relational DBMSs are lax and treat NULL as just

an-other value, the definition of a unique key for parentID + nodeName does work Although it

is not shown, the Leaf and Branch tables would have additional fields for application data.

2.3.3 SQL Queries

Figure 2.21 and Figure 2.22 show SQL queries for common traversals of the template The

queries could omit the Branch table, but I wrote them according to template traversal—then

it is easy to retrieve any data that is added to the template The colon prefix denotes variable values that must be provided

<Branch>

<Leaf>

<Tree>

parent

root

0 1 1

0 1

*

Figure 2.19 Structured tree: UML template, with node names There are two variations

of the template—globally unique names and names within a context

<Node>

nodeName {unique}

<Branch>

<Node>

<Leaf>

<Tree>

child parent

root 0 1 1

0 1 0 1

nodeName child

treeID

rootID (FK) (AK1.1)

nodeID nodeDiscriminator parentID (FK)

nodeDiscriminator

Leaf

leafID (FK)

Branch

branchID (FK)

Figure 2.20 Structured tree: IDEF1X template.

nodeName (AK1.1)

treeID rootID (FK) (AK1.1)

nodeID nodeDiscriminator parentID (FK) (AK1.1)

nodeDiscriminator

Leaf

leafID (FK)

Branch

branchID (FK) nodeName (AK1.2)

Định dạng
Số trang	5
Dung lượng	162,96 KB