정규화 설명

완료됨

데이터베이스 정규화는 데이터베이스 내에서 데이터를 테이블과 열로 구성하는 데 사용되는 디자인 프로세스입니다. 각 표에는 특정 엔터티와 관련된 데이터가 포함되어야 하며 해당 엔터티를 지원하는 정보만 포함해야 합니다. 정규화의 주요 목적은 데이터베이스 내 중복 데이터를 최소화하여 삽입 및 업데이트 중에 성능 저하를 방지하는 것입니다. 예를 들어, 고객의 주소를 업데이트해야 하는 경우 주소가 Customers 테이블과 같이 단일 위치에 저장되어 있으면 변경 내용을 구현하기가 더 단순합니다.

가장 일반적인 정규화 형태는 첫 번째, 두 번째, 세 번째 기본형 형태입니다.

첫 번째 기본형

첫 번째 기본형은 다음과 같은 특징이 있습니다.

• 각 관련 데이터 세트에 대한 별도의 테이블 만들기
• 개별 테이블의반복 그룹 제거
• 기본 키를 사용하여 각 관련 데이터 세트 식별

이 모델에서는 유사한 데이터를 저장하기 위해 단일 테이블에 여러 열을 사용하는 것은 피해야 합니다. 예를 들어, 제품이 여러 색으로 나올 수 있는 경우에는 다른 색 값을 포함하는 단일 행에 여러 열이 있어서는 안 됩니다. 첫 번째 다음 표 ProductColors는 색에 대한 반복되는 값을 가지므로 첫 번째 기본형이 아닙니다. 한 색만 있는 제품의 경우 공간이 낭비됩니다. 또한 제품이 세 가지 이상의 색으로 제공되는 경우 최대 열 개수를 설정하는 것은 비현실적입니다. 대신 두 번째 테이블 ProductColor에 표시된 대로 테이블을 다시 만들 수 있습니다.

첫 번째 기본형은 테이블에 대한 고유 키가 있어야 한다는 것을 요구합니다. 고유 키란 각 행을 고유하게 식별하는 값을 갖는 열입니다. 두 번째 표에서는 두 열 모두 그 자체로는 고유하지 않지만 ProductID와 Color를 조합하면 고유 키를 형성합니다. 고유 키를 만들기 위해 여러 열이 필요한 경우 이를 복합 키라고 합니다.

• ProductColors 테이블:

  ProductID	Color1	Color2	Color3
  1	빨강	녹색	황색
  2	황색
  3	파랑	빨강
  4	파랑
  5	빨강

• ProductColor 테이블:

  ProductID	색상
  1	빨강
  1	녹색
  1	황색
  2	황색
  3	파랑
  3	빨강
  4	파랑
  5	빨강

세 번째 테이블인 ProductInfo는 각 행이 특정 제품을 참조하고, 반복 그룹이 없고, 기본 키로 사용할 ProductID 열이 있기 때문에 첫 번째 기본형으로 되어 있습니다.

ProductID	ProductName	가격	ProductionCountry	ShortLocation
1	위젯	15.95	미국	미국
2	Foop	41.95	영국	영국
3	Glombit	49.95	영국	영국
4	Sorfin	99.99	필리핀	RepPhil
5	스템 볼트	29.95	미국	미국

두 번째 기본형

두 번째 기본형에는 첫 번째 기본형에서 요구하는 것 외에도 다음과 같은 특징이 있습니다.

• 테이블에 복합 키가 있는 경우 모든 특성은 그 일부가 아니라 전체 키에 종속되어야 합니다.

두 번째 기본형은 복합 키가 있는 테이블(예: 두 번째 테이블인 ProductColor 테이블)에만 적용됩니다. ProductColor 테이블에 제품 가격도 포함되어 있는 경우를 생각해 보세요. 이 테이블에는 ProductID와 Color에 복합 키가 있는데, 두 열 값을 모두 사용해야만 행을 고유하게 식별할 수 있기 때문입니다. 제품의 가격이 색에 따라 변경되지 않는 경우 다음 테이블에 표시된 것처럼 데이터가 표시될 수 있습니다.

ProductID	색상	가격
1	빨강	15.95
1	녹색	15.95
1	황색	15.95
2	황색	41.95
3	파랑	49.95
3	빨강	49.95
4	파랑	99.95
5	빨강	29.95

이 표는 두 번째 기본형이 아닙니다. 가격 값은 ProductID에 따라 달라지지만 Color에는 따라 달라지지 않습니다. ProductID 1에 대한 행이 3개이므로 해당 제품의 가격이 3번 반복됩니다. 두 번째 기본형을 위반하는 문제는 가격을 업데이트해야 하는 경우 모든 곳에서 업데이트되도록 해야 한다는 것입니다. 첫 번째 행의 가격은 업데이트하지만 두 번째나 세 번째 행의 가격은 업데이트하지 않으면 업데이트 변칙이 발생합니다. 업데이트 후에는 ProductID 1의 실제 가격을 확인할 수 없습니다. 솔루션은 Price 열을 ProductID가 단일 열 키로 있는 테이블로 이동하는 것입니다. 이는 Price가 종속된 유일한 열이기 때문입니다. 예를 들어, Price를 저장하기 위해 표 3을 사용할 수 있습니다.

