28 de Octubre, 2004

Diseño visual de bases de datos

Cualquier aplicación que desarrollemos, con toda seguridad, necesitará estructuras de datos, y muy probablemente sea buena idea emplear un motor de bases de datos para almacenar la información.

La forma de manejar dicha información es vital para el funcionamiento del programa, y si el diseño de la base de datos es malo o erróneo, tendremos gran cantidad de problemas, pudiendo llegar a ser necesario tirarlo todo a la basura y empezar de nuevo.

Tampoco digo nada del otro mundo, es cierto. Pero como en todo la experiencia es un grado. También a la hora de diseñar las bases de datos.

Muchas veces la estructura de la base de datos se limita a dos o tres tablas relacionadas o no entre sí, y hasta ese punto mi experiencia llega ;). Pero cuando la cosa se hace más grande, necesito seguir un patrón de diseño para no fastidiarla.

Normalmente dibujaba un esquema a mano (Entidad Relación) y lo repasaba hasta estar seguro que de que se ajustaba al 100% a los requerimientos del programa. Pero es cansado y muchas veces da pereza ponerse.

Así que me he puesto a buscar herramientas de modelado para bases de datos.

Después de buscar un rato me he dado cuenta que tengo prejuicios :D. Mejor me explico.

En la universidad me enseñaron a modelar aplicaciones orientadas a objetos empleando la metodología de Booch, que ahora ha sido asimilado por el nuevo estándar de moda: UML.

He intentado aprender UML un par de veces, pero tiene cosas que desde el punto de vista de un tío con experiencia en Booch... no entran ni a tiros :P.

Resulta que la gente no es tonta, y más de uno ha visto la similitud entre las relaciones que permite establecer UML entre clases con las que se dan en una base de datos relacional.

¿Es posible entonces que siguiendo unas pequeñas reglas podamos obtener código SQL a partir de un diseño UML? La respuesta es: sí.

Voy a poner un ejemplo muy sencillo para ilustrar como funciona el invento. En este caso utilizo el fantástico (y a veces empalagoso de utilizar) DIA, que soporta UML sobradamente para nuestros intereses, y DIA2Code, que permite convertir diagramas de DIA a código en gran cantidad de lenguajes (incluyendo SQL).

Tampoco quiero convertir este artículo en un tutorial de DIA, pero sí voy a explicar algunos pasos sencillos.

Para generar código SQL solo vamos a crear clases y a emplear asociaciones de clases; en rojo y en verde respectivamente en la siguiente imagen:

Herramientas
Herramientas a usar

Cuando creamos una clase pasamos a editar sus propiedades (doble click sobre la clase creada). Estas son:

  • Nombre de la clase: ej. tblFactura.
  • Atributos: ej. id int primary key.

El nombre de la clase indica como se llamará la tabla. Los atributos constan de:

  • Nombre: nombre de la columna, ej. iva.
  • Tipo: tipo de la columna, ej. float.
  • Valor: valor por defecto (opcional), ej. default '16' o not null.
  • Visibilidad: para la claves primarias pondremos protegido y activaremos vista de clase, para el resto nada. Esto es redundante porque ya habremos indicado con primary key en el Tipo que es la clave primaria. Lo hacemos por dos cosas: porque así gráficamente la clave se ve diferenciada y porque otros conversores de UML a SQL sí lo tienen en cuenta (lo explico más adelante).

Introducimos todas la columnas y ya tenemos la tabla lista.

Cuando empleamos la asociación debemos indicar para cada extremo (lados A y B, otra vez doble click):

  • Papel: la columna que hace la referencia.
  • Multiplicidad: la cardinalidad (1, 0..1, n, 1..n, etc).

Con esto ya podríamos obtener un diagrama como el siguiente:

Diagrama de ejemplo
Un diagrama de ejemplo

Es muy sencillo e ilustra lo que podría ser una base de datos muy rudimentaria para almacenar facturas.

Ahora solo falta generar el código SQL, suponiendo prueba.dia para el diagrama:

$ dia2code -t sql prueba.dia

Con lo que obtenemos el siguiente DEFINITION.SQL:

CREATE TABLE tblFactura(
-- Attributes --
numero varchar(64),
fecha datetime,
dniNifCli varchar(13),
nombreCli varchar(255),
direccionCli varchar(255),
iva float,
id int primary key);

CREATE TABLE tblLineaFactura(
-- Attributes --
idFactura int,
concepto varchar(255),
importe float,
id int primary key);

Como vemos dia2code no transcribe la integridad referencial de las tablas. Ese primary key lo hemos introducido nosotros a mano al indicar el tipo (en tblFactura sería int primary key). Hay otros traductores que sí tienen en cuenta, no solo las claves primarias sino también las ajenas, que indicamos en las asociaciones UML, como dia2sql-stl (creo, no lo he podido probar - ahora explico porqué no tiene importancia :P).

La verdad es que estoy algo desconcertado porque dia2code sí parece comprobar que las asociaciones sean correctas (muestra advertencias en determinados casos), pero luego no usa esa información para nada (aparentemente).

En realidad tiene poca importancia. En el diseño nos ayuda a ver que todo está correctamente gracias a que indicamos las relaciones, y al generar código empleamos el hack descrito para la clave primaria y pasamos de la integridad referencial. Al menos yo puedo hacerlo porque uso MySQL en una versión que, aunque estuvieran disponibles, no podría usar esas claves ajenas. Por lo tanto para mi es más que suficiente con el uso descrito.

Si alguien necesita la integridad referencial, pues que pruebe otro traductor, que hay varios disponibles con diferentes niveles de usabilidad y madurez, y que informe de sus resultados :D.

Anotación por Juan J. Martínez.

Hay 1 comentario

Gravatar

Muy interesante me ha parecido el texto, sobre las "claves foráneas" comentarte que por experiencia tan solo conozco un cliente que las pidiera... digamos que es forzar un poco el motor de la base de datos que uses u que si además tienes código por debajo de mantenimiento de las tablas, estás introduciendo validaciones dos veces: una por código y otra por el sistema de base de datos. Además está el coste en espacio de estas claves (no dejan de ser ficheros indexados).

Bajo Oracle conocía la herramienta Designer (bajo WIN), y en DB2 hay una par4ecida pero no recuerdo el nombre.

Ya te digo, que me ha parecido muy interesante

por micmic, en 2004-10-29 18:21:02

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.