Figure 11.32: The solid line indicates the relationship between the Agents and Assignments tables.
Creating a View
The data has been normalized, which provides some important advantages, but the user really doesn’t care. The user doesn’t want to have to look up which assignment is assignment number 2, for example. Data management systems have a special entity called the View which enables you to generate a “virtual table” that recognizes the relationship you’ve just created. You can create a view in the server explorer just like you created a table and a data view. When you right−click on the Views item and choose Create New View, you get the opportunity to include any data tables. If you choose both tables you see a screen similar to Figure 11.33.
350
Figure 11.33: The view editor features a form of the data diagram. The relationship has been preserved.
The view editor has four main sections. The top section is a version of the data diagram. The next section is a Query By Example (QBE) tool. The third band displays an SQL statement, and the bottom layer shows the results of the current query.
Hint You might wonder why the view editor has all these query tools. It’s because a view and a query are essentially the same thing. It’s called a query when it’s created on the fly in an application or by a user. A view is usually stored with the database. Often a data developer creates a number of views to reconnect any tables that have been separated by the normalization process, and any other queries that are likely to be extremely common.
The best way to understand the view editor is to look at an example. Figure 11.34 illustrates my completed Agent_Assignment View.
351
Figure 11.34: As you can see from the bottom of the screen, this view recombines the Agents and Assignments tables.
A view or query can be used to recombine tables. I created this view by using a tool called Query By Example (QBE). I drug all the fields I was interested in displaying from the data diagram at the top of the screen to the grid in the middle of the screen. When I did so, the center grid automatically filled with the values you see. The grid describes which fields I want to use in the query. For each field, I can assign an alias. The alias describes the name of the field in the resulting virtual table. If you do not provide an alias, the original field name is retained. You can choose whether each field is displayed. The Sort Type and Sort Order values are used to determine how the resulting data is sorted. The Criterion value enables you to set a WHERE clause for the view.
To see the results of the view, click on the exclamation point icon at the upper−left of the view editor, or choose Run from the Query menu.
Hint The view editor is a great way to learn SQL syntax. It’s pretty easy to experiment by dragging fields to the grid and examining the resulting SQL statement. Don’t forget to periodically run the query so you can be sure that the data view you see in the bottom grid is related to the currently displayed SQL statement.
Take a careful look at the SQL statement in Figure 11.34. It can be reformatted as follows for clarity:
SELECT Agents.CodeName,
Assignment.Name,
Assignment.Description,
Assignment.Location
FROM Agents INNER JOIN Assignments
ON Agents.AssignmentID = Assignments.AssignmentID
The only part of the SELECT statement that is really new is the FROM clause. The relationship between the Agents and Assignments tables is automatically represented by an INNER JOIN statement. The INNER JOIN tells the computer to display fields from the Assignment table only when the AssignmentID fields in the two tables match.
352
You can create SQL queries with inner joins inside your code as well as in views. The advantage of a view is the way it appears as a virtual table to the program
Referring to a View in a Program
Once you have created a view in the database, it’s very simple to add that view to your programs. Simply drag the view to your form to build a data connection and data adapter for the view, then create a data set from the adapter and connect your data grid to the data set as usual.
Figure 11.35 shows a database that features a view.
Figure 11.35: Once you’ve created a view, you can attach a grid to the view as if it were a table. Views give you the best of both worlds. You can design your data to improve its integrity, but the user will see the data without any cryptic foreign key values.
Incorporating the Agent Specialty Attribute
The Agent Specialty field creates another problem for the data developer. The rules of normalization indicate you should never have a list of data in a field. Each agent could have a number of specialties. If you enable the user to enter all the specialties into a single text box, you have the same ambiguity problems you prevented with the Assignments table. Also, it is hard to predict how much room to allocate for skills if the skills will be a list.
Hint The relationship between agents and specialties is called a many−to−many relationship, because each spy could have many specialties, and each specialty could belong to many different agents.
Searching for a spy with particular skills is a challenge if the skills are simply a list of text values in a field. The solution is to use two tables to manage the relationship between the Agent and his or her specialties. First, take a look at the Specialties table featured in Figure 11.36.
353
Figure 11.36: The Specialties table simply lists all the various specialties.
The Specialties table consists of a primary key and specialty name fields. However, because each agent can conceivably have many specialties, you cannot use the same type of join that connected agents with assignments. Instead, I added another table, displayed in Figure 11.37.
Figure 11.37: The Agent_Specialty table serves as a bridge between the Agents table and the Specialties Table.
The Agent_Specialty table is very interesting because the user will never see it. Instead, this table has joins to both the Agents table and the Specialties table. The Agent_Specialty.AgentID field is a foreign key reference to the Agents table, and the Agent_Specialty.SpecialtyID field is a foreign key reference to the Specialties table. The complete data diagram of the spy database including all four of its tables and their relationships is shown in Figure 11.38.
354