타스크: 데이터베이스 디자인
이 타스크에서는 응용프로그램에서 데이터베이스가 지속성을 유지하면서 구현되도록 디자인하는 방법을 설명합니다.
목적
  • 지속적 데이터가 일관성 있고 효율적으로 저장되도록 합니다.
  • 데이터베이스에서 구현해야 하는 동작을 정의합니다.
관계
기본 설명

이 타스크에 표시된 단계에서는 응용프로그램의 지속적 데이터 디자인이 관계형 데이터베이스 관리 시스템(RDBMS)을 사용하여 구현되는 것으로 간주합니다. 또한 사용자가 정규화 및 비정규화를 포함한 데이터베이스 개념은 물론, [DAT99]와 같은 참조에서 다루는 데이터베이스 용어에 대해서도 익숙하다고 간주합니다. 

이 타스크의 단계에서는 [NBG01]에서 논의되는 데이터베이스 모델링을 위한 UML(Unified Modeling Language) 프로파일도 참조합니다. 또한, [NBG01]에는 UML을 사용하여 관계형 데이터베이스를 모델링하고 디자인하는 프로세스의 일반적인 설명이 포함됩니다. 관계형 데이터 모델과 오브젝트 모델의 관계에 대한 배경 정보에 대해서는 개념: 관계형 데이터베이스 및 객체 지향을 참조하십시오.

단계
논리 데이터 모델 개발(선택사항)
목적 데이터베이스의 논리 디자인 모델을 정의합니다.

논리 데이터 모델의 목적은 핵심 논리 데이터 엔티티와 해당 엔티티의 관계에 대한 이상적인 보기를 제공하는 데 있으며 해당 보기는 특정 소프트웨어 또는 데이터베이스 구현과는 독립적입니다. 논리 데이터 모델은 일반적으로 세 번째 정규형을 사용하는데(개념: 정규화 참조), 해당 양식은 중복을 최소화하고 이행 종속성이 없는 데이터 모델링 양식입니다. 해당 모델은 데이터 및 성능을 사용하는 응용프로그램과 관련되지 않고 데이터 캡처 시의 데이터베이스 모양과 관련됩니다. 논리 데이터 모델은 중간 산출물: 데이터 모델의 파트로 간주되며, 독립된 RUP 중간 산출물이 아닙니다. 그러나 다음의 경우 개별 논리 데이터 모델을 정의하는 것이 중요한 경우도 있습니다.

  • 별도의 팀에서 데이터베이스 및 응용프로그램 디자인을 개발 중인 프로젝트.
  • 공통 데이터베이스를 공유하게 되는 여러 응용프로그램이 있는 프로젝트.

논리 데이터 모델을 작성하는 경우 중간 산출물 가이드라인: 데이터 모델에서 논의되는 모델 요소를 사용하여 새로 시작하거나, 분석 모델 또는 디자인 모델의 각 지속적 클래스의 엔티티로 시작할 수 있습니다.

별도의 논리 데이터 모델을 작성하지 않을 수도 있습니다(특히 단일 응용프로그램을 지원하는 데이터베이스를 디자인하는 경우). 이런 경우 데이터베이스 디자이너는 지속적 클래스 세트 및 디자인 모델의 연관성을 기반으로 실제 데이터 모델을 개발합니다.

어떤 경우의 접근 방식에서든 데이터베이스 디자이너디자이너중간 산출물: 디자인 모델에서 데이터베이스에 정보를 저장해야 하는 클래스를 식별하기 위해 분석 및 디자인 프로세스 동안 협업해야 합니다. 타스크: 클래스 디자인의 지속적 클래스 식별" 제목의 단계에서 설명된 대로 데이터베이스 디자이너는 데이터베이스의 테이블이 되는 지속적이며 잠재적인 후보 디자인 모델의 디자인 클래스를 식별하기 위해 디자이너와 협업합니다.

실제 데이터베이스 디자인 개발
목적 데이터베이스의 자세한 실제 디자인을 정의합니다.

실제 데이터베이스 디자인에는 데이터베이스의 기본 데이터 저장영역 디자인을 나타내는 데이터베이스 및 모델 요소(예: 스키마와 테이블 영역)의 자세한 실제 구조를 나타내는 모델 요소(예: 테이블, 뷰 및 스토어드 프로시저)가 포함됩니다. 전체적으로 해당 모델 요소는 데이터베이스의 실제 데이터 모델로 구성됩니다. 이 실제 데이터 모델은 중간 산출물: 데이터 모델에 포함되며 독립 모델 중간 산출물은 아닙니다.

실제 데이터베이스 디자인 개발의 자세한 단계는 다음과 같습니다.

도메인 정의

목적 재사용가능 사용자 정의 유형 정의. 

데이터베이스 디자이너는 데이터베이스 디자인에 걸친 유형 표준 실행에 도메인을 사용할 수 있습니다. 도메인은 테이블의 열에 적용 가능한 사용자 정의 데이터 유형입니다. 도메인에는 이름이 없는 열 특성이 포함됩니다.  

초기 실제 데이터베이스 디자인 요소 작성

목적 초기 데이터베이스 테이블 및 관계 작성.

데이터베이스 디자이너는 중간 산출물 가이드라인: 데이터 모델에 설명된 대로 테이블 및 테이블의 열을 사용하여 실제 데이터 모델 요소를 모델링합니다. 

논리 데이터 모델이 작성된 경우 해당 논리 엔티티는 테이블의 초기 설정의 기초로 사용될 수 있습니다.

대안으로, 데이터베이스 디자이너는 디자인 모델의 지속적 클래스를 실제 데이터 모델의 테이블 시작점으로 사용하여 실제 데이터 모델을 바로 시작할 수 있습니다. 데이터베이스 디자이너는 지속적 클래스 및 해당 속성을 테이블 및 열로 각각 모델링합니다. 데이터베이스 디자이너는 디자인 모델의 지속적 클래스의 연관을 기반으로 테이블의 연관도 정의해야 합니다. 디자인 모델 요소 및 관계가 데이터 모델 요소 및 관계에 맵핑되는 방법에 대한 설명은 중간 산출물 가이드라인: 포워드 엔지니어링 관계형 데이터베이스를 참조하십시오.

모델을 정규화된 논리 데이터 모델이 아닌 지속적 클래스에서 시작하는 경우 일반적으로 몇 가지 정규화 과정을 적용하여 데이터 중복 및 키가 아닌 다른 필드의 종속성을 제거해야 합니다. 데이터베이스 정규화에 대한 자세한 정보는 개념: 정규화를 참조하십시오.

참조 테이블 정의

목적 프로젝트에 걸쳐 사용되는 표준 참조 테이블 정의.

프로젝트에 걸쳐 사용되는 표준 찾아보기 테이블, 유효성 검증 테이블 또는 참조 테이블이 있는 경우가 있습니다. 해당 테이블의 데이터는 자주 액세스되지만 거의 변경되지 않기 때문에 데이터에 특별한 주의가 필요합니다. 디자인 모델의 해당 테이블에는 표준 제품 코드, 시/도 코드, 우편 번호, 관세표, 영역 코드 유효성 검증 테이블 또는 기타 자주 액세스하는 정보가 포함됩니다. 재무 시스템의 해당 테이블에는 정책 코드, 보험 증권 재할인율 카테고리, 전환 비율 목록이 포함됩니다. 주로 읽기 전용인 클래스의 디자인 모델에는 많은 수의 고객에 대한 유효성 검증 정보가 제공됩니다.

작은 테이블에 색인을 작성하면 실제로 추가 오버헤드가 생기므로, 참조 테이블이 작은 경우 색인을 작성하지 않는 것이 좋습니다. 캐싱 알고리즘이 자주 액세스되는 테이블을 데이터 캐시에 보관하기 때문에, 작고 자주 액세스되는 테이블도 메모리에 남아 있을 수 있습니다.

가능하면 데이터베이스 캐시는 조회 및 트랜잭션을 위한 일반 "작업 세트 영역"과 함께, 메모리에 참조되는 모든 테이블을 유지할 수 있을 정도의 크기가 좋습니다. 디스크 입출력을 줄이면 데이터베이스 성능이 향상되는 경우도 있습니다.

참조 테이블 구조가 정의되면 참조 테이블 채우기 전략을 결정하십시오. 해당 테이블은 프로젝트 초반에 액세스되기 때문에 참조 값 결정 및 테이블 로드를 상대적으로 응용프로그램 런타임 초반에 수행해야 하는 경우가 있습니다. 데이터베이스 디자이너는 데이터 확보를 책임지지는 않지만 참조 테이블이 새로 고쳐지는 방법과 시기를 결정합니다.

1차 키 및 고유 제한조건 작성

목적 테이블의 행을 고유하게 식별하는 하나 이상의 열을 정의.
데이터 또는 데이터 콜렉션의 고유성을 보장하는 열의 제한조건 정의.

1차 키는 테이블의 행을 고유하게 식별하는 하나 이상의 열입니다. 하나의 테이블에는 하나의 1차 키만 있습니다. 데이터의 행을 고유하게 식별하는데 사용되는 "자연" 키가 있는 경우가 있습니다(예: 참조 테이블의 우편 번호). 1차 키에는 비즈니스 환경에 따라 변경되는 데이터가 포함되면 안됩니다. "자연" 키가 사람 이름처럼 변경 가능한 값인 경우, 데이터베이스 디자이너는 1차 키 작성 시 의미 없고 사용자가 입력하지 않는 열을 하나 작성하는 것이 좋습니다. 이렇게 되면 비즈니스 구조, 규칙 또는 환경의 변경에 더 잘 적응할 수 있는 데이터 구조가 작성됩니다.

의미 없고 사용자가 입력하지 않는 열을 1차 키로 사용하는 것은 데이터 웨어하우스 디자인의 중요한 개념입니다. 트랜잭션 시스템은 의미 없고 사용자가 입력하지 않는 열 대신 거의 변경되지 않는 "자연" 1차 키를 선택하는 경우가 있습니다.

고유 제한조건은 열의 데이터 또는 열의 콜렉션이 행별로 고유하다고 지정합니다. 고유 제한조건이 행에 있는 경우 지정한 열의 특정 행에 있는 데이터는 동일한 열의 다른 행에 있는 데이터와 다른 값으로 고유하게 지정되어야 합니다. 

열 그룹에 대해 고유 제한조건이 정의된 경우 고유성은 해당 고유 제한조건을 구성하는 열의 전체 데이터 콜렉션을 기반으로 합니다. 특정 열의 특정 행에 있는 데이터는 동일한 열의 다른 행에 있는 데이터와 다른 값으로 고유하게 지정되지 않아도 됩니다. 데이터베이스 디자이너는 고유 제한조건을 사용하여 비즈니스 데이터의 고유성을 확보합니다.

데이터 및 참조 무결성 실행 규칙 정의

목적 데이터베이스 무결성 확인.

제한조건으로도 알려진 데이터 무결성 규칙은 데이터 값이 정의된 범위 내에 있도록 합니다. 이러한 범위가 식별 가능하면 데이터베이스는 이를 실행합니다. (데이터 유효성 검증이 응용프로그램에서 수행되어서는 안된다는 의미가 아니라, 응용프로그램이 제대로 작동되지 않는 경우 데이터베이스가 "최후 수단의 유효성 검증기"로 사용될 수 있다는 의미입니다.) 데이터 유효성 검증 규칙이 있는 경우 데이터베이스 제한조건은 해당 규칙을 실행하도록 디자인되어야 합니다.

외부 키는 다른 테이블의 1차 키에 맵핑되는 테이블의 하나 이상의 열입니다. 하나의 테이블에 여러 개의 외부 키가 있을 수 있으며 각 외부 키는 다른 테이블에 맵핑됩니다. 테이블 사이의 맵핑 또는 관계를 상위-하위 관계라고 부르기도 합니다. 하위 테이블에는 상위 테이블의 1차 키에 맵핑되는 외부 키가 포함됩니다.  

조회 최적화 프로그램이 외부 키 제한조건의 정의를 사용하여 조회 성능을 향상시키기도 합니다. 많은 경우 외부 키 수행 규칙에서 참조 테이블을 사용합니다.

성능을 위해 데이터베이스 디자인을 비정규화하여 최적화

목적 성능을 위해 데이터베이스 데이터 구조 최적화.

관계형 데이터 모델의 경우 초기 맵핑은 일반적으로 단순한 클래스에서 테이블로의 맵핑으로 작성됩니다. 다른 클래스의 오브젝트를 동시에 검색해야 하는 경우 RDBMS는 "테이블 결합" 오퍼레이션을 사용하여 해당 오브젝트와 연관된 행을 검색합니다. 자주 액세스하는 데이터인 경우 결합 오퍼레이션의 계산에 많은 비용이 들 수 있습니다. 결합 비용을 제거하기 위해 표준 관계형 기법인 "비정규화"를 사용하는 경우가 있습니다.

비정규화는 두 개 이상의 다른 테이블의 열을 동일한 테이블로 결합하여 효율적으로 정보를 사전 결합합니다. 비정규화는 비용이 덜 드는 검색 오퍼레이션을 위해 비용이 많이 드는 갱신 오퍼레이션 간의 절충을 반영합니다. 이 기법은 비정규화 테이블에 효율적으로 결합된 오브젝트 중 연관된 하나의 속성만 조회하는 조회 시스템의 성능도 저하시킵니다. 이는 보통 매 조회 시마다 모든 속성이 검색되기 때문입니다. 보통 모든 속성을 조회하는 응용프로그램의 경우 탁월한 성능 개선이 있을 수 있습니다.

세 개 이상의 테이블을 비정규화하는 경우는 드물며 삽입 및 갱신 비용이 증가되고 비결합 조회 비용도 증가됩니다. 더 큰 수익이 예상되는 경우를 아니면 비정규화를 두 개의 테이블로 제한하는 것이 좋은 정책입니다.

비정규화는 클래스가 중첩된 경우에 디자인 클래스에서 추론됩니다. 중첩된 클래스는 비정규화 테이블로 맵핑될 수 있습니다.

몇몇 오브젝트 데이터베이스에서는 비정규화와 비슷한 개념을 허용하는데, 이는 연관된 오브젝트가 디스크에 같이 클러스터되어 한번의 오퍼레이션으로 검색되는 것입니다. 사용 개념은 비슷합니다. 즉, 연관된 오브젝트를 데이터베이스에서 검색하기 위해 실행해야 하는 작업량을 줄여서 오브젝트 검색 시간을 단축시킵니다.

어떤 경우에는 데이터 모델을 최적화하여 성능 병목 현상, 미숙한 모델링 또는 불완전한 디자인을 포함한 디자인 모델의 문제점을 발견할 수 있습니다. 이러한 경우 클래스의 디자이너와 문제점을 논의하여 필요한 경우 변경 요청을 트리거할 수 있습니다.

데이터 액세스 최적화

목적 색인을 사용하여 효율적인 데이터 액세스 제공.
데이터베이스 뷰를 사용하여 효율적인 데이터 액세스 제공.

테이블 구조가 디자인되면 데이터 조회 유형을 결정해야 합니다. 색인은 데이터베이스에서 액세스 속도를 높이는 데 사용됩니다. 색인은 색인을 작성 중인 열의 데이터 값이 상대적으로 명확한 경우 가장 효율적입니다.

다음 색인 작성 원칙을 고려하십시오.

  • 테이블의 1차 키 열은 항상 색인으로 작성해야 합니다. 1차 키 열은 검색 키 및 결합 오퍼레이션으로 자주 사용됩니다.
  • 크기가 100행 미만이며 적은 열만 있는 테이블은 색인을 작성해도 별로 이득이 되지 않습니다. 작은 테이블은 일반적으로 데이터베이스 캐시에 알맞습니다.
  • 색인은 자주 실행되는 조회 또는 데이터를 빨리 검색해야 하는 조회에 대해 정의되어야 합니다(일반적으로 사용자가 기다리는 동안 완료되는 모든 검색). 색인은 검색 기준으로 같이 사용되는 각 속성 세트에 대해 정의되어야 합니다. 예를 들어 시스템에서 특정 제품이 주문된 주문을 모두 찾아야 하는 경우 제품 번호 열의 품목 테이블 색인이 필요할 수 있습니다.
  • 색인은 일반적으로 계정 잔액과 같은 숫자 값이나 주문 설명과 같은 텍스트 정보가 아닌 ID로 사용되는 열에 대해서만 정의해야 합니다. ID 열 값은 오브젝트가 작성되어 오브젝트 사용 주기 동안 변경되지 않는 경우에만 지정됩니다.
  • 단순한 숫자(정수 및 숫자 데이터 유형)에 색인을 사용하면 문자열에 색인을 사용할 때 보다 더 간편하고 빨리 검색됩니다. 조회에서 큰 데이터 볼륨을 처리하거나 결합이 많은 경우에는 이득이 커집니다. 숫자 열의 색인은 문자 색인보다 훨씬 적은 공간을 차지합니다.

그러나 색인을 사용하는 경우 잃는 것도 있습니다. 테이블의 색인을 더 많이 만들수록 삽입 및 갱신을 처리하는 데 시간이 더 오래 걸립니다. 색인 사용을 고려하는 경우 다음에 유의해야 합니다.

  • 조회가 주요 시점에서 발생하여 최대 속도를 필요로 하는 경우가 아니면, 자주 실행되지 않는 조회의 속도를 증가하기 위해 색인을 작성하지는 마십시오.
  • 어떤 시스템의 경우 갱신 및 삽입 성능이 조회 성능보다 중요할 수도 있습니다. 공통 예제로는 품질 데이터가 실시간으로 캡처되는 공장 데이터 확보 응용프로그램을 들 수 있습니다. 이러한 시스템에서는 온라인 조회만 가끔 실행되고, 대부분의 데이터는 통계적인 분석을 수행하는 일괄처리 보고 응용프로그램을 통해 주기적으로 분석됩니다. 데이터 확보 시스템의 경우 모든 색인을 제거하여 최대 처리량을 확보해야 합니다. 색인이 필요한 경우 일괄처리 보고 및 분석 응용프로그램이 실행되기 바로 전에 색인을 다시 빌드하고 보고 및 분석이 완료되면 삭제할 수 있습니다.
  • 색인 작성에는 숨겨진 비용이 있다는 점에 주의하십시오. 예를 들어 갱신(모든 삽입, 갱신 또는 삭제에 대가 지불) 시 시간이 소요되고 디스크 공간을 차지합니다. 색인 사용 시 이득이 있어야 합니다.

많은 데이터베이스에서 다양한 색인 유형을 제공합니다. 가장 공통적인 유형은 다음과 같습니다.

  • B-tree 색인-가장 자주 사용되는 유형은 밸런스 조절된 B-tree 색인 데이터 구조를 기반으로 합니다. 색인 키 값이 무작위로 분배되고 광범위한 변동을 가지는 경우 유용합니다. 성능은 좋지 않지만 색인을 작성하면 데이터가 이미 순차적인 순서로 지정됩니다.
  • 해시 색인-자주 사용되지는 않으며, 색인 키 값이 해시됩니다. 해싱은 색인 키 값의 범위를 알고 상대적으로 변경이 적으며 고유한 경우 더 나은 성능을 제공합니다. 이 기법은 키 값을 사용하여 연관 데이터의 주소를 계산하는 방식을 기반으로 하고 있습니다. 예측 가능성의 요구로 인해, 해시 색인은 거의 변경되지 않는 중간 크기의 찾아보기 테이블의 경우에만 유용합니다.

색인 전략 및 색인 작성 시기 결정은 성능에 많은 영향을 줄 수 있습니다. 대량의 데이터 로드는 색인 없이 수행되어야 합니다(이 작업은 색인을 삭제하고 데이터를 로드한 다음 색인을 다시 작성하여 수행할 수 있음). 이는 각 행이 추가될 때마다 색인 구조가 다시 밸런스되기 때문입니다. 후속 행으로 최적화된 색인 구조가 변경되므로 각 행의 추가 시 색인을 다시 밸런스 조절하는 작업은 불필요한 작업이 됩니다. 그렇기 때문에 데이터를 색인 없이 로드한 후 데이터 로드가 완료되면 색인을 다시 작성하는 것이 더 빠르고 효율적입니다. 몇몇 데이터베이스에서는 대량 데이터 로더를 제공하여 해당 작업을 자동화합니다.

