Basisbeginselen van de schemacompositie
Gemaakt voor:
- Ontwikkelaar
Leer over de schema's van de Gegevens van de Ervaring van het Model (XDM) en de bouwstenen, principes, en beste praktijken voor het samenstellen van schema's in Adobe Experience Platform. Voor algemene informatie over XDM en hoe het binnen Platform wordt gebruikt, zie het XDM overzicht van het Systeem.
Schema's begrijpen
Een schema is een set regels die de structuur en indeling van gegevens vertegenwoordigen en valideren. Op een hoog niveau, verstrekken de schema's een abstracte definitie van een real-world voorwerp (zoals een persoon) en schetsen welke gegevens in elke instantie van dat voorwerp (zoals voornaam, achternaam, verjaardag, etc.) zouden moeten worden omvat.
Naast het beschrijven van de structuur van gegevens, passen de schema's beperkingen en verwachtingen op gegevens toe zodat het kan worden bevestigd aangezien het zich tussen systemen beweegt. Deze standaarddefinities maken het mogelijk dat gegevens consistent worden geïnterpreteerd, ongeacht de oorsprong, en verwijderen de noodzaak van vertaling in verschillende toepassingen.
Experience Platform handhaaft deze semantische normalisatie door schema's te gebruiken. Schema's zijn de standaardmanier om gegevens in Experience Platform te beschrijven, zodat alle gegevens die aan schema's voldoen, opnieuw kunnen worden gebruikt in een organisatie zonder conflicten, of zelfs kunnen worden gedeeld tussen meerdere organisaties.
XDM-schema's zijn ideaal voor het opslaan van grote hoeveelheden complexe gegevens in een op zichzelf staand formaat. Zie de secties op ingebedde voorwerpenen grote gegevensin het bijlage aan dit document voor meer informatie over hoe XDM dit verwezenlijkt.
Workflows op basis van schema's in Experience Platform
Standaardisering is een sleutelbegrip van Experience Platform. XDM, aangedreven door Adobe, is een inspanning om de gegevens van de klantenervaring te standaardiseren en standaardschema's voor het beheer van de klantenervaring te bepalen.
De infrastructuur waarop Experience Platform is gebouwd, ook wel XDM System genoemd, vereenvoudigt workflows op basis van schema's en omvat de Schema Registry , Schema Editor , schema-metagegevens en het serviceconsumptiepatroon. Zie het XDM overzicht van het Systeemvoor meer informatie.
Er zijn verschillende belangrijke voordelen verbonden aan het gebruik van schema's in Experience Platform. In de eerste plaats zorgen schema's voor een beter gegevensbeheer en gegevensminimalisering, wat vooral belangrijk is bij privacyregels. Ten tweede, staan de bouwschema's met Adobe standaardcomponenten voor uit-van-de-doosinzichten en gebruik van de diensten van AI/ML met minimale aanpassingen toe. Ten slotte bieden schema's infrastructuren voor het uitwisselen van inzichten in gegevens en een efficiënte orchestratie.
Uw schema plannen
De eerste stap in het bouwen van een schema is het concept, of real-world voorwerp, te bepalen dat u binnen het schema probeert te vangen. Zodra u het concept identificeert dat u probeert te beschrijven, begin plannend uw schema door over dingen zoals het type van gegevens, potentiële identiteitsgebieden te denken, en hoe het schema in de toekomst kan evolueren.
Gedrag van gegevens in Experience Platform
Gegevens die bestemd zijn voor gebruik in Experience Platform worden gegroepeerd in twee gedragstypen:
- gegevens van het Verslag: Verstrekt informatie over de attributen van een onderwerp. Een onderwerp kan een organisatie of een individu zijn.
- de reeksgegevens van de Tijd: Verstrekt een momentopname van het systeem in de tijd dat een actie of direct of indirect door een verslagonderwerp werd genomen.
Alle XDM schema's beschrijven gegevens die als verslag of tijdreeks kunnen worden gecategoriseerd. Het gegevensgedrag van een schema wordt bepaald door de klasse van het schema, die aan een schema wordt toegewezen wanneer het eerst wordt gecreeerd. XDM-klassen worden later in dit document nader beschreven.
Zowel bevatten de verslag als de tijdreeksenschema's een kaart van identiteiten (xdm:identityMap). Dit veld bevat de identiteitsrepresentatie van een onderwerp, getekend vanuit velden die zijn gemarkeerd als Identiteit zoals beschreven in de volgende sectie.
Identity
Schema's worden gebruikt voor het opnemen van gegevens in Experience Platform. Deze gegevens kunnen over de veelvoudige diensten worden gebruikt om één enkele, verenigde mening van een individuele entiteit tot stand te brengen. Daarom is het belangrijk om bij het ontwerpen van schema's voor klantenidentiteiten te overwegen welke gebieden kunnen worden gebruikt om een onderwerp te identificeren, ongeacht waar de gegevens uit kunnen komen.
Om dit proces te helpen, kunnen de belangrijkste gebieden binnen uw schema's als identiteiten worden gemerkt. Op gegevensopname, worden de gegevens in die gebieden opgenomen in "Identity Graph"voor dat individu. De grafiekgegevens kunnen vervolgens worden benaderd door Real-Time Customer Profile en andere Experience Platform-services om een samengevoegde weergave van elke afzonderlijke klant te bieden.
Velden die algemeen als "Identity"worden gemerkt omvatten: e-mailadres, telefoonaantal, Experience Cloud ID (ECID), identiteitskaart van CRM, of andere unieke gebieden van identiteitskaart Overweeg om het even welke unieke herkenningstekens specifiek voor uw organisatie, aangezien zij ook goede "Identity"gebieden kunnen zijn.
Het is belangrijk om over klantenidentiteiten tijdens de schema planningsfase te denken helpen ervoor zorgen dat de gegevens worden samengebracht om het robuustst mogelijke profiel te bouwen. Meer over leren hoe de identiteitsinformatie u kan helpen digitale ervaringen aan uw klanten leveren, zie het overzicht van de Dienst van de Identiteit. Zie het gegevens modellerend beste praktijkdocument voor uiteinden op het gebruik van identiteiten wanneer het creëren van een schema.
Er zijn twee manieren om identiteitsgegevens naar Platform te verzenden:
- Toevoegend identiteitsbeschrijvers aan individuele gebieden, of door de Redacteur UI van het Schemaof het gebruiken van de Registratie API van het Schema
- Een
identityMapveldgebruiken
identityMap
identityMap is een map-type gebied dat de diverse identiteitswaarden voor een individu, samen met hun bijbehorende namespaces beschrijft. Dit gebied kan worden gebruikt om identiteitsinformatie voor uw schema's te verstrekken, in plaats van het bepalen van identiteitswaarden binnen de structuur van het schema zelf.
Het belangrijkste nadeel van het gebruik van identityMap is dat identiteiten in de gegevens worden ingesloten en daardoor minder zichtbaar worden. Als u onbewerkte gegevens opgeeft, moet u in plaats daarvan afzonderlijke identiteitsvelden definiëren binnen de daadwerkelijke schemastructuur.
NOTEidentityMap gebruikt kan als bronschema in een verhouding worden gebruikt, maar kan niet als verwijzingsschema worden gebruikt. Dit komt omdat alle verwijzingsschema's een zichtbare identiteit moeten hebben die op een verwijzingsgebied binnen het bronschema kan worden in kaart gebracht. Verwijs naar de gids UI op verhoudingenvoor meer informatie over de vereisten van bron en verwijzingsschema's.Identiteitskaarten kunnen echter nuttig zijn als er een variabel aantal identiteiten voor een schema is of als u gegevens opneemt uit bronnen die identiteiten samen opslaan (zoals Airship of Adobe Audience Manager). Bovendien worden de identiteitskaarten vereist als u Adobe Experience Platform Mobile SDKgebruikt.
Een voorbeeld van een eenvoudige identiteitskaart zou als het volgende kijken:
"identityMap": {
"email": [
{
"id": "jsmith@example.com",
"primary": true
}
],
"ECID": [
{
"id": "87098882279810196101440938110216748923",
"primary": false
},
{
"id": "55019962992006103186215643814973128178",
"primary": false
}
],
"CRMID": [
{
"id": "2e33192000007456-0365c00000000000",
"primary": false
}
]
}
Zoals in het bovenstaande voorbeeld wordt getoond, vertegenwoordigt elke sleutel in het identityMap -object een naamruimte voor de identiteit. De waarde voor elke sleutel is een serie van voorwerpen, die de identiteitswaarden (id) voor respectieve namespace vertegenwoordigen. Verwijs naar de Identity Service documentatie voor a lijst van standaard identiteitsnamespacesdie door de toepassingen van Adobe wordt erkend.
NOTEprimary) is, kan ook worden opgegeven voor elke identiteitswaarde. U hoeft alleen primaire identiteiten in te stellen voor schema's die bedoeld zijn voor gebruik in Real-Time Customer Profile . Zie de sectie over verenigingsschema'svoor meer informatie.Beginselen voor de ontwikkeling van schema's
Naarmate de aard van de digitale ervaringen zich blijft ontwikkelen, moeten de schema's die gebruikt worden om ze te vertegenwoordigen ook worden gebruikt. Een goed ontworpen schema kan daarom aanpassen en evolueren zoals nodig, zonder destructieve veranderingen in vorige versies van het schema te veroorzaken.
Aangezien het handhaven van achterwaartse verenigbaarheid essentieel voor schemaevolutie is, handhaaft Experience Platform een zuiver additief versieringsbeginsel. Dit beginsel zorgt ervoor dat om het even welke revisies aan het schema slechts in niet-destructieve updates en veranderingen resulteren. Met andere woorden, wordt het breken veranderingen niet gesteund.
NOTEIn de volgende tabel wordt aangegeven welke wijzigingen worden ondersteund bij het bewerken van schema's, veldgroepen en gegevenstypen:
- Nieuwe velden toevoegen aan de bron
- Een vereist veld optioneel maken
- Nieuwe vereiste velden maken*
- De weergavenaam en beschrijving van de bron wijzigen
- Het schema toestaan om aan Profiel deel te nemen
- Eerder gedefinieerde velden verwijderen
- Bestaande velden hernoemen of opnieuw definiëren
- Eerder ondersteunde veldwaarden verwijderen of beperken
- Bestaande velden verplaatsen naar een andere locatie in de structuur
- Het schema verwijderen
- Het schema uitschakelen om deel te nemen aan profiel
* verwijs naar de sectie hieronder voor belangrijke overwegingen betreffende het plaatsen van nieuwe vereiste gebieden.
Vereiste velden
De individuele schemagebieden kunnen zoals vereistworden gemerkt, zo betekent het dat om het even welke ingebedde verslagen gegevens op die gebieden moeten bevatten om bevestiging over te gaan. Bijvoorbeeld, kan het plaatsen van het primaire identiteitsgebied van een schema zoals vereist helpen ervoor zorgen dat alle ingebedde verslagen aan het Profiel van de Klant in real time zullen deelnemen. Als u een tijdstempelveld instelt als vereist, blijven alle gebeurtenissen in de tijdreeks chronologisch behouden.
IMPORTANTnull of lege waarden voor een ingesloten veld. Als er geen waarde is voor een bepaald veld in een record of gebeurtenis, moet de sleutel voor dat veld worden uitgesloten van de opname-lading.Velden instellen zoals vereist na invoegen
Als een veld is gebruikt om gegevens in te voeren en oorspronkelijk niet is ingesteld als vereist, heeft dat veld mogelijk een null-waarde voor sommige records. Als u dit veld na invoer als vereist instelt, moeten alle toekomstige records een waarde voor dit veld bevatten, ook al kunnen historische records null zijn.
Houd rekening met het volgende wanneer u een eerder optioneel veld naar wens instelt:
- Als u historische gegevens controleert en de resultaten in een nieuwe dataset schrijft, zullen sommige rijen ontbreken omdat zij ongeldige waarden voor het vereiste gebied bevatten.
- Als het gebied aan in real time het Profiel van de Klantdeelneemt en u gegevens alvorens het zoals vereist te plaatsen uitvoert, kan het voor sommige profielen ongeldig zijn.
- U kunt de API van de Registratie van het Schema gebruiken om een timestamped verandering voor alle middelen XDM in Platform, met inbegrip van nieuwe vereiste gebieden te bekijken. Zie de gids op het eindpunt van het controlelogboekvoor meer informatie.
Schema's en gegevensinvoer
Om gegevens in Experience Platform in te voeren, moet eerst een dataset worden gecreeerd. Datasets zijn de bouwstenen voor gegevenstransformatie en -tracking voor Catalog Service en vertegenwoordigen over het algemeen tabellen of bestanden die ingesloten gegevens bevatten. Alle datasets zijn gebaseerd op bestaande schema's XDM, die beperkingen voor wat verstrekken de ingebedde gegevens zouden moeten bevatten en hoe het zou moeten worden gestructureerd. Zie het overzicht op Ingestie van Gegevens van Adobe Experience Platformvoor meer informatie.
Bouwstenen van een schema
Experience Platform gebruikt een compositiebenadering waarin de standaard bouwstenen worden gecombineerd om schema's tot stand te brengen. Deze benadering bevordert de herbruikbaarheid van bestaande componenten en drijft standaardisatie over de industrie om verkopersschema's en componenten in Platform te steunen.
De schema's worden samengesteld gebruikend de volgende formule:
Klasse + de Groef& van het Gebied van het Schema;ast; = XDM Schema
*Een schema bestaat uit een klasse en nul of meer groepen schemavelden. Dit betekent dat u een datasetschema kon samenstellen zonder gebiedsgroepen bij allen te gebruiken.
Klasse
Het samenstellen van een schema begint door een klasse toe te wijzen. De klassen bepalen de gedragsaspecten van de gegevens die het schema (verslag of tijdreeks) zal bevatten. Bovendien beschrijven de klassen het kleinste aantal gemeenschappelijke eigenschappen die alle die schema's op die klasse worden gebaseerd zouden moeten omvatten en een manier verstrekken om veelvoudige compatibele datasets worden samengevoegd.
De klasse van een schema bepaalt welke gebiedsgroepen voor gebruik in dat schema in aanmerking komen. Dit wordt besproken meer in detail in de volgende sectie.
Adobe biedt verschillende standaard XDM-klassen ("core"). Twee van deze klassen, XDM Individual Profile en XDM ExperienceEvent , zijn vereist voor bijna alle downstream-platformprocessen. Naast deze kernklassen kunt u ook uw eigen aangepaste klassen maken om specifieke gebruiksgevallen voor uw organisatie te beschrijven. Aangepaste klassen worden gedefinieerd door een organisatie wanneer er geen door Adobe gedefinieerde kernklassen beschikbaar zijn om een uniek geval van gebruik te beschrijven.
De volgende schermafbeelding toont hoe klassen worden vertegenwoordigd in de gebruikersinterface van het platform. Aangezien het getoonde voorbeeldschema geen gebiedsgroepen bevat, worden alle getoonde gebieden verstrekt door de klasse van het schema (XDM Individual Profile).
Voor de meest bijgewerkte lijst van beschikbare standaardXDM klassen, verwijs naar de officiële bewaarplaats XDM. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.
Veldgroep
Een veldgroep is een herbruikbare component die een of meer velden definieert die bepaalde functies implementeren, zoals persoonlijke gegevens, hotelvoorkeuren of adres. Veldgroepen moeten worden opgenomen als onderdeel van een schema dat een compatibele klasse implementeert.
Veldgroepen definiëren met welke klasse of klassen ze compatibel zijn, op basis van het gedrag van de gegevens die ze vertegenwoordigen (record- of tijdreeks). Dit betekent dat niet alle veldgroepen beschikbaar zijn voor gebruik met alle klassen.
Experience Platform bevat veel standaard Adobe-veldgroepen en biedt leveranciers ook de mogelijkheid om veldgroepen voor hun gebruikers te definiëren, en afzonderlijke gebruikers om veldgroepen voor hun eigen specifieke concepten te definiëren.
Bijvoorbeeld, om details zoals "First Name"en "Home Address"voor uw "Loyalty Members"schema te vangen, zou u standaardgebiedsgroepen kunnen gebruiken die die gemeenschappelijke concepten bepalen. Nochtans, concepten die specifieker voor uw organisatie (zoals de details van het douaneloyaliteitsprogramma of productattributen) zijn die niet door standaardgebiedsgroepen kunnen worden behandeld. In dit geval moet u uw eigen veldgroep definiëren om deze gegevens vast te leggen.
NOTEHerinner dat de schema's uit "nul of meer"gebiedsgroepen worden samengesteld, zodat betekent dit dat u een geldig schema kon samenstellen zonder enige gebiedsgroepen bij allen te gebruiken.
De volgende schermafbeelding laat zien hoe veldgroepen worden vertegenwoordigd in de gebruikersinterface van het platform. Één enkele gebiedsgroep (Demographic Details) wordt toegevoegd aan een schema in dit voorbeeld, dat een groepering van gebieden aan de structuur van het schema verstrekt.
Voor de meest bijgewerkte lijst van beschikbare standaard XDM gebiedsgroepen, verwijs naar de officiële XDM bewaarplaats. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.
NOTEGegevenstype
Gegevenstypen worden op dezelfde manier als letterlijke basisvelden gebruikt als referentieveldtypen in klassen of schema's. Het belangrijkste verschil is dat gegevenstypen meerdere subvelden op dezelfde manier kunnen definiëren als veldgroepen. Het belangrijkste verschil tussen hen, is dat de gegevenstypes overal in een schema kunnen worden omvat door het als "gegevenstype"van een gebied toe te voegen. Veldgroepen zijn alleen compatibel met bepaalde klassen, maar gegevenstypen kunnen in elke bovenliggende klasse of veldgroep worden opgenomen.
NOTEExperience Platform biedt een aantal gangbare gegevenstypen als onderdeel van de Schema Registry voor ondersteuning van het gebruik van standaardpatronen voor het beschrijven van algemene gegevensstructuren. Dit wordt verklaard meer in detail in de leerprogramma's van de Registratie van het Schemaen zal duidelijker worden aangezien u door de stappen loopt om gegevenstypes te bepalen.
De volgende schermafbeelding toont hoe gegevenstypen worden weergegeven in de interface van het platform. Een van de velden in de veldgroep Demographic Details gebruikt het gegevenstype Object , zoals wordt aangegeven door de tekst na het verticale streepje (| ) naast de naam van het veld. Dit specifieke gegevenstype biedt verschillende subvelden die betrekking hebben op de naam van een individuele persoon, een constructie die opnieuw kan worden gebruikt voor andere velden waarin de naam van een persoon moet worden vastgelegd.
Voor de meest bijgewerkte lijst van beschikbare standaard XDM gegevenstypes, verwijs naar de officiële XDM bewaarplaats. Alternatief, kunt u naar de gids verwijzen bij het onderzoeken van componenten XDMals u verkiest om middelen in UI te bekijken.
NOTEVeld
Een veld is de eenvoudigste bouwsteen van een schema. Velden bieden beperkingen met betrekking tot het type gegevens dat ze kunnen bevatten door een specifiek gegevenstype te definiëren. Deze basisgegevenstypes bepalen één enkel gebied, terwijl de eerder genoemde gegevenstypesu toestaan om veelvoudige subfields te bepalen en de zelfde multi-gebiedstructuur door diverse schema's opnieuw te gebruiken. Naast het definiëren van het "gegevenstype" van een veld als een van de gegevenstypen die in het register zijn gedefinieerd, ondersteunt Experience Platform dus elementaire scalaire typen, zoals:
- String
- Geheel
- Dubbel
- Boolean
- Array
- Object
TIPDe geldige waaiers van deze scalaire types kunnen verder tot bepaalde patronen, formaten, minimum/maximum, of vooraf bepaalde waarden worden beperkt. Gebruikend deze beperkingen, kan een brede waaier van specifiekere gebiedstypes worden vertegenwoordigd, die omvatten:
- Enum
- Lang
- Kort
- Byte
- Datum
- Datum/tijd
- Kaart
NOTECompositievoorbeeld
Schema's zijn gemaakt met behulp van een compositiemodel en vertegenwoordigen de indeling en structuur van gegevens die in Platform moeten worden opgenomen. Zoals eerder vermeld, zijn deze schema's samengesteld uit een klasse en nul of meer gebiedsgroepen die met die klasse compatibel zijn.
Bijvoorbeeld, zou een schema beschrijvend aankopen die bij een detailhandel worden gemaakt "Store Transactions"kunnen worden genoemd. Het schema implementeert de klasse XDM ExperienceEvent in combinatie met de standaard Commerce veldgroep en een door de gebruiker gedefinieerde Product Info veldgroep.
Een ander schema dat websiteverkeer volgt zou "Web Visits"kunnen worden genoemd. De klasse XDM ExperienceEvent wordt ook geïmplementeerd, maar deze keer wordt de standaardveldgroep van Web gecombineerd.
In het onderstaande diagram worden deze schema's en de velden weergegeven die door elke veldgroep worden bijgedragen. Het bevat ook twee schema's die op de XDM Individual Profile klasse worden gebaseerd, met inbegrip van het "Loyalty Members"schema dat eerder in deze gids wordt vermeld.
Samenvoegen
Hoewel Experience Platform u toestaat om schema's voor bepaalde gebruiksgevallen samen te stellen, staat het u ook toe om een "unie"van schema's voor een specifiek klassentype te zien. In het vorige diagram worden twee schema's weergegeven op basis van de klasse XDM ExperienceEvent en twee schema's op basis van de klasse XDM Individual Profile . De samenvoeging, die hieronder wordt weergegeven, aggregeert de velden van alle schema's die dezelfde klasse delen (XDM ExperienceEvent respectievelijk XDM Individual Profile ).
Wanneer u een schema inschakelt voor gebruik met Real-Time Customer Profile , wordt dit opgenomen in de union voor dat klassetype. Profile biedt robuuste, gecentraliseerde profielen van klantkenmerken en een tijdstempelaccount voor elke gebeurtenis die de klant heeft gehad in een systeem dat is geïntegreerd met Platform . Profile gebruikt de verenigingsmening om deze gegevens te vertegenwoordigen en een holistische mening van elke individuele klant te verstrekken.
Voor meer informatie bij het werken met Profile, zie het Real-Time overzicht van het Profiel van de Klant.
Gegevensbestanden toewijzen aan XDM-schema's
Alle gegevensbestanden die in Experience Platform worden opgenomen, moeten de structuur van een XDM-schema hebben. Voor meer informatie over hoe te om gegevensbestanden te formatteren om aan hiërarchieën XDM (met inbegrip van steekproefdossiers) te voldoen, zie het document op transformaties van steekproefETL. Voor algemene informatie over het opnemen van gegevensbestanden in Experience Platform, zie het overzicht van partijingestitie.
Schema's voor extern publiek
Als u publiek van externe systemen in Platform brengt, moet u de volgende componenten gebruiken om hen in uw schema's te vangen:
- Segment definition class: Gebruik deze standaardklasse om zeer belangrijke attributen van een externe segmentdefinitie te vangen.
- Segment Membership Details veldgroep: voeg deze veldgroep toe aan uw XDM Individual Profile -schema om klantprofielen aan specifieke doelgroepen te koppelen.
Volgende stappen
Nu u de grondbeginselen van schemacompositie begrijpt, bent u bereid beginnen het onderzoeken van en het bouwen van schema's gebruikend Schema Registry.
Raadpleeg de volgende documentatie voor informatie over de structuur van de twee belangrijkste XDM-klassen en hun veelgebruikte compatibele veldgroepen:
Schema Registry wordt gebruikt om Schema Library binnen Adobe Experience Platform te openen, en verstrekt een gebruikersinterface en RESTful API waarvan alle beschikbare bibliotheekmiddelen toegankelijk zijn. Schema Library bevat de middelen van de Industrie die door Adobe worden bepaald, de middelen van de Leverancier door de partners van Experience Platform worden bepaald, en klassen, gebiedsgroepen, gegevenstypes, en schema's die door leden van uw organisatie zijn samengesteld.
Beginnen samenstellend schema gebruikend UI, volg samen met het leerprogramma van de Redacteur van het Schemaom het schema van de "Leden van de Loyaliteit"te bouwen dat door dit document wordt vermeld.
Beginnen gebruikend Schema Registry API, begin door de gids van de ontwikkelaar van de Registratie API van het Schema te lezen. Na het lezen van de ontwikkelaarsgids, volg de stappen die in het leerprogramma worden geschetst op creërend een schema gebruikend de Registratie API van het Schema.
Bijlage
De volgende secties bevatten extra informatie betreffende de beginselen van schemacompositie.
Relatieve tabellen versus ingesloten objecten
Wanneer het werken met relationele gegevensbestanden, impliceren de beste praktijken het normaliseren van gegevens, of het nemen van een entiteit en het verdelen van het in discrete stukken die dan over veelvoudige lijsten worden getoond. Om de gegevens als geheel te lezen of de entiteit bij te werken, lees en schrijf verrichtingen over vele individuele lijsten moeten worden gemaakt gebruikend JOIN.
Door ingebedde voorwerpen te gebruiken, kunnen de schema's XDM complexe gegevens direct vertegenwoordigen en het opslaan in op zichzelf staande documenten met een hiërarchische structuur. Één van de belangrijkste voordelen aan deze structuur is dat het u toestaat om de gegevens te vragen zonder het moeten de entiteit door dure verbindingen aan veelvoudige gedenormaliseerde lijsten reconstrueren. Er zijn geen harde beperkingen aan hoeveel niveaus uw schemahiërarchie kan zijn.
Schema's en grote gegevens
Moderne digitale systemen genereren enorme hoeveelheden gedragssignalen (transactiegegevens, weblogbestanden, internet van dingen, weergave, enzovoort). Deze grote gegevens bieden buitengewone mogelijkheden om ervaringen te optimaliseren, maar zijn lastig te gebruiken vanwege de schaal en de verscheidenheid van de gegevens. Om waarde te kunnen halen uit de gegevens, moeten de structuur, indeling en definities ervan worden gestandaardiseerd, zodat deze consistent en efficiënt kunnen worden verwerkt.
De schema's lossen dit probleem op door gegevens toe te laten om uit veelvoudige bronnen worden geïntegreerd, door gemeenschappelijke structuren en definities worden gestandaardiseerd, en over oplossingen worden gedeeld. Dit staat verdere processen en de diensten toe om het even welk type van vraag te beantwoorden die van de gegevens wordt gesteld. Het verschuift van de traditionele benadering naar gegevensmodellering, waarbij alle vragen die over de gegevens moeten worden gesteld van tevoren bekend zijn, en de gegevens worden gemodelleerd om aan die verwachtingen te voldoen.
Objecten versus vrije-formuliervelden
Bij het ontwerpen van uw schema's moet u rekening houden met een aantal belangrijke factoren wanneer u objecten kiest op vrije-formuliervelden:
Objecten
Hieronder ziet u de voor- en nadelen van het gebruik van objecten op vrije-formuliervelden.
Pros:
- Objecten kunt u het beste gebruiken als u een logische groepering van bepaalde velden wilt maken.
- Objecten ordenen het schema op een meer gestructureerde manier.
- Objecten helpen indirect bij het maken van een goede menustructuur in de gebruikersinterface van Segment Builder. De gegroepeerde velden in het schema worden direct weerspiegeld in de mappenstructuur die is opgegeven in de gebruikersinterface van Segment Builder.
Kons:
- Velden worden meer genest.
- Wanneer het gebruiken van de Dienst van de Vraag van Adobe Experience Platform, langere verwijzingskoorden moeten aan vraaggebieden worden verstrekt die in voorwerpen worden genesteld.
Velden met vrije vorm
De voor- en nadelen van het gebruik van vrije-formuliervelden op objecten worden hieronder weergegeven.
Pros:
- Vrije-vormgebieden worden gecreeerd direct onder het wortelvoorwerp van het schema (
_tenantId), verhogend zicht. - De koorden van de verwijzing voor vrije-vormgebieden zijn gewoonlijk korter wanneer het gebruiken van de Dienst van de Vraag.
Kons:
- De locatie van vrije-formuliervelden in het schema is ad hoc. Dit betekent dat deze velden in alfabetische volgorde worden weergegeven in de Schema-editor. Hierdoor kunnen schema's minder gestructureerd worden, en vergelijkbare vrije-vormgebieden kunnen uiteindelijk ver worden gescheiden afhankelijk van hun namen.