1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
<H2>1.2. A database and a spreadsheet</H2>
<p>
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?
</p>
<p>
While comparing spreadsheets and databases you may encounter the following issues which you will later see in greater detail:
</p>
<ul>
<li><a href="#ref_integrity">Referential data integrity</a></li>
<li><a href="#data_redundancy">Data redundancy</a></li>
<li><a href="#data_integrity">Data integrity and validity</a></li>
<li><a href="#data_limiting">Data limiting</a></li>
<li><a href="#performance">Performance and capacity</a></li>
<li><a href="#data_entry">Convenient data entry</a></li>
<li><a href="#reports">Reports</a></li>
<li><a href="#programming">Programming</a></li>
<li><a href="#multiuse">Multiuse</a></li>
<li><a href="#security">Security</a></li>
</ul>
<H3>How is a database different from a spreadsheet?</H3>
<p>
Gradually exceeding the capacity of a mobile phone, expand your table <em>Contacts</em> adding a column (field) <em>Address</em>. Add more telephone numbers (office, home) for each person and add surnames to names. To make it simpler we assume the following:
</p>
<ul>
<li>the table is limited to two people (obviously, there could be hundreds and thousands of them in a real database)</li>
<li>there are no two persons with the same name and surname</li>
</ul>
<p>
<table border="1" cellspacing="0" cellpadding="2">
<tr><td colspan="3"><b>Contacts</b></td></tr>
<tr><td><b>Name and surname</b></td><td><b>Tel</b></td><td><b>Address</b></td></tr>
<tr><td>Joan Smith</td><td>699 23 43 12</td><td>Western Gate 1, Warsaw</td></tr>
<tr><td>Adam Willson</td><td>711 19 77 21</td><td>London, Frogs Drive 5</td></tr>
<tr><td>Joan Smith</td><td>110 98 98 00</td><td>Western Gate 1</td></tr>
<tr><td>Smith Joan</td><td>312 43 42 22</td><td>Warsaw, Western Gate 1</td></tr>
<tr><td>ADAM Willson</td><td>231 83 02 04</td><td>Frogs Drive 5, London</td></tr>
</table>
</p>
<p>
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?
<a name="ref_integrity"></a>
<h4>Referential data integrity</h4>
<p>
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 lines. For example, Joan takes three lines. A real problem will arise if you forget to change one of the lines - the address asigned to this person will be <b>ambiguous</b>, hence <b>your data loses integrity</b>.
</p>
<p>
Moreover there is no simple way of deleting a chosen person from the table since you have to remember about deleting all the lines releted to him or her.
</p>
<a name="data_redundancy"></a>
<h4>Data redundancy</h4>
<p>
This is directly connected to the previous problem. In fields <em>Name and surname</em> and <em>Address</em> the same data is entered many times. This is typical of spreadsheets, ineffective way of storing data because the database grows unnecessarily, thus requiring more computer resources (larger size of data and slower access).
</p>
<p>How can you solve these problems with a database? You can split information into smaller chunks by creating additional table <em>Persons</em> with only two columns: <em>Name and suname</em> and <em>Address</em>:
</p>
<p>
<p>
<table border="1" cellspacing="0" cellpadding="2">
<tr><td colspan="2"><b>Persons</b></td></tr>
<tr><td><b>Name and surname</b></td><td><b>Address</b></td></tr>
<tr><td>Joan Smith</td><td>Western Gate 1, Warsaw</td></tr>
<tr><td>Adam Willson</td><td>Frogs Drive 5, London</td></tr>
</table>
</p>
<p>
Each line in the table <em>Persons</em> corresponds to a <b>single person</b>.
Table <em>Contacts</em> is from now <b>in a relation</b> to the table <em>Persons</em> (see next paragraph).
</p>
<a name="data_integrity"></a>
<h4>Data integrity and validity</h4>
<p>
Note the way data is entered in fields <em>Name and surname</em> and <em>Address</em>. 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.
</p>
<p>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 line instead of three. Moreover You will also not find all the telephone numbers searching for the value "Joan Smith" in the field <em>Name and surname</em>, because "Smith Joan" will not fit to "Joan Smith".
</p>
<p>How can you solve these problems using a database? You can do this by changing the design of the table <em>Persons</em> by:
</p>
<p>
<ol>
<li><p><b>Dividing data</b> in the field <em>Name and surname</em> into two separate fields: <em>Name</em> and <em>Surname</em>.
</p></li>
<li><p><b>Dividing data</b> in the field <em>Address</em> into three separate fields <em>Street</em>, <em>House number</em> and <em>Town</em>.
</p></li>
<li><p><b>Guaranteeing data correctness:</b> by ensuring that no fields are empty, e.g. you must always enter house number.
</p>
</ol>
</p>
<p>
A modified table looks something like this:
</p>
<p>
<table border="1" cellspacing="0" cellpadding="2">
<tr><td colspan="5"><b>Persons</b></td></tr>
<tr><td><b>Name</b></td><td><b>Surname</b></td><td><b>Street</b></td><td><b>House number</b></td><td><b>City</b></td></tr>
<tr><td>Joan</td><td>Smith</td><td>Western Gate</td><td>1</td><td>Warsaw</td></tr>
<tr><td>Adam</td><td>Willson</td><td>Frogs Drive</td><td>5</td><td>London</td></tr>
<tr><td colspan="5"><b>Conditions</b></td></tr>
<tr><td>required<br>field</td><td>required<br>field</td><td>required<br>field</td><td>required<br>field</td><td>required<br>field</td></tr>
</table>
</p>
<p>
Thanks to introducing conditions <em>required field</em> 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.
</p>
<a name="data_limiting"></a>
<h4>Limiting data view</h4>
<p>
Spreadsheet displays all lines and columns of the table which is bothersome in case of very large data sheets. You may of course filter and sort lines 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.
</p>
<p>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 incorect calculations.
</p>
<p>To limit the <b>data view</b> database applications offer <em>queries</em>, <em>forms</em> and <em>reports</em>.
</p>
<p>A very practical way of limitting is the following extended version of the previously described table <em>Persons</em>:
</p>
<p>
<table border="1" cellspacing="0" cellpadding="2">
<tr><td colspan="6"><b>Persons</b></td></tr>
<tr><td><b>Name</b></td><td><b>Surname</b></td><td><b>Street</b></td><td><b>House number</b></td><td><b>City</b></td><td><b>Income</b></td></tr>
<tr><td>Joan</td><td>Smith</td><td>Western Gate</td><td>1</td><td>Warsaw</td><td>2300</td></tr>
<tr><td>Adam</td><td>Willson</td><td>Frogs Drive</td><td>5</td><td>London</td><td>1900</td></tr>
</table>
</p>
<p>
Let's assume that the newly introduced column <em>Income</em> contains confidential data. How can you share e.g. contact details of the persons with your coworkers but without <b>revealing their income</b>? It is possible if <b>you share only a query and not the whole table</b>. The query could select all columns except for the column <em>Income</em>. In database world such a query is often known as a <em>view</em>
</p>
<a name="performance"></a>
<h4>Performance and capacity</h4>
<p>
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.
</p>
<p>Spreadsheets containing large data sets may take ages to open. 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.
</p>
<p>
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:
</p>
<ul>
<li>
The sequence of lines since you can order the lines according to your needs. Moreover, you can view the same data in many views with different orders. </li>
<li>The same goes for columns (fields) of the table.</li>
</ul>
</p>
<p>
Together with <em>Limiting data view</em> described in the previous paragraph these qualities constitute the advantage of databases.
</p>
<a name="data_entry"></a>
<h4>Data entry
</h4>
<p>
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 lines or if all the columns do not fit on the screen.
</p>
<p>
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.
</p>
<a name="reports"></a>
<h4>Reports</h4>
<p>
Databases enable grouping, limiting and summing up data in a form of a <em>report</em>. Spreadsheets are usually printed in a form of small tables without fully automatic control over page divisions and the layout of fields.
</p>
<a name="programming"></a>
<h4>Programming</h4>
<p>
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 an integrity rules mentioned in previous paragraphs.
</p>
<p>
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.
</p>
<a name="multiuse"></a>
<h4>Multiuse</h4>
<p>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.
</p>
<p>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.
</p>
<p>
On the other hand, databases have been designed mainly with multiuser access in mind. Even for simplest version locking at particular table row's level is possible, what enables easy sharing of table data.
</p>
<a name="security"></a>
<h4>Security</h4>
<p>
Securing a spreadsheet or its particular sections with a password is only symbolic activity.
After providing a spreadsheet file in 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.
</p>
<p>Features for edit locking or copy locking of a spreadsheet (or its part) is equally easy to break.
</p>
<p>
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) whose were assigned to you by setting appropriate access rights.
</p>
<p>
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.
</p>
|
