데이타베이스 설계

< 출처 : http://members.tripod.lycos.co.kr/leenlim/subject/subject5.html >


 

기업 또는 조직의 정보시스템 구축에는 보다 안정적인 데이터의 구축과 관리가 보다 중요한 요소이다. 따라서 과거처럼 프로세스 중심적이고, 어플리케이션 로직 중심, 파일 구조 중심 보다는 관계형 데이터베이스를 이용한 데이터 중심적인 시스템 구축 방법이 일반화되었고, 이를 위해서는 데이터의 분석과 설계가 보다 중요할 수 밖에 없다. 데이터 또는 데이터베이스의 분석과 설계는 RDBMS의 등장으로 보다 복잡하면서 체계화되고 있다. 데이터베이스의 설계 과정은 다음 그림과 같이 표현된다.

1. 데이터베이스 계획(Database Plan)

데이터베이스 계획은 일반적으로 ISP(정보전략계획)과 거의 유사한 작업이거나 같은 개념이라고 볼 수 있다. 기업의 내적, 외적 환경과 전략적 요구사항, 그리고 최상위 수준의 시스템 구분과 모델링을 통해 향후 데이터베이스 구축의 방향을 제시한다.

2. 요구사항 분석(Requirement Analysis)

요구사항 수집 단계는 기업 내에 존재하는 각종 문서들(장표, 업무분장, 보고서, 시스템 산출물 등)을 수집하거나 분석하고 인터뷰, 관찰, Brainstorming 등을 통해 데이터들을 찾는 과정이다. 사용자와 어플리케이션 범위의 검증 : 주요 대상범위와 데이터베이스를 사용할 사용자 집단이 검증된다. 운영환경과 처리사항의 분석 : 트랜잭션 처리 형태와 발생빈도, 시스템내에서의 정보의 흐름, 입력 및 출력 데이터 등이 정의된다. 질의서와 인터뷰 : 잠재적 데이터베이스 사용자에 대한 서면 질의서가 작성, 검토되고 주요 담당자와의 인터뷰를 통해 각 정보에 대한 가치를 평가하고 이에 따른 정보의 등급도 평가된다.

3. 개념 데이터 설계(Conceptual Data Design)

이 단계에서는 데이터베이스를 구현하기 위한 사전 단계로서 DBMS에 독립적이며, 순수한 업무관점의 개략적인 데이터 모델링에 해당한다. 요구사항 분석을 토대로 이 단계에서 만들어지는 모델은 다음 단계인 논리적 데이터 모델의 바탕이 되며, 데이터 테이블, 혹은 엔티티들의 큰 묶음인 주제영역(Subject Area)이 파악된다. 각 주제 영역별로 구체적인 속성이 드러나지 않은 정도의 개략적 ERD(Entity Relationshio Diagram) 정도만 그려진다. 개념 데이터 모델은 추상화된 최상위 수준의 데이터 설계라고 할 수 있다.

4. 논리 데이터 설계(Logical Data Design)

