데이터베이스 설계의 기본원리

1. 기능분석 

시스템을 분석할 때 필자는 제일 우선적으로 기능분석을 실시해야 한다고 생각한다. 그 이유는 기능분석을 통해서 우리는 구축해야 할 전체 시스템의 규모와 기능을 일목요연하게 정리할 수 있기 때문이다. 또한, 이를 통해서 시스템을 구축하기 위해 필요한 최소 단위의 프로세스를 판별해 낼 수가 있다. 기능분석은 우선 개발해야 할 시스템이 가져야 할 기능을 Tree 구조로 도식화하여 정리한 다. 이것은 Top-Down 방식을 통해서 개발해야 할 시스템의 기능 구성을 보다 쉽게 정리할 수 있기 때문이다. 이때 기능의 각 항목은 짧은 제목으로 표시한다.

2. 엔티티 도출

우선 단위 프로세스를 분석하게 되면 엔티티 도출은 상당히 쉬워진다. 엔티티란 정보를 저장하는 최소단위 객체를 뜻한다. 여기서는 단순히 데이터베이스의 테이블이라 명칭 하겠 다. 기본적으로 프로세스 또는 프로그램이라고 하면 크게 세가지 구조로 나뉘게 된다. 그것은 “입력 ->처리 -> 출력”으로 표현된다. 즉, 모든 프로그램은 입력된 데이터를 처리하고 그 가공한 결과 데이터를 출력하게 된다. 따라서 우리는 도출된 각각의 단위 프로세스가 필요한 입력데이터의 종류를 찾아내고 처리 후 결과를 저장해야 할 종류를 분석해 나가면, 이 시스템 전체가 필요한 엔티티의 종류를 알 아낼 수가 있는 것이다. 엔티티는 이 밖에도 장표분석, 업무분석, 동적분석 등 모든 수단을 통하여 세밀하게 검토 되고 도출되어야 한다. 

3.동적분석, 관계정의, 식별자정의

주식별자 정의는 전체 데이터 모델의 복잡성을 결정하는 중요한 요소이다. 

- 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다. 

- 속성값의 길이가 가변적인 속성은 주식별자로서 적당하지 않다. “부서이름”보다는 “부서코드”를 주식별자로 지정하라 

- 속성값이 자주 변하는 속성은 주식별자로서 적당하지 않다. 

- 주식별자를 선정하기 위한 속성(필드)의 수를 적게 한다. 

- 주식별자에는 Null 데이터가 들어와서는 안 된다. 

4. 세부사항 정리

이제 설계된 각각의 엔티티에 입력될 세부사항(속성)을 정의할 단계이다. 아래는 속성을 정의할 때 주의해야 할 원칙이다.  

- 각각의 속성은 반드시 하나의 엔티티에 속해야 한다. 

- 각각의 속성은 전체 데이터 모델에서 하나의 의미만을 가지고 있어야 한다. 

5. 정규화

정규화란 데이터 모델을 보다 효율적으로 개선시켜나가는 과정을 뜻한다. 일반적으로 정 규화는 중복된 데이터를 삭제하는 것이 주 목적이다. 정규화는 1차에서 5차까지의 단계로 나누어 지며, 5차 정규화는 실무에서 거의 사용하지 않고 있다. 

- 1차 정규화 : 하나이 주식별자를 기준으로 여러 값을 가진 속성은 존재할 수 없다.

- 2차 정규화 : 모든속성은 주식별자에 종속적이어야 한다.

- 3차 정규화 : 다른 속성에 종속적인 속성은 분리되어야 한다.

-4차 정규화 : N:M 관계 해소

6. 반정규화

반정규화란 정규화를 통해서 제거된 중복데이터를 고의로 입력하는 작업을 뜻한다. 정규 화가 잘되어 있는 모델의 경우 무결성이 보장되는 장점이 있지만, 정규화가 잘되어 있을 경 우 성능이 오히려 떨어질 수 있다. 이때, 성능 자체가 큰 이슈가 되었을 때는 반정규화를 통해서 성능을 향상시킬 수 있다. 정규화와 반정규화는 시스템의 무결성과 성능이라는 두 가지 이슈 사이에서 적절한 선택을 통하여 균형을 잡았을 때 빛이 나게 된다. 정규화는 정합성과 무결성을 보장하는 대신 성능 에 저하를 가져올 수 있고, 반정규화는 성능과 모델의 단순화에 대한 이점이 있지만 무결성 저하로 인하여 시스템의 안정성을 해칠 수가 있다.

7. 검증

CRUD 분석은 프로세스와 엔티티의 상관관계를 이용하여 구축된 데이터베이스 시스템을 검 증할 수 있는 방법이다. 아래의 토표처럼 각 프로세스 마다 사용하는 엔티티를 표기하고, 각각의 프로세스가 해당 엔티티를 생성(C), 조회(R), 변경(U), 삭제(D) 하는가에 대한 여부 를 표기한다.

-  모든 엔티티 타입에 CRUD가 한 번 이상 표기되었는가? 

- 모든 엔티티 타입에 C가 한 번 이상 존재하는가? 

- 모든 엔티티 타입에 R이 한 번 이상 존재하는가? 

- 모든 단위 프로세스 하나 이상의 엔티티 타입에 표기가 되었는가? 

- 두 개 이상의 단위 프로세스가 하나의 엔티티 타입을 생성하는가? (이 경우 반드시 잘못되었다기 보다 로직의 검토 대상이 된다) 

8. Primary Key를 가볍게

사용자 테이블을 구축할 때 주로 “Primary Key”로 사용하는 것은 UserID일 것이다. 하 지만, 문자열은 숫자에 비해 그 데이터 사이즈가 크기 때문에 인덱스 효율이 떨어진다. 일 반적인 코드 테이블에서는 그 레코드 숫자가 작기 때문에 이러한 것을 무시할 수 있으나, 사 용자 테이블의 레코드 수가 많아진다면 문제가 될 수가 있다. 이러한 경우에는 일련번호 필드를 새로 추가해서 “Primary Key”로 사용하는 것이 효율 적이다. 

또한, 필드를 조합하여 “Primary Key”로 사용할 경우에도 그 크기가 너무 커지지 않도록 조심해야 한다.

9. 주민번호와 사원번호 등에 대한 고정관념

 가끔 필드타입을 결정하는 데 있어서, 사원번호를 문자열 형태로만 만드는 경향이 있다. 이것들을 숫자형태로 바꾼다면 인덱스의 효과 면에서나 테이블이 차지하는 용량 면에서나 많 은 이점을 얻을 수 있다.

- 주민번호는 가운데 '-'를 필드에 반드시 넣을 필요가 있을 까? 

- 사원번호는 '000001'처럼 '0'이라는 문자가 반드시 필드에 있어야 할 까? 

- 사원번호는 영문과 함께 반드시 부서이름을 설정해줘야 할 까? 

10. 테이블이 중복되면 무조건 역효과를 가져올 것인가?

통계처리와 같은 경우를 생각해보면 해당 월이든 기본 단위 외에는 데이터가 변하지 않는 다. 이런 경우 이미 고정된 범위를 미리 집계한 테이블을 생성하고 추가될 부분만 필요 시 마다 생성한다면, 퍼포먼스는 매우 향상될 것이다. 만약 빈번한 사용이 없는 통계데이터라 면 분리할 필요는 없다. 만약 월마다 또는 기본 단위마다 서로 상관관계가 없는 데이터가 생성된다면 기본단위 별 로 테이블을 잘라내서 변경 시 걸리는 부하를 줄일 수 있다.