Relationship Lines Maintained Between Attributes

Hello,
Firstly, great product, thanks guys. I'm currently trialling it, and so far, very impressed.

Although this "Architect Suggestion" has been suggested before in various different ways, I would just like to highlight it again to show further interest.

I would be keen to see the relationship lines maintained between the individual PK and FK attributes as opposed to just the entities.
This is something I have always done as standard, as it makes 'reading' the diagrams much easier. A particular example of this is when printing the diagram for documentation purposes. Although, in theory, the FK will have the name of the PK, this is realistically not always the case, and having the relationship go directly between the related attributes I personally just find much easier.
It would be interesting to here other peoples thoughts on this, particularly how they would draw it, say if they had 'old school' pen and paper as opposed to software - would you draw the relationships between attributes or just the higher level entities? - personally, I've always drawn between attributes, but this certainly doesn't make it right (or standard)

Cheers

Hi Andy. Thanks for taking the time to post your suggestion!

You're right, this is becoming a frequently requested feature. I'm personally still not sold on the idea, for the following reasons:

It's not a feature of any standard ER modeling language I know of

It's unclear what to do with composite keys.. there is no guarantee the FK columns are grouped together in the child table

It means relationship lines can only meet tables at their left and right edges; this greatly limits your flexibility in diagram layout. I expect the diagram would become really hard to read due to all the crossing lines

Despite all that, I do recognise and respect that you are not the first Architect user to come forward with this request. What I'll ask of you now is to do some research and build a case for this feature request. Come up with anything you like, but here's what I'd be looking for if I were in your shoes:

Examples of existing ER modeling tools that draw diagrams this way

Pointers to one or more diagram language specifications which include this feature (bonus points if the language is an open standard rather than the property of a software vendor; no points if important aspects of the modeling language you find are patented)

Examples of genuinely complex data model diagrams where the relationship lines connect beside the attributes they involve

As always, I would really appreciate input from anyone else listening in on this topic.

-Jonathan

PS: To answer your question about how I personally draw data model diagrams with pen-and-paper, I vaguely try to put parent tables higher on the page than their children. Hence, I usually have my relationship lines connecting bottoms and tops of boxes rather than sides. But it's hard to shift things around on paper, so sooner or later my hand-drawn diagrams turn to spaghetti.

This message was edited 6 times. Last update was at 2008-03-12 18:46:34

Hi Andy,

Thanks for the feedback!

I can understand why someone would like this feature. If I were doing this on paper, I would imagine myself maintaining the lines between attributes if only so that I remember which attributes the relationship refers to. (Since on paper, you wouldn't have Power*Architect's handy column highlighting when selecting a relationship

) However, Jonathan does bring up a good point with the composite keys, and I'm not sure how I would do that on paper (or at least not in any standard way).

Also, since the end points of the relationship lines are fixed, it limits your flexibility in placement of other tables, columns, tables, and relationships if you want to keep your diagram clean and readable, (and not 'spaghetti', as Jonathan puts it).

Perhaps this is something to turn into a user preference? (Like the rectilinear vs direct lines option)

Hi Jeff/Jonathan,

Firstly, thanks to you both for taking the time to respond.

It's very interesting to read your thoughts on this and see differences in the industry. Since day 1 at university, I have always joined entities by their related attributes, hence to me this is the norm (or dare I say, standard) - I have worked like this for as long as I've worked with databases, so obviously it becomes very standard from my point of view.

Your comments on composite keys are interesting as well. (Before I go on, I think it important to clarify what I mean by composite key, as I have recently seen people approaching this subject slightly different, so for terms of clarity, I mean - 2 or more attributes of a table that when referenced together, uniquely identify a record in a table. Please don't think I'm trying to tell you what you already know, it's just for clarity in the posting)

In terms of diagrammatically representing a composite key, I simply just show the relationships between the parent attribute(s) and child attribute(s), so in terms of your software, the composite key would be above the line (as they are now), but the relationship shown would be multiple, (again, as they are now), but just maintaining the relationship at attribute level instead of entity level. I think in terms of grouping the FK that make a CK together, this would happen anyway because you would have ticked in pk as your option when defining that field - (obviously please correct me if I'm wrong as I am very new to the software).

Regarding reducing your location of relationships to the left and right edge only - I can see this is restrictive from a software point of view. If drawing manually, I would normally put a right angle in the relationship as soon as possible if joining a table below/above, but obviously this a quite a change to how the relationship code works in the software.

In terms of "spaghetti", again, I suppose it comes from history with me. From my early learnings in this subject, the rules where no crossed lines, so you just get used to drawings the table structures in a way not to cross lines, albeit, sometimes with long relationship links. If lines do have to cross, then a "bridge" semi circle seems to be the norm.

Anyway, I'll take a look at your suggestions and see if I can build some form of case as you requested - I won't be able to respond quite as quick as you guys but I'll get onto it asap.

One last thought, that may be quick and a simple short term solution, would be to display the relationship name in a label next to the relationship (as a user option), so with good naming of the relationship, e.g. with related attribute names, you could see the attributes referenced by the relationship by reading the label contents (relationship name), useful when you print the diagrams. What do you think about this?

Cheers once again for your time

This message was edited 1 time. Last update was at 2008-03-13 17:38:05

Hi again Andy.

Since day 1 at university, I have always joined entities by their related attributes, hence to me this is the norm (or dare I say, standard) - I have worked like this for as long as I've worked with databases, so obviously it becomes very standard from my point of view.

That's fine, but standards don't exist from a point of view. They're painstakingly worked out by committees, then put into writing. Further, it may be fair to argue that such an exercise only becomes a standard when it's been ratified by a standards organization. "What I did at university," although comfortable and familiar to you, is a long way from becoming a well-documented, generally applicable, ratified standard!

I can name three standards that relate to Entity-Relationship data modeling:

IDEF1X is conveniently in the public domain, since it was developed under contract to the United States Air Force. Get the spec here: http://www.idef.com/pdf/Idef1x.pdf

IE (Information Engineering) IE appears to be a whole theory of life, the universe, and everything... and one small part of it is an ER diagram language. I'm not sure if it's a ratified standard, but it is complete and well-documented. The books that define IE concepts are listed at the bottom of this page. The Power*Architect loosely follows ("is inspired by?") the IE notation. Unfortunately, the contents of the IE books aren't available on the web. Our local public library, although fairly large (99 branches), only has one copy of these books, in the reference library (not for borrowing).

UML, specified by the OMG, has been applied to ER diagramming. There was a discussion about UML for ER on this forum in the past. Although OMG standards appear to be available on the web, I was unable to actually find the document that specifies how to apply UML to ER diagramming. If you can find it, that would be excellent!

In terms of diagrammatically representing a composite key, I simply just show the relationships between the parent attribute(s) and child attribute(s), so in terms of your software, the composite key would be above the line (as they are now), but the relationship shown would be multiple, (again, as they are now), but just maintaining the relationship at attribute level instead of entity level. I think in terms of grouping the FK that make a CK together, this would happen anyway because you would have ticked in pk as your option when defining that field - (obviously please correct me if I'm wrong as I am very new to the software).

Well yes, the primary key columns of a table are always grouped together because everything above the line is in the primary key. I was talking about where those columns end up when imported into the child table. Sometimes it is impossible to cluster them all together, especially when some of them are in the child table's PK and others are not.

Another thought running through my head: If the diagram shows relationships between individual attributes rather than between entities, isn't it then an attribute-relationship diagram?

In any case, I really appreciate your continued interest, and I'm looking forward to the fruits of your research.

-Jonathan