Application 테이블은 정보를 기반으로 필요 충분하기 때문에 두 테이블이 필요하지 않을 가능성이 있습니다. 그리고 AcceptedApplication 테이블에 추가하려는 필드, 즉 IsAccepted 필드는 Application 테이블에 간단히 추가 할 수 있습니다.
당신은 아마 당신의 응용 프로그램 테이블이 구조를 가질 수있다 :
테이블 : 응용 프로그램
ApplicationID, Applicant_Lastname, Applicant_Firstname, ApplyDate, IsAccepted, AcceptedDate
Normalization의 키를 흥미롭게 primary key입니다. E.F. Codd가 말했듯이 나는 "키가 아닌 모든 키 (기본 키가 아닌)는 키 (사실 기본 키를 의미 함)에 키를 제공해야하며 키는"으로 표시해야합니다.
예를 들어, IsAccepted 필드는 실제적으로 기본 키 ApplicationID에 기능적으로 종속적 인 비 키이므로 해당 문제에 대해 새 테이블을 만들 필요가 없습니다.
개인적으로 처음 세 가지 정규 형식 즉, RePeaT (모음을 무시함)에 대해 니모닉 장치를 사용합니다.첫 번째는 반복 그룹 또는 다중 값 필드이며, 두 번째는 기본 키에 부분적으로 종속되며 마지막으로 일시 의존성이 없습니다.
제 1 정규형 (1NF)가 :
예 아니오 그룹 또는 다중 값 필드를 반복 :이 경우 CoursesTaken에서
+-----------------------------------------------
+ CourseTakenID StudentID CoursesTaken
+-----------------------------------------------
+ 1 101 CS100, CS102, CS103
+ 2 102 MS100, CS101
(학생과정을 복용)는 Multi-valued 필드없고 1NF의 위반입니다.
+-----------------------------------------------
+ CourseTakenID StudentID CoursesTaken
+-----------------------------------------------
+ 1 101 CS100
+ 2 101 CS102
+ 3 101 CS103
+ 4 102 MS100
+ 5 102 CS101
또는 반복 그룹의 경우
, 그것과 같을 것이다 : 정규화으로
, 당신은 같은 CourseTaken (지금은 Course 테이블이 이미 있다는 것을 여기에 또한 가정입니다)라는 별도의 테이블을 만들 수 있습니다 이 :
+--------------------------------------------------------------
+ StudentID StudentLastName StudentFirstName CoursesTaken
+--------------------------------------------------------------
+ 101 Smith John CS100
+ 101 Smith John CS102
+ 101 Smith John CS103
+ 102 Gilmore Anna MS100
+ 102 Gilmore Anna CS101
정상화하기 위해서는 상기와 동일하지만 당신 Student 표는 단순히 것 같습니다
0 123,158,
제 2 정규형 (2NF) : 이제 부분적인 의존
는 2NF는 primary key 두 개 이상의 필드의 조합을 의미 composite primary key 것을 여기에 가정합니다.
예 : (고객의 주문 정보)
이제, 우리는 ProductName 이상이 경우 복합 차 OrderID의 키와 ProductID
+-----------------------------------------------
+ OrderID ProductID ProductName Quantity
+-----------------------------------------------
+ 1 WM101 Washing Machine 1
+ 2 EI201 Electric Iron 1
이있는 주문 정보 테이블을 아래로 부분적으로는 ProductID에 의존하지만 OrderID 및 ProductID은 아니며 composite primary key입니다.
따라서 ProductName을 제거하고이를 예를 들어 Product 테이블에 넣으면 정규화 할 수 있습니다.
Order Details 테이블 :
+----------------------------------
+ OrderID ProductID Quantity
+----------------------------------
+ 1 WM101 1
+ 2 EI201 1
Products 테이블 :
+----------------------------------
+ ProductID ProductName QuantityOnHand
+----------------------------------
+ WM101 Washing Machine 20
+ EI201 Electric Iron 40
3 정규형 (3NF) : 없음 일시적인 의존
예 : (고객과는 대응 영업 담당자 RepID 그래서 그것은 과도 및 기본 키가 아닌 직접적인 의존성이다 CustomerID 에 의존하면서 resentative) RepLastNameRepFirstName 및 상기 경우
+-----------------------------------------------------------------------------------------
+ CustomerID CustomerLastName CustomerFirstName RepID RepLastName RepFirstName
+----------------------------------------------------------------------------------------
+ 101 James Grace SR101 Bravo Brave
+ 102 Gordon Ronald SR102 Alpha Alfonso
+ 103 Moore Jeff SR101 Bravo Brave
는 RepID에 의존한다. 지금과 같을 것이다
+-----------------------------------------
+ RepID RepLastName RepFirstName
+-----------------------------------------
+ SR101 Bravo Brave
+ SR102 Alpha Alfonso
그리고 당신의 Customers 테이블 :
그래서, 당신은 같을 것이다 SalesRep에 대해 별도의 테이블을 생성 정상화하는
+----------------------------------------------------------
+ CustomerID CustomerLastName CustomerFirstName RepID
+----------------------------------------------------------
+ 101 James Grace SR101
+ 102 Gordon Ronald SR102
+ 103 Moore Jeff SR101
_Why_ 당신이 테이블을 비정규입니까? 일반적으로 데이터 불일치 오류가 발생할 위험이 있으며 성능 관련 문제를 해결하는 데에만 사용됩니다. 'AcceptedApplications'에 어떤 추가 속성이 있었는가요? 그리고 당신이 그 테이블을 제거한다면 어떻게 할 계획입니까? –