Práctica 1 - solución propuesta

De FdIwiki ABD
Saltar a: navegación, buscar

Práctica 1

APARTADO 2

2.1. x – Para empezar, da error al copiar la consulta directamente, ya que utiliza “Morosos.DNI”, y la tabla se llama “Moroso”.

Una vez corregido eso, la consulta da el siguiente resultado:

DNI DIRECCION
00000001 direc 11
00000003 direc 13
00000005 direc 11
00000006 direc 16

El resultado es incorrecto, ya que el cliente 01 no es moroso. Se debería igualar el campo DNI en vez del campo Dirección en la cláusula Where. La consulta del enunciado no es válida porque existen varios DNI con la misma dirección y nombre.

2.1. a- Podemos considerar CC el atributo “Dirección” siempre y cuando para todo DNI diferente, exista una dirección diferente. Para que esto sea posible, hemos cambiado la dirección del DNI 05 (originalmente 11) por 15.

2.1. b- No es estrictamente necesario corregirlo, ya que los datos pueden ser cambiados manualmente, exigiendo mucho trabajo. Por lo tanto, es recomendable.

La solución propuesta sería crear una tabla nueva, cuyos atributos sean DNI y título, ambos claves ajenas referentes al DNI del cliente y al título del puesto. Además, en la tabla puesto no sería necesario tener el atributo DNI.

Siguiendo esta corrección, hemos eliminado la columna DNI de la tabla Puesto, y hemos tomado como CP título, eliminando la fila repetida. Así mismo, en la tabla cliente hemos tomado como CP DNI.

--Hemos borrado la tabla Puesto anterior

DROP TABLE Puesto CASCADE CONSTRAINTS;

--Creamos la tabla Puesto con dos atributos: titulo y sueldo

CREATE TABLE Puesto (Titulo VARCHAR2(30),Sueldo FLOAT);

--Introducimos los valores que teníamos en la BBDD inicial

INSERT INTO Puesto VALUES ('cajera', 300); INSERT INTO Puesto VALUES ('estudiante', 301); INSERT INTO Puesto VALUES ('Presidente', 30000); INSERT INTO Puesto VALUES ('VicePresidente', 3000); INSERT INTO Puesto VALUES ('Parado', 0);

--Borramos la anterior y creamos una nueva tabla Trabaja con atributos DNI y puesto referenciándolos a las tablas cliente y puesto

DROP TABLE TRABAJA;
CREATE TABLE TRABAJA(
DNI CHAR(8) NOT NULL,
PUESTO VARCHAR(30) NOT NULL);
ALTER TABLE TRABAJA
ADD FOREIGN KEY (DNI) REFERENCES CLIENTE (DNI);
ALTER TABLE TRABAJA
ADD FOREIGN KEY (PUESTO) REFERENCES PUESTO (TITULO);

--Insertamos los valores para tener el contenido de la BBDD inicial

INSERT INTO TRABAJA VALUES ('00000001', 'cajera');
INSERT INTO TRABAJA VALUES ('00000002', 'estudiante');
INSERT INTO TRABAJA VALUES ('00000003', 'Presidente');
INSERT INTO TRABAJA VALUES ('00000004', 'VicePresidente');
INSERT INTO TRABAJA VALUES ('00000005', 'Presidente');
INSERT INTO TRABAJA VALUES ('00000006', 'Parado');
INSERT INTO TRABAJA VALUES ('00000001', 'estudiante');

Resultados:

DNI PUESTO
00000001 cajera
00000002 estudiante
00000003 Presidente
00000004 VicePresidente
00000005 Presidente
00000006 Parado
00000001 estudiante

2.1. c- Como es un atributo multivaluado, hemos creado una tabla nueva cuya columna DNI hace referencia al DNI de cliente y la segunda columna es un teléfono. Cada vez que un cliente tenga un nuevo telefóno habrá una nueva fila.

CREATE TABLE TELEFONOS (
DNI CHAR (8) NOT NULL,
TELEFONO VARCHAR(30) NOT NULL,
FOREIGN KEY (DNI) REFERENCES CLIENTE(DNI));
INSERT INTO TELEFONOS VALUES ('00000001', '911111111111');
INSERT INTO TELEFONOS VALUES ('00000002', '911111111112');
INSERT INTO TELEFONOS VALUES ('00000003', '911111111113');
INSERT INTO TELEFONOS VALUES ('00000004', '911111111114');
INSERT INTO TELEFONOS VALUES ('00000005', '911111111115');
INSERT INTO TELEFONOS VALUES ('00000006', '911111111116');

2.1. d- Se establece como clave primaria de esa table tanto DNI como TELEFONO.


2.2. a- Cuando el nombre del cliente fija su DNI. Es decir, para dos clientes con el mismo nombre se tiene el mismo DNI.

No se cumple en la base de datos actual porque ‘Client A’ Tiene distintos DNI. Hay que corregir las filas con DNI ‘00000004’ y ‘00000005’

Tabla corregida:

DNI NOMBREC DIRECCION
00000001 Client A direc 11
00000003 Client B direc 13
00000002 Client C direc 12
00000005 Client F direc 15
00000004 Client E direc 14
00000006 Client D direc 16

2.2. b- Cuando el cliente tiene la misma dirección, tiene el mismo nombre.

Como se puede comprobar en la tabla corregida anterior, para distintas direcciones hay distintos nombres de cliente. Todas las filas son correctas

2.2. c- Cuando una compra tiene una misma tienda, tiene el mismo número de factura.

No es razonable, porque en la misma tienda se emiten diversas facturas todos los días


2.2. d- Cuando una compra tiene un mismo nº de factura, es de la misma tienda.

No es razonable, ya que debería poder existir el mismo nº de factura para diferentes tiendas.


2.3. a- Existen tres dependencias:

  1. 1

DNI ->> Nombre, que es DM, ya que cada vez que invierte en una empresa nueva, tiene que invertir en todos los tipos en los que había invertido antes (obliga a que existan nuevas filas).

  1. 2

DNI ->> Tipo, también es DM, ya que cada vez que el Cliente quiera invertir en otro Tipo diferente a los que ya tenía, le obligan a invertir en todas las empresas (en las que ya tiene inversiones) con ese Tipo. (Obliga a que se añada más de una fila)

  1. 3

DNI, Nombre, Tipo -> Cantidad es una DF, ya que los tres atributos de los que depende definen directamente su valor (Prohíbe filas)


2.3. b-

INSERT into INVIERTE values('00000003', 'Empresa 55', 12, 'bono2');

Esta sentencia demuestra que no se cumple DNI, Nombre, Tipo -> Cantidad

DNI NOMBREE CANTIDAD TIPO
00000003 Empresa 55 310000 bono1
00000003 Empresa 33 320000 bono2
00000003 Empresa 55 12 bono2

Esta tabla también demuestra el error en la dependencia DNI ->> Tipo, porque tendría que haber una fila con la empresa 33 y el bono 1.

INSERT into INVIERTE values('00000003', 'Empresa 44', 220000, 'bono4');
DNI NOMBREE CANTIDAD TIPO
00000003 Empresa 55 310000 bono1
00000003 Empresa 33 320000 bono2
00000003 Empresa 55 12 bono2
00000003 Empresa 44 220000 bono4

Demuestra un error en la dependencia DNI ->> Nombre, porque al insertar la Empresa44, debería haber añadido una fila por cada tipo que ya tenía antes.


2.3. c- Se arreglaría estableciendo como clave primaria DNI, nombre, tipo.


APARTADO 3


3.1- Para que no esté en la 1ª FN, permitiremos los atributos multivaluados, que pueden ser dirección y teléfono, en la misma columna.

DNI NOMBREC DIRECCION TELEFONO
00000001 Client A direc 11 {911111111111, 91111111112}
00000001 Client A {direc 11, direc 12, direc 13} 91111111112

3.2-Para que no esté en la segunda forma normal, habría que crear una DF parcial, es decir, que sus antecedentes no compongan la clave completa. Cualquier DF establecida en la tabla, debe cumplir que todos sus antecedentes sean CP (en este caso, la CP debería ser DNI, nombre, tipo).


En este ejemplo, existiría una DF, DNI->Tipo, siendo Clave DNI y NombreE.

DNI NOMBREE CANTIDAD TIPO
00000001 Empresa 44 21000 bonoA

El arreglo sería establecer como CP DNI, nombre, tipo.


3.3- Para que no esté en 3ª forma normal, debería existir una DF NombreE -> Cotización (siendo NombreE CP), y otra DF Cotización -> Capital, ya que la tercera forma normal intenta corregir las dependencias transitivas. Es decir, que existe una DF cuyo antecedente no es clave.

NOMBREE COTIZACION CAPITAL
Empresa 11 111111 110000
Empresa 22 222222 220000

