views:

120

answers:

4

Can we furthur Normalize this Sql Table Structue is Primary key is ID,Date,NAme,Type

ID  Date          Name            Type           Value 
-----------------------------------------------------


1   08/15/2010    Rating          A+               10       
1   08/15/2010    Rating          A-               10        
1   08/15/2010    Composition     MultipleChoice   33        
1   08/15/2010    Composition     YESNO            33        
1   08/15/2010    Composition     Fillin           33        

1   08/16/2010    Rating          A+               30      
1   08/16/2010    Rating          A-               10        
1   08/16/2010    Composition     MultipleChoice   25       
1   08/16/2010    Composition     YESNO            50        
1   08/16/2010    Composition     Fillin           25      

and so on

+1  A: 

Are types and names going to be out of a specific set? You could break them out into lib tables and reference them. That's the only thing I can think of though.

For example, if your types are always going to just be A1, A2, B1, B2, and C1, you can go make those into a separate table, and then instead of constantly entering A1 into the database, you can have a foreign key off to the table of types that references A1's row.

fire.eagle
+1: That's all I can see too
OMG Ponies
Yes it looks like name is functionally dependant on type in which case this would violate 2NF.
Martin Smith
-1 Your suggestion of isolating the natural values into a lookup table has nothing to do with normalization.
Bill Karwin
+1  A: 

You could do this

alt text

Raj More
How do I create foreignKeys in degin Mode using SQL SERVER 2005 Exp
ThinkingCap
+1 for "purty" pictures. (^_^)
Brock Adams
A: 

The only obvious thing that I can see is breaking out Name and Type to separate tables, but I can't say definitely since I'm not quite sure what they actually represent.

Just Will
+2  A: 

This looks suspiciously like a combination EAV table and history table. What is its true purpose? What are the associated tables?

Based on the limited information given, you would normalize it by turning it into a pure history table. The Rating and Composition should not be split across rows but should be in decently-named columns. Something like so:

ID  Date          Rating_A+     Rating_A-   MultipleChoicePercent  YESNOPercent FillinPercent
---------------------------------------------------------------------------------------------
1   08/15/2010    10.0          10.0        33.3                    33.3        33.3
1   08/16/2010    30.0          10.0        25.0                    50.0        25.0

.
This will allow for simpler and faster: Check constraints, indexes, and queries.

Brock Adams