You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
783 lines
24 KiB
783 lines
24 KiB
<!--
|
|
<!DOCTYPE appendix PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd">
|
|
-->
|
|
|
|
<appendix id="database">
|
|
<title
|
|
>Introduktion til databaser</title>
|
|
|
|
<sect1 id="what-is-a-database">
|
|
<title
|
|
>Hvad er en database?</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>Kig på dette diagram for et af de ovenstående eksempler: en simpel telefonbog. </para>
|
|
<screenshot>
|
|
<screeninfo
|
|
>Et diagram af en database med telefonnumre</screeninfo>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="contact-example.png" format="PNG"/>
|
|
</imageobject>
|
|
<textobject>
|
|
<phrase
|
|
>Et diagram af en database med telefonnumre</phrase>
|
|
</textobject>
|
|
</mediaobject>
|
|
</screenshot>
|
|
<para
|
|
>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: </para>
|
|
|
|
<para
|
|
><emphasis
|
|
>Tabellen <guilabel
|
|
>Kontakter</guilabel
|
|
></emphasis
|
|
></para>
|
|
<informaltable>
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry
|
|
><guilabel
|
|
>Navn</guilabel
|
|
></entry>
|
|
<entry
|
|
><guilabel
|
|
>Tlf nr.</guilabel
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna</entry>
|
|
<entry
|
|
>699 23 43 12</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Emil</entry>
|
|
<entry
|
|
>711 19 77 21</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para
|
|
><emphasis
|
|
>Udtryk og definitioner</emphasis
|
|
>: Et enkelt dataobjekt som udgør en del af en større samling kan kaldes en <firstterm
|
|
>række</firstterm
|
|
>, eller mere professionelt en <firstterm
|
|
>post</firstterm
|
|
>. Samlingen kaldes normalt en <firstterm
|
|
>tabel</firstterm
|
|
>. Desuden er det mest naturlige navn på tabellen det som beskriver data som den tilbyder/opbevarer, hvilket er <guilabel
|
|
>Kontakter</guilabel
|
|
>. Foruden dette, består hver række i tabellen af <firstterm
|
|
>søjler</firstterm
|
|
> som ofte også kaldes <firstterm
|
|
>felter</firstterm
|
|
>. Der er to søjler (felter) i tabellen <guilabel
|
|
>Kontakter</guilabel
|
|
>: <guilabel
|
|
>Navn</guilabel
|
|
> og <guilabel
|
|
>Tlf nr.</guilabel
|
|
>. </para>
|
|
<para
|
|
>For simpel brug kan en enkelt tabel udgøre en <firstterm
|
|
>database</firstterm
|
|
>. Mange anser begge som ækvivalente. Som du vil se, behøves der ofte mere end en tabel i rigtige databaser. </para>
|
|
<para
|
|
>For at opsummere, har du allerede en enkel database med en tabel, <guilabel
|
|
>Kontakter</guilabel
|
|
>. </para>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="database-and-spreadsheet">
|
|
<title
|
|
>Databaser og regneark</title>
|
|
<para
|
|
>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? </para>
|
|
<para
|
|
>Ved sammenligning af regneark og databaser kan du støde på følgende emner som du senere vil få at se mere detaljeret: </para>
|
|
<itemizedlist>
|
|
<listitem
|
|
><para
|
|
><link linkend="referential-data-integrity"
|
|
>Datahenvisningsintegritet</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="data-redundyncy"
|
|
>Dataredundans</link>
|
|
</para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="data-integrity-and-validity"
|
|
>Dataintegritet og gyldighed</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="data-limiting"
|
|
>Begrænset datavisning</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="performance-and-capacity"
|
|
>Ydelse og kapacitet</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="convenient-data-entry"
|
|
>Bekvem indtastning af data</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="reports"
|
|
>Rapporter</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="programming"
|
|
>Programmering</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="multiuse"
|
|
>Flere brugere</link
|
|
></para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><link linkend="security"
|
|
>Sikkerhed</link
|
|
></para
|
|
></listitem>
|
|
</itemizedlist>
|
|
|
|
<sect2 id="difference-database-and-spreadsheet">
|
|
<title
|
|
>Hvordan adskiller en database sig fra et regneark?</title>
|
|
|
|
<para
|
|
>Udvid gradvis tabellen <guilabel
|
|
>Kontakter</guilabel
|
|
> ved at tilføje en søjle (et felt) <guilabel
|
|
>Adresse</guilabel
|
|
>, 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: </para>
|
|
<itemizedlist>
|
|
<listitem
|
|
><para
|
|
>tabellen er begrænset til to personer (åbenbart kan der være hundredvis eller tusindvis i en rigtig database)</para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>at der ikke findes to personer med samme for- og efternavn</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para
|
|
><emphasis
|
|
>Kontakttabel</emphasis
|
|
></para>
|
|
<informaltable>
|
|
<tgroup cols="3">
|
|
<tbody>
|
|
<row>
|
|
<entry
|
|
><emphasis
|
|
>For- og efternavn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Tlf</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Adresse</emphasis
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna Stricker</entry>
|
|
<entry
|
|
>699 23 43 12</entry>
|
|
<entry
|
|
>Vesterport 1, Helsingør</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Emil Pedersen</entry>
|
|
<entry
|
|
>711 19 77 21</entry>
|
|
<entry
|
|
>Odense, Madsensvej 15</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna Stricker</entry>
|
|
<entry
|
|
>10 98 98 00</entry>
|
|
<entry
|
|
>Vesterport 1</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Stricker, Anna</entry>
|
|
<entry
|
|
>12 43 42 22</entry>
|
|
<entry
|
|
>Helsingør, Vesterport 1</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>EMIL Pedersen</entry>
|
|
<entry
|
|
>31 83 02 04</entry>
|
|
<entry
|
|
>Madsensvej 15, Odense</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para
|
|
>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? </para>
|
|
|
|
<sect3 id="referential-data-integrity">
|
|
<title
|
|
>Datahenvisningsintegritet</title>
|
|
<para
|
|
>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 <emphasis
|
|
>tvetydig</emphasis
|
|
>, så på den måde går <emphasis
|
|
>dataintegriteten</emphasis
|
|
> tabt. </para>
|
|
<para
|
|
>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. </para>
|
|
</sect3>
|
|
|
|
|
|
<sect3 id="data-redundyncy">
|
|
<title
|
|
>Dataredundans</title>
|
|
<para
|
|
>Dette hører direkte sammen med foregående problem. I felterne <guilabel
|
|
>For- og efternavn</guilabel
|
|
> samt <guilabel
|
|
>Adresse</guilabel
|
|
> 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). </para>
|
|
<para
|
|
>Hvordan kan du løse disse problemer med en database? Du kan dele information i mindre dele ved at oprette en yderligere tabel <emphasis
|
|
>Personer</emphasis
|
|
> med kun to søjler: <guilabel
|
|
>For- og efternavn</guilabel
|
|
> samt <guilabel
|
|
>Adresse</guilabel
|
|
>: </para>
|
|
|
|
<para
|
|
><emphasis
|
|
>Tabellen <guilabel
|
|
>Personer</guilabel
|
|
></emphasis
|
|
></para>
|
|
<informaltable>
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry
|
|
><emphasis
|
|
>For- og efternavn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Adresse</emphasis
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna Stricker</entry>
|
|
<entry
|
|
>Vesterport 1, Helsingør</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Emil Pedersen</entry>
|
|
<entry
|
|
>Madsensvej 15, Odense</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para
|
|
>Hver række i tabellen <guilabel
|
|
>Personer</guilabel
|
|
> svarer til en <emphasis
|
|
>enkelt person</emphasis
|
|
>. Tabellen <guilabel
|
|
>Kontakter</guilabel
|
|
> er fra og med nu i en relation til tabellen <guilabel
|
|
>Personer</guilabel
|
|
>. </para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="data-integrity-and-validity">
|
|
<title
|
|
>Dataintegritet og gyldighed</title>
|
|
<para
|
|
>Bemærk måden som data skrives ind i felterne <guilabel
|
|
>For- og efternavn</guilabel
|
|
> samt <guilabel
|
|
>Adresse</guilabel
|
|
>. 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. </para>
|
|
<para
|
|
>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 <guilabel
|
|
>For- og efternavn</guilabel
|
|
>, eftersom "Stricker, Anna" ikke stemmer overens med "Anna Stricker". </para>
|
|
<para
|
|
>Hvordan kan man løse disse problemer ved at bruge en database? Du kan gøre dette ved at ændre design af tabellen <guilabel
|
|
>Personer</guilabel
|
|
> ved at: </para>
|
|
<orderedlist>
|
|
<listitem
|
|
><para
|
|
><emphasis
|
|
>Opdele data</emphasis
|
|
> i feltet <guilabel
|
|
>For- og efternavn</guilabel
|
|
> i to separate felter: <guilabel
|
|
>Fornavn</guilabel
|
|
> og <guilabel
|
|
>Efternavn</guilabel
|
|
>. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><emphasis
|
|
>Opdele data</emphasis
|
|
> i feltet <guilabel
|
|
>Adresse</guilabel
|
|
> i tre separate felter: <guilabel
|
|
>Gade</guilabel
|
|
>, <guilabel
|
|
>Husnummer</guilabel
|
|
> og <guilabel
|
|
>By</guilabel
|
|
>. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><emphasis
|
|
>Garantere at data er rigtig:</emphasis
|
|
> ved at sikre dig at ingen felter er tomme, f.eks. skal husnummeret altid skrives ind. </para
|
|
></listitem>
|
|
</orderedlist>
|
|
|
|
<para
|
|
>En ændret tabel ser ud cirka sådan her: </para>
|
|
|
|
<para
|
|
><emphasis
|
|
>Persontabel</emphasis
|
|
></para>
|
|
<informaltable>
|
|
<tgroup cols="5">
|
|
<colspec colnum="1" colname="c1"
|
|
></colspec>
|
|
<colspec colnum="2" colname="c2"
|
|
></colspec>
|
|
<colspec colnum="3" colname="c3"
|
|
></colspec>
|
|
<colspec colnum="4" colname="c4"
|
|
></colspec>
|
|
<colspec colnum="5" colname="c5"
|
|
></colspec>
|
|
<tbody>
|
|
<row>
|
|
<entry
|
|
><emphasis
|
|
>Navn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Efternavn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Gade</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Husnummer</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>By</emphasis
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna</entry>
|
|
<entry
|
|
>Stricker</entry>
|
|
<entry
|
|
>Vesterport</entry>
|
|
<entry
|
|
>1</entry>
|
|
<entry
|
|
>Odense</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Emil</entry>
|
|
<entry
|
|
>Pedersen</entry>
|
|
<entry
|
|
>Madsensvej</entry>
|
|
<entry
|
|
>5</entry>
|
|
<entry
|
|
>Odense</entry>
|
|
</row>
|
|
<row>
|
|
<entry namest="c1" nameend="c5"
|
|
><emphasis
|
|
>Betingelser</emphasis
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>krævet felt</entry>
|
|
<entry
|
|
>krævet felt</entry>
|
|
<entry
|
|
>krævet felt</entry>
|
|
<entry
|
|
>krævet felt</entry>
|
|
<entry
|
|
>krævet felt</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para
|
|
>På grund af at betingelser <guilabel
|
|
>nødvendigt felt</guilabel
|
|
> 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. </para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="data-limiting">
|
|
<title
|
|
>Begrænset datavisning</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>For at begrænse <emphasis
|
|
>datavisningen</emphasis
|
|
> tilbyder databaseprogrammer <emphasis
|
|
>forespørgsler</emphasis
|
|
>, <emphasis
|
|
>formularer</emphasis
|
|
> og <emphasis
|
|
>rapporter</emphasis
|
|
>. </para>
|
|
<para
|
|
>En meget praktisk måde at begrænse på er følgende udvidede version af tabellen <guilabel
|
|
>Personer</guilabel
|
|
> som tidligere beskrevet: </para>
|
|
|
|
<para
|
|
><emphasis
|
|
>Persontabel</emphasis
|
|
></para>
|
|
<informaltable>
|
|
<tgroup cols="6">
|
|
<tbody>
|
|
<row>
|
|
<entry
|
|
><emphasis
|
|
>Navn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Efternavn</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Gade</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Husnummer</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>By</emphasis
|
|
></entry>
|
|
<entry
|
|
><emphasis
|
|
>Indkomst</emphasis
|
|
></entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Anna</entry>
|
|
<entry
|
|
>Stricker</entry>
|
|
<entry
|
|
>Vesterport</entry>
|
|
<entry
|
|
>1</entry>
|
|
<entry
|
|
>Odense</entry>
|
|
<entry
|
|
>23 000</entry>
|
|
</row>
|
|
<row>
|
|
<entry
|
|
>Emil</entry>
|
|
<entry
|
|
>Pedersen</entry>
|
|
<entry
|
|
>Madsensvej</entry>
|
|
<entry
|
|
>5</entry>
|
|
<entry
|
|
>Odense</entry>
|
|
<entry
|
|
>19 000</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para
|
|
>Lad os antage at den nys tilføjede søjle <guilabel
|
|
>Indkomst</guilabel
|
|
> indeholder fortrolige data. Hvordan kan du for eksempel dele personernes kontaktinformation med arbejdskolleger uden at <emphasis
|
|
>afsløre deres indkomst</emphasis
|
|
>? Dette er muligt hvis <emphasis
|
|
>du kun deler en forespørgsel og ikke hele tabellen</emphasis
|
|
>. Forespørgslen kunne vælge alle søjler undtagen søjlen <guilabel
|
|
>Indkomst</guilabel
|
|
>. I databaseverdenen er en sådan forespørgsel ofte kendt som en <guilabel
|
|
>visning</guilabel
|
|
>. </para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="performance-and-capacity">
|
|
<title
|
|
>Ydelse og kapacitet</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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: </para>
|
|
<itemizedlist>
|
|
<listitem
|
|
><para
|
|
>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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>Det samme gælder for søjler (felter) i tabellen. </para
|
|
></listitem>
|
|
</itemizedlist>
|
|
|
|
<para
|
|
>Sammen med <link linkend="data-limiting"
|
|
>Begrænset datavisning</link
|
|
> beskrevet i foregående paragraf, udgør disse kvaliteter fordelene ved databaser. </para>
|
|
|
|
</sect3>
|
|
|
|
<sect3 id="convenient-data-entry">
|
|
<title
|
|
>Dataindtastning</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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). </para>
|
|
</sect3>
|
|
|
|
<sect3 id="reports">
|
|
<title
|
|
>Rapporter</title>
|
|
<para
|
|
>Databaser muliggør gruppering, begrænsning og opsummering af data i form af en <emphasis
|
|
>rapport</emphasis
|
|
>. Regneark skrives ofte ud i form af små tabeller uden fuldstændig automatisk styring af sidebrud og layout af felter. </para>
|
|
</sect3>
|
|
|
|
<sect3 id="programming">
|
|
<title
|
|
>Programmering</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
</sect3>
|
|
|
|
<sect3 id="multiuse">
|
|
<title
|
|
>Flere brugere</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
</sect3>
|
|
|
|
<sect3 id="security">
|
|
<title
|
|
>Sikkerhed</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>Funktioner for at låse ved redigering eller kopiering af et regneark (eller en del af det) er lige så enkle at knække. </para>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="database-design">
|
|
<title
|
|
>Databasekonstruktion</title>
|
|
<para
|
|
>Databasedesignet kræver nøjagtig planlægning. Bemærk at ændring af design af tabellen <guilabel
|
|
>Kontakter</guilabel
|
|
> 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 <guilabel
|
|
>Adresse</guilabel
|
|
> i separate felter kræver forsigtigt og langtrukkent arbejde. </para>
|
|
<para
|
|
>For at undgå sådanne situationer, <emphasis
|
|
>gennemtænk databaseprojektet</emphasis
|
|
> 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. </para>
|
|
</sect1>
|
|
|
|
<sect1 id="who-needs-a-database">
|
|
<title
|
|
>Hvem behøver en database?</title>
|
|
<itemizedlist>
|
|
<title
|
|
>Bliv ved regneark hvis:</title>
|
|
<listitem
|
|
><para
|
|
>Dine behov er begrænsede og data aldrig vokser til store mængder (kan du virkelig forudsige det nu?) </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>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. </para
|
|
></listitem>
|
|
</itemizedlist>
|
|
|
|
<itemizedlist>
|
|
<title
|
|
>Overvej at bruge databaser hvis:</title>
|
|
<listitem
|
|
><para
|
|
>Din samling med data ekspanderer hvert uge.</para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
>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. </para
|
|
></listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="database-software">
|
|
<title
|
|
>Programmel til at oprette databaser</title>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>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. </para>
|
|
<para
|
|
>I 70'erne formulerede videnskaben teorien om relationsdatabaser (begreber såsom <firstterm
|
|
>tabel</firstterm
|
|
>, <firstterm
|
|
>post</firstterm
|
|
>, <firstterm
|
|
>søjle (felt)</firstterm
|
|
> og <firstterm
|
|
>relation</firstterm
|
|
> 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. </para>
|
|
<para
|
|
>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 <firstterm
|
|
>clusters</firstterm
|
|
>. Dette er imidlertid udenfor denne håndbogs rækkevidde. </para>
|
|
<para
|
|
>Indenfor området "mulige" databaser med grafisk brugergrænseflade for pc'er kan du vælge blandt følgende: </para>
|
|
|
|
<itemizedlist>
|
|
<listitem
|
|
><para
|
|
><ulink url="http://www.dbase.com/"
|
|
>DBase</ulink
|
|
>: 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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><ulink url="http://msdn.microsoft.com/vfoxpro/productinfo/overview/"
|
|
>FoxPro</ulink
|
|
>: 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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><ulink url="http://office.microsoft.com/access/"
|
|
>Microsoft Access</ulink
|
|
>: 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. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><ulink url="http://www.filemaker.com/"
|
|
>FileMaker</ulink
|
|
>: populært program som ligner MS Acess i enkelhed, som virker på Windows og MacIntosh platforme, tilbudt siden 1985. </para
|
|
></listitem>
|
|
<listitem
|
|
><para
|
|
><ulink url="http://www.kexi.pl/"
|
|
>&kexi;</ulink
|
|
>: 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 <ulink url="http://www.kde.org/"
|
|
>K-desktopmiljøet</ulink
|
|
>, dvs. et grafisk miljø for systemer med Unix/Linux. En betydningsfuld bidragyder til &kexi;s udvikling er firmaet OpenOffice Poland. </para
|
|
></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect1>
|
|
|
|
</appendix>
|