base de datos

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

Dra. Miriam Yta

Directora de Enlace Académico 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 no tienen necesariamente que funcionar en 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

COMPONENTE

CLIENTE

M i c r o s o f t W i n 9 5 / 9 8 S i S i

M i c r o s o f t W i n d o w s N T W o r k s t a t i o n 4 . 0 y p o s t e r i o r e s

S i S i

M i c r o s o f t W i n d o w s N T S e r v e r 4 . 0 y p o s t e r i o r e s

S i S i

M i c r o s o f t W i n d o w s N T S e r v e r E n t e r p r i s e E d i t i o n 4 . 0 y p o s t e r i o r e s

S i S i

W i n d o w s 3 . X N o S i

M S - D O S N o S i

T h i r d p a r t y N o S i ( U n i x , a p p l e

M a c i n t o s h )

I n t e r n e t b r o w s e r s N o S i

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) Valor actividad: 5 Puntos b) Producto esperado: Contestar preguntas de manera escrita c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Individual

1.1.4.1.2. CRITERIO DE EVALUACIÓN DE LA ACTIVIDAD 1

ACTIVIDAD DESARROLLO PONDERACIÓN

Cuestionario del tema

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

5 puntos

Total 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 en función de 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 Contienen cifras y letras. Presentan una longitud limitada (255 caracteres)

Numéricos Existen de varios tipos, principalmente, enteros (sin

decimales) y reales (con decimales).

Booleanos Poseen dos formas: Verdadero y falso (Sí o No)

Fechas

Almacenan fechas facilitando posteriormente su

explotación. Almacenar fechas de esta forma posibilita

ordenar los registros por fechas o calcular los días entre

una fecha y otra...

Memos

Son campos alfanuméricos de longitud ilimitada.

Presentan el inconveniente de no poder ser indexados

(veremos más adelante lo que esto quiere decir).

Autoincrementables

Son campos numéricos enteros que incrementan en una

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 Descripción

CREATE Utilizado para crear nuevas tablas, campos e índices

DROP Empleado para eliminar tablas e índices

ALTER Utilizado para modificar las tablas agregando campos o

cambiando la definición de los campos.

COMANDOS DML

Comando Descripción

SELECT Utilizado para consultar registros de la base de datos que

satisfagan un criterio determinado

INSERT Utilizado para cargar lotes de datos en la base de datos en una

única operación.

UPDATE Utilizado para modificar los valores de los campos y registros

especificados

DELETE 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 Descripción

FROM Utilizada para especificar la tabla de la cual se van a seleccionar

los registros

WHERE Utilizada para especificar las condiciones que deben reunir los

registros que se van a seleccionar

GROUP BY Utilizada para separar los registros seleccionados en grupos

específicos

HAVING Utilizada para expresar la condición que debe satisfacer cada

grupo

ORDER BY Utilizada para ordenar los registros seleccionados de acuerdo

con un orden específico

OPERADORES LÓGICOS

Operador Uso

AND Es el "y" lógico. Evalua dos condiciones y devuelve un valor de

verdad sólo si ambas son ciertas.

OR Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de

verdar si alguna de las dos es cierta.

NOT 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 Utilizado en la comparación de un modelo

IN 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 Descripción

AVG Utilizada para calcular el promedio de los valores de un campo

determinado

COUNT Utilizada para devolver el número de registros de la selección

SUM Utilizada para devolver la suma de todos los valores de un

campo determinado

MAX Utilizada para devolver el valor más alto de un campo

especificado

MIN 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

2. Cláusula WHERE

3. Cláusula GROUP BY

4. Cláusula HAVING

5. Cláusula SELECT

6. 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 Omite los registros cuyos campos seleccionados

coincidan totalmente

DISTINCTROW 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





A2-T2 Realizar Base de Datos


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) Valor actividad: 5 Puntos b) Producto esperado: Base de datos. c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Archivo f) Tipo de Actividad: Equipo (3 gentes)



Realizar Base de Datos

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

5 puntos

Total 5 Puntos


Aprender a crear bases de datos en SQL Server 2000.


SQL Server 7.0

1.2.7. DOCUMENTOS


1.3. CONSULTA DE TABLAS MULTIPLES


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.

campo1,

campo2

Son los nombres de los campos que se combinan. Si no son

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

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

mismo nombre.

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

=>, ó >.

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 un ERROR. Se 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 SQL-

SERVER 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:


FROM Facturas, Albaranes

WHERE Facturas.IdAlbaran = Albaranes.IdAlbaran (+)


Y esto a un RIGHT JOIN:


FROM Facturas, Albaranes

WHERE Facturas.IdAlbaran (+) = Albaranes.IdAlbaran


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 Autor

B0012 1. Francisco López 1. Francisco López

B0012 1. Francisco López 2. Javier Alonso

B0012 1. Francisco López 3. Marta Rebolledo

B0012 2. Javier Alonso 2. Javier Alonso

B0012 2. Javier Alonso 1. Francisco López

B0012 2. Javier Alonso 3. Marta Rebolledo

B0012 3. Marta Rebolledo 3. Marta Rebolledo

B0012 3. Marta Rebolledo 2. Javier Alonso

B0012 3. Marta Rebolledo 1. Francisco López

C0014 1. Francisco López 1. Francisco López

C0014 1. Francisco López 2. Javier Alonso

C0014 2. Javier Alonso 2. Javier Alonso

C0014 2. Javier Alonso 1. Francisco López

D0120 2. Javier Alonso 2. Javier Alonso

D0120 2. Javier Alonso 3. Marta Rebolledo

D0120 3. Marta Rebolledo 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 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

1 Marcos 6

2 Lucas 1

3 Ana 2

4 Eva 1

5 Juan 6

6 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

1,consulta 2,

Son instrucciones SELECT, el nombre de una

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


FROM Proveedores


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


FROM Proveedores


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

agregada

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

seleccionados.

instrucción

SELECT Es una instrucción SELECT.

campo PIVOT

Es el campo o expresión que desea utilizar para crear

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 PEDIDOS

ID Nombre ID Fecha Cantidad

1 Zapatos 1 11/11/1996 250

2 Pantalones 2 11/11/1996 125

3 Blusas 3 11/11/1996 520

1 12/10/1996 50

2 04/10/1996 250

3 05/08/1996 100

1 01/01/1997 40

2 02/08/1997 60

3 05/10/1997 70

1 12/12/1997 8

2 15/12/1997 520

3 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 1 348 87 300 48

Pantalones 2 955 238,75 375 580

Blusas 3 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 Ejemplo (para grabar la fecha 18 de mayo de 1969)

SQL-SERVER 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 SQL-

SERVER 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 Falso

Verdad AND Verdad Verdad

Falso AND Verdad Falso

Falso AND Falso Falso

Verdad OR Falso Verdad

Verdad OR Verdad Verdad

Falso OR Verdad Verdad

Falso OR Falso Falso

Verdad XOR Verdad Falso

Verdad XOR Falso Verdad

Falso XOR Verdad Verdad

Falso XOR Falso Falso

Verdad EQV Verdad Verdad

Verdad EQV Falso Falso

Falso EQV Verdad Falso

Falso EQV Falso Verdad

Verdad IMP Verdad Verdad

Verdad IMP Falso Falso

Verdad IMP NULL NULL

Falso IMP Verdad Verdad

Falso IMP Falso Verdad

Falso IMP NULL Verdad

NULL IMP Verdad Verdad

NULL IMP Falso NULL

NULL IMP NULL 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


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:


WHERE DNI IS NULL

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

siguiente sintaxis:


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

coincidencia

Modelo

Planteado Coincide

No

coincide

Varios caracteres 'a*a' 'aa', 'aBa',

'aBBBa' 'aBC'

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'

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 Descripción

LIKE 'A%' Todo lo que comience por A

LIKE '_NG' Todo lo que comience por cualquier carácter y luego siga

NG

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

LIKE '[A-

F]%'

Todo lo que comience por cualquier letra comprendida entre

la A y la F

LIKE

'[A^B]%'

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

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, . . .)


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


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


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


SELECT VARP(Gastos) AS Varianza


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





A3-EC1 Sentencias SQL “Tablas Multiples”


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) Valor actividad: 10 Puntos b) Producto esperado: 5 sentencias SQL validas para SQL Server 2000 c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Individual



Sentencias SQL “Tablas Multiples”

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

10 puntos

Total 10 puntos


Comprobar que la sintaxis principalmente de las sentencias SQL es correcta y

además de verificar las ventajas que el lenguaje SQL ofrece.


Este manual

1.3.7. DOCUMENTOS


1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O

SUBCONSULTAS


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 Es una expresión y un operador de comparación que

compara la expresión con el resultado de la subconsulta.

expresión Es una expresión por la que se busca el conjunto

resultante de la subconsulta.

instrucción

SQL

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

3 > ANY (2,5,7) Cierto

3 = ANY (2,5,7) Falso

3 = ANY (2,3,5,7) Cierto

3 > ALL (2,5,7) Falso

3 < 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





A4-ER1 Examen Rápido.


Formular 5 preguntas acerca de subconsultas y dictárselas a los alumnos(as)

para que se contesten.




Examen Rápido de subconsultas

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

10 puntos

Total 10 Puntos


Verificar que el tema se este entendiendo, para medir el nivel de aprendizaje y

tomar acciones en base a los resultados.


Ayuda de SQL Server 2000

1.4.7. DOCUMENTOS


1.5. PROCEDIMIENTOS ALMACENADOS


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 se recompila cada vez que se ejecuta, desoyendo o

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 la misma sentencia de creación de 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 el nombre de un 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





A5-EC2 Procedimientos Almacenados.


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)



Procedimientos almacenados

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

10 puntos

Total 10 puntos


Conocer de cerca la utilidad que tienen los procedimientos almacenados.



1.5.7. DOCUMENTOS


1.6. TRIGGERS


Entender la ventaja de manejar ciertas acciones dentro de una base de datos

con procedimientos de disparo (autoejecutables).


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 de 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 la 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





A6-EC3 Procedimientos de disparo


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)



Procedimientos de disparo Entregar en papel la solucion y corroborar que funcionen con SQL Server 2000.

10 puntos

Total 10 puntos


Validar cuestiones de integridad de datos y aprender a validar ciertas reglas de

negocio que se pueden presentar.



1.6.7. DOCUMENTOS


1.7. VISTAS


Aprender a crear Tablas Virtuales, las cuales son de mucha ayuda para ciertas

necesidades.


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 Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación

FROM 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 Alumno.Nombre AS Alumno, Materia.Nombre AS Materia, Calificación

FROM Alumno INNER JOIN Calificacion

ON Alumno.Matricula = Calificacion.Matricula

INNER JOIN Materia ON Calificacion.CvMat = Materia.CvMat

WHERE Materia.Nombre = 'Fisica'





A7-EC4 Vistas


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) Valor actividad: 10 Puntos b) Producto esperado: Dos tablas virtuales c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes)



Vista

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

10 puntos

Total 10 Puntos


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.7. DOCUMENTOS


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


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.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 se llama Sueldo de tipo FLOTA no 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 Transact-

SQL 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,


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.





A8-ER2 Examen Rápido


Formular 5 preguntas del tema de Tipos de Integridad de Datos y dictárselas a

los alumnos para que procedan a contestarlas.




Examen Rápido Formular preguntas y dictárselas a los alumnos para que se respondan.

5 puntos

Total 5 Puntos


Repaso Rápido de los conceptos aprendidos.



2.1.7. DOCUMENTOS


2.2. USANDO RESTRICCIONES (CONSTRAINTS)


Entender algunas restricciones de SQL Server para declarar llaves, o

características especificas del campo de una tabla.


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,


CONSTRAINT PK PRIMARY KEY (CvDepto)

)





A9-EC5 Restricciones CONSTRAINTS


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) Valor actividad: 5 Puntos b) Producto esperado: Una tabla mas a la base de datos “ESQUINITA” c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Individual



Restricciones CONSTRAINTS La tabla creada en la base de datos.

5 puntos

Total 5 puntos


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.7. DOCUMENTOS


2.3. USANDO VALORES POR OMISIÓN Y REGLAS


Aplicar ciertas reglas de negocio desde el momento de creación de las tablas

de la base de datos.


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

el usuario

Regla antigua substituida Sin cambio

Columna Regla antigua substituida 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]'





A10-EC6 Valores por omision.


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)



Valores por omision Checar en la base de datos “ESQUINITA”, las restricciones propuestas.

5 puntos

Total 5 Puntos


Entender que es una regla de negocio y como validarla desde la creación de la

base de datos.



2.3.7. DOCUMENTOS


2.4. INTRODUCCIÓN A INDICES


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 un índice agrupado, se creará de 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.





A11-I1 Investigacion de Indices


Realizar un trabajo de investigación que complemente el tema de indices.

a) Valor actividad: 5 Puntos b) Producto esperado: documento que avale la investigación. c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes)



Investigacion de Indices Contenido de la investigación Presentación del trabajo

4 puntos

1 punto

Total 5 puntos


Entender la importancia del manejo de indices en la optimizacion del tiempo en

