🗄️ Bases de datos y SQL

1. ¿Qué autor propuso el modelo relacional de datos en el artículo "A Relational Model of Data for Large Shared Data Banks", publicado en 1970 en Communications of the ACM?

1. Peter Chen
2. C. J. Date
3. E. F. Codd
4. Michael Stonebraker

E. F. Codd propuso el modelo relacional en ese artículo de 1970, base teórica de las bases de datos relacionales y de SQL. Peter Chen, C. J. Date y Michael Stonebraker son otros autores relevantes en bases de datos, pero no los del artículo citado. (E. F. Codd, "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM, vol. 13, núm. 6, 1970.)

2. ¿Qué autor introdujo el modelo entidad-relación (E-R) para describir entidades, atributos y relaciones, en un artículo publicado en 1976 en ACM Transactions on Database Systems?

1. C. J. Date
2. E. F. Codd
3. Peter Chen
4. Michael Stonebraker

Peter Chen propuso el modelo E-R en 1976 como herramienta de modelado conceptual. E. F. Codd es el autor del modelo relacional (1970), no del modelo E-R. (Peter P. Chen, "The Entity-Relationship Model — Toward a Unified View of Data", ACM Transactions on Database Systems (TODS), vol. 1, núm. 1, 1976.)

3. En una tabla EMPLEADO cuya clave primaria es el atributo numero_empleado, un programador intenta insertar un registro sin especificar valor para numero_empleado, de modo que ese atributo quede en NULL. Conforme a la regla de integridad de entidad, ¿qué debe ocurrir con esa operación?

1. Se acepta, porque NULL representa un valor aún no determinado
2. Se rechaza, porque un atributo de la clave primaria no puede tener valor nulo
3. Se acepta, porque solo las claves foráneas prohíben valores nulos
4. Se rechaza, únicamente si la tabla tiene definida una clave foránea

La regla de integridad de entidad establece que ningún atributo de la clave primaria puede ser nulo, por lo que la inserción debe rechazarse; esta regla aplica siempre, no solo cuando existen claves foráneas. (E. F. Codd; Elmasri y Navathe, "Fundamentals of Database Systems", capítulo del modelo relacional.)

4. De acuerdo con la regla de integridad referencial del modelo relacional, ¿qué valores puede tomar válidamente una clave foránea?

1. Cualquier valor numérico distinto de cero
2. Un valor igual a una clave primaria existente en la tabla referenciada, o bien NULL
3. Solamente valores que ya existan en la misma tabla
4. Un valor igual a la clave primaria de la propia fila

La integridad referencial exige que la clave foránea coincida con un valor existente de la clave primaria referenciada o sea nula; no se limita a un tipo de dato ni a valores dentro de la misma tabla. (Elmasri y Navathe, "Fundamentals of Database Systems"; C. J. Date, "An Introduction to Database Systems".)

5. Una relación PEDIDO_DETALLE tiene clave primaria compuesta (numero_pedido, clave_producto) y un atributo nombre_producto que depende únicamente de clave_producto, sin depender del par completo de la clave. Considerando que sus valores son atómicos, ¿cuál es la forma normal de menor nivel (menos estricta) que esta relación deja de cumplir?

1. La primera forma normal (1FN), por un atributo multivaluado
2. La segunda forma normal (2FN), por una dependencia parcial
3. La tercera forma normal (3FN), por una dependencia transitiva
4. La forma normal de Boyce-Codd (FNBC), por un determinante que no es clave candidata

La relación cumple la 1FN (valores atómicos); la primera forma que deja de cumplir es la 2FN, pues un atributo no primo depende solo de una parte de la clave compuesta (dependencia parcial). No hay atributo multivaluado ni dependencia transitiva. (E. F. Codd; Elmasri y Navathe, "Fundamentals of Database Systems".)

6. En una relación EMPLEADO cuya clave primaria es numero_empleado, el atributo clave_departamento depende de numero_empleado, y el atributo nombre_departamento depende de clave_departamento (no depende directamente de numero_empleado). Considerando que sus valores son atómicos, ¿cuál es la forma normal de menor nivel (menos estricta) que esta relación deja de cumplir?

1. La forma normal de Boyce-Codd (FNBC)
2. La segunda forma normal (2FN)
3. La tercera forma normal (3FN)
4. La primera forma normal (1FN)

La relación cumple 1FN (valores atómicos) y 2FN (su clave primaria no es compuesta, por lo que no puede haber dependencias parciales); la primera forma que deja de cumplir es la 3FN, pues nombre_producto/nombre_departamento depende transitivamente de la clave a través de otro atributo no primo. (E. F. Codd; Elmasri y Navathe, "Fundamentals of Database Systems".)

7. Una relación cumple la tercera forma normal (3FN) porque toda dependencia funcional cuyo determinante no es clave candidata tiene como atributo determinado un atributo que forma parte de alguna clave candidata (atributo primo). ¿Qué forma normal NO cumple necesariamente esta relación?

1. La segunda forma normal (2FN), porque persistiría una dependencia parcial
2. La forma normal de Boyce-Codd (FNBC), porque exige que todo determinante sea clave candidata
3. La primera forma normal (1FN), porque persistirían atributos no atómicos
4. La tercera forma normal (3FN), porque persistiría una dependencia transitiva

La FNBC exige que todo determinante de una dependencia funcional sea clave candidata, sin excepción para atributos primos; la 3FN sí permite esa excepción, por lo que una relación puede estar en 3FN sin estar en FNBC. (R. F. Boyce y E. F. Codd; Silberschatz, Korth y Sudarshan, "Database System Concepts".)

8. Al transformar el modelo entidad-relación al modelo relacional, ¿cómo se representa una relación con cardinalidad muchos a muchos (M:N) entre dos entidades?

1. Se agrega la clave primaria de una entidad como clave foránea en la otra entidad
2. Se fusionan ambas entidades en una sola tabla con todos sus atributos
3. Se crea una tabla intermedia cuya clave primaria está formada por las claves foráneas de ambas entidades
4. Se agrega un atributo multivaluado en la entidad con mayor número de registros

Una relación M:N se representa mediante una tabla intermedia cuya clave primaria combina las claves foráneas de las entidades participantes; agregar una clave foránea directa solo es válido para relaciones 1:N. (Elmasri y Navathe, "Fundamentals of Database Systems", algoritmo de mapeo E-R a relacional.)

9. ¿Cuál de las siguientes listas corresponde únicamente a instrucciones del lenguaje de definición de datos (DDL) en SQL?

1. SELECT, INSERT, UPDATE, DELETE
2. CREATE, SELECT, INSERT, DROP
3. CREATE, ALTER, DROP, TRUNCATE
4. GRANT, SELECT, ALTER, DELETE

CREATE, ALTER, DROP y TRUNCATE son las instrucciones que crean y modifican estructuras (DDL); SELECT, INSERT, UPDATE y DELETE pertenecen al DML. (ISO/IEC 9075 (estándar SQL), parte de definición de datos.)

10. Un estudiante afirma que las instrucciones DELETE y TRUNCATE pertenecen ambas al lenguaje de manipulación de datos (DML), porque las dos eliminan filas de una tabla. ¿Por qué esta clasificación es incorrecta?

1. Porque DELETE pertenece al DDL, mientras que TRUNCATE pertenece al DML
2. Porque ambas instrucciones pertenecen al lenguaje de control de datos (DCL)
3. Porque TRUNCATE no elimina filas, sino que elimina la estructura completa de la tabla
4. Porque TRUNCATE pertenece al lenguaje de definición de datos (DDL), mientras que DELETE pertenece al DML

Aunque ambas eliminan datos, TRUNCATE se clasifica como DDL y DELETE como DML; TRUNCATE elimina las filas conservando la estructura de la tabla, por lo que la tercera opción también es falsa. (ISO/IEC 9075 (estándar SQL), partes de definición y manipulación de datos.)

11. En el procesamiento lógico de una sentencia SELECT con GROUP BY, ¿cuál es la diferencia entre las cláusulas WHERE y HAVING?

1. WHERE filtra grupos después de agrupar, mientras que HAVING filtra filas individuales antes de agrupar
2. WHERE filtra filas individuales antes de agrupar, mientras que HAVING filtra grupos después de agrupar
3. Ambas cláusulas filtran filas individuales, pero HAVING se ejecuta antes que WHERE
4. WHERE solo admite funciones de agregación, mientras que HAVING no las admite

WHERE actúa sobre filas individuales antes de la agrupación, mientras que HAVING filtra los grupos ya formados por GROUP BY; la primera opción invierte esta relación. (ISO/IEC 9075 (procesamiento lógico de la sentencia SELECT).)

12. Se tienen las tablas CLIENTE(id_cliente, nombre, ciudad) y PEDIDO(id_pedido, id_cliente, monto). Se ejecuta: SELECT ciudad, COUNT(*) AS total FROM CLIENTE JOIN PEDIDO ON CLIENTE.id_cliente = PEDIDO.id_cliente GROUP BY ciudad HAVING COUNT(*) > 5; ¿Qué representa el resultado de esta consulta?

1. Los clientes con más de 5 pedidos registrados
2. Las ciudades con exactamente 5 pedidos registrados
3. Las ciudades con más de 5 pedidos registrados
4. Los pedidos cuyo monto es mayor a 5 unidades

La consulta agrupa por ciudad y HAVING COUNT(*) > 5 conserva solo los grupos (ciudades) con más de 5 filas de pedidos asociadas, no clientes individuales ni el monto. (ISO/IEC 9075 (estándar SQL), cláusulas GROUP BY y HAVING.)

13. En una tabla EMPLEADO donde la columna telefono admite valores nulos, ¿qué diferencia existe entre COUNT(*) y COUNT(telefono) al ejecutarse sobre esa tabla?

1. COUNT(*) excluye las filas con telefono nulo, mientras que COUNT(telefono) las incluye
2. COUNT(*) cuenta todas las filas, incluidas las que tienen telefono nulo, mientras que COUNT(telefono) excluye esas filas
3. Ambas expresiones producen siempre el mismo resultado, sin importar los valores nulos
4. COUNT(*) solo puede usarse junto con GROUP BY, mientras que COUNT(telefono) no lo requiere

COUNT(*) cuenta todas las filas del resultado, incluidas aquellas con valores nulos en telefono, mientras que COUNT(telefono) omite esas filas. (ISO/IEC 9075 (estándar SQL), funciones de agregación.)

14. La tabla CONTACTO tiene 12 filas en total; de ellas, 3 tienen valor nulo en la columna correo_electronico. Al ejecutar SELECT COUNT(*), COUNT(correo_electronico) FROM CONTACTO;, ¿qué par de resultados se obtiene?

1. 12 y 12
2. 9 y 12
3. 12 y 9
4. 9 y 3

COUNT(*) cuenta las 12 filas totales, mientras que COUNT(correo_electronico) excluye las 3 filas con valor nulo, dando 12 - 3 = 9. (ISO/IEC 9075 (estándar SQL), funciones de agregación.)

15. Un reporte debe incluir a todos los clientes registrados en la tabla CLIENTE, incluso a quienes no tienen ningún pedido en la tabla PEDIDO, mostrando NULL en las columnas de PEDIDO cuando no exista coincidencia. Colocando CLIENTE como tabla izquierda y PEDIDO como tabla derecha, ¿qué tipo de reunión (JOIN) satisface este requisito?

1. INNER JOIN
2. RIGHT OUTER JOIN
3. LEFT OUTER JOIN
4. CROSS JOIN

El LEFT OUTER JOIN conserva todas las filas de la tabla izquierda (CLIENTE) y rellena con NULL las columnas de la derecha cuando no hay coincidencia; INNER JOIN excluiría a los clientes sin pedidos y RIGHT OUTER JOIN preservaría las filas de PEDIDO. (ISO/IEC 9075 (estándar SQL), operaciones de reunión (joined tables).)

16. Se desea obtener los productos que nunca han sido incluidos en algún pedido mediante: SELECT nombre FROM PRODUCTO WHERE id_producto NOT IN (SELECT id_producto FROM DETALLE_PEDIDO); Si la columna id_producto de DETALLE_PEDIDO contiene al menos un valor NULL, ¿qué problema presenta esta consulta?

1. La consulta genera un error de sintaxis, porque NOT IN no admite subconsultas
2. El operador NOT IN puede devolver un resultado vacío para toda fila, debido a la lógica trivaluada al comparar con un NULL de la lista
3. El operador NOT IN ignora automáticamente los valores nulos y produce el resultado correcto
4. La subconsulta se ejecuta una vez por cada fila de PRODUCTO, lo cual siempre produce un error

Con lógica trivaluada, comparar un valor con un NULL de la lista de NOT IN produce 'desconocido', por lo que la condición nunca se evalúa como verdadera y el resultado queda vacío; NOT IN sí admite subconsultas y no ignora los nulos automáticamente. (ISO/IEC 9075 (estándar SQL), lógica trivaluada y predicado null.)

17. La tabla PEDIDO tiene 8 filas y la tabla DETALLE_PEDIDO tiene 20 filas; cada fila de DETALLE_PEDIDO hace referencia a exactamente un id_pedido existente en PEDIDO, y id_pedido es la clave primaria de PEDIDO. Al ejecutar un INNER JOIN entre PEDIDO y DETALLE_PEDIDO usando la igualdad sobre id_pedido, ¿cuántas filas contendrá el resultado?

1. 8
2. 28
3. 160
4. 20

Como id_pedido es clave primaria única en PEDIDO y cada una de las 20 filas de DETALLE_PEDIDO referencia un id_pedido existente, cada fila encuentra exactamente una coincidencia, por lo que el resultado tiene 20 filas; 28 surge de sumar en vez de emparejar y 160 de multiplicar como en un producto cartesiano. (ISO/IEC 9075 (estándar SQL), operaciones de reunión (joined tables).)

18. La tabla PEDIDO registra los montos 100, 250, 150 y 500 correspondientes a los 4 únicos pedidos de un mismo cliente. Al ejecutar SELECT SUM(monto), AVG(monto) FROM PEDIDO WHERE id_cliente = X;, ¿qué par de resultados se obtiene?

1. 1000 y 250
2. 1000 y 4
3. 250 y 1000
4. 1000 y 200

La suma de los 4 montos es 1000 y el promedio es 1000 entre 4, es decir 250; 1000 y 200 correspondería a dividir por error entre 5 pedidos, y 1000 y 4 confunde el promedio con el número de filas. (ISO/IEC 9075 (estándar SQL), funciones de agregación SUM y AVG.)

19. ¿Qué conjunto de propiedades garantiza que las transacciones en un sistema gestor de bases de datos (SGBD) se ejecuten de manera confiable, resumido en el acrónimo ACID?

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

ACID corresponde a Atomicidad, Consistencia, Aislamiento (Isolation) y Durabilidad; las demás opciones mezclan términos de seguridad informática que no forman parte del acrónimo. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de transacciones; ISO/IEC 9075 (SQL).)

20. ¿En qué consiste el protocolo de bloqueo de dos fases (2PL) para el control de concurrencia en transacciones?

1. Cada transacción adquiere y libera bloqueos de manera simultánea durante toda su ejecución
2. Cada transacción se divide en una fase de crecimiento, donde solo adquiere bloqueos, y una fase de decrecimiento, donde solo los libera
3. Cada transacción adquiere todos los bloqueos posibles al inicio y los libera solo al final de todo el sistema
4. Cada transacción libera un bloqueo inmediatamente después de adquirir el siguiente

El protocolo 2PL divide la ejecución de cada transacción en una fase de crecimiento (solo adquisición de bloqueos) seguida de una fase de decrecimiento (solo liberación), lo cual garantiza la serializabilidad de las transacciones concurrentes. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

21. Una transacción T, que sigue el protocolo de bloqueo de dos fases (2PL), libera su primer bloqueo. A partir de ese momento, ¿qué restricción aplica al resto de la ejecución de T?

1. T puede seguir adquiriendo y liberando bloqueos libremente hasta su confirmación (commit)
2. T debe adquirir de inmediato todos los bloqueos restantes que necesite antes de continuar
3. T ya no puede adquirir ningún bloqueo nuevo; solo puede liberar los que ya tiene
4. T entra en un estado de espera indefinida hasta que otra transacción libere sus bloqueos

Al liberar su primer bloqueo, T entra en la fase de decrecimiento, en la que el protocolo 2PL le prohíbe adquirir bloqueos nuevos; solo puede seguir liberando los que ya posee. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

22. A diferencia del protocolo básico de bloqueo de dos fases (2PL), el protocolo de bloqueo estricto de dos fases (strict 2PL) exige, adicionalmente, que:

1. Todos los bloqueos, tanto compartidos como exclusivos, se mantengan hasta que la transacción confirme o aborte
2. Todos los bloqueos exclusivos se mantengan hasta que la transacción confirme (commit) o aborte
3. Todos los bloqueos que la transacción necesitará se adquieran antes de iniciar su ejecución
4. Las transacciones se ejecuten estrictamente una a la vez, sin ninguna concurrencia

El strict 2PL exige que los bloqueos exclusivos se mantengan hasta el commit o abort para evitar lecturas de datos no confirmados; mantener también los compartidos hasta el final corresponde al 2PL riguroso, y adquirir todos los bloqueos antes de iniciar corresponde al 2PL conservador. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

23. La transacción T1 mantiene un bloqueo exclusivo sobre la fila A y solicita un bloqueo exclusivo sobre la fila B; al mismo tiempo, la transacción T2 mantiene un bloqueo exclusivo sobre la fila B y solicita un bloqueo exclusivo sobre la fila A. Ambas transacciones siguen el protocolo 2PL y ninguna libera sus bloqueos. ¿Qué situación describe este escenario?

