Can FK be nullable/optional by design?

[Andy]

Hi All!

General statement: FK should not be nullabe to avoid orphans in DB.

Real life:
Business rule says that not every record will have a parent. It is
implemented as a child record has FK that is null.



It works, and it is simpler.
The design that satisfy business rule and FK not null can be
implemented but it will be more complicated.

Example: There are clients. A client might belong to only one group.

Case A.
Group(GroupID PK, Name,Code…)
Client(ClientID PK, Name, GroupID FK NULL)


Case B(more cleaner)
Group(GroupID PK, Name, GroupCode…)

Client (ClientID PK, Name, ….)
Subtype:
GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)

There is one more entity in Case B and it will require an additional
join in compare with caseA
Example: Select all clients that belongs to any group


Summary Q: Is it worth to go with CaseB?

Thank you in advance

[Joe \Nuke Me Xemu\ Foster]

Re: Can FK be nullable/optional by design?

"Andy" <net__space@hot mail.com> wrote in message <news:edb90340. 0311301114.1971 8061@posting.go ogle.com>...
[color=blue]
> Hi All!
>
> General statement: FK should not be nullabe to avoid orphans in DB.
>
> Real life:
> Business rule says that not every record will have a parent. It is
> implemented as a child record has FK that is null.[/color]

Nulls suck. Dealing with Null is ugly any way you look at it.
[color=blue]
> It works, and it is simpler.
> The design that satisfy business rule and FK not null can be
> implemented but it will be more complicated.
>
> Example: There are clients. A client might belong to only one group.
>
> Case A.
> Group(GroupID PK, Name,Code.)
> Client(ClientID PK, Name, GroupID FK NULL)[/color]

In this scheme, a client may belong to no group or one group but
cannot belong to more than one group. Is this the business rule?
[color=blue]
> Case B(more cleaner)
> Group(GroupID PK, Name, GroupCode.)
>
> Client (ClientID PK, Name, ..)
> Subtype:
> GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)
>
> There is one more entity in Case B and it will require an additional
> join in compare with caseA
> Example: Select all clients that belongs to any group[/color]

With one tweak, GroupedClient can be a many<->many link between
Client and Group. Otherwise, you can always use a view to turn
Case B into Case A for the convenience of a particular program.
[color=blue]
> Summary Q: Is it worth to go with CaseB?[/color]

Case C. Use one or more "special" groups to "contain" otherwise
"groupless" clients. However, you now have the "special" groups
to deal with.

--
Joe Foster <mailto:jlfoste r%40znet.com> Sign the Check! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Bruce Lewis]

Re: Can FK be nullable/optional by design?

net__space@hotm ail.com (Andy) writes:
[color=blue]
> General statement: FK should not be nullabe to avoid orphans in DB.[/color]

I don't see the reasoning behind this statement. Any column that
references keys to another table should be explicitly specified as such
to avoid orphans.

If that column may sometimes be unknown/unspecified for perfectly valid
records, I see no reason not to make it nullable.

