PRÁCTICA B2. Definición y modificación de datos en SQL

Transcripción

1 3º Ingeniero Técnico en Informática de Sistemas Facultad de Informática Asignatura: Fundamentos de Bases de Datos Curso: 2007/08 PRÁCTICA B2. Definición y modificación de datos en SQL Objetivos Construir y ejecutar sentencias SQL de definición de datos (LDD), es decir, de creación, alteración y eliminación de los elementos que componen un esquema de base de datos, así como de definición de restricciones de integridad. Construir, depurar y ejecutar sentencias SQL de modificación de la información almacenada en una base de datos: inserción, actualización y borrado (LMD). Construir y ejecutar sentencias SQL de definición de restricciones de seguridad: concesión y revocación de privilegios de acceso, creación de roles, etc. Construir y ejecutar sentencias SQL de definición de estructuras de almacenamiento y de acceso para los elementos de un esquema de bases de datos. Contenidos La realización de esta práctica permitirá afianzar los conocimientos aprendidos en las clases de teoría acerca de las sentencias SQL de definición y manipulación de datos, de definición de restricciones de seguridad en el acceso a los datos, así como de creación de estructuras de almacenamiento y de acceso. Normas de realización Es necesario contestar los ejercicios en el orden indicado en el enunciado. Es posible que algún apartado necesite de más de una sentencia SQL para ser resuelto, en cuyo caso han de escribirse en el orden en el que se deben ejecutar para que funcionen correctamente. Si lo que se pide en un ejercicio se puede hacer directamente en Oracle (la versión 10g es la que utilizamos para realizar esta práctica y la siguiente), hay que hacerlo y con ello ya está resuelto el ejercicio. Sin embargo, si algún ejercicio no se puede hacer directamente en Oracle hay que... Justificar por qué no se puede hacer en Oracle. Indicar cómo se haría en el estándar SQL-92. Simularlo en Oracle (por ejemplo, con varios INSERT/UPDATE/DELETE ejecutados en cierto orden, etc.). Se debe proponer distintas soluciones de un ejercicio cuando haya lugar a ello. Es habitual que exista una solución que sólo use sentencias LMD (lenguaje de manipulación de datos) y otra solución que también use sentencias LDD (lenguaje de definición de datos). Es muy importante tener en cuenta que cualquier restricción de integridad (referencial, de dominio, de tabla, etc.) existente antes de un determinado ejercicio, debe seguir existiendo después de ejecutar el conjunto de sentencias que dan solución a dicho ejercicio. Debe justificarse adecuadamente toda decisión tomada a la hora de realizar cada apartado. Además, debe indicarse el efecto de cada sentencia sobre el esquema de base de datos. Durante la realización de la práctica en los laboratorios, la estructura y/o contenido de los elementos de base de datos (tablas, vistas, etc.) ha de ser creado, modificado o alterado en la cuenta Oracle de su grupo de prácticas (fbdsxxx). En el momento de la entrega del informe, el esquema de base de datos correspondiente a su grupo de prácticas debe haber sido creado, contener datos en las tablas y estar preparado para la ejecución correcta del segundo al último ejercicio. Práctica B2. Definición y modificación de datos en SQL - 1/6

