DB모델링

개념적 모델링

• 요구사항 또는 업무프로세스 분석을 통해 개체(Entity), 속성(Attribute), 식별자(identifier), 개체간 관계(Relation) 정의

• E-R 다이어그램 만들기

---

논리적 모델링

• 개념적 모델링을 통해서 만들어진 E-R Diagram을 *Mapping Rule을 통해 스키마로 설계

  • *Mapping Rule
    • Entity(개체) => Table
    • Ayrribute(속성) => Column
    • Identifier(식별자) => Primary key
    • Realtion(개체 간의 관계) => Foreign key
      • (1:1) (1:N)의 관계에서만
      • (N:M) 인 경우 중복 데이터가 발생하기 때문에 관계를 정의하는 테이블 추가
      • (아래그림 참고) N:M 관계에서 발생하는 문제점: 게시글의 각 컬럼이 태그의 여러 항목을 가지고 있다면, 게시글의 col1, col2에 해당하는 정보가 태그정보 N개당 N개씩 중복 데이터가 발생하기 때문에(한 컬럼에 하나의 정보), 관계 정의 테이블의 생성으로 중복을 막는다.
      • 
      • 글번호, 태그번호를 담는 테이블 생성!
      • 
      • 사번, 자격증 정보를 담는 테이블 생성! => 중복 제거

• 정규화 : 규칙에 따라 테이블을 분리

  • 제 1 정규화

    • 개체 내 모든 속성은 반드시 하나의 값을 가져야함(중복 데이터가 발생하면 X)
    • 중복 데이터를 최소화(제거)하는 과정

  • 제 2 정규화

    • 개체 내 모든 속성은 모든 식별자(복합키)에 종속되어야함
    • ex) 재고 테이블

      제품번호(PK), 창고번호(PK), 재고수량, 창고이름, 창고주소
      ㄴ재고수량 : (제품번호, 창고번호)에 종속
      ㄴ창고이름,주소 : 창고번호에만 종속

      => 복합키에 종속되지 않은 창고이름,주소는 분리 가능 => (단, 종속되어있는 창고번호를 함께)
      
      *▼정규화 후* 재고 테이블 : ㄴ제품번호(PK), 창고번호(PK), 재고수량 창고번호: ㄴ창고번호(PK), 창고이름, 창고주소

  • 제 3 정규화

    • 개체 내 속성은 식별자 외 다른 속성에 종속되면 안됨
    • ex) 주문 테이블

      주문번호(PK), 상품번호, 주문일자, 고객번호, 고객명
      ㄴ 고객명 : 고객번호에 종속(식별자에 종속 X)

      ▼*정규화 후* 주문 테이블 ㄴ 주문번호(PK), 상품번호, 주문일자, 고객번호(FK) 고객 테이블 ㄴ 고객번호(PK), 고객명

---

물리적 모델링

• 논리적 모델링을 통해 만든 스키마를 시스템 성능을 고려, 재구성
  • 역정규화
• 실제 데이터베이스 구축
  • 스키마 생성 / 테이블 생성 / 컬럼명 / 데이터 타입 / 제약조건 지정 등