Modelo Entidad-Relación Paul Leger http://pleger.cl pleger@ucn.cl

Modelos de una Base de Datos Conceptual: Entidad-Relación Lógico: Relacional Físico: representación física de los datos (lenguajes de base de datos, estructuras de archivos, algoritmos de búsquedas, etc) En este nivel, solamente veremos SQL

Modelo E-R: Un modelo conceptual (1) Peter Pin-Shan Chen (1947). Creador del modelo Entidad-Eelación (E-R) El Modelo Entidad-Relación es fácil comprender por usuarios finales y desarrolladores En el mundo de desarrollo de software, generalmente se usa este modelo para validar la información que contiene una organización E-R se puede considerar como una extensión (o versión) más compleja del modelo conceptual de datos

Modelo E-R: Un modelo conceptual (2) Un modelo E-R es creado a través de una descripción en prosa de uno o varios escenarios El detalle de estos escenarios es fundamental para capturar la información que maneja una organización Por ejemplo, suponga que una compañía desea guardar dónde viven todos sus clientes Vive Cliente Ciudad

Principales Conceptos Cliente Entidad Representa un concepto/sustantivo Nombre es generalmente singular Tiene atributos Relación Relación dos (o más) entidades a través de un verbo Una relación tiene cardinalidad de participación - Rut - Nombre n vive 1 Ciudad - Nombre - Numeros de habitantes

Más sobre cardinalidad Vive 1 Cliente Ciudad ¿Qué pasa si la compañía tiene registradas ciudades donde no viven clientes? 0..n Vive 1 Cliente Ciudad ¿Qué pasa si un cliente puede tener registrado que vive en tres ciudades como máximo? n Vive 1..3 Cliente Ciudad “0” significa un participación parcial de la relación ¿Qué pasa si la compañía acepta a clientes que no vivan en ninguna ciudad registrada? n Vive 0..1 Cliente Ciudad

Modelo E-R: Un modelo conceptual (2) Empresa Elmasri Ejercicio: En el diagrama anterior, encuentre las entidades con sus atributos y sus relaciones con su cardinalidades

Conociendo a fondos a los atributos de una entidad (1) Compuestos: los cuales están compuestos de más de un dato (ej. dirección). Hint: Por lo general se recomienda separar en más de un atributo (ej. ciudad, calle, número) Mono y multi valuados: Mono -> los cuales solo pueden contener un solo valor (ej. rut). Multi -> los pueden contener más de un valor (ej. grados académicos). Hint: Los multi evaluados se modelan en una entidad aparte Derivados: Los cuales pueden ser calculados desde otros datos (ej. edad puede ser calculado desde fecha de nacimiento). Hint: Los derivados generalmente deben ser omitidos de un base de datos

Conociendo a fondos a los atributos de una entidad (2) Nulo: Una entidad podría carecer de la información en algunos de los atributos (ej. número fijo en persona). Hint: Evitar tener información nula Atributos claves (Primary Key): Cada instancia de una entidad debería ser diferentes de las demás. Una instancia puede identificada por su atributo clave (ej. rut). En ocasiones, un solo atributo no es suficiente, se necesita un conjunto de atributo (ej. un viaje en bus => patente, fecha). Hint: en ocasiones, pueden haber más un candidato de atributos para ser atributos primary key, en ese caso, seleccione al más corto

Conociendo a fondos a los atributos de una entidad (3) Atributos “Tabulados”: Hay ciertos que tienen un conjunto finito y potencialmente pequeño de datos (ej. ciudad, calles, países, modo pago, Isapre). Hint: Para estos atributos, es recomendable tener una entidad independiente para estos datos Dependencia entre atributos: Hay ciertos atributos cuyo valor dependen de otros atributos (ej. ciudad y región). Hint: Para los atributos dependiente, se recomiendan tenerlos en otra entidad

Leer capitulo 3 del libro ¿Preguntas? Leer capitulo 3 del libro