NEW
Font size
WorksheetsADBD Test 2
Total questions: 25
Worksheet time: 13mins
El término 'consistencia' de datos lo utilizamos cuando:
La base de datos puede comprobar internamente si un dato es incorrecto
No existen grupos repetitivos y, por tanto, es consistente con el modelo relacional
El tipo de un dato es consistente con el tipo que aparece en el esquema de esos datos
Existen varias copias de una misma información y nos preguntamos si son iguales
Según el principio de independencia lógico-física:
Obliga a utilizar un sistema de transacciones en la arquitectura funcional de la base de datos
El generador de código ejecutable del sistema de gestión de base de datos será quien haga la traducción al nivel físico
La base de datos no tiene nivel físico, solo lógico, eliminando de esta forma la posible dependencia entre ambos
Esta independencia la garantiza el nivel de abstracción 'esquema externo', de forma que el usuario no tiene que conocer el nivel físico
Llamamos lenguaje de consulta estructurado a aquel que:
Puede operar sobre cualquier tipo de dato, incluyendo aquellos que tienen una estructura compleja
Opera sobre tablas en base a un conjunto específico de operaciones
Tiene una estructura de control similar a lo que en lenguajes de programación son los bucles y los condicionales
Los lenguajes de consulta no son estructurados ya que no son tan potentes como los lenguajes de programación estructurados
Supongamos una relación entre las entidades A --- B, y una clase asociativa C correspondiente a esa
relación. La cardinalidad en la dirección C -> A y C -> B es:
1 en ambas direcciones
Dependerá de la cardinalidad que haya entre A y B
* (muchos) en ambas direcciones
1 en una dirección C->B, y * en la dirección C->A
Hacemos primero el diseño conceptual y después el lógico porque:
Podemos estructurar la información con entidades, atributos y relaciones, sin tener que entrar en algunos tecnicismos propios de los modelos de tablas
El conceptual es el único nivel que no define ningún tipo de estructura de datos, ya que las tablas se pueden considerar como estructuras de datos
En realidad, los dos diseños se hacen en paralelo y a la vez
Enlaza mejor con la programación orientada al objeto, que es como suele implementarse el programa que accede a la base de datos
Una entidad es débil cuando:
Necesita de otra para identificarse, y esto se puede dar sobre cualquier tipo de relación
No puede existir si no existe otra con la que está relacionada de cualquier manera
Necesita de otra para identificarse, y esto se da sobre una relación con cardinalidad 1
No puede existir si no existe otra con la que está relacionada obligatoriamente
Un grupo repetitivo se produce cuando:
Se quiere almacenar un número indeterminado de valores en una tabla
Se quiere almacenar un número indeternimado de valores en un atributo
Se quiere almacenar un número indeterminado de valores en una entidad
Se quiere almacenar un número indeterminado de valores en cualquier sitio
En la cardinalidad de una relación, llamamos opcionalidad:
A la cardinalidad mínima que, habitualmente suele ser 0 ó 1
A la cardinalidad máxima pero siempre que sea * , ya que esto permite cualquier opción
A la representación opcional de clases asociativas para relaciones muchos-a-muchos
A la opción de no poner una cardinalidad por no ser necesaria para la representación de los requisitos
El hecho de que un atributo en una tabla sea al mismo tiempo clave primaria (no multicolumna; sólo ese atributo) y clave foránea, ocurre cuando:
Implementamos una relación recursiva, esto es, una relación que en ambos extremos está la misma entidad
Implementamos la especialización con tablas para la superclase y las subclases
Implementamos la tabla que representa a una entidad asociativa
Implementamos una entidad que es débil
En el modelo relacional, cuando en SQL se crea una tabla con una sentencia que contiene 'PRIMARY KEY
(atrib1,atrib2)', lo que realmente se está creando es:
Dos claves primarias, una para cada atributo
Una clave primaria (primer atributo) y una clave alternativa (segundo atributo)
Una clave primaria que utiliza únicamente el primer atributo, salvo en los casos en los que puede haber repetición de valores que es cuando utiliza también el segundo atributo
Una única clave primaria formada conjuntamente por dos atributos
¿Cuál es la política por defecto (si no indicamos nada en la definición de la clave foránea) de cumplimiento de la integridad referencial en una operación de borrado?
CASCADE
NO ACTION
SET DEFAULT
SET NULL
Supongamos una clave foránea que apunta a una clave primaria de otra tabla. Esta clave foránea NO puede contener nulos:
Verdadero: al estar apuntando a una clave primaria esta no puede contener nulos
Verdadero: simplemente por integridad referencial
Falso: ya que de lo contrario podríamos tener un problema de inconsistencia
Falso: los nulos no se tienen en cuenta en la integridad referencial y permiten implementar la opcionalidad en las relaciones
Cuando se traduce a tablas una relación muchos-a-muchos que tiene una clase asociativa:
Aparece una tabla que implementa la clase asociativa, y esta tabla contiene una única clave foránea formada por varios atributos que apuntan a las clases asociadas
Si la relación no es uno-a-muchos, no harán falta claves foráneas y, por tanto, no se incluirá una tabla que implemente la clase asociativa
Aparece una tabla que implementa la clase asociativa, y esta tabla contiene dos claves foráneas que apuntan a las clases asociadas
Aparece una tabla que implementa la clase asociativa, que es apuntada por dos claves foráneas que están en las clases asociadas
En SQL, un uso habitual de las vistas es:
Implementar el diseño físico para las tablas que no son base, esto es, para aquellas que no están almacenadas
Permitir la construcción de restricciones de integridad específicas de la aplicación que se esté construyendo
Implementar la generalización/especialización de superclases y subclases
Restringir los datos a los que puede acceder un usuario, por medio de operaciones de restricción y proyección sobre tablas base
La relación entre el cálculo relacional y las restricciones de integridad de la base de datos es que:
Ambos dos tienen forma declarativa e incluyen condiciones booleanas que se pueden evaluar para distintas combinaciones de datos
En realidad no tienen ninguna relación
Ambos dos tienen forma declarativa pero el cálculo no incluye condiciones booleanas
Ambos dos tienen forma declarativa pero las restricciones no incluyen condiciones booleanas
En el álgebra relacional, el orden en que se aplican los operadores tiene importancia a la hora de escribir
SQL
Verdadero, en SQL tenemos que escribir la misma ordenación de operaciones que en el álgebra relacional
Falso, es la base de datos la que internamente busca la forma más eficiente de realizar las consultas
Verdadero, pero solo si disponemos en SQL de la construcción WITH, ya que esto nos permite ordenar la definición de las tablas intermedias
Falso, el SQL tiene relación con el cálculo relacional, pero no con el álgebra
En SQL, ¿qué relación hay entre agregación y agrupación?
En realidad no tienen ninguna relación
La agrupación particiona las tuplas por valores de atributos, y sobre cada grupo se aplica la agregación
La agrupación junta tuplas de distintas tablas y la partición es el operador contrario, esto es, las separa
La agregación calcula sumas, máximos, conteos, etc, y dependiendo de los valores resultantes se produce la partición en grupos
El motivo por el que muchos sistemas de gestión de bases de datos no implementan un procedimiento
general para asegurar que se cumplen las restricciones explícitas es porque:
Ya figuran en el estándar SQL92 los disparadores, y con esto se puede implementar cualquier restricción
En realidad casi todos los sistemas de gestión de bases de datos comerciales SÍ que comprueban todas las restricciones de integridad, tanto implícitas como explícitas
La mayoría de las restricciones explícitas se pueden poner como restricciones implícitas, y esto sí que está soportado por las bases de datos
Es un problema de muy alto coste y se degradaría la eficiencia general de la base de datos
En SQL, la construcción <>ALL es equivalente a
NOT IN
EXISTS
NOT EXISTS
IN
En SQL, cuando construyo un 'natural join' entre dos tablas A y B, utilizando una clave foránea (B.idA) que apunta a una primaria (A.idA), el número resultante de tuplas es:
Es variable y no tiene por qué coincidir con el número de tuplas de A ni de B
Por integridad referencial el resultado siempre es una única tupla
Tantas como tenga la tabla B
Tantas como tenga la tabla A
Cuando una relación está desnormalizada, por ejemplo con dependencia funcional A --> B (A no clave),
la anomalía de borrado consiste en que:
Es una anomalía por el grupo repetitivo que ocurre en B para un determinado valor de A
Si se borran todas las tuplas de un cierto valor de A, se deja de saber el valor que le corresponde en B
La base de datos no permitiría ese borrado ya que todavía tiene que asegurarse la integridad referencial
Deja de haber redundacia, lo cual implica que ya no es necesario normalizar
En una dependencia funcional A --> B (A no es clave primaria; B no es parte de clave primaria), si mantenemos fijo el valor de A de una determinada tupla, entonces tampoco se puede cambiar el valor de B de esa misma tupla
Falso, el valor de B se puede cambiar en esa tupla siempre que lo hagamos igualmente para todas las tuplas en las que coincida el valor de A
Falso, ya que A no es clave primaria
Verdadero, la dependencia funcional es una función que nos dice que valor tiene que tener B una vez que sabemos el de A. Por tanto B no se puede cambiar en una tupla sin cambiar correspondientemente el de A
Verdadero, ya que B no es parte de clave primaria
Un administrador de bases de datos tiene que trabajar con árboles relacionales
Los árboles relacionales son completamente internos al funcionamiento de las bases de datos y nadie puede verlos, ni siquiera el administrador, ya que no se puede hacer nada para cambiarlos
El administrador puede ver los árboles relacionales relativos a una consulta, pero no puede hacer nada para introducir mejoras
Solo si está trabajando en modo 'álgebra relacional', donde sí que aparecen los árboles relacionales. Si trabaja en modo 'cálculo relacional' no aparecen.
Para entender los planes de ejecución de las consultas y ver si existen formas de introducir mejoras
El administrador de bases de datos se encarga de crear el diseño físico de la base de datos
Verdadero, ya que los desarrolladores de bases de datos solo realizan los diseños conceptual y lógico
Falso, ya que el diseño físico es una consecuencia directa de los requisitos, lo cual es realizado por los analistas de datos
Verdadero, a excepción de las tablas que las crean los desarrolladores
Falso, los desarrolladores de bases de datos realizan todos los diseños
En los lenguajes etiquetados de los modelos semi-estructurados, ¿qué papel juegan los esquemas?
En estos modelos no existe ningún tipo de esquema
Hay algún tipo de esquema que da estructura a los datos, pero solo en lo que se refiere al modelo físico (no para el conceptual ni para el lógico)
Hay algún tipo de esquema que da estructura a los datos, pero es más limitado y flexible que en los rígidos esquemas de los modelos estructurados
Hay algún tipo de esquema que da estructura a los datos, pero es todavía más rígido que en los modelos estructurados
