Libro Tecnologias Modernas de BD

INSTITUTO TECNOLGICO DE CUAUTLA
TECNOLOGAS MODERNAS DE BASE DE DATOS

Dr. ZAVALETA OLEA EDIRAY.
LIBRO
ALUMNOS:
CORTS MENDOZA ANA KAREN 0868015 L!EZ CABRALES LUIS ALBERTO 086801 5 MARTNEZ CARI"O CONRADO 086801 8 RIVERA BARRANCO GABRIEL 08680#$1
%. %. CUATLA MOR. A 0& DE MAYO DE #01#
NDICE
Pginas
CAPTULO 1 Conceptos De Base De Datos Multiusuario ................................................................. 1 1.1 Base de Datos Multiusuario .................................................................................................. 1 1.2 Arquitectura Cliente Servidor ............................................................................................... 1 1. Caracter!sticas de los Servidores de Base de Datos ............................................................... 1." #nteracci$n Cliente Servidor en Siste%as De Base De Datos .................................................. " Pr&ctica de Conectividad Cliente'Servidor con M(S)L ................................................................ * CAPTULO 2 Con+ia,ilidad en la Base de Datos -#nte.ridad ( Se.uridad/ ....................................... 12 2.1 #nte.ridad .......................................................................................................................... 12 2.1.1 Concepto de #nte.ridad ............................................................................................... 12 2.1.2 0e.las de #nte.ridad Do%inio10elaci$n ....................................................................... 12 2.1. Mecanis%os de 2istas para la i%ple%entaci$n de #nte.ridad ................................ 1*
2.2 Se.uridad ........................................................................................................................... 13 2.2.1 #denti+icaci$n ( Autenti+icaci$n. ................................................................................... 13 2.2.2 Matri4 de Autori4aci$n................................................................................................. 15 2.2. De+inici$n de un 6sque%a de Se.uridad ...................................................................... 17 2.2." Mecanis%os de 2istas para la #%ple%entaci$n de Se.uridad. ............................... 18
2.2.* Bases de Datos 6stad!sticas.......................................................................................... 21 2. Mecanis%os de Protecci$n Contra #n(ecci$n S)L. .............................................................. 22 Pr&ctica Mecanis%os de 2istas para la #nte.ridad de la Base de Datos ..................................... 2 Pr&ctica de Sentencias S)L para la #nte.ridad de la Base de Datos ........................................... 2* CAPTULO Ad%inistraci$n de Transacciones .............................................................................. 5 .1 Transacciones..................................................................................................................... 5 .2 Tipos de +allas .................................................................................................................... 7 . 0ecuperaci$n -recovery/ ..................................................................................................... "9 ." Concurrencia ...................................................................................................................... "1 .* Pro,le%as que se presentan -actuali4aci$n: p;rdida: etc./.................................................. " .3 Candados ........................................................................................................................... " .5 Deadloc< ............................................................................................................................ "" Pr&ctica de =esti$n de Transacciones con M(S)L .................................................................... "7 CAPTULO " Modelo de Capas para el Procesa%iento de Base de Datos....................................... *
".1 Conceptos: %odelos ( tecnolo.!as ...................................................................................... * ". 2 Tecnolo.!as de conectividad de ,ase de datos ................................................................... ** ". Acceso a ,ases de datos con otros servicios de internet ..................................................... 32 "." Arquitectura de servicios a,iertos ...................................................................................... 35 ".".1 ODBC. .......................................................................................................................... 35 ".".2 >DBC ............................................................................................................................ 38 ".". #DAP# ........................................................................................................................... 5* ".* CO0BA................................................................................................................................ 53 ".*.1 Arquitectura de CO0BA. .............................................................................................. 55 ".*.2 6l Len.ua?e de de+inici$n de #nter+aces. ....................................................................... 57 ".*. Pro.ra%aci$n en CO0BA.............................................................................................. 58 ".*. .1 6L Preco%pilado #DL para >ava .................................................................................. 79 ".*. .2 A.re.ar la #%ple%entaci$n del O,?eto. ..................................................................... 71 ".*. . Construcci$n del cliente ( co%pilaci$n de todos los co%ponentes. ..................... 72
".*." 6?ecuci$n del cliente ( el servidor. ............................................................................... 7 ".*.* An&lisis ( dise@o de aplicaci$n. ......................................... 'Err(r) M*r+*,(r -( ,./0-0,(. ".*.*.1 Aivel Conceptual............................................................ 'Err(r) M*r+*,(r -( ,./0-0,(. ".*.*.2 Aisla%iento de la =U# de la %anipulaci$n datos. ............ 'Err(r) M*r+*,(r -( ,./0-0,(. ".*.*. Aplicaci$n Coordinador Multicliente. ............................ 'Err(r) M*r+*,(r -( ,./0-0,(. ".*.*." 6?ecuci$n del siste%a %ultiClient. .................................. 'Err(r) M*r+*,(r -( ,./0-0,(. ".*.3. Conclusiones ................................................................... 'Err(r) M*r+*,(r -( ,./0-0,(. Practica Carrito de Co%pras ..................................................................................................... 7" Practica de Uso de Berra%ienta CAS6 para .enerar c$di.o S)L desde un dia.ra%a 6'0 .r&+ico.81 Practica 2olcado ...................................................................................................................... 83 CAP#TULO * Auevos Desarrollos en Bases de Datos .....................................................................199 *.1 Auevos %odelos de ,ases de datos ...................................................................................199 *.2 Bases de datos en %Cltiples servidores .............................................................................19" *. Transacciones distri,uidas.................................................................................................193 *." #nteropera,ilidad ..............................................................................................................119 *.* Auevas tecnolo.!as. ..........................................................................................................111
PROLOGO
El motivo de este libro fue diseado para la materia de nuevas tecnologas de base de datos del plan semestral de la carrera de ingeniera en sistemas computacionales. Al impartir el curso se encontr que se inverta demasiado tiempo en la busque da informacin en el desarrollo de las practicas debido a la falta de entrenamiento en el desarrollo de base de datos. En el desarrollo del curso muy pocos alumnos podan implementar las prcticasy los restantes no lograron realizarlas. Por lo cual se cre este libro para mejorar el desarrollo de la prctica de esta materia. Este libro est conformado por 5 captulos de acuerdo al temario de la materia, en el captulo1Conceptos de Bases de Datos multi-usuario (cliente-servidor), en este captulo se definen los conceptos bsicos para las base de datos multiusuario, los conceptos relacionados con la arquitectura cliente servidor, adems de describir caractersticas de los servidores de base de datos, as como su interaccin. Se describe la realizacin de una prctica utilizando el servidor de base de datos Mysql con respecto a este tema con el fin de reforzar su aprendizaje. En el captulo 2Confiabilidad en la Base de Datos (integridad y seguridad), se describe el concepto de integridad, as como las reglas dominio-relacin y los mecanismos de vistas para implantacin en Mysql . Con respecto a seguridad se tratan los temas de identificacin y autentificacin definiendo un esquema de seguridad y mecanismos de vistas para la implantacin de seguridad, bases de datos estadsticas y mecanismos de proteccin contra la inyeccin SQL. La seguridad e integridad sern ilustradas mediante el desarrollo de un caso prctico. En el captulo 3 administracin de transacciones. En este captulo describe los conceptos para la gestin de transacciones por ejemplo de los tipos de fallas, recuperacin, concurrencia, los problemas que se presentan en la realizacin de las transacciones y a su vez la implementacin de candados, para evitar los bloqueos (Deadlocks), as como de las tcnicas para prevenirlo y deshacerlo. Se describe la realizacin de una prctica que implica el uso de transacciones usando candados para mantener la integridad de la base de datos. En el captulo 4Modelo de Capas para el Procesamiento de Base de Batos. Este captulo contiene cuatro subtemas, en el primer subtema se vern los conceptos de procesamiento de base de datos, a continuacin se vern los modelos de capas y las tecnologas correspondientes a cada uno de ellos; el segundo subtema comprende las tecnologas de conectividad de bases de datos, en l se tocaran ODBC y JDBC; en el subtema tres se ver
cmo acceder a bases de datos con otros servicios en internet, por ltimo se ver la arquitectura de servicios abiertos especficamente ODBC,JDBC y IDAPI. Posteriormente en el CAPITULO 5Nuevos Desarrollos en Bases de Datos, se describirn algunos de los nuevos desarrollos en bases de datos, tales como: los Nuevos Modelos de Base de Datos, los desarrollos de Bases de Datos en Mltiples Servidores, se explicaran lo que son Transacciones Distribuidas y la interoperabilidad, se citaran algunas de las Nuevas Tecnologas para trabajar con Bases de Datos. En este captulo tambin se presentara una prctica en la cual se palpan los puntos antes mencionados y los lineamientos para la entrega del reporte de las prcticas del l curso.
CAPTULO 1 CONCEPTOS DE BASE DE DATOS MULTIUSUARIO 1.1 Base de Datos Multiusuario

La palabra multiusuario surgi del concepto de sistemas operativos, pero actualmente se aplicar a los servidores de otro tipo (ej. aplicaciones de base de datos). En general se le llama multiusuario a la caracterstica de un sistema operativo o programa que permite proveer servicio y procesamiento a mltiples usuarios simultneamente (tanto en paralelismo real como simulado). En las base de datos las operaciones son referentes a la definicin y a la manipulacin de los datos presentes en una o ms base de datos, sin preocuparnos del hecho de que normalmente el acceso a tales datos se produce al mismo tiempo por parte de muchos usuarios. Los mecanismos que hay que tener en cuenta para este mtodo de acceso se refieren principalmente a la seguridad de los datos, la gestin de las transacciones y la posibilidad de definir las vistas en las tablas de la base de datos.
1.2 Arquitectura Cliente Servidor

La arquitectura cliente-servidor es un modelo utilizado el desarrollo de aplicacin distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que le proporciona la respuesta. Con respecto a la definicin de arquitectura cliente/servidor se encuentran las siguientes definiciones: Cualquier combinacin de sistemas que pueden colaborar entre s para dar a los usuarios toda la informacin que ellos necesiten sin que tengan que saber dnde est ubicada. Es una arquitectura de procesamientos cooperativa donde uno de los componentes pide servicios a otro. Es un procesamiento de datos de ndole colaborativo entre dos o ms computadoras conectadas a una red.
El trmino cliente/servidor es originalmente aplicado a la arquitectura de software que describe el procesamiento entre dos o ms programas: una aplicacin y un servicio soportante.
IBM define al modelo Cliente/Servidor. "Es la tecnologa que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cmputo o cualquier otro recurso del grupo de trabajo y/o, a travs de la organizacin, en mltiples plataformas. El modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes'', resultan en un trabajo realizado por otros computadores llamados servidores".
"Es un modelo para construir sistemas de informacin, que se sustenta en la idea de repartir el tratamiento de la informacin y los datos por todo el sistema informtico, permitiendo mejorar el rendimiento del sistema global de informacin".
Elementos principales "Los elementos principales de la arquitectura cliente servidor son justamente el elemento llamado cliente y el otro elemento llamado servidor". Por ejemplo dentro de un ambiente multimedia, el elemento cliente seria el dispositivo que puede observar el vdeo, cuadros y texto, o reproduce el audio distribuido por el elemento servidor. Por otro lado el cliente tambin puede ser una computadora personal o una televisin inteligente que posea la capacidad de entender datos digitales. Dentro de este caso el elemento servidor es el depositario del vdeo digital, audio, fotografas digitales y texto y los distribuye bajo demanda de ser una mquina que cuenta con la capacidad de almacenar los datos y ejecutar todo el software que brinda stos al cliente. En resumen se puede definir lo siguiente: C/S es una relacin entre procesos corriendo en mquinas separadas El servidor (S) es un proveedor de servicios. El cliente (C) es un consumidor de servicios. C y S Interactan por un mecanismo de pasaje de mensajes: Pedido de servicio y Respuesta.
1.3 Caractersticas de los Servidores de Base de Datos

Los servidores de bases de datos surgen con motivo de la necesidad de las empresas de manejar grandes y complejos volmenes de datos, al tiempo que requieren compartir la informacin con un conjunto de clientes (que pueden ser tanto aplicaciones como usuarios) de una manera segura. Ante este enfoque, un sistema gestor de bases de datos deber ofrecer soluciones de forma fiable, rentable y de alto rendimiento. A estas tres caractersticas, le debemos aadir una ms: debe proporcionar servicios de forma global y, en la medida de lo posible, independientemente de la plataforma. En este libro hablaremos del servidor MySQL fue desarrollado originalmente para manejar grandes bases de datos mucho ms rpido que las soluciones existentes y ha estado siendo usado exitosamente en ambientes de produccin sumamente exigentes por varios aos. Aunque se encuentra en desarrollo constante, el servidor MySQL ofrece hoy un conjunto rico y til de funciones. Su conectividad, velocidad, y seguridad hacen de MySQL un servidor bastante apropiado para acceso a bases de datos en Internet. El software de bases de datos MySQL consiste de un sistema cliente/servidor que se compone de un servidor SQL multi hilo, varios programas clientes y bibliotecas, herramientas administrativas, y una gran variedad de interfaces de programacin (APIs). Se puede obtener tambin como una biblioteca multihilo que se puede enlazar dentro de otras aplicaciones para obtener un producto ms pequeo, ms rpido, y ms fcil de manejar.
Caractersticas de MySQL
Es muy rpido Administracin por consola o por herramientas grficas Es seguro Es fcil de usar Maneja grandes bases de datos Cuenta con varios programas cliente y bibliotecas Cuenta con varias herramientas grficas administrativas Cuenta con una gran variedad de Interfaces de programacin programable (APIs) Licencia GPL Mejor integracin con PHP No hay lmite en el tamao de los registros
Consume muy pocos recursos, tanto de CPU como de memoria Cuenta con un mejor control de acceso, es decir, se puede definir qu usuarios tienen acceso a que tablas y con qu permisos.
1.4 Interaccin Cliente Servidor en Sistemas De Base De Datos

El almacenamiento y gestin del acceso a los datos los realiza el gestor (el servidor). Los gestores de bases de datos relacionales tambin se conocen como servidores SQL, por ser ste el lenguaje que se utiliza para acceder a los datos. Oracle, IBM DB2, InterBase y SQL Server entran dentro de esta categora. Las aplicaciones de los usuarios (los clientes) hacen peticiones al servidor utilizando algn protocolo predefinido, CLI [Call-Level-Interface] en ingls, que puede ser un estndar (ODBC, JDBC o BDE) o especfico de la base de datos que utilicemos. Como es lgico, varios usuarios situados en distintos puestos de trabajo de una red pueden compartir el mismo servidor SQL, que ser el responsable de mantener la "acidez" de las transacciones [Atomicity-Consistency-Isolation-Durability].
Figura 1.1 Interaccin Cliente Servidor en Base de Datos
"
Prctica No 1 Conectividad Cliente-Servidor con MySQL

Objetivo de la prctica: Al trmino de la prctica el alumno el alumno podr realizar la configuracin para la conectividad Cliente-Servidor con MySQL. Materiales, equipo y software necesarios En esta prctica se utilizar el siguiente equipo: 1. Una red ad-hoc para las pruebas en red de con conexin inalmbrica, formado por un servidor y un conjunto de maquinas cliente.. 2. As mismo un servidor MySQL, por utilidad se utilizar WAMP que posee ms utilidades que MySQL nicamente. Como primer paso la creacin de la red ad-hoc: 1. Ir a panel de control centro de redes y recursos compartidos. 2. Administrar redes inalmbricas - agregar 3. Seleccionar red ad-hoc 4. Dar un nombre a la red y clave de seguridad. 5. Guardar. En la maquina cliente se debe est conectado a la red prueba2 creada en el servidor y se puede hacer ping al servidor, (es necesario configurar una IP esttica tanto en servidor como cliente) la IP del servidor es 192.168.1.8 y la del cliente es 192.168.1.3 . Una vez que se ha establecido la conexin entre el cliente y el servidor SQL previamente instalado, se abre el navegador de internet y se escribe en la barra de direcciones: http://localhost/phpmyadmin/. Se procede a editar los usuarios para que puedan acceder a MySQL a travs de la red, para ello nos apoyamos en la herramienta PHPmyAdmin del servidor. Una vez abierta la interfaz damos clic en la pestaa localhost para poder ver las bases de datos existentes en el servidor.Posteriormente creamos una Base de Datos a la cual accederemos de forma remota (a travs del cliente) para poder interactuar con ella (dependiendo de los privilegios que se le otorguen). 1. Le damos un nombre en nuestro caso se llamar BDPrueba. 2. Damos clic en crear
Una vez ya creada nuestra base de datos, procederemos a crear los usuarios que podrn conectarse a ella. A continuacin nos ubicamos en la pestaa Privilegios en donde podremos ver la lista de los usuarios existentes actualmente en nuestro sistema. Una vez ubicados en la pestaa daremos clic en la opcin Agregar un nuevo usuario ubicada en la parte inferior de la interfaz, donde nos desplegar un men para proporcionarle los datos correspondientes del usuario. Una vez desplegado el formulario llenamos los campos con la informacin pertinente para nuestro usuario.El nombre del usuario con el que se conectar el cliente de forma remota al servidor MySQL. 1. La IP a travs de la cual se conectar de forma remota al servidor (el cliente), en este caso es 192.168.1.8. 1. La contrasea con la cual acceder el usuario que estamos creando. 2. Confirmacin de la contrasea. 3. Clic en el botn Crear Usuario para agregar al nuevo usuario. Nos debe aparecer el usuario que acabamos de crear, en este caso es gabo: Procedemos a continuacin a asignarle los permisos a nuestro usuario recin creado, para ello nos ubicamos en la lista donde esta nuestro usuario y damos clic en la opcin Editar privilegios, donde posteriormente se desplegara un formulario correspondiente a los privilegios de dicho usuario.
Figura1. 2. Creacin del usuario del Mysql Procedemos a seleccionar los privilegios que queremos otorgar al usuario, basta con marcar la casilla correspondiente al privilegio que queramos, en este caso se le permitirn todos los privilegios sobre la base de datos que creamos, inclusive la posibilidad de crear otras bases de datos como se mostrara posteriormente en el lado del cliente (ver figura 12). Una vez hecho todo lo anterior procedemos a conectarnos a la base de datos desde el cliente, de esta manera: 1. Abrir cmd de Windows 2. Escribir (en nuestro caso) mysql h 192.168.1.8 u gabo p 3. Escribir el password del usuario 4. Con esto ya estaremos conectados como si estuviramos en el servidor.
Figura 1.3. Conexin mySql Una vez dentro de MySQL se procede a crear la base de datos escuela mediante el comando: mysql> create database escuela; y posteriormente se cambia a esta base con el comando: mysql> use escuela;
Figura 4. Creacin de base datos Mysql.
Ahora se creara una tabla alumnos (en nuestro caso) con los campos nombre y nmero_control, registrando en dichos campos nuestros datos tanto nombre completo y numero de control: mysql> create table alumnos (nombre varchar(50), no_control varchar(8)); mysql> insert into alumnos values (gabriel rivera barranco, 08680241), (Conrado martinez cario, 08680198);
Figura 1.4. Insercin registros tabla. Verificamos que se insertaron los datos (Ver figura 16). mysql> select * from alumnos; En esta ocasin y como nuestro usuario posee los privilegios necesarios crearemos otros usuarios desde el cliente en nuestro servidor para comprobar tanto la forma de crearlos as como la utilidad que esto conlleva (ver figura 17).Luego de estar logeado como usuario con privilegios (en este caso si) crearemos un usuario nuevo con la siguiente lnea: mysql> create user alberto@192.168.1.3 identified by 1234567890;
Figura 1.5. Creacin de usuarios en Mysql En la figura 18, se muestra como se crea un usuario llamado Alberto que se conectar desde la IP sealada, ahora procedemos a darle privilegios dentro de nuestro servidor, en este caso le daremos todos los privilegios (ver figura 19). mysql> grant all privileges on *.* to alberto@192.168.1.3; Ahora salimos del shell de mysql para acceder nuevamente pero utilizando el usuario que acabamos de crear (ver figura 20).Estando logeados con el usuario que accedimos probamos viendo las tablas existentes (ver figura 21). Una vez que el cliente termina de modificar la base de datos de forma remota accederemos a la consola de MySQL para comprobar que las modificaciones realizadas si surtieron efecto en el servidor. Damos clic en los servicios de WAMP y seleccionamos la consola de MySQL. Una vez que entremos en el Shell de MySQL cambiamos la base de datos en uso.
mysql> use escuela;
19
mysql> show tables;

En este caso sera escuela que fue creada de forma remota por el cliente (porque en este caso posee todos los privilegios el usuario que creamos), podremos ver las tablas creadas de forma remota en este caso solo se cre la tabla alumnos (ver figura 24). Haremos una consulta general de la tabla para ver los datos que inserto el cliente y corroboramos que efectivamente la conexin de forma remota al servidor MySQL fue exitosa. Mediante el comando:
mysql>select * from alumnos;
11
CAPTULO 2 CONFIABILIDAD EN LA BASE DE DATOS (INTEGRIDAD Y SEGURIDAD)
2.1 Integridad
La palabra integridad se toma de la palabra integrtas significa cualidad de ntegro. A partir de esto la integridad en una base de datos se refiere a la correccin y exactitud de la informacin contenida. Una base de datos determinada podra estar sujeta a cualquier cantidad de restricciones de integridad (en general) de una complejidad arbitraria. En la mayora de los sistemas actuales, la verificacin de la integridad se realiza mediante cdigos de procedimientos escritos por los usuarios. Algunos ejemplos de restricciones de integridad seran: Los dueos de cuentas de ahorro no pueden solicitar un monto mayor de dinero del que hayan juntado hasta la fecha. Para que un cliente sea considerado especial, deber tener un mnimo de USD 1.000 en compras promedio al ao. La Integridad es el trmino utilizado para decir que la informacin almacenada tiene calidad. El DBMS tiene que asegurar que los datos se almacenan de acuerdo a las polticas previamente determinadas por el DBA (Data Base Administrator). En otras palabras, el DBMS debe principalmente, a este respecto, comprobar las restricciones de integridad, controlar la correcta ejecucin de las actualizaciones y recuperar la base de datos en caso de prdida. La Integridad conserva la seguridad en un sistema de bases de datos que permite el acceso a mltiples usuarios en tiempos paralelos.Un control de integridad o restriccin es aquel que nos permite definir con precisin el rango de valores vlidos para un elemento y/o las operaciones que sern consideraciones vlidas en la relacin de tales elementos.
2.1.2 Reglas de Integridad Dominio/Relacin Reglas de Integridad - Dominio

Un Dominio de valores posibles puede estar asociado a cada atributo. Los lmites de Dominio son la forma ms elemental de restricciones de Integridad. Son fciles de probar en el sistema siempre que se introduce un nuevo dato en el sistema.
12
Tipos de Datos en SQL

Dato Bit Byte Counter Currency Datetime Text Longitud 1 byte 1 byte 4 bytes 8 bytes 8 bytes 1 byte/carcter Descripcin Valores true/false Entero entre 0 y 255 Campo ID (long) Numrico Fecha De 0 a 255 caracteres
Una definicin bien adecuada de restricciones de dominio no slo nos permite probar valores insertados en la base de datos. Tambin nos permite probar consultas para asegurarnos de que las comparaciones que se hacen tienen sentido.
Reglas de Integridad - Relacin

Las reglas de Integridad de relacin son restricciones que se deben cumplir en todas las bases de datos relacionales y en todos sus estados o instancias, es decir, se deben cumplir todo el tiempo. Existen bsicamente dos reglas de Integridad asociadas con el modelo relacional: la Integridad de Entidad y la Integridad Referencial. Estas dos reglas son generales y tienen relacin con las llaves primarias y forneas.
Integridad de Entidad
Las restricciones de entidades aseguran la integridad de las entidades que son modeladas por el sistema. En el nivel ms simple, la existencia de una clave principal es una restriccin de entidad que impone la regla "cada entidad debe estar identificada de forma nica". En esta no est permitido que algn componente de la clave primaria acepte valores nulos. Las razones de esta regla son: Las tuplas en las relaciones base representan entidades en la realidad. Las entidades en la realidad son identificables por definicin. Sus contrapartes en la base de datos tambin deben ser identificables. Los valores de la clave primaria sirven como identificadores en la base de datos. Los valores de clave primaria no pueden ser nulos.
Integridad Referencial
La regla de Integridad referencial define que la base de datos no debe contener valores de claves forneas sin concordancia .Esta regla se aplica a las claves forneas. Si en una relacin hay alguna clave fornea, entonces sus valores deben coincidir con los valores de la clave primaria a la que hace referencia, o bien, debe ser completamente nulo. Esta regla impide que, por ejemplo, en una base de datos acadmica, exista un profesor en un departamento inexistente, o un curso impartido por un profesor inexistente. Hemos de recordar que slo los productos puramente relacionales implementan realmente estas dos reglas generales de Integridad relacional. En otros, destinados al mercado domstico (un Microsoft Access por ejemplo), estas incongruencias son admitidas sin problemas. As que cuando se realiza una operacin ilegal, existen dos opciones: rechazar la operacin ilegal o bien aceptar la operacin y realizar operaciones adicionales compensatorias que conduzcan a volverla legal. Por lo tanto, para cada clave fornea en la base de datos habr que contestar a dos preguntas: Regla de los nulos: tiene sentido que la clave fornea acepte nulos? Regla de borrado: Qu ocurre si se intenta borrar la tupla referenciada por la clave fornea? Restringir: no se permite borrar la tupla referenciada. Propagar: se borra la tupla referenciada y se propaga el borrado a las tuplas que hacen referencia mediante la clave fornea. Anular: se borra la tupla referenciada y las tuplas que la referenciaban indicando un valor nulo a la clave fornea (slo si acepta nulos). La Integridad referencial tambin vigila que se cumplan las siguientes reglas: No se podr introducir un valor en la tabla relacionada si antes no ha sido introducida en la tabla principal. No se puede eliminar un registro de una tabla principal si existen registros coincidentes en la tabla relacionada.
1"
No se puede cambiar un valor de la clave primaria en la tabla principal si el registro tiene registros relacionados.
2.1.3 Mecanismos de Vistas para la implementacin de Integridad

Las vistas son expresiones del lgebra relacional con un nombre determinado. Por ejemplo, veamos la tabla siguiente que contiene informacin sobre los vendedores de una ferretera. Supongamos que el dueo del negocio quiere conocer a los mejores vendedores para premiarlos con un bono especial al final del ao. Para hacerlo, l considera un buen vendedor a aquel que iguale o supere los $100.000 en ventas. Utilizando una vista en SQL podramos decir: var BUEN_VENDEDOR view (V where venta >= 100000) { Clave, Nombre, Ciudad} Al ejecutar esta instruccin, la expresin del lgebra relacional no es evaluada, sino que es recordada por el sistema de tal forma que para el usuario es como si en realidad tuviera una tabla denominada BUEN_VENDEDOR con los registros y atributos. En otras palabras, una vista es una ventana a travs de la cual se puede consultar o cambiar informacin de la tabla a la que est asociada. Esto, claro est, en relacin con los privilegios que posea el usuario de la base de datos. Si el usuario solamente tiene privilegios de lectura en una entidad, en la vista tampoco podr agregar o modificar informacin; si el usuario no tiene acceso a determinadas tablas, tampoco podr crear una vista con informacin proveniente de las mismas. Las vistas tienen la misma estructura que una tabla: filas y columnas. La nica diferencia es que slo se almacena de ellas la definicin, no los datos. Los datos que se recuperan mediante una consulta en una vista se presentarn igual que los de una tabla. De hecho, si no se sabe que se est trabajando con una vista, nada hace suponer que es as. Al igual que sucede con una tabla, se pueden insertar, actualizar, borrar y seleccionar datos. Esto significa que una vista no contiene datos duplicados de una tabla de la base de datos. No tiene absolutamente ningn dato, pues como ya se mencionaba, no es una tabla real. Es decir, se percibe como una tabla virtual.
1*
Por qu utilizar vistas?

Las vistas pueden proporcionar un nivel adicional de seguridad. Las vistas permiten ocultar la complejidad de los datos. Una base de datos se compone de muchas tablas. La informacin de dos o ms tablas puede recuperarse utilizando una combinacin de tablas, y estas combinaciones pueden resultar muy confusas. Creando una vista se hace visualmente todo ms simple. Las vistas ayudan a mantener unos nombres razonables para las consultas. Por ejemplo, en lugar de la instruccin:
Select Clave, Nombre, Ciudad fromVendedores where Venta > 100000 Se utiliza slo la frase: Buen_Vendedor
En las vistas remotas y en las vistas sin conexin puede crear reglas a nivel de campo y de registro para validar datos introducidos localmente antes de enviarlos al origen de datos remoto. Puesto que el objetivo de estas reglas es impedir que se enve al origen de datos cualquier dato que pueda ser rechazado por las reglas de Integridad del servidor, debe reproducir las reglas del origen de datos en las reglas que se crean para la vista remota. Por ejemplo, si la clave de un vendedor est formada por cuatro dgitos y as lo establecen las restricciones de Integridad de la tabla Vendedores, entonces en la vista, cuando un vendedor se d de alta, tambin se deber cumplir con esa restriccin. Existen funciones en los DBMS para crear reglas para las vistas, y es precisamente as como una vista puede implementarse para garantizar la Integridad de la base de datos; tambin, mediante las vistas, es posible determinar si existen datos referenciados que pudieran comprometer la Integridad relacional.
2.2 Seguridad 2.2.1 Identificacin y Autentificacin.

En un SGBD existen diversos elementos que ayudan a controlar el acceso a los datos.En primer lugar el sistema debe identificar y autentificar a los usuarios utilizando alguno de las siguientes formas: Cdigo y contrasea Identificacin por hardware Caractersticas bioantropomtricas
13
Conocimiento, aptitudes y hbitos del usuario Informacin predefinida (Aficiones, cultura, etc)
Adems, el administrador deber especificar los privilegios que un usuario tiene sobre los objetos: Usar una B.D. Consultar ciertos datos Actualizar datos Crear o actualizar objetos Ejecutar procedimientos almacenados Referenciar objetos Indexar objetos Crear identificadores.
2.2.2 Matriz de Autorizacin.

La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. La norma es que la base de datos relacionales cuente con dos niveles de seguridad: Relacin. Puede permitrsele o impedrsele que el usuario tenga acceso directo a una relacin. Vista. Puede permitrsele o impedrsele que el usuario tenga acceso a la informacin que aparece en un vista. Aunque es imposible impedir que un usuario tenga acceso directo a una informacin puede permitrsele acceso a una parte de esta relacin por medio de una vista. De tal manera que es posible utilizar una combinacin de seguridad al nivel relacional y al nivel de vistas para limitar el acceso del usuario exclusivamente a los datos que necesita. Un usuario puede tener varias formas de autorizacin sobre partes de la base de datos. Entre ellas se encuentran las siguientes: Autorizacin de lectura, que permite leer, pero no modificar la base de datos. Autorizacin de insercin, permite insertar datos nuevos pero no modificar lo ya existente.
15
Autorizacin de actualizacin, que permite insertar modificar la informacin pero no permite la eliminacin de datos. Autorizacin de borrado, que permite la eliminacin de datos.
Un usuario puede tener asignados todos, ninguno o una combinacin de los tipos de autorizacin anteriores. Adems de las formas de autorizacin de acceso de datos antes mencionados, es posible autorizar al usuario para que modifique el esquema de la base de datos. Autorizacin de ndice, que permite la creacin y eliminacin de ndices. Autorizacin de recursos, que permite la creacin de relaciones nuevas. Autorizacin de alteracin, que permite agregar o eliminar atributos de una relacin. Autorizacin de eliminacin, que permite eliminar relaciones.
Las autorizaciones de eliminacin y borrado difieren en cuanto a que la autorizacin de borrado solo permite la eliminacin de tuplas. La habilidad para crear nuevas relaciones viene regulada por la autorizacin de recursos de tal forma que la utilizacin del espacio del almacenamiento puede ser controlada. La autorizacin de ndice puede aparecer innecesariamente puesto que la creacin o eliminacin de un ndice no altera los datos en las relaciones. Ms bien los ndices son una estructura para realizar mejoras. La forma fundamental de autoridad es la que se le da al administrador de la base de datos. El administrador de la base de datos puede entre otras cosas autorizar nuevos usuarios, reestructurar la base de datos, etc.
2.2.3 Definicin de un Esquema de Seguridad

El problema de la seguridad consiste en lograr que los recursos de un sistema sean, bajo toda circunstancia, utilizados para los fines previstos.Un aspecto importante de la seguridad es el de impedir la prdida de informacin, la cual puede producirse por diversas causas: fenmenos naturales, guerras, errores de hardware o de software, o errores humanos. La solucin es una sola: mantener la informacin respaldada, de preferencia en un lugar lejano.
17
Otro aspecto importante de la seguridad, es el que tiene que ver con el uso no autorizado de los recursos: Lectura de datos, modificacin de datos, destruccin de datos y uso de recursos: ciclos de CPU, impresora, almacenamiento.
2.2.4 Mecanismos de Vistas para la Implementacin de Seguridad.

Para proteger la base de datos es preciso proteger los recursos, concretamente los datos almacenados, de lecturas y/o actualizaciones accidentales o malintencionadas.
Concretamente los requisitos de proteccin que pueden establecerse son: Proteccin de accesos indebidos. Proteccin de inferencias. Integridad de la BD. Integridad operacional de los datos Integridad semntica de los datos Contabilidad y auditoria Autenticacin del usuario. Gestin y proteccin de datos sensibles. Proteccin multinivel
Para cumplir con ellos es preciso que en cada organizacin que contenga una base de datos se establezca lo que se denomina polticas, modelos y mecanismos de proteccin: Las polticas son la directrices generales que definen las lneas que deben guiar la seguridad de la informacin estas polticas son marcadas, unas veces, por niveles de mayor responsabilidad de la empresa dependiendo del tipo de actividad de la misma. Otras veces vienen impuestas por obligaciones legales. Los modelos son formulaciones matemticas abstractas de las polticas de seguridad. Los mecanismos son conjuntos de funciones que implantan los modelos de seguridad previamente definidos. En algunos casos estos mecanismos se materializan en hardware o software, y otras veces en procedimientos administrativos. Las polticas, modelos y mecanismos estn
18
encaminadas a determinar la forma de restringir el acceso de los usuarios a los recursos del sistema dependiendo de la proteccin que se necesite suministrar. Es una forma lgica de ver los datos fsicos ubicados en tablas. Cuando creamos una vista, seleccionamos una forma que incluye datos que pueden ser tomados de una o ms tablas. La vista queda almacenada en forma permanente, si bien los datos grabados permanecen inalterados en las tablas correspondientes. Una vista solo es una ventana a los datos almacenados. Utilizadas como mecanismos de seguridad, las vistas restringen el acceso de un usuario a determinadas columnas de la tabla, si la columna excluida es la clave de la fila, tambin se est impidiendo que el usuario pueda relacionar dos tablas. La vista deber ser propiedad del mismo usuario que posea objetos subyacentes. En la arquitectura de tres niveles estudiada se describe una vista externa como la estructura de la BD tal y como la ve el usuario en particular. En el modelo relacional, el trmino vista tiene un significado un tanto diferente. En lugar de ser todo el esquema externo de un usuario, una vista es una relacin virtual, una relacin que en realidad no existe como tal. Una vista se puede construir realizando operaciones como las del algebra relacional: restricciones, proyecciones, concatenaciones, etc. Una vista es un resultado dinmico de una o varias operaciones relacionales realizadas sobre las relaciones base. Una vista es una relacin virtual que se produce cuando un usuario la consulta. Al usuario le parece que la vista es una relacin que existe y la puede manipular como si se tratara de una relacin base, pero la vista no est almacenada fsicamente. El contenido de una vista est definido como una consulta sobre una o varias relaciones base. Cualquier operacin que se realice sobre la vista se traduce automticamente a operaciones sobre las relaciones de las que se deriva. Las vistas son dinmicas porque los cambios que se realizan sobre las tablas base que afectan a una vista se reflejan inmediatamente sobre ella. Cuando un usuario realiza un cambio sobre la vista (no todo tipo de cambios estn permitidos), este cambio se realiza sobre las relaciones de las que se deriva. Las vistas son tiles por varias razones:
29
Proporcionan un poderoso mecanismo de seguridad, ocultando partes de la base de datos a ciertos usuarios, el usuario no sabr que existen aquellos atributos que se han omitido al definir una vista.
Permiten que los usuarios accedan a los datos en el formato que ellos desean o necesitan, de modo que los mismos datos pueden ser vistos con formatos distintos por distintos usuarios.
Se puede simplificar operaciones sobre las relaciones base que son complejas. Por ejemplo, se puede definir una vista como la concatenacin de dos relaciones. El usuario puede hacer restricciones y proyecciones sobre la vista, que el sistema SGBD traducir en las operaciones equivalentes sobre la concatenacin.
Las vistas proporcionan independencia de datos a nivel lgico, que tambin se da cuando se organiza el nivel conceptual. Si se aade un atributo a una relacin, los usuarios no se percatan de su existencia si sus vistas no lo incluyen. Si una relacin existe se reorganiza o se divide en varias relaciones, se pueden crear Las vistas es una forma de proporcionar al usuario un modelo personalizado de la base de datos. Una vista puede ocultar datos que el usuario no tiene necesidad de ver. El uso del sistema es ms sencillo porque el usuario puede restringir su atencin a los datos que le interesan. La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. Lo normal es que las bases de datos relacionales cuenten con los dos niveles de seguridad:
2.2.5 Bases de Datos Estadsticas

Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con la abreviatura b. d.) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayora por documentos y textos impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnolgico de campos como la informtica y la electrnica, la mayora de las bases de datos estn en formato digital (electrnico), que ofrece un amplio rango de soluciones al problema de almacenar datos. Existen programas denominados sistema gestor de bases de datos, abreviado SGBD, que permiten almacenar y posteriormente acceder a los datos de forma rpida y estructurada.
21
Las propiedades de estos SGBD, as como su utilizacin y administracin, se estudian dentro del mbito de la informtica. Las aplicaciones ms usuales son para la gestin de empresas e instituciones pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto de almacenar la informacin experimental. 2.3 Mecanismos de Proteccin Contra Inyeccin SQL. Es un mtodo de infiltracin de cdigo intruso que se vale de una vulnerabilidad informtica presente en una aplicacin en el nivel de validacin de las entradas para realizar consultas a una base de datos. La inyeccin de cdigo SQL es un ataque en el cual se inserta cdigo malicioso en las cadenas que posteriormente se pasan a una instancia de SQL Server para su anlisis y ejecucin. Todos los procedimientos que generan instrucciones SQL deben revisarse en busca de vulnerabilidades de inyeccin de cdigo, ya que SQL Server ejecutar todas las consultas recibidas que sean vlidas desde el punto de vista sintctico. Un atacante cualificado y con determinacin puede manipular incluso os datos con parmetros. La forma principal de inyeccin de cdigo SQL consiste en la insercin directa de cdigo en variables especificadas por el usuario que se concatenan con comandos SQL y se ejecutan. Existe un ataque menos directo que inyecta cdigo daino en cadenas que estn destinadas a almacenarse en una tabla o como metadatos. Cuando las cadenas almacenadas se concatenan posteriormente en un comando SQL dinmico, se ejecuta el cdigo daino.
22
Prctica 2
Nombre de la prctica: Mecanismos de vistas para la integridad de la base de datos Objetivo: Al trmino de esta prctica el alumno ser capaz de programar las reglar de integridad de las base de datos utilizando Sql. Material requerido: Para esta prctica utilizaremos: 1 Laptop Wamp-server o o o o Apache PHP MySQL PHPMyAdmin
Smbolo del sistema
Metodologa de desarrollo:
El desarrollo de la prctica consiste en realizar los siguientes mtodos con el fin de que se obtengas los resultados esperando los cules sern presentados en el reporte de la prctica. A continuacin se presenta los mtodos : 1. Creacin base datos y tabla: Previamente crearemos una nueva base de datos llamada escuela, como se muestra en la figura 1.En esta base de datos se crea una tabla con el nombre alumnos y los siguientes campos: no_control (entero), nombre (cadena), materia (cadena) y calificacin (entero). Ver figura 2. 2. Insercin datos: Posteriormente insertamos los siguientes datos dentro de la tabla:
(08680159, ana Karen cortes mendoza, bases de datos, 90) (08680195, luis Alberto lopez cabrales, bases de datos, 80) (08680241, gabriel rivera barranco, bases de datos, 95)
Despus mostramos los datos ya insertadosVer figuras 3 y 4 3. Creacin vista: En este punto se crea la vista donde se seleccionan de la tabla, slo los campos que se desean mostrar. Esto con el fin de ocultar los datos importantes a los usuarios a los que no les es permitido acceder libremente a toda la informacin. Se cre la vista con la siguiente instruccin:
create view datos_alumnos as select no_control, nombre from alumnos; En este caso el nombre de la vista es definido como datos_alumnos y se seleccionan los campos no_control y nombre y estos campos son obtenidos desde la tabla alumnos. Ya creada la vista, podemos acceder a ella utilizando la misma instruccin para hacer una consulta a una tabla normal.
Select * from datos_alumnos; Caractersticas del reporte

Para el desarrollo del reporte se deber seguir los lineamientos presentado en el anexo A, y seguir la metodologa presentada en la unidad con el fin de obtener los resultados mostrados en la figuras a continuacin.
Figura 2.1 Creacin e Inserta datos tabla alumnos.
Figura 2.2. Creacin y consulta de la vista
2"
Prctica 3: Sentencia Sql para la integridad de la base de datos

Objetivo: Al trmino de esta prctica el alumno ser capaz de implementar Sentencia Sql para la integridad de la base de datos. Material requerido: en la prctica 1 . En esta prctica se utilizar MySQL.que fue instalado previamente
Para esta prctica se utilizar nicamente MySQL, en vista que es el DBMS ms accesible en mbitos estudiantiles aun cuando no cuenta con todo el soporte y funcionalidades que otros DBMS comerciales s. Se pretende comprobar la utilidad de las restricciones SQL, UNIQUE en este caso, para asegurar ms estabilidad e integridad de datos en nuestras tablas esto con la finalidad de crear aplicaciones futuras ms estables y seguras para nuestros clientes. Para comprobar la integridad de nuestras tablas, usualmente se utilizan llaves primarias para asegurar que no existan datos repetidos, sin embargo esto no asegura la integridad de los datos, por tal motivo se pretende trabajar con restricciones tales como UNIQUE y CHECK, que nos ofrecen SQL. Para este caso se usar una base de datos ya existente, en este caso se usar integridad, posteriormente procederemos a crear una tabla de la siguiente manera. CREATE TABLE NICUStatus ( Name CHAR(15), Status CHAR(8),from_date DATE, UNIQUE (Name, Status)
to_date DATE, );
Hay que notar que no se utilizan llaves primarias de manera que a simple vista pareciera que aceptar datos repetidos, sin embargo se utiliza la restriccin UNIQUE, que aunque no es una llave primaria restringe los datos duplicados para los campos especificados, en este caso los campos Name y Status, para comprobar que si funciona insertaremos datos y a propsito daremos un duplicado:
2*
INSERT INTO NICUStatus (Name, Status, from_date, to_date) VALUES ('Kenneth Robert', 'serious', DATE '1997-11-19', DATE '1997-11-21'), ('Alexis May', 'serious', DATE '1997-11-19', DATE '1997-11-27'), ('Natalie Sue', 'serious', DATE '1997-11-19', DATE '1997-11-25'), ('Kelsey Ann', 'serious', DATE '1997-11-19', DATE '1997-11-26'), ('Brandon James', 'serious', DATE '1997-11-19', DATE '1997-11-26'), ('Nathan Roy', 'serious', DATE '1997-11-19', DATE '1997-11-28'), ('Joel Steven', 'critical', DATE '1997-11-19', DATE '1997-11-20'), ('Joel Steven', 'serious', DATE '1997-11-20', DATE '1997-11-26'), ('Kenneth Robert', 'fair', DATE '1997-11-21', DATE '1998-01-03'), ('Alexis May', 'fair', DATE '1997-11-27', DATE '1998-01-11'), ('Alexis May', 'fair', DATE '1997-12-02', DATE '9999-12-31');
Esto provocar un error dado que el ltimo registro viola la restriccin unique: ('Alexis May', 'fair', DATE '1997-12-02', DATE '9999-12-31');Ver figura 3. Nota: Observe que aun cuando arriba ya existe ese mismo nombre el estatus es diferente, pero para el ltimo insertado ya existe tanto el nombre, como el status, por tal motivo marca un error y no realiza la ltima insercin. Posteriormente borraremos la tabla para continuar demostrando el uso de este tipo de restricciones:
drop table NICUStatus;

A continuacin crearemos nuevamente la misma tabla pero en esta ocasin la restriccin ser diferente (ver figura 5): CREATE TABLE NICUStatus ( Name CHAR(15), Status CHAR(8), from_date DATE, to_date DATE, UNIQUE (Name, Status, from_date, to_date) ); Ntese que la restriccin es diferente, en este caso los duplicados no pueden ser secuenciados, insertaremos datos para comprobar su funcionamiento.
23
INSERT INTO NICUStatus (Name, Status, from_date, to_date) VALUES ('Kenneth Robert', 'serious', DATE '1997-11-19', DATE '1997-11-21'), ('Alexis May', 'serious', DATE '1997-11-19', DATE '1997-11-27'), ('Natalie Sue', 'serious', DATE '1997-11-19', DATE '1997-11-25'), ('Kelsey Ann', 'serious', DATE '1997-11-19', DATE '1997-11-26'), ('Brandon James', 'serious', DATE '1997-11-19', DATE '1997-11-26'), ('Nathan Roy', 'serious', DATE '1997-11-19', DATE '1997-11-28'), ('Joel Steven, critical', DATE '1997-11-19', DATE '1997-11-20'), ('Joel Steven, serious', DATE '1997-11-20', DATE '1997-11-26'), ('Kenneth Robert', 'fair', DATE '1997-11-21', DATE '1998-01-03'), ('Alexis May', 'fair', DATE '1997-11-27', DATE '1998-01-11'), ('Alexis May', 'fair', DATE '1997-12-02', DATE '9999-12-31');
El ltimo registro provocar un error, porque la restriccin verificar que ningn campo este duplicado para poder realizar la insercin, algo que no se puede lograr con solo llaves primarias, ya que estas solo checan el campo clave y los dems no, con esto podremos asegurar que ningn registro podr ser duplicado logrando mayor integridad. A continuacin se borrar nuevamente la tabla para continuar con la prctica: drop table NICUStatus; Se crear nuevamente la tabla pero las restricciones cambiaran: CREATE TABLE NICUStatus ( Name CHAR(15), Status CHAR(8), from_date DATE, to_date DATE, CHECK (NOT EXISTS (SELECT N1.SSN FROM NICUStatus AS N1 WHERE 1 < (SELECT COUNT(Name) FROM NICUStatus AS N2 WHERE N1.Name = N2.Name AND N1.Status = N2.Status AND N1.from_date <= CURRENT_DATE AND CURRENT_DATE < N1.to_date AND N2.from_date <= CURRENT_DATE
25
AND CURRENT_DATE < N2.to_date))) );
En esta ocasin la creacin de la tabla depender de la restriccin CHECK, que est ms completa en DBMS propietarios, esta restriccin fungir como una llave fornea, al menos en el comportamiento, es decir la condicin que est dentro del check deber cumplirse para los atributos de la tabla, es decir no debe haber duplicados en una tabla independiente pero que a su vez est relacionada con la que queremos crear. Primero compara que los registros (de atributos similares) en la tabla N1 y N2(NICUStatus) no coincidan con registros de la tabla NICUStatus:
En esta ocasin las dos ltimas entradas provocaran error dado que la restriccin es similar a la ltima UNIQUE que se realiz. Nuevamente borramos la tabla para probar otras restricciones: drop table NICUStatus;
Ahora crearemos nuevamente la tabla pero nuevamente la restriccin cambiar:

CREATE TABLE NICUStatus ( Name CHAR(15), Status CHAR(8), from_date DATE, to_date DATE, UNIQUE (Name, Status, to_date)
27
); Nuevamente se usa UNIQUE, en este caso se indican los tres primeros campos como nicos para prevenir duplicados:
Nuevamente el ltimo registro es el que provoca error al violar la restriccin UNIQUE establecida; Se borrar la tabla nuevamente y se probar con otra restriccin: drop table NICUStatus; CREATE TABLE NICUStatus ( Name CHAR(15), Status CHAR(8), from_date DATE, to_date DATE, CHECK (NOT EXISTS (SELECT N1.Name FROM NICUStatus AS N1 WHERE 1 < (SELECT COUNT(Name) FROM NICUStatus AS N2 WHERE N1.Name = N2.Name AND N1.Status = N2.Status AND N1.from_date < N2.to_date ); AND N2.from_date < N1.to_date)))
28
En esta restriccin check los atributos debern pasar la condicin del check para los tres primeros campos, que se comparan contra las tablas N1 y N2 (NICUStatus) para asegurarse que los estos tres campos no se dupliquen:
Nuevamente el ltimo registro no cumple la restriccin del check establecido y causa un error. Hay que notar que aun sin el uso de claves primarias y forneas es posible asegurar la integridad de los datos pero para ello es necesario tener bien establecida las relaciones entre tablas y tener en claro los datos que se necesitan para prevenir que las restricciones sean las que no permitan la insercin o borrado de datos aun cuando a simple vista parezcan correctos.
RESULTADOS OBTENIDOS
A continuacin se muestran las pantallas con los resultados obtenidos al realizar los mtodos descritos previamente en el desarrollo de la prctica, se presenta una serie de pantallas con el fin de que las puedas comparar y presentar los resultado que obtengas en tu reporte de la practica.
Figura 2.3. Uso de la base datos integridad
Figura 2.4. Creacin de la tabla NICUStatus
Insercin de datos en la primera tabla
Figura 2.5 Insercin en la tabla NICUStatus Eliminacin de la primera tabla
Figura 2.6. Borrado de la tabla NICUStatus.
Figura 2.7 Creacin de la segunda tabla
Figura 2.8 Insercin de datos en la segunda tabla
Figura 2.9 Consulta general de la tabla
"
Prctica 4: Gestin de candados con MySQL

Objetivo: Al trmino de esta prctica el alumno ser capaz de implementar candados con Mysql. Material requerido: en la prctica 1 . En esta prctica se utilizar MySQL.que fue instalado previamente
En esta prctica demostraremos el uso de los candados mediante un ejemplo prctico Ahora comprobaremos el funcionamiento de la funcin lock table de MySQL, en la base de datos ya creada, y en la ventana principal realizamos el bloqueo para la nica tabla con la que se cuenta:
lock table Datos write; Ahora desde la otra sesin intentamos insertar datos:
insert into Datos values ('08680010','Gerardo',25); Ntese que la operacin queda en stand by mientras la tabla siga bloqueada. Ahora desde la primera ventana desbloquemos la tabla: unlock tables; Hecho esto la operacin pendiente se realiza y la insercin de datos es llevada a cabo.Comprobamos con una consulta para verificar que los datos si se insertaron correctamente: select * from Datos; Ya con esto comprobamos el funcionamiento de lock ahora comprobaremos que trabaja nicamente en la tabla que bloquemos, para ello se creara una nueva tabla: create table Datos2(No int); Ahora procederemos nuevamente a bloquear la tabla Datos: lock table Datos write;
Y desde la segunda ventana insertaremos datos en la tabla nueva (Datos2):
insert into Datos values('08680011','Adrian',22); Hay que notar que nos permite realizar la operacin, esto se debe a que nicamente bloquemos la primera tabla, con esto queda corroborado el bloque de tablas en MySQL.
Caractersticas del reporte

Para el desarrollo del reporte se deber seguir los lineamientos presentado en el anexo A, y seguir la metodologa presentada con el fin de obtener los resultados a presentar en tu reporte de prctica con la informacin proporcionada por el docente.
CAPTULO 3 ADMINISTRACIN DE TRANSACCIONES 3.1 TRANSACCIONES

Desde el punto de vista del usuario la interaccin con la base de datos se lleva a cabo mediante operaciones con significado en el modelo semntico (por ejemplo, una transferencia de fondos en un banco). Desde el punto de vista de la base de datos estas operaciones pueden estar formadas por varias operaciones elementales (por ejemplo, quitar fondos de una cuenta y aadrselos a otra). Una transaccin es una unidad de la ejecucin de un programa que accede y, posiblemente, actualiza varios elementos de datos. Una Transaccin est delimitada por instrucciones de inicio transaccin y fin transaccin (la transaccin consiste en todas las operaciones que se ejecutan entre inicio transaccin y fin transaccin).
Propiedades de las transacciones (ACID)

Para garantizar la integridad de los datos los sistemas de bases de datos deben tener las siguientes propiedades en sus transacciones:
Atomicidad
Se refiere al hecho de que una transaccin se trata como una unidad de operacin. Debe garantizar que en la base de datos se realicen (adecuadamente) todas las operaciones o no se realice ninguna. La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales sean anulados.
Consistencia
Debe asegurarse que mientras se realice una transaccin la consistencia de la base de datos debe estar asegurada. La consistencia de una transaccin es simplemente su correctitud. En otras palabras, una transaccin es un programa correcto que lleva a la base de datos de un estado consistente a otro con la misma caracterstica.
Aislamiento (Isolation)
Mientras una transaccin se est llevando a cabo ninguna otra transaccin (concurrentemente) puede interrumpirla, es decir, debe ignorarlas hasta que termine la primera transaccin. Esto implica tambin que una transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de finalizar.
Durabilidad
Despus de una transaccin concluida con xito, los cambios realizados deben permanecer, inclusive si ocurre algn fallo del sistema.Esta propiedad motiva el aspecto de recuperacin de base de datos, el cual trata sobre cmo recuperar la base de datos a un estado consistente reflejadas en la base. donde todas las acciones que han finalizado con xito queden
Estados de las transacciones Transaccin comprometida

Una transaccin que termina su ejecucin con xito se dice que est comprometida (commit). Una transaccin comprometida que haya hecho modificaciones transforma la base de datos llevndola a un nuevo estado consistente, que permanece incluso si hay fallo en el sistema. En ausencia de fallos, todas las transacciones se completan con xito.
Transaccin abortada
Una transaccin que no termina su ejecucin con xito se dice que est abortada. Para asegurar la atomicidad, las transacciones abortadas no deben tener efecto sobre el estado de la base de datos y cualquier cambio que haya hecho la transaccin abortada debe deshacerse. Una vez deshechos los cambios de una transaccin abortada se dice que la transaccin se ha retrocedido (rollback).
Transaccin compensadora
Una vez que una transaccin se ha comprometido no se pueden deshacer sus efectos abortndola slo se pueden invertir sus efectos mediante una transaccin compensadora No siempre se puede crear una transaccin compensadora asociada a cada transaccin a realizar y esto queda a responsabilidad del usuario.
3.2 Tipos de fallas

El sistema debe estar preparado para recuperarse no slo de fallas puramente locales, como la aparicin de una condicin de desborde dentro de una transaccin, sino tambin de fallas globales, como podra ser la interrupcin del suministro elctrico al CPU. Las fallas locales son las que afectan slo a la transaccin en donde ocurri. Por el contrario las fallas globales, afectan a varias las transacciones que se estaban efectuando en el momento de la falla, por lo cual tienen implicaciones importantes en el sistema. Estas fallas pueden ser:
Falla del sistema

Por ejemplo interrupcin del servicio elctrico, estas afectan a todas Las transacciones que se estaban ejecutando pero no afectan a la base de datos.Las fallas de sistema se conocen tambin como cadas suaves. El problema aqu es que se pierda el contenido de memoria principal, en particular, las reas de almacenamiento temporal o buffers. Si esto ocurre, no se conocer el estado preciso de la transaccin que se estaba ejecutando en el momento de la falla, esta transaccin jams se podr completar con xito por lo que ser preciso anularla cuando se reinicie el sistema. Adems, puede ocurrir que sea necesario volver a ejecutar algunas transacciones que s se realizaron con xito antes de la falla pero cuyas modificaciones no lograron efectuarse sobre la base de datos porque no lograron ser transferidas de los buffers de la base de datos a la base de datos fsica (en el disco).
Fallas en los medios de almacenamiento

Una falla de los medios de almacenamiento es un percance en el cual se destruye fsicamente alguna porcin de la BD. La recuperacin de una falla semejante implica en esencia cargar de nuevo la BD a partir de una copia de respaldo y utilizar despus la bitcora para realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia de respaldo. No hay necesidad de anular las transacciones inconclusas en el momento de la falla, porque por definicin todas las modificaciones de esas transacciones ya se anularon de todas maneras. La parte de restauracin de la utilera servir entonces para recrear la BD despus de una falla de los medios de almacenamiento a partir de una copia de respaldo especificada. Por ejemplo una falla en el controlador de disco o un aterrizaje de cabeza en el disco, estas fallas s causan daos a la base de datos o a una porcin de ella y afecta, al menos, a las transacciones que estn haciendo uso de esa porcin.
Las fallas de los medios de almacenamiento se llaman cadas duras.
La Recuperacin de una falla semejante implica, en esencia, cargar de nuevo la base de datos a partir de una copia de respaldo (database backup) y despus utilizar la bitcora, o system log, para realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia para respaldo. No hay necesidad de anular todas las transacciones inconclusas en el momento de la falla, porque por definicin esas transacciones ya se anularon (se destruyeron) de todas maneras.
Errores del sistema

Como realizar operaciones que causen un overflow de un entero o la divisin por cero, as mismo puede ocurrir que se pasen valores errneos a algn parmetro o que se detecte un error en la lgica de un programa, o que sencillamente no se encuentren los datos del programa. Adems, en algunos ambientes de desarrollo el usuario puede explcitamente interrumpir una transaccin durante su ejecucin. Lo importante en las fallas del sistema es que se pierde el contenido de la memoria principal. Por tanto las transacciones que se estaban ejecutando deben ser desechas. Las transacciones que completaron satisfactoriamente antes de la falla pero que no actualizaron deben ser reiniciadas.
3.3 Recuperacin (recovery)

Una vez que ha ocurrido una falla Cmo el sistema determina las que pueden ser reiniciadas y cules desechadas? La recuperacin de las fallas de transacciones significa que la base de datos se debe restaurar desde algn estado considerado correcto del pasado - lo ms cercano posible al momento de la falla. Para lograr esto el sistema debe mantener (externamente a la BD) la informacin de todo lo que afecta a los data tems de la base de datos. A esto se le llama Bitcora o system log como se mencion anteriormente. Es importante considerar las dos principales tcnicas de recovery debido a fallas no catastrficas:
"9
Deferred Update (o actualizacin diferida)

Tambin conocida como NO UNDO/REDO: esta tcnica actualiza la base de datos slo despus de que la transaccin ha llegado a su COMMIT. Antes de la llegada al COMMIT, todas las modificaciones son guardadas en un rea de trabajo de la transaccin local. Durante el COMMIT, las actualizaciones primero que nada son guardadas en el system log y luego se guardan en la base de datos. Si la transaccin falla antes de llegar al commit no se guarda ningn cambio en la base de datos, de manera que no es necesario hacer ningn UNDO. Si la transaccin lleg al commit grab en el system log pero no grab en la base de datos, es necesario hacer un REDO, es decir, grabar los efectos de la transaccin que se encuentran en el log sobre la base de datos.
Inmediate Update (actualizacin inmediata)

Conocida tambin como UNDO/REDO: esta tcnica propone que algunas operaciones actualicen la base de datos antes de que la transaccin llegue al commit. Estas
actualizaciones son guardadas en el system log a nivel de disco antes de ser aplicadas a la base de datos. Si una transaccin falla despus de grabar algunos cambios en la base de datos y antes de llegar al commit, se debe aplicar un UNDO para anular los efectos sobre la base de datos, es decir, la transaccin debe aplicar un ROLLBACK y hacer un REDO para grabar los valores anteriores a la falla. Una variacin de este algoritmo UNDO/REDO consiste en permitir que todos los cambios de hace la transaccin antes de llegar al commit afecten a la base de datos y si ocurre una falla slo se requiere un UNDO de manera que esta tcnica tambin se le conoce como UNDO/NO REDO.
3.4 Concurrencia
Las propiedades ACID crean la ilusin de que cada usuario es nico en la base de datos, es decir se aslan unos de otros. El control de transacciones concurrentes en una base de datos brinda un eficiente desempeo del sistema de base de datos, puesto que permite controlar la ejecucin de transacciones que operan en paralelo, accesando a informacin compartida y, por lo tanto, interfiriendo potencialmente unas con otras.
"1
La concurrencia en las bases de datos es de gran importancia en los sistemas de informacin, ya que evita errores en el momento de ejecutar las diferentes transacciones. Cuando dos o ms transacciones se ejecutan concurrentemente, sus operaciones se ejecutan en un modelo intercalado. Esto significa que las operaciones de un programa se ejecutan entre dos operaciones de otro programa. Esta intercalacin puede causar que los programas no funcionen correctamente, o interfieran, y de esta manera, dejara inconsistente a la base de datos. Esta interferencia se debe completamente a la intercalacin de las operaciones, puesto que puede ocurrir a pesar de que cada programa funciona correctamente cuando se ejecuta de forma individual y no se presenta falla alguna en el sistema. El objetivo del control de concurrencia es evitar la interferencia y, por ende, los errores.
Teora de Seriabilidad
Una forma de evitar los problemas de interferencia es no permitir que las transacciones se intercalen. Una ejecucin en la cual ninguna de dos transacciones se intercala se conoce como serial. Para ser ms precisos, una ejecucin se dice que es serial si, para todo par de transacciones, todas las operaciones de una transaccin se ejecutan antes de cualquier operacin de la otra transaccin. Desde el punto de vista del usuario, en una ejecucin serial se ve como si las transacciones fueran operaciones que el sistema de base de datos (DBS) procesa atmicamente. Las transacciones seriales son correctas dado que cada transaccin es correcta individualmente, y las transacciones que se ejecutan serialmente no pueden interferir con otra. Si el DBS procesara transacciones serialmente, significara que no podra ejecutar transacciones concurrentemente, si entendemos concurrencia como ejecuciones
intercaladas. Sin dicha concurrencia, el sistema usara sus recursos en un nivel relativamente pobre y podra ser sumamente ineficiente. Una solucin puede ser ampliar el rango de ejecuciones permisibles para incluir aquellas que tienen los mismos efectos que los seriales. Dichas ejecuciones se conocen como serializables. Entonces, una ejecucin es serializable si produce el mismo resultado y tiene el mismo efecto sobre la base de datos que alguna ejecucin serial de las mismas transacciones. Puesto que las transacciones seriales son correctas, y dado que cada ejecucin serializable tiene el mismo efecto que una ejecucin serial, las ejecuciones serializables tambin son correctas.
"2
La teora de seriabilidad es una herramienta matemtica que permite probar si un sincronizador trabaja o no correctamente. Desde el punto de vista de la teora de seriabilidad, una transaccin es una representacin de una ejecucin de operaciones de lectura y escritura y que indica el orden en el que se deben ejecutar estas operaciones. Adems, la transaccin contiene un commit o un rollback como la ltima operacin para indicar si la ejecucin que representa termin con xito o no.
3.5 Problemas que se presentan (actualizacin, prdida, etc.) Problema de la actualizacin perdida
Ocurre cuando dos transacciones que acceden a los mismos datos tienen sus operaciones intercaladas de forma que hacen que el valor de un dato sea incorrecto.
Problema de la actualizacin temporal

Ocurre cuando una transaccin actualiza un dato y despus falla. El dato actualizado es accedido por otra transaccin antes de cambiar su valor al original.
Problema de la suma incorrecta

Si una transaccin est calculando una funcin matemtica sobre un conjunto de tuplas mientras que otras transacciones estn actualizndolas, el resultado puede ser incorrecto. La solucin obvia a estos problemas sera permitirle a una transaccin bloquear un objeto durante una actualizacin y liberarlo apenas culmine. Sin embargo, el mecanismo de bloqueo puede el mismo, generar serios problemas en el sistema y por lo tanto debe ser monitoreado y controlado cuidadosamente.
3.6 Candados
Un bloque o candado (lock) es una estructura que slo puede ser adquirida por una hebra de ejecucin (thread) a la vez. Un candado es una garanta de ciertos derechos de exclusividad para la transaccin. Si dos ejecuciones tratan de obtener un candado para actualizar una tabla, la primera que trate de obtenerlo tendr acceso exclusivo a la tabla, la segunda debe esperar a que la primera lo suelte para obtener el acceso. Los candados pueden tener distintas metas: Bases de Datos, Tabla, Tupla, Atributo. Adems de los bloqueos exclusivos existen candados de slo lectura o candados compartidos que pueden estar simultneamente siendo utilizados por distintas ejecuciones.
"
Bloqueo Exclusivo
Si una transaccin T mantiene un bloqueo exclusivo sobre algn objeto (digamos un registro de la base de datos), entonces ninguna transaccin distinta puede adquirir un bloqueo de ningn tipo sobre ese objeto hasta que la transaccin T libere su bloqueo. El bloqueo exclusivo provee la base para resolver el problema de actualizacin perdida planteado anteriormente.
Bloqueo Compartido
Una transaccin puede necesitar retener data bloqueada cuando no la vaya a actualizar. Si una transaccin T retiene un bloqueo compartido sobre algn objeto (digamos un registro de la BD), entonces una transaccin distinta T' puede adquirir un bloqueo compartido sobre ese objeto, pero ninguna transaccin distinta T' puede adquirir un bloqueo exclusivo sobre ese objeto hasta que todos los bloqueos compartidos existentes sobre ese objeto sean liberados.
3.7 Deadlock
Un interbloqueo (deadlock) es una situacin en donde un grupo de procesos estn permanentemente bloqueados como consecuencia de que cada proceso ha adquirido un subconjunto de los recursos necesarios para su operacin y est esperando la liberacin de los restantes recursos mantenidos por otros del mismo grupo, haciendo as imposible que ninguno de los procesos pueda continuar. Cuando dos transacciones se quedan a la espera de que se liberen elementos que tiene bloqueados la otra ocurre un deadlock.Puede producirse incluso con protocolos de bloqueo que garantizan la seriabilidad.
Tcnicas para prevenirlo

Exclusin Mutua: si ningn recurso se puede asignar de forma exclusiva, no se producir interbloqueo. Sin embargo, existen recursos para los que no es posible negar la condicin de exclusin mutua. No obstante, es posible eliminar esta condicin en algunos procesos. Por ejemplo, una impresora es un recurso no compatible pues si se permite que dos procesos escriban en la impresora al mismo tiempo, la salida resulta catica. Pero con el Spooling de salida varios procesos pueden generar salida al mismo tiempo. Puesto que el Spooler nunca solicita otros recursos, se elimina el bloqueo originado por la impresora.
""
Hold and wait: se exige al proceso que pida todos sus recursos de una sola vez y no comenzara a correr hasta que se le puedan asignar todos simultneamente. Esta solucin resulta ineficiente por dos factores: En primer lugar, un proceso puede estar suspendido durante mucho tiempo, esperando que concedan todas sus solicitudes de recursos, cuando de hecho podra haber avanzado con solo algunos de los recursos. Y en segundo lugar, los recursos asignados a un proceso pueden permanecer sin usarse durante periodos considerables, tiempo durante el cual se priva del acceso a otros procesos.
No expropiacin: se puede prevenir de varias maneras. Una es hacer que un proceso al que se le niega un recurso, libera todos los que ya tiene, y ms adelante vuelve a pedirlos. Otra es que si un proceso pide un recurso que es de otro, es este ltimo el que libera sus recursos. Espera circular: se previene imponiendo un orden lineal para pedir recursos (segn los que ya se tienen asignados). Los recursos se clasifican por categoras y los procesos solo pueden solicitar los recursos en orden creciente, adems todos los recursos de una categora deben ser solicitados a la vez. Una vez que un proceso ha solicitado un recurso de una categora, no puede solicitar otro de una categora inferior.
"*
Prctica 3: Gestin de candados con MySQL

Objetivo: Al trmino de esta prctica el alumno ser capaz de implementar candados con Mysql. Material requerido: en la prctica 1 . En esta prctica se utilizar MySQL.que fue instalado previamente
En esta prctica demostraremos el uso de los candados mediante un ejemplo prctico Ahora comprobaremos el funcionamiento de la funcin lock table de MySQL, en la base de datos ya creada, y en la ventana principal realizamos el bloqueo para la nica tabla con la que se cuenta:
lock table Datos write; Ahora desde la otra sesin intentamos insertar datos:
insert into Datos values ('08680010','Gerardo',25); Ntese que la operacin queda en stand by mientras la tabla siga bloqueada. Ahora desde la primera ventana desbloquemos la tabla: unlock tables; Hecho esto la operacin pendiente se realiza y la insercin de datos es llevada a cabo.Comprobamos con una consulta para verificar que los datos si se insertaron correctamente: select * from Datos; Ya con esto comprobamos el funcionamiento de lock ahora comprobaremos que trabaja nicamente en la tabla que bloquemos, para ello se creara una nueva tabla: create table Datos2(No int); Ahora procederemos nuevamente a bloquear la tabla Datos: lock table Datos write;
Y desde la segunda ventana insertaremos datos en la tabla nueva (Datos2):
"3
insert into Datos values('08680011','Adrian',22); Hay que notar que nos permite realizar la operacin, esto se debe a que nicamente bloquemos la primera tabla, con esto queda corroborado el bloque de tablas en MySQL.

Para el desarrollo del reporte se deber seguir los lineamientos presentado en el anexo A, y seguir la metodologa presentada con el fin de obtener los resultados a presentar en tu reporte de prctica con la informacin proporcionada por el docente.
"5
PRCTICA 5: GESTIN DE TRANSACCIONES CON MYSQL

Objetivo: Al trmino de esta prctica el alumno ser capaz de implementar transacciones con Mysql. Material requerido: en la prctica 1 . En esta prctica se utilizar MySQL.que fue instalado previamente
En esta prctica demostraremos el uso de las transacciones mediante un ejemplo prctico que utilice sus mtodos commint y rollback, se utilizara la consola de mysql y la consola del sistema operativo es decir la lnea de comandos de Windows. 1. Creacin base datos Para comenzar se crear una nueva base de datos para demostrar el funcionamiento de las transacciones y sus mtodos commint y rollback para ello:
create database ejemplo; use ejemplo;

De esta forma y ya usando la nueva base de datos procederemos a crear una tabla sobre la cual realizaremos transacciones:
create table Datos( No_Control varchar(8), Nombre varchar(50), Edad int, primary key(No_Control) )engine=INNODB;
Ntese que el mecanismo de la tabla es INNODB que es que soporta operaciones de transaccin, de otro modo no funcionarn. 2. Insercin datos tabla: Procedemos a continuacin a insertar datos (ver figura siguiente) en la tabla: insert into Datos values ('08680001','Juan',21), ('08680002','Alfredo',22), ('08680003','Rodrigo',23), ('08680004','Alberto',24), ('08680005','Jose',20);
"7
Una vez hecho esto es necesario acceder a MySQL desde otro cliente (o ventana en su defecto), para poder comprobar que las transacciones funcionan, para ello lo hacemos desde el cmd como en prcticas anteriores ya se ha llevado a cabo. Una vez ya conectados a la BD ejemplo procederemos a utilizar esta sesin nicamente como espectador, observando el comportamiento de la BD durante la transaccin que se llevar a cabo desde la primera interfaz. Para ello comprobamos con una consulta para corroborar que si estamos viendo los datos actuales de la tabla datos:
select * from Datos;

Despus de corroborar esto regresamos a la primera interfaz, donde iniciaremos una transaccin para ello:
start transaction;
Una vez hecho esto procedemos realizar las operaciones necesarias para la transaccin, primeramente actualizaremos un registro de los datos existentes:
update Datos set Edad=20 where No_COntrol='08680001';

Realizamos una consulta en la ventana del espectador para ver si hay cambios en los datos:
select * from Datos;

Nota Observamos que no, se muestran alteraciones a los datos por lo tanto asumimos (al menos desde el punto de vista del observador) que no se han hecho cambios.
Nuevamente en la terminal de mysql donde se ejecuta la transaccin insertamos un nuevo registro:
insert into Datos values ('08680006','Pepe',25);

Una vez hecho esto finalizaremos la transaccin para aplicar los cambios para lo cual utilizamos: commint;
"8
Checamos en la otra ventana y nos daremos cuenta de que se realizaron cambios a los datos anteriores, con lo cual comprobamos que si se llev a cabo la transaccin, Nuevamente realizaremos otra transaccin para comprobar el funcionamiento de rollback en las transacciones:
start transaction; update Datos set Edad=65 where No_control='08680001';

Ntese que se modificar un campo sin embargo nuevamente como es parte una transaccin no se refleja en la ventana del espectador. Pero en esta ocasin se utilizar:
rollback;
Con esto se cancela la transaccin para corroborar realizamos de nuevo una consulta en ambas ventanas, Con esto comprobamos el funcionamiento de las transacciones y mtodos commint y rollback.

Para el desarrollo del reporte se deber seguir los lineamientos presentado en el anexo A, y seguir la metodologa presentada con el fin de obtener los resultados a presentar en tu reporte de prctica con la informacin proporcionada por el docente. A continuacin se muestra las pantallas con el resultado de la prctica.
Figura 3.1. Creacin base datos.
*9
Figura 3.2. Insercin de datos y comprobacin.
*1
Figura 3.3 Termino de la Transaccin2 y comprobacin.
*2
CAPTULO 4 MODELO DE CAPAS PARA EL PROCESAMIENTO DE BASE DE DATOS 4.1 Conceptos, modelos y tecnologas Modelos de bases de datos.
Un modelo es una abstraccin de la realidad, las bases de datos, se pueden clasificar de acuerdo a su modelo de administracin de datos. Un modelo de datos es bsicamente una "descripcin" de algo conocido como contenedor de datos. (Algo en donde se guarda la informacin), as como de los mtodos para almacenar y recuperar informacin de esos contenedores. Los modelos de datos no son cosas fsicas: son abstracciones que permiten la implementacin de un sistema eficiente de base de datos; por lo general se refieren algoritmos, y conceptos matemticos. Algunos modelos con frecuencia utilizados en las bases de datos:
Bases de datos jerrquicas

stas son bases de datos que, como su nombre indica, almacenan su informacin en una estructura jerrquica. En este modelo los datos se organizan en una forma similar a un rbol (visto al revs), en donde un nodo padre de informacin puede tener varios hijos .El nodo que no tiene padres es llamado raz, y a los nodos que no tienen hijos se los conoce como hojas. Las bases de datos jerrquicas son especialmente tiles en el caso de aplicaciones que manejan un gran volumen de informacin y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento. Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.
Base de datos de red ste es un modelo ligeramente distinto del jerrquico; su diferencia fundamental es la modificacin del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerrquico). Fue una gran mejora con respecto al modelo jerrquico, ya que ofreca una solucin eficiente al problema de redundancia de datos; pero, aun as, la dificultad que significa administrar la informacin en una base de datos de red ha significado que sea un modelo utilizado en su mayora por programadores ms que por usuarios finales. Base de datos relacional
ste es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. Tras ser postulados sus fundamentos en1970por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados "tuplas". Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar. Esto es pensando en cada relacin como si fuese una tabla que est compuesta por registros (las filas de una tabla), que representaran las tuplas, y campos (las columnas de una tabla). En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia(a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar para un usuario espordico de la base de datos. La informacin puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la informacin. El lenguaje ms habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estndar implementado por los principales motores o sistemas de gestin de bases de datos relacionales.
Bases de datos orientadas a objetos.

Este modelo, bastante reciente, y propio de los modelos objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento).Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos: Encapsulacin: Propiedad que permite ocultar la informacin al resto de los objetos, impidiendo as accesos incorrectos o conflictos. Herencia-: Propiedad a travs de la cual los objetos heredan comportamiento dentro de una jerarqua de clases. Polimorfismo: Propiedad de una operacin mediante la cual puede ser aplicada distintos tipos de objetos.
*"
En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definicin de la base de datos. Una operacin (llamada funcin) se especifica en dos partes. La interfaz (o signatura) de una operacin incluye el nombre de la operacin y los tipos de datos de sus argumentos (o parmetros). La implementacin (o mtodo) de la operacin se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicacin de los usuarios pueden operar sobre los datos invocando a dichas operaciones a travs de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podra denominarse independencia entre programas y operaciones. Se est trabajando en SQL3, que es el estndar de SQL92 ampliado, que soportar los nuevos conceptos orientados a objetos y mantendra compatibilidad con SQL92.
Bases de datos documentales.

Permiten la indexacin a texto completo, y en lneas generales realizar bsquedas ms potentes. Tesaurus es un sistema de ndices optimizado para este tipo de bases de datos.
Bases de datos deductivas.

Un sistema de bases de datos deductivas, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a travs de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Tambin las bases de datos deductivas son llamadas base de datos lgica, a raz de que se basan en lgica matemtica.
Gestin de bases de datos distribuida.

La base de datos est almacenada en varias computadoras conectadas en red. Surgen debido a la existencia fsica de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder as a distintas universidades, sucursales de tiendas, etctera.
4. 2 Tecnologas de conectividad de base de datos La conectividad permite el uso y creacin de bases de datos a la que puedan acudir los usuarios para hacer consultas y acceder a la informacin que les interese, es una herramienta imprescindible de cualquier sistema informativo sea en red o fuera de ella. Interfaces de Programacin (API) para uso de Conectividad en Base de Datos.
**
Las interfaces de programacin denotan el proceso de acceso y manipulacin de los datos a una base de datos, partiendo de la aplicacin. El siguiente esquema muestra 4 niveles o interfaces:
a)
La interfaz de Aplicacin: La cual abarca y/o corresponde a cada uno de los programas clientes.
b)
La Interfaz de Objetos de Acceso a Datos: Se encuentra como punto medio entre las aplicaciones y las API's que llegan a ser necesarias para el acceso a las bases de datos. Entre las tecnologas que pertenecen a la Interfaz de Objetos de Acceso de Datos encontramos: DAO (Data Access Objects), ADO (ActiveX Data Objects), RDO (Remote Data Object), RDS (Remote Data Service) y MIDAS (Middle-tier Distributed Application Service).
Su funcin es encapsular los componentes que se encuentran en la interfaz que corresponde a la de API's, con la finalidad de reducir el desarrollo de la aplicacin y los costos de mantenimiento y deben situarse en todos los equipos que ejecuten la aplicacin, ya que se encuentran casi de manera conjunta con la aplicacin. c) La Interfaz de Programacin de Aplicaciones: API (Application Programming
Interface), se encarga de mantener el dilogo con la base de datos, para poder llevar a cabo el acceso y manipulacin de los datos. Algunos de los componentes que forman parte de esta interfaz son los siguientes: OLE DB, ODBC (Open Database
*3
Connectivity), JDBC (Java Data Base Connectivity), ISAPI (Internet Server Application Programming Interface) y CGI (Common Gateway Interface). La funcin que tienen las API's, es la de ser una interfaz entre las aplicaciones y las bases de datos, llevando sta tarea unas veces a travs de los clientes y otros a travs del servidor de base de datos. Esto quiere decir, que puede darse el caso de que el cliente conste de las tres primeras interfaces o niveles, o que se encuentren las dos ltimas en el servidor. La interfaz correspondiente a la base de datos, es donde se encontrar el servidor y toda la informacin depositada en l. Para poder accesar y manipular la informacin de una base de datos, es necesario llevar a cabo la instalacin de ciertos API's o controladores, que son indispensables para efectuar la conectividad de los datos externos, y vincularlos a la aplicacin para su correcta y adecuada utilizacin.
Tecnologas de Conectividad a la Base de Datos (Interfaz de Objetos de Acceso a Datos) DAO

