Modelo objeto-relacional en Oracle ÍNDICE

Modelo objeto-relacional en
Oracle
Modelos Avanzados de Bases de
Datos
Práctica 2
ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
1

ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
LOBS
• El tipo de datos predefinido LOB (Large
OBjects) permite manejar las necesidades de
almacenamiento de imágenes, videos,
documentos y en general, cualquier tipo de dato
no estructurado y de tamaño grande.
• Los datos no estructurados no se pueden
descomponer en unidades de información más
pequeñas y manejables.
• Los datos multimedia probablemente ocupe
miles de veces ese espacio. Por ello, con el fin
de minimizar el espacio de almacenamiento en
la BD
2

LOBS
• Generalmente la información recogida por un LOB se
guardará en ficheros que serán manejados por el
sistema de ficheros del sistema operativo
• En el campo correspondiente al valor de tipo LOB habrá
un puntero que permitirá acceder al contenido de dicho
fichero.
• Oracle puede almacenar en la misma tabla LOBs
pequeños, de hasta 4K de tamaño. Cuando el LOB
supera ese tamaño, el SGBD lo almacena fuera de la
tablay pone en su lugar el localizador que permita
acceder a la nueva ubicación de los datos.
• Así, los LOBs son capaces de almacenar hasta 4G de
datos; además, se pueden definir varias columnas de
tipo LOB en una misma tabla, así como varios atributos
de un tipo de objeto pueden ser de tipo LOB.
LOBS
• Los LOBs se dividen básicamente en dos
subtipos:
– INTERNOS: aquellos que se almacenan en los
espacios de tabla (tablespaces) de la propia BD:
BLOB (Binary Large OBjects), compuestos de datos
binarios no estructurados, y los CLOB (Character
Large OBjects) y NCLOB (National Character Large
OBjects), que almacenan datos de tipo carácter;
– EXTERNOS: los que almacena el sistema de ficheros
del sistema operativo. Los únicos LOBs externos son
los BFILEs, que son grandes cantidades de datos
binarios. Una columna o un atributo de tipo BFILE
almacena un puntero al comienzo del fichero que
contiene los datos.
3

• Ejemplo:
LOBS
CREATE TABLE Plano
( planoID INTEGER PRIMARY KEY,
fecha_fin DATE,
gráfico BFILE);
ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
4

TIPOS ANY
• Oracle permite crear variables y columnas que
pueden almacenar datos de cualquier tipo,
permitiendo comprobar el valor de ese dato en
cualquier momento;
• De este modo se puede ver su representación
subyacente, es decir, el tipo concreto del dato.
• Empleando este tipo de datos, una misma
columna puede almacenar en una fila un valor
numérico, en otra fila una cadena de caracteres
y en otra un objeto.
TIPOS ANY
• Existen tres tipos de datos que permiten el
tipado dinámico:
– SYS.ANYDATA, que almacena un valor de
cualquier tipo escalar o tipo de objeto,
– SYS.ANYDATASET, que almacena valores
de cualquier tipo colección y finalmente, el
– SYS.ANYTYPE que permite manipular y
comprobar información de tipos.
5

• Ejemplo
CREATE TABLE tabla
(un_valor SYS.AnyData);
TIPOS ANY
INSERT INTO tabla
VALUES (SYS.AnyData.ConvertNumber(5));
CREATE TYPE tipoEmpleado AS OBJECT(
numE INTEGER,
nombre VARCHAR (20))
/
INSERT INTO tabla
VALUES (SYS.AnyData.ConvertObject(tipoEmpleado(5555,
‘Pepe’)));
ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
6

TIPOS DEFINIDOS POR EL
USUARIO
• Al igual que el estándar SQL:2003, Oracle
soporta dos clases de tipos definidos por
el usuario:
– los tipos distintos y
– los tipos estructurados
ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
7

TIPOS DISTINTOS
• En SQL-92 las columnas de una tabla se definían
mediante tipos de datos primitivos.
• Dos columnas, con distinta semántica y por tanto,
distinto comportamiento, podían estar definidas bajo el
mismo tipo de datos compartiendo, por tanto, la misma
representación.
• Esto daba lugar a incompatibilidades y errores, ya que,
por ejemplo, se podía igualar el atributo LongSala a
AreaSala, si ambos eran de tipo INTEGER. Sin
embargo, esta asignación es semánticamente
incorrecta, ya que estos atributos tienen un significado y
un comportamiento distinto.
TIPOS DISTINTOS
• Con los tipos distintos se resuelve este
problema. Se usan cuando dos tipos de
datos comparten una misma
representación pero tienen distinto
comportamiento.
• La definición de tipos distintos se basa en
el renombrado de tipos, de tal modo que
el tipo distinto no es comparable con el
tipo fuente.
8

SQL:2003
TIPOS DISTINTOS
CREATE TYPE tipoSala
AS CHAR(10) FINAL;
CREATE TYPE tipoMetros
AS INTEGER FINAL;
CREATE TYPE tipoMetrosCuad
AS INTEGER FINAL;
CREATE TABLE Sala (
IdSala tipoSala,
LongSala tipoMetros,
AnchoSala tipoMetros,
AreaSala tipoMetrosCuad,
PerimSala tipoMetros));
ÍNDICE
Incorrecto
UPDATE Sala
SET AreaSala=LongSala;
Correcto
UPDATE Sala
SET AnchoSala=LongSala;
• LOBS
• TIPOS ANY
• URI TYPES
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS DISTINTOS
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
9

TIPOS ESTRUCTURADOS
• Se utilizan:
– como tipos de una columna,
– como tipos de un atributo de otro tipo definido por el
usuario o
– como el tipo de una tabla.
• Cuando se utilizan como el tipo de una columna
o de un atributo, son tipos de datos valor;
• Cuando se utilizan como el tipo de una tabla se
convierten en tipos de objetos.
TIPOS ESTRUCTURADOS
• Se definen mediante la cláusula
CREATE TYPE AS OBJECT,
• tanto para definir un tipo de dato valor,
como para definir un tipo de objeto.
• Lo que determinará si se trata de un tipo
de dato valor o un tipo de objeto es el que
dicho tipo se utilice como el tipo de una
columna (o un atributo) o como el tipo de
una fila.
10

TIPOS ESTRUCTURADOS
• Un ejemplo de tipo estructurado, utilizado como
tipo de dato valor en Oracle (ya que se utiliza en
la definición de una columna de una tabla
relacional ):
CREATE OR REPLACE TYPE tipoDireccion AS OBJECT(
calle VARCHAR2 (30),
ciudad VARCHAR2 (20),
provincia VARCHAR2 (2),
CP VARCHAR2 (5))
/
CREATE TABLE Persona (
nombre VARCHAR2(30),
vive_en tipoDireccion,
foto BLOB);
TIPOS ESTRUCTURADOS
• Un tipo de objeto se define igual que un tipo
estructurado. La diferencia radica en que no se
usa como el tipo de una columna, sino como el
tipo de una tabla tipada.
CREATE OR REPLACE TYPE tipoEmpleado AS OBJECT
( DNI NUMBER,
nombre VARCHAR2(30),
fecha_nac DATE)
/
CREATE TABLE Empleado OF tipoEmpleado;
11

TIPOS ESTRUCTURADOS
• En este caso, el tipo estructurado
tipoEmpleado, es un tipo de objeto, ya que
se utiliza como el tipo de la tabla
Empleado.
• Así, la definición del tipo especifica la
intensión (o estructura del mismo)
mientras que la extensión se definirá
mediante la creación de una tabla tipada.
TIPOS ESTRUCTURADOS
• Igualmente, pueden crearse varias tablas
sobre un mismo tipo estructurado.
– La tabla tendrá una columna por cada atributo
del tipo,
– además de la columna REF;
– sus filas van a ser las instancias de los
objetos del tipo de objeto.
– Las restricciones (de clave primaria, unicidad,
etc.) se definen sobre la tabla, no sobre el
tipo.
12

ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
TIPOS REF
• Un tipo referencia (REF) es un tipo de
datos que contiene el valor del atributo
REF (que se correspondería con el OID)
de una fila de una tabla tipada.
• REF, en realidad, es un constructor de
tipo, ya que existe un tipo REF por cada
tabla tipada.
13

TIPOS REF
• Así, en el ejemplo de la figura, la columna REF
contendrá valores del tipo REF (tipoPropiedad).
• El tipo referencia permite implementar relaciones
prescindiendo de la utilización de claves ajenas. Un
atributo definido como de tipo referencia contendrá el
valor del atributo REF del objeto referenciado.
PROPIEDADES
REF precio num_habitaciones tamaño ubicación
TIPOS REF
calle ciudad provincia CP
• En la siguiente sentencia SQL se puede ver la
creación de un tipo tipoPropiedad que contiene
un atributo, propietario, de tipo referencia al tipo
estructurado tipoPersona.
CREATE TYPE tipoPropiedad AS (
propietario REF (tipoPersona),
precio INTEGER,
num_habitaciones INTEGER,
tamaño DECIMAL (8,2),
ubicacion tipoDireccion);
CREATE TABLE Propiedades OF tipoPropiedad;
14

TIPOS REF
• Un tipo estructurado tiene un tipo referencia
correspondiente.
• Un tipo referencia puede ser usado en cualquier sitio
donde pueda ser usado otro tipo de datos.
• Aunque el tipo REF nos va a permitir implementar
relaciones entre tipos de objetos, hay que tener en
cuenta que el tipo referencia no tiene la misma semántica
que la clave ajena.
• Mientras que la clave ajena implica una dependencia de
inclusión, debido a la restricción de integridad referencial,
el tipo REF no, permitiéndose la posibilidad de
referencias que no apunten a ninguna parte (son las
denominadas “dangling references”).
• Además, el tipo REF soporta la noción de tipado fuerte
que no va ligada a una clave ajena; de este modo, un
atributo de tipo REF puede, por ejemplo, usarse como
parámetro en la llamada de un método.
TIPOS REF
• Los tipos referencia permiten navegar de una tabla a
otra, eliminando la necesidad de joins del modelo
relacional.
CREATE OR REPLACE TYPE tipoDepartamento AS OBJECT
( nombre_Dep VARCHAR2(30))
/
CREATE OR REPLACE TYPE tipoEmpleado AS OBJECT
( DNI NUMBER,
nombre VARCHAR2(30),
fecha_nac DATE,
pertenece_a REF tipoDepartamento)
/
CREATE TABLE Departamento OF tipoDepartamento;
CREATE TABLE Empleado OF tipoEmpleado;
15

TIPOS REF
• De este modo, las relaciones podrán seguir
implementándose mediante claves ajenas, o bien
utilizar referencias.
• Para las consultas que involucren a dos tablas, en
el primer caso se seguirán realizando mediante
joins, mientras que en el caso de haberlas
relacionado mediante referencias se realizarán
utilizando la notación “punto”:
SELECT nombre, e.pertenece_a.nombre_Dep
FROM Empleado e
WHERE DNI=9687452;
que devolvería el nombre del empleado con DNI
9687452, así como el nombre del departamento al
que pertenece.
ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
16

MÉTODOS
• Es posible asociar comportamiento a los tipos
de objetos, definiendo la cabecera de los
métodos como parte de la definición del tipo:
CREATE OR REPLACE TYPE tipoEmpleado AS OBJECT
( DNI NUMBER,
nombre VARCHAR2(30),
fecha_nac DATE,
pertenece_a REF tipoDepartamento,
MEMBER FUNCTION edad RETURN NUMBER)
/
CREATE TABLE Empleado OF tipoEmpleado;
MÉTODOS
• Los métodos de un tipo se declaran como
funciones miembro y no como métodos. El
cuerpo del método se define por separado.
CREATE TYPE BODY tipoEmpleado AS
MEMBER FUNCION edad RETURN NUMBER IS
BEGIN
...
RETURN edad;
END;
END;
/
17

MÉTODOS
• Los métodos reciben siempre como parámetro
implícito la lista de atributos del tipo de objeto al
que pertenecen.
• La palabra reservada a través de la cual un
método se refiere a dichos atributos es SELF.
Así, por ejemplo, SELF.nombre, hace referencia
al nombre de un empleado concreto.
• Puede existir sobrecarga en la definición de
métodos. Es decir, puede haber dos métodos
que se llamen igual siempre que sus parámetros
formales varíen en número, orden o tipo de
dato.
MÉTODOS
• Cada tipo de objeto tiene un método
constructor; se trata de una función definida por
el sistema con el mismo nombre que el tipo de
objeto.
• El constructor inicializa y devuelve una instancia
del tipo de objeto.
• Los parámetros formales que recibe el
constructor son los atributos, en el mismo orden
que se han definido, del tipo de objeto.
18

ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
HERENCIA
• Oracle 8 no soportaba una de las características
más importantes de la orientación al objeto, la
herencia. Desde la versión 9i de Oracle se
incorpora ya la herencia simple de tipos, pero
no soporta la herencia de tablas.
• El tipo raíz de una jerarquía se crea empleando
la sentencia CREATE TYPE y debe ser
declarado como NOT FINAL. La opción por
defecto es FINAL (indicando así, que pueden
derivarse subtipos de él).
19

HERENCIA
CREATE TYPE tipoPersona AS
OBJECT
(DNI VARCHAR(9),
nombre VARCHAR(25),
fecha_nac DATE,
direccion VARCHAR(1000),
MEMBER FUNCTION edad
RETURN NUMBER)
NOT INSTANTIABLE NOT FINAL
/
CREATE TYPE tipoEstudiante UNDER
tipoPersona
(estudios VARCHAR(50))
/
CREATE TYPE tipoEmpleado UNDER
tipoPersona
(empresa VARCHAR(50))
/
Estudiante
estudios: String
HERENCIA
Persona
DNI: String
nombre: String
fecha_nac: Date
direccion: String
edad(): Integer
Empleado
empresa: String
• La herencia simple de tipos que contempla
Oracle implica que cualquier subtipo hereda de
su padre los métodos y atributos que posea.
• Así, para el ejemplo presentado, los subtipos
tipoEstudiante y tipoEmpleado poseen los dos la
función edad().
• Por tanto, esta función podrá ser invocada sobre
cualquier instancia de estos tipos, es decir,
cuando se defina una tabla de cualquiera de los
dos subtipos, podremos llamar a la función
edad() sobre cualquiera de las filas de la tabla
(que no son sino objetos).
20

HERENCIA
• La característica [NOT] FINAL permite
indicar si la clase puede tener subclases o
no
• La característica [NOT] INSTANTIABLE
permite indicar si la clase va a poder
instanciarse o no.
HERENCIA
• Es muy importante tener en cuenta que Oracle
no soporta la herencia de tablas; es decir, la
definición de jerarquías de tablas sobre tipos
que están integrados en una jerarquía de tipos.
• Oracle sólo permite asegurar que los atributos y
métodos del supertipo de la tabla padre, se
heredarán en las tablas definidas sobre los
subtipos.
• Sin embargo, las restricciones, disparadores,
etc. definidos para una tabla no podrán ser
heredados por otras tablas, aunque sus tipos
subyacentes pertenezcan a la misma jerarquía.
21

HERENCIA
• A continuación se muestran las sentencias para
crear las tablas del tipo padre y de los dos
subtipos.
• Es necesario definir en cada tabla sus propias
restricciones, ya que éstas no se propagan:
CREATE TABLE Persona OF tipoPersona
(PRIMARY KEY (DNI),
CHECK(direccion like (‘%Madrid%’)));
CREATE TABLE Estudiante OF tipoEstudiante
(PRIMARY KEY (nombre));
CREATE TABLE Empleado OF tipoEmpleado
(PRIMARY KEY (DNI));
HERENCIA
• Las tablas Estudiante y Empleado definidas sobre
subtipos del tipo tipoPersona no deben cumplir en
absoluto las restricciones impuestas para la tabla
Persona definida sobre el tipo padre TipoPersona.
• Así, por ejemplo, podemos insertar en la tabla Empleado
una fila en la que el valor del atributo direccion no
contenga la cadena ‘Madrid’, mientras que en la tabla
Persona nos sería imposible.
• Así mismo, podemos definir el campo nombre como
clave primaria en la tabla Estudiante, aunque en la tabla
padre Persona la clave primaria se definió sobre el
campo DNI.
22

HERENCIA
• Pero, además de que las tablas no hereden las
restricciones de la tabla definida para el supertipo, existe
un problema aun mayor, y es que con el ejemplo
anterior, no podemos recoger el hecho, implícito en toda
jerarquía, de que todo estudiante es persona y de que
todo empleado es persona.
• Esto es debido a que no existe relación alguna entre las
tablas, no hay nada que le indique al SGBD que un
empleado o un alumno es también una persona. Por
ello, al realizar una consulta a persona, obtendríamos
sólo aquellas personas que no fueran ni estudiantes ni
empleados.
HERENCIA
• De este modo, para la implementación de
una jerarquía en Oracle, aunque podamos
apoyarnos en ocasiones en la utilización
de la herencia de tipos, necesitamos
además recurrir a los clásicos
mecanismos empleados en relacional
(claves ajenas, o referencias, entre las
tablas, restricciones, vistas, etc.).
23

ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
TIPOS COLECCIÓN
• Oracle soporta dos tipos de colecciones: VARRAY y
NESTED TABLE.
• El tipo VARRAY es un tipo de longitud variable; es decir,
se almacena sólo la longitud ocupada del array.
CREATE OR REPLACE TYPE tipoTelefono
AS VARRAY (3) of VARCHAR(10)
/
CREATE TABLE Empleado
( DNI NUMBER,
nombre VARCHAR2(30),
telefonos_contacto tipoTelefono);
INSERT INTO Empleado
VALUES (‘9876543’, ‘Pepe’, tipoTelefono (‘914445566’, ‘606445566’,
‘934445566’));
24

TIPOS COLECCIÓN
• Desde una sentencia SELECT no es
posible acceder a los elementos
individuales del VARRAY indexándolos;
• Para el tratamiento individual de cada
elemento del VARRAY, es necesario
hacerlo mediante PL/SQL, que
proporciona cláusulas para posicionarse
en los distintos elementos del array.
TIPOS COLECCIÓN
• Oracle soporta otro tipo de datos colección que
son las tablas anidadas o NESTED TABLES.
• Es posible definir un tipo de datos como una
tabla, y utilizar dicho tipo como el tipo de datos
de la columna de otra tabla.
• De este modo, la columna contendrá una
colección de valores, objetos o referencias, que
se almacenarán en formato de tabla.
• Aunque Oracle almacena las filas de una
NESTED TABLE sin orden, al recuperarlas es
posible referirse a ellas según un orden de
indexación que empieza en el 1.
25

TIPOS COLECCIÓN
CREATE TYPE tipoNombres AS VARRAY(5) OF vARCHAR(20)
CREATE TYPE tipoPlano AS OBJECT
( plano_ID NUMBER,
num_figuras NUMBER,
arquitectos tipoNombres)
CREATE TABLE Plano OF tipoPlano
(PRIMARY KEY (plano_Id));
CREATE OR REPLACE TYPE refTipoPlano AS OBJECT
(refPlano REF tipoPlano)
CREATE OR REPLACE TYPE NT_Planos AS TABLE OF
refTipoPlano
CREATE OR REPLACE TYPE tipoProyecto AS OBJECT
( proyecto_ID NUMBER,
nombre VARCHAR(30),
tiene_plano NT_Planos)
/
CREATE TABLE Proyecto OF tipoProyecto
(PRIMARY KEY (proyecto_ID),
UNIQUE (nombre))
NESTED TABLE tiene_plano STORE AS ListaPlanos;
INSERT INTO Plano VALUES (1, 5,NULL);
INSERT INTO Plano VALUES (2, 4,NULL);
DECLARE
p1_ref refTipoPlano;
p2_ref refTipoPlano;
--Se utilizan referencias a los dos nuevos
--planos para introducir valores en la tabla
--anidada creada
BEGIN
SELECT refTipoPlano(REF(p1)) INTO p1_ref
FROM Plano p1 WHERE p1.plano_id=1;
SELECT refTipoPlano(REF(p2)) INTO p2_ref
FROM Plano p2 WHERE p2.plano_id=2;
INSERT INTO Proyecto
VALUES (1, 'MIDAS', NT_Planos (p1_ref, p2_ref));
END;
/
TIPOS COLECCIÓN
• Al definir una tabla tipada que contiene un atributo que
es de tipo tabla, es necesario darle un nombre de
almacenamiento a la NESTED TABLE mediante la
cláusula STORE AS que es un nombre interno y no se
puede utilizar para acceder directamente a la tabla
anidada.
• La tabla anidada es un tipo colección y funciona como
tal. Por tanto, el acceso a sus miembros (bien para
inserción, borrado o consulta) es necesario hacerlo a
través de la tabla principal.
SELECT P.proyecto_ID, Pl.refplano.Plano_ID,
Pl.refplano.num_figuras
FROM Proyecto P, TABLE(P.tiene_plano) Pl
WHERE P.Nombre='MIDAS';
26

TIPOS COLECCIÓN
• Las principales diferencias entre los tipos
colección VARRAY y NESTED TABLE son:
– Los VARRAYS tienen un tamaño máximo fijo que se
especifica en la definición del tipo, mientras que las
NESTED TABLES son de tamaño variable (no se
dimensionan).
– A la hora del almacenamiento en la base de datos,
los VARRAYS se guardan en el mismo espacio que
la tabla. Sin embargo, las NESTED TABLES se
almacenan como otra tabla independiente asociada a
la tabla sobre la que está definida, pero sobre la que
solo se pueden realizar consultas a través de la tabla
en la que esta definida.
TIPOS COLECCIÓN
• Cuando se necesite emplear un tipo colección, a la hora
de elegir entre una NESTED TABLE o un VARRAY hay
varios criterios a seguir
– Si el orden en que se almacenan los elementos de la colección
es relevante, se emplea un VARRAY, puesto que la NESTED
TABLE no conservan el orden.
– En caso de saber de antemano el número de elementos que
tendrá la colección, se emplea un VARRAY porque permite
limitar su tamaño en el momento de su definición.
– En general, si el tamaño y el orden no son especialmente
relevantes: si se necesitan consultas sobre la colección, que nos
permitan tratar los elementos de la colección por separado, se
emplea una NESTED TABLE, mientras que si se desea
recuperar la colección como un todo, se empleará un VARRAY,
aunque también se permitiría el acceso a los elementos
individuales.
27

ÍNDICE
• LOBS
• TIPOS ANY
• TIPOS DEFINIDOS POR EL USUARIO
– TIPOS ESTRUCTURADOS
– TIPOS REF
– MÉTODOS
– HERENCIA
– TIPOS COLECCIÓN: NESTED TABLES Y VARRAYS
– EVOLUCIÓN DE TIPOS
EVOLUCIÓN DE TIPOS
• La evolución de tipos es un mecanismo que permite al usuario
cambiar la definición de un tipo y propagar esos cambios a otros
objetos del esquema que usen el tipo modificado.
• Estos objetos se denominan dependientes del tipo y pueden ser,
por ejemplo, una tabla, otro tipo o subtipo, una unidad de
programación o bloque PL/SQL (procedimiento, función, paquete o
disparador), etc.
• La evolución de tipos permite realizar las siguientes modificaciones
sobre un tipo definido por el usuario:
– Añadir y eliminar atributos.
– Añadir y eliminar métodos.
– Modificar un atributo de tipo numérico, cambiando su longitud, precisión
o escala.
– Modificar un atributo de tipo carácter de tamaño variable, para
incrementar el tamaño que admite.
– Cambiar las propiedades final e instantiable de un tipo.
28

EVOLUCIÓN DE TIPOS
• Pero, ¿qué sucede con un objeto dependiente cuando
se modifica el tipo del que depende? Esto estará en
función de la naturaleza del objeto y de la modificación
efectuada.
• Por ejemplo, si el objeto es una tabla, por cada atributo
añadido al tipo se añaden a la tabla una o varias
columnas, según el tipo del nuevo atributo añadido al
tipo (esos nuevos atributos se añaden con valor nulo).
• En el caso de eliminar atributos en el tipo, las columnas
del objeto dependiente asociadas con esos atributos son
eliminadas, y si lo que se hace es modificar la definición
del atributo (escala, tamaño...), se realizan las mismas
modificaciones en las columnas del objeto dependiente
asociadas con dicho atributo.
EVOLUCIÓN DE TIPOS
• Introducir estas modificaciones en los objetos
dependientes requiere:
– por un lado, modificar los metadatos (información
sobre la estructura de una tabla, que describe sus
columnas y los tipos de éstas), lo cual no consume
demasiado tiempo, y,
– por otro, modificar los datos de la tabla para reflejar la
redefinición del tipo; si hay una gran cantidad de
datos, esta modificación puede consumir una
importante cantidad de tiempo, por ello, Oracle
proporciona opciones para la sentencia ALTER TYPE
(empleada para redefinir un tipo), que posponen
estas modificaciones en los datos hasta que sean
actualizados.
29

EVOLUCIÓN DE TIPOS
• En cualquier caso, Oracle siempre devuelve los datos de
una tabla en el formato especificado por la última
versión del tipo.
• Así, si la tabla está aún almacenada en el formato de
una versión anterior del tipo, Oracle convierte los datos
antes de devolverlos, aunque el formato en que están
almacenados no cambia hasta que los datos sean
reescritos.
• En el ejemplo siguiente se cambia el tipo tipoPersona,
añadiéndole un atributo y eliminando otro.
• La palabra clave CASCADE propaga el cambio a los
tipos y tablas dependientes, mientras que la cláusula
NOT INCLUDING TABLE DATA pospone la conversión
de los datos de esas tablas dependientes hasta que se
reescriban.
EVOLUCIÓN DE TIPOS
CREATE TYPE tipoPersona AS OBJECT
( nombre VARCHAR(30),
apellidos VARCHAR(30),
edad NUMBER(3))
/
CREATE TABLE Persona OF tipoPersona;
INSERT INTO Persona
VALUES (tipoPersona (‘Pepe’, ‘Sánchez’, 50));
En la consulta se recupera el valor de los objetos de la tabla Persona:
SELECT VALUE(p) FROM Persona p;
El resultado sería el siguiente:
VALUE(P)(NOMBRE, APELLIDOS, EDAD)
----------------------------------------------
TIPOPERSONA (’Pepe', ’Sánchez', 50)
30

EVOLUCIÓN DE TIPOS
A continuación, modificamos el tipo tipoPersona sustituyendo el
atributo edad por f_nacimiento. En este punto, la redefinición del tipo
tipoPersona, ha cambiado también la definición de la tabla Persona,
pero los datos de la tabla no han sido modificados aún, para ajustarse
a la nueva definición.
ALTER TYPE tipoPersona
ADD ATTRIBUTE (f_nacimiento DATE),
DROP ATTRIBUTE edad CASCADE NOT INCLUDING TABLE DATA;
Cuando consultamos ahora el valor de los objetos de la tabla Persona
obtenemos lo siguiente:
SELECT value(p) FROM TablaPersona p;
VALUE(P)(NOMBRE, APELLIDOS, F_NACIMIENTO)
----------------------------------------------
TIPOPERSONA(’Pepe', ’Sánchez', NULL)
EVOLUCIÓN DE TIPOS
• Cuando la consulta anterior recupera los datos
de la tabla Persona, Oracle los modifica para
que concuerden con la nueva definición del tipo.
• En este caso, como se ha añadido un nuevo
atributo, se limita a inicializarlo con valor nulo,
NULL.
• Para borrar tipos con tablas u otros tipos
dependientes, es necesario borrar antes todos
los objetos dependientes o bien incluir la
cláusula FORCE.
• Así, por ejemplo, para borrar el tipo tipoPersona,
tendríamos que especificar:
DROP TYPE tipoPersona FORCE;
31