2 Fecha de entrega Lunes, 17 de diciembre de 2007 Enunciado del caso práctico Concesionarios de Coches Se desea diseñar un esquema de bases de datos para la gestión de una red de concesionarios de coches de diversas marcas. La información que interesa recoger de cada concesionario es su nombre, dirección, teléfono y fecha de inauguración, así como el conjunto de vendedores empleados en el mismo. Cada vendedor sólo puede trabajar para un concesionario y se desea conocer su nombre, teléfono y, si lo tiene, quién es su jefe directo. Cada concesionario pertenece a una determinada marca de coches (Toyota, Opel, Seat, Ford, Volkswagen, Renault, etc.). De entre los concesionarios que representan a una misma marca se elige uno como concesionario principal. Cada marca comercializa sus propios modelos de coche. Cada modelo se caracteriza por un nombre y el precio de venta recomendado (pvr) por la marca para los coches de dicho modelo. Cada concesionario dispone de un catálogo en el que aparecen recogidos aquellos modelos con los que trabaja, que pueden ser todos o sólo algunos de los modelos de la marca a la que pertenece. Por supuesto, diferentes concesionarios (de la misma marca) pueden trabajar con el mismo modelo de coche. Un concesionario puede tener en su exposición varios coches disponibles para la venta. Los distintos coches de un mismo modelo se diferencian entre sí por un número (de hasta tres cifras), e interesa conocer su color, número de puertas y cilindrada. En cada operación de venta interesa anotar qué coche concreto es vendido, el cliente que lo adquiere y el vendedor del concesionario que ha conseguido la venta. De los clientes, que pueden ser de dos tipos: particular o empresa, se desea recoger un identificador (el nif o cif), el nombre, un teléfono y los 20 dígitos de su número de cuenta bancaria. También interesa anotar la matrícula asignada al coche, que sólo se conoce en el momento de su venta. Cada coche se vende una vez y, por supuesto, un mismo cliente puede comprar muchos coches, así como un vendedor puede participar en la venta de diversos coches. Como resultado de las etapas de diseño conceptual y diseño lógico de la base de datos, se ha identificado el siguiente conjunto de tablas (en orden alfabético y con las claves primarias subrayadas): CATALOGO ( concesionario, marca, modelo ); CLIENTE( identificador, tipo, nombre, telefono, cuenta ); COCHE ( marca, modelo, numero, color, puertas, cilindrada, matricula, concesionario ); CONCESIONARIO ( codigo, nombre, fecha_inauguracion, direccion, telefono, marca ); MARCA ( nombre, concesionario_principal ); MODELO ( marca, modelo, pvr); VENDEDOR( codigo, nombre, telefono, jefe, concesionario ); VENTA ( marca, modelo, coche, cliente, vendedor, fecha, precio ); Práctica B2. Definición y modificación de datos en SQL - 2/6

3 Ejercicios *Trate de ajustarse a las normas de realización indicadas en la primera página* Creación del esquema de base de datos e inserción de datos 1. Creación y carga de las tablas del esquema. Para ello se ha de seguir estos pasos: - Dibujar el esquema de base de datos utilizando una notación gráfica similar a la incluida en el enunciado de la práctica B1 de consultas. Se recomienda dibujar este esquema antes de intentar crear las tablas, para tener una visión clara de las relaciones existentes entre ellas (integridad referencial). - Crear las tablas (en el orden adecuado, véase nota abajo). Para ello, previamente hay que... Elegir el tipo de datos y longitud más adecuados para las columnas de las tablas. Deducir del enunciado las restricciones de integridad y darles un nombre adecuado: Columnas que no deben permitir nulos y columnas que sí pueden contener nulos. Nota: Como política general, ninguna columna ha de permitir nulos (NOT NULL), excepto aquellas para las que pueda deducirse del enunciado que sí pueden no contener ningún valor (NULL). Claves primarias (PRIMARY KEY). Claves alternativas (UNIQUE). Claves ajenas (FOREIGN KEY). - Para cada clave ajena, elegir y justificar las acciones de mantenimiento de la integridad referencial (ON DELETE... y ON UPDATE...) que se consideren más apropiadas. Valores por defecto (DEFAULT). Otras restricciones (CHECK). Nota: Siempre que sea posible, el CREATE TABLE de cada tabla debe incluir (además de las columnas, claro) sus restricciones de integridad de columna y de tabla. Sólo cuando esto no sea posible, se añadirán a posteriori dichas restricciones de integridad, con ALTER TABLE... - Insertar varias filas en cada tabla. Las inserciones hay que hacerlas en el orden adecuado de forma que no se violen las reglas de integridad referencial. Se valorará la cantidad y calidad del conjunto de filas insertadas en cada tabla. En cada INSERT debe indicarse la lista de nombres de columnas antes de la cláusula VALUES. - Crear en la BD los comentarios (COMMENT) de la tabla CLIENTE. - Crear en la BD los comentarios (COMMENT) de todas las columnas de la tabla CLIENTE. - Comprobar la creación correcta de los comentarios anteriores, mostrando por pantalla un par de SELECT sobre las vistas del diccionario de datos denominadas USER_TAB_COMMENTS y USER_COL_COMMENTS. Actualización de datos almacenados Importante: debe suponer que toda acción referencial de actualización para toda clave ajena del esquema de BD, ha sido especificada como ON UPDATE NO ACTION (en SQL-92), que corresponde a la opción por defecto en Oracle. Nota: No se puede usar tablas temporales intermedias, ni utilizar estructuras CASE ni DECODE. 2. Incrementar un 5% el precio recomendado (pvr) para todos los modelos de aquellas marcas con más de 3 modelos comercializados (ofertados, puestos a la venta). 3. Modificar (actualizar) el nombre de una marca. Dada la marca a, cambiar su nombre por un nuevo valor b inexistente hasta ese momento. Téngase en cuenta que dicha columna es la clave primaria de la tabla MARCA y es clave ajena en otras tablas. Práctica B2. Definición y modificación de datos en SQL - 3/6

