Los diagramas o modelos entidad-relación (a veces denominado por su siglas, E-R “Entity relationship”) son una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades.

El Modelo Entidad-Relación es un concepto de modelado para bases de datos, propuesto por Peter Chen, mediante el cual se pretende ‘visualizar’ los objetos que pertenecen a la Base de Datos como entidades (esto es similar al modelo de Programación Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones.

Es una representación lógica de la información. Mediante una serie de procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo relacional.

El modelado entidad-relación es una técnica para el modelado de datos utilizando diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente consiste en los siguientes pasos:

1. Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos).

2. Se hace una lista de los sustantivos y verbos que aparecen.

3. Los sustantivos son posibles entidades o atributos.

4. Los verbos son posibles relaciones.

5. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles.

6. Se elabora el diagrama (o diagramas) entidad-relación.

7. Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementable en una base de datos. Brevemente:

  • Transformación de relaciones múltiples en binarias.
  • Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
  • Conversión en tablas en caso de utilizar una base de datos relacional.
  • Etc.
Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos. Informalmente, son simples dibujos o gráficos que describen la información que trata un sistema de información y el software que lo automatiza.

Los elementos de dicho lenguaje se describen a continuación, por orden de importancia.

Una entidad es cualquier “objeto” discreto sobre el que se tiene información. Se representa mediante un rectángulo o “caja” etiquetada en su interior mediante un nombre. Ejemplos de entidades habituales en los sistemas de información son: factura, persona, empleado, etc.

Cada ejemplar de una entidad se denomina instancia.Por ejemplo,”carlos ch y doris ar” pueden ser dos instancias distintas de la entidad “persona”. Las instancias no se representan en el diagrama. No obstante, se pueden documentar aparte porque son útiles para inicializar la base de datos resultante. Por ejemplo, los departamentos existentes de una empresa pueden ser relevantes como datos iniciales de la entidad “departamento”.

Una relación describe cierta interdependencia (de cualquier tipo) entre entidades. Se representa mediante un rombo etiquetado en su interior mediante un verbo. Además, dicho rombo debe unirse mediante líneas con las entidades que relaciona (es decir, los rectángulos).

Una relación no tiene sentido sin las entidades que relaciona. Por ejemplo: una persona (entidad) trabaja (relación) para un departamento (entidad).

Modelo Er (entidad-relación)

Los atributos son propiedades relevantes propias de una entidad y/o relacion. Se representan mediante un círculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta.

Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-relación, sino que se describen textualmente en otros documentos adjuntos.

Los atributos describen información útil sobre las entidades. En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un empleado de otro es su número de la Seguridad Social.

Ejemplos de atributos de la entidad “persona”:

  • Documento Nacional de Identidad (identificativo).
  • Nombre.
  • Apellidos.
  • Dirección.
  • Código postal.

Los diagramas Entidad-Relación no cumplen su propósito con eficacia debido a que tienen limitaciones semánticas. Por ese motivo se suelen utilizar los diagramas Entidad-Relación extendidos que incorporan algunos elementos más al lenguaje:

Cuando una entidad participa en una relación puede adquirir un papel fuerte o débil. Una entidad débil es aquella que no puede existir sin participar en la relación, es decir, aquella que no puede ser unívocamente identificada solamente por sus atributos. Una entidad fuerte es aquella que sí puede ser identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad fuerte “preste” algunos de sus atributos a una entidad débil para que, esta ultima, se pueda identificar.

Las entidades débiles se representan mediante un doble rectángulo, es decir, un rectángulo con doble línea.

Las relaciones, en principio binarias, pueden involucrar a un número distinto de instancias de cada entidad. Así, son posibles tres tipos de cardinalidades:

  • Relaciones de uno a uno: una instancia de la entidad A se relaciona con una y solamente una de la entidad B.
  • Relaciones de uno a muchos: cada instancia de la entidad A se relaciona con varias instancias de la entidad B.
  • Relaciones de muchos a muchos: cualquier instancia dela entidad A se relaciona con cualquier instancia de la entidad B.

El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: “1:1″, “1:N” y “N:M”, aunque la notación depende del lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación:

  • si la entidad no está obligada a participar en la relación.
  • “1″ si la entidad está obligada a participar en la relación y además, cada instancia solamente participa una vez.
  • “N” , “M”, ó “*” si la entidad no está obligada a participar en la relación y cada instancia puede participar cualquier número de veces.

Ejemplos de relaciones que expresan cardinalidad:

  • Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona puede tener varias facturas emitidas a su nombre. Es una relación 1:N.
  • Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser comprado por varios clientes distintos. Es una relación N:M.

Las relaciones también pueden tener atributos asociados. Se representan igual que los atributos de las entidades. Un ejemplo típico son las relaciones de tipo “histórico” donde debe constar una fecha o una hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisión de una factura a un cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo “Fecha de emisión” de la factura debería colocarse en la relación “se emite”.

La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos. La herencia es un tipo de relación entre una entidad “padre” y una entidad “hijo”. La entidad “hijo” hereda todos los atributos y relaciones de la entidad “padre”. Por tanto, no necesitan ser representadas dos veces en el diagrama. La relación de herencia se representa mediante un triángulo interconectado por líneas a las entidades. La entidad conectada por el vértice superior del triángulo es la entidad “padre”. Solamente puede existir una entidad “padre” (herencia simple). Las entidades “hijo” se conectan por la base del triángulo.

El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional.

