📄 lib0050.html
字号:
<html>
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<head>
<title>Architect's Exercise: ProjectTrak</title>
<link rel="STYLESHEET" type="text/css" href="images/xpolecat.css">
<link rel="STYLESHEET" type="text/css" href="images/ie.content.css">
</head>
<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0049.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0051.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
<br>
<div class="chapter">
<a name="ch07"></a>
<div class="section">
<h2 class="first-section-title"><a name="233"></a><a name="ch07lev1sec3"></a>Architect's Exercise: ProjectTrak</h2><a name="234"></a><a name="IDX-91"></a>
<p class="para">Now that we've defined all the key data-modeling terms, let's pull them all together into a real application. We'll continue with the following use case from ProjectTrak:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">
<i class="emphasis">The system will allow users to define, edit, and display project tasks.</i> A project task has a name, an estimate (in hours), percent complete, one assigned personnel resource, any number of dependent tasks, and a priority (high/medium/low).</p>
</li>
</ul>
<p class="para">The first task in the data-modeling exercise is to identify the entities. And the first question we need to answer is: what things are we keeping information about? A project task is the most obvious candidate and alludes to the existence of another entity, a project. Although the use case doesn't give us any information about the characteristics of a project, we should identify it as an entity anyway.</p>
<p class="para">The second sentence of the use case gives a list of characteristics for the <span class="fixed">PROJECT_TASK</span> entity. Those traits that are atomic will be attributes of <span class="fixed">PROJECT_TASK</span>. The name and estimate for <span class="fixed">PROJECT_TASK</span> are definitely atomic, so let's add them to <span class="fixed">PROJECT_TASK</span> as attributes.</p>
<p class="para">
<span class="fixed">PERCENT_COMPLETE</span> might (or might not) be an atomic attribute. Another use case for this project states that the product needs to track the time people work on each task. So we could calculate the percent complete for each task by adding up the time people have contributed to the task and dividing that by the hourly estimate. We could argue that the estimate might be wrong and that we might use up all the time estimated for a particular task before completing it. Because the use case doesn't make the issue clear, <a name="235"></a><a name="IDX-92"></a>let's assume that the <span class="fixed">PERCENT_COMPLETE</span> is atomic and might not correlate to the time worked toward a task. We'll check that assumption with a business analyst later.</p>
<p class="para">The phrase "personnel resource" is a bit ambiguous. If we only had this use case to consider, we might assume this to mean the name of that resource and model it as an attribute of <span class="fixed">PROJECT_TASK</span>. However, one of the other use cases mentions tracking skill sets for a resource. That would indicate that a resource is a separate entity with a relationship to <span class="fixed">PROJECT_TASK</span> rather than an attribute of <span class="fixed">PROJECT_TASK</span>. We'll go ahead and identify the entity <span class="fixed">RESOURCE</span>, even though this use case doesn't tell us its attributes. We also know that there is a relationship between <span class="fixed">PROJECT_TASK</span> and <span class="fixed">RESOURCE</span>.</p>
<p class="para">The phrase "any number of dependent tasks" indicates that <span class="fixed">PROJECT_TASK</span> has a recursive relationship (a one-to-many relationship to itself). The children tasks in this relationship are other tasks that must be completed before we can consider <span class="fixed">PROJECT_TASK</span> complete.</p>
<p class="para">
<span class="fixed">PRIORITY</span> might (or might not) be an appropriate attribute. A data-modeling purist might tell you that a priority is separate from a project task and thus should be modeled as an entity. If we did this, we would need to put a one-to-many relationship between the <span class="fixed">PRIORITY</span> and <span class="fixed">PROJECT_TASK</span> entities.</p>
<p class="para">If we had identified a use case that provided for users to define their own priority levels, we would definitely make <span class="fixed">PRIORITY</span> an entity. However, because the use case only mentions priority as a characteristic of a project task, let's model <span class="fixed">PRIORITY</span> as an attribute of <span class="fixed">PROJECT_TASK</span>.</p>
<p class="para">While the use case doesn't specify a relationship between <span class="fixed">PROJECT</span> and <span class="fixed">PROJECT_TASK</span>, most people would feel comfortable that there is one. Another ProjectTrak use case states that projects can have multiple tasks. Although we could be accused of jumping the gun a bit, we'll go ahead and draw in the relationship.</p>
<p class="para">Next, we need to identify primary keys for our three entities. At this point, let's assume that we have to artificially construct a key for each. We'll call them <span class="fixed">PROJECT_ID</span>, <span class="fixed">TASK_ID</span>, and <span class="fixed">RESOURCE_ID</span>. Typically, we would record the assumption and revisit it after we've analyzed several other use cases. We may be able to identify a natural key for each entity later in the analysis. Natural keys are preferable to artificially constructed keys because they are more intuitive and understandable. Artificial keys also require additional application logic to generate and maintain.</p>
<p class="para">Perhaps you felt a bit uncomfortable with making assumptions in this exercise. But it's a fact of corporate life: few decisions (including design <a name="236"></a><a name="IDX-93"></a>decisions like the ones we made here) are made with perfect information. Try as you might, your use cases will never be 100 percent complete.</p>
<p class="para">
<a class="internaljump" href="#ch07fig06">Figure 7.6</a> shows the ProjectTrak data model.</p>
<div class="figure">
<a name="237"></a><a name="ch07fig06"></a><span class="figuremediaobject"><a href="images/fig109%5F01%5F0%2Ejpg" NAME="IMG_25" target="_parent"><img src="images/fig109_01.jpg" height="134" width="350" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 7.6: </span>ProjectTrak Data Model Example</span>
</div>
</div>
</div><br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td><div STYLE="MARGIN-LEFT: 0.15in;"><a href="toc.html"><img src="images/teamlib.gif" width="62" height="15" border="0" align="absmiddle" alt="Team LiB"></a></div></td>
<td align="right"><div STYLE="MARGIN-LEFT: 0.15in;">
<a href="LiB0049.html"><img src="images/previous.gif" width="62" height="15" border="0" align="absmiddle" alt="Previous Section"></a>
<a href="LiB0051.html"><img src="images/next.gif" width="41" height="15" border="0" align="absmiddle" alt="Next Section"></a>
</div></td></tr></table>
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -