Has E/R had a negative impact on db?
JOG
I don't like entities. In fact I despise entities, as the enemy of good
information philosophy. You see I just don't accept their existence.
There is no magical wrapper surrounding some construct that turns it
into a nicely formed 'thing' or 'object'. Sure, we can invent them, but
there is never any inherent truth to their boundaries. Now in the
constraints of a piece of my OO code, which is only going to be used by
other parts of my code, and whose domain I have total control over this
is not a problem. But everywhere else in information modelling it is,
as it encourages one to view those boundaries as non-decomposable.
To me the situation get worse when one then adds relationships between
entities. What on earth is the difference between an entity (an
association of attributes) and a relationship (an association of
entities), except for the fact that a relationship is constrained to
being binary. Nothing. In fact all they are, are special cases of n-ary
relationships, or 'associative entities'. Everything we want to model
is ultimately an associative entity, or better put everything we want
to model is an n-ary _relationship_.
Now Codd grokked this. I am sure he did. That's why the RM has no
'links' and pivots on the information principle. Chen did not -
remember his E/R model was originally intended to be a direct
competitor to RM, not just a tool for conceptual modeling.
Okay, so for those in the know this isn't an issue and E/R is a useful
tool. But for those not in the know (which appears to be a lot of the
industry) it promotes the fallacy of the Entity/Relationship
distinction, of impenetrable wrappers, and encourages the mindset that
has lead to OODBMS, XML databases, etc.
So I put to you that Chen's E/R has had a greater deleterious influence
to fashion in db theory than any other paper in the last 30 years.
Jon Heggland
> I don't like entities. In fact I despise entities, as the enemy of good
>
> Okay, so for those in the know this isn't an issue and E/R is a useful
> tool. But for those not in the know (which appears to be a lot of the
> industry) it promotes the fallacy of the Entity/Relationship
> distinction, of impenetrable wrappers, and encourages the mindset that
> has lead to OODBMS, XML databases, etc.
Agreed. ORM is much better in this regard. It was a major revelation to
me to think in terms of *facts* instead of entities.
--
Jon
SD
discover the problem domain. Does a business analyst understand E/R?
ORM was a revelation to me, but sadly it appears to be dying because
tech heads like to think they are god and keep "knowledge" to themselves.
SD
Bob Badour
> On 4/20/2006 9:12 AM, Jon Heggland wrote:
>
>> JOG wrote:
>>
>>> I don't like entities. In fact I despise entities, as the enemy of good
>>> information philosophy. [...]
>>>
>>> Okay, so for those in the know this isn't an issue and E/R is a useful
>>> tool. But for those not in the know (which appears to be a lot of the
>>> industry) it promotes the fallacy of the Entity/Relationship
>>> distinction, of impenetrable wrappers, and encourages the mindset that
>>> has lead to OODBMS, XML databases, etc.
>>
>>
>> Agreed. ORM is much better in this regard. It was a major revelation to
>> me to think in terms of *facts* instead of entities.
>
> E/R is too close to the logical model (in RDBMS) to richly describe and
> discover the problem domain.
Huh? An entity in E/R corresponds to a relation in an RDBMS. A
relationship in E/R corresponds to a relation in an RDBMS.
Two things in E/R = one thing in RDBMS, and this makes it "too close" ?
> Does a business analyst understand E/R?
What a business analyst understands depends very much on the business
analyst.
> ORM was a revelation to me, but sadly it appears to be dying because
> tech heads like to think they are god and keep "knowledge" to themselves.
I suspect knowledge greed is more of a cultural thing. I have known more
than a few techies who were very generous with knowledge, and I have
known more than a few decidedly non-techie people who hoarded
information for personal advantage.
In my mind, the achilles heel of techies involves a drive to invent new
tools (and new uses for the tools they have) instead of learning the
principles by which to identify the right tool. In other words, what
they know is more important than what others can teach them.
On a Myers-Briggs scale, I suspect the overwhelming majority of techies
would share three of the four characteristics. In regular expression
form, the Myer-Briggs for techies would look like: I(N|S)TP
JOG
I'm not sure what you mean when you say 'E/R is too close to the
logical model (in RDBMS)'. In fact I'd say the exact opposite, I feel
that it is too far away.
In RM everything is stored as a relationship (mathematical relation
plus a header), and as such it pretty much denies the concept of
entities, period. If more people thought like this, whether they use RM
or not, we'd have far better multi-user persistence of data. In
contrast E/R encourages its user's to think in terms of objects and
links, and these artifices seem incredibly detrimental to me.
Alfredo Novoa
I sympathize with your thought. The only thing we can save from E/R are
some diagraming conventions to use with conceptual models. Something
very far from Chen's ambitions.
On the other hand it helped to cause a lot of confusion. When I was
studiyng database theory in the university I had to "learn" many weird
things about E/R. For instance we were forced to start a database
design with an E/R diagram and to use a transformation technique which
often leaded to redundant designs.
Regards
Alfredo
Neo
information philosophy.
What is your definition of an entity? What steps would one go through
to verify something is an entity?
JOG
I refer to them as they are specified by Chen. I've already pointed out
I believe their specification is impossible above simply being
arbitrary so your second question makes no sense to me.
Neo
Ok, I just wanted to make sure there isn't anything in RM that would be
considered an entity.
Jay Dee
There is nothing in the RM called "entity."
There is nothing in the RM called "relationship."
Bob Badour
Technically, the latter statement is untrue. Codd distinguishes
relations and relationships in his early papers, but most folks don't
any longer. Similarly, Date and Darwen have dropped the term 'domain' in
favour of 'type', which decision certainly eliminates a lot of explaining.
Regardless, Neo is incapable of understanding any of it.
David Cressey
"Neo" <neo5...@hotmail.com> wrote in message
news:1145756315....@u72g2000cwu.googlegroups.com...
> > Just a thought. I don't like entities. In fact I despise entities, as
the enemy of good
> information philosophy.
>
> What is your definition of an entity?
What is your definition of a nonentity?
David Cressey
"JOG" <j...@cs.nott.ac.uk> wrote in message
news:1145759385.7...@t31g2000cwb.googlegroups.com...
I honestly believe that this long discussion has lost sight of the idea that
the E/R model is an analysis model, and not a design model. Arbitrary
choices made during the analysis phase can be useful, in order to come up
with a conceptual model that is easily communicated from one person to
another. That's the main usefulness of an E/R model, IMO. If the E/R model
were a design model, then arbitrary choices would be far more costly.
Arbitrary choices during the design phase can (will) come back to bite you
if those choices were only arbitrary in your mind, and not in terms of the
downstream consequences of the design choice.
Many of the complaints made against undereducated database designers can be
grouped into the following class of complaints: the undereducated will
often think that a design choice is arbitrary when a more educated person
will be able to see different consequences in the various alternatives.
Bob Badour
> "JOG" <j...@cs.nott.ac.uk> wrote in message
> news:1145759385.7...@t31g2000cwb.googlegroups.com...
>
>>Neo wrote:
>>
>>>>Just a thought. I don't like entities. In fact I despise entities, as
>
> the enemy of good
>
>>>information philosophy.
>>>
>>>What is your definition of an entity? What steps would one go through
>>>to verify something is an entity?
>>
>>I refer to them as they are specified by Chen. I've already pointed out
>>I believe their specification is impossible above simply being
>>arbitrary so your second question makes no sense to me.
>
> I honestly believe that this long discussion has lost sight of the idea that
> the E/R model is an analysis model, and not a design model. Arbitrary
> choices made during the analysis phase can be useful, in order to come up
> with a conceptual model that is easily communicated from one person to
> another. That's the main usefulness of an E/R model, IMO. If the E/R model
> were a design model, then arbitrary choices would be far more costly.
Perhaps, our experiences differ. I have found the NIAM/ORM methods of
constructing english sentences to describe the concepts more useful for
communicating with domain experts.
Programmers like pretty pictures, but users' and business experts' eyes
glaze over. This usually precedes: "That's good. When will the software
be ready?" ;)
Bob Badour
I know you were asking someone else. But I couldn't resist sharing that
my definition is "Neo".
David Cressey
"Bob Badour" <bba...@pei.sympatico.ca> wrote in message
news:V1L2g.64571$VV4.1...@ursa-nb00s0.nbnet.nb.ca...
> David Cressey wrote:
[snip]
> > I honestly believe that this long discussion has lost sight of the idea
that
> > the E/R model is an analysis model, and not a design model. Arbitrary
> > choices made during the analysis phase can be useful, in order to come
up
> > with a conceptual model that is easily communicated from one person to
> > another. That's the main usefulness of an E/R model, IMO. If the E/R
model
> > were a design model, then arbitrary choices would be far more costly.
>
> Perhaps, our experiences differ. I have found the NIAM/ORM methods of
> constructing english sentences to describe the concepts more useful for
> communicating with domain experts.
Perhaps. I don't have enough experience with NIAM/ORM to compare with E/R.
>
> Programmers like pretty pictures, but users' and business experts' eyes
> glaze over. This usually precedes: "That's good. When will the software
> be ready?" ;)
Our experiences differ here, as well. The users and business experts I've
dealt with like pretty pictures, provided they are few in number! On the
other hand, a large number of English sentences, bound together in something
like a "functional spec" make their eyes glaze over.
David Cressey
The fact that I was asking Neo was not an accident.
Bob Badour
> "Bob Badour" <bba...@pei.sympatico.ca> wrote in message
> news:V1L2g.64571$VV4.1...@ursa-nb00s0.nbnet.nb.ca...
>
>>David Cressey wrote:
>
> [snip]
>
>>>I honestly believe that this long discussion has lost sight of the idea
>
> that
>
>>>the E/R model is an analysis model, and not a design model. Arbitrary
>>>choices made during the analysis phase can be useful, in order to come
>
> up
>
>>>with a conceptual model that is easily communicated from one person to
>>>another. That's the main usefulness of an E/R model, IMO. If the E/R
>
> model
>
>>>were a design model, then arbitrary choices would be far more costly.
>>
>>Perhaps, our experiences differ. I have found the NIAM/ORM methods of
>>constructing english sentences to describe the concepts more useful for
>>communicating with domain experts.
>
> Perhaps. I don't have enough experience with NIAM/ORM to compare with E/R.
That's a pity. You aren't doing yourself any favours.
>>Programmers like pretty pictures, but users' and business experts' eyes
>>glaze over. This usually precedes: "That's good. When will the software
>>be ready?" ;)
>
> Our experiences differ here, as well. The users and business experts I've
> dealt with like pretty pictures, provided they are few in number!
But that's the problem. "Oooh, aaah! That's good. When will the software
be ready?" is not the same as: "No, this over here is wrong. It should
be..." or "I don't understand. What other possible alternative could
there be?!?"
If the goal is to get users to sign off on a design as soon as possible
regardless of the cost of inevitable failure, then I suppose pretty
pictures are the ideal solution. Are you a consultant by any chance?
Does "Big 5" feature predominantly on your resume?
Once again, I direct your attention to a gem of great wisdom from the
mind of EWD and others before him:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD696.html
In that vein, NIAM surpasses ORM. However, I believe the availability of
tools for ORM surpasses the availability of tools for NIAM, and ORM has
the desirable feature that one can still disregard the pictures and
communicate in english.
On the
> other hand, a large number of English sentences, bound together in something
> like a "functional spec" make their eyes glaze over.
I don't recall where I suggested such an absurdity. NIAM or ORM allows
one to present the domain expert a list of fairly simple sentences with
which the user can agree, disagree, or express confusion.
Since the list provides an exhaustive reflection of the past
communications between the analyst and the domain expert plus the
analyst's assumptions about same, the process quickly reveals errors in
perception and assumption, and alerts the analyst to areas requiring
further probing.
It can also trigger memories of special cases in the domain expert's
mind. Contradictions among domain experts generally lead to very
fruitful discussions.
J M Davitt
> Jay Dee wrote:
>
>> Neo wrote:
>>
>>>>>> Just a thought. I don't like entities. In fact I despise entities,
>>>>>> as the enemy of good information philosophy.
>>>>>
>>>>>
>>>>> What is your definition of an entity? What steps would one go through
>>>>> to verify something is an entity?
>>>>
>>>>
>>>> I refer to them as they are specified by Chen. I've already pointed out
>>>> I believe their specification is impossible above simply being
>>>> arbitrary so your second question makes no sense to me.
>>>
>>>
>>> Ok, I just wanted to make sure there isn't anything in RM that would be
>>> considered an entity.
>>
>>
>> There is nothing in the RM called "entity."
>> There is nothing in the RM called "relationship."
>
>
> Technically, the latter statement is untrue. Codd distinguishes
> relations and relationships in his early papers, but most folks don't
> any longer.
Technically, yes; but the relationship Codd described is nothing like
the relationships Chen (sort of) described.
Similarly, Date and Darwen have dropped the term 'domain' in
> favour of 'type', which decision certainly eliminates a lot of explaining.
In TTM3, they've stopped using familiar terms because they were familiar
terms; no longer does the prose seem to gently guide readers along the
path to enlightenment. (This, I think, is due mostly to Darwen's
style.)
-CELKO-
One problem is that a relationship in a ER diagram is a line between
boxes. That puts us in a binary-only world. ORM, on the other hand,
allows n-ary relationships. And the diagram has no other information
about the nature of the relationship, like ORM does.
The map becomes the territory. And when you look at query generating
tools based on ER diagrams, they tend "follow the lines", so to answer
a questlon like "Who was in the mail room the day we invoiced XYZ
company?" becomes a chain of joins instead of a match on two date
columns.
Jon Heggland
> Bob Badour wrote:
>> Similarly, Date and Darwen have dropped the term 'domain' in
>> favour of 'type', which decision certainly eliminates a lot of
>> explaining.
>
> In TTM3, they've stopped using familiar terms because they were familiar
> terms; no longer does the prose seem to gently guide readers along the
> path to enlightenment. (This, I think, is due mostly to Darwen's
> style.)
Do you consider the term "type" unfamiliar?
--
Jon
Jon Heggland
> One problem is that a relationship in a ER diagram is a line between
> boxes. That puts us in a binary-only world. ORM, on the other hand,
> allows n-ary relationships.
Are you talking about Chen's original ER? Because most ER variants I've
seen definitely allow n-ary relationships---and the relationship aren't
the lines, they're the diamonds.
> And the diagram has no other information
> about the nature of the relationship, like ORM does.
This also depends on the ER dialect.
--
Jon
David Cressey
"Jon Heggland" <jon.he...@idi.ntnu.no> wrote in message
news:e2hslc$sfq$1...@orkan.itea.ntnu.no...
> -CELKO- wrote:
> > One problem is that a relationship in a ER diagram is a line between
> > boxes. That puts us in a binary-only world. ORM, on the other hand,
> > allows n-ary relationships.
>
> Are you talking about Chen's original ER? Because most ER variants I've
> seen definitely allow n-ary relationships---and the relationship aren't
> the lines, they're the diamonds.
Agreed.
And another way to depict n-ary relationships in an ER model is called
"reification". That's just a fancy word for expressing
a relationship as if it were an entity. The reified relationships play the
role of diamonds in the above.
The UTexas outline of modeling suggests doing this for resolving
many-to-many binary relationships. They call it "association entities". I
don't doo what they suggest, but I have done it for n-ary relationships.
A second parallel question is whether attributes can be attached to both
entities and relationships, or whether they can only be attached to entites.
I've followed the first practice.
In my own mind, without developing any formal concept for it, I've had a
tendency to view entities as "unary relationships". I realize that's an
oxymoron, but it's intentional. This collapses two concepts, entity and
relationship, down to a single concept, relationship.
JOG
> "Jon Heggland" <jon.he...@idi.ntnu.no> wrote in message
> news:e2hslc$sfq$1...@orkan.itea.ntnu.no...
> > -CELKO- wrote:
> > > One problem is that a relationship in a ER diagram is a line between
> > > boxes. That puts us in a binary-only world. ORM, on the other hand,
> > > allows n-ary relationships.
> >
> > Are you talking about Chen's original ER? Because most ER variants I've
> > seen definitely allow n-ary relationships---and the relationship aren't
> > the lines, they're the diamonds.
>
> Agreed.
>
> And another way to depict n-ary relationships in an ER model is called
> "reification". That's just a fancy word for expressing
> a relationship as if it were an entity. The reified relationships play the
> role of diamonds in the above.
>
And what exactly defines a relationship as not being an entity in the
first place? This is a rhetorical question of course, as I cannot seem
to discern any boundaries. It appears to me that this is no more than
an arbitrary, and artificial, decision.
> The UTexas outline of modeling suggests doing this for resolving
> many-to-many binary relationships. They call it "association entities". I
> don't doo what they suggest, but I have done it for n-ary relationships.
>
> A second parallel question is whether attributes can be attached to both
> entities and relationships, or whether they can only be attached to entites.
> I've followed the first practice.
Bill Kent (a great loss imo) would have disagreed with the second line
of thought wholeheartedly. Relationships may always have attributes
themselves and indeed, if one views them as just links then it's a lot
tougher to change diagrams in the future when one discovers that they
do in fact have attributes that require modelling. Why then not just
think about them as n-ary relationships (or associative entities if
preferred) at all times?
>
> In my own mind, without developing any formal concept for it, I've had a
> tendency to view entities as "unary relationships". I realize that's an
> oxymoron, but it's intentional.
> This collapses two concepts, entity and relationship, down to a single concept, relationship.
I am unclear here David why one would want to view an entity as a unary
as opposed to an n-ary relationship. An 'entity' has numerous items in
it all playing a role in that association, just as a 'relationship' has.
Jan Hidders
JOG wrote:
> Just a thought.
Likewise. :-)
> I don't like entities. In fact I despise entities, as the enemy of good
> information philosophy. You see I just don't accept their existence.
Actually, I don't see what you could possibly mean with that, and to
the extent that I can guess a meaning I find that a rather baffling
statement. The usual definition of 'entity' in the context of data
modelling for database is something like "things that can be identified
and which we would like to store information about in the database". If
that's how I interpret your statement then you seem to be saying that
you don't believe there are such things, and since we cannot store
information about things we cannot identify, this leads inexorably to
the conclusion that you don't believe that we can store information
about anything interesting in a database.
Yes, I have just put words in your mouth, but you shouldn't have left a
hole there. :-) If you are going to rant about something you despise,
you better define it properly.
> There is no magical wrapper surrounding some construct that turns it
> into a nicely formed 'thing' or 'object'.
What makes you think a wrapper is needed?
> Sure, we can invent them, but
> there is never any inherent truth to their boundaries.
When making an ER / ORM / ... some ER dialect ... model one doesn't
identify boundaries, except perhaps when determining part-of
relationhips, so I have no idea what you are talking about here. Until
you further explain this it looks mainly like pseudophilosophical
nonsense to me.
> To me the situation get worse when one then adds relationships between
> entities. What on earth is the difference between an entity (an
> association of attributes) and a relationship (an association of
> entities), except for the fact that a relationship is constrained to
> being binary.
What makes you think a relationship is necessarily binary? And why do
you think it is a problem that the distinction between relationsips and
entities is not clear? Does it also bother you that the distinction
between a relation and a foreign-key relationship is not always clear?
Or between a unary relation and a domain?
> Nothing. In fact all they are, are special cases of n-ary
> relationships, or 'associative entities'.
No, that is clearly false. Not every entity is necessarily identified
by its associated attributes, identification could be more complex
and/or indirect than that.
> Now Codd grokked this. I am sure he did. That's why the RM has no
> 'links' and pivots on the information principle.
Codd is not on you side here. The surrogate identifiers qualify as
"links" and why, if he thought the term "entity" meaningless, did he
use it?
> Okay, so for those in the know this isn't an issue and E/R is a useful
> tool. But for those not in the know (which appears to be a lot of the
> industry) it promotes the fallacy of the Entity/Relationship
> distinction, of impenetrable wrappers, and encourages the mindset that
> has lead to OODBMS, XML databases, etc.
Gee, James, here I was thinking I was in the know and it turns out that
I couldn't disagree more, so apparently I'm not(!) I would argue that
it is exactly *because* ER dialects were ignored as a viable
alternative for a DBMS logical model, and consequently got swallowed up
and crushed in the OODBMS avalanche, that the field of database theory
has been held back. Serious study of object / entity identity would
have led to simpeler and more general models, and we would have had a
better understanding of schema evolution and temporal databases.
-- Jan Hidders
JOG
> JOG wrote:
> > Just a thought.
>
> Likewise. :-)
>
> > I don't like entities. In fact I despise entities, as the enemy of good
> > information philosophy. You see I just don't accept their existence.
>
> Actually, I don't see what you could possibly mean with that, and to
> the extent that I can guess a meaning I find that a rather baffling
> statement.
Agreed, in a scientific paper, I would be embarressed by such nonsense,
so take it with a pinch of salt - the prose is purple to engender
responses, however one wishes to interpret such a rant. The point I am
really making is that I see no satisfactory distinction between
entities and relationships, that I find this jarring, and that perhaps
making this split may not always be productive. Nonetheless, from this
thread I have discovered ORM and have been pretty impressed by it.
> The usual definition of 'entity' in the context of data
> modelling for database is something like "things that can be identified
> and which we would like to store information about in the database". If
> that's how I interpret your statement then you seem to be saying that
> you don't believe there are such things, and since we cannot store
> information about things we cannot identify, this leads inexorably to
> the conclusion that you don't believe that we can store information
> about anything interesting in a database.
Right, so your working definition is that entities are "things that can
be identified and which we would like to store information about in the
database". Relationships however are also things, they can be identifed
and we would like to store them - so the definition appears to be on a
sticky wicket.
>
> Yes, I have just put words in your mouth, but you shouldn't have left a
> hole there. :-)
Not a problem. I left the hole there, I expect it.
> If you are going to rant about something you despise,
> you better define it properly.
This is circuitous as what I am actually 'despising' is the fact that I
have trouble making that definition.
>
> > There is no magical wrapper surrounding some construct that turns it
> > into a nicely formed 'thing' or 'object'.
>
> What makes you think a wrapper is needed?
The use of the term 'entity' has seemed to me to be as a collection of
attributes or properties, wrapped up together. Objects equally are
wrappers in that they encapsulate whatever is inside. I may have missed
your point - I was just inferring that these groupings of attributes
are made in pragmatic fashion and that there is no right or wrong to
them.
>
> > Sure, we can invent them, but
> > there is never any inherent truth to their boundaries.
>
> When making an ER / ORM / ... some ER dialect ... model one doesn't
> identify boundaries, except perhaps when determining part-of
> relationhips, so I have no idea what you are talking about here. Until
> you further explain this it looks mainly like pseudophilosophical
> nonsense to me.
>
> > To me the situation get worse when one then adds relationships between
> > entities. What on earth is the difference between an entity (an
> > association of attributes) and a relationship (an association of
> > entities), except for the fact that a relationship is constrained to
> > being binary.
>
> What makes you think a relationship is necessarily binary? And why do
> you think it is a problem that the distinction between relationsips and
> entities is not clear?
Well, I offered the suggestion that this may have encouraged a
navigational viewpoint of data, between nodes connected by links.
> Does it also bother you that the distinction
> between a relation and a foreign-key relationship is not always clear?
> Or between a unary relation and a domain?
I'm not sure how these comparisons are relevent, but yes (although I
believe I am wrong to be bothered by it) and no. I am far more
concerened however with the fact that my hair is starting to grey.
>
> > Nothing. In fact all they are, are special cases of n-ary
> > relationships, or 'associative entities'.
>
> No, that is clearly false. Not every entity is necessarily identified
> by its associated attributes, identification could be more complex
> and/or indirect than that.
Well, clearly not clearly. Would liebniz equality not state that the
only thing that identifies an item is very much its atrributes? Given
an E/R relationship can always be restated as an associative entity I'd
appreciate if you could expand on this.
>
> > Now Codd grokked this. I am sure he did. That's why the RM has no
> > 'links' and pivots on the information principle.
>
> Codd is not on you side here. The surrogate identifiers qualify as
> "links" and why, if he thought the term "entity" meaningless, did he
> use it?
Well I am on no side (these are merely musings). AFAIK surrogate
identifiers were not supposed to be seen or manipulated by the user so
these 'links' were internal, so I'm not clear as to your objection
there.
Either way, the point I was making is that his model does not
distinguish relationships and entities. I'd believe this has proven to
be a good thing - but I get the feeling you think there may be an
alternative?
>
> > Okay, so for those in the know this isn't an issue and E/R is a useful
> > tool. But for those not in the know (which appears to be a lot of the
> > industry) it promotes the fallacy of the Entity/Relationship
> > distinction, of impenetrable wrappers, and encourages the mindset that
> > has lead to OODBMS, XML databases, etc.
>
> Gee, James, here I was thinking I was in the know and it turns out that
> I couldn't disagree more, so apparently I'm not(!).
No, outside of being perplexed by the time you've spent working with
XML databases, I'd say you were very much in the know. I value your
responses Jan.
> I would argue that
> it is exactly *because* ER dialects were ignored as a viable
> alternative for a DBMS logical model, and consequently got swallowed up
> and crushed in the OODBMS avalanche, that the field of database theory
> has been held back. Serious study of object / entity identity would
> have led to simpeler and more general models, and we would have had a
> better understanding of schema evolution and temporal databases.
That is equally interesting to me. To your knowledge has anyone ever
done such a study?
>
> -- Jan Hidders
All best, Jim.
Neo
> it is exactly *because* ER dialects were ignored as a viable
> alternative for a DBMS logical model, and consequently got swallowed up
> and crushed in the OODBMS avalanche, that the field of database theory
> has been held back.
Darn those OODBMS proponent! They haven't a clue.
> Serious study of object / entity identity would
> have led to simpler and more general models, and we would have had a
> better understanding of schema evolution and temporal databases.
There isn't a shread of evidence for such outrageous and ludicrous
statements.
JOG
[snip]
> There isn't a shread of evidence for such outrageous and ludicrous
> statements.
That you are aware of. Just because one is not informed about something
does not mean it doesn't exist.
Neo
> > > have led to simpler and more general models, and we would have had a
> > > better understanding of schema evolution and temporal databases.
> > There isn't a shread of evidence for such outrageous and ludicrous
> > statements.
No JOG, I have been reading the best of the best right here in c.d.t.
for half a decade and there is simply not a shread of evidence that
"Serious study of object / entity identity would have led to simpler
and more general models, and we would have had a better understanding
of schema evolution and temporal databases". If you have proof, please
present it.
JOG
Why would you require proof from me of someone else's comment.
Neo
> > > > > have led to simpler and more general models, and we would have had a
> > > > > better understanding of schema evolution and temporal databases.
> > > >
> > > > outrageous and ludicrous statements.
> > >
> > > JOG: That you are aware of. Just because one is not informed
> > > about something does not mean it doesn't exist.
> >
> > for half a decade and there is simply not a shread of evidence that
> > "Serious study of object / entity identity would have led to simpler
> > and more general models, and we would have had a better understanding
> > of schema evolution and temporal databases". If you have proof, please
> > present it.
>
Ideally, it should be provided by Jan first, since he made the
outrageous and ludicrous statement, but since it seems you are open to
the possibility of that outrageous and ludicrous statement, I thought
maybe you knew something or have run across someone claiming such
nonsense. If so, I would like to hear about it as it might provide at
least a shread of evidence. Have you run into any such kooks?
Jan Hidders
JOG wrote:
> Jan Hidders wrote:
> > JOG wrote:
> > > Just a thought.
> >
> > Likewise. :-)
> >
> > > I don't like entities. In fact I despise entities, as the enemy of good
> > > information philosophy. You see I just don't accept their existence.
> >
> > Actually, I don't see what you could possibly mean with that, and to
> > the extent that I can guess a meaning I find that a rather baffling
> > statement.
>
> Agreed, in a scientific paper, I would be embarressed by such nonsense,
> so take it with a pinch of salt - the prose is purple to engender
> responses, however one wishes to interpret such a rant.
Ok. Fair enough.
> The point I am
> really making is that I see no satisfactory distinction between
> entities and relationships, that I find this jarring, and that perhaps
> making this split may not always be productive. Nonetheless, from this
> thread I have discovered ORM and have been pretty impressed by it.
Indeed. One of the few ER dialects that took into account that
sometimes you would like to consider the same thing as both an entity
and a relationship.
> > The usual definition of 'entity' in the context of data
> > modelling for database is something like "things that can be identified
> > and which we would like to store information about in the database". If
> > that's how I interpret your statement then you seem to be saying that
> > you don't believe there are such things, and since we cannot store
> > information about things we cannot identify, this leads inexorably to
> > the conclusion that you don't believe that we can store information
> > about anything interesting in a database.
>
> Right, so your working definition is that entities are "things that can
> be identified and which we would like to store information about in the
> database". Relationships however are also things, they can be identifed
> and we would like to store them - so the definition appears to be on a
> sticky wicket.
Yes, relationships are a special kind of entity. Why do you think this
is problematic? I would argue that this is not a deep problem in ER
modelling and can be fixed. ORM, for example, does that to some extent.
> > > There is no magical wrapper surrounding some construct that turns it
> > > into a nicely formed 'thing' or 'object'.
> >
> > What makes you think a wrapper is needed?
>
> The use of the term 'entity' has seemed to me to be as a collection of
> attributes or properties, wrapped up together. Objects equally are
> wrappers in that they encapsulate whatever is inside. I may have missed
> your point - I was just inferring that these groupings of attributes
> are made in pragmatic fashion and that there is no right or wrong to
> them.
Encapsulation is a nonsensical concept in the context of data
modelling. It looks a bit as if the problem is more that you are
retro-fitting terminology from the world of object-oriented programming
into the world of datamodelling that has no place there. ;-) More to
the point: it's certainly not an inherent part of modelling with ER
dialects.
> > What makes you think a relationship is necessarily binary? And why do
> > you think it is a problem that the distinction between relationsips and
> > entities is not clear?
>
> Well, I offered the suggestion that this may have encouraged a
> navigational viewpoint of data, between nodes connected by links.
Binary relationships encourage just as much a navigational viewpoint as
foreign keys do. And even if they did and the query language would
encourage you to specify queries in a navigational way then this
becomes only problematic if the query engine is going to execute
navigationally specified queries in a navigational way.
> > > Nothing. In fact all they are, are special cases of n-ary
> > > relationships, or 'associative entities'.
> >
> > No, that is clearly false. Not every entity is necessarily identified
> > by its associated attributes, identification could be more complex
> > and/or indirect than that.
>
> Well, clearly not clearly. Would liebniz equality not state that the
> only thing that identifies an item is very much its atrributes?
You mean Leibniz' substitution principle?:
Two things X and Y are equal iff in all true propositions containing X
we can substitute Y for X and again obtain a true propsition and vice
versa.
That would only imply what you think it implies if only attributes
where stored, and not relationships.
> Given
> an E/R relationship can always be restated as an associative entity I'd
> appreciate if you could expand on this.
Consider weak entities, say the weak entity "Dog" with attribute "name"
that depends via the "is-owned-by" relationship upon the entity "Owner"
with attributes "name" and "address". To identify a dog you not only
need its name (which is probably not globally unique) but also the name
and address of its owner.
> > Serious study of object / entity identity would
> > have led to simpeler and more general models, and we would have had a
> > better understanding of schema evolution and temporal databases.
>
> That is equally interesting to me. To your knowledge has anyone ever
> done such a study?
I know of some work done in the context of ORM by Erik Proper in his
PhD thesis: H.A. (Erik) Proper. A Theory for Conceptual Modelling of
Evolving Application Domains. University of Nijmegen, Nijmegen, The
Netherlands, EU, 1994, ISBN 909006849X.
Erik worked closely with Arthur ter Hofstede on the formalization of
ORM. This doesn't make light reading, but it might give an idea of what
I'm talking about.
-- Jan Hidders
David Cressey
> Jan Hidders wrote:
> > JOG wrote:
> > > Just a thought.
> >
> > Likewise. :-)
> >
> > > I don't like entities. In fact I despise entities, as the enemy of
good
> > > information philosophy. You see I just don't accept their existence.
> >
> > Actually, I don't see what you could possibly mean with that, and to
> > the extent that I can guess a meaning I find that a rather baffling
> > statement.
>
> Agreed, in a scientific paper, I would be embarressed by such nonsense,
> so take it with a pinch of salt - the prose is purple to engender
> responses, however one wishes to interpret such a rant. The point I am
> really making is that I see no satisfactory distinction between
> entities and relationships, that I find this jarring, and that perhaps
> making this split may not always be productive. Nonetheless, from this
> thread I have discovered ORM and have been pretty impressed by it.
>
OK, since you are seeking responses on the outer fringe, I'll give one.
Look into the Hindu concept of Maya.
There's a short article in the wikipedia.
http://en.wikipedia.org/wiki/Maya_%28Hinduism%29
As near as I understand it, the idea is that the division of the universe
of discourse into entities is at best subjective and, at worst, illusion.
Is this anything along the lines of what you were pursuing?
Along the same lines, I too have had a philosophical problem with the
distinction between "entities" and "relationships". What I'm toying with
now is this: a binary relation ship is of order 2, a ternary is of order 3,
etc. So what is a relationship of order 1? Well, gee whiz, it sure looks
like an entity to me... If this sounds like hd waving, well it is. And
I'm just toying with the idea right now. It isn't something I'd advance in
a serious modeling discussion.
mAsterdam
[snip]
> Encapsulation is a nonsensical concept in the context of data
> modelling.
Yes. Yet, it is a very useful concept in partitioning software.
It takes some time for software developers to take off that hat
and get into the data-centric mindset needed to grow a proper
data-model - that is /if/ they manage to do that. Some can't, and
rely on hibernate or other Object-Relational-Mapping tools
(unfortunately also abbreviated as ORM, @#&$#!) to create
throw-away software.
dawn
> Jan Hidders wrote:
> [snip]
>
> > Encapsulation is a nonsensical concept in the context of data
> > modelling.
>
> Yes. Yet, it is a very useful concept in partitioning software.
> It takes some time for software developers to take off that hat
> and get into the data-centric mindset needed to grow a proper
> data-model - that is /if/ they manage to do that.
Agreed. Since there is no reason to persist the same functions/methods
repeatedly by keeping data and functions together all the way through
CRUD functions, there is a point where these need to be decoupled. The
functions defined for a given object are metadata (functions defined
for a domain).
Since we often define the same metadata / functions in apps and dbms's,
we will continue to have those who specify the functions from "each
side" think their functions are the ones that need to stay packaged
with the data, with no obvious way to get the db specs into the code or
the OO methods into the dbms metadata.
> Some can't, and
> rely on hibernate or other Object-Relational-Mapping tools
> (unfortunately also abbreviated as ORM,
yes, that has confused me more than once
> @#&$#!)
don't forget -- I can read some Dutch
> to create
> throw-away software.
>
> > It looks a bit as if the problem is more that you are
> > retro-fitting terminology from the world of object-oriented programming
> > into the world of datamodelling that has no place there. ;-)
But you do have operations defined on domains in the dbms schema and
these are tied to attributes. So, we might use other terminology when
discussing the dbms, but there is some similarity, with the OO side of
the house often providing more precision in the validations (in
setters) and more of the functions specific to this domain (dbms
domains are often specified as varchar with more detailed validations
in the code to verify that a string is a valid e-mail address, for
example).
> >More to
> > the point: it's certainly not an inherent part of modelling with ER
> > dialects.
Typing is, however. Cheers! --dawn
paul c
> JOG wrote:
>
>>Jan Hidders wrote:
>>
>>>JOG wrote:
>
>>>The usual definition of 'entity' in the context of data
>>>modelling for database is something like "things that can be identified
>>>and which we would like to store information about in the database". If
>>>that's how I interpret your statement then you seem to be saying that
>>>you don't believe there are such things, and since we cannot store
>>>information about things we cannot identify, this leads inexorably to
>>>the conclusion that you don't believe that we can store information
>>>about anything interesting in a database.
>>
>>Right, so your working definition is that entities are "things that can
>>be identified and which we would like to store information about in the
>>database". Relationships however are also things, they can be identifed
>>and we would like to store them - so the definition appears to be on a
>>sticky wicket.
>
>
> Yes, relationships are a special kind of entity. Why do you think this
It may not be a problem in abstract philosophy but it seems a problem to
me when one is trying to metaphorically describe things or make an
analogy on a computer, where the advantage seems to come from initial
reduction, not expansion. Shouldn't the opportune comparison be that an
entity (if one thinks entities are needed for conversation) is a special
case of a relationship?
p
mAsterdam
> mAsterdam wrote:
>
>>Jan Hidders wrote:
>>[snip]
>>
>>>Encapsulation is a nonsensical concept in the context of data
>>>modelling.
>>
>>Yes. Yet, it is a very useful concept in partitioning software.
>>It takes some time for software developers to take off that hat
>>and get into the data-centric mindset needed to grow a proper
>>data-model - that is /if/ they manage to do that.
>
>
> Agreed.
> Since there is no reason to persist the same functions/methods
> repeatedly by keeping data and functions together all the way through
> CRUD functions, there is a point where these need to be decoupled.
What do you mean with "to persist ... functions" or to "to persist ...
methods"?
I think the OO perspective makes one look for
ways to persist /objects/ - which are supposed to
encapsulate data. This is exactly the idea that should
be dropped when designing the database because
"Encapsulation is a nonsensical concept in the
context of data modelling". There is no us vs them
here. Designing a database is just a different task
than partitioning a piece of software.
> The
> functions defined for a given object are metadata (functions defined
> for a domain).
Only where there is code-data equivalence (e.g. prolog, or the output of
compilers) this is true. In the rest of the world it is code.
> Since we often define the same metadata / functions in apps and dbms's,
Putting them on two sides of a slash does not make them the same.
Do you have an example of these "metadata/functions" as data?
> we will continue to have those who specify the functions from "each
> side" think their functions are the ones that need to stay packaged
> with the data, with no obvious way to get the db specs into the code or
> the OO methods into the dbms metadata.
>
>
>>Some can't, and
>>rely on hibernate or other Object-Relational-Mapping tools
>>(unfortunately also abbreviated as ORM,
>
>
> yes, that has confused me more than once
>
>
>>@#&$#!)
>
>
> don't forget -- I can read some Dutch
:-)
>>to create
>>throw-away software.
>>
>>
>>>It looks a bit as if the problem is more that you are
>>>retro-fitting terminology from the world of object-oriented programming
>>>into the world of datamodelling that has no place there. ;-)
>
>
> But you do have operations defined on domains in the dbms schema and
> these are tied to attributes. So, we might use other terminology when
> discussing the dbms, but there is some similarity, with the OO side of
> the house often providing more precision in the validations (in
> setters) and more of the functions specific to this domain (dbms
> domains are often specified as varchar with more detailed validations
> in the code to verify that a string is a valid e-mail address, for
> example).
It's other goals and concerns, not just terminology.
(BTW I really don't like this idea: "the OO side of the house" vs the
other side).
J M Davitt
Good point; no, of course not. My meaning was not clear.
Date, it seems, has tried to use terms that already had currency
but gave them careful and precise definitions which did not
differ drastically from their generally-understood meaning. The
subtle distinctions were lost on many readers. (His definitions of
some terms, however, were very different, and he seemed to make the
effort to emphasize those differences.) In his later writings, I
sense much less tenancy to continue doing so.
Jan Hidders
Neo wrote:
> Jan Hidders wrote:
> > I would argue that
> > it is exactly *because* ER dialects were ignored as a viable
> > alternative for a DBMS logical model, and consequently got swallowed up
> > and crushed in the OODBMS avalanche, that the field of database theory
> > has been held back.
>
> Darn those OODBMS proponent! They haven't a clue.
Depending on your definition of OODBMS you may just have accused me of
being clueless. Was that your intention?
-- Jan Hidders
PS. I did not give you permission to quote me without proper
attribution, so either attribute properly or don't quote.
Neo
> > > it is exactly *because* ER dialects were ignored as a viable
> > > alternative for a DBMS logical model, and consequently got swallowed up
> > > and crushed in the OODBMS avalanche, that the field of database theory
> > > has been held back.
> >
> > Darn those OODBMS proponent! They haven't a clue.
>
> Depending on your definition of OODBMS you may just have accused me of
> being clueless. Was that your intention?
My intention was to bash any person who shows any type of preference,
leaning, acceptance, amicable feelings, sympathy, etc to any db that is
or appears to be object-oriented in the remotest sense; regardless of
what that oodb actually does or how it does or why it does it. These
people haven't a clue because they are raising strawman issues that
simply do not exist or couldn't be addressed by proper
understanding/application of RM which is based on rock solid relational
math and set theory. Thirty plus years of research and verification by
the best companies like IBM, Microsoft and Oracle with thousand of
highly trained engineers taught by Phd professors all around the world
simply can't be wrong.
> PS. I did not give you permission to quote me without proper
> attribution, so either attribute properly or don't quote.
OOps, I did it again :)