가이드라인: 데이터 모델
주제
데이터 모델은 시스템에서 사용되는 지속적 데이터 저장의
구조를 설계하는 데 사용됩니다. 데이터베이스 설계용 UML
프로파일은 데이터베이스 설계자에게 데이터베이스 내의 테이블에 대한 자세한 설계를 개발하고
데이터베이스의 실제 기억장치 레이아웃을 모델화하는 데 사용될 수 있는
모델링 요소 세트를 제공합니다. UML 데이터베이스 프로파일은 데이터베이스에 대한
액세스를 관리하는 데 사용되는 저장 프로시저뿐 아니라 참조 무결성을 모델링하는 데 필요한
구성(제한조건 및 트리거)도 제공합니다.
데이터 모델은 엔터프라이즈, 부서 또는 개별 어플리케이션 레벨로 구축될 수 있습니다.
엔터프라이즈 및 부서 레벨의 데이터 모델은 비즈니스 또는 비즈니스 단위 내의
모든 어플리케이션에 사용될 핵심 비즈니스 엔티티(예: 고객 및 엔티티)에 대한 표준 정의를
제공하는 데 사용될 수 있습니다. 이러한 유형의 데이터 모델은 엔터프라이즈
중에서 어떤 시스템이 특정 비즈니스 엔티티에
대한 데이터의 "소유자"이고 어떤 시스템이 데이터의 사용자(서브스크라이버)인지를 정의하는 데
사용될 수 있습니다.
이 가이드라인에서는 관계형 데이터베이스의 데이터 모델을 구축하는 데 사용되는
데이터베이스 모델링에 대한 UML 프로파일의 모델 요소에 대해 설명합니다. 일반 데이터베이스 이론에 대한
기존의 서적이 많기 때문에 여기서는 이 영역에 대해 다루지 않습니다. 관계형 데이터 모델 및
객체 모델에 대한 배경 정보는 개념: 관계형 데이터베이스 및 객체의 방향을
참조하십시오.
참고: 이 가이드라인에 포함되어 있는 데이터 모델링 표현은 UML 1.3을 기본으로 합니다.
이 가이드라인을 개발할 때에는 UML 1.4 데이터 모델링 프로파일이 사용 가능하지 않았습니다.
NBG01]에서 설명된 대로 데이터 모델 개발에는 개념,
논리 및 실제의 세 가지 일반 단계가 있습니다. 이 데이터 모델링 단계는 어플리케이션의
지속적 데이터 기억장치 및 검색 메커니즘 설계에
여러 레벨의 세부사항을 반영합니다.
개념적 데이터 모델에 대한 토론은 개념
:
개념적 데이터 모델링에 제공되어 있습니다. 논리 및 실제 데이터
모델링의 요약은 이 가이드라인의 다음 두 섹션에 제공되어 있습니다.
논리 데이터 모델링

논리 데이터 모델링에서 데이터베이스 설계자는
어플리케이션이 데이터베이스에 존속시켜야 하는 중요한 데이터를 캡처하는 핵심 엔티티와 관계를
식별하는 데 관여합니다. 유스 케이스 분석,
유스 케이스 설계 및 클래스 설계 활동 중에
데이터베이스 설계자 및 설계자는
함께 작업하여 어플리케이션에 대한 분석 및 설계 클래스의 설계 전개가 데이터베이스 개발을 지원하는지
확인해야 합니다. 클래스 설계 활동 중에
데이터베이스 설계자 및 설계자는 데이터베이스에 데이터를 존속시키는 데 필요한 설계 모델에서
클래스 세트를 식별해야 합니다.
설계 모델의 이러한 지속적 클래스 세트는 일반 논리 데이터 모델과는 다르나
동일한 요구사항의 대부분을 만족시키는 설계 모델 보기를 제공합니다. 지속적 클래스는
논리 데이터 모델의 일반 엔티티와 동일한 방법으로 설계 모델
기능에 사용됩니다. 이러한 설계 클래스는 존속되어야 하는 모든 데이터 열(속성) 및 중요한 관계를
포함하여 존속되어야 하는 데이터를 정확히 반영합니다.
이는 이러한 설계 클래스를 실제 데이터베이스 설계를 시작하기에 좋은 지점으로 만듭니다.
별도의 논리 데이터 모델을 작성하는 것은 선택사항입니다.
그러나 가장 좋은 케이스에서는 결국 다른 양식에서 동일한 정보를 캡처하게 됩니다.
그렇지 못한 가장 나쁜 케이스에서는 결국 어플리케이션의 비즈니스 요구를 만족시키지
못할 수도 있습니다. 특히, 데이터베이스가 단일 어플리케이션을 제공하려 할 경우
어플리케이션의 데이터 보기가 가장 좋은 시작 지점이 될 수 있습니다.
데이터베이스 설계자는 이 지속적 설계 클래스 세트로부터 테이블을 작성하여 초기
실제 데이터 모델을 구성합니다.
계속해서 데이터베이스 설계자가 응용프로그램 설계에 독립적인 이상적인 데이터베이스 설계를
작성하도록 하는 상황이 발생할 수 있습니다. 이런 경우,
논리 데이터베이스 설계는 전체 결과물:
데이터 모델의 일부인 별도의 논리 데이터 모델로 표현될 수 있습니다. 이 논리 데이터
모델은 전체적인 어플리케이션 구조와 일치하는
지속적 데이터에 대한 시스템 요구사항을 만족시키는 데 필요한 핵심 논리 엔티티 및
해당 관계를 설명합니다. 논리 데이터 모델은 이 가이드라인의 후반
섹션에 설명되어 있는 데이터베이스 설계를 위한
UML 프로파일의 모델링 요소를 사용하여 구축됩니다. 이 접근 방법으로 사용하는 프로젝트의 경우,
어플리케이션 설계자와 데이터베이스 설계자 간의 긴밀한
협력이 데이터베이스 설계의 개발을 성공시키는 데 절대적인 역할을 합니다.
논리 데이터 모델은 데이터베이스의 실제 설계를 작성하기 위해 논리 데이터 모델의 요소를
전개하기 전에 개념:
정규화에 정의된 대로 정규화에 필요한 표준 정책을 적용하여 정제할 수 있습니다.
아래의 그림은 초기 실제 데이터 모델 작성에 필요한 논리 데이터베이스 설계 정보의 소스로서
설계 모델 클래스를 사용하는 기본 접근 방법을 설명합니다.
또한 별도의 논리 데이터 모델을 사용하는 다른 접근 방법도 보여줍니다.

논리 데이터 모델 접근 방법
물리 데이터 모델링
실제 데이터 모델링은 데이터베이스 설계의 최종 개발 단계입니다. 실제 데이터 모델은
처음에 지속적 설계 클래스 및 해당 관계로부터 시작된
자세한 데이터베이스 테이블 설계 및 해당 관계로 구성됩니다. 설계 모델 클래스에서 테이블로의
변환을 수행하는 메커니즘은
가이드라인: 관계형 데이터베이스 포워드 엔지니어링에
설명되어 있습니다. 실제 데이터 모델은 데이터 모델의
일부분입니다. 별도의 결과물은 아닙니다.
실제 데이터 모델의 테이블은 잘 정의된 열과 중요한 및 인덱스(필요에 따라)를 갖고 있습니다.
테이블에는 데이터베이스 기능성 및 시스템의 참조 무결성을 지원하기 위해
트리거도 지정되어 있습니다(필요에 따라).
테이블에 추가하여 저장 프로시저가 작성, 문서화되어 저장 프로시저가 상주하는
데이터베이스에 연관되어 있습니다.
아래의 다이어그램은 실제 데이터 모델 요소에 대한 몇 가지 예제가 나와 있습니다.
이 모델 예제는 가공의 온라인 경매 어플리케이션에 대한 실제 데이터 모델의 일부입니다.
여기에는 하나의 저장 프로시저(sp_Auction) 및 해당 컨테이너 클래스(AuctionManagement)와 함께
네 개의 테이블(Action, Bid, Item 및 AuctionCategory)이 나와 있습니다. 그림에는
각 테이블의 열, 기본 중요한 및 외부 중요한 제한조건, 테이블에 대해 정의된 색인도 나와 있습니다.

(실제) 데이터 모델 요소 예제
실제 모델 요소에는 데이터베이스의 실제 기억장치 단위(테이블 공간)에 대한 테이블 맵핑도 들어 있습니다. 아래의
그림에 이 맵핑 예제가 표시되어 있습니다. 이 예제에서 Auction 및
OrderStatus 테이블은 PRIMARY라는 테이블 공간으로 맵핑됩니다. 다이어그램은 테이블 구현을
데이터베이스(이 예제에서는 PearlCircle)로 모델링하는 것도 보여줍니다.