las consultas a las tablas indexadas.



2.4.7. DOCUMENTOS


2.5. ARQUITECTURA y CREACIÓN DE INDICES


Aprender a crear indices en las tablas.


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





A12-EC7 Crear Indices


Crear indices compuestos en las tablas de VtaProd(Clave Venta y Clave

Producto) y CpaProd(Clave Compra y Clave Producto)

a) Valor actividad: 5 Puntos b) Producto esperado: Tablas indexadas c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo(3 gentes)



Crear Indices Checar las tablas que efectivamente tengan los indices indicados.

5 puntos

Total 5 Puntos


Manejo de indices



2.5.7. DOCUMENTOS


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


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).





A13-T3 Cuestionario transacciones.



a) Valor actividad: 2.5 Puntos b) Producto esperado: Contestar preguntas de manera escrita c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Individual



Cuestionario transacciones

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

2.5 puntos

Total 2.5 Puntos


Entender la funcion y ventajas de las transacciones en una base de datos



3.1.7. DOCUMENTOS


3.2. CONCEPTOS DE TRANSACCIONES


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.3. PROPIEDADES DE LAS TRANSACCIONES


Conocer cuales son las características especificas de las transacciones.


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 estricta2; 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.





A14-ER3 Examen Rápido.


Formular 5 preguntas de los dos temas anteriores y dictárselas a los alumnos

para que ñas contesten.




Examen Rápido Constestar las preguntas 5 puntos

Total 5 Puntos


Comprobar que los alumnos están captando la importancia de las

transacciones en una base de datos.



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


3.4. PLANES Y RECUPERABILIDAD


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.5. SERIABILIDAD DE PLANES


Proponer un plan de recuperación de información a traves te transacciones.


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 la transacción finaliza, pasa al 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





A15-T4 Cuestionario planes.



a) Valor actividad: 2.5 Puntos b) Producto esperado: Contestar preguntas de manera escrita c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento

f) Tipo de Actividad: Individual



Cuestionario planes


2.5 puntos

Total 2.5 Puntos


Repasar ciertas características de las transacciones



3.5.7. DOCUMENTOS


3.6. TRANSACCIONES SQL


Aprender a crear transacciones en una base de datos.


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‟.

http://www.monografias.com/trabajos15/llave-exito/llave-exito.shtml

http://www.monografias.com/trabajos12/elorigest/elorigest.shtml

http://www.monografias.com/trabajos11/basda/basda.shtml


http://www.monografias.com/trabajos15/llave-exito/llave-exito.shtml


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


SET @ERROR=@@ERROR


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


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


Si la primera sentencia se ejecuta con éxito, pasamos a la segunda


SET @ERROR=@@ERROR

Y si hay un ERROR hacemos como antes


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 a esta idea de 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.

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml

http://www.monografias.com/trabajos16/comportamiento-humano/comportamiento-humano.shtml

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml

http://www.monografias.com/trabajos4/refrec/refrec.shtml

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






COMMIT TRAN TranInterna2




COMMIT TRAN TranExterna


SELECT * FROM Calificacion


@@TRANCOUNT ahora es 1




@@TRANCOUNT ahora es 2.








Reduce @@TRANCOUNT a 2.

Pero no se guarda nada en la base de datos.




Pero no se guarda nada en la base de datos.


COMMIT TRAN TranExterna


Se lleva a cabo la transacción externa y todo lo que conlleva.



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


@@TRANCOUNT ahora es 1











ROLLBACK TRAN

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

internas.



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

http://www.monografias.com/trabajos12/dispalm/dispalm.shtml

http://www.monografias.com/trabajos16/marca/marca.shtml


INSERT INTO Test VALUES (1)

BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.



SAVE TRAN Guardada

BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.



ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.


--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.


COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.

-- Pero no se guarda nada en la base de datos.


COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.

-- Se lleva a cabo la transacción externa y todo lo que conlleva.


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.





A16-EC8 Transacciones.


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)



Transacciones

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

10 puntos

Total 10 Puntos


Validar ciertas reglas de integridad, para evitar inconsistencia de la

información.



http://www.monografias.com/trabajos14/soluciones/soluciones.shtml

3.6.7. DOCUMENTOS


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


Saber controlar algunos aspectos mas importantes de la seguridad que SQL

Server 2000 ofrece.


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)

http://www.sc.ehu.es/jiwibmaj/ApuntesCastellano/TEMA_9-bd.pdf

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.

4 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 a 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.





A17-EC9 Crear usuarios.


Crear 2 tipos de usuario, uno administrador (todos los derechos) y uno general

(solo puede consultar y agregar información).

a) Valor actividad: 5 Puntos b) Producto esperado: Dos usuarios dentro de la base de datos c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Archivo f) Tipo de Actividad: Individual



Crear usuarios

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

5 puntos

Total 5 Puntos


Concesión y renovación de privilegios a los usuarios.



4.1.7. DOCUMENTOS


4.2. TIPOS DE SEGURIDAD


Aplicar los mecanismos de seguridad que SQL Server 2000 ofrece para

aprovecharlos al máximo.


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 de seguridad dependientes de 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



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.


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



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.


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.





A18-EC10 Seguridad de SQL.


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



Seguridad de SQL

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

5 puntos

Total 5 Puntos


Brindarle mayor seguridad a nuestra base de datos.



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.


Poder administrar los derechos y restricciones de los usuarios respecto de las

bases de datos.


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.





A19-T5 Concesion y Renovación de privilegios.


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) Valor actividad: 5 Puntos b) Producto esperado: Tres usuarios en la base de datos c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Archivo f) Tipo de Actividad: Individual



Concesion y Renovación de privilegios.

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

5 puntos

Total 5 Puntos


Saber crear usuarios y poder renovar privilegios asi como quitarlos y agregar

nuevos.


Ayuda de sQL Server 2000

4.3.7. DOCUMENTOS

SQL Server 7.0

4.4. SEGUIMIENTO DE AUDITORIA


Saber cuales son los mecanismos de suguridad que ofracen los manejadores

de basas de datos en este caso SQL Server 2000


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.

5 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 y restablece su 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.





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


Configurar SQL Server para que pueda llevar un registro de todos los

movimientos que los usuarios realicen.

a) Valor actividad: 5 Puntos b) Producto esperado: Reporte de eventos en SQL Server 2000 c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento impreso del reporte f) Tipo de Actividad: Equipo (3 gentes)



Configurar SQL Server para poder supervisar los sucesos.

Checar el reporte impreso que se entrega para verificar que efectivamente este configurado el manejador de base de datos.

5 puntos

Total 5 Puntos


A21-ER4 Examen Rápido de los temas 4.3 y 4.4


Formaular 5 preguntas de los temas mencionados y dictárselas a los alumnos.

g) Valor actividad: Requisito h) Producto esperado: Preguntas contestadas i) Fecha inicio: j) Fecha entrega: k) Forma de entrega: Documento l) Tipo de Actividad: Individual



Examen Rápido Preguntas contestadas Requisito

Total Requisito


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.7. DOCUMENTOS


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


Identificar las características de un sistema de base de datos dentro de una

organización específicamente funciones y ventajas.


5.1.3. DESARROLLO

ESTRUCTURA DE BASES DE DATOS DISTRIBUIDAS

6 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 la posibilidad de 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.





A22-I2 Sistemas en organizaciones.



a) Valor actividad: 5 Puntos b) Producto esperado: Reporte de la investigación c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (5 gentes)



Sistemas en organizaciones Revisar documento que avale la investigación en los negocios de la region

5 puntos

Total 5 Puntos


Saber realmente cuales son los beneficios que los sistemas de información

ofrecen a las empresas.


FUNDAMENTOS DE BASES DE DATOS, Segunda Edición, Henry F. Korth,

Abraham Silberschatz

5.1.7. DOCUMENTOS

5.2. MODELO GENERAL DE UN SGBD


Conocer de manera concreta cuales son las funciones y ventajas de Sistema

de Gestion de Base de Datos (SGBD)


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 Funciones SGBD Componentes SGBD

Descripción unificada e independiente de los datos

Independencia de las aplicaciones

Definición de datos a varios niveles:

Esquema lógico

Esquema interno

Lenguajes de definición de esquemas y traductores asociados.

7 http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf (03/Ago/05)

http://www.dsic.upv.es/~emarzal/bda/Tema3a.pdf

Definición de vistas parciales

Gestión de la información Integridad y seguridad de los datos

Esquemas externos Manipulación de los datos:

Consulta

Actualización Gestión y administración de la base de datos Control de:

Integridad semántica

Accesos concurrentes

Reconstrucción en caso

de fallo

Seguridad (privacidad)

Lenguajes de manipulación y traductores asociados. Herramientas para:

Reestructuración

Simulación

Estadísticas

Impresión 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





A23-ER5 Examen Rápido de SGBD.


Realizar un cuestionario de 5 preguntas del tema 5.2 y dictárselas a los

alumnos para que las contesten.

a) Valor actividad: 5 Puntos b) Producto esperado: Preguntas contestadas c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Individual



Examen Rápido de SGBD


5 puntos

Total 5 Puntos


Reafirmar los conceptos básicos de un SGBD



5.2.7. DOCUMENTOS

5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y

RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS.


Entender el mecanismo de las consultas distribuidas.


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 deposito1 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 Ld 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 r1 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 L1. 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 L1, 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 ∩ R2 (r1))|X| r2

como r1 |X| II (R1 ∩ 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 Li, 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 Li 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 Lk 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 Li 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 la 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, Ci

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 se eleva automáticamente a

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 y 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

8 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 he 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 distinto-

En 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.





A24-EC11 Realizacion de una Base de Datos Distribuida.


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)

http://www.configuracionesintegrales.com/miguele/trdissqlserver.asp?articulo=149

hacer una consulta a una tabla que este en el servidor donde yo no este

trabajando.

a) Valor actividad: 30 Puntos b) Producto esperado: Base da tos distribuida c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Base de datos. f) Tipo de Actividad: Equipo (5 gentes)



Realizacion de una Base de Datos Distribuida

Estructura de la base de datos Configuración de los servidores Conexion de los servidores Pruebas a la base de datos

5 puntos

5 puntos

10 puntos

10 puntos

Total 30 Puntos


Verificar las ventajas que ofrece una Base de Datos Distribuida a diferencia de

una Base de datos Relacional.



5.3.7. DOCUMENTOS


UNIDAD TEMATICA 6. TECNOLOGÍAS DE ACCESO A DATOS

6.1. ARQUITECTURAS MULTICAPA y XML


Entender el funcionamiento del lenguaje XML


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

10

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 la sede web de Microsoft

http://msdn.microsoft.com/workshop/xml/articles/xmlsql/). Otra manera de

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 a SQL Server a 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 o Extensión del lenguaje de 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 en consultas como en

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 los datos XML: sp_xml_preparedocument,

sp_xml_fetchdocument, 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) y recuperar documentos mediante un 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





A25-ER6 Examen Rápido XML.


Formular 5 preguntas del tema y dictárselas a los alumnos para que se

resuelvan.




Examen Rápido XML Formular preguntas y dictárselas a los alumnos para que se resuelvan.

5 puntos

Total 5 Puntos


Entender claramente el lenguaje XML


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.


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.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 obtener más

información sobre la compatibilidad con BackOffice.

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.

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 ve Emergente Sí Todas

RDO VB,VJ Actual No La mayoría

ODBe Ve,VB Actual No Todas

DAO VB,Ve Actual No Limitadas

DB-Library VB,Ve Heredada No Limitadas

VB-SQL oex VB Heredada No Limitadas

SQL incrustado ve Heredada No Limitadas

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)

http://www.etse.urv.es/EngInf/assig/ens4/2004/net4a.pdf

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 y 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 de rendimiento y confiabilidad, se 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.


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:

o 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.

o 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.

o 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, no 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 de Microsoft SQL Server Technical Support en

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.


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.

http://microsoft.com/odbc/

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


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.

<%



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:

<%



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



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:

<%


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



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:


cn.ConnectionTimeout = 20


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.





A26-EC12 Manejo de Bases de Datos atraves de ADO.


Realizar una aplicación que manipule una base de datos utilizando la

tecnología de acceso ADO.

a) Valor actividad: 10 Puntos b) Producto esperado: Aplicacion c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Archivo f) Tipo de Actividad: Equipo (5 gentes)



Manejo de Bases de Datos atraves de ADO

Aplicación que manipula una Base de Datos en cualquier lenguaje de programación

10 puntos

Total 10 Puntos


Aprender a utilizar una tecnología de acceso a datos



6.2.7. DOCUMENTOS

6.3. JDBC, PAGINAS DEL SERVIDOR JAVA.


Aprender de forma general las característica del manejador de Base de Datos

para Java (JDBC).


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





A27-I7 JDBC.


Hacer una investigación de complemento al tema de JDBC.

a) Valor actividad: 5 Puntos b) Producto esperado: Investigación c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (3 gentes)



JDBC

Documento que avale la investigacón, el documento debe contener fuentes bibliograficas

5 puntos

