lunes, 23 de mayo de 2011

Soluciones T12 (por dificultad)

Dificultad A

T12.002- Calcula y muestra la cantidad de televisores, cámaras y objetivos almacenados en la base de datos.
select
(select count(*) from tv) Televisiones,
(select count(*) from camara) Cámaras,
(select count(*) from objetivo) Objetivos;

T12.003- Calcula y muestra el porcentaje de televisores, cámaras y objetivos sobre el total de artículos almacenados en la base de datos.
select
(select count(*) from tv)/(select count(*) from articulo)*100 Televisiones,
(select count(*) from camara)/(select count(*) from articulo)*100 Cámaras,
(select count(*) from objetivo)/(select count(*) from articulo)*100 Objetivos;

Dificultad B

T12.001- Días que han pasado entre el primer y último pedido.
select datediff (
(select fecha from pedido
where fecha = (select max(fecha) from pedido)),
(select fecha from pedido
where fecha = (select min(fecha) from pedido))
) Días;

T12.004- Email, nombre y apellidos de los usuarios de la provincia 03, y si tienen un pedido cuyo importe total sea mayor que 10000€, mostrar también el número de pedido y ese importe; ordena la salida descendentemente por el valor del pedido.
select email, nombre, apellidos, numPedido, valor
from usuario u
left join (select p.numPedido, usuario, sum(cantidad*precio) valor
from pedido p, linped lp
where p.numpedido = lp.numpedido
group by numPedido, usuario
having sum(cantidad*precio) > 10000) calculo
on (email = usuario)
where provincia='03'
order by valor desc;

T12.005- De los usuarios que tengan algún pedido sin líneas de pedido y artículos pendientes de solicitud en alguna cesta, mostrar su email, nombre, apellidos, número del pedido sin líneas, y valor total de su cesta.

Comienza resolviendo pedidos sin líneas y valor de la cesta por usuario y utiliza los resultados como tablas temporales.
select email,nombre, apellidos,numPedido, pendiente
from usuario u,
(select numPedido,usuario
from pedido
where numPedido not in (select numPedido from linped)) Pedidos,
(select usuario, sum(pvp) Pendiente
from cesta ce, articulo art
where ce.articulo=art.cod
group by usuario) Cestas
where email=pedido.usuario and email=cestas.usuario;

T12.006- Para aquellos usuarios que tengan más de un pedido en 2010, obtener una tabla donde cada columna se corresponda con un mes del año y muestre la cantidad de pedidos realizada por ese usuario en ese mes. Cada fila empieza por el email, nombre y apellidos del usuario.
select email,nombre,apellidos,
(select count(*) from pedido where month(fecha)=1 and year(fecha)=2010 and usuario=email) Enero,
(select count(*) from pedido where month(fecha)=2 and year(fecha)=2010 and usuario=email) Febrero,
(select count(*) from pedido where month(fecha)=3 and year(fecha)=2010 and usuario=email) Marzo,
(select count(*) from pedido where month(fecha)=4 and year(fecha)=2010 and usuario=email) Abril,
(select count(*) from pedido where month(fecha)=5 and year(fecha)=2010 and usuario=email) Mayo,
(select count(*) from pedido where month(fecha)=6 and year(fecha)=2010 and usuario=email) Junio,
(select count(*) from pedido where month(fecha)=7 and year(fecha)=2010 and usuario=email) Julio,
(select count(*) from pedido where month(fecha)=8 and year(fecha)=2010 and usuario=email) Agosto,
(select count(*) from pedido where month(fecha)=9 and year(fecha)=2010 and usuario=email) Septiembre,
(select count(*) from pedido where month(fecha)=10 and year(fecha)=2010 and usuario=email) Octubre,
(select count(*) from pedido where month(fecha)=11 and year(fecha)=2010 and usuario=email) Noviembre,
(select count(*) from pedido where month(fecha)=12 and year(fecha)=2010 and usuario=email) Diciembre
from usuario
where email in (select usuario from pedido group by usuario having count(*) > 1);

