Chapter 4: Database Design

Transcription

1 Chapter 4: Chapter 4: Objectives Understand data integrity concepts. Learn how to normalize data. Work with SQL Server s tools for enforcing data integrity. Implement primary and foreign keys. Use Declarative Referential Integrity. Work with Database Diagrams. Microsoft SQL Server 7.0 Professional Training Series 4-1

2 Chapter 4: What Is Data Normalization? You already know that data is stored in tables, and that tables contain columns where individual data items are stored, but how do you figure out which piece of data belongs in which table, and how do you decide how many tables to create? Normalization is the technical term for a process of structuring a database for efficiency by applying some common-sense rules to organize it. Think of your database as a pile of clothes waiting to be put away in your dresser. You would never pick out articles of clothing at random and shove them into the closest drawer (at least not if your mother was watching!). There should be a place for everything, and everything should be in its place. If you keep your socks in multiple random places, you d never find a matching pair to wear to work in the morning. And if you mixed your socks with your swimfins in the same drawer, you might look pretty funny if you weren t paying attention when you got dressed. Normalization is the process of taking a tangled mass of data and untangling it, to make tables with logical places for each strand of the tangle. The notion of data integrity works hand in hand with normalization: integrity rules help you identify units of data in order to protect the data, normalization rules help you decide where to store these units. When you design a database, you should not pack every piece of data you run across into the nearest table. Just because your table for customers includes first name and last name fields does not mean you should put employees into the same table. Employees and customers are two different sorts of things ( entities in database theory terms) that belong in two different places. NOTE The whole concept of relational database theory was developed by Dr. E. F. Codd at IBM back in the 1960 s and is based on set theory and predicate logic. You don t have to immerse yourself in the scientific and technical underpinnings of Dr. Codd s work in order to understand and implement a sound database design, but you do need to understand the basic concepts, which apply to all relational databases not just SQL Server 7.0. A good reference for beginners is for Mere Mortals by Michael J. Hernandez, Addison-Wesley, ISBN Microsoft SQL Server 7.0 Professional Training Series

3 What Is Data Normalization? Key Terms Normalization Normal Forms The process of verifying that the data in a database is stored in an efficient format. A series of rules that are applied to a database in the process of normalization. Integrity Concepts Integrity rules are designed to keep your data consistent, correct, and compliant with your business rules. You ve undoubtedly heard the computer maxim Garbage in, garbage out. The main reason to use databases rather than spreadsheets or word processors to store data is that databases are designed to use integrity rules to help prevent garbage from getting into the database in the first place. The four types of data integrity you ll learn about are: Entity integrity Domain integrity Referential integrity User-defined integrity Entity Integrity The basic idea of entity integrity is that you must be able to identify each entity that you store in a database. An entity is any real-world thing (either an object, subject, or an event) that you choose to represent in the database. For example, suppose you were developing a patient-tracking system. Entities in this system might include: Patients Insurers Prescriptions Physicians Drugs Appointments There is one basic requirement that your data must fulfill to ensure entity integrity: every row must be unique. No two rows can contain the same data. Each entity needs to have a primary key, which consists of a unique characteristic or set of characteristics that distinguish it from other entities of the same type. Primary keys consist of a column (or columns) that contains Microsoft SQL Server 7.0 Professional Training Series 4-3

4 Chapter 4: unique values, so that no row of data is ever exactly the same as another row of data. NOTE If you can locate a single column that serves to identify records in a table, you ve found a simple primary key. If it takes a combination of columns to do this, the table is said to have a composite primary key. As you re developing a database schema (a set of tables with interrelationships) to represent your real-world problem, you ll create a table to store each entity and a field (or group of fields) to store the primary key for each entity. However, before you start creating tables, you need to list the tables and columns so that you have a template to build your database structure. Table 1 lists the possible tables, columns, and primary keys in the Shark database. Table Fields (* Indicates possible Primary Key) tblcategories tblcustomer tblemployee tblorder tblorderdetail tblproducts CategoryID*, Category* CustomerID*, LastName*, FirstName*, Address, City, State, ZipCode, Phone, Extension, EmployeeID*, LastName*, FirstName*, Address, City, State, ZipCode, HomePhone, url_ address OrderID*, OrderDate*, CustomerID*, EmployeeID*, PaymentMethod, CardNumber, ExpirationDate OrderID*, ItemID*, ProductID, SalePrice, Quantity ProductID*, Product*, CategoryID, Description, Price, Units, ShipWeight, Taxable, Discontinued tblunits Units* Table 1. List of tables, columns and possible primary keys. Identifying key fields is the first step in enforcing entity integrity. Think about the Order table, for example. If you know that customers never place more than one order on the same day, then the combination of OrderDate and CustomerID is enough to uniquely identify the order. However, if there s a possibility that they may place more than one order per day, that won t work. In the Shark database there is an OrderID number, which uniquely identifies the order. The CustomerID is still in the table, which allows you to look up any customer information (such as Address) that you may need. Once you ve identified the key fields for your tables, you can use a variety of SQL Server features to enforce entity integrity. You can create a unique index on the field, use PRIMARY KEY or UNIQUE KEY constraints, or the IDENTITY property, to enforce entity integrity, which you ll learn about later in the chapter. 4-4 Microsoft SQL Server 7.0 Professional Training Series

5 What Is Data Normalization? Domain Integrity Just as entity integrity keeps watch over the values entered in primary key columns in a table, ensuring the uniqueness of each row, domain integrity enforces restrictions on the values you can enter in any column, enforcing business rules particular to your application. For any given piece of data say, the customer name or the order date there is some domain of values that is valid for entry in that field. At the simplest level, the data type assigned to the column enforces domain integrity. For example, you won t be able to enter text in a domain that is defined as a date. The more you do to keep bad data from being entered, the less you need to worry about handling bad data later. TIP: SQL Server (like most other database products) can store a special value called Null, which is a placeholder for unknown data. Null is not equal to anything else, not even another Null it just means unknown. As you re considering the domain integrity rules for your database, you need to consider whether a field should allow Nulls, or whether to require a value when a new record is created. SQL Server allows you to specify whether a column allows Nulls. If you define a column to not allow Nulls, the record can t be saved until the column is given a value. If you were to list out the domains in the customers, orders, and order details tables, you might come up with a list similar to that shown in Table 2. Table Field Domain Nulls OK? Customer LastName, FirstName Names of people Address Mailing addresses No address Yes Order Customer Must be in Customers table No Employee Must be in Employees table No Order Date Between 1/1/80 and 12/31/2099 No Payment Method Name of payment method No OrderDetail Order Must be in Orders table No Product Must be in Products table Yes Price Between 0-10, No Quantity Between 1-1,000,000 Yes Table 2. List of Tables, Columns, and Domains. No Some of these rules, like the maximum date for orders and the maximum price for products may need to be modified as the business changes. SQL Server Microsoft SQL Server 7.0 Professional Training Series 4-5

6 Chapter 4: provides a variety of tools for enforcing and modifying domain integrity, which we ll look at in this chapter. These include: Datatypes User-defined datatypes DEFAULT constraints CHECK constraints Rules FOREIGN KEY constraints Referential Integrity If you look back at Table 2, you ll see that there are some fields whose acceptable values are defined in terms of fields in other tables. For example, you don t want to have orders for non-existent customers, so it wouldn t make sense for the Orders table to contain the name of a customer who isn t in the Customers table. Enforcing relationships such as this and ensuring that there are no orphan records, like orders without customers, is the job of referential integrity. If you preserve referential integrity between the Orders and Customers tables in this example, you must constrain, or limit, a number of possible database actions: You can t add an order for a non-existent customer. You can t change the customer name for an existing order to a name that isn t already in your table of customers. You can t delete a customer who has outstanding orders. You can t change the name of a customer who has orders. These rules are not as arbitrary as they might seem at first glance. The basic idea is that no matter what actions you perform in the database, you always have to be able to match each order to a corresponding customer. Referential integrity states that there are immutable relationships between tables in your database that need to be enforced. TIP: In the real world, of course, customers do sometimes change their names. You could allow for this in your database by using a different unique characteristic, say customer ID number, as the primary key of the Customer table and the linking field, or foreign key, of the Orders table. Such a key, which provides uniqueness but no real-world information, is called a surrogate key. 4-6 Microsoft SQL Server 7.0 Professional Training Series

7 What Is Data Normalization? The relations between tables in a database can be represented as shown in Figure 1. Here the lines between the tables show the relationships that referential integrity will preserve, and the key symbols show the primary key fields. Figure 1. The Database Schema for Shark. You can modify referential integrity by creating cascading updates and cascading deletes. Cascading increases the range of allowable database actions while still preserving the relationships between different tables. If you implement cascading updates, you can change the primary key of a table on the parent side of a relationship, and the foreign keys on the child side to automatically update to match. If you implement cascading deletes, you can delete a record from a parent table, and any matching child rows will be automatically deleted as well. Microsoft SQL Server 7.0 Professional Training Series 4-7

