Mer

Modelo de Entidad Relacin

El anlisis de datos y de funciones se complementan y apoyan en el proyecto de un sistema. Dan informacin y modelos complementarios. Un buen anlisis de datos es aquel que ha tenido en cuenta el anlisis de funciones. Un buen anlisis de funciones se debe apoyar en un anlisis de datos. Modelo de datos: es la representacin de la estructura esttica de los datos de un sistema. Modelo funcional: representa la estructura dinmica de los procesos. MODELO DE ENTIDAD RELACION (M.E.R.) Es una herramienta grfica que se utiliza para modelar los datos. Es un modelo de red que describe con un alto nivel de abstraccin la distribucin de datos almacenados en un sistema. Definiciones: Entidad u objeto: es una representacin abstracta de un objeto del mundo real. Es algo que puede identificarse en el ambiente de trabajo de los usuarios, es algo importante para los usuarios del sistema que se va a desarrollar. Puede ser un hecho, una cosa, un organismo social. Ejemplos de entidades u objetos: . Empleado Jos . Cliente 1237 . Pedido de venta 786 . Vendedora Marta . Artculo AC105 Clase de entidades o tipos de objetos: las entidades o los objetos se agrupan en conjuntos del mismo tipo llamados clases de entidades o tipos de objetos. Una clase de entidad o tipo de objeto es la forma general o descripcin de algo (CLIENTE), en tanto que una ocurrencia es la representacin de una entidad u objeto particular (cliente 1237). Las clases de entidades se representan en maysculas mientras que las entidades se representan en minsculas. En el M.E.R. las clases de entidades se representan con un rectngulo. Caractersticas de una clase de entidades: - Puede identificarse de manera nica por algn medio. - Juega un papel necesario en el sistema que se construye. - Puede describirse por uno o ms datos (atributos), es decir, CLIENTE puede describirse por medio de datos tales como nombre, domicilio, telfono, lmite de crdito, etc.

Un sistema y una entidad pueden tener el mismo nombre, pero representan cosas diferentes. Ejemplo: Compras: - como sistema, es un conjunto de procesos, estructuras de datos que tienen como objetivo el manejo de informacin sobre las compras de una empresa. - como entidad, es un evento, una transaccin, un hecho. Atributos: son las propiedades que describen las caractersticas de una entidad u objeto. Ejemplo: la entidad AUTO tiene los atributos: marca, modelo, patente, color, nro. de puertas, etc. Caractersticas de los atributos: 1 - Puede tomar un valor nulo. En algunos casos es necesario definir una restriccin de integridad para impedir que tome un valor nulo. Ejemplo: en la entidad CLIENTE el atributo telfono puede tomar un valor nulo pero el atributo nombre siempre debe tener un valor. 2 - No pueden definirse atributos multivalentes , es decir, no pueden tomar ms de un valor. Ejemplo: Empleados : Nombre + Direccin + Salario + Telfonos. El atributo telfonos se debe dividir en Telfono Particular y Telfono Comercial 3 - No pueden definirse atributos compuestos, es decir, formado por varios sub-atributos. Ejemplo: Domicilio est formado por Direccin (calle y nro.) , Cdigo Postal , Ciudad . 4 - Atributo determinante: es un atributo que toma un valor nico de forma tal que determina unvocamente a la entidad. Se lo llama atributo clave o llave. Relaciones: las entidades se conectan entre s mediante las relaciones. Una relacin representa un conjunto de conexiones. Grficamente se representa con un rombo. Caractersticas de las relaciones : 1 - Representan algo que debe ser recordado por el sistema: algo que no puede calcularse ni derivarse mecnicamente. 2 - Las relaciones tienen ocurrencia y tambin pueden tener atributos. 3 - Puede existir ms de una relacin entre dos entidades y mltiples relaciones entre mltiples entidades. 4 - Una relacin puede incluir muchas entidades, la cantidad de entidades en una relacin es el grado de la relacin. La relacin VENDEDOR-PEDIDO es de grado 2 o binaria, porque cada ocurrencia de la relacin implica dos ocurrencias de entidades: una ocurrencia vendedor y una pedido. Aunque el DER permite relaciones de cualquier grado la mayora de las aplicaciones del modelo slo consideran relaciones de grado 2, que son relaciones binarias. Tipos de relaciones binarias (cardinalidad): 1 - Relaciones con el mximo de restriccin o relaciones uno a uno (1:1):

En una relacin 1:1 una ocurrencia de una entidad se relaciona con slo una ocurrencia de otra entidad. Ejemplo: en la relacin ASIGNA cada EMPLEADO de una empresa tiene asignado un AUTO para su movilidad y ningn AUTO se asigna a ms de un empleado. 2 - Relaciones con algn tipo de restriccin o relaciones uno a muchos (1:N): En una relacin 1:N una ocurrencia de una entidad se relaciona con muchas ocurrencias de otra entidad. Ejemplo: en la relacin OCUPA cada ESTUDIANTE ocupa un dormitorio pero un DORMITORIO est ocupado por varios ESTUDIANTES. 3 - Relaciones con ninguna restriccin o relaciones muchos a muchos (N:N): En una relacin N:N muchas ocurrencias de una entidad se relacionan con muchas ocurrencias de otra entidad. Ejemplo: en la relacin ESTUDIANTE-CLUB un ESTUDIANTE puede inscribirse en ms de un CLUB y en un CLUB puede haber como miembros muchos ESTUDIANTES. Representaciones de las relaciones: Las relaciones pueden representar: 1- un evento. Ejemplo CLIENTE COMPRA FACTURA

2- se le puede asociar a la entidad un atributo multivalorado, que se lo considera como otra entidad. Ejemplo CLIENTE CLIENTE / CTA. CTE. (tiene) CTA. CTE.

Atributos de una relacin: el valor de estos atributos depende de los valores de las dos entidades. Ejemplo MATERIALES cdigo telfono nombre descripc. precio Autorelaciones o relaciones recursivas. Es una relacin que asocia elementos de un conjunto de entidades (E) a elementos de ese mismo conjunto (E). Generalmente de utilizan para representar jerarquas o subordinacin. EMPLEADO COMPRA condiciones cantidad nro. proveedor plazo PROVEEDOR nombre direccin

JEFE Particionamiento de un conjunto.

Se realiza cuando un conjunto de entidades representan elementos del mundo real que se subdividen en categoras con atributos parcialmente distinto. Se representa anexando al diagrama un rombo con una lnea arriba. Pueden definirse relaciones y atributos para todo el conjunto de entidades o para una categora en particular. Nombre Documento Direccin EMPLEADO localiz. DEPARTAMENTO

ADMINIST.

GERENTES

OBREROS

Pasos alternativos para realizar el MER

1- Identificar las entidades y los atributos 2- Identificar las relaciones 3- Racionalizar el modelo, eliminando las relaciones redundantes, y los atributos derivados y

redundantes
4- Realizar el Diccionario de Datos 5- Validar el modelo con el Diccionario de Datos

Comentarios y Notas: Una entidad normalmente tiene existencia propia, un valor de una atributo o una relacin slo existe vinculado a una entidad. Una entidad normalmente es identificada por un atributo unvoco. El MER es un modelo esttico, por lo tanto no se representan las caractersticas dinmicas del sistema. Las entidades y las relaciones son archivos. La relacin es un archivo fsico cuando existen atributos de la relacin, es un archivo lgico cuando no tiene atributos. Normalizacin de los datos Se realiza de forma de obtener la mxima independencia de datos y eliminar las redundancias innecesarias. Ejemplo: datos de un archivo de empleados obreros de la construccin.

Nro. Empl. 51 35 50 77

Cd.Capa c. 113 113 179 204 179 148 113

Descr.Capa c. electricidad electricidad gas plomera gas cielo raso electricidad

Nombr Edad Cd. Obra e Perez 35 52 Garca 32 44 Gomez 30 Torres 36 40 44

Ciudad Trab. Crdoba Mendoza San Juan Mendoza

Calific. 3 5 1 6 2 6 6

Primera Forma Normal: Se dice que una tabla es de 1FN cuando se ha definido una llave para la tabla y por lo tanto no hay atributos que tomen ms de un valor (no existen atributos multivalorados). Para evitar que existan ms de un valor para un casillero de la tabla se definen 7 en vez de cuatro. La llave que se define es compuesta: nro. de empleado / nro. de capacitacin.

Nro. Empl. 51 35 35 35 50 77 77

Cd.Capa c. 113 113 179 204 179 148 113

Descr.Capa c. electricidad electricidad gas plomera gas cielo raso electricidad

Nombr e Perez Garca Garca Garca Gomez Torres Torres

Edad Cd. Obra Ciudad Trab. 35 52 Crdoba 32 44 Mendoza 32 44 Mendoza 32 44 Mendoza 30 40 San Juan 36 44 Mendoza 36 44 Mendoza

Calific. 3 5 1 6 2 6 6

Segunda Forma Normal: Se define una tabla en 2FN cuando todos los atributos no llaves dependan totalmente de la llave. Para verificar que esto suceda se analizan las dependencias entre las columnas: determina Nro. Empleado Nro. Empleado Nro. Empleado Nro. Empleado Cd. Capacit. Cd. Obra N.Empl/C.Cap. Cdigo Capacitacin Nombre Edad Cdigo Obra Descrip. Capacitacin Ciudad Nombre

Solamente la calificacin depende totalmente de la llave. Para resolver la 2FN se puede desglozar la tabla original en una serie de tabla original en una seire de tablas, segn se muestra a continuacin.