1. Una violación de la propiedad de atomicidad, porque ninguna transacción puede confirmarse
2. Una ejecución en serie válida, porque ambas transacciones mantienen sus bloqueos correctamente
3. Un interbloqueo (deadlock), porque ambas transacciones esperan de manera circular una a la otra
4. Una violación de la regla de integridad referencial entre las filas A y B

La espera circular entre T1 y T2 constituye un interbloqueo; el protocolo 2PL garantiza la serializabilidad de las transacciones, pero no impide por sí mismo que ocurran interbloqueos. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

24. Un equipo de desarrollo afirma que, por seguir el protocolo de bloqueo de dos fases (2PL), su sistema de transacciones queda automáticamente libre de interbloqueos (deadlocks). ¿Por qué esta afirmación es incorrecta?

1. Porque 2PL solo se aplica a transacciones de solo lectura, donde no puede haber interbloqueos
2. Porque 2PL garantiza la serialización de las transacciones, pero no evita que ocurran interbloqueos
3. Porque 2PL elimina la necesidad de bloqueos exclusivos, evitando así cualquier espera circular
4. Porque 2PL garantiza la durabilidad de las transacciones, lo cual previene interbloqueos por definición

El protocolo 2PL asegura que los planes de ejecución concurrentes sean serializables, pero no impide la espera circular entre transacciones que produce interbloqueos, los cuales requieren mecanismos adicionales de detección o prevención. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

