Grunderna för schemakomposition

Lär dig mer om XDM-scheman (Experience Data Model) och byggstenarna, principerna och de bästa sätten att komponera scheman i Adobe Experience Platform. Allmän information om XDM och hur det används i Platform, se XDM - systemöversikt.

Scheman understanding-schemas

Ett schema är en uppsättning regler som representerar och validerar datastrukturen och dataformatet. På en hög nivå ger scheman en abstrakt definition av ett objekt i verkligheten (till exempel en person) och ger en översikt över vilka data som ska inkluderas i varje instans av objektet (till exempel förnamn, efternamn, födelsedag o.s.v.).

Förutom att beskriva datastrukturen, tillämpar scheman begränsningar och förväntningar på data så att de kan valideras när de flyttas mellan olika system. Med dessa standarddefinitioner kan data tolkas på ett enhetligt sätt, oavsett ursprung, och behovet av översättning mellan olika program försvinner.

Experience Platform underhåller denna semantiska normalisering med hjälp av scheman. Scheman är standardmetoden för att beskriva data i Experience Platform, vilket gör att alla data som överensstämmer med scheman kan återanvändas i en organisation utan konflikter, eller till och med delas mellan flera organisationer.

XDM-scheman är idealiska för att lagra enorma mängder komplexa data i ett självständigt format. Se avsnitten om inbäddade objekt och big data i bilagan till det här dokumentet om du vill ha mer information om hur XDM gör detta.

Schemabaserade arbetsflöden i Experience Platform schema-based-workflows

Standardisering är ett nyckelbegrepp bakom Experience Platform. XDM, som drivs av Adobe, är ett försök att standardisera kundupplevelsedata och definiera standardscheman för kundupplevelsehantering.

Den infrastruktur som Experience Platform bygger på, känd som XDM System, underlättar schemabaserade arbetsflöden och innehåller Schema Registry, Schema Editor, schemadata och tjänstekonsumtionsmönster. Se XDM - systemöversikt för mer information.

Det finns flera fördelar med att använda scheman i Experience Platform. För det första möjliggör scheman bättre datastyrning och minimering av data, vilket är särskilt viktigt med sekretessbestämmelser. För det andra gör det möjligt att bygga scheman med Adobe standardkomponenter för körklara insikter och använda AI/ML-tjänster med minimala anpassningar. Slutligen tillhandahåller scheman infrastruktur för datautbytesinsikter och effektiv samordning.

Planera ditt schema planning

Det första steget i att skapa ett schema är att fastställa konceptet, eller det verkliga objektet, som du försöker fånga inom schemat. När du har identifierat konceptet som du försöker beskriva börjar du planera ditt schema genom att tänka på saker som datatypen, potentiella identitetsfält och hur schemat kan utvecklas i framtiden.

Databeteenden i Experience Platform data-behaviors

Data som är avsedda att användas i Experience Platform är grupperade i två beteendetyper:

Alla XDM-scheman beskriver data som kan kategoriseras som post- eller tidsserier. Databeteendet för ett schema definieras av schemats klass, som tilldelas till ett schema när det skapas första gången. XDM-klasser beskrivs mer ingående senare i det här dokumentet.

Scheman för både post- och tidsserier innehåller en karta över identiteter (xdm:identityMap). Det här fältet innehåller identitetsbeteckningen för ett ämne, som har ritats från fält som markerats som "Identitet" enligt beskrivningen i nästa avsnitt.

Identity identity

Scheman används för inmatning av data i Experience Platform. Dessa data kan användas för flera tjänster för att skapa en enda, enhetlig vy av en enskild enhet. Därför är det viktigt att tänka på vilka fält som kan användas för att identifiera ett ämne när du utformar scheman för kundidentiteter, oavsett varifrån uppgifterna kommer.

Nyckelfält i dina scheman kan markeras som identiteter för att underlätta med den här processen. När data har matats in infogas uppgifterna i dessa fält iIdentity Graph" för den där individen. Diagramdata kan sedan nås av Real-Time Customer Profile och andra Experience Platform-tjänster för att ge en enhetlig bild av varje enskild kund.

Fält som vanligen markeras som "Identity" inkludera: e-postadress, telefonnummer, Experience Cloud ID (ECID), CRM-ID eller andra unika ID-fält. Överväg alla unika identifierare som är specifika för din organisation, eftersom de kan vara braIdentityäven fält.

Det är viktigt att tänka på kundens identiteter under schemaplaneringsfasen för att säkerställa att data samlas ihop för att skapa den mest robusta profilen som är möjlig. Mer information om hur identitetsinformation kan hjälpa er att leverera digitala upplevelser till era kunder finns i Översikt över identitetstjänsten. Läs dokumentet om god praxis för datamodellering för tips om hur du använder identiteter när du skapar ett schema.

Det finns två sätt att skicka identitetsdata till plattformen:

identityMap identityMap

identityMap är ett mappningsfält som beskriver de olika identitetsvärdena för en individ, tillsammans med deras associerade namnutrymmen. Det här fältet kan användas för att ange identitetsinformation för dina scheman, i stället för att definiera identitetsvärden inom strukturen för själva schemat.

Den största nackdelen med att använda identityMap är att identiteter blir inbäddade i data och därmed blir mindre synliga. Om du importerar rådata bör du definiera enskilda identitetsfält i den faktiska schemastrukturen i stället.

Identitetskartor kan dock vara användbara om det finns ett varierande antal identiteter för ett schema, eller om du samlar in data från källor som lagrar identiteter tillsammans (till exempel Airship eller Adobe Audience Manager). Dessutom krävs identitetskartor om du använder Adobe Experience Platform Mobile SDK.

Ett exempel på en enkel identitetskarta skulle se ut så här:

"identityMap": {
  "email": [
    {
      "id": "jsmith@example.com",
      "primary": true
    }
  ],
  "ECID": [
    {
      "id": "87098882279810196101440938110216748923",
      "primary": false
    },
    {
      "id": "55019962992006103186215643814973128178",
      "primary": false
    }
  ],
  "CRMID": [
    {
      "id": "2e33192000007456-0365c00000000000",
      "primary": false
    }
  ]
}

Som visas i exemplet ovan finns varje tangent i identityMap -objektet representerar ett identitetsnamnutrymme. Värdet för varje nyckel är en array med objekt som representerar identitetsvärdena (id) för respektive namnutrymme. Se Identity Service dokumentation för lista med vanliga ID-namnutrymmen känns igen av Adobe.

Principer för schemautveckling evolution

I takt med att de digitala upplevelserna utvecklas måste även de scheman som används för att representera dem finnas kvar. Ett väldesignat schema kan därför anpassas och utvecklas efter behov, utan att det medför destruktiva ändringar i tidigare versioner av schemat.

Eftersom det är viktigt att bibehålla bakåtkompatibiliteten för att kunna utveckla scheman tillämpar Experience Platform en rent additiv versionsprincip. Denna princip säkerställer att alla ändringar av schemat endast resulterar i icke-förstörande uppdateringar och ändringar. Med andra ord: brytningsändringar stöds inte.

I följande tabell visas vilka ändringar som stöds vid redigering av scheman, fältgrupper och datatyper:

*Se avsnittet nedan för viktig information ställa in nya obligatoriska fält.

Obligatoriska fält

Enskilda schemafält kan vara markerat som obligatoriskt, vilket innebär att alla kapslade poster måste innehålla data i dessa fält för att validera. Om du till exempel anger ett schemats primära identitetsfält som obligatoriskt kan du se till att alla inkapslade poster deltar i kundprofilen i realtid. Om du anger ett tidsstämpelfält som obligatoriskt ser du dessutom till att alla händelser i tidsserien bevaras kronologiskt.

Ange fält som obligatoriska efter intag post-ingestion-required-fields

Om ett fält har använts för att importera data och inte ursprungligen ställdes in som nödvändigt, kan det fältet ha ett null-värde för vissa poster. Om du anger det här fältet som obligatoriskt för postinmatning måste alla framtida poster innehålla ett värde för det här fältet, även om historiska poster kan vara null.