Un objeto de acceso a datos (DAO) es un objeto que proporciona un resumen de interfaz a algn tipo de base de datos de mecanismo o la persistencia, proporcionando algunas operaciones especficas, sin exponer los detalles de la base de datos. Se proporciona una asignacin de llamadas de aplicacin a la capa de persistencia. Este aislamiento se separa de las preocupaciones de los datos que accede a las necesidades de su aplicacin, en trminos de dominio de objetos especficos y tipos de datos (la interfaz pblica de la DAO), y cmo estas necesidades pueden ser satisfechas con una especfica de DBMS , el esquema de base de datos, etc. ( la aplicacin de la DAO). Este patrn de diseo es igualmente aplicable a la mayora de lenguajes de programacin, la mayora de los tipos de software con las necesidades de la persistencia y la mayora de los tipos de base de datos, sino que se asocia tradicionalmente con Java EE , y con las aplicaciones de bases de datos relacionales acceder a travs de la API de JDBC, debido a su origen en Sun Microsystems directrices sobre mejores prcticas [1] ("Core J2EE Patterns") para esa plataforma.
ADO y RDO.
*5
Existen varios niveles o interfaces para lograr la comunicacin o acceso a la base de datos a travs de la aplicacin. El siguiente esquema muestra 2 de los principales niveles, dentro de los cuales se encuentra ADO.
Por lo general, las interfaces de objetos de datos son ms fciles de usar que las APIS, aunque las APIs ofrecen ms funcionalidades. ADO (ActiveX Data Objects) es la interfaz de objetos de datos para OLE DB, y RDO (Remote Data Objects) es la interfaz para el objeto ODBC. ADO encapsula el API OLE DB en un modelo objeto simple que reduce el desarrollo, mantenimiento y costo de la aplicacin. Es muy fcil de usar, utiliza lenguajes de programacin como Visual Basic, Java, C++, VBScript y JScript, puede accesar datos desde cualquier recurso OLE DB y adems, es extensible. Es la interfaz utilizada por Microsoft. El modelo ADO, basado en el modelo de objetos, define una jerarqua de objetos programables que pueden ser usados por desarrolladores de pginas Web para acceder a la informacin almacenada en una base de datos. Una jerarqua es un grupo de objetos relacionados que trabajan juntos para un mismo propsito. ADO est compuesto de siete objetos, algunos de alto nivel como Connection, Command y Recordset, que pueden ser creados y eliminados por el usuario y otros con distintas funcionalidades como designar propiedades de conexin, definir sentencias y ejecutarlas, optimizacin de consultas, etc. Estos elementos se representan en la siguiente figura:
*7
Cada uno de los objetos anteriores contiene una coleccin de objetos Property. El objeto Property permite a ADO mostrar dinmicamente las capacidades de un objeto especfico. ADO permite disear sitios web que pueden acceder repetidamente a la misma base de datos usando una misma bsqueda u otra similar. Se pueden compartir conexiones y esto significa una menor carga de trabajo para el servidor de la base de datos, un tiempo de respuesta ms rpida y ms accesos a pgina con xito.
RDS.
Existe un componente llamado RDS (Remote Data Service) que ofrece el ambiente de Acceso Universal a Datos, ya sea desde Internet o la World Wide Web, creando un marco de trabajo que permite una interaccin fcil y eficiente con los datos fuente OLE DB tanto en Intranets corporativas o en Internet. RDS ofrece la ventaja de obtener por el lado del cliente resultados de datos, actualizacin y soporte para controles ADO y ofrece el modelo de programacin OLE DB/ADO para manipular datos de las aplicaciones del cliente.
Conectividad de Base de Datos a Travs de las API's.

