데이터베이스 설계 프로세스

요약

데이터베이스 설계 과정을 배운다.

실전 예제로는 패캠 부트캠프 파이널 프로젝트(Sable 함께모으기 서비스) 예시로 한다.

임무 목표와 임무 명세 정의

임무 명세 : 이 데이터베이스의 존재 이유나 목적을 단순한 한 문장으로 정리

임무 목표 : 이 데이터베이스가 수행해야 할 작업을 정리.

이렇게 작성된 목표와 임무 명세는 사용자와 관리자에게 타당해야 한다.
각 임무 목표는 하나의 작업을 너무 디테일하지 않을 정도로 기술한다.

예시

임무 명세 : 함께 모으기 데이터베이스는 Sable의 함께모으기(저축 챌린지)에 필요한 데이터를 관리한다.

임무 1. 챌린지의 정보를 완전히 관리한다.
임무 2. 사용자의 정보를 완전히 관리한다.
임무 3. 챌린지마다 사용자가 작성한 리뷰를 관리한다.
임무 4. 사용자의 계좌를 관리한다.
임무 5. 챌린지의 계좌를 관리한다.

기존 데이터베이스 분석

해당 데이터베이스의 사용자와 관리자의 요구사항을 인터뷰. 기존의 데이터베이스 분석.

인터뷰를 통해 대상과 사건을 특정할 수 있다.
(사용자는 챌린지에 참여해서 규칙에 따라 저축 을 한다.)
여기서 대상은 사용자, 챌린지, 규칙, 저축이다.

대상을 정리했으면, 각 대상에 대한 특징을 찾아낼 수 있다.

이 과정에서 예상되는 필드를 구성할 수 있다.

• 어떤 대상이, 어떤 특징을 가지는 지 분석
• 특정 대상의 특징을 설명하는게 필드다.
• 값 목록(특별한 값의 집합을 나타내는 특성)은 따로 표시한다.
• 계산된 필드는 따로 정리한다.
• 중복된 특성은 하나의 필드로 정리한다.(혹은 여러개로 나눠야 할 특성은 분해한다.)

예시

일단 우리 서비스에 요구사항을 정리해본다.

사용자는 이름, 이메일, 생년월일, 닉네임, 성별, 비밀번호, 하나의 사용자 계좌와 여러 개의 챌린지 계좌를 가진다.
챌린지는 챌린지 호스트, 챌린지 이름, 챌린지 시작일, 챌린지 종료일, 챌린지 내용, 챌린지 주기, 챌린지 목표 금액, 챌린지 성공한 사람들의 리뷰를 가진다.
챌린지는 챌린지 모드와 자유 모드가 있다.
챌린지 모드는 패널티 금액을 가진다.
자유 모드는 패널티 금액이 없다.
챌린지는 정해진 시간 전에 모집을 시작해서 시작일이 되면 모집을 마감한다.
사용자는 각 챌린지에서 자신이 원할 때 원하는 금액을 사용자 계좌에서 빼서 챌린지 계좌에 저축할 수 있다.
각 챌린지 계좌에 사용자가 저금한 내용은 저장된다.
….

이제 대상을 정리해본다. (대상은 사람, 장소, 물건, 사건 등…)

사용자, 챌린지, 호스트, 리뷰, 사용자 계좌, 챌린지 계좌

이제 대상마다 특징을 정리해본다.(계산된 필드와 값 목록 필드를 구분한다.)

특징(필드) : 이메일, 생년월일, 닉네임, 성별, 비밀번호, 사용자 공식 여부, 챌린지 이름, 챌린지 시작일, 챌린지 종료일, 챌린지 내용, 챌린지 주기, 챌린지 목표금액, 챌린지 패널티 금액, 챌린지 공식 여부, 챌린지 모드

값 목록 필드 : 사용자가 가지는 챌린지 계좌들, 챌린지에 참여한 사용자들, 사용자가 한 챌린지에 저금한 내용들, 사용자가 참여한 챌린지들, 사용자가 만든 챌린지들

계산된 필드 : 사용자의 미션 달성율, 사용자의 챌린지 예금 합, 사용자의 챌린지 저축액 / 챌린지 목표 금액, 챌린지의 참여 사용자 합

데이터 구조 생성

1. 예비 필드 목록이 존재하면 이를 기반으로 대상에 할당해본다.(대상을 잘 설명하는 것 같은 필드를 할당)
   • 예비 필드 목록을 검토하는 중 새로운 대상이 필요하면 추가한다.
2. 앞 단계들을 통해 표현할 다양한 대상를 선정하여 테이블들에 할당한다.
   (처음 테이블을 만들면 모든 테이블은 데이터 테이블이 된다.)
   1. 데이터 테이블 : 조직에 중요한 주제를 나타냄
   2. 연결 테이블 : 다대다 관계의 두테이블의 연결 설정
   3. 부분 집합 테이블 : 특정 데이터 테이블과 관계. 특정 주제를 구체적으로 설명.
      부분 집합 테이블은 데이터들이 해당 필드를 모두 사용하지 않은 경우가 많은 경우를 말한다.
      (재고 테이블은 책 테이블과 장비 테이블을 하위 테이블로 만들 수 있다. (이는 서로 1대1 관계를 가진다.))
   4. 검증 테이블 : 데이터 무결성을 제공하는 중요한 테이블
3. 각 테이블의 필드들 할당하고 검토
   • 좋은 필드의 조건을 따르는지 확인
   • 필드들이 단독 값을 저장.
   • 다중 구조나 다중값 필드는 개선
   • 부분 집합 테이블을 구성한다.
4. 각 테이블 키 설정
   • 각 키는 데이터베이스에서 유일하게 식별할 수 있는 값이어야 한다.
     (부분 집합 테이블을 제외하면 동일한 기본키를 가지면 안된다.)
   • 만약 마땅한 키가 없는 경우, 인위적인 키를 만들어줄 수 있다.
5. 데이터베이스 각 필드의 필드 명세 설정
   • 일반적 요소 : 필드 이름, 소속 테이블 등…
   • 물리적 요소 : 데이터 타입, 길이, 문자 지원 등..
   • 논리적 요소 : 키 종류, 유일성, 널 지원, 기본값 등..

좋은 필드의 조건

• 테이블의 대상의 특성을 잘 설명하는 필드가 되도록 한다.
• 필드는 단 하나의 값을 포함한다
• 더 작은 구성요소로 해체 될 수 없다.
• 계산되거나 연결된 값은 포함하지 않는다.
• 전체 데이터베이스에서 해당 필드는 유일하다.(연결되는 필드 외에..)
• 다중 부분 필드는 여러 필드로 나눠준다. (이름 -> 성 , 이름)
• 다중값 필드는 새로운 테이블로 분리해서 사용한다.

예시

예비 필드 목록을 대상에 할당

사용자 - 이메일, 생년월일, 닉네임, 성별, 비밀번호, 사용자 공식 여부

챌린지 - 챌린지 식별아이디, 챌린지 이름, 시작일, 종료일, 내용, 주기, 목표금액, 패널티 금액, 챌린지 공식여부, 챌린지 모드, 챌린지 유효 여부

사용자 계좌 - 계좌 소유자, 계좌 잔고

챌린지 계좌 - 계좌 소유자, 계좌 잔고, 소속 챌린지 아이디

리뷰 - 리뷰 작성자 이메일, 리뷰 내용, 리뷰 작성 날짜, 리뷰의 챌린지 아이디

값 목록 필드는 다른 테이블로 분리하고, 종속되는 주제는 부분 집합 테이블로 만든다

챌린지의 태그는 따로 일대다 관계를 가지는 태그 테이블로 따로 빼서 만들고,

계좌 - 사용자 입출금 계좌 & 챌린지 계좌 구조는 종속되는 주제인 사용자 계좌와 챌린지 계좌를 따로 부분집합 테이블로 만든다.

테이블 관계 연결 및 결정

테이블은 1대1, 1대다, 다대다 관계가 있다.
다만 다대다 관계는 주의해야 한다.

다대다 관계의 문제

다대다 관계로 외래키를 도입하면 그 외래키가 중복 데이터가 많이 발생한다.
그리고 만약 하나만 관계를 맺는 튜플을 삭제하면, 그 관계를 맺는 다른 테이블의 해당 튜플이 삭제될 수 있다.

학생과 수업 테이블이 다대다이고 서로 id을 외래키로 연결한다고 하면,
학생 테이블의 수업id가 중복되는 데이터가 많아진다.
한 학생만 듣는 수업이 있다고 했을 때, 그 학생을 삭제하면 그 수업이 삭제될 수 있다.

1. 테이블 관계와 관계의 특징을 확인
2. 기본 키나 연결 테이블을 통해 각 관계에 있는 테이블 간의 논리적인 연결 설정.
3. 각 테이블에 대한 참여의 유형과 정도를 결정

업무 규칙 정의 및 결정

1. 데이터베이스의 다양한 측면에서 제약사항 확인
2. 업무 규칙 설정
3. 검증 테이블을 정의, 구현

뷰의 정의 및 결정

1. 데이터로 작업하는 다양한 방법을 확인 (상세 정보 조회, 요약 조회 등..)
2. 적당한 테이블과 필드를 활용해서 뷰를 정의(뷰의 표준을 정할 수 있음.)

데이터 무결성 재확인

1. 설계된 테이블이 잘 설계된 테이블인지 확인
2. 필드가 적절한 구조인지 확인
3. 테이블 수준 무결성 확인
4. 필드 명세 점검, 무결성 점검
5. 관계 유효성 점검, 각 테이블 참여 특징 명확히 결정.
6. 데이터베이스의 다양한 측면에 있는 제약사항 결정