데이터베이스 설계

1. 데이터베이스 설계 개요

가) 데이터베이스 설계 정의

- 사용자 요구조건 에서부터 데이터베이스 구조를 도출해 내는 과정

- 데이터들을 효과적으로 관리하기 위하여 데이터베이스의 구조를 조직화하는 작업

​

나) 데이터베이스 설계 목적

- 이해관계자의 데이터 관점 요구사항에 대한 정확한 이해 및 추상화

- 데이터를 중심으로 한 이해관계자 간의 원활한 의사소통 수단

- 데이터 중심의 분석방법

​

다) 데이터베이스 설계 시 고려사항

항목	설명
제약조건	저장된 데이터 값이 만족해야 될 주어진 조건
데이터베이스 무결성	갱신, 삽입, 삭제 등의 연산이 수행된 뒤에도 데이터 값은 제약조건을 만족해야하는 조건
일관성	저장된 두 데이터 값 또는 특정 질의에 대한 응답들에 모순성 없이 일치하는 특성
회복	시스템에 장애가 발생했을 때 장애 발생 직전의 일관된 데이터 상태로 돌아가는 기법
보안	불법적인 데이터의 변경이나 손실 또는 노출에 대한 보호
효율성	응답 시간의 단축, 저장공간의 최적화, 시스템 생산성이 포함
데이터베이스 확장성	시스템 운영에 영향을 주지 않으면서 새로운 데이터를 계속적으로 추가 가능한 기법

​

2. 데이터베이스 설계 개념도 및 설계 단계

가) 데이터베이스 설계 개념도

출처: http://www.incodom.kr/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%AA%A8%EB%8D%B8%EB%A7%81

- 개념적 설계 => 논리적 설계 => 물리적 설계

- Entry 목록 및 정의서, Relation 목록, ERD가 공통 주요 산출물

​

나) 데이터베이스 설계 단계별 특성

단계	주요관점	설명
요구조건 분석	문서화	- 개체, 속성, 관계, 제약조건과 같은 정적정보 구조 - 트랜잭션 유형, 트랜잭션 실행빈도와 같은 동적 DB 처리 요구조건 - 기관의 경영목표, 정책 및 규정과 같은 기관적 제약조건
개념적 설계	현실세계 추상화	- 현실세계를 데이터관점으로 추상화 단계 - DBMS를 고려하지 않는 독립적 설계 - 데이터베이스의 개념적 스키마 (E-R다이어그램) 구성
논리적 설계	데이터모형기반 설계	- 특정 데이터모델(계층형, 관계형, 객체지향형 등)을 적용한 설계 - 사용 할 DBMS 특성을 고려한 설계 - 데이터베이스의 논리적 스키마 (릴레이션 스키마) 생성
물리적 설계	DBMS기반 설계	- 특정 DBMS의 물리적 구조와 내부적인 저장구조, 분산형태, 데이터타입의 특징, 인덱스의 특징 등을 구체화하는 설계단계 - 오브젝트, 접근방법, 트랜잭션분석, 인덱스, 뷰, 데이터베이스 용량설계 등을 수행 - 데이터베이스의 물리적 스키마 생성 (하드웨어/운영체제 특성 고려)

​

3. 데이터베이스 요구사항 수집 및 분석

가) 데이터베이스 요구사항 수집 및 분석 항목

항목	설명
요구조건 수집	- 데이터베이스를 사용하는 주요 분야와 사용자 그룹을 식별 - 식별된 그룹들의 업무, 데이터 종류, 용도, 처리형태, 흐름 및 제약/요구조건 수집 - 트랜잭션에 대한 입력과 출력 데이터 식별 - 설문지/인터뷰 및 회의롤 통해 도출하고 문서화 진행
제약조건 식별	- 경영정책, 내/외부적 환경, 조직의 정보전략을 연구/분석하여 요구조건 명세에 반영 - 반영된 요구조건 명세는 데이터베이스 설계 범위를 결정짓는 중요 요소로 활용
명세 작성	- 관련 데이터 요소, 트랜잭션, 처리 특성에 대한 명세 포함 - 빈번한 변경을 방지하여 안정적인 개발 환경조성 - 작업-데이터 관계, 데이터 요소간 제약조건, 유일성 및 함수 종속성 명세 포함
명세 검토	- 정보 처리 요구조건을 조직하여 표현하기 위한 소프트웨어 공학기법 사용 - 사용자 그룹과 다시 검토하고 확인 한 뒤 최종 시스템 명세로 확정
명세검토 활용 기법	소프트웨어 공학	- HIPO, SADT, DFD, Orr-Warnier, Nassi-Schneiderman - 정보 처리 요구조건을 조직하여 표현하기 위한 다이어그램 방식
	프로그램 활용 (PSL/PSA)	- 명세에 대한 일관성과 완전성을 검사하기 위한 자동화 도구 활용 - 요구조건을 설계 데이터베이스에 저장하여 설계 과정동안 활용

​

4. 데이터베이스 개념적 설계

가) 개념적 설계 정의 및 특징

- 요구사항 분석 결과를 개념적인 데이터 모델(E-R 모델)을 사용하여 고차원적인 표현 기법으로 기술하는 방식

- DBMS를 고려하지 않는 독립적 설계

- 데이터베이스의 개념적 스키마 (E-R다이어그램) 구성

​

나) 개념적 스키마 설계 과정

개체와 속성 추출	- 요구사항 분석단계에서 개체와 속성을 추출하는 일
관계 추출	- 개체간의 의미있는 연관성이며, 추출한 관계의 매핑 카디널리티를 기준으로하여 관계(1:1, 1:N, N:M) 결정 - 개체가 관계에 필수적 참여인지 또는 선택적 참여인지를 구분짓는 참여특성을 결정
E-R 다이어그램 작성	- 요구 사항 명세서에서 추출한 개체, 속성 및 관계를 E-R 다이어그램으로 작성

* 매핑 카디널리티란? 관계를 맺는 두 개체 집합에서, 각 개체 인스턴스가 연관성을 맺고 있는 상대 개체 집합의 인스턴수 개수

개념적 스키마 결과물 = E-R 다이어그램

다) 개념적 설계 방법

뷰 통합방법 (하향식 방법)	뷰 식별 모델링 관점	- 요구조건 분석 단계에서 식별된 사용자 그룹을 기초로 뷰(VIEW)를 식별하고 모델링 수행 - 필요 개체를 식별, 각 개체의 키 속성 결정, 개체들간 관계성을 식별 및 명세 - 개체의 특성을 표현하는 설명 속성 추가
	뷰 통합 관점	- 완성된 부문별 뷰들을 하나로 통합해서 전체적 개념 스키마를 작성하는 방식 - 통합 시 동일성 통합(같은 요소나 동의어 통합), 집단화(개체를 구성하는 속성집합), 일반화(공통 성질을 가진 개체들을 일반적이고 포괄적으로 만듬) 개념 이용
애트리뷰트 합성 방법 (상향식 방법)	작업-데이터 관계	- 속성을 분류하고, 분류된 속성들 중 후보키 가능여부를 기준으로 분류 - 개체 정의(기본키, 대체키, 설명 속성으로 구성) - 관계 정의(개체간의 관계, 개체와 속성간 관계, 속성들 간의 관계 식별) - E-R 다이어그램 작성

​

5. 데이터베이스 논리적 설계

가) 논리적 설계 정의 및 특징

- 개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용, 개념적 설계 단계에서 생성한 개념적 스키마를 기반으로 DBMS가 처리할 수 있는 데이터베이스의 논리적 구조를 설계

​

나) 논리적 설계 시 변환 규칙

- E-R 다이어그램을 릴레이션으로 변환 시 작업의 난이도는 낮춰주는 규칙

규칙	설명
1. 모든 개체는 릴레이션으로 변환	- E-R 다이어그램의 각 개체를 하나의 릴레이션으로 변환. 개체의 이름을 릴레이션 이름으로, 속성은 릴레이션 속성으로 변환 ​ ​ ​
2. N:M 관계는 릴레이션으로 변환	- E-R 다이어그램의 관계는 릴레이션 이름, 관계의 속성은 릴레이션 속성으로 변환 - 관계를 맺고 있는 개체는 제1규칙에 따라 변환한 후 이 릴레이션의 기본키를 관계 릴레이션에 포함시키고 외래키로 지정 (외래키 지정 시 이름이 같을 경우 변경)
3. 1:N 관계는 외래키로 표현	3.1 일반적인 1:N 관계는 릴레이션으로 변환하지 않고 외래키로만 표현 - 제1규칙에 따라 개체를 릴레이션으로 변환, 1에 해당하는 개채의 기본키를 N에 해당하는 개체의 외래키로 지정 ​ 3.2 약개체가 참여하는 1:N 관계의 경우 외래키가 포함된 릴레이션에서는 해당 외래키를 포함하여 기본키를 지정 - 약개체의 기본키는 외래키(오너개체의 기본키)와 약개체의 기본키의 혼합으로 구성 승객이 좌석번호만을 가지고 자신이 예매한 좌석을 정확하게 찾을 수 없다. 예매한 비행기까지 알아야만 정확한 확인이 가능하기에 약개체 좌석 릴레이션에서 비행기번호와 좌석번호를 기본키로 설정하는 것이 타당하다
4. 1:1 관계는 외래키로 표현	4.1 일반적인 1:1 관계는 외래키를 서로 주고 받음 - 관계는 릴레이션으로 변환하지 않고 개체 릴레이션 기본키를 상호간 외래키로만 표현 - 관계가 가지고 있는 속성들은 관게에 참여하는 개체를 변환한 릴레이션에 포함 ​​ ​ 4.2 1:1관계에 필수적으로 참여하는 개체의 릴레이션만 외래키를 수용 - 관계를 맺는 두 개체중 관계에 필수적으로 참여하는 개체 릴레이션에만 외래키 포함 - 관계에 필수적으로 참여하는 개체 릴레이션이 선택적으로 참여하는 개체 릴레이션의 기본키를 받아 외래키로 지정, 관계의 속성들은 관계에 필수적인 개체 릴레이션에 포함 - 선택적 참여 릴레이션이 외래키를 가져도 되지만 외래키로 지정 된 속성에는 Null 값이 저장되는 경우가 많이 발생 ​ 4.3 모든 개체가 1:1 관계에 필수적으로 참여 시 릴레이션 하나로 표현 - 두 개체가 모두 필수적으로 참여한다면 관련성이 높기에 릴레이션을 합쳐 하나로 표현 - 관계의 이름을 릴레이션으로 사용, 관계에 참여하는 개체의 속성을 관계 릴레이션에 포함 - 두 개체 릴레이션의 키 속성을 조합하여 관계 릴레이션의 기본키로 지정
5. 다중 값 속성은 릴레이션으로 변환	- 관계 데이터 모델 릴레이션은 다중 값 속성을 허용하지 않아 E-R 다이어그램에 있는 다중 값 속성은 별도의 릴레이션을 만들어 포함 - 신규 릴레이션의 속성 구성은 다중 값 속성으로 구성되고 기본키 구성은 다중값 속성과 외래키를 조합하여 지정

6. 데이터베이스 물리적 설계 개요

가) 물리적 설계 정의 및 특징

정의	- 논리적 스키마로부터 효율적이고 구현 가능한 물리적 데이터베이스 구조를 설계하는 행위
특징	- 구현단계에서 실행할 수 있는 트랜잭션을 구현하는데 필요한 내부 구조를 결정 (병행 수행) - 데이터베이스의 물리적 구조는 데이터베이스 시스템 성능에 중대한 영향을 미침 - 물리적 설계는 하드웨어와 운영 체제의 특성을 고려하여 설계

나) 물리적 데이터베이스 기본 저장 구조

- 물리적 데이터베이스의 기본적인 데이터 단위는 저장 레코드(= 논리적 레코드 + 물리적 저장 정보)

- 동일 파일(한 타입의 저장 레코드들의 집합) 내에 있는 저장 레코드라고 해서 반드시 크기 미일치

- 물리적 설계는 "저장 레코드 양식", "저장 장치에서의 레코드 집중화", "접근 경로 설계"가 포함

​

다) 물리 데이터베이스 (내부 스키마) 설계

분 류	설 명
저장 레코드의 양식 설계	- 저장 레코드 양식은 데이터 타입, 데이터 값의 분포, 프로그램, 접근빈도 고려 - 저장 레코드에 대한 데이터 표현과 압축에 대한 양식 - 물리적 단계의 성능평가에 따라 앞의 결정 사항이 변경 가능성 존재
레코드 집중의 분석 및 설계	- 저장 공간에 레코드들이 물리적으로 집중 저장되도록 할당 (물리적 순차성) - 레코드들을 연속된 저장 공간에 할당, 블록 크기 선성(효율적 검색 목적) - 데이터 레코드의 순차 처리시 "큰 블록" 유리, 임의 접근 처리시 "작은 블록" 유리
접근 경로 설계	- 접근 경로는 물리적 저장 장치 위에 저장된 데이터의 접근(저장구조)과 처리(탐색 기법)를 가능하게 하는 절차 - 저장 구조는 주로 인덱스를 통한 접근 방법과 저장 레코드를 정의 - 탐색 기법은 주어진 응용을 위해 취해야 될 적절한 접근 경로 정의 - DBMS가 정해지면 물리적 설계는 DBMS가 제공하는 DB파일 조직 방법 중 선택

라) 물리 데이터베이스 설계 시 고려사항

항목	설명
응답 시간	- 트랜잭션을 실행시키기 위해 시스템에 입력 시킨 때부터 다시 결과를 받을 때 까지 시간 - 트랜잭션이 참조하는 데이터에 대한 데이터베이스 접근시간은 DBMS에 영향을 받음
저장 공간 효율화	- 데이터베이스 파일, 접근 경로 구조들을 저장하기 위해 최소한의 저장공간을 사용
트랜잭션 처리도	- 단위 시간에 데이터베이스 시스템이 처리할 수 있는 평균 트랜잭션 처리도 - 시스템에 부하가 절정을 이루는 시간대를 고려

- 성능 요건을 만족하는 여부를 평가는 시뮬레이션이나 프로토타입과 같은 분석적 기법이나 실험적 기법 사용

​

​

참고내용

​

1. CRUD Matrix - 프로세스와 데이터 간의 상관관계

가) CRUD Matrix 정의

- 시스템 개발 시 프로세스와 DB에 저장되는 데이터 사이의 상관관계을 표현하는 Matrix

​

나) CRUD Matrix 필요성

필요성	설명
모델링 작업 검증	- 분석 단계의 데이터 모델과 프로세스 모델에 대한 작업 검증 역활
중요 산출물	- 시스템 구축 단계에서 어플리케이션 개발 시 필요하며 중요한 산출물
테스트시 사용	- 어플리케이션을 객관적 자료를 사용하여 테스트 시 중요 테스트 케이스 역활
인터페이스 현황파악	- 전체 업무의 인터페이스 파악 가능

​

다) CRUD Matrix 명칭

확인사항	설명
Create	- 프로세스가 하나 이상의 엔티티에 데이터를 생성하는지 여부 - 필수 데이터 생성 누락 여부 확인 및 생성 후 읽기가 전혀 없는 경우 확인 - 특정 엔티티 데이터를 생성하는 프로세스가 다수 존재하는 경우 병합을 고려
Read	- 데이터 생성 없는 읽기가 존재하는지 여부 - 특정 데이터 읽기가 과도하고 빈번하게 발생하는 경우 부하분산을 고려
Upload	- 데이터 생성 없는 수정이 존재하는지 여부 - 데이터 수정 프로세스가 전혀 없는 경우 확인 - 특정 엔티티 데이터를 수정하는 프로세스가 다수 존재하는 경우 병합을 고려
Delete	- 데이터 생성 없는 삭제가 존재하는지 여부 - 데이터 삭제 프로세스가 전혀 없는 경우 확인 - 특정 엔티티 데이터를 삭제하는 프로세스가 다수 존재하는 경우 병합을 고려
공통	- 한개의 프로세스가 CRUD를 모두 수행하는 경우 프로세스 분할을 고려 - CRUD가 한번도 유발되지 않는 엔티티 및 프로세스 확인

 

[출처] https://m.blog.naver.com/roser111/221638714322