Databasestøttet Mini CRM system. Bachelorprojekt. Christian Gerner Schmidt, s031996. 8. juni 2009 IMM DTU

Databasestøttet Mini CRM system Bachelorprojekt Christian Gerner Schmidt, s031996 8. juni 2009 IMM DTU Side 1 af 40

1 Introduktion...4 Summary...4 Indledning...4 2 Analyse...5 2.1 Identifikation af de væsentligste problemer...5 2.2 Gennemgang af Access-databasen...6 Forklaring til felterne...6 2.3 KLS arbejdsgange...7 Baggrund...7 Specifikation...8 2.4 Tingene rundt om...8 Et Kig på ForeningPro...8 Lovgivningen...9 2.5 Brugergrænseflade...11 2.6 Løsningsforslag...11 Databasen...11 Brugergrænseflade...11 Kommunikationen imellem database og brugergrænseflade...12 Synkronisering med medlemsdatabasen...12 3 Design af databasen...13 Normalisering...13 3.1 ER-diagram over databasen...13 Gennemgang af ER-diagrammet...13 3.2 Synkronisering med medlemsdatabasen...18 3.3 Import af data til den nye CRM-database...18 3. 4 Dubletsøgning...19 3.5 Eksport af data fra databasen...20 3.6 Sikkerheden for databasen...20 3.7 Design af Stored Procedures...20 3.8 Design af webinterface...21 Lav udtræk...21 Søg og redigér i databasen...22 Se Statistik...23 Præferencer...23 4 Implementering af databasen...24 4.1 Fra ER-diagram til Relationsdatabasemodellen...24 4.2 Oprettelse af databasen i T-SQL...26 Navnestandarder og andre valg...26 4.3 De ikke-trivielle tilfælde...27 Primary Keys...27 Materialer_El.Sam og Materialer_Sk.Sam...27 3. Normal Form...27 Cascade...27 4.4 Stored Procedures...28 4.5 Import af data til databasen...28 Side 2 af 40

4.6 Dubletsøgning...29 4.7 Synkronisering og eksport...30 4.8 Webinterface...30 5 Test...31 Test 1: Simpel INSERT og DELETE i Lokationer...31 6 Konklusion...32 7 Litteraturliste...33 8 Bilag...34 Bilag 1: ER- Diagram...34 Bilag 2: Webinterface design Lav Udtræk...35 Bilag 3: Webinterface design Vis Udtræk...36 Bilag 4: Webinterface design Søg og redigér i databasen...37 Bilag 5: Webinterface design Se statistik...38 Bilag 6: Webinterface design Indstillinger...39 Bilag 7: Opsætning af databasen...40 Side 3 af 40

1 Introduktion Summary This project is about the development of a new mini CRM database for the union DJØF, customized for the specific requests and needs of a single user. The user requests leads to a broad range of requirements for the new CRM database, as it should import the data from the existing CRM database, recieve updated data from DJØF s union member database, deal appropriately with legal issues, and furthermore a new graphical user interface is requested, to access the database. Through the analysis of these requirements, a solution that meets the requirements are designed and partially implemented. Indledning Personligt har jeg altid synes de store projekter var de sjoveste, og det er helt sikkert også noget af bevæggrunden for at jeg valgte dette projekt, selvom det har stået klart fra begyndelsen at det ikke ville blive færdigt. For det som har kendetegnet dette projekt, eller denne opgave, er at den har spredt sig ud på mange områder, og så har udfordringen været at samle det hele til ét produkt. Det er også lykkedes at designe et komplet produkt, som overholder alle målene og samtidig er en meget enkel løsning. Til gengæld mangler der en hel del implementering, men det var kendt fra start, og det er derfor i stedet vist hvordan det kan komme til at fungere. Side 4 af 40

2 Analyse 2.1 Identifikation af de væsentligste problemer Kirsten Lykke Simonsen, KLS, arbejder i Danmarks Jurist og Økonom Forbund, herefter DJØFs Marketingsafdeling, hvor hun hyppigt anvender samt vedligeholder en CRM 1 -database. Databasens formål er at indeholde alle de personer, som det er relevant for DJØF at markedsføre sig overfor. Disse er en blandet skare, da DJØF både har nogle mere almene produkter, f.eks. kurser indenfor forhandlingsteknik i en lønsituation, samt nogle mere fagspecifikke, som f.eks. brush-up i lejeret for erhvervsjurister. Derfor opstår behovet for at kunne inddele og søge de personer, der er i CRM-databasen efter mange forskellige kriterier, eksempelvis branche, titel eller geografisk placering. Dataene i databasen er hentet fra flere kilder, primært fra DJØFs medlemsdatabase, ForeningPro, men også fra markedsdata som er købt ude i byen, samt manuelt tilføjede data, hovedsageligt hentet fra virksomheders hjemmesider. Det, at der er importeret fra flere kilder, har skabt et problem med dubletter i databasen. Derudover er der et problem med at databasen nu er svær at holde opdateret på grund af mængden af data, men også fordi nogle kilder var dårligt opdaterede fra start. Selvom ForeningPro-dataene holdes opdateret i ForeningPro, og disse udgør en væsentlig del af de samlede data i CRM-databasen, så er der ingen synkronisering imellem de to databaser. Dertil kommer at CRM-databasen i dag er udformet som én stor tabel i Access, hvilket KLS ønsker sig anderledes. Men da hun ikke har forudsætningerne for at arbejde med databaser og samtidig er alene om at vedligeholde den, er der ikke sket så meget. Derfor ønskes der en ny brugergrænseflade som er målrettet specifikt efter KLS behov. Når KLS har lavet et udtræk fra databasen med personer/virksomheder, der er udset til at modtage et givent produkt, materiale, opstår et nyt problem. Der sendes (forskelligt) materiale ud til de samme personer indenfor kort tid, da der ikke er mulighed for at filtrere dem fra, som har fået materiale tilsendt for nylig. Problemet forværres af, at der internt i DJØF er flere afdelinger, der udsender materiale uafhængigt af hinanden, og derfor er det højt prioriteret opgave i DJØF at undgå at spamme 2. Så selvom løsningen udelukkende skal tilpasses KLS behov, vil det være hensigtsmæssigt hvis databasen kunne have flere samtidige brugere. KLS ønsker sig også noget statistik i form af succesrate ved udsendelse af reklamemateriale, og at kunne gemme en udtræks skabelon, der først skal bruges lang tid senere, sådan at disse udtræk er opdaterede når man genåbner dem. 1 Customer Relations Management 2 Se vedlagte organisations diagram i CDROM-Bilag A. Både DJØF Efteruddannelse, DJØF Netværk, Medlemsadministrationen og Karriere og Kompetence udsender marketing relateret materiale. Side 5 af 40

Endelig ville det være rart at kunne gemme emailadresserne på personer, der ønsker at modtage mails fra DJØF indenfor specificerede temaer. 2.2 Gennemgang af Access-databasen Databasen består af 62.361 rækker med følgende 26 kolonner: Navn Type Værdier ID int Primary Key (unik), Not Null, {1,2,, 85129} Firma string Not Null, mange forskellige værdier Afdeling string Null, 2817 rækker med mange forskellige værdier Titel string Null, 45207 rækker med mange forskellige værdier Navn string Null, 57272 rækker med mange forskellige værdier Adresse1 string Null, 54228 rækker med mange forskellige værdier Adresse2 string Null, 5816 rækker med mange forskellige værdier Postnummer int Null, 54226 rækker med mange forskellige værdier By string Null, 54214 rækker med mange forskellige værdier Medlem string Null, 21528 rækker med {"Ja","Nej","v"} Branche string Null, 52464 rækker med mange forskellige værdier Kursus katalog int Null, 495 rækker med {0,..,45} TR int Not Null, {0, -1} Land string Null, 214 rækker med værdier: "Økonomi", "Belgium", Tidligere deltaget på kursus i string Null, 1195 rækker med mange forskellige værdier Ledelse string Null, 1711 rækker med mange forskellige værdier Coaching string Null, 1 række med "Personale" Projektledelse string Null, 17 rækker med mange forskellige værdier Organisation string Null, 65 rækker med mange forskellige værdier Kommunikation string Null, 100 rækker med mange forskellige værdier Jura string Null, 698 rækker med mange forskellige værdier Økonomi string Null, 142 rækker med mange forskellige værdier Konference string Null, 151 rækker med mange forskellige værdier Al Reklame int Not Null, {0,-1}, 2 rækker med -1 Ingen Reklame int Not Null, {0,-1}, 259 rækker med -1 Antal ansatte string Null, 23036 rækker med mange forskellige værdier: "Uoplyst", 0, 53, "500-999", Forklaring til felterne Kigger man på feltet ID-nummer, så er dette nummer autogenereret af Access og fungerer udelukkende som Primary Key, dvs. det er ikke en kolonne KLS har brug for fremover. Firma derimod indeholder navnet på firmaet, og tilsvarende for afdeling. Så er der eksempelvis 10 personer i tabellen fra en given afdeling i et givent firma er firmaet og afdelingen gentaget 10 gange i tabellen, en for hver person. Feltet Titel indeholder enten uddannelse, titel eller begge dele, for den pågældende person, der arbejder i firmaet, denne persons navn er angivet i det næste felt, Navn. Adresseinformation bliver gemt i feltet Adresse1, og når der er behov for 2 linjer tages Adresse2 også i brug. Eksempelvis står der i Adresse1: Anker Engelundsvej 1 og i Adresse2: 101 A. Således udgør Adresse1, Adresse2, Postnummer og By den Side 6 af 40

fulde adresse for afdelingen, hvis en sådan eksisterer, ellers for firmaet. Det er aldrig personens privatadresse, der står i feltet. Medlem angiver om personen er medlem af DJØF med henholdsvis Ja eller Nej. Branche angiver firmaets branche, ud for DTU står der eksempelvis Universitet/Højere uddannelse. Feltet Kursus katalog angiver det antal kursuskataloger firmaet ønsker. TR-feltet bliver ikke brugt, så det kan ignoreres helt (angiver om personen er tillidsrepræsentant). Land angiver landet tilknyttet adressen, og feltet Tidligere deltaget på kursus i, indeholder navnet på et eller flere kurser personen har deltaget i. Herefter kommer inddelingen i kategorier, henholdsvis Ledelse, Coaching, Projektledelse, Organisation, Kommunikation, Jura, Økonomi og Konference, som også er de 8 kategorier alle kurser i kursuskataloget 3 er inddelt i. I selve feltet står der en underkategori, eksempelvis Arbejdsret under Jura. Al Reklame er til folk, der ønsker at modtage alt marketingsmateriale DJØF sender ud og Ingen er dem, der intet ønsker at modtage. 2.3 KLS arbejdsgange Baggrund En af DJØFs væsentlige indtægtskilder er at udbyde og arrangere kurser som man kan betale for at deltage på. En typisk pris for et kursus på 1 dag fra 9 til 16 kunne være 5000 kr. ekskl. moms. Det er afdelingen DJØF Efteruddannelse, der står for at oprette kurser og administrere tilmeldinger dertil, og de opretter alle kurser i ForeningPro. Herefter bliver kurserne udbudt på 2 måder; de bliver lagt op på hjemmesiden 4 og de fremgår af kursuskataloget som bliver udsendt hvert halve år. Mangler et kursus mange deltagere, beder Efteruddannelsen KLS om at finde nogle personer i ForeningPro som tidligere har deltaget i lignende kurser og sender et brev med markedsføring af det pågældende kursus. Hvis det ikke skaffer tilstrækkeligt med deltagere prøver KLS derefter i sin CRM-database, at finde nogle nye personer, kursusmaterialet kan blive sendt til. Det KLS har at gå ud fra når der skal laves et udtræk fra CRM-databasen, er et kursusnavn og en kursuskategori evt. med underkategori, samt en liste med personer, der ikke skal have tilsendt materialet fordi de enten er meldt til eller fra kurset, eller allerede har modtaget materialet. Det er dog ikke hver gang KLS bliver bedt om at lave et udtræk, at der er personer, der skal filtreres fra. I perioderne imellem der skal laves udtræk opdaterer KLS CRM-databasen. Det består dels af fjernelse af dubletter, som er et stort problem. Især fordi de kan være svære at identificere, da 2 personer godt kan hedde det samme, og der således ikke kan konkluderes om den ene er en dublet medmindre rækkerne er helt ens. Men ellers, når der opdateres gøres det ved at gå på internettet, eventuelt firmaets hjemmeside og opdatere databasen ud fra det. Det hænder også at folk mailer KLS for at få rettet i deres data. 3 Se CDROM Bilag B 4 http://www.djoef.dk/djoef-efteruddannelse/kurseroguddannelser.aspx Side 7 af 40

Specifikation Når KLS er i gang med at lave udtræk, er nøglefunktionerne brancher, kategorier, antal fordelt på brancher, antal fordelt på kategorier og antallet markeret/i udtrækket. Der arbejdes ud fra at udtrækket skal ende på et på forhånd fastlagt antal. Når udtrækket så er færdigt, skal det enten gemmes til senere brug, eller eksporteres. Ved eksport, eksporteres kun virksomhed, afdeling, titel/uddannelse, navn, adresse, og det eksporteres til Excel 2003-formatet *.xls. Herefter bliver det flettet ind i et Word-dokument vha. Words brevflet-funktion, og til sidst printet. Når der fjernes dubletter søges der efter personer hvor navnene ligger tæt op af hinanden, og ud fra en visning af alle personens data, inkl. Relationer vurderer KLS om personen skal slettes. Ved manuel tilføjelse eller opdatering af data er det typisk 1 række ad gangen, der opdateres. Ved import af data modtages dataene altid i Excel-format, og efter formateringen er tilpasset i Excel, importeres dataene. 2.4 Tingene rundt om Et Kig på ForeningPro ForeningPro består af en Informix SQL-database, der anvendes gennem en lokalt installeret applikation. Da databasen er ret omfattende er det følgende kun et udsnit af hvad den indeholder. Alle personer i ForeningPro har et unikt medlemsnummer som anvendes som primary key. Derudover haves for alle aktive medlemmer også fulde navn, privatadresse, uddannelse/titel, emailadresser, og relationer til kurser de har været på samt hvilken virksomhed de er ansat i og dennes branche. DJØF har også et abonnement hos CPR, som betyder at CPR kender alle DJØFmedlemmer, og når et medlem skifter adresse, sender CPR de nye data til ForeningPro, således at medlemsdatabasen er fuldt ud opdateret. Det er meningen at virksomheder på tilsvarende vis skal vaskes op imod CVR-registret, men denne funktion er endnu ikke implementeret. Derudover er det værd at nævne at det ikke kun er DJØF-medlemmer der er oprettet i ForeningPro, men også alle, der har deltaget i et DJØF-kursus, som automatisk bliver oprettet. Alle kurser i DJØF er også oprettet i ForeningPro med et unikt kursusnummer, en startdato og slutdato, et navn og evt. en kategori. Derudover er der en relation til de personer som er tilmeldt kurset. Der er også en kampagne -funktion til at udsende materiale til mange personer. Side 8 af 40

Så overordnet set har ForeningPro de funktioner KLS mangler, ulempen er bare at ForeningPro-databasen kun er for personer, der har en eller anden tilknytning til DJØF, og det har alle i CRM-databasen ikke, formålet med den er jo i høj grad at finde potentielle nye medlemmer. En eksport af data til ForeningPro, således at der kun skal arbejdes i ForeningPro kan derfor udelukkes. Alternativt kunne man lave de samme udtræk både i ForeningPro og CRMdatabasen, men her opstår også en række problemer. Virksomhedsoplysningerne, altså navn, adresse, cvr-nummer og branche, samt relationen, der angiver hvilke personer, der er ansat hvor, er så dårligt opdateret, at KLS ikke ønsker at anvende dataene. Derudover er det essentielt for KLS at kunne ændre i persondataene, da de oplysninger, der skal stå udenpå kuverten med materiale ikke nødvendigvis skal stemme overens med dem i CPR-registret. Det sker eksempelvis at personer kontakter KLS for at få ændret titel eller navn, da de ønsker noget andet end de egentlige oplysninger skal fremgå udenpå det materiale, der bliver sendt til deres virksomhed. Tilsvarende har KLS også behov for at kunne ændre i de virksomhedsbrancher som ForeningPro har fra CVR-registret, da de ikke egner sig godt nok til KLS søgninger. Konklusionen er derfor at hverken dataene eller funktionerne i ForeningPro dækker KLS behov i tilstrækkelig grad, uden at der skal laves udvidelser til ForeningPro, og det er der ingen grund til når den samme funktionalitet alligevel skal laves i CRMdatabasen for de personer, der ikke er i ForeningPro. Til gengæld er der data i ForeningPro som med fordel kan anvendes i CRM-databasen, og det vil derfor være en fordel enten løbende at opdatere CRM-databasen med data fra ForeningPro eller oprette en forbindelse til ForeningPro så de kan tilgås direkte. I forbindelse med ForeningPro bør det nævnes, at databasen står overfor at blive udskiftet med en større softwareløsning som er under udvikling ca. 1 år endnu. Selvom alt ikke er på plads endnu, står det dog klart at den nye database heller ikke vil indeholde personer, der ikke er medlemmer af DJØF eller har været på kurser i DJØF, og at den vil være baseret på Transact-SQL. DJØF vil derfor, også efter denne softwareløsning er kommet i produktion, have et behov for en CRM-database. Lovgivningen Under udarbejdelsen af dette projekt har det været nødvendigt at undersøge lovgivningen på området, helt konkret persondataloven og markedsføringsloven, for at sikre, at den CRM-database, der skal udvikles holder sig indenfor loven. Det følgende er ikke eksakte uddrag af lovene, men mine omformuleringer af de paragraffer, der har relevans for projektet. Side 9 af 40

