소개
이 가이드라인은 디자인 모델의 지속적 디자인
클래스를 데이터 모델의 테이블로 맵핑하는 방법을 설명합니다.
디자인 모델 요소를 데이터 모델 요소로 변환
디자인 모델의 지속적 클래스는 데이터 모델의 테이블로 변환될 수 있습니다. 아래 표에서는 디자인 모델 요소 및 데이터 모델 요소 사이의 맵핑에 대한 요약을 표시합니다.
디자인 모델 요소
|
이에 해당하는 데이터 모델 요소
|
클래스
|
테이블
|
속성
|
열
|
연관
|
비식별 관계
|
연관 클래스
|
교차 테이블
|
컴포지트 집계
|
식별 관계
|
다수 대 다수 연관
|
교차 테이블
|
다중성
|
카디널리티
|
규정된 연관
|
교차 테이블
|
일반화(상속)
|
별도의 테이블
|
지속적 클래스를 테이블에 맵핑
디자인 모델의 지속적 클래스는 시스템이 저장해야 하는 정보를 표시합니다. 개념상, 이 클래스는 관계형 디자인과 유사합니다. 예를 들어 디자인 모델의 클래스는 일부 방법을 통해 관계형 스키마의 엔티티로 반영될 수
있습니다. 그러나 프로젝트가 정제에서 생성으로 이동하면 디자인 모델 및 관계형 데이터 모델의 목적은 서로 달라집니다. 관계형 데이터베이스 개발 목표는 데이터를 정규화하는 것이지만 디자인 모델의 목적은 복잡한 동작을
많이 캡슐화하는 것이기 때문에 서로 달라지는 것입니다. 이 두 개의 관점(데이터 및 동작) 차이 때문에 두 모델의 관련 요소 사이에서 맵핑이 필요합니다.
세 번째 정규형으로 작성된 관계형 데이터베이스에서 테이블의 모든 행(모두 "튜플"임)은 오브젝트로 간주됩니다. 테이블의 열은 클래스의 지속적 속성과 동등합니다. (지속적 클래스에는 임시 속성이 있을 수 있다는 점을
명심하십시오.) 따라서 기타 클래스에 대한 연관이 없는 단순 클래스에서 두 세계 사이의 맵핑은 단순합니다. 속성의 데이터 유형은 열의 허용 가능한 데이터 유형 중 하나와 일치합니다.
예제
다음은 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차 키 값을 포함하는 테이블의 열입니다.
예제:
주문 및 고객 사이에 다음과 같은 연관이 있다고 가정해 보십시오.
관계형 테이블로 맵핑되면 결과는 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에 따라 다릅니다. 일반적으로 데이터 모델의 기본 구조 요소(테이블, 뷰, 스토어드 프로시저, 트리거 및
색인 포함)는 데이터베이스로 포워드 엔지니어링될 수 있습니다.
|