데이터베이스 (Databases) 관계 데이터베이스의 함수적 종속성과 정규화 문양세 강원대학교 IT대학 컴퓨터과학전공

강의 내용 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 기본 키를 기반으로 한 정규형 BCNF (Boyce-Codd Normal Form) 더 많은 종속성과 정규형

릴레이션 스키마 설계를 위한 개략적 지침 (1/2) 관계 DB의 함수적 종속성과 정규화 관계형 데이터베이스 설계란? “좋은” 릴레이션 스키마를 생성하기 위하여 애트리뷰트들을 묶는(그룹핑하는) 과정 “좋은” 릴레이션에 대한 기준은? 릴레이션 스키마의 두 가지 수준 논리적인 “사용자 뷰(user view)” 수준 저장이 되는 “기본 릴레이션(base relation)” 수준 데이터베이스 설계는 주로 기본 릴레이션을 대상으로 함

릴레이션 스키마 설계를 위한 개략적 지침 (2/2) 관계 DB의 함수적 종속성과 정규화 먼저 좋은 릴레이션 설계에 관한 개괄적인 지침을 논의한 후, 함수적 종속성과 정규형 개념에 관해 논의함 정규형의 종류 1NF (제1정규형) 2NF (제2정규형) 3NF (제3정규형) BCNF (Boyce-Codd 정규형) 4NF (제4정규형) 5NF (제5정규형)

릴레이션 애트리뷰트들의 의미 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 형성하기 위해 애트리뷰트들을 집단화 하는 경우, 한 릴레이션에 속하는 애트리뷰트는 실세계에서 어떤 의미를 가져야 한다. 여러 엔티티(EMPLOYEE, DEPARTMENT, PROJECT)의 애트리뷰트들이 하나의 릴레이션에 혼합되면 의미가 불명확해지므로 좋지 않음.  하나의 릴레이션은 하나의 엔티티나 관계를 나타내는 것이 바람직함 다른 엔티티를 참조하기 위해서는 외래키 만을 사용해야 한다. 릴레이션 설계의 예: 그림 13.1 – 잘 설계된 경우 그림 13.2 – 그림 13.1의 데이터베이스 인스턴스 그림 13.3 –잘 설계되지 않은 예

[그림 13.1] 단순화된 COMPANY 관계 DB 스키마 외래키 EMPLOYEE ENAME SSN BDATE ADDRESS DNUMBER 기본키 DEPARTMENT 외래키 DNAME DNUMBER DMGRSSN DLOCATIONS 기본키 DEPT_LOCATIONS 외래키 PROJECT 외래키 DNUMBER DLOCATIONS PNAME PNUMBER PLOCATIONS DNUM 기본키 기본키 WORKS_ON 외래키 외래키 SSN PNUMBER HOURS 기본키

[그림 13.2] 그림 13.1 스키마를 위한 DB 상태 (1/2) EMPLOYEE ENAME SSN BDATE ADDRESS DNUMBER Smith, John B. Wong, Franklin T. Zelaya, Alicia J. Wallace, Jennifer S. Narayan, Ramesh K. English, Joyce A. Jabbar, Ahmad V. Bong, James E. 123456789 333445555 999887777 987654321 666884444 453453453 987987987 888665555 09-JAN-55 08-DEC-45 19-JUL-58 20-JUN-31 15-SEP-52 31-JUL-62 29-MAR-59 10-NOV-27 731 Fondren, Houston, TX 638 Voss, Houston, TX 3321 Castle, Spring, TX 291 Berry. Bellaire, TX 975 Fire Oak, Humble, TX 5631 Rice, Houston, TX 980 Dallas, Houston, TX 731 Stone, Houston, TX 5 4 1 DEPARTMENT DEPT_LOCATIONS DNAME DNUMBER DMGRSSN DNUMBER DLOCATIONS Research Administration Headquarters 5 4 1 333445555 987654321 888665555 1 4 5 Houston Stafford Bellaire Sugarland

