Download Manual - Animated DataBase Courseware

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