Catálogo de publicaciones - libros

You may wonder about the use of the word ‘object’ in this and subsequent chapters. You may have noticed heard about object-oriented programming and you might wonder if there is any connection. In fact, we are using the word ‘object’ here simply to mean ‘thing” or ‘entity’. The only reason we don’t use the word ‘thing’ is that it looks thoroughly unprofessional to do so in a book about a serious subject like databases. There is, however, no hidden complex meaning in ‘object’ as the word is used here and if you want to mentally substitute the word ‘thing’, that’s fine by me.

How do you ensure that you split up your data into an acceptable set of tables? For example, I might decide to store all of the information about employees in one table; but is that always the right decision? Is it always a good idea to have a separate table for the items that we sell? Again, if we sell mostly furniture and then start selling ice-cream, should the information relating to ice-cream sales go in the same table as that for furniture sales or a different one? How are you supposed to make these decisions?

It is worth remembering that each table represents a type of object in the real world. If this were a real (rather than a demonstration) database, each record in the CUSTOMERS table would refer to a real customer and each entry in the EMPLOYEES table would represent a real employee. The first step in deciding what relationships we need to set up between the tables is to ask the question “What types of relationships can exist between these real world objects?”

OK, so we’ve got our objects — employees, customers, orders etc. — nicely represented as tables in the database. We now understand the relationships that can exist between these objects. The next step is to see how we can model the relationships in the database.

In this part we have been looking at why single tables are bad, why multiple tables are good and latterly at how you actually arrange the data into separate tables. Now seems like a good time to look at the gains you get from splitting up data in this way.

How accurate should the data in a database be? 100% would be good, of course, but what is realistically acceptable in a database of reasonable size? 90%? 95%? The answer is that we need to go much higher than 95% for one very simple reason.

This is an exceedingly short chapter which simply summarizes what Part 2 is all about and points the way to the next part.

The idea of splitting it like this arose very early in the development of databases. These three layers were first described in an interim paper published by the ANSI/SPARC Study Group on Data Base Management Systems in 1975.

OK, that covers how we design a database. The next point to consider is how and where you deploy it. In other words we haven’t talked about where the components that make up the database — the database engine, the data and the database application etc. — are going to be placed. There’s a huge range of possibilities. We don’t move the parts around for fun (although the process is intellectually challenging and therefore enjoyable), we do it because each database architecture has a distinctly different set of pros and cons. You may well be called upon to make decisions about which architecture is appropriate for a given database implementation so it is worth understanding the advantages and disadvantages associated with each one. In order to understand these differences, we need to look at the parts into which a database can be dissected, then, in the next chapter, we’ll examine where those parts can be located.

In Access, of course, we often develop an entire database on a PC and use it there. This is an excellent solution for allowing single user access to a set of data. If this is what you need then you certainly shouldn’t consider making life any more complex for yourself by starting to move components around; leave it on the PC.