가이드라인: 데이터 모델
데이터 모델은 시스템에서 사용하는 지속적 데이터 스토어의 디자인을 캡처합니다. 이 가이드라인은 데이터 모델링과 RUP에서의 사용 방법에 대해 설명합니다.
관계
기본 설명

개요

데이터 모델은 시스템에서 사용하는 지속적 데이터 스토어의 구조를 디자인하는 데 사용됩니다. 데이터베이스 디자인의 UML(Unified Modeling Language) 프로파일은 데이터베이스 디자이너에게 모델링 요소 세트를 제공합니다. 이 모델링 요소는 데이터베이스에서 테이블의 자세한 디자인을 개발하고 데이터베이스의 실제 저장영역 레이아웃을 모델링하는 데 사용할 수 있습니다. UML 데이터베이스 프로파일에서는 참조 무결성(제한조건 및 트리거) 및 데이터베이스에 대한 액세스를 관리하는 데 사용하는 스토어드 프로시저를 모델링할 때 필요한 구조를 제공합니다.

데이터 모델은 엔터프라이즈, 부서 또는 개별 응용프로그램 레벨로 구성될 수 있습니다. 엔터프라이즈 및 부서 레벨의 데이터 모델은 비즈니스 또는 비즈니스 단위에서 모든 응용프로그램이 사용하는 주요 비즈니스 엔티티(예: 고객 및 직원)에 대한 표준 정의를 제공할 때 사용할 수 있습니다. 이 데이터 모델 유형은 엔터프라이즈에서 특정 비즈니스 엔티티에 대한 데이터의 "소유자"에 해당하는 시스템 및 데이터의 사용자(데이터 등록자(subscriber))에 해당하는 기타 시스템을 정의하는 데 사용할 수도 있습니다.

이 가이드라인은 관계형 데이터베이스의 데이터 모델을 구성하는 데 사용하는 데이터베이스 모델링에 적합한 UML 프로파일의 모델 요소를 설명합니다. 일반 데이터베이스 이론을 다루는 기존 서적이 많이 있으므로 여기에서는 이 영역을 다루지 않습니다. 관계형 데이터 모델 및 오브젝트 모델에 대한 배경 정보는 개념: 관계형 데이터베이스 및 객체 지향을 참조하십시오.

참고: 이 가이드라인에 포함된 데이터 모델링 표시는 UML 1.3에 기반합니다. 이 가이드라인 개발 당시에는 UML 1.4 데이터 모델링 프로파일이 아직 없었습니다.

데이터 모델링 단계

[NBG01]에서 설명한 대로, 데이터 모델 개발은 개념, 논리 및 실제와 같은 세 가지 일반 단계로 구성됩니다. 데이터 모델링의 이 단계는 응용프로그램의 지속적 데이터 저장 및 검색 메커니즘을 디자인 시 다양한 세부사항 레벨을 반영합니다. 개념적 데이터 모델링에 대한 논의는 [개념: 개념적 데이터 모델링]에서 제공됩니다. 논리 및 실제 데이터 모델링의 요약은 이 가이드라인의 다음 두 섹션에서 제공됩니다.

논리 데이터 모델링

논리 데이터 모델링에서 데이터베이스 디자이너는 응용프로그램이 데이터베이스에서 지속시켜야 하는 중요한 정보를 캡처하는 주요 엔티티 및 관계를 식별하는 작업과 관련됩니다. 유스 케이스 분석, 유스 케이스 디자인클래스 디자인 타스크 중에 데이터베이스 디자이너디자이너는 응용프로그램에 대한 분석 및 디자인 클래스의 디자인 전개가 데이터베이스 개발을 올바르게 지원하도록 함께 협력해야 합니다. 클래스 디자인 타스크 중에 데이터베이스 디자이너 및 디자이너는 데이터베이스에서 데이터를 지속시켜야 하는 디자인 모델의 클래스 세트를 식별해야 합니다.

디자인 모델의 이 지속적 클래스 세트에서는 기존 논리 데이터 모델과는 다르지만 동일한 요구의 많은 부분을 충족시키는 디자인 모델 뷰를 제공합니다. 디자인 모델에서 사용하는 지속적 클래스는 논리 데이터 모델의 기존 엔티티와 동일한 방식으로 작동합니다. 이 디자인 클래스는 지속되어야 하는 모든 데이터 열(속성) 및 주요 관계를 포함하여 지속되어야 하는 데이터를 정확히 반영합니다. 이런 점에서 이 디자인 클래스가 실제 데이터베이스 디자인의 휼륭한 시작점이 될 수 있습니다.

별도의 논리 데이터 모델 작성은 선택사항입니다. 그러나 최선의 경우 결국 동일한 정보를 다른 양식으로 캡처하게 됩니다. 최악의 경우에는 그렇지 않으며, 결국 응용프로그램의 비즈니스 요구를 충족시키지 못할 수도 있습니다. 특히 데이터베이스가 단일 응용프로그램을 지원하도록 고안된 경우 응용프로그램의 데이터 보기가 최고의 시작점이 될 수 있습니다. 데이터베이스 디자이너는 지속적 디자인 클래스 세트에서 테이블을 작성하여 초기 실제 데이터 모델을 구성합니다.

여전히 데이터베이스 디자이너는 응용프로그램 디자인과는 독립적인 데이터베이스의 이상적 디자인을 작성해야 합니다. 이 경우 논리 데이터베이스 디자인은 전반적인 중간 산출물: 데이터 모델의 파트인 별도의 논리 데이터 모델에 표시됩니다. 이 논리 데이터 모델에서는 응용프로그램의 전반적인 아키텍처에서 일관되게 데이터를 지속시켜야 하는 시스템의 요구사항을 만족시키는 데 필요한 주요 논리 엔티티 및 해당 관계를 보여줍니다. 논리 데이터 모델은 데이터베이스 디자인을 위한 UML 프로파일의 모델링 요소(이 가이드라인의 이후 섹션에서 설명됨)를 사용하여 구성될 수 있습니다. 프로젝트에서 이 접근 방식을 사용하는 경우 데이터베이스 디자인 개발에 성공하려면 응용프로그램 디자이너 및 데이터베이스 디자이너 사이의 긴밀한 협업이 절대적으로 필요합니다.

논리 데이터 모델은 실제 데이터베이스 디자인을 작성하도록 논리 데이터 모델의 요소를 전개하기 전에 개념: 정규화에 정의된 대로 정규화의 표준 규칙을 적용하여 정제될 수 있습니다.

아래 그림에서는 초기 실제 데이터 모델을 작성하는 데 사용할 논리 데이터베이스 디자인 정보의 소스로 디자인 모델 클래스를 사용하는 기본 접근 방식을 보여줍니다. 별도의 논리 데이터 모델을 사용하는 대체 접근 방식도 설명합니다.   

함께 표시된 텍스트에서 설명되는 다이어그램

논리 데이터 모델링 접근 방식

실제 데이터 모델링

실제 데이터 모델링은 데이터베이스 디자인의 최종 개발 단계입니다. 실제 데이터 모델은 원래 지속적 디자인 클래스 및 관계에서 작성된 자세한 데이터베이스 테이블 디자인 및 관계로 구성됩니다. 디자인 모델 클래스를 테이블로 변환하는 과정은 가이드라인: 관계형 데이터베이스 포워드 엔지니어링에서 논의합니다. 실제 데이터 모델은 데이터 모델의 파트이며, 별도의 아티팩트가 아닙니다.

실제 데이터 모델의 테이블에는 잘 정의된 열 및 색인이 필요한 만큼 있습니다. 또한 테이블에는 시스템의 데이터베이스 기능 및 참조 무결성을 지원하는 데 필요한 경우 트리거가 정의되어 있습니다. 테이블 이외에도 스토어드 프로시저를 작성 및 문서화하고 스토어드 프로시저가 상주하는 데이터베이스와 연관시킵니다.