8 Chapter 4: NOTE Cascading updates and cascading deletes are not created automatically in SQL Server when you create relationships. You need to create triggers to cascade the data. Generally speaking, implementing cascading updates causes little harm, but you need to carefully consider whether implementing cascading deletes makes sense in a given relationship. For example, if you have implemented cascading deletes between the Customers table and the Orders table, accidental deletion of a Customer will trigger deleting all of the related orders rows as well. In this case cascading deletes is a bad idea without it, users would be prevented from deleting a customer if there were related records in the orders table. When deciding whether or not you need to implement cascading deletes in a given situation, ask yourself whether or not you want all the historical data on the child side to be permanently deleted. If the answer is no, then don t implement cascading deletes. SQL Server provides the following tools for maintaining referential integrity: FOREIGN KEY constraints CHECK constraints Triggers and stored procedures TIP: Although FOREIGN KEY constraints have largely replaced triggers and stored procedures for implementing referential integrity, the latter are still necessary if you need cascading updates or cascading deletes. User-Defined Integrity (aka Business Rules) Entity integrity, domain integrity, and referential integrity are all formal database concepts. User-defined integrity encompasses all other business rules that don t fit neatly into one of these concepts. For example, in a medical database you might know that the Cautions field of the Prescriptions table should include Do not operate heavy machinery any time it also includes Do not drive while using this prescription. Such a rule can t be expressed through integrity rules. Business rules are commonly implemented using triggers, rules, or stored procedures on the server or through logic implemented in a client application that retrieves data from the database. Normalizing Data As you design databases with entity, domain, and referential integrity, you ll begin to recognize patterns in the way that you organize the data. For example, 4-8 Microsoft SQL Server 7.0 Professional Training Series

9 What Is Data Normalization? the search for primary keys will encourage you to separate dissimilar data into different tables. These rules have been codified as the normal forms, a progression of structural ideas that have been shown to lead to well-behaved databases. Advanced books on the subject (such as C.J. Date s classic An Introduction to Database Systems) identify half a dozen or more normal forms, but the higher forms are mainly of academic interest. For most straightforward business databases you ll only need to be concerned with the first three normal forms, which we ll cover here. Each normal form includes the previous ones, so that a database in Third Normal Form is automatically in First Normal Form and Second Normal Form as well. As you re gaining experience in database design, you may want to explicitly apply the rules of each normal form in turn to your tables, moving through the process of normalizing the data. As you grow more experienced, you ll find that you tend to automatically put your data in Third Normal Form, and may just need to review the final database schema to make sure you haven t introduced any inconsistencies along the way. TIP: As you re learning the normal forms, it s important to concentrate on the concepts, rather than knowing precisely which normal form enforces which rules. Before you even begin to normalize your tables, there is one rule that you must comply with: Every table must have a primary key. First Normal Form A table is in First Normal Form when each and every field is atomic. The rule for First Normal Form is simple: each field in a table must contain only a single type of data, and each piece of data must only be stored in one place. A common violation of this would be to store a first name and a last name in a single Name column. Problems arise with this when you want to sort data on the last name or use only the first name. It s much easier to store the first and last names in separate columns and join them together when needed. Another violation of First Normal Form is repeating columns. For example, suppose you created an Invoice table with fields such as Quantity1, Part1, Amount1, Quantity2, Part2, Amount2, Quantity3, Part3, and Amount3. A structure such as this runs into problems because it is not flexible enough, it wastes space, and it is an inefficient structure for quickly retrieving data once it s entered. And what happens if you want to enter a fourth Part? You need to add columns to the table. If you only need one Part, you re wasting space with all the empty Part2 and Part3 columns. The solution is to create a separate Microsoft SQL Server 7.0 Professional Training Series 4-9

10 Chapter 4: InvoiceDetails table and use referential integrity to relate it back to the main Invoice table. Second Normal Form A table is in Second Normal Form when it only contains information on a single type of entity. To achieve Second Normal Form, you must make sure that your tables contain data about one and only one kind of thing. You can check this by making sure that all non-key fields are dependent on the entire primary key, and not on other fields in the table. When a table has a composite primary key, violations of Second Normal Form can be hard to spot. For example, in the Orders table, you might be tempted to include the CustomerName field. But this would be a violation of Second Normal Form, since the customer name is not dependent on the entire primary key of the table. Storing the customer name in the Orders table would waste space, since you d have to repeat it with every order, instead of storing it once in the Customers table where it belongs. And what if you wanted to change a customer s name? You d have to change it on all of that customer s orders. Third Normal Form A table is in Third Normal Form when any field can be updated without affecting any other field. The rule for Third Normal Form is that all non-key fields must be mutually independent. That is, you should be able to change the value of any field without needing to recalculate or fix up any other field. The most obvious violations of Third Normal Form are calculated fields. If you design an Invoice table that includes Quantity, Price, and TotalPrice fields (with TotalPrice being simply Quantity multiplied by Price), you ve violated Third Normal Form. You can derive the total price any time you need it by knowing the Quantity and Price values. Storing the total can cause inconsistencies in your data if either the Price or the Quantity changes. Third Normal Form also helps you see that some tables need to be split into lookup tables. If you store customer data in the Orders table, you d quickly find that changing a customer s address is a nightmare, requiring you to search through the entire table and change the address for every order belonging to that customer. You d be much better off splitting the customer information into a separate customer table, so that changing a customer s address affects only a single row of data. There are many instances where the needs of a particular business must be taken into account when normalizing a database. For example, your business may need to store a customer s current shipping address in the orders table, so 4-10 Microsoft SQL Server 7.0 Professional Training Series

11 What Is Data Normalization? that even if that customer moves, you can go back and see where you shipped a particular order in the past. Normalization Summary The following summarizes the normalization rules you need to use when designing your databases: Each table must have a primary key. All fields must contain atomic data. There must be no repeating fields. Each table must contain information about a single type of entity. Each field in a table must depend on the entire primary key. All non-key fields must be mutually independent. Denormalizing Data Denormalization is the process of deliberately reintroducing redundancy to your data. In theory, you should never denormalize data, but in the real world things are often not that simple. The following are some scenarios where you might want to consider denormalizing your data: Sometimes it may be necessary to denormalize data in the interest of performance. An over-normalized database can be slow on a network due to the number of joins that have to be performed to retrieve data from multiple tables. If your normalized data model produces tables with multi-part primary keys, particularly if those keys have four or more columns in them and are used in joins with other tables, you should consider denormalizing the data by introducing arbitrary surrogate keys. You can easily create surrogate keys using Identity columns, combined with UNIQUE constraints (discussed in the next sections). You can then add arbitrary foreign keys to tables that join back to the main table, and enforce the join on the surrogate keys. This will often provide a substantial performance benefit over multi-part primary keys. Some experts would argue that this wouldn t be denormalizing at all, since use of surrogate keys has become a standard accepted practice. If producing calculated values such as maximum historic prices involves queries that must process many records or records from many related tables, you should consider denormalizing the data by adding calculated columns to your tables to hold these values. You can use triggers to ensure that these calculated columns are updated whenever one of the columns that they depend on is updated. Microsoft SQL Server 7.0 Professional Training Series 4-11

12 Chapter 4: If your database contains extremely large tables, you should consider denormalizing the data by creating multiple redundant tables instead. You partition the data either by column or by row. For example, if the employees table contains many columns, and some of these (such as hire date) are very infrequently used, it may help to move the less frequently used columns to their own table. By reducing the volume of data in the main table you can make it faster to access this data. If the employees table is worldwide and most queries are only interested in employees from one region, you can speed up the queries by creating separate tables for each region. If you split a table into multiple tables by row, you can still query all the data by using the Transact-SQL UNION operator. If data is no longer live and is being used for archiving or is otherwise read-only, denormalizing by storing calculated values in fields can make certain queries run faster. For example, year-to-date figures can be stored once that year s entries are completed. If queries on a single table frequently use only one column from a second table, consider including a copy of that single field in the first table. For example, you might choose to include a SalespersonName field in an Orders table, even though the table already includes the SalespersonID, because you always include the Salesperson s name with the order. In this case, of course, you ll need to write code to ensure that the SalespersonName field is updated every time the SalespersonID is changed. WARNING! Remember, you should never denormalize your data without a specific business reason for the denormalization! Careless denormalization can ruin the integrity of your data, and lead to slower performance. Whenever you are forced to denormalize data for any reason, make sure you document your decision, so that some other developer doesn t think you simply made a mistake Microsoft SQL Server 7.0 Professional Training Series

13 Tools for Enforcing Data Integrity Tools for Enforcing Data Integrity Understanding the principles of data normalization is one thing, but how do you enforce these rules using SQL Server? SQL Server provides a wide variety of tools for enforcing data integrity. In this section, you ll learn about identity columns, constraints, rules, and declarative referential integrity (DRI). You can also use triggers and stored procedures for some complex operations, such as maintaining user-defined integrity or implementing referential integrity with cascades. Identity Columns One way to enforce entity integrity is by using an identity column, which automatically supplies a unique value. The value defaults to starting at 1 and incrementing by 1 from there, but you can specify a different start value (the seed ) and increment. To create a table including an identity column using SQL Server Enterprise Manager, right-click Tables and choose New Table. Choose a name for your new table, and then fill in a field name, make the Datatype int, and check the Identity column. Figure 2 shows tblcustomer in the Shark database where the CustomerID is an Identity column with a seed value of 1 and an increment of 1. Figure 2. The CustomerID column in tblcustomer is set up as an Identity column. There are some limitations on which columns can be identity columns: The data type must be tinyint, smallint, int, decimal, or numeric. The column must not allow null values. There can only be one identity column per table. Microsoft SQL Server 7.0 Professional Training Series 4-13

14 Chapter 4: There cannot be a default value. If you create an additional column in the table to hold a text value, you can enter data in the new table and see how the identity column works. To enter data in the table, right-click on it and select Open Table Return all rows. As you enter text, the identity column is automatically filled in, as shown in Figure 3. Figure 3. Entering data in a table with an identity column. WARNING! You might expect a SQL Server Identity column to automatically enforce entity integrity, but this is not the case. You can insert duplicated values into an Identity column. You need to apply a UNIQUE constraint to the column to prevent duplicate values. Constraints SQL Server uses constraints to enforce limitations on the data that can be entered into a particular column in a table. You can use UNIQUE, DEFAULT, and CHECK constraints to enforce entity, domain, and user-defined integrity (business rules). In addition, SQL Server uses PRIMARY KEY and FOREIGN KEY constraints to implement referential integrity, which you ll learn about later. Unique Constraints Unique constraints are used to guarantee that every row is unique by specifying that each value in a given column must be unique (have a different value in every row in the table). To add a UNIQUE constraint to a table, click the Table and Index Properties button on the toolbar and select the Indexes/Keys tab. Click the New button to add the constraint and select the column name in the Column Name grid Microsoft SQL Server 7.0 Professional Training Series

