[DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

Publicado en 'Programación' por celsoxvi, 18 Feb 2012.





  1. celsoxvi

    celsoxvi Miembro de bronce

    Registro:
    1 Mar 2009
    Mensajes:
    1,196
    Likes:
    72




    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.
     


  2. San Diablo

    San Diablo Miembro de bronce

    Registro:
    1 Feb 2008
    Mensajes:
    1,066
    Likes:
    364
    En realidad al ser un lenguje de modelamiento todos los pasos son importantes pues es un leguaje estandarizado (qué se supone es el fuerte de este metodo), aunque el 100% de los estudiantes nos preguntemos una y mil veces para qué seguir haciendo pasos 99% similares en muchos puntos a lo largo del proyecto.

    Analogamente dentro de la seccion de Base de Datos hay pasos que tal como el Modelo del Negocio, Análisis, Requerimientos, etc. son casi iguales salvo por uno que otro detalle (diagramas de objetos, clases, análisis de clases, etc).

    Con respecto al tipo de enseñanza, tienes mucha razon! es relativa segun la universidad/instituto y ni hablar que varía entre los docentes de un mismo centro. Si hasta en los libros las metodologías tienen diferentes pasos cuando se habla de lo mismo.

    Yo mis trabajos de la u, siempre los basé en el libro Analisis y Diseño de Sistemas de los brothers Kendall, sé que no estan todos los puntos de base de datos e implementacion, pero al menos da pautas generales entendibles. Aunque no falta algun profe desubicado que quiere que todo lo hagamos a "su modo".
     
  3. Gasa

    Gasa Suspendido

    Registro:
    26 Jun 2010
    Mensajes:
    339
    Likes:
    90
    man investiga mas metodologia para k tengas un criterio mas amplio de estos puntos no solo lo k es E-R existen diversas metodologias actualez k son mejor aplicadas en produccion y no es cuestiones teoricas
     
    A celsoxvi le gustó este mensaje.
  4. arevilla

    arevilla Suspendido

    Registro:
    1 Oct 2010
    Mensajes:
    273
    Likes:
    41
    Un toque enredado tu post, el modelo entidad-relación no es un diagrama sino la representación de los datos atraves de diagramas (uno o muchos) y aunque normalmente usado para describir la estructura de una base de datos relacionales su uso no está limitado solo a ello. SQL se diseño para mantener bases de datos en sistemas manejadores (de bases de datos), que es otra cosa. UML es un lenguaje de notación gráfica que (asi como otros) permite diagramar un modelo entidad-relación. Si vas a usar UML para generar tu modelo ER entonces lo lógico es que lo uses también para documentarlo.
     
    Última edición: 2 Mar 2012
    A celsoxvi le gustó este mensaje.
  5. celsoxvi

    celsoxvi Miembro de bronce

    Registro:
    1 Mar 2009
    Mensajes:
    1,196
    Likes:
    72
    Claro, Pero lo de SQL esta mas esta Orientada a la Base de Datos Relaciones y como tu dices Nacen para hacer un Sistema de Gestión de Base de Datos, Así como el PL/SQL de Oracle y MySQL. Es por ello que existen muchos debate, Si se Debe de Omitir el Modelo Entidad-Relacion (Conceptual) como primer Paso Siempre y cuando ya se sabe que datos van a ir en tu Modelo Relacional (Lógico).

    Mira y que cuento he una Opinión, Siempre cuando hacemos los Diagramas Entidad-Relacion Conceptualisamos todo los que nos Rodea, Osea Abstraemos, Ahora cuando nos Vamos a un Diseñador ya sea el de SQL, el de MySQL Workbench, Entre otros. Cuando comenzamos a Diseñar nuestro Modelo Relacional, vemos en el Diseñador que se crean las Tablas todo, pero ahí nace la Duda de algunos que recién empiezan, Pues ven que el Modelo Relacional del Diseño es el Modelo Entidad-Relacion del Modelo Conceptual, y no es así, ya que el Modelo Relacional es solamente SQL con el Álgebra Relacional.

    Lo de UML claro lo tengo Claro que si Usas UML en tu Diseño, Debes de Usar en tu Documentación, Pero en Cuanto al Modelo Entidad-Relacion osea al Conceptual, que no es UML; también se Pondría como un Anexo a la Documentación para el Programador, o este ya no seria necesario. ¿Que Opinión das?
     
  6. Gasa

    Gasa Suspendido

    Registro:
    26 Jun 2010
    Mensajes:
    339
    Likes:
    90
    Man dale una leida a la metodologia XP para k tengas otra optica de este enredo
     
  7. Drknow

    Drknow Miembro maestro

    Registro:
    21 Abr 2011
    Mensajes:
    332
    Likes:
    42
    Aprende todo lo que puedas... en la vida facil vas a unirte a proyectos con personas que trabajan con varias metodologias, diagramas, patrones, etc y con personas que dejan de lados varios puntos.