데이터베이스 액세스 성능의 또 다른 최적화 전략은 뷰를 사용하는 것입니다. 데이터베이스 뷰는 가상의 테이블로 자체의 독립 저장영역이 없습니다. 호출 프로그램(또는 사용자)에게 뷰는 테이블과 같이 동작합니다. 뷰는 데이터 검색을 지원하고 데이터베이스 구조 및 데이터베이스 벤더에 따라 데이터 갱신에도 사용할 수 있습니다. 뷰에는 하나의 select 문으로 액세스할 수 있는 하나 이상의 테이블의 데이터가 포함됩니다. 데이터 선택, 특히 자주 조회되는 테이블에서 데이터 선택 시 성능 개선이 발생합니다. 데이터 검색은 데이터베이스의 여러 테이블 또는 큰 테이블을 검색하는 대신 단일 위치(뷰)에서 수행됩니다.

뷰는 데이터베이스 보안에서도 중요한 역할을 합니다. 테이블의 파트를 포함하는 뷰는 기본 테이블의 민감한 데이터 액세스를 제한할 수 있습니다.

저장영역 특성 정의

목적 데이터베이스의 공간 할당 및 디스크 페이지 조직 디자인.

데이터베이스 디자이너는 테이블 공간을 사용하여 테이블, 색인, 스토어드 프로시저 및 기타에 할당된 저장영역 공간 양을 표시합니다. 하나 이상의 테이블 공간이 데이터베이스에 맵핑됩니다. 데이터베이스 디자이너는 데이터 모델의 테이블을 분석하여 데이터베이스의 저장영역 공간에 해당 테이블과 기타 데이터베이스 요소를 분배하는 방법을 결정해야 합니다.

데이터베이스의 테이블 공간 구조 결정 시, 데이터베이스가 행, 레코드 또는 전체 테이블에서 입출력을 수행하지 않음을 고려해야 합니다. 대신 디스크 블록에서 입출력을 수행합니다. 이유는 단순합니다. 블록 입출력 오퍼레이션은 일반적으로 시스템의 소프트웨어 및 하드웨어에서 최적화됩니다. 그래서 데이터베이스의 테이블 및 색인의 실제 조직은 시스템의 성능에 많은 영향을 주게 됩니다.

데이터베이스의 공간 할당 및 디스크 페이지 조직을 계획할 때 다음 요인을 고려하십시오.

  • 디스크 페이지의 정보 밀도
  • 디스크 또는 여러 전체 디스크의 디스크 페이지 위치
  • 테이블에 할당되는 디스크 공간 크기

이러한 요인은 다음 섹션에서 논의됩니다.

디스크 페이지 밀도

디스크 페이지 밀도는 시간에 따라 예상되는 데이터 변경 정도에 따라 달라집니다. 기본적으로 밀도가 낮은 페이지는 이후의 값 변경 또는 추가 데이터를 더 많이 허용할 수 있지만 밀도가 높은 데이터 페이지는 읽는 블록당 검색되는 데이터가 더 많기 때문에 읽기 성능은 훨씬 좋습니다.

디스크 관리를 단순화하기 위해 데이터베이스 디자이너는 예상되는 변경 정도별로 테이블을 그룹화할 수 있습니다. 다음 세 그룹은 이런 유형의 조직에 적당한 시작이 됩니다.

  • 매우 동적인 테이블
  • 다소 동적인 테이블
  • 대체로 정적인 테이블

매우 동적인 테이블은 디스크 페이지의 빈 공간이 가장 많은 디스크 페이지로 맵핑되어야 합니다(30% 정도). 다소 동적인 테이블은 빈 공간이 이보다 적은 디스크 페이지로 맵핑되어야 합니다(15% 정도). 대체로 정적인 테이블은 거의 빈 공간이 없는 디스크 페이지로 맵핑되어야 합니다(5% 정도). 테이블 색인도 비슷하게 맵핑되어야 합니다.

디스크 페이지 위치

테이블 그룹이 맵핑된 후에 데이터베이스 디자이너는 디스크 페이지 위치를 결정해야 합니다. 위치 결정은 다른 드라이브 간의 워크로드의 밸런스를 조절하고 병목 현상을 줄이거나 없애기 위해서 필요합니다. 다음 가이드라인을 고려하십시오.

  • 데이터를 운영 체제, 운영 체제의 임시 파일 또는 스왑 장치와 동일한 디스크에 위치시키지 마십시오. 이러한 드라이브는 워크로드를 추가하지 않아도 이미 매우 부지런히 사용되고 있습니다.
  • 동시에 액세스되는 데이터를 다른 드라이브에 위치시켜서 워크로드의 밸런스를 유지하십시오. 몇몇 시스템은 병렬 입출력 채널을 지원합니다. 이런 경우에는 데이터를 다른 채널에 위치 시키십시오.
  • 워크로드 분산을 위해 색인 대상 데이터와 다른 드라이브에 색인을 위치시키십시오.
  • 가이드라인은 데이터베이스 벤더의 문서를 참조하십시오.
  • 사용하는 저장영역 유형(예: RAID-5, RAID-10, SAN, NAS 및 채널 부착형)은 데이터베이스 성능에 영향을 줍니다. 저장영역 제공업체에서 제공한 성능 가이드라인을 사용하십시오.

데이터베이스 입출력은 일반적으로 데이터베이스 성능의 제한 요인입니다. 입출력 밸런스 조절은 반복적이며 실험적인 프로세스입니다. 정제(Elaboration) 단계에서 적절한 인스트루먼테이션과 결합하여 실제 입출력 및 논리 입출력을 모니터하도록 데이터베이스 액세스 성능의 프로토타입을 생성하여 데이터베이스 디자인 조정이 가능할 때 미리 성능 문제점을 발견할 수 있습니다.

디스크 공간 할당

지속성 디자인 메커니즘의 특성을 사용하여 저장해야 하는 오브젝트의 수를 예상하십시오. 오브젝트 저장에 필요한 디스크 공간의 양은 RDBMS에 따라 달라집니다. 디스크 공간을 계산할 때 데이터 추가에 따른 확장도 고려해야 합니다. 데이터베이스의 디스크 공간을 예상하려면, 먼저 각 테이블에 필요한 디스크 공간을 예상하고 전체 테이블에 필요한 공간을 계산하십시오. 특정 RDBMS 제품의 데이터베이스 관리자 매뉴얼을 참조하여 정확한 크기 예상 공식을 결정하십시오. 다음은 테이블에 필요한 공간 예상에 필요한 일반적인 몇 가지 단계입니다.

  • 평균 행 크기를 계산하십시오. 행 크기 계산에는 레코드 레벨의 모든 제어 정보 및 가변 길이 열에 필요한 모든 제어 정보도 포함해야 합니다.
  • 페이지 또는 입출력 블록에 맞는 행의 수를 계산하십시오. 대부분의 데이터베이스는 페이지 또는 입출력 블록의 완전한 레코드만 저장하기 때문에 행의 수는 페이지 또는 입출력 블록에 맞는 행의 정수값이어야 합니다.
  • 데이터베이스 레코드의 예상 수를 저장하는 데 필요한 페이지 또는 입출력 블록의 수를 계산합니다. 레코드 예상 수치에는 모든 로드 요인이 포함되어야 합니다.
  • 페이지 또는 입출력 블록의 크기에 필요한 페이지 또는 입출력 블록 수를 곱하십시오.
  • 색인 추가에 필요한 모든 오버헤드를 추가하십시오.
  • 테이블의 고정된 오버헤드를 추가하십시오.

테이블 공간 요구사항이 정의되면 다음을 수행하십시오.

  • 테이블에 필요한 공간 합계를 계산하십시오.
  • 데이터베이스 관리 공간에 필요한 전체 고정된 양을 추가하십시오.
  • 트랜잭션 로그 및 감사 추적에 필요한 디스크 공간을 추가하십시오. 

자주 갱신되는 환경에서는 감사 추적 유지 요구사항에 많은 저장영역 공간이 필요합니다. 주요 상용 데이터베이스 관리 시스템 문서에서는 자세한 크기에 대한 지시사항을 제공하고 있습니다. 데이터베이스 디스크 공간 요구사항 예상량을 계산할 때 해당 지시사항을 반드시 참조하십시오.

클래스 동작을 데이터베이스에 분배하도록 스토어드 프로시저 디자인

목적 데이터 액세스 클래스 오퍼레이션 구현에 스토어드 프로시저 또는 트리거 사용 여부 결정.

대부분의 데이터베이스는 스토어드 프로시저 기능을 지원합니다. 스토어드 프로시저는 데이터베이스 관리 시스템의 프로세스 공간에서 실행되는 실행 가능 코드입니다. 이는 데이터를 네트워크로 전송하지 않고도 서버에서 데이터베이스와 연관된 조치를 수행할 수 있도록 해주는 기능을 제공합니다. 스토어드 프로시저를 알맞게 사용하는 경우 시스템 성능을 개선할 수 있습니다.

스토어드 프로시저는 일반적으로 실제 프로시저 또는 트리거의 두 가지 유형 중 하나입니다. 프로시저는 응용프로그램에서 명시적으로 수행되며 일반적으로 매개변수를 포함하고 있으며 명시적인 리턴값을 제공합니다. 반면에 트리거는 임의의 데이터베이스 이벤트가 발생할 때(예: 행 삽입, 행 갱신, 또는 행 삭제) 내재적으로 호출되고 수정 중인 행 이외의 매개변수를 포함하지 않으며(수정 중인 행은 내재적으로 호출되기 때문) 명시적인 리턴값을 제공하지 않습니다.

제한조건이 없는 데이터베이스 시스템에서 참조 및 데이터 무결성 실행에 트리거를 사용하는 경우가 있습니다. 또는 이벤트에서 다른 이벤트를 트리거해야 하는 경우(또는 다른 이벤트를 발생시키는 경우)에 사용되기도 합니다. 트리거는 트리거 이벤트를 감사하는 보안 목적으로도 자주 사용됩니다.

디자인 모델의 디자인 클래스는 스토어드 프로시저 또는 트리거를 사용하여 구현해야 하는 오퍼레이션이 있는지 여부를 확인하기 위해 점검되어야 합니다. 후보에는 다음이 포함됩니다.

  • 주로 지속적 데이터를 처리하는 모든 오퍼레이션(데이터 작성, 갱신, 검색 또는 삭제).
  • 계산에 연관된 조회의 모든 오퍼레이션(예: 재고에 있는 제품의 평균 수량 및 값 계산).
  • 데이터의 유효성을 검증하기 위해 데이터베이스에 액세스해야 하는 오퍼레이션.

일반적으로 데이터베이스 성능이 개선되면 입출력이 감소됩니다. 따라서 DBMS 서버에서 계산을 수행하면 네트워크로 전송되는 데이터 양이 감소할 경우 계산을 서버에서 수행해야 합니다.

디자인 클래스 디자이너와 함께 성능 개선을 위한 데이터베이스 사용 방법을 논의하십시오. 디자이너는 오퍼레이션 메소드를 갱신하여 하나 이상의 스토어드 프로시저가 오퍼레이션 구현에 사용되는지 여부를 나타냅니다.

결과 검토
목적 데이터 모델의 품질 및 무결성 확인.

이 타스크의 전반에 걸쳐 지속적으로 체크리스트: 데이터 모델을 고려하여 노력의 완전성 및 품질을 평가해야 합니다. 또한 데이터베이스 디자이너는 데이터베이스 구현 구조를 규칙적으로 검토하여 데이터 모델이 데이터베이스에 직접적으로 적용된 모든 변경과 일관성이 유지되도록 해야 합니다. 프로젝트에서 데이터베이스 실제 구조와 데이터 모델의 동기화를 지원하는 데이터 모델링 도구를 사용하는 경우 데이터베이스 디자이너는 데이터베이스의 데이터 모델 상태를 주기적으로 확인하여 필요한 경우 조정을 수행해야 합니다. 

현재 수정되지 않은 알려진 결함은 변경 요청에 문서화하고, 담당자를 배정하여 해결해야 합니다.

특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보