Kexi/Håndbog/Introduktion til databaser/Database og regneark
Database og regneark
Du har sandsynligvis allerede brugt et regneark som Calligra Sheets, LibreOffice Calc eller Microsoft Excel. I så fald tænker du nok: da både regneark og databaser har tabeller, hvorfor skulle jeg så bruge en database?
Under sammenligningen af regneark og databaser vil du måske støde på følgende emner, som du senere vis se i større detalje.
Hvordan er en database forskellig fra et regneark
Udvid din tabel Kontakter ved at tilføje en søjle (et felt) kaldet Adresse. Tilføj flere telefonnumre (kontor og hjem) for hver person og tilføj efternavne til navnet. For at forenkle tingene antager vi følgende:
- Tabellen er begrænset til to personer (der kunne selvfølgelig være hundrede eller tusinder af dem i en virkelig database)
- Der er ikke mere end en person med et givet efternavn
| Navn og efternavn | Tlf | Adresse |
|---|---|---|
| Joan Smith | 699 23 43 12 | Western Gate 1, Warsaw |
| Adam Willson | 711 19 77 21 | London, Frogs Drive 5 |
| Joan Smith | 110 98 98 00 | Western Gate 1 |
| Smith Joan | 312 43 42 22 | Warsaw, Western Gate 1 |
| ADAM Willson | 231 83 02 04 | Frogs Drive 5, London |
Sådan en tabel kan både laves i et regneark og i en database. Det er selvfølgelig meget let at bruge et regneark. Hvilke problemer støder vi på i dette trin?
Referentiel dataintegritet
Antag, at du bruger et regneark og skal ændre en persons adresse. Du har så et lille problem: du vil ofte skulle ændre adressen flere steder. For eksempel findes Joan i tre rækker. Hvis du glemmer at ændre en af disse rækker, så opstår der et reelt problem — adressen knyttet til denne person vil være uvis; du har mistet dataintegritet.
Desuden er der ingen enkel måde at slette eller vælge en person fra tabellen, da du skal huske at slette alle de rækker, hvor vedkommende findes.
Data redundans
Dette er indirekte forbundet med det foregående problem. I felterne Navn og efternavn og Adresse er de samme data opgivet mange gange. Det er typisk for et regnearks ineffektive måde at gemme data; databasen vokser unødvendigt og kræver således flere computerressourcer (data fylder mere og er langsommere at tilgå).
Hvordan kan du løse disse problemer med en database? Du kan dele informationen i mindre bidder ved at lave endnu en tabel, Personer med kun to søjler: Navn og efternavn og Adresse:
| Navn og efternavn | Adresse |
|---|---|
| Joan Smith | Western Gate 1, Warsaw |
| Adam Willson | Frogs Drive 5, London |
Hver række i tabellen Personer svarer til én person. Tabellen Kontakter er herefter en relation til tabellen Personer.
Data integritet and gyldighed
Bemærk, hvordan data er indskrevet i felterne Navn og efternavn og Adresse. De, der indskriver data er fejlbarlige, nogle gange endda skødesløse. I vore eksempeldata har vi både forskellige rækkefølger ved angivelse af navn og efternavn (Joan Smith og Smith Joan; Adam og ADAM) og mange flere måder at angive den samme adresse. Du kan utvivlsomt komme på andre måder.
Ovennævnte problem viser, at når du f.eks. søger efter telefonnummeret for en person, hvis adresse er "Western Gate 1, Warsaw", så finder du ikke det fulde resultat. Du vil kun finde en række, ikke tre. På tilsvarende måde vil du ikke telefonnumre hvis du søger på værdien "Joan Smith" i feltet Navn og efternavn, fordi "Smith Joan" ikke matcher med "Joan Smith".
Hvordan kan du løse disse problemer ved brug af en database? Du kan gøre det ved at ændre designet af tabellen Person således:
- Del data i feltet Navn og efternavn i to adskilte felter: Navn og Efternavn.
- Del data i feltet Adresse i tre adskilte felter: Gade, Husnummer og By.
- Garantere datakorrekthed: ved at sikre at intet felt er tomt; f.eks. skal du altid angive et husnummer.
En modificeret tabel kan se sådan ud:
| Navn | Efternavn | Gade | Husnummer | By |
|---|---|---|---|---|
| Joan | Smith | Western Gate | 1 | Warsaw |
| Adam | Willson | Frogs Drive | 5 | London |
| Conditions | ||||
| krævet felt | krævet felt | krævet felt | krævet felt | krævet felt |
Ved at introducere betingelsen Krævet felt kan vi sikre, at de indskrevne data er fuldstændige. I nogle tilfælde kan du selvfølgelig tillade at nogle felter springes over.
Begrænsning af viste data
Et regneark viser alle tabellens rækker og søjler, hvilket er et problem når man arbejder med meget store dataark. Du kan selvfølgelig filtrere og sortere rækker i regnearket, men du skal være ekstra forsigtig når du gør det. Brugere af regneark risikerer at glemme, at deres datavisning er blevet filtreret, hvilket kan føre til fejtagelser. Når du for eksemple beregner summer, så tror du måske at du har 100 rækker, mens du i virkeligheden har yderligere 20 skjulte rækker.
Hvis du ønsker at arbejde med en lille del af dine data, f.eks. for at sende dem til andre til redigering, så kan du kopiere dem og indsætte dem i et andet regneark; og efter redigering kan du sætte de ændrede data tilbage i hovedregnearket. Sådanne "manuelle" redigeringer kan forårsage datatab eller forkerte beregninger.
Databaser har forespørgsler, formularer og rapporter til at begrænse datavisningen.
En meget praktisk metode til begrænsning er følgende udvidede version af den før beskrevne tabel Personer:
| Name | Surname | Street | House number | City | Income |
|---|---|---|---|---|---|
| Joan | Smith | Western Gate | 1 | Warsaw | 2300 |
| Adam | Willson | Frogs Drive | 5 | London | 1900 |
Lad os antage, at den nyligt introducerede søjle indeholder fortrolige data. Hvordan kan du dele personernes kontaktdetaljer med dine kolleger uden at afsløre deres inkomst.? Det er muligt ved kun at dele en forespørgsel, ikke hele tabellen. Forespørgslen kunne udvælge alle søjler undtagen søjlen med inkomst. I databaseverdenen kaldes sådan en forespørgsel ofte for et view.
Ydelse og kapacitet
Din computer er sikkert ret hurtig, men du opdager let, at det ikke hjælper på store, langsomme regneark. Deres ringe effektivitet skyldes først og fremmest at de ikke bruger indeksering til at accelerere datasøgning (i modsætning til databaser). Og hvis du bruger udklipsholder eller lignende, så kan selv kopiering af data blive besværligt efterhånden.
Det kan tage evigheder at åbne regneark med store datasæt. Et regneark indlæser masser af data i computerens hukommelse mens den åbner. De fleste data skal du sikkert ikke bruge denne gang. I modsætning hertil indlæser en database kun data fra det permanante lager når de skal bruges.
I de fleste tilfælde behøver du ikke at bekymre dig om, hvordan databasen gemmer sine data. Dette betyder, at databaser i modsætning til regneark er ligeglade med:
- Rækkernes rækkefølge, da du kan ordne rækkerne efter dine behov. Desuden kan du få de samme data vist i mange forskellige views i forskellig orden.
- Det samme gælder for tabellens søjler (felter).
Disse egenskaber sammen med Begrænsning af viste data beskrevet i det forrige afsnit udgør databasernes fordele.
Indskrivning af data
De seneste udgaver af regnearksprogrammer lader dig designe formularer til indskrivning af data. Sådanne formularer er nyttigst, hvis dine data ikke så let kan vises i en tabel, f.eks. hvis teksten fylder for mange rækker eller hvis alle søjler ikke kan være på skærmen.
I disse situationer er selve den måde regnearken virker problematisk. Felter til indskrivning af data placeres lidt tilfældigt i regnearket og ofte er de ikke særligt sikre imod brugerens (bevidste eller ubevidste) indblanding.
Rapporter
Databaser muliggør gruppering, begrænsning og opsummering af data i form af en rapport. Regneark bliver sædvanligvis udskrevet i form af små tabeller uden helt automatisk kontrol over sideopdeling og felternes layout.
Programming
Applications for creating databases often contain full programming languages. Newer spreadsheets have this capability too, however calculations come down to modifying the spreadsheet's fields and simple data copying, regardless of the relevance and integrity rules mentioned in previous paragraphs.
Data processing within a spreadsheet is usually done via a graphical user's interface which may slow down the data processing speed. Databases are capable of working in background, outside of graphical interfaces.
Multiuse
It is hard to imagine a multiuse of one spreadsheet. Even if it is technically possible in the case of the latest applications, it requires a lot of discipline, attention and knowledge from the users, and these cannot be guaranteed.
A classical way to sharing data saved in a spreadsheet with other person is to send a file as a whole (usually using e-mail) or providing a spreadsheet file in a computer network. This way of work is ineffective for larger groups of people - data that could be needed in a particular time may be currently locked by another person.
On the other hand, databases have been designed mainly with multiuser access in mind. Even for the simplest version locking at a particular table row's level is possible, which enables easy sharing of table data.
Security
Securing a spreadsheet or its particular sections with a password is only symbolic activity. After providing a spreadsheet file in a computer network, every person being able to copy the file can try to break the password. It is sometimes not so hard as the password is stored in the same file as the spreadsheet.
Features for edit locking or copy locking of a spreadsheet (or its part) is equally easy to break.
Databases (except these saved in a file instead of a server) do not need to be available in a single file. You're accessing them using a computer network, usually by providing a user name and a password. You are gaining access only to these areas (tables, forms or even selected rows and columns) which were assigned to you by setting appropriate access rights.
Access rights can affect ability of data editing or only data reading. If any data is not available to you, it will not be even sent to your computer, so there is no possibility of making a copy of the data in such easy way as in case of spreadsheet files.