[그림 13.2] 그림 13.1 스키마를 위한 DB 상태 (2/2) WORKS_ON PROJECT SSN PNUMBER HOURS PNAME PNUMBER PLOCATIONS DNUM 123456789 666884444 453453453 333445555 999887777 987987987 987654321 888665555 1 2 3 10 20 30 32.5 7.5 40.0 20.0 10.0 30.0 35.0 5.0 15.0 null ProductX ProductY ProductZ Computerization Reorganization Newbenefits 1 2 3 10 20 30 Bellaire Sugarland Houston Stafford 5 4 1

[그림 13.3] 좋지 않은 설계 예 – 갱신 이상 발생 (그림의 선들은 FD 설명 시 사용할 것이므로, 현재는 무시해도 됨) 관계 DB의 함수적 종속성과 정규화 (그림의 선들은 FD 설명 시 사용할 것이므로, 현재는 무시해도 됨) 여러 엔티티의 속성들이 하나의 릴레이션에 혼합되어 문제 (a) EMP_DEPT 릴레이션 스키마 (EMPLOYEE + DEPARTMENT) 사원 엔티티 + 부서 엔티티 EMP_DEPT ENAME SSN BDATE ADDRESS DNUMBER DNAME DMGRSSN (b) EMP_PROJ 릴레이션 스키마 (EMPLOYEE + PROJECT) 사원 엔티티 + 프로젝트 엔티티 EMP_PROJ SSN PNUMBER HOURS ENAME PNAME PLOCATIONS fd1 fd2 fd3

투플에서 중복된 정보와 갱신 이상 (1/3) 관계 DB의 함수적 종속성과 정규화 하나의 릴레이션에 하나 이상 엔티티의 애트리뷰트들을 혼합하는 것은 여러 가지 문제를 일으킨다. (그림 13.4) 정보가 중복 저장되며, 저장 공간을 낭비하게 된다. (그림 13.2의 EMPLOYEE와 DEPARTMENT  13.3 및 13.4의 EMP_DEPT 비교) 갱신 이상이 발생하게 된다: 동일한 정보를 한 릴레이션에는 변경하고, 나머지 릴레이션에서는 변경하지 않은 경우 어느 것이 정확한지 알 수 없게 된다.

투플에서 중복된 정보와 갱신 이상 (2/3) 갱신 이상의 종류 관계 DB의 함수적 종속성과 정규화 갱신 이상의 종류 삽입 이상 (insertion anomalies): EMP_DEPT에 객체를 삽입할 때 부서가 정해지지 않은 직원이나 직원이 없는 부서를 insert 하는데 문제가 발생함 삭제 이상 (deletion anomalies): 부서의 마지막 직원을 삭제하면 부서 정보도 없어짐 수정 이상 (modification anomalies): 부서 정보를 변경하면 부서의 모든 직원 투플에서 동일하게 변경해야 함

투플에서 중복된 정보와 갱신 이상 (3/3) 데이터 중복 발생 관계 DB의 함수적 종속성과 정규화 [그림 13.4] 그림 13.3의 스키마에 대한 릴레이션 예 (그림 13.2의 릴레이션들을 자연조인하여 얻은 결과임) ENAME SSN BDATE ADDRESS DNUMBER EMP_DEPT Smith, John B. Wong, Franklin T. Zelaya, Alicia J. Wallace, Jennifer S. Narayan, Ramesh K. English, Joyce A. Jabbar, Ahmad V. Bong, James E. 123456789 333445555 999887777 987654321 666884444 453453453 987987987 888665555 09-JAN-55 08-DEC-45 19-JUL-58 20-JUN-31 15-SEP-52 31-JUL-62 29-MAR-59 10-NOV-27 731 Fondren, Houston, TX 638 Voss, Houston, TX 3321 Castle, Spring, TX 291 Berry. Bellaire, TX 975 Fire Oak, Humble, TX 5631 Rice, Houston, TX 980 Dallas, Houston, TX 731 Stone, Houston, TX 5 4 1 DNAME DMGRSSN Research Administration Headquarters PNUMBER HOURS PNAME PLOCATIONS EMP_PROJ 2 3 10 20 30 32.5 7.5 40.0 20.0 10.0 30.0 35.0 5.0 15.0 null ProductX ProductY ProductZ Computerization Reorganization Newbenefits Bellaire Sugarland Houston Stafford 데이터 중복 발생