Nro. empleado 21 35 50 77 Nro. empleado 21 35 35 35 50

Nombre Perez Garca Gomez Torres Cd. Capacitacin 113 113 179 204 179

Edad 35 32 30 36 Calificacin 3 5 1 6 2

Cd. Obra 52 44 40 44

Ciudad Trabajo Crdoba Mendoza San Juan Mendoza

77 77 Cdigo Capacitac. 113 179 204 148

148 361 Descrip. Capacit. electricidad gas plomera cielo raso

6 6

En cada tabla se comprueba que las columnas no llaves dependen totalmente de la llave. Se observa que se han eliminado las redundancias. Tercera Forma Normal: Se verifica que las columnas no llaves sean independientes entre s. En las tablas definidas anteriormente se ve que: Cdigo Obra Ciudad

Nro. empleado Nombre 21 Perez 35 Garca 50 Gomez 77 Torres Tabla de empleados Cd. Obra 52 44 40 44 Tabla de Obras Ciudad Trabajo Crdoba Mendoza San Juan Mendoza

Edad 35 32 30 36

Cd. Obra 52 44 40 44

Nro. empleado

Cd. Capacitacin 21 113 35 113 35 179 35 204 50 179 77 148 77 361 Tabla de Calificacin

Calificacin 3 5 1 6 2 6 6

Cdigo Descrip. Capacitac. Capacit. 113 electricidad 179 gas 204 plomera 148 cielo raso Tabla de Capacitacin
Se comprueba lo siguiente:
1- se ha eliminado la redundancia 2- se agrupan los datos que se refieren a una entidad, o sea que son los atributos de una entidad. 3- se puede verificar que todas las tablas se relacionan entre s por medio de las llaves.

Ctedra : D I S E O D E S I S T E M A S T e r c e r A o - INGENIERIA EN SISTEMAS DE INFORMACIN U. T. N. - Facultad Regional Mendoza - 1998 Prof.: Poblete C.(teora), Fontana G. y Rotella C.

Herencia en entidades y su impacto en persistencia

Herencia en entidades
La principal capacidad del paradigma de orientacin a objetos es la herencia con todas las consecuencias positivas que atrae. Desde el punto de vista tcnico la herencia entre objetos permite el uso del polimorfismo, sobremanejo, sobrecarga, abstraccin e implementacin. Todos aspectos muy necesarios en las soluciones de software modernas. En algunas situaciones el uso de la herencia no es tan evidente como se quisiera y deben adoptarse modelos no tan sencillos a primera vista. El caso que vemos en este documento es el de la herencia entre entidades, que se ve dificultado por los esquemas interfaz agente e implementacin:

En el genrico

esquema mostrado

no se ve tan claramente cmo debe ser la herencia en caso de existir entidades especficas. Vamos a tomar de ejemplo el caso de la clase Persona, que puede representar muchas personas distintas con capacidades y roles diversos en una misma aplicacin. Inicialmente la clase Persona podra contener:

En este caso se ve una entidad muy sencilla a modo de presentacin. La clase PersonaImpl es la que realmente posee los atributos necesarios para la entidad. Si quisiramos introducir informacin necesaria de otras personas de acuerdo a distintas responsabilidades y comportamientos dentro de la aplicacin podramos agregarla dentro de la entidad persona que se ha representado. En el caso de las personas que actuan como vendedores necesitaremos algunos datos extras como el legajo y el porcentaje de comisin. En el caso de las personas que actuan como clientes necesitaremos datos como CUIT (limitando de esta manera la capacidad de registrar clientes que son responsables inscriptos, es solo a modo de ejemplo). El esquema quedara:

Si bien es posible guardar informacin en la

entidad Persona tanto para los clientes como para los vendedores, la coherencia de esta entidad es muy mala. La solucin ideal es aplicar herencia y crear subclases para representar las personas especficas: Cliente y Vendedor. La solucin parece ser muy sencilla en primer instancia ya que parece ser una simple herencia. El planteo genrico ser:

Debe quedar claro que la entidad Persona existe nicamente por reutilizacin y no representa una entidad en el modelo real, ya que no existen personas que no sean clientes o vendedores (en la aplicacin que se est modelando). En este caso la entidad Persona respeta el patrn Fabricacin Pura. El esquema representa una herencia en donde no existen interfaces o agentes, solo implementaciones. Esto puede sugerir el hecho de que solamente se generen las subclases del esquema y no las interfaces y los agentes, pero no es as y es all donde se complica un poco:

En primer lugar es necesario observar que el cliente no es una persona porque no existe herencia en ningn momento, y en segundo lugar debemos preguntarnos cmo debe realizarse la herencia, quin hereda de quin?

Empecemos por la ms sencilla. La clase ClienteImpl es la que posee los atributos y por lo tanto debera poseer los atributos de la entidad Persona, lo que nos lleva a pensar que debera heredar de PersonaImpl, y de hecho es correcto:

Recordemos que cuando los objetos que son el resultado de bsquedas por parte de la persistencia son visualizados por los expertos como interfaces, con el fin de ocultarles la realidad sobre la existencia de agentes e implementaciones. A tal fin, en el caso de buscar clientes deberemos responder con interfaces de cliente, en este caso la interfaz Cliente. Si as lo hiciramos el experto que obtenga las interfaces como respuesta solamente podr acceder al CUIT del cliente y no al nombre y al apellido, lo que no es deseable. Por lo tanto la solucin ideal es crear una relacin de herencia entre interfaces:

En el esquema queda claro que al responderle a los expertos con interfaces de cliente, los expertos podrn acceder a todos los datos existentes en un cliente, no solamente el CUIT. En tercer lugar, deberemos ver cmo relacionamos los agentes. Suponiendo que tanto la entidad Persona como la entidad Cliente poseen relaciones con otras entidades, ambas harn uso de la bsqueda tarda por medio de los agentes correspondientes. Esto plantea la necesidad de que el agente de la entidad Persona deba ser capaz de recuperar bajo demanda las entidades relacionadas a Persona. Y plantea, adems, la necesidad de que el agente de la entidad Cliente deba ser capaz de recuperar bajo demanda las entidades relacionadas a Persona y relacionadas a Cliente, ya que el cliente es una persona. En esta situacin tenemos 2 opciones: que cada agente implemente la lgica para recuperar sus entidades relacionadas, lo que plantea que el agente de Cliente deba repetir el proceso para las entidades relacionadas a Persona; o que exista una

10

relacin de herencia entre ellos a fin de reutilizar la lgica planteada por el agente de la entidad Persona. Evidentemente la ltima opcin es la correcta y el esquema sera:

Hasta aqu cada planteo en forma aislada es sencillo y correcto, veamos como queda el esquema completo y qu error existe en el mismo:

All se puede apreciar como una sencilla herencia evidente entre 2 entidades puede verse afectada al formar parte de un esquema robusto como el de persistencia. Sin embargo hemos encontrado un mecanismo intuitivo para determinar las relaciones de herencia correctas. Aun as existe un inconveniente en el esquema que plantea una ambigedad en el agente de Cliente. El hecho de que el agente de Persona se relaciona con la implementacin de Persona significa que el agente de Cliente tambin se relaciona con la implementacin de Persona, pero este a su vez tambin se relaciona con la implementacin de Cliente, lo que es incorrecto ya que la implementacin de Cliente es una implementacin de Persona gracias a la herencia existente entre ellas.

11

Cmo es posible solucionar este inconveniente? Es posible eliminar la relacin de herencia entre las implementaciones, pero ya vimos que es necesaria. Es posible eliminar la relacin de herencia entre los agentes, pero esta tambin es necesaria. Es posible eliminar la relacin entre el agente y la implementacin de Persona, pero no se podran realizar bsquedas tardas. Es posible eliminar la relacin entre el agente y la implementacin de Cliente, pero no se podran realizar bsquedas tardas. Aun as esta es la solucin correcta, porqu? Porque una implementacin de Cliente ES UNA implementacin de Persona. Esto permite modificar el esquema:

En el esquema se puede apreciar que AgenteCliente se encuentra relacionado con ClienteImpl (aunque no exista una relacin directa), la relacin la ha heredado de AgentePersona, quien se relaciona con PersonaImpl. Y como dijimos, ClienteImpl ES UNA PersonaImpl. Es como si la relacin estuviese dibujada, si no la hubiramos eliminado AgenteCliente estara relacionado 2 veces con ClienteImpl, lo que no es correcto. A medida que la jerarqua de herencia crece este diagrama se repite una y otra vez, siempre manteniento la relacin Agente-Implementacin en la entidad de nivel superior. En algunos casos, algunos grupos han planteado la necesidad de poseer una clase denominada a veces ObjetoPersistente que permite introducir en l la necesidad del OID. Si ObjetoPersistente se plantea como una clase tanto AgentePersona como PersonaImpl debern heredar de l. En cambio, si se plantea como una interfaz, solamente la interfaz Persona deber heredar de ella. Recuerden que esta herencia solamente debe realizarse en

12

