Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!g43g2000cwa.googlegroups.com!not-for-mail From: "vldm10" Newsgroups: comp.databases.theory Subject: Re: Database design, Keys and some other things Date: 29 Sep 2005 13:02:33 -0700 Organization: http://groups.google.com Lines: 50 Message-ID: <1128024153.556718.36300@g43g2000cwa.googlegroups.com> References: <1127482601.079853.35050@f14g2000cwb.googlegroups.com> <433446ec$0$11069$e4fe514c@news.xs4all.nl> <1127584698.565076.211910@z14g2000cwz.googlegroups.com> <1127588192.332053.36050@g14g2000cwa.googlegroups.com> <1127680922.278009.187620@g44g2000cwa.googlegroups.com> <1127685541.779935.206860@o13g2000cwo.googlegroups.com> <1127782810.663225.104900@g44g2000cwa.googlegroups.com> NNTP-Posting-Host: 12.64.109.73 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1128024158 10233 127.0.0.1 (29 Sep 2005 20:02:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 29 Sep 2005 20:02:38 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: g43g2000cwa.googlegroups.com; posting-host=12.64.109.73; posting-account=CB0lnw0AAAChEu544z-NNxyXXneEx7Cf Xref: dp-news.maxwell.syr.edu comp.databases.theory:33776 vldm10 wrote: > dawn wrote: > > > > So, what is your rationale for choosing a single, often meaningless, > > identifier for each relation rather than working with a more natural > > candidate key in a relationship table? > > > I do not generate only a key; it is also the attribute which is the > name of the relation's instance. In current RM, typically, you do not Here I made mistake it is not a name it is the key and the attribute. So it is as I wrote in my text at www.dbdesign10.com Sorry about this The point was that in my definition it is a key and an attribute. In current RM it is key. It can be an attribut but not in case of a compaund key. > have an attribute which is the name of the relation's instance, you > have only the key. The key can be compound - meaning a key can be a set > of the attributes; i.e. the key is not an attribute. So my solution is > the attribute and it can't be meaningless because attribute has > origins in Conceptual Model and meaning in the Real World. A key which > has number as value is annoying, but we always use some additional > information to get meaning in the Real World. It is same case with SSN, > VIN etc. > If we have the Car table with the cars which attributes are all the > time same, it is okay to use existing RM solutions. However the RM's > definition of the key can't support cases which we discussed. In > these cases we need maybe to split the table. This involves a FK and > the data integrity or we need some additional "fields" which are > not the attributes, or we need some additional attributes. If an > entity has an attribute which repeats its value then I prefer my > solution. Relationships repeat their values more frequently then the > entities. > Finally current implementation of the Relational Model causes some > problems. > The TransRelational=99 Model is what the database world is waiting. It > provides a completely new approach to implementation. In this Model > columns are stored separately. But the key definition in the RM should > be changed. The logic of the compound key is directly opposite to the > logic of this model. > In 2.4 under 2. on my website I set more general representation of > storing the columns separately. An example 2.5 shows how knowledge can > be represented regarding one data (column Amount) and using the key > which is related to the state.=20 >=20 >=20 > Vladimir Odrljin