Total 5 Puntos


Conocer las características generales de JDBC


http://www2.terra.com/informatica/que-es/jdbc.cfm

6.3.7. DOCUMENTOS

13

http://www2.terra.com/informatica/que-es/jdbc.cfm (05-Ago-05)



UNIDAD TEMATICA 7. PROYECTO FINAL


PONER EN PRACTICA TODO LO APRENDIDO EN ESTA MATERIA


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




A28-T7 Análisis del sistema.


Realizar el análisis del negocio para poder definir la base da datos (Los puntos

a cubrir que a disposición del docente)

a) Valor actividad: 10 Puntos b) Producto esperado: Análisis del Sistema c) Fecha inicio: d) Fecha entrega: e) Forma de entrega: Documento f) Tipo de Actividad: Equipo (4 gentes)



Análisis del sistema Debe cubrir con todos los puntos que el docente disponga

10 puntos

Total 10 Puntos


A29-T8 Diseño de la Base de Datos.


Diseñar la Base de Datos en base al análisis hecho en la practica anterior.

g) Valor actividad: 15 Puntos h) Producto esperado: Base de Datos i) Fecha inicio: j) Fecha entrega: k) Forma de entrega: Archivo l) Tipo de Actividad: Equipo (4 gentes)



Diseño de la Base de Datos

La Base de Datos debe de estar normalizada y debe de cubrir con todos los aspectos del negocio

15 puntos

Total 15 Puntos


A30-T9 Reglas de Negocio.


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) Valor actividad: 20 Puntos n) Producto esperado: Reglas del negocio aplicadas o) Fecha inicio: p) Fecha entrega: q) Forma de entrega: Archivo r) Tipo de Actividad: Equipo (4 gentes)



Reglas de Negocio Las reglas deben de estar aplicadas

20 puntos

Total 20 Puntos


A31-T10 Sistema de Base de Datos.


En cualwuier lenguaje de programación, realizar la aplicación que interacte con

la base de datos.

s) Valor actividad: 10 Puntos t) Producto esperado: Sistema de Base de Datos u) Fecha inicio: v) Fecha entrega: w) Forma de entrega: Archivo x) Tipo de Actividad: Equipo (4 gentes)



Sistema de Base de Datos Checar que el sistema cumpla con las especificaciones necesarias

10 puntos

Total 10 Puntos


Conocer el negocio del cual se va a realizar el diseño de la base de datos


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, PRENTICE-

HALL , Segunda edición.

7.1.7. DOCUMENTOS

ANEXO A

BASE DE DATOS II


RESUMEN DE ACTIVIDADES DE APREDIZAJE

MES 1

Actividad de

Aprendizaje

Fecha de

Inicio

Fecha de

Entrega Puntuación

A1-T1 Cuestionario. 5 puntos

A2-T2 Realizar Base de Datos 5 Puntos

A3-EC1 Sentencias SQL “Tablas

Multiples” 10 puntos

A4-ER1 Examen Rápido. 10 Puntos

A5-EC2 Procedimientos

Almacenados 10 Puntos

A6-EC3 Procedimientos de

disparo 10 Puntos

A7-EC4 Vistas 10 Puntos

Subtotal 60 Puntos

Examen 40 Puntos

Puntaje total del mes: 100 Puntos

MES 2

Actividad de

Aprendizaje

Fecha de

Inicio

Fecha de

Entrega Puntuación

A8-ER2 Examen Rápido 5 Puntos

A9-EC5 Restricciones

CONSTRAINTS 5 Puntos

A10-EC6 Valores por omision 5 Puntos

A11-I1 Investigacion de

Indices 5 Puntos

A12-EC7 Crear Indices 5 Puntos

A13-T3 Cuestionario

transacciones 2.5 Puntos

A14-ER3 Examen Rápido 5 Puntos

A15-T4 Cuestionario planes 2.5 Puntos

A16-EC8 Transacciones 10 Puntos

A17-EC9 Crear usuarios 5 Puntos

A18-EC10 Seguridad de SQL 5 Puntos

A19-T5 Concesion y Renovación

de privilegios 5 Puntos

Subtotal 60 Puntos

Examen 40 Puntos


MES 3

Actividad de

Aprendizaje

Fecha de

Inicio

Fecha de

Entrega Puntuación

A20-T6 Configurar SQL Server

para poder supervisar los

sucesos

5 Puntos

A21-ER4 Examen Rápido de los

temas 4.3 y 4.4 Requisito

A22-I2 Sistemas en

organizaciones 5 Puntos

A23-ER5 Examen Rápido de SGBD 5 Puntos

A24-EC11 Realización de una

Base de Datos Distribuida. 30 Puntos

A25-ER6 Examen Rápido XML 5 Puntos

A26-EC12 Manejo de Bases de

Datos a través de ADO 10 Puntos

Subtotal 60 Puntos

Examen 40 Puntos


MES 4

Actividad de

Aprendizaje

Fecha de

Inicio

Fecha de

Entrega Puntuación

A27-I7 JDBC 5 Puntos

A28-T7 Análisis del sistema 10 Puntos

A29-T8 Diseño de la Base de

Datos. 15 Puntos

A30-T9 Reglas de Negocio. 20 Puntos

A31-T10 Sistema de Base de

Datos. 10 Puntos

Subtotal 60 Puntos

Examen 40 Puntos


Claves de apoyo:

A: Actividad (A#-Tipo#) T: Tarea

I: Investigación EC: Ejercicios en clases ER: Examen Rápido

ANEXO B

BASE DE DATOS II


RESUMEN DE ACTIVIDADES DE SESIONES

MES 1

Fecha de la

sesión Tema

No.

Hrs.

1.1. LA VENTAJA DEL SQL

1.2. CONSULTA DE UNA SOLA TABLA

1.3. CONSULTA DE TABLAS MULTIPLES

1.4. CONSULTAS ANIDADAS O CONSULTAS AVANZADAS O

SUBCONSULTAS

1.5. PROCEDIMIENTOS ALMACENADOS

1.6. TRIGGERS

1.7. VISTAS

1

2

3

5

6

7

6

SUBTOTAL DE

HRS FRENTE A

GRUPO

28

HORAS

EXTRACLASE 0

TOTAL DE HRS

AUTORIZADAS 28

MES 2

Fecha de la

sesión Tema

No.

Hrs.

2.1. TIPOS DE INTEGRIDAD DE DATOS

2.2. USANDO RESTRICCIONES (CONSTRAINTS)

2.3. USANDO VALORES POR OMISIÓN Y REGLAS

2.4. INTRODUCCIÓN A INDICES

2.5. ARQUITECTURA y CREACIÓN DE INDICES

3.1. PROCESAMIENTO DE TRANSACCIONES

3.2. CONCEPTOS DE TRANSACCIONES

3.3. PROPIEDADES DE LAS TRANSACCIONES

3.4. PLANES Y RECUPERABILIDAD

3.5. SERIABILIDAD DE PLANES

3.6. TRANSACCIONES SQL

4.1. SEGURIDAD y AUTORIZACIÓN EN BASES DE DATOS

4.2. TIPOS DE SEGURIDAD

4.3. CONTROL DE ACCESO DISCRECIONAL BASADO EN CONCESIÓN /

RENOVACION DE PRIVILEGIOS.

1

2

4

1

3

½

½

1

1

1

8

1

2

2

SUBTOTAL DE

HRS FRENTE A

GRUPO

28

HORAS

EXTRACLASE 0

TOTAL DE HRS

AUTORIZADAS 28

MES 3

Fecha de la

sesión Tema

No.

Hrs.

4.4. SEGUIMIENTO DE AUDITORIA

5.1. SISTEMAS DE BASES DE DATOS EN LAS ORGANIZACIONES

5.2. MODELO GENERAL DE UN SGBD

5.3. PROCESAMIENTO DE CONSULTAS, CONCURRENCIA y

RECUPERACIÓN EN BASES DE DATOS DISTRIBUIDAS.

6.1. ARQUITECTURAS MULTICAPA y XML

6.2. TECNOLOGÍAS DE ACCESO A DATOS: ODBC, OLEDB, ADO y

ASP.

2

2

1

7

4

12

SUBTOTAL DE

HRS FRENTE A

GRUPO

28

HORAS

EXTRACLASE 0

TOTAL DE HRS

AUTORIZADAS 28

MES 4

Fecha de la

sesión Tema

No.

Hrs.

6.3. JDBC, PAGINAS DEL SERVIDOR JAVA.

PROYECTO FINAL

5

16

SUBTOTAL DE

HRS FRENTE A

GRUPO

21

HORAS

EXTRACLASE 0

TOTAL DE HRS

AUTORIZADAS 21

base de datos

Documents

esperamos

resultado

tecnologas

material de

contener datos

reflejar la

bases de datos

integridad