El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser implementadas directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es el método más usado para el almacenamiento de datos. Es en el modelado de este área donde UML se queda corto. El diagrama de clase de UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER diagram) se recomienda como extensión a UML.
El Diagrama de Clase se puede usar para modelar el estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el método de implementación escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama de relación de entidad (ER diagram).
Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo el modelo relacional encaja; y qué atributos son claves primarias, claves secundarias, y claves externas basadas en relaciones con otras entidades. La idea es constriur un modelo lógico que sea conforme a las reglas de normalización de datos.
Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico puede ser denormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso a los datos. Las relaciones super-sub entre entidades se resuelven por las estructuras de tablas actuales. Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físco representa uno de los RDBMS que son nuestro objetivo.
No hay comentarios:
Publicar un comentario