República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación

Universidad Nacional Experimenta Politécnica de la Fuerza Armada

Nacional Bolivariana

UNEFA Núcleo Guacara Edo Carabobo

Modelo Relacional

Profesora:
Estudiante

Aryeling Manosalva
Gabriel González

Materia:
C.I:31.445.815

Base de Datos

5to semestre de ING de Sistemas sección 05S-2629-D1

Guacara,11 de octubre del 2024

 Pasar del Modelo Entidad-Relación al Modelo Relacional

Partiendo de un esquema conceptual (modelo Entidad-Relación),

podemos obtener un esquema relacional (modelo relacional) siguiendo
las siguientes reglas:
1. Cada entidad se representa como una tabla y sus atributos como
columnas de ésta.
Fondos (ID, ISBN, Titulo)

2. Cada Entidad débil se representa como una tabla, cuyas columnas

serán los atributos de ésta, añadiendo una columna más para la llave
primaria de la Entidad fuerte de la que depende.

Ejemplares (IDFondos,IDEjemplares, Estado Saludo, Ubicación)

3. En las relaciones 1:N (uno a muchos), se crea una tabla con los
atributos de la Entidad del extremo «N» (Fondos) como columnas y una
columna del atributo principal de la Entidad del extremo «1» (Editorial).
Dicho de otro modo, se propaga la clave principal de la de menor
cardinalidad.

Fondos (IDFondos, ISBN, Titulo, IdEditorial)

4. En el caso de una relación N:M (muchos a muchos), se crea una
tabla con los atributos principales de ambas Entidades como columnas y
tantas columnas como atributos tenga esa relación.
REP (IDEjemplares_IDPréstamos, Fecha, Fecha Real)

5. En una relación 1:1 la clave principal de una de las entidades se

propaga a la que tenga mayor cardinalidad o, sino, se escoge la opción
más lógica en el caso concreto para decidir de qué Entidad será
propagada su clave primaria.
Fondos (IdFondos, ISBN, Título, idEjemplar).

6. Cuando nos encontramos con las Generalizaciones o Jerarquías, hay

dos posibilidades:
A. Si no hay relaciones y atributos en las Entidades subtipos, se crea
una tabla con una columna con un atributo discriminador, que contendrá
los tipos de lectores (asemejándose a lo que sería un atributo
multivaluado). Por otro lado, estará la tabla de la Entidad supertipo, con
tantas columnas como atributos tenga y el atributo discrimandor en
cuestión.

Lectores (idLectores, DNI, Sanciones, Nombre, Teléfono,

Dirección, Tipo).
TipoLectores(Tipo).
B. Se crea una tabla para el supertipo y su clave principal se propaga a
los subtipos, cada uno con tantas columnas como atributos tengan
(independientes de la Entidad supertipo).
Fondos (idFondos, ISBN, Titulo)
Multimedia (idFondos, Formato) Libre (IdFondos, Páginas
 Normalización
La normalización es la transformación de las vistas de usuario
complejas y del almacén de datos a un juego de estructuras de datos
más pequeñas y estables. Además de ser más simples y estables, las
estructuras de datos son más fáciles de mantener que otras estructuras
de datos. (Kendall, 2005).
La normalización de bases de datos es un proceso que consiste en
designar y aplicar una serie de reglas a las relaciones obtenidas tras el
paso del modelo entidad-relación al modelo relacional. Con objeto de
minimizar la redundancia de datos, facilitando su gestión posterior
(Wikipedia).
Una vez obtenido el esquema relacional resultantes del modelo
entidad relación que representaba la base de datos, normalmente
tendremos una buena base de datos. Pero otras veces, debido a fallos
en el diseño o a problemas indetectables en esta fase del diseño,
tendremos un esquema que puede producir una base de datos que
incorpore estos problemas:
Redundancia: Se llama así a los datos que se repiten continua e
innecesariamente por las tablas de las bases de datos.
Ambigüedades: Datos que no clarifican suficientemente el registro al
que representan.
Objetivos
La normalización de bases de datos tiene como objetivos:
 Establecer un formato de datos estándar en todo el sistema
 Corregir datos duplicados y anomalías
 Evitar la creación de relaciones y dependencias no deseadas
 Prevenir borrados indeseados de datos
 Optimizar el espacio de almacenamiento
 Reducir el tiempo y complejidad de revisión de las bases de datos
 Facilitar el acceso e interpretación de los datos
 Eliminar datos redundantes
 Minimizar errores de modificación de datos
 Simplificar el proceso de consulta
 Dependencia Funcional
La dependencia funcional es una relación entre dos conjuntos de
atributos en una base de datos que describe cómo el valor de uno
determina el valor del otro. Se representa como X → Y, donde X e Y son
conjuntos de atributos.
¿Por qué son importantes las dependencias funcionales?
 Diseño de bases de datos: Las dependencias funcionales son
fundamentales para el diseño eficiente de bases de datos. Al
identificar estas dependencias, podemos organizar los datos de
manera lógica y evitar redundancias.
 Normalización: Las dependencias funcionales son la base de la
normalización de bases de datos, un proceso que busca eliminar
redundancias y anomalías en los datos.
 Integridad de los datos: Las dependencias funcionales ayudan a
garantizar la integridad de los datos, asegurando que los datos
almacenados sean consistentes y precisos.
Reglas de Inferencia de las Dependencias Funcionales (Axiomas
de Armstrong)
Existen varias reglas que permiten inferir nuevas dependencias
funcionales a partir de un conjunto dado de dependencias. Las más
importantes son:
 Reflexividad: Si Y ⊆ X, entonces X → Y. (Si Y es un subconjunto
de X, entonces X determina a Y).
 Aumento: Si X → Y, entonces XZ → YZ para cualquier Z. (Si
añadimos atributos a un lado de una dependencia, la dependencia
sigue siendo válida).
 Transitividad: Si X → Y y Y → Z, entonces X → Z. (Si X determina
a Y y Y determina a Z, entonces X determina a Z).
¿Cómo se utilizan las dependencias funcionales?
 Identificación de claves candidatas: Una clave candidata es un
conjunto mínimo de atributos que determina de forma única cada
 tupla en una relación. Las dependencias funcionales ayudan a
identificar las claves candidatas.
 Normalización de bases de datos: Las dependencias
funcionales son la base para aplicar las formas normales (Primera
Forma Normal, Segunda Forma Normal, Tercera Forma Normal,
etc.), que son reglas para diseñar bases de datos bien
estructuradas.
 Optimización de consultas: Al conocer las dependencias
funcionales, se pueden optimizar las consultas a la base de datos,
ya que se pueden identificar los índices adecuados y las uniones
más eficientes.

Ejemplos prácticos
 Base de datos de una librería:
o LibroID → Título, Autor
o Autor → Nacionalidad
 Base de datos de una universidad:
o Matrícula → Nombre, Carrera
o Carrera → Facultad

Formas Normales
Primera Forma Normal
Es la forma normal propia al esquema relacional, de uso
obligatorio.
 Todos los atributos llave están definidos.
 No hay grupos repetidos en la tabla. Cada fila/columna contiene
un solo valor, no un conjunto de ellos.
 Todos los atributos son dependientes de la llave primaria.
 Todos los atributos son atómicos. Un atributo es atómico si los
elementos del dominio son simples e indivisibles.
 No debe existir variación en el número de columnas.
  Los campos no clave deben identificarse por la clave (dependencia
funcional).
 Debe existir una independencia del orden tanto de las filas como
de las columnas; es decir, si los datos cambian de orden no deben
cambiar sus significados.
Algunos ejemplos de tablas (o de vistas) que no satisfacen esta
definición de primera forma normal son:
 Una tabla que carece de una clave primaria. Esta tabla podría
acomodar filas duplicadas, en violación de la condición de filas
duplicadas.
 Una vista cuya definición exige que los resultados sean retornados
en un orden particular, de modo que el orden de la fila sea un
aspecto intrínseco y significativo de la vista. Las tuplas en
relaciones verdaderas no están ordenadas una con respecto de la
otra.
 Una tabla con por lo menos un atributo que pueda ser nulo. Un
atributo que pueda ser nulo estaría en violación de la condición 4,
que requiere a cada campo contener exactamente un valor de su
dominio de columna. Sin embargo, debe observarse que este
aspecto de la condición 4 es controvertido. Muchos autores
consideran que una tabla está en 1FN si ninguna clave candidata
puede contener valores nulos, pero se aceptan éstos para
atributos (campos) que no sean clave, según el modelo original de
Codd sobre el modelo relacional, el cual hizo disposición explícita
para los nulos.
 Es imperativo mantener la unicidad de los valores de los
atributos/columnas. En que, si bien la solución inicial puede ser duplicar
el registro/tupla para contener la información adicional, no es una
medida aceptada. Otra opción aparente sería agregar curso 1 y curso 2.
Al igual que lo indicado en la figura siguiente permtiría atributos en
blanco o nulos.
Segunda Forma Normal
La Segunda Forma Normal (2FN) es un concepto fundamental en el
diseño de bases de datos relacionales. Es una de las varias formas
normales que se utilizan para organizar los datos de manera eficiente y
evitar redundancias. Una tabla está en 2FN si cumple con los siguientes
requisitos:
1. Primera Forma Normal (1FN): Debe cumplir con todos los
requisitos de la 1FN, es decir:
o Cada celda debe contener un solo valor atómico.
o Cada fila debe ser única.
o Debe existir una clave primaria que identifique de forma
única cada fila.
2. Dependencia Funcional Completa: Ningún atributo no clave
debe depender únicamente de una parte de la clave primaria. Es
decir, todos los atributos no clave deben depender de toda la
clave primaria.
¿Por qué es Importante la 2FN?
  Reducción de Redundancia: Al eliminar las dependencias
parciales, se reduce la cantidad de datos duplicados en la base de
datos.
 Mejora de la Integridad: Al asegurar que todos los atributos no
clave dependan de toda la clave primaria, se garantiza la
consistencia de los datos.
 Facilita las Modificaciones: Una base de datos normalizada es
más fácil de modificar y mantener.
 Optimiza las Consultas: Las consultas se ejecutan de manera
más eficiente en bases de datos normalizadas.

¿Cuándo Debo Aplicar la 2FN?

La 2FN debe aplicarse siempre que se diseñe una nueva
base de datos o se modifique una existente. Al seguir las reglas de
la 2FN, se garantiza que la base de datos sea eficiente,
consistente y fácil de mantener.
¿Qué Pasa si No Se Cumple la 2FN?
Si una tabla no cumple con la 2FN, puede llevar a los
siguientes problemas:
 Anomalías de Inserción: No se pueden insertar nuevos registros
sin incluir todos los atributos de la clave primaria, incluso si no se
conocen todos los valores.
 Anomalías de Eliminación: Al eliminar un registro, se pueden
eliminar accidentalmente datos relacionados.
 Anomalías de Actualización: Al actualizar un valor, se debe
actualizar en múltiples lugares, lo que puede llevar a
inconsistencias.

¿Por qué es Importante la 2FN?

 Reducción de Redundancia: Al eliminar las dependencias
parciales, se reduce la cantidad de datos duplicados en la base de
datos.
 Mejora de la Integridad: Al asegurar que todos los atributos no
clave dependan de toda la clave primaria, se garantiza la
consistencia de los datos.
  Facilita las Modificaciones: Una base de datos normalizada es
más fácil de modificar y mantener.
 Optimiza las Consultas: Las consultas se ejecutan de manera
más eficiente en bases de datos normalizadas.
Ejemplo
Tabla No Normalizada:
PedidoI Producto NombreProd Preci Cliente NombreClie
D ID ucto o ID nte

1001 P001 Teléfono 200 C001 Juan Pérez

1001 P002 Cargador 20 C001 Juan Pérez

En esta tabla, los atributos "NombreProducto" y "Precio" dependen
solo de "ProductoID", que es parte de la clave primaria (PedidoID,
ProductoID). Esto es una dependencia parcial y viola la 2FN.
Tablas Normalizadas en 2FN:
Tabla Pedidos:
PedidoI ClienteI
D D

1001 C001

Tabla DetallesPedido:
PedidoI Producto Cantid
D ID ad

1001 P001 1

1001 P002 1

Tabla Productos:
Producto NombreProd Preci
ID ucto o

P001 Teléfono 200

P002 Cargador 20
Tabla Clientes:
ClienteI NombreClie
D nte

C001 Juan Pérez

Al separar los datos en estas cuatro tablas, se elimina la

dependencia parcial y se cumple con la 2FN.

Tercera Forma Normal

La Tercera Forma Normal (3FN) es un concepto fundamental en el

diseño de bases de datos relacionales. Se trata de un nivel de
normalización que busca eliminar las dependencias transitivas,
asegurando así una estructura de datos más eficiente y menos propensa
a anomalías.
Dependencia transitiva: Ocurre cuando un atributo no clave depende
de otro atributo no clave a través de la clave primaria. Por ejemplo, en
una tabla de "Empleados", el atributo "Ciudad" podría depender de
"Departamento" y "Departamento" a su vez depender de
"ID_Empleado".
¿Por qué es importante la 3FN?
 Reducción de la redundancia: Evita la duplicación innecesaria
de datos, lo que ahorra espacio de almacenamiento y facilita la
actualización de la información.
 Mejora de la integridad: Minimiza la posibilidad de
inconsistencias en los datos, ya que cada atributo depende
directamente de la clave primaria o de otro atributo que forma
parte de ella.
  Facilita la consulta: Al tener una estructura de datos más clara y
organizada, las consultas a la base de datos son más eficientes y
precisas.
Condiciones para que una tabla esté en 3FN:
1. Debe estar en Segunda Forma Normal (2FN): No debe haber
dependencias parciales, es decir, cada atributo no clave debe
depender de la clave primaria completa.
2. No debe haber dependencias transitivas: Ningún atributo no
clave puede depender de otro atributo no clave.

Beneficios de trabajar con tablas en 3FN:

 Mayor flexibilidad: Facilita realizar cambios en la estructura de
la base de datos sin afectar la integridad de los datos.
 Mejor rendimiento: Las consultas son más rápidas y eficientes.
 Menor riesgo de errores: Se reducen las posibilidades de
introducir datos inconsistentes o duplicados.
Ejemplo con un almacén:
Imagina que tienes un almacén que vende productos electrónicos.
Inicialmente, tienes una tabla llamada "Productos" con la siguiente
estructura:
ID_Produc Nombre_Prod Preci País_Orige
Marca
to ucto o n

Samsu Corea del

1 Televisor 4K 500
ng Sur

Estados
2 Smartphone 300 Apple
Unidos

3 Laptop 800 Lenovo China

¿Qué pasa con esta tabla?

 Dependencia transitiva: Observa que el "País_Origen" de un
producto depende de la "Marca". Y a su vez, la "Marca" depende
del "ID_Producto". Esto es una dependencia transitiva, ya que
 "País_Origen" no depende directamente de la clave primaria
(ID_Producto), sino a través de otro atributo no clave ("Marca").

¿Por qué esto es un problema?

 Redundancia: Si quieres cambiar el país de origen de todos los
productos Samsung, tendrías que actualizar esta información en
cada fila donde aparezca la marca Samsung. Esto es ineficiente y
propenso a errores.
 Inconsistencias: Si por error se asigna un país de origen
diferente a un mismo producto en distintas filas, se generan
inconsistencias en los datos.
¿Cómo solucionamos esto con la 3FN?
Dividimos la tabla "Productos" en dos tablas:
1. Productos: | ID_Producto | Nombre_Producto | Precio | Marca |
|---|---|---|---| | 1 | Televisor 4K | 500 | Samsung | | 2 | Smartphone |
300 | Apple | | 3 | Laptop | 800 | Lenovo |
2. Marcas: | Marca | País_Origen | |---|---| | Samsung | Corea del Sur |
| Apple | Estados Unidos | | Lenovo | China |
¿Por qué esto es mejor?
 Eliminación de la dependencia transitiva: Ahora,
"País_Origen" depende directamente de "Marca", que es la clave
primaria de la tabla "Marcas".
 Reducción de la redundancia: La información sobre el país de
origen se almacena solo una vez, en la tabla "Marcas".
 Mayor flexibilidad: Si quieres cambiar el país de origen de una
marca, solo tienes que actualizar una fila en la tabla "Marcas".

Metodología para Alcanzar las Formas Normales en

Bases de Datos
¿Qué son las Formas Normales?
Antes de adentrarnos en la metodología, es fundamental entender
qué son las formas normales en el contexto de las bases de datos. Son
un conjunto de reglas que buscan organizar los datos de manera lógica y
eficiente, minimizando la redundancia y las anomalías. Las formas
normales más comunes son la primera, segunda y tercera.
Metodología General
1. Análisis de los Datos:
o Identificar las entidades: ¿Qué objetos o conceptos
representan los datos? (Ej: clientes, productos, pedidos)
o Determinar los atributos: ¿Qué características describen
a cada entidad? (Ej: nombre del cliente, precio del producto)
o Establecer las relaciones: ¿Cómo se relacionan las
entidades entre sí? (Ej: un cliente puede realizar muchos
pedidos)
2. Primera Forma Normal (1FN):
o Atomicidad: Cada celda debe contener un solo valor
atómico.
o Eliminar grupos repetitivos: Si hay grupos de datos
repetidos dentro de una celda, crear una nueva tabla.
o Clave primaria: Definir una clave primaria que identifique
de forma única cada fila.
3. Segunda Forma Normal (2FN):
o Dependencia total: Todos los atributos no clave deben
depender completamente de la clave primaria.
o Eliminar atributos parcialmente dependientes: Si hay
atributos que dependen solo de una parte de la clave
primaria, crear una nueva tabla.
4. Tercera Forma Normal (3FN):
o Dependencia transitiva: Ningún atributo no clave debe
depender transitivamente de otro atributo no clave.
o Eliminar dependencias transitivas: Si hay dependencias
transitivas, crear una nueva tabla.
Pasos Prácticos
 Crear un diagrama entidad-relación (DER): Visualizar las
entidades, atributos y relaciones de manera gráfica.
  Identificar las claves candidatas: Son los atributos que pueden
servir como clave primaria.
 Seleccionar la clave primaria: Elegir la clave primaria más
adecuada considerando factores como la unicidad y la estabilidad.
 Normalizar las tablas: Aplicar las reglas de cada forma normal
de manera secuencial.
 Verificar la integridad referencial: Asegurar que las relaciones
entre las tablas sean correctas y consistentes.
Ejemplo Práctico
Imagina una tabla "Pedidos" con los campos: Número de pedido, Cliente,
Producto, Cantidad, Precio.
 1FN: Si "Producto" contiene varios productos separados por
comas, crear una tabla aparte "Productos_Pedido".
 2FN: Si "Precio" depende solo del producto y no del número de
pedido, mover "Precio" a la tabla "Productos".
 3FN: Si "Ciudad" del cliente depende del código postal, crear una
tabla aparte "Ciudades".