Chapter 14: 정규화

14.1 배경

• 우리는 관계형 모델과 언어의 다양한 측면을 다루었습니다.

• 관계 스키마: 여러 속성을 가짐.

• 관련 속성들은 "상식"이나 매핑에 의해 관계 스키마로 그룹화됨.

• 관계형 데이터베이스: 여러 (관련된) 관계 스키마들

• Q: 어떤 속성 그룹화가 다른 것보다 관계 스키마에 더 나은 이유를 어떻게 분석할 수 있을까요? 이 장에서 이 질문에 답할 것입니다.

• 관계형 데이터베이스 설계의 두 가지 암묵적이고 중요한 목표: 정보 보존과 최소 중복

• 모든 개념을 보존하는 것? 저장 공간 최소화와 여러 번의 갱신 줄이기?

• 이 주제에서 우리는 설계 품질, 관계 스키마의 좋음을 평가하는 목표를 가진 이론의 일부를 탐구할 것입니다.

하향식 설계

• 속성에서 시작,

• 속성을 그룹화하여 엔티티 및/또는 약한 엔티티 식별

• 엔티티 간의 관계 식별

• 엔티티들 사이의 관계 만들기

• 데이터베이스 설계 점진적 정제 => ER 설계

상향식 설계

• 하나의 통합된 관계에서 속성 그룹으로 시작하여 더 작은 관계로 분해

• 설계 점진적 정제 => 오늘의 초점인 정규 형태를 사용한 관계 정규화

관계 스키마에 대한 비공식적 지침

• 관계 스키마 설계 품질을 결정하기 위한 척도로 사용될 수 있음

• 속성의 의미를 확실히 하는 것

• 튜플 내의 중복 정보 줄이기

• 튜플 내의 NULL 값 줄이기

• 비합리적인 튜플 생성 가능성 배제

• 이러한 척도들은 항상 서로 독립적이지 않음, 우리가 보게 될 것처럼.

G1) 관계 내 속성에 명확한 의미 부여

• 지침 1: 비공식적으로, 관계 내의 각 튜플은 하나의 엔티티나 관계 인스턴스를 나타내야 함. (개별 관계와 그 속성에 적용됨.)

• 다른 엔티티들의 속성(EMPLOYEEs, DEPARTMENTs, PROJECTs)은 같은 관계에 혼합되어서는 안 됨.

• 다른 엔티티를 참조하는 것은 오직 외래 키를 사용해야 함

• 엔티티와 관계 속성은 가능한 한 분리되어 유지되어야 함.

• 결론:
• 관계별로 쉽게 설명할 수 있는 스키마를 설계함.
• 속성의 의미가 쉽게 해석될 수 있어야 함.

G2) 튜플과 갱신 이상에서 중복 정보 최소화

• 스키마 설계의 한 목표:
• 기본 관계와 해당 파일이 사용하는 저장 공간을 최소화함.
• 정보가 중복으로 저장되면,
• 저장 공간을 낭비하고, 더 근본적으로,
• 갱신 이상(update anomalies) 문제를 야기함, 다음으로 분류됨:
• 수정(또는 갱신) 이상
• 삽입 이상
• 삭제 이상

수정 이상의 예

• EMP_PROJ라는 관계를 고려해보세요(EMP., PROJ., WOR.에 NATURAL JOIN을 적용한 후의 투영 결과).

• "수정 이상"

• 프로젝트 번호 10의 이름을 "컴퓨터화"에서 "고객-회계"로 변경하는 것

• 이것은 프로젝트 번호 10에서 일하는 "모든" 직원들(예: '333...', '999...', '987...')에 대해 이 갱신이 이루어질 수 있음. 왜 그럴까요?
• BTW, 이것은 슬라이드 9에서 일어나지 않습니다. 왜 그럴까요?

삽입 이상의 예

• EMP_PROJ라는 관계를 고려하세요(EMP., PROJ., WOR.에 NATURAL JOIN을 적용한 후의 투영 결과).

• "삽입 이상"
1. 한편으로, 직원이 할당되지 않은 프로젝트를 삽입할 수 없습니다. 어떻게 삽입할 수 있을까요? 어떤 위반인가요?
2. 반대로, 직원이 프로젝트에 할당되지 않으면 직원을 삽입할 수 없습니다. 어떻게 삽입할 수 있을까요? 어떤 위반인가요?

• 슬라이드 9에서 발생하지 않습니다. 왜 그럴까요?

삭제 이상의 예

• EMP_PROJ라는 관계를 고려하세요(EMP., PROJ., WOR.에 NATURAL JOIN을 적용한 후의 투영 결과).

• "삭제 이상"
1. 프로젝트가 삭제되면 해당 프로젝트에서 일하는 "모든" 직원들이 삭제될 것입니다.
2. 대안적으로, 직원이 프로젝트에서 "유일한" 직원이라면, 해당 직원을 삭제하면 해당 프로젝트가 삭제될 것입니다.

• 슬라이드 9에서 발생하지 않습니다. 왜 그럴까요?

갱신 이상에 시달리는 또 다른 예: EMP_DEPT=EMP.*DEPT.

• 그러나 성능상의 이유로 일부 경우 EMP_DEPT와 EMP_PROJ는 기본 관계로 저장될 수 있습니다. 예제는?

G2) 튜플과 갱신 이상에서 중복 정보 최소화 (계속)

• 지침 2: (그러므로) 삽입, 삭제, 갱신 이상에서 고통받지 않는 스키마를 설계하세요.

• 이상이 존재한다면, 응용 프로그램이 이를 고려하여 만들 수 있도록 주목하세요.

G3) 튜플에서 NULL 값의 사용 최소화

• 지침 3: 관계는 가능한 한 적은 NULL 값을 가질 속성들로 할당되어야 합니다.

• 자주 NULL인 속성을 피할 수 없다면, PK와 함께 별도의 관계에 배치될 수 있습니다.

• NULL의 이유를 상기시키기 위해:
1. 속성이 적용되지 않거나 무효인 경우: 예를 들어, 한국 학생에게는 '비자 상태'가 적용되지 않음.
2. 알려지지 않은 속성 값(존재할 수 있음): 예를 들어, 아직 어떤 부서에도 배정되지 않은 직원
3. 존재하지만 사용할 수 없거나 부재인 속성 값: 예를 들어, 아직 데이터베이스에 기록되지 않은 집 전화번호

잘못된 투영으로 인한 가짜 튜플 생성

• EMP_PROJ1과 EMP_LOCS의 튜플에 NATURAL JOIN을 적용한 결과로서, Ssn = “123456789”인 직원에 대해서만 생성됨.

• 가짜 튜플 생성 - 왜 이 문제가 발생하나요??

• EMP_PROJ를 EMP_LOCS와 EMP_PROJ1로 분해하는 것은 바람직하지 않습니다. 왜 그럴까요?
• EMP_PROJ1 * EMP_LOCS의 결과는 원래의 정확한 정보가 아닙니다.
• Plocation은 두 테이블 중 어느 곳에서도 PK 또는 FK가 아닙니다.
• 이는 PK 또는 FK에 대한 "적절한" 속성(들)을 선택하는 것이 중요함을 시사합니다.

• 관계형 데이터베이스에 대한 나쁜 설계는 특정 JOIN 작업에 대해 잘못된 결과를 초래할 수 있습니다.

• [중요] 따라서, "손실 없는 조인" 속성은 조인 작업에 대해 의미 있는 결과를 보장하기 위해 사용됩니다.

G4) 손실 없는 조인 조건 충족

• 지침 4: 손실 없는 조인 조건을 충족하는 관계 스키마를 설계하세요.
• 즉, 관계는 적절하게 관련된 속성(PK, FK) 쌍에 대한 동등 조건으로 조인되어야 합니다.
• 그렇지 않으면 가짜 튜플이 생성될 수 있습니다.
• 어떠한 (분해된) 관계의 NATURAL JOIN을 통해 가짜 튜플이 생성되어서는 안 됩니다.

G4) 손실 없는 조인 조건 충족 (계속)

• 관계의 "분해"에 대한 두 가지 중요한 속성
1. 해당 조인의 비중독적 또는 손실 없음 (특정 조인이 가짜 튜플을 생성하지 않는다는 것을 보장하는 공식적인 조건이 있으며, 곧 논의될 것입니다.)
2. 함수적 종속성의 보존 (곧 논의될 것)

• 주목할 점:
• 1)는 매우 중요하므로, 희생되거나 타협될 수 없습니다.
• 2)는 덜 엄격하므로 주로 성능 향상 때문에 희생될 수 있습니다.

관계 스키마에 대한 비공식적 지침 요약

• 지침 1: 비공식적으로, 관계 내의 각 튜플은 하나의 엔티티나 관계 인스턴스를 나타내야 합니다.
• 개별 관계와 그 속성에 적용됩니다.

• 지침 2: 삽입, 삭제, 갱신 이상에서 고통받지 않는 스키마를 설계하세요.

• 지침 3: 관계는 가능한 한 적은 NULL 값을 가질 속성들로 할당되어야 합니다.

• 지침 4: 손실 없는 조인 조건을 충족하는 관계 스키마를 설계하세요.

14.3 함수적 종속성

• 이전까지는 데이터베이스 디자인의 비공식적인 측정 방법에 대해 논의해왔습니다.

• 이제 우리는 관계 스키마의 분석을 위한 "공식적인" 도구를 소개합니다.

• 가장 중요한 개념 중 하나: 함수적 종속성(Functional Dependencies)

함수적 종속성 (Functional Dependency)

• 데이터베이스(DB)에서 두 속성 집합 간의 제약 조건.
• 데이터 속성의 의미와 상호관계로부터 유도됨.

• 관계형(데이터베이스) 설계의 "좋음"에 대한 공식적인 척도를 명시하는 데 사용됨.
• 키는 관계의 정규 형태를 정의하는 데 사용됨.

• 보다 구체적으로,
• 속성 집합 가 속성 집합 를 함수적으로 결정한다는 것은 의 값이 의 "유일한" 값을 결정한다는 것을 의미함.
• "함수적으로" ≡ "유일하게"

• 정의: 두 속성 집합 와 사이의 함수적 종속성(FD), 는 의 부분집합인 와 가 관계 상태 의 을 형성할 수 있는 튜플에 대한 제약을 명시함.
• 의 두 튜플 과 가 를 가지면, 도 가져야 함.
• : FD의 왼쪽, : FD의 오른쪽
• 튜플의 구성요소의 값이 에서 구성요소의 값에 따라 의존(또는 결정됨)한다는 것을 의미함.
• 는 두 튜플이 에 대해 같은 값을 가질 때마다 에 대해서도 같은 값을 가져야 할 때 성립함.
• FD는 속성에 대한 실제 세계의 제약으로부터 유도됨.
• 다음 슬라이드를 참조.

COMPANY에서의 FD 제약 조건 예시

• 사회보장번호는 직원 이름을 결정함.
• Ssn → Ename

• 프로젝트 번호는 프로젝트 이름과 위치를 결정함.
• Pnumber → {Pname, Plocation}

• 직원의 사회보장번호와 프로젝트 번호는 직원이 프로젝트에서 일주일에 일하는 시간을 결정함.
• {Ssn, Pnumber} → {Hours}

• FD는 스키마 의 속성의 속성임.

• 제약 조건은 "모든" 관계 인스턴스 에서 유지되어야 함.

• 의 키 가 의 모든 속성을 함수적으로 결정함, 같은 값: 을 가진 두 "구별된" 튜플이 있어서는 안 됨.
• 가 의 후보키이면 .
• 일지라도, 인지 여부는 에서 명시되지 않음.
• 결론적으로, FD의 주요 사용은 관계 스키마 R을 "더 자세히" 설명하기 위해, 모든 시간에 유지되어야 하는 속성에 대한 제약을 명시하는 것임.

관계 인스턴스에서 FD 정의

• FD를 정의하려면 관련 속성의 의미와 속성 간의 관계를 이해해야 함.

• 관계 인스턴스가 주어지면 특정 속성 간에 FD가 존재할 수 있음.
• 예. CAR에서, {State, Driver_license_number} → {Ssn}

• 특정 FD는 존재하지 않음, 왜냐하면 이러한 종속성을 위반하는 튜플이 있기 때문.
• 예. PROJECT에서, {Plocation} → {Pnumber}는 존재하지 않음. 왜 그럴까?
• 슬라이드 9의 PROJECT 참조.

FD 배제

• FD는 속성의 의미를 아는 사람이 명시적으로 정의해야 함(우리가 PK를 명시적으로 선언하는 것처럼).

• TEACH 관계의 다음 관계 상태를 고려함.
• FD, Text → Course,는 "현재에만" 존재할 수 있음. 왜 그럴까?

이것은 TEACH 관계에서 Text가 Course에 종속되는 FD라는 의미입니다. 즉, 현재 상태에서 Text가 Course에 종속되어 있지만 미래에는 그렇지 않을 수 있습니다. 이것은 TEACH 관계의 특성에 따라 Text가 현재 Course에만 종속되어 있고, 미래에는 다른 속성에 종속될 수 있다는 것을 나타냅니다.

• 다음 FD를 배제할 수 있음:
• Teacher → Course, Teacher → Text, Course → Text.

어떤 FD가 존재할까?

• A의 값이 B의 값을 결정한다고 보기 어렵다. a1은 b1과 b2 모두와 관계가 있다.

• A의 값이 C의 값을 결정하지 못한다. a1은 c1과 c2 두 값을 가진다.

• A와 B의 조합은 C의 값을 결정하는 것으로 보인다. (a1, b2)는 항상 c2를, (a2, b2)는 c2를, 그리고 (a3, b3)는 c4를 가진다.

• C의 값은 D의 값을 결정하지 못한다. c2는 d2와 d3 두 값을 가진다.

• {A, B} → C

함수적 종속성(FD)을 시각적으로 나타내는 도표적인 표기법

관계 정규화

• 정규화 (Normalization): Codd에 의해 1972년에 제안됨
• 관계를 취하여 일련의 테스트를 실행하여 해당 관계가 특정 정규형을 만족하는지 확인함.
• 불만족스러운 "나쁜" 관계들을 분해하는 과정으로, 속성들을 "더 작은" 관계들로 나눔. (수학에서 정규화는 어떻게 해석되는가?)

수학적으로 정규화는 데이터의 관계나 구조를 형식적인 규칙에 따라 분해하고 정리하는 프로세스입니다. 이것은 데이터를 더 작은 부분으로 나누고 부분 간의 관계를 정확하게 정의함으로써 데이터 구조를 개선하는 것을 의미합니다.

• 실제로 수행되어 결과적인 설계가 고품질이 되고 (1) 중복을 최소화하며 (2) 업데이트 이상을 최소화하는 것을 목표로 함.

• 비교, 역정규화(Denormalization)
• 더 높은 정규형 관계의 조인을 낮은 정규형의 기본 관계로 저장하는 과정.
• 예. 슬라이드 14의 EMP_DEPT

정규 형태 (NF)

• 관계의 상태를 의미하며, 해당 관계의 키와 함수적 종속성(FDs)을 사용하여 관계 스키마가 특정 정규 형태에 있는지 인증함.
• 관계가 충족하는 가장 높은 (정규 형태) 조건을 가리킴.
• 관계가 얼마나 "정규화"되었는지를 나타냄.

• NF의 수준
• 1NF, 2NF, 3NF, 그리고 보이스-코드 NF (BCNF) (3NF의 강화된 정의): 관계 스키마의 키와 FDs를 기반으로 함.
• 그 외에,
• 4NF: 키와 다중값 종속성(MVDs)을 기반으로 함.
• 5NF: 키와 조인 종속성(JDs)을 기반으로 함.

• 데이터베이스 설계자는 성능상의 이유로 최고 수준의 정규 형태로 정규화할 필요가 없음:
• 실제로는 주로 3NF와 BCNF까지 사용됨; 4(5)NF는 드물게 사용됨.

첫 번째 정규 형태 (1NF)

• 기본적인 (평면적인) 관계형 모델에서 관계의 공식 정의의 일부로 간주됨.

• 다음과 같은 것들을 허용하지 않음:
• 복합 속성
• 다중값 속성 (MVAs)
• 중첩된 관계 (NRs)
• 개별 튜플에 대한 값이 비원자적인 속성:
• 단일 튜플에 대한 값의 집합, 튜플의 값, 또는 두 가지의 조합
• 관계 내의 관계 또는 튜플 내의 속성 값으로서의 관계

• 대부분의 RDBMS는 1NF에 있는 관계만 정의할 수 있도록 허용함.

첫 번째 정규 형태 (1NF) (계속):

1NF에 해당하지 않습니다. 왜냐하면 각 속성이 원자적이지 않기 때문입니다.

1NF에 도달하려면 DEPARTMENT 관계의 각 속성이 원자적이어야 합니다. 즉, 각 속성은 더 이상 분해되지 않아야 합니다. 여기서 Dnumber와 Dlocations가 하나의 속성으로 취급되지 않고 서로에게 종속되어 있다면 1NF에 해당하지 않습니다.

1NF에 도달하면 데이터 중복이 최소화되고 데이터 일관성이 유지됩니다. 그러나 1NF는 데이터의 논리적 구조를 표현하는 데만 중점을 두고 있으며 데이터 중복을 제거하는 데만 집중합니다. 이것은 데이터 업데이트 및 쿼리 작업에 대한 성능을 고려하지 않습니다.

따라서 1NF에 도달하면 데이터 중복 문제가 해결되지만, 일부 쿼리 작업은 더 복잡해질 수 있습니다. 예를 들어, Dnumber와 Dlocations가 분리되면 DEPARTMENT 관련 정보를 검색하거나 업데이트하는 데 더 많은 노력이 필요할 수 있습니다. 이러한 단점을 극복하기 위해 더 고급 정규화 단계가 필요할 수 있습니다.

First Normal Form (1NF) (계속):

1. 1NF를 위반하는 Dlocations 속성을 제거하고 별도의 관계에 배치합니다.
• 가장 좋은 방법으로 간주됩니다. 그 이유는 무엇일까요?

다중 값 속성은 별도의 튜플로 분해하여 각 값에 대한 별도의 레코드를 만들면 더 나은 데이터 구조와 일관성을 유지할 수 있습니다. 이렇게 하면 중복을 최소화하고 업데이트 이상을 방지하는 데 도움이 됩니다.

2. 키를 확장하여 DEPARTMENT 관계의 각 위치에 대해 원래 DEPARTMENT 관계에 별도의 튜플이 있도록 합니다. 이전 슬라이드에서 보여진 대로 {Dnumber, Dlocation}이 주 키로 작동합니다.
• 그러나 권장되지 않습니다. 그 이유는 무엇일까요?

중복 데이터가 증가하고 데이터의 무결성이 저하될 수 있습니다. 주 키를 확장하는 대신 다중 값 속성을 처리하는 방법이 더 효율적입니다.

3. 속성의 최대 개수, 예를 들어 ,을 알고 있다면 해당 속성을 개의 속성으로 대체합니다.
• 예: 최대 3개의 위치 -> Dloc1, Dloc2, Dloc3 속성
• 그러나 권장되지 않습니다. 그 이유는 무엇일까요?

속성의 최대 개수를 미리 알고 있다면 각 속성을 개별적인 속성으로 대체할 수 있지만, 이 방법은 권장되지 않습니다. 이렇게 하면 속성의 수가 고정되어 있어야 하며, 최대 개수를 초과하는 경우에 대비할 수 없습니다. 또한 이러한 속성을 처리하는 것은 복잡성을 높이며, 유연성을 제한할 수 있습니다. 따라서 다중 값 속성을 처리하기 위해 별도의 관계를 사용하는 것이 더 효율적입니다.

First Normal Form (1NF) (계속):

• EMP_PROJ의 정규화:
• EMP_PROJ1과 EMP_PROJ2로 분해하며 주 키를 전파합니다.

정의: (비)주요 속성

