Re: Database design
Date: Sat, 25 Feb 2006 00:00:23 +0100
Message-ID: <43ff8fbe$0$11062$e4fe514c_at_news.xs4all.nl>
Mark Johnson wrote:
> mAsterdam 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?
Codd used the word "table". I knew that.
>>"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.
Codd used the word "table". I knew that.
>>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.
Yes. Copying things, and copying parts of things is possible.
> 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.
In a general sense, yes. Something like this: Structure supports substance. Structures tend to get less flexible over time. As such they become an obstacle for change over time: by changing a structure you risk what it is supporting.
> 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.
I don't know if a hierarchy is inherently more or less flexible/stable than a mesh.
>>>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.
No doubts in your mind. I'll pass.
> 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.
What makes you think that I think this doesn't happen? ("/But/ it's done all the time.")
> 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".
Hierarchies denoting part-whole associations. Received on Sat Feb 25 2006 - 00:00:23 CET