Re: Clean Object Class Design -- What is it?

>A set is a collection of "things" that are guaranteed to be unique.

As is a relation.

>A bag is a collection of "things" that are not guaranteed to be unique

If they are not unique, how does one logically distinguish among the duplicates? If one adds some means of logical identification, a relation results.

>An array is an ordered collection of things.

Implicitly ordered or explicitly ordered? A relation is explicitly ordered by any combination of columns with a well-defined sequence.

>A map is an associative container of keys and things where keys are
>guaranteed to be unique

A relation associates the values in any combination of columns with the values in the remaining columns (or vice versa). A map gives up symmetry without any compensating benefit.

>A multi-map is an associative container of keys and things where keys are
>not guaranteed to be unique.

A relation associates the values in any combination of columns with the values in the remaining columns regardless whether the association is unique for the combination of columns.

>These are different concepts. OK?

Not that I can see.

>> single inherent ordering of entities. The problem space does not have
>> essential performance requirements -- the solution space does.
>
>Yours may not. Mine does. Be careful of the "God complex" where
>what-I-know-is-all-there-is.

You are right, of course. Real-time systems have event frequencies etc. that are part of the problem domain.

>> "Report A must order employees by tenure."
>> "Report B must order employees alphabetically by last name, then first
 name,
>> then middle initial."
>> "Report C must order employees by decreasing salary."
>
>So? I find report generation a toy and singularly uninteresting problem. I
>wouldn't use an ODBMS for that either, most likely.

Replace report with Application. How does it change original point?

>> >But "bag" and "set" do not map directly to
>> >"relation".
>>
>> Sure they do. How not?
>
>Because they represent different concepts. You can't have it both ways.

Sure, I can. Relation represents the same concepts as bag and set. It also represents the same concepts as associative array and array.

>> >You must add constraints on your relation and awkward arbitrary
>> >key values
>>
>> You must have some logical means of identifying your data. This is an
>> attribute of the problem space. If you cannot identify a thing, you
 cannot
>> even begin to talk about it. I fail to see what is awkward about this.
>
>In order to normalize data, it is necessary to split repeated values into
>separate tables. Although the modelling of the data just recognizes the
>aggregation of the parts by the whole, you must create key values to put
>into your tables so that you can re-constitute the parts and the whole
>together.

Why not use a relation valued attribute? My point still stands that one needs some logical means of identifying the data.

>> >And if you are dead set on not learning new concepts then why are you
 even
>> >using a computer?
>>
>> I am not the one who is dead set on learning new concepts. I am not even
>> opposed to applying new names to old concepts; although, you have accused
 me
>> of such.
>
>You don't want to learn set, bag, array. How else should I take it?

As a programmer, I understand set, bag and array quite well. I also understand how the simple interface a relation exposes encompasses all of them. Why should a user who is not a programmer have to learn all of them?

>> >Fine. These views are created because someone (you?) programmed them.
>>
>> Because someone declared them. No programming (in the sense that most of
 our
>> audience understands it, at least) is required.
>
>Then your understanding is way too limited. They were "declared" in a
>language. Transforming a human derived model to computer executable
>instructions is programming. Just as people program Excel spreadsheets and
>Word macros.

Actually, I call the transformation compiling not programming. If algebra is a language and writing down an algebraic expression is programming, then I guess in your world a declaration is a program.

>> >Of course, if the data model was
>> >not constructed to support all these views in the first place (e.g.,
>> >"department" as a column of "employee" rather than an assignment table
 that
>> >links employee to department by date), then you will have to do a bit
 more
>> >work. So would I. So where's the beef?
>>
>> The relational model allows the latter design as well. They content of
 the
>> views would change slightly, but I would not consider it "more" work.
>
>You expect to be paid for it, don't you?

I wouldn't expect to be paid more for it than for the first design.

>> >I disagree with your assertion that OODBs add needless complexity.
>>
>> Your disagreement doesn't change the fact that non-relational OODBs add
>> needless complexity.
>
>And your opinion is not equivalent to fact.

I have already explained ad nauseum how non-relational OODBs add complexity. Every time the DB adds a new interface that is equivalent to a relation or is a subset of a relation, it must add new operators, it must expand the optimizer, etc. etc. etc. In the end, adding array, set, bag, hash etc. adds complexity without any compensating benefit and causes considerable harm.

>> >> >> Why does everyone want to throw away the logical model just because
 vendors
>> >> >> have failed to deliver on the physical side? Changing the logical
 model
 will
>> >> >> only make things worse.
>> >> >
>> >> >My favorite quote is attributed as Coggins' Law of Software
 Engineering:
>> >> >"Elegance must give way to pragmatics because Nature cannot be
 impressed."
>> >>
>> >> Unfortunately, the quotation does not address any of my questions.
>> >
>> >Certainly it does. People abandon purity to achieve success.
>>
>> No, it does not. It explains why people will accept the deficiencies of
>> incomplete database products. It does not explain why many people
 actively
>> want to throw away the logical model, the relational data model. This has
>> nothing to do with what Nature has given but what these individuals
 demand
>> of Nature.
>
>I've finally figured out that you have been arguing about purely
 theoretical
>databases (while criticizing real object databases). Since you've admitted
>elsewhere that no major vendor can implement the concepts you are clinging
>dearly to

I have never made any such comment. Please do not put words in my mouth. I am quite capable of doing that myself.

I go back to my original point: Why does everyone want to throw away the logical model just because vendors have failed to deliver on the physical side? Changing the logical model will only make things worse.

>> >Is it POSSIBLE that there is AT LEAST ONE application for which an
 object
>> >database is a superior tool than a relational one?
>>
>> Since a relational database is an object database, your question cannot
 be
 a
>> matter of the "object-ness" of the database. Presumably, you mean a
>> non-relational object database. To answer this, I will need to know in
 what
>> ways you think the non-relational database should differ from a
 relational
>> database.
>
>That's odd. I wonder why people like Oracle and Informix have to provide
>substantial object-relational mapping tools to accomplish the feat you say
>is inherent.

That's simple: They failed to provide any support for domains.

>> >If you answered "no" to the above question, then either you are
 omniscient
>> >and therefore God, or you are making a religious assertion based on
>> >incomplete information. If you answered "yes", then I can live with most
 of
>> >what you've said.
>>
>>
>> And if I gave neither of those answers?
>
>And if I don't answer your question either?

Then, lacking sufficient information, I cannot give you a yes or no answer. Would you care to explain how your idea of a non-relational OODB differs from a relational one for the purposes of the question you posed? If not, why did you bother posing it in the first place? Received on Sat Jul 14 2001 - 07:01:03 CEST