본문 바로가기
DB/MySQL

데이터베이스 설계 지침

by 가므자 2012. 3. 26.

데이터베이스의 설계 과정을 더욱 확실하게 살펴보자.
데이터베이스를 생성하기 전에 데이터베이스에 관한 구조를 먼저 설계 해야한다.
이 설계 과정 동안에 정의될 테이블과 각 테이블에 포함된 열을 결정.
그 다음에 데이터베이스 설계 과정을 구조 작업과 비교하여 데이터베이스를 설계한다.

- 사용할 수 있는 기억공간
- 갱신을 위해 최대 수용할 수 있는 시간
- SELECT 명령문을 위해 최대 수용할 수 있는 시간
- 보안성

실제적인 설계를 시작하기 전일지라도 설계는 상황에 가장 관련 있는 요소를 결정해야한다.
즉,
가능하다면 기억공간을 절약할 수 있는가?
SELECT 명령문이 거의 3초의 처리시간을 가질 수 잇는가?
반대로 몇개의 서로 다른 요소를 고려하는 요구가 있는가?
등을 결정해야한다.

여러 가지 요소의 조합을 고려하는 것은 항상 상충 문제를 가져온다.
예를 들면,
기억공간을 절약하는 것은 SELECT 명령문의 처리 시간을 더 길게 한다.
SELECT 명령문의 처리 시간을 빠르게 처리하려고 하면 데이터는 여러 번 저장 되어야 할 것이고 이는 많은 기억 공간을 요구한다.

데이터베이스의 설계 기본 지침 : SELECT와 UPDATE 명령문의 구성을 간단하게 만든다. 변경 명령문의 처리는 각 요소가 오직 한번만 기록되어 있기 때문에 아주 빠르다.

테이블 열에 대한 지침
지침 1 : 각 테이블에 대한 기본 키를 정의하라.
만약 여러 개의 후보 키를 가지고 있다면 기본 키를 선택해야한다. 기본 키의 선택은 항상 열의 번호가 가장 적은 것으로 구성된 후보 키이다. 이는 특히 SELECT 명령문을 사용하여 테이블의 조인과정을 간단하게 한다.

만약 이러한 표준이 어떤 이유 때문에 훌륭한 해결책을 가져오지 못한다면 기억 공간의 양을 가장 적게 사용하는 것이 좋다.
예를 들면 VARCHAR(30)보다는 CHAR(5) 열을 선택하는 것이 좋다.

지침 2: 테이블에서 각 결정자는 그 테이블의 후보 키이어야 한다.
결정 요소란? A라는 열에 있는 각각의 서로 다른 값에 대하여 B라는 열에 관련된 값과 적어도 하나가 다르다면 A라는 열은 B라는 열의 결정요소라 한다. 즉 B는 A에 함수적으로 의존한다는 것.
예를 들면, STUDENT 테이블에 있는 STU_NO 열은 테이블에서 모든 다른 열에 대하여 결정요소이다.

결정요소는 하나 이상의 열로 구성될 수 있다.
FEE 테이블에서 FEE_YEAR와 FEE_DATE열의 결정요소는 FEE_TEAM와 조합으로 구성된다.

STU_NO열이 기본키 일 때, STU_NAME 열의 결정 요소는 STU_NO이다.
GRADE는 또한 CLASS의 결정요소이다. 그 이유는 모든 GRADE가 CLASS에 관련된 것을 적어도 하나 가지고 있기 때문이다

지침 3: 열을 조합하지 않아야 한다.
STUDENT 테이블은 13개의 열로 구성 되어 있는데, 이들 중 일부는 하나의 열로 결합 될 수 있다. 예를 들면 우편번호(POST), 주소(ADDRESS) 열은 ADDRESS라는 하나의 열로 합쳐 질 수 있다. 이는 어떤 SELECT 명령문의 사용을 좀 더 쉽게 한다.

하지만 여러 개의 열을 하나의 열로 조합하는데 있어서 아주 어려운 문제가 발생한다. 예를 들면, 다음과 같은 문제가 있다.
- 학생이 거주하는 도시를 검색하기 위해서는 스칼라 함수를 조합한 아주 복잡한 수식을 사용해야한다. 만약 도시의 이름 앞에 콤마와 공백이 있다면 RTRIM(ADDRESS)와 같은 스칼라 함수를 사용해야한다. 모든 SQL 제품이 이러한 함수를 제공하는 것은 아니기 때문에, 이러한 함수가 제공되지 않는다면 하나의 SELECT 명령문만을 사용하여 열의 값의 일부를 검색할 수 없다.

- 주소의 이름에 기초를 두고 행을 선택했을 때 위의 수식이 사용되어야 한다. 그리고 이러한 수식을 처리하는데는 긴 시간이 소요될 것이다.

- 주소의 이름에 기초를 두고 행을 선택하는 것은 LIKE 연산자를 사용해야한다.

'DB > MySQL' 카테고리의 다른 글

중복 데이터의 포함 설계 지침  (0) 2012.03.27
Database 결정자(Determinant)  (0) 2012.03.27
SQL 명령문의 최적화  (0) 2012.03.21
락(LOCK)  (0) 2012.03.21
innodb 설정  (0) 2012.03.21

댓글