repaso y ampliación del paradigma de la orientación a objeto en sql:1999 capacidades y...

Repaso y Ampliación del Paradigma de la Orientación a

Objeto en SQL:1999 Capacidades y Limitaciones

1.2 Soporte a la Orientación a objeto 1.2.1 Tipos, abstracción y clases 1.2.1.1 Creación de tipos (CREATE TYPE) 1.2.1.2 Atributos 1.2.1.3 Métodos 1.2.1.3.1 Métodos de Instancia 1.2.1.3.2 Métodos estáticos 1.2.1.3.3 Constructores 1.2.1.3.4 Creación de métodos (CREATE METHOD) 1.2.1.4 Modificación de tipos (ALTER TYPE) 1.2.1.4.1 Agregar un atributo 1.2.1.4.2 Eliminar un atributo 1.2.1.4.3 Agregar un método 1.2.1.4.4 Eliminar un método 1.2.1.5 Eliminación de tipos (DROP TYPE) 1.2.1.6 Comparación de instancias 1.2.1.6.1 Eliminación de funciones de comparación 1.2.1.7 Conversión de UDT (CAST definidos por el usuario) 1.2.1.7.1 Eliminación de CAST definidos por el usuario

1.2 Soporte a la Orientación a objeto

Para analizar el soporte de la orientación a objeto en SQL:1999, nos basaremos en los conceptos básicos de la orientación a objetos y en los requerimientos para bases de datos orientadas a objetos. La sintaxis de SQL: 1999 relacionada con la orientación a objeto, se encuentra en el apéndice A.

1.2.1 Tipos, abstracción y clases

El estándar unifica estos conceptos bajo el nombre de tipo estructurado, que es otro tipo de UDT.

Un tipo estructurado encapsula atributos y métodos en una única entidad lógica, pero físicamente separados.

Los atributos de un objeto persistente se almacenan en una tabla, los métodos, junto con los demás procedimientos almacenados. Cabe destacar que esta separación será transparente al usuario.

Un tipo estructurado pasará a ser uno más del sistema, pudiendo ser utilizado del mismo modo que un tipo primitivo.

1.2.1.1 Creación de tiposPara crear un tipo estructurado se utiliza el predicado CREATE TYPE, donde especificamos una lista de atributos, y opcionalmente, una lista de métodos. Por ejemplo, consideremos un tipo Punto, con los atributo: X, Y; y con los métodos: moverA(x,y), distanciaA (p), crear(x,y); su implementación sería:

CREATE TYPE punto AS ( X INTEGER, Y INTEGER ) INSTANTIABLE NOT FINAL METHOD moverA(x INTEGER, y INTEGER), METHOD distanciaA(p Punto) RETURNS FLOAT, STATIC METHOD crear(x INTEGER, y INTEGER) RETURNS punto

La cláusula INSTANTIABLE, permite crear instancias del tipo directamente. El valor por defecto es INSTANTIABLE.Para implementar clases abstractas indicamos NOT INSTANTIABLE. La cláusula NOT FINAL, permite que el tipo sea utilizado como supertipo de otro (herencia y polimorfismo). Esta cláusula no es opcional.

tipo estructurado….

Todo tipo estructurado tiene asociado un correspondiente tipo de referencia. Este tipo almacena una secuencia de bytes, que indica el lugar donde está almacenado un objeto de ese tipo. El número de bytes es dependiente de la implementación del estándar.

Un tipo de referencia puede ser utilizado en los mismos lugares que un tipo estructurado. Se identifican con la palabra reservada REF, seguida por el nombre del tipo entre paréntesis.

Por ejemplo, consideremos un tipo linea_recta, definido de la siguiente manera:

CREATE TYPE linea_recta AS ( a REF(punto), b REF(punto))INSTANTIABLE NOT FINAL

con este tipo de datos, podemos crear redes de objetos. Por ejemplo, podemos crear una lista enlazada, un árbol binario, etc.

Al definir un tipo estructurado, podemos indicar la manera en que el sistema construirá sus referencias. Para eso, debemos escoger entre tres formas de representación, definidas por la cláusula opcional <reference type specification>, que es indicada a continuación de la cláusula <finality>. Las 3 formas de representación son:• USER GENERATED, la referencia se basa en un tipo primitivo, cuyo valor será proporcionado por el usuario.La sintaxis es: REF USING <predefined type>. Ejemplo: CREATE TYPE persona AS ( Dni CHAR(12), Nombre CHAR(40) )INSTANTIABLE NOT FINAL REF USING INTEGER

• SYSTEM GENERATED, la referencia es generada automáticamente por el sistema. Este es el valor por defecto.La sintaxis es: REF IS SYSTEM GENERATED Ejemplo: CREATE TYPE persona AS ( Dni CHAR(12), Nombre CHAR(40) )INSTANTIABLE NOT FINAL REF IS SYSTEM GENERATED

• DERIVED, La referencia se basa en uno o más atributos. Es semejante a una clave primaria.

La sintaxis es: REF FROM <list of attributes> Ejemplo:

CREATE TYPE persona AS ( Dni CHAR(12),Nombre CHAR(40) )INSTANTIABLE NOT FINAL REF FROM (Dni)

Una limitación importante de los tipos de referencia, es que sólo pueden almacenar direcciones de objetos persistentes.

1.2.1.2 AtributosUn tipo estructurado puede tener uno o más atributos, cada uno con un nombre, un tipo de dato, y opcionalmente, un valor por defecto (con DEFAULT).

• No podemos definir dos atributos del mismo nombre, para un mismo tipo estructurado.

• El tipo de dato del atributo, puede ser cualquiera de SQL, incluyendo un UDT.

Ejemplo, si quisiéramos crear un tipo Direccion con los atributos calle, numero, ciudad y provincia, sería:

CREATE TYPE Direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30), provincia CHAR(30) )NOT FINAL

Ahora, podemos crear un tipo empleado con un atributo del tipo Dirección de la siguiente manera:

…tipo empleado con un atributo del tipo Dirección :

CREATE TYPE empleado AS ( dni CHAR(12), nombre CHAR(40), sueldoBase INTEGER, anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, jefe REF(empleado), domicilio direccion)INSTANTIABLE NOT FINAL

Para acceder a un atributo de una instancia, lo hacemos de la misma manera que en JAVA, a excepción de los atributos de tipo REF(...)

Por ejemplo, para acceder al atributo dni, de un empleado e, sería: e.dni, y esto se aplica a cualquier nivel de anidamiento, por ejemplo: e.domicilio.numero.

Para acceder a los atributos cuyo tipo de datos sea REF(...) existe el

operador ->. Por ejemplo, si queremos saber el nombre del jefe del empleado, sería: e.jefe->nombre

No podemos asignar una visibilidad (Ej.: public, private, protected) a los atributos (característica que estuvo presente en el borrador de trabajo del año 1997). A pesar de esto, el acceso a los atributos de un tipo no es directo. Para cada atributo, el sistema genera dos funciones, una observadora y otra mutadora.

Por ejemplo, si decimos p.dni, lo que sucede en realidad es que estamos invocando a la función observadora dni(p).

Si realizamos una asignación como

p.dni:=’13.131.344’

estamos invocando implícitamente a la función mutadora

dni(p,’13.131.344’).

Lamentablemente, las funciones observadoras y mutadoras, no pueden ser sobrecargadas.

1.2.1.3 MétodosA partir de SQL-92 se introduce la noción de procedimiento almacenado, que corresponde a funciones o procedimientos definidos por el usuario, que pueden ser usados en sentencias SQL.

SQL: 1999 incorpora una tercera categoría de procedimiento almacenado, los métodos. Un método, al igual que una función, posee un nombre, una lista de argumentos (que puede estar vacía) y un valor de retorno (opcional). La gran diferencia radica en que un método, está asociado a un UDT estructurado en particular, y no puede ser invocado Independientemente.

