간단한 용어로 3NF와 BCNF의 차이점 (8 세에게 설명 할 수 있어야 함)


157

인용문을 읽었습니다. 데이터는 키 [1NF], 전체 키 [2NF] 및 키 [3NF]에만 의존합니다 .

그러나 3.5NF 또는 BCNF를 이해하는 데 어려움을 겪고 있습니다. 내가 이해하는 것은 다음과 같습니다.

  • BCNF는 3NF보다 엄격
  • 테이블에서 FD의 왼쪽은 수 퍼키 (또는 적어도 후보 키) 여야합니다.

그렇다면 일부 3NF 테이블이 BCNF에없는 이유는 무엇입니까? 내 말은, 3NF 인용문은 명시 적으로 "키 외에는 아무것도 없다"고 말하며 모든 속성은 기본 키에만 의존한다는 것을 의미합니다. 기본 키는 결국 기본 키로 선택 될 때까지 후보 키입니다.

지금까지 나의 이해와 관련하여 잘못된 점이 있으면 저를 정정 해 주시고 도움을 주셔서 감사합니다.


그것은 출판 된 교과서 만이 개념에 대한 간결하고 정확한 설명을 제공 할 수 있다는 이상한 감정입니다. 이 (정말 오래된) 질문에 대한 답변을 보면, 등급이 매겨진 질문 중 모호하거나 부정확 한 것이 없다는 것을 알 수 있습니다. 대수적 정의를 갖는 것은 문제가되지 않았으며 실제 사례를 통해 개념을 이해하는 것이 문제였습니다. 내 원래 질문의 인용문에 관해서는 Google이 인용 부호의 원점을 찾도록 "나를 도와주세요" 그것에 대해 모호한 것은 없습니다.
Arnab Datta

1
교과서 이외의 출처에서 정보를 얻는다고 생각하는 곳은 어디입니까? 교과서도 많이 있지만 교과서는 학술 견습 과정을 가진 여러 사람들이 검토하며 다른 사람들의 교과서 해석보다 넌센스가 아닐 가능성이 큽니다. 정보가 없거나 잘못된 정보를 제공 한 사람들의 높은 평가는 무언가를 올바르게 만들지 않습니다. 나는 당신의 질문에 도착한 사람들을 위해 그 의견을 썼습니다. "키 외에는"라는 문구는 쓸모가 없습니다. "개념을 이해하는 것"이 ​​없으면 불가능하기 때문에 정확한 정의를 갖는 것이 확실히 문제입니다.
philipxy

답변:


162

피자는 정확히 세 가지 토핑 유형을 가질 수 있습니다.

  • 한 종류의 치즈
  • 한 종류의 고기
  • 한 종류의 야채

그래서 우리는 피자 두 개를 주문하고 다음 토핑을 선택합니다.

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

잠깐만 요, 모짜렐라는 치즈와 고기가 될 수 없습니다! 그리고 소시지는 치즈가 아닙니다!

모짜렐라는 항상 치즈가 되려면 이런 종류의 실수를 막아야합니다 . 이를 위해 별도의 테이블을 사용해야하므로 한 곳에서만 해당 사실을 기록합니다.

Pizza    Topping
-------- ----------
1        mozzarella
1        pepperoni
1        olives
2        mozzarella 
2        sausage
2        peppers

Topping     Topping Type
----------  -------------
mozzarella  cheese
pepperoni   meat
olives      vegetable
sausage     meat
peppers     vegetable

그것은 8 살짜리 아이가 이해할 수있는 설명이었습니다. 더 기술적 인 버전은 다음과 같습니다.

BCNF는 겹치는 후보 키가 여러 개인 경우에만 3NF와 다르게 작동합니다.

그 이유는 의 하위 집합 인 X -> Y경우 기능 종속성 이 물론 사실 Y이기 때문입니다 X. 따라서 후보 키가 하나만 있고 3NF 인 테이블에서는 키 이외의 항목에 기능적으로 종속되는 열 (키 또는 키가 아님)이 없으므로 이미 BCNF에 있습니다.

각 피자는 각 토핑 유형 중 정확히 하나를 가져야하므로 (피자, 토핑 유형)이 후보 키라는 것을 알고 있습니다. 우리는 또한 주어진 토핑이 동시에 다른 유형에 속할 수 없다는 것을 직관적으로 알고 있습니다. 따라서 (피자, 토핑)은 고유해야하므로 후보 키이기도합니다. 따라서 두 개의 겹치는 후보 키가 있습니다.

