Dr. E. F. Codds 12 rules for defining a fully relational database1) Foundation Rule A relational database management system must manage its stored data using only its relational capabilities.2) Information Rule All information in the database should be represented in one and only one way - as values in a table.3) Guaranteed Access Rule Each and every datum (atomic value) is guaranteed to be logically accessible by resorting to a combination of table name, primary key value and column name.
(4) Systematic Treatment of Null Values Null values (distinct from empty character string or a string of blank characters and distinct from zero or any other number) are supported in the fully relational DBMS for representing missing information in a systematic way, independent of data type.(5) Dynamic On-line Catalog Based on the Relational Model The database description is represented at the logical level in the same way as ordinary data, so authorized users can apply the same relational language to its interrogation as they apply to regular data.(6) Comprehensive Data Sublanguage Rule A relational system may support several languages and various modes of terminal use. However, there must be at least one language whose statements are expressible, per some well-defined syntax, as character strings and whose ability to support all of the following is comprehensible: data definition view definition data manipulation (interactive and by program) integrity constraints authorization transaction boundaries (begin, commit, and rollback).
(7) View Updating Rule All views that are theoretically updateable are also updateable bythe system.(8)High-level Insert, Update, and Delete The capability of handling a base relation or a derived relation asa single operand applies nor only to the retrieval of data but also tothe insertion, update, and deletion of data.(9)Physical Data IndependenceApplication programs and terminal activities remain logicallyunimpaired whenever any changes are made in either storagerepresentation or access methods.
(10)Logical Data Independence Application programs and terminal activities remain logically unimpairedwhen information preserving changes of any kind that theoretically permitunimpairment are made to the base tables.(11) Integrity Independence Integrity constraints specific to a particular relational database must bedefinable in the relational data sublanguage and storable in the catalog, not inthe application programs.(12) Distribution Independence The data manipulation sublanguage of a relational DBMS must enableapplication programs and terminal activities to remain logically unimpairedwhether and whenever data are physically centralized or distributed.(13) Non subversion Rule If a relational system has or supports a low-level (single-record-at-a-time)language, that low-level language cannot be used to subvert or bypass theintegrity rules or constraints expressed in the higher-level (multiple-records-at-a-time) relational language.
Anchored Data Type An anchored variable is a local variable or parameter with a data type that is an anchored data type. Anchored variables are supported in the following contexts: SQL procedures In SQL procedures, parameters and local variables can be specified to be of an anchored data type. Compiled SQL functions SQL functions created using the CREATE FUNCTION statement that specify the BEGIN clause instead of the BEGIN ATOMIC clause can include parameter or local variable specification that are of the anchored data type. Module variables Anchored variables can be specified as published or unpublished variables defined within a module. Global variables Global variables can be created of the anchored data type. Anchored variables are declared using the DECLARE statement.
Example: Variable declarations of anchored data types Examples of anchored data type declarations can be useful references when declaring variables. The following is an example of a declaration of a variable named v1 that has the same data type as the column name in table staff: DECLARE v1 ANCHOR DATA TYPE TO staff.name;
The following is an example of a CREATE TYPE statement that defines a type named empRow1 that is anchored to a row defined in a table named employee: CREATE TYPE empRow1 AS ROW ANCHOR DATA TYPE TO ROW OF employee; For variables declared of type empRow1, the field names are the same as the table column names. If the data type of the column name is VARCHAR(128), then the variable v1 will also be of data type VARCHAR(128).
CREATE TABLE tab1(col1 INT, col2 CHAR)@INSERT INTO tab1 VALUES (1,2)@INSERT INTO tab1 VALUES (3,4)@CREATE TABLE tab2 (col1a INT, col2a CHAR)@ CREATE PROCEDURE p1()BEGIN DECLARE var1 ANCHOR tab1.col1; SELECT col1 INTO var1 FROM tab1 WHERE col2 = 2;INSERT INTO tab2 VALUES (var1, a); END@CALL p1()@
When the procedure p1 is called, the value of the column col1 for a particular row is selected into the variable var1 of the same type. The following CLP script includes an example of a function that demonstrates the use of an anchored data type for a parameter to a function:-- Create a table with multiple columnsCREATE TABLE tt1 (c1 VARCHAR(18), c2 CHAR(8), c3 INT, c4 FLOAT) @INSERT INTO tt1 VALUES (aaabbb, ab, 1, 1.1) @ INSERT INTO tt1 VALUES (cccddd, cd, 2, 2.2) @ SELECT c1, c2, c3, c4 FROM tt1 @ --
Creation of the function CREATE FUNCTION func_a(p1 ANCHOR tt1.c3) RETURNS INT BEGIN RETURN p1 + 1; END @ -- Invocation of the function SELECT c1, c2 FROM tt1 WHERE c3 = func_a(2) @ -- Another invocation of the function SELECT c1, c2 FROM tt1 WHERE c3 = func_a(1) @ DROP FUNCTION func_a @ DROP TABLE tt1 @ When the function func_a is invoked, the function performs a basic operation using the value of the anchored data type parameter.
Ordinary array data type An ordinary array data type is a structure that contains an ordered collection of data elements in which each element can be referenced by its ordinal position in the collection. If N is the cardinality (number of elements) in an array, the ordinal position associated with each element, called the index, is an integer value greater than or equal to 1 and less than or equal to N. All elements in an array have the same data type.
Features of the array data type The many features of the array data type make it ideal for use in SQL PL logic. Restrictions on the array data type It is important to note the restrictions on the array data type before you use it or when troubleshooting problems with their declaration or use. Use of the array data type in dynamic compound statements is not supported. Use of the ARRAY_AGG function outside of SQL procedures is not supported. Use of the UNNEST function outside of SQL procedures is not supported . Use of parameters of the array data type in external procedures other than Java™ procedures is not supported. The casting of an array to any data type other than a user-defined arrays data type is not supported. Array variables Array variables are variables based on user-defined array data types. Array variables can be declared, assigned a value, set to another value, or passed as a parameter to and from SQL procedures.
Creating array variables To create array variables you must first create the array type and then declare the local array variable or create the global array variable. CREATE TYPE id_Phone AS VARCHAR(20) ARRAY;
Trimming the array (TRIM_ARRAY function) Trimming an array is a task that you would perform using the TRIM_ARRAY function when you want to remove unnecessary array elements from the end of an array. Deleting an array element (ARRAY_DELETE) Deleting an element permanently from an array can be done using the ARRAY_DELETE function. Determining if an array element exists Determining if an array element exists and has a value is a task that can be done using the ARRAY_EXISTS function. Array support in SQL procedures SQL procedures support parameters and variables of array types. Arrays are a convenient way of passing transient collections of data between an application and a stored procedure or between two stored procedures.
Features of the row data type The features of the row data type make it useful for simplifying SQL PL code. The row data type is supported for use with the SQL Procedural language only. It is a structure composed of multiple fields each with their own name and data type that can be used to store the column values of a row in a result set or other similarly formatted data. This data type can be used to:Simplify the coding of logic within SQL Procedural Language applications. For example, database applications process records one at a time and require parameters and variables to temporarily store records. A single row data type can replace the multiple parameters and variables required to otherwise process and store the record values. This greatly simplifies the ability to pass row values as parameters within applications and routines. Facilitate the porting to DB2® SQL PL of code written in other procedural SQL languages that support a similar data type. Reference row data in data-change statements and queries including: INSERT statement, FETCH statement, VALUES INTO statement and SELECT INTO statement. Row data types must be created using the CREATE TYPE (ROW) statement. Once created, variables of the defined data type can be declared within SQL PL contexts using the DECLARE statements. These variables can then be used to store values of the row type. Row field values can be explicitly assigned and referenced using single-dot, "." notation.
Restrictions on the row data type It is important to note the restrictions on the use of the row data type before using it or when troubleshooting an error that might be related to its use. The following restrictions apply to the row data type:The maximum number of fields supported in a row data type is 1012. The row data type cannot be passed as an input parameter value to procedures and functions from the CLP. The row data type cannot be passed as an input-output or output parameter value from procedures and functions to the CLP. Row data type variables cannot be directly compared. To compare row type variables, each field can be compared. The following data types are not supported for row fields: XML data type LONG VARCHAR LONG VARGRAPHIC structured data types row data types array data types Global variables of type row that contain one or more fields of type LOB are not supported. Use of the CAST function to cast a parameter value to a row data type is not supported.
Row variables Row variables are variables based on user-defined row data types. Row variables can be declared, assigned a value, set to another value, or passed as a parameter to and from SQL procedures. Row variables inherit the properties of the row data types upon which they are based. Row variables are used to hold a row of data from within a result set or can be assigned other tuple- format data. Row variables can be declared within SQL procedures using the DECLARE statement.
Creating a row data type To create a row data type within a database, you must successfully execute the CREATE TYPE (ROW) statement from any DB2® interface that supports the execution of SQL statements. Formulate a CREATE TYPE (ROW) statement: Specify a name for the type. Specify the row field definition for the row by specifying a name and data type for each field in the row. The following is an example of how to create a row data type that can be associated with result sets with the same format as the empRow row data type: CREATE TYPE empRow AS ROW (name VARCHAR(128), id VARCHAR(8)); Execute the CREATE TYPE statement from a supported DB2 interface. If the CREATE TYPE statement executes successfully, the row data type is created in the database. If the statement does not execute successfully, verify the syntax of the statement and verify that the data type does not already exist.
Declaring local variables of type row Formulate a declare statement: Specify a name for the variable. Specify the row data type that will define the variable. The specified row data type must be already defined in the database. The following is an example of how to formulate a DECLARE statement that defines a row variable of type empRow: DECLARE r1 emp Row; Execute the DECLARE statement within a supported context.
Cursor typesCursor variables Cursor variables are cursors based on predefined cursor data type. Cursor variables can be un- initialized, initialized, assigned a value, set to another value, or passed as a parameter from SQL procedures. Cursor variables inherit the properties of the cursor data types upon which they are based. Cursor variables can be strongly-typed or weakly-typed. Cursor variables hold a reference to the context of the cursor defined by the cursor data type. Cursor variables can be declared within SQL procedures using the DECLARE statement.
Cursor predicates Cursor predicates are SQL keywords that can be used to determine the state of a cursor defined within the current scope. They provide a means for easily referencing whether a cursor is open, closed or if there are rows associated with the cursor. 1. IS OPEN This predicate can be used to determine if the cursor is in an open state. This can be a useful predicate in cases where cursors are passed as parameters to functions and procedures. Before attempting to open the cursor, this predicate can be used to determine if the cursor is already open.
IS NOT OPEN This predicate can be used to determine if the cursor is closed. Its value is the logical inverse of IS OPEN. This predicate can be useful to determine whether a cursor is closed before attempting to actually close the cursor.
IS FOUND This predicate can be used to determine if the cursor contains rows after the execution of a FETCH statement. If the last FETCH statement executed was successful, the IS FOUND predicate value is true. If the last FETCH statement executed resulted in a condition where rows were not found, the result is false
BEGIN DECLARE C1 cursor; DECLARE lvarInt INT; SET count = -1; SET c1 = CURSOR FOR SELECT c1 FROM t1; IF (c1 IS NOT OPEN) THEN OPEN c1; ELSE set count = -2; END IF; set count = 0; IF (c1 IS OPEN) THEN FETCH c1 into lvarInt; WHILE (c1 IS FOUND) DO SET count = count + 1; FETCH c1 INTO lvarInt; END WHILE; ELSE SET count = 0; END IF; END@ CALL p()@
Creating cursor variables To create cursor variables you must first create a cursor type and then create a cursor variable based on the type. The following topics show you how to do these tasks: