DWA-lagret

DWA-lagret är där en publicerad leverans blir strukturerad affärskunskap. Det hanterar datamodellering, käll-till-mål-mappning, transformationer och relationshantering.

QPI hör hemma här. Det är inte ett fjärde steg i flödet: data går INGEST → DLS → DWA, och QPI är ramverkets datakvalitetsmotor, med kontroller placerade på Published, Core och Business inom DWA. Avsnittet ligger längst ned på den här sidan.

För den skärmvisa guiden, se Data Warehouse Automation.

DWA-lagret är där rådata blir strukturerad affärskunskap. Det hanterar datamodellering, källa-till-mål-mappning, transformationer och relationshantering.

Modellkedjan

Kedjan är Published → Base → Core → DM. Stage har utgått som nivå: inläsningssteget det brukade beteckna heter nu Published, och laddas med de tekniker som beskrivs i Målplattformar.

┌─────────────┐    ┌──────────────────┐    ┌──────────────────┐    ┌────────────┐
│  Published  │ ──►│ Base Model       │ ──►│ Core Model       │ ──►│  DM        │
│  (Inläsning)│    │ (Integrera)      │    │ (Konsumera)      │    │ (Business) │
└─────────────┘    └──────────────────┘    └──────────────────┘    └────────────┘

Base Model (Ensemble / Integration)

• Syfte: Sammanfoga data från flera källor med konsekventa affärsregler
• Vad som händer här: Deduplicering, affärsnyckelsmatchning, käll-övergripande konsolidering
• Konfiguration: baseModelName, baseModelSchema i Settings

Core Model (Integrated / Konsumtion)

• Syfte: Slutgiltiga, rena affärsentiteter redo för analys och rapportering
• Vad som händer här: Publicera enhetliga Customer, Order, Product-tabeller
• Konfiguration: coreModelName, coreModelSchema i Settings

Dessutom kan Datamart-modeller konfigureras för specifika analytiska användningsfall via datamartModelNames och datamartModelSchemas i Settings.

Skapa modeller

En modell representerar en måltabell i lagret. Varje modell har:

Egenskap	Beskrivning
object	Unikt modellnamn
alias	Visningsnamn
description	Affärssyfte
objectType	Specific (enskild källa) eller Combined (flerkälla)
loadingPattern	Hur data laddas (se nedan)
attributes	Kolumner/fält med typer och nycklar
relationships	Främmande nycklar till andra modeller

Laddningsmönster

Mönster	Beteende	När det ska användas
full	Ersätt hela tabellen vid varje laddning	Små dimensioner, referensdata
incremental	Lägg bara till nya/ändrade poster	Stora faktatabeller, händelseloggar
transaction	Varje rad är en oföränderlig händelse	Finansiella transaktioner, revisionsloggar
dayspan	Partitionera efter datumintervall	Tidsseriedata, dagliga ögonblicksbilder
none	Ingen automatiserad laddning	Manuell eller externt hanterad

Modellattribut

Attribut definierar kolumnerna i din modell:

Egenskap	Beskrivning
attribute	Kolumnnamn
alias	Visningsnamn (valfritt)
dataType	Varchar, Integer, Decimal, Boolean, Time, Date, Timestamp
isBusinessKey	Y / N — är detta del av den unika identifieraren?
businessKeyOrder	Prioritet i sammansatta nycklar (1, 2, 3…)
description	Affärsdefinition

Affärsnycklar

Affärsnycklar identifierar unikt en post och är kritiska för deduplicering och upsert-operationer.

Tips:

• Markera attribut som affärsnycklar med isBusinessKey: "Y"
• Använd businessKeyOrder för att definiera prioriteten i sammansatta nycklar
• Dra rader för att ändra nyckelprioritet i UI:t
• Mappa affärsnycklar före attribut — de måste finnas innan beroende mappningar

Exempel — Sammansatt affärsnyckel:

Customer model:
  #1  SystemCode    (businessKeyOrder: 1)
  #2  CustomerID    (businessKeyOrder: 2)

Mappningar — källa till mål

Mappningar kopplar sourcefilefält till modellattribut. De är kärnmekanismen för datatransformation i DWA.

Mapping Properties

Egenskap	Beskrivning
source	Källfältsreferens
target	Målmodellattribut
isKeyMapping	Yes = affärsnyckelsmappning
keyOrder	Nyckelprioritetsordning
filter	SQL WHERE-villkor för denna mappning
optionalCalculation	SQL-uttryck för transformation
sortOrder	Sorteringsprioritet (negativt = ASC, positivt = DESC)
useFieldNameAsValue	Yes = använd fältnamnet självt som värde
mappingNumber	Gruppidentifierare för multi-mappningsscenarier

Mappningstyper

Typ	Visuell indikator	Beskrivning
Nyckelmappning	Teal, animerad	Affärsnyckel — mappar till unik identifierare
Beräkningsmappning	Grön	Inkluderar en SQL-transformation
Relationsmappning	Lila	Mappar till en främmande nyckelrelation
Standardmappning	Grå	Enkel fält-till-attribut-länk

Transformationer

Valfria beräkningar

Tillämpa SQL-uttryck för att transformera data under mappning:

-- Normalisering av skiftläge
UPPER(CustomerName)

-- Strängmanipulation
LEFT(OrderDate, 10)
TRIM(CustomerName)

-- Numeriska beräkningar
ROUND(priceUSD / 1.08, 2)
Amount * 0.25

-- Villkorslogik
CASE WHEN Status = 'A' THEN 'Active' ELSE 'Inactive' END

-- Datumformatering
TO_DATE(TransactionDate, 'YYYY-MM-DD')

important

Beräkningar använder måldatabasens SQL-dialekt. Fältnamn är skiftlägeskänsliga och måste matcha källan exakt.

Filter

Tillämpa radnivåvillkor för att inkludera/exkludera poster för en specifik mappning:

-- Bara icke-null-värden
IS NOT NULL

-- Mönstermatchning
LIKE 'ACTIVE%'

-- Numeriska jämförelser
> 0

-- Likhet
= 'SALE'

Ett filter gäller för ett enskilt källfält, och en mappningsgrupp kan bära flera kompositfilter. Olika laddningsvillkor hör hemma i olika mappningsgrupper.

Sorteringsordning

Styr postordning för CDC- och versioneringsscenarier:

Värde	Riktning	Användningsfall
Positivt (t.ex. 1)	Fallande	Senaste först (typiskt för LoadDate)
Negativt (t.ex. -2)	Stigande	Äldsta först
0	Ingen sortering	Standard

Använd fältnamn som värde: När useFieldNameAsValue: "Yes", används det bokstavliga fältnamnet som datavärde istället för fältets innehåll. Användbart för typindikatorer och enum-liknande kolumner.

Relationer (främmande nycklar)

Modeller kan referera andra modeller genom relationer:

Egenskap	Beskrivning
toObject	Målmodell
toAttribute	Målattribut (den refererade nyckeln)
relationType	1:N (en-till-många) eller M:M (många-till-många)
relationRole	Om objektet är parent eller child i relationen, eller many i en många-till-många. Utan angivet värde defaultas det till parent-child.

Visuella indikatorer i mappningsdiagrammet:

• Lila kanter med REL-märke för relationsmappningar
• 1:N visas som lila streckade linjer
• M:M visas som magenta streckade linjer

Modelleringsscenarier

Flerkälla-kundmaster

Du har kunddata i Salesforce, Marketo och ditt ERP. Mål: enhetlig Customer-modell.

Steg 1 — Published (varje källa läses in och normaliseras per attribut):

Salesforce:  Contact.FirstName → Customer.FirstName  (UPPER(FirstName))
Marketo:     Lead.first_name   → Customer.FirstName  (UPPER(first_name))
ERP:         CUST.FNAME        → Customer.FirstName  (UPPER(FNAME))

Steg 2 — Base Model (integrera med dedup):

Business Key: CustomerID (mappad från varje källas unika ID)
Filter: IS NOT NULL (exkludera test/ofullständiga poster)
Loading Pattern: incremental

Steg 3 — Core Model (slutgiltig dimension):

Business Key: CustomerID (sammansatt vid behov)
ValidFrom: LoadDate (validFrom=1, sortOrder=1 för DESC)
Loading Pattern: incremental med CDC

Tidigt anländande data (mastern ännu inte laddad)

Transaktioner anländer normalt före den masterdata de pekar på — en order för en kund som ännu inte finns i kundextraktet, ett ärende för en tillgång som registrerats i ett system med långsammare schema. Transaktionen hålls inte tillbaka, avvisas inte och parkeras inte för lagning.

Så fungerar det:

1. Relationer bärs av affärsnyckeln, inte av en surrogatnyckel som slås upp vid laddning. Barnposten lagrar förälderns affärsnyckel, så referensen är komplett i samma stund som barnet landar.
2. Föräldramodellen får en post för den nyckeln direkt, med nyckeln och ingenting annat. Relationen går ihop; det är bara de beskrivande attributen som saknas.
3. När masterkällan laddas fäster dess attribut på samma affärsnyckel. Den nyckelbärande posten blir en fullständig post — samma nyckel, samma relationer, nu med sina attribut.
4. Eftersom kärnan är historiserad blir kompletteringen en ny version i stället för en överskrivning. När masterdatan blev känd förblir synligt och spårbart.

Dag 1   Order 5591 → Kund "C-4417"        Kund C-4417: endast nyckel, inga attribut
Dag 3   Kundmastern laddas                 Kund C-4417: namn, segment, adress
                                           Order 5591 oförändrad — den var aldrig fel

Ingen manuell inblandning: barnladdningen körs inte om, inget avstämningsjobb löser nycklar i efterhand, och det finns ingen platshållarpost att leta rätt på och städa bort.

Fråga	Svar
Misslyckas eller väntar transaktionen?	Varken eller. Den laddas, med relationen intakt
Måste jag köra om något när mastern kommer?	Nej — nästa masterladdning kompletterar posten
Hur ser jag vad som fortfarande saknas?	En post som bär en affärsnyckel utan attribut
Upprätthållna främmande nycklar?	Den nyckelbärande föräldraposten är det som gör barnladdningen tillåten på mål som upprätthåller främmande nycklar — se målplattformar

note

En QPI-kontroll skriven som "noll föräldralösa" rapporterar väntande nycklar som ett fel så länge mastern är utestående. Där tidigt anländande data är normalt bör kontrollen avgränsas till nycklar som är äldre än masterkällans eget schema, i stället för till varje oupplöst nyckel.

Hierarkisk JSON med nästlade arrayer

Källa: API som returnerar kunder med inbäddade orderarrayer.

Sourcefile-struktur:

Level 0 (OBJECT): Root
  ├── customer.id        (keyFieldIndicator=1)
  ├── customer.name
  └── customer.loadDate  (validFrom=1)

Level 1 (LIST): orders   (useForSplittingRecords=1)
  ├── order.orderId
  ├── order.amount
  └── order.status

Mappningsstrategi:

• customer.id → Customer.CustomerKey (isKeyMapping=Yes)
• customer.name → Customer.Name
• customer.loadDate → sortera DESC för senaste version
• order.orderId → Order.OrderKey (isKeyMapping=Yes)
• order.status → filter != 'CANCELLED'
• customer.id → Order.CustomerID (relationsmappning)

Beräknade fält

Källa: Rå försäljningsdata som behöver affärsberäkningar.

Källfält	Målattribut	Beräkning
amount	TaxAmount	amount * 0.10
priceUSD	PriceEUR	ROUND(priceUSD / 1.08, 2)
transactionType	TransactionType	filter: = 'SALE'
rawDate	TransactionDate	TO_DATE(rawDate, 'YYYY-MM-DD')

SCD Typ 2 (Slowly Changing Dimension)

Spåra historiska ändringar av dimensionsposter.

Alla fält och relationer spårar historik som standard och är därmed kompatibla med SCD Typ 2.

Resultat: Varje ändring skapar en ny version. Sorteringsordningen säkerställer att den senaste versionen kan identifieras.

Hantering av känslig data

Hantera PII och styrningskrav i din modell.

Fält	Konfiguration	Effekt
ssn	sensitive: 1, excludeFromProfiling: 1	Maskerad i profiler, flaggad som PII
creditCard	sensitive: 1, excludeField: 1	Exkluderad från mål helt
email	sensitive: 1, fieldDomain: "PII"	Spårad för efterlevnad
internalId	excludeField: 1	Hoppad — behövs inte nedströms

Batch-redigering

När du behöver tillämpa samma konfiguration på många fält, använd Batch Edit-panelen:

• Välj flera attribut med kryssrutor
• Tillämpa filter, beräkning, sorteringsordning eller fältnamnsinställningar i bulk
• Användbart för att tillämpa en gemensam transformation över en stor sourcefile

Mappningsdiagram

Det visuella mappningsdiagrammet ger en drag-och-släpp-yta för att skapa och granska mappningar:

Vyer och funktioner

Vyer:

• Tree View — traditionell hierarkisk redigerare för detaljerat fält-för-fält-arbete
• Diagram View — React Flow-baserad yta som visar hela mappningsbilden

Diagramfunktioner:

• Färgkodade kanter efter mappningstyp (nyckel, beräkning, relation, standard)
• Beroendegraf — orange ramar markerar fält involverade i beräkningsformler
• Sök och filtrera — hitta fält efter namn, sökväg eller datatyp med auto-zoom
• Exportera — ladda ner som PNG (1920×1080) eller SVG-vektor med tidsstämpel
• Minikarta — översikt av hela mappningsstrukturen

Bästa praxis för DWA

Modelldesign

• Börja med affärsnycklar — definiera unika identifierare innan du lägger till attribut
• Använd sammansatta nycklar sparsamt — 2–3 fält max för underhållbarhet
• Skriv tydliga beskrivningar — de fungerar som dokumentation för nedströmskonsumenter
• Välj laddningsmönster noggrant — full för små tabeller, incremental för stora

Mappningsstrategi

• Mappa nycklar först, attribut sedan — affärsnycklar måste finnas innan beroende mappningar
• Använd beräkningar för normalisering — standardisera format (datum, skiftläge) på mappningsnivå
• Tillämpa filter på mappningsnivå — inte i exportens WHERE-klausul — för modellspecifika exkluderingar
• Gruppera relaterade mappningar — använd mappingNumber för att organisera multi-mappningsscenarier

Prestanda och styrning

• Undvik övermappning — mappa bara fält som faktiskt behövs i modellen
• Använd excludeField — ta bort bruskolumner innan de går in i modelleringspipelinen
• Profilera selektivt — exkludera högvolym, välförstådda fält från profilering
• Flagga känsliga fält tidigt — markera PII i sourcefile-strukturen, inte som en eftertanke
• Tilldela fältdomäner — använd klassificeringskategorier för efterlevnadsspårning
• Dokumentera relationer — lägg till beskrivningar för att förklara varför modeller är länkade

---

Kvalitetsövervakning (QPI)

QPI är ramverkets datakvalitetsmotor. Den kör SQL-kontroller mot data i DWA och rapporterar vad den hittar — den blockerar inte en laddning och kan inte stoppa nedströms arbete.

Kontroller kan placeras på Published, Core (Integrated) och DM (Business). De är fristående och kan triggas av orkestreringen efter Additional Tasks, när de källflöden de beror på är klara, eller kedjade efter varandra. De skapas och administreras i DataOps-konsolen, under QPI Monitor och QPI Administration — se Datakvalitet.

Den spårar mappningstäckning, styrning på fältnivå, dataprofilering och pipelinens fullständighet — ett ställe att titta på för datakvalitet.

Plattformsnivåmått

Dashboarden visar fem nyckelräknare som ger en omedelbar pulskontroll:

Mått	Vad det mäter	Varför det är viktigt
Systems	Totalt anslutna källsystem	Är alla förväntade källor registrerade?
Source Files	Totalt sourcefile-definitioner	Är alla förväntade dataflöden definierade?
Fields	Totalt fält över alla sourcefiles	Är datakontraktet komplett?
Mappings	Totalt källa-till-modell-mappningar	Är källor anslutna till lagret?
Models	Totalt lagermodeller	Är målschemat helt definierat?

En plötslig minskning i någon räknare kan indikera ett konfigurationsproblem eller oavsiktlig radering.

Mappningstäckning

Den viktigaste kvalitetsindikatorn. Mappningstäckning mäter vilken procentandel av en sourcefils fält som är mappade till en modell.

Beräkning: coverage = (mappedFieldCount / fieldCount) × 100

Täckning	Status	Visuell	Betydelse
80–100%	Frisk	Grön	De flesta fält är mappade och modellerade
40–79%	Varning	Gul	Betydande omappade fält — granskning behövs
0–39%	Kritisk	Röd	Mestadels omappad — troligen ofullständig uppsättning

Var det syns:

• Data Lineage Flow — kanter mellan sourcefiles och modeller är färgkodade efter täckning
• Sourcefile-noder — framstegsbalkar visar täckningsprocent per fil
• Animerade kanter — anslutningar under 80% täckning animeras för att dra uppmärksamhet

Anslutningshälsa

Varje källsystems anslutningstyp och exportstatus övervakas:

Indikator	Värden	Vad man ska titta på
Anslutningstyp	DB, API, File, Custom, Manual	Saknade anslutningar visas som "undefined"
Har exporter	Ja / Nej	System utan exporter producerar ingen data
Exportantal	Antal konfigurerade exporter	Förvänta minst en per aktivt system

I arkitekturdiagrammet ansluter system med exporter via heldragna pilar genom Ingest Agent, medan system utan exporter ansluter med streckade pilar (direktöverföring).

Styrning på fältnivå

Varje fält i en sourcefile bär styrningsflaggor som fungerar som kvalitetsindikatorer:

Flagga	Syfte	Övervaka för
keyFieldIndicator	Markerar primär-/affärsnycklar	Saknade nycklar = ingen deduplicering möjlig
sensitive	Flaggar PII/känslig data	Otaggad PII = efterlevnadsrisk
excludeField	Tar bort fält från pipeline	Överexkludering kan tappa nödvändig data
excludeFromProfiling	Hoppar över kvalitetskontroller	För många exkluderingar = blinda fläckar
validFrom	SCD Typ 2-versioneringsfält	Saknas = ingen historisk spårning
fieldDomain	Styrningsklassificering	Oklassificerade fält = styrningslucka

Flaggorna är inte bara indikatorer — de är instruktioner. Generatorn läser dem när den bygger måltabellerna: keyFieldIndicator blir en primärnyckel på publiceringstabellen och ett unikt villkor på core-tabellen, fieldDomain blir en kategoritagg på kolumnen, sensitive blir en känslighetstagg och, på plattformar som stödjer det, en kolumnmask. Ett fält som klassificerats en gång på källan är klassificerat överallt plattformen bär det vidare, även på de normaliserade barntabeller som ärver dess nyckel.

Det är därför ett oklassificerat fält är en styrningslucka snarare än en dokumentationslucka: ingenting nedströms hittar på klassificeringen åt dig, och ingenting applicerar den i efterhand på tabeller som redan skapats.

→ Vad som landar i målmiljön

Dataprofilering

Vad profilering validerar

När enableProfiler är aktivt på en sourcefile kör systemet kontinuerliga kvalitetskontroller mot datakontraktet:

• Datatypöverensstämmelse (är heltal verkligen heltal?)
• Null/tomma fältkvoter
• Värdefördelningmönster
• Schemadriftdetektering (nya eller saknade kolumner)

Konfiguration:

• Aktivera per sourcefile via enableProfiler: 1
• Exkludera specifika fält med excludeFromProfiling: 1
• Resultat skrivs till Profile Zone i DLS-pipelinen

Avvägningar:

• Profilering ökar beräkningsresursanvändningen
• Inaktivera för högvolym, välförstådda, stabila källor
• Aktivera alltid för nya integrationer tills datakontraktet är validerat

Modellrelationer

Data Lineage Flow spårar hur modeller kopplas till varandra:

Relationstyp	Visuell	Vad man ska övervaka
1:N (One-to-Many)	Lila streckade linjer	Saknade = isolerade modeller utan kopplingar
M:M (Many-to-Many)	Magenta streckade linjer	Överdrivet = möjligt modelleringsproblem

Additional Tasks (utökad övervakning)

Konfigurera för- och efterbearbetningsuppgifter

För övervakningsbehov bortom inbyggda indikatorer, konfigurera Additional Tasks:

Egenskap	Beskrivning
Name	Uppgiftsidentifierare
Type	pre (före huvudbearbetning) eller post (efter)
RunCommand	Körbart kommando att köra
Dependency[]	Andra uppgifter som måste slutföras först
SortOrder	Exekveringssekvens

Användningsfall:

• Datafärskhekskontroller — verifiera att data anlände inom förväntade tidsfönster
• Radantalvalidering — jämför faktiska mot förväntade postantal
• Schemadriftdetektering — varna när källstruktur ändras oväntat
• Tröskelvarningar — flagga när mått överskrider acceptabla gränser
• Efterladdningsaggregering — beräkna sammanfattande statistik efter varje laddning

Dashboards och visualiseringar

Arkitekturdiagram

Den end-to-end pipelinevisualiseringen som visar alla fyra lager:

Datakällor (grå) → Ingest (teal) → DLS (blå) → DWA (lila)

Vad man ska övervaka:

• Finns alla förväntade system?
• Har alla system anslutningar och exporter?
• Är hela pipelinekedjan intakt (inga trasiga länkar)?

Data Lineage Flow

En detaljerad vy som visar hur data flödar från system genom sourcefiles till modeller:

System → Sourcefiles → Modeller → Relaterade modeller

Trekolumnslayout:

• Vänster: Källsystem med sourcefile-antal
• Mitten: Sourcefiles med täckningsframstegsbalkar
• Höger: Målmodeller med attributantal och relationer

Vad man ska övervaka:

• Röda/gula kanter som indikerar låg mappningstäckning
• Animerade kanter som drar uppmärksamhet till ofullständiga mappningar
• Föräldralösa modeller (inga inkommande mappningar)
• Föräldralösa sourcefiles (inga utgående mappningar)

Källdetaljpanel

Klicka på valfritt system i arkitekturdiagrammet för att se:

• Anslutningstyp och status
• Alla sourcefiles för det systemet
• Fältantal per sourcefile
• Mappningsantal per sourcefile
• Expanderbar sökvägstruktur med fältdetaljer

Övervakningschecklistor

Dagliga kontroller

Kontroll	Var	Vad man ska leta efter
Plattformsräknare	Dashboard Stats	Oväntade minskningar i någon räknare
Mappningstäckning	Data Lineage Flow	Nya röda/gula kanter
Systemanslutningar	Arkitekturdiagram	Saknade eller trasiga anslutningar
Exportstatus	Arkitekturdiagram	System utan exporter (streckade linjer)

Veckovisa kontroller

Kontroll	Var	Vad man ska leta efter
Styrningtäckning	Field Editor	Fält som saknar sensitive eller fieldDomain-flaggor
Profileringsresultat	Profile Zone	Anomalier i datatypöverensstämmelse eller nullkvoter
Modellfullständighet	Model Editor	Modeller med få eller inga attribut
Relationshälsa	Data Lineage Flow	Föräldralösa eller frånkopplade modeller

Vid ny integration

Steg	Åtgärd
1	Verifiera att systemet visas i arkitekturdiagrammet
2	Bekräfta att anslutningstypen är korrekt
3	Kontrollera att exporter är konfigurerade och schemalagda
4	Aktivera enableProfiler på alla nya sourcefiles
5	Markera känsliga fält med sensitive: 1
6	Tilldela fieldDomain-klassificeringar
7	Skapa mappningar och verifiera att täckningen når målet för källfilstypen (se Täckningsmål)
8	Validera profileringsresultat efter första laddning

Bästa praxis för QPI

Täckningsmål

Sourcefile-typ	Måltäckning	Motivering
Kärnaffärsdata (kunder, ordrar)	90–100%	Kritisk för analys
Referens-/dimensionsdata	80–100%	Behövs för kopplingar och uppslagningar
Händelse-/loggdata	60–80%	Många fält kan vara metadata/brus
Staging-/temporära källor	40–60%	Kan vara delvis relevant

Profileringsstrategi

• Aktivera som standard för alla nya sourcefiles
• Inaktivera selektivt för stabila, högvolymkällor efter validering
• Inaktivera aldrig för källor med PII — efterlevnad kräver löpande validering
• Exkludera specifika fält istället för att inaktivera profilering helt

Styrningsprioriteringar

1. Tagga PII först — sensitive: 1 på alla personligt identifierbara fält
2. Klassificera fält — tilldela fieldDomain för efterlevnadsspårning
3. Definiera affärsnycklar — varje modell behöver minst en
4. Dokumentera relationer — lägg till beskrivningar för att förklara varför modeller är länkade
5. Granska exkluderingar — se till att excludeField inte döljer nödvändig data

---

Nästa steg

• Data Warehouse Automation — konfigurationsguiden fält för fält
• Vad som landar i målmiljön — villkoren, kommentarerna och taggarna generatorn skapar
• Skillnader mellan målplattformar — vad varje motor upprätthåller och inte klarar