Entity and Identity

#**121**

Roy Hann wrote:

Quote:

You've got me rolling in the aisle here. This is vintage stuff!
Excellent. Are you here all week?

Do you always laugh at the words of a theory you aren't familiar with?
If so, you're in company with those who laughed at the Wright Bros.

If you prefer to see code, check it out on http://github.com/cjheath

If neither theory nor practice floats your boat, try http://disney.com
or just test the theory of gravity by stepping off something tall.

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

#**122**

Bob Badour wrote:

Quote:

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, http://dataconstellation.com
Agile Information Management and Design

#**123**

Clifford Heath wrote:

Quote:

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.

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?

Quote:

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.

Quote:

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.

#**124**

Bob Badour wrote:

Quote:

Clifford Heath wrote:
Bob Badour wrote:
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.
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?

It's not exactly the same thing. It's a thing that contains, is built on,
a deeply nested relation, but it doesn't just refer to the static content,
but to the object-based representation and programming API, and the way
those objects work in the face of perhaps not all the attributes of each
object having been included in the query. It's a little hard to explain,
and though I've demonstrated it, I haven't yet published a screencast.

Suffice to say, I find it works rather well for conveniently combining
objects with relations, even though those objects aren't quite traditional.
I think it could help the industry write better applications by making
better use of the RM, without abandoning the convenience of objects.

Why are you so antagonistic to that goal?

Quote:

Would you care to comment on the substance of my posts, instead of the
terminology?
So far, terminology is the substance of your posts.

That's false, and you know it. I've made a number of factual claims,
together with pointers to the information that backs them up, but you
haven't bothered yourself to even look at them. Otherwise you'd be
asking different questions than simply "Why?".

But before I pursue that... in regard to terminology... fact orientation
is built on FOL, not on set theory. By itself, that isomorphism means
there is going to be parallel terminology. Would you ask mathematicians
to only use set theory, or only use FOL, without ever having recourse
to the other? Is either truly superfluous?

People understand facts much more readily than they understand relations.
Facts verbalise better, and emerge from the analysis of verbalisations.
If a change in terminology can help establish correct use of RM, what's
not to like about that?

Quote:

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.

Ok, help me. You challenged me over not having made factual claims.
One factual claim I made is that CQL handles join constraints more fully
than any previous technology. This capability is also key to its use as
a query language. Before I spend time substantiating that claim, how's
about you tell me which ORM graphical constraint types already include
(or can include) implicit joins? If you can, I'll continue my defense.
If you don't, I'll assume you're just ignorant.

But I expect you'll just splutter some emotive irrelevant crap instead,
or duck the question to avoid having to actually doing some research.

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Entity and Identity

comp.databases.theory comp.databases.theory

Re: Entity and Identity - 09-29-2009 , 03:30 PM

Re: Entity and Identity - 09-29-2009 , 03:30 PM

Re: Entity and Identity - 09-29-2009 , 05:45 PM

Re: Entity and Identity - 09-30-2009 , 01:22 AM