Rebecca Riordan wrote in message <35f660f...@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.
I noticed that Rick, relational database theory, as proposed by Codd in 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.569...@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.
>SSpanke wrote in message ><1998091005163700.BAA17...@ladder01.news.aol.com>... >>I'm sure the level of thinking in this thread is much more profound than >this >>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.
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.
>I'm sure the level of thinking in this thread is much more profound than this >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.
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.569...@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.
>SSpanke wrote in message ><1998091005163700.BAA17...@ladder01.news.aol.com>... >>I'm sure the level of thinking in this thread is much more profound than >this >>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.
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.
I've always thought of null as the absence of a value(most people seem to 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 <35fcdcd...@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.569...@NewsRead.Toronto.iSTAR.net>... >>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.
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.
Allan Morstein wrote in message <6tjhbs$bs...@hops.adnc.com>... >I've always thought of null as the absence of a value(most people seem to >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 <35fcdcd...@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.569...@NewsRead.Toronto.iSTAR.net>... >>>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.
In article <0U_K1.59$Zc2.569...@NewsRead.Toronto.iSTAR.net>, R...@RFDSystems.REMOVE.com (Rick) writes: > 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?
anjanitec4...@gmail.com wrote:
> Hi,I have two tables which are 1) orchestra and 2) musician
> 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"
This sounds like part of a term paper in SQL and relational theory rather 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?
> anjanitec4...@gmail.com wrote:
>> Hi,I have two tables which are 1) orchestra and 2) musician
>> 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"
> This sounds like part of a term paper in SQL and relational theory rather
> 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
Why can a musician only play for 1 orchestra. Particularly soloists play for
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
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.
> 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.
> 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.
> Hunh? Did you mean one-to-many or many-to-many or one-to-one -- there's no
> zero to many relationship.
I'm with Joan here bur with great trepidation, as Larry is not normally
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?
I wouldn't care to start an argument, but to me, "zero to many" would imply 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
> 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.
Yeah, you're probably right, Joan. I'm trying to think of an example, but 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!)
> 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.