Tänk på följande när du ställer in ett tidigare valfritt fält efter behov:

Scheman och datainmatning

För att kunna importera data till Experience Platform måste en datauppsättning först skapas. Datauppsättningar är byggstenarna för dataomvandling och -spårning för Catalog Serviceoch representerar vanligtvis tabeller eller filer som innehåller inkapslade data. Alla datauppsättningar baseras på befintliga XDM-scheman, som innehåller begränsningar för vad de inmatade data ska innehålla och hur de ska struktureras. Se översikten på Adobe Experience Platform datainmatning för mer information.

Bygga block i ett schema schema-building-blocks

Experience Platform använder en dispositionsmetod där standardbyggstenar kombineras för att skapa scheman. Den här metoden främjar återanvändbarheten av befintliga komponenter och driver standardisering i hela branschen för att stödja leverantörsscheman och komponenter i Platform.

Scheman består av följande formel:

Klass + schemafältgrupp; = XDM-schema

*Ett schema består av en klass och noll eller flera schemafältgrupper. Det innebär att du kan skapa ett datauppsättningsschema utan att använda fältgrupper alls.

Klass class

Dispositionen av ett schema börjar med att tilldela en klass. Klasser definierar de beteendeaspekter av data som schemat kommer att innehålla (post- eller tidsserie). Förutom detta beskriver klasser det minsta antalet gemensamma egenskaper som alla scheman baserade på den klassen behöver innehålla och tillhandahåller ett sätt för att sammanfoga flera kompatibla datamängder.

En schemaklass avgör vilka fältgrupper som är berättigade att användas i schemat. Detta diskuteras mer ingående i nästa avsnitt.

Adobe tillhandahåller flera standardklasser ("core") för XDM. Två av dessa klasser, XDM Individual Profile och XDM ExperienceEventkrävs för nästan alla plattformsprocesser längre fram i kedjan. Dessutom kan du skapa egna klasser som beskriver mer specifika användningsfall för organisationen. Anpassade klasser definieras av en organisation när det inte finns några Adobe-definierade huvudklasser tillgängliga som beskriver ett unikt användningsfall.

I följande skärmbild visas hur klasser visas i användargränssnittet för plattformen. Eftersom exempelschemat som visas inte innehåller några fältgrupper, kommer alla fält som visas att tillhandahållas av schemaklassen (XDM Individual Profile).

Den senaste listan över tillgängliga standard-XDM-klasser finns i officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att visa resurser i användargränssnittet.

Fältgrupp field-group

En fältgrupp är en återanvändbar komponent som definierar ett eller flera fält som implementerar vissa funktioner, som personlig information, hotellinställningar eller adress. Fältgrupper är avsedda att ingå i ett schema som implementerar en kompatibel klass.

Fältgrupper definierar vilken eller vilka klasser de är kompatibla med, baserat på beteendet för de data de representerar (post- eller tidsserie). Det innebär att inte alla fältgrupper är tillgängliga för användning med alla klasser.

Experience Platform innehåller många standardfältgrupper i Adobe samtidigt som leverantörer kan definiera fältgrupper för sina användare, och enskilda användare kan definiera fältgrupper för sina egna specifika koncept.

Om du till exempel vill hämta information som "First Nameoch "Home Address" för dina "Loyalty Members"schema, du skulle kunna använda standardfältgrupper som definierar dessa vanliga begrepp. Begrepp som är mer specifika för din organisation (t.ex. kundens kundlojalitetsprogram eller produktattribut) som kanske inte omfattas av standardfältgrupper. I det här fallet måste du definiera en egen fältgrupp för att kunna hämta informationen.

Kom ihåg att scheman består av fältgrupper som är "noll eller fler", vilket innebär att du kan skapa ett giltigt schema utan att använda några fältgrupper alls.

I följande skärmbild visas hur fältgrupper representeras i användargränssnittet för plattformen. En enda fältgrupp (Demographic Details) läggs till i ett schema i det här exemplet, som innehåller en gruppering av fält till schemats struktur.

Den senaste listan över tillgängliga standardfältgrupper i XDM finns i officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att visa resurser i användargränssnittet.

Datatyp data-type

Datatyper används som referensfälttyper i klasser eller scheman på samma sätt som grundläggande litteralfält. Den största skillnaden är att datatyper kan definiera flera delfält på samma sätt som fältgrupper. Den största skillnaden mellan dem är att datatyper kan inkluderas var som helst i ett schema genom att lägga till den som"datatyp" för ett fält. Fältgrupper är bara kompatibla med vissa klasser, men datatyper kan inkluderas i alla överordnade klasser eller fältgrupper.

Experience Platform tillhandahåller ett antal vanliga datatyper som en del av Schema Registry som stöder användning av standardmönster för att beskriva vanliga datastrukturer. Detta förklaras mer ingående i Självstudiekurser för schemaregister och blir tydligare när du går igenom stegen för att definiera datatyper.

I följande skärmbild visas hur datatyperna visas i användargränssnittet för plattformen. Ett av fälten i Demographic Details fältgruppen använder "Object", datatyp, enligt texten efter lodstreck (|) bredvid fältets namn. Den här särskilda datatypen innehåller flera delfält som relaterar till namnet på en enskild person, en konstruktion som kan återanvändas för andra fält där en persons namn måste hämtas.

Den senaste listan över tillgängliga XDM-standarddatatyper finns i officiell XDM-databas. Du kan även läsa guiden på utforska XDM-komponenter om du föredrar att visa resurser i användargränssnittet.

Fält field

Ett fält är den mest grundläggande byggstenen i ett schema. Fält innehåller begränsningar för vilken typ av data de kan innehålla genom att definiera en viss datatyp. Dessa grundläggande datatyper definierar ett enda fält, medan datatyper kan du definiera flera delfält och återanvända samma struktur med flera fält i olika scheman. Förutom att definiera ett fälts"datatyp" som en av de datatyper som definieras i registret, stöder Experience Platform grundläggande skalära typer som:

Giltiga intervall för dessa skalära typer kan begränsas ytterligare till vissa mönster, format, minimum/maximum eller fördefinierade värden. Med dessa begränsningar kan en mängd mer specifika fälttyper visas, bland annat:

Kompositionsexempel composition-example

Scheman byggs med hjälp av en kompositionsmodell och representerar formatet och strukturen för de data som ska infogas i Platform. Som tidigare nämnts består dessa scheman av en klass och noll eller flera fältgrupper som är kompatibla med den klassen.

Ett schema som beskriver inköp som görs i en butik kan till exempel kallasStore Transactions". Schemat implementerar XDM ExperienceEvent klass kombinerad med standard Commerce fältgrupp och en användardefinierad Product Info fältgrupp.

Ett annat schema som spårar webbplatstrafiken kan kallasWeb Visits". Den implementerar även XDM ExperienceEvent -klassen, men den här tiden kombinerar standarden Web fältgrupp.

Diagrammet nedan visar dessa scheman och fälten från varje fältgrupp. Den innehåller även två scheman baserade på XDM Individual Profile -klass, inklusiveLoyalty Membersschemat som nämndes tidigare i den här guiden.

Sammanslutning union

Med Experience Platform kan du skapa scheman för olika användningsområden, men du kan även se en "union" av scheman för en viss klasstyp. I föregående diagram visas två scheman baserade på klassen XDM ExperienceEvent och två scheman baserade på XDM Individual Profile klassen. Unionen, som visas nedan, samlar fälten för alla scheman som delar samma klass (XDM ExperienceEvent och XDM Individual Profile).

Genom att aktivera ett schema för användning med Real-Time Customer Profile, ingår det i unionen för den typen av klass. Profile ger robusta, centraliserade profiler av kundattribut och en tidsstämplad översikt över alla händelser som kunden har haft i alla system som är integrerade med Platform. Profile använder unionsvyn för att representera dessa data och ge en helhetsbild av varje enskild kund.

