1. Application Development with Views
Chapter 10
Application Development with Views
Welcome to Chapter 10 on application development with views
Views are fundamental to application development:
- Purpose of writing queries is to specify data for applications (forms, reports, batch
processing)
- View: a stored query with intelligent processing
- Data requirements are important part of applications: user interface design and
workflow important also but not covered in this course
Objectives:
- Understand motivation for using views
- Write CREATE VIEW statements and stored queries (Access)
- Apply rules to write updatable views especially multi table updatable views
- Analyze data requirements of hierarchical forms and reports
- Skills important for application development work and course assignments

2. Outline Background Creating views and using views
Processing queries that reference views
Updatable views
Data requirements for hierarchical forms
Data requirements for reports
Background:
- What is a view?
- Why use views?
Creating and using views:
- CREATE VIEW statement and stored queries in Access
- Using views in queries
Processing views: brief presentation of materialization and modification
Updatable views:
- What is it?
- Single table
- Multiple table: Access rules
Hierarchical forms:
- What are they?
- Specification of data requirements for hierarchical forms
- Conceptual background for Access lab chapter 5
Hierarchical reports
- Specification of data requirements for hierarchical reports

3. What is a View? Derived table
Behaves like a base table (virtual) with some restrictions for view usage in modification statements
Stored query
What is a view?
- Derived table
- Not just a subset of base tables: specify with a query
- Query can be complex and even contain row summaries, not individual rows
View behavior:
- Use a view like a base table
- Use a view in a query
- Use a view in modification statements
- Some restrictions especially on usage in modification statements
Virtual
- Seems to be real but is not
- Virtual memory: provide perception of much larger main memory
- Performance may suffer: must buffer in anticipation of memory needs (delay otherwise)
- Performance of views must be close to base tables: otherwise not used

4. View Advantages Reduce impact of database definition changes
Simplify database usage
Unit of database security
Can be a performance penalty on complex views
Reduce impact of changes
- Software maintenance is a major expense
- Large fraction of software maintenance involves database definition changes
- Applications access db through views not base tables
- Only direct changes to the view itself result in program maintenance, not changes
to base tables
- View acts like a buffer between db and applications
- Known as data independence
- Reduces but does not eliminate impact of changes
- Change the data type of column in a view: application must be changed
- Add a column to a table and column not needed in the view: no appl change
Simplification:
- Views can be derived using complex queries
- Easier to use the view than to write the underlying complex query
- View provides a buffer between the user and the underlying db complexity
- Single table (view) vs multiple tables (db): no need for joins, grouping by users
Security:
- Views provide a unit of security
- Fine level of control over access privileges: data specified by a query
- View can be complex and even contain row summaries, not individual rows
Performance penalty:
- Should not be significant on most views: explain under view processing
- Can be significant for complex views: views with complex queries
- Experiment with DBMS on complex views

5. Three Schema Architecture
- Schema: database description
- explanation in chapter 1
- Reference architecture for compartmentalizing database descriptions
Schema levels:
- Conceptual level: base tables
- External level: views
- Internal level: implementation details for base tables (indexes, disk extents, clustering)
- Chapter 8 for physical database design
Mappings:
- Performed by the DBMS: relieve user of much work
- External to Conceptual: submit query using a view; DBMS translates to base tables
- Conceptual to Internal: SELECT statement implemented with loops, join order, index
usage, …
Reduce impact of changes:
- Use views rather than base tables in applications
- DBMS translates queries on a view to query on lower level schema

6. View Definition Example
Example 1: Create a view consisting of offerings taught by faculty
in the MS department.
CREATE VIEW MS_View AS
SELECT OfferNo, Course.CourseNo, CrsUnits,
OffTerm, OffYear, Offering.FacSSN,
FacFirstName, FacLastName, OffTime,
OffDays
FROM Faculty, Course, Offering
WHERE FacDept = 'MS'
AND Faculty.FacSSN = Offering.FacSSN
AND Offering.CourseNo = Course.CourseNo
CREATE VIEW statement:
- Specify the name of the view
- SELECT statement: derivation of view
Example 1:
- MS_View contains data from 3 tables
- Column names of view are identical to the names in the SELECT clause
View definition in Access:
- CREATE VIEW statement not supported
- Write the query and save it as MS_View
- Can use CREATE VIEW statement with Access data projects
- Use SQL Server as the data manager
- Use Microsoft Data Engine

7. Column Renaming
Example 2: create a view containing offering data and the number of
enrolled students.
CREATE VIEW Enrollment_View
( OfferNo, CourseNo, Term, Year, Instructor,
NumStudents ) AS
SELECT Offering.OfferNo, CourseNo, OffTerm,
OffYear, FacLastName, COUNT(*)
FROM Offering, Faculty, Enrollment
WHERE Offering.FacSSN = Faculty.FacSSN
AND Offering.OfferNo = Enrollment.OfferNo
GROUP BY Offering.OfferNo, CourseNo, OffTerm,
OffYear, FacFirstName, FacLastName
Must rename columns:
- derived columns
- multiple columns with the same unqualified names (CourseNo from Offering
and Course)
Example 2:
- Row summaries
- Derived column: NumStudents
- Must provide a name for all columns when one column is renamed
- Positional notation for column names
Access:
- Use AS in the SELECT clause for derived columns
- COUNT(*) AS NumStudents

8. Using Views Example 3 SELECT OfferNo, CourseNo, FacFirstName,
FacLastName, OffTime, OffDays
FROM MS_View
WHERE OffTerm = 'SPRING' AND OffYear = 2003
Example 4
SELECT OfferNo, Instructor, NumStudents,
CrsUnits
FROM Enrollment_View, Course
WHERE Enrollment_View.CourseNo =
Course.CourseNo
AND NumStudents < 5
Using views: reference view name just like base tables
Example 3:
- Simpler than base table query: 1 table versus 3 tables
Example 4:
- Simpler than base table query: neither join nor grouping
- Complex query on a view:
- View definition has GROUP BY
- Joining a base table with GROUP BY view
- Condition on aggregate column
- Some DBMSs will not execute Example 4 (Access and Oracle do perform)
- Check performance of view query against base table query

9. Processing View Queries
Materialization
Execute two queries
Large overhead
Preferred in static environments such as data warehouses (Chapter 16)
Modification
Substitute view definition for view references
Execute one query
Incurs little overhead
Not possible for all view queries
Two view processing strategies
- Details are not important
- Understand characteristics especially performance implications
Materialization:
- Execute the view definition (SELECT statement defining the view)
- Execute the query on the view
- Preferred in static environments: data warehouses (queries dominate)
Modification:
- Replace view references with view definition
- Substitution process occurs in main memory (fast)
- Execute modified query containing only base table references
- Not possible on some queries involving complex views
- Check DBMS performance on queries like Example 4
- DBMS may be using materialization rather than modification

10. View Modification
The diagram shows that a query using a view is modified or rewritten as a query using base tables only; then the modified query is executed using the base tables. The modification process happens automatically without any user knowledge or action. In most DBMSs, the modified query cannot be seen even if you want to review it.

11. View Materialization
View materialization is usually not the preferred strategy because it requires the DBMS to execute two queries. However, on certain queries such as Examples 10.6 and 10.7, materialization may be necessary. In addition, materialization is preferred in data warehouses in which retrievals dominate. In a data warehouse environment, views are periodically refreshed from base tables rather than materialized on demand. Chapter 16 discusses materialized views used in data warehouses.

12. Modification Examples
Example 5: Query using a view
SELECT OfferNo, CourseNo, FacLastName
FROM MS_View
WHERE OffYear = 2006
Example 6: Modified query
SELECT OfferNo, Course.CourseNo, FacLastName
FROM Faculty, Course, Offering
WHERE FacDept = 'MS' AND OffYear = 2006
AND Faculty.FacSSN = Offering.FacSSN
AND Offering.CourseNo = Course.CourseNo
Query using a view:
- Retrieve data about 2006 courses
Modification process:
- FROM: substitute tables in the view's definition
- WHERE: add conditions from the view's definition
Additional simplification possible:
- Course table is not needed
- Offering must be related to one course
- CourseNo column can be taken from the Offering table
- Some (most) DBMSs will not perform this additional simplification
- Simplified base table query will run faster than unsimplified modified query

13. Single Table Updatable Views
Support modification statements
Rules for single table updatable views
1-1 correspondence between view rows and base table rows
View includes PK of base table
View includes all required columns
View definition does not have GROUP BY or DISTINCT
Updatable view:
- Supports INSERT, UPDATE, and DELETE statements as well as SELECT statements
- DBMS translates modification of view rows to corresponding modification on base
table(s)
- Corresponding base table modifications must be unambiguous
- Read-only view: only supports SELECT statement
Rules:
- 1-1 correspondence: include PK
- For INSERT operations: include all required columns without default values
- GROUP BY and DISTINCT destroy updatability: DBMS assumes no 1-1 correspondence

14. Updatable View Examples
Example 7: Single table updatable view
CREATE VIEW Fac_View1 AS
SELECT FacSSN, FacFirstName, FacLastName,
FacRank, FacSalary, FacDept,
FacCity, FacState, FacZipCode
FROM Faculty
WHERE FacDept = 'MS'
Example 8: View update
UPDATE Fac_View1
SET FacSalary = FacSalary * 1.1
WHERE FacRank = 'ASST'
Example 7:
- View includes the PK and required columns of Faculty table
- View includes a subset of Faculty rows
Example 8:
- Change the salary of assistant professors
- Update performed on base table, not on the view
- When view is used again, the changes are visible

15. View Update with Side Effects
Modify column used in the WHERE condition of a view definition
Use WITH CHECK OPTION clause to prevent
Example 9: Change the department of rows in the Fac_View1
UPDATE Fac_View1
SET FacDept = 'FIN'
WHERE FacSalary >
Side effect:
- Something unexpected occurs
- Can confuse users
- Updating a view row causes the row to disappear from the view
- Updated row violates the view definition
Example 9:
- Fac_View1 has 'MS' in a condition in its definition
- Update is precise: Faculty rows are updated
- Rows disappear in the view when it is redisplayed
WITH CHECK OPTION:
- Prevents view updates that modify a column used in the WHERE condition
- Place at end of CREATE VIEW statement

16. Multiple Table Updatable Views
No industry standard
Only recently supported
More complex rules than single table updatable views
Access supports flexible view updates for multi-table views
Oracle rules in Appendix 10.B
Multiple table updatable views:
- Especially useful for data entry forms
- Views are the data source for data entry forms
- Support only recently (last 5 years)
Chapter 10 uses the Access rules for multiple table updatable views
Access allows great flexibility with multiple table updatable views
Oracle rules are less flexible: Oracle relies on triggers (Chapter 11) for view updates
Too complex to present both sets of rules in the chapter body

17. 1-M Updatable Queries Associated with 1-M relationships
Join column of the parent table: primary key or unique
Determine updatable tables
Child table updatable
Primary key
Foreign key: must include in the query result
Required columns of the child table
Include primary key and required columns to support insert operations on the parent table
Use join operator style
General:
- Access term
- Precise rules in the Access help documentation
Rules:
- Single table rules apply: no GROUP BY or DISTINCT
- Typically designed to modify rows of the child table
- Can support INSERT operations on the parent table
- To support INSERT operations on the parent table, include its PK and required columns
- UPDATE operations supported on the parent table even if PK of parent table is omitted
Key point:
- FK of the child table: repeat several times
- SELECT statement must include the FK of the child table
- May also include the PK of the parent table to support INSERT operations on the parent table

18. 1-M Updatable Query Example
Example 10: Save as Course_Offering_View1
SELECT Course.CourseNo, CrsDesc, CrsUnits,
Offering.OfferNo, OffTerm, OffYear,
Offering.CourseNo, OffLocation,
OffTime, FacSSN, OffDays
FROM Course INNER JOIN Offering
ON Course.CourseNo = Offering.CourseNo
Tables:
- Course (parent)
- Offering (child)
Analysis:
- PK and required columns of the child (Offering) table
- Join operator style: cross product style not supported for updatability
- Join column of parent (Course) table is CourseNo (PK)
- Includes the PK and required columns of the parent table
Supports update and insert operations to both tables (1 and M)

