TodoList DB 설계

sally·2022년 4월 4일

db 스키마

DB

목록 보기

1/1

마스터즈 프로젝트 시작으로 내가 있는 BE와 안드로이드와의 협업이 시작 되었다.

생각보다 재밌겠다는 생각이 들지만, BE로서 같은 클래스 팀원과 DB 테이블 설계를 잠시 얘기 나눴었는데, 곰곰이 생각해보니, 테이블 설계 방향에 따라 서버단의 로직도 영향이 클 것이 예상됐다.

좀더 설계연습을 해봐야 겠다는 생각이 들었고, 시작한지 얼마 안 된, 데이터베이스 개론에서 데이터베이스 설계 부분을 좀 앞당겨 공부하고 적용해 봐야 겠다는 생각이 들었다.

한빛아카데이의 데이터베이스 개론을 참고하여 작성하였습니다.

관계 데이터 모델 기반으로 데이터베이스 설계시 2가지 방법

E-R 모델과 릴레이션 변환 규칙 이용한 데이터베이스 설계
정규화를 이용한 데이터베이스 설계

1. E-R 모델과 릴레이션 변환 규칙 이용한 데이터베이스 설계

데이터 베이스 설계 과정

요구 사항 분석
요구사항 명세서

개념적 설계
DBMS에 독립적
개념적 스키마 : E-R 다이어그램

논리적 설계
DBMS 처리
논리적 스키마 : 릴레이션 스키마

물리적 설계

구현
데이터베이스 생성

1. 요구 사항 분석

사용자들의 요구 사항 수집, 분석하여 개발할 데이터베이스의 용도 파악 목적
요구사항 명세서 작성 ➜ 설계 단계 기초자료로 활용

2. 개념석 설계

개념적 모델링
- 요구 사항 분석 단계의 결과물을 개념적 데이터 모델을 이용하여 표현
개념적 구조 or 개념적 스키마
- E-R 다이어그램과 같이 개념적 데이터 모델로 표현된 개념적 설계의 결과물

(1) 개체와 속성 추출

기본적 방법
- 업무 처리와 관련 깊은 의미 있는 명사 찾기
- 찾아낸 명사를 개체,속성으로 정확히 분류 작업 필요
E-R 다이어그램
- 개체 : 사각형
- 속성 : 타원형
- 키 속성 : 밑줄
ex
- 카드 변경 정보는 카드 등록과 변경해야 생기는 정보
  - 카드 개체에 항상 속해있는 속성으로 보기는 어렵다
  - 추출할 특정 관계의 속성으로 판단 가능성이 높으니 개체에 속하지 않는 속성으로 분류

(2) 관계 추출

관계 : 개체간의 의미있는 연관성
동사
매핑 카디널리티 : 각 개체 인스턴스가 관계 맺은 상대 개체의 개체 인스턴스 개수 의미
- 분류 - 1:1, 1:n, n:m
참여 특성 : 개체가 관계가 필수적 참여하는지, 선택적으로 참여하는지 의미

ex
- 회원은 여러 카드를 등록할 수 있고, 하나의 카드는 한 명의 회원만 등록 할 수 있다.
  - 등록 할 수 있다. - 회원 개체와 카드 개체가 맺는 등록 관계
  - 회원 개체와 카드 개체의 등록 관계는 1:n
  - 회원이 등록하지 않은 카드는 있을 수 없다.
    - 카드는 등록 관계에 필수적 참여
- 회원은 카드 등록/변경/삭제에 대한 카드변경이력을 제공받는다.
  - 카드와 카드변경이력은 카드 생성시부터(등록/변경/삭제)시 관계 생긴다.
  - 1:n
  - 필수적 참여

(3) E-R 다이어그램 작성

3. 논리적 설계

DBMS에 적합한 논리적 데이터 모델을 통해 개념적 설계 단계에서 생성한 개념적 스키마를 기반으로 논리적 스키마를 설계한다.
개념적 설계 단계의 결과물 ERD을 관계 모델의 테이블 스키마로 변환하는 작업을 한다.
논리적 모델링 or 데이터 모델링
- ERD를 논리적 데이터 모델로 변환하는 작업
논리적 구조 or 논리적 스키마
- 논리적 데이터 모델로 표현된 논리적 설계의 결과물

(1) 릴레이션 스키마 변환 규칙

5가지

규칙 1. 모든 개체는 릴레이션으로 변환한다.
- ERD 에서
  - 개체의 이름 ➜ 릴레이션의 이름
  - 속성 ➜ 릴레이션의 속성
    - 복합 속성 : 단순속성 ➜ 릴레이션의 속성
  - 키 ➜ 릴레이션의 기본키
규칙 2. 다대다 관계는 릴레이션으로 변환한다.
- ERD의 다대다 관계를 하나의 릴레이션으로 변환한다.
- 규칙1 에 따라 변환 후 릴레이션들의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정한다.
  - 외래키들을 조합하여 관계 릴레이션의 기본키로 지정한다.
  - 한 릴레이션에 있는 속성명들은 모두 달라야 한다.
규칙 3. 일대다 관계는 외래키로 표현한다.
- 1:n 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다.
- 단, (일반 개체 참여와 다르게) 약한 개체가 참여하는 1:n 관계는 2개의 세부 규칙으로 나누어 적용한다.
  - 약한 개체가 참여하는 일대다 관계는 외래키를 포함해서 기본키로 지정한다.
규칙 4. 일대일 관계를 외래키로 표현한다.
- 일대다 관계처럼 릴레이션으로 변환하지 않고 외래키로만 표현한다.
  - 데이터 중복을 피하기 위해 개체가 관계 참여하는 특성에 따라 3개의 세부규칙으로 나누어 적용한다.
- 규칙 4-1. 일반적인 일대일 관계는 외래키를 서로 주고 받는다.
  - 1:1 관계에 참여한 개체에 서로의 기본키를 주고받아 외래키 지정시 불필요한 데이터 중복이 발생한다.
    - 한 쪽 릴레이션에만 포함시켜도 충분하다.
    - 관계에 참여하는 특성을 고려하여 외래키 속성을 포함시킬 릴레이션을 선택할 수 있다. ➜ 규칙 4-2, 4-3 참고
- 규칙 4-2. 일대일 관계에 필수적 참여하는 개체의 릴레이션만 외래키를 받는다.
  - 선택적 참여하는 개체에 해당하는 릴리이션이 외래키를 가지면, 외래키로 지정된 속성에 null 값이 저장되는 경우가 많을 것이다.
- 규칙 4-3. 모든 개체가 일대일 관계에 피수적으로 참여하면 릴레이션 하나로 합친다.
  - 관련성이 있는 개체라는 의미
  - 관계의 이름 ➜ 릴레이션 이름
  - 두 개체 릴레이션의 키 속성 조합 ➜ 기본키
규칙 5. 다중 값 속성은 릴레이션으로 변환한다.
- 관계 데이터 모델의 릴레이션에는 다중 값을 가지는 속성을 허용하지 않는다.
  - ERD에 있는 다중값 속성은 별도의 릴레이션을 만들어 포함시킨다.
    - 기본키는 다중 값 속성과 외래키를 조합하여 지정
기타 고려 사항
- 외래키로만 표현이 가능한 1:1, 1:n 관계는 릴레이션으로 변환하지 않는 것이 좋다.
  - 릴레이션의 개수가 불필요하게 늘어나 DBMS의 부담이 커질 수 있다.
- 개체가 자기 자신과 관계를 맺는 순환 관계도 기본 규칙을 그대로 적용하면 된다.
  - 순환 관계가 n:m ➜ 릴레이션으로 변환
  - 순환 관계가 1:1 or 1:n ➜ 외래키로만 표현