Etablera ett system för hur du och kollegor döper fältnamn, och var konsekvent. Då behöver ingen av er spendera evigheten med att alltid få felprojicerade geoobjektklasser eller för evigt vara dömd att spara dina fält i fel format. Fortsätt läsa, och få räddningen serverad på ett silverfat.

I grund och botten kan vi alla hålla med om att det är en pina att öppna datasetet ”FT_98346” i hopp om att dess innehåll ska förtälja vilken information det lagrar, och så möts man av ”343546123N” – fältet som lagrar variablerna Ja och Nej.

Jaha, då får man innerligt hoppas att vederbörande författare till datasetet fyllt i sitt metadata.

Därför rekommenderar jag att man etablerar ett system för hur man döper fältnamn. Så att man själv enklare kan tolka dess innehåll i de fall man råkar gömma det någonstans långt bak i mappstrukturen. Eller när man distribuerar datan till andra.

Att ha ett utarbetat system för namngivningen av fält underlättar för både dig och alla som jobbar omkring dig. Nyckelordet här är att vara konsekvent.

Namnge fält med stöd av prefix och suffix

En värdefull ansats till fältnamn som jag lärt mig är att tänka på dem som alla världens komplexa ord. Genom att förstå ordens prefixer och suffixer kan man förstå innebörden i det utan att ens ha hört det tidigare.

Ta ordet Arachnofobi. Fobi vet många betyder rädsla, och Arachno kan vissa kanske härleda till franska ordet araignée vilket betyder spindel. Spindelrädsla alltså.

Prefixer och suffixer är fantastiska verktyg för att kommunicera innebörd i ord, och således också information om vad för data som lagras i ditt fält.

Som med mycket annat så finns det självklart inget rätt och fel, men jag rekommenderar starkt att man bygger upp sitt eget system. Är du konsekvent blir ditt data konsekvent och konsekvent data är enklare för alla att tolka. Sen underlättar det om man förstärker det hela med lite logik. Jag ger ett par exempel på det nedan.

Skapa metodik i namngivningen som passar dig och verksamheten

För binära variabler vill jag ha suffixer som sammanfattar vilka variabler som lagras. Om till exempel statusen på ett värde är Ja eller Nej, skulle jag använda suffixen JN eller _JN (mer om versaler/gemener och understreck snart). Fältnamnet för ett fält som lagrar information om huruvida något eller någon har testats skulle då kunna heta testatsJN eller Testats_JN.

Kategoriserar jag kontinuerliga variabler såsom ålder, population eller utbildningsnivå använder jag prefixerna MA, ML, SA, SL som står för mindre än, mindre än eller lika med, större än och större än eller lika med. Alltså:

  • 3MAutb skulle betyda mindre än 3 års högre studier i ett dataset över utbildningsnivåer.
  • ML17alder skulle betyda icke myndiga personer i ett populationsdataset.
  • SA1000 skulle lagra information om hur många organisationer som har fler än 1000 medlemmar.
  • SL65 innefattar antalet personer i pensionsålder.

Testa dig fram till en best practice som fungerar för dig, din organisation och det data du arbetar med.

Var konsekvent i namngivningen

Ytterligare en aspekt att överväga är om du vill skriva fältnamnSåhär eller Fältnamn_Såhär. Det är en personlig preferens. Jag är själv helt såld på versaler/gemener. Men återigen – var konsekvent.

Ett par riktigt kända sista ord i den här branschen är personen som sammanställer ett demografidataset med många tätt relaterade attribut innan hen går på semester och tänker ”Jag kommer ihåg vilket fält som lagrar vad”. Nej, det gör du inte. Var lite logisk och döp fältet som lagrar information om antal personer i straffbar ålder som SL15. Inte som ”f6” för att det är fält nummer 6 i ordningen.

Logik i fältnamngivningen effektiviserar

Det leder mig till nästa argument: logik i fältnamngivningen gör det enkelt för den som ska använda ditt data. Framförallt när denne ska skriva uttryck av olika slag.

Om alla fält som lagrar en timlönen i olika branscher börjar på ”tL” så kan till exempel multiplicera alla dessa med 40 för att kunna jämföra veckolönen i de olika branscherna utan att behöva gå igenom hela datasetet för att hitta de fält som lagrar den här informationen.

I det här datasetet kan man enkelt peka ut alla fält med prefixen tL för att analysera timlöner, eller alla med prexifen mL30 för att analysera antalet unga i branschen (åldern är mindre eller lika med 30).

I det här datasetet måste man specificera alla enskilda fältnamn för att kunna analysera timlönen eller antalet unga i branschen.

Förstärk innebörden i ett fältnamn med fältalias

Men nu säger ni: ”Det är ju enklare att tolka ungaAnstTillv än mL30Tillv…?” Ja, ni har säkert rätt, men jag har två invändningar.

Man kan nyttja den fantastiska funktionen fältalias för att förstärka innebörden i det fältnamn som lagras i databasen. I det här fallet kanske jag skulle komplettera mL30Tillv med fältaliaset Antal anställda under 30 år, tillverkningsindustrin. Fältalias är nämligen mycket mer generösa med antal tecken och specialtecken. De hänger dessutom med när man publicerar upp till portalen.

Min fältaliasälskande kollega ville också tipsa er om att det mest effektiva sättet att skapa upp alias är att göra det direkt i databasen. På så sätt följer det med kontinuerligt med genom hela plattformen.

Min andra invändning är att jag har fokuserat på att skapa korta, koncisa och uttrycksvänliga fältnamn som ligger i linje med mitt arbetssätt och mitt utarbetade system som jag och de som jobbar med mig förstår. Ni får göra detsamma för er, det är ett kul projekt. Ett tips är också ett sätta upp en liten ordlista med just dina prefixer och suffixer.

Lycka till och döp inte ett fält till något jag inte skulle döpa det till!

Lästips: