Re: Entity and Identity

From: Clifford Heath <>
Date: Wed, 30 Sep 2009 06:30:58 +1000
Message-ID: <78uwm.147188$nL7.89058_at_newsfe18.iad>

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 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?

They would - for those that know what they are. I'm addressing more than just the DB research community here though.

Would you care to comment on the substance of my posts, instead of the terminology?

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?

Clifford Heath, Data Constellation,
Agile Information Management and Design
Received on Tue Sep 29 2009 - 22:30:58 CEST

Original text of this message