Herramientas de diseo de Modelos Entidad-Relacin Open Source

Publicado por rfpp en octubre 17, 2008

Llevo tiempo buscando por Internet una solucio n Open Source para el disen o y
modelado de diagramas E-R que adema s permita exportar el M.E-R a scripts de
creacio n de tablas para diferentes SGBD, pero principalmente PostgreSQL.
Empece mi bu squeda en la web oficial de PostgreSQL, y all encontre unas cuantas
noticias de versiones recientes de aplicaciones para hacer disen os con soporte para
PostgreSQL (entre otros), pero se trataba de aplicaciones propietarias con
versiones de prueba. As que me di un paseo por sourceforge y freshmeat, y all
encontre una serie de aplicaciones Open Source, pero la verdad, dejaban un poco
que desear.
Finalmente encontre DB Designer Fork, que como su propio nombre implica, se
trata de un fork de DB Designer. DB Designer esta pensado principalmente para
trabajar con MySQL. Si es el caso, y lo que queremos es trabajar con MySQL
entonces la solucio n que buscamos es
Db Designer Fork tiene todo lo necesario para no echar en falta estas aplicaciones
comerciales de uso profesional, el problema, es que tengo que matizar que esta
herramienta esta bastante bien si lo que pretendes es hacer disen os de bases de
datos no muy grandes, como podra serlo una biblioteca, la gestio n de un
videoclub, etc.

Existen gran cantidad de aplicaciones para el modelado, desde diagramas en UML a

incluso aplicaciones que te sacan el disen o haciendo ingeniera inversa a tu base de
datos. Dependiendo si nos queremos gastar la pasta o no podremos escoger entre
una gran variedad de aplicaciones. A continuacio n dejare un listado de las opciones
Open Source ma s viables:

DB Designer Link
Fork
MySQL Link
Workbench
DDT (Database Link
Design Tool)
Open System Link
Architect
PG Designer Link
Power*Architect Link
Data modeling
tool

[ CITATION wor08 \l 22538 ]

DISEO CONCEPTUAL DE BASE DE DATOS
[ CITATION Dat01 \l 10250 ] El proceso de disen ar una base de datos se divide en varios
subprocesos que comienzan una vez concluida la fase de recopilar y analizar los
requerimientos de la base de datos. Estos consisten en desarrollar los disen os
conceptual, lo gico y fsico de la base de datos, y cada uno se realiza usando te cnicas
y me todos especficos.
Etapa

del diseo conceptual: en esta etapa se obtiene una estructura de la informacio n

del entorno o el sistema donde se implantara la base de datos, independientemente
de cualquier consideracio n fsica. A este se le denomina esquema conceptual y
tiene como objetivo lograr la comprensio n de la estructura, sema ntica, relaciones y
restricciones de la base de datos, realizar una descripcio n estable del contenido de
la base de datos, lograr la comunicacio n entre usuarios, analistas y disen adores,
para dar paso al disen o lo gico de la base de datos. Se construye utilizando la
informacio n que se encuentra en la especificacio n de los requisitos de usuarios.

ELEMENTOS EN UN MODELO DE DATOS CONCEPTUAL

Conjuntos:
Los elementos de intere s aparecen agrupados o clasificados en conjuntos de
acuerdo a sus caractersticas
Relaciones entre Conjuntos:
Conjuntos de parejas, ternas, cuaternas, etc. de elementos de los conjuntos
anteriores
Restricciones de Integridad:
Condiciones que indican cuando un elemento o una pareja puede o no puede
pertenecer a un conjunto o relacio n.

PRINCIPIOS DE LOS ESQUEMAS CONCEPTUALES

Principio del 100%:
El esquema conceptual asociado a un problema debe representar todos sus
aspectos
Principio de Conceptualizacin:
El esquema conceptual no debe incluir ningu n elemento asociado a la
implementacio n del esquema, as como ningu n elemento orientado a la
performance de la futura BD.

Ejemplo:

De cada AMIGO sabemos el nombre y su tele fono.

