데이터베이스 과제 회고록

데이터베이스 과제를 진행하면서,,
이전에 프로젝트를 진행하며 논리적, 물리적 설계 단계에서 이해하지 않고 쉽게 지나쳤던 부분을 다시 마주치며 과정을 기록으로 남겨보고자 한다.

---

데이터베이스 설계 단계는 보편적으로 다음과 같다.

1. 요구 사항 분석
   2. 개념적 설계
   3. 물리적 설계
2. 논리적 설계
3. 구현

과제 목표는 영화 예매 사이트의 데이터베이스 구축으로 논리적 설계 단계까지만 진행된다.

1. 개념적 설계

요구 사항 분석은 과제의 내용으로 주어졌기 때문에 요구 사항 분석 결과를 가지고 개념적 설계부터 시작하여 설계 진행 순서로 기술한다.

1-1. 엔티티 추출

추상화(Abstraction) 되어있는 정보를 일련의 과정을 거쳐 엔티티 후보 풀과 리스트로 기술한다.

1. 엔터티 후보 풀과 엔터티 리스트를 그린다.
2. 분석 대상 문서를 보고 명사를 찾아 표시한다.
3. 명사 하나하나에 대해 속성(Attribute)인지 엔터티인지를 구분한다.
   여기에서 속성은 개체나 관계가 가지고 있는 고유의 특성으로 의미있는 데이터의 가장 작은 논리적 단위
4. 중복된 명사나 유사한 의미의 명사는 하나로 정리한다.
5. 엔터티 후보 풀에 있는 명사들을 검토한다.
6. 도출된 엔터티에 대하여 구축될 시스템에서 데이터를 관리할 필요가 있는지를 판단한다.

1-2. 엔티티 종류

엔티티 종류에 따라 추가적으로 필요한 엔티티를 확인해 추출한다.
특히 동사

• 실체 엔티티
  • 고객, 사원, 제품 등 과 같이 보이는 물체의 본질적인 성격을 관리하는 엔티티이다.
• 기준 엔티티
  • 우편번호, 배율, 날짜 등 실체나 행위 데이터의 기준이 되는 데이터를 관리하는 엔티티이다.
• 행위 엔티티
  • 강의, 주문, 신청 등 행위나 활동에 의해 발생된 원천 데이터를 관리하는 엔티티이다.
• 가공 엔티티
  • 통계, 임시, 요약 등 원천 데이터를 추출, 집계한 데이터로 관리하는 엔티티
  • 데이터 쌓는 방법 : 트랜잭션 발생, 특정 기간 집계

1-3. 속성의 분류

• 속성 값의 개수
  • 단일 값 속성 Single-valued Attribute
    • 고객 객체의 이름, 적립금 속성
  • 다중 값 속성 Multi-valued Attribute(이중선)
    • 고객 객체의 연락처, 책 개체의 저자
      
      
• 의미의 분해 가능성
  • 단순 속성
    • 적립금, 책 이름, 가격
  • 복합 속성 (세분화)
    • 주소(우편번호, 기본 주소, 상세 주소), 생년월일(년, 월, 일)
      
      
• 기존 속성 값에서 유도
  • 유도 속성 (점선)
    • 가격과 할인율로 계산되는 판매가격, 생년월일로 계산되는 나이
      
      
• 널(Null) 속성
  • 결정되지 않았거나 모르는 값, 현재 존재하지 않는 값
    
    
• 키 속성 (밑줄)
  • 인스턴스 식별자

1-4. 관계 표현

개체와 개체가 맺고 있는 의미 있는 연관성으로 대응관계를 의미한다. (Mapping)

E-R 다이어그램에서 마름모로 표현된다.

관계설정(마름모) - 관계명 - 참여도(점선) - 필수 관계(이중선) 를 검토하여 설정한다.

참여도와 필수 관계를 정의하는데 생각보다 둘의 정의가 모호하고 어려웠다.

(참고)
공급에서 상품은 필수적이다.
→ 제조업체가 상품을 공급한다.
→ 모든 상품은 제조업체에서 공급되어야한다.
→ 상품이 공급하지 않은 제조업체가 있을 수 있다.
작성에서 게시글은 필수적이다.
→ 회원이 게시글을 작성한다.
→ 모든 게시글은 회원이 작성한다.
→ 게시글을 작성하지 않은 회원이 있을 수 있다.

영화예매 관계를 주어진 명세서로 작성했을 때 ERD이다.

2. 논리적 설계

2-1. 릴레이션 작성

ERD를 기반으로 릴레이션 스키마를 작성한다.

• 다대다 관계

  • 관계를 단독 릴레이션으로 변환한다.
  • 참여 개체의 기본키를 포함하여 외래키로 지정하고 외래키를 조합하여 릴레이션의 기본키로 지정한다.

• 일대다 관계

  • 약한 개체가 참여하는 일대다 관계는 외래키를 포함하여 기본키로 지정한다.
  • N측에 관계 속성을 추가한다.

• 일대일 관계

  • 외래키로 표현한다.

• 단, 관계 속성이 많을 경우 (2~3개 이상) 관계를 단독 릴레이션으로 변환한다.

• 복합속성은 논리적 설계 과정에서 나열하여 변환한다.

• 필수적 참여를 포함한 관계 릴레이션에서는 참여개체의 기본키를 외래키로 포함한다.
  
  
  

2-2. 정규화

정규형을 정규화하여 오류 현상을 최소화한다. 조인이 많아지는 성능 문제는 여기에서는 다루지 않는 물리적 설계과정에서 변환한다.

① 제 1 정규형 (1NF)

• 모든 속성이 원자 값을 가진다.
• 기본키에 완전 함수 종속되지 못하고 부분 함수 종속된 속성이 없다.

② 제2정규형 (2NF)

• 릴레이션이 제 1 정규형에 속한다.
• 기본키에 의해 식별되며 모든 비주요 속성이 기본키 전체에 종속된다.

③ 제 3 정규형 (3NF)

• 릴레이션이 제 2 정규형에 속한다.
• 모든 비주요 속성 간에 이행적 함수 종속성이 존재하지 않는다.

④ 보이스/코드 정규형 (BCNF)

• 릴레이션이 제 2 정규형에 속한다.
• 모든 결정자가 후보키 집합에 속한다.

사진 출처 : https://spidyweb.tistory.com/116

3. 느낀점

회원-좌석 관계를 정의하는 과정에서 요구 사항을 만족하는 관계를 찾지 못해 가장 많은 시간을 할애했던 것 같다...
그리고 정규화 과정을 수행하면서 출연 릴레이션의 배우 속성이 후보키가 아님에도 영화 속성을 결정한다고 생각하면서 분해하고 복합키로 추가하는 방법을 찾아갔다. (하지만 종속자인 영화번호 속성이 기본키가 아니므로 해당되지 않는 다는 것을 깨달았다.)

강의를 들으며 일대다, 다대다 관계에서 릴레이션을 변환하는 과정을 보면서 어느정도 익혔다고 생각했는데 역시 예제를 보면서 하는 것과는 다르다. 과제를 수행하면서 원리를 파악하지 못했다는 것을 느꼈고 이번 기회로 오류를 바로 잡고 부족한 부분을 채운것 같다.