Sobreviviendo a la Arquitectura

Nos ponemos en el lugar de un programador en 1968. No existen las bases de datos como las conocemos hoy, todo se guarda en archivos de texto planos. ¿Cuál es el drama principal de este enfoque?. A) Que los archivos de texto pesan el doble que una base de datos relacional. B) Que si dos usuarios intentan actualizar el mismo archivo a la vez, uno pisa los datos del otro sin enterarse (problema de concurrencia). C) Que los sistemas operativos de esa época no permitían buscar texto dentro de un archivo.

En los años 60, el modelo Jerárquico organizaba todo como un árbol de carpetas (un padre, muchos hijos). Si diseñamos el sistema de una universidad así, ¿con qué limitación absurda nos topamos?. A) Un estudiante no puede estar inscrito en dos asignaturas a la vez, porque un "hijo" no puede tener dos "padres". B) No se pueden borrar los datos de un profesor sin borrar también todo el edificio de la facultad. C) El sistema solo permite un máximo de 10 profesores por carrera.

3. En 1970, Edgar F. Codd (un matemático de IBM) publica el paper que cambia la historia. ¿Cuál era su argumento principal para proponer el Modelo Relacional?. A) Que el software de base de datos debía ser gratis y de código abierto. B) Que debíamos separar cómo se guardan físicamente los datos en el disco de cómo los ve el programador (independencia de datos). C) Que el lenguaje SQL era la única forma en que los humanos debían comunicarse con las máquinas.

Estás revisando una tabla de "Usuarios" y ves que la columna Direccion contiene: "Calle Falsa 123, Depto 4B, Madrid, España". ¿Por qué la Primera Forma Normal (1FN) te obligaría a romper esto?. A) Porque la 1FN exige que los valores de cada columna sean atómicos (indivisibles), por lo que deberías separar calle, ciudad y país. B) Porque la 1FN prohíbe el uso de texto largo en las tablas principales. C) Porque no puedes tener números y letras mezclados en la misma celda.

Un cliente te pide que cuando un usuario cambie su correo en su perfil, ese cambio se refleje mágicamente en los 500 historiales de compras viejas que tiene guardados. ¿Cuál es la forma correcta de diseñar esto en un modelo relacional?. A) Duplicar el correo del cliente en la tabla de compras para que el sistema no tenga que buscar en dos sitios. B) Usar una Clave Foránea (id_cliente) en la tabla de compras que apunte a la tabla de usuarios, evitando la redundancia. C) Guardar las compras dentro de un archivo de texto plano separado por comas.

1 +1 son 2?. Si. No.

¿Cuál es la diferencia real entre una Clave Primaria (Primary Key) y una Clave Foránea (Foreign Key) en una tabla?. A) La clave primaria solo acepta texto y la foránea solo acepta números. B) La primaria identifica de forma única a un registro en su propia tabla; la foránea sirve para conectar ese registro con otra tabla distinta. C) La clave primaria es obligatoria en todas las bases de datos y la foránea se dejó de usar en los años 90.

¿Es obligatorio que una tabla de una base de datos relacional tenga una Clave Primaria (Primary Key) para poder guardar información en ella?. Si. No.

Si eliminas una base de datos por completo (haces un DROP DATABASE), ¿puedes recuperar los datos simplemente reiniciando el servidor?. Sí. No.

Prof voy bien?. Si. Excelente (Correcta). Muy bien.

Estás haciendo el sistema para la biblioteca de la UDO (Sibiudo) y necesitas conectar la tabla Estudiantes con la tabla Libros_Prestados. ¿Es una buena idea usar el número de cédula del estudiante como Clave Foránea (Foreign Key) en la tabla de préstamos?. Sí. No.