1 / 43

Contenido

Contenido. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. Introducción a las BDOR 2. Nuevos t ipos de Datos Objeto-Relacionales: 2.1 Large LOB, Object Data Type ( Tipo de Objeto Grande ) 2.2 Colection Type (Tipo Colección): Arrays 2.3 ROW Type (Tipo fila)

kina
Télécharger la présentation

Contenido

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Contenido Modelo de Datos Objeto-Relacional. Estándar SQL:1999 • Introducción a las BDOR • 2. Nuevos tipos de Datos Objeto-Relacionales: • 2.1 Large LOB, Object Data Type (Tipo de Objeto Grande) • 2.2 Colection Type (Tipo Colección): Arrays • 2.3 ROW Type (Tipo fila) • 2.4 UDT, User Definition Type (Tipos Definidos por el Usuario) • 2.4.1 Distinct Type (Tipo Distinto) • 2.4.2 Structured Type (Tipo estructurado) • 2.5 Métodos • 2.6 Ref Type (Tipo Referencia) • 2.7 Jerarquías de Tablas • 2.8 Herencia

  2. Modelo de Datos Objeto-Relacional. Estándar SQL:1999 • 1. Introducción • El estándar SQL: 1999 sigue un enfoque “evolutivo”. Es una versión aprobada del estándar SQL que incorpora varias características del paradigma de orientación a objeto al enfoque relacional; pero no se limita a eso, puesto que incorpora otras características y reestructura completamente la documentación del estándar. • Las nuevas características del estándar se pueden dividir entonces en “Características Relacionales”y“Características Orientadas a Objeto”. • Durante su desarrollo se conoció como SQL 3, y a partir de los borradores de trabajo del estándar, se desarrollaron varios ORDBMS entre ellos Oracle 8 de Oracle, Universal Server de Informix, DB2 Universal Database de IBM, entre otros. • SQL3 es computacionalmente completo, incluye: • Asignación • IF .. THEN .. ELSE .. ENDIF, y CASE • CALL y RETURN para invocar procedimientos

  3. Modelo de Datos Objeto-Relacional. Estándar SQL:1999 1. Introducción Extensiones en las capacidades de los SGBDOR vs. SGBDR: Nuevos Tipos de Datos que permiten gestionar aplicaciones más complejas con una gran riqueza de dominios (imagen, voz, sueldo, etc.) Nuevas operaciones que permiten gestionar el comportamiento de los Tipos de Datos. Mayor capacidad expresiva para los conceptos y asociaciones complejos. Reusabilidad, propio de la Orientación a Objetos. Se pueden compartir diversas bibliotecas de clases ya existentes. Integración de lenguajes: relacional, de objetos, XML, etc Mayor capacidad consultiva(consultas anidadas, recursivas, almacenadas, pre-fabricadas), etc.

  4. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 1.Introducción... Se extiende la sintaxis de SQL:92 y se amplía su alcance: ►Nuevos tipos de datos (dominios) Objeto-Relacionales: Tipo de datos Objeto Grande, LOB (Large Object) Tipos de datos fila (Row) y referencia (REF) Tipos de datos colección (set, bag, list y array) Tipos de datos Definidos por el Usuario (UDTs) ►Extensiones en el Control de datos Objeto-Relacionales Triggers Procedimientos almacenados y funciones definidas por el Usuario ►Extensiones en las capacidades Consultivas Objeto-Relacionales: Consultas recursivas SQL:99->SQL2003 Incorpora al lenguaje XML y viceversa ►Otras Extensiones en las Bases de Datos Objeto-Relacionales: Extensiones a la ayuda en la toma de Decisiones: OLAP, etc. Intercambio de Objetos (OEM), Datos Multimedia, etc.

  5. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 1 Introducción… • Nuevos tipos de datos... • Otro nuevo tipo de datos es BOOLEANque permite a SQL manejar los valores: verdadero (true), falso(false), y desconocido(Unknown). • SQL:1999 agrega además otro tipos de datos llamados “Tipos Distintos”,que son tipos de datos definidos por el usuario (UDTs) que se basan en tipos primitivos o en otros tipos distintos. • Soporte a la Orientación a objeto. Tipos, abstracción y clases • El estándar unifica estos conceptos bajo el nombre detipo estructurado, que es un tipo de UDT que puedeencapsular 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. • *La sintaxis de SQL: 1999 para la orientación a objeto se encuentra en el apéndice A.

  6. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 1. Introducción a las BDOR Tipos de Datos Objeto-Relacionales Tipo de dato Large Object (LOB) Binary Large Object (BLOB) Character Large Object (CLOB) Constructores de tipo objeto Row types Referenced types Tipo colección Set, Bag, List y Arrays Tipos de datos Definidos por el Usuario (UDT) Distinct types Structured types Métodos, funciones y procedimiento definidos por el usuario Jerarquías de tablas y de vistas

  7. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.1 Tipo Large Object: LOB Tipo LOB, se almacena en la BDOR como cualquier atributo. Su gran capacidad puede definirse en DDL como: KB, MB o Gigabytes El tipo LOBtiene dos subtipos: Binary Large Object, BLOB, almacena objetos multimedia: audio, imagen, mapas, video, fotos. Character Large Object, CLOB, almacena texto Ejemplo: CREATE TABLE documental ( titulo VARCHAR(200), id_doc INTEGER, resumen CLOB (32K), texto_doc CLOB (20M), video_film BLOB (2G));

  8. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.1 Tipo Large Object: LOB El Tip LOB se gestiona como cualquier columna de una BD: Para consultar un valor o parte de él (SELECT…), Añadir valores (INSERT…), con algunas restricciones Borrar (DELETE…) Actualizar (UPDATE…), con algunas limitaciones Adicionalmente, el tipo LOB tiene permitidas las operaciones siguientes: Predicado LIKE La yuxtaposición o concatenación de objetos Funciones: LENGH, SUBSTRING, POSITION, TRIM

  9. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.1 Tipo Large Object: LOB Debido al gran tamaño del tipo LOB, el ORDBMS precisa la definición de ‘buffers’ del tamaño adecuado para su gestión, según cada caso. LOCATOR :si LOB es del orden de GB, entonces se usa esta cláusula para ayudar al ORDBMS a la gestión de dicho LOB. Los LOB no tienen permitidas las siguientes operaciones: GRATHER THAN y LESS THAN Claves primarias PK, claves externas FK y UNIQUE GROUP BY y ORDER BY Operador JOIN (como columnas del Join)

  10. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.2 Colection Type (Tipo Colección): Array SQL:1999 incorpora dos tipos compuestos: ARRAY yROW. El tipo ARRAY nos permite guardar colecciones de valores directamente en una columna de una tabla de la BD. ->“No First Normal Form”(NFNF o NF2) Ejemplo: DIAS_DE_LA_SEMANA VARCHAR(10) ARRAY[7] ►Pueden definirse sobre cualquier tipo (excepto array) Operaciones: Acceso a los elementos por un número ordinal, Cardinalidad, Comparación, Asignación, Concatenación, CAST, transformación de array a tabla...

  11. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. Continuación... 2.2 Colection Type: Arrays Ejemplo: CREATE TABLElibro ( títuloVARCHAR(200), id_libro INTEGER, autores VARCHAR (15) ARRAY [20], resumen CLOB (32K), texto_libro CLOB (20M), películaBLOB (2G)); INSERT INTOlibro (título, id_libro, autores) VALUES(“A guide to the SQL Standard”, 15, [‘Date’, ‘Darwen’ ]) SELECT id, autores[1] AS nombre FROM libro

  12. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.3 ROW Type (Tipo fila) El tipo ROW (en SQL:1999) es una secuencia de una o más parejas (<Nombre Campo>,<Tipo de datos>) llamados campos (fields) que permite almacenarvalores estructuradosen simples columnas de la base de datos. CREATE TABLE empleado( id_emp INTEGER, nombre ROW (nombre_de_pila VARCHAR(30), apellido VARCHAR(30)), dirección ROW (calle VARCHAR(50), ciudad VARCHAR(30), provincia CHAR(2)), sueldo REAL) SELECT E.nombre.apellido FROM empleado E Una vez definido un row type, éste se puede usar para definir una tabla con filas del tipo de ese row type.De hecho, esta es la forma de darle persistencia al tipo.Los row type también se pueden utilizar para definir el tipo de una columna de una tabla. Se pueden definir funciones que devuelvan valores del tipo row type.

  13. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 UDTs, Tipos Definidos por el Usuario Un tipo definido por el usuario (UDT) es un tipo de interés para dicho usuario y diseñado a la medida de cierta aplicación. Su sintaxis se inicia con la cláusula: CREATE TYPEnombre_UDT AS (…. Cada UDT se define en términos de: • otros tipos del lenguaje SQL y/o • otros tipos definidos previamente por el usuario. Nota: SQL-99 es -a diferencia de SQL-92-fuertemente tipado (SQL-92 no maneja objetos, sin embargo es la base de partida para JDBC, SQLJ, SQL:1999, y ODMG OQL)

  14. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 UDTs, Tipos Definidos por el Usuario Hay dos tipos de UDTs: Distinct type: basados en un tipo de datos built-in, comoINTEGER, pero uno de estos tipos no puede mezclarse directamente en operaciones con ese tipo built-in ni con cualquier otro tipo. Structured type: tienen una estructura interna tal como un tipo dirección con atributos de tipo calle, ciudad y código postal como parte de la estructura. Pueden contenerfunciones definidas por el usuario Participar enjerarquías de tiposcon otros tipos estructurados. Soportanherencia simple. Ambos tipos,distintos y estructurados, pueden ser usadoscomo tipos de datos decolumnas, variables SQL, un campo de un row type, o como atributo de otro UDT.

  15. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 UDTs, Tipos Definidos por el Usuario • El modelo de objetos de SQL:1999 también permite declarar a un UDT como eltipo para una tabla. • Una typed table, o tabla tipada, es una tabla o vista construida en base a un tipo estructurado definido por el usuario. • Cada fila de la tabla será una instancia de dicho UDT • Cada atributo del UDT se transforma en una columna de la tabla • Los métodos asociados con el tipo son asociados con la tabla. • Cada tabla tipada tiene una columna adicional auto • referente. 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. Esto es similar a un OID usadoen el modelo • de objetos clásico.

  16. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. Continuación... 2.4 Tipos Definidos por el Usuario: 2.4.1 Distinct Type (Tipo Distinto) Distinct types: se basan en un tipo ya definido (en función de tipos de datos built-in, tal como INTEGER). Los nuevos tipos declarados serán diferentes, a pesar de que el tipo base sea el mismo, por lo tanto, las operaciones que los combinen darán error. Aunque estostipos comparten una misma representaciónsus valores no pueden mezclarse directamente. Tienen distinto comportamiento Ejemplo: CREATE TYPE MY_SHOE_SIZEAS INTEGER(3) FINAL CREATE TYPE MY_IQAS INTEGER(3) FINAL ... WHERE MY_SHOE_SIZE > MY_IQ // ERROR Esta última expresión arroja un error de sintaxis, puesto que MY_SHOE_SIZE y MY_IQson de tipo distinto.

  17. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. Continuación... 2.4 Tipos Definidos por el Usuario: 2.4.1 Distinct Type (Tipo Distinto) Ejemplo de Tipo Distinto CREATE TYPE tipoSala AS CHAR(10) FINAL; CREATE TYPE tipoMetros AS INTEGER FINAL; CREATE TYPE tipoMetrosCuad AS INTEGER FINAL; CREATE TABLE Sala ( Nsala tipoSala, LongSala tipoMetros, AnchoSala tipoMetros, AreaSala tipoMetroscuad, PerimSala tipoMetros)); UPDATE Sala SETAreaSala=LongSala; Incorrecto (error: tipo distinto) UPDATESala SETAnchoSala=LongSala; Correcto

  18. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. Continuación... 2.4 Tipos Definidos por el Usuario: 2.4.1 Distinct Type (Tipo Distinto) Cuando se quiera operar sobre dos tipos distintos, primero se hace CAST de uno al otro o de cada uno a un tipo base y luego sí se puede operar sobre los valores. Si se declaran las siguientes variables: DECLARE VARIABLE X decimal(9,2) DECLARE VARIABLE Y usDollars No se puede sumar directamente X + Y, sin embargo si se puede hacer X + CAST(Y AS decimal(9,2)). Se pueden definir funciones, para hacer las conversiones de tipo con la opción CAST,dentro de la definición del tipo (en el CREATE TYPE)

  19. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 Tipos Definidos por el Usuario: 2.4.1 Structured Type (Tipo Estructurado) El estándar unifica los conceptosde tipo, abstracción y clase bajo el nombre detipo estructurado.Mediante este tipo de UDT se pueden encapsular atributos y métodos en una única entidad lógica. Un tipo estructurado pasará a ser uno más del sistema, pudiendo ser utilizado del mismo modo que un tipo primitivo. Se puede usar como: Column Type (Tipo Columna): Para modelar atributos de las entidades. Ej: Texto, imagen, vídeo, series de tiempo, punto, línea.... Facilita el uso de objetos multimedia (SQL/MM) Row Type (Tipo Fila): Para modelar entidades con relaciones y comportamiento. Ej: empleado, departamento, alumno... Facilita el uso de objetos de negocio

  20. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 Tipos Definidos por el Usuario Ejemplos: CREATE TYPE direccion AS ( calleVARCHAR (40), ciudad VARCHAR (20), provincia VARCHAR (40), código_postal INTEGER (5)); CREATE TYPE foto-bitmap AS BLOB FINAL; CREATE TYPE chalet AS ( Propietario REF (persona), Precio INTEGER, habitaciones INTEGER, tamaño DECIMAL (8,2), ubicación direccion, imagen foto-bitmap) NOT FINAL •La cláusula NOT FINAL, permite que un tipo sea utilizado como supertipo de otro. Esta cláusula no es opcional.

  21. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 Tipos Definidos por el Usuario: 2.4.2 Tipo estructurado: tipo de datos Abstractos Características asociadas: Comportamiento ,Encapsulación, Sustitución, Polimorfismo Ligadura dinámica y Verificación de tipos estática Como ya se dijo, un tipo estructurado encapsula atributos y métodos en una única entidad lógica (pero físicamente separados). Los atributos de un objeto persistente serán almacenaremos en una tabla, y los métodos,junto a los demás procedimientos almacenados. Cabe destacar que esta separación es transparente para el usuario. Como vimos, para crear un tipo estructurado se utiliza el predicado CREATE TYPE , donde especificamos una lista de atributos,y opcionalmente, una lista de métodos.

  22. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 Tipos Definidos por el Usuario: 2.4.2 Tipo estructurado: tipo de datos abstractos… La definición de un tipo de dato abstracto (TDA) o (ADT en inglés) incluye la estructura del tipo, las operacionesque definenigualdady ordenamiento, y las operaciones que definen el comportamiento del ADT. Las operaciones se implementan con procedimientos llamados rutinas. create type empleado_t as object ( nombre VARCHAR(100), apellido VARCHAR(100), direccion direccion_t, salario decimal(9,2)); create table Empleados of empleado_t; La manera de almacenar persistentemente un ADTen una BD es declarándolo como el tipo de una columna de una tabla.

  23. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.4 Tipos Definidos por el Usuario: 2.4.2 Tipo estructurado: tipo de datos abstractos… ►Los atributos y las operacionesde un ADT pueden ser públicos o privados, los públicos son los únicos que pueden ser accedidos fuera del ADT. ► Adicionalmente, para cada atributo se definen automáticamente dosfunciones:una “observador”y una“mutator”. ► Se pueden definir atributos virtuales dentro de un ADT, para los cuales no se almacenan valores, sino que se calculan cuando se necesitan a través de las funciones definidas por el usuario de observador y mutator. ►Las instancias de un ADT se crean con las funciones constructoras del sistema. ► Para acceder las partes de un ADT se puede utilizar la notación de punto o la funcional (solo para las funciones).

  24. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.5 Métodos Con SQL-92, se introduce la noción de procedimiento almacenado, que corresponde afunciones o procedimientos definidos por el usuario, que pueden ser utilizados 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 unnombre, unalista 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 o signatura). Para definir su implementación o cuerpo, se utiliza 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 lenguajes de programación tradicionales, incluyendo JAVA).

  25. 2.5 Métodos El Método es una función SQL ligada a un Tipo Definido por el Usuario Se definen en el esquema. La signatura se define separada de la especificación del cuerpo. CREATE TYPE empleado AS ( id INTEGER, nombre VARCHAR (20), sueldo_base DECIMAL (9,2), primas DECIMAL (9,2)) INSTANTIABLE NOT FINAL METHOD sueldo() RETURNS DECIMAL (9,2); CREATE METHOD sueldo() FOR empleado BEGIN ...... END; Los métodos se invocan utilizando la notación “punto” SELECT e.sueldo() FROM empleado e La cláusula INSTANTIABLE, permite crear instancias del tipo en forma directa. Si queremos prohibir esto (para implementar clases abstractas), indicamos NOT INSTANTIABLE. Esta cláusula es opcional y su valor por defecto es INSTANTIABLE. IR Modelo de Datos Objeto-Relacional. Estándar SQL:1999.

  26. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.5 Métodos • Otro ejemplo: • considerar untipo Punto, con los atributos: 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; • Existen diversas formas de invocación del método y distintas formas de ligadura, a los posibles tipos de datos, durante el tiempo de compilación y/o de ejecución (early binding and late binding, herencia, polimorfismo).

  27. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.5 Métodos: tipos • Originales • Overriding (de los subtipos) • CREATE TYPE empleado AS ( • id INTEGER, nombre VARCHAR (20), sueldo_base DECIMAL (9,2), primas DECIMAL (9,2)) INSTANTIABLE NOT FINAL • METHOD sueldo() RETURNS DECIMAL (9,2); • CREATE TYPE gestión UNDER empleado AS ( • stock_option INTEGER) INSTANTIABLE NOT FINAL • OVERRIDING METHOD sueldo() RETURNS DECIMAL (9,2), METHOD otro() RETURNS INTEGER; • Ligadura dinámica: los métodos sobrecargados se resuelven en tiempo de ejecución (vinculándose al más específico)

  28. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.6 Tipo Referencia • Todo tipo estructurado tiene asociado su 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 usados es dependiente de la implementación del estándar). • Un tipo de referencia puede ser utilizado en los mismos lugares que un tipo estructurado. Para definirlos utilizamos 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 TYPElinea_rectaAS ( • a REF (punto), • b REF (punto))INSTANTIABLE NOT FINAL

  29. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.6 Tipo Referencia... • 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<reference type specification>, que es opcional y se coloca a continuación de la cláusula <finality>. • Las3 formasde generar lasreferenciasson: • Generada por el usuario (USER GENERATED), la referencia se basa en un tipo primitivo, cuyo valor será proporcionado por el usuario y su sintaxis es: REF USING <predefined type>. • Ejemplo:CREATE TYPE persona AS ( • DNI CHAR(10), • Nombre CHAR(40) • )INSTANTIABLE NOT FINAL • REF USING INTEGER

  30. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.6 Tipo Referencia... • Generada por el sistema (SYSTEM GENERATED), la referencia es generada automáticamente por el sistema. Este es el valor pordefecto • La sintaxis es: REF IS SYSTEM GENERATED • Ejemplo: • CREATE TYPE persona AS ( • DNI CHAR(10) , • Nombre CHAR(40) • )INSTANTIABLE NOT FINAL • REF IS SYSTEM GENERATED

  31. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.6 Tipo Referencia... • Derivada (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(10) , • 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.

  32. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.6 Tipo Referencia... Para acceder a un atributo lo hacemos de la misma manera que en JAVA, a excepción de los atributos del tipo REF(...).Por ejemplo, para acceder al atributo dni, de un empleado e, sería: e.dni, y esto se usa para cualquier nivel de anidamiento, por ejemplo: e.domicilio.numero. Para acceder a los atributos de un tipo de datos REF(...), existe el operador “->”. Por ejemplo, si queremos saber el nombre del jefe del empleado, sería: e.jefe->nombre CREATE TYPE empleado AS ( DNI CHAR(10), nombre CHAR(40), sueldoBase INTEGER , anticipo INTEGER DEFAULT 0, fecha_ing DATE DEFAULT CURRENT_DATE, jefe REF(empleado), domicilio direccion )INSTANTIABLE NOT FINAL CREATE TYPE direccion AS ( calle CHAR(40), numero CHAR(10), ciudad CHAR(30) )NOT FINAL

  33. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. • 2.6 Tipo Referencia... • CREATE TYPE chalet AS ( • Propietario REF (persona), • Precio INTEGER, habitaciones INTEGER, tamaño DECIMAL (8,2), ubicación direccion, imagen foto-bitmap) NOT FINAL • CREATE TABLE bien_inmueble OF chalet • (REF IS oid USER GENERATED) • Los atributos del tipo chalet se convierten en columnas de la tabla • bien_inmueble. • Se añade en la tabla una columna más para definir el valor REF de la • fila (oid)

  34. 2.6 Tipo Referencia • El tipo REF no tiene la misma semántica que la regla de referencias • cruzadas o restricción de integridad referencial. • La integridad referencial implica una dependencia de inclusión y el tipo REF no. • El tipo REF se puede usar donde se use cualquier otro tipo. • SELECT ch.precio,ch.propietario->nombre • FROMchalet ch • WHERE ch.propietario->ciudad=“Madrid” • SELECT e.nombre, e.departamento->num_empleados() • FROMempleado e • SELECT ch.precio, DEREF (ch.propietario) • FROM chalet ch ●Eliminación de JOINs ●Las referencias pueden servir para invocar métodos ●Las referencias pueden servir para obtener el valor del tipo estructurado al que está referenciando (derreferencia) Modelo de Datos Objeto-Relacional. Estándar SQL:1999.

  35. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.7 Jerarquías de Tablas La tablas tipadas pueden tener subtablas Las subtablas heredan: atributos, restricciones, disparadores, métodos. CREATE TYPE persona AS .... NOT FINAL CREATE TYPE bienes AS (dueñoREF (persona), .... NOT FINAL CREATE TYPE tierras UNDER bienes AS .... NOT FINAL CREATE TYPE bien_inmuebleUNDER bienes AS .... NOT FINAL CREATE TYPE casas UNDERbien_inmueble AS ....NOT FINAL CREATE TYPE chalet UNDER bien_inmueble AS ....NOT FINAL CREATE TABLE persona OF persona(...) CREATE TABLE inmueble OFbien_inmueble CREATE TABLE tierras OF tierras UNDER bienes CREATE TABLE casa OF casas UNDER bien_inmueble ......

  36. Modelo de Datos Objeto-Relacional. Estándar SQL:1999. 2.7 Jerarquías de Tablas Las consultas sobre la supertabla, devuelven también las filas de las subtablas SELECT* FROM Inmueble WHERE .... Se pueden restringir las filas seleccionadas a las que pertenecen a la supertabla SELECT* FROM ONLY Inmueble WHERE ....

  37. Herencia en SQL:1999 Se especifica mediante UNDER Ejemplo: CREATE TYPE tipo-ManagerUNDER tipo_Empl AS( depto_dirigido CHAR (20)); Tipo_Managerhereda todas las características de tipo_Empl y tiene el atributo adicionaldepto_dirigido

  38. Herencia en SQL:1999 • Dada la siguiente definición para el tipo persona: create typePersona(nombre varchar(20), direcciónvarchar(20)) • Usando herencia definir los tipos estudiante y profesor create type estudianteunder Persona(carreravarchar(20),departamento varchar(20)) create type profesorunder Persona(sueldo integer,departamento varchar(20)) En los Subtipos pueden redefinirse los métodos usando overriding method en lugar de usarmethod en la declaración de los métodos.

  39. Herencia Múltiple • SQL:1999 no soporta herencia múltiple • Si nuestro sistema de tipos soportara herencia múltiple, podríamos definir un tipo para ayudante de cátedra como sigue: create type Ayudanteunder Estudiante, Profesor Para evitar conflicto entre las dos ocurrencias de departamento las renombraríamos create type Ayudanteunder Estudiantewith (departmentoas dpto-estudiante),Profesorwith (departmentoas dpto-profesor)

  40. Herencia de Tablas • La herencia de tablas permite a un objeto tener múltiples tipos, permitiendo que una entidad pertenezca a más de una tabla a la vez. • Ejemplo: create table personasof persona • Podemos definir las tablas estudiantes y profesores como subtablas de personas create table estudiantesof estudianteunder personascreate table profesoresof profesorunder personas • Cada tupla en una subtabla (e.g. estudiantes y profesores) está implicitamente presente en sus supertablas (e.g. persona)

  41. Herencia de Tablas: requerimientos de consistencia • Requerimientos de consistencia entre subtablas y supertablas. • A cada tupla de la supertabla (e.g. personas)le podría correspondera lo sumo una tupla en cada una de las subtablas (e.g. estudiantes y profesores)... • Requerimientos adicionales en SQL:1999: Todas las tuplas que se corresponden entre si (esto es, que tengan los mismos valores para los atributos heredados) deben ser derivadas de una(1) tupla (insertada en 1 tabla). • Esto es, cada entidad debe tener un sólo tipomás específico • No podemos tener una tupla en personas correspondiendo a una tupla en estudiantes y a una tupla en profesores

  42. Herencia de Tablas: alternativas de almacenamiento • Alternativas de almacenamiento • Almacenar en la subtabla sólo los atributos locales y la clave primaria de la supertabla • Los atributos derivados se obtienen mediante Join con la supertabla • Cada tabla almacena todo, los atributos locales y los heredados • Las supertablas contienen implicitamente los atributos que heredan sus subtabla • El acceso a todos los atributos de una tupla es más rápido (no se necesita join) • Si las entidades deben tener un tipo más específico (most specific type), las tuplas se “almacenan” en una (1) tabla

  43. Tipos de Referencia • Los lenguajes O.O. Tienen la capacidad de manejar referencias a objetos. • En SQL:1999 • Las Referencias son a tuplas, y • Las Referencias deben tener un ámbito de aplicación (must be scoped), • I.e., sólo pueden apuntar a tuplas de una tabla especificada • Más adelante se estudiará como definir referencias y luego como se usan dichas referencias.

More Related