Catálogo de publicaciones - libros

So far we have skated around the definition of a relational database. It is really tempting to believe that the use of multiple tables marks the transition to a relational database. Indeed, I have read several times that a ‘relational’ database is so called because it allows you to “relate” information held in different tables. How can I put this politely? This information is wrong. Anyone who tells you this is incorrect. If they try to sell you anything, say nothing and back carefully away.

This chapter covers triggers and stored procedures which are important when you write complex multi-user databases. The Jet engine in Access provides no direct support for triggers although you can provide much the same functionality using VB and, say, the “Before Insert” property of a form. There is no direct support for Stored Procedures either although again, you can emulate pretty much the same functionality using VB. Of course, Access can also connect to other databases engines which do provide direct support for these features.

Tables hold data and that data is constantly being accessed, altered and updated by various operations. It is relatively common in certain applications for two or more of these operations to be logically related.

Relational databases are, by now, so widely accepted that many people are unaware that any other form of database can exist. It is also sad (but true) that many people don’t know what particular facets of a DBMS make it relational or not. Since the relational model is the brainchild of Dr. Edgar Codd (‘the Father of the Relational Database’), the best place to start is with Ted Codd’s rules.

The tables shown in this chapter are not included on the web site since there is very little that you can do with them. Indeed, some of the tables are demonstrations of how not to construct a table.

The only tables from this chapter that you might find useful are the READINGS tables. They are included in case you want to play around with the SQL statements.

You design tables, you give the tables columns, you name the columns, you create joins between tables, you build queries etc. Have you ever stopped to wonder where that information is stored? Where does the database store the information about which tables have which columns, which tables are joined and so on?

Data manipulation is a vital part of the relational model. After all, there is little point in storing data correctly, safely and securely if that is all you ever do with it. Stored data has no value if you cannot question it and extract it in some way for humans to examine. So if you want to know more about databases, you will probably want to know about querying more than any other part.

SQL stands for Structured Query Language, which is pronounced either as S Q L (as the three letters) or as Sequel. It appears that the former pronunciation is more common in the UK and the latter in the US but as the two are interchangeable it shouldn’t be a cause of anxiety.

The concept of a domain is a crucial part of the relational model, which is strange because it is ignored by almost every RDBMS I can call to mind.