투플의 널값 (1/2) 릴레이션의 투플들이 (가급적) 널 값을 가지지 않도록 설계해야 함 관계 DB의 함수적 종속성과 정규화 릴레이션의 투플들이 (가급적) 널 값을 가지지 않도록 설계해야 함 널 값은 저장 단계에서 공간을 낭비하게 되고 논리적 차원에서는 조인 연산들을 지정하기 힘들고 애트리뷰트들의 의미를 이해하기 어려움 COUNT나 AVG와 같은 집단 함수들이 적용되었을 때 널 값의 해석이 모호함 널 값은 다음과 같이 여러 가지로 해석이 가능함 그 애트리뷰트가 이 투플에는 적용되지 않는다. (존재 여부를 모른다) 이 투플에서 애트리뷰트의 값이 아직 알려져 있지 않다 (존재하지만 모른다). 애트리뷰트 값이 알려져 있지만 DB에 기록되지는 않았다. 모든 널 값을 동일하게 표현하면 널 값이 갖는 여러 의미를 훼손하게 된다.

투플의 널값 (2/2) 널 값의 방지 기법 – 릴레이션의 분리 Employee Employee Emp_Office 관계 DB의 함수적 종속성과 정규화 널 값의 방지 기법 – 릴레이션의 분리 널 값이 많이 나타나는 애트리뷰트들은 별도 릴레이션으로 분리함 예: 사원들 중 10%만이 자기의 사무실을 가지고 있는 경우, 사원 레코드의 90%는 널 값으로 채워짐 Employee ssn ename age office_no Employee ssn ename age Emp_Office ssn office_no 분리 사무실을 가지고 있는 사원만 기록 널값이 존재 X 90%가 널 값으로 채워짐

가짜 투플 (Spurious Tuple) 관계 데이터베이스 설계를 잘못하게 되면, 조인 연산들이 틀린 결과를 생성할 수 있다. 관계 DB의 함수적 종속성과 정규화 관계 데이터베이스 설계를 잘못하게 되면, 조인 연산들이 틀린 결과를 생성할 수 있다. 조인 연산의 결과가 올바르기 위해서는, 릴레이션들이 “무손실 조인(lossless join)” 조건을 만족하도록 설계되어야 한다. 무손실 조인 특성: 원래의 릴레이션을 분해하여 두 릴레이션을 생성하는 경우, 분해된 두 릴레이션을 조인하면 원래의 릴레이션이 복원되어야 한다. 무손실 조인 특성이 만족되지 않으면 조인 시 원래의 릴레이션에 없던 가짜 투플이 발생함. 분해 시 (기본키, 외래키) 조합을 이용하는 것이 바람직함  키가 아닌 애트리뷰트를 매개로 분해하면 조인 시 가짜 투플이 발생할 수 있음

