Advanced Database CS-426 Week 2 – Logic Query Languages, Object Model

Object Models An object typically has two components: state (value) and behavior (operations). One goal of an ODMS (Object Data Management System) is to maintain a direct correspondence between real-world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon. define type EMPLOYEE tuple ( Fname: string ; Minit: char ; Lname: string ; Ssn: string ; Birth_date: DATE; Address: string ; Sex: char ; Salary: float ; Supervisor: EMPLOYEE; Dept: DEPARTMENT;);

Object Models define type DATE tuple ( Year: integer ; Month: integer ; Day: integer ; );

Object Data Modeling Group (ODMG) The ODMG object model is the data model upon which the object definition language (ODL) and object query language (OQL) are based. It is meant to provide a standard data model for object databases, just as SQL describes a standard data model for relational databases. It also provides a standard terminology in a field where the same terms were sometimes used to describe different concepts.

Object Definition Language (ODL) The ODL is designed to support the semantic constructs of the ODMG object model and is independent of any particular programming language. Its main use is to create object specifications—that is, classes and interfaces. Hence, ODL is not a full programming language. A user can specify a database schema in ODL independently of any programming language, and then use the specific language bindings to specify how ODL constructs can be mapped to constructs in specific programming languages, such as C++, Smalltalk, and Java.

Object Query Language (OQL) The object query language OQL is the query language proposed for the ODMG object model. It is designed to work closely with the programming languages for which an ODMG binding is defined, such as C++, Smalltalk, and Java. Hence, an OQL query embedded into one of these programming languages can return objects that match the type system of that language. Additionally, the implementations of class operations in an ODMG schema can have their code written in these programming languages. The OQL syntax for queries is similar to the syntax of the relational standard query language SQL, with additional features for ODMG concepts, such as object identity, complex objects, operations, inheritance, polymorphism, and relationships.

Advanced SQL 1. Accessing SQL From a Programming Language There are two approaches to accessing SQL from a general-purpose programming language: Dynamic SQL : A general-purpose program can connect to and communicate with a database server using a collection of functions (for procedural languages)or methods (for object-oriented languages). Dynamic SQL allows the program to construct an SQL query as a character string at runtime, submit the query, and then retrieve the result into program variables a tuple at a time. The dynamic SQL component of SQL allows programs to construct and submit SQL queries at runtime.

Advanced SQL Embedded SQL : Like dynamic SQL, embedded SQL provides a means by which a program can interact with a database server. However, under embedded SQL, the SQL statements are identified at compile time using a preprocessor. The preprocessor submits the SQL statements to the database system for precompilation and optimization; then it replaces the SQL statements in the application program with appropriate code and function calls before invoking the programming-language compiler.

2. Functions and Procedures Procedures and functions allow “business logic” to be stored in the database, and executed from SQL statements. Example: create function dept count(dept name varchar(20) ) returns integer begin declare d count integer ; select count (*) into d count from instructor where instructor.dept name= dept name return d count; end

3. Triggers A trigger is a statement that the system executes automatically as a side effect of a modification to the database. To design a trigger mechanism, we must meet two requirements: 1. Specify when a trigger is to be executed. This is broken up into an event that causes the trigger to be checked and a condition that must be satisfied for trigger execution to proceed. 2. Specify the actions to be taken when the trigger executes.