Las API's que se describen a continuacin, son un claro ejemplo del proceso correspondiente a la conectividad de datos.
ODBC.
Open Database Connectivity (ODBC) es una interface de aplicaciones (API) para acceder a datos en sistemas gestores de bases de datos tanto relacionales como no relacionales, utilizando para ello SQL (Lenguaje de Consulta Estructurado).
*8
Todas las aplicaciones que soporten ODBC reconocern una instruccin comn de Lenguaje de Consulta Estructurado (SQL). Las aplicaciones ODBC o aplicaciones cliente envan peticiones a un servidor de bases de datos. El gestor del driver ODBC determina qu fuente de datos usar y qu driver ODBC puede comunicar con esa fuente de datos en particular. La peticin se enva luego a travs del driver al servidor normalmente una aplicacin de base de datos. Esta base de datos puede ser local, o en el mismo ordenador, o remota. Los datos solicitados se devuelven a travs del gestor del driver ODBC, entonces a la aplicacin del cliente. El lenguaje ODBC es una combinacin de llamadas de funcin ODBC API y lenguaje SQL.
JDBC.
JDBC (Java DataBase Connectivity) es una API de Java para ejecutar sentencias SQL. Consta de un conjunto de clases e interfaces escrito en lenguaje de programacin Java. Usando JDBC es fcil enviar sentencias SQL a virtualmente cualquier base de datos relacional. En otras palabras, con la API JDBC no es necesario escribir un programa para acceder a una base de datos tipo Access, otro programa para acceder a una base de datos tipo Oracle y as para cada tipo de base de datos. Uno puede escribir un solo programa usando la API JDBC y el programa ser capaz de enviar sentencias SQL a la base de datos apropiada. Y, con una aplicacin escrita en Java, uno no tiene por qu preocuparse por escribir diferentes programas para diferentes plataformas. La combinacin de JDBC permite al programador escribir una vez y ejecutar en cualquier sitio. Java, siendo robusto, seguro, fcil de usar, fcil de entender, y automticamente descargable en una red, es un excelente lenguaje base para aplicaciones con bases de datos. Lo que es necesario es una forma para que las aplicaciones Java puedan entenderse con bases de datos de diferentes tipos. JDBC es el mecanismo para hacer esto. JDBC extiende lo que puede hacerse con Java. Por ejemplo, con Java y la API de JDBC, es posible publicar una pgina web que usa informacin obtenida de una base de datos remota. O una compaa puede usar JDBC para conectar todos sus empleados (incluso si estos estn usando un conglomerado de mquinas Windows, Macintosh y UNS) a una o ms bases de datos internas va una intranet.
De una forma simple, JDBC posibilita hacer tres cosas:
39
ISAPI
Establecer una conexin con una base de datos Enviar sentencias SQL Procesar los resultados.
ISAPI (Internet Server Application Programming Interface) es la interfaz propuesta por Microsoft como una alternativa ms rpida que el CGI, y est incluida en el Servidor Microsoft Internet Information (IIS). As como los escritos CGI, los programas escritos usando ISAPI habilitan un usuario remoto para ejecutar un programa, busca informacin dentro de una base de datos, o intercambia informacin como otro software localizado en el servidor. Los programas escritos usando la interfaz ISAPI son compilados como bibliotecas de enlace dinmico (DLL - Dinamic Link Library), ya que son cargados por el servidor Web cuando ste se inicia. Dichos programas se vuelven residentes en memoria, por lo que se ejecutan mucho ms rpido que las aplicaciones CGI, debido a que requieren menos tiempo de uso de CPU al no iniciar procesos separados. Uno de los programas ISAPI ms usados es el HTTPODBC.DLL que se usa para enviar y/o devolver informacin hacia y desde las bases de datos, a travs de ODBC. Adems, ISAPI permite realizar un procesamiento previo de la solicitud y uno posterior de la respuesta, con lo cual manipula la solicitud/respuesta HTTP. Los filtros ISAPI pueden utilizarse para aplicaciones tales como autenticacin, acceso o apertura de sesin.
CGI
CGI (Common Gateway Interface) es una de las soluciones que se est utilizando ms para la creacin de interfaces Web/DBMS. Entre las ventajas de la programacin CGI, destaca la sencillez, ya que es muy fcil de entender, adems de ser un lenguaje de programacin independiente, ya que los escritos CGI pueden elaborarse en varios lenguajes. Tambin es un estndar para usarse en todos los servidores Web, y funcionar bajo una arquitectura independiente, ya que ha sido creado para trabajar con cualquier arquitectura de servidor Web. Como la aplicacin CGI se encuentra funcionando de forma independiente, no pone en peligro al servidor, en cuanto al cumplimiento de todas las tareas que ste se encuentre realizando, o al acceso del estado interno del mismo.
31
Pero el CGI presenta cierta desventaja en su eficiencia, debido al que el servidor Web tiene que cargar el programa CGI y conectar y desconectar con la base de datos cada vez que se recibe una requisicin. Adems, no existe un registro del estado del servidor, sino que todo hay que hacerlo manualmente.
4.3 Acceso a bases de datos con otros servicios de internet Uso de conectividad en base de datos va WEB.
La tecnologa llamada Web DB es utilizada por algunos servidores de bases de datos, con la cual, un usuario puede solicitar la informacin que requiera y visualizarla a modo de respuesta en una pgina Web, que ser creada y elaborada por el propio servidor de base de datos. El proceso que comprende desde la solicitud a la visualizacin de la informacin, puede ser representado de la siguiente manera:
En este esquema anterior destacan:

a) Navegador (browser): es la aplicacin mediante la cual, se tiene acceso libre a los servicios de Internet, y el medio que permite al usuario introducir la solicitud para visualizar la informacin, empleando el URL para especificar detalladamente el proceso que se desea ejecutar. b) Interfaz de Web: proporciona una interfaz para que un programa que se ejecute en el servidor genere como salida el cdigo HTML, en lugar de leer simplemente un archivo esttico de texto. Con sta interfaz se podrn crear las pginas Web de forma dinmica y/o utilizar la implementacin de formularios HTML. Esta interfaz permite tecnologas como los CGIs o aquellas otras que son propias del servidor de base de datos. c) Agente PL/SQL: es el eslabn final del proceso entre un navegador cliente y el servidor de base de datos. El agente ejecutar una llamada a un procedimiento almacenado en el servidor. Este procedimiento crear una pgina HTML dinmica
32
como salida, y el agente devolver dicha salida al cliente a travs del navegador empleando de igual manera la Interfaz de Web. d) Base de Datos (BD). En ella se mantendr almacenada la informacin; se encargar de proporcionar los datos que le hayan solicitado previamente, al momento de la ejecucin de un procedimiento por parte del Agente PL/SQL. Esta herramienta es una muy buena opcin para pequeas o medianas empresas, en las cuales llegara a resultar muy costosa la implementacin de otro tipo de tecnologas ms caras y avanzadas.
Tecnologas web para conectividad de base de datos.

El acceso a los datos se puede realizar mediante distintas tecnologas Web, entre las que destacan:
NET
Es la ltima aplicacin desarrollada por Microsoft e incluye ASP+, C#, mientras deja de lado las anteriores inversiones de Microsoft en Java (y programas relacionados como Microsoft Visual J++). Todas estas soluciones se basan en estndares propietarios, aunque en la plataforma .NET se incluye soporte a SOAP.
JSP
El acceso a base de datos desde JSP (Java Server Pages), al igual que desde Servlets, se apoya en la tecnologa JDBC de Java. Para ello se precisa un controlador o driver que proporcione el acceso a la base de datos subyacente (MySQL). JSP es un lenguaje muy potente de cdigo abierto que permite crear de manera fcil aplicaciones Web. J2EE (Java 2 Enterprise Edition) es una tecnologa de las ms utilizadas.A veces se utiliza el trmino: servidores de aplicaciones Java para referirse a aquellos servidores de aplicaciones que implementan de forma adecuada las soluciones propuestas por J2EE. J2EE es una especificacin que propone un estndar para servidores de aplicaciones. Define diferentes tecnologas e indica cmo deben trabajar juntas. Todos los servidores de aplicaciones J2EE deben pasar un test de compatibilidad, que garantiza la correcta implementacin de las tecnologas Java. Muchos grandes fabricantes como IBM, Sun Microsystems, Hewlett-Packard, Oracle, Sybase, etc. utilizan J2EE. Sin embargo, Java consume una gran cantidad de recursos y la mquina virtual Java es lenta.
PHP
PHP o Hypertext Preprocessor ofrece interfaces propias de acceso a multitud de fuentes de datos: BBDDs (MySQL, mSQL, Oracle 8, etc.), servidores de directorio (LDAP), texto en XML, etc. Todas ellas estn documentadas en la pgina Web de PHP.
Servidor de aplicaciones
Disear hoy una web se ha convertido en una labor compleja puesto que se exigen conocimientos de arquitectura de la informacin en sus distintas facetas y una de ellas, es administrar y gestionar bases de datos. La Web es aqu entendida como interfaz de software que permite una serie de funcionalidades como que el usuario pueda interrogar y consultar de forma directa a la base de datos y obtener las referencias o el acceso directo a los recursos o documentos buscados.
Los SGBD suelen incluir herramientas de administracin que permiten ajustar el rendimiento en funcin de las necesidades particulares. Muchas empresas cuentan son sus propios administradores de bases de datos, pero tambin hay muchas otras que no, y lo ms probable es que el diseador web tenga que administrar tambin las bases de datos. Sin embargo, la complejidad del diseo ha dado lugar al nacimiento de nuevas profesiones
3"
que se encargan de llevar a cabo procesos tales como el anlisis o minera de datos (data mining) o la distribucin de los mismos (data warehouse). Como se ha afirmado anteriormente, existen sistemas de gestin de bases de datos tanto de uso libre, como soluciones comerciales de pago. Una de las tendencias ms claras en la Web actual es integrar el acceso a datos en los servidores de aplicaciones y esto ha conducido a que casi todos los fabricantes de sistemas de gestin de bases de datos comerciales ofrezcan sus propios servidores de aplicaciones que se integran a bajo nivel con los productos de bases de datos de la misma empresa. Como ejemplos, tenemos Sybase Enterprise Server y Oracle Application Server. Un servidor de aplicaciones no es ms que un cambio de nombre para algunos servidores Web de nueva generacin que permiten construir aplicaciones. Suelen asociarse con servidores de alto rendimiento pensados para dar servicio a sitios Web con grandes necesidades para gestionar movimientos de datos, afluencia de visitas, atencin de transacciones hacia bases de datos, etc. Generalmente los fabricantes del sector tienen a disposicin del pblico un servidor Web bsico y otro con multitud de extensiones integradas al que llaman servidor de aplicaciones.
Un servidor de aplicaciones clsico se apoya en un modelo cliente/servidor de tres capas: a) Presentacin: una interfaz, generalmente grfica que reside en los clientes. El ejemplo tpico es un navegador. b) Lgica de negocio: donde reside el servidor de aplicaciones y el conjunto de programas a los que da soporte. c) Almacenamiento: generalmente una base de datos.
Los servicios aadidos a los servidores de aplicaciones suelen ser: generacin de cdigo HTML XML, trabajo con bases de datos y gestin de transacciones, funcionamiento multiproceso para atender a distintas peticiones, establecimiento de distintas sesiones para acceso de usuarios, mecanismos de seguridad y autentificacin, monitorizacin para evitar fallos, etc. Los servidores ms utilizados son: Apache, Microsoft IIS, iPlanet de Netscape, Zeus, thttpd, Rapidsite, etc. De cualquier forma, hay que tener en cuenta que, aparte de cmo se almacenan los datos en la base de datos, una cuestin importante es la interfaz de presentacin de esos datos. Las interfaces o presentaciones de una aplicacin hacia el usuario han ido evolucionando a travs del tiempo y, actualmente se utilizan muchos lenguajes visuales denominados de cuarta generacin como son: Visual Fox Pro,
3*
Visual Basic, Delphi, etc. Tambin los ambientes Web, se han vuelto una opcin viable para las aplicaciones distribuidas en Internet y esto se ha logrado mediante el uso de ciertas herramientas como son: HTML, DHTML y JavaScripts. Con tecnologas como el scripting y DHTML, los desarrolladores de aplicaciones pueden crear acciones con interfaces de Web funcionales, basadas para la entrada de datos o salida de resultados de bsqueda sin usar controles comunes o applets. La tendencia es que las empresas intenten mejorar la interfaz hacia el usuario para que ste tenga la oportunidad de explotar la mayor cantidad de informacin, en una nica pantalla o ventana del sistema.
33
4.4 Arquitectura de servicios abiertos
4.4.1 ODBC. Se basa en cuatro componentes: Aplicaciones: son las responsables de interactuar con el usuario y de llamar a las funciones ODBC para ejecutar sentencias SQL y recoger los resultados. El driver manager: se encarga de cargar y llamar a los drivers segn lo demanden las aplicaciones. Drivers: procesan las llamadas a las funciones ODBC, ejecutan sentencias SQL y devuelven los resultados a las aplicaciones. Son tambin responsables de interactuar con cualquier capa software necesaria para acceder a las fuentes de datos, como puede ser el software de red. Orgenes de datos: consisten en conjuntos de datos, ms todo lo que pueda ser necesario para llegar hasta ellos; sistemas operativos, gestores de bases de datos, redes de comunicacin, etc. Handles en ODBC. Un handle no es ms que una variable de una aplicacin, en la cual el sistema operativo es capaz de guardar informacin sobre la aplicacin y sobre alguno de los objetos que maneja dicha aplicacin. ODBC usa tres tipos de handles: De sistema (environment): es el handle de contexto global. Todo programa que utilice ODBC comienza solicitndolo y acaba liberndolo. Slo puede haber uno por aplicacin. De conexin (connection): maneja toda la informacin relativa a una conexin. Identifica el driver que debe ser utilizado al realizar una conexin y en las llamadas posteriores a funciones ODBC. Puesto que se permiten varias conexiones, una aplicacin puede solicitar varios. De sentencia (statement): se utiliza para manejar todo el procesamiento relativo a una sentencia SQL, desde su ejecucin hasta la recogida de datos. En Windows, los handles se utilizan para acceder a estructuras de datos de las cuales slo Windows conoce los detalles. Esto tambin se cumple en ODBC: las aplicaciones nunca miran el contenido de los handles, y tampoco manipulan el contenido a que hacen referencia. Este concepto, conocido como ocultacin de la informacin, es uno de los principios bsicos de la programacin orientada a objeto. Todas las funciones ODBC usan un handle como primer parmetro.
35
Controladores y orgenes de datos El controlador (driver) es un dispositivo intermedio entre los datos y el programa de acceso a dichos datos. Los controladores se almacenan en ficheros con extensin DLL (libreras dinmicas de Windows) que generalmente se copian en el directorio SYSTEM de Windows. Tiene que haber un controlador para cada formato de bases de datos que se quiere utilizar. Los orgenes de datos (data source) son los ficheros o directorios especficos donde se encuentran los datos. En el caso de las bases de datos locales (dBase, Paradox, Access, etc.) el origen de datos nicamente incluye la localizacin de los datos, no siendo necesario que est disponible el gestor propietario de dicho formato. Sin embargo, en los servidores SQL no slo es necesario indicar donde se encuentran los datos, sino que adems es necesario es necesario que est disponible el propio programa servidor de datos (SQL Server, Oracle, SQL Base, etc.). El concepto de origen de datos es independiente del controlador y de los datos. Por ejemplo, se podran crear dos orgenes de datos diferentes para la misma base de datos, uno de ellos configurado para usar la base de datos en modo slo lectura y el otro con autorizaciones para leer y escribir en la base de datos. Cuando se ejecuta el icono ODBC del Panel de Control de Windows, aparece una ventana con la lista de los orgenes de datos, mostrando el nombre del origen de datos y, entre parntesis, el controlador asociado con cada uno. Esta ventana permite, adems de conocer los orgenes de datos instalados y el controlador asociado con cada uno, configurar, aadir y borrar los orgenes de datos. Gestin de los orgenes de datos. Para instalar un origen de datos, debe pulsar el botn Agregar. Lo primero que nos pide es que identifiquemos el controlador con el que se asociar el origen de datos que se est creando. Por supuesto, en el caso de que se trate de un origen para un controlador nuevo, primero debe instalarse el controlador y luego instalar el origen de datos para dicho controlador. Una vez seleccionado el controlador, aparece una ventana en la que es necesario definir ciertas caractersticas del origen de datos. Estas caractersticas varan en funcin de las opciones soportadas por el formato del origen de datos, pero siempre debe indicarse un nombre propio para identificar el origen (que no tiene por qu coincidir con el nombre del directorio o fichero donde se encuentren los datos), y un directorio o nombre de fichero que corresponda al lugar donde se almacenan los datos. En la lista de orgenes de datos hay otros botones adems de Agregar. El botn Configurar permite definir los valores fundamentales del origen de datos. Al activar este botn aparece la misma ventana que se utiliz para crear el origen de datos. El botn Eliminar borra el origen de datos seleccionado (no borra fsicamente el fichero de la base de datos al que est asociado dicho origen).
37
Y el botn Opciones permite establecer algunas opciones generales para toda la gestin ODBC. Entre esas opciones est la posibilidad de registrar las llamadas de ODBC en un fichero especfico con extensin LOG. Desactivar esta opcin dar un mejor rendimiento de velocidad a la aplicacin que est haciendo llamadas ODBC; sin embargo, registrar todo lo que ocurre puede ser til cuando se produzcan errores y as poderlos documentar. Toda la gestin de orgenes de datos se realiza mediante el fichero ODBC.INI. De hecho, el administrador de ODBC lo nico que hace es gestionar el contenido de dicho fichero. En el fichero ODBC.INI se encuentra la seccin general [ODBC Data Sources], que almacena la lista de los orgenes de datos instalados. A continuacin se establece una seccin para cada origen que guarda los valores de cada una: directorio, controlador, etc. Gestin de controladores. Debe haber un controlador para cada formato de bases de datos que queramos gestionar. Para acceder a las opciones relativas a los controladores hay que pulsar el botn Controladores en la ventana principal del Administrador ODBC (la ventana con la lista de los orgenes de datos instalados). Al pulsar dicho botn, aparece una ventana con la lista de los controladores ODBC instalados. En esa ventana existen botones para borrar e instalar controladores. La instalacin de un controlador exige tener un disquete con dicho controlador. En la seccin general [ODBC Drivers] del fichero ODBCINST.INI aparecen los controladores instalados. Despus existe una seccin para cada controlador donde se detallan parmetros como su situacin en el disco. 4.4.2 JDBC La interaccin tpica con una base de datos consta de los siguientes cuatro pasos bsicos: Abrir la conexin a la base de datos Ejecutar consultas contra la base de datos Procesar los resultados Cerrar la conexin a la base de datos
Pero JDBC abstrae al desarrollador del Sistema Gestor que tenga nuestra base de datos por lo que tendremos que cargar inicialmente el controlador que lleve a cabo dicha funcin, introduciendo as un nuevo paso anterior a todos los dems: Cargar la clase del controlador JDBC. Estos pasos se contemplan en el esquema siguiente:
38
JDBC hace de intermediario entre nuestro programa escrito en Java y la base de datos para cumplir con estos pasos, como se muestra en la siguiente figura:
En los siguientes puntos se aclarar como llevar a cabo los pasos descritos anteriormente en JDBC haciendo uso de las 16 interfaces, 8 clases y 4 tipo de excepciones que aade. Que junto con las 12 interfaces y 2 clases que aade la API Optional Package (JDBC 2.0) dan un amplio abanico de funcionalidades.
59
Cargar la clase del controlador JDBC. Para utilizar un controlador JDBC es necesario registrarlo antes con el administrador de controladores. Esta tarea se puede realizar de varias formas pero todas y cada una de ellas exigen una llamada a DriverManager.registerDriver(). Una de ellas es aprovecharse de los mtodos ofrecidos y que liberan de trabajo. El cdigo resultante sera el siguiente (en este caso se carga un controlador de tipo 1). try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); }catch (ClassNotFoundException e) { System.out.println("Imposible encontrar el driver:" + e.getMessage()); } Internamente se llama al mtodo antes citado para registrar el driver que pasamos como parmetro al mtodo Class.forName. Otra forma es poner el nombre del controlador en la propiedad del sistema jdbc.drivers que DriverManager carga durante su iniciacin. En JDBC 2.0 se ahorra tener que escribir el nombre de la clase controlador y de las URL de las bases de datos ya que se guardan en el servicio de nombres. Todo ello a travs del objeto DataSource. El ejemplo quedara como a continuacin: InitialContext ctc=new initialContext(); DataSource ds =(DataSource) ctx.lookup (java:comp/env/jdbc/lyricnote_internal); Connection con = null; try{ con = ds.getConnection(); ... } finally{ if (con = null) con.close(); }
51
Abrir la conexin a la base de datos. Una vez cargado y registrado el driver, se puede crear la conexin a la base de datos con DriverManager el cual proporciona tres mtodos para hacerlo: GetConnection(String url) GetConnection(String url, String userID, String password) GetConnection(String url, Properties prop)
El administrador de controladores mantiene una lista de controladores registrados, as cuando se invoca el mtodo getConnection() pregunta a cada controlador si acepta la URL especificada. Si la acepta devuelve un objeto Connection y si no devuelve null. En caso de usar DataSource el parmetro URL no se necesita por las razones anteriormente vistas. Si por el contrario no usamos DataSource habremos de saber que el argumento URL es una cadena de la forma: <protocolo>:<subprotocolo>:<subnombre> Protocolo es siempre jdbc. El subprotocolo se refiere al controlador que se va a usar y ha suministrado laEmpresa distribuidora (odbc en el caso de un controlador de tipo 1). Por ltimo, el subnombre identifica la base de datos a la que conectarse, pudiendo contener parmetros de conexin.
Ejecutar consultas contra la base de datos. JDBC permite acceder a la base de datos de una forma orientada a objetos, por lo que ofrece una serie de clases en las cuales se encapsula el texto, el estado de ejecucin y los resultados de las instrucciones SQL ejecutadas. La interfaz java.sql.Statement, enva los comandos SQL a la base de datos para ser ejecutadas, y pueden ser los siguientes: Comando de definicin: CREATE TABLE y CREATE INDEX. Comando de manipulacin: INSERT y UPDATE Una instruccin SELECT
Los comandos de manipulacin devuelven el nmero de filas modificadas mientras que la instruccin SELECT devuelve el denominado conjunto de resultados.
52
Al tratarse de una interfaz java.sql.Statement no posee constructor y el objeto se crea en la llamada a Connection.createStatement(). Connection con = null; try{ con = ds.getConnection(); Statement stm=con.createStatement(); ... } finally{ if (con = null) con.close(); } Con esto ya tenemos el objeto necesario para poder llevar a cabo las instrucciones que queramos sobre la base de datos. Disponemos de cuatro mtodos para ejecutar comandos: executeUpdate: para hacer INSERT, UPDATE o DELETE. Y tambin para
CREATE TABLE. Devuelve el n de filas actualizadas. Int n_rows = stm.executeUpdate(UPDATE ); executeQuery: para instrucciones SELECT, devolviendo el conjunto e resultados.
ResultSet rs = stm.executeQuery(SELECT ); excute: se puede usar con cualquier propsito pero est concebida para las instrucciones que devuelven un contador de actualizacin, conjunto de resultado mltiple o una combinacin de ambos. Devuelve un booleano indicando cul de estas opciones es, proporcionando un mtodo para recuperar los resultados de cada una de ellas.
Boolean i = stm.execute (sql_line); executeBatch(): sirve para enviar un conjunto de instrucciones de actualizacin que se han de ejecutar en un solo lote. Adems de ofrecer los mtodos clearBatch, addBatch para editar el conjunto de instrucciones que se quieren ejecutar.
stm.clearBatch (); stm.addBatch (line_1); . stm.addBatch (line_n); int[] counst = stm.executeBatch();
Adems esta interfaz ofrece otras dos subinterfaces que amplan su funcionabilidad PreparedStatement y CallableStatement: PreparedStatement: emplea SQL precompilado en vez de sentencias normales. Esto mejora el rendimiento si la instruccin se realiza en multitud de ocasiones. La cadena hay que pasrsela a la hora de crear el objeto y no en el executeQuery. En la sentencia SQL podemos aprovechar las ventajas del tipo String y usar ? para hacer que las instrucciones no sean estticas.
PreparedStatement pstm=con.prepareStatement(sql_line); pstm.executeQuery(); CallableStatement: Mejora de la anterior. Se emplea para ejecutar procedimientos almacenados si es que la base de datos lo permite. Los procedimientos almacenados no son otra cosa que instrucciones SQL almacenadas en la propia base de datos (Viene ya hechas en la base de datos).
CallableStatement cstm=con.prepareCall(call myproc(x,y)); cstm.executeQuery(); Procesar los resultados. Como se ha visto executeQuery de las diferentes interfaces devuelven bien el n de lneas modificadas si realizan una actualizacin, un ResultSet en caso de ser una consulta, as que veremos cmo tratar esta clase especial. El conjunto de resultados es una lista ordenada de filas de tabla en JDBC. Para extraer los resultados de este conjunto de datos se puede ayudar uno de los siguientes mtodos: Para desplazarse por el conjunto de resultados slo se dispone de next(). Para recuperar los valores de las columnas deseadas se dispone de:
ResultSet.getXXX(numero_col) o ResultSet.getXXX(nombre_col), donde XXX es un tipo de dato JDBC. while(rs.next()) { out.println("<tr>"); out.println("<td width=\"33%\">"+ rs.getString(\"Nombre\")+"</td>"); out.println("<td width=\"33%\">"+rs.getString(\"Apellidos\")+"</td>"); out.println("<td width=\"33%\">"+ rs.getInt(\"Dni\")+"</td>"); out.println(</tr>); }
5"
Los ResultSet en las primeras versiones de JDBC no eran explorables en todos los sentidos sino que haba que empezar por el principio y seguir esa misma direccin, pero con JDBC 2.0 se puede empezar por donde se quiera y seguir por cualquier sitio con solo asignarle las propiedades necesarias en la creacin. A esto se le conoce con el nombre de conjunto de resultados desplazables. Esta version de JDBC aade estos mtodos: isAfterLast(), isBeforeFirst(), isFirst(), isLast().Absolute(), relative(), previous(), first(), last(), beforeFirst() y afterLast(). Otra propiedad que con JDBC 2.0 le podemos asignar al conjunto de resultados es que se pueda actualizar las columnas, aadir las filas o borrar las ya existentes. Llamndose conjunto de resultados actualizables. Simplemente con aadir, quitar o modificar capos en el conjunto de resultados se actualizan las tablas que residen en la base de datos. Se ha de tener en cuenta, aunque no se desarrolle con profundidad, que JDBC incluye dos interfaces para el manejo de metadatos, los cuales constituyen una gran informacin de conexiones y conjuntos de resultados. Estas interfaces son DatabaseMetaData y ResultSetMetaData. Cerrar la conexin a la base de datos. Cuando ya no se desee mantener un dilogo con la base de datos se optar por cerrar la conexin. Este es el paso ms sencillo de todos, basta con llamar al mtodo Connection.close(). 4.4.3 IDAPI IDAPI es la API de BDE. Est formada por un conjunto de funciones que pueden ser utilizadas por cualquier lenguaje de programacin capaz de manejar DLLs de Windows, aunque est optimizado para trabajar con C/C++. Al igual que BDE, IDAPI se ha diseado segn una filosofa orientada a objetos. Debido a esto, las aplicaciones que la manejen utilizan una serie de objetos, entre los que destacan: Drivers: cada driver es cargado automticamente en el momento en que una aplicacin requiere de ste una accin concreta. En ese momento, todos aquellos parmetros configurables relativos al mismo que se encuentren en el fichero de configuracin de IDAPI se utilizan para inicializarlo. Bases de datos: una base de datos se maneja a travs de un handle al objeto, que es creado en el momento en el que se le ordena a IDAPI abrir una base de datos.
5*
Cursores: son los que permiten acceder a los contenidos de las tablas de una base de datos o a los resultados de la ejecucin de una consulta (query). Todas las operaciones de manipulacin de datos y de posicionamiento en la tabla se realizan a travs del cursor. Se puede cerrar un cursor en cualquier momento, tambin es posible tener simultneamente abiertos varios cursores sobre una misma tabla. Querys: estos objetos contienen un query (sentencia SQL vlida) cuya validez ya ha sido comprobada por BDE, dispuesto a ser enviado para su ejecucin.
4.5 CORBA
Para facilitar el desarrollo de aplicaciones basadas en objetos, se cuenta con un marco de trabajo o entorno de programacin como OLE [Cha96], ActiveX [Cha96], OpenDoc [OH95], donde el programador va seleccionando el componente u objeto que necesita para el desarrollo de la aplicacin. Para resolver el problema de la integracin de procesamiento de objetos distribuidos, surgen modelos de compaas como Microsoft que propone su propio modelo de objetos distribuidos conocido como Modelo para Objetos y Componentes Distribuidos (DCOM) [Ses97], Sun MicroSystems con los JavaBeans [Sun97]. Por su parte la tecnologa orientada a objetos y los sistemas distribuidos se unen para proponer una nueva tecnologa de software basada en objetos distribuidos (coordinacin, arquitectura de interaccin concurrente), con el fin de conciliar las diferentes interfaces que ofrecen los proveedores para el acceso a los objetos.
53
Cliente: Es la entidad, que requiere un servicio de uno o ms objetos. Operacin: Denota un servicio que una interfaz proporciona al cliente. Requerimiento: Es un mensaje enviado por el cliente para el requerimiento de un servicio, de manera conceptual el objeto interpreta los mensajes y decide qu servicio va a desarrollar. Atributo: Es una propiedad asociada con una interfaz, que es exportada a un cliente, un atributo es equivalente a las operaciones para la lectura y la modificacin de algn dato de un objeto. Interfaz: Es la descripcin de un conjunto de posibles operaciones que un cliente puede requerir de un objeto. Referencia a un objeto: Es un valor que denota a un objeto en particular, esta es usada cada vez que se realiza un requerimiento a un objeto. Identificador de Objetos: Los objetos son identificados mediante un identificador conocido IORs (Interoperable Object Reference). Objeto: es una entidad que proporciona uno o ms servicios que pueden ser solicitados por un cliente. 4.5.1 Arquitectura de CORBA.
CORBA presenta un modelo de objetos distribuidos que permiten el intercambio de informacin entre objetos localizados en diferentes lugares geogrficos, bajo una arquitectura cliente/servidor. Simplificando el problema de la interoperabilidad ya que proporciona un mecanismo consistente de acceso a los servicios y la comunicacin entre componentes u objetos distribuidos heterogneos mediante la definicin de un conjunto de servicios comunes y la definicin de las interfaces que especifican las restricciones en las relaciones de los objetos, con el fin de garantizar la mutua compatibilidad en la sintaxis de los requerimientos y sus formatos de datos. Permitiendo definir los mecanismos mnimos necesarios para que los objetos se comuniquen a travs de distintos lenguajes de programacin, sistemas operativos y redes de computadoras. CORBA es una especificacin abierta para la interoperacin entre componentes de software distribuidos u objetos. La arquitectura de CORBA, est formada bsicamente: Objetos de aplicacin: Son los componentes especficos para la construccin de aplicaciones finales de usuario. El OMG no proporciona estndares para estos objetos ya que es responsabilidad del usuario la especificacin y desarrollo. Repositorio de Interfaces: El ORB de CORBA proporciona un catlogo de interfaces que contiene la informacin disponible para describir las funciones que proporciona cada objeto.
55
Repositorio de Implantaciones: Contiene la informacin que permite al ORB localizar y activar las implantaciones de los objetos. Cliente Stubs (Interfaz de invocacin esttica): Proporciona un API especifico para la invocacin de los objetos CORBA. Una aplicacin cliente puede invocar la implementacin del objeto utilizando directamente el stub cliente, los stubs cliente/servidor son generados utilizado el compilador de la IDL. Interfaz de Invocacin Dinmica: Permite definir e invocar a los objetos dinmicamente, CORBA proporciona un API para obtener la informacin de las interfaces del objeto servidor, crear los requerimientos, generar parmetros para realizar la invocacin remota y obtener los resultados. Adaptador de Objetos: Es el mecanismo para realizar las instancias de la implementacin del objeto, el adaptador de objetos es la interfaz entre el ORB y la implementacin del objeto. Los esqueletos estticos: Proporcionan la interfaz esttica al objeto servidor. Este contiene el cdigo necesario para el envo de un requerimiento a un mtodo remoto del objeto que el cliente esta invocando. Los esqueletos son generados por el compilador de la IDL de CORBA. Interfaz del ORB: Proporciona APIs (Application Programming Interface), para los servicios locales del ORB. 4.5.2 El Lenguaje de definicin de Interfaces.
En CORBA se simplifica el problema de la interoperabilidad ya que nicamente el ORB conoce los detalles de la Implementacin de las interfaces de los objetos. La especificacin de la interoperabilidad entre el cliente y el servidor es definida en la IDL (Lenguaje de Definicin de Interfaces), en donde se declara el conjunto de operaciones accesibles por el cliente (excepciones, tipo de atributos, etc.). La IDL permite especificar el servicio que proporciona un componente u objeto en funcin de las interfaces que permite encapsular dentro de una clase al cdigo del objeto. La IDL especifica los atributos de los objetos, sus antecesores, las excepciones que generan, los eventos que emite y los mtodos que soporta, incluyendo tipos de parmetros (entrada, salida, o ambos). Los componentes deben definirse y publicarse utilizando este lenguaje, posteriormente la plataforma CORBA ser la encargada de facilitar el acceso a los objetos. El lenguaje IDL es puramente declarativo ya que simplemente se define el nombre y los parmetros de los servicios ofrecidos por un objeto y es independiente de su implementacin o la sincronizacin con otros objetos. Los mtodos especificados mediante IDL pueden ser implementados e invocados, independientemente del lenguaje de programacin o del sistema operativo.
57
Actualmente se tienen implementaciones para los lenguajes de programacin C, C++, Java, SmallTalk, Ada, COBOL, etc.
4.5.3 Programacin en CORBA. El proceso de programacin bajo CORBA es mostrado en la Figura 2. A continuacin se presenta un ejemplo para el desarrollo de una aplicacin que permite enva una secuencia de cadena de caracteres a un objeto remoto el cual lo retorna como eco. Declaracin en la IDL. Consiste en definir en un archivo Count.idl, los tipos de datos del estado del objeto formado por un entero largo (lnea 7), la interfaz del objeto se define en lnea 5. Se realiza la definicin del mtodo del objeto remoto long increment (), el cual retorna el nmero incrementado (lnea 8). A continuacin se presenta la declaracin del archivo count.idl:
58
1 // Count.idl 2 3 module Counter 4{ 5 interface Count 6 { 7 attribute long sum; 8 long increment(); 9 }; 10 }; 4.5.3.1 EL Precompilado IDL para Java Se utiliza el compilador de IDL para integrar el modelo de objetos a un lenguaje de programacin como Java, en este caso particular se utiliz el compilador IDL de Sun que es llamado idlj, un ejemplo de la compilacin es presentado a continuacin: idlj oldImplBase fall Count.idl <Enter> El compilador tomar como entrada el archivo count.idl, genera el codigo formado por el paquete Counter, y un conjunto de clases. La definicin de la interface Counter, se convierte en un paquete Counter. Las lneas de cdigo de la implementacin del objeto servidor CountServer.java, se muestran a continuacin: import Counter.*; import java.net.*; import java.io.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; class CountServer { static public void main(String[] args) { try{ // Crea y inicializa el ORB ORB orb = ORB.init(args, null); // Crea el servant y los registra con el ORB PServant Pref = new PServant("My Count"); orb.connect(Pref); // Obtiene el contexto para el servidor de nombre org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
79
NamingContext ncRef = NamingContextHelper.narrow(objRef); // Crear la referencia del objeto con el servidor de nombre NameComponent nc = new NameComponent("My Count", ""); NameComponent path[] = {nc}; ncRef.rebind(path, Pref); System.out.println("Servidor activo My Count" ); // Espera la invocaciones con el cliente java.lang.Object sync = new java.lang.Object(); synchronized(sync){ sync.wait(); } } catch(Exception e) { System.err.println("ERROR: " + e); e.printStackTrace(System.out); } }}//-Al observar este cdigo es necesario observar, que el objeto servidor tiene un nombre, y es implementado por una clase, a partir de estas consideraciones nicamente falta desarrollar el cdigo que implementa los mtodos del objeto. 4.5.3.2 Agregar la Implementacin del Objeto. Consiste en escribir el cdigo para el mtodo increment. A continuacin se presenta el cdigo de la clase PServant, que realiza la implementacin de este mtodo: class PServant extends _CountImplBase { PServant(String name) { super(name); } public int increment () { sum++; return sum; } } En la clase PServant se puede observar que hereda de la clase _CountImplBase que es generada por el precompilador de CORBA para java ( ver el punto 3.1).
71
4.5.3.3 Construccin del cliente y compilacin de todos los componentes. En la construccin de la aplicacin cliente CounClient.java, se hace la invocacin del mtodo del objeto remoto increment(): import Counter.*; class CountClient { public static void main(String args[]) { Count Ref=null; try { // Inicializa el ORB System.out.println("Initializing the ORB"); try { ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references ("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // Resuelve la referencia al servidor de nombre de CORBa NameComponent nc = new NameComponent("My Count", ""); NameComponent path[] = {nc}; Ref = CountHelper.narrow(ncRef.resolve(path)); } catch(Exception e) { System.out.println("Error al conectarse al Servidor MyCount"); e.printStackTrace(System.out); } // end try // Inicializa el valor inicial de suma a 0 System.out.println("Setting sum to 0"); Ref.sum((int)0); // Calcula el tiempo de inicio long startTime = System.currentTimeMillis(); // Incrementa el tiempo en 1000 System.out.println("Incrementing"); for (int i = 0 ; i < 1000 ; i++ ) { Ref.increment(); } // Calcula el tiempo de paro ; imprime la estadstica long stopTime = System.currentTimeMillis(); System.out.println("Avg Ping = " + (( stopTime - startTime) /1000f) + " msecs"); System.out.println("Sum = " + Ref.sum()); } catch(Exception e)
72
{ System.err.println("System Exception"); System.err.println(e); } } Finalmente se compilan para crear la aplicacin cliente/servidor. Mediante los siguientes comandos: C:\> javac CountServer.java <Enter> C:\> javac CountClient.java <Enter> 4.5.4 Ejecucin del cliente y el servidor. En primera instancia es necesario ejecutar el servidor de nombre de CORBA (SNC) para invocar una instancia del objeto, el SNC se encuentra en el directorio bin donde se realiz la instalacin de java, el cual ejecutamos mediante el siguiente comando: C:\> tnameserv,.<Enter> Si este se ejecuta con xito se mostrara la siguiente pantalla:
TransientNameServer: estableciendo puerto para referencias a objeto iniciales en: 900 Listo. Posteriormente es necesario ejecutar el servidor mediante el siguiente comando C:\Count> start java CountServer, el cual despliega el siguiente mensaje:
El cliente se ejecuta mediante C:\Count>java CountClient.
Practica Carrito de Compras
Para poder utilizar el software del carrito de compras es necesario primeramente tener instalado Tomcat para poder correr aplicaciones JSP.
7"
Previamente hay que configurar las variables de entorno necesarias para poder ejecutar archivos JSP: JAVA_HOME En esta variable de entorno hay que indicarle el directorio de instalacin del JDK, para que puedan compilarse los archivos JSP.
CATALINA_HOME En esta variable se indica el directorio de instalacin de Tomcat.
7*
Conector mysql-connector-java-5.1.18-bin Es necesario colocar este conector en la carpeta lib del directorio de instalacin de Tomcat, para que puedan realizarse aplicaciones con conexin a bases de datos.
CLASSPATH En esta variable hay que indicarle el directorio donde se encuentra el conector JDBC para las aplicaciones con bases de datos, en este caso se encuentra en el directorio lib donde lo posicionamos previamente.
Una vez configuradas las variables de entorno necesarias para nuestras aplicaciones JSP procedemos a crear la base de datos necesaria para utilizar el carrito de compras.
73
En la consola de MySQL: create database productos; use productos; create table articulos (clave varchar(3), nombre varchar(50),precio int); insert into articulos values (ABC,Lapicero,25);
Posteriormente creada la base de datos y ya con registros procedemos a crear el proyecto para el Catalogo de compras. En la carpeta Webapps creamos una carpeta llamada Catalogo y ah pondremos el cdigo .jsp del carrito de compras.
75
Procedemos a abrir el navegador vamos a Tomcat: localhost:8080\Catalogo Hecho esto nos muestra el navegador los productos que se insertaron en la base de datos que se cre previamente.
77
El cdigo: Catalogo.jsp <% Connection con; String url = "jdbc:mysql://localhost/productos"; String usuario = "root"; String password = ""; try { Class.forName("com.mysql.jdbc.Driver").newInstance(); con = DriverManager.getConnection(url,usuario,password); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("Select clave, nombre, precio from articulos"); %> En esta seccin de cdigo se establece la conexin con la base de datos, para ello nos auxiliamos del conector JDBC, indicndolo en la instanciacin de la clase para crear la conexin, tambin se le indica el nombre de la base de datos a la cual se conectar, as mismo el usuario y contrasea para realizar la conexin. En la siguiente parte una vez establecida la conexin se crea un statment para realizar la consulta, en este caso es un select indicndolos campos y la tabla de donde queremos extraer datos, posteriormente esa consulta la almacenamos en un resultset para extraer los datos obtenidos ms adelante. while (rs.next()) { String fclave = rs.getString(1); String fnombre = rs.getString(2); double fprecio = rs.getDouble(3); %> <TR> <TD><%=fclave%></TD> <TD><%=fnombre%></TD> <TD><%=fprecio%></TD> <TD> <form name="form1" method="post" action="Carrito.jsp"> <input type="hidden" name="clave" value="<%=fclave%>"> <input type="submit" name="Submit" value="Comprar"> </form> </TD> </TR> <% } rs.close(); rs = null;
78
stmt.close(); stmt = null; con.close(); } catch(Exception e) { System.out.println("Error al conectarse: " + e.toString()); }%> En esta seccin del cdigo utilizamos el resulset donde almacenamos la informacin para mostrarla en una tabla en el navegador, esto lo hacemos a travs de un ciclo while, que imprime en el documento los artculos y sus correspondientes botones para realizar la compra. Carrito.jsp <% Connection cn = null; String host = "localhost"; String nombreBd = "productos"; int puerto = 3306; String usuario = "root"; String password = ""; String clave = ""; String nombre = ""; String detalles = ""; String precio = ""; String url ="jdbc:mysql://"+host+":"+puerto+"/"+ nombreBd; NumberFormat formato = NumberFormat.getCurrencyInstance(); try { Class.forName("com.mysql.jdbc.Driver").newInstance(); cn = DriverManager.getConnection(url,usuario,password); clave = request.getParameter("clave"); Statement stmt = cn.createStatement(); ResultSet rs = stmt.executeQuery("Select clave, nombre, precio from articulos where clave = '"+ clave+"'"); En esta pgina recibimos a travs del formulario del Catalogo.jsp la clave de los artculos que se les dio comprar, una vez hecho esto nuevamente se establece la conexin con la base de datos de la misma manera que en la pgina anterior, una vez conectados utilizamos la clave que obtuvimos del formulario para realizar una consulta especfica, por clave en este caso, y encontrar los artculos para aadirlos al carrito.
89
while(rs.next()) { clave = rs.getString(1); nombre = rs.getString(2); precio = rs.getString(3); } } finally { if(cn != null) { cn.close(); } } %> Ya realizada la bsqueda, se muestra los resultados en el documento a travs de un while, conservando las bsquedas realizadas (o compras hechas) con anterioridad, solo aadiendo la clave ms reciente.
Practica de Uso de Herramienta CASE para generar cdigo SQL desde un diagrama E-R grfico.
En esta prctica veremos cmo utilizar la herramienta workbench en la que se pueden relacionar tablas grficamente desde el diagrama entidad relacin, siendo una herramienta til que a partir del diagrama entidad relacin nos genera el cdigo fuente exportado mediante un script. El objetivo de la prctica es el conocer herramientas para el diseo de bases de datos y el conocer nuevas tecnologas de desarrollo. El sw puede ser descargado desde http://dev.mysql.com/downloads/workbench/ de manera gratuita. Despus de descargar e instalar el sw, procederemos a la utilizacin del mismo para lo cual creamos un diseo que nombramos Test
81
Lo primero es agregar una tabla y se hace mediante la opcin add table y ser nombrada como producto.
Lo siguiente es agregar columnas a la tabla de las cuales una de ellas ser utilizada como clave primaria y los dems campos se ponen como no nulos, es necesario hacer notar que todo esto se hace de manera grfica como se muestra en la figura siguiente.
82
Como siguiente paso se agrega un diagrama entidad relacin mediante la opcin de add diagram en el cual podremos relacionar tablas y a parecer una grid en la cual disearemos nuestro diagrama. En la parte izquierda aparece la tabla que creamos, solo es necesario arrastrarla a la grid para agregarla al diagrama.
Como siguiente paso haremos una prueba creando otra tabla llamada almacn la cual contendr una clave primaria. Con esta tabla se realizara una relacin de muchos a uno para probar una de las funcionalidades de workbench.
Como se puede apreciar la relacin fue creada as que ahora mostraremos la caracterstica que hace a workbench de mucha utilidad que es la exportacin de datos.
Primero nos aparecer una ventana en donde nos pedir el directorio donde se guardara el script y le indicamos el directorio y el nombre. En nuestro caso se llamara script y se guardara en el disco local D:\
8"
Como siguiente nos mostrara los objetos que sern creados, en este caso solo dos tablas tal y como se puede apreciar en la imagen.
Por ltimo verificamos la creacin del script en el directorio indicado y lo abrimos por medio de Word-Pad para verificar su contenido. Como se puede apreciar es el cdigo fuente que genera las tablas y que hace las relaciones e incluye las claves primarias.
8*
Se puede concluir que esta es una herramienta poderosa que nos facilita el trabajo y es claramente una opcin para desarrollo en base de datos. A pesar de ser un ejemplo simple nos demuestra lo fcil que es crear tablas con claves primarias, incluso con disparadores. Es importante sealar que esta herramienta solo est hecha para Windows y no para otras plataformas.
Practica Volcado
Una herramienta muy til a la hora de crear backups de nuestras bases de datos es mysqldump una herramienta que nos permite volcar nuestra base de datos a un archivo sql muy til en caso de que se pierdan los datos de la base de datos original. Para comenzar abrimos la consola de mysql, en este caso para corroborar que si hace el respaldo, y una ventada del cmd de Windows, Primero visualizamos las bases de datos en nuestro sistema:
Para esta prctica se har un respaldo de la base de datos llamada productos, nos situamos en la consola cmd, y escribimos lo siguiente: mysqldump -u root p productos > d:/Respaldo_SQL/BK_Productos.sql
83
Donde BK_Productos.sql es el nombre del archivo de respaldo que elegimos, lo dems equivale a la ruta donde queremos guardar el respaldo, Una vez hecho esto corroboramos que se ha creado el respaldo que indicamos:
85
Si lo abrimos podemos observar su contenido:
Ahora para comprobar que realmente funciona, borramos la base de datos desde la shell de mysql, para posteriormente restaurarla a travs del archivo backup que creamos.
87
Podemos crear una base de datos llamada productos, pero estar vaca y nos apoyremos del respaldo para restaurarla hasta antes de borrarla:
Regresamos a la consola cmd y escribimos lo siguiente: mysql u root p productos < d:/RespaldoSQL/BK_Productos.sql
88
De regreso en el Shell de mysql nos fijamos nuevamente y vemos que las tablas se han creado a travs del respaldo, en la figura anterior se muestra que hay que indicar la ruta y nombre del respaldo sql para la base de datos correspondiente.
CAPITULO 5 Nuevos Desarrollos en Bases de Datos

5.1 Nuevos modelos de bases de datos
Tratamiento de datos multimedia. Del tiempo, de la seguridad de la incertidumbre. Los sistemas de bases de datos ms conocidos en la actualidad, los relacionales, se caracterizan por gestionar de manera eficiente datos formateados (tipo numrico, carcter, fecha, etc.) con un moderado grado de seguridad (confidencialidad, integridad y disponibilidad). Sin embargo, las aplicaciones que estn surgiendo para atender a nuevos tipos de negocio requieren: Soportar tipos de datos ms sofisticados (voz, vdeo, imagen, texto, etc.), Tratar la dimensin temporal, Garantizar una mayor seguridad, y Manejar datos imprecisos.
Por todo ello, diversas instituciones acadmicas y laboratorios de fabricantes de SGBD estn trabajando con el fin de ampliar las capacidades de los sistemas de bases de datos y adecuarlos as a estas necesidades.
199
A continuacin presentaremos, de manera muy resumida, las caractersticas de los SGBD multimedia, temporales, seguros y difusos. Bases de Datos Multimedia. En la actualidad se est desarrollando toda una serie de aplicaciones que incorporan el tratamiento de datos multimedia (televisin interactiva, sistemas de informacin geogrficos, enciclopedias electrnicas, aplicaciones musicales, etc.). Si las bases de datos no quieren quedarse fuera de este tipo de aplicaciones deben soportar el tratamiento de los datos multimedia de una manera eficiente. Hay que tener en cuenta que este tipo de datos presenta algunas caractersticas especiales: Los datos multimedia son muy grandes y voluminosos, por lo que a pesar del avance del hardware, no parece probable que se mantengan en discos magnticos. Se necesita un nuevo nivel de memoria, conocido como memoria terciaria, por ejemplo juke boxes de discos compactos. Estos nuevos tipos de datos, llevan consigo operaciones que requieren una implementacin muy eficiente. Los datos multimedia presentan restricciones en la velocidad de entrega; por ejemplo, los objetos de un vdeo se deben recuperar a una velocidad constante. Para cada tipo de dato multimedia, debe definirse la calidad de servicio deseada, cmo se degrada, que se hace ante una degradacin, etc. Se necesita un nuevo tipo de interfaces, para visualizar de forma grfica, espacial, y poder realizar consultas a la base de datos basndose en la forma, color u otras caractersticas de los objetos.
Los SGBD actuales no estn concebidos, sin embargo, para manejar grandes cantidades de datos en dispositivos como CD-ROM o videodiscos. En general, podemos afirmar que el modelo relacional no es el ms adecuado para soportar los datos multimedia, aunque en la actua1idad la mayor parte los productos ofrezcan la posibilidad de definir BLOBs (Binary Large Objects) para almacenar texto, vdeo, sonido, etc. Con este mecanismo no es posible expresar la semntica asociada a los objetos multimedia ni realizar accesos por determinados componentes de stos.
191
Aunque no existen propuestas universalmente aceptadas sobre qu componentes o caractersticas debe poseer un SGBD multimedia. Segn esta arquitectura, un SGBD multimedia consta de tres niveles: Nivel de SGBD monomedia, que proporcionan las funcionalidades esenciales para gestionar un medio particular. Nivel de gestin/composicin multimedia, que permite integrar los monomedia para componer documentos multimedia, as como coordinar los diferentes SGBD monomedia en caso de que estuviesen distribuidos. Nivel de interfaz de usuario, que ofrece diversas facilidades para presentacin y visualizacin de imgenes, vdeo, etc. as como varios lenguajes de consulta.
Modelo de referencia para SGBD multimedia:
Bases de Datos Temporales. De manera general, en las bases de datos temporales se suelen distinguir dos aspectos importantes: la gestin de la historia y la gestin de versiones. En estos ltimos aos se ha logrado un consenso en cuanto a la semntica de la historia, pero no a la gestin de versiones, para la que existen muchas propuestas en el contexto de los sistemas de diseo asistido por ordenador e ingeniera de software.
192
En un sentido ms estricto, se conocen como bases de datos temporales aquellas que gestionan la historia, pudiendo contemplar dos dimensiones del tiempo: Tiempo vlido, en el que un hecho es verdadero en el mundo real (con independencia de su registro en la base de datos). Tiempo de transaccin, durante el cual el hecho estuvo presente en la base de datos. Las dos dimensiones son ortogonales, y permiten distinguir de esta manera cuatro tipos de SGBD, segn soporten: Ninguna dimensin: SGBD instantneos (snapshots), como son los productos relacionales ms difundidos en la actualidad, Slo tiempo vlido, Slo tiempo de transaccin, Ambas dimensiones: sistemas bitemporales.
Bases de datos seguras. Aunque existen algunas propuestas para extender el modelo E/R con el fin de poder especificar el nivel de seguridad de las entidades y atributos de una base de datos, la aportacin en estos momentos ms importante, a nuestro juicio, la constituye la metodologa. Esta metodologa, que como su nombre indica esta basada en OMT de Rumbaugh, consta tambin de tres fases: anlisis, diseo del sistema y diseo del objeto. En la fase de anlisis se describe el sistema desde tres puntos de vista: EI modelo de objetos que representa los aspectos estructurales y que pretende controlar ciertos tipos de inferencias no autorizadas. EI modelo dinmico que representa los aspectos de control de las aplicaciones. EI modelo funcional que representa los aspectos transformacionales. Durante la fase de diseo del sistema se disea la base de datos multinivel y, durante la fase de diseo de objetos se determinan los detalles del sistema.
Bases de Datos Difusas. El problema que plantea es la informacin desconocida/incompleta y su representacin por medio de valores nulos en las bases de datos. Dentro de la misma lnea que pretende tratar con datos y consultas imprecisas, tambin se han introducido los denominados Sistemas de Gestin de Bases de Datos Relacionales Difusos (FRDBS), basados en la teora de conjuntos difusos.
19
Un conjunto difuso es un conjunto de elementos en el que cada uno tiene un valor (entre 0 y 1) que indica el grado de pertenencia al conjunto. As, se puede considerar que los valores de los atributos en un dominio o las tuplas en una relacin tienen asociado un grado de pertenencia. Aunque a alguno le suene a ciencia-ficcin, este tipo de bases de datos resultan muy tiles ya que, casi toda la informacin que manejamos acerca del mundo real es incompleta, imprecisa, incierta o vaga. Otra aplicacin de estas teoras, puede ser la integracin de consultas difusas en SGBD tradicionales (precisas), proporcionando una gran flexibilidad y superando el carcter restrictivo de los lenguajes de consultas actuales. Este tipo de sistemas necesita, como es lgico, ampliar los fundamentos tericos de modelos como el relacional, a la vez que hace imprescindible extender los lenguajes, basados en clculo o en lgebra relacional.
5.2 Bases de datos en mltiples servidores
Los Servidores de Bases de Datos, tambin conocidos como RDBMS (acrnimo en ingls de Relational DataBase Management Systems), son programas que permiten organizar datos en una o ms tablas relacionadas. Los servidores de Bases de Datos se utilizan en todo el mundo en una amplia variedad de aplicaciones. Para bases de datos con mltiples usuarios sirve un servidor de base de datos. Las bases de datos estn situadas en un servidor y se puede acceder a ellas desde terminales o equipos con un programa -llamado cliente- que permita el acceso a la base o bases de datos. Los gestores de base de datos de este tipo permiten que varios usuarios hagan operaciones sobre ella al mismo tiempo: un puede hacer una consulta al mismo tiempo que otro, situado en un lugar diferente, est introduciendo datos en la base. La seguridad En todo sistema abierto, debe proporcionarse un potente mecanismo de seguridad que garantice que ningn intruso pueda acceder o corromper la integridad del sistema, en servidores de bases de datos hablaremos de la seguridad a 4 niveles bsicos: a) La seguridad de acceso se implementa de dos maneras posibles: a nivel de sistema operativo, en cuyo caso el SGBD se apoya en la seguridad de entrada al sistema operativo para comprobar la validez del acceso a los datos almacenados; o bien lo que se llama modo mixto, en el cual la seguridad de entrada a la informacin la llevar a cabo el propio servidor de datos a partir de la definicin de cuentas de usuario al servidor (su denominacin de mixta proviene de la capacidad de los sistemas de incluir como cuentas de acceso o login aquellas propias del sistema operativo, lo que facilita la transicin de las cuentas de seguridad). La segunda es de gran ayuda cuando los clientes que acceden al sistema provienen de sistemas operativos con poca (o ninguna) seguridad o de aplicaciones instaladas
19"
que necesiten acceder a los volmenes de informacin del sistema. En ambos casos, en los sistemas se contar con roles o papeles con los que contar el usuario al entrar al sistema para la realizacin de determinadas operaciones de cara al sistema. b) La seguridad a nivel de objetos es el acceso a nivel de creacin y administracin de objetos de datos: tablas, vistas, ndices, relaciones, reglas...etc. Es decir, las responsabilidades y acciones que puede hacer el usuario en el esquema de la base de datos (el esqueleto a partir del cual el sistema definir cmo se debe almacenar y relacionar la informacin). Este podrn especificar de nuevo roles a los usuarios, indicando quin podr crear, modificar o eliminar cualquier objeto de datos (con lo que se permite establecer una poltica de delegacin de responsabilidades). c) La seguridad a nivel de datos accede a la informacin para su consulta, actualizacin, insercin o borrado y las caractersticas de los diversos motores, los que determinarn hasta qu grado de seguridad se llega en este apartado (desde la proteccin de las columnas de una tabla hasta la tabla en s, creacin de vistas...etc.). d) La seguridad a nivel de proteccin de los almacenamientos fsicos de la informacin. es la seguridad a nivel de sistema operativo de los archivos de datos del sistema, y las polticas de copia de seguridad y restauracin de los datos (tanto con herramientas del sistema operativo como las proporcionadas por el propio servidor de datos) junto con sus posibles aproximaciones (total, incremental y diferencial), adems de los soportes hardware compatibles de almacenamiento masivo empleados como destino de las copias. El soporte de red Los servidores de datos deben proporcionar mecanismos de comunicacin ptimos, pues de cmo se enve la informacin dependern parmetros tan importantes como la velocidad de acceso a los datos. Todos los sistemas gestores analizados cuentan con mltiples configuraciones de protocolos, adaptndose a los protocolos existentes y estandarizados de la actualidad: TCP/IP, IPX, Banyan, etc.; es importante no slo el canal de comunicaciones que est disponible para los servidores de datos sino tambin cmo es transmitida la informacin.
19*
5.3 Transacciones distribuidas.
Transacciones locales y distribuidas. Una transaccin local es aquella que utiliza un cliente o el TM para proteger el cambio al estado que administra un solo RM. Con transacciones locales, el resource manager es el transaction manager lo que se ilustra en la siguiente figura:
Una transaccin local se inicia cuando un cliente le solicita al RM (que acta como TM) que arranque una. Todo el trabajo que se ejecuta a travs de la conexin que el cliente tiene, es tratado por el RM como parte de la transaccin y por lo tanto todos los datos que el cliente altera quedan protegidos mientras la transaccin est en progreso. Cuando el cliente termina, solicita al RM (en su funcin de TM) que haga efectiva la transaccin (commit) o que la aborte (rollback). Mientras todo esto sucede, el RM mantiene informacin acerca de la transaccin de tal forma que sea posible recuperarse en caso de que el proceso termine inesperadamente. Una transaccin distribuida, en cambio, permite proteger el trabajo que un cliente realiza para cambiar el estado administrado por varios RMs. Puesto que las transacciones distribuidas no son especficas a un RM en particular, es necesario usar un Transaction Manager externo. Una transaccin distribuida se inicia cuando un cliente le solicita al TM externo que arranque una. El cliente obtiene del TM una transaccin distribuida que presenta a cada RM con el que quiere interactuar. A este procedimiento se le conoce como enlistado (enlistment). Cada RM procesa todo el trabajo que el cliente le enva a travs de una conexin enlistada como parte de la transaccin distribuida. Como sucede con las transacciones locales, cada RM protege los datos que el cliente altera mientras la transaccin est en progreso. Cuando el cliente termina, solicita al TM que haga efectiva la transaccin (commit) o que la aborte (rollback). Terminar una transaccin distribuida es ms complicado que terminar una transaccin local. Puesto que se trata de coordinar las modificaciones al estado de mltiples RMs, un TM utiliza un protocolo de two-phase commit.
193
Componentes. Hardware El hardware utilizado no difiere mucho del hardware utilizado en un servidor normal. Al principio se crea que si los componentes de una base de datos eran especializados seran ms eficientes y rpidos, pero se comprob que el descentralizar todo y adoptar un enfoque "nada compartido" (shared-nothing) resultaba ms barato y eficaz. Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red. Software a) Sistema manejador de base de datos distribuida (DDBMS): Este sistema est formado por las transacciones y los administradores de la base de datos distribuidos. Un DDBMS implica un conjunto de programas que operan en diversas computadoras, estos programas pueden ser subsistemas de un nico DDBMS de un fabricante o podra consistir de una coleccin de programas de diferentes fuentes. b) Administrador de transacciones distribuidas (DTM): Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos. Los DTM se encargan de coordinar y controlar estas acciones. Este DTM puede ser propietario o desarrollado en casa. c) Sistema manejador de base de datos (DBMS): Es un programa que procesa cierta porcin de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM. d) Nodo: Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transaccin ejecuta un DTM y un nodo de base de datos ejecuta un DBM.
195
Tipos de arquitecturas/implementaciones En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideracin que definen la arquitectura del sistema: Distribucin: Los componentes del sistema estn localizados en la misma computadora o no. Heterogeneidad: Un sistema es heterogneo cuando existen en l componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc. Autonoma: Se puede presentar en diferentes niveles, los cuales se describen a continuacin:
1. Autonoma de diseo: Habilidad de un componente del sistema para decidir cuestiones relacionadas a su propio diseo. 2. Autonoma de comunicacin: Habilidad de un componente del sistema para decidir cmo y cundo comunicarse con otros SGBD (Sistema Gestor de Bases de Datos). 3. Autonoma de ejecucin: Habilidad de un componente del sistema para ejecutar operaciones locales como quiera. Objetivos de implementacin. Al implementar una base de datos distribuida se tienen ciertos objetivos comunes: Transparencia de ubicacin. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicacin de stos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localizacin de los datos y de emitir acciones a los calendarizadores apropiados, lo cual puede ejecutarse cuando los administradores de transacciones distribuidas poseen acceso a los directorios de localizaciones de los datos. Transparencia de duplicacin. Para que la transparencia de duplicacin sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transaccin en acciones para el administrador de datos. Para las lecturas el administrador de transacciones selecciona uno de los nodos que almacena los datos y ejecuta la lectura. Para optimizar el proceso, el administrador de transacciones necesita informacin sobre el rendimiento de varios nodos respecto al sitio de consulta, as podr seleccionar el nodo de mejor rendimiento. La actualizacin y escritura de datos duplicados suelen ser ms complicadas, ya que el manejador de transacciones debe emitir una accin de escritura para cada uno de los calendarizadores que almacena una copia de los datos.
197
Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no debern afectarse. La transparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lgica con los resultados que se habran obtenido si las transacciones se hubieran ejecutado una por una, en cualquier orden secuencial. Transparencia de fallas. Significa que a pesar de fallas las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atmicas, significa que se procesen todas o ninguna de ellas. Para este tipo de problemas es importante tener resguardo de la base de datos, y as poder restaurarla cuando sea conveniente. El sistema debe detectar cundo falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por ltimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mnimo de complicaciones. Localidad del procesamiento. Los datos se deben distribuir lo ms cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos. Disear una distribucin que maximice localidad del procesamiento puede hacerse aadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentacin candidata y asignar la fragmentacin eligiendo la mejor solucin. Independencia de configuracin. La independencia de configuracin permite aadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el sistema de base de datos distribuida. Particionado de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicacin de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes. Si un mismo segmento de datos se usa en ms de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad tambin puede verse limitada cuando se produce un fallo en el sistema de clculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estn disponible para los usuarios en cualquier parte del sistema. Fragmentacin de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias (tablas) de relaciones en otras ms pequeas. La fragmentacin se puede realizar por tuplas individuales (fragmentacin horizontal), por atributos individuales fragmentacin vertical) o una combinacin de ambas (fragmentacin hbrida). El principal problema de la fragmentacin radica en encontrar la unidad apropiada de distribucin. Una relacin no es una buena unidad por muchas razones. Normalmente las vistas de una relacin estn formadas por subconjuntos de relaciones.
198
Adems, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribucin. Al descomponer de una relacin en fragmentos, tratados cada uno de ellos como una unidad de distribucin, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocar la ejecucin paralela de una consulta al ser dividida en una serie de subconsultas que operar sobre los fragmentos. Cuando las vistas definidas sobre una relacin son consideradas como unidad de distribucin que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relacin no estar replicada y se almacena en un nico sitio, o existe rplica en todos o algunos de los sitios en los cuales reside la aplicacin. Las consecuencias de esta estrategia son la generacin de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas replicas. Adems, las rplicas innecesarias pueden causar problemas en la ejecucin de las actualizaciones y puede no ser deseable si el espacio de almacenamiento est limitado. Los inconvenientes de la fragmentacin estn dados en que si las pueden estar definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la operacin de unin (Join), lo cual puede ser costoso. El control semntico cuando los atributos implicados en una dependencia una relacin se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer bsquedas en un gran nmero de sitios.
5.4 Interoperabilidad
La Interoperabilidad desde un punto de vista informtico, interoperabilidad se define como la habilidad que tiene un sistema o producto para trabajar con otros sistemas o productos sin un esfuerzo especial por parte del cliente. Este concepto tiene una importancia creciente a tenor de las colecciones digitales distribuidas que utilizan distintos esquemas de metadatos. A pesar de la complejidad de este concepto y de sus mltiples implicaciones para los sistemas de recuperacin de informacin basados en metadatos, es un concepto clave al hablar de esquemas de metadatos y de la necesidad de compatibilizar todos ellos, para una recuperacin de informacin integral en distintas colecciones de datos y metadatos distribuidos. La interoperabilidad entre distintos esquemas de metadatos puede realizarse de diversas formas, por ejemplo a travs del funcionamiento de un protocolo (tipo OAI) o bien a travs del mapeo o establecimiento de correspondencias entre informaciones en diferentes formatos (por ej. MARC-DC, FGDC-DC, etc.) Para la conversin de elementos de meta informacin que permita hacerlos compatibles.
119
5.5 Nuevas tecnologas.
Las organizaciones estn instalando poderosas herramientas de anlisis de datos y almacenes de datos para hacer un mejor uso de la informacin almacenada en sus bases de datos y estn aprovechando la tecnologa de bases de datos vinculada a World Wide Web. Anlisis Multimedia de Datos En ocasiones los gerentes necesitan analizar datos de maneras que los modelos tradicionales de bases de datos no puedan representar. Por ejemplo, una compaa que vende cuatro productos diferentes tuercas, pernos arandelas y tornillos- en las regiones del este, el oeste y el centro, podran necesitar cuales son las ventas reales por producto de cada regin, y tambin comprarlas con las ventas proyectadas. Este anlisis requiere una vista multidimensional de los datos. Para proporcionar este tipo de informacin las organizaciones pueden emplear una base de datos multidimensionales especializados o una herramienta que cree vistas multidimensionales de los datos bases de datos relacionales. El anlisis multidimensional permite a los usuarios ver los mismos datos en diferentes maneras de utilizando en varias dimensiones. Cada aspecto de la informacin producto, precio, costo, regin o lapso de tiempo- representa una dimensin diferente. Por lo tanto un gerente de producto permite podr usar una herramienta de anlisis de datos multimedia mencionada para saber cuntas arandelas se vendieron en el este en junio. Como se compara esto con el mes anterior y el junio el anterior, y como se compara en el pronstico de ventas. Otro trmino para el anlisis multidimensional de datos es procesamiento analtico en lnea (OLAP). Sistema de Gestin de Base de Datos Activo Un SGBD activo es aquel, que bajo ciertas condiciones, y de manera automtica ejecuta acciones anteriormente especificadas, todo ello sin intervencin del usuario. Es decir una especie de BD + super-triggers. Se puede subdividir en dos modelos que lo constituyen: Modelo del conocimiento: especifica las reglas del sistema, en resumen seran tuplas (Evento, Condicin, Accin). Modelo de ejecucin: se encarga de realizar un seguimiento de la situacin y de gestionar el comportamiento. Es decir, el jefe que dice qu hacer y cmo.
111
Sistema de Gestin de Base de Datos Deductivo Es aquel que es capaz de deducir hechos, a partir de un conjunto de axiomas deductivos y reglas de inferencias que ya posee. Una especie de BD + lgica (BD + prolog, o sql + prolog). Un esquema global podra ser que recibida una consulta concreta, el SGBD deductivo segn unas determinadas reglas de inferencia consulta sus datos para obtener una respuesta. Este modelo est muy ligado a las BD Activas, y tienden a converger. Tanto las BD Activas y como las Deductivas podran englobarse en el rea de representacin del conocimiento. Datawarehouse Es un depsito de informacin integrada a partir de varias fuentes guardada segn un esquema unificado en un nico lugar.
112
Reporte de las prcticas Nombre del Tecnolgico Nombre de la Materia
Nombre del Maestro Nombre del Alumno.
Fecha Nmero de Control
Nombre del la prctica 1. Introduccin 2. Objetivo: Describir de manera clara el objetivo del trabajo. 3. Antecedentes: Describir los antecedentes del trabajo y/o los conceptos tericos necesarios para desarrollar su trabajo. 4. Desarrollo Describir de manera formal su trabajo fundamental. Incluir en el reporte de sus prcticas y proyectos la lista de materiales utilizados, diagramas y la descripcin de los pasos de su desarrollo. 5 Pruebas. La pantalla la ejecucin y pruebas, debe ser insertada en el documento con un formato que ocupe el mnimo espacio en disco, que se vea correctamente y que tenga nmero de figura y su nombre. 6 Conclusiones: Describir sus experiencias en la realizacin del trabajo (tarea, prctica y/o proyecto). Describir las dificultades que se le presentaron (falta de conocimientos, equipo, etc.). Describir sus posibles aplicaciones del trabajo. Describir su visin sobre el tema desarrollado. Si el trabajo fue en equipo, describir la participacin de cada integrante del equipo.
7. Bibliografa Esta debe estar ordenada por orden alfabtico, iniciar por el apellido del autor, nombre del libro, fecha edicin, editorial
N(1*: 6l reporte de,e tener un !ndice ( todas las Do?as del reporte de,en
estar -23.r*,*45 de,e utili4ar el %is%o tipo de letra ( el %is%o ta%a@o de la letra para los p&rra+os.
11

Libro Tecnologias Modernas de BD

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Libro Tecnologias Modernas de BD

Caricato da

Copyright:

Formati disponibili

INSTITUTO TECNOLGICO DE CUAUTLA

TECNOLOGAS MODERNAS DE BASE DE DATOS

%. %. CUATLA MOR. A 0& DE MAYO DE #01#

CAPTULO 1 CONCEPTOS DE BASE DE DATOS MULTIUSUARIO 1.1 Base de Datos Multiusuario

1.2 Arquitectura Cliente Servidor

1.3 Caractersticas de los Servidores de Base de Datos

1.4 Interaccin Cliente Servidor en Sistemas De Base De Datos

Figura 1.1 Interaccin Cliente Servidor en Base de Datos

Prctica No 1 Conectividad Cliente-Servidor con MySQL

Figura 4. Creacin de base datos Mysql.

mysql> use escuela;

mysql> show tables;

mysql>select * from alumnos;

CAPTULO 2 CONFIABILIDAD EN LA BASE DE DATOS (INTEGRIDAD Y SEGURIDAD)

2.1.2 Reglas de Integridad Dominio/Relacin Reglas de Integridad - Dominio

Tipos de Datos en SQL

Reglas de Integridad - Relacin

2.1.3 Mecanismos de Vistas para la implementacin de Integridad

Por qu utilizar vistas?

2.2 Seguridad 2.2.1 Identificacin y Autentificacin.

2.2.2 Matriz de Autorizacin.

2.2.3 Definicin de un Esquema de Seguridad

2.2.4 Mecanismos de Vistas para la Implementacin de Seguridad.

2.2.5 Bases de Datos Estadsticas

Smbolo del sistema

Select * from datos_alumnos; Caractersticas del reporte

Figura 2.1 Creacin e Inserta datos tabla alumnos.

Figura 2.2. Creacin y consulta de la vista

Prctica 3: Sentencia Sql para la integridad de la base de datos

drop table NICUStatus;

AND CURRENT_DATE < N2.to_date))) );