가짜 투플이 나타나는 예 (1/2) 관계 DB의 함수적 종속성과 정규화 [그림 13.5] EMP_PROJ를 다르게 표현 (a) 그림 13.3(b)의 EMP_PROJ를 두 개 릴레이션 스키마 (EMP_LOCS와 EMP_PROJ1)로 표현 (b) 그림 13.4의 EMP_PROJ 릴레이션을 EMP_LOCS 와 EMP_PROJ1 릴레이션의 애트리뷰트 들 상에 프로젝트 한 결과 ENAME PLOCATIONS EMP_LOCS 기본키 SSN PNUMBER EMP_PROJ1 HOURS PNAME Smith, John B. Narayan, Ramesh K. English, Joyce A. Wong, Franklin T. Zelay, Alicia J. Jabbar, Ahmad V. Wallace, Jennifer S. Borg, James E. Bellaire Sugarland Houston Stafford 123456789 666884444 453453453 333445555 999887777 987987987 987654321 888665555 1 2 3 10 20 30 32.5 7.5 40.0 20.0 10.0 30.0 35.0 5.0 15.0 null ProductX ProductY ProductZ Computerization Reorganization Newbenefits (a) (b)

가짜 투플이 나타나는 예 (2/2) 관계 DB의 함수적 종속성과 정규화 [그림 13.6] EMP_PROJ1과 EMP_LOCS을 자연조인한 결과 (는 가짜 투플을 나타냄) SSN PNUMBER HOURS PNAME PLOCATIONS ENAME 123456789 *123456789 666884444 *666884444 *453453453 453453453 *333445555 333445555 1 2 3 10 20 32.5 7.5 40.0 20.0 10.0 ProductX ProductY ProductZ Computerization Reorganization Bellaire Sugarland Houston Stafford Smith, John B. English, Joyce A. Wong, Franklin T. Narayan, Ramesh K.

강의 내용 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 기본 키를 기반으로 한 정규형 BCNF (Boyce-Codd Normal Form) 더 많은 종속성과 정규형

함수적 종속성 함수적 종속성(FD: functional dependency)은 좋은 릴레이션 설계의 정형적 기준으로 사용된다. 관계 DB의 함수적 종속성과 정규화 함수적 종속성(FD: functional dependency)은 좋은 릴레이션 설계의 정형적 기준으로 사용된다. FD와 키는 릴레이션의 정규형을 정의하기 위해 사용된다. FD는 데이터 애트리뷰트들의 의미와 애트리뷰트들 간의 상호 관계로부터 유도되는 제약조건(constraints)의 일종이다.

함수적 종속성의 정의 (1/2) 함수적 종속성 함수적 종속성의 검사 방법 관계 DB의 함수적 종속성과 정규화 함수적 종속성 X와 Y를 임의의 애트리뷰트 집합이라고 할 때, X의 값이 Y의 값을 유일하게(unique) 결정한다면 “X는 Y를 함수적으로 결정한다(functionally determines)”라고 함 X → Y로 표기하고, “Y는 X에 함수적으로 종속된다” 라고 함 함수적 종속성은 모든 릴레이션 인스턴스 r(R)에 대하여 성립해야 함 함수적 종속성의 검사 방법 릴레이션 인스턴스 r(R)에 속하는 어떠한 임의의 두 투플에 대해서도 속성들의 집합 X에 대해 동일한 값을 가질 때마다 Y에 대해서도 동일한 값을 가진다면 X → Y라는 함수적 종속성이 성립한다. 즉, r(R)에서의 임의의 두 투플 t1과 t2에 대해 t1[X] = t2[X]이면, t1[Y] = t2[Y]이다.

함수적 종속성의 정의 (2/2) FD 제약조건의 예제 관계 DB의 함수적 종속성과 정규화 FD 제약조건의 예제 주민등록번호는 사원의 이름을 결정한다. SSN → ENAME 프로젝트 번호는 프로젝트 이름과 위치를 결정한다. PNUMBER → {PNAME, PLOCATION} 사원의 주민등록번호와 프로젝트 번호는 그 사원이 일주일 동안 그 프로젝트을 위해서 일하는 시간을 결정한다. {SSN, PNUMBER} → HOURS FD는 스키마 R에 있는 애트리뷰트들의 특성이며, 모든 릴레이션 인스턴스 r(R)에서 성립해야 하는 성질이다. K가 R의 키이면 K는 R의 모든 애트리뷰트들을 함수적으로 결정한다. (t1[K] = t2[K]인 서로 다른 두 투플이 존재하지 않기 때문에).

