Steps in query processing in DBMS are:
- Parsing
- Translation
- Optimization
- Execution
Key takeaways:
View resolution in databases retrieves data from a base table through a view, which is a stored query.
A view provides a specific way of looking at data without directly querying the base table.
View resolution adapts column names in the user’s query to match those in the view.
It replaces view references with base table references in the
FROMclause.User
WHEREconditions are combined with those in the view’sWHEREclause.
GROUP BYandHAVINGclauses from both the view and user query are included.
ORDER BYclauses in the user query are adjusted to match the view’s structure.
View resolution in databases refers to the process by which a database system determines how to retrieve the data you ask for when querying through a view. A view is essentially a stored query that presents a specific way of looking at the data in a database.
Imagine you have a box full of toys and want to find a specific toy. Instead of sifting through the entire box, you have a picture on the box cover representing how the toys are organized. This picture is like a “view.” View resolution, then, is like ensuring that the picture accurately helps you identify and retrieve the toy you’re looking for without directly interacting with the contents of the box.
Now, let’s understand the steps involved in view resolution, using a database example for clarity.
The process of view resolution when querying a view can be broken down into several steps:
SELECT clause to match the view’s column names.Here, we ensure that the column names used in the user’s query align with those defined in the view. For instance, if the user’s query specifies different column names than those used in the view, we adapt them accordingly.
Example: If the user tries to query item_id, but the view defines it as id, we map it to the correct name.
Note: Since our view does not contain the
idcolumn in the result, a query asking for it will result in an error.
FROM clause with the base tablesIn this step, any reference to the view in the user’s FROM clause is replaced by the underlying table(s) that the view is based on. This step resolves the view into its base table to continue processing. In our case, the dairy view would be replaced by the items table.
For example,
SELECT * FROM dairy;
The code above will be translated into:
SELECT id, name, price, item_in_stock FROM items WHERE category = 'dairy';
WHERE conditions from both the user’s query and the view’s definitionAny conditions specified in the user’s WHERE clause are combined with the conditions specified in the view’s WHERE clause. For instance, if the user adds a filter like price > 2.00, it will be combined with the category = 'dairy' condition from the view.
For example:
SELECT * FROM dairy WHERE price > 2.00;
The code above will be translated into:
SELECT id, name, price, item_in_stock FROM items WHERE category = 'dairy' AND price > 2.00;
GROUP BY and HAVING clausesIf the view or the user’s query includes GROUP BY or HAVING clauses, which are integrated during view resolution. In this step, both clauses are directly copied from the defining query and the user query.
Example: If the user’s query includes:
SELECT name, COUNT(*) FROM dairy GROUP BY name;
The view resolution would result in:
SELECT name, COUNT(*) FROM items WHERE category = 'dairy' GROUP BY name;
ORDER BY clause based on the view’s structureIf the user’s query specifies an ORDER BY clause, the column names are adapted to match those in the view. The result set is ordered based on either the user’s specification or the view’s predefined order, if present.
For example:
SELECT * FROM dairy ORDER BY price DESC;
This query orders the results based on the price in descending order, even if the original view did not specify an ordering.
To illustrate the steps of view resolution, suppose we have a table defined as follows:
CREATE DATABASE mart;USE mart;CREATE TABLE items (id INT AUTO_INCREMENT PRIMARY KEY,name VARCHAR(255),price DECIMAL(10, 2),item_in_stock INT,category VARCHAR(60));INSERT INTO items (name, category, price, item_in_stock) VALUES('Milk', 'Dairy', 200, 90),('Onion', 'Vegetables', 140, 190),('Bread', 'Bakery', 110, 64),('Butter', 'Dairy', 210, 50),('Cereal', 'Breakfast', 180, 80),('Eggs', 'Dairy', 120, 300),('Apples', 'Fruits', 280, 240);SELECT * FROM items
Line 1: Create a database named mart.
Line 2: Switch to the mart database.
Lines 4–10: Create a table items to store the id, name, price, item_in_stock and category for every item.
Lines 12–19: Insert items in the table.
Line 21: Show the table.
Next, let’s create a view to filter only dairy products:
CREATE VIEW dairy (ItemID, ItemName, ItemPrice, ItemInStock) ASSELECT id, name, price, item_in_stockFROM itemsWHERE category = 'Dairy';SELECT id, name , price, item_in_stock FROM itemsWHERE category = 'Dairy' AND item_in_stock > 50 ORDER BY name;
Lines 1–4: Create a view as dairy and select ItemID, ItemName, ItemPrice, ItemInStock from the items tables where the category is Dairy.
Line 6: Display the Dairy view.
View resolution ensures that a query involving a view is broken down into a set of steps to correctly retrieve data from the underlying base tables. These steps involve adapting column names, resolving the view to its base tables, combining conditions, and handling any additional clauses like GROUP BY and ORDER BY. By following these steps, the database guarantees that the view accurately presents the desired subset of data while remaining consistent with the underlying table definitions.
Haven’t found what you were looking for? Contact Us
Free Resources