el nivel superior, y posteriormente por las relaciones de herencia se traslada a los siguientes niveles. Un aspecto a observar es el hecho de que entre interfaces puede haber herencia (generalizacin) y no implementacin (realizacin). Esto significa que una interfaz recibe todos aquellos requerimientos de su super-interfaz. Si implementara ser vera obligada a definir los distintos mtodos y dejara de ser una interfaz. Respecto de los intermediarios, cuntos deberan crearse? Uno para cada entidad, o solamente uno para cada entidad concreta, dejando sin intermediario a la entidad Persona. Si se crea un intermediario para cada entidad podremos realizar bsquedas de personas sin importar si son clientes o vendedores, si solamente se crean los intermediarios para las entidades concretas perderemos la posibilidad de realizar la bsqueda comentada, que los mecanismos de persistencia denominan bsqueda polimrfica. Las bsquedas polimrficas son muy interesantes porque demuestran la fuerza que introduce la herencia en la persistencia. Podemos obtener un listado de todas las personas del sistema sin tener que buscar primero clientes y luego vendedores. El desafo que plantean es ver cmo se mapean en los modelos relacionales de las bases de datos.

Mapeo objeto-relacional cuando existe herencia

Todos los mecanismos de persistencia sin excepcin poseen al menos 3 estrategias distintas para realizar los mapeos de los objetos con herencia en las bases de datos relacionales. Es necesario encontrar una forma de llevar a cabo el mapeo necesario para que se permita disfrutar de la herencia entre entidades y la posibilidad de realizar bsquedas polimrficas. No existe un nico planteo til para cada caso, por lo que es necesario que comprenda cada uno de ellos y opte por el mejor en cada jerarqua de herencia. Las 3 estrategias existentes actualmente son: mapeo por jerarqua de herencia, mapeo por clase concreto, mapeo por clase. Los nombres dejan bastante que desear por lo que los veremos en detalle.

Mapeo por jerarqua de herencia

Inicialmente parece ser el ms sencillo de implementar, a continuacin un ejemplo sobre cmo podran guardarse tanto clientes como vendedores: Tabla Personas Nombre Carlos Ernesto Mara Apellido Perez Romero Lopez CUIT 20-25984746-0 4556-8 4003-9 15 20 Legajo Comisin

13

Jos

Castro

30-78987230-6

Queda bien claro en el ejemplo que este mapeo plantea crear una nica tabla para almacenar informacin para todas las entidades existentes en una jerarqua de herencia. Cmo podemos determinar con certeza si Jos Castro es un cliente o un vendedor? Si nos basamos en las columnas en las que tenga y en las que no tenga datos podemos llegar a cometer algn error cuando cambien las reglas del negocio. Adems debemos tener en cuenta que el mecanismo de persistencia no debe conocer ninguna regla del negocio. Existen algunas soluciones variadas, pero la ms utilizada es la de agregar una columna extra en la tabla para indicar el tipo de objeto que representa cada fila: Tabla Personas ID 46463 08941 87423 65423 Nombre Carlos Ernesto Mara Jos Apellido Perez Romero Lopez Castro 30-78987230-6 CUIT 20-25984746-0 4556-8 4003-9 15 20 Legajo Comisin Tipo Cliente Vendedor Vendedor Cliente

En el ejemplo se puede apreciar cmo difieren significativamente las estructuras de las entidades y las de las tablas que dan soporte a la persistencia. Aparece la columna ID debido a la necesidad de poseer una clave primaria que NO debe formar parte de los atributos de las entidades, no debe ser parte de las reglas del negocio, solamente se utiliza (y no es poco) para relacionar los datos en un esquema relacional. Con el planteo realizado, cuntos intermediarios deberan crearse en el framework de persistencia? La respuesta va a ser siempre la misma, 1 por cada entidad, en nuestro caso sern 3, uno para Persona, otro para Cliente y otro para Vendedor. Aunque parezca tentador reunir las 3 capacidades en uno solo fundamentando que se mapean en una misma tabla sera un error importante. Mantener 1 intermediario por entidad nos dar flexibilidad para soportar cualquier cambio futuro, ya sea un cambio en las entidades que implique adaptar al intermediario, o un cambio en la estructura relacional de las tablas que implique adaptar el intermediario. La idea es que el intermediario actue haciendo de Variaciones Protegidas y frene el impacto de las modificaciones, encargndose del mapeo. Las ventajas que plantea esta estrategia son: Gran velocidad al realizar bsquedas polimrficas, ya que no debe realizar JOINs en las consultas Plantea un buen soporte para el uso de relaciones polimrficas entre entidades, por ejemplo: una nueva entidad Y podra relacionarse con Persona, lo que le permitira relacionarse con Cliente Vendedor, en tal caso esta estrategia ofrece buenos tiempos de respuesta Las desventajas que posee esta estrategia son: 14

Normalizacin incorrecta en la tabla, puede crecer desmedidamente y ser poco coherente en relacin a las tablas que posea Necesidad de agregar una columna para discriminar la entidad a mapear Debe permitir que las diversas columnas acepten valores nulos gracias a las diversas entidades que pueden almacenarse

Mapeo por clase concreto

Esta estrategia plantea la solucin de dividir las tablas de acuerdo a las entidades y reflejar en cada una de ellas todos los datos que posean. En ejemplo de acuerdo a las entidades que hemos utilizado en el documento: Tabla Personas Nombre Carlos Ernesto Mara Jos Tabla Clientes Nombre Carlos Jos Tabla Vendedores Nombre Ernesto Mara Apellido Romero Lopez Legajo 4556-8 4003-9 Comisin 15 20 Apellido Perez Castro CUIT 20-25984746-0 30-78987230-6 Apellido Perez Romero Lopez Castro

El ejemplo deja claro que existe una redundancia en los datos que van copindose desde la entidad superior en la jerarqua de herencia y se trasladan a los largo del resto de las entidades. Las tablas Clientes y Vendedores discriminan automticamente el tipo de entidad al que estn haciendo referencia, pero o es el caso de la tabla Personas, que an debe incorporar una columna para discriminar a qu hace referencia en cada fila. Si las entidades Cliente y Vendedor necesitaran ser superclases de otras (es decir, poseer subclases) debern agregar en las tablas correspondientes columnas para discriminar el tipo de Cliente o Vendedor que se est mapeando.

15

No hemos incorporado Ids en el ejemplo, cmo debera realizarse? El ID de unos de los vendedores cmo debe ser en las tablas Personas y Vendedores? Veamos en un ejemplo completo cmo quedaran las tablas definitivamente:

Tabla Personas ID 46463 08941 87423 65423 Tabla Clientes ID 46463 65423 Tabla Vendedores ID 08941 87423 Nombre Ernesto Mara Apellido Romero Lopez Legajo 4556-8 4003-9 Comisin 15 20 Nombre Carlos Jos Apellido Perez Castro CUIT 20-25984746-0 30-78987230-6 Nombre Carlos Ernesto Mara Jos Apellido Perez Romero Lopez Castro Tipo Cliente Vendedor Vendedor Cliente

Se observa como los IDs se van repitiendo desde las superclases hacia las subclases para lograr relacionarlas cuando sea necesario. Las ventajas que ofrece esta estrategia son: No poseer columnas con valores nulos ya que no posee columnas que no reflejen datos propios de la entidad Gran velocidad para realizar bsquedas concretas, no polimrficas. Si se desea buscar a todos los clientes, solamente debe buscar en la tabla Clientes ya que posee todos los datos, incluso los de Persona Ofrece un buen soporte al uso de relaciones polimrficas entre entidades Las desventajas que posee esta estrategia son: No ofrece gran soporte para bsquedas polimrficas ya que debe realizar JOINs para obtener los resultados En el caso de requerir realizar bsquedas polimrficas deben utilizarse operadores especiales o mltiples consultas, por ejemplo: en el caso de querer buscar todas las personas de la aplicacin

16

Genera datos redundantes que pueden ser muy peligrosos para la integridad de la informacin

Mapeo por clase

Esta ltima estrategia parece ser la ms agradable, pero posiblemente no la de mejor performance. Igualmente es necesario analizar cada situacin de herencia y determinar cul de estos mecanismos es el ms correcto, no perder de vista los impactos de acuerdo a las reglas de normalizacin. Esta estrategia plantea la necesidad de crear una tabla por entidad y nicamente almacenar en cada tabla los datos respectivos a la entidad que representa. Veamos en un ejemplo incluyendo el uso del ID y de la columna discriminatoria: Tabla Personas ID 46463 08941 87423 65423 Tabla Clientes ID 46463 65423 Tabla Vendedores ID 08941 87423 Legajo 4556-8 4003-9 Comisin 15 20 CUIT 20-25984746-0 30-78987230-6 Nombre Carlos Ernesto Mara Jos Apellido Perez Romero Lopez Castro Tipo Cliente Vendedor Vendedor Cliente

La tabla Personas no presenta ninguna modificacin, continua con la columna discriminatoria. Las tablas Clientes y Vendedores se han simplificado para contener nicamente los datos nuevos de cada entidad, no aquellos heredados. El ID nuevamente debe repetirse para servir de vinculacin entre distintas filas de diversas tablas y permitir realizar los JOINs necesarios.

17

A simple vista es la estrategia ms sencilla, clara y la que ms refleja la estructura de las entidades pero la peor en trminos de performance, es la que debe realizar la mayor cantidad de trabajo para recuperar cualquier tipo de entidad que se solicite. Las ventajas de esta estrategia son: Respeta las reglas de normalizacin al no duplicar informacin entre diversas tablas No posee columnas con valores nulos ya que se mapean los datos directos de cada entidad Provee un buen soporte para el uso de relaciones polimrficas entre entidades Las desventajas de esta estrategia son: No posee la mejor performance al momento de realizar bsquedas, de cualquier tipo, sean polimrficas o no. Siempre debe realizar JOINs En el caso de requerir realizar bsquedas polimrficas deben utilizarse operadores especiales o mltiples consultas, por ejemplo: en el caso de querer buscar todas las personas de la aplicacin En casos de herencia con muchos niveles puede proveer tiempos de respuesta inaceptables Al igual que con la estrategia anterior, si Cliente o Vendedor fueran a poseer subclases debern incorporar columnas discriminatorias en las tablas correspondientes. Como se ha visto es necesario evaluar cada una de las estrategias y determinar cul ser la mejor para cada caso de herencia. Deben tenerse en cuenta aspectos muy diversos como: performance, normalizacin, redundancia, simplicidad, etc. Como se coment previamente, cada una de las estrategias es independiente de la cantidad de intermediadios que existan. Siempre debe existir 1 intermediario por entidad para poder realizar todos los cambios que se requieran con posterioridad.