Al definir los métodos en la creación del UDT estructurado, sólo declaramos su interfaz (función prototipo o encabezado). Para definir su implementación o cuerpo, utilizamos la sentencia CREATE METHOD. El código que implementa al método, puede ser escrito en SQL (usando las sentencias computacionalmente completas del SQL/PSM o en cualquiera de los lenguajes de programación más tradicionales, incluyendo JAVA.Los métodos se clasifican en: métodos de instancia, métodos constructores y métodos estáticos.

1.2.1.3.1 Métodos de Instancia

Los métodos de instancia, son aquellos que serán invocados a partir de un objeto concreto.

• Para definirlos anteponenemos las palabras reservadas INSTANCE METHOD o simplemente METHOD, seguido por el nombre, la lista de parámetros (que puede estar vacía) y opcionalmente el tipo del valor de retorno.

• Cada elemento de la lista de parámetros está compuesto por: Modo, nombre y tipo de datos; donde el modo es la manera en la que se pasa el parámetro, que puede ser IN (entrada), OUT (salida), INOUT( entrada y salida).

• Los métodos de instancia, pueden ser sobrecargados.

Por ejemplo, consideremos un tipo triángulo, definido por los tres vértices que lo componen, y con tres métodos, uno que calcule su área, y dos para calcular la distancia entre un punto y el lado más cercano del triángulo.

1.2.1.3.1 Métodos de Instancia…CREATE TYPE triangulo AS ( A punto, B punto, C punto )INSTANTIABLE NOT FINAL METHOD Area() RETURNS FLOAT,INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT,INSTANCE METHOD distanciaA(x FLOAT, y FLOAT) RETURNS FLOAT;

La Invocación de un método de instancia, se realiza de la misma forma que accedemos a un atributo.

Por ejemplo, si quisiéramos saber el área de un triángulo t, sería:

... t.Area()Si t fuera una referencia a un triangulo, la invocación al método area() sería:

... t->Area()

1.2.1.3.1 Métodos de Instancia…

Los métodos de instancia incluyen, implícitamente un parámetro, cuyo nombre es SELF, y representa al objeto de la invocación.

Opcionalmente podemos especificar otras características del método (ver <method characteristic> en A.2. 1), las cuales se indican a continuación del encabezado. La primera es

(<language clause>) indica el lenguaje en el que se programará el método. Si omitimos esta cláusula, el lenguaje por defecto, es SQL.

Por ejemplo, si al método área del tipo triangulo, mostrado anteriormente, lo quisiéramos programar en pascal, tendríamos que especificar:...METHOD Area() RETURNS FLOATLANGUAGE PASCAL ...


La cláusula <parameter style clause> indica cómo debemos pasar los parámetros. • Puede tomar dos valores posibles:PARAMETER STYLE SQL. Los parámetros son pasados al estilo de SQL. Para las rutinas externas que utilicen este estilo, es necesario agregar algunos parámetros para el control de los valores nulos, valores de retorno y otros parámetros de control.

En general, se necesitan 2n+4 parámetros para los procedimientos y 2n+6 para las funciones, donde n es el número de parámetros del método.

PARAMETER STYLE GENERAL. Cada parámetro del método, corresponde efectivamente a un parámetro en la implementación. Para las rutinas externas, es la manera más fácil de pasar parámetros, porque coinciden uno a uno. El problema existe con los valores nulos, que no son soportados, es decir, no podemos invocar al método con parámetros cuyos valores actuales, sean nulo.

Si esta cláusula es omitida, se asume PARAMETER STYLE SQL.


…cómo debemos pasar los parámetros. <parameter style clause>

Ejemplo:...METHOD Area() RETURNS FLOATLANGUAGE PASCALPARAMETER STYLE GENERAL...


La cláusula <deterministic characteristic> indica si el método es determinista o no.

Un método es determinista, si en cada llamada con los mismos parámetros entrega el mismo resultado. Por ejemplo:

... Math.sqrt(9).

• Es difícil que un método de instancia sea determinista, puesto que el estado actual del objeto, afecta su comportamiento (Ej. de la distancia entre un triángulo y un punto).

• El comportamiento determinista es más propio de los métodos estáticos.

• El valor por defecto de esta cláusla es NOT DETERMINISTIC.

... METHOD Area() RETURNS FLOAT LANGUAGE PASCAL PARAMETER STYLE GENERAL NOT DETERMINISTIC ...


La cláusula <SQL-data access indication>, indica si el método manipula o no datos y sentencias de SQL.

Los valores posibles son: NOT SQL CONTAINS SQL READS SQL DATA MODIFIES SQL DATA.

Ejemplo:...METHOD Area() RETURNS FLOATLANGUAGE PASCALPARAMETER STYLE GENERALNOT DETERMINISTICNOT SQL...

1.2.1.3.1 Métodos de Instancia…Los métodos que modifican datos de SQL (cláusula MODIFIES SQL DATA) no son permitidos en:

-Constraint-Assertions-Sentencia CASE-Before Triggers-Cláusula de búsqueda en sentencias DELETE-Cláusula de búsqueda en sentencias UPDATE (aunque es permitido dentro de la cláusula SET)

La cláusula <null-call clause>, indica la forma de proceder, si todos los parámetros pasados al momento de la llamada fuesen nulos. Para este caso existen dos alternativas, retornar NULL sin llamar al método (RETURNS NULL ON NULL INPUT) o llamar al método (CALLED ON NULL INPUT). Este último es el valor por defecto. Ejemplo:...INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOATRETURNS NULL ON NULL INPUT...

1.2.1.3.2 Métodos estáticos

Los métodos estáticos, son aquellos que serán invocados a partir de un tipo estructurado y no de un objeto.

Para definirlos se anteponen las palabras reservadas STATIC METHOD seguido del nombre, la lista de parámetros (que puede estar vacía) y opcionalmente el tipo del valor de retorno.

Un método estático, no posee el parámetro implícito self, porque son invocados a partir de un tipo y no de un objeto. Por esta razón, no podemos acceder a los atributos del tipo, desde un método estático.

Al igual que en un método de instancia, los métodos estáticos pueden ser sobrecargados.

Por ejemplo, consideremos el tipo triángulo mostrado anteriormente, al que agregámos un método estático que permita crear un triángulo a partir de tres puntos:

1.2.1.3.2 Métodos estáticos

… método estático que permite crear un triángulo a partir de tres puntos:

CREATE TYPE triangulo AS ( A punto, B punto, C punto )INSTANTIABLE NOT FINAL METHOD Area() RETURNS FLOAT,INSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOATSTATIC METHOD crear(a Punto, b Punto, c Punto) RETURNS triangulo

Para invocar al método crear se utiliza: triangulo: :crear(a,b,c)Donde a,b,c son instancias del tipo Punto previamente definidas.

Al igual que en los métodos de instancia, podemos especificar las características opcionales descritas en <method characteristic> en A.2.1.

1.2.1.3.3 Constructores

Al crear un tipo estructurado incluyendo la cláusula INSTANTIABLE, el sistema define un método constructor por defecto. Este método, es una función que:

• Tiene el mismo nombre que el tipo estructurado • No posee argumentos • El valor de retorno es una instancia del tipo al que pertenece dicho método constructor, y el valor de cada atributo corresponde al valor por defecto, especificado al momento de su creación.

Por ejemplo, para el tipo persona, el constructor por defecto es persona( )

El estándar SQL: 1999, no permite los constructores definidos por el usuario, pero existe un operador llamado NEW que nos permite invocar a un método de instancia que hará las veces de constructor. El método debe tener el mismo nombre que su tipo estructurado, y puede ser sobrecargado.

Por ejemplo, consideremos el siguiente tipo persona:

1.2.1.3.3 Constructores

… consideremos el siguiente tipo persona:

CREATE TYPE persona AS ( dni CHAR(12), Nombre CHAR(40),)INSTANTIABLE NOT FINAL METHOD persona(doc CHAR(12), nom CHAR(40)) RETURNS persona

Si queremos construir un objeto del tipo persona utilizando el operador NEW sería:

...new persona(’13.131.344’, ’Miguel Romero Vásquez’)

El operador NEW suple la carencia de constructores definidos por el usuario.

método de instancia que hace las veces de constructor

1.2.1.3.4 Creación de métodos

Para cada método definido al crear el tipo estructurado, es necesario definir su código o enlazarlo con un programa externo. Para esto utilizamos la cláusula CREATE METHOD (ver A.2.4).

Por ejemplo, consideremos la creación del siguiente tipo estructurado para implementar un número complejo:

CREATE TYPE complejo AS ( rpart REAL DEFAULT 0, ipart REAL DEFAULT 0)INSTANTIABLE FINALMETHOD suma(x complejo) RETURNS complejo,METHOD resta(x complejo) RETURNS complejo,METHOD mult(x complejo) RETURNS complejo,METHOD div(x complejo) RETURNS complejo;

Un numero complejo consta de dos partes una real (atributo rpart) y otra imaginaria (atributo ipart), ambas dentro del rango de los números reales. Además existen una serie de operaciones matemáticas que se pueden aplicar a dichos números(métodos suma, resta, mult y div).


Creación de los métodos suma y resta usando SQL/PSM:

CREATE METHOD suma(x complejo) RETURNS complejo FOR complejoBEGIN DECLARE co complejo; SET co = complejo(); SET co.rpart = self.rpart + x.rpart; SET co.ipart = self.ipart + x.ipart; RETURN co;END;

CREATE METHOD resta(x complejo) RETURNS complejo FOR complejo BEGIN DECLARE co complejo; SET co = complejo(); SET co.rpart = self.rpart - x.rpart; SET co.ipart = self.ipart - x.ipart; RETURN co;END;

constructor

412.1.3.4 Creación de métodos

Creación de los otros métodos del tipo complejo, usando SQL/PSM:

CREATE METHOD mult(x complejo) RETURNS complejo FOR complejo BEGIN DECLARE co complejo; SET co = complejo();

SET co.rpart = rpart * x.rpart – ipart * x.ipart;

SET co.ipart = rpart * x.ipart + ipart * x.rpart; RETURN co;END;

CREATE METHOD div(x complejo) RETURNS complejo FOR complejo BEGIN DECLARE z REAL;

SET z = x.rpart * x.rpart + x.ipart * x.ipart; DECLARE co complejo; SET co = complejo();

SET co.rpart = (rpart * x.rpart + ipart * x.ipart)/z;

SET co.ipart = (ipart * x.rpart - rpart * x.ipart)/z; RETURN co; END;


Como se puede observar, la sintaxis es bastante sencilla, comienza con las palabras reservadas CREATE METHOD, seguida por el nombre del método, la lista de argumentos y opcionalmente la cláusula RETURNS junto al tipo del valor de retorno.

La palabra reservada FOR nos permite indicar el tipo al que pertenece el método, en este caso complejo.

Al encabezado le sigue el cuerpo del método, que puede ser escrito en SQL (como en el ejemplo anterior) o en un lenguaje externo (C, Fortran, Ada, etc).

Para aquellos métodos que son implementados en un lenguaje externo, es necesario indicar <external routine name>, <parameter style clause>, <external security clause> (ver A.2.4).


Por ejemplo: Consideremos el mismo tipo complejo, con el método suma externo. Lo primero sería indicar el lenguaje de programación al momento de definir el tipo:

CREATE TYPE complejo AS ( rpart REAL DEFAULT 0, ipart REAL DEFAULT 0 )INSTANTIABLE FINAL METHOD suma(x complejo) RETURNS complejo, LANGUAGE C METHOD resta(x complejo) RETURNS complejo, METHOD mult(x complejo) RETURNS complejo, METHOD div(x complejo) RETURNS complejo;

Luego, al implementar el método, indicar el nombre externo, y opcionalmente, el estilo del paso de parámetros y la cláusula de seguridad:

CREATE METHOD suma(x complejo) RETURNS complejo FOR complejo EXTERNAL NAME ‘/routines/suma’PARAMETER STYLE GENERALEXTERNAL SECURITY INVOKER


Para poder invocar un método, el usuario debe tener el privilegio EXECUTE sobre el método ( otorgado con la cláusula GRANT ).

La cláusula de seguridad indica al sistema qué privilegios considerar para permitir o negar la ejecución del método. Puede asumir tres valores posibles:

EXTERNAL SECURITY DEFINER. Considerar los privilegios del usuario que definió el método.

EXTERNAL SECURITY INVOKER. Considerar los privilegios del usuario que invoca al método.

EXTERNAL SECURITY IMPLEMENTATION DEFINED. Permite que la implementación decida qué privilegios utiliza, si los del usuario que definió el método o del que lo invoca. Este valor es asumido cuando se omite la cláusula de seguridad.


Los métodos externos tienen varias ventajas frente a los métodos implementados con SQL:

• Permiten utilizar funciones que ya teníamos, o incorporar bibliotecas de funciones de otros lenguajes como Java, Pascal, C, Fortran, extendiendo las capacidades de SQL, sin la necesidad de programarlas en SQL.

• Las rutinas externas son más portables (por ejemplo rutinas escritas en C o Java).

• Las rutinas externas, permiten aprovechar las características y capacidades de un amplio conjunto de lenguajes. Por ejemplo: concurrencia, funciones matemáticas y estadísticas avanzadas, comunicación entre procesos, envío de correo electrónico, manejo de sensores, etc.


Pero tienen las siguientes desventajas que deben ser consideradas:

• Mover datos entre la rutina externa y el código SQL requiere un esfuerzo adicional de programación y a veces problemas, por la falta de correspondencia entre los tipos de datos. Por ejemplo el tipo Real de SQL soporta valores nulos, pero el tipo Real de C, no.

• Para las rutinas externas que contienen código SQL, es necesaria la creación de nuevas sesiones de SQL, lo que puede ser bastante costoso.

• El tiempo de desarrollo puede incrementarse al tener que utilizarlenguajes externos, por el esfuerzo adicional de entrenamiento y depuración frente a los métodos desarrollados bajo SQL/PSM.

1.2.1.4 Modificación de tipos (ALTER TYPE)

Con el predicado ALTER TYPE (ver A.2.3 <alter type statement>) podemos agregar o eliminar atributos y métodos a un tipo estructurado.

Para ejemplificarlo utilizaremos el siguiente tipo:

CREATE TYPE empleado AS ( dni CHAR(12), nombre CHAR(40), sueldoBase INTEGER, anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, domicilio direccion )INSTANTIABLE NOT FINAL

…ALTER TYPE1.2.1.4.1 Agregar un atributo

Si queremos agregar el atributo email al tipo empleado, sería:

ALTER TYPE empleado ADD ATTRIBUTE email CHAR(50)

No podremos agregar el atributo email cuando exista una o más columnas en alguna tabla relacional cuyo tipo de datos sea:

- empleado. - Un arreglo de cualquier supertipo o subtipo de empleado. - Cualquier supertipo o subtipo de T, siendo T un tipo que posee uno o más atributos que referencian a un empleado.

Tampoco podremos agregar un atributo, si existe alguna tabla de objetos cuyo tipo base sea un subtipo (directo o no) de empleado.

La definición de un atributo con ALTER TYPE utiliza la misma sintaxis que en CREATE TYPE.

…ALTER TYPE1.2.1.4.2 Eliminar un atributo

Si queremos eliminar el atributo domicilio del tipo empleado sería:

ALTER TYPE empleado DROP ATTRIBUTE domicilio RESTRICT

En los siguientes casos, no podremos eliminar el atributo domicilio:

- Si es el único atributo que posee el tipo empleado.- Si es un atributo heredado.-Si existe una o más columnas en alguna tabla relacional cuyo tipo de datos sea:

- empleado. - Un arreglo de cualquier supertipo o subtipo de empleado, sea directo o no. - Cualquier supertipo o subtipo de T, siendo T un tipo que posee uno o más atributos que referencian a un empleado - Si existe alguna table tipada cuyo tipo base sea un subtipo (directo o no) de empleado.

…ALTER TYPE1.2.1.4.2 Eliminar un atributo

….no podremos eliminar el atributo domicilio:

-Si es utilizado directa o indirectamente en:

-El cuerpo de un método -Una función o un procedimiento -Un trigger -La expresión booleana de una constraint o una assertion -La expresión de consulta que define una vista.

…ALTER TYPE

1.2.1.4.3 Agregar un método

Si queremos agregar el método SueldoLiquido() al tipo empleado, sería: ALTER TYPE empleado ADD METHOD SueldoLiquido() RETURNS INTEGER

Para especificar el nuevo método, utilizamos la misma sintaxis que en CREATE TYPE.

1.2.1.4.4 Eliminar un métodoConsideremos el tipo triángulo definido previamente:Si queremos eliminar el método distanciaA del tipo triangulo sería:

ALTER TYPE triangulo DROP METHOD distanciaA(Punto) FOR triangulo RESTRICT

Para indicar el método a eliminar, tenemos que indicar su nombre y opcionalmente, los tipos de datos de los parámetros, separados por coma y entre paréntesis, seguido de eso, la palabra reservada FOR y el nombre del tipo al que pertenece. Esto último, es obligatorio cuando tenemos sobrecargado el método.

1.2.1.5 Eliminación de tipos (DROP TYPE)

Mediante la sentencia DROP TYPE, podemos eliminar un tipo estructurado.

Por ejemplo, si queremos eliminar el tipo punto, decimos:

DROP TYPE punto CASCADE

La cláusula CASCADE, indica que se deben borrar todas las dependencias que existan con este tipo. Alternativamente a CASCADE, existe la cláusula RESTRICT, que impide el borrado del tipo si existen dependencias. Por ejemplo:

DROP TYPE punto RESTRICT

1.2.1.6 Comparación de instancias

Inicialmente, no podemos comparar dos instancias de un tipo estructurado (ej: A>B). Para lograr esto, es necesario que el usuario defina una función que los compare y luego asociarla al tipo estructurado correspondiente. Para esto existe la sentencia CREATE ORDERING (ver A.2.8).

1.2.1.6 Comparación de instancias…

Existen dos modos de comparación:EQUALS ONLY. Sólo se permiten comparaciones de igualdad (=) y desigualdad (<>).ORDER FULL. Todas las comparaciones son permitidas (>,<,=,<>)

Además, podemos escoger entre tres posibles funciones de comparación:

STATE. La función de comparación es creada por el sistema. Dicha función tiene dos parámetros (que son las instancias a comparar) y retorna un Boolean. La función compara ambas instancias, atributo por atributo. Si coinciden los valores de todos los atributos entre las instancias retorna true, si no, retorna false.

RELATIVE. El usuario debe especificar la función de comparación, lacual debe contar con dos parámetros (las instancias a comparar) y cuyo valor de retorno sea del tipo Integer. La función debe retornar 0 si ambas instancias son iguales, un valor positivo si la primera instancia es mayor que la segunda, y un valor negativo si es menor.

MAP. El usuario debe especificar la función de comparación…sigue


MAP. El usuario debe especificar la función de comparación, la cual debe contar con un sólo parámetro y debe retornar un tipo de dato primitivo.

La función no se encarga de comparar las instancias, pero puede indicar la posición que tomaría la instancia pasada por parámetro, si ordenáramos el universo completo de las instancias.

El sistema utiliza el valor devuelto para realizar la comparación.

Al momento de definir una función de comparación debemos considerar lo siguiente:- STATE sólo puede ser utilizado con EQUALS ONLY.

- Dentro de una jerarquía de tipos, STATE y RELATIVE deben ser especificados para el supertipo máximo (aquel que no tiene padre).

- MAP puede ser especificado para más de un tipo, dentro de una jerarquía de tipos, pero todos ellos deben utilizar MAP, es decir, no podemos definir unos tipos con MAP y otros con STATE o RELATIVE.Para ejemplificarlo, utilizaremos el tipo empleado utilizado antes:


Para ejemplificarlo, utilizaremos…

CREATE TYPE empleado AS ( dni CHAR(12), nombre CHAR(40), sueldoBase INTEGER, anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, domicilio direccion)INSTANTIABLE NOT FINAL

Si queremos definir una función de comparación del tipo STATE sería:

CREATE ORDERING FOR empleado EQUALS ONLY BY STATE

Con ella podremos hacer comparaciones de igualdad y desigualdad.

Si lo que queremos es permitir todas las comparaciones, debemos utilizar ORDER FULL y definir una función del tipo RELATIVE o MAP. Por ejemplo:

CREATE ORDERING FOR empleado ORDER FULL BY RELATIVEWITH FUNCTION empleado_relative (empleado,empleado)

Una implementación válida de la función empleado_relative sería:

CREATE FUNCTION empleado_relative(a empleado, b empleado) RETURNS INTEGERBEGINDECLARE comp INTEGER; IF a.sueldoBase = b.sueldoBase THEN SETcomp=0; ELSE IF a.sueldoBase > b.sueldoBase THEN SET comp=1; ELSE SETcomp= -1; END IF; END IF;RETURN comp; END

Comparamos a los empleados por su sueldo

CREATE ORDERING FOR empleado ORDER FULL BY MAPWITH FUNCTION empleado_map(empleado)

Una implementación válida de la función empleado_map sería: CREATE FUNCTION empleado_map(e empleado) RETURNS INTEGER BEGIN RETURN e.sueldoBase; ENDLas funciones del tipo MAP y RELATIVE, también pueden ser usadas con EQUALS ONLY. Por ejemplo:

CREATE ORDERING FOR empleado EQUALS ONLY BY RELATIVEWITH FUNCTION empleado_relative (empleado,empleado)

CREATE ORDERING FOR empleado EQUALS ONLY BY MAPWITH FUNCTION empleado_map(empleado)

Para entender mejor cómo trabajan estas funciones, consideremos la comparación “E1 = E2” siendo E1 y E2 instancias del tipo empleado. Internamente esta expresión será sustituida por otra, basada en la función de comparación correspondiente. Tenemos 3 casos posibles:

Si la función es del tipo STATE, la expresión se sustituye por:

“SF(E1,E2)= TRUE” siendo SF(...) la función definida por el sistema.

Si la función es del tipo MAP, se sustituye por:

“empleado_map(E1) = empleado_map(E2)”

Si la función es del tipo RELATIVE, se sustituye por:

“empleado_relative(E1,E2) = 0”

1.2.1.6.1 Eliminación de funciones de comparación

Para eliminar la función de comparación de un tipo, utilizamos la sentencia DROP ORDERING (ver A.2.9).

Por ejemplo, para eliminarla del tipo empleado sería: DROP ORDERING FOR empleado RESTRICT

No podremos eliminar la función de comparación, si existe algún predicado que compare instancias del tipo empleado en:

métodos , Funciones o procedimientosVistasConstraintAssertionTrigger

1.2.1.7 Conversión de UDT

SQL es un lenguaje fuertemente tipado. Esto significa que no podemos mezclar tipos arbitrariamente en expresiones de comparación o en asignaciones, sino que debemos hacer una conversión explícita de tipos con la sentencia CAST.

Para los tipos primitivos (ej.: INTEGER, BOOLEAN, CHAR, etc), existen funciones CAST predefinidas.

Por ejemplo, si queremos asignar un valor INTEGER a una variable SMALLINT dentro de una función sería:...DECLARE a INTEGER, b SMALLINT; SET b = CAST (a AS SMALLINT) ...

1.2.1.7 Conversión de UDT (CAST definidos por el usuario)

Para los tipos definidos por el usuario, no existen funciones CAST por defecto.

Para solucionar esto, SQL-1999 permite al usuario definir funciones CAST para sus tipos con la sentencia CREATE CAST (ver A.2.6).

Por ejemplo, consideremos que tenemos dos tipos estructurados, uno llamado T1 y otro T2, y queremos implementar un CAST para convertir valores de T1 a T2.

Lo primero que tenemos que hacer, es crear una función con un único parámetro del tipo T1, cuyo valor de retorno sea del tipo T2, es decir:

CREATE FUNCTION convert(T1) RETURNS T2 BEGIN ...RETURN ...END;

…CAST definidos por el usuario

Y luego definimos el CAST de la siguiente manera:

CREATE CAST(T1 AS T2) WITH FUNCTION convert(T1) AS ASSIGNMENT

La cláusula AS ASSIGNMENT es opcional, y permite que la función de conversión sea llamada implícitamente en las asignaciones. Por ejemplo:...DECLARE a T1, b T2;SET b = a;...Si omitimos esta cláusula AS ASSIGNMENT, tendremos que llamar explícitamente al CAST en las asignaciones. Por ejemplo: ...DECLARE a T1, b T2; SETb=CAST(a AS T2); ...

1.2.1.7.1 Eliminación de CAST definidos por el usuario

Para eliminar un CAST definido por el usuario existe la sentencia DROP CAST( ver A.2.7).

Por ejemplo:

DROP CAST (T1 AS T2) RESTRICT

No podremos eliminar el CAST definido por el usuario, si es utilizado en:

métodos , Funciones o procedimientosVistasConstraintAssertionTrigger

1.2.2 Colecciones 1.2.2.1 Arreglos

1.2.3 Encapsulamiento

1.2.4 Modularidad

1.2.5 Persistencia 1.2.5.1 Manejo de Tablas 1.2.5.1.1 Creación (CREATE TABLE) 1.2.5.1.2 Modificación (ALTER TABLE) 1.2.5.1.3 Eliminación (DROP TABLE) 1.2.5.2 Manejo de Instancias 1.2.5.2.1 Inserción de objetos 1.2.5.2.2 Selección de objetos (SELECT) 1.2.5.2.3 Modificación de objetos 1.2.5.2.4 Eliminación de objetos

1.2.2 Colecciones

Una colección es una estructura que permite almacenar cero o más elementos del mismo o de distinto tipo de datos.

El término colección es genérico, y comprende: arreglos, conjuntos, árboles, etc. El estándar SQL: 1999 solamente soporta arreglos.

1.2.2.1 Arreglos

Un arreglo (array) es un conjunto de elementos del mismo tipo, donde cada elemento está en una posición determinada.

Al definir un arreglo, se especifica la cantidad máxima de elementos que puede tener (m en adelante).

Las posiciones del arreglo comienzan a partir de 1, hasta n, siendo n el número de elementos que contiene el arreglo, y deberá estar en el rango

1 <=n <= m.

1.2.2 Colecciones

Un arreglo, es un tipo de datos, que utilizamos de igual modo que un tipo primitivo.

Por ejemplo, podemos crear un tipo polígono, que contenga un arreglo para sus vértices (del tipo punto), y los métodos de area (), y perímetro(), de la siguiente manera:

CREATE TYPE poligono(vertices punto ARRAY [200] )INSTANTIABLE NOT FINALMETHOD Area() RETURN FLOAT, METHOD Perimetro() RETURN FLOAT Si queremos acceder al segundo vértice del poligono p, se escribe: ...p.vertices[2].

1.2.2 Colecciones

Podemos asignar varios elementos en un arreglo, simultáneamente. Por ejemplo, supongamos que hemos definido un arreglo notas, y quisiéramos asignarle las calificaciones: 100, 80 y 45 de una sola vez, esto sería: ... set Notas = ARRAY [100,80,45]; ...

También existe un operador de concatenación ( || ), que nos permitirá construir un nuevo arreglo, a partir de dos o más. Para el mismo ejemplo anterior, pensemos que queremos agregar las notas al final del arreglo, esto sería:...set Notas = Notas || ARRAY[100,80,45]; ...

Podemos definir un arreglo a partir de cualquier tipo de datos, sea primitivo o no, siempre y cuando, no contenga o no sea un arreglo.Dos arreglos (C y D) son iguales (C = D), si ambos tienen el mismo número de elementos y C[i]=D[i], para i=1 hasta n


Tres aspectos del encapsulamiento:

• Agrupar atributos y métodos en una sola entidad.

• Distinguir entre interfaz(pública) e implementación (privada)

• Asignar niveles de acceso individual a los atributos y métodos.

El primer aspecto, es cubierto con el predicado CREATE TYPE. Esta es la parte pública del método.

Con el predicado CREATE METHOD es cubierto el segundo punto. Gracias a esta división (publica y privada) podemos realizar cambios a la implementación de los métodos, sin que estos afecten a las aplicaciones que los utilizan.

El tercer punto es cubierto medianamente por las funciones observadoras y mutadoras definidas por el sistema, puesto que estas impiden que los usuarios accedan a los atributos directamente. Lamentablemente, no podemos sobrescribir dichas funciones.


Lo que falta para que el soporte al encapsulamiento sea completo, es la posibilidad de definir niveles de acceso a los atributos y métodos, como public, private y protected de Java.

Sin embargo, el modelo de seguridad de SQL-1999, permite obtener una funcionalidad similar, pero no completa de lo anterior.

Con respecto a los métodos, sólo los usuarios que tengan el privilegio EXECUTE podrán ejecutar un método, tanto para objetos persistentes como transitorios.

Para otorgar el privilegio EXECUTE utilizamos la sentencia GRANT. Por ejemplo:

GRANT EXECUTE ON METHOD sueldo_liquido() FOR empleado TO PUBLIC


Podemos ejecutar métodos dentro de sentencias SELECT. Para esto debemos otorgar el permiso correspondiente. Por ejemplo:

GRANT SELECT (METHOD sueldo_liquido() FOR empleado) ON TABLE tbl_emp TO PUBLIC

Con respecto a los atributos, sólo podremos restringir el acceso a ellos en objetos persistentes, para los objetos transitorios, todos sus atributos serán públicos.

Por defecto, un usuario no puede acceder a las filas de una tabla.

Para cada sentencia de manipulación de tablas existe un privilegio que debe ser otorgado. Por ejemplo:

GRANT SELECT (dni,nombre,sueldo) ON TABLE tbl_emp TO PUBLICGRANT INSERT (dni,nombre,sueldo) ON TABLE tbl_emp TO PUBLIC GRANT UPDATE (dni,nombre) ON TABLE tbl_emp TO PUBLIC GRANT DELETE ON TABLE tbl_emp TO PUBLIC

También podemos restringir el acceso a los atributos, creando vistas sobre las tablas.

1.2.4 Modularidad

SQL: 1999 sólo provee modularidad para las funciones y procedimientos almacenados.

1.2.5 Persistencia

Para hacer persistir los objetos tenemos dos alternativas:

• Almacenarlos como columnas en tablas relacionales

• Almacenarlos en una tabla especial denominada typed table donde cada fila es un objeto y cada columna un atributo del mismo.

En las siguientes secciones veremos el manejo de tablas que almacenen objetos, tanto en columnas como en filas. Además de cómo trabajar con dichas instancias.

1.2.5.1 Manejo de Tablas

El estándar incorpora varias características a las tablas relacionales. Además de permitir almacenar objetos como columnas, define tres tipos especiales de tablas:

typed tables, subtablas y supertablas.

En la presente sección, describiremos como definir dichas tablas.

1.2.5.1.1 Creación (CREATE TABLE)

Como mencionamos anteriormente, podemos almacenar objetos como columnas de tablas relacionales. Por ejemplo, Consideremos la siguiente definición de un tipo dirección.

…Manejo de TablasCREATE TYPE Direccion AS ( calle CHAR(40), Numero CHAR(10), ciudad CHAR(30), region CHAR(30))NOT FINAL

Ahora, podemos crear una tabla relacional con una columna del tipo dirección. Como ejemplo, consideremos la definición de una tabla de personas de la siguiente manera:

CREATE TABLE persona ( dni CHAR(12) PRIMARY KEY, nombre CHAR(40), fecha_nacim DATE, domicilio direccion)Como podemos observar, es bastante sencillo definir columnas basadas en tipos estructurados.

…Manejo de Tablas

Los objetos almacenados como columnas no pueden ser referenciados por no poseer un OID.

Solamente los objetos almacenados en una typed table pueden ser referenciados.

Una typed table, es una tabla o vista construida en base a un tipo estructurado definido por el usuario.

Además de crear una columna para cada atributo del tipo base, se agrega otra, para almacenar el identificador de objeto. Esta columna tiene las restricciones UNIQUE y NOT NULL implícitas.

Para crear una typed table llamada tbl_emp basada en el tipo empleado sería:

CREATE TABLE tbl_emp OF empleado (REF IS oid SYSTEM GENERATED)

oid, es el nombre de la columna adicional que almacenará el identificador de objeto. El tipo de datos de oid es REF(empleado).

…Manejo de Tablas

Dependiendo de la forma que el tipo base de la tabla maneje las referencias, (SYSTEM GENERATED, USER GENERATED y DERIVED) se especificará en el CREATE:

REF IS oid SYSTEM GENERATEDREF IS oid USER GENERATEDREF IS oid DERIVED

El valor que asumirá la columna oid, será asignado al insertar el objeto en la tabla, y no podrá ser modificado posteriormente.

Si especificamos SYSTEM GENERATED o DERIVED, el valor de oid será definido automáticamente al momento de la inserción.

En cambio si es USER GENERATED será suministrado por el usuario.

…Manejo de Tablas

Si queremos hacer persistir objetos que tengan un supertipo tenemos la posibilidad de definir una estructura super tabla/subtabla.

Por ejemplo, consideremos el tipo vendedor que es un subtipo de empleado definido de la siguiente manera:

CREATE TYPE vendedor UNDER empleado AS ( comision FLOAT, viatico INTEGER)INSTANTIABLE NOT FINAL OVERRIDING METHOD SueldoLiquido() RETURNS INTEGER

Ya habíamos hecho... CREATE TABLE tbl_emp OF empleado (REF IS oid SYSTEM GENERATED)

Ahora, podemos crear una subtabla de tbl_emp que almacene instancias del tipo vendedor. Para ello escribimos:

CREATE TABLE tbl_vendedor OF vendedor UNDER tbl_emp

Para que esta sentencia sea válida, tbl_emp, debe ser una tabla tipada cuyo tipo de datos sea el supertipo directo de vendedor.

…Manejo de Tablas

Así como toda instancia de un subtipo es también instancia de su supertipo, cada objeto “almacenado” en una subtabla, también es “almacenado” en la supertabla.

• Físicamente, los valores de los atributos heredados pueden ser “almacenados” en la supertabla y los valores más específicos del tipo, ser “almacenados” en la subtabla.

Como se trata del mismo objeto almacenado en la supertabla y en la subtabla, poseerá el mismo OID en ambas. Por esto. la forma de manejar el OID debe concordar en toda la Jerarquía de tablas.

• Cuando necesitamos recuperar un objeto en particular. el sistema se encarga de recopilar los valores desde las distintas tablas de la jerarquía de manera automática.

• La definición de estructuras jerárquicas de tablas, permite minimizar el impacto al extender las aplicaciones.

1.2.5.1.2 Modificación de tablas

Para modificar una tabla utilizamos el predicado ALTER TABLE (A.2. 13). Esta sentencia nos permite:

Agregar y Eliminar columnas.Agregar y eliminar cláusula DEFAULT.Agregar y eliminar cláusula SCOPE.Agregar y eliminar restricciones (CONSTRAINT).

Para la eliminación de elementos podemos especificar la cláusula CASCADE, que indica al sistema que, además de eliminar el elemento, elimine todas las dependencias existentes;o la cláusula RESTRICT, que impide el borrado del elemento al haber dependencias.

Por ejemplo, si queremos eliminar la restricción com de la tabla tbl_vendedor sería:

ALTER TABLE tbl_vendedor DROP CONSTRAINT com CASCADE

• No podemos agregar o eliminar columnas a una typed table

1.2.5.1.3 Eliminación de tablas

Para eliminar una tabla utilizamos el predicado DROP TABLE (ver A.2. 14).

Cuando queremos eliminar una tabla, debemos indicarle al sistema qué hacer con las dependencias que existan de ella, como pueden ser, subtablas, triggers, vistas, etc. Para ello tenemos dos predicados:

CASCADE, que indica que se borren todas las dependencias de la tabla.

RESTRICT, impide que se borre la tabla si existen dependencias. La sintaxis es bastante sencilla.

Por ejemplo, si queremos eliminar la tabla tbl_emp, sería:

DROP TABLE tbl_emp CASCADE

O bien: DROP TABLE tbl_emp RESTRICT

1.2.5.2 Manejo de Instancias

Para manipular las instancias que fueron almacenadas en una tabla, utilizamos las mismas sentencias del manejo de filas y columnas en tablas relacionales.

Las operaciones sobre las instancias las podemos agrupar en: Inserción, selección, eliminación y modificación de objetos.

1.2.5.2.1 Inserción de objetosPara insertar un objeto, tanto en tablas relacionales como en tablas tipadas utilizamos la sentencia INSERT INTO (ver A.2. 15).

Veamos primero cómo insertar un objeto como columna de una tabla relacional.

Para ello consideremos, a modo de ejemplo, las siguientes definiciones :

Manejo de Instancias….CREATE TYPE direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30))NOT FINALMETHOD direccion (ca CHAR(40),nu CHAR(10),ciu CHAR(30)) RETURNS direccion

