Chapter 8 Views and Indexes Mary Norwood & Oberon Ilano

Sections Virtual Views Modifying Views Indexes in SQL Selection Indexes Materialized Views

Views Virtual view/Virtual relation is a type of SQL relations that do not physically exist. Views are not stored in a database. It can be query. It can be materialized.

Declaring Views CREATE VIEW <view-name> AS <view-definition>; The base table/underlying relation for this example is Tesla.

Another Example of Declaring View

Querying Views

Renaming Attributes

8. 2 Modifying Views It is limited to execute an insertion, deletion, or update to a view since the view does not exist the way a base table (stored relation) does. Updatable view is introduced to translate the modification of the view into an equivalent modification on a base table. “INSTEAD OF” trigger is introduced to turn view modification into modification of base tables.

View Removal A modification of a view is to delete it altogether and can be done whether or not the view is updatable. Dropping the view does not affect any tuples of the underlying relation.

Updatable Views The SQL rules are complex, but they permit modifications on views that are defined by selecting (using SELECT but not SELECT DISTINCT) some attributes from one relation R (which may itself can be an updatable view). Important technical points: • The WHERE clause must not involve R in a subquery. • The FROM clause can only consist of one occurrence of R and no other relation. • The list in the SELECT clause must include enough attributes that for every tuple inserted into the view, we can fill the other attributes out with NULL values or the proper default. For example, it is not permitted to project out an attribute that is declared NOT NULL and has no default. Insertion on the view can be applied directly to the underlying relation R.

Updatable Views - INSERT

Updatable Views - DELETE

Updatable Views - UPDATE

INSTEAD OF Triggers on Views INSTEAD OF is used in place of BEFORE or AFTER when a trigger is defined on a view. INSTEAD OF trigger intercepts attempts to modify the view in its place performs any action the database designer trust. Note: Mysql does not support INSTEAD OF

Examples

8.3 Indexes in SQL "Views can also be materialized, in the sense that they are constructed periodically from the database and stored there." "A very important specialized type of  'materialized view' is the index, a stored data structure whose sole purpose is to speed up the access to specified tuples of one of the stored relations." The purpose of using indexes is to make searching for tuples and answering queries much faster and more efficient. Renter

Motivation for Indexes A good real life example of an index is the index in the back of a book. To find all the pages that explain "BCNF" in our Database Systems book, we can look at the index in the back where it says "BCNF" and the set of pages "88-92, 111, 113" Without an index, we would have to search every page for the subject we want to find.

Motivation for Indexes Another real life example from: https://www.essentialsql.com/what-is-a-database-index/ "Consider that you have a deck of 52 cards: four suits, Ace through King. If the deck is shuffled into random order, and I asked you to pick out the 8 of hearts, to do so you would individually flip through each card until you found it. On average you would have to go through half the deck, which is 26 cards. "Now, instead, consider that we separated the cards into four piles by suit, each pile randomly shuffled. Now if I asked you to pick out the 8 of hearts you would first select the hearts pile, which would take on average two to find, and then flip through the 13 cards. On average if would take seven flips to find, thus nine total. This is seventeen flips (26-9) faster than just scanning the whole deck."

Motivation for Indexes “We could think of the index [on attribute A] as a binary search tree of (key, value) pairs, in which a key a (one of the values that attribute A may have) is associated with a “value” that is the set of locations of the tuples that have a in the component for attribute A.” The key of the index is not necessarily the key of the relation. In the index on the subjects of our book, a key "BCNF" is associated with the set of page numbers (locations) of the pages that have "BCNF" in the page.

Declaring Indexes Creating indexes is not part of any SQL standard, but many DBMS have a way to create indexes. Using the typical syntax given in our book, we can declare an index called ManufacturerIndex on the manufacturer attribute of the Product relation like this: CREATE INDEX ManufacturerIndex ON Product(manufacturer);

Declaring Indexes

Declaring Indexes The index created by CREATE INDEX ManufacturerIndex ON Product(manufacturer); Will make an index like this: (A, {location1, location2, location3, location4, location5, location6}) (B, {location1, location2, location3, location4}) (C, {location1}) (D, {location1, location2, location3, location4}) (E, {location1, location2, location3, location4, location5, location6, location7, location8, location9}) (F,  {location1, location2} (G, {location1, location2} (H, {location1})

Declaring Indexes Except we can place each pair in a binary tree like this:

Declaring Indexes It is important to ensure the binary tree is balanced so it is not more or less efficient to search for certain items compared to others. We can make indexes on multiple different attributes, called multiattribute indexes.

8.4 Selection of Indexes The advantage of creating indexes is that it speeds up the process of searching for certain tuples. The disadvantage is that every index makes insertions, deletions, and updates to that relation more time-consuming.

A Simple Cost Model To know which indexes will improve efficiency the most, it is important to understand how the computer stores tuples. Tuples are stored on many pages of a disk. One page holds many tuples. The entire page must be brought into main memory to examine one tuple. But it does not cost much more to examine the entire page instead of examining only one tuple once it has been brought into main memory. So "the principal cost of a query or modification is the number of pages that need to be brought to main memory."

Some Useful Indexes "Often, the most useful index we can put on a relation is an index on its key. There are two reasons:  Queries in which a value for the key is specified are common. Thus, an index on the key will get used frequently.  Since there is at most one tuple with a given key value, the index returns either nothing or one location for a tuple. Thus, at most one page must be retrieved to get that tuple into main memory (although there may be other pages that need to be retrieved to use the index itself)"

Some Useful Indexes "When the index is not on a key, it may or may not be able to improve the time spent retrieving from disk the tuples needed to answer a query. There are two situations in which an index can be effective, even if it is not on a key: If the attribute is almost a key; that is, relatively few tuples have a given value for that attribute. Even if each of the tuples with a given value is on a different page, we shall not have to retrieve many pages from disk. If the tuples are “clustered” on that attribute. We cluster a relation on an attribute by grouping the tuples with a common value for that attribute onto as few pages as possible. Then, even if there are many tuples, we shall not have to retrieve nearly as many pages as there are tuples."

Calculating the Best Indexes to Create We calculate the cost of answering a query with and without an index to determine which is better. And we need to make assumptions about the frequency of certain queries and modifications to the database. The cost of a query or modification can be measured in the number of disk accesses required to perform it.

Calculating the Best Indexes to Create Q1: SELECT movieTitle, movieYear FROM Starsln WHERE starName = s; Q2: SELECT starNameFROM StarslnWHERE movieTitle = t AND movieYear = y; I: INSERT INTO Starsln VALUES(i, y , s) ;

Automatic Selection of Indexes to Create Here is an outline of the process of index-selection: Establish the query workload Specify any constraints Evaluate each set of possible candidate indexes Choose the set of indexes with the lowest cost

8.5 Materialized Views A view is materialized if it’s being used enough. Materialized View can store data. There is a cost involved in maintaining a materialized view because of the changes in the underlying base tables. Note: Mysql does not support Materialized Views

Maintaining a Materialized View It is possible to make the changes to the view incrementally, without recomputing the entire view. The whole view doesn’t need to be reconstructed from scratch. CREATE MATERIALIZED VIEW MVProduct AS -> SELECT model, screen, price, manufacturer -> FROM Product, Laptop -> WHERE Product.model = Laptop.model; INSERT | DELETE | UPDATE | DROP | ALTER Query are similar from regular views. Periodic Maintenance of Materialized View OLAP (On-Line Analytic Processing) is another setting that uses materialized views (Section 10.6).

Rewriting Queries to Use Materialized View Query V Query Q

Automatic Creation of Materialized Views The ideas that were discussed in Section 8.4.4 for indexes can apply as well to materialized views. If the query optimizer can perform such rewritings, then an automatic design tool can consider the improvement in performance that results from creating materialized views and can select views to materialize, automatically. The process can be limited if there is no point in creating a materialized view that does not help for at least one query of our expected workload. We can limit ourselves to candidate materialized views that: 1. Have a list of relations in the FROM clause that is a subset of those in the FROM clause of at least one query of the workload. 2. Have a WHERE clause that is the AND of conditions that each appear in at least one query. 3. Have a list of attributes in the SELECT clause that is sufficient to be used in at least one query.

Sources “Views and Indexes” Database Systems: the Complete Book, by Hector Garcia-Molina pp. 341–367. https://dev.mysql.com/doc/refman/8.0/en/trigger-syntax.html https://www.guru99.com/triggers-pl-sql.html https://www.essentialsql.com/what-is-a-database-index