데이터베이스 정규화 기본 사항 설명

이 문서에서는 초보자를 위한 데이터베이스 정규화 관련 용어에 대해 설명합니다. 관계형 데이터베이스의 디자인에 대해 논의할 때 이러한 용어에 대해 기본적으로 파악하고 있으면 도움이 됩니다.

정규화 설명

정규화는 데이터베이스의 데이터를 구성하는 프로세스입니다. 여기에는 데이터를 보호하고 중복성과 일관성 없는 종속성을 제거하여 데이터베이스를 보다 유연하게 만들기 위해 설계된 규칙에 따라 테이블을 만들고 해당 테이블 간에 관계를 설정하는 것이 포함됩니다.

데이터가 중복되면 디스크 공간이 낭비되며 유지 관리상의 문제가 발생합니다. 여러 위치에 있는 데이터를 변경해야 하는 경우에는 모든 위치에서 데이터를 정확히 동일한 방식으로 변경해야 합니다. 고객 주소 변경은 해당 데이터가 Customers 테이블에만 저장되고 다른 데이터베이스에 저장되지 않은 경우 구현하기 쉽습니다.

그렇다면 "일치하지 않는 종속성"이란 무엇일까요? 사용자가 Customers 테이블에서 특정 고객의 주소를 확인하는 것은 직관적이지만 해당 고객을 호출하는 직원의 급여를 찾는 것은 의미가 없을 수 있습니다. 직원의 급여는 직원에 관련/종속되므로 Employees 테이블로 이동해야 합니다. 일치하지 않는 종속성이 있는 경우 데이터를 찾을 수 있는 경로가 없거나 끊겨 있을 수 있으므로 데이터를 찾기가 어려울 수 있습니다.

데이터베이스 정규화에는 몇 가지 규칙이 적용됩니다. 각 규칙을 "일반 양식"이라고 합니다. 첫 번째 규칙이 관찰되면 데이터베이스는 "첫 번째 일반 형식"이라고 합니다. 처음 세 규칙을 관찰하는 경우 데이터베이스는 "세 번째 일반 형식"으로 간주됩니다. 다른 수준의 정규화가 가능하지만, 세 번째 정규식은 대부분의 애플리케이션에 필요한 가장 높은 수준으로 간주됩니다.

많은 공식 규칙 및 사양과 마찬가지로 실제 시나리오에서 항상 완벽한 규정 준수를 허용하지는 않습니다. 일반적으로는 정규화를 수행하려면 테이블이 추가로 필요한데, 이러한 테이블 추가 작업을 번거로워하는 고객도 있습니다. 정규화의 처음 3개 규칙 중 하나를 위반해야 할 때는 중복 데이터, 일치하지 않는 종속성 등 응용 프로그램에서 발생 가능한 문제를 예측해야 합니다.

아래 설명에 관련 예제가 포함되어 있습니다.

첫 번째 정규 형식

  • 개별 테이블에서 반복되는 그룹을 제거합니다.
  • 각 관련 데이터 집합에 대해 별도의 테이블을 만듭니다.
  • 기본 키를 사용하여 각 관련 데이터 집합을 식별합니다.

단일 테이블에 여러 필드를 사용하여 유사한 데이터를 저장하지 마세요. 예를 들어 가능한 두 원본에서 제공되었을 수 있는 인벤토리 항목을 추적하려는 경우 인벤토리 레코드에 공급업체 코드 1 및 공급업체 코드 2 필드를 포함할 수 있습니다.

이때 세 번째 공급업체를 초과하면 어떻게 될까요? 필드를 추가하는 것은 답이 아닙니다. 프로그램 및 테이블 수정이 필요하며 동적 공급 업체를 원활하게 수용하지 않습니다. 대신 모든 공급업체 정보를 별도의 Vendors 테이블에 저장하고 항목 번호 키를 사용하여 인벤토리를 공급업체에 연결하거나 공급업체 코드 키를 사용하여 공급업체를 인벤토리에 연결합니다.

두 번째 정규 형식

  • 여러 레코드에 적용되는 값 집합에 대해 별도의 테이블을 만듭니다.
  • 외래 키를 사용하여 이러한 테이블 간의 관계를 설정합니다.

레코드는 테이블의 기본 키(필요한 경우 복합 키) 이외의 항목에 의존해서는 안 됩니다. 회계 시스템의 고객 주소를 예로 들어 보겠습니다. 이 주소는 Customers 테이블뿐 아니라 Orders, Shipping, Invoices, Accounts Receivable, Collections 테이블에도 필요합니다. 이 경우 고객 주소를 이러한 각 테이블에 별도의 항목으로 저장하는 대신 한 곳(Customers 테이블 또는 별도의 Addresses 테이블)에 저장합니다.

세 번째 정규 형식

  • 키에 의존하지 않는 필드를 제거합니다.

