• database
  • modeling

E/R 모델 설계 원칙 정리

충실성, 중복 회피, 단순성, 관계 선택, Weak Entity Set까지 E/R 설계에서 지켜야 할 원칙을 예시와 함께 정리한다.

Manx3분 읽기
시리즈 · Database1 / 8
  1. E/R 모델 설계 원칙 정리
  2. 데이터베이스 키의 종류와 UNIQUE 제약
  3. 인덱스와 B-Tree, 그리고 스캔 방식
  4. JOIN의 종류와 구현 방식
  5. 트랜잭션의 ACID와 DBMS의 복구 전략: UNDO, REDO, WAL
  6. 데이터베이스 Lock: 공유 락·배타 락, 낙관적 락·비관적 락
  7. DB 클러스터링, 레플리케이션, 샤딩과 분산 트랜잭션
  8. PostgreSQL Vacuum 이해와 AutoVacuum 튜닝

좋은 데이터베이스 설계를 위해 지켜야 할 원칙을 「A First Course in Database Systems」의 영화 데이터베이스 예시로 정리한다.

Faithfulness

설계는 표현하려는 현실에 충실해야 한다. 속성(attribute)과 관계 집합(relationship set)은 실제로 연관이 있는 것만 둔다.

  • Stars(number-of-cylinders): 배우와 엔진 실린더 수는 관련이 없다.
  • Automobiles(number-of-cylinders): 자동차와 엔진은 실제로 연관이 있다.

Avoiding Redundancy

모든 것은 한 번만 표현한다. 아래 그림에서는 Movies의 StudioName과 Studios의 name이 같은 정보를 중복으로 담고 있다.

Movies가 Owns 관계로 Studios와 연결되어 있는데도 StudioName 속성을 중복으로 가진 E/R 다이어그램

중복은 저장 공간을 낭비하고, 수정할 때 한쪽만 바꾸는 실수로 데이터가 어긋날 수 있다.

Simplicity Counts

꼭 필요하지 않은 요소를 추가해 설계를 복잡하게 만들지 않는다. 아래의 Holdings는 Movies와 Studios 사이에 끼어 있을 뿐 아무 정보도 더하지 않는 불필요한 엔티티다.

Movies와 Studios 사이의 불필요한 Holdings 엔티티를 제거하고 Owns 관계 하나로 단순화한 다이어그램

Choosing the Right Relationships

엔티티 집합은 여러 경로로 연결될 수 있지만, 가능한 모든 관계를 다 추가하는 것은 좋지 않다. 중복이 생기고, 공간이 낭비되며, 알아보기도 힘들어진다.

Movies, Stars, Studios가 Stars-in, Owns, Works-for 관계로 삼각형을 이루는 다이어그램

Star가 Movie에 출연하고 그 Movie를 Studio가 소유한다면, Star와 Studio의 관계는 이미 유도할 수 있으므로 Works-for는 중복이다. 반면 영화에 출연하지 않는 Star까지 표현해야 한다면 중복이 아니다. 관계가 원을 이루면 중복일 가능성이 높으니 의심해 봐야 한다.

Weak Entity Sets

Weak entity set은 자신의 속성만으로는 key를 구성할 수 없는 엔티티 집합이다(↔ strong entity set).

  • key의 일부를 다른 엔티티 집합에 의존하며, 이 대상을 identifying entity set(식별 개체 집합)이라고 한다.
  • identifying entity set과 weak entity set은 일대다 관계다.
  • weak entity set 안에서 그나마 개체를 구분해 주는 속성을 discriminator라고 한다.

Weak entity set인 Crews가 Unit-of 관계로 Studios에 연결된 다이어그램

Crews의 primary key는 자신의 number와 Studios의 name을 합친 (number, studioName)이다.

참고