Database Reference
In-Depth Information
Implementing the types in this way makes it easy to find the employee
data because all of it is in the same place. The only drawback is that you
must implement some logic to look at the columns that are appropriate to
the type of employee you are working with. This supertype-only imple-
mentation works well only because there are very few additional attributes
from the subtype's entities. If there were a lot of differences, you would
end up with many of the columns being NULL for any given row, and it
would take a great deal of logic to pull the data together in a meaningful
way.
Subtype Tables
When the data contained in the subtypes is dissimilar and the number of
common attributes from the supertype is small, you would most likely im-
plement the subtype tables by themselves. This is effectively the opposite
data layout that would prompt you to use the supertype-only model.
Suppose you're creating a system for a retail store that sells camera
equipment. You could build a subtype cluster for the products that the
store sells, because the products fall into distinct categories. If you look
only at cameras, lenses, and tripods, you have three very different types of
product. For each one, you need to store the model number, stock num-
ber, and the product's availability, but that is where the similarities end. For
cameras you need to know the maximum shutter speed, frames per second,
viewfinder size, battery type, and so on. Lenses have a different set of at-
tributes, such as the focal length, focus type, minimum distance to subject,
and minimum aperture. And tripods offer a new host of data; you need to
store the minimum and maximum height, the planes on which it can pivot,
and the type of head. Anyone who has ever bought photography equip-
ment knows that the differences listed here barely scratch the surface; you
would need many other attributes on each type to accurately describe all
the options.
The sheer number of attributes that are unique for each subtype, and
the fact that they have only a few in common, will push you toward imple-
menting only the subtype tables. When you do this, each subtype table will
end up storing the common data on its own. In other words, the camera,
lens, and tripod tables would have columns to store model numbers, SKU
numbers, and availability. When you're querying for data implemented in
this way, the logic needs to support looking at the appropriate table for the
type of product you need to find.
Search WWH ::
Custom Search