활동:
|
목적
|
|
역할: 데이터베이스 설계자 | |
빈도: 각 반복당 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: |
워크플로우 세부사항: |
이 활동에 표시된 단계는 어플리케이션의 지속적 데이터 설계가 관계형 데이터베이스 관리 시스템(RDBM)을 사용하여 구현됨을 가정합니다. 사용자가 [DAT99]와 같은 참조에서 다룬 데이터베이스 용어뿐 아니라 표준화 및 비표준화를 포함하여 데이터베이스 개념에 익숙하다고 가정합니다.
이 활동의 단계는 데이터베이스 모델링의 UML 프로파일 또한 참조하며, 이는 [NBG01]에서 설명합니다. 또한 [NBG01]은 UML을 사용하여 관계형 데이터베이스를 모델링하고 설계하는 프로세스의 일반 설명을 포함합니다. 관계형 데이터 모델 및 객체 모델 간 관계에 대한 백그라운드 정보는 개념: 관계형 데이터베이스 및 객체 지향을 참조하십시오.
목적 | 데이터베이스의 논리적 설계 모델을 정의하기 위함입니다. |
논리적 데이터 모델의 목적은 임의의 특정 소프트웨어 또는 데이터베이스 구현에 독립적인 주요 논리적 데이터 항목 및 관계의 이상적 보기를 제공하기 위함입니다. 일반적으로 세 번째 정상 양식(개념: 표준화 참조)으로 되어 있으며, 이는 중복을 최소화하고 추이 종속성을 확인하는 데이터 모델링 양식입니다. 이러한 모델은 데이터 및 해당 성능을 사용하는 어플리케이션보다는 데이터 캡처시 데이터베이스가 표시되는 상태에 관여합니다. 논리 데이터 모델이 결과물: 데이터 모델의 일부로 간주되며 별도의 RUP 결과물이 아님을 참고하십시오. 그러나 종종 다음을 위해 개별 논리 데이터 모델을 정의하는 것이 중요합니다.
논리 데이터 모델을 작성 중인 경우, 가이드라인: 데이터 모델에서 설명된 모델 요소를 사용하여 스크래치에서 시작하거나 분석 모델 또는 설계 모델의 각 지속적 클래스의 엔티티를 시동하여 시작할 수 있습니다.
특히 단일 어플리케이션에 사용하는 데이터베이스를 설계 중인 경우, 별도의 논리 데이터 모델을 작성하지 않도록 결정할 수도 있습니다. 이런 경우, 데이터베이스 설계자가 설계 모델의 지속적 클래스 및 해당 연관 세트를 기반으로 실제 데이터 모델을 개발합니다.
어느 방식으로든 데이터베이스 설계자 및 설계자가 분석 및 설계 프로세스 전반에 걸쳐 공동 연구하여 데이터베이스에 정보를 저장해야 하는 결과물: 설계 모델의 클래스를 식별하는 것이 중요합니다. "활동: 클래스 설계의 지속적 클래스 식별" 단계에 설명된 대로 데이터베이스 설계자가 설계자와 함께 작업하여 지속적으로 간주되고 데이터베이스의 테이블이 될 잠재적 후보인 설계 모델의 설계 클래스를 식별합니다.
목적 | 데이터베이스의 자세한 실제 설계를 정의하기 위함입니다. |
실제 데이터베이스 설계는 데이터베이스의 자세한 실제 구조를 표시하는 모델 요소(예: 테이블, 보기 및 저장 프로시저)와 데이터베이스의 하위 데이터 저장영역 설계를 표시하는 모델 요소(예: 스키마 및 테이블 공간)를 포함합니다. 집합적으로 이러한 모델 요소는 데이터베이스의 실제 데이터 모델로 구성됩니다. 이 실제 데이터 모델은 결과물: 데이터 모델에 포함되며 별도의 모델 결과물이 아닙니다.
실제 데이터베이스 설계 개발의 자세한 단계는 다음과 같습니다.
목적 | 재사용 가능한 사용자 정의 유형을 정의하기 위함입니다. |
도메인은 데이터베이스 설계 전반에 걸쳐 유형 표준을 시행하도록 데이터베이스 설계자에 의해 사용될 수 있습니다. 도메인은 테이블의 열에 적용될 수 있는 사용자 정의 데이터 유형입니다. 도메인에는 이름 없이 열의 등록 정보가 있습니다.
목적 | 초기 데이터베이스 테이블 및 관계를 작성하기 위함입니다. |
데이터베이스 설계자가 가이드라인: 데이터 모델에 설명된 대로 테이블의 열 및 테이블을 사용하여 실제 데이터 모델 요소를 모델화합니다.
논리 데이터 모델이 작성되면 논리적 엔티티가 테이블의 초기 세트에 대한 기초로 사용될 수 있습니다.
대안으로, 데이터베이스 설계자가 설계 모델의 지속적 클래스를 실제 데이터 모델의 테이블에 대한 시작 위치로 사용하여 실제 데이터 모델을 시작할 수도 있습니다. 데이터베이스 설계자가 지속적 클래스와 해당 속성을 각각 테이블과 열로 모델화합니다. 데이터베이스 설계자는 설계 모델의 지속적 클래스 간 연관을 기반으로 테이블 간 관계도 정의해야 합니다. 설계 모델 요소 및 관계가 데이터 모델 요소 및 관계에 맵핑되는 방법의 설명은 가이드라인: 엔지니어링 관계형 데이터베이스 전달에 제공됩니다.
표준화된 논리 데이터 모델이 아니라 지속적 클래스에서 모델을 시작 중인 경우, 일반적으로 데이터 중복 및 주요하지 않은 필드 종속성을 제거하도록 일부 표준화를 적용해야 합니다. 데이터베이스 표준화에 대한 자세한 정보는 개념: 표준화를 참조하십시오.
목적 | 프로젝트 전반에 걸쳐 사용되는 표준 참조 테이블을 정의하기 위함입니다. |
종종 프로젝트 내내 사용하는 참조 테이블, 유효성 검증 테이블 또는 표준 찾아보기 테이블이 있습니다. 해당 테이블의 데이터가 자주 액세스되지만 거의 변경되지 않는 경향이 있으므로 데이터는 특별히 고려할 가치가 있습니다. 설계 모델에서 해당 테이블에 표준 제품 코드, 주 또는 도 코드, 우편번호, 세금 테이블, 지역 번호 유효성 테이블 또는 기타 자주 액세스되는 정보가 포함될 수 있습니다. 재정 시스템에서 이러한 테이블에는 정책 코드, 보험 정책 등급 범주 또는 변환 비율이 포함될 수 있습니다. 설계 클래스에서 주로 읽기 전용인 클래스를 찾아 대다수 클라이언트에 유효성 확인 정보를 제공하십시오.
참조 테이블이 작은 경우, 해당 테이블을 색인화하려고 하지 마십시오. 왜냐하면 색인화로 인해 사실상 작은 테이블에 추가 오버헤드가 추가될 수 있기 때문입니다. 캐싱 알고리즘이 데이터 캐시에 자주 액세스되는 테이블을 유지하므로 작고 자주 액세스되는 테이블은 메모리에 남아 있는 경향이 있습니다.
가능한 경우, 데이터베이스 캐시가 조회 및 트랜잭션의 일반 "작업 세트 공간"과 함께 모든 참조 테이블을 메모리에 유지할 만큼 큰지 확인하십시오. 데이터베이스 성능을 증가시키는 비결은 종종 디스크 I/O를 감소시킵니다.
참조 테이블 구조가 정의되고 나면 참조 테이블을 채울 전략을 판별하십시오. 이러한 테이블은 거의 프로젝트 시작부터 액세스되므로 참조값 판별과 테이블 로드는 종종 비교적 어플리케이션 런타임 초기에 발생해야 합니다. 데이터베이스 설계자에게 데이터베이스 획득에 대한 책임이 없는 반면 참조 테이블이 새로 고치기될 시기 및 방법을 판별하는 책임이 있습니다.
목적 | 테이블의 열을 고유하게 식별하는 하나 이상의 열을 정의하기
위함입니다. 데이터의 고유함 또는 데이터의 콜렉션을 보증하는 열에 제한조건을 정의하기 위함입니다. |
1차 키는 테이블의 행을 고유하게 식별하는 하나 이상의 열입니다. 테이블에는 단일 1차 키가 있습니다. 종종 데이터 행을 고유하게 식별하는데 사용할 수 있는 "자연" 키가 있습니다(예: 참조 테이블의 우편 번호). 1차 키는 비즈니스 환경에 따라 변경될 수 있는 데이터를 포함하지 않아야 합니다. "자연" 키가 변경될 수 있는 값인 경우(예: 개인 이름) 데이터베이스 설계자가 1차 중요한 작성시 하나의 의미없는 비사용자 입력 열을 작성하도록 권장합니다. 이로써, 비즈니스 구조, 규칙 또는 환경의 변경사항에 대해 보다 나은 적용성이 있는 데이터 구조가 작성됩니다.
1차 키로 의미없는 비사용자 입력 열의 사용은 데이터 웨어하우스 설계의 주요한 개념입니다. 트랜잭션 시스템은 종종 의미없는 비사용자 입력 열에 대해 아주 적게 변경될 수 있는 "자연" 1차 키를 선택합니다.
고유 제한조건이 열에 있는 데이터 또는 열의 콜렉션이 행당 고유함을 지정합니다. 고유 제한조건이 열에 있는 경우, 지정한 열의 특정 행에 있는 데이터가 동일한 열의 다른 행에 있는 데이터로부터 고유해야 합니다.
고유 제한조건이 열 그룹에 대해 정의된 경우, 고유성이 해당 고유 제한조건을 형성하는 열의 집합적인 전체 데이터를 기반으로 합니다. 특정 열의 특정 행에 있는 데이터는 동일한 열의 다른 행에 있는 데이터와 달리 고유할 필요가 없습니다. 데이터베이스 설계자가 고유 제한조건을 사용하여 비즈니스 데이터의 고유성을 확인합니다.
목적 | 데이터베이스의 무결성을 확인하기 위함입니다. |
제한조건으로도 알려져 있는 데이터 무결성 규칙은 데이터 값이 정의된 범위 내에 있는지 확인합니다. 이러한 범위가 식별될 수 있는 경우에 데이터베이스가 해당 범위를 시행합니다. (이는 데이터 유효성 확인이 어플리케이션에서 수행되지 않아야 함을 의미하는 것이 아니라 데이터베이스가 어플리케이션이 제대로 작동하지 않는 이벤트에서 "최종 의뢰의 유효성 확인자"역할을 할 수 있음을 의미합니다.) 데이터 유효성 확인 규칙이 있는 경우, 데이터베이스 제한조건이 해당 규칙을 시행하도록 설계되어야 합니다.
외부 키는 다른 테이블에서 1차 키에 맵핑되는 테이블의 하나 이상의 열입니다. 한 테이블에 여러 외부키가 있을 수도 있으며 각 외부 키는 다른 테이블에 대한 맵입니다. 테이블 간 맵핑 또는 관계가 종종 상-하위 관계로 표시됩니다. 하위 테이블에는 외부 키가 포함되어 있어 상위 테이블의 1차 키에 맵핑됩니다.
외부 중요한 제한사항의 정의 또한 종종 조회 최적화 프로그램에 의해 조회 성능을 가속시키는데 사용됩니다. 여러 경우에 외부 중요한 시행 규칙이 참조 테이블을 사용합니다.
목적 | 데이터베이스 데이터 구조를 성능에 최적화하기 위함입니다. |
관계형 데이터 모델의 경우, 일반적으로 초기 맵핑이 단순한 클래스와 테이블 맵핑을 초래합니다. 다른 클래스의 객체가 동시에 검색되어야 하는 경우, RDBMS가 "테이블 결합"이라는 조작을 사용하여 관심있는 객체와 관련된 행을 검색합니다. 자주 액세스되는 데이터의 경우, 결합 조직이 컴퓨터 사용면에서 비용이 많이 들 수 있습니다. 결합의 비용을 제거하도록 "비표준화"라는 표준 관계형 기술이 종종 채택됩니다.
비표준화가 두 개 이상의 다른 테이블에서 동일한 테이블로 열을 결합하여 효율적으로 정보를 사전 결합합니다. 비표준화가 보다 덜 비용이 드는 검색 조작을 위해 보다 비용이 드는 갱신 조작 간 트레이드오프를 반영합니다. 이 기술이 또한 비표준화 테이블에 효율적으로 결합하는 객체 중 하나의 속성에만 관여하는 조회의 시스템 성능을 감소시킵니다. 왜냐하면 일반적으로 모든 속성이 모든 조회에서 검색되기 때문입니다. 일반적으로 어플리케이션이 모든 속성을 원하는 경우 상당한 성능 개선이 있을 수 있습니다.
세 테이블 이상의 비표준화는 드문 경우이며 비결합 조회의 비용뿐 아니라 삽입 및 갱신의 비용도 증가시킵니다. 비표준화를 두 테이블에 한정하는 것은 수익성과 관련하여 강하고 확신하는 증거가 작성되지 않는 한 좋은 정책입니다.
비표준화는 클래스가 중첩된 경우에 설계 클래스에서 추론될 수 있습니다. 중첩 클래스는 비표준화 테이블로 맵핑될 수 있습니다.
일부 객체 데이터베이스는 비표준화와 유사한 개념을 허용하며, 이로써 관련 객체가 디스크에서 함께 군집되고 단일 조작으로 검색됩니다. 사용 개념은 다음과 유사합니다. 시스템이 데이터베이스에서 관련 객체를 검색하도록 수행해야 하는 작업을 줄여 객체 검색 시간을 줄입니다.
일부 경우에, 데이터 모델 최적화가 성능 병목 현상, 형편없는 모델링 또는 불완전한 설계를 포함하여 설계 모델의 문제점을 밝혀냅니다. 이 이벤트에서 클래스의 설계자와 문제점을 상의하여 적절한 경우 변경 요청을 시작하십시오.
목적 | 색인 작성을 사용하여 효율적인 데이터 액세스를 제공하기 위함입니다. 데이터베이스 보기를 사용하여 효율적인 데이터 액세스를 제공하기 위함입니다. |
테이블 구조가 설계되고 나면 데이터에 대해 수행되어야 할 조회 유형을 판별해야 합니다. 색인 작성은 액세스의 속도를 높이도록 데이터베이스가 사용합니다. 색인 작성 중인 열의 데이터 값이 비교적 명료한 경우 색인 작성이 가장 효율적입니다.
다음 색인 작성 원칙을 고려하십시오.
아래쪽에서 색인의 사용은 무료가 아닙니다. 테이블의 색인이 더 많을수록 삽입과 갱신이 처리되는데 오래 걸립니다. 색인의 사용 계획시 다음 주의사항을 명심하십시오.
여러 데이터베이스가 색인 유형의 선택을 제공합니다. 가장 공통된 유형에는 다음이 포함됩니다.
색인 작성 전략 선택 및 색인 작성의 타이밍은 성능에 큰 영향을 미칠 수 있습니다. 대량의 데이터 로드는 색인없이 수행되어야 합니다(이는 색인을 제거하고 데이터를 로드한 다음 색인을 다시 작성하여 달성될 수 있음). 이 이유는 각 행이 추가됨에 따라 색인 구조가 다시 밸런스되기 때문입니다. 후속 행이 최적 색인 구조를 변경하므로 각 행이 삽입됨에 따라 다시 밸런스 맞추기를 완료한 작업이 상당히 낭비됩니다. 색인없이 데이터를 로드한 다음 데이터 로드가 완료되면 색인을 다시 작성하는 것이 보다 빠르고 효율적입니다. 일부 데이터베이스가 대량 데이터 로더를 제공하여 이를 자동으로 수행합니다.
데이터베이스 액세스 성능을 최적화하는 또다른 전략은 보기의 사용입니다. 데이터베이스 보기는 고유의 독립적 저장영역이 없는 가상 테이블입니다. 그러나 호출 프로그램(또는 사용자)에 대해 보기가 테이블과 같이 작동합니다. 보기가 데이터의 검색을 지원하며 데이터 구조 및 데이터 벤더에 따라 데이터를 갱신하는데도 사용할 수 있습니다. 보기에는 단일 select문을 통해 액세스할 수 있는 하나 이상의 테이블에서의 데이터가 포함됩니다. 성능 증진은 특히 자주 조회되는 테이블에서 데이터를 선택하는 동안 발생합니다. 데이터는 데이터베이스에 있는 여러 또는 보다 큰 테이블에서 검색하는 대신 단일 위치, 보기에서 검색됩니다.
보기는 데이터베이스 보안에 있어 중요한 역할도 합니다. 테이블의 파트를 포함하는 보기가 기본 테이블에 포함된 의존 데이터에 대한 액세스를 제한할 수 있습니다.
목적 | 데이터베이스의 디스크 페이지 조작 및 공간 할당을 설계하기 위함입니다. |
데이터베이스 설계자가 테이블 공간을 사용하여 테이블, 색인, 저장 프로시저 등에 할당된 저장영역 공간의 양을 표시합니다. 하나 이상의 테이블 공간이 데이터베이스에 맵핑됩니다. 데이터베이스 설계자가 데이터 모델의 테이블을 분석하여 기타 지원 데이터베이스 요소와 함께 해당 테이블을 데이터베이스의 저장 공간에 걸쳐 분배하는 방법을 판별합니다.
데이터베이스의 테이블 공간 구조 판별시, 데이터베이스가 행, 레코드 또는 전체 테이블에서 I/O를 수행하지 않음을 명심하십시오. 대신, 디스크 블록에서 I/O를 수행합니다. 그 이유는 다음과 같이 단순합니다. 블록 I/O 조작은 일반적으로 시스템의 소프트웨어와 하드웨어에서 최적화됩니다. 결과적으로, 데이터베이스의 테이블 및 색인의 실제 조직이 시스템 성능에 대단한 영향을 미칠 수 있습니다.
데이터베이스의 디스크 페이지 조직 및 공간 할당 계획시, 다음 인수를 고려하십시오.
이러한 인수는 다음과 같은 섹션에서 설명됩니다.
디스크 페이지 밀도
디스크 페이지의 밀도는 시간 경과에 따라 변경될 데이터의 범위에 따라 달라집니다. 기본적으로, 덜 조밀한 페이지가 값의 변화 또는 시간이 경과함에 따른 데이터의 추가를 더 잘 승인할 수 있습니다. 반면에, 가득찬 데이터 페이지는 블록 읽기당 더 많은 데이터가 검색되므로 다 나은 읽기 성능을 제공합니다.
디스크 관리를 단순화하도록 데이터베이스 설계자가 변경 가능한 범위별로 테이블을 그룹화할 수 있습니다. 다음 세 그룹이 이 유형의 조직에 좋은 시작을 이룹니다.
- 매우 동적인 테이블
- 약간 동적인 테이블
- 대부분 정적인 테이블
매우 동적인 테이블이 상당한 양의 빈 공간이 있는(30% 가량) 디스크 페이지에 맵핑되어야 합니다. 약간 동적인 테이블은 빈 공간이 덜 있는(15%가량) 디스크 페이지에 맵핑되어야 하며 대부분 정적인 테이블은 빈 공간이 거의 없는(5% 가량) 디스크 페이지에 맵핑되어야 합니다. 해당 테이블에 대한 색인이 유사하게 맵핑되어야 합니다.
디스크 페이지 위치
테이블의 그룹이 맵핑된 다음 데이터베이스 설계자가 디스크 페이지를 두어야 할 위치를 판별해야 합니다. 여기서 목표는 여러 다른 드라이브와 헤드에 걸쳐 워크로드의 밸런스를 맞추어 병목 현상을 줄이거나 없애기 위함입니다. 다음 가이드라인을 고려하십시오.
- 데이터를 운영 체제, 임시 파일 또는 스왑 장치와 동일한 디스크에 절대 두지 마십시오. 이러한 드라이브는 추가 워크로드없이도 충분히 사용 중입니다.
- 워크로드의 밸런스를 맞추도록 동시에 액세스되는 데이터를 다른 드라이브에 두십시오. 일부 시스템이 평행 I/O 채널을 지원합니다. 이런 경우, 데이터를 다른 채널에 두십시오.
- 워크로드를 전개하기 위해 색인화하는 데이터와 다른 드라이브에 색인을 두십시오.
- 가이드라인은 데이터베이스 벤더의 문서를 참조하십시오.
- 사용된 저장영역 유형(예: RAID-5, RAID-10, SAN, NAS 및 첨부된 채널)이 데이터베이스 성능에 영향을 줍니다. 저장영역 제공업체가 제공하는 성능 가이드라인을 사용하십시오.
데이터베이스 I/O는 일반적으로 데이터베이스 성능의 제한 요인입니다. I/O 밸런스 맞추기는 반복적이고 실험적인 프로세스입니다. 구현화 단계 중에 실제 및 논리 I/O를 모니터할 적절한 수단과 함께 데이터베이스 액세스 성능을 프로토타입화하여 데이터베이스 설계를 조정할 시간이 아직 있는 동안 일찍 성능 문제점을 밝힐 수 있습니다.
디스크 공간 할당
지속성 설계 메커니즘의 특성을 사용하여 저장해야 하는 객체의 수를 추정하십시오. 객체 저장에 필요한 디스크 공간의 양은 RDBMS에서 RDBMS로 다양합니다. 디스크 공간 계산시, 데이터 추가로 인한 증대를 설명하도록 하십시오. 데이터베이스의 디스크 공간을 추정하려면 우선 각 테이블에 필수인 디스크 공간을 추정한 다음 모든 테이블에 대한 공간 요구사항을 계산하십시오. 특정 RDBMS 제품용 데이터베이스 관리자 매뉴얼을 참조하여 정확한 크기 산출 공식을 판별하십시오. 여기에 테이블에 필요한 공간을 산출하는 일반적 단계가 있습니다.
- 평균 행 크기를 계산하십시오. 이 계산에는 레코드 레벨에서의 임의의 제어 정보뿐 아니라 변동 가능 길이 열에 필수인 임의의 정보도 포함해야 합니다.
- 페이지 또는 I/O 블록에 적합한 행의 수를 계산하십시오. 대부분의 데이터베이스가 페이지 또는 I/O 블록에 완료된 레코드만을 저장하므로 페이지 또는 I/O 블록에 적합한 행의 정수여야 합니다.
- 데이터베이스의 추정 레코드 수를 저장하는데 필수인 페이지 또는 I/O 블록의 수를 계산하십시오. 레코드의 추정 수에는 임의의 로드 인수가 포함되어야 합니다.
- 필수 페이지 또는 I/O 블록의 수와 페이지 또는 I/O 블록의 크기를 곱하십시오.
- 추가 색인의 모든 오버헤드를 추가하십시오.
- 테이블의 모든 고정 오버헤드를 추가하십시오.
테이블 공간 요구사항이 정의되고 나면 다음을 수행하십시오.
- 테이블에 필요한 공간의 합을 계산하십시오.
- 데이터베이스 관리에 필수인 임의의 고정된 공간 크기를 추가하십시오.
- 트랜잭션 로그 및 감사 추적에 필수인 디스크 공간을 추가하십시오.
자주 갱신되는 환경에서 감사 추적의 보유 요구사항은 상당한 양의 저장영역을 필수로 합니다. 주요 상업 데이터베이스 관리 시스템의 문서가 일반적으로 자세한 크기 지정 지시사항을 제공합니다. 데이터베이스 디스크 공간 요구사항의 추정 계산시 이러한 지시사항을 참조하도록 하십시오.
목적 | 저장된 프로시저 또는 트리거가 데이터 액세스 클래스 조작 구현에 사용되어야 하는지를 판별하기 위함입니다. |
대부분의 데이터베이스가 저장된 프로시저 성능을 지원합니다. 저장된 프로시저는 데이터베이스 관리 시스템의 프로세스 공간 내에서 실행하는 실행 가능 코드입니다. 데이터를 네트워크 상에서 전송하지 않고 서버에서 데이터베이스 관련 조치를 수행하는 능력을 제공합니다. 저장된 프로시저의 현명한 사용은 시스템의 성능을 향상시킬 수 있습니다.
저장된 프로시저는 일반적으로 다음 두 유형, 실제 프로시저 또는 트리거, 중 하나입니다. 프로시저는 어플리케이션이 명시적으로 실행하며 일반적으로 매개변수가 있고 명시적 리턴값을 제공합니다. 한편, 트리거는 일부 데이터베이스 이벤트가 발생하고(예: 행 삽입, 행 갱신 또는 행 삭제) 수정 중인 행 이외에 매개변수가 없으며(내재적으로 호출되므로) 명시적 리턴값을 제공하지 않는 경우 내재적으로 호출됩니다.
제한조건이 결여된 데이터베이스 시스템에서 트리거는 종종 참조용 및 데이터 무결성을 강제 실행하는데 사용됩니다. 그렇지 않으면 이벤트가 다른 이벤트를 트리거(또는 유발)해야 하는 경우 사용되는 경향이 있습니다. 트리거는 또한 트리거 이벤트를 감사하여 보안 용도로자주 사용됩니다.
설계 모델의 설계 클래스는 저장된 프로시저 또는 트리거 기능을 사용하여 구현되어야 하는 조작이 있는지 확인하기 위해 검사되어야 합니다. 후보에는 다음이 포함됩니다.
데이터베이스 성능의 향상은 일반적으로 I/O의 감소를 의미함을 기억하십시오. 그러므로 DBMS 서버에서의 계산 수행이 네트워크 상에서 전달된 데이터의 양을 감소시키는 경우 계산이 서버에서 수행되어야 할 가능성이 있습니다.
설계 클래스의 설계자와 함께 작업하여 성능 개선에 데이터베이스가 사용될 수 있는 방법을 의논하십시오. 설계자가 조작 메소드를 갱신하여 하나 이상의 저장된 프로시저가 조작을 구현하는데 사용될 수 있는지 여부를 표시합니다.
목적 | 데이터 모델의 품질 및 무결성을 확인하기 위함입니다. |
계속적으로 이 활동 전반에 걸쳐 체크포인트: 데이터 모델을 고려하여 노력의 완성 및 품질을 평가해야 합니다. 더우기, 데이터베이스 설계자는 정규적으로 데이터베이스의 구현 구조를 검토하여 데이터 모델이 데이터베이스에서 직접 작성된 모든 변경사항과 일관되는지 확인해야 합니다. 프로젝트가 데이터베이스의 실제 구조로 데이터 모델의 동기화를 지원하는 데이터 모델링 도구를 사용하는 경우, 데이터베이스 설계자가 데이터베이스로 데이터 모델의 상태를 주기적으로 점검하고 필요한 대로 조정을 해야 합니다.
이번에 정정되지 않을 식별된 결함은 변경 요청에 문서화되어 결국 솔루션을 소유 및 진행할 사람에게 지정되어야 합니다.
![]() |
이 컨텐츠는 Applied Information Science에 의해 부분적으로 개발 또는 전적으로 개발되었습니다. |
Rational Unified Process
|