Column Aggregation
is the Fundamental
Relational Constraint
|
|
By organizing information into tables, we have already imposed many constraints,
possibly the greatest proportion of all constraints which will eventually effect our data.
We organize raw data concepts into (at least) first normal form - i.e., no repeating
values - precisely because we want to impose constraints which implement business
requirements. For example, we structure a PERSON table with exactly one column
for DATE_OF_BIRTH to implement the obvious business rule that one human was born
only once (ignoring more complex issues of vanity and deceit). |
 |
|
If we wanted to design a database devoid of constraints, or more constructively, one
which would be maximally adaptable, then we would use the binary technique where every
attribute sits in its own table and is only related to others through many-to-many
association tables. This scheme is not new. There have been studies of binary databases
for at least twenty years. Yet as long as we must pay any price for I/O and processing, we
will not be able to afford to join every attribute involved in even the simplest view of
data.
Binary database concepts bring to mind Object Role Modeling
as exemplified in InfoModeler. Although
ORM examines and models data from a binary perspective, it also transforms thebinary model
into a fully normalized (i.e., aggregated) relational schema. |
 |
|
The instant we aggregate columns into tables we impose constraints and we begin to
partition our application logic. In addition to whatever business rules are scattered
through ten thousand modules of code, we must also consider the implicit rules designed
into the data structures themselves. That much may be unavoidable unless we want to revert
to free-form data under program control, back to the pre-database days of ISAM files. However,
we must not take column aggregation for granted. Consider the case of airports and
flights: |
|
|
There are many other sorts of rules and constraints which data modeling conventions
encourage us to embed in our database design without due consideration of the potential
costs. Let's examine these issues in more detail. |