Ahora crearemos nuevamente la tabla pero nuevamente la restriccin cambiar:

Figura 2.3. Uso de la base datos integridad

Figura 2.4. Creacin de la tabla NICUStatus

Insercin de datos en la primera tabla

Figura 2.5 Insercin en la tabla NICUStatus Eliminacin de la primera tabla

Figura 2.6. Borrado de la tabla NICUStatus.

Figura 2.7 Creacin de la segunda tabla

Figura 2.8 Insercin de datos en la segunda tabla

Figura 2.9 Consulta general de la tabla

Prctica 4: Gestin de candados con MySQL

Y desde la segunda ventana insertaremos datos en la tabla nueva (Datos2):

Caractersticas del reporte

CAPTULO 3 ADMINISTRACIN DE TRANSACCIONES 3.1 TRANSACCIONES

Propiedades de las transacciones (ACID)

Estados de las transacciones Transaccin comprometida

3.2 Tipos de fallas

Falla del sistema

Fallas en los medios de almacenamiento

Las fallas de los medios de almacenamiento se llaman cadas duras.

Errores del sistema

3.3 Recuperacin (recovery)

Deferred Update (o actualizacin diferida)

Inmediate Update (actualizacin inmediata)

Problema de la actualizacin temporal

Problema de la suma incorrecta

Tcnicas para prevenirlo

Prctica 3: Gestin de candados con MySQL

Y desde la segunda ventana insertaremos datos en la tabla nueva (Datos2):

Caractersticas del reporte

PRCTICA 5: GESTIN DE TRANSACCIONES CON MYSQL

create database ejemplo; use ejemplo;