25. En el control de concurrencia basado en bloqueos, ¿qué combinación de bloqueos puede mantenerse simultáneamente sobre el mismo elemento de datos por dos transacciones distintas?

1. Un bloqueo compartido y uno exclusivo, otorgados a ambas transacciones al mismo tiempo
2. Dos bloqueos exclusivos (de escritura), otorgados a ambas transacciones al mismo tiempo
3. Un bloqueo exclusivo otorgado a ambas transacciones al mismo tiempo
4. Dos bloqueos compartidos (de lectura), otorgados a ambas transacciones al mismo tiempo

Dos bloqueos compartidos sobre el mismo elemento son compatibles porque ambas transacciones solo leen el dato; cualquier combinación que incluya un bloqueo exclusivo es incompatible con otro bloqueo simultáneo sobre el mismo elemento. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia (matriz de compatibilidad de bloqueos).)

26. Una variante del protocolo de bloqueo de dos fases exige que cada transacción adquiera todos los bloqueos que necesitará antes de comenzar a ejecutar cualquier operación, sin poder solicitar bloqueos adicionales después. ¿Cómo se conoce esta variante?

1. Bloqueo de dos fases estricto (strict 2PL)
2. Bloqueo de dos fases básico (basic 2PL)
3. Bloqueo de dos fases conservador (conservative 2PL)
4. Bloqueo de dos fases riguroso (rigorous 2PL)

El bloqueo de dos fases conservador (o estático) exige predeclarar y adquirir todos los bloqueos antes de iniciar la ejecución, lo cual evita el interbloqueo al eliminar la condición de retener y esperar; strict y rigorous 2PL se refieren al momento de liberación de los bloqueos, no de su adquisición inicial. (Silberschatz, Korth y Sudarshan, "Database System Concepts", capítulo de control de concurrencia.)

27. ¿Qué autor propuso en 1976 el modelo entidad-relación (E-R) como una forma de representar de manera conceptual las entidades, sus atributos y las relaciones entre ellas, con independencia de un sistema gestor de base de datos particular?

1. Peter Chen
2. E. F. Codd
3. Charles Bachman
4. Donald Chamberlin

Peter Chen publicó "The Entity-Relationship Model" en 1976 en ACM TODS; Codd había propuesto antes el modelo relacional (1970) y Bachman el modelo en red, por lo que no corresponden al modelo E-R. (Peter P. Chen, "The Entity-Relationship Model — Toward a Unified View of Data", ACM TODS, vol. 1, núm. 1, 1976.)

28. En el esquema relacional derivado de un diagrama entidad-relación, la regla de integridad de entidad impone una restricción específica sobre los atributos que forman la clave primaria de una tabla. ¿Cuál es esa restricción?

1. La clave primaria debe estar formada por al menos dos atributos combinados
2. Ningún atributo que forme parte de la clave primaria puede tomar valor nulo
3. Todo atributo de la clave primaria debe repetirse también como clave foránea en otra tabla
4. Los valores de la clave primaria pueden repetirse en dos filas distintas de la misma tabla

La regla de integridad de entidad establece que ningún atributo de la clave primaria puede ser nulo, ya que de lo contrario no podría identificarse de forma única cada fila. (E. F. Codd; Elmasri y Navathe, "Fundamentals of Database Systems", capítulo del modelo relacional.)

29. En una base de datos, la tabla Inscripcion tiene el atributo id_alumno como clave foránea que referencia a la clave primaria de la tabla Alumno. Un desarrollador intenta insertar en Inscripcion un nuevo registro con id_alumno = 350, valor que no existe en ningún registro de la tabla Alumno y que tampoco se dejó como nulo. De acuerdo con la regla de integridad referencial, ¿qué debe suceder?

1. El sistema gestor debe crear automáticamente un registro con id_alumno = 350 en la tabla Alumno
2. El sistema gestor debe aceptar la inserción y sustituir el valor 350 por NULL de forma automática
3. El sistema gestor debe rechazar la inserción, porque el valor de la clave foránea no coincide con ningún valor existente de la clave primaria referenciada
4. El sistema gestor debe aceptar la inserción sin restricción, ya que id_alumno es un valor numérico válido

La integridad referencial exige que la clave foránea coincida con un valor existente de la clave primaria referenciada o sea nula; como 350 no existe y no se dejó nula, la inserción debe rechazarse. (Elmasri y Navathe, "Fundamentals of Database Systems"; C. J. Date, "An Introduction to Database Systems".)

30. Un modelo entidad-relación describe que un Alumno puede inscribirse en muchas Materias y que una Materia puede tener inscritos a muchos Alumnos (cardinalidad muchos a muchos). Al transformar este modelo al esquema relacional, ¿cuál es el procedimiento correcto?

1. Agregar la clave primaria de Materia como clave foránea dentro de la tabla Alumno
2. Fusionar las tablas Alumno y Materia en una sola tabla con clave primaria compuesta
3. Agregar la clave primaria de Alumno como clave foránea dentro de la tabla Materia
4. Crear una tabla intermedia cuya clave primaria esté formada por las claves foráneas que referencian a Alumno y a Materia

Una relación M:N se transforma creando una tabla intermedia (de unión) cuya clave primaria combina las claves foráneas de ambas entidades participantes; agregar la clave de una entidad en la otra solo es válido para relaciones 1:N. (Elmasri y Navathe, "Fundamentals of Database Systems", algoritmo de mapeo E-R a relacional.)

31. Un modelo entidad-relación describe que cada Empleado ocupa como máximo una Oficina, aunque no todos los empleados tienen oficina asignada, mientras que toda Oficina debe estar asignada exactamente a un Empleado. Se trata de una relación uno a uno (1:1) en la que Oficina tiene participación total y Empleado tiene participación parcial. Al mapear este modelo a tablas relacionales, ¿en qué tabla conviene colocar la clave foránea para minimizar los valores nulos?

1. En la tabla Oficina, como clave foránea que referencia a Empleado
2. En una tabla intermedia independiente que relacione a Empleado con Oficina
3. En la tabla Empleado, como clave foránea que referencia a Oficina
4. En ambas tablas al mismo tiempo, duplicando la clave foránea en cada una

Dado que toda Oficina tiene participación total (siempre tiene un empleado asignado), colocar ahí la clave foránea evita nulos; si se colocara en Empleado, los empleados sin oficina generarían valores nulos. (Elmasri y Navathe, "Fundamentals of Database Systems", reglas de mapeo de relaciones 1:1 según participación.)

32. Un modelo entidad-relación describe en palabras la siguiente situación: "un Departamento puede tener asignados muchos Empleados, pero cada Empleado pertenece exactamente a un Departamento". ¿Qué cardinalidad describe esta relación entre Departamento y Empleado?

1. Muchos a muchos (M:N)
2. Uno a muchos (1:N)
3. Cero a muchos (0:N)
4. Uno a uno (1:1)

Cada empleado se asocia con exactamente un departamento (no cero) y un departamento puede tener varios empleados, lo que corresponde a la cardinalidad uno a muchos. (Elmasri y Navathe, "Fundamentals of Database Systems", representación de cardinalidades en el modelo E-R.)

33. En un modelo entidad-relación, la entidad Dependiente es una entidad débil que no puede existir sin un Empleado asociado, y se identifica mediante una clave parcial propia junto con la clave primaria de Empleado. Al construir el esquema relacional, ¿cómo se refleja correctamente esta dependencia en la tabla Dependiente?

1. Omitiendo cualquier referencia a Empleado, ya que las entidades débiles no requieren claves foráneas
2. Creando una tabla intermedia adicional para vincular a Empleado con Dependiente
3. Incluyendo la clave primaria de Empleado como clave foránea dentro de Dependiente, formando parte de su clave primaria junto con la clave parcial
4. Incluyendo la clave primaria de Empleado únicamente como un atributo descriptivo, sin relación con la clave primaria de Dependiente

Las entidades débiles se identifican combinando su clave parcial con la clave primaria de la entidad fuerte, la cual se incorpora como clave foránea que forma parte de la clave primaria de la entidad débil. (Elmasri y Navathe, "Fundamentals of Database Systems", entidades y claves débiles.)

34. La tabla Pedido tiene como clave primaria id_pedido y contiene el atributo id_cliente, definido como clave foránea que referencia a la clave primaria de la tabla Cliente. ¿Cuál de las siguientes inserciones en Pedido NO es congruente con la regla de integridad referencial?

1. Insertar un pedido con id_cliente igual al identificador de un cliente ya registrado en la tabla Cliente
2. Insertar un pedido con id_cliente = NULL, en una columna que no tiene restricción NOT NULL
3. Insertar un pedido con id_cliente igual al valor usado en otro pedido ya existente
4. Insertar un pedido con id_cliente = 87, valor que no existe en ningún registro de la tabla Cliente

La regla de integridad referencial exige que la clave foránea coincida con un valor existente de la clave primaria referenciada o sea nula; el valor 87 inexistente viola esa regla, mientras que las demás opciones sí son congruentes con ella. (Elmasri y Navathe, "Fundamentals of Database Systems"; C. J. Date, "An Introduction to Database Systems".)

35. Un modelo entidad-relación describe que un Empleado puede supervisar a varios empleados, y que cada Empleado tiene a lo sumo un supervisor, el cual también es un Empleado. Al mapear esta relación recursiva uno a muchos al esquema relacional, ¿cómo se representa correctamente en la tabla Empleado?

1. Agregando un atributo id_supervisor en la propia tabla Empleado, como clave foránea que referencia a la clave primaria de la misma tabla
2. Duplicando cada fila de Empleado que tiene subordinados, para representar la jerarquía
3. Creando una tabla llamada Supervisor con los mismos atributos que Empleado
4. Agregando en Empleado una clave foránea que referencia a una tabla independiente llamada Jerarquia

Las relaciones recursivas 1:N se representan mediante una clave foránea que apunta a la clave primaria de la misma tabla (clave foránea autorreferenciada), sin necesidad de tablas adicionales. (Elmasri y Navathe, "Fundamentals of Database Systems", relaciones recursivas en el modelo E-R.)