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.
650 lines
23 KiB
650 lines
23 KiB
15 years ago
|
<!--
|
||
|
|
<!DOCTYPE appendix PUBLIC "-//KDE//DTD DocBook XML V4.2-Based Variant V1.1//EN" "dtd/kdex.dtd" >
|
||
|
|
-->
|
||
|
|
|
||
|
|
<appendix id="database">
|
||
|
|
<title>Introduction to Databases</title>
|
||
|
|
|
||
|
|
<sect1 id="what-is-a-database">
|
||
|
|
<title>What Is a Database?</title>
|
||
|
|
<para>
|
||
|
|
You can define a database as a collection of data on one topic.
|
||
|
|
It is organised in a way allowing to easily browse the information,
|
||
|
|
make changes or add new items.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Look at this diagram for one of the above examples: a simple phone book.
|
||
|
|
</para>
|
||
|
|
<screenshot>
|
||
|
|
<screeninfo>A diagram of a phone number database</screeninfo>
|
||
|
|
<mediaobject>
|
||
|
|
<imageobject>
|
||
|
|
<imagedata fileref="contact-example.png" format="PNG"/>
|
||
|
|
</imageobject>
|
||
|
|
<textobject>
|
||
|
|
<phrase>A diagram of a phone number database</phrase>
|
||
|
|
</textobject>
|
||
|
|
</mediaobject>
|
||
|
|
</screenshot>
|
||
|
|
<para>
|
||
|
|
The above picture shows a set of two contacts each of which is
|
||
|
|
presented on a separate card. It appears that such a card can
|
||
|
|
constitute a single row in a table:
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para><emphasis><guilabel>Contacts</guilabel> table</emphasis></para>
|
||
|
|
<informaltable>
|
||
|
|
<tgroup cols="2">
|
||
|
|
<tbody>
|
||
|
|
<row>
|
||
|
|
<entry><guilabel>Name</guilabel></entry>
|
||
|
|
<entry><guilabel>Tel No.</guilabel></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan</entry>
|
||
|
|
<entry>699 23 43 12</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Adam</entry>
|
||
|
|
<entry>711 19 77 21</entry>
|
||
|
|
</row>
|
||
|
|
</tbody>
|
||
|
|
</tgroup>
|
||
|
|
</informaltable>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
<emphasis>Terms and definitions</emphasis>:
|
||
|
|
A single data which constitutes a part of a greater collection can be called a
|
||
|
|
<firstterm>row</firstterm> or more professionally a
|
||
|
|
<firstterm>record</firstterm>.
|
||
|
|
The collection is normally called a <firstterm>table</firstterm>.
|
||
|
|
Moreover, the most natural name for the table is one describing the data it
|
||
|
|
offers/stores which is <guilabel>Contacts</guilabel>.
|
||
|
|
Furthermore, each row in the table consists of <firstterm>columns</firstterm>
|
||
|
|
often also called <firstterm>fields</firstterm>. In the table
|
||
|
|
<guilabel>Contacts</guilabel> there are two columns (fields):
|
||
|
|
<guilabel>Name</guilabel> and <guilabel>Tel No.</guilabel>.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
For simple uses a single table can make up a <firstterm>database</firstterm>.
|
||
|
|
Many people consider these two equivalent.
|
||
|
|
As you will see, for real databases we usually need more than one table.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
To sum up, you have already got a simple database with one table
|
||
|
|
<guilabel>Contacts</guilabel>.
|
||
|
|
</para>
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
|
||
|
|
<sect1 id="database-and-spreadsheet">
|
||
|
|
<title>Database and Spreadsheet</title>
|
||
|
|
<para>
|
||
|
|
It is very likely that you have already used spreadsheet applications like
|
||
|
|
KSpread, OpenOffice.org Calc or Microsoft Excel. If so, you will probably
|
||
|
|
wonder: since both spreadsheets and databases have tables, why should I use
|
||
|
|
the latter?
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
While comparing spreadsheets and databases you may encounter the following issues which you will later see in greater detail:
|
||
|
|
</para>
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para><link linkend="referential-data-integrity">Referential
|
||
|
|
data integrity</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="data-redundyncy">Data redundancy</link>
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para><link linkend="data-integrity-and-validity">Data integrity
|
||
|
|
and validity</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="data-limiting">Limiting data view</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="performance-and-capacity">Performance and
|
||
|
|
capacity</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="convenient-data-entry">Convenient data entry</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="reports">Reports</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="programming">Programming</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="multiuse">Multiuse</link></para></listitem>
|
||
|
|
<listitem><para><link linkend="security">Security</link></para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
|
||
|
|
<sect2 id="difference-database-and-spreadsheet">
|
||
|
|
<title>How Is a Database Different From a Spreadsheet?</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Gradually exceeding the capacity of a mobile phone, expand your table
|
||
|
|
<guilabel>Contacts</guilabel> adding a column (field)
|
||
|
|
<guilabel>Address</guilabel>. Add more telephone numbers
|
||
|
|
(office, home) for each person and add surnames to names.
|
||
|
|
To make it simpler we assume the following:
|
||
|
|
</para>
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>the table is limited to two people (obviously,
|
||
|
|
there could be hundreds and thousands of them in a real
|
||
|
|
database)</para></listitem>
|
||
|
|
<listitem><para>there are no two persons with the same name and surname</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
<para><emphasis>Contacts table</emphasis></para>
|
||
|
|
<informaltable>
|
||
|
|
<tgroup cols="3">
|
||
|
|
<tbody>
|
||
|
|
<row>
|
||
|
|
<entry><emphasis>Name and surname</emphasis></entry>
|
||
|
|
<entry><emphasis>Tel</emphasis></entry>
|
||
|
|
<entry><emphasis>Address</emphasis></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan Smith</entry>
|
||
|
|
<entry>699 23 43 12</entry>
|
||
|
|
<entry>Western Gate 1, Warsaw</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Adam Willson</entry>
|
||
|
|
<entry>711 19 77 21</entry>
|
||
|
|
<entry>London, Frogs Drive 5</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan Smith</entry>
|
||
|
|
<entry>110 98 98 00</entry>
|
||
|
|
<entry>Western Gate 1</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Smith Joan</entry>
|
||
|
|
<entry>312 43 42 22</entry>
|
||
|
|
<entry>Warsaw, Western Gate 1</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>ADAM Willson</entry>
|
||
|
|
<entry>231 83 02 04</entry>
|
||
|
|
<entry>Frogs Drive 5, London</entry>
|
||
|
|
</row>
|
||
|
|
</tbody>
|
||
|
|
</tgroup>
|
||
|
|
</informaltable>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Such a table can be made both in a spreadsheet and in a database.
|
||
|
|
Using a spreadsheet is very easy, of couse. What problems do we
|
||
|
|
encounter at this stage?
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<sect3 id="referential-data-integrity">
|
||
|
|
<title>Referential data integrity</title>
|
||
|
|
<para>
|
||
|
|
Suppose you are using a spreadsheet and you need to change the address of at
|
||
|
|
least one person. You have a small problem: you often have to change the
|
||
|
|
address in many rows. For example, Joan takes three rows. A real problem
|
||
|
|
will arise if you forget to change one of the rows - the address asigned
|
||
|
|
to this person will be <emphasis>ambiguous</emphasis>, hence
|
||
|
|
<emphasis>your data loses integrity</emphasis>.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Moreover there is no simple way of deleting a chosen person from the table
|
||
|
|
since you have to remember about deleting all rows releted to him or her.
|
||
|
|
</para>
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
|
||
|
|
<sect3 id="data-redundyncy">
|
||
|
|
<title>Data redundancy</title>
|
||
|
|
<para>
|
||
|
|
This is directly connected to the previous problem. In fields
|
||
|
|
<guilabel>Name and surname</guilabel> and <guilabel>Address</guilabel>
|
||
|
|
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).
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
How can you solve these problems with a database? You can split information
|
||
|
|
into smaller chunks by creating an additional table <emphasis>Persons</emphasis>
|
||
|
|
with only two columns: <guilabel>Name and surname</guilabel>
|
||
|
|
and <guilabel>Address</guilabel>:
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para><emphasis><guilabel>Persons</guilabel> table</emphasis></para>
|
||
|
|
<informaltable>
|
||
|
|
<tgroup cols="2">
|
||
|
|
<tbody>
|
||
|
|
<row>
|
||
|
|
<entry><emphasis>Name and surname</emphasis></entry>
|
||
|
|
<entry><emphasis>Address</emphasis></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan Smith</entry>
|
||
|
|
<entry>Western Gate 1, Warsaw</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Adam Willson</entry>
|
||
|
|
<entry>Frogs Drive 5, London</entry>
|
||
|
|
</row>
|
||
|
|
</tbody>
|
||
|
|
</tgroup>
|
||
|
|
</informaltable>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Each row in the table <guilabel>Persons</guilabel> corresponds to a
|
||
|
|
<emphasis>single person</emphasis>. Table <guilabel>Contacts</guilabel>
|
||
|
|
is from now on a relation to the table <guilabel>Persons</guilabel>
|
||
|
|
<!--(see next paragraph)-->.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="data-integrity-and-validity">
|
||
|
|
<title>Data integrity and validity</title>
|
||
|
|
<para>
|
||
|
|
Note the way data is entered in the fields <guilabel>Name and surname</guilabel>
|
||
|
|
and <guilabel>Address</guilabel>. 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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
The above problem shows that ⪚ 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 <guilabel>Name and surname</guilabel>, because "Smith Joan" will
|
||
|
|
not fit to "Joan Smith".
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
How can you solve these problems using a database? You can do this by changing the design of the table <guilabel>Persons</guilabel> by:
|
||
|
|
</para>
|
||
|
|
<orderedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Dividing data</emphasis> in the field <guilabel>Name and
|
||
|
|
surname</guilabel> into two separate fields: <guilabel>Name</guilabel>
|
||
|
|
and <guilabel>Surname</guilabel>.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Dividing data</emphasis> in the field <guilabel>Address</guilabel>
|
||
|
|
into three separate fields: <guilabel>Street</guilabel>, <guilabel>House
|
||
|
|
number</guilabel> and <guilabel>City</guilabel>.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<emphasis>Guaranteeing data correctness:</emphasis> by ensuring that no fields
|
||
|
|
are empty, ⪚ you must always enter house number.
|
||
|
|
</para></listitem>
|
||
|
|
</orderedlist>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
A modified table looks something like this:
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para><emphasis>Persons table</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>Name</emphasis></entry>
|
||
|
|
<entry><emphasis>Surname</emphasis></entry>
|
||
|
|
<entry><emphasis>Street</emphasis></entry>
|
||
|
|
<entry><emphasis>House number</emphasis></entry>
|
||
|
|
<entry><emphasis>City</emphasis></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan</entry>
|
||
|
|
<entry>Smith</entry>
|
||
|
|
<entry>Western Gate</entry>
|
||
|
|
<entry>1</entry>
|
||
|
|
<entry>Warsaw</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Adam</entry>
|
||
|
|
<entry>Willson</entry>
|
||
|
|
<entry>Frogs Drive</entry>
|
||
|
|
<entry>5</entry>
|
||
|
|
<entry>London</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry namest="c1" nameend="c5"><emphasis>Conditions</emphasis></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>required field</entry>
|
||
|
|
<entry>required field</entry>
|
||
|
|
<entry>required field</entry>
|
||
|
|
<entry>required field</entry>
|
||
|
|
<entry>required field</entry>
|
||
|
|
</row>
|
||
|
|
</tbody>
|
||
|
|
</tgroup>
|
||
|
|
</informaltable>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Thanks to introducing the condition <guilabel>required field</guilabel> 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.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="data-limiting">
|
||
|
|
<title>Limiting data view</title>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
If you want to work on a small subset of data, ⪚ 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 incorect calculations.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
To limit the <emphasis>data view</emphasis> database applications offer
|
||
|
|
<emphasis>queries</emphasis>, <emphasis>forms</emphasis>
|
||
|
|
and <emphasis>reports</emphasis>.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
A very practical way of limitting is the following extended version of
|
||
|
|
the previously described table <guilabel>Persons</guilabel>:
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<para><emphasis>Persons table</emphasis></para>
|
||
|
|
<informaltable>
|
||
|
|
<tgroup cols="6">
|
||
|
|
<tbody>
|
||
|
|
<row>
|
||
|
|
<entry><emphasis>Name</emphasis></entry>
|
||
|
|
<entry><emphasis>Surname</emphasis></entry>
|
||
|
|
<entry><emphasis>Street</emphasis></entry>
|
||
|
|
<entry><emphasis>House number</emphasis></entry>
|
||
|
|
<entry><emphasis>City</emphasis></entry>
|
||
|
|
<entry><emphasis>Income</emphasis></entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Joan</entry>
|
||
|
|
<entry>Smith</entry>
|
||
|
|
<entry>Western Gate</entry>
|
||
|
|
<entry>1</entry>
|
||
|
|
<entry>Warsaw</entry>
|
||
|
|
<entry>2300</entry>
|
||
|
|
</row>
|
||
|
|
<row>
|
||
|
|
<entry>Adam</entry>
|
||
|
|
<entry>Willson</entry>
|
||
|
|
<entry>Frogs Drive</entry>
|
||
|
|
<entry>5</entry>
|
||
|
|
<entry>London</entry>
|
||
|
|
<entry>1900</entry>
|
||
|
|
</row>
|
||
|
|
</tbody>
|
||
|
|
</tgroup>
|
||
|
|
</informaltable>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Let's assume that the newly introduced column <guilabel>Income</guilabel>
|
||
|
|
contains confidential data. How can you share ⪚ contact details of the
|
||
|
|
persons with your coworkers but without <emphasis>revealing their
|
||
|
|
income</emphasis>? It is possible if <emphasis>you share only a query and
|
||
|
|
not the whole table</emphasis>. The query could select all columns except
|
||
|
|
for the column <guilabel>Income</guilabel>. In database world such a query
|
||
|
|
is often known as a <guilabel>view</guilabel>.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="performance-and-capacity">
|
||
|
|
<title>Performance and capacity</title>
|
||
|
|
<para>
|
||
|
|
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 accelertaing 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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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/unneccessary for you at the moment. Databases
|
||
|
|
unlike spreadsheets load data from computer storage only when needed.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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:
|
||
|
|
</para>
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
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.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
The same goes for columns (fields) of the table.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Together with <link linkend="data-limiting">Limiting data view</link>
|
||
|
|
described in the previous paragraph these qualities constitute the
|
||
|
|
advantage of databases.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="convenient-data-entry">
|
||
|
|
<title>Data entry</title>
|
||
|
|
<para>
|
||
|
|
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, ⪚ if the text occupies
|
||
|
|
too many rows or if all the columns do not fit on the screen.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="reports">
|
||
|
|
<title>Reports</title>
|
||
|
|
<para>
|
||
|
|
Databases enable grouping, limiting and summing up data in a form of a
|
||
|
|
<emphasis>report</emphasis>. Spreadsheets are usually printed in a form
|
||
|
|
of small tables without fully automatic control over page divisions and
|
||
|
|
the layout of fields.
|
||
|
|
</para>
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="programming">
|
||
|
|
<title>Programming</title>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="multiuse">
|
||
|
|
<title>Multiuse</title>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
</sect3>
|
||
|
|
|
||
|
|
<sect3 id="security">
|
||
|
|
<title>Security</title>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Features for edit locking or copy locking of a spreadsheet (or its part)
|
||
|
|
is equally easy to break.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
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.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Access rights can affect ability of data editing or only data reading.
|
||
|
|
If any data is not avaliable 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.
|
||
|
|
</para>
|
||
|
|
|
||
|
|
</sect3>
|
||
|
|
</sect2>
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
<sect1 id="database-design">
|
||
|
|
<title>Database Design</title>
|
||
|
|
<para>
|
||
|
|
Database design needs careful planning. Note that <guilabel>Contacts</guilabel>
|
||
|
|
table redesign proposed in section 1.2 can generate problems when the
|
||
|
|
table is filled with data. For example, renaming a field is a simple task,
|
||
|
|
but splitting the <guilabel>Address</guilabel> field into separate fields
|
||
|
|
requires careful and tedious work.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
To avoid such situations, <emphasis>rethink your database project</emphasis>
|
||
|
|
before you create it in your computer, and before you and others will start
|
||
|
|
to use it. Thus, by investing some time initially, you will most probably
|
||
|
|
save your time on everyday use.
|
||
|
|
</para>
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
<sect1 id="who-needs-a-database">
|
||
|
|
<title>Who Needs a Database?</title>
|
||
|
|
<itemizedlist>
|
||
|
|
<title>Stick to spreadsheets if:</title>
|
||
|
|
<listitem><para>
|
||
|
|
Your needs are limited and your data will never grow to
|
||
|
|
large volumes (can you actually forecast that now?)
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
You are unable to acquire the methodology of database construction.
|
||
|
|
You may however consider either outsourcing this task to someone else
|
||
|
|
or using simpler tools.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
You use complicated spreadsheets and you lack time or money to switch
|
||
|
|
to databases. Think or ask someone whether this does not lead down a
|
||
|
|
blind alley. Don't count on magical tools that would change your
|
||
|
|
spreadsheet (regardless how well made) into a database.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<title>Consider using databases if:</title>
|
||
|
|
<listitem><para>Your data collection expands every week.</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
You often create new spreadsheets, copy within these and you feel
|
||
|
|
that this work is getting more and more tedious. In this case the
|
||
|
|
effort of switching to databases easily pays off.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
You create reports and statements for which the table view of
|
||
|
|
a spreadsheet is not suitable. You can then consider switch
|
||
|
|
to using a database with form views.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
<sect1 id="database-software">
|
||
|
|
<title>Database Creation Software</title>
|
||
|
|
<para>
|
||
|
|
So far you have learnt the general characteristics of databases without
|
||
|
|
going into much detail about specific applications for designing them.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
The first databases were built together with large mainframe computers
|
||
|
|
in the 60s, ⪚ IBM System/360. Those were not the days of PCs,
|
||
|
|
therefore these databases required a highly specialized personnel.
|
||
|
|
Although the old computers' hardware was unreliable, they were immeasurably
|
||
|
|
slower and had less storage capacity, one feature of databases still remains
|
||
|
|
most attractive: the data access by many users through a network.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
In the 70s scientists formed the theory of relational databases
|
||
|
|
(terms like: <firstterm>table</firstterm>, <firstterm>record</firstterm>,
|
||
|
|
<firstterm>column (field)</firstterm> and <firstterm>relationality</firstterm>
|
||
|
|
and many others).
|
||
|
|
On the basis of this theory IBM DB2 and Oracle databases were created,
|
||
|
|
which have been developed and used till today. In the late 70s the first
|
||
|
|
PCs were constructed. Their users could (gradually) utilize many types of
|
||
|
|
applications, including those for database construction.
|
||
|
|
</para>
|
||
|
|
<para>When it comes to large databases in companies, the situation
|
||
|
|
hasn't changed:
|
||
|
|
they still require powerful computers or computer complexes called
|
||
|
|
<firstterm>clusters</firstterm>. This goes, however, beyond the topic
|
||
|
|
of this manual.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
In the area of "accessible" databases with graphic user interface
|
||
|
|
for PCs you can choose from the following:
|
||
|
|
</para>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url="http://www.dbase.com/">DBase</ulink>
|
||
|
|
- a tool for databases operation for DOS popular in the 80s. Files in DBase format
|
||
|
|
are still used in some specific cases due to their simplicity.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url="http://msdn.microsoft.com/vfoxpro/productinfo/overview/">FoxPro</ulink>
|
||
|
|
- an application similar to DBase (early 90s). After being taken over by
|
||
|
|
Microsoft, graphic user interfaces were introduced and therefore it is
|
||
|
|
used for creating databases on PCs. This product is still offered, though
|
||
|
|
seems a bit obsolete.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url="http://office.microsoft.com/access/">Microsoft Access</ulink>
|
||
|
|
- an application for databases (data and graphic interface design) with many
|
||
|
|
simplifications, therefore suitable for beginners, designed in the late 80s,
|
||
|
|
based on 16-Bit Architecture. This product is offered and widely used till today, especially
|
||
|
|
by small companies, where efficiency and multiuser requirements are not very demanding.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url="http://www.filemaker.com/">FileMaker</ulink>
|
||
|
|
- popular application similar to MS Access in simplicity, operating on Windows
|
||
|
|
and Macintosh platforms, offered since 1985.
|
||
|
|
</para></listitem>
|
||
|
|
<listitem><para>
|
||
|
|
<ulink url="http://www.kexi.pl/">&kexi;</ulink>
|
||
|
|
- a multiplatform application (Unix/Linux, Windows, Mac OS X) designed in 2003,
|
||
|
|
developed according to OpenSource principles, part of the global
|
||
|
|
<ulink url="http://www.kde.org/">K Desktop Environment</ulink> project,
|
||
|
|
&ie; graphic environment for Unix/Linux systems. A significant contributor
|
||
|
|
to &kexi;'s development is the OpenOffice Poland company.
|
||
|
|
</para></listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
|
||
|
|
</sect1>
|
||
|
|
|
||
|
|
</appendix>
|