Here's a website I stmbled across:

http://www.islandnet.com/~tmc/html/a...s/datamodl.htm

Note that, at the start of the introduction, the author says that analysis
is the most important part of any project. That's rather different from the
impression I've gotten in response to my topic on "what is analysis".

By the way, I don't like the author's dialect of ER. In particular, his
topic on "resolving many-to-many relationships" is, I believe extraneous
to ER. His reification of a "watering" reminds me of the term "association
entity" that someone wrote in reposnse to me a few days ago.

In analysis, there is nothing to resolve in a many-to-many relationship.
You only have to resolve it when you are designing relational tables or
relvars. So the resolution is a feature of the solution, not a feature of
the problem to be solved. And ER diagrams have no problem diagramming
many-to-many relationships: just put crow's feet at both end of the
relationship line.

ER diagrams are a little awkward at diagramming n-ary relationships, but a
diamond representing the relationship is good enough, even if a little
cluttered.

Aside to Cimode: you are trying to give ER a fair chance. But if you
indeed do not separate analysis from design, and if I am correct the ER is
useful in analysis but not in design, then it seems logical that you will
eventually conclude that ER is of no value to you.

OOPS, I goofed. What meant to say under resolving a many-to-many
relationship was the reification of "treatment", rather than "watering".

Drat the loss of short term memory!

"David Cressey" <cressey73 (AT) verizon (DOT) net> wrote

On Dec 4, 9:34 am, "David Cressey" <cresse... (AT) verizon (DOT) net> wrote:
It looks like the author is using the Barker notation for his
diagrams. I like
to use the same for business modeling due to the accessibility of the
notation to the business users. I find, however, that the diagrams
definitely
require accompanying text for full elucidation of the business rules
at play.

An example can be found in an article of mine (the first in a 5-part
series)
that was just published on a product-specific "tips and tricks"
website:
http://www.sqlservercentral.com/arti...odeling/61526/

Note that for this example, I am defering the "resolution" of the many-
to-many
relationship to the logical model. In practice, I like to think about
the so-called
"associating entity" to check whether it is or is not something that
should
be surfaced to the subject matter experts.

Behind the scenes, the design is all predicates documented in
mathematical
notation, but I'm the only one that sees that version.

TroyK

Quoth David Cressey:
Well, that depends on what analysis is. It seems this guy thinks it's
the same as data modeling, which in turn is the same as developing a
graphical representation of the client's needs and processes. Is it?
Furthermore, you could interpret Marshall's and my response as "we don't
do analysis, we just start coding", but I don't think that's what we
mean. Myself, I'm skeptical of presenting analysis as a very separate,
distinct kind of activity, defined by the kinds of artifacts it
produces, i.e. "pretty pictures" to use Bob's term.

But I digress. This was what I meant to respond to:

Both yes and no. Reifying relationships can be helpful, but /not/
because "Many-to-many relationships cannot be directly converted into
database tables and relationships". The point is rather to make it
easier to discover their properties---their attributes, mainly, but
potentially also other things, e.g. constraints. When I discover a
many-to-many-relationship, I usually make it a box, with a name, and ask
if there is anything else we want to be able to say about this thing.
Often, there is. If there isn't, I can demote it to a line again.

This mainly applies to many-to-many-relationships, because business
rules / attributes / constraints regarding a one-to-many-relationship
are often better relegated to the entity on the many-side (though not
always, of course). It has little to do with the implementation (or
design?) of many-to-many-relationships in relational databases.

Some might argue that reifying relationships is unnecessary, since
relationships in "good" E/R dialects can have attributes. What, then, is
the difference between an entity and a relationship? The best answer I
can think of is that an entity is identified by itself, while a
relationship is identified by its entities. But what if something has
more than one way of identification (i.e. multiple keys)? This is where
classic E/R breaks down for me. A "relationship" may be identified by
its entities, but also by (say) just one of its entities in combination
with a subset of its attributes. And/or perhaps a subset of its
attributes, disregarding any entities. Is it then a relationship, a weak
entity, or an entity?