나는 우리가 mozarella를 잘못된 토핑 유형으로 표시 한 예외를 보여주었습니다. 우리는 이것이 틀렸다는 것을 알고 있지만, 틀리게 만드는 규칙 Topping -> Topping Type은이 테이블에 대한 BCNF의 유효한 종속성이 아닌 종속성입니다. 전체 후보 키가 아닌 다른 것에 대한 종속성입니다.

이를 해결하기 위해 Pizzas 테이블에서 Topping Type을 가져와 Toppings 테이블에서 키가 아닌 속성으로 만듭니다.


3
"전체 후보 키 이외의 다른 항목에 대한 종속성입니다." -감사합니다
gnsb

12
"따라서 하나의 후보 키만 있고 3NF에있는 모든 테이블에서"-확실하지 않습니다. 귀하가 제공 한 예가이 조건을 충족합니다. 그러나 2NF가 아니기 때문에 3NF 예제가 아닙니다. 키 (1NF), 전체 키 (2NF) 및 키 (3NF) 외에는 아무것도 없습니다. 키는 (Pizza, Topping)이며 ToppingType 열은 키에만 의존하지만 키에만 의존하지는 않지만 전체 키에 의존하지는 않습니다. 따라서 2NF가 아니므로 3NF 또는 BCNF가 아닙니다. 1NF입니다. 2NF로 만들면 설명하려는 문제를 무시할 수 있습니다.
Daniel Barbalace

4
@DanielBarbalace,이 테이블의 요점은이 테이블에 대한 다른 후보 키를 가지고 있다는 것입니다 : (Pizza, ToppingType). ToppingType은 해당 후보 키의 서브 세트이므로 2NF를 충족시킵니다.
Bill Karwin

6
공감해야해서 미안 해요 당신이 보여준 예는 3NF가 아닙니다. BCNF의 목적을 이해하려면 BCNF가 아닌 3NF에있는 예를보아야합니다. 지금은 BCNF의 목적이 보이지 않습니다.
Spero

5
왜 이것이 2NF에서 처리되지 않습니까? 내 관점에서, 원래 테이블의 기본 키는 Pizza + Topping이고 Topping Type은 Topping에 의존하므로 2NF 단계에서 처리해야 할 부분 의존성이 아닌가?
GreenPenguin

91

미묘한 차이점은 3NF는 키 속성과 비키 속성 ( 비 프라임 속성 이라고도 함 )을 구분하는 반면 BCNF는 그렇지 않습니다.

이는 Zaniolo의 3NF 정의 를 사용하여 가장 잘 설명 됩니다. Codd와 동일합니다.

다음 조건 중 하나 이상이 R에 의해 충족되는 모든 사소한 FD (X-> A)에 대해 관계 R은 3NF iff입니다.

(a) X는 R의 수 퍼키 이거나

(b) A는 R의 핵심 속성이다

BCNF는 (a)를 요구하지만 (b)는 특별한 경우로 취급하지 않습니다. 다시 말해, BCNF는 모든 중요하지 않은 결정 요인이 수 퍼키 여야하며, 종속 속성이 키의 일부인 경우에도 마찬가지입니다.

R이 만족하는 모든 사소한 FD (X-> A)에 대해 관계 R은 BCNF iff로 다음 조건에 해당합니다.

(a) X는 R의 수 퍼키입니다.

따라서 BCNF가 더 엄격합니다.

그 차이는 매우 미묘하여 많은 사람들이 비공식적으로 3NF로 묘사하는 것은 실제로 BCNF입니다. 예를 들어, 여기서 3NF는 "데이터는 키에 의존하고 키에만 의존하지 않는다"는 것을 의미하지만 실제로는 3NF가 아닌 BCNF에 대한 비공식적 인 설명입니다. 3NF는 "비키 데이터 는 키에 의존하고 ...

당신은 또한 말했다 :

3NF 인용문은 명시 적으로 "키 외에는 없음"을 나타내며 모든 속성은 기본 키에만 의존한다는 것을 의미합니다.

그것은 지나치게 단순화 된 것입니다. 3NF 및 BCNF 및 모든 일반 양식은 하나의 "기본"키가 아닌 모든 후보 키 및 / 또는 수 퍼키와 관련이 있습니다.


7
와. Zaniolo 교수는 실제로 내 수업 (CS 143, UCLA)을 가르치며 최종 시험을 준비하는 동안이 답변을 우연히 발견했습니다. 내 교수님의 이름을 볼 수있어서 자세한 답변을 주셔서 감사합니다!
DV.

3NF에 있지만 BCNF에는없는 관계의 예를들 수 있습니까? 내가 상상하기 힘든 ...
Leo

10
R {A, B, C} 여기서 {A, B}는 키입니다. C-> B의 의존성을 고려할 때, R은 BCNF가 아닌 3NF의 요구 사항을 만족시킨다.
nvogel 2016 년

2
키는 후보 키를 의미합니다. 키 속성 은 후보 키의 일부인 속성이며 AKA는 주요 속성 입니다.
nvogel

3
후보 키의 일부인 경우 속성이 중요합니다. 후보 키의 일부가 아닌 경우 비 프라임.
nvogel 2016 년

26

BCNF와 3NF의 차이점

BCNF 정의 사용

종속성 X → Y마다 하나 이상인 경우에만 다음 조건 중 하나 이상이 유지됩니다 .

  • X → Y는 사소한 기능 의존성 (Y ⊆ X)이거나
  • X는 스키마 R의 슈퍼 키입니다

그리고 3NF 정의

각 기능 종속성 X → A에 대해 다음 조건 중 하나 이상이 충족되는 경우에만 해당됩니다.

  • X에 A가 포함되어 있거나 (즉, X → A는 사소한 기능 의존성 임)
  • X는 슈퍼 키이거나
  • A와 X의 설정 차이 인 AX의 모든 요소는 주요 속성입니다 (즉, AX의 각 속성은 일부 후보 키에 포함됨)

간단한 용어로 다음과 같은 차이점이 있습니다.

  • BCNF에서 : 모든 부분 키 (프라임 속성)는 수 퍼키 에만 의존 할 수 있습니다 .

이므로

  • 3NF에서 : 부분 키 (프라임 속성)는 또한 슈퍼 키 가 아닌 속성 (예 : 다른 부분 키 / 프라임 속성 또는 비 프라임 속성)에 의존 할 수 있습니다 .

어디

  1. 주요 속성은 후보 키에있는 속성이며,
  2. 후보 키는 그 관계에 대한 최소한의 퍼키이며,
  3. 퍼키 는 해당 변수에 할당 된 모든 관계에서이 세트의 속성에 대해 동일한 값을 갖는 두 개의 별개의 튜플 (행)이 없음을 보유하는 관계 변수의 속성 세트입니다. 스키마의 모든 속성이 기능적으로 종속되는 관계 스키마의 속성 집합으로 정의됩니다. (수 퍼키는 항상 후보 키를 포함합니다. / 후보 키는 항상 수 퍼키의 하위 집합입니다. 관계에 속성을 추가하여 수 퍼키 중 하나를 얻을 수 있습니다.)

즉, 후보 키의 부분 서브 세트 (전체 세트를 제외하고 사소하지 않은 서브 세트)는 기능적으로 수 퍼키 이외의 다른 것에 의존 할 수 없습니다.

BCNF에없는 테이블 / 관계는 다른 사용자가 피자 예에서 언급 한 업데이트 예외와 같은 예외를 따릅니다. 운수 나쁘게,

  • BNCF는 없습니다 항상 얻을 수 있지만,
  • 3NF 는 항상 얻을 있습니다 .

3NF 대 BCNF 예

차이점의 예는 현재 Wikipedia의 " BCNF (Boyce–Codd normal form)을 충족하지 않는 3NF 테이블 "에서 찾을 수 있습니다 . 다음 테이블은 "테니스 코트"(일부 키 / 프라임 속성)에 따라 BNF가 아닌 3NF를 충족합니다. "Rate Type"(수 퍼키 가 아닌 부분 키 / 프라임 속성 )에 관한 것입니다. 이는 데이터베이스의 테니스 클럽에 고객에게 문의하여 결정할 수있는 종속성입니다.

오늘의 테니스 코트 예약 ( BCNF가 아닌 3NF )

Court   Start Time  End Time    Rate Type
------- ----------  --------    ---------
1       09:30       10:30       SAVER
1       11:00       12:00       SAVER
1       14:00       15:30       STANDARD
2       10:00       11:30       PREMIUM-B
2       11:30       13:30       PREMIUM-B
2       15:00       16:30       PREMIUM-A

테이블의 슈퍼 키는 다음과 같습니다.

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

3NF 문제 : 부분 키 / 프라임 속성 "Court"는 수 퍼키 이외의 것에 의존합니다. 대신 부분 키 / 프라임 속성 "Rate Type"에 의존합니다. 즉, 법원을 업그레이드하는 경우 사용자가 수동으로 요율 유형을 변경하거나 요율 변경을 적용하려면 수동으로 법원을 변경해야합니다.

  • 그러나 사용자가 법원을 업그레이드하지만 요율을 올리는 것을 기억하지 못하면 어떻게 될까요? 또는 법원에 잘못된 요율 유형을 적용하면 어떻게됩니까?

(기술적 인 용어로, "요금 유형"-> "코트"기능 종속성이 위반되지 않을 것을 보증 할 수 없습니다.)

BCNF 솔루션 : 위의 표를 BCNF에 배치하려면 주어진 관계 / 표를 다음 두 가지 관계 / 표로 분해 할 수 있습니다. 데이터베이스의 고객, 테니스 클럽의 소유자에게 문의하여 확인하십시오.)

요율 유형 ( BCNF 및 BCNF에 의해 암시되는 약한 3NF)

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

오늘의 테니스 코트 예약 ( BCNFBCNF 가 암시하는 약한 3NF)

Member Flag     Court     Start Time   End Time
-----------     -----     ----------   --------
Yes             1         09:30        10:30
Yes             1         11:00        12:00
No              1         14:00        15:30
No              2         10:00        11:30
No              2         11:30        13:30
Yes             2         15:00        16:30

문제 해결 : 이제 법원을 업그레이드하면 요율 유형에 이러한 변경 사항이 반영 될 수 있으며 법원에 잘못된 가격을 청구 할 수 없습니다.

(기술적 인 용어로, "Rate Type"-> "Court"기능 의존성을 위반하지 않을 것을 보장 할 수 있습니다.)


6

모든 좋은 답변. 간단한 언어로 작성하려면 [BCNF] 부분 키는 키에 의존 할 수 없습니다.

즉, 후보 키의 부분 서브 세트 (즉, 전체 세트를 제외한 임의의 비 사소 서브 세트)는 일부 후보 키에 기능적으로 의존 할 수 없다.


2
왜 안돼? R (A, B, C, D, E) 및 (A, B) 및 (C, D)는 후보 키라는 관계가 있다고 가정합니다. 그런 다음 AB-> D. AB는 R의 수 퍼키이므로 R은 BCNF에 있어야합니까? (물론, 이것을 이해하려고 노력하십시오.)
peteykun

3

' smartnut007 ', ' Bill Karwin '및 ' sqlvogel ' 의 답변 이 우수합니다. 그러나 이것에 대해 흥미로운 관점을 제시하겠습니다.

우리는 프라임 및 비 프라임 키를 가지고 있습니다.

프라임이 아닌 프라임이 어떻게 프라임에 의존하는지에 초점을 맞출 때 두 가지 경우가 있습니다.

비 프라임은 의존적이거나 그렇지 않을 수 있습니다 .

  • 의존하는 경우 : 전체 후보 키에 의존해야합니다. 이것은 2NF 입니다.
  • 의존하지 않을 때 : 의존성이 없거나 전 이적 의존성이있을 수있다

    • 전이 의존성조차도 : 어떤 정규화 이론이 이것을 다루고 있는지 확실하지 않습니다.
    • 전 이적으로 의존하는 경우 : 바람직하지 않은 것으로 간주됩니다. 이것은 3NF 입니다.

소수 간의 종속성은 어떻습니까?

이제 두 번째 또는 세 번째 NF로 소수 간의 종속성 관계를 다루지 않습니다 . 더 나아가 그러한 의존성은 바람직하지 않으며 따라서이를 해결하기위한 단일 규칙이 있습니다. 이것은 BCNF 입니다.

Bill Karwin 의 게시물 의 예를 참조하면 ' Topping '과 ' Topping Type '이 모두 주요 키이며 종속성이 있음을 알 수 있습니다. 그들이 의존성이없는 비 프라임 이었다면 3NF가 시작되었을 것입니다.

노트 :

BCNF의 정의는 매우 일반적이며 프라임과 프라임이 아닌 속성을 구별하지 않습니다. 그러나 위의 사고 방식은 2 차 및 3 차 NF 이후에도 일부 이상이 어떻게 침투되는지 이해하는 데 도움이됩니다.

고급 주제 : 일반 BCNF를 2NF 및 3NF로 매핑

이제 BCNF가 프라임 / 프라임 이외의 속성을 참조하지 않고 일반적인 정의를 제공한다는 것을 알았으므로 BCNF와 2/3 NF가 어떻게 관련되는지 봅시다.

먼저, BCNF는 (사소한 경우를 제외하고) 각 기능 의존성 X -> Y(FD)에 대해 X가 수 퍼키 여야한다고 요구합니다. FD를 고려하면 (1) X와 Y 비 프라임 모두, (2) 프라임과 (3) X 프라임과 Y 비 프라임 모두 세 가지 경우가 있습니다. -프라임 및 Y 프라임.

(1)의 경우, 3NF가 처리합니다.

사례 (3)의 경우, 2NF가 처리합니다.

사례 (2)의 경우 BCNF의 사용을 찾습니다.


3

이것은 귀중한 답변이있는 오래된 질문이지만 3NF의 문제를 보여주는 실제 사례를 찾을 때까지 여전히 혼란 스럽습니다. 8 살짜리 아이에게는 적합하지 않지만 도움이되기를 바랍니다.

내일 나는 분기 별 부모 / 교사 회의 중 하나에서 장녀의 선생님들을 만날 것입니다. 내 일기의 모습은 다음과 같습니다 (이름과 방이 변경되었습니다).

Teacher   | Date             | Room
----------|------------------|-----
Mr Smith  | 2018-12-18 18:15 | A12 
Mr Jones  | 2018-12-18 18:30 | B10 
Ms Doe    | 2018-12-18 18:45 | C21 
Ms Rogers | 2018-12-18 19:00 | A08 

한 방에 한 명의 선생님 만 있으며 절대 움직이지 않습니다. 당신이보고있는 경우, 당신은 그것을 볼 수 있습니다 : (1) 모든 속성에 대해 Teacher, Date, Room, 우리는 행 당 하나 개의 값을 갖는다. (2) 슈퍼 키는 다음과 같습니다 (Teacher, Date, Room), (Teacher, Date)그리고 (Date, Room)후보 키는 분명히있다 (Teacher, Date)(Date, Room).

(Teacher, Room) 다음 분기에 테이블을 완성하고 다음과 같은 행을 가질 수 있기 때문에 수 퍼키가 아닙니다. (미스터 스미스는 움직이지 않았습니다!) :

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

우리는 무엇을 결론 내릴 수 있습니까? (1)은 1NF의 비공식이지만 정확한 공식입니다. (2)에서 우리는 "비 소위 속성"이 없음을 알 수 있습니다 : 2NF와 3NF는 무료로 제공됩니다.

내 일기는 3NF입니다. 좋은! 아니요. 실제로 데이터 모델러가 DB 스키마에서이를 허용하지 않기 때문은 아닙니다. Room속성은에 따라 다릅니다 Teacher(다시! : 교사가 이동하지 않습니다) 속성하지만 스키마가이 사실을 반영하지 않습니다. 제정신 데이터 모델러는 무엇을합니까? 테이블을 두 개로 나누십시오.

Teacher   | Date
----------|-----------------
Mr Smith  | 2018-12-18 18:15
Mr Jones  | 2018-12-18 18:30
Ms Doe    | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

그러나 3NF는 주요 속성 종속성을 처리하지 않습니다. 이것이 문제입니다. 3NF 준수는 일부 상황에서 사운드 테이블 스키마 설계 를 보장하기에 충분하지 않습니다 .

BCNF를 사용하면 속성이 프라임 속성인지 2NF 및 3NF 규칙이 아닌지 상관하지 않습니다. 모든 사소한 의존성 (하위 집합이 하위 집합에 의해 결정됨)에 대해 결정자는 완전한 수 퍼키입니다. 다시 말해, 완전한 수 퍼키 (사소한 FD 제외) 이외의 것으로 결정된 것은 없습니다 . (정식 정의에 대한 다른 답변을 참조하십시오).

마자 Room에 따라 Teacher, Room의 하위 집합이어야합니다 Teacher(그렇지 않다가) 또는 Teacher슈퍼 키를해야합니다 (내 일기의 경우 아니지만, 테이블을 분할하는 경우를 먹으 렴).

요약하면 : BNCF는 3NF보다 더 엄격하지만 제 생각에는 이해하기 쉽습니다.

  • 대부분의 경우 BCNF는 3NF와 동일합니다.
  • 다른 경우에, BCNF는 3NF가 생각 / 희망하는 것입니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.