DISEÑO FÍSICO Especificación de estructuras de almacenamiento internas y caminos de acceso específicos para que las diversas aplicaciones que accedan a.

Presentación del tema: "DISEÑO FÍSICO Especificación de estructuras de almacenamiento internas y caminos de acceso específicos para que las diversas aplicaciones que accedan a."— Transcripción de la presentación:

1 DISEÑO FÍSICO Especificación de estructuras de almacenamiento internas y caminos de acceso específicos para que las diversas aplicaciones que accedan a la BD tengan un buen rendimiento Cada SGBD ofrece varias opciones: Diferentes tipos de ÍNDICES Agrupamiento de registros (de distinto tipo) relacionados en los mismos bloques de disco (CLUSTER de ficheros) Distintos tipos de técnicas de dispersión (HASHING) Diferentes valores para los parámetros físicos (tamaño de bloque, de buffers, ...) ... El diseño físico es muy dependiente del SGBD comercial seleccionado Una vez elegido el SGBD, el Diseño Físico consiste en la elección e implementación de las estructuras más apropiadas para los archivos de la BD, entre las opciones que ofrece el SGBD Diseñar e implementar los mecanismos de seguridad : vistas de usuario y reglas de acceso (privilegios/roles) INTRODUCCIÓN Una BD física es una colección de registros interrelacionados de diferentes tipos, posiblemente incluyendo una colección de archivos interrelacionados. El DF de BD es el proceso de elegir estructuras de almacenamiento y caminos de acceso específicos para que los archivos de la base de datos tengan un buen rendimiento con las diferentes aplicaciones de la BD. Las transacciones (o aplicaciones) de consulta y actualización se hacen eficientes mediante la implementación de diversos métodos de acceso como parte del sistema de gestión de BD. Una vez seleccionado el SGBD específico, el proceso de DF se reduce a elegir las estructuras más apropiadas para la BD entre las opciones que ofrece ese SGBD. No existe un método formal para diseño físico --> muy dependiente del producto comercial concreto. Diferentes tipos de ÍNDICES Agrupamiento de registros (de distinto tipo) relacionados en los mismos bloques de disco (CLUSTER de ficheros) Distintos tipos de técnicas de dispersión (HASHING) Diferentes valores para los parámetros físicos (tamaño de bloque, de buffers, ...) ...

2 D.FÍSICO: OBJETIVOS CRITERIOS PARA ELEGIR OPCIONES DE DISEÑO FÍSICO (~OBJETIVOS) TIEMPO DE RESPUESTA (debe minimizarse) Tiempo entre la introducción de una transacción de BD y la obtención de respuesta Depende de... TIEMPO DE ACCESO A LA BASE DE DATOS (bajo el control del SGBD) para obtener los datos que T necesita CARGA DEL SISTEMA, PLANIFICACIÓN DE TAREAS DEL SO, RETRASOS DE COMUNICACIÓN (fuera del control del SGBD) APROVECHAMIENTO DEL ESPACIO (debe optimizarse) Cantidad de espacio ocupado por archivos de la BD y sus estructuras de acceso PRODUCTIVIDAD DE LAS TRANSACCIONES (debe maximizarse) Número promedio de transacciones que el SBD puede procesar por minuto Parámetro crítico de los sistemas de procesamiento masivo de transacciones Debe medirse en “condiciones pico” del sistema Objetivos: Disminuir tiempos de respuesta: tiempo entre introducción de transacción y obtención de respuesta. Un aspecto que influye mucho en el tiempo de respuesta es el tiempo de acceso a la BD para obtener la información requerida por la transacción. Minimizar espacio de almacenamiento. Optimizar la productividad de las transacciones: número promedio de transacciones que el sistema de BD puede procesar por minuto. Parámetro crítico en reservas en líneas aéreas o bancos. Se mide en condiciones pico del sistema.

3 D.FÍSICO: OBJETIVOS Especificar LÍMITES PROMEDIO y del PEOR DE LOS CASOS de cada parámetro como parte de los REQUERIMIENTOS de RENDIMIENTO del Sistema. Utilizar técnicas analíticas o experimentales (prototipos, simulación) para ESTIMAR valores promedio y del peor de los casos suponiendo diferentes decisiones de diseño físico, para ver si se satisfacen los requerimientos de rendimiento especificados El rendimiento depende del TAMAÑO y NÚMERO de REGISTROS en los ficheros  * estimar estos parámetros para cada fichero * estimar también “cómo y cuánto va a crecer” (en tamaño de registro, o en número de registros) Estimar PATRONES DE ACTUALIZACIÓN y OBTENCIÓN de datos para cada fichero, considerando TODAS las TRANSACCIONES Normalmente se especifican límites promedio y del peor de los casos para estos parámetros como parte de los requerimientos del sistema. El rendimiento dependerá del tamaño y número de registros que contienen los archivos, por lo que se debe estimar estos parámetros por cada archivo, así como la estimación de crecimiento de los mismos. También se deben estimar los patrones de actualización y recuperación de datos a partir de todas las transacciones.

4 ESTRUCTURAS DE ALMACENAMIENTO Y CAMINOS DE ACCESO
D.FÍSICO: OBJETIVOS DISEÑO FÍSICO ESTRUCTURAS DE ALMACENAMIENTO Y CAMINOS DE ACCESO IMPLEMENTACIÓN inicial El resultado de la fase de DF es una determinación inicial de las estructuras de almacenamiento y los caminos de acceso para los archivos de la BD. Casi siempre es necesario afinar (tuning) el diseño sobre la base del rendimiento observado después de la implementación del sistema BD

