Fundamentos de Bases de Datos Relacionales: Diseño, Álgebra y Normalización

Enviado por Comunidad Wikiteka y clasificado en Informática

Escrito el 19 de Agosto de 2025 en español con un tamaño de 14,36 KB

Conceptos Fundamentales del Modelo Relacional

El Modelo Entidad-Relación (E/R) establece las normas para diseñar esquemas conceptuales de bases de datos. El Modelo Relacional, por su parte, define las normas para implementar Bases de Datos, fundamentado en una sólida base matemática.

Definiciones Clave

Un atributo es la información específica que interesa almacenar, representada comúnmente como un campo o columna.
El dominio de un atributo es el conjunto de todos los valores posibles que puede tomar.
Un valor es el dato concreto que un atributo toma en un registro específico.
Un registro (o tupla) es un conjunto de valores que representan una instancia única de una entidad.
Una relación (o tabla) es una estructura que consta de un conjunto de atributos (su esquema) y un conjunto de registros (sus instancias).

Identificación de Claves

Una superclave (SuperC) es cualquier conjunto de atributos que puede identificar de forma única una tupla dentro de una relación.
Una clave candidata (CC) es una superclave mínima, lo que significa que ningún subconjunto de sus atributos es, por sí mismo, una superclave.
La clave primaria (CP) es una clave candidata elegida para identificar de forma única cada registro en una tabla.

Álgebra Relacional: Operaciones Fundamentales

El Álgebra Relacional es un lenguaje de consulta procedimental que permite manipular relaciones (tablas) para obtener nuevas relaciones. Se compone de operaciones unarias y binarias.

Operaciones Unarias

Selección (σ): Filtra las tuplas de una relación (R) que cumplen una condición específica. Mantiene todas las columnas de R, pero solo las tuplas que satisfacen la condición.
```
σ_condición(R)
```
Proyección (π): Selecciona un subconjunto de columnas de una relación (R). Mantiene todas las tuplas de R, pero solo las columnas especificadas.
```
π_atributos(R)
```
Renombrar (ρ): Permite cambiar el nombre de una relación o de sus atributos.
```
ρ_{nuevo_nombre}(R)
```
```
ρ_{nuevo_nombre(A1, A2, ...)}(R)
```

Operaciones Binarias

Producto Cartesiano (×): Combina cada tupla de la relación R con cada tupla de la relación S. El resultado tiene todas las columnas de R y S, y el número de tuplas es el producto del número de tuplas de R y S.
```
R × S
```
Join Natural (⋈): Combina tuplas de dos relaciones (R y S) basándose en la igualdad de sus atributos comunes. El resultado incluye las columnas de R y S (sin duplicar las comunes) y las tuplas donde los valores de los atributos comunes coinciden.
```
R ⋈ S
```
Unión (∪): Combina todas las tuplas de dos relaciones (R y S) que tienen el mismo esquema (mismo número y tipo de atributos). El resultado incluye todas las tuplas de R y S, eliminando duplicados.
```
R ∪ S
```
Intersección (∩): Retorna las tuplas que están presentes en ambas relaciones (R y S), asumiendo que tienen el mismo esquema.
```
R ∩ S
```
Diferencia (–): Retorna las tuplas que están en la relación R pero no en la relación S, asumiendo que tienen el mismo esquema.
```
R – S
```
División (÷): Se utiliza para encontrar tuplas en R que están asociadas con todas las tuplas de S. El resultado incluye los atributos de R que no son comunes con S.
```
R ÷ S
```

Ejemplos de Consultas en Álgebra Relacional

A continuación, se presentan ejemplos de consultas complejas utilizando las operaciones del álgebra relacional:

Consulta 1: Identificar ofertas con mismo código de empresa pero diferente trabajador.
```
var := π_A.*(σ_{A.cod_empr=B.cod_empr AND A.cod_tra≠B.cod_tra}(ρ_A(OFER) × ρ_B(OFER)))
```
Esta consulta var identifica todas las ofertas (OFER) que tienen el mismo código de empresa (cod_empr) pero un código de trabajador (cod_tra) diferente, proyectando todos los atributos de la primera instancia de la oferta.
Consulta 2: Códigos de empresa con ofertas únicas por trabajador.
```
solo1 := π_{cod_empr}(OFER – var)
```
La consulta solo1 obtiene los códigos de empresa de las ofertas que no cumplen la condición definida en var, es decir, aquellas ofertas que no tienen otra oferta con el mismo cod_empr pero diferente cod_tra.
Consulta 3: Clientes y descripciones de pedidos en 2005.
```
p2m5 := π_nif,desc(σ_fech=2005(CLI ⋈ PED))
```
La consulta p2m5 obtiene el NIF y la descripción de los clientes que realizaron pedidos en el año 2005.
Consulta 4: NIFs de clientes con descripciones inconsistentes en 2005.
```
noalto := π_A.nif(σ_{A.desc≠B.desc}(ρ_A(p2m5) × ρ_B(p2m5)))
```
La consulta noalto identifica los NIF de clientes que, habiendo realizado pedidos en 2005, tienen descripciones diferentes para el mismo NIF (lo cual podría indicar un problema de datos o una interpretación específica).
Consulta 5: NIFs de clientes con descripciones consistentes en 2005.
```
alto2m5 := π_nif(p2m5) – noalto
```
La consulta alto2m5 obtiene los NIF de clientes que realizaron pedidos en 2005 y que no tienen descripciones diferentes para el mismo NIF (es decir, sus descripciones son consistentes).
Consulta 6: Películas disponibles en todos los idiomas.
```
pelis_todos_idiomas := π_pelis.*((CINT ÷ π_idioma(CINT)) ⋈ PELIS)
```
Esta consulta pelis_todos_idiomas busca las películas que tienen cintas disponibles en todos los idiomas registrados en la tabla CINT, y luego une este resultado con la tabla PELIS para obtener todos los detalles de esas películas.

Mapeo del Modelo Entidad-Relación al Modelo Relacional

El proceso de transformar un diseño conceptual E/R en un esquema relacional implica reglas específicas para cada componente:

Mapeo de Entidades

Entidades Fuertes: Se mapean directamente a una tabla. La clave primaria de la entidad se convierte en la clave primaria de la tabla.
Entidades Débiles (Existencia): Se mapean a una tabla. Su clave primaria se forma combinando su identificador parcial con la clave primaria de la entidad fuerte de la que depende.
Entidades Débiles (Identificación): Se mapean a una tabla que incluye la clave primaria de la entidad padre como parte de su propia clave primaria (o como clave foránea que forma parte de la clave primaria).

Mapeo de Relaciones

Relaciones N:N (Muchos a Muchos): Se transforman en una nueva tabla. Esta tabla contiene las claves primarias de las entidades participantes como claves foráneas (que a menudo forman la clave primaria compuesta de la nueva tabla), más cualquier atributo propio de la relación.
Relaciones 1:N (Uno a Muchos): La clave primaria de la entidad del lado '1' se propaga como clave foránea a la tabla de la entidad del lado 'N'.
Relaciones 1:1 (Uno a Uno): La clave primaria de una de las entidades se propaga como clave foránea a la tabla de la otra entidad. La elección depende de la participación y la cardinalidad. Alternativamente, se puede crear una tabla separada para la relación.

Mapeo de Especializaciones (Generalización/Especialización)

Existen diferentes estrategias para mapear jerarquías de especialización:

Estrategia de Colapso (Single Table Inheritance): Se crea una única tabla para la superclase que incluye todos los atributos de la superclase y de todas sus subclases, además de un atributo discriminador para identificar el tipo de subclase.
Estrategia de Explicitación (Table Per Subclass): Se crea una tabla para la superclase y una tabla separada para cada subclase. Las tablas de las subclases incluyen sus propios atributos y una clave foránea que referencia la clave primaria de la tabla de la superclase.

Nota sobre Cardinalidades: En ciertos casos de cardinalidades complejas, como una relación donde una entidad participa con cardinalidad (0,1) y la otra con (1,N), la implementación puede requerir consideraciones especiales, aunque generalmente se resuelve como una relación 1:N con opcionalidad.

Normalización de Bases de Datos

La normalización es un proceso fundamental en el diseño de bases de datos relacionales que busca eliminar la redundancia de datos y mejorar la eficiencia del almacenamiento y la integridad de los datos.

El proceso de diseño de una base de datos relacional típicamente sigue estos pasos: Modelo E/R → Mapeo a Tablas Relacionales → Normalización (que puede resultar en la creación de nuevas tablas o la reestructuración de las existentes).

Descomposición sin Pérdida de Información

Una descomposición sin pérdida de información de una relación A en relaciones B y C implica que la unión natural de B y C (B ⋈ C) debe ser igual a la relación original A. Para lograr esto, es crucial que las claves primarias o candidatas se mantengan en las tablas resultantes para permitir la reconstrucción de la información.

Formas Normales (FN)

Las Formas Normales (FN) son un conjunto de reglas que definen las condiciones para un diseño de tabla relacional óptimo, minimizando la redundancia y mejorando la integridad de los datos.

Primera Forma Normal (1FN)
Una relación está en 1FN si todos sus atributos son atómicos, es decir, no contienen valores multivaluados ni grupos repetitivos. Si un atributo es multivaluado, se puede:
- Crear múltiples columnas si el número de valores es fijo y conocido.
- Crear una nueva tabla para el atributo multivaluado, con la clave primaria de la tabla original como clave foránea, y cada valor en una tupla separada.
Segunda Forma Normal (2FN)
Una relación está en 2FN si está en 1FN y todos los atributos no clave dependen funcionalmente de toda la clave primaria. Si un atributo no clave depende solo de una parte de la clave primaria compuesta, se debe mover a una nueva tabla junto con la parte de la clave de la que depende.
Tercera Forma Normal (3FN)
Una relación está en 3FN si está en 2FN y no existen dependencias funcionales transitivas. Una dependencia transitiva ocurre cuando un atributo no clave depende de otro atributo no clave, que a su vez depende de la clave primaria. Para normalizar, se crea una nueva tabla para la dependencia transitiva.
Forma Normal de Boyce-Codd (FNBC)
Una relación está en FNBC si, para cada dependencia funcional no trivial X → Y, X es una superclave (o clave candidata). Es una forma más estricta que la 3FN.

Dependencias Funcionales

Una dependencia funcional (DF), denotada como X → Y, en una relación R, significa que para cualquier par de tuplas en R, si los valores de los atributos en X son iguales, entonces los valores de los atributos en Y también deben ser iguales. En otras palabras, X determina funcionalmente a Y.

Dependencia Funcional Completa: Un atributo Y tiene una dependencia funcional completa de un conjunto de atributos X si Y depende de X, pero no de ningún subconjunto propio de X. Por ejemplo, si XY → Z, pero X ↛ Z y Y ↛ Z.
Dependencia Funcional Transitiva: Ocurre cuando un atributo no clave depende de otro atributo no clave, que a su vez depende de la clave primaria. Formalmente, X → Y y Y → Z, donde Y no es una superclave y Y ↛ X.

Cierre de un Conjunto de Dependencias Funcionales (F⁺)

A partir de un conjunto de dependencias funcionales, se pueden inferir otras dependencias. El cierre de un conjunto de dependencias funcionales (F⁺) es el conjunto de todas las dependencias funcionales que pueden ser lógicamente inferidas a partir de F.

Axiomas de Armstrong

Los Axiomas de Armstrong son un conjunto de reglas de inferencia que permiten derivar todas las dependencias funcionales lógicamente implicadas por un conjunto dado de dependencias:

Reflexividad: Si Y ⊆ X, entonces X → Y.
Aumento: Si X → Y, entonces XZ → YZ.
Transitividad: Si X → Y y Y → Z, entonces X → Z.
Unión: Si X → Y y X → Z, entonces X → YZ.
Descomposición: Si X → YZ, entonces X → Y y X → Z.
Pseudotransitividad: Si X → Y y ZY → W, entonces XZ → W.

Identificación de Claves Candidatas

Para identificar claves candidatas en un conjunto de atributos y dependencias funcionales, se pueden seguir estas pautas:

Si un atributo aparece solo en el lado derecho de las DFs, no puede ser parte de una clave candidata.
Si un atributo aparece solo en el lado izquierdo de las DFs, debe ser parte de una clave candidata.
Si un atributo no aparece en ninguna DF (es decir, no está ni a la izquierda ni a la derecha de ninguna dependencia), también debe ser parte de una clave candidata.