Generar Modelo E-R a partir de BBDD

02/07/2007 - 11:39 por Jesus Suarez | Informe spam
Hola a todos,

existe algun programa, que me permita pasandole la BBDD, obtener el diagrama
modelo ER de dicha base de datos.

Gracias

Preguntas similare

Leer las respuestas

#6 Gustavo Larriera (MVP)
02/07/2007 - 19:26 | Informe spam
Hola Alfredo, creo que tienes alguna confusión de conceptos teóricos. Si me
permites, quisiera explicarlos:

El modelo E-R es un modelo para diseño conceptual y no para el nivel lógico
(mucho menos para el físico). A nivel de modelo conceptual se puede diseñar
una entidad Persona y por herencia puedo modelar Cliente y Empleado, a partir
de Persona. Eso es lo que normalmente hacemos en un diagrama E-R. Es un
modelo semiformal en la mayoria de los casos.

De ese modelo conceptual pasamos al modelo lógico, que normalmente es un
conjunto de relaciones y operaciones de consulta a realizar sobre el modelo.
Este modelo es formal, normalmente usamos el modelo relacional normalizado.

Finalmente implementamos el modelo físico: tablas, indices, claves primareas
y foraneas, etc.

Por los detalles de todo esto, puedes leer cualquier texto recomendado de
teoria de diseño de bases de datos. Autores clásicos: C.J. Date, J. Ullman,
Elmasri, Navathe, J. Paredaens.

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.Larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Alfredo Novoa" wrote:


Hola Gustavo,

On Mon, 2 Jul 2007 08:46:14 -0700, Gustavo Larriera (MVP)
wrote:

>Los diagramas de SQL Server son solamente una representación del nivel físico
>de la stablas y sus dependencias basadas en foreign keys.

Son una representación de algunos aspectos del nivel lógico.

>Pero eso no se acerca a un diagrama ER, que es una representación del nivel
>conceptual,

El nivel conceptual es un nivel informal, el nivel lógico es preciso.

> donde incluso aparecen construcciones como herencia (que
>obviamente no existen en el nivel físico).

Esto no tiene sentido. Por supuesto que la herencia se puede definir
en el nivel lógico e implementar en el nivel físico.

>Para lo que quiere hacer el amigo, Visio y Erwin pueden ayudarle bastante
>bien.

Y los diagramas de SQL Server también.


Saludos

Respuesta Responder a este mensaje
#7 Alfredo Novoa
03/07/2007 - 08:02 | Informe spam
Hola Gustavo,

On Mon, 2 Jul 2007 10:26:04 -0700, Gustavo Larriera (MVP)
wrote:

Hola Alfredo, creo que tienes alguna confusión de conceptos teóricos. Si me
permites, quisiera explicarlos:



Veamos quien está confundido :-)

El modelo E-R es un modelo para diseño conceptual y no para el nivel lógico



El modelo E-R son unas convenciones para dibujar diagramas. Puedes
aplicarlas tando al diseño conceptual como al diseño lógico.

Los diagramas de SQL Server se derivan del diseño lógico y son tan
diagramas E-R como cualquiera otros.

(mucho menos para el físico).

A nivel de modelo conceptual se puede diseñar
una entidad Persona y por herencia puedo modelar Cliente y Empleado, a partir
de Persona.



Estás hablando de una extensión (bastante grotesca por cierto) de los
diagramas E-R. No de los diagramas E-R originales.

Eso es lo que normalmente hacemos en un diagrama E-R.



Lo harás tu normalmente, pero hay mucha gente que no usa esas
extensiones.

De todas formas los modelos E-R son muy limitados y solo pueden
representar algunos aspectos de un diseño de base de datos. Los
modelos conceptuales suelen incluir explicaciones escritas en lenguaje
natural para expresar lo que los diagramas no pueden expresar.

Por otra parte los diseños lógicos se pueden complementar con
diagramas E-R, que aunque no aportan ninguna información adicional
pueden ayudar a comprender el diseño más fácilmente. Aquí entrarían
los diagramas de SQL Server.

De ese modelo conceptual pasamos al modelo lógico, que normalmente es un
conjunto de relaciones y operaciones de consulta a realizar sobre el modelo.



Las operaciones de consulta no son parte de un diseño lógico. Quizás
te refieres a las vistas que si son parte del diseño lógico, igual que
las demás tablas.

Este modelo es formal, normalmente usamos el modelo relacional normalizado.



Solo hay un modelo relacional: el Modelo Relacional.

Para el diseño lógico normalmente usamos SQL. Aunque SQL no separa
bien el nivel lógico del nivel físico. Por ejemplo para crear una
clave única (concepto lógico) necesitamos crear un índice (artefacto
físico).

Finalmente implementamos el modelo físico: tablas, indices, claves primareas
y foraneas, etc.



Craso error. Los índices son parte del modelo físico, pero las tablas
son el equivalente SQL de las relaciones, y por lo tanto son
"artefactos" del nivel lógico. Las claves primarias y exteriores son
casos particulares de restricciones de integridad, y por lo tanto
también pertenecen al nivel lógico.

Al modelo físico pertenecen las estructuras de datos que utiliza
internamente el SGBD como: árboles B, índices bitmap, páginas, etc.

El nivel físico debe de permanecer oculto a los usuarios del SGBD.

Por los detalles de todo esto, puedes leer cualquier texto recomendado de
teoria de diseño de bases de datos. Autores clásicos: C.J. Date, J. Ullman,
Elmasri, Navathe, J. Paredaens.



El de Paredaens no lo conozco. Los demás los he leido, y también otros
como el de Korth y Silberschatz. El de Elmasri y Navathe tiene
bastantes errores.

La confusión entre los niveles lógico y físico es muy habitual incluso
en los libros. Por ejemplo el de Candace, Fleming y von Halle llama
nivel físico al nivel lógico todo el rato.

La confusión es causada en gran parte por que la mayoría de los SGBD
SQL crean automáticamente un diseño físico directamente derivado del
diseño lógico, con muy pocas opciones para modificarlo. Por cada tabla
base lógica se crea una tabla física automáticamente.

Por lo tanto en muchas ocasiones la única forma de modificar el diseño
físico es modificar el diseño lógico :-(

Por suerte hay algunos mecanismos que permiten aliviar un poco el
problema como las "vistas materializadas", el mecanismo de seguridad,
los "triggers", etc.

El libro que mejor trata estos temas es el de Date, creo que deberías
de pegarle un repaso.


Saludos
Alfredo
Respuesta Responder a este mensaje
#8 Gustavo Larriera (MVP)
03/07/2007 - 18:16 | Informe spam
Hola Alfredo,

sigo pensando que hay muchos conceptos confusos en lo que dices.

De todas formas no quiero que aburramos a los demas colegas del foro. Si
quieres, podemos seguir esta interesante discusion por mail privado. Mi
correo es gux arroba mvps punto com.

Muchos saludos,
~gux

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.Larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Respuesta Responder a este mensaje
#9 Víctor Rafael Bocanegra Arias
03/07/2007 - 23:41 | Informe spam
Al menos a mi no me aburren y si me interesan los conceptos. Gustavo no nos
prives de APRENDER!!!!!!

Salu2

Victor


"Gustavo Larriera (MVP)" escribió en el mensaje
news:
Hola Alfredo,

sigo pensando que hay muchos conceptos confusos en lo que dices.

De todas formas no quiero que aburramos a los demas colegas del foro. Si
quieres, podemos seguir esta interesante discusion por mail privado. Mi
correo es gux arroba mvps punto com.

Muchos saludos,
~gux

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.Larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Respuesta Responder a este mensaje
#10 Alfredo Novoa
04/07/2007 - 01:09 | Informe spam
On Tue, 3 Jul 2007 16:41:45 -0500, "Víctor Rafael Bocanegra Arias"
wrote:

Al menos a mi no me aburren y si me interesan los conceptos. Gustavo no nos
prives de APRENDER!!!!!!



Eso, eso, que diga lo que cree que está mal :-)


Saludos
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida