Re: Relations, Relationships

[Ken Pugh]

There seems to be a combination of terminology (and remember I'm not
a database expert) in what we're discussing, which makes it somewhat
confusing.

The term "relation" in the relational model, which is a table (a set
of tuples).

The term "relationship" from Entity-Relationship Diagrams, which is
an association between two entities. This is often referred to as a
"relation" in common ER discussion.

So in the Car / Owner / CarOwner example, one could denote this as:

Relationsl model
Three relations (Car, Owner, CarOwner)

Entity-relationship model
Two entities (Car, Owner)
One relationship (CarOwner)

Object model
Two objects (Car, Owner)
One association (CarOwner)

Now as I read general discussions on SQL, one would probably refer to
the situation as:

Two tables (Car, Owner)
CarOwner (also a table) has two foreign key relationships

So with the example, you can describe it as three relations or one
relationship or two relationships.

Now I'm not sure what you mean by the statement:

"relations" between entities exists in a relational database

because I'm not sure what you mean by "relations". Are you talking
about relational database relations? Could you give an example of
what "relations" exist because of the structure (in the Car, Owner,
CarOwner example)? If there were no CarOwner table, are those
"relations" still present?

Thanks.

Ken

>Date: Sun, Apr 2 2006 10:36 am
>From: "remco...@gmail.com"
>
>"Is this what you guys are talking about when you say uni and bi? ". No
>it is not.
>First your relations are not the same as my relations. I see 3
>relations here Car Owner and CarOwner you can make even more relations
>by joining them. Second if you model it like Scott proposes then there
>is no difference the relation still exists even if you do not define it
>or know that it exists you can device a algorithm to find them. The
>difference between a relational database and objects is that the
>"relations" between entities exists in a relational database because of
>the structure of the data and by objects you have to make it explicit
>not making it explicit does not mean it does not exist.

[remco...@gmail.com]

(i am also not e database expert)I meant probably relationship. But I
do not see a logical difference everything that connects elements of
sets is a relation in the mathematical sense. I recognize the
terminology you are describing and i agree but the relationship of the
ER model you can always implement as a table as you can model any
relationship/relation as tuples in math. But what is the kind of
unidirectional relationship in the real world Scott revert to ??

[remco...@gmail.com]

I meant to say somthing like by joining and projection and ... you can
create other valid relations/relationships in your model if you define
them explicitly or not . (again i am not a database expert and not a
native English speaker but I Am not stupid as Scott seems to think)

[Tim]

Remco,

I don't think Scott thinks you are stupid. I think he simply does
not like it when somebody points out some shortcomings in his writings
and he cannot explain it satisfactorily

Then he follows the usual path of pointing to more of his writings
which were the cause of disagreement in the first place! And if you
still do not acept his viewpoint, he then either discontinues the
conversation or says something like " I have X million visitors to my
site, so I must be right."

Of course, using his logic, the possibly millions of visitors who
visited the pictures exposing US torturing Iraqis at Abu Grhaib would
justify the torture itself, because, you see, millions of people wanted
to see it! If the US had not tortured prisoners how could the millions
have seen what they wanted to see? Therefore, the act of torture must
be right!

Tim

[Scott W. Ambler]

At 02:53 PM 4/9/2006, Remco wrote:

>(i am also not e database expert)I meant probably relationship. But I
>do not see a logical difference everything that connects elements of
>sets is a relation in the mathematical sense. I recognize the
>terminology you are describing and i agree but the relationship of the
>ER model you can always implement as a table as you can model any
>relationship/relation as tuples in math. But what is the kind of
>unidirectional relationship in the real world Scott revert to ??

Restricting the conversation to the real world, and not to
mathematical and/or relational theory, here are some examples of
uni-directional associations:

1. Management maintains a private list of people of their "up and
coming stars", but those people don't know that they are on the list
2. A person drew someone else's name from a hat and must now buy them
a "Secret Santa" gift. The buyer knows who the receiver is, but the
receiver doesn't know who is giving them the gift.
3. A CIA agent is assigned to monitor five suspected foreign agents,
but these people do not know they are being monitored.

In all three cases one entity has knowledge of another entity, but
not vice versa, making them uni-directional associations. You can
read about uni-directional associations in the UML literature
published by the OMG if you want to find out more about them.

At 03:15 PM 4/9/2006, Remco wrote:

>I meant to say somthing like by joining and projection and ... you can
>create other valid relations/relationships in your model if you define
>them explicitly or not . (again i am not a database expert and not a
>native English speaker but I Am not stupid as Scott seems to think)

I never said that you were stupid, although other people who have
posted messages on this list have unfortunately used that terminology.

- Scott

====================================================
Scott W. Ambler :-)
Senior Consultant, Ambysoft Inc.
www.ambysoft.com/scottAmbler.html

Refactoring Databases: Evolutionary Database Design
(www.ambysoft.com/books/refactoringDatabases.html) is now available!

[markcol...@gmail.com]

Tim

Please stop doing this - in particular:

>Of course, using his logic, the possibly millions of visitors who
>visited the pictures exposing US torturing Iraqis at Abu Grhaib would
>justify the torture itself, because, you see, millions of people wanted
>to see it! If the US had not tortured prisoners how could the millions
>have seen what they wanted to see? Therefore, the act of torture must
>be right!

is a clear attempt to associate someone in people's minds with
torture. It's completely inappropriate and highly unjustified. This is
a technical discussion group, not a place for personal vendettas (or
political discussion for that matter).

