 | |
#121
 
| ||||
| ||||
|
Re: Another view on analysis and ER -
12-19-2007
, 04:55 AM
|
"JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message news:3e4b7a1f-8a53-4d16-aa2e-5d7e80e52884 (AT) e10g2000prf (DOT) googlegroups.com... On Dec 18, 4:38 am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message news:0110e0c9-3176-4c85-b089-e3a301eb93bc (AT) v4g2000hsf (DOT) googlegroups.com... On Dec 17, 2:31 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message [snip] Look, to identify an external entity, some attribute /must/ be immutable for us to recognize it as the same thing (in fact for it to be the same thing full stop), so let me exemplify what I think is the problem in your reasoning: 1) Say the construct in our UoD representing the entity E does not use its immutable identifer, X. 2) In the outside world imagine that, unbeknownst to us everything about the external entity E changes apart from X. 3) We are presented with E, but cannot find /one single/ attribute that matches with any of the constructs in our UoD. 4) We hence deign it to be a new construct, and add it. The original construct is now garbage, and its continued existence in the db will generate serious querying errors. 5) Broken database. I don't agree with your line of reasoning. This is what can happen: 1) Say the construct in our UoD representing the entity E does not use its immutable identifier, X. 2) In the outside world, everything about entity E changes apart from X. You missed out the words 'unbeknownst to us'. Kind of crucial Brian. Well, that's just it. If the entities that are represented in the database are being tracked, then there can't be any changes "unbeknownst to us." And how pray are you "tracking" these entities in the real world? Following them around in the real world with a camera? Or hiring temps to stalk them?  It doesn't really matter. If you're issuing updates, then you're tracking them. If you're issuing assignments, that is, deletes and inserts, then you're not. |
tracking items internally in the db, whereas I am referring to the
difficulty (or sometimes impossibility) of tracking something
externally without using its attributes to recognize it. I am
concerned with the issues of identifying something out there in the
real world before it gets to the DBA, and only then with corresponding
that to what we have in the database.
Quote:
|
When a car turns up for your vehicle database, with all its attributes changed apart from the VIN, and thats the /one/ attribute we didn't record in the db, how exactly are you going to ask it what its history was, so that you can update the right line in the table? Its impossible. By not using the VIN, we're fubar. We'll ask the surveillance team what the old values were, of course It's funny. Yours is almost the same argument I presented several years ago. IIRC, the resolution of that argument was that I am a vociferous ignorant. Perhaps you'll have better luck than I. Which contains more information, a set of still photographs or a video recording? Which, then, is better, an occasional snapshot of the entities that are interesting or active monitoring of those entities? 3) The database is told what is different about entity E via an UPDATE, Hence step 3 is the knock-on error. The whole point was that you cannot identify E in the database. You can't be guaranteed to know E's history, and there are no attributes recorded for E in the db which are any longer the same. So would you know what to update? Either by magic, or you simply can't do it. 4) The representation in the database is adjusted to reflect the current state of entity E. 5) Consistent database. In an update, both the old values and the new values are submitted, so an immutable identifier is not required. Incorrect schema choices (not picking X for the internal construct) are a serious design error that will generate this problem. However OID's positively facilitate the mistake, promoting the concept that E has an identity outside of its attributes. They don't even require you to take a stab at picking the correct identifer, so the whole mess can be avoided. Your argument is specious. How can assigning a name to something promote the concept that that something has an identity outside of its attributes? Non-sequitur - an OID is not a name. A name would be an attribute like any other. Keep your specious's to yourself selzerama. An object identifier is simply a rigid designator--a name--that is assigned to an object during instantiation. scratches head/> Surely this one has been done to death? An OID is a logical address, and even those in favour of OID's recognize that. It has nothing to do with the external entity, it is just a logical location where information about the entity is being stored. (I wonder if you are confusing what I'm talking about, with using a GUID as a surrogate attribute say, which is of course fine). Regards, J. Perhaps I am. My understanding of object identifiers is that they are arbitrary numbers assigned by the system to objects as they are instatiated. I was not under the impression that they were memory locations. |
OOP), but are now more generally viewed as logical locations (and
hence why they are often referred to as 'pointers', indicating where
information about an item is currently being /stored/). They are very
much a internal system artifact, whereas a name, a name is an
attribute - part of the information proper outside of the system.
Quote:
|
Now, whether they identify something or they identify information about something is not important, since there is a 1:1 correspondence between that which is interesting about something and the information about that something. |
entity so it can be 'tracked' - and it's just our approaches that
differ. As with hidden surrogates, the main problem with OID's is that
they don't do squit for us outside the database, and thats our first
port of call in the data management process.
Its like I was saying with the car - you can't ask it what its OID is
so you can update the right object. You can't examine its mutable
attributes to correspond to the right OID, because they may have all
changed. You can't necessarily ask it anything about it's history
because it's, well,...a car. So you need the VIN, a pretty good stable
identifier, that we can recognize in the real world, and use to
correspond to the information already in our db.
I hope at least, given the assumption that one cannot always rely on
'tracking' an item outside of the database (and hence the whole
'unbeknownst' changes are possible), that my 1-5 point argument
doesn't look quite so specious. Merry Xmas, J.
Quote:
|
As a consequence, if you can identify the information about something, then you can also indentify that something. For that reason it makes sense to me to think of OIDs as rigid designators for objects in the wild. Moreover, it may be the case that one or more of the attributes that are necessary to rigidly describe that something are not relevant to the problem at hand. Furthermore, assigning a name to something doesn't change the fact that there may be other ways to identify it--it may just be that that identification may change. These are serious practical issues for data modelling imo. External entities must correspond to your internal constructs, and if your UoD cannot do this (which I concede to your point that this can very easily happen), then that is when we require a surrogate to be invented to provide the correspondence. So it is certainly not at odds with the theories of identity ... read more |
#122
| |||
| |||
|
|
On Dec 18, 3:02 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message news:3e4b7a1f-8a53-4d16-aa2e-5d7e80e52884 (AT) e10g2000prf (DOT) googlegroups.com... On Dec 18, 4:38 am, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message news:0110e0c9-3176-4c85-b089-e3a301eb93bc (AT) v4g2000hsf (DOT) googlegroups.com... On Dec 17, 2:31 pm, "Brian Selzer" <br... (AT) selzer-software (DOT) com> wrote: "JOG" <j... (AT) cs (DOT) nott.ac.uk> wrote in message [snip] Look, to identify an external entity, some attribute /must/ be immutable for us to recognize it as the same thing (in fact for it to be the same thing full stop), so let me exemplify what I think is the problem in your reasoning: 1) Say the construct in our UoD representing the entity E does not use its immutable identifer, X. 2) In the outside world imagine that, unbeknownst to us everything about the external entity E changes apart from X. 3) We are presented with E, but cannot find /one single/ attribute that matches with any of the constructs in our UoD. 4) We hence deign it to be a new construct, and add it. The original construct is now garbage, and its continued existence in the db will generate serious querying errors. 5) Broken database. I don't agree with your line of reasoning. This is what can happen: 1) Say the construct in our UoD representing the entity E does not use its immutable identifier, X. 2) In the outside world, everything about entity E changes apart from X. You missed out the words 'unbeknownst to us'. Kind of crucial Brian. Well, that's just it. If the entities that are represented in the database are being tracked, then there can't be any changes "unbeknownst to us." And how pray are you "tracking" these entities in the real world? Following them around in the real world with a camera? Or hiring temps to stalk them? It doesn't really matter. If you're issuing updates, then you're tracking them. If you're issuing assignments, that is, deletes and inserts, then you're not. ah, what a prickly thing terminology is. You seem to be referring to tracking items internally in the db, whereas I am referring to the difficulty (or sometimes impossibility) of tracking something externally without using its attributes to recognize it. I am concerned with the issues of identifying something out there in the real world before it gets to the DBA, and only then with corresponding that to what we have in the database. When a car turns up for your vehicle database, with all its attributes changed apart from the VIN, and thats the /one/ attribute we didn't record in the db, how exactly are you going to ask it what its history was, so that you can update the right line in the table? Its impossible. By not using the VIN, we're fubar. We'll ask the surveillance team what the old values were, of course It's funny. Yours is almost the same argument I presented several years ago. IIRC, the resolution of that argument was that I am a vociferous ignorant. Perhaps you'll have better luck than I. Which contains more information, a set of still photographs or a video recording? Which, then, is better, an occasional snapshot of the entities that are interesting or active monitoring of those entities? 3) The database is told what is different about entity E via an UPDATE, Hence step 3 is the knock-on error. The whole point was that you cannot identify E in the database. You can't be guaranteed to know E's history, and there are no attributes recorded for E in the db which are any longer the same. So would you know what to update? Either by magic, or you simply can't do it. 4) The representation in the database is adjusted to reflect the current state of entity E. 5) Consistent database. In an update, both the old values and the new values are submitted, so an immutable identifier is not required. Incorrect schema choices (not picking X for the internal construct) are a serious design error that will generate this problem. However OID's positively facilitate the mistake, promoting the concept that E has an identity outside of its attributes. They don't even require you to take a stab at picking the correct identifer, so the whole mess can be avoided. Your argument is specious. How can assigning a name to something promote the concept that that something has an identity outside of its attributes? Non-sequitur - an OID is not a name. A name would be an attribute like any other. Keep your specious's to yourself selzerama. An object identifier is simply a rigid designator--a name--that is assigned to an object during instantiation. scratches head/> Surely this one has been done to death? An OID is a logical address, and even those in favour of OID's recognize that. It has nothing to do with the external entity, it is just a logical location where information about the entity is being stored. (I wonder if you are confusing what I'm talking about, with using a GUID as a surrogate attribute say, which is of course fine). Regards, J. Perhaps I am. My understanding of object identifiers is that they are arbitrary numbers assigned by the system to objects as they are instatiated. I was not under the impression that they were memory locations. OID's once referred specifically to memory locations (and still do in OOP), but are now more generally viewed as logical locations (and hence why they are often referred to as 'pointers', indicating where information about an item is currently being /stored/). They are very much a internal system artifact, whereas a name, a name is an attribute - part of the information proper outside of the system. |
a surrogate and immediately claim their advantage is speed. :-\
Quote:
|
Now, whether they identify something or they identify information about something is not important, since there is a 1:1 correspondence between that which is interesting about something and the information about that something. Ok, so we are seeking the same things - an immutable identifier for an entity so it can be 'tracked' - and it's just our approaches that differ. As with hidden surrogates, the main problem with OID's is that they don't do squit for us outside the database, and thats our first port of call in the data management process. Its like I was saying with the car - you can't ask it what its OID is so you can update the right object. You can't examine its mutable attributes to correspond to the right OID, because they may have all changed. You can't necessarily ask it anything about it's history because it's, well,...a car. So you need the VIN, a pretty good stable identifier, that we can recognize in the real world, and use to correspond to the information already in our db. I hope at least, given the assumption that one cannot always rely on 'tracking' an item outside of the database (and hence the whole 'unbeknownst' changes are possible), that my 1-5 point argument doesn't look quite so specious. Merry Xmas, J. |
straightforward and compelling argument.
#123
| |||
| |||
|
|
"rpost" <rpost (AT) pcwin518 (DOT) campus.tue.nl> wrote in message news:c1f35$4766eca5$839b4533$16718 (AT) news1 (DOT) tudelft.nl... David Cressey wrote: [...] The question of whether it's "the same entity" or "a different entity" is also moot. Until you consider other relations referring to the same entity. Their attributes may or may not have to be updated as well. Are they really "referring to the same entity"? |
Quote:
|
Or are they "referring to data values that describe and/or identify some entity"? |
to able to state that two references refer, in the given context, to the
same thing (i.e. that changes to that thing affect both occurrences)
without having said how the thing is identified.
Quote:
|
Can an entity be identified without data? |
all access to the data is in terms of the query (and update) language): no.
Regarding references within the model (if the model allows them): yes.
--
Reinier
#124
| |||
| |||
|
|
Moreover, an OODBMS doesn't force you to omit step 3. This I am unclear of. Does an OODBMS not tie the logical encoding into one binding conceptual view? |
standard logical models are supported.
--
Reinier
#125
| |||
| |||
|
|
paul c schreef: mAsterdam wrote: Nice duck. Are you holding up the claim or are you letting it go? Thanks, I like ducks because of their character, eg., they will kill a seagull that comes near their young but what have ducks got to do with your opinion which is getting harder and harder to pin down in spite of the volume of messages? You are letting the claim go. Ok. You brought in the RM. Can we now get back on (sub-)topic? (Facts) |
--
What you see depends on where you stand.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.