Mer information om hur du arbetar med Profile, se Översikt över kundprofiler i realtid.

Mappa datafiler till XDM-scheman mapping-datafiles

Alla datafiler som importeras till Experience Platform måste överensstämma med strukturen i ett XDM-schema. Mer information om hur du formaterar datafiler enligt XDM-hierarkier (inklusive exempelfiler) finns i dokumentet om exempel på ETL-omformningar. Allmän information om hur du importerar datafiler till Experience Platform finns i batchvis hantering - översikt.

Scheman för externa målgrupper

Om du samlar målgrupper från externa system i Platform måste du använda följande komponenter för att fånga dem i dina scheman:

Nästa steg

Nu när du förstår grunderna i schemakomposition kan du börja utforska och skapa scheman med Schema Registry.

Om du vill granska strukturen för de två grundläggande XDM-klasserna och deras vanliga kompatibla fältgrupper, se följande referensdokumentation:

The Schema Registry används för att komma åt Schema Library i Adobe Experience Platform och tillhandahåller ett användargränssnitt och RESTful API från vilket alla tillgängliga biblioteksresurser är tillgängliga. The Schema Library innehåller branschresurser som definieras av Adobe, leverantörsresurser som definieras av Experience Platform partners, och klasser, fältgrupper, datatyper och scheman som har disponerats av medlemmar i din organisation.

För att börja komponera schemat med användargränssnittet följer du med Schemaredigeraren, genomgång att skapa schemat "Lojalitetsmedlemmar" som omnämns i hela det här dokumentet.

Börja använda Schema Registry API, börja med att läsa Utvecklarhandbok för API för schematabell. När du har läst utvecklarhandboken följer du de steg som beskrivs i självstudiekursen om skapa ett schema med API:t för schemaregister.

Bilaga

Följande avsnitt innehåller ytterligare information om principerna för schemakomposition.

Relationstabeller jämfört med inbäddade objekt embedded

När du arbetar med relationsdatabaser omfattar de effektivaste strategierna att normalisera data eller att ta en enhet och dela upp den i separata delar som sedan visas i flera tabeller. Om du vill läsa data som helhet eller uppdatera entiteten måste läs- och skrivåtgärder utföras för många enskilda tabeller med JOIN.

Genom att använda inbäddade objekt kan XDM-scheman representera komplexa data direkt och lagra dem i självständiga dokument med en hierarkisk struktur. En av de största fördelarna med den här strukturen är att den gör det möjligt att fråga efter data utan att behöva rekonstruera enheten med dyrbara kopplingar till flera deformerade tabeller. Det finns inga hårda begränsningar för hur många nivåer din schemahierarki kan vara.

Scheman och big data big-data

Moderna digitala system genererar enorma mängder beteendesignaler (transaktionsdata, webbloggar, internet med mera). Dessa stora data ger fantastiska möjligheter att optimera upplevelser, men är svåra att använda på grund av datans storlek och variation. För att få ut mer av informationen måste dess struktur, format och definitioner standardiseras så att de kan behandlas på ett konsekvent och effektivt sätt.

Scheman löser detta problem genom att data kan integreras från flera källor, standardiseras med gemensamma strukturer och definitioner och delas mellan olika lösningar. Detta gör att efterföljande processer och tjänster kan besvara alla typer av frågor som ställs om data. Det går längre än till traditionell datamodellering där alla frågor som ska ställas om data är kända i förväg och data är modellerade för att uppfylla dessa förväntningar.

Objekt jämfört med frihandsfält objects-v-freeform

Det finns några viktiga faktorer att tänka på när du väljer objekt framför frihandsfält när du utformar scheman:

Objekt

Fördelarna och nackdelarna med att använda objekt över frihandsfält visas nedan.

Proffs:

Kon:

Frihandsfält

Fördelarna och nackdelarna med att använda frihandsfält över objekt visas nedan.

Proffs:

Kon: