주제

소개페이지 맨 위

이 가이드라인에서는 데이터베이스 리버스 엔지니어링과 결과로 나타난 데이터 모델 테이블을 설계 모델설계 클래스에 맵핑하는 관련 단계를 설명합니다. 이 프로세스는 전개 개발 주기의 일부분으로서 데이터베이스 수정 개발을 시드하는 데이터베이스 설계자가 사용할 수 있습니다. 데이터베이스 설계자는 프로젝트 개발 라이프사이클 전반에 걸쳐 리버스 엔지니어링 프로세스를 관리해야 합니다. 다수의 경우에서 리버스 엔지니어링 프로세스는 프로젝트 라이프사이클 초기에 수행된 다음 후속 데이터베이스 리버스 엔지니어링을 수행할 필요 없이 데이터 설계의 변경사항을 점증적으로 관리합니다.

데이터베이스 리버스 엔지니어링과 결과로 나타난 데이터 모델 요소를 설계 모델 요소로 변환하는 프로세스의 주요 단계는 다음과 같습니다.

  • 테이블을 포함하는 실제 데이터 모델을 작성하여 데이터베이스에서 지속적 데이터의 실제 레이아웃을 표시하십시오. 이 단계는 관계형 데이터베이스 관리 시스템(RDBMS)에서 제공하는 툴을 사용하거나 최신 비주얼 모델링 툴을 통해 자동으로 수행될 수 있습니다.
  • 실제 데이터 모델의 테이블을 설계 모델의 설계 클래스로 변환하십시오. 이 단계는 수동 조정이 수반된 초기 변환을 지원하는 자동화 툴의 조합을 통해 수행될 수 있습니다.
  • 설계 모델에서 클래스 사이의 연관을 정의하십시오.
  • 해당 데이터 모델 요소에 수행되는 조치에 따라 설계 모델의 클래스에 대해 적절한 조작을 정의하십시오.
  • 필요에 따라 설계 모델의 클래스를 서브시스템 및 패키지로 그룹화하십시오.

RDBMS 데이터베이스 또는 DDL 스크립트를 리버스 엔지니어링하여 데이터 모델 생성페이지 맨 위

일반적으로 데이터베이스 또는 데이터 정의 언어(DDL) 스크립트 리버스 엔지니어링 프로세스는 일련의 모델 요소(테이블, 보기, 저장 프로시저 등)를 데이터 모델에서 하나 이상의 시스템 정의 패키지로 생성합니다. 데이터베이스 설계자는 데이터베이스의 복잡도에 따라 리버스 엔지니어링된 모델 요소를 논리적으로 관계된 테이블 세트를 포함하는 주제 영역 패키지로 파티션 지정해야 합니다.

데이터 모델을 설계 모델로 변환 페이지 맨 위

다음 프로시저가 데이터 모델의 모델 요소에서 설계 클래스를 생성하기 위해 수행될 수 있습니다. 클래스 모델에서 데이터베이스 구조 복제는 비교적 간단합니다. 다음에 나열된 프로세스는 데이터 모델 요소를 설계 모델 요소로 변환하는 알고리즘을 설명합니다.

다음 표에서는 설계 모델 요소와 데이터 모델 요소 사이의 일반적인 맵핑 요약을 보여줍니다.

데이터 모델 요소 

해당 설계 모델 요소 

테이블  클래스 
열  속성 

식별하지 않는 관계 

연관 

교차 테이블

 

연관 클래스

다대다 연관

규정된 연관 

식별하는 관계 

합성 총계 

관계차수 

 

다양성 

 
열거된 절을 포함하는 확인 제한조건  <<ENUM>> 클래스 
스키마  패키지 

설계 모델에서 직접적으로 상관 없는 데이터 모델의 모델 요소가 일부 있습니다. 이 요소에는 데이터베이스의 실제 저장영역 특성을 모델링하여 컴포넌트로 나타나는 테이블 공간과 데이터베이스 자체가 있습니다. 또다른 항목으로 "가상" 테이블이며 설계 모델에서 의미가 없는 데이터베이스 보기가 있습니다. 끝으로 데이터베이스 조작을 최적화하는 데 사용되는 테이블 및 데이터베이스 트리거 함수의 1차 키에 대한 색인은 데이터베이스 및 데이터 모델의 컨텍스트에서만 의미가 있습니다.

테이블을 클래스로 변환 페이지 맨 위

변환하려는 각 테이블에 대해 클래스를 작성하여 테이블을 나타내십시오. 각 열에 대해서는 적절한 데이터 유형을 사용하여 해당 클래스의 속성을 작성하십시오. 속성의 데이터 유형을 연관된 열의 데이터 유형과 가능한 근접하게 일치시키십시오.

다음 그림에 표시된 구조를 갖춘 고객 데이터베이스 테이블을 고려하십시오.

열 이름 데이터 유형
Customer_ID Number
이름 Varchar
동/군 Varchar
시/구 Varchar
시/도 Char(2)
우편번호 Varchar
국가 Varchar

고객 테이블에 대한 테이블 정의

이 시점에서 시작하여 다음 그림에서 표시하는 구조를 갖춘 고객 클래스를 작성합니다.

고객 클래스 정의

초기 고객 클래스

이 초기 고객 클래스에는 고객 테이블에 있는 각 열의 속성이 있습니다. 원래 테이블의 열이 조회될 수 있기 때문에 각 속성에는 public 가시성이 있습니다.

주: 속성의 왼쪽에 나열되는 "+" 아이콘은 속성이 'public'임을 나타내며, RDBMS에서는 일반적으로 제한조건 없이 열을 조회할 수 있으므로 RDBMS 테이블에서 도출되는 속성은 모두 기본적으로 public이어야 합니다.

임베디드 또는 암시적 클래스 식별 페이지 맨 위

직접 테이블-클래스 맵핑에서 발생하는 클래스는 특히 해당 속성이 다수의 변환된 클래스에 나타나는 경우 별개의 클래스로 분류될 수 있는 속성을 종종 포함하게 됩니다. 이러한 '반복 속성'은 성능의 이유로 테이블의 비정규화에서 발생했거나 지나치게 간소화된 데이터 모델의 결과일 수도 있습니다. 이러한 경우 해당 클래스를 둘 이상의 클래스로 분할하여 정규화된 테이블 보기를 표시하십시오.

위에서 고객 클래스를 정의한 후에 다음 클래스와 함께 모든 주소 정보를 포함하는 주소 클래스를 정의할 수 있습니다(주소와 함께 그 밖의 정보도 시스템에 있다고 가정함).

텍스트 설명이 첨부된 다이어그램

추출된 주소 클래스로 수정된 고객 클래스

고객의 주소는 고객의 일부분으로 간주될 수 있으므로 이러한 두 개 클래스 사이에 나타나는 연관은 총계입니다.

외부 중요한 관계 처리 페이지 맨 위

테이블에 있는 각각의 외부 중요한 관계에 대해 연관되는 클래스 사이의 연관을 작성하여 해당 외부 중요한 열에 맵핑된 클래스에서 속성을 제거합니다. 처음에 외부 중요한 열을 속성으로 나타냈으면 해당 클래스에서 이 속성을 제거합니다.

다음과 같은 나열된 주문 테이블의 구조를 가정하십시오.

열 이름  데이터 유형 
번호  Number 
고객_ID  Varchar 

주문 테이블의 구조

위에 나열된 주문 테이블에서 Customer_ID 열은 외부 중요한 참조이며 주문과 연관된 고객의 1차 중요한 값을 포함하고 있습니다. 이 열은 설계 모델에서 다음과 같이 표시됩니다.

아래에 설명된 UML 다이어그램

설계 모델에서 외부 중요한 관계 표시

외부 키는 주문 클래스와 품목 클래스 사이의 연관으로 표시됩니다.

다대다 관계 처리 페이지 맨 위

RDBMS 데이터 모델은 결합 테이블 또는 연관 테이블과의 다대다 관계를 표시합니다. 이러한 테이블을 통해 결합될 수 있는 다른 두 개 테이블의 1차 키를 포함하는 중간 테이블을 사용하여 다대다 관계를 나타낼 수 있습니다. 외부 중요한 참조에서만 단일 외부 중요한 값에 대한 참조를 포함할 수 있으므로 이유 결합 테이블이 필요합니다. 즉, 한 행이 다른 테이블에 있는 다수의 다른 행과 관계되는 경우 결합 테이블이 이 행들을 연관시키는 데 필요합니다.

여러 공급자 중 한 공급자가 제공할 수 있는 제품과 다수의 제품을 제공할 수 있는 특정 공급자의 경우를 고려하십시오. 제품공급자 테이블의 구조는 다음과 같이 정의됩니다.

제품 테이블
열 이름 데이터 유형
Product_ID Number
이름 Varchar
설명 Varchar
가격 Number
공급자 테이블
열 이름 데이터 유형
Supplier_ID Number
이름 Varchar
동/군 Varchar
시/구 Varchar
시/도 Char(2)
우편번호 Varchar
국가 Varchar

제품 및 공급자 테이블 정의

이러한 두 개 테이블을 링크하여 특정 공급자가 제공하는 제품을 찾으려면 다음에 정의된 제품-공급자 테이블이 필요합니다.

제품-공급자 테이블
열 이름  데이터 유형 
Product_ID  Number 
Supplier_ID  Number 

제품-공급자 테이블 정의

결합 테이블은 제품 및 공급자의 1차 키를 포함하여 두 개 테이블을 링크합니다. 테이블의 한 행은 특정 공급자가 특정 제품을 제공한다고 나타냅니다. 특정 공급자 ID와 일치하는 Supplier_ID 열의 모든 행은 해당 공급자가 제공하는 모든 제품을 나열해 줍니다.

설계 모델에서는 객체 모델이 다대다 연관을 직접적으로 나타낼 수 있으므로 이러한 중간 테이블이 필요하지 않습니다. 아래 그림은 앞에서 설명한 대로 공급자에서 추출된 주소 클래스와 함께 공급자 클래스 및 제품 클래스와의 해당 관계를 보여줍니다.

캡션 설명이 있는 UML 다이어그램.

제품 및 공급자 클래스 표시

일반화 도입 페이지 맨 위

종종 일부 유사한 구조를 가지는 테이블을 찾게 됩니다. 데이터 모델에서는 일반화 개념이 전혀 없으므로 공통의 구조를 일부 가지는 둘 이상의 테이블을 표시할 방법이 없습니다. 때때로 공통 구조는 별도의 클래스로 추출한 '암시적' 주소 테이블이 있는 위의 경우와 같이 성능에 대한 비정규화로부터 발생합니다. 기타의 경우에서 테이블은 두 개 이상의 서브클래스를 포함하는 일반화된 상위 클래스로 추출 가능한 근본적인 특성을 공유합니다. 일반화 기회를 찾으려면 여러 개의 테이블에서 반복되는 열을 찾아보십시오. 여기서 테이블은 다르다기 보다는 유사합니다.

다음과 같이 SoftwareProductHardwareProduct 테이블을 고려하십시오.

소프트웨어 제품 테이블
열 이름  데이터 유형 
Product_ID  Number 
이름  Varchar 
설명  Varchar 
가격  Number 
버전  Number 
하드웨어 제품 테이블
열 이름  데이터 유형 
Product_ID  Number 
이름  Varchar 
설명  Varchar 
가격  Number 
버전  Number 


SoftwareProduct 및 HardwareProduct 테이블

파란색으로 강조표시된 열은 동일합니다. 즉, 이 두 개 테이블은 공통된 대부분의 정의를 공유하는 한편 서로 약간만 다를 뿐입니다. 다음 그림에 나타난 바와 같이 제품 클래스의 서브클래스로서 SoftwareProductHardwareProduct를 사용하여 공통 제품 클래스를 추출하여 이를 나타낼 수 있습니다.

텍스트 설명이 첨부된 다이어그램

제품 클래스에 대한 일반화를 표시하는 SoftwareProduct 및 HardwareProduct 클래스

모든 클래스 정의를 수집할 경우 다음 그림에서 주문 입력 시스템의 통합된 클래스 다이어그램(주요 클래스만 해당)을 보여줍니다.

텍스트 설명이 첨부된 합성 UML 다이어그램

통합된 주문 입력 시스템의 클래스 다이어그램

설계 모델에서 RDBMS 작동 복제 페이지 맨 위

일반적으로 관계형 데이터베이스는 객체 지향적이 아니며 객체 모델의 클래스에 대한 조작과 유사한 것으로 보이지 않으므로 작동 복제는 어렵습니다. 위에서 식별한 클래스의 작동을 재구성하는 데 도움을 줄 수 있는 단계는 다음과 같습니다.

  1. 각 속성을 가져오고 설정하는 조작을 작성하십시오. 객체의 속성값을 설정, 변경 및 조회하는 방법이 있어야 합니다. 클래스에서 제공하는 조작을 통해서만 객체의 속성에 액세스할 수 있기 때문에 이와 같은 조작은 해당 클래스에 정의되어 있어야 합니다. 속성값을 설정하는 조작을 작성하는 경우 연관된 열에서 작동할 수 있는 유효성 제한조건을 반드시 포함시키십시오. 유효성 제한조건이 없으면 위의 다이어그램에서 수행되었던 것과 같은 "public" 가시성이 속성에 있는 것으로 표시함으로써(속성 이름 왼쪽에 아이콘 사용) 속성을 getset할 수 있다는 사실만 나타내도록 선택할 수 있습니다.
  2. 연관된 테이블에서 작동하는 각 저장 프로시저의 클래스에 대한 조작을 작성하십시오. 저장 프로시저는 DBMS 자체 내에서 실행하는 실행 가능한 서브루틴입니다. 이 논리는 설계 모델로 변환해야 합니다. 저장 프로시저가 한 클래스에서만 작동하는 경우 저장 프로시저와 동일한 매개변수 및 리턴 유형을 사용하여 해당 클래스에 대한 조작을 작성하십시오. 조작에서 저장 프로시저 작동을 문서화하는데, 해당 저장 프로시저를 통해 조작이 구현되는지 메소드 설명에서 확인하십시오.
  3. 클래스 사이의 연관을 관리하는 조작을 작성하십시오. 두 개 클래스 사이에 연관이 있는 경우 연관을 작성, 관리 및 제거하는 방법이 있어야 합니다. 객체 사이의 연관은 객체 참조를 통해 관리되므로 주문라인 품목 사이의 연관(예: 주문라인 품목 추가)을 작성하려면 주문에 대한 조작이 호출되어 인수로서 라인 품목을 전달합니다(예: Order.add(aLineItem)). 또한 연관을 제거 및 갱신하는 방법도 있어야 합니다(예: Order.remove(aLineItem)Order.change(aLineItem,aNewLineItem)).
  4. 객체 삭제를 처리하십시오. 대상 언어에서 삭제를 명백하게 지원하는 경우 참조 무결성 검사를 구현하는 클래스의 소멸자에 작동을 추가하십시오. 데이터베이스에 참조 무결성 제한조건(예: 계단식 삭제)이 있는 경우 작동이 해당 클래스에 복제되어야 합니다. 예를 들어, 데이터베이스에서 한 주문을 삭제할 때마다 연관된 모든 라인 품목도 삭제해야 한다는 제한조건을 정의할 수 있습니다. 대상 언어에서 가비지 콜렉션을 지원하는 경우 연관된 객체를 가비지 콜렉션으로 수집할 때 테이블에서 열을 제거할 수 있는 메커니즘을 작성하십시오. 데이터베이스 클라이언트가 가비지 콜렉션으로 수집될 객체를 참조하지 않도록 하는 메커니즘을 구현해야 하기 때문에 이러한 메커니즘의 구현은 생각보다 더 어렵습니다(상당히 어렵습니다). 그리고 이는 클라이언트의 한 실제 보기에 지나지 않으므로 실행 환경/가상 시스템의 가비지 콜렉션 성능에 의존할 정도로 충분하지 않습니다.
  5. 조회에서 암시하는 작동을 처리하십시오. 테이블에 액세스하는 Select 명령문을 검토하여 정보 검색 및 조작 방법을 확인하십시오. Select 명령문에서 직접 리턴하는 각 열에 대해 연관된 속성의 public 등록 정보를 true로 설정하십시오. 기타 모든 속성은 private이어야 합니다. Select 명령문에서 계산되는 각 열에 대해 값을 계산하여 리턴하도록 연관된 클래스에 대한 조작을 작성하십시오. 또한 Select 명령문을 고려할 경우 보기 정의에 임베드된 Select 명령문도 포함시키십시오.

설계 모델에서 요소 구성 페이지 맨 위

테이블-클래스 변환에서 작성되는 설계 클래스는 어플리케이션의 전반적인 구조에 기반하여 필요에 따라 설계 모델에서 적합한 설계 패키지 및/또는 설계 서브시스템으로 구성되어야 합니다. 어플리케이션 구조의 개요는 개념: 계층화개념: 소프트웨어 구조를 참조하십시오.



Rational Unified Process   2003.06.15