The fastest easiest way to get it right.

Normalization and Automation

A successful project must have an accurate specification, which is no more and no less than a clear description of what the program will do. While this sounds like a simple thing to produce, it can be fiendishly difficult for any but the simplest projects.

There are various proposed solutions available to these difficulties, but none of them seem to provide a definitive transformation of the problem into something more predictable than it is now. Andromeda's solution to this problem begins by restating the situation: "All business rules resolve to database specifications".

Andromeda begins by asking what elements of a specification must be correct if the program is to have any hope of succeeding. The answer to this is of course the database specification. A correct database specification has the hope of leading to a working system, while an incorrect database specification lacks even that hope (programmers and programming managers can actually be very optimistic about lost causes, so perhaps we should say a bad spec lacks a realistic hope of success).

So any effort to automate the software development process must begin with the spec, and the spec begins with the database. This leads to database idea one:

Idea 1: All business rules resolve to database specifications.

Once the users start talking about databases, they will almost always mix together two kinds of information that database theorists much prefer to keep separate. These separate kinds of data are primary data and derived data, where derived data is anything that can be computed or generated from primary data. If we lay aside for a moment the question of why the theorist wants to keep them separate, we can approach the reality of our second database idea:

Idea 2: Derived values are part of any database specification.

Current industry wisdom, which is Relational Database Theory, is governed by the idea of normalization, which seeks eliminate many categories of error by removing redundancies. Derived values are inherently redundant, and are therefore forbidden by relational theory. This proscription leads us to conclude that the theory is not sufficient for the entire scope of fundamental user needs, and therefore:

Idea 3: Normalizing relational theory must be placed into a context that supports derived values.

This context is not hard to find. We first recognize that normalization is crucial for values supplied by sources outside of the server, and should be used without modification to maintain correctness on that data. However, if the server is given complete control over derived values, and the rules for derivations can be kept free of conflicts, then the derived values can be guaranteed to be consistent with the specification. This leads directly to the fourth and fifth ideas of the Andromeda database theory:

Idea 4: Values supplied from outside sources are governed by normalization and constraints. The server may provide defaults for these, but can never override user-supplied values.

Idea 5: Derived values are controlled entirely by the server, the user can never supply values for automated data.

The Andromeda database theory is to make full use of normalization for all user-supplied values (where the user can be any external source like an automated feed), and then to provide a systematic treatment of derived values that are controlled by the server.

Including derived values in a specification does not imply anything about how or when those derivations will be performed. Some automations can be implemented any number of ways, while others are restricted by their nature to very specific implementations.

comments powered by Disqus
Home |  Documentation |  Download |  Credits |  Contact |  Login
Andromeda © Copyright 2004-2013, Licensed under the GPL Version 2