Práctica 1 - Solución Propuesta

De FdIwiki ABD
Saltar a: navegación, buscar

PRÁCTICA 1 - SOLUCIÓN PROPUESTA


APARTADO 2.1)

2.1.x)

     DNI   DIRECCIÓN
1 00000001 direcc 11
2 00000003 direcc 13
3 00000005 direcc 11
4 00000006 direcc 16

No es correcto porque el cliente con DNI 00000001 no es moroso. La causa es que estamos mostrando DNI y Dirección de la tabla Cliente, pero únicamente estamos comparando la Dirección entre la tabla Cliente y Moroso, pero no existe una DF entre Dirección y DNI. De este modo, la dirección de un cliente y de un moroso pueden coincidir, pero no necesariamente tienen por qué corresponder al mismo DNI.

2.1.a) Podremos considerar CC al atributo Dirección cuando permita distinguir a todas y cada una de las posibles tuplas de la tabla Cliente. En la relación que existe actualmente, varios clientes tienen la misma dirección. Por esta razón, el atributo Dirección no puede ser considerado CC. CorRección:

UPDATE Cliente
SET Direccion = 'direc 15'
WHERE DNI = '00000005';

2.1.b) Sí, existe redundancia. El atributo Sueldo no aporta información nueva porque en este caso cada título determina el sueldo. Corrección:

ALTER TABLE Puesto
DROP COLUMN Sueldo;

Si en la tabla Puesto suponemos que un cliente puede tener dos títulos, la CP podría ser el conjunto de los atributos DNI y Título.

ALTER TABLE Puesto
ADD primary key (DNI, Titulo);

2.1.c) Si un cliente puede tener varios teléfonos, la tabla Cliente no cumple la 1FN. Corrección: NombreC y Teléfono serían la CP

ALTER TABLE Cliente
ADD primary key (NombreC, Teléfono)
INSERT INTO Cliente VALUES ('00000003', 'Client B', 'direc 13', '911111111117');


APARTADO 2.2)

2.2.a) El nombre del cliente determina su DNI, es decir, dos clientes con el mismo nombre tendrán el mismo DNI. Corrección:

UPDATE Cliente
SET NombreC = 'Client E'
WHERE DNI = '00000005';
UPDATE Cliente
SET NombreC = 'Client F'
WHERE DNI = '00000004';

2.2.b) La dirección del cliente determina su nombre, es decir, dos clientes con la misma dirección tendrán el mismo nombre. Corrección:

UPDATE Cliente
SET Direccion = 'direc 15'
WHERE DNI = '00000005';
UPDATE Cliente
SET NombreC = 'Client E'
WHERE DNI = '00000005';
UPDATE Cliente
SET NombreC = 'Client F'
WHERE DNI = '00000004';

2.2.c) La tienda donde se compró determina el número de factura, es decir, dos compras realizadas en la misma tienda tendrán el mismo número de factura. Esta DF no es razonable porque una tienda puede tener varias facturas.

2.2.d) El número de factura determina la tienda en la que se compró, es decir, dos compras con el mismo número de factura habrán sido realizadas en la misma tienda. Esta DF no es razonable porque dos tiendas diferentes pueden tener números de factura iguales.


APARTADO 2.3)

2.3.a) Se trata de una DM, porque obliga a que haya unas filas en la tabla. En este caso obliga a que cada vez que un cliente invierta en una nueva empresa lo tenga que hacer en todos los tipos en los que había invertido antes.

2.3.b) Anomalías de inserción: Si un cliente que no se encuentra en la BD quiere invertir en una empresa en la que aún no ha invertido nadie, se desconocería la cantidad de los diferentes tipos para esa empresa. Anomalías de modificación: Si un cliente que ya se encuentra en la BD quiera añadir/eliminar un tipo de inversión que realiza en una empresa en la que ya invierte con otros tipos, se deberá añadir/eliminar el nuevo tipo en todas las empresas en las que invierta. Anomalías de borrado: Si borramos el único cliente que haya invertido en un tipo determinado para una empresa determinada, perderíamos la información de la cantidad de ese tipo para esa empresa.

2.3.c) Convirtiendo la tabla Invierte en dos tablas. Una formada por DNI y NombreE y otra formada por NombreE, Tipo y Cantidad. En la primera la CP estará formada por DNI y NombreE y en la segunda por NombreE y Tipo. En la segundo habría una DF: {NombreE, Tipo} → {Cantidad}.


APARTADO 3)

3.1) Para que la tabla Cliente NO esté en 1FN debería no tener todos sus atributos atómicos, es decir, contener atributos multivalorados, compuestos o sus combinaciones. Ejemplo de NO 1FN: DNI es CP de la tabla Cliente. Cada cliente puede tener más de un teléfono.

DNI        NombreC   Dirección      Teléfono
00000001   Andrés   C/ Legazpi   {123, 321, 213}
00000002   Carmen   C/ Perú           {456}
00000003   Roberto  C/ Ordoño       {789, 987}

3.2) Para que la tabla Invierte NO esté en 2FN algún atributo que no forme parte de la CP no debe depender de forma completa de la CP. Ejemplo de NO 2FN: DNI, NombreE y Tipo forman la CP de la tabla Invierte. DF1 parcial: Tipo → Cantidad

DNI        NombreE   Cantidad   Tipo
00000001    Apple      1000     bono1
00000001    Apple      2000     bono2
00000001   Samsung     1000     bono1
00000002    Nokia      3000     bono3
00000002    Nokia      2000     bono2
00000003    Nokia      1000     bono1
00000003   Samsung     2000     bono2

3.3) Para que la tabla Empresa NO esté en 3FN debe existir alguna dependencia funcional transitiva entre los atributos que no son CP, es decir, no se cumple la 3FN cuando algún atributo depende funcionalmente de atributos que no son CP. Ejemplo de NO 3FN: NombreE es la CP de la tabla Empresa. NombreE → Capital Capital → Cotización

NombreE   Cotización   Capital
Apple       30000      3000000
Nokia       10000      1000000
Samsung     20000      2000000

3.4) Para que la tabla Tarjeta no esté en FNBC debe haber algún determinante que no sea CP. Ejemplo de NO FNBC: NumT y TipoT es la CP de la tabla Tarjeta. DF1: Organización → TipoT

NumT                    TipoT                   Organización
00000001   Tarjeta de Compra El Corte Inglés   El Corte Inglés
00000001            Tarjeta Socio                   Fnac
00000001   Tarjeta Regalo El Corte Inglés      El Corte Inglés
00000002            Tarjeta Socio                   Fnac
00000002   Tarjeta Compra El Corte Inglés      El Corte Inglés


APARTADO 4)

4.1) Para reducir el número de accesos en el caso de que se realicen operaciones que tomen información de ambas relaciones.

4.2) Mejorar el rendimiento asumiendo alguna pérdida en calidad.

4.3) Una posible solución sería eliminar las tablas Estudiante, Bibliotecario y Profesor e incluir en la tabla Usuario un atributo Tipo para determinar si se trata de un usuario estudiante, un usuario bibliotecario o un usuario profesor. También habría que añadir los atributos específicos de cada tabla eliminada. Estos atributos podrían ser nulos en el caso de que no fueran los específicos del tipo de usuario.