Ifølge persondataloven 5 må man ikke behandle personfølsomme data i en elektronisk database uden personens samtykke, og for DJØFs CRM-database er: cpr-nummer betragtet som personfølsomt data navn, adresse, DJØF medlemsnummer, DJØF-kurser deltaget i samt dato for deltagelse på kursus betragtet som ikke personfølsomme data I den forbindelse er der for nuværende medlemmer givet samtykke, men for andre personer i ForeningPro-databasen, dvs. kursister og tidligere medlemmer, er der ikke givet samtykke. Ifølge markedsføringslovens 6 6 om uanmodet henvendelse til bestemte aftagere gælder det at: Man må kun rette uanmodet henvendelse per brev til en person på dennes privatadresse, hvis personen tidligere har købt en vare eller en tjenesteydelse. Man må godt rette uanmodet henvendelse per brev til virksomhedsadresser Man må ikke rette uanmodet henvendelse til en person, der har frabedt sig det direkte overfor DJØF eller er på CPRs Robinsonliste 7, som tilgås via cprnummeret. Der må ikke rettes uanmodet henvendelse til nogen via elektronisk post. Hvis en person giver samtykke til at modtage elektronisk materiale skal det i samtykkeerklæringen være specificeret hvilken type materiale man giver samtykke til, eksempelvis økonomi-kurser og ikke bare kurser generelt. Så mht. indsamling af CPR-nummer så skal det vides hvad personen har givet samtykke til før det kan anvendes i CRM-sammenhæng, og det kan i praksis være svært at definere klart. Derfor er det uhensigtsmæssigt at opbevare CPR-numre på ikke-medlemmer. 5 LOV nr 429 af 31/05/2000 med følgende ændringer LOV nr 280 af 25/04/2001 7, LOV nr 552 af 24/06/2005 6, LBK nr 158 af 09/03/2006, LOV nr 519 af 06/06/2007 2 samt LOV nr 188 af 18/03/2009 med populærtitel Persondataloven. På www.datatilsynet.dk er der en forklaret udgave af persondataloven. 6 LOV nr 1389 af 21/12/2005 med følgende ændringer LOV nr 538 af 08/06/2006 102, LBK nr 1000 af 05/10/2006, LOV nr 1547 af 20/12/2006, LOV nr 181 af 28/02/2007 4 samt LOV nr 364 af 13/05/2009 7 med populærtitel Markedsføringsloven. På forbrugerstyrelsens side, www.forbrug.dk er der en forklaret udgave af markedsføringsloven. 7 Robinsonlisten er listen over folk, der ikke ønsker at modtage markedsførings-materiale, som administreres af CPR, der opdaterer den hvert kvartal. Det er kun privatpersoner, ikke virksomheder, der kan tilføjes listen. Pt. er ca. 15% af befolkningen på Robinson-listen. Side 10 af 40

2.5 Brugergrænseflade For at nå frem til kravene til brugergrænsefladen er de 6 mål for Usability 8 sat i prioritet rækkefølge: 1. Learnability (Hvor hurtigt er det at lære) 2. Utility (I hvor høj grad funktionerne er arrangeret efter brugerens behov) 3. Safety (I hvor høj grad skal brugeren forebygges fra at lave fejl og gives mulighed for at rette op på dem) 4. Efficiency (hvor mange trin er der hen til de mest anvendte funktioner) 5. Memorability (nemt at huske hvordan man bruger) 6. Effectiveness (i hvor høj grad udføres der direkte det brugeren ønsker) Det vigtigste for brugergrænsefladen er at den er nem at lære at anvende, dvs. at tekster, hjælpetekster, ikoner og navne er sigende for de forskellige funktioner. Brugeren skal hurtigt kunne komme i gang med at anvende den, og ikke være i tvivl om hvad de forskellige funktioner gør. I den forbindelse er strategien Less Is More ; hellere en funktion mindre og et bedre overblik, end mange tæt pakkede funktioner og mindre overblik over brugergrænsefladen som helhed. Dernæst skal funktionerne være grupperet og tilpasset så de passer ind i KLS arbejdsgange, så hver funktions standardopsætning passer til KLS hyppigste arbejdsgange. Det tredje ret vigtige mål er at minimere risikoen for, at en handling brugeren ikke havde til hensigt at udføre, bliver gennemført. Efficiency og Memorability er lavt prioriterede mål, da de bliver nogenlunde opfyldt hvis de højerestående mål opnås, da der ikke er så mange funktioner i alt. Effektivitet er prioritet lavest alene fordi det ikke forventes at være et problem. 2.6 Løsningsforslag Databasen Det første, der skal ske, er at databasen skal designes på ny, da det er nødvendigt at repræsentere dataene således, at der oprettes relationer imellem de enheder, der egentlig er i databasen allerede, såsom personer og virksomheder. Med andre ord er der brug for en relationsdatabase, som eksempelvis kan laves i Access eller på en SQL server. Da databasen kun har 1 bruger og kun fylder ca. 40 MB kan begge løsninger dække KLS behov fint, så det er et spørgsmål om præference. I den forbindelse er min præference SQL i en eller anden variant, og Webteamet i DJØF, som vil komme til at vedligeholde databasen når den står færdig, foretrækker Transact-SQL, da den nye medlemsdatabase vil blive lavet i Transact-SQL. Brugergrænseflade Når der mht. databasen hældes imod SQL, er det oplagte valg af brugergrænseflade umiddelbart et webinterface, da dette, tilsvarende til SQL Servere, typisk lægges på 8 Sharp/Preece/Rogers: Interaction Design, beyond human-computer interaction, s. 20-21 Side 11 af 40

