Database Chapter 8 - 데이터베이스 설계

• Database 설계 5단계
  • 1 : 요구 사항 분석
    • 데이터의 종류, 처리 방법 수집
    • 수집한 요구 사항 분석 => 데이터베이스의 용도 결정
    • 결과물 : 명세서 ( E-R diagram으로 표현하면 좋음)
  • 2 : 개념적 설계
    • 사용자 요구 사항을 개념적 데이터 모델로 표현 -> 개념적 모델링
    • 결과물 : 주로 E-R model . -> 개념적 구조, 개념적 스키마
    • 객체 및 속성, 관계, 카디널리티 및 관계 특성, 등을 추출 및 결정한다.
  • 3 : 논리적 설계
    • DBMS에 적합한 논리적 데이터 모델을 이용해 논리적 구조 설계 -> 논리적 모델링(데이터 모델링)
    • 관계 데이터 모델 주로 사용
    • 결과물 : 논리적 구조, 논리적 스키마
    • E-R 모델과 관계 데이터 모델의 차이?
    • 릴레이션 스키마 변환  5 규칙 ( E-R 다이어그램 -> 릴레이션 스키마로 )
      • 1. 모든 개체는 릴레이션으로 변환한다.
        • 각 개체를 하나의 릴레이션으로 변환
        • 복합 속성인 경우 단순 속성만 릴레이션의 속성으로 변환
        • 키 속성은 릴레이션의 기본키로 변환
      • 2. 다대다 (n:m)관계는 릴레이션으로 변환한다.
        • 관계를 맺는 개체들을 규칙 1에 의해 변환한 후, 릴레이션 기본키를 관계 릴레이션에 포함시키고 외래키로 저장
        • 외래키를 조합하여 관계 릴레이션의 기본키로 지정
        • 이름 중복 비허용
        • * 다대다 이외 관계를 릴레이션으로 변환하지 않는 것을 권장하는 이유 -> DBMS의 부담이 커지게 된다.
      • 3. 일대다 (1:n)관계는 외래키로 표현한다.
        • 릴레이션으로 변환하지 않고 외래키로만 표현한다.
        • 약한 개체의 1:n 관계(일반 개체의 일대다 관계와의 차이점)
          • 반드시 1 쪽의 릴레이션의 기본키를 n쪽의 릴레이션 외래키로 지정해야 한다.
          • 외래키가 포함된 릴레이션에서 외래키를 포함한 기본키를 지정해야 한다.
          • n쪽 릴레이션 키와 외래키를 조합해 기본키로 지정한다.
          • 강한 개체의 기본키를 이용해 식별하려는 이유
      • 4. 1:1 관계는 외래키로 표현한다.
        • 릴레이션으로 변환하지 않고 외래키로 표현한다.
        • 데이터 중복을 피하기 위함
        • 일반적인 1:1관계는 외래 키를 서로 주고받는다. (서로 기본 키를 주고받아 외래 키로 지정)
        • 1:1 관계에 필수적으로 참여하는 개체의 릴레이션만 외래 키를 가질 수 있다.
          • 그렇지 않을 경우 관계 표현에는 문제가 없지만, 외래키로 지정된 속성에 null값이 저장되는 경우가 늘어남
        • 모든 개체가 1:1관계에 필수적으로 참여한다면 릴레이션을 합친다.
      • 5. 다중 값 속성은 릴레이션으로 변환한다.
      • * 속성이 많은 관계는, 관계 유형에 상관 없이 릴레이션으로 변환하는 것이 좋다.
      •  
  • 4 : 물리적 설계
    • 논리적 설계 단계에서 생성된 논리적 구조를 기반으로 물리적 구조 (내부 저장 구조 및 접근 경로, 레코드 및 인덱스 구조) 설계
    • 결과물 : 내부 스키마, 물리적 스키마
  • 5 : 구현
    • 데이터 정의어 DDL (SQL문)을 이용해 실제 데이터베이스 생성

 

• E-R model VS 관계 model

	E-R model	관계 model
개체와 관계	구분하여 표현	모두 릴레이션으로 표현
다중 값, 복합 속성	허용	비허용