• 두 번째 정규 형식으로 이동하기 전에:
• 관계 스키마에 둘 이상의 (슈퍼)키가 있는 경우, 각각을 후보 키(candidate key)라고 합니다.
• 키(key): 와 같이 에서 최소한의 슈퍼키인 라고 할 수 있음.
• 주 키(primary key): 후보 키 중 하나가 임의로 지정됨.
• 보조 키(secondary keys): 다른 후보 키(예: SSN 대 Emp #No)들.
• 주요 속성(Prime attribute): 어떤 후보 키의 구성원이어야 함.

데이터베이스 설계에서 "어떤 후보키의 구성원이어야 한다"는 말은 주요 속성(Prime attribute)에 대한 정의를 나타냅니다. 후보 키(candidate key)는 관계 스키마에서 유일성을 보장하는 열(또는 열의 집합)을 나타냅니다. 주요 속성은 이러한 후보 키의 일부로서 그 구성원이어야 합니다.

다시 말해, 주요 속성은 최소한 하나의 후보 키를 구성하는 속성들 중 하나입니다. 주요 속성은 후보 키의 일부이므로 데이터베이스에서 레코드를 식별하거나 조회하는 데 필수적인 열입니다. 그리고 주요 속성은 후보 키의 일부로서 데이터의 무결성과 일관성을 유지하는 역할을 합니다.

비주요 속성은 후보 키의 구성원이 아니며, 주요 속성이 아닌 열입니다. 주요 속성과 달리 비주요 속성은 데이터 무결성을 유지하기 위한 필수적인 열이 아니며, 후보 키에 대한 유일성을 보장하는 데 직접적으로 기여하지 않습니다.

따라서 "어떤 후보키의 구성원이어야 한다"는 말은 주요 속성은 후보 키의 일부로 선택되어야 한다는 의미입니다.

• 비주요 속성(Nonprime attribute): 주요 속성이 아닌 속성. 어떤 후보 키의 부분집합이 아님.

Ssn (FK, PK): 외래 키(FK)이자 주 키(PK)입니다.
Pnumber (FK, PK): 외래 키(FK)이자 주 키(PK)입니다.

Second Normal Form (2NF):

• 전체 함수 종속성(full functional dependency) 개념을 기반으로 합니다.
• FD 가 모든 속성 에서 에서 속성 를 제거하면 더 이상 종속성이 유지되지 않는다면 는 전체 함수 종속성입니다.
• 전체 종속성: 에서 어떤 속성 를 제거해도 종속성이 유지되지 않음.
• 부분 종속성: 어떤 속성 를 제거해도 종속성이 계속 유지되는 경우.

• 정의: 2NF에 따르면 모든 비주요 속성 는 의 주 키에 대해 완전히 종속되어야 합니다.

• 2NF의 정규화: 2NF 관계로 분해됩니다.
• 2NF 관계에서 비주요 속성들은 해당 속성이 완전하게 종속되는 주 키와 관련되어 있습니다.

2NF의 정규화

2NF(Second Normal Form)는 정규화의 두 번째 단계로, 다음과 같은 조건을 만족해야 합니다:

1. 테이블이 1NF(First Normal Form)를 만족해야 합니다. 즉, 각 컬럼에는 원자값만 존재해야 하며, 각 로우와 컬럼의 교차점에는 유일한 값이 있어야 합니다.
2. 모든 비주요 속성(non-key attributes)이 주 키에 완전하게 함수적으로 종속되어야 합니다. 즉, 복합 키의 일부가 아니라 전체에 대한 종속성이어야 합니다.

FD2와 FD3가 2NF라고 표시된 것은, EMP_PROJ 테이블이 부분적 종속성을 제거하고 2NF를 충족한다는 것을 나타냅니다.

 - FD2: {Ssn} -> {Ename}: 이 종속성은 부분적 종속성이므로, 이것이 2NF를 충족한다는 것은 Ssn이 별도의 키로 작용하며, Ename이 Ssn에 완전하게 종속된다는 것을 의미합니다. 이는 Ssn이 각 Ename을 유일하게 식별하기 때문입니다.
 - FD3: {Pnumber} -> {Pname, Plocation}: 이 종속성도 마찬가지로, Pnumber가 별도의 키로 작용하여 Pname과 Plocation을 유일하게 식별합니다.

이러한 분석은 EMP_PROJ 테이블이 이미 2NF 상태라는 가정 하에 해당합니다. 그러나 실제로 FD2와 FD3가 2NF를 충족하는지 여부는, Ssn과 Pnumber가 복합 키의 일부인지, 아니면 독립적인 키로 작용하는지에 따라 달라질 수 있습니다. 단, 여기서 Ename과 Pname, Plocation이 복합 키에 종속되지 않고 독립적인 키에만 종속되므로, 이들은 2NF를 만족한다고 볼 수 있습니다.

• Full FD (Full Functional Dependency): 속성 그룹이 전체 키에 대해서만 종속적일 때 발생합니다. 다시 말해, 키의 일부분에 대해서는 종속적이지 않습니다.

• Partial FD (Partial Functional Dependency): 속성이 복합 키의 일부분에 대해서만 종속적일 때 발생합니다.

1. FD1: {Ssn, Pnumber} → {Hour}

이것은 full FD입니다. 왜냐하면 Hour는 복합 키인 {Ssn, Pnumber}에 전적으로 종속되며, 이 키의 어느 부분에도 부분적으로 종속되지 않기 때문입니다.

2. FD2: {Ssn} → {Ename}

이것은 partial FD입니다. Ename은 복합 키의 일부인 {Ssn}에 종속되고, Pnumber에는 종속되지 않기 때문입니다. 복합 키의 전체가 아닌 일부에 의해 결정되므로 부분적 종속성입니다.

3. FD3: {Pnumber} → {Pname, Plocation}

이것도 partial FD입니다. Pname과 Plocation은 복합 키의 일부인 {Pnumber}에 종속되며, Ssn에는 종속되지 않습니다. 복합 키의 한 부분에 의해서만 값이 결정되므로 부분적 종속성입니다.

Third Normal Form (3NF):

• 전이적 함수 종속성(transitive functional dependency) 개념을 기반으로 합니다.

• FD 가 에서 전이적으로 를 유도할 수 있다면 는 전이적 함수 종속성입니다.

• (속성 집합): R의 주 키 또는 후보 키의 부분 집합이 아니거나 후보 키가 아닙니다.

• 정의: 3NF에 따르면 이 2NF를 충족하고 R의 모든 비주요 속성이 R의 주 키에 대한 전이적 종속성이 없어야 합니다.

• EMP_DEPT 관계의 예시에 관해서는 슬라이드 31과 43에서 다룹니다.
• {Ssn} → {Dmgrssn}: 이것은 전이적인 함수 종속성(Transitive FD)입니다.
• 왜냐하면 {Ssn}이 {Dmgrssn}을 완전하게 결정하며, {Ssn} → {Dnumber}와 {Dnumber} → {Dmgrssn}도 성립하기 때문입니다.
• {Ssn} → {Ename}: 이것은 비전이적인 함수 종속성(Non-transitive FD)입니다.
• 왜냐하면 {Ssn}을 통해 {Ename}을 완전하게 결정하는 다른 속성 가 존재하지 않기 때문입니다.

• "3NF 정규화(Normalization of 3NF)": 이 관계를 3NF로 분해하라는 의미입니다.
• 가 주 키인 상태에서 및 의 경우에만 이를 문제로 간주합니다. 그렇지 않은 경우에는 문제가 없습니다.
• 예를 들어, EMPLOYEE(Ssn, Eno, Salary) 관계가 3NF인가요? 예 또는 아니오에 대한 답을 고려합니다.

3NF를 확인하기 위해 다음을 고려해야 합니다:

 - 비키 속성인 Salary가 Ssn이나 Eno에 직접 종속되어야 합니다. 이는 직관적으로 만족하는 것으로 보입니다. Salary는 Ssn이나 Eno에 의해 결정되며, 다른 비키 속성에 의해 결정되지 않습니다.
 - 이행적 종속성이 없어야 합니다. 즉, 어떤 비키 속성도 다른 비키 속성에 의해 결정되지 않아야 합니다.

주어진 정보에 기반하여 Salary가 Ssn이나 Eno에 의해 결정되고, 다른 비키 속성에 의해 이행적으로 결정되지 않는다면, EMPLOYEE(Ssn, Eno, Salary) 테이블은 3NF를 만족합니다.

따라서, 제공된 정보만으로 볼 때 EMPLOYEE(Ssn, Eno, Salary) 관계는 예, 3NF에 해당합니다.

2NF (Second Normal Form, 두 번째 정규형)

• EMP_DEPT 테이블은 2NF에 해당합니다. 이유는 다음과 같습니다:
• 테이블은 이미 1NF(첫 번째 정규형)에 해당합니다. 모든 속성에는 원자 값만 존재합니다.
• Ssn이 단일 기본 키이며, 복합 키의 일부분에 대한 부분 종속성이 없습니다. 비주요 속성(Ename, Bdate, Address, Dnumber)은 Ssn에 완전히 종속됩니다.

3NF (Third Normal Form, 세 번째 정규형)

• EMP_DEPT 테이블은 3NF에 해당하지 않습니다. 이유는 다음과 같습니다:
• 비주요 속성 중 일부(Dname, Dmgr_ssn)가 다른 비주요 속성(Dnumber)에 이행적으로 종속됩니다.
• {Dnumber} -> {Dname, Dmgr_ssn} 종속성은 {Ssn} (기본 키)를 거치지 않고 Dnumber (비주요 속성)에 직접 종속되어 있습니다.
• 3NF에서는 모든 비주요 속성이 기본 키에만 직접적으로 종속되어야 하며, 비주요 속성 간의 이행적 종속성이 없어야 합니다.

주 키와 관련된 정규화에 대한 요약

14. 4 두 번째 및 세 번째 정규 형태에 대한 일반적인 정의

• 현재까지, 관계 스키마는 주 키의 일부이거나 전부에 대한 부분적이거나 이행적인 속성을 제거하지 않도록 설계되었습니다. (그렇지 않으면 업데이트 이상이 발생합니다.)

• 이제 모든 후보 키에 관련된 주요 속성을 고려합니다. (주요 속성: 모든 다른 속성을 나타냄. 비주요: 모든 다른 속성 외의 모든 속성.)

• 관계 이 2NF에 속한다면 의 모든 비주요 속성 는 의 어떤 키에 대해서도 부분적으로 또는 완전하게 종속되지 않습니다.

2NF (Second Normal Form) 위반 여부

2NF를 위반하는지 평가하기 위해, 테이블이 1NF를 충족하며 비주요 속성들이 기본 키의 일부분에 부분적으로 종속되지 않는지 확인해야 합니다.

 - FD1과 FD2에서, Property_id# 및 County_name과 Lot# 조합이 각각 별개의 기본 키로 작용합니다. Property_id#는 모든 속성을 유일하게 결정하며, County_name과 Lot#도 마찬가지입니다.
 - FD3에서 County_name은 Tax_rate에 대한 종속성을 가지며, 이는 Property_id#와 관계없는 독립적인 종속성입니다.
 - FD4에서 Area는 Price를 결정하지만, 이것은 Property_id#와 관계없는 별도의 종속성입니다.

2NF를 위반하는 핵심적인 요소는 비주요 속성이 복합 키의 일부분에만 종속되는 경우입니다. 이 경우, FD3와 FD4는 Property_id# (기본 키)와 관련 없이 다른 속성에 종속되므로, LOTS 테이블은 2NF를 위반합니다. Tax_rate와 Price는 기본 키 Property_id#에 직접적으로 종속되지 않으며, 이는 2NF의 기준을 만족하지 않습니다.

• R의 모든 비주요 속성 는 의 어떤 키에 대해서도 부분적으로 (또는 완전하게) 종속되어 있지 않습니다.

• 관계 R이 3NF에 속한다면 R에서 비자명한 함수 종속성 가 존재할 때, 가 의 슈퍼키이거나 가 의 주요 속성인 경우, 즉 (a) 가 의 슈퍼키이거나 (b) 가 의 주요 속성인 경우입니다.

• 내에서 중요하지 않은 함수 종속성 FD 가 성립하면, 반드시 다음 중 하나가 충족되어야 합니다.
• (a) 는 의 수퍼키(superkey)입니다.
• (b) 는 의 주요 속성(prime attribute)입니다.

• 관계 이 3NF에 속하려면 R에서 FD 가 항상 다음과 같아야 합니다.
• (a) 가 의 수퍼키이거나 (b) 가 의 주요 속성이어야 합니다.

• (a)는 두 가지 유형의 위반 사항을 잡아냅니다:
1. 주요 속성이 비주요 속성을 기능적으로 결정하는 경우.
• 이로 인해 부분적인 기능적 종속성으로 인한 2NF 위반이 잡힙니다.

2NF에서는 비주요 속성이 주요 속성에만 종속되어야 하며, 다른 비주요 속성에 종속되어서는 안 됩니다.

2. 비주요 속성이 다른 비주요 속성을 기능적으로 결정하는 경우.
• 이로 인해 전이적 종속성으로 인한 3NF 위반이 잡힙니다.

3NF에서는 비주요 속성이 주요 속성에만 종속되어야 하며, 다른 비주요 속성에 종속되어서는 안 됩니다.

• 일반적인 3NF의 대안적인 정의
• 관계 이 3NF에 속하려면 의 모든 비주요 속성이 다음 조건을 모두 만족해야 합니다.
• (a) 의 모든 (기본) 키에 대해 완전한 기능 종속 관계이어야 하며 (b) 의 모든 (후보) 키에 대한 비전이적 종속 관계이어야 합니다.
• 관계가 3NF에 속하면 (a)에 의해 자동으로 2NF의 요구 사항도 충족되며,
• (b) 조건은 3NF에서 허용되지만 곧 다룰 Boyce-Codd 정규 형식 (BCNF)에서는 허용되지 않습니다.

보이스-코드 정규형 (BCNF)

• 3NF보다 엄격한 정규 형식입니다.

BCNF 정규화의 예시

• 수천 개의 많은 지역이 있음에도 불구하고 지역은 과 두 개의 군에만 속한다고 가정합니다.

• 의 지역 크기: 59m2, 72m2, 84m2 (17평, 21평, 25평)

• 의 지역 크기: 102m2, 136m2, 165m2 (31평, 41평, 50평)
• 여전히 3NF 상태, 3NF의 (b) 조건에 따라

• 그런 다음 추가적인 FD, 예를 들어 FD5를 찾습니다. 이것은 {Area} → {County_Name}입니다.
• County_Name은 주요 속성이 됩니다.

• BCNF 정규화를 통해 LOTS1A의 여러 튜플에서 동일한 정보를 반복하는 중복성을 줄일 수 있습니다.

BCNF (보이스-코드 정규형)

• 관계 은 BCNF에 속합니다. 만약 FD가 에서 성립한다면 는 의 슈퍼키여야 합니다.
• 이전 슬라이드에서 'Area'는 LOT1A에서 의 슈퍼키가 아니었습니다.

• 각 정규 형식은 이전 것보다 엄격합니다:
• 모든 2NF 관계는 1NF에 속합니다.
• 모든 3NF 관계는 2NF에 속합니다.
• 모든 BCNF 관계는 3NF에 속합니다.

• BCNF 관계 중에서도 3NF에 속하지 않는 관계가 있습니다.
• 따라서 BCNF는 3NF의 더 강력한 형태로 간주됩니다.

BCNF에 속하지 않는 관계의 또 다른 예

• TEACH에는 2개의 FD가 있습니다.
• FD1: {Student, Course} → {Instructor}
• FD2*: {Instructor} → {Course}.

• {Student, Course}은 TEACH의 후보 키 (슈퍼키)입니다. 왜냐하면?

이 문제는 TEACH 관계와 그 안의 함수적 종속성(FD)을 바탕으로 후보 키(Candidate Key)를 파악하는 것입니다. 후보 키는 관계에서 모든 튜플을 유일하게 식별할 수 있는 최소 속성 집합입니다.

### 주어진 정보
- TEACH 관계에는 두 개의 함수적 종속성이 있습니다:
  - FD1: `{Student, Course} → {Instructor}`
  - FD2*: `{Instructor} → {Course}`

- `{Student, Course}`는 TEACH의 후보 키입니다.

### 후보 키 (슈퍼키)로서의 `{Student, Course}`
- `{Student, Course}`가 후보 키(슈퍼키)인 이유는, 이 조합이 TEACH 관계에서 각 튜플을 유일하게 식별하기 때문입니다.
- FD1에 따르면, `Student`와 `Course`의 조합은 `Instructor`를 유일하게 결정합니다. 즉, 같은 `Student`와 `Course` 조합이 다른 `Instructor`를 가지는 경우는 없다는 것을 의미합니다. 이는 `{Student, Course}` 조합이 모든 튜플을 유일하게 식별한다는 것을 나타냅니다.
- `Instructor`는 비주요 속성(non-prime attribute)입니다. 후보 키는 주요 속성(prime attribute)으로만 구성되어야 합니다. 여기서 주요 속성은 키의 일부가 되는 속성을 말합니다. `Instructor`가 비주요 속성이라는 것은, 그 자체로는 튜플을 유일하게 식별할 수 없다는 것을 의미합니다.
- FD2*에 따르면, `Instructor`는 `Course`를 결정하지만, 이것만으로는 `Student`에 대한 정보는 결정할 수 없습니다. 즉, `Instructor`가 키의 일부가 될 수 없다는 것을 나타냅니다.

결론적으로, `{Student, Course}`는 TEACH 관계에서 모든 튜플을 유일하게 식별할 수 있는 최소 속성 집합이므로, 이는 TEACH의 후보 키가 됩니다.

• TEACH: BCNF에 속하지 않습니다. 왜냐하면?

### BCNF 정의:
- BCNF는 데이터베이스 정규화의 한 형태로, 모든 함수적 종속성에서 결정자가 후보 키(superkey)인 경우에 해당합니다.
- 즉, 관계 내의 모든 함수적 종속성에 있어서, 왼쪽에 있는 속성 집합이 해당 관계의 후보 키여야 합니다.

### 주어진 정보:
- TEACH 관계에는 두 개의 함수적 종속성이 있습니다:
  - FD1: `{Student, Course} → {Instructor}`
  - FD2: `{Instructor} → {Course}`
- `{Student, Course}`는 TEACH의 후보 키입니다.

### 분석:
- **FD1 `{Student, Course} → {Instructor}`**:
  - 여기서 `{Student, Course}`는 후보 키이므로, 이 종속성은 BCNF를 만족합니다.

- **FD2 `{Instructor} → {Course}`**:
  - 이 경우, `Instructor`는 후보 키가 아닙니다. 그러나 `Instructor`는 `Course`를 결정합니다.
  - 이 함수적 종속성에서 왼쪽에 있는 `Instructor`가 후보 키가 아니므로, 이 관계는 BCNF를 위반합니다.

### 결론:
- TEACH는 BCNF에 속하지 않습니다. 이유는 FD2 `{Instructor} → {Course}`에서 `Instructor`가 후보 키가 아닌데도 불구하고 `Course`를 결정하기 때문입니다. BCNF에서는 모든 함수적 종속성의 결정자가 후보 키여야 하는데, 이 경우에 해당하지 않습니다.

• BCNF에 속하지 않는 관계는 BCNF의 속성을 충족하기 위해 분해되어야 합니다.

• 분해된 관계에서 모든 기능 종속성을 보존하려고 노력합니다.
• 여러 FD가 관계에 존재하는 경우, BCNF로 만들려면 FD 보존을 희생해야 합니다.

BCNF 달성하는 방법? 분해!

• D1) R1(Student, Instructor) 및 R2(Student, Course)

• D2) R1(Course, Instructor) 및 R2(Course, Student)

• D3) R1(Instructor, Course) 및 R2(Instructor, Student)
=> 그러나 모든 세 분해는 FD1을 잃게 됩니다. 왜 그럴까요?
• BCNF 상태로 만들기 위해, 특히 관계에 여러 FD가 존재하는 경우, FD 보존을 희생해야 할 수도 있습니다.

• 그렇다면 어떤 분해를 선택해야 할까요?
• 정규화 과정에서 두 가지 속성을 보존하는 분해를 선택해야 합니다: 비가산적(손실 없는) 조인 속성(희생할 수 없는 속성) 및 함수적 종속성 보존 속성

• D3)는 NJB(비가산적 조인 테스트를 위한 이진 분해)를 통과하므로 원하는 분해가 될 것입니다.

이진 분해에 대한 비가산 결합 검사 (NJB)

• 관계 의 분해 는 에 대한 일련의 FD()에 대해 비가산(손실 없는) 결합 속성을 가진다고 말할 수 있으려면 (필요충분조건) 다음 중 하나여야 합니다:
• FD((R1∩R2)→(R1–R2))가 F+에 속하는 경우
• 또는 FD((R1∩R2)→(R2–R1))가 F+에 속하는 경우, 여기서 F+는 F에서 유도된 모든 FD를 포함합니다.

