Manejadores de Base de Datos_solonotas

RESUMEN DE CONCEPTOS GENERALES DE SISTEMAS MANEJADORES DE BASES DE

DATOS

1. Sistemas Manejadores de Base de Datos DBMS 2. Las 12 reglas de Codd para DBMS relacionales 3. SQL 4. LMD, LDD Y LCD 5. Tablas 6. Vistas 7. Índices 8. Catálogo 9. Optimización de consultas 10. Seguridad 11. Integridad 12. Control de concurrencias 13. Respaldo y recuperación 14. Utilerías de mantenimiento 15. Herramientas para monitoreo 16. Administración de base de datos

SISTEMAS MANEJADORES DE BASES DE DATOS

El DBMS o SMBD (Sistema Manejador de Base de Datos) es un Software que actúa como un intermediario entre la base de datos y los usuarios. Estos usuarios pueden ser finales, técnicos (programadores) o especializados (administrador de base de datos). Las bases de datos de las empresas se miden en términos de gigabytes o terabytes. Puesto que la memoria principal de las computadoras no puede almacenar esta información, la base de datos se almacena en disco. Es de gran importancia que el sistema de base de datos minimice la necesidad de mover los datos entre la memoria y el disco. Una base de datos es similar a un archivo de datos en cuanto a que ambos son un almacenamiento de datos. Como en un archivo de datos, una base de datos presenta información directamente al usuario; el usuario ejecuta una aplicación que tiene acceso a los datos de la base de datos y los presenta al usuario en un formato inteligible. Los sistemas de bases de datos son más útiles que los archivos de datos. Los datos están mucho mejor organizados. En una base de datos bien diseñada, no hay elementos de datos duplicados que el usuario o la aplicación tengan que actualizar al mismo tiempo. Los elementos de datos están agrupados en una única estructura o registro, y se pueden definir relaciones entre dichas estructuras y registros.

Un Sistema Manejador de Base de Datos es una herramienta de Software con un conjunto de programas que permiten construir y administrar una base de datos, además de ofrecer los medios para que programas dedicados al usuario puedan explotar la información que se agrega a las tablas de las bases de datos. Los principales componentes de un manejador serian los siguientes:

MOTOR DE BASE DE DATOS

PROTOCOLOS DE COMUNICACIONES HERRAMIENTAS DE ADMINISTRACION

HERRAMIENTAS DE DISEÑO DE REPORTES Y PANTALLAS

HERRAMIENTAS DE MANTENIMIENTO

HERRAMIENTAS DE DISEÑO DE SCRIPTS

. . . . . OTROS











. . . . . OTROS

Las funciones que debe cumplir un DBMS son las siguientes:

Simplificar la definición de las estructuras de una base de datos. Facilitar el acceso a los datos. interactuar con el sistema de archivos. Permitir la implantación de esquemas de integridad. Permitir la implantación de esquemas de seguridad. Agregar esquemas de respaldo y recuperación. Establecer control de concurrencia.

Ejemplos de manejadores de bases de datos:

• SQL SERVER, DB2, SYBASE , ORACLE, INFORMIX, INGRESS El entorno de Software en el que se puede ver involucrado un Sistema Manejador de Base de Datos puede ser el siguiente.

I N T E R N E T

SERVICIO EXTERNO

SERVICIO LOCAL

WIN NT, WIN 2000 SERVER

JAVA, HTML, FRONT PAGE, DREAM WEAVER, FLASH, OTROSSISTEMAS SOBRE INTERNET

VISUAL B, VISUAL C

ERWIN, S DESIGNOR, ETC

ESTRUCTURAS Y MODELOS DE DATOS

SQL SERVER

OTROS SIST. OPERATIVOS

OTROS LENGUAJES

OTROS S M B D

I N T E R N E T

SERVICIO EXTERNO

SERVICIO LOCAL

WIN NT, WIN 2000 SERVER

JAVA, HTML, FRONT PAGE, DREAM WEAVER, FLASH, OTROSSISTEMAS SOBRE INTERNET

VISUAL B, VISUAL C

ERWIN, S DESIGNOR, ETC

ESTRUCTURAS Y MODELOS DE DATOS

SQL SERVER

OTROS SIST. OPERATIVOS

OTROS LENGUAJES

OTROS S M B D

Todo DBMS está basado en un modelo de Datos.

Modelo relacional de base de datos Hay varias formas de organizar los datos en las bases de datos, pero las bases de datos relacionales son una de las formas más efectivas. Los sistemas de bases de datos relacionales son una aplicación de la teoría matemática de los conjuntos al problema de la organización de los datos. En una base de datos relacional, los datos están organizados en tablas (llamadas relaciones en la teoría relacional). Una tabla representa una clase de objeto que tiene cierta importancia en una organización. Por ejemplo, una corporación puede tener una base de datos con una tabla para los empleados, otra tabla para los clientes y otra para los productos del almacén. Las tablas están compuestas de columnas y filas (atributos y tuplas en la teoría relacional). Cada columna representa algún atributo del objeto representado por la tabla. Por ejemplo, una tabla Empleados normalmente tendría columnas para el nombre, el apellido, el Id. del empleado, el departamento, la categoría laboral y el cargo. Cada fila representa una instancia del objeto representado por la tabla. Por ejemplo, una fila de la tabla Empleados representa el empleado cuyo Id. de empleado es 12345. Al organizar los datos en tablas, se pueden encontrar varias formas de definirlas. La teoría de las bases de datos relacionales define un proceso, la normalización, que asegura que el conjunto de tablas definido organizará los datos de manera eficaz.