19. Usage of a 1-M Updatable Query
Example 11: Insert a row into the Course_Offering_View1.
INSERT INTO Course_Offering_View1
( OfferNo, Offering.CourseNo, OffTerm,
OffYear, OffLocation, OffTime,
FacSSN, OffDays )
VALUES
( 7799, 'IS480', 'Spring', 2003, 'BLM201',
'1:30PM', ' ', 'MW' )
Example 11:
- Inserts a row into the Offering table
- No row inserted into the Course table: IS480 must exist
Insert a row into both tables (Course and Offering)
- Include values for both the Course and Offering tables
- PK of Course should be unique (not an existing course)
More details:
- 1-M Updatable Query Animation
- Lab Chapter 5: Appendix 5.C (Steps to test a 1-M Updatable Query)

20. Extensions to Multiple Tables
Apply rules to each 1-M relationship
FK of each child table in the query result
Usually only the lowest level child table is updatable
Examples
Course-Offering, Faculty-Offering
Offering-Enrollment, Faculty-Offering
Example 1:
- Course (parent) – Offering (child): Offering.CourseNo (FK)
- Faculty (parent) – Offering (child): Offering.FacSSN (FK)
- Offering.OfferNo: PK of Offer
Example 2:
- Offering (parent) – Enrollment (child): Enrollment.OfferNo (FK)
- Enrollment.StdSSN, Enrollment.OfferNo: PK of Enrollment
- Only Enrollment is updatable

21. Hierarchical Forms Formatted window for data entry and display
Main form
Subform
Provide attractive interface for a 1-M relationship
Specification of data requirements is important
Main form:
- One record at a time shown
- Also known as the master form
Subform:
- Multiple records displayed
- Also known as the detail form
Textbook chapter 10: conceptual details about defining the data requirements
Lab chapter 5: specific Access details; need conceptual understanding from
textbook chapter 10

22. Revised University Database
Registration:
- New table
- Row for each term in which a student registers
- RegNo: PK
- RegDate
- RegTerm
- RegYear
- StdSSN: FK to Student table
Relationships:
- 1-M from Student to Registration
- 1-M from Registration to Enrollment

23. Example Hierarchical Form
Registration form (Figure 10-4)
Main form:
- Registration and student data
- Registration is a new table in the revised university database
Subform:
- Enrollment data: OfferNo
- Offering data: CourseNo, term, year, location, time
- Faculty data: faculty name
- Course data: number of units
Form keys:
- PK of the form: what field(s) are unique for each instance of the form
- Main form: Registration No
- Subform: OfferNo (unique within main form)

24. Analysis of Data Requirements
Identify the 1-M relationship
Identify the linking fields
Determine other tables in the main form and the subform
Determine updatable tables
Write queries for the main form and subform
Data requirements for hierarchical forms
- Perform each step
- Final step: write queries; ultimate goal
- Access oriented but also apply to other products such as Oracle Forms Developer
Identify 1-M relationship:
- Hierarchical form is essentially a nice interface for a 1-M relationship
- Registration form: Registration No is unique
- Parent table: contains Form PK as its PK
- Child table: table in the subform in a 1-M relationship with the parent table
- Registration form: Enrollment table
Identify the linking field:
- Join columns in the 1-M relationship
- Usually the PK-FK of the 1-M relationship
- Registration form: Registration.RegNo, Enrollment.RegNo
Determine other tables:
- Tables used in the main form and subform besides the 1-M relationship
- Data from other tables provides context for the form: shows related data
- Registration main form: Student table
- Registration subform: Offering, Course, Faculty tables
Determine updatable tables:
- Underlying business process: what db updates does the business process support
- Main form: parent table is usually updatable; sometimes it is not updatable
- Subform: child table is almost always updatable
- Should other tables be updatable directly in the form or indirectly through a link
to another form?
- Registration form:
- Registration updatable in the main form
- Student not updatable: link to another form to update Student data
- Enrollment updatable in the subform
- Faculty, Course, Offering: different business processes to update these tables
Write queries:
- Each query must support updates to the tables identified in Step 4
- For reasonably complex forms, 1-M updatable query for main form and subform
- Apply rules of 1-M updatable queries
- 1-M relationships in each query differ from the 1-M relationship for the form
- 1-M relationship for the form determines how main and subform are linked

