En dos secciones de la especificación de la clase: • Definición de atributos. • Restricciones de integridad estáticas. Cada clase se representa como una tabla dentro de su propio esquema. Las columnas de esta tabla serán cada uno de sus atributos constantes y variables. Cada ejemplar de la clase será una fila en la tabla. Los atributos derivados se representarán como una columna de la tabla o como una función dependiendo del diseñador. Si se ven como atributos virtuales, la función que calcule su valor tendrá que definirse en el paquete que, como veremos más tarde, incluirá los servicios del objeto. Si elegimos almacenarlos, se definirán de la misma manera que los otros, pero además será necesario declarar disparos que mantengan actualizado este campo (por ejemplo, disparos pre-insert y pre-update asociados a la tabla). Los atributos que componen el identificador de los objetos de la clase se representarán como la(s) columna(s) que constituye(n) la clave primaria de la tabla. Los atributos constantes por definición son not null. Los atributos variables se definirán como not null si deben introducirse obligatoriamente como un argumento del evento de creación o si se han declarado con un valor por defecto. Toda esta información se habrá introducido a nivel conceptual durante la definición de la clase. Las restricciones de integridad estáticas se representarán como restricciones de la tabla, que se validarán sobre los atributos del objeto. Como ejemplo, podemos ver la siguiente sentencia CREATE TABLE para la clase Trabajos: CREATE TABLE Trabajos (nro_trabajo(6) CONSTRAINT pk_trabajo PRIMARY KEY CONSTRAINT ck_trabajo CHECK(nro_trabajo<200000), descripcion varchar(50) NOT NULL, centro_trabajo number(5) CONSTRAINT fk_cen REFERENCES centros(cen_num), especialidad_trabajo number(3) CONSTRAINT fk_esp REFERENCES especialidades (esp_num), programa_economico number(2) CONSTRAINT fk_peco REFERENCES programas(num_pro), situacion number(2) DEFAULT 0, nro_marcas number(2) DEFAULT 0, control number(2) DEFAULT 0) Agregación Cuando se define una clase como agregada la cardinalidad asociada al enlace establecido entre la clase compuesta y su clase componente determinará dónde se incluye la restricción de clave ajena correspondiente. La clave ajena representará la agregación. Como se hace normalmente, una cardinalidad (máxima) de 1:M generará una clave ajena en la clase que participa con cardinalidad M en la agregación. Esto ocurre por ejemplo con trabajos y centros, siendo centro_trabajo la clave ajena de trabajos. En este caso, centros es una agregación de trabajos con cardinalidad 1:M. Una cardinalidad 1:1 generará (al menos) una clave ajena, y una cardinalidad M:N generará una tabla nueva cuya clave primaria será la compuesta por las claves de las clases componentes, en este caso la clave primaria de la nueva tabla también será la clave ajena que referenciará las tablas componentes. Las claves ajenas que representan a las clases componentes se definirán como atributos NOT NULL en la tabla agregada si la cardinalidad mínima es 1. De forma muy resumida, la agregación en Oasis tiene una taxonomía muy rica que determina una gran cantidad de situaciones que se pueden dar en una agregación. Dependiendo de los tipos de agregación (especificados en el modelo conceptual) sabremos la cardinalidad de la relación entre contenedor y componentes. Una vez conocido el tipo de agregación manipularemos la cardinalidad como se hace normalmente [Teo86], y etiquetaremos la restricción de clave ajena con null, restrict o cascade para las operaciones de actualización y borrado según corresponda. Esta conversión se explica con ejemplos en [Pas94]. Herencia En Oracle una clase especializada se representará como una tabla que tendrá como clave primaria la de su clase padre. Las columnas de esta tabla serán los atributos que no pertenecen a la clase padre. Si no existen atributos especializados podremos implementar la herencia como una vista de la clase padre. 3.2. La Dinámica La dinámica de los objetos se define mediante los eventos y transacciones que pueden activarse, los estados válidos por los que puede pasar un objeto durante su vida (process), las restricciones de integridad dinámicas que deben satisfacerse y la interfaz de usuario que caracteriza la interacción del usuario. Por ello en Oracle debemos ser capaces de representar: • Eventos: Evaluaciones, Precondiciones y Disparos. • Transacciones y Procesos • Interfaces Eventos, Transacciones y Disparos se implementan mediante procedimientos y disparos almacenados en el esquema asociado a la clase. Para representar los procesos adecuadamente será necesario introducir el concepto de orden en el espacio de eventos y transacciones, un concepto que no existe en el Modelo Relacional. Los eventos de un objeto se representan como procedimientos y funciones en un paquete. El paquete correspondiente a la clase trabajos de nuestro ejemplo será: create package trabajos_pack as procedure crear_trabajo (nro_trabajo number, descrip char, cent_trab number, esp_trab number,pro_economico number); procedure borrar_trabajo (num_trab number); procedure marcar (nro_trabajo number, uc number); procedure desmarcar (nro_trabajo number); procedure contratar (nro_trabajo number, dni number); procedure cerrar_trabajo (nro_trabajo number) end trabajos_pack; Los eventos y las transacciones se representarán como procedimientos que podrán tener argumentos. Los argumentos de los procedimientos se podrán utilizar en las acciones definidas en la fórmula de evaluación. Cada procedimiento posee una excepción que representará la precondición del evento. Si no se cumple la precondición, se eleva la excepción asociada y se efectúa un rollback de los cambios. Vamos a ver por ejemplo el procedimiento asociado al evento marcar de la clase trabajos: procedure marcar (nro_trab number,uc number) is exc_marcar exception; uc_ac number(2); begin select control into uc_ac from trabajos where nro_trabajo=nro_trab if uc_ac !=0 then raise exc_marcar; end if; update trabajos set control = uc, nro_marcas = nro_marcas + 1 where nro_trabajo=nro_trab; end marcar; y para la transacción cerrar_trabajo tenemos el siguiente procedimiento: procedure cerrar_trabajo (nro_trab number) is begin borrar_trabajo (nro_trab); personas_pack.despedir(nro_trab); end cerrar_trabajo; Los eventos compartidos los representamos mediante un procedimiento que está presente en los paquetes de las clases en las que está definido. Para reutilizar código lo implementaremos en el paquete de una clase y los demás paquetes lo tendrán definido como una referencia a éste. En el paquete de una clase especializada, tendremos que definir los eventos de la clase padre referenciándolos como hemos visto anteriormente. El evento de creación inserta una fila (se corresponderá con un nuevo objeto) en la tabla. Cuando se cree un objeto activo también se creará un usuario para dicho objeto. Con este fin se definirá una transacción en la que se incluirá la secuencia de eventos que han de ocurrir y se traducirá a Oracle como un procedimiento que ejecute la secuencia de eventos y realice un commit cuando termina cada una de las operaciones. Si ocurre una excepción asociada a un evento componente de la transacción, entonces se hará un rollback de los cambios que hayan tenido lugar para asegurar la política de "todo-o-nada" y la "no-observabilidad de estados intermedios". Las transacciones también pueden tener argumentos. Los disparos podrán implementarse como disparos de la base de datos que se ejecutan como resultado de una acción de inserción o borrado. En la especificación de una clase, el proceso (la sección process en Oasis o el DTE en el modelo dinámico) define la secuencia válida de eventos en la vida de un objeto. Un objeto cambia de estado ante la ocurrencia de un evento o transacción, por lo que, para saber si el evento ocurrido es válido tendremos que comprobar si forma parte de una secuencia válida de eventos (comprobando que en el estado6 en el que se encuentra y ante la ocurrencia del evento, puede alcanzar un nuevo estado en el proceso definido). Para poder realizar estas comprobaciones podemos incluir en la tabla asociada a la clase un nuevo atributo donde guardaremos el estado actual (en el proceso) del objeto. Con esta información podremos invalidar la ocurrencia de un evento que no forme una vida válida (secuencia de eventos), añadiendo una nueva excepción en el código del procedimiento asociado con el evento o transacción. Las acciones que pueden activar los objetos se especifican como interfaces entre objetos y se implementan como privilegios concedidos a los usuarios. Por ejemplo, si en la especificación hemos dicho que un objeto O1 de la clase C1 puede ser actor de un evento E2 definido en la clase C2, lo traduciremos a Oracle-v7 dándole al rol asociado con C1 permisos de ejecución sobre el procedimiento E2 definido en el paquete correspondiente a C2, y añadiremos el objeto O1 al rol de C1. En el ejemplo propuesto, hemos asumido que los administradores serán los usuarios finales activos. Así pues, como podemos ver a continuación para un usuario crearemos un usuario administrador adm1, y lo incluiremos en el rol admin (se asume ya creado) que tendrá concedidos los privilegios de ejecución sobre los procedimientos del paquete '