USUARIO FINAL USUARIO TECNICO DBA DBA DBA REQUERIMIENTO PROGRAMA SMBD TABLAS MODELO

Necesidad de información LENGUAJE C SQL SERVER DDF TECNICAS para modelar

Necesidad de automatizar funciones Pascal DB2 HERRAMIENTAS DE

DISEÑO

Visual Basic SEQUEL ANYWHERE Power Builder ACCESS INFORMIX ORACLE

Bases de datos

Los datos de una base de datos están organizados en los componentes lógicos visibles por los usuarios. Además, una base de datos está implementada físicamente como dos o más archivos de disco. Al utilizar una base de datos, se trabaja principalmente con los componentes lógicos, como tablas, vistas, procedimientos y usuarios. La implementación física de los archivos es casi enteramente transparente. Normalmente, sólo el administrador de la base de datos tiene que trabajar con la implementación física.

Funciones del servidor

• El servidor es el componente que recibe las instrucciones SQL de los clientes y realiza las acciones necesarias para completar las instrucciones. Esta sección trata:

• E servidor compila cada una de las instrucciones SQL de proceso por lotes en un plan de ejecución que indica al servidor cómo procesar la instrucción.

• Administra los recursos de memoria, subprocesos y tareas. • Determina qué parte de una consulta distribuida hace referencia a un servidor vinculado y

qué petición se transmite al servidor para obtener los datos que se necesitan. • Transmite las llamadas a procedimientos almacenados remotos a los servidores remotos. • Administra la simultaneidad y los problemas de transacciones. • Implementa los cursores del servidor.

Sistemas de bases de datos cliente-servidor Los sistemas cliente-servidor están construidos de tal modo que la base de datos puede residir en un equipo central, llamado servidor y ser compartida entre varios usuarios. Los usuarios tienen acceso al servidor a través de una aplicación de cliente o de servidor:

1. En un sistema cliente-servidor de dos estratos, los usuarios ejecutan una aplicación en su equipo local, llamado cliente, que se conecta a través de la red con el servidor que ejecuta SQL Server. La aplicación de cliente ejecuta las reglas de la compañía y el código necesario para presentar el resultado al usuario.

2. En un sistema cliente-servidor de varios componentes, la lógica de la aplicación de cliente

se ejecuta en dos ubicaciones:

• El cliente reducido se ejecuta en el equipo local del usuario y se encarga de presentar

resultados al usuario. • La lógica de la compañía se encuentra en aplicaciones de servidor que se ejecutan en

un servidor. Los clientes reducidos solicitan funciones a la aplicación de servidor, que, a su vez, es una aplicación multiproceso capaz de operar con varios usuarios simultáneos. La aplicación de servidor es la que abre las conexiones con el servidor de la base de datos y se puede ejecutar en el mismo servidor que la base de datos, o se puede conectar a través de la red con otro servidor que opere como servidor de base de datos.

El tener los datos almacenados y administrados en una ubicación central ofrece varias ventajas:

• Todos los elementos de datos están almacenados en una ubicación central en donde todos los usuarios pueden trabajar con ellos.

• Los servidores de base de datos relacionales optimizan el tráfico de la red al devolver sólo los datos que la aplicación necesita. Por ejemplo, si una aplicación que trabaja con un servidor de archivos tiene que presentar la lista de los representantes comerciales de Oregón, debe obtener el archivo de empleados completo. Si la aplicación trabajara con un servidor de bases de datos relacionales, enviaría este comando: SELECT first_name, last_name FROM employees WHERE emp_title = 'Sales Representative' AND emp_state = 'OR' La base de datos relacional sólo devuelve los nombres de los representantes comerciales de Oregón, no toda la información de todos los empleados

• No se almacenan copias separadas del elemento en cada cliente, lo que elimina los

problemas de hacer que todos los usuarios trabajen con la misma información. • Las reglas de la organización y las reglas de seguridad se pueden definir una sola vez en el

servidor para todos los usuarios. • Esto se puede hacer en una base de datos mediante el uso de restricciones, procedimientos

almacenados y desencadenadores. También se puede hacer en una aplicación de servidor. • Los gastos en hardware se pueden minimizar. • Como los datos no están almacenados en los clientes, éstos no tienen que dedicar espacio

de disco a almacenarlos. Los clientes tampoco necesitan la capacidad de proceso para administrar los datos localmente y el servidor no tiene que dedicar capacidad de proceso para presentar los datos.

• El servidor se puede configurar para optimizar la capacidad de E/S de disco necesaria para obtener los datos y los clientes se pueden configurar para optimizar el formato y presentación de los datos obtenidos desde el servidor.

• El servidor puede estar situado en una ubicación relativamente segura y estar equipado con dispositivos como Sistemas de alimentación interrumpida (SAI), lo que resulta más económico que si se protegieran todos los clientes.

• Las tareas de mantenimiento como las copias de seguridad y restauración de los datos son más sencillas porque están concentradas en el servidor central.

.

Sistemas de bases de datos de escritorio Son útiles para aplicaciones que necesiten bases de datos independientes almacenadas de forma local en el cliente. No se tiene que dedicar un administrador de bases de datos a cada cliente. Cuando los clientes utilizan bases de datos locales, una copia del motor de bases de datos se ejecuta en el cliente y administra todas las bases de datos de dicho cliente. Las aplicaciones conectan con el motor de la base de datos casi de la misma forma en que se conectan a través de la red con un motor de base de datos que se ejecuta en un servidor remoto.