4 4. Crear un nuevo concesionario como copia de otro existente. Esto es, dada la marca a, introducir en las tablas adecuadas un nuevo concesionario c (inexistente hasta este momento) como una copia del concesionario principal de la marca a. A continuación, hacer que el nuevo concesionario c sea ahora el concesionario principal de la marca a. 5. Mostrar por pantalla la clave primaria de los coches junto con su número de puertas. Intercambiar el número de puertas de los coches, de forma que los de 5 puertas pasen a tener 3 puertas y viceversa. Volver a mostrar los datos para comprobar que se han intercambiado. Por último, hacer ROLLBACK para dejar los datos como estaban al principio y comprobar que así ha sido. IMPORTANTE: En este ejercicio se supone que en el ejercicio 1 se ha definido una restricción de integridad (tipo check ) para que el campo puertas de la tabla COCHE sólo admita los valores 3 o 5. En el caso de que no se haya creado dicha restricción, hay que incluir la sentencia de creación al principio de este ejercicio 5. Eliminación de datos almacenados Importante: debe suponer que toda acción referencial de borrado para toda clave ajena del esquema de BD, ha sido especificada como ON DELETE NO ACTION (en SQL-92), que corresponde a la opción por defecto en Oracle. 6. Indique qué sentencias SQL sería necesario realizar, dentro de una misma transacción, para borrar todos los datos referentes a cierta marca. Intente resolver los problemas que puedan surgir con las referencias entre las tablas afectadas por la eliminación de datos. La solución debe ser válida tanto si se ha vendido algún coche de un modelo de dicha marca como si no. Alteración de la estructura del esquema de base de datos 7. Modificar la definición de la columna que almacena el número de puertas de los coches, para que su valor por defecto sea Establecer que la columna que almacena los teléfonos de los clientes debe, a partir de ahora, ser opcional, es decir, admitir NULL como valor. 9. Supuesta la existencia de una restricción de integridad sobre la columna que almacena el tipo de cliente, que limita su valor a particular y empresa (Nota: si no existe ya, debe crearse dicha restricción al principio de este ejercicio), alterar dicha restricción de forma que un organismo público pueda registrarse como cliente, esto es, que la columna admita también el valor org_publ. 10. Alterar la tabla que almacena las marcas para añadir una columna num_conces. A continuación rellenar dicha columna con el número actual de concesionarios que tiene cada marca. 11. Eliminar la columna num_conces de la tabla que almacena las marcas, de forma que dicha tabla quede tal y como estaba originalmente (en estructura, contenido y restricciones de integridad). 12. Crear una vista llamada VENTAS_MARCA que muestre para cada marca y modelo, cuántos coches se han vendido y la suma de sus precios de venta, por cada año y mes. La vista, por tanto, ha de tener las columnas marca, modelo, anno, mes, num_coches y suma_precios. A continuación modificar la vista VENTAS_MARCA, de forma que la columna suma_precios se vea incrementada con el 16% de IVA. Práctica B2. Definición y modificación de datos en SQL - 4/6

