Re: Database design

mAsterdam <mAsterdam_at_vrijdag.org> wrote:

>> That is, the tables are supposed to correspond to relations in RM.

>You could have tried a different phrasing. I'll just
>guess an interpretation.

No need for that. Take it from Codd:

Rule #2: "table name, primary key value, and column name"

Rule #1: "values in tables"

Perhaps you would argue that he meant "relation" to mean something more than one table?

>"relation" is a defined term in RM.
>"tables" is AFAIK /not/ part of RM - but I am not a RM specialist.

Codd was. Now, of course, if this is not the language he used in that magazine article, then it's another matter.

>In informal use, "table" and "relation" roughly map.

Mmm.

>> more dependent upon and/or complicated that fixed structure becomes,
>> there is the possibility that modification to that structure or design
>> become prohibitive, or at least very much prone to error.

>Yes. This holds for structures of buildings, cells,
>musical compositions, and other systems.

Not necessarily. A musical composition can be modified by simple insertion, either by Mozart or Lars of Metallica before his cut n paste machine. Another chorus can be added, the entire tempo changed at points with a few 'marginal' marks on the score, etc.

But to modify a skyscraper, say one just detests the proposed replacement for the WTC, as example, it might be difficult to just axe the 'latticework' - wait a minute. That's what I think they did. Maybe it would be difficult to modify the sort of masonic triangle, pentagram, hexagram suggestions, and so on. But I think if that has also - wait a minute. I think they did, at least on one side. But I could be wrong about that.

I would agree, that when it comes time to lay the foundation, that is not the time to modify the design. When one has completed the multi-story lobby, it's not a good time to decide that the profile of the building should be changed. So, I'd agree.

>> But only to point out that the structure from which RM sought to free
>> people, from COBOL or whatever else, was replaced by another equally
>> inflexible structure.

>I am not a native english speaker.

That structure of tables and links is as inflexible as a COBOL hierarchy, in other words, in terms of later modification. I thought you had agreed. But such inflexibility is not found in a tree structure, suggested by the need to use explicit/full/materialized paths, to which branches and leaves can be added, literally at whim.

>> But if one builds a COBOL structure upon it,
>> without the interwoven programming, a hierarchy, then perhaps it
>> becomes more useful, but in a way, and for creating certain problems
>> by that (by violating the fundamentals of RM) which some sought to
>> address by a full/materialized path key.

>Maybe - probably not. But do you, some certainly, in a way agree?

I would certainly hope that I might agree with what I myself wrote, yes; unless I thought I was in error and mistaken. And I don't think that.

If one builds a COBOL structure upon it, without the interwoven programming, a hierarchy, then perhaps it becomes more useful, but in a way, and for creating certain problems by that (by violating the fundamentals of RM) which some sought to address by a full/materialized path key.

>> Domains. Imagine a graph or chart. Interpolation through points. You
>> store the points. But a set of points might itself become a primitive
>> by reference. But the initial set of primitives would have to be
>> treated in another fashion. Maybe 'true' primitives vs. 'combined'
>> primitives. But that's weak. Essentially there are the same, but the
>> initial state items would probably require different handling and
>> reference than anything constructed from them. Again, because it is a
>> practical matter, perhaps any theory must necessarily reflect that, as
>> well. But maybe not. I don't know.

>Aside: Ah yes - again you delete the essence,
>and you don't respond to it.

And by that, I think . . you meant:

>what you /choose/ to see as primitives or combined primitives.
>If you can't decide on that, you can't design a database.

But it's done all the time. People do combine primitives into larger constructs. These in turn become primitives to others, and so on. Some have used the term, blocking, to describe this pattern of knowledge. And everyone does it. That cat is out of the bag. That lamp has been rubbed. In fact, people couldn't function in any other fashion.

>How are "containment hierarchies" and "organisation hierarchies"
>different/the same?

It seems that an organizational hierarchy need not be qualified or modified as, organizational. It seems redundant. And if you questioned my phrasing, then it's fair for me to ask that you clarify as well what you meant by "containment". Received on Fri Feb 24 2006 - 01:02:37 CET