Las bases de datos relacionales se normalizan para:

  • Evitar la redundancia de los datos.
  • Evitar problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla bidimensional sea considerada como una relación tiene que cumplir con algunas restricciones:

  • Cada columna debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.
  • entidad = tabla o archivo
  • tupla = registro, fila o renglón
  • atributo = campo o columna
  • base de datos = banco de datos
  • dependencia multivaluada = dependencia multivalor
  • clave = llave
  • clave primaria = superclave
  • clave ajena = clave externa o clave foránea
  • RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
  • 1FN = Significa, Primera Forma Normal aunque en diferentes articulos puede que lo encontremos como 1NF que viene del ingles First Normal Form.

Una dependencia funcional son conexiones entre uno o más atributos. Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos conocer el valor de Edad.

Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:

Fecha De Nacimiento→Edad

Aquí a Fecha De Nacimiento se le conoce como un determinante. Se puede leer de dos formas Fecha De Nacimiento determina a Edad o Edad es funcionalmente dependiente de Fecha De Nacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr mayor eficiencia en las tablas.

transitiva’‘’

ID_Estudiante → Curso_Tomando

Curso_Tomando → Profesor_Asignado

ID_Estudiante → Curso_Tomando → Profesor_Asignado

Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a través del ID_estudiante el Profesor_Asignado.

Clave candidata Este registro de cada entrada en la tabla es imprescindible. Indicará de forma unívoca la identidad de la entrada a la que representa. Es habitual usar un número que se incrementa con cada inserción, o autonumérico. Puede haber más de una clave candidata en una tabla. Sólo una de ellas actuará como clave primaria.

Clave alternativa Son aquellas claves candidatas que no han sido seleccionadas como clave primaria.

Clave simple Es una clave que está compuesta de un solo atributo, pero que está aparte en un sistema.

Clave compuesta Es una clave que está compuesta por más de un atributo.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, éste introdujo la normalización en un artículo llamado A Relational Model of Data for Large Shared Data Banks..

Primera Forma Normal (1FN) Una relación está en Primera Forma Normal si y sólo si todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.

Por ejemplo La Relación:

  • cursos: nombre, código, vacantes, horario, bibliografía

Queda después de aplicar la Forma Normal 1 de la siguiente manera:

  • cursos1: nombre, código, vacantes
  • horario1: código, día, módulo
  • bibliografia1: código, nombre, autor

Una columna no puede tener multiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X).

Segunda Forma Normal (2FN)

Dependencia completa. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependecias parciales. Los atributos dependen de la clave. Varía la clave y varían los atributos.

En Otras palabras pudiésemos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional X → Y es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – Ā) -x→ Y. Una dependencia funcional X→ Y es una dependencia parcial si hay algunos atributos A Є X que pueden ser removidos de X y la dependencia todavía se mantiene, esto es A Є X, (X – Ā) → Y . Por ejemplo {SSN,PNUMBER} → HOURS es completamente dependencia dado que ni SSN → HOURS ni PNUMBER → HOURS mantienen la dependencia. Sin embargo {SSN,PNUMBER} → ENAME es parcialmente dependiente dado que SSN→ENAME mantiene la dependencia

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.

Un ejemplo de este concepto sería que, una dependencia funcional X→Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X→Z y Z→Y.. Por ejemplo, la dependencia SSN→DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva via DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

Forma Normal de Boyce-Codd (FNBC)

La tabla se encuentra en BCNF si cada determinante, atributo que determina completamente a otro, es clave candidata.

Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse “más relacional” cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

“Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla”.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos.

Regla No. 2 - La regla del acceso garantizado

“Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna”.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.

% Regla No. 3 - Tratamiento sistemático de los valores nulos

“La información inaplicable o faltante puede ser representada a través de valores nulos”.

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.

No. 4 - La regla de la descripción de la base de datos

“La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados”.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL.

Regla No. 5 - La regla del sub-lenguaje Integral

“Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones”.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

“Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo”.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

“La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos”.

Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física

“El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos”.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

“Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos”.

La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad

“Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación”.

Las reglas de integridad son:

1. Ningún componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma básica de integridad). 2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya Integridad referencial.

Regla No. 11 - La regla de la distribución

“El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación”.

El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que este conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

“Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL)”.

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.

Fuente de Informacion: http://es.wikipedia.org/wiki/Modelo_E-RComunicate conmigo en Skype: My status
Competencias Adquiridas con la realizacion de este tema
  • Se adquirio el Conocimiento de manejar html junto con Wiki al editar un sito de internet.
  • Aprendi a Realizar un video educativo en el da una explicacion de un tema.
  • Tambien adquiri el conocimiento para realizar un chat de un tema y asi discutir los diferentes puntos de vista.
  • Al mismo tiempo adquiri habilidades para generar una video conferencia por medio de la pagina del tema usando Skype.
  • Soy competente al usar la plataforma Google para realizar un video, subirlo a la red y editarlo.
  • Igualmente crear un audio narrativo y explicativo sobre un tema.
  • Disenar un elemento flash para asi poder crear una animacion simple sobre un tema.
  • Ahora puedo realizar presentacion en Word, Excel y Powerpoint con la plataforma google y cualquier persona pueda tener acceso a esos documentos.
  • Un conocimiento extra es haber manejado Picasa y editar fotos, crear slides y galerias para poder visualizadas en cualquier sitio.

‘’‘ Click sobre la foto para entrar a mi perfil, Mi E-mail es: danielfigueroa11@gmail.com


Google