5 Restricciones de Integridad y de Seguridad 13. Restricciones de integridad adicionales. Verifique si el esquema lógico creado permite asegurar el cumplimiento de cada una de las restricciones mostradas a continuación. Si es así, indique cómo o por qué. Si no es así, escriba las sentencias SQL-92 necesarias para ello. RI1. Todas las marcas han de tener un concesionario principal y solamente uno. RI2. El concesionario principal de una marca ha de ser uno de entre los concesionarios que pertenecen a tal marca. RI3. Un vendedor sólo puede participar en las ventas de coches expuestos en el concesionario en el que trabaja. RI4. Un concesionario sólo puede trabajar con modelos de la marca a la que pertenece. RI5. Un concesionario no puede tener a la venta coches de modelos con los que no trabaja. RI6. Cada coche sólo puede ser vendido una vez. RI7. El precio de venta de un coche no puede superar un 10% al precio recomendado (pvr) por la marca. RI8. Al menos debe existir un vendedor que sea jefe de otros. 14. Reglas de seguridad. Utilice las sentencias adecuadas para conceder permiso a todos los usuarios (PUBLIC) para RS1. Consultar el nombre y teléfono de los clientes RS2. Introducir nuevos vendedores RS3. Modificar la cuenta bancaria y teléfono de los clientes RS4. Consultar la marca, modelo, matrícula y precio de venta de los coches vendidos RS5. Borrar vendedores A continuación, denegar (revocar), uno a uno, los permisos anteriores. Estructuras de Acceso 15. Crear índices que aceleren los accesos de aquellas consultas I1. que hagan JOIN (reunión) de las tablas CLIENTE y VENTA, I2. que hagan JOIN de las tablas CONCESIONARIO y MARCA, I3. que accedan a la tabla COCHE por la columna numero, y las que accedan por las columnas numero y modelo simultáneamente, y también las que accedan por las columnas numero, modelo y marca conjuntamente. I4. que accedan a la tabla CONCESIONARIO por la columna codigo o por la columna marca. Nota: Tenga en cuenta que Oracle crea automáticamente un índice para cada clave de cada tabla. Hay que crear el mínimo número de índices necesarios, y justificar las decisiones tomadas. Práctica B2. Definición y modificación de datos en SQL - 5/6

6 Documentación que se debe entregar La entrega se realizará mediante SUMA, antes de la fecha límite indicada en este enunciado. En el área privada ( Mis Contenidos ) de la asignatura, cada miembro de cada grupo creará una carpeta denominada practicas. Dentro de esta carpeta, creará una subcarpeta con el nombre b2. En esta carpeta (insistimos: todos los miembros de cada grupo) depositará el informe de realización de la práctica junto con el conjunto de guiones (scripts) SQL. El formato de estos ficheros será el siguiente: - Informe de la práctica. Documento llamado fbdsxxx-b2 (sustituyendo XXX por el nº de grupo asignado por el profesor). El fichero ha de tener formato/extensión.doc o.rtf. Las páginas han de estar numeradas. El documento deberá incluir Portada, que incluya: - asignatura, curso académico (2007/08) y convocatoria (junio, septiembre, febrero), - identificador y nombre de la práctica (PRÁCTICA B2. Definición y modificación de datos en SQL), - nombre del grupo de prácticas (fbdsxxx), - nombre y apellidos de cada componente del grupo, - dirección de correo electrónico de cada integrante del grupo de prácticas. Para cada uno de los ejercicios deberá aparecer lo siguiente: - Número de ejercicio y enunciado del ejercicio. - Comentarios y aclaraciones que se consideren necesarios. - Sentencias LDD y/o LMD. Deben aparecer en el mismo orden en el que habría que ejecutarlas. El texto ha de estar perfectamente sangrado y ser fácilmente legible. - Ejemplos que se consideren oportunos para comprobar el correcto funcionamiento del ejercicio. Se puede presentar varias soluciones alternativas de un mismo ejercicio. Puede indicarse la que se considera más adecuada. Es posible ayudarse del comando spool de SQL*Plus para la elaboración del informe. - Guiones SQL (scripts). Ha de crearse un guión (fichero de texto plano) por cada ejercicio, llamado b2-nn.sql (nn es el nº de ejercicio), que contendrá - Número de ejercicio. - Sentencias LDD y/o LMD. Deben aparecer en el mismo orden en el que habría que ejecutarlas. El texto ha de estar perfectamente sangrado y ser fácilmente legible. - Ejemplos que se consideren oportunos para comprobar el correcto funcionamiento del ejercicio. - NO DEBE APARECER el resultado de la ejecución de las sentencias. Criterios de evaluación Es obligatorio entregar, vía SUMA, tanto el informe de la práctica como todos los guiones (scripts SQL): no se corregirá la práctica si no se ha presentado la documentación completa. Es obligatorio presentar la solución de todos los ejercicios. La lectura del informe ha de ser suficiente para la comprensión total del trabajo realizado en la práctica (sin necesidad de recurrir a los guiones). Se valorará la inclusión de varias soluciones alternativas cuando haya lugar a ello, la justificación de las mismas y la presentación (estilo) de la práctica. Es obligatorio respetar estrictamente las normas y el formato de presentación de la documentación que se debe entregar, detallados en este documento Práctica B2. Definición y modificación de datos en SQL - 6/6