데이터베이스 설계
#
Find similar titles
- (rev. 14)
- jhkim
Structured data
- Category
- Database
Table of Contents
데이터베이스 설계 프로세스 #
데이터베이스 설계 프로세스 (출처)
데이터베이스 설계 기본원리 #
기능분석 #
데이터베이스 설계 시 가장 먼저 수행하여야 하는 작업으로, 기능분석을 통해 구축 대상 시스템의 규모와 기능을 정리한다.
기능분석은 구축 대상 시스템이 담고자 하는 기능을 Tree 구조로 도식화하여 정리한 것으로, 기능의 각 항목을 짧은 제목으로 표시하여 구축 대상 시스템의 기능 구성을 쉽게 정리한다. 기능분석을 통하여 시스템을 구축하기 위한 최소 단위의 프로세스를 판별할 수 있다.
데이터베이스 기능분석(PBS) (출처)
위 그림에서 볼 수 있듯이 Tree 구조의 가장 낮은 단계가 구축 대상 시스템의 최소 단위 프로세스이다.
기능분석을 통해 작성된 Tree는 구축 대상 시스템의 개발일정 산출의 근거로 사용되기도 한다.
엔티티 도출 #
엔티티(Entity)란 정보를 저장하는 최소 단위의 객체를 뜻하는 것으로, 쉽게 이해하자면 데이터베이스의 테이블이라 할 수 있다.
앞서 기능분석에서 도출된 단위 프로세스에서 필요한 입력데이터의 종류를 찾아내고, 처리 후 결과를 저장해야 할 종류를 분석해 나가면, 구축 대상 시스템에서 필요한 엔티티들을 도출할 수 있는 것이다.
동적분석 #
단위 프로세스와 데이터 흐름의 관계를 분석하고 검증할 수 있는 방법이다. 대표적인 예로는 DFD(Data Flow Diagram)가 있다.
20 YEARS OF DEVELOPING TOOLS AND METHODOLOGY (출처)
DFD의 정의
DFD(Data Flow Diagram)는 데이터가 소프트웨어의 각 프로세스에 따라서 변환되는 모습을 나타내는 흐름표이며 정보시스템의 분석, 설계에서 유용하게 사용되고 있는 다이어그램이다. 데이터 흐름도 혹은 자료 흐름도라고 지칭되며 시스템의 모형화 도구로서 보편적으로 사용된다. 데이터보다 기능이 복잡하고 중요할 때 유용하게 사용되며 한눈에 프로세스를 이해할 수 있다.
DFD의 특징
1. 시스템을 분할하기 위한 중요한 모형화 도구
2. 도형을 사용하여 그림 중심으로 표현
3. 자료의 흐름에 중점을 두고 상황을 표현
DFD 작성 원칙
-
데이터 보존의 원칙
- 출력 데이터의 흐름은 반드시 입력 데이터 흐름을 이용하여 생성한다.
-
최소 데이터 입력의 원칙
- 출력 데이터를 산출하는 데 필요한 최소의 데이터 흐름만 입력한다.
-
독립성의 원칙
- 단위 프로세스는 단위 프로세스에 해당하는 입력 데이터와 출력 데이터에 대해서만 관여한다.
-
지속성의 원칙
- 단위 프로세스는 항상 수행되어야 한다.
-
순차 처리의 원칙
- 입력 데이터 흐름의 순서는 출력되는 데이터 흐름에서도 유지되어야 한다.
-
영구성의 원칙
- 데이터 저장소의 데이터는 입력으로 사용해도 지워지지 않는다.
관계 정의 #
데이터베이스 관계정의 (출처)
위의 그림은 간단하게 정의된 ERD(Entity Relationship Diagram)로 엔티티 간의 관계를 정의하며 주로 1:1, 1:N, N:M의 관계로 분류된다.
관계가 명확하게 정의되지 않을 때 데이터의 무결성을 보장받을 수 없으며, 데이터들 간의 관계를 잘 파악하여 먼저 ERD를 통해 구축 대상 시스템의 효율성을 검토한다.
식별자 정의 #
주식별자 정의는 전체 데이터 모델의 복잡성을 결정하는 중요한 요소이다.
아래와 같은 사항에 유의하여 정의한다.
- 자주 이용되는 속성을 주식별자로 지정한다.
- 속성값의 길이가 가변적인 속성을 주식별자로서 적당하지 않다.
- "부서이름" 보다는 "부서코드"를 주식별자로 지정한다.
- 속성값이 자주 변하는 속성은 주식별자로 적당하지 않다.
- 주식별자를 선정하기 위한 속성(필드)의 수를 적게 한다.
- 주식별자에는 NULL을 사용하지 않는다.
세부사항 정의 #
설계된 엔티티에 입력될 세부사항(속성)을 정의한다.
아래와 같은 사항에 유의하여 정의한다.
- 각각의 속성은 반드시 하나의 엔티티에 속해야 한다.
- 각각의 속성은 전체 데이터 모델에서 하나의 의미만을 지녀야 한다.
정규화 #
정규화란 데이터베이스의 중복을 최소화하여 저장 효율을 높이고 연산 시 이상 현상을 최소화할 수 있는 논리적 구조로 변환시키는 작업으로 데이터 모델을 보다 효율적으로 개선해나가는 과정을 뜻한다. 총 6가지의 정규화 과정 중 실질적으로 제 3 정규화까지는 실무에서 필수적으로 적용되며 나머지 남은 정규화는 필요에 의해서 적용되는 경우가 많다.
제1 정규화 #
제1 정규화는 릴레이션의 모든 속성값이 원자값(Atomic Value)만을 갖는 경우이다. 이를 만족시키는 조건은 다음과 같다.
- 반복 그룹이 존재하면 안 된다.
- 모든 행은 식별자로 완전하게 구분되어야 한다.
제2 정규화 #
제2 정규화는 릴레이션이 제1 정규형을 만족하고, 기본키가 아닌 속성이 기본키에 완전 함수 종속일 때를 의미한다. 완전 함수 종속이란 기본키로 묶인 복합키가 모여 하나의 다른 값을 결정하고, 복합키의 부분집합이 결정자가 되면 안 된다.
- 키가 아닌 값들은 모두 키에 종속되어야 한다.
제3 정규화 #
제3 정규화는 제2 정규형을 만족하고, 모든 속성이 키에 의존하며 다른 후보키에 의존하지 않는다. 다르게 표현하면, 기본키 이외의 속성이 그 외 다른 속성을 결정할 수 없는 것이다.
반정규화 #
반정규화란 정규화를 통해서 제거된 중복데이터를 고의로 입력하는 작업을 뜻한다. 정규화가 잘되어 있는 모델의 경우 무결성이 보장되는 장점이 있지만, 정규화가 잘되어 있을 때 성능이 저하될 수 있다. 이때, 의미 없는 정규화 작업으로 인하여 성능 자체가 큰 이슈가 되었을 때는 반정규화를 통해서 성능을 향상 시킨다.
역정규화 #
정규화된 릴레이션은 하나의 릴레이션을 분류하기 때문에 원하는 자료가 하나의 릴레이션에 존재하지 않아 외래키를 이용해 참조해야 하는 상황이 많이 발생할 때 데이터베이스에 데이터를 출력하는 시간을 증가시키며 성능을 저하시킬 수 있으므로 역정규화를 진행한다. 역정규화된 스키마는 데이터를 입력, 수정, 삭제할 때 관계를 맺고 있는 테이블을 참조해야 하며 가장 작은 단위로 테이블에 나뉘어져 있기 때문에 연관된 정보를 보기 위해서 조인을 수행해야 한다. 즉 시스템의 기능 향상을 위한 정규화에 위배되는 행위를 역정규화라고 한다.
검증 #
CRUD 분석 #
CRUD 분석은 프로세스와 엔티티의 상관관계를 이용하여 구축된 데이터베이스 시스템을 검증하는 방법이다.
아래의 도표처럼 모든 엔티티 목록을 나열하고 각각의 프로세스가 해당 엔티티에 대하여 생성(C), 조회(R), 변경(U), 삭제(D) 하는가에 대한 여부를 표기한다.
프로세스/엔티티 | 엔티티 1 | 엔티티 2 | 엔티티 3 | 엔티티 4 |
---|---|---|---|---|
프로세스 1 | C | RUD | ||
프로세스 2 | R | C | ||
프로세스 3 | RU | C | R | |
프로세스 4 | R | RUD | C |
CRUD 매트릭스 작성 후 아래와 같은 항목들을 점검하여 설계에 이상이 없는가를 확인한다.
- 모든 엔티티 타입에 CRUD가 한 번 이상 표기되었는가?
- 모든 엔티티 타입에 C가 한 번 이상 존재하는가?
- 모든 엔티티 타입에 R이 한 번 이상 존재하는가?
- 모든 단위 프로세스가 하나 이상의 엔티티 타입에 표기되었는가?
- 두 개 이상의 단위 프로세스가 하나의 엔티티 타입을 생성하는가?
- 이 경우 반드시 잘못되었다기 보다 로직의 검토 대상이 된다.
데이터베이스 설계 시 유의사항 #
- Primary Key 설정
- 인덱스 효율 측면을 고려하여 문자열의 User ID 필드를 Primary Key로 설정하기보다는 일련번호 필드를 새로 추가하여 Primary Key로 사용하는 것이 효율적이다.
- 데이터 타입 설정
- 주민등록번호와 사원번호 필드의 타입을 문자형이 아닌 숫자 형으로 바꾼다면 Index 효율이나 용량 면에서 많은 이점을 얻을 수 있다.
- 데이터의 속성에 대하여 파악한 후 그 데이터에 속성에 맞게 적용하며 데이터의 크기 또한 데이터의 속성을 잘 파악해야만 효율적인 데이터 타입과 크기 선정이 가능하다.
- Index 설계
- 한 필드에 입력될 내용의 종류가 적으면 그 필드는 Index를 만들지 않는다.
- Data의 양(=Record 수)이 적으면 Index를 만들지 않는다.
- 결합 Index를 생성할 때는 검색이 많은 필드를 항상 먼저 쓴다.
- 결합 Index를 생성할 때는 효율이 높은 필드를 먼저 쓴다.
- Index가 가해지는 필드는 가능한 NULL 값이 없어야 한다.
- Index의 효과로는 해당 필드에 데이터를 미리 Index로 정의하여 빠르게 데이터를 출력한다.
- Table Join
- Table Join 시에는 Record의 수가 적은 것부터 Join 한다.
- 다량의 Table과 다중 Join이 필요할 시에는 Cluster를 생성한다.
데이터베이스 설계 강의자료 #
[출처] YouTube, [3장 데이터베이스 설계]
Reference #
- 데이터베이스 설계의 기본 원리