[Database Modeling] 정규화

DaeHoon·2023년 7월 28일
0

Database Modeling

목록 보기
4/5

Anomaly (데이터베이스 이상 현상)

  • 데이터의 이상 현상
  • 중복때문에 anomaly가 발생 (의도하지 않은 이상 현상 발생 가능)​
  • Update, Delete, Insert에서 발생할 수 있음

Update Anomaly

  • 홍길동을 2루수로 바꿀 때, 일부 홍길동이 바뀌지 않는 현상이 있을 수 있다.
    • 이유는 홍길동이 중복으로 나타나기 때문이다.
  • 홍길동을 찾는 조건에서 팀번호가 관여했다면 다른 팀에 소속된 홍길동은 값이 바뀌지 않을 수 있다.
  • 정규화가 되면 홍길동이 중복으로 나타날 수 없다.
  • 즉, 홍길동의 속성인 포지션을 한번만 바꾸면 전체가 업데이트되는 것이나 마찬가지인 효과가 난다.

Delete Anomaly

  • 김길동을 삭제할 때 의도하지 않은 타이거스, 엘리펀츠 팀 정보가 사라질 수 있다. 타이거스, 엘리펀츠는 해당 테이블에 유일한 팀 정보이기 때문이다.
  • 정규화가 되면 김길동만 사라지고, 팀 정보는 그대로 유지할 수 있다.

Insert Anomaly

  • 장길동이라는 새로운 선수를 동록하려 할 때 팀이 결정되지 않았다면 입력할 수 없는 문제가 발생한다.
  • 선수는 존재하는데 입력할 수 없는 이상 현상이 발생한 것이다.
  • 다른 데이터가 존재하지 않아 원하는 데이터를 입력할 수 없는 것이 삽입 이상 현상이다.

Anomaly를 해결하는 방법?

정규화!

제1 정규화

  • 모든 속성은 반드시 하나의 값을 가져야 한다.
  • 값이라는 것은 원자성(ATOM)을 가져야 한다. 즉 더 이상 쪼갤 수 없는 하나의 값만을 가져야 한다.
    • 다가 속성
    • 복합 속성

1정규화 대상

  • 다가 속성이 사용된 릴레이션
  • 복합 속성이 사용된 릴레이션
  • 유사한 속성이 반복된 릴레이션
  • 중첩 릴레이션
  • 동일 속성이 여러 릴레이션에 사용된 경우

1) 다가 속성이 사용된 릴레이션

  • 다가 속성같은 종류의 값을 여러 개 가지는 속성

  • 위의 엔티티는 고객 번호를 알더라도 유일하게 식별할 수 있는 전화번호가 없다. 즉, 전화번호는 주 식별자인 고객번호에 함수적으로 종속되지 않았다.

    • 고객번호->고객명 (함수적 종속)
    • 고객번호-> 주민번호 (함수적 종속)
    • 고객번호-> 전화번호 (함수적 종속 X)
  • 한 속성에는 반드시 하나의 값을 가져야 한다는 1정규형에 어긋나는 릴레이션이다.

  • 한 속성이 하나의값을 가지도록 풀어보면 위와 같은 엔티티를 설계할 수 있다.

  • 이 후, 고객번호, 고객명, 주민번호 중복을 제거하면 위와 같은 엔티티 설계가 가능하다.

2) 복합 속성이 사용된 릴레이션

  • 고객명은 성과 이름으로 구성된 복합 속성이다.

  • 만일 고객의 성 또는 이름을 따로 조회해야 하는 경우가 업무에 효율적이라고 판단된다면 위와 같이 엔티티를 만들 수 있다.

3) 유사한 속성이 반복된 릴레이션

  • 1정규식의 중요한 원칙
    • 모든 속성이 단일 값을 사용해야 한다.
    • 한 릴레이션에서 반복 형태의 속성이 있어서는 안 된다는 것
  • 위의 엔티티에서는 주문번호, 상품번호, 주문수량 반복되는 속성이다.

  • 위와 같이 엔티티를 설계할 수 있음.

제2 정규화

  • 2개 이상으로 구성된 PK에서 발생
  • 모든 비 식별자 속성 (일반 속성)은 후보 식별자 속성에 완전 함수 종속 되어야 한다.

실습

  • 다음 릴레이션의 함수적 종속관계를 분석하고 제 2 정규화를 수행해라
  • 함수적 종속관계
    • 주문번호 -> 상품명
    • 상품번호 -> 상품명
    • 상품번호 -> 단가
    • (주문번호, 상품번호) -> 주문수량
  • 제 2 정규화

제3 정규화

  • 식별자가 아닌 일반 속성 간에는 종속성이 존재하지 않는다
  • 3정규형의 대상이 되는 속성을 이행 종속 속성이라고 함 (A -> B -> C , A -> C)
  • 즉, 일반 속성간의 종속 관계를 분해하는 것
  • 2 정규화와 차이점은 2 정규화는 식별자 집합이 컬럼을 정하는 경우, 3 정규화는 일반 컬럼이 다른 컬럼을 정의하는 경우

실습

  • 이 엔터티에서 고객명은 고객번호에 종속된 관계
  • 일반 속성 간의 종속이 발생했으므로 고객명 속성은 주문 엔터티에서 삭제하고, 고객번호 속성을 주 식별자로 하는 고객 엔터티를 만들고, 고객명 속성을 추가해서 3정규형으로 설계한다.

BC 정규화

  • 릴레이션에 존재하는 종속자는 후보 식별자가 아니어야 한다 (일반 컬럼이 후보 키를 결정하면 안된다.)
  • 위에서 B는 C에 종속되어 있는 종속자인데 후보 식별자이다.

실습

요구사항

  • 교수는 정해진 한 과목만 강의할 수 있다.
  • 여러 교수가 동일한 과목을 강의할 수 없다. 따라서 과목을 알면 교수를 알 수 있다고 가정한다

  • 종속자면서 후보 식별자인 교수번호를 과목이라는 엔티티의 종속자로 넣는다.

역정규화

  • 효율을 위해서 정규화된 결과의 일부를 수정하여 중복을 만든다.
    • 대부분 JOIN 시 발생되는 엄청난 계산량을 해결하기 위해서 사용
    • 참조 무결성은 존재하되 중복은 허용시킨다.
    • 참조되는 테이블이 수정이 되면 역정규화된 테이블도 수정이 되어야 하는대 이 때 프로그래머들이 이 역할을 수행한다.

실습 1

  • 주문 엔티티에서 고객명은 중복속성이며 이는 2정규화를 위반한 것은 아니다.

실습 2

  • 입출금 장부와, 2019년 12월 장부는 1대1 관계

  • 입출금장부에 통계관련 컬럼을 추가하고 중복 데이터를 허용 시켰다.
  • 장부를 확인하기 위해 장부 테이블과 JOIN을 할 필요가 없다.

그러면 언제 역정규화를 고려해야할까?

  • 관계 테이블 설계에서는 반드시 역정규화를 고려하자.
    • 예를 들어 주문의 경우, 회원, 결제, 상품 엔티티 등 다양한 컬럼을 필요로 하는 엔티티다. 이를 다 조인해서 가져오는 거는 비용이 매우 크다.
    • 만약 역정규화로 해결이 안될 시 테이블을 분할해서 모델링을 하자
    • 테이블 분할로 해도 데이터가 너무 많이 쌓였을 경우? Database WareHousing을 통해 빅데이터 기술을 이용해 처리.
profile
평범한 백엔드 개발자

0개의 댓글