🗄️ Manejo de datos y bases de datos

1. En el modelo relacional formulado por E. F. Codd (1970), una relación se define formalmente como un conjunto de tuplas. ¿Qué consecuencia directa tiene esta definición basada en teoría de conjuntos?

1. El orden de las columnas (atributos) determina la identidad de cada tupla dentro de la relación
2. El orden en que se listan las tuplas forma parte de la definición de la relación
3. Una relación no puede contener dos tuplas exactamente iguales
4. Una relación siempre debe contener al menos una tupla y no puede estar vacía

Por definición, una relación es un conjunto de tuplas y en teoría de conjuntos no existen elementos duplicados ni orden entre ellos; por eso una relación no puede tener dos tuplas idénticas. (E. F. Codd, A Relational Model of Data for Large Shared Data Banks, CACM 13(6), 1970; ISO/IEC 9075.)

2. Un analista necesita, en álgebra relacional, obtener el nombre y el correo de los empleados del departamento de Sistemas, a partir de la relación Empleado(NumEmpleado, Nombre, Correo, Departamento). ¿Qué combinación de operadores debe aplicar, en el orden correcto?

1. Un producto cartesiano (×) de Empleado consigo misma y, después, una proyección (π) sobre Nombre y Correo
2. Primero una selección (σ) con la condición Departamento = 'Sistemas' y, después, una proyección (π) sobre Nombre y Correo
3. Primero una proyección (π) sobre Nombre y Correo y, después, una selección (σ) con la condición Departamento = 'Sistemas'
4. Únicamente una proyección (π) sobre Nombre, Correo y Departamento, sin aplicar ninguna selección

Debe filtrarse primero con la selección σ y proyectar después, pues proyectar antes sobre Nombre y Correo eliminaría la columna Departamento necesaria para aplicar el filtro. (Silberschatz, Korth & Sudarshan, Fundamentos de Bases de Datos, cap. de álgebra relacional; formalismo original de E. F. Codd (1970).)

3. ¿Cuál es la condición que debe cumplir una relación para estar en Primera Forma Normal (1FN)?

1. Que el dominio de cada atributo contenga solo valores atómicos y cada atributo tome un único valor de ese dominio
2. Que todo atributo no primo dependa de forma completa de toda la clave primaria
3. Que ningún atributo no primo dependa transitivamente de otro atributo no primo
4. Que todo determinante de una dependencia funcional no trivial sea una superclave

La 1FN exige valores atómicos y monovaluados por atributo, sin grupos repetitivos; las otras opciones describen 2FN, 3FN y FNBC respectivamente. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de normalización; concepto original de E. F. Codd (1970).)

4. La tabla Empleado incluye el atributo Telefonos, en el que se almacenan varios números telefónicos de un mismo empleado separados por comas dentro de una sola celda. ¿Qué forma normal viola directamente este diseño?

1. La Segunda Forma Normal, porque Telefonos depende parcialmente de la clave primaria
2. La Tercera Forma Normal, porque Telefonos depende transitivamente de otro atributo no primo
3. La Forma Normal de Boyce-Codd, porque el determinante de la dependencia no es superclave
4. La Primera Forma Normal, porque Telefonos no contiene un valor atómico

Almacenar varios valores en un mismo atributo viola la 1FN, que exige valores atómicos e indivisibles por atributo. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de normalización.)

5. En una relación Inscripcion con clave primaria compuesta (NumControl, Materia), el atributo NombreAlumno depende únicamente de NumControl, mientras que Calificacion depende de la combinación completa de ambos atributos. ¿Qué tipo de dependencia presenta NombreAlumno y qué forma normal ocasiona que el esquema no cumpla?

1. Una dependencia parcial de la clave primaria, que viola la Segunda Forma Normal
2. Una dependencia transitiva entre atributos no primos, que viola la Tercera Forma Normal
3. Una dependencia multivaluada no trivial, que viola la Cuarta Forma Normal
4. Un valor no atómico en el atributo, que viola la Primera Forma Normal

NombreAlumno depende solo de una parte (NumControl) de la clave primaria compuesta, lo que constituye una dependencia parcial y viola la 2FN; no es transitiva, pues NumControl es un atributo primo por formar parte de la clave. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos; 2FN definida por E. F. Codd (1971).)

6. En la relación Empleado(NumEmpleado, Departamento, GerenteDepartamento), el atributo GerenteDepartamento depende de Departamento, y Departamento depende de la clave primaria NumEmpleado. ¿Qué tipo de dependencia representa GerenteDepartamento sobre NumEmpleado y qué forma normal viola?

1. Una dependencia parcial, que viola la Segunda Forma Normal
2. Una dependencia multivaluada, que viola la Cuarta Forma Normal
3. Una dependencia transitiva, que viola la Tercera Forma Normal
4. Un grupo repetitivo, que viola la Primera Forma Normal

GerenteDepartamento depende de un atributo no primo (Departamento) y no directamente de la clave primaria, lo que constituye una dependencia transitiva que viola la 3FN. (Silberschatz, Korth & Sudarshan, Fundamentos de Bases de Datos; 3FN definida por E. F. Codd (1971).)

7. ¿En qué se diferencia la Forma Normal de Boyce-Codd (FNBC) respecto de la Tercera Forma Normal (3FN)?

1. La FNBC exige que el determinante de toda dependencia funcional no trivial sea superclave, condición más estricta que 3FN
2. La FNBC permite dependencias transitivas entre atributos no primos, algo que la 3FN prohíbe
3. La FNBC solo aplica a relaciones con clave primaria simple, mientras que 3FN aplica a claves compuestas
4. La FNBC es una condición menos estricta que 3FN porque tolera dependencias parciales

La FNBC generaliza la 3FN al exigir superclave en el determinante de cualquier dependencia no trivial, incluso entre atributos primos, por lo que es más estricta. (Silberschatz et al., Fundamentos de Bases de Datos; FNBC atribuida a R. Boyce y E. F. Codd (1974).)

8. En la tabla Cliente, el atributo Telefono contiene NULL en varios registros. Un desarrollador ejecuta SELECT * FROM Cliente WHERE Telefono = NULL; y no obtiene ninguna fila, ni siquiera las que tienen Telefono en NULL. ¿Cuál es la causa correcta de este resultado, según la lógica de tres valores de SQL?

1. El motor interpreta el signo = como una asignación cuando se compara con NULL, no como una comparación
2. SQL no permite usar el operador = en la cláusula WHERE cuando la tabla contiene columnas NULL
3. El resultado vacío indica que la tabla Cliente no tiene ningún registro con Telefono en NULL
4. Cualquier comparación con NULL produce UNKNOWN, no TRUE, por lo que debe usarse IS NULL para probar nulidad

En la lógica de tres valores de SQL, columna = NULL evalúa a UNKNOWN y nunca a TRUE; para probar nulidad se requieren los predicados IS NULL / IS NOT NULL. (ISO/IEC 9075 (estándar SQL), lógica de tres valores (TRUE/FALSE/UNKNOWN).)

9. En el contexto de dependencias funcionales, ¿qué significa que una relación cumple X→Y?

1. Que el atributo Y siempre es una clave candidata de la relación
2. Que para cada par de tuplas con los mismos valores en X, los valores en Y también coinciden
3. Que X y Y deben pertenecer a tablas distintas relacionadas por una clave foránea
4. Que el valor de X puede repetirse solo si Y contiene un valor NULL

Una dependencia funcional X→Y significa que X determina de forma única el valor de Y en toda la relación. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de dependencias funcionales.)

10. ¿Qué establece la regla de integridad de entidad en el modelo relacional?

1. Que toda clave foránea debe coincidir con un valor existente de la clave referenciada o ser NULL
2. Que cada relación debe contar con al menos una clave foránea hacia otra relación
3. Que ningún atributo que forme parte de la clave primaria puede tener valor NULL
4. Que los atributos no primos no pueden depender de una clave candidata distinta de la primaria

La integridad de entidad prohíbe valores NULL en cualquier atributo de la clave primaria, para garantizar que cada tupla sea identificable; la opción sobre claves foráneas describe integridad referencial. (C. J. Date, Introducción a los Sistemas de Bases de Datos; regla de integridad del modelo relacional de E. F. Codd.)

11. Un desarrollador intenta insertar en la tabla Pedido un registro cuyo atributo IdCliente hace referencia a un cliente que no existe en la tabla Cliente. Según la regla de integridad referencial, ¿qué debe ocurrir?

1. El motor debe rechazar la inserción, salvo que IdCliente se establezca como NULL
2. La inserción debe aceptarse siempre, porque la integridad referencial solo aplica a operaciones UPDATE
3. El motor debe crear automáticamente un nuevo registro en Cliente con ese IdCliente
4. La inserción debe aceptarse porque la integridad referencial solo se valida al eliminar registros

La integridad referencial exige que toda clave foránea coincida con una clave existente en la tabla referenciada o sea NULL; un valor sin correspondencia debe rechazarse. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos; modelo relacional de E. F. Codd.)

12. La tabla Cliente contiene 10 filas; en 3 de ellas el atributo Telefono es NULL. Se ejecutan dos consultas: SELECT COUNT(*) FROM Cliente; y SELECT COUNT(Telefono) FROM Cliente; ¿qué resultado arroja cada una, respectivamente?

1. 7 y 10, porque COUNT(*) ignora las filas con algún valor NULL y COUNT(columna) las cuenta todas
2. 10 y 10, porque ambas funciones cuentan el total de filas sin excepción
3. 10 y 7, porque COUNT(*) cuenta todas las filas y COUNT(columna) ignora los valores NULL
4. 7 y 7, porque ambas funciones excluyen las filas que contienen algún valor NULL

COUNT(*) cuenta las 10 filas totales de la tabla, mientras que COUNT(Telefono) ignora las 3 filas con NULL y cuenta solo 7. (ISO/IEC 9075 (estándar SQL), funciones de agregación (set functions).)

13. Un analista desea listar los departamentos cuyo salario promedio supera los $15,000 pesos mensuales, a partir de la tabla Empleado agrupada por departamento. ¿En qué cláusula debe colocar la condición AVG(Salario) > 15000?

1. En la cláusula WHERE, porque filtra las filas antes de agruparlas y admite funciones de agregación
2. En la cláusula HAVING, porque filtra los grupos después de GROUP BY y admite funciones de agregación
3. En la cláusula ORDER BY, porque ordena los grupos según el valor agregado
4. En la cláusula FROM, porque ahí se definen las condiciones de agregación de la consulta

HAVING filtra después de GROUP BY y admite funciones de agregación como AVG; WHERE actúa antes de agrupar y no puede usar funciones agregadas. (ISO/IEC 9075 (estándar SQL), cláusulas de la sentencia SELECT.)

14. Un reporte debe incluir a todos los empleados, incluso a quienes aún no tienen un departamento asignado, y mostrar NULL en los datos del departamento cuando no exista coincidencia. Las tablas son Empleado (izquierda) y Departamento (derecha). ¿Qué tipo de reunión (join) debe usarse?

1. INNER JOIN, porque devuelve todas las filas de ambas tablas sin importar la coincidencia
2. RIGHT OUTER JOIN, porque conserva todas las filas de la tabla Departamento
3. CROSS JOIN, porque combina cada fila de Empleado con cada fila de Departamento
4. LEFT OUTER JOIN, porque conserva todas las filas de Empleado y rellena con NULL cuando no hay coincidencia

El LEFT OUTER JOIN preserva todas las filas de la tabla izquierda (Empleado) y coloca NULL en las columnas de la derecha cuando no hay coincidencia; INNER JOIN excluiría a los empleados sin departamento. (ISO/IEC 9075 (estándar SQL), joined tables.)

15. En el contexto de las propiedades ACID de una transacción, ¿qué garantiza la propiedad de Atomicidad?

1. Que la base de datos pase de un estado válido a otro estado válido conforme a sus reglas de integridad
2. Que todas las operaciones de la transacción se ejecuten por completo, o que ninguna de ellas se aplique
3. Que los efectos de una transacción confirmada persistan incluso ante una falla del sistema
4. Que las transacciones concurrentes no interfieran entre sí, como si se ejecutaran una tras otra

La Atomicidad trata la transacción como una unidad indivisible: se ejecuta completa o se revierte por completo; las otras opciones describen Consistencia, Durabilidad y Aislamiento. (Härder & Reuter, Principles of Transaction-Oriented Database Recovery, ACM Computing Surveys, 1983 (origen del acrónimo ACID); J. Gray, The Transaction Concept, 1981.)

16. Una aplicación bancaria transfiere $5,000 pesos de la cuenta A a la cuenta B mediante dos operaciones: primero resta el monto de A y después lo suma a B. El sistema falla justo después de restar el monto de A, antes de sumarlo a B. Si la base de datos garantiza correctamente la Atomicidad, ¿qué debe ocurrir al reiniciar?

1. La transacción completa debe deshacerse (ROLLBACK), dejando la cuenta A con su saldo original
2. La cuenta A debe conservar el descuento, y la cuenta B debe recibirlo en la siguiente transacción disponible
3. El sistema debe registrar la transacción como parcialmente completada y notificar al usuario
4. El sistema debe sumar el monto a la cuenta B tomando el último valor guardado en el registro de operaciones

La Atomicidad exige que, ante una falla a mitad de la transacción, todas sus operaciones se reviertan; la cuenta A debe recuperar su saldo original mediante ROLLBACK. (J. Gray, The Transaction Concept: Virtues and Limitations, 1981; Silberschatz, Korth & Sudarshan, Fundamentos de Bases de Datos, cap. de transacciones.)

17. ¿Qué garantiza la propiedad de Consistencia dentro de las propiedades ACID?

1. Que dos transacciones concurrentes nunca se ejecuten al mismo tiempo sobre la misma tabla
2. Que los datos modificados por una transacción confirmada no se pierdan ante un corte de energía
3. Que una transacción se ejecute de manera indivisible, sin estados intermedios visibles
4. Que toda transacción lleve a la base de datos de un estado válido a otro estado válido, respetando sus reglas

La Consistencia asegura que las reglas de integridad del esquema (claves, restricciones) se mantengan antes y después de cada transacción; las demás opciones describen Aislamiento, Durabilidad y Atomicidad. (Härder & Reuter, Principles of Transaction-Oriented Database Recovery, 1983; Silberschatz et al., Fundamentos de Bases de Datos.)

18. La tabla Cuenta tiene una restricción CHECK que impide que el atributo Saldo sea negativo. Una transacción intenta dejar el saldo de una cuenta en -200 pesos tras un retiro. ¿Qué propiedad ACID obliga al sistema a rechazar o revertir esta transacción?

1. El Aislamiento, porque otra transacción concurrente podría estar leyendo el mismo saldo
2. La Durabilidad, porque el cambio debe persistir aun si el sistema falla después del retiro
3. La Consistencia, porque la transacción no puede dejar a la base de datos en un estado que viole sus restricciones de integridad
4. La Atomicidad, porque el retiro involucra más de una tabla en la base de datos

Violar una restricción CHECK deja a la base de datos en un estado inválido, lo cual corresponde directamente a la propiedad de Consistencia. (Silberschatz, Korth & Sudarshan, Fundamentos de Bases de Datos, cap. de transacciones.)

19. ¿Qué garantiza la propiedad de Aislamiento (Isolation) en las transacciones de una base de datos?

1. Que la ejecución concurrente de varias transacciones produzca el mismo resultado que si se hubieran ejecutado una tras otra
2. Que cada transacción, una vez confirmada, sobreviva a fallas de hardware o cortes de energía
3. Que una transacción no pueda dividirse en operaciones más pequeñas durante su ejecución
4. Que la base de datos rechace toda transacción que viole una restricción de clave foránea

