Normal Forms - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

2026-01-15T12:51:03Z

봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

← 이전 판		2026년 1월 15일 (목) 12:51 판
102번째 줄:		102번째 줄:

	==각주==		==각주==
	[[분류:데이터베이스 ~~시스템~~]]		[[분류:데이터베이스]]

Pinkgo: /* First Normal Form */

2025-05-19T16:30:19Z

First Normal Form

← 이전 판		2025년 5월 19일 (월) 16:30 판
97번째 줄:		97번째 줄:

	==First Normal Form==		==First Normal Form==
			1NF(First Normal Form)은 도메인의 원자성(atomicity)와 큰 관련이 있다. 도메인이 원자적(atomic)하다는 것은 해당 도메인의 값들이 더 이상 나눌 수 없는 불가분의 단위라는 것을 의미한다. 즉, 하나의 속성 값은 하나의 값만을 가져야 한다는 것이다. 예를 들어 "CS2023"이라는 학번은 "CS"(전공)와 "2023"(입학년도)으로 나누어 해석할 수 있으므로 비원자적이다. 이때 1NF의 정의는 어떤 릴레이션 스키마 R에 대해, R의 모든 속성들의 도메인이 원자적이라는 것이다. 만약 1NF를 만족하지 않는다면, 복잡한 저장 방식이 필요하거나, 중복 저장을 야기할 수 있다. 이는 가장 기본적인 정규형이므로, 본 위키에서 특별한 언급이 없다면 모든 릴레이션이 1NF를 만족한다고 가정한다.

			이때 중요한 점은 도메인의 원자성이 해당 도메인의 속성이 아니라 사용 방식에 달려있다는 것이다. 위에서 관찰했듯이 문자열은 일반적으로 원자적이지만, 문자열을 부분으로 나누어 해석하면 그것은 더 이상 원자적이지 않다. "CS2023"과 같은 방식으로 데이터를 저장하고 그 문자열의 일부분을 통해 전공과 입학년도를 얻는다면, 이는 정보를 인코딩한것에 불과하다. 이는 정보가 DB 스키마가 아닌 응용 프로그램 로직에 묻혀버리기 때문에, 유지보수성, 이식성, 확장성 모두에서 문제를 유발하므로 나쁜 설계 방식이다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* More Normal Forms */

2025-05-19T16:23:38Z

More Normal Forms

← 이전 판		2025년 5월 19일 (월) 16:23 판
95번째 줄:		95번째 줄:
	==More Normal Forms==		==More Normal Forms==
	4NF는 결코 궁극적인 형태의 정규형이 아니다. 다만, 다중값 종속성을 활용해 함수 종속성만으로는 제거할 수 없는 일부 형태의 중복을 처리할 뿐이다. 그리하여 다중값 종속성 보다 더욱 일반화된 제약조건이 존재하는데, 그것이 바로 조인 종속성(join dependency)과 해당 종속성을 이용한 5NF(Fifth Normal Form)이다. 또한 이보다 더 일반적인 제약조건도 존재하며, 이는 DKNF(Domain-Key Normal Form)이라는 정규형으로 이어진다. 하지만 이런 일반화된 제약조건들을 사용하는 데는 문제가 있다. 이는 다루기 어려울 뿐더러, 해당 제약 조건들에 대해 정확하고 완전한 추론 규칙 체계가 존재하지 않는다는 것이다. 따라서 PJNF와 DKNF는 실제로 거의 사용되지 않는다.		4NF는 결코 궁극적인 형태의 정규형이 아니다. 다만, 다중값 종속성을 활용해 함수 종속성만으로는 제거할 수 없는 일부 형태의 중복을 처리할 뿐이다. 그리하여 다중값 종속성 보다 더욱 일반화된 제약조건이 존재하는데, 그것이 바로 조인 종속성(join dependency)과 해당 종속성을 이용한 5NF(Fifth Normal Form)이다. 또한 이보다 더 일반적인 제약조건도 존재하며, 이는 DKNF(Domain-Key Normal Form)이라는 정규형으로 이어진다. 하지만 이런 일반화된 제약조건들을 사용하는 데는 문제가 있다. 이는 다루기 어려울 뿐더러, 해당 제약 조건들에 대해 정확하고 완전한 추론 규칙 체계가 존재하지 않는다는 것이다. 따라서 PJNF와 DKNF는 실제로 거의 사용되지 않는다.

			==First Normal Form==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* More Normal Forms */

