Before you can write database applications, you have to know a little about how databases work. Databases have come a long way since their invention, so there’s much you can learn about them. This section provides a quick introduction to basic database concepts, including the two main types of databases: flat and relational.

Simply put, a database is a collection of records. Each record in the database is composed of fields, and each field contains information related to that specific record. For example, suppose you have an address database. In this database, you have one record for each person. Each record contains six fields: the person’s name, street address, city, state, zip code, and phone number. A single record in your database might look like this:

Your entire database will contain many records like this one, with each record containing information about a different person. To find a person’s address or phone number, you search for the name. When you find the name, you also find all the information that’s included in the record with the name.

This type of database system uses the flat database model. For home use or for small businesses, the simple flat database model can be a powerful tool. However, for large databases that must track dozens, or even hundreds, of fields of data, a flat database can lead to repetition and wasted space. Suppose you run a large department store and want to track some information about your employees, including their name, department, manager’s name, and so on. If you have 10 people in Sporting Goods, the name of the Sporting Goods manager is repeated in each of those 10 records. When Sporting Goods hires a new manager, all 10 records have to be updated. It would be much simpler if each employee record could be related to another database of departments and manager names.

A relational database is like several flat databases linked together. Using a relational database, you can not only search for individual records, as you can with a flat database but also relate one set of records to another. This enables you to store data much more efficiently. Each set of records in a relational database is called a table. The links are accomplished through keys, values that define a record. (For example, the employee ID might be the key to an employee table.)

The sample relational database that you use in this unit was created using Microsoft Access. The database is a simple system for tracking employees, managers, and the departments for which they work. Figures 12.1, 12.2, and 12.3 show the tables: The Employees table contains information about each store employee, the Managers table contains information about each store department’s manager, and the Departments table contains information about the departments themselves. (This database is very simple and probably not usable in the real world.)

FIG. 12.1 The Employees table contains data fields for each store employee.

FIG. 12.2 The Managers table contains information about each store department’s manager.

FIG. 12.3 The Departments table contains data about each store department.

Relational databases are accessed by using some sort of database scripting language. The most commonly used database language is the Structured Query Language (SQL), which is used to manage not only databases on desktop computers but also huge databases used by banks, schools, corporations, and other institutions with sophisticated database needs. By using a language such as SQL, you can compare information in the various tables of a relational database and extract results made up of data fields from one or more tables combined.

TIP: Most developers pronounce SQL as Sequel.

Learning SQL, though, is a large task, one that is beyond the scope of this book (let alone this unit). In fact, entire college-level courses are taught on the design, implementation, and manipulation of databases. Because there isn’t space in this unit to cover relational databases in any useful way, you will use the Employee table (refer to Figure 12.1) of the Department Store database in the sample database program you will soon develop. When you finish creating the application, you will have learned one way to update the tables of a relational database without knowing even a word of SQL.

When you create a database program with Visual C++’s AppWizard, you end up with an application that draws extensively on the various ODBC classes that have been incorporated into MFC. The most important of these classes are CDatabase, CRecordset, and CRecordView.

AppWizard automatically generates the code needed to create an object of the CDatabase class. This object represents the connection between your application and the data source that you will be accessing. In most cases, using the CDatabase class in an AppWizard-generated program is transparent to you, the programmer. All the details are handled by the framework.

AppWizard also generates the code needed to create a CRecordset object for the application. The CRecordset object represents the actual data currently selected from the data source, and its member functions manipulate the data from the database.

Finally, the CRecordView object in your database program takes the place of the normal view window you’re accustomed to using in AppWizard-generated applications. A CRecordView window is like a dialog box that’s being used as the application’s display. This dialog box-type of window retains a connection to the application’s CRecordset object, hustling data back and forth between the program, the window’s controls, and the recordset. When you first create a new database application with AppWizard, it’s up to you to add edit controls to the CRecordView window. These edit controls must be bound to the database fields they represent so that the application framework knows where to display the data you want to view.

In the next section, you will see how these various database classes fit together as you build the Employee application step by step.