데이터 기억장치 모델 요소 예제
프로젝트가 이미 존재하는 프로젝트에서 데이터베이스 설계자는 실제 데이터 모델에 데이터를 입력하기 위해
기존의 데이터베이스를 역엔지니어링할 수 있습니다. 자세한 정보는
가이드라인: 관계형 데이터베이스 역엔지니어링을 참조하십시오.
이 섹션에서는 데이터베이스 모델링을 위한 UML 프로파일을 기반으로 데이터 모델의
각 주요 요소에 대한 일반 모델링 가이드라인에 대해 설명합니다.
UML 모델 요소 그림 예제 다음에 각 모델 요소에 대한 간략한 설명이 있습니다.
이 가이드라인의 관계 섹션에는 모델 요소의 사용법에 대한
설명이 들어 있습니다.
표준 UML 패키지는 데이터 모델 요소를 그룹화하고 조직하는 데 사용됩니다. 예를 들어, 데이터 모델을
별도의 논리 및 실제 데이터 모델로 구성하도록 패키지가
구성되어 있을 수 있습니다. 패키지는 개발 중인 어플리케이션의 비즈니스 도메인에 중요한 주요
"주제 영역"을 구성하는 데이터 모델에서 논리적으로 연관된 테이블 그룹을 식별하는 데
사용될 수 있습니다. 아래의 그림은 데이터 모델에 보기 및 테이블을 조직하는 데
사용되는 두 개의 주제 영역 패키지(경매 관리 및 사용자 계정 관리) 예제를 보여줍니다.

주제 영역 페키지 예제
데이터 모델링을 위한 UML 프러파일에서 테이블은 <<테이블>> 스테레오타입을
가진 클래스로 모델화됩니다. 테이블의 열은 <<열>> 스테레오타입을 가진
속성으로 모델화됩니다. 테이블에 고유한 행 항목을 제공하기 위해 하나 이상의
열을 1차 키로 지정할 수 있습니다.
열은 외부 키로도 지정할 수 있습니다. 1차 중요한 및 외부 키는
각각 <<1차 키>> 및
<<외부 키>>의 스테레오타입 조작으로서 모델화되는 연관된 제한조건을 가집니다. 아래의 그림에
가공 온라인 경매 시스템의 경매에서 팔린 항목에 대한 정보를 관리하는 데
사용되는 테이블 구조 예제가 나와 있습니다.

테이블 예제
테이블은 다음과 같은 관계 유형을 통해 다른 테이블에 연관될 수 있습니다.
이 가이드라인의 관계 섹션은 이 관계를 사용하는 방법에
대한 예제를 제공합니다. 이러한 관계 유형에 대한 정보는
가이드라인: 관계형 데이터베이스 역엔지니어링에 표시된
설계 모델 요소에 맵핑됩니다.
트리거는 트리거가 상주하는 테이블에 대한 일부 조치의 결과로서 실행되도록 설계된 절차적 기능입니다.
트리거는 테이블의 행이 갱신, 삽입 또는 삭제될 때 실행하도록 정의됩니다.
추가로 트리거는 테이블 명령을 실행하기 전이나 후에 실행하도록 지정됩니다.
트리거는 테이블에 조작으로 정의됩니다.
조작은 <<트리거>> 스테레오타입을 갖고 있습니다.

트리거 예제
색인은 특정 열을 사용하여 테이블을 검색할 때 정보에 신속하게 액세스할 수 있게 하는
메커니즘으로 사용됩니다. 색인은 스테레오타입이 <<색인>>인
테이블에서 조작으로 모델화됩니다. 색인은 고유하게 지정되며
클러스터 또는 비클러스터로 지정될 수 있습니다.
클러스터된 색인은 색인 값의 순서를 사용하여 테이블에 있는 데이터 열의 순서를 강제로
정렬하는 데 사용됩니다.
색인 조작(IX_auctioncategory)의 예가 아래의 그림에 나와 있습니다.

