왜 데이터베이스 설계에 관심을 가져야 하는가
- RDBMS는 DB를 설계하는 데에는 도움이 되지 않는다. 다만 쉽고 생성/수정/조작할 수 있을 뿐이다.
- RDBMS는 논리적 DB 구조를 설계한 이후에 사용하는 것이 더 좋다.
- DB 설계는 데이터의 일관성, 무결성, 정확성에 영향을 끼친다.
- 부정확한 정보는 잘못된 DB 설계가 가져올 수 있는 가장 최악의 결과다.
이론의 중요성
- 이론은 결과를 예측할 수 있게 해준다.
- 관계형 DB는 집합 이론(set theory)과 1차 술어 논리(first-order predicate logic)로 알려진 수학 분야에 기초를 두고 있다.
- 원하는 결과를 얻기 위해 기초 구조물을 배열하는 것을
"설계"라고 정의한다.
훌륭한 설계 방법론을 배움으로써 얻는 이점
훌륭한 설계 방법론을 학습하고 사용하면 다음과 같은 이점들이 있다:
- 견고한 DB 구조를 설계하는 데 필요한 기술을 제공한다
- 불필요한 데이터, 중복 데이터, 의미 없는 데이터, 필요한 데이터의 부재 등을 막을 수 있다.
- 단계적으로 설계 프로세스를 알려줄 조직화된 기술 집합을 제공한다
- 조직화된 기술은 설계의 모든 측면에서 정보에 근거한 결정을 내릴 수 있게 해준다.
- 실수와 설계 반복을 최소한으로 줄여준다
- 훌륭한 방법론은 설계 오류를 인식하고 이를 해결할 수 있는 도구를 제공한다.
- 설계 프로세스를 쉽게 만들며 DB의 설계에 소요되는 시간을 줄여준다
- 논리와 조직화를 통해, 시행착오를 할 때보다 더 시간을 아낄 수 있다.
- RDBMS 응용프로그램을 보다 더 완벽하고 효과적으로 이해하고 사용하는 데 도움을 준다
훌륭한 설계의 목적
훌륭하고 견고한 DB 구조를 설계하기 위해서는 아래의 목적들을 목표로 해야 한다:
- DB는 필수 및 임의적인 정보 검색을 모두 지원한다.
- 설계 과정에서 정의한 요구사항 뿐 아니라 사용자가 추가로 요구하는 임의적인 질의를 지원해야 한다.
- 테이블은 적절하고 효율적으로 구성되어야 한다.
- 중복 데이터를 최소화하고 고유값을 가진 필드에 의해 식별되어야 한다.
- 필드, 테이블, 관계 수준에서 데이터 무결성을 보장한다.
- 무결성의 수준은 데이터 구조와 데이터가 항상 정확하다는 것을 보증한다.
- DB는 조직과 관련된 업무 규칙을 지원한다.
- 데이터는 항상 업무에 의미가 유효하고 정확한 정보를 제공해야 한다.
- DB는 자체의 미래성장에 적합하다.
- DB 구조는 업무 변화나 성장에 따른 정보 요구사항에 의해 확장, 수정이 쉬워야 한다.
훌륭한 설계의 이점
- DB 구조를 쉽게 수정할 수 있고 운영할 수 있다.
- 테이블, 필드에 대한 수정이 DB의 다른 테이블, 필드에 부정적 영향을 주지 않는다.
- 데이터를 쉽게 수정할 수 있다.
- 필드값을 변경하는 것이 다른 필드값에 부정적 영향을 주지 않는다.
- 중복을 최소화하므로 특정한 데이터값만 수정할 수 있다.
- 정보를 쉽게 검색할 수 있다.
- 관계가 제대로 설정되어있기 때문에 질의가 쉽다.
- 최종 사용자 응용프로그램을 개발하고 구축하기가 쉽다.
- 잘못 설계된 DB에서 오는 부작용을 피해, 프로그래밍과 데이터 조작 작업에 시간을 더 투자할 수 있다.
데이터베이스 설계 방법
전통적인 설계 방법
DB 설계의 전통적인 방법은 3단계이다: (1) 요구사항 분석, (2) 데이터 모델링, (3) 정규화
요구사항 분석 과정
- 모델이 되는 사업에 대한 조사
- 현재 시스템을 평가하고 미래의 요구를 분석하기 위한 사용자, 관리자와의 면담
- 전체 사업에 대한 정보 요구사항의 평가 등
데이터 모델링 과정
- DB 구조를 설계하는 것
- ERD, 의미-개체(semantic-object) 모델링, 개체-관계(object-relation) 모델링, 개체-역할(object-role) 모델링, UML 모델링 등의 방법을 사용한다.
- 테이블, 테이블 관계, 관계 특성과 같은 DB 구조의 다양한 측면을 시각적으로 표현하는 수단을 제공한다.
- 필드들도 이 단계에서 정의되고 적절한 테이블에 포함된다.
- 각 테이블에 기본 키(Primary Key)를 할당한다.
- 데이터 무결성의 다양한 수준이 식별 및 구현된다.
- 외래 키(Foreign Key)를 통해 관계가 설정된다.
정규화 과정
- 불필요한 데이터와 중복 데이터를 제거하고, 데이터 삽입, 업데이트 또는 삭제에서 발생하는 문제를 방지하기 위해 큰 테이블을 작은 테이블들로 분해하는 과정
- 테이블 구조를 정규형(normal form)에 대해서 테스트를 수행한 후 문제를 발견하면 수정한다.
이 책에서 제시된 설계 방법
- 요구사항 분석, 간단한 ERD 방법을 포함한다.
- 정규형은 공부하지 않은 사람에게는 혼란스러울 수 있으니 포함하지 않는다.
- 다음은 테이블 구조에 대한 제3정규형을 사용한 결과에서 도출된 정의다:
테이블은 각각의 레코드들을 유일하게 식별하는 필드를 가져야 한다.
이 각각의 필드들은 테이블이 나타내는 주제를 표현하여야 한다.
- 다음은 테이블 구조에 대한 제3정규형을 사용한 결과에서 도출된 정의다:
여담
- 책에는
개체-관계(object-role) 모델링으로 되어있는 것을개체-역할(object-role) 모델링로 옮겼다.
- 우리는 완전하게 정규화된 테이블이 적절하고 효율적으로 설계되었다고 가정한다면 그런 테이블의 구체적인 특징을 식별해 이상적인 테이블의 속성이라고 제기할 순 없을까?
- 설계 프로세스에서 DB를 위해 생성하는 모든 테이블을 위한 모델로 이상적인 테이블을 사용할 수 있지 않을까?
라는 구절이 있는데 굉장히 플라톤스럽다고 생각했다. 일단 이 책에서는 테이블의 이데아는 있다("당연히 가능하다")고 주장한다.