5 Diseño FÍSICO Muchos sistemas incluyen UTILERÍAS DE SUPERVISIÓN que obtiene ESTADÍSTICAS DE RENDIMIENTO Nº de INVOCACIONES de TRANSACCIONES y/o CONSULTAS PREDEFINIDAS, Actividades de Entrada/Salida para cada fichero, Nº de bloques (páginas) por fichero, Nº de entradas por índice, Frecuencias de UTILIZACIÓN de índices, ... Cambios en Requerimientos del Sistema de BD (Nuevas Consultas o Transacciones, ...)  Reorganizar la BD: Creación de nuevos índices, o Modificación de métodos de acceso, ... optimizador: decisión final sobre el camino de acceso. Pero es el diseñador el que puede especificar los mecanismos de acceso que dispondrá el optimizador. Para asegurar que el optimizador dispone de eficientes métodos de acceso: a. Conocer los mecanismos de acceso soportados por el SGBD. b. Evaluar las circunstancias bajo las que el DBMS utiliza el mecanismo de acceso. c. Concentrarse sobre las solicitudes de procesamiento más críticas. La mayoría de los sistemas cuentan con una serie de utilidades (utilerías) de supervisión que reúnen datos estadísticos de rendimiento, los cuales se conservan en el catálogo del sistema para su análisis posterior: número de invocaciones a transacciones o consultas predefinidas, actividad de Entrada/Salida, frecuencia de utilización de índices,... Al cambiar los requerimientos del sistema de BD suele ser necesaria la reorganización de la BD mediante la construcción de nuevos índices o la modificación de los métodos de acceso primarios. Los usuarios operan con el SGBD mediante SQL  los SGBD no permiten que el usuario especifique explícitamente el mecanismo / camino de acceso (deliberadamente ocultados). La elección la realiza el optimizador, pieza de SW “inteligente” que analiza varias formas de desarrollar los pasos necesarios para satisfacer una consulta. Selecciona lo que cree que es un método óptimo  evalúa un conjunto de alternativas de acceso basándose en tiempo de CPU estimado, número de operaciones de E/S. (EXPLAIN PLAN Oracle) Estimaciones: estudio de estadísticas (catálogo) acerca de número de tuplas, secuencia de tuplas, índices, hashing disponible,... El optimizador efectúa la decisión final sobre el camino de acceso. Pero es el diseñador el que puede especificar los mecanismos de acceso que dispondrá el optimizador. Para asegurar que el optimizador dispone de eficientes métodos de acceso: a. Conocer los mecanismos de acceso soportados por el SGBD. b. Evaluar las circunstancias bajo las que el DBMS utiliza el mecanismo de acceso. c. Concentrarse sobre las solicitudes de procesamiento más críticas. a. y b.  [Ceri, 83] “ el problema de diseño físico para el administrador de la BD consiste en proveer un conjunto eficiente de estructuras de acceso de modo que el optimizador pueda tomar las mejores decisiones”. c.  Distintos estudios muestran que del orden del 80% al 90% de las manipulaciones [procesamiento] sobre la BD son realizadas únicamente por un 10% al 20% de las aplicaciones [consultas y transacciones]. [Regla del 80-20]

6 FACTORES A CONSIDERAR EN EL D.FÍSICO
Factores que afectan al rendimiento de las aplicaciones (transacciones y consultas) Objetivo del DISEÑO FÍSICO ESTRUCTURACIÓN ADECUADA de datos en el ALMACENAMIENTO de tal forma que GARANTICE un BUEN RENDIMIENTO de las aplicaciones Pero para un Esquema Conceptual podemos tener diversos Esquemas Físicos posibles en un mismo SGBD: ¿Cuál es el más apropiado? ¿en base a qué podemos decidirnos por uno u otro? Imposible analizar el RENDIMIENTO ni TOMAR DECISIONES DE DISEÑO sin saber QUÉ USO SE LE VA A DAR A LA BASE DE DATOS Consultas/Transacciones Frecuencia (esperada) de Consultas y Transacciones Restricciones de Tiempo (especiales) de Consultas y Transacciones Frecuencia (esperada) de operaciones de Actualización de la BD Factores a considerar en el DF de BD: El DF es una actividad en la que el objetivo no sólo es lograr la estructuración adecuada de los datos en el almacenamiento, sino hacerlo de manera que se garantice un rendimiento óptimo. Para un esquema conceptual dado, existen muchas alternativas de diseño físico en un SGBD particular. No es posible tomar decisiones de diseño físico ni realizar análisis de rendimiento antes de conocer las consultas, transacciones y aplicaciones que se piensa ejecutar en el sistema de BD: frecuencias de invocación esperadas, restricciones de tiempo y frecuencia esperada de actualización.

7 FACTORES A CONSIDERAR EN EL D.FÍSICO
1. ANÁLISIS DE CONSULTAS Y TRANSACCIONES Definir (alto nivel) transacciones y consultas que se espera ejecutar en la BD PARA CADA CONSULTA... TABLAS (FICHEROS) a los que accede CAMPOS sobre los que se especifica alguna CONDICIÓN DE SELECCIÓN  CAMPOS sobre los que se especifica alguna CONDICIÓN DE REUNIÓN o de ENLACE de REGISTROS de diferente tipo  CAMPOS cuyos valores obtiene la consulta PARA CADA TRANSACCIÓN y operación de ACTUALIZACIÓN... TABLAS (FICHEROS) que actualiza Operación que realiza en cada fichero (INSERCIÓN, MODIFICACIÓN, ELIMINACIÓN) CAMPOS sobre los que se especifica alguna CONDICIÓN DE SELECCIÓN para las modificaciones y borrados  CAMPOS actualizados (por una operación de modificación)  () Candidatos para definir ESTRUCTURAS DE ACCESO sobre ellos () Candidatos para EVITAR definir ESTRUCTURAS DE ACCESO sobre ellos 1. Análisis de consultas y transacciones. Para cada consulta deberemos especificar: a) Tablas a las que tendrá acceso la consulta. b) Atributos sobre los que se especificarán cualesquier condiciones de selección incluidas en la consulta. c) Atributos sobre los cuales se especificarán condiciones de reunión o condiciones para enlazar múltiples tablas incluidas en la consulta. d) Los atributos cuyos valores obtendrá la consulta. (b) y (c)  candidatos para la definición de estructuras de acceso Para cada transacción o actualización deberemos especificar: a) Las tablas que se actualizarán. b) El tipo de operación de actualización (inserción, borrado, modificación). c) Los atributos sobre los que se especificarán condiciones de selección para una operación de eliminación o modificación. d) Los campos cuyos valores alterará una operación de modificación. (c)candidatos para definición de estructuras de acceso. (d) candidatos a evitar estructuras de acceso, ya que su modificación requeriría la actualización de dichas estructuras.

