08. Evolución del modelo relacional

Desde su aparición en 1970, el Modelo Relacional de datos ha experimentado una larga evolución guiada por el objetivo de proporcionar al modelo una mayor capacidad expresiva. En el apartado 2.8.1, se van a analizar las principales limitaciones del modelo que han provocado la incorporación al mismo de diferentes extensiones.

Como ya se ha dicho en otros puntos de este tema, en el desarrollo de los sistemas relacionales, el estándar aceptado ha sido definido en cada momento por la versión vigente del lenguaje SQL. En su última versión, el SQL3 publicado en 1999, el modelo que se propone ya no es un modelo relacional puro, sino un modelo objeto-relacional con capacidad deductiva y mecanismo de actividad. En el apartado 2.8.2, se analizarán estas extensiones del modelo.

Limitaciones del Modelo Relacional

En este tema se han presentado los fundamentos del Modelo Relacional de Datos. Del estudio realizado es fácil advertir ciertas limitaciones del modelo que justifican su evolución en varias direcciones. Para ilustrar estas limitaciones considérense los siguientes ejemplos relativos al esquema relacional del Ejemplo 2.35, sobre la docencia en una universidad. En cada ejemplo se plantea un nuevo requisito del usuario, se analiza su tratamiento y se estudian las implicaciones de la solución adoptada, implicaciones derivadas de las características del modelo de datos.

Ejemplo 2.63

Se decide cambiar la codificación de los departamentos en la Universidad.

Este cambio implica la actualización de la base de datos, concretamente la actualización del atributo código de todas las tuplas de la relación Departamento:

UPDATE Departamento SET código = ...

Sin embargo, como se puede observar en el esquema, este cambio afectará a otras relaciones de la base de datos y obligará a actualizar también todas las referencias a Departamento desde otras relaciones, como son la relación Profesor y la relación Asignatura. La necesidad de estas actualizaciones secundarias reside en el hecho de que en el esquema relacional, las referencias a Departamento se representan por medio de claves ajenas, dónde la referencia se realiza “por valor”, es decir la referencia a un departamento desde la tupla que representa a un profesor o a una asignatura se realiza almacenando el valor del código del departamento (identificador) en dicha tupla. El Modelo Relacional contempla esta situación y permite definir en el esquema, directrices de restauración de la consistencia, asociadas a una clave ajena, por ejemplo la directriz UPDATE CASCADE en las claves ajenas a Departamento, liberaría al usuario de la responsabilidad de realizar estas actualizaciones secundarias.

Ejemplo 2.64

Se desea contemplar la posibilidad de que un departamento tenga varios teléfonos de contacto.

La incorporación de este cambio significa la modificación del esquema de la base de datos, concretamente la definición de una nueva relación en el esquema.

CREATE TABLE Dpto_Tlfno

    (dpto CHAR (5),

    tlfno CHAR (11),

    CONSTRAINT CP_Dpto_Prof PRIMARY KEY (dpto, tlfno),

    CONSTRAINT CAj_dpto FOREING KEY (dpto) REFERENCES Departamento (codigo)

        ON UPDATE CASCADE

        ON DELETE CASCADE )

Un análisis del nuevo esquema conduce a las siguientes reflexiones sobre el modelo. Un pequeño cambio en una propiedad del departamento, ya contemplada en el esquema anterior, como son los teléfonos de contacto del departamento, que pasan a ser varios, obliga a extraer esta propiedad de la relación Departamento y a representarla en una nueva estructura de datos, la relación Dpto-Tlfno. La necesidad de esta modificación del esquema, reside en la limitación del modelo relacional que obliga a utilizar dominios escalares para los atributos de las relaciones. El efecto destacable de esta característica del modelo, es que en un esquema relacional la información sobre un mismo objeto del mundo real queda dispersa en varias relaciones. Es el usuario, durante la manipulación de la base de datos, el que debe recuperar e integrar toda la información del objeto, realizando concatenaciones entre relaciones de la base de datos. Así para recuperar la información sobre un departamento (código, nombre y teléfonos) sería necesaria la siguiente consulta:

SELECT codigo, nombre, tlfno

FROM Departamento JOIN Dpto-Tlfno ON codigo = dpto

Ejemplo 2.65

Se desea introducir en la base de datos información sobre la relación de prerrequisitos entre las asignaturas de un plan de estudios. Esta relación de prerrequisitos introduce restricciones de incompatibilidad entre las asignaturas que limitan la matrícula de los alumnos.

La incorporación de este cambio obliga a modificar el esquema de la base de datos, concretamente a introducir una nueva relación con la información sobre los prerrequisitos.

CREATE TABLE Prer

    (asg1 CHAR(5),

    asg2 CHAR(5),

    CONSTRAINT CP_Prer PRIMARY KEY (asg1, asg2),

    CONSTRAINT CAj_asg1 FOREING KEY (asg1) REFERENCES Asignatura (codigo),

    CONSTRAINT CAj_asg2 FOREING KEY (asg2) REFERENCES Asignatura (codigo) )

Una tupla de la relación Prer, representa que la asignatura de código asg1 tienen como prerrequisito directo a la asignatura de código asg2, lo que significa en la práctica que un alumno no puede cursar la asignatura asg1 sin haber aprobado previamente la asignatura asg2. Del análisis de la propiedad “ser prerrequisito”, es fácil deducir que esta propiedad se transmite transitivamente entre las asignaturas del plan de estudios. Así, si la asignatura de código BDA tiene como prerrequisito a la asignatura de código AD3 y esta última tiene como prerrequisito a la asignatura de código AD2, entonces se puede deducir que la asignatura BDA tiene como prerrequisito indirecto a AD2.

La propiedad “ser prerrequisito” directa o indirectamente entre un par de asignaturas, se puede definir por medio de dos reglas de conocimiento:

R1:”la asignatura asg1 tiene como prerrequisito a la asignatura asg2, si asg1 tiene como prerrequisito directo a asg2”

R2: “la asignatura asg1 tiene como prerrequisito a la asignatura asg2, si asg1 tiene como prerrequisito directo a una asignatura asg3, y ésta tiene como prerrequisito directo o indirecto a la asignatura asg2”.

Esta idea de definir información por medio de reglas de conocimiento, en lugar de hacerlo a través de datos almacenados, está contemplada en el Modelo Relacional en el mecanismo de vistas. Como ya se vio en el apartado 2.6, este mecanismo ofrece la posibilidad de definir en el esquema de la base de datos información implícita, es decir información derivable a partir de la información explícitamente almacenada.

Así la propiedad “ser prerrequisito” directa o indirectamente podría representarse en el esquema por una vista Prerrequisito cuya extensión implícita se obtuviese aplicando las dos reglas de derivación R1 y R2 a la relación básica Prer. Utilizando un lenguaje de tipo lógico la vista Prerrequisito podría definirse de la forma:

R1: Prerrequisito ({(asg1, PX.asg1), (asg2, PX.asg2)}) ← (PX: Prer )

R2: Prerrequisito ({(asg1, PX.asg1), (asg2, PY.asg2)}) ← (PX: Prer , PY: Prerrequisito  PX.asg2=PY.asg1)

Es importante destacar que la vista Prerrequisito se define recursivamente a partir de ella misma, como indica la regla R2.

La existencia de esta vista en el esquema, facilitaría al usuario las consultas sobre relaciones de incompatibilidad entre asignaturas. Así, si un alumno quisiese saber a qué asignaturas no tiene acceso debido a no tener aprobada la asignatura de código AD1, podría plantear la siguiente consulta al sistema:

SELECT asg1

FROM Prerrequisito

WHERE asg2=’AD1’

En SQL la vista Prerrequisito podría definirse de la siguiente forma.

CREATE VIEW Prerrequisito (asg1, asg2) AS

    SELECT *

    FROM Prer

    UNION

    SELECT P1.asg1, P2.asg2

    FROM Prer P1 JOIN Prerrequisito P2 ON P1.asg2=P2.asg1

donde cada operando del operador UNION traduce una regla de derivación. Sin embargo la vista Prerrequisito no puede definirse en un sistema relacional que contemple el SQL92, ya que en esta versión del lenguaje, están prohibidas las consultas recursivas y por lo tanto las vistas recursivas como la anterior.

Este ejemplo ilustra las limitaciones del Modelo Relacional (versión SQL92) a la hora de definir información derivada en forma de vistas.

Ejemplo 2.66

Se desea añadir a la relación Departamento un nuevo atributo profesores cuyo valor sea en cada momento el número de profesores adscritos al departamento.

La incorporación de este cambio significa modificar el esquema de la relación Departamento añadiendo el nuevo atributo:

ALTER Departamento ADD COLUMN profesores INTEGER DEFAULT 0

(esta modificación del esquema obligaría a actualizar inicialmente para cada departamento existente el valor de este atributo con el número de profesores adscritos a él en ese momento).

Una pequeña reflexión sobre esta modificación advierte inmediatamente, de que el nuevo atributo contiene información redundante en la base de datos, ya que el número de profesores adscritos a un departamento puede derivarse de la relación Profesor, dónde para cada profesor el departamento de adscripción queda registrado en la clave ajena cod_dep. La consulta que recuperaría los datos del departamento y el número de profesores adscritos a él sería:

SELECT D.codigo, D.nombre, COUNT (P.codigo)

FROM Departamento D LEFT JOIN Profesor P ON D.codigo=P.dep

GROUP BY D.código, D.nombre

Sin embargo, y aunque la eliminación de la redundancia es un objetivo de diseño en bases de datos, la redundancia puede estar justificada en muchos casos por razones de eficiencia. Así, si el número de profesores de un departamento es una información que se consulta frecuentemente junto a los datos del departamento, puede estar justificada la inclusión del nuevo atributo. Ahora bien, en este caso, la redundancia debe ser controlada durante la actualización de la base de datos, asegurándose de que cualquier actualización sobre la relación Profesor (inserción, borrado o modificación del atributo dep) lleva asociada la correspondiente actualización del atributo derivado profesores en la relación Departamento. Así un borrado de un profesor debería ser ejecutado a través del siguiente par de operaciones de actualización:

UPDATE Departamento

SET profesores = profesores – 1

WHERE codigo = (SELECT dep FROM Profesor WHERE codigo=’LBP’);

DELETE FROM Profesor WHERE codigo=’LBP’

Tradicionalmente la responsabilidad de mantener la consistencia de la información redundante, ha estado en manos del usuario o en su caso del programador de las aplicaciones de acceso a la base de datos, con el alto riesgo de inconsistencia que esto significa. Una mejora obvia del modelo pasaría por poder especificar en el esquema de la base de datos, reglas de comportamiento autónomo para el sistema. En el ejemplo, esto significaría poder especificar en el esquema las reglas para el mantenimiento automático de los datos redundantes.

En el apartado 2.7, ya se ha visto como el SQL3 (la última versión del modelo) ofrece la posibilidad de definir comportamiento autónomo en forma de disparadores.

Los ejemplos anteriores ponen en evidencia algunas limitaciones del Modelo Relacional en su versión SQL92.

El Ejemplo 2.63, pone de manifiesto el problema que significa el uso de referencias “por valor” entre las relaciones de la base de datos. En el modelo relacional la identidad de un objeto, está definida por la clave primaria de la relación en la que se representa el objeto, es decir la identidad se basa en el valor de algunas de sus propiedades (atributos de la clave primaria); si alguna de estas propiedades cambia, la identidad cambia, y por lo tanto cualquier referencia a él desde otra relación deja de ser válida (integridad referencial).

El Ejemplo 2.64, pone de manifiesto las limitaciones del modelo relacional para representar los objetos del mundo real con toda su complejidad. La ausencia de constructores de tipos estructurados (conjunto, lista, ...) y de tipos de datos definidos por el usuario, obliga a representar un mismo objeto de información por medio de varias relaciones del esquema. El usuario de la base de datos se ve obligado a manejar esa representación dispersa del objeto durante la manipulación de la base de datos.

El Ejemplo 2.65, pone de manifiesto las limitaciones del modelo a la hora de definir información implícita a través de reglas de conocimiento. En las aplicaciones de bases de datos reales, aparecen con frecuencia consultas y reglas de conocimiento con el mismo esquema de recursividad que la presentada en el ejemplo.

El Ejemplo 2.66, pone de manifiesto las limitaciones del modelo a la hora de definir en el esquema de la base de datos reglas de comportamiento autónomo del sistema. Estas reglas permitirían trasladar al esquema parte de la lógica de las aplicaciones, en aquellos casos en que no fuera necesaria la intervención del usuario.

Analizando algunas de estas limitaciones, se observa que muchas de ellas son debidas a la forma en que se representa la realidad en el Modelo Relacional. En una base de datos relacional, los objetos del mundo real, sea cual sea su complejidad y características, se representan por estructuras de datos relación, que son manipuladas por el mismo conjunto de operadores genéricos. Esta simplificación de la realidad al ser representada por medio de datos escalares organizados en tablas, genera muchas de las limitaciones observadas. Modelos de datos posteriores, como el Modelo Orientado a Objetos, han intentado superar esta limitación permitiendo al diseñador definir sus propios tipos de objetos con sus operadores específicos.

Existen otras limitaciones del Modelo Relacional, que no aparecen reflejadas en los ejemplos anteriores y que no son tan fáciles de ilustrar porque exigen conocimientos que exceden los objetivos de este curso. El lenguaje SQL (versión SQL92) es computacionalmente incompleto, es decir con su lenguaje de manipulación no se puede expresar cualquier función computable. Al no poder definir tipos de objetos con sus métodos, los operadores de manipulación (INSERT, DELETE, UPDATE) son genéricos e independientes del significado de cada relación del esquema.

No se pueden definir jerarquías de objetos, entre los que heredar propiedades.

Todas las limitaciones vistas para el modelo se relacionan en la lista siguiente:

  1. uso de atributos simples sobre dominios escalares

  2. identificación de los objetos por el valor de algunas de sus propiedades.

  3. manipulación de las relaciones entre objetos explícitamente.

  4. ausencia de primitivas para representar objetos complejos. (agregación)

  5. ausencia de primitivas para representar jerarquías de objetos. (generalización)

  6. lenguaje de manipulación computacionalmente incompleto.

  7. operadores predefinidos y genéricos (INSERT, DELETE y UPDATE)

  8. limitaciones en la definición de información implícita. (vistas recursivas)

  9. limitaciones en la definición de comportamiento activo. (disparadores).

El intento de superar las limitaciones apuntadas en la lista anterior ha provocado la incorporación de algunas extensiones al Modelo Relacional que ya aparecen contempladas en la última versión del lenguaje estándar SQL, el SQL3. Las limitaciones de la 1a a la 7a han provocado la extensión del modelo con la incorporación de conceptos de la orientación a objetos, haciendo que el modelo pase a ser un modelo objeto-relacional. La limitación 8a ha provocado la extensión del modelo con la posibilidad de definir consultas y vistas recursivas, haciendo que el modelo sea deductivo, y la limitación 9a ha provocado la extensión del modelo con la incorporación de reglas de actividad (disparadores), haciendo que el modelo sea un modelo activo. En el apartado siguiente se van a presentar con más detalle estas extensiones.

Extensiones del Modelo Relacional

SQL3: MODELO DEDUCTIVO

En el SQL3 se contempla la posibilidad de definir consultas y vistas recursivas, con lo que la limitación 8a apuntada anteriormente, quedaría superada.

La sintaxis que se sigue para la definición de una vista recursiva es la siguiente:

CREATE [ RECURSIVE ] VIEW nombre_vista

[(nombre_atr1 [{,nombre_atr2}...]) ]

AS sentencia_SELECT

La vista recursiva Prerrequisito del Ejemplo 2.65, se definiría:

CREATE RECURSIVE VIEW Prerrequisito (asg1, asg2) AS

(SELECT * FROM Prer

UNION

SELECT P.asg1, PR.asg2

FROM Prer P, Prerrequisito PR

WHERE P.asg2=PR.asg1 )

SQL3: MODELO ACTIVO

El SQL3 contempla la definición de reglas de comportamiento autónomo del sistema, en forma de disparadores, con lo que la limitación 9a apuntada anteriormente, queda superada.

Esta capacidad activa del modelo ha sido estudiada extensamente en el apartado 2.7.

SQL3: MODELO OBJETO-RELACIONAL

El lenguaje SQL3 incorpora algunos de los conceptos de la orientación a objetos con lo que la expresividad del modelo para representar la realidad aumenta significativamente.

El Modelo Orientado a Objetos ha sido utilizado extensamente en diferentes campos de la Informática: lenguajes de programación, análisis y diseño de sistemas, bases de datos, etc. En el contexto de las bases de datos, el objetivo que se persigue con este modelo de datos es mantener una correspondencia directa entre los objetos del mundo real y su representación en la base de datos. Como se ha comentado en el apartado anterior, los modelos de datos clásicos, entre ellos el Modelo Relacional, obligan al diseñador y al usuario, a trasladar su observación de la realidad a un conjunto de estructuras de datos que son la únicas disponibles en el modelo, esto provoca, que en muchas ocasiones, la representación del mundo real en la base de datos, diste mucho de la percepción que del mismo tiene el usuario.

El concepto central al Modelo Orientado a Objetos es el concepto de objeto, una clase de objeto (o tipo de objeto)40 se define por un conjunto de atributos (propiedades observables) y un conjunto de métodos (operadores) que permiten manipular las instancias (valores) del tipo. En la orientación a objetos un objeto puede representar cualquier cosa (hecho, individuo o suceso) del mundo real; en la definición del tipo se captura toda la complejidad del objeto, tanto estructural como de comportamiento.

La idea básica de la orientación a objetos consiste en definir los objetos del mundo real tal como estos son percibidos, es decir a través de sus propiedades y con un conjunto de operadores que sólo tienen sentido para cada tipo de objeto. Para poder definir la estructura del objeto, el modelo proporciona constructores de tipos estructurados, disponibles en cualquier lenguaje de programación (tupla, conjunto, lista, vector, etc); estos constructores pueden anidarse a cualquier nivel de profundidad, y pueden usarse sobre tipos básicos (tira, numérico, fecha, etc) o sobre otros tipos de objetos. Asimismo, y aunque se pueden definir operadores específicos para cada tipo de objeto del esquema, el modelo proporciona operadores genéricos con los que manipular los objetos en el caso de que dichos operadores específicos no hayan sido definidos.

Ejemplo 2.67

Sea el sistema de información correspondiente al esquema relacional del Ejemplo 2.35, relativo a la docencia en una universidad.

En la universidad, los departamentos son los órganos responsables de la docencia en las materias relacionadas con su área de conocimiento. Un departamento es responsable de todas las asignaturas con contenidos dentro de su área de conocimiento y tiene adscritos a los profesores que son especialistas en dicha área y que por lo tanto pueden impartir esas asignaturas.

Desde el punto de vista del sistema de información de la universidad, la información relevante de un departamento es: su código interno en la universidad, su nombre, su director, su teléfono (o teléfonos) de contacto, la relación de asignaturas de cuya docencia es responsable y la relación de profesores adscritos a él.

La información relevante de un profesor es: su código, su nombre, su teléfono, su categoría, la docencia que imparte (asignaturas y grupos asignados), y el departamento al que pertenece.

La información relevante de una asignatura es: su código, su nombre, el semestre en el que se imparte, los créditos teóricos y prácticos, el departamento al que pertenece y los profesores a los que se le ha asignado la docencia de la asignatura (grupos asignados).

Observad, cómo ha quedado representado el objeto de información departamento, en el esquema relacional del ejemplo. Debido a las limitaciones del modelo que obliga a organizar los datos en relaciones, la información relativa a un departamento queda repartida en varias relaciones de la base de datos: Departamento, Profesor y Asignatura. Si un usuario quiere recuperar información sobre un departamento, debe reconstruirla utilizando el lenguaje de consulta, que le ofrece unos operadores genéricos (SELECT) con los que manipular las relaciones de la base de datos sea cual sea su significado. La consulta siguiente permitiría obtener datos propios de un departamento (código y nombre) junto al nombre de sus asignaturas:

SELECT DX.codigo, DX.nombre, AX.nombre

FROM Departamento DX, Asignatura AX

WHERE DX.codigo=AX.dep AND DX.codigo=”DSIC”

En esta consulta el usuario ha tenido que concatenar tuplas de dos relaciones de la base de datos, Departamento y Asignatura, apoyándose en la claves ajena dep de Asignatura; esto exige un conocimiento preciso del esquema relacional y de la forma en que la información sobre el departamento ha quedado representada en él.

El Modelo Orientado a Objetos persigue el objetivo de poder representar los objetos en la base de datos tal como son percibidos por el usuario. Así los tipos de objetos Departamento, Profesor y Asignatura, que son los tres tipos de objetos identificables en el sistema de información, serían definidos en un esquema orientado a objetos intentando trasladar su descripción, tal como se puede leer en los párrafos anteriores.

El esquema anterior no está escrito en ningún lenguaje particular, en él se pretende destacar cómo se define la estructura de un objeto en un modelo orientado a objetos. Por ejemplo, el tipo de objeto Departamento consta de los siguientes atributos: dos atributos escalares código y nombre, un atributo director de tipo Profesor que representa el profesor que es el director del departamento, un atributo profesores que es una lista de tipo Profesor que representa a los profesores adscritos al departamento y un atributo asignaturas de tipo Asignatura que representa la lista de asignaturas adscritas al departamento. De momento se ha omitido la definición de operadores específicos para estos tipos de objetos, lo que significa que el usuario tendría que utilizar operadores de consulta y actualización genéricos para manipular los objetos de la base de datos. Por ejemplo, si D es una variable del tipo Departamento, la expresión D.director.nombre permitiría seleccionar el nombre del director del departamento D, en la expresión se ha utilizado el operador selector de un atributo denotado con un punto. Asimismo, sería necesario utilizar los operadores genéricos de los tipos lista y conjunto para manipular algunos de los atributos del ejemplo.

En el esquema se puede advertir también que el tipo de un atributo puede ser otro tipo de objeto, con lo cual las relaciones entre objetos son vistas como propiedades del objeto, así una relación binaria entre objetos queda representada en cada uno de los dos objetos implicados en la relación. La relación de adscripción de los profesores en los departamentos, se representa en el objeto Departamento con el atributo profesores y en el objeto Profesor con el atributo dep. Desde un punto de vista conceptual, es transparente para el usuario del esquema, si los valores de estos atributos son instancias de objetos o referencias (punteros) a ellos.

Aunque no existe un modelo estándar, existen tres principios básicos que caracterizan un modelo orientado a objetos: abstracción de datos, identidad de objetos y herencia en jerarquía de objetos. A continuación van a ilustrarse estos principios con algunos ejemplos y posteriormente se concretarán en el modelo objeto-relacional del SQL3.

Identidad de objetos

En el Ejemplo 2.63, se ha puesto en evidencia las implicaciones que tiene el uso de referencias “por valor” en el Modelo Relacional. Para evitar esos problemas, en el Modelo Orientado a Objetos, todo objeto, instancia de una clase, tiene un identificador interno desde el momento de su creación, a este identificador se le conoce como OID (Object Identifier). El OID es generado por el sistema, no cambia durante la vida del objeto, no depende de valores de atributos ni de detalles de representación física del objeto, y no es visible para los usuarios. El OID es utilizado por el sistema para identificar unívocamente a los objetos en la creación y manipulación de relaciones entre objetos (referencias).

La existencia del OID, no evita el uso de identificadores externos (claves de usuario) ya que éstas representan la única forma de interactuar con el mundo exterior. A diferencia del caso relacional, cuando la claves de usuario de un objeto cambia, esto no obliga a cambiar las referencias al objeto desde otros objetos de la base de datos.

Ejemplo 2.68

En el Ejemplo 2.67, los atributos que se han definido de algún tipo de objeto no tienen por qué tener como valor una instancia del tipo, pueden contener su OID. A continuación se representa utilizando una notación totalmente intuitiva, una instancia de la clase Departamento, consistente en un par (OID,valor) ( i1, [código: ‘DSIC’, nombre: ‘Sistemas Informáticos’, director: i2 , teléfonos: {‘3708976’, ‘3456734’}, profesores: <i2, i13, i24>, asignaturas: <i15, i16, i23> ] )

Donde i1 es el OID del departamento de clave de usuario “DSIC”. El valor del objeto consiste en una tupla (denotada entre corchetes), con un valor para cada atributo. El valor del atributo director es un OID de objeto de tipo Profesor, el valor del atributo profesores es una lista (denotada entre < >) de referencias (OID) de objetos de tipo Profesor, y el valor del atributo asignaturas es una lista de referencias (OID) a objetos de tipo Asignatura.

Abstracción de datos

El principio de abstracción de datos, presente en todos los lenguajes de programación, consiste en separar la especificación de la implementación. Este principio que se aplica en distintos ámbitos de la programación (abstracción de funciones, abstracción de datos) también está presente en el mundo de las bases de datos. En los sistemas de bases de datos al principio de abstracción de datos se le conoce como independencia de datos, este concepto fue presentado en el tema I y volverá a estudiarse con mayor profundidad en el tema III.

En el Modelo Orientado a Objetos, el principio de abstracción de datos tiene como objetivo ocultar al usuario la estructura del objeto de forma que éste sea manipulable exclusivamente a través de métodos (consultores y constructores) definidos específicamente para él. A este hecho se le conoce como encapsulamiento del objeto. En un sentido estricto, todos los atributos (propiedades observables) del objeto deberían estar ocultos, lo que se conoce como encapsulamiento total, pero en la práctica esto es demasiado rígido e incómodo, por lo que se suelen mantener algunos atributos públicos (manipulables con operadores genéricos) y otros privados (manipulables con operadores específicos), a este tipo de encapsulamiento se le conoce como encapsulamiento parcial.

De acuerdo a esta idea del encapsulamiento, en la definición de un objeto se diferencias dos partes: interfaz del objeto, en la que se definen los atributos públicos y la especificación (signatura) de los métodos, y la implementación del objeto donde se definen los atributos privados así como la implementación de todos los métodos especificados en la interfaz. Decidir qué atributos deben ser públicos y cuáles privados es tarea del diseñador. Los atributos cuya actualización debe estar sujeta al cumplimiento de ciertas restricciones de integridad son candidatos a ser definidos como privados. Asimismo, el hecho de que una relación entre objetos se represente en todos los objetos implicados en la relación, aconseja que su actualización se haga por medio de métodos que se encargarían de actualizar consistentemente la relación en todos los objetos en la que está representada.

Ejemplo 2.69

Sea el sistema de información del Ejemplo 2.67. Si la docencia de un profesor estuviera sujeta a algunas restricciones sobre la carga lectiva dependiendo de la categoría del profesor, el atributo docencia de Profesor podría definirse como privado y especificar métodos para consultar la docencia de un profesor, para asignarle docencia o para anulársela. También y debido a que la relación de docencia entre profesores y asignaturas se representa simétricamente en ambos tipos de objetos, estos métodos deberían actualizar consistentemente el atributo docencia del par de objetos relacionados entre sí que en ambos casos debería definirse como privado

Clase Profesor ------ especificación de la interfaz del objeto ------

código

tira(4)

nombre

tira(20)

dirección tira(40)

teléfono tira(10)

categoría tira(3)

director Departamento

dep

Departamento

Método consultar_docencia: LISTA (TUPLA (Asg: Asignatura, gteo:entero, gprac:entero))

Método asignar_docencia (asg: Asignatura, gteo: entero, gprac:entero)

Método anular_docencia (asg: Asignatura)

Cuerpo Profesor -------- implementación del objeto ------

docencia LISTA (TUPLA (Asg: Asignatura, gteo:entero, gprac:entero))

Método docencia: LISTA (TUPLA (Asg: Asignatura, gteo:entero, gprac:entero))

--- código de la función docencia que devuelve la lista de asignaturas impartidas por el profesor para el que se invoca el método ------

Método asignar_docencia (asg: Asignatura, gteo: entero, gprac:entero)

--- código del procedimiento asignar_docencia que asigna al profesor para el que se invoca el método, gteo grupos de teoría, y gprac grupos de prácticas de la asignatura asg. Este método también actualizaría consistentemente el atributo docencia de la asignatura asg ----

Método anular_docencia (asg: Asignatura)

--- código del procedimiento anular_docencia que anula, al profesor para el que se invoca el método, la docencia en la asignatura asg. Este método también actualizaría consistentemente el atributo docencia de la asignatura asg -----

Herencia en jerarquía de objetos

Este principio consiste en la posibilidad de definir un nuevo tipo de objeto (subclase) a partir de otro ya definido (superclase). La clase Y es una subclase de la clase X si y sólo si todo objeto de tipo Y es también un objeto de tipo X. La clase Y hereda todos los atributos (herencia estructural) y métodos (herencia de comportamiento) de la clase X, pero puede contener atributos y métodos propios. Un objeto de la clase Y podrá ser utilizado en cualquier punto donde pueda ser utilizado un objeto de la clase X (principio de sustitutibilidad). En la subclase se puede cambiar la implementación de los métodos con lo que se cambia su semántica. Un tipo puede ser subtipo de varios tipos de objetos (herencia múltiple), en este caso hay que eliminar las ambigüedades que se pueden presentar por heredar propiedades del mismo nombre.

Ejemplo 2.70

Sea el sistema de información del Ejemplo 2.67. Supóngase que en el contexto de una universidad existen profesores numerarios (funcionarios por oposición) y profesores que no son numerarios (contratados) y que esto significa tener propiedades y tratamientos diferenciados. Por ejemplo, el profesor que no es numerario tiene un contrato laboral, cuyos datos deben registrarse, y sufre procesos especiales como la renovación anual de su contrato. Para el profesor numerario sin embargo existe otra información que es específica de él, como son algunos tipos de complementos salariales. Esta situación aconseja definir una jerarquía de tipos de objetos en la que aparecieran las clases Numerario y No Numerario como subclases de la clase Profesor ya definida, estas subclases heredarían todos los atributos y métodos de Profesor pero tendrían sus atributos y métodos propios.

El modelo objeto-relacional de SQL3

El lenguaje SQL3 soporta un modelo que no es relacional puro como en las versiones anteriores del lenguaje, sino objeto-relacional. El término objeto-relacional se ha acuñado para referirse a un modelo de datos que extiende el modelo relacional con conceptos de la orientación a objetos. Las novedades más significativas del modelo objeto-relacional del SQL3 son:

  • tipos estructurados: tupla y vector.

  • tipos de objetos: identidad, abstracción y herencia.

  • tipos de referencia: sus valores son identificadores (OID) de objetos.

  • relaciones de objetos.

El modelo es orientado a objetos porque incorpora el concepto de objeto, respetando los tres principios de identidad de objetos, abstracción de datos y herencia en jerarquía de objetos. El modelo sigue siendo relacional porque las estructuras de la base de datos siguen siendo relaciones, que ahora podrán definirse como en el caso clásico o como relaciones de objetos. El lenguaje extiende la sintaxis de las sentencias de manipulación para poder tratar con relaciones de objetos. A continuación se presentan con un poco mas de detalle estas novedades.

El usuario dispone de constructores de tipos estructurados predefinidos: ROW (tupla) y ARRAY (vector). Estos tipos pueden utilizarse en la definición de los atributos del esquema de una relación o en la definición de tipos de objetos.

La sintaxis para el tipo ROW es:

ROW (campo1 tipo1, campo2, tipo2, ..., campon tipon)

Los campos se seleccionan utilizando una notación de punto (tupla.campoi). Existe el constructor de un valor del tipo con la sintaxis (campo1 valor1, campo2, valor2, ..., campon valorn).

La sintaxis para el tipo ARRAY es:

tipo_base ARRAY [dimensión]

En la sintaxis dimensión es una constante de tipo entero que indica la cardinalidad máxima del vector. Los elementos del vector se seleccionan por el ordinal del elemento (vector[i]). Existe el constructor de un valor del tipo con la sintaxis ARRAY[valor1, valor2, ..., valorn]. El tipo de los elementos puede ser cualquier tipo de datos excepto ARRAY y los vectores sólo pueden ser unidimensionales.

Ejemplo 2.71

En el esquema relacional del Ejemplo 2.35, el uso de estos constructores de tipo, permitiría una definición más correcta del la relación Profesor. El atributo nombre podría definirse como una tupla de tres campos (nombre, primer apellido y segundo apellido) y el atributo teléfono como un vector de números de teléfono lo que permitiría asociar más de un teléfono al profesor sin tener que recurrir a la solución adoptada en el Ejemplo 2.64.

CREATE TABLE Profesor

    ( codigo CHAR(5),

    nombre ROW (nombre CHAR(15), ape1 CHAR(15), ape2 CHAR(15) ) NOT NULL,

    teléfonos CHAR(11) ARRAY [5],

    categoría CHAR(3) NOT NULL

        CHECK categoría IN (‘TEU’, ‘TU’, ‘CEU’, ‘CU’),

    dep CHAR(5) NOT NULL,

    CONSTRAINT CP_prof PRIMARY KEY (codigo),

    CONSTRAINT CAj_prof_dpto FOREIGN KEY (dep)

        REFERENCES Departamento (codigo)

        ON UPDATE CASCADE

    )

El usuario puede definir en el esquema de la base de datos tipos de objetos, estos tipos podrán ser utilizados en la definición de los atributos del esquema de una relación, en la definición de otros tipos de objetos o como tipo base de una relación (relaciones de objetos). La sintaxis para la definición de un tipo de objeto es:

CREATE TYPE nombre_tipo AS (atributo1 tipo1,....., atributon tipon)

--- interfaz del objeto ---

[NOT] FINAL

[REF IS SYSTEM GENERATED

REF USING tipo_básico

REF FROM (atributoi [, atributok [,...] )]

[METHOD nombre_método ([parámetro1 tipo1, ..., parámetron tipon]) RETURNS tipo] ...

CREATE INSTANCE METHOD nombre_método ([parámetro1 tipo1, ..., parámetron tipon])

--- implementación ---

RETURNS tipo

FOR tipo_objeto

BEGIN ... END.

En la definición se da nombre al tipo y se especifican los atributos públicos del objeto, así como los métodos definidos sobre él. La cláusula [NOT] FINAL obliga a indicar si sobre el tipo se podrán definir subtipos o no. Los atributos pueden ser de cualquier tipo de datos predefinido en el sistema o definido por el usuario. Para seleccionar un atributo se utiliza la notación de punto.

En SQL3 los métodos son funciones. Un método se invoca usando también la notación de punto. Entre los parámetros de cualquier método, siempre existe un parámetro implícito (no hace falta declararlo) del tipo de objeto al que va asociado el método; en una invocación del método el valor de este parámetro es el objeto para el que se hace la invocación. En el código que implementa el método se puede hacer referencia a este parámetro con la palabra reservada SELF.

En SQL3 el comportamiento de un objeto también puede definirse por medio de rutinas (funciones o procedimientos) escritos en SQL/PSM, el lenguaje de programación incorporado al modelo. Estas rutinas estarán definidas en el esquema de la base de datos, y deberán llevar al menos un parámetro del tipo de objeto para el que se define la rutina.

Para crear valores de un tipo de objeto existen constructores genéricos, el constructor de la instancia vacía, y el constructor de una instancia del tipo:

NEW tipo_objeto ()

NEW tipo_objeto (atributo1 valor1, ..., atributon valorn).

---constructor de instancia vacía---

---constructor de instancia ---

también se pueden definir constructores específicos como métodos.

Ejemplo 2.72

En el esquema relacional del Ejemplo 2.35, la relación Profesor podría definirse de forma mas precisa utilizando las facilidades de definición de tipos que proporcional el lenguaje SQL3.

CREATE TYPE datos_laborales AS

(trienios INTEGER,

---años de antigüedad----

quinquenios INTEGER,

---méritos docentes evaluados cada cinco años----

sexenios INTEGER)

--- méritos de investigación evaluados cada seis años ----

FINAL

METHOD complemento () RETURNS INTEGER );

CREATE INSTANCE METHOD complemento () RETURNS INTEGER

FOR datos_laborales

BEGIN

RETURN (SELF.trienios*30+SELF.quinquenios*60+SELF.sexenios*70)

END;

CREATE TABLE Profesor

( codigo CHAR(5),

nombre ROW (nombre CH CHAR(15), ape1 CHAR(15), ape2 CHAR(15)) NOT NULL,

telefonos CHAR(11) ARRAY [5],

categoria CHAR(3) NOT NULL

CHECK categoría IN (‘TEU’, ‘TU’, ‘CEU’, ‘CU’),

meritos datos_laborales,

dep CHAR(5) NOT NULL,

CONSTRAINT CP_prof PRIMARY KEY (codigo),

CONSTRAINT CAj_prof_dpto FOREIGN KEY (dep)

REFERENCES Departamento (codigo)

ON UPDATE CASCADE

)

El método complemento devuelve el complemento salarial del profesor derivado de los méritos acumulados. En este ejemplo el método sirve para definir un atributo derivado.

Una invocación al método complemento podría ser la siguiente:

SELECT codigo, nombre, meritos.complemento

FROM Profesor

WHERE dep=”DSIC”

La inserción de un nuevo profesor se haría con la siguiente instrucción INSERT:

INSERT INTO Profesor

VALUES (“MCG”, “María Cantó Giner”, ARRAY [ ], “TEU”, NEW datos_laborales ( ), “DSIC”)

En este caso, los atributos teléfonos y meritos se han inicializados como vacios.

La actualización de los atributos telefonos y meritos para un profesor se haría con la siguiente instrucción UPDATE:

UPDATE Profesor

SET telefonos = [77654, 77890]

meritos=NEW datos_laborales (trienios 3, quinquenios 1, sexenios 0)

WHERE codigo=”MCG”

Como ya se ha comentado una de las características más significativas del modelo objeto-relacional del SQL3 es la posibilidad de definir relaciones de objetos, es decir relaciones definidas sobre un tipo de objeto. En este caso, las tuplas de la relación son instancias del tipo de objeto sobre el que se define la relación. Los valores de un tipo de objeto (instancias) sólo tienen asignado un identificador (OID) cuando se almacenan como tuplas de una relación, este OID es asignado automáticamente por el sistema en el momento de la inserción. El diseñador puede elegir la forma de implementar los identificadores de un tipo de objeto, esto se hace con la cláusula REF en la definición del tipo: REF SYSTEM GENERATED significa que los identificadores serán generados por el sistema, REF USING tipo_básico significa que el sistema utilizará un tipo escalar predefinido, y REF FROM lista_atributos, significa que el sistema construirá el identificador a partir de los valores de los atributos especificados.

Para poder hacer referencia a un objeto desde otro objeto por medio de su OID, se introduce el tipo de datos de referencia. La sintaxis de definición de un tipo de referencia es REF tipo_objeto.

La notación que se usa para seleccionar atributos (o métodos) del objeto referido por una valor de referencia es la flecha (valor → atributo).

La sintaxis para la definición de una tabla de objetos es:

CREATE TABLE nombre_tabla OF tipo_objeto

(REF IS atributo {SYSTEM GENERATED USER GENERATED  DERIVED},

[lista_restricciones] )

donde la cláusula REF obliga a definir un atributo para contener el OID del objeto, y lista_de_restricciones permite definir restricciones sobre la relación (clave primaria, valor no nulo, etc) que no pueden aparecer en la definición del tipo de objeto, así como restricciones de alcance para los atributos de referencia.

Ejemplo 2.73

A continuación se presenta un ejemplo de la definición de una relación de objetos y del uso de los tipos de referencia.

CREATE TYPE Persona AS

(DNI

INTEGER,

nombre VARCHAR(60)

)

REF IS SYSTEM GENERATED;

CREATE TABLE Autores OF Persona

(REF id_autor IS SYSTEM GENERATED);

CREATE TABLE Informes

(nro

INTEGER,

titulo

VARCHAR(100),

autor

REF (Persona),

claves

VARCHAR(10) ARRAY [5 ],

formato ROW (paginas INTEGER,

tipo_letra CHAR(10),

tamaño INTEGER) )

(autor WITH OPTIONS SCOPE Autores);

El atributo autor de la relación Informes es de un tipo de referencia, sus valores son identificadores (OID) de instancias del tipo Persona, en este caso estos identificadores son generados por el sistema. Las instancias del tipo Persona almacenadas en la relación Autores guardan su OID en el atributo id_autor. La cláusula WITH OPTIONS SCOPE en la definición de la relación Informes, permite indicar que las instancias del tipo Persona referidas desde el atributo autor deben buscarse en la relación Autores definida sobre el tipo Persona.

Una posible consulta sobre la base de datos relacional correspondiente al esquema anterior, que devolvería los títulos del autor Juan García, sería:

SELECT I.título, I.formato.paginas

FROM Informes I

WHERE I.autor → nombre =‘Juan García’