Base de Datos
Unidad:
Modelado de Datos
Docente: Jorge Bojorquez
Diagrama Entidad Relación
(DER)
Definiciones
• Diagrama Entidad Relación: Es el Modelo de Datos que usaremos y tal como vimos tiene tres fases
de construcción: conceptual, lógico, y físico. Sus componentes son las entidades que contienen
atributos y las relaciones entre entidades.
• Modelado de datos: Proceso iterativo para diseñar una base de datos que pueda guardar
información relevante y responder a las preguntas del usuario relacionadas con dicha información.
• Modelo de datos: Plano de construcción la base de datos. Se representa mediante el DER.
Necesidad del Modelado de Datos
Tal como aprendimos durante el Caso de introducción del curso, un correcto diseño nos permite
almacenar datos:
• Con una relación entre tablas acorde al proceso
• Previniendo datos repetidos
• Previniendo el ingreso de datos inválidos o no existentes
• Evitando redundancia tanto como sea posible
• Permitiendo guardar toda la información relevante del proceso atendido
• Permitiendo excelentes tiempos de respuesta en consultas y actualizaciones de información
• Sin desperdiciar espacio en el disco
Metodologías de Modelado de Datos
• Bottom-Up: Son el resultado de un esfuerzo de reingeniería. Por lo general, comienzan con formularios
de estructuras de datos existentes (campos en pantallas de aplicaciones o informes). Estos modelos
suelen ser físicos, específicos de la aplicación e incompletos desde una perspectiva empresarial.
• Top-Down: Se crean de manera abstracta al obtener información de personas que conocen el negocio.
Un sistema puede no implementar todas las entidades en un modelo lógico, pero el modelo sirve como
punto de referencia.
Notaciones del DER
El DER se representa de varias maneras (notaciones) aunque las más usadas son la Chen y la Crow’s foot.
En la imagen se ven varias notaciones. Lo que tienen en común es que buscan definir las entidades y
establecer las relaciones entre ellas.
Entidad
Relación
Entidad
Relación
Notaciones del DER - CHEN
Símbolos
Notaciones del DER - CHEN
Ejemplo
Notaciones del DER – CROW’S FOOT
Símbolos
Notaciones del DER – CROW’S FOOT
Ejemplo
Pasos para crear un DER
1. Crear DER conceptual a partir de los documentos del
proceso
2. Crear DER lógico al completar atributos, establecer PK, FK,
convertir relaciones M-M en 1-M. Finalmente se debe
normalizar las tablas
3. Crear DER físico al especificar cual es el tipo de dato de un
SGBD específico para que se pueda implementar
Pasos para crear un DER
1. Crear DER conceptual a partir de los documentos del proceso
2. Crear DER lógico al completar atributos, establecer PK, FK, convertir relaciones M-M en 1-M.
Finalmente se debe normalizar las tablas
3. Crear DER físico al especificar cual es el tipo de dato de un SGBD específico para que se pueda
implementar
1 2 3
Herramienta de Modelamiento
Usaremos https://www.draw.io/ que es una herramienta online y gratuita. Permite hacer varios tipos
de diagramas, en particular los DER. Puede guardar tus proyectos principalmente en el disco duro, en
google drive y en Microsoft Onedrive
Ejemplo de Modelamiento
Haga el diagrama entidad relación lógico de:
• Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de
los clientes (nombre, apellidos, dni, dirección y fecha de nacimiento). Cada producto tiene un
nombre y un código, así como un precio unitario. Un cliente puede comprar varios productos a
la empresa, y un mismo producto puede ser comprado por varios clientes.
• Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta
que un producto puede o no tener asociado un proveedor, y que un proveedor suministra
uno o varios productos. De cada proveedor se desea conocer el RUC, nombre y dirección.
Ejemplo de Modelamiento - Solución
Entidades y atributos encontrados:
• Cliente: Dni, nombre, apellidos, dirección, fecha_nac
• Producto: Codigo, nombre, precio_unit
• Proveedor: Nif, nombre, dirección
Relaciones entre entidades encontradas:
• Cliente – Producto:
• De ida: 1 Cliente tiene Muchos Productos
• De regreso: 1 Producto tiene Muchos Clientes
• Resultado: Muchos a Muchos (M - M)
• Proveedor - Producto:
• De ida: 1 Proveedor tiene Muchos Productos
• De regreso: 1 Producto tiene 1 Proveedor
• Resultado: Uno a Muchos (1 - M)
Ejemplo de Modelamiento - Solución
Paso 1: DER Conceptual. Solución en ambas notaciones
Crows foot
Chen
Ejemplo de Modelamiento - Solución
Paso 2: DER Lógico. Empezamos en el conceptual y cambiamos:
• Agregar atributos a entidades
• Identificar los atributos PK en cada tabla
• En todas las relaciones 1-M: las PK de la tabla con 1 debe pasar como FK de la tabla con M. Por esto
la tabla Producto ganaría un atributo FK llamado nif que hace referencia a la PK de la tabla
Proveedor.
• Todas las relaciones M-M deben ser convertidas en dos 1-M mediante una tabla intermedia. Los 1
apuntan a las tablas originales y ambos M apuntan a la nueva tabla intermedia. La tabla intermedia
tendrá las PK de ambas tablas originales, las que formarán una PK compuesta. Nótese que
adicionalmente cada atributo de la PK compuesta es un FK que apunta a sus respectivas tablas de
origen. Por esto Entre Cliente y Producto se creará la tabla ProdXCli y sus atributos serán código y
dni, que como conjunto son una PK compuesta, pero individualmente son FK de las tablas Producto
y Cliente respectivamente. En Chen la relación se convierte en tabla intermedia.
Ejemplo de Modelamiento - Solución
Paso 2: DER Lógico. Solución en ambas notaciones
Crows foot
Chen
Ejemplo de Modelamiento - Solución
Paso 3: DER Físico. Empezamos en el conceptual y cambiamos:
• Agregar los tipos de datos del SGBD a implementar, en este caso SQL Server.
• En caso de CHEN, cada relación que representaba una tabla debido a un muchos a muchos, como la
que está entre Cliente y Producto, debe convertirse en tabla y ponerle relaciones para conectarlas
con las otras tablas.
• A cada lado de cada relación entre tablas se le define el mínimo y máximo y se debe representar
según cada notación. Por ejemplo Entre Proveedor y Producto inicialmente tenemos 1-M, pero si
vemos el texto:
• El 1 es en realidad 0 o 1. “un producto puede o no tener asociado un proveedor”
• El M es en realidad 1 o M. “un proveedor suministra uno o varios productos”
En resumen entre Proveedor y Producto existe una relación de (0 o 1) a (1 o M).
Ejemplo de Modelamiento - Solución
Paso 3: DER Físico. Solución en ambas notaciones
Crows foot
Chen
Tipos de modelos
Tipos de Modelos de Datos
• Jerárquico
• Red
• Relacional
• Orientada a Objetos
Tipos de Modelos de Datos
Cada nuevo modelo de datos buscaba resolver los problemas de modelos previos. El modelo de red
sustituyo al modelo jerárquico porque este hizo mucho mas fácil representar relaciones complejas (muchos
a muchos). A su vez el modelo relacional ofrece varias ventajas sobre el modelo jerárquico y red por medio
de su mas sencilla representación de datos, superior independencia de datos y leguaje de consulta fácil de
usar logrando posicionarse como la favorita en las aplicaciones de negocio.
Adicional a esta esta la Orientada a Objetos pero no es muy utilizada y solo 5 SGBD la implementan
Reglas de Negocio
Reglas de Negocio
Son una descripción breve y no ambigua de una política, o procedimiento de una organización, estas se
aplican a los datos, y sirven a manejar la integridad de los datos.
Estas restricciones se expresan normalmente en forma de reglas que ayudan a definir entidades,
atributos, relaciones y restricciones.
Un SGBD puede implementar ciertos tipos de reglas en forma de restricciones.
Ejemplos de reglas de negocios:
• El salario de un trabajador puede tener valores entre 850 a 15000.
• El promedio de calificación de estudiante puede estar entre 0 a 10.
• Cada clase debe tener un y solo y un maestro.
• Un agente puede atender a varios clientes y cada cliente puede ser atendido por un solo agente.
• Una sesión de capacitación no puede ser programada para menos de 10, ni para mas de 30
empleados.
Tipos de Relaciones
Uno a Uno
Cada fila de una tabla hace referencia a solo una fila de la otra. La PK de una tabla debe ser la FK de la
otra
Uno a Muchos
Cada fila de la tabla con el 1 se relaciona con una o varias filas de la otra. La PK de una tabla con 1 debe
ser la FK en la tabla con M.
Uno a Muchos - débil
Cada fila de la tabla con el 1 se relaciona con una o varias filas de la otra. Cada fila de la tabla con
el M no puede existir sin que exista la fila relacionada en la tabla con el 1.
La PK de una tabla con 1 debe ser la FK en la tabla con M, pero además debe ser parte de la llave
primaria de la tabla con el M.
Este caso es común en tablas cabecera / detalle
Muchos a Muchos
La relación Muchos a Muchos no puede representarse en una base de datos relacional, por lo que
debe usarse una tabla intermedia, la cual estará compuesta por las PK de las dos tablas de origen.
Los atributos que vienen con FK de estas tablas serán una PK compuesta.
Recursividad
Es cuando el valor de un atributo de una tabla se debe validar contra la PK de la misma tabla. Un
ejemplo frecuente es la tabla de Empleados de una empresa porque la PK es el código del empleado
pero también existe otro atributo jefe que tiene el código del empleado que es su jefe. Por tanto del
atributo jefe hace una FK hacia la misma tabla para validar que el código del jefe sea un código de
empleado válido
Normalización
Introducción
Concepto introducido por Edgar Frank Codd en 1970 con estos objetivos:
• Para liberar la colección de relaciones (tablas) de dependencias de inserción, actualización y
eliminación no deseadas.
• Para reducir la necesidad de reestructurar la colección de relaciones (tablas), a medida que se
introducen nuevos tipos de datos, y así aumentar la vida útil de los softwares de aplicación.
• Hacer que el modelo relacional sea más informativo para los usuarios.
• Hacer que la colección de relaciones (tablas) sean neutrales para el cálculo de estadísticas, donde
estas estadísticas pueden cambiar a medida que pasa el tiempo.
Objetivos de la Normalización
Se resume en lograr:
• Minimizar la redundancia (repetición) de los datos, por tanto ahorrar espacio.
• Disminuir problemas al agregar, actualizar y borrar datos en las tablas.
• Proteger la integridad de datos.
• Agrupar datos relacionados directamente en una misma tabla.
• Optimizar el tiempo de respuesta de las consultas, inserciones, actualizaciones y borrado de los
datos
¿Cuántos niveles de normalización
existen?
Actualmente hay hasta 10 niveles de normalización, aunque una base de datos relacional se considera
"normalizada" si cumple hasta la tercera forma normal. (Wikipedia)
1ra Forma Normal
Redistribuir datos en tablas tal que:
1. No deben haber filas repetidas
2. Se identifiquen las clave primaria(PK) y llaves foráneas(FK) que correspondan
3. Eliminar grupos repetidos de columnas. Se creará una tabla de detalle dependiente de la PK de
la principal
4. Eliminar columnas que guarde múltiples valores. Se creará una tabla de detalle dependiente de
la PK de la principal
2da Forma Normal
Redistribuir datos en tablas tal que:
1. Cumpla la 1FN
2. Cada columna que pertenece a una tabla debe tener dependencia funcional con la clave
primaria(PK)
Este caso se aplica a relaciones con llaves compuestas.
Recordando que es Dependencia Funcional:
Si uno o varios atributos son determinados de manera única por un tercero, entonces tienen una
dependencia funcional con este. Ejemplo:
DNI nombre, dirección y teléfono
3ra Forma Normal
Redistribuir datos en tablas tal que:
1. Cumpla la 2FN
2. No deben haber columnas dependiente funcionalmente de manera transitiva con la clave
primaria(PK). Se incluyen columnas calculadas
Es decir que las si hay columnas en la tabla que no son dependientes funcionalmente con la PK entonces
deben ir a otra tabla. Nótese que también significa que no deben existir columnas calculadas por la
misma razón, dichos datos se deberán calcular al necesitarlos o se guardarán en otra tabla.
¿Que es Dependencia Transitiva?
Si X -> Y , además Y -> Z, entonces Z tiene dependencia transitiva con X.
Código Código Código Dirección
factura Cliente Cliente Cliente
Caso de Ejemplo: Hoja de Pedido
Explicaremos las formas normales iniciales mediante un caso:
Caso de Ejemplo: Hoja de Pedido
Paso 1:
Caso de Ejemplo: Hoja de Pedido
Paso 2:
Caso de Ejemplo: Hoja de Pedido
Caso de Ejemplo: Hoja de Pedido
Paso 3:
Caso de Ejemplo: Hoja de Pedido
Paso 4:
Caso de Ejemplo: Hoja de Pedido
Caso de Ejemplo: Hoja de Pedido
Paso 5:
Caso de Ejemplo: Hoja de Pedido
Paso 6:
Caso de Ejemplo: Hoja de Pedido
Caso de Ejemplo: Hoja de Pedido
Paso 7: Implemente las tablas en el SQL Server
Desnormalización
Introducción
• Lamentablemente usar las formas normales de manera total no permite alcanzar su objetivo
de rapidez de acceso a los datos.
• Adicionalmente, en la realidad, la redundancia es útil por ejemplo en datos de resumen
evitando recálculos y mejorando el tiempo de respuesta al usuario.
• La experiencia enseñó que siempre es más importante dar un excelente tiempo de respuesta
al usuario.
Desnormalización
Trata de balancear la rapidez de consulta con el hecho de tener datos redundantes o calculados.
Para desnormalizar se necesita que la base de datos esté previamente normalizada.
Algunas bases de datos como Postgres y Oracle ayudan a automatizar la desnormalización
mediante las Vistas Meterializadas que son Consultas (SELECT) que se guardan automáticamente
como tablas de manera redundante, las cuales se recalculan conforme los datos cambien.
Si la base de datos no ayuda entonces de debe hacer el recalculo manual de dos maneras:
• Total con baja frecuencia de veces: Logra datos consistentes pero con un alto costo en uso de
procesamiento.
• Incremental con alta frecuencia de veces: Logra datos medianamente consistentes. Cada
cambio en la información sufriría un costo moderado en uso de procesamiento.
Cuándo y porqué desnormalizar
1. Mantener un historial: Debido a que los datos cambian con el tiempo, si se quiere saber como
evolucionó se puede adicionar una tabla que contenga el historial de estos cambios.
2. Mejora del rendimiento: Si hay consultas que requieran unir varias tablas o recalcular campos,
puede crear campos o tablas redundantes.
3. Acelerar reportes: Si necesitamos resúmenes con mucha frecuencia que requieran de muchos
registros notaremos que demorarán considerablemente. Se crearán tablas redundantes.
4. Cálculo de valores por adelantado: Si necesitamos datos calculados sin tener que calcularlos en
tiempo real, debe crear campos redundantes.
5. No desnormalice a menos que su sistema tenga problemas de rendimiento no relacionados a vicios
de programación, de la base de datos o del servidor.
Desventajas de la desnormalización
1. Más espacio en disco: Por datos duplicados.
2. Anomalías en los datos: Los datos ahora se pueden cambiar en más de un lugar. Debemos
recalcular cada dato duplicado o redundante.
3. Documentación: Debemos documentar cada regla de desnormalización aplicada.
4. Ralentización de otras operaciones: Ralentizaremos inserciones, modificaciones y eliminaciones
de datos. Dependiendo de la frecuencia, podría ralentizar notablemente todo el sistema.
5. Más codificación: No todas las bases de datos pueden atender las diferentes desnormalizaciones.
Se deben atender haciendo cambios en programas u otros procesos en segundo plano.
Diccionario de datos
Diccionario de datos
El diccionario de datos proporciona una descripción detallada de todas las tablas de la base
de datos creada por el usuario y el diseñador, de este modo el diccionario de datos
contiene, al menos, todos los nombres de atributos y características para cada tabla en el
sistema.
Diccionario de datos
• En una base de datos podemos encontrar las definiciones de nuestra base de datos en el
catálogo del sistema: Este describe todos los objetos de la base de datos, incluyendo
creador, la fecha de creación de la tabla, el número de columnas en cada tabla, el tipo de
datos correspondiente a cada columna, índice los nombres de archivo, los creadores de
índice, los usuarios autorizados, y privilegios de acceso.
• El catálogo del sistema es en realidad una base de datos creada por el sistema de cuyas
tablas almacenar las características de base de datos ,de usuario, etc. Por lo tanto, las
tablas de catálogo del sistema se pueden consultar al igual que cualquier tabla de usuario.
Gracias
Docente: Jorge Bojorquez
