KR101159311B1 - 임의의 데이터 모델에 대한 맵핑 시스템 및 방법 - Google Patents

Abstract

2 이상의 데이터 소스들 자체의 메타데이터나 스트럭처를 변경하지 않고 이 데이터 소스들 사이에서 맵핑을 수행하는 데이터 맵핑 아키텍처가 제공된다. 또한, 데이터 맵핑은 갱신을 지원한다. 또한, 이 아키텍처는 적어도, 맵핑될 데이터 소스들이 미리 정의된 자신의 스키마가 주어져 있으며 변경될 수가 없는 경우도 지원한다. 상기 아키텍처는, 적어도 2개의 임의의 데이터 모델로부터 개개의 메타데이터를 수신하여 상기 데이터 모델들 간의 표현식들을 맵핑시키는 맵핑 컴포넌트를 포함한다.

맵핑, 맵핑 아키텍처, 데이터 모델, 스키마, 데이터 소스, 메타데이터, 스트럭처

Description

임의의 데이터 모델에 대한 맵핑 시스템 및 방법{MAPPING ARCHITECTURE FOR ARBITRARY DATA MODELS}

도 1은 본 발명의 맵핑 시스템의 블럭도.

도 2는 본 발명에 따른 프로세스의 흐름도.

도 3은 소스의 타겟에의 맵핑을 용이하게 하기 위해 제공되는 개념적 메타데이터 엔티티의 블럭도.

도 4는 소스 스키마를 타겟 스키마에 맵핑하기 위한 맵핑 파일의 일반적인 예를 도시하는 도면.

도 5는 소스 도메인과 타겟 도메인 간의 맵핑의 일례를 도시하는 도면.

도 6a는 맵핑 컴포넌트가 네트워크 상에서 분리 배치되어 있는, 소스 데이터 소스와 타겟 데이터 소스의 네트워크도.

도 6b는 맵핑 컴포넌트가 소스 위치, 타겟 위치, 또는 이 두 위치 모두에 배치될 수 있는 네트워크도.

도 7은 개시되는 아키텍처를 실행하도록 동작 가능한 컴퓨터의 블럭도.

도 8은 본 발명에 따른 예시적인 컴퓨팅 환경의 개략적인 블럭도.

도 9는 본 발명에 따른 데이지 체인 맵핑 구현의 블럭도.

도 10은 본 발명의 맵핑 아키텍처의 허브 앤 스포크 구현을 도시하는 도면.

도 11은 본 발명의 일 양상에 따른 중첩 가능 스트럭처를 도시하는 도면.

<도면의 주요 부분에 대한 부호의 설명>

100 : 맵핑 시스템

102 : 소스 데이터 모델

104 : 소스 메타데이터

106 : 맵핑 컴포넌트

110 : 타겟 메타데이터

112 : 타겟 데이터 모델

본 발명은 데이터 소스들 간의 데이터 맵핑에 관한 것이다.

오늘날 유무선 체제에서 정보의 자유로운 유통이 널리 행하여지지만, 사용할 데이터를 저장하고 해석하는 한에 있어서는 소스와 목적지 간의 호환이 요구된다. 전세계적으로 정보 소스들이 존재하며, 대다수의 경우, 데이터가 소스마다 다르게 표현되어 있다. 오늘날 기업과 개인이 직면하게 되는 주요한 문제는 하나의 포맷으로 존재하는 데이터가 다른 목적을 위해 다른 포맷으로 될 필요가 있을 수 있다는 점이다. 그러나, 이러한 처리는, 완전히 다르고 항상 변경되는 일련의 데이터셋트로 인해 제한된다. 이와 같은 예로는, 데이터를 각종 복수의 소스들로부터 저장 및 다른 소스로부터의 고속 액세스를 위해 수신하는 데이터 웨어하우징에서 찾 아볼 수 있다. 한 데이터 표현(data representation)으로부터 다른 데이터 표현으로 전환하는 것은 시간이 소요되며 리소스가 집중되는 일일 뿐만 아니라, 전환 문제들을 수반할 수 있고, 몇몇 경우에는 그 복잡성으로 인해 아예 실행 불가능할 수도 있다.

이하, 본 발명의 몇 가지 양상들에 대한 기본적인 이해를 제공하기 위해서 본 발명의 요약을 간략히 소개한다. 이 요약은 본 발명의 광범위한 개관이 아니다. 본 발명의 핵심/필수 요소들을 알린다거나, 본 발명의 범위를 경계짓도록 의도된 것이 아니다. 그 유일한 목적은, 이후에 설명되는 상세한 설명에 대한 도입부로서 본 발명의 몇 가지 개념들을 간단한 방식으로 소개하기 위함이다.

본 명세서에 개시되고 특허청구범위에서 청구된 본 발명은, 그 일 양상으로서, 2개(혹은 그 이상)의 데이터 소스가 그 자체의 메타데이터나 스트럭처(structure)를 변경하지 않으면서도 서로에게 맵핑되어야 할 시나리오를 지원하도록 설계된 맵핑 포맷을 포함한다. 맵핑은 예컨대, 오브젝트 공간과 관계형 데이터베이스 사이, 오브젝트 공간과 XML 데이터 모델 사이, 혹은 XML 데이터 모델과 관계형 데이터 모델 사이에 제공되거나, XML 데이터 모델, 관계형 데이터 모델, 혹은 임의의 다른 데이터 모델로의 맵핑이 다른 임의의 가능한 데이터 모델 사이에서 제공될 수 있다. 맵핑 포맷은 갱신을 지원한다. 또한, 맵핑 포맷은, 맵핑될 2개의 데이터 소스가 주어지고 이들의 스키마(schema)가 사전에 정의되어 변경될 수 없는(예컨대, 판독 전용(read-only)) 경우도 지원한다. 예컨대, 주석을 부가하기 위해 XML 스키마 정의(XML schema definition : XSD)를 변경하도록 요구된 관계형 데이터베이스에 XML 데이터를 맵핑시키는 방안이 이전에 사용되었다. 본 발명의 맵핑 포맷은, XSD 파일이 외부 엔티티(entity)에서 소유하여 변경될 수 없는 것처럼 동작한다. 또한, 본 발명의 맵핑 포맷은 여러 다른 데이터 소스들(데이터베이스 등)로의 다중 맵핑을 위해 편집없이 동일 XSD 파일을 재사용할 수 있게 한다.

각 데이터 모델은 맵핑에 대하여 스트럭처, 필드, 및 관계(relationship)의 3가지 개념(혹은 표현식(expression)) 중 적어도 하나를 제시한다. 이러한 개념들 모두는 데이터 모델들 사이에서 맵핑될 수 있다. 하나의 데이터 모델이, 3가지의 표현을 갖는 또 다른 데이터 모델로 맵핑되도록 하기 위한 표현식들 중 오직 한가지 혹은 두가지를 갖는 것이 가능하다. 맵핑 스트럭처는 맵핑 스키마의 기본 컴포넌트이며, 관계되는 맵핑 필드들의 컨테이너(container)로서 기능한다. 필드는 타입 선언된 데이터(typed data)를 보유하는 데이터 모델 개념이다. 관계는 동일 데이터 모델에서 2개의 스트럭처 간의 링크(link) 및 연관성(association)으로서, 동일 도메인 내의 스트럭처들이 서로 어떻게 관련되는지를 기술한다. 관계는 두 스트럭처들의 공통 필드 및/또는 한 스트럭처가 다른 스트럭처를 포함하는 것에 관련된 격리 관계(containment)/참조 관계(reference)를 통해 설정된다. 이들은 관계의 예시일 뿐이므로, 다른 관계들도 설정될 수 있다(예컨대, 형제 관계, 함수 관계 등). 본 발명은 임의의 관계를 설정할 수 있다. 데이터 모델의 멤버는 맵핑 컨텍스트에 따라 다양한 맵핑 개념으로서 제시될 수 있다.

의미론적으로, 맵핑은, 2개의 피맵핑 도메인(mapped domain)에 대하여 가역 성(reversibility)에 관한 지시 및 추가의 정보를 포함한 추가적인 메타데이터를 이용한 뷰(즉, 뷰는 사실상 질의(query)임)에 상당한다. 하나의 데이터 소스가 다른 데이터 소스에 맵핑되는 경우에, 정말로 필요한 것은 타겟 스키마가 소스 스키마의 뷰인 것이 희망된다는 점이다. 맵핑은 다른 데이터 도메인의 상부에서 한 데이터 도메인에 표현되는 뷰이고, 뷰 변환 자체를 정의한다. 맵핑은 데이터에 대한 스트럭처상의 변환(structural transformation)들을 이용하여 복잡한 뷰들을 생성할 수 있으며, 이 변환들은 계층구조(hierarchy)를 생성하거나 제거하고, 속성(attribute)을 한 엘리먼트(element)로부터 다른 엘리먼트로 이동시키고, 새로운 관계를 도입한다.

맵핑은 2 이상의 피맵핑 모델(mapped model)들 사이에서 동일한 맵핑 가능 개념(concept)들을 관련시키고 연결시킨다. 또한, 맵핑은 지향적이다. 따라서, 한 도메인은 소스로서 분류되고, 다른 도메인은 타겟으로서 분류된다. 소스로서 맵핑되는 모델은 타겟으로서 맵핑되는 모델과는 다른 특성들을 갖는다는 점에서, 맵핑의 지향성은 맵핑 구현 및 의미론 면에서 중요하다. 맵핑이 타겟 도메인의 질의 언어를 사용하여 구현되는 경우, 타겟은 소스 모델의 뷰를 보유한다. 소스는 데이터의 영구적 기억 장소(persistent location)로서, 맵핑은 타겟 도메인 질의 언어로 작성된 질의를 소스 도메인 질의 언어로 번역한다. 소스와 타겟 간의 한 가지 차이점은 소스 혹은 타겟 모델로부터의 스트럭처 또는 필드가 스트럭처와 필드에 적용될 수 있는 맵핑의 수에 관하여 소정의 제약을 갖는다는 점이다. 타겟 도메인에서는 스트럭처와 필드가 오직 한 번 맵핑될 수 있을 뿐인 반면, 소스 도메 인에서는 스트럭처와 필드가 복수회 맵핑될 수 있다. 예를 들어, Customers 테이블은 타겟 도메인의 BuyingCustomer 엘리먼트와 ReferringCustomer 엘리먼트에 맵핑될 수 있다. 그러나, 로컬 엘리먼트나 로컬 클래스는 오직 한 번만 맵핑될 수 있을 뿐이다. 맵핑의 지향적 속성으로 인해 유발되는 또 다른 차이점은, 맵핑에 의해 사용자가 타겟 도메인의 질의 언어를 통해(예컨대, 관계형 모델을 XML 모델로 맵핑하기 위한 XQuery 및 관계형 모델을 오브젝트 모델로 맵핑하기 위한 OPath를 사용하여) 맵핑 모델을 조작할 수 있다는 점이다.

맵핑 아키텍처의 또 다른 중요한 속성은 갱신 가능하다는 점이다. 종래, 개발자들은 도메인들 사이에서 변경 내용을 전달하고 동기화하기 위한 코드를 작성해야만 했다. 그러나, 본 발명에 따르면, 이제 맵핑 엔진이 이러한 태스크들을 수행한다. 즉, 사용자가 타겟 도메인의 스트럭처를 생성, 삭제, 또는 변경할 경우, 이러한 변경 내용이 타겟 API(application programmable interface) 및 맵핑 엔진에 의해서 소스 도메인에 자동으로 동기화된다(보유된다).

본 발명의 다른 양상으로는, 맵핑의 여러 단계들이 소스로부터 타겟까지 발생할 수 있는 맵핑 아키텍처가 중첩 가능(stackable)하다는 것이다.

상기 및 그에 관련된 목적을 달성하기 위해, 본 발명의 소정의 예시적인 양상들이 이하의 상세한 설명과 첨부 도면에 관련하여 본 명세서에 개시된다. 그러나, 이러한 양상들은 본 발명의 원리들이 채용될 수 있는 다양한 방식 중 일부를 나타낼 뿐이며, 본 발명은 이러한 모든 양상들과 그 균등물들을 포함하도록 의도되었다. 본 발명의 그 밖의 이점들과 신규한 특징들은 이하의 본 발명에 관한 상세 한 설명을 첨부 도면과 관련하여 고려할 때 명백하게 될 것이다.

이제, 도면을 참조하여 본 발명을 기술한다. 도면 전반에 있어서, 유사한 구성 요소를 참조하는 데에는 유사한 참조 번호를 부여하였다. 이하의 기술에 있어서, 설명의 목적상, 본 발명의 완전한 이해를 제공하기 위해 여러 특정 상세가 언급되어 있다. 그러나, 본 발명은 이러한 특정 상세가 아니고서도 실시될 수 있음은 분명하다. 한편, 본 발명을 기술하는 것을 용이하게 위해서, 공지된 스트럭처 및 디바이스를 블럭도에 도시하였다.

본 명세서에 사용된 바와 같이, "컴포넌트" 및 "시스템"이라는 용어는, 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행 중인 소프트웨어 등의 컴퓨터 관련 엔티티를 지칭하는 것으로 의도되었다. 예를 들어, 컴포넌트는 프로세서 상에서 실행 중인 프로세스, 프로세서, 오브젝트, 실행 파일(executable), 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이에 한정되지 않는다. 예로서, 서버 및 그 서버 상에서 실행되는 애플리케이션 둘 다 컴포넌트일 수 있다. 하나 이상의 컴포넌트는 프로세스 및/또는 실행 스레드에 상주할 수 있고, 컴포넌트는 1대의 컴퓨터 상에 배치될 수 있고/있거나, 2대 이상의 컴퓨터들 간에 분산될 수 있다.

본 명세서에 사용된 바와 같이, "추론(inference)"은 일반적으로 이벤트 및/또는 데이터를 통해 캡처되는 일련의 결과들로부터 시스템의 상태, 환경, 및/또는 사용자에 관하여 추론하거나 이들을 추측하는 프로세스를 지칭한다. 추론은 예컨 대 특정 컨텍스트나 동작을 식별하는 데 사용되거나, 상태들에 관한 확률 분포를 산출할 수 있다. 추론은 확률적이다. 즉, 데이터 및 이벤트의 고려 사항들에 기초하여 대상으로 하는 상태들에 대한 확률 분포의 계산이다. 또한, 추론은 일련의 이벤트 및/또는 데이터로부터 보다 높은 레벨의 이벤트를 구성하기 위해 채용되는 기술들을 지칭한다. 이러한 추론에 의하면, 일련의 관찰된 이벤트들 및/또는 저장된 이벤트 데이터로부터, 이벤트들이 시간적으로 매우 근접하여 상관되어 있든지 아니든지 간에, 그리고 이벤트 및 데이터가 하나 혹은 수개의 이벤트 소스 및 데이터 소스로부터 발생된 것이든지 아니든지 간에, 새로운 이벤트 또는 동작을 구성하게 된다.

정의

본 발명의 다양한 양상들에 대한 이해를 돕기 위해, 본 명세서에서 사용되는 용어들의 정의를 이하에 제공한다.

모델 - 예컨대 XML 스키마, 관계형 스키마, 오브젝트 스키마 등의 설계물을 표현하는 복합 이산 스트럭처

도메인 - 특정 데이터 모델에 기초하여 데이터를 관리하는 하나 이상의 애플리케이션

오브젝트 도메인 - 오브젝트 그래프 데이터 모델의 ObjectSpace 구현

XML 도메인 - XML 데이터 모델에 기초한 질의 언어 및 오브젝트의 스택

관계형 도메인 - 관계형 데이터 모델에 기초한 DMBS(Database Management System)

I 도메인 스키마(IDomainSchema) - 맵핑 가능 스트럭처의, 연속 가능하며 라벨이 부여된 이산 그래프로서 모델을 나타내는 모델 관리 오브젝트 모델. 이 모델 그래프의 엣지는 "관계"를 나타낸다. 예컨대, XSOM(XML 스키마 XSD(XML Schema Definition)를 나타내는 오브젝트 모델), RSOM(관계형 스키마 RSD(Relational Schema Definition)를 나타내는 오브젝트 모델), 및 OSOM(오브젝트 스키마 OSD(Object Schema Definition)을 나타내는 오브젝트 모델).

맵핑 스트럭처 - 관련된 맵핑 필드들에 대한 컨테이너로서 기능하는 데이터 모델 스키마의 기본 컴포넌트(예컨대, 관계형 도메인에서의 테이블, XML 도메인에서의 복합 타입 엘리먼트(complex type element), 및 오브젝트 도메인에서의 클래스).

필드 - 타입 선언된 데이터를 보유하는 데이터 모델 개념. 개념적으로, 필드는 스칼라 값(scalar value)을 보유하지만, 몇몇 경우에는 복소수 데이터(예컨대, XML 데이터 타입 및 UDT)를 보유할 수 있다. 또 다른 예로는, 관계형 데이터 모델의 컬럼(column), XML 도메인의 단순 타입 엘리먼트(simple type element), 및 오브젝트 도메인의 특성이 포함된다.

관계 - 동일 데이터 모델 내의 2개의 스트럭처 간의 링크 및 연관성으로서, 동일 도메인 내의 스트럭처들이 어떻게 서로 관련는지를 기술한다. 관계는 2개의 스트럭처의 공통 필드 및/또는 한 스트럭처가 다른 스트럭처를 포함하는 것에 관련된 격리 관계/참조 관계를 통해 설정된다(예컨대, XML 격리 계층구조, 필드에 의해 다른 오브젝트를 참조하는 오브젝트 등).

이제, 도 1을 참조하면, 본 발명의 맵핑 시스템(100)의 블럭도가 도시되어 있다. 프레임워크는, 데이터 모델들 각각의 질의 언어나 API를 이용하는 데이터 모델들의 도메인에서 CRUD(생성, 판독, 갱신, 및 삭제(Create, Read, Update and Delete) 연산들을 수행할 수 있는 데이터 모델들의 기능을 제공하며, 이는 연산들로 변환된다. 예를 들어, XML 모델 및 오브젝트 모델은 상기 모델들의 질의 언어(예컨대, 각각 XQuery 및 OPath)를 사용하는 상기 모델들의 도메인의 CRUD 연산들을 수행할 수 있으며, 이는 관계형 모델의 질의 언어(예컨대, SQL)를 사용하는 관계형 도메인의 연산들로 변환된다.

맵핑 시스템(100)은 소스 데이터 모델(102)과 타겟 데이터 모델(104)을 포함하며, 맵핑은 맵핑 컴포넌트(106)를 통해 소스 데이터 모델(102)로부터 타겟 데이터 모델(104)로 일어난다. 각 데이터 모델(102 및 104)은, 관련될 수 있는 하나 이상의 엔티티를 제시하는 메타데이터와 연관되어 있다. 즉, 소스 데이터 모델(102)은 소스 메타데이터(108)를 제시하고, 타겟 데이터 모델(104)은 타겟 메타데이터(110)를 제시하며, 이 메타데이터(108 및 110) 각각은, 맵핑 컴포넌트(106)를 통해 직접적으로 관련될 수 있는 개념상 엔티티들을 포함한다. 메타데이터 엔티티들은 스트럭처, 필드, 및 관계의 개념(또는 표현식)을 포함한다.

맵핑은 적어도 2개의 피맵핑 모델로부터의 동일한 맵핑 가능 개념, 상이한 맵핑 가능 개념, 및 이들의 조합(이들에 대해서는 이후에 보다 상세히 설명될 것임)을 서로 관련짓고 연결시킨다. 맵핑은 지향적이다. 따라서, 어떤 도메인들은 소스 데이터 모델(102)로서 분류되고, 다른 어떤 도메인들은 타겟 데이터 모델 (104)로서 분류된다. 개시되는 맵핑 아키텍처의 지향적인 양상은 맵핑 구현 및 의미론에 있어 상당한 이점을 제공한다. 또한, 소스 데이터 모델(102)로서 맵핑되는 모델은 타겟 데이터 모델(104)로서 맵핑되는 모델과는 다른 특성을 가질 수 있다.

타겟 데이터 모델(104)은 소스 데이터 모델(102)의 뷰를 보유한다. 즉, 맵핑은 타겟 도메인의 질의 언어를 사용하여 구현된다. 소스 데이터 모델(102)은 데이터의 영구적 기억 위치이며, 맵핑 컴포넌트는 타겟 도메인 질의 언어로 작성된 질의를 소스 도메인 질의 언어로 번역한다.

소스 데이터 모델(102)과 타겟 데이터 모델(104) 간의 차이는 소스 데이터 모델(102) 또는 타겟 데이터 모델(104)로부터의 스트럭처나 필드가 스트럭처 및 필드에 적용될 수 있는 맵핑의 수에 관한 소정의 제한을 갖는다는 점이다. 타겟 도메인에서는 스트럭처와 필드는 단 한 번만 맵핑될 수 있는 반면, 소스 도메인에서는 스트럭처와 필드가 복수회 맵핑될 수 있다. 예를 들어, Customers 테이블은 타겟 도메인의 BuyingCustomer 엘리먼트와 ReferringCustomer 엘리먼트에 맵핑될 수 있다. 그러나, 로컬 엘리먼트 및 로컬 클래스는 단 한 번만 맵핑될 수 있다. 보다 상세한 설명은 예제, 구문론, 및 의미론과 관련하여 본 명세서에서 후술된다.

맵핑의 지향적인 속성으로부터 기인하는 소스와 타겟 간의 또 다른 차이점은 맵핑에 의해서 사용자가 타겟 도메인의 질의 언어(예컨대, 관계형으로부터 XML로의 맵핑의 경우에는 XQuery, 관계형으로부터 오브젝트로의 맵핑의 경우에는 OPath)를 통해서 피맵핑 모델들을 조작할 수 있다는 점이다.

이제 도 2를 참조하면, 본 발명에 따른 프로세스의 흐름도가 도시되어 있다. 설명을 간명하게 하기 위해, 본 명세서에서 예컨대 흐름도의 형태로 나타나 있는 하나 이상의 방법론(methodology)은 일련의 행위(act)들로서 도시되고 설명되지만, 본 발명은, 본 발명에 따른 소정의 행위들이 본 명세서에서 설명되고 도시된 바와는 다른 순서로 행하여질 수 있고/있거나, 다른 행위들과 함께 동시에 수행될 수 있으므로, 행위들의 순서에 의해 제한되지 않는다는 것을 이해하고 인식해야할 것이다. 예를 들어, 본 기술 분야의 당업자라면, 방법론이 상태도와 같은 일련의 상관된 상태들 또는 이벤트들로서 다른 방법으로 표현될 수 있다는 것을 이해하고 인식할 것이다. 또한, 본 발명에 따른 방법론을 구현하는 데, 도시되지 않은 모든 행위들이 필요할 수 있다.

단계 200에서는, 데이터 맵핑을 위한 데이터 모델들이 식별된다. 단계 202에서는, 데이터 모델이 식별된 후에 각 모델에 대응하는 메타데이터가 식별된다. 단계 204에서는, 소스 모델로부터 타겟 모델로의 데이터 맵핑이 개시된다. 단계 206에서는, 맵핑 시스템이 맵핑 에러가 발생되었는지의 여부를 판정한다. "예"인 경우에는 단계 208로 진행하여 에러를 보고한다. 그 다음, 진행이 단계 204의 입력으로 복귀하여 맵핑 프로세스를 계속한다. 한편, 맵핑 에러가 발생되지 않은 경우에는 단계 206으로부터 단계 210으로 진행되어, 맵핑 프로세스가 완료될 때까지 계속된다. 그 다음, 맵핑 프로세스는 끝 블럭에 도달한다.

이제, 도 3을 참조하면, 소스로부터 타겟으로의 맵핑을 용이하게 하기 위해 제시되는 개념상의 메타데이터 엔티티에 대한 도면이 도시되어 있다. 맵핑 컴포넌트는 맵핑 파일(300)을 포함한다. 맵핑 파일은 소스 메타데이터(108)와 타겟 메타 데이터(110) 간의 맵핑 함수를 설정한다. 본 특정예에서, 소스 메타데이터(108)와 타겟 메타데이터(110)는 각각, 맵핑 관계를 설정하는 데 사용될 수 있는 스트럭처, 필드, 및 관계의 3개의 엔티티를 포함한다. 따라서, 소스 메타데이터(108)는 스트럭처_S 엔티티(302), 필드_S 엔티티(304), 및 관계_S 엔티티(306)를 포함한다. 마찬가지로, 타겟 메타데이터(110)는 스트럭처_T 엔티티(308), 필드_T 엔티티(310), 및 관계_T 엔티티(312)를 포함한다.

스트럭처는 데이터 모델 스키마의 기본 컴포넌트이며, 관련된 맵핑 필드들에 대한 컨테이너로서 기능한다. 예로서, 관계형 도메인의 테이블, XML 도메인의 복합 타입 엘리먼트, 및 오브젝트 도메인의 클래스가 포함된다. 필드 엔티티는 타입 선언된 데이터를 보유하는 데이터 모델 개념이다. 개념적으로, 필드는 스칼라 값을 보유하지만, 몇몇 경우에는 (XML 데이터 타입 및 UDT와 같은) 복소수 데이터를 보유할 수 있다. 맵핑 필드의 예로는, 관계형 데이터 모델의 컬럼, XML 도메인의 속성 및 단순 타입 엘리먼트, 및 오브젝트 도메인의 특성이 포함된다. 관계는 동일 데이터 모델 내의 2개의 스트럭처 간의 링크 및 연관성을 말하는 것으로, 동일 도메인 내의 스트럭처들이 어떻게 서로 관련되는지를 기술한다. 관계는 2개의 스트럭처에서의 공통 필드 및/또는 한 스트럭처가 다른 스트럭처를 포함하는 것에 관련된 격리 관계/참조 관계(예컨대, XML 격리 계층구조, 및 필드를 통해 다른 오브젝트를 참조하는 오브젝트)를 통해 설정된다.

데이터 모델의 멤버는 맵핑 컨텍스트에 기초하여 상이한 다른 맵핑 개념으로 서 제시될 수 있다. 예를 들어, XML 엘리먼트는 필드 및 스트럭처로서 제시될 수 있다(예컨대, 단순 타입 엘리먼트 및 복합 타입 엘리먼트). 맵핑 및 I 도메인 스키마는 해당 멤버가 특정 개념이 유효한 것임을 제시하는 것인지를 판정한다. 데이터 모델이 상이한 맵핑 개념으로서 제시될 수 있는 또 다른 예로는, 예컨대 커스텀 테이블에서 표현식이 소정의 개념일 수도 있는 관계형 도메인을 포함한다.

맵핑 의미론

의미론적으로, 맵핑은 2개의 피맵핑 도메인에 대해 가역성에 관한 지시 및 추가의 정보를 포함한 추가의 메타데이터를 갖는 질의/뷰에 상당한다. 한 데이터 소스 스키마가 다른 데이터 소스 스키마에 맵핑되는 경우, 타겟 스키마가 소스 스키마의 뷰인 것이 필요하다. 맵핑은 뷰 변환 그 자체를 정의한다. 예를 들어, 관계형 데이터베이스를 XML 데이터베이스로 맵핑할 경우, 룩(look)(또는 스키마)이 궁극적으로 XSD에 의해 정의되는 뷰가 정의되고, 맵핑 파일은 RSD 파일로 표현되는 관계형 데이터베이스에 대한 상기의 뷰를 어떻게 (처리 및 실행함으로써) 생성하는지를 정의한다.

맵핑은 다른 데이터 도메인 상에서 한 데이터 도메인에 표현되는 뷰이다. 맵핑이 이러한 뷰인 것(그리고, 뷰가 실제로 질의인 것)을 이해하는 것은 맵핑의 의미론을 이해하는 데 중요하다.

맵핑 뷰를 SQL 뷰와 비교해 본다. SQL 서버는 관계형 데이터베이스 상에서 관계형 뷰를 정의할 수 있게 한다. 이러한 뷰는 SQL 질의에 의해 정의되며, 기본적으로는 결과에 관한 스키마(문장의 SELECT절), 소스의 서브스키마(subschema)에 관련되는 부분(개략적으로, 문장의 FROM절), 및 소스 스키마로부터 결과 스키마를 생성할 수 있게 하는 변환(WHERE절)의 세 가지 사항을 결합한 것이다.

개시되는 맵핑 포맷은 이러한 세 가지 사항을 갖고 있지만, (XSD, 맵핑, RSD에서와 같이) 분명하게 구분된다.

맵핑은 도메인 간의 복잡한 뷰이다. 맵핑은 도메인 간 뷰의 생성을 허용한다. (예컨대, SQL 뷰나 XSLT 뷰에 대해) 차별화되는 특징으로는, 소스 스키마와 타겟 스키마가 서로 다른 데이터 모델 도메인에 속할 수 있다는 점이다. 맵핑은 관계형 스키마 상의 계층적 뷰(XML)나, 계층적 스키마 상의 그래프 뷰(오브젝트) 등을 구축할 수 있다.

개시되는 맵핑 아키텍처는, 타겟 도메인이나 소스 도메인을 변환하기 위한 맵핑과 함께 XQuery, XSLT와 같은 다른 언어들을 사용하는 기능을 제공한다. 예를 들어, 연산별로 맵핑에 변환이 추가될 수 있다. 일례가 되는 연산으로는 삽입, 갱신, 삭제, 및 질의가 있다.

예제 코딩은 다음과 같다 :

TransformLanguage는 맵핑될 데이터를 변환하는 데 사용되는 언어이다. TransformLocation은 그 변환이 제공되는 인터넷이나 디스크 상의 파일 위치이다. 어떤 위치도 특정되지 않는 경우에는, 변환은 MapTransform 엘리먼트의 텍스트에 제공될 수 있다. Operation은, 상기 변환이 맵핑을 이용하는 애플리케이션에 기초하여 정의된 연산이다.

맵핑은 데이터에 대한 스트럭처상의 변환들을 갖는 복잡한 뷰를 생성할 수 있다. 맵핑은 계층구조를 생성 또는 파기하고, 한 엘리먼트로부터 다른 엘리먼트로 속성을 이동시키며, 새로운 관계를 도입할 수 있다. 맵핑의 결과(타겟 스키마)는 복잡한 스키마일 수 있다. 이는, 기본적으로 멀티-테이블 데이터베이스 스키마로부터 단일 테이블 데이터베이스 스키마로 변환한다는 점에서 종래의 아키텍처와는 다르다. 맵핑은 출력의 관계에 관한 다중 테이블들을 생성할 수 있다.

맵핑은 뷰를 정의한다. 이는, 맵핑의 사용에 있어, 사용자가 뷰 상에서 질의를 실행하고 갱신할 수 있다는 것을 의미한다. 맵핑은 연산이 아니며, 데이터에 대한 질의나 갱신 연산없이 데이터를 생성하는 데 사용될 수 없다. 그러나, 질의는 간단한 것(예컨대, sql:view("filename"))일 수 있고, 맵핑 뷰에 의해 기술되는 모든 데이터를 검색할 수 있다(이러한 뷰를 구현할 수 있다). 맵핑은 뷰(갱신 가능 뷰)에 대한 질의 및 갱신 모두를 (소정의 예외를 갖고) 지원한다.

보다 전문적으로 보면, 맵핑은 질의와 유사하다. SQL 뷰가 질의에 의해서 정의되는 것과 동일한 방식으로, 맵핑도 또한 이러한 뷰를 생성하는 질의가 존재함을 내포한다. 맵핑은, 정적이고 재사용 가능하며 갱신 가능한 뷰를 정의하고, 따라서 사용자는 이러한 뷰를 사용하여 이 뷰 상에서 복수의 임시적(ad-hoc) 질의/갱신을 취할 수 있다.

예를 들어, 사용자는 개시되는 맵핑 포맷을 사용하여, 최근 7일간 주문을 한 모든 고객들(이후, 이들을 "활동 고객"이라고 함)과 해당 주문 및 주문 상세에 대한 뷰(스키마)를 정의할 수 있다. 따라서, 사용자는 이러한 뷰를 사용하여, 뷰 상에서 질의를 실행한다. 한 도메인에서, 예컨대, XQuery는 마이너스 잔액을 가진 모든 "활동 고객"을 검색하는 것을 취할 수 있다. 실행 단계에서, 맵핑 프로세서는 맵핑 정보를 공개한다. SQL 서버가 관계형 뷰 상에서 SQL 질의에 대해 수행하는 것과 마찬가지로, 이 맵핑 정보는 XQuery 문장과 결합되는 경우에 SQLGen 엔진에서 사용되어 맵핑의 관련 부분에 대응하는 질의를 구성할 수 있다.

검색 연산과 갱신 연산은 본질적으로 상이하다. 단일의 검색 연산은 한 방향으로 진행하도록 지원되는 한편, 다른 3가지의 연산(삽입, 갱신, 및 삭제)은 다른 방향으로 진행하도록 지원된다. 예를 들어, 소스로서의 SQL 서버의 데이터를 타겟 XML 스키마에 맵핑하여 관계형 데이터의 XML 뷰를 생성할 수 있게 하는 맵핑을 정의한다. XQuery는 SQL 서버의 테이블들에 대해서는 실행될 수 없다. 또한, 동일한 맵핑이 XML 데이터 소스 상에서 관계형 뷰를 표현하는 데 사용될 수도 없다. 개시되는 맵핑 포맷은 대칭성이 없어, 용이하게 역행될 수 없다. 데이터는 XML 질의 언어를 사용하여 질의될 수 있으므로 SQL 서버로부터 검색될 수 있다. 또한, 맵핑은 뷰에 의한 갱신을 지원하므로 동일 맵핑을 통해 갱신이 수행될 수 있다.

맵핑은 2개의 피맵핑 모델 간의 양방향(판독과 기입) 변환을 적용하기 위한 필수 정보를 제공한다. 데이터 모델 도메인 간에 질의, 갱신, 삽입, 및 삭제 연산들을 수행하는 데 필요한 정보는, 존재성(두 도메인이 동기화된 경우에, 한 도메인 내의 스트럭처의 존재는 다른 도메인 내의 스트럭처의 존재에 기초함); 복사(소스 모델과 타겟 모델의 피맵핑 필드들 간의 데이터를 복사함. 예컨대, 널값 및 데이터 타입 변환 등과 같이 복사 연산은 값의 한 도메인으로부터 다른 도메인으로의 제한된 변환을 포함할 수 있음); 및 관계 맵(소스 도메인의 개개의 맵핑 스트럭처들 간의 관계의, 타겟 도메인의 2개의 피맵핑 스트럭처 사이에 존재하는 관계로의 맵핑)이다. 관계들 간의 맵핑은 2개의 데이터 모델의 병렬 내비게이션을 가능하게 한다. 즉, 한 도메인의 소정의 관계에 기초하여 한 스트럭처로부터 다른 스트럭처로 이동하는 것은 다른 도메인의 2개의 맵핑 스트럭처 사이에서 이동하는 것으로 번역한다.

관계 맵은 존재성 또는 복사 의미론보다는 덜 직관적인 개념이다. 관계 맵은 2개의 피맵핑 도메인에서 동시에 "그래프들을 진행하게" 할 수 있도록 하는 데 필요하다. 타겟 모델(예컨대, 오브젝트, XML 등)로부터의 2개의 피맵핑 스트럭처가 이들 간의 관계를 갖는 경우, 혹은 한 타겟 스트럭처가 하나 이상의 소스 스트럭처(예컨대, 테이블)에 맵핑되는 경우, 타겟 도메인에서의 함축적인(implicit) 혹은 명시적인(explicit) 관계는 소스 도메인(예컨대, 관계형)에서의 대응하는 관계에 맵핑되어야 한다. 타겟 도메인의 모든 관계가 소스 도메인의 관계에 맵핑되어야 하며, 그 역은 성립하지 않는다는 요건은, 소스 도메인에 대한 뷰로서의 타겟 도메인으로부터 기인한다는 것에 유의한다. 따라서, 맵핑은 이와 같은 뷰를 생성하는 데 필요한 최소한의 정보를 요구한다. 소스 도메인은 맵핑에 관련되지 않은 관계 및 스트럭처(테이블)를 상당히 많이 포함할 수 있다.

도메인 내의 스트럭처들 간의 관계는 참조 관계(한 타입이 다른 타입에 대한 참조를 갖고, 한 타입이 다른 타입에 종속되지 않는 삭제/갱신을 갖는 경우, 그 참조만이 소거됨) 또는 소유 관계(복합)(한 스트럭처가 다른 스트럭처를 소유하고, 한 스트럭처의 한 인스턴스에 대한 연산이 관련된 스트럭처의 한 인스턴스에 종속되는 관계)일 수 있다. 예를 들어, 특정 고객을 삭제하는 것은 그 주문도 삭제하는 것이지만, 주문 상세를 삭제하는 것은 제품을 삭제하는 것은 아니다.

임의의 특정 맵핑은 판독 및 기입(read and write) 연산들 모두에 적용된다. 따라서, 맵핑은 (양방향성의) 갱신 가능한 것으로 간주된다. 다른 동작(예를 들어, 다중 테이블 시나리오에 대한 판독 전용의 또는 기입의 한 타겟 스트럭처)을 지정하기 위해, 사용자는 각 도메인마다의 확장 가능 메커니즘의 이점을 이용할 수 있다. 예를 들어, 관계형 도메인은 질의, 갱신, 삽입, 및 삭제 명령을 갖는 CustomTable을 제시한다. 여기서, 사용자는 상기 명령이 맵핑에 기초하여 호출될 경우에 실행될 임의의 SQL 문장을 특정할 수 있다. 또 다른 예로는, 관계형 도메인의 컬럼 및 테이블에서의 ReadOnly 플래그가 있다. 상기의 컬럼이나 테이블을 갱신하기 위한 시도는 에러를 유발할 수 있지만, 이러한 정보는 도메인 내에서 기술되고, 맵핑에서는 기술되지 않는다.

이제, 도 4를 참조하면, 맵핑 파일(400)을 이용하여 소스 관계형 스키마를 타겟 XML 스키마에 맵핑하는 일례가 도시되어 있다. 본 발명의 양상에 따르면, 소스 스키마(402)도 타겟 스키마(404)도 맵핑을 수행하기 위한 임의의 방식으로 변경될 필요가 없다. 따라서, 소스 관계형 스키마(402)와 타겟 XML 스키마(404) 중 어 느 것도 편집될 필요가 없으므로, 이들 모두는 판독 전용일 수 있다. 많은 클라이언트 데이터 모델의 애플리케이션에서는 맵핑을 수행하기 위한 편집을 허용하지 않기 때문에, 본 발명의 이와 같은 특징은 의미있는 것이다.

개시되는 맵핑 포맷은, 소스 데이터 소스(402)에서 누락되는 정보와 함께 소스 데이터 소스(402)의 스키마를 정의하기 위한 소스 기술 컴포넌트(406); 타겟 데이터 소스(404)에서 누락되는 정보와 함께 타겟 데이터 소스(404)의 스키마를 정의하기 위한 타겟 기술 컴포넌트(408); 및 중앙 맵핑 컴포넌트(410)의 적어도 3가지 이상의 컴포넌트로 구성되는 것으로 볼 수 있다. 소스 기술 컴포넌트(406)는 관계형 소스 스키마(402)를 확장하고, 타겟 기술 컴포넌트(408)는 XML 타겟 스키마(404)를 확장하며, 중앙 맵핑 컴포넌트(410)는 실제 맵핑을 수행한다.

이 때의 태스크는 상기 2개의 스키마(402 및 404) 간의 맵핑을 정의하는 것으로서, 상기 맵핑에 따라서, 타겟 스키마(404)의 XSD에 의해 정의되는 포맷의 XML 데이터를 생성하기 위해 관계형 데이터베이스에 질의할 수 있고, 다른 방향으로는 소스로서 XML 데이터를 수용하여 이를 관계형 테이블로 로딩한 후, XML 데이터를 관계형 데이터로 재편성할 수 있다.

맵핑을 정의할 때 종래부터 있던 한 가지 문제점은 데이터 소스 스키마의 불완전성이다. 예를 들어, 관계형 스키마는, 데이터베이스에 사실상 존재하는 관계들 중 일부를 누락할 수 있다. 데이터베이스 설계자가 형식상 기본 키(primary key : PK) - 외래 키(foreign key : FK) 제약 조건으로서 관계를 정의하지 않는 일은 불행하게도 흔한 일이다. 외래 키 자체는 자식 테이블에서 제공되지만, 스키마 에 그 자체로서 마킹되어 있지는 않다. 그러나, 개시되는 맵핑 아키텍처에서는, 기본 키/외래 키 관계가 보다 바람직하므로, 정의될 필요가 있다. 또 다른 흔한 경우로는, 기본 키가 테이블에서 기본 키로서 마킹되어 있지 않은 경우이다.

때때로, 커스텀 관계를 스키마에 부가하는 것이 바람직할 수 있다. 예를 들어, "J"로 시작하는 VIN 번호를 갖는 모든 차량은 관계 "made in"을 갖는 "Countries" 테이블의 엔트리 "Japan"에 관련된다. 최악의 경우의 시나리오에서는 관계형 스키마 파일이 편집 가능하지 않은 경우이므로, 맵핑 파일(400)에는 관계형 스키마 파일에서 누락된 개념을 정의할 공간이 필요하다.

소스 및 타겟 기술 컴포넌트(406 및 407)는 이하에서 "DataSource" 엘리먼트에 대응한다.

맵핑 의미론 - 관계형 모델(도메인)

관계형 도메인의 맵핑 가능 스트럭처는 (CustomTable이라고 지칭하는) 커스텀 테이블이다. 커스텀 테이블은 컬럼/필드 및 명령의 집합으로 이루어져 있다. 커스텀 테이블은 물리적 관계의 스트럭처들 중 하나 즉, 뷰; UDF 또는 저장된 프로시저; SQL 문장(질의의 결과 셋트); 및 필터링된 테이블(조건이 적용된 테이블) 중 하나를 나타낼 수 있다. 모든 데이터베이스 테이블은 커스텀 테이블임을 유의한다. 사용자가 데이터베이스 테이블을 참조할 경우, 맵핑은 백그라운드에서 커스텀 테이블을 투명하게(transparently) 생성한다. 각 커스텀 테이블은 질의, 갱신, 삽입, 및 삭제의 4개의 명령을 갖는다. 이 명령들은 사용자에 의해 명시적으로 혹은 맵핑 엔진에 의해 자동으로 생성될 수 있다. 커스텀 테이블이 데이터베이스 테이 블에 기초한 경우, 커스텀 테이블은 데이터베이스 테이블 관계들을 상속한다(이는 그 반대 방향에서는 발생하지 않는다).

커스텀 테이블이 맵핑될 때마다, 커스텀 테이블은 관계형 도메인에서 일련의 인스턴스(이들을 레코드 셋트, 로우(row) 셋트 등으로 지칭하기도 함)를 생성한다. 맵핑은 커스텀 테이블이 맵핑될 때마다 새로운 일련의 인스턴스를 생성한다. 그렇지 않으면, 사용자가 자신이 다른 맵에서 생성된 일련의 인스턴스에 맵핑하고자 하는 것을 명확히 식별한다.

관계 - 관계형 도메인

관계는 임의의 두 커스텀 테이블들 간에 정의될 수 있다. 정규(regular) 테이블에 기초한 커스텀 테이블은 기본(base) 테이블로부터 모든 관계들을 상속한다. 이는, 사용자가 커스텀 테이블과 임의의 다른 테이블(또는 다른 커스텀 테이블) 간의 관계를 생성할 필요가 없다는 것을 의미한다. 왜냐하면, 유사한 관계들이 이미 기본 테이블과 다른 테이블 사이에 존재하기 때문이다. 그러나, 유사한 관계가 기본 테이블 사이에 존재하는 경우 커스텀 테이블들 사이에 관계를 생성하는 것은 오류가 아니다. 이러한 관계의 생성은 중복될 수 있고, 사용자가 기본 테이블에 정의된 관계를 재사용할 수 있다.

관계 상속에 관한 일례로는, 복수의 타겟 스트럭처가 컬럼 값에 기초하여 동일 테이블로부터 생성될 수 있는 단일 테이블 상속의 경우가 있다. 이제 도 5를 참조하여, 소스 도메인(500)과 타겟 도메인(502) 간의 맵핑을 살펴본다. 소스 도메인(500)은 부서 테이블(504) 및 직원 테이블(506)을 포함한다. 부서 테이블 (504)과 직원 테이블(506) 간의 관계(508)가 정의되어 있다. 직원 테이블(506)은 부서 테이블(504)로부터의 외래 키를 갖고, 이와 유사한 관계가 타겟 도메인(502)에 구조화되어 있다. 직원 테이블(506)은 "M", "HE", 및 "SE"의 3개의 값을 저장하는 직원 타입이라고 명명된 컬럼을 갖고 있다. 소스 도메인(500)으로부터 타겟 도메인(502)으로의 맵핑은 다음과 같다 : 부서 테이블(504)은 타겟 도메인(502)의 부서 테이블(510)로 맵핑됨; 값 "M"(512)은 경영자 테이블(514)에 맵핑됨 (M→Manager); 값 "HE"(516)는 시급 직원 테이블(518)에 맵핑됨 (HE→HourlyEmployee); 및 값 "SE"(520)는 월급 직원 테이블(522)에 맵핑됨 (SE→SalaryEmployee). 소스 도메인(500)의 외래 키 관계(508)로 인해, 타겟 도메인(502)의 부서 테이블(510)은 경영자 테이블(514), 시급 직원 테이블(518), 및 월급 직원 테이블(522)에 링크되어 있다.

외래 키는 소스 테이블과 타겟 테이블의 데이터 간의 링크를 설정하고 실행하는 데 사용되는 컬럼 또는 컬럼들의 집합이다. 링크는, 기본 키 값들을 보유하는 소스 테이블의 컬럼 또는 컬럼들을 타겟 테이블의 컬럼 또는 컬럼들에 부가함으로써, 소스 테이블과 타겟 테이블 사이에서 생성된다. 따라서, 이러한 컬럼(들)은 타겟 테이블의 외래 키가 된다.

도 5의 예에서, 3개의 커스텀 테이블 CTable(512, 516, 및 520)이 관계(508)를 부서 테이블(504)로부터 직원 테이블(506)으로 상속하므로, 이 커스텀 테이블들(514, 518, 및 520)과 부서 테이블(504) 간의 명시적인 관계가 가능하고, 이와 같이 수행하는 것이 오류가 아님에도 불구하고, 상기 관계를 생성할 필요가 없다. 기본 테이블(직원 테이블(506))에 대한 관계(508)는 커스텀 테이블(예컨대, 커스텀 테이블(514))에 의해 공유되므로, 사용자는 커스텀 테이블(514)과 다른 테이블 사이에 보다 많은 관계를 정의할 수 있다.

이하의 규칙들은 테이블에 기반한 커스텀 테이블들에 대해 관계가 어떻게 공유되는지를 설명한다. 물리적 테이블과 커스텀 테이블 사이에 맵핑이 존재하고, 그 둘 사이에서 관계가 참조되는 경우에는, 물리적 테이블과 커스텀 테이블이 기반하는 물리적 테이블 간의 관계와 같이, 커스텀 테이블과 물리적 테이블 간의 관계는 유효하다고 간주된다. 그 역은 성립하지 않는다. 즉, 2개의 커스텀 테이블이 관계를 갖는 경우, 이 커스텀 테이블이 기반하는 물리적 테이블들은 상기 관계를 공유하지 않는다는 것을 유의한다. 2개의 커스텀 테이블 사이에 맵핑이 존재하는 경우, 참조되는 관계는, 커스텀 테이블 1과 커스텀 테이블 2 사이, 커스텀 테이블 1과 커스텀 테이블 2의 기본 테이블 사이, 혹은 커스텀 테이블 1의 기본 테이블과 커스텀 테이블 2 사이, 혹은 커스텀 테이블 1 및 2의 기본 테이블들 사이에 존재할 수 있다.

관계형 도메인의 관계는 RSD의 관계 엘리먼트를 사용하여 정의된다. 관계는 데이터베이스에 정의된 물리적 외래 키 제한 조건 또는 맵핑 필요에 대한 새로운 정의의 관계에 기초한 것일 수 있다. 각 관계는 모호하지 않게 참조될 수 있도록 고유한 명칭을 가져야만 한다. 이하의 예제를 살펴본다.

<re:Relationship name="Cust_Ord" From="Customers" To="Orders" CascadeDelete="Server">

<re:ColumnJoin Column="id" RelatedColumn="customerid"/>

<re:Relationship>

관계들이 명칭에 의해 명시적으로 참조되면, 관계형 도메인은 동일한 테이블 쌍 사이에서 정의되는 복수의 관계들을 가질 수 있으며, 그들의 차이는 각 관계가 ColumnJoin들의 상이한 셋트를 갖는다는 점이다. 관계 요소는 맵핑 엔진의 모든 필요한 정보를 제공하여, 관계형 도메인에서의 다음과 같은 연산들을 수행한다 : 질의 연산에 대한 커스텀 테이블 간의 결합(join); 관련된 커스텀 테이블들 사이에서 갱신 연산을 종속시키는지의 여부; 갱신 연산의 순서(우선 삭제할 테이블부터와 같은 순서 등); 및 갱신 연산이 관계의 사상수(cardinality)에 매칭되는지에 관한 검증(validation).

맵핑 의미론 - 오브젝트 도메인

오브젝트 도메인은 타입(클래스)을 맵핑을 위해 맵핑 가능 스트럭처로서 나타낸다. 타입은 순로식(path expression)에 기초하여 전역(global) 혹은 지역(local)적으로 식별될 수 있다. 예를 들어, Target = "Address"는 전역 클레스 "Address"를 의미하는 한편, Target = "Customer/Address"는 Customer 클래스의 필드인 Address 클래스를 의미한다. 각 타입(전역이든 지역이든)은 (맵핑 엘리먼트를 이용하여) 관계형 도메인의 단 하나씩의 커스텀 테이블에 바로 맵핑될 수 있다. 타입은 다른 타입의 멤버들을 가질 수 있는데, 이는 타입 맵핑에 기초하여 생성되었던 타입의 인스턴스를 참조하는 것을 의미한다. 참조는 오브젝트 관계 정보에 기초하여 생성된다.

오브젝트 도메인 타입 매핑의 의미론은, 소스 도메인의 피맵핑 셋트의 기존의 인스턴스에 대해 오브젝트 도메인의 타입의 한 인스턴스의 최대치가 생성될 수 있고, 오브젝트 도메인의 관계 정보에 기초하여 해당 타입에 무한개의 참조가 생성될 수 있다는 것을 의미한다. 이러한 점을 예시하기 위해, 고객이 주소 클래스 타입인 "MyAddress"라는 멤버를 갖는 고객 클래스 및 주소 클래스를 살펴본다. 고객 클래스는 고객 테이블에 맵핑되고, 주소 클래스는 주소 테이블에 맵핑된다. 사용자가 "Address" 클래스를 검색하기 위해 맵핑을 통해 질의를 발행하면, 이 클래스의 새로운 인스턴스가 질의 기준(citeria)에 기초하여 생성되고, 그렇지 않으면 동일한 항등 관계를 갖는 주소 오브젝트가 이미 존재한다. 사용자가 "Customer" 클래스를 검색하기 위해 다른 질의를 발생하여 그 범위가 "MyAddress" 특성을 포함하는 경우에는, 그 인스턴스가 오브젝트 저장소에 사전에 존재하지 않을 때에만 새로운 주소 오브젝트가 "MyAddress" 멤버에 대해 생성된다. 우선, 이 인스턴스는 오브젝트 공간 컨텍스트(오브젝트 도메인)에 의해 관리되는 "Address" 오브젝트 집합에 부가된다. 다음으로, "MyAddress" 필드는 "Address" 인스턴스를 참조하여 갱신된다.

맵핑 의미론 - XML 모델(도메인)

XML 도메인은 엘리먼트를 맵핑 스트럭처로서 나타내고, 엘리먼트와 속성을 맵핑 필드로서 나타낸다. 다음과 같은 이유에서, XML 스키마의 타입 정의는 무시되고, 맵핑 스트럭처로 하는 것을 고려하지 않는다. XML 스키마는 명명된 타입과 익명의 타입 모두를 제공한다. 익명 타입을 맵핑하기 위해서는, 사용자는 순로식 을 이용함으로써 익명 타입을 식별할 필요가 있다. XML 도메인에서, 문서 내의 임의의 타입 발생에 대하여 새로운 타입이 생성된다. 그 이유는 오브젝트 도메인과는 달리 XML 도메인은 타입에 기반하여 XML 데이터를 관리하는 XML 문서 저장소를 갖지 않고, 이미 생성되었던 타입의 인스턴스에의 참조를 생성하기 때문이다. 이러한 XML 캐쉬가 저장소일 수 있게 하기 위해서는, 타입들이 XML 스키마에 기초하여 분명하지 않을 경우에 이 타입들을 분명하게 정의하기 위해 추가의 메타데이터를 부가하는 것이 XML 도메인의 맵핑에서 요구된다.

타입 명칭과 엘리먼트 명칭은 2개의 다른 값 공간에 있게 되는데, 타입 명칭과 엘리먼트 명칭 간의 차이로 맵핑하는 것이 한 가지 방안이다.

XSD 스키마에 대한 XPath의 서브셋트는 맵핑될 수 있는 인스턴스를 식별하는 데 사용된다. 맵핑 구문은 오브젝트 도메인에서의 맵핑 뿐만 아니라 XML 도메인에서의 맵핑에 기반한 타입을 지원한다.

맵핑 엘리먼트 및 속성

맵핑 구문은 맵핑 설계 섹션에서 기술된 맵핑 설계 및 원리를 지원하도록 설계된다. 맵핑 스키마의 포맷은 XML이 되도록 선택되는 것이었다. XML 포맷에 의하면, XML API를 사용하는 맵핑 고객은 맵핑 파일을 생성 및 유지하게 할 수 있으므로, 이는 사용자에 의한 판독을 보다 쉽게 하고, 맵핑 엔진이 맵핑 파일의 검증을 수행하는 데 XML 스키마를 사용하는 것이 가능하다.

이하는 하나 이상의 엘리먼트 및 속성의 고객 대 주문 맵핑의 완전한 맵핑의 일례를 나타낸다.

Customer와 Order는 클래스이고, Customer 클래스는 특성 MyOrders를 가지며, Order 클래스는 특성 MyCustomer를 갖는 오브젝트 스키마를 가정하면, 그 맵핑 섹션은 아래와 같이 변경된다 :

맵핑 스키마 엘리먼트(MappingSchema element)

MappingSchema는 맵핑 스키마의 루트 엘리먼트로서, 유효한 Mapping 및 DataSource 엘리먼트를 포함하여야 한다. MappingSchema는 메타데이터 세그먼트화 규칙에 기초하여 세그먼트화될 수 있다. 맵핑 포맷은 XML 문서이다. 이는 단일 루트 엘리먼트 즉, MappingSchema를 갖는다. 맵핑 파일은 소스 데이터 소스 및 타겟 데이터 소스의 기술, 이 소스들 간의 맵핑, 및 맵핑 스키마로 전달될 수 있는 복수의 파라미터 정의를 포함한다. 따라서, 루트 엘리먼트는 그 내부에 MappingParameter, DataSource, 및 Mapping sub-element를 갖는다. 어떤 DataSource나 Mapping sub-element도 갖지 않는 맵핑 스키마도 여전히 유효한 맵핑 스키마이다. 이러한 맵핑 스키마에 대하여 질의 및 갱신을 실행하는 행위는 이 스키마를 사용하는 특정 구현에 의해서 정해진다. 통상적으로 사용자는 이러한 엘리먼트에 대한 모든 네임스페이스를 정의해야 한다. 이러한 엘리먼트에 대해서는 어 떤 속성도 존재하지 않는다. 이러한 서브엘리먼트들의 순서는 중요하며, 아래의 표와 같은 순서로 되어야 한다.

태그	카드	설명
MappingParameter	0-1	전체 맵핑에 대한 파라미터를 기술하고, MappingParameter 엘리먼트들을 포함하며, 비어있을(empty) 수 있다.
DataSource	0-1	해당 mapping에 의해 맵핑된 모든 데이터 소스(DataSource 및 DataTarget)에 대한 기술을 포함함.
Mapping	0-1	데이터 소스들 간의 모든 맵핑을 정의함.

예제 :

데이터 소스 엘리먼트(DataSource element)

DataSource 엘리먼트는 피맵핑 데이터 소스의 스키마 정보를 보유한다. 데이터 소스는 스키마의 여러 다른 세그먼트들을 표현하는 다수의 스키마 파일들을 포함할 수 있다. 이 엘리먼트는 가상 SQL 서버를 표현한다.

속성 :

태그	카드	설명
Name	Req	해당 DataSource의 명칭. 명칭은 관계형 도메인의 접속로로서 외부 리소스와 해당 데이터 소스를 연관시키는 맵핑을 사용하는 외부 API로서 사용될 수 있음.
Default	Opt	소스 도메인에 전달된 디폴트 식별자의 명칭. 예컨대, 소정의 RSD로 된 디폴트 데이터베이스의 명칭

서브엘리먼트 :

태그	카드	설명
Schema	0+	도메인 스키마의 @Location 속성을 통해 상기 도메인 스키마를 가리킴.
InlineSchema	0-1	소스 도메인 스키마를 인라인형으로 포함함.

Schema 엘리먼트나 InlineSchema 엘리먼트가 제공되어야 하지만, 이들 중 단 하나만 제공되어야 한다. 예를 들어, 맵핑 파일을 보자. Schema/InlineSchema 엘리먼트가 유효 RSD를 가리키고 있어야 한다.

데이터 타겟 엘리먼트(DataTarget element)

본 엘리먼트는 피맵핑 타겟 도메인의 스키마 정보를 보유한다. 확장형 엘리먼트는 도메인 스키마에 정보를 부가할 수 있는 기능을 제공한다. 이는 해당 스키마가 편집될 수 없는 경우나, 해당 스키마가 맵핑을 위해 특별히 생성되지 않았던 경우에 유용하다. 타겟 스키마는 세그먼트화될 수 있다.

속성 :

태그	카드	설명
Type	Req	타겟 도메인의 타입. 적어도 XML과 OBJECT가 지원됨.

서브엘리먼트 :

태그	카드	설명
Schema	0+	도메인 스키마의 @Location 속성을 통해 해당 도메인 스키마를 가리킴.
InlineSchema	0-1	타겟 도메인 스키마를 인라인형으로 포함함.

서로 다른 도메인들로부터 타겟 도메인 스키마의 세그먼트를 갖는 것은 오류가 된다. 예컨대, XML 스키마와 Object 스키마를 혼합하는 것은 오류이다.

예를 들어, 맵핑 파일 예를 참조해 본다.

스키마 엘리먼트(Schema element)

Schema 엘리먼트는 데이터 소스의 스키마를 정의하기 위해 DataSource 엘리먼트에서 사용된다. 스키마는 인라인형으로 혹은 개별 파일형으로 정의될 수 있다. 스키마가 개별 XSD, RSD 등의 파일(대부분의 시나리오의 경우임)로 정의되면, Schema 엘리먼트가 사용되어야 한다. InlineSchema 엘리먼트는 스키마 도메인(XML 데이터 소스용의 XSD 등)의 네임스페이스에서 스키마 인라인(Schema 엘리먼트의 본문에 포함됨)을 정의하는 데 사용된다. 본 엘리먼트에는 서브엘리먼트가 없다. 이하의 속성을 유의한다.

태그	카드	설명
Location	Req	본 속성은 데이터 소스(XML용의 XSD, 관계형 데이터베이스용의 RSD, 오브젝트용의 OSD)의 스키마를 정의하는 파일의 URL임.

예제 :

인라인 스키마 엘리먼트(InlineSchema element)

Schema 엘리먼트는 데이터 소스의 스키마를 정의하기 위해 DataSource 엘리먼트에 사용된다. InlineSchema 엘리먼트는 스키마 도메인(XML 데이터 소스의 XSD 등)의 네임스페이스에서 스키마 인라인(Schema 엘리먼트의 본문에 포함됨)을 정의하는 데 사용된다. 본 엘리먼트에서 속성은 존재하지 않는다. 본 엘리먼트에서 서브엘리먼트도 존재하지 않는다. 본 엘리먼트의 본문은 스키마 정의(XSD, RSD, 또는 OSD)를 포함한다.

예제 :

관계형 맵 엘리먼트(RelationshipMap element)

RelationshipMap 엘리먼트는 Source 및 Target 도메인에서 Relationship을 어떻게 맵핑시키는지에 대한 정보를 제공하는 Map 엘리먼트의 자식 엘리먼트이다. 이 엘리먼트는, 타겟 도메인과 소스 도메인 양측에서 한 스트럭처로부터 다른 스트럭처로 이동할 때 어느 관계를 사용할지를 식별하는 데 필요하다. 본 섹션은 맵핑 스키마에서 본 엘리먼트의 구문, 의미론, 및 검증의 기술을 제공한다. 본 명세서를 볼 때에는 RelationshipMap 개념을 숙지한 상태이어야 한다. RelationshipMap 엘리먼트는 서로 다른 소스 스트럭처들에 맵핑된 2개의 피맵핑 스트럭처("피맵핑 스트럭처(mapped structure)"란 "Map" 엘리먼트를 이용하여 맵핑되어 있는 스트럭처를 의미함) 사이의 관계가 타겟 도메인에 존재하는 경우에 필요하다. 이러한 관계들의 일례로는, (오브젝트의 경우) 오브젝트의 타입이 다른 맵에 맵핑되어 있는 오브젝트 필드/특성, 및 (XML의 경우) 다른 맵핑 XML 엘리멘트의 자식인 맵핑 XML 엘리먼트가 있다.

RelationshipMap은 소스와 타겟을 관계형 맵 모두에 매칭하여야 함을 유의한다. 다음은 이러한 프로세서가 어떻게 동작하는지를 예시하는 것이다. 즉, 2개의 타겟 스트럭처 사이에 관계가 존재하고(상기의 예제들을 참조); 이 2개의 타겟 스트럭처는 2개의 Map(2개의 Map 엘리먼트)에 의해 맵핑되며; 이 Map들에 대해 적용 가능한 소스들은 RelationshipMap의 소스로서 특정된 유효한 관계를 갖는다.

또 다른 소스에 맵핑된 상속성이나 필드 등의 타겟 도메인에서의 기타 타입의 관계들이 각종 맵핑 속성들을 통해 핸들링된다(상속성의 경우에는 BasedOnRelationship, FieldMap의 필드의 경우에는 SourceRelationship).

맵핑 엔진이 타겟 도멘인의 관계를 식별하여 (맵핑 소스들(테이블들) 사이에서) 소스 도메인의 매칭 관계를 찾아냄으로써 RelationshipMap을 추론해낼 수 있지만, RelationshipMap은 2가지의 이유로 명확할 필요가 있다. 첫째로는, 명시적인 RelationshipMap이라 함은 RSD에 관계를 부가하는 것이 맵핑을 깨뜨리지 않는다는 것을 의미한다. 맵핑 엔진이 RelationshipMap을 추론하여 RSD에 관계를 부가하면, 부가된 Relationship이 단일 관계를 갖도록 사용되는 2개의 맵핑 테이블 사이 존재하므로, 맵핑을 깨뜨릴 수 있다. 관계를 부가한 후에, 맵핑 엔진은 어느 관계가 선택되었는지와 어느 관계가 예외를 두는지를 알지 못한다. 두번째로는, (RelationshipMap을 추론함으로써) "자동으로(magic)" 수행되기보다는, 사용자로 하여금, 맵핑의 3가지 간단한 개념들을 모두 이해하여 상기의 예제와 같이 불명확한 관계가 발견된 경우에 예외를 두게 하기 위한 보다 바람직한 유용한 경험이 될 것이다.

태그	카드	설명
Source	Req	소스 도메인에서의 관계에 대한 식별자. 이는 스페이스별 리스트임. 규칙으로부터 회피하는 것은 RSD spec에 규정되어 있음.
Target	Req	타겟 도메인에서의 다른 맵핑 스트럭처에 대한 식별자로서, 부모 맵 타겟 스트럭처에의 관계를 가짐.
UseForConcurrency	Opt	디폴트는 "항상(Always)"임.

소스는 소스 (관계형) 도메인에서 유효한 관계이어야 한다. 그 검증은 소스 스키마의 모든 세그먼트들이 로딩되어진 이후에 이루어진다.

타겟은 맵핑 타겟에의 관계를 갖는 타겟 도메인에서의 유효한 스트럭처이어 야 한다. 타겟은 타겟 도메인의 관련 피맵핑 스트럭처의 명칭이어야 한다. 또 다른 맵에 매핑되어 있지 않거나 부모 맵에 대한 타겟에의 관계를 갖지 않은 스트럭처(타입, 엘리먼트)의 명칭을 지정하는 것은 오류이다. XML 도메인에서, 타겟은 부모 맵에 대한 타겟인 엘리먼트의 자식이어야 한다. 부모 맵은 RelationshipMap이 포함되어 있는 맵을 지칭한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

관계 리스트에서, 부모 맵의 소스는 관계 리스트의 제1 관계의 "출처(From)"과 "목적지(To)" 중의 하나이어야 한다. 이러한 규칙은 제1 관계가 부모 맵의 소스를 포함하는 것을 보장한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

관계 리스트에서, 관련 타겟의 맵의 소스는 관계 리스트의 최종 관계의 "From"과 "To" 중의 하나이어야 한다. 이러한 규칙은 최종 관계가 관련 맵의 소스를 포함하는 것을 보장한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

소스가 관계 리스트에 있으면, 그 리스트는 정렬되어야 한다. 각 관계에 있어서, "From"과 "To" 중 하나는 다음 관계에서의 "From"이나 "To"에 매칭되어야 한다. 테이블들이 서로 결합(join)되지 않는 join절을 갖는 것이 부적절하기 때문에, 이러한 규칙은 관계로부터 구성되는 Join/Where절이 항상 유효하다는 것을 보장한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

2개의 피맵핑 타겟 스트럭처 간의 관계가 맵핑되어야 한다. 소스 속성을 통해서 소스 스트럭처에 맵핑되며 타겟 도메인에서 정의된 관계를 갖는 임의의 두 피맵핑 타겟 스트럭처는 RelationshipMap을 가져야 한다. "Ref" 속성을 통해 소스 스트럭처에 맵핑되는 타겟 스트럭처에의 관계는 해당 관계의 맵핑을 필요로 하지 않는다. 이 검증은 아래의 알고리즘을 이용하여 이루어진다 :

For 각 맵핑 타겟 스트럭처가 다른 타겟 스트럭처들에 대한 모든 관계를 취득하는 경우

{

For 각 해당 타겟 스트럭처의 경우

{

IF (

해당 타겟 스트럭처가 맵핑되어 있음

And (XML 도메인에만 적용하고, Object에 대해서는 무시함)

상기 스트럭처는 자식 엘리먼트이고, 현재 타겟 스트럭처는 "Ref" 속성을 이용하여 맵핑하지 않는다.

상기 검증 규칙들에 기반한 유효한 RelationshipMap이 존재하는지를 검증한다.

}

}

관련된 타겟들의 정의가 타겟 도메인 의미론에 따름을 유의한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

맵핑 관계들의 CascadeDelete 값은 매칭되어야 한다(오브젝트 도메인에만 적용됨). 매칭 값들의 허용 가능한 매트릭스는 아래와 같다 :

소스	타겟	유효
서버(Server)	불특정 참(True not specified)	예
명시적(Explicit)	불특정 참	예
불가(Never)	불특정 거짓(False not specified)	예

다른 어떤 조합도 에러이다. 이 검증은 맵핑 캐쉬에서 이루어진다.

관계들의 사상수 값은 매칭되어야 하며, 아래의 표와 같다 :

소스	타겟	유효
일대일(OneToOne)	오브젝트 도메인에서는 일대일	예
일대다(OneToMany)	일대다인 임의의 사상수	예

다른 어떤 조합도 에러이다. 이 검증은 맵핑 캐쉬에서 이루어진다. 예를 들어, 일반예(canonical example)를 참조한다.

맵 엘리먼트

맵 엘리먼트의 의미론은, 소스 도메인으로부터의 피맵핑 스트럭처의 인스턴스가 존재한다는 것은 피맵핑 타겟 스트럭처의 인스턴스가 타겟 도메인에 존재하여야 한다는 것을 내포한다는 것이다. 판독 연산에 있어서, 타겟 도메인에서의 스트럭처의 인스턴스는 소스 도메인에 존재하는 모든 인스턴스에 대하여 생성된다. 기입 연산에 있어서, 타겟 도메인에서의 인스턴스에 대한 이 연산은 소스 도메인의 기존의 인스턴스에 대한 동일 동작으로 번역된다. 예를 들어, 맵 엘리먼트를 이용한 고객 오브젝트 또는 엘리먼트에의 고객 테이블의 맵핑을 고려해본다. 이러한 맵의 의미론은 고객 오브젝트가 고객 테이블의 모든 행에 대해 생성된다는 것이다. 이러한 고객 오브젝트를 삭제하는 것은 고객 테이블에서 바로 그 한 행을 삭제하게 되는 것이며, 새로운 고객 오브젝트를 생성하는 것은 고객 테이블에 한 행을 삽입하게 되는 것으로, 갱신에서의 논리 적용과 마찬가지이다. 상술한 기존의 1 : 1 맵에 대한 확장성과 오버라이딩 메커니즘이 RSD로 특정된 CustomTable에 의해 제공된다. 맵핑 테이블 외의 임의의 다른 테이블에 또 다른 레코드를 삽입하는 등의 부효과가 가능하다. 사용자는 임의의 다른 테이블과 마찬가지로 각 타입의 연산(검색, 삽입, 갱신, 및 삭제)에 대한 명령을 갖는 CustomTable에 맵핑할 수 있다. 각 명령에서, 사용자는, 타겟 도메인에서 수행되는 연산에 기초하여 명령이 호출되면 맵핑 엔진에 의해 실행되는 SQL/SP를 특정할 수 있다. 이러한 명령은 타겟 도메인의 각 인스턴스마다 단 한 번 호출된다(모든 테이블은 참으로 설정된 자동 명령(auto command)를 갖는 커스텀 테이블임을 유의한다).

동일 소스 스트럭처는 복수의 맵에서 사용될 수 있다. 예로는, 다수의 오브젝트 타입에의 한 테이블의 맵핑(Customers 테이블은 Customer 오브젝트 및 CustomerInfor 오브젝트에 맵핑됨)이나, XML 엘리먼트에의 동일 테이블의 맵핑(Customers 테이블은 Company 엘리먼트 하의 Customer element 및 Customer 최상위 레벨의 엘리먼트에 맵핑됨)이 있다. 이러한 맵핑의 의미론은, 반복자(iterator)라고도 지칭되는 새로운 셋트가 모든 맵마다 소스 도메인 내에 생성된다는 것이다. 사용자는 소스 대신에 Ref 속성을 가짐으로써 동일 셋트를 사용할 수 있다.

속성 :

태그	카드	설명
Source	Opt	(관계형) 소스 도메인 내의 스트럭처(CustomTable)의 선택 표현식 또는 명칭.
Target	Req	타겟 도메인 내의 스트럭처의 선택 표현식.
Name	Opt	해당 맵의 고유 명칭. 이는 사용자가 맵을 참조할 필요가 있을 때 사용됨.
Ref	Opt	다른 맵의 명칭. XML 관계형 맵핑에만 사용될 수 있음.
BasedOnMap	Opt	또 다른 맵의 명칭.
BasedOnRelationship	Opt	관계형 도메인의 관계의 명칭.
UseForConcurrency	Opt	해당 맵 내의 모든 FieldMap에 대한 동기성 설정.

서브엘리먼트 :

태그	카드	설명
FieldMap	0+	본 변수의 필드들에 대한 맵핑.
OverflowMap	0-1	본 엘리멘트는 타겟 스트럭처에 대한 오버플로우를 소스 DataSource의 필드에 맵핑하는 데 사용됨. 본 엘리먼트는 XML 도메인에 의해서만 지원됨.
RelationshipMap	0+	다른 스트럭처에의 Map의 타겟 스트럭처의 관계와 맵핑 소스 스트럭처들 간의 적용 가능한 관계 간의 맵핑.

Target은 DataTarget의 유효한 스트럭처이다. Target 도메인에 존재하지 않는 타겟을 가리키는 맵을 갖는 것은 에러이다. 이 검증은 맵핑 캐쉬에서 이루어진다. Source가 존재하는 경우에, 이는 DataSource에서 유효한 스트럭처이어야 한다. Source 도메인에서 존재하지 않는 Source를 가리키는 맵을 갖는 것은 에러이다. 이 검증은 맵핑 캐쉬에서 이루어진다.

타겟 스트럭처는 단 한 번 맵핑될 수 있다. 이 규칙은 맵핑이 갱신 가능할 수 있게 하는 것으로서, Target 스트럭처가 단 한 번 맵핑될 수 있으므로 타겟 도메인 내의 이 스트럭처의 어떤 인스턴스라도 소스 (관계형) 도메인에 명확하게 기입될 수 있기 때문이다. 사용자가 판독 연산이나 기입 연산에서 타겟 스트럭처를 1회보다 많은 횟수로 맵핑하기를 원한다면, 사용자는 소스 (관계형) 도메인의 Custom 테이블을 사용할 수 있다. 이 검증은 매핑 캐쉬에서 이루어진다.

Map 명칭은 맵핑 스키마 전반에 걸쳐 고유하다. Map 명칭은 해당 맵을 다른 맵이 명시적으로 참조할 수 있도록 하기 위해 맵핑 파일 전반에 걸쳐 고유할 필요가 있다. Ref나 BasedOnMap과 같은 기존의 Map을 참조할 필요가 있는 소정의 기능이 존재한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

Ref 속성은 유효한 Map을 가리켜야 한다. Ref 속성의 값은 맵핑 스키마에서 기존의 유효한 맵에 대한 명칭이어야 한다. 이 검증은 맵핑 캐쉬에서 이루어진다. Ref 속성 및 Source 속성은 상호 배타적이다. 복수의 Source는 동일 맵에서 허용되지 않고, 따라서 Ref 속성(이는 해당 맵이 다른 맵으로부터 Source를 이용한다는 것을 의미함)은 동일 Map에서 Source와 함께 존재할 수 없다.

BasedOnRelationship 속성은 BasedOnMap 없이는 존재할 수 없다. Ref 속성 및 BasedOnRelationship 속성은 상호 배타적이다. Ref 속성은 범위 내에서 이미 Source(반복자)를 가리키고 있고, 따라서 관계를 특정할 필요가 없다.

Ref는 오브젝트 - 관계형 맵핑에 사용될 수 없다. Ref 속성 의미론은 오브젝트 - 관계형 맵핑에 적용되지 않는다.

예를 들어, 상술한 풀(full) 맵핑 예제를 참조한다.

필드 맵 서브엘리먼트(FieldMap sub-element)

FiledMap 엘리먼트는 한 도메인으로부터 다른 도메인으로 값을 복사하는 연산을 나타낸다. 맵핑 엔진은 판독 시에, 혹은 그 반대로 기입 시에, Source Field의 값을 Target Field로 간단히 복사한다. 이러한 값이 다른 Source(테이블)로부터 온 것인 경우, Source/Ref/SourceRelationship 속성들은 상기 값을 어떻게 취득 하는지에 대한 필요 정보를 제공한다. FieldMap은 기입 연산에 대한 동시성 옵션에 대한 설정 및 널 값 변환에 대한 정의를 허용한다.

FieldMap은 타겟 측에서의 데이터를 비정규화(denormalize)할 수 있다. 타겟 필드(오브젝트-필드 등)는 단 한 번 맵핑될 수 있다. 그러나, SourceField는 한 번보다 많은 횟수로 맵핑될 수 있다. 이는, 사용자가 타겟 도메인에서의 데이터를 비정규화하기를 원하는 시나리오를 지원하기 위해 허용된다. Orders 테이블이 CurrencyID에 대한 하나의 필드를 갖고, Order 오브젝트가 수량 필드마다 통화 필드(예컨대, FreightAmount와 FreightCurrency, TaxAmount와 TaxCurrency)를 갖는 시나리오를 고려해본다. 갱신 시에, 맵핑 엔진은 갱신 및 동일 소스 필드에의 맵핑된 타겟 필드가 동일 값을 갖는지를 확인한다.

동일 소스를 갖는 복수의 FieldMap이란, 사용자가 동일 셋트(이는, 변수(variable) 또는 반복자라고도 알려져 있음)를 참조하고 있다는 것을 의미한다. 이는 가장 간단하고 가장 직관적인 것으로서, 사용자가 동일한 관계에 대해 다른 셋트를 사용하기를 원하는 시나리오는 존재하지 않는다. 각종 키들에 기초하여 한 테이블을 다른 테이블에 결합하는 것은 새로운 결과 셋트를 생성한다는 것을 의미하는 것이므로, SourceRelationship을 변경하는 것은 새로운 셋트를 의미함을 유의한다. 이를 분명하고 명확하기 하기 위해, 이러한 동작의 의미론은 모든 Source가 새로운 셋트(결과 셋트에 대한 반복자)를 의미하는 Map 의미론과는 상이하다.

속성 :

태그	카드	설명
SourceField	Req	소스 도메인의 필드(데이터베이스의 경우, 컬럼) 또는 MappingParameter에 대한 식별자.
TargetField	Req	타겟 도메인의 필드(XML의 경우에는 속성 또는 단순 타입 엘리먼트, Object의 경우에는 필드) 또는 MappingParameter에 대한 식별자.
Source	Opt	소스 도메인의 스트럭처의 선택 표현식 또는 명칭. 제공되지 않는 경우에는 SourceField가 컨테이너 Map의 소스의 필드로서 해석됨.
SourceRelationship	Opt	map의 Source와 FieldMap의 Source 간의 관계에 대한 명칭.
ReadOnly	Opt	해당 필드가 SourceField에 기입될 수 없다는 것을 특정하는 부울. 타겟 필드는 어떤 갱신 연산에 대해서도 무시됨.
Ref	Opt	또 다른 맵의 명칭. XML - 관계형 맵핑의 경우에만 사용될 수 있음.
UseForConcurrency	Opt	본 FieldMap에 대한 동기성 설정.
NullHandling	Opt	"DomainNull", "Absence", 및 "UseNullValue"의 값들을 취득할 수 있음.
NullValue	Opt	타겟 도메인에서의 Null 사상(image) 표현.
ForceNullOnInsert	Opt	Null을 소스 도메인 필드(컬럼)에 명확하게 삽입하는 것을 허용하는 부울.

SourceField나 TargetField의 값이 "$"로 시작하면, 다른 필드(SourceField나 TargetField)는 MappingParameter에 맵핑된다. SourceField가 MappingParameter이면, 이 경우는 SourceField가 ReadOnly FieldMap이며, 갱신 연산에 포함되지 않는다는 것을 의미한다. SourceField/TargetField 검증 : 이 속성들의 값은 부모 Map Source/Target 스트럭처들 각각의 유효한 필드에 대해 혹은 Mapping Parameter에 대해 성공적으로 구해져야 한다. 이 속성들의 값들이 "$" 기호로 시작하면, 이 값들은 맵핑 파라미터 섹션 내의 선언된 맵핑 파라미터에 대해 구해져야 한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

Source/Ref/SourceRelationship은 소스 도메인에서 유효이어야 한다. Source는 소스 도메인에서의 유효한 스트럭처(CustomTable)에 대해 구해져야 하고, Ref는 기존의 맵의 명칭이어야 하며, SourceRelationship은 소스 도메인에서의 유 효한 관계의 명칭이어야 한다. 이 검증은 맵핑 캐쉬에서 이루어진다.

Ref 및 Source/SourceRelationship는 상호 배타적이다. Ref의 의미론이 다른 맵으로부터의 Source이므로, 그 소스는 SourceRelationship이 필요없도록 하는 범위 내에 있어야 한다.

Source가 FieldMap에 존재하면, SourceRelationship이 제공되어야 한다. 이는, Map의 소스와 FieldMap의 Source 사이에 어떤 관계가 있는지를 Mapping이 알 필요가 있기 때문이다.

SourceRelationship은 Source가 FieldMap에 존재하지 않는 경우에 제공될 수 없다. Source가 존재하지 않는 경우, 이는 SourceField가 부모 맵 소스 스트럭처에 속하는 것을 의미한다. 따라서, 관계 정보가 필요 없다.

임의의 특정 Target Field는 단 한 번 맵핑될 수 있다. 개념적으로, 양측 도메인의 필드들은 스칼라 값이므로, 이 값을 SourceField로부터 TargetField로 복사하는 것은 명확해야 하며, 어떤 병합(merge) 의미론도 가질 수 없다.

SourceField와 TargetField 둘 다는 맵핑 파라미터일 수 없다. 한 MappingParameter로부터 다른 MappingParameter로의 맵핑은 무의미하다.

UseForConcurrency는 SourceField가 MappingParameter인 경우를 특정할 수 없다. 이는 맵핑 파라미터의 컨텍스트에서 적용될 수 없다.

SourceRelationship의 사상수 값은 TargetField 타입과 호환 가능하여야 한다. SourceRelationship 사상수가 일대일(OneToOne)이면, TargetField 타입은 스칼라이어야 하며, 그렇지 않은 경우는 에러이다. SourceRelationship 사상수가 일 대다(OneToMany)이면, TargetField 타입은 리스트 타입이어야 하며, 그렇지 않은 경우는 에러이다(오브젝트 맵핑의 경우에는 이러한 케이스가 지원되지 않는다). 이 검증은, 예컨대 Customer 클래스에서의 "oid int" 타입 특성이 Customer 클래스와 다대일(many-to-one) 관계를 갖는 Orders 테이블의 orderId 컬럼에 맵핑되는 경우와 같이, 타겟 필드의 타입과 관계 사상수 간의 컴파일 시의 미스매칭을 검출할 수 있도록 하는 데 유용하다.

Ref는 오브젝트 - 관계형 맵핑에 사용될 수 없다. Ref 의미론은 오브젝트 - 관계형 맵핑에 적용되지 않는다. 예로서, 풀 맵핑 예제를 참조해 본다.

오버플로우 엘리먼트(OverflowMap element)

본 엘리먼트는 Overflow를 맵핑하는 데 사용되는 "Map" 엘리먼트에 항상 포함되어 있다. Overflow는 명시적으로 맵핑되어 있지 않은 컨테이닝 변수(containing variable) 내의 어떤 것으로서도 정의된다. 이는, 맵핑되지 않은 속성과 공개된 컨텐츠를 갖는 XML 엘리먼트들에 사용된다. 본 엘리먼트는 오브젝트 맵핑에 적용 가능하지 않으므로, 관계형 도메인과 오브젝트 도메인 사이에서 맵핑되는 맵핑 스키마에 본 엘리먼트가 있는 것은 에러이다.

Overflow SourceField는 자신의 루트 엘리먼트인 Map Target Structure 엘리먼트를 갖는 유효한 XML 문서(스트링으로서 저장되어 있음)를 포함하여야 한다. 질의 내에서 맵핑을 이용할 때, 루트 노드에 대한 속성들은 TargetStructure 엘리먼트에 부가되고, 그 서브엘리먼트들은 TargetStructure 엘리먼트의 자식 엘리먼트로서 부가된다.

기입 시나리오에서 맵핑을 이용할 때, TargetStructure 엘리먼트와 동일한 명칭을 갖는 XML 엘리먼트가 생성되고, 스키마에 포함되지 않거나 맵핑되지 않은 XML 엘리먼트의 속성들이 루트 엘리먼트에 부가된다. 맵핑되지 않거나 스키마에 포함되지 않은 서브엘리먼트들은 XML 엘리먼트의 텍스트 컨텐츠를 포함하여 XML 엘리먼트의 자식 엘리먼트로서 부가된다.

사용자는 질의 및 오버플로우 데이터에의 갱신을 행할 수 있으며, 이러한 동작을 융합(fusion)이라고 지칭한다. 에러 조건은 아래와 같다 :

질의 - (중복 속성 조건을 생성하는) 오버플로우 필드에 맵핑 속성을 갖는 것.

질의 - 맵핑되었고 오버플로우 필드에 포함되어 있는 TargetStructure 엘리먼트의 텍스트 컨텐츠를 갖는 것.

속성 :

태그	카드	설명
SourceField	Req	Source 도메인에서의 필드(데이터베이스의 경우, 컬럼)의 명칭. 이 명칭은 컨테이닝에 관련됨. 필드의 구문은 데이터 소스에 따름.

본 엘리먼트는 어떤 서브엘리먼트도 갖지 않는다.

맵핑 파라미터 엘리먼트(MappingParameter element)

맵핑 파라미터의 의미론은 런타임 시에 소스 필드나 타겟 필드에 알려져 있는 값을 맵핑할 수 있는 기능을 말한다. MappingParameter는 MappingParameter 섹션에서 선언되며, 런타임 시에 맵핑 API를 통해서 액세스될 수 있다. 또한, FieldMap에 대한 NullHandling 설정은 SourceField나 TargetField로서 사용될 수 있다. 맵핑 엔진은 MappingParameter 명칭의 시작부에서 전치 부호 $에 기초하여 상기 두 필드를 구분한다($는 모든 맵핑 도메인(오브젝트, XML, 관계형(관계형은 제외될 수도 있음))들에서 식별자에 대한 위법(illegal) 문자임). MappingParameter는 타입이 정해지지 않았으므로, 그 XSD 타입은 스트링이다. 런타임 시에, 맵핑 엔진은 상기 값을 맵핑 필드(타겟 필드 또는 소스 필드) 타입의 타입으로 변환시킨다.

본 엘리먼트의 텍스트 컨텐츠는 상기 파라미터의 디폴트 값이다. 이 값은 ObjectSpace, XQueryProcessor, Bulkload, 및 XMLAdapter 등의 맵핑을 사용하는 애플리케이션에 의해 런타임 시에 변경될 수 있다.

속성 :

태그	카드	설명
Name	Req	파라미터의 명칭. 이는 맵핑 파일 내에서 고유하여야 함. 이는, 파라미터가 맵핑에서 어떻게 참조되는지를 나타냄. 명칭은 "$"로 시작하여야 함.

SourceField/TargetField/NullValue의 값이 "$$"로 시작한다면, 이는, SourceField/TargetField/NullValue가 맵핑 파라미터가 아니며, 실제 값은 단일의 "$"로 시작한다는 것을 의미한다. MappingParameter는 SourceField, TargetField, 또는 NullValue의 값으로만 사용될 수 있다. 맵핑 엔진은 이들의 필드 맵핑에 기초하여 맵핑 파라미터 값을 할당할 수 없다. 이들은 다음과 같은 맵핑 컨텍스트에서 적용 및 사용된다 : MappingParameter는 SourceField에 맵핑되어, 기입 연산에 는 사용되고, 판독 연산에는 무시된다. MappingParameter는 TargetField에 맵핑되어, 판독 연산에는 사용되고, 기입 연산에는 무시된다. 따라서, MappingParameter는 출력 파라미터로서 사용될 수 없다.

Bulkload에서, 사용자는 자신의 데이터베이스에 XSD 스키마에 포함되지 않은 데이터를 삽입하고자 하는 경우가 많을 수 있다. 또한, 이 데이터는 통상적으로 런타임 시에만 알려진 것일 수 있으며, XML 문서의 일부로서 포함되지 않는다. 예로는 userid, machine id 등이 있다.

사용자는 맵핑 스키마 전반에서 사용되는 NullValue를 통합하기를 원할 수 있다. 이는, 소정의 디폴트 값을 사용하여 MappingParameter를 생성하고, 이 맵핑 파라미터를 복수의 FieldMap의 NullValue 속성의 값에 사용함으로써, 수행된다.

검증에 있어서, MappingParameter의 명칭은 문자 "$"로 시작하여야 한다. 다른 임의의 문자는 에러를 일으킨다. 명칭은 "$$"으로 시작할 수 없다. 이는, 사용자가 "$"로 시작하는 유효한 도메인 필드 명칭을 갖거나 "$"로서 널 값을 가리키고자 하는 경우에 "$" 부호를 회피할 수 있게 한다.

명칭은, 런타임 시에 소스 필드나 타겟 필드에의 맵핑 파라미터에 값을 할당할 때의 모호함을 회피할 수 있도록, 맵핑 스키마 전반에 있어서 고유하여야 한다. 명칭의 고유성은 맵핑 스키마의 로딩된 모든 세그먼트에 대한 것임을 유의한다.

BasedOnMap - BasedOnRelationship 속성

설계 지침은, 필요한 모든 맵핑 정보는 맵핑 파일의 맵핑 섹션으로부터 제공되는 것이지, 도메인으로부터 제공되는 것이 아니라는 데 있다. 따라서, 상속 및 재귀(recursion)의 경우, 사용자는 재귀 엘리먼트 및 피상속 클래스 필드를 맵핑하기 위한 정보를 명시적으로 제공할 필요가 있다. "BasedOnMap" 속성은, 사용자에게, 한 맵으로부터 다른 맵으로 FieldMap 및 RelationshipMap을 복사하기 위한 구문상 쇼트컷(shortcut)을 제공한다. 이에 의하면, 맵핑 엔진은 오브젝트 상속 시나리오 및 XML 재귀 시나리오에서 FieldMap 및 RelationshipMap을 복사하는 데 필요한 정보를 취득하여, 명확하며 도메인으로부터 독립적인 맵핑 구문을 보유할 수 있다. BasedOnMap 옵션은 맵으로부터 FieldMap 및 RelationshipMap을 복사하므로, 이들과 같이 그 명칭이 "BasedOnMap" 속성의 값으로서 불리운다. 복사된 FieldMap/RelationshipMap은 SourceRelationship 속성을 포함한 기본 속성들과 동일하다.

BasedOnRelationship은 Map의 Source가 BasedOnMap이 특정된 Map의 Source와는 다른 경우에 사용된다. 따라서, BasedOnRelationship은 모든 관련 소스 정보 및 관계(SourceRelationship, RelationshipMap)를 생성 및 갱신할 것을 요구한다. BasedOnRelationship 속성을 특정하는 것은, 기본 Map 및 SourceRelationship에서 BasedonRelationship 속성의 값으로 특정하는 것과 마찬가지로, 복사된 FieldMap에 Source의 값과 함께 Source 속성을 부가한다. 복사된 FieldMap이 임의의 복사된 RelationshipMap에 대해서 이미 Source 속성 및 SourceRelationship 속성을 갖고 있다면, 이 속성들은 맵에 기초하여 Source와 새로운 맵의 Source 간의 관계를 이용하여 갱신된다.

BasedOnMap 속성 및 BasedOnRelationship 속성은 모두 구문상 쇼트컷을 허용 하는 매크로(macro)로서 해석될 수 있다. 다음의 기술 및 규칙의 2개의 핵심어 즉, BasedOnMapValue - BasedOnMap 속성에 의해 특정되는 값 - 및 BasedRelationshipValue - BasedOnRelationship 속성에 의해 특정되는 값 - 가 사용된다.

BasedOnMap의 값은 FieldMap을 복사하기 위한 Map 명칭이다. BasedOnMap이 선언된 Map을 가리키는 명명된 Map으로부터 FieldMap을 간단히 복사한다. Map으로부터, 모든 자식 FieldMap 엘리먼트 및 RelationshipMap 엘리먼트를 그 속성들과 함께 복사한다. Map의 명칭은 BasedOnMap 속성이 특정된 Map 엘리먼트에 대한 BasedOnMapValue이다.

BasedOnRelationship 속성은 BasedOnMap 속성을 갖는다. 모든 FieldMap 엘리먼트에 대해서, 관련되는 FieldMap을 찾아 갱신한다. 명칭이 BasedOnMapValue인 Map으로부터 모든 자식 FieldMap 엘리먼트를 찾아낸다. Source 속성이 FieldMap에 존재하는 경우, 그대로 그 값을 두고, 그렇지 않으면, 명칭이 BasedOnMapValue인 Map 엘리먼트의 Source 속성의 값을 갖는 Source 속성을 FieldMap에 부가한다.

SourceRelationship 속성이 FieldMap에 존재하는 경우, 공백문자(" ")를 SourceRelationship 속성의 시작에 삽입한다. BasedRelationshipValue를 SourceRelationship의 시작에 삽입하고, 그렇지 않으면, BasedRelationshipValue의 값을 갖는 SourceRelationship 속성을 부가한다.

변경된 Source 속성 및 SourceRelationship 속성과 변경되지 않은 그 외 다른 모든 속성들을 갖는 모든 FieldMap 엘리먼트들을, BasedOnMap 속성 및 BasedOnRelationship 속성이 특정된 Map 엘리먼트에 둔다.

모든 자식 RelationshipMap 엘리먼트의 모든 속성들을 그대로 유지하면서 명칭이 BasedOnMapValue인 Map으로부터 모든 자식 RelationshipMap 엘리먼트를 찾아낸다. 모든 RelationshipMap에 대해서, Source 속성의 값의 시작에 공백문자(" ")를 삽입한다. BasedRelationshipValue를 Source 속성의 시작에 삽입한다. BasedOnMap 속성 및 BasedOnRelationship 속성이 특정된 Map 엘리먼트에, 변경된 Source 속성을 갖는 모든 RelationshipMap 엘리먼트들 및 변경되지 않은 그 외 다른 모든 속성들을 복사한다.

상술한 의미론은 아래의 규칙들이 적용된다는 것을 내포한다. BasedOnMap은 유효한 Map 명칭을 참조하여야 한다. BasedOnRelationship은 소스 도메인의 유효한 Relationship 명칭을 참조하여야 한다. BasedOnRelationship이 특정되는 경우에 유효한 BasedOnMap이 존재하여야 한다. 복사된 FieldMap은 명확하게 정의되는 그 외 다른 모든 맵핑 규칙들을에 따른다.

예제 - XML 경우의 BasedOnRelationship의 사용

테이블 :

Employee(EID, FirstName, LastName, HireDate, Salary, Manager)

FiredEmployee(EID, FirstName, LastName, HireDate, Salary, Manager)

XML에서의 결과 샘플 :

맵핑 :

맵핑 엔진에서 생성되는 바와 같은 실제 Map :

테이블 간 상속 계층구조(오브젝트)

테이블 :

Persons(SSId, FirstName, LastName)

Employee(EID, EmployeeSSID, HireDate, Salary, Manager)

Manager(EID, Bonus)

상속 계층구조 : Person→Employee→Manager

맵핑 :

맵핑 엔진에서 생성되는 바와 같은 실제 Map :

동일 기본 테이블(다른 커스텀 테이블)을 사용한 상속성

예제(오브젝트)

RSD :

MAP :

의미하는 바 :

널 핸들링(NullHandling) 속성

값 NULL은, 알려지지 않거나 이용 가능하지 않은 컬럼의 데이터 값을 의미한다. NULL은 제로(zero)(수치 혹은 이진값), 제로 길이의 스트링, 또는 공백(문자 값)과 동의어는 아니다. 오히려, 널 값은 제로(수치 컬럼)나 공백(문자 컬럼)의 엔트리와 넌엔트리(nonentry)(수치 컬럼과 문자 컬럼 둘 다에서의 NULL) 간의 구별을 허용한다. 2개의 널값은 동치가 아니다. 2개의 널값 간의 비교 혹은 NULL과 다른 임의의 값 간의 비교는 미지(unknown)를 리턴한다. 그 이유는 각 NULL의 값 이 unknown이기 때문이다. 널값은 대개 알려지지 않거나, 적용 가능하지 않거나, 차후에 부가될 데이터를 나타낸다. 예를 들어, 고객의 중간이름의 첫글자는 고객이 주문을 할 때에 알려지지 않을 수도 있다. 널을 맵핑하는 것은 복잡한 작업이다. 그 이유는 그 값이 unknown이고, 각 도메인마다 그 개념(널)을 달리 표현하기 때문이다. 때로는, 널은 각종 다른 방식으로 표현되기도 한다. 예를 들어, XML 도메인은 널을 xsi:nil, 부재(absence), 또는 빈 리스트(empty list)로서 표현하고, 오브젝트 도메인은 널 가능 타입(nullable type) 및 DBNull인 SQL 타입을 가질 수 있다. 또한, 사용자는 널을 표현하는 Target 도메인에서 값(이 값을 종종 널 사상이라고도 지칭함)을 선택하기를 원할 수 있다.

NullHandling 속성은 널을 소스 도메인으로부터 타겟 도메인의 널 표현으로, 그리고 그 역의 방식으로(타게 도메인의 값으로부터 소스 도메인의 널로) 변환하는 기능을 제공한다.

속성 명칭	타입	카드	값	설명
NullHandling	xsd:string	선택적	'DomainNull' 'Absence' 'UseNullValue'	판독 및 기입 시나리오에 적용함.
NullValue	xsd:string	NullHandling 값이 'UseNullValue'이거나, 그렇지 않으면 부재이어야 하는 경우에 요구됨	사용자가 제공	널값은 로캘(locale) 인식되어야 함.
ForceNullOnInsert	xsd:Boolean	선택적	참/거짓	디폴트 = 거짓

S를 소스 (관계형) 도메인의 SourceField로서 정의하고, T를 타겟 (오브젝트, XML) 도메인의 TargetField로서 정의한다. S(Null) ⇔ T(NullHandling 속성에 기초한 값). 이는, 질의 상에서 널이 NullHandling, NullValue 속성에 특정된 값 으로의 데이터베이스(DB)의 출력임을 의미한다. 갱신 시에, 타겟 도메인의 값이 상기 속성에 특정되었던 것이면, 그 값은 타겟 도메인에서 소스 도메인의 널로 번역된다. 타겟 도메인의 NullHandling의 특정 동작 및 디폴트는 각 타겟 도메인 사양(specification)에 기술되어 있다.

새로운 타겟 스트럭처(오브젝트 또는 XML 엘리먼트)를 생성하여 널 값의 필드에 할당하거나 XML 속성을 생략할 경우, 갱신 엔진에 의한 디폴트 동작은 값을 컬럼에 대해 정의된 디폴트 값으로 설정하는 것이다. 디폴트 값이 없는 경우에는 널이 적용될 것임을 의미하는 것이다.

ForceNullOnInsert는 사용자가 상술한 디폴트 동작을 오버라이딩하기를 원하는 경우를 지원한다. 이 경우, 사용자는 갱신 엔진이 널을 컬럼에 정확하게 기입하여 컬럼에 정의되어 있는 어떤 디폴트라도 오버라이딩할 수 있기를 원한다. ForceNullOnInsert 속성을 TRUE로 설정하는 것은 오브젝트/엘리먼트가 생성되었을 때 타겟 도메인의 임의의 널 값에 해당하는 컬럼에 널이 명확히 삽입됨을 의미한다. 이러한 특징을 위한 주 시나리오는 (커스텀 테이블의 삽입 명령으로서 나타나 있는) 기존의 Insert 프로시저의 파라미터에 널을 전달하는 것이다.

NullValue는 NullHandling 값이 "UseNullValue"인 경우에 제공될 수 있다.

NullValue로서의 공백 스트링 - 본 예의 경우, 사용자는 고객의 중간이름 첫글자 특성에 대해 널인 빈 스트링을 특정하기를 원한다.

널 핸들링을 위한 DomainNull의 사용 - 본 예의 경우, MI는 XML 도메인의 한 엘리먼트의 명칭이다.

XML은 <MI xsi:nil="true"/>일 것이다.

UseForConcurrency 속성

본 속성에 대한 필요의 이면에 있는 이론 및 추론은 낙관적 병행수행 문서(Optimistic Concurrency document)에 기술되어 있다. 병행수행이 맵핑에 기술되어 있고 RSD에 기술되어 있지 않은 이유는 소정의 시나리오에서 사용자가 다른 병행수행 설정을 원할 수 있기 때문이다. 2개의 클래스에 맵핑되어 있는 비정규화 테이블을 고찰해보자. 이 클래스들은 병행수행 제어에 사용되어야 하는 여러 필드들을 가질 수 있다. 일반적으로 말하면, 사용자들은 자신의 비즈니스 로직에 의해 유도된 여러 다른 맵핑들에 동일 RSD 정보를 공유하기를 원한다. UseForConcurrency 속성은, 항상(Always; 이 필드는 병행수행에 항상 사용되며, 디폴트 값임), 불가(Never; 이 필드는 병형수행에 결코 사용되지 않음), 및 변경(Modified; 이 필드는 값이 변경된 경우에만 병행수행에 사용됨)의 3가지 값을 갖는 열거(enum)이다.

UseForConcurrency 속성은 FieldMap과 Map 둘 다에서 사용될 수 있다. 그 디폴트 메커니즘은 다음과 같다. UseForConconcurrency가 특정되지 않은 경우에, 디폴트는 "Always"이다. UseForConconcurrency가 Map에 특정된 경우에, 디폴트는 Map에 관련된 모든 FieldMap 및 RelationshipMap에 대한 UseForConcurrency의 값으로서 사용되며, 그렇지 않다면, FieldMap 및 RelationshipMap은 UseForConcurrency 가 미리 정해져 있다. 이 경우, 정의되어 있는 값은 Map에 특정된 디폴트를 오버라이딩한다. FieldMap에 특정된 UseForConcurrency는 Map 또는 RelationshipMap에 정의된 UseForConcurrency를 오버라이딩한다.

사용자는 RelationshipMap 엘리먼트에 대한 UseForConcurrency 속성을 특정함으로써 명시적으로 맵핑되어 있지 않은 relationship 필드에 대한 병행수행 설정을 제어할 수 있다. RelationshipMap에 대한 이 속성은 모든 relationship 필드에 적용됨을 유의한다.

검증은 다음과 같이 수행된다. Alternate Key UseForConcurrency = Always인 경우, 이는 병행수행에 사용되며, Primary Key concurrency는 다른 임의의 필드와 같은 디폴트 규칙에 기초하여 결정된다. 그렇지 않고, Alternate Key가 존재하지 않거나 UseForConcurrency = Always로서 마크되어 있지 않으면, Primary Key UseForConcurrency는 디폴트가 Always로 된다(맵핑 엔진은 Map UseForConcurrency 값을 무시함). Primary Key FieldMap에 대한 UseForConcurrency 값이 다른 임의의 값(Never 또는 Modified)에 명시적으로 설정되어 있으면, 맵핑 엔진은 예외를 통해 진행된다.

예제 :

맵은 아래와 같이 내부적으로 표현된다 :

Ref 속성

Ref 속성 값은 Map의 명칭이다. 이 속성의 의미론은 타겟 스트럭처 또는 타겟 필드가 명명된 맵의 동일 Source에 맵핑되는 것이다. "동일 소스(same Source)"라 함은 관계형 도메인의 테이블로부터 선택된 셋트를 의미한다. 관계형 도메인의 의미론에 기초하여, 맵핑 엔진은 테이블이 맵핑될 때마다 새로운 레코드들의 셋트(선택 문장)를 생성한다. XML 도메인의 무소속의 대상과 같은 몇몇 경우, 사용자는 미리 생성되어 있던 셋트를 타겟 스트럭처 또는 필드에 맵핑하기를 원할 수 있다. 사용자가 고객 주문을 포함하는 고객 엘리먼트를 갖는 이하의 시나리오(XML 도메인 맵핑을 취함)를 고려해 본다. Order 엘리먼트는 고객 성명을 포 함한다.

관계형 스트럭처는 MyBuyerRelationship을 갖는 Customers 테이블 및 Orders 테이블이다. 따라서, 맵핑은 다음과 같을 수 있다 :

상기는 다른 셋트 및 결합을 생성할 필요를 덜어줌으로써 주문 엘리먼트에 대한 고객 성명을 취득하는 효과적인 방법이다. 소스 도메인의 각 스트럭처(행)로부터 복수의 XML 엘리먼트가 생성될 수 있으므로, Ref 속성은 XML 도메인에만 사용됨을 유의한다. 또한, 상기의 예제로부터 알 수 있는 바와 같이, 상기 행으로부터의 값들은 XML 계층에서 계통을 잇는 임의의 것에 의해 선택될 수 있다.

갱신 의미론

맵핑의 강력한 속성은 갱신 가능하다는 기능에 있다. 자신의 오브젝트 도메인이나 XML 도메인의 변동 사항을 SQL 서버 도메인으로 전달 및 동기화하기 위한 다량의 코드를 작성할 필요가 있었던 많은 개발자들은 자신들의 이러한 작업을 수행하는 맵핑 엔진에 맡길 수 있다. 사용자들이 타겟 도메인의 스트럭처(오브젝트 또는 XML 엘리먼트)를 생성, 삭제, 또는 변경하면, 이러한 변동 사항들이 타겟 도메인 API 및 맵핑 엔진(이는 변경 프로세서(change processor : CP)라고 알려져 있 으며, 이를 이하의 섹션에서는 CP라고 칭함)에 의해서 소스 도메인으로 극적으로 동기화된다. 이 섹션은 소스 도메인(관계형 데이터 모델)에 존속하는 타겟 도메인의 변동 사항들의 의미론을 설명한다.

이하의 용어들은 상술한 존재(Existence), 복사(Copy), 및 맵핑 관계(Mapping Relationship)의 개념들에 부가되는 것이다.

타겟 유닛(Target Unit) - Map 엘리먼트를 이용하여 동일 소스 스트럭처에 맵핑되는 타겟 도메인으로부터의 스트럭처 또는 스트럭처 그룹. 타겟 스트럭처 그룹은 Ref 속성을 이용하여 다른 Map을 참조하는 맵에서의 타겟이다(타겟 유닛은 참조되는 Map을 포함한다). 이는, 이러한 스트럭처들의 그룹핑이 가능하지 않고 Map 엘리먼트를 이용하여 맵핑되는 각 오브젝트가 타겟 유닛인 오브젝트 도메인과, 상술한 바와 같이 스트럭처들의 그룹이 생성될 수 있는 XML 도메인 간의 결정적인 차이이다.

소스 유닛(Source Unit) - 소스 도메인에서의 스트럭처. 관계형 도메인에서, 소스는 CustomTable이다.

변경 유닛(Changed Unit) - 변경되어 있는 타겟 유닛으로 맵핑되는 소스 유닛.

CP는 소스 도메인의 해당 유닛들에 대해 수행할 연산들, 연산들의 순서, 검증을 결정하기 위해 어떤 변경 유닛의 관계들조차도 관찰한다. 타겟 도메인과 소스 도메인 둘 다의 해당 유닛들에 변동 사항을 적용하여 이들을 동기화시키는 일은 매우 복잡하다. RelationshipMap 섹션의 검증 규칙들은 타겟 도메인의 변동 사항 들이 소스 도메인에서 CP에 의해 적용되는 변동 사항들과 충돌하지 않도록 보장한다.

본 섹션은 소스 도메인 스키마의 관계 엘리먼트(RSD)의 의미론을 설명한다.

From 및 To

"From"은 관계에 있어서 부모 유닛을 말하고, "To"는 관계에 있어서 자식 유닛을 말한다. 부모 유닛과 자식 유닛의 구별은 소스 도메인에서 연산들의 순서를 결정하는 데 필요하다. 변동 사항의 종류(삽입, 삭제, 및 갱신)는 연산의 실행 순서를 결정하는 데 사용된다. 삽입/갱신의 경우에는 부모가 먼저 실행되고, 삭제의 경우에는 자식이 먼저 실행된다.

CascadeDelete/CascadeUpdate

소스 도메인에 변동 사항을 적용할 때, CP는 변경 유닛(이 변경 유닛이 부모임)과 다른 맵핑 소스 유닛 간의 모든 관계를 찾아낸다. CascadeDelete/CascadeUpdate의 값은 연산이 자식 테이블에 영향을 끼치는지의 여부를 결정한다. 이 속성들의 값은 자식 테이블에서 변동 사항들을 CP가 실행할지 혹은 SQL 서버가 실행할지를 결정한다.

IsForeinKey를 이용한 계산 유닛(calculating unit)(테이블) 종속성

이하, 갱신 엔진 CP의 행 실행 순서를 결정하기 위한 관계 정보에 기반한 테이블 내 행 종속성(유닛 종속성이라도 함) 및 계산 테이블 종속성의 의미론을 설명한다. CP는 부모(From)와 자식(To)의 정보 및 관계 엘리먼트에 대한 IsForeignKey 속성에 의해 표시되는 외래 키 제약 조건의 존재를 이용하여, 갱신 문장들의 실행 순서 및 종속성을 결정한다.

아래 예제는 Customers→Orders→OrderDetails의 간단한 계층이 있고, 이 계층에는 순환적 참조(circular reference)는 없다.

아래 예제는 한 관계가 서버 상에서 FK 제약 조건이 아니라는(IsForeignKey = false) Circular Reference이다. 이는, 적어도 한 관계에서 외래 키 제약 조건이 서버 상에서 생성되지 않는다는 시나리오이다. 맵핑의 순서는 A→B→C이다.

아래 예제는 모든 관계가 서버 상에서 FK 제약 조건인(IsForeignKey = false) Circular Reference이다. 이는, 서버 상에서 외래 키 제약 조건에 의해 모 든 관계가 적용된다. 맵핑의 순서는 C→A→B이다.

또는

맵핑 컴파일 시에, "From" 및 "To" 지향적 속성은 테이블 종속성을 결정하는 데 주로 사용된다. 이는, 제1 시나리오와 유사한 모든 간단한 계층적 시나리오를 해결한다. 한편, 관계 방향이 순환적 참조를 유발하는 상기 제2 및 제3 시나리오에서는, 서버 상에서 구현된 외래 키 제약 조건을 가리키지 않는(IsForeignKey = "true") 관계를 무시함으로써 종속성을 찾아내고자 한다. 이는 제2 시나리오를 처리한다. 순환적 참조가 여전히 존재하는(즉, 모든 관계가 외래 키 제약 조건으로서 구현되었으므로 어떤 관계 경로도 무시되지 않는) 경우에는, (이하의 알고리즘 섹션에서 설명되는 바와 같이) 계층적 트리에서 임의 방식(random way)으로 종속성 그래프가 해결된다.

런타임 시에, 제1 시나리오에서처럼 ChangeUnit이 수신되면, 더 이상의 연산이 필요하지 않으며, 실행 순서는 컴파일 종속성 그래프에 따라 수행된다. 그러나, 제2 및 제3 시나리오에서의 순환적 참조의 경우에는 ChangeUnit을 이용함으로 써 정확한 실행 순서를 정하기 위해 런타임 인스턴스들을 평가한다. 대부분의 경우, 런타임 인스턴스들은 그래프를 형성하지 않으며, ChangeUnit들은 계층적 방식(HarronA→DanielD→Foo→Bar→BillG)으로 실행된다. 그러나, 런타임 인스턴스들이 그래프를 형성하는 경우, 이 유닛들은 컴파일 시간 종속성에 따라 실행된다. 이는 제2 시나리오의 경우에 동작하는 반면, 모든 관계가 외래 키 제약 조건에 참조되어 있는 제3 시나리오에서는 삽입 연산 및 삭제 연산에 대하여 서버 측 제약 조건 예외를 초래한다.

여기서 이러한 알고리즘은 모든 시나리오에 대해 맵핑 컴파일 시에 종속성을 계산할 수 있는 한편, 런타임 인스턴스는 제2 및 제3 시나리오에 대해 순환적 참조에 대해 평가되어 우선권이 주어진다. 맵핑 구문으로부터 한 차례 계산되어진 모든 유닛에 대한 종속성 정보는 컴파일된 맵핑 내의 어레이에 저장된다. 이 맵핑은 모든 소스 유닛이 상대적인 해당 순서로 할당되어 있다. 상술한 바와 같이 제3 시나리오의 해결 불가능한 순환적 참조에서도, 맵핑 파일 내의 발생 순서로 그래프가 트리 내로 임의적으로 분리된다. 이는 관련되지 않은 유닛들 사이에도 결정론적인 실행 순서를 보장하므로, 잠재적인 교착 상태(deadlock)의 경우를 회피한다.

사상수는 일대일 및 일대다 중 하나일 수 있다. 다대다는 갱신과 관련하여 일대다와 유사한 의미론을 갖는다. "Map" 엘리먼트에 대한 "Source" 속성에 의해 특정된 소스 유닛은 스트롱 유닛(Strong Unit)이라고 하는 한편, 기본적인 "FieldMap" 엘리먼트들에서 특정된 다른 모든 소스 유닛들은 위크 유닛(Weak Unit)이라고 한다. 사상수 정보는 위크 유닛과 스트롱 유닛의 개념에 상당히 연관된다. 일대다에서는 위크 유닛이 판독 전용(Read-Only)으로 간주된다.

이러한 시나리오들에 대한 예로는, ObjectSpace의 타입 상속성에 따른 일 테이블과 복수의 테이블(Customer, CustomerInfo)에 맵핑된 Customer XML 엘리먼트(또는 클래스)가 있다. 이 경우, 스트롱 유닛 및 위크 유닛 둘 다의 동작은 기입-판독이고, 위크 유닛 행들의 존재는 스트롱 유닛 행의 존재와 결부된다. 이는, 만일 타겟 유닛이 삽입된다면, 스트롱 유닛에 한 행이 삽입될 뿐만 아니라 대응하는 모든 위크 유닛의 행들이 삽입됨을 의미한다. 마찬가지로, 타겟 유닛이 삭제된다면, 스트롱 유닛과 위크 유닛의 대응하는 모든 행들이 삭제된다. 위크 유닛에 관련된 속성을 삭제하는 것은 대응하는 컬럼들이 스트롱 유닛에 속하는지 혹은 위크 유닛에 속하는지에 관계없이 이 컬럼들의 값을 널로 만드는 것으로 번역된다. 소정의 위크 유닛에 맵핑된 모든 타겟 필드들이 삭제된다할지라도 그 위크 유닛의 행은 삭제되지 않음을 분명히 해 둘 필요가 있다. 위크 유닛으로부터의 한 행은 타겟 유닛이 삭제될 때 스트롱 유닛과는 구분될 수 있을 뿐이다. 이러한 타겟 필드 삭제 시나리오는 XML에만 존재하며, ObjectSpace에는 존재하지 않는다는 것을 유의한다. 그 이유는 클래스의 특성들이 삭제되는 것이 아니라 널로 될 뿐이기 때문이다.

FieldMap의 Ref 속성에 있어서, 복수의 소스 유닛이 FieldMap의 "Ref" 속성을 이용하여 맵핑되는 경우에, 위크 유닛에 대한 갱신 의미론은 모든 사상수에 대하여 판독 전용이다. 이는 갱신 의미론을 제어하기 위한 또 다른 맵핑이 존재한다는 것을 의미하는 "Ref" 속성 의미론에 따른 것이다. 판독 전용 의미론이란, 타겟 이 삽입되면 갱신 연산이 스트롱 유닛의 행을 삽입할 뿐이고 위크 유닛은 다루지 않는다는 것을 의미한다. 마찬가지로, 타겟이 삭제되면 스트롱 유닛의 행만이 삭제된다. 유사하게, 위크 유닛들에 관련된 속성들이 변경(갱신/삭제)되면, 갱신 엔진(CP)은 예외를 발생시킨다. 클라이언트(ObjectSpace, XmlCache 등)는 CP에 위크 유닛에 대한 변경된 변동 사항을 제공하지 않음으로써 언제나 이러한 동작을 오버라이딩할 수 있다. 변동 사항에 대한 이 방식은 예외를 초래하는 것이 아니라 무시하는 것이다.

소스 대신에 Ref 속성을 갖는 맵은 하나의 유닛으로 그룹핑되어, 메인(main) 맵에 맵핑되어 있는 타겟 스트럭처 없이 삽입 또는 삭제될 수 없다. 개념적으로, 이 맵은 메인 맵의 일부이다. 이러한 동작의 이유로는, 메인 맵이 언제나 개인 비밀 정보를 포함하는 것을 보장하고, 맵핑되는 스트럭처는 맵핑되는 스트럭처의 피상속자이어야 하며, 이로써 이 스트럭처가 해당 맵의 소유자 스트럭처(owner structure)가 될 수 있기 때문이다.

판독 전용 FieldMap에서, CP는 Read-Only FieldMap에서 맵핑되는 소스 필드들이 변경되지 않았는지를 검증하여, 이런 경우에는 에러를 발생시킨다. CustomTable의 임의의 갱신 명령의 현재 파라미터들을 판독 전용 타겟 필드에 결부시키는 것은 에러임을 유의한다.

이제 도 6a를 참조하면, 소스 데이터 소스(602)와 타겟 데이터 소스(604)의 네트워크도(600)가 도시되어 있다. 여기서, 맵핑 컴포넌트(606)는 네트워크에서 분리되어 배치된다. 소스 데이터 소스(606)와 타겟 데이터 소스(604) 둘 다는 판 독 전용이며, 맵핑을 필요로 한다. 본 발명에 따르면, 맵핑 컴포넌트(606)는 소스(602)로부터 타겟(604)으로의 맵핑을 수행하는 데 사용된다. 맵핑 컴포넌트(606)의 네트워크 위치에 있는 사용자는 맵핑 컴폰넌트(606)가 이러한 맵핑을 수행하도록 구성한다. 이는 인터넷 등의 글로벌 통신 네트워크(global communication network : GCN)(608)를 통해 이루어질 수 있다. 또한, 맵핑은 LAN, WAN, WLAN, WWAN 등일 수 있는 네트워크(608)를 통해서 이루어질 수 있다. 이러한 시나리오는 벤더에 의해 수행되는 맵핑 동작을 획득하기 위해 고객이 가입하는 구현을 용이하게 한다. 벤더는, 아마도 로그인 정보를 획득한 후에(로그인 정보가 요구되지 않을 수도 있음), 네트워크(608)를 통해 소스 및 타겟 데이터 모델들을 간단히 액세스하여, 맵핑 동작을 수행하기 위한 맵핑 컴포넌트(606)를 구성한다. 또한, 이 시나리오는 LAN, WAN 등을 통해 자신의 맵핑 동작을 수행하는 고객을 지원한다.

이제 도 6b를 참조하면, 맵핑 컴포넌트(606)가 소스 위치나 타겟 위치, 혹은 이 두 위치 모두에 배치될 수 있는 네트워크도(610)가 도시되어 있다.

이제 도 7을 참조하면, 개시되는 아키텍처를 실행하도록 동작 가능한 컴퓨터의 블럭도가 도시되어 있다. 본 발명의 다양한 양상들에 대한 추가적인 컨텍스트를 제공할 목적으로, 본 발명의 다양한 양상들이 구현될 수 있는 적절한 컴퓨팅 환경(700)의 간단하고 일반적인 설명을 제공하기 위해 도 7 및 이하의 논의가 의도되었다. 본 발명이 하나 이상의 컴퓨터에서 실행될 수 있는 컴퓨터 실행 가능 명령어(instruction)들의 일반적인 컨텍스트에서 상술되었지만, 본 기술 분야의 당업자라면, 본 발명이 하드웨어와 소프트웨어의 조합으로서 및/또는 기타 프로그램 모듈 과의 조합으로 구현될 수도 있음을 알 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 구행하거나 특정 추상 데이터 타입을 구현하는 루틴, 프로그램, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 본 기술 분야의 당업자라면, 본 발명의 방법들이 퍼스널 컴퓨터, 핸드헬드(hand-held) 컴퓨팅 디바이스, 마이크로프로세서 기반 또는 프로그램 가능 가전 제품 등 뿐만 아니라 단일 프로세서 또는 멀티프로세서 컴퓨터 시스템, 미니컴퓨터, 메인프레임 컴퓨터(이들 각각은 하나 이상의 관련 장치들에 동작 가능하게 접속될 수도 있음)를 포함한 기타 컴퓨터 시스템 구성으로 실시될 수 있음을 알 것이다. 또한, 본 발명의 예시된 양상들은, 소정의 태스크가 통신 네트워크를 통해서 링크된 원격 프로세싱 디바이스들에 의해서 수행되는 분산형 컴퓨팅 환경에서 실시될 수 있다. 분산형 컴퓨팅 환경에서는 프로그램 모듈이 로컬 메모리 저장 장치와 원격 메모리 저장 장치 둘 다에 배치될 수도 있다.

다시 도 7을 참조하면, 본 발명의 다양한 양상들을 구현하기 위한 예시적인 환경(700)이 도시되어 있다. 이 환경은 프로세싱 유닛(704), 시스템 메모리(706), 및 시스템 버스(708)를 포함하는 컴퓨터(702)를 포함한다. 시스템 버스(708)는 시스템 메모리(706)를 포함한(이에 한정되지는 않는다) 시스템 컴포넌트들을 프로세싱 유닛(704)에 접속시킨다. 프로세싱 유닛(704)은 상업적으로 입수 가능한 각종 프로세서들 중 임의의 것일 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처도 프로세싱 유닛(704)으로서 채용될 수 있다.

시스템 버스(708)는 상업적으로 입수 가능한 각종 버스 아키텍처들 중 임의 의 것을 이용한 시스템 버스나 메모리 컨트롤러, 주변 버스, 및 로컬 버스를 포함한 여러 종류의 버스 구조들 중 임의의 것일 수 있다. 시스템 메모리(706)는 ROM(read only memory)(710) 및 RAM(random access memory)(712)을 포함한다. 시동(start-up) 시와 같은 때에 컴퓨터(702) 내의 구성 요소들 간의 정보 전송을 돕는 기본 루틴을 포함하는 BIOS(basic input/output system)(710)는 ROM(710)에 저장되어 있다.

컴퓨터(702)는 하드 디스크 드라이브(714), (예컨대, 분리형 디스크(718)로부터 판독하거나, 이 디스크에 기록하기 위한) 자기 디스크 드라이브(716), 및 (예컨대, CD-ROM 디스크(722)를 판독한다거나, 기타 광학 매체로부터 판독하거나 이 매체에 기록하기 위한) 광 디스크 드라이브(720)를 더 포함한다. 하드 디스크 드라이브(714), 자기 디스크 드라이브(716), 및 광 디스크 드라이브(720)는 하드 디스크 드라이브 인터페이스(724), 자기 디스크 드라이브 인터페이스(726), 및 광학 드라이브 인터페이스(728) 각각에 의해 시스템 버스(708)에 접속될 수 있다. 드라이브들과 이에 관련된 컴퓨터 판독 가능 매체들은 데이터, 데이터 구조, 컴퓨터 실행 가능 명령어 등의 영구 저장을 제공한다. 컴퓨터(702)에 있어서, 드라이브들과 매체들은 적절한 디지털 포맷으로 방송 편성된 저장소를 수용한다. 상술한 컴퓨터 판독 가능 매체의 설명이 하드 디스크, 분리형 자기 디스크, 및 CD에 관련되어 있지만, 본 기술 분야의 당업자라면, ZIP 드라이브, 자기 카셋트, 플래쉬 메모리 카드, DVD(digital video disk), 카트릿지 등의 컴퓨터에 의해 판독될 수 있는 다른 종류의 매체들이 예시적인 동작 환경에 사용될 수도 있으며, 이와 같은 매체들 중 어떤 매체라도 가 본 발명의 발명들을 수행하기 위한 컴퓨터 실행 가능 명령어들을 포함할 수 있음을 알 것이다.

오퍼레이팅 시스템(730), 하나 이상의 애플리케이션 프로그램(732), 기타 프로그램 모듈(734), 및 프로그램 데이터(736)를 포함한 다수의 프로그램 모듈들이 드라이브와 RAM(712)에 저장될 수 있다. 본 발명은 상업적으로 입수 가능한 각종 오퍼레이팅 시스템이나 오퍼레이팅 시스템들의 조합으로 구현될 수 있음을 알 수 있다.

사용자는 마우스(740) 등의 포인팅 디바이스와 키보드(738)를 이용하여 컴퓨터(702)에 명령과 정보를 입력할 수 있다. 다른 입력 장치(도시되지 않음)로는, 마이크로폰, IR 원격 제어기, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등이 포함될 수 있다. 상기 및 기타 입력 장치들은 흔히 시스템 버스(708)에 연결되어 있는 시리얼 포트 인터페이스(742)를 통해 프로세싱 유닛(704)에 접속되지만, 병렬 포트, 게임 포트, USB(universal serial bus), IR 인터페이스 등의 다른 인터페이스들에 의해 접속될 수도 있다. 모니터(744)나 다른 종류의 디스플레이 디바이스도 비디오 어댑터(746) 등의 인터페이스를 통해서 시스템 버스(708)에 접속된다. 모니터(744) 외에도, 컴퓨터는 통상적으로 스피커, 프린터 등의 다른 주변 출력 장치(도시되지 않음)를 포함한다.

컴퓨터(702)는 원격 컴퓨터(들)(748) 등의 하나 이상의 원격 컴퓨터에의 논리적 접속로를 이용한 네트워킹 환경에서 동작할 수 있다. 원격 컴퓨터(들)(748)는 워크스테이션, 서버 컴퓨터, 라우터, 퍼스널 컴퓨터, 휴대용 컴퓨터, 마이크로 프로세서 기반의 엔터테인먼트 제품, 피어(peer) 디바이스, 또는 기타 일반적인 네크워크 노드일 수 있고, 통상적으로는 컴퓨터(702)에 관하여 상술한 엘리먼트들의 다수 혹은 전부를 포함하지만, 간결함을 위해서 메모리 저장 장치(750)만을 도시하였다. 도시된 논리적 연결로는 LAN(local area network)(752) 및 WAN(wide area network)(754)을 포함한다. 이러한 네트워킹 환경은 사무실, 기업형 컴퓨터 네트워크, 인트라넷, 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(702)는 네트워크 인터페이스 또는 어댑터(756)를 통해 LAN(752)에 접속된다. 어댑터(756)는 LAN(752)으로의 유무선 통신을 용이하게 할 수 있으며, LAN은 무선 어댑터(756)와의 통신을 위해 그 내부에 배치된 무선 접속점을 포함할 수 있다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(702)는 일반적으로 모뎀(758)을 포함하거나, LAN 상의 통신 서버에 접속하거나, 인터넷 등의 WAN(754)을 통해 통신을 구축하기 위한 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(758)은 시리얼 포트 인터페이스(742)를 통해 시스템 버스(708)에 접속된다. 네트워킹 환경에서, 컴퓨터(702)에 관하여 도시된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장치(750)에 저장될 수 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 구축하는 그 외의 수단이 사용될 수도 있음을 알 것이다.

이제 도 8을 참조하면, 본 발명에 따른 예시적인 컴퓨팅 환경(800)의 개략적인 블럭도가 도시되어 있다. 시스템(800)은 하나 이상의 클라이언트(들)(802)를 포함한다. 클라이언트(들)(802)는 하드웨어 및/또는 소프트웨어(예컨대, 스레드, 프로세스, 컴퓨팅 디바이스)일 수 있다. 클라이언트(들)(802)는 예컨대 본 발명을 채용함으로써 하우스 쿠키(house cookie)(들) 및/또는 이에 연관된 컨텍스트 정보일 수 있다. 또한, 시스템(800)은 하나 이상의 서버(들)(804)를 포함한다. 서버(들)(804)는 하드웨어 및/또는 소프트웨어(예컨대, 스레드, 프로세스, 컴퓨팅 디바이스)일 수 있다. 서버(들)(804)는 예컨대 본 발명을 채용함으로써 변환을 수행하는 하우스 스레드(house thread)일 수 있다. 클라이언트(802)와 서버(804) 간의 한 가지 가능한 통신은 둘 이상의 컴퓨터 프로세스 사이에서 전송되기에 알맞은 데이터 패킷의 형태일 수 있다. 데이터 패킷은 예컨대 쿠키 및/또는 이에 연관된 컨텍스트 정보를 포함할 수 있다. 시스템(800)은 클라이언트(들)(802)와 서버(들)(804) 간의 통신을 용이하게 하기 위해 채용될 수 있는 통신 프레임워크(806)(예컨대, 인터넷 등의 GCN)를 포함한다.

(광섬유를 포함한) 유선 및/또는 무선 기술을 통해 통신이 용이하게 될 수 있다. 클라이언트(들)(802)는 하나 이상의 클라이언트 데이터 저장소(들)(808)에 동작 가능하게 접속된다. 이 저장소는 클라이언트(들)(802)에 정보(예컨대 쿠키 및/또는 이에 연관된 컨텍스트 정보)를 로컬로 저장하도록 채용될 수 있다. 마찬가지로, 서버(들)(804)는 서버(들)(804)에 정보를 로컬로 저장하도록 채용될 수 있는 하나 이상의 서버 데이터 저장소(들)(810)에 동작 가능하게 접속된다.

이제 도 9를 참조하면, 본 발명에 따른 데이지 체인(daisy-chain) 맵핑 구현의 블럭도가 도시되어 있다. 개시되는 신규한 맵핑 아키텍처는 데이지 체인 맵핑 시나리오의 구현을 용이하게 한다. 이 시나리오에서, 도 1의 시스템(100)에 유사 한 복수의 스테이지(stage)들(900)은, 궁극적으로 타겟 데이터 모델 T_N(목적지)에 소정의 데이터 포맷을 제공하는 데 필요한 중간 데이터 변환을 수행하기 위한 임의의 개수의 중간 스테이지를 포함하여, (임의의 스트럭처의) 소스 데이터 모델 S₁으로부터 (임의의 스트럭처의) 타겟 데이터 모델 T_N까지 직렬 형상으로 구성될 수 있다. 이 컨텍스트에서의 스테이지(900)는 소스 모델 S, 맵핑 컴포넌트 M, 및 타겟 데이터 모델 T를 포함하는 것으로 나타나 있다. 또한, 복수의 스테이지(900)를 갖는 데이지 체인에서, 중간 타겟 데이터 모델 T는 후속하는 스테이지(902)에 대해서는 데이터 소스 S2이다. 따라서, 중간 데이터 모델(예컨대, T1/S2)은, 이전의 스테이지(902)의 맵핑 컴포넌트 M1의 타겟인 T1, 및 후속 스테이지(902)의 후속 맵핑 컴포넌트 M2의 소스인 S2의 2개의 부호가 부여되어 있따.

데이터 모델들은 질의 언어, 데이터 액세스 언어, 데이터 조작 언어, 데이터 정의 언어, 오브젝트 모델, 관계형 모델, 및 XML 모델을 포함할 수 있지만, 이에 한정되지는 않는다.

일례에 있어서, 목표는 소스 데이터 모델 S1으로부터 타겟 데이터 모델 T2로 데이터를 맵핑하는 것이다. 소스 S1이 관계형 데이터 스트럭처이고, 타겟 T2가 XML 데이터 스트럭처라고 상정한다. 또한, 소스 S1으로부터 타겟 T2로의 경로가 오브젝트 기반의 경로만을 제공한다고 상정한다. 제1 스테이지 맵핑 컴포넌트 M1은 소스 S1에 대한 적절한 관계형 기술 컴포넌트 및 타겟 T1에 대한 오브젝트 기술 컴포넌트를 사용하여, 소스 S1을 중간 타겟 T1에 맵핑시킨다. 다음으로, 중간 타 겟 T1은 맵핑 컴포넌트 M2에 대한 소스 S2가 아니다. 그래서, 맵핑 컴포넌트 M2는 적절한 오브젝트 기술 컴포넌트 및 XML 기술 컴포넌트를 사용하여, 소스 S2로부터 타겟 T2로의 맵핑을 완료한다.

이러한 특성에서 볼 때, 특정 애플리케이션에 따라 임의의 개수의 스테이지들(900 및 902)가 채용될 수 있음을 알 것이다.

이제 도 10을 참조하면, 본 발명의 맵핑 아키텍처의 허브 앤 스포크(hub and spoke) 구현이 도시되어 있다. 이 구현은, 데이터 경로의 유용성이 임의의 시점에서 네트워크 장애, 이용 가능한 대역폭 등으로부터 영향을 받는, 예컨대 인터넷이나 대기업 네트워크 등의 광역 네트워크 환경에 특히 유용하다. 임의의 개수의 데이터 소스 S1, S2, 및 S3 - 데이터가 이들로부터 및/또는 이들을 통해서 이동되거나, 질의됨 - 및 (T/S라고 도시된) 임의의 개수의 데이터 타겟들(1008)과 통신하는 중앙 제어 엔티티(1000)가 제공된다. 궁극적으로는, 맵핑은 소스 S1, S2, 및 S3 중 하나로부터 타겟 T2로인 것으로 함이 바람직할 수 있다.

중앙 제어 엔티티(1000)는 엔티티의 모든 양상들을 제어하기 위한 제어 컴포넌트(1002) - 이 컴포넌트는 데이터를 한 타입의 데이터 모델로부터 다른 타입의 데이터 모델(예컨대, 관계형, 오브젝트, XML, …)로 변환하기 위한 다수의 액세스 가능한 기술 알고리즘을 저장하는 기술 컴포넌트 리소스(1004)를 포함함 - 및 소스 S1, S2, 및 S3와 중간 타겟(1008) 사이에서 데이터를 라우팅하거나 스위칭하기 위한 스위칭 메커니즘(1006)을 포함한다.

동작 시에는 예를 들어 제1 중간 데이터소스 타겟(1010)으로부터 소스 S1으 로의 데이터 질의가 개시된다. 소스 S1의 데이터 스트럭처는 관계형이고, 타겟(1010)의 데이터 스트럭처는 XML이다. 타겟(1010)으로부터 소스 S1으로의 질의는 제어 컴포넌트(1002)에 변환 정보를 제공함으로써, 맵핑을 완료하는 데 사용하기 위한 적절한 관계형 대 XML 맵핑 알고리즘이 리소스(1004)로부터 검색 및/또는 생성될 수 있게 한다. 그러면, 맵핑 기능이 엔티티(1000)의 일부를 이룬다.

한 데이터 모델에 대한 맵핑 요구(질의 또는 갱신)가 하나 이상의 다른 데이터 모델로의 요구로 번역될 수 있는 보다 확장된 예에서는, 질의가 타겟 T2로부터 중간 타겟/소스들 중 임의의 하나(1008)를 통해서 소스 S1으로 개시되는 경우, 엔티티(1000)는 중간 데이터소스(1008)를 경유하는 가장 최적의 경로를 선택할 수 있다. 예를 들어, 소스 S1이 관계형이고, 타겟 T2는 XML이며, 제1 중간 데이터소스(1010)는 오브젝트 기반형이고, 제2 중간 데이터소스(1012)는 관계형 기반형이며, 제3 중간 데이터소스(1014)는 XML 기반형이면, 엔티티(1000)는 소스 S1으로부터 제2 중간 데이터소스(1012)를 통해서 타겟 T2로 이동하는 가장 최적의 경로를 정할 수 있다. 일단 이러한 결정이 정해지면, 제어 컴포넌트(1002)는 소스 S1으로부터 중간 데이터소스(1012)로의 관계형 대 관계형 맵핑을 채용한다. 이로써, 제2 제어 엔티티(1016)의 맵핑 컴포넌트(제어 엔티티(1000)와 유사함)는 제2 중간 데이터소스(1012)로부터 타겟 T2로의 관계형 대 XML 맵핑을 채용한다. 제어 엔티티들(1000 및 1016)은 이 데이터소스를 경유하여 타겟 T2로 이동하는 통신 경로들 중 임의의 하나로부터 경로 선택을 조정한 링크(1018)를 통해서 통신할 수 있다.

상술한 바와 같이, 데이터소스들 간의 맵핑은 데이터 스트럭처들, 예컨대 관 계형 대 관계형, XML 대 XML 등과 유사할 수 있다. 즉, 소스 관계형 데이터베이스가 다른 관계형 스트럭처를 갖는 타겟 관계형 데이터베이스에 맵핑될 수 있는 시나리오가 존재할 수 있다. 마찬가지로, 소스 오브젝트 데이터가 다른 오브젝트 스트럭처를 갖는 타겟 오브젝트 데이터 모델에 맵핑될 수 있는 시나리오가 존재할 수 있다. 또한, 소스 XML 데이터가 다른 XML 스트럭처를 갖는 타겟 XML 데이터 모델에 맵핑될 수 있는 시나리오가 존재할 수 있다.

이제 도 11을 참조하면, 본 발명의 일 양상에 따른 중첩 가능 스트럭처(1100)가 도시되어 있다. 이 기능은 도 10의 네트워크 구현에 채용되어 있다. 맵핑 프레임워크는, 사용자가 임의의 두 데이터 모델들 간의 데이터 프로세싱을 구현할 수 있도록 하기 위해, 적절한 포맷들의 셋트, API, 최적화기, 유틸리티, 및 툴을 제공한다. 누구든지 자신의 질의를 어떤 다른 데이터 소스들에 대해서도 자동으로 실행할 수 있는 QIL(query independent language) 컴파일러로 구현할 수 있다. QIL은 데이터소스에의 질의(또는 갱신)에 대한 범용 데이터소스 독립형 표현이다. 맵핑에 의하면, 이러한 기능이, 한 데이터 모델에 대해 이루어진 요구(질의 또는 갱신)가 다른 데이터 모델로의 요구로 번역될 수 있게 한다.

도시된 API들은 관계형(1102), XML(1104), 오브젝트(1106), 및 기타형(1108)를 포함한다. 따라서, 질의는 실행될 맵핑의 수개의 층들(1110, 1112, 및 1114)을 통해 이동될 수 있으므로, 리턴되기 전에 수차례 재맵핑될 수 있다. 맵핑과 QIL은 구성 가능하다. 맵핑은 양방향적 즉, 가역적이므로, 당연히 갱신이 이행될 수 있다.

이상의 설명에서는 본 발명의 실시예들을 포함한다. 당연히, 본 발명을 설명하기 위한 생각할 수 있는 모든 구성 요소들 또는 방법론들의 조합을 기술할 수는 없다. 그러나, 본 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 또 다른 많은 조합과 치환이 가능하다는 것을 알 것이다. 따라서, 본 발명은 이하의 특허청구범위의 사상 및 범주 내에 있는 한 이러한 모든 대체, 변경, 및 변형을 포함하도록 의도된 것이다.

본 발명에 따르면, 2 이상의 데이터 소스가 그 자체의 메타데이터나 스트럭처를 변경하지 않으면서도 서로에게 맵핑되어야 할 시나리오를 지원하도록 설계된 맵핑 포맷이 제공되며, 맵핑의 여러 단계들이 소스로부터 타겟까지 발생할 수 있는 중첩 가능한 맵핑 아키텍처가 제공된다.

Claims (55)

1. 임의의 데이터 모델들을 맵핑(mapping)하는 것을 용이하게 하는 시스템을 구현하기 위한 컴퓨터 프로그램을 기록한 컴퓨터 판독가능 기록 매체로서,

   상기 시스템은,

   적어도 2개의 임의의 데이터 모델로부터 개개의 메타데이터를 수신하고, 상기 데이터 모델들 간의 관계(relationship), 스트럭처(structure) 및 필드 중 적어도 하나를 포함하는 표현식(expression)들을 맵핑시키는 맵핑 컴포넌트

   를 포함하며,

   상기 맵핑 컴포넌트가 수행하는 상기 데이터 모델들 간의 맵핑은 지향적이고(directional), 상기 데이터 모델들은 소스 도메인 및 타겟 도메인을 포함하며, 상기 맵핑의 지향성은 상기 소스 도메인 및 상기 타겟 도메인의 데이터 모델들을 포함하는 상기 임의의 데이터 모델들 각각에 대한 맵핑 구현 및 의미론에 영향을 끼쳐서 소스로서 맵핑된 모델들이 타겟으로서 맵핑된 모델들과는 다른 하나 이상의 특성들을 갖게 하고, 상기 타겟 도메인은 단 한번만 맵핑될 수 있는 스트럭처 및 필드를 포함하는 반면에 상기 소스 도메인은 복수회 맵핑될 수 있는 스트럭처 및 필드를 포함하고, 상기 데이터 모델들 간의 맵핑은 중첩가능(stackable)하여서, 상기 소스 도메인으로부터 상기 타겟 도메인으로의 맵핑들의 복수 개 스테이지들이 발생하게 되고, 중첩가능한 맵핑은 사용자로 하여금 임의의 데이터 모델들 중 임의의 2개의 데이터 모델 간의 데이터 프로세싱을 구현할 수 있게 하고,

   상기 맵핑 컴포넌트는 사용자로 하여금 상기 타겟 도메인의 질의 언어(query language)를 통해 상기 데이터 모델들을 조작할 수 있게 하고, 상기 타겟 도메인 또는 상기 소스 도메인으로의 맵핑과 조합하여 다른 언어의 이용을 제공하고,

   상기 데이터 모델들 간의 맵핑은 상기 타겟 도메인의 질의 언어로 작성된 질의를 상기 소스 도메인의 질의 언어로 번역하고,

   상기 맵핑 컴포넌트는 갱신을 자동으로 동기화하는 것을 용이하게 하고, 상기 갱신은 질의, 갱신, 삽입 또는 삭제 명령이 상기 맵핑에 기초하여 호출될 때에 실행될 사용자-지정된 스트럭처의 질의 언어 문장을 포함함으로써 상기 사용자로 하여금 상기 맵핑에 대해 상이한 행동을 지정할 수 있게 하고, 사용자가 상기 타겟 도메인 내 스트럭처를 생성, 삭제, 또는 변경할 때에 이러한 변화들이 상기 소스 도메인에 자동으로 보유되는, 컴퓨터 판독가능 기록 매체.
2. 제1항에 있어서,

   상기 데이터 모델들은 적어도 하나의 오브젝트 모델 및 적어도 하나의 관계형 모델(relational model)을 포함하고, 상기 오브젝트 모델은 상기 관계형 모델들 중 적어도 하나에 맵핑되는 컴퓨터 판독가능 기록 매체.
3. 제1항에 있어서,

   상기 데이터 모델들은 오브젝트 모델들을 포함하고, 상기 오브젝트 모델들 중 하나는 다른 오브젝트 모델들 중 적어도 하나에 맵핑되는 컴퓨터 판독가능 기록 매체.
4. 제1항에 있어서,

   상기 맵핑 컴포넌트는 상기 메타데이터로부터 도출된 토폴로지(topology) 데이터를 수신하는 컴퓨터 판독가능 기록 매체.
5. 제1항에 있어서,

   상기 맵핑 컴포넌트는, 계층구조(hierarchy)를 생성 또는 폐기하는 것과, 속성(attribute)들을 하나의 엘리먼트(element)로부터 다른 엘리먼트로 이동시키는 것과, 새로운 관계들을 도입하는 것 중 적어도 하나에 의해서, 데이터 모델의 데이터에 대한 스트럭처상의 변환(structural transformation)을 생성하는 컴퓨터 판독가능 기록 매체.
6. 임의의 데이터 모델들을 맵핑하는 것을 용이하게 하는 시스템을 구현하기 위한 컴퓨터 프로그램을 기록한 컴퓨터 판독가능 기록 매체로서,

   상기 시스템은,

   소스 데이터 소스의 소스 개념을 나타내는 소스 메타데이터;

   적어도 하나의 타겟 데이터 소스의 타겟 개념을 나타내는 타겟 메타데이터; 및

   상기 소스 메타데이터 및 상기 타겟 메타데이터를 수신하고 상기 소스 데이터 소스로부터의 상기 개념을, 하나 이상의 상기 타겟 데이터 소스와 관련된 상기 타겟 메타데이터로 맵핑하는 맵핑 컴포넌트

   를 포함하며,

   상기 데이터 모델들은 상기 데이터 모델들 자체의 상기 메타데이터 또는 스트럭처를 변경하지 않고 맵핑되며,

   상기 소스 데이터 소스 간의 상기 개념들을 상기 타겟 데이터 소스에 맵핑하는 것은 지향적이며(directional), 상기 데이터 모델들 간의 맵핑은 중첩 가능하여, 소스 도메인으로부터 타겟 도메인으로의 맵핑의 복수의 스테이지가 발생하며, 중첩가능한 맵핑은 사용자로 하여금 임의의 데이터 모델들 중 임의의 2개의 데이터 모델 간의 데이터 프로세싱을 구현할 수 있게 하고, 상기 맵핑의 지향성은 상기 소스 도메인 및 상기 타겟 도메인의 데이터 모델들을 포함하는 상기 임의의 데이터 모델들 각각에 대한 맵핑 구현 및 의미론에 영향을 끼쳐서 소스로서 맵핑된 모델들이 타겟으로서 맵핑된 모델들과는 다른 하나 이상의 특성들을 갖게 하고, 상기 타겟 도메인은 단 한번만 맵핑될 수 있는 스트럭처 및 필드를 포함하는 반면에 상기 소스 도메인은 복수회 맵핑될 수 있는 스트럭처 및 필드를 포함하고,

   상기 맵핑 컴포넌트는 사용자로 하여금 상기 타겟 데이터 소스의 질의 언어를 통해 상기 소스 데이터 소스 및 상기 타겟 데이터 소스를 조작할 수 있게 하고,

   상기 맵핑 컴포넌트는 갱신을 자동으로 동기화하는 것을 용이하게 하고, 상기 갱신은 질의, 갱신, 삽입 또는 삭제 명령이 상기 맵핑에 기초하여 호출될 때에 실행될 사용자-지정된 스트럭처의 질의 언어 문장을 포함함으로써 상기 사용자로 하여금 상기 맵핑에 대해 상이한 행동을 지정할 수 있게 하고, 사용자가 상기 타겟 도메인 내의 스트럭처를 생성, 삭제, 또는 변경할 때에 이러한 변화들이 상기 소스 도메인에 자동으로 보유되는, 컴퓨터 판독가능 기록 매체.
7. 제6항에 있어서,

   맵핑되는 개념은 동일한 것, 상이한 것, 동일한 것과 상이한 것의 조합 중 적어도 하나인 컴퓨터 판독가능 기록 매체.
8. 제6항에 있어서,

   상기 소스 개념 및 상기 타겟 개념은, 동일한 데이터 소스 내의 2개의 스트럭처 간의 링크(link) 및 연관성(association)인 관계 엘리먼트를 포함하는 컴퓨터 판독가능 기록 매체.
9. 데이터 모델들 간에 데이터를 맵핑하는 컴퓨터 구현 방법으로서,

   맵핑 컴포넌트에 의해 수행되는 컴퓨터 실행가능 단계들을 포함하며,

   상기 컴퓨터 실행가능 단계들은,

   적어도 2개의 임의의 데이터 모델로부터 개개의 메타데이터를 수신하는 단계;

   상기 메타데이터에 기초하여 상기 데이터 모델들 중 적어도 2개의 데이터 모델 간에 스트럭처, 필드 및 관계(relationship) 중 적어도 하나를 포함하는 표현식들을 맵핑하는 단계 - 상기 표현식들은 상기 데이터 모델들 간에 지향적으로(directionally) 맵핑되고, 상기 맵핑의 지향성은 소스 도메인 및 타겟 도메인의 데이터 모델들을 포함하는 상기 임의의 데이터 모델들 각각에 대한 맵핑 구현 및 의미론에 영향을 끼쳐서 소스로서 맵핑된 모델들이 타겟으로서 맵핑된 모델들과는 다른 하나 이상의 특성들을 갖게 하고, 상기 타겟 도메인은 단 한번만 맵핑될 수 있는 스트럭처 및 필드를 포함하는 반면에 상기 소스 도메인은 복수회 맵핑될 수 있는 스트럭처 및 필드를 포함함 -;

   상기 지향적인 맵핑을 통해 상기 데이터 모델들로부터 소스 도메인 및 타겟 도메인을 생성하는 단계;

   상기 소스 도메인으로부터 상기 타겟 도메인으로의 맵핑의 복수의 스테이지들을 중첩시키는 단계 - 중첩 가능한 맵핑은 사용자로 하여금 임의의 데이터 모델들 중 임의의 2개의 데이터 모델 간의 데이터 프로세싱을 구현할 수 있게 함 -;

   사용자로 하여금 상기 타겟 도메인의 질의 언어를 통해 상기 데이터 모델들을 조작할 수 있게 하는 단계;

   상기 타겟 도메인의 질의 언어로 작성된 질의를 상기 소스 도메인의 질의 언어로 번역하는 단계;

   갱신을 자동으로 동기화하고, 상기 소스 도메인에 변화들을 보유하는 단계 - 상기 갱신은 질의, 갱신, 삽입 또는 삭제 명령이 상기 맵핑에 기초하여 호출될 때에 실행될 사용자-지정된 스트럭처의 질의 언어 문장을 포함함으로써 상기 사용자로 하여금 상기 맵핑에 대해 상이한 행동을 지정할 수 있게 함 -; 및

   함수를 이용하여 소스 데이터 모델을 타겟 데이터 모델로 맵핑시킬 동안에 데이터를 변환하는 단계

   를 포함하는 컴퓨터 구현 방법.
10. 제9항에 있어서,

    상기 2개의 데이터 모델 간에 맵핑되는 상기 표현식들은 동일한 표현식인 컴퓨터 구현 방법.
11. 임의의 데이터 모델들을 맵핑하는 컴퓨터 구현 방법으로서,

    맵핑 컴포넌트에 의해 수행되는 컴퓨터 실행가능 단계들을 포함하며,

    상기 컴퓨터 실행가능 단계들은,

    소스 데이터 소스의 소스 개념을 나타내는 소스 메타데이터 및 타겟 데이터 소스의 타겟 개념을 나타내는 타겟 메타데이터를 수신하는 단계;

    상기 소스 메타데이터 및 상기 타겟 메타데이터에 기초하여 상기 소스 데이터 소스와 상기 타겟 데이터 소스 간에 상기 개념들을 지향적으로 맵핑하는 단계 - 상기 맵핑의 지향성은 소스 도메인 및 타겟 도메인의 데이터 모델들을 포함하는 임의의 데이터 모델들 각각에 대한 맵핑 구현 및 의미론에 영향을 끼쳐서 소스로서 맵핑된 모델들이 타겟으로서 맵핑된 모델들과는 다른 하나 이상의 특성들을 갖게 하고, 상기 타겟 도메인은 단 한번만 맵핑될 수 있는 스트럭처 및 필드를 포함하는 반면에 상기 소스 도메인은 복수회 맵핑될 수 있는 스트럭처 및 필드를 포함함 -;

    상기 소스 도메인으로부터 상기 타겟 도메인으로의 맵핑의 복수의 스테이지를 중첩시키는 단계 - 중첩 가능한 맵핑은 사용자로 하여금 임의의 데이터 모델들 중 임의의 2개의 데이터 모델 간의 데이터 프로세싱을 구현할 수 있게 함 -;

    상기 데이터 모델들 자체의 상기 메타데이터 또는 스트럭처를 변경하지 않고 상기 데이터 모델들을 맵핑하는 단계;

    사용자로 하여금 상기 타겟 데이터 소스의 질의 언어를 통해 상기 소스 데이터 소스 및 상기 타겟 데이터 소스를 조작할 수 있게 하는 단계;

    갱신을 자동으로 동기화하고, 상기 소스 도메인에 변화를 보유하는 단계 - 상기 갱신은 질의, 갱신, 삽입 또는 삭제 명령이 상기 맵핑에 기초하여 호출될 때에 실행될 사용자-지정된 스트럭처의 질의 언어 문장을 포함함으로써 상기 사용자로 하여금 상기 맵핑에 대해 상이한 행동을 지정할 수 있게 함 -; 및

    상기 소스와 상기 타겟 간의 맵핑을 위한 최적 경로를 선택하는 단계

    를 포함하는 컴퓨터 구현 방법.
12. 제11항에 있어서,

    상기 데이터 소스들은 동일한 스트럭처로 된 컴퓨터 구현 방법.
13. 제11항에 있어서,

    소스 도메인에서 변수(variable)를 생성하는 단계;

    상기 변수를 조건(condition)에 의해 제한하는 단계; 및

    상기 변수를 상기 타겟 개념에 맵핑시키는 단계

    를 더 포함하는 컴퓨터 구현 방법.
14. 제11항에 있어서,

    복수의 데이터 소스와 복수의 데이터 타겟 간의 최적 경로를 선택하는 것에 응답하여, 맵핑 알고리즘을 액세스하는 단계

    를 더 포함하는 컴퓨터 구현 방법.
15. 임의의 데이터 모델들을 맵핑하는 것을 용이하게 하는 시스템을 구현하기 위한 컴퓨터 프로그램을 기록한 컴퓨터 판독가능 기록 매체로서,

    상기 시스템은,

    소스 데이터 소스의 소스 개념을 나타내는 소스 메타데이터 및 타겟 데이터 소스의 타겟 개념을 나타내는 타겟 메타데이터를 수신하는 수단;

    상기 소스 메타데이터 및 상기 타겟 메타데이터에 기초하여 상기 소스 데이터 소스와 상기 타겟 데이터 소스 간에 상기 개념들을 맵핑하는 수단 - 상기 데이터 모델들 간의 상기 맵핑은 중첩가능하고 지향적이어서, 소스 도메인으로부터 타겟 도메인으로의 맵핑의 복수의 스테이지가 발생하며, 중첩가능한 맵핑은 사용자로 하여금 임의의 데이터 모델들 중 임의의 2개의 데이터 모델 간의 데이터 프로세싱을 구현할 수 있게 하고, 상기 맵핑의 지향성은 상기 소스 도메인 및 상기 타겟 도메인의 데이터 모델들을 포함하는 상기 임의의 데이터 모델들 각각에 대한 맵핑 구현 및 의미론에 영향을 끼쳐서 소스로서 맵핑된 모델들이 타겟으로서 맵핑된 모델들과는 다른 하나 이상의 특성들을 갖게 하고, 상기 타겟 도메인은 단 한번만 맵핑될 수 있는 스트럭처 및 필드를 포함하는 반면에 상기 소스 도메인은 복수회 맵핑될 수 있는 스트럭처 및 필드를 포함함 -;

    상기 데이터 소스들 자체의 상기 메타데이터 또는 스트럭처를 변경하지 않고 상기 소스 데이터 소스 및 상기 타겟 데이터 소스를 맵핑하는 수단;

    사용자로 하여금 상기 타겟 데이터 소스의 질의 언어를 통해 상기 소스 데이터 소스 및 상기 타겟 데이터 소스를 조작할 수 있게 하는 수단;

    상기 타겟 데이터 소스의 질의 언어로 작성된 질의를 상기 소스 데이터 소스의 질의 언어로 번역하는 수단; 및

    갱신을 자동으로 동기화하고, 상기 소스 도메인에 변화들을 보유하는 수단 - 상기 갱신은 질의, 갱신, 삽입 또는 삭제 명령이 상기 맵핑에 기초하여 호출될 때에 실행될 사용자-지정된 스트럭처의 질의 언어 문장을 포함함으로써 상기 사용자로 하여금 상기 맵핑에 대해 상이한 행동을 지정할 수 있게 함 -;

    을 포함하는 컴퓨터 판독가능 기록 매체.
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제
45. 삭제
46. 삭제
47. 삭제
48. 삭제
49. 삭제
50. 삭제
51. 삭제
52. 삭제
53. 삭제
54. 삭제
55. 삭제

Images