I am having some problems with database dependencies and was looking for some help. I just made up some data here to see if I am on the right track.

Stuff (H,I,J,K,L,M,N,O) Could someone tell me what normal form this would be if only H and I can act as the key

MORE_Stuff (D,O,B,G,C,J) Could someone tell me what normal form this would be if only Dand O can act as the key

Store_Item (Sku, PromoID,Vendor,Style,Price) Same with this one.

Software (softwarevendor,Product,release,systemreq,price,wa rranty) Is this first normal form and what would I have to do to put it into BCNF.

Thanks for the help I am having a few problems with dependencies and normalization, but I will hopefully get the hang of it.

if only H and I, or if only H or I? in any case, we can't tell, because we don't know what the dependencies of the other columns are on these two

for example, H could be order number, I could be order timestamp, and on the assumption that no two orders have exactly the same timestamp, either one of them could be the primary key, but if J is product number and K is product name, then K depends on J and not on the key

Store_Item looks like BCNF (although i am not sure, and i'm too lazy to look it up), with Sku, PromoID, and Vendor forming a 3-column composite primary key, and Style and Price depending on the key

same with Software, it looks like another 3-column composite key

Okay lets say these are the dependencies does that help.H,I, ---- J,K,l
J--- M
K---N
L---O

Thanks again for the help

that doesn't help me at all

sorry

They're apparently using Rutherford notation. To translate:

H, I, ----- J, K, M

means that the combination of attributes H and I imply a specific combination of attributes J, K, and M. In database terms, that makes the combination of H and I the primary key. Further translating:

J--- M
K---N
L---O

means that the presense of a value for J implies a value for M. Since J is a single attribute instead of a tuple set, this means that the presense of a value for J requires a presense of a value for M. SQL can do this via constraints, but it isn't pretty. A "real world" example of this would be that if a measurement for something is specified (for example a weight or length) as J, the presence of a unit (as M) is required. Early in the use, the contrapositive was assumed (no J enforced no M), however later in use that restriction was frequently ignored.

This notation was often used in Hierarchical Database implementations, but not often for relational implementations.

-PatP

Pat,

So are you saying that "J---M" does not mean that J functionally determines M, but that "H, I ----- J, K, M" does mean that (H, I) functionally determines (J, K, M)? That seems counter-intuitive.

I would have guessed that J---M does mean that J functionally determines M, and so "Stuff" violates 2NF and is therefore only in 1NF.

That weirdness of the notation kind of helps explain why relational folks aren't fond of it. The weirdness makes a lot more sense if you think in Hierarchical terms, where that actually makes sense (in its own, hierarchical way). It is also why I haven't seen Rutherford taught since the mid-to-late 1980s... It was a "blast from the past" to see the notation again.

-PatP

I'd never heard of "Rutherford notation", so I Googled it and got exactly one hit, which as you can see makes it all perfectly clear!