DB/이론 및 개념

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

파프리카_ 2024. 4. 25. 15:16
728x90
반응형

데이터 베이스 모델링

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

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]
}
728x90
반응형