Manual Base de Datos II Completo by Miguel Sanchez Vicencio

UNIVERSIDAD TECNOLÓGICA DE LA HUASTECA HIDALGUENSE

TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

Manual de la asignatura del profesor: BASE DE DATOS II

Elaborado por: ISC LEODEGARIO REDONDO MARTÍNEZ

Revisado por Director de Carrera M en C FELIPE DE JESÚS NÚÑEZ CARDENAS

AGOSTO 2005

ÍNDICE FIRMAS DE AUTORIZACIÓN ...................................................................................................... 3 INTRODUCCIÓN........................................................................................................................... 4 UNIDAD TEMATICA 1. LENGUAJE DE CONSULTA ESTRUCTURADO ....................... 5 1.1. LA VENTAJA DEL SQL ......................................................................................................... 5 1.2. CONSULTA DE UNA SOLA TABLA .................................................................................... 9 1.3. CONSULTA DE TABLAS MULTIPLES .............................................................................. 25 1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O SUBCONSULTAS .......... 55 1.5. PROCEDIMIENTOS ALMACENADOS ............................................................................... 61 1.6. TRIGGERS ............................................................................................................................. 71 1.7. VISTAS ................................................................................................................................... 85 UNIDAD TEMATICA 2. INTEGRIDAD DE DATOS y MANEJO DE INDICES ............... 88 2.1. TIPOS DE INTEGRIDAD DE DATOS ................................................................................. 90 2.2. USANDO RESTRICCIONES (CONSTRAINTS)................................................................ 101 2.3. USANDO VALORES POR OMISIÓN Y REGLAS ............................................................ 102 2.4. INTRODUCCIÓN A INDICES ............................................................................................ 107 2.5. ARQUITECTURA y CREACIÓN DE INDICES ................................................................. 111 UNIDAD TEMATICA 3. TRANSACCIONES EN LA BASE DE DATOS ....................... 115 3.1. PROCESAMIENTO DE TRANSACCIONES ..................................................................... 116 3.2. CONCEPTOS DE TRANSACCIONES ............................................................................... 118 3.3. PROPIEDADES DE LAS TRANSACCIONES ................................................................... 118 3.4. PLANES Y RECUPERABILIDAD ...................................................................................... 121 3.5. SERIABILIDAD DE PLANES ............................................................................................. 122 3.6. TRANSACCIONES SQL ..................................................................................................... 125 UNIDAD TEMATICA 4. SEGURIDAD ........................................................................... 136 4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS .............................................. 136 4.2. TIPOS DE SEGURIDAD ..................................................................................................... 145 4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN / RENOVACION DE PRIVILEGIOS. ............................................................................................................................. 154 4.4. SEGUIMIENTO DE AUDITORIA ...................................................................................... 159 UNIDAD TEMATICA 5. BASES DE DATOS DISTRIBUIDAS ...................................... 165 5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES ................................. 165 5.2. MODELO GENERAL DE UN SGBD .................................................................................. 171 5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS. ............................................................................................... 177 UNIDAD TEMATICA 6. TECNOLOGÍAS DE ACCESO A DATOS .............................. 203 6.1. ARQUITECTURAS MULTICAPA y XML ......................................................................... 203 6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y ASP. ....................... 218 6.3. JDBC, PAGINAS DEL SERVIDOR JAVA. ........................................................................ 243 UNIDAD TEMATICA 7. PROYECTO FINAL ................................................................. 246

FIRMAS DE AUTORIZACIÓN

Elaboró

Revisó

ISC LEODEGARIO REDONDO MARTÍNEZ

M en C FELIPE DE JESÚS NÚÑEZ CARDENAS Directora de la Carrera

Vo. Bo.

Autorizó

MAD. Marisol Flores Contreras Directora de Enlace Académico

Dra. Miriam Yta Rectora

INTRODUCCIÓN Elevar la calidad académica de esta universidad se ha convertido en el objetivo a corto plazo, es de reconocer el esfuerzo aquí vertido para proporcionar a los estudiantes una formación de calidad, sin embargo, la participación global de una institución educativa obliga a una actualización permanente Dentro de este marco los materiales didácticos se convierten en instrumentos indispensable para ayudar a elevar la calidad educativa en las instituciones. Esta guía pretende proporcionar una visión de conjunto de la asignatura, así como señalar los conceptos fundamentales tratados en cada uno de los temas del programa. El objetivo principal que se persigue es el de ayudar al alumno a estructurar y organizar la información recogida en el manual para facilitar así la compresión de sus contenidos. Por tanto, el equipo docente recomienda a todos los alumnos de la carrera de Administración y Evaluación de Proyectos en que lean detenidamente la primera parte de esta Guía para tener una orientación general de la asignatura y que la consulten cuando estudien cada uno de los temas tratados en el texto, ya que en ella se proporcionarán las orientaciones didácticas precisas para su estudio. Creemos que esta Guía puede facilitar al alumno de la Universidad Tecnológica de la Huasteca Hidalguense un material didáctico adicional que contribuya al aprendizaje de los contenidos de la asignatura. Se indican igualmente en esta Guía, otra serie de medios con los que cuenta el alumno para el estudio. Todos ellos obedecen a un interés fundamental, reducir la distancia alumno-profesor. El presente manual representa ser un instrumento de

apoyo para que el

profesor lleve acabo una planeación por sesión y una revisión minuciosa de los contenidos para cumplir con el saber y saber hacer de una manera evidenciable, el curso se divide en 6 Unidades temáticas, las cuales incluyen las actividades de aprendizaje y los criterios de evaluación de cada actividad, el manual cuenta además con 2 anexos, a) Resumen de actividades de aprendizaje, b) Resumen de sesiones.

UNIDAD TEMATICA 1. LENGUAJE DE CONSULTA ESTRUCTURADO

El lenguaje SQL es usado para comunicarse con una base de datos según el ANSI (American National Standards Institute). Es el lenguaje clásico para sistemas manejadores de bases de datos relaciónales. Las declaraciones SQL son usadas para ejecutar tareas tales como: actualizar datos en una base de datos o recuperarlos, algunos sistemas manejadores de bases de datos relacionales que usan SQL son: Oracle, Sybase, Microsoft SQL Server, Access, Ingres, etc. Aunque más sistemas usan SQL tienen sus propias extensiones adicionales que usualmente son usadas sólo en sus propios sistemas. Las instrucciones normales tales como: “seleccionar”. “Insertar”, “actualizar”, “suprimir”, “crear”, y “borrar” pueden ser usadas para realizar casi todo lo que necesite hacer con una base de datos. 1.1. LA VENTAJA DEL SQL 1.1.1. OBJETIVO DE APRENDIZAJE Conocer los operadores del lenguaje SQL, para adquirir la habilidad de realizar consultas simples y complejas a una base de datos, asi como conocer las bases de SQL. 1.1.2. RECURSO TIEMPO DEL TEMA 1 hora 1.1.3. DESARROLLO Las aplicaciones en red son cada día más numerosas y versátiles. En muchos casos, el esquema básico de operación es una serie de scripts que rigen el comportamiento de una base de datos.

Debido a la diversidad de lenguajes y de bases de datos existentes, la manera de comunicar entre unos y otras sería realmente complicada a gestionar de no ser por la existencia de estándares que nos permiten el realizar las operaciones básicas de una forma universal.

Es de eso de lo que trata el Structured Query Language que no es mas que un lenguaje estándar de comunicación con bases de datos. Hablamos por tanto de

un lenguaje normalizado que nos permite trabajar con cualquier tipo de lenguaje (ASP o PHP) en combinación con cualquier tipo de base de datos (MS Access, SQL Server, MySQL...).

El hecho de que sea estándar no quiere decir que sea idéntico para cada base de datos. En efecto, determinadas bases de datos implementan funciones específicas

que

tienen

necesariamente

que

funcionar

otras.

Aparte de esta universalidad, el SQL posee otras dos características muy apreciadas. Por una parte, presenta una potencia y versatilidad notables que contrasta, por otra, con su accesibilidad de aprendizaje.

LENGUAJE DE CONSULTA ESTRUCTURADO SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por los diferentes motores de bases de datos para realizar determinadas operaciones sobre los datos o sobre la estructura de los mismos. Pero como sucede con cualquier sistema de normalización hay excepciones para casi todo; de hecho, cada motor de bases de datos tiene sus peculiaridades y lo hace diferente de otro motor, por lo tanto, el lenguaje SQL normalizado (ANSI) no nos servirá para resolver todos los problemas, aunque si se puede asegurar que cualquier sentencia escrita en ANSI será interpretable por cualquier motor de datos.

TRANSACT-SQL

Transact-SQL (T-SQL) es el lenguaje de programación del SQL Sever, a través de el podemos realizar muchas operaciones relacionadas con el SQL sin tener que volver a pasar por código VB, esto simplificará vuestro código y ganará en rapidez dado que el T-SQL se ejecuta dentro del SQL Server y es código compilado, se compila la primera vez que se ejecuta el Stored PROCEDURE.

EL T-SQL se puede utilizar desde multitud de aplicaciones y desde diferentes lenguajes de programación :



Desde Visual Basic



Desde Visual C++



Desde Active Server Pages (ASP)



...

No se utiliza dentro de estos lenguajes sino en desde los llamados Stored Procedures (SP) Sistema administrador para bases de datos relacionales (RDBMS)

El RDBMS es responsable de:  Mantener las relaciones entre la información y la Base de Datos.  Asegurarse de que la información es almacenada correctamente, es decir, que las reglas que definen las relaciones ente los datos no sean violadas.  Recuperar toda la información en un punto conocido en caso de que el sistema falle.

PLATAFORMAS PARA SQL

Los componentes Cliente y Servidor de SQL Server corren en los Sistemas Operativos mostrados en la siguiente tabla:

PLATAFORMA

COMPONENTE

SERVER

CLIENTE

Microsoft W in 95/98 Microsoft W indows NT Workstation 4.0 y posteriores Microsoft W indows NT Server 4.0 y posteriores Microsoft W indows NT Server Enterprise Edition 4.0 y posteriores Windows 3.X MS-DOS Third party

Si Si

No No No

Si Si Si (Unix, apple Macintosh) Si

Internet browsers

1.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.1.3.2.

MATERIAL DE APOYO

1.1.4. ACTIVIDADES DE APRENDIZAJE 1.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A1-T1 Cuestionario.

1.1.4.1.1. INSTRUCCIONES Realizar un cuestionario de 5 preguntas del tema visto. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 1.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Cuestionario del tema

DESARROLLO Formular preguntas y responderlas, estas se deben de transmitir hacia sus compañeros Total

PONDERACIÓN 5 puntos 5 Puntos

1.1.5. RESULTADO DE APRENDIZAJE Que el alumno sepa de las ventajas que tiene el utilizar SQL en este caso TRANSACT-SQL de SQL Server 2000. 1.1.6. BIBLIOGRAFÍA Ayuda SQL Server 2000 1.1.7. DOCUMENTOS

Manual SQL Server 2000 Standard final 1.2.

CONSULTA DE UNA SOLA TABLA

1.2.1. OBJETIVO DE APRENDIZAJE Crear la habilidad en los alumnos de poder aprovechar las ventajas de SQL, haciendo consultas sencillas a una sola tabla. 1.2.2. RECURSO TIEMPO DEL TEMA 2 horas 1.2.3. DESARROLLO

TIPOS DE CAMPO Como sabemos una base de datos esta compuesta de tablas donde almacenamos

registros

catalogados

función

distintos

campos

(características).

Un aspecto previo a considerar es la naturaleza de los valores que introducimos en esos campos. Dado que una base de datos trabaja con todo tipo de informaciones, es importante especificarle qué tipo de valor le estamos introduciendo de manera a, por un lado, facilitar la búsqueda posteriormente y por otro, optimizar los recursos de memoria.

Cada base de datos introduce tipos de valores de campo que no necesariamente están presentes en otras. Sin embargo, existe un conjunto de tipos que están representados en la totalidad de estas bases. Estos tipos comunes son los siguientes: Alfanuméricos Numéricos Booleanos

Contienen cifras y letras. Presentan una longitud limitada (255 caracteres) Existen de varios tipos, principalmente, enteros (sin decimales) y reales (con decimales). Poseen dos formas: Verdadero y falso (Sí o No) Almacenan fechas facilitando posteriormente su

Fechas

explotación. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los días entre

una fecha y otra... Son campos alfanuméricos de longitud ilimitada. Memos

Presentan el inconveniente de no poder ser indexados (veremos más adelante lo que esto quiere decir). Son campos numéricos enteros que incrementan en una

Autoincrementables

unidad su valor para cada registro incorporado. Su utilidad resulta más que evidente: Servir de identificador ya que resultan exclusivos de un registro. COMPONENTES DE SQL

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos. Existen dos tipos de comandos SQL: 

los DLL que permiten crear y definir nuevas bases de datos, campos e índices.



los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos. COMANDOS DDL

Comando CREATE DROP ALTER

Descripción Utilizado para crear nuevas tablas, campos e índices Empleado para eliminar tablas e índices Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos. COMANDOS DML

Comando SELECT

Descripción Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado

INSERT

UPDATE

DELETE

Utilizado para cargar lotes de datos en la base de datos en una única operación. Utilizado para modificar los valores de los campos y registros especificados Utilizado para eliminar registros de una tabla de una base de datos

CLAUSULAS Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.

Cláusula FROM

WHERE

GROUP BY

HAVING

ORDER BY

Descripción Utilizada para especificar la tabla de la cual se van a seleccionar los registros Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar Utilizada para separar los registros seleccionados en grupos específicos Utilizada para expresar la condición que debe satisfacer cada grupo Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico OPERADORES LÓGICOS

Operador AND

OR NOT

Uso Es el "y" lógico. Evalua dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas. Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdar si alguna de las dos es cierta. Negación lógica. Devuelve el valor contrario de la expresión.

OPERADORES DE COMPARACIÓN Operador

Uso

Menor que

Mayor que

Distinto de

Menor ó Igual que

Mayor ó Igual que

Igual que

BETWEEN Utilizado para especificar un intervalo de valores. LIKE IN

Utilizado en la comparación de un modelo Utilizado para especificar registros de una base de datos

FUNCIONES DE AGREGADO Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único.

Valor que se aplica a un grupo de registros. Función AVG COUNT SUM

MAX

MIN

Descripción Utilizada para calcular el promedio de los valores de un campo determinado Utilizada para devolver el número de registros de la selección Utilizada para devolver la suma de todos los valores de un campo determinado Utilizada para devolver el valor más alto de un campo especificado Utilizada para devolver el valor más bajo de un campo especificado

ORDEN DE EJECUCIÓN DE LOS COMANDOS

Dada una sentencia SQL de selección que incluye todas las posibles cláusulas, el orden de ejecución de las mismas es el siguiente: 1.

Cláusula FROM

Cláusula WHERE

Cláusula GROUP BY

Cláusula HAVING

Cláusula SELECT

Cláusula ORDER BY CONSULTAS DE SELECCIÓN

Bases de datos-SQL-Sentencias SQL-Consultas de Selección Las consultas de selección se utilizan para indicar al motor de datos que devuelva información de las bases de datos, esta información es devuelta en forma de conjunto de registros que se pueden almacenar en un objeto recordset. Este conjunto de registros puede ser modificable.

Consultas básicas

La sintaxis básica de una consulta de selección es la siguiente:

SELECT Campos FROM Tabla

En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los mismos, por ejemplo:

SELECT Nombre, Teléfono FROM Clientes

Esta sentencia devuelve un conjunto de resultados con el campo nombre y teléfono de la tabla clientes.

DEVOLVER LITERALES

En determinadas ocasiones nos puede interesar incluir una columna con un texto fijo en una consulta de selección, por ejemplo, supongamos que tenemos una tabla de empleados y deseamos recuperar las tarifas semanales de los electricistas, podríamos realizar la siguiente consulta:

SELECT Empleados.Nombre, 'Tarifa semanal: ', Empleados.TarifaHora * 40 FROM Empleados WHERE Empleados.Cargo = 'Electricista'

ORDENAR LOS REGISTROS

Adicionalmente se puede especificar el orden en que se desean recuperar los registros de las tablas mediante la cláusula ORDER y Lista de Campos. En donde Lista de campos representa los campos a ordenar. Ejemplo:

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER y Nombre

Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla Clientes ordenados por el campo Nombre.

Se pueden ordenar los registros por mas de un campo, como por ejemplo:

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER y CodigoPostal, Nombre

Incluso se puede especificar el orden de los registros: ascendente mediante la cláusula (ASC - se toma este valor por defecto) ó descendente (DESC)

SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER y CodigoPostal DESC , Nombre ASC

USO DE ÍNDICES DE LAS TABLAS

Si deseamos que la sentencia SQL utilice un índice para mostrar los resultados se puede utilizar la palabra reservada INDEX de la siguiente forma:

SELECT ... FROM Tabla (INDEX=Indice) ...

Normalmente los motores de las bases de datos deciden que indice se debe utilizar para la consulta, para ello utilizan criterios de rendimiento y sobre todo los campos de búsqueda especificados en la cláusula WHERE. Si se desea forzar a no utilizar ningún índice utilizaremos la siguiente sintaxis:

SELECT ... FROM Tabla (INDEX=0) ...

CONSULTAS CON PREDICADO El predicado se incluye entre la cláusula y el primer nombre del campo a recuperar, los posibles predicados son: PREDICADO

DESCRIPCIÓN

ALL

Devuelve todos los campos de la tabla

TOP

Devuelve un determinado número de registros de la tabla

DISTINCT

DISTINCTROW

Omite

los

registros

cuyos

campos

seleccionados

coincidan totalmente Omite los registros duplicados basandose en la totalidad del registro y no sólo en los campos seleccionados.

ALL Si no se incluye ninguno de los predicados se asume ALL. El Motor de base de datos selecciona todos los registros que cumplen las condiciones de la instrucción SQL y devuelve todos y cada uno de sus campos. No es conveniente abusar de este predicado ya que obligamos al motor de la base de datos a analizar la estructura de la tabla para averiguar los campos que contiene, es mucho más rápido indicar el listado de campos deseados.

SELECT ALL FROM Empleados SELECT * FROM Empleados

TOP Devuelve un cierto número de registros que entran entre al principio o al final de un rango especificado por una cláusula ORDER y. Supongamos que queremos recuperar los nombres de los 25 primeros estudiantes del curso 1994:

SELECT TOP 25 Nombre, Apellido FROM Estudiantes ORDER y Nota DESC

Si no se incluye la cláusula ORDER y, la consulta devolverá un conjunto arbitrario de 25 registros de la tabla de Estudiantes. El predicado TOP no elige entre valores iguales. En el ejemplo anterior, si la nota media número 25 y la 26 son iguales, la consulta devolverá 26 registros. Se puede utilizar la palabra reservada PERCENT para devolver un cierto porcentaje de registros que caen al principio o al final de un rango especificado por la cláusula ORDER y. Supongamos que en lugar de los 25 primeros estudiantes deseamos el 10 por ciento del curso:

SELECT TOP 10 PERCENT Nombre, Apellido FROM Estudiantes ORDER y Nota DESC

El valor que va a continuación de TOP debe ser un entero sin signo. TOP no afecta a la posible actualización de la consulta.

DISTINCT Omite los registros que contienen datos duplicados en los campos seleccionados. Para que los valores de cada campo listado en la instrucción SELECT se incluyan en la consulta deben ser únicos. Por ejemplo, varios empleados listados en la tabla Empleados pueden tener el mismo apellido. Si

dos registros contienen López en el campo Apellido, la siguiente instrucción SQL devuelve un único registro:

SELECT DISTINCT Apellido FROM Empleados

Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la cláusula SELECT posean un contenido diferente. El resultado de una consulta que utiliza DISTINCT no es actualizable y no refleja los cambios subsiguientes realizados por otros usuarios.

DISTINCTROW Este predicado no es compatible con ANSI. Que yo sepa a día de hoy sólo funciona con ACCESS. Devuelve los registros diferentes de una tabla; a diferencia del predicado anterior que sólo se fijaba en el contenido de los campos seleccionados, éste lo hace en el contenido del registro completo independientemente de los campos indicados en la cláusula SELECT.

SELECT DISTINCTROW Apellido FROM Empleados

Si la tabla empleados contiene dos registros: Antonio López y Marta López el ejemplo del predicado DISTINCT devuelve un único registro con el valor López en el campo Apellido ya que busca no duplicados en dicho campo. Este último ejemplo devuelve dos registros con el valor López en el apellido ya que se buscan no duplicados en el registro completo.

ALIAS En determinadas circunstancias es necesario asignar un nombre a alguna columna determinada de un conjunto devuelto, otras veces por simple capricho o porque estamos recuperando datos de diferentes tablas y resultan tener un campo con igual nombre. Para resolver todas ellas tenemos la palabra reservada AS que se encarga de asignar el nombre que deseamos a la

columna deseada. Tomado como referencia el ejemplo anterior podemos hacer que la columna devuelta por la consulta, en lugar de llamarse apellido (igual que el campo devuelto) se llame Empleado. En este caso procederíamos de la siguiente forma:

SELECT DISTINCTROW Apellido AS Empleado FROM Empleados

AS no es una palabra reservada de ANSI, existen diferentes sistemas de asignar los alias en función del motor de bases de datos. En ORACLE para asignar un alias a un campo hay que hacerlo de la siguiente forma:

SELECT Apellido AS "Empleado" FROM Empleados

También podemos asignar alias a las tablas dentro de la consulta de selección, en esta caso hay que tener en cuenta que en todas las referencias que deseemos hacer a dicha tabla se ha de utilizar el alias en lugar del nombre. Esta técnica será de gran utilidad más adelante cuando se estudien las vinculaciones entre tablas. Por ejemplo:

SELECT Apellido AS Empleado FROM Empleados AS Trabajadores

Para asignar alias a las tablas en ORACLE y SQL-SERVER los alias se asignan escribiendo el nombre de la tabla, dejando un espacio en blanco y escribiendo el Alias (se asignan dentro de la cláusula FROM). SELECT Trabajadores.Apellido (1) AS Empleado FROM Empleados Trabajadores (1)

Esta nomenclatura [Tabla].[Campo] se debe utilizar cuando se está

recuperando un campo cuyo nombre se repite en varias de las tablas que se utilizan en la sentencia. No obstante cuando en la sentencia se emplean varias tablas es aconsejable utilizar esta nomenclatura para evitar el trabajo que supone al motor de datos averiguar en que tabla está cada uno de los campos indicados en la cláusua SELECT.

RECUPERAR INFORMACIÓN DE UNA BASE DE DATOS EXTERNA

Para concluir este capítulo se debe hacer referencia a la recuperación de registros de bases de datos externas. Es ocasiones es necesario la recuperación de información que se encuentra contenida en una tabla que no se encuentra en la base de datos que ejecutará la consulta o que en ese momento no se encuentra abierta, esta situación la podemos salvar con la palabra reservada IN de la siguiente forma:

SELECT Apellido AS Empleado FROM Empleados IN 'c: \databases\gestion.mdb'

En donde c: \databases\gestion.mdb es la base de datos que contiene la tabla Empleados. Esta técnica es muy sencilla y común en bases de datos de tipo ACCESS en otros sistemas como SQL-SERVER u ORACLE, la cosa es más complicada la tener que existir relaciones de confianza entre los servidores o al ser necesaria la vinculación entre las bases de datos. Este ejemplo recupera la información de una base de datos de SQL-SERVER ubicada en otro servidor (se da por supuesto que los servidores están lincados):

SELECT Apellido FROM Servidor1.BaseDatos1.dbo.Empleados

CONSULTAS DE ACCIÓN

Bases de datos-SQL-Sentencias SQL-Consultas de Acción

Las consultas de acción son aquellas que no devuelven ningún registro, son las encargadas de acciones como añadir y borrar y modificar registros. Tanto las sentencias de actualización como las de borrado desencaderán (según el motor de datos) las actualizaciones en cascada, borrados en cascada, restricciones y valores por defecto definidos para los diferentes campos o tablas afectadas por la consulta.

DELETE Crea una consulta de eliminación que elimina los registros de una o más de las tablas listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta consulta elimina los registros completos, no es posible eliminar el contenido de algún campo en concreto. Su sintaxis es:

DELETE FROM Tabla WHERE criterio

Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la operación. Si desea saber qué registros se eliminarán, primero examine los resultados de una consulta de selección que utilice el mismo criterio y después ejecute la consulta de borrado. Mantenga copias de seguridad de sus datos en todo momento. Si elimina los registros equivocados podrá recuperarlos desde las copias de seguridad.

DELETE

FROM Empleados WHERE Cargo = 'Vendedor'

INSERT INTO Agrega un registro en una tabla. Se la conoce como una consulta de datos añadidos. Esta consulta puede ser de dos tipo: Insertar un único registro ó Insertar en una tabla los registros contenidos en otra tabla. Para insertar un único Registro: En este caso la sintaxis es la siguiente:

INSERT INTO Tabla (campo1, campo2, ..., campoN) VALUES (valor1, valor2, ..., valorN)

Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así sucesivamente. Para seleccionar registros e insertarlos en una tabla nueva En este caso la sintaxis es la siguiente:

SELECT campo1, campo2, ..., campoN INTO nuevatabla FROM tablaorigen [WHERE criterios]

Se pueden utilizar las consultas de creación de tabla para archivar registros, hacer copias de seguridad de las tablas o hacer copias para exportar a otra base de datos o utilizar en informes que muestren los datos de un periodo de tiempo concreto. Por ejemplo, se podría crear un informe de Ventas mensuales por región ejecutando la misma consulta de creación de tabla cada mes. Para insertar Registros de otra Tabla: En este caso la sintaxis es:

INSERT INTO Tabla [IN base_externa] (campo1, campo2,..., campoN) SELECT TablaOrigen.campo1, TablaOrigen.campo2,...,TablaOrigen.campoN FROM Tabla Origen

En este caso se seleccionarán los campos 1,2,..., n de la tabla origen y se grabarán en los campos 1,2,.., n de la Tabla. La condición SELECT puede incluir la cláusula WHERE para filtrar los registros a copiar. Si Tabla y Tabla Origen poseen la misma estructura podemos simplificar la sintaxis a:

INSERT INTO Tabla SELECT Tabla Origen.* FROM Tabla Origen

De esta forma los campos de Tabla Origen se grabarán en Tabla, para realizar esta operación es necesario que todos los campos de Tabla Origen estén contenidos con igual nombre en Tabla. Con otras palabras que Tabla posea todos los campos de Tabla Origen (igual nombre e igual tipo). En este tipo de consulta hay que tener especial atención con los campos contadores o autonuméricos puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo homólogo en la tabla origen, no incrementándose como le corresponde. Se puede utilizar la instrucción INSERT INTO para agregar un registro único a una tabla, utilizando la sintaxis de la consulta de adición de registro único tal y como se mostró anteriormente. En este caso, su código especifica el nombre y el valor de cada campo del registro. Debe especificar cada uno de los campos

del registro al que se le va a asignar un valor así como el valor para dicho campo. Cuando no se especifica dicho campo, se inserta el valor predeterminado o NULL. Los registros se agregan al final de la tabla. También se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra tabla o consulta utilizando la cláusula SELECT... FROM como se mostró anteriormente en la sintaxis de la consulta de adición de múltiples registros. En este caso la cláusula SELECT especifica los campos que se van a agregar en la tabla destino especificada. La tabla destino u origen puede especificar una tabla o una consulta. Si la tabla destino contiene una clave principal, hay que asegurarse que es única, y con valores no nulos; si no es así, no se agregarán los registros. Si se agregan registros a una tabla con un campo Contador, no se debe incluir el campo Contador en la consulta. Se puede emplear la cláusula IN para agregar registros a una tabla en otra base de datos. Se pueden averiguar los registros que se agregarán en la consulta ejecutando primero una consulta de selección que utilice el mismo criterio de selección y ver el resultado. Una consulta de adición copia los registros de una o más tablas en otra. Las tablas que contienen los registros que se van a agregar no se verán afectadas por la consulta de adición. En lugar de agregar registros existentes en otra tabla, se puede especificar los valores de cada campo en un nuevo registro utilizando la cláusula VALUES. Si se omite la lista de campos, la cláusula VALUES debe incluir un valor para cada campo de la tabla, de otra forma fallará INSERT. EJEMPLOS

INSERT INTO Clientes SELECT ClientesViejos.* FROM ClientesNuevos SELECT Empleados.* INTO Programadores FROM Empleados WHERE Categoria = 'Programador'

Esta consulta crea una tabla nueva llamada programadores con igual estructura que la tabla empleado y copia aquellos registros cuyo campo categoría se programador

INSERT INTO Empleados (Nombre, Apellido, Cargo)

VALUES ( 'Luis', 'Sánchez', 'Becario' )

INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores WHERE Provincia = 'Madrid'

UPDATE Crea una consulta de actualización que cambia los valores de los campos de una tabla especificada basándose en un criterio específico. Su sintaxis es:

UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, CampoN=ValorN WHERE Criterio

UPDATE es especialmente útil cuando se desea cambiar un gran número de registros o cuando éstos se encuentran en múltiples tablas. Puede cambiar varios campos a la vez. El ejemplo siguiente incrementa los valores Cantidad pedidos en un 10 por ciento y los valores Transporte en un 3 por ciento para aquellos que se hayan enviado al Reino Unido.:

UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03 WHERE PaisEnvío = 'ES'

UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar, hay que examinar primero el resultado de una consulta de selección que utilice el mismo criterio y después ejecutar la consulta de actualización.

UPDATE Empleados SET Grado = 5 WHERE Grado = 2 UPDATE Productos SET Precio = Precio * 1.1 WHERE Proveedor = 8 AND Familia = 3

Si en una consulta de actualización suprimimos la cláusula WHERE todos los registros de la tabla señalada serán actualizados.

UPDATE Empleados SET Salario = Salario * 1.1 1.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.2.3.2.

MATERIAL DE APOYO

1.2.4. ACTIVIDADES DE APRENDIZAJE 1.2.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A2-T2 Realizar Base de Datos

1.2.4.1.1. INSTRUCCIONES Traducir el siguiente esquema Entidad Relación a una base de datos en SQL Server 2000 y colocarle el nombre de “ESQUINITA”. ABARROTES “LA ESQUINITA”

a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Base de datos. Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Equipo (3 gentes) 1.2.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Realizar Base de Datos

DESARROLLO Traducir el esquema entidad relacion a una base de datos en SQL Server 2000 Total

1.2.5. RESULTADO DE APRENDIZAJE

PONDERACIÓN 5 puntos 5 Puntos

Aprender a crear bases de datos en SQL Server 2000. 1.2.6. BIBLIOGRAFÍA SQL Server 7.0 1.2.7. DOCUMENTOS Manual SQL Server 2000 Standard final 1.3.

CONSULTA DE TABLAS MULTIPLES

1.3.1. OBJETIVO DE APRENDIZAJE Que el alumno aprenda a manejar consultas un tanto mas complejas, solucionando las necesidades mas comunes de una BD. 1.3.2. RECURSO TIEMPO DEL TEMA 3 horas. 1.3.3. DESARROLLO

CONSULTAS DE UNIÓN INTERNAS Bases de datos-SQL-Sentencias SQL-Consultas de Unión Internas CONSULTAS DE COMBINACIÓN ENTRE TABLAS Las vinculaciones entre tablas se realizan mediante la cláusula INNER que combina registros de dos tablas siempre que haya concordancia de valores en un campo común. Su sintaxis es:

SELECT campos FROM tb1 INNER JOIN tb2 ON tb1.campo1 comp tb2.campo2

En donde:

tb1, tb2

Son los nombres de las tablas desde las que se combinan los registros. Son los nombres de los campos que se combinan. Si no son

campo1,

numéricos, los campos deben ser del mismo tipo de datos y

campo2

contener el mismo tipo de datos, pero no tienen que tener el mismo nombre.

Es cualquier operador de comparación relacional: =, <,<>, <=,

comp

=>, ó >.

Se puede utilizar una operación INNER JOIN en cualquier cláusula FROM. Esto crea una combinación por equivalencia, conocida también como unión interna. Las combinaciones equivalentes son las más comunes; éstas combinan los registros de dos tablas siempre que haya concordancia de valores en un campo común a ambas tablas. Se puede utilizar INNER JOIN con las tablas Departamentos y Empleados para seleccionar todos los empleados de cada departamento. Por el contrario, para seleccionar todos los departamentos (incluso si alguno de ellos no tiene ningún empleado asignado) se emplea LEFT JOIN o todos los empleados (incluso si alguno no está asignado a ningún departamento), en este caso RIGHT JOIN. Si se intenta combinar campos que contengan datos Memo u Objeto OLE, se produce

ERROR.

pueden

combinar

dos

campos

numéricos

cualesquiera, incluso si son de diferente tipo de datos. Por ejemplo, puede combinar un campo Numérico para el que la propiedad Size de su objeto Field está establecida como Entero, y un campo Contador. El ejemplo siguiente muestra cómo podría combinar las tablas Categorías y Productos basándose en el campo IDCategoria:

SELECT NombreCategoria, NombreProducto FROM Categorias INNER JOIN Productos ON Categorias.IDCategoria = Productos.IDCategoria

En el ejemplo anterior, IDCategoria es el campo combinado, pero no está incluido en la salida de la consulta ya que no está incluido en la instrucción SELECT. Para incluir el campo combinado, incluir el nombre del campo en la instrucción SELECT, en este caso, Categorias.IDCategoria. También se pueden enlazar varias cláusulas ON en una instrucción JOIN, utilizando la sintaxis siguiente:

SELECT campos FROM tabla1 INNER JOIN tabla2

ON (tb1.campo1 comp tb2.campo1 AND ON tb1.campo2 comp tb2.campo2) OR ON (tb1.campo3 comp tb2.campo3)

También puede anidar instrucciones JOIN utilizando la siguiente sintaxis:

SELECT campos FROM tb1 INNER JOIN (tb2 INNER JOIN [( ]tb3 [INNER JOIN [( ]tablax [INNER JOIN ...)] ON tb3.campo3 comp tbx.campox)] ON tb2.campo2 comp tb3.campo3) ON tb1.campo1 comp tb2.campo2

Un LEFT JOIN o un RIGHT JOIN puede anidarse dentro de un INNER JOIN, pero un INNER JOIN no puede anidarse dentro de un LEFT JOIN o un RIGHT JOIN. Ejemplo:

SELECT DISTINCT SUM(PrecioUnitario * Cantidad) AS Sales, (Nombre + ' ' + Apellido) AS Name FROM Empleados INNER JOIN( Pedidos INNER JOIN DetallesPedidos ON Pedidos.IdPedido = DetallesPedidos.IdPedido) ON Empleados.IdEmpleado = Pedidos.IdEmpleado GROUP y Nombre + ' ' + Apellido

(Crea dos combinaciones equivalentes: una entre las tablas Detalles de pedidos y Pedidos, y la otra entre las tablas Pedidos y Empleados. Esto es necesario ya que la tabla Empleados no contiene datos de ventas y la tabla Detalles de pedidos no contiene datos de los empleados. La consulta produce una lista de empleados y sus ventas totales.)

Si empleamos la cláusula INNER en la consulta se seleccionarán sólo aquellos registros de la tabla de la que hayamos escrito a la izquierda de INNER JOIN que contengan al menos un registro de la tabla que hayamos escrito a la derecha. Para solucionar esto tenemos dos cláusulas que sustituyen a la palabra clave INNER, estas cláusulas son LEFT y RIGHT. LEFT toma todos

los registros de la tabla de la izquierda aunque no tengan ningún registro en la tabla de la izquierda. RIGHT realiza la misma operación pero al contrario, toma todos los registros de la tabla de la derecha aunque no tenga ningún registro en la tabla de la izquierda. La sintaxis expuesta anteriormente pertenece a ACCESS, en donde todas las sentencias con la sintaxis funcionan correctamente. Los manuales de SQLSERVER dicen que esta sintaxis es incorrecta y que hay que añadir la palabra reservada OUTER: LEFT OUTER JOIN y RIGHT OUTER JOIN. En la práctica funciona correctamente de una u otra forma. No obstante, los INNER JOIN ORACLE no es capaz de interpretarlos, pero existe una sintaxis en formato ANSI para los INNER JOIN que funcionan en todos los sistemas. Tomando como referencia la siguiente sentencia:

SELECT Facturas.*, Albaranes.* FROM Facturas INNER JOINAlbaranes ON Facturas.IdAlbaran = Albaranes.IdAlbaran WHERE Facturas.IdCliente = 325

La transformación de esta sentencia a formato ANSI sería la siguiente:

SELECT Facturas.*, Albaranes.* FROM Facturas, Albaranes WHERE Facturas.IdAlbaran = Albaranes.IdAlbaran AND Facturas.IdCliente = 325

Como se puede observar los cambios realizados han sido los siguientes: 1.

Todas las tablas que intervienen en la consulta se especifican en la

cláusula FROM. 2.

Las condiciones que vinculan a las tablas se especifican en la cláusula

WHERE y se vinculan mediante el operador lógico AND. Referente a los OUTER JOIN, no funcionan en ORACLE y además conozco una sintaxis que funcione en los tres sistemas. La sintaxis en ORACLE es igual a la sentencia anterior pero añadiendo los caracteres (+) detrás del nombre de

la tabla en la que deseamos aceptar valores nulos, esto equivale a un LEFT JOIN:

SELECT Facturas.*, Albaranes.* FROM Facturas, Albaranes WHERE Facturas.IdAlbaran = Albaranes.IdAlbaran (+) AND Facturas.IdCliente = 325

Y esto a un RIGHT JOIN:

SELECT Facturas.*, Albaranes.* FROM Facturas, Albaranes WHERE Facturas.IdAlbaran (+) = Albaranes.IdAlbaran AND Facturas.IdCliente = 325

En SQL-SERVER se puede utilizar una sintaxis parecida, en este caso no se utiliza los caracteres (+) sino los caracteres =* para el LEFT JOIN y *= para el RIGHT JOIN.

CONSULTAS DE AUTOCOMBINACIÓN La autocombinación se utiliza para unir una tabla consigo misma, comparando valores de dos columnas con el mismo tipo de datos. La sintaxis en la siguiente:

SELECT alias1.columna, alias2.columna, ... FROM tabla1 AS alias1, tabla2 AS alias2 WHERE alias1.columna = alias2.columna AND otras condiciones

Por ejemplo, para visualizar el número, nombre y puesto de cada empleado, junto con el número, nombre y puesto del supervisor de cada uno de ellos se utilizaría la siguiente sentencia:

SELECT t.num_emp, t.nombre, t.puesto, t.num_sup,s.nombre, s.puesto FROM empleados AS t, empleados AS s WHERE t.num_sup = s.num_emp

CONSULTAS DE COMBINACIONES NO COMUNES

La mayoría de las combinaciones están basadas en la igualdad de valores de las columnas que son el criterio de la combinación. Las no comunes se basan en otros operadores de combinación, tales como NOT, BETWEEN, <>, etc. Por ejemplo, para listar el grado salarial, nombre, salario y puesto de cada empleado ordenando el resultado por grado y salario habría que ejecutar la siguiente sentencia: SELECT grados.grado,empleados.nombre, empleados.salario, empleados.puesto FROM empleados, grados WHERE empleados.salario BETWEEN grados.salarioinferior AND grados.salariosuperior ORDER y grados.grado, empleados.salario

Para listar el salario medio dentro de cada grado salarial habría que lanzar esta otra sentencia:

SELECT grados.grado, AVG(empleados.salario) FROM empleados, grados WHERE empleados.salario BETWEEN grados.salarioinferior AND grados.salariosuperior GROUP y grados.grado

CROSS JOIN (SQL-SERVER)

Se utiliza en SQL-SERVER para realizar consultas de unión. Supongamos que tenemos una tabla con todos los autores y otra con todos los libros. Si

deseáramos obtener un listado combinar ambas tablas de tal forma que cada autor apareciera junto a cada título, utilizaríamos la siguiente sintaxis:

SELECT Autores.Nombre, Libros.Titulo FROM Autores CROSS JOIN Libros

SELF JOIN SELF JOIN es una técnica empleada para conseguir el producto cartesiano de una tabla consigo misma. Su utilización no es muy frecuente, pero pongamos algún ejemplo de su utilización. Supongamos la siguiente tabla (El campo autor es numérico, aunque para ilustrar el ejemplo utilice el nombre):

Autores Código (Código del libro)

Autor (Nombre del Autor)

B0012

1. Francisco López

B0012

2. Javier Alonso

B0012

3. Marta Rebolledo

C0014

1. Francisco López

C0014

2. Javier Alonso

D0120

2. Javier Alonso

D0120

3. Marta Rebolledo

Queremos obtener, para cada libro, parejas de autores:

SELECT A.Codigo, A.Autor, B.Autor FROM Autores A, Autores B WHERE A.Codigo = B.Codigo

El resultado es el siguiente:

Código

Autor

B0012

1. Francisco López

B0012

1. Francisco López

2. Javier Alonso

B0012

1. Francisco López

3. Marta Rebolledo

B0012

2. Javier Alonso

B0012

2. Javier Alonso

1. Francisco López

B0012

2. Javier Alonso

3. Marta Rebolledo

B0012

3. Marta Rebolledo

B0012

3. Marta Rebolledo

2. Javier Alonso

B0012

3. Marta Rebolledo

1. Francisco López

C0014

1. Francisco López

C0014

1. Francisco López

2. Javier Alonso

C0014

2. Javier Alonso

C0014

2. Javier Alonso

1. Francisco López

D0120

2. Javier Alonso

D0120

2. Javier Alonso

3. Marta Rebolledo

D0120

3. Marta Rebolledo

D0120

3. Marta Rebolledo

2. Javier Alonso

Como podemos observar, las parejas de autores se repiten en cada uno de los libros, podemos omitir estas repeticiones de la siguiente forma

SELECT A.Codigo, A.Autor, B.Autor FROM Autores A, Autores B WHERE A.Codigo = B.Codigo AND A.Autor < B.Autor

El resultado ahora es el siguiente: Código

Autor

B0012

1. Francisco López

2. Javier Alonso

B0012

1. Francisco López

3. Marta Rebolledo

C0014

1. Francisco López

2. Javier Alonso

D0120

2. Javier Alonso

3. Marta Rebolledo

Ahora tenemos un conjunto de resultados en formato Autor - CoAutor. Si en la tabla de empleados quisiéramos extraer todas las posibles parejas que podemos realizar, utilizaríamos la siguiente sentencia:

SELECT Hombres.Nombre, Mujeres.Nombre FROM Empleados Hombre, Empleados Mujeres WHERE Hombre.Sexo = 'Hombre' AND Mujeres.Sexo = 'Mujer' AND Hombres.Id <>Mujeres.Id

Para concluir supongamos la tabla siguiente:

Empleados Id

Nombre

SuJefe

Marcos

Lucas

Ana

Eva

Juan

Antonio

Queremos obtener un conjunto de resultados con el nombre del empleado y el nombre de su jefe:

SELECT Emple.Nombre, Jefes.Nombre FROM Empleados Emple, Empleados Jefe WHERE Emple.SuJefe = Jefes.Id

FULL JOIN Este tipo de operador se utiliza para devolver todas las filas de una combinación tengan o no correspondencia. Es el equivalente a la utilización de LEFT JOIN y RIGHT JOIN a la misma vez. Mediante este operador se obtendrán por un lado las filas que tengan correspondencia en ambas tablas y también aquellas que no tengan correspondencia sean de la tabla que sean. Si desearamos obtener un listado que incluyera todos los autores con sus libros correspondientes, pero además todos los autores que no han escrito ningún libro y todos aquellos libros sin autor (devemos suponer que no existe un autor llamado anónimo):

SELECT Autores.*, Libros.* FROM Autores FULL Libros ON Autores.IdAutor = Libros.IdAutor

CONSULTAS DE UNIÓN EXTERNAS

Bases de datos-SQL-Sentencias SQL-Consultas de Unión Externas Se utiliza la operación UNION para crear una consulta de unión, combinando los resultados de dos o más consultas o tablas independientes. Su sintaxis es:

[TABLE] consulta1 UNION [ALL] [TABLE] consulta2 [UNION [ALL] [TABLE] consultan [ ... ]]

En donde: consulta

Son instrucciones SELECT, el nombre de una

1,consulta 2,

consulta almacenada o el nombre de una tabla

consulta n

almacenada precedido por la palabra clave TABLE.

Puede combinar los resultados de dos o más consultas, tablas e instrucciones SELECT, en cualquier orden, en una única operación UNION. El ejemplo siguiente combina una tabla existente llamada Nuevas Cuentas y una instrucción SELECT:

TABLE NuevasCuentas UNION ALL SELECT * FROM Clientes WHERE CantidadPedidos > 1000

Si no se indica lo contrario, no se devuelven registros duplicados cuando se utiliza la operación UNION, no obstante puede incluir el predicado ALL para asegurar que se devuelven todos los registros. Esto hace que la consulta se ejecute más rápidamente. Todas las consultas en una operación UNION deben pedir el mismo número de campos, no obstante los campos no tienen porqué tener el mismo tamaño o el mismo tipo de datos. Se puede utilizar una cláusula GROUP y y/o HAVING en cada argumento consulta para agrupar los datos devueltos. Puede utilizar una cláusula ORDER y al final del último argumento consulta para visualizar los datos devueltos en un orden específico.

SELECT NombreCompania, Ciudad FROM Proveedores WHERE Pais = 'Brasil' UNION SELECT NombreCompania, Ciudad FROM Clientes WHERE Pais = 'Brasil'

Recupera los nombres y las ciudades de todos proveedores y clientes de Brasil

SELECT NombreCompania, Ciudad FROM Proveedores WHERE Pais = 'Brasil' UNION SELECT NombreCompania, Ciudad FROM Clientes WHERE Pais = 'Brasil' ORDER y Ciudad

Recupera los nombres ylas ciudades de todos proveedores yclientes radicados en Brasil, ordenados por el nombre de la ciudad

SELECT NombreCompania, Ciudad FROM Proveedores WHERE Pais = 'Brasil' UNION SELECT NombreCompania, Ciudad FROM Clientes WHERE Pais = 'Brasil' UNION SELECT Apellidos, Ciudad FROM Empleados WHERE Region = 'América del Sur'

Recupera los nombres y las ciudades de todos los proveedores y clientes de brasil y los apellidos y las ciudades de todos los empleados de América del Sur

TABLE Lista_Clientes UNION TABLE ListaProveedores

Recupera los nombres y códigos de todos los proveedores y clientes

REFERENCIAS CRUZADAS Bases de datos-SQL-Sentencias SQL-Referencias Cruzadas

ACCESS Una consulta de referencias cruzadas es aquella que nos permite visualizar los datos en filas y en columnas, estilo tabla, por ejemplo: Producto / Año

1996

1997

Pantalones

1.250

3.000

Camisas

8.560

1.253

Zapatos

4.369

2.563

Si tenemos una tabla de productos y otra tabla de pedidos, podemos visualizar en total de productos pedidos por año para un artículo determinado, tal y como

se visualiza en la tabla anterior. La sintaxis para este tipo de consulta es la siguiente:

TRANSFORM función agregada instrucción SELECT PIVOT campo PIVOT [IN (valor1[, valor2[, ...]])]

En donde: Función

Es una función SQL agregada que opera sobre los datos

agregada

seleccionados.

instrucción SELECT

Es una instrucción SELECT. Es el campo o expresión que desea utilizar para crear

campo PIVOT

las cabeceras de la columna en el resultado de la consulta.

valor1, valor2

Son valores fijos utilizados para crear las cabeceras de la columna.

Para resumir datos utilizando una consulta de referencia cruzada, se seleccionan los valores de los campos o expresiones especificadas como cabeceras de columnas de tal forma que pueden verse los datos en un formato más compacto que con una consulta de selección. TRANSFORM es opcional pero si se incluye es la primera instrucción de una cadena SQL. Precede a la instrucción SELECT que especifica los campos utilizados como encabezados de fila y una cláusula GROUP y que especifica el agrupamiento de las filas. Opcionalmente puede incluir otras cláusulas como por ejemplo WHERE, que especifica una selección adicional o un criterio de ordenación. Los valores devueltos en campo PIVOT se utilizan como encabezados de columna en el resultado de la consulta. Por ejemplo, al utilizar las cifras de ventas en el mes de la venta como PIVOT en una consulta de referencia cruzada se crearían 12 columnas. Puede restringir el campo PIVOT para crear

encabezados a partir de los valores fijos (valor1, valor2) listados en la cláusula opcional IN. También puede incluir valores fijos, para los que no existen datos, para crear columnas adicionales. Ejemplos

TRANSFORM SUM(Cantidad) AS Ventas SELECT Producto, Cantidad FROM Pedidos WHERE Fecha BETWEEN #01-01-1998# AND #12-31-1998# GROUP y Producto ORDER y Producto PIVOT DatePart("m", Fecha)

Crea una consulta de tabla de referencias cruzadas que muestra las ventas de productos por mes para un año específico. Los meses aparecen de izquierda a derecha como columnas y los nombres de los productos aparecen de arriba hacia abajo como filas.

TRANSFORM SUM(Cantidad) AS Ventas SELECT Compania FROM Pedidos WHERE Fecha BETWEEN #01-01-1998# AND #12-31-1998# GROUP y Compania ORDER y Compania PIVOT "Trimestre " & DatePart("q", Fecha) IN ('Trimestre1', 'Trimestre2', 'Trimestre 3', 'Trimestre 4')

Crea una consulta de tabla de referencias cruzadas que muestra las ventas de productos por trimestre de cada proveedor en el año indicado. Los trimestres aparecen de izquierda a derecha como columnas y los nombres de los proveedores aparecen de arriba hacia abajo como filas.

Un caso práctico:

Se trata de resolver el siguiente problema: tenemos una tabla de productos con dos campos, el código y el nombre del producto, tenemos otra tabla de pedidos en la que anotamos el código del producto, la fecha del pedido y la cantidad pedida. Deseamos consultar los totales de producto por año, calculando la media anual de ventas. Estructura y datos de las tablas:

ARTICULOS ID

PEDIDOS

Nombre

Fecha

Cantidad

Zapatos

11/11/1996

250

Pantalones

11/11/1996

125

Blusas

11/11/1996

520

12/10/1996

04/10/1996

250

05/08/1996

100

01/01/1997

02/08/1997

05/10/1997

12/12/1997

15/12/1997

520

17/10/1997

1.250

Para resolver la consulta planteamos la siguiente consulta:

TRANSFORM SUM(Pedidos.Cantidad) AS Resultado SELECT Nombre AS Producto, Pedidos.Id AS Código, SUM(Pedidos.Cantidad) AS TOTAL, AVG(Pedidos.Cantidad) AS Media FROM Pedidos, Artículos

WHERE Pedidos.Id = Artículos.Id GROUP y Pedidos.Id, Artículos.Nombre PIVOT year(Fecha)

Y Obtenemos el siguiente resultado: Producto

Código

Total

Media

1996

1997

Zapatos

348

300

Pantalones

955

238,75

375

580

Blusas

1940

485

620

1320

Comentarios a la consulta:

La cláusula TRANSFORM indica el valor que deseamos visualizar en las columnas que realmente pertenecen a la consulta, en este caso 1996 y 1997, puesto que las demás columnas son opcionales. SELECT especifica el nombre de las columnas opcionales que deseamos visualizar, en este caso Producto, Código, Total y Media, indicando el nombre del campo que deseamos mostrar en cada columna o el valor de la misma. Si incluimos una función de cálculo el resultado se hará basándose en los datos de la fila actual y no al total de los datos. FROM especifica el origen de los datos. La primera tabla que debe figurar es aquella de donde deseamos extraer los datos, esta tabla debe contener al menos tres campos, uno para los títulos de la fila, otros para los títulos de la columna y otro para calcular el valor de las celdas. En este caso en concreto se deseaba visualizar el nombre del producto, como en la tabla de pedidos sólo figuraba el código del mismo se añadió una nueva columna en la cláusula SELECT llamada Producto que se corresponda con el campo Nombre de la tabla de artículos. Para vincular el código del artículo de la tabla de pedidos con el nombre del mismo de la tabla artículos se insertó la cláusula INNER JOIN. La cláusula GROUP y especifica el agrupamiento de los registros, contrariamente a los manuales de instrucción esta cláusula no es opcional ya

que debe figurar siempre y debemos agrupar los registros por el campo del cual extraemos la información. En este caso existen dos campos de los que extraemos la información: pedidos.cantidad y artículos.nombre, por ello agrupamos por los campos. Para finalizar la cláusula PIVOT indica el nombre de las columnas no opcionales, en este caso 1996 y 1997 y como vemos a el dato que aparecerá en las columnas, en este caso empleamos el año en que se produjo el pedido, extrayéndolo del campo pedidos.fecha.

Otras posibilidades de fecha de la cláusula PIVOT son las siguientes: 1.

Para agrupamiento por Trimestres:

PIVOT "Tri " & DatePart("q",[Fecha]); 2.

Para agrupamiento por meses (sin tener en cuenta el año)

PIVOT Format([Fecha],"mmm") IN ("Ene", "Feb", "Mar", "Abr", "May", "Jun", "Jul", "Ago", "Sep", "Oct", "Nov", "Dic"); 3.

Para agrupar por días

PIVOT Format([Fecha],"Short Date");

CRITERIOS DE SELECCIÓN Bases de datos-SQL-Sentencias SQL-Criterios de Selección

En el apartado anterior se vio la forma de recuperar los registros de las tablas, las formas empleadas devolvían todos los registros de la mencionada tabla. A lo largo de este apartado se estudiarán las posibilidades de filtrar los registros con el fin de recuperar solamente aquellos que cumplan unas condiciones preestablecidas. Antes de comenzar el desarrollo de este apartado hay que recalcar tres detalles de vital importancia. El primero de ellos es que cada vez que se desee

establecer una condición referida a un campo de texto la condición de búsqueda debe ir encerrada entre comillas simples; la segunda es que no es posible establecer condiciones de búsqueda en los campos memo y; la tercera y última hace referencia a las fechas. A día de hoy no he sido capaz de encontrar una sintaxis que funcione en todos los sistemas, por lo que se hace necesario particularizarlas según el banco de datos: Banco de Datos

Sintaxis

SQL-SERVER

Fecha = #mm-dd-aaaa#

ORACLE

Fecha = to_date('yyyyDDMM','aaaammdd',)

ACCESS

Fecha = #mm-dd-aaaa# EJEMPLO

Banco de Datos SQL-SERVER

Ejemplo (para grabar la fecha 18 de mayo de 1969) Fecha

#05-18-1969#

Fecha = 19690518

ORACLE

Fecha = to_date('yyyyDDMM', '19690518')

ACCESS

Fecha = #05-18-1969#

Referente a los valores lógicos TRUE o FALSE cabe destacar que no son reconocidos en ORACLE, ni en este sistema de bases de datos ni en SQLSERVER existen los campos de tipo "SI/NO" de ACCESS; en estos sistemas se utilizan los campos BIT que permiten almacenar valores de 0 ó 1. Internamente, ACCESS, almacena en estos campos valores de 0 ó -1, así que todo se complica bastante, pero aprovechando la coincidencia del 0 para los valores FALSE, se puede utilizar la sintaxis siguiente que funciona en todos los casos: si se desea saber si el campo es falso "... CAMPO = 0" y para saber los verdaderos "CAMPO <> 0". OPERADORES LÓGICOS Los operadores lógicos soportados por SQL son: AND, OR, XOR, EQV, IMP, IS y NOT. A excepción de los dos últimos todos poseen la siguiente sintaxis:

<expresión1> operador <expresión2> En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado de la operación varía en función del operador lógico. La tabla adjunta muestra los diferentes posibles resultados:

<expresión1>

Operador

<expresión2>

Resultado

Verdad

AND

Falso

Verdad

AND

Verdad

Falso

AND

Verdad

Falso

AND

Falso

Verdad

Falso

Verdad

Falso

Verdad

Falso

Verdad

XOR

Verdad

Falso

Verdad

XOR

Falso

Verdad

Falso

XOR

Verdad

Falso

XOR

Falso

Verdad

EQV

Verdad

EQV

Falso

EQV

Verdad

Falso

EQV

Falso

Verdad

IMP

Verdad

IMP

Falso

Verdad

IMP

NULL

Falso

IMP

Verdad

Falso

IMP

Falso

Verdad

Falso

IMP

NULL

Verdad

NULL

IMP

Verdad

NULL

IMP

Falso

NULL

IMP

NULL

Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la operaci贸n ser谩 el contrario al devuelto sin el operador NOT.

El 煤ltimo operador denominado IS se emplea para comparar dos variables de tipo objeto <Objeto1> IS <Objeto2>. este operador devuelve verdad si los dos objetos son iguales.

SELECT * FROM Empleados WHERE Edad > 25 AND Edad < 50

SELECT * FROM Empleados WHERE (Edad > 25 AND Edad < 50) OR Sueldo = 100

SELECT * FROM Empleados WHERE NOT Estado = 'Soltero'

SELECT * FROM Empleados WHERE (Sueldo > 100 AND Sueldo < 500) OR (Provincia = 'Madrid' AND Estado = 'Casado')

Valores Nulos

En muchas ocasiones es necesario emplear como criterio de seleccion valores nulos en los campos. Podemos emplear el operacion IS NULL para realizar esta operaci贸n. Por ejemplo:

SELECT * FROM Empleados WHERE DNI IS NULL

Este operador no está reconocido en ACCESS y por ello hay que utilizar la siguiente sintaxis:

SELECT * FROM Empleados WHERE ISNULL(DNI)=TRUE

Intervalos de Valores

Para indicar que deseamos recuperar los registros según el intervalo de valores de un campo emplearemos el operador BETWEEN cuya sintaxis es: campo [NOT] BETWEEN valor1 AND valor2 (la condición NOT es opcional) En este caso la consulta devolvería los registros que contengan en "campo" un valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condición NOT devolverá aquellos valores no incluidos en el intervalo.

SELECT * FROM Pedidos WHERE CodPostal BETWEEN 28000 AND 28999

Devuelve los pedidos realizados en la provincia de Madrid

El Operador LIKE

Se utiliza para comparar una expresión de cadena con un modelo en una expresión SQL. Su sintaxis es:

Expresión LIKE modelo

En donde expresión es una cadena modelo o campo contra el que se compara expresión. Se puede utilizar el operador LIKE para encontrar valores en los

campos que coincidan con el modelo especificado. Por modelo puede especificar un valor completo (Ana María), o se puede utilizar una cadena de caracteres comodín como los reconocidos por el sistema operativo para encontrar un rango de valores (LIKE An*). El operador LIKE se puede utilizar en una expresión para comparar un valor de un campo con una expresión de cadena. Por ejemplo, si introduce LIKE C* en una consulta SQL, la consulta devuelve todos los valores de campo que comiencen por la letra C. En una consulta con parámetros, puede hacer que el usuario escriba el modelo que se va a utilizar. El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido de cualquier letra entre A y F y de tres dígitos:

LIKE 'P[A-F]###'

Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la A a la D seguidas de cualquier cadena.

LIKE '[A-D]*'

En la tabla siguiente se muestra cómo utilizar el operador LIKE para comprobar expresiones con diferentes modelos. ACCESS Tipo de

Modelo

coincidencia

Planteado

Coincide 'aa',

'aBa',

No coincide

Varios caracteres

'a*a'

Carácter especial

'a[*]a'

'a*a'

'aaa'

Varios caracteres

'ab*'

'abcdefg', 'abc'

'cab', 'aab'

Un solo carácter

'a?a'

'aaa', 'a3a', 'aBa'

'aBBBa'

Un solo dígito

'a#a'

'a0a', 'a1a', 'a2a'

'aaa', 'a10a'

'aBBBa'

'aBC'

Rango de caracteres

'[a-z]'

'f', 'p', 'j'

'2', '&'

Fuera de un rango

'[!a-z]'

'9', '&', '%'

'b', 'a'

Distinto de un dígito

'[!0-9]'

'A', 'a', '&', '~'

'0', '1', '9'

Combinada

'a[!b-m]#'

'An9', 'az0', 'a99'

'abc', 'aj0'

SQL-SERVER Ejemplo LIKE 'A%' LIKE '_NG'

Descripción Todo lo que comience por A Todo lo que comience por cualquier carácter y luego siga NG

LIKE '[AF]%' Todo lo que comience por A ó F LIKE

'[A- Todo lo que comience por cualquier letra comprendida entre

F]%'

la A y la F

Todo lo que comience por A y la segunda letra no sea una

'[A^B]%'

En determinado motores de bases de datos, esta cláusula, no reconoce el asterisco como carácter comodín y hay que sustituirlo por el carácter tanto por ciento (%).

El Operador IN

Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de los en una lista. Su sintaxis es: expresión [NOT] IN(valor1, valor2, . . .)

SELECT * FROM Pedidos WHERE Provincia IN ('Madrid', 'Barcelona', 'Sevilla')

LA CLÁUSULA WHERE

La cláusula WHERE puede usarse para determinar qué registros de las tablas enumeradas en la cláusula FROM aparecerán en los resultados de la instrucción SELECT. Después de escribir esta cláusula se deben especificar las condiciones expuestas en los apartados anteriores. Si no se emplea esta cláusula, la consulta devolverá todas las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir a continuación de FROM.

SELECT Apellidos, Salario FROM Empleados WHERE Salario = 21000

SELECT IdProducto, Existencias FROM Productos WHERE Existencias <= NuevoPedido

SELECT * FROM Pedidos WHERE FechaEnvio = #05-30-1994#

SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos = 'King'

SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos LIKE 'S*'

SELECT Apellidos, Salario FROM Empleados WHERE Salario BETWEEN 200 AND 300

SELECT Apellidos, Salario FROM Empleados WHERE Apellidos BETWEEN 'Lon' AND 'Tol'

SELECT IdPedido, FechaPedido FROM Pedidos WHERE FechaPedido BETWEEN #01-01-1994# AND #12-31-1994#

SELECT Apellidos, Nombre, Ciudad FROM Empleados WHERE Ciudad IN ('Sevilla', 'Los Angeles', 'Barcelona')

AGRUPAMIENTO DE REGISTROS

Bases de datos-SQL-Sentencias SQL-Agrupamiento de Registros

GROUP BY Combina los registros con valores idénticos, en la lista de campos especificados, en un único registro. Para cada registro se crea un valor sumario si se incluye una función SQL agregada, como por ejemplo SUM o COUNT, en la instrucción SELECT. Su sintaxis es: SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo GROUP BY es opcional. Los valores de resumen se omiten si no existe una función SQL agregada en la instrucción SELECT. Los valores NULL en los campos GROUP BY se agrupan y no se omiten. No obstante, los valores NULL no se evalúan en ninguna de las funciones SQL agregadas. Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la cláusula HAVING para filtrar los registros una vez agrupados. A menos que contenga un dato Memo u Objeto OLE, un campo de la lista de campos GROUP BY puede referirse a cualquier campo de las tablas que aparecen en la cláusula FROM, incluso si el campo no esta incluido en la instrucción SELECT, siempre y cuando la instrucción SELECT incluya al menos una función SQL agregada. Todos los campos de la lista de campos de SELECT deben o bien incluirse en la cláusula GROUP BY o como argumentos de una función SQL agregada.

SELECT IdFamilia, SUM(Stock) AS StockActual FROM Productos GROUP y IdFamilia

Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING. HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a mostrar.

SELECT IdFamilia, SUM(Stock) AS StockActual FROM Productos GROUP y IdFamilia HAVING StockActual > 100 AND NombreProducto LIKE BOS*

AVG Calcula la media aritmética de un conjunto de valores contenidos en un campo especificado de una consulta. Su sintaxis es la siguiente

AVG(expr)

En donde expr representa el campo que contiene los datos numéricos para los que se desea calcular la media o una expresión que realiza un cálculo utilizando los datos de dicho campo. La media calculada por AVG es la media aritmética (la suma de los valores dividido por el número de valores). La función AVG no incluye ningún campo NULL en el cálculo.

SELECT AVG(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100

COUNT Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente:

COUNT(expr)

En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.

Aunque expr puede realizar un cálculo sobre un campo, COUNT simplemente cuenta el número de registros sin tener en cuenta qué valores se almacenan en los registros. La función COUNT no cuenta los registros que tienen campos NULL a menos que expr sea el carácter comodín asterisco (*). Si utiliza un asterisco, COUNT calcula el número total de registros, incluyendo aquellos que contienen campos NULL. COUNT(*) es considerablemente más rápida que COUNT(Campo). No se debe poner el asterisco entre dobles comillas ('*').

SELECT COUNT(*) AS Total FROM Pedidos Si expr identifica a múltiples campos, la función COUNT cuenta un registro sólo si al menos uno de los campos no es NULL. Si todos los campos especificados son NULL, no se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).

SELECT COUNT(FechaEnvío & Transporte) AS Total FROM Pedidos

Podemos hacer que el gestor cuente los datos diferentes de un determinado campo

SELECT COUNT(DISTINCT Localidad) AS Total FROM Pedidos

MAX, MIN Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo especifico de una consulta. Su sintaxis es:

MIN(expr) MAX(expr)

En donde expr es el campo sobre el que se desea realizar el cálculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una

función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

SELECT MIN(Gastos) AS ElMin FROM Pedidos WHERE Pais = 'España'

SELECT MAX(Gastos) AS ElMax FROM Pedidos WHERE Pais = 'España'

STDEV, STDEVP Devuelve estimaciones de la desviación estándar para la población (el total de los registros de la tabla) o una muestra de la población representada (muestra aleatoria). Su sintaxis es:

STDEV(expr) STDEVP(expr)

En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL). STDEVP evalúa una población, y STDEV evalúa una muestra de la población. Si la consulta contiene menos de dos registros (o ningún registro para STDEVP), estas funciones devuelven un valor NULL (el cual indica que la desviación estándar no puede calcularse).

SELECT STDEV(Gastos) AS Desviación FROM Pedidos WHERE País = 'España'

SELECT STDEVP(Gastos) AS Desviación FROM Pedidos WHERE País = 'España'

SUM Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis es:

SUM(expr)

En donde expr representa el nombre del campo que contiene los datos que desean sumarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

SELECT SUM(PrecioUnidad * Cantidad) AS Total FROM DetallePedido

VAR, VARP Devuelve una estimación de la varianza de una población (sobre el total de los registros) o una muestra de la población (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:

VAR(expr) VARP(expr)

VARP evalúa una población, y VAR evalúa una muestra de la población. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL) Si la consulta contiene menos de dos registros, VAR y VARP devuelven NULL (esto indica que la varianza no puede calcularse). Puede utilizar VAR y VARP en una expresión de consulta o en una Instrucción SQL.

SELECT VAR(Gastos) AS Varianza FROM Pedidos WHERE País = 'España'

SELECT VARP(Gastos) AS Varianza FROM Pedidos WHERE País = 'España'

COMPUTE de SQL-SERVER Esta cláusula añade una fila en el conjunto de datos que se está recuperando, se utiliza para realizar cálculos en campos numéricos. COMPUTE actúa siempre sobre un campo o expresión del conjunto de resultados y esta expresión debe figurar exactamente igual en la cláusula SELECT y siempre se debe ordenar el resultado por la misma o al memos agrupar el resultado. Esta expresión no puede utilizar ningún ALIAS.

SELECT IdCliente, COUNT(IdPedido) FROM Pedidos GROUP y IdPedido HAVING COUNT(IdPedido) > 20 COMPUTE SUM(COUNT(IdPedido))

SELECT IdPedido, (PrecioUnidad * Cantidad - Descuento) FROM [Detalles de Pedidos] ORDER y IdPedido COMPUTE SUM((PrecioUnidad * Cantidad - Descuento)) // Calcula el Total y IdPedido // Calcula el Subtotal 1.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.3.3.2.

MATERIAL DE APOYO

1.3.4. ACTIVIDADES DE APRENDIZAJE 1.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A3-EC1 Sentencias SQL “Tablas Multiples”

1.3.4.1.1. INSTRUCCIONES Encontrar la solucion SQL para los siguientes planteamientos: 1. Mostrar todas las compras del cliente “Germán Goméz Lizalde”

2. Mostrar todos los pagos que ha realizado el cliente “Jazmín Perez Perez”. 3. Mostrar todos los pagos que ha realizado el cliente “Jazmín Perez Perez” pero solo en su ultimo credito. 4. Mostrar todos los productos en los cuales solo haya 5 piezas o menos. 5. Mostrar el total de ventas del día de hoy.

a) b) c) d) e) f)

Valor actividad: 10 Puntos Producto esperado: 5 sentencias SQL validas para SQL Server 2000 Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 1.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Sentencias SQL “Tablas Multiples”

DESARROLLO Realizar las sentencias SQL, y validarlas con el manejador SQL Server 2000, para cerciorarse de que la respuesta es correcta. Total

PONDERACIÓN

10 puntos

1.3.5. RESULTADO DE APRENDIZAJE Comprobar que la sintaxis principalmente de las sentencias SQL es correcta y además de verificar las ventajas que el lenguaje SQL ofrece. 1.3.6. BIBLIOGRAFÍA Este manual 1.3.7. DOCUMENTOS Manual SQL Server 2000 Standard final

1.4.

CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O SUBCONSULTAS

1.4.1. OBJETIVO DE APRENDIZAJE Aprender a crear consultas anidadas, para poder realizar tareas mas complajas requeridas para la administración de una base de datos. 1.4.2. RECURSOTIEMPO DEL TEMA 5 horas. 1.4.3. DESARROLLO

Bases de datos-SQL-Sentencias SQL-Subconsultas

Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta. Puede utilizar tres formas de sintaxis para crear una subconsulta:

Comparación [ANY | ALL | SOME] (instrucción sql) Expresión [NOT] IN (instrucción sql) [NOT] EXISTS (instrucción sql)

En donde: comparación

expresión

instrucción SQL

Es una expresión y un operador de comparación que compara la expresión con el resultado de la subconsulta. Es una expresión por la que se busca el conjunto resultante de la subconsulta. Es una instrucción SELECT, que sigue el mismo formato y reglas que cualquier otra instrucción SELECT. Debe ir entre paréntesis.

Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos de una instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta, se utiliza una instrucción SELECT para proporcionar un conjunto de uno o más valores especificados para evaluar en la expresión de la cláusula WHERE o HAVING. Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para recuperar registros de la consulta principal, que satisfagan la comparación con cualquier otro registro recuperado en la subconsulta. El ejemplo siguiente devuelve todos los productos cuyo precio unitario es mayor que el de cualquier producto vendido con un descuento igual o mayor al 25 por ciento:

SELECT * FROM Productos WHERE PrecioUnidad ANY ( SELECT PrecioUnidad FROM DetallePedido WHERE Descuento = 0 .25 )

El predicado ALL se utiliza para recuperar únicamente aquellos registros de la consulta principal que satisfacen la comparación con todos los registros recuperados en la subconsulta. Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolverá únicamente aquellos productos cuyo precio unitario sea mayor que el de todos los productos vendidos con un descuento igual o mayor al 25 por ciento. Esto es mucho más restrictivo. El predicado IN se emplea para recuperar únicamente aquellos registros de la consulta principal para los que algunos registros de la subconsulta contienen un valor igual. El ejemplo siguiente devuelve todos los productos vendidos con un descuento igual o mayor al 25 por ciento:

SELECT * FROM Productos WHERE IDProducto IN ( SELECT IDProducto FROM DetallePedido WHERE Descuento = 0.25 )

Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos registros de la consulta principal para los que no hay ningún registro de la subconsulta que contenga un valor igual. El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en comparaciones de verdad/falso para determinar si la subconsulta devuelve algún registro. Supongamos que deseamos recuperar todos aquellos clientes que hayan realizado al menos un pedido:

SELECT Clientes.Compañía, Clientes.Teléfono FROM Clientes WHERE EXISTS ( SELECT FROM Pedidos WHERE Pedidos.IdPedido = Clientes.IdCliente )

Esta consulta es equivalente a esta otra:

SELECT Clientes.Compañía, Clientes.Teléfono FROM Clientes WHERE IdClientes IN ( SELECT Pedidos.IdCliente FROM Pedidos )

Se puede utilizar también alias del nombre de la tabla en una subconsulta para referirse a tablas listadas en la cláusula FROM fuera de la subconsulta. El ejemplo siguiente devuelve los nombres de los empleados cuyo salario es igual o mayor que el salario medio de todos los empleados con el mismo título. A la tabla Empleados se le ha dado el alias T1:

SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS T1 WHERE Salario = ( SELECT AVG(Salario) FROM Empleados WHERE T1.Titulo = Empleados.Titulo ) ORDER y Titulo

En el ejemplo anterior, la palabra reservada AS es opcional.

SELECT Apellidos, Nombre, Cargo, Salario FROM Empleados WHERE Cargo LIKE 'Agente Ven*' AND Salario ALL ( SELECT Salario FROM Empleados WHERE Cargo LIKE '*Jefe*' OR Cargo LIKE '*Director*' )

Obtiene una lista con el nombre, cargo y salario de todos los agentes de ventas cuyo salario es mayor que el de todos los jefes y directores.

SELECT DISTINCT NombreProducto, Precio_Unidad FROM Productos WHERE PrecioUnidad = ( SELECT PrecioUnidad FROM Productos WHERE NombreProducto = 'Almíbar anisado' )

Obtiene una lista con el nombre y el precio unitario de todos los productos con el mismo precio que el almíbar anisado.

SELECT DISTINCT NombreContacto, NombreCompania, CargoContacto, Telefono FROM Clientes WHERE IdCliente IN ( SELECT DISTINCT IdCliente FROM Pedidos WHERE FechaPedido <#07/01/1993# )

Obtiene una lista de las compañías y los contactos de todos los clientes que han realizado un pedido en el segundo trimestre de 1993.

SELECT Nombre, Apellidos FROM Empleados AS E WHERE EXISTS ( SELECT * FROM Pedidos AS O WHERE O.IdEmpleado = E.IdEmpleado )

Selecciona el nombre de todos los empleados que han reservado al menos un pedido.

SELECT DISTINCT Pedidos.Id_Producto, Pedidos.Cantidad, ( SELECT Productos.Nombre FROM Productos WHERE Productos.IdProducto = Pedidos.IdProducto ) AS ElProducto FROM Pedidos WHERE Pedidos.Cantidad = 150 ORDER y Pedidos.Id_Producto

Recupera el Código del Producto y la Cantidad pedida de la tabla pedidos, extrayendo el nombre del producto de la tabla de productos.

SELECT NumVuelo, Plazas FROM Vuelos WHERE Origen = 'Madrid' AND EXISTS ( SELECT T1.NumVuelo FROM Vuelos AS T1 WHERE T1.PlazasLibres > 0 AND T1.NumVuelo=Vuelos.NumVuelo)

Recupera números de vuelo y capacidades de aquellos vuelos con destino Madrid y plazas libres

Supongamos ahora que tenemos una tabla con los identificadores de todos nuestros productos y el stock de cada uno de ellos. En otra tabla se encuentran todos los pedidos que tenemos pendientes de servir. Se trata de averiguar que productos no se podemos servir por falta de stock.

SELECT PedidosPendientes.Nombre FROM PedidosPendientes GROUP y PedidosPendientes.Nombre

HAVING SUM(PedidosPendientes.Cantidad < (SELECT Productos.Stock FROM Productos WHERE Productos.IdProducto = PedidosPendientes.IdProducto ) )

Supongamos que en nuestra tabla de empleados deseamos buscar todas las mujeres cuya edad sea mayor a la de cualquier hombre:

SELECT Empleados.Nombre FROM Empleados WHERE Sexo = 'M' AND Edad > ANY (SELECT Empleados.Edad FROM Empleados WHERE Sexo ='H')

ó lo que sería lo mismo:

SELECT Empleados.Nombre FROM Empleados WHERE Sexo = 'M' AND Edad > (SELECT MAX( Empleados.Edad )FROM Empleados WHERE Sexo ='H')

La siguiente tabla muestra algún ejemplo del operador ANY y ALL Valor 1

Operador

Valor 2

Resultado

> ANY

(2,5,7)

Cierto

= ANY

(2,5,7)

Falso

= ANY

(2,3,5,7)

Cierto

> ALL

(2,5,7)

Falso

< ALL

(5,6,7)

Falso

El operación =ANY es equivalente al operador IN, ambos devuelven el mismo resultado. Para concluir este apartado comentar que: la cláusula EXISTS se puede emplear para generar la intersección entre dos consultas y, por tanto, la cláusula NOT EXISTS para generar la diferencia entre consultas 1.4.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.4.3.2.

MATERIAL DE APOYO

1.4.4. ACTIVIDADES DE APRENDIZAJE 1.4.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A4-ER1 Examen Rápido.

1.4.4.1.1. INSTRUCCIONES Formular 5 preguntas acerca de subconsultas y dictárselas a los alumnos(as) para que se contesten. a) b) c) d) e) f)

Valor actividad: 10 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 1.4.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Examen Rápido de subconsultas

DESARROLLO Formular las 5 preguntas de subconsultas y dictárselas a los alumnos para proceder a contestarlas. Total

PONDERACIÓN 10 puntos 10 Puntos

1.4.5. RESULTADO DE APRENDIZAJE Verificar que el tema se este entendiendo, para medir el nivel de aprendizaje y tomar acciones en base a los resultados. 1.4.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 1.4.7. DOCUMENTOS Manual SQL Server 2000 Standard final

1.5.

PROCEDIMIENTOS ALMACENADOS

1.5.1. OBJETIVO DE APRENDIZAJE Manejar procedimientos para reducir errores en las acciones provocadas en muchas ocaciones por los usuarios de Bases de Datos. 1.5.2. RECURSOTIEMPO DEL TEMA 6 horas 1.5.3. DESARROLLO

La característica primordial de los procedimientos almacenados es que se optimizan en el momento de su creación. Esto supone que, a diferencia de lo que sucede con las sentencias SQL que se envían el gestor de manera interactiva, los procedimientos almacenados pasan previamente por un proceso de normalización. Cuando se crea un procedimiento almacenado el procesador de consultas del gestor crea una versión del mismo con una cierta estructura normalizada, y la almacena en una de las tablas de sistema. Las siguientes ejecuciones de dicho procedimiento, no necesitarán consumir el tiempo necesario para llevar a cabo este proceso de normalización, con lo que su ejecución será más rápida. Por otra parte, cuando el procedimiento se ejecuta por vez primera, se produce su compilación y la optimización del acceso del procedimiento a los datos. Este proceso optimizado se mantiene en memoria para posteriores ejecuciones con el consiguiente ahorro adicional de tiempo y recursos.

Existen dos maneras de crear procedimientos almacenados: utilizando la sentencia CREATE PROCEDURE y mediante Enterprise Manager La sentencia CREATE PROCEDURE La sentencia Transact-SQL que permite crear procedimientos almacenados es CREATE PROCEDURE. Permite crear un procedimiento almacenado a partir de una determinada colección de sentencias SQL ligadas por sentencias adicionales de control de flujo La sintaxis de esta sentencia es la siguiente: Sintaxis CREATE PROCEDURE

CREATE PROCEDURE [propietario.] nombre de procedimiento[;número] [(lista de parámetros) ] [{FOR REPLICATION} | {WITH RECOMPILE} [{[WITH] | [,]} ENCRYPTION]] AS sentencias SQL

PARAMETROS Como hemos comentado anteriormente, los procedimientos almacenados permiten que su ejecución pueda ser adaptada a la situación y ámbito en el que sean llamados. Para ello, al igual que las funciones y procedimientos en lenguajes de programación estructurada, pueden recibir parámetros. Así el procedimiento recibir datos diversos en función de la situación en la que la llamada se realice. La definición de parámetros se lleva a cabo en el momento de la creación del procedimiento almacenado. Cuando el usuario solicite la ejecución de un procedimiento definido con parámetros deberá suministrar valores para ellos La sintaxis de definición de un parámetro es la siguiente: 

Sintaxis de definición de parámetros @nombre_de _parámetro tipo_de_datos [= valor por defecto] [OUTPUT]

Puede especificarse un valor por defecto para cada parámetro. La manera de especificar un valor por defecto es colocar después del nombre de parámetro el signo = seguido por la constante que se utilizará como valor. De igual modo, también es posible definir ciertos parámetros como de retorno. Este tipo de parámetros se especifican como cualquier otro, con la salvedad de que sus nombres aparecen seguidos por la palabra clave OUTPUT. Cuando el procedimiento se ejecute devolverá en esos parámetros los valores que hayan

tomado en el interior del mismo. Estos valores podrán ser almacenados en variables y utilizados posteriormente.

RECOMPILE: Procedimientos de recompilación forzosa

Imaginemos que generamos un procedimiento almacenado cuyos parámetros puedan ser de tipos muy diversos. Esto supondrá que sea común que la optimización que se ha llevado a cabo en primera instancia, no sea válida para otras ejecuciones del procedimiento. Por otra parte, es común que frecuentemente se añadan nuevos índices que hagan que la optimización de la consulta deje también de ser válida. El rendimiento en este tipo de situaciones no es el más adecuado, pues se ralentizan las operaciones. Es en estos casos necesario que el procedimiento almacenado

recompila

cada

vez

que

ejecuta,

desoyendo

deshabilitando la característica de optimización única que antes hemos presentado. La cláusula que permite indicar que el procedimiento debe ser recompilado en cada ejecución es WITH RECOMPILE

Sentencias SQL del procedimiento almacenado

El cuerpo del procedimiento estará integrado por un conjunto de sentencias SQL que realizarán las tareas que esperamos del mismo y que se especificarán en la definición del procedimiento siguiendo a la cláusula AS En general podemos decir que en un procedimiento almacenado pueden incluirse cualquier número y tipo de sentencias Transact SQL. Sin embargo, es necesario comentar algunas restricciones respecto a la creación de objetos No pueden incluirse las siguientes sentencias CREATE 

CREATE VIEW



CREATE TRIGGER



CREATE DEFAULT



CREATE PROCEDURE



CREATE RULE

Creación de procedimientos almacenados mediante Enterprise Manager Hasta este momento hemos presentado la sintaxis de la sentencia Transact SQL que permite crear procedimientos almacenados. A continuación recordaremos el procedimiento necesario para crear un procedimiento almacenado mediante Enterprise Manager Para ello deberán seguirse los siguientes pasos: 

Acceder a la ventana Server Manager y al nodo Stored Procedures



Una vez accedido pulsar el botón derecho del ratón y elegir la orden de menú New Stored PROCEDURE.



Especificar

misma

sentencia

creación

procedimiento

almacenado que pusimos antes como ejemplo. 

Pulsar el botón SAVE Object.



En la ventana Server Manager aparecerá el nuevo procedimiento almacenado.

Una vez creado el procedimiento, esto es, una vez definido, SQL Server generará el siguiente código. 

Código generado tras la creación del procedimiento

IF EXISTS (SELECT * FROM sysobjects WHERE id = object_id('dbo.infousuarios') AND sysstat & 0xf = 4) DROP PROCEDURE dbo.infousuarios GO CREATE PROCEDURE infousuarios AS SELECT * FROM sysusers GO Las líneas adicionales evitarán que se intenten crear dos procedimientos con el mismo nombre.

ELIMINACIÓN DE PROCEDIMIENTOS ALMACENADOS

La sentencia DROP PROCEDURE sirve para eliminar del catálogo un procedimiento almacenado y su sintaxis y uso resulta totalmente análogo a las que se utilizan para eliminar cualquier otro objeto de una base de datos

EJECUCIÓN DE PROCEDIMIENTOS ALMACENADOS

Una vez se ha creado un procedimiento almacenado, se encontrará en disposición de ser ejecutado. Si en la primera línea de una secuencia de sentencias

Transact_SQL

aparece

nombre

procedimiento

almacenado, SQL Server lo ejecutará. En el resto de situaciones deberemos utilizar la sentencia EXECUTE Esta sentencia se utiliza para la ejecución de todo tipo de procedimientos almacenados, tanto de sistema, como de usuario. Por otra parte también permite la ejecución de una cadena de caracteres que contiene una cierta sentencia Transact_SQL Su sintaxis es la siguiente: SINTAXIS EXECUTE PARA PROCEDIMIENTOS ALMACENADOS

EXEC[ute] {[@valor de retorno =]{[[[nombreproc[;num]|@variablenombre} [[@parámetro =] {valor | @variable [OUTPUT]] [, [@parámetro =] {valor | @variable [OUTPUT]}]...] [WITH RECOMPILE]] El procedimiento que se ejecutará es el especificado en nombreproc. El nombre del procedimiento puede estar contenido en una variable como aquí @variablenombre.

VALOR DE RETORNO Como hemos comentado anteriormente, los procedimientos almacenados pueden, opcionalmente devolver un valor. Si esto es así, este valor retornado deberá ser almacenado en una variable que en la sintaxis hemos presentado como @valor de retorno.

INFORMACIÓN RETORNADA POR UN PROCEDIMIENTO ALMACENADO

Los procedimientos almacenados pueden retornar información al procedimiento que los llamó o al usuario que solicita su ejecución básicamente de dos modos: 

Mediante el retorno de un valor de estado.



Mediante parámetros de retorno. VALOR DE ESTADO (STATUS VALUE)

Es una práctica común la mayoría de lenguajes de programación el hacer que los procedimientos o funciones retornen un valor que permita testear cual ha sido el modo o resultado con el que la ejecución de dicha función ha concluido. Generalmente dichos valores son definidos de antemano de manera que un mero análisis del valor de estado permita conocer qué ha sucedido. Los procedimientos almacenados SQL Server devuelven también un valor de estado o status value. Este valor puede ser almacenado en una variable de manera que pueda examinarse posteriormente para valorar el éxito de su ejecución o el motivo de su fracaso. Veamos un ejemplo tomando como base la base de datos ESCUELA, con las siguientes tablas:



Devolución de valor de estado definido por el usuario Este procedimiento devuelve 100 si la calificación del alumno es menor que 70 y 200 en caso contrario

CREATE PROCEDURE APROBADO AS IF (SELECT Cal FROM Calificacion WHERE Matricula = 2004001 AND CvMat = 100) > 70

RETURN 100 ELSE RETURN 200 GO Podríamos definir un nuevo procedimiento almacenado que utilice a este primero 

Utilización del procedimiento almacenado Este procedimiento presenta un mensaje indicando si un determinado alumno está aprobado o no, utilizando el procedimiento aprobado

CREATE PROCEDURE MOSTRARMENSAJE AS DECLARE @ValorDeRetorno INT EXECUTE @ValorDeRetorno = APROBADO IF (@ValorDeRetorno = 100) PRINT 'APROBADO' ELSE

PRINT 'REPROBADO' GO

RETORNO DE PARÁMETROS

En el momento de la creación y definición de un procedimiento almacenado puede especificarse que alguno, o todos, los parámetros que dicho procedimiento aceptará sean considerados parámetros de retorno. Veamos un ejemplo de uso de procedimiento almacenado con paso de parámetros PASO DE PARÁMETROS Este procedimiento realiza la suma de dos variables enteras y devuelve una variable entera como un parámetro de salida.

Este ejemplo solo suma dos numeros enteros y regresa el resultado. CREATE PROCEDURE suma @sum1 int, @sum2 int, @res int OUTPUT AS SELECT @res = @ sum1 + @sum2 RETURN 0 Veamos un ejemplo de utilización 

Uso de procedimiento almacenado con parámetros

DECLARE @resultado int DECLARE @retorno int

EXECUTE @retorno = suma 2, 2, @resultado OUTPUT En este punto @retorno valdrá 0 y @resultado tendrá como valor 4.

Este es otro ejemplo con la tabla de Calificación.

CREATE PROCEDURE PROMEDIO @Matric INT, @Prom FLOAT OUTPUT AS

SELECT @Prom = AVG(Cal) FROM Calificacion WHERE Matricula = @Matric RETURN 0 GO

Y esta seria la Consulta a realizar

DECLARE @Matric FLOAT DECLARE @Prom int EXECUTE @Matric = PROMEDIO 2004001, @Prom OUTPUT PRINT @Prom

1.5.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.5.3.2.

MATERIAL DE APOYO

1.5.4. ACTIVIDADES DE APRENDIZAJE 1.5.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A5-EC2 Procedimientos Almacenados.

1.5.4.1.1. INSTRUCCIONES Realizar los siguientes procedimientos almacenados: 1. Cacular las ventas del día de hoy 2. Calcular cuantos pagos ha hecho un cliente.

3. Calcular el total de las compras en un mes.

a) Valor actividad: 10 Puntos b) Producto esperado: Mostrar la sentencia SQL de los procedimientos almacenados anteriores c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes) 1.5.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO Los alumnos deben de checar la solucion para cada Procedimientos almacenados planteamiento, en SQL Server 2000. y entregar la solución en papel. Total

PONDERACIÓN

10 puntos

1.5.5. RESULTADO DE APRENDIZAJE Conocer de cerca la utilidad que tienen los procedimientos almacenados. 1.5.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 1.5.7. DOCUMENTOS Manual SQL Server 2000 Standard final 1.6.

TRIGGERS

1.6.1. OBJETIVO DE APRENDIZAJE Entender la ventaja de manejar ciertas acciones dentro de una base de datos con procedimientos de disparo (autoejecutables). 1.6.2. RECURSOTIEMPO DEL TEMA 7 horas 1.6.3. DESARROLLO Un TRIGGER no es más que un tipo especial de procedimiento almacenado. En lugar de ejecutarse como respuesta a una llamada, se ponen en funcionamiento automáticamente como respuesta a ciertas modificaciones de los datos, cuya naturaleza se especifica en el momento de la creación del TRIGGER.

La utilidad de los TRIGGERS es múltiple. Quizá la más ampliamente utilizada es la de establecer reglas de consistencia entre los datos presentes en las diferentes tablas de nuestra base de datos. Los TRIGGERS son una herramienta poderosa para centralizar en la base de datos la toma de las decisiones de negocio que se asocian a los datos de la misma. De esta manera se descarga en gran medida a las aplicaciones cliente de la tarea de revisar las acciones de actualización de datos. Como hemos dicho, las acciones que motivarán que un TRIGGER se ponga en ejecución, es decir aquellas acciones que disparan el TRIGGER, son modificaciones que puedan llevarse a cabo en los datos, tanto la adición de datos nuevos como la eliminación de datos existentes. Dichas modificaciones se llevan a cabo, evidentemente, mediante la ejecución de las sentencias UPDATE, DELETE o INSERT. Supongamos el caso en el que existan dos tablas Existencias y Ventas de manera que cada vez que se produce una nueva venta deben actualizarse las unidades que aún quedan en existencias. La solución a este problema, si se sigue la filosofía de toma de decisiones mediante TRIGGERS que Microsoft recomienda utilizar con SQL Server, es dejar que sea la propia base de datos la que se encargue de realizar las actualizaciones de manera automática. Es posible definir un TRIGGER que realice las tareas descritas y que se ponga en ejecución inmediatamente después a la operación de borrado o inserción. Así, cuando dicha acción de modificación se complete, el TRIGGER adecuado se disparará. Pueden definirse TRIGGERS que respondan a una o varias de estas acciones, es decir, puede definirse un TRIGGER que responda tanto a una operación INSERT, como a una DELETE. De este modo, los TRIGGERS pueden utilizarse para resolver, entre otras, las siguientes situaciones: 

Preservar la integridad referencial. En el caso en que dos o más tablas en una base de datos se hallen ligadas por claves ajenas no será posible modificar datos en la tabla primaria sin modificar aquellos que se

hallen vinculados a él en la tabla subordinada. Utilizando TRIGGERS podemos controlar este proceso forzando a que los registros dependientes sean eliminados cuando llevamos a cabo un DELETE en la tabla principal. 

Establecimiento

condiciones

complejas:

Los

TRIGGERS

permiten, como veremos más adelante, especificar condiciones para que los datos de una o varias columnas sean considerados válidos. 

Respuesta a cambios de estado de la tabla: Los TRIGGERS permiten examinar el estado de la tabla antes y después de que una determinada tarea de modificación haya sido llevada a cabo y obrar en consecuencia.

La sentencia Transact-SQL que permite crear TRIGGERS es CREATE TRIGGER. SINTAXIS CREATE TRIGGER

CREATE TRIGGER [propiet.] nombretrigger ON [propiet.]nombretabla FOR {INSERT, UPDATE, DELETE} [WITH ENCRyPTION] AS sentenciasSQL Acciones que desatan la ejecución del TRIGGER El TRIGGER se ejecuta como respuesta a la aplicación de ciertas sentencias de modificación sobre la tabla asociada al mismo. Estas sentencias se especifican en la cláusula FOR UPDATE/INSERTDELETE Cuando se lleven a cabo la o las acciones que se especifiquen en la definición del TRIGGER sobre la tabla, las sentencias que lo conforman se ejecutarán. De esta manera, pueden definirse hasta tres TRIGGERS diferentes para cada tabla, uno por cada acción INSERT, UPDATE o DELETE. En cualquier caso, es posible especificar en un sólo TRIGGER, cualquier combinación de las tres acciones disponibles.

SENTENCIAS SQL DEL TRIGGER

El cuerpo del TRIGGER constará de una serie de sentencias SQL que realizarán las tareas que esperamos del mismo y una serie de condiciones que determinarán de manera adicional si las acciones del TRIGGER deben ser llevadas o no cabo. En general podemos decir que en un TRIGGER, como en cualquier procedimiento almacenado, pueden incluirse cualquier número y tipo de sentencias Transact SQL. Sin embargo, y por su propia naturaleza, la de responder a una acción ejecutando otras, no es posible incluir en las sentencias del TRIGGER la sentencia SELECT. No son estas las únicas restricciones aplicables a las sentencias ejecutables en un TRIGGER. Concretamente las siguientes sentencias no pueden utilizarse. 

Sentencias de creación: No puede incluirse ninguna sentencia CREATE.



Sentencias de eliminación de objetos: No pueden eliminarse objetos, por lo que no está permitido utilizar ninguna de las sentencias de la familia DROP



Sentencias de modificación de objetos: No puede alterarse la estructura de tablas ni bases de datos mediante las sentencias ALTER DATABASE, ALTER TABLE



Sentencias de borrado de filas: No puede utilizarse la sentencia TRUNCATE TABLE para borrar todas las filas de una tabla.



Permisos: No pueden otorgarse ni retirarse permisos, por lo que no son utilizables GRANT y REVOKE

Veamos un ejemplo de un sencillo TRIGGER que presenta un mensaje cada vez que se añade un nuevo autor a la tabla authors de la base de datos pubs

CREACIÓN DE TRIGGERS MEDIANTE ENTERPRISE MANAGER

También es posible crear TRIGGERS mediante Enterprise Manager. A pesar de ser un objeto más de la base de datos, los TRIGGERS no aparecen en la

ventana Server Manager, por lo que deberán ser creados utilizando opciones de menú. Concreatamente deberán seguirse los siguientes pasos: 

Pulsar el menú Manage TRIGGERS, una vez seleccionada en la ventana Server Manager una base de datos.



Seleccionar la tabla a la que se desee asociar un TRIGGER, de la lista desplegable adjunta.



Escoger New



Escribir las sentencias de creación del TRIGGER ELIMINACIÓN DE TRIGGERS

Para eliminar un TRIGGER puede utilizarse la sentencia DROP TRIGGER, análogamente al resto de objetos. Puede eliminarse más de un TRIGGER de manera simultánea pasando a la sentencia sus nombres separados por comas. SINTAXIS DROP TRIGGER DROP TRIGGER [prop.]nombretrigger1 [, [prop.]nombretrigger2...]

Utilización de TRIGGERS para validar actualizaciones de tablas

Una de las principales utilidades de los TRIGGERS es la de controlar que las operaciones de actualización que se llevan a cabo sobre una tabla sean coherentes. De este modo podemos centralizar en la base de datos los procesos de validación de datos, tanto al añadir nuevos registros como en su eliminación.

Las tablas Inserted y Deleted En multitud de ocasiones las operaciones de actualización de la tabla que suponen inserción y borrado de filas se llevan a cabo en cadena, normalmente por la propia naturaleza de las sentencias implicadas.

En este tipo de situaciones el TRIGGER que deba responder a estas acciones puede necesitar valorar qué cambios se han producido sobre la tabla de manera que se pueda obrar en consecuencia. Para ello se necesitaría disponer de algún modo de información del estado de la tabla antes y después de las modificaciones efectuadas. Para ello SQL Server proporciona dos tablas temporales denominadas Para conocer el número de filas modificadas por una sentencia de actualización determinada es posible acudir a la variable global @@rowcount. Esta variable contiene el número de filas modificadas. INSERCIÓN MÚLTIPLE La tabla inserted almacena una copia de las filas que se han añadido durante la ejecución de una sentencia INSERT o UPDATE sobre una tabla que tiene asociado un TRIGGER. BORRADO MÚLTIPLE La tabla deleted almacena una copia de las filas eliminadas durante una sentencia DELETE o UPDATE. Evidentemente, una vez realizada la loperación de borrado, las filas desaparecerán de la tabla asociada al TRIGGER y sólo aparecerán en la tabla deleted TRIGGERS y TRANSACCIONES Los TRIGGERS pueden descartar las transacciones en el marco de las cuales se ejecutan. Es decir, los TRIGGERS pueden ser ejecutados en respuesta a una acción que se haya inmersa en una transacción. Si uno de estos TRIGGERS

contiene

sentencia

ROLLBACK

TRANSACTION,

que

recordemos tiene como resultado el descartar las operaciones realizadas en la transacción en curso, la transacción completa en la que dicho TRIGGER se ejecuta será descartada. Veamos un ejemplo en que la operación UPDATE tiene asociado un TRIGGER que, por cualquier circunstancia que no nos detendremos a concretar, provoca

que la transacción en curso sea descartada mediante ROLLBACK. En el ejemplo que sigue la operación INSERT no se ejecutará, pues la transacción se dará por finalizada después de la sentencia UPDATE. 

TRANSACCIONES y TRIGGERS

BEGIN TRANSACTION UPDATE alumnos SET nota = nota + 1 WHERE notapracticas = 10 INSERT alumnos VALUES ('Javier Márquez', „Grupo3‟, 5.5, 6.3, '6/11/96') END TRANSACTION

UN EJEMPLO COMPLETO Para ilustrar los conceptos expuestos en este artículo vamos a presentar un pequeño ejemplo en el que se utilizan tanto procedimientos almacenados como TRIGGERS. Nos proponemos informatizar una biblioteca creando una base de datos que mantenga información de los volúmenes existentes en su fondo, de los socios inscritos y de los préstamos efectuados. Evidentemente, nuestro objetivo es simplemente ilustrar el sentido y necesidad de procedimientos almacenados y TRIGGERS por lo que el diseño se ha simplificado al máximo evitando cualquier tipo de consideración sobre el modelo de datos. CREACIÓN DE LA BASE DE DATOS El primer paso será definir siquiera burdamente las tablas necesarias. Del más sencillo análisis resulta que es necesario, al menos, definir una tabla libros, una segunda autores, una tercera socios, y una cuarta prestamos, que servirá para almacenar cada acción de préstamo que se lleve a cabo.

La definición de las tablas podemos realizarla mediante Enterprise Manager o utilizando sentencias Transact SQL. Por simplicidad haremos uso de las herramientas visuales de Enterprise Manager, tal y como podemos ver en la figura A.6. Las sentencias Transact_Sql mínimas equivalentes serían 

Tabla libros:

CREATE TABLE libros (registro smallint signatura char(20), titulo varchar(50), nombreautor varchar(50) editorial varchar(20), fechaentrada datetime)



Tabla autores:

CREATE TABLE autores (idautor smallint nombreautor varchar(50), nacionalidad varchar(20))



Tabla socios:

CREATE TABLE socios

(idsocio smallint nombresocio varchar(50), edad smallint, direccion varchar(20), teléfono varchar(10))



Tabla prestamos:

CREATE TABLE prestamos (idprestamo smallint idautor smallint, idsocio smallint, fechaprestamo datetime)

DEFINICIÓN DE PROCEDIMIENTOS ALMACENADOS

Se supone que la base de datos estará disponible al público que visite la biblioteca para que puedan consultar por su cuenta, por ejemplo, los libros de un determinado autor. La manera de hacer posibles estas consultas generalmente será mediante la programación de una pequeña aplicación cliente que enviará a SQL Server las peticiones de datos. Parece evidente que la consulta Libros de un autor será muy frecuente, de manera que será adecuado y adecuado definir en la base de datos un procedimiento almacenado que reciba como argumento el nombre del autor del que se desea conocer su obra completa. Este procedimiento se almacenará en SQL Server y su ejecución será solicitada por las aplicaciones cliente,

obteniendo un rendimiento mejor al que puede obtenerse con la simple realización de la consulta. Veamos una posible implementación de este procedimiento. 

Procedimiento ObraPorAutor

CREATE PROCEDURE ObraPorAutor @nautor varchar(50) AS SELECT titulo, editorial, cantidad FROM libros WHERE nombreautor = @nautor

DEFINICIÓN DE TRIGGERS

Existen múltiples situaciones en las que en este ejemplo sería interesante definir un TRIGGER. Una primera muestra sería la del control de préstamo. Imaginemos que deseamos evitar que cada socio pueda tener más de un libro simultáneamente en su poder. Cada vez que se realiza un préstamo nuevo la aplicación cliente solicitará la inserción de una nueva fila en la tabla de préstamos. Podríamos escribir un TRIGGER que tras cada inserción en esta tabla, buscase si existe alguna otra fila en la misma que corresponda a un préstamo al mismo socio, y que eliminase el nuevo préstamo si ya existía uno aún no terminado. La aplicación cliente podría recibir información en la que examinase si la inserción se había realizado correctamente y presentar, si así se desea un mensaje explicativo. Pero, lo que es más importante, los datos de la base de datos serían coherentes. Veamos este ejemplo: 

Inserción condicional de un préstamo

CREATE TRIGGER prestamocondicional ON prestamos FOR INSERT AS IF (SELECT COUNT(*) FROM prestamos, inserted WHERE prestamos.idsocio = inserted. idsocio ) <> @@rowcount BEGIN DELETE * FROM prestamos WHERE prestamos. idprestamo = inserted. idprestamo END Otra posibilidad es la de gestionar la correspondencia entre la tabla libros y la tabla autores cuando se da de baja un ejemplar por pérdida, sustracción o cualquier otra circunstancia. En este caso el TRIGGER deberá examinar, tras la eliminación de un libro, si existe el autor del libro eliminado tiene aún algún volumen en el fondo de la biblioteca, eliminando su entrada en la tabla autores si no es así. El TRIGGER sería similar al siguiente: 

Eliminación condicional de un autor

CREATE TRIGGER comprobarautor ON libros FOR DELETE AS IF

(SELECT COUNT(*) FROM libros WHERE libros.idautor = deleted. idautor ) > 0 BEGIN DELETE * FROM autores WHERE autores. idautor = deleted. idautor END Otro ejemplo con la base de datos ESCUELA, que se activa cada vez que deseo ingresar una calificaci贸n nueva. Lo que que hace es checar si no hay alguna calificaci贸n para ese alumno y esa misma matricula. CREATE TRIGGER ACTUALIZACAL ON Calificacion FOR INSERT AS IF (SELECT COUNT(Calificacion.Cal) FROM Calificacion, inserted WHERE Calificacion.Matricula = inserted.Matricula AND Calificacion.CvMat = inserted.CvMat) > 0 BEGIN DELETE FROM Calificacion WHERE Calificacion.Matricula = inserted.Matricula AND Calificacion.CvMat = inserted.CvMAt END

C贸mo crear un desencadenador (Administrador corporativo)

Para crear un desencadenador 1. Expanda un grupo de servidores y, a continuaci贸n, un servidor. 2. Expanda Bases de datos, expanda la base de datos a la que pertenece la tabla que va a contener el desencadenador y, a continuaci贸n, haga clic en Tablas. 3. En el panel de detalles, haga clic con el bot贸n secundario del mouse en la tabla en la que va a crear el desencadenador, seleccione Todas las tareas y haga clic en Administrar desencadenadores. 4. En el cuadro Nombre, haga clic en <nuevo>. 5. En el cuadro Texto, escriba el texto del desencadenador. Utilice Ctrl+Tab para aplicar una sangr铆a al texto de un desencadenador. 6. Para comprobar la sintaxis, haga clic en Comprobar la sintaxis.

EJEMPLO: tomando como base el siguiente esquema

El siguiente TRIGGER lo que hace es disminuir las existencias en base a la cantidad de producto vendido.

CREATE TRIGGER Inventario ON VentaProducto FOR INSERT AS DECLARE @Cant INTEGER DECLARE @Exis INTEGER DECLARE @ClaveP INTEGER SELECT @Cant = Cantidad, @ClaveP = CvProd FROM VentaProducto SELECT @Exis = Existencias FROM Producto WHERE CvProd = @ClaveP

BEGIN UPDATE Producto SET Existencias = @Exis- @cant WHERE CvProd = @ClaveP

END 1.6.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.6.3.2.

MATERIAL DE APOYO

1.6.4. ACTIVIDADES DE APRENDIZAJE 1.6.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A6-EC3 Procedimientos de disparo

1.6.4.1.1. INSTRUCCIONES Indicar la instrucción de los siguientes TRIGGERS: 1. Un disparo que actualice las Existencias de Producto con le realización de una venta. 2. Un disparo que actualice las Existencias de Producto con le realización de una compra. a) Valor actividad: 10 Puntos b) Producto esperado: Sentencias SQL de los dos plateamientos propuestos c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes) 1.6.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Procedimientos de disparo

DESARROLLO Entregar en papel la solucion y corroborar que funcionen con SQL Server 2000. Total

PONDERACIÓN 10 puntos 10 puntos

1.6.5. RESULTADO DE APRENDIZAJE Validar cuestiones de integridad de datos y aprender a validar ciertas reglas de negocio que se pueden presentar. 1.6.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 1.6.7. DOCUMENTOS Manual SQL Server 2000 Standard final

1.7.

VISTAS

1.7.1. OBJETIVO DE APRENDIZAJE Aprender a crear Tablas Virtuales, las cuales son de mucha ayuda para ciertas necesidades. 1.7.2. RECURSOTIEMPO DEL TEMA 6 horas 1.7.3. DESARROLLO

La definición más simple de una vista es la que nos dice que una vista es una consulta a la que se da un nombre. Una vista es una tabla virtual que nos permite alcanzar tres objetivos: 

La confidencialidad de la información



La transparencia de la estructura interna de la BD



El control de las restricciones de integridad

Se denomina virtual porque no tiene existencia propia; ella parece y se comporta como una tabla para el usuario, pero consiste a nivel interno en una sentencia SQL, que esta catalogada en el diccionario de datos. Una vez que la vista se ha detenido, se puede acceder a ella exactamente igual que si fuese una tabla para ver su estructura o para seleccionar los datos que contiene. El mayor problema asociado a las vistas es determinar cuando los datos de una vista se pueden actualizar (insertar, borrar o modificar filas). Las tablas indicadas en la consulta que define una vista se denominan tablas base, y pueden a su vez ser vistas.

Puede utilizar las vistas para simplificar las consultas. Un modelo de datos normalizado puede estar formado por muchas tablas. Si los usuarios finales están autorizados a consultar los datos de forma interactiva, probablemente desee simplificar el modelo de datos, incluso si los usuarios utilizan potentes herramientas de análisis. Una simplificación habitual consiste en realizar una combinación en la definición de la vista. En lugar de que el usuario realice la combinación cada vez que escriba una consulta, trabajara utilizando una vista.

La sentencia utilizada para crear una vista es CREATE VIEW, cuya sintaxis general se muestra a continuación.

CREATE VIEW nombre vista AS sentencia SELECT

Como ejemplo creamos una vista que encuentre todos los alumnos que cursan una materia de Ingles.

CREATE VIEW dbo.vista1 AS SELECT

FROM

Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación

Alumno INNER JOIN Calificacion

ON Alumno.Matricula = Calificacion.Matricula INNER JOIN Materia ON Calificacion.CvMat = Materia.CvMat WHERE

Materia.Nombre = 'Ingles'

CONSULTA A TRAVÉS DE UNA VISTA

SELECT * FROM vista1 WHERE Alumno = 'xxxx'

La consulta anterior toma a la vista como una tabla propia de la Base de Datos, aunque en realidad no lo es, lo que paso fue que al momento de ejecutar la vista se creo una tabla virtual.

La sentencia utilizada para eliminar una vista es DROP VIEW, cuya sintaxis general se muestra a continuación.

DROP VIEW nommbre_vista

La sentencia utilizada para modificar una vista es ALTER VIEW, cuya sintaxis es idéntica a la sintaxis de la instrucción CREATE VIEW.

Ejemplo para modificar la vista1 creada arriba.

ALTER VIEW vista1 AS SELECT

FROM

Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación

Alumno INNER JOIN Calificacion

ON Alumno.Matricula = Calificacion.Matricula INNER JOIN Materia ON Calificacion.CvMat = Materia.CvMat WHERE

Materia.Nombre = 'Fisica'

1.7.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

1.7.3.2.

MATERIAL DE APOYO

1.7.4. ACTIVIDADES DE APRENDIZAJE 1.7.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A7-EC4 Vistas

1.7.4.1.1. INSTRUCCIONES Elaborar las siguientes vistas: 1. Crear una vista de los productos que surte un poroveedor. 2. Una vista para los pagos de los clientes por cada venta a credito

a) b) c) d) e) f)

Valor actividad: 10 Puntos Producto esperado: Dos tablas virtuales Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo (3 gentes) 1.7.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Vista

DESARROLLO Las sentencias deben de ser entregadas en papel y deben de ser corroboradas en SQL Server 2000 Total

PONDERACIÓN 10 puntos 10 Puntos

1.7.5. RESULTADO DE APRENDIZAJE Hay ocasiones en que tenemos que crear una consulta y después con los valores obtenidos de esta consulta se realizan otras acciones, este problema se puede solucionar con subconsultas, pero el que se utilicen Vistas nos da la posibilidad de poder manejar los resultados de esa consulta como una tabla virtual, precisamente esto se espera de este tema. 1.7.6. BIBLIOGRAFÍA Ayuda SQL Server 2000 1.7.7. DOCUMENTOS Manual SQL Server 2000 Standard final

UNIDAD TEMATICA 2. INTEGRIDAD DE DATOS y MANEJO DE INDICES INTEGRIDAD: consistencia o corrección de datos en la base de datos. Las reglas de integridad (RI) no son específicas para cada usuario.

1. Nos interesan las reglas de integridad específicas de una BD (reglas del negocio), además de RI Entidad, RI Referencial... 2. Veremos las RI definidas sobre relaciones base, por estar restringidas a contener datos correctos (reflejar la realidad).

Veremos las RI definidas sobre relaciones base, por estar restringidas a contener datos correctos (reflejar la realidad). La regla “los títulos de las películas son únicos” se aplica a la tabla base PELICULA, y a cualquier vista definida sobre ésta ¿Podemos definir RI sobre relaciones derivadas (sobre vistas)? 

Sería deseable



La vista heredaría toda RI de sus relaciones base y podría añadir nuevas (clave candidata nueva para la vista, p.ej.)

Solo consideraremos RI sobre relaciones base (por simplicidad)

3. Nos interesa soporte de RI declarativo

No hablaremos de... 

Procedimientos almacenados (stored procedures), ni de



Procedimientos disparados (triggered procedures)

4. Una BD en un estado de integridad es correcta si: 

No viola ninguna RI conocida por el SGBD, es decir, satisface AND lógico de todas las RI definidas en su esquema.

5. La integridad es importante en... 

DISEÑO (estructuras de datos y reglas de integridad adecuadas)



EJECUCIÓN (corrección de la información)

6. RI son mantenidas en el Catálogo del Sistema

El Subsistema de Integridad del SGBD: 

Controla operaciones de usuario (INSERT,UPDATE,DELETE...) para asegurar que NO violan las reglas de integridad

COMPONENTES DE UNA REGLA DE INTEGRIDAD

A. Nombre 

Regla almacenada en el Catálogo del Sistema bajo ese nombre.



Aparecerá en diagnósticos, producidos por el sistema como respuesta a intentos de violación de la regla (mensajes de error al usuario)

B. Restricción NOT EXISTS (SELECT * FROM ACTOR WHERE cache <= 0) 

Expresión booleana.



La regla

o Se satisface, la restricción es TRUE o Es violada, la restricción es FALSE

C. Respuesta a un intento de violación de la regla 

Indica al SGBD qué hacer si se intenta una operación que viola la RI



Por defecto RECHAZAR (o rehusar) que implica... o Deshacer los posibles daños causados por la operación o Mostrar información de diagnóstico (mensaje)



Podría ser un procedimiento de complejidad arbitraria: tratarErr(...)

CREACIÓN, DESTRUCCIÓN Y TIPOS DE REGLAS DE INTEGRIDAD

A. Creación de una regla de integridad... (en cualquier momento) El SGBD comprueba: ¿el estado actual de la BD satisface RI? 

Sí RI aceptada o El sistema la almacena en el catálogo o La regla es activada (entra en vigor) 

SGBD controlará todo INSERT y UPDATE de caché en ACTOR



No RI rechazada

B. Destrucción de reglas de integridad 

El sistema elimina su definición del catálogo

Las RIs pueden restringir los valores legales de... 

Dominio



Atributo



Relación



Base de Datos

2.1.

TIPOS DE INTEGRIDAD DE DATOS

2.1.1. OBJETIVO DE APRENDIZAJE Conocer las diferentes formas de integridad de datos que existen, para evitar por ejemplo redundancia de información o ausencia de la misma.

2.1.2. RECURSO TIEMPO DEL TEMA 1 hora 2.1.3. DESARROLLO RESTRICCIONES, REGLAS, VALORES PREDETERMINADOS Y DESENCADENADORES Las columnas de tablas tienen otras propiedades además del tipo y el tamaño de los datos. Estas propiedades forman una parte importante en la garantía de la integridad de los datos de una base de datos. 

La integridad de los datos significa que todas las apariciones de una columna tienen un valor de datos correcto. Los valores de los datos tienen que ser del tipo de datos correcto y se tienen que encontrar en el dominio definido.



La integridad referencial indica que las relaciones entre las tablas se tienen que mantener de la forma adecuada. Los datos de una tabla sólo tienen que apuntar a filas existentes de otra tabla; no pueden apuntar a filas inexistentes.

Los objetos que se utilizan para mantener ambos tipos de integridad son: 

Restricciones



Reglas



Valores predeterminados



Desencadenadores

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 Clave de Empleado = 123, la base de datos no debe permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna Sueldo para la que se prevea valores entre el $1,500.00 y el $5,00.00 la base de datos no debe

aceptar el valor $6,000.00. Si en la tabla hay una columna NumDep 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. Estas son las categorías de integridad de datos: 

Integridad de entidad



Integridad de dominio



Integridad referencial



Integridad definida por el usuario

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™, 2000 la integridad referencial se basa en las relaciones entre claves externas y claves principales o entre claves externas y claves exclusivas (mediante restricciones

FOREIGN KEY, restricciones CHECK). La integridad referencial garantiza que los valores clave sean 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 Calificación y Alumno de la base de datos ESCUELA, la integridad referencial se basa en la relación entre la clave externa (Matricula) de la tabla Calificación y la clave principal (Matricula) de la tabla Alumno.

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 (todas las restricciones en columnas y tablas de CREATE TABLE, procedimientos almacenados y desencadenadores).

Ejemplo de una restricci贸n CHECK

El sueldo de un Docente debe ser mayor que 1000 y menor a 5000.

CREATE TABLE Docente ( Folio SMALLINT IDENTITY(1,1) PRIMARY KEY CLUSTERED, Nombre

VARCHAR(50) NOT NULL

DEFAULT 'xxx', Sueldo FLOAT NOT NULL CHECK (Sueldo >= 1000 AND Sueldo <=5000) )

//explicacion de la restriccion CREATE TABLE Docente Crea la tabla Docente Folio SMALLINT IDENTITY(1,1) PRIMARY KEY CLUSTERED, Crea el campo Folio de tipo SMALLINT, IDENTITY crea una columna de identidad en una tabla. Esta propiedad se utiliza con las instrucciones CREATE TABLE y ALTER TABLE de Transact-SQL.

Sintaxis IDENTITY [ ( seed , increment ) ] Argumentos

seed Es el valor que se utiliza para la primera fila cargada en la tabla.

Increment.

Se trata del valor incremental que se agrega al valor de identidad de la anterior fila cargada. Es necesario especificar la inicialización y el incremento, o no especificar ninguno de los dos. Si no se especifica ninguno, el valor predeterminado es (1,1). PRIMARY KEY CLUSTERED es una restricción que exige la integridad de entidad para una o varias columnas dadas a través de un índice único. Sólo se puede crear una restricción PRIMARY KEY por cada tabla y CLUSTERED indica que se ha creado un indice agrupo (En temas posteriores se vera el tema de indices). Nombre

VARCHAR(50) NOT NULL

DEFAULT 'xxx', Crea otro campo mas a la tabla que se llama Nombre el cual

es de tipo

VARCHAR con 50 espacios, NOT NULL indica que el valor de este campo no puede ser nulo, DEFAULT ‘xxx’ El valor por default que se le da al campo.

Sueldo FLOAT NOT NULL CHECK (Sueldo >= 1000 AND Sueldo <=5000) Crea

otro

campo

que

llama

Sueldo

tipo

FLOTA

nulo,

CHECK(Sueldo >= 1000 AND Sueldo <=5000) indica que el valor de este campo tendra que ser mayor o igual que 1000 y menor o igual que 5000, lo que significa que esta institución no paga menos de 1000 y no paga mas de 5000.

INTEGRIDAD DE ENTIDAD Restricciones UNIQUE 

Si no se especifica CLUSTERED o NONCLUSTERED para una restricción UNIQUE, de forma predeterminada se utiliza NONCLUSTERED.



Cada restricción UNIQUE genera un índice. El número de restricciones UNIQUE no puede hacer que el número de índices de la tabla exceda de 249 índices no agrupados y 1 índice agrupado.

Utilizando la restricción UNIQUE (Me limitare en los siguientes ejemplos a solo explicar el significado de las instrucciones nuevas...)

CREATE TABLE Empleado ( Clave SMALLINT PRIMARY KEY, Nombre VARCHAR(50) NOT NULL, Puesto VARCHAR(15) NOT NULL UNIQUE )

Puesto VARCHAR(15) NOT NULL UNIQUE, esta linea lo que provoca es que el valor del campo Puesto no se repita. En este ejemplo tambien se realiza la restricción PRIMARY KEY, la cual indica que el campo Clave es la llave de la tabla Empleado.

INTEGRIDAD DE DOMINIO

Las definiciones DEFAULT se pueden: 

Crear cuando se crea la tabla, durante el proceso de definición de la misma.



Agregar a una tabla ya existente. Cada columna de una tabla puede contener una sola definición DEFAULT.



Modificar o eliminar, si ya existen definiciones DEFAULT. Por ejemplo, puede modificar el valor que se inserta en una columna cuando no se escribe ningún valor.

Nota Para modificar una definición DEFAULT mediante TransactSQL o SQL-DMO, antes deberá eliminar la definición DEFAULT existente y, a continuación, volver a crearla con la nueva definición. No se puede crear definiciones DEFAULT para columnas definidas con: 

Un tipo de datos timestamp.



Una propiedad IDENTITY o ROWGUIDCOL.



Una definición DEFAULT o un objeto DEFAULT ya existentes.

Nota El valor predeterminado debe ser compatible con el tipo de datos de la columna a la que se aplica la definición DEFAULT. Por ejemplo, el valor predeterminado para una columna int debe ser un número entero, no una cadena de caracteres. Cuando se agrega una definición DEFAULT a una columna existente en una tabla, Microsoft® SQL Server™ 2000 aplica de forma predeterminada el nuevo valor predeterminado sólo a las nuevas filas de datos que se agregan a la tabla; los datos existentes que se insertan mediante la definición DEFAULT anterior no se ven afectados. No obstante, cuando agregue una nueva columna a una tabla ya existente, puede especificar que SQL Server inserte en la nueva columna el valor predeterminado (especificado mediante la definición DEFAULT) en vez de un valor NULL para las filas existentes en la tabla. Cuando elimine una definición DEFAULT, SQL Server insertará un valor NULL en vez del valor predeterminado si no se inserta ningún valor para las nuevas

filas de la columna. No obstante, no se realizan cambios en los datos existentes en la tabla.

ALTER TABLE Secretaria ADD ESTUDIO VARCHAR(20) DEFAULT 'Superior'

La instrucción anterior modifica la tebla Secretaria agregándole un campo mas ESTUDIO de 20 caracteres, además por DEFAULT

le coloca el valor de

„Superior‟. INTEGRIDAD REFERENCIAL

La integridad referencial entre tablas se exige de forma predeterminada cuando se crea una relación en el diagrama de base de datos. Una relación exigida garantiza que cada valor especificado en una columna de clave externa coincida con un valor existente en la columna de clave principal relacionada.

Restricciones FOREIGN KEY 

Cuando en la columna de una restricción FOREIGN KEY se introduce un valor distinto de NULL, el valor debe existir en la columna a la que se hace referencia; de lo contrario, se devuelve un mensaje de error de infracción de clave externa.



Las restricciones FOREIGN KEY se aplican a la columna anterior a menos que se especifiquen columnas de origen.



Las restricciones FOREIGN KEY sólo pueden hacer referencia a las tablas de la misma base de datos en el mismo servidor. La integridad referencial de las bases de datos cruzadas debe implementarse a través de desencadenadores. Para obtener más información, consulte CREATE TRIGGER.



Las restricciones FOREIGN KEY pueden hacer referencia a otras columnas de la misma tabla (una auto-referencia).



La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de columna puede enumerar sólo una columna de referencia, que debe tener el mismo tipo de datos que la columna en la que se define la restricción.



La cláusula REFERENCES de una restricción FOREIGN KEY en el nivel de tabla debe tener el mismo número de columnas de referencia que el número de columnas de la lista de columnas de restricción. El tipo de datos de cada columna de referencia debe ser también el mismo que la columna correspondiente de la lista de columnas.



Es posible que no se pueda especificar CASCADE si una columna del tipo timestamp forma parte de la clave externa o de la clave a la que se hace referencia.



Se puede combinar CASCADE y NO ACTION en tablas que tengan relaciones referenciales entre sí. Si SQL Server encuentra NO ACTION, termina y deshace las acciones CASCADE relacionadas. Cuando una instrucción DELETE hace que se combinen acciones CASCADE y NO ACTION, todas las acciones CASCADE se aplican antes de que SQL Server compruebe si hay cláusulas NO ACTION.



Una tabla puede contener un máximo de 253 restricciones FOREIGN KEY.



Las restricciones FOREIGN KEY no se exigen en tablas temporales.



Una tabla puede hacer referencia a un máximo de 253 tablas distintas en sus restricciones FOREIGN KEY.



Las restricciones FOREIGN KEY sólo pueden hacer referencia a las columnas de las restricciones PRIMARY KEY o UNIQUE de la tabla de referencia o a las columnas en UNIQUE INDEX de la tabla de referencia.

CREATE TABLE Secretaria ( CvSecre

SMALLINT PRIMARY KEY,

Nombre

VARCHAR(50) NOT NULL,

CvJefe

SMALLINT

FOREIGN KEY (CvJefe) REFERENCES Empleado(Clave) )

Este ejemplo, crea una tabla nueva la cual se llama Secretaria y tiene su propia llave primaria, pero además crea el campo CvJefe el cual hace referencia al campo Clave de la tabla Empleado creada en el ejemplo anterior.

2.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

2.1.3.2.

MATERIAL DE APOYO

2.1.4. ACTIVIDADES DE APRENDIZAJE 2.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A8-ER2 Examen Rápido

2.1.4.1.1. INSTRUCCIONES Formular 5 preguntas del tema de Tipos de Integridad de Datos y dictárselas a los alumnos para que procedan a contestarlas. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 2.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Examen Rápido

DESARROLLO Formular preguntas y dictárselas a los alumnos para que se respondan. Total

2.1.5. RESULTADO DE APRENDIZAJE Repaso Rápido de los conceptos aprendidos. 2.1.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 2.1.7. DOCUMENTOS Manual SQL Server 2000 Standard final

PONDERACIÓN 5 puntos 5 Puntos

2.2. USANDO RESTRICCIONES (CONSTRAINTS) 2.2.1. OBJETIVO DE APRENDIZAJE Entender algunas restricciones de SQL Server para declarar llaves, o características especificas del campo de una tabla. 2.2.2. RECURSOTIEMPO DEL TEMA 2 horas 2.2.3. DESARROLLO

Es una palabra clave opcional que indica el principio de la definición de una restricción PRIMARY KEY, NOT NULL, UNIQUE, FOREIGN KEY o CHECK. Las restricciones son propiedades especiales que exigen la integridad de los datos y pueden crear índices para la tabla y sus columnas. constraint_name Es el nombre de una restricción. Los nombres de restricción deben ser únicos en una base de datos.

Ejemplo: CREATE TABLE Departamento ( CvDepto

SMALLINT,

Nombre

VARCHAR(50) NOT NULL,

CONSTRAINT PK PRIMARY KEY (CvDepto) ) 2.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

2.2.3.2.

MATERIAL DE APOYO

2.2.4. ACTIVIDADES DE APRENDIZAJE 2.2.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A9-EC5 Restricciones CONSTRAINTS 2.2.4.1.1. INSTRUCCIONES Crear la tabla USUARIO con instrucciones SQL, a la cual se le colocan los siguientes campos: NomUsuario(llave primaria), Contraseña(no nula), Nivel.

a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Una tabla mas a la base de datos “ESQUINITA” Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 2.2.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO La tabla creada en la base de Restricciones CONSTRAINTS datos. Total

PONDERACIÓN 5 puntos 5 puntos

2.2.5. RESULTADO DE APRENDIZAJE Crear una tabla con instrucciones SQL y además agregarle ciertas restricciones que van a darle mayor seguridad y evitar duplicaciones de información. 2.2.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 2.2.7. DOCUMENTOS Manual SQL Server 2000 Standard final 2.3. USANDO VALORES POR OMISIÓN Y REGLAS 2.3.1. OBJETIVO DE APRENDIZAJE Aplicar ciertas reglas de negocio desde el momento de creación de las tablas de la base de datos. 2.3.2. RECURSO TIEMPO DEL TEMA 4 horas 2.3.3. DESARROLLO CREATE RULE Crea un objeto denominado regla. Cuando se enlaza una regla a una columna o un tipo de datos definido por el usuario, la regla especifica los valores aceptables que se pueden insertar en esa columna. Las reglas, que son una característica de compatibilidad con versiones anteriores, realizan algunas de las mismas funciones que las restricciones CHECK. Las restricciones CHECK,

creadas mediante la palabra clave CHECK de ALTER o CREATE TABLE, son la forma preferida y estándar de restringir los valores de una columna (se pueden definir restricciones múltiples en una o múltiples columnas). Una columna o tipo de datos definido por el usuario sólo puede tener una regla enlazada. Sin embargo, una columna puede tener una regla y una o más restricciones CHECK asociadas a ella. Cuando esto es así, se evalúan todas las restricciones. Sintaxis CREATE RULE rule AS condition_expression Argumentos rule Es el nombre de la nueva regla. Los nombres de reglas deben seguir las reglas de los identificadores. Especificar el propietario de la regla es opcional. condition_expression Son las condiciones que definen la regla. Una regla puede ser cualquier expresión válida en una cláusula WHERE y puede incluir elementos como operadores aritméticos, operadores relacionales y predicados (por ejemplo, IN, LIKE, BETWEEN). Una regla no puede hacer referencia a columnas u otros objetos de base de datos. Se pueden incluir funciones integradas que no hagan referencia a objetos de base de datos. condition_expresión Incluye una variable. El signo (@) precede a cada variable local. La expresión hace referencia al valor que se introduce con la instrucción UPDATE o INSERT. Se puede utilizar cualquier nombre o símbolo para representar el valor cuando se crea la regla, pero el primer carácter debe ser @. Observaciones La instrucción CREATE RULE no puede combinarse con otras instrucciones Transact-SQL en un único proceso por lotes. Las reglas no se aplican a los datos ya existentes en la base de datos en el momento en que se crearon las reglas y no se pueden enlazar a los tipos de datos del sistema. Una regla sólo se puede crear en la base de datos actual. Una vez creada la regla, ejecute sp_bindrule para enlazarla a una columna o a un tipo de datos definido por el usuario.

La regla debe ser compatible con el tipo de datos de la columna. Una regla no se puede enlazar a una columna text, image o timestamp. Asegúrese de incluir las constantes de fecha y de caracteres entre comillas simples (') y de preceder las constantes binarias con 0x. Por ejemplo, "@valor LIKE A%" no se puede utilizar como regla para una columna numérica. Si la regla no es compatible con la columna a la que se ha enlazado, Microsoft® SQL Server™ devuelve un mensaje de error cuando se inserta un valor, pero no cuando se enlaza la regla. Una regla enlazada a un tipo de datos definido por el usuario sólo se activa cuando se intenta insertar un valor o actualizar una columna de la base de datos del tipo de datos definido por el usuario. Como las reglas no prueban las variables, no debe asignar un valor a una variable de tipo de datos definido por el usuario que sería rechazada por una regla enlazada a una columna del mismo tipo de datos. Para obtener un informe de una regla, utilice sp_help. Para que se muestre el texto de una regla, ejecute sp_helptext con el nombre de la regla como parámetro. Para cambiar el nombre de una regla, utilice sp_rename. Una regla debe quitarse (mediante DROP RULE) antes de crear otra con el mismo nombre y debe cancelarse el enlace (mediante sp_unbindrule) antes de quitarla. Utilice sp_unbindrule para cancelar el enlace de una regla a una columna. Una nueva regla se puede enlazar a una columna o tipo de datos sin cancelar el enlace de la anterior; la nueva regla anula la anterior. Las reglas enlazadas a columnas tienen siempre preferencia sobre las reglas enlazadas a tipos de datos definidos por el usuario. Enlazar una regla a una columna substituye una regla ya enlazada al tipo de datos definido por el usuario de esa columna. Pero el enlace de una regla a un tipo de datos no substituye una regla enlazada a una columna de ese tipo de datos definido por el usuario. La tabla muestra el efecto que tiene precedencia cuando se enlazan reglas a columnas y a tipos de datos definidos por el usuario en los que ya existen reglas. Regla antigua del enlace Nueva regla del enlace

tipo de datos definido por el usuario

Columna

Tipo de datos definido por Regla antigua substituida

Sin cambio

el usuario Columna

Regla antigua substituida

Si una columna tiene un valor predeterminado y una regla asociada a ella, el valor predeterminado debe encontrarse en el dominio definido por la regla. Un valor predeterminado que esté en conflicto con una regla no se inserta nunca. SQL Server genera un mensaje de error cada vez que intenta insertar tal valor predeterminado.

Nota El que SQL Server interprete una cadena vacía como un espacio simple o como una verdadera cadena vacía se controla mediante el valor de sp_dbcmptlevel. Si el nivel de compatibilidad es menor o igual que 65, SQL Server interpreta las cadenas vacías como espacios simples. Si el nivel de compatibilidad es igual a 70, SQL Server interpreta las cadenas vacías como tales. Para obtener más información, consulte sp_dbcmptlevel. Permisos De forma predeterminada, los permisos CREATE RULE se conceden a los miembros de la función fija de servidor sysadmin y a las funciones fijas de base de datos db_ddladmin y db_owner. Los miembros de las funciones sysadmin, db_owner y db_securityadmin pueden transferir los permisos a otros usuarios. Ejemplos A. Regla con un intervalo Este ejemplo crea una regla que restringe el intervalo de enteros que se insertan en las columnas a las que la regla está enlazada.

CREATE RULE Valor AS @Rango >=0 AND @Rango<=100

Se crea una regla que se llama Valor la cual evalua un rango de 0 a 100, esta regla se le puede asignar al campo Cal de la tabla Calificación.

B. Regla con una lista Este ejemplo crea una regla que restringe los valores reales que se escriben en la columna o columnas a las que la regla está enlazada, a sólo aquéllos enumerados en la regla.

CREATE RULE Puesto AS @Descripcion IN ('Director', 'Secretaria', 'Subdirector') C. Regla con un patrón Este ejemplo crea una regla que sigue un patrón de dos caracteres cualquiera con un guión a continuación, cualquier número de caracteres (o no caracteres) y un entero entre 0 y 9 al final.

CREATE RULE pattern_rule AS @value LIKE '_ _-%[0-9]' 2.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

2.3.3.2.

MATERIAL DE APOYO

2.3.4. ACTIVIDADES DE APRENDIZAJE 2.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A10-EC6 Valores por omision.

2.3.4.1.1. INSTRUCCIONES Crear una regla o utilizar una restricción CHECK para validar ciertas cuestiones en los campos de la tabla. 1. De la tabla Cliente el campo RFCC validar que solo reciba 4 letras seguido de 6 numeros y alfinal solo tres letras de la omoclave. 2. La misma regla para el campo RFCP de la tabla Proveedor a) Valor actividad: 5 Puntos b) Producto esperado: Dos tablas con ciertas reglas o restricciones de negocio aplicadas directamente a las tablas. c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes)

2.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Valores por omision

DESARROLLO Checar en la base de datos “ESQUINITA”, las restricciones propuestas. Total

PONDERACIÓN 5 puntos 5 Puntos

2.3.5. RESULTADO DE APRENDIZAJE Entender que es una regla de negocio y como validarla desde la creación de la base de datos. 2.3.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 2.3.7. DOCUMENTOS Manual SQL Server 2000 Standard final

2.4. INTRODUCCIÓN A INDICES 2.4.1. OBJETIVO DE APRENDIZAJE Aprender a manejar indices en las tablas de la base de datos. 2.4.2. RECURSOTIEMPO DEL TEMA 1 hora 2.4.3. DESARROLLO

CREAR UN ÍNDICE Después de determinar el diseño, puede crear índices en las tablas de la base de datos. Microsoft® SQL Server™ 2000 crea automáticamente índices únicos para exigir los requisitos de exclusividad de las restricciones PRIMARY KEY y UNIQUE. A menos que ya exista un índice agrupado en la tabla o que se haya especificado explícitamente un índice no agrupado, se creará un índice único, agrupado, para exigir la restricción PRIMARY KEY. A menos que se especifique

explícitamente

índice

agrupado,

creará

forma

predeterminada un índice único, no agrupado, para exigir la restricción UNIQUE.

Si necesita crear un índice independiente de una restricción, puede utilizar la instrucción CREATE INDEX. De forma predeterminada, se crea un índice no agrupado si no se especifica la opción de agrupación. Otras consideraciones que hay que tener en cuenta en el momento de crear un índice incluyen: 

Sólo el propietario de la tabla puede crear índices en la misma tabla.



Sólo se puede crear un índice agrupado por tabla.



El número máximo de índices no agrupados que pueden crearse por tabla es de 249 (incluidos los índices creados por restricciones PRIMARY KEY o UNIQUE).



El tamaño máximo de todas las columnas de longitud no variable que abarca el índice es de 900 bytes. Por ejemplo, no se puede crear un solo índice para las tres columnas definidas como char(300), char(300) y char (301), ya que la suma total supera los 900 bytes.



El número de columnas que puede abarcar el mismo índice es de 16, como máximo.

Cuando cree índices con la instrucción CREATE INDEX, deberá especificar el nombre del índice, de la tabla y de las columnas a las que se aplica el índice. Los nuevos índices creados como parte de una restricción PRIMARY KEY o UNIQUE, o bien mediante el Administrador corporativo de SQL Server, reciben automáticamente nombres definidos por el sistema que se basan en el nombre de la tabla de la base de datos. Si crea varios índices en una tabla, se adjuntan los sufijos _1, _2, etc. a los nombres de los índices. Si es necesario, puede cambiar el nombre del índice.

Nota No puede crear un índice en la base de datos actual si se está realizando una copia de seguridad de la base de datos. Si se crea un índice agrupado en una tabla con varios índices secundarios, se deben volver a generar todos los índices secundarios de manera que contengan el valor de clave de agrupación en lugar del identificador de fila

(RID). Asimismo, si se elimina un índice agrupado de una tabla con varios índices no agrupados, se vuelven a generar todos los índices no agrupados como parte de la operación DROP. Si las tablas son de gran tamaño, la operación puede prolongarse significativamente. La mejor manera de generar índices en tablas de gran tamaño es empezar con el índice agrupado y, a continuación, generar los índices no agrupados. Al quitar todos los índices, quite primero los índices no agrupados y después los agrupados. De esta forma no es necesario volver a generar los índices.

Índices agrupados Cuando cree un índice agrupado, se copiará la tabla, se ordenarán los datos de la tabla y se eliminará la tabla original. Por lo tanto, debe haber suficiente espacio vacío en la base de datos para que pueda realizarse una copia de los datos. De forma predeterminada, los datos de la tabla se ordenan cuando se crea el índice. Sin embargo, si los datos están ordenados porque ya había un índice agrupado y se vuelve a crear con el mismo nombre y las mismas columnas, la operación de ordenación puede omitirse automáticamente si se vuelve a generar el índice, en vez de crearlo de nuevo. Cuando se vuelve a generar el índice, se comprueba que las filas estén ordenadas mientras se genera el índice. Si las filas no están correctamente ordenadas, se cancelan las operaciones y no se crea el índice.

Índices únicos La creación de un índice único asegura que fracase cualquier intento de duplicar valores clave. Si se crea una sola consulta que provoque la agregación de valores de clave duplicados y no duplicados, SQL Server rechaza todas las filas, incluidas las que tengan valores de clave no duplicados. Por ejemplo, si una sola instrucción de inserción recupera 20 filas de la tabla A y las inserta en la tabla B, pero 10 de esas filas contienen valores de clave duplicados, se rechazarán las 20 filas de forma predeterminada. Sin embargo, se puede especificar la cláusula IGNORE_DUP_KEY cuando se crea el índice; así, sólo se rechazarán los valores de clave duplicados; los no duplicados se agregarán.

En el ejemplo anterior, sólo se rechazarían los 10 valores de clave duplicados; los 10 valores no duplicados se insertarían en la tabla B. No se puede crear un índice único si hay valores de la clave duplicados. Por ejemplo, si desea crear un índice compuesto y único en las columnas a y b, pero hay dos filas en la tabla que contienen los valores 1 y 2 para a y b respectivamente, no se puede crear el índice único.

Nota No se puede crear un índice único en una sola columna si esa columna contiene valores NULL en más de una fila. Tampoco se puede crear un índice único en varias columnas si la combinación de columnas contiene valores NULL en más de una fila. Estos valores se tratan como duplicados a efectos de indización. 2.4.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

2.4.3.2.

MATERIAL DE APOYO

2.4.4. ACTIVIDADES DE APRENDIZAJE 2.4.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A11-I1 Investigacion de Indices

2.4.4.1.1. INSTRUCCIONES Realizar un trabajo de investigación que complemente el tema de indices. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: documento que avale la investigación. Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo (3 gentes) 2.4.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO Contenido de la investigación

PONDERACIÓN 4 puntos

Investigacion de Indices Presentación del trabajo Total

1 punto 5 puntos

2.4.5. RESULTADO DE APRENDIZAJE Entender la importancia del manejo de indices en la optimizacion del tiempo en las consultas a las tablas indexadas. 2.4.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000

2.4.7. DOCUMENTOS Manual SQL Server 2000 Standard final 2.5. ARQUITECTURA y CREACIÓN DE INDICES 2.5.1. OBJETIVO DE APRENDIZAJE Aprender a crear indices en las tablas. 2.5.2. RECURSO TIEMPO DEL TEMA 3 horas 2.5.3. DESARROLLO

ARQUITECTURA DE TABLAS E ÍNDICES Los objetos de una base de datos de Microsoft® SQL Server™ 2000 se almacenan como una colección de páginas de 8 KB. Este tema describe el modo en que se organizan las páginas de tablas e índices. SQL Server 2000 admite índices en las vistas. El primer índice permitido en una vista es un índice agrupado. En el momento en que se ejecuta una instrucción CREATE INDEX en una vista, el conjunto de resultados para la vista se materializa y almacena en la base de datos con la misma estructura que una tabla que tiene un índice agrupado. El conjunto de resultados que se almacena es el mismo que produce esta instrucción.

SELECT * FROM Nombre_Vista

Las filas de datos para cada tabla o vista indizada se almacenan en una colección de páginas de datos de 8 KB. Cada página de datos dispone de una cabecera de 96 bytes que contiene información del sistema como el identificador (Id.) de la tabla que es propietaria de la página. La cabecera de página también incluye punteros a las páginas anteriores y siguientes que se utilizan si las páginas se vinculan a una lista. Al final de la página se encuentra una tabla de desplazamiento de filas. Las filas de datos ocupan el resto de la página.

Organización de páginas de datos Las tablas de SQL Server 2000 utilizan uno de estos dos métodos para organizar sus páginas de datos: 

Las tablas agrupadas son tablas que tienen un índice agrupado. Las filas de datos están almacenadas en un orden basado en la clave del índice agrupado. El índice se implementa como una estructura de árbol B que admite la rápida recuperación de las filas a partir de los valores de claves del índice agrupado. Las páginas de cada nivel del índice, incluidas las páginas de datos del nivel de hoja, se vinculan en una lista con vínculos dobles, pero la navegación de uno a otro nivel se produce mediante valores de clave.



Los montones son tablas que no tienen un índice agrupado. Las filas de datos no están almacenadas en ningún orden particular ni tampoco hay un orden particular en la secuencia de las páginas de datos. Las páginas de datos no están vinculadas en una lista vinculada.

Las vistas indizadas tienen la misma estructura de almacenamiento que las tablas agrupadas. SQL Server admite también hasta 249 índices no agrupados en cada vista de tabla o índice. Los índices no agrupados tienen una estructura de árbol B similar a la de los índices agrupados. La diferencia está en que los índices no agrupados no tienen ningún efecto en el orden de las filas de datos. Las tablas agrupadas y las vistas indizadas mantienen sus filas de datos en orden de acuerdo con la clave del índice agrupado. La colección de páginas de datos de un montón no se ve afectada cuando se definen índices no agrupados en la

tabla. Las páginas de datos permanecen en un montón a menos que se defina un índice agrupado. Las páginas que almacenan datos text, ntext e image se administran como una única unidad por cada tabla. Todos los datos text, ntext e image de una tabla están almacenados en una colección de páginas. Todas las colecciones de páginas para tablas, índices y vistas indizadas están delimitadas por punteros de página en la tabla sysindexes. Cada tabla y vista indizada tiene una colección de páginas de datos, además de colecciones adicionales de páginas para implementar cada índice definido para la tabla o vista. Cada tabla, índice y vista indizada tiene una fila en sysindexes identificada de manera exclusiva por la combinación de la columna del identificador del objeto (id) y la columna del identificador del índice (indid). La asignación de páginas a tablas, índices y vistas indizadas se administra mediante una cadena de páginas IAM. La columna sysindexes.FirstIAM apunta a la primera página IAM de la cadena de páginas IAM que administran el espacio asignado a la tabla, índice o vista indizada. Cada tabla tiene un conjunto de filas en sysindexes: 

Un montón tiene una fila en sysindexes con indid = 0. La columna FirstIAM apunta a la cadena IAM de la colección de páginas de datos de la tabla. El servidor utiliza las páginas IAM para buscar las páginas en la colección de páginas de datos, puesto que no están vinculadas.



Un índice agrupado en una tabla o vista tiene una fila en sysindexes con indid = 1. La columna root apunta a la parte superior del árbol B del índice agrupado. El servidor utiliza el árbol B del índice para buscar las páginas de datos.



Cada índice no agrupado creado para una tabla o una vista tiene una fila en sysindexes.

Los valores de indid de las filas de los índices no agrupados se encuentran entre 2 y 250. La columna root apunta al nodo superior del árbol B del índice no agrupado. 

Todas las tablas que tengan al menos una columna text, ntext o image también tienen una fila en sysindexes, con indid = 255. La columna FirstIAM apunta a la cadena de páginas IAM que administra las páginas text, ntext e image.

En SQL Server 6.5 y anterior, sysindexes.first apunta siempre al inicio de un montón, al inicio del nivel de hoja de un índice, o al inicio de una cadena de páginas text e image. En SQL Server 7.0 y posterior, no se suele utilizar sysindexes.first. En SQL Server 6.5 y anterior, sysindexes.root en una fila con indid = 0 apunta a la última página de un montón. En SQL Server 7.0 y posterior, no se utiliza sysindexes.root en una fila con indid = 0.

Por ejemplo: CREACIÓN DE INDICE Estas instrucciones crean un indice a la tabla Calificacion, para el campo de Cal.

USE ESCUELA CREATE INDEX IndCal ON Calificacion (Cal)

ELIMINACIÓN DE INDICE

USE ESCUELA DROP INDEX Calificacion.IndCal

2.5.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

2.5.3.2.

MATERIAL DE APOYO

2.5.4. ACTIVIDADES DE APRENDIZAJE 2.5.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A12-EC7 Crear Indices 2.5.4.1.1. INSTRUCCIONES Crear indices compuestos en las tablas de VtaProd(Clave Venta y Clave Producto) y CpaProd(Clave Compra y Clave Producto) a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Tablas indexadas Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo(3 gentes) 2.5.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Crear Indices

DESARROLLO Checar las tablas que efectivamente tengan los indices indicados.

PONDERACIÓN 5 puntos Total

5 Puntos

2.5.5. RESULTADO DE APRENDIZAJE Manejo de indices 2.5.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 2.5.7. DOCUMENTOS Manual SQL Server 2000 Standard final

UNIDAD TEMATICA 3. TRANSACCIONES EN LA BASE DE DATOS Entre las habilidades de todo Sistema Gestor de Bases de Datos Relaciones tiene que estar la de permitir al programador crear transacciones. El SQL Server nos permite trabajar con transacciones de manera sencilla y eficaz. Una transacción es una unidad lógica de trabajo o procesamiento: ejecución de un programa que incluye operaciones de acceso a la base de datos (en adelante, BD).

Una transacción es una secuencia de operaciones que llevan la base de datos desde un estado de consistencia1 a otro estado de consistencia, por esto suele decirse también que la transacción es una unidad lógica de integridad. Cuando múltiples transacciones son introducidas en el sistema por varios usuarios, es necesario evitar que interfieran entre ellas de forma tal que provoquen que la BD quede en un estado no consistente; desde este punto de vista, podemos ver una transacción como una unidad lógica de concurrencia. Si ocurre un fallo que provoca la caída del sistema de bases de datos, cuando había varias transacciones en curso de ejecución, muy probablemente los datos en la BD quedarán erróneos (estado inconsistente debido a un fallo); en estas circunstancias, se debe garantizar que la BD pueda ser recuperada a un estado en el cual su contenido sea consistente, observando las transacciones que terminaron su ejecución y las que quedaron a medio; por esto una transacción es considerada también una unidad lógica de recuperación.

3.1. PROCESAMIENTO DE TRANSACCIONES 3.1.1. OBJETIVO DE APRENDIZAJE Entender la finalidad de las Transacciones 3.1.2. RECURSOTIEMPO DEL TEMA ½ horas 3.1.3. DESARROLLO

La idea clave es que una transacción debe ser atómica, es decir, las operaciones que la componen deben ser ejecutadas en su totalidad o no ser ejecutadas en absoluto. Una sentencia de definición o manipulación de datos ejecutada de forma interactiva (por ejemplo utilizar el SQL * Plus de Oracle para realizar una consulta) puede suponer el inicio de una transacción. Asimismo, la ejecución de una sentencia SQL por parte de un programa que no tiene ya una transacción en progreso, supone la iniciación de una transacción. Toda transacción finaliza con una operación de COMMIT (confirmar) o bien con una operación de ROLLBACK (anular, abortar o revertir). 1

El conjunto de valores almacenados en la base de datos cumple toda restricción de integridad especificada en el

esquema, así como cualesquiera otras restricciones que deban cumplirse en la base de datos.

Tanto una operación como la otra puede ser de tipo explícito (si la propia transacción (su código) contiene una sentencia COMMIT o ROLLBACK) o implícito (si dicha operación es realizada por el sistema de forma automática, por ejemplo tras detectar una terminación normal (éxito) o anormal (fallo) de la transacción). Por defecto, una vez finalizada una transacción, si todas sus operaciones se han realizado con éxito, se realiza un COMMIT implícito de dicha transacción; y si alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implícito de la transacción (es decir, se deshacen todas las operaciones que había realizado hasta el momento del fallo). 3.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.1.3.2.

MATERIAL DE APOYO

3.1.4. ACTIVIDADES DE APRENDIZAJE 3.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A13-T3 Cuestionario transacciones.

3.1.4.1.1. INSTRUCCIONES Realizar un cuestionario de 5 preguntas del tema visto. a) b) c) d) e) f)

Valor actividad: 2.5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 3.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Cuestionario transacciones

DESARROLLO Formular preguntas y responderlas, estas se deben de transmitir hacia asu compañeros Total

PONDERACIÓN 2.5 puntos 2.5 Puntos

3.1.5. RESULTADO DE APRENDIZAJE Entender la funcion y ventajas de las transacciones en una base de datos 3.1.6. BIBLIOGRAFÍA Ayuda SQL Server 2000 3.1.7. DOCUMENTOS Manual SQL Server 2000 Standard final

3.2. CONCEPTOS DE TRANSACCIONES 3.2.1. OBJETIVO DE APRENDIZAJE Saber que es una transacción y en que casos se pueden utilizar 3.2.2. RECURSO TIEMPO DEL TEMA ½ hora 3.2.3. DESARROLLO Una transacción es un conjunto de operaciones que van a ser tratadas como una única unidad. Estas transacciones deben cumplir 4 propiedades fundamentales comúnmente conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad). La transacción más simple en SQL Server es una única sentencia SQL. Por ejemplo una sentencia como esta: UPDATE Products SET UnitPrice=20 WHERE ProductName =‟Chai‟ Es una transacción. Esta es una transacción „AUTOCOMMIT‟, una transacción autocompletada. Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de transacciones lo que va a ocurrir y a continuación realiza los cambios necesarios en la base de datos. Si hay algún tipo de problema al hacer esta operación el SQL Server puede leer en el fichero de transacciones lo que se estaba haciendo y si es necesario puede devolver la base de datos al estado en el que se encontraba antes de recibir la sentencia. Por supuesto este tipo de transacciones no requieren de nuestra intervención puesto que el sistema se encarga de todo. Sin embargo si hay que realizar varias operaciones y queremos que sean tratadas como una unidad tenemos que crear esas transacciones de manera explícita. 3.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.2.3.2.

MATERIAL DE APOYO

3.3. PROPIEDADES DE LAS TRANSACCIONES 3.3.1. OBJETIVO DE APRENDIZAJE Conocer cuales son las características especificas de las transacciones.

3.3.2. RECURSO TIEMPO DEL TEMA 1 hora 3.3.3. DESARROLLO

Se suele hacer referencia a estas como las propiedades ACID (por sus iniciales en inglés).

1. Atomicidad

Todas las operaciones de la transacción son ejecutadas por completo, o no se ejecuta ninguna de ellas (si se ejecuta la transacción, se hace hasta el final).

2. Consistencia

Una transacción T transforma un estado consistente de la base de datos en otro estado consistente, aunque T no tiene por qué preservar la consistencia en todos los puntos intermedios de su ejecución. Un ejemplo es el de la transferencia de una cantidad de dinero entre dos cuentas bancarias.

3. Aislamiento (Isolation)

Una transacción está aislada del resto de transacciones. Aunque existan muchas transacciones ejecutándose a la vez, cualquier modificación de datos que realice T está oculta para el resto de transacciones hasta que T sea confirmada (realiza COMMIT). Es decir, para cualesquiera T1 y T2, se cumple que:

- T1 ve las actualizaciones de T2 después de que T2 realice COMMIT, o bien - T2 ve las modificaciones de T1, después de que T1 haga un COMMIT

Pero nunca se cumplen ambas cosas al mismo tiempo.

Nota: esta propiedad puede no imponerse de forma estricta 2; de hecho, suelen definirse niveles de aislamiento de las transacciones.

4. Durabilidad

Una vez que se confirma una transacción, sus actualizaciones sobreviven cualquier fallo del sistema. Las modificaciones ya no se pierden, aunque el sistema falle justo después de realizar dicha confirmación. 3.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.3.3.2.

MATERIAL DE APOYO

3.3.4. ACTIVIDADES DE APRENDIZAJE 3.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A14-ER3 Examen Rápido.

3.3.4.1.1. INSTRUCCIONES Formular 5 preguntas de los dos temas anteriores y dictárselas a los alumnos para que ñas contesten. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 3.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Examen Rápido

DESARROLLO Constestar las preguntas Total

PONDERACIÓN 5 puntos 5 Puntos

3.3.5. RESULTADO DE APRENDIZAJE Comprobar que los alumnos están captando la importancia de las transacciones en una base de datos. 3.3.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 2

Aunque lo estudiaremos en el tema de Recuperación de Caídas en Sistemas de Base de Datos, si se impone de

forma estricta el aislamiento de las transacciones, se resuelve el problema de la actualización temporal y no es necesario realizar reversiones en cascada.

3.3.7. DOCUMENTOS Manual SQL Server 2000 Standard final

3.4. PLANES Y RECUPERABILIDAD 3.4.1. OBJETIVO DE APRENDIZAJE Proponer la forma mas adecuada de 3.4.2. RECURSOTIEMPO DEL TEMA 3.4.3. DESARROLLO

El Subsistema de Recuperación del SGBD es el encargado de conseguir el cumplimiento de las propiedades de atomicidad y durabilidad de las transacciones. La conservación de la consistencia es una propiedad cuyo cumplimiento han de asegurar, por un lado los programadores de base de datos, y por otro el Subsistema de Integridad del SGBD. El Subsistema de Control de Concurrencia es el encargado de conseguir el aislamiento de las transacciones. Para hacer posible el control de la concurrencia de las transacciones, así como la recuperación del sistema tras fallos o caídas del mismo, es necesario almacenar cuándo se inicia, termina, se confirma o se aborta cada transacción, y además qué modificaciones de qué elementos de BD realiza cada una. 

INICIO DE TRANSACCIÓN

Operación que marca el momento en el que una transacción comienza a ejecutarse. En un entorno SQL, esta operación «es implicada» de forma implícita por la primera sentencia SQL que se ejecuta dentro de una transacción. 

LEER o ESCRIBIR

Operaciones de lectura/escritura de elementos de la base de datos, que se realizan como parte de una transacción. 

FIN DE TRANSACCIÓN

Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si la transacción debe abortarse por alguna razón (si viola el control de concurrencia, por ejemplo), o bien si los cambios realizados por la transacción (hasta ahora en búfers de memoria volátil) pueden aplicarse permanentemente a la base de datos en disco (es decir, si puede realizarse una operación de CONFIRMAR). 

CONFIRMAR (COMMIT)

La transacción terminó con éxito, todos los cambios que ha realizado se pueden confirmar sin peligro en la BD y ya no serán cancelados. 

ABORTAR (ROLLBACK)

La transacción terminó sin éxito y toda actualización que ha realizado se debe cancelar. Algunas técnicas de recuperación necesitan operaciones adicionales como las siguientes: 

DESHACER

Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción completa. 

REHACER

Especifica que algunas de las operaciones realizadas por una transacción deben repetirse, para asegurar que todas las operaciones realizadas por una transacción que ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es decir, los cambios hayan quedado grabados físicamente en disco). 3.4.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.4.3.2.

MATERIAL DE APOYO

3.5. SERIABILIDAD DE PLANES 3.5.1. OBJETIVO DE APRENDIZAJE Proponer un plan de recuperación de información a traves te transacciones. 3.5.2. RECURSO TIEMPO DEL TEMA 1 hora 3.5.3. DESARROLLO

ESTADOS DE UNA TRANSACCIÓN

El siguiente es el diagrama de transición de estados para la ejecución de transacciones:

Una transacción entra en el estado ACTIVA justo después de iniciar su ejecución y, en este estado, puede realizar operaciones LEER y ESCRIBIR. Cuando

transacción

finaliza,

pasa

estado

PARCIALMENTE

CONFIRMADA. En este punto, el Subsistema de Control de Concurrencia puede efectuar verificaciones para asegurar que la transacción no interfiera con otras transacciones en ejecución. Además, el Subsistema de Recuperación puede anotar, en un fichero del sistema (bitácora), qué operaciones (qué cambios) ha realizado la transacción, con el objetivo de garantizar que los cambios realizados por la transacción terminada queden permanentes, a pesar de fallos del sistema. Una vez realizadas con éxito ambas verificaciones, la transacción ha llegado a su punto de confirmación y pasa al estado CONFIRMADA (ha concluido su ejecución con éxito). Si una de las verificaciones falla o la transacción se aborta mientras está en estado ACTIVA, pasa al estado FALLIDA. En este caso, es posible que la transacción deba ser cancelada (anulada, revertida, abortada) para anular los efectos de sus operaciones ESCRIBIR sobre la BD. El estado TERMINADA indica que la transacción ha abandonado el sistema. Las transacciones fallidas (abortadas) pueden ser reiniciadas posteriormente, ya sea de forma automática por parte del sistema, o bien sea el usuario el que las reintroduzca como si fueran nuevas transacciones.

Protocolos de bloqueo en dos fases 

Transacción dos fases: bloquea primero todos los gránulos, ejecuta operaciones y luego desbloquea todos.



Toda ejecución completa de un conjunto de transacciones con protocolo de bloqueo en dos fases es serializable.



En bloqueo en dos fases limita la cantidad de concurrencia al realizar bloqueos tempranos y liberaciones tardías de recursos.



Variaciones del bloqueo en dos fases o Bloqueo básico o Bloqueo conservativo o estático --> bloquea antes de comenzar o Bloqueo estricto --> desbloquea después de terminar totalmente

Problemas derivados del uso de bloqueos 

Interbloqueo (deadlock) o Imposibilidad de realizar simultáneamente dos operaciones no compatibles sobre el mismo gránulo o Dos o más transacciones quedan en espera de un recurso



Esperada indefinida (livelock) o Una transacción no entra mientras exista otra



Inanición (starvation) o El módulo controlador siempre mata a la misma o Transacción para resolver un interbloqueo

3.5.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.5.3.2.

MATERIAL DE APOYO

3.5.4. ACTIVIDADES DE APRENDIZAJE 3.5.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A15-T4 Cuestionario planes.

3.5.4.1.1. INSTRUCCIONES Realizar un cuestionario de 5 preguntas del tema visto. a) b) c) d) e)

Valor actividad: 2.5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento

f) Tipo de Actividad: Individual 3.5.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Cuestionario planes

DESARROLLO Formular preguntas y responderlas, estas se deben de transmitir hacia asu compañeros Total

PONDERACIÓN 2.5 puntos 2.5 Puntos

3.5.5. RESULTADO DE APRENDIZAJE Repasar ciertas características de las transacciones 3.5.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 3.5.7. DOCUMENTOS Manual SQL Server 2000 Standard final

3.6. TRANSACCIONES SQL 3.6.1. OBJETIVO DE APRENDIZAJE Aprender a crear transacciones en una base de datos. 3.6.2. RECURSO TIEMPO DEL TEMA 8 horas 3.6.3. DESARROLLO Como decíamos una transacción es un conjunto de operaciones tratadas como una sola. Este conjunto de operaciones debe marcarse como transacción para que todas las operaciones que la conforman tengan éxito o todas fracasen. La sentencia que se utiliza para indicar el comienzo de una transacción es „BEGIN TRAN‟. Si alguna de las operaciones de una transacción falla hay que deshacer la transacción en su totalidad para volver al estado inicial en el que estaba la base de datos antes de empezar. Esto se consigue con la sentencia „ROLLBACK TRAN‟. Si todas las operaciones de una transacción se completan con éxito hay que marcar el fin de una transacción para que la base de datos vuelva a estar en un estado consistente con la sentencia „COMMIT TRAN‟.

Un ejemplo

Trabajaremos con la base de datos ESCUELA en nuestros ejemplos.

Vamos a realizar una transacción que modifica las calificaciones de dos alumnos de la base de datos. USE ESCUELA DECLARE @ERROR int BEGIN TRAN UPDATE Calificacion SET Cal = 90 WHERE Matricula= 2004001 AND CvMat = 100

SET @ERROR=@@ERROR IF (@ERROR<>0) GOTO TratarError UPDATE Calificacion SET Cal = 100 WHERE Matricula= 2004002 AND CvMat = 100

SET @ERROR=@@ERROR IF (@ERROR<>0) GOTO TratarError COMMIT TRAN TratarError: IF @@ERROR<>0 BEGIN PRINT „Ha recorrido un ERROR. Abortamos la transacción‟ ROLLBACK TRAN END

USE ESCUELA DECLARE @ERROR int

Declaramos una variable que utilizaremos para almacenar un posible código de ERROR.

BEGIN TRAN

Iniciamos la transacción UPDATE Calificacion SET Cal = 90 WHERE Matricula= 2004001 AND CvMat = 100

Ejecutamos la primera sentencia

SET @ERROR=@@ERROR

Si ocurre un ERROR almacenamos su código en @ERROR y saltamos al trozo de código que deshará la transacción. Si, eso de ahí es un GOTO, el demonio de los programadores, pero no pasa nada por usarlo cuando es necesario

IF (@ERROR<>0) GOTO TratarError

Si la primera sentencia se ejecuta con éxito, pasamos a la segunda UPDATE Calificacion SET Cal = 100 WHERE Matricula= 2004002 AND CvMat = 100

SET @ERROR=@@ERROR

Y si hay un ERROR hacemos como antes

IF (@ERROR<>0) GOTO TratarError

Si llegamos hasta aquí es que los dos UPDATE se han completado con éxito y podemos "guardar" la transacción en la base de datos.

COMMIT TRAN

TratarError:

Si ha ocurrido algún ERROR llegamos hasta aquí

IF @@ERROR<>0 BEGIN PRINT „Ha recorrido un ERROR. Abortamos la transacción‟

Se lo comunicamos al usuario y deshacemos la transacción todo volverá a estar como si nada hubiera ocurrido

ROLLBACK TRAN END

Como se puede ver para cada sentencia que se ejecuta miramos si se ha producido o no un ERROR, y si detectamos un ERROR ejecutamos el bloque de código que deshace la transacción. Hay una interpretación incorrecta en cuanto al funcionamiento de las transacciones que esta bastante extendida. Mucha gente cree que si tenemos varias sentencias dentro de una transacción y una de ellas falla, la transacción se aborta en su totalidad. ¡Nada más lejos de la realidad! Si tenemos dos sentencias dentro de una transacción.

USE ESCUELA BEGIN TRAN UPDATE Calificacion SET Cal=85 WHERE Matricula=2004001 AND CvMat= 100 UPDATE Calificacion SET Cal=85 WHERE Matricula=2004001 AND CvMat= 100

COMMIT TRAN

Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de la transacción (después del primer UPDATE y antes del segundo) hay un corte de electricidad, cuando el SQL Server se recupere se encontrará en medio de una transacción y, o bien la termina o bien la deshace, pero no se quedará a medias. El ERROR está en pensar que si la ejecución de la primera sentencia da un ERROR se cancelará la transacción. El SQL Server sólo se preocupa de

ejecutar las sentencias, no de averiguar si lo hacen correctamente o si la lógica de la transacción es correcta. Eso es cosa nuestra. Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro conjunto averiguamos si se ha producido un ERROR y si es así actuamos en consecuencia cancelando toda la operación. TRANSACCIONES ANIDADAS Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones anidadas. Esto quiere decir que podemos tener transacciones dentro de transacciones, es decir, podemos empezar una nueva transacción sin haber terminado la anterior. Asociada

esta

idea

anidamiento

existe

una

variable

global

@@TRANCOUNT que tiene valor 0 si no existe ningún nivel de anidamiento, 1 si hay una transacción anidada, 2 si estamos en el segundo nivel de anidamiento… y así sucesivamente. La dificultad de trabajar con transacciones anidadas está en el comportamiento que tienen ahora las sentencias „COMMIT TRAN‟ y „ROLLBACK TRAN‟ ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia deshace todas las transacciones internas hasta la instrucción BEGIN TRANSACTION más externa. COMMIT TRAN: Dentro de una transacción anidada esta sentencia únicamente reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza" ninguna transacción ni "guarda" los cambios. En el caso en el que @@TRANCOUNT=1 (cuando estamos en la última transacción) COMMIT TRAN hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transacción sean parte permanente de la base de datos, libera los recursos mantenidos por la conexión y reduce @@TRANCOUNT a 0.

Como siempre un ejemplo es lo mejor para entender como funciona.

BEGIN TRAN TranExterna SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004001, 300, 90) BEGIN TRAN TranInterna1 SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004002, 200, 85) BEGIN TRAN TranInterna2 SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004002, 100, 100) COMMIT TRAN TranInterna2 SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranInterna1 SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranExterna SELECT 'El nivel de anidamiento es', @@TRANCOUNT SELECT * FROM Calificacion

BEGIN TRAN TranExterna

@@TRANCOUNT ahora es 1

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004001, 300, 90) BEGIN TRAN TranInterna1

@@TRANCOUNT ahora es 2.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004002, 200, 85) BEGIN TRAN TranInterna2

@@TRANCOUNT ahora es 3.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004002, 100, 100) COMMIT TRAN TranInterna2

Reduce @@TRANCOUNT a 2. Pero no se guarda nada en la base de datos.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranInterna1

Reduce @@TRANCOUNT a 1. Pero no se guarda nada en la base de datos.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranExterna

Reduce @@TRANCOUNT a 0. Se lleva a cabo la transacci贸n externa y todo lo que conlleva.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT SELECT * FROM Calificacion

Por cierto que lo de usar nombre para las transacciones es por claridad, puesto que COMMIT TRAN como ya hemos dicho solamente reduce en 1 el valor de @@TRANCOUNT. Veamos ahora un ejemplo de transacci贸n anidada con ROLLBACK TRAN BEGIN TRAN TranExterna

@@TRANCOUNT ahora es 1

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004001, 100, 0) BEGIN TRAN TranInterna1

@@TRANCOUNT ahora es 2.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Calificacion VALUES (2004002, 200, 85) BEGIN TRAN TranInterna2

@@TRANCOUNT ahora es 3.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT

INSERT INTO Calificacion VALUES (2004002, 100, 100) ROLLBACK TRAN

@@TRANCOUNT es 0 y se deshace la transacción externa y todas las internas.

SELECT 'El nivel de anidamiento es', @@TRANCOUNT SELECT * FROM Calificacion

En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace todas las transacciones dentro de nuestro anidamiento hasta la transacción más externa y además hace @@TRANCOUNT=0 ¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un problema? Pues la verdad es que no. La manera de tratar las transacciones por el SQL Server es la que nos permite programar de manera natural los anidamientos. De todos modos, si queremos ir un poco más lejos hay una cuarta sentencia para trabajar con transacciones: SAVE TRAN SAVE TRAN Esta sentencia crea un punto de almacenamiento dentro de una transacción. Esta marca sirve para deshacer una transacción en curso sólo hasta ese punto. Por supuesto nuestra transacción debe continuar y terminar con un COMMIN TRAN (o los que hagan falta) para que todo se guarde o con un ROLLBACK TRAN para volver al estado previo al primer BEGIN TRAN. BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1

SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Test VALUES (1) BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2. SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Test VALUES (2) SAVE TRAN Guardada BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3. SELECT 'El nivel de anidamiento es', @@TRANCOUNT INSERT INTO Test VALUES (3) ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado. SELECT 'El nivel de anidamiento es', @@TRANCOUNT --Ahora podemos decidir si la transacción se lleva a cabo --o se deshace completamente --Para deshacerla un ROLLBACK bastará como hemos visto --Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0 COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 2. SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1. -- Pero no se guarda nada en la base de datos. SELECT 'El nivel de anidamiento es', @@TRANCOUNT COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0. -- Se lleva a cabo la transacción externa y todo lo que conlleva. SELECT 'El nivel de anidamiento es', @@TRANCOUNT SELECT * FROM Test

Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un ROLLBACK TRAN se deshace la transacción más externa y @@TRANCOUNT se pone a 0. Como podemos ver el uso de transacciones no es complicado, e incluso las transacciones anidadas si se tratan con cuidado son fáciles de manejar. Como

siempre si hay alguna duda la mejor fuente de ejemplos y soluciones son los BOL del SQL Server. 3.6.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

3.6.3.2.

MATERIAL DE APOYO

3.6.4. ACTIVIDADES DE APRENDIZAJE 3.6.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A16-EC8 Transacciones.

3.6.4.1.1. INSTRUCCIONES Realizar las siguientes transacciones en la base de datos “ESQUINITA”: 1. No permitir vender si no hay suficientes productos en existencias. 2. al momento de comprar productos aumentar las existencias de productos. 3. Realizar un pago de un cliente, se debe insertar un pago nuevo mas aparte actualizar el campo de Resto de la tabla VentaC 4. Eliminar producto (no se permite mientras haya alguna venta a credito para este producto) a) Valor actividad: 10 Puntos b) Producto esperado: Cuatro operaciones basicas para las base de datos hechas almacenadas. c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes) 3.6.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Transacciones

DESARROLLO Verificar que todas las transacciones funcionen dentro de la base de datos. Deben de ser entregadas en papel. Total

PONDERACIÓN

10 puntos

10 Puntos

3.6.5. RESULTADO DE APRENDIZAJE Validar ciertas reglas de integridad, para evitar inconsistencia de la información. 3.6.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000

3.6.7. DOCUMENTOS Manual SQL Server 2000 Standard final

UNIDAD TEMATICA 4. SEGURIDAD Una base de datos debe tener un sistema de seguridad sólido para controlar qué actividades se pueden realizar y qué información se puede ver y modificar. Un sistema de seguridad sólido garantiza la protección de los datos, independientemente de la manera en que los usuarios tienen acceso a la base de datos.

4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS 4.1.1. OBJETIVO DE APRENDIZAJE Saber controlar algunos aspectos mas importantes de la seguridad que SQL Server 2000 ofrece. 4.1.2. RECURSO TIEMPO DEL TEMA 1 hora 4.1.3. DESARROLLO

Las Bases de Datos (BDs) incluidas hoy en día en los sistemas de información de cualquier organización, nacen con el fin de resolver las limitaciones que en algunos casos presentan los ficheros para el almacenamiento de información. En los entornos de Bases de Datos, las diferentes aplicaciones y usuarios utilizan un único conjunto de datos integrado a través de un Sistema de Gestión de Bases de Datos (SGBD). De esta forma se pueden resolver problemas como duplicación de información, inconsistencia de los datos y dependencia entre programa y estructura de datos. Por otra parte, la agrupación de datos pertenecientes a distintos usuarios y catalogados en niveles de seguridad diferentes aumenta los riesgos en cuanto a la seguridad de los datos. El sistema de BD debe controlar si está autorizada cada operación sobre la BD. Para conseguir un entorno de BD seguro se han de identificar las amenazas reales, elegir las políticas de seguridad adecuadas que establezcan mecanismos de prevención así como métodos que comprueben que no se han producido accesos ilícitos.

Las BDs que contienen información sobre datos financieros son un blanco tentador para los ladrones. Asímismo, las BDs que contienen información referentes a las operaciones de una compañía pueden ser de interés para sus competidores sin escrúpulos. También existen BD que por su contenido personal deben ser mantenidas en estricto secreto. Por otra parte, la pérdida de operatividad del SGBD o de información de sus BDs es un problema que afecta muy seriamente al funcionamiento de una compañía. Una amenaza contra la seguridad de las BDs es un agente hostil que puede difundir o modificar información gestionada por el SGBD sin la debida autorización. Las amenazas contra la seguridad se clasifican en accidentales y fraudulentas. Las primeras son consecuencia de accidentes, errores de hardware o software y fallos humanos, mientras que las segundas son realizadas intencionadamente por usuarios no autorizados o agentes hostiles. Las violaciones que puede sufrir un entorno de BD consisten en lecturas, modificaciones y borrado de datos. Las consecuencias de estas violaciones son: difusión de información confidencial, modificación no autorizada de datos e incluso denegación de servicio a usuarios. A continuación se estudian dos aspectos de seguridad que afectan particularmente a las BDs como son la deducción ilícita de información confidencial a partir de información accesible y vulneraciones de la integridad de sus datos. También se enumeran otros aspectos de seguridad importantes a tener en cuenta en un SGBD.3 Inferencia Las vulneraciones en un SGBD debidas a la inferencia permiten deducir información confidencial de la BD. Por ejemplo, cuando en una BD tenemos dos campos relacionados por una función matemática siendo uno accesible y el otro secreto, si el atacante conoce la relación podrá hacerse fácilmente con los datos secretos. También se considera inferencia cuando se reduce el nivel de incertidumbre sobre ciertos datos. Por ejemplo, si se pretende mantener en secreto donde va el jet privado del presidente y en la BD que gestiona los vuelos gubernamentales aparece el número de litros de combustible que se han cargado en el avión podremos, con un sencillo cálculo, acotar los lugares a 3

http://www.sc.ehu.es/jiwibmaj/ApuntesCastellano/TEMA_9-bd.pdf (02/08/05)

los que puede ir. La inferencia de información secreta se puede realizar aplicando únicamente el sentido común, o utilizando información auxiliar.

Agregación Agregación consiste en el proceso de combinar múltiples objetos de una BD en un objeto con un nivel de seguridad mayor que sus partes. Si se toman objetos de tipos diferentes se llama agregación inferencial, si se combinan objetos del mismo tipo se denomina agregación cardinal. Los dos tipos precisan de diferente forma de prevención.

Integridad de la BD La integridad de las BDs es un tema ampliamente tratado en la literatura de BDs. Las vulneraciones de la integridad de la BD permiten la modificación, adición o borrado de información de la BD. La integridad se debe garantizar también frente a errores del sistema, virus y sabotajes que puedan dañar los datos almacenados. Este tipo de protección se consigue mediante controles del sistema apropiados, procedimientos de respaldo y recuperación y también mediante procedimientos de seguridad ad hoc4. En general podemos diferenciar dos peligros que requieren tratamientos diferentes. Por una parte tenemos el problema de la consistencia de los datos debido a errores en el sistema y por otra los usuarios que pretenden realizar modificaciones no autorizadas en la BD. EL SGBD debe mantener la consistencia de los datos incluidos en la BD frente a peligros como la caída del sistema, bloqueo mutuo entre procesos que realizan accesos concurrentes, etc. Los accesos para realizar modificaciones en la BD son tareas delicadas que la puede dejar inconsistente. Por ejemplo, si mientras se está modificando un registro de la BD hay un corte de fluido eléctrico, no podremos estar seguros de que se habrá quedado grabado en la BD. Para mantener la consistencia, la SGBD trabaja con transacciones, que son unidades de programa que realizan una única función lógica en una aplicación de la BD.

Procedimientos almacenados del sistema que permiten la supervisión

Las transacciones deben cumplir dos requisitos: (1) ser atómicas, esto es, todos las operaciones asociadas a una transacción deben ejecutarse por completo o ninguna de ellas, y (2) ser correctas, es decir, cada transacción debe ser un programa que conserve la consistencia de la BD. Si se produce algún incidente durante la ejecución de una transacción que deje la BD inconsistente el SGBD debe recuperar el estado previo a dicha transacción. Los procedimientos de respaldo y recuperación tienen como objetivo poder recuperar un estado anterior de la BD. Para ello, mantienen en un fichero (fichero LOG o Bitácora de la BD) información sobre las transacciones que se realizan. Si por cualquier razón se detecta que se pierde la consistencia en la BD el sistema de recuperación deshace las modificaciones realizadas por las últimas transacciones hasta dejar la BD consistente. Para asegurar la integridad operativa de la BD se ha de controlar la consistencia lógica de los datos cuando se producen transacciones concurrentes. Por ejemplo, cuando un agente desea modificar un registro mientras otro lo esta leyendo. Cuando se pueden producir accesos simultáneos a un mismo objeto de la BD la práctica común consiste en bloquear el objeto accedido el tiempo que dure la operación y liberarlo una vez completada. Esta técnica, sin embargo, tiene que verificar que no se produzcan bloqueos mutuos entre varias aplicaciones. En cuanto a los intentos de acceso indebido con el fin de modificar la BD, en general las políticas de integridad se basan en limitar los privilegios a los usuarios en cada momento de tal forma que cada usuario sólo puede acceder a los datos que precisa para su trabajo y utilizando únicamente las operaciones estrictamente necesarias. Las restricciones de privilegios no sólo se aplican a departamentos dentro de una organización sino también a grupos de usuarios con tareas comunes. Una mejora para realizar esto de forma ordenada consiste en utilizar los roles que permiten agrupar usuarios que comparten los mismos privilegios. Así, el SGBD puede controlar más fácilmente las actividades de los usuarios y detectar cambios en los privilegios otorgados a cada role (ver figura 4.1). Además, el administrador de la BD puede fácilmente modificar los privilegios a grupos de usuarios cambiando un único role.

Fig. 4.1 : Ejemplo de control de acceso basado en roles.

El SGBD también puede garantizar la integridad semántica de los datos manteniendo los valores en los rangos que se les hayan asignado. Las restricciones de integridad representan este tipo de controles. Esto debe ser cuidado cuando se hace el diseño de la BD.

En general para anular los efectos de operaciones que han alterado inadecuadamente la BD se emplean los mecanismos de respaldo y recuperación.

Seguridad en sql server

SQL Server valida a los usuarios con 2 niveles de seguridad; autentificación del login y validación de permisos en la Base de Datos de cuentas de usuarios y de roles. La autentificación identifica al usuario que está usando una cuenta y verifica sólo la habilidad de conectarse con SQL Server. El usuario debe tener permiso para accesar a las Bases de Datos en el Servidor. Esto se cumple para asignar permisos específicos para la Base de Datos, para las cuentas de usuario y los roles. Los permisos controlan las actividades que el usuario tiene permitido realizar en la Base de Datos del SQL Server.

Autentificación del login:

Un usuario debe tener una cuenta para conectarse al SQL Server.

Este

reconoce 2 mecanismos de autentificación: Autentificación de SQL Server y de Windows NT. Cada uno tiene un diferente tipo de cuenta.

Autentificación de sql server

Cuando se usa, un administrador del Sistema de SQL Server, define una cuenta y un password WQL Server. Los usuarios deben suministrar tanto el login como el password cuando se conectan al SQL Server.

Autentificación de windows nt

Cuando se usa, el usuario no necesita de una cuenta de SQL Server, para conectarse. Un administrador del sistema debe definir, ya sea cuentas de Windows NT o grupos de Windows NT como cuentas válidas de SQL Server.

Modo de autentificación

Cuando SQL Server está corriendo en Windows NT, un sistema administrador puede especificar que está corriendo en uno de 2 modos de autentificación:  Modo de autentificación de Windows NT: Sólo está autorizada la autentificación de Windows NT. Los usuarios no pueden usar cuentas de SQL Server.  Modo mixto: Cuando se usa este modo de autentificación, los usuarios se pueden conectar a SQL Server con la autentificación de Windows NT o con la de SQL Server.

Cuentas de usuario y roles en una base de datos

Después de que los usuarios han sido autentificados, y se les ha permitido conectarse al SQL Server, deben tener cuentas en la Base de Datos. Las cuentas de usuario y los roles, identifican permisos para ejecutar tareas.

Cuentas de usuarios de la base de datos

Las cuentas de usuario utilizadas para aplicar permisos de seguridad son las de usuarios, o grupos de Windows NT o las de SQL Server. Las cuentas de usuario son específicas para cada Base de Datos.

Roles

Permiten reunir a los usuarios en una sola unidad a la cual se le pueden aplicar permisos.

SQL Server contiene roles de servidor y de Base de Datos

predefinidos, para tareas administrativas comunes, de manera que pueden asignársele determinados permisos administrativos a un usuario en particular. También se pueden crear roles de Base de Datos definidos por el usuario. En SQL Server, los usuarios pueden pertenecer a varios roles:  Roles fijos del Servidor: Proveen agrupamientos con privilegios administrativos

nivel

del

Servidor.

Son

administrados

independientemente de las Bases de Datos de usuarios a nivel servidor.  Roles fijos de la Base de Datos: Proveen agrupamientos con privilegios administrativos a nivel de Base de Datos.

 Roles de usuarios definidos en la Base de Datos: También se pueden crear roles para Base de Datos, para representar un trabajo desarrollado por un grupo de empleados dentro de una organización. No es necesario asignar y quitar permisos a cada persona. En función de que cambia un rol, se pueden cambiar fácilmente los permisos del rol y hacer que los cambios se apliquen automáticamente a todos los miembros del rol.

Validación de permisos

Dentro de cada Base de Datos, se asignan permisos a las cuentas de usuarios y a los roles para permitir o limitar ciertas acciones.

SQL Server acepta

comandos después de que un usuario ha accesado a la Base de datos.

SQL Server realiza los siguientes pasos cuando valida permisos: 1. Cuando el usuario realiza una acción, tal como ejecutar un comando de Transact-SQL o elegir una opción de un menú, los comandos de Transact SQL son enviadas al SQL Server. 2. Cuando SQL Server recibe un comando de Transact –SQL, checa que el usuario tenga permiso de ejecutar dicha instrucción. 3. Después, SQL realiza cualquiera de las siguientes acciones: a) Si el usuario no tiene los permisos adecuados, SQL Server devuelve un error. b) Si el usuario tiene los permisos adecuados, SQL Server realiza la acción.

Crear cuentas de seguridad

Cada usuario debe obtener acceso a una instancia de Microsoft® SQL Server™ a través de una cuenta de inicio de sesión que establece su capacidad para conectarse (autenticación). A continuación, esta cuenta de inicio de sesión se asigna a una cuenta de usuario de SQL Server que se utiliza para controlar las actividades realizadas en la base de datos (validación de permisos). Por tanto, se asigna un único inicio de sesión a cada cuenta de usuario creada en cada base de datos a la que el inicio de sesión tiene acceso. Si en una base de datos no hay ninguna cuenta de usuario, el usuario no podrá tener acceso a ella, aunque pueda conectarse a una instancia de SQL Server. El inicio de sesión se crea en Microsoft Windows NT® 4.0 o Windows® 2000, y no en SQL Server. A continuación, se concede permiso a este inicio de sesión para conectarse a una instancia de SQL Server. Se concede acceso al inicio de sesión en SQL Server. Cómo agregar una cuenta de inicio de sesión de SQL Server (Administrador corporativo) Para agregar una cuenta de inicio de sesión de SQL Server 1. Expanda un grupo de servidores y, a continuación, un servidor. 2. Expanda Seguridad, haga clic con el botón secundario del mouse (ratón) en Inicios de sesión y, a continuación, haga clic en Nuevo inicio de sesión. 3. En Nombre, escriba un nombre para el inicio de sesión de Microsoft® SQL Server™. 4. En Autenticación, seleccione Autenticación de SQL Server. 5. Opcionalmente, en Contraseña, escriba una contraseña. 6. Opcionalmente: 

En Base de datos, haga clic en la base de datos predeterminada a la que se conecta la cuenta de inicio de sesión después de iniciar una sesión en una instancia de SQL Server.



En Idioma, haga clic en el idioma predeterminado en el que se mostrarán los mensajes al usuario.

4.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

4.1.3.2.

MATERIAL DE APOYO

4.1.4. ACTIVIDADES DE APRENDIZAJE 4.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A17-EC9 Crear usuarios.

4.1.4.1.1. INSTRUCCIONES Crear 2 tipos de usuario, uno administrador (todos los derechos) y uno general (solo puede consultar y agregar información).

a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Dos usuarios dentro de la base de datos Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Individual 4.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Crear usuarios

DESARROLLO Verificar que los dos usuario este creados en la base de datos. Total

PONDERACIÓN 5 puntos 5 Puntos

4.1.5. RESULTADO DE APRENDIZAJE Concesión y renovación de privilegios a los usuarios. 4.1.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 4.1.7. DOCUMENTOS Manual SQL Server 2000 Standard final 4.2. TIPOS DE SEGURIDAD 4.2.1. OBJETIVO DE APRENDIZAJE Aplicar los mecanismos de seguridad que SQL Server 2000 ofrece para aprovecharlos al máximo. 4.2.2. RECURSO TIEMPO DEL TEMA 2 horas

4.2.3. DESARROLLO

Mecanismos de seguridad en SGBD Análogamente a lo que sucede en los sistemas operativos, los SGBDs han de ser diseñados teniendo en cuenta la seguridad desde las primeras etapas del desarrollo. El SGBD juega un papel crucial en cuanto a la seguridad en una organización. Obviamente, el sistema operativo debe proporcionar ciertos mecanismos de protección básicos. Por ejemplo, el sistema operativo ha de garantizar la identidad del usuario y la protección de los ficheros físicos sobre los que está soportada la BD. Por otra parte, el SGBD debe hacerse cargo de restricciones

seguridad

dependientes

las

aplicaciones.

Los

requerimientos de seguridad principales deben hacer frente a los siguientes aspectos: Acceso a diferentes niveles de granularidad. En un entorno de BD se puede acceder a los datos a diferentes niveles (BD, colección de relaciones, una relación, conjunto de columnas de una relación, algunas filas de una relación etc.). El SGBD debe establecer controles de acceso a cada nivel de granularidad. Varios modos de acceso. Los controles de acceso deben ser distintos según la operación a realizar. Por ejemplo Select, Insert, UPDATE, DELETE en SQL. Diferentes tipos de control de acceso. El acceso se puede regular mediante diferentes tipos de controles: control basado en el nombre del objeto a acceder, control basado en el contenido del objeto a acceder, control dependiente del contexto (ej.: permitir o denegar el acceso dependiendo de ciertas variables de entorno como el día, hora o terminal), control dependiente de la secuencia de acciones del usuario y finalmente control dependiente del procedimientos auxiliares. Autorización dinámica. El SGDB debe ser capaz de modificar las autorizaciones de los usuarios dinámicamente mientras la BD sea operativa. Protección multinivel. Las BD pueden beneficiarse del mecanismo de protección multinivel explicado en el capítulo anterior. Con este método se etiqueta cada objeto de la BD con un nivel de seguridad. Teniendo en cuenta los diferentes niveles de granularidad dentro de una BD, podemos tener una

relación etiquetada con un nivel de seguridad y los atributos de dicha relación tienen su propio nivel de seguridad. Auditoría. Los eventos importantes o sospechosos que se produzcan durante operaciones con la BD deben ser almacenados para su posterior análisis en busca de acciones no autorizadas. Las secuencias de acciones realizadas por un mismo usuario puede ser utilizadas para detectar posibles inferencias. Esta práctica puede ser un agente disuasor contra los usuarios que tengan malas intenciones. El problema de la auditoria estriba en la cantidad de información que se ha de almacenar si deseamos controlar operaciones a un bajo nivel de granularidad. Además de estos requerimientos, el SGBD debe asegurarse de que no existan canales encubiertos a través de los cuales de pueda divulgar información confidencial, puertas traseras que permitan acceder a usuarios no autorizados. Asímismo se ha de controlar el flujo de la información. Normalmente, el recurso que se utiliza para restringir el acceso a las BD son las vistas. Las vistas son una forma de proporcionar a cada usuario un modelo personalizado de la BD. Una vista puede ocultar al usuario los datos que no necesita ver, y de la misma forma, los datos a los que tiene negado el acceso. El objetivo de seguridad se logra si se dispone de un mecanismo que limite a los usuarios a utilizar sus vistas personales. Otros mecanismos sencillos y evidentes que mejoran la seguridad en las BDs son contrastar periódicamente los datos informáticos con los reales e implementar las aplicaciones que operen con el sistema de BD de forma que sean fáciles de utilizar para evitar en los posible los errores. Otra medida de seguridad interesante es guardar las tablas de la BD y no dejarlas disponibles a terceros que puedan extraer información de su estructura que luego les sirva para realizar deducciones de la BD. La mejor forma de ocultarlas será mediante cifrado. Finalmente, una cuestión a tener en cuenta en los sistemas de información es la eficiencia. Los controles de seguridad entrañan un costo computacional adicional por lo que se ha de lograr un compromiso entre mantener el tiempo de respuesta de la BD en límites razonables y la BD segura.

USUARIOS Un identificador (Id.) de usuario identifica a un usuario dentro de una base de datos. Todos los permisos y la propiedad de los objetos de la base de datos están controlados por la cuenta del usuario. Las cuentas de usuario son específicas de una base de datos; la cuenta de usuario xyz de la base de datos sales es diferente de la cuenta de usuario xyz de la base de datos inventory, aunque ambas cuentas tengan el mismo Id. Los Id. de los usuarios son definidos por los miembros de la función fija db_owner de la base de datos. Por sí mismo, el Id. de inicio de sesión no concede al usuario los permisos para tener acceso a los objetos de las bases de datos. El Id. de inicio de sesión tiene que estar asociado a un Id. de usuario en cada base de datos para que quien se conecte con dicho Id. de inicio de sesión pueda tener acceso a los objetos de la base de datos. Si en una base de datos no se ha asociado explícitamente un Id. de inicio de sesión a un Id. de usuario, se asocia al Id. del usuario guest. Si una base de datos no tiene la cuenta de usuario guest, el inicio de sesión no puede tener acceso a la base de datos a menos que se asocie a una cuenta de usuario válida. Cuando se define un Id. de usuario, se asocia a un Id. de inicio de sesión. Por ejemplo, un miembro de la función db_owner puede asociar el inicio de sesión NETDOMAIN\Joe de Microsoft® Windows® 2000 al Id. de usuario abc en la base de datos sales y el Id. de usuario def en la base de datos employee. La asociación predeterminada es que el Id. de inicio de sesión y el Id. de usuario sean iguales. Este ejemplo muestra la concesión de acceso a una base de datos de una cuenta de Windows 2000 y la asociación del inicio de sesión a un usuario de la base de datos:

USE master GO sp_grantlogin 'NETDOMAIN\Sue' GO sp_defaultdb @loginame = 'NETDOMAIN\Sue', defdb = 'sales' GO

USE sales GO sp_grantdbaccess 'NETDOMAIN\Sue', 'Sue' GO

En la instrucción sp_grantlogin, al usuario NETDOMAIN\Sue de Windows 2000 se le concede acceso a Microsoft SQL Server™ 2000. La instrucción sp_defaultdb establece que la base de datos sales sea su base de datos predeterminada. La instrucción sp_grantdbaccess concede al inicio de sesión NETDOMAIN\Sue acceso a la base de datos sales y establece que Sue es su Id. de usuario dentro de sales. Este ejemplo muestra la definición de un inicio de sesión en SQL Server, asignando una base de datos predeterminada y asociando el inicio de sesión a un usuario de la base de datos:

USE master GO sp_addlogin @loginame = 'TempWorker', @password = 'fff', defdb = 'sales' GO USE sales GO sp_grantdbaccess 'TempWorker' GO

La instrucción sp_addlogin define un inicio de sesión en SQL Server que va a ser utilizado por varios empleados temporales. La instrucción especifica también la base de datos sales como base de datos predeterminada para el inicio de sesión. La instrucción sp_grantdbaccess concede al inicio de sesión TempWorker acceso a la base de datos sales; como no se especifica el nombre del usuario, el valor predeterminado es TempWorker. Un usuario de una base de datos se identifica por su Id. de usuario, no por su Id. de inicio de sesión. Por ejemplo, sa es una cuenta de inicio de sesión que se asigna a la cuenta de usuario especial dbo (propietario de la base de datos) en todas las bases de datos. Todas las instrucciones Transact-SQL

relacionadas con la seguridad utilizan el Id. de usuario como el parámetro security_name. La administración y la compresión de los permisos son menos confusas si los miembros de la función fija sysadmin del servidor y de la función fija db_owner de la base de datos configuran el sistema de tal manera que el Id. de inicio de sesión y el Id. de usuario sean iguales en cada usuario, pero no es obligatorio. La cuenta guest es una cuenta de usuario especial en las bases de datos SQL Server. Si un usuario utiliza una instrucción USE base de datos para tener acceso a una base de datos en la que no tiene asociada una cuenta de usuario, se le asociará al

INTERFAZ DE SEGURIDAD DE SQL SERVER

PROPIEDADES DE SQL SERVER: FICHA SEGURIDAD Utilice esta ficha para ver o especificar las siguientes opciones.

Opciones SQL Server y Windows Especifica que los usuarios pueden conectarse a la instancia de Microsoft® SQL Server™ mediante la autenticación de SQL Server y la autenticación de Windows. Esto se considera una autenticación en Modo mixto. Los usuarios que se conectan a través de una cuenta de usuario de Microsoft Windows NT 4.0 o Windows 2000 pueden utilizar las conexiones en las que se confía, ya sea en el Modo de autenticación de Windows o en el Modo mixto. Cuando un usuario se conecta a través de una cuenta de usuario de Windows NT 4.0 o Windows 2000, SQL Server vuelve a validar el nombre y la contraseña de la cuenta solicitando a Windows NT 4.0 o Windows 2000 la información. Sólo Windows Especifica que los usuarios pueden conectarse a la instancia de SQL Server utilizando sólo la autenticación de Windows. Ninguna Deshabilita la auditoría. Éste es el valor predeterminado para esta configuración. Correcto Audita en los intentos de inicio de sesión que sean correctos. Es posible registrar los accesos de usuario que se intente, así como información de registro de SQL Server de otro tipo; también puede habilitar la auditoría para ambos modos de seguridad y registrar información sobre conexiones, tanto en las que se confía como en las que no. Las entradas de registro para estos sucesos aparecen en el registro de aplicación de Microsoft Windows®, en el registro de errores de SQL Server o en ambos, según cómo se haya configurado la opción de registro para la instancia de SQL Server. Si selecciona esta opción, debe detener y reiniciar el servidor para habilitar la auditoría. Error Audita en los intentos de inicio de sesión que no sean correctos. Es posible registrar los accesos de usuario que se intente, así como información de registro de SQL Server de otro tipo; también puede habilitar la auditoría para ambos modos de seguridad y registrar información sobre conexiones, tanto en las que se confía como en las que no. Las entradas de registro para estos

sucesos aparecen en el registro de aplicación de Windows, en el registro de errores de SQL Server o en ambos, según cómo se haya configurado la opción de registro para la instancia de SQL Server. Si selecciona esta opción, debe detener y reiniciar el servidor para habilitar la auditoría. Todas Audita tanto los intentos de inicio de sesión correctos como los erróneos. Es posible registrar los accesos de usuario que se intente, así como información de registro de SQL Server de otro tipo; también puede habilitar la auditoría para ambos modos de seguridad y registrar información sobre conexiones, tanto en las que se confía como en las que no. Las entradas de registro para estos sucesos aparecen en el registro de aplicación de Windows, en el registro de errores de SQL Server o en ambos, según cómo se haya configurado la opción de registro para la instancia de SQL Server. Si selecciona esta opción, debe detener y reiniciar el servidor para habilitar la auditoría. Cuenta del sistema Especifica que la cuenta de servicio de la instancia de SQL Server es la cuenta integrada del administrador del sistema local. Esta cuenta Especificar que la cuenta de servicio de SQL Server es una cuenta de dominio de Microsoft Windows NT® o de Windows 2000. Este campo está habilitado sólo si utiliza una cuenta de administrador válida de Windows NT 4.0 o Windows 2000 en el equipo en donde se está ejecutando la instancia registrada de SQL Server. Contraseña Especifica la contraseña para la cuenta de dominio de Windows NT 4.0 o Windows 2000. Este campo sólo se habilita si utiliza una cuenta de administrador de Windows NT 4.0 o Windows 2000 en el equipo donde se ejecuta la instancia registrada de SQL Server.

PROPIEDADES DEL USUARIO DE LA BASE DE DATOS: FICHA GENERAL Utilice esta ficha para ver o especificar las siguientes opciones. Opciones Nombre de inicio de sesión Especifica el nombre de inicio de sesión del usuario de la base de datos. Nombre de usuario Especifica el nombre del usuario de la base de datos. Permisos Muestra el cuadro de diálogo de propiedades Propiedades del usuario de la base de datos, donde puede especificar los permisos del usuario para la base de datos. Permitir en la función de base de datos Especifica la función de base de datos a la que pertenece el usuario. Propiedades Muestra el cuadro de diálogo Propiedades de la función de la base de datos, donde puede agregar o quitar usuarios de la función.

4.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

4.2.3.2.

MATERIAL DE APOYO

4.2.4. ACTIVIDADES DE APRENDIZAJE 4.2.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A18-EC10 Seguridad de SQL.

4.2.4.1.1. INSTRUCCIONES Crear un usuario de Windows nuevo. Después con el usuario que estas firmado (checar cual es la contraseña) agregarlo a SQL Server 2000 como la cuenta de inicio de servicio. Posterior a todo esto cerrar la sesion y abrir sesion con el usuario nuevo, verifiacar que la base de datos “ESQUINITA” no se puede acceder desde este usuario. a) Valor actividad: 5 Puntos b) Producto esperado:Ralacionar el usuario de Windows con SQL Server 2000 c) Fecha inicio: d) Fecha entrega: e) Forma de entrega:Base de datos con seguridad Windows f) Tipo de Actividad: Individual 4.2.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Seguridad de SQL

DESARROLLO Checar que la base de datos efectivamente no pueda se accesada por ningun otro usuario salvo el que esta agregado. Total

PONDERACIÓN

5 puntos

5 Puntos

4.2.5. RESULTADO DE APRENDIZAJE Brindarle mayor seguridad a nuestra base de datos. 4.2.6. BIBLIOGRAFÍA Manual SQL Server 2000 Standard final 4.2.7. DOCUMENTOS Ayuda SQL Server 2000, SQL Server 7.0

4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN / RENOVACION DE PRIVILEGIOS. 4.3.1. OBJETIVO DE APRENDIZAJE

Poder administrar los derechos y restricciones de los usuarios respecto de las bases de datos. 4.3.2. RECURSO TIEMPO DEL TEMA 2 horas 4.3.3. DESARROLLO

PROPIEDADES DEL USUARIO DE LA BASE DE DATOS: FICHA PERMISOS Utilice esta ficha para ver o especificar las siguientes opciones. Una marca negra indica que el permiso se ha concedido. Una X roja indica que el permiso se ha denegado. Opciones Usuario de la base de datos Especifica el usuario para el que se muestran los permisos. Enumerar todos los objetos Enumera todos los objetos de la base de datos seleccionada. Haga clic en el cuadro correspondiente para modificar los permisos del usuario para la base de datos.

Enumerar sólo los objetos con permisos para este usuario Enumera sólo los objetos para los que el usuario tiene permiso. Haga clic en el cuadro correspondiente para modificar los permisos del usuario para la base de datos. Columnas Muestra el cuadro de diálogo Permisos de columna, donde puede administrar los permisos para cada columna. ADMINISTRAR PERMISOS Cuando los usuarios se conectan a una instancia de Microsoft® SQL Server™, las actividades que pueden realizar se determinan mediante los permisos que se conceden a: 

Sus cuentas de seguridad.



Los grupos o jerarquías de funciones de Microsoft Windows NT® 4.0 o Windows® 2000 a los que pertenecen sus cuentas de seguridad.

El usuario debe tener los permisos adecuados para realizar cualquier actividad que implique cambiar la definición de una base de datos o el acceso a su contenido. La administración de permisos incluye la concesión o revocación de los derechos de usuario para: 

Trabajar con datos y ejecutar procedimientos (permisos de objeto).



Crear una base de datos o un elemento en la base de datos (permisos de instrucción).



Utilizar los permisos concedidos a las funciones predefinidas (permisos implícitos).

Permisos de objeto Al trabajar con datos o ejecutar un procedimiento, es necesario disponer de una clase de permisos conocida como permisos de objeto. 

Permisos para las instrucciones SELECT, INSERT, UPDATE y DELETE, que pueden aplicarse a toda la tabla o vista.



Permisos para las instrucciones SELECT y UPDATE, que pueden aplicarse selectivamente a columnas individuales de una tabla o vista.



Permisos para la instrucción SELECT, que se puede aplicar a funciones definidas por el usuario.



Permisos para las instrucciones INSERT y DELETE, que afectan a toda una fila y, por ello, sólo pueden aplicarse a la tabla o vista, y no a columnas individuales.



Permisos para la instrucción EXECUTE, que afecta a funciones y procedimientos almacenados.

Permisos de instrucción Las actividades que implica la creación de una base de datos o de uno de sus elementos, como una tabla o un procedimiento almacenado, necesitan una clase diferente de permisos, llamados permisos de instrucción. Por ejemplo, si un usuario necesita crear una tabla en una base de datos, será necesario otorgarle el permiso de instrucción CREATE TABLE. Los permisos de instrucción como, por ejemplo, CREATE DATABASE, se aplican a la instrucción en sí y no a un objeto específico definido en la base de datos. Los permisos de instrucción son: 

BACKUP DATABASE



BACKUP LOG



CREATE DATABASE



CREATE DEFAULT



CREATE FUNCTION



CREATE PROCEDURE



CREATE RULE



CREATE TABLE



CREATE VIEW

Permisos implícitos Los permisos implícitos controlan las actividades que sólo pueden realizar los miembros de las funciones de sistema predefinidas o los propietarios de objetos de base de datos. Por ejemplo, un miembro de la función fija de servidor sysadmin hereda automáticamente todos los permisos para realizar cualquier actividad o ver cualquier elemento de la instalación de SQL Server. Los propietarios de objetos de base de datos también tienen permisos implícitos que les permiten realizar todas las actividades con los objetos que les pertenecen. Por ejemplo, si un usuario es propietario de una tabla, puede ver, agregar o eliminar datos en ella, modificar la definición de la tabla o controlar sus permisos para permitir que otros usuarios trabajen con ella. 4.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

4.3.3.2.

MATERIAL DE APOYO

4.3.4. ACTIVIDADES DE APRENDIZAJE 4.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A19-T5 Concesion y Renovación de privilegios. 4.3.4.1.1. INSTRUCCIONES El usuario general creado anteriormente (el cual solo podia consultar e insertar información), le agregamos el privilegio de ppoder modificar información. Creamos un tercer usuario el cual se llama supervisor el cual solo puede observar la información. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Tres usuarios en la base de datos Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Individual 4.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Concesion y Renovación de privilegios.

DESARROLLO Checar que efectivamente los derechos o privilegios de los usuarios hayan sido alterados Total

4.3.5. RESULTADO DE APRENDIZAJE

PONDERACIÓN 5 puntos 5 Puntos

Saber crear usuarios y poder renovar privilegios asi como quitarlos y agregar nuevos. 4.3.6. BIBLIOGRAFÍA Ayuda de sQL Server 2000 4.3.7. DOCUMENTOS SQL Server 7.0

4.4. SEGUIMIENTO DE AUDITORIA 4.4.1. OBJETIVO DE APRENDIZAJE Saber cuales son los mecanismos de suguridad que ofracen los manejadores de basas de datos en este caso SQL Server 2000 4.4.2. RECURSO TIEMPO DEL TEMA 2 horas 4.4.3. DESARROLLO

AUDITORÍA DE LA ACTIVIDAD DE SQL SERVER Microsoft® SQL Server™ 2000 proporciona la auditoría como una forma de trazar y registrar la actividad que ha tenido lugar en cada instancia de SQL Server, por ejemplo, inicios de sesión correctos o incorrectos. SQL Server 2000 también dispone de una interfaz, Analizador de SQL, para administrar los registros de auditoría. Sólo los miembros de la función fija de seguridad sysadmin pueden habilitar o modificar la auditoría, y toda modificación es un suceso auditable. Existen dos tipos de auditoría: 

la auditoría, que proporciona cierto nivel de auditoría, pero no requiere el mismo número de directivas que la auditoría C2.



la auditoría C25, que requiere que se sigan directivas de seguridad muy específicas

Ambos tipos de auditoría se pueden realizar utilizando el Analizador de SQL.

La auditoría C2 es necesaria si se está ejecutando un sistema certificado C2. Un sistema certificado C2 cumple con

un estándar gubernamental que define el nivel de seguridad. Para que Microsoft® SQL Server™ tenga la certificación C2, debe configurarlo en la configuración C2 evaluada.

USAR EL ANALIZADOR DE SQL El Analizador de SQL proporciona la interfaz de usuario para la auditoría de sucesos. Existen varias categorías de sucesos que se pueden auditar con el Analizador de SQL, por ejemplo: 

la actividad del usuario final (todos los comandos de SQL, cierres e inicios de sesión, habilitación de las funciones de aplicación)



la actividad de DBA (DDL distintos de conceder, revocar, denegar y los sucesos de seguridad, y la configuración (base de datos o servidor)



los sucesos de seguridad (conceder, revocar o denegar, agregar, quitar o configurar función o usuario de inicio de sesión)



los sucesos de herramientas (comandos de copia de seguridad, restaurar, inserción masiva, BCP, DBCC)



los sucesos del servidor (cerrar, pausa, inicio)



los sucesos de auditoría (agregar, modificar o detener auditoría)



Categoría de sucesos Auditoría de seguridad

Utilice la categoría de sucesos Auditoría de seguridad para supervisar la actividad de auditoría.

Se puede auditar los siguientes aspectos de SQL Server mediante el Analizador de SQL: 

fecha y hora del suceso



usuario responsable de que ocurriera el suceso



tipo de suceso



éxito o fracaso del suceso



el origen de la solicitud (por ejemplo, el nombre del equipo con Microsoft Windows NT® 4.0)



el nombre del objeto al que se obtuvo acceso



el texto de la instrucción SQL (contraseñas sustituidas por ****)



Si es un miembro de la función fija de servidor sysadmin o securityadmin

restablece

propia

contraseña

mediante

sp_password con los tres argumentos especificados ('old_password', 'new_password', 'login'), el registro de auditoría reflejará que se ha cambiado alguna contraseña. La auditoría puede tener consecuencias importantes para el rendimiento. Si todos los contadores de auditoría están activados, las repercusiones sobre el rendimiento pueden ser importantes. Es necesario evaluar cuántos sucesos es necesario auditar en comparación con las consecuencias que habrá sobre el rendimiento. El análisis de la auditoría puede llevar tiempo, por lo que se recomienda ejecutar la actividad de auditoría en un servidor distinto del servidor de producción. Nota Si se inicia SQL Server con el indicador –f, no se podrá ejecutar la auditoría. SUPERVISAR CON EL ANALIZADOR DE SQL El Analizador de SQL es una herramienta gráfica que permite a los administradores del sistema supervisar sucesos de una instancia de Microsoft®

SQL Server™. Puede capturar y guardar datos acerca de cada suceso en un archivo o en una tabla de SQL Server para analizarlos posteriormente. Por ejemplo, puede supervisar un entorno de producción para ver qué procedimientos empeoran el rendimiento al ejecutarse demasiado lentamente. Utilice el Analizador de SQL para supervisar únicamente los sucesos en los que está interesado. Si las trazas son demasiado grandes, puede filtrarlas a partir de la información que desea, de forma que sólo se recopile un subconjunto de los datos del suceso. Si se supervisan demasiados sucesos, aumentará la sobrecarga del servidor y el proceso de supervisión, y podría hacer que el archivo o la tabla de traza crezcan demasiado, especialmente cuando el proceso de supervisión se realiza durante un período prolongado de tiempo. Cuando haya trazado los sucesos, el Analizador de SQL permite reproducir los sucesos capturados en una instancia de SQL Server, volviendo a ejecutar así los sucesos guardados tal y como se produjeron originalmente. Utilice el Analizador de SQL para: 

Supervisar el rendimiento de una instancia de SQL Server.



Depurar procedimientos almacenados e instrucciones Transact-SQL.



Identificar consultas de ejecución lenta.



Probar procedimientos almacenados e instrucciones SQL en la fase de desarrollo de un proyecto mediante la ejecución paso a paso de las instrucciones para confirmar que el código funciona como se esperaba.



Solucionar problemas de SQL Server mediante la captura de sucesos en un sistema de producción y su reproducción en un sistema de prueba. Esto es útil para propósitos de pruebas o depuración, y permite a los usuarios seguir utilizando el sistema de producción sin interferencias.



Auditar y revisar la actividad producida en una instancia de SQL Server. Esto permite a los administradores de seguridad revisar los sucesos de auditoría, incluidos el éxito o el error de un intento de inicio de sesión y problemas de permisos al tener acceso a instrucciones u objetos.

El Analizador de SQL proporciona una interfaz gráfica de usuario a un conjunto de procedimientos almacenados, que se puede utilizar para supervisar una instancia de SQL Server. Por ejemplo, puede crear su propia aplicación que utilice procedimientos almacenados del Analizador de SQL para supervisar SQL Server. Debe tener al menos 10 megabytes (MB) de espacio libre para ejecutar el Analizador de SQL. Si se redujera la cantidad de espacio libre a menos de 10 MB mientras se utiliza el Analizador de SQL, se detendrán todas las funciones del Analizador de SQL. INICIAR EL ANALIZADOR DE SQL El Analizador de SQL se inicia desde el menú Inicio de Microsoft® Windows NT® 4.0, Microsoft Windows® 2000 o Microsoft Windows 98, o desde el Administrador corporativo de SQL Server. En el modo de Autenticación de Windows, la cuenta de usuario que se ejecuta en el Analizador de SQL debe conceder permiso para conectar a una instancia de SQL Server. También se debe conceder permisos a la cuenta de inicio de sesión para ejecutar procedimientos almacenados del Analizador de SQL

PARA INICIAR EL ANALIZADOR DE SQL Cómo iniciar el Analizador de SQL (Administrador corporativo)

Para iniciar el Analizador de SQL 1. En el menú Inicio, seleccione Programas, Microsoft SQL Server y, a continuación, haga clic en Administrador corporativo. 2. En el menú Herramientas, haga clic en Analizador de SQL.

4.4.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

4.4.3.2.

MATERIAL DE APOYO

4.4.4. ACTIVIDADES DE APRENDIZAJE 4.4.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A20-T6 Configurar SQL Server para poder supervisar los sucesos.

4.4.4.1.1. INSTRUCCIONES Configurar SQL Server para que pueda llevar un registro de todos los movimientos que los usuarios realicen. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Reporte de eventos en SQL Server 2000 Fecha inicio: Fecha entrega: Forma de entrega: Documento impreso del reporte Tipo de Actividad: Equipo (3 gentes) 4.4.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO Checar el reporte impreso que se entrega para verificar que Configurar SQL Server para efectivamente este poder supervisar los sucesos. configurado el manejador de base de datos. Total

4.4.4.2.

PONDERACIÓN

5 puntos

5 Puntos

ACTIVIDAD DE APRENDIZAJE 2

A21-ER4 Examen Rápido de los temas 4.3 y 4.4 4.4.4.2.1. INSTRUCCIONES Formaular 5 preguntas de los temas mencionados y dictárselas a los alumnos. g) h) i) j) k) l)

Valor actividad: Requisito Producto esperado: Preguntas contestadas Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 4.4.4.2.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD Examen Rápido

DESARROLLO Preguntas contestadas Total

PONDERACIÓN Requisito Requisito

4.4.5. RESULTADO DE APRENDIZAJE Poder auditar los mivimientos y operacines que los usuarios realicen, para poder determinar la razon en muchos casos de fallas en el sistema. 4.4.6. BIBLIOGRAFÍA Ayuda de SQL Server 2000 4.4.7. DOCUMENTOS Manual SQL Server 2000 Standard final

UNIDAD TEMATICA 5. BASES DE DATOS DISTRIBUIDAS

En un sistema de base distribuido, los datos almacenan en varios computadores. Los computadores de un sistema distribuido se comunican entre si a través de diversos medios de comunicación, tales como cables de alta velocidad a líneas telefónicas. No comparten la memoria principal ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño y función. Pueden incluir microcomputadoras y sistemas de computadores grandes de aplicación general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos, computadores, dependiendo en el contexto donde se mencionen. Nosotros utilizamos normalmente el termino localidad para hacer hincapié en el distribución física de estos sistemas.

Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada una de las cuales puede participar en la ejecución de transacciones que accedan a datos de una o varias localidades. La diferencia principal entre los sistemas de base de datos centralizados y distribuidos es que, en los primeros, los datos residen en una sola localidad, mientras que, en los últimos, se encuentran en varias localidades.6

5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES 5.1.1. OBJETIVO DE APRENDIZAJE Identificar las características de un sistema de base de datos dentro de una organización específicamente funciones y ventajas. 5.1.2. RECURSOTIEMPO DEL TEMA 2 horas 5.1.3. DESARROLLO

ESTRUCTURA DE BASES DE DATOS DISTRIBUIDAS

FUNDAMENTOS DE BASES DE DATOS, Segunda Edición, Henry F. Korth, Abraham Silberschatz Pag. 507

un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las cuales mantienen un sistema de base de datos local. Cada localidad puede procesar transacciones locales, es decir, aquellas que solo acceden a datos que residen en esa localidad. Además, una localidad puede participar en la ejecución de transacciones globales, es decir, aquellas que acceden a datos de varias localidades. La ejecución de transacciones globales requiere comunicación entre las localidades. Las localidades en el sistema conectarse físicamente de diversas formas. Las distintas configuraciones se representan por medio de grafos cuyos nodos corresponden a las localides. Una arista del modo A al nodo B corresponde a una conexión directa entre las dos localidades. En la figura 5.1.1 se ilustra algunas de las configuraciones más comunes. Las diferencias principales entre estas configuraciones son: 

Coste de instalación. El coste conecta físicamente las localidades del sistema.



Coste de comunicación. El coste en tiempo y dinero que implica enviar un mensaje desde la localidad A a la B.



Fiabilidad. La frecuencia con que falla una línea de comunicación o una localidad.



Disponibilidad. La posibilidad de acceder a información a pesas de fallos en algunos localidades o líneas de comunicación .

Como se verá, estas diferencias juegan un papel importante en la elección del mecanismo adecuado para manejar la distribución de los datos. Las localidades de un sistema distribuido de bases de datos pueden estar dispersas de forma física, ya sea por un área geográfica extensa (como los Estados Unidos) o en un atea reducida (por ejemplo, un solo edificio ó varios edificios adyacentes). Una red de primer tipo se denomina red de larga distancia, mientras que las ultimas se conocen como redes de área local.

Figura 5.1.1: Configuración de Red

CONSIDERACIONES AL DISTRIBUIR LA BASE DE DATOS.

Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el procesamiento de las consultas. Sin embargo, estas ventajas vienen acompañadas de varias desventajas, como son mayores costes de desarrollo del software, mayor posibilidad de errores y el aumento en el coste extra del procesamiento. En esta sección se comentaran brevemente cada una de ellas.

VENTAJAS DE LA DISTRIBUCIÓN DE DATOS la principal ventaja de los sistemas distribuidos de base de datos es la capacidad de compartir y acceder a la información de una forma fiable y eficaz. Utilización compartida de los datos y distribución del control

Si varias localidades diferentes están conectadas entre si, entonces un usuario de una localidad pueden acceder a datos disponibles en otra localidad. Por ejemplo, en el sistema bancario distribuido que se describió en la sección 15.1, un usuario de una sucursal puede acceder a datos de otra. Si no se contara con esta facilidad, un usuario que quisiera transferir fondos de una sucursal a otra tendr8ia que recurrir a un mecanismo externo para realizar la transferencia. Este mecanismo externo seria, de hecho, una base de datos única centralizada.

La ventaja principal de compartir los datos por medio de la distribución es que cada localidad pueda controlar hasta cierto punto las datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de estas responsabilidades se delega al administrador de base de datos de cada localidad. Dependiendo del diseño del sistema distribuido, cada administrador local podrá tener un grado de autonomía diferente, que se conoce como autonomía local. La posibilidad de contar con autonomía local es en muchos casos una ventaja importante de las bases de datos distribuidas.

Fiabilidad y disponibilidad Si se produce un fallo en una localidad en un sistema distribuido, es posible que las demás localidades puedan seguir trabajando. En particular, si los datos se repiten en varias localidades, una transacción que requiere un dato especifico puede encontrarlo en más de una localidad. Así, el fallo de una localidad no implica necesariamente la desactivación del sistema. El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que falló. Por ultimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones. Aunque la recuperación de fallos es más compleja en sistemas distribuidos que en los centralizados, la capacidad que tiene el sistema para seguir trabajando, a pesar del fallo de una localidad, da como resultado una mayor disponibilidad. La disponibilidad es fundamental para los sistemas de base de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no puede tener acceso a la información, es posible que pierda clientes a favor de la competencia.

Agilización del procesamiento de consultas Si una consulta comprende datos de varias localidades, pueden ser posible dividir la consulta en varias subconsultas que

se ejecuten en paralelo en

distintas localidades. Se podrían usar algunas de las estrategias de

computación de intersección en paralelo de la sección 9.6. sin embargo, en un sistema distribuido no se comparte la memoria principal, así que no todas las estrategias de intersección para procesadores paralelos su pueden aplicar directamente a los sistemas distribuidos. En los casos en que hay repetición de los datos, el sistema puede pasar la consulta a las localidades más ligeras de carga.

DESVENTAJAS DE LA DISTRIBUCIÓN DE LOS DATOS

La desventaja principal de los sistemas distribuidos de base de datos es la mayor complejidad que se requiere para garantizar una coordinación adecuada entre localidades. El aumento de la complejidad se refleja en: 

Coste de desarrollo de software. Es más difícil estructurar un sistema de base de datos distribuidos y, por tanto, su coste es mayor.



Mayor posibilidad de errores. Puesto que las localidades del sistema distribuido operan en paralelo, es más difícil garantizar que los algoritmos

sean

correctos.

Existe

posibilidad

errores

extremadamente sutiles. 

Mayor tiempo extra de procesamiento. El intercambio de mensajes y los cálculos adicionales que se requieren para coordinar las localidades son una forma de tiempo extra que no existe en los sistemas centralizados.

Al escoger el diseño de una base de datos, el diseñador debe hacer un balance entre las ventajas y las desventajas de la distribución de los datos. Se verá que existen varios enfoques del diseño de bases de datos distribuidas que van desde diseños totalmente distribuidos hasta diseños que incluyen un alto grado de centralización.

DISEÑO DE BASES DE DATOS DISTRIBUIDAS

Los principios del diseño de base de datos que se explicaron en capítulos anteriores también se aplican a las bases de datos distribuidas. Esta sección

se dedicara a los factores del diseño que se aplican específicamente a las bases de datos distribuidas. Considérese una relación r que se va a almacenar en la base de datos. Hay varios factores que deben tomarse en cuenta al almacenar esta relación en la base de datos distribuida. Tres de ellos son: 

Repetición. El sistema mantiene varias copias idénticas de la relación. Cada copia se almacena en una localidad diferente, lo que resulta en una repetición de la información. La alternativa a la repetición es almacenar una sola copia de la relación r.



Fragmento. La relación se divide en varios fragmentos. Cada fragmento se almacena en una localidad diferente.

Repetición y fragmentación. Esta es una combinación de los dos conceptos antes mencionados. La relación se divide en varios fragmentos. El sistema mantiene varias copias idénticas de cada uno de los fragmentos. 5.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

5.1.3.2.

MATERIAL DE APOYO

5.1.4. ACTIVIDADES DE APRENDIZAJE 5.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A22-I2 Sistemas en organizaciones.

5.1.4.1.1. INSTRUCCIONES Realizar un cuestionario de 5 preguntas del tema visto. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Reporte de la investigación Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo (5 gentes) 5.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Sistemas en organizaciones

DESARROLLO Revisar documento que avale la investigación en los negocios de la region Total

PONDERACIÓN 5 puntos 5 Puntos

5.1.5. RESULTADO DE APRENDIZAJE Saber realmente cuales son los beneficios que los sistemas de información ofrecen a las empresas.

5.1.6. BIBLIOGRAFÍA FUNDAMENTOS DE BASES DE DATOS, Segunda Edición, Henry F. Korth, Abraham Silberschatz 5.1.7. DOCUMENTOS

5.2. MODELO GENERAL DE UN SGBD 5.2.1. OBJETIVO DE APRENDIZAJE Conocer de manera concreta cuales son las funciones y ventajas de Sistema de Gestion de Base de Datos (SGBD) 5.2.2. RECURSO TIEMPO DEL TEMA 1 hora 5.2.3. DESARROLLO

SGBD: Software que permite la creación y manipulación de bases de datos.7

Los SGBD permiten: Descripción unificada de los datos e independiente de las aplicaciones 

Independencia de las aplicaciones respecto a la representación física de los datos



Definición de vistas parciales de los datos para distintos usuarios



Gestión de la información



Integridad y seguridad de los datos

Objetivos de técnicas BD  Descripción unificada e independiente de los datos  Independencia de las aplicaciones 7

Funciones SGBD Definición de datos a varios niveles:  Esquema lógico  Esquema interno

http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf (03/Ago/05)

Componentes SGBD Lenguajes de definición de esquemas y traductores asociados.

 Definición de vistas parciales



Gestión de la información

Manipulación de los datos:  Consulta  Actualización

Lenguajes de manipulación y traductores asociados.

Gestión y administración de la base de datos

Herramientas para:  Reestructuración  Simulación  Estadísticas  Impresión

Integridad y seguridad de los datos

Esquemas externos

Control de:  Integridad semántica  Accesos concurrentes  Reconstrucción en caso  de fallo  Seguridad (privacidad)

Herramientas para:  Control integridad  Reconstrucción  Control seguridad

ESQUEMA DE ACCESO DEL SGBD A LOS DATOS

Esquema externo aplicación 1: CREATE VIEW Administrativo (dni, nombre, salario_men) AS SELECT dni, nombre, salario/14 FROM Empleado WHERE tipo=„AD‟

Esquema lógico:

Empleado(dni, nombre, dirección, salario, tipo) CP: {dni}

Esquema Interno: Fichero ordenado Empleado con índice primario sobre el campo dni en el camino h:/disco1/gerencia

Aplicación 1: accede a la información a través del esquema externo 1

SELECT nombre, salario_men FROM Administrativo WHERE dni = parámetro

SGBD: control del acceso y resolución de la operación pedida

SO: Manipulación de los controladores de los dispositivos de memoria secundaria

EJEMPLO Especificación Una pequeña inmobiliaria desea mantener información sobre los edificios cuya venta gestiona. Se quiere saber:

– De cada edificio, el código, la ubicación, el distrito, el propietario, el precio solicitado por éste y el agente encargado de la venta si ya está asignado. – De cada propietario, el código, nombre y teléfono. – De cada agente el DNI, el nombre, la comisión por cada venta, los años de antigüedad y el teléfono.

Las restricciones que deben cumplirse son las siguientes: – La comisión de un agente no puede exceder el 3% si su antigüedad es menor de 3 años. – No se quiere tener información de propietarios si no se tiene al menos un edificio para la venta.

Grupos de trabajo: – El personal de administración tiene acceso a toda la información comentada. – El jefe de la inmobiliaria sólo desea tener información referente a los edificios con precio solicitado superior a 5 millones. De cada uno desea el código, la ubicación, y el distrito. – El jefe es el único que puede modificar la información de los agentes.

Esquema Lógico (SQL) CREATE SCHEMA Inmobiliaria CREATE TABLE Edificios (Código d_cod PRIMARY KEY, Ubicación d_ubi NOT NULL, Distrito d_dis NOT NULL, Precio d_pre NOT NULL, Dni_age d_dni FOREIGN KEY REFERENCES Agente ON UPDATE CASCADE, ON DELETE NO ACTION Dueño d_cod NOT NULL, FOREIGN KEY(Dueño) REFERENCES Propietario (cod) ON UPDATE CASCADE ON DELETE CASCADE)

CREATE TABLE Propietarios (Cod d_cod PRIMARY KEY,

Nombre d_nom NOT NULL, Teléfono d_tel NOT NULL)

CREATE TABLE Agentes (Dni_age d_dni PRIMARY KEY, Comisión d_com, Años d_años NOT NULL, Tel d_tel NOT NULL, CHECK NOT (años < 3 AND comisión > 3))

CREATE ASSERTION no_propet_sin_edificios CHECK NOT EXISTS (SELECT * FROM Propietarios WHERE cod NOT IN (SELECT Dueño FROM Edificio))

Esquemas Externos (SQL) GRANT ALL ON Edificios TO PUBLIC; GRANT ALL ON Propietarios TO PUBLIC; GRANT SELECT ON Agentes TO PUBLIC; ESQUEMA EXTERNO DEL JEFE: CREATE VIEW más_de_5 AS SELECT código, ubicación, distrito FROM Edificios WHERE E.precio >= 5000000; GRANT ALL ON más_de_5 TO Jefe; GRANT ALL ON Agentes TO Jefe; + El resto de tablas del esquema lógico (excepto edificios) ESQUEMA EXTERNO DEL PERSONAL ADMINISTRACIÓN : Todas las tablas del esquema lógico

Esquema Físico Edificios : Fichero disperso por dni_age Índice B+ sobre (distrito + precio) Propietarios

Fichero disperso por cod Índice B+ sobre nombre Agentes Fichero desordenado (se suponen pocos agentes).

Proceso de Acceso

5.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

5.2.3.2.

MATERIAL DE APOYO

5.2.4. ACTIVIDADES DE APRENDIZAJE 5.2.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A23-ER5 Examen Rápido de SGBD.

5.2.4.1.1. INSTRUCCIONES Realizar un cuestionario de 5 preguntas del tema 5.2 y dictárselas a los alumnos para que las contesten. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Preguntas contestadas Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 5.2.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO

PONDERACIÓN

Examen Rápido de SGBD

Formular preguntas y responderlas, estas se deben de transmitir hacia asu compañeros Total

5 puntos 5 Puntos

5.2.5. RESULTADO DE APRENDIZAJE Reafirmar los conceptos básicos de un SGBD 5.2.6. BIBLIOGRAFÍA http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf 5.2.7. DOCUMENTOS

5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS. 5.3.1. OBJETIVO DE APRENDIZAJE Entender el mecanismo de las consultas distribuidas. 5.3.2. RECURSOTIEMPO DEL TEMA 7 horas 5.3.3. DESARROLLO

PROCESAMIENTO DISTRIBUIDO DE CONSULTAS En el caso de sistemas centralizados, el criterio principal para determinar el coste de una estrategia especifica en el numero de accesos al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son: 

El coste de transición de datos en la red.



El beneficio potencial que supondría en la ejecución el que varias localidades procesaran en paralelo partes de la consulta.

El coste relativo de la transferencia de datos de la red y la transferencia de datos entre la memoria y el disco varia en forma considerable, dependiendo del tipo de red y de la velocidad de los discos. Por tanto, en un caso general, no podemos tener en cuenta sólo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuado entre los dos.

Repetición y fragmentación Consideramos una consulta muy sencilla: “encontrar todas las tuplas de la relación deposito”. Aunque la consulta es muy simple, de hecho es trivial; su

procesamiento no es trivial, ya que es posible que la relación deposito esté fragmentada, repetida o las dos cosas. Si la relación deposito está repetida, es preciso decidir que copia se va a utilizar. Si ninguna de las copias esta fragmentada, se elige la copia que implica coste de transmisión más reducidos. Pero si una copia esta fragmentada, la elección no es tan sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la relación deposito. En tal caso, el numero de estrategias para este ejemplo sencillo puede ser grande. De hecho, la elección de una estrategias puede ser una tarea tan compleja como hacer una consulta arbitraria. La transparencia de la fragmentación implica que el usuario puede escribir una consulta como esta: σ

nombre – sucursal = “Hillside” (deposito)

Puesto que deposito está definido como deposito1

deposito2 la expresión que resulta del esquema de traducción

de nombre es: σ

nombre – sucursal = “Hillside”

deposito1

deposito2

La expresión que resulta es σ

nombre – sucursal = “Hillside” (deposito1)

nombre – sucursal = “Hillside”

(deposito2)

la cual incluye dos subexpresiones. La primera incluye solo deposito 1 y, por tanto, puede ser calculado en la localidad Valleyview. Existe aun una optimización que se puede hacer calculando σ

nombre – sucursal = “Hillside” (deposito1)

pues que deposito1 tiene solamente tuplas pertenecientes a la sucursal de Hillside, podemos eliminar la operación de selección. Calculando σ

nombre – sucursal = “Hillside” (deposito2)

podemos aplicar la definición del fragmento deposito2 para obtener σ

nombre – sucursal = “Hillside”

(σ

nombre – sucursal = “Hillside” (deposito))

Esta expresión es el conjunto vació, independientemente del contenido de la relación deposito. Así, nuestra estrategia final para la localidad Hillside consistirá en devolver deposito1 como resultado de la consulta.

Procesamiento de intersección simple

Considerar la expresión en álgebra relacional:

cliente |X| deposito |X| sucursal

Suponemos que ninguna de las tres relaciones estan repetidas o fragmentada y que cliente esta almacenada en la localidad Lc, deposito en la Ld y sucursal en la Lb. Sea LI la localidad donde se origino la consulta. El sistema debe producir el resultado en la localidad LI. Entre las posibles estrategias para procesar esta consulta se encuentra las siguientes: 

Enviar copias de las tres relaciones a la localidad LI.



Enviar una copia de la relación cliente a la localidad L d y calcular cliente |X| deposito de Lb. Enviar cliente |X| deposito de Ld a Lb, donde se calcula (cliente |X| deposito) |X| sucursal. El resultado de esta operación es enviado a LI.



Pueden elaborarse estrategias similares a la anterior al intercambiar los papeles de Lc, Ld, y Lb.

No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre los factores que deben tomarse en cuenta están la cantidad de datos que debe transmitirse, el

coste de transmitir un bloque de datos entre dos

localidades determinadas y la velocidad de procesamiento relativa en cada localidad. Considerar las dos primeras estrategias arriba mencionadas. Si se envía las tres relaciones a LI y existen índices para ellas, pueden ser necesario volver a crear estos índices en LI. Esto requiere tiempo extra de procesamiento y mas accesos al disco. Sin embargo, la segunda estrategia tiene la desventaja de que una relación potencialmente grande (cliente |X| deposito) debe transmitirse desde Ld a Lb. Esta relación repite los datos de domicilio de un cliente una vez por cada cuenta que tenga el cliente. Así, la segunda estrategia puede requerir la transmisión de un volumen de datos mayor que la primera estrategia.

Estrategias de intersección utilizando el paralelismo

Consideramos un producto de cuatro relaciones:

r1 |X| r2 |X| r3 |X| r4 donde la relación ri esta almacenada en la localidad Li. Suponemos que el resultado ha de presentarse en la localidad L1. existen, por supuesto, muchas estrategias que se pueden considerar. Por ejemplo, se puede enviar r 1 a L2 y calcular r1 |X| r2 en L2. Al mismo tiempo se puede enviar r3 a L4 y calcular r3 |X| r4 en L4. La localidad L2 puede enviar tuplas de (r1 |X| r2) a L1 conforme se vayan produciendo, en vez de esperar a que se calcule el producto completo. De forma similar, L4 puede enviar tuplas de (r3 |X| r4) a L1. Una vez que las tuplas de (r1 |X| r2) y (r3 |X| r4) lleguen a L1, esta localidad podrá empezar el calculo de (r1 |X| r2) |X| (r3 |X| r4) en paralelo con el calculo de (r1 |X| r2) en L2 y de (r3 |X| r4) en L4. Estrategia de semiinterseccion Suponer que deseamos calcular la expresión r1 |X| r2, donde r1 y r2 están almacenados en las localidades L1 y L2 respectivamente. Sean R1 y R2 los esquemas de r1 y r2. Suponer que queremos obtener el resultado en L 1. Si hay muchas tuplas de r2 que no interseccionan con ninguna de r1, entonces el envió de r2 a S1 requiere el envió de tuplas que no contribuyen al resultado. Es conveniente borrar tales tuplas antes de enviar los datos a L 1, particularmente si los costes de la red son muy elevados. Para hacerlo vemos la siguiente estrategia:

1. Calcular temp1

II R1

∩ R2

(r1) en L1.

2. Enviar temp1 de L1 a L2. 3. Calcular temp2

de L2 a L1.

4. Calcular r1 |X| temp2 en L1. Este es el resultado de r1 |X| r2. Antes de considerar que esta estrategia es eficiente, verificamos que obtenemos la respuesta correcta. En el paso 3, temp2 tiene el resultado de r2 |X| II R1

∩ R2

(r1). En el paso 5, calculamos:

r1 |X| r2 |X| II R1

∩ R2

(r1)

Puesto que el producto es conmutativo y asociativo, podemos volver a escribirlo como: (r1 |X| II R1 como r1 |X| II (R1

∩ R2)

∩ R2

(r1))|X| r2

(r1)= r1, la expresión anterior es, hecho, igual a r1 |X| r2.

La estrategia anterior es ventajosa particularmente cuando en el producto participan relativamente pocas tuplas de r2. Es probable que suceda esta situación si r1 es el resultado de una expresión de álgebra relacionan que contenga la selección. En tal caso, temp2 puede tener de una considerable, menos tuplas que r2. El ahorro de costes viene de tener que enviar solo temp2, en vez de todas las de r2, a L1. Al enviar temp1 a L2, se produce un coste adicional. Si una pequeña fracción de tuplas de r2 contribuye suficientemente al producto, el tiempo extra de enviar temp1será contrarrestado por el ahorro que se produce al enviar solo una fracción de tuplas en r2. Esta estrategia es conocida como una estrategia de semiproducto, después del operador de semiproducto, indicado por |X, de álgebra relacional. El semiproducto de r1 con r2, indicado por r1 |X| r2, es: IIR (r1 |X| r2) Así, r1 |X r2 selecciona las tuplas de r1 que contribuyeron a r1 |X| r2. en el paso 3 anterior, temp2 = r2 |X r1. La estrategia anterior puede ser ampliada a unas series de pasos de semiinterseción, para la intersección de varias relaciones. Se ha desarrollado una teoría muy amplia referente al uso de semiproductos para optimizar a las consultas. Las notas bibliograficas hacen referencia a partes de esa teoría.

RECUPERACIÓN EN SISTEMAS DISTRIBUIDOS Hemos definido una transacción como una unidad de programa cuya ejecución conserva la consistencia de una base de datos. Una transacción debe ejecutarse de forma atómica. Es decir, se ejecutan completamente todas las instrucciones de la transacción, o no se ejecuta ninguna. Además, en el caso

de ejecución concurrente, el efecto de ejecutar una transacción debe ser el mismo que si se ejecutara sola en el sistema.

Estructura del sistema Cuando se tiene un sistema de base de datos distribuidos, es cuando mas difícil garantizar la propiedad de atomicidad de una transacción. Esto se debe a que es posible que participen varias localidades en la ejecución de una transacción. El fallo de una de estas localidades o el fallo de la linea de comunicación entre ellas, puede dar como resultado un calculo erróneo. La función del gestor de transacción de un sistema de base de datos distribuido es asegurar que la ejecución de las distintas transacciones de un sistema distribuido conserve la atomicidad. Cada localidad cuenta con su propio gestor de transacciones local. Los distintos gestores de transacciones cooperan para ejecutar

las

transacciones

globales.

Para

comprender

como

puede

estructurarse un gestor de este tipo, definiremos un modelo abstracto para un sistema de transacciones. Cada localidad del sistema contiene dos subsistemas: 

Gestor de transacciones, cuya funcion es gestionar la ejecución de aquellas transacciones (o subtransacciones) que accedan a datos almacenados en esa localidad. Observamos que cada transacción puede ser bien una transacción local (es decir, que se ejecuta sólo en esa localidad), parte de una transacción global (es decir, que se ejecuta en varias localidades).



Coordinador de transacciones, cuya función es la de coordinar la ejecución de varias transacciones (tanto local como global) iniciadas en esa localidad.

La arquitectura general del sistema se ilustra en la siguiente Figura.

La estructura de un gestor de transaciones es similar en muchos aspectos a la que se utiliza en el caso de un sistema centralizado. Cada gestor de transacciones se encarga de: 

Mantener una bitácora por la recuperación.



Participar en un esquema de control de concurrencia apropiado para coordinar la ejecución en paralelo de las transacciones que se ejecuten en esa localidad.

Como veremos, los esquemas, tanto de recuperación como de concurrencia, deben modificarse para tomar en cuenta la distribuciones de transacciones. El subsistema coordinador de transacciones no se necesita en el sistema centralizado, ya que las transacciones tienen acceso a datos de una sola localidad. Como su nombre indica, un coordinador de transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para cada una de estas transacciones, el coordinador debe: 

Iniciar la ejecución de la transacción.



Dividir la transacción en varias subtransacciones, las cueles ha de distribuir en las localidades apropiadas para su ejecución.



Coordinar la terminación de la transacción, ya sea que quede ejecutada o abortada en todas las localidades.

Robustez Un sistema distribuido puede sufrir el mismo tipo de fallos que un sistema centralizado (por ejemplo, fallo de memoria, fallo del disco). Sin embargo, en una configuración distribuida es necesario prever otro tipo de fallos, como pueden ser: 

El fallo total de una localidad.



La interrupción de una línea de comunicación.



Perdida de mensajes.



Fragmentación de la red.

Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera de estos fallos, que reconfigure el sistema de manera que pueda

reanudarse el proceso y que se recupere una vez que haya sido reparado el procesador o ola línea de comunicación afectados. En general, no es posible distinguir entre la interrupción de una línea de comunicación, el fallo total de una localidad, la perdida de mensajes o la fragmentación de la red. Por lo general, es posible detectar que existe un fallo, pero resulta difícil identificar el tipo del que se trata. Por ejemplo, suponemos que la localidad L1 no se puede comunicar con la L2. Una posibilidad es que la L2 se encuentre fuera de servicio, pero también es factible que se haya interrumpido la línea de comunicación entre L1 y L2. Suponemos que la localidad L1 se da cuenta de que existe un fallo. En ese momento debe iniciar un procesamiento de reconfiguración del sistema que le permita continuar con sus operaciones normales. 

Sin en la localidad que esta fuera de servicio se almacena información repetida, debe actualizarse el catalogo de manera que las consultas no hagan referencia a la copia que se encuentra en dicha localidad.



Si, en el momento de presentarse el fallo existían transacciones activas en la localidad que quedo fuera de servicio, deben abortarse. Es conveniente abortar estas transacciones tan pronto como sea posible, ya que puede darse el caso de que hayan puesto bloqueos a información que se encuentra el localidades que siguen activas.



Si la localidad que quedo fuera de servicio en el distribuidor central de algún subsistema, es preciso “elegir” un nuevo distribuidor. Los distribuidores centrales pueden ser, por ejemplo, asignadores de nombres, coordinadores de concurrencia o detectores de bloqueo globales.

En general, no es posible distinguir entre los fallos en las líneas de comunicación de la red y de las localidades. Por tanto, el esquema de reconfiguracion que se adopte debe estar diseñado para que funcione correctamente aun cuando la red quede fragmentada. En particular es preciso evitar que se presenten las siguientes situaciones: 

Elección de dos o más distribuidores centrales en distintos fragmentos.



Actualización de un dato repetido en más de un fragmento de la red.

También es necesario tener cuidado al reintegrar al sistema una localidad o línea de comunicación separada. Cuando una localidad que quedo fuera de servicio se recupera, debe iniciar un procesamiento de actualización de sus tablas de sistema para que reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidad tenia copias de datos, debe obtener los valores actuales de todos ellos y asegurarse de recibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que es posible que se actualicen los datos que se están procesando mientras que el sistema se recupera. Una solución sencilla es suspender temporalmente todas las operaciones del sistema mientras la localidad que quedo fuera de servicio se reintegre a el. Los problemas que acarrea esta suspensión es la mayor parte de las aplicaciones no pueden aceptarse. Es preferible representar a las tareas de recuperación como una serie de transacciones. En este caso, el subsistema de control de concurrencia y el manejo de transacciones puede encargarse de realizar de manera fiable la reintegración de la localidad. Si se recupera una línea de comunicación interrumpida, es posible que se unan de nuevo dos fragmentos de la red. Dado que la fragmentación de una red limita las operaciones que pueden permitirse en algunas localidades, o en todas ellas, es conveniente enviar un mensaje a todas ellas informando sin dilatación que la línea se recuperó. En las redes en que no se permitá el envió de este tipo de mensaje puede utilizarse otros esquemas

PROTOCOLO DE COMPROMISO Para garantizar la atomicidad, es preciso que todas las localidades en las que haya ejecutado la transacción T coincidan en el resultado final de la ejecución. T debe quedar ejecutada o abortada en todas las localidades. Para garantizar esta propiedad, el coordinador de transacciones encargado de T debe ejecutar un protocolo den compromiso. Entre los mas comunes y mas ampliamente usados esta el compromiso de dos–fases. Otra alternativa es el protocolo de compromiso de tres–fases, el cual impide ciertas desventajas del compromiso de dos fases, pero añade complejidad y tiempo extra.

Compromiso de dos – fases sea T una transacción que se inicio en la localidad L i, y sea Ci el coordinador de transacciones de esa localidad. El protocolo de compromiso Cuando T una termina de ejecutarse, es decir, cuando todas las localidades en las que se ejecuto T informan a C1 que T llego a su termino, Ci inicia el protocolo de compromiso de dos – fases. 

Fase 1. C1 añade el registro <preparar T> a la bitácora y la graba en memoria estable. Una vez hecho esto envía un mensaje de preparar T a todas las localidades en las que se ejecuto T, al recibir el mensaje, el gestor de transacciones de cada una de esas localidades determina si esta dispuesto a ejecutar la parte de T que le correspondió. Si no esta dispuesto, este añade un registro <no T> la bitácora y a continuación enviará un mensaje abortar T a C1. Si la respuesta es afirmativa agregara un registro < T lista > a la bitácora y grabara todos los registros de bitácora que corresponden a T en memoria estable. Una vez hecho esto, responderá a C1 con el mensaje T lista.



Fase 2. Una vez que todas las localidades hayan respondido al menaje preparar T en enviado

a Ci, o después de un intervalo de tiempo,

previamente especificado, Ci puede determinar si la transacción T puede ejecutarse o abortarse. Si Ci recibió el mensaje T lista de todas las localidades que participan, la transacción T puede ejecutarse. En caso contrario, la transacción T debe abortarse. Según haya sido el veredicto, se agregara un registro <ejecutar T> o <abortar T> a la bitácora y se grabara en memoria estable. En este punto, el destino de la transacción se habrá sallado. A continuación, el coordinador enviara un mensaje <ejecutar T> o <abortar T> a todas las localidades participantes. Al recibir este mensaje, cada una de las localidades lo registra en la bitácora. Una de las localidades en las que se ejecuto T puede abortar T incondicionalmente en cualquier momento antes de enviar el mensaje T lista al coordinador. De hecho, el mensaje T lista es una promesa que hace la localidad de cumplir con la orden del coordinador de ejecutar T o abortar T.

Una localidad solo puede hacer tal promesa si la información requerida esta ya en almacenamiento estable. En caso contrario, si la localidad se cayera después de enviar el mensaje T lista, no seria capaz de cumplir su promesa. El destino de una transacción esta sellado en el momento en que por lo menos una de las localidades responde aborto T, ya que se requiere unanimidad para ejecutar una transacción. Dado que la localidad coordinadora L i es una de las localidades en las que se ejecuta T, el coordinador puede decidir de forma unilateral abortar T. El veredicto final en lo que registra (ejecutar o abortar) en la bitácora y graba esta en la memoria estable. En algunas implementaciones del protocolo de compromiso de dos – fases, una localidad envía un mensaje de reconocimiento a T al coordinador al final de la segunda fase del protocolo. Una vez que el coordinador recibe este mensaje de todas las localidades, añade el registro <T completo> en la bitácora.

Manejo de fallos

A continuación veremos de manera detallada la forma en que el compromiso de dos – fases responde a los distintos tipos de fallos. 

Fallo de una localidad participante.

En el momento en que una

localidad participante Lk se recupera de un fallo, debe examinar su bitácora para determinar el destino de aquellas transacciones que se estaban ejecutado cuando se produjo el fallo. Sea T una de esas transacciones. Consideramos los siguientes casos: o La bitácora contiene un registro <ejecutar T>. En este caso, la localidad ejecuta rehacer (T). o La bitácora contiene un registro <abortar T>. En este caso, la localidad ejecuta deshacer (T). o La localidad contiene un registro < T lista >. En este caso, la localidad debe consultar con Ci, para determinar el destino de T. Si Ci esta activo, notificara a Lk ejecutara o aborto de T. A continuación, Lk ejecutara rehacer (T) o deshacer (T), según sea el caso. Si Ci esta inactivo, Lk debe interrogar a las demás localidades para intentar determinar el destino de T. Esto lo hará enviando un mensaje de consulta de estado de T a todas las demás localidades del sistema. Al recibir uno de estos

mensajes una localidad, deberá consultar su bitácora para ver si T se realizo allí y en caso de que así haya sido , si se ejecuto o se aborto. A continuación notificara dicho resultado a Lk. Si ninguna de las localidades cuenta con la información apropiada (es decir, si T se ejecuto o aborto), entonces Lk no podrá ejecutar ni abortar T. La decisión con respecto a T se pospondrá hasta que L k pueda obtener la información necesaria. De esta forma, Lk deberá seguir mandando el mensaje de consulta a las otras localidades de forma periódica hasta que alguna de las localidades que contienen la información requerida se recupere. Se puede hacer mención de que la localidad en la que reside Ci siempre tendrá la información requerida. o La bitácora no contiene registro de control (abortar, ejecutar, lista) referentes a T. Esto implica que Lk tuvo un fallo antes de responder al mensaje preparar T de Ci. Puesto que el fallo de Lk excluye el envió de esa respuesta, de acuerdo a nuestro algoritmo, Ci debe abortar T. En consecuencia, Lk debe ejecutar deshacer (T). 

Fallo del coordinador. Si el coordinador falla en la mitad de la ejecución del protocolo de compromiso de la transacción T, entonces las localidades participantes deben decidir de T. Veremos que en algunos casos las localidades participantes no pueden decidir si ejecutar o abortar T, y, por tanto, será necesario que estas localidades esperen a que se recupere el coordinador que fallo. o

Si una localidad activa contiene un registro < ejecutar T > en su bitácora, entonces T debe ser ejecutada.

o Si una localidad activa contiene un registro < abortar T > en su bitácora, entonces T debe ser abortada. o Si alguna localidad activa no contiene un registro < T lista> en su bitácora, entonces el coordinador que fallo Ci no puede haber decidido ejecutar T. Esto se debe a que una localidad que no tiene un registro < T lista > en su bitácora no puede haber enviado un mensaje de T lista a Ci. Sin embargo, el coordinador puede haber decidido abortar T, y no ejecutar T. Es preferible abortar T antes que esperar que Ci se recupere. o Si no ocurre ninguno de los casos anteriores, entonces todas las localidades activas deben tener en sus bitácoras un registro < T lista >,

y ningún registro de control adicional (tales como < abortar T > o < ejecutar t >). Puesto que el coordinador ha fallado, es imposible determinar hasta que el coordinador se recupere si se produjo una decisión, y si la hubo, cual fue. De esta forma, la localidad activa debe esperar a que Ci se recupere. Debido a que el destino de T continua en duda, T puede continuar reteniendo recursos del sistema. Por ejemplo, si se utiliza bloqueos, T puede mantener bloqueos sobre los datos en las localidades activas. Esta situación no es deseable puesto que puede pasar horas o días hasta que Ci este activo de nuevo. Durante este tiempo, otras transacciones pueden haber sido forzadas a esperar a T. Como resultado tenemos que los datos no estén disponibles no solo en la localidad del fallo (Ci), sino también en localidades activas. Cuando mayor es el tiempo que Ci este caído, mayor será el numero de datos que no estén disponibles. A esta situación se la denomina el problema de bloqueo debido a que T esta bloqueada, dependiendo de la recuperación del Ci de la localidad. 

Fallo de un alinea de comunicación. Cuando una línea de comunicación falla, todos los mensajes que estaban siendo enrutados a través de la línea no llegan a sus destinos intactos. Desde el punto de vista de las localidades conectadas a través de esa línea, parece que el fallo corresponde a las otras localidades. Por tanto, nuestro anterior esquema también se puede aplicar aquí.



Fragmentación de la red. Cuando se fragmenta la red, caben dos posibilidades. o El coordinador y todos sus participantes queden en un fragmento. En este caso el fallo no tendrá efecto sobre el protocolo de compromiso. o El coordinador y sus participantes quedan distribuidos en varios fragmentos. En este caso se perderán los mensajes entre la participación y el coordinador, situación que es equivalente a la interrupción de líneas de comunicación mencionadas anteriormente.

Compromiso de tres – fases El protocolo de compromiso de tres–fases están diseñado para impedir la posibilidad de bloqueo en un caso restringido de los fallos posibles. El protocolo requiere que: 

No puede ocurrir una fragmentación de la red.



Debe haber al menos una localidad funcionando en cualquier punto.



En cualquier punto, como máximo un numero K de participantes pueden caer simultáneamente (siendo K un parámetro que indica la resistencia del protocolo a fallos en localidades).

El protocolo alcanza esta propiedad de no – bloqueo añadiendo una fase extra, en la cual se toma una decisión preliminar sobre el destino de T. Como resultado de esta decisión, se pone en conocimiento de las localidades participantes cierta información que permite tomar una decisión a pesar del fallo del coordinador. El protocolo de compromiso

De la misma forma, sea T una transacción iniciada en la localidad L i y Ci el coordinador de transacciones en Li. 

Fase 1. esta fase es idéntica a las fase 1 del protocolo de compromiso de dos – fases.



Fase 2. si Ci recibe un mensaje abortar T de una localidad participante, o si Ci no recibe respuesta dentro de un intervalo previamente especificado de una localidad participante, entonces Ci decide abortar T. La decisión de abortar esta implementada de la misma forma que en el protocolo de compromiso de dos – fases. Si Ci recibe un mensaje T lista de

cada

localidad

participante,

tomara

decisión

preliminar

“preejecutar” T. La diferencia entre preejecutar y ejecutar radica en que T puede ser todavía abordar eventualmente. La decisión de preejecutar permite al coordinador informar a cada localidad participante que todas las localidades participantes están “listas”. Ci añade un registro < preejecutar T > a la bitácora y lo graba en un almacenamiento estable. De acuerdo a esto, Ci envía un mensaje preejecutar T a todas las localidades participantes. Cuando una localidad recibe un mensaje del

coordinador (ya sea abortar T o preejecutar T), lo registra en su bitácora, grabando esta información en almacenamiento estable, y envía un mensaje de reconocimiento a T al coordinador. 

Fase 3. Esta fase se ejecuta solo si la decisión tomada en la fase 2 fue de preejecutar. Después de que los mensajes preejecutar T se han enviado a todas las localidades participantes, el coordinador debe esperar hasta que reciba al menos un numero K de mensajes de reconocimiento a T. Siguiendo este proceso, el coordinador toma una decisión de compromiso. Añade un registro < ejecutar T > en su bitácora y la graba en un almacenamiento estable. De acuerdo a esto, C i envía un mensaje ejecutar T a todas las localidades participantes. Cuando una localidad recibe el mensaje, lo registra en su bitácora.

Tal y como en el protocolo de compromiso de dos – fases, una localidad en la que se haya ejecutado T puede abordar T incondicionalmente en cualquier momento, antes de enviar el mensaje T lista al coordinador. El mensaje T lista es, de hecho, una promesa hecha por la localidad para seguir la orden del coordinador de ejecutar T abortar T. En contraste con el protocolo de compromiso de dos – fases, en el que el coordinador puede incondicionalmente abortar T en cualquier momento antes de enviar el mensaje ejecutar T, el mensaje preejecutar T en el protocolo de compromiso de tres – fases, es una promesa hecha por el coordinador para seguir la orden del participante de ejecutar T.

Puesto que la fase 3 siempre induce a una decisión de compromiso, parece que no es muy útil. El papel de la tercera fase toma importancia por la forma en que el protocolo de tres – fases maneja los fallos. En algunas implementaciones del protocolo de compromiso de tres – fases, al recibir una localidad el mensaje ejecutar T, esta envía un mensaje de recibo t al coordinador. (Observamos el uso de recibo para destituirlo de los mensajes de reconocimiento usados en la fase2.) Cuando el coordinador recibe el mensaje de recibo T de todas las localidades, añade el registro < T completo > a la bitácora.

Transacciones distribuidas Dados el creciente interés y creciente utilización de los sistemas distribuidos, existe la necesidad de acceder y modificar datos distribuidos. Considere un sistema en el que se almacena la información de clientes en un servidor y la de productos en otro. Cuando un cliente adquiere un artículo, es necesario iniciar una transacción que registre el pedido en el servidor incluyendo la información de cliente y que, asimismo, decremente el nivel de stock en el servidor que almacene los datos de productos. Esta transacción debe ser una única transacción desde el punto de vista lógico, pero está físicamente distribuida entre dos servidores. Necesitamos una forma de asegurar que la transacción distribuida opere de la misma manera en que lo haría una transacción local y que respete las propiedades ACID (Propiedades de las transacciones)de cualquier transacción. El enfoque que utilizaremos estará basado sobre lo que se denomina protocolo de confirmación en dos fases.

PROTOCOLO DE CONFIRMACIÓN EN DOS FASES La implementación de transacciones distribuidas requiere un esfuerzo adicional de planificación y control. El servicio que proporciona la funcionalidad de confirmación en dos fases se basa en un servidor SQL Server conocido con el nombre de servidor de confirmación. Este servidor está a cargo de mantener el estado actual de la transacción y los otros servidores lo emplean para determinar el éxito o fracaso global de la misma. La transacción atraviesa los siguientes pasos: 1. La transacción da comienzo y se identifica a sí misma ante el servidor de confirmación. 2. Se emiten las instrucciones de modificación de datos en los servidores implicados. 3. El servidor de confirmación recopila información acerca de cada servidor y agrega a todos ellos a la transacción. 4. La transacción indica que desea fmalizar, emitiendo una instrucción PREPARE TRANSACTION. 5. Fase 1: durante la primera fase de la confirmación, todos los servidores comunican al servidor de confirmación que están listos para confirmar.

6. Fase 2: se emite una instrucción COMMIT TRANSACTION a todos los servidores, después de haber llegado a la conclusión de que todos ellos están preparados.

Si ocurre un error entre las dos fases, todos los servidores se comunican con el servidor de confirmación para ver si la transacción va a ser confiimada o cancelada. He aquí una lista de alguno de los errores que pueden tener lugar entre las fases 1 y 2: 

Uno de los servidores registrados se para. La solicitud de confirmación en dicho servidor falla, porque no se puede establecer comunicación con el servidor. Sin embargo, es posible que la solicitud para efectuar la confirmación haya tenido éxito. El servidor detenido utiliza probe para identificar qué acción debe tomar.



El servidor de confirmación deja de estar disponible. Es necesario deshacer la transacción. La aplicación ejecuta una instrucción ROLLBACK TRANSACTION para cada servidor registrado.



Se produce una detención tanto de un servidor registrado como del servidor de confirmación. La aplicación ejecuta una instrucción ROLLBACK TRANSACTION en todos los servidores que estén todavía activos. El servidor registrado que sufrió la detención se comunica con el servidor de confirmación, que no está al tanto de que la transacción se ha comRJetadq, Y que ordena al servidor registrado que deshaga la transacción.

Si uno de los servidores SQL registrados no puede comunicarse con el servidor de confirmación, se marca como sospechosa la base de datos correspondiente. Cuando el servidor de confirmación vuelve a estar «visible», el servidor afectado debe ser reiniciado para poder recuperar la base de datos y la transacción dudosa. Sólo se contacta una vez con el servidor de confirmación cuando tienen lugar dichos fallos; el servidor de confirmación devuelve el estado de la transacción, según la última actualización que la aplicación de control haya efectuado.

Afortunadamente, la parte dura de la tarea ha sido realizada por Microsoft, que ha implementado el servicio de confirmación en dos fases. Lo único que necesitamos es entender cómo interactuar con él para conseguir los resultados deseados. Podemos, para ello, hacer uso de las funciones de confirmación en dos fases disponibles en la biblioteca de e9lace dinámico DB-Library o en el servicio DTC de Microsoft.

EL COORDINADOR DE TRANSACCIONES DISTRIBUIDAS (MS DTC)

El Coordinador de transacciones distribuidas de Microsoft (DTC, Distributed Transaction Coordinator) se instala junto con SQL Server y el Agente SQL. Pueden ejecutar" se varios servicios DTC dentro de una red; si se desea, puede ejecutarse uno por cada servidor SQL Server. Se puede controlar qué servidor DTC emplear desde el Panel de control del cliente. Haciendo uso de múltiples servidores DTC, puede distribuirse la carga de trabajo.

El servidor MS DTC es el servidor de confmnación para las transacciones distribuidas y hace uso de un archivo de registro para-almacenar el resultado de todas las transacciones que hayan utilizado sus servicios.

LA IMPORTANCIA DE MSDTC.lOG

No debe, bajo ninguna circunstancia, modifi¿arse o borrarse el archivo IMSDTC.lOG. Si se borra el archivo, el sistema no funcionará.

INSTALACIÓN Durante la instalación del servicio (que tiene lugar como parte de la instalación del servidor), las DLL y los archivos ejecutables del servidor DTC se copian al subdirectorio \BIRM del directorio raíz de SQL. El archivo de registro de DTC se instala en el directorio \DATA, bajo la raíz de SQL.

PRECAUCIÓN Antes de instalar un pJiquete de servicio o actualización, asegúrese de que se hayan resuelto todas las transacciones dudosas. Microsoft se reserva el

derecho de cambiar el formato del archivo de registro DTC entre una versión y otra.

Una vez iniciado el servicio DTC, puede realizarse una prueba simple para verificar que todo está funcionando como debe. Abra la ventana Estadísticas de la consola de administración MS DTC y observe el contador Actual/Activas mientras abre una ventana de consulta y ejecuta BEGIN DISTRIBUTED TRAN. Cada vez que el contador se incremente, emita una instrucción ROLLBACK; el contador debería volver a 0.

UTILIZACIÓN Afortunadamente, no necesitamos preocuparnos de los protocolos subyacentes ni de las funciones que se invocan para que tenga lugar una transacción distribuida. Como desarrolladores, basta con cambiar muy sutilmente nuestra forma de programar, utilizando BEGIN DISTRIBUTED TRAN en lugar de la instrucción más usual BEGIN TRAN. Al ejecutar BEGIN DISTRIBUTED TRAN, la transacción se registra ante el servidor MS DTC. Esta acción nos convierte en el origen de la transacción y nos asigna la responsabilidad de enviar las instrucciones COMMIT o ROLLBACK al DTC, que entonces se encargará de gestionar la terminación de la transacción en todos los servidores implicados. Los servidores SQL pueden registrarse en nuestra transacción de una de las siguientes maneras: 

Un procedimiento almacenado remoto se ejecuta sobre un servidor.



Proporcionamos un testigo de acoplamiento a nuestra transacción distribuida.



Se ejecuta una consulta distribuida.

En las versiones anteriores de SQL Server, la única forma de llevar a cabo transacciones distribuidas era utilizar procedimientos almacenados :remotos como éste:

USE pubs GO BEGIN DISTRIBUTED TRANSACTION UPDATE sales SET qty = qty + 10000 WHERE au_id = 'GAL-06-1269' EXECUTE remotesrv.pubs.update_sales_qty 'GAL-06-1269', 10000 COMMIT TRAN GO

NOTA Para que los procedimientos almacenados remotos se ejecuten siempre dentro del contexto de una transacción distribuida. Puede utilizarse la opción SET REMOTE ROC TRANSACTlONS ON. que se establece por separado para cada conexión, o puede configurarse esta opción globalmente para todo un servidor utilizando sp_configure 'remote proc trans', ´1´.

Cuando el origen de datos OLE DB de destino de una consulta distribuida admite

ItransactionLocal, la

transacción

eleva

automáticamente

transacción distribuida. Sin embargo, si el origen de datos no admite ItransactionLocal, sólo pueden efectuarse consultas; el origen de datos se considera como de sólo lectura.

NOTA Después de haber configurado servidores enlazados, pueden realizarse transacciones distribuidas sin estar restringidos a ejecutar solamente procedimientos almacenados remotos.

Solución de problemas Obviamente,

como

hemos

complicado

nuestra

transacción

hemos

involucrado más componentes (servidores, red, etc.), tarde o temprano se producirán problemas (confiamos en que más tarde que temprano).

La forma más sencilla de determinar si un servidor puede comunicarse con un servidor de confirmación consiste en abrir una ventana de consulta y ejecutar BEGIN DISTRIBUTED TRANSACTION. Si no puede encontrarse el servicio, se obtendrá un error, que informará de que el servicio no está disponible.

Si un servidor de confirmación está resultando ser poco fiable para ciertos clientes, quizás debido a problemas de red transitorios, puede instalarse la Herramienta de cliente de red DTC en dichos clientes e instalar el servicio DTC en un servidor más próximo. La Herramienta de cliente de red permite especifIcar un servicio DTC y un protocolo de red concretos para utilizarlos en las transacciones distribuidas. La consola de administración del DTC proporciona un completo conjunto de estadísticas e información sobre el servicio DTC que se está ejecutando en el servidor. Esta herramienta proporciona acceso a cinco áreas: 

General. Información de versión, nombre del coordinador y funciones para arrancar y detener el servicio DTC.



Transacciones. Las transacciones actualmente activas, junto con su estado. Desde

esta

ventana,

puede

también

resolverse

una

transacción, forzando su confirmación, abortándola o eliminandola. 

Rastreo. Esta área tiene información de registro del servicio DTC. La profundidad de la traza se fIja en la ficha Avanzado.



Estadísticas. Esta área muestra el número actual de transacciones activas y dudosas, junto con información histórica sobre el número total de transacciones confirmadas, anuladas, etc.



Avanzado. Desde esta fIcha, puede controlarse la profundidad de traza, la velocidad de actualización para la presentación de datos y el tamaño y ubicación del archivo de registro DTC.

La consola de administración del DTC es la herramienta básica de depuración de transacciones distribuidas.8

TRANSACCIONES DISTRIBUIDAS CON SQLSERVER (Ejemplo)

En algunas ocasiones es necesario realizar operaciones que afectan a más de un servidor. Hay casos en los que esto puede ser muy conveniente o simplemente ser necesario. Llegados a esta necesidad, no podemos dejar de

Microsoft SQL Server /, Sharon Bjeletich, Greg Mable, et al., PRENTICE HALL

plantearnos un montón de cuestiones, todas ellas complejas. Si tengo dos conexiones a mi base de datos y abro una transacción en la primera, ¿puedo compartirla con la segunda?, y si no puedo, ¿hay posibilidades de garantizar que o se realicen las dos o no se realice ninguna?. Esto nos lleva, simplificando bastante el problema, a que tendría mi aplicación que garantizar que va a poder validar la segunda transacción, antes de validar la primera. Esto resumido y simplificado es lo que podríamos denominar confirmación en dos pasos. No obstante no es nada sencillo desde el punto de vista técnico responder a esa pregunta. Microsoft Transaction Server, precisamente resuelve este problema, lo resuelve no ya a nivel de base de datos, sino a nivel de objetos, pero en nuestro caso no vamos a tratar (de momento) de MTS, sino que nos vamos a centrar en como Sql-Server resuelve el problema. En otro artículo, espero que a no mucho tardar, podremos hablar de COM+ y Visual Studio .NET, y como crear componentes transaccionales que nos permitan olvidarnos más de nuestra base de datos. Pasos previos. Antes de garantizar que vamos a poder realizar transacciones distribuidas, incluso antes de siquiera intentarlo necesitaremos dos servidores. Nos servirán también dos instancias (aunque el ejemplo está hecho y probado con dos servidores). En el caso del ejemplo, los dos servidores se llaman 'A8B8O2' Y 'Maricarmen' respectivamente. Sí , lo sé, ¿que nombre es A8xde?, pues la verdad es que no sé, metí el cd de Windows-Xp, le dí siguiente-siguiente, y no leí ni un mensaje, tampoco podía esperar mucho más. Podría cambiarlo, de hecho no se vería afectado mi Sql, ya que tengo Sql-server 2000, pero no lo voy a hacer, :-). Los dos servidores están físicamente conectados en red, en una red local. Para

comunicarlos

usado

los

procedimientos

almacenados

sp_addlinkedserver y sp_addlinkedsrvlogin, con el código que podéis ver a continuación :

sp_addlinkedserver @server = 'maricarmen'

, @srvproduct= 'SQLServer' , @provider = 'SQLOLEDB' , @datasrc = 'maricarmen' , @catalog = 'pruebas'

Con esto añado el servidor vinculado maricarmen, que es un Sql-server, y el catálogo inicial será pruebas, no es necesario ya que de todas formas voy a usar el nombre en formato completo 'Servidor.BaseDeDatos.Propietario.Tabla', pero bueno, todo sea por que el ejemplo quede más claro. Con el servidor vinculado, tengo que añadir un login, podría pedir que fuese con las mismas credenciales o no, en nuestro caso no. Así que añadimos un login a ese servidor vinculado mediante el siguiente código :

sp_addlinkedsrvlogin @rmtsrvname='maricarmen' , @useself ='False' , @rmtuser='sa' , @rmtpassword='javier'

Inmediatamente

después,

comprobamos

que

efectivamente

estamos

conectados y que la conexión funciona, para ello, nada mejor que ejecutar una consulta. Select * From maricarmen.pruebas.dbo.pruebas Además de esto hay que tener en cuenta: Para que se puedan ejecutar transacciones distribuidas debemos tener activados los servicios de MS DTC de ambos servidores, o el servidor remoto debe implementar la interfaz ItransacionLocal. Consulte los books on line para mayor y más detallada información. Podemos explicitar Begin Distributed Trans o simplemente anidarla dentro de una transacción local, el sistema abre una transacción distribuida en cualquier caso siempre que el parámetro de sp_configure 'remote proc trans' esté habilitado. Es conveniente que SET XACT_ABORT esté a ON. Este parámetro en mi opinión está mejor a off siempre, si no el sistema rechaza transacciones de

forma implícita y eso no me gusta, pero en este caso no tiene más remedio que ser así, ya que -entiendo yo- que si se hace un commit, y por ejemplo, se ha perdido la conexión con el servidor remoto, este commit no puede tener efecto, y lamentablemente habrá que rechazar toda la transacción. El coordinador de transacciones distribuidas es un servicio más de Sql-Server. Para activarlo basta con pulsar play ..

Manos a la obra por fín. Pues eso, ya estamos en disposición de probar que efectivamente funciona, que hay transacciones distribuidas y que se anulan tanto si hay rollback manual como si hay commit y éste no puede ser validado. USE pruebas GO SET xact_abort on GO BEGIN TRAN INSERT INTO maricarmen.pruebas.dbo.pruebas (texto) VALUES('hola') INSERT INTO pruebas (texto) VALUES ('adiós') EXEC sp_lock

El resultado de sp_lock es : 51 1 0 0 DB S GRANT 51 8 0 0 DB S GRANT 51 8 0 0 DB S GRANT 51 8 21575115 1 PAG 1:30 IX GRANT

51 8 21575115 1 KEY (03000d8f0ecc) X GRANT 51 8 21575115 0 TAB IX GRANT 51 1 85575343 0 TAB IS GRANT

select object_name(21575115) dá naturalmente pruebas - Ojo, en vuestro sistema el identificador será seguramente distintoEn el ordenador remoto, sp_who2 dice lo siguiente... 53 sleeping sa A8B8O2 . pruebas AWAITING COMMAND 1092 0 10/05 01:10:33 Microsoft SQL Server 53 54 RUNNABLE sa A8B8O2 . pruebas SELECT INTO 1432 9 10/05 01:13:12 Analizador de consultas SQL 54

sp_lock en maricarmen nos dice que es el id 53 el que tiene bloqueado el registro (el que acabamos de insertar), el 54, es la conexión desde el servidor principal para poder ejecutar sp_lock ... :-D

Por último nuestra prueba consistió en desenchufar físicamente el cable y hacer commit y el resultado fue :

Servidor: mensaje 8522, nivel 18, estado 1, línea 1 Transacción distribuida anulada por MSDTC. Es decir que se comportó de acuerdo a lo esperado9.

5.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

5.3.3.2.

MATERIAL DE APOYO

5.3.4. ACTIVIDADES DE APRENDIZAJE 5.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A24-EC11 Realizacion de una Base de Datos Distribuida. 5.3.4.1.1. INSTRUCCIONES Diseñar una Base de datos de 5 tablas cuando mucho y color en dos servidores un numero equitativo de tablas, enlazar los servidores e intentar 9

http://www.configuracionesintegrales.com/miguele/trdissqlserver.asp?articulo=149 (09-08-05)

hacer una consulta a una tabla que este en el servidor donde yo no este trabajando. a) b) c) d) e) f)

Valor actividad: 30 Puntos Producto esperado: Base da tos distribuida Fecha inicio: Fecha entrega: Forma de entrega: Base de datos. Tipo de Actividad: Equipo (5 gentes) 5.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Realizacion de una Base de Datos Distribuida

DESARROLLO Estructura de la base de datos Configuración de los servidores

PONDERACIÓN 5 puntos 5 puntos 10 puntos

Conexion de los servidores Pruebas a la base de datos Total

10 puntos 30 Puntos

5.3.5. RESULTADO DE APRENDIZAJE Verificar las ventajas que ofrece una Base de Datos Distribuida a diferencia de una Base de datos Relacional. 5.3.6. BIBLIOGRAFÍA http://www.configuracionesintegrales.com/miguele/trdissqlserver.asp?articulo=149 5.3.7. DOCUMENTOS

UNIDAD TEMATICA 6. TECNOLOGÍAS DE ACCESO A DATOS 6.1. ARQUITECTURAS MULTICAPA y XML 6.1.1. OBJETIVO DE APRENDIZAJE Entender el funcionamiento del lenguaje XML 6.1.2. RECURSO TIEMPO DEL TEMA 4 horas 6.1.3. DESARROLLO

QUE ES XML Introduccion

XML es un Lenguaje de Etiquetado Extensible muy simple, pero estricto que juega un papel fundamental en el intercambio de una gran variedad de datos. Es un lenguaje muy similar a HTML pero su función principal es describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la lectura de datos a través de diferentes aplicaciones.

Las tecnologías XML son un conjunto de módulos que ofrecen servicios útiles a las demandas más frecuentes por parte de los usuarios. XML sirve para estructurar, almacenar e intercambiar información.

Conceptos

Entre las tecnologías XML disponibles se pueden destacar:

XSL: Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar cómo debería estar estructurado el contenido, cómo debería ser diseñado el contenido de origen y cómo debería ser paginado en un medio de presentación como puede ser una ventana de un navegador Web o un dispositivo de mano, o un conjunto de páginas de un catálogo, informe o libro.

XPath: Lenguaje de Rutas XML, es un lenguaje para acceder a partes de un documento XML.

XLink: Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos en documentos XML para crear enlaces entre recursos XML.

XPointer: Lenguaje de Direccionamiento XML, es un lenguaje que permite el acceso a la estructura interna de un documento XML, esto es, a sus elementos, atributos y contenido.

XQL: Lenguaje de Consulta XML, es un lenguaje que facilita la extracción de datos desde documentos XML. Ofrece la posibilidad de realizar consultas flexibles para extraer datos de documentos XML en la Web.

Cómo funcionan

XSL funciona como un lenguaje avanzado para crear hojas de estilos. Es capaz de transformar, ordenar y filtrar datos XML, y darles formato basándolo en sus valores. XPath identifica partes de un documento XML concreto, como pueden ser sus atributos, elementos, etc. XLink por su lado, describe un camino estándar para añadir hipervínculos en un archivo XML. Es decir, es un mecanismo de vinculación a otros documentos XML.

Funciona de forma similar a un enlace en una página Web, es decir, funciona como lo haría <a href="">, sólo que a href es un enlace unidireccional. Sin embargo, XLink permite crear vínculos bidireccionales, lo que implica la posibilidad de moverse en dos direcciones. Esto facilita la obtención de información remota como recursos en lugar de simplemente como páginas Web. XPointer funciona como una sintaxis que apunta a ciertas partes de un documento XML, es como una extensión de XPath. Se utiliza para llegar a ciertas partes de un documento XML.

Primero, XLink permite establece el enlace con el recurso XML y luego es XPointer el que va a un punto específico del documento. Su funcionamiento es muy similar al de los identificadores de fragmentos en un documento HTML ya que se añade al final de una URI y después lo que hace es encontrar el lugar especificado en el documento XML.

Al ser XPointer una extensión de XPath, XPointer tiene todas las ventajas de XPath y además permite establecer un rango en un documento XML, es decir, con XPointer es posible establecer un punto final y un punto de inicio, lo que incluye todos los elementos XML dentro de esos dos puntos.

Finalmente, XQL, lenguaje de consultas, se basa en operadores de búsqueda de un modelo de datos para documentos XML que puede realizar consultas en infinidad de tipos de documentos como son documentos estructurados, colecciones de documentos, bases de datos, estructuras DOM, catálogos, etc.10

XML Y SQL SERVER 2000 Una de las prestaciones más esperadas de SQL 2000 ha sido el soporte para XML (eXtensible Markup Language o Lenguaje de marcas extensible). Paradójicamente, es una característica cuyo valor práctico e inmediato no acaba de estar claro. Por una parte, todo el mundo ha oído hablar de ese lenguaje tan especial que haría de puente entre el resto de los lenguajes y, por otra, la práctica totalidad de sistemas gestores de bases de datos relacionales proclaman soportar el estándar XML. Pero veamos, ¿cuándo, dónde y por qué habría que usar XML?

XML, el estándar de Internet para intercambio de información, fue diseñado para publicar tipos de datos independientemente de la plataforma empleada, permitiendo así la interoperabilidad y el comercio electrónico. En las páginas web, XML también separa el contenido de la presentación y, de este modo, permite un sistema estándar para definir e intercambiar datos entre aplicaciones y bases de datos. (En el artículo «XML: el último gran invento», publicado en exclusiva en esta sede web, hallará las ventajas de utilizar XML para separar la presentación de los contenidos).

Al tratarse de un lenguaje construido para la definición de otros lenguajes de marcas o códigos (markup languages), su primera ventaja proviene por la

http://www.netyweb.com/contenido.asp?vcon=33 (05-aGO-05)

aceptación de algún lenguaje definido mediante XML, o por la aceptación del propio estándar XML, y después por la proliferación de utilidades, herramientas e infraestructura que sin duda surgirán para soportar su utilización. Aunque XML ya dispone de algunos lenguajes definidos excelentes --como BizTalk, DSML (Directory Markup Language o Lenguaje de marcas de directorio) y SOAP (Simple Object Access Protocol o Protocolo de acceso a objetos simples)--, no es un lenguaje al alcance de cualquiera, especialmente de quienes están acostumbrados a desarrollar aplicaciones Windows de 32 bits con los productos más conocidos de Microsoft. Si hablamos de transferir datos a través de redes locales, la opción más lógica parecen ser las tablas de resultados ADO. Pero, ya metidos de lleno en la era Internet, pocas son las organizaciones que desean aislarse del resto del mundo. E incluso dentro de una misma organización, empieza a ser raro encontrar un entorno puro (no híbrido), con tipos de servidores, plataformas o lenguajes únicos.

Si bien SQL Server 2000 es la primera versión de SQL Server que soporta XML, las primeras entregas de tecnología XML desarrolladas por Microsoft ya podían ejecutarse bajo las versiones 7.0 y 6.5 (entregas que pueden descargarse

desde

sede

web

http://msdn.microsoft.com/workshop/xml/articles/xmlsql/).

de Otra

Microsoft manera

proporcionar soporte para XML bajo SQL Server 7.0, 6.x y 4.2 consiste en escribir procedimientos almacenados ampliados y estándares, aunque estos últimos podrían menguar considerablemente el rendimiento si se están manipulando grandes tablas de resultados con estructuras complejas. Por otro lado, algunas funciones de SQL Server 7.0, como la búsqueda de textos completos, son capaces de almacenar el código XML como texto. La pregunta obvia es: ¿qué otras prestaciones aporta SQL Server 2000 para que oficialmente se declare compatible con XML?

Tradicionalmente, desde una base de datos se podían solicitar dos clases de XML: XML estático almacenado dentro de la base de datos y XML dinámico generado a partir de los datos contenidos en la base de datos. Ya la primera versión de SQL Server era capaz de utilizarse como repositorio de XML y los

programadores han utilizado ampliamente las versiones anteriores a SQL Server 2000 para crear aplicaciones que generan XML. Pero ahora, SQL Server 2000 soporta un nuevo tipo de datos denominado XML que permite almacenar XML en la base de datos, de forma nativa. Disponer de un tipo de datos nativo XML es uno de los criterios que hace de SQL Server 2000 un producto compatible con XML. Pero, además, SQL Server 2000 también introduce: · URL (Universal Resource Locator o Localizador de recursos universal) que permiten

acceder

SQL

Server

través

del

protocolo

http,

· la cláusula FOR XML dentro de la sentencia SELECT, pudiendo así recuperar resultados en formato XML, 

procedimientos almacenados del sistema para la manipulación de datos XML,



operaciones por lotes basadas en XML (grams) de actualización para



operaciones por lotes



y extensiones proveedoras de SQL Server OLE DB para XML.

A continuación, examinaremos de cerca estas mejoras introducidas por el XML de SQL Server 2000 y veremos un ejemplo de cómo compatibilizar sus sistemas para extraer datos en formato XML desde su SQL Server 2000, formateando dichos datos a su medida para utilizarlos después en sus aplicaciones. ACCESO A TRAVÉS DE HTTP SQL Server 2000 permite introducir una sentencia SQL en el campo Dirección de IE 5.0 (Internet Explorer 5.0 de Microsoft) y recuperar registros en formato XML. La siguiente consulta pseudo URL muestra los diversos componentes de una consulta del tipo mencionado: http://<SERVIDOR WEB>/ <DirectorioVirtual> ?sql=<CONSULTA SQL CODIFICADA>+FOR+XML+RAW

En primer lugar, la consulta utiliza el protocolo HTTP, lo cual permite utilizar cualquier tipo de software cliente existente o que usted mismo pueda crear. A continuación, la consulta dirige su petición al servidor web, IIS (Internet Information Server, de Microsoft), a través de una raíz virtual ubicada en el servidor IIS y que debe configurarse previamente para que pueda utilizar las extensiones XML de SQL Server. En tercer lugar, la consulta pide los datos deseados. Por lo general, cuando se solicitan datos desde un servidor web, suele utilizarse un formulario HTML con uno de los dos métodos típicos: GET o POST. Con GET, los datos del formulario contenido en el cliente se transfieren hasta el servidor como pares nombre/valor añadidos al final de la URL. Este mecanismo está sujeto a inconvenientes harto conocidos, entre los que se cuentan la limitación de longitud para la URL y ciertos fallos de seguridad. El método preferido en el desarrollo de aplicaciones es POST, ya que los pares nombre/valor contenidos en el formulario se almacenan en el cuerpo de la solicitud HTTP. A pesar de lo dicho, los ejemplos de este artículo utilizarán el método GET para enviar consultas a la base de datos, ya que, de este modo, usted podrá visualizar la cadena que conforma la solicitud de datos. Otra de las nuevas posibilidades consiste en utilizar sentencias SQL o procedimientos almacenados para acceder a los datos en formato XML. O bien ejecutar una plantilla XML, es decir, un documento XML que contiene una o más consultas válidas, sentencias u operaciones por lotes basadas en XML (grams) actualizadas. Las plantillas suelen tener la siguiente forma: <sql:query xmlns:sql="urn:schemas-microsoft-com:xml-sql" name1=‟valor1‟ name2=‟valor2‟> sentencia(s) sql </sql:query> La invocación de plantillas se realiza incluyéndolas en la petición GET o POST o llamándolas como archivos guardados en el directorio virtual del servidor web. Si sus consultas SQL suelen ser largas, IE no podrá mostrarlas en la barra de tareas y, por lo tanto, va a tener que teclearlas una y otra vez durante las pruebas que vaya ejecutando. Por esta razón, y otras muchas, resulta

conveniente almacenar las plantillas de consultas como archivos del directorio virtual e invocarlas del modo siguiente: http://miservidor/Northwind/miconsulta.xml La consulta miconsulta.xml solicita la información sobre el pedido de un cliente representado por un determinado identificador de cliente. La plantilla tiene el siguiente aspecto: ROOT xmlns:sql="urn:schemas-microsoft-com:xml-sql"> <sql:query IDCliente=‟PACOS‟> SELECT IDPedido, FechaPedido, FechaEntregaSolicitada, FechaEnvio FROM PEDIDOS WHERE IDCliente=? ORDER BY IDPedido XML RAW </sql:query></ROOT> Con las consultas-plantilla también pueden utilizarse parámetros. Esto permite combinar las consultas con el lenguaje XSL (Extensible Style Language o Lenguaje de estilo extensible) pudiendo así sustituir rápidamente el código de determinadas páginas ASP (Active Server Pages o Páginas de servidor activo) superdinámicas que realizan consultas contra bases de datos y formatean los registros resultantes como tablas HTML. El lenguaje XSL describe cómo formatear o mostrar los datos XML. El empleo de consultas-plantilla vinculadas a hojas de estilo XSL se acerca mucho al uso de los archivos HTX (Hypertext Markup

Language

Extension

Extensión

del

lenguaje

marcas

hipertextuales) y conectores IDC (Internet Database Conector o Conector de base de datos de Internet), posteriormente remplazados y mejorados por las páginas ASP. Si bien es verdad que las prestaciones XML de SQL Server, por sí solas, son incapaces de remplazar a las ASP, tampoco deja de ser cierto que XML permite recuperar los datos de forma más sencilla, aparte de resultar más rápido y fácil de implementar. En la Pantalla de Vista de un navegador con los registros devueltospor una consulta en formato XML se muestra el resultado de una consulta simple en la que se combinan una consulta-plantilla XML y una hoja de estilo XSL:

http://miservidor/Northwind/miconsulta.xml? IDCliente=pacos&xsl=ptab.xsl LA CLÁUSULA 'FOR XML' En SQL Server 2000, el empleo de la nueva cláusula FOR XML dentro de una sentencia SELECT genera documentos XML en lugar de un conjunto de filas. Esta

nueva

cláusula

puede

utilizarse

tanto

consultas

como

procedimientos almacenados. Los argumentos admitidos por FOR XML son XML mode, SchemaOptions y ELEMENTS. 

XML

Mode.

Las

tres

modalidades XML posibles son RAW, AUTO o EXPLICIT. Cada una de ellas especifica la forma del árbol XML resultante (en la Tabla 1, hallará una descripción de las tres modalidades). De las tres, la más útil es EXPLICIT, ya que permite crear un árbol XML (siempre que disponga de los datos imprescindibles) que, a su vez, proporciona los datos XML en el formato que usted prefiera.



SchemaOption. Esta opción instruye a la base de datos para que devuelva un esquema. SchemaOption puede devolver resultados DTD (Document Type Definition o Definición de tipo de documento) o XMLData. DTD devuelve el esquema y añade el elemento raíz a los resultados. XMLData, a su vez, devuelve el esquema pero no añade el elemento raíz. Si se especifica SchemaOption, la cláusula añadirá el esquema al principio del documento. En caso contrario, la base de datos no devolverá ningún esquema.



ELEMENTS. En caso de utilizar la opción ELEMENTS, la sentencia SELECT devolverá subelementos en las columnas. De otro modo, la sentencia correlaciona las columnas con los atributos XML. SQL Server 2000 únicamente soporta esta opción si la modalidad AUTO está activada.

Para especificar la modalidad XML en la cláusula FOR de la sentencia SELECT, deberá utilizar la sintaxis: FOR | [XML mode [, SchemaOption] [, ELEMENTS]]

PROCEDIMIENTOS ALMACENADOS DEL SISTEMA. SQL Server 2000 introduce seis nuevos procedimientos almacenados del sistema

para

manipular

sp_xml_fetchdocument,

los

datos

XML:

sp_xml_preparedocument,

sp_xml_removedocument,

sp_xml_insertfromxml,

xp_xml_removexml y sp_xml_fetchintoxml. Los procedimientos almacenados para la manipulación de datos XML sólo están disponibles por cada conexión que se establece. Esto no los hace especialmente útiles en aplicaciones

n-tier (multicapa), que

reservan

conexiones precisamente para asegurarse la escalabilidad. No obstante, los procedimientos ofrecen otro tipo de funcionalidad, ya que permiten almacenar (preparedocument)

recuperar

documentos

mediante

puntero

(fetchdocument). Complementariamente, también se puede eliminar un documento entero o algunos elementos del documento (removedocument, removexml), realizar inserciones en un documento XML desde una tabla o desde un documento XML a una tabla (insertfromxml, fetchintoxml). A pesar de que SQL Server 2000 ofrece un acceso muy completo desde el programa al lenguaje XML, algunos motores y extensiones de XML específicos, como interMedia, de Oracle8i, proporcionan un control de XML mucho más exhaustivo en tareas como, por ejemplo, consultar conjuntos de documentos XML o encontrar elementos o patrones específicos dentro de un documento. No obstante, SQL Server 2000 dispone de otros avances, como las funciones

definidas por el usuario, que podrían suplir esas carencias al permitir la redacción de código adicional adaptado a las necesidades de cada usuario. Pero aun con la funcionalidad actual, que le permite usar XML como medio de transporte para los datos relacionales, SQL Server 2000 no sólo cumple sobradamente los requisitos de una base de datos compatible con XML, sino que además destaca por su facilidad de uso. A partir de la base de datos de ejemplo Northwind, por ejemplo, podría construirse una aplicación web compatible con XML, diseñada para dar servicio a sus clientes, en unas pocas horas. GRAMS DE ACTUALIZACIÓN

Las grams de actualización son operaciones por lotes, basadas en XML, destinadas a insertar, suprimir y actualizar con el siguiente formato general: <sql:sync xmlns:sql="urn:schemas-microsoft-com:xml-sql"> <sql:before> <NOMBRE_TABLA [sql:id="valor"] col="valor" col="valor" ../> </sql:before> <sql:after> <NOMBRE_TABLA [sql:id="valor"] [sql:at-identity="valor"] col="valor col="valor" ../> </sql:after> </sql:sync>

Para llevar a cabo una operación INSERT, basta con utilizar un bloque sql:after. El bloque sql:before ejecuta una operación de DELETE y la de UPDATE se consigue empleando ambos bloques. Para que la transacción se produzca con éxito, la base de datos debe completar todas las operaciones dentro de un bloque sql:sync. OLE DB PARA XML Las nuevas extensiones de SQL Server 2000 proveedoras de OLE DB para XML --ICommandText::SetCommandText y ICommand::Execute-- permiten que los documentos XML se conviertan en auténticos mandatos, pudiendo ejecutarlos y recuperar los resultados en forma de corrientes (streams),

fácilmente manipulables en procesos posteriores. No resultaría difícil, por ejemplo, pasar el documento XML a DOM (Document Object Model o Modelo de objeto documento), una interfaz gracias a la cual los programas y guiones acceden –dinámicamente-- a los documentos y actualizan sus contenidos, estructura y estilo. SQL Server también soporta plantillas que se comportan como textos de mandatos; sólo hay que passar DBGUID_MSSQLXML como GUID (Globally Unique ID o ID único global) del mandato. El consumidor debe invocar el mandato ICommand:Execute para ejecutar plantillas XML. Para obtener un conjunto de resultados como documento XML, hay que establecer el «riid» a «Istream», consiguiendo de este modo que el proveedor devuelva los resultados como una corriente (stream). COMPATIBLE CON XML Lo primero que cualquier desarrollador de SQL Server desea conseguir con XML es transformar datos relacionales estándares a formatos XML. Aunque muchas empresas también puedan estar desarrollando nuevas aplicaciones, su primer interés se centrará en transformar al formato XML todos aquellos datos que ya estén disponibles. He aquí un ejemplo sencillo que debería ayudarle a ponerse en marcha. En primer lugar, configure un usuario e inicio de sesión para que la base de datos Northwind (incluida en la instalación del producto como ejemplo de base de datos) pueda utilizar todas las consultas relacionadas con XML. A continuación, entre en Programas, Microsoft SQL Server 2000 y Configurar soporte SQL para XML en IIS para llegar a la pantalla que le permitirá configurar las extensiones XML SQL Server de IIS. La Pantalla de Registro de las extensiones XML para SQL Server muestra esta configuración, con la mayoría de las opciones por omisión seleccionadas. Sin embargo, la casilla «Permitir consultas URL» está marcada para poder ejecutar consultas de este tipo. Como ya hemos mencionado, una consulta URL es una sentencia SQL inmersa en la URL de una máquina IIS configurada

para soportar el lenguaje XML de SQL Server. En consultas expresas de este tipo, la URL transfiere la sentencia SQL como un único parámetro. En este ejemplo, los parámetros de la conexión también se han configurado para utilizar una cuenta de SQL Server ya existente. (Observe que en todos los ejemplos de los libros en línea SQL Server --Books on line o BOL-- siempre se menciona a Nwind como raíz virtual; por lo tanto, deberá cambiar dicho valor por el nombre de su propia raíz virtual). En nuestro caso, durante la instalación de Windows 2000 hemos incluido tanto el servidor web como SQL Server 2000. Si decide instalar SQL Server 2000 en una máquina donde ya tenga instalado SQL Server 7.0, asegúrese de estar refiriéndose a la versión correcta de SQL Server. Veamos ahora un ejemplo de consulta URL : http://miservidor/Northwind?sql=SELECT+IDCliente, NombreContacto+FROM+Clientes+FOR+XML+RAW en la que miservidor es el nombre de la máquina que ejecuta el servidor IIS, /Northwind se refiere al directorio virtual configurado para el soporte XML y ?sql= es el único parámetro que describe la sentencia SQL. El resto de la consulta es la propia sentencia SQL codificada de modo que pueda pasarse de forma segura dentro de la dirección URL. SQL Server recibe la sentencia como: SELECT IDCliente, NombreContacto FROM Clientes FOR XML RAW La consulta solicita XML RAW (XML puro), lo que devuelve cada fila como un elemento independiente, con campos en cada fila listados como atributos separados de ese elemento. La Pantalla de Resultado de una consulta URL muestra un ejemplo del resultado de esta consulta.

En aplicaciones de múltiples capas (n-tier) que utilizan un número limitado de procedimientos almacenados con parámetros establecidos para controlar el acceso a los datos, el esquema de la base de datos puede modificarse, sin tener que cambiar ningún código cliente, con sólo editar los procedimientos almacenados relevantes. Tome como ejemplo el procedimiento almacenado de la base de datos Northwind mostrado en el Listado 1. Para que este procedimiento almacenado sea compatible con XML, deberá crearse un nuevo procedimiento almacenado con las modificaciones que se resaltan en el Listado 2. A continuación, tendrá que enviar al servidor SQL una solicitud “execute pedidosclientesxml ´GNZLZ´", introduciendo la siguiente URL en el campo Dirección de IE 5.0: http://miservidor/northwind?sql=execute+ pedidosclientesxml+GNZLZ Los resultados generados dentro de su navegador serán registros con formato XML, tal como se muestra en la Figura. Este ejemplo utiliza la convención T-SQL “execute <nombre_procedimiento_almacenado>" , pero las extensiones XML de SQL Server para IIS también soportan las llamadas a función mediante CALL, al estilo de ODBC. La consulta ilustrada demuestra cómo sacar partido de las

funcionalidades

más

básicas,

pero,

indudablemente, útiles. Si además introducimos hojas de estilo XSL, podremos generar documentos HTML con informes de seguimiento acerca de los pedidos de los clientes. Para conseguirlo, bastaría con combinar este documento XML con otro XSL. Las ventajas del método XML sobre las páginas ASP tradicionales son que, por una parte, XML ofrece más flexibilidad para generar presentaciones de datos

sencillas y, por otra, su implementaci贸n es mucho menos costosa. Si desea conocer todas sus posibilidades, espere a ver el alud de aplicaciones de ejemplo que nos llegar谩n con la nueva versi贸n de SQL Server 2000.

Vista de un navegador con los registros devueltospor una consulta en formato XML

Registro de las extensiones XML para SQL Server

Resultado de una consulta URL

RASCANDO EN LA SUPERFICIE Con XML pueden definirse tipos de documentos estándares que le permitirán compartir, transmitir y transformar la información de la empresa, así como facilitar la automatización de los procesos empresariales. En el recuadro «Enlaces XML» encontrará algunas direcciones web que le ayudarán a investigar más a fondo las posibilidades y ventajas del lenguaje XML. Este artículo apenas deja al descubierto una parte insignificante de todo lo que se puede hacer –y rápidamente-- con XML y SQL Server 2000. Un último ejemplo: hace poco creamos un servicio muy sencillo basado en el protocolo HTTP (un conjunto de URL con parámetros de consulta bien definidos que devolvían datos XML) en un asombroso tiempo récord de 10 minutos. Conseguimos tener la URL funcionando en menos tiempo del que tardamos en telefonear para averiguar si la especificación había llegado correctamente. Este

tipo de productividad mejorada hará de SQL Server 2000 la plataforma ideal para la entrega de formatos XML11 6.1.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

6.1.3.2.

MATERIAL DE APOYO

6.1.4. ACTIVIDADES DE APRENDIZAJE 6.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A25-ER6 Examen Rápido XML.

6.1.4.1.1. INSTRUCCIONES Formular 5 preguntas del tema y dictárselas a los alumnos para que se resuelvan. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Contestar preguntas de manera escrita Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Individual 6.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Examen Rápido XML

DESARROLLO Formular preguntas y dictárselas a los alumnos para que se resuelvan. Total

PONDERACIÓN 5 puntos 5 Puntos

6.1.5. RESULTADO DE APRENDIZAJE Entender claramente el lenguaje XML 6.1.6. BIBLIOGRAFÍA http://www.windowstimag.com/sqlmag/atrasados/01_sep00/articulos/XML_1.htm 6.1.7. DOCUMENTOS

6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y ASP. 6.2.1. OBJETIVO DE APRENDIZAJE Manejar una base de datos a traves de una de las tecnologías mencionas en el titulo del tema. 11

http://www.windowstimag.com/sqlmag/atrasados/01_sep00/articulos/XML_1.htm (9-08-05)

6.2.2. RECURSO TIEMPO DEL TEMA 12 horas 6.2.3. DESARROLLO

Aquí se describe las distintas interfaces de programación de aplicaciones (API) disponibles en SQL Server. El apéndice pretende proporcionar una breve panorámica de cada API, presentar las ventajas y desventajas relativas de cada una y explicar qué las interfaces juegan un papel importante en la estrategia de futuro de Microsoft.

Guías generales de selección de una interfaz

Como administrador de bases de datos, necesita conocer qué interfaces de programación hay disponibles para SQL Server. Por ejemplo, puede que se incorpore a un grupo de desarrolladores que estén trabajando en la construcción de un programa personalizado que utilice SQL Server como base de datos. En este tipo de entorno, puede que le pidan ayuda para decidir qué API es la más adecuada para el tipo de aplicación que esté siendo desarrollada. Incluso si usted mismo no escribe directamente código de programa utilizando una de las API de SQL Server, tiene que conocer cuáles hay disponibles y las ventajas y desventajas de cada una. También debe ser consciente de que cualquier producto de otras empresas escrito para SQL Server debe incluir el logotipo de Windows ó el de BackOffice.

El logotipo de Windows indica que los productos pueden

ejecutarse tanto en plataformas NT 4.0 como Windows 95/98, mientras que los productos compatibles con BackOffice se ejecutarán como servicios NT y permitirán inicios de sesión unificados y la utilización del protocolo TCP/lP, entre otras funciones. Consulte el sitio web de Microsoft, en la dirección http://www.microsoft.com/windows/thirdparty/winlogo/.

para

obtener

más

información sobre la compatibilidad con Windows, y consulte la dirección http://www.microsoft.com/backoffice/designed/,

para

información sobre la compatibilidad con BackOffice.

obtener

más

TABLA

D.1.

INTERFACES DE PROGRAMACIÓN DE SQL SERVER

API

Lenguaje

Estándar

Soporte OLAP

Características de SQL Server 7.0

ADO

VB, ve, VJ, VBS, JS

Emergente

Sí

La mayoría

OLE DB RDO ODBe DAO DB-Library VB-SQL oex SQL incrustado

ve VB,VJ Ve,VB VB,Ve VB,Ve VB

Emergente Actual Actual Actual Heredada Heredada

Sí No No No No No

Todas La mayoría Todas Limitadas Limitadas Limitadas

Heredada

Limitadas

La Tabla es un resumen de las distintas interfaces disponibles en SQL Server, en el que se indica bajo qué lenguajes de programación está disponible y si la API forma parte de la estrategia de futuro de Microsoft o forma parte del código heredado. VB = Visual Basic, VC = Visual C++, VJ = Visual J++, VBS = VBScript y JS = JavaScript

ADO Los objetos de datos ActiveX (ActiveX Data Objects, ADO) pueden considerarse como un envoltorio de OLE DB, que proporciona un modelo de objetos estructurado, fácil de programar y sencillo de utilizar: un conjunto de interfaces COM que proporcionan acceso a muchos orígenes de datos diferentes. Puede emplearse ADO para comunicarse con distintos orígenes de datos compatibles con OLE DB, y no sólo con SQL Server. Se recomienda utilizar ADO como API principal para acceder a datos desde aplicaciones de propósito general. Puesto que ADO está construido sobre la API OLE DB y es un modelo de objetos simplificado, reduce el tiempo de desarrollo y la curva de aprendizaje asociados con cualquier nueva Apl. Una aplicación ADO se comunica con un origen de datos OLE DB utilizando un proveedor OLE DB. Un proveedor OLE DB es una biblioteca de enlace dinámico que utiliza interfaces OLE DB para acceder a un origen de datos concreto. Pueden utilizarse dos tipos de proveedores OLE DB con SQL Server: 

SQLOLEDB. El proveedor OLE DB de SQL Server, que hace corresponder de manera directa las interfaces OLE DB a SQL Server.



MSDASQL. El proveedor OLE DB para ODBC, que hace corresponder las interfaces OLE DB con una API ODBC.

El proveedor OLE DB de SQL Server, que se suministra con éste, es el suministrador preferido para las aplicaciones ADO que accedan a SQL Server. Es una asignación directa de la interfaz a SQL Server, en lugar de un nivel colocado sobre una API preexistente, como es el caso de MSDASQL con ODBC.

OLE DB OLE DB es una API de bajo nivel basada en COM12 (Desde un punto de vista práctico, un objeto COM es básicamente una caja negra que nuestra aplicación puede usar para llevar a cabo una o más tareas) para acceder a datos de diversos orígenes de datos. OLE DB es el método preferido para desarrollar utilidades o aplicaciones SQL Server que requieran un máximo rendimiento. El proveedor OLE DB de SQL Server, SQLOLEDB, es un proveedor compatible con la versión 2.0 de OLE DB. Proporciona acceso directo al protocolo nativo de SQL Server, TDS (Tabular Data Stream, Flujo de Datos Tabulares). Sin embargo, esta potencia tiene un precio asociado: la complejidad. Requerirá más tiempo de desarrollo, tanto en términos de la curva de aprendizaje de la nueva API, como del tiempo requerido para escribir programas.

SQL-DMO y SQL Namespace SQL Distributed Management Objects (SQL-DMO, Objetos de Administración Distribuidos) es un conjunto de objetos COM que proporciona un modelo de objetos para la administración de la duplicación y las bases de datos SQL Server. Se implementa como un servidor en proceso de interfaz dual. Puede desarrollarse una aplicación SQL-DMO utilizando un control de automatización OLE, como el de Visual Basic, o desarrollando una aplicación basada en COM 12

El COM (Component Object Model ) es un estándar binario que define como se crean y destruyen los objetos y, lo

más importante, como interactúan entre ellos. La idea es que distintas aplicaciones con distintos códigos fuente puedan comunicarse entre ellas mediante procesos, siempre que dichas aplicaciones sigan el estándar COM. Normalmente se usa el COM para establecer fácilmente comunicaciones con otros procesos. http://www.etse.urv.es/EngInf/assig/ens4/2004/net4a.pdf (04/Ago/05)

mediante C++. SQL-DMO requiere el controlador ODBC de SQL Server, versión 3.70 o posterior, incluido en SQL Server 7.0. SQL Namespace, SQL-NS, es un conjunto de interfaces COM que permite a una aplicación mostrar los componentes de interfaz de usuario del Administrador corporativo. Esto permite a cualquier aplicación desarrollada en Visual Basic o Visual C++ mostrar cualquiera de los muchos asistentes, hojas de propiedades y cuadros de diálogo del Administrador corporativo. Utilizando los objetos SQL Namespace, cualquier des arrollador de aplicaciones puede aprovecharse de la funcionalidad ya incorporada en SQL Server. Por ejemplo, un desarrollador de aplicaciones que quiera que se puedan realizar copias de seguridad de las bases de datos SQL Server directamente desde su aplicación, puede utilizar objetos SQL Namespace para proporcionar esta capacidad, en lugar de escribir su propio código.

ODBC y RDO ODBC es la API estándar empleada para acceder a datos almacenados en bases de datos relacionales o ISAM. SQL Server incluye ODBC como una de sus API nativas para el desarrollo de aplicaciones escritas en Visual C++ y Visual Basic. Las aplicaciones que se comunican con SQL Server mediante ODBC requieren un mayor esfuerzo de desarrollo que otras API, porque se trata de una interfaz de bajo nivel. Al igual que ADO, RDO es un conjunto de objetos simplificados que proporciona acceso a bases de datos compatibles con ODBC. Requiere menos esfuerzo que ODBC, pero carece de la rapidez y grado de control disponibles cuando se utilizan llamadas a funciones nativas ODBC. Las aplicaciones escritas en Visual Basic y Visual J++ pueden utilizar RDO. Para el uso futuro de ODBC, Microsoft recomienda que todas las aplicaciones de nuevo desarrollo realicen la migración desde ODBC o RDO a OLE DB o ADO. OLE DB es la dirección futura para todas las API de acceso a datos, porque proporciona la posibilidad de consultar y extraer datos de orígenes tan diversos como SQL Server, Microsoft Access e incluso hojas de cálculo Microsoft Excel.

Interfaces heredadas: DB-Library, ODS y SQL incrustado

DB-Library es una API que consiste en un conjunto de funciones y macros en C. Un subconjunto de esta biblioteca está disponible para su utilización con Visual Basic. DBLibrary es la API original proporcionada con SQL Server y fue su API estándar hasta el advenimiento de ODBC y, ahora, de OLE DB.

PRECAUCIÓN DB-Library no ha sido mejorado con respecto a las capacidades disponibles en SQL Server 6.5. Aunque todas las aplicaciones basadas en DB-Library seguirán funcionando con SQL Server 7.0, no podrán acceder a las numerosas funciones nuevas que SQL Server 7.0 proporciona. Considere realizar la migración de sus aplicaciones DB-Library a alguna de las nuevas API, como ADO.

SQL incrustado para C permite a las aplicaciones incrustar instrucciones Transact-SQL en código fuente escrito en lenguaje C. Las aplicaciones que utilicen SQL incrustado para C necesitarán que se preprocese el código fuente mediante un precompilador. El precompilador de SQL incrustado convierte las instrucciones incrustadas Transact-SQL en llamadas de función que pueden ser procesadas por un compilador C. El compilador C generará un programa ejecutable a partir de los resultados preprocesados. SQL incrustado se considera una API heredada y Microsoft sugiere que sólo se utilice cuando una aplicación deba forzosamente mantener estándares ANSI SQL estrictos. Los Servicios abiertos de datos (ODS, Open Data Services) son una API basada en SQL Server, que puede ser utilizada para ampliar las capacidades que SQL Server incluye. La API consiste en un conjunto de funciones

macros

C/C++,

que

pueden

usarse

para

construir

procedimientos almacenados extendidos y aplicaciones de pasarela. Los procedimientos almacenados extendidos son bibliotecas de enlace dinámico que añaden funcionalidad mediante rutinas desarrolladas en C/C++ (y pronto en Visual Basic y Visual J++, también) utilizando la API de los servicios abiertos de datos y la API Win32. Los usuarios pueden invocar los procedimientos almacenados extendidos de la misma forma que los

procedimientos almacenados normales. SQL Server contiene diversos procedimientos almacenados extendidos, todos los cuales llevan como prefijo xp. El procedimiento xp_sendmail es un buen ejemplo de procedimiento almacenado extendido: . amplía la funcionalidad de SQL Server, permitiendo enviar correo electrónico desde un lote Transact-SQL. En las versiones anteriores de SQL Server, ODS era el único medio de proporcionar una pasarela con aplicaciones que no fueran de SQL Server. Si se deseaba escribir una aplicación que almacenara datos en SQL Server y accediera a otro origen de datos situado en una aplicación de otra compañía, había que desarrollar una aplicación pasarela utilizando ODS. ODS es difícil de programar y requiere una gestión exhaustiva de las excepciones. Con el advenimiento de la función de consulta distribuida y los Servicios de transformación de datos de SQL Server 7.0, y con el lanzamiento de Microsoft Transaction Server, hay menos necesidad de emplear ODS. Es recomendable que las nuevas aplicaciones de pasarela para SQL Server empleen alguna de las tecnologías basadas en componentes. Las aplicaciones basadas en componentes son independientes del lenguaje y pueden ser ejecutadas bajo MTS, que ofrece ampliabilidad, seguridad y una gestión estructurada de los errores. ASP

Qué es ADO? ActiveX Data Objects (ADO) es una tecnología ampliable y de fácil uso para agregar acceso a bases de datos a sus páginas Web. Puede utilizar ADO para escribir secuencias de comandos compactas y escalables que conecten con bases de datos compatibles con Open Database Connectivity (ODBC, Conectividad abierta de bases de datos) y orígenes de datos compatibles con OLE DB. Si no tiene mucha experiencia en conectividad con bases de datos, encontrará que las instrucciones de ADO son asequibles y no complicadas. Del mismo modo, si ya tiene experiencia en la programación con bases de datos, apreciará las características avanzadas de conexión y de manipulación de consultas independientes del lenguaje de ADO.

Nota. Si se desean usar las constantes de ADO se deben incluir los siguientes archivos.  ó  Características de ADO 

Objetos creados independientemente.



Ayudas de modificación en lote.



Soporte para procedimientos almacenados.



Diferentes tipos de cursores.



Soporte para retornar múltiples recordsets



Aplicaciones libres de Hilos para aplicaciones de servidor web eficientes.

Objetos ADO 

Connection: Mantiene la información de conexión con el proveedor de datos.

set VarConexion = Server.CreateObject(ADODB.Connection) Métodos: Open: VarConexion.Open ConnectionString [,UserID] [,Password] Close: VarConexion.Close Execute: VarConexion.Execute CommandText,RecordsAffected,Options Propiedades: CommandTimeOut ConnectionString ConnectionTimeOut State Version DefaultDataBase



Command: Mantiene información acerca de un comando

set VarComando = Server.CreateObject(ADODB.Command) Métodos: CreateParameter: Set varParametro= command.CreateParameter(Name, Type, Direction, Size, Value) Execute: Set recordset = command.Execute( RecordsAffected, Parameters, Options ) Propiedades: ActiveConectionComandtext CommandTimeOut CommandType Name Prepared State 

Error: Mantiene información acerca de algún error ocurrido en el proveedor

set VarError = Server.CreateObject(ADODB.Error) 

Field: Mantiene información de un único campo dentro de un recordset

set VarConexion = Server.CreateObject(ADODB.Connection) 

Parameter: Es un parámetro para ser usado en un objeto command.

set VarParametro = Server.CreateObject(ADODB.Parameter) 

Property: Características de un objeto.

set VarPropiedad = Server.CreateObject(ADODB.Property) 

Recordset: Conjunto de registros retornados desde una consulta con un cursor asociado.

set VarConexion = Server.CreateObject(ADODB.Recordset)

MĂŠtodos: AddNew: recordset.AddNew Fields, Values CancelUpdate: recordset.CancelUpdate Close: object.Close Delete: recordset.Delete AffectRecords GetRows: array = recordset.GetRows( Rows, Start, Fields ) Move: recordset.Move NumRecords, Start Movefirst, MoveNext, MoveLast, MovePrevious: recordset.MoveX Open: recordset.Open Source, ActiveConnection, CursorType, LockType, Options Requery: recordset.Requery Update: recordset.Update Fields,Values Supports: boolean = recordset.Supports( CursorOptions ) Propiedades: AbsolutePage, AbsolutePosition, ActiveConnection, BOF, Bookmark, CacheSize, CursorLocation, CursorType, EditMode, EOF, Filter, LockType, MarshalOptions, MaxRecords, PageCount, PageSize, RecordCount, Source,

State, Status Creación del Archivo de Acceso a Datos (DSN) Antes de crear secuencias de comandos para bases de datos tiene que proporcionar una forma para que ADO encuentre, identifique y se comunique con una base de datos. Los controladores de bases de datos (programas que pasan información desde su aplicación Web a una base de datos) utilizan un Nombre de origen de datos (DSN) para encontrar e identificar una base de datos ODBC en particular. Normalmente, el DSN contiene información de configuración de la base de datos, seguridad de usuarios y ubicación, y puede tener la forma de una entrada en el registro del sistema de Windows NT o de un archivo de texto. Con ODBC puede elegir el tipo de DSN que va a crear: Usuario, Sistema o Archivo. Los DSN de Usuario y de Sistema residen en el registro del sistema de Windows NT. Los DSN de Sistema permiten que todos los usuarios que han iniciado una sesión en un servidor concreto tengan acceso a una base de datos, mientras que los DSN de Usuario limitan la conectividad con la base de datos a los usuarios que dispongan de las credenciales de seguridad apropiadas. Los DSN de Archivo, que tienen la forma de archivos de texto, proporcionan acceso a varios usuarios y son fácilmente transferibles entre un servidor y otro mediante la copia de los archivos DSN. Por estas razones, los ejemplos de este tema utilizan DSN de Archivo. Puede crear un DSN de Archivo si abre Panel de control desde el menú Inicio de Windows. Haga doble clic en el icono ODBC y seleccione la hoja de propiedades DSN de Archivo. Haga clic en Agregar, elija el controlador de la base de datos y haga clic en Siguiente. 

Para configurar un DSN de Archivo para una base de datos de Microsoft Access

1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione Controlador Microsoft Access en el cuadro de lista, después, haga clic en Siguiente. 2. Escriba el nombre de su DSN de Archivo y haga clic en Siguiente. 3. Haga clic en Finalizar para crear el origen de datos. 4. En el cuadro de diálogo Instalación de ODBC para Microsoft Access 97, haga clic en Seleccionar. Elija un archivo de base de datos de Microsoft Access (*.mdb) y haga clic en Aceptar. Nota

Por

razones

rendimiento

confiabilidad,

recomienda

encarecidamente que utilice un motor de base de datos cliente-servidor para el despliegue de aplicaciones Web controladas por datos que requieran una elevada demanda de accesos por parte de más de 10 usuarios simultáneos. Si bien Páginas Active Server funciona con cualquier base de datos compatible con ODBC, se ha probado y está diseñado para funcionar con bases de datos cliente-servidor como Microsoft (r) SQL Server u Oracle. ASP acepta bases de datos de archivos compartidos (Microsoft(r) Access o Microsoft(r) FoxPro) como orígenes válidos de datos. Aunque algunos ejemplos de la documentación de ASP utilizan una base de datos de archivos compartidos, se recomienda utilizar estos tipos de motores de bases de datos únicamente con fines de desarrollo o en situaciones de despliegue limitado. Las bases de datos de archivos compartidos pueden no ser tan adecuadas como las bases de datos cliente-servidor para aplicaciones Web de producción muy exigentes. 

Para configurar un DSN de Archivo para una base de datos de SQL Server

Nota Si la base de datos reside en un servidor remoto, póngase en contacto con el administrador del servidor para obtener información de configuración adicional; el siguiente procedimiento utiliza la configuración predeterminada de ODBC para SQL Server, que puede no funcionar con su configuración hardware.

1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione SQL Server en el cuadro de lista y haga clic en Siguiente. 2. Escriba el nombre de su DSN de Archivo y haga clic en Siguiente. 3. Haga clic en Finalizar para crear el origen de datos. 4. Escriba el nombre del servidor que ejecuta SQL Server, su Id. de inicio de sesión y su contraseña. 5. En el cuadro de diálogo Crear un nuevo origen de datos SQL Server, escriba en el cuadro de lista Servidor el nombre del servidor que contenga la base de datos de SQL Server y haga clic en Siguiente. 6. Seleccione el método de comprobar la autenticidad del Id. de inicio de sesión. 7. Si elige la autenticación SQL Server, escriba el Id. de inicio de sesión y la contraseña; después, haga clic en Siguiente. 8. En el cuadro de diálogo Crear un nuevo origen de datos SQL Server, establezca la base de datos predeterminada, la configuración de los procedimientos almacenados del controlador y los identificadores ANSI; después, haga clic en Siguiente. (Para obtener más información, haga clic en Ayuda.) 9. En el cuadro de diálogo (también se llama Crear un nuevo origen de datos SQL Server), elija el método de traducción de caracteres y haga clic en Siguiente. (Para obtener más información, haga clic en Ayuda.) 10. En el siguiente cuadro de diálogo (también se llama Crear un nuevo origen de datos SQL Server), seleccione las opciones de registro. Nota Normalmente, sólo debe utilizar el registro para depurar problemas de acceso a la base de datos. 11. En el cuadro de diálogo Instalación de ODBC para Microsoft SQL Server, haga clic en Comprobar origen de datos. Si el DSN se ha creado correctamente, el cuadro de diálogo Resultados de la comprobación indicará que la comprobación es correcta.

Información de conexión y seguridad de SQL Server Si va a desarrollar una aplicación ASP de base de datos diseñada para conectar con una base de datos remota de SQL Server, debe tener en cuenta también los aspectos siguientes: Esquema de conexión Puede elegir entre los métodos Sockets

TCP/IP y Canalizaciones con nombre para tener acceso a bases de datos remotas de SQL Server. Con Canalizaciones con nombre, los clientes de la base de datos tienen que estar autenticados por Windows NT antes de establecer una conexión, dejando la posibilidad de que un equipo remoto que ejecute canalizaciones con nombre pueda denegar el acceso a un usuario que tenga las credenciales apropiadas de acceso a SQL Server, pero no tenga una cuenta de usuario de Windows NT en dicho equipo. Como alternativa, las conexiones que utilizan Sockets TCP/IP

conectan directamente con el servidor de la base de datos, sin conectar a través de un equipo intermediario (como es el caso de Canalizaciones con nombre). Como las conexiones establecidas mediante Sockets TCP/IP conectan directamente con el servidor de la base de datos, los usuarios pueden tener acceso mediante la autenticación de SQL Server, no mediante la autenticación de Windows NT.

Nota Para aumentar el rendimiento en la conexión con bases de datos remotas, utilice Sockets TCP/IP. Seguridad Si utiliza las características de seguridad Integrada o

Mixta de SQL Server y la base de datos de SQL Server reside en un servidor remoto, no podrá utilizar la autenticación Desafío/Respuesta de Windows

NT.

Específicamente,

puede

reenviar

credenciales

Desafío/Respuesta de Windows NT al equipo remoto. Esto significa que quizá tenga que utilizar la autenticación Básica, que se basa en que el usuario proporcione la información del nombre de usuario y la contraseña.

Para obtener más información acerca de estos aspectos, visite la página principal

Microsoft

SQL

Server

Technical

Support

http://www.microsoft.com/sqlsupport/. 

Para configurar un DSN de Archivo para una base de datos de Oracle

Asegúrese de que el software cliente de Oracle esté correctamente instalado en el equipo donde vaya a crear el DSN. Para obtener más información, consulte con el administrador del servidor y la documentación de la base de datos. 1. En el cuadro de diálogo Crear nuevo origen de datos, seleccione Controlador ODBC de Microsoft para Oracle en el cuadro de lista y haga clic en Siguiente. 2. Escriba el nombre del DSN de Archivo y haga clic en Siguiente. 3. Haga clic en Finalizar para crear el origen de datos. 4. Escriba un nombre de usuario, una contraseña y el nombre del servidor; después, haga clic en Aceptar. Nota Los archivos DSN tienen la extensión .dsn y residen en el directorio \Archivos de programa\Archivos comunes\ODBC\Data Sources. Para obtener más información acerca de la creación de DSN de Archivo, visite el sitio Web de Microsoft ODBC en http://microsoft.com/odbc/.

Conexión con una Base de Datos El primer paso para tener acceso a la información de una base de datos consiste en establecer una conexión con el origen de datos. ADO proporciona el objeto Connection, que puede utilizar para establecer y administrar las conexiones entre sus aplicaciones y las bases de datos de ODBC. El objeto Connection incorpora diversas propiedades y métodos que puede utilizar para abrir y cerrar conexiones con bases de datos, y para enviar consultas de actualización de la información.

Para establecer una conexión con una base de datos, cree primero una instancia del objeto Connection. Por ejemplo, la siguiente secuencia de comandos crea una instancia del objeto Connection y procede a abrir una conexión: <% 'Crea un objeto Connection Set cn = Server.CreateObject("ADODB.Connection") 'Abre una conexión; la cadena hace referencia al DSN cn.Open "FILEDSN=MiBaseDeDatos.dsn" %> Nota La cadena DSN no contiene espacios en blanco ni antes ni después del signo igual (=). En este caso, el método Open del objeto Connection hace referencia al DSN de Archivo, que contiene la información de ubicación y la configuración de la base de datos. Opcionalmente, también puede hacer referencia directamente a un proveedor, origen de datos, Id. de usuario y contraseña, en lugar de al DSN.

Ejecución de Consultas con el Objeto CONNECTION Con el método Execute del objeto Connection puede enviar consultas en el Lenguaje de consulta estructurado (SQL) al origen de datos y recuperar los resultados. SQL, un lenguaje estándar para comunicarse con bases de datos, tiene comandos para recuperar y actualizar información. La siguiente secuencia de comandos utiliza el método Execute del objeto Connection para enviar una consulta con un comando INSERT de SQL, que inserta datos en una tabla concreta de la base de datos. En este caso, el bloque de la secuencia de comandos inserta el nombre José Lugo en una tabla de la base de datos llamada Customers.

<% 'Define el DSN de Archivo strDSN = "FILEDSN=MiBaseDeDatos.dsn"

'Crea la instancia del objeto Connection y abre una conexión con la base de datos

Set cn = Server.CreateObject("ADODB.Connection") cn.Open strDSN

'Define la instrucción SELECT de SQL strSQL = "INSERT INTO Customers (FirstName, LastName) VALUES ('José','Lugo')"

'Utiliza el método Execute para enviar una consulta SQL a la base de datos cn.Execute(strSQL)

Nota La ruta del DSN de Archivo no debe incluir espacios en blanco antes ni después del signo igual (=). Además del comando INSERT de SQL, puede utilizar los comandos UPDATE y DELETE de SQL para modificar y quitar información de la base de datos. Con el comando UPDATE de SQL puede modificar los valores de los elementos de una tabla de la base de datos. La siguiente secuencia de comandos usa el comando UPDATE para cambiar todos los campos FirstName de la tabla Customers a Juan en todas las filas cuyo campo LastName contenga el apellido Robles.

<% Set cn = Server.CreateObject("ADODB.Connection") cn.Open "FILEDSN=MiBaseDeDatos.dsn" cn.Execute "UPDATE Customers SET FirstName = 'Juan' WHERE LastName = 'Robles' "

Para quitar determinados registros de una tabla de la base de datos, < BR > utilice el comando DELETE de SQL. La siguiente secuencia de comandos quita todas las filas de la tabla Customers cuyo apellido sea Robles:

<% Set cn = Server.CreateObject("ADODB.Connection") cn.Open "FILEDSN=MiBaseDeDatos.dsn" cn.Execute "DELETE FROM Customers WHERE LastName = 'Robles'" %>

Nota Debe tener mucho cuidado al utilizar el comando DELETE de SQL. Un comando DELETE que no vaya acompañado de una cláusula WHERE eliminará todas las filas de la tabla. Asegúrese de incluir una cláusula WHERE de SQL, que especifica las filas exactas que se van a eliminar.

Uso del Objeto RECORDSET para manipulación de resultados Aunque el objeto Connection simplifica la tarea de conectar con una base de datos y emitir una consulta, el objeto Connection tiene sus limitaciones. En concreto, con el objeto Connection no se pueden crear secuencias de comandos que recuperen y presenten información de una base de datos; tiene que saber exactamente las modificaciones que desea realizar en la base de datos y después implementar las modificaciones como consultas. Para recuperar datos, examinar resultados y modificar su base de datos, ADO proporciona el objeto Recordset. El objeto Recordset tiene las funciones necesarias para, dependiendo de las restricciones de las consultas, recuperar y presentar un conjunto de filas, o registros, de una base de datos. El objeto Recordset mantiene la posición de cada registro devuelto por la consulta, lo que permite "recorrer" los resultados de uno en uno. Dependiendo de cómo configure las propiedades del tipo de cursor del objeto Recordset, puede recorrer y actualizar los registros. Los cursores de la base de datos se comportan como punteros que le permiten encontrar un elemento específico de un conjunto de registros. Los cursores son especialmente útil para recuperar y examinar registros, y después realizar operaciones basadas en dichos registros. El objeto Recordset tiene propiedades que le permiten controlar con precisión el comportamiento de los cursores, lo que aumenta la capacidad de examinar y actualizar los resultados. Por ejemplo, puede utilizar las propiedades CursorType y CursorLocation para configurar un tipo de cursor que devuelva un conjunto de resultados a su aplicación cliente (los resultados permanecen normalmente en el servidor de base de datos) y presente las últimas modificaciones realizadas en la base de datos por otros usuarios.

Recuperar un conjunto de registros Las buenas aplicaciones de base de datos emplean el objeto Connection para establecer un vínculo y el objeto Recordset para manipular los datos devueltos. Si utiliza conjuntamente las funciones especializadas de ambos objetos puede desarrollar aplicaciones de bases de datos que realicen casi cualquier tarea de tratamiento de datos. Por ejemplo, la siguiente secuencia de comandos del servidor utiliza el objeto Recordset para ejecutar un comando SELECT de SQL. El comando SELECT recupera un conjunto específico de información basándose en las restricciones de la consulta. La consulta también contiene una cláusula WHERE de SQL, que se utiliza para establecer el criterio de selección de la consulta. En este ejemplo, la cláusula WHERE limita la consulta a todos los registros que contengan el apellido Soto en la tabla Customers de la base de datos.

<% 'Establece una conexión con un origen de datos strDSN = "FILEDSN=MiBaseDeDatos.dsn" Set cn = Server.CreateObject("ADODB.Connection") cn.Open strDSN

'Crea una instancia de un objeto Recordset Set rsCustomers = Server.CreateObject("ADODB.Recordset")

'Abre un objeto Recordset con el método Open 'y utiliza la conexión establecida por el objeto Connection strSQL = "SELECT FirstName, LastName FROM Customers WHERE LastName = 'Soto' "

rsCustomers.Open strSQL, cn

'Recorre el conjunto de los registros y presenta los resultados 'e incrementa la posición del registro con el método MoveNext Set objFirstName = rsCustomers("FirstName") Set objLastName = rsCustomers("LastName") Do Until rsCustomers.EOF Response.Write objFirstName & " " & objLastName & "<BR>"

rsCustomers.MoveNext Loop %> Observe que en el ejemplo anterior, el objeto Connection estableció la conexión con la base de datos y el objeto Recordset utilizó la misma conexión para recuperar resultados de la base de datos. Este método es útil cuando tenga que configurar con precisión la forma en que se establece el vínculo con la base de datos. Por ejemplo, si necesitara especificar el tiempo de espera antes de anular un intento de conexión, tendría que utilizar el objeto Connection para establecer dicha propiedad. Sin embargo, si sólo desea establecer una conexión con las propiedades de conexión predeterminadas de ADO, podría utilizar el método Open del objeto Recordset para establecer el vínculo: <% strDSN = "FILEDSN=MiBaseDeDatos.dsn" strSQL = "SELECT FirstName, LastName FROM Customers WHERE LastName = 'Soto' "

Set rsCustomers = Server.CreateObject("ADODB.Recordset")

'Abre una conexión con el método Open 'y utiliza la conexión establecida por el objeto Connection rsCustomers.Open strSQL, strDSN

'Recorre el conjunto de registros, presenta los resultados 'e incrementa la posición del registro con el método MoveNext Set objFirstName = rsCustomers("FirstName") Set objLastName = rsCustomers("LastName") Do Until rsCustomers.EOF Response.Write objFirstName & " " & objLastName & "<BR>" rsCustomers.MoveNext Loop %> Cuando establece una conexión con el método Open del objeto Recordset, está utilizando implícitamente el objeto Connection para proteger el vínculo.

Manejo de consultas con el Objeto COMMAND Con el objeto Command de ADO puede ejecutar consultas de la misma forma que con los objetos Connection y Recordset, excepto en que con el objeto Command puede preparar, o compilar, la consulta con el origen de la base de datos y después enviar la misma consulta repetidamente con distintos valores. La ventaja de compilar consultas de esta manera consiste en la enorme reducción del tiempo necesario para volver a enviar las modificaciones de una consulta existente. Además, puede dejar las consultas SQL parcialmente indefinidas, con la posibilidad de alterar partes de las consultas justo antes de su ejecución. La colección Parameters del objeto Command le ahorra los problemas de tener que volver a construir la consulta cada vez que tenga que ejecutarla. Por ejemplo, si tiene que actualizar periódicamente la información de suministros y costos en un sistema de inventario Web, puede predefinir su consulta de la siguiente manera: <% 'Abre una conexión mediante el objeto Command del objeto 'Connection no tiene un método Open para establecer 'la conexión strDSN = "FILEDSN=MiBaseDeDatos.dsn" Set cn = Server.CreateObject("ADODB.Connection") cn.Open strDSN

'Crea el objeto Command; utiliza la propiedad 'ActiveConnection para 'adjuntar la conexión al objeto Command Set cm= Server.CreateObject("ADODB.Command") Set cm.ActiveConnection = cn 'Define laconsulta SQL cm.CommandText = "INSERT INTO Inventory (Material, Quantity) VALUES (?, ?)"

'Guarda una versión preparada (o precompilada) de la consulta < BR > 'especificada en la propiedad

'CommandText antes de la primera ejecución del objeto Command. cm.Prepared = True

'Define la información de configuración 'de los parámetros de la consulta cm.Parameters.Append cm.CreateParameter("material_type",200,,255) cm.Parameters.Append cm.CreateParameter("quantity",200, ,255 )

'Define y ejecuta la primera inserción cm("material_type") = "Bombillas" cm("quantity") = "40" cm.Execute

'Define y ejecuta la segunda inserción cm("material_type") = "Fusibles" cm("quantity") = "600" cm.Execute %> Si examina el ejemplo anterior, observará que la secuencia de comandos vuelve a construir repetidamente y envía una consulta SQL con distintos valores, sin tener que volver a definir y enviar la consulta al origen de datos. Compilar consultas con el objeto Command también le ofrece la ventaja de evitar los problemas que pudieran provenir de concatenar cadenas y variables para formar consultas SQL. En particular, si utiliza la colección Parameter del objeto Command puede evitar problemas relacionados con la definición de ciertos tipos de variables de cadenas, fechas y horas. Por ejemplo, los valores de las consultas SQL que contengan apóstrofos (') pueden hacer que la consulta falle: strSQL = "INSERT INTO Customers (FirstName, LastName) VALUES ('Roberto','O'Hara')"

Observe que el apellido O'Hara contiene un apóstrofo que entra en conflicto con los apóstrofos que se utilizan como delimitadores de datos en la palabra

clave VALUES de SQL. Si enlaza el valor de la consulta como un parámetro del objeto Command, se evitan este tipo de problemas.

MANEJO DE CONEXIONES A BASES DE DATOS

Uno de los mayores retos del diseño de una aplicación Web sofisticada de base de datos, como una aplicación de entrada de pedidos en línea que atienda a miles de clientes, es la correcta administración de la conexiones con la base de datos. Abrir y mantener las conexiones con las bases de datos, incluso cuando no se transmita información, puede afectar severamente a los recursos del servidor de base de datos y provoca problemas de conectividad. Las aplicaciones Web de bases de datos bien diseñadas reciclan las conexiones con la base de datos y compensan los retrasos debidos al tráfico de la red. Abandonar los intentos de conexión Un servidor de base de datos que experimente un repentino incremento en su actividad puede quedar saturado en sus conexiones, lo que incrementa considerablemente el tiempo necesario para establecer una nueva conexión. Como resultado, los retrasos excesivos en la conexión pueden reducir el rendimiento de su aplicación de base de datos. Con la propiedad ConnectionTimeout del objeto Connection puede limitar la cantidad de tiempo que su aplicación espera antes de abandonar un intento de conexión y emitir un mensaje de error. Por ejemplo, la siguiente secuencia de comandos establece la propiedad ConnectionTimeout para esperar veinte segundos antes de cancelar el intento de conexión:

Set cn = Server.CreateObject("ADODB.Connection") cn.ConnectionTimeout = 20 cn.Open "FILEDSN=MiBaseDeDatos.dsn"

El valor predeterminado de la propiedad ConnectionTimeout es 30 segundos.

Nota Antes de incorporar la propiedad ConnectionTimeout a sus aplicaciones de bases de datos, asegúrese de que su proveedor de conexiones y el origen de datos acepten esta propiedad. Aceptar conexiones Las aplicaciones Web de bases de datos que establecen y terminan con frecuencia conexiones con bases de datos pueden reducir el rendimiento del servidor de base de datos. ASP acepta la eficiente administración de las conexiones que se consigue mediante la función de agrupamiento de conexiones de ODBC 3.5. El agrupamiento de conexiones mantiene abiertas las conexiones con las bases de datos y administra el uso compartido de las conexiones entre distintas peticiones de usuario para mantener el nivel de rendimiento y reducir el número de conexiones inactivas. En cada petición de conexión, el conjunto de conexiones determina si hay alguna conexión inactiva en el conjunto. Si es así, el conjunto de conexiones devuelve una de ellas en lugar de establecer una nueva conexión con la base de datos. Si desea que su controlador ODBC participe en el conjunto de conexiones, debe configurar su controlador específico de base de datos y después establecer la propiedad CPTimeout del controlador en el registro del sistema de Windows NT. Cuando ODBC desconecta una conexión, la conexión se guarda en un conjunto, en lugar de desconectarse. La propiedad CPTimeout determina el periodo de tiempo de inactividad que una conexión puede permanecer en el conjunto de conexiones. Si la conexión permanece en el conjunto durante un periodo de tiempo mayor que el establecido en CPTimeout, la conexión se cierra y se quita el conjunto. El valor predeterminado de CPTimeout es 60 segundos. Puede establecer selectivamente la propiedad CPTimeout para permitir el agrupamiento de conexiones por cada controlador específico de base de datos ODBC si crea una entrada en el registro del sistema con los siguientes valores:

\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\controlador \CPTimeout = timeout

(REG_SZ, en segundos)

Por ejemplo, la clave siguiente establece el tiempo de inactividad del conjunto de conexiones a 180 segundos (3 minutos) para el controlador de SQL Server.

\HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\SQL Server\CPTimeout = 180

Nota De forma predeterminada, su servidor Web activa el conjunto de conexiones para SQL Server y asigna a CPTimeout 60 segundos. 6.2.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

6.2.3.2.

MATERIAL DE APOYO

6.2.4. ACTIVIDADES DE APRENDIZAJE 6.2.4.1.

ACTIVIDAD DE APRENDIZAJE 1

A26-EC12 Manejo de Bases de Datos atraves de ADO. 6.2.4.1.1. INSTRUCCIONES Realizar una aplicación que manipule una base de datos utilizando la tecnología de acceso ADO. a) b) c) d) e) f)

Valor actividad: 10 Puntos Producto esperado: Aplicacion Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Equipo (5 gentes) 6.2.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Manejo de Bases de Datos atraves de ADO

DESARROLLO Aplicación que manipula una Base de Datos en cualquier lenguaje de programación Total

6.2.5. RESULTADO DE APRENDIZAJE Aprender a utilizar una tecnología de acceso a datos 6.2.6. BIBLIOGRAFÍA Manual SQL Server 2000 Standard final 6.2.7. DOCUMENTOS

PONDERACIÓN 10 puntos 10 Puntos

6.3. JDBC, PAGINAS DEL SERVIDOR JAVA. 6.3.1. OBJETIVO DE APRENDIZAJE Aprender de forma general las característica del manejador de Base de Datos para Java (JDBC). 6.3.2. RECURSO TIEMPO DEL TEMA 5 horas 6.3.3. DESARROLLO

Acceso a Bases de DatosJava IDL JDBC fue diseñado para mantener sencillas las cosas sencillas. Esto significa que el API JDBC hace muy sencillas las tareas diarias de una base de datos, como una simple sentencia SELECT. Esta sección nos llevará a través de ejemplos que utilizan el JDBC para ejecutar sentencias SQL comunes, para que podamos ver lo sencilla que es la utilización del API JDBC básico.

Esta sección está dividida a su vez en dos secciones. JDBC Basico que cubre el API JDBC 1.0, que está incluido en el JDK 1.1. La segunda parte cubre el API JDBC 2.0 API, que forma parte de la versión 1.2 del JDK. También describe brevemente las extensiones del API JDBC, que, al igual que otras extensiones estándard, serán liberadas independientemente. Al final de esta primera sección, sabremos como utilizar el API básico del JDBC para crear tablas, insertar valores en ellas, pedir tablas, recuperar los resultados de las peticiones y actualizar las tablas. En este proceso, aprenderemos como utilizar las sentencias sencillas y sentencias preparadas, y veremos un ejemplo de un procedimiento almacenado. También aprenderemos como realizar transaciones y como capturar excepciones y avisos. En la última parte de este sección veremos como crear un Applet. Nuevas Características en el API JDBC 2.0 nos enseña como mover el cursor por una hoja de resultados, cómo actualizar la hoja de resultados utilizando el API JDBC 2.0, y como hacer actualizaciones batch. También conoceremos los nuevos tipos de datos de SQL3 y como utilizarlos en aplicaciones escritas en Java. La parte final de esta lección entrega una visión de la extensión del API JDBC, con caracterísitas que se aprovechan de la tecnologías JavaBeans y Enterprise JavaBeans.

Esta sección no cubre cómo utilizar el API metadata, que se utiliza en programas más sofisticados, como aplicaciones que deban descubrir y presentar dinámicamente la estructura de una base de datos fuente. La Conectividad de Bases de Datos Java (Java Database Connectivity, JDBC) es una especificación de la interfaz de aplicación de programa (application program interface, API) para conectar los programas escritos en Java a los datos en bases de datos populares. La interfaz de aplicación de programa nos permite codificar órdenes de solicitud de acceso en lenguaje estructurado de solicitud (structured query language, SQL) que luego pasan al programa que administra la base de datos. Devuelve los resultados a través de una interfaz similar. La JDBC es muy similar a la Conectividad Abierta de Base de Datos (Open Database Connectivity, ODBC) de Microsoft y, con un pequeño programa "puente" podemos usar la interfaz JDBC para acceder a bases de datos a través de la interfaz ODBC de Microsoft. Por ejemplo, podemos escribir un programa diseñado para acceder a muchos productos populares de base de datos en una variedad de plataformas de sistema operativo. Cuando se accede a una base de datos en un PC que corre bajo Windows 95 de Microsoft y, por ejemplo, una base de datos de Microsoft Access, nuestro programa con órdenes JDBC será capaz de acceder a la base de datos de Access de Microsoft.

La JDBC tiene actualmente dos niveles de interfaz. Además de la interfaz principal hay también una API de un "administrador" JDBC que a su vez se comunica con los "controladores" de producto de las bases de datos individuales, si es necesario, el puente JDBC-ODBC bridge y a un controlador de red JDBC cuando el programa Java está corriendo en un entorno de red (es decir, accediendo a una base de datos remota).

Cuando accede a una base de datos remota, la JDBC aprovecha el esquema de dirección de archivos de Internet y un nombre de archivo que tiene en mucho la apariencia de una dirección de página web (o URL). Por ejemplo, una orden SQL en Java puede identificar a la base de datos como:

jdbc:odbc://www.empresa.com:400/basededatos

JDBC especifica un conjunto de clases de programación orientada a objetos para que el programador lo use en la construcción de solicitudes SQL. Un conjunto adicional de clases describe el controlador API de JDBC. Soporta los tipos de datos más comunes de SQL, mapeados en forma de tipos de datos Java. La API permite el soporte específico de implementación para las solicitudes transaccionales y la capacidad de "comprometerse" o volver al principio de una transacción.13

6.3.3.1.

TÉCNICA DIDÁCTICA Exposición del profesor.

6.3.3.2.

MATERIAL DE APOYO

6.3.4. ACTIVIDADES DE APRENDIZAJE 6.3.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A27-I7 JDBC.

6.3.4.1.1. INSTRUCCIONES Hacer una investigación de complemento al tema de JDBC. a) b) c) d) e) f)

Valor actividad: 5 Puntos Producto esperado: Investigación Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo (3 gentes) 6.3.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD JDBC

DESARROLLO Documento que avale la investigacón, el documento debe contener fuentes bibliograficas Total

6.3.5. RESULTADO DE APRENDIZAJE Conocer las características generales de JDBC 6.3.6. BIBLIOGRAFÍA http://www2.terra.com/informatica/que-es/jdbc.cfm 6.3.7. DOCUMENTOS

http://www2.terra.com/informatica/que-es/jdbc.cfm (05-Ago-05)

PONDERACIÓN 5 puntos 5 Puntos

UNIDAD TEMATICA 7. PROYECTO FINAL 7.1.1. OBJETIVO DE APRENDIZAJE PONER EN PRACTICA TODO LO APRENDIDO EN ESTA MATERIA 7.1.2. RECURSO TIEMPO DEL TEMA 16 horas 7.1.3. DESARROLLO Esta unidad consite básicamente en realizar un proyecto que incluya muchos de los conceptos y practicas vistas en el curso. Por lo cual se pide un proyecto por equipo de 4 personas, el cual debe cumplir con los siguientes requisitos:

1. El proyecto a realizar debe de estar basado en una organización real. 2. Debe manejar una base de datos distribuida o relacional la que mejor se adpate a la organización. 3. Todas las reglas de negocio deben de estar validadas ya sea por restricciones CHECK, Reglas, Transacciones, Procedimientos, además debe de contener los posibles usuarios que el sistema requiera. 4. Por ultimo debe de haber una aplicación que manipule los datos de la base de datos.

7.1.3.1.

TÉCNICA DIDÁCTICA Practica por parte de los alumnos

7.1.3.2.

MATERIAL DE APOYO

7.1.4. ACTIVIDADES DE APRENDIZAJE 7.1.4.1.

ACTIVIDAD DE APRENDIZAJE 1 A28-T7 Análisis del sistema.

7.1.4.1.1. INSTRUCCIONES Realizar el análisis del negocio para poder definir la base da datos (Los puntos a cubrir que a disposición del docente) a) b) c) d) e) f)

Valor actividad: 10 Puntos Producto esperado: Análisis del Sistema Fecha inicio: Fecha entrega: Forma de entrega: Documento Tipo de Actividad: Equipo (4 gentes) 7.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

DESARROLLO

PONDERACIÓN

Debe cubrir con todos los puntos que el docente disponga

Análisis del sistema

10 puntos Total

7.1.4.2.

10 Puntos

ACTIVIDAD DE APRENDIZAJE 2 A29-T8 Diseño de la Base de Datos.

7.1.4.2.1. INSTRUCCIONES Diseñar la Base de Datos en base al análisis hecho en la practica anterior. g) h) i) j) k) l)

Valor actividad: 15 Puntos Producto esperado: Base de Datos Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Equipo (4 gentes) 7.1.4.2.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Diseño de la Base de Datos

7.1.4.3.

DESARROLLO La Base de Datos debe de estar normalizada y debe de cubrir con todos los aspectos del negocio Total

PONDERACIÓN 15 puntos 15 Puntos

ACTIVIDAD DE APRENDIZAJE 3 A30-T9 Reglas de Negocio.

7.1.4.3.1. INSTRUCCIONES Aplicar todas las reglas del negocio utilizando restricciones CHECK, reglas, transacciones, relaciones, etc. Asi como tambien debe de contener los usuarios con los privilegios correspondientes. m) n) o) p) q) r)

Valor actividad: 20 Puntos Producto esperado: Reglas del negocio aplicadas Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Equipo (4 gentes) 7.1.4.3.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Reglas de Negocio

DESARROLLO Las reglas deben de estar aplicadas Total

PONDERACIÓN 20 puntos 20 Puntos

7.1.4.4.

ACTIVIDAD DE APRENDIZAJE 4 A31-T10 Sistema de Base de Datos.

7.1.4.4.1. INSTRUCCIONES En cualwuier lenguaje de programación, realizar la aplicación que interacte con la base de datos. s) t) u) v) w) x)

Valor actividad: 10 Puntos Producto esperado: Sistema de Base de Datos Fecha inicio: Fecha entrega: Forma de entrega: Archivo Tipo de Actividad: Equipo (4 gentes) 7.1.4.4.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1 ACTIVIDAD

Sistema de Base de Datos

DESARROLLO Checar que el sistema cumpla con las especificaciones necesarias Total

PONDERACIÓN 10 puntos 10 Puntos

7.1.5. RESULTADO DE APRENDIZAJE Conocer el negocio del cual se va a realizar el diseño de la base de datos 7.1.6. BIBLIOGRAFÍA Manual de las materias de “Calidad de SoftWare” y el de “Ingenieria de SoftWare”. Diseño y Administración de Bases de Datos, HANSEN-HANSEN, PRENTICEHALL , Segunda edición. 7.1.7. DOCUMENTOS

ANEXO A BASE DE DATOS II TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

RESUMEN DE ACTIVIDADES DE APREDIZAJE

MES 1 Actividad de Aprendizaje

Fecha de Inicio

Fecha de Entrega

A1-T1 Cuestionario. A2-T2 Realizar Base de Datos A3-EC1 Sentencias SQL “Tablas Multiples” A4-ER1 Examen Rápido. A5-EC2 Procedimientos Almacenados A6-EC3 Procedimientos de disparo A7-EC4 Vistas

Puntuación 5 puntos 5 Puntos 10 puntos 10 Puntos 10 Puntos 10 Puntos 10 Puntos

Subtotal Examen Puntaje total del mes:

60 Puntos 40 Puntos 100 Puntos

MES 2 Actividad de Aprendizaje

Fecha de Inicio

Fecha de Entrega

A8-ER2 Examen Rápido A9-EC5 Restricciones CONSTRAINTS A10-EC6 Valores por omision A11-I1 Investigacion de Indices A12-EC7 Crear Indices A13-T3 Cuestionario transacciones A14-ER3 Examen Rápido A15-T4 Cuestionario planes A16-EC8 Transacciones A17-EC9 Crear usuarios A18-EC10 Seguridad de SQL A19-T5 Concesion y Renovación de privilegios

Puntuación 5 Puntos 5 Puntos 5 Puntos 5 Puntos 5 Puntos 2.5 Puntos 5 Puntos 2.5 Puntos 10 Puntos 5 Puntos 5 Puntos 5 Puntos

Subtotal Examen Puntaje total del mes:

60 Puntos 40 Puntos 100 Puntos

MES 3 Actividad de Aprendizaje

Fecha de Inicio

Fecha de Entrega

A20-T6 Configurar SQL Server para poder supervisar los sucesos A21-ER4 Examen Rápido de los temas 4.3 y 4.4 A22-I2 Sistemas en organizaciones A23-ER5 Examen Rápido de SGBD A24-EC11 Realización de una Base de Datos Distribuida. A25-ER6 Examen Rápido XML A26-EC12 Manejo de Bases de Datos a través de ADO

Puntuación 5 Puntos Requisito 5 Puntos 5 Puntos 30 Puntos 5 Puntos 10 Puntos

Subtotal Examen Puntaje total del mes:

60 Puntos 40 Puntos 100 Puntos

MES 4 Actividad de Aprendizaje

Fecha de Inicio

Fecha de Entrega

A27-I7 JDBC A28-T7 Análisis del sistema A29-T8 Diseño de la Base de Datos. A30-T9 Reglas de Negocio. A31-T10 Sistema de Base de Datos.

Puntuación 5 Puntos 10 Puntos 15 Puntos 20 Puntos 10 Puntos

Subtotal Examen Puntaje total del mes:

Claves de apoyo: A: Actividad (A#-Tipo#) T: Tarea I: Investigación EC: Ejercicios en clases ER: Examen Rápido

60 Puntos 40 Puntos 100 Puntos

ANEXO B BASE DE DATOS II TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN

RESUMEN DE ACTIVIDADES DE SESIONES MES 1 Fecha de la sesión

Tema 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7.

LA VENTAJA DEL SQL CONSULTA DE UNA SOLA TABLA CONSULTA DE TABLAS MULTIPLES CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O SUBCONSULTAS PROCEDIMIENTOS ALMACENADOS TRIGGERS VISTAS

SUBTOTAL DE HRS FRENTE A GRUPO HORAS EXTRACLASE TOTAL DE HRS AUTORIZADAS

No. Hrs. 1 2 3 5 6 7 6

28 0 28

MES 2 Fecha de la sesión

SUBTOTAL DE HRS FRENTE A GRUPO HORAS EXTRACLASE TOTAL DE HRS AUTORIZADAS

Tema

No. Hrs.

2.1. 2.2. 2.3. 2.4. 2.5.

TIPOS DE INTEGRIDAD DE DATOS USANDO RESTRICCIONES (CONSTRAINTS) USANDO VALORES POR OMISIÓN Y REGLAS INTRODUCCIÓN A INDICES ARQUITECTURA y CREACIÓN DE INDICES

1 2 4 1 3

3.1. 3.2. 3.3. 3.4. 3.5. 3.6.

PROCESAMIENTO DE TRANSACCIONES CONCEPTOS DE TRANSACCIONES PROPIEDADES DE LAS TRANSACCIONES PLANES Y RECUPERABILIDAD SERIABILIDAD DE PLANES TRANSACCIONES SQL

½ ½ 1 1 1 8

4.1. 4.2. 4.3.

SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS TIPOS DE SEGURIDAD CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN / RENOVACION DE PRIVILEGIOS.

1 2 2

28 0 28

MES 3 Fecha de la sesión

Tema

No. Hrs.

4.4.

SEGUIMIENTO DE AUDITORIA

5.1. 5.2. 5.3.

SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES MODELO GENERAL DE UN SGBD PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS.

2 1

ARQUITECTURAS MULTICAPA y XML TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y ASP.

6.1. 6.2.

SUBTOTAL DE HRS FRENTE A GRUPO HORAS EXTRACLASE TOTAL DE HRS AUTORIZADAS

28 0 28

MES 4 Fecha de la sesión

Tema 6.3.

JDBC, PAGINAS DEL SERVIDOR JAVA.

PROYECTO FINAL

SUBTOTAL DE HRS FRENTE A GRUPO HORAS EXTRACLASE TOTAL DE HRS AUTORIZADAS

No. Hrs. 5 16

21 0 21