This is turning into a rant against the classic(?) E/R notation, but
here goes anyway. I think it's a bad idea that more than one kind of
thing can have attributes. I think it's a bad idea that there are two
(or more) different ways of indicating how something is identified.
Relationship diamonds are required for non-binary relationships, but are
just clutter for binary ones---bad idea.

Fortunately, there is (at least) one E/R dialect that resolves all these
issues, and in so doing, even makes the distinction between entities and
relationships far less important.

Apropos this distinction: As to whether marriage is a relationship or an
entity, you said that one should listen to the subject matter experts. I
have never had such an expert say to me, "No, that's not a relationship,
that's an entity!" or vice versa. Have you?
--
Jon

I told my other half that we weren't in a relationship, and that we
should go off and get entity councilling.

Now she thinks i'm weird.

Jon Heggland wrote:

The difference between entity and relationship is neither more nor less
than psychological prejudice or bias. The distinction is entirely imagined.


Most SMEs just agree when they look at a pretty picture because they
don't want to look stupid for not understanding the notation. NIAM's
formalized english works so much better because when an SME disagrees
with a statement, the SME speaks up. They immediately say: "No, that's
wrong." or "No, that's not always right."

"Jon Heggland" <jon.heggland (AT) ntnu (DOT) no> wrote

Not all modeling is analysis. Some of it is design. In particular, I'm
going to claim that you discover attributes, but you design relvars. I've
already have the second claim confirmed by Bob and others.

Bob's distaste for pretty pictures should not obscure the mian theme. A
model isn't a "pretty picture" as such. Rather, a "pretty picture" is the
projection of a model on a flat screen. Other projections have been
proposed. A table written on a whiteboard, with some imaginary sample data
written into it, proposed by another participant, is another projection of
a model on a flat screen.

Whether a pretty picture was worth the cost of making it depends on what
happens next.






If you look at the metadata in the implemented database, none.


Not in so many words. But they have said things like "a reservation for a
certain car, on a certain date, by a certain customer has a way of
identifying it. We call it a 'reservation number'. What you have now
learned is that the UofD people think of a reservation as a thing in and of
itself and not just an association between a customer and a car on some
future date.

This tells you something you need to know about the problem statement: The
database has to store reservation numbers.

It also tells you something you need to know about database design: you
have two candidate keys for identifying a relationship, and eventually, a
relvar. One is reservation number. The other is customer ID, car type,
and date. If you declare primary keys in your database, you need to pick
one of these. This could have consequences for performance, ease of
programming, "natural joins" etc. etc. You also need to anticipate that
the application programmers are going to want to be able to find a
reservation, or the absence of a reservation (CWA), based on the
reservation number, based on a slip of paper the customer hands the clerk,
or based on the customer, the car type, and the date.

In some cases, the business rules will make the design decision for you. In
other cases, the business rules are silent on this score.

David Cressey wrote:

Pretty pictures have subtle pitfalls and limiting characteristics.
Learning to think without them and to communicate without them improves
both thought and communication.


Where do you have to look to find any difference? (Other than one is
drawn as a box and the other as a line or diamond.)


Protecting the integrity of data is a primary goal of data management.
If one wants to manage one's data, one must declare all candidate keys.
Whether one needs to pick one to designate as primary is secondary to this.


This could have consequences for performance, ease of
Performance is independent of choices at the logical level of discourse
where one identifies candidate keys or designates primary keys.
Performance is only affected at the physical level of discourse.


You also need to anticipate that
I disagree. First, what the application programmers want is irrelevant.
They are paid to meet the needs of the organization not their own whim.
Second, business rules are essentially synonymous with what the
organization needs.

"Bob Badour" <bbadour (AT) pei (DOT) sympatico.ca> wrote

A picture is worth a thousand words. Only an idiot would try to use a
screwdriver to drive a nail. Only a lunatic would choose to use a
screwdriver when there is a perfectly good hammer available.

"paul c" <toledobythesea (AT) ooyah (DOT) ac> wrote

I agree with that, but it doesn't address the issue of whether you design
an unnormalized schema and then normalize it on the one hand or on the other
hand start with something from which you can design a schema that will
already be normalized.