Simulador EGEL Informática

🗄️ Bases de datos

Bases de datos: diseño y consulta

El modelo relacional, propuesto por Edgar F. Codd en 1970, representa los datos como relaciones (tablas) fundamentadas en la teoría de conjuntos y la lógica de predicados. Cada tabla se compone de registros (tuplas) y campos (atributos). La clave primaria (PRIMARY KEY) identifica de forma única cada tupla y combina las restricciones UNIQUE y NOT NULL; por la regla de integridad de entidad, ningún atributo de la clave primaria admite valores NULL. La clave foránea (FOREIGN KEY) impone la integridad referencial: su valor debe coincidir con una clave referenciada existente o bien ser NULL.

El modelo entidad-relación (E-R), propuesto por Peter Chen en 1976, describe el diseño conceptual mediante entidades, atributos y relaciones. La cardinalidad entre dos entidades puede ser uno a uno (1:1), uno a muchos (1:N) o muchos a muchos (N:M). Al pasar al diseño lógico y físico, una relación N:M se implementa creando una tabla intermedia cuya clave primaria suele formarse con las claves foráneas de las entidades participantes.

La normalización (Codd, 1972-1974) reduce redundancias mediante formas normales sucesivas:

SQL se divide en DDL (Data Definition Language: CREATE, ALTER, DROP y TRUNCATE), que define y modifica la estructura de los objetos, y DML (SELECT, INSERT, UPDATE, DELETE), que consulta y modifica los datos. En una consulta con agrupamiento, WHERE filtra filas antes de agrupar, GROUP BY forma los grupos y HAVING filtra los grupos ya formados; las funciones de agregación son COUNT, SUM, AVG, MIN y MAX. Un INNER JOIN devuelve solo las filas con coincidencia en ambas tablas, mientras que un OUTER JOIN (LEFT, RIGHT o FULL) conserva las filas sin coincidencia completando con NULL. NULL representa un valor ausente o desconocido y se rige por una lógica de tres valores (TRUE, FALSE, UNKNOWN), por lo que se prueba con IS NULL y no con el operador =.

El álgebra relacional aporta el fundamento conceptual de las consultas. Finalmente, un SGBD garantiza la fiabilidad de las transacciones con las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) y ofrece mecanismos de respaldo y recuperación para restaurar la base de datos ante fallos.

Practica el banco completo y haz simulacros gratis

Preguntas de muestra (35)

1. En el modelo relacional de bases de datos, ¿cómo se denomina el conjunto de valores que corresponde a una fila completa de una tabla?

  1. Campo o atributo
  2. Índice de búsqueda
  3. Registro o tupla
  4. Vista relacional

En el modelo relacional cada fila de una tabla (relación) es un registro o tupla que representa una instancia de la entidad; las columnas son los campos o atributos. (Codd, E. F., 'A Relational Model of Data for Large Shared Data Banks', Communications of the ACM, Vol. 13, No. 6 (1970))

2. ¿Qué autor propuso en 1970 el modelo relacional de bases de datos, fundamentado en la teoría de conjuntos y la lógica de predicados?

  1. Edgar F. Codd
  2. Peter P. Chen
  3. Charles W. Bachman
  4. Michael Stonebraker

Codd publicó en 1970 el artículo fundacional del modelo relacional; Chen propuso el modelo entidad-relación en 1976 y Bachman es reconocido por el modelo de red, no por el relacional. (Codd, E. F., Communications of the ACM, Vol. 13, No. 6 (1970))

3. En SQL, la restricción PRIMARY KEY aplicada a una columna combina automáticamente ¿cuáles dos restricciones de integridad?

  1. UNIQUE y CHECK
  2. UNIQUE y NOT NULL
  3. NOT NULL y DEFAULT
  4. FOREIGN KEY y CHECK

La clave primaria garantiza unicidad (UNIQUE) y ausencia de valores nulos (NOT NULL) para identificar de forma única cada tupla, conforme a la norma SQL. (Norma ISO/IEC 9075 (SQL); Elmasri & Navathe, Fundamentals of Database Systems)

4. De acuerdo con la regla de integridad de entidad del modelo relacional, ¿qué tipo de valores no puede contener ningún atributo que forme parte de la clave primaria de una tabla?

  1. Valores duplicados
  2. Valores negativos
  3. Valores de texto vacío
  4. Valores nulos (NULL)

La regla de integridad de entidad prohíbe que un atributo de la clave primaria contenga valores nulos (NULL), pues impediría identificar de forma única cada tupla; la ausencia de duplicados deriva de la propiedad de unicidad de la llave, no de esta regla. (Codd, E. F., reglas de integridad del modelo relacional; Norma ISO/IEC 9075 (SQL))

5. Según la regla de integridad referencial del modelo relacional, el valor de una clave foránea en una tabla debe cumplir ¿qué condición?

  1. Ser distinto de los valores de la clave referenciada
  2. Coincidir con la clave primaria de su propia tabla
  3. Coincidir con un valor existente de la clave referenciada, o ser NULL
  4. Tomar únicamente valores numéricos consecutivos

La integridad referencial exige que la clave foránea coincida con un valor existente de la clave primaria o única referenciada, o bien sea nula; de lo contrario se rompe la relación entre tablas. (Norma ISO/IEC 9075 (restricción FOREIGN KEY/REFERENCES); Codd, reglas de integridad)

6. Un analista modela un sistema escolar donde un ALUMNO puede inscribirse en varios CURSOS y un CURSO puede tener varios ALUMNOS inscritos (cardinalidad muchos a muchos). Al pasar este modelo E-R al modelo relacional, ¿qué debe hacer para representar correctamente esta relación?

  1. Crear una tabla intermedia con las claves foráneas de ALUMNO y CURSO
  2. Agregar una columna multivaluada en la tabla ALUMNO que liste los cursos
  3. Fusionar las tablas ALUMNO y CURSO en una sola tabla
  4. Duplicar la tabla CURSO dentro de la tabla ALUMNO

Una relación N:M se implementa mediante una tabla de asociación cuya clave primaria suele estar formada por las claves foráneas de las entidades participantes, evitando atributos multivaluados que violarían la 1FN. (Elmasri & Navathe, Fundamentals of Database Systems; Silberschatz et al., Database System Concepts)

7. En el modelo entidad-relación propuesto por Peter Chen en 1976, ¿qué tipos de cardinalidad puede tener una relación entre dos entidades?

  1. Uno a uno, uno a muchos y muchos a uno solamente
  2. Uno a uno, uno a muchos y muchos a muchos
  3. Únicamente relaciones de tipo muchos a muchos
  4. Uno a uno y muchos a muchos, pero no uno a muchos

Chen definió tres tipos de cardinalidad para las relaciones del modelo E-R: uno a uno (1:1), uno a muchos (1:N) y muchos a muchos (N:M). (Chen, P. P., 'The Entity-Relationship Model', ACM Transactions on Database Systems, Vol. 1, No. 1 (1976))

8. En un modelo E-R, la relación INSCRIPCION entre ALUMNO y CURSO es de tipo muchos a muchos y además tiene un atributo propio 'calificación' que depende tanto del alumno como del curso. Al construir la tabla intermedia INSCRIPCION en el modelo relacional, ¿cuál es la clave primaria más adecuada?

  1. Solo la clave foránea que referencia a la tabla ALUMNO
  2. Solo la clave foránea que referencia a la tabla CURSO
  3. Un atributo nuevo sin relación con ALUMNO ni CURSO
  4. La combinación de las claves foráneas de ALUMNO y CURSO

Cuando la relación N:M tiene un atributo propio como 'calificación', la clave primaria natural de la tabla intermedia es la combinación de las claves foráneas de ambas entidades, pues juntas identifican de manera única cada inscripción. (Elmasri & Navathe, Fundamentals of Database Systems)

9. En una tabla EMPLEADO existen dos atributos que, cada uno por separado, identifican de forma única cada fila: 'numero_empleado' y 'CURP'. Si se elige 'numero_empleado' como clave primaria, ¿cómo se denomina 'CURP' dentro del modelo relacional?

  1. Clave foránea
  2. Clave compuesta
  3. Clave candidata
  4. Atributo no primo

Un atributo que puede identificar de forma única cada tupla pero no fue elegido como clave primaria se denomina clave candidata; CURP cumple esta condición frente a numero_empleado, por lo que es atributo primo y no un atributo no primo. (Codd, E. F.; Elmasri & Navathe, Fundamentals of Database Systems)

10. ¿Qué condición debe cumplir una relación para estar en Primera Forma Normal (1FN)?

  1. Que todos los atributos tengan valores atómicos, sin grupos repetitivos
  2. Que no existan dependencias parciales respecto a la clave
  3. Que no existan dependencias transitivas entre atributos no clave
  4. Que todo determinante funcional sea una clave candidata

La 1FN exige que cada atributo tenga un valor atómico y no existan grupos repetitivos; las demás opciones describen requisitos de 2FN, 3FN y BCNF respectivamente. (Codd, E. F., 'Further Normalization of the Data Base Relational Model' (1972))

11. Una tabla DETALLE_PEDIDO tiene como clave primaria compuesta (id_pedido, id_producto); el atributo 'cantidad' depende de ambos campos de la clave, pero el atributo 'nombre_producto' depende únicamente de 'id_producto'. ¿Qué forma normal viola esta tabla?

  1. Primera Forma Normal, por valores no atómicos
  2. Segunda Forma Normal, por una dependencia parcial
  3. Tercera Forma Normal, por una dependencia transitiva
  4. Forma Normal de Boyce-Codd, por un determinante que no es superclave

'nombre_producto' depende solo de una parte de la clave compuesta (id_producto), lo cual es una dependencia parcial que viola la 2FN. (Codd, E. F. (1972); Elmasri & Navathe, Fundamentals of Database Systems)

12. En una tabla EMPLEADO con clave primaria 'id_empleado', el atributo 'id_departamento' depende de la clave, y el atributo 'nombre_departamento' depende de 'id_departamento' y no directamente de la clave primaria. ¿Qué forma normal viola esta situación?

  1. Segunda Forma Normal, por una dependencia parcial
  2. Primera Forma Normal, por un grupo repetitivo
  3. Forma Normal de Boyce-Codd, por dos claves candidatas superpuestas
  4. Tercera Forma Normal, por una dependencia transitiva

'nombre_departamento' depende transitivamente de 'id_empleado' a través de 'id_departamento', lo que constituye una dependencia transitiva entre atributos no clave y viola la 3FN. (Codd, E. F. (1972); Silberschatz, Korth & Sudarshan, Database System Concepts)

13. Una tabla tiene los atributos (curso, profesor, aula) con las dependencias funcionales: (curso, profesor) determina a aula, y aula determina a profesor. Aunque la tabla está en 3FN, 'aula' es un determinante que no es clave candidata. ¿Qué forma normal no cumple esta tabla?

  1. Primera Forma Normal
  2. Segunda Forma Normal
  3. Forma Normal de Boyce-Codd
  4. Tercera Forma Normal

La BCNF exige que todo determinante sea superclave; como 'aula' determina a 'profesor' sin ser clave candidata, la tabla viola la BCNF aunque cumpla la 3FN, ya que 'profesor' es atributo primo. (Codd, E. F., IBM Research Report RJ1385 (1974); Elmasri & Navathe, Fundamentals of Database Systems)

14. La tabla DETALLE_PEDIDO (id_pedido, id_producto, cantidad, nombre_producto, precio_unitario) tiene clave primaria compuesta (id_pedido, id_producto). Los atributos 'nombre_producto' y 'precio_unitario' dependen solo de 'id_producto'. ¿Qué acción de normalización corrige la dependencia parcial y lleva la tabla a 2FN?

  1. Mover 'nombre_producto' y 'precio_unitario' a una tabla PRODUCTO
  2. Eliminar el atributo 'cantidad' de la tabla DETALLE_PEDIDO
  3. Agregar una nueva clave primaria simple autonumérica a la tabla
  4. Combinar todos los atributos en una sola clave candidata única

Para eliminar la dependencia parcial se extraen los atributos que dependen solo de una parte de la clave ('id_producto') hacia una tabla separada, quedando 'cantidad' en DETALLE_PEDIDO por depender de la clave completa. (Codd, E. F. (1972); Elmasri & Navathe, Fundamentals of Database Systems)

15. En la tabla EMPLEADO (id_empleado, nombre, id_departamento, nombre_departamento), el atributo 'nombre_departamento' depende transitivamente de 'id_empleado' a través de 'id_departamento'. ¿Qué acción de normalización lleva esta tabla a Tercera Forma Normal?

  1. Eliminar por completo el atributo 'nombre' de la tabla EMPLEADO
  2. Separar 'id_departamento' y 'nombre_departamento' en tabla DEPARTAMENTO
  3. Unir 'id_departamento' y 'nombre_departamento' en una sola clave compuesta
  4. Convertir el atributo 'nombre_departamento' en la nueva clave primaria

Se elimina la dependencia transitiva creando una tabla DEPARTAMENTO con 'id_departamento' como clave primaria y 'nombre_departamento' como atributo, dejando en EMPLEADO solo la referencia mediante clave foránea. (Codd, E. F. (1972); Silberschatz, Korth & Sudarshan, Database System Concepts)

16. ¿Cuál es el objetivo principal del proceso de normalización de bases de datos relacionales?

  1. Aumentar la velocidad de las consultas mediante índices adicionales
  2. Incrementar el número de tablas para facilitar los respaldos
  3. Eliminar por completo el uso de índices y claves foráneas
  4. Reducir la redundancia de datos y las anomalías de actualización

La normalización busca organizar los atributos en relaciones para minimizar la redundancia y prevenir anomalías de inserción, actualización y eliminación. (Codd, E. F., 'Further Normalization of the Data Base Relational Model' (1972))

17. ¿Cuál es la diferencia esencial entre la Tercera Forma Normal (3FN) y la Forma Normal de Boyce-Codd (BCNF)?

  1. La 3FN prohíbe valores nulos y la BCNF los permite
  2. La BCNF solo se aplica a tablas sin clave primaria definida
  3. La BCNF exige que todo determinante sea una clave candidata
  4. La 3FN exige atomicidad de los atributos y la BCNF no la exige

La BCNF es una versión más estricta de la 3FN: exige que todo determinante de una dependencia funcional no trivial sea superclave, mientras la 3FN permite dependencias hacia atributos primos. (Codd, E. F., IBM Research Report RJ1385 (1974); Elmasri & Navathe, Fundamentals of Database Systems)

18. ¿Cuál de las siguientes condiciones NO es necesaria para que una relación esté en Segunda Forma Normal (2FN)?

  1. Que todo determinante sea clave candidata
  2. Que la relación esté en Primera Forma Normal
  3. Que no existan dependencias parciales en la clave compuesta
  4. Que los atributos no primos dependan de la clave completa

Exigir que todo determinante sea clave candidata corresponde a la BCNF, no a la 2FN; la 2FN solo requiere partir de 1FN y no tener dependencias parciales respecto a una clave compuesta. (Codd, E. F. (1972); Elmasri & Navathe, Fundamentals of Database Systems)

19. ¿Qué significan las siglas ACID que describen las propiedades deseables de una transacción en una base de datos?

  1. Atomicidad, Concurrencia, Integridad y Disponibilidad
  2. Atomicidad, Consistencia, Aislamiento y Durabilidad
  3. Autenticación, Consistencia, Indexación y Disponibilidad
  4. Atomicidad, Consistencia, Integridad y Distribución

ACID es el acrónimo de Atomicity, Consistency, Isolation y Durability, propiedades que garantizan la fiabilidad de las transacciones. (Härder, T. & Reuter, A., 'Principles of Transaction-Oriented Database Recovery', ACM Computing Surveys, Vol. 15, No. 4 (1983))

20. La propiedad de Atomicidad de una transacción en una base de datos establece que:

  1. Los datos permanecen almacenados aun después de una falla del sistema
  2. Dos transacciones concurrentes no pueden ver resultados intermedios una de la otra
  3. La base de datos pasa de un estado válido a otro estado válido
  4. Todas las operaciones de la transacción se ejecutan por completo, o ninguna se aplica

La atomicidad garantiza que una transacción se comporta como una unidad indivisible: se ejecuta completamente o se revierte por completo mediante ROLLBACK. (Härder & Reuter (1983); Silberschatz, Korth & Sudarshan, Database System Concepts)

21. La propiedad de Aislamiento (Isolation) en una transacción de base de datos garantiza que:

  1. Los cambios confirmados se conservan aunque falle el servidor
  2. La transacción puede modificar varias tablas de manera simultánea y libre
  3. Los efectos parciales de una transacción no son visibles para otras hasta que concluye
  4. El resultado final de la base de datos cumple todas las restricciones de integridad

El aislamiento evita que transacciones concurrentes interfieran entre sí, ocultando los estados intermedios hasta que cada una finaliza con COMMIT. (Härder & Reuter (1983); Berenson et al., 'A Critique of ANSI SQL Isolation Levels' (1995))

22. La propiedad de Durabilidad de una transacción establece que, una vez confirmada (COMMIT) una transacción:

  1. Sus efectos permanecen en la base de datos aunque el sistema falle después
  2. Puede deshacerse automáticamente si otra transacción lo solicita
  3. Sus resultados intermedios quedan visibles para el resto de los usuarios
  4. La base de datos deja de aceptar nuevas transacciones durante un tiempo

La durabilidad garantiza que los cambios de una transacción confirmada sobreviven a fallas posteriores del sistema, típicamente mediante bitácoras de recuperación. (Härder & Reuter (1983); Silberschatz, Korth & Sudarshan, Database System Concepts)

23. En una transacción bancaria se descuenta dinero de la cuenta A mediante un UPDATE, pero antes de ejecutar el UPDATE que abona ese monto a la cuenta B, el sistema sufre una falla eléctrica y la transacción no llega a confirmarse (COMMIT). Al reiniciar, el sistema revierte el descuento en la cuenta A. ¿Qué propiedad ACID se está preservando con esta acción de recuperación?

  1. Aislamiento
  2. Atomicidad
  3. Consistencia
  4. Durabilidad

Al revertir el descuento cuando la transacción no se completó, el sistema aplica la atomicidad: la transacción se ejecuta por completo o no deja ningún efecto. (Härder & Reuter (1983); Silberschatz, Korth & Sudarshan, Database System Concepts)

24. Dentro de una transacción SQL, si tras varias instrucciones DML el usuario ejecuta la instrucción ROLLBACK, ¿qué ocurre con los cambios realizados desde el inicio de la transacción?

  1. Se confirman de manera permanente todos los cambios realizados
  2. Solo se deshace la última instrucción DML ejecutada por el usuario
  3. Se bloquean las tablas afectadas hasta que otro usuario confirme
  4. Se deshacen todos los cambios y la base de datos regresa a su estado anterior

ROLLBACK deshace todas las operaciones realizadas desde el inicio de la transacción, dejando la base de datos en su estado previo, en contraste con COMMIT que las hace permanentes. (Norma ISO/IEC 9075 (SQL); Silberschatz, Korth & Sudarshan, Database System Concepts)

25. El estándar SQL define varios niveles de aislamiento para las transacciones. ¿Cuál de los siguientes es el nivel de aislamiento MÁS estricto, en el que se evitan por completo las lecturas sucias, las lecturas no repetibles y los fenómenos fantasma?

  1. READ COMMITTED
  2. READ UNCOMMITTED
  3. SERIALIZABLE
  4. REPEATABLE READ

SERIALIZABLE es el nivel más estricto del estándar SQL: garantiza que la ejecución concurrente de transacciones produzca el mismo resultado que alguna ejecución serial, evitando lecturas sucias, no repetibles y fantasma. (Norma ISO/IEC 9075 (SQL); Berenson et al., 'A Critique of ANSI SQL Isolation Levels' (1995))

26. La Transacción 1 actualiza el saldo de una cuenta pero aún no ejecuta COMMIT. En ese momento, la Transacción 2 lee ese saldo modificado y toma una decisión con base en él; después, la Transacción 1 ejecuta ROLLBACK. ¿Qué fenómeno de concurrencia ocurrió durante la lectura de la Transacción 2?

  1. Fenómeno de lectura sucia
  2. Fenómeno de lectura irrepetible
  3. Fenómeno de lectura fantasma
  4. Fenómeno de bloqueo mutuo

Una lectura sucia ocurre cuando una transacción lee datos modificados por otra transacción que aún no ha confirmado (COMMIT) y que posteriormente puede deshacerse con ROLLBACK, como en este caso. (Berenson et al., 'A Critique of ANSI SQL Isolation Levels' (1995); Silberschatz, Korth & Sudarshan, Database System Concepts)

27. ¿Quién propuso en 1976 el modelo entidad-relación (E-R), en el cual las entidades, los atributos y las relaciones se representan mediante rombos como parte del diseño conceptual de bases de datos?

  1. Edgar F. Codd
  2. Peter Chen
  3. Charles Bachman
  4. James Martin

Peter Chen presentó el modelo entidad-relación en 1976 como herramienta de diseño conceptual; Codd propuso el modelo relacional (no el E-R) y Bachman el modelo en red. (Chen, P. P., 'The Entity-Relationship Model — Toward a Unified View of Data', ACM Transactions on Database Systems, Vol. 1, No. 1 (1976))

28. El modelo relacional de datos, que representa la información mediante relaciones (tablas) fundamentadas en la teoría de conjuntos y la lógica de predicados, fue propuesto en 1970 por...

  1. Peter Chen
  2. Charles Bachman
  3. Edgar F. Codd
  4. Michael Stonebraker

Edgar F. Codd introdujo el modelo relacional en 1970 en Communications of the ACM; Chen propuso después el modelo E-R (1976) como herramienta de diseño conceptual. (Codd, E. F., 'A Relational Model of Data for Large Shared Data Banks', Communications of the ACM, Vol. 13, No. 6 (1970))

29. En el modelo entidad-relación, la cardinalidad de una relación entre dos entidades se clasifica en tres tipos posibles, que son:

  1. Uno a uno, muchos a uno y participación total
  2. Obligatoria, opcional y multivaluada
  3. Entidad fuerte, entidad débil y entidad asociativa
  4. Uno a uno, uno a muchos y muchos a muchos

Las cardinalidades del modelo E-R son 1:1, 1:N y N:M; 'participación total/parcial' describe la obligatoriedad de la relación y 'entidad fuerte/débil' clasifica tipos de entidades, no cardinalidades. (Chen, P. P. (1976); Elmasri & Navathe, Fundamentals of Database Systems)

30. En un sistema escolar se describe lo siguiente: cada alumno puede inscribirse en varias materias a lo largo del semestre, y cada materia puede tener inscritos a varios alumnos distintos. Al traducir esta relación del modelo E-R al modelo relacional, ¿cómo debe representarse?

  1. Se agrega la llave primaria de Materia como llave foránea dentro de la tabla Alumno
  2. Se crea una tabla adicional cuya llave primaria está formada por las llaves foráneas de Alumno y de Materia
  3. Se agrega la llave primaria de Alumno como llave foránea dentro de la tabla Materia
  4. Se combinan Alumno y Materia en una sola tabla con todos sus atributos

Una relación N:M se implementa mediante una tabla intermedia cuya llave primaria suele integrar las llaves foráneas de las entidades participantes; colocar la llave foránea en una sola tabla solo funciona para relaciones 1:N. (Elmasri & Navathe, Fundamentals of Database Systems; Silberschatz et al., Database System Concepts)

31. La regla de integridad de entidad, aplicable a toda relación del modelo relacional, establece que...

  1. toda llave foránea debe tener siempre un valor distinto de nulo
  2. todo atributo de la tabla debe tener asignado un valor por defecto
  3. ningún atributo que forme parte de la llave primaria puede tener un valor nulo
  4. ninguna tabla puede tener más de una llave candidata definida

La integridad de entidad exige que ningún componente de la llave primaria sea nulo, para garantizar la identificación única de cada tupla; la regla sobre llaves foráneas corresponde a la integridad referencial, no a la de entidad. (Codd, E. F., reglas de integridad del modelo relacional; Norma ISO/IEC 9075 (restricción PRIMARY KEY))

32. En SQL, la restricción PRIMARY KEY aplicada a una columna equivale, en términos de las restricciones que impone, a la combinación de...

  1. UNIQUE y NOT NULL
  2. UNIQUE y CHECK
  3. NOT NULL y FOREIGN KEY
  4. UNIQUE y DEFAULT

PRIMARY KEY combina unicidad (UNIQUE) y obligatoriedad de valor (NOT NULL) para identificar de forma única cada fila; CHECK, FOREIGN KEY y DEFAULT son restricciones independientes que no forman parte de esa combinación. (Norma ISO/IEC 9075 (SQL); Elmasri & Navathe, Fundamentals of Database Systems)

33. De acuerdo con la regla de integridad referencial del modelo relacional, el valor almacenado en una columna definida como llave foránea debe...

  1. ser siempre diferente de cualquier valor de la llave primaria referenciada
  2. coincidir obligatoriamente con un valor de la llave referenciada, sin admitir valores nulos en ningún caso
  3. heredar de forma automática el valor por defecto definido en la llave primaria
  4. coincidir con un valor existente de la llave referenciada, o bien ser nulo

La integridad referencial permite que la llave foránea sea nula (relación opcional) o coincida con un valor existente de la llave referenciada; el error común es creer que la llave foránea nunca puede ser nula. (Norma ISO/IEC 9075 (restricción FOREIGN KEY / REFERENCES); Codd, reglas de integridad)

34. Una tabla Pedido tiene los atributos NumPedido, ProductoID, NombreProducto y Cantidad, con llave primaria compuesta por NumPedido y ProductoID. NombreProducto depende únicamente de ProductoID y no de la llave compuesta completa. Sabiendo que la relación ya cumple la Primera Forma Normal, ¿cuál es la forma normal de menor nivel que deja de cumplirse?

  1. La Primera Forma Normal, porque el atributo NombreProducto no contiene un valor atómico
  2. La Tercera Forma Normal, porque existe una dependencia transitiva entre atributos no clave
  3. La Segunda Forma Normal, porque existe una dependencia parcial respecto a la llave compuesta
  4. La Forma Normal de Boyce-Codd, porque el determinante no es una llave candidata

Un atributo no primo que depende solo de una parte de la llave compuesta (dependencia parcial) hace que la relación deje de cumplir la Segunda Forma Normal, que es la de menor nivel violada; aunque la FNBC también se incumple no es la de menor nivel, no hay dependencia transitiva entre atributos no clave (3FN) y los valores sí son atómicos (1FN). (Codd, E. F., 'Further Normalization of the Data Base Relational Model' (1972); Elmasri & Navathe)

35. Una relación cumple con la Primera Forma Normal (1FN) cuando...

  1. todos sus atributos no primos dependen completamente de la llave primaria
  2. todos sus atributos contienen valores atómicos, sin grupos repetitivos ni atributos multivaluados
  3. no existen dependencias transitivas entre atributos que no forman parte de la llave
  4. todo determinante funcional de la relación es una llave candidata

La 1FN exige atomicidad en los valores de los atributos; las otras opciones describen, respectivamente, la 2FN (sin dependencias parciales), la 3FN (sin dependencias transitivas) y la FNBC (todo determinante es llave candidata). (Codd, E. F., 'Further Normalization of the Data Base Relational Model' (1972); C. J. Date, An Introduction to Database Systems)

Comienza gratis