Re: Entity and Identity

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.

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.

-- 
Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design