색인 예제
보기는 독립된 지속적 기억장치가 없는 가상 테이블입니다.
보기는 테이블의 특성 및 작동을 갖고 있으며 보기가 관계를 정의한 테이블로부터
열의 데이터에 액세스합니다. 보기는 하나 이상의 테이블에 있는 정보에 보다
효율적인 액세스를 제공하는 데 사용되며
테이블의 데이터에 대한 액세스를 제한하기 위해 비즈니스 규칙을 실시하는 데 사용될 수 있습니다.
아래의 예제에서 AuctionView는 이 가이드라인의 실제 데이터 모델링 섹션에 표시된
Auction 테이블에 있는 정보에 대한 "보기"로서 정의되었습니다.
보기는 <<보기>> 스테레오타입을 가진 클래스로서 모델화됩니다. 보기 클래스의 속성은
보기가 참조하는 테이블에 있는 열입니다. 보기에 있는 열의 데이터 유형은 보기를 사용하여
종속성이 정의된 테이블로부터 상속됩니다.

보기 예제
도메인은 여러 테이블에 걸친 열에 적용할 수 있는
사용자 정의 데이터 유형을 작성하는 데 사용되는 메커니즘입니다. 도메인은 <<도메인>>
스테레오타입을 가진 클래스로서 모델화됩니다. 아래의 예제에서는
"zip + 4" 우편번호에 대해 도메인이 정의되었습니다.

도메인 예제
저장 프로시저 컨테이너는 데이터 모델 내의 저장 프로시저 그룹입니다.
저장 프로시저 컨테이너는 <<SP 컨테이너>> 스테레오타입의 UML 클래스로 작성됩니다.
데이터베이스 설계에 복수의 저장 프로시저 컨테이너를 작성할 수 있습니다.
각각의 저장 프로시저 컨테이너는 최소한 하나의 저장 프로시저를 가져야 합니다.
저장 프로시저는 일반적으로 데이터베이스 서버에 상주하는 독립적 프로시저입니다.
저장 프로시저는 <<SP 컨테이너>> 스테레오타입을 가진 클래스로 그룹화되는 조작으로 문서화됩니다.
조작은 <<SP>> 스테레오타입을 갖습니다. 아래의 예제에
AuctionManagement라는 컨테이너 클래스에 있는 단일 저장 프로시저 조작(SP_Auction)이 나와 있습니다. 저장 프로시저를
설계할 때 데이터베이스 설계자는 특정 DBMS가 사용하는 이름 지정 규칙을 인식해야 합니다.

저장 프로시저 컨테이너 및 저장 프로시저 예제
테이블 공간은 테이블, 저장 프로시저 및 색인과 같은 항목에 할당할 기억장치 공간의 양을 나타냅니다.
테이블은 종속성 관계를 통해 특정 데이터베이스에 링크됩니다.
테이블 공간의 수 및 개별 테이블을 테이블 공간에 맵핑하는 방법은 데이터 모델의 복잡도에 따라 다릅니다. 자주
액세스하는 테이블은 복수의 테이블 공간으로 파티션해야 합니다.
자주 액세스하는 데이터를 많이 포함하지 않는 테이블은 하나의 테이블 공간으로 그룹화할 수 있습니다.
각 테이블 공간에 대해 테이블 컨테이너가 정의됩니다.
테이블 공간 컨테이너는 테이블 공간에 대한 실제 기억장치입니다.
하나의 테이블 공간에 대해 복수의 테이블 공간 컨테이너가 존재할 수는 있지만
하나의 테이블 공간에만 테이블 공간 컨테이너를 지정하는 것이 좋습니다.
테이블 컨테이너는 테이블 공간에 대한 속성으로 정의됩니다. 테이블 컨테이너는 명시적으로
삭제되지 않습니다.

테이블 공간 예제
스키마는 데이터베이스의 조직 또는 구조를 문서화합니다.
스키마는 <<스키마>> 스테레오타입을 가진 패키지로 표현됩니다.
스키마를 패키지로 정의하면 해당 패키지를 구성하는 테이블은 스키마 내에 포함됩니다.
데이터베이스 및 스키마 사이의 관계를 문서화하기 위해 데이터베이스 및 스키마 사이에 종속성이 작성됩니다.

스키마 예제
데이터베이스는 데이터베이스 내의 정보에 액세스하여 관리할 수 있도록 구성된 데이터의 콜렉션입니다.
데이터베이스 내의 정보 관리 및 액세스는 상업용 DBMS(Database Management System)를 사용하여 수행됩니다. 데이터베이스는
데이터 모델 내에 <<데이터베이스>> 스테레오타입을 가진
컴포넌트로 표현됩니다.

