Man kan definere en database som en samling data om et emne. Den er organiseret på en måde som gør det muligt nemt at bladre i informationen, lave ændringer eller tilføje nye punkter. Kig på dette diagram for et af de ovenstående eksempler: en simpel telefonbog. Et diagram af en database med telefonnumre Et diagram af en database med telefonnumre Billedet ovenfor viser et sæt med to kontakter, hvor hver af dem vises på et separat kort. Det ser ud som om et sådan kort kan udgøre en enkelt række i en tabel: Tabellen Kontakter Navn Tlf nr. Anna 699 23 43 12 Emil 711 19 77 21 Udtryk og definitioner: Et enkelt dataobjekt som udgør en del af en større samling kan kaldes en række, eller mere professionelt en post. Samlingen kaldes normalt en tabel. Desuden er det mest naturlige navn på tabellen det som beskriver data som den tilbyder/opbevarer, hvilket er Kontakter. Foruden dette, består hver række i tabellen af søjler som ofte også kaldes felter. Der er to søjler (felter) i tabellen Kontakter: Navn og Tlf nr.. For simpel brug kan en enkelt tabel udgøre en database. Mange anser begge som ækvivalente. Som du vil se, behøves der ofte mere end en tabel i rigtige databaser. For at opsummere, har du allerede en enkel database med en tabel, Kontakter. Det er troligt at du allerede har benyttet regneark såsom Kspread, OpenOffice.org Calc eller Microsoft Excel. Hvis du har gjort det, undrer du dig nok: eftersom både regneark og databaser har tabeller, hvorfor skal jeg bruge de sidste? Ved sammenligning af regneark og databaser kan du støde på følgende emner som du senere vil få at se mere detaljeret: Datahenvisningsintegritet Dataredundans Dataintegritet og gyldighed Begrænset datavisning Ydelse og kapacitet Bekvem indtastning af data Rapporter Programmering Flere brugere Sikkerhed Udvid gradvis tabellen Kontakter ved at tilføje en søjle (et felt) Adresse, så den overskrider kapaciteten hos en mobiltelefon. Tilføj flere telefonnumre (kontor, hjem) for hver person og tilføj efternavn til navnene. For at gøre det enklere antager vi følgende: tabellen er begrænset til to personer (åbenbart kan der være hundredvis eller tusindvis i en rigtig database) at der ikke findes to personer med samme for- og efternavn Kontakttabel For- og efternavn Tlf Adresse Anna Stricker 699 23 43 12 Vesterport 1, Helsingør Emil Pedersen 711 19 77 21 Odense, Madsensvej 15 Anna Stricker 10 98 98 00 Vesterport 1 Stricker, Anna 12 43 42 22 Helsingør, Vesterport 1 EMIL Pedersen 31 83 02 04 Madsensvej 15, Odense En sådan tabel kan både laves i et regneark og i en database. Det er naturligvis meget enkelt at bruge et regneark. Hvilke problem støder man på i dette stadie? Antag at du bruger et regneark og skal ændre adressen for mindst en person. Du har et lille problem: du skal ofte ændre adressen på flere rækker. Anna bruger for eksempel tre rækker. Et rigtigt problem opstår hvis du glemmer at ændre en af de tre rækker: adressen som hører sammen med personen bliver tvetydig, så på den måde går dataintegriteten tabt. Derudover er det ingen enkelt måde at fjerne en valgt person fra tabellen, eftersom du skal huske at fjerne alle rækker som hører sammen med ham eller hende. Dette hører direkte sammen med foregående problem. I felterne For- og efternavn samt Adresse skrives samme data ind mange gange. Dette er typisk i regneark, og er en ineffektiv måde at opbevare data eftersom databasen vokser unødigt, og på den måde kræver flere maskineressourcer (større datastørrelse og langsommere adgang). Hvordan kan du løse disse problemer med en database? Du kan dele information i mindre dele ved at oprette en yderligere tabel Personer med kun to søjler: For- og efternavn samt Adresse: Tabellen Personer For- og efternavn Adresse Anna Stricker Vesterport 1, Helsingør Emil Pedersen Madsensvej 15, Odense Hver række i tabellen Personer svarer til en enkelt person. Tabellen Kontakter er fra og med nu i en relation til tabellen Personer. Bemærk måden som data skrives ind i felterne For- og efternavn samt Adresse. De som skriver data ind kan lave fejl, eller sommetider til og med være sløsede. I vor eksempeldata har vi både forskellige rækkefølge når for- og efternavn skrives ind (Anna Stricker og Stricker, Anna, Emil og EMIL) og endnu flere måder at indtaste samme adresse. Du kan sikkert tænke dig mange andre varianter. Ovenstående problem viser at ved søgning efter telefonnummeret til en person hvis adresse for eksempel er "Vesterport 1, Helsingør" får du ikke et fuldstændigt resultat. Du får kun en række i stedet for tre. Desuden finder du heller ikke alle telefonnumre ved søgning efter værdien "Anna Stricker" i feltet For- og efternavn, eftersom "Stricker, Anna" ikke stemmer overens med "Anna Stricker". Hvordan kan man løse disse problemer ved at bruge en database? Du kan gøre dette ved at ændre design af tabellen Personer ved at: Opdele data i feltet For- og efternavn i to separate felter: Fornavn og Efternavn. Opdele data i feltet Adresse i tre separate felter: Gade, Husnummer og By. Garantere at data er rigtig: ved at sikre dig at ingen felter er tomme, f.eks. skal husnummeret altid skrives ind. En ændret tabel ser ud cirka sådan her: Persontabel Navn Efternavn Gade Husnummer By Anna Stricker Vesterport 1 Odense Emil Pedersen Madsensvej 5 Odense Betingelser krævet felt krævet felt krævet felt krævet felt krævet felt På grund af at betingelser nødvendigt felt er introduceret kan vi være sikre på at indskrevne data er fuldstændige. I tilfælde af andre tabeller kan man naturligvis fortsætte med at udelukke visse felter når data skrives ind. Et regneark viser alle rækker og søjler i tabellen, hvilket er besværligt i tilfælde af meget store datamængder. Du kan naturligvis filtrere og sortere rækker i regneark, men du skal være ekstra forsigtig når du gør det. Brugere af regneark løber risikoen for at glemme at datavisningen er filtreret, hvilket kan forårsage fejl. Når du beregner summer, tror du måske at du har 100 rækker med data, mens der i virkeligheden er yderligere 20 skjulte rækker. Hvis du vil arbejde med en lille delmængde af data, f.eks. for at sende dem til andre for redigering, kan du kopiere og indsætte i et andet regneark og efter redigering indsætte ændrede data i hovedregnearket. Sådan "manuel" redigering kan forårsage datatab eller fejlagtiga beregninger. For at begrænse datavisningen tilbyder databaseprogrammer forespørgsler, formularer og rapporter. En meget praktisk måde at begrænse på er følgende udvidede version af tabellen Personer som tidligere beskrevet: Persontabel Navn Efternavn Gade Husnummer By Indkomst Anna Stricker Vesterport 1 Odense 23 000 Emil Pedersen Madsensvej 5 Odense 19 000 Lad os antage at den nys tilføjede søjle Indkomst indeholder fortrolige data. Hvordan kan du for eksempel dele personernes kontaktinformation med arbejdskolleger uden at afsløre deres indkomst? Dette er muligt hvis du kun deler en forespørgsel og ikke hele tabellen. Forespørgslen kunne vælge alle søjler undtagen søjlen Indkomst. I databaseverdenen er en sådan forespørgsel ofte kendt som en visning. Din maskine er formodentlig ret hurtig, men du mærker let at dette ikke er nok med langsomme, store regneark. Deres lave effektivitet skyldes først og fremmest manglende af indeks som gør datasøgningsprocessen hurtigere (databaser tilbyder dem). Hvis du desuden bruger ting såsom systemets klippebord, kan til og med kopiering af data blive besværlig med tiden. Regneark som indeholder store datamængder kan tage enorm tid at åbne. Et regneark indlæser mængder med data i maskinens hukommelse når de åbnes. Det meste data som indlæses er for formodentlig unyttigt indtil videre eller ikke nødvendigt for dig. I modsætning til regneark indlæser databaser kun data fra maskinens lagringsmedier når de behøves. I de fleste tilfælde behøver du ikke bekymre dig om hvordan databasen opbevarer sine data. Dette betyder at i modsætning til regneark, er databaser ligeglade med: Sekvensen af rækker, eftersom du kan ordne rækker efter dine behov. Desuden kan du kigge på samme data i mange visninger med forskellige rækkefølge. Det samme gælder for søjler (felter) i tabellen. Sammen med Begrænset datavisning beskrevet i foregående paragraf, udgør disse kvaliteter fordelene ved databaser. De seneste udgaver af programmer til at oprette regneark gør det muligt for dig at oprette dataindtastningsformularer. Sådanne formularer er mest nyttige hvis data ikke kan vises bekvemt i en tabelvisning, f.eks. hvis teksten optager for mange rækker eller hvis alle søjler ikke får plads på skærmen. I dette tilfælde er selve måden som regneark fungerer problematisk. Felter for dataindtastning placeres frit inde i regnearket og er oftest ikke sikrede mod brugerens indgriben (med vilje eller af fejl). Databaser muliggør gruppering, begrænsning og opsummering af data i form af en rapport. Regneark skrives ofte ud i form af små tabeller uden fuldstændig automatisk styring af sidebrud og layout af felter. Programmer til at oprette databaser indeholder ofte fuldstændige programmeringssprog. Nyere regneark har også den mulighed, men alligevel består beregninger i at ændre regnearkets felter og enkel datakopiering, uafhængig af relevans og integritetsregler som nævnt i foregående paragraf. Databehandling i et regneark gøres ofte via en grafisk brugergrænseflade, som kan gøre databehandlingens hastighed langsommere. Databaser har mulighed for at arbejde i baggrunden, udenfor den grafiske grænseflade. Det er svært at forestille sig flere brugere af et regneark. Selvom det er teknisk muligt med de seneste programmer, kræver det meget disciplin, opmærksomhed og kundskab af brugerne, og det kan ikke altid garanteres. En klassisk måde at dele data som er gemt i et regneark med andre er at sende filen i sin helhed (oftest med e-mail) eller sørge for en fil med et regneark i et maskinenetværk. Denne måde at arbejde er ineffektiv for større grupper: data som kan behøves et bestemt øjeblik kan for øjeblikket være låst af en anden. På den anden side er databaser i hovedsagen konstrueret med adgang af flere brugere fra begyndelsen. Til og med i de aller enkleste versioner er det muligt at låse på niveau af en bestemt tabelrække, hvilket gør det muligt let at dele data. At sikre et regneark eller dets forskellige dele med et kodeord er kun en symbolsk aktivitet. Efter en fil med regnearket er sørget for i et maskinenetværk, kan hvem som helst som kan kopiere filen forsøge at knække kodeordet. Det er sommetider ikke så svært eftersom kodeordet opbevares i samme fil som regnearket. Funktioner for at låse ved redigering eller kopiering af et regneark (eller en del af det) er lige så enkle at knække. Databaser (undtagen dem som opbevares i en fil i stedet for på en server) behøver ikke at være tilgængelige i en enkelt fil. Du kommer til dem via et maskinenetværk, oftest ved at sørge for et brugernavn og kodeord. Du får kun adgang til de områder (tabeller, formularer og til og med udvalgte rækker og søjler) som blev tildelt dig ved at indstille passende adgangsrettigheder. Adgangsrettigheder kan påvirke muligheden for at redigere data, eller mulighed til kun at læse data. Hvis noget data ikke er tilgængelig for dig, sendes det ikke engang til din maskine, så der er ingen mulighed for at lave en kopi af data på en så enkel måde som for filer i et regneark. Databasedesignet kræver nøjagtig planlægning. Bemærk at ændring af design af tabellen Kontakter som foreslået i afsnittet ovenfor kan give problemer når tabellen er fyldt med data. Det er for eksempel en enkel opgave at skifte navn på et felt, men at dele feltet Adresse i separate felter kræver forsigtigt og langtrukkent arbejde. For at undgå sådanne situationer, gennemtænk databaseprojektet inden du laver det i maskinen, og inden du og andre begynder at bruge det. På den måde, ved at investere en vis tid i begyndelsen, sparer du formodentlig din tid ved daglig brug. Dine behov er begrænsede og data aldrig vokser til store mængder (kan du virkelig forudsige det nu?) Du kan ikke indhente metodikken for databasekonstruktion. Du kan imidlertid overveje at lægge aktiviteten ud til en anden, eller bruge enklere værktøj. Du bruger komplicerede regneark og mangler tid eller penge til at skifte til databaser. Gennemtænk eller spørg nogen om dette ikke er en død ende. Regn ikke med magiske værktøjer som vil kunne ændre dit regneark (uafhængig af hvor godt det er gjort) til en database. Din samling med data ekspanderer hvert uge. Du ofte laver nye regneark, kopierer mellem dem og mærker at dette arbejde bliver mere og mere ensformigt. I dette tilfælde betaler anstrengelsen at skifte til databaser sig let. Du laver rapporter og uddrag hvor tabelvisningen i et regneark ikke er passende. Så kan du overveje at skifte til brug af en database med formularvisninger. Hidtil har du lært dig de generelle særligheder hos databaser uden at være gået ind på detaljer om specifikke programmer til at oprette dem. De første databaser blev oprettet sammen med store maskiner i 60'erne, f.eks. IBM System/360. Det var ikke personlige computeres tid, og derfor krævede databaserne meget specialiseret personale. Selvom de gamle maskiners hardware hvor utilforladelig, de var grænseløst meget langsommere og havde mindre lagringskapacitet, var der funktion ved databaser som er forblevet den mest attraktive: dataadgang for mange brugere via netværk. I 70'erne formulerede videnskaben teorien om relationsdatabaser (begreber såsom tabel, post, søjle (felt) og relation og mange flere). Baseret på denne teori oprettedes databaserne IBM DB2 og Oracle, som har udviklet sig og bruges frem til i dag. Sent i 70'erne blev de første personlige computere konstrueret. Deres brugere kunne (gradvis) begynde at udnytte mange typer af programmer, inklusive dem til databasekonstruktion. Når det gælder store databaser i er firma, har situationen ikke ændret sig: de kræver stadigvæk kraftfulde maskiner eller maskineanlæg som kaldes clusters. Dette er imidlertid udenfor denne håndbogs rækkevidde. Indenfor området "mulige" databaser med grafisk brugergrænseflade for pc'er kan du vælge blandt følgende: DBase: et værktøj til databasebrug for DOS populært i 80'erne. Filer med DBase-format bruges stadigvæk i visse specifikke tilfælde på grund af deres enkelhed. FoxPro: et program som ligner DBase (tidligt i 90'erne). Efter det blev overtaget af Microsoft, introduceredes en grafisk brugergrænseflade og det bruges derfor til at oprette databaser på pc'er. Dette produkt sælges stadigvæk, selvom det virker noget forældet. Microsoft Access: et program for databaser (design af data og grafisk grænseflade) med mange forenklinger, og derfor godt for nybegyndere, designet tidligt i 80'erne, baseret på en 16-bit arkitektur. Dette produktet tilbydes og er i bred brug frem til i dag, især af små firmaer, hvor effektivitet og krav om flere brugere ikke er særligt krævende. FileMaker: populært program som ligner MS Acess i enkelhed, som virker på Windows og MacIntosh platforme, tilbudt siden 1985. &kexi;: et program for flere platforme (Unix/Linux, Windows, MacOS X) designet i 2003, udviklet ifølge principperne om åben kildekode, en del af det globale projekt K-desktopmiljøet, dvs. et grafisk miljø for systemer med Unix/Linux. En betydningsfuld bidragyder til &kexi;s udvikling er firmaet OpenOffice Poland.