Informationsmodellering: Om namngivning

Hur ska vi namnge alla de element i en informationsmodell som representerar verksamhetsbegrepp?
När vi tar fram en informationsmodell för en verksamhet eller en tjänst behöver vi besluta om namn för många olika saker. Det är inte bara entiteter, attribut och relationer som ska han namn utan också de specifika attributvärdena i det fall de utgör ett bestämt värdeförråd för något attribut. Alla dessa är verksamhetsbegrepp och bör ges korrekta och tydliga namn. Vad ska vi tänka på då? Vad är ett bra namn? Och hur gör vi med de namn som redan är etablerade på olika sätt i verksamheten, men kanske inte så lämpliga alla gånger? 

Begrepp har namn och definition

Varje element i en informationsmodell, vare sig det är en entitet, ett attribut, en relation eller ett visst attributvärde, representerar en företeelse för vilket vi behöver ett namn.
Ibland handlar det om en helt ny företeelse i denna verksamhet men oftast om något som redan finns. Ett begrepp har två viktiga aspekter som bägge behöver uttryckas i naturligt språk. Dels behöver vi ta fram en korrekt och tydlig definition för att ringa in betydelsen, och dels behöver vi ett bra och tydligt namn.
Det kan till exempel vara att vi erbjuder våra kunder olika varor eller tjänster. Namnet vi bestämmer blir kanske ”Produkt”, och definitionen blir ”Det vi erbjuder våra kunder”.
Märk att det inte är själva namnet ”Produkt” som är begreppet i fråga utan det som namnet och definitionen står för. Namnet ”Produkt” är som ett handtag, en symbol eller ett tecken med vilket vi kan framkalla begreppet i våra hjärnor.

Om synonymer

Vi kan använda ett annat namn för samma begrepp (”Produkt”). Vi kan till exempel säga ”Vara”, ”Artikel” eller uttrycka oss på engelska och säga ”Product”, och ändå mena samma begrepp. Det kallas synonymer när ett och samma begrepp har flera namn. Det kan också finnas homonymer. Det är att ett och samma namn har flera betydelser.

Vad är ett bra namn?

Ett bra namn ska vara korrekt, det vill säga så tydligt som möjligt peka på betydelsen hos det begrepp man vill använda namnet för. På sätt och vis fungerar det då som en liten definition i sig. Idealet är att man direkt förstår vad som menas och vad som inte menas. Åtminstone om man har lämplig förförståelse, som en allmän kunnighet om området i fråga. Namnet får inte ha en för bred betydelse och inte heller för snäv.

Vikten av bra namn

När vi sätter namn på detta sätt bygger vi de facto verksamhetens språk. Det är svårt att tänka sig en mer central och ansvarsfull uppgift som vi som modellerar kan ha. Med en korrekt och tydlig terminologi blir all kommunikation tydligare, i varje interaktion och integration. Risken för oklarhet och missförstånd minskar i varje punkt.
Men det finns också en annan minst lika tung aspekt som man kanske inte alltid tänker på. Vi använder språk inte bara för att kommunicera utan även för att tänka. Med en rik och tydlig vokabulär kan vi tänka klarare, både som individer och som grupp.

Råd för namn i informationsmodeller

Här följer ett antal saker att tänka på då vi bestämmer namn:

• Förkorta inte 
  Jag anser att man i det längsta bör undvika förkortningar i de namn man sätter. Dels ökar det risken för misstolkning, och dels blir det en extra börda att hålla reda på alla förkortningar. Ty vi vill ju vara konsekventa så en term alltid förkortas på samma sätt överallt. Undantaget är några få mycket allmänna och etablerade förkortningar som ”SEK”, ”kg” etcetera.
• Låt namnet uttrycka den fulla betydelsen 
  Om ett attribut heter ”Vikt” kan det förr eller senare bli osäkert i vilken viktenhet som avses.
  Ändra till ”Vikt – kg”.
• Använd verksamhetens språk 
  Det vill säga svenska i helsvenska verksamheter och engelska i verksamheter som ser sig som mer internationella. Det är ju verksamhetens språk vi normerar, inget annat.Inom it-utveckling har det vuxit fram en informell standard att skriva namnen på programkonstrukter som moduler, klasser, metoder och variabler med mera samt även kommentarer på engelska. Därför tror ibland it-utvecklare att man ska skriva även verksamhetsbegrepp på engelska, även i det fall där verksamhetsspråket är svenska. Eftersom man vill vara konsekvent händer det också att engelskan fortplantar sig till andra sammanhang som rapporter med mera.Därför ser man ibland amatörmässiga och ofta helt missvisande försök till engelsk översättning av svenska facktermer.
  Jag menar att verksamhetstermer alltid ska vara på verksamhetens språk och det bör vara konsekvent överallt. Alltså även i programkod, databaser och filer, som ju är en integrerad del av verksamheten.
• Använd naturligt språk 
  Det innebär till exempel att man använder både versaler och gemener samt blanksteg.
  Det förekommer annars att man i it-funktioner är påverkad av det skrivsätt som blivit standard i programkod på grund av att man där är begränsad till sammanskrivning av ord, så kallad ”Camel Casing”. Man skriver ”numberOfPieces” i stället för ”Number of pieces”. Men det finns alltså ingen anledning att tillämpa det skrivsättet utanför programkod.

Hur gör vi med redan etablerade men dåliga namn?

Det händer ofta att man sedan tidigare har namn i databaser och i system som är felaktiga och missvisande. Då kan det kännas som att vi i konsekvensens namn behöver fortsätta att använda de namnen. Namn har en tendens att bita sig fast väldigt hårt.
Men en dålig terminologi hämmar en verksamhets möjligheter framgent. Vår hållning måste vara att vi tar språk på allvar och att vi tar vårt ansvar. Vi kan inte bara fortsätta att propagera fel bara för att de en gång har uppstått. Vi behöver rätta till felen, även om det känns jobbigt för stunden. Vi behöver ju kontinuerligt vårda och utveckla verksamhetens terminologi.
Men om vi bara byter en term mot en annan, vet ingen vad vi menar med den nya termen. Förvirringen blir stor, man kanske tror att det är ett nytt begrepp, och inte ett nytt namn på ett befintligt begrepp.
Vi behöver hantera detta på ett ansvarsfullt sätt, det vill säga rätta till felaktigheter utan att ändringen skapar onödig förvirring. Det går till så här: I informationsmodellen anger vi det namn vi gemensamt kommit fram till är bäst, utan hänsyn till de misstag som har gjorts tidigare. Samtidigt anger vi i informationsmodellen det gamla etablerade namnet som en synonym som förekommer i verksamheten.
På så sätt får vi en spårbarhet från den äldre termen till den nyare. Våra informationsmodeller blir på så sätt på samma gång deskriptiv (beskriver befintligt språkbruk i verksamhet och it-system) och normerande (beskriver vad vi kommit fram till att det korrekta språket bör vara).

Exempel

Jag vill här visa exempel på hur det kan se ut i en informationsmodell. Detta är ett utsnitt från ett ER-diagram som visar en entitet med många attribut. I det följande beskriver jag de olika delarna av diagrammet.

• Entitetens namn: ”Företagskonkurs – Statushändelse”
  Fetstil för att lyfta fram namnet, tydligt utskrivet och med versaler och gemener. Namnet är valt för att så tydligt som möjligt förmedla vad en förekomst av entiteten står för.
• Källa för informationen: ”BLV (Daglig avisering via Bisnode)”
  Anger källan för informationen (BLV står för Bolagsverket). I detta fall hade vi många olika informationskällor och det var viktigt att lyfta fram dessa, därför rött typsnitt.
• Entitetens definition: ”Händelsen att en företagskonkurs fått en ny status”.
  Försöker ge en så bra definition som möjligt för en förekomst av entiteten. Mörkgrått typsnitt för att tona ner uppgiften i förhållande till entitetens namn.
