For EDB-systemer, som har en underliggende database, og som er over en bestemt størrelse, vil det være det underliggende database-design, der er EDB-systemets sjæl. Uanset hvor dygtige programmørerne er, så er EDB-systemets skæbne beseglet af databasens design.

Det er meget vigtigt at analysere det område (forretningsområde, etc.), som EDB-systemet skal håndtere. Ud fra denne analyse kan man definere et database-design. Man skal modellere dette område ind i database-designet.

Man ser ofte, at denne analyse ikke er god og tilstrækkelig, og det vil give problemer. Typisk betyder det, at EDB-systemet ikke lever længe, eller at der er store omkosninger ved at holde systemet i live. Hvis database-designet er godt, så vil systemet være nemt at programmere, og man har ikke behov for at justere database-designet løbende. Generelt vil jeg påstå, at mange programmører ikke har forståelse for vigtigheden af databasens design.

En stor del af de systemer, som jeg har konstrueret, er version 2 af systemet. Dvs version 1 er blevet skrottet. Som database-designer og programmør på version 2, bør man undgå at kigge på den første version.

Ved et godt database-design kan man opnå følgende:

• Databasen bliver normaliseret. F.eks. kan databasen modellere adresser på juridiske enheder. Udover at man kan generalisere begrebet adresser, så vil den klassiske danske adresse kunne opløses i postnummer, (kommune,) vej, stednavn, samt et par ekstra ting såsom husnummer. Det er klart, at postnummer '2000' ikke bør optræde mere end 1 gang i databasen, og det vil være interessant hvis vejnavnet (også selv om det er forskellige veje - 'Nyvej' er mange steder i Danmark) kun optræder 1 gang i databasen. Data bliver relateret via referencer, idet de enkelte ting (f.eks. en adresse) bliver opløst i atomer. I eksemplet med de danske adresser vil vi til en konkret adresse have referencer til postnummeret, til vejens navn, til stednavnet og til kommunen.
• Historik og fremtid. Vi vil ikke slette eller ændre data i databasen - derved bevarer vi historikken i alle hændelser, som der måtte være sket. I bankverdenen er et revisionsspor meget vigtigt, og eksistensen af revisionssporet er et krav. Dette skal gælde generelt i databasens design, og ikke blot på udvalgte tabeller. Faktisk kan vi generalisere begrebet historik, således, at vi kan skrue tiden frem eller tilbage. Forestil, at f.eks. en rentesats varierer i tid (eventuelt også ind i fremtiden). Ved at definere hvilke periode den konkrete rentesats er gældende, så kan vi præcis fortælle hvad summen af renter bliver i et hvilket som helst tidsrum (igen også ind i fremtiden).

Der findes en del database-servere, f.eks. IBM DB2, Microsoft SQL Server, Oracle, MySQL og PostgreSQL. De alle er relationelle, og de fungerer nogenlunde ens. Man anvender sproget SQL, når man vil tilgå data i databaserne. Og man kan komme i forbindelse med database-serveren via de fleste programmeringssprog, f.eks. Java, PHP, og C#. Man vil typisk anvende ODBC-drivere, JDBC-drivere hvis programmeringssproget er Java, eller man kan anvende 'native-drivere' (f.eks. kan man anvende npgsql, hvis man anvender C# mod en PostgreSQL database-server).

Jeg har for tiden en forkærlighed for PostgreSQL, som er en opensource database-server - du kan læse mere om PostgreSQL på denne hjemmeside.