• 이제 이 테스트를 세 가지 분해 옵션에 적용해 보겠습니다.
• D1) R1(Student, Instructor) 및 R2(Student, Course) => Student → Instructor 및 Student → Course 모두 거짓입니다.
• D2) R1(Course, Instructor) 및 R2(Course, Student) => Course → Instructor 및 Course → Student 모두 거짓입니다.
• D3) R1(Instructor, Course) 및 R2(Instructor, Student) => Instructor → Course (= FD2)는 F+에 속합니다.
• 따라서 NJB 속성이 충족됩니다. 따라서 D3가 비가산 분해로 선택됩니다.

BCNF 분해 알고리즘

1. BCNF에 속하지 않는 관계 을 선택합니다.

2. 내에서 FD(Functional Dependency) 를 선택하고, 이 FD가 BCNF 위배의 원인이 되었음을 확인합니다.

3. 그런 다음, 을 두 관계로 분해할 수 있습니다:
• (i) 에서 를 제외한 관계인 와
• (ii) 와 같은 관계로 분해합니다.

4. (i) 또는 (ii) 중 하나라도 BCNF를 충족하지 못하면, 분해 과정을 반복합니다. 그렇지 않으면 알고리즘을 종료합니다.

• 예를 들어, TEACH(=R) 관계에서 Instructor(=X) → Course(=A) FD가 BCNF 위배를 일으켰다고 가정해 봅시다. 그런 경우 BCNF 분해는 다음과 같을 수 있습니다:
• (TEACH - Course) 및 (Instructor, Course) 관계
• 이러한 분해는 BCNF 관계를 생성합니다:
• (Instructor, Student) 및 (Instructor, Course)

• 따라서 이 알고리즘은 주어진 관계를 BCNF로 분해하기 위한 단계입니다. Slide 54에서 LOTS1A 관계에 대한 이 알고리즘을 확인할 수 있습니다.

결론

• 관계가 좋은지 나쁜지에 대한 비형식적인 측정 방법.

• 업데이트 이상
• 삽입, 삭제 및 업데이트 이상 등...

• 기능 종속성

• 분해: 손실 없는 결합 속성 및 기능 종속성 속성 충족 (가능한 경우)