• Grupprubriker för attribut: ”Identitet”, ”Typ av statushändelse” etc.
  Vi har strävat efter att ordna (sortera och gruppera) attributen i en ordning som känns naturlig och meningsfull. Detta är ett enkelt grepp för att öka modellens läsbarhet och begriplighet. Grupprubrikerna är mörkblå för att skilja ut dem från attributnamnen.
• Attributnamn
  Vi har valt namn som försöker att ge en fullständig och tydlig betydelse. Logisk datatyp är med på många ställen som suffix. Vi har inte varit rädda för att skriva ut även långa namn och namn i flera led då det ökat tydligheten.
• Teknisk datatyp och fältlängd: ”chr 1”, ”int”, ”dat” ”dat tid” etc.
  Skrivet i blått. Viktigt för att tolka data rätt.
• Markering för obligatoriska attribut: ”obl”
  Behövs också för att tolka data rätt.
• Fysiska fältnamn: ”PRIMARYKEY” ”KODFORDOMSTOLSOMUPPHAVTKONK” etc.
  Detta är vad attributen i fråga råkar heta i it-systemet, och som vi idag inte kan ändra. Detta är en typ av synonymer. Vi har använt ett grått typsnitt för att tona ner dessa i förhållande till de normerande attributnamnen. Det är viktigt att ha med fysiska namn för att få en spårbarhet till fysiskt data. Om vi inte har med dessa så blir det som att vår modell ”hänger i luften” utan koppling till en fysisk verklighet.

Användning av namnen i informationsmodellen

I de flesta sammanhang jag jobbat har vi på detta sätt använt informationsmodellen som en normering av den gemensamma terminologin i hela verksamheten. De namn vi satt är de som vi vill ska användas genomgående, som verksamhetens gemensamma språk. Det kommer dock att finnas synonymer alltjämt. Man kan inte bygga om alla rapporter och system bara för att vi har infört normerade begrepp.
Vi dokumenterar alla synonymer vi stöter på och i vilket sammanhang de förekommer. Men i allt nytt som görs kommer denna nya standardiserade terminologi att användas.

Namn i programkod, databaser och filer

Det är viktigt att detta normerade språk används i alla sammanhang. Många tror att man i programkod och liknande kan ha ”tekniska namn” som är annorlunda. Det är inte bra. Det ökar friktionen i kommunikationen. Jag menar att det är ett arv från den tiden då namn behövde vara korta och endast i versaler i programkod och databaser, av tekniska skäl. Så är inte fallet längre, i något sammanhang tror jag. Det man kan behöva göra det är en viss transkribering av namnen för de tekniska sammanhang där man inte har samma teckenuppsättning. Jag brukar då göra den transkriberingen redan i informationsmodellens textdel.

Transkriberingsmetod

Den transkriberingsmetod vi då väljer bör vara den som gör minsta våld på namnen och har störst läsbarhet. Den metod vi har valt ofta är följande:

• Ersätt Å, Ä med A, liksom å och ä med a.
• Ersätt Ö med O, liksom ö med o
• Ersätt blanksteg med understreck ”_”
• Ersätt bindestreck med understreck ”_”

”Konkurs avslutad – datum” blir då ”Konkurs_avslutad_datum”
Denna metod har en tradition inom databasdesign, vilket är en fördel.
Det finns dock en annan transkriberingsmetod som kommer från programvaruutveckling. Den kallas för ”Camel casing” eller mer anekdotiskt för ”Hungarian C”. Den består i att man använder versaler endast för att avdela mellan ord.
”Konkurs avslutad – datum” blir då ”konkursAvslutadDatum”.

Jag menar att den första metoden är att föredra och detta av tre skäl:

1. Metoden gör inte onödigt våld på namnet. Läsbarheten är bästa möjliga.
2. Versalerna har samma funktion som före transkriberingen.
3. Metoden har en tradition inom databasutveckling vilket ligger kulturellt och historiskt närmare informations- och databehandling än programvaruutveckling.

Hur gör ni?

Vad sägs om detta? Hur gör ni i er verksamhet?