가이드라인:
|
설계 모델 요소 |
해당 데이터 모델 요소 |
---|---|
클래스 | 테이블 |
속성 | 열 |
연관 |
식별하지 않는 관계 |
연관 클래스 |
교차 테이블 |
합성 총계 |
식별하는 관계 |
다대다 연관 |
교차 테이블 |
다양성 |
관계차수 |
규정된 연관 |
교차 테이블 |
일반화(상속) | 별도 테이블 |
설계 모델에서 지속적 클래스는 시스템에서 저장해야 하는 정보를 나타냅니다. 개념적으로 이러한 클래스는 관계형 설계와 비슷할 수 있습니다. (예를 들어, 설계 모델에서 클래스는 일부 방식에 따라 관계형 스키마의 엔티티로서 반영될 수 있습니다.) 그렇지만 프로젝트가 구현화 단계에서 구성 단계로 이동함에 따라 설계 모델과 관계형 데이터 모델의 목표는 분기됩니다. 관계형 데이터베이스 개발에서는 데이터의 정규화가 목적이지만 설계 모델에서는 점점 더 복잡한 작동의 캡슐화가 목적이기 때문에 이러한 분기가 발생합니다. 이와 같은 두 개 관점인 데이터 및 작동의 분기는 두 개 모델에서 관련되는 요소 사이의 맵핑을 요구하게 됩니다.
세 번째 정상 형태로 작성된 관계형 데이터베이스에서 테이블의 각 행(각 "튜플")은 하나의 객체로 간주됩니다. 테이블의 각 열은 한 클래스의 지속적 속성 하나와 등등합니다. (지속적 클래스에 임시 속성이 있을 수 있습니다.) 따라서 다른 클래스에 대한 연관이 전혀 없는 간단한 경우에서 두 세계간의 맵핑은 단순합니다. 속성의 데이터 유형은 열에 허용되는 데이터 유형 중 하나와 일치합니다.
예
다음과 같은 고객 클래스가 있습니다.
RDBMS에서 모델링된 경우 Customer_ID, 이름 및 주소 열을 갖춘 고객 테이블로 변환됩니다.
이 테이블의 한 인스턴스는 다음과 같이 가시화될 수 있습니다.
각각의 지속적 속성의 경우 관계형 데이터 모델에서 지속적 객체를 적절하게 모델링하는 데 사용될 추가 정보를 도출하도록 요구하는 질문이 있어야 합니다. 예를 들면, 다음과 같습니다.
지속적 두 객체 간 연관은 연관되는 객체에 대한 외부 키로 인식됩니다. 외부 키는 연관되는 객체의 1차 중요한 값을 포함하는 한 테이블의 열입니다.
예:
주문 및 고객 사이에 다음 연관이 있다고 가정하십시오.
이 연관이 관계형 테이블에 맵핑되는 경우 결과는 주문 테이블 및 고객 테이블이 됩니다. 주문 테이블에는 속성이 나열되는 열이 있고 고객 테이블에서 연관된 행의 1차 키를 참조하는 외부 키를 포함하는 Customer_ID라는 추가 열이 있습니다. 제공된 주문의 경우 Customer_ID 열에는 해당 주문이 연관되는 고객의 ID가 있습니다. 외부 키를 사용하면 RDBMS에서 관계되는 정보를 모두 결합할 수 있습니다.
총계도 외부 중요한 관계를 사용하여 모델링됩니다.
예:
주문 및 라인 품목 사이에 다음 연관이 있다고 가정하십시오.
이 연관이 관계형 테이블에 맵핑되는 경우 결과는 주문 테이블 및 품목 테이블이 됩니다. 라인 품목 테이블에는 속성이 나열되는 열이 있고 주문 테이블에서 연관된 행을 참조하는 외부 키를 포함하는 Order_ID라는 추가 열이 있습니다. 제공된 라인 품목의 경우 Order_ID 열에는 라인 품목이 연관되는 해당 주문의 Order_ID가 있습니다. 외부 키를 사용하면 RDBMS에서 결합 연산을 최적화할 수 있습니다.
또한 데이터 모델에서 참조 무결성을 제공하는 계단식 삭제 제한조건을 반드시 구현해야 합니다. 주문을 삭제할 때마다 이러한 구현이 수행되면 해당 라인 품목도 모두 삭제됩니다.
표준 관계형 데이터 모델에서는 직접적인 방법으로 상속 모델링을 지원하지 않습니다. 다수의 전략이 상속을 모델링하는 데 사용될 수 있습니다. 이러한 전략은 다음과 같이 요약할 수 있습니다.
관계형 모델링에서 표준 기술은 교차 엔티티를 사용하여 다대다 연관을 나타내는 것입니다. 여기에서는 교차 테이블을 사용하여 연관을 나타내는 동일한 접근 방법이 적용됩니다.
예:
다양한 제품을 제공하는 공급자가 있는 경우와 다양한 공급자를 통해 한 제품을 제공할 수 있는 경우 솔루션은 공급자/제품 테이블을 작성하는 것입니다. 이 테이블에는 공급자 및 제품 테이블의 1차 키만 포함되며 공급자 및 관련 제품을 링크하기 위해 사용됩니다. 객체 모델은 전적으로 관계형 데이터 모델에서 연관을 나타내는 데에만 사용되므로 이 테이블에 유사한 내용은 전혀 없습니다.
일단 설계 클래스가 데이터 모델에서 테이블 및 해당 관계로 변환되었으면 이 모델은 참조 무결성을 구현하고 보기 및 저장 프로시저를 통해 데이터 액세스를 최적화하는 데 필요한 경우 개선됩니다. 자세한 정보는 가이드라인: 데이터 모델을 참조하십시오.
대부분의 어플리케이션 설계 툴은 데이터 모델에서 데이터 정의 언어(DDL) 스크립트 생성 및/또는 데이터베이스 생성을 지원합니다. 데이터베이스의 포워드 엔지니어링은 전반적인 어플리케이션 개발 및 통합 활동의 일부분으로 계획되어야 합니다. 데이터 모델에서 데이터베이스 포워드 엔지니어링의 시기 및 빈도는 특정 프로젝트 상황에 따라 달라집니다. 새 데이터베이스를 작성하는 새 어플리케이션 개발 프로젝트에서는 초기 포워드 엔지니어링이 구현화 단계 종료 시까지 어플리케이션의 안정된 구조적 버전을 구현하는 작업의 일부분으로 수행되어야 합니다. 기타의 경우 초기 포워드 엔지니어링은 구성 단계의 초기 반복에서 수행될 수 있습니다.
포워드 엔지니어링될 수 있는 데이터 모델의 모델 요소 유형은 프로젝트에서 사용되는 특정 설계 툴 및 RDBMS에 따라 다양합니다. 일반적으로 테이블, 보기, 저장 프로시저, 트리거 및 색인을 포함하여 데이터 모델의 주요 구조적 요소는 데이터베이스에 포워드 엔지니어링될 수 있습니다.
![]() |
이 컨텐츠는 Applied Information Science에 의해 부분적으로 개발 또는 전적으로 개발되었습니다. |
Rational Unified Process
|