두 번째 정규 형식 (2NF)에 문제가 있으며 Google을 사용하여 문제를 해결할 수 없습니다. 나는 선생님이기 때문에 나를 미치게 만들고 있으며 학생들에게 잘못된 것을 가르치고 싶지 않습니다.

5 개의 필드가있는 테이블을 보자.

채점 = {학생 이름, 과목 코드, 과목 이름, # 시험, 학년}

종속성은 다음과 같습니다.

StudentName, SubjectCode, # 시험-> 학년

SubjectCode-> SubjectName

SubjectName-> SubjectCode

따라서 후보 키 1은 {StudentName, SubjectCode, #Exam} 이고 후보 키 2는 {StudentName, SubjectName, #Exam} 입니다.

프라임 속성은 {StudentName, SubjectCode, SubjectName, #Exam} 이고 비 프라임 속성은 Grade입니다.

제 2 정규형의 정의에 따르면, 비 프라임 속성은 후보 키의 일부에 의존 할 수 없다. 비 프라임 속성 (Grade)은 후보 키의 일부에 의존하지 않으므로이 테이블은 2NF로 보입니다.

문제는 무언가가 잘못되었다고 생각한다는 것입니다 (그리고 나는 틀릴 수 있습니다). 피험자들은 각자의 테이블을 가져야한다고 생각합니다.

채점 = {학생 이름, 과목 코드, # 시험, 학년}

과목 = {제목 코드, SubjectName}

그러나 2NF는 이것을 생산하지 않습니다. 3NF는 비 프라임 속성 간의 종속성에 관한 것이므로이 속성도 생성하지 않습니다. 그러나 중복성이 없기 때문에 이것이 올바른 결과 인 것 같습니다.

프라임이 아닌 속성이 "후보 키가 아닌 속성"으로 정의 된 경우 2NF가 원하는 결과를 생성합니다. 그러나 나는 이것을 반복해서 확인했으며 프라임이 아닌 속성은 "후보 키에 속하지 않는 속성"으로 정의됩니다.

내가 뭘 잘못하고 있죠?

소수가 아닌 유일한 속성은 Grade 이며 FD의 오른쪽에만 표시 되므로 관계는 3NF이며 2NF 에만 있습니다.

두 개의 작은 FD의 왼쪽이 수 퍼키가 아니기 때문에 관계는 BCNF에 없습니다.

그러나 ( SubjectCode , SubjectName ) 및 ( StudentName, SubjectCode, #Exam, Grade ) 또는 ( StudentName, SubjectName, #Exam, Grade ) 와의 관계를 무손실로 분해 할 수 있습니다.

이 분해는 두 가지 BCNF 관계를 제공하고 모든 기능 종속성을 유지합니다. 항상 가능하지는 않습니다 (항상 3NF와의 관계를 분해 할 수 있지만 반드시 BCNF와의 관계는 아닙니다).

2NF

2NF (3NF 아님)의 예를 원하면 관계에 전이 종속성이 포함되어야합니다.

예를 들어 점수 열이 있다고 가정합니다. 직관적으로 점수-> 같은 점수를 가진 모든 시험은 같은 등급을 받아야하므로 (그렇지 않은 경우 다소 불공평하지만) 여러 점수가 동일한 등급 (11 % 및 12 %)을 가질 수 있으므로 Grade-> 점수를 말할 수 없습니다. 예를 들어 "실패"일 수 있습니다.

이제 당신의 관계는 :

채점 ( StudentName, SubjectCode, SubjectName, #Exam, Score, Grade )

다른 등급 기록과 동일한 점수를 가진 결과를 입력 할 때마다 해당 등급을 반복해야하기 때문에 새로운 형태의 중복성이 있습니다. 따라서 3NF에 도달하기 위해 분해 할 수 있습니다.

ScoreGrades ( 점수, 성적 )

와 점수 키로하고,

점수 ( StudentName, SubjectCode, SubjectName, #Exam, Score )

당신은 당신이 말하는 모든 것에 옳습니다. 원하는 종속성을 적용하려면 SubjectCode, SubjectName이 자체 테이블로 이동해야합니다. 이것이 2NF와 3NF가 좋은 데이터베이스 디자인을 생성하기에 충분하지 않은 이유의 좋은 예입니다. 대신 BCNF (Boyce Codd Normal Form)가 필요합니다.

2NF와 3NF는 BCNF로 대체되어 실제로는 NF가 덜 쓸모 없게됩니다. BCNF는 설명하고 적용하는 것이 더 중요하고 논란의 여지가 없습니다. 교사로서 저는 BCNF에 더 많은 시간을 보내고 2NF와 3NF에 더 적은 시간을 보내라고 제안합니다. 표가 BCNF의 요구 사항을 충족하면 2NF 및 3NF도 만족합니다.

* 3NF는 의존도가 가장 높은 정규 형식이 아닙니다. 기본 키 표준 양식 (EKNF)입니다. 엄밀히 말하면 3NF를 쓸모 없게 만드는 것은 BCNF가 아닌 EKNF이지만, EKNF는 부주의하게 무시되며 대부분의 교과서와 과정에서는 언급하지 않습니다. BCNF로 디자인 한 다음 원하는 모든 종속성 및 기타 무결성 규칙을 올바르게 적용 할 수 있는지 확인한 다음 그렇지 않은 경우 디자인을 수정하십시오. NF 중 어느 것도 데이터 무결성에 대한 완벽한 솔루션은 아니지만 BCNF는 일반적으로 가장 가깝고 설명하고 사용하기가 가장 쉽습니다.

나는이 모든 것을 처음 배운 이후 얼마나 오래 걸렸는지는 말할 수 없습니다. 그러나 나는 "기능적 의존성"과 "프라임이 아닌 속성"과 다른 모든 유행어의 올바른 의미를 정직하게 가르친 후, 우리에게 특정한 정상인지를 묻는 일련의 간단한 질문을했던 교수를 기억합니다. 양식에 도달했습니다. 내가 너무 멀리 기억할 수 있는지 보자 ...

후보 키를 확인 했으므로 나머지 비 프라임 속성에 대해이 질문을합니다. 이 경우 등급은 하나뿐입니다.

등급을 고유하게 식별하기 위해 필요한 최소한의 정보는 무엇입니까? 우리는 학생, 과목 및 시험을 알아야합니다. 좋아, 이것은 후보 키 중 하나입니다.

편집 : VVV

그러나 답은 학생 이름, 과목 이름 및 시험일 수도 있습니다. 이것은 두 번째 후보 키와 일치합니다.

SubjectCode와 SubjectName이 Subject 엔티티의 후보 키라고 가정하면,이 두 필드를 모두 여기에 둘 이유가 없습니다. 주제 테이블의 행에 대한 하나의 고유 한 참조로 충분합니다. 따라서 모델의 무결성을 희생하지 않으면 서 SubjectName 필드를 완전히 제거 할 수 있습니다.

그러나 원래의 대답에서 다른 수준의 정규화를 보여주기 위해 SubjectName이 후보 키에 사용되었다는 것을 무시하고 다른 비 프라임 속성으로 간주했습니다. 나는 그것이 쓸모없는 필드라는 것이 나에게 너무 명백했다고 생각한다. 나는 그것이 모두에게 명백 할 것이라고 생각했다.

그러나 답변의 해당 부분을 제거하는 대신 비교를 위해 계속하겠습니다.

편집 종료 : ^ ^ ^

주제 이름을 고유하게 식별하는 데 필요한 최소 정보는 무엇입니까?

SubjectName은 후보 키의 하위 집합 인 SubjectCode에만 종속됩니다. 따라서이 튜플은 2nf에 없습니다. SubjectCode는 SubjectName을 배치하기에 적합한 위치가되도록 Subjects 테이블의 기본 키 여야합니다. 이 튜플에서 제거하면 2nf에 있습니다.

속성에 대한 질문을하고 답변이 후보 키의 전부 또는 일부가 아닌 경우 튜플은 3nf가 아닙니다. 그러나이 튜플은 3nf 이상에서도 사소하게 나타납니다. ;)

참고 : "정규화"라고 할 때는 논리 엔터티에 적용되는 프로세스를 말합니다. 제공된 튜플은 "grade"라는 엔티티의 정의 인 것처럼 보이므로 정규화 할 수 있습니다. 그러나, 한 지점에서 좀 더 제대로 했어야하는 "이 튜플, 2NF에없는"며 "이 엔티티가 2NF에 있지 않습니다." 이것이 혼란을 초래 한 경우 사과드립니다.

비 프라임 속성 (Grade)은 후보 키의 일부에 의존하지 않으므로이 테이블은 2NF로 보입니다.

2NF입니다.

문제는 무언가가 잘못되었다고 생각한다는 것입니다 (그리고 나는 틀릴 수 있습니다). 피험자들은 각자의 테이블을 가져야한다고 생각합니다.

피험자들이 원래의 테이블을 2NF로 분해하기 위해 자신의 테이블 을 가져야 할 이유는 없다 . 당신은 어떤 "정상적인"형태가 실제로 당신에게주는 것과 "모호해야한다"라는 모호한 개념을 혼동하고 있습니다.

3NF는 비 프라임 속성 간의 종속성에 관한 것이므로이 속성도 생성하지 않습니다.

"3NF는 비 프라임 속성 간의 종속성에 관한 것"은 3NF의 적절한 정의가 아니므로 "이것도 생성하지 않습니다"는 건전한 결론이 아닙니다. 실제 정의를 적용해도 테이블이 3NF이고 학생 테이블이 필요하지 않음을 보여줍니다. 그러나 다시 그럴 것이라고 기대할 이유가 없습니다.

그러나 중복성이 없기 때문에 이것이 올바른 결과 인 것 같습니다.

"중복성"도 도움이되지 않으므로 모호한 점과 학생 테이블 기대치가 좋지 않습니다. 상이한 정상 형태에는 특정 종류의 이상 및 관련 "중복성" 이 없으며 그에 종속된다 . 그러나 정규화로 해결되지 않은 다른 "중복"은 남아있을 수 있습니다.

이 테이블에는 CK를 벗어난 FD가 있으므로 BCNF에 없습니다. BCNF에 따라 분해하면 학생 테이블이 생깁니다. BCNF는 FD와 함께 제공되는 JD (join dependencies)를 처리하기위한 가장 일반적인 형식입니다. 그러나 다른 JD는 문제가 될 수 있으며 (즉, "CK에 의해 암시되지 않음") 5NF로 정규화하여 제거해야합니다.

PS 원본 테이블은 FD {StudentName, SubjectName, #Exam}-> Grade도 충족합니다.

종속성은 다음과 같습니다.

이것은 무엇을 의미합니까? 명확하지 않습니다.

"이것은 모두 사소한 FD입니다"를 의미합니까? 아니요, 네 번째를 의미하기 때문입니다. "여기에 보유하고있는 일부 FD가 있습니까?" 아니, 수단이 전이 폐쇄 보류에 FDS는하지만, 다른 사람이 있다는 말을하지 않는 것을 하지 않는 채 아직 당신이 CKs의를 확인할 수 있었다. "보유하는 FD는 정확히 이것들의 전 이적 폐쇄에있는 것"입니까? 당신이 그것을 의미 했다면 , 당신이 그것을 보여 주었을 때만 알 것입니다 . 즉, 당신은 그 폐쇄 (일반적으로 최소 / 표준 커버를 통해)를 발견하고 다른 FD가 없다는 것을 보여 주어야 할 것입니다; 당신은? 어쨌든, 당신이 쓴 것은 그 의미가 아닙니다. FD & CK 상황에 대해 건전하게 추론하지 않기를 바랍니다.

당신은 맞습니다. 과목에는 자체 테이블이 필요합니다. 당신은 당신의 후보 키 중 하나를 선택, 어느 경우 subject_code또는 subject_name기본이 아닌 후보 키가됩니다. 그런 다음 성적표에서 기본이 아닌 주제 필드를 제거하십시오.

두 개의 고유 식별자가있는 주제에 대한 기능적 종속성이 있습니다. 이것은 간의 전이 의존성에 의해 입증된다 subject_code하고 subject_name. 이는 두 필드를 포함하는 테이블을 작성하고이 필드 중 하나를 다른 모든 테이블에서 제거해야한다는 것을 나타냅니다. 이 테이블에는 추가 종속 열이있을 수 있지만이 예에서는 아무것도 표시되지 않습니다. 세 번째 일반 형식으로 선택했습니다.

성적은 새 성적표의 다른 세 필드 (후보 키)에 따라 다릅니다. 위에서 언급했듯이 주제 테이블에 대한 후보 필드 중 하나를 선택해야합니다. 일반적으로 가능한 경우 코드 값이 더 안정적이므로 코드 값이됩니다. 키가 아닌 모든 필드가 기본 키의 필드에 완전히 종속되므로 결과 모델은 3nf입니다.

문제점 (요구 사항)에 대한 추가 분석은 마크가 적용되는 세션 테이블을 생성 할 수 있습니다. 현재 모델은 코스를 반복하는 학생을 포함하지 않을 것입니다. 이 내용은 다음 단원에서 다룰 것입니다.

같은 이름을 가진 여러 명의 학생이있을 수 있으므로 학생들은 별도의 테이블이 될 수 있습니다. 이것은 합성 기본 키 (학생 번호?)를 추가하여 해결할 수 있습니다.

subjects --->  sessions ---+--> grades
students  -----------------+

잘못된 것으로 간주되어 삭제를 준비 중입니다.

주제 이름은 또한 기본이 아닌 속성이며 기본 키 주제 코드의 일부에 의존합니다 (규칙 위반-기본 키에 대한 열의 부분 종속성이 없어야 함).

이것은 두 번째 정규 양식에서 금지되어 있으며 의심 되는대로 자체 테이블에 배치해야합니다.

나는 당신이 어디에 두지 않았는지 두 개의 후보 키 세트를 식별하는 것이라고 생각합니다. 테이블을 만들 때 기본 키를 만들기 위해 하나의 후보 키 세트를 선택해야합니다. 나머지 열은 기본이 아닌 속성이됩니다. 즉, 두 번째 후보 키를 선택한 경우 주제 코드는 기본 키 (주제 이름)의 일부에 따라 기본이 아닌 속성이되며 자체 테이블에 배치해야합니다.

제 1, 제 2, 제 3 정규형은 서로 쌓을 때 순서대로 가르치는 것이 중요합니다. BCNF는 본질적으로 3 차 정규형으로의 확장이므로 하위 레벨에 대한 강력한 이해가 필수적입니다.

더욱이; 숙련 된 개발자는 많은 규칙이 직관적이기 때문에 독립적 인 정규화 수준을 고려하지 않습니다.

또한 특정 설계 및 최적화 문제를 해결하기 위해 정규화 규칙을 어기는시기도 알게됩니다. 정규화는 엄격한 규칙이 아닌 좋은 디자인에 대한 지침으로 취급되어야하며, 나는 또한 좋은 가르침 포인트라고 생각합니다.