Analysproblem går i slutändan tillbaka till datan under. Duplicerade kundposter, intäkter som inte stämmer överens mellan rapporter och instrumentpaneler som motsäger varandra är inte visualiserings- eller frågeproblem; det är schemaproblem, och datanormalisering är hur team löser dem vid källan.

Nedan kommer vi att diskutera hur datanormalisering fungerar, hur ett normaliserat schema ser ut i praktiken och var de verkliga avvägningarna visar sig för analys- och lagerteam.

Viktiga punkter

• Datanormalisering strukturerar en relationsdatabas så att varje bit information bor på exakt ett ställe. Detta eliminerar duplicerade och motstridiga värden.

• Analysteam kan tillämpa normalisering i en pipeline genom att först bygga normaliserade kärnentitetstabeller och sedan lägga på denormaliserad rapportering ovanpå.

• En modern betalleverantör kan synkronisera betalningsdata direkt in i ett företags lager. Detta ger normaliserade scheman en komplett och uppdaterad källa att bygga från utan att dirigera känsliga ekonomiska data genom tredjepartsanslutningar.

Vad är datanormalisering?

Datanormalisering är processen att organisera en relationsdatabas så att varje del av informationen finns på exakt ett ställe. Du gör det genom att dela upp data i relaterade tabeller och länka dem via nycklar snarare än att upprepa samma värden över rader.

Målet är konsekvens. I takt med att datavolymen växer är denna strukturella disciplin det som skiljer ett lager du kan lita på från ett du ständigt granskar.

Varför spelar datanormalisering någon roll för analysnoggrannhet och styrning?

Onormaliserad data kan skapa kategorier av problem som förvärras i takt med att din data växer.

Vart och ett av följande är en strukturell brist i själva schemat:

• Uppdateringsanomalier: Dessa uppstår när samma fakta förekommer i flera rader. Om namnet på en abonnemangsplan lagras direkt på varje faktura-rad innebär ett namnbyte av planen att tusentals poster måste uppdateras, och att missa ens en enda skapar en avvikelse. I ett normaliserat schema bor plannamnet i en planer-tabell; fakturan håller bara ett plan_id.

• Infogningsanomalier: Dessa uppstår när du inte kan registrera något utan att registrera något annat orelaterat. I en platt tabell som lagrar kund- och beställningsdata tillsammans kan du inte lägga till en ny kund förrän hen gör en beställning, vilket innebär att tabellen går sönder i samma stund som ditt säljteam börjar ladda in prospekt i lagret.

• Borttagningsanomalier: Dessa inträffar när radering av en specifik post oavsiktligt tar bort orelaterad, viktig data. Om du tar bort den sista beställningen för en kund från en platt tabell förlorar du också deras kontaktinformation eftersom den inte hade en fristående plats.

Vilka är de huvudsakliga normalformerna?

Normalformer är en sekvens av allt strängare regler för hur data ska struktureras.

Team som använder datanormalisering måste förstå formerna upp till och med tredje normalformen (3NF) för att fatta bra schemabeslut. En databas beskrivs ofta som "normaliserad" om den uppfyller 3NF.

• Första normalformen (1NF): Detta kräver att varje kolumn innehåller atomära värden – inga listor, inga kommaseparerade strängar och inga fält sammanpackade i ett enda fält. En produktkolumn som innehåller "tröja, byxor, jacka" klarar inte 1NF. Tre rader med ett product_id och ett product_name på varje klarar det.

• Andra normalformen (2NF): Denna bygger på 1NF genom att kräva att varje icke-nyckelkolumn är beroende av hela primärnyckeln, inte bara en del av den. Om en radartikelstabell använder "(order_id, product_id)" som sin nyckel men också lagrar kundens stad, vilken bara beror på order_id, är det ett partiellt beroende och ett brott mot 2NF. Kundens stad hör hemma i beställningstabellen.

• Tredje normalformen (3NF): Denna eliminerar transitiva beroenden, det vill säga icke-nyckelkolumner som beror på andra icke-nyckelkolumner i stället för på själva nyckeln. Om en beställningstabell lagrar både zip_code och city, och staden bestäms av postnumret i stället för av beställningen, hör de fälten hemma i en separat geografitabell.

• Boyce-Codd Normal Form (BCNF): Detta är en striktare version av 3NF som hanterar specialfall som rör överlappande kandidatnycklar. För analysscheman är det tillräckligt att nå 3NF.

Hur fungerar datanormalisering i praktiken?

Det tydligaste sättet att se vad normalisering faktiskt gör är att börja med en trasig tabell och fixa den. Här är ett exempel på en onormaliserad beställningstabell och en förklaring av vad som händer med den efter normalisering.

Onormaliserad beställningstabell

Det finns tre omedelbara problem med den här tabellen. Anas e-postadress visas två gånger: om du uppdaterar den på en rad har du skapat en konflikt. Produktnamnet och kategorin upprepas på varje beställningsrad, så att ändra en kategori innebär att du måste ändra varje historisk beställning som inkluderade den. Dessutom finns det inget sätt att lägga till en ny kund eller produkt utan att koppla en beställning till den.

Efter normalisering skulle du ha tre tabeller:

• Kunder: customer_id, name, email
  
• Produkter: product_id, name, category
  
• Beställningar: order_id, customer_id, product_id, qty, unit_price
  

Anas e-postadress finns på ett ställe. Headsetets kategori finns på ett ställe. Beställningar refererar till båda med id. En two-join SELECT-sats i Structured Query Language (SQL) kan kombinera data från flera tabeller baserat på gemensamma villkor: en liten, permanent kostnad för ett schema som inte ackumulerar fel när det skalas.

Vilka är de vanliga avvägningarna med datanormalisering?

Även om det har viktiga fördelar kan normalisering också medföra verkliga kostnader för team.

Avvägningarna faller inom tre områden:

• Frågekomplexitet: Varje relation du normaliserar i sin egen tabell är en join du kommer att skriva senare. En rapport du kunde läsa från en platt tabell kräver nu tre joins, och den kognitiva belastningen byggs på i ett team av analytiker som arbetar direkt i SQL.

• Förhandsarbete för modellering: Att designa ett normaliserat schema kräver att du förstår domänen tillräckligt väl för att identifiera entiteter, deras attribut och relationerna mellan dem. Team som är under press att leverera hoppar ofta över detta för att bygga platta strukturer som verkar enklare för stunden, men som blir dyra senare.

• Läsprestanda: På mycket stora tabeller är joins långsammare än genomsökningar (scans). Moderna datalager (t.ex. BigQuery, Snowflake, Redshift) har frågeoptimerare som hanterar joins någorlunda väl, men denormaliserade strukturer vinner ofta när det gäller ren frågehastighet för analytiska arbetsbelastningar mot miljarder rader.

Hur tillämpar analys- och lagerteam datanormalisering i arbetsflöden?

I praktiken tillämpar analysteam normalisering i lager genom en pipeline. Olika strukturnivåer tjänar olika syften och intressen: dataintegritet hanteras på det normaliserade kärnlagret, medan frågeprestanda och analytikerergonomi hanteras på rapporteringslagret.

Så här går det till:

• Mellanlager (Staging layer): Rådata hamnar här nästan precis som den är från källan. Lite till ingen transformering sker i detta skede. Målet är bara att få in data i lagret intakt och sökbart, inte att modellera den.

• Normaliserat kärnlager: Transformeringsverktyg producerar normaliserade entitetstabeller från mellanlagret – en för kunder, en för abonnemang och en för transaktioner. Dessa ligger på ungefär 3NF och fungerar som källan till sanning för alla underordnade modeller.

• Rapporteringslager: Ovanpå den normaliserade kärnan bygger team breda, denormaliserade tabeller utformade för snabbhet och användarvänlighet i ett Business Intelligence-verktyg (BI) som Tableau eller Looker. En instrumentpanelsmodell för intäkter kan sammanfoga fem normaliserade tabeller till en bred faktatabell som BI-verktyget läser direkt.

Hur Stripe stödjer renare, mer tillförlitliga data för normalisering i efterföljande led

Kvaliteten på ett normaliserat schema beror helt och hållet på kvaliteten och fullständigheten hos de data som matar det. Gamla eller ofullständiga transaktionsposter kan skapa avstämningsluckor som ingen mängd noggrann schemadesign kan fixa.

Här är vad en betalleverantör kan erbjuda:

• Synkronisering: Stripe Data Pipeline flyttar Stripe-data (t.ex. debiteringar, kunder, abonnemang, återbetalningar, tvister, utbetalningar) direkt till ett datalager eller en molnlagringsdestination, utan någon tredjepartskontakt i mitten eller hastighetsbegränsningar för gränssnitt för applikationsprogrammering (API).

• Fullständighet: Stripe säkerställer att data är fullständiga genom att synkronisera alla Stripe-data, förbyggda ekonomiska rapporter och kurerade datamängder.

• Säkerhet: När team dirigerar Stripe-data genom tredjepartsanslutningar för att extrahera, transformera och ladda (ETL), skickar de känsliga finansiella data till ytterligare en leverantörs infrastruktur. Data Pipeline hanterar transporten direkt, vilket tar bort den mellanhanden och eliminerar en leverantör från din säkerhetsgranskningslista för data.

Data Pipeline ersätter inte en fullständig ETL-plattform. Om du kombinerar Stripe-data med data från ett dussin andra källor behöver du fortfarande transformationsverktyg. Men den här lösningen är utformad specifikt för att synkronisera dina Stripe-data bättre än en tredjepartsanslutning för att säkerställa att dina finansiella data synkroniseras tillförlitligt, säkert och exakt.