주제

소개페이지 맨 위

이 가이드라인에서는 설계 모델의 지속적 설계 클래스데이터 모델의 테이블에 맵핑하는 방법을 설명합니다.  

설계 모델 요소를 데이터 모델 요소로 변환페이지 맨 위

설계 모델의 지속적 클래스는 데이터 모델의 테이블로 변환할 수 있습니다. 다음 표에서는 설계 모델 요소와 데이터 모델 요소 사이의 맵핑 요약을 보여줍니다.

설계 모델 요소

해당 데이터 모델 요소

클래스 테이블
속성

연관

식별하지 않는 관계

연관 클래스

교차 테이블

합성 총계

식별하는 관계

다대다 연관

교차 테이블

다양성

관계차수

규정된 연관

교차 테이블

일반화(상속) 별도 테이블

지속적 클래스를 테이블에 맵핑페이지 맨 위

설계 모델에서 지속적 클래스는 시스템에서 저장해야 하는 정보를 나타냅니다. 개념적으로 이러한 클래스는 관계형 설계와 비슷할 수 있습니다. (예를 들어, 설계 모델에서 클래스는 일부 방식에 따라 관계형 스키마의 엔티티로서 반영될 수 있습니다.) 그렇지만 프로젝트가 구현화 단계에서 구성 단계로 이동함에 따라 설계 모델과 관계형 데이터 모델의 목표는 분기됩니다. 관계형 데이터베이스 개발에서는 데이터의 정규화가 목적이지만 설계 모델에서는 점점 더 복잡한 작동의 캡슐화가 목적이기 때문에 이러한 분기가 발생합니다. 이와 같은 두 개 관점인 데이터 및 작동의 분기는 두 개 모델에서 관련되는 요소 사이의 맵핑을 요구하게 됩니다.

세 번째 정상 형태로 작성된 관계형 데이터베이스에서 테이블의 각 행(각 "튜플")은 하나의 객체로 간주됩니다. 테이블의 각 열은 한 클래스의 지속적 속성 하나와 등등합니다. (지속적 클래스에 임시 속성이 있을 수 있습니다.) 따라서 다른 클래스에 대한 연관이 전혀 없는 간단한 경우에서 두 세계간의 맵핑은 단순합니다. 속성의 데이터 유형은 열에 허용되는 데이터 유형 중 하나와 일치합니다.

다음과 같은 고객 클래스가 있습니다.

고객 클래스

RDBMS에서 모델링된 경우 Customer_ID, 이름 및 주소 열을 갖춘 고객 테이블로 변환됩니다.

이 테이블의 한 인스턴스는 다음과 같이 가시화될 수 있습니다.

새 고객 객체 테이블의 일부를 보여주는 다이어그램

지속적 속성 및 키 페이지 맨 위

각각의 지속적 속성의 경우 관계형 데이터 모델에서 지속적 객체를 적절하게 모델링하는 데 사용될 추가 정보를 도출하도록 요구하는 질문이 있어야 합니다. 예를 들면, 다음과 같습니다.

  • 이러한 지속적 속성이 중요한 또는 키의 일부분으로 역할을 수행할 수 있습니까? 예: "Z 속성과 함께 X 속성이 객체를 고유하게 식별합니다." 고객 테이블에서 Customer_ID는 1차 키를 나타냅니다.
  • 해당 속성의 최소값 및 최대값은 무엇입니까?
  • 이 속성을 키로 사용하여 검색할 수 있습니까? 인스턴스의 경우 "일반적으로 Y > 1000인 모든 인스턴스를 검색합니다."는 Select 명령문에서 필터의 일부분일 수 있습니다.
  • 해당 속성에 "X 속성이 100,000개 전송 문자당 재전송의 수입니다."라는 설명이 있습니까?
  • 해당 속성에 가능한 숫자값 및 여러 숫자값 사이에 필요한 변환이 있습니까?
  • 누가 해당 속성을 갱신할 수 있습니까? 예: "T는 nn 권한 클래스에 속하는 사용자만이 변경할 수 있습니다."
  • 누가 해당 속성을 읽을 수 있습니까? 예: "P는 yy 및 zz 권한 클래스에 속하는 사용자가 읽을 수 있습니다." 또는 "P는 Vi 및 Vj 보기에 포함됩니다."
  • 볼륨 및 빈도에 관한 적절한 정보가 있습니까? 예: "A의 발생 빈도는 최대 50,000회입니다." 또는 "매일 평균 2,000개의 A가 변경됩니다."
  • 고유한 속성입니까? 예: 한 사용자만이 동일한 드라이버의 라이센스 번호를 보유합니다.

지속적 객체 간 연관을 데이터 모델에 맵핑 페이지 맨 위

지속적 두 객체 간 연관은 연관되는 객체에 대한 외부 키로 인식됩니다. 외부 키는 연관되는 객체의 1차 중요한 값을 포함하는 한 테이블의 열입니다.

예:

주문 및 고객 사이에 다음 연관이 있다고 가정하십시오.

주문 및 고객 사이의 연관을 보여주는 UML 다이어그램

이 연관이 관계형 테이블에 맵핑되는 경우 결과는 주문 테이블 및 고객 테이블이 됩니다. 주문 테이블에는 속성이 나열되는 열이 있고 고객 테이블에서 연관된 행의 1차 키를 참조하는 외부 키를 포함하는 Customer_ID라는 추가 열이 있습니다. 제공된 주문의 경우 Customer_ID 열에는 해당 주문이 연관되는 고객의 ID가 있습니다. 외부 키를 사용하면 RDBMS에서 관계되는 정보를 모두 결합할 수 있습니다.

총계 연관을 데이터 모델에 맵핑 페이지 맨 위

총계도 외부 중요한 관계를 사용하여 모델링됩니다.

예:

주문 및 라인 품목 사이에 다음 연관이 있다고 가정하십시오.

주문 및 라인 품목 클래스

이 연관이 관계형 테이블에 맵핑되는 경우 결과는 주문 테이블 및 품목 테이블이 됩니다. 라인 품목 테이블에는 속성이 나열되는 열이 있고 주문 테이블에서 연관된 행을 참조하는 외부 키를 포함하는 Order_ID라는 추가 열이 있습니다. 제공된 라인 품목의 경우 Order_ID 열에는 라인 품목이 연관되는 해당 주문의 Order_ID가 있습니다. 외부 키를 사용하면 RDBMS에서 결합 연산을 최적화할 수 있습니다.

또한 데이터 모델에서 참조 무결성을 제공하는 계단식 삭제 제한조건을 반드시 구현해야 합니다. 주문을 삭제할 때마다 이러한 구현이 수행되면 해당 라인 품목도 모두 삭제됩니다.

데이터 모델에서 일반화 관계 모델링 페이지 맨 위

표준 관계형 데이터 모델에서는 직접적인 방법으로 상속 모델링을 지원하지 않습니다. 다수의 전략이 상속을 모델링하는 데 사용될 수 있습니다. 이러한 전략은 다음과 같이 요약할 수 있습니다.

  • 별도의 테이블을 사용하여 수퍼클래스와 서브클래스를 나타내십시오. 서브클래스 테이블에는 수퍼클래스 테이블을 참조하는 외부 키가 포함되어야 합니다. 서브클래스 객체를 인스턴스화하려면 두 개의 테이블을 결합해야 합니다. 이러한 접근 방법은 개념적으로 쉽게 이해할 수 있고 모델을 용이하게 변경할 수 있지만 종종 추가 작업으로 인해 불완전하게 수행됩니다.
  • 서브클래스 테이블에 있는 별도의 열로서 상속되는 모든 속성 및 연관을 중복시키십시오. 이 방법은 표준 관계형 데이터 모델에서 비정규화와 유사합니다.

데이터 모델에서 다대다 연관 모델링 페이지 맨 위

관계형 모델링에서 표준 기술은 교차 엔티티를 사용하여 다대다 연관을 나타내는 것입니다. 여기에서는 교차 테이블을 사용하여 연관을 나타내는 동일한 접근 방법이 적용됩니다.

예:

다양한 제품을 제공하는 공급자가 있는 경우와 다양한 공급자를 통해 한 제품을 제공할 수 있는 경우 솔루션은 공급자/제품 테이블을 작성하는 것입니다. 이 테이블에는 공급자 및 제품 테이블의 1차 키만 포함되며 공급자 및 관련 제품을 링크하기 위해 사용됩니다. 객체 모델은 전적으로 관계형 데이터 모델에서 연관을 나타내는 데에만 사용되므로 이 테이블에 유사한 내용은 전혀 없습니다.

데이터 모델 개선페이지 맨 위

일단 설계 클래스가 데이터 모델에서 테이블 및 해당 관계로 변환되었으면 이 모델은 참조 무결성을 구현하고 보기 및 저장 프로시저를 통해 데이터 액세스를 최적화하는 데 필요한 경우 개선됩니다. 자세한 정보는 가이드라인: 데이터 모델을 참조하십시오.

관계형 데이터베이스 포워드 엔지니어링페이지 맨 위

대부분의 어플리케이션 설계 툴은 데이터 모델에서 데이터 정의 언어(DDL) 스크립트 생성 및/또는 데이터베이스 생성을 지원합니다. 데이터베이스의 포워드 엔지니어링은 전반적인 어플리케이션 개발 및 통합 활동의 일부분으로 계획되어야 합니다. 데이터 모델에서 데이터베이스 포워드 엔지니어링의 시기 및 빈도는 특정 프로젝트 상황에 따라 달라집니다. 새 데이터베이스를 작성하는 새 어플리케이션 개발 프로젝트에서는 초기 포워드 엔지니어링이 구현화 단계 종료 시까지 어플리케이션의 안정된 구조적 버전을 구현하는 작업의 일부분으로 수행되어야 합니다. 기타의 경우 초기 포워드 엔지니어링은 구성 단계의 초기 반복에서 수행될 수 있습니다.  

포워드 엔지니어링될 수 있는 데이터 모델의 모델 요소 유형은 프로젝트에서 사용되는 특정 설계 툴 및 RDBMS에 따라 다양합니다. 일반적으로 테이블, 보기, 저장 프로시저, 트리거 및 색인을 포함하여 데이터 모델의 주요 구조적 요소는 데이터베이스에 포워드 엔지니어링될 수 있습니다.




이 컨텐츠는 Applied Information Science에 의해 부분적으로 개발 또는 전적으로 개발되었습니다.

Rational Unified Process   2003.06.15