Soluciones T11 (por dificultad)

Dificultad A

T11.002- Utilizando operadores de conjuntos obtener los nombres de los artículos que sean cámaras compactas con visor electrónico o televisores CRT.
select nombre from camara, articulo
where camara.cod = articulo.cod
and tipo like '%compacta%visor%electrónico%'
union
select nombre from tv, articulo
where tv.cod = articulo.cod
and panel like '%televisor%CRT%'

T11.004- Nombre y email de los usuarios de Asturias que tengan la misma dirección de envió que de residencia (por defecto es la misma dirección si no se especifica una dirección de envío).
select u.nombre, email from usuario u, provincia p
where u.provincia = codp
and p.nombre = 'Asturias'
and not exists(
select * from direnvio d
where u.email = d.email
)
O bien:
SELECT u.nombre, email FROM usuario u 
JOIN provincia p ON (u.provincia = codp)
WHERE p.nombre = 'Asturias' AND email NOT IN (SELECT email FROM direnvio)

T11.007- Utilizando operadores de conjuntos, muestra los nombres de los artículos que estén en un pack.
SELECT nombre
FROM articulo
WHERE EXISTS
(SELECT * FROM ptienea WHERE cod = articulo);

T11.008- Utilizando el producto cartesiano, obtener los nombres de las localidades con 2 o más usuarios. Realizar lo mismo utilizando el GROUP BY.
select distinct l.pueblo
from usuario u1, usuario u2, localidad l
where u1.email != u2.email
and u1.pueblo = u2.pueblo
and u1.provincia = u2.provincia
and u1.pueblo=l.codm
and u1.provincia=l.provincia
Explicación: Siendo distinto el email (es decir, siendo usuarios diferentes) y con la condición de que posean misma provincia y mismo pueblo; sacar el nombre de dicho pueblo. De aquí
se entiende que para dos usuarios distintos y con el mismo pueblo-provincia, se tiene al menos a estos dos usuarios con un mismo pueblo-provincia; por tanto se cumple la condición más
relevante del ejercicio (obviando el distinct y las claves ajenas bien definidas)
Group by:
select localidad.pueblo from localidad, usuario
where usuario.provincia = localidad.provincia
and usuario.pueblo = localidad.codm
group by localidad.pueblo
having count(localidad.pueblo) > 1

T11.009- Los códigos de los artículos que están en stock, en la cesta y han sido pedidos.
SELECT DISTINCT s.articulo 
FROM stock s, cesta c, linped l 
WHERE s.articulo = c.articulo AND s.articulo = l.articulo;
Con conjuntos sería
select articulo from cesta
INTERSECT
select articulo from stock
INTERSECT
select articulo from linped

T11.011- Códigos de artículos que están en alguna cesta o en alguna línea de pedido.
select articulo from cesta
union
select articulo from linped;

T11.013- Apellidos que se repitan en más de un usuario (sin utilizar group by).
select distinct u1.apellidos from usuario u1, usuario u2
where u1.email != u2.email
and u1.apellidos = u2.apellidos;

T11.014- Parejas de nombres de provincia que tienen algún pueblo que se llama igual, junto con el nombre del pueblo.
select p1.nombre, p2.nombre, l1.pueblo
from provincia p1, provincia p2, localidad l1, localidad l2
where p1.codp<>p2.codp 
 and p1.codp=l1.provincia 
 and p2.codp=l2.provincia 
 and l1.pueblo=l2.pueblo;

Dificultad B

T11.001- Listado de los códigos de los artículos Samsung que han sido pedidos.
select cod from articulo a, linped l
where cod = l.articulo
and marca = 'Samsung'