CREATE TABLE persona ( Dni CHAR(12) PRIMARY KEY, nombre CHAR(40), domicilio direccion )

Inserción de una tupla en la tabla persona:

INSERT INTO personaVALUES(‘13131344’,’Miguel Romero’)NEW direccion(‘Pasaje San Francisco’,’1661’,’La Rioja’’)

Mediante el operador NEW creamos un nuevo objeto del tipo direccion, el cual será asignado a la columna domicilio de la tabla persona.

método de instancia que hace las veces de constructor

Inserción del objeto dirección

como columna de

la tabla

Manejo de Instancias…

También podríamos haber utilizado el constructor del tipo direccion, el que creará un objeto con los valores por defecto. Sería:

INSERT INTO persona VALUES(‘13131344’,’Miguel Romero’,direccion () )

La sintaxis para insertar un objeto como fila es muy similar. Por ejemplo, consideremos un tipo cliente y una tabla de clientes (tbl_cli), definidos de la siguiente manera:

CREATE TYPE cliente AS ( dni CHAR(12), nombre CHAR(40), domicilio direccion)INSTANTIABLE NOT FINALREF IS SYSTEM GENERATED

CREATE TABLE tbl_cli OF cliente (REF IS oid SYSTEM GENERATED)

Para insertar un cliente en esta tabla sería:INSERT INTO tbl_cliVALUES(‘13131344’,’Miguel Romero’) NEW direccion(‘Pasaje San Francisco’,’1661’,’La Rioja’’) al insertar este objeto, automáticamente se genera el valor para la columna oid, puesto que fue definida como SYSTEM GENERATED.


Al momento de insertar, tenemos la posibilidad de sobrescribir el valor que el sistema asigna automáticamente como oid. Por ejemplo:

INSERT INTO tbl_cli (oid,dni,nombre,domicilio) OVERRIDING SYSTEM VALUEVALUES(145,‘13 131344’,’Miguel Romero’, NEW dirección(‘Pasaje San Francisco’,’1661’,’La Rioja’’))

Si el tipo de referencia fuese USER GERERATED, obligatoriamente tendríamos que entregar el valor para la columna oid al hacer inserciones en la tabla correspondientePor ejemplo, consideremos la cláusula REF del tipo cliente como:REF USING NUMERIC(8)

y la definición de la tabla como: CREATE TABLE tbl_cli OF cliente (REF IS oid USER GENERATED)

La inserción de un cliente sería:INSERT INTO tbl_cli (oid,dni,nombre,domicilio)VALUES(13131344,‘1313 1344’,’Miguel Romero’, ) NEW dirección(‘Pasaje San Francisco’,’1661’,’La Rioja’’)


Para insertar un objeto en una typed table, el tipo estructurado que de origen a la tabla, debe ser instanciable (INSTANTIABLE).

Cuando insertamos un objeto en una tabla tipada que posea una supertabla, automáticamente se insertará la fila correspondiente en la supertabla. Para ello, tendremos que asignar valores tanto para los atributos heredados como para los más específicos, dentro del predicado INSERT.

Por ejemplo, para insertar un vendedor en la tabla tbl_vendedor sería:

INSERT INTO tbl_vendedor (dni,nombre,SueldoBase,Anticipo, domicilio, comision, viatico) VALUES(’11.111.111’,’Luis Perez’,1500,1000,direccion(),12,3500)

Si se excluyen valores para alguno de los atributos, estos asumirán el valor por defecto. Eso es lo que pasa en el ejemplo anterior con el atributo fecha_ing, que no fue especificado.

1.2.5.2.2 Selección de objetos

La sentencia SELECT, nos permite obtener uno o más objetos almacenados en tablas, tanto relacionales como tipadas.

Por ejemplo, consideremos la tabla de persona definida en la seción anterior, supongamos que queremos obtener el nombre y el domicilio de todas las personas que viven en San Juan, esto sería:

SELECT nombre, domicilio.calle, domicilio.numero FROM personaWHERE domicilio.ciudad=’San Juan’

Como puede observar, podemos utilizar el atributo de un objeto, de la misma manera que las columnas de las tablas relacionales. Lo mismo pasa con los métodos. Por ejemplo, consideremos la tabla tbl_emp donde el tipo base es empleado.

Si queremos obtener el DNI, el nombre y el sueldo líquido de todos los empleados que tengan sueldos superiores a $2500, sería:

SELECT e.dni,e.nombre,e.SueldoLiquido() FROM tbl_emp eWHERE e.SueldoLiquido() > 2500

Si aplicamos la sentencia SELECT sobre una typed table que posea subtablas, la búsqueda de filas se extenderá a todas las subtablas que posea.

Por ejemplo, consideremos la tabla tbl_vendedor que es una subtabla de tbl_emp y cuyo tipo base es vendedor

Para obtener a todos los empleados de la empresa, incluyendo a los vendedores, sería:

SELECT e.dni,e.nombre,e.SueldoLiquido() FROM tbl_emp

Gracias al polimorfismo, la ejecución del método SueldoLiquido(), dependerá del tipo concreto del objeto ya sea empleado o vendedor.

Para el ejemplo anterior, esta característica es fundamental, pues el cálculo del sueldo líquido de un vendedor, es diferente al de un empleado.Si queremos excluir de la búsqueda a las subtablas de tbl_emp, utilizamos la cláusula ONLY, de la siguiente manera:

SELECT *FROM ONLY(tbl_emp)

Selección de objetos…

Para restringir la búsqueda a la tabla tbl_vendedor hacemos:SELECT *FROM tbl_empWHERE DEREF(oid) IS OF (tbl_vendedor)

Si tenemos un atributo o una columna que es una referencia a un objeto, podemos acceder a los atributos y métodos del objeto referenciado, utilizando el operador ->

Considerar los siguientes tipos y sus respectivas tablas:

CREATE TYPE punto AS ( X REAL, Y REAL) INSTANTIABLE NOT FINALREF IS SYSTEM GENERATEDINSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT

CREATE TABLE tbl_pto OF punto (REF IS oid SYSTEM GENERATED)

CREATE TYPE linea_recta AS (A REF punto, B REF punto)INSTANTIABLE NOT FINALREF IS SYSTEM GENERATED

CREATE TABLE tbl_lineas OF linea_recta (REF IS oid SYSTEM GENERATED)Si queremos obtener las coordenadas de los puntos A y B de todas las líneas que tengan un largo mayor a 100, sería:

Uso de referencias...

…coordenadas de los puntos A y B de todas las líneas que tengan un largo mayor a 100:

SELECT L.A->X, L.A->Y, L.B->X, L.B->Y FROM tbl_lineas LWHERE L.A->distanciaA(B)> 100

El uso de referencias simplifica las consultas, puesto que disminuye la necesidad de utilizar JOIN.

1.2.5.2.3 Modificación de objetosPara modificar uno o más objetos, utilizamos el predicado UPDATE

Por ejemplo, consideremos la typed table tbl_emp definida en la donde el tipo base es empleado; si queremos aumentar el sueldo en $2500 a todos los empleados que tengan sueldos entre $ 1000 y $ 2000, sería:

UPDATE tbl_empSET SueldoBase = SueldoBase + 2500 WHERE SueldoBase BETWEEN 1000 AND 2000

Modificación de objetos…

Si aplicamos el predicado UPDATE sobre una supertabla, los cambios también se aplicarán a todos los objetos de las subtablas que cumplan con la condición definida en la cláusula WHERE

Para evitar esto, utilizamos el predicado ONLY de la siguiente manera:

UPDATE ONLY(tbl_emp)SET SueldoBase = SueldoBase + 2500 WHERE SueldoBase BETWEEN 1000 AND 2000

Al igual que en la sentencia SELECT, en UPDATE, podemos restringir las tablas que serán utilizadas. Si en el ejemplo anterior, quisiéramos que UPDATE sólo afectara a la tabla tbl_vendedor sería:

UPDATE tbl_empSET SueldoBase = SueldoBase + 2500WHERE DEREF(oid) IS OF(tbl_vendedor) AND SueldoBase BETWEEN 1000 AND 2000

Modificación de objetos…

Como toda fila de la tabla tbl_vendedor posee una fila, de atributos heredados, en la tabla tbl_emp, el sistema ajustará automáticamente la fila que corresponde a la supertabla cuando utilicemos el predicado UPDATE sobre la tabla tbl_vendedor.

Por ejemplo:UPDATE tbl_vendedorSET SueldoBase = SueldoBase + 2500 WHERE SueldoBase BETWEEN 1000 AND 2000

Si el tipo base de una tabla, posee un atributo que es un arreglo, podemos actualizarlo de dos maneras:

La primera, tomando los elementos individualmentepor ejemplo, consideremos que el tipo base posee un atributo llamado arr que es un arreglo de 5 enteros:UPDATE tabla_con_arreglo SET arr[5] = 23, arr[2] = 12 WHERE arr[1]=0La segunda, asignando un arreglo completo, por ejemplo:UPDATE tabla_con_arreglo SET arr = ARRAY[12,34,56,78,90] WHERE arr[1]=0

1.2.5.2.4 Eliminación de objetos

Para eliminar uno o más objetos utilizamos el predicado DELETE (ver A.2. 17). Este predicado borrará todas las filas que cumplan con la condición indicada por la cláusula WHERE, tanto en tablas relacionales como en typed tables.

Por ejemplo, consideremos la tabla tbl_cli para eliminar a todos los clientes cuyo nombre contenga el string ‘miguel’, sería:

DELETE FROM tbl_cli c WHERE c.nombre LIKE ’%miguel%’

Si ejecutamos la sentencia DELETE sobre una typed table que posea subtablas, también se eliminarán todos los objetos que cumplan con la condición en las subtablas.

Por ejemplo, consideremos la tabla tbl_emp que posee una subtabla denominada tbl_vendedor, si ejecutamos la sentencia:

DELETE FROM tbl_emp e WHERE e.sueldobase < 1000Eliminará a todos los empleados y vendedores que tengan sueldos inferior a 100. Para limitar el borrado a la tabla tbl_emp, utilizamos la cláusula ONLY. DELETE FROM ONLY tbl_emp e WHERE e.sueldobase < 1000

Eliminación de objetos…

Podemos restringir las tablas que serán tratadas por DELETE. Si para el ejemplo anterior, queremos eliminar sólo de la subtabla vendedores (tbl_vendedor) a los que cumplan con la condición sería:

DELETE FROM tbl_emp eWHERE DEREF(oid) IS OF(tbl_vendedor) AND e.sueldobase <1000

1.2.6 Jerarquía de Clases 1.2.6.1 Asociación 1.2.6.2 Agregación y Composición 1.2.6.3 Herencia y Polimorfismo1.2.7 Concurrencia1.2.8 Manejo de Versiones de objetos y configuraciones1.2.9 Evolución de esquemas y de Instancias1.2.10 Transacciones y recuperación ante fallos1.2.11 Mecanismos de Autorización1.2.12 Compatibilidad con el modelo relacional1.2.13 Limitaciones encontradas en SQL:1 9991.3 Evaluación 1.3.1 Criterios de evaluación 1.3.2 Matriz de evaluación

1.2.6 Jerarquía de Clases1.2.6.1 AsociaciónEl concepto de asociación es similar al de relación en el modelo entidad-relación. Por eso, podemos utilizar las mismas estrategias para su implementación, pero con la ventaja de la existencia de las referencias de objeto, que son más eficientes que el manejo de clave foránea. Por ejemplo, consideremos la siguiente asociación:

Para implementarla, agregaremos un atributo en el tipo cliente que sea una referencia al tipo vendedor. La implementación de los tipos quedaría:

Cliente Vendedor

Jerarquía de clases…

CREATE TYPE vendedor AS ( dni CHAR(12), nombre CHAR(40), sueldo NUMBER, comision NUMBER, domicilio direccion)INSTANTIABLE NOT FINAL

Otra alternativa es agregar un atributo clientes al tipo vendedor, que sea un arreglo de referencias a sus clientes. El único inconveniente es que debemos definir un largo máximo al arreglo.

Lo anterior sería:

CREATE TYPE cliente AS ( dni CHAR(12), nombre CHAR(40), telefono CHAR(20), domicilio dirección, vendedorAsignado REF(vendedor) )INSTANTIABLE NOT FINAL

CREATE TYPE vendedor AS ( dni CHAR(12), nombre CHAR(40), sueldo NUMBER, comision NUMBER, domicilio direccion, clientes REF(cliente) ARR [100] )INSTANTIABLE NOT FINAL

Jerarquía de clases…

Si la multiplicidad de la asociación es uno a uno, cualquiera de los tipos puede tener la referencia al otro (ejemplo anterior).

Si la multiplicidad de la asociación es muchos a muchos, o si la asociación en si misma tiene atributos, es necesario crear otro tipo para implementarla.

Por ejemplo:

clientevendedor

Cartera_de_clientes

* *

Cliente

La implementación de estos tres tipos sería:

CREATE TYPE vendedor AS ( dni CHAR(12), nombre CHAR(40), sueldo NUMBER, comision NUMBER, domicilio direccion)INSTANTIABLE NOT FINAL

CREATE TYPE cliente AS ( dni CHAR(12), nombre CHAR(40), telefono CHAR(20), domicilio direccion )INSTANTIABLE NOT FINAL

CREATE TYPE cartera_de_clientes AS ( vendedorAsignado REF(vendedor), cliente REF(cliente) )INSTANTIABLE NOT FINAL

1.2.6.2 Agregación y Composición

La implementación de la agregación es muy similar a la asociación. Pero se diferencia por tener una relación todo-parte, en la que desde el todo se puede tener acceso a las partes. En la Agregación, el todo no contiene físicamente a las partes, por ello, la implementación se hace a través de referencias a objetos.

Consideremos por ejemplo la relación de agregación entre una carrera y sus asignaturas, donde una carrera puede tener muchas asignaturas y una asignatura puede pertenecer a varias carreras. La implementación sería:

CREATE TYPE carrera AS ( Código CHAR(12), nombre CHAR(40), asignaturas REF(asignatura) ARR [100])INSTANTIABLE NOT FINALCREATE TYPE asignatura AS ( codigo CHAR(12), nombre CHAR(40), creditos NUMBER)INSTANTIABLE NOT FINAL

Si la agregación es uno a uno no necesitamos un arreglo, bastará con una referencia a la parte.

1.2.6.2 Agregación y Composición

Como en una composición las partes pertenecen a un único agregado (y se destruyen junto con él) la mejor estrategia es implementarla utilizando los tipos directamente.

Por ejemplo, consideremos la relación entre un círculo y un punto, donde un círculo posee un único punto que es su centro. La implementación sería:

CREATE TYPE circulo AS ( centro punto, radio NUMBER)INSTANTIABLE NOT FINAL

Si la multiplicidad de la composición es uno a muchos, la implementación es por medio de un arreglo. Por ejemplo, consideremos la relación entre un polígono irregular y los puntos (vértices) que lo componen. Esto sería:

CREATE TYPE polígono AS ( vertices punto ARR [100] )INSTANTIABLE NOT FINAL

1.2.6.3 Herencia y Polimorfismo

SQL: 1999 permite la herencia simple de tipos, es decir, un tipo puede poseer un único supertipo. La sintaxis es bastante sencilla.

Veamos el siguiente ejemplo:Consideremos un tipo figura_geométrica, con la siguiente definición:

CREATE TYPE figura_geometrica AS ( color_linea CHAR(10), color_fondo CHAR(10) )NOT FINAL METHOD area() RETURNS REALMETHOD perimetro() RETURNS REAL

A partir de este tipo, podemos definir dos subtipos triángulo y cuadrado, de la siguiente manera:

herencia...CREATE TYPE punto AS ( X REAL, Y REAL)INSTANTIABLE NOT FINALREF IS SYSTEM GENERATEDINSTANCE METHOD distanciaA(IN p Punto) RETURNS FLOAT

CREATE TYPE triángulo UNDER figura_geometrica AS ( a punto, b punto, c punto ) INSTANTIABLE NOT FINAL OVERRIDING METHOD area() RETURNS REAL OVERRIDING METHOD perimetro() RETURNS REAL

CREATE TYPE cuadrado UNDER figura_geometrica AS ( a punto, b punto, c punto, d punto ) INSTANTIABLE NOT FINAL OVERRIDING METHOD area() RETURNS REALOVERRIDING METHOD perimetro() RETURNS REAL

El nombre del supertipo se especifica anteponiendo la cláusula UNDER.

herencia...

• Una característica esencial de la herencia es que los atributos y métodos del supertipo pasan a formar parte del subtipo.

• Por lo anterior, no podemos definir el nombre de un atributo igual a otro que se haya heredado.

• Con respecto a los métodos, estos pueden ser redefinidos en el subtipo. Esto es lo que indica la cláusula OVERRIDING que precede a la definición de los métodos en los tipos triangulo y cuadrado.

• Al momento de crear el método, será necesario indicar que el método está siendo sobrescrito. Por ejemplo, una implementación del método area() para el tipo cuadrado sería;

CREATE OVERRIDING METHOD area() RETURNS REAL FOR cuadrado BEGIN

RETURN a.distanciaA(b) * b.distanciaA(c);END;

La redefinición y la sobrecarga de métodos son la base del polimorfismo soportado por el estándar.

herencia...

Otra característica de la herencia es que toda instancia de un subtipo, es una instancia de su supertipo directo y también de los indirectos.

Así tenemos que una instancia t del tipo triangulo también es una instancia del tipo figura_geométrica. Esto significa que la instancia t puede ser utilizada en cualquier lugar donde se espere una instancia del tipo figura_geométrica.

Por ejemplo, si tenemos una tabla que posea una columna del tipo figura_geométrica:

CREATE TABLE figuras ( id NUMBER PRIMARY KEY, fig figura_geometrica )

Podemos insertar una fila donde la columna fig almacene un cuadrado, y otra, donde almacene un triangulo, de la siguiente manera:

INSERT INTO figuras VALUES(1,cuadrado())INSERT INTO figuras VALUES(2,triangulo())

herencia...

Si hacemos una consulta sobre la tabla figuras y ejecutamos el método area() de la columna fig, el sistema determinará el método correspondiente, según el tipo concreto, en tiempo de ejecución.

SELECT id, fig.area() FROM figuras

Además de las columnas, existen otros casos donde podemos sustituir el valor de una instancia del supertipo, por un valor de su subtipo. Por ejemplo, en los parámetros de una función, método o procedimiento.

Al modificar un supertipo con la cláusula ALTER TYPE, estos cambios afectarán a sus subtipos.

Por ejemplo, si agregamos un atributo a la clase figuras_geometricas, automáticamente, se agrega el atributo a los subtipos, triangulo y cuadrado. Lo mismo pasa con los métodos.

1.2.7 Concurrencia

Como en las versiones anteriores, SQL: 1999 incluye el manejo de concurrencia. Varios usuarios pueden manipular un mismo objeto a la vez.

