问题
Im fairly new to SQL, so difficult for me to know whats good, bad, better or best design.
I have a SQL 2008 database which I'm using along with Entity Framework 4.3. I'm trying to normalize my database.
In my design I have 2 tables Applications and AcceptedApplications.
AcceptedApplications is simply an extension of the Applications table, for, you guessed it, AcceptedApplications. This simply contains further information that is not pertinent to rejected applications.
There is a foreign key relationship between Application and AcceptedApplications so an Application must exist before an AcceptedApplication can be inserted.
However, I am also contemplating putting a bit field in the Application table to indicate whether it is accepted or not, something like 'IsAccepted'.
The question is, is this strictly necessary? Being a newbie I'm not necessarily aware of the benfits (if any) over simply checking whether an ID exists in ApplicationAccepted or joining the 2 tables togther. In terms of use I will not be querying for rejected applications on the live website only for analytical/reporting purposes.
回答1:
An IsAccepted bit field seems more reasonable.
However, if for some reason there might be another Applications table, for instance for applications in the process of being accepted or that have been refused, with different fields, your current solution seems better.
I believe this to be very unlikely but depending on your actual needs this may sound useful.
Please note that both solutions are in 3rd normal form.
回答2:
There is a good chance that you don't need the two table simply because the Application table will suffice your need based in your information. And the field that you want to add to AcceptedApplication table, namely, the IsAccepted field could simply be added in your Application table.
You could probably have this structure for your application table:
Table: Application
ApplicationID, Applicant_Lastname, Applicant_Firstname, ApplyDate, IsAccepted, AcceptedDate
The key in Normalization is interestingly the primary key. As E.F. Codd says and I'll be quoting from memory "Every non-key (meaning not the primary key) must provide a fact on the key (meaning the primary key) and nothing but the key".
For example the IsAccepted field actually is a non-key that is functionally dependent on the primary key ApplicationID so no need to create a new table for that matter.
Personally, I use a mnemonic device for the first three normal form, namely, the word RePeaT (ignoring the vowels). First is no Repeating groups or multivalued fields, second no Partial dependence on primary key and finally no Transitory dependence.
First Normal form (1NF): No Repeating Groups or Multivalued fields
Example: (Students taking Courses)
+-----------------------------------------------
+ CourseTakenID StudentID CoursesTaken
+-----------------------------------------------
+ 1 101 CS100, CS102, CS103
+ 2 102 MS100, CS101
In this case CoursesTaken is a Multi-valued fields and is a violation of 1NF.
To normalized, you could create a separate table named CourseTaken (now I am assuming also here that there is already a Course table), like:
+-----------------------------------------------
+ CourseTakenID StudentID CoursesTaken
+-----------------------------------------------
+ 1 101 CS100
+ 2 101 CS102
+ 3 101 CS103
+ 4 102 MS100
+ 5 102 CS101
Or if a repeating groups, it would look like this:
+--------------------------------------------------------------
+ StudentID StudentLastName StudentFirstName CoursesTaken
+--------------------------------------------------------------
+ 101 Smith John CS100
+ 101 Smith John CS102
+ 101 Smith John CS103
+ 102 Gilmore Anna MS100
+ 102 Gilmore Anna CS101
To normalize, it would be the same as above however your Student table would simply be:
+-----------------------------------------------
+ StudentID StudentLastName StudentFirstName
+-----------------------------------------------
+ 101 Smith John
+ 102 Gilmore Anna
Second Normal form (2NF): No Partial dependence
Now, the 2NF assumes here that the primary key is a composite primary key meaning combination of two or more fields.
Example: (Order Details of a customer)
Now, below we have an Order Details table that has a composite primary key of OrderID and ProductID
+-----------------------------------------------
+ OrderID ProductID ProductName Quantity
+-----------------------------------------------
+ 1 WM101 Washing Machine 1
+ 2 EI201 Electric Iron 1
In this case above ProductName is partially dependent on ProductID but not on OrderID and ProductID which are the composite primary key.
So, you could normalized this one by removing ProductName and put it instead on the Product table for example.
Order Details table:
+----------------------------------
+ OrderID ProductID Quantity
+----------------------------------
+ 1 WM101 1
+ 2 EI201 1
Products table:
+----------------------------------
+ ProductID ProductName QuantityOnHand
+----------------------------------
+ WM101 Washing Machine 20
+ EI201 Electric Iron 40
Third Normal form (3NF): No Transitory Dependence
Example: (Customer and their corresponding Sales Representative)
+-----------------------------------------------------------------------------------------
+ CustomerID CustomerLastName CustomerFirstName RepID RepLastName RepFirstName
+----------------------------------------------------------------------------------------
+ 101 James Grace SR101 Bravo Brave
+ 102 Gordon Ronald SR102 Alpha Alfonso
+ 103 Moore Jeff SR101 Bravo Brave
In the case above RepLastName and RepFirstName is dependent on RepID while RepID is dependent
on CustomerID so it is transitional and not a direct dependence on the primary key.
So, to normalized you create a separate table for SalesRep that would look like this:
+-----------------------------------------
+ RepID RepLastName RepFirstName
+-----------------------------------------
+ SR101 Bravo Brave
+ SR102 Alpha Alfonso
And your Customers table would now look like this:
+----------------------------------------------------------
+ CustomerID CustomerLastName CustomerFirstName RepID
+----------------------------------------------------------
+ 101 James Grace SR101
+ 102 Gordon Ronald SR102
+ 103 Moore Jeff SR101
来源：https://stackoverflow.com/questions/20188944/pattern-for-normalized-tables