개념 데이터 설계가 DBMS 및 하드웨어 구조와 완전히 독립된 것이라면 논리적 설계에서 만들어지는 모델은 이 개념적 모델을 DBMS가 처리할 수 있도록 Mapping하는 과정이라고 보면 된다. 논리 설계를 위해 필요한 자료들을 정리해보면 다음과 같다. 개념 데이터 모델 : 개념 설계에서 작성한 ERD 등의 모델 운영 요구사항 : 요구사항 분석 단계에서 파악된 응답시간, 보안, 회복 및 데이터 저장, 익관성의 제약조건 등에 관한 명세 상위 수준의 프로그램 명세 : 데이터베이스 트랜잭션의 접근형태 등 DBMS 특성 : DBMS의 논리적 구조 기타 제약조건 일반적으로 모델링이라 함은 현실세계의 대상을 이해, 해석하는데 이용하기 위한 표현방법이라 할 수 있다. 따라서 데이터 모델링이라는 것은 처리되어야 할 데이터를 이해하고 해석하기 위해 그림 또는 문서의 형태로 알기쉽게 표현하는 것이라 보면 된다. 관계형 데이터베이스가 DBMS의 주를 이룸에 따라 ERD(Entity Relationship Diagram)의 작성은 데이터베이스 설계에서 가장 중요한 요소가 되었다. 4.1. ERD(Entity Relationship Diagram)의 작성 데이터베이스를 물리적으로 구축하기 전까지의 작업에서는 ERD를 통한 모델링과정에 가장 많은 노력을 들이게 된다. ERD는 현업의 데이터의 구성을 표현할 수 있어 데이터베이스의 논리적 구조를 이해할 수 있을 뿐만 아니라 신규 데이터베이스 구축의 근거가 된다. 다음은 ERD의 아주 간단한 예이며 ERD의 요소를 간단히 정리하면 다음과 같다.   4.2 엔티티 식별 엔티티는 명확히 정의를 내리기 어렵지만 다음과 같은 정의들이 있다. Thomas Bruce : 정보가 유지되는 것에 관한 어떤 구별 가능한 사람, 장소, 어떤 것(thing), 이벤트 또는 개념이다.(1992) Clive Finkelstein : 엔티티는 향후 참조되기 위해 저장될 'thing'을 표현한다. 엔티티라는 말은 데이터의 논리적 표현이다.(1989) James Matin : 엔티티라는 저장되는 정보(고객, 공급자, 도구, 종업원, 비행기 좌석 등)에 관한 것이다. 각각의 엔티티 타입에 대해 속성들이 저장된다.(1989) 한마디로 저장되고 관리되어야 할 정보(명사)로서 물리적으로 DBMS의 Table하나 정도가 되는 것으로 보면 된다. 엔티티를 추출하기 위한 방법은 다음과 같다. ▶ 업무에 있어서 관심사이며 관리의 필요성이 있는 정보 ▶ 명사, 단수형 ▶ 업무요구사항의 파악에 중요한 것 ▶ 모든 엔티티는 다수의 인스턴스(Insburlywoodce; 사용건수)를 가져야 한다. ▶ 모든 엔티티는 자신을 설명하는 속성들을 포함해야 한다. 예) --------burlywoodgible --------사람(Person) - 고객, 종업원, 관리자 등 --------장소(Site) - 자료실, 창고, 공장 등 --------어떤 것(Thing) - 제품, 벤더, 부품 등 --------Inburlywoodgible --------개념(Concept) - 일정, 예산항목, 정산 등 --------사건(Event) - 판매, 구입 등 4.3 엔티티의 유형   Kernal Entity Type : 다른 엔티티의 인스턴스의 존재와 무관하게 존재하는 기본적인 엔티티 Characteristic Entity Type : 다른 엔티티의 존재에 의존하는 엔티티 Associative Entity Type : 두 엔티티간의 관계를 나타내는 엔티티 Subtype Entity Type : 다른 엔티티에 종속적인 엔티티 4.4 관계의 개념 관계(Relation)는 두 개의 엔티티나 그 자신과의 특정관계를 연결하여 양방향으로 표현한 것을 의미한다. 그림 4에서 처럼 관계선과 관계명, 카디널리티(Cardinality), 옵셔널리티(Optionality) 등으로 업무규칙(Business Rules)을 표현한다. ▶ 관계선 위와 아래에 관계명을 표시한다. 관계명은 동사(verb) 형태로 표현된다. ▶ 카디널리티는 양쪽의 엔티티의 관계가 1:n, n:1, 1:1, n:n 등 임을 나타낸다. ▶ 옵셔널리티는 양쪽의 엔티티가 Mandatory(반드시 존재해야 함), Optional(존재하지 않울 수 있음) 중 하나로 표현된다. 그림4의 경우는 고객은 주문을 하고 주문은 고객에게 주문되는 관계이며, 한명의 고객은 여러 주문을 할 수 있고 하나의 주문은 단 한명의 고객에 의해서만 이루어지므로 1:n의 관계이다. 또한 고객이 주문하는 관계에서 고객이 반드시 있어야 주문이 이루어지고, 고객만 있고 주문을 하지 않을 수 있으므로 고객은 Mandatory, 주문은 Optional이 된다. ER 모델에서는 1:1의 관계나 n:n의 관계는 되도록 피하도록 한다. 1:1의 관계는 두 엔티티가 하나의 엔티티로 합쳐지는 것으로 볼 수도 있으며 n:n의 관계는 다른 한쪽의 식별이 어렵기 때문에 다음 그림과 같이 Associative 엔티티를 인위적으로 삽입하여 1:n의 관계로 풀어준다.   4.5 속성의 개념 속성(Attributes)은 엔티티 내에서 관리되는 정보들의 항목으로서 엔티티를 설명하는데 사용되는 명사이다. 즉, 엔티티를 구성하는 요소가 되며, 하나의 엔티티에는 고유식별자를 포함한 하나 이상의 속성이 포함되어야 한다. 속성의 명칭을 정의하는 방법을 간단하게 알아보면 다음과 같다. ▶ 의미가 명확하고 길지 않으며 내용을 함축성있게 표현 ▶ 엔티티명을 사용해서는 안됨 ▶ 단 하나의 엔티티에만 속하도록 함 ▶ 가능한한 최소단위까지 분할 ▶ 여러 값을 가지거나 반복되는 속성은 엔티티로 분할 ▶ 추출값, 즉 Count값이거나 Total값, 최대, 최소, 평균 등의 계산 값 등은 포함시키는 것은 낭비 ▶ 속성이 자신의 속성을 가질 수 있으면 엔티티로 분류 속성은 물리적 개발 단계에 앞서 각 속성의 값의 범위(Scope), 크기(Size), 형식(Format), Null 여부 등의 특성들을 기술해주어야 한다. 4.6 상세 데이터 모델링 개념 데이터 모델은 정규화(Normalization)를 해주어야 바람직한 모형이 된다. 직관적으로 엔티티에 속성을 배치하다보면 이를 테이블로 옮길 때 RDBMS의 무결성을 손상시킬 수 있다. 따라서 정보의 손실이나 불필요한 정보의 도입없이 일관성과 최소한의 중복 및 최대의 안정성을 확보하기 위해 데이터 구조를 정규화하게 된다. 되도록 엔티티(테이블)들을 쪼개는 작업이다. 정규화는 개념 모델링이 어느 정도 이루어진 후 하는 것이 바람직 하겠지만 ERD를 어느 정도 완성하다보면 1, 2차 정규화는 알게 모르게 이루어진다. 또한 정규화를 집중하여 하더라도 3차 이상의 정규화는 하지 않아도 큰 문제는 없다. 정규화의 이점을 다음과 같이 정리할 수 있다. ▶ 데이터 저장공간을 최소화 한다. ▶ 데이터베이스에서 데이터가 불일치할 위험을 최소화시킨다. ▶ 갱신 및 삭제시의 Anomalies를 최소화한다. ▶ 데이터 구조의 안정성을 최대화한다. ▶ 여러 값을 가지거나 반복되는 속성은 엔티티로 분할 ▶ 추출값, 즉 Count값이거나 Total값, 최대, 최소, 평균 등의 계산 값 등은 포함시키는 것은 낭비 ▶ 속성이 자신의 속성을 가질 수 있으면 엔티티로 분류 정규화의 규칙을 간략히 정리하면 다음과 같다. 제 1 정규형 : 모든 속성은 반드시 하나의 값을 가져야 한다. 즉, 여러 인스턴스(Insburlywoodce)가 발생되는 속성의 그룹은 별도의 엔티티로 분리시켜야 한다. 제 2 정규형 : 모든 속성은 반드시 고유식별자(또는 Key)에 종속되어야 한다. 즉, 고유식별자에 종속적이지 않은 속성들은 분리하여 별도의 엔티티로 만든다. 제 3 정규형 : 고유식별자가 아닌 모든 속성간에는 서로 종속될 수 없다. 고유식별자가 아닌 속성에 종속되는 속성들을 모아서 별도의 엔티티로 분리한다.   정규화외에도 3.4 절에서 설명한 바와 같이 n:n의 관계를 가진 두 엔티티의 관계를 1:n으로 해소해주는 작업도 상세 모델링에 해당된다. 이 때 Associative 엔티티가 추가되면서 엔티티의 분할이 이루어진다.