Patrones GoF: Fue por los aos 1994, que apareci el libro "Design
Patterns: Elements of Reusable Object Oriented Software" escrito por los ahora famosos Gang of Four (GoF, que en espaol es la pandilla de los cuatro) formada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Ellos recopilaron y documentaron 23 patrones de diseo aplicados usualmente por expertos diseadores de software orientado a objetos. Desde luego que ellos no son los inventores ni los nicos involucrados, pero ese fue luego de la publicacin de ese libro que empez a difundirse con ms fuerza la idea de patrones de diseo. El grupo de GoF clasificaron los patrones en 3 grandes categoras basadas en su PROPSITO: creacionales, estructurales y de comportamiento.

Creacionales: Patrones creacionales tratan con las formas de crear instancias de objetos. El objetivo de estos patrones es de abstraer el proceso de instanciacin y ocultar los detalles de cmo los objetos son creados o inicializados. Estructurales: Los patrones estructurales describen como las clases y objetos pueden ser combinados para formar grandes estructuras y proporcionar nuevas

18

funcionalidades. Estos objetos adicionados pueden ser incluso objetos simples u objetos compuestos. Comportamiento: Los patrones de comportamiento nos ayudan a definir la comunicacin e iteracin entre los objetos de un sistema. El propsito de este patrn es reducir el acoplamiento entre los objetos.

En el segundo nivel, ellos clasificaron los patrones en 2 mbitos: Clases y objetos. Es as que, tenemos 6 tipos de patrones:

Creacionales

Creacional de la Clase Los patrones creacionales de Clases usan la herencia como un mecanismo para lograr la instanciacin de la Clase. Por ejemplo el mtodo Factora. Creacional del objeto Los patrones creacionales de objetos son ms escalables y dinmicos comparados de los patrones creacionales de Clases. Por ejemplo la Factora abstracta y el patrn Singleton.

Estructurales

Estructural de la Clase Los patrones estructurales de Clases usan la herencia para proporcionar interfaces ms tiles combinando la funcionalidad de mltiples Clases. Por ejemplo el patrn Adaptador (Clase). Estructural de Objetos Los patrones estructurales de objetos crean objetos complejos agregando objetos individuales para construir grandes estructuras. La composicin de l patrn estructural del objeto puede ser cambiado en tiempo de ejecucin, el cual nos da flexibilidad adicional sobre los patrones estructurales de Clases. Por ejemplo el Adaptador (Objeto), Fachada, Proxi, Composite.

Comportamiento

Comportamiento de Clase Los patrones de comportamiento de Clases usan la herencia para distribuir el comportamiento entre Clases. Por ejemplo Interpreter.

Comportamiento de Objeto Los patrones de comportamiento de objetos nos permite analizar los patrones de comunicacin entre objetos interconectados, como objetos incluidos en un objeto complejo. Ejemplo Iterator, Observer, Visitor.
(Para leer)

19

Singleton
Limita el nmero de instancias de un objeto a uno. Los clientes que quieran usar dicho objeto compartirn la nica instancia existente. Se admite una nica instancia para todo el sistema, (mantiene un nico estado en toda la secuencia).

Contexto
El sistema solo necesita emplear una nica instancia de una clase. La clase debe ser accesible desde diferentes partes del sistema. Las clases que cumplen estas caractersticas suelen tener alguna de estas funciones: Controlar el acceso a un recurso que por su naturaleza no admite el acceso concurrente (Impresora, socket, fichero). Obtener referencias de clases que actan como servidoras de recursos (pool de conexiones). Ejecutar cdigo carente de estado (si el estado no cambia solo necesitamos una instancia). Mantener un estado que debe ser globalmente nico. Por ejemplo, un sistema de log se ajusta a estas caractersticas porque: Controla el acceso al recipiente de la informacin de log. Toda la informacin de log se enva a travs de un punto nico. Su nico estado es la configuracin, que es global y no suele variar.

Problema La instancia de una clase debe ser nica. Dicha instancia debe ser accesible para todos los clientes. Solucin Se hace privado el nico constructor del Singleton para evitar que el cliente lo instancie. El cliente obtiene la instancia a travs de un mtodo esttico (getInstance()) que devuelve siempre la misma instancia .

20

En el diagrama anterior, getCreationTime() representa el cdigo til del Singleton.

Figura 2. Diagrama de secuencia

(Para leer) Consecuencias Crear subclases de un Singleton es problemtico y poco elegante. No se puede sobrescribir el mtodo getInstance() (Java no permite sobrescribir mtodos estticos). Solo podemos crear subclases si existe un constructor que no sea privado, pero esto permitira crear indefinidas instancias de esta clase. El empleo de singletons complica la compatibilidad hacia atrs de futuras versiones del diseo. El uso de un Singleton incumple el principio de Principio de Sustitucin de Liskov. Este principio establece que un cliente que usa una clase, debera funcionar tambin con subclases suyas. Esto es importante porque si evolucionamos un diseo extendiendo el cdigo existente, garantizamos la compatibilidad hacia atrs de las nuevas versiones. El Singleton lo incumple doblemente porque: El Singleton se disea explcitamente para que no admita la creacin de subclases suyas. El cliente est acoplado con el Singleton a travs del mtodo getInstance() --esto se puede evitar usando inyeccin de dependencias. Si prestamos atencin a la compatibilidad cuando modifiquemos la clase no deberan surgir problemas.

21

Pero suponer que en el futuro prestaremos atencin a todos los detalles de nuestro cdigo es una receta segura para el desastre. El diseo siempre debe ser defensivo, sin suposiciones ..

De lo contrario Samuel L. Jackson nos visitar durante el desayuno y solo podremos decir "NN- nos metimos en esto con la mejor de las intenciones". Los singletons implementados como objetos estticos no estn permitidos por la especificacin J2EE. Cuando existen varios cargadores de clases no podemos garantizar que solo exista una instancia compartida. Vistos los inconvenientes no deberamos abusar de este patrn. Una alternativa es dejar que la aplicacin cliente se ocupe de emplear una instancia nica del objeto. Contenedores como Spring nos pueden ayudar en esta tarea. Hay quien recomienda sustituir el Singleton por un POJO (Plain Java Object = objeto java normalito) y prescindir de este patrn, es un tema controvertido en ciertos foros (ideal para iniciar una flamewar [http://www.google.es/search?q=define %3Aflamewar]). Implementacin La opcin ms simple es hacer que todos los mtodos y variables de la clase sean static. De este modo aunque se instancie, seguir consumiendo los mismos recursos, que es en la prctica lo que perseguimos con el Singleton. En el caso en que no sea conveniente haremos lo siguiente: Evitaremos que el usuario instancie la clase creando un constructor privado. Crearemos una variable esttica privada que almacene la nica instancia de la clase. La instancia se obtendr a travs de un mtodo esttico de la clase. Esta es la implementacin ms corriente:
class Singleton { private static Singleton singleton = new Singleton(); private Singleton() { // inicializacin } public static Singleton getIntance() { return singleton; } // ... cdigo til de la clase ... }

Hasta ahora hemos evitado que el usuario instancie la clase pero no que la clone. Para evitar que la clase sea clonada

22

 Si su superclase implementa Clonable hay que sobrescribir clone() para que lance una CloneNotSupportedException.

Si su superclase no implementa Cloneable basta con hacerla final, lo que

impedir aadir la clonabilidad a una subclase suya. El nuevo cdigo es este:
final class Singleton { // solo necesario cuando la superclase de Singleton implementa clone()protected Object clone() throws CloneNotSupportedException { throw new CloneNotSupportedException("operacin prohibida"); } ... el resto es igual }

Preservar la instancia Tal como est ahora, nos hemos asegurado de que en cualquier momento existe como mucho una instancia de la clase. Pero esto no garantiza que la instancia sea la misma durante toda la vida de la aplicacin. La JVM podra descargarla para ahorrar recursos. La solucin obvia es lanzar un thread con una referencia a la clase y dejarlo en espera. Para ello nos valemos del patrn ObjectPreserver, que es en si mismo un Singleton:
final class ObjectPreserver implements Runnable { // nica instancia de esta clase private static ObjectPreserver lifeline = new ObjectPreserver(); // Referencias a conservar. Sincronizado para ejecutar en entorno multihilo. private static Set preservedSet = Selections.synchronizedSet(new HashSet()); // el cliente no instanciar esta clase private ObjectPreserver() { Thread t = new Thread(this); // cuando la aplicacin termine se recolecta esta clase y sus referencias t.setDaemon(true); t.start(); } // siempre en ejecucin para evitar que las referencias se pierdan public synchronized void run() { try { wait(); } catch (InterruptedException e) { } }

// Guarda una referencia al objeto pasado hasta que sea liberado por public static void save(Object obj) { preservedSet.add(obj); } // Libera la referencia al objeto pasado. public static void remove(Object obj) {

23

preservedSet.remove(obj) } }

24