* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Manual - Animated DataBase Courseware
Survey
Document related concepts
Extensible Storage Engine wikipedia , lookup
Oracle Database wikipedia , lookup
Tandem Computers wikipedia , lookup
Microsoft Access wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Concurrency control wikipedia , lookup
Ingres (database) wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational algebra wikipedia , lookup
Clusterpoint wikipedia , lookup
Database model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Transcript
ANIMATED DATABASE COURSEWARE (ADbC) Instructor’s Guide Version 1.2 Mario Guimaraes Meg Murray http://adbc.kennesaw.edu ANIMATED DATABASE COURSEWARE (adbc.kennesaw.edu) Version 1.1 Page I) DATABASE DESIGN ………………………………………………………………………… 04 I.1) Database Design -> E-R Diagrams ............................................................. ........................ 04 I.2) Database Design -> Scenarios to ER ………………………………………....................... 14 I.3) Database Design -> E-R to Tables …………………………………………....................... 23 I.4) Database Design -> Normalization ……………………………………….......................... 38 I.5) Database Design –> Denormalization ………………………………………...................... 42 I.6) Database Design –> Anomalies …………………………………….................................. 43 I.7) Database Design -> Construct ER (under testing) ……………………………………… 49 II) SQL ............................................................................................................................................ 51 II.1) SQL -> Interactive SQL …………………………………………………………………. 51 II.1.1) SQL -> Interactive SQL -> DDL and DML ……………………………………… 52 II.1.2) SQL -> Interactive SQL -> Queries – Basic ……………….................................... 53 II.1.3) SQL -> Interactive SQL -> Queries – Advanced …………..................................... 55 II.1.4) SQL -> Interactive SQL ->Code– Basic …………………………………………... 57 II.1.5) SQL -> Interactive SQL ->Code - Advanced ……………………………………... 58 II.1.6) SQL -> Interactive SQL -> Misconceptions ……………………………………… 59 II.1.7) SQL -> Interactive SQL -> Join …………………………………………………… 60 II.1.8) SQL -> Interactive SQL -> Minus …........................................................................ 62 II.2) SQL -> More SQL (visual basic) ……………………………………………………….. 65 II.3) SQL -> Embedded SQL ……… ,………………………………………………………… 65 II.3.1) SQL -> Embedded SQL -> Oracle…….……….,…………………………………. 65 II.3.2) SQL -> Embedded SQL -> Cursors ………………………………………………. 68 II.4) SQL -> Stored Procedures & Functions ………………………………………………… 70 II.4.1) SQL -> Stored Procedures & Functions -> Procedures …………………………. 70 II.4.2) SQL -> Stored Procedures & Functions -> Functions …………………... ……….72 III) Transactions …………………………………………………………………………………. 73 III.1) Transactions -> Concurrency ………………………………………………………….. 73 III.1.1) Transactions -> Concurrency -> Simple ………………………………………… 74 III.1.2) Transactions -> Concurrency -> Database ……….. …………………………… 75 III.1.3) Transactions -> Concurrency -> Error Handling ………………………………. 76 III.2) Transactions -> Recovery ………………………………………………………………. 77 III.2.1) Transactions -> Recovery -> Least Recently Used ……………………………… 77 III.2.2) Transactions -> Recovery -> Data Recovery ……..……………………………. 79 III.3) Transactions -> Triggers ……………………………………………………………….. 81 III.3.1) Transactions -> Triggers -> Triggers – Introduction ………………………….. 81 III.3.2) Transactions -> Triggers -> Triggers & Locks ………………………………… 83 2 IV) Security ……………………………………………………………………………………… IV.1) Security -> Referential Integrity ………….……………………………………… IV.2) Security -> Security Matrix ……………………………………………………….. IV.3) Security -> Row Level Security …………………………………………………… IV.4) Security -> SQL Injection …………………………………………..……………... IV.5) Security -> Database Inference …………………………………………………… IV.6) Security -> Database Auditing ……………………………………………………. 84 84 86 89 90 93 96 V) HOW ADBC CAN BE USED ……………………………………………………….. 101 V.1) Database Design –> ER Notation ………………………………………………………. V.2) Database Design –> Converting Scenarios to E-R ………………………………… V.3) Database Design -> Converting E-R Diagrams to Tables ……………………………. V.4) Database Design –> Normalization -> Tutorial …………… ……………………….. V.4.1) Database Design -> Normalization -> Tutorial …………………………………….. 101 103 105 106 106 V.4.2) Database Design -> Normalization -> Identify FD - under construction………… 107 V.4.3) Database Design -> Normalization -> Converting One Big Table and FD to 3NF.. 108 V.5) SQL -> Interactive SQL ……………………………………………………………… V.5.1) SQL -> Interactive SQL -> DDL and DML ……………………………………… V.5.2) SQL -> Interactive SQL -> Queries ………………………………………………… V.5.3) SQL -> Interactive SQL -> Code …….……………………………………………… V.5.4) SQL -> Interactive SQL -> Join and Minus ……………………………………….. V.5.5) SQL -> Interactive SQL -> Misconceptions ……………………………………….. V.5.6) SQL -> More SQL (visual basic) ……………………………………………………. 109 110 111 112 113 114 114 V.6) SQL -> Embedded SQL …….. ………………………………………………………… V.7) SQL -> Stored Procedures & Functions ……………………………………………… V.8) Transactions -> Concurrency ………………………………………………………….. V.9) Transactions -> Recovery ………………………………………………………………. V.10) Transactions -> Triggers ……………………………………………………………… V.11) Security -> Referential Integrity …………………………………………….………. V.12) Security -> Security Matrix ………………………………………………………….. V.13) Security -> Row Level Security ……………………………………………………… V.14) Security -> SQL Injection …………………………………… ……………………… VI) Enhancements being Performed on ADbC ……………………………………………. VII) Other Database Coursewares ……………………………………………………. 115 115 115 115 117 117 117 117 117 117 117 3 INTRODUCTION The screen below is the opening screen of the Animated Database Courseware. For ease of navigation, this software has a header and a menu window at the top and a area on the left that tells you the exact program you are in. If you need more screen space, at any time within a program, there is a pop-out option (see link below on the bottom left) I) DATABASE DESIGN The Database Design Module consists of E-R Notations, Converting E-R Diagrams to Tables, Converting Scenarios to E-R Diagrams, Normalization, Denormalizations, and Anomalies. I.1) Database Design -> E-R Notations An Entity-Relationship (E-R) Diagram is a conceptual representation of data and its relationship. E-R Diagrams were first proposed by Peter Chen in 1976. Since then, many different authors have proposed many different notations and variations. Nevertheless, all E-R 4 Diagrams have 4 components: Entity, Relationships, Attributes and Cardinalities. For simplicity reasons (to avoid cluttering), the Attributes are sometimes not displayed. Unfortunately, every book or software has a slightly different notation of E-R Diagrams and this can lead to some confusion. The purpose of this program is so that students can quickly associate one notation with another. Figure I.1.1 – E-R Diagram This animation consists of seven different types of relationships : 1-N Binary Non identifying, 1-N Binary identifying, N-N Binary, 1-1 Binary, 1-N Unary, Generalization 1 (incomplete, overlap) and Generalization 2 (complete, disjoint). For each of these relationships, the user can see up to six different Diagram notations. If the user clicks on the Intro link, they will get a brief explanation about ER diagrams. By clicking on the Help link, they will get an explanation on how to use the program as far as what keys to press, what windows they can drag, etc. 5 Figure I.1.2 shows a 1-N Binary Non-Identifying Relationship in three different notations: Maximum, Minimum/Maximum, and James Martin (from Hoffer book). It is a binary relationship because there are two entities involved. It is non-identifying because one does not identify the other one. There is not an identifying/weak entity such as the one described in Figure I.1.4. The numbers on each side of the relationship indicate the cardinality. Note that when there is only one number on each side, it always refer to the maximum cardinality. According to the diagrams in Figure I.1.2, an Employee can belong to a maximum of 1 Department and a Department can have a maximum of many Employees. The minimum and maximum is a more complete description of the relationship, but also more complex. It reads, an employee works may not work in any Department (zero) and may work in at most 1 department. A department has at least one employee (1) and may have many employees (N). It is good to start students by looking at the Maximum Notation and then Explain the Minimum/Maximum by comparing it with the Maximum. There is also the Notation found in the Hoffer book (created by James Martin). The oval corresponds to optional, the hashmark to one and the crowfoot to many. It is easy to explain this notation, when you compare it side by side with the Minimum/Maximum notation. Figure I.1.2 – One-to-many Binary Non Identifying Relationship – part I 6 Figure I.1.3 shows the One-to-many Binary Non Identifying Relationship in the three other notations. The IDEF1X notation is a notation commonly found in case tools. The IDEF1X notation uses the dashed line to distinguish the one-to-many non-identifying relationship from the one-to-many idenfying relationship. The Kroenke notation shows the maximum cardinality inside the diamond and the minimum cardinality close to the respective entities. In the Class Diagram notation, the asterisk shows the many. A class diagram is a superset of an E-R Diagram (actually a superset of an Extended E-R Diagram). A class is more broad than an Entity. A class can be an entity class, a control class or an interface class. Besides classes can have methods (functions) as well as attributes. The attributes in class diagram are frequently called properties and the relationships called associations. Figure I.1.3 – One-to-many Binary Non Identifying Relationship – part II 7 Figure I.1.4 shows a Binary One-to-many Identifying Relationship in five different E-R Diagram notations. Note that It is an Identifying Relationship because there is a weak or dependent entity called Section. Section can’t exist without course. Furthermore, section has a composite primary key (course_id, Section_id) and part of the Primary key of Section is the primary key of course. In an identifying relationship, the minimum cardinality of the parent entity (in this example, course) is always one or mandatory. Note that some notations draw the weak/dependent entity differently, such as a round rectangle or a rectangle inside a rectangle. When we create a weak entity and we are specifying the Foreign key, we normally cascade deletes, as opposed to a strong entity in the previous example, where we rarely want to cascade deletes. Figure I.1.4 – Binary one-to-many Identifying Relationship 8 Figure I.1.5 displays a binary many-to-many (N-N) relationship. Note that a many-to-many relationship is never identifying. Therefore, for many-to-many relationships, we never use the terms identifying and non-identifying. A many-to-many Relationship. Can always be converted into two one two many relationships. Figure I.1.5 – Binary many-to-many (N-N) relationship 9 Figure I.1.6 displays a binary one-to-one (1-1) relationship, where a faculty can chair at most one department and a department is chaired by at most one faculty. Figure I.1.6 shows a Binary one-to-one (1-1) relationship 10 In a unary relationship (also called recursive relationship), there is only one entity involved and the relationships are between instances of the same entity. Figure 1.7 shows the unary relationship Employees manage Employees. Figure I.1.7 – Unary One-to-many – Employees Manage Employees 11 Figure I.1.8 displays a Generalization with supertype (superclass) Person and subtypes (subclasses) Faculty, Staff and Student. Generalizations are is-a relationships. For example, a Person is-a Faculty, a Person is-a Staff, a Person is-a Student. Leg, for example, could not be a sub-type, because we can NOT say that a Person is-a Leg. E-R Diagrams that include Supertype/Subtype relationships are called Extended E-R Diagrams (EER). Subtypes can be Incomplete/Partial or Complete/Total. Subtypes are incomplete when they don’t represent the all the possibilities of subtypes. For example, A Person doesn’t necessarily have to be a Faculty, Staff or Student. Sub-types can also be disjoint (exclusive) or overlapping (inclusive or notexclusive) In this example, the subtypes are overlapping because an instance of person can be an instance of two or more subtypes. For example, a person can be a Staff member and a Student at the same time. Figure I.1.8 – Generalization – Incomplete and Overlapping 12 Figure I.1.9 shows an example of Generalization II, that consists of a Complete (Total) and Disjoint (exclusive) sub-types. It is complete because every patient must be either an In-Patient or an Out-Patient . It is disjoint because a specific patient can NOT be In-Patient and Out-Patient at the same time. Figure I.1.9 – Generalization - Complete and Disjoint 13 I.2) Database Design -> Scenarios to ER For this sub-module, the user is given a scenario and identifies or converts the scenario into an ER Diagram. Figure I.2.1 - Scenarios to ER A scenario can be a Problem Specifications, a form or a report. Currently the first four scenarios are Problem Descriptions (Employees, Automobiles, Medical and Car Dealer). The next two (Orders, Phone) are Forms and the last two (Suppliers and University) are Reports. Figure I.2.2 shows a Scenario that is a Problem Description. The user navigates through the tabs (Solution 1, Solution 2, Solution 3, Solution 4) to see each specific solution or chooses the last tab, Show All, to see all solutions. Once they see the solution they believe is the correct solution on the screen, they choose the button Choose Solution, below the solution displayed. Figure I.2.2 – Scenarios to ER – Employee Works on Project 14 Figure I.2.3 displays a recursive relationship or unary relationship (Automobile parts contain automobile parts). In this figure, the user is looking at solution 3 (Solution 3 tab is selected above the ER), which is the correct solution. If the user now clicks Choose solution (button bellow the ER, the user will be informed that they chose the correct solution. Figure I.2.3 – Scenarios to ER – Auto Parts contain Auto Parts (Recursive Relationship) 15 Figure I.2.4 displays a problem description involving medical procedures. Notice that the complexity has increased and there are four entities (Patient, Referral, Procedure and Bills). Also notice that this ER diagram also displays attributes as indicated by the ovals. ER Diagrams may or may not display attributes so that the user can see a summarized view (without attributes) or a more detailed view (with attributes). Many CASE tools (tools that help you create an ER diagram) allows you to turn on and off the display attribute option. Figure I.2.4 – Medical Procedures 16 Figure I.2.5 is a car dealer scenario where the car is brought in for repair and assigned to a technician. Figure I.2.5 – a Car Dealer 17 Figure I.2.6 Shows a Form where products are being ordered. Note that instead of a Problem description, the scenario is a Form. When obtaining the requirements from a client, the user may obtain the problem description (typically through an interview) or simply request forms and documents. These methods (Interview and examining existing documentation) are not mutually exclusive, but supplement each other. Figure I.2.6 – Scenario Represented by a Form (Orders) 18 Figure I.2. 7 shows another scenario that is represented by a form. In this example, Company contains Phones. Figure I.2.7 – Scenario Represented by a Form (Phones) 19 Figure I.2.8 shows a scenario that is represented by a Report. On the top of the work area is a Report on Suppliers and in the bottom opart they should identify the solution. Note that the student is visualizing all four solutions and is selecting one of the solutions (Solution 2). Figure I.2.8 – Scenario Represented by a Report (suppliers) 20 Figure I.2.9 shows another scenario that is represented by a Report. On the top of the work area is a Report on College, Department and University and in the bottom part they should identify the solution. Note that the student is visualizing all four possible solutions in order to select the correct one. Figure I.2.9 – Scenario Represented by a Report (University) 21 Figure I.2.10 shows a scenario that is represented by a Problem Description. In this example, the correct solution is a ternary relationship. Figure I.2.10 – Example of a Ternary Relationship 22 I.3) Database Design -> E-R to Tables For converting E-R Diagrams to tables, the user is presented with a scenario such as the one shown in Figure I.3.1 where an Employee may be employed by one or none department and a Department may have many employees. Figure I.3.1 – Database Design – Converting E-R to Tables Next, the user is presented with a button to construct the E-R. The E-R is constructed and data is automatically loaded in the tables. However, the tables have no association (through foreign key, association table, etc.). The student is presented with several multiple-choice options. After each option, an animation is shown and the tables are completed. The pros and cons of each option are illustrated through animations. In many cases, there is not a single correct answer. 23 Binary One-to-many When the user chooses ER to Tables – Binary One-to-many, Employee Work _in Department, the screen in Figure I.3.2 is displayed. Figure I.3.2 – ER to Tables – Binary One-to-many When the user clicks Show / Hide Association he/she sees the screen displayed in Figure I.1.2.3, where Josh Smith, Mary Black and Andy Wallace are associated with the Accounting Department and Earl Tilley is associated with the HR Department. 24 Figure I.2.3 - – ER to Tables – Binary One-to-many with Associations shown Then the user clicks Proceed to Exercise, he/she will see a screen with four options. Figure I.2.4 - – ER to Tables – Binary One-to-many Exercise 25 Option A, adding the foreign key Dept_ID in the Employee table (child table) is the default option and when selected, the user will receive the screen in Figure I.2.5. Figure I.2.5 - – ER to Tables – Binary One-to-many Exercise – correct choice Option C, adding the foreign key Emp_ID in the Department table (parent table) is a wrong option and when selected, the user will receive the screen in Figure I.1.2.6. This is the wrong option because a Department may have more than one employee, and for each employee in the Department, a row of redundant data is added. Emp_ID is a multi-valued attribute in the employee table because Dept_ID does NOT determine Emp_ID. It is important to emphasize that the redundant data results in insert, update and delete anomalies. 26 Figure I.2.6 - – ER to Tables – Binary One-to-many Exercise – wrong choice ER to Tables – Unary One-to-many Figure I.2.7 shows a unary (recursive) relationship where instances of an entity such as John, are related to other instances such as Franklin and Mary. Figure I.2.7 - – ER to Tables – Unary One-to-many When the user proceeds to exercise, the screen in Figure I.2.8 is shown. 27 Figure I.2.8 -– ER to Tables – Unary One-to-many - Exercise Most literature recommend that the default solution for a unary one-to-many relationship is the same as a binary one-to-many (add a Foreign key) as displayed in Figure I.2.9. Figure I.2.9 - One-to-many Unary Relationship - Add Foreign Key - Default Solution The other valid solution is to create an intersection table as shown in Figure I.2.10. This solution avoids the null value, however, there is an overhead of a second table. 28 Figure I.2.9 - One-to-many Unary Relationship – Create an Intersection Table 29 The option to create a Manager table as shown in Figure I.2.10 – creates unnecessary redundancy. With this solution, every time information about a manager needs to be updated, it will have to be updated in the Employee table and in the Manager table. Figure I.2.10 - One-to-many Unary Relationship – Create a Manager Table – Wrong Solution 30 ER to Tables – Binary One-to-one In the example of Figure 1.2.11, an Employee can use a maximum of 1 Parking Space and a Parking Space is assigned to a maximum of one Employee. Figure 1.2.11 – ER to Tables – Binary One-to-one Figure 1.2.12, shows the Binary one-to-one Relationship where the user is assigned at most one parking space and a parking space is assigned to at most one user. In a binary one-to-one relationship, we may insert a foreign key on either side (never on both in order to avoid redundancy), because either way there will be no multi-valued attributes since the maximum cardinality is one. Therefore, in order to decide which side is best, we need to look at which side will generate less null values (preferably no null values). For Figure 1.2.12, it is hard to tell which is the correct option (Option A or Option C). Apparently, either table that we append the Foreign Key, it may not generate too many nulls. One would have to examine the specific scenario of the client. Create an intersection table may be a good option when a foreign key on either side will generate a large amounts of nulls (which is probably no the case in the example below. Appending a foreign Key on both sides will never be a good option, because it generates unnecessary redundancy. 31 Figure 1.2.12 – Binary one-to-one Relationship – Employee assigned to Parking Space For the one-to-one relationship Faculty Chairs Department displayed in Figure 1.2.13, it is easy to see that adding the Foreign key in Name (Faculty Name) in the Department table is the best solution. Since every Department has a chair, there will be no null values. Adding a Foreign Key D_No (Department Number) in the Faculty table will generate many null values since most faculty do NOT chair a department. Figure 1.2.13 – Binary one-to-one Relationship – Faculty Chairs Department In the example in Figure 1.2.14, the user chose to append the wrong Foreign Key, because there will be a null value for every faculty that doesn’t chair a department. Actually, the example 32 below does not give an idea of how many null values there will be, because most faculty will not be chairing a department, thus will have a null value for D_No (Department Numbers). Figure 1.2.14 - Binary one-to-one Relationship – Faculty Chairs Department – wrong option Figure 1.2.15 shows the correct answer, appending a foreign key ssn in Department table. Since every Department will have one and only one chair, this solution will avoid null values and multivalued attributes. Figure 1.2.15 - Binary one-to-one Relationship – Faculty Chairs Department – correct option 33 Binary Many-to-many Relationship For a many-to-many binary relationship, the best solution is always (at least theoretically) to create an associate table. This way, it avoids multi-valued attributes as well as null values. In any many-many-relationship, if we create a foreign key on either side, it will generate multi-valued attributes, Figure 1.2.15 - Binary many-to-many Relationship After the user chooses the correct solution from the screen displayed in Figure 1.2.15, the system will display the screen shown in Figure 1.2.16 Figure 1.2.16 - Binary many-to-many Relationship – Correct Solution 34 Unary Many-to-many Relationship Figure 1.2.17 shows the unary relationship Project has alternative Projects. Similar to a binary many-many relationship, the correct solution is to create an intersection table. Figure 1.2.17 - Unary many-to-many Relationship The correct solution is displayed in Figure 1.2.18 below. Figure 1.2.17 - Unary many-to-many Relationship – Correct Solution 35 Generalization Figure 1.2.18 displays a generalization (is-a relationship). Although generalizations don’t convert naturally into tables, the default solution is to create a table for the super type and a table for each subtype (Figure 1.2.19). Figure 1.2.18 – Generalization Figure 1.2.19 shows a table for the supertype and a table for each sub-type. The primary key of the supertype will also become the primary key of each subtype. The primary key of each subtype is also a foreign key, pointing to the respective supertype. Figure 1.2.18 – Generalization – Default Solution 36 Figure 1.2.19 and Figure 1.2.20 show two other alternatives for converting Generalizations into tables. Figure 1.2.18 – Generalization – Eliminate the Supertype Figure 1.2.19 Eliminates the subtypes and places the generalization into one table. As can be seen in the figure below, the biggest problem with this solution is the large number of NULLS that has been created. Figure 1.2.19 – Generalization – Eliminate the Subtypes 37 I.4) Database Design -> Normalization This section is also being currently enhanced and there may be some incompatibilities between the User Guide and the software as we are completing new examples and converting Normalizations that are Visual Basic to Flash as we are standardized this module in Flash. Version 1.2 of this manual should have major changes in the Normalization (as well as the Embedded SQL sub-module). Figure I.4.1 – Normalization Menu Figure I.4.2 – Normalization Tutorial Figure I.4.2 – Normalization Tutorial – What is Normalization ? 38 Figure I.4.3 – Normalization Tutorial – UnNormalized Table Figure I.4.3 – Normalization Tutorial – Third Normal Form 39 If you select Exercises (Visual Basic) from the Database Design -> Normalization Menu, you will receive the screen on Figure I.4.3. Figure I.4.3 – Exercises – Visual Basic Figure I.4.4 shows the Cleaning Company – 3NF scenario. The user is given a table and a Dependency Diagram and is requested to normalize the table to 3NF. Figure I.4.4 shows the Cleaning Company – 3NF scenario Above each attribute (column) of a table, there is a checkbox. As the user selects a checkbox, they are requested to identify if the attribute will be part of the primary key (see Figure I.4.5 ). 40 Figure I.4.5 Cleaning Company – 3NF scenario – Selecting an attribute After one or more columns have been checked, as in Figure 1.4, the Create table button is inhibited (Figure I.4.6). Figure I.4.6 Cleaning Company – 3NF scenario – CreateTable Button Inhibited By clicking the Create Table button from Figure I.4.6, a table is created with the attributes checked. You receive the screen displayed in Figure 1.4.7. When you have completed the normalization, click the Finished button. Figure I.4.7 – Result after CreateTable 41 Button is chosen from Figure I.4.6 I.5) Database Design –> Denormalization Although our first goal in Relational Database Design is to Normalize the table in order to eliminate update anomalies, thus improving maintenance, normalization may not always be the most desirable design strategy in all scenarios. Normalization breaks down a table into smaller tables. When queries have to search through multiple tables to find the needed data, it degrades updates. Certain scenarios are more suitable to denormalization (breaking the normalization rules. These scenarios include read only database, queries that are taking too long to execute and whenever the number of multivalued attributes and null values are reduced to a minimum. Figure I.5.1 Asks the user for the situation that is more appropriate to denormalization. The answer is B – When most students submit an application Figure I.5.1 – Denormalization 42 I.6) Database Design –> Anomalies The purpose of this sub-module is to understand exactly what are the update anomalies caused by bad denormalization. I.6.1) Insert in a normalized table (FK on the child table) Figure I.6.1 – Insert 1 (normalized table) 43 I.6.2) Insert Anomaly – Insert in a badly designed table (with FK on the parent table) 44 I.6.3) Update in a normalized table (FK on the child table) 45 I.6.4) Update Anomaly – Insert in a badly designed table (with FK on the parent table) 46 I.6.5) Delete in a normalized table (FK on the child table) 47 I.6.6) Delete Anomaly – Insert in a badly designed table (with FK on the parent table) 48 I.7) Database Design -> Construct ER (under testing) This module is currently under testing. It is a tool to construct ER diagram (similar to MS-Visio, ER Win), but it is more reduced than a commercial tool. Although student can construct any reduced ER Diagram (there is a limit to the number of Entities and Relationships involved to 10, for example), we have two scenarios where the student is to construct ER diagrams and there is specific feedback. Below are the two scenarios. Library Database (Draw an E-R Diagram). A Reader can be Faculty, a Staff or a Student. A book may have several copies. While the books is identified by an ISBN number, the copy is identified by the ISBN number and the copyNumber. A reader can Check out a maximum five instances of different books. An instance of a book can be checked out by many readers. We need to track alternative books for a reader in case all copies of a specific book is checked out. A reader has as attributes ssn and name. Faculty, Staff and Student also have their own individual attributes. Faculty has officeNum and PhoneNum. Staff has officeNum and Student has major and gpa. A book has an ISBN number, a Title, an Author, a Publisher and the Year of Publication. Draw the complete E-R Diagram of the Scenario. You will need to show: 1) A super class / Sub-class relationship 2) An identifying relationship where one entity is a weak entity 3) A non-identifying relationship 4) A recursive relationship. Hint: Does a reader checks out a book or a bookcopy ? Is it a book or a bookcopy that has alternatives ? 49 Course Offerings (Draw an E-R Diagram). For the following scenario, draw an E-R Diagram A faculty (ssn, name, dept) teaches at least one section (offering) of a course and at most four sections. Each section is taught at a different day/time. An faculty can be a Computer Science faculty or a Math faculty. If it is a computer Science faculty, it has an attribute thesisArea, to identify the Area that the instructor advises thesis. A course (course number, course name, number of credits) may have at most three section (offering). A course may have at most one pre-requisite, but may be pre-requisites for several other courses. A student (ssn, name, gpa) may not be taking a course, but can be taking at most 5 different class offerings. You will need to show: 1) A super class / Sub-class relationship 2) An identifying relationship where one entity is a weak entity 3) A non-identifying relationship 4) A recursive relationship. 50 II) SQL When the user chooses the SQL Menu, they will see the options in Figure II. Figure II – SQL Menu II.1) SQL -> Interactive SQL When the user chooses Interactive SQL, he/she will receive the radio button options on the left side of Figure II.1. Note that in the work area, the first example is shown Figure II.1 - Interactive SQL Menu 51 II.1.1) SQL -> Interactive SQL -> DDL and DML The first option of the Interactive SQL menu is an introduction to Data Definition Language (DDL) and Data Manipulation Languag (DML). The following windows are available: A DDL Window (Create, Alter and Drop Table) a DML Window (Insert, Update, Select and Delete), the Data Window (Employees table) a Control Window (Reset ) as well as an SQL Code window. In the example below, the Insert button was clicked. Therefore the Insert commands are showing up in the SQL Code Window and the rows inserted are showing up in white background. Figure II.1.1 - DDL and DML 52 II.1.2) SQL -> Interactive SQL -> Queries – Basic The second option on the left side of the screen, SQL Queries – Basic (formerly called constructing SQL Queries – Basic), displays the SQL command that implements one of Codd’s Relational Algebra primitives - Projection, Restriction (originally known as Selection), Multiplication (officially known as Cartesian Product), Join, Union, Intersect, Difference (also known as Minus). The user selects the tab corresponding to one of these relational algebra primitives and then through the drop down menus, changes the variable part of the SQL statement in the SQL command window. This introduces the user to the SQL statements, showing him/her that there is a fixed part (SQL keywords) as well as the variable part. Special emphasis is given to Projection, Restriction and Join, since they are the most prevalent in nearly all queries that are needed. Figure II.1.2 shows a simple Projection. In the example below, as the user changes the columns to be projected, the Problem window and the Results window changes correspondingly. For each of our SQL http://science.kennesaw.edu/~mguimara/3310/spring08/hw2.htm assignments and at at http://science.kennesaw.edu/~mguimara/3310/spring08/hw3.htm, we describe in parenthesis, where in the Database Courseware that you can find an equivalent solution. For example: 6) List name and city for all customers (Interactive SQL -> Queries-Basic -> Projection). During a closed lab, we saw students who had never been exposed to sql use the Database courseware efficiently to find these solution. Figure II.1.2 - Queries – Basic - Projection 53 To explain the Relational Algebra operation and how it relates to SQL, we over on the chart/table that we have at http://science.kennesaw.edu/~mguimara/3310/RA_SQL.htm. We find it very useful to be able to compare SQL with Relational Algebra, with Procedural Pseudo-code. Besides going over each relational algebra operation with a sample database, we the necessary input for each operation. We emphasize that Projection and Restriction require only one table as input. Multiplication requires any two tables as input. Join requires any two tables with one common column and Intersect/Union/Difference require two tables with the exact same column. Students often wonder why Intersection, Union and Difference have any practical value since it is rare two have two tables with exactly the same column headings. However, we explain that as long as what is projected from one table has the same column heading with what is projected from another table, the SQL syntax allows the operation. In the example in Figure II.1.2, it is what is projected that have to be the same attributes (SELECT name, species and breed ..); It is not registered_pets that need the exact same attributes as sheltered_pets; Figure II.1.2.2 - Queries – Basic - Difference 54 II.1.3) SQL -> Interactive SQL -> Queries – Advanced Queries Basic (Formerly called Constructing SQL Queries – Advanced), consists of the additional SQL clauses that can be found in any relational DBMS. Our instructors use this applet extensively to describe these clauses in the classroom. It is also used in lab as a reference (once the student doesn’t know the answer, he/she goes to the specific example in the Database Courseware that resolves the same concept. The functions available are count, sum, average, min, and max. We have found that the Function is self explanatory for most students. The only explanation that may be useful is to show how the COUNT reacts different when there are duplicates and we use distinct and when there are null values. Figure II.1.3.1 - Queries – Advanced - Function The GROUP BY allows the student to GROUP BY StudentID or TestID. For the GROUP BY, it is important to explain that the user should select by the same column that they are grouping by. In other words. In other words, if you GROUP BY TestID, you should SELECT TestID. If you GROUP BY StudentID, you should SELECT StudentID. A common mistake in our labs is that students group by cname and select by cid or vice-versa. 55 The HAVING clause is explained as the WHERE of the GROUP BY. It is important to explain that the WHERE clause is processed before the GROUP BY, so you can’t have WHERE sum(score) >200 because you can’t compare the result of sum(score) when the sum hasn’t been grouped; SELECT [columns] 5 FROM [tables] 1 WHERE [condition] 2 GROUP BY [columns] 3 HAVING [condition] 4 -- Projection is the last part processed of the SQL statement -- First we retrieve the tables For the Distinct, it is important to change the drop down menu to all and then back to distinct in order to point out the difference. Note that the all clause is rarely seen in an SQL statement because the ALL is the default. For the ORDER BY clause, we display it in class an example with ASCENDING and DESCENDING. To emphasize the importance of this clause, we mention that a Computer in French is called Ordinateur and in some Hispanic countries it is called Ordenador instead of Computador. The OUTER JOIN is a little bit more difficult for the students to grasp the concept. In Figure II.1.3.2, it is important to explain that the last row of the Result table would not be displayed if it was a NATURAL JOIN instead of an OUTER JOIN. It is also important to note that although the outer join is available in nearly all SQL Databases, the + is an oracle syntax. We also emphasize that it is more important to understand the concept of the OUTER JOIN than to be able to differentiate the right outer join from the left. A database programmer or DBA can figure that out the difference between the LEFT and the RIGHT OUTER JOIN immediately by trial as long as they understand the concept of OUTER JOIN. Figure II.1.3.2 - Queries – Advanced – Outer Join 56 II.1.4) SQL -> Interactive SQL -> Code – Basic Similar to the Constructing SQL Queries – Basic, this module displays the SQL code that implements each one of the Relational Algebra operations. However, in this module, instead of constructing the SQL query through drop down menus, the user clicks the Next Step button, to see one line of Procedural pseudo-code being highlighted. In class, we focus on showing how the procedural pseudo-code of Projection, Restriction and Join work. We leave the other operations to be done at home or cover it less thoroughly, since they are needed with much less frequency. Furthermore, the overhead of going over the procedural pseudo-code of a division operation is intense and the amount gained when successful, doesn’t compensate. Figure II.1.4 - Code – Basic 57 II.1.5) SQL -> Interactive SQL -> Code– Advanced Like in the basic applet in the previous example, we also do not go over in class the procedural pseudo-code of these advanced sql queries (with the exception of Restriction, Projection and Join). Nevertheless, some students find it interesting to analyze the code at home. Especially the ones that have a very good programming background. We are going to add the animation of the Outer Join to this applet. Figure II.1.5 - Code – Advanced 58 II.1.6) SQL -> Interactive SQL -> Misconceptions In this module, we have following windows: Objective, SQL, Relational Algebra, Data Window (Customers and Orders) and Temporary Data Window and Buttons. The SQL window corresponds is equivalent to the Relational Algebra window. Every time the Next Step button is clicked, one Relational Algebra command is executed and a Temporary Data Window pops up. Figure II.1.6.1 shows a frequent misconception. The user tries to retrieve customers that have ordered both ‘p02’ and ‘p04’, However, what it is doing is retrieving Customers that have a single order line with the value of both ‘p02’ and ‘p04’, which is impossible, so the result will always be no rows selected. To see the Correct solution for this exercise (Figure II.1.6.2), the user needs to click the Correct button. Wrong solutions are always in Red and Correct Solutions are always in green. Figure II.1.6.1 - Animating SQL w/Relational Algebra – Misconceptions – Wrong Solution Figure II.1.6.2 - Animating SQL w/Relational Algebra – Misconceptions – Wrong Solution 59 II.1.7) SQL -> Interactive SQL -> Join Figure II.1.7.2 shows an animation that we present in class. In this example, every time the Next Step button is clicked, one Relational Algebra command is executed and a temporary table pops up that contain the temporary data R1, R2, and R3 (see temporary tables in Figure II.1.8). When demonstrating this example in class, we first explain that each SQL window as well as the Relational Algebra window has the same solution but a different way. We also tell them that the windows are associated by color. We then ask, which what are the three most common (important) relational algebra operation and tell them that they are all in this example. Finally, we ask them to identify each one. Figure II.1.7.1 - Join 60 Note that the Figure II.1.7.2 shows three different SQL solutions and a Relational Algebra solution. Through the Window menu, the user can control which windows they want to visualize. Figure II.1.7.2 – Join with all windows 61 II.1.8) SQL -> Interactive SQL -> Minus This animation is similar to the other one, except that it is a minus. The example in Figure II.1.8 obtains names of Employees not working on project ‘X001’ ? Figure II.1.8 - Minus 62 II.2) SQL -> More SQL (visual basic) This section describes a list of programs that will be part of the Interactive SQL sub-module. However, these are implemented in Visual Basic. Currently, all these Visual Basic programs are also available in Java, except for the two programs that consists of Join with 1 table (recursive Join), Employee in same city and Employee in same department. Figure II.2 – More SQL (Visual Basic) – List of Programs SQL -> More SQL (visual basic) -> Employee in same city The animation Employee in the same city is an animation that we describe in the classroom because it has several interesting features that are emphasized in class. One that it builts on the join with two tables and the procedural pseudo-code is very similar the join with two tables. Another concept emphasized in this example is the concept of the alias. Although many other animations use the alias, it is usually not necessary, but done for convenience purpose (not having to write the full name of the table in multiple tables). In this example, the alias is a must to differentiate the two virtual tables. Another concept is that e1.ssn < e2.ssn where ssn is alpha-numeric. First, it is important to emphasize the need to differentiate the two employees. We don’t want to say that Mary Brown is in the same city as Mary Brown, which would happen if we omit e1.ssn < e2.ssn. The immediate solution that comes to mind is to write e1.ssn != e2.ssn. We then emphasize that it would still result in redundant and unnecessary information. We would have Mary Jones listed with Joe Nobles and then we would have Joe Nobles listed with Mary Jones. The last thing to explain is that we can perform comparisons between alphanumeric fields. To emphasize the 63 comparisons between alphanumeric characters, when this animation is re-done in Java, we will use Name of employee instead of ssn. Figure II.2.1 - More SQL (visual basic) -> Employee in same city 64 II.3) SQL -> Embedded SQL II.3.1) SQL -> Embedded SQL -> Oracle The embedded SQL program consists of accessing SQL from within a program. In these examples, there are several code windows, data window, a variable window and a result window. Every time we click the Next Step button, one command is executed and highlighted in each of the code windows. Note that all the code windows are equivalent. Figure I.3.1.1 show two different code windows (PL/SQL and PRO C). These are the two windows that appear by default. However, through the Window menu on the top left, the user can select which code window he/she wants to view. Figure II.3.1.1 - Embedded -> Oracle 65 Besides PL/SQL and C, there is the JAVA (with JDBC) window and the SQLJ window. The example in Figure II.3.1.2 shows PL/SQL code, PRO*C code and Java code side by side. A good question is to highlight a line of code in one window and ask students to identify the corresponding code in another window. Figure II.3.1.2 - Embedded SQL -> Oracle (code comparison) One interesting thing about this applet is how variable declarations are done in PL/SQL. We ask the students what do these variable declarations mean ? After they correctly reply, we then ask the students what is the advantage of declaring a variable as the same as a field in the table. We emphasize the fact that many errors in programming are the result of using the wrong data type when assigning a variable the value of another variable or a field coming from a table. We also emphasize the fact that if we modify the data type in the database, we don’t need to change the corresponding data type in the program (Data 66 Independence). The last point that is emphasized is that the SQL SELECT statement only returns one row. What would happen if the SQL statement returned more than one row ? After we explain that it would result in error because the variables can only contain the result of one row, we can explain the concept of pseudo-files (Cursors, recordsets, resultsets, etc.), and move to the Embedded SQL -> Cursor. 67 II.3.2) SQL -> Embedded SQL -> Cursors This is another program that we use inside the class. Although we show the Java code, we initially prefer to compare the PL/SQL code with the PRO*C code because these two are more similar (both use Cursors instead of Recordsets or Resultsets. In this animation, it is important to execute it step by step and show the DECLARE EMP (declare cursor), that allocates space in memory to store the pseudo-file/cursor, OPEN EMP (open cursor) that executes the SQL statement and stored the result in the cursor, and the FETCH Figure II.3.2.1 - Embedded SQL -> Cursors (execution) 68 Figure II.3.2.2 - Embedded SQL -> Cursors (code comparison) Like in the previous example, a good question is to highlight a line of code in one window and ask students to identify the corresponding code in another window. Another good question is to ask which line of code processes the SQL statement and place the result in the cursor ? Which one gets the current row in the cursor and places it in variables ? A current problem with this animation is that part of the code scrolls out of the window since the whole program may not fit in the screen at the same time. We are improving on this, by always selecting the correct lines to be shown. 69 II.4) SQL -> Stored Procedures & Functions When we select Stored Procedures & Functions from the SQL menu, we get the following menu (radio buttons) on the left side of the screen. Figure II.4 – Stored Procedures & Functions II.4.1) SQL -> Stored Procedures & Functions -> Procedures The stored function shows a window that has a CREATE PROCEDURE template. When the user selects the Create a Stored Procedure button and the Call Stored Procedure button, we see get the screen on Figure II.4.1. In this example we have a supertype vehicle and a subtype Trucks. The stored procedure assures that when we insert in the supertype, we also insert the corresponding row in the subtype. It is important to emphasize that if these operations were processed interactively, it would be likely that one SQL statement is executed and the other one is forgotten. 70 Figure II.4.1 .1 - Stored Procedures – Creating and Calling It is important to note that the Stored procedure in Figure II.4.1.1 was called from the SQL prompt. However, it could have had been called from within any popular programming language as long as the proper middleware was present (such as ODBC, JDBC, ADO). It is also important to click on the What is a Stored Procedure button and Why Stored Procedures to see the screens in Figure II.4.1.2 and II.4.1.3 respectively. Figure II.4.1 .2 - Stored Procedures – Definition Figure II.4.1 .3 - Stored Procedures – Motivation 71 II.4.2) SQL -> Stored Procedures & Functions -> Functions This applet is similar to a stored procedure, but notice that they are quite different the way it is called. The screen below shows a stored function that given the radius of the circle, it returns the area. It is important to emphasize that students when they get to this point, they have already used built-in functions (COUNT, SUM, AVG, MIN, MAX) and that the only difference is that these are user defined functions. Figure Figure II.4.2.1 displays the screen after the Create a Stored Procedure and Call the Stored Procedure buttons are clicked. Figure II.4.2.1 - Stored Functions – Creating and Calling It is also important to click on the What is a Stored Function button and Why Stored Funcion to see the screens in Figure II.4.1.2 and II.4.1.3 respectively. Figure II.4.2.2 - Stored Function – Definition Figure II.4.2.3 - Stored Function – Motivation 72 III) Transactions A transactions is a series of two or more instructions that they all have be executed or none, otherwise the database may become inconsist. Figure III.1 shows the transaction menu, where we have the concurrency, recovery and triggers option. Figure III – Transactions Menu III.1) Transactions -> Concurrency When Concurrency is chosen from the Transactions Menu (Figure III) the user receives the options in Figure III.1. The purpose of these concurrency animations are to illustrate that there is not a perfect solution, but some concerns that a database programmer and DBA must be aware of in order to avoid problems such Lost Updates, Deadlock. Before going into the concurrency animation, it necessary to give the user a quick overview of concurrency, by defining 1) what a transaction is, 2) Difference between Shared Lock and an Exclusive Lock, and Unit of Locking. Figure III.1 – Concurrency Menu 73 III.1.1) Transactions -> Concurrency -> Simple In the simple example illustrated in Figure III.1.2, there are two transactions accessing the database. There are four examples: Lost Update, Record Locking, Deadlock and Serial Locking. The current example as can be seen by the Panel on the top of the screen, is the Deadlock. It is recommended that the user clicks the Next Step button that is highlighted in yellow that may appear in Process I or in Process II every time either of the Next Step buttons is clicked. Nevertheless, the user may click on the either of the Next Step buttons at any time. Figure III.1.1 – Concurrency – Simple 74 III.1.2) Transactions -> Concurrency -> Database This applet is similar to the previous one. We have four examples: Without Record Locking, With Record Locking, Deadlock and Serial Locking. Different than the previous example, though, is that there is only one next button. Also, this example shows a real application. Transaction 1 is transferring US$1,5000.00 dollars from a user’s checking account to a user’s savings account (user who’s ssn is 111.11.1111. Transaction 2 checks if the sum of the user’s accounts is greater than US $2,000.00. If it is greater, it issues the user a credit card. If it is not the credit card is denied. However, if there is no record locking, the credit card is denied when it should be accepted. This is because transaction 2 accesses the two accounts when the $1,500.00 has been removed from the Checking account, but it has not been incremented in the savings account. If there is no locking, operations should e executed in the ABCDE order. Figure III.1.2 – Concurrency – Database Example 75 III.1.3) Transactions -> Concurrency -> Error Handling In The error handling examples the Pets table is updated. Then a select statement is issued to retrieve a row in the Owner’s table that is locked by another transaction. Depending if there is no error handling or what type of code is in the error handling procedure, a different result is produced. The user interacts with the system with one Next Step button. The Code Windows (PL/SQL and PRO*C code perform the exact same activities). Every time the Next Step button is clicked, one code line is executed in each of the code windows. By choosing the Window menu on the top left, one may also see a Java Window (see Figure III.1.4). Figure III.1.3 – Concurrency -> Error Handling Figure III.1.4 – Concurrency -> Code visualization 76 III.2) Transactions -> Recovery When Recovery is chosen from the Transactions menu, the options in Figure III.2 appears. Figure III.2 – Transactions - Recovery III.2.1) Transactions -> Recovery -> Least Recently Used Physical Updates to disk is typically done using the Least Recently Used Algorithm. This example also shows that every time we read a record, the block (page) in disk that the record is located is loaded into memory. In the example, we read record 215 and Page 3 is loaded, we read record 419 and Page 5 is loaded, we read record 218 and Page 3 is already loaded so we don’t need to re-load it. We read record 952 and page 10 is loaded. When we want to record 712, page 8 needs to be loaded, so the Least Recently Used page needs to leave memory. Since Page 3 was accessed when we Read Record 218, page 5 became the Least Recently Used and is the Dirty page (page that is updated in memory but not in disk) that needs to be updated. 77 III.2.1 – Least Recently Used algorithm 78 III.2.2) Transactions -> Recovery -> Data Recovery Figure III.2.2 shows the screen after the Summary button on the Logical versus Physical Update window is displayed. Figure III.2.2.1 – Data Recovery – Summary of Logical versus Physical Update Figure III.2.2.2 shows the screen after the Summary button on the System Failure window is displayed. Some questions that should be asked while displaying the software in class are: When a power failure occurs, which should prevail, the Physical Updates or the Logical Updates ? Answer: Logical Updates. If it is the Physical Logical Updates, how can we get the pages to disk after the Power Failure? Answer: logfiles. Figure III.2.2.2 – Data Recovery – System Failure 79 The screen displayed in Figure III.2.2.3 is shown when the Test 1 panel chosen. Note that the information window on the right is displayed when the Tc (time of checkpoint) button is chosen from the Transactions window on the left. Figure III.2.2.3 – Database Recovery – Test 1 When we click one of the Transactions button (T1-T5) from the Transactions window, the Questions window appears in the bottom of the screen. In Figure III.2.2.4 the Transaction T2 button has been chosen, so the questions refer to transaction 2. For every button clicked in the Questions menu, a feedback is given. Figure III.2.2.4 – Database Recovery – Test 1 – T2 80 III.3) Transactions -> Triggers When Triggers is chosen from the Transactions menu, the options in Figure III.3 is displayed. Figure III.3 – Triggers Menu III.3.1) Transactions -> Triggers -> Triggers – Introduction Figure III.3.1 1 is displayed when we choose Triggers – Introduction from the menu displayed in Figure III.3 and then click the button Create a Trigger. It is important to explain what the :new means. Is it from the Employees table or the Department Table ? Figure III.3.1.1 - Triggers – Introduction 81 Just as important as understanding how a trigger works is knowing why we use a trigger. This is explained in Figure III.3.1.2 when the Why Triggers button on the right of the screen is clicked. Figure III.3.1.2 - Triggers – Motivation 82 III.3.2) Transactions -> Triggers -> Triggers & Locks This example simulates two Oracle user sessions in order to show what happens when a trigger results in an error or needs to wait before it updates a record that is locked by another transaction. In the example, User system logs in and locks the Products table located in user Scott’s schema. User Scott then logs in and inserts a row in his orders table. This however, activates a trigger that will update the procucts table (locked by user system). If there is a nowait clause such as the one displayed in the Figure below, the insert will be rolled back (Trigger and Error). Figure III.3.2 - Triggers & Locks 83 IV) Security When Security is chosen from the main menu, the options in Figure IV.1 are displayed. Figure IV.1 IV.1) Security -> Referential Integrity The Referential Integrity applet displays what will happen when we try to delete a department from the Department Table (parent table) and there are rows in the Employees table referencing the Department. The result will be different depending on the clause which the Employees table was created (RESTRICT, CASCADE or SET NULL). Figure IV.1.1.1 – Referential Integrity Figure IV.1.1.2 shows a DELETE attempt with the RESTRICT clause. There is an attempt to delete department d002-Marketing (Departments window). However, Employees e0006 and e0007 (Employees window) belong to department d002 and the table was created with the RESTRICT clause (window Table Setup SQL). Therefore, the Delete attempt will fail. 84 Figure IV.1.1.2 – Referential Integrity – Delete Attempt with Restrict 85 IV.2) Security -> Security Matrix The Security Matrix shows the operations or Authorization that each Form has to each program. Although simple, such a matrix helps keep track of integrity and security. Although this is a Forms versus Tables Matrix, it could also be used to display Users/Roles versus Objects (tables , views, procedures, etc.). When we click the Introduction button, an Introduction window appears (Figure IV.1.2.1), when we click the Advantages button, the Advantages window appears (Figure IV.1.2.2) and when we choose the Quiz tab, a few questions appear that when answered correctly indicates that the student has understood the advantages of such a matrix. Figure IV.1.2.1 – Security Matrix - Introduction 86 It is important to emphasize the advantages of using a Security Matrix. Figure IV.1.2.2 displays the screen when the user clicks on the Advantages button Figure IV.1.2.2 Security Matrix -Advantages 87 Currently, the quiz is not an interactive quiz. It asks the user a question and after clicking the next button, the user sees the answer. Figure IV.1.2.3 – Security Matrix - Quiz 88 IV.3) Security -> Row Level Security Row Level Security is a simple way to implement Virtual Private databases that can done in basically any Relational Database Managenent System. Figure IV.1.3.1.1 – Row Level Security (Help) Figure IV.1.3.1.2 – Row Level Security – User Knight logged in 89 IV.4) Security -> SQL Injection The SQL injection is a tutorial form, where the user is guided through SQL injections as well as solutions (protection) from SQL injection by selecting the NEXT STEP button. There are two examples of SQL injection, a description of strategy to combat SQL injection, as well as a Quiz. Figure IV.1.4 – SQL Injection I 90 Figure IV.1.4 – SQL Injection II The figure above describes another form of SQL injection. 91 The example in Figure IV.I.4 describes how Parametrized Queries can be used to help defend against SQL injections. Figure IV.1.4 – SQL Injection – Protection (Parameterized Queries) 92 IV.5) Security -> Database Inference Database inference is another threat to the Database. This is the scenario where the user can infer unknown values from known values. For example, with census data, user is allowed to see aggregate values, but not individual ones. However, if the user knows the content of the database, he/she will select options that will return an average of a few rows. Like SQL injection, these examples are also displayed in a tutorial like form, where the user will be guided through the examples by selecting the NEXT button. Inference I – Opening Screen 93 Inference II – Opening Screen 94 Inference 3 – Opening Screen 95 IV.6) Security -> Database Auditing As can be seen in the figure below, the Database Auditing sub-module contains five different programs. All of them are in a tutorial like format where the user moves through the tutorial by selecting the Next button. The example below shows tow triggers that inserts data into the LOGON_LOGOFF table every time the user logs on or off. Data incluses username, session id , IP address, day and time the user logs in. Audit Login 96 The example below displays how a user can audit DML commands. Audit DML 97 A DDL changes the structure of your database and in most Databases, DDL statements are not frequently used. Therefore, it is common that a DBA may want to audit DDL statements. Audit DDL 98 While the rest of the examples in this sub-modules are not DBMS dependent, the Audit Command is specific of Oracle. The easiest way to break into a Database is to use a default user with a default password. Audit Default passwords is a tutorial that emphasizes the DBA to check for default users with default password. 99 100 V) HOW ADBC CAN BE USED – DATABASE DESIGN AND INTERACTIVE SQL Introduction There are many ways in which the courseware maybe used: Mode 1) teachers use it while explaining a new topic in a classroom setting; Mode 2) students use it as a reinforcement of old topics; for example, a student in an advanced database class or a graduate class reviews the software to recall what they learned in the past. Mode 3) students reference it when they are doing homework and they cannot find a solution to their problem. Mode 4) students use it to learn new topics; use of it as a stand-alone, self explanatory software. Currently, most sub-modules in the Animated Database Courseware can be used in any of the first three ways cited above. V.1) Database Design – ER Notation Pre-Requisite: There is no pre-requisite knowledge expected. Learning Objective: to be introduced to different type of relationships and be familiar with the different types of ER notations and to realize that the different types of notations contain the same information. Primary Mode of Usage: Instructor uses the courseware in class to introduce ER Diagrams. The E-R Diagram program (Page 4, Figure I.1.2) is introduced as soon as the topic of Entity Relationship Diagrams is introduced (first class that we talk about E-R). Secondary Mode of Usage: Students go back to the sub-module when they are not familiar with a specific notation and compare a notation they are familiar with to one they are not familiar with. Test of Module: Students are given an ER diagram in one notation and are asked to convert it to another notation. They are not given the exact same ER diagram as shown in this sub-module, but an exact type of an ER Diagram. Description: We say that an E-R has four components (Entities, Cardinalities, Relationships, Attributes), and after going through two or three slides that displays different ER diagrams with different notations and asking students to identify Entities, Relationships, Cardinalities in Different Systems (such as an Inventory System, Accounting System), we emphasize that there are many different notations attempting the same objective. When the sub-module is first called, we click on the Intro button so the students can see the purpose of the program. We next choose the 1-N Binary non-identifying (first option on the 101 Relationship menu) and choose the Maximum and the Minimum, Maximum from the Notation Menu. With the two notations displayed side by side in two different windows, we explain that some ER diagrams only show maximum cardinality while others show minimum and maximum cardinality, but when only one number appears in each side of the relationship, this number will always correspond to maximum. The Maximum notation helps the instructor explain the Minimum, Maximum, since the Maximum is quite intuitive to the students and the Minimum, Maximum may generate confusion. Next the instructor leaves the Minimum, Maximum notation on the screen pulls out the notation used in the Hoffer book (James Martin notation). The instructor then explains how a vertical has mark corresponds to the one (or mandatory), an oval to the zero (or optional) and the crow ‘s feet to many. As a homework assignment, we give one notation, and ask students to convert to a different notation. Usually, we provide an E-R Diagram in the Minimum, Maximum notation and ask students to turn in a representation in each of the other notations. Example: Convert the following ER Diagram notation into the IDEF1X and the Hoffer (James Martin) notation: Branch 0..1 contains 1..N Project We believe students should return frequently to this module when they forget a notation or want to compare different structures. 102 V.2) Database Design –> Converting Scenarios to E-R Pre-Requisite: The pre-requisite to this sub-module is to have been introduced to an ER diagram and the different type of relationships. In other words, to have been exposed to the relationships described in the Sub-module Database Design -> ER Diagram (1-N binary non-identifying, 1-N Binary identifying, N-N binary, 1-1 Binary, 1-N Unary, supertype/subtype). Learning Objective: To be able to identify an appropriate ER diagram model from a scenario (problem description, Form or Report). Primary Mode of Usage: Students use the module on their own for review, and try to identify the correct ER Diagram from the Scenario given. Secondary Mode of Usage: Instructor introduces the first example in class. Test of Module: Students are given several scenarios and must identify an appropriate ER diagram. Students are also given an ER Diagram and must identify a corresponding scenario. Description: While the first sub-module (ER Notations) is used primarily by the instructor to introduce ER Diagrams, this sub-module is used mainly by the student. The instructor will present the sub-module and will show the first exercise in class. The instructor will show the scenario, Employee works on Project, and ask the class which ER diagram corresponds to the scenario described. The instructor will click on the show all tab for the students to see all four possible answers. The student will then review, outside of class, the other scenarios - automobile parts contain automobile parts, medical procedures, car dealer, orders, phone, suppliers, university and prescriptions. Students are given both homework examples and test examples of questions similar to the ones depicted in this sub-module. Currently we are also elaborating tests build into the software. On both homework assignments and tests, students are also requested to identify the reverse engineering of the problem that they are given in this sub-module, such as displayed in the example below. Students are given an ER diagram and they are asked to identify the scenario that it corresponds to. 103 Given the E-R diagrams, Circle the letter that corresponds to the best Problem Specification Employee 0:N 1:N manages a) An employee can manage many employees, but is only managed by one employee. b) An employee can manage many employees, but some employees do not manage any employees at all. An employee has at least one and at most one manager. c) An employee can be managed by at most one employee. An employee also manages one employee at most. d) An employee may not manage any employees or may manage many employees. An employee is managed by at least one employee. Some employees are managed by more than one employee. 104 V.3) Database Design -> Converting E-R Diagrams to Tables Pre-Requisite: The pre-requisite to this sub-module is to have been introduced to an ER diagram and the different types of relationships. In other words, to have been exposed to the relationships described in the sub-module Database Design -> ER Diagram (1-N binary non-identifying, 1-N Binary identifying, N-N binary, 1-1 Binary, 1-N Unary, supertype/subtype). Although this is the minimum pre-requisite, students typically work on this sub-module after having completed the exercises in the sub-module of Scenarios to ER Diagrams as well as the sub-module of Constructing ER Diagrams. Learning Objective: To produce appropriate tables and attributes including appropriate foreign keys, given an ER diagram. Primary Mode of Usage: Students review the courseware to assist in completing homework assignments and preparing for tests. Secondary Mode of Usage: Instructor introduces the first example in class. Test of Module: Students are given an ER diagram and must convert it into tables. Description: The first example: Converting 1:N Binary Relationship (Figure 1.2.3), is presented in class when we introduce Converting E-R to tables, and it is also displayed when we talk about normalization. We show the correct (default) answer, option a (Figure I.2.5) and the most common wrong answer, option c (Figure I.2.6) and state why - option c is not in 1NF because Dept_id does not determine Emp_ID. We point to the highlighted rows. 105 V.4) Database Design -> Normalization -> Tutorial Pre-Requisite: There is no pre-requisite knowledge Learning Objective: To understand what is a functional dependency understand what is a Functional Dependency (FD), First Normal Form (1NF), Second Normal Form (2NF) and Third Normal Form (3NF) as well as to be able to visualize data and identify violations of 1NF, 2NF and 3NF as well as identifying possible Functional Dependencies. Primary Mode of Usage: Instructor uses the courseware in class to introduce Normalization. Secondary Mode of Usage: Students should also be able to learn the concepts of normalization by themselves. Students go back to the tutorial at any time and be able to follow it without explanations from the instructor. Test of Module: Students are tested on this program when they use the other normalization programs. Furthermore, students are given exercises for homework and tests where they identify functional dependencies as well as normalize a table given functional dependencies. Description: The introductory tutorial on normalization is totally system driven as opposed to the other programs of this sub-module. The instructor goes through this sub-module as soon as they introduce normalization. The instructor explains that to Design a Database we must first obtain the user requirements (through Interview, Questionnaire, JAD, Observation, Research, etc.), and that once we obtain the user requirements there are two alternative approaches (and not mutually exclusive) to designing a database: Define Functional Dependencies and then Normalize AND/OR Draw and ER diagram and then convert to tables. Once this explanation is done, the instructor will start the Normalization tutorial and use it much like powerpoint slides. 106 Database Design -> Normalization -> Identify Functional Dependencies (FD) - under construction Pre-Requisite: Completed the Tutorial on Normalilzation Learning Objective: To gain skill in identifying Functional Dependencies and possible functional dependencies by visualizing data. Primary Mode of Usage: Students identify the functional dependencies as homework assignments. Secondary Mode of Usage: Instructor may complete one example in class to show how the sub-module works. Test of Module: Students are given exercises for homework and in exams where they identify possible functional dependencies based on Data. Description: These exercises should be done right after the tutorial on normalization is completed. Ideally, the instructor should do one exercise with the class and let the other exercises be done at home. However, if time doesn’t allow or with a graduate class, the instructor may request that they all be done at home. 107 Database Design -> Normalization -> Converting One Big Table and FD to 3NF Pre-Requisite: Completed the Tutorial on Normalilzation Learning Objective: To gain skill on converting tables to 3NF. Primary Mode of Usage: Students identify the functional dependencies as homework assignments. Secondary Mode of Usage: Instructor may complete one example in class to show how the sub-module works. Test of Module: Students are given exercises for homework and in exams where they convert tables to 3NF Description: Although students can go straight to these exercises once the tutorial on normalization is completed, it is recommended that students complete the exercise on Fuctional Dependencies first. Ideally, the instructor should do one exercise with the class and let the other exercises be done at home. However, if time doesn’t allow or with a graduate class, the instructor may request that they all be done at home. In this sub-module, Like the Converting E-R Diagrams to tables module, we plan to include an option for the student to see update anomalies once they design the correct solution. Below is an example (Stolen Car Database). We are currently implementing this exercise to be included in this sub-module. We will also develop an exercise in the anomaly sub-module that involve updating a correct solution as well as an incorrect solution of the Stolen car database example. STOLEN CAR DATABASE Normalization. Put the database in 3NF by breaking up this one big table into several tables Vid -> vtype Suspect_id -> Suspect_Name own_id -> own_name Vid -> own_id STOLEN_CARS Vid vtype owner_id owner_name Suspect_id 207 Escort 17 Jack 10 205 Quest 22 Mary 10 336 Neon 17 Jack 14 208 Camry 15 Sue 18 207 Escort 17 Jack 19 108 Suspect_Name John John Joe James Henry V.5) SQL -> Interactive SQL This sub-module is used in intensively in three ways: 1) teachers to use it while explaining a new topic in a classroom setting; 2) students use it as a reinforcements of old topics; for example, a student in and advanced database class or a graduate class reviews the software to recall what they learned in the past. 3) students reference it when they are doing homework and they can’t find a solution to their problem. This third way is used intensively by students because for each of our SQL assignments at http://science.kennesaw.edu/~mguimara/3310/spring08/hw2.htm and at http://science.kennesaw.edu/~mguimara/3310/spring08/hw3.htm, we describe in parenthesis, where in the Database Courseware that you can find an equivalent solution. For example: 6) List name and city for all customers (Interactive SQL -> Constructing SQL Queries-Basic -> Projection). During a closed lab, we saw students who had never been exposed to sql use the Database courseware efficiently to find these solution. 109 V.5.1) SQL -> Interactive SQL -> DDL and DML Pre-Requisite: No pre-requisite Learning Objective: To gain an overview of the popular DDL and DML commands Primary Mode of Usage: Instructor will use it in class to introduce DDL and DML Secondary Mode of Usage: Students can use it at home as reinforcement as well as use it without ever being introduced to the topic. Students also go back to these animations when they are doing their lab exercises (see page 109). Test of Module: Students are assigned lab exercises and exams where they need to show this knowledge. Description: For the typical student in an introductory class, it is best to be used with the instructor guiding the students. For students in a graduate class or in a second class, this sub-module will be used by the student at home without any help or support from the instructor. In the very first lecture about SQL, we say that SQL statements can be divided into two major categories: - Data definition language (DDL) statements that define the structure of the tables, creating tables, relationships, and other structures. - Data manipulation language (DML) statements, that are used for querying and modifying statements. We then say that there are three basic DDL statements (CREATE, ALTER, DROP) and four basic DML statements (INSERT, UPDATE, SELECT and DELETE). We then launch the SQL -> DDL and DML program (see Figure II.1.2). 110 V.5.2) SQL -> Interactive SQL -> Queries Pre-Requisite: Although no pre-requisite is necessary, it is best that the instructor gives a small overview of Relational Algebra or SQL Learning Objective: To gain an overview of the SQL commands that implement CODD’s Relational Algebra primitives. Primary Mode of Usage: Instructor will use it in class to introduce one or two animations of this group and the students will use the other ones at home. Secondary Mode of Usage: Students can use it at home as reinforcement. Students also go back to these animations when they are doing their lab exercises (see page 109). Test of Module: Students are assigned lab exercises and exams where they need to show this knowledge. Description: For students of introductory classes, we first introduce Relational Algebra by describing an example of each of CODD’s original Relational Algebra primitives. We use the chart located at http://science.kennesaw.edu/~mguimara/3310/RA_SQL.htm that compares relational algebra, SQL and pseudo-code side by side and briefly describe each of the operations. Few students will really benefit from these animations if they have never used SQL before and they have not been presented to at least one introductory lesson. As for the Advanced queries, we go over each one of them in the classroom as described in the Interactive SQL session of this user guide. We spend more time on the GROUP BY, HAVING and OUTER JOIN. The FUNCTION, DISTINT and ORDER BY are easier to grasp for the students. 111 V.5.3) SQL -> Interactive SQL -> Code Pre-Requisite: Although no pre-requisite is necessary, it is best that the instructor gives a small overview of Relational Algebra or SQL and that the students have already executed the Interactive SQL > Basic animations. Learning Objective: To gain an overview of the SQL commands that implement CODD’s Relational Algebra primitives and to have an idea of how the Projection, Restriction and Join are done internally. Primary Mode of Usage: Instructor will use it in class to introduce one or two animations of this group and the students will use the other ones at home. Secondary Mode of Usage: Students can use it at home as reinforcement. Students also go back to these animations when they are doing their lab exercises (see page 109). Test of Module: Students are assigned lab exercises and exams where they need to show this knowledge. Description: In these exercises, we go over in class the Restriction, Projection and Join in class because they are the three most used relational algebra operations. We leave the others for homework, but we tell them they will not be tested on the procedural code of the other relational algebra operations (union, intersection, minus and division) and they can optionally review it just to help them understand the SQL code, but it is not necessary. We go into more detail of the pseudo-code only for the first operation four relational algebra operations (Projection, Restriction, Multiplication or Cartesian Product and Join). We also show the animation of the first four operations. As for the union, minus and intersect, students have trouble understanding the practical advantage (since it requires two tables with exactly the same column. We explain that : 1) The operation is not with the tables, but what is projected with from each select 2) These operations can be useful when you import the same tables from two different databases. Customers that did not order a certain product. Students try it with the not = and we explain that it is wrong. The not = retrieves customers that at least one order was not of a certain products. Then we explain the solution with a MINUS. 112 V.5.4) SQL -> Interactive SQL -> Join and Minus (Animating SQL with Relational Algebra) Pre-Requisite: Having completed the Interactive SQL -> Basic and/or the Interactive SQL -> Code animations. Learning Objective: To gain an overview of the SQL commands that implement CODD’s Relational Algebra primitives. Primary Mode of Usage: Instructor will use it in class to introduce both of these animations in class. Secondary Mode of Usage: Students can use it at home as reinforcement. Students also go back to these animations when they are doing their lab exercises (see page 109). Test of Module: Students are assigned lab exercises and exams where they need to show this knowledge. Description: The first example (Join) is used multiple times in class. The first time it is used is in the second class of teaching SQL. Students have already been presented to one or more animations of Interactive SQL -> Basic and/or the Interactive SQL -> Code in the first class. Then they are given time to absorb the introductory animations at home. In the second class, the instructor asks what are the three most important/common relational algebra operations. When they answer, we emphasize that a typical SQL query containing the three most common relational algebra operations (restriction, projection and join) and show the Animation with the Join. We show the EXISTS window only after explaining the Relational Algebra, the solution without a sub-select, and the solution with the IN clause. The Not Exists window is shown just before they go to the lab (typically at the end of the second class on SQL or beginning of the third class). 113 V.5.5) SQL -> Interactive SQL -> Misconceptions These animations are used by students as reference when they are doing homework and their solution is one of the misconception. Pre-Requisite: Having completed the Interactive SQL -> Basic and/or the Interactive SQL -> Code animations. Learning Objective: To gain an overview of the SQL commands that implement CODD’s Relational Algebra primitives. Primary Mode of Usage: Instructor will use it in class to introduce both of these animations in class. Secondary Mode of Usage: Students can use it at home as reinforcement. Students also go back to these animations when they are doing their lab exercises (see page 109). Test of Module: Students are assigned lab exercises and exams where they need to show this knowledge. Description: The instructor typically goes over these animations at two moments. The first is in the lab as soon as the students are implementing the misconceptions. The instructor then displays the wrong solution and asks the class to correct it. A few students usually answer it and then the rest of the students execute the animation. The instructor may also display these animations right after the lab exercises have been graded or right after the exams have been handed out to explain the misconception that the student performed. Like all other animations, these animations are also referenced by the students while they are doing their lab exercises (see p. 109). V.5.6) SQL -> More SQL (visual basic) We go over the a code to display all pair of employees in the same city. We then give them an exercise to solve that requires a recursive join (join with one table). The recursive (unary operations) are currently being converted to java. 114 V.6) SQL -> Embedded SQL Teachers use this animation while explaining how to access SQL from within a program. When we teach SQL from within a program, we start off with this animation. Currently the code is lacking explanations for most students to benefit from using these two programs alone. In this animation we emphasize: 1) Benefits of variable declarion with %TYPE (data independence; 2) SELECT INTO Statement ; 3) DECLARE, OPEN AND FETCH Cursor 4) Corresponding code to DECLARE, OPEN and FETCH with JAVA. V.7) SQL -> Stored Procedures & Functions Like the Embedded SQL Demo, the Stored Procedures and Functions programs are introduced as soon as we introduce Stored Procedures and Functions. We select each of the buttons in the classroom and go over what is happening. V.8) Transactions -> Concurrency For the concurrency animations, it is necessary to give a small explanation of concurrency before the students use the program. We emphasize that there is no ideal concurrency solutions and the animations illustrates some problems that can occur as well some mechanisms that can be used to deal with these problems. We also need to explain the concept of Shared Lock, Exclusive Lock, Unit of Locking and Implicit Locking. Also, although the three animations are fairly easy to use, it is important to stress in class that they have a slightly different structure. Concurrency – Simple Example has two buttons, one to control each process. Concurrency – Database Example has one button that controls both concurrent processes. Concurrency Error Handling has one different code windows that are doing the same task, while the first two examples have two different concurrent processes. Once the Concurrency examples are explained in class, it is easier for them to use it at home. We plan to include a little tutorial so that this module can also be used in a stand-alone mode. V.9) Transactions -> Recovery As soon as we start explaining Recovery, we launch the recovery programs. These two programs, the Least Recently Used algorithm and the Database Recovery are nearly self explanatory, but students will benefit from going over it in class. 115 V.10) Transactions -> Triggers The introductory program on triggers is used as soon as we introduce triggers . Currently, the Introduction program doesn’t show the actual tables being updated when the trigger is executed (we are working on this update). Therefore, this part is now done manually. Also, we explain the :new and :old command. We ask them to guess which table the :new refers to. We then give an example in class with the :new and :old. We explain that the word :new and :old, may be substituted for a different name (such as :newvalue and :oldvalue, or may not be preceded by a column), but every DBMS that supports triggers need two special reserve words that perform the same task as the :new and :old do. The Triggers and Locks program is a program that could be in triggers just as well as in locks. This program simulates an Oracle user session. This program is self explanatory once the student has some knowledge of triggers. Therefore, it is usually assigned for the student to do at home and we emphasize that they will be tested on it. V.11) Security -> Referential Integrity The Referential Integrity program is a useful tool for the students when it is explained in class or through a stand-alone. For graduate class, we just tell them that there are two drop down menus in the Table Setup Window and depending on what is set in this window, the results from executing the SQL window will be different. For an undergraduate class, we go over the animation making a DELETE and an UPDATE command with each of the possibilities (CASCADE, RESTRICT, SET, NULL). We also mention that Microsoft uses the clause NO ACTION instead of RESTRICT. V.12) Security -> Security Matrix This example can be used by students to learn by themselves. Although one may question if it is really necessary to have an explanation to explain such a simple concept matrix, when we assigned an Accessibility matrix as part of their project deliverables, few groups understood and we had to spend some class time on it. When we asked them about the benefits of the matrix in a test, few students were able to answer it prior to the construction of this example. 116 V.13) Security -> Row Level Security Row Level Security as well as Virtual Private Database is explained in our class prior to the students doing looking at an animations. The instructor also shows this animation in class. Students from the advanced database class as well as the our graduate database class also do a lab where they implement Row Level Security. V.14) Security -> SQL Injection SQL injection is also explained in class. Then they do this tutorial at home. This tutorial has not been used by the instructors in class. VI) Enhancements being Performed on ADbC Enhancements currently being performed include: 1) Standardization of Normalization. A few new Normalization examples 2) Denormalization 3) Store students’ answers and have an option for the student to submit their answers to the faculty. 4) Embedded SQL Module – make it more readable. VII) Other Database Courswewares WINRDBI - http://www.eas.asu.edu/~winrdbi/ - SQL, Relational Algebra, Relational Calculus ASU’s second database Class - http://www.eas.asu.edu/~advdb/ - Procedures, Triggers, OO, etc. http://www.w3schools.com/ - link to SQL in the panel on the left side SQL tutorial - http://www.1keydata.com/sql/sql.html 117