[DATABASE] 데이터베이스 개론_CH8

bin1225·2024년 10월 26일
0

DATABASE

목록 보기
13/19
post-thumbnail

데이터베이스 개론2판(김연희)를 읽고 복습목적으로 내용을 정리한 글입니다.

1. 데이터베이스 설계 단계

데이터베이스는 구조를 변경하기 어려우므로 체계적인 설계 과정을 통해 처음부터 올바르게 구축하는 것이 중요하다.

데이터베이스를 설계 할 때는 두가지 방법을 주로 이용한다.

  • E-R 모델과 릴레이션 변환 규칙 이용
  • 정규화

8장에서는 E-R 모델과 릴레이션 변환 규칙을 이용하는 방법을 설명한다.

1.1 데이터베이스 설계 과정

설계 과정 중 오류를 발견하면 전단계로 돌아가 오류를 수정한다.

1단계: 요구사항 분석

  • 말 그대로 사용자가 데이터베이스를 사용하는 용도를 파악한다.
  • 필요한 데이터의 종류와 처리 방법 등을 수집한다.
  • 정보를 토대로 요구 사항 명세서를 작성한다.

2단계: 개념적 설계

  • 개념적 모델링을 통해 DBMS의 종류에 독립적인 데이터 요소간의 관계를 표현한다.
  • 요구사항 명세서를 개념적 모델로 변환한다.
  • E-R 다이어그램과 같이 개념적 데이터 모델로 표현한 결과물을 개념적 구조 또는 개념적 스키마라고 한다.

3단계: 논리적 설계

  • DBMS에 적합한 논리적 모델을 이용해 개념적 구조를 기반으로 논리적 구조를 설계한다.
  • 주로 관계 데이터 모델을 많이 사용한다.
  • 논리적 데이터 모델로 표현된 결과물을 논리적 구조 또는 논리적 스키마라고 한다.

4단계: 물리적 설계

  • 실제 저장 장치에 저장하기 위한 내부 저장 구조와 접근 경로를 설계한다.
  • 저장 장치에 적합한 저장 레코드와 인덱스 구조 등을 설계하고, 탐색 기법 등을 정의한다.

5단계: 구현

  • SQL문을 사용하여 실제 데이터베이스를 구현한다.

2. 요구사항 분석

  • 데이터베이스를 사용할 주요 사용자의 범위를 결정한다.

    • 사용자마다 요구 사항이 다양하므로, 주요 사용자를 결정하여 불필요한 요구 사항을 수집하지 않는다.
  • 사용자의 업무 관련 필요 데이터와 데이터에 필요한 처리를 수집하고 분석한다.


3. 개념적 설계

요구사항을 바탕으로 데이터베이스에 저장할 필요가 있는 데이터 요소를 추출하고 요소 간의 관계를 파악하여 표현한다.

개념적 모델링 과정

  1. 개체와 속성을 추출한다.
  2. 개체 간 관계를 결정한다.
  3. 결과를 E-R 다이어그램으로 작성한다.

3.1 개체와 속성 추출

개체

  • 개체는 현실 세계에서 어떤 조직을 운영하는 데 꼭 필요한 사람, 사물과 같이 구별되는 모든 것을 의미한다.

  • 개체는 저장할 만한 가치가 있는 모든 요소이다. (실체가 있을 필요X)

  • 요구사항 명세서에서 주로 주어로 표현된다.

요구사항 명세서를 바탕으로 개체와 각 개체에 필요한 속성값들을 추출하고 관련성을 정의한다.

3.2 관계 추출

관계

  • 개체 간의 의미 있는 연관성
  • 요구사항 명세서에서 주로 동사로 표현된다.

관계를 추출하면 추출한 관계에 대한 매핑 카디널리티와 참여 특성을 결정한다.

  • 매핑 카디널리티는 각 개체 인스턴스가 관계를 맺고 있는 상대 개체의 인스턴스 개수를 의미한다. (일대일, 일대다, 다대다)

  • 참여 특성은 관계 참여의 필수성을 의미한다.

3.3 E-R 다이어그램 작성

추출한 개체와 관계를 바탕으로 E-R다이어그램을 작성한다.
개념적 설계 단계의 결과물인 개념적 스키마이다.

E-R 다이어그램 예시


4. 논리적 설계

E-R 다이어그램을 DBMS가 처리할 수 있는 논리적 구조로 변환하는 단계이다.

E-R다이어그램과 관계 데이터 모델은 표현이 다르기 때문에 변환이 쉽지 않다.

  • E-R 다이어그램에서는 개체와 관계를 구분하지만, 논리적 설계 단계에서는 개체와 관계를 구분하지 않고 모두 릴레이션으로 표현한다.

  • E-R 다이어그램에서는 다중 값 속성이나 복합 속성의 표현을 허용하지만, 관계 데이터 모델에서는 허용하지 않는다.

이를 체계적으로 변환하기 위해 릴레이션 스키마 변환 규칙 5가지가 존재한다. 하지만 규칙을 따른다고 해서 완벽함을 보장하지는 않기 때문에 설계 이후 정규화를 통해 검증 작업이 필요하다.

4.1 릴레이션 스키마 변환 규칙

4.1.1 규칙 1: 모든 개체는 릴레이션으로 변환한다.

  • 각 개체를 릴레이션으로 변환한다.
  • 개체가 포함한 속성도 릴레이션의 속성으로 변환한다.
  • 속성이 복합 속성인 경우 복합 속성을 구성하고 있는 단순속성만 릴레이션의 속성으로 변환한다.

4.2.2 규칙 2: 다대다 관계는 릴레이션으로 변환한다.

  • E-R 다이어그램의 다대다 관계 자체를 하나의 릴레이션으로 변환한다.
  • 관계를 맺고 있던 개체들의 기본키를 외래키로 가진다. (외래키 2개를 조합하여 기본키로 사용한다.)

4.2.3 규칙 3: 일대다 관계는 외래키로 표현한다.

  • 일대다 관계는 릴레이션으로 변환하지 않고 외래키로만 표현한다.
  • 약한 개체가 참여하는 경우와 일반 개체만 참여하는 경우를 다르게 처리한다.
    4.2.3.1 일반적인 일대다 관계
    • 1측이 가진 기본키를 n측 개체의 외래키로 지정한다.
    • 반대의 경우는 외래키가 다중값을 가져 릴레이션의 특성을 위반한다.
      4.2.3.2 약한개체가 참여하는 일대다 관계
    • 약한 개체는 강한 개체의 기본키를 외래키로 지정한다.
    • 약한 개체의 기본키는 약한개체의 기본키 + 외래키(강한개체의 기본키)조합으로 구성한다.

4.2.4 규칙 4: 일대일 관계는 외래키로 표현한다.

  • 데이터 중복을 피하기 위해 개체 참여 특성에 따라 3개의 세부 규칙으로 나눈다.

    4.2.4.1 일반적인 일대일 관계는 외래키를 서로 주고 받는다.
    • 관계를 맺는 개체들의 기본키를 서로 주고 받아 외래키로 지정한다.

    • 서로 외래키를 가지게 되면 불필요한 데이터 중복이 발생한다. (한쪽만 가지고 있어도 충분)

      4.2.4.2 일대일 관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 받는다.
    • 두 개체 중 관계에 필수적으로 참여하는 개체가 해당 개체에 대응하는 외래키를 가진다.

    • 반대의 경우는 외래키에 널 값을 가지는 상황이 발생한다.

      4.2.4.3 둘 다 관게에 필수적으로 참여하는 경우 릴레이션 하나로 합친다.
    • 둘 다 필수적이라면 그만큼 관련성이 있는 개체라는 의미이다.

    • 두 릴레이션을 하나로 합치고 각각의 기본키를 조합하여 합친 릴레이션의 기본키로 지정한다.

    4.2.5 규칙 5: 다중 값 속성은 릴레이션으로 변환한다.

  • 관계 데이터 모델은 다중 값을 허용하지 않는다.

  • 별도의 릴레이션을 만들어서 다중 속성과 그 속성을 가지는 개체 간의 관계를 저장한다.

릴레이션이 많아질수록 이를 관리하는 DBMS의 부담이 커진다.
외래키로만 표현할 수 있는 관계는 릴레이션으로 변환하지 않는 것이 좋다.

Reference

IT CookBook, 데이터베이스 개론(2판): 기초 개념부터 빅데이터까지_김연희

0개의 댓글