5. 물리 데이터 설계(Physical Data Design)

물리적 설계는 시스템을 고려한 논리적 설계를 해당 구현가능한 물리적 데이터베이스 구조로 전환하고 DBMS의 조건에 맞게 성능을 최적화하는 과정이라 할 수 있다. 각 엔티티는 테이블(Table)이 되고 고유식별자는 기본키(Primary Key)로, 속성은 컬럼(Column)으로, 관계는 외래키(Foreign Key)와 그에 따른 Foreign Key Rule로 전환된다. 또한 정규화로 분리된 테이블들을 운영 요구사항과, DBMS의 조건, 트랜잭션 용량과 발생 주기 등을 고려하여 일부 다시 합치는 비정규화(Denormalization)작업도 이루어지며, 데이터 구조의 생성을 위해 SQL을 이용하여 스키마(Schema)를 생성한다. 데이터 조작어(DML이나 SQL)을 사용하여 데이터를 조작할 때 이 자체로는 특정 데이터에 대한 접근경로를 명확히 할 수 없다. SQL 구문은 접근해야 할 데이터, 테이블의 컬럼이나 행의 식별만 지원할 뿐, 그 데이터를 어떻게 접근할 것인가를 지원하지는 않는다. 이것은 DBMS 제품에 따라 따르며 이러한 최적화의 설계는 각 DBMS 벤더의 정보에 의존할 수 밖에 없다. 물리 데이터베이스에서 고려되는 요소들은 다음과 같은 것들을 들 수 있다. 인덱스(Index) : 인덱스는 데이터 테이블을 포인트하는 특정한 구조를 가지며, 테이블에서 한 개당 여러 개 인덱스를 만들 수 있다. 예) CREATE UNIQUE INDEX CUSTOMER_PKEY ON CUSTOMER (CNO); 인덱스는 언제나 테이블 자체보다 적고, 메모리에 올려놓고 사용할 수 있기 때문에 성능 향상에 도움이 되지만 잦은 갱신의 경우에는 오히려 성능을 저하시킨다. 클러스터링(Clustering) : 논리적으로 관련된 레코드들을 물리적으로 디스크에 같이 저장하는 개념이다. 예) 고객 데이터가 고객번호에 의해 순차적으로 자주 수행된다면, 이때 고객번호로 물리적으로 정렬하여 저장한다. 비정규화(Denormalization) : 자주 같이 사용되는 테이블은 결합시킨다. 이것은 어플리케이션과 사용자가 데이터를 접근하는 방식에 따라 결정된다. 예) 데이터가 주로 읽기 위주로 접근될 때 그리고 데이터가 주로 한 개의 응용 프로그램에 의해 접근될 때 테이블을 합치면 성능 향상 효과를 볼 수 있다. 단편화(Fragmentation) : 한 개의 테이블이 상당히 크거나 데이터의 부분집합을 배타적으로 사용할 때, 한 개의 테이블을 두 개로 쪼갠다. 예) 수천만개의 rows를 가진 “전화 가입자 청구서” 테이블은 각 지역별로 테이블을 분할할 수 있다.