8 FACTORES A CONSIDERAR EN EL D.FÍSICO
2. ANÁLISIS DE FRECUENCIA ESPERADA DE INVOCACIÓN DE CONSULTAS Y TRANSACCIONES (tasas o velocidades de invocación) Datos de FRECUENCIAS de cada CONSULTA y TRANSACCIÓN Información sobre los CAMPOS (de selección y reunión) en cada CONSULTA y TRANSACCIÓN FRECUENCIA ESPERADA DE USO DE CADA CAMPO (de selección y reunión) --considerando TODAS las CONSULTAS y TRANSACCIONES-- 2. Análisis de la frecuencia esperada de invocación de consultas y transacciones. Esta información de frecuencias junto con la información recabada sobre los campos de cada consulta o transacción servirá para compilar una lista colectiva de frecuencia de uso esperada. Se expresa como la frecuencia esperada de uso de cada campo de selección o reunión, considerando todas las consultas y transacciones. En general, cuando el volumen de procesamiento es elevado se aplica la regla informal del Por tanto, en situaciones prácticas nunca es necesario recabar datos estadísticos y tasas de invocación exhaustivas: basta con determinar alrededor del 20% de ellas que comprende las más importantes. Si el volumen de procesamiento es elevado, aplicar la regla informal del 80-20  NO es necesario SUPERVISAR TODAS las Consultas y Transacciones para recoger Estadísticas y Tasas de Invocación, sino que BASTA con hacerlo con un 20% de ellas (las que realizan el 80% del procesamiento)

9 FACTORES A CONSIDERAR EN EL D.FÍSICO
3. ANÁLISIS DE RESTRICCIONES DE TIEMPO SOBRE CONSULTAS Y TRANSACCIONES “T debe TERMINAR ANTES de 6 segundos en el 95% de las veces que sea invocada y NUNCA debe DURAR más de 25 segundos” Restricciones de Tiempo  ASIGNACIÓN DE PRIORIDADES ADICIONALES a los campos candidatos para ESTRUCTURAS DE ACCESO Un campo de selección utilizado por T será candidato con mayor prioridad para estructura de acceso que otros 4. ANÁLISIS DE FRECUENCIA ESPERADA DE OPERACIONES DE ACTUALIZACIÓN Los ficheros que se modifican mucho deben tener el MÍNIMO posible de ESTRUCTURAS DE ACCESO Actualizar el fichero (inserciones, eliminaciones, modificaciones)  Actualizar los caminos de acceso  más lentas las operaciones de actualización 3. Análisis de restricciones de tiempo sobre consultas y transacciones. Las consideraciones de rendimiento muy exigentes pueden servir para asignar prioridades adicionales a los campos que son candidatos para caminos de acceso. (Ej. transacción terminada antes de 5 seg. en el 95% de sus invocaciones, con máximo de 20 seg.). 4. Análisis de frecuencias esperadas de operaciones de actualización. Se debe de especificar el mínimo posible de caminos de acceso para los archivos que se actualizan con frecuencia, porque la actualización de los caminos de acceso hace más lentas las operaciones.

10 PROCESO DE DISEÑO FÍSICO
ANÁLISIS DE TRANSACCIONES Y CONSULTAS SOBRE LOS DATOS ESTUDIO DE ALTERNATIVAS OFRECIDAS POR EL SGBD DECISIONES DE DISEÑO FÍSICO PAUTAS DE DISEÑO FÍSICO ESTRUCTURAS DE ALMACENAMIENTO Y CAMINOS DE ACCESO AFINAMIENTO (TUNING) * BAJO RENDIMIENTO * NO CUMPLIMIENTO DE REQUERIMIENTOS DEL SISTEMA Una vez compilada la información anterior, podemos abordar las decisiones de DF. Rara vez se conocen todas las consultas y transacciones en el momento en que se hace el DF: normalmente surgen nuevas aplicaciones que obligan a especificar nuevas consultas y transacciones. También podremos encontrarnos con transacciones o consultas que no cumplen los requerimientos especificados.  Proceso de afinación o tuning del DF: se requerirán modificaciones del diseño físico original. IMPLEMENTACIÓN NUEVAS CONSULTAS Y TRANSACCIONES BD SUPERVISIÓN DEL RENDIMIENTO

11 PAUTAS DE DISEÑO FÍSICO DE BD’s RELACIONALES
 ELECCIÓN DE ESTRUCTURAS DE ALMACENAMIENTO Y CAMINOS DE ACCESO La mayoría de los SGBD representan cada RELACIÓN BASE como un FICHERO Es necesario especificar... Tipo de fichero,Tipos de estructuras de acceso Técnicas de exploración (scan) Técnicas de índices (index) Técnicas de dispersión (hash) Técnicas de agrupamiento(cluster)  TÉCNICAS PARA ACELERAR la operación de EQUIRREUNIÓN y/o de REUNIÓN NATURAL Técnicas de Agrupamiento de 2 o más tablas (Clusters) Desnormalización, por razones de eficiencia

12 EXPLORACIÓN Mecanismo de acceso por defecto (tabla desordenada).
Ineficiente si: Se inspeccionan muchas tuplas y se selecciona un pequeño porcentaje. Eficiente: Sobre tablas pequeñas e inspeccionadas mediante pocas E/S (factor de bloqueo). Alto porcentaje de seleccionadas  20%. Otros mecanismos de acceso son demasiado costosos. Como incrementar el porcentaje de tuplas recuperadas: limitando el alcance del examen a un conjunto de tuplas que contengan todas las especificadas (selección) y pocas no seleccionadas (rango de valores). Tabla de agrupación (clustered table): tuplas almacenadas en la secuencia de valores para un conjunto específico de columnas (Tabla ordenada). Supone mecanismo de acceso complementario que proporcione acceso directo a la primera tupla que satisfaga la condición de búsqueda (p.e. índice o hashing). Particionamiento horizontal de acuerdo a algún criterio de selección. Afinamiento (tuning): Utilizar dispositivos de alta velocidad para tablas frecuentemente examinadas. Especificar número y tamaño apropiado de buffers. Técnicas de exploración (Scanning). Mecanismo de acceso por defecto. Ineficiente: Se inspeccionan muchas tuplas y se selecciona un pequeño porcentaje. Eficiente: Sobre tablas pequeñas e inspeccionadas mediante pocas E/S (factor de bloqueo). Alto porcentaje de seleccionadas  20%. Otros mecanismos de acceso son demasiado costosos. En algunos productos puede ser muy eficiente: buen factor de bloqueo, procesamiento paralelo. Como incrementar el porcentaje de tuplas recuperadas: limitando el alcance del examen a un conjunto de tuplas que contengan todas las especificadas (selección) y pocas no seleccionadas (rango de valores).  Tabla de agrupación (clustered table): tuplas almacenadas en la secuencia de valores para un conjunto específico de columnas. Supone un mecanismo de acceso complementario que proporcione acceso directo a la primera tupla que satisfaga la condición de búsqueda (p.e. índice o hashing). Afinamiento (tuning): Utilizar dispositivos de alta velocidad para tablas (o partes) frecuentemente examinadas. Especificar número y tamaño apropiado de buffers (algunos sistemas permiten especificar diferentes parámetros de buffer para cada tabla o consulta).

13 AGRUPAMIENTO (Cluster)
Almacenamiento de tuplas en una secuencia predeterminada basada en los valores de una o más columnas (cluster key) Agrupar: tablas medio-grandes ( 6 bloques físicos) que son frecuentemente (a) ordenadas sobre esa secuencia, (b) ó accedidas sobre criterios de selección que involucran un rango de valores sobre una columna o conjuntos de columnas, (c) ó procesadas de forma secuencial en esa secuencia, (d) y que no son frecuentemente actualizadas (d1) mediante inserciones o borrados de tuplas (d2) ó modificaciones de los valores que determinan el agrupamiento (cluster). ¿Sobre qué columnas?: Que participen en ORDER BY, GROUP BY, UNION, DISTINCT y otras operaciones que impliquen ordenación. Columnas de reunión (JOINS de clave primaria + clave ajena). Selección sobre rango de valores. Agrupar: tablas medio-grandes ( 6 bloques físicos) que son frecuentemente (a) ordenadas sobre esa secuencia, (b) ó accedidas sobre criterios de selección que involucran un rango de valores sobre una columna o conjuntos de columnas, (c) ó procesadas de forma secuencial en esa secuencia, (d) y que no son frecuentemente actualizadas (d1) mediante inserciones o borrados de tuplas (d2) ó modificaciones de los valores que determinan el agrupamiento (cluster). ¿Sobre qué columnas?: Que participen en ORDER BY, GROUP BY, UNION, DISTINCT y otras operaciones que impliquen ordenación. Columnas de reunión (JOINS de clave primaria + clave ajena). Selección sobre rango de valores. [ En ORACLE, debe crearse un índice de agrupamiento (cluster index) antes que cualquier sentencia DML (incluyendo INSERT y SELECT) puedan ser ejecutadas contra las tablas de agrupamiento (clustered tables). Un cluster index es diferente a un índice de tabla (table index) en cuanto que: Las claves de cluster nulas tienen una entrada en el cluster index. Las entradas del índice apuntan al primer bloque en la secuencia para un valor de clave de cluster dado. Un cluster index contiene una entrada por valor de clave de cluster (cluster key value), no una entrada por tupla de cluster. La ausencia de un índice de tabla no afecta a los usuarios, pero los datos del agrupamiento no pueden ser accedidos a menos que exista un cluster index. ]

14 ÍNDICES Son el mecanismo de acceso más dinámico: se pueden añadir, suprimir, redefinir índices de forma más fácil que cambiar una secuencia de cluster, redefinir una clave de dispersión o cambiar cualquier otro parámetro que afecte al almacenamiento físico de la BD.  se puede posponer la especificación de índices para el final del proceso de diseño e incluso después de la implementación inicial de la BD. Estructura común a muchos SGBD: B-trees  soporta bien diferentes tipos de consultas (por rango, valores extremos MIN-MAX, ...), inserciones frecuentes, ... Pueden ser usados para: Evitar el examen de tabla completa (Full table scan) (se utiliza el índice para realizar el examen)  para ser útil: suma de E/S a índice + E/S a tabla < E/S a tabla. Limitar el alcance del examen a tabla: cluster index, ordenación. Evitar una ordenación. Evitar el acceso a las tablas para determinadas consultas. INDICES. Virtualmente, todos los productos el acceso mediante índices (múltiples por tabla normalmente). Son el mecanismo de acceso más dinámico: se puede añadir, suprimir, redefinir índices de forma más fácil que cambiar una secuencia de cluster, redefinir una clave de hash o cambiar cualquier otro parámetro que afecte al almacenamiento físico de la BD.  se puede posponer la especificación de índices para el final del proceso de diseño e incluso después de la implementación inicial de la BD. Estructura común a muchos SGBD: B-trees  soporta bien diferentes tipos de consultas (por rango, valores extremos MIN-MAX, ...), inserciones frecuentes, ... Pueden ser usados para: Evitar el examen (scan) de tabla completa (se utiliza el índice para realizar el examen)  para ser útil, suma de E/S a índice + E/S a tabla < E/S a tabla. Limitar el alcance del examen a tabla: cluster index, ordenación. Evitar una ordenación. Evitar el acceso a las tablas para determinadas consultas. Nota: Implícitamente se suelen crear índices sobre las columnas que componen la clave primaria (PRIMARY KEY) o claves candidatas o de valores únicos (UNIQUE). Estos índices son los más selectivos y efectivos en la optimización del rendimiento.

15 ÍNDICES Conviene UTILIZAR índices...
sobre tablas medianas/grandes (ocupan gran cantidad de espacio) para facilitar el acceso a pequeños porcentajes del total de tuplas (≤20%) seleccionadas y para evitar... el recorrido de la tabla completa el acceso a tablas para consultas que incluyen un pequeño subconjunto de columnas (gracias a los índices compuestos) PERSONA(ssnum, apellido, nombre, edad, telef) CREATE INDEX idx_perso ON PERSONA(apellido, nombre) la ordenación de las tuplas de la tabla (ORDER BY, GROUP BY, UNION, DISTINCT, JOIN, ...) el acceso a ficheros para determinadas consultas (EXISTS, IN, ...) Crearlos sobre columnas ... que suelen aparecer en cláusulas WHERE, order by, ... (ordenación) que suelen ser atributos de reunión de varias tablas (p.ej. claves ajenas) con gran variedad de valores (mayor discriminación en las búsquedas) a) En general, se construye índice sobre tablas medianas - grandes, para facilitar el acceso a porcentajes pequeños de tuplas (20%) seleccionadas, o evitar acceso a tablas para consultas que involucren un pequeño subconjunto de columnas (índices compuestos). b) Indices ordenados: facilitan el acceso secuencial / ordenado (la mayor parte de los productos sólo soportan índices ordenados, ASC por defecto) (order by, group by, union, distinct, joins  pueden requerir ordenación). NOTA: c) Casi todos los SGBD requieren la creación de un índice sobre la clave de cluster (ORACLE, INFORMIX, ...)  cluster index. Los índices ordenados “normales” sirven a los mismos propósitos pero se puede crear más de uno sobre cada tabla o cluster  seleccionar el más crítico como cluster index. d) Si creamos un cluster sobre dos o más tablas, cuando el criterio de selección involucre solo a una de las tablas del cluster, el procedimiento será ineficiente.  podemos crear índices sobre cada tabla que eviten el examen (scan) multitabla. Sobre que columnas: Columnas frecuentemente involucradas en selección (where) o reunión (JOIN), order by, group by, union, distinct,... (ordenación). [puede que un SGBD concreto no efectúe ordenaciones en las sentencias anteriores o puede realizar las ordenaciones en HW especial o puede permitir cambiar el algoritmo de ordenación por otro más eficiente,...] Sobre claves ajenas  son las que con más frecuencia participarán en JOINs y subconsultas (sobre todo cluster index).

16 ÍNDICES Conviene EVITAR los índices...
si la tabla es muy pequeña (ocupa poco espacio) si se degradan los requerimientos de procesamiento crítico si el costo de su almacenamiento +mantenimiento >>>> beneficio INSERCIÓN, MODIFICACIÓN, ELIMINACIÓN sobre tablas indexadas  mantenimiento del índice (automático, por parte del SGBD) A veces conviene CREAR la tabla, rellenarla, y luego CREAR los ÍNDICES Y a veces conviene (actualizaciones masivas, reorganizaciones, copias de seguridad, estadísticas): ELIMINAR ÍNDICES, realizar las MODIFICACIONES sobre la BD y CREAR de nuevo los ÍNDICES Máximo de  4 índices por tabla. Más si rara vez es actualizada  INDICES   necesidad de espacio +  velocidad de inserción/eliminación Evitar crear índices sobre columnas que son actualizadas muy a menudo con distribución irregular de valores (selectividad: confunde al optimizador) columnas que sólo aparezcan en cláusulas WHERE con funciones u operadores (distintos a MIN o MAX)  pueden no hacer disponible el camino de acceso e) No se deben crear índices sobre tablas pequeñas. f) Debemos evitar índices cuando se degraden severamente los requerimientos de procesamiento crítico o cuando el costo de su almacenamiento y mantenimiento sea excesivo en relación a los beneficios. Las inserciones, modificaciones y borrados sobre tablas indexadas implican mantenimiento del índice. Además afecta a: Carga inicial, actualizaciones masivas, reorganizaciones, copias de seguridad y estadísticas. A veces es necesario reducir el número de índices, realizar operaciones sobre la BD y posteriormente crear de nuevo los índices. g) En general, máximo de 4 índices por tabla. Más de 4 si es raramente actualizada. h) Aconsejable almacenar los índices sobre dispositivos de almacenamiento distintos a los de las tablas (mínimo 2 E/S). Evitar: No indexaremos columnas que sólo aparezcan en cláusulas WHERE con funciones u operadores (distintos a MIN o MAX) pues pueden no hacer disponible el camino de acceso que usa el índice. Evitarlo sobre columnas frecuentemente actualizadas. Evitarlo sobre columnas con distribución irregular de valores. (pueden confundir al optimizador. Este decide entre scan e índice en función del porcentaje de filas de que pueden ser accedidas mediante el índice y normalmente asume una distribución uniforme de valores en la columna de índice. Se puede determinar la selectividad de un índice dividiendo el número de tuplas en la tabla entre el número de valores distintos indexados: ( empleados / 1000 departamentos  100 emp/dep, índice sobre departamento  asume utilización de índice sobre departamento; sin embargo, empleados son del mismo departamento  mejor no utilizar el índice). (comando ANALYZE de Oracle: permite obtener estos porcentajes).

17 ÍNDICES El SGBD Oracle ... Implementa los índices mediante árboles B*
No incluye entrada en el índice para tupla con NULL en la columna de indexación El Optimizador NO usa el índice construido sobre una columna, si la consulta... no incluye WHERE, usa una columna indexada aplicandole una función (SUBSTR, ...) u operador (||, ...) pero el SGBD sí usa el índice si la consulta... contiene un ORDER BY a la columna indexada, aplica MAX, MIN sobre una única columna (la indexada)

18 Técnicas de dispersión (Hashing)
Las tuplas son físicamente almacenadas y recuperadas de acuerdo con los resultados de una función de dispersión (hash function): genera a distribución de valores numéricos (hash values), basada en valores específicos de la clave de dispersión (hash key values). Alternativa a tablas indexada / agrupada: las tuplas son localizadas usando los valores de clave que están almacenados en un índice separado  mínimo de 2 operaciones de E/S. Una función de dispersión no necesita E/S  mínimo una E/S para leer o escribir una tupla en la tabla. No todos los SGBD soportan hashing (no universal) Extremadamente eficiente para acceso directo. Solo se puede definir un hashing por tabla (determina la posición física). Utilizar hashing para: tablas medianas – grandes. Frecuentes accesos individuales aleatorios. Especificar valores discretos (selección por igualdad) de la misma columna o conjunto de columnas (hash key values). Actualizaciones infrecuentes de la hash key. Tamaño de la tabla conocido y no se esperan crecimientos o reducciones significativos  dispersión estática / dispersión dinámica en caso contrario. HASHING : Conversión de un valor de datos (en una columna o conjunto de columnas) mediante algún algoritmo que determine la dirección lógica de una fila en la tabla. Las filas de una tabla son físicamente almacenadas y recuperadas de acuerdo con los resultados de una función de dispersión (hash function): genera una distribución de valores numéricos (hash values), que están basados en valores específicos de la clave de dispersión (hash key values). Es una alternativa a tablas no agrupadas con un índice o a un index cluster. Con una tabla indexada o un index cluster, las filas en una tabla son localizadas usando los valores de clave que están almacenados en un índice separado. Por tanto se necesitan un mínimo de 2 operaciones de E/S. Por el contrario con una función de asociación no se necesita E/S: se necesita un mínimo de una operación de E/S para leer o escribir una tupla en la tabla. NOTA: No todos los SGBD soportan hashing (no universal) Extremadamente eficiente para acceso directo. Solo se puede definir un hashing por tabla. No se puede mezclar hash y cluster: el índex cluster también determina la posición física de la tupla en la tabla. Utilizar hashing para: tablas medianas – grandes. Frecuentes accesos individuales aleatorios. Especificar valores discretos (selección por igualdad) de la misma columna o conjunto de columnas (hash key values). Actualizaciones infrecuentes de la hash key. Tamaño de la tabla conocido y no se esperan crecimientos o reducciones significativos  dispersión estática / dispersión dinámica en caso contrario.

19 Técnicas de dispersión (Hashing)
No utilizarlo: Accesos por rango de valores, a menos que sea una lista discreta de valores de clave (IN (val, val, val)). Accesos que requieran ordenación (como acceso en secuencia lógica). Si se accede a la tabla sobre criterios de selección que no involucran la clave o que involucran a parte de la misma Si se accede mediante búsqueda de patrón (pattern match, LIKE). Sobre que columnas: a) Que permitan lograr una buena distribución de tuplas. b) Eviten colisiones (sinónimos, valores duplicados de hash: originan encadenamientos, overflow, ...)  no se debe definir sobre columnas con pocos valores diferentes. c) Sobre columnas frecuentemente utilizadas para recuperar mediante condiciones de igualdad sobre valores discretos. d) Evirtarlo sobre columnas frecuentemente actualizadas. No utilizarlo: Accesos por rango de valores, a menos que sea una lista discreta de valores de clave (IN (val, val, val)). Accesos que requieran ordenación (como acceso en secuencia lógica). Si se accede a la tabla sobre criterios de selección que no involucran la clave o que involucran a parte de la misma (pattern match, LIKE). Sobre que columnas: a) Que permitan lograr una buena distribución de tuplas. b) Eviten colisiones (sinónimos, valores duplicados de hash: originan encadenamientos, overflow, ...)  no se debe definir sobre columnas con pocos valores diferentes. c) Sobre columnas frecuentemente utilizadas para recuperar mediante condiciones de igualdad sobre valores discretos. d) Evirtarlo sobre columnas frecuentemente actualizadas.

20  Acelerar la operación de equirreunión y/o de reunión natural: Técnicas de agrupamiento
Almacenar DOS RELACIONES (intererrelación 1:N clave primaria / clave ajena) en un ÚNICO FICHERO según la clave del cluster: Cada registro del lado 1 (clave primaria) está SEGUIDO de los registros del lado N (ajena)  Consultas MUY EFICIENTES sobre la clave del cluster ... REUNIONES entre ambas tablas Agrupamiento de registros del lado N por el valor de la clave externa (los registros relacionados están en el mismo bloque  menos accesos a bloque)  Mayor aprovechamiento del espacio  Consultas a cada tabla por separado resultan ineficientes (acceso multi-tabla)  Examen completo (scan) de cada tabla por separado, más costoso  INSERCIÓN poco eficiente debido a que se debe mantener la ordenación física, al tiempo que desaprovechar el mínimo espacio de almacenamiento  muchos encadenamientos entre registros (zonas de desborde, etc.)  menor eficiencia de las búsquedas según la clave del cluster  reducción del rendimiento de las consultas CLUSTERING (agrupamiento)  Almacenamiento de tuplas en una secuencia predeterminada basada en los valores de una o más columnas (cluster key). Supone ordenación física de las tuplas. Técnica de almacenamiento que puede mejorar los mecanismos de acceso. Facilita los requerimientos de procesamiento que causan cuellos de botella en el rendimiento: proceso secuencial, examen (scan), ordenaciones. Desventaja: Mantenimiento de la secuencia  encontrar espacio cerca de la tupla, lógicamente adyacente + suele ir acompañado de índice (mecanismo de acceso al cluster)  mantenimiento del índice adicional. Espacio: movimiento físico de tuplas o utilización de espacio libre (con el tiempo se produce degeneración en el cluster  utilidad para reorganizar la secuencia). Si creamos un cluster sobre dos o más tablas, cuando el criterio de selección involucre solo a una de las tablas del cluster, el procedimiento será ineficiente.  podemos crear índices sobre cada tabla que eviten el examen (scan) multitabla. Nota: Es una alternativa a tablas no agrupadas con un índice o a un index cluster. Con una tabla indexada o un index cluster, las filas en una tabla son localizadas usando los valores de clave que están almacenados en un índice separado. Por tanto se necesitan un mínimo de 2 operaciones de E/S. Por el contrario con una función de asociación no se necesita E/S: se necesita un mínimo de una operación de E/S para leer o escribir una tupla en la tabla.

21 RESUMEN DE PAUTAS DE D.FÍSICO (1) (Elmasri/Navathe)
Usar “FICHERO ORDENADO” y escoger como atributo de ordenación el que se use mucho para obtener o procesar los registros en orden, o en operaciones de reunión con este fichero, o en selecciones que incluyen un rango de valores sobre ese atributo CREANDO un ÍNDICE sobre ese atributo (camino de acceso primario) Índice PRIMARIO (atributo clave) CREATE UNIQUE INDEX... CLUSTER Índice de AGRUPAMIENTO (no clave) CREATE INDEX ... CLUSTER Usar un “FICHERO NO ORDENADO” si si ningún atributo satisface estos criterios, o el fichero es frecuentemente actualizado ... inserciones/borrados de tuplas (registros) modificaciones del atributo de ordenación

22 RESUMEN DE PAUTAS DE DISEÑO FÍSICO (y 2)
Para cada atributo (no de ordenación) que se use mucho en operaciones de selección o reunión, crear un índice SECUNDARIO -- CREATE [UNIQUE] INDEX ... Si el fichero se va a actualizar mucho (INSERCIÓN/ELIMINACIÓN), reducir al MÍNIMO el número de ÍNDICES del fichero Usar un FICHERO DISPERSO y si algún atributo ... se usa mucho para selección por igualdad u operaciones de reunión nunca se utiliza para obtener los registros en orden sus valores son muchos y diferentes, y apenas se modifica su valor y se puede CREAR ÍNDICES SECUNDARIOS sobre otros atributos del fichero disperso

23 Acelerar la operación de equirreunión y/o de reunión natural: DESNORMALIZACIÓN
«Desnormalizar, es decir, violar la normalización, sólo tiene una excusa: rendimiento ... y sólo en algunas situaciones » [Shasha-92] La normalización hasta la 3FN, FNBC o superior, facilita la comprensión de... los datos y relaciones entre los datos, que deben protegerse y mantenerse al crear las aplicaciones En aplicaciones importantes o muy sencillas, cuyas tareas no se adaptan a tablas normalizadas, una vez terminado el análisis, puede ser necesario desnormalizar algunas tablas, para conseguir una aplicación que se adapte a... las tareas de los usuarios los requerimientos de tiempo DESNORMALIZACIÓN Otra técnica que permite acelerar las operaciones de equireunión o reunión natural es la desnormalización del esquema lógico de la BD. La normalización de los datos hasta la 3ªFN, FNBC, o formas más altas, puede ofrecer una comprensión profunda de los datos, y las relaciones entre los distintos elementos que deben ser protegidos y mantenidos al construir las aplicaciones. Sin embargo, para una aplicación importante o aplicaciones simple cuyas tareas no se adaptan con facilidad a tablas plenamente normalizadas, una vez terminado el análisis, puede ser necesario seguir un proceso de desnormalización en algunas de sus tablas, para conseguir una aplicación sensible, que se adapte a las tareas de los usuarios y a los requerimientos de tiempo disponible.

24 DESNORMALIZACIÓN REAL
Consultas o Transacciones frecuentes que necesitan reunión de demasiadas tablas (tres o más), o dos tablas con muchas tuplas se ejecutarán muy lentamente Solución: Romper la 3FN (FNBC o superior) Almacenar atributos de una tabla en otra tabla REPETICIÓN, DUPLICACIÓN o REDUNDANCIA de atributos Importante: las transacciones que actualizan el atributo deben MANTENER LA CONSISTENCIA entre los duplicados (evitar anomalías) Procedimientos almacenados, Disparadores (Triggers), Afirmaciones Redundancia controlada DESNORMALIZACIÓN EXTREMA Almacenar un FICHERO con la REUNIÓN de las tablas  Resolver explícitamente las ANOMALÍAS DE ACTUALIZACIÓN Desnormalización real. Podemos encontrar consultas o transacciones frecuentes que requieran el acceso simultáneo a demasiadas tablas. Las combinaciones de tablas que conciernen a tres o más tablas, incluso si sólo dos de ellas son largas, consumen un número sustancial de ciclos de CPU. Puede que las aplicaciones se ejecuten demasiado lentamente. Una solución a este problema es violar de manera intencionada la 3ª FN en el diseño de tablas, poniendo datos redundantes en una tabla que no sean completamente dependientes de la KP. Deberemos compensar esta desnormalización exigiendo a las transacciones de actualización el mantenimiento de la consistencia de los valores de los atributos duplicados (procedimientos almacenados y disparadores; aserciones). Una desnormalización extrema puede llevarnos a almacenar en una tabla física la combinación de dos o más tablas. Debe adoptarse con mucho cuidado ya que pueden presentarse todas las anomalías de actualización vistas en tema de Dependencias Funcionales.

25 DESNORMALIZACIÓN REAL
Esquema de base de datos no normalizado El análisis de requerimientos indica que siempre que se necesita el perfil de un trabajador, se requiere el nombre del responsable de donde esté alojado el trabajador. EMPLEADO(nombre, edad, alojamiento, responsable) OFICIO_EMPLEADO(nombre, oficio, calificacion) OFICIO(oficio, descripcion) ALOJAMIENTO(alojamiento, nombre-completo, direccion, responsable) Este esquema... INSERCIÓN NO DIRECTA en la tabla EMPLEADO: al insertar un empleado  el nombre del responsable debe venir desde la tabla ALOJAMIENTO, según el valor de “alojamiento” para el nuevo empleado MODIFICACIÓN del nombre de un responsable en la tabla ALOJAMIENTO, o cambio de responsable para un alojamiento  modificación de tuplas EMPLEADO EjEMPLO: suponemos que siempre que siempre que se necesite el perfil de un trabajador, necesitará el nombre del patrón donde esté alojado el trabajador. Tareas atómicas de actualización: cada vez que insertemos un nuevo empleado  responsable debe venir de la tabla Alojamiento, no inserción directa de responsable en empleado; cada vez que modifiquemos el responsable de la tabla alojamiento  modificación de responsable en tabla empleado. (Nota: los sistemas de BDR son sistemas adaptados a la memoria de la CPU. Aunque se consiga reducir el número de E/S necesario para llevar la información de una tabla a memoria, si el tamaño de memoria es muy pequeño, trabajando en modo paginado, la operación de almacenar, ordenar y combinar tablas pasaría de ser una tarea de memoria a una tarea cargada sobre la E/S del disco. Todos los sistemas disponen utilidades de monitorización que permiten verificar los cuellos de botella que puedan producirse. Lo que intuitivamente puede parecer más rápido a menudo no lo es.) Bibliografía: Connolly, T.; Begg, C.; Strachan, A. Database systems: a practical approach to design, implementation and management. Addison-Wesley Longman, 1996. Elmasri, R; Navathe, S.B. Sistemas de bases de datos: conceptos fundamentales. 2ª ed. Addison-Wesley Iberoamericana, 1997. Fleming, C.C.; Von Halle, B. Handbook of relational database design. Addison-Wesley, 1989. Koch, G. Oracle 7: manual de referencia. McGraw-Hill, 1994. Shasha, D.E. Database Tuning: a principled approach. Prentice-Hall, 1992.

26 Estructura lógica de una BD Oracle

27 Estructuras lógicas de almacenamiento
Segmento datos Segmento de índices Segmento de rollback Segmento temporal SELECT ... ORDER BY... CREATE INDEX. SELECT ... GROUP BY... SELECT ... UNION ... SELECT DISTINCT ... SELECT … INSERSEC ... SELECT ... MINUS ...

28 Estructura física de Oracle
Ficheros de datos Ficheros redo log Ficheros de control

29 Entorno de memoria en Oracle
SGA: System/Shared Global Area Shared pool: library (zona sql, control y bloqueos)+dictionary (metadatos) cache Database Buffer Cache Redo Log Buffer PGA: Program Global Area

30 Elementos de diseño físico en ORACLE
Tablespace CREATE TABLESPACE TS_DATOS DATAFILE ‘/disco1/fichero1’ SIZE 100 M, DATAFILE ‘/disco2/fichero2’ SIZE 250 M; Tablas y extensiones CREATE TABLE Alumnos (…) TABLESPACE TS_DATOS PCTFREE 20 PCTUSED STORAGE (INITIAL 20K NEXT 30K MINEXTENTS 1 MAXEXTENTS 10 PCTINCREASE 0);

31 Elementos de diseño físico en ORACLE
Índices (dentro de create table) ……. CREATE INDEX nom_ind ON Alumnos (atributos) …. Clusters CREATE CLUSTER CL_1(clave number(4)) SIZE 512 TABLESPACE TS_DATOS PCTFREE 20 STORAGE(…..); CREATE TABLE Alumno (….) CLUSTER CL1_(a1); Dispersión CREATE CLUSTER CL_1() SIZE 512 HASH IS clave HASKEY 300 ……

32 Disparadores en Oracle
Uso de disparadores Evitar ejecución de transacciones inválidas Garantizar el cumplimiento de restricciones de integridad y de reglas de negocio Generar automáticamente valores de columnas derivadas Mal uso Para garantizar el cumplimiento de restricciones que puedan ser definidas a nivel de esquema  CHECK Disparadores recursivos Gran tamaño  Procedimiento almacenado

33 Creación de disparadores
CREATE TRIGGER BUpCUOTA BEFORE UPDATE OF f_pago ON Cuota FOR EACH ROW WHEN (new.f_pago > old.f_venc) BEGIN raise_application_error(-20000, ‘Cuota ‘ || TO_CHAR(:old.num_cuota) || ‘ del prestamo ‘ || TO_CHAR(:old.num_prest) || ‘ vencida. Por favor, dirigirse a la gerencia.’); END;

34 Sobre la creación de disparadores
Los nombres de los triggers deben ser únicos dentro de un esquema dado. Alguna de las dos, BEFORE o AFTER, debe ser utilizada en el CREATE TRIGGER. La sentencia activadora especifica el tipo de operación que despierta el disparador (DELETE, INSERT o UPDATE). En la sentencia activadora se especifica la tabla asociada al trigger. Puede especificarse exactamente una tabla (no una vista) en la sentencia activadora. Si la sentencia activadora especifica un UPDATE se puede incluir una lista de columnas en dicha sentencia. Si se incluye la lista de columnas, el trigger se activa por un UPDATE sólo si una de las columnas especificadas es actualizada. Si se omite la lista, el trigger se activa cuando cualquier columna de la tabla se actualiza. No se puede especificar lista de columnas para INSERT o DELETE. La presencia o ausencia de la opción FOR EACH ROW determina si el disparador es a nivel de filas (row trigger) o a nivel de sentencia activadora (statement trigger). Especifica que el cuerpo del trigger se ejecuta individualmente para cada una de las filas de la tabla que haya sido afectada por la sentencia activadora. Opcionalmente, se pueden incluir restricciones en la definición de un row trigger. Para ello se especifica, en una cláusula WHEN, una expresión booleana de SQL. Si se incluye una cláusula WHEN, la expresión se evalúa para cada una de las filas que el disparador afecta. Si el resultado de la evaluación es TRUE, se ejecuta el cuerpo del trigger sobre la fila que hizo cierta la expresión. La expresión en una cláusula WHEN no puede incluir subqueries.

35 Cuerpo de un disparador
Bloque de PL/SQL Disparador que se activa con Insert OR Delete or Update If Inserting/Updating/Deleting THEN….. END IF; Update OF (atributos) Row trigger: new, old Rollback en caso de error si no hay manejo específico de la excepción

36 Modificar disparadores
No hay modificación explícita, se reemplaza. 1)CREATE OR REPLACE TRIGGER BUpCUOTA 2) DROP TRIGGER BUpCUOTA ; CREATE TRIGGER BUpCUOTA (Des)habilitar ALTER TRIGGER BUpCUOTA ENABLE/DISABLE; ALTER TABLE CUOTA ENABLE/DISABLE ALL TRIGGERS;

37 Ejemplo de trigger CREATE TRIGGER salary_check
BEFORE INSERT OR UPDATE OF sal, job_classification ON emp FOR EACH ROW DECLARE minsal NUMBER; maxsal NUMBER; salary_out_of_range EXCEPTION; BEGIN SELECT minsal, maxsal INTO minsal, maxsal FROM salgrade WHERE job_classification = :new.job_classification; IF (:new.sal < minsal OR :new.sal > maxsal) THEN RAISE salary_out_of_range; END IF; EXCEPTION WHEN salary_out_of_range THEN raise_application_error (-20300, 'Salary '||TO_CHAR(:new.sal)||' out of range for ' ||'job classification '||:new.job_classification ||' for employee '||:new.name); WHEN NO_DATA_FOUND THEN raise_application_error(-20322, 'Invalid Job Classification ' ||:new.job_classification); END;

38 Ejemplo de trigger Para generar valores de columnas derivadas:
BEFORE INSERT OR UPDATE OF ename ON emp FOR EACH ROW BEGIN :new.uppername := UPPER(:new.ename); :new.soundexname := SOUNDEX(:new.ename); END;