Fuente : Database Systems: a practical approach to design, implementation and management. 4º edición. T. Connolly, C. Begg. Objetivo : Determinar la forma en que se hará efectiva la persistencia de las relaciones y sus tuplas (datos) en almacenamiento secundario. 1. Analizar las transacciones de los usuarios para determinar las características que pueden afectar el rendimiento. 2. Seleccionar las organizaciones de archivos apropiadas para almacenar las relaciones, teniendo en cuenta el análisis de las transacciones. 3. Seleccionar los índices para mejorar el rendimiento con el objetivo de conseguir prestaciones aceptables. 4. Estimar los requisitos de espacio para realizar las optimizaciones de las transacciones a resolver El diseño físico de las estructuras de datos debe estar guiado por la naturaleza de los datos y por el uso que se pretende hacer de los mismos. Se debe comprender cuál es la carga de trabajo típica que manejará la aplicación. Durante la etapa de recopilación y análisis de requisitos puede que se hayan documentado requisitos relativos a la velocidad de ciertas transacciones o número de transacciones por segundo que se realizarán. Para poder determinar estas organizaciones óptimas de almacenamiento de datos es necesario realizar distintas actividades, éstas se detallan y describen a continuación: 1. Analizar las transacciones Objetivo : comprender la funcionalidad de las transacciones que se ejecutarán y analizar las más importantes. Esto significa identificar criterios de rendimiento, tales como: transacciones que se ejecutan con frecuencia y tendrán un impacto significativo en el rendimiento; operaciones críticas para el negocio; frecuencia diaria/semanal/etc.; horario u oportunidad de alta demanda sobre los datos (carga máxima). Utilice esta información para identificar fracciones de los datos que pueden causar problemas de rendimiento. Para seleccionar los archivos correspondientes sus organizaciones y sus índices, es necesario conocer ciertos datosl de las transacciones, tales como: las columnas que se actualizan en cada operación de actualización; criterios utilizados para filtrar los registros que se recuperan en una consulta, etc. Si no es posible analizar todas las transacciones, analizar las más 'importantes', para ello se pueden construirse: la matriz de referencias cruzadas transacción/relación, mostrando las relaciones a las que accede cada transacción, o el mapa de uso de transacciones, indicando cuáles relaciones se utilizan asiduamente. A. Establecer la correspondencia entre todas las rutas de las transacciones y las relaciones B. Determinar frecuencias: determinar cuáles son las relaciones a las que con mayor frecuencia acceden las transacciones. No olvide indicar, además: (a) las relaciones y columnas accedidas y tipo de acceso. (b) las columnas utilizadas en las condiciones de búsqueda. Página 1 de 8
(c) para consultas en más de una relación, las columnas involucradas en los ensambles. (d) frecuencia esperada de operación. (e) desempeño deseado de la transacción. 2. Seleccionar la organización de los archivos Objetivo: Determinar una organización de archivos eficiente para cada relación. Las organizaciones de archivo pueden ser: ordenadas (secuencia), desordenadas (Heap), dispersas (Hash), en árbol B+ con agrupamientos. A. Documentar la organización de archivos: se debe realizar la documentación total de la selección de organizaciones de archivos, complementadas con las justificaciones correspondientes a la selección realizada, el orden (si corresponde) y todo otro detalle que contribuya a definir una buena opción. En particular debe quedar indicado por qué se seleccionó una solución cuando habría otras posibles que se han descartado. 3. Seleccionar los índices Objetivo: determinar si la adición de índices permitirá mejorar las prestaciones del sistema. A. Especificar los índices: Un enfoque (no necesariamente el más adecuado para todos los casos) consiste en mantener registros desordenados y crear tantos índices secundarios como sea necesario. a. Se pueden ordenar registros mediante índices primarios o de agrupamiento. b. La columna para ordenar o agrupar debe ser la que se utiliza más a menudo para operaciones de ensamble o la que se utiliza más a menudo para acceder a los registros en una tabla por orden de esa columna. Cada tabla sólo puede tener un índice primario o un índice de agrupamiento. c. Equilibrar gastos indirectos en el mantenimiento y el uso de índices secundarios contra la mejora del rendimiento obtenida al recuperar los datos. Esto incluye: agregar un registro de índice para cada índice secundario cuando se inserta un registro; actualizar un índice secundario cuando se actualiza el registro correspondiente; aumento de espacio en disco necesario para almacenar el índice secundario. B. Documentar la organización de índices: Debe realizarse la documentación total de la selección de organizaciones de índices, complementadas con las justificaciones correspondientes a la selección realizada, el orden, sus características (primario, secundario, de agrupamiento) y todo otro detalle que contribuya a definir una buena opción. Ayudas: (1) no indexar relaciones pequeñas. (2) crear un índice sobre PK de una relación si no es una clave de la organización de los archivos. (3) Añadir índice secundario a cualquier columna que es frecuentemente utilizada como una clave de búsqueda. (4) Añadir índice secundario a una FK si se accede con frecuencia. (5) Añadir índice secundario en las columnas que participan en: criterios de selección o ensamble (navegación entre tablas). Página 2 de 8
(6) Agregar índice secundario en columnas que podrían resultar en consultas index-only. (7) evitar la indexación de una columna o tabla que se actualiza con frecuencia. (8) evitar la indexación de una columna si la consulta recuperará una proporción significativa de los registros de la tabla. (9) evitar la indexación de las columnas que consisten en largas cadenas de caracteres. 4. Estimar los requisitos de espacio en disco Objetivo: comprender la funcionalidad de las transacciones que se ejecutarán y analizar las más importantes El diseñador tiene que estimar la cantidad de espacio en disco necesario para almacenar el SA+I en almacenamiento secundario. En general, la estimación se basa en el tamaño de cada tupla y el número de tuplas en cada relación. Debe incluirse en este análisis el tamaño estimado de los índices. Puede considerarse un tamaño máximo, pero también puede ser útil estimar cómo crecerá la relación y los índices y modificar el tamaño resultante según este factor de crecimiento para determinar el tamaño potencial en el futuro. 5. Considerar la posibilidad de utilizar recursos sintácticos adicionales Objetivo: refinar la solución obtenida a los fines de mejorar el desempeño global del sistema. Puede refinarse la solución obtenida utilizando uno o más de los siguientes recursos: desnormalización, fragmentación de relaciones y optimización. Página 3 de 8
Desarrollo de una Solución para un SA+I Considere el siguiente Diagrama de Entidades y Relaciones (DERExt) que modela la información referida a una empresa que fabrica productos a partir de partes provistas por diferentes proveedores y de clientes que solicitan comprar los diferentes productos. El esquema relacional que se deriva del DERExt de la figura anterior es el siguiente: CLIENTE [ IdCliente, Apellido,Nombre,Calle,Puerta,Ciudad] ORDEN_COMPRA [ NroOrdenCompra, Fecha, IdCliente] PRODUCTO [ CodProducto, Descripcion] ENVIO [ NroEnvio, Fecha, IdProveedor] PROVEEDOR [ IdProveedor, NombreComercial, Apellido, Nombre, e_mail] PARTE [ CodParte, Descripcion] usado_en [ CodParte,CodProducto ] incluye [ NroEnvio, CodParte, cantidad] Página 4 de 8
provee [ IdProveedor, CodParte ] requiere [ CodProducto, NroOrdenCompra, cantidad] Las RIRs (Restricciones de Integridad Referencial) que completan el esquema son las siguientes: usado_en(codparte) << PARTE(CodParte) usado_en(codproducto) << PRODUCTO(CodProducto) ENVIO(NroEnvio) << PROVEEDOR(IdProveedor) incluye(nroenvio) << ENVIO(NroEnvio) incluye(codparte) << PARTE(CodParte) provee(idproveedor) << PROVEEDOR(IdProveedor) provee(codparte) << PARTE(CodParte) requiere(codproducto) << PRODUCTO(CodProducto) requiere(nroordencompra) << ORDEN_COMPRA(NroOrdenCompra) solicita(nroordencompra) << ORDEN_COMPRA(NroOrdenCompra) Transacciones Se detalla a continuación una lista de posibles servicios. 1. Obtener los datos completos de las partes que son usadas en un producto dado por su CodProducto. 2. Obtener los CodProducto y descripción de todos los productos que usan una parte dada por su CodParte, incluyendo la descripción de la parte. 3. Obtener los datos completos de los envíos realizados a un proveedor dado el IdProveedor. 4. Obtener los datos completos de todos los productos que han sido comprados este año. 5. Verificar que las partes usadas en un producto, estén incluidas entre las que son provistas por algún proveedor. 6. Obtener el listado en orden alfabético de los clientes 7. Obtener el listado de los proveedores ordenado alfabéticamente por el nombre comercial. 8. Altas, bajas y cambios en usado_en 9. Altas, bajas y cambios en ORDEN_COMPRA 10. Altas, bajas y cambios en ENVIO Página 5 de 8
1. Análisis de las transacciones A. Se establece en el gráfico la correspondencia entre las rutas de las transacciones y las relaciones detalladas anteriormente en el esquema relacional. Página 6 de 8
NOTA: El objetivo de incluir un conjunto extenso de transacciones es para utilizarlo como banco de prueba construyendo subconjuntos de 2 o 3 transacciones que se analizarán conjuntamente para elaborar un SA+I que permita resolver eficientemente los servicios considerados. De igual manera, se puede realizar el análisis probando con diferentes juegos de frecuencias para cada transacción. B. A continuación se detalla la Matriz de Referencias Cruzadas para la mayoría de las transacciones indicadas en el mapa. No se han incluído en ésta las relaciones que involucran a las transacciones T8 a T10 inclusive NOTA: Se seleccionará un subconjunto de transacciones para resolver la organización de archivos e índices en clase. Otros casos se dejan como material de práctica para el alumno. Página 7 de 8
Página 8 de 8