데이터베이스 설계단계 & 정규화

설계 단계

1. 데이터 규정

 데이터베이스 설계의 초기 단계는 이용자들이 필요로 하는 데이터를 충분히 규정하는 것이다.

이 단계의 결과물은 사용자의 요구 명세서(specification of user requirements)이다.

2. 개념적 설계

 다음으로 설계자는 데이터 모델을 선택하고 스키마를 구성한다. 이를 개념적 설계라고 한다.

이때 설계자는 물리적으로 어떻게 저장할지 보다 데이터들의 관계를 기술하는 데 초점을 맞춰야한다.

관계형 모델에서의 개념적 설계는 '어떤 속성'과 테이블을 이루는 속성들을 '어떻게 그룹화 할 것인가'에 초점을 둔다.

'어떤 속성'에 대한 것은 서비스에 따라 다르기 때문에 '어떻게 그룹화 할 것인가'가 주된 CS의 문제이다.

3. 논리 설계 단계

 상위의 개념적 스키마를 사용할 데이터베이스의 구현 데이터 모델에 대응시킨다.

4. 물리 설계 단계

 논리 설계로 나온 시스템 특유의 데이터베이스 스키마를 이용하여 물리적 속성들을 구체화한다.

파일 구성의 형식과 내부적인 저장 구조들을 포함한다.

---

* 개체-관계 데이터 모델은 기본적인 객체를 나타내는 개체들과 개체들 간의 관계를 이용한다. 개체는 속성의 집합으로 기술되며 관계란 여러 개체들 간의 연관성을 말한다. 같은 형의 개체들의 집합은 개체 집합(entity set)이라 하고 모든 관계들의 집합은 관계 집합(relationship set)이라고 한다.

DB의 전체적인 스키마는 E-R 다이아그램으로 시각적 도식을 할 수 있다. 바로 UML을 사용하는 것이다.

E-R 다이아그램의 중요한 제약조건 중 하나가 바로 대응 수 이다. 예를 들어 교수가 하나의 학과에만 속해야한다면 E-R 모델은 적절하게 표현할 수 있어야한다.

---

정규화

 관계형 데이터베이스를 설계하는 또 다른 방법은 일반적으로 정규화로 알려진 단계를 이용하는 것이다.

정규화의 목표는 불필요하게 중복 저장되는 정보가 없고, 정보 검색을 쉽게 할 수 있는 릴레이션 스키마 집합을 생성하는 것이다.

잘못된 설계로 인해 생기는 문제점들은 다음과 같다.

1. 정보의 중복

 만약 나뉘어진 두 개의 테이블을 하나로 합쳐보자. 학과와 학과 예산이 학과 소속 교수 테이블과 합쳐졌다해보자. 학과소속 교수가 여러명인 경우 그만큼 학과 예산도 많은 자리를 차지하게 된다. 이때 학과 예산이 변경되면 중복된 데이터들을 다 바꿔줘야하는 소요가 발생한다.

2. 특정 정보의 표현이 불가능

 위처럼 합쳐진 테이블에서는 특정 학과 소속 교수가 없다면 특정 학과를 표시할 수 없다. 테이블의 모든 레코드들은 값을 다 가지고 있어야하기 때문이다. 이 문제를 해결하기 위해 널(null)을 도입할 수 있다. 널이란 missing(값이 존재하지만 정보가 없음), not known(값이 실제로 존재하는지 아닌지 모름)을 뜻한다. 하지만 널 값은 다루기 힘들기 때문에 의지하지 않는 것이 바람직하다.