Re: Second Normal Form help.

From: Kristian Damm Jensen <kristian-Damm.Jensen_at_REMOVEcapgemini.dk>
Date: Fri, 30 Mar 2001 09:43:48 +0200
Message-ID: <3AC43934.186C396B_at_REMOVEcapgemini.dk>


Tom wrote:
>
> You cant have a concatenated primary key and achieve 2NF.

Nonsense.

2NF: A table is in 2NF if it is in 1NF and if all non-key attributes are dependent on all of the key.

Not "non-key attributes".

<snip>

> James_one <James_one_at_deja.com> wrote in message
> news:GoMw6.271821$65.1466316_at_news1.rdc1.fl.home.com...
> > Here is a simplified version of a model I'm working on.
> > Buildings have many garages, and the garages can hold 1 or more trucks:

<snip>

> > CREATE TABLE Garages (
> > BuildingID int NOT NULL REFERENCES Buildings(BuildingID),
> > GarageNumber int NOT NULL ,
> > Width int NOT NULL ,
> > Length int NOT NULL ,
> > Height int NOT NULL,
> > PRIMARY KEY (BuildingID, GarageNumber)
> > )

<snip>

> > My question is about the garages table. Is it in second normal form?

If the GarageNumber is unique only within a given building, the primary key of Garage would be (BuildingID, GarageNumber), and the dependency between BuildingId and GarageNumber does not interfere with 2NF.

On the other hand, if GarageNumber is globally unique, the primary key of Garage would be (GarageNumber) and since we now have a single-attribute key, we cannot possibly violate 2NF.

In either case you are okay, unless you define the PK wrong.

> > I mean do the dimensions(height width and length) of the garage depend on
> > the whole primary key of garages or just the garage number?

That is for you to decide!

Knowing this is a prerequisite for designing the DB, not the other way around.

--
Kristian Damm Jensen              | Feed the hungry. Go to 
kristian-damm.jensen_at_capgemini.dk | http://www.thehungersite.com
Received on Fri Mar 30 2001 - 09:43:48 CEST

Original text of this message