해당 레코드의 키에 속하지 않는 레코드의 값은 테이블에 속하지 않습니다. 일반적으로는 필드 그룹의 내용이 테이블의 단일 레코드에 적용될 수 있는 경우 항상 해당 필드를 별도의 테이블에 배치하는 것이 좋습니다.

예를 들어 Employee Recruitment 테이블에 입사 지원자의 대학 이름과 주소가 포함되어 있을 수 있습니다. 하지만 그룹에 메일을 보내려면 전체 대학 목록이 필요합니다. 대학 정보가 Candidates 테이블에 저장되어 있는 경우 현재 입사 지원자를 포함하지 않고 대학 목록만 생성할 수 있는 방법은 없습니다. 이 경우에는 별도의 Universities 테이블을 만든 후 대학 코드 키를 사용하여 Candidates 테이블과 연결합니다.

예외: 이론적으로는 바람직하지만 세 번째 일반 형식을 준수하는 것이 항상 실용적인 것은 아닙니다. 예를 들어 Customers 테이블에서 발생 가능한 모든 필드 간 종속성을 제거하려는 경우에는 도시, 우편 번호, 영업 사원, 고객 등급 및 여러 레코드에서 중복될 수 있는 기타 모든 요소에 대해 별도의 테이블을 만들어야 합니다. 이론적으로 정규화는 추구할 가치가 있습니다. 그러나 대부분의 작은 테이블에서는 정규화를 수행하면 성능이 저하되거나 열린 파일 및 메모리 용량이 초과될 수 있습니다.

자주 변경되는 데이터에만 세 번째 정규 형식을 적용하는 것이 보다 적절할 수 있습니다. 일부 종속 필드가 남아 있는 경우 변경되는 필드가 있으면 사용자가 모든 관련 필드를 확인해야 하도록 응용 프로그램을 디자인하세요.

기타 정규화 형식

BCNF(Boyce-Codd Normal Form)라고도 하는 네 번째 정규 양식과 다섯 번째 정규 양식은 존재하지만 실용적인 디자인에서는 거의 고려되지 않습니다. 이러한 규칙을 무시하면 데이터베이스 디자인이 완벽하지 않을 수 있지만 기능에는 영향을 주지 않아야 합니다.

예제 테이블 정규화

아래 단계에서는 가상의 학생 테이블을 정규화하는 프로세스를 보여 줍니다.

  1. 정규화되지 않은 테이블:

    Student# Advisor Adv-Room Class1 Class2 Class3
    1022 Jones 412 101-07 143-01 159-02
    4123 Smith 216 101-07 143-01 179-04
  2. 첫 번째 일반 양식: 반복 그룹 없음

    테이블에는 차원이 두 개만 있어야 합니다. 한 학생의 강의가 여러 개이므로 이러한 강의를 별도의 테이블에 나열해야 합니다. 위 레코드의 Class1, Class2, Class3 필드로 인해 디자인상의 문제가 발생하게 됩니다.

    스프레드시트는 종종 세 번째 차원을 사용하지만 테이블은 사용하지 않아야 합니다. 이 문제를 보는 또 다른 방법은 일 대 다 관계입니다, 같은 테이블에 한쪽과 많은 측면을 넣어하지 마십시오. 대신 다음 예제와 같이 반복 그룹(클래스#)을 제거하여 첫 번째 일반 형식으로 다른 테이블을 만듭니다.

    Student# Advisor Adv-Room Class#
    1022 Jones 412 101-07
    1022 Jones 412 143-01
    1022 Jones 412 159-02
    4123 Smith 216 101-07
    4123 Smith 216 143-01
    4123 Smith 216 179-04
  3. 두 번째 일반 양식: 중복 데이터 제거

    위의 표에서 각 Student# 값에 대한 여러 클래스# 값을 확인합니다. 클래스#은 Student#(기본 키)에 기능적으로 종속되지 않으므로 이 관계는 두 번째 일반 형식이 아닙니다.

    다음 테이블은 두 번째 정규 형식을 보여 줍니다.

    Students:

    Student# Advisor Adv-Room
    1022 Jones 412
    4123 Smith 216

    Registration:

    Student# Class#
    1022 101-07
    1022 143-01
    1022 159-02
    4123 101-07
    4123 143-01
    4123 179-04
  4. 세 번째 정규 형식: 키에 의존하지 않는 데이터 제거

    마지막 예제에서는 Adv-Room(상담 교사의 사무실 번호)이 Advisor 특성에 기능적으로 종속됩니다. 따라서 아래에 나와 있는 것처럼 해당 특성을 Students 테이블에서 Faculty 테이블로 이동해야 합니다.

    Students:

    Student# Advisor
    1022 Jones
    4123 Smith

    Faculty:

    이름 Room Dept
    Jones 412 42
    Smith 216 42