Beginning SQL
Beginning SQL Beginning SQL
The index is no longer needed, so delete it with the following code. If using MS SQL Server, write the following DROP INDEX statement: DROP INDEX MemberDetails.member_name_indx; In IBM DB2 and Oracle, the DROP INDEX statement simply requires the index name without the table name prefixed: DROP INDEX member_name_indx; In MySQL, the code to drop the index is as follows: ALTER TABLE MemberDetails DROP INDEX member_name_indx; MS Access has yet another way of dropping the index: DROP INDEX member_name_indx ON MemberDetails; You’ve learned a lot of useful stuff for improving the design and efficiency of your databases. The next section takes that knowledge and applies it to the Film Club database. Improving the Design of the Film Club Database This section revisits the Film Club database, taking into account the topics discussed in this chapter: normalization, ensuring data integrity with constraints, and using indexes to speed up data retrieval. The discussion begins with an examination of the database structure and then turns to constraints and indexes. Reexamining the Film Club Database Structure Generally speaking, the database is in third normal form, with the exception of the MemberDetails table. The Street, City, and State columns are all transitively dependent on the ZipCode column. Therefore, the MemberDetails table is still in second normal form. The question now, however, is one of common sense, because the amount of duplication reduced by going to third normal form is going to be quite small. It’s unlikely that many people from the same street would join the club, and with a small database, storage size is not usually an issue. In addition, changing the table to comply with third normal form involves creating another table, and as a result any SELECT queries require another JOIN statement, which impinges on database efficiency. Therefore, in this instance, the database is fine as it is, and moving the MemberDetails table to third normal form is probably unnecessary and only adds complexity without really saving any storage space. However, one area of the database design needs altering: the Attendance table. Consider the following query: SELECT * FROM Attendance; Advanced Database Design 143
- Page 276: Chapter 4 normalization can make da
- Page 280: Chapter 4 120 Field Name Data Type
- Page 284: Chapter 4 122 The Street, City, and
- Page 288: Chapter 4 MySQL versions prior to 5
- Page 292: Chapter 4 126 Except for IBM’s DB
- Page 296: Chapter 4 128 You can add more than
- Page 300: Chapter 4 Try It Out Adding a CHECK
- Page 304: Chapter 4 Obviously, if the table i
- Page 308: Chapter 4 134 Drop the MoreHolidayB
- Page 312: Chapter 4 136 If you want to return
- Page 316: Chapter 4 If you’re using IBM DB2
- Page 320: Chapter 4 140 index helps speed up
- Page 324: Chapter 4 142 The results you get m
- Page 330: WHERE MemberAttended = ‘Y’; DRO
- Page 334: Primary keys must be unique and can
- Page 338: Then add the PRIMARY KEY constraint
- Page 342: ( ); FilmId integer NOT NULL, FilmN
- Page 346: ALTER TABLE Attendance ADD CONSTRAI
- Page 350: ❑ You learned the importance of e
- Page 356: Chapter 5 158 Function Operator Mul
- Page 360: Chapter 5 Consider the following SQ
- Page 364: Chapter 5 The SQRT() Function The S
- Page 368: Chapter 5 164 chairperson now also
- Page 372: Chapter 5 The FLOOR() Function The
The index is no longer needed, so delete it with the following code. If using MS <strong>SQL</strong> Server, write the<br />
following DROP INDEX statement:<br />
DROP INDEX MemberDetails.member_name_indx;<br />
In IBM DB2 and Oracle, the DROP INDEX statement simply requires the index name without the table<br />
name prefixed:<br />
DROP INDEX member_name_indx;<br />
In My<strong>SQL</strong>, the code to drop the index is as follows:<br />
ALTER TABLE MemberDetails<br />
DROP INDEX member_name_indx;<br />
MS Access has yet another way of dropping the index:<br />
DROP INDEX member_name_indx ON MemberDetails;<br />
You’ve learned a lot of useful stuff for improving the design and efficiency of your databases. The next<br />
section takes that knowledge and applies it to the Film Club database.<br />
Improving the Design of the Film Club Database<br />
This section revisits the Film Club database, taking into account the topics discussed in this chapter: normalization,<br />
ensuring data integrity with constraints, and using indexes to speed up data retrieval.<br />
The discussion begins with an examination of the database structure and then turns to constraints and<br />
indexes.<br />
Reexamining the Film Club Database Structure<br />
Generally speaking, the database is in third normal form, with the exception of the MemberDetails table.<br />
The Street, City, and State columns are all transitively dependent on the ZipCode column. Therefore, the<br />
MemberDetails table is still in second normal form. The question now, however, is one of common sense,<br />
because the amount of duplication reduced by going to third normal form is going to be quite small. It’s<br />
unlikely that many people from the same street would join the club, and with a small database, storage<br />
size is not usually an issue. In addition, changing the table to comply with third normal form involves<br />
creating another table, and as a result any SELECT queries require another JOIN statement, which<br />
impinges on database efficiency. Therefore, in this instance, the database is fine as it is, and moving the<br />
MemberDetails table to third normal form is probably unnecessary and only adds complexity without<br />
really saving any storage space.<br />
However, one area of the database design needs altering: the Attendance table. Consider the following<br />
query:<br />
SELECT * FROM Attendance;<br />
Advanced Database Design<br />
143