Database Reference
In-Depth Information
Start by observing the objects in the real world, in this case, the emergency room.
The data model must represent the information requirements of this real-world sit-
uation. What do you see? What are the objects in the emergency room? In fact,
there are many objects, and each object has a set of data relating to it. Begin with
the patients in the emergency room waiting for their turn. There is a bunch of data
about each patient. Then you see the nurses in attendance. Data elements about the
object called NURSE may be enumerated. Next, you notice the physicians attend-
ing to patients in the booths behind the waiting area. The object called PHYSICIAN
has a set of data relating to it. Then you look around and see the walls and ceiling
and the overall lighting. What about the data about the walls and ceiling—the color
of the walls and the height of the ceiling? You also hear the supposedly soothing
music that comes over the PA system.
There is no need to push the observation farther. Two aspects of the information
content of the real world become clear. When you observe the real world for infor-
mation content, first you notice the existence of a large number of objects about
which data are available. Second, you also realize that for each object there exists
an abundance of data. Here is the predicament. What do you do with the abun-
dance of data in the real-world situation? How do you represent the real-world
information content in a data model?
Filtering Out Irrelevant Data
When you observe the real-world objects and the extent of data about these, how
do you translate these into a data model? We mentioned that a data model is a
replica or representation of real-world information requirements. A data model is
a representation, but with one qualification. It is a representation only insofar as it
is relevant to the purposes of the database.
Go back to the scenario of the emergency room. What is the stated purpose of
the database in this case? Ability to support billing for emergency services. The types
of uniforms worn by the nurses, the color of the walls in the waiting area, the height
of the ceiling, the nature of the music heard, and the overall number of doctors in
attendance—are these germane to the process of billing for emergency services?
Not really. However, if the purpose is to assess the customer service in the emer-
gency room, then the color of the walls, the state of cleanliness, and the nature of
the music may all have a bearing.
What, therefore should a data model reflect? Not the entire information
content of the real world, only those data elements that are relevant. In the emer-
gency room situation, the data model for billing must exclude data elements such
as the nurses' uniforms, wall colors, and ceiling heights. Remember, though, these
could have been legitimate and relevant data if the purpose of the database had
been different.
Figure 5-6 illustrates this filtering process for creating the data model for billing
for emergency services. Note the data items that are excluded and observe how only
those relevant to the billing process are included.
Usually, most of the filtering out of irrelevant data happens during the require-
ments definition phase itself. When you collect information requirements, you
observe the primary business processes, review current applications, and examine
Search WWH ::




Custom Search