2025-05-19T15:15:21Z

More Normal Forms

← 이전 판		2025년 5월 19일 (월) 15:15 판
94번째 줄:		94번째 줄:

	==More Normal Forms==		==More Normal Forms==
			4NF는 결코 궁극적인 형태의 정규형이 아니다. 다만, 다중값 종속성을 활용해 함수 종속성만으로는 제거할 수 없는 일부 형태의 중복을 처리할 뿐이다. 그리하여 다중값 종속성 보다 더욱 일반화된 제약조건이 존재하는데, 그것이 바로 조인 종속성(join dependency)과 해당 종속성을 이용한 5NF(Fifth Normal Form)이다. 또한 이보다 더 일반적인 제약조건도 존재하며, 이는 DKNF(Domain-Key Normal Form)이라는 정규형으로 이어진다. 하지만 이런 일반화된 제약조건들을 사용하는 데는 문제가 있다. 이는 다루기 어려울 뿐더러, 해당 제약 조건들에 대해 정확하고 완전한 추론 규칙 체계가 존재하지 않는다는 것이다. 따라서 PJNF와 DKNF는 실제로 거의 사용되지 않는다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

2025년 5월 19일 (월) 15:11에 Pinkgo님의 편집

2025-05-19T15:11:16Z

← 이전 판		2025년 5월 19일 (월) 15:11 판
92번째 줄:		92번째 줄:
	===[[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]]===		===[[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]]===
	자세한 내용은 [[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]] 문서를 참조해 주십시오.		자세한 내용은 [[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]] 문서를 참조해 주십시오.

			==More Normal Forms==


	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* 4NF Decomposition Algorithm */

2025-05-19T14:09:53Z

4NF Decomposition Algorithm