Otro aspecto de la concurrencia es que los métodos puedan ser concurrentes, ya sea en modo multihilo o multiproceso.

Si desarrollamos los métodos con SQL/PSM, no podremos contar con esta característica.

Pero si lo implementamos como una rutina externa, podremos utilizar algún lenguaje que soporte concurrencia, como Java o C.

1.2.8 Manejo de Versiones de objetos y configuraciones

No soportado en SQL:1999, pero prevista para SQL 2003 mediante la especificación SQL/Temporal (manejo de bases de datos históricas y también estas otras características).

1.2.9 Evolución de esquemas y de Instancias

La evolución de esquemas se refiere a la capacidad de modificar la estructura de los tipos, agregando, modificando o eliminando métodos o atributos y que estos cambios sean reflejados en todas las estructuras que dependan de ellos.

La evolución de instancias apunta a dos cosas, la primera es que al alterar un tipo, dicho cambio debe verse reflejado en las instancias y la otra es contar con la posibilidad de migrar instancias entre tipos.

La evolución de esquemas está soportada mediante la sentencia ALTER TYPE.

Evolución de esquemas y de Instancias…

La evolución de instancias no es soportada completamente, debido a las restricciones impuestas al predicado ALTER TYPE con respecto a los atributos. Pero utilizando tablas temporales, se puede simular

La migración de clases no es soportada directamente, pero podemos sacar una copia idéntica e insertarla en otra tabla, y eliminar el original. Esto es posible, gracias a la posibilidad de sobrescribir los OIDs al insertar.

1.2.10 Transacciones y recuperación ante fallosEl estándar implementa un robusto sistema de transacciones, incorporando en esta versión la noción de SAVEPOINT.

Con respecto a la recuperación ante fallos, es un aspecto que depende de la implementacion del estándar.

1.2.11 Mecanismos de AutorizaciónLos mecanismos de autorización están basados en las tablas y en los tipos. Se autoriza o restringe el acceso y manipulación de las tablas o tipos, como un todo, pero no se puede restringir el acceso sobre un objeto o una fila en particular

1.2.12 Compatibilidad con el modelo relacional

El estándar ofrece una alta compatibilidad con el modelo relacional, no sólo por soportarlo directamente, sino por permitir el mezclado de tablas relacionales y tablas que almacenan objetos.

Además podemos definir vistas de objetos sobre tablas relacionales, permitiendo definir una “capa” de orientación a objeto sobre nuestros datos relacionales. Las vistas de objeto también pueden ser creadas jerárquicamente.

Por ejemplo, consideremos la tabla persona:

CREATE TABLE persona( dni CHAR(12) PRIMARY KEY, nombre CHAR(40), fecha_nacim DATE )

Para definir una vista de objetos sobre esta tabla tendremos que definir un tipo que represente a una fila de la tabla persona.

CREATE TYPE tipo_persona AS ( dni CHAR(12), nombre CHAR(40), fecha_nacim DATE )INSTANTIABLE NOT FINAL INSTANCE METHOD edad()RETURNS REAL

Ahora, podemos crear una vista de objetos llamada persona_view de la siguiente manera:

CREATE VIEW persona_view OF tipo_persona REF IS oid SYSTEM GENERATEDAS (SELECT * FROM persona)

Esto facilita enormemente la migración de bases de datos relacionales a bases de datos orientadas a objeto, puesto que las aplicaciones actuales pueden continuar utilizando la tabla relacional, mientras que las nuevas aplicaciones orientadas a objeto podrán utilizar la vista de objeto, sin que se produzcan inconsistencias.

Otras mejoras de SQL:1999

A SQL3 se le ha llamado informalmente “SQL orientado a objetos”, pero SQL3 es más que SQL-92 más tecnología de objetos. Este nuevo estándar provee muchas mejoras sobre SQL-92 que no se limitan a la inclusión de los conceptos OO. Aparte de los nuevos tipos de datos y nuevos predicados, hay tres aspectos fundamentales de SQL:1999:

• Orientación a objetos, aquí se concentran las características denominadas objeto-relacionales y es donde hemos énfatizado.

• Bases de Datos Activas, lo cual se refleja en la especificación de triggers y assertions del estándar. Este aspecto lo cubrimos luego, cuando veamos el paradigma de base de datos activas.

• Nueva semántica, nos referimos específicamente a la habilidad de SQL3 de definir consultas recursivas, con lo cual se puede computar la clausura transitiva, eliminando así la restricción que existía en el álgebra relacional. El paradigma envuelto en esta nueva habilidad de SQL es el de Bases de Datos Deductivas.

Otras mejoras de SQL:1999 …Bases de datos activas

SQL: 1999 reconoce la noción de base de datos activa, aunque algunos años después que los SGBD lo hicieran. Esta facilidad es proporcionada a través de una característica conocida como disparador (trigger). Un disparador es una facilidad que les permite a los diseñadores de la base de datos instruir al sistema para ejecutar ciertos procedimientos cada vez que una aplicación realice operaciones específicas en tablas particulares. Por ejemplo inserción, borrado y actualización de tuplas.

Ejemplo: usar disparadores para registrar todas las operaciones que cambian el sueldo en una tabla empleado:

CREATE TRIGGER cambia_sueldo ( BEFORE UPDATE OF sueldo ON empeadoREFERENCING OLD ROW as viejo NEW ROW as nuevoFOR EACH ROWINSERT INTO tabla_registrarVALUES (CURRENT_USER, viejo.sueldo, nuevo.sueldo)

Otras mejoras de SQL:1999 …

semántica reforzada

Consultas recursivas en SQL:1999

El estandar SQL:1999 agrega una funcionalidad particular al lenguaje de consultas de bases de datos relacionales que permite elaborar algunas consultas que previamente parecían imposibles de construir sin un lenguaje de programación asociado. Este elemento es la recursión. Sin embargo, debido a su dificultad de implementación (y a la posibilidad de colgar facilmente una base de datos con una consulta que consuma demasiados recursos), muchas de las bases de datos disponibles en el mercado no la han implementado aún.Una destacable excepción es Postgres SQL, que a partir de la versión 8.4 la ha implementado.

Consultas recursivas en SQL:1999…El esquema general de una consulta en el estandar SQL:1999 pasa a ser el siguiente:

[WITH...]SELECT...FROM...(WHERE...)[GROUP BY...][HAVING...][ORDER BY...]

2. La clausula WITHLa clausula WITH de SQL:1999 permite definir nuevas tablas temporales para ser utilizadas por una consulta, y asignarles un nombre. Estas tablas temporales pueden contener datos ya existentes, que se obtienen mediante una consulta SQL, o datos nuevos, construyéndolos de manera recursiva. Asimismo, es con esta cláusula que se pueden realizar las consultas recursivas sobre una base de datos. Veamos una serie de ejemplos…

Se han parentizado aquellas expresiones tales que una consulta es válida aún sin ellas. (aunque el WHERE es especial dado que la mayor parte de las consultas útiles necesitan restringir las tablas)

Ejemplo: Usuarios de Banda Ancha (uso de With sin recursión)

Supongamos que una empresa de telecomunicaciones posee una BD que contiene (al menos) las siguientes dos tablas:

• clientes, que posee los campos dni, que identica al cliente, y producto que señala los productos contratados.

• documentos_impagos, registrando las boletas y facturas por pagar, con los campos cliente (donde se almacena el dni del cliente), fecha_pago con el vencimiento del documento, y monto, el total a pagar. La consulta:

WITH usuarios_bandaancha(dni) AS(SELECT DISTINCT dniFROM clientesWHERE producto LIKE '%Banda_Ancha%')SELECT *FROM documentos_impagos JOIN usuarios_bandaanchaON documentos_impagos.cliente=usuarios_bandaancha.dniWHERE fecha_pago <= (CURRENT_DATE - INTERVAL '3' MONTH);

crea una tabla temporal usuarios_bandaancha, de una columna, para obtener luego los usuarios que tienen cuentas impagas de más de tres meses.

Para utilizar recursión en SQL la cláusula WITH se utiliza de la siguiente manera:

WITH RECURSIVE nombretabla(<lista de columnas>) AS(<semilla>[UNION | INTERSECT] [ALL | DISTINCT]<paso recursivo>)

Se genera la tabla nombretabla con las columnas <lista de columnas>.La semilla es el conjunto de valores con los que se empezará la construccion de la tabla. Estos valores pueden obtenerse de una consulta (SELECT...) o insertándo valores.

Normalmente en SQL se construye el cuerpo de una nueva tabla mediante la instruccion INSERT INTO nombretabla VALUES..., pero como acabamos de definir nombretabla y sólo a ella nos referiremos, bastará utilizar VALUES...

Inicialmente nombretabla contiene “la semilla” y luego se aplicará la consulta del paso recursivo y su resultado se almacenará nuevamente en nombretablahasta que , según elijamos UNION o INTERSECT, no se agreguen o eliminen mas datos.

Ejemplo: Un Abuelo generoso (uso de With con recursión)

Un abuelo viejito, millonario y con mala memoria, quiere saber cuales de sus descendientes son mayores de edad para regalarles un automóvil a cada uno; para lo cual se acerca al Registro Civil donde usted es el encargado de la BD:Diseñe una consulta SQL para el abuelo, cuyo LE es 1.342.123, sabiendo quela tabla personas posee las columnas doc, edad, doc_padre y doc_madre.

Una posible solución, gracias a la recursion, es la siguiente:

WITH RECURSIVE parientes(doc, edad) AS ( ( SELECT doc, edad FROM personas WHERE doc_padre='1342123' ) UNION ALL ( SELECT personas.doc, personas.edad FROM personas, parientes WHERE (personas.doc_padre=parientes.doc) OR (personas.doc_madre=parientes.doc) ) )SELECT doc, nombre, edadFROM personas NATURAL JOIN parientesWHERE edad>=18;

Consultas recursivas en SQL:1999…Lista de números

Supongamos que queremos generar una lista con los números enteros entre el 100 y el 500, sin tener ninguna información previa en la base de datos. Dado que SELECT nos permite alterar los datos recibidos, podemos generar dicha lista mediante la siguiente consulta:

WITH RECURSIVE números(valor) AS ( VALUES (100) UNION ALL ( SELECT valor+1 FROM números WHERE valor<=500 ) ) SELECT * FROM números;

Consultas recursivas en SQL:1999…Loops Infinitos: Cuando se construyen consultas que utilizan recursión cabe la posibilidad de que nunca se dejen de agregar elementos en la tabla.

Esto puede ocurrir porque se generan datos nuevos, como será si en el ejemplo de la lista de números eliminamos la instruccion WHERE valor<=500 , o porque hay ciclos en los datos contenidos en la BD.

No hay una manera estandar sencilla para terminar la recursión en el primer caso, sin embargo, se ha definido un pequeño truco para detener la recursión en el segundo caso: Podemos asociar un grafo dirigido a la tabla que estamos construyendo en la que cada nodo corresponderá a una tupla en particular.

Caeremos en un loop si construimos nuevamente un nodo con una tupla que ya estaba en el grafo, o sea cuando en los caminos que se generan aparece un ciclo. Para evitar esto bastará ir marcando los caminos que se van recorriendo. Si se vuelve a pasar por un nodo previamente creado debemos detener la recursion. Para esto SQL:1999 nos provee la sentencia CYCLE que irá marcando los nodos durante la construccion de la nueva tabla.

Consultas recursivas en SQL:1999…

En general, CYCLE se usa de la manera siguiente:

WITH RECURSIVE nombretabla(columnas) AS ( semilla UNION [ALL|DISTINCT] recursión ) CYCLE columna_que_puede_provocar_loop SET marca_de_loop to 'S' DEFAULT 'N' USING camino_de_loop

Donde:columna_que_puede_provocar_loop está presente en el conjunto columnas

camino_de_loop será una columna temporal en la tabla nombretabla (que no está en el conjunto columnas), en la que iremos marcando los nodos. Esta no será parte de nombretabla luego de terminar la recursion.

marca_de_loop será el contenido de la columna camino_de_loop. En el ejemplo general utilizamos S y N. Podria ser cualquier marca con tal que tenga valores diferentes.

semántica reforzada del SQL:1999

Otra funcionalidad incorporada es la noción de savepoints. Ellos permiten, a una aplicación, deshacer las acciones realizadas después del principio de un savepoint sin deshacer todas las acciones de una transacción.

SQL:1999 permite ROLLBACK TO SAVEPOINT y RELEASE SAVEPOINT

1.1.2.4 seguridad adicional

La nueva característica de seguridad de SQL: 1999 se encuentra en su capacidad de creación de roles (o papeles). Pueden concederse privilegios a los roles y estos pueden ser identificadores de autorización individual o conceder privilegios de autorización a otros roles. Por ejemplo:

CREATE ROLE AdministradorCREATE ROLE Jefe_SupremoGRANT Administrador TO Miguel GRANT Administrador TO Jefe_Supremo

1.2.13 Limitaciones encontradas en SQL:1999

El estándar tiene las siguientes limitaciones:-No podemos sobrecargar las funciones observadoras y mutadoras-No podemos especificar un nivel de encapsulamiento (public, private, protected) sobre los atributos y métodos.-No podemos definir constructores-No podemos definir atributos estáticos-Sólo contamos con los arreglos para definir colecciones.-No podemos definir arreglos de múltiples dimensiones (por ejemplo matrices).-Los tipos de referencia sólo pueden almacenar direcciones de objetos persistentes.-No podemos crear módulos o paquetes de objetos.-No contamos con herencia múltiple.-No está soportado el manejo de versiones y configuraciones de objetos.-No podemos modificar la definición de un atributo ni la interfaz de los métodos.

1.3 EvaluaciónEvaluaremos la implementación que hace el estándar SQL: 1999del paradigma de la orientación a objeto. El objetivo de estaevaluación es determinar en qué porcentaje son soportadas lascaracterísticas de la orientación a objeto, por parte del estandarSQL:1999.1.3.1 Criterios de evaluaciónPara evaluar objetivamente el paradigma de la orientación a objetoen SQL- 1999, definimos un conjunto de criterios basados en lascaracterísticas del paradigma de la Orientación a Objeto y en losrequerimientos para las bases de datos orientadas a objeto.

Si la característica: Valoración

Está presente 100%

No está presente, pero se puede simular 60%

No está presente 0%

1.3.2 Matriz de evaluación

Características

1. Definición de tipos o clases

a. Definición de atributos estáticos 60%

b. Definición de atributos de instancia 100%

c. Constructores definidos por el usuario 100%

d. Métodos estáticos 100%

e. Métodos de instancia 100%

f. Sobrecarga de métodos 100%

g. Definición de colecciones 100%

h. Clases abstractas 100%

60%d. Visibilidad de atributos (Ej.: Public, private, protected)

60%c. Visibilidad de métodos (Ej. :Public, private, protected)

100%b. Distinguir entre interfaz e implementación

100%a. Atributos y métodos en una sola entidad

80,00%

2. Encapsulamiento

60%d. Herencia Múltiple

100%c. Herencia Simple

100%b. Agregación y Composición

100%a. Asociación

92,00%

4. Jerarquía de clases o tipos

60,00%3. Modularidad

100%100%a. Métodos con múltiples hilos de control

b. Concurrencia de usuarios.

100,00%5. Concurrencia

100%e. Polimorfismo

0,00%7. Versiones y configuraciones de objetos

100%e. Identificadores de objetos

100%d. Consulta

100%c. Eliminación

100%b. Modificación

100%a. Creación

100,00%6. Objetos Persistentes

100%j. Modificar Restricciones

100%i. Modificar Implementación de métodos

60%h. Modificar Interfaz de métodos

60%g. Modificar definición de atributos

100%f. Eliminar Restricciones

100%e. Eliminar Métodos

100%d. Eliminar Atributos

100%c. Agregar Restricciones sobre objetospersistentes

100%b. Agregar Métodos

100%a. Agregar Atributos

92,00%9. Evolución de esquemas

60,00%8. Evolución de instancias

78,25%Promedio

100%12. Compatibilidad con el modelo relacional.

60%11. Mecanismos de autorización basados en objetos

100%10. Transacciones y recuperación ante fallos

El estándar SQL:1999 está dividido en cinco documentos o partes:

Número de Documento Nombre del documento

1. ANSI/ISO/IEC 9075-1-1999Informatión Technology – Database Languages – SQL – part 1: Framework (SQL/Framework)

2. ANSI/ISO/IEC 9075-2-1999Information Technology – Database Languages – SQL – part 2: Foundation (SQL/ Foundation)

3. ANSI/ISO/IEC 9075-3-1999Information Technology – Database Languages –SQL – part 3: Call-level Interface (SQL/CLI)

4. ANSI/ISO/IEC 9075-4-1999Information Technology – Database Languages – SQL – part4: Persistent Stored Modules (SQL / PSM)

5. ANSI/ISO/IEC 9075-5-1999Information Technology – Database Languages – SQL – part 5: Host Language Bindings (SQL/Binding)

SQL/PSM

PSM= Persistent Stored Modules

Especifica facilidades para particionar una aplicación entre un cliente y un servidor.

Minimiza el tráfico en la red, por lo tanto ofrece mejor desempeño

Incluye Embedded SQL SQL/Temporal= para manejar datos históricos

Apéndice A: Sintaxis de SQL:1999 relacionada con la OOA.1 SimbologíaA.2 SentenciasA.2.1 Creación de tipos (CREATE TYPE)A.2.2 Definición de atributosA.2.3 Modificación de tipos (ALTER TYPE)A.2.4 Creación de métodos, funciones y procedimientosA.2.5 Modificación de métodos, funciones y procedimientosA.2.6 CAST definido por el usuarioA.2.7 Eliminación de un CASTA.2.8 Definición del ORDERING de un tipoA.2.9 Eliminación de un user definer orderingA.2.10 Funciones de transformación de tiposA.2.11 Eliminación de funciones de transformaciónA.2.12 Definición de Tablas (CREATE TABLE)A.2.13 Modificación de tablas (ALTER TABLE)A.2.14 Eliminación de tablas (DROP TABLE)A.2.15 Inserción de filas (INSERT INTO)A.2.16 Actualización de filas (UPDATE)A.2.17 Eliminación de filas (DELETE FROM)

Apéndice A: Sintaxis de SQL:1999 relacionada con la OO.

A.1 SimbologíaPara la descripción del lenguaje se utiliza una sintaxis extendida de la gramática BNF (Backus Normal Form o Forma normal de Backus).

En la gramática BNF, cada elemento sintáctico es conocido como un símbolo no terminal, el cual es definido por el significado de una regla de producción. Esto define el elemento en términos de una fórmula consistente de: caracteres, cadenas de caracteres, y elementos sintácticos.

La simbología es la siguiente:

Indica que el elemento que aparece antes de los puntos suspensivos, puede ser repetido nveces

. . .

Indica que la porción de la fórmula que aparece después de la barra esuna alternativa a la porción que precede a la barra.|

Las llaves agrupan elementos en una fórmula.{ }

Los corchetes indican que el elemento en una fórmula es opcional.[ ]

El operador de definición es utilizado en una regla deproducción para separar el elemento definido por la regla y sudefinición. A la izquierda del operador, aparece el símbolo noterminal, y a la derecha, la fórmula que lo define.

: : =

Las palabras encerradas en estos símbolos, representa un símbolo no terminal.

< >

SignificadoSímbolo

La sintaxis expuesta en este apéndice es tan sólo un extracto del estándar, por ser éste de gran tamaño (1.196 páginas).

A.2 SentenciasA.2.1 Creación de tipos (CREATE TYPE)Especifica un tipo de datos definido por el usuario. Formato:<user-defined type definition> ::= CREATE TYPE <user-defined type body><user-defined type body> ::= <user-defined type name> [<subtype clause> ] [ AS <representation> ] [<instantiable clause>] <finality>[<reference type specification> ] [<cast option> ][<method specification list> ]<subtype clause> ::= UNDER <supertype name> <supertype name> ::= <user-defined type><representation> ::= <predefined type>| <member list><member list>::= <left paren> <member> [ { <comma> <member> }... ] <right paren><member> ::= <attribute definition><instantiable clause> ::= INSTANTIABLE | NOT INSTANTIABLE <finality> : := FINAL | NOT FINAL

<reference type specification> ::= <user-defined representation> | <derived representation> | <system-generated representation><user-defined representation>::= REF USING <predefined type> [<ref cast option> ]<derived representation> : := REF FROM <list of attributes><system-generated representation> : := REF IS SYSTEM GENERATED<ref cast option>::= [<cast to ref> ] [<cast to type> ] <cast to ref> ::= CAST <left paren> SOURCE AS REF <right paren> WITH <cast to ref identifier><cast to ref identifier> ::= <identifier><cast to type> ::= CAST <left paren> REF AS SOURCE <right paren> WITH <cast to type identifier><cast to type identifier> ::=<identifier><list of attributes>::= <left paren> <attribute name> [ { <comma> <attribute name> }...] <right paren><cast option>::= [<cast to distinct>] [<cast to source> ]<cast to distinct> ::= CAST <left paren> SOURCE AS DISTINCT <right paren> WITH <cast to distinct identifier><cast to distinct identifier> : := <identifier><cast to source> ::= CAST <left paren> DISTINCT AS SOURCE <right paren> WITH <cast to source identifier><cast to source identifier> ::= <identifier>

<method specification list> ::= <method specification> [ { <comma> <method specification> }... ]<method specification>::= <original method specification> | <overriding method specification><original method specification> ::= <partial method specification> [SELF AS RESULT] [SELF AS LOCATOR] [<method characteristics>]<overriding method specification> ::= OVERRIDING <partial method specification><partial method specification>::= [INSTANCE | STATIC ] METHOD <method name> <SQL parameter declaration list> <returns clause> [SPECIFIC <specific name>]<method characteristics> ::= <method characteristic>...<method characteristic> ::= <language clause> | <parameter style clause> | <deterministic characteristic> | <SQL-data access indication> | <null-call clause> | <transform group specification> <language clause> ::= LANGUAGE <language name><language name>::= ADA |C |COBOL | FORTRAN | MUMPS | PASCAL | PLI | SQL

A.2.2 Definición de atributosDefine los atributos de un tipo estructurado Formato:<attribute definition>::=<attribute name> <data type> [<reference scope check>] [<attribute default>] [<collate clause> ]<attribute default> ::= <default clause><default clause> : := DEFAULT <default option><default option>::= <literal> | <datetime value function>| USER | CURRENT_USER | CURRENT_ROLE | SESSION_USER | SYSTEM_USER | CURRENT_PATH | <implicitly typed value specification>

A.2.3 Modificación de tipos (ALTER TYPE)Permite agregar y eliminar atributos o métodos. Formato:<alter type statement> ::=ALTER TYPE <path-resolved user-defined type name> <alter type action><alter type action> ::= <add attribute definition> | <drop attributedefinition> | <add original method specification> | <add overriding method specification> | <drop method specification><add attribute definition> ::= ADD ATTRIBUTE <attribute definition><drop attribute definition>::= DROP ATTRIBUTE <attribute name> RESTRICT <add original method specification> ::= ADD <original method specification><add overriding method specification> ::= ADD <overriding method specification><drop method specification>::= DROP <specific routine designator> RESTRICT<drop data type statement> ::= DROP TYPE <path-resolved user-defined type name> <drop behaviour><drop behaviour> : := CASCADE | RESTRICT

<specific routine designator>::= SPECIFIC <routine type> <specific name> | <routine type> <member name> [FOR <path-resolved user-defined type name> ]<routine type> ::= ROUTINE | FUNCTION | PROCEDURE | [INSTANCE | STATIC ] METHOD<member name> ::= <schema qualified routine name> [<data type list> ]<data type list> ::= <left paren> [<data type> [ { <comma> <data type> }... ] ] <right paren>

A.2.4 Creación de métodos, funciones y procedimientosPermite definir métodos, funciones y procedimientos almacenados. Formato:<SQL-invoked routine> ::= <schema routine><schema routine> ::= <schema procedure> | <schema function> <schema procedure> ::= CREATE <SQL-invoked procedure> <schema function> : := CREATE <SQL -invoked function><SQL-invoked procedure>::= PROCEDURE <schema qualified routine name> <SQL parameter declaration list> <routine characteristics><routine body><SQL-invoked function> ::= { <function specification> | <method specification designator> } <routine body><SQL parameter declaration list> ::= <left paren> [<SQL parameter declaration> [ { <comma> <SQL parameter declaration> }...]] <right paren><SQL parameter declaration> ::= [<parameter mode>] [<SQL parameter name>] <parameter type> [RESULT]<parameter mode> ::= IN | OUT | INOUT<parameter type> : := <data type> [<locator indication> ] <locator indication> : := AS LOCATOR

<function specification> ::= FUNCTION <schema qualified routine name> <SQL parameter declaration list> <returns clause><routine characteristics> [<dispatch clause> ]<method specification designator> ::= [INSTANCE | STATIC] METHOD <method name> <SQL parameter declaration list> [<returns clause> ] FOR <path-resolved user-defined type name><routine characteristics> : :=[ <routine characteristic>... ]<routine characteristic>::= <language clause> | <parameter style clause> | SPECIFIC <specific name> | <deterministic characteristic> | <SQL-data access indication> | <null-call clause> | <transform group specification> |<dynamic result sets characteristic> <dynamic result sets characteristic> ::= DYNAMIC RESULT SETS <maximum dynamic result sets><parameter style clause>::= PARAMETER STYLE <parameter style><dispatch clause> ::= STATIC DISPATCH<returns clause>::= RETURNS <returns data type> [<result cast> ]<result cast> ::= CAST FROM <result cast from type> <result cast from type>::= <data type> [<locator indication>]<returns data type> : := <data type> [<locator indication> ]

<routine body>::= <SQL routine body>| <external body reference><SQL routine body> ::= <SQL procedure statement><external body reference> ::= EXTERNAL [NAME <external routine name>] [<parameter style clause> ] [<external security clause>]<external security clause> ::= EXTERNAL SECURITY DEFINER |EXTERNAL SECURITY INVOKER | EXTERNAL SECURITY IMPLEMENTATION DEFINED <parameter style> ::= SQL | GENERAL<deterministic characteristic> ::= DETERMINISTIC | NOT DETERMINISTIC<SQL-data access indication> ::= NO SQL | CONTAINS SQL | READS SQL DATA | MODIFIES SQL DATA<null-call clause>::= RETURNS NULL ON NULL INPUT | CALLED ON NULL INPUT<maximum dynamic result sets> : := <unsigned integer><transform group specification> : := TRANSFORM GROUP{ <single group specification> | <multiple group specification> }<single group specification> ::= <group name><multiple group specification> ::=<group specification> [ { <comma> <group specification> }...]<group specification> ::=<group name> FOR TYPE <path-resolved user-defined type name>

A.2.5 Modificación de métodos, funciones y procedimientosPermite modificar la definición de una función, procedimiento o de un método.Formato:<alter routine statement> ::=ALTER <specific routine designator> <alter routine characteristics> <alter routine behaviour><alter routine characteristics> ::= <alter routine characteristic>...<alter routine characteristic> ::= <language clause> | <parameter styleclause> | <SQL-data access indication> | <null-call clause> | <dynamic result sets characteristic> | NAME <external routine name><alter routine behaviour> ::= RESTRICT<drop routine statement> ::= DROP <specific routine designator> <drop behaviour><specific routine designator>::= SPECIFIC <routine type> <specific name> | <routine type> <membername> [FOR <path-resolved user-defined type name> ] <routine type> ::= ROUTINE | FUNCTION | PROCEDURE | [INSTANCE | STATIC ] METHOD<member name> ::= <schema qualified routine name> [<data type list>]<data type list> ::= <left paren> [<data type> [ { <comma> <data type> }... ] ] <right paren>

A.2.6 CAST definido por el usuarioPermite crear un CAST definido por el usuario Formato:<user-defined cast definition> ::= CREATE CAST <left paren> <source data type> AS <target data type> <right paren> WITH <cast function> [AS ASSIGNMENT]<cast function> : := <specific routine designator> <source data type> ::= <data type><target data type> : := <data type><specific routine designator>::= SPECIFIC <routine type> <specific name> | <routine type> <member name> [FOR <path-resolved user-defined type name> ]<routine type> ::= ROUTINE | FUNCTION | PROCEDURE | [INSTANCE | STATIC ] METHOD<member name> ::= <schema qualified routine name> [<data type list> ]<data type list> ::= <left paren> [<data type> [ { <comma> <data type> }...]] <right paren>

A.2.7 Eliminación de un CASTPermite eliminar un CAST definido por el usuario Formato:<drop user- defined cast statement>::= DROP CAST <left paren> <source data type> AS <target data type> <right paren> <drop behaviour>A.2.8 Definición del ORDERING de un tipo.Define la forma en que el sistema debe comparar dos instancias de un mismo tipo. Formato:<user-defined ordering definition> : := CREATE ORDERING FOR <path -resolved user-defined type name> <ordering form><ordering form>::= <equals ordering form> | <full ordering form><equals ordering form> ::=EQUALS ONLY BY <ordering category> <full ordering form> ::=ORDER FULL BY <ordering category><ordering category>::= <relative category> | <map category> | <state category><relative category>::= RELATIVE WITH <relative function specification><map category>::=MAP WITH <map function specification>

<state category> : := STATE [<specific name>]<relative function specification> ::= <specific routine designator><map function specification> ::= <specific routine designator><specific routine designator>::= SPECIFIC <routine type> <specific name> | <routine type> <member name> [FOR <path-resolved user-defined type name> ]<routine type> ::= ROUTINE | FUNCTION | PROCEDURE | [INSTANCE | STATIC ] METHOD<member name> ::= <schema qualified routine name> [<data type list>]<data type list> ::= <left paren> [<data type> [ { <comma> <data type> }... ] ] <right paren>

A.2.9 Eliminación de un user definer orderingPermite eliminar la definición de un user definer ordering. Formato:<drop user-defined ordering statement> ::= DROP ORDERING FOR <path resolvedEuser-defined type name> <drop behaviour>A.2.1 0 Funciones de transformación de tiposPermite definir una o más funciones de transformación para tipos definidos por el usuario.Formato:<transform definition> ::= CREATE { TRANSFORM | TRANSFORMS } FOR <path-resolved user-defined type name> <transform group>...<transform group>::= <group name> <left paren> <transform element list> <right paren><group name> ::= <identifier><transform element list>::= <transform element> [<comma> <transform element> ]<transform element> : := <to sql> | <from sql> <to sql> ::= TO SQL WITH <to sql function> <from sql> : := FROM SQL WITH <from sql function> <to sql function> ::= <speciic routine designator> <from sql function> ::= <specific routine designator>

<specific routine designator>::= SPECIFIC <routine type> <specific name> | <routine type> <member name> [FOR <path-resolved user-defined type name> ] <routine type> ::= ROUTINE |FUNCTION | PROCEDURE | [INSTANCE | STATIC ] METHOD<member name> ::= <schema qualified routine name> [<data type list>]<data type list> ::= <left paren> [<data type> [ { <comma> <data type> }... ] ] <right paren>

A.2.1 1 Eliminación de funciones de transformaciónPermite eliminar funciones de transformación de tipos definidos por el usuario. Formato:<drop transform statement>::=DROP { TRANSFORM | TRANSFORMS } <transforms to be dropped> FOR <path-resolved user-defined type name> <drop behaviour><transforms to be dropped>::= ALL | <transform group element><transform group element> ::= <group name>A.2.1 2 Definición de Tablas (CREATE TABLE)Permite definir tablas, tanto relacionales como typed tables, subtablas, y supertablas.Formato:<table definition> ::= CREATE [<table scope> ] TABLE <table name> <table contents source> [ON COMMIT <table commit action> ROWS ]<table contents source>::= <table element list> | OF <user‑ defined type> [<subtable clause> ] [<table element list> ]<table scope> ::= <global or local> TEMPORARY <global or local> : := GLOBAL | LOCAL<table commit action> : := PRESERVE | DELETE

<table element list> ::= <left paren> <table element> [ { <comma> <table element> }... ] <right paren> <table element> ::= <column definition> | <table constraint definition>| <like clause> | <self-referencing column specification> | <column options><self-referencing column specification> ::= REF IS <self-referencing column name> <reference generation> <reference generation> ::=SYSTEM GENERATED | USER GENERATED | DERIVED<self-referencing column name> : := <column name><column options>::= <column name> WITH OPTIONS <column option list><column option list> ::= [<scope clause> ] [<default clause> ] [<column constraint definition>...] [<collate clause> ]<subtable clause> ::= UNDER <supertable clause> <supertable clause> : := <supertable name> <supertable name> ::= <table name><like clause> : := LIKE <table name><column definition> ::= <column name> { <data type> | <domainname> } [<reference scope check> ] [ { <default clause> | <identity column specification> } ] [<column constraint definition>... ][<collate clause> ]

<column constraint definition>::= [<constraint name definition> ] <column constraint> [<constraint characteristics> ]<column constraint> ::= NOT NULL | <unique specification>| <references specification> | <check constraint definition><reference scope check> ::= REFERENCES ARE [NOT ] CHECKED [ON DELETE <reference scope check action> ]<reference scope check action> ::= <referential action><identity column specification> ::= GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [<start and increment> ]<start and increment> ::= <left paren> <start or increment 1> [<comma> <start or increment 2>] <right paren><start or increment 1> ::= <start or increment> <start or increment 2> ::= <start or increment><start or increment>::= <start specification> | <increment specification><start specification> : := START WITH <start value><increment specification> ::= INCREMENT BY <increment><start value> ::= <signed numeric literal><increment> ::= <signed numeric literal><table constraint definition> ::= [<constraint name definition>] <table constraint> [<constraint characteristics> ]

<table constraint>::=<unique constraint definition> | <referential constraint definition> | <check constraint definition><unique constraint definition> ::=<unique specification> <left paren> <unique column list> <right paren> | UNIQUE ( VALUE)<unique specification> ::= UNIQUE | PRIMARY KEY<unique column list> : := <column name list><referential constraint definition>::=FOREIGN KEY <left paren> <referencing columns> <right paren> <references specification><references specification> ::=REFERENCES <referenced table and columns> [MATCH <match type>][<referential triggered action>]<match type> : := FULL | PARTIAL | SIMPLE <referencing columns> ::= <reference column list><referenced table and columns> ::=<table name> [<left paren> <reference column list> <right paren> ]

<reference column list> : := <column name list><referential triggered action> : : = <update rule> [<delete rule>] | <delete rule> [ <update rule>]<update rule> ::= ON UPDATE <referential action> <delete rule> : := ON DELETE <referential action><referential action> ::= CASCADE | SET NULL | SET DEFAULT | RESTRICT | NO ACTION<check constraint definition>::= CHECK <left paren> <search condition> <right paren>

A.2.1 3 Modificación de tablas (ALTER TABLE)Permite cambiar la definición de una tablas. Formato:<alter table statement> ::= ALTER TABLE <table name> <alter table action><alter table action>::= <add column definition> | <alter columndefinition> | <drop column definition> | <add table constraint definition> | <drop table constraint definition><add column definition>::= ADD [COLUMN] <column definition><alter column definition> ::= ALTER [ COLUMN] <column name> <alter column action><alter column action>::= <set column default clause> | <drop column default clause> | <add column scope clause> | <drop column scope clause><set column default clause> : := SET <default clause><drop column default clause> ::= DROP DEFAULT<add column scope clause> ::= ADD <scope clause> <drop column scope clause> ::= DROP SCOPE <drop behaviour><drop column definition>::= DROP [COLUMN] <column name> <drop behaviour><add table constraint definition> ::= ADD <table constraint definition><drop table constraint definition>::= DROP CONSTRAINT <constraint name> <drop behaviour>

A.2.14 Eliminación de tablas (DROP TABLE)Permite eliminar una tabla. Formato:<drop table statement> ::= DROP TABLE <table name> <drop behaviour>A.2.1 5 Inserción de filas (INSERT INTO)Permite insertar una fila en una tabla. Formato:<insert statement>::= INSERT INTO <insertion target> <insert columns and source><insertion target> ::=<table name><insert columns and source> ::= <from subquery> | <from constructor> | <from default><from subquery> ::= [<left paren> <insert column list> <right paren> ] [override clause>] <query expression><from constructor> ::= [<left paren> <insert column list> <right paren> ] [<override clause>] <contextually typed table value constructor><override clause> ::= OVERRIDING USER VALUE | OVERRIDING SYSTEM VALUE

<from default> ::= DEFAULT VALUES<insert column list> ::= <column name list> <contextually typed table value constructor> ::= VALUES <contextually typed row value expression list><contextually typed row value expression list>::= <contextually typed row value expression> [{ <comma> <contextually typed row value expression> }... ]<contextually typed row value expression> ::= <row value special case> | <contextually typed row value constructor><row value special case>::= <value specification> | <value expression>

A.2.1 6 Actualización de filas (UPDATE)Permite modificar el contenido de una fila existente. Formato:<update statement: searched> ::= UPDATE <target table> SET <set clause list> [WHERE <search condition>]<set clause list> ::= <set clause> [ { <comma> <set clause> }...]<set clause> ::= <update target> <equals operator> <update source> | <mutated set clause> <equals operator> <update source><update target> ::= <object column> | <object column><left bracket or trigraph> <simple value specification> <right bracket or trigraph><object column> ::= <column name><mutated set clause> ::= <mutated target> <period> <method name><mutated target> ::= <object column> | <mutated set clause><update source> ::= <value expression> | <contextually typed value specification>

A.2.1 7 Eliminación de filas (DELETE FROM)Permite modificar el contenido de una fila existente. Formato: <delete statement: searched> ::= DELETE FROM <target table> [WHERE <search condition>]<target table>::= <table name> | ONLY <left paren> <table name> <right paren>

repaso y ampliación del paradigma de la orientación a objeto en sql:1999 capacidades y...

Documents