# 05. 데이터 베이스 모델링

데이터 베이스 모델링

• 여러 절차적 과정에 의해 진행

1. 순서

1. 요구사항 분석 -> 요구사항 명세서 생성

2. 개념적 모델링

3. 논리적 모델링

4. 물리적 모델링

• 개념적 모델링

  • 분석 관점으로 사용자의 요구사항을 분석

  • E-R 모델을 통해 개체/관계/속성으로 분류

• 논리적 모델링

  • 설계 관점에서 개념적 모델을 충실히 변환

  • 특정 유형군의 DBMS을 염두에 두고 표현

  • 릴레이션 스키마의 테이블 구조로 표현됨

• 물리적 모델링

  • 논리적 모델링의 연장선으로 물리적 구조를 표현

  • 특정 DBMS의 특성과 구조에 적합하게 물리적 데이터 구조 명세

  • 최적화된 테이블 레코드 형식, 저장구조, 접근 방식 명세

==> 좋은 데이터 베이스 설계는

1. 요구사항을 충실히 만족

2. 데이터의 일관성과 무결성 유지

3. 최적의 성능을 발휘

2. 실습

1. 요구사항 명세

- 모든 DevOps팀원들은 식물에 물을 준다.
- 모든 DevOps팀원들은 고유한 사번, 이름, 직급이 있다.
- 모든 식물들은 고유한 이름, 품종, 물주는 시기, 상태 정보가 관리된다.
- 팀원이 식물에 물을 준 경우, 물을 준 날짜, 물의 양 정보를 관리한다.
- DevOps팀원들은 팀원 1인당 1개의 물뿌리개를 구매할 수 있으며, 구매 시 구매날짜를 관리한다.
- 물뿌리개는 고유한 물품번호가 있으며, 모양, 색 정보도 보관한다.

2. 개념적 설계

2-1. 개체 정의

• 개체는 기본 요소 (독립적 요소)

2-2. 관계 정의

• 개체와 개체 사이에 맺어지는 연관성

• 개체 없이 존재할 수 없는 종속적 존재

2-3. 속성 정의

• 개체나 관계가 갖는 고유한 특성

2-4. ER 다이어그램으로 표현

물뿌리개와 팀원은 1:1 관계

• -> 팀원이 물뿌리개는 1개까지밖에 사지 못하므로

팀원과 식물을 다:다 관계

• -> 팀원들은 여러 식물에게 물을 줄 수 있으며, 식물들도 여러 팀원으로부터 물을 받을 수 있으므로

3. 논리적 설계

3-1. 개체 변환

• 개체의 이름이 릴레이션의 이름이 된다.
• ex)

• 

• 팀원(사번, 팀원이름, 직급)

3-2. 관계 변환

• 일대일(1:1) 관계 변환

  • 둘 릴레이션 중 하나의 릴레이션의 기본키를 다른 릴레이션의 외래키 속성으로 추가

  • 어느 쪽 릴레이션에 외래키를 추가하더라고 상관 없음

  • 관계가 가지고 있던 속성을 외래키를 추가한 릴레이션의 속성으로 추가

  • ex)

    

  • 팀원(사번, 팀원이름, 직급)

  • 물뿌리개(물품번호, 색, 모양, 구매날짜, 구매자사번)

• 다대다(m:n) 관계 변환

  • 관계는 하나의 독립된 릴레이션으로 변환

  • 생성된 릴레이션에 기존 양쪽 개체 릴레이션의 기본키 속성을 외래키 속성으로 포함 시키고, 이를 기본키로 지정한다.

  • ex)

    

  • 팀원(사번, 팀원이름, 직급)

  • 물주기(사번, 식물이름, 물준날짜, 물의양)

  • 식물(식물이름, 품종, 상태, 물주는시기)

• 일대다(1:n) 관계 변환

  • 일 측의 개체 릴레이션 기본키의 속성을 가져와, 다 측의 릴레이션의 외래키 속성으로 추가하여 포함

  • 단, 외래키 속성의 이름에 관계이름을 포함하도록 변경 => 의미를 명확히 하기 위해

3-3. 논리모델링 -> ERD 작성(IE 표기법)

4. 물리적 설계

• 특정 데이터베이스로 설계함으로써 데이터를 저장할 수 있는 물리적인 스키마

• 특정 DBMS 특성에 맞게 설계

• 즉, 논리 모델을 각 DBMS의 특성에 맞게 데이터 베이스 저장 구조(물리 데이터 모델)로 변환하는 것

• 단순한 설계된 논리 데이터 모델의 개체 명칭이나 속성 명칭, 데이터 형태, 길이, 영역값등을 변환하는 것으로만 생각하지만, 실제 저장 공간, 분산, 저장 방법 등까지도 고려해야 한다.

• https://dbdiagram.io/ 사이트에서 아래의 코드로 생성

  Table MEMBER {
    EMPLOYEE_NO VARCHAR [primary key]
    DUTY_NAME VARCHAR
    NAME VARCHAR
    TEL_NO VARCHAR(11)
  }
  
  Table WATERING {
    EMPLOYEE_NO VARCHAR [primary key, ref: > MEMBER.EMPLOYEE_NO]
    PLANT_NAME VARCHAR [primary key, ref: > PLANT.PLANT_NAME]
    WATERTING_DATE VARCHAR(8)
    WATERING_MOUNT integer
  }
  
  Table PLANT {
    PLANT_NAME VARCHAR [primary key]
    PLANT_KIND VARCHAR
    WATERING_INTERVAL_DAY integer
    STATUS VARCHAR(1) [note: '코드값으로 관리']
  }
  
  Table WATERING_CAN {
    WATERING_CAN_ID VARCHAR [primary key]
    COLOR VARCHAR
    SHAPE integer
    PURCHASE_DATE VARCHAR(8)
    PURCHASE_EMPLOYEE_NO VARCHAR [ref: > MEMBER.EMPLOYEE_NO]
  }