Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:9lv9lc.vdt.ln_at_mercury.downsfam.net...

> No reverse-engineering. There is a one-way street that goes:

I appreciate your reason for taking this stand. I honestly think you are going to be forced to reverse yourself by the people who can't resist reverse engineering. Reverse Engineering may be "skunk works", but it's one of the best ways I know to recover the investment in outdated forms of expression, whether that's COBOL or SQL.

>
> Human being or design tool -> text file spec -> tool -> database
>

You may want to take a look as DA (Data Architect, part of Power Designer from Sybase).

It will do this, but it will also do an ODBC connection to an existing database, and tell you of any differences between the model of the metadata inside DA, and the model of the metadata expressed in the catolog of the database.

In other words, if the customer has been DDLing with the database, it will rat on the customer! Boy, would that have saved you some time in one of the situations you recounted!

It can also "upgrade" a database, without interrupting everything else.

> It actually took me years to completely work out the idea that the system
of
> record must exist both in definition and in reality outside of the system
> it governs. If you are building a database you can store a reference copy
> of the spec inside of it, but the persistent store for the spec must be
> outside of the database. It took so long because I tried it different
ways
> and then of course had to make a living with the results of different
> decisions before I could try it a different way.
>

This is excellent. I'm inclined to agree, although I haven't thought this through, and I might roll back later.

In the meantime, I'd rather explore than debate.

First off, I wonder if you can tolerate the following terminology, which I'm borrowing from DA.

[The following turned into a long overview of DA. I'm sorry if it's too long, and I'm sorry if it sounds like I'm selling DA. I am not. But I am favorably impressed with it, at least in concept.]

DA works on files that contain "data models". The data model is, afaik, expressed as data, but it's a black box from my point of view. All I know is what I see on the screen, which is diagrams and text.

DA has three kinds of models: a Conceptual Data Model (CDM), a Physical Data Model (PDM) and an Object Oriented Data Model (OODM).

The CDM is implementation independent. It's so much like ER modeling that I would just call it an extension of ER modeling. It can express many-many relationships on the screen, but it doesn't use foreign key to implement them. It has some nice features that I don't remember learning when I learned ER modeling. One nice feature is the "generalization/specialization" relationship. Examples are: a vehicle is a car or a truck or a bus; a member of the college community is a student, a faculty member, or a staff member or any combination of these.

The PDM is implementation dependent. Before you can move from a CDM to a PDM, you have to pick a database: Oracle, DB2, SQL server, MS Access, and so on. The PDM models such things as TABLES and INDEXES, but also such things as TABLESPACES. If you print out a diagram for the PDM and the CDM, you are going to see that the table design is pretty much what you would expect if you have ever converted an ERD into a SQL database by hand.

The OODM is not a model of a database. Rather it's a model of some data definitions that a programmer in a language like Java is going to need, in order to make sense to the data that comes out of the database, inside an object oriented world. I do not know how they map sets of rows into objects.

You can have one CDM with multiple PDMs, each for a different target implementation. You can also have multiple OODMs for one CDM, but I don't know what that implies.

You can edit any model interactively, or you can let DA take a shot at doing the design automatically, and you can combine the two activities.

You can use a PDM to spit out SQL, or you can interactively make an ODBC connection to an existing database.

You can use an OODM to spit out some kind of Java data definition stub, but again, I don't know anything about that.

And, yes, Kenneth, it does reverse engineering (refs unconcepts ++ungood!).

But if your model is kept at the development site, there isn't any way a hacker from the production site is going to mangle your model, unless the hacker can crack into your files!

Any way, to make a long story short, do the terms CDM, PDM, and OODM map well into your paradigm, where your design tool is separate from the implemented DB? Received on Fri Oct 22 2004 - 17:07:15 CEST