데이터베이스 예제
데이터베이스 모델링을 위한 UML 프로파일은 데이터 모델의 기본 요소 간의 올바른 관계를 정의합니다.
다음 섹션에서는 다른 관계 유형에 대한 예제를 제공합니다.
비식별
비식별 관계는 데이터베이스 내에 독립적으로 존재하는 두 테이블 간의 관계입니다.
비식별 관계는 테이블 간의 연관을 사용하여 문서화됩니다.
연관은 <<비식별>> 스테레오타입을 갖습니다. 아래의 예제에 Item 테이블과
AuctionCategory 테이블 간의 비식별 관계가 표시되어 있습니다.

비식별 관계 예제
식별
식별 관계는 하위 테이블이 상위 테이블과 함께 공존해야 하는 두 개의 테이블 간의 관계입니다.
식별 관계는 두 테이블 간의 합성 총계를 사용하여 문서화됩니다.
합성 총계는 <<식별>> 스테레오타입을 갖습니다.
아래의 그림은 식별 관계에 대한 예제입니다. 이 예제는 하위 테이블(CreditCard) 인스턴스가
상위 테이블(UserAccount)에 연관 항목을 갖고 있어야 함을 표시합니다.

식별 관계 예제
연관 및 합성 총계 모두의 경우,
관계 내에 행의 수를 문서화하려면 다양성이 정의되어 있어야 합니다.
위의 예제에서 UserAccount 테이블의 각 행의 경우
CreditCard 테이블에 0개 이상의 CreditCard 행이 있을 수 있습니다.
CreditCard 테이블의 각 행의 경우, UserAccount 테이블에 단 하나의 행이 있습니다.
다양성을 카디낼러티라고도 합니다.
데이터베이스 보기
테이블과의 데이터베이스 보기 관계를 정의할 경우, 종속성 관계가 사용되며
보기에서 테이블로 그려집니다. 종속성의 스테레오타입은 <<도출>>입니다.
일반적으로 보기 종속성에는 이름이 지정되며 종속성의 이름은
데이터베이스 보기와의 종속성 관계에 정의된 테이블의 이름과 동일합니다.

보기 및 테이블 종속성 관계 예제
테이블 공간
종속성 관계는 테이블 공간을 특정 데이터베이스에 링크하는 데 사용됩니다.
아래 그림에 표시된 대로 데이터베이스가 테이블 공간에 대한 종속성을 갖고 있음을
나타내는 관계가 그려집니다. 복수의 테이블 공간이 모델 내의 하나의 데이터베이스에 관련될 수 있습니다.

테이블 공간 및 데이터베이스 종속성 관계 예제
종속성 관계는 테이블 공간과 테이블 공간 내의 테이블 간의 관계를 문서화하는 데 사용됩니다.
하나 또는 복수의 테이블이 하나의 테이블 공간에 관련될 수 있으며
단일 테이블은 복수의 테이블 공간에 관련될 수 있습니다 .
아래의 예제에 Auction 테이블이 PRIMARY라는 단일 테이블 공간에 지정되어 있음이 표시되어 있습니다.

테이블 및 테이블 공간 종속성 관계 예제
구현
구현은 데이터베이스 및 데이터베이스 내에 존재하는 테이블 간에 관계를 설정하는 데 사용됩니다.
테이블은 데이터 모델 내의 복수의 데이터베이스에 의해 구현될 수 있습니다.

테이블 및 데이터베이스 구현 관계 예제
저장 프로시저
종속성 관계는 저장 프로시저 컨테이너 및 저장 프로시저 컨테이너 내의 저장 프로시저가 영향을 미치는
테이블 간의 관계를 문서화하는 데 사용됩니다. 아래의 예제에서는
저장 프로시저 SP_Auction를 사용하여 Auction 테이블의 정보에 액세스하는 것을 보여줌으로써
이 유형의 관계를 설명합니다.

