Procesamiento de base de datos: Fundamentos, Deseño e Implementación. Capítulo 8

Transcripción

1 Procesamiento de base de datos: Fundamentos, Deseño e Implementación Capítulo 8 Rediseño de la base de datos 8-1

2 Objetivos Comprender la necesidad de un nuevo diseño de la base de datos. Usar subconsultas relacionadas. Utilizar las palabras clave de SQL EXISTS y NOT EXISTS en subconsultas relacionadas. Comprender la ingeniería inversa. Utilizar gráficos de dependencia. Cambiar los nombres de tabla. Cambiar las columnas de la tabla. Cambiar la cardinalidad de relación. Cambiar las propiedades de la relación. Agregar y eliminar las relaciones. 8-2

3 Necesidad de rediseño de la base de datos Database redesign es necesaria: Para corregir errores cometidos durante el diseño de base de datos inicial. Para adaptar la base de datos a los cambios en los requisitos del sistema. Nuevos sistemas de información causan cambios en los requerimientos de los sistemas debido a que: cuando se instala un nuevo sistema, los usuarios suelen comportarse de diferente manera. Los usuarios se comporten en de diferente manera, quieren cambios en el sistema para dar cabida a sus nuevos comportamientos. 8-3

4 Subconsultas relacionadas Una correlated subquery se parece a una subconsulta regular. Una subconsulta regular puede procesarse desde abajo hacia arriba. Para una subconsulta correlacionada, el procesamiento está anidado, es decir, se utiliza una fila de una instrucción de consulta superior en comparación con las filas de una consulta de nivel inferior. 8-4

5 Subconsulta no correlacionadas Contiene dos tablas independientes en los niveles de la consulta. ARTIST en la consulta de alto nivel WORK en la subconsulta SELECT FROM WHERE A.Name ARTIST A A.Artist IN (SELECT W.ArtistID FROM WORK W WHERE W.Title = Blue Interior ); 8-5

6 Subconsulta correlacionada La siguiente es una subconsulta correlacionada. Contine las mismas tablas en ambos niveles de la consulta. SELECT W1.Title, W1.Copy FROM WORK W1 WHERE W1.Title IN (SELECT W2.Title FROM WORK W2 WHERE W1.Title = W2.Title AND W1.WorkID <> W2.WorkID); 8-6

7 Comprobación de dependencias funcionales La siguiente subconsulta correlacionada puede utilizarse para comprobar si las filas violan la dependencia funcional. Department BudgetCode SELECT FROM WHERE E1.Department, E1.BudgetCode EMPLOYEE E1 E1.Department IN (SELECT E2.Department FROM EMPLOYEE E2 WHERE E1.Department = E2.Department AND E1.BudgetCode <> E2.BudgetCode); 8-7

8 EXISTS y NOT EXISTS EXISTS y NOT EXISTS son formas especializadas de subconsultas relacionadas. Una condición EXISTS es cierta si cualquiera de las filas de la subconsulta cumple con las condiciones especificadas. Una condición NOT EXISTS es cierto sólo si todas las filas de la subconsulta no cumplen la condición especificada. El uso de un double NOT EXISTS puede utilizarse para buscar las filas que tienen alguna condición especificada para cada fila de una tabla 8-8

9 Comprobación de dependencias funcionales A continuación se presenta el código para comprobar el uso anterior de dependencia funcional de EXISTS : SELECT FROM WHERE E1.Department, E1.BudgetCode EMPLOYEE E1 EXISTS (SELECT * FROM EMPLOYEE E2 WHERE E1.Department = E2.Department AND E1.BudgetCode <> E2.BudgetCode); 8-9

10 NOT EXISTS Doble El siguiente código determina el nombre de cualquier ARTIST que es de interés a todos los CUSTOMER : SELECT FROM WHERE A.Name ARTIST AS A NOT EXISTS (SELECT C.CustomerID FROM CUSTOMER C WHERE NOT EXISTS (SELECT CI.CustomerID FROM CUSTOMER_artist_int CI WHERE C.CustomerID = CI.CustomerID AND A.ArtistID = CI.ArtistID)); 8-10

11 Rediseño de la base de datos Tres principios para el rediseño de la base de datos: Medir dos veces y cortar una vez: entender la estructura actual y el contenido de la base de datos antes de realizar cualquier cambio. Probar los nuevos cambios en una base de datos de prueba antes de realizar cambios reales. Crear una copia de seguridad backup de la base de datos operacional antes de realizar cualquier cambio a la estructura. Técnica: Reverse Engineering (RE) 8-11

12 Re-ingeniería inversa Reverse Engineering (RE) Reverse engineering (RE) es el proceso de lectura y producción de un modelo de un esquema de una base de datos. Un modelo de re-ingeniería inversa reverse engineered (RE) data model : Proporciona una base para comenzar el proyecto de rediseño de la base de datos. No es verdaderamente un concepto real, ni un esquema interno, ya que tiene características de ambos. Debe revisarse cuidadosamente porque casi siempre le falta información. 8-12

13 Modelo de datos de ingeniería inversa 8-13

14 Gráficos de dependencia Dependency Graphs Dependency graphs son los diagramas utilizados para are diagrams used to interpretar la dependencia de un elemento a otro. 8-14

15 Gráfico de dependencias compuesto [Incompleto] 8-15

