1. Physical Changes That Don’t Change the Logical Design
CGS2540C Database Management
This video discusses physical changes in the DB design that don’t change the logical design. Most importantly this means there is no introduction of data redundancy.

2. Physical Database Design Techniques
Adding External Features
Adding Indexes
Adding Views
Reorganizing Stored Data
Clustering Files
Splitting a Table into Multiple Tables
Horizontal Partitioning
Vertical Partitioning
Splitting-Off Large Text Attributes
Adding indexes and views are usually the first strategies used when creating the physical database design. First, they do not change the logical design which is a big benefit. Second they generally will have a large positive impact on the operational database. Clustering files and partitioning are less frequently used. These require the relational DB software have the capability to implement these strategies. Many small relational database software applications targeted for creating department databases do not. For example, MS Access can’t cluster or partition data. We will look at each of these options in more detail.

3. Adding Indexes
Which attributes or combinations of attributes should you consider indexing in order to have the greatest positive impact on the application environment?
Attributes that are likely to be prominent in direct searches
Primary keys
Search attributes
Attributes that are likely to be major players in operations, such as joins, SQL SELECT ORDER BY clauses and SQL SELECT GROUP BY clauses.
Most people have used the index of a book.  We recognize that it provides a quick way to scan for a topic, find a location (page number), and then proceed directly to that page to find the topic.  We would need to scan the entire book, page by page, front to back for a topic if there was no index.  Likewise, a database table must be scanned row by row when an index doesn't exist.  

4. Adding Indexes
It is appropriate to create an index under the following conditions.
A column contains a wide range of values.
A column contains a large number of NULL values.
One or more columns are frequently used together in a WHERE clause or a join condition.
The table is large and most queries will return less than 2-4%  of the rows.

5. Adding Indexes
What potential problems can be caused by building too many indexes?
Indexes are wonderful for direct searches. But when the data in a table is updated, the system must take the time to update the table’s indexes, too.
As mentioned in the textbook, there are diminishing returns as you add indexes for a table.  Each index incurs overhead as the underlying data is added, deleted, and changed. Not only must the data be changed but each index must also be updated. The book index looses some of its value if every word in the book is in the index.  Likewise, a database index looses some of its value (efficiency) if every or column or many columns are indexed.

6. Adding Views Doesn’t change the logical design.
No data is physically duplicated.
An important device in protecting the security and privacy of data.
A view is a logical or virtual table.  It is based on one or more other views or physical tables in the database.  The view doesn't contain data in the same way a true table does.  Rather it represents another way to look at existing data.  You can think of a view as a stored query. Views are an excellent tool to tailor the presentation of data to fit the needs of the end user and/or the organization.  A view can also be used to limit access to sensitive data.  Consider a simple employees table that contains salary information.  You could create a view that extracts all the columns for each employee except those related to salary. A view can be used just as a table is used.  The end user need never know they are accessing a view and not a table. A view allows a database administrator (or anyone who has the proper rights) to "pre-select" data based on a complicated set of requirements and make that data available as a table.  The end user accesses only the end result and can see the data by using simple SELECT statements.

7. Reorganizing Stored Data
Doesn’t change the logical design.
No data is physically duplicated.
Clustering Files
Houses related records together on a disk.
Another strategy to improve database performance is to change the way the data is physically stored. This doesn’t change the logical design and no data is physically duplicated. The most common way to reorganize the data is to use clustering. Clustered files store related rows together on the disk.

8. Reorganizing Stored Data: Clustering Files
Here is an example of clustering. The salesperson record for salesperson 137, Baker, (click) is followed on the disk by the customer records for customers 0121, 0933, 1047, and (click) This arrangement would be quite beneficial anytime you needed to retrieve Salesperson data with his or her associated customers. Unfortunately, the Customer table is now fragmented and it is less efficient to retrieve all the rows in this table.

9. Splitting a Table Into Multiple Tables
Horizontal Partitioning
Vertical Partitioning
Splitting-Off Large Text Attributes
Another design strategy is to split a table into multiple tables. This can be accomplished by horizontal partitioning, vertical partitioning, or splitting-off large text attributes.

10. Horizontal Partitioning
The Customer Employee table is horizontally partitioned in this example. The business rules have indicated it is common to retrieve information on customer employees who are sales managers. The rows of a table are divided into groups, and the groups are stored separately on different areas of a disk or on different disks. In this case, the rows are those for any employee who is a sales manager. This strategy is useful in managing the different groups of records separately for speed of access, security or backup and recovery purposes. A disadvantage of this strategy is that retrieval of records from more than one partition can be more complex and slower. For example, if you needed to retrieve all the employees for customer 1525, some of these would be in one partition and some would be in the other. Keep in mind in horizontal partitioning each partition has every column found in the table but only some of the rows. In this example, both partitions have the Customer Number, Employee Number, Employee Name, and Title columns.

11. Vertical Partitioning
The Salesperson table is vertically partitioned in this example. The separate groups, each made up of different columns of a table, are created because different users or applications require different columns. In this example, the business rules have indicated it is common to retrieve the commission percentage (click) for a Salesperson. This column is therefore extracted and put in it is own table. In vertical partitioning it is necessary to add the primary key field or fields to the new partition (click) . In vertical partitioning, each partition has all the rows but only some of the columns of the complete table. The drawback to this approach is that retrieving a complete row is now less efficient.

12. Splitting Off Large Text Attributes
A variation on vertical partitioning involves splitting off large text attributes into separate partitions.
Each partition must have a copy of the primary key.
A table may contain large text attributes like descriptions or comments. These may be rarely accessed and therefore it becomes more efficient to store these in a separate table. This is also true of certain objects like images, audio, or video that can be stored in a database.

13. This ends the video!
“Copyright 2004 John Wiley & Sons, Inc. All rights reserved. Reproduction or translation of this work beyond that permitted in Section 117 of the 1976 United States Copyright Act without express permission of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages caused by the use of these programs or from the use of the information contained herein.”