제품의 가격이 색상에 따라 달라지는 경우 네 번째 테이블은 두 번째 기본형에 속합니다. 가격이 키의 ProductID와 Color 부분에 따라 달라지기 때문입니다.

세 번째 기본형

세 번째 기본형은 일반적으로 대부분의 OLTP 데이터베이스를 대상으로 합니다. 세 번째 기본형은 두 번째 기본형에서 요구하는 것 외에 다음과 같은 특징이 있습니다.

• 모든 키가 아닌 열은 기본 키에 비전이적으로 종속됩니다.

전이적 관계는 테이블의 한 열이 두 번째 열을 통해 다른 열과 관련됨을 의미합니다. 종속성이란 이 관계의 결과로 한 열이 다른 열로부터 값을 파생할 수 있음을 의미합니다. 예를 들어 나이는 생년월일에 따라 결정할 수 있으며, 이때 나이는 생년월일에 종속됩니다. 세 번째 표 ProductInfo를 다시 참조하세요. 이 테이블은 두 번째 기본형에 속하지만 세 번째에는 속하지 않습니다. ShortLocation 열은 키가 아닌 ProductionCountry 열에 종속됩니다. 두 번째 기본형과 마찬가지로 세 번째 기본형을 위반하면 업데이트 이상이 발생할 수 있습니다. ShortLocation을 해당 위치가 있는 모든 행에서 업데이트하지 않고 한 행에서 업데이트한 경우 결국 데이터 불일치가 발생합니다. 이 문제를 방지하기 위해 별도의 테이블을 만들어 국가/지역 이름과 각각의 축약형을 저장할 수 있습니다.

비정규화

이론적으로는 세 번째 기본형이 필요하지만 데이터에 따라 이를 구현하지 못하는 경우도 있습니다. 또한 정규화된 데이터베이스가 항상 최상의 성능을 제공하지는 않습니다. 단일 쿼리로 반환되는 필요 데이터를 모두 가져오려면 정규화된 데이터에 여러 번의 조인 작업이 필요합니다. 쿼리 결과를 반환하는 데 필요한 조인 횟수로 인해 CPU 사용률이 높은 데이터 정규화와 조인이 적고 CPU가 덜 필요하지만 업데이트 이상이 발생할 수 있는 데이터 비정규화 간에는 장단점이 있습니다.

비정규화된 데이터를 쿼리하는 것이 더 효율적일 수 있습니다. 데이터 웨어하우스와 같이 읽기가 많이 이루어지는 워크로드인 경우에 특히 그렇습니다. 이러한 경우 추가 열이 있으면 더 나은 쿼리 패턴 및/또는 보다 단순한 쿼리를 제공할 수 있습니다.

별모양 스키마

대부분의 정규화는 OLTP 워크로드를 대상으로 하지만 데이터 웨어하우스에는 일반적으로 비정규화된 모델인 자체 모델링 구조체가 있습니다. 이 디자인은 판매와 같은 특정 이벤트에 대한 측정값이나 메트릭을 기록하기 위해 팩트 테이블을 사용하고 이를 차원 테이블과 조인합니다. 차원 테이블은 행 개수가 더 적지만 팩트 데이터를 설명하기 위해 많은 수의 열이 있을 수 있습니다. 차원의 예로는 인벤토리, 시간, 지역 등이 있습니다. 이 디자인 패턴을 사용하면 데이터베이스 쿼리가 더 쉬워지고 읽기 워크로드의 성능이 향상됩니다.

이 이미지는 날짜, 통화, 제품에 대한 차원과 FactResellerSales 팩트 테이블이 포함된 별모양 스키마의 예를 보여 줍니다. 팩트 테이블에는 판매 트랜잭션과 관련된 데이터가 포함되어 있는 반면, 차원에는 판매 데이터의 특정 요소와 관련된 데이터만 포함됩니다. 예를 들어, FactResellerSales 테이블에는 판매된 제품을 나타내는 ProductKey만 포함되어 있습니다. 각 제품에 대한 모든 세부 정보는 DimProduct 테이블에 저장되며 ProductKey 열을 사용하여 팩트 테이블과 다시 관련됩니다.

별모양 스키마 디자인과 관계를 이루는 눈송이 스키마는 단일 비즈니스 엔터티에 보다 정규화된 테이블 집합을 사용합니다. 다음 이미지는 눈송이 스키마의 단일 차원의 예를 보여 줍니다. 제품 차원은 정규화되어 DimProductCategory, DimProductSubcategory, DimProduct의 세 테이블에 저장됩니다.

별모양 스키마와 눈송이 스키마의 주요 차이점은 눈송이 스키마의 경우, 중복도를 줄여 스토리지 공간을 줄일 수 있도록 차원이 정규화된다는 것입니다. 단점은 쿼리에 더 많은 조인을 필요로 하므로 복잡성이 증가하고 성능이 저하될 수 있다는 것입니다.