El Aislamiento garantiza que el resultado de ejecutar transacciones concurrentes sea equivalente a ejecutarlas en algún orden secuencial (serializabilidad); las otras opciones describen Durabilidad, Atomicidad e integridad referencial. (Härder & Reuter, Principles of Transaction-Oriented Database Recovery, 1983; Silberschatz et al., Fundamentos de Bases de Datos, cap. de control de concurrencia.)

20. La Transacción 1 actualiza el saldo de una cuenta pero aún no ejecuta COMMIT. 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 describe la lectura realizada por la Transacción 2?

1. Lectura no repetible, porque el mismo valor cambió entre dos lecturas de la Transacción 2
2. Lectura sucia (dirty read), porque leyó datos no confirmados que después fueron revertidos
3. Lectura fantasma, porque aparecieron nuevas filas que cumplen la condición de su consulta
4. Actualización perdida, porque el cambio de la Transacción 1 sobrescribió el de la Transacción 2

Leer un valor modificado pero aún no confirmado, que luego se revierte, es exactamente una lectura sucia (dirty read), un fenómeno que un buen Aislamiento debe evitar. (ISO/IEC 9075 (estándar SQL), niveles de aislamiento de transacciones; Berenson et al., A Critique of ANSI SQL Isolation Levels, 1995.)

21. De los cuatro niveles estándar de aislamiento definidos en SQL (Read Uncommitted, Read Committed, Repeatable Read y Serializable), ¿cuál evita por completo los tres fenómenos de lectura sucia, lectura no repetible y lectura fantasma?

1. Read Uncommitted
2. Read Committed
3. Repeatable Read
4. Serializable

Solo Serializable, el nivel más estricto, elimina los tres fenómenos; Repeatable Read evita lecturas sucias y no repetibles pero, según el estándar SQL, permite lecturas fantasma. (ISO/IEC 9075 (estándar SQL), niveles de aislamiento; Berenson et al., A Critique of ANSI SQL Isolation Levels, 1995.)

22. ¿Qué garantiza la propiedad de Durabilidad en una transacción de base de datos?

1. Que todas las operaciones de la transacción se ejecuten como una unidad indivisible
2. Que la transacción respete todas las restricciones de integridad definidas en el esquema
3. Que los efectos de una transacción confirmada persistan de manera permanente, incluso ante una falla del sistema inmediatamente posterior
4. Que ninguna otra transacción pueda leer datos modificados hasta que se confirme la primera

La Durabilidad asegura que, una vez ejecutado el COMMIT, los cambios sobrevivan a cualquier falla posterior; las demás opciones describen Atomicidad, Consistencia y Aislamiento. (Härder & Reuter, Principles of Transaction-Oriented Database Recovery, 1983; Silberschatz et al., Fundamentos de Bases de Datos.)

23. Inmediatamente después de que una transacción ejecuta COMMIT, el servidor sufre un corte de energía antes de escribir los cambios en el archivo de datos en disco. Al reiniciar, el sistema recupera exitosamente los cambios confirmados. ¿Qué mecanismo típico permite garantizar la Durabilidad en este escenario?

1. El bloqueo de aislamiento (locking), que impide que otras transacciones accedan a los datos modificados
2. Un registro de escritura anticipada (write-ahead log) que se guarda en disco antes de confirmar la transacción y se usa para rehacer los cambios en la recuperación
3. La verificación de restricciones CHECK y claves foráneas antes de ejecutar el COMMIT
4. La reversión automática (ROLLBACK) de la transacción confirmada al reiniciar el servidor

El write-ahead log (WAL) registra los cambios en disco antes de confirmar la transacción, lo que permite rehacerlos durante la recuperación tras una falla y así garantizar la Durabilidad. (Mohan et al., ARIES: A Transaction Recovery Method, ACM TODS, 1992; Silberschatz et al., Fundamentos de Bases de Datos, cap. de recuperación.)

24. Todas las siguientes situaciones son consecuencias directas de la propiedad de Atomicidad en una transacción, EXCEPTO:

1. Garantizar que dos transacciones concurrentes nunca lean datos no confirmados entre sí
2. Permitir revertir (ROLLBACK) todas las operaciones ya ejecutadas si la transacción falla antes de terminar
3. Tratar la secuencia de operaciones de la transacción como una unidad indivisible de trabajo
4. Evitar que la base de datos quede en un estado donde solo parte de las operaciones se aplicó

Impedir que una transacción lea datos no confirmados de otra es responsabilidad del Aislamiento, no de la Atomicidad; las demás opciones sí describen consecuencias directas de la Atomicidad. (Härder & Reuter, Principles of Transaction-Oriented Database Recovery, 1983; Silberschatz et al., Fundamentos de Bases de Datos.)

25. En el modelo entidad-relación, un atributo que puede tomar más de un valor para una misma entidad (por ejemplo, los números telefónicos de un empleado) se clasifica como:

1. Atributo derivado
2. Atributo compuesto
3. Atributo multivaluado
4. Atributo simple

Un atributo multivaluado admite varios valores simultáneos para una misma entidad, como los teléfonos de un empleado; el simple y el compuesto toman un solo valor (atómico o estructurado) y el derivado se calcula a partir de otro atributo. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de modelado entidad-relación.)

26. En el modelo entidad-relación, un atributo cuyo valor se calcula a partir del valor de otro atributo almacenado, como la 'Edad' calculada a partir de 'Fecha_nacimiento', se denomina atributo:

1. Derivado
2. Compuesto
3. Multivaluado
4. Clave

Un atributo derivado no se almacena directamente, sino que se obtiene mediante un cálculo sobre otro atributo almacenado; no debe confundirse con el atributo compuesto, que se subdivide en partes con significado propio. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de modelado entidad-relación.)

27. En una relación (vínculo) binaria del modelo ER, si cada instancia de la entidad A puede asociarse con muchas instancias de la entidad B, pero cada instancia de B se asocia con una sola instancia de A, la razón de cardinalidad de dicha relación (de A hacia B) es:

1. 1:1
2. M:N
3. N:1
4. 1:N

Cuando una instancia del lado A se relaciona con muchas de B, pero cada instancia de B se relaciona con una sola de A, la razón de cardinalidad se expresa como 1:N; escribirla como N:1 invierte el orden convencional de los lados de la relación. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de restricciones de razón de cardinalidad.)

28. Un analista describe el siguiente esquema: 'Cada Departamento tiene un único Gerente responsable, y cada empleado puede ser gerente de a lo sumo un departamento.' ¿Qué razón de cardinalidad describe correctamente la relación Dirige entre Departamento y Empleado (gerente)?

1. N:1
2. 1:1
3. M:N
4. 1:N

Ambos lados de la relación quedan limitados a una sola instancia asociada (un departamento con un gerente, y un gerente con un solo departamento), lo que corresponde a una cardinalidad 1:1, el ejemplo clásico de Departamento-Gerente. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de restricciones de razón de cardinalidad (ejemplo Departamento-Gerente).)

29. En el esquema ER de una empresa, la entidad Dependiente solo puede existir si está asociada mediante la relación identificadora 'Tiene_dependiente' con la entidad Empleado, y su clave se compone del nombre del dependiente junto con la clave del empleado del cual depende. ¿Qué tipo de entidad es Dependiente?

1. Entidad fuerte con clave compuesta
2. Subtipo (ISA) de Empleado
3. Entidad débil con clave parcial (discriminador)
4. Entidad asociativa

Una entidad débil no posee una clave propia que la identifique de forma independiente; se identifica combinando su clave parcial (discriminador) con la clave primaria de la entidad propietaria a través de la relación identificadora. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de entidades y relaciones débiles.)

30. En notación de Chen para el modelo entidad-relación, la restricción de participación TOTAL de una entidad en una relación significa que:

1. La entidad puede existir sin participar en ninguna instancia de la relación
2. La relación permite un máximo de una instancia asociada
3. Al menos una instancia de la entidad debe participar en la relación
4. Toda instancia de la entidad debe participar en al menos una instancia de esa relación

La participación total (u obligatoria) exige que cada instancia de la entidad aparezca relacionada con al menos una instancia de la otra entidad; la opción que habla de 'al menos una instancia' de la entidad describe de forma imprecisa la restricción y no equivale a la definición formal. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de restricciones de participación (total y parcial).)

31. En el modelo entidad-relación extendido (EER), cuando cada instancia de la superclase puede pertenecer, como máximo, a una sola subclase dentro de una especialización, dicha especialización se clasifica como:

1. Disjunta
2. Solapada
3. Total
4. Parcial

En una especialización disjunta, cada instancia de la superclase pertenece a lo sumo a una subclase (categorías mutuamente excluyentes); en la solapada una misma instancia puede pertenecer a varias subclases a la vez, mientras que total/parcial es una restricción distinta de participación. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de especialización y generalización (EER).)

32. Un ingeniero de bases de datos debe transformar a esquema relacional una relación M:N llamada Inscribe entre las entidades Alumno y Curso, la cual además tiene el atributo propio 'Calificación'. ¿Cuál es la forma correcta de representar esta relación en el modelo relacional?

1. Agregar el atributo Calificación como una columna adicional en la tabla Alumno
2. Agregar una clave foránea de Curso en la tabla Alumno y guardar Calificación en Curso
3. Crear una tabla Inscribe con clave primaria compuesta por las FK de Alumno y Curso, más Calificación
4. Fusionar las tablas Alumno y Curso en una sola, con Calificación como atributo derivado

Las relaciones M:N no pueden representarse con una clave foránea en ninguna de las dos tablas participantes; requieren una tabla independiente cuya clave primaria combine las claves foráneas de ambas entidades, donde además se colocan los atributos propios de la relación como Calificación. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de mapeo de ER a relacional (algoritmo de 7 pasos).)

33. Al mapear una relación binaria con razón de cardinalidad 1:N del modelo ER al modelo relacional, la clave foránea que referencia a la entidad del lado '1' debe colocarse en:

1. La tabla del lado 'N'
2. La tabla del lado '1'
3. Una tabla puente adicional
4. Ambas tablas participantes

En una relación 1:N, la clave foránea se coloca en la tabla del lado 'N' (el de participación múltiple), apuntando a la clave primaria del lado '1'; a diferencia de las relaciones M:N, no se necesita crear una tabla adicional. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de mapeo de ER a relacional.)

34. Un diagrama entidad-relación contiene 3 entidades fuertes, 1 entidad débil, una relación binaria 1:N, una relación binaria M:N y un atributo multivaluado. Aplicando el algoritmo estándar de mapeo de ER a esquema relacional, ¿cuántas tablas se generan en total?

1. 5 tablas
2. 6 tablas
3. 7 tablas
4. 4 tablas

Cada entidad fuerte genera una tabla (3), la entidad débil suma una tabla más que incorpora la clave del propietario (4), la relación 1:N no genera tabla nueva porque se resuelve con una clave foránea, la relación M:N sí genera una tabla independiente (5) y el atributo multivaluado requiere su propia tabla (6). (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de algoritmo de mapeo ER a relacional (7 pasos).)

35. Un caso describe una relación ternaria 'Suministra' entre las entidades Proveedor, Pieza y Proyecto, donde la cantidad suministrada depende de la combinación específica de los tres elementos. ¿Dónde debe colocarse el atributo Cantidad al mapear este esquema al modelo relacional?

1. En la tabla Proveedor, como un atributo propio de esa entidad
2. Repetido de forma idéntica en las tres tablas participantes
3. Únicamente en la tabla Proyecto, como atributo propio
4. En una tabla independiente con las FK de las tres entidades

Al igual que en las relaciones M:N binarias, una relación de grado tres requiere una tabla independiente cuya clave primaria combine las claves foráneas de las tres entidades participantes; el atributo Cantidad, que depende de la combinación completa, se almacena en esa tabla. (Elmasri & Navathe, Fundamentos de Sistemas de Bases de Datos, cap. de relaciones de grado mayor a dos (ternarias).)