강의 내용 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 기본 키를 기반으로 한 정규형 BCNF (Boyce-Codd Normal Form) 더 많은 종속성과 정규형

정규화 소개 정규화(normalization) 정규형(normal form) 제1정규형, 제2정규형, 제3정규형, BCNF 관계 DB의 함수적 종속성과 정규화 정규화(normalization) 불만족스러운 “나쁜” 릴레이션의 애트리뷰트들을 나누어서 더 작은 “좋은” 릴레이션으로 분해하는 과정 정규형(normal form) 특정 조건을 만족하는 릴레이션 스키마의 형태 제1정규형, 제2정규형, 제3정규형, BCNF 릴레이션 스키마의 FD와 키에 기반하여 정의됨 일반적으로 업계에서는 제 3 정규형 또는 BCNF형까지 고려 주요 애트리뷰트: 키(기본키, 후보기 모두 포함)에 속하는 애트리뷰트 비주요 애트리뷰트: 주요 애트리뷰트가 아닌 애트리뷰트

제1정규형 (1NF) 제1정규형 제1정규형은 릴레이션 내의 릴레이션 또는 투플의 애트리뷰트 값들로서의 릴레이션을 허용하지 않음 관계 DB의 함수적 종속성과 정규화 제1정규형 애트리뷰트의 도메인이 오직 원자 값만을 포함하고, 투플의 모든 애트리뷰트가 도메인에 속하는 하나의 값을 가져야 함 복합 애트리뷰트(composite attribute), 다치 애트리뷰트(multivalue attribute), 그리고 중첩 릴레이션(nested relation) 등 비원자적(non-atomic) 애트리뷰트들을 허용하지 않은 릴레이션의 형태 제1정규형은 릴레이션 내의 릴레이션 또는 투플의 애트리뷰트 값들로서의 릴레이션을 허용하지 않음

[그림 13.9] 다치 애트리뷰트를 1NF로 정규화 (a) (b) (c) 관계 DB의 함수적 종속성과 정규화 (a) 제1정규형이 아닌 릴레이션 스키마 (부서는 여러 위치가 있을 수 있다.) (b) 릴레이션 인스턴스의 예 (다치 애트리뷰트를 갖기 때문에 1NF가 아니다.) (c) 중복이 포함된 제1정규형 릴레이션 DEPARTMENT (a) DNAME DNUMBER DMGRSSN DLOCATIONS DEPARTMENT (b) DNAME DNUMBER DMGRSSN DLOCATIONS Research Administration Headquarters 4 5 1 333445555 987654321 888665555 {Bellaire, Sugarland, Houston} {Stafford} {Houston} DEPARTMENT (c) DNAME DNUMBER DMGRSSN DLOCATIONS Research Administration Headquarters 4 5 1 333445555 987654321 888665555 Bellaire Sugarland Houston Stafford

[그림 13.10] 중첩된 릴레이션을 1NF로 정규화 (a) (b) (c) 관계 DB의 함수적 종속성과 정규화 (a) 중첩 릴레이션 PROJS를 포함하는 릴레이션 EMP_PROJ의 스키마 (b) 각 투플 안에 중첩 릴레이션을 포함하고 있는 릴레이션 EMP_PROJ의 외연의 예 (c) 기본 키를 복사함으로써 EMP_PROJ를 제1정규형 릴레이션들로 분해 (a) (b) EMP_PROJ EMP_PROJ SSN ENAME PROJS SSN ENAME PROJS PNUMBERS HOURS PNUMBERS HOURS 123456789 666884444 453453453 333445555 999887777 987987987 987654321 888665555 Smith, John B. Narayan, Joyce K. English, Joyce A. Wong, Franklin T. Zelaya, Alicia J. Jabbar, Ahmad V. Wallace, Jennifer S. Bong, James E. 1 2 3 10 20 30 32.5 7.5 40.0 20.0 10.0 30.0 35.0 5.0 15.0 null (c) EMP_PROJ1 SSN ENAME EMP_PROJ2 SSN PNUMBER HOURS

