En genomgång av förändringarna som kommer ske i och med flytten till Marknadsdatabasen 2. Ta en kopp kaffe, detta är en lång text!
I vår så kommer vi uppdatera Marknadsdatabasen till version 2 där den största förändringen är anpassningen till SSNF's adress-standard. Här är en matig genomgång av vad det kommer innebära.
Vi kan börja med att länka till nuvarande Marknadsdatabas specifikation och sedan kan ni jämföra den med Marknadsdatabasen 2-specifikationen
MdB2-specifikationen är en sammanslagning av SSNF's adress-standard samt de fält som är unika för just Marknadsdatabasen. Fältnamn och Fältnamnsstandard har också anpassats för att vara enhetligt.
Här ser vi hur MdB och MdB-specifikationerna hör ihop fältmässigt. De gröna pilarna är de fält vars data mer eller minde kan föras över som dom är, medan de orange fälten avser data som måste förändras eller översättas på något vis.
accessID
Det första fältet är "socket" som byter namn till "accessID", och går från att vara frivilligt till att vara obligatoriskt.I dagsläget så har 28% av alla adresserna i Marknadsdatabasen inget värde i "socket" så vi utgår från att detta kommer bli ett problem för en hel del av våra kunder. Tjänsteleverantörerna kommer bli väldigt glada dock.accessID kan vara max 36 tecken långt och kan enbart innehålla specifika tecken, enligt specifikationen.
type
Nästa fält är "type", som byter namn till premisesType, och de sex olika värdena som den kan ha i MdB byter till fem olika värden i MdB2, varav enbart tre är av egentligt intresse för oss.
propertyUnitDesignation
"building" byter namn till "propertyUnitDesignation", ska max vara 67 tecken långt och följa Lantmäteriets standard för fastighetsbeteckningar, samt blir obligatoriskt. För framtida synk-funktioner mellan MdB2 och Anslutamotorn så kan detta givetvis leda till problem där MdB2 har större krav på fastighetsbeteckningens format.
media
Värdena i "media" kommer byta från fyra möjliga till tre som är relevanta för Marknadsdatabasen. Det här fältet avser fortfarande medium till kundutrustningen, inte till kundens switch.
services
Det här fältet ska innehålla komma-separerade "nyckelord" som avser vilka typer av tjänster som kan beställas på porten. Detta är en kombination av "capacity"-fältet och tv-fältet. Notera dock att både capacity och TV-information kommer ha egna fält.
coCpe
Två av MdB-fälten, "cpe" och "cpetype" slås ihop till ett nytt fält som heter "coCpe" som innehåller samma information.
openTv, cableTv, exclusiveTv
"tv"-fältet bryts ut till tre olika fält som avser de tre olika leveranssätten för TV, Öppen-TV, Leverantörslåst TV samt kabel-TV. Värdet i fälten avser samma som det gamla tv-fältet.
Ny struktur
I och med flytten till MdB2 så kommer Marknadsdatabasen genomgå en grundläggande strukturförändring. Historiskt sett så har Marknadsdatabasen laddats upp som en CSV-fil av admin som sedan lästs in i en databas med samma kolumner.Nackdelen med detta är ju att om man vill redigera till exempel en felstavad adress eller fastighetsbeteckning så måste man ändra på tio, tjugo eller femtio rader i databasen.
Med ett mer utbrett användande av API:er, samt större behov av manuell hantering av databasen så har vi valt att dela upp databasen i mindre delar. Så vi har en databas för alla era fastigheter, en för alla adresser som är knutna till en fastighet, en för alla lägenheter/lokaler som är knutna till en adress, samt slutligen en databas för alla uttag som i sun tur är knuten till en lägenhet/lokal samt adress.
Här är en illustration för att tydliggöra hur uppdelningen sker. Över i bilden ser ni "in-datat" så som de flesta av er känner igen det, som en Excel-fil med kolumner där mycket data repeteras. Sedan under de olika databaserna och de poster som skapas i dem. De rödmarkerade fälten är de interna ID posterna får i databasen och visar på hur dom hör ihop relationsmässigt.
Fastigheter
Den "blåa" databasen är fastighetsdatabasen, och i Excel-vyerna så ser du vilket data som blir en post i den här databasen. Så "Skeden 1" finns bara i databasen en gång.Adresser
I in-datat så finns det sammanlagt tre olika adresser, så det skapar tre poster i adress-databasen, alla tre är kopplade till id 1 i fastighetsdatabasen via en databasrelation.Lokaler
Och slutligen så har vi åtta olika lägenheter, som alla hör till samma fastighet och till tre olika adresser, färgkodat i den här illustrationen.Uttag
Fördelningen av uttag är densamma, med kopplingar till både vilken adress, lägenhet och fastighet dom hör.Sökningar
Här ser vi ett exempel på när man då söker på en adress i databasen. Till exempel Granvägen 1A. Vad som händer då är att vi kan automatiskt hämta all relaterad information om detta eftersom vi har dessa relationer. Så granvägen 1A har tre lägenheter, tre uttag och en fastighet, vilket då resulterar i tre rader i sökresultatet
Uppdateringar
Det som är riktigt smidigt dock är att om vi går in i fastighetsdatabasen och uppdaterar fastighetsbeteckningen till "Matskeden 4" och sedan uppdaterar vi gatunamnet i adressdatabasen till "Grenvägen" så betyder det att alla poster i en resultatlista automatiskt får det nya datat, så vi slipper redigera massor av poster som alla har samma data i vissa fält.
Komplett vy
Här ser du en översiktsbild på hur en post från specifikationen är uppdelad i de olika databaserna
Admin-gränssnitt
Den här uppdelningen kommer också vara tydlig i Admin, där varje databas är en egen modul med relationer mellan dem. När du går in och redigerar en adress till exempel så ser du vilka lägenheter och uttag som är bunden till den posten, samt vilken fastighet den hör till.
