Re: Entity and Identity
Date: Tue, 29 Sep 2009 19:45:48 -0300
Clifford Heath wrote:
> Bob Badour wrote: >
>> Clifford Heath wrote:
>>> Bob Badour wrote:
>>>>> * Value types (also known as lexical types). Because instances of
>>>>> value types are identified by a lexical (written) form, the CQL
>>>>> syntax encodes that, for example, "Name is written as String(20);"
>>>>> * Entity types (non-lexical types) of three forms:
>>>>> * Subtypes, defined as for example "Employee is a kind of Person".
>>>>> Here the identification is inherited from the first supertype.
>>>> Sounds like the 1st Great Blunder to me. Why do you not have
>>>> subtypes for value types? Subtyping is far more useful for value
>>>> types than for structures.
>>> I do. In the above example, Name is a subtype of String. All value
>>> types are either subtypes, or base types supported by some
>>> framework. I don't support multiple inheritance for value types, and a
>>> value type cannot be derived from an entity tpe and vice versa.
>>>> How is it truly relational with all these superfluous structural
>>> These elements support the linguistic content from which the relational
>>> model emerges. They're what makes it possible to communicate logical
>>> constructs to those not trained in logic. They're also not my invention,
>>> they're core ORM2 concepts.
>>> The relational model is a solid basis, like the Von Neumann architecture
>>> or the Turing machine is for computation, but implementations can still
>>> add layers of convenience without breaking the paradigm. For example,
>>> trivial to represent ordered lists in RM, but SQL and the programming
>>> don't provide the syntactic sugar that makes it easy; so you get people
>>> like Dawn W espousing Pick because it does... and O-O people bagging the
>>> RM for being too hard to work with. If we add the convenience layers
>>> without losing the RM, the conflict can be resolved.
>>> For another example, consider fetching an order in an order processing
>>> system, to display it on-screen. The query is "get order 273". I need
>>> to fetch the order, the customer, the contact person, the salesperson,
>>> the order lines, the description for each SKU, maybe the shipping and
>>> supply status. There's a dozen relations before I can draw my screen,
>>> and they should all be fetchable with a single query, and preferably not
>>> as a single join; you'd like the query results to be represented in the
>>> conceptual form. That result set is what a constellation is, and that
>>> is what CQL's queries achieve. Yeah, it's a buzzword, but it reflects a
>>> concrete facility that's not present in existing relational tools, for
>>> no good reason.
>> Why won't relation valued attributes achieve what you want? Why invent
>> some new name?
> > They would - for those that know what they are. I'm addressing more > than just the DB research community here though.
Not here, you're not. (Well, you do seem wont to engage the resident cranks, but most groups don't count those.) You might actually achieve some communication if you adopt the pre-existing terminology.
Inventing new words to mean exactly the same as some existing term does nothing to help anyone. Do you go around renaming addition and division?
> Would you care to comment on the substance of my posts, instead of the > terminology?
So far, terminology is the substance of your posts. I am left with the big question: Why?
Why would you invent some new formalism based on an existing formalism that already has superfluous structural elements and then cite Simsion, who observes that most designers design using plain ol' relations -- albeit often using crow's feet as a graphical crutch.
> On the one hand, you seem to be familiar with and respect Nijssen and > Halpin's work and on the other, profoundly ignorant. Which is it?
Let me know when you figure it out. Received on Tue Sep 29 2009 - 17:45:48 CDT