아래 다이어그램은 실제 데이터 모델의 일부 요소에 대한 예제입니다. 이 예제 모델은 가상의 온라인 경매 응용프로그램에 대한 실제 데이터 모델의 파트입니다. 이 그림에서는 네 개의 테이블(Auction, Bid, Item 및 AuctionCategory)과 함께 하나의 스토어드 프로시저(sp_Auction) 및 해당 컨테이너 클래스(AuctionManagement)를 보여줍니다. 또한 그림에서는 각 테이블의 열, 1차 키와 외부 키 제한조건 및 테이블에 정의된 색인을 보여줍니다.  

함께 표시된 텍스트에서 설명되는 다이어그램

실제 데이터 모델 요소 예제

실제 데이터 모델은 데이터베이스의 실제 저장영역 단위(테이블 공간)에 대한 테이블 맵핑도 포함합니다. 아래 그림은 이 맵핑에 대한 예제입니다. 이 예제에서 Auction 및 OrderStatus 테이블은 PRIMARY 테이블 공간에 맵핑됩니다. 이 다이어그램에서는 데이터베이스(이 예제에서의 이름은 PearlCircle임)에서 테이블 실현을 모델링하는 방법을 설명합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

데이터 저장영역 모델 요소 예제

데이터베이스가 이미 있는 프로젝트에서 데이터베이스 디자이너는 실제 데이터 모델을 채우도록 기존 데이터베이스의 리버스 엔지니어링을 수행할 수 있습니다. 자세한 정보는 가이드라인: 관계형 데이터베이스 리버스 엔지니어링을 참조하십시오.

데이터 모델 요소

이 섹션에서는 데이터베이스 모델링을 위한 UML 프로파일에 기반하여 데이터 모델의 각 주요 요소에 대한 일반 모델링 가이드라인을 설명합니다. 각 모델 요소에 대한 간략한 설명 뒤에는 UML 모델 요소에 대한 예제 그림이 나옵니다. 이 가이드라인의 관계 섹션에는 모델 요소의 사용법에 대한 설명이 있습니다.

패키지

표준 UML 패키지를 사용하여 데이터 모델의 요소를 그룹화하고 조직합니다. 예를 들어 패키지는 데이터 모델을 별도의 논리 및 실제 데이터 모델로 조직하도록 정의할 수 있습니다. 또한 패키지는 데이터 모델에서 논리적으로 관련된 테이블 그룹을 식별하는 데 사용할 수 있습니다. 이때 테이블은 개발 중인 응용프로그램의 비즈니스 도메인에 중요한 "주제 영역"과 같은 중요한 데이터로 구성됩니다. 아래 그림에서는 데이터 모델에서 뷰 및 테이블을 구성할 때 사용하는 두 개의 주제 영역 패키지(경매 관리 및 사용자 계정 관리)에 대한 예제를 표시합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

주제 영역 패키지 예제

테이블

데이터베이스 모델링에 적합한 UML 프로파일에서 테이블은 스테레오타입이 <<table>>인 클래스로 모델링됩니다. 테이블의 열은 스테레오타입이 <<column>>인 속성으로 모델링됩니다. 하나 이상의 열은 테이블에서 고유한 행 항목을 제공하도록 1차 키로 지정될 수 있습니다. 열은 외부 키로 지정될 수도 있습니다. 1차 키 및 외부 키는 각각 <<Primary Key>> 및 <<Foreign Key>>의 스테레오타입화된 오퍼레이션으로 모델링된다는 연관 제한조건을 가집니다. 아래 그림에서는 가상의 온라인 경매 시스템에서 경매에 판매된 항목 정보를 관리할 때 사용하는 예제 테이블의 구조를 보여줍니다.  

함께 표시된 텍스트에서 설명되는 다이어그램

테이블 예제

테이블은 다음과 같은 관계 유형을 통해 다른 테이블과 관련될 수 있습니다.

  • 식별(컴포지트 집계)
  • 비식별(연관)

