Re: the relational model of data objects *and* program objects

mountain man wrote:

>
> However one should note that in real terms the change-management
> of data and application code (ie: programs) will see that everything
> is in a state of flux, driven by change in the environment.
>

There an important point here. If meta-data describes user data, then change management is the application of a delta-meta-data. If your meta data is true meta-data, meaning rows and columns (XML flames to /dev/null), then the delta-meta-data is magically transformed into first-order logic and an easily codable sequence of events. But more importantly, you can validate the destination state, and also validate the delta itself using very simple constraints, often just using unique and referential constraints. For instance, you can take a SELECT of column types before and after, and look them up in a table of allowed transformations. The table would show "from char to text" as OK, but would have no row for "from char to int", causing the delta to fail validation with message "cannot convert column foo in table bar from char to int".

But you can never do this with human-supplied code. There is absolutely nothing intrinsic in the code that will give the same level of guarantee that you are installing something that will actually work.

It was that basic realization a few years ago, when my job was writing change management, that I realized:

Change Managements = Upgrades = Installs = Development

They are all the same thing and should be handled by the same tools and must be foolproof. Code is the sore thumb in the picture, it does not allow foolproof change management. Hence the need to find a way to replace human-generated code in the db.

<snip>

>
>
>

>>> The relational model of the data is a very good reference for the
>>> management of data and its integrity within the RDBMS, but it
>>> is totally useless for program objects, and thus is restricted in
>>> issues involving the coordination of both data and program
>>> objects.
>>
>> The relational model is permanently hobbled by normalization.
>> Normalization
>> provides an astoundingly simple and powerful way to pursue conformance,
>> but
>> it has nothing to offer in the area of *completeness*.  A normalized
>> database is required to be incomplete, to be missing data that is
>> valuable to the computer's human masters, data that would serve them well
>> by its existence and which causes confusion and expense by its absence.

I always liked grandmother's advice to have "a place for everything and everything in its place". not very theoretical :)

>
>
>
>

>>> Since the emergence of addressable stored procedure objects
>>> within the RDBMS vendor software at the end of the 1990's
>>> program objects have lived within the RDBMS.
>>
>> Yes!  Returning again to your first paragraph, the database server can
>> now store inert data and also perform actions upon that data, much more
>> than simply playing Schoolyard Crossing Guard and saying what can go in
>> and what
>> can't.
>>
>> So, if we had a model that spoke to both structure (data table layouts)
>> and
>> actions (triggers, sprocs), etc., we'd have the Grand Unified Theory, no?

I have the creeping suspicion that such a change will not come about through discussion and persuasion. If the insight is correct, then the weilder of the tool will have an "unfair advantage" in generating software, and will gain market strength through organic growth.

>

>>> Given that such an environment exists whereby both data objects
>>> and program objects are physically stored within the RDBMS
>>> has anyone seen recently any emergent models that address both
>>> these objects in a consistent manner?
>>
>> If the question can be phrased as, has somebody unified a picture of
>> inert data and active code, I will say no, though of course that
>> assertion will be disputed.

I was thinking of object-relational, but probably should have said so.

<big snip>

>

>>The normal toy example is an
>> automated column extended = price * qty, but if you systematize that and
>> add some other nifty stuff, you can create a database that can do
>> anything that procedural code can do, and organize the entire process
>> flawlessly from analysis to real-world use.

Exactly! But I have gained some sympathy for those who cannot see this, as I think I have found a trend in the resistance to the idea. It seems that people lack a framework or history for defining automated data, so a lot of time they simply do not know WHERE to put things, its as simple as that.

Consider the simple case of extended = price * qty. A person schooled in normalization will be uneasy about putting that column into the orders table, and will become bogged down arguing over implementation.

The yellow brick road out of that maze is to continue to define properties of entities. Extended price is a property of the item(s) being sold. VAT is a property of order header, even if it does violate 3NF, so define it in terms of the order. This is the yellow brick road that led me to the four fundamental column automations in the whitepaper.

>

>>>
>>> Do you think it is important to address the issue that a model
>>> of both the data objects and the program objects is required?
>>> [As distinct from a model only of the data side of the picture]
>>
>> Me?  Yes.  That's why I wrote this:
>>
>> http://www.secdat.com/dev/atomic.html
>>
>> But it is not a model of unifying code and data, rather it is an
>> expansion of the data model to re-organize code and data.

On the db side it is a "code assembler". I am beginning to settle on the term "Automated Software Assembly" (opponents can then call it Automated Assembly of Software, ASS, ha ha) to distinguish it from CASE and RAD. Each item in the db spec requires some snippet of code, with some substitutions of table and column names. Those are assembled and then loaded into the server.

On the client side we have found it easiest to have the builder copy the spec into the client area, and install the latest library code.

I wrote the builder first in C#. Then when I switched over to Linux completely I translated it to Java (Mono didn't do it for me), and then I made the happy discovery of PHP, it is now in PHP.

But I should stress strongly that it is not a PHP app, it is, for today, implemented in PHP. Our attitude towards all programming languages is "this too shall pass", the asset value is in the specs. The builder must be kept simple and small so that a complete reimplementation of it in The Next Big Thing 10 years from now would be a very small investment.

>>
>> Then, in a weird converse of Conway's Law, we get shops organized around
>> the
>> tiers of the system, with skills concentrated in the db camp, the web
>> code camp, the HTML camp, and so forth, and the technological divisions
>> become organizational divisions and baby that's all she wrote.

yes. I liked your exposition better than mine, but I snipped it because I could add nothing to it.  

>
> Thanks for the dialogue.
>

Thanks as well for raising the subject, I don't get to discuss it often.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)