이 가이드라인은 데이터베이스의 리버스 엔지니어링 및 생성된 데이터
모델 테이블을 디자인 모델의 디자인
클래스로 맵핑하는 작업과 관련된 단계를 설명합니다. 이 프로세스는 데이터베이스
디자이너가 전개 개발 주기의 일부로 데이터베이스에 대한 수정사항 개발을 도입할 때 사용할 수 있습니다. 데이터베이스 디자이너는 프로젝트의 개발 라이프사이클 내내 리버스 엔지니어링 프로세스를 관리해야 합니다.
대부분의 경우 리버스 엔지니어링 프로세스는 프로젝트 라이프사이클 초반에 수행되며 데이터 디자인의 변경은 데이터베이스의 후속 리버스 엔지니어링을 수행하지 않고 점진적으로 관리됩니다.
데이터베이스의 리버스 엔지니어링 및 결과로 생성된 데이터 모델 요소를 디자인 모델 요소로 변환하는 프로세스의 기본 단계는 다음과 같습니다.
-
데이터베이스에서 지속적 데이터의 실제 레이아웃을 표시하도록 테이블을 포함하는 실제 데이터 모델을 작성하십시오. 이 단계는 관계형 데이터베이스 관리 시스템(RDBMS)에서 제공하는 도구 또는 최신 비주얼
모델링 도구를 사용하여 자동으로 수행될 수 있습니다.
-
실제 데이터 모델의 테이블을 디자인 모델의 디자인 클래스로 변환하십시오. 이 단계는 초기 변환 및 뒤따르는 수동 조정에 대한 자동 도구 지원의 결합을 통해 수행될 수 있습니다.
-
디자인 모델에서 클래스 사이의 연관을 정의하십시오.
-
해당 데이터 모델 요소에서 수행한 조치에 따라 디자인 모델의 클래스에 적합한 오퍼레이션을 정의하십시오.
-
필요한 경우 디자인 모델의 클래스를 서브시스템 및 패키지로 그룹화하십시오.
보통 데이터베이스 또는 DDL(Data Definition Language) 스크립트 리버스 엔지니어링 프로세스는 모델 요소 세트(테이블, 뷰, 스토어드 프로시저 등)를 생성합니다. 데이터베이스 복잡도에 따라
데이터베이스 디자이너는 리버스 엔지니어링 모델 요소를 논리적으로 관련된 테이블 세트를 포함하는 주제 영역 패키지로 파티션해야 할 수도 있습니다.
다음 프로시저를 수행하여 데이터 모델의 모델 요소에서 디자인 클래스를 생성할 수 있습니다. 클래스 모델에서 데이터베이스의 구조 복제는 비교적 간단합니다. 아래 나열된 프로세스에서는 데이터 모델 요소를 디자인 모델
요소로 변환하는 알고리즘을 설명합니다.
아래 표에서는 디자인 모델 요소 및 데이터 모델 요소 사이의 일반 맵핑에 대한 요약을 표시합니다.
데이터 모델 요소
|
해당하는 디자인 모델 요소
|
테이블
|
클래스
|
열
|
속성
|
비식별 관계
|
연관
|
교차 테이블
|
연관 클래스
다수 대 다수 연관
규정된 연관
|
식별 관계
|
집계
|
카디널리티
|
다중성
|
나열된 절에서 검사 제한조건
|
<<ENUM>> 클래스
|
스키마
|
패키지
|
데이터 모델에는 디자인 모델과 직접적으로 상관되지 않은 일부 모델 요소가 있습니다. 이 요소는 테이블 공간 및 데이터베이스 자체를 포함합니다. 이 요소는 데이터베이스의 실제 저장영역 특성을 모델링하며 컴포넌트로
표시됩니다. 다른 항목은 데이터베이스 뷰로서 "가상" 테이블에 해당하며 디자인 모델에서는 아무 의미가 없습니다. 마지막으로 데이터베이스의 오퍼레이션을 최적화할 때 사용하는 데이터베이스 트리거 함수 및 테이블의 1차
키에 대한 색인은 데이터 모델 및 데이터베이스의 컨텍스트에서만 중요합니다.
변환할 각 테이블에서, 테이블을 표시할 클래스를 작성하십시오. 각 열에서, 적절한 데이터 유형의 속성을 클래스에 작성하십시오. 속성의 데이터 유형 및 연관된 열의 데이터 유형을 가능한 가깝게 일치시키십시오.
예제
다음 그림에 표시되는 구조를 가지는 Customer 데이터베이스 테이블을 고려하십시오.
열 이름
|
데이터 유형
|
Customer_ID
|
Number
|
이름
|
Varchar
|
Street
|
Varchar
|
City
|
Varchar
|
State/Province
|
Char(2)
|
Zip/Postal Code
|
Varchar
|
Country
|
Varchar
|
Customer 테이블에 대한 테이블 정의
이 시점부터 다음 그림에 표시되는 구조를 가지는 Customer 클래스를 작성합니다.
초기 Customer 클래스
이 초기 Customer 클래스에서 Customer 테이블의 각 열에는 속성이 있습니다. 원래 테이블의 열을 조회할 수 있기 때문에 각 속성은 public 가시성을 가집니다.
속성 왼쪽에 나열된 "+" 아이콘은 속성이 'public'임을 표시함에 유의하십시오. 일반적으로 RDBMS에서는 제한 없이 모든 열을 조회할 수 있기 때문에 기본적으로 RDBMS 테이블에서 파생된 모든 속성은
public입니다.
직접 테이블-클래스 맵핑에서 표시된 클래스는 종종 별도의 클래스로 구분되는 속성을 포함할 수 있습니다. 특히, 속성이 여러 개의 변환된 클래스에 나타나는 경우가 이에 해당합니다. 이런 '반복된 속성'은 성능상의
이유로 테이블을 비정규화하는 경우 또는 데이터 모델을 지나치게 단순화하는 경우 나타날 수 있습니다. 이 경우 해당 클래스를 둘 이상의 클래스로 분할하여 테이블의 정규화된 뷰를 표시하십시오.
예제
위에서 Customer 클래스를 정의한 후 모든 주소 정보를 포함하는 Address 클래스를 정의할 수 있습니다. (이때 시스템에 주소를 포함하는 다른 항목도 있다고 가정해 보십시오.)
그러면 다음과 같은 클래스가 나타납니다.
개정된 Customer 클래스(추출된 Address 클래스가 포함됨)
이 두 클래스에서 도출되는 연관은 집계입니다. 고객의 주소는 고객의 파트로 볼 수 있기 때문입니다.
테이블의 각 외부 키 관계의 경우, 클래스에서 외부 키 열에 맵핑된 속성을 제거하여 연관된 클래스 사이에서 연관을 작성하십시오. 처음에 외부 키 열이 속성으로 표시되는 경우 클래스에서 제거하십시오.
예제
아래 나열된 Order 테이블의 구조를 다음과 같이 가정해 보십시오.
열 이름
|
데이터 유형
|
Number
|
Number
|
Customer_ID
|
Varchar
|
Order 테이블 구조
위에서 나열한 Order 테이블에서 Customer_ID 열은 외부 키 참조입니다. 이 열에는 주문과 연관된 고객의 1차 키 값이 있습니다. 이 값을 디자인 모델에서 다음과
같이 표시합니다.
디자인 모델에서 외부 키 관계 표시
외부 키는 Order 및 Item 클래스 사이의 연관으로 표시됩니다.
RDBMS 데이터 모델은 결합 테이블 또는 연관 테이블이라고 하는 다수 대 다수 관계를 표시합니다. 이 테이블을 사용하면 함께 결합할 수 있는 다른 테이블 두 개의 1차 키를 포함하는 임시
테이블을 사용하여 다수 대 다수 관계를 표시할 수 있습니다. 결합 테이블이 필요한 이유는 외부 키 참조가 단일 외부 키 값에 대한 참조만 포함할 수 있기 때문입니다. 단일 행이 다른 테이블의 다른 많은 행과 관련이
있는 경우 이들을 연관시킬 때 결합 테이블이 필요합니다.
예제
많은 수의 공급자 중 하나가 많은 수의 제품을 제공하는 경우 및 많은 수의 공급자가 많은 수의 제품을 제공하는 경우를 고려하십시오. Product 및
Supplier 테이블의 구조는 다음과 같이 정의됩니다.
Product 테이블
열 이름
|
데이터 유형
|
Product_ID
|
Number
|
이름
|
Varchar
|
설명
|
Varchar
|
Price
|
Number
|
|
Supplier 테이블
열 이름
|
데이터 유형
|
Supplier_ID
|
Number
|
이름
|
Varchar
|
Street
|
Varchar
|
City
|
Varchar
|
State/Province
|
Char(2)
|
Zip/Postal Code
|
Varchar
|
Country
|
Varchar
|
|
Product 및 Supplier 테이블 정의
특정 공급자가 제공하는 제품을 찾기 위해 두 테이블을 함께 링크시키려면 아래 표에 정의된 것과 같은 Product-Supplier 테이블이 필요합니다.
Product-Supplier 테이블
|
열 이름
|
데이터 유형
|
Product_ID
|
Number
|
Supplier_ID
|
Number
|
Product-Supplier 테이블 정의
이 결합 테이블에는 제품 및 공급자를 함께 링크하는, 제품 및 공급자의 1차 키가 있습니다. 테이블의 행은 특정 공급자가 특정 제품을 제공함을 표시합니다. Supplier_ID 열이 특정 공급자 ID와
일치하는 모든 행에서 해당 공급자가 제공하는 모든 제품 목록이 제공됩니다.
디자인 모델에서는 오브젝트 모델로 직접 다수 대 다수 연관을 표시할 수 있기 때문에 이 임시 테이블은 불필요합니다. Supplier 및 Product 클래스와 해당 관계가 이전 논의에 따라
Supplier에서 추출된 Address 클래스와 함께 아래 그림에서 표시됩니다.
Product 및 Supplier 클래스 표시
테이블의 일부 구조가 유사한 경우가 종종 있습니다. 데이터
모델의 경우 일반화 개념이 없으므로 두 개 이상의 테이블에서 일부 구조가 공통됨을 표시하는 방법이 없습니다. 때때로 성능을 위한 비정규화로 인해 공통 구조가 발생하기도 합니다(예: 위에서 언급한 별도의
클래스로 추출한 '내재적' Address 테이블). 다른 경우 테이블에서 둘 이상의 서브클래스를 통해 일반화된 상위 클래스로 추출할 수 있는 추가 기본 특성을 공유합니다. 일반화 기회를 찾으려면 여러
테이블에서 반복된 열을 찾으십시오. 이런 테이블은 차이점보다 유사점이 더 많습니다.
예제
아래에 표시된 대로, 다음과 같은 SoftwareProduct 및 HardwareProduct 테이블을 고려하십시오.
SoftwareProduct 테이블
열 이름
|
데이터 유형
|
Product_ID
|
Number
|
Name
|
Varchar
|
Description
|
Varchar
|
Price
|
Number
|
Version
|
Number
|
|
HardwareProduct 테이블
열 이름
|
데이터 유형
|
Product_ID
|
Number
|
Name
|
Varchar
|
Description
|
Varchar
|
Price
|
Number
|
Version
|
Number
|
|
SoftwareProduct 및 HardwareProduct 테이블
파란색으로 강조표시된 열은 서로 동일함에 유의하십시오. 이 두 테이블은 대부분의 정의를 공통적으로 공유하며 약간만 다릅니다. 다음 그림에 표시된 대로 Product의 서브클래스로
SoftwareProduct 및 HardwareProduct에서 공통 Product 클래스를 추출하여 표시할 수 있습니다.
SoftwareProduct 및 HardwareProduct 클래스(Product 클래스로의 일반화 표시)
아래 그림에서는 모든 클래스 정의를 함께 모아서 주문 입력 시스템의 통합 클래스 다이어그램을 표시합니다(주요 클래스만).
주문 입력 시스템의 통합 클래스 다이어그램
동작 복제는 더 어렵습니다. 보통 관계형 데이터베이스는 객체 지향이 아니며 오브젝트 모델에 있는 클래스의 오퍼레이션과 유사한 내용은 표시하지 않기 때문입니다. 다음 단계는 위에서 식별한 클래스의 동작을 다시
구성하는 데 도움을 줄 수 있습니다.
-
각 속성을 가져오고 설정하는 오퍼레이션을 작성하십시오. 오브젝트의 속성 값을 설정, 변경 및 조회하는 방법이 필요합니다. 오브젝트의 속성에 액세스하는 유일한 방법은 클래스에서 제공하는
오퍼레이션을 사용하는 것뿐이므로 클래스에 해당 오퍼레이션을 정의해야 합니다. 속성 값을 설정하는 오퍼레이션을 작성하는 경우 연관된 열에서 조작할 수 있는 유효성 검증 제한조건을 통합해야 합니다. 유효성 검증
제한조건이 없는 경우 위 다이어그램에서 수행한 대로 속성을 "public" 가시성으로 표시하여 속성을 가져오고 설정할 수 있다는 사실을 단순히 표시하도록 선택할 수 있습니다(속성
이름 왼쪽에 아이콘 표시).
-
각 스토어드 프로시저의 클래스에 연관된 테이블에서 조작할 오퍼레이션을 작성하십시오. 스토어드 프로시저는 DBMS 자체에서 실행하는 실행 가능 서브루틴입니다. 이 로직은 디자인 모델로 변환할 때
필요합니다. 스토어드 프로시저가 하나의 클래스에서만 조작되는 경우 스토어드 프로시저와 매개변수 및 리턴 유형이 동일한 클래스에 오퍼레이션을 작성하십시오. 오퍼레이션에 스토어드 프로시저의 동작을
문서화하십시오. 이때 오퍼레이션이 스토어드 프로시저으로 구현되었음을 메소드 설명에 기록하십시오.
-
클래스 사이에서 연관을 관리하는 오퍼레이션을 작성하십시오. 두 클래스 사이에 연관이 있는 경우 연관을 작성, 관리 및 제거하는 방법이 필요합니다. 오브젝트 사이의 연관은 오브젝트 참조를 통해
관리합니다. Order 및 LineItem 사이의 연관을 작성하려면(즉, LineItem을 Order에 추가) LineItem을 인수로 전달하여
Order에 대한 오퍼레이션을 호출합니다(즉, Order.add(aLineItem)). 연관을 제거 및 갱신하는 방법도 필요합니다(즉,
Order.remove(aLineItem) 및 Order.change(aLineItem,aNewLineItem)).
-
오브젝트 삭제를 처리하십시오. 대상 언어에서 명시적 삭제를 지원하는 경우 참조 무결성 확인을 구현하는 클래스의 파괴자(destructor)에 동작을 추가하십시오. 데이터베이스에 참조 무결성
제한조건이 있는 경우(예: 계단식 삭제) 적절한 클래스에 동작을 복제해야 합니다. 예를 들어 데이터베이스에서 Order를 삭제할 때마다 연관된 모든 LineItem도
삭제된다는 점을 알려주는 제한조건을 정의할 수 있습니다. 대상 언어에서 가비지 콜렉션을 지원하는 경우 연관된 오브젝트의 가비지 콜렉션 수행 시 테이블에서 행을 제거할 수 있는 메커니즘을 작성하십시오. 이는
생각만큼 쉽지 않다는 점에 유의하십시오. 가비지 콜렉션이 수행될 오브젝트에 대한 참조를 포함하는 데이터베이스 클라이언트가 없도록 하는 메커니즘을 구현해야 하기 때문입니다. 실행 환경/가상 시스템의 가비지
콜렉션 기능에 의존하는 것은 너무 제한된 형태이므로 충분하지 않습니다.
-
조회로 내재된 동작을 처리하십시오. 테이블에 액세스하는 Select 문을 점검하여 정보 검색 및 조작 방법을 확인하십시오. Select 문에서 직접 리턴되는 각 열에서, 연관된 속성의
public 특성을 true로 설정하십시오. 기타 모든 속성은 private이어야 합니다. Select 문의 계산된 각 열에서, 연관된 클래스에 대한 오퍼레이션을
작성하여 값을 계산하고 리턴하십시오. Select 문을 고려할 때 뷰 정의에 임베드된 Select 문도 포함하십시오.
테이블에서 클래스로의 변환으로 작성된 디자인 클래스는 필요한 경우 응용프로그램의 전반적인 아키텍처 구조에 기반하여 디자인 모델에서 적절한 디자인
패키지 및/또는 디자인 서브시스템으로 구성되어야 합니다. 응용프로그램 아키텍처 개요는 개념: 계층화 및 개념: 소프트웨어
아키텍처를 참조하십시오.
|