25. Registration Form Requirements
1-M relationship: Registration-Enrollment
Linking fields: Registration.RegNo, Enrollment.RegNo
Other tables
Main form: Student
Subform: Offering, Course, Faculty
Updatable tables: Registration, Enrollment
Registration form:
- RegNo is the PK of the form
- OfferNo is unique in the subform
- Registration updatable in the main form
- Student not updatable: link to another form to update Student data
- Enrollment updatable in the subform
- Faculty, Course, Offering: different business processes to update these tables

26. Registration Main Form Query
SELECT RegNo, RegTerm, RegYear,
RegDate, Registration.StdSSN,
Registration.StdSSN,
RegStatus, StdFirstName,
StdLastName, StdClass,
StdCity, StdState
FROM Registration INNER JOIN Student
ON Registration.StdSSN =
Student.StdSSN
Write queries:
- Each query must support updates to the tables identified in Step 4
- For reasonably complex forms, 1-M updatable query for main form and subform
- Apply rules of 1-M updatable queries
- 1-M relationships in each query differ from the 1-M relationship for the form
- 1-M relationship for the form determines how main and subform are linked

27. Registration Subform Query
SELECT RegNo, Enrollment.OfferNo, OffTime,
Offering.CourseNo, OffLocation,
OffTerm, OffYear, Offering.FacSSN,
FacFirstName, FacLastName,
CrsDesc, CrsUnits
FROM ( ( Enrollment INNER JOIN Offering
ON Enrollment.OfferNo =
Offering.OfferNo )
INNER JOIN Course
ON Offering.CourseNo =
Course.CourseNo )
LEFT JOIN Faculty
ON Faculty.FacSSN =
Offering.FacSSN
In the subform query for the Registration Form, there is one other issue. The subform query will only display an Offering row if there is an associated Faculty row. If you want the subform to display Offering rows regardless of whether there is an associated Faculty row, a one-sided outer join should be used, as shown above. You can tell if an outer join is needed by looking at example copies of the form. If you can find offerings listed without an assigned faculty, then you need a one-sided outer join in the query.

28. Faculty Assignment Form
The goal of this form is to support administrators in assigning Faculty to Course Offerings.
This form cannot be used to insert new Faculty rows or change data about Faculty. In addition, this form cannot be used to insert new Offering rows. The only update operation supported by this form is to change the Faculty assigned to teach an existing Offering.

29. Faculty Assignment Requirements
Step 1: Faculty (parent table), Offering (child table)
Step 2: Faculty.FacSSN, Offering.FacSSN
Step 3: Course table in the subform
Step 4: update Offering.FacSSN
The 1-M relationship for the form is the relationship from the Faculty table to the Offering table. This form cannot be used to insert new Faculty rows or change data about Faculty. In addition, this form cannot be used to insert new Offering rows. The only update operation supported by this form is to change the Faculty assigned to teach an existing Offering.

30. Faculty Assignment Queries
Main form
SELECT FacSSN, FacFirstName,
FacLastName, FacDept
FROM Faculty
Subform
SELECT OfferNo, Offering.CourseNo,
FacSSN, OffTime, OffDays,
OffLocation, CrsUnits
FROM Offering INNER JOIN COURSE
ON Offering.CourseNo =
Course.CourseNo

31. Hierarchical Reports
Stylized presentation of data appropriate to a selected audience
Use nesting (or indentation) to provide a visually appealing layout
Vocabulary
Group: sorted field; usually indented
Detail line: innermost field
Hierarchical Report: a formatted display of a query using indentation to show grouping and sorting.
Hierarchical reports (also known as control break reports) use nesting or indentation to provide a visually appealing format. The major advantage of hierarchical reports is that users can grasp more readily the meaning of data that are sorted and arranged in an indented manner. The standard output of a query (a datasheet) is not easy to inspect.
Each indented field is known as a group. The nesting of the groups indicates the sorting order of the report.
The innermost line in a report is known as the detail line. The detail lines also can be sorted.

