가이드라인: 관계형 데이터베이스 포워드 엔지니어링
이 가이드라인은 디자인 모델의 지속적 디자인 클래스를 데이터 모델의 테이블로 맵핑하는 방법을 설명합니다.
관계
기본 설명

소개

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

디자인 모델 요소를 데이터 모델 요소로 변환

디자인 모델의 지속적 클래스는 데이터 모델의 테이블로 변환될 수 있습니다. 아래 표에서는 디자인 모델 요소 및 데이터 모델 요소 사이의 맵핑에 대한 요약을 표시합니다.

디자인 모델 요소

이에 해당하는 데이터 모델 요소

클래스 테이블
속성

연관

비식별 관계

연관 클래스

교차 테이블

컴포지트 집계

식별 관계

다수 대 다수 연관

교차 테이블

다중성

카디널리티

규정된 연관

교차 테이블

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

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

디자인 모델의 지속적 클래스는 시스템이 저장해야 하는 정보를 표시합니다. 개념상, 이 클래스는 관계형 디자인과 유사합니다. 예를 들어 디자인 모델의 클래스는 일부 방법을 통해 관계형 스키마의 엔티티로 반영될 수 있습니다. 그러나 프로젝트가 정제에서 생성으로 이동하면 디자인 모델 및 관계형 데이터 모델의 목적은 서로 달라집니다. 관계형 데이터베이스 개발 목표는 데이터를 정규화하는 것이지만 디자인 모델의 목적은 복잡한 동작을 많이 캡슐화하는 것이기 때문에 서로 달라지는 것입니다. 이 두 개의 관점(데이터 및 동작) 차이 때문에 두 모델의 관련 요소 사이에서 맵핑이 필요합니다.

세 번째 정규형으로 작성된 관계형 데이터베이스에서 테이블의 모든 행(모두 "튜플"임)은 오브젝트로 간주됩니다. 테이블의 열은 클래스의 지속적 속성과 동등합니다. (지속적 클래스에는 임시 속성이 있을 수 있다는 점을 명심하십시오.) 따라서 기타 클래스에 대한 연관이 없는 단순 클래스에서 두 세계 사이의 맵핑은 단순합니다. 속성의 데이터 유형은 열의 허용 가능한 데이터 유형 중 하나와 일치합니다.

예제

다음은 Customer 클래스입니다.

Customer 클래스

RDBMS에서 모델링되면 Customer_ID, Name 및 Address 열을 가지는 Customer 테이블로 변환될 수 있습니다.

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

다이어그램에서는 새 고객 오브젝트 테이블의 부분을 표시합니다.

지속적 속성 및 키

각 지속적 속성에서 관계형 데이터 모델의 지속적 오브젝트를 적절히 모델링할 때 사용할 추가 정보를 도출하는 질문을 사용해야 합니다. 예제:

  • 이 지속적 속성이 키 또는 키의 파트로 지원될 수 있습니까? 예를 들어 "속성 Z와 함께 속성 X는 오브젝트를 고유하게 식별합니다." Customer 테이블에서 Customer_ID는 1차 키를 표시합니다.
  • 속성의 최소값 및 최대값은 무엇입니까?
  • 이 속성을 키로 사용하여 검색할 수 있습닊까? 예를 들어 "Y가 1000을 초과하는 모든 인스턴스 검색"과 같은 Select 문에서 필터의 파트에 해당할 수 있습니다.
  • 속성에 "속성 X는 전송 100,000자마다의 재전송 수"와 같은 설명을 포함합니까?
  • 속성으로 숫자 값 및 요구되는 다른 숫자 값 사이의 변환이 가능합니까?
  • 속성을 갱신할 수 있는 사람은 누구입니까? 예제: "T는 권한 클래스 nn의 사람만 변경할 수 있습니다."
  • 속성을 읽을 수 있는 사람은 누구입니까? 예제: "P는 권한 클래스 yy 및 zz의 사람이 읽을 수 있다" 또는 ""P는 Vi 및 Vj 뷰에 포함된다."
  • 볼륨 및 빈도에 대한 정보가 적절합니까? 예제: "A의 최대 발생 빈도는 50 000이다" 또는 "하루에 변경 빈도는 평균 2000이다."
  • 속성이 고유합니까? 예제: 동일한 운전자 면허증 번호를 가질 수 있는 사람은 한 사람뿐입니다.

지속적 오브젝트 사이의 연관을 데이터 모델에 맵핑

두 개의 지속적 오브젝트 사이 연관은 연관된 오브젝트에 대한 외부 키로 실현됩니다. 외부 키는 연관된 오브젝트의 1차 키 값을 포함하는 테이블의 열입니다.

예제:

주문 및 고객 사이에 다음과 같은 연관이 있다고 가정해 보십시오.

UML 다이어그램에서는 주문 및 고객 사이의 연관을 표시합니다.

관계형 테이블로 맵핑되면 결과는 Order 테이블 및 Customer 테이블로 나타납니다. Order 테이블에서는 속성이 열로 나열되고 Customer 테이블에 있는 연관된 행의 1차 키에 대한 외부 키 참조를 포함하는 Customer_ID 이름의 추가 열이 추가되었습니다. 지정된 주문에서 Customer_ID 열에는 주문과 연관된 고객의 ID가 있습니다. 외부 키를 사용하면 RDBMS에서 관련된 정보를 함께 결합할 수 있습니다.

집계 연관을 데이터 모델에 맵핑

집계도 외부 키 관계를 사용하여 모델링됩니다.

예제:

주문 및 품목 사이에 다음과 같은 연관이 있다고 가정해 보십시오.

주문 및 품목 클래스

관계형 테이블로 맵핑되면 결과는 Order 테이블 및 Line_Item 테이블로 나타납니다. Line_Item 테이블에서는 속성이 열로 나열되고 Order 테이블에 있는 연관된 행에 대한 외부 키 참조를 포함하는 Order_ID 이름의 추가 열이 추가되었습니다. 지정된 품목에서 Order_ID 열에는 품목과 연관된 주문의 Order_ID가 있습니다. 외부 키를 사용하면 RDBMS에서 결합 조작을 최적화할 수 있습니다.

또한 데이터 모델에서 참조 무결성을 제공하는 계단식 삭제 제한조건을 구현해야 합니다. 이 작업을 달성하면 주문을 삭제할 때마다 해당 모든 품목도 삭제됩니다.

데이터 모델에서 일반화 관계 모델링

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

  • 별도의 테이블을 사용하여 수퍼 클래스 및 서브클래스를 표시하십시오. 서브클래스 테이블은 수퍼 클래스 테이블에 대한 외부 키 참조를 포함해야 합니다. 서브클래스 오브젝트를 인스턴스로 작성하려면 두 테이블이 함께 결합되어 있어야 합니다. 이 접근 방식은 개념적으로 쉽고 모델 변경을 용이하지만 추가 작업 때문에 종종 성능이 떨어집니다.
  • 모든 상속 속성 및 연관을 서브클래스 테이블에 있는 별도의 열로 중복시키십시오. 표준 관계형 데이터 모델에서 비정규화 과정과 유사합니다.

데이터 모델에서 다수 대 다수 연관 모델링

관계형 모델링의 표준 기법은 다수 대 다수 연관을 표시하도록 교차 엔티티를 사용하는 것입니다. 여기에서도 동일한 접근 방식을 적용할 수 있습니다. 교차 테이블을 사용하여 연관을 표시합니다.

예제:

공급자가 많은 제품을 공급할 수 있고 한 제품을 많은 공급자가 공급할 수 있는 경우 솔루션은 Supplier/Product 테이블을 작성하는 것입니다. 이 테이블은 Supplier 및 Product 테이블의 1차 키만 포함하고 공급자 및 관련 제품을 링크하도록 지원할 수 있습니다. 오브젝트 모델은 이 테이블과 유사하지 않습니다. 관계형 데이터 모델의 연관을 표시하는 데만 사용됩니다.

데이터 모델 정제

디자인 클래스를 데이터 모델에서 적절한 관계 및 테이블로 변환하면 모델은 참조 무결성을 구현하고 뷰 및 스토어드 프로시저를 통해 데이터 액세스를 최적화하는 데 필요한 형태로 정제됩니다. 자세한 정보는 가이드라인: 데이터 모델을 참조하십시오.

데이터 모델 포워드 엔지니어링

대부분의 응용프로그램 디자인 도구는 데이터 모델에서 데이터베이스 생성 및/또는 데이터 모델에서 DDL(Data Definition Language) 스크립트 생성을 지원합니다. 데이터베이스의 포워드 엔지니어링은 전반적인 응용프로그램 개발 및 통합 타스크의 파트로 계획되어야 합니다. 데이터 모델에서 데이터베이스를 포워드 엔지니어링하는 경우 타이밍 및 빈도는 특정 프로젝트 상황에 따라 다릅니다. 새 데이터베이스를 작성하는 새 응용프로그램 개발 프로젝트인 경우 첫 번째 포워드 엔지니어링은 정제 단계 마지막에서 응용프로그램의 안정된 아키텍처 버전을 구현하는 작업의 파트로 수행되어야 할 수도 있습니다. 다른 경우 첫 번째 포워드 엔지니어링은 구현/구축 단계의 초기 반복에서 수행되어야 할 수도 있습니다.  

포워드 엔지니어링 가능한 데이터 모델의 모델 요소 유형은 프로젝트에서 사용된 특정 디자인 도구 및 RDBMS에 따라 다릅니다. 일반적으로 데이터 모델의 기본 구조 요소(테이블, 뷰, 스토어드 프로시저, 트리거 및 색인 포함)는 데이터베이스로 포워드 엔지니어링될 수 있습니다.