15 Tools for Enforcing Data Integrity Select the Create Unique checkbox. SQL Server will generate a name for the new constraint, as shown in Figure 4. Figure 4. Creating a unique constraint. NOTE Whenever SQL Server creates a unique constraint, it automatically creates an index on the field as well. By default, this is a nonclustered index, but you can specify CLUSTERED explicitly if you d like to control this. Default Constraints A Default constraint gives you a way to supply a default value for a column in any table. That is, the constraint provides the value that will be stored with new rows in the data when the value for the column is not otherwise specified. Default constraints can help enforce domain integrity by providing reasonable values for new records. They also help with some user-defined integrity Microsoft SQL Server 7.0 Professional Training Series 4-15

16 Chapter 4: problems: for example, all new customers might start with an account balance of zero. To see how this works, open tblproducts, and specify a Default Value of 0 for the Price column, as shown in Figure 5. Figure 5. Creating a default constraint. TIP: You can specify a default constraint for any column except timestamp columns or identity columns. Note that you must supply the constraint in this dialog box using legal Transact-SQL syntax. If you have a character value, it must be enclosed in single quotes. The value supplied for a default constraint (in this example, 0) can be a constant, a function, NULL, or a niladic-function. Niladic-functions are functions supplied by SQL Server that do not take arguments. Some examples of niladic functions are CURRENT_TIMESTAMP, CURRENT_USER, SESSION_USER, SYSTEM_USER, and USER. Check Constraints A CHECK constraint allows you to control the data entered into a particular column by evaluating an expression. The expression must return a Boolean (True/False) value. If the return value is False, the constraint has been violated and the command that caused the violation will be terminated. Check constraints are useful for setting limits on acceptable data to enforce domain integrity, as well as for enforcing more complex user-defined integrity rules. To add a CHECK constraint, click the Properties button in the Table Designer, select the Tables tab and click New. Type the following constraint expression, which will enforce a pattern on invoice numbers, so that they must start with two letters, followed by four numbers: 4-16 Microsoft SQL Server 7.0 Professional Training Series

17 Tools for Enforcing Data Integrity (InvoiceNum LIKE '[A-Z][A-Z][0-9][0-9][0-9][0-9]') It should look like the dialog shown in Figure 6. Figure 6. Creating a CHECK constraint. The following CHECK constraint would allow values equal to or less than 30 in the NetDays column: NetDays <= 30 The following would allow only values of M or F in the Gender column: Gender IN ('M', 'F') The following would allow only values between zero and 120 in the Age column: ((Age > 0) AND (Age < 120)) Microsoft SQL Server 7.0 Professional Training Series 4-17

18 Chapter 4: TIP: If you re creating a CHECK constraint to enforce integrity rules, you should select the option to check the existing data in your table to make sure nothing has slipped by. Rules Rules provide another means of enforcing domain and user-defined integrity rules within your database. The easiest way to think of a rule is as a reusable constraint. A rule is a separate SQL Server object that can be bound to one or more columns in one or more tables. To add a rule using SQL Server Enterprise Manager, right-click Rules in the database in which you want to create the rule and choose New Rule. This will open the dialog box shown in Figure 7. To define the rule, enter an expression that returns a Boolean value, and a name for the rule. Just as with CHECK constraints, if this expression evaluates to False, the operation that triggered the evaluation is canceled. This expression can use one local variable to refer to the value being entered into the column, as shown in Figure 7. You can use any name to refer to this constant, but it must start with sign, as shown with variable. Figure 7. Creating a Rule Microsoft SQL Server 7.0 Professional Training Series

19 Tools for Enforcing Data Integrity Once you save the rule, you can then go back into its Properties and use the buttons at the bottom of the dialog box to bind this rule to as many columns in as many different tables as you like. Binding a rule to a column is the operation that tells SQL Server to use that rule when values are entered or changed in that column. Figure 8 shows the Bind Rule to Columns dialog box. Select the table you want to add the rule to, then click the Add button. You can also remove existing rules. Click the Apply button when finished. Figure 8. Binding PercentRule to the CommissionPercent column in tblemployee. TIP: There is a limitation of one rule per column a single column can only have one rule bound to it. If you need multiple constraints on one column, use CHECK constraints instead of rules. Microsoft SQL Server 7.0 Professional Training Series 4-19