← 이전 판		2025년 5월 19일 (월) 14:09 판
92번째 줄:		92번째 줄:
	===[[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]]===		===[[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]]===
	자세한 내용은 [[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]] 문서를 참조해 주십시오.		자세한 내용은 [[Relational Database Design#Decomposition Using Multivalued Dependencies#4NF Decomposition Algorithm\|4NF Decomposition Algorithm]] 문서를 참조해 주십시오.

	~~아래와 같은 BNCF에 속하는 스키마를 예를 들어 생각하자:~~
	~~r(ID, dept_name, street, city)~~
	위의 스키마에서는 [[Relational Database Design#Decomposition Using Multivalued Dependencies#Multivalued Dependencies\|다값 종속성(multivalued dependency)]] <code>ID →→ street, city</code>가 성립한다. 왜냐하면, instructor의 주소와 학과는 독립적인 관계를 가지므로, instructor의 주소 정보를 각 부서마다 반복해야 하기 때문이다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Fourth Normal Form */

2025-05-19T13:57:11Z

Fourth Normal Form

@@ 79번째 줄: / 79번째 줄: @@
 ==Fourth Normal Form==
 ==각주==
 [[분류:데이터베이스 시스템]]

Pinkgo: /* Higher Normal Form */

2025-05-19T13:17:25Z

Higher Normal Form

← 이전 판		2025년 5월 19일 (월) 13:17 판
76번째 줄:		76번째 줄:
	(99999, David, 981-992-3443)		(99999, David, 981-992-3443)
	(99999, William, 981-992-3443)		(99999, William, 981-992-3443)
	해당 relation 스키마가 이러한 문제점들을 가지고 있음에도, 해당 스키마에는 비자명한 함수 종속성이 존재하지 않으므로, BCNF를 만족한다. 즉, 함수 종속성을 이용한 스키마 분해는 불필요한 정보의 반복을 방지하기에는 충분치 않을 수 있다.		해당 relation 스키마가 이러한 문제점들을 가지고 있음에도, 해당 스키마에는 비자명한 함수 종속성이 존재하지 않으므로, BCNF를 만족한다. 즉, 함수 종속성을 이용한 스키마 분해는 불필요한 정보의 반복을 방지하기에는 충분치 않을 수 있다.

			==Fourth Normal Form==

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Redundancy in 3NF */

2025-05-12T15:12:22Z

Redundancy in 3NF

← 이전 판		2025년 5월 12일 (월) 15:12 판
57번째 줄:		57번째 줄:

	===Redundancy in 3NF===		===Redundancy in 3NF===
	[[파일:Redundancy in 3NF.png\|대체글=Figure 1. Redundancy in 3NF\|섬네일\|~~189x189픽셀~~\|'''Figure 1. Redundancy in 3NF''' ]]		[[파일:Redundancy in 3NF.png\|대체글=Figure 1. Redundancy in 3NF\|섬네일\|126x126px\|'''Figure 1. Redundancy in 3NF''' ]]
	3NF를 사용하는 스키마는 정보의 중복이나 null값 사용 등의 문제가 나타날 수 있다. 예를 들어, figure 1과 같이 3NF에 속하는 스키마가 아래와 같이 정의되어 있다고 하자:		3NF를 사용하는 스키마는 정보의 중복이나 null값 사용 등의 문제가 나타날 수 있다. 예를 들어, figure 1과 같이 3NF에 속하는 스키마가 아래와 같이 정의되어 있다고 하자:
	R = (J, K, L)		R = (J, K, L)

2025년 5월 1일 (목) 07:08에 Pinkgo님의 편집

2025-05-01T07:08:07Z

← 이전 판		2025년 5월 1일 (목) 07:08 판
57번째 줄:		57번째 줄:

	===Redundancy in 3NF===		===Redundancy in 3NF===
	3NF를 사용하는 스키마는 정보의 중복이나 null값 사용 등의 문제가 나타날 수 있다. 예를 들어, figure 2는 3NF에 속하는 스키마가 아래와 같이 정의되어 있다고 하자:		[[파일:Redundancy in 3NF.png\|대체글=Figure 1. Redundancy in 3NF\|섬네일\|189x189픽셀\|'''Figure 1. Redundancy in 3NF''' ]]
			3NF를 사용하는 스키마는 정보의 중복이나 null값 사용 등의 문제가 나타날 수 있다. 예를 들어, figure 1과 같이 3NF에 속하는 스키마가 아래와 같이 정의되어 있다고 하자:
	R = (J, K, L)		R = (J, K, L)
	F = { JK → L, L → K }		F = { JK → L, L → K }
71번째 줄:		72번째 줄:
	즉, 정규화는 무손실성과 함수 종속성 보존을 유지하면서 정규형에 맞는 스키마로 분해하는 것이 핵심이다. 이때, 어떤 데이터베이스 스키마는 BCNF를 만족하더라도 충분히 정규화된 것처럼 보이지 않을 수 있다. 예를 들어 inst_info relation에 대한 스키마가 아래와 같이 주어져있다고 해보자.		즉, 정규화는 무손실성과 함수 종속성 보존을 유지하면서 정규형에 맞는 스키마로 분해하는 것이 핵심이다. 이때, 어떤 데이터베이스 스키마는 BCNF를 만족하더라도 충분히 정규화된 것처럼 보이지 않을 수 있다. 예를 들어 inst_info relation에 대한 스키마가 아래와 같이 주어져있다고 해보자.
	inst_info(ID, child_name, phone)		inst_info(ID, child_name, phone)
	이때 하나의 강사가 여러 자녀와 여러 휴대폰 번호를 가질 수 있으므로, figure 1과 같은 인스턴스가 생길 수 있다. 이는 동일한 정보가 각각의 자녀에 대해 따로 저장되었으므로, 정보의 중복이 발생한 인스턴스이다. 또한 새로운 전화 번호 981-992-3443을 추가하고 싶을 때에는 아래와 같이 David와 William 모두에 대해 각각 튜플을 넣어야 한다:		[[파일:BCNF Redundency example.png\|대체글=Figure 2. BCNF Redundency example\|섬네일\|200x200픽셀\|Figure 2. BCNF Redundency example]]
			이때 하나의 강사가 여러 자녀와 여러 휴대폰 번호를 가질 수 있으므로, figure 2와 같은 인스턴스가 생길 수 있다. 이는 동일한 정보가 각각의 자녀에 대해 따로 저장되었으므로, 정보의 중복이 발생한 인스턴스이다. 또한 새로운 전화 번호 981-992-3443을 추가하고 싶을 때에는 아래와 같이 David와 William 모두에 대해 각각 튜플을 넣어야 한다:
	(99999, David, 981-992-3443)		(99999, David, 981-992-3443)
	(99999, William, 981-992-3443)		(99999, William, 981-992-3443)