제2정규형 (2NF) 제2정규형은 기본키와 완전 함수적 종속성의 개념에 기반을 둔다. 관계 DB의 함수적 종속성과 정규화 제2정규형은 기본키와 완전 함수적 종속성의 개념에 기반을 둔다. 완전 함수적 종속성(full functional dependency): FD Y→Z에서 Y의 어떤 애트리뷰트라도 제거하면 더 이상 함수적 종속성이 성립하지 않는 경우 예제: {SSN, PNUMBER} → HOURS는 SSN → HOURS와 PNUMBER → HOURS가 성립하지 않기 때문에 완전 함수적 종속성이다. {SSN, PNUMBER} → ENAME은 SSN → ENAME이 성립하기 때문에 완전 함수적 종속성이 아니다 (이는 부분 함수 종속성(partial function dependency)이라고 부름). 제 2 정규형의 정의: 릴레이션 스키마 R의 모든 비주요 애트리뷰트들이 기본키에 대해서 완전 함수적 종속이면, R은 제2정규형(2NF)에 속한다.

[그림 13.11(a)] EMP_PROJ를 2NF으로 정규화 관계 DB의 함수적 종속성과 정규화 기본키 EMP_PROJ SSN PNUMBER HOURS ENAME PNAME PLOCATIONS 완전 함수적 종속성 fd1 부분 함수적 종속성 fd2 부분 함수적 종속성 fd3 2NF 정규화 EP1 EP2 EP3 SSN PNUMBER HOURS SSN ENAME PNUMBER PNAME PLOCATIONS fd1 fd2 fd3 완전 함수적 종속성 완전 함수적 종속성 완전 함수적 종속성

제3정규형 (3NF) 제3정규형은 이행 함수적 종속성의 개념에 기반을 둔다. 관계 DB의 함수적 종속성과 정규화 제3정규형은 이행 함수적 종속성의 개념에 기반을 둔다. 이행 함수적 종속성(transitive functional dependency): 두 FD Y → X와 X → Z에 의해서 추론될 수 있는 FD Y → Z 예제 SSN → DMGRSSN은 SSN → DNUMBER과 DNUMBER → DMGRSSN이 성립하기 때문에 이행적 함수적 종속성이다. SSN → ENAME는 SSN → X이고 X → ENAME인 애트리뷰트 집합 X가 존재하지 않기 때문에 이행적 종속성이 아니다. 제3정규형의 정의: 릴레이션 스키마 R이 제2정규형을 갖고 R의 어떤 비주요 애트리뷰트도 기본키에 대해서 이행적으로 종속되지 않으면 R은 제3정규형을 갖는다고 한다.

[그림 13.11(b)] EMP_DEPT를 3NF으로 정규화 관계 DB의 함수적 종속성과 정규화 EMP_DEPT ENAME SSN BDATE ADDRESS DNUMBER DNAME DMGRSSN 이행 함수적 종속성 3NF 정규화 ED1 ED2 ENAME SSN BDATE ADDRESS DNUMBER DNUMBER DNAME DMGRSSN

COMPANY 데이터베이스 SQL Part1

강의 내용 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 기본 키를 기반으로 한 정규형 BCNF (Boyce-Codd Normal Form) 더 많은 종속성과 정규형

BCNF (Boyce-Codd Normal Form) 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마 R에서 성립하는 임의의 FD X → A에서 X가 R의 슈퍼키이면 R은 Boyce-Codd 정규형(BCNF)을 갖는다고 한다. 각 정규형은 그의 선행 정규형보다 더 엄격한 조건을 갖는다. 즉, 모든 제2정규형 릴레이션은 제1정규형을 갖는다. 모든 제3정규형 릴레이션은 제2정규형을 갖는다. 모든 BCNF 릴레이션은 제3정규형을 갖는다. 제3정규형에는 속하나 BCNF에는 속하지 않는 릴레이션이 존재한다. 관계 데이터베이스 설계의 목표는 각 릴레이션이 BCNF(또는 3NF)를 갖게 하는 것이다.