20 Chapter 4: Using Declarative Referential Integrity (DRI) Declarative Referential Integrity (usually just called DRI) is a process that allows you to notify SQL Server of the referential integrity between tables and to have the server automatically enforce these relationships. Prior to the implementation of DRI, keeping referential integrity enforced required writing trigger code for every table to perform appropriate actions. As with other integrity support, DRI is implemented using constraints on tables. There are two types of constraints used: PRIMARY KEY and FOREIGN KEY. Choosing a Primary Key In most relational databases, the primary key of a table performs two duties. First, since it is guaranteed to be unique on every record, it enforces entity integrity. Second, it serves as an anchor for referential integrity relationships from other tables. Given a table without a primary key, you have a choice as to which fields to choose for the primary key. Every column or combination of columns that is unique is called a candidate key. For example, in an employees table, the employee number might be one candidate key, but so might the Social Security Number. So how do you decide which candidate key to actually use for your primary key? Two useful criteria are minimality and stability: A minimal key is a key with the fewest columns. Thus, if you have a choice of a simple key or a composite key to be your primary key, take the simple key. This rule flows from the fact that, generally speaking, manipulating a single column is faster than manipulating multiple columns. Like other rules of thumb, there are exceptions to this. For example, a combination of two integer columns would be faster to work with than a single large varchar column. Stability is a characteristic of the data in your table. Because the primary key will be used in relationships, it s important that the data in the primary key column change as little as possible ideally, it should never change. This avoids the necessity to implement cascading updates, and once again makes your database a bit faster. Thus, candidate keys such as employee number are usually preferable to candidate keys such as employee name. Finally, remember the advice from the section on denormalization. If your table s natural primary key includes many fields, you re usually better off creating a surrogate key and making that the primary key of the table Microsoft SQL Server 7.0 Professional Training Series

21 Tools for Enforcing Data Integrity Creating a primary key is easy: while the table is open in design mode, select the column or columns that you want to designate as the primary key, and click the gold key icon on the toolbar, as shown in Figure 9. Figure 9. Setting a primary key. The toolbar button is a toggle, so if you want to delete the primary key, simply click it again and the primary key will be deleted. Foreign Keys Foreign keys, in conjunction with primary keys, provide the other half of SQL Server s implementation of referential integrity. A foreign key is a copy of the primary key from the parent table that is inserted in the child table in order to create a relationship between the two. In an Orders table, CustomerID would be a foreign key. Just like primary keys, foreign keys are implemented with CONSTRAINT clauses. Unlike primary keys, a single table can have multiple foreign keys. The easiest way to create a foreign key is by using the Database Diagrammer, discussed in the next section. Using Database Diagrams to Enforce DRI A database diagram displays the columns contained within selected tables, the relationships between the tables, and indexes and constraints attached to the tables. You can use it to: View the tables and their relationships in a database. Alter the physical structure of your database. Manipulate database objects without writing Transact-SQL code. Create new tables, indexes, relationships, and other constraints. Microsoft SQL Server 7.0 Professional Training Series 4-21

22 Chapter 4: Experiment with database changes, using the diagram as a modeling tool, without modifying the underlying database. Save the changes to selected tables or to the database diagram and have the changes modify the database. Every database diagram consists of one or more tables. You can have multiple diagrams in one database, which is handy if you have many tables or a complex data model. Each diagram functions as a graphical view of the tables it contains. You can insert a new table into a diagram, or add an existing table. To create a new diagram, right-click on the Diagrams icon in the database and select New Database Diagram. This will load the Create Database Diagram wizard. After an introductory screen, the wizard will ask you to select the tables to be used in the diagram. This example utilizes just the Customers, Orders and Order Detail tables, as shown in Figure 10. Figure 10. Adding tables to a diagram with the Database Diagram wizard. You will then get a confirmation dialog showing the tables that will be added. Click the Finish button, and a diagram will be created with your tables, as shown in Figure Microsoft SQL Server 7.0 Professional Training Series

23 Tools for Enforcing Data Integrity Figure 11. A new database diagram. There are no menus in the Diagrammer; you need to use the toolbar buttons to get around. They are (reading from left to right): Save Properties Print Save change script Cut Copy Paste New table Add table Zoom Microsoft SQL Server 7.0 Professional Training Series 4-23

24 Chapter 4: Show Set primary key New text annotation Arrange tables Additional options are available by selecting an object and right-clicking on it. If you select a table and right-click, you will get the list of available actions for a table, as shown in Figure 12. Figure 12. Right-clicking on a table gives you additional menu options. Creating Relationships To create a relationship, select the primary key from one table and drop it on the table you want the relationship with. If you drop it on the column name that will be the foreign key, then the name will be automatically filled in on the Create Relationship dialog, as shown in Figure 13. Click OK to save the relationship Microsoft SQL Server 7.0 Professional Training Series

