가이드라인:
|
데이터 모델 요소 |
해당 설계 모델 요소 |
---|---|
테이블 | 클래스 |
열 | 속성 |
식별하지 않는 관계 |
|
교차 테이블 |
연관 클래스 다대다 연관 규정된 연관 |
식별하는 관계 |
|
관계차수 |
다양성 |
열거된 절을 포함하는 확인 제한조건 | <<ENUM>> 클래스 |
스키마 | 패키지 |
설계 모델에서 직접적으로 상관 없는 데이터 모델의 모델 요소가 일부 있습니다. 이 요소에는 데이터베이스의 실제 저장영역 특성을 모델링하여 컴포넌트로 나타나는 테이블 공간과 데이터베이스 자체가 있습니다. 또다른 항목으로 "가상" 테이블이며 설계 모델에서 의미가 없는 데이터베이스 보기가 있습니다. 끝으로 데이터베이스 조작을 최적화하는 데 사용되는 테이블 및 데이터베이스 트리거 함수의 1차 키에 대한 색인은 데이터베이스 및 데이터 모델의 컨텍스트에서만 의미가 있습니다.
변환하려는 각 테이블에 대해 클래스를 작성하여 테이블을 나타내십시오. 각 열에 대해서는 적절한 데이터 유형을 사용하여 해당 클래스의 속성을 작성하십시오. 속성의 데이터 유형을 연관된 열의 데이터 유형과 가능한 근접하게 일치시키십시오.
예
다음 그림에 표시된 구조를 갖춘 고객 데이터베이스 테이블을 고려하십시오.
열 이름 | 데이터 유형 |
---|---|
Customer_ID | Number |
이름 | Varchar |
동/군 | Varchar |
시/구 | Varchar |
시/도 | Char(2) |
우편번호 | Varchar |
국가 | Varchar |
고객 테이블에 대한 테이블 정의
이 시점에서 시작하여 다음 그림에서 표시하는 구조를 갖춘 고객 클래스를 작성합니다.
초기 고객 클래스
이 초기 고객 클래스에는 고객 테이블에 있는 각 열의 속성이 있습니다. 원래 테이블의 열이 조회될 수 있기 때문에 각 속성에는 public 가시성이 있습니다.
주: 속성의 왼쪽에 나열되는 "+" 아이콘은 속성이 'public'임을 나타내며, RDBMS에서는 일반적으로 제한조건 없이 열을 조회할 수 있으므로 RDBMS 테이블에서 도출되는 속성은 모두 기본적으로 public이어야 합니다.
직접 테이블-클래스 맵핑에서 발생하는 클래스는 특히 해당 속성이 다수의 변환된 클래스에 나타나는 경우 별개의 클래스로 분류될 수 있는 속성을 종종 포함하게 됩니다. 이러한 '반복 속성'은 성능의 이유로 테이블의 비정규화에서 발생했거나 지나치게 간소화된 데이터 모델의 결과일 수도 있습니다. 이러한 경우 해당 클래스를 둘 이상의 클래스로 분할하여 정규화된 테이블 보기를 표시하십시오.
예
위에서 고객 클래스를 정의한 후에 다음 클래스와 함께 모든 주소 정보를 포함하는 주소 클래스를 정의할 수 있습니다(주소와 함께 그 밖의 정보도 시스템에 있다고 가정함).
추출된 주소 클래스로 수정된 고객 클래스
고객의 주소는 고객의 일부분으로 간주될 수 있으므로 이러한 두 개 클래스 사이에 나타나는 연관은 총계입니다.
테이블에 있는 각각의 외부 중요한 관계에 대해 연관되는 클래스 사이의 연관을 작성하여 해당 외부 중요한 열에 맵핑된 클래스에서 속성을 제거합니다. 처음에 외부 중요한 열을 속성으로 나타냈으면 해당 클래스에서 이 속성을 제거합니다.
예
다음과 같은 나열된 주문 테이블의 구조를 가정하십시오.
열 이름 | 데이터 유형 |
---|---|
번호 | Number |
고객_ID | Varchar |
주문 테이블의 구조
위에 나열된 주문 테이블에서 Customer_ID 열은 외부 중요한 참조이며 주문과 연관된 고객의 1차 중요한 값을 포함하고 있습니다. 이 열은 설계 모델에서 다음과 같이 표시됩니다.
설계 모델에서 외부 중요한 관계 표시
외부 키는 주문 클래스와 품목 클래스 사이의 연관으로 표시됩니다.
RDBMS 데이터 모델은 결합 테이블 또는 연관 테이블과의 다대다 관계를 표시합니다. 이러한 테이블을 통해 결합될 수 있는 다른 두 개 테이블의 1차 키를 포함하는 중간 테이블을 사용하여 다대다 관계를 나타낼 수 있습니다. 외부 중요한 참조에서만 단일 외부 중요한 값에 대한 참조를 포함할 수 있으므로 이유 결합 테이블이 필요합니다. 즉, 한 행이 다른 테이블에 있는 다수의 다른 행과 관계되는 경우 결합 테이블이 이 행들을 연관시키는 데 필요합니다.
예
여러 공급자 중 한 공급자가 제공할 수 있는 제품과 다수의 제품을 제공할 수 있는 특정 공급자의 경우를 고려하십시오. 제품 및 공급자 테이블의 구조는 다음과 같이 정의됩니다.
|
|
제품 및 공급자 테이블 정의
이러한 두 개 테이블을 링크하여 특정 공급자가 제공하는 제품을 찾으려면 다음에 정의된 제품-공급자 테이블이 필요합니다.
제품-공급자 테이블 | |
---|---|
열 이름 | 데이터 유형 |
Product_ID | Number |
Supplier_ID | Number |
제품-공급자 테이블 정의
이 결합 테이블은 제품 및 공급자의 1차 키를 포함하여 두 개 테이블을 링크합니다. 테이블의 한 행은 특정 공급자가 특정 제품을 제공한다고 나타냅니다. 특정 공급자 ID와 일치하는 Supplier_ID 열의 모든 행은 해당 공급자가 제공하는 모든 제품을 나열해 줍니다.
설계 모델에서는 객체 모델이 다대다 연관을 직접적으로 나타낼 수 있으므로 이러한 중간 테이블이 필요하지 않습니다. 아래 그림은 앞에서 설명한 대로 공급자에서 추출된 주소 클래스와 함께 공급자 클래스 및 제품 클래스와의 해당 관계를 보여줍니다.
제품 및 공급자 클래스 표시
종종 일부 유사한 구조를 가지는 테이블을 찾게 됩니다. 데이터 모델에서는 일반화 개념이 전혀 없으므로 공통의 구조를 일부 가지는 둘 이상의 테이블을 표시할 방법이 없습니다. 때때로 공통 구조는 별도의 클래스로 추출한 '암시적' 주소 테이블이 있는 위의 경우와 같이 성능에 대한 비정규화로부터 발생합니다. 기타의 경우에서 테이블은 두 개 이상의 서브클래스를 포함하는 일반화된 상위 클래스로 추출 가능한 근본적인 특성을 공유합니다. 일반화 기회를 찾으려면 여러 개의 테이블에서 반복되는 열을 찾아보십시오. 여기서 테이블은 다르다기 보다는 유사합니다.
예
다음과 같이 SoftwareProduct 및 HardwareProduct 테이블을 고려하십시오.
|
|
SoftwareProduct 및 HardwareProduct 테이블
파란색으로 강조표시된 열은 동일합니다. 즉, 이 두 개 테이블은 공통된 대부분의 정의를 공유하는 한편 서로 약간만 다를 뿐입니다. 다음 그림에 나타난 바와 같이 제품 클래스의 서브클래스로서 SoftwareProduct 및 HardwareProduct를 사용하여 공통 제품 클래스를 추출하여 이를 나타낼 수 있습니다.
제품 클래스에 대한 일반화를 표시하는 SoftwareProduct 및 HardwareProduct 클래스
모든 클래스 정의를 수집할 경우 다음 그림에서 주문 입력 시스템의 통합된 클래스 다이어그램(주요 클래스만 해당)을 보여줍니다.
통합된 주문 입력 시스템의 클래스 다이어그램
일반적으로 관계형 데이터베이스는 객체 지향적이 아니며 객체 모델의 클래스에 대한 조작과 유사한 것으로 보이지 않으므로 작동 복제는 어렵습니다. 위에서 식별한 클래스의 작동을 재구성하는 데 도움을 줄 수 있는 단계는 다음과 같습니다.
테이블-클래스 변환에서 작성되는 설계 클래스는 어플리케이션의 전반적인 구조에 기반하여 필요에 따라 설계 모델에서 적합한 설계 패키지 및/또는 설계 서브시스템으로 구성되어야 합니다. 어플리케이션 구조의 개요는 개념: 계층화 및 개념: 소프트웨어 구조를 참조하십시오.
Rational Unified Process
|