3 정규형 (데이터베이스) 가뿐만 아니라 제 2 정규형을 준수 구성하는 다른 테이블 있지만, 모든 속성 또는 필드가 기본 키에 직접적으로 의존하는 관계형 데이터베이스 설계 기법이다.
데이터베이스를 설계 할 때 주요 목표는 데이터, 데이터 간의 관계 및 관련 데이터에 대한 제한 사항을 정확하게 표현하는 것입니다.
출처 : pixabay.com
이 목표를 달성하기 위해 일부 데이터베이스 설계 기술을 사용할 수 있으며 그중에는 정규화가 있습니다.
이는 데이터의 삽입, 업데이트 또는 제거시 중복성과 가능한 이상을 피하기 위해 데이터베이스에 데이터를 구성하는 프로세스로, 개념 모델의 단순하고 안정적인 설계를 생성합니다.
속성 간의 기능적 관계 또는 종속성을 조사하는 것으로 시작됩니다. 이들은 데이터의 일부 속성 또는 이들 간의 관계를 설명합니다.
정상적인 모양
정규화는 정규 형식이라고하는 일련의 테스트를 사용하여 이러한 특성의 최적 그룹을 식별하고 궁극적으로 회사의 데이터 요구 사항을 지원하는 적절한 관계 집합을 설정합니다.
즉, 정규화 기술은 제약 시스템을 정의하는 정규 형식의 개념을 중심으로 구축됩니다. 관계가 특정 정규 형식의 제약 조건을 충족하는 경우 관계는 해당 정규 형식이라고합니다.
첫 번째 정규형 (1FN)
테이블 내의 모든 속성 또는 필드에 고유 한 값만 포함 된 경우 테이블은 1FN에 있다고합니다. 즉, 각 속성의 모든 값은 나눌 수 없습니다.
정의에 따라 관계형 데이터베이스는 속성 값이 항상 원자 적이기 때문에 항상 첫 번째 정규 형식으로 정규화됩니다. 데이터베이스의 모든 관계는 1FN에 있습니다.
그러나 이와 같이 데이터베이스를 그대로두면 중복성 및 가능한 업그레이드 실패와 같은 여러 문제가 발생합니다. 이러한 문제를 해결하기 위해 더 높은 정상 형태가 개발되었습니다.
두 번째 정규형 (2FN)
테이블에서 순환 종속성을 제거합니다. 관계가 1FN에있는 경우 2FN에 있다고 말하며 키가 아닌 각 필드 또는 속성은 전적으로 기본 키에 의존하거나보다 구체적으로 테이블이 단일 목적을 갖도록합니다.
키가 아닌 속성은 관계에 대한 기본 키의 일부가 아닌 모든 속성입니다.
세 번째 정규형 (3FN)
테이블에서 전 이적 종속성을 제거합니다. 즉, 기본 키에 의존하지 않고 다른 속성에 의존하는 키가 아닌 속성을 제거합니다.
전 이적 종속성은 키가 아닌 필드 또는 특성의 값이 키가 아닌 다른 필드의 값에 의해 결정되는 기능적 종속성 유형입니다.
키가 아닌 속성에서 반복되는 값을 찾아 이러한 키가 아닌 속성이 기본 키 이외의 다른 것에 의존하지 않도록해야합니다.
속성 중 어느 것도 기능적으로 다른 조합에 의존하지 않는 경우 속성은 상호 독립적이라고합니다. 이러한 상호 독립성을 통해 다른 속성에 영향을 미칠 위험없이 속성을 개별적으로 업데이트 할 수 있습니다.
따라서 데이터베이스의 관계가 세 번째 정규 형식이 되려면 다음을 준수해야합니다.
-2FN의 모든 요구 사항.
-기본 키와 관련이없는 속성이있는 경우 해당 속성을 제거하고 별도의 테이블에 배치하여 두 테이블을 외래 키로 연결해야합니다. 즉, 전 이적 종속성이 없어야합니다.
세 번째 정규형의 예
예 1
기본 키가 학생의 ID (STUDENT_ID)이고 STUDENT_NAME, STREET, CITY 및 POST_CODE 속성으로 구성되어 2FN이되는 조건을 충족하는 테이블을 STUDENT로 설정합니다.
이 경우 STREET 및 CITY는 학생과 직접 관련이 없지만 우편 번호에 전적으로 의존하기 때문에 기본 키 STUDENT_ID와 직접적인 관계가 없습니다.
학생이 CODE_POSTAL에 의해 결정된 사이트에 의해 위치하므로 STREET 및 CITY는이 속성과 관련이 있습니다. 이 두 번째 종속성으로 인해 이러한 속성을 STUDENT 테이블에 저장할 필요가 없습니다.
새 테이블 만들기
STUDENT 테이블에 막대한 양의 레코드가 있고 거리 나 도시의 이름을 변경해야하는 동일한 우편 번호에 여러 학생이 있고,이 거리 또는 도시를 전체 테이블에서 찾아서 업데이트해야한다고 가정합니다. 학생.
예를 들어 거리 "El Limón"을 "El Limón II"로 변경해야하는 경우 전체 STUDENT 테이블에서 "El Limón"을 검색 한 다음 "El Limón II"로 업데이트해야합니다.
거대한 테이블에서 검색하고 단일 또는 다중 레코드를 업데이트하는 데 시간이 오래 걸리므로 데이터베이스 성능에 영향을 미칩니다.
대신, 이러한 세부 사항은 POST_CODE 속성을 사용하여 STUDENT 테이블과 관련된 별도의 테이블 (POSTCARD)에 보관 될 수 있습니다.
POST 테이블에는 비교적 적은 수의 레코드가 있으며이 POST 테이블은 한 번만 업데이트하면됩니다. 이것은 STUDENT 테이블에 자동으로 반영되어 데이터베이스와 쿼리를 단순화합니다. 따라서 테이블은 3FN에 있습니다.
예 2
Project_Num 필드를 기본 키로 사용하고 키가 아닌 속성에서 반복되는 값으로 다음 테이블을 사용합니다.
관리자 이름이 반복 될 때마다 전화 값이 반복됩니다. 이는 전화 번호가 프로젝트 번호에 2 차 의존성을 갖기 때문입니다. 그것은 실제로 관리자에게 먼저 의존하고, 이것은 차례로 프로젝트 번호에 의존하여 전 이적 의존성을 만듭니다.
동일한 관리자가 둘 이상의 프로젝트를 관리하므로 Project_Manager 속성은 Projects 테이블에서 가능한 키가 될 수 없습니다. 이에 대한 해결책은 반복되는 데이터 (Phone)가있는 속성을 제거하여 별도의 테이블을 만드는 것입니다.
해당 속성을 함께 그룹화하여 새 테이블을 만들어 저장해야합니다. 데이터가 입력되고 반복되는 값이 기본 키의 일부가 아님이 확인됩니다. 각 테이블에 대해 기본 키가 설정되고 필요한 경우 외래 키가 추가됩니다.
세 번째 정규 형식을 준수하기 위해 문제를 해결하기 위해 새 테이블 (Managers)이 생성됩니다. 두 테이블 모두 Project_Manager 필드를 통해 관련됩니다.
참고 문헌
- Teradata (2019). 첫 번째, 두 번째 및 세 번째 정규형. 출처 : docs.teradata.com.
- 튜토리얼 컵 (2019). 제 3 정규형 (3NF). 출처 : tutorialcup.com.
- 데이터베이스 개발 (2015). Third Normal Form (3NF)-데이터베이스 정규화. 출처 : databasedev.co.uk.
- 관계형 DB 설계 (2019). 세 번째 정규형 소개. 출처 : relationaldbdesign.com.
- Dummies (2019). SQL First, Second 및 Third Normal Forms. 출처 : dummies.com.