0 to Many relationship
Sébastien Biaudet
I have two tables which are joined in a 1 to many relationship.
I will two tables joined in a 0 to many relationship.
How can i made this.
Thanks.
Sébastien Biaudet
Terry Kreft
entity doesn't exist then why (how) can you model it?
Sébastien Biaudet wrote in message <6rj7i6$86h$1...@news.internetsat.com>...
Rebecca Riordan
HTH
- Rebecca
Dev Ashish
non-existant entity in the arch.? (Sorry for being dense..)
-- Dev
Rebecca Riordan wrote in message <35dd5...@news1.ibm.net>...
:Don't enforce referential integrity.
:>
:>
:
:
Gary Labowitz
side.
I believe he may be looking for a Left Outer Join which will retrieve all
the records from the 1 side and records that match on the many side. Any
records on the primary side that don't have any matching records on the many
side are returned with Nulls in the columns.
Double click the relationship line in the query builder window and select
the type of join wanted (probably number 2.)
HTH
--
Gary (MCT, MCPS, MCSD)
http://www.enter.net/~garyl/ for references to good books
Contribute to ga...@enter.net
ICQ 6375624
Dev Ashish wrote in message <6rl1l4$p...@bgtnsc02.worldnet.att.net>...
Clive Bolton
Are you asking how to change the relationship between tblA and tblB from
1-to-many to "sometimes there is a relationship"?
If so, Rebecca's answer is appropriate - go to the relationships window,
select the *line* between tblA and tblB and remove "enforce referential
integrity".
However, some of the gurus of this group argue that the only purpose of the
defined relations is to enforce such integrity, and if that is not needed,
remove the relationship altogether (by deleting the line, then the two table
images.
In that case, make sure the the two fields that were previously joined do
have indexes. Then in any queries you create, draw your own joins there.
Clive Bolton
Tauranga, New Zealand
(Please respond via this newsgroup)
Rebecca Riordan
set, but the relationship is optional. For example, you can enter a
customer who may not have been assigned a sales rep yet, but when you _do_
assign a sales rep, they must be listed in the sales rep table. It's not an
uncommon situation. Some people put a dummy "unassigned" record in the
sales rep table, which also works, but causes other problems (like it shows
up in reports and confuses the users)
- Rebecca.
Dev Ashish wrote in message <6rl1l4$p...@bgtnsc02.worldnet.att.net>...
>But Rebecca, a "0-Many" relationship???? What's that saying, we have a
>non-existant entity in the arch.? (Sorry for being dense..)
>
>-- Dev
>
>Rebecca Riordan wrote in message <35dd5...@news1.ibm.net>...
>:Don't enforce referential integrity.
>:
>:HTH
>:
>: - Rebecca
>:
>:Sébastien Biaudet wrote in message <6rj7i6$86h$1...@news.internetsat.com>...
>:>Hi,
>:>
>:>I have two tables which are joined in a 1 to many relationship.
>:>I will two tables joined in a 0 to many relationship.
Fernando Martins
wrote:
>Are you asking how to change the relationship between tblA and tblB from
>1-to-many to "sometimes there is a relationship"?
>
>If so, Rebecca's answer is appropriate - go to the relationships window,
>select the *line* between tblA and tblB and remove "enforce referential
>integrity".
>
<snip>
Don't remove the check. Referential Integrity allows for 0-many
relathionships. You can have some records on the One-side of the rel.
without related records on the Many-side. The opposite is also true.
You can have records in the many-side with a null value on the foreign
key.
Fernando C Martins
Kurt A. Fisher
<6rj9oj$bbl$1...@newsreader1.core.theplanet.net>...
Terry, to my understanding, 0------>N ( zero to many ) relationships are
not used in entity relationship (ER) diagramming of _relationships_. They
occassionally occur in UML notation for UML _associations_ to indicate an
optional dependency. Although I've never personally seen a zero to many
relationship notated in an application, the example given in one reference
book is the one to many relationship between a flight and airport landings.
1 flight may land at many airports. However, the dependency is optional.
If the flight crashes, instead of lands, there will be an airport landing
without a flight.
I guess one could say the same thing about interstate trucks that have
accidents before shipments are completed and suppliers whose factory burn
down before a product is delivered. Sounds too theoretical for my tastes.
Terry Kreft
Thanks very much for your answer.
I was hung up on the relational model, but thinking about it there are a
number of "real world" relationships which are potentially 0 to many.
Kurt A. Fisher wrote in message <35e09...@news.lgcy.com>...
Rebecca Riordan
Actually, 0:N is perfectly acceptable in ER. A null value in the many-side
is not considered to violate referential integrity. My understanding was
that enforcing referential integrity with the Access prohibited this (that's
Access as opposed to Jet), but another poster has disagreed, so I'll have to
double check that. Maybe it's a "no null values in primary keys" issue,
which as you undoubtedly know is the subject of considerable debate in the
theoretical community.
FWIW...
- Rebecca.
Fernando Martins
<rebe...@magna.com.au> wrote:
>Kurt,
>
>Actually, 0:N is perfectly acceptable in ER. A null value in the many-side
>is not considered to violate referential integrity. My understanding was
>that enforcing referential integrity with the Access prohibited this (that's
>Access as opposed to Jet), but another poster has disagreed, so I'll have to
>double check that. Maybe it's a "no null values in primary keys" issue,
>which as you undoubtedly know is the subject of considerable debate in the
>theoretical community.
>
ER modelling doesn't accept null values in primary keys. This violates
the so called Entity-Integrity-Rule because a null "value" it's not a
value and doesn't represent anything. If you pick a primary key to
_represent_ an entity, then you must really represent it, giving a
unique value (which null is not).
OTOH, the Referential-Integrity-Rule states that the foreign (related)
key can take null "values", which Access allows.
As Rebecca said, there is a battle field on this subject. Codd, the
creator of Relational Theory, aproves Null values and they are now
part of the theory. On the opposite side is C.J.Date, a well known
scientist and writer.
I'm not sure about the exact arguments of each side. If there is
enough interest, I could check this. If anybody knows it, please post
them.
Fernando C Martins
Lyle Fairfield
immense ignorance of relationships and get a little help.
I think of relationships as sets of ordered pairs. Each element of a pair is
a set of fields, with the first set being a record from one table, and the
second set being a record from the other table. Thus I think of only one
pointer, the pointer that points to some particular ordered pair.
(I used to think of the pointer in table two being moved in step with the
record pointer of table one, but this is a poor model for one to many, or
many to many. When we get to Lyle do we move the pointer to Daughter 1 or to
Daughter 2?)
A relationship rule allows Access or Jet to create the relationship, that
set of ordered pairs; for whatever reason it was decided to make that rule
very restrictive, equality being its only operator, although we can specify
that more than one pair of fields be equal. As an aside, I wonder why this
restriction is necessary?
In any case, I am trying to think of what that 0 to many relationship would
look like. While I can envision it as a theoretical model, with the first
element in each pair being an empty set, and the second being one of the
records from the second table, I stumble on how Access or the Jet would
actually create the relationship, for it is restricted to using the equality
operator as the relationship rule. There will be no element of the empty
first set that Access or the Jet can use to find an equal element on the
second set.
Perhaps, someone can help.
Lyle Fairfield
Rebecca Riordan wrote in message <35e13...@news1.ibm.net>...
>Kurt,
>
>Actually, 0:N is perfectly acceptable in ER. A null value in the many-side
>is not considered to violate referential integrity. My understanding was
>that enforcing referential integrity with the Access prohibited this
(that's
>Access as opposed to Jet), but another poster has disagreed, so I'll have
to
>double check that. Maybe it's a "no null values in primary keys" issue,
>which as you undoubtedly know is the subject of considerable debate in the
>theoretical community.
>
Clive Bolton
relationship, surely. Unless the term is used to include a stand-alone table
on the "many" side with no relationships at all. On that basis, there could
also be a 0-1 relationship (such as the 1-table 1-record system record I
use).
I had been reading this thread and thinking of instances of "1-M with nulls
allowed in the M table". So, too, Rebecca and who knows who else...
Clive Bolton
Tauranga, New Zealand
(Please respond via this newsgroup)
Lyle Fairfield wrote in message <35e22...@news.cgocable.net>...
>I'm trying to find the appropriate message in this thread to display my
>immense ignorance of relationships and get a little help.
>A relationship rule allows Access or Jet to create the relationship, that
>set of ordered pairs; for whatever reason it was decided to make that rule
>very restrictive, equality being its only operator, although we can specify
>that more than one pair of fields be equal. As an aside, I wonder why this
>restriction is necessary?
>In any case, I am trying to think of what that 0 to many relationship would
>look like. While I can envision it as a theoretical model, with the first
>element in each pair being an empty set, and the second being one of the
>records from the second table, I stumble on how Access or the Jet would
>actually create the relationship, for it is restricted to using the
equality
>operator as the relationship rule. There will be no element of the empty
>first set that Access or the Jet can use to find an equal element on the
>second set.
>Rebecca Riordan wrote in message <35e13...@news1.ibm.net>...
Rebecca Riordan
principles, which is not, of course, necessarily correct.
Remember, always, that data modelling is a _semantic_ process. This is why
you can't just say, "right, this is how an address is modelled", for
instance, and go on with your life. It all depends on what the data means
and how it's going to be used. So, if you're going to work on a conceptual
model of relationships, you're better off (IMNSHO), working from what normal
people call reality rather than this bizarreness that we computer people
have created for ourselves. I shall call the former the "real world" and
hope that we can, for the moment, put aside otherwise-interesting
epistimological debate. <g>
In the real world, abstract classes of things don't have actual existence
(Plato's Allegory of the Cave notwithstanding). We do talk about things in
the abstract, however...we discuss "chairs" without necessarily referring to
any specific instance of a chair. And we can build a model of the
inter-relationships of abstract things, in the real world. We talk usefully
about "men" and "women", without worrying overmuch about the specifics of
any particular individual's genetic or sexual make-up. (Oh, for pity's
sake, she's talking about sex again...) We talk about "marriage in the
Catholic church" as a 1:1 relationship between a man and a woman. Marriage
in most other religions is, I think, n:m, since we must allow for divorce,
but not being at all religious, I wouldn't swear to that. (And if I'm
wrong, please, just forgive me. It's not pertinent to the current
discussion, okay?) Anyway, "Catholic Marriage" is a theoretical
relationship between two abstract classes of things, "men" and "women".
Building a data model, then, is only a matter of describing the theoretical
relationships between abstract classes. We have an entity called "Woman"
and an entity called "Man", and we create a relationship between the two
classes called "CatholicMarriage". Now, we might choose to implement this
by using a foreign key in the Man entity, called "Wife" defined on the
domain "Woman" (Last I checked, Catholics didn't allow marriage between two
individuals of the same gender...)
But obviously, not every man or woman gets married. That's okay, that
doesn't break the _model_. A Null value in a foreign key (an optional
relationship in the model) does not compromise relational integrity. The
rule is "If it the value is not null, it must come from the defined domain".
The same holds true if you're modelling a customer who doesn't yet have a
sales rep, or a class that doesn't yet have a teacher. In relational
theory, if you have a relationship that may not be null (invoice line item
to invoice header, for example), you have to specify that as a separate
step. (BTW, this is why I use the "crow's foot" method of drawing ER
diagrams rather than the "infinity symbol" method that the Access UI
uses...it allows you to explicitly state the optionality of the
relationship).
Now, there's a problem with the implementation here. If the foreign key
participates in the primary key of the entity, Access will not allow null
values. Easy enough to work around, just use an autonumber as the primary
key...compound keys can allow nulls. You can still set up the relationship
in the engine. (As I think I mentioned, the use of null values _at_all_ is
contentious, the MS designers are not indefinsible. I happen to think
they're useful, but there are certainly contrary opinions.)
What's important here is that you keep in mind the various logical layers
you're working with here...you have the "abstract classes of things in the
real world", which I call the "problem space", the "data model" and the
"data implementation". Obviously, you want to have the implementation as
close to the real world as possible (given that odd way of thinking about
the real world that data modellers develop <g>), but there are going to be
some variances. You have to work with your tools, but don't mistake the
tools for the problem space.
On a related subject, Access is not restricted to equi-joins. You can use
the SQL editor to change the default "=" to any of the logical comparisons,
it's just that by default, the query editor uses a natural join (well, _I_
define a natural join as an inner equi-join; I recently saw it described as
a projection against an equi-join, which I think is very odd).
HTH...
- Rebecca.
Clive Bolton wrote in message <6rtctm$2ee$1...@news.wave.co.nz>...
Fernando Martins
<lyle...@cgocable.net> wrote:
>I'm trying to find the appropriate message in this thread to display my
>immense ignorance of relationships and get a little help.
>I think of relationships as sets of ordered pairs. Each element of a pair is
>a set of fields, with the first set being a record from one table, and the
>second set being a record from the other table. Thus I think of only one
>pointer, the pointer that points to some particular ordered pair.
>(I used to think of the pointer in table two being moved in step with the
>record pointer of table one, but this is a poor model for one to many, or
>many to many. When we get to Lyle do we move the pointer to Daughter 1 or to
>Daughter 2?)
This is too confusing to me. Relationship is a simple concept and it
seems to me you are complicating the subject. Let me try a simple
explanation.
Relationships are not sets. Tables are. A relationship is kind of a
_virtual_ conection between two tables, which a DBMS is aware of. The
data representing the relationship is _only_ on the tables.
Consider two tables, for categories and products:
tblCategories(CatID, Category)
tblProducts(ProdID, Name, CatID)
tblProducts.CatID references field tblCategories.CatID (and so we say
this field is a pointer to tblCategories). This conection is
considered to be a relathionship.
>A relationship rule allows Access or Jet to create the relationship, that
>set of ordered pairs; for whatever reason it was decided to make that rule
>very restrictive, equality being its only operator, although we can specify
>that more than one pair of fields be equal. As an aside, I wonder why this
>restriction is necessary?
Jisas Craist, you are really confused. tblProducts.CatID is
_referencing_ categories, telling us what categorie the product
_belongs_ to. There is _no_ operator involved!
I think you are confusing with types of JOIN between tables/queries.
A relathionship and a join are different things. It just happens they
are graphically represent in the same way. Is this the source of your
confusion?
>In any case, I am trying to think of what that 0 to many relationship would
>look like. While I can envision it as a theoretical model, with the first
>element in each pair being an empty set, and the second being one of the
>records from the second table, I stumble on how Access or the Jet would
>actually create the relationship, for it is restricted to using the equality
>operator as the relationship rule. There will be no element of the empty
>first set that Access or the Jet can use to find an equal element on the
>second set.
>Perhaps, someone can help.
>
Let me try. A 0:M relationship is simply a 1:M relationship relaxed,
meaning that you are not requiring all categories to have related
produts. A 0:M relationship simply states you can have a category
without products. As a matter of fact this is the kind of relationship
Access supports.
When talking about JOINS, Access allows Inner and Outer joins as well
as theta-joins (using inequality to ralate tables)
HTH
Fernando C Martins
Terry Kreft
The relational model does not allow 0-M, that's true (which was the reason
for my question before), but the real world does, I remember on the
"Implementing a Database design in SQL6.5" course they have a Library
database example; one of the requirements for junior members was that they
had to have a corresponding parent in the library before they could join,
and my first thought was "what about the orphans?", the relational design
they insisted on didn't allow for a real world 0-M relationship.
Clive Bolton wrote in message <6rtctm$2ee$1...@news.wave.co.nz>...
>A fellow stumbler says thanks, Lyle. It is impossible to have a 0-M
>relationship, surely. Unless the term is used to include a stand-alone
table
>on the "many" side with no relationships at all. On that basis, there could
>also be a 0-1 relationship (such as the 1-table 1-record system record I
>use).
>
>I had been reading this thread and thinking of instances of "1-M with nulls
>allowed in the M table". So, too, Rebecca and who knows who else...
>
>Clive Bolton
>Tauranga, New Zealand
>(Please respond via this newsgroup)
>
>Lyle Fairfield wrote in message <35e22...@news.cgocable.net>...
>>I'm trying to find the appropriate message in this thread to display my
>>immense ignorance of relationships and get a little help.
>>A relationship rule allows Access or Jet to create the relationship, that
>>set of ordered pairs; for whatever reason it was decided to make that rule
>>very restrictive, equality being its only operator, although we can
specify
>>that more than one pair of fields be equal. As an aside, I wonder why this
>>restriction is necessary?
>>In any case, I am trying to think of what that 0 to many relationship
would
>>look like. While I can envision it as a theoretical model, with the first
>>element in each pair being an empty set, and the second being one of the
>>records from the second table, I stumble on how Access or the Jet would
>>actually create the relationship, for it is restricted to using the
>equality
>>operator as the relationship rule. There will be no element of the empty
>>first set that Access or the Jet can use to find an equal element on the
>>second set.
>
Clive Bolton
it emphasises my point: a 0 to many relationship means a primary table with
a record with null as its primary key (or no existing records) related to
many records in another table which also have null as the foreign key. One
can type the words, but it's an empty set.
0 to many means its a null value in the primary key. Or, no records matched
to many records.
1-to-some is what is being illustrated, and I use it quite extensively. It
is probably what the original questioner had in mind, but it isn't what he
asked.
Clive Bolton
Tauranga, New Zealand
(Please respond via this newsgroup)
Rebecca Riordan wrote in message <35e28...@news1.ibm.net>...
>Okay, let me see if I can explain this....at least the way I understand the
>principles, which is not, of course, necessarily correct.
>
Clipped to get through my ISP's server!
Lyle Fairfield
it is unlikely that we shall ever stumble across it as an observable
phenomenom, especially in the Access-Jet world where relationship rule,
(relationship generator), constraints are so severe.
That way I'll be able to argue from the other side when it pleases me.
In article <6rtctm$2ee$1...@news.wave.co.nz>, "Clive Bolton" <al...@wave.co.nz>
wrote:
>A fellow stumbler says thanks, Lyle. It is impossible to have a 0-M
>relationship, surely.
Lyle Fairfield
Ceterum censeo Microsoft esse delendam - Cato
Clive Bolton
Clive Bolton
Tauranga, New Zealand
(Please respond via this newsgroup)
Fernando Martins wrote in message <35e381a0....@news.telepac.pt>...
>On Mon, 24 Aug 1998 23:07:55 -0400, "Lyle Fairfield"
><lyle...@cgocable.net> wrote:
>
>>I'm trying to find the appropriate message in this thread to display my
>>immense ignorance of relationships and get a little help.
Fernando Martins
wrote:
>How can there be a relationship between nothing and something (0 to many)?
>
>
As I've learnead it, this is not the meaning of a 0:M relationship. In
ER modelling, 0:M simply means you _have_ a record on the 0-side of
the relationship _without_ (this is the meaning of the 0) any record
on the many-side.
Fernando C Martins
Arvin Meyer
Database Design in SQL6.5 too.
There should have been a member table which described a family unit,
complete with address and phone number, and a many-side table which
described ALL the members of that family unit. In the Library database, that
is probably a better model. As I recall, there was no need for multiple
contact information.
This model allows for a description of relationships to the family unit for
all members, not just juveniles, and avoids any duplication of data. It
allows for changing members within the family unit, (i.e. the juvenile grows
up, and starts his/her own family unit or wife divorces and joins another
family unit, or starts her own)
-----
Arvin Meyer
ons...@esinet.net
Terry Kreft wrote in message
<6ru6rn$g0g$1...@newsreader1.core.theplanet.net>...
Keri Hardwick
Expenses
Revenue
There many be many revenue items with no related expenses (good) or
many expenditure items with no related revenue (not so good).
Of course you can not define such a Relationship in Access; and it is
not a Relationship from the perspective of maintaining referential
integrity or cascading updates/deletes; but it most certainly a "mental"
relationship, and it is the very thing for which a Full Outer Join is
intended. Which we do not have in Access, but instead simulate via
(Left Join)-(Right Join)-(Union Query).
IMHO, using the word "Relationships" as the name of a defined join
between two tables was a mistake by MS (the only one! <vbg>) I see many
people, especially new users, getting so hung up on defining
Relationships without stopping to consider the realtionships between the
tables. In fact, I personally see no point in defining Relationships at
all if you are not going to enforce ref. integ. or cascade changes.
Anyway, my point is that there is a set of data to model any sort of
relationship you can come up with; but they aren't all Relationships in
Access.
Keri Hardwick
Clive Bolton wrote:
>
> A fellow stumbler says thanks, Lyle. It is impossible to have a 0-M
> relationship, surely. Unless the term is used to include a stand-alone table
> on the "many" side with no relationships at all. On that basis, there could
> also be a 0-1 relationship (such as the 1-table 1-record system record I
> use).
>
> I had been reading this thread and thinking of instances of "1-M with nulls
> allowed in the M table". So, too, Rebecca and who knows who else...
>
> Clive Bolton
> Tauranga, New Zealand
> (Please respond via this newsgroup)
>
> Lyle Fairfield wrote in message <35e22...@news.cgocable.net>...
> >I'm trying to find the appropriate message in this thread to display my
> >immense ignorance of relationships and get a little help.
Robin Stoddart-Stones
Is this not a specification error rather than a real world 0-M relationship? A
spec that read parent, but meant 'representative adult' I could understand, but
an insistence on a parental (blood) relationship? Mind you, having seen how
some bureaucrats manage to misinterpret anything that they are questioned on, I
am sure that once misstated it was unthinkingly enforced. :-)
Have Fun
Robin
In article
<6ru6rn$g0g$1...@newsreader1.core.theplanet.net>, "Terry Kreft"
(terry...@mps.co.uk) writes:
>Hi Clive,
>The relational model does not allow 0-M, that's true (which was the reason
>for my question before), but the real world does, I remember on the
>"Implementing a Database design in SQL6.5" course they have a Library
>database example; one of the requirements for junior members was that they
>had to have a corresponding parent in the library before they could join,
>and my first thought was "what about the orphans?", the relational design
>they insisted on didn't allow for a real world 0-M relationship.
>
>
>Clive Bolton wrote in message <6rtctm$2ee$1...@news.wave.co.nz>...
Lyle Fairfield
idea what this sentence means.
Lyle
In article <35e381a0....@news.telepac.pt>, NoSpam.f...@computer.org
wrote:
>A relationship is kind of a
>_virtual_ conection between two tables, which a DBMS is aware of.
>HTH
>
>Fernando C Martins
Lyle Fairfield
understand. I believe that it is because I always start with the abstract
idea, try to make it as sound as possible, and then move to the real world, a
place where I admit, I tread much more carefully than in the abstract, (where
I am reasonably sure that an "a" is an "a"). In the real world, I try to find
things that behave in a manner that can be explained and predicted by the
model. When I do, I use the model to explain and predict them.
But I never develop the model from that real world. I can see that this may be
the cause of my being out-of-step with some of the ideas about relationships
that have been presented throughout this thread.
Unfortunately, I do not see a solution. I am not at the stage of life where I
am going to change my whole way of knowing things. So, I guess in this case, I
shall have to follow.
Lyle
In article <35e28...@news1.ibm.net>, "Rebecca Riordan"
Clive Bolton
1. 0-M defines "no relationship" eg orphan
2. If it arises, look at redefining the parent object, or redesigning the
table structures, including adding a table.
Clive Bolton
Tauranga, New Zealand
(Please respond via this newsgroup)
Robin Stoddart-Stones wrote in message <10...@gmsproject.win-uk.net>...
Gary Labowitz
That means it's allowed, but only once per table even for non-unique keys.
HTMTW
--
Gary (MCT, MCPS, MCSD)
http://www.enter.net/~garyl/ for references to good books
Contribute to ga...@enter.net
ICQ 6375624
>>
>>Actually, 0:N is perfectly acceptable in ER. A null value in the
many-side
>>that enforcing referential integrity with the Access prohibited this
(that's
>>Access as opposed to Jet), but another poster has disagreed, so I'll have
to
>>double check that. Maybe it's a "no null values in primary keys" issue,
>>which as you undoubtedly know is the subject of considerable debate in the
>>theoretical community.
>>
>
Fernando Martins
Fairfield) wrote:
>I'm afraid that your hope, (HTH), goes unfulfilled. For instance, I have no
>idea what this sentence means.
>
>>A relationship is kind of a
>>_virtual_ conection between two tables, which a DBMS is aware of.
>
(please consider that I am not a native english speaker/writer)
I wrote this sentence (..._virtual_...) because you said that
relationships were sets, i.e. a _real_ data object. I answered that
tables are sets (real), relationships are not. The pairs of fields you
were refering are conections between tables but they don't have
existence in the DB, so they are _virtual_. However the DBMS is aware
of them because you made the conection between two tables. This is
what allows the DBMS to check for referential integrity and apply the
cascade operations.
The conections (relathionships) are virtual because you are simply
informing the DBMS that some fields in the related table (many-side)
are taking values from some similar fieldsin the primary table
(one-side). (The first set of fields is called Foreign Key, the 2nd is
the well known Primary Key).
I hope this time I have been more helpfull. By the way, could you
understand the rest of the post? I don't know how bad my "english" is,
but if you think I can be of any help let me know.
Fernando C Martins
Lyle Fairfield
If we have any problems in communication, I think they are more likely to be
attributable to different ways of thinking about databases than language. In
my opinion, you express yourself quite clearly.
Thanks, again.
Lyle Fairfield
In article <35e3f5c4...@news.telepac.pt>, NoSpam.f...@computer.org
wrote:
Kurt Milam
Consider a real-world situation wherein ACME Corp sells products to
corporate customers and individuals. In the pursuit of good normalization, I'd
probably set up a a company table with a people daughter. Since ACME might
sell to multiple people within one company, the relationship from company to
people would be one to many.
0 to many would exist as long as there were multiple individuals who were
not corporate customers, and therefore had no parent associated records in the
company table. Am I on the right track here? I have to say, I find data
modeling extremely intruiging.
Perhaps a single "No Company" record in the company table would be a simple
solution to the 0 to many situation in this instance - something of a single
"Protector of Orphaned Children," if you will.
Just a though,
Kurt
Lyle Fairfield wrote:
> I'm trying to find the appropriate message in this thread to display my
> immense ignorance of relationships and get a little help.
> I think of relationships as sets of ordered pairs. Each element of a pair is
> a set of fields, with the first set being a record from one table, and the
> second set being a record from the other table. Thus I think of only one
> pointer, the pointer that points to some particular ordered pair.
> (I used to think of the pointer in table two being moved in step with the
> record pointer of table one, but this is a poor model for one to many, or
> many to many. When we get to Lyle do we move the pointer to Daughter 1 or to
> Daughter 2?)
> A relationship rule allows Access or Jet to create the relationship, that
> set of ordered pairs; for whatever reason it was decided to make that rule
> very restrictive, equality being its only operator, although we can specify
> that more than one pair of fields be equal. As an aside, I wonder why this
> restriction is necessary?
> In any case, I am trying to think of what that 0 to many relationship would
> look like. While I can envision it as a theoretical model, with the first
> element in each pair being an empty set, and the second being one of the
> records from the second table, I stumble on how Access or the Jet would
> actually create the relationship, for it is restricted to using the equality
> operator as the relationship rule. There will be no element of the empty
> first set that Access or the Jet can use to find an equal element on the
> second set.
> Perhaps, someone can help.
>
> Lyle Fairfield
>
> Rebecca Riordan wrote in message <35e13...@news1.ibm.net>...
> >Kurt,
> >
> >Actually, 0:N is perfectly acceptable in ER. A null value in the many-side
> >is not considered to violate referential integrity. My understanding was
> >that enforcing referential integrity with the Access prohibited this
> (that's
> >Access as opposed to Jet), but another poster has disagreed, so I'll have
> to
> >double check that. Maybe it's a "no null values in primary keys" issue,
> >which as you undoubtedly know is the subject of considerable debate in the
> >theoretical community.
> >
Kurt Milam
If I'd only read the rest of the thread before posting my previous comment, I'd
have realized it was superfluous.
On an aside, any reading recommendations which treat this subject of data
modeling in detail?
Thanks, your comments are appreciated.
Kurt
Terry Kreft
Yes, that's what I was getting at, the specification called for a 1:M
relationship, whereas the real world isn't like that.
If you see Arvin Meyers reply to my posting you'll see, what i would
consider a far superior design model.
Robin Stoddart-Stones wrote in message <10...@gmsproject.win-uk.net>...
>Terry,
>
>Is this not a specification error rather than a real world 0-M
relationship? A
>spec that read parent, but meant 'representative adult' I could understand,
but
>an insistence on a parental (blood) relationship? Mind you, having seen
how
>some bureaucrats manage to misinterpret anything that they are questioned
on, I
>am sure that once misstated it was unthinkingly enforced. :-)
>
>Have Fun
>Robin
>
>
>
>
> In article
><6ru6rn$g0g$1...@newsreader1.core.theplanet.net>, "Terry Kreft"
>(terry...@mps.co.uk) writes:
>>Hi Clive,
>>The relational model does not allow 0-M, that's true (which was the reason
>>for my question before), but the real world does, I remember on the
>>"Implementing a Database design in SQL6.5" course they have a Library
>>database example; one of the requirements for junior members was that they
>>had to have a corresponding parent in the library before they could join,
>>and my first thought was "what about the orphans?", the relational design
>>they insisted on didn't allow for a real world 0-M relationship.
>>
>>
>>Clive Bolton wrote in message <6rtctm$2ee$1...@news.wave.co.nz>...
>>>A fellow stumbler says thanks, Lyle. It is impossible to have a 0-M
>>>relationship, surely. Unless the term is used to include a stand-alone
>>table
>>>on the "many" side with no relationships at all. On that basis, there
could
>>>also be a 0-1 relationship (such as the 1-table 1-record system record I
>>>use).
>>>
>>>I had been reading this thread and thinking of instances of "1-M with
nulls
>>>allowed in the M table". So, too, Rebecca and who knows who else...
>>>
>>>Clive Bolton
>>>Tauranga, New Zealand
>>>(Please respond via this newsgroup)
>>>
>>>Lyle Fairfield wrote in message <35e22...@news.cgocable.net>...
>>>>I'm trying to find the appropriate message in this thread to display my
>>>>immense ignorance of relationships and get a little help.
>>>>A relationship rule allows Access or Jet to create the relationship,
that
>>>>set of ordered pairs; for whatever reason it was decided to make that
rule
>>>>very restrictive, equality being its only operator, although we can
>>specify
>>>>that more than one pair of fields be equal. As an aside, I wonder why
this
>>>>restriction is necessary?
>>>>In any case, I am trying to think of what that 0 to many relationship
>>would
>>>>look like. While I can envision it as a theoretical model, with the
first
>>>>element in each pair being an empty set, and the second being one of the
>>>>records from the second table, I stumble on how Access or the Jet would
>>>>actually create the relationship, for it is restricted to using the
>>>equality
>>>>operator as the relationship rule. There will be no element of the empty
>>>>first set that Access or the Jet can use to find an equal element on the
>>>>second set.
>>>
Rebecca Riordan
Databases, it's downstairs at the moment, and I'm too lazy to go look <g>)
is the classic academic text.
HTH
- Rebecca.
Kurt Milam wrote in message <35E4C69D...@milamdesign.com>...
Rebecca Riordan
foreign key of the _many_ table. You can never have nulls in PKs, by
definition.
- Rebecca.
Clive Bolton wrote in message <6ru7bv$d5t$1...@news.wave.co.nz>...
>That's a absorbing exposition and fraught with points to pick up or on, but
>it emphasises my point: a 0 to many relationship means a primary table with
>a record with null as its primary key (or no existing records) related to
>many records in another table which also have null as the foreign key. One
>can type the words, but it's an empty set.
>
>0 to many means its a null value in the primary key. Or, no records matched
>to many records.
>
>1-to-some is what is being illustrated, and I use it quite extensively. It
>is probably what the original questioner had in mind, but it isn't what he
>asked.
>
>
>Clive Bolton
>Tauranga, New Zealand
>(Please respond via this newsgroup)
>
>Rebecca Riordan wrote in message <35e28...@news1.ibm.net>...
>>Okay, let me see if I can explain this....at least the way I understand
the
>>principles, which is not, of course, necessarily correct.
>>
Rebecca Riordan
Some people do use a "No Company", as I said, but I don't much care for this
as you have to go through a bunch of hoops to keep it from showing up in
forms and reports...particularly forms, where the users are going to
immediately want to delete it <g>.
- Rebecca.
Kurt Milam wrote in message <35E4C450...@milamdesign.com>...
> Thought I'd throw this out for your esteemed comments and opinions.
>
> Consider a real-world situation wherein ACME Corp sells products to
>corporate customers and individuals. In the pursuit of good normalization,
I'd
>probably set up a a company table with a people daughter. Since ACME
might
>sell to multiple people within one company, the relationship from company
to
>people would be one to many.
>
> 0 to many would exist as long as there were multiple individuals who
were
>not corporate customers, and therefore had no parent associated records in
the
>company table. Am I on the right track here? I have to say, I find data
>modeling extremely intruiging.
>
> Perhaps a single "No Company" record in the company table would be a
simple
>solution to the 0 to many situation in this instance - something of a
single
>"Protector of Orphaned Children," if you will.
>
>Just a though,
>Kurt
>
>Lyle Fairfield wrote:
>
>> I'm trying to find the appropriate message in this thread to display my
>> immense ignorance of relationships and get a little help.
>> I think of relationships as sets of ordered pairs. Each element of a pair
is
>> a set of fields, with the first set being a record from one table, and
the
>> second set being a record from the other table. Thus I think of only one
>> pointer, the pointer that points to some particular ordered pair.
>> (I used to think of the pointer in table two being moved in step with the
>> record pointer of table one, but this is a poor model for one to many, or
>> many to many. When we get to Lyle do we move the pointer to Daughter 1 or
to
>> Daughter 2?)
>> A relationship rule allows Access or Jet to create the relationship, that
>> set of ordered pairs; for whatever reason it was decided to make that
rule
>> very restrictive, equality being its only operator, although we can
specify
>> that more than one pair of fields be equal. As an aside, I wonder why
this
>> restriction is necessary?
>> In any case, I am trying to think of what that 0 to many relationship
would
>> look like. While I can envision it as a theoretical model, with the first
>> element in each pair being an empty set, and the second being one of the
>> records from the second table, I stumble on how Access or the Jet would
>> actually create the relationship, for it is restricted to using the
equality
>> operator as the relationship rule. There will be no element of the empty
>> first set that Access or the Jet can use to find an equal element on the
>> second set.
>> Perhaps, someone can help.
>>
>> Lyle Fairfield
>>
>> Rebecca Riordan wrote in message <35e13...@news1.ibm.net>...
>> >Kurt,
>> >
>> >Actually, 0:N is perfectly acceptable in ER. A null value in the
many-side
Clive Bolton
Clive Bolton
Tauranga, New Zealand
Rebecca Riordan wrote in message <35e51...@news1.ibm.net>...
Rebecca Riordan
- Rebecca
Clive Bolton wrote in message <6s3f3u$kj3$1...@news.wave.co.nz>...
Paolo F. Cantoni
Rebecca Riordan wrote in message <35e28...@news1.ibm.net>...
>Okay, let me see if I can explain this....at least the way I understand the
>principles, which is not, of course, necessarily correct.
>
>Remember, always, that data modelling is a _semantic_ process.
We have been Semantic Conceptual (Object/Data) Modellers since 1978... BTW:
See my signature... :-)
You have hit the nail on the head! I'd _really_ like to start an on-going
thread (or better still a newsgroup related to this subject!
Over these years we have watched people develop data models and developed
them ourselves. We have investigated database schemas that "work" and those
that don't... We have come to the conclusion that most database based
systems often don't work properly (or as well as they could) because the
conceptual models on which they are based are not valid for the domain of
application.
>This is why you can't just say, "right, this is how an address is
modelled", for
>instance, and go on with your life.
Absolutely - every model has a domain of applicability... We specialise in
developing "industrial strength" models - but this has come about by a lot
of blood and pain...
> It all depends on what the data means and how it's going to be used.
The problem is further compounded by who decides what it means? Again, here
we have long experience to draw on and the secret is to find definitions
which allow the multiple legitimately different views of the entity (class)
to each see the object correctly and stop invalid views.
One thing which is defined to get Semantic Conceptual Modellers to "see red"
is the statement (often heard in our group modelling sessions): "That's
only a matter of semantics".
It is _exactly_ a matter of semantics! Our experience has shown that
getting the semantics of the small number of basic conecpts in any domain
correct (at least for the domain of applicability) allows everything else
"to fall out in the wash".
>So, if you're going to work on a conceptual
>model of relationships, you're better off (IMNSHO), working from what
normal
>people call reality rather than this bizarreness that we computer people
>have created for ourselves.
Well, by now, you'll have guessed that I'm another (IMNSHO)... :-)
However, I'd like to put forward some points which differ (slightly) from
what you said above... I suspect, though, that if we continue the
discussion, we are probably in "violent agreement".
> I shall call the former the "real world" and
>hope that we can, for the moment, put aside otherwise-interesting
>epistimological debate. <g>
>
Firstly, the "real world" is variable (and in particular, as I alluded
above) depends on who you ask. We have found that by being "hard" about
entity and relationship definitions we can change people's perception of
"reality" for the better.
Also, to take up a point I think you are making... Over the years, when we
have found a business scenario which we can't model, we have upgraded the
modelling technology! (Once we've established that there is a new concept
to be modelled - and not a misunderstanding of an existing situation).
What we have then found is that when we get a correctly applicable
conceptual model - we can build the databases directly from them, and they
handle the business properly.
I'm not sure I understand the semantics of a 0:N relationship... My
understanding of the term relationship in ER modelling was: the union of two
uni-directional associations into a bidirectional relationship. Hence we
(should) talk about the parent-child relationship or the parent association
and child association. Associations can have [Min:max] cardinality where we
can talk of optionality and multiplicity, but relationships can't. Since,
by definition, if I am your child, you are my parent...
We (should) talk about 1:1 relationships, 1:N relationships, N:M
relationships.
We can talk about [0:1] [0:n] [1:n] [n:m] associations.
Are we talking the same language? Are we using the same syntax to generate
the same semantics?
See what I've (and by extension, you) been talking about? :-)
We need a consistency of language to get a meaningful dialog...
"There is no such thing as an inconsistently right system. Therefore: aim
for consistency, in the hope of getting rightness" - Paolo Cantoni (1990)
Consequently, before we get into the specifics of the particular examples
you mentioned in your original post, can we clarify that we mean the same
things when we use the same words?
Regardz, Paolo F. Cantoni Tel: +61-2-9498 5945
Director Fax: +61-2-9418 4402
-Semantica- Cell: +61-416 11 00 95
Suite 2, Charing House EMail: pcan...@semantica.com.au
45 Kendall Street Web: http://www.semantica.com.au
Pymble NSW 2073 AUSTRALIA
"Many problems turn out to be caused by invalid concepts.
Conceptual Modelling provides techniques for solving them..."
-Semantica- can help your organisation understand itself better
and thus operate more effectively and efficiently...
Clive Bolton
Here, Here!
Right on!
Clive Bolton
Tauranga, New Zealand
Paolo F. Cantoni wrote in message <6s61k3$p28$1...@the-fly.zip.com.au>...
TEmp...@qwest.net
without being able to pin it down (to "concretely conceptualize" it *G*). I'd
*really* like to hear further discussion. Do you have any sources I could
look up?
BB,
Hutch
In article <6s61k3$p28$1...@the-fly.zip.com.au>,
"Paolo F. Cantoni" <pcan...@semantica.com.au> wrote:
[snip]
> What we have then found is that when we get a correctly applicable
> conceptual model - we can build the databases directly from them, and they
> handle the business properly.
[snip]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Rebecca Riordan
1) There's a great deal of advertising in your remarks, Paolo. I don't
appreciate that, and I'm pretty sure other don't either. Your opinions will
stand or fall on their own merit here. I'll give you the benefit of the
doubt and assume it was accidental, or an attempt to establish your
credibility, but I really don't think its either necessary or appropriate.
2) I specifically tried to avoid epistemological discussions regarding what
does and does not constitute the "real world". They're great fun over a
bottle of wine, but I can't say that they contribute much to the topic at
hand.
3) The semantics of a 0:N relationship are more easily expressed as
N:0..."if the relationship exists, it must be defined on this domain,
however the relationship need not exist." As I have said repeatedly, a null
in a foreign key does not violate relational integrity.
- Rebecca.
Paolo F. Cantoni wrote in message <6s61k3$p28$1...@the-fly.zip.com.au>...
>It is _exactly_ a matter of semantics! Our experience has shown that
>getting the semantics of the small number of basic conecpts in any domain
>correct (at least for the domain of applicability) allows everything else
>"to fall out in the wash".
>
>>So, if you're going to work on a conceptual
>>model of relationships, you're better off (IMNSHO), working from what
>normal
>>people call reality rather than this bizarreness that we computer people
>>have created for ourselves.
>
>Well, by now, you'll have guessed that I'm another (IMNSHO)... :-)
>However, I'd like to put forward some points which differ (slightly) from
>what you said above... I suspect, though, that if we continue the
>discussion, we are probably in "violent agreement".
>
>> I shall call the former the "real world" and
>>hope that we can, for the moment, put aside otherwise-interesting
>>epistimological debate. <g>
>>
>
>
>Firstly, the "real world" is variable (and in particular, as I alluded
>above) depends on who you ask. We have found that by being "hard" about
>entity and relationship definitions we can change people's perception of
>"reality" for the better.
>
>Also, to take up a point I think you are making... Over the years, when we
>have found a business scenario which we can't model, we have upgraded the
>modelling technology! (Once we've established that there is a new concept
>to be modelled - and not a misunderstanding of an existing situation).
>
>What we have then found is that when we get a correctly applicable
>conceptual model - we can build the databases directly from them, and they
>handle the business properly.
>
Paolo F. Cantoni
TEmp...@qwest.net wrote in message <6sdl6u$jg1$1...@nnrp1.dejanews.com>...
>I think that this expresses a vague idea I've had for a number of years
>without being able to pin it down (to "concretely conceptualize" it *G*).
I'd
>*really* like to hear further discussion. Do you have any sources I could
>look up?
Sources for this type of stuff are few and far between. The article that
started me off twenty years ago was:
Abrial, Jean-Raymond
"Data Semantics"
in:
Klimbie, J. W. and Koffeman, K. L. (ed)
Data Base Management
Proceedings of the IFIP Working Conference on Data Base Management
001.6442 74-81831
North Holland 1974
ISBN 0 7204 2809 2
0 444 10704 5
This article was so potent, for me at least, that I haven't specifically
gone looking for more. Once you read this article and appreciate it, you
just read other stuff in a different way and improve your understanding of
Semantic Modelling that way. I'd be interested in any other books or
articles which deal specifically with this topic.
>
>BB,
>Hutch
>
We've found that a lot of it is the way you view "the world" and keeping to
the discipline. The rules are quite (well relatively) simple...
To repeat the phrase of J.R.'s, I used in my response to Rebecca:
To paraphrase the patron saint of Semantic Modellers: St. J.R. Abrial:
"The purpose of an information system should be to allow the user to ask the
same question of the system and of reality - AND GET THE SAME ANSWER!"
(emphasis mine).
If you don't believe that, then what's it for? The user is interested in
that. What they don't realise, is how hard it is to get to that state (same
question, same answer), principally because of the differences of
(uneducated - not in the negative sense of the word) views of "reality"
created by the different stakeholders in the situation.
Uneducated because, in general, people are not educated in data,
information, knowledge. How data are related to each other, how to turn
data into information etc.
Once they understand (or at least appreciate) the "laws of the information
universe" - which you break at your peril, we can get consensus on what we
are "looking at' and what it "means".
That's why I give the exhortation: "Aim for consistency, in the hope of
getting rightness"
Letz keep talking...
Regardz,
Paolo
Paolo F. Cantoni
Rebecca Riordan wrote in message <35ea6...@news1.ibm.net>...
>Paolo,
>
>1) There's a great deal of advertising in your remarks, Paolo. I don't
>appreciate that, and I'm pretty sure other don't either. Your opinions
will
>stand or fall on their own merit here. I'll give you the benefit of the
>doubt and assume it was accidental, or an attempt to establish your
>credibility, but I really don't think its either necessary or appropriate.
Ok, I'll try to refrain from "advertising"... You will, however - I hope,
allow me to accrete a degree of authority by being able to quote from our
experience where appropriate. :-)
I'll let the "opinions" stand or fall on their merit...
>2) I specifically tried to avoid epistemological discussions regarding
what
>does and does not constitute the "real world". They're great fun over a
>bottle of wine, but I can't say that they contribute much to the topic at
>hand.
We, I guess our experience has been different... However, because our
(-Semantica-'s) view is that most questions are a matterof semantics it does
still depend upon the defintion of "real world". For the sake of the on
going discussion (and at least BB thinks there shoudl be one). Lets define
the "real world" as "that part of the external environment which is the
subject of the data contained within the system".
If you agree with that definition, we can take the discussion from there.
If you don't then we should discuss what you'd propose as a definition of
the "real world". Since you've said you don't want to talk about the "real
world" - we need to at least know what NOT "real world" is... :-)
>3) The semantics of a 0:N relationship are more easily expressed as
>N:0..."if the relationship exists, it must be defined on this domain,
Then why isn't it? Why do we say 0:N should really be N:0 why don;t we make
it so? Why add confusion on top of error (oops my bias is showing...)?
Again, I thought that the cardinality description of a (binary) relationship
was a function of the maximum (not minimum values) of the two associations
which make it up...
Otherwise, in your 0:N or N:0 world, how do you distinguish between a
relationship created by: two 0:N associations and one which is 0:1 and the
other which is 1:N?
If you use the maximum cardinality of the associations to describe the
relationship the problem doesn't arise... Since there is no such thing as
[0:0] associations. (well actually, we have used them in the past for
defining certyain validation rules - but that's another story...)
BTW: if we have got our semantics mixed up and what you mean by
relationship, is what we mean by association - then we have progressed (and,
I hope, I have made my point!). If this is the case, what do you then call
the "thing" we call the relationship (the union of the two directed
associations).
>however the relationship need not exist." As I have said repeatedly, a
null
>in a foreign key does not violate relational integrity.
Agreed, a null in a foreign key doesn't necessarily violate relational
integrity. I've used them myself (sparingly) to achieve specific ends.
However, based on our semantically valid modelling techniques, we use them
much less than most other designers and so don't have the problem first
published by Date regarding the multiple semantics of "null".
BTW: do you accept the Macquarie Dictionary definition of epistemology: "
the theory of knowledge, esp. with regards to its methods and validation."?
I would have thought this was valid to the design of databases...
To paraphrase the patron saint of Semantic Modellers: St. J.R. Abrial:
"The purpose of an information system should be to allow the user to ask the
same question of the system and of reality - AND GET THE SAME ANSWER!"
(emphasis mine).
Letz keep talking...
Regardz,
Paolo
Paolo F. Cantoni
Rebecca Riordan wrote in message <35ea6...@news1.ibm.net>...
>Paolo,
>
>1) There's a great deal of advertising in your remarks, Paolo. I don't
>appreciate that, and I'm pretty sure other don't either. Your opinions
will
>stand or fall on their own merit here. I'll give you the benefit of the
>doubt and assume it was accidental, or an attempt to establish your
>credibility, but I really don't think its either necessary or appropriate.
Ok, I'll try to refrain from "advertising"... You will, however - I hope,
allow me to accrete a degree of authority by being able to quote from our
experience where appropriate. :-)
I'll let the "opinions" stand or fall on their merit...
>2) I specifically tried to avoid epistemological discussions regarding
what
>does and does not constitute the "real world". They're great fun over a
>bottle of wine, but I can't say that they contribute much to the topic at
>hand.
We, I guess our experience has been different... However, because our
(-Semantica-'s) view is that most questions are a matterof semantics it does
still depend upon the defintion of "real world". For the sake of the on
going discussion (and at least BB thinks there shoudl be one). Lets define
the "real world" as "that part of the external environment which is the
subject of the data contained within the system".
If you agree with that definition, we can take the discussion from there.
If you don't then we should discuss what you'd propose as a definition of
the "real world". Since you've said you don't want to talk about the "real
world" - we need to at least know what NOT "real world" is... :-)
>3) The semantics of a 0:N relationship are more easily expressed as
>N:0..."if the relationship exists, it must be defined on this domain,
Then why isn't it? Why do we say 0:N should really be N:0 why don;t we make
it so? Why add confusion on top of error (oops my bias is showing...)?
Again, I thought that the cardinality description of a (binary) relationship
was a function of the maximum (not minimum values) of the two associations
which make it up...
Otherwise, in your 0:N or N:0 world, how do you distinguish between a
relationship created by: two 0:N associations and one which is 0:1 and the
other which is 1:N?
If you use the maximum cardinality of the associations to describe the
relationship the problem doesn't arise... Since there is no such thing as
[0:0] associations. (well actually, we have used them in the past for
defining certyain validation rules - but that's another story...)
BTW: if we have got our semantics mixed up and what you mean by
relationship, is what we mean by association - then we have progressed (and,
I hope, I have made my point!). If this is the case, what do you then call
the "thing" we call the relationship (the union of the two directed
associations).
>however the relationship need not exist." As I have said repeatedly, a
null
>in a foreign key does not violate relational integrity.
Agreed, a null in a foreign key doesn't necessarily violate relational
Rebecca Riordan
Paolo F. Cantoni wrote in message <6sf9im$79u$1...@the-fly.zip.com.au>...
<snips>
>We, I guess our experience has been different... However, because our
>(-Semantica-'s) view is that most questions are a matterof semantics it
does
>still depend upon the defintion of "real world". For the sake of the on
>going discussion (and at least BB thinks there shoudl be one). Lets define
>the "real world" as "that part of the external environment which is the
>subject of the data contained within the system".
That's the problem space. It's an important distinction, since separating
the problem space from "everything else" largely establishes the scope of
the design exercise.
>
>If you agree with that definition, we can take the discussion from there.
>If you don't then we should discuss what you'd propose as a definition of
>the "real world". Since you've said you don't want to talk about the "real
>world" - we need to at least know what NOT "real world" is... :-)
I believe we can go ahead if we use "problem space".
>
>>3) The semantics of a 0:N relationship are more easily expressed as
>>N:0..."if the relationship exists, it must be defined on this domain,
>
>
>Then why isn't it? Why do we say 0:N should really be N:0 why don;t we
make
>it so? Why add confusion on top of error (oops my bias is showing...)?
It's a only matter of English syntax, not, in this instance, a question of
semantic error.
>
>Again, I thought that the cardinality description of a (binary)
relationship
>was a function of the maximum (not minimum values) of the two associations
>which make it up...
To the best of my knowledge, cardinality describes relations, not
relationships. Relationships do have degree, but that's the number of
participants (e.g., binary), not the count of instances, nor is it a measure
of the minimum or maximum number of instances.
>
>Otherwise, in your 0:N or N:0 world, how do you distinguish between a
>relationship created by: two 0:N associations and one which is 0:1 and the
>other which is 1:N?
>
>If you use the maximum cardinality of the associations to describe the
>relationship the problem doesn't arise... Since there is no such thing as
>[0:0] associations. (well actually, we have used them in the past for
>defining certyain validation rules - but that's another story...)
>
>
>BTW: if we have got our semantics mixed up and what you mean by
>relationship, is what we mean by association - then we have progressed
(and,
>I hope, I have made my point!). If this is the case, what do you then call
>the "thing" we call the relationship (the union of the two directed
>associations).
>
I have no idea what you mean by "association". The term is not part of the
formal relational model, and you seem to be making a distinction that eludes
me.
>>however the relationship need not exist." As I have said repeatedly, a
>null
>>in a foreign key does not violate relational integrity.
>
>Agreed, a null in a foreign key doesn't necessarily violate relational
>integrity. I've used them myself (sparingly) to achieve specific ends.
>However, based on our semantically valid modelling techniques, we use them
>much less than most other designers and so don't have the problem first
>published by Date regarding the multiple semantics of "null".
What is your point here?
>
>BTW: do you accept the Macquarie Dictionary definition of epistemology: "
>the theory of knowledge, esp. with regards to its methods and validation."?
>
>I would have thought this was valid to the design of databases...
>
>To paraphrase the patron saint of Semantic Modellers: St. J.R. Abrial:
>"The purpose of an information system should be to allow the user to ask
the
>same question of the system and of reality - AND GET THE SAME ANSWER!"
>(emphasis mine).
>
Yes, and I believe that being kind to strangers is a good thing, too, so
what?
- Rebecca.
Paolo F. Cantoni
Rebecca Riordan wrote in message <35f3f...@news1.ibm.net>...
>Comments interspersed....
>
>Paolo F. Cantoni wrote in message <6sf9im$79u$1...@the-fly.zip.com.au>...
><snips>
>>We, I guess our experience has been different... However, because our
>>(-Semantica-'s) view is that most questions are a matterof semantics it
>does
>>still depend upon the defintion of "real world". For the sake of the on
>>going discussion (and at least BB thinks there should be one). Lets
define
>>the "real world" as "that part of the external environment which is the
>>subject of the data contained within the system".
>
>That's the problem space. It's an important distinction, since separating
>the problem space from "everything else" largely establishes the scope of
>the design exercise.
Agreed...
>>If you agree with that definition, we can take the discussion from there.
>>If you don't then we should discuss what you'd propose as a definition of
>>the "real world". Since you've said you don't want to talk about the
"real
>>world" - we need to at least know what NOT "real world" is... :-)
>
>I believe we can go ahead if we use "problem space".
Done!
>>>3) The semantics of a 0:N relationship are more easily expressed as
>>>N:0..."if the relationship exists, it must be defined on this domain,
>>
>>Then why isn't it? Why do we say 0:N should really be N:0 why don't we
>make
>>it so? Why add confusion on top of error (oops my bias is showing...)?
>
>It's a only matter of English syntax, not, in this instance, a question of
>semantic error.
Yes, but to a large degree syntax is intimately concerned with semantics.
>>Again, I thought that the cardinality description of a (binary)
>relationship
>>was a function of the maximum (not minimum values) of the two associations
>>which make it up...
>
>To the best of my knowledge, cardinality describes relations, not
By relations - do you mean what I call associations? You distinguish
between relations and relationships. I distinguish between associations and
relationships. If you answer yes, can we call them associations? I believe
there's a more clearer distinction between the "glyphs" associations and
relationships than between relation and relationship?
>relationships. Relationships do have degree, but that's the number of
>participants (e.g., binary), not the count of instances, nor is it a
measure
>of the minimum or maximum number of instances.
Agreed, the degree of relationship is not the same as the cardinality. So
where does the cardinality come in? Are you saying that we should only talk
about the degree of the relationship? (Not flaming, just asking :-))
>>Otherwise, in your 0:N or N:0 world, how do you distinguish between a
>>relationship created by: two 0:N associations and one which is 0:1 and the
>>other which is 1:N?
>>
>>If you use the maximum cardinality of the associations to describe the
>>relationship the problem doesn't arise... Since there is no such thing as
>>[0:0] associations. (well actually, we have used them in the past for
>>defining certain validation rules - but that's another story...)
>>
>>BTW: if we have got our semantics mixed up and what you mean by
>>relationship, is what we mean by association - then we have progressed
>(and,
>>I hope, I have made my point!). If this is the case, what do you then
call
>>the "thing" we call the relationship (the union of the two directed
>>associations).
>
>I have no idea what you mean by "association". The term is not part of the
>formal relational model, and you seem to be making a distinction that
eludes
>me.
Has my response above clarified things? I agree that the word (glyph)
"association" is not part of the standard model, but we've found making a
clear distinction between the higher level concept of relationship (with
degree _and_ cardinality - as I defined previously) and the lower level
concept of the component binary associations (which have cardinality,
decomposing into optionality and multiplicity - but not degree since they
are all binary) is useful. It stops us accidentally naming one concept when
we mean the other (relations vs relationships).
>>>however the relationship need not exist." As I have said repeatedly, a
>>null
>>>in a foreign key does not violate relational integrity.
>>
>>Agreed, a null in a foreign key doesn't necessarily violate relational
>>integrity. I've used them myself (sparingly) to achieve specific ends.
>>However, based on our semantically valid modelling techniques, we use them
>>much less than most other designers and so don't have the problem first
>>published by Date regarding the multiple semantics of "null".
>
>What is your point here?
Well, that the fact that a foreign key doesn't exist in a specific situation
has different semantics (meaning) in any given situation.
Two different tables may have different meanings for a null key pointing to
the same base table.
There are other techniques - than the use of null - for achieving the
appropriate semantics in each case.
>>BTW: do you accept the Macquarie Dictionary definition of epistemology: "
>>the theory of knowledge, esp. with regards to its methods and
validation."?
>>
>>I would have thought this was valid to the design of databases...
>>
>>To paraphrase the patron saint of Semantic Modellers: St. J.R. Abrial:
>>"The purpose of an information system should be to allow the user to ask
>the
>>same question of the system and of reality - AND GET THE SAME ANSWER!"
>>(emphasis mine).
>>
>Yes, and I believe that being kind to strangers is a good thing, too, so
>what?
Just clarifying. Sometimes when I quote the above, I get people who
disagree! This tells me they're not on the same planet as me. (NOTE: I'm
NOT saying my planet is better than theirs... Just we aren't in the same
problem space!)
As an aside - I once asked the question in a presentation: "How quickly do
you want the wrong answer?" To which someone replied: "Next week!"
(Honest, AND he was serious!) Now, I'd always assumed this was a rhetorical
question - so I hadn't ever considered a reply to an affirmative response!
Thinking fast "on my feet"... I countered with: "Well, do you want it this
wrong, thus wrong or that wrong". (Gesticulating with different size gaps
between hands - as though sizing a fish)... To which the room erupted in
laughter! But the serious point, to reiterate, is to clarify if we are in
the same problem space.
I haven't reiterated my point about minimum and maximum cardinality of
relationships because I feel we need to settle on the words (like relation
vs association) before we can finalise that matter.
> - Rebecca.
Regardz,
Paolo
Rebecca Riordan
Paolo F. Cantoni wrote in message <6t4alc$bpe$1...@the-fly.zip.com.au>...
<snips>
>
>>>>3) The semantics of a 0:N relationship are more easily expressed as
>>>>N:0..."if the relationship exists, it must be defined on this domain,
>>>
>>>Then why isn't it? Why do we say 0:N should really be N:0 why don't we
>>make
>>>it so? Why add confusion on top of error (oops my bias is showing...)?
>>
>>It's a only matter of English syntax, not, in this instance, a question of
>>semantic error.
>
>
>Yes, but to a large degree syntax is intimately concerned with semantics.
Don't think the syntax issue is worth pursuing. I was just trying to avoid
the passive. Unless you're trying to make the point that if a model is
difficult to express in English there is some fault in the model. That's
preposterous.
>
>>>Again, I thought that the cardinality description of a (binary)
>>relationship
>>>was a function of the maximum (not minimum values) of the two
associations
>>>which make it up...
>>
>>To the best of my knowledge, cardinality describes relations, not
>
>
>By relations - do you mean what I call associations? You distinguish
>between relations and relationships. I distinguish between associations
and
>relationships. If you answer yes, can we call them associations? I
believe
>there's a more clearer distinction between the "glyphs" associations and
>relationships than between relation and relationship?
I still don't know what you mean by "association". A relation is what is
informally referred to as a "table"...a lot of people (erroneously) think
that the relational model is called that because you set up relationships
between tables. It's actually called relational because you model
relations. If you wish to argue relational theory, I don't see any reason
not to use the accepted terminology. BTW, glyphs are pictograms...are you
talking about a diagramming method here?
>
>>relationships. Relationships do have degree, but that's the number of
>>participants (e.g., binary), not the count of instances, nor is it a
>measure
>>of the minimum or maximum number of instances.
>
>Agreed, the degree of relationship is not the same as the cardinality. So
>where does the cardinality come in? Are you saying that we should only
talk
>about the degree of the relationship? (Not flaming, just asking :-))
Relationships do not have cardinality, that was my point.
<snips>
>Has my response above clarified things? I agree that the word (glyph)
>"association" is not part of the standard model, but we've found making a
>clear distinction between the higher level concept of relationship (with
>degree _and_ cardinality - as I defined previously)
You have not explained what you mean by the cardinality of a relationship.
>and the lower level
>concept of the component binary associations (which have cardinality,
>decomposing into optionality and multiplicity - but not degree since they
>are all binary) is useful. It stops us accidentally naming one concept
when
>we mean the other (relations vs relationships).
No, I don't accept this. Optionality and degree are both attributes of the
relationship. And not all relationships are binary.
<snips>
>Well, that the fact that a foreign key doesn't exist in a specific
situation
>has different semantics (meaning) in any given situation.
Well, of course it does. I would have thought that was self-evident.
>
>Two different tables may have different meanings for a null key pointing to
>the same base table.
Yes, so?
>
>There are other techniques - than the use of null - for achieving the
>appropriate semantics in each case.
Yes, I know there are. Doesn't change the validity of what I said.
>
>>Yes, and I believe that being kind to strangers is a good thing, too, so
>>what?
>
>Just clarifying. Sometimes when I quote the above, I get people who
>disagree! This tells me they're not on the same planet as me. (NOTE: I'm
>NOT saying my planet is better than theirs... Just we aren't in the same
>problem space!)
>
My apologies. My remark sounded snide, which was not my intention.
` - Rebecca.
SSpanke
observation.
However:
There are plenty of o to many relationships in the real world. Such as how zero
degrees of temperature would affect the viscosity of many liquids.
To display that relationship in Access though you have to have a one table with
a temperature field with a record with a value of zero and a many table with a
liquids field with the records of the various liquids.So thats a one to many
relationship not a zero to many relationship.
The only other options that I can think of for Access to be o to many would be
a one table with zero records relating to a many table or a one table with zero
fields relating to a many table. Both of those options wouldnt display
anything.
Rebecca Riordan
perfectly valid value (as in your temperature example), but to nothing. And
there are lots of real-world examples. Most of them are temporary
situations...customers who don't yet have sales reps, projects that don't
yet have managers, that kind of thing. But not always...some customers
never have sales reps, because they're a special case (the CEO's golfing
buddy...it would not do to list the CEO as a sales rep). The rule for 0:M
is "The foreign key on the many-side is optional, but if it exists, it must
exist in this table."
I suppose one could think of it more in terms of optionality than the degree
of the relationship, if that's easier or cleaner. The implementation
wouldn't change. When I draw data models, actually, I use what I think of
as the "crow's foot method"...hmmm...this is trivial to show, hard to
describe...you draw a line between the two entities. A bar (|) across the
line indicates "one", a crow's foot (<- or ->, sort of) indicates many, an
open circle indicates an optional relationship and a solid circle indicates
a mandatory one. So a zero to many might be modeled as o-| ----- o-|-<-
which reads as "zero or one to zero, one or many". But that's hard to
express in the x:y notation. I guess 0,1:0,1,M or something, but that seems
to ugly to be useful.
Clear as mud?
- Rebecca.
SSpanke wrote in message
<199809100516...@ladder01.news.aol.com>...
SSpanke
did make sense at the time though.Thank for your explanation.
Paolo F. Cantoni
Rebecca Riordan wrote in message <35f66...@news1.ibm.net>...
><snips>
>>
>>>>>3) The semantics of a 0:N relationship are more easily expressed as
>>>>>N:0..."if the relationship exists, it must be defined on this domain,
>>>>
>>>>Then why isn't it? Why do we say 0:N should really be N:0 why don't we
>>>make
>>>>it so? Why add confusion on top of error (oops my bias is showing...)?
>>>
>>>It's a only matter of English syntax, not, in this instance, a question
of
>>>semantic error.
>>
>>
>>Yes, but to a large degree syntax is intimately concerned with semantics.
>
>Don't think the syntax issue is worth pursuing. I was just trying to avoid
>the passive. Unless you're trying to make the point that if a model is
>difficult to express in English there is some fault in the model. That's
>preposterous.
Ok... we can drop it. Although, I have to admit that I do use the english
narrative form of our extended ERA models from our tool to help validate the
models we produce. If the english narrative looks wrong - generally we find
there's something wrong with the model (that is, it doesn't actually fit the
problem space).
>>>>Again, I thought that the cardinality description of a (binary)
>>>relationship
>>>>was a function of the maximum (not minimum values) of the two
>associations
>>>>which make it up...
>>>
>>>To the best of my knowledge, cardinality describes relations, not
>>
>>
>>By relations - do you mean what I call associations? You distinguish
>>between relations and relationships. I distinguish between associations
>and
>>relationships. If you answer yes, can we call them associations? I
>believe
>>there's a more clearer distinction between the "glyphs" associations and
>>relationships than between relation and relationship?
>
>
>I still don't know what you mean by "association". A relation is what is
>informally referred to as a "table"...a lot of people (erroneously) think
>that the relational model is called that because you set up relationships
>between tables. It's actually called relational because you model
>relations. If you wish to argue relational theory, I don't see any reason
>not to use the accepted terminology. BTW, glyphs are pictograms...are you
>talking about a diagramming method here?
Sorry, it slipped my mind you we talking the relational model (don't ask
why). I was using more data modelling related terms. Yes, of course
relations are tables. And relationships are the links between them. In the
relational model, the links are uni-directional since the target table
doesn't know it's being referenced and by definition, they have no
multiplicity since there is only one tuple in the other relation which can
be addressed at one time. I think we are using the word cardinality
differently. I use cardinality to meant the entire set of instances [0:1]
[1:n] [n:m] etc... I use optionality to mean wether the lower bound of the
cardinality is zero or not, and multiplicity to indicate wether the upper
bound of the cardinality is greater than one. Over the years I've found
this to be the most precice mechanism.
So in my "syntax" a relational relationship has a cardinality of either
[0:1] or [1:1] depending on whether it is optional or not.
I stand erected on "glyph". I thought it also extended to sequences of
characters - but i have been put right by you and a quick reference to my
dictionary. :-(
>>
>>>relationships. Relationships do have degree, but that's the number of
>>>participants (e.g., binary), not the count of instances, nor is it a
>>measure
>>>of the minimum or maximum number of instances.
>>
>>Agreed, the degree of relationship is not the same as the cardinality. So
>>where does the cardinality come in? Are you saying that we should only
>talk
>>about the degree of the relationship? (Not flaming, just asking :-))
>
>Relationships do not have cardinality, that was my point.
>
Accepted for the relational model. In the ERA model however, relationships
are said to have cardinality - we talk about one-to-one, one-to-many and
many-to-many relationships (each of which is a binary relationship -
composed of two interlinked uni-directional associations). So what you
meant by relation wasn't what I was meaning by associations! Mea culpa -
entirely!
><snips>
>
>>Has my response above clarified things? I agree that the word (glyph)
>>"association" is not part of the standard model, but we've found making a
>>clear distinction between the higher level concept of relationship (with
>>degree _and_ cardinality - as I defined previously)
>
>You have not explained what you mean by the cardinality of a relationship.
Hopefully, I now have - for ERA type relationships.
>>and the lower level
>>concept of the component binary associations (which have cardinality,
>>decomposing into optionality and multiplicity - but not degree since they
>>are all binary) is useful. It stops us accidentally naming one concept
>when
>>we mean the other (relations vs relationships).
>
>No, I don't accept this. Optionality and degree are both attributes of the
>relationship. And not all relationships are binary.
Yes, in general, this is true.
However, just to refresh my (now admitted rusty) knowledge of the relational
model in your original discussion with regard to "marriage", weren't you
talking about instances there? Weren't you therefore talking about
cardinality? (Again, just asking)
I do think however, you need to distinguish between rules which apply at an
arbitrary point in time and those which apply as a consequence of the
effluxion of time. For example, in those religions (or denominations) where
one can have serially monogamous marriages we have a different set of
relationships than in those which allow polygamy or polyandry and/or
divorce. Although all can be represented in a many-to-many relationship,
implemented as the appropriate intersector relation, the count of instances
which can exist at one time for a given point in time is different. Because
the semantics of the various problem spaces are different.
We often find people mix the two (point in time and effluxion of time)up and
then wonder why the model doesn't deliver the right view of the problem
space.
Regardz,
Paolo
Arvin Meyer
1967, did not refer to relationships between tables, but to relational set
theory in mathematics.
But Null is not nothing, Null is an unknown and never = anything, even
another Null. You can set a value to Null, but you can't retrieve a Null,
only be aware of its existence.
OTOH, 0 (zero) has a value. If memory serves me right (its been a LONG time)
you can build certain sets with 0.
-----
Arvin Meyer
ons...@esinet.net
Rick wrote in message <0U_K1.59$Zc2.5...@NewsRead.Toronto.iSTAR.net>...
>Hi,
>
>Has anyone noticed that relational algebra breaks down here? I think this
is
>important.
>This is the other side of the NULL Argument coin,
>Nothing with anything is always nothing.
>In a nutshell; -If you have a 0-n relationship then you have an error in
>your model.
>
>Just my 2c
>
>r.
Rick
Rebecca Riordan
that's true, but that's not a failure in the algebra, that's just the way it
works, and it's a perfectly sensible result.
I think there's this tendency to reject nulls because they confuse people,
and that's not (IMHO) a compelling argument. Zeros confused people too for
several hundred years, but they're extraordinarily useful things.
Three-valued logic is more complex than two-valued logic, but it's not
_that_ complicated. I mean, I figured it out, and I figure if I can do it,
it can be done, and if it can be done, anybody can do it.
- Rebecca.
Rick wrote in message <0U_K1.59$Zc2.5...@NewsRead.Toronto.iSTAR.net>...
SSpanke
If A and B are two subsets of a set S, the elements found in A or in B or in
both form a subset of S called the union of A and B, written A È B. The
elements common to A and B form a subset of S called the intersection of A and
B, written A Ç B. If A and B have no elements in common, the intersection is
empty; it is convenient, however, to think of the intersection as a set,
designated by Æ and called the empty, or null, set.
Allan Morstein
see it as a value of nothing, which, at least in my mind, is different). If
you were to add something to the lack of a value you would still lack a
value. Following this through, a lack of a value would not be equal to a
lack of a value because neither one has a value and therefore cannot be
evaluated. This always seemed intuitively correct to me, but that may just
be my warped intuition speaking.
Rebecca Riordan wrote in message <35fcd...@news1.ibm.net>...
>I don't agree. The result of an inner join in a 0:n relationship is null,
>that's true, but that's not a failure in the algebra, that's just the way
it
>works, and it's a perfectly sensible result.
>
>I think there's this tendency to reject nulls because they confuse people,
>and that's not (IMHO) a compelling argument. Zeros confused people too for
>several hundred years, but they're extraordinarily useful things.
>Three-valued logic is more complex than two-valued logic, but it's not
>_that_ complicated. I mean, I figured it out, and I figure if I can do it,
>it can be done, and if it can be done, anybody can do it.
>Rick wrote in message <0U_K1.59$Zc2.5...@NewsRead.Toronto.iSTAR.net>...
Rebecca Riordan
Null vs. Nothing? Yeah, they're definitely different. I tend to think of
Null as "unknown" or "undefined" which is clearly different from
"non-existent", which _is_ a known value.
- Rebecca.
Allan Morstein wrote in message <6tjhbs$bsq$1...@hops.adnc.com>...
Joe We are Borg Foster
> Hi,
> Has anyone noticed that relational algebra breaks down here? I think this is
> important.
How so? By using the relational union and subtraction operations,
you can do the same tricks you can do using Access' outer joins.
> This is the other side of the NULL Argument coin,
> Nothing with anything is always nothing.
> In a nutshell; -If you have a 0-n relationship then you have an error in
> your model.
Assuming this is true, how then should such models be corrected?
--
Joe Foster <mailto:jfo...@ricochet.net> Spam is irrelevant. Assimilate this:
<ftp://ftp.microsoft.com/softlib/index.txt> Microsoft's master patch list
<ftp://ftp.microsoft.com/softlib/mslfiles/> MS I got yer patch right here!
<http://www.microsoft.com/msdn/> MS Knowledge Base & more
<http://www.dejanews.com/home_ps.shtml> Usenet search and archival engine
<http://www.altavista.digital.com> WWW *and* Usenet search engine
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
anjani...@gmail.com
The condition is
"An orchestra consists of different musicians; each musician services to only one orchestra".
How to find
"minimum and maximum cardinalities, degree and optional/mandatory"
Access Developer
zero to many relationship.
--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
<anjani...@gmail.com> wrote in message
news:f149a1f4-9b86-4b9c...@googlegroups.com...
David Hare-Scott
than real database work. As stated I don't think there is an answer to the
question. Which field(s) of which table are you interested in? I suppose
'degree' means degree of cardinality, but of what? Is there some data
supplied with the question or is this all theory?
D
Phil
many different orchestras. A 0 to many relationship is not a relationship,
it's 2 separate unrelated tables. This sounds like some sort of exam question
that you have misunderstood. Phil
Douglas J Steele
one-to-many relationships. The reason for the zero is to indicate that it's
acceptable for there to be a parent entity that has no children: one-to-many
would mean that you cannot have parent entities unless there are associated
children.
For instance, if a company stores details in the Customer table for people
who have never placed orders, that would be a zero-to-many relationship.
"Access Developer" wrote in message
news:adcld7...@mid.individual.net...
Joan Wild
Hate to argue, Doug, but I believe your examples would be 1 to zero. 1
Customer with zero orders, or any parent entity with 0 children.
The 'zero' in this case is included in 'many'.
To me, a zero to many relationship says orphan records in the child
table (a child with no parent record).
Phil
> Hate to argue, Larry, but I've often heard zero-to-many used to describe
> one-to-many relationships. The reason for the zero is to indicate that
> it's acceptable for there to be a parent entity that has no children:
> one-to-many would mean that you cannot have parent entities unless there
> are associated children.
>
> For instance, if a company stores details in the Customer table for people
> who have never placed orders, that would be a zero-to-many relationship.
>
> "Access Developer" wrote in message
> news:adcld7...@mid.individual.net...
>
> Hunh? Did you mean one-to-many or many-to-many or one-to-one -- there's no
> zero to many relationship.
>
wrong. In your example, the implication is that as soon as a customer places
an order, the relationship changes. Don't think so What does your
zero-to-many look lihe in the relationships window?
Phil
Access Developer
some child records without a parent record.
I've heard a lot of inaccurate descriptions in the database business (and
general computing, too). Some think I tend to be a bit pedantic in
disagreeing with those, but that's the way it is.
--
Larry Linson
Microsoft Office Access MVP
Co-Author, Microsoft Access Small Business Solutions, Wiley 2010
news:k4rv3s$fbo$1...@dont-email.me...
Douglas J Steele
I'm drawing a blank: it was over 25 years ago, when I first started getting
into database design, when I recall that terminology being used!
It may well have been a case that it was used to designate cases which
didn't require RI (although I can't think of a single case where that should
be legitimate!)
Good to hear from you, btw.
"Joan Wild" wrote in message news:xn0i41u7q...@nntp.aioe.org...