Foros del Web » Programación para mayores de 30 ;) » Bases de Datos General »

[DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Estas en el tema de [DEBATE]Modelo Entidad-Relacion VS Modelo Relacional en el foro de Bases de Datos General en Foros del Web. Hola Comunidad; Bueno creo que todos los que hemos pasado por Base de Datos hemos visto los Temas del Modelo Entidad-Relacion y el Modelo Relacional. ...
  #1 (permalink)  
Antiguo 18/02/2012, 14:30
 
Fecha de Ingreso: noviembre-2009
Ubicación: Chimbote
Mensajes: 60
Antigüedad: 14 años, 7 meses
Puntos: 5
[DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Hola Comunidad;

Bueno creo que todos los que hemos pasado por Base de Datos hemos visto los Temas del Modelo Entidad-Relacion y el Modelo Relacional.

Como ya se Sabe, el Modelo Entidad-Relacion es Solamente el "Diagrama" con el cual va a quedar tu Base de Datos, Luego de esto se Tendría que pasar al Modelo Relacional, Pero veo aquí que una vez yo me Pregunte, Cuando tu haces un Software, en la Documentación que Diagrama es la que tiene mas relevancia, el Modelo Entidad-Relacion o el Modelo Relación en UML.

Una vez hice una Exposición, en el Cual yo dije que casi el Modelo Entidad-Relacion no se Utiliza en producción porque no tiene un Lenguaje SQL Propio, Siempre en las Aulas del Instituto nos enseña primero el Modelo Entidad-Relacion, Las Formas Normales, Los Tipos de Datos, que Campos no Van, que campos Van, Etc, Pero Siempre Utilizan el Lenguaje SQL del Modelo Relacional, Mas no un Lenguaje Propio del Modelo Entidad-Relacion.

Yo Creo, y es una Opinión Personal, que cuando ya Digamos, sabes las Normas del Modelo Entidad-Relacion, ya te puedes saltar de hacer este Diagrama porque en si, ya sabes de antemano el analisis, Por ejemplo sabes que un Campo Calculable no va, Sabes desde que Entidad vas a hacer una Herencia o una Agregación, Sabes cuales son tus Entidades Fuertes y Débiles (Identificadora y no Identificadora).

Pero me gustaría vuestra Opinión de Todos Ustedes que están mas años en el Desarrollo de Software y Viendo las Bases de Datos, yo a penas tengo unos meses en esto, y estoy leyendo un Libro que es muy Bueno, INTRODUCCIÓN A LOS SISTEMAS DE BASE DE DATOS.
__________________
Para llegar a algo se debe de empezar barriendo o pateando Lata!! XD
  #2 (permalink)  
Antiguo 19/02/2012, 19:49
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 7 meses
Puntos: 2658
Respuesta: [DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Tengo la impresión de que tienes algunas confusiones conceptuales respecto de "Modelo Relacional" y "Modelo Entidad-Relación", y su aplicación tanto en el área de sistemas como del de las Bases de Datos.
Empecemos haciendo algunas aclaraciones:

- Modelo Entidad-Relación no es "solamente el diagrama". El modelo E-R es un modelo teórico y el diagrama es solamente su representación, la cual no tiene directa vinculación con las bases de datos, porque el modelo E-R es en realidad un modo de analizar los sistemas, y no los datos. El objetivo principal es el diseño estructurado de sistemas, del cual el modelo de datos es sólo una parte.

- Modelo Relacional no es el diagrama de tablas. Este ni siquiera se denomina así. Modelo Relacional es el modelo teórico desarrollado por Codd en 1970, sobre el que se basan todos los desarrollos posteriores de las bases de datos relacionales, pero no es aplicable en forma directa, ya que lo que hace es análisis a nivel lógico. En el modelo relacional no se trabaja con datos, sino con relaciones, entidades y conjuntos. Y las operaciones que se realizan se hacen con Algebra Relacional y Cálculo Relacional, ninguno de los cuales es utilizable en forma directa en el mundo de los datos.

- Lo que tu estás llamando "Modelo Entidad Relación", y "sólo diagrama", es la etapa del DER Lógico, donde se analizan las Entidades del sistema y sus relaciones. Pero es un diagrama de tipo teórico que sirve para lograr un acercamiento al modelo de sistema y los flujos de datos que originará, y sobre esa base establecer los requerimientos de datos necesarios. Como etapa previa, no es utilizable en forma directa.

- Lo que estás llamando "Modelo Relacional", es en realidad el DER Físico, o Modelo Físico de datos, que es una transformación del DER Lógico a estructuras de tablas, previo a la normalización. No son excluyentes uno de otro, sino que uno es consecuencia del otro, pero especialmente, el DER Lógico no da solamente origen al Modelo Físico, sino al diseño del software, de los sistemas de comunicación, el diseño de clases y objetos, los mensajes, las dependencias, las librerías y un largo etcétera.

La cosa es que si bien es común suprimir la creación del DERL y directamente crear el DERF, seguir la secuencia natural ayuda a evitar estar bocetando constantemente sobre el DERF, por cuanto muchísimas redundancias, errores de análisis e inconsistencias se hacen manifiestamente visibles cuando trababajas el DERL primero. Una vez que lo tienes bien definido, el resto de los pasos (Clases, DFD, DERF, etc.) se vuelven mucho más simples y sencillos, y sin tantos errores.

Hacer directamente el DERF, y que este resulte optimo y bien desarrollado, requiere de mucha experiencia y sólo he visto que lo hagan bien aquellas personas que han estudiado el tema en la Universidad. No he visto, hasta ahora, ningún autodidacta que lo logre, porque dominarlo requiere el conocimiento y dominio mentalmente del paso previo, el DERL, a niveles que sólo con una guía profesional se logra.
Puede parecerte exagerado, pero el objetivo de la enseñanza de Análisis de Sistemas antes de Bases de Datos tiene su fundamento en que para entrar en BBDD bien parado tienes que haber aprendido a pensar como analista, a razonar como analista, a ver el mundo como analista.
Y no hay manuales que enseñen eso.

Por tanto: DERL y DERF (según se entiende lo que dices), son necesarios ambos, interdependientes y sólo puedes suprimir uno de ellos (cuando no es por fiaca), con experiencia y estudio.

Ahora bien, yo he visto modelos de datos de bases empresariales que han ido siendo modificadas por sucesivas adaptaciones a un entorno cambiante. Esto ha hecho que la distancia entre el modelo físico implementado y el modelo físico originalmente diseñado se haya transformado en un abismo insalvable. Asimismo, el modelo lógico ha ido sufriendo otro enorme conjunto de cambios al punto de no guardar relaciones con su diseño original.
El resultado es que existe cierta dificultad para la software factory (SF) para lograr implemtnar los cambios futuros, porque el análisis de impacto se vuelve extremadamente dificultoso ya que no existe una documentación del modelo lógico que permita hacer un seguimiento simple del impacto que un cambio , por menor que sea, tiene en el sistema.
Esta es probablemente la razón por la cual es siempre una muy buena idea no saltarse las etapas: Cualquier modificación ulterior debe tener suficiente documentación sobre el modelo del sistema hasta un nivel de desagregación muy básica, tal que permita conocer las consecuencias de un cambio, antes de que el mismo entre en producción.

Como experiencia de terceros, he visto suceder que un error de implementación por documentación deficiente de las relaciones entre entidades, se hayan perdido los datos contables de cinco años de 12.000 afiliados a un sistema de medicina prepaga (seguro médico). REcuperar parcialmente los datos desde los backups (Ley de Murphy: Los backups nunca están suficientemente actualizados) resultó una tortura, y requirió de reinstalar los sistemas anteriores, antes de comenzar a hacer nueva reingeniería para ver dónde se había metido la pata.

Por supuesto que no se trata de situaciones diarias, pero resolver los problemas de diseño en la mente, no es suficiente para crear un sistema seguro, y menos para que los siguientes responsables (cuando el diseñador ya no está en la empresa), puedan trabajar sin sobresaltos.

En definitiva: Saltarse etapas, ir directamente a las implementaciones y resolver en la mente los problemas de normalización y consistencia, es algo que sólo debería existir para los trabajos hogareños, o para los hobbies. Los profesionales en el ramo tenemos cierta responsabilidad de hacer las cosas bien, no solo para nosotros y nuestro respeto a la profesión, también como consideración a los analistas que nos suplan cuando nos hayamos ido a trabajar a otra empresa.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)

Última edición por gnzsoloyo; 19/02/2012 a las 21:05
  #3 (permalink)  
Antiguo 21/02/2012, 14:23
 
Fecha de Ingreso: febrero-2011
Mensajes: 55
Antigüedad: 13 años, 5 meses
Puntos: 3
Respuesta: [DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Cita:
En definitiva: Saltarse etapas, ir directamente a las implementaciones y resolver en la mente los problemas de normalización y consistencia, es algo que sólo debería existir para los trabajos hogareños, o para los hobbies. Los profesionales en el ramo tenemos cierta responsabilidad de hacer las cosas bien, no solo para nosotros y nuestro respeto a la profesión, también como consideración a los analistas que nos suplan cuando nos hayamos ido a trabajar a otra empresa.
Así mismo, en los proyectos de software empresariales se usa la ingeniería del software, la cual se deben tener en cuenta muchos factores, como los requerimientos del sistema, de los usuarios, hay modelos para escoger, ya sea escalar, espiral, etc, y de ahí puede ser incremental o evolutivo, además de eso, tener en cuenta el SRS, los casos de uso, el modelo de proceso de negocio, etc, y dentro de todo esto, se encuentra el D.E.R
  #4 (permalink)  
Antiguo 21/02/2012, 18:31
Avatar de jhsilva  
Fecha de Ingreso: mayo-2009
Mensajes: 85
Antigüedad: 15 años, 1 mes
Puntos: 5
Respuesta: [DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Cita:
Iniciado por GuzmanDiaz18 Ver Mensaje
Hola Comunidad;

Bueno creo que todos los que hemos pasado por Base de Datos hemos visto los Temas del Modelo Entidad-Relacion y el Modelo Relacional.

Como ya se Sabe, el Modelo Entidad-Relacion es Solamente el "Diagrama" con el cual va a quedar tu Base de Datos, Luego de esto se Tendría que pasar al Modelo Relacional, Pero veo aquí que una vez yo me Pregunte, Cuando tu haces un Software, en la Documentación que Diagrama es la que tiene mas relevancia, el Modelo Entidad-Relacion o el Modelo Relación en UML.

Una vez hice una Exposición, en el Cual yo dije que casi el Modelo Entidad-Relacion no se Utiliza en producción porque no tiene un Lenguaje SQL Propio, Siempre en las Aulas del Instituto nos enseña primero el Modelo Entidad-Relacion, Las Formas Normales, Los Tipos de Datos, que Campos no Van, que campos Van, Etc, Pero Siempre Utilizan el Lenguaje SQL del Modelo Relacional, Mas no un Lenguaje Propio del Modelo Entidad-Relacion.

Yo Creo, y es una Opinión Personal, que cuando ya Digamos, sabes las Normas del Modelo Entidad-Relacion, ya te puedes saltar de hacer este Diagrama porque en si, ya sabes de antemano el analisis, Por ejemplo sabes que un Campo Calculable no va, Sabes desde que Entidad vas a hacer una Herencia o una Agregación, Sabes cuales son tus Entidades Fuertes y Débiles (Identificadora y no Identificadora).

Pero me gustaría vuestra Opinión de Todos Ustedes que están mas años en el Desarrollo de Software y Viendo las Bases de Datos, yo a penas tengo unos meses en esto, y estoy leyendo un Libro que es muy Bueno, INTRODUCCIÓN A LOS SISTEMAS DE BASE DE DATOS.
Creo que todo depende del contexto y la expertiz. Si estás desarrollando un proyecto de no gran magnitud y deseas omitir el modelo entidad relación porque sabes en que se convertirá y decides altiro implementar el modelo relacional bien . En contraste en ambiente de software industrial donde debes analizar quirurjicamente todo y además con un proceso bien estilo RUP es bueno realizar ambos modelos.

No le pidas a un agilista que te cree el modelo entidad-relación y luego el modelo relacional....

En conclusión el desarrollador o Ingeniero debe decidir de acuerdo al contexto en el que se desenvuelve el proyecto.

Etiquetas: entidad-relacion, modelo, relacional, sql, campos
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 15:51.