Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Can FK be nullable/optional by design?

Re: Can FK be nullable/optional by design?

From: Louis Davidson <dr_dontspamme_sql_at_hotmail.com>
Date: Fri, 12 Dec 2003 14:24:02 -0600
Message-ID: <#cFym3OwDHA.1680@TK2MSFTNGP12.phx.gbl>


Just a couple of things:

> Your bind above demonstrates a very real pitfall of confusing knowledge of
a
> specific tool with knowledge of fundamentals. I have seen numerous people
> fall into this specific pit throughout my career. I figure at least a 90%
> chance the tool you know is Erwin, and you are describing their
> "identifying" vs. "non-identifying" relationships.

Identifying and non-identifying relationships are not an Erwin thing. They are an idef1x thing. Check FIPS publication 184: http://www.itl.nist.gov/fipspubs/idef1x.doc.

> I have seen people using this tool create schemas with ridiculous six and
> seven part compound primary keys and call it "normalization".

Just because you have six and seven part compound keys does not mean that you are not normalized. It may take that many different atomic bits to uniquely identify something. If these compound keys are built from six relationships, the chances of it being normalized are about as good as the San Diego Chargers winning last years Super Bowl, but it is possible.

> Your bind above also demonstrates the dangers of using a graphical crutch
in
> place of real thought and analysis.

So you don't use data models? The graphical "crutch" as you call it is pretty standard stuff. I have never considered data models controversial in the least. Cannot question the need for thought and analysis though :)

> I respectfully suggest you will find yourself much more effective if you
> learn the fundamentals before the tools.

You are correct (cannot believe I am agreeing with you :) about just having tool knowledge. Erwin is a great tool, but they do have some terminology/practices that are not standard, and frankly the tool will let you get away with murder. It's job is to let you draw pictures of your data, not to give you a hard time. That is your job Bob :)

-- 
----------------------------------------------------------------------------
-----------
Louis Davidson (drsql_at_hotmail.com)
Compass Technology Management

Pro SQL Server 2000 Database Design
http://www.apress.com/book/bookDisplay.html?bID=266

Note: Please reply to the newsgroups only unless you are
interested in consulting services.  All other replies will be ignored :)

"Bob Badour" <bbadour_at_golden.net> wrote in message
news:Vf6dnepaArIqnkeiRVn-tw_at_golden.net...

> "Tobes (Breath)" <tobin_dont_spam_me_at_breathemail.net> wrote in message
> news:brck8d$1t2ru$1_at_ID-131901.news.uni-berlin.de...
> >
> > "Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message
> > news:1071189386.456990_at_news-1.nethere.net...
> > > Did you really mean to claim that ALL non-nullable attributes MUST
> > > 'logically' be included as part of the primary key?!
> >
> > Well, not really! I was just throwing in another option - where if the
> > existance of one entity is dependent on another, then you can make the
PK
> of
> > that entity part of a composite key in the dependent entity. It's an
> > alternative to just non nullable foreign keys, where the related
column(s)
> > become part of a primary key, rather than just a foreign key. Sorry, I
> think
> > I need to take my anti-waffle pill, can't seem to put a good explanation
> > together 8-)
>
> Please allow me to hang an important point off of your post. The bind you
> find yourself in above is certainly not unique to you so there is no need
to
> take this personally.
>
> Your bind above demonstrates a very real pitfall of confusing knowledge of
a
> specific tool with knowledge of fundamentals. I have seen numerous people
> fall into this specific pit throughout my career. I figure at least a 90%
> chance the tool you know is Erwin, and you are describing their
> "identifying" vs. "non-identifying" relationships.
>
> I have seen people using this tool create schemas with ridiculous six and
> seven part compound primary keys and call it "normalization".
>
> Your bind above also demonstrates the dangers of using a graphical crutch
in
> place of real thought and analysis.
>
> I respectfully suggest you will find yourself much more effective if you
> learn the fundamentals before the tools.
> >
Received on Fri Dec 12 2003 - 14:24:02 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US