West M. Developing High Quality Data Models
Подождите немного. Документ загружается.
Another possibility is that the requirement is
for a functional_system_component. This hap-
pens, for example, when you are constructing a
complex system, such as an assembly line or a
process plant. What is required is something to
play a particular role in the overall system, which
will be assembled on site.
When I used to design process plants for
Shell, I often found that I needed a pump; either
liquid needed to be moved from on e place to
another, or it needed to be moved from a lower
pressure environment to a higher pressure envi-
ronment, or both. The question is: wh at is this? It
is not an actual pump here and now, because
I cannot kick it, but at some point in the future
there may be (there will be, if my plans work out) a pump that
I can kick that does the job that I am specifying. So we have a
pump whose life will start at some point in the future that is
part of a possible world that may be our actual world if our
plans come to fruition.
Figure 15-4 illustrates the situation. The large ellipse is the
set of all the pumps (the small circles) that are part of any pos-
sible world. The smaller ellipse is the set of those pumps that
meet our requirement specification—say requirement specifica-
tion XYZ—and the two solid circles are the ones that are our
requirement.
Now the two pumps that are our requirement are members
of a product of another organization. I looked at products
in Chapter 13. Since we are looking at a specification-based
view of the product from a customer perspective, then we are
Car at
manufacturer
Car sold
Requirement
My company car
Time
Space
Figure 15-3 Requirement that is a state of
a functional system.
Requirement
specification XYZ
Pump
Figure 15-4 What are the required pumps?
192 Chapter 15 REQUIREMENTS SPECIFICATION
interested in members of sales_product. Different versions of a
sales_product are improved ways of meeting the same specifi-
cation as seen by the purchaser.
Figure 15-5 illustra tes this. The sales_product we have cho-
sen (and we could have chosen from any of the sales_products
in this diagram, since I have only shown those that meet our
requirements) is P15-AB. The diagram also shows that sales_
product is a subset of class_of_functional_object, and that our
requirement specification XYZ is a member of requirement_
specification that is also a subset of class_of_functional_object.
At this point I would just like to distinguish between our
requirement, and our requirement_specification. Our require-
ment is for two pumps, that is, two spatio-temporal extents.
Our requirement_specification defines the properties that
these two pumps must have in order to be suitable; its mem-
bers are all those pumps that are suitable, not just the pumps
we end up with.
class of_
functional_object
requirement_
specification
XYZ
sales_product
PX-75
PB047
PPAB3
P15-AB
P-14GL
17-PX
PX-75
PB047
PPAB3
P15-AB
P-14GL
17-PX
XYZ
Figure 15-5 Pump product selection.
Chapter 15 REQUIREMENTS SPECIFICATION 193
15.2.2 A Data Model for Requirement and
Requirement Specification
Figure 15-6 shows the data model for requirement, requirement_
specification,andsales_product . I have left out some subtype/super -
type relationships and some intervening entity types in the subtype/
supertype network.
A plan is a poss ible_world that some party would like to
bring about.
A requirement is a spatio_temporal_extent that is part_
of_plan of at least one plan and is defined_by exactly one
requirement_specification, where the part_of_plan relationship
type is a subtype of the part_of relationship type and the defined_
by relationship type is a subtype of the member_of relationship
type.
A requirement_specification is a class_of_functional_object
that is the set of possible functional_objects that meet the
specification.
15.2.3 Requirement Specifications
In the preceding overview, I said that there was a
requirement_specification that any possible functional_object
that met the specification was a member of, but that did not
say much about what the specification was. I will cover this
here.
A specification is a collection of individual elements, each of
which is a class that each object that meets the specification is a
member of. So the specification itself is the intersection of these
possible_world
plan
spatio_temporal_
extent
requirement
class_of_
functional_object
requirement_
specification
defined_by S[1:1]
meets_requirement S[1:?]
sales_
product
part_of_plan S[1:?]
Figure 15-6 Requirements
specification and sales product.
194 Chapter 15 REQUIREMENTS SPECIFICATION
classes that are elements of the specifi-
cation. To illustrate this I take some
examples from the American Petroleum
Institute’s standard pump data sheet,
API 676, shown in Table 15-2.
Notice that the first two parameters
have a maximum and minimum value;
that is, they specify a range. This is
quite normal as it would be difficult for
any pump to have an exact discharge
pressure. You will notice that NPSH is
shown as a single value; however, if you
understand pumps, you will know that
this is actually a minimum value but
that there is no particular upper limit.
Some parameters are single valued
though; take, for example, the pump
type, whi ch can be one of the six types
listed (in this case).
Figure 15-7 shows a Venn diagram
for the elements from Table 15-2 of the
XYZ requirement_specification.
One particular thing to note here is the ranges of kind_of_
physical_quantity. In Chapter 12, I developed a data model
for physical quantities, but this did not cover ranges. A range
of physical quantities is simply the superclass of all the physical
quantities that are in the range. It is not generally useful to note
Table 15-2 Excerpt from API 676 Pump Data Sheet
Operating Conditions
Parameter Maximum Minimum
Discharge Pressure (kPa) 10000 5000
Differential Pressure (kPa) 3000 2000
NPSH
1
available (m) 5
CONSTRUCTION
Pump Type x Internal Gear x Twin Screw
•
Vane
x External Gear x Three Screw x Progressing Cavity
1
NPSH stands for Net Positive Suction Head, the difference between the actual pressu re of a liquid in a pipe and its vapor pressure at a
given temperature.
Vane
pump
NPSH
3m
Discharge pressure
5000–10000 kPa
Differential pressure
2000–3000 kPa
XYZ
Figure 15-7 Building up the requirement specification from
the elements.
Chapter 15 REQUIREMENTS SPECIFICATION 195
all the subclasse s of a range; noting the largest and the smallest
is sufficient to define the membership. Ranges of kind_of_
physical_property are also possible, of course, though less
commonly encountered.
15.2.4 A Data Model for Elements of a Requirement
Specification
Figure 15-8 is a data model that shows the elements of a require-
ments specification. A physical_property_range is a class_of_state
that ranges_o ver (is a superset of) one or more physical_property of
the same kind_of_physical_property.Astate is a member_of
a property_r ange when its value for the kind_of_physical_property
falls within the range.
A physical_quantity_range is a physical_property_range
where the kind_of_physical_property is a kind_o f_physical_
quantity and where the physical_quantity_range has an upper_
bound and a lower_bound that are a physical_quantity.
A requirement_specification is a class_of_spatio_temporal_
extent that is the intersection_of one or more class_of_state.
plan
requirement
requirement_
specification
class_of_state
physical_
property_range
physical_
property
physical_
quantity_range
physical_
quantity
part_of_plan S [1:?]
defined_by S [1:1]
intersection_of S [1:?]
ranges_over S [1:?]
upper_bound
lower_bound
Figure 15-8 A data model that shows the
elements of a requirements specification.
196 Chapter 15 REQUIREMENTS SPECIFICATION
16
CONCLUDING REMARKS
In this part I have presented a data model that
• Provides a framework for analyzing business requirements
• Provides a data model of some detailed areas that shows
how business terms can be incorporated into a data model
• Is easily extensible, either by adding entity types or reference
data
This makes it particularly suitable as an integration model.
As I have developed this framework, I have spread data
model fragments over several chapters, so it may not be obvious
that there is a cohesive whole. I have therefore put the whole
model in Chapter 17. From this it can clearly be seen that the
model is coherent and cohesive, as well as extensible in a regu-
lar way; all desirable properties in a changing world. Chapter 17
also makes a handy reference.
One pattern is particularly important and is shown in
Figure 16-1.
If we are interested in Xs where an X is a kin d of individual,
then in addition to an entity type X there will be state_of_X,of
which X is a subtype. state_of_X may have subtypes that are the
roles Xs play as participantsinanactivity or association;
examples shown here are X_in_ role_Y and X_in_role_Z.
A class_of_X is a class that necessarily applies to an X for the
whole of its life. The m ost interesting of these I call kind_of_X ,
which is a class of Xs of the same kind—that have properties in
common—excluding the random sets that class_of_X allows.
Other subtypes may be interesting where particular rules apply.
When a state_of_X is not a participant, it is usually interest-
ing because it has a property_of_X. I have dealt with properties
that apply widely to individuals, but there can also be proper-
ties that are specific to a particular kind_of_individual.
Constructing your data model using a template like this is
like showing your working when you are solving a problem in
mathematics. You do it to make sure you have the right answer.
But having worked the answer out, it is up to you whether you
197
show the working or not. For example, it will not be helpful for
people who do not understand the method you have used, but
it would be convincing for those who do.
Another question is whether it is worth showing your work-
ing at all; there are some extra boxes involved, surely it would
be quicker without them? The answ er is the same as in mathe-
matics. Working things out properly is actually the fastest way
to the right answer, plus it helps to assure that you have the
right answer. In data modeling, it is not the time it takes to pro-
duce a model that determines the effort it takes, but how many
times you have to redo the model before you get it right.
The result overall is improved consistency, especially when
you have a team of data modelers, and a reduction in errors
and rework. All of which leads to high quality data mod els that
meet the information requirements of the business.
state_of_X
class_of_X
kind_of_X
participant
association
activity
class_of_
state_of_X
property_
of_X
X_in_
role_Y
participant_in_
activity_or_
association
X_in_
role_Z
X
temporal_part_of S[1:?]
member_of_kind S[1:?]
(RT) member_of S[1:?]
member_of S[1:?]
has_property S[1:?]
participant_in S[1:?]
Figure 16-1 A basic data
model template.
198 Chapter 16 CONCLUDING REMARKS
PART
4
THE HQDM
FRAMEWORK
SCHEMA
This part provides the full data model that I have been
working through in this book as an EXPRESS schema including
both the EXPRESS-G diagrams and the lexical EXPRESS that is
computer interpretable, descriptions of the diagrams, and defi-
nitions of the entity types and relationship types on each dia-
gram. It is intended as a reference document and an extension
to the data model fragments that I introduced in Part 3.
This schema was developed using Jotne EPM Technology’s
EDMVisualExpress data modeling tool. This part covers one
way in which a data model may be published by
VisualEXPRESS. It may also be published as a website. I intend
to publish this schema as a web resource. You should be able to
find it by searching the web for the schema name.
The data model presented here is broadly compatible with
ISO 15926-2, but there are four key differences.
1. The first is that the metamodel for relationship takes a dif-
ferent approach. The approach in ISO 15926-2 is a little
cumbersome, in particular in the way that n-ary relation-
ships are represented. This has little significance since the
implementation environment will determine the way that
199
the metamodel will be implemented; what is presented here
is a statement of requirements.
2. The second area of difference is in the way that representa-
tion is modeled. In ISO 15926-2, the invo lvement of those
who interpret the sign or pattern was optional. This is
clearly a weakness, and I have remedied this.
3. The third area is in the classes that are represented as
entity types. ISO 15926’s possible_individual is equivalent to
spatio_temporal_extent in the model presented here, and
whole_life_individual is equivalent to individual here. If X is
a subtype of possible_individual , then X is equivalent to
state_of_X in this model, and class_of_X is equivalent
to class_of_state_of_X. ISO 15926-2 does not make explicit
the subtypes of whole_life_individual as I have done here.
Although this made the ISO 15926-2 data model smaller,
I think it also made it a lot less easy to see how it should be
used.
4. The fourth area of difference is in the use of association in
this data model. An association is a state that consists_of its
participants. In ISO 15926-2, these are modeled as relation-
ships between the states, rather than as an association that
consists_of the states.
A mapping of the key entity types in the schema presented
here to ISO 15926-2 is presented in Appendix A.
200 Part 4 THE HQDM FRAMEWORK SCHEMA
17
HQDM_FRAMEWORK
CHAPTER OUTLINE
17.1 Thing and Abstract Object 202
17.2 Class and Class of Class 204
17.3 Relationship and Class of Relationship 207
17.4 Spatio-Temporal Extent and Class of Spatio-Temporal Extent 211
17.5 Event, Class of Event, and Point in Time 216
17.6 State and Individual 218
17.7 Physical Object 220
17.8 Ordinary Physi cal Object 223
17.9 Kind of Individual and Subtypes 226
17.10 Kind of System and System Component 230
17.11 Period of Time and Possible Worlds 233
17.12 Physical Proper ties and Physical Quantities 235
17.13 Association 241
17.14 Activity 243
17.15 Participant 245
17.16 Role, Class of Activity, and Class of Association 247
17.17 System 251
17.18 System Component 254
17.19 Installed Object 256
17.20 Biological Object 257
17.21 Ordinary Biological Object 260
17.22 Biological Syst em 263
17.23 Person 265
17.24 Biological Syst em Component 268
17.25 Intentionally Constructed Object 272
17.26 Functional Object 274
17.27 Ordinary Functional Object 277
17.28 Functional System 280
17.29 Socially Constructed Object 286
17.30 Party 290
17.31 Organization and Language Community 292
17.32 Employm ent 296
17.33 Organization Component and Position 298
17.34 Money 304
201