3.4- Para que no esté en FNBC debería existir una DF TIPOT -> ORGANIZACIÓN

 NUMT TIPOT      ORGANIZACION

10000001 PISA MASTERUIN
30000002 VDK MASTERUIN
10000001 VDK MASTERUIN -> Esta fila sería incorrecta y me deja añadirla

Una posible solución sería establecer que la CP es NUMT y ORGANIZACIÓN, de esta manera no se pueden crear tuplas incorrectas.


APARTADO 4


4.1- Unir las dos tablas es ventajoso porque cada vez que queremos añadir una tarjeta a la BBDD pertenece a un cliente por lo cual siempre hay que actualizar dos tablas. Al unir las dos, solo necesitamos actualizar una.

No encontramos inconvenientes en ningún caso.


4.2- Se busca reducir el número de accesos para hacer consultas y actualizar tablas. Combatir las redundancias.

4.3- Para desnormalizar esta tabla eliminaríamos las tablas bibliotecario, estudiante y profesor y añadiríamos tres columnas nuevas a la tabla usuarios.

La primera sería ROL que solo puede tomar los valores {bibliotecario, estudiante, profesor}. La segunda columna la titulamos “Info_propia” que en el caso de los estudiantes es el código de expediente, en el de los profesores la dirección y en el de los bibliotecarios el número de personal. La tercera sería ubicación que en el caso de los estudiantes valdría null.

Habría que mantener como clave primaria el DNI. De esta manera tenemos a todos los usuarios en la misma tabla y reducimos el número de accesos a tablas en consultas y actualizaciones.

CREATE TABLE UsuarioDesnormalizado (
DNI CHAR(9) not null,
Nombre CHAR(50) not null,
Apellidos CHAR(50) not null,
Rol CHAR(50) not null,
Ubicacion CHAR(50),
PRIMARY KEY (DNI)
);


PARTE OPCIONAL

APARTADO 5

Tablas y claves

AUTOR – ID (PK)

BIBLIOTECARIO – DNI (PK) NUMERODEPERSONAL(CC), UBICACIÓN(FK, UBICACIÓN.NUMERODECENTRO)

COPIA – LIBRO(FK, LIBRO. ISBN) NUMERODECOPIA(PK)

ESAUTORDE – AUTOR(FK, AUTOR.ID) LIBRO(FK, LIBRO.ISBN)

ESTUDIANTE – DNI (PK), CODIGODEEXPEDIENTE(CC)

LIBRO – ISBN(PK)

MATERIAS – LIBRO(FK, LIBRO.ISBN)

MULTA – DNI(FK, ESTUDIANTE.DNI), DNI FECHADEMULTA(PK)

PRESTAMO – LIBRO(FK, LIBRO.ISBN) COPIA(FK, COPIA.NUMERODECOPIA) USUARIO(FK, ESTUDIANTE.DNI) USUARIOMULTADO(FK, MULTA.DNI) FECHADEMULTA(FK, MULTA.FECHADEMULTA)

PROFESORES – DNI(PK) UBICACIÓN(FK, UBICACIÓN.NUMERODECENTRO)

SIGNATURA – UBICACIÓN(FK, UBICACIÓN.NUMERODECENTRO) COPIA(FK, COPIA.NUMERODECOPIA) LIBRO(FK, LIBRO.ISBN) CODIGODELOCALIZACION(PK)

UBICACIÓN – NUMERODECENTRO(PK)

USUARIO – DNI(PK)


5.1-

Autor -> FNBC

Bibliotecario -> 3ªFN

Copia -> FNBC

Esautorde -> FNBC

Estudiante –> 3ªFN

Libro -> FNBC

Materias -> FNBC

Multa -> FNBC

Préstamo -> null

Profesores -> 2ªFN

Signatura -> 3ªFN

Ubicación -> FNBC

Usuario -> FNBC


5.2 – No es una BBDD de una calidad aceptable, ya que hay redundancias y se podría reducir el tiempo de acceso a datos. Debido a la tabla préstamo, en la que encontramos columnas que no deberían estar ahí, y atributos repetidos. Por ejemplo: fechamulta

5.3 – Para empezar, desnormalizaríamos los usuarios, aunando en la tabla usuario bibliotecario, estudiante y profesor, como ya se explicó en apartados anteriores.

Así como cambiar los valores de usuariomultado (cambiarlos exclusivamente a los valores S o N) y eliminar el atributo fechademulta, ya que este se puede extraer de la tabla multa a partir del dni del usuario si este está multado.