BCNF으로 정규화 – 생략 BCNF로 정규화하는 과정에서 종속성 fd2가 없어지는 경우 (정보의 손실이 발생하는 경우임) 관계 DB의 함수적 종속성과 정규화 BCNF로 정규화하는 과정에서 종속성 fd2가 없어지는 경우 (정보의 손실이 발생하는 경우임) 후보키(슈퍼키) LOTS1A 제 3 정규형 PROPERTY_ID# COUNTY_NAME LOT# AREA fd1 fd2 이행 함수적 종속성 fd5 이행 종속성의 대상이 슈퍼키이므로 제 3 정규형을 만족함 (그러나, 이 조건은 BCNF에서는 빠져야 함) BCNF 정규화 LOTS1AX LOTS1AY BCNF PROPERTY_ID# AREA LOT# AREA COUNTY_NAME

강의 내용 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 기본 키를 기반으로 한 정규형 BCNF (Boyce-Codd Normal Form) 더 많은 종속성과 정규형

관계 DB 스키마 설계 알고리즘 좋은 데이터베이스 스키마 설계를 위해서는 정규형만으로는 불충분함 예제: 두 개 애트리뷰트를 갖는 릴레이션은 BCNF이다. 그러면, 모든 릴레이션을 두 개 애트리뷰트로 설계하면 좋은 설계인가? 좋은 데이터베이스 설계를 보장하기 위해서는 다음의 추가적인 조건들이 필요함 종속성 보존 특성 (dependency preservation property) 무손실 조인 특성 (lossless join property)

다치 종속성과 제4정규형(4NF) 관계 DB의 함수적 종속성과 정규화 함수적 종속성은 하나의 공통된 형태의 제약조건을 명기하기 위해서 사용되며, 함수적 종속성 만에 의해서 명기될 수 없는 다른 형태의 제약조건들이 존재한다. 추가적인 종속성에는 다치 종속성(multi-valued dependency)이 있으며, 이에 기반한 정규형이 제4정규형(4NF)이다. 제4정규형의 특성 3NF와 BCNF는 다치 종속성을 다루지 않는다. 비단순 다치 종속성을 가지는 릴레이션 스키마는 좋은 디자인이 아닐 수 있다. 제 4 정규형은 위와 같은 문제를 다루며, BCNF 정규형이 된다. (제 4 정규형에 속하는 모든 릴레이션은 BCNF 정규형에 속한다)

조인 종속성과 제5정규형(5NF) 관계 DB의 함수적 종속성과 정규화 또 다른 추가적 종속성으로 조인 종속성(Join Dependency)이 있으며, 이에 기반한 정규형이 제5정규형이다. 제5정규형(5NF) 함수적 종속성, 다치 종속성, 조인 종속성을 모두 고려하는 정규형으로, 프로젝트-조인 정규형(Project-Join NF: PJNF)이라고도 한다. 조인 종속성을 발견하는 것은 매우 어려운 일로, 실제로 제5정규형은 거의 쓰이지 않는다.

요약 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 함수적 종속성 (functional dependencies, FDs) 관계 DB의 함수적 종속성과 정규화 릴레이션 스키마를 설계하는 몇 가지 개략적인 지침 갱신이상, 널값 발생, 가짜투플 함수적 종속성 (functional dependencies, FDs) 정규형 기본 키를 기반으로 한 정규형 제 2 정규형과 제 3 정규형의 일반적인 정의 BCNF (Boyce-Codd Normal Form) 추가 제약조건과 제4 및 제5 정규형