De cada BAR sabemos el nombre y la direccio n.
Algunos ejemplos de modelos conceptuales son:
Modelo RM/T
Modelo E/R(1976)
Modelos sema ntico
EL MODELO ER:[ CITATION Bat92 \l 10250 ]
El disen o conceptual de una base de datos mediante el modelo ER. Lo que
explicaremos es aplicable al disen o de cualquier tipo de bases de datos relacional,
jera rquica, etc., porque en la etapa del disen o conceptual todava no se tiene en
cuenta la tecnologa concreta que se utilizara para implementar la base de datos.
El modelo ER es uno de los enfoques de modelizacio n de datos que ma s se utiliza
actualmente por su simplicidad y legibilidad. Su legibilidad se ve favorecida porque
proporciona una notacio n diagrama tica muy comprensiva. Es una herramienta u til
tanto para ayudar al disen ador a reflejar en un modelo conceptual los requisitos
del mundo real de intere s como para comunicarse con el usuario final sobre el
modelo conceptual obtenido y, de este modo, poder verificar si satisface sus
requisitos.
Cuando se quiere utilizar el modelo ER para comunicarse con el usuario, es
recomendable emplear una variante del modelo que incluya so lo sus elementos
ma s simples entidades, atributos e interrelaciones y, tal vez, algunas
construcciones adicionales, como por ejemplo entidades de biles y dependencias de
existencia. E stos eran los elementos incluidos en el modelo original propuesto por
Chen. En cambio, para llevar a cabo la tarea de modelizar propiamente dicha, suele
ser u til usar un modelo ER ma s completo que incluya construcciones ma s
avanzadas que extienden el modelo original.
Te cnica de ana lisis basada en la identificacio n de las entidades y de las relaciones
que se dan entre ellas en la parte de realidad que pretendemos modelar.
Existen notaciones alternativas para la representacio n gra fica del disen o
conseguido mediante la te cnica de ana lisis que propone el modelo E/R:
Diagramas E/R
Diagramas UML (Lenguaje Unificado de Modelado)
Diagramas CASE*Methodo
Diagramas ORM (Object-Role Modeling)
Diagramas IDEF1X
Elementos del modelo E/R
Entidades (conceptos de inters):
Se trata de cualquier objeto u elemento (real o abstracto) acerca del cual se pueda
almacenar informacio n en la base de datos, es decir, un objeto del mundo real que
podemos distinguir del resto de objetos y del que nos interesan algunas
propiedades.
Algunos ejemplos de entidad son un empleado, un producto o un despacho.
Tambie n son entidades otros elementos del mundo real de intere s, menos tangible
pero igualmente diferenciable del resto de objetos; por ejemplo, una asignatura
impartida en una universidad, un pre stamo bancario, un pedido de un cliente, etc.
Una entidad no es un propiedad concreta sino un objeto que puede poseer
mu ltiples propiedades (atributos).
Al grupo de entidades con cualidades similares acerca de los cuales se almacena
informacio n se le denomina tipo (o, simplemente, conjunto de entidades).

Relaciones (conexiones o asociaciones):[CITATION Vil05 \l 10250 ]

Representan asociaciones entre entidades. Es el elemento del modelo que permite
relacionar en s los datos del modelo.
Las relaciones se representan gra ficamente mediante rombos y su nombre aparece
en el interior.
La cardinalidad con la que una entidad participa en una relacio n especifica el
nu mero mnimo y el nu mero ma ximo de correspondencias en las que puede tomar
parte cada ocurrencia de dicha entidad.

Caractersticas de las relaciones

Grado: Nu mero de tipos de entidades que participan en la conexio n.
Cardinalidad
Indica el nu mero de relaciones en las que una entidad puede aparecer. Se anota en
te rminos de:
Cardinalidad mnima. Indica el nu mero mnimo de asociaciones en las que
aparecera cada ejemplar de la entidad (el valor que se anota es de cero o
uno)
Cardinalidad ma xima. Indica el nu mero ma ximo de relaciones en las que
puede aparecer cada ejemplar de la entidad (puede ser uno o muchos)
En los esquemas entidad / relacio n la cardinalidad se puede indicar de muchas
formas.
Actualmente una de las ma s populares es esta:

o Cardinalidad mxima de una relacin:

Relacio n uno a uno

Relacio n muchos a uno

Relacio n muchos a muchos

 o
Cardinalidad mnima de una relacin
La notacio n UML permite especificar la cardinalidad mnima de una relacio n
(p.ej. su obligatoriedad)

Atributos:
Describen propiedades de las entidades y las relaciones. En este modelo se
representan con un crculo, dentro del cual se coloca el nombre del atributo.
La cardinalidad de un atributo indica el nu mero mnimo y el nu mero ma ximo de
valores que puede tomar para cada ocurrencia de la entidad o relacio n a la que
pertenece. El valor por omisio n es (1,1).

Tipos de atributos
Atributos compuestos vs. Atributos simples (ato micos)
Los atributos compuestos se pueden dividir en componentes ma s pequen os con
significado propio
p.ej. direccio n = calle + municipio + CP + provincia
Atributos monovaluados vs. Atributos multivaluados
Un atributo monovaluado tiene un u nico valor para una entidad particular.
Atributos almacenados vs. Atributos derivados
p.ej. la edad de una persona [atributo derivado] se puede calcular (derivar) de su
fecha de nacimiento [atributo almacenado], que es lo que almacenaremos en la
base de datos.

METODOLOGA DE DISEO CONCEPTUAL

Para cada a rea funcional de la empresa se construye un esquema conceptual local
siguiendo estos pasos:
1. Identificar las entidades.
2. Identificar las relaciones.
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquas de generalizacio n (si las hay).
7. Dibujar el diagrama entidad relacio n.
8. Revisar el esquema conceptual local con el usuario.
Diagrama entidad/relacin (notacin UML)

Bibliografa
Batini, C., Ceri, S., & Navathe, S. B. (1992). Conceptual Database Design: An Entity-
Relationship Approach. Adisson Wesley: Reading, Massachusetts.
Date, C. J. (2001). "introduccin a los sistemas de bases de datos". Prentice Hall: 7
edicion.
korth, sudarshan (2002). Fundamentos de bases de datos, Cuarta edicion.