en server frem for en arbejdsstation. Det har den fordel, at databasen kan tilgås fra en hvilken som helst computer på netværket, hvor alternativet, en applikation, skal installeres på hver enkelt computer. Behovet i dag er dog kun at kunne tilgå databasen fra en enkelt computer. Men muligheden for flere samtidige brugere har aldrig været der, så det kan jo være behovet ændrer sig. Kommunikationen imellem database og brugergrænseflade En ting, der kun bliver mere væsentlig af valget af et webinterface frem for en applikation, er at der ikke udføres CRUD-operationer 9 direkte fra brugergrænsefladen til databasen. Derimod at alt foretages igennem foruddefinerede funktioner, som både skal sikre, at dataene står korrekt i databasen samt at give besked retur til brugergrænsefladen med status på de forespørgsler, der er afgivet. Synkronisering med medlemsdatabasen Endelig skal der foregå en synkronisering af data imellem CRM-databasen og medlemsdatabasen, som primært skal foregå i retningen fra medlemsdatabasen til CRM-databasen. 9 CRUD: Create, Read, Update og Delete; i SQL: Insert, Select, Update og Delete. Side 12 af 40

3 Design af databasen Normalisering Som dataene står i en enkelt tabel i Access står de i 1. normal form, med en eller flere unikke keys til alle data. I den nye database stræbes der efter at alle tabeller står i 3. normal form, men det er ikke et ultimatum. 3.1 ER-diagram over databasen Ud fra de beskrevne behov i analysen er der udarbejdet følgende ER-diagram 10. Det har været et gennemgående mål at give brugeren væsentligt flere muligheder i den nye CRM-database. Derfor er der i høj grad gjort plads til ting som måske, måske ikke, vil blive anvendt, frem for at fravælge dem, fordi der på den måde åbnes op for at CRM-databasen kan anvendes på nye måder. For ikke at skabe forvirring imellem den nye og den gamle CRM-database er den gamle kaldt for Access-databasen i det følgende. Gennemgang af ER-diagrammet I dette afsnit vil hver entity i ER-diagrammet blive beskrevet, og dens attributter, primary key og relationships er forklaret. I den forbindelse er primary key, PK, angivet med store bogstaver og attributter med små: Entitynavn(PRIMARY KEY, atribut1, atribut2) Relationships er kun beskrevet første gang der stødes på dem, og så er de skrevet på engelsk, f.eks: E har et ManytoMany-relationship med F. Postnumre(POSTNUMMER, LAND, bynavn) Da postnummeret er unikt indenfor hvert land, anvendes kombinationen som PK. Land er i den forbindelse det område/territorium/stat/land der skal angives nederst i adressen på forsendelser, som f.eks Færøerne. Postnumre har kun ét relationship, og det er et betinget OnetoMany-relationship til Lokationer, da Lokationer er en weak entity der kræver et Postnummer for at blive oprettet. Lokationer(ADRESSE, stednavn) Adresse består af en lang tekststreng med gadenavn, nr, etage og lignende, og er tiltænkt at blive vist på 1 linje ved eksport. Adresse skal derfor både indeholde dataene fra felterne Adresse1 og Adresse2 i Accessdatabasen, for fremover at minimere risikoen for at data bliver placeret forkert. Stednavn er oprettet da der er et behov for at kunne tilføje stednavn til nogle adresser, udover det postnummer og bynavn der i forvejen er tilknyttet. Eksempelvis er der beboere i Kirkelte der ønsker at der står Kirkelte, 3450 Allerød på det post de modtager, i stedet for 3450 Allerød. 10 ER-diagrammet er i Bilag 1. Det er udarbejdet ud fra bogen Database Systems, The Complete Book, International Edition: Hector Garcia-Molina, Jeffrey D. Ullman, Jennifer Widom, som f.eks indeholder ISA-relationships. Side 13 af 40

Stednavn er derfor oprettet som en adresselinje nr. 2, til den slags ønsker. Endelig har Lokationer et OnetoMany-relationship til Afdelinger, og ligeledes et OnetoMany-relationship til Virksomheder, så mens det er muligt for flere virksomheder at have samme adresse, kan en virksomhed kun have én, uden at oprette afdelinger. Virksomheder(VIRKSOMHEDSNAVN, antalansatte, cvrnummer, antalkursuskatalogervirksomhed) Virksomheder har virksomhedsnavn som primary key, da det er den eneste attribut som eksisterer for alle virksomheder i Access-databasen (og som samtidig er unik). Selvom databasen indeholder både virksomheder og offentlige institutioner, er attributten cvrnummer oprettet, med det formål at kunne synkronisere virksomhedsdata med medlemsdatabasen, som engang i fremtiden vil være opdateret med CVR. Antalansatte skal kun rumme de kategorier som haves hos CVR. Virksomheder har et ManytoMany-relationship med Virksomhedsbrancher og et betinget OnetoMany-relationship med Afdelinger, hvor Afdelinger er en weak entity der kræver at der eksisterer en virksomhed. Derudover har virksomheder et kvartært OnetoZeroOrOnetoZeroOrOnetoMany-relationship til Afdelinger, Jobs og Personer, kaldet Ansatte. Det betyder at en Virksomhed kan have mange personer ansat, men hver person kan kun være ansat i et firma, og måske kendes personens Afdeling og Job eller også gør det ikke. Begrænsningen på 1 virksomhed pr. person er lavet da det aldrig ønskes at sende samme materiale til samme person mere end 1 gang uanset om personen har flere virksomhedsadresser. Derfor skal en person heller ikke være tilknyttet mere end 1 afdeling, til gengæld behøver der ikke være en afdeling. Jobs er knyttet til dette relationship da en persons jobtitel (PK i Jobs) også afhænger af virksomheden, udover personen. Så er der et ManytoMany-relationship til Materialer og et ManytoMany-relationship til Skriftlige Samtykkeerklæringer. Meningen med disse 2 relationships er at de skal sammenholdes, således at det materiale en virksomhed modtager stemmer overens med den type materiale virksomheden har samtykket til at modtage. Afdelinger(AFDELINGSNAVN, antalkursuskatalogerafdeling) Inddelingen i Virksomheder og Afdelinger er lavet (bevaret) for at afdelinger kan have en anden adresse end virksomheden en funktionalitet der er et behov for eksempelvis til adresser til Københavns Universitets forskellige fakulteter, som der er mange af i databasen. Da afdelinger ikke har CVR-numre og da det er sværere at indhente information om antal ansatte i en afdeling, har Afdelinger ikke disse attributter. Afdelinger har et ManytoMany-relationship til Afdelingsbrancher og ligesom Virksomheder har Afdelinger et ManytoMany-relationship til Materialer og et ManytoMany-relationship til Skriftlige Samtykkeerklæringer. Side 14 af 40

Personer(IDNUMMER, displaynavn, fuldenavn, uddannelse, cprnummer) Det er blevet overvejet at adskille medlemmer og ikke medlemmer i hver deres entity, med det formål kun at give DJØFmedlemmer attributten cprnummer, da det kun er for dem at det vides med sikkerhed at det må bruges. Men da ikkemedlemmer også kan have et medlemsnummer (i ForeningPro), og det i så fald kan anvendes til at hente information om hvilke kurser de har deltaget i, fra medlemsdatabasen, er der en idé i også at have attributten medlemsnummer for ikke-medlemmer, og gerne som PK. Det er derfor løst ved at alle personer har idnummer som PK, men medlemmers idnummer er lig deres medlemsnummer, imens ikke-medlemmer får autogenereret et idnummer. For da flere personer kan have samme navn og der ikke nødvendigvis er flere informationer om en person end dennes navn, er der ingen vej udenom at oprette en vilkårlig unik værdi som Primary Key til disse personer, hvilket lægges i idnummer. Displaynavn er ment som den attribut der, hvis den eksisterer, erstatter fuldenavn ved eksport. Fuldenavn og uddannelse skal således indeholde de korrekte data, som hentes fra medlemsdatabasen via synkronisering. Personer har et betinget OnetoMany-relationship til Emailadresser, som er en weak entity, der kræver en Person tilknyttet. Det skyldes at lovgivningen altid kræver at en person har tilladt modtagelse af materiale, så for at sikre det altid sker, er der altid tilknyttet en person til en emailadresse i databasen. Derudover er der et ManytoMany-relationship til Temaer, så en persons interesser kan gemmes og et ManytoMany-relationship til Materialer, der angiver hvilket materiale personer har modtaget med brev. Yderligere er der et ManytoMany-relationship til Skriftlige Samtykkeerklæringer som fortæller hvilke tilladelser en Person har givet til at modtage Materiale. Endelig er der et ManytoMany-relationship til Kurser, der angiver hvilke kurser en Person har deltaget på og et ManytoOne-relationship til Fagforeninger. Oplysningen om hvilken fagforening personer har indsamles allerede i dag ved evaluering af kurser og er ønsket at få ind i den nye CRM-database. Fagforeninger(FAGFORENINGSNAVN, fagforeningsbeskrivelse) En fagforening oprettes ud fra et fagforeningsnavn og har attributten fagforeningsbeskrivelse. Udover sit relationship til Personer har Fagforeninger et ManytoMany-relationship til Jobbrancher. Jobs(JOBTITEL, jobtitelbeskrivelse) Jobtitel er PK i Jobs, og jobtitelbeskrivelse er ment som hjælp til KLS, til hvad jobtitlen dækker over. Jobs har et ManytoMany-relationship til Jobbrancher. Temaer(TEMANAVN, temabeskrivelse) Ideen med temaer er at kunne kæde data sammen ud fra vilkårlige fællestræk. Derfor er det meningen at kategorierne fra kursuskataloget skal gemmes her, men der må også gerne udvides med helt andre temaer. Da der er brug for at inddele temaer hierarkisk, er der oprettet et OnetoMany-relationship kaldet Side 15 af 40

erundertematil som går fra og til Tema, så der kan oprettes mange niveauer af temaer. Temaer har ManytoMany-relationships til Jobbrancher,Virksomhedsbrancher, Afdelingsbrancher, Materialer og Kurser. Kurser(KURSUSNUMMER, KURSUSDATO, kursusnavn, kursustype) I ForeningPro har alle kurser i DJØF et kursusnummer, og dette kursusnummer er unikt. Kurser der bliver lavet flere gange får samme kursusnavn og kursusbeskrivelse, men et nyt kursusnummer hver gang. Derfor vælges kursusnummer som primary key til kurser, sammen med kursusdato, da datoen er relevant for KLS og denne dato altid eksisterer i ForeningPro. Feltet kursusbeskrivelse i ForeningPro angiver en kursuskategori, som dog ikke stemmer helt overens med KLS kategorier, og de skal derfor parses før de kan overføres til Temaer. Da feltet kursusbeskrivelse ikke altid er udfyldt i ForeningPro er det ikke krævet at der er et Tema tilknyttet et Kursus i CRM-databasen. Kursustypen for et kursus, er en attribut der er udfyldt for alle kurser i ForeningPro, og den fortæller noget om hvorvidt kurset koster penge (Åbent kursus), er et internt kursus for de ansatte, osv. Kurser har også et ManytoMany-relationship til Materialer. ElektroniskeSamtykkeErklæringer( ELEKTRONISKSAMTYKKEERKLÆRINGSTEKST, elektronisksamtykkeerklæringsnavn) En elektronisk samtykkeerklæring er den formulering som en person giver sit samtykke til, når vedkommende tilmelder sig til at modtage elektronisk materiale fra DJØF. Det sker eksempelvis når kursister udfylder skemaer og tilmelder sig med emailadresse, eller når personer tilmelder sig til nyhedsbreve online. Da teksterne kan skifte med tiden, er det valgt at gemme den eksakte tekst, og gøre den til PK, så det er teksten der tilknyttes emailadresserne direkte. Samtykkeerklæringsnavnet er til brug for KLS til at angive hvad teksten dækker, dvs. en slags overskrift. ElektroniskeSamtykkeErklæringer har et ManytoMany-relationship til Materialer, således at flere elektroniske samtykkeerklæringer kan være acceptable for at et givent materiale sendes ud, dog skal der være mindst én tilknyttet. Derudover er der et betinget OnetoMany-relationship til Emailadresser, som kræver en elektronisk samtykkeerklæring. Emailadresser(EMAILADRESSE) I dag registrerer KLS ikke emailadresser i manglen på et system der sikrer de ikke anvendes forkert senere hen. Derfor er Emailadresser oprettet som en weak entity der kræver en elektronisk samtykkeerklæring tilknyttet udover en Person som tidligere nævnt. Da markedsføringsloven er så stram når det gælder elektronisk markedsføring er det valgt altid at have en Person tilknyttet, så det altid kan ses hvem der har samtykket til hvad. Emailadresser har et ManytoMany-relationship til Materialer, som viser hvilke emailadresser et givent materiale er sendt til. Side 16 af 40

SkriftligeSamtykkeErklæringer( SKRIFTLIGSAMTYKKEERKLÆRINGSTEKST, Skriftligsamtykkeerklæringsnavn) SkriftligeSamtykkeErklæringer dækker over de mulige til- og fra-valg af markedsføringsmateriale fra DJØF der er for breve; det der hedder Al Reklame og Ingen Reklame i Access-databasen. Ligesom ElektroniskeSamtykkeErklæringer har SkriftligeSamtykkeErklæringer et ManytoMany-relationship til Materialer, der angiver hvilke samtykkeerklæringer materialet opfylder. Materialer(MATERIALENAVN, DATOPLANLAGT, materialebeskrivelse, datoudsendt, antaludsendt, antalreturneret, antaltilmeldte) Da det samme markedsføringsmateriale nogle gange udsendes flere gange er både Materialenavn og Datoplanlagt PK. Når eller hvis materialet bliver udsendt udfyldes datoudsendt med dags dato, og antaludsendt med det samlede antal modtagere af materialet, dvs. Personer, Afdelinger, Virksomheder og Emailadresser. AntalReturneret og AntalTilmeldte opdateres derefter løbende, da de skal bruges til at lave statistik som f.eks succesraten på det udsendte materiale, dvs. hvor mange der tilmeldte sig efter at have modtaget materialet i forhold til hvor mange der har fået tilsendt materialet i alt. Det været overvejet om det skulle være et krav at Materiale skulle være tilknyttet mindst en Elektronisk Samtykkeerklæring og en Skriftlig Samtykkeerklæring. Det er blevet fravalgt, da der f.eks kunne opstå det problem at der ikke var en dækkende elektronisk samtykkeerklæring for et Materiale der skulle udsendes med brev. I så fald ville brugeren være tvunget til at opfinde en dummy elektronisk samtykkeerklæring, som Emailadresser herefter kunne blive tilknyttet, hvilket ville være uhensigtsmæssigt. Derfor er begge relationships til samtykkeerklæringer ManytoMany, og så er det op til den Stored Procedure der skal oprette Materialer at sikre at enten en elektronisk eller en skriftlig samtykkeerklæring bliver tilknyttet. Virksomhedsbrancher(VIRKSOMHEDSBRANCHENAVN, virksomhedsbranchebeskrivelse) En virksomhedsbranche består af et navn og en beskrivelse i DJØFs tilfælde ville virksomhedsbranchen være Fagforeninger. Afdelingsbrancher(AFDELINGSBRANCHENAVN, afdelingsbranchebeskrivelse) Et eksempel på et Afdelingsbranchenavn kunne være Regnskab, IT eller Kommunikation. Jobbrancher(JOBBRANCHENAVN, jobbranchebeskrivelse) Jobbrancher er næsten det samme som Jobs, men også kun næsten. Hvor Jobs indeholder den jobtitel som personen selv ønsker, så indeholder Jobbrancher de jobtitler KLS ønsker, og da der er et ManytoMany-relationship imellem Jobs og Jobbrancher kan der til en person der kun ønsker at fremstå som Konsulent tilknyttes flere Jobbrancher, f.eks. Selvstændige og Advokater. Side 17 af 40

3.2 Synkronisering med medlemsdatabasen Der ønskes kun en synkronisering af data i retningen fra medlemsdatabasen til CRMdatabasen. De relationer og attributter som ønskes synkroniseret er: Personer(idnummer, fuldenavn, cprnummer) Personer_Kurser(idnummer, kursusnummer, kursusdato) Kurser(Kursusnummer, kursusnavn, kursusdato, kursustype) Temaer(temanavn) Kurser_Temaer(kursusnummer, kursusdato, temanavn) Virksomheder(virksomhedsnavn, cvrnummer, antalansatte,adresse,postnummer,land) Ansatte(virksomhedsnavn, idnummer) Virksomhedsbranche(virksomhedsbranchenavn) Virksomheder_Virksomhedsbrancher(virksomhedsnavn, virksomhedsbranchenavn) Nogle af disse attributter vil først kunne blive synkroniseret engang i snarlig fremtid, eksempelvis gemmes CPR-numre ikke i ForeningPro, men det vil det blive i den nye medlemsdatabase som kommer (og som er unavngivet). Ligeledes er opdateringen mellem ForeningPro og CVR ikke i produktion endnu, så pt. er det kun attributter fra Personer, Kurser og Temaer der er relevante at importere. Det er ikke så afgørende at dataene opdateres konstant, bare det vides at dataene er opdateret inden der laves et udtræk. Derfor er vurderingen at en synkronisering 1 gang i timen vil være fint, men der må godt være en mulighed fra brugergrænsefladen for at opdatere øjeblikkeligt. 3.3 Import af data til den nye CRM-database Som vist i tabellen under Gennemgang af Accessdatabasen, så er der under analysen fundet invalide data i flere af kolonnerne i Access-databasen. Der er dels tale om nogle tastefejl, dels nogle data der står i forkerte kolonner, og dels nogle data der skal slettes (Roskilde Bank f.eks.), men det væsentlige er at omfanget ikke kendes på forhånd. Derfor er det essentielt at der under importen bliver ryddet så meget som muligt op i de fejlbehæftede data der eksisterer, ved at kigge dataene igennem som de bliver importeret, og håndtere fejlene løbende. Det er derfor valgt at anvende scripting til at importere dataene, da scripts er hurtige at tilpasse løbende, og det gør ikke noget at scriptet kun virker til de aktuelle data, da der ikke fremover kommer flere data i samme format. Side 18 af 40

3. 4 Dubletsøgning Formålet med dubletsøgning er at finde de tilfælde hvor flere Personer i databasen ligner hinanden tilstrækkeligt meget til at der sandsynligvis er tale om dubletter. Herefter skal brugeren afgøre hvilke data der skal gemmes, ud fra en oversigt over alle persondata og dennes relationer. De dubletter der ønskes fundet kan inddeles i 3 typer: eksakte dubletter: Minimum displaynavn for Personerne er præcis ens, ud af alle Personernes attributter og relationer. Nyt Navn -dubletter: En Person har fået nyt mellemnavn eller efternavn, og dele af navnet er derfor præcis ens, men de har ikke nødvendigvis procentvis meget af deres navne til fælles. Tastefejls-dubletter: Personer, der procentvis er meget ens Heraf er det de eksakte dubletter og nyt-navn -dubletter som udgør det største problem for datakvaliteten, hvor de eksakte dubletter vil være lettest at identificere, da der blot skal laves en sammenligning på displaynavn. Nyt-navn -dubletter er derimod lidt sværere, og det dækker også over 2 tilfælde: Når en person har fået et navn ekstra og når en person har fået et navn ændret. Hvis Person A har et ekstra navn i forhold til Person B, er B.displayname derfor en slags substring til A.displayname, men hvor alle tegnene fra B.displayname ikke behøver komme lige efter hinanden. Når en Person ændrer sit navn er det i databasen nødvendigt at sammenligne på flere attributter end kun displaynavn, for ikke at få for mange false positives iblandt resultaterne, når der søges efter dubletter. Derfor er det relevant at anvende attributterne virksomhedsnavn og afdelingsnavn fra Ansatte, således at en person der har ændret navn skal have dele af sit displaynavn til fælles med sin dublet, og mindst hele virksomhedsnavn eller afdelingsnavn til fælles med sin dublet. For at undersøge for tastefejlsdubletter skal der sammenlignes, imellem 2 Personer A og B, ved at køre A.displaynavn igennem og tælle op hvor mange af tegnene i B.displaynavn der forekommer (i korrekt rækkefølge), og optællingen skal herefter gentages hvor nogle af tegnene fra B udelades. Det højeste af disse antal divideres med antallet af tegn i B.displaynavn for at få lighedsgraden, som til sidst holdes op i mod et af brugeren valgt minimumskrav. Fælles for alle typer dubletter er at når mulige dubletter er fundet, skal de vises til brugeren inkl. alle relationer for Personerne, og så er det op til brugeren at beslutte hvad der skal ske. Side 19 af 40

3.5 Eksport af data fra databasen Inden en eksport foretages skal følgende betingelser være opfyldt: Personerne er tilknyttet en af de samtykkeerklæringer materialet er tilknyttet Hvis materialet udsendes med brev (der kan tjekkes på om det er en skriftlig samtykkeerklæring), skal der være en Lokation tilknyttet til enten Virksomheden eller Afdelingen. Hvis både Personens Afdeling og Virksomhed har en Lokation, anvendes Afdelingens Lokation. Herefter er kravet for udsendelse med brev at dataene gemmes i et format Excel kan importere, og som består af rækker med data, og kolonnerne: displaynavn, jobtitel, virksomhedsnavn, afdelingsnavn, adresse, stednavn, postnummer, by og land. CSVformatet er således passende til det formål. For udsendelse via email ville det være optimalt hvis der kunne sendes en email direkte fra databasen, således at den også kunne administrere besvarelserne, men den opgave ligger udenfor dette projekts mål. 3.6 Sikkerheden for databasen Mht. netværkssikkerhed, så vil databasen kun blive anvendt indenfor DJØFs domæne, hvor kun medarbejdere har adgang, og det sikkerhedsniveau er tilstrækkeligt til CRM-databasen. Der er derfor ikke noget problem i at databasen kan tilgås over netværket, dog bør der være brugernavn og kodeord på. 3.7 Design af Stored Procedures Ambitionen med løsningen er at Stored Procedures skal fungere som bindeleddet imellem databasen og webinterfacet. Ambitionen er også at databasen skal være nogenlunde statisk, imens brugergrænsefladen godt må udskiftes fuldstændig efterhånden som den udvikles. Men det strider lidt imod formålet med udelukkende at anvende Stored Procedures, som var at sikre at CRUD-operationer foretages ensartet. Side 20 af 40