저장 프로시저 컨테이너 및 테이블 종속성 관계 예제
초기화 단계에서 초기 데이터 모델링
활동은 "구조 통합 워크플로우 세부사항 수행" 활동의 일부인
모든 개념 인증 프로토타입의 개발과 함께 수행될 수 있습니다.
데이터베이스가 이미 존재하는 프로젝트에서 데이터베이스 설계자는 기존 데이터베이스의
구조를 기본으로 초기 실제 데이터 모델을 개발하기 위해 기존의 데이터베이스를
역엔지니어링할수 있습니다. 자세한 정보는
가이드라인: 관계형 데이터베이스 역엔지니어링을 참조하십시오.
실제 데이터 모델의 요소는 모든 개념 입증 프로토타입 활동을 지원하기 위해
필요에 따라 설계 모델 요소로 변환될 수 있습니다.
구현화 단계의 목표는 기술적 위험을 제거하고
시스템에 안정적인(기준선이 설정된) 구조를 생성하는 것입니다.
대형 시스템에서 데이터 모델의 설계가 잘못되어 성능이 떨어지는 것은
주로 구조적 문제점 때문입니다. 결과적으로, 데이터베이스의 성능을 평가할 수 있게 하는
데이터 모델링 및 구조적 프로토타입의 개발 모두 안정적 구조를 달성하는 데 필요합니다.
구조적으로 중요한 유스 케이스는 각 반복에서 상세화되고 분석되기 때문에
데이터 모델 요소는 유스 케이스의 지속적 클래스 설계 개발을 기본으로 정의됩니다.
클래스 설계가 안정되면, 데이터베이스 설계자는 정기적으로 클래스 설계를
데이터 모델 내의 테이블로 변환하고 적절한 데이터 기억장치 모델 요소를 정의할 수 있습니다.
구현화 단계가 끝난 후, 어플리케이션을 위해 정의된 구조적으로 중요한 시나리오의
실행을 지원하려면 주요 데이터베이스 구조(테이블, 색인, 1차 및 외부 중요한 열)를 적소에 배치해야 합니다.
추가로 구조적 성능 테스트를 지원하려면 대표적인 데이터 볼륨을 데이터로 로드해야 합니다.
성능 테스트 결과에 따라, 실제 기억장치 속성의 최적화 또는 분배 및 인덱스화를
포함하여(비정규화로 제한되지는 않음) 최적화 기법을 사용하여 데이터 모델을 조정해야 합니다.
구축 단계 중에는 데이터 모델의 기본 재구성이
발생해서는 안 됩니다. 유스 케이스 세트의 설계 세부사항 및 반복에 할당된 승인된 변경 요청을
기본으로 구축 단계 반복 중에 추가 테이블 및 데이터 기억장치 요소를 정의할 수 있습니다.
구축 단계 중에 데이터베이스 설계시 가장 중점을 두는 점은 데이터베이스의 성능을 계속해서
모니터하고 비정규화, 색인 정의, 데이터베이스 보기 작성 및 기타 최적화 기법을 통해 필요에 따라
데이터베이스 설계를 최적화하는 것입니다.
실제 데이터 모델은 구축 단계 중에 데이터베이스 설계자가 유지보수하는 설계 결과물입니다.
모델 내에서 직접 갱신을 수행하거나 데이터베이스에 대해 직접 행한 툴 읽기 갱신 결과로서
설계 결과물을 유지보수할 수 있습니다.
설계 모델과 같은 데이터 모델은 승인된 변경 요청에 대한 응답으로
전이 단계 중에 유지보수됩니다.
데이터베이스 설계자는 어플리케이션이 최종 승인 테스트를 거쳐 생산으로 전개됨에 따라
데이터 모델을 데이터베이스와 동기화해야 합니다.
개발 팀이 클래스를 테이블로(또는 그 반대로) 변환할 수 있는 기능이 있거나
데이터베이스를 역엔지니어링 또는 포워드 엔지니어링할 수 있는 기능이 있는 경우,
팀은 변환 관리 및 프로세스 설계에 필요한 가이드라인을 설정해야 합니다.
팀이 데이터베이스 및 어플리케이션 설계에 대해 병렬로 작업하는 대형 프로젝트에는
기본적으로 가이드라인이 필요합니다.
개발 팀은 어플리케이션(빌드/릴리즈 주기) 개발시 클래스 대 테이블 변환을 수행하고 데이터베이스를 포워드 엔지니어링하는 데
적절한 지점을 정의해야 합니다. 초기 데이터베이스가 작성되면,
시스템의 설계 및 코드가 프로젝트 전체에 걸쳐 전개됨에 따라
팀이 데이터 모델 및 데이터베이스의 동기화를 관리할 수 있게 하려면
개발 팀은 가이드라인을 정의해야 합니다.
|