CS(Computer Science)

[스터디] 데이터베이스의 정규화

🐱‍👤지식닌자 2023. 4. 18. 16:21
728x90
데이터베이스의 정규화는 관계형 데이터 모델에서 중복을 최소화하고 데이터의 일관성을 유지하기 위한 과정이다.

 

중복된 데이터가 많을수록 데이터를 변경할 때 일일히 수정해야 하기 때문에 매우 번거롭다.

또한 변경 작업 중 일부 데이터만 수정하거나 데이터 일관성을 깨뜨리는 등의 문제가 발생할 수 있다.

 

중복된 데이터로 인해 데이터베이스에 대한 접근 시간이 길어지는 등 데이터베이스의 성능이 저하될 수 있다.

데이터베이스의 정규화는 1차~5차까지 있으며, 각 단계는 다음과 같다.

 

1번째

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

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

이때 세 번째 공급업체를 초과하면 어떻게 될까요? 단순히 필드를 추가해서는 안 되며, 프로그램 및 테이블을 수정해야 합니다. 공급업체 수를 동적으로 설정하기는 어렵기 때문입니다. 대신 모든 공급업체 정보를 별도의 Vendors 테이블에 저장하고 항목 번호 키를 사용하여 인벤토리를 공급업체에 연결하거나 공급업체 코드 키를 사용하여 공급업체를 인벤토리에 연결합니다.

 

2번째

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

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

 

3번째

  • 키에 종속되지 않는 필드를 제거합니다.

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

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

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

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

 

BCNF(Boyce-Codd Normal Form)

모든 결정자가 후보키 집합에 속해야 한다.

후보키 집합에 없는 칼럼이 결정자가 되어서는 안 된다.

 

기타

네 번째 정규화 형식과 다섯 번째 정규화 형식은 있기는 하지만, 실제 디자인에서 고려되는 경우는 거의 없습니다. 이러한 규칙을 무시하는 경우 데이터베이스 디자인이 완벽하지는 않을 수 있지만 기능적으로는 아무런 영향이 없습니다.

 

e.g.

- 정규화 되지 않은 테이블:

- 정규화 후:

참고: https://learn.microsoft.com/ko-kr/office/troubleshoot/access/database-normalization-description

728x90