Ch 8. 데이터베이스 설계

01 데이터베이스 설계 단계

데이터베이스 설계는 다음과 같은 5단계로 진행되며 한 방향으로만 순서대로 진행되지 않고 설계 과정 중에 오류를 발견하여 변경이 필요하면 이전 단계로 되돌아가 설계 내용을 변경할 수도 있습니다 :)

 

요구 사항 분석

조직의 구성원들이 데이터베이스를 사용하는 용도 파악 (필요한 데이터 종류, 처리방법 같은 요구사항 수집 및 명세서로 작성)

개념적 설계

요구 사항 분석 단계에서 파악한 사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현하며, 명세서를 개념적 데이터 모델로 변환하는 일을 개념적 모델링이라 합니다. 그리고 표현한 결과물을 개념적 구조 또는 개념적 스키마라고 합니다.

논리적 설계

논리적 데이터 모델을 이용해 개념적 설계 단계에서 생성한 개념적 구조를 기반으로 논리적 구조를 설계합니다. DBMS의 종류에 따라 네트워크 데미터 모델, 계층 데이터 모델, 관계 데이터 모델, 객체지향 데이터 모델 등을 논리적 데이터 모델로 사용할 수 있으며, 일반적으로 관계 데이터 모델을 많이 사용합니다.

그리고 릴레이션 스키마와 같이 논리적 데이터 모델로 표현된 결과물을 논리적 구조 또는 스키마라고 합니다. 

물리적 설계

놀리적 설계 단계에서 생성된 논리적 구조를 기반으로 물리적 구조를 설계합니다. 저장 장치에 적합한 저장 레코드와 인덱스의 구조 등을 설계하고, 저장된 데이터 베이스와 인덱스에 빠르게 접근하게 할 수 있는 탐색 기법 등을 정의합니다. 물리적 설계의 결과물인 물리적 구조를 내부 스키마 또는 물리적 스키마라고 합니다.

구현

설계 단계의 결과물을 기반으로 DBMS에서 SQL로 작성한 명령문을 실행하여 데이터베이스를 실제로 생성합니다. 이때 사용되는 SQL 문은 테이블이나 인덱스 등을 생성할 때 사용되는 데이터 정의어(DDL) 입니다.

 

02 요구 사항 분석

목적: 사용자들의 요구 사항을 수집하고 분석하여, 개발할 데이터베이스의 용도를 명확히 파악합니다.

활용: 분석한 사용자 요구 사항의 내용을 요구 사항 명세서로 작성하여 이후 설계 단계에서 기초 자료로 활용합니다.

주의사항:

사용자 범위를 지정해 불필요한 요구사항을 수집하지 않습니다.

사용자의 업무와 관련해 필요한 데이터가 무엇이고, 그 데이터에 어떤 처리가 필요한지 등에 초점을 맞춰 요구 사항들을 수집하고 분석해야 합니다.

03 개념적 설계

요구 사항 분석 단계의 결과물을 개념적 데이터 모델을 이용하여 표현합니다. 개념적 데이터 모델은 사용자 요구 사항에 대해 분석한 결과를 바탕으로 데이터베이스에 저장할 필요가 있는 데이터 요소를 추출하고 관계를 파악하여 표현합니다. 

 

 

개체와 속성 추출

요구 사항 분석 단계의 결과물에서 개체를 추출합니다. 개체부터 결정해야 속성과 관계도 결정할 수 있으며, 현실 세계에서 조직을 운영하는 데 꼭 필요한 사람, 사물과 같이 구별되는 무든 것을 의미합니다.

 

관계 추출

개체와 속성을 추출하고 나며 개체 간의 관계를 결정할 수 있습니다. 관계는 개체 간의 의미 있는 연관성입니다. 일반적으로 요구 사항을 표현한 문장에서 동사로 표현됩니다.

 

E-R 다이어그램 작성

데이터 베이스에 대한 요구 사항 명세서를 개념적으로 모델링하여 표현한 것입니다. 개념적 설계 단계의 결과물인 개념적 스키마입니다.

https://ko.wikipedia.org/wiki/%EA%B0%9C%EC%B2%B4-%EA%B4%80%EA%B3%84_%EB%AA%A8%EB%8D%B8

개체-관계 모델 - 위키백과, 우리 모두의 백과사전

04 논리적 설계

목표: 독립적인 개념 스키마를 기반으로 논리적 구조를 설계하는 것 입니다.

논리적 데이터 모델로 변환하는 작업을 논리적 모델링 또는 단순히 데이터 모델링이라 합니다.

릴레이션 스키마 변환 규칙

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

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

3. 일대다 관계는 외래키로 표현한다.

4. 일대일 관계를 외래키로 표현한다.

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

 

기타 - 기본 뵨환 규칙에서 다대다 관계만 릴레이션으로 변환하였지만 일대일, 일대다 관계도 릴레이션으로 변환할 수 있습니다. 특히 속성이 많은 관계는 관계 유형에 상관없이 릴레이션으로 변환하는 것을 고려할 수 있습니다.

 

릴레이션 스키마 변환 규칙을 이용한 논리적 설계

릴레이션 스키마 변환 규칙은 데이터베이스의 논리적 설계를 위해 사용되는 중요한 개념입니다. 릴레이션 스키마 변환 규칙을 사용하여 개념적 설계(ER 다이어그램 등)로부터 논리적 설계(릴레이션 테이블)로의 전환을 수행합니다.

일반적으로 다음과 같은 릴레이션 스키마 변환 규칙을 사용합니다:

• 개체 타입(Entity Type)을 릴레이션으로 변환: 개념적 설계의 개체 타입을 릴레이션으로 변환합니다. 개체 타입의 속성들은 릴레이션의 속성으로 매핑됩니다.
• 관계 타입(Relationship Type)을 릴레이션으로 변환: 관계 타입은 일반적으로 외래 키(Foreign Key)를 이용하여 릴레이션으로 변환됩니다. 연결 역할(Connecting Role)과 매핑 역할(Mapping Role)은 외래 키를 통해 다른 릴레이션과 연결됩니다.
• 식별자(Identifier) 처리: 개체 타입의 주 식별자는 해당 릴레이션의 기본 키(Primary Key)로 매핑됩니다. 관계 타입의 식별자는 외래 키로 처리됩니다.
• 상속(Inheritance) 처리: 상속 관계가 있는 경우 슈퍼 타입과 서브 타입을 릴레이션으로 변환하고, 슈퍼 타입의 식별자를 서브 타입의 외래 키로 사용하여 연결합니다.
• 속성 도메인(Domain) 정의: 속성들은 적절한 도메인으로 정의되어야 합니다. 도메인은 해당 속성이 가질 수 있는 값을 제한하고 유효성을 보장합니다.
• 정규화(Normalization): 릴레이션 스키마가 정규화되어야 합니다. 이는 중복을 제거하고 데이터베이스의 무결성을 보장하기 위해 필요한 과정입니다.

릴레이션 스키마 변환 규칙을 적용하여 논리적 설계를 완성하면 데이터베이스 시스템이 데이터를 효율적으로 저장하고 관리할 수 있도록 준비됩니다.

 

05 물리적 설계와 구현

릴레이션 스키마의 설계 완료 후, 하드웨어나 운영체제의 특성을 고려해 필요한 인덱스의 구조나 내부 저장 구조, 접근 경로 등에 대한 물리적인 구조를 설계합니다. SQL 문을 작성하고 이를 실행시켜 DB에 실제 생성하면 데이터베이스 개발이 완료됩니다.