.

LAS 12 REGLAS DE CODD PARA DBMS RELACIONALES

Sirven para determinar la fidelidad de un sistema relacional al modelo relacional En la década de los 80 comenzaron a aparecer numerosos SMBD que se anunciaban como "relacionales". Sin embargo estos sistemas carecían de muchas características que se consideran importantes en un sistema relacional, perdiendo muchas ventajas del modelo relacional. Como ejemplo extremo de esto "sistemas relacionales" eran simplemente sistemas que utilizaban tablas para almacenar la información, no disponiendo de elementos como claves primarias, etc. En 1984 Codd publicó 12 reglas que un verdadero sistema relacional debería de cumplir. En la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas. REGLA 0 Para que un sistema se denomine sistema de manejo de bases de datos relacionales, este sistema debe usar (exclusivamente) sus capacidades relacionales para manejar la base de datos. REGLA 1: REGLA DE LA INFORMACIÓN Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. REGLA 2: REGLA DEL ACCESO GARANTIZADO Para todos y cada uno de los datos (valores atómicos) de una BDR se garantiza que son accesibles a nivel lógico utilizando una combinación de nombre de tabla, valor de clave primaria y nombre de columna. REGLA 3: TRATAMIENTO SISTEMÁTICO DE VALORES NULOS Los valores nulos (que son distintos de la cadena vacía, blancos, 0, ...) se soportan en los SMBD totalmente relacionales para representar información desconocida o no aplicable de manera sistemática, independientemente del tipo de datos. REGLA 4: CATÁLOGO DINÁMICO EN LÍNEA BASADO EN EL MODELO RELACIONAL La descripción de la base de datos se representa a nivel lógico de la misma manera que los datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales.

REGLA 5: REGLA DEL SUBLENGUAJE DE DATOS COMPLETO Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal (ej: rellenar formularios, etc.). Sin embargo, debe existir al menos un lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de caracteres y que sea completo, soportando: REGLA 6: REGLA DE ACTUALIZACIÓN DE VISTAS Todas las vistas que son teóricamente actualizables se pueden actualizar por el sistema. REGLA 7: INSERCIÓN, ACTUALIZACIÓN Y BORRADO DE ALTO NIVEL La capacidad de manejar una relación base o derivada como un solo operando se aplica no sólo a la recuperación de los datos (consultas), si no también a la inserción, actualización y borrado de datos. REGLA 8: INDEPENDENCIA FÍSICA DE DATOS Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando quiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso. REGLA 9: INDEPENDENCIA LÓGICA DE DATOS Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuando quiera que se realicen cambios a las tablas base que preserven la información. REGLA 10: INDEPENDENCIA DE INTEGRIDAD Los limitantes de integridad específicos para una determinada base de datos relacional deben poder ser definidos en el sublenguaje de datos relacional, y almacenables en el catálogo, no en los programas de aplicación. REGLA 11: INDEPENDENCIA DE DISTRIBUCIÓN Una SMBD tiene independencia de distribución. REGLA 12: REGLA DE LA NO SUBVERSIÓN Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes expresados en los lenguajes relacionales de más alto nivel (una relación (conjunto de registros) de cada vez).

TABLAS

TABLAS BASE

• Denominaremos tabla base a aquella tabla (columnas + renglones) que tienen existencia física.

• Es el objeto al que hacen referencia los programas. • Al definir una tabla no se indica ningún ordenamiento para los renglones. • Las columnas se ordenan de izquierda a derecha.

Se distingue el término de tabla base, con el de tabla debido a que no todas las tablas tienen existencia física, como es el caso de aquellas que son resultado de una vista. A todas las tablas se les asigna un nombre, al igual que a cada columna dentro de una tabla. Estos serán los únicos objetos a que un programa hará referencia en un postulado de SQL. El orden de los renglones no es relevante desde un punto de vista lógico, aunque si puede importar desde el punto de vista físico. Por ello, normalmente existirán mecanismos que permitan conservar los renglones en un cierto orden, aunque esta no debe imponer restricción alguna en los postulados de SQL ni alterar los resultados de estos. TABLAS RESULTANTES

• Son aquellas que a partir de una consulta en una proyección y/o restricción a una o varias tablas son recuperadas de tablas base.

• Existen de manera temporal en la memoria mientras dura la consulta

VISTAS

Una vista se puede considerar una tabla virtual o una consulta almacenada. Los datos accesibles a través de una vista no están almacenados en otro objeto distinto de la base de datos. Lo que está almacenado en la base de datos es una instrucción SELECT. El resultado de la instrucción SELECT forma la tabla virtual que la vista devuelve. El usuario puede utilizar dicha tabla virtual haciendo referencia al nombre de la vista, de la misma forma en que se hace referencia a las tablas. Las vistas se utilizan para alguna de estas funciones, o para todas:

Restringir al usuario a filas concretas de una tabla.

Por ejemplo, hacer que un empleado sólo vea las filas que guardan sus datos en una tabla de seguimiento de actividad laboral (consulta con una restricción de algunos renglones).

Restringir al usuario a columnas específicas.

Por ejemplo, hacer que los empleados que no trabajen en el departamento de nóminas vean las columnas nombre, oficina, teléfono y departamento de la tabla de empleados, pero no vean las columnas con los datos de salario u otra información personal (consulta con una proyección de solo algunas columnas).

Combinar columnas de varias tablas de forma que parezcan una sola tabla.

Agregar información en lugar de presentar los detalles.

CREATE VIEW costo_vista AS SELECT titulo, nombre_autor, precio, id_publicacion FROM titulo

INDICES

• Es un mecanismo que se puede emplear para hacer mas veloz el acceso a los datos de una tabla.

• También se emplean para garantizar la unicidad de la llave primaria • Ningún postulado de manipulación de datos hace referencia a los índices. • La decisión de emplear o no un índice existente la toma el optimizador. • A todas las tablas se les define un índice para reforzar la unicidad de la llave primaria. • El DBA decide si define varios índices sobre una tabla. • La existencia o no de índices puede alterar la velocidad con la que se produce el resultado,

pero no sus resultados.

Los índices se implementan en forma de árboles B. Un índice contiene una entrada con una o varias columnas (la clave de búsqueda) de cada fila de una tabla. Un árbol B se ordena con la clave de búsqueda y se puede buscar de forma eficiente en cualquier subconjunto principal de la clave de búsqueda. Por ejemplo, un índice en las columnas A, B y C puede buscarse de forma eficiente en A, en A y B, y en A, B y C. PRIMARY KEY (clave principal) y UNIQUE (no duplicados) son cláusulas que crean de manera automática índices No obstante, las ventajas que ofrecen los índices por lo que respecta al rendimiento también tienen un costo. Las tablas con índices necesitan más espacio de almacenamiento en la base de datos. Asimismo, es posible que los comandos de inserción, actualización o eliminación de datos sean más lentos y precisen más tiempo de proceso para mantener los índices. Cuando se diseña y crea índices, se debe asegurar de que las ventajas en el rendimiento compensan suficientemente el costo adicional en cuanto a espacio de almacenamiento y recursos de proceso.

Los dos tipos de índice en casi cualquier manejador son: Agrupado Los índices agrupados ordenan y almacenan las filas de los datos de la tabla de acuerdo con los valores de la clave del índice. Como las filas de los datos están almacenadas siguiendo el orden de la clave del índice agrupado, los índices agrupados son eficientes para buscar filas. Sólo puede haber un índice agrupado por cada tabla, porque las filas de datos sólo pueden estar ordenadas de una forma. Las propias filas de datos forman el nivel inferior de los índices agrupados. No agrupado Los índices no agrupados tienen una estructura que está completamente separada de las filas de datos. Las primeras filas de un índice no agrupado contienen los valores de las claves del índice y cada entrada de clave tiene punteros a las filas de datos que contienen el valor de la clave. Las filas de datos no están ordenadas en el orden de las claves del índice no agrupado. El puntero de una fila de índice no agrupado para una fila de datos se denomina localizador de fila. Los índices pueden ser únicos, lo que significa que ninguna fila puede tener el mismo valor que otra en la clave del índice. De lo contrario, el índice no es único y varias filas pueden compartir el mismo valor de clave. Hay dos formas de definir índices.

• CREATE INDEX crea y asigna el nombre de un índice. • CREATE TABLE acepta las siguientes restricciones que crean índices:

PRIMARY KEY crea un índice único que implementa una clave principal. UNIQUE Índice en el que no se permite que dos filas tengan el mismo valor de

índice, para así prohibir los índices o valores de clave duplicados. El sistema comprueba si hay valores de claves duplicados cuando se crea el índice y realiza la comprobación cada vez que se agregan datos con una instrucción INSERT o UPDATE

CLUSTERED Índice en el que el orden lógico o indizado de los valores de la clave es el mismo que el orden físico almacenado de las correspondientes filas existentes en la tabla.

NONCLUSTERED crea Índice en el que el orden lógico del índice no coincide con el orden físico o almacenado de las filas en el disco.

El siguiente es un posible ejemplo de creación de varios índices sobre la misma tabla.

USE pubs GO CREATE TABLE emp_sample (emp_id int PRIMARY KEY CLUSTERED, emp_name char(50), emp_address char(50), emp_title char(25) UNIQUE NONCLUSTERED ) GO CREATE NONCLUSTERED INDEX sample_nonclust ON emp_sample(emp_name) GO

La decisión de qué conjunto concreto de índices optimizara mejor el rendimiento depende de los tipos de consultas del sistema. Tenga en cuenta el índice agrupado en emp_sample.emp_id. Éste funciona bien si la mayor parte de las consultas que hacen referencia a emp_sample hacen comparaciones de igualdad o de intervalo sobre emp_id en sus cláusulas WHERE. Si las cláusulas WHERE de la mayor parte de las consultas hacen referencia a emp_name en lugar de a emp_id, se podría aumentar el rendimiento al crear el índice agrupado sobre la columna emp_name.

TABLAS DE CATALOGO

• Es un conjunto de tablas donde se almacena información de:

Estructuras de datos definidas Programas que hacen referencia a las estructuras Autorizaciones sobre objetos

• El catálogo es mantenido por el DBMS en forma automática • Puede ser consultado con postulados de SQL. • La estructura del catálogo varia dependiendo del DBMS en particular • Un catalogo tiene como ejemplo las siguientes tablas:

TABLAS, se almacena un renglón por cada tabla definida en el DBMS COLUMNAS se almacena un renglón por cada columna defina en el DBMS. INDICES: se guarda un renglón por cada índice definido sobre una tabla.

Las aplicaciones dinámicas que no están diseñadas para funcionar con un conjunto exclusivo de tablas y vistas deben disponer de un mecanismo para determinar la estructura y atributos de los objetos de cualquier base de datos a la que se conectan. Las aplicaciones pueden necesitar información como, por ejemplo:

• El número y nombre de las tablas y vistas de una base de datos. • El número de columnas en una tabla o vista, junto con el nombre de cada columna, tipo de

datos, escala y precisión. • Las restricciones definidas en una tabla. • Los índices y claves definidas para una tabla.

No es recomendable que los usuarios consulten directamente las tablas de catálogo; esto sólo debe hacerse en el caso de que ninguno de los métodos anteriores suministre la información necesaria. La actualización, eliminación o inserción de datos en una tabla del sistema puede producir efectos impredecibles o erróneos en un manejador de base de datos.

OPTIMIZACION DE CONSULTAS

El objetivo de la optimización del rendimiento consiste en minimizar el tiempo de respuesta de cada consulta y maximizar el rendimiento de todo el servidor de bases de datos al minimizar el tráfico de red, la E/S de disco y el tiempo de CPU. Este objetivo se logra mediante la comprensión de los requisitos de las aplicaciones, la estructura física y lógica de los datos y los intercambios entre usos conflictivos de la base de datos, como el procesamiento de transacciones en línea (OLTP, Online Transaction Processing), frente a la ayuda a la toma de decisiones. Se deben tener en cuenta los problemas de rendimiento durante el ciclo de desarrollo, no al final cuando el sistema está implementado. Muchos aspectos de rendimiento que causan una mejora significativa se consiguen mediante un cuidadoso diseño desde el principio. Mientras otros aspectos del rendimiento en el nivel de sistema, como la memoria, hardware, etc., también se deben estudiar, la experiencia muestra que la ganancia de rendimiento de estas áreas a menudo es incremental. Los manejadores suelen administrar automáticamente los recursos de hardware disponibles, lo que reduce la necesidad (y por lo tanto, las ventajas) de realizar optimizaciones manuales extensas en el nivel de sistema. Algunos renglones que ayudan a optimizar el performance en un ambiente de manejo bases de datos son los siguientes:

Diseño de bases de datos Optimizar las consultas Diseño de aplicaciones Optimizar el rendimiento de programas y herramientas Optimizar el rendimiento del servidor

El Componente responsable de generar el plan de ejecución óptimo de una consulta se llama optimizador, el cual utiliza información estadística contenida en las tablas del catalogo principalmente de los índices de tablas para desarrollar su actividad de minimizar los costos de búsquedas.

SEGURIDAD DE INFORMACIÓN

• Es la protección contra la divulgación, alteración o destrucción no autorizada. • Privacidad es el derecho de todo individuo a tener control sobre su información personal.

Es el derecho de individuos, grupos o instituciones a determinar por ellos mismos cuanto, como y que información acerca de ellos puede ser comunicada a otros.

• Privacidad vs. Derecho de la información.

SEGURIDAD E INTEGRIDAD

CONTROL DE SEGURIDAD Dentro del DBMS tiene que haber un mecanismo para proteger los datos, y para poder dar o quitar autorizaciones a los usuarios.

• Los tipos de autorización son:

Lectura, actualización, borrado e inserción

• Y se pueden otorgar sobre:

Una tabla, un grupo de tablas, una vista (subconjunto de renglones y columnas) En SQL existen 2 postulado para dar o quitar autorización: GRANT y REVOKE OTROS ASPECTOS DE SEGURIDAD

• La seguridad que provee el DBMS debe ser complementada por el sistema operativo. • No existen sistemas de seguridad perfectos. • Los DBMS suelen brindar la función de crear tiras de auditoria. • Se deben considerar otras opciones como el encriptado de datos.

USUARIO

No hay violación de integridad

Hay violación de integridad

Cambio incorrecto Cambio correctoNo hay cambio en los datos

Hay violación n de seguridad

No hay violación n de seguridad

Acceso ProhibidoAcceso permitido

INTEGRIDAD Integridad de los datos La integridad de los datos garantiza la calidad de los datos de la base de datos. Por ejemplo, si se especifica para un empleado el valor de employee_id (IdEmpleado) “123”, la base de datos no debe permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna employee_rating (clasificaciónEmpleado) para la que se prevea valores entre el 1 y el 5, la base de datos no debe aceptar el valor 6. Si en la tabla hay una columna dept_id (IdDepto) en la que se almacene el número de departamento del empleado, la base de datos sólo debe permitir valores que correspondan a los números de departamento de la compañía. Dos pasos importantes en el diseño de las tablas son la identificación de valores válidos para una columna y la determinación de cómo forzar la integridad de los datos en la columna. Hay cuatro categorías de integridad de datos:

Integridad de entidad, de dominio, referencial y definida por el usuario. Hay varias maneras de forzar cada tipo de integridad.

Tipo de integridad Opciones recomendadas

Entidad Restricción PRIMARY KEY Restricción UNIQUE Propiedad IDENTITY

Dominio Definición predeterminada (DEFAULT)

Restricción FOREIGNKEY Restricción CHECK NOT NULL

Referencial Restricción FOREIGNKEY

Restricción CHECK Definidos por el usuario Todas las restricciones en columnas y tablas de CREATE

TABLE Procedimientos almacenados Desencadenadores

Integridad de entidad La integridad de entidad define una fila como entidad única para una tabla determinada. La integridad de entidad fuerza la integridad de la columna o columnas de los identificadores o la clave principal de una tabla (mediante índices, restricciones UNIQUE, restricciones PRIMARY KEY o propiedades IDENTITY).

Integridad de dominio La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede forzar la integridad de dominio si restringe el tipo (mediante tipos de datos), el formato (mediante las reglas y las restricciones CHECK), o el intervalo de valores posibles (mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas). Integridad referencial La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se eliminan registros. En Microsoft® SQL Server™, la integridad referencial se basa en las relaciones entre las claves externas y las claves principales o entre las claves externas y las claves únicas. La integridad referencial garantiza que los valores clave son coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos. Cuando se fuerza la integridad referencial, SQL Server impide a los usuarios: Agregar registros a una tabla relacionada si no hay ningún registro asociado en la tabla principal. Cambiar valores en una tabla principal de manera que queden registros huérfanos en una tabla relacionada. Eliminar registros de una tabla principal cuando hay registros relacionados coincidentes. Por ejemplo, con las tablas sales (compras) y titles (títulos) de la base de datos pubs, la integridad referencial se basa en la relación entre la clave externa (title_id) de la tabla sales y la clave principal (title_id) de la tabla titles.

.

Integridad definida por el usuario La integridad definida por el usuario le permite definir reglas de la compañía específicas que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad son compatibles con la integridad definida por el usuario.

CONTROL DE CONCURRENCIA Para que un DBMS permita el acceso concurrente a los datos debe tener técnicas para asegurar la integridad de los datos. Se emplean técnicas de locking (bloqueo) para poder asegurar la integridad. TRANSACCIÓN

• Todo DBMS deberá soportar el concepto de transacción. • Entenderemos por transacción una unidad lógica de trabajo. • El DBMS deberá garantizar la atomicidad de cada transacción. • Para ello emplea los mecanismos de control de concurrencia y de respaldo y recuperación.

Una transacción estará formada por un conjunto de postulados SQL que conforman una unidad lógica de trabajo.

-hacer un retiro de una cuenta de cheques -dar de alta un cliente nuevo -efectuar un pago para tarjeta de crédito -autorizar un pago con tarjeta de crédito -hacer una reservación en un vuelo de una línea área

PREMISA: Una transacción individualmente correcta arrojará un estado válido en los datos,

después de ejecutarse, si se ejecuta aisladamente. Aún cuando un conjunto de transacciones sean individualmente correctas, es posible, en un

ambiente multi-usuario, que al ejecutarse concurrentes interfieran entre ellas y arrojen un estado inválido al concluir su ejecución.

El DBMS deberá garantizar que una transacción se ejecuta en su totalidad y nunca parcialmente. EL PROBLEMA DE LA ACTUALIZACIÓN PERDIDA T1 SELECT UPDATE Saldo Saldo (10000) (8000) SELECT UPDATE Saldo Saldo (10000) (9000) T2 En este escenario se están representando dos transacciones T1 y T2, que se ejecutan concurrentemente. La transacción T1 consiste en hacer un retiro de 2000 de una cuenta de cheques. En T2 se hace un retiro de 1000 de la misma cuenta de cheques. Observe que el resultado final es erróneo.

LOCKING

• La técnica de locking o bloqueo regula el acceso concurrente a objetos compartidos (datos). • Existe un componente del DBMS llamado lock manager que se encarga de otorgar locks a

petición de una transacción. • Un lock (candado) es un bloque de control que tiene la identificación del renglón al que está

asociado y la identificación de la transacción que solicitó el lock. • Si la transacción T tiene un lock sobre el registro R, entonces T tiene ciertas garantías sobre

R (por ejemplo, exclusividad) • La naturaleza de las garantías depende del tipo de lock.

LOCKS EXCLUSIVOS.

• Si la transacción T tiene un lock exclusivo sobre un renglón R, entonces, ninguna otra

transacción T’ podrá adquirir un lock de cualquier tipo sobre R hasta que T libere su lock. • Protocolo PX: cualquier transacción que intente actualizar un renglón R deberá, primero,

ejecutar un XREAD R para leer el renglón y adquirir un lock exclusivo sobre R. Si el lock no pude ser adquirido, la transacción pasará a un estado wait (espera); la transacción continuará su proceso cuando el renglón esté disponible y el lock pueda ser otorgado.

EL PROBLEMA DE LA ACTUALIZACION PERDIDA. T1 SELECT UPDATE XREAD Saldo saldo (10000) (8000) SELECT SELECT XREAD Saldo XREAD Saldo (WAIT) (8000) T2 DEADLOCKS

• El empleo de locks puede producir DEADLOCKS. • Un deadlock se presenta cuando 2 ó más transacciones están simultáneamente en estado

de wait, cada una esperando que se libere el lock otorgado a la otra. DEADLOCKS. . . T1 SELECT SELECT XREAD R1 XREAD R2 (WAIT) SELECT SELECT XREAD R2 XREAD R1 T2 WAIT

DEADLOCKS. . .

• Para resolver un deadlock se escoge una víctima (una de las transacciones en el deadlock) y se le hace ROLLBACK. El rollback, además de hacer un UNDO, deberá liberar todos los locks otorgados a la transacción víctima.

• A la transacción víctima se le notifica del deadlock a través de un código de retorno. EL PROBLEMA DE LA ACTUALIZACION PERDIDA. . . T1 SELECT UPDATE XREAD saldo saldo (10000) (8000) SELECT SELECT XREAD saldo . . . . . . . . . . . . XREAD saldo (WAIT) (8000) T2 EL PROBLEMA DE LA ACTUALIZACION PERDIDA T1 SELECT UPDATE XREAD saldo saldo ROLLBACK (10000) (8000) SELECT SELECT UPDATE XREAD saldo XREAD saldo saldo (WAIT) (8000) (7000) T2

PROTOCOLO PXC

• Para evitar la posibilidad de perder una actualización a causa de un ROLLBACK, no se debe permitir a ninguna transacción actualizar un uncommited change.

• PROTOCOLO PXC: se agrega al protocolo KPX una regla que establece que los locks exclusivos se retiene hasta el punto de COMMIT/ROLLBACK.

LOCKS COMPARTIDOS (SHARE) T1 T2 READ CTA 1(40) SUMA = SUMA + CTA1 (40) READ CTA 2 (50) SUMA = SUMA + CTA 2 (90) XREAD CTA 3, (30) UPDATE CTA 3, (20) XREAD CTA 1, (40) READ CTA3 (20) UPDATE CTA 1 (50) SUMA= SUMA + CTA 3 (40) COMMIT LOCKS COMPARTIDOS . . .

• T1 debería establecer un lock en cada cuenta según las va leyendo y retener estos locks

hasta terminar la suma. • El tipo de lock para T1 necesita ser exclusivo, aunque un lock exclusivo serviría, la

concurrencia se reduciría innecesariamente. • Se necesita un lock que impida que otra transacción cambien los valores de los datos,

aunque no hay ningún problema con permitir que otra transacción vea los datos. • Esto se puede resolver con un lock compartido.

LOCK COMPARTIDO

• Si una transacción T tiene un lock compartido sobre algún renglón, otra transacción T’ puede adquirir también un lock compartido sobre ese mismo renglón. Sin embargo, ninguna otra transacción T” puede adquirir un lock exclusivo sobre ese renglón hasta que no se hayan liberado todos los locks compartidos.

LOCKS COMPARTIDOS T1 T2 SREAD CTA 1(40) SUMA= SUMA + CTA 1(40) SREAD CTA 2, (50) SUMA = SUMA +CTA 2 (90) XREAD CTA 3, (30) UPDATE CTA 3, (20) XREAD CTA 1 WAIT SREAD CTA3 WAIT PROTOCOLO PSC

• Cualquier transacción que intente procesar un renglón R (incluye lectura y actualización), deberá ejecutar primero un SREAD R, par leer el renglón y adquirir un lock compartido sobre R.

• Cualquier intento subsecuente de actualizar el registro deberá hacerse por medio de un XUPDATE R que no sólo actualice el renglón sino que también promueva el lock s sobre ese renglón a un lock X

• Los locks X se retiene hasta el punto de COMMIT/ROLLBACK

MATRIZ DE COMPATIBILIDAD X S X NO NO SI S NO SI SI SI SI SI FALLAS

• Todo DBMS deberá estar construido a partir de la premisa de que las fallas son inevitables. • Las fallas pueden clasificarse en 4 tipos:

Fallas locales a un programa en ejecución detectadas por el programa Fallas locales a un programa en ejecución no detectada por el programa. Fallas globales que afectan a todas las transacciones en ejecución. Fallas en los dispositivos de almacenamiento.

El primer tipo de falla deberá ser manejado por el programa, apoyándose en las herramientas que el DBMS proporciona. Las fallas del segundo y tercer tipo deberán ser manejadas por el DBMS en forma automática. Las fallas del cuarto tipo se deberán resolver apoyándose en utilerías de recuperación proporcionadas por el DBMS.

RESPALDO Y RECUPERACIÓN.

• El DBMS debe contar con mecanismos que permitan recuperar los datos en caso de alguna falla.

• Los mecanismos de recuperación se basan en la redundancia controlada. • Por tanto deberá contar también con proceso par poder respaldar la información.

MECANISMOS DE RESPALDO Y RECUPERACIÓN.

• Por lo general, los DBMS proporcionan tres elementos básicos para resolver alguna falla:

Utilerías para hacer respaldo periódicos de las tablas Mecanismos para registrar en una bitácora o log todos los cambio efectuados a los

valores de los datos en las tablas Utilerías para poder restaurar o recupera tablas a partir de los respaldos y del log.

BITACORA O LOG

• Transferir 500 cheques (31561) a inversiones (100911) TABLAS

CTA NOMBRE SALDO……. ……. …….. 31561 RUBEN ADAD 1000 ……. …….. ……..

T1 Begin solicitar leer saldo cargo a abono a commit Monto cheques cheques inversiones Transferencia 500 500 TABLA OPER BEFORE IMAGE AFTER IMAGE TX

ID TX SEC

BEGIN T1 1 CHEQUES UPDATE 31561 RUBEN ABAD 1000 31561 RUBEN ABAD 500 T1 2 INVERSION UPDATE 100911 2000 RUBEN ABAD 100911 2500 RUBEN ABAD T1 3 COMMIT T1 4

CONTRATO MONTO NOMBRE ……. ……. ……. 100911 2000 RUBEN ADAD

EJEMPLO CON DOS TRANSACCIONES

• Transferir 500 de cheques (31561) a inversiones (100911)2) • Transferir 750 de cheques (35871) a inversiones (102456)

CUENTA DE CHEQUES CUENTA DE INVERSION NUMCTA NOMBRE SALDO …….. ………. ……… …….. ……… ……… 31561 R. LINARES 1000 35871 Q. RAMOS 1500 …….. ……… …….. Begin solicitar leer cargo abono commit Monto saldo cheques inversiones Transferencia por 500 por 500 Begin solicitar leer cargo abono commit Monto saldo cheques inversiones Transferencia por 750 por7 50 EJEMPLO CON DOS TRANSACCIONES tabla oper Before image Alter image Tx

id Tx sec

Begin T1 1 Begin T2 1 Cheques Update 35871 O. RAMOS 1500 35871 O. RAMOS 750 T2 2 Cheque Update 31561 R. LINARES 100 31561 R. LINARES

1500 T1 2

Inversiones Update 100911 2000 R. LINARES 100911 1500 R. LINARES

T1 3

Inversiones Update 102456 5000 O. RAMOS 102456 5000 O. RAMOS

T2 3

Commit T2 4 Commit T1 4

NUM CTA MONTO NOMBRE ……………. ……………. …………….. …………… ………………. …………….. 100911 2000 R. LINARES …………….. ……………… ………………. 102456 5000 Q. RAMOS

LOG ACTIVO Y LOG ARCHIVE LOG ACTIVO OFFLOAD LOG ARCHIVE O PASIVO Una alternativa es mantener un trozo de la bitácora en DASD y el resto en otro tipo de dispositivos mas económicos (cinta). Al pedazo del log que está en DASD se le denomina LOG ACTIVO; al que se almacena en cinta se le llama LOG ARCHIVE. El log activo se forma por un conjunto de n archivos que funcionan de forma rotativa. Cada vez que se llena un archivo se continúa en el sibolsa de trabajo siguiente y se hace una descarga (off load) asincrona del dataset lleno al archive log. TIPOS DE FALLAS

1) Fallas locales a la transacción que son detectadas por el propio programa 2) Fallas locales a las transacción que no son detectadas por el propio programa 3) Fallas del sistema que afectan a todas las transacciones en ejecución. 4) Fallas en los dispositivos de almacenamiento que dañan los datos

DATASET 1 DATASET 2 DATASET n

1) FALLAS LOCALES DETECTADAS

• Cuando la transacción descubre la falla, se puede ejecutar un ROLLBACK para asegurar que los datos no se corrompan.

Así, el ROLLBACK no es considerado como una falla de transacción sino como una terminación anormal prevista.

2) FALLAS LOCALES NO DETECTADAS

• En este caso el DBMS forzará el ROLLBACK para deshacer los cambios efectuados a los datos

3) FALLAS DEL SISTEMA

• El contenido de los buffers en memoria se pierde: Los datos no se dañan físicamente pero pueden reflejar un estado inválido.

• Al reiniciar el sistema, el DBMS revisa cada transacción que ejecutaba:

Dependiendo del punto donde se encontraba los concluye (COMMIT) o los deshace (ROLLBACK).

5) FALLAS EN LOS DISPOSITIVOS DE ALMACENAMIENTO.

Ultimo respaldo tomado LOG para rehacer los cambios Efectuados desde que se Tomo el respaldo

• Los datos grabados se destruyen y es necesario recuperarlos.

REDO

UTILERIAS PARA MANTENIMIENTO

Para tener un buen rendimiento, todo DBMS debe contar con diferentes procesos para mantener y ajustar las estructuras de datos.

• Reorganizar una tabla • Reorganizar un índice • Validar la integridad de un índice • Validad la integridad referencial • Generar estadística de una tabla • Etc.

Este tipo de utilerías se ejecutará en forma periódica dependiendo del volumen y volatilidad de los datos encada tabla. En lo general, las utilerías de mantenimiento se pueden agrupar en 3 clases:

1) Reorganización física: este tipo de utilerías se emplean para estructurar físicamente alguna tabla o índice con objeto de preservar las condiciones físicas con las que se diseñó originalmente, o bien, corregir alguna de estas condiciones (por ejemplo: tamaño, espacio reservado, orden físico, reagrupación de renglones fragmentados, etc.).

2) Validación de integridad: sin utilerías que chequean algún aspecto de la integridad de datos.

3) Reporteo y generación de estadística son utilerías para producir reportes sobre algún

aspecto del DBMS, o bien, para actualizar las estadísticas que emplean el optimizador para seleccionar trayectorias de acceso a los datos.

HERRAMIENTAS PARA MONITOREO La actividad de monitoreo consiste en un chequeo constante al ambiente de trabajo dentro de un SMBD con un conjunto de herramientas para supervisar el uso de los recursos. Los usuarios pueden configurar gráficos que presentan información acerca del uso de los recursos de forma gráfica. El Monitoreo tiene muchos contadores diferentes, cada uno de los cuales mide algún recurso del equipo. El Monitoreo es aplicable a actividades como las siguientes

Entrada/Salida Uso de la memoria Conexiones de usuario Bloqueos Actividad de duplicación

ADMINISTRACIÓN DE BASE DE DATOS La administración es la respuesta a la responsabilidad administrativa o suceso del ambiente del manejo de bases de datos en un servidor. El trabajo de un administrador conlleva diversas responsabilidades administrativas que no varían de un día para otro y que pueden resultar tareas tediosas. Una alternativa es automatizar todas aquellas actividades inherentes a la administración misma. Al automatizar las tareas administrativas puede disponer de más tiempo para realizar las tareas administrativas que requieren creatividad y carecen de respuestas predecibles o programables. Algunas tareas administrativas son las siguientes:

Creación de copias de seguridad de seguridad. Administración de múltiples servidores. Ejecución de programas rutinarios. Restauración de de bd’s. Creación y administración de usuarios y privilegios. Administración de dispositivos de respaldo y recuperación. Administrar y configurar módulos de los SMBD. Monitorear tablas de catálogo y de usuario. Monitorear trabajos de sesiones y usuarios. Diseñar y probar consultas para la obtención de datos. Etc.

Manejadores de Base de Datos_solonotas

Documents

Transcript of Manejadores de Base de Datos_solonotas