T11.003- Utilizando operadores de conjuntos obtener el nombre de los usuarios, la localidad y la provincia de los usuarios que sean de un pueblo que contenga 'San Vicente' o que sean de la provincia de 'Valencia'.
select distinct u.nombre, l.pueblo, p.nombre from usuario u, localidad l, provincia p
where u.provincia = l.provincia
and u.pueblo = codm
and l.provincia = codp
and l.pueblo like 'San V%Raspeig%'
union
select distinct u.nombre, l.pueblo, p.nombre from usuario u, localidad l, provincia p
where u.provincia = l.provincia
and u.pueblo = codm
and l.provincia = codp
and p.nombre like 'Valencia%'

T11.005- Necesito comprar los objetivos con focales de 500 o 600 mm para todas las marcas con las que trabajo para los que no tengo registrado todavía en artículos y necesito saber cuáles tengo que comprar.
SELECT DISTINCT focal, m.marca 
FROM objetivo o, marca m, articulo a 
WHERE a.cod = o.cod AND (focal = '500 mm' OR focal = '600 mm') 
 AND (focal,m.marca) NOT IN 
 (SELECT DISTINCT focal, a.marca FROM objetivo o 
 JOIN articulo a ON (o.cod = a.cod));

T11.006- Código y precio de los artículos 'Samsung' que tengan pvp y que no tengan pedidos.
select distinct cod, marca, pvp from articulo
where marca = 'Samsung'
and pvp is not null
and not exists (select * from linped
where linped.articulo = cod)

T11.010- Todos los artículos, aunque estén repetidos, que aparezcan en un pack o en una cesta.
select p.articulo, a.nombre
from ptienea p, articulo a
where p.articulo = a.cod
union all
select c.articulo, a.nombre
from cesta c, articulo a
where c.articulo = a.cod

T11.017- Usuarios que han solicitado pedidos de importe superior a 10000 (por pedido) o que han solicitado más de 5 artículos distintos entre todos sus pedidos.
select p.usuario from linped l, pedido p
where l.numPedido = p.numPedido
group by p.usuario
having sum((precio*cantidad))>10000
union
select p.usuario from linped l, pedido p
where l.numPedido = p.numPedido
group by p.usuario
having count(distinct articulo)>5

Reglas de normalizacion

Primera forma normal:
Para que una base de datos sea 1 forma normal, cada columna debe ser indivisible.
Para aplicar la primera forma normal solo hay que dividir cada columna no atomica en tantas columnas como sea necesario.

Segunda forma normal:
Para que una base de datos sea 2 forma normal (primero debe ser primera forma normal), todas las columnas que formen parte de una clave candidata deben aportar información sobre la clave completa.
Para aplicarla empezamos identificando las claves candidatas y elegimos la que va a ser la principal,si no existe una clave clara , crearemos una columna específica.
Tercera forma normal :
Una base de datos está en 3 forma normal (estando en 2 forma normal)  si todas las columnas que no sean claves depeden de la clave completa de forma no transitiva.
Para aplicarla hay que  eliminar las dependencias transitivas.

Cuarta Forma normal:
Una relación está en 4 forma normal si cada  atributo facilita unicamente  información sobre claves candidatas, y no sobre atributos que no formen parte de ninguna clave candidata.
Es decir no deben existir interrelaciones entre atributos fuera de las claves candidatas.

Todo sacado del material de clase ;)

Repaso de practicas

Crea una tabla: mitabla(a entero, b entero) CP(a) b) Inserta una fila: (1,10); c) Inserta una fila: (2,20); d) borra las filas con b<22 en una única instrucción. e) Borra la tabla.
create table mitabla( a int, b int, primary key (a))engine=innodb; insert into mitabla values(1,10); insert into mitabla values(2,20); delete from mitabla where b < 22; drop table if exists mitabla;


Nombre de los pueblos de la provincia '16', y si les pertenece alguna dirección de envío mostrar también el email
select nombre, email from provincia left join direnvio on (codp=provincia) where codp='16'


Crea una tabla: mitabla(a cadena(4), b cadena(2)) CP(b,a) b) Inserta desde tiendaonline.localidad todos los (codm,provincia) en una única instrucción. d) Borra todas las filas de mitabla. c) Borra la tabla.create table mitabla(a varchar(4), b varchar(2), primary key (b,a)); insert into mitabla(a,b) select codm, provincia from tiendaonline.localidad; delete from mitabla; drop table mitabla;

 Codigo, nombre y pvp de los artículos cuyo pvp está entre 85 y 155 euros, y si han sido solicitadas en algún pedido también el número de pedido y el precio de venta en el mismo
select cod, nombre, pvp, numPedido, precio from tiendaonline.articulo a left join tiendaonline.linped l on (l.articulo=a.cod) where pvp between 85 and 155;

a) Crea una tabla: mitabla(a int, b int, c int) CP(a) b) Inserta una fila: (a=1,b=10); c) Inserta una fila: (a=2,b=20); d) modifica todos los c al producto a*b en una única instrucción. d) Borra la tabla.
create table mitabla (a int,b int,c int,primary key (a));
insert into mitabla (a,b,c) values(1,10,NULL); insert into mitabla (a,b,c) values(2,20,NULL);
update mitabla set c=a*b;
drop table mitabla;

Lista de códigos de artículo y precio de las lineas del pedido 39, y si el artículo tiene un pvp mayor que 4000€ mostrar también la marca y ese pvp.
select linped.articulo,linped.precio,articulo.pvp,articulo.marca from linped left join articulo on(articulo.cod=linped.articulo and articulo.pvp>4000) where linped.numPedido=39;

Actividad 05a

¿Cuáles son las ideas principales que se pueden extraer de http://en.wikipedia.org/wiki/Data_model ?

Elige las 3 ideas o conceptos que consideres más importantes o relevantes para el tema Modelos de Datos, comentando brevemente la cita literal o explicando esas ideas con tus propias palabras.



La actividad 05, se basa en una búsqueda de los 3 conceptos más importantes sobre el modelo de las bases de datos “data model” usando como fuente de información:http://en.wikipedia.org/wiki/Data_model
Como se puede comprobar hay muchísima información y al principio puede costar decidir cuál es más importante que otra (en verdad toda es importante), no obstante me basaré sobretodo en un criterio de selección que estará orientado al uso posterior o implicación de la información en clase (aunque aún sea un poco prematuro).
Dando por sabidas las definiciones y la información en general cabe destacar los siguientes 3 aspectos:
Dentro de: “Database model” encontramos “A database model is a theory or specification describing how a database is structured and used”. Esto nos quiere decir que un modelo de base de datos es una descripción de especifica de cómo una base de datos es estructurada y usada. Obviamente este punto es clave porque según los diferentes tipos de modelos encontraremos una estructura diferente, pero común para todos. Cada modelo tendrá una forma de representación característica de cada uno.
Comentando brevemente podemos indicar los siguientes tipos de modelos de datos:

- Modelo plano cuya característica es la única serie bidimensional de elementos de datos donde todos los miembros de una fila son asumidos para ser relacionado el uno con el otro.
-Modelo jerárquico donde se organizan “como un árbol” donde los datos característicos se sitúan por niveles hasta llegar al único y general “en la cima”.
- Modelo de red: este modelo organiza datos que usan dos construcciones fundamentales.
- Modelo relacional: es un modelo de base de datos basado en la lógica Su idea principal es de describir una base de datos como una colección de predicados
2.  En “Data architecture” podemos hallar “in software engineering is the process of creating a data model by applying formal data model descriptions using data modeling techniques”. Donde podemos ver que en la ingeniería de software la arquitectura de datos es el proceso para poder crear un modelo de datos propio aplicando descripciones de modelos formales.

Este modelo de datos es una técnica usada apra definir las exigencias de un negocio mediante una base de datos. Estos modelos de datos son puestos en la práctica en las bases de datos.
3. Por último cabe destacar la los “Data properties”. Es decir, las propiedades: 
Los datos son extremadamente útiles dentro del contexto de su negocio.  Además se tiene una disponibilidad de una definición clara y compartida para los todos los datos que son compatiblespara el mismo tipo de datos aun siendo de diferentes fuentes.
También podemos encontrar más propiedades dentro del contenido ya  que hay una gran disponibilidadde datos en el tiempo requerido de una forma exacta.
Adémas de las propiedades relacionadas con la definición y esta última  con el contenido encontramos unas mixtas que relacionan definición y contenido como la entereza(“completeness”) que hace referencia a la  cantidad de datos disponibles. La accesibilidad donde vemos donde, como, y a quien están disponibles o no disponibles los datos (como la seguridad) y por último el coste incurrido en obtener los datos, y su fabricación para el uso.

Actividad 05b

  • ¿Qué son Cassandra, Dynamo, BigTable, etc.?




  • ¿Cuál es la causa principal de su aparición?




  • ¿Qué piensas, entonces, del futuro del modelo relacional




  • Para comenzar a introducirnos en estos temas cabe mencionar primero el problema que surge con el modelo actual de bases de datos y el movimiento "NoSQL" (Not Only SQL) que pretende bajar del podio al modelo Relacional.
    Las bases de datos relacionales que son las que guardan relaciones entre sus datos, se guardan en tablas obteniendo interconexiones.  Este modelo de datos es actualmente es más utilizado y además el más “robusto”. Además nos ofrece que cuantas más relaciones tenemos entre nuestras tablas mejor integridad de datos podemos lograr.
    Pero esta aparente virtud (la de tener mejor integridad a cuantas mas tablas) se puede volver un grave problema que ha hecho tambalear este arraigado sistema de datos. El problema consiste en que tanta integridad a la información fueron saturando todos los sistemas.
    Aquí podemos ver que el modelo relacional tiene como punto débil el consumo de recursos y la lentitud. Por ello los grandes de internet han comenzado ha lanzar nuevos sistemas revolucinadores como Google con BigTable, Amazon con Dynamo y Facebook con Cassandra.
    De esta forma el movimiento NoSQL surge por el año 2009 donde constan todos los demás sistemas alternativos a los que utilizan el modelo actual (MySQL, Oracle, PostgreSQL,...). Una de las características de este nuevo movimiento es que solucionan el problema del modelo relacional además al no estar bajo un mismo funcionamiento (como el relacional) y un lenguaje de acceso a los datos (SQL), dando muchísimos caminos para llegar a un resultado y dejando al aire muchas soluciones.
    Facebook contrató y diseñó un nuevo sistema para sus datos de donde nació Cassandra que es el resultado de la fusión de Dynamo para Amazon y las características de BigTable. Este sistema fue desarrollado en 2008 y liberado gratuitamente.
    Cassandra pretende combinar lo mejor de Dynamo (consistencia eventual) con lo mejor de BigTable (familias de columnas). De esta forma sus principales características son:
    Tiene la consistencia eventual de Dynamo de Amazon.
    Su modelo de datos basados en ColumnFamily, más rico que el tradicional modelo de clave/valor, esto lo obtiene de BigTable de Google.
    Cada fila de una tabla puede tomar valores en columnas distintas de una familia de columnas que otra fila.
    Tolerancia a los fallos, porque los datos se replican de forma automática en distintos nodos, o en distintos centros de datos.
    Es muy rápida ya que elimina el cuello de botella que supone el tener que traducir las consultas a lenguaje SQL.
    Gran disponibilidad, porque lo encontramos gratuitamente en Internet mantenido por  Apache (http://cassandra.apache.org).
    Esta mini redacción acerca del movimiento NoSQL y su rápida y contundente aparición en el mundo de la informática a causa de (aunque pocas) carencias del sistema relacional actual no es sino lo que ya se ha dicho: un fugaz surgimiento (aunque contundente) que no ha hecho nada mas que empezar. Por ello creo que la inmadura opinión de un joven futuro informático no va desencaminada cuando me atrevo a decir que tardeo temprano estos nuevos sistemas alternativos al modelo relacional desbancarán con el tiempo la utilización de este sistema en lo puntos donde flaquea.
    Concluyendo debo resaltar que estos modelos alternativos al sistema relacional con el paso del tiempo mejorarán y se abrirán el hueco que pretenden al hacer los puntos débiles del modelo relacional su punto mas fuerte de esta forma creo que en un futuro no tan lejano podremos ver el sistema relacional "destronado parcialmente" es decir un futuro compartido con estos nuevos sistemas que destacaran en sus características mas fuertes.

    BIBLIOGRAFIA: 

    domingo, 8 de mayo de 2011

    Soluciones del test de MR


    Sabemos que una tabla es una especialización del concepto representado por otra, por ejemplo coche respecto de vehículo, porque
    tiene una clave ajena exactamente igual a la clave primaria

    Si como producto de la adaptación del concepto de relación matemática al modelo relacional decimos que la relación tiene intensión y extensión, la segunda se define como
    el conjunto de n-tuplas, donde cada tupla es un conjunto de pares (nombreAtributo: valor)


    En el modelo relacional, una clave primaria puede ser al mismo tiempo
                    Una clave ajena

    Si R es una relación y A es una clave ajena de R que hace referencia a R2

                    no hay nunca que definir una política en A ante inserciones en R2, con independencia                                                            
                    de otras características que pueda tener la columna A (Valor No Nulo, Clave                 
                    Alternativa, Clave  primaria

    Si una tabla tiene 4 columnas, la cantidad máxima posible de claves candidatas es
    6

    Una clave candidata (o parte de ella)
                    puede contener cadenas vacías

    Si T es una tabla que contiene una clave ajena que hace referencia a una tabla X
                    borrar en X puede provocar problemas con la integridad referencial

    En el sistema real, ALUMNO puede escoger tantos VIAJES como quiera y los VIAJES sólo permiten un máximo de 30 ALUMNOS cada uno, pero al diseñar las tablas en modelo relacional la aproximación más correcta
                    necesita dos claves ajenas 

    De dominios en el modelo relacional y tipos de datos en lenguajes de programación, sistemas de gestión de bases de datos, etc.
                    los tipos de datos son casos particulares de dominios 

    El caso de Factura-Línea_de_detalle es un ejemplo de
                    dependencia de identificador

    Si no necesito que los coches tengan propietario, pero sólo pueden tener un propietario
                    pondré la clave ajena en coches

    La política de anular en la clave ajena de una relación no tiene sentido si
                    esa clave ajena es también clave primaria o clave alternativa

    Las propiedades de cobertura son
                    total o parcial, y solapada o disjunta 

    la definición de la relación matemática por intensión, después de su adaptación al modelo relacional es equivalente a su
                    esquema 

    La integridad de clave
                    no permite nulos en ninguna de las columnas de la clave primaria 

    Una restricción de correspondencia entre clases de objetos de cardinalidad mínima 3
    nos dice que la ocurrencia del objeto estará presente en la agregación al menos tres veces

    Si entre cliente y vehículo existe una relación alquilar de tipo uno a uno, y cliente sufre una restricción de existencia respecto de alquilar, tendrá clave alternativa la tabla
                    cliente 

    A una clave ajena de una relación R se le pueden definir políticas para velar por la integridad referencial para saber que acciones realizar ante
                    borrados y modificaciones en R que violen la integridad referencial. 

    Si una clave ajena tiene, además, una restricción de valor no nulo
                    refleja una restricción de existencia 

    En el modelo relacional, si VEHÍCULO es una clase generalizada y COCHE es subtipo, la CARD(VEHÍCULO,R)
                    tiene cardinalidad máxima 1

    Si los alumnos de mi sistema de información no son tales hasta que se han matriculado de al menos una asignatura pero, al mismo tiempo, pueden matricularse de varias asignaturas
                    con una clave ajena en alumno que no admita nulos lo tengo solucionado. 

    Para adaptar el concepto de relación matemática al modelo relacional, Codd tuvo que
                    poner nombre a los dominios que constituyen la relación 

    Una tabla en el modelo relacional
                    no puede tener filas duplicadas 

    Una tercera tabla con dos claves ajenas, una de ellas clave primaria y la otra alternativa
                    es una relación uno a uno 

    La intensión de una relación se refiere

                    a su esquema 

    Una relación 1:1 con doble restricción de existencia
    una única tabla sin claves ajenas pero con una clave primaria y otra alternativa 

    Una clave ajena en el modelo relacional
                    indica una asociación entre objetos. 
    La definición de claves ajenas entre dos tablas es consecuencia de la aplicación de los mecanismos de abstracción
                    agregación o generalización 

    La integridad referencial puede "romperse"
    si no hay definida una estrategia de mantenimiento en todas y cada una de las claves ajenas 

    Si una tabla tiene 3 claves ajenas y todas admiten nulos y duplicados
                    estamos hablando de tres relaciones diferentes de esa tabla con otras. 

    El modelo relacional no recoge el concepto de
                    atributo multivaluado. 



    Si, en una tabla R(A,B,C), (A,B) es clave primaria y (B,C) es clave ajena que genera una correspondencia X con otra tabla
                    Card(R,x) = (1,1) 

     La relación matemática, antes de su adaptación al modelo relacional
                    no tiene orden entre sus tuplas ni duplicados 

     En una tabla en el modelo relacional
                    una clave candidata puede estar compuesta por varios atributos 


    Las políticas para mantener la integridad referencial en borrados y modificaciones en el modelo relacional se definen para
                    impedir referencias inconsistentes en claves ajenas 

    Si EMPLEADO y DEPARTAMENTO se relacionan de forma que un empleado sólo puede trabajar en un departamento como máximo, en modelo relacional se representaría como
                    una clave ajena en EMPLEADO 


    La definición de tablas en un SGBD relacional constituye
                    el esquema de la base de datos 


    Sea R una relación R(a:dom_a, b:dom_b, c:dom_c , d:dom_d)
                    R puede tener como claves candidatas (a,c), (b,c) y (d) 

     Al hablar de claves en el Modelo Relacional
                    una clave ajena de una relación R puede ser también la clave primaria de R. 

    Toda relación tiene al menos una clave candidata ya que
                    el conjunto de todos los atributos de una relación siempre cumplen la propiedad de   
                    identificación única. 

    Si todo valor de clave ajena ha de aparecer en la tabla a la que hace referencia, nos estamos refiriendo a
                    integridad referencial. 

    Una clave candidata puede contener nulos
                    nunca 

     Una relación 1:1
    dos tablas más una tercera que aloja 2 claves ajenas a cada una de las anteriores, una como clave primaria y la otra como alternativa 


    Para un conjunto de atributos determinado, la integridad de clave consiste en
                    la imposibilidad de almacenar nulos 

     Una generalización total y disjunta
                    no se puede representar en el modelo relacional 

    Un dominio, en la teoría del modelo relacional es
                    un conjunto de valores escalares 

    En toda relación se puede encontrar al menos una clave candidata ya que el conjunto de todos los atributos de una relación siempre
                    cumple la propiedad de identificación única 

    El trabajar con un SGBD que siga el Modelo Relacional fielmente nos garantiza
                    que en las tablas no hay tuplas duplicadas. 

    Para el Modelo Relacional, la no duplicidad de tuplas
                    es una restricción implícita por el tipo de estructura en la que se basa el modelo. 

    La independencia de datos en el modelo relacional se refiere a que
    cambios de dominio sobre columnas que no utiliza una vista no obligan a redefinir esta última 

    Una clave candidata puede contener nulos
                    nunca 

    Si necesito que cada empleado se relacione como máximo con un departamento aunque puede no asignársele
                    la clave ajena ha de estar en empleado. 

    La columna que actúa como clave ajena de una tabla puede contener valores nulos
    cuando la clave ajena representa una relación de conectividad 1:M y no hay restricción de existencia. 

     Si una tabla A, que se relaciona con otra tabla B, contiene una clave ajena que no permite nulos pero sí duplicados
                    cualquier fila de A se relacionará siempre con una y sólo una fila de B. 

     La integridad referencial en un SGBD relacional
    se cumple si toda la clave ajena es nula o ningún atributo de la clave es nulo y la referencia es válida. 

     El concepto matemático de tupla, como consecuencia del concepto de relación matemática (antes de su adaptación al modelo relacional), implica que
                    sólo existe una forma de referenciar una componente dentro de la tupla. 

     Si 2 tablas se relacionan mediante tres claves ajenas, todas en una de estas dos tablas, estamos hablando de
                    3 relaciones entre las dos tablas 

    Una especificación de correspondencia entre clases Card(T,x) = (1,N)
                    es imposible en un esquema de bases de datos relacionales 

     La integridad de clave primaria en un SGBD relacional
                    es la restricción que garantiza la no duplicidad de tuplas. 

    Una relación 1:1 con una restricción de existencia
    son dos tablas con una clave ajena en una de ellas que es, al mismo tiempo, clave alternativa 

    En el modelo relacional, al hecho de formar una relación empleado con dos atributos, nombre y tipo_de_contrato se le relaciona con un mecanismo de
    agregación 

    Si una relación se define en función de sus atributos como R(a, b, c) y (a, b) es clave primaria,
                    tendrá como máximo tres claves candidatas. 

    La definición de relaciones (tablas) en una BD relacional establece las propiedades (del sistema de información que representan)
                    estáticas 

    Las restricciones de existencia en las correspondencias entre clases en el modelo relacional
                    no son posibles en las relaciones muchos a muchos 

    Si toda relación siempre tiene al menos una clave candidata, la totalidad de los atributos de una relación
                    nunca será clave alternativa. 

    El concepto de relación matemática se adapta al modelo relacional
                    asignando un nombre simbólico a los componentes de las tuplas de la relación 

    El procedimiento de borrado en cascada (propagar el borrado), desde el punto de vista de la integridad referencial
                    es elegido por el diseñador del sistema en función de las necesidades del mismo. 

    Hablando de SGBD relacionales
                    catálogo y diccionario de datos son, en realidad, la misma cosa. 

    La política de propagar un borrado a una clave ajena de una relación no es posible
                    no es cierta la afirmación: siempre es posible 

    La agregación permite
    Construir clases de objetos complejas a partir de otras clases de objetos previamente definidas 

    Para una clave ajena en una relación R que forma parte de una clave alternativa también de R
                    anular no es una opción válida para mantener la integridad referencial 
    Si MARINO capitanea uno y sólo un BARCO, mientras que los BARCOS pueden NO tener capitán pero como mucho UN capitán
                    en la tabla MARINO hay una clave ajena que es, al mismo tiempo, clave alternativa 

    Si T es una tabla que contiene una clave ajena que hace referencia a una tabla X
    siempre podré borrar y modificar en T, salvo si existe alguna clave ajena en otra tabla que haga referencia a T 

    Si una relación tiene más de una clave candidata
                    cualquiera de las claves candidatas sirve para identificar las tuplas de la misma. 

    Si una tabla A tiene una relación con otra tabla y la clave ajena está definida en en esa otra tabla
                    nunca podrá tener restricción de existencia. 

    Si 2 tablas se relacionan mediante una clave ajena en una de ellas que es al mismo tiempo clave alternativa, estamos hablando de
                    una relación uno a uno con restricción de existencia 

    Si R es una relación compuesta por tres atributos R(A,B,C), que las claves candidatas sean irreducibles significa que
                    (A,C) y (A, B) pueden ser ambas claves candidatas