데이터베이스 설계 | 12. 데이터베이스 설계

1. 데이터베이스 설계 정의

사용자의 요구사항(Requirements)으로부터 현실 세계를 반영한 데이터베이스 구조를 도출해내는 과정
어떠한 필드로 구성된 테이블을 어떠한 물리적 형태의 데이터베이스로 구성할 것인가를 결정

2. 데이터베이스설계단계

데이터베이스 생명 주기
- 요구사항 분석 : DB 사용 환경 분석 후 대상 및 제한 조건 도출
- 개념적 설계 : 분석 결과를 추상화된 표현 방식으로 기술, DBMS에 독립적, 개념적 스키마 생성(ex. E-R 다이어그램)
- 논리적 설계 : 목표 DBMS 구조에 맞는 스키마 생성, 논리적 스키마 생성(ex. Relation(Table))
- 물리적 설계 : 목표 DBMS에 맞게 실제 컴퓨터에 저장되는 방식 설계, 물리적 스키마 생성
- 구현 : 목표 DBMS의 SQL(DDL)로 데이터베이스 생성, 트랜잭션 작성
데이터베이스 설계 시 고려사항
- 충실성 : 필요로 하는 모든 데이터 표현
- 단순성 : 단순하고 이해하기 쉬운 구조로 표현
- 중복의 최소화 : 저장 공간의 효율적 사용, 데이터 일관성 유지
- 제약조건의 표현 : 데이터가 갖추어야 할 조건을 표현

3. 개념적 설계

E-R Model : 개념 설계 단계에서 사용, 관계형 스키마로 매핑할 수 있다

4. 논리적 설계 : E-R to Relational

Relationship sets to Relations
- 관계 집합을 관계로 변환할 때 관계의 속성은 반드시 포함되어야 한다
- 각 참여 엔터티 집합에 대한 키(외래 키)
- 각각의 기본키를 가져오고 자기 속성을 가져오는 것이 보편적 방법
- 카디날리티 비율은 두 개의 엔티티 타입 간 관계에서 참여자의 수를 의미
- 1 : 1
  - 방법 1 : E1의 기본 키를 E2의 외래 키로 추가(효율적)
  - 방법 2 : E2의 기본 키를 E1의 외래 키로 추가
  - 방법 3 : 관계를 별도의 릴레이션으로 만드는 것 ⇒ 필요 이상으로 릴레이션 수를 늘려서 조인으로 인한 연산의 양이 많아져서 비효율적
  - 방법 4 : 하나의 릴레이션으로 만드는 것 ⇒ E1과 E2 모두 전체 참여일 때 가장 효율적(후보 키 : PK1, PK2/기본 키 : PK1)
  - 한 쪽은 전체 참여, 다른 쪽은 부분 참여할 경 우⇒ 전체 참여하는 릴레이션에 다른 릴레이션의 기본 키를 외래 키로 포함하는 것이 효율적(방법 1)
- 1 : M
  - 방법 1 : 관계가 M인 방향의 릴레이션에 관계가 1인 방향 릴레이션의 기본 키를 외래 키로 추가(효율적)
  - 방법 2 : 관계가 1인 방향의 릴레이션에 관계가 M인 방향 릴레이션의 기본 키를 외래 키로 추가 ⇒ M만큼 정보 중복
  - 방법 3 : 별도의 릴레이션을 만드는 것 ⇒ 릴레이션 수를 늘려서 조인이 많아져 비효율적
- N : M
  - 1 : M에서 관계가 1쪽인 릴레이션에 관계가 M쪽인 릴레이션의 기본 키를 외래 키로 두면 많은 중복 발생 ⇒ N : M인 경우 양방향으로 1 : M이므로 관계를 별도의 릴레이션으로 설계하는 것이 가장 효율적

5. 논리적 설계 : 제약 조건

전체 참여 제약 조건(굵은 선) ⇒ SQL에서 NOT NULL로 표현
Weak Entity Sets in SQL : 오너 개체의 기본 키와 약한 개체의 부분 키가 기본 키
- 오너 개체가 삭제될 때 약한 개체도 삭제되게 하려면 : ON DELETE CASCADE\
IS-A Hierarchies to Relations
- 방법 1 : 상위 클래스의 기본 키를 외래 키가 아닌 기본 키로 추가(유일하게 구별하는 속성이기 때문) : IS-A Hierarchies를 3개의 릴레이션으로 설계할 때 서브 클래스에 반드시 상위 클래스의 기본 키 추가
- 릴레이션이 참조하는 것이 삭제되면 ⇒ 연쇄 삭제(CASCADE)
- 장점 : 최소화된 중복성
- 단점 : 릴레이션과 조인 필요
방법 2 : 속성을 두 릴레이션에 중복해서 포함, 두 개의 서브 클래스 중 하나에 속해야 함
- 장점 : 조인 불필요
- 단점 : 속성이 중복됨