25 Tools for Enforcing Data Integrity Figure 13. Creating a relationship. Repeat the process for all of the relationships you want to create. When you are finished, your tables will be connected with join lines. When you drag the mouse over one of the join lines, you will see tooltip text telling you the name of the relationship and the fields involved, as shown in Figure 14. Figure 14. Viewing relationship information. Microsoft SQL Server 7.0 Professional Training Series 4-25

26 Chapter 4: Editing Relationships To edit the relationship, right-click on the join line between the tables and select Properties. (You can also get there by selecting either table involved in the relationship and selecting Properties.) You can then edit the relationship, as shown in Figure 15. Figure 15. Editing a relationship. You can also use the Properties dialog box to create constraints by clicking on the Tables tab, and to create indexes by clicking on the Indexes/Keys tab. TIP: When you ve finished creating your relationships, make sure to set an index on the foreign key. SQL Server doesn t do this for you automatically when the foreign key relationship is created Microsoft SQL Server 7.0 Professional Training Series

27 Tools for Enforcing Data Integrity Deleting Relationships To delete a relationship, simply right-click the join line between the two tables, and select Delete Relationship From Database. Finishing Up When you re done making changes to the diagram you are working on, you can elect to save your changes, cancel your changes or save a change script. You can also save changes to individual tables without saving changes to the database diagram as a whole. If you right-click on a table, you can choose the Save Selection option. If you right-click on an empty area of the diagram, you can choose the Save option, which would apply to all tables and to the diagram itself. To create a script of the changes you ve made, right-click on an empty area of the diagram, and choose Save Change Script from the menu. This will load the Save Change Script dialog, which will show you the script that will be generated. You can also elect to generate a script every time you save, as shown in Figure 16. Figure 16. A change script from a diagram. The first script you create will be saved as \MSSQL7\BIN\DbDgm1.sql. You can open it using any text editor. Microsoft SQL Server 7.0 Professional Training Series 4-27

28 Chapter 4: WARNING! Once you ve made changes to the Database Diagram, there is no way to undo them. If you don t want changes you ve made in a diagram saved back to the database, then close the diagram without saving. Using Triggers to Cascade Updates and Deletes Triggers are just what they sound like an action is invoked (or triggered) whenever data in a table is modified. You can create triggers to make something happen automatically when data in a table changes. If you want to cascade updates or deletes to related tables, you need to create triggers to do the work. Unfortunately, DRI isn t automatic in SQL 7. A trigger is a special type of stored procedure that is invoked in response to INSERT, UPDATE, or DELETE statements. The trigger and the statement that fires it are treated as a single transaction that can be rolled back from within the trigger. The transaction automatically rolls back if an error is detected. Two special tables are maintained during trigger operations. These tables are named inserted and deleted, and you can examine the data in them from within the trigger if you need more information on the data changes that are taking place. During a delete, rows are removed from the main table and transferred to the delete table. Then the delete trigger fires. During an insert, rows are added to both the main table and the inserted table. Then the insert trigger fires. During an update, the old data is added to the deleted table, and the new data is added to the main table and the inserted table. Then the update trigger fires. To create a trigger, open the table in Design view. Click the Triggers button on the toolbar to bring up the Trigger Properties dialog box and select <new> from the drop-down list, as shown in Figure 17. Alternatively, right-click anywhere in the table and choose Task Manage Triggers. Type in the Transact-SQL statement for the trigger. When you ve finished typing, click the Check Syntax button. If you ve made any errors, you ll be told. When the syntax checker is happy, click the Apply button. The trigger will now be active Microsoft SQL Server 7.0 Professional Training Series

29 Tools for Enforcing Data Integrity Figure 17. Creating a new trigger. The CREATE TRIGGER statement creates a trigger on the tblorder table so that when an order is deleted, all related records in the tblorderdetail table will also be deleted. CREATE TRIGGER DelOrderDetails ON tblorder FOR DELETE AS DELETE tblorderdetail FROM tblorderdetail, deleted WHERE tblorderdetail.orderid = deleted.orderid WARNING! If you create a relationship between tblorder and tblorderdetail, then the trigger will never get fired since the foreign key constraint will be evaluated before the trigger fires, disallowing the deletion. In this case, you would create a stored procedure to delete the tblorderdetail records first, then the related tblorder records. The following trigger will cascade updates between tblcustomer and tblorder if for some reason the CustomerID field changes: Microsoft SQL Server 7.0 Professional Training Series 4-29

30 Chapter 4: CREATE TRIGGER CascadeCustomers ON tblcustomer FOR UPDATE AS IF UPDATE(CustomerID) BEGIN UPDATE tblorder SET tblorder.customerid = inserted.customerid FROM tblorder, deleted, inserted WHERE deleted.customerid = tblorder.customerid END Using Stored Procedures to Implement Arguably the best way to implement database design and business rules is to use stored procedures. This gives you complete control over how the data is updated. However, the downside to this is that you have to write a lot more Transact-SQL code than by using DRI or triggers Microsoft SQL Server 7.0 Professional Training Series

31 Tools for Enforcing Data Integrity Summary Data normalization is the process of verifying that the data in a database is stored in an efficient format. Integrity rules are designed to keep your data consistent, correct, and compliant with your business rules. Each normal form includes the previous normal form, so that a database in Third Normal Form is automatically in First Normal Form and Second Normal Form. Every table must have a primary key. All fields must contain atomic data. There must be no repeating fields. Each table must contain information about a single type of entity. Each field in a table must depend on the entire primary key. All non-key fields must be mutually independent. Identity columns help enforce entity integrity. Constraints enforce limitations on the data that can be entered into a particular column. Rules can be thought of as reusable constraints and can be used in many tables. There is a limit of one Rule per column. You can use Database Diagrams to edit and create new tables, indexes, relationships, and constraints. Microsoft SQL Server 7.0 Professional Training Series 4-31

32 Chapter 4: Questions 1. What must every table have before you can start the process of normalizing your data? 2. Name 3 normalization principles. 3. How can you enforce limitations on the data that can be entered into a particular column in a table? 4. Which Enterprise Manager tool can you use to enforce Declarative Referential Integrity? 4-32 Microsoft SQL Server 7.0 Professional Training Series

33 Tools for Enforcing Data Integrity Answers 1. What must every table have before you can start the process of normalizing your data? A Primary Key 2. Name 3 normalization principles. All fields must contain atomic data. There must be no repeating fields. Each table must contain information about a single entity. Each field in a table must depend on the entire primary key. All non-key fields must be mutually independent. 3. How can you enforce limitations on the data that can be entered into a particular column in a table? By creating contstraints or by creating and binding a rule. 4. Which Enterprise Manager tool can you use to enforce Declarative Referential Integrity? Database Diagrams. Microsoft SQL Server 7.0 Professional Training Series 4-33

34 Lab 4: Lab 4: Microsoft SQL Server 7.0 Professional Training Series 4-34

35 Lab 4 Overview Lab 4 Overview In this lab you ll learn how to create primary and foreign keys for the tables in the Shark database and work with Database Diagrams to create relationships between tables. To complete this lab, you ll need to work through three exercises: Create Primary Keys Work with Database Diagrams Create a CHECK Constraint Each exercise includes an Objectives section that describes the purpose of the exercise. You are encouraged to try to complete the exercise from the information given in the Objectives section. If you require more information to complete the exercise, the Objectives section is followed by detailed step-bystep instructions. Microsoft SQL Server 7.0 Professional Training Series 4-35

36 Lab 4: Create Primary Keys Objective In this exercise, you ll examine the tables in the Shark database and create primary keys for them. Things to Consider What makes a good primary key? How to you set a primary key in a table? Step-by-Step Instructions 1. Run the script file to create the Shark database. 2. Expand the tables and right-click the first one, tblcategories. Select Design Table from the menu. 3. Select CategoryID and click the gold key button on the toolbar to set the primary key, as shown in Figure 18. Figure 18. Setting the primary key for tblcategories. 4. Click the Save button and close the table. 5. Repeat with the other tables in the database. The primary keys for each table are listed in Table Microsoft SQL Server 7.0 Professional Training Series

37 Create Primary Keys Table Name Primary Key tblcategories CategoryID tblcustomer CustomerID tblemployee EmployeeID tblorder OrderID tblorderdetail OrderID, ItemID tblproducts ProductID tblunits Units Table 3. Table and Primary Key list for Shark. Microsoft SQL Server 7.0 Professional Training Series 4-37

38 Lab 4: Work with Database Diagrams Objective In this exercise, you ll create a new Database Diagram and use it to build the relationships between the tables in the Shark database. Things to Consider How do you create a Database Diagram? How do you create relationships between tables? What happens when you save the Database Diagram? Step-by-Step Instructions 1. Expand the Shark database and right-click on Diagrams. Select New Database Diagram. This will load the New Database Diagram wizard s introductory dialog. Click the Next button. 2. Select the tables shown in Figure Microsoft SQL Server 7.0 Professional Training Series

39 Work with Database Diagrams Figure 19. Add all of the tables to the Database Diagram 3. Click the Next button, and then the Finish button. This will create a new diagram. Click in any empty space to de-select all of the tables (the diagram opens with them all selected; if you try to move one, you move them all). 4. You can re-arrange the tables so that they aren t so spread out. You can also use the Zoom button to make them larger, as shown in Figure 20. Microsoft SQL Server 7.0 Professional Training Series 4-39

40 Lab 4: Figure 20. Zooming in on the Database Diagram and rearranging the tables. 5. To start creating relationships, think about how the tables are going to be related. One customer can have many orders, so select the CustomerID in the tblcustomer table, hold down the left mouse button, and drag CustomerID over to CustomerID in tblorder and release the mouse. This will bring up the Create Relationship dialog, as shown in Figure 21. Click OK to create the relationship Microsoft SQL Server 7.0 Professional Training Series