Re: Extending my question. Was: The relational model and relational
Date: Tue, 18 Feb 2003 16:44:13 -0500
"Bernard Peek" <bap_at_shrdlu.com> wrote in message
> In message <0ai4a.10$m52.1404041_at_mantis.golden.net>, Bob Badour
> <bbadour_at_golden.net> writes
> >> I collect books and as sometimes happens I have some duplicates. I have
> >> two copies of the same book, quite often both of them in mint
> >> I have two database entries for that edition. I have two copies of the
> >> book on the shelf. Suppose I give one copy away? I take one copy off of
> >> the shelf and I delete one record from the database.
> >You seem to have missed the point that there is logically no way to
> >only one of the records without also deleting the other record. One must
> >rely on proprietary, non-portable features that directly expose the
> >storage model. One cannot simply issue a statement to delete the book.
> >must first query the dbms for the physical pointers to matching books
> >arbitrarily choose one of the physical pointers to navigate for the
> That's correct if you use a relational database. This is because
> relational databases operate under the axiom that there cannot be two
> identical records.
Huh? It's not possible with a relational dbms. The situation is only possible with a dbms based on multisets or that otherwise expose duplicates in the logical model. Think about it.
> >This means that all delete processes must follow this two-step method
> >when no duplicate books exist.
> >> It makes no difference whether I delete the record that was created
> >> I acquired the first book or the second. It makes no difference whether
> >> I remove the first book or the second.
> >It makes a difference whether one can logically address each of the
> >independently, though. How would you construct an SQL delete statement to
> >delete just one of the identical book rows?
> I wouldn't try to do it using SQL. SQL was designed to work on
> relational databases, where there cannot be two identical records.
SQL was designed to work on multisets not relations. It allows duplicate rows. If duplicates are useful as you have suggested, I expect a reasonable and direct answer to my question:
How would you construct an SQL delete statement to delete just one of the identical book rows?
If not SQL, then some other DML language for a dbms that allows duplicates.
> >> I could create a new entity and call it "Acquisition Number" and that's
> >> what most librarians do. Acquisition numbers are simply identity
> >> They should not be considered part of the logical data structure.
> >Logical identifiers are absolutely required for the logical data model.
> >That's where logical identifiers are most important. By adding a logical
> >identifier, you no longer have a multiset and you might as well use a
> >relational dbms instead.
> From a purely pragmatic viewpoint I invariably choose databases that at
> least claim to be relational. My book collection database has an
> acquisition number field.
Then your database prohibits duplicates obviating your own arguments in favour of them.
> Bernard Peek
> www.diversebooks.com: SF & Computing book reviews and more.....
> In search of cognoscenti
Received on Tue Feb 18 2003 - 22:44:13 CET