이 문서에서는 초보자를 위한 데이터베이스 정규화 용어를 설명합니다. 이 용어에 대한 기본적인 이해는 관계형 데이터베이스의 설계에 대해 논의할 때 유용합니다.
정규화에 대한 설명
정규화는 데이터베이스에서 데이터를 구성하는 프로세스입니다. 여기에는 데이터를 보호하고 중복성과 일관성 없는 종속성을 제거하여 데이터베이스를 보다 유연하게 만들기 위해 설계된 규칙에 따라 테이블을 만들고 해당 테이블 간에 관계를 설정하는 것이 포함됩니다.
중복 데이터는 디스크 공간을 낭비하고 유지 관리 문제를 만듭니다. 둘 이상의 위치에 있는 데이터를 변경해야 하는 경우 모든 위치에서 정확히 동일한 방식으로 데이터를 변경해야 합니다. 고객 주소 변경은 해당 데이터가 Customers 테이블에만 저장되고 데이터베이스의 다른 위치에는 저장되지 않는 경우 보다 쉽게 구현할 수 있습니다.
"일관성 없는 종속성"은 무엇인가요? 사용자가 고객 테이블에서 특정 고객의 주소를 확인하는 것은 직관적이지만, 해당 고객에게 전화를 하는 직원의 급여를 찾는 것은 의미가 없을 수 있습니다. 직원의 급여는 직원과 관련되거나 종속되므로 직원 테이블로 이동해야 합니다. 일관성 없는 종속성으로 인해 데이터를 찾는 경로가 누락되거나 손상될 수 있으므로 데이터에 액세스하기 어려울 수 있습니다.
데이터베이스 정규화에 대한 몇 가지 규칙이 있습니다. 각 규칙을 "일반 양식"이라고 합니다. 첫 번째 규칙이 관찰되면 데이터베이스는 "첫 번째 일반 형식"이라고 합니다. 처음 세 규칙이 관찰되면 데이터베이스는 "세 번째 정규 형식"으로 간주됩니다. 다른 수준의 정규화가 가능하지만, 세 번째 정규식은 대부분의 애플리케이션에 필요한 가장 높은 수준으로 간주됩니다.
많은 공식 규칙 및 사양과 마찬가지로 실제 시나리오에서 항상 완벽한 규정 준수를 허용하지는 않습니다. 일반적으로 정규화에는 추가 테이블이 필요하며 일부 고객은 이 번거로울 수 있습니다. 처음 세 가지 정규화 규칙 중 하나를 위반하려는 경우 애플리케이션에서 중복 데이터 및 일관되지 않은 종속성과 같은 발생할 수 있는 문제를 예상하는지 확인합니다.
다음 설명에는 예제가 포함되어 있습니다.
첫 번째 일반 양식
- 개별 테이블에서 반복 그룹을 제거합니다.
- 각 관련 데이터 집합에 대해 별도의 테이블을 만듭니다.
- 기본 키를 사용하여 각 관련 데이터 집합을 식별합니다.
단일 테이블에 여러 필드를 사용하여 유사한 데이터를 저장하지 마세요. 예를 들어 가능한 두 소스에서 제공되는 인벤토리 항목을 추적하기 위해 인벤토리 레코드에는 공급업체 코드 1 및 공급업체 코드 2에 대한 필드가 포함될 수 있습니다.
세 번째 공급업체를 추가하면 어떻게 되나요? 필드를 추가하는 것은 답이 아닙니다. 프로그램 및 테이블 수정이 필요하며 동적 공급 업체 수를 원활하게 수용하지 않습니다. 대신, 공급업체라는 별도의 테이블에 모든 공급업체 정보를 배치한 다음, 항목 번호 키를 사용하여 인벤토리를 공급업체에 연결하거나, 공급업체 코드 키를 사용하여 공급업체를 인벤토리에 연결합니다.
두 번째 표준 형식
- 여러 레코드에 적용되는 값 집합에 대해 별도의 테이블을 만듭니다.
- 이러한 테이블을 외래 키로 연결합니다.
레코드는 테이블의 기본 키(필요한 경우 복합 키) 이외의 항목에 의존해서는 안 됩니다. 예를 들어 회계 시스템에서 고객의 주소를 고려합니다. 주소는 Customers 테이블뿐만 아니라 주문, 배송, 송장, 미수금 및 컬렉션 테이블에도 필요합니다. 고객 주소를 각 테이블에 별도의 항목으로 저장하는 대신 고객 테이블 또는 별도의 주소 테이블에 한 곳에 저장합니다.
세 번째 기본형
- 키에 의존하지 않는 필드를 제거합니다.
해당 레코드의 키에 속하지 않는 레코드의 값은 테이블에 속하지 않습니다. 일반적으로 필드 그룹의 내용이 테이블의 단일 레코드 이상에 적용될 수 있는 경우 해당 필드를 별도의 테이블에 배치하는 것이 좋습니다.
예를 들어 직원 채용 테이블에는 후보자의 대학 이름과 주소가 포함될 수 있습니다. 그러나 그룹 우편 발송을 위한 대학의 전체 목록이 필요합니다. 대학 정보가 후보 테이블에 저장되는 경우 현재 후보자가 없는 대학을 나열할 수 있는 방법은 없습니다. 별도의 Universityies 테이블을 만들고 대학 코드 키를 사용하여 후보 테이블에 연결합니다.
예외: 이론적으로는 바람직하지만 세 번째 정규 형식을 준수하는 것이 항상 실용적인 것은 아닙니다. Customers 테이블이 있고 가능한 모든 필드 간 종속성을 제거하려면 도시, 우편 번호, 영업 담당자, 고객 클래스 및 여러 레코드에 중복될 수 있는 기타 요소에 대해 별도의 테이블을 만들어야 합니다. 이론적으로 정규화는 추구할 가치가 있습니다. 그러나 작은 테이블이 많으면 성능이 저하되거나 열린 파일 및 메모리 용량을 초과할 수 있습니다.
자주 변경되는 데이터에만 세 번째 일반 양식을 적용하는 것이 더 가능할 수 있습니다. 일부 종속 필드가 남아 있는 경우 사용자가 변경될 때 모든 관련 필드를 확인하도록 애플리케이션을 디자인합니다.
기타 정규화 양식
BCNF(Boyce-Codd Normal Form)라고도 하는 네 번째 표준 양식과 다섯 번째 정규 양식은 존재하지만 실용적인 디자인에서는 거의 고려되지 않습니다. 이러한 규칙을 무시하면 데이터베이스 디자인이 완벽하지 않을 수 있지만 기능에 영향을 주지 않아야 합니다.
예제 테이블 정규화
이러한 단계에서는 가상의 학생 테이블을 정규화하는 프로세스를 보여 줍니다.
비정규화 테이블:
학생# 조언자 Adv-Room 클래스1 Class2 Class3 1022 존스 412 101-07 143-01 159-02 4123 스미스 216 101-07 143-01 179-04 첫 번째 일반 양식: 반복 그룹 없음
테이블에는 두 개의 차원만 있어야 합니다. 한 학생에게 여러 수업이 있으므로 이러한 클래스는 별도의 테이블에 나열되어야 합니다. 위 레코드의 Class1, Class2 및 Class3 필드는 디자인 문제를 나타냅니다.
스프레드시트는 종종 세 번째 차원을 사용하지만 테이블은 사용하지 않아야 합니다. 이 문제를 보는 또 다른 방법은 일대다 관계입니다. 한쪽과 여러 측면을 같은 테이블에 두지 마십시오. 대신 다음 예제와 같이 반복 그룹(클래스#)을 제거하여 첫 번째 일반 형식으로 다른 테이블을 만듭니다.
학생# 조언자 Adv-Room 수업# 1022 존스 412 101-07 1022 존스 412 143-01 1022 존스 412 159-02 4123 스미스 216 101-07 4123 스미스 216 143-01 4123 스미스 216 179-04 두 번째 일반 양식: 중복 데이터 제거
위의 표에서 각 Student# 값에 대한 여러 클래스# 값을 확인합니다. 클래스#은 Student#(기본 키)에 기능적으로 종속되지 않으므로 이 관계는 두 번째 일반 형식이 아닙니다.
다음 표에서는 두 번째 일반 형식을 보여 줍니다.
학생:
학생# 조언자 Adv-Room 1022 존스 412 4123 스미스 216 등록:
학생# 수업# 1022 101-07 1022 143-01 1022 159-02 4123 101-07 4123 143-01 4123 179-04 세 번째 일반 양식: 키에 종속되지 않는 데이터 제거
마지막 예제에서 Adv-Room(advisor의 사무실 번호)는 Advisor 특성에 따라 기능적으로 달라집니다. 해결 방법은 아래와 같이 해당 특성을 Students 테이블에서 교직원 테이블로 이동하는 것입니다.
학생:
학생# 조언자 1022 존스 4123 스미스 학부:
이름 방 부서 존스 412 42 스미스 216 42