--
"Notwithstandin g fervent argument that patent protection is essential
for the growth of the software industry, commentators have noted
that `this industry is growing by leaps and bounds without it.'"
-- US Supreme Court Justice John Paul Stevens, March 3, 1981.

[Trey Walpole]

Re: Can FK be nullable/optional by design?

depends on what a Group is and how it is used...

e.g.,
is a Group a Super-Client? -- individual Clients may be subsidiaries of a
Super-Client?
is a Group in internal designation, like a Sales territory?

How many Clients are there likely to be w/o a group?
When you need to act on the clients that are grouped, do you also need to
act on the clients that are not grouped?

[ps. in Case B, where did PersonID come from? Is that the Client?]
[color=blue]
> Example: There are clients. A client might belong to only one group.
>[/color]
[color=blue]
> Case A.
> Group(GroupID PK, Name,Code.)
> Client(ClientID PK, Name, GroupID FK NULL)
>
>
> Case B(more cleaner)
> Group(GroupID PK, Name, GroupCode.)
>
> Client (ClientID PK, Name, ..)
> Subtype:
> GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)
>
> There is one more entity in Case B and it will require an additional
> join in compare with caseA
> Example: Select all clients that belongs to any group
>
>
> Summary Q: Is it worth to go with CaseB?
>
> Thank you in advance[/color]

[Andy]

Re: Can FK be nullable/optional by design?

"Trey Walpole" <treyNOpole@SPc omcastAM.net> wrote in message news:<u3p24vCuD HA.3144@tk2msft ngp13.phx.gbl>. ..[color=blue]
> depends on what a Group is and how it is used...
>
> e.g.,
> is a Group a Super-Client? -- individual Clients may be subsidiaries of a
> Super-Client?
> is a Group in internal designation, like a Sales territory?
>
> How many Clients are there likely to be w/o a group?
> When you need to act on the clients that are grouped, do you also need to
> act on the clients that are not grouped?
>
> [ps. in Case B, where did PersonID come from? Is that the Client?][/color]

Yes, it does.
It should be this way

[ps. in Case B, where did PersonID come from? Is that the Client?]

Case B
Group(GroupID PK, Name, GroupCode.)
Client (ClientID PK, Name, ..)
Subtype:
GroupedClient (ClientID PK/FK, GroupID FK NOT NULL)

[Eric Junkermann]

Re: Can FK be nullable/optional by design?

net__space@hotm ail.com (Andy) wrote in message news:<edb90340. 0311301114.1971 8061@posting.go ogle.com>...[color=blue]
> Hi All!
>
> General statement: FK should not be nullabe to avoid orphans in DB.
>[/color]

Where did this statement come from? The idea of an orphan belongs to
network and hierarchical databases (old fashioned) or to
object-oriented databases (allegedly new), where the only way to get
to a record might be through its parent record. In a relational
database there is no such thing as an orphan.

You can find your "orphans" by some equivalent of (client where
groupcode not present) (worded that way to keep away from arguments
about NULLS).

In your example, what you have is

A client may be a member of at most one group.

If you meant to have

A client must be a member of exactly one group.

then (in your example) you would have to use NOT NULL.

Regards,

Eric

[Tobin Harris]

Re: Can FK be nullable/optional by design?


"Andy" <net__space@hot mail.com> wrote in message
news:edb90340.0 311301114.19718 061@posting.goo gle.com...[color=blue]
> Hi All!
>
> General statement: FK should not be nullabe to avoid orphans in DB.
>
> Real life:
> Business rule says that not every record will have a parent. It is
> implemented as a child record has FK that is null.
>[/color]

I'm not too hot on all this, but here is what I was lead to believe: If
Client *must* belong to at least one group, then the client is dependent on
the group - it cannot exist without it. Therefore, it's primary key would
(at least logically) be a composite, where the group pk forms part of the
clients composite primary key. This would ensure that a client cannot exist
without a group!?

This might look like:
Client(GroupID PK, ClientID PK, Name )


Otherwise, if the Client could optionally belong to one Group, the
relationship would be captured in a link table, as you suggested in B?

GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)

Just my 2 pennies worth 8-)

Tobes

[Joe \Nuke Me Xemu\ Foster]

Re: Can FK be nullable/optional by design?

"Tobin Harris" <tobin_dont_you _spam_me@breath email.net> wrote in message <news:braub1$1c ceh$1@ID-135366.news.uni-berlin.de>...
[color=blue]
> "Andy" <net__space@hot mail.com> wrote in message
> news:edb90340.0 311301114.19718 061@posting.goo gle.com...[color=green]
> > Hi All!
> >
> > General statement: FK should not be nullabe to avoid orphans in DB.
> >
> > Real life:
> > Business rule says that not every record will have a parent. It is
> > implemented as a child record has FK that is null.[/color][/color]
[color=blue]
> I'm not too hot on all this, but here is what I was lead to believe: If
> Client *must* belong to at least one group, then the client is dependent on
> the group - it cannot exist without it. Therefore, it's primary key would
> (at least logically) be a composite, where the group pk forms part of the
> clients composite primary key. This would ensure that a client cannot exist
> without a group!?
>
> This might look like:
> Client(GroupID PK, ClientID PK, Name )[/color]

Did you really mean to claim that ALL non-nullable attributes MUST
'logically' be included as part of the primary key?!
[color=blue]
> Otherwise, if the Client could optionally belong to one Group, the
> relationship would be captured in a link table, as you suggested in B?
>
> GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)[/color]

This would avoid the null nonsense until someone does an outer join.

--
Joe Foster <mailto:jlfoste r%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Tobes \(Breath\)]

Re: Can FK be nullable/optional by design?


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
news:1071189386 .456990@news-1.nethere.net.. .[color=blue]
> Did you really mean to claim that ALL non-nullable attributes MUST
> 'logically' be included as part of the primary key?![/color]

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-)
[color=blue][color=green]
> > Otherwise, if the Client could optionally belong to one Group, the
> > relationship would be captured in a link table, as you suggested in B?
> >
> > GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)[/color]
>
> This would avoid the null nonsense until someone does an outer join.[/color]

That's true. So which option would you go for?

Tobes
[color=blue]
> --
> Joe Foster <mailto:jlfoste r%40znet.com> L. Ron Dullard[/color]
<http://www.xenu.net/>[color=blue]
> WARNING: I cannot be held responsible for the above They're[/color]
coming to[color=blue]
> because my cats have apparently learned to type. take me away,[/color]
ha ha!

[Joe \Nuke Me Xemu\ Foster]

Re: Can FK be nullable/optional by design?

"Tobes (Breath)" <tobin_dont_spa m_me@breathemai l.net> wrote in message <news:brck8d$1t 2ru$1@ID-131901.news.uni-berlin.de>...
[color=blue]
> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
> news:1071189386 .456990@news-1.nethere.net.. .[color=green]
> > Did you really mean to claim that ALL non-nullable attributes MUST
> > 'logically' be included as part of the primary key?![/color]
>
> 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-)[/color]

The ClientID by itself should probably be the primary key, though
the GroupID could be made part of an alternate candidate key.
[color=blue][color=green][color=darkred]
> > > Otherwise, if the Client could optionally belong to one Group, the
> > > relationship would be captured in a link table, as you suggested in B?
> > >
> > > GroupedClient (PersonID PK/FK, GroupID FK NOT NULL)[/color]
> >
> > This would avoid the null nonsense until someone does an outer join.[/color]
>
> That's true. So which option would you go for?[/color]

Maybe have a special "Loners" group? =) It's hard to say given
the information at hand. Yeah, I know, the usual cop-out...

--
Joe Foster <mailto:jlfoste r%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Bob Badour]

Re: Can FK be nullable/optional by design?

"Tobes (Breath)" <tobin_dont_spa m_me@breathemai l.net> wrote in message
news:brck8d$1t2 ru$1@ID-131901.news.uni-berlin.de...[color=blue]
>
> "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
> news:1071189386 .456990@news-1.nethere.net.. .[color=green]
> > Did you really mean to claim that ALL non-nullable attributes MUST
> > 'logically' be included as part of the primary key?![/color]
>
> 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[/color]
of[color=blue]
> 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[/color]
think[color=blue]
> I need to take my anti-waffle pill, can't seem to put a good explanation
> together 8-)[/color]

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
"identifyin g" 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.

[Louis Davidson]

Re: Can FK be nullable/optional by design?

Just a couple of things:
[color=blue]
> Your bind above demonstrates a very real pitfall of confusing knowledge of[/color]
a[color=blue]
> 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
> "identifyin g" vs. "non-identifying" relationships.[/color]

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.
[color=blue]
> I have seen people using this tool create schemas with ridiculous six and
> seven part compound primary keys and call it "normalization" .[/color]

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.
[color=blue]
> Your bind above also demonstrates the dangers of using a graphical crutch[/color]
in[color=blue]
> place of real thought and analysis.[/color]

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 :)
[color=blue]
> I respectfully suggest you will find yourself much more effective if you
> learn the fundamentals before the tools.[/color]

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@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@golden .net> wrote in message
news:Vf6dnepaAr IqnkeiRVn-tw@golden.net.. .[color=blue]
> "Tobes (Breath)" <tobin_dont_spa m_me@breathemai l.net> wrote in message
> news:brck8d$1t2 ru$1@ID-131901.news.uni-berlin.de...[color=green]
> >
> > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
> > news:1071189386 .456990@news-1.nethere.net.. .[color=darkred]
> > > Did you really mean to claim that ALL non-nullable attributes MUST
> > > 'logically' be included as part of the primary key?![/color]
> >
> > 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[/color][/color]
PK[color=blue]
> of[color=green]
> > that entity part of a composite key in the dependent entity. It's an
> > alternative to just non nullable foreign keys, where the related[/color][/color]
column(s)[color=blue][color=green]
> > become part of a primary key, rather than just a foreign key. Sorry, I[/color]
> think[color=green]
> > I need to take my anti-waffle pill, can't seem to put a good explanation
> > together 8-)[/color]
>
> 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[/color]
to[color=blue]
> take this personally.
>
> Your bind above demonstrates a very real pitfall of confusing knowledge of[/color]
a[color=blue]
> 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
> "identifyin g" 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[/color]
in[color=blue]
> place of real thought and analysis.
>
> I respectfully suggest you will find yourself much more effective if you
> learn the fundamentals before the tools.
>
>[/color]

[Tobin Harris]

Re: Can FK be nullable/optional by design?

"Bob Badour" <bbadour@golden .net> wrote in message
news:Vf6dnepaAr IqnkeiRVn-tw@golden.net.. .[color=blue]
> "Tobes (Breath)" <tobin_dont_spa m_me@breathemai l.net> wrote in message
> news:brck8d$1t2 ru$1@ID-131901.news.uni-berlin.de...[color=green]
> >
> > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
> > news:1071189386 .456990@news-1.nethere.net.. .[color=darkred]
> > > Did you really mean to claim that ALL non-nullable attributes MUST
> > > 'logically' be included as part of the primary key?![/color]
> >
> > 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[/color][/color]
PK[color=blue]
> of[color=green]
> > that entity part of a composite key in the dependent entity. It's an
> > alternative to just non nullable foreign keys, where the related[/color][/color]
column(s)[color=blue][color=green]
> > become part of a primary key, rather than just a foreign key. Sorry, I[/color]
> think[color=green]
> > I need to take my anti-waffle pill, can't seem to put a good explanation
> > together 8-)[/color]
>
> 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[/color]
to[color=blue]
> take this personally.
>
> Your bind above demonstrates a very real pitfall of confusing knowledge of[/color]
a[color=blue]
> 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
> "identifyin g" vs. "non-identifying" relationships.[/color]

Interestingly, I have used Erwin, but only briefly! My knowledge of this
technique came from something tought in relational theory during my degree.
Basically, we were being shown how to transition from conceptual ER diagrams
to a physical model, and this specific technique was to be used if one
entity's existance was dependent on another. I even recall the classroom
example! This was along the lines of if you had the entities Cinema and
CinemaScreen, then the existance of the screen might be dependent on the
cinema (no screen without a cinema kinda thing). Therefore, the PK of the
cinema would 'propogage' down to form part of the CinemaScreens PK. I'm not
really bothered about the context, this just did seem like a logical thing
to do.

Don't worry, I haven't taken this personally! However, having learnt this
approach well before sitting down and trying to use a RDBMS, I found that
when using any RDBMS, they seemed to support the concept of a column that is
part of a primary key, and a foreign key also. So, way back then I never
questioned it.
[color=blue]
> I have seen people using this tool create schemas with ridiculous six and
> seven part compound primary keys and call it "normalization" .[/color]

Yeah, I've fallen into this trap once or twice (although not quite so far!)
[color=blue]
> Your bind above also demonstrates the dangers of using a graphical crutch[/color]
in[color=blue]
> place of real thought and analysis.
>
> I respectfully suggest you will find yourself much more effective if you
> learn the fundamentals before the tools.[/color]

A fair suggestion, although I thought I knew at least most of the
fundamentals! I've always put learning this before learnign the tools. That
way, when you come to learn the tools, it os interesting to see if/how they
supported the things you want to achieve, rather than pushing buttons seeing
what the tool could do, and then trying to understand it!

Just out of interest, what would you describe as the fundamentals?

Tobes

[Bob Badour]

Re: Can FK be nullable/optional by design?

"Tobin Harris" <tobin_dont_you _spam_me@breath email.net> wrote in message
news:brddal$26u nq$1@ID-135366.news.uni-berlin.de...[color=blue]
> "Bob Badour" <bbadour@golden .net> wrote in message
> news:Vf6dnepaAr IqnkeiRVn-tw@golden.net.. .[color=green]
> > "Tobes (Breath)" <tobin_dont_spa m_me@breathemai l.net> wrote in message
> > news:brck8d$1t2 ru$1@ID-131901.news.uni-berlin.de...[color=darkred]
> > >
> > > "Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUC P> wrote in message
> > > news:1071189386 .456990@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[/color][/color]
> PK[color=green]
> > of[color=darkred]
> > > that entity part of a composite key in the dependent entity. It's an
> > > alternative to just non nullable foreign keys, where the related[/color][/color]
> column(s)[color=green][color=darkred]
> > > become part of a primary key, rather than just a foreign key. Sorry, I[/color]
> > think[color=darkred]
> > > I need to take my anti-waffle pill, can't seem to put a good[/color][/color][/color]
explanation[color=blue][color=green][color=darkred]
> > > together 8-)[/color]
> >
> > Please allow me to hang an important point off of your post. The bind[/color][/color]
you[color=blue][color=green]
> > find yourself in above is certainly not unique to you so there is no[/color][/color]
need[color=blue]
> to[color=green]
> > take this personally.
> >
> > Your bind above demonstrates a very real pitfall of confusing knowledge[/color][/color]
of[color=blue]
> a[color=green]
> > specific tool with knowledge of fundamentals. I have seen numerous[/color][/color]
people[color=blue][color=green]
> > fall into this specific pit throughout my career. I figure at least a[/color][/color]
90%[color=blue][color=green]
> > chance the tool you know is Erwin, and you are describing their
> > "identifyin g" vs. "non-identifying" relationships.[/color]
>
> Interestingly, I have used Erwin, but only briefly! My knowledge of this
> technique came from something tought in relational theory during my[/color]
degree.[color=blue]
> Basically, we were being shown how to transition from conceptual ER[/color]
diagrams[color=blue]
> to a physical model, and this specific technique was to be used if one
> entity's existance was dependent on another. I even recall the classroom
> example![/color]

I doubt, then, you were actually taught any relational theory. With the
current state of the education, I do not find that surprising.

[color=blue]
> Don't worry, I haven't taken this personally! However, having learnt this
> approach well before sitting down and trying to use a RDBMS, I found that
> when using any RDBMS, they seemed to support the concept of a column that[/color]
is[color=blue]
> part of a primary key, and a foreign key also. So, way back then I never
> questioned it.[/color]

The candidate keys and foreign keys within a relation are generally
independent of one another and can overlap. Of course, a correspondence
exists between a foreign key in a referencing relation and a candidate key
in the referenced relation. I said "generally independent" above because in
the case that a relation refers to itself, the foreign key and candidate key
are in the same relation.

Whether some or all of a foreign key forms some or all of a candidate key
has no particular importance to me.

[color=blue][color=green]
> > I have seen people using this tool create schemas with ridiculous six[/color][/color]
and[color=blue][color=green]
> > seven part compound primary keys and call it "normalization" .[/color]
>
> Yeah, I've fallen into this trap once or twice (although not quite so[/color]
far!)[color=blue]
>[color=green]
> > Your bind above also demonstrates the dangers of using a graphical[/color][/color]
crutch[color=blue]
> in[color=green]
> > place of real thought and analysis.
> >
> > I respectfully suggest you will find yourself much more effective if you
> > learn the fundamentals before the tools.[/color]
>
> A fair suggestion, although I thought I knew at least most of the
> fundamentals! I've always put learning this before learnign the tools.[/color]
That[color=blue]
> way, when you come to learn the tools, it os interesting to see if/how[/color]
they[color=blue]
> supported the things you want to achieve, rather than pushing buttons[/color]
seeing[color=blue]
> what the tool could do, and then trying to understand it!
>
> Just out of interest, what would you describe as the fundamentals?[/color]

Chris Date's _Introduction to Database Management Systems_ makes a good
start at them. I would seem foolish to try to teach them in an email
message.

One would start with "What is data?" and "What does it mean to manage data?"
From there, one would move to: "What principles facilitate or guide
effective data management?" And onward...

Since you apparently think one can easily enumerate them in an email, what
would you describe as the fundamentals?

[Mike MacSween]

Re: Can FK be nullable/optional by design?

"Bob Badour" <bbadour@golden .net> wrote in message
news:tPGdndKS74 g91Eei4p2dnA@go lden.net...
[color=blue]
> I doubt, then, you were actually taught any relational theory. With the
> current state of the education, I do not find that surprising.[/color]
[color=blue]
> One would start with "What is data?"[/color]

If I add this data to that data do I have 2 datas?