Re: Entity and Identity
Date: Tue, 29 Sep 2009 09:53:59 -0300
Message-ID: <4ac2036a$0$23755$9a566e8b_at_news.aliant.net>
Clifford Heath 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 implementation
> 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 >> elements?
>
>
> 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, it's
> trivial to represent ordered lists in RM, but SQL and the programming APIs
> 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? Received on Tue Sep 29 2009 - 14:53:59 CEST