32. Example Hierarchical Report
The Faculty Schedule Report shows data arranged by department, faculty name, and quarter. In the Faculty Schedule Report, detail lines show the course number, offering number, and other details of the assigned course. In the Faculty Schedule Report, the detail lines are sorted by course number.
Groups: department, name, and term
Detail line: courseno, offerno, days, start time, location

33. Summary Data in Detail Lines
To improve appearance, hierarchical reports can show summary data in the detail lines, computed columns, and calculations after groups. The detail lines in Figure 10.9 show the enrollment (number of students enrolled) in each course offering taught by a professor. In SQL, the number of students is computed with the COUNT function. The columns Percent Full ((Enrollment/Limit) * 100%) and Low Enrollment (a True/False value) are computed. A check box is a visually appealing way to display true/false columns. Many reports show summary calculations after each group. In the Faculty Work Load Report, summary calculations show the total units and students as well as average percentage full of course offerings.

34. Query Formulation Skills
Less difficult than skills for forms
Inspect report
Match fields in the report to database columns
Determine the needed tables
Identify the join conditions
Determine the level of detail
Row data versus summary data
Query should provide data for the detail lines
Formulating queries for reports is similar to formulating queries for forms. In formulating a query for a report, you should (1) match fields in the report to database columns, (2) determine the needed tables, and (3) identify the join conditions. Most report queries will involve joins and possibly one-sided outer joins. More difficult queries involving difference and division are not common.
In some ways, formulating queries for hierarchical reports is easier than for hierarchical forms. Queries for reports do not need to be updatable (they usually are not updatable). In addition, there is only one query for a report as opposed to two or more queries for a hierarchical form.
The major query formulation issue for hierarchical reports is the level of the output. Sometimes there is a choice between whether the query’s output contains individual rows or groups of rows. A rule of thumb is that the query should produce data for detail lines on the report.
With most reporting tools, it is easier to perform aggregate calculations in the query when the detail line of the report shows only summary data.

35. Faculty Work Load Query
SELECT Offering.OfferNo, FacFirstName, FacLastName,
FacDept, OffTerm, CrsUnits, OffLimit,
Count(Enrollment.RegNo) AS NumStds,
NumStds/Offlimit AS PercentFull,
(NumStds/Offlimit) < 0.25 AS LowEnrollment
FROM Faculty, Offering, Course, Enrollment
WHERE Faculty.FacSSN = Offering.FacSSN
AND Course.CourseNo = Offering.CourseNo
AND Offering.OfferNo = Enrollment.OfferNo
AND ( ( Offering.OffTerm = 'Fall'
AND Offering.OffYear = 2005 )
OR ( Offering.OffTerm = 'Winter'
AND Offering.OffYear = 2006 )
OR ( Offering.OffTerm = 'Spring'
AND Offering.OffYear = 2006 ) )
GROUP BY Offering.OfferNo, FacFirstName, FacLastName,
FacDept, OffTerm, CrsUnits, OffLimit
The query for the Faculty Work Load Report groups the data and counts the number of students enrolled. The query directly produces data for detail lines on the report. If the query produced one row per student enrolled in a course (a finer level of detail), then the report must calculate the number of students enrolled. With most reporting tools, it is easier to perform aggregate calculations in the query when the detail line of the report shows only summary data.
The other calculations (PercentFull and LowEnrollment) can be performed in the query or report with about the same effort. Note that the field OffLimit is a new field in the Offering table. It shows the maximum number of students that can enroll in a course offering.

36. Summary Significant benefits with a modest performance penalty
Foundation of application data requirements
Updatable views important for hierarchical forms
Carefully analyze data requirements before developing forms and reports
Benefits:
- Reduced software maintenance
- Improved security
- Simplicity
- Performance penalty: slight in most cases
Application data requirements:
- Queries for forms and reports: significant application development skills
- Links nonprocedural access to application development
- Other details (user interface, workflow) are also important
Updatable view:
- Changes to view automatically mapped to base tables
- Multiple table view rules require careful study: no industry standards
Form development:
- Perform 5 steps before developing form
- Practice with textbook Chapter 10 problems
- Difficult to debug form with errors in data requirements