16 Copia de seguridad de base de datos y bases de datos de prueba Antes de realizar cualquier cambio en una base de datos operativa: Debería hacerse una copia de seguridad completa de la base de datos operacional. Cualquier cambio propuesto debe ser probada cuidadosamente. Tres diferentes copias del esquema de base de datos utilizado en el proceso de rediseño: Una pequeña prueba base de datos para las pruebas iniciales. Una prueba grande de la base de datos para pruebas secundarias.. La base de datos operativa. 8-16

17 Cambios de rediseño de la base de datos Modificación de tablas y columnas Cambiar nombres de tabla Agregar y eliminar columnas de la tabla Cambio de tipo de datos o restricciones Agregar y eliminar las restricciones Cambio de las relaciones Cambio de cardinalidades Agregar y eliminar relaciones Agregar y quitar relación para denormalización 8-17

18 Cambiar nombres de tabla No hay ningún comando SQL-92 para cambiar un nombre de tabla. La tabla debe ser creado de nuevo con su nuevo nombre, probado, y se elimina la tabla anterior. Cambio de un nombre de tabla tiene un número sorprendente de las posibles consecuencias.. Por lo tanto, el uso de vistas definidas como alias de tabla es más apropiado. Sólo las vistas que definen los alias tendrían que modificarse cuando se cambia el nombre de la tabla de origen. 8-18

19 Agregar columnas Para agregar columnas nulas NULL a una tabla: ALTER TABLE WORK ADD COLUMN DateCreated Date NULL; Otras limitaciones de la columna, por ejemplo, DEFAULT or UNIQUE, se pueden ser incluidas con la definición de columna. DEFAULT recien agregados pueden ser aplicados a sólo nuevas filas, las filas existentes tienen valores nulos null. Tres pasos para agregar una columna NOT NULL : Agregue la columna como nula NULL. Agregar datos a cada fila. Alterar la restricción de la columna no nula NULL. 8-19

20 Colocar las columnas Para colocar las columnas no claves nonkey : ALTER TABLE WORK DROP COLUMN DateCreated; Para eliminar una columna de clave foránea, en primer lugar debe descartarse la restricción foreign key. Para colocar la clave primaria, primero deben eliminar todas las claves foráneas mediante la clave primaria; seguido eliminar la restricción de clave principal. 8-20

21 Cambio de tipo de datos o de restricciones Utilice el ALTER TABLE ALTER COLUMN para cambiar los tipos de datos y las limitaciones. Para algunos cambios, se perderán los datos o DBMS puede rechazar el cambio. Para cambiar una restricción de NULL a NOT NULL, todas las filas deben tener un primer valor. 8-21

22 Cambio de tipo de datos o de restricciones La conversión de tipo de datos más específicos, por ejemplo, la fecha, el dinero, y numéricos, a char o varchar suele tener éxito. Cambiar un tipo de datos char o varchar de un tipo más específico puede ser un problema. Ejemplo: ALTER TABLE ARTIST ALTER COLUMN Birthdate Numeric (4,0) NULL; 8-22

23 Adding and Dropping Constraints Utilice el ALTER TABLE ADD (DROP) CONSTRAINT para añadir (remove) restricciones. Ejemplo: ALTER TABLE ARTIST ADD CONSTRAINT NumericBirthYearCheck CHECK (Birthdate > 1900 and Birthdate < 2100); 8-23

24 Cambio de cardinalidad mínima En el lado de parent : Para cambiar de cero a uno, cambie la restricción de clave externa de NULL a NOT NULL. Sólo se puede hacer si todas las filas de la tabla tienen un valor. Para cambiar de uno a cero, cambie la restricción de clave externa de NOT NULL a NULL. En el lado de child : Añada (to change from zero to one) o colocar (to change from one to zero) active los desencadenantes que hacen cumplir la restricción. 8-24

25 Cambio de cardinalidad máxima: 1:1 to 1:N Si la clave foránea se encuentra en la tabla correcta, quite la restricción única en la columna de clave foránea. Si la clave foránea está en la tabla equivocada, mueva la clave foránea a la tabla correcta y no se de debe colocar una restricción única en la tabla. 8-25

26 Cambio de cardinalidad máxima : 1:1 to 1:N Example 8-26

27 Cambio de cardinalidad máxima : 1:N to N:M Build a new intersection table and move the key and foreign key values to the intersection table 8-27

28 Cambio de cardinalidad máxima: 1:N to N:M Example 8-28

29 Reducción de cardinalidad La reducción de la cardinalidad puede resultar en pérdida de datos. La reducción de N:M a 1:N: Crea una clave foránea en la tabla parent y mueve un valor de la tabla de intersección a esa clave foránea. La reducción de 1:N to 1:1: Elimina las entradas duplicadas en la clave foránea y entonces establezca una restriccción de inicidad en esa clave. 8-29

30 Agregar y eliminar las relaciones Agregar nuevas tablas y relaciones: Agregar las tablas y relaciones utilizando comandos CREATE TABLE con restricciones FOREIGN KEY. Si una tabla existente tiene una relación de child a la nueva tabla, agregar una restricción clave foránea FOREIGN KEY utilizando la tabla existente.. Eliminando las relaciones y tablas: Colocar las restricciones de clave externa y, a continuación, elimine las tablas. 8-30

31 Ingeniería hacia adelante Forward Engineering Forward engineering es el proceso de aplicar cambios de modelo de datos a una base de datos existente. Resultados de la ingeniería hacia adelante debe ser probado antes de utilizarlo en una base de datos operacionales. Algunas herramientas mostrarán el SQL que se ejecutará durante el proceso de ingeniería directa : Si es así, ese SQL debe ser cuidadosamente revisado. 8-31