스키마 컴포지션 기본 사항
작성 대상:
- 개발자
XDM(Experience Data Model) 스키마와 Adobe Experience Platform에서 스키마를 구성하기 위한 빌딩 블록, 원칙 및 모범 사례에 대해 알아봅니다. XDM 및 Experience Platform 내에서 XDM을 사용하는 방법에 대한 일반 정보는 XDM 시스템 개요를 참조하십시오.
스키마 이해하기
스키마는 데이터의 구조와 형식을 나타내고 유효성을 검사하는 규칙 세트입니다. 스키마는 높은 수준에서 실제 개체(예: 사람)에 대한 추상적인 정의를 제공하고, 해당 개체의 각 인스턴스에 포함되어야 하는 데이터(예: 이름, 성, 생일 등)에 대한 개요를 제공합니다.
데이터 구조를 설명하는 것 외에도 스키마는 데이터에 제약 조건과 기대를 적용하여 시스템 간에 이동할 때 유효성을 검사할 수 있습니다. 이러한 표준 정의를 사용하면 출처에 관계없이 데이터를 일관되게 해석할 수 있으며 애플리케이션 간에 번역할 필요가 없습니다.
Experience Platform은 스키마를 사용하여 이 의미 체계 표준화를 유지합니다. 스키마는 Experience Platform에서 데이터를 설명하는 표준 방식입니다.스키마를 따르는 모든 데이터를 조직 전체에서 충돌 없이 재사용하거나 여러 조직에서 공유할 수 있습니다.
XDM 스키마는 대량의 복잡한 데이터를 자체 포함 형식으로 저장하는 데 이상적입니다. XDM이 이 작업을 수행하는 방법에 대한 자세한 내용은 이 문서 부록의 포함된 개체 및 빅 데이터에 대한 섹션을 참조하십시오.
Experience Platform의 스키마 기반 워크플로
표준화는 Experience Platform 뒤의 핵심 개념입니다. Adobe을 기반으로 하는 XDM은 고객 경험 데이터를 표준화하고 고객 경험 관리를 위한 표준 스키마를 정의하는 작업입니다.
Experience Platform이 빌드된 인프라(XDM System)는 스키마 기반 워크플로를 용이하게 하며 Schema Registry, Schema Editor, 스키마 메타데이터 및 서비스 사용 패턴을 포함합니다. 자세한 내용은 XDM 시스템 개요를 참조하십시오.
Experience Platform에서 스키마를 사용하면 몇 가지 주요 이점이 있습니다. 첫째, 스키마를 사용하면 데이터 거버넌스 및 데이터 최소화를 개선할 수 있으며, 이는 개인정보 보호 규정과 함께 특히 중요합니다. 둘째, Adobe의 표준 구성 요소를 사용하여 스키마를 구축하면 최소한의 맞춤화로 즉시 통찰력을 얻고 AI/ML 서비스를 사용할 수 있습니다. 마지막으로, 스키마는 데이터 공유 통찰력과 효율적인 오케스트레이션을 위한 인프라를 제공합니다.
스키마 계획
스키마를 구축하는 첫 번째 단계는 스키마 내에서 캡처하려는 개념 또는 실제 객체를 결정하는 것입니다. 설명하려는 개념을 식별하면 데이터 유형, 잠재적 ID 필드 및 향후 스키마가 어떻게 발전할 수 있는지 고려하여 스키마 계획을 시작합니다.
Experience Platform의 데이터 동작
Experience Platform에서 사용하기 위한 데이터는 다음 두 가지 동작 유형으로 그룹화됩니다.
- 레코드 데이터: 제목의 특성에 대한 정보를 제공합니다. 주제는 조직 또는 개인일 수 있습니다.
- 시계열 데이터: 레코드 주체가 직접 또는 간접적으로 작업을 수행한 시간에 시스템의 스냅숏을 제공합니다.
모든 XDM 스키마는 레코드 또는 시계열로 분류할 수 있는 데이터를 설명합니다. 스키마의 데이터 비헤이비어는 스키마가 처음 생성될 때 스키마에 할당된 스키마의 클래스에 의해 정의됩니다. XDM 클래스는 이 문서의 뒷부분에서 자세히 설명합니다.
레코드와 시계열 스키마 모두에 ID 맵(xdm:identityMap)이 포함되어 있습니다. 이 필드에는 다음 섹션에 설명된 대로 "ID"로 표시된 필드에서 가져온 주체의 ID 표현이 포함되어 있습니다.
ID
스키마는 Experience Platform으로 데이터를 수집하는 데 사용됩니다. 이 데이터는 여러 서비스에 걸쳐 개별 엔터티의 단일 통합 보기를 만드는 데 사용할 수 있습니다. 따라서 고객 ID용 스키마를 디자인할 때는 데이터의 출처와 관계없이 주제를 식별하는 데 사용할 수 있는 필드를 고려하는 것이 중요합니다.
이 프로세스를 지원하기 위해 스키마 내의 키 필드를 ID로 표시할 수 있습니다. 데이터를 수집하면 해당 필드의 데이터가 해당 개인의 "ID 그래프"에 삽입됩니다. 그런 다음 Real-Time Customer Profile 및 기타 Experience Platform 서비스에서 그래프 데이터에 액세스하여 각 개별 고객에 대한 결합 보기를 제공할 수 있습니다.
일반적으로 "ID"(으)로 표시되는 필드에는 전자 메일 주소, 전화 번호, Experience Cloud ID (ECID), CRM ID 또는 기타 고유 ID 필드가 포함됩니다. 조직에 고유한 식별자를 고려하십시오. 이러한 식별자는 좋은 "ID" 필드일 수도 있습니다.
가능한 한 가장 강력한 프로필을 구축하기 위해 데이터를 통합하는 데 도움이 되는 스키마 계획 단계 동안 고객 ID에 대해 고려하는 것이 중요합니다. ID 정보를 통해 디지털 환경을 고객에게 제공하는 방법에 대한 자세한 내용은 ID 서비스 개요를 참조하세요. 스키마를 만들 때 ID 사용에 대한 팁은 데이터 모델링 모범 사례 문서를 참조하십시오.
ID 데이터를 Experience Platform으로 전송하는 방법에는 두 가지가 있습니다.
- 스키마 편집기 UI를 통해 또는 스키마 레지스트리 API를 사용하여 ID 설명자를 개별 필드에 추가하는 중
identityMap필드 사용
identityMap
identityMap은(는) 연결된 네임스페이스와 함께 개인의 다양한 id 값을 설명하는 맵 형식 필드입니다. 이 필드는 스키마 자체의 구조 내에서 ID 값을 정의하는 대신 스키마에 ID 정보를 제공하는 데 사용할 수 있습니다.
identityMap을(를) 사용할 때 발생하는 주요 단점은 ID가 데이터에 임베드되고 그 결과 더 이상 표시되지 않는다는 것입니다. 원시 데이터를 수집하는 경우 실제 스키마 구조 내에서 개별 ID 필드를 대신 정의해야 합니다.
NOTEidentityMap을(를) 사용하는 스키마는 관계에서 소스 스키마로 사용할 수 있지만 참조 스키마로 사용할 수는 없습니다. 모든 참조 스키마에는 소스 스키마 내의 참조 필드에 매핑될 수 있는 표시 ID가 있어야 하기 때문입니다. 소스 및 참조 스키마의 요구 사항에 대한 자세한 내용은 관계의 UI 안내서를 참조하십시오.그러나 스키마에 대한 ID가 여러 개 있거나 ID를 함께 저장하는 소스(예: Airship 또는 Adobe Audience Manager)에서 데이터를 가져오는 경우 ID 맵이 유용할 수 있습니다. 또한 Adobe Experience Platform Mobile SDK를 사용하는 경우 ID 맵이 필요합니다.
간단한 ID 맵의 예는 다음과 같습니다.
"identityMap": {
"email": [
{
"id": "jsmith@example.com",
"primary": true
}
],
"ECID": [
{
"id": "87098882279810196101440938110216748923",
"primary": false
},
{
"id": "55019962992006103186215643814973128178",
"primary": false
}
],
"CRMID": [
{
"id": "2e33192000007456-0365c00000000000",
"primary": false
}
]
}
위의 예에서 보듯이 identityMap 개체의 각 키는 ID 네임스페이스를 나타냅니다. 각 키의 값은 각 네임스페이스의 ID 값(id)을 나타내는 개체 배열입니다. Adobe 애플리케이션에서 인식하는 표준 ID 네임스페이스 목록에 대해서는 Identity Service 설명서를 참조하십시오.
NOTEprimary)인지 여부에 대한 부울 값을 각 ID 값에 제공할 수도 있습니다. Real-Time Customer Profile에서 사용할 스키마에 대한 기본 ID만 설정하면 됩니다. 자세한 내용은 유니온 스키마의 섹션을 참조하십시오.스키마 진화 원칙
디지털 경험의 특성이 계속 발전함에 따라 이를 나타내는 데 사용되는 스키마도 진화해야 합니다. 따라서 잘 설계된 스키마는 이전 버전의 스키마에 파괴적인 변경 없이 필요에 따라 조정 및 발전할 수 있습니다.
이전 버전과의 호환성을 유지하는 것은 스키마 진화에 중요하므로, Experience Platform에서는 완전히 부가적인 버전 관리 원칙을 적용합니다. 이 원칙은 스키마에 대한 모든 수정 사항이 비파괴적인 업데이트 및 변경만 발생하도록 보장합니다. 즉, 변경 내용 중단이 지원되지 않습니다.
NOTE다음 표는 스키마, 필드 그룹 및 데이터 유형을 편집할 때 지원되는 변경 사항을 분류합니다.
- 리소스에 새 필드 추가
- 필수 필드를 선택 사항으로 설정
- 새로운 필수 필드 소개*
- 리소스의 표시 이름 및 설명 변경
- 프로필에 참여할 스키마 활성화
- 이전에 정의한 필드 제거
- 기존 필드 이름 변경 또는 재정의
- 이전에 지원되는 필드 값 제거 또는 제한
- 기존 필드를 트리의 다른 위치로 이동
- 스키마 삭제
- 프로필에 참여하지 못하도록 스키마 비활성화
*아래 섹션을 참조하여 새 필수 필드 설정에 대한 중요 고려 사항을 확인하십시오.
필수 필드
개별 스키마 필드는 필요에 따라 표시할 수 있습니다. 즉, 수집된 모든 레코드에는 유효성 검사를 통과하기 위해 해당 필드의 데이터가 포함되어야 합니다. 예를 들어, 스키마의 기본 ID 필드를 필요에 따라 설정하면 수집된 모든 레코드가 실시간 고객 프로필에 참여하게 될 수 있습니다. 마찬가지로 타임스탬프 필드를 필요에 따라 설정하면 모든 시계열 이벤트가 시간순으로 보존됩니다.
IMPORTANTnull 또는 빈 값을 허용하지 않습니다. 레코드나 이벤트에 특정 필드에 대한 값이 없는 경우 해당 필드의 키를 수집 페이로드에서 제외해야 합니다.수집 후 필요에 따라 필드 설정
필드가 데이터를 수집하는 데 사용되었지만 원래 필요에 따라 설정되지 않은 경우 일부 레코드에 대해 해당 필드가 null 값을 가질 수 있습니다. 이 필드를 필수 사후 수집으로 설정하면 기록 레코드가 null일 수 있더라도 이후의 모든 레코드에는 이 필드의 값이 포함되어야 합니다.
이전에 선택 사항이었던 필드를 필요에 따라 설정할 때에는 다음 사항에 유의하십시오.
- 이전 데이터를 쿼리하고 결과를 새 데이터 세트에 쓰는 경우 일부 행에 필수 필드에 대한 null 값이 포함되어 있어 오류가 발생합니다.
- 필드가 실시간 고객 프로필에 참여하고 필요에 따라 설정하기 전에 데이터를 내보내는 경우 일부 프로필의 경우 null일 수 있습니다.
- 스키마 레지스트리 API를 사용하여 새 필수 필드를 포함하여 Experience Platform의 모든 XDM 리소스에 대한 타임스탬프가 지정된 변경 로그를 볼 수 있습니다. 자세한 내용은 감사 로그 끝점의 안내서를 참조하십시오.
스키마 및 데이터 수집
Experience Platform으로 데이터를 수집하려면 먼저 데이터 세트를 만들어야 합니다. 데이터 집합은 Catalog Service에 대한 데이터 변환 및 추적을 위한 기본 구성단위이며 일반적으로 수집된 데이터가 포함된 테이블 또는 파일을 나타냅니다. 모든 데이터 세트는 기존 XDM 스키마를 기반으로 하며, 이는 수집된 데이터에 포함해야 하는 항목과 데이터 구성 방법에 대한 제약 조건을 제공합니다. 자세한 내용은 Adobe Experience Platform 데이터 수집에 대한 개요를 참조하십시오.
스키마의 빌딩 블록
Experience Platform에서는 표준 빌딩 블록이 결합되어 스키마를 만드는 작성 접근 방식을 사용합니다. 이 접근 방식은 기존 구성 요소의 재사용을 촉진하고 업계 전반의 표준화를 유도하여 Experience Platform의 공급업체 스키마 및 구성 요소를 지원합니다.
스키마는 다음 공식을 사용하여 구성됩니다.
클래스 + 스키마 필드 그룹* = XDM 스키마
*스키마는 클래스와 0개 이상의 스키마 필드 그룹으로 구성됩니다. 즉, 필드 그룹을 전혀 사용하지 않고 데이터 세트 스키마를 구성할 수 있습니다.
클래스
스키마 작성은 클래스를 할당하는 것부터 시작됩니다. 클래스는 스키마에 포함될 데이터의 동작 측면(레코드 또는 시계열)을 정의합니다. 이 외에도 클래스는 해당 클래스를 기반으로 하는 모든 스키마가 포함해야 하는 가장 적은 수의 공통 속성을 설명하고 여러 호환되는 데이터 세트가 병합될 수 있는 방법을 제공합니다.
스키마의 클래스는 해당 스키마에서 사용할 수 있는 필드 그룹을 결정합니다. 자세한 내용은 다음 섹션을 참조하세요.
Adobe은 몇 가지 표준("코어") XDM 클래스를 제공합니다. 이러한 클래스 중 두 개(XDM Individual Profile 및 XDM ExperienceEvent)는 거의 모든 다운스트림 Experience Platform 프로세스에 필요합니다. 이러한 핵심 클래스 외에도 자신만의 사용자 지정 클래스를 만들어 조직에 대한 보다 구체적인 사용 사례를 설명할 수도 있습니다. 고유한 사용 사례를 설명하는 데 사용할 수 있는 Adobe 정의 핵심 클래스가 없는 경우 조직에서 사용자 정의 클래스를 정의합니다.
다음 스크린샷은 Experience Platform UI에서 클래스가 표현되는 방법을 보여 줍니다. 표시된 예제 스키마에는 필드 그룹이 없으므로 표시되는 모든 필드는 스키마의 클래스(XDM 개인 프로필)에서 제공합니다.
사용 가능한 표준 XDM 클래스의 최신 목록을 보려면 공식 XDM 저장소를 참조하십시오. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색에 대한 안내서를 참조할 수 있습니다.
필드 그룹
필드 그룹은 개인 세부 정보, 호텔 환경 설정 또는 주소와 같은 특정 기능을 구현하는 하나 이상의 필드를 정의하는 재사용 가능한 구성 요소입니다. 필드 그룹은 호환 가능한 클래스를 구현하는 스키마의 일부로 포함하기 위한 것입니다.
필드 그룹은 나타내는 데이터(레코드 또는 시계열)의 동작을 기반으로 호환되는 클래스를 정의합니다. 즉, 모든 필드 그룹을 모든 클래스에서 사용할 수 있는 것은 아닙니다.
Experience Platform에는 많은 표준 Adobe 필드 그룹이 포함되어 있으며 공급업체는 이를 통해 사용자를 위한 필드 그룹을 정의하고 개별 사용자는 고유한 개념에 대한 필드 그룹을 정의할 수 있습니다.
예를 들어 "충성도 멤버" 스키마에 대한 "이름" 및 "홈 주소" 등의 세부 정보를 캡처하려면 일반적인 개념을 정의하는 표준 필드 그룹을 사용할 수 있습니다. 그러나 조직에 더 고유한 개념(예: 사용자 정의 충성도 프로그램 세부 정보 또는 제품 속성)은 표준 필드 그룹에서 다루지 않을 수 있습니다. 이 경우 이 정보를 캡처하려면 고유한 필드 그룹을 정의해야 합니다.
NOTE스키마는 "0개 이상"의 필드 그룹으로 구성되어 있으므로 필드 그룹을 전혀 사용하지 않고도 유효한 스키마를 구성할 수 있음을 의미합니다.
다음 스크린샷은 Experience Platform UI에 필드 그룹이 어떻게 표시되는지 보여 줍니다. 단일 필드 그룹(인구 통계 세부 정보)이 이 예제의 스키마에 추가되어 스키마 구조에 대한 필드 그룹화를 제공합니다.
사용 가능한 표준 XDM 필드 그룹의 최신 목록을 보려면 공식 XDM 저장소를 참조하세요. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색에 대한 안내서를 참조할 수 있습니다.
NOTE데이터 유형
데이터 형식은 기본 리터럴 필드와 같은 방식으로 클래스나 스키마에서 참조 필드 형식으로 사용됩니다. 중요한 차이점은 데이터 유형이 필드 그룹과 동일한 방식으로 여러 하위 필드를 정의할 수 있다는 것입니다. 두 요소의 주요 차이점은 데이터 유형을 필드의 "데이터 유형"으로 추가하여 스키마의 모든 위치에 포함할 수 있다는 것입니다. 필드 그룹은 특정 클래스와만 호환되지만 데이터 형식은 모든 상위 클래스 또는 필드 그룹에 포함될 수 있습니다.
NOTEExperience Platform에서는 일반적인 데이터 구조를 설명하는 표준 패턴을 사용할 수 있도록 Schema Registry의 일부로 여러 가지 일반적인 데이터 형식을 제공합니다. 이 내용은 스키마 레지스트리 튜토리얼에 자세히 설명되어 있으며 데이터 형식을 정의하는 단계를 거칠 때 명확해집니다.
다음 스크린샷은 Experience Platform UI에 데이터 유형이 표현되는 방법을 보여 줍니다. 인구 통계학적 세부 정보 필드 그룹에서 제공한 필드 중 하나가 필드 이름 옆에 있는 파이프 문자(|) 뒤에 있는 텍스트로 표시된 "Object" 데이터 형식을 사용합니다. 이 특정 데이터 유형은 개별 사용자의 이름과 관련된 여러 하위 필드를 제공하며, 개인의 이름을 캡처해야 하는 다른 필드에 다시 사용할 수 있는 구성입니다.
사용 가능한 표준 XDM 데이터 형식의 최신 목록을 보려면 공식 XDM 저장소를 참조하십시오. 또는 UI에서 리소스를 보려면 XDM 구성 요소 탐색에 대한 안내서를 참조할 수 있습니다.
NOTE필드
필드는 스키마의 가장 기본적인 빌딩 블록입니다. 필드는 특정 데이터 형식을 정의하여 포함할 수 있는 데이터 형식과 관련된 제약 조건을 제공합니다. 이러한 기본 데이터 형식은 단일 필드를 정의하는 반면, 이전에 언급된 데이터 형식을(를) 사용하면 여러 하위 필드를 정의하고 여러 스키마 전체에서 동일한 다중 필드 구조를 재사용할 수 있습니다. 따라서 필드의 "데이터 유형"을 레지스트리에 정의된 데이터 유형 중 하나로 정의하는 것 외에도 Experience Platform은 다음과 같은 기본 스칼라 유형을 지원합니다.
- 문자열
- 정수
- 더블
- 부울
- 배열
- 오브젝트
TIP이러한 스칼라 유형의 유효한 범위는 특정 패턴, 형식, 최소/최대 또는 사전 정의된 값으로 추가로 제한될 수 있습니다. 이러한 제약 조건을 사용하면 다음을 포함하여 보다 구체적인 다양한 필드 유형을 나타낼 수 있습니다.
- 열거형
- Long
- 짧음
- 바이트
- 일자
- 날짜-시간
- 맵
NOTE컴포지션 예
스키마는 컴포지션 모델을 사용하여 만들어지며 Experience Platform에 수집할 데이터의 형식 및 구조를 나타냅니다. 앞에서 언급했듯이 이러한 스키마는 클래스와 해당 클래스와 호환되는 0개 이상의 필드 그룹으로 구성됩니다.
예를 들어 소매점에서 구매한 항목을 설명하는 스키마를 "스토어 트랜잭션"이라고 할 수 있습니다. 스키마는 표준 Commerce 필드 그룹 및 사용자 정의 제품 정보 필드 그룹과 결합된 XDM ExperienceEvent 클래스를 구현합니다.
웹 사이트 트래픽을 추적하는 다른 스키마를 "웹 방문"이라고 할 수 있습니다. 또한 XDM ExperienceEvent 클래스도 구현하지만 이번에는 표준 Web 필드 그룹이 결합됩니다.
아래 다이어그램은 이러한 스키마와 각 필드 그룹에서 제공한 필드를 보여 줍니다. 또한 이 안내서에서 이전에 언급한 "충성도 멤버" 스키마를 포함하여 XDM Individual Profile 클래스를 기반으로 하는 두 개의 스키마가 포함되어 있습니다.
합집합
Experience Platform을 사용하면 특정 사용 사례에 맞게 스키마를 구성할 수 있지만 특정 클래스 유형에 대한 스키마의 "결합"을 확인할 수도 있습니다. 이전 다이어그램은 XDM ExperienceEvent 클래스를 기반으로 하는 두 스키마와 XDM Individual Profile 클래스를 기반으로 하는 두 스키마를 보여 줍니다. 아래에 표시된 유니온은 동일한 클래스(XDM ExperienceEvent 및 XDM Individual Profile)를 공유하는 모든 스키마의 필드를 집계합니다.
Real-Time Customer Profile에 사용할 스키마를 활성화하면 해당 클래스 형식의 유니온에 포함됩니다. Profile은(는) 고객 특성에 대한 강력한 중앙 집중식 프로필과 Experience Platform과(와) 통합된 모든 시스템에서 고객이 경험한 모든 이벤트에 대한 타임스탬프가 지정된 계정을 제공합니다. Profile은(는) 유니온 보기를 사용하여 이 데이터를 나타내고 각 개별 고객에 대한 거시적인 보기를 제공합니다.
Profile 작업에 대한 자세한 내용은 실시간 고객 프로필 개요를 참조하십시오.
XDM 스키마에 데이터 파일 매핑
Experience Platform에 수집되는 모든 데이터 파일은 XDM 스키마 구조를 준수해야 합니다. XDM 계층 구조(샘플 파일 포함)를 준수하도록 데이터 파일의 형식을 지정하는 방법에 대한 자세한 내용은 샘플 ETL 변환에 대한 문서를 참조하십시오. Experience Platform으로 데이터 파일을 수집하는 방법에 대한 일반적인 정보는 일괄 처리 수집 개요를 참조하십시오.
외부 대상자용 스키마
외부 시스템의 대상을 Experience Platform으로 가져오는 경우 다음 구성 요소를 사용하여 스키마에서 캡처해야 합니다.
- 세그먼트 정의 클래스: 이 표준 클래스를 사용하여 외부 세그먼트 정의의 주요 특성을 캡처할 수 있습니다.
- 세그먼트 멤버십 세부 정보 필드 그룹: 이 필드 그룹을 XDM 개인 프로필 스키마에 추가하여 고객 프로필을 특정 대상과 연결합니다.
다음 단계
스키마 컴포지션의 기본 사항을 이해했으므로 Schema Registry을(를) 사용하여 스키마를 탐색하고 빌드할 준비가 되었습니다.
두 핵심 XDM 클래스의 구조와 일반적으로 사용되는 호환 가능한 필드 그룹을 검토하려면 다음 참조 설명서를 참조하십시오.
Schema Registry은(는) Adobe Experience Platform 내에서 Schema Library에 액세스하는 데 사용되며 사용 가능한 모든 라이브러리 리소스에 액세스할 수 있는 사용자 인터페이스와 RESTful API를 제공합니다. Schema Library에는 Adobe이 정의한 업계 리소스, Experience Platform 파트너가 정의한 공급업체 리소스, 조직의 멤버가 구성한 클래스, 필드 그룹, 데이터 형식 및 스키마가 포함되어 있습니다.
UI를 사용하여 스키마 작성을 시작하려면 스키마 편집기 튜토리얼과(와) 함께 이 문서 전체에서 언급된 "충성도 멤버" 스키마를 빌드하십시오.
Schema Registry API를 사용하려면 스키마 레지스트리 API 개발자 안내서를 읽는 것부터 시작하십시오. 개발자 안내서를 읽은 후 스키마 레지스트리 API를 사용하여 스키마 만들기에 대한 자습서에 설명된 단계를 따릅니다.
부록
다음 섹션에는 스키마 구성 원리에 대한 추가 정보가 포함되어 있습니다.
관계형 테이블 및 포함된 개체
관계형 데이터베이스를 사용하는 경우 모범 사례에는 데이터를 표준화하거나 엔티티를 여러 테이블에 표시되는 개별 조각으로 분할하는 작업이 포함됩니다. 데이터를 전체적으로 읽거나 엔티티를 업데이트하려면 JOIN을 사용하여 여러 개별 테이블에 대해 읽기 및 쓰기 작업을 수행해야 합니다.
XDM 스키마는 포함된 개체를 사용하여 복잡한 데이터를 직접 나타내고 계층 구조를 사용하여 자체 포함된 문서에 저장할 수 있습니다. 이 구조의 주요 이점 중 하나는 많은 비정규화된 테이블에 대한 값비싼 조인으로 엔티티를 재구성하지 않고 데이터를 쿼리할 수 있다는 것입니다. 스키마 계층 구조의 수에는 엄격한 제한이 없습니다.
스키마 및 빅 데이터
현대의 디지털 시스템은 방대한 양의 행동 신호(트랜잭션 데이터, 웹 로그, 사물 인터넷, 디스플레이 등)를 생성한다. 이러한 빅데이터는 경험을 최적화할 수 있는 남다른 기회를 제공하지만 데이터의 규모와 다양성으로 인해 활용이 어렵다. 데이터를 통해 가치를 얻기 위해서는 그 구조, 형식, 정의 등이 일관되고 효율적으로 처리될 수 있도록 표준화되어야 한다.
스키마는 여러 소스에서 데이터를 통합하고, 일반적인 구조와 정의를 통해 표준화하고, 솔루션 간에 공유할 수 있도록 함으로써 이러한 문제를 해결합니다. 이를 통해 후속 프로세스 및 서비스가 데이터에 대해 묻는 모든 유형의 질문에 답변할 수 있습니다. 데이터에 대해 질문할 모든 질문을 미리 알고, 이러한 기대에 부합하도록 데이터를 모델링하는 기존의 데이터 모델링 접근 방식에서 벗어납니다.
오브젝트 대 자유 형식 필드
스키마를 디자인할 때 자유 형식 필드 위에서 개체를 선택할 때 고려해야 할 몇 가지 주요 요소가 있습니다.
개체
자유 형식 필드에서 개체를 사용할 때의 장단점은 다음과 같습니다.
장점:
- 객체는 특정 필드의 논리적 그룹화를 만들려는 경우에 가장 잘 사용됩니다.
- 객체는 스키마를 보다 구조화된 방식으로 구성합니다.
- 오브젝트는 세그먼트 빌더 UI에서 좋은 메뉴 구조를 만드는 데 간접적으로 도움이 됩니다. 스키마 내의 그룹화된 필드는 세그먼트 빌더 UI에 제공된 폴더 구조에 직접 반영됩니다.
단점:
- 필드가 더 많이 중첩됩니다.
- Adobe Experience Platform 쿼리 서비스를 사용하는 경우 개체에 중첩된 쿼리 필드에 더 긴 참조 문자열을 제공해야 합니다.
자유 형식 필드
개체 위에 자유 형식 필드를 사용할 때의 장단점은 아래에 나와 있습니다.
장점:
- 자유 형식 필드가 스키마의 루트 개체(
_tenantId) 바로 아래에 만들어져 가시성이 높아집니다. - 자유 형식 필드의 참조 문자열은 쿼리 서비스를 사용할 때 더 짧은 경향이 있습니다.
단점:
- 스키마 내의 자유 형식 필드 위치는 애드혹(ad hoc)입니다. 즉, 스키마 편집기 내에서 알파벳 순서로 표시됩니다. 이렇게 하면 스키마의 구조가 줄어들고 유사한 자유 형식 필드가 이름에 따라 멀리 분리될 수 있습니다.