Kexi/Handbook/Introduction to Databases/Database and Spreadsheet/da: Difference between revisions

From KDE UserBase Wiki
(Importing a new version from external source)
No edit summary
 
(59 intermediate revisions by 2 users not shown)
Line 10: Line 10:
==== Hvordan er en database forskellig fra et regneark ====
==== 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:  
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)
* Tabellen er begrænset til to personer (der kunne selvfølgelig være hundrede eller tusinder af dem i en virkelig database)
Line 31: Line 31:
|}
|}


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å på dette trin?
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?
<span id="Referential data integrity"></span>
<span id="Referential data integrity"></span>
<span id="Referential data integrity"></span>
<span id="Referential data integrity"></span>
Line 38: Line 38:
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 &mdash; adressen knyttet til denne person vil være uvis; du har mistet 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 &mdash; adressen knyttet til denne person vil være uvis; du har mistet dataintegritet.  


Moreover there is no simple way of deleting a chosen person from the table since you have to remember about deleting all rows related to him or her.
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.
<span id="Data redundancy"></span>
<span id="Data redundancy"></span>
====Data redundancy====
<span id="Data redundancy"></span>
====Data redundans====


This is directly connected to the previous problem. In fields Name and surname and Address the same data is entered many times. This is typical of a spreadsheets' ineffective way of storing data because the database grows unnecessarily, thus requiring more computer resources (larger size of data and slower access).  
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å).  


