Database Reference
In-Depth Information
We also went through special cases of objects that are related in a particular way.
One object appeared to be contained within another or one object seemed to be
inheriting attributes and relationships from another object. This is the concept of
generalization and specialization. You have also noted examples of supersets and
subsets.
We now want to consider a few remaining concepts about special object types
and relationships. This would complete the types of objects and relationships you
commonly come across in real-world information requirements. As you know, a data
model must be a true replica of everything relevant in the real world.
Conceptual and Physical Objects
Assume that you are asked to model the information requirements for an airline
company. Very quickly, you realize that AIRCRAFT must be one of the objects in
your data model. Now examine the requirements of the company with regard to the
object AIRCRAFT. The company's fleet consists of many aircraft. Each of these
aircraft has a serial number, a given number of seats, the date it was placed in service,
the chief mechanic responsible to service it, and so on. The company needs to keep
track of all the planes in its fleet. Notice also that the company uses different types
of aircraft like Boeing 747, MD 11, Airbus 321, and so on. The company needs to
keep track of the aircraft types used in its fleet as well. What are Boeing 747, MD11,
Airbus 321, and so on? Are these aircraft? No, these are types of aircraft, not the
physical aircraft themselves. In this case of information requirements for the airline
company, you find two types of related objects. One is the object AIRCRAFT and
the other is the object AIRCRAFT TYPE.
Now consider the information requirements for a library. The library has to keep
track of the individual copies of the topics so that it will know which particular copy
is out with a member. Each copy is marked with a call number. Furthermore, the
library must also have a catalog of topics available for members. These are not the
actual copies of the topics but the titles. So, in this case, you see the need for two
related objects in your data model: BOOK and BOOK COPY. The two are not the
same. The instances within each object are different. In the case of the object
BOOK, the instances are the individual titles; for the object BOOK COPY the
instances are individual copies of the topics.
Just one more example. An appliance store needs to keep track of individual
units of each appliance. Also, the store has to maintain a list of the types of appli-
ances available in the store. Here you note the need for two related objects in the
data model: APPLIANCE UNIT and APPLIANCE TYPE.
Physical Objects
The objects like AIRCRAFT, BOOK COPY, and APPLI-
ANCE UNIT are examples of physical objects. A physical object refers to tangible
objects that you can see, touch, or feel. These are physical things. You need to have
physical objects in your data model, whenever the information requirements call
for keeping track of individual, physical things.
What about the instances within a physical object? Each instance represents a
particular physical thing. The instances within the object AIRCRAFT are the phys-
ical aircraft in the company's fleet. If the company owns 100 aircraft, 100 instances
exist within the object set. In the same way, if the library has a total inventory of
Search WWH ::
Custom Search