Catálogo de publicaciones - libros

Chapter 1 of Sir Henry Birkin’s autobiography “Full Throttle”, published in 1932, ends with the following: “I can waste no more time on this matter; for the end is reached of what I now confess to have been 24 pages of deceit. I have disguised under the designation of Chapter One what was really nothing more than an introduction; but I know quite well, that had I been honest and called it an introduction, nobody would have read it.”

The first database you ever build is likely to do something relatively simple, such as keeping a list of your customers or friends.

Tables are containers for holding data which is similar in structure. If you collected information about your employees, the data about each would be similar and would therefore make the contents of a perfectly satisfactory table.

Creating a database and then entering all the data takes time and effort. Simply creating a database is not an end in itself; unless you are one of those sad people (like me) who actually enjoys that sort of thing, there has to be some gain for the pain. That gain lies in the easy access to the data provided by an electronic database.

Data resides in the tables, but a database is more than simply data. It also includes components that are used as tools to look at, enter, delete and manipulate that data. Those components are called forms.

Reports are rather like queries in that they can be used to summarize the information in a database. One difference is that reports usually produce printed output, or produce web-based output that can be printed as required. Suppose that, at the end of every month, you need to produce a list of all invoices issued in that month, together with their individual values and a total. The best method is to use a report.

Tables, forms, reports and queries are the core components of a database. So far I have described each in isolation. However, when they are used together, they display a wonderful synergy. For example, as described above, a query is a storable question, the output from which is a table. Forms are based on tables, thus a form can be based on a query. Reports are based on tables, so they too can be based on a query. This is a really important point so it is worth repeating. Both forms and reports can be based upon queries.

So far we have confined ourselves to databases based upon a single table of data. These are great for learning about databases and occasionally the data you meet in the real world will actually fit neatly into just one table. For example, I once built a single-table database for SHARP (Scottish Heart and Arterial disease Risk Prevention).

Suppose we decide, despite advice to the contrary, that we are going to use one and only one table in the database that we are building for our company. In that table we store the details of the orders that we process. These details include item sold, price, customer information, date of sale etc.. If we ran a bonus incentive scheme, we would also need to include the name of the employee who made the sale. We also need to store information about our employees — name, date of birth, date first employed, salary, address, home telephone number etc.. Since we only have one table, then that is the only place where we can put this additional information.

So, let’s have a look at the way in which multiple tables can remove these problems.