데이터베이스 정규화
Database normalization |
데이터베이스 정규화(Database Normalization) 또는 데이터베이스 정규화(Database Normalization)는 데이터 중복을 줄이고 데이터 무결성을 향상시키기 위해 일련의 소위 정상 형태에 따라 관계형 데이터베이스를 구조화하는 과정입니다.이것은 영국의 컴퓨터 과학자 에드거 F에 의해 처음으로 제안되었습니다. 그의 관계형 모델의 일부로 Codd.
정규화는 데이터베이스의 열(속성) 및 테이블(관계)을 구성하여 데이터베이스 무결성 제약 조건에 따라 종속성이 적절하게 적용되도록 합니다.이는 합성(새 데이터베이스 설계 작성) 또는 분해(기존 데이터베이스 설계 개선) 과정을 통해 몇 가지 공식 규칙을 적용함으로써 이루어집니다.
목표
1970년 Codd에 의해 정의된 최초의 정상 형태의 기본적인 목적은 1차 [1]논리에 기초한 "보편적 데이터 하위 언어"를 사용하여 데이터를 쿼리하고 조작하는 것을 허용하는 것이었습니다.그러한 언어의 예로는 SQL이 있지만 Codd가 심각한 [2]결함이 있다고 간주한 언어입니다.
코드는 1NF(최초의 정상 형태) 이상의 정규화의 목표를 다음과 같이 밝혔습니다.
- 바람직하지 않은 삽입, 업데이트 및 삭제 종속성으로부터 관계 수집을 해방합니다.
- 새로운 유형의 데이터가 도입됨에 따라 관계 수집을 재구성할 필요성을 줄이기 위해 응용 프로그램의 수명을 늘립니다.
- 관계형 모델을 사용자에게 보다 유용하게 제공합니다.
- 이러한 통계가 시간이 지남에 따라 변경되기 쉬운 쿼리 통계에 대해 관계 수집이 중립적이 되도록 합니다.
— E.F. Codd, "Further Normalisation of the Data Base Relational Model"[3]
관계를 수정(업데이트, 삽입 또는 삭제)하려고 시도할 경우 충분히 정규화되지 않은 관계에서 다음과 같은 바람직하지 않은 부작용이 발생할 수 있습니다.
- 삽입 이상.일정한 사실을 전혀 기록할 수 없는 사정이 있습니다.예를 들어, "교수 및 과정" 관계에 있는 각 기록에는 교수 ID, 교수 이름, 교수 채용 날짜 및 과정 코드가 포함될 수 있습니다.따라서 적어도 하나 이상의 과정을 가르치는 교직원의 내용은 기록할 수 있지만, 아직 과정 코드를 null로 설정하지 않은 신규 채용 교직원은 기록할 수 없습니다.
- 업데이트 이상.동일한 정보를 여러 행에 표현할 수 있으므로 관계를 업데이트하면 논리적으로 불일치할 수 있습니다.예를 들어, "Employee's Skills" 관계에 있는 각 레코드에는 Employee ID, Employee Address(직원 주소) 및 Skill(기능)이 포함될 수 있으므로, 특정 직원에 대한 주소 변경을 여러 레코드(기능별로 하나씩)에 적용해야 할 수 있습니다.업데이트가 일부만 성공한 경우(일부 기록에서는 직원의 주소가 업데이트되지만 일부 기록에서는 업데이트되지 않은 경우), 관계는 일관되지 않은 상태로 유지됩니다.구체적으로, 이 관계는 이 직원의 주소가 무엇인지에 대한 상반된 답변을 제공합니다.
- 삭제 이상.특정한 상황에서 특정한 사실을 나타내는 자료의 삭제는 전혀 다른 사실을 나타내는 자료의 삭제를 필요로 합니다.위 예에서 설명한 '교수자와 그들의 강좌' 관계는 이와 같은 변칙을 겪고 있는데, 교수가 어떠한 강좌에도 배정을 일시적으로 중단하는 경우에는 그 교수자가 등장하는 기록 중 마지막 부분을 삭제하여야 함으로써 사실상 교수자를 삭제하고,Course Code 필드가 null로 설정되지 않은 경우.
데이터베이스 구조 확장 시 재설계 최소화
완전히 정규화된 데이터베이스를 사용하면 기존 구조를 크게 변경하지 않고도 새로운 유형의 데이터를 수용할 수 있도록 구조를 확장할 수 있습니다.결과적으로 데이터베이스와 상호 작용하는 응용프로그램은 최소한의 영향을 받습니다.
정규화된 관계, 그리고 하나의 정규화된 관계와 다른 관계 사이의 관계는 실제 세계의 개념과 그들의 상호관계를 반영합니다.
정상형태
Codd는 [4]1970년에 정규화의 개념과 현재 최초의 정규 형태(1NF)로 알려진 것을 소개했습니다.1971년에 Codd는 두 번째 정규 형태(2NF)와 세 번째 정규 형태(3NF)를 정의했고,[5] Codd와 Raymond F. 보이스(Boyce)[6]는 1974년에 BCNF(Boyce-Codd normal form)를 정의했습니다.
비공식적으로 관계형 데이터베이스 관계가 세 번째 정규 [7]형태를 충족하는 경우 "정규화"된 것으로 표현되는 경우가 많습니다.대부분의 3NF 관계에는 삽입, 업데이트 및 삭제 이상이 없습니다.
(최소 정규화에서 최대 정규화) 정규화된 형태는 다음과 같습니다.
| 제약조건 (괄호 안에 설명 포함) | UNF (1970) | 1NF (1970) | 2NF (1971) | 3NF (1971) | EKNF (1982) | BCNF (1974) | 4NF (1977) | ETNF (2012) | 5NF (1979) | DKNF (1981) | 6NF (2003) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 고유 행(중복 [4]레코드 없음) |  |  | | | | | | | | | |
| 스칼라 열(열에는 관계 또는 합성 [5]값을 포함할 수 없음) |  | | | | | | | | | | |
| 모든 비우량 속성은 후보 키에 대한 완전한 기능적 종속성을 갖습니다(속성은 모든 [5]키의 전체에 따라 다름). | | | | | | | | | | | |
| 중요하지 않은 모든 기능적 의존성은 수퍼키로 시작하거나 프라임 속성으로 끝납니다(속성은 [5]후보 키에만 의존합니다). | | | | | | | | | | | |
| 모든 사소한 기능 의존성은 수퍼키로 시작하거나 기본적인 프라임 속성(3NF의 더 엄격한 형태)으로 끝납니다. | | | | | | | | | | | — |
| 사소한 모든 기능적 의존성은 슈퍼키(3NF의 더 엄격한 형태)로 시작됩니다. | | | | | | | | | | | — |
| 사소한 것이 아닌 모든 다중값 의존성은 수퍼키로 시작합니다. | | | | | | | | | | | — |
| 모든 조인 종속성에는 수퍼키[8] 구성 요소가 있습니다. | | | | | | | | | | | — |
| 모든 조인 종속성에는 슈퍼키 구성 요소만 있습니다. | | | | | | | | | | | — |
| 모든 제약 조건은 도메인 제약 조건과 주요 제약 조건의 결과입니다. | | | | | | | | | | | |
| 모든 조인 종속성은 사소한 것입니다. | | | | | | | | | | | |
단계별 정규화 예제
정규화는 상위 정규 형태까지 관계형 [9]데이터베이스 테이블을 설계하는 데 사용되는 데이터베이스 설계 기법입니다.프로세스는 점진적이며 이전 수준이 [10]충족되지 않는 한 더 높은 수준의 데이터베이스 정규화를 달성할 수 없습니다.
즉, 정규화되지 않은 형태의 데이터를 가지고 가장 높은 수준의 정규화를 달성하는 것을 목표로 하는 첫 번째 단계는 첫 번째 정규화 형태를 준수하는지 확인하는 것이고, 두 번째 단계는 두 번째 정규화 형태를 만족하는지 확인하는 것이며, 따라서 데이터가 여섯 번째 정규화 형태를 준수할 때까지 위에서 언급한 순서대로 수행하는 것입니다.
그러나 4NF를 넘어서는 정상 형태는 주로 학문적 관심사라는 점에 주목할 필요가 있는데,[11] 이는 그것들이 해결하기 위해 존재하는 문제들이 실제적으로 거의 나타나지 않기 때문입니다.
다음 예제의 데이터는 대부분의 정규 형태와 모순되도록 의도적으로 설계되었습니다.실제로는 데이터가 이미 어느 정도 정규화되었기 때문에 일부 정규화 단계를 생략할 수도 있습니다.일반적인 형태의 위반을 수정하면 일반적으로 일반적인 형태의 위반도 수정됩니다.예제에서는 각 단계에서 정규화를 위해 하나의 테이블을 선택했는데, 이는 마지막에 일부 테이블이 충분히 정규화되지 않을 수 있음을 의미합니다.
초기자료
다음 [10]구조의 데이터베이스 테이블이 존재하도록 합니다.
| 제목 | 작가. | 작가국적 | 서식 | 가격. | 주제 | 페이지들 | 두께 | 출판인 | 게시자 국가 | 장르ID | 장르명 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| MySQL 데이터베이스 설계 및 최적화 시작 | 채드 러셀 | 아메리카의 | 하드커버 | 49.99 |
| 520 | 두꺼운 | 프레스 | 미국 | 1 | 자습서 |
이 예제에서는 각 책에 한 명의 저자만 있다고 가정합니다.
관계형 모델을 준수하는 표에는 행을 고유하게 식별하는 기본 키가 있습니다.두 권의 책은 같은 제목을 가질 수 있지만 ISBN은 책을 고유하게 식별하기 때문에 기본 키로 사용할 수 있습니다.
| ISBN | 제목 | 작가. | 작가국적 | 서식 | 가격. | 주제 | 페이지들 | 두께 | 출판인 | 게시자 국가 | 장르ID | 장르명 | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | MySQL 데이터베이스 설계 및 최적화 시작 | 채드 러셀 | 아메리카의 | 하드커버 | 49.99 |
| 520 | 두꺼운 | 프레스 | 미국 | 1 | 자습서 |
만족스러운 1NF
첫 번째 정규 형태에서는 각 필드에 단일 값이 포함됩니다.필드에는 값 집합이나 중첩 레코드가 포함되지 않을 수 있습니다.
제목에 제목 값 집합이 포함되어 있으므로 이 값이 준수되지 않습니다.
문제를 해결하기 위해 제목을 별도의 제목 [10]테이블로 추출합니다.
| ISBN | 제목 | 작가. | 작가국적 | 서식 | 가격. | 페이지들 | 두께 | 출판인 | 게시자 국가 | 장르ID | 장르명 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1590593324 | MySQL 데이터베이스 설계 및 최적화 시작 | 채드 러셀 | 아메리카의 | 하드커버 | 49.99 | 520 | 두꺼운 | 프레스 | 미국 | 1 | 자습서 |
| ISBN | 제목명 |
|---|---|
| 1590593324 | MySQL |
| 1590593324 | 데이터베이스 |
| 1590593324 | 설계. |
제목에서 ISBN은 외부 키입니다.그것은 책의 주요 키를 가리키며, 이 두 표 사이의 관계를 명시적으로 만듭니다.
정규화되지 않은 형태의 하나의 테이블 대신, 이제 1NF에 부합하는 두 개의 테이블이 있습니다.
만족스러운 2NF
아래 Book 테이블에는 복합 키가 {Title, Format}(밑줄로 표시)되어 있으며, 해당 키의 일부 하위 집합이 결정 요소인 경우 2NF를 만족하지 않습니다.이 시점에서 설계 시 키는 기본 키로 확정되지 않으므로 후보 키라고 합니다.다음 표를 생각해 보십시오.
| 제목 | 서식 | 작가. | 작가국적 | 가격. | 페이지들 | 두께 | 출판인 | 게시자 국가 | 장르ID | 장르명 |
|---|---|---|---|---|---|---|---|---|---|---|
| MySQL 데이터베이스 설계 및 최적화 시작 | 하드커버 | 채드 러셀 | 아메리카의 | 49.99 | 520 | 두꺼운 | 프레스 | 미국 | 1 | 자습서 |
| MySQL 데이터베이스 설계 및 최적화 시작 | 전자책 | 채드 러셀 | 아메리카의 | 22.34 | 520 | 두꺼운 | 프레스 | 미국 | 1 | 자습서 |
| 데이터베이스 관리를 위한 관계형 모델:버전2 | 전자책 | E.F.Codd | 영국의 | 13.88 | 538 | 두꺼운 | 애디슨-웨슬리 | 미국 | 2 | 대중과학 |
| 데이터베이스 관리를 위한 관계형 모델:버전2 | 페이퍼백 | E.F.Codd | 영국의 | 39.99 | 538 | 두꺼운 | 애디슨-웨슬리 | 미국 | 2 | 대중과학 |
후보 키의 일부가 아닌 모든 속성은 제목에 따라 달라지며, 가격만 형식에 따라 달라집니다.2NF를 준수하고 중복을 제거하려면 후보 키가 아닌 모든 속성이 후보 키의 일부가 아니라 전체에 의존해야 합니다.
이 테이블을 정규화하려면 모든 비후보 키 속성이 전체 후보 키에 의존하도록 {Title}을(를) 후보 키(기본 키)로 만들고, Price를 별도의 테이블로 제거하여 형식에 대한 종속성을 유지합니다.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
이제 Book과 Price 테이블 모두 2NF에 부합합니다. 만족스러운 3NFBook 테이블에 경과적 기능 종속성이 여전히 있습니다({Author Nationality}는 {Title}에 종속됨).게시자({Publisher Country}가 {Title}에 종속적인 {Publisher}) 및 장르({GenerName}이(가) {Title}에 종속적인 {Gener ID}에 대해 유사한 위반이 있습니다.따라서 북 테이블은 3NF에 없습니다.3NF로 만들기 위해 다음 표 구조를 사용하여 {Auther Nationality}, {Publisher Country} 및 {GenerName}을(를) 각각의 표에 배치하여 과도적 기능 종속성을 제거합니다.
EKNF 만족하기기본 키 정규 형태(EKNF)는 엄격하게 3NF와 BCNF 사이에 속하며 문헌에서 많이 논의되지 않습니다.이는 "3NF와 BCNF 모두의 두드러진 특성을 포착하고" 동시에 두 가지 문제를 방지하기 위한 것입니다(즉, 3NF는 "너무 용서"하고 BCNF는 "계산 복잡성이 발생하기 쉽다").문헌에 거의 언급되지 않기 때문에 본 예시에는 포함되지 않습니다. 만족스러운 4NF데이터베이스가 서로 다른 위치에 상점을 소유하고 있는 여러 개의 프랜차이즈 가맹점이 있는 도서 소매점 프랜차이즈가 소유하고 있다고 가정합니다.이에 따라 소매업체는 다양한 위치에서 책을 구입할 수 있는지에 대한 데이터가 포함된 표를 추가하기로 결정했습니다.
이 테이블 구조는 복합 기본 키로 구성되어 있기 때문에 키가 아닌 속성을 포함하지 않으며 이미 BCNF에 포함되어 있습니다(따라서 이전의 모든 정규 형태를 만족합니다).그러나 각 영역에서 사용 가능한 모든 책이 제공된다고 가정하면 제목이 특정 위치에 명확하게 구속되지 않으므로 표가 4NF를 만족하지 않습니다. 즉, 네 번째 정규 형태를 만족시키려면 이 표도 분해해야 합니다.
이제 모든 기록은 슈퍼키에 의해 명확하게 식별되므로 4NF가 충족됩니다. ETNF 만족하기가맹점주들이 다른 공급업체로부터 책을 주문할 수도 있다고 가정해 보겠습니다.관계 역시 다음과 같은 제약 조건을 따르도록 합니다.
이 표는 4NF에 있지만 공급자 ID는 해당 프로젝션의 조인과 동일합니다. {{공급자 ID, 제목}, {제목, 프랜차이즈 ID}, {프랜차이즈 ID}.이 조인 종속성의 구성 요소는 슈퍼키가 아니므로(유일한 슈퍼키는 전체 표제), 테이블은 ETNF를 만족하지 않고 더 [12]분해할 수 있습니다.
그 분해는 ETNF를 준수합니다. 만족스러운 5NF5NF를 만족하지 않는 표를 발견하려면 일반적으로 데이터를 철저히 검사해야 합니다.데이터를 약간 수정한 4NF 예제의 표를 가정하고 5NF를 만족하는지 조사해 보겠습니다.
이 테이블을 분해하면 중복성이 낮아져 다음과 같은 두 개의 테이블이 생성됩니다.
이 테이블에 결합하는 쿼리는 다음 데이터를 반환합니다.
JOIN은 필요한 것보다 세 개의 행을 더 많이 반환합니다. 다른 테이블을 추가하여 관계를 명확하게 하면 세 개의 개별 테이블이 생성됩니다.
JOIN은 이제 무엇으로 돌아올까요?실제로 이 세 개의 테이블에 합류하는 것은 불가능합니다.즉, 데이터 손실 없이 프랜차이즈 가맹점 - 장부 - 위치를 분해할 수 없으므로 표는 이미 5NF를 만족합니다. C.J. Date는 5NF의 데이터베이스만 진정으로 "정상화"[13]된다고 주장했습니다. DKNF 만족하기이전 예제의 Book 테이블을 살펴보고 도메인 키 정규 형식을 충족하는지 알아보겠습니다.
논리적으로 두께는 페이지 수에 따라 결정됩니다.이는 키가 아닌 페이지에 따라 다름을 의미합니다.350페이지까지의 책은 "날씬한" 것으로 간주하고 350페이지 이상의 책은 "두툼한" 것으로 간주한다는 예규를 설정해 봅시다. 이 규칙은 엄밀히 말하면 제약 조건이지만 도메인 제약 조건이나 핵심 제약 조건은 아닙니다. 따라서 데이터 무결성을 유지하기 위해 도메인 제약 조건과 핵심 제약 조건에 의존할 수 없습니다. 다시 말해, 예를 들어, 50페이지 밖에 되지 않는 책에 대해 "두꺼운"을 넣는 것을 막지 못하는 그 어떤 것도 테이블이 DKNF를 위반하게 만듭니다. 이를 해결하기 위해 Thickness를 정의하는 테이블 고정 열거가 생성되고 해당 열이 원래 테이블에서 제거됩니다.
이렇게 하면 도메인 무결성 위반이 제거되고 테이블은 DKNF에 있습니다. 6NF 만족여섯 번째 정규 형태에 대한 단순하고 직관적인 정의는 "행에 기본 키와 기껏해야 하나의 다른 [14]속성이 포함되어 있을 때 테이블이 6NF에 있다"는 것입니다. 예를 들어, 1NF를 생성하는 동안 설계된 Publisher 테이블을 의미합니다.
를 두 개의 테이블로 더 분해해야 합니다.
6NF의 명백한 단점은 단일 개체에 대한 정보를 표현하는 데 필요한 테이블의 확산입니다.5NF의 테이블에 하나의 기본 키 열과 N개의 속성이 있는 경우 6NF에 동일한 정보를 표현하려면 N개의 테이블이 필요합니다. 단일 개념 레코드에 대한 다중 필드 업데이트는 여러 테이블에 대한 업데이트를 필요로 하며 삽입 및 삭제도 마찬가지로 여러 테이블에 대한 작업을 필요로 합니다.이러한 이유로 온라인 트랜잭션 처리(OLTP) 요구를 충족하기 위한 데이터베이스에서는 6NF를 사용해서는 안 됩니다. 그러나 대화형 업데이트를 허용하지 않고 대규모 데이터 볼륨에 대한 빠른 쿼리에 특화된 데이터 웨어하우스에서는 특정 DBMS가 컬럼 데이터 저장소로 알려진 내부 6NF 표현을 사용합니다.열의 고유 값 수가 테이블의 행 수보다 훨씬 적은 상황에서 열 중심 스토리지를 사용하면 데이터 압축을 통해 공간을 크게 절약할 수 있습니다.또한 컬럼 저장을 통해 범위 쿼리를 빠르게 실행할 수 있습니다(예: 특정 컬럼이 X와 Y 사이에 있거나 X보다 작은 모든 레코드를 표시). 그러나 이 모든 경우에 데이터베이스 설계자는 별도의 테이블을 만들어 수동으로 6NF 정규화를 수행할 필요가 없습니다.Sybase IQ와 같이 웨어하우징에 특화된 일부 DBMS는 기본적으로 컬럼 스토리지를 사용하지만 설계자는 여전히 단일 다중 컬럼 테이블만 볼 수 있습니다.Microsoft SQL Server 2012 이상과 같은 다른 DBMS에서는 특정 [15]테이블에 대해 "열 저장소 인덱스"를 지정할 수 있습니다. 참고 항목참고 및 참고 자료
추가열람
외부 링크
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