Personal attacks are not acceptible in this group. Technical argument
or the merits of this or that approach, the benefits versus costs of
different choices are more than welcome. Please, let's have an
intelligent - non personal - discussion.

Mark.

--
Mark Collins-Cope
Ratio - Training, Consultancy and Development
--------------------------------------------------------------------------
+44 (0)20 8579 7900 or :+44 (0)777 163 6882
Author: "Agile Development with Iconix Process"
Editor: www.ratio.co.uk/objectiveview.html
---------------------------------------------------------------------------
recursion is - of course - a form of magic

[Rebecca Wirfs-Brock]

At 01:03 PM 4/10/2006, Scott W. Ambler wrote:

>Restricting the conversation to the real world, and not to
>mathematical and/or relational theory, here are some examples of
>uni-directional associations:
>
>1. Management maintains a private list of people of their "up and
>coming stars", but those people don't know that they are on the list
>2. A person drew someone else's name from a hat and must now buy them
>a "Secret Santa" gift. The buyer knows who the receiver is, but the
>receiver doesn't know who is giving them the gift.
>3. A CIA agent is assigned to monitor five suspected foreign agents,
>but these people do not know they are being monitored.
>
>In all three cases one entity has knowledge of another entity, but
>not vice versa, making them uni-directional associations. You can
>read about uni-directional associations in the UML literature
>published by the OMG if you want to find out more about them.

So I have one observation I'd like to toss into the discussion. Just
because in the real world these are uni-directional associations, it
may or may not mean that that should be preserved in our software
models. For example, we may want to ask the software who is X's
secret santa (so we can send a reminder to that secret santa to
remember to get x a present).....the point I am trying to make is
this, I think a good model supports the types of navigations that are
needed to answer questions/do the work of the software. So whether
these physical relation restrictions should be preserved in an
implementation is the right question to be asking.....

An implementation need not be equivalent to a conceptual model for
this very reason. As a behaviorialist, that's how I always look at a
design--what does it need to incorporate in order to support the
desired system behavior?

Regards,
Rebecca

Rebecca Wirfs-Brock President, Wirfs-Brock Associates
website: www.wirfs-brock.com blog:
http://www.wirfs-brock.com/rebeccasblog.html
cell: 503-313-4978 phone: 503-625-9529
reb...@wirfs-brock.com fax: 503-625-1969

"A man should learn to detect and watch that gleam of light which
flashes across his mind from within, more than the lustre of the
firmament of bards and sages. Yet he dismisses without notice his
thought, because it is his." --Ralph Waldo Emerson

Don't you want to take responsibility for your design?

[markcol...@gmail.com]

Chaps,

I think I'm with Rebecca here. Everything is subordinate to meeting
the stated (functional) requirements the system has to implement.

But Scott is right there are times when in OO terms you would only
want a uni-directional relationship.

There are other reasons why you might want uni-directional
relationships - for example, for engineering purposes - to maintain a
dependency in one direction and not in both directions for two modules
/ packages (reducing coupling).

e.g. package A ----------> package B, but package B -------/-------> package A.

Package/module level dependencies are an abstraction (summary) of the
dependencies between the classes within the modules. So A ----------->
B implies a class in A -------------> a class in B. In order to ensure
that B ---------/---------->A, no class in B may depend on a class in
A.

One "issue" (no offence intended) with relational models (or with OO
models, if you like) is that if you have A ----------------------> * B
(class A is dependent on many class Bs) in OO terms, in relational
terms, B ends up with an Fkey reference to A.

Which means in the database, B "knows" about A, but in the code, A
"knows" about B. There are ways round this, but it is indicative of
the so called OO/RDBMS mismatch.

Mark.

[Scott W. Ambler]

At 07:12 PM 4/11/2006, Rebecca wrote:
>So I have one observation I'd like to toss into the discussion. Just
>because in the real world these are uni-directional associations, it
>may or may not mean that that should be preserved in our software
>models. For example, we may want to ask the software who is X's
>secret santa (so we can send a reminder to that secret santa to
>remember to get x a present).....the point I am trying to make is
>this, I think a good model supports the types of navigations that are
>needed to answer questions/do the work of the software. So whether
>these physical relation restrictions should be preserved in an
>implementation is the right question to be asking.....
>
>An implementation need not be equivalent to a conceptual model for
>this very reason. As a behaviorialist, that's how I always look at a
>design--what does it need to incorporate in order to support the
>desired system behavior?

I agree. I prefer to implement the requirements on a just-in-time
(JIT) basis. So, if I have an actual need to traverse a
uni-directional relationship in the opposite direction then I'll
implement at that time. To do this, I'll change the model (if I'm
maintaining one) appropriately, update my tests (if required), and
write the appropriate code. As long as you can deploy easily, this
JIT approach seems to work well. If you can't deploy easily, then
overbuilding your software ahead of the actual requirement coming in
starts to make more sense. As always, you need to do the right thing
for the situation.

[Scott W. Ambler]

At 11:22 AM 4/12/2006, Mark wrote:

><snip>

>Which means in the database, B "knows" about A, but in the code, A
>"knows" about B. There are ways round this, but it is indicative of
>the so called OO/RDBMS mismatch.

Which, if memory serves, was exactly the original point that I had
made which started this conversation in the first place. See
http://www.agiledata.org/essays/impedanceMismatch.html for a detailed
discussion on the subject.