How can you solve these problems with a database? You can split information into smaller chunks by creating an additional table '''''Persons''''' with only two columns: Name and surname and Address:  
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''''':  


{|class="tablecenter" style="border: 1px solid grey;"
{|class="tablecenter" style="border: 1px solid grey;"
|+ ''Persons table''
|+ ''Tabellen Personer''
! '''Name and surname''' !! '''Address'''
! '''Navn og efternavn''' !! '''Adresse'''
|-
|-
| Joan Smith || Western Gate 1, Warsaw
| Joan Smith || Western Gate 1, Warsaw
Line 55: Line 56:
|}
|}


Each row in the table '''''Persons''''' corresponds to a single person. Table '''''Contacts''''' is from now on a relation to the table '''''Persons'''''.
Hver række i tabellen '''''Personer''''' svarer til én person. Tabellen '''''Kontakter''''' er herefter en relation til tabellen '''''Personer'''''.
  <span id="Data_integrity_and_validity"></span>
  <span id="Data_integrity_and_validity"></span>
====Data integrity and validity====
====Data integritet and gyldighed====


Note the way data is entered in the fields '''Name and surname''' and '''Address'''. People entering data can be fallible, sometimes even negligent. In our sample data we have both different sequence of entering name and surname (Joan Smith and Smith Joan; Adam and ADAM) and many more ways of entering the same address. Surely you can think of many other ways.
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.


The above problem shows that e.g. when searching the telephone number of a person whose address is "Western Gate 1, Warsaw" you will not get a full result. You will get only one row instead of three. Moreover You will also not find all the telephone numbers searching for the value "Joan Smith" in the field '''Name and surname''', because "Smith Joan" will not fit to "Joan Smith".
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".


How can you solve these problems using a database? You can do this by changing the design of the table '''''Persons''''' by:  
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:  


# Dividing data in the field '''Name and surname''' into two separate fields: '''Name''' and '''Surname'''.  
# Del data i feltet '''''Navn og efternavn''''' i to adskilte felter: '''''Navn''''' og '''''Efternavn'''''.  
# Dividing data in the field '''Address''' into three separate fields: '''Street''', '''House number''' and '''City'''.  
# Del data i feltet '''''Adresse''''' i tre adskilte felter: '''''Gade''''', '''''Husnummer''''' og '''''By'''''.  
# Guaranteeing data correctness: by ensuring that no fields are empty, e.g. you must always enter house number.  
# Garantere datakorrekthed: ved at sikre at intet felt er tomt; f.eks. skal du altid angive et husnummer.  


A modified table looks something like this:
En modificeret tabel kan se sådan ud:


{|class="tablecenter" style="border: 1px solid grey;"
{|class="tablecenter" style="border: 1px solid grey;"
|+ ''Persons table''
|+ ''Tabellen Personer table''
! '''Name''' !! '''Surname''' !! '''Street''' !! '''House number''' !! '''City'''
! '''Navn''' !! '''Efternavn''' !! '''Gade''' !! '''Husnummer''' !! '''By'''
|-
|-
| Joan || Smith || Western Gate|| 1 || Warsaw
| Joan || Smith || Western Gate|| 1 || Warsaw
Line 81: Line 82:
| ''Conditions''
| ''Conditions''
|-
|-
| required field || required field || required field || required field || required field
| krævet felt || krævet felt || krævet felt || krævet felt || krævet felt
|}
|}


Thanks to introducing the condition required field we can be sure that the entered data is complete. In case of other tables you may of course allow omitting certain fields while entering data.  
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.  
<span id="Limiting data view"></span>
<span id="Limiting data view"></span>
====Limiting data view====
==== Begrænsning af viste data ====


A spreadsheet displays all rows and columns of the table which is bothersome in case of very large data sheets. You may of course filter and sort rows in spreadsheets, however you must be extra careful while doing so. Spreadsheet users are in risk of forgetting that their data view has been filtered what can lead to mistakes. For example, while calculating sums you may think you have 100 rows of data while in fact there are 20 rows more hidden.  
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.  


If you want to work on a small subset of data, e.g. to send it for others to edit, you can copy and paste it to another spreadsheet and after editing paste the changed data back to the main spreadsheet. Such "manual" editing may cause data loss or incorrect calculations.  
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.  


To limit the data view database applications offer queries, forms and reports.  
Databaser har forespørgsler, formularer og rapporter til at begrænse datavisningen.  


A very practical way of limiting is the following extended version of the previously described table '''''Persons''''':  
En meget praktisk metode til begrænsning er følgende udvidede version af den før beskrevne tabel '''''Personer''''':  


{|class="tablecenter" style="border: 1px solid grey;"
{|class="tablecenter" style="border: 1px solid grey;"
Line 105: Line 106:
|}
|}


Let's assume that the newly introduced column Income contains confidential data. How can you share e.g. contact details of the persons with your coworkers but without revealing their income? It is possible if you share only a query and not the whole table. The query could select all columns except for the column Income. In database world such a query is often known as a view.  
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.  
<span id="Performance_and_capacity"></span>
<span id="Performance_and_capacity"></span>
====Performance and capacity====
==== Ydelse og kapacitet ====


Your computer is probably quite fast, however you will easily see that it doesn't help with slow, large spreadsheets. Their low efficiency is first of all due to lack of indexes accelerating the process of data search (databases do offer them). Moreover if you use things like system clipboard, even copying data may become troublesome with time.  
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.  


Spreadsheets containing large data sets may take ages to open. A spreadsheet loads lots of data to the computer's memory while opening. Most of the data loaded are probably useless/unnecessary for you at the moment. Databases unlike spreadsheets load data from computer storage only when needed.  
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.  


In most cases you will not have to worry how the database stores its data. This means that unlike spreadsheets, databases do not care about:  
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:  


* The sequence of rows since you can order the rows according to your needs. Moreover, you can view the same data in many views with different orders.  
* 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.  


* The same goes for columns (fields) of the table.  
* Det samme gælder for tabellens søjler (felter).  


Together with [[#Limiting data view|Limiting data view]] described in the previous paragraph these qualities constitute the advantage of databases.  
Disse egenskaber sammen med [[Special:myLanguage/Kexi/Handbook/Introduction to Databases/Database and Spreadsheet#Limiting data view|Begrænsning af viste data]] beskrevet i det forrige afsnit udgør databasernes fordele.  
<span id="Data entry"></span>
<span id="Data entry"></span>
====Data entry====
==== Indskrivning af data ====


The latest editions of applications for creating spreadsheets enable you to design data-entry forms. Such forms are most useful if your data cannot be conveniently displayed in tabular view, e.g. if the text occupies too many rows or if all the columns do not fit on the screen.  
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.  


In this case the very way the spreadsheet works is problematic. Fields for data entry are placed loosely within the spreadsheet and very often are not secure against the user's (intentional or accidental) intervention.  
I disse situationer er selve den måde regnearket virker på 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.  
<span id="Reports"></span>
<span id="Reports"></span>
====Reports====
==== Rapporter ====


Databases enable grouping, limiting and summing up data in a form of a report. Spreadsheets are usually printed in a form of small tables without fully automatic control over page divisions and the layout of fields.  
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.  
<span id="Programming"></span>
<span id="Programming"></span>
====Programming====
==== Programmering ====


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.  
Databaseprogrammer har ofte regulære programmeringssprog. Nyere regneark har også denne funktion, men beregninger sker ved at ændre regnearkets felter og simpel kopiering af data uanset relevansen eller integritetsreglerne, som omtaltes i de forrige afsnit.  


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.  
Databehandling i et regneark foregår ofte via en grafisk brugerflade, hvilket kan gøre databehandlingen langsommere. Databaser er i stand til at arbejde i baggrunden uafhængigt af grafiske brugerflader.  
<span id="Multiuse"></span>
<span id="Multiuse"></span>
====Multiuse====
==== Flere brugere ====


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.  
Det er svært at forestille sig flere brugere af det samme regneark. Selv om det er teknisk muligt med de nyeste programmer, så kræver det megen diciplin, opmærksomhed og viden af brugerne, og dette kan ikke garanteres.  


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.  
En klassisk måde at dele data gemt i et regneark med andre er at sende en hel fil (ofte vedhæftet en e-mail) eller at gøre en regnearksfil tilgængelig på et computernetværk. Denne arbejdsform er ineffektiv for store grupper &ndash; data, som måske skal bruges på et bestemt tidspunkt kan være midlertidigt låst af en anden 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.  
Databaser er derimod blevet designet specielt til at kunne bruges af mange samtidigt. Selv i den simpleste udgave er det muligt at låse i tabellerne på rækkeniveau, hvilket gør det nemt at dele datatabeller.  
<span id="Security"></span>
<span id="Security"></span>
====Security====
==== Sikkerhed ====


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.  
Det har kun symbolsk betydning at sikre et regneark med en adgangskode. Efter at have gjort regnearket tilgængeligt på et computernetværk kan enhver, der kan kopiere filen bryde adgangskoden. Det er nogle gange ikke særligt svært, da adgangskoden gemmes i samme fil som regnearket.  


Features for edit locking or copy locking of a spreadsheet (or its part) is equally easy to break.  
Funktioner til låse et regneark (eller dele af det) for redigering eller kopiering er tilsvarende lette at bryde.  


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.  
Databaser (hvis de gemmes på en server og ikke i en fil) behøver ikke at være tilgængelige i en enkelt fil. Du tilgår dem over et computernetværk og skal som regel angive et brugernavn og en adgangskode. Du får kun tilgang til de dele (tabeller, formularer eller endda udvalgte rækker og søjler), som du har fået rettigheder til.  


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.
Rettigheder til tilgang bestemmer om man kan redigere eller blot læse data. Data, som du ikke har ret til at tilgå vil slet ikke blive sendt til din computer, så det er ikke lige så let at lave en kopi af data som med regnearksfiler.


{{Prevnext2
{{Prevnext2

Latest revision as of 09:50, 13 August 2012

Other languages:


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
Tabellen Kontakter
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:

Tabellen Personer
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:

  1. Del data i feltet Navn og efternavn i to adskilte felter: Navn og Efternavn.
  2. Del data i feltet Adresse i tre adskilte felter: Gade, Husnummer og By.
  3. 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:

Tabellen Personer table
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:

Persons table
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 regnearket virker på 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.

Programmering

Databaseprogrammer har ofte regulære programmeringssprog. Nyere regneark har også denne funktion, men beregninger sker ved at ændre regnearkets felter og simpel kopiering af data uanset relevansen eller integritetsreglerne, som omtaltes i de forrige afsnit.

Databehandling i et regneark foregår ofte via en grafisk brugerflade, hvilket kan gøre databehandlingen langsommere. Databaser er i stand til at arbejde i baggrunden uafhængigt af grafiske brugerflader.

Flere brugere

Det er svært at forestille sig flere brugere af det samme regneark. Selv om det er teknisk muligt med de nyeste programmer, så kræver det megen diciplin, opmærksomhed og viden af brugerne, og dette kan ikke garanteres.

En klassisk måde at dele data gemt i et regneark med andre er at sende en hel fil (ofte vedhæftet en e-mail) eller at gøre en regnearksfil tilgængelig på et computernetværk. Denne arbejdsform er ineffektiv for store grupper – data, som måske skal bruges på et bestemt tidspunkt kan være midlertidigt låst af en anden person.

Databaser er derimod blevet designet specielt til at kunne bruges af mange samtidigt. Selv i den simpleste udgave er det muligt at låse i tabellerne på rækkeniveau, hvilket gør det nemt at dele datatabeller.

Sikkerhed

Det har kun symbolsk betydning at sikre et regneark med en adgangskode. Efter at have gjort regnearket tilgængeligt på et computernetværk kan enhver, der kan kopiere filen bryde adgangskoden. Det er nogle gange ikke særligt svært, da adgangskoden gemmes i samme fil som regnearket.

Funktioner til låse et regneark (eller dele af det) for redigering eller kopiering er tilsvarende lette at bryde.

Databaser (hvis de gemmes på en server og ikke i en fil) behøver ikke at være tilgængelige i en enkelt fil. Du tilgår dem over et computernetværk og skal som regel angive et brugernavn og en adgangskode. Du får kun tilgang til de dele (tabeller, formularer eller endda udvalgte rækker og søjler), som du har fået rettigheder til.

Rettigheder til tilgang bestemmer om man kan redigere eller blot læse data. Data, som du ikke har ret til at tilgå vil slet ikke blive sendt til din computer, så det er ikke lige så let at lave en kopi af data som med regnearksfiler.

Retrieved from "https://userbase.kde.org/index.php?title=Kexi/Handbook/Introduction_to_Databases/Database_and_Spreadsheet/da&oldid=260933"