이 가이드라인의 관계 섹션에서는 이 관계를 사용하는 방법에 대한 예제를 제공합니다. 이 관계 유형을 디자인 모델 요소에 맵핑하는 방법에 대한 정보는 가이드라인: 관계형 데이터베이스 리버스 엔지니어링을 참조하십시오.

트리거

트리거는 트리거가 상주하는 테이블에서 일정한 조치를 수행한 결과 실행하도록 디자인된 프로시저 기능입니다. 트리거는 테이블의 행을 삽입, 갱신 또는 삭제하는 경우 실행하도록 정의됩니다. 또한 트리거는 테이블 명령을 실행하기 전 또는 이후에 실행하도록 지정됩니다. 트리거는 테이블에서 오퍼레이션으로 정의됩니다. 이 오퍼레이션의 스테레오타입은 <<trigger>>입니다.  

함께 표시된 텍스트에서 설명되는 다이어그램

트리거 예제

색인

색인은 특정 열을 사용하여 테이블을 검색할 때 정보에 빨리 액세스할 수 있도록 하는 메커니즘으로 사용됩니다. 색인은 테이블에서 스테레오타입이 <<index>>인 오퍼레이션으로 모델링됩니다. 색인은 고유하게 지정될 수 있으며 클러스터되거나 클러스터되지 않도록 지정될 수 있습니다. 클러스터된 색인은 테이블의 데이터 행 순서를 색인 값의 순서와 맞추도록 강제 실행할 때 사용됩니다. 아래 그림은 색인 오퍼레이션에 대한 예제(IX_auctioncategory)입니다.

함께 표시된 텍스트에서 설명되는 다이어그램

색인 예제

뷰는 독립적인 지속적 저장영역이 없는 가상 테이블입니다. 뷰는 테이블의 특성 및 동작을 포함하며, 뷰가 정의된 관계를 가지는 테이블의 열에 있는 데이터에 액세스합니다. 뷰는 하나 이상의 테이블에 있는 정보에 대한 효과적인 액세스를 제공할 때 사용되며 테이블의 데이터에 대한 액세스를 제한하는 비즈니스 규칙을 적용할 때에도 사용할 수 있습니다. 아래 예제에서 AuctionView는 이 가이드라인의 실제 데이터 모델링 섹션에서 표시한 Auction 테이블 정보의 "뷰"로 정의됩니다.

뷰는 스테레오타입이 <<view>>인 클래스로 모델링됩니다. 뷰 클래스의 속성은 뷰에서 참조하는 테이블의 열입니다. 뷰에 있는 열의 데이터 유형은 뷰와 정의된 종속성으로 연결된 테이블에서 상속됩니다.

 함께 표시된 텍스트에서 설명되는 다이어그램

뷰 예제

도메인

도메인은 다중 테이블의 열에 적용할 수 있는 사용자 정의 데이터 유형을 작성할 때 사용하는 메커니즘입니다. 도메인은 스테레오타입이 <<Domain>>인 클래스로 모델링됩니다. 아래 예제에서 도메인은 "우편번호 + 4"와 같은 우편번호로 정의됩니다.  

함께 표시된 텍스트에서 설명되는 다이어그램

도메인 예제

스토어드 프로시저 컨테이너

스토어드 프로시저 컨테이너는 데이터 모델에 있는 스토어드 프로시저의 그룹입니다. 스토어드 프로시저 컨테이너는 스테레오타입이 <<SP Container>>인 UML 클래스로 작성됩니다. 다중 스토어드 프로시저 컨테이너는 데이터베이스 디자인에서 작성될 수 있습니다. 각 스토어드 프로시저 컨테이너에는 하나 이상의 스토어드 프로시저가 있어야 합니다.

스토어드 프로시저

스토어드 프로시저는 보통 데이터베이스 서버에 상주하는 독립된 프로시저입니다. 스토어드 프로시저는 스테레오타입이 <<SP Container>>인 클래스로 그룹화된 오퍼레이션으로 문서화됩니다. 이 오퍼레이션의 스테레오타입은 <<SP>>입니다. 아래 예제에서는 이름이 AuctionManagement인 컨테이너 클래스의 단일 스토어드 프로시저 오퍼레이션(SP_Auction)을 표시합니다. 스토어드 프로시저를 디자인하는 경우 데이터베이스 디자이너는 특정 RDBMS에서 사용하는 이름 지정 규칙을 알아야 합니다. 

함께 표시된 텍스트에서 설명되는 다이어그램

스토어드 프로시저 컨테이너 및 스토어드 프로시저 예제

테이블 공간

테이블 공간은 테이블, 스토어드 프로시저 및 색인과 같은 항목에 할당되는 저장영역 공간의 크기를 표시합니다. 테이블 공간은 종속성 관계를 통해 특정 데이터베이스와 링크됩니다. 테이블 공간의 수 및 개별 테이블을 테이블 공간에 맵핑하는 방법은 데이터 모델의 복잡도에 따라 다릅니다. 자주 액세스하는 테이블은 여러 테이블 공간으로 파티션되어야 할 수도 있습니다. 자주 액세스하는 데이터를 많이 포함하지 않은 테이블은 단일 테이블 공간으로 그룹화될 수 있습니다.

각 테이블 공간에 대해 테이블 공간 컨테이너가 정의됩니다. 테이블 공간 컨테이너는 테이블 공간의 실제 저장 장치입니다. 하나의 테이블 공간에 여러 테이블 공간 컨테이너가 있을 수도 있지만 단일 테이블 공간에 하나의 테이블 공간 컨테이너만 지정하는 것이 좋습니다. 테이블 공간 컨테이너는 테이블 공간에 대한 속성으로 정의됩니다. 따라서 명시적으로 모델링되지 않습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

테이블 공간 예제

스키마 페이지 맨 위로

스키마는 데이터베이스 구조 또는 조직을 문서화합니다. 스키마는 스테레오타입이 <<Schema>>인 패키지로 표시됩니다. 스키마가 패키지로 정의되면 해당 패키지를 구성하는 테이블이 스키마 내부에 포함되어야 합니다. 데이터베이스 및 스키마 사이의 종속성을 작성하여 데이터베이스 및 스키마 사이의 관계를 문서화합니다.  

함께 표시된 텍스트에서 설명되는 다이어그램

스키마 예제

데이터베이스 페이지 맨 위로

데이터베이스는 정보를 액세스 및 관리할 수 있도록 구성된 데이터 콜렉션입니다. 데이터베이스에 있는 정보의 관리 및 액세스는 상용 데이터베이스 관리 시스템(DBMS)을 사용하여 수행됩니다. 데이터 모델에서 데이터베이스는 스테레오타입이 <<Database>>인 컴포넌트로 표시됩니다.

함께 표시된 텍스트에서 설명되는 다이어그램

데이터베이스 예제

관계s 페이지 맨 위로

데이터베이스 모델링에 적합한 UML 프로파일에서는 데이터 모델의 주요 요소 간에 올바른 관계를 정의합니다. 이 섹션에서는 서로 다른 관계 유형에 대한 예제를 제공합니다.  

비식별

비식별 관계는 데이터베이스 내부에서 독립적으로 존재하는 두 테이블 사이의 관계입니다. 비식별 관계는 테이블 사이의 연관을 사용하여 문서화됩니다. 이 연관의 스테레오타입은 <<Non-Identifying>>입니다. 아래 예제에서는 Item 테이블 및 AuctionCategory 테이블 사이의 비식별 관계를 보여줍니다.

함께 표시된 텍스트에서 설명되는 다이어그램

비식별 관계 예제

식별

식별 관계는 하위 테이블이 상위 테이블과 함께 공존해야 하는 두 테이블 사이의 관계입니다. 식별 관계는 두 테이블 사이의 컴포지트 집계를 사용하여 문서화됩니다. 이 컴포지트 집계의 스테레오타입은 <<Identifying>>입니다. 아래 그림은 식별 관계에 대한 예제입니다. 이 예제에서는 하위 테이블(CreditCard)의 인스턴스가 상위 테이블(UserAccount)의 연관된 항목을 포함해야 함을 표시합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

식별 관계 예제

연관 및 컴포지트 집계 모두에서 다중성을 정의하여 관계의 행 수를 문서화해야 합니다. 위 예제에서 UserAccount 테이블의 각 행에 대해 CreditCard 테이블에 CreditCard 행이 0개 이상 포함될 수 있습니다. CreditCard 테이블의 각 행에 대해 UserAccount 테이블에 정확히 하나의 행이 있습니다. 다중성은 카디널리티라고도 합니다.

데이터베이스 뷰

데이터베이스 뷰와 테이블의 관계를 정의할 때 뷰에서 테이블로의 종속성 관계가 사용됩니다. 종속성의 스테레오타입은 <<Derive>>입니다. 보통 뷰 종속성은 이름이 지정됩니다. 종속성 이름은 데이터베이스 뷰와의 종속성 관계에 정의된 테이블 이름과 동일합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

뷰 및 테이블 종속성 관계 예제

테이블 공간

종속성 관계는 테이블 공간을 특정 데이터베이스로 링크하는 데 사용됩니다. 아래 그림에 표시된 대로, 데이터베이스가 테이블 공간에 종속되어 있음을 표시하도록 관계가 그려집니다. 모델에서 여러 테이블 공간을 단일 데이터베이스에 관련시킬 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

테이블 공간 및 데이터베이스 종속성 관계 예제

종속성 관계는 테이블 공간의 테이블 및 테이블 공간 사이의 관계를 문서화하는 데 사용됩니다. 하나 이상의 테이블을 단일 테이블 공간에 관련시킬 수 있으며 단일 테이블을 여러 테이블 공간에 관련시킬 수도 있습니다. 아래 예제에서는 Auction 테이블을 단일 테이블 공간 PRIMARY에 지정한 경우를 표시합니다.

함께 표시된 텍스트에서 설명되는 다이어그램

테이블 및 테이블 공간 종속성 관계 예제

실현(realization)

실현은 데이터베이스 및 데이터베이스에 있는 테이블 사이의 관계를 설정하는 데 사용됩니다. 테이블은 데이터 모델에서 다중 데이터베이스로 실현될 수 있습니다.

함께 표시된 텍스트에서 설명되는 다이어그램

테이블 및 데이터베이스 실현(realization) 관계 예제

스토어드 프로시저

종속성 관계는 스토어드 프로시저 컨테이너 및 스토어드 프로시저 컨테이너 내의 스토어드 프로시저가 조치를 수행하는 테이블 사이의 관계를 문서화하는 데 사용됩니다. 아래 예제에서는 스토어드 프로시저 SP_Auction을 사용하여 Auction 테이블의 정보에 액세스하는 경우를 표시하여 이 관계 유형을 보여줍니다.

함께 표시된 텍스트에서 설명되는 다이어그램

스토어드 프로시저 컨테이너 및 테이블 종속성 관계 예제

데이터 모델 전개

도입/인식(Inception) 단계

도입/인식(Inception) 단계에서 초기 데이터 모델링 타스크는 "아키텍처 통합 활동 수행" 타스크의 파트로 개념 검증 프로토타입의 개발과 함께 수행될 수 있습니다. 데이터베이스가 이미 있는 프로젝트에서 데이터베이스 디자이너는 기존 데이터베이스의 구조에 기반하여 초기 실제 데이터 모델을 개발하도록 기존 데이터베이스의 리버스 엔지니어링을 수행할 수 있습니다. 자세한 정보는 가이드라인: 관계형 데이터베이스 리버스 엔지니어링을 참조하십시오. 개념 검증 프로토타입 타스크를 지원하기 위해 필요에 따라 실제 데이터 모델의 요소가 디자인 모델 요소로 변환될 수 있습니다.

정제 단계

정제 단계의 목적은 기술 위험성을 제거하고 시스템의 안정된(기준선 작성된) 아키텍처를 생성하는 것입니다. 대규모 시스템에서는 잘못된 데이터 모델 디자인으로 인한 성능 저하가 주요 아키텍처 관심사항입니다. 결과적으로 데이터베이스의 성능을 평가할 수 있는 아키텍처 프로토타입의 개발 및 데이터 모델링은 안정된 아키텍처를 달성하는 데 매우 중요합니다. 구조적으로 중요한 유스 케이스가 각 반복에서 자세히 설명하고 분석됨에 따라 데이터 모델 요소가 유스 케이스에서의 지속적 클래스 디자인 개발에 기반하여 정의됩니다. 클래스 디자인이 안정화됨에 따라 데이터베이스 디자이너는 데이터 모델에서 정기적으로 클래스 디자인을 테이블로 변환하고 적절한 데이터 저장영역 모델 요소를 정의할 수 있습니다.

정제 단계의 마지막에는 응용프로그램에 대해 구조적으로 중요하다고 정의된 시나리오 실행을 지원하도록 주요 데이터베이스 구조(테이블, 색인, 1차 및 외부 키 열)를 적절히 배치해야 합니다. 또한 아키텍처 성능 테스트를 지원하도록 대표 데이터 볼륨을 데이터베이스에 로드해야 합니다. 성능 테스트 결과에 따라 비정규화, 실제 저장영역 속성 최적화 또는 분배 및 색인화를 포함하여(단, 이에 한하지 않음) 데이터 모델을 최적화 기법에 맞게 조정해야 합니다.

구현/구축(Construction) 단계

데이터 모델의 주요 재구성 작업은 구현/구축 단계에서 발생해서는 안됩니다. 추가 테이블 및 데이터 저장영역 요소가 유스 케이스 세트의 자세한 디자인 및 승인된 변경 요청(반복에 할당됨)에 따라 구현/구축 단계 중에 정의될 수 있습니다. 구현/구축 단계 중 데이터베이스 디자인의 기본 초점은 지속적으로 데이터베이스 성능을 모니터하고 비정규화, 색인 정의, 데이터베이스 뷰 작성 및 기타 최적화 기법을 통해 필요한 만큼 데이터베이스 디자인을 최적화하는 데 있습니다.

실제 데이터 모델은 구현/구축 단계 중 데이터베이스 디자이너가 유지보수하는 디자인 아티팩트입니다. 이 데이터 모델은 데이터베이스에서 직접 수행된 갱신사항을 도구에서 읽은 결과로 또는 모델에서 직접 갱신을 수행하여 유지보수될 수 있습니다.

전이(Transition) 단계

디자인 모델과 마찬가지로 데이터 모델은 승인된 변경 요청에 대한 응답으로 전이 단계 중에 유지보수됩니다. 데이터베이스 디자이너는 응용프로그램이 최종 적합성 테스트를 통과하여 프로덕션으로 배치됨에 따라 데이터베이스와 데이터 모델을 동기화해야 합니다.

라운드트립 엔지니어링 고려사항

개발 팀이 클래스를 테이블(및 그 반대)로 변환하는 기능 및/또는 데이터베이스를 리버스 및 포워드 엔지니어링하는 기능이 있는 최신 비주얼 모델링 도구를 사용하는 경우, 해당 팀은 변환 및 엔지니어링 프로세스를 관리하는 가이드라인을 설정해야 합니다. 이 가이드라인은 주로 팀에서 데이터베이스 및 응용프로그램 디자인을 병렬로 수행하는 대규모 프로젝트에 필요합니다. 개발 팀에서는 응용프로그램 개발에 클래스를 테이블로 변환 및 데이터베이스의 포워드 엔지니어링 수행에 적합한 위치(빌드/릴리스 주기)를 정의해야 합니다. 초기 데이터베이스가 작성되면 개발 팀은 프로젝트에 걸쳐 시스템의 디자인 및 코드가 전개됨에 따라 팀이 데이터 모델 및 데이터베이스의 동기화를 관리하는 가이드라인을 정의해야 합니다.