정규화

2022. 4. 30. 09:00Cloud Native/Database

    목차
반응형

정규화란?

불필요한 속성의 제거 및 변경

Entity의 추가

 

정규화 이유

중복 제거

단순화

정상적인 관계 확보

 

정규화 종류

1) 제 1 정규화

모든 속성은 반드시 하나의 값을 가짐 -> 중복되지 않음

 

2) 제 2 정규화

모든 속성은 UID에 종속

 

 

제 1 정규화

'주문' table

	주문
		# 주문번호
		# 항목번호
		* 고객명
		담당사원명
		...
		선적유무

 

records들

	주문번호,   항번,  고객명, ... 선적유무, ...
	45          1      A            Y ...
	45          2      A            Y
	45          3      A
	...

주문번호와 항번의 조합은 unique

고객명, 담당사원 등은 중복

 

위와 같은 entity 설계는 데이터의 '중복'을 발생

이런 중복을 지양해야 함

 

중복의 문제

 - 공간의 낭비

 - 중복된 연산

 

중복의 발생은 하나의 record에 다 모여 있기 때문이므로, 이를 분리해야 함

 

ex. 
주문공통 entity 생성
#* 주문번호
   고객명
   주문번호
   담당사원명
   선적일자
   주문합계금액
   지불방법
   선적유무
   
주문 >-------- - - - - - 주문공통

비 관계형 DBMS를 관계형 DBMS로 정규화 한 것

 

사원명, 고객명도 중복될 수 있으니, 
사원 entity, 고객 entity에 연결 (하고 사원번호, 고객번호로 관계)

 

단, 너무 과도한 분리는 복잡도를 높일 수 있으므로 적절한 타협점을 찾아야 한다.

 

table에 column이 많으면,

RDB는 행 지향 DB이므로 row 단위로 데이터를 읽기에, 한개 혹은 두 개의 column에서만 데이터를 확인하고 싶어도 모든 column의 데이터를 다 읽은 후 filtering 하기에 불필요한 연산(및 메모리 등의 자원) 소모가 매우 크게 발생함

 

제 2 정규화

"논리적 정규화"로 reference로 알 수 있는 속성은 제거

 

ex. table에 식별자는 2개의 column (2개의 key)로 식별됨

이 table에는 이 두 개의 키로 식별되는 필드 A와 둘 중 하나의 key로 식별되는 필드 B가 있다.

 

이 경우 필드 B는 이를 식별하는 하나의 key에만 종속 되므로, 위 table에 존재할 경우 중복이 야기된다. 

즉, 이런 필드는 별도의 하나의 해당 키로 식별되는 table로 분리되어야 한다. 

 

-> 즉, 제 2 정규화의 목표도 역시 중복의 제거이다. 

 

제 3 정규화

이행 함수적 종속관계 제거

다른 테이블에에 찾을 수 있는 속성을 제거하는 것

 

 

정규화의 장점

유연한 데이터 구축

데이터의 정확성 향상

성능 향상

 

정규화의 단점

데이터 결합처리(join) 증가

물리적 접근이 복잡

 

반응형

'Cloud Native > Database' 카테고리의 다른 글

ORM (Object Relational Mapping) w/ Pydantic and SQLAlchemy  (0) 2022.05.06
master table, transaction table  (0) 2022.04.30
개념적 모델링, 논리적 모델링  (0) 2022.04.30
PostgreSQL  (0) 2022.01.11
GraphQL  (0) 2022.01.10