27 UNIDAD 1Fundamentos Bases de Datos Distribuidas

1.1 Conceptos bsicos. Una Base de Datos Distribuida es, una base de datos construida sobre una red y no por el contrario en una mquina aislada. La informacin que constituye la base de datos est almacenada en diferentes sitios en la red, y las aplicaciones que se ejecutan acceden datos en distintos sitios. Una Base de Datos Distribuida entonces es una coleccin de datos que pertenecen lgicamente a un slo sistema, pero se encuentra fsicamente esparcido en varios sitios de la red. Un sistema de bases de datos distribuidas se compone de un conjunto de sitios, conectados entre s mediante algn tipo de red de comunicaciones, en el cual: 1. cada sitio es un sistema de base de datos en s mismo, pero 2. los sitios han convenido en trabajar juntos (si es necesario) con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario. En consecuencia, la llamada base de datos distribuida es en realidad una especie de objeto virtual, cuyas partes componentes se almacenan fsicamente en varias bases de datos reales distintas ubicadas en diferentes sitios. De hecho, es la unin lgica de esas bases de datos. En otras palabras, cada sitio tiene sus propias bases de datos reales locales, sus propios usuarios locales, sus propios DBMS y programas para la administracin de transacciones (incluyendo programas de bloqueo, bitcoras, recuperacin, etc.), y su propio administrador local de comunicacin de datos (administrador DC). En particular un usuario dado puede realizar operaciones sobre los datos en su propio sitio local exactamente como si ese sitio no participara en absoluto en el sistema distribuido (al menos, ese es uno de los objetivos). As pues, el sistema de bases de datos distribuidas puede considerarse como una especie de sociedad entre los DBMS individuales locales de todos los sitios. Un nuevo componente de software en cada sitio (en el aspecto lgico, una extensin del DBMS local) realiza las funciones de sociedad necesarias; y es la combinacin de este nuevo componente y el DBMS ya existente lo que constituye el llamado sistema de

1

27 administracin de bases de datos distribuidas (DDBMS, distributed database management system ).

BD

BDServidor

........ ...

BDServidor Cliente

Cliente

Cliente

Sitio 1

Sitio 2

Sitio 3

Sitio n

Red de Comunicaciones

Una base de datos distribuida (BDD) es un conjunto de mltiples bases de datos lgicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones, los cuales tienen la capacidad de procesamiento autnomo, lo que indica que puede realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual mltiples sitios de bases de datos estn ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si los datos estuvieran siendo accedidos de forma local. En un sistema distribuido de bases de datos, la informacin se almacena en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:2

27 * Hay mltiples computadores, llamados sitios o nodos. * Estos sitios deben estar comunicados por medio de algn tipo de red de comunicaciones para transmitir datos y rdenes entre los sitios. El procesamiento de bases de datos distribuidas es el procesamiento de bases de datos en el cual la ejecucin de transacciones y la recuperacin y actualizacin de los datos acontece a travs de dos o ms computadoras independientes, por lo general separadas geogrficamente. Un Sistema de Gestin de Bases de Datos (DataBase Management System) Es una agrupacin de programas que sirven para definir, construir y manipular una base de datos. Los SGBD deben: Controlar la concurrencia, o sea, deben permitir a varios usuarios tener acceso "simultneo" a la base de datos. Encargarse de cumplir las reglas de integridad y redundancia. Tener la capacidad de realizar copias de seguridad y de recuperacin de datos. Manejar la restriccin de acceso. Soportar el almacenamiento de cantidades voluminosas de datos. Ofrecer a los usuarios la capacidad de consultar los datos y modificarlos, usando para ello un lenguaje apropiado. Manejo de Transacciones. Varios procesos que se han de aplicar uno despus del otro y que se ejecutan como una sola operacin. Ejemplos.- MySQL, Oracle, SQL server, Sybase Un Sistema de Gestin de Bases de Datos Distribuidas. Es el sistema de software que gestiona las bases de datos distribuidas. Es un sistema de varios SGBD ejecutndose en sitios locales cuyas funciones son: Capacidad de acceder a sitios remotos. Capacidad de recuperar la distribucin y la replicacin de los datos. Capacidad de elaborar estrategias de ejecucin para consultas y transacciones. Mantener la consistencia de las copias de un elemento de informacin replicado. Decidir a cul copia de un elemento replicado se tendr acceso. La capacidad de recuperarse de cadas de sitios individuales. Aplicaciones generales: Organismos distribuidos geogrficamente Servicios bancarios y financieros Industria Manufactura (Automotriz) Hospitales Reservacin de vuelos Cadena de hoteles Cualquier organismo descentralizado

3

27

Historia La necesidad de almacenar datos de forma masiva dio paso a la creacin de los sistemas de bases de datos. En 1970 Edgar Frank Codd escribi un artculo con nombre: "A Relational Model of Data for Large Shared Data Banks" ("Un modelo relacional para grandes bancos de datos compartidos"). Con este artculo y otras publicaciones, defini el modelo de bases de datos relacionales y reglas para poder evaluar un administrador de bases de datos relacionales. Inicio de las bases de datos distribuidas Originalmente se almacenaba la informacin de manera centralizada, pero con el paso del tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes que no era posible solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas impulsaron la creacin de almacenamiento distribuido, los cuales hoy en da proveen caractersticas indispensables en el manejo de informacin; es decir, la combinacin de las redes de comunicacin y las bases de datos. Evolucin Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalizacin y a la vez las operaciones de las empresas son cada vez ms descentralizadas geogrficamente. Tambin el poder de las computadoras personales aument y el costo de los Mainframes ya no tena sentido. Adems la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas. Hardware involucrado 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 esto no se comprob, por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red. Software Sistema de Administracin 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. 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. Administrador de la base de datos (DBM).- 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.4

27 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. VENTAJAS Y DESVENTAJAS DE LAS BDD Es importante sealar que ocurren en funcin a las caractersticas del entorno distribuido que se requiere para la operacin de una BDD, es decir, los aspectos benficos o perjudiciales de una BDD dependen en cierta medida del hecho que el ambiente de una red distribuida est funcionando correctamente o no, por ejemplo, de nada sirve que una BDD est perfectamente diseada, igual que las rplicas, fragmentos e incluso, que el sistema que las manipule est muy bien validado y dems, si la red en la que opera no es confiable y tiene deficiencias, pues el sistema no funcionar correctamente. CLASIFICACIN Homogneas. Todos los sitios tienen idntico software de sistemas gestores de BD, son conscientes de la existencia de los dems sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios Heterogneas. En estos sistemas puede ser que utilicen esquemas diferentes y diferente software de gestin de bases de datos. Puede ser que unos sitios no sepan de la existencia de los dems. VENTAJAS DE UNA BDD

Compartimiento de datos. Los usuarios son capaces de acceder a datos de otro nodo. Disponibilidad. Si falla un nodo, los nodos restantes pueden seguir funcionando. Mejor rendimiento. La operacin en forma simultnea de varias computadoras mejora el procesamiento de datos. Los datos generalmente se ubican cerca del sitio con mayor demanda, tambin los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores. Autonoma local. Un departamento puede controlar los datos que le pertenecen. Refleja una estructura organizacional. Los fragmentos de la base de datos se ubican en los departamentos con los que tienen relacin. Economa. Es ms barato crear una red de muchas computadoras pequeas, que tener una sola computadora muy poderosa. Modularidad. Se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los dems sistemas (mdulos).

DESVENTAJAS DE UNA BDD Costo de desarrollo de software. La implementacin de un sistema distribuido es mucho ms difcil y por lo tanto ms costoso. La complejidad y la infraestructura necesaria implica que se necesitar una mayor mano de obra. Mayor sobrecarga de procesamiento. La sobrecarga surge con el intercambio de mensajes y el cmputo adicional para conseguir la coordinacin entre los sitios. Fallo de sitios individuales. El SGBDD debe de continuar operando con los dems sitios activos. Cuando el sitio se recupere, su base de datos local debe de ponerse al da con los dems antes de reincorporarse.5

27 Complejidad. Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades nicas. El diseo de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas. Seguridad. Se debe trabajar en la seguridad de la infraestructura as como cada uno de los sistemas. La probabilidad de violaciones a la seguridad es creciente por la existencia de varios nodos de red. Integridad. Se vuelve difcil mantener la integridad, aplicar las reglas de integridad a travs de la red puede ser muy caro en trminos de transmisin de datos. Falta de experiencia. Las bases de datos distribuidas son un campo relativamente nuevo y poco comn por lo cual no existe mucho personal con experiencia o conocimientos adecuados. Carencia de estndares. Aun no existen herramientas o metodologas que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido. El diseo de la base de datos se vuelve ms complejo. Adems de las dificultades que generalmente se encuentran al disear una base de datos, el diseo de una base de datos distribuida debe considerar la fragmentacin, replicacin y ubicacin de los fragmentos en sitios especficos. VENTAJAS PARA EL USUARIO FINAL Mayor rapidez en sus accesos a la informacin. Menos peticiones abortadas por el congestionamiento en la red. Las operaciones respecto a actualizaciones automticas, ubicacin fsica de los datos, nombre de archivos de datos y campos y dems, se realizan de manera totalmente transparente para l. El usuario final se ve beneficiado porque no requiere de grandes capacidades de almacenamiento primario ni secundario para operar un sistema con BDD, porque no necesariamente debe contener todos los mdulos del sistema ni todas las tablas de todas las BD en su localidad. Independientemente del estado de la red, una BDD debe estar conectada a las diversas localidades que contienen los datos que solicita y ante el fallo de algn sector de red, sus peticiones se redireccionan hacia otro(s) nodo(s) que s est(n) disponible(s), esa ventaja se puede traducir en que el uso de su sistema no es dependiente de un slo nodo que contiene los datos, lo que significa que, an con nodos fuera de la red el usuario puede recibir la salida de sus consultas. Otra ventaja radica en cuanto a las actualizaciones automticas, tanto para lo que accede y que haya sido actualizado por otros usuarios anteriormente o bien, lo que l modifica y que se refleja inmediatamente para las copias que emplean otros usuarios, esta ventaja en s, no es otra cosa ms que confiabilidad por la consistencia de los datos. VENTAJAS PARA EL ADMINISTRADOR La modularidad (Y no nada ms respecto al SW, sino a la BDD y la propia red). Todo problema, por complejo y variado que sea, si se divide en partes (Mdulos), ser simple de atacar, porque te enfocas al sector donde se haya originado y/o los que se hayan visto afectados, pero no necesariamente debes intervenir en el 100% de las partes; por ejemplo,6

27 con una BDD, si por alguna razn hay un error en una actualizacin de ciertas tablas, el administrador no tiene por qu detener el uso de todo el sistema, puede bloquear el acceso temporalmente a esas tablas en lo que localiza dnde ocurri el problema, lo puede corregir y sigue en operacin el sistema. Su trabajo luce mucho ms y es capaz de satisfacer necesidades ms complejas que las que podra con un sistema 100% centralizado, es decir, eso redunda en mayor prestigio como profesional, porque evidentemente vale ms el trabajo de quien administra algo distribuido que algo local. Una ventaja consecuente es que puede cobrar ms. VENTAJAS PARA EL SW DE RED Menor tiempo consumido para arrojar los datos solicitados, debido a que maneja una menor cantidad de datos en sus operaciones al utilizar nicamente los fragmentos involucrados. Un SW programado de esta manera vale mucho ms en el mercado que otro que sea centralizado. Idealmente, ofrece la posibilidad de acceder a datos que estn almacenados en SMBD distintos. Una ms radicara en que adems ofrezca independencia del tipo de SO que se est empleando en los nodos de la red. Estas dos ltimas ventajas haran de este SW multiplataforma (Tanto desde la perspectiva del SO, como del SMBD). Para que ello sea posible depende en gran medida del tipo de SMBD y Lenguaje de Programacin que se haya elegido para disear el sistema, que sea compatible con una gran variedad de plataformas. DESVENTAJAS PARA EL USUARIO FINAL La posible inconsistencia temporal de los datos, porque en un caso extremo podra acceder a datos de una rplica que no haya sido actualizada en determinado momento, esto puede ocurrir si la red es muy grande y aunque la actualizacin es automtica, NO es inmediata, se requiere cierto tiempo (Aunque idealmente pequeo) para actualizar todas las rplicas y podra coincidir que cuando accede a una rplica en particular, sta an est en vas de ser actualizada. A mayor cantidad de rplicas, mayor posibilidad de esa inconsistencia temporal de datos. Hay una dependencia muy alta respecto a las condiciones operativas de la red, es decir, si la red no funciona, sus operaciones de consulta de ciertos datos (Los que no contenga localmente) difcilmente podrn realizarse (O sera imposible en ciertos casos). Su mayor dependencia es respecto a la eficiencia del trabajo del administrador/diseador de la BDD y su sistema que la manipula. DESVENTAJAS PARA EL ADMINISTRADOR DE RED Necesita un mayor grado de especializacin para poder manejar un entorno distribuido en una red. Una MAYOR cantidad de trabajo y complejidad para realizar sus funciones. Es MUCHO ms difcil su trabajo de planeacin, diseo e implementacin de una BDD con su respectivo SW que la manipular, porque ah es donde ms tiene que pensar, pero si hace7

27 bien todo eso, la ventaja es que su administracin (Una vez que la haya puesto en marcha y la haya probado) ser ms simple. TODO depende de la eficiencia de su trabajo en lo relativo al diseo de la BDD y el SW, porque si esto est mal hecho, de nada sirven usuarios muy capacitados, una red excelentemente configurada, equipos muy potentes, medios de conexin fabulosos, en pocas palabras, la mayor responsabilidad recae sobre l y an cuando no siempre los problemas operativos son su culpa, de todos modos, todo fallo se le reclama a l. No siempre (De hecho, la mayor parte de las veces) el DDBA es quien administra por completo la red, por lo que depende del administrador de sta y si quien controla la red es malo, aunque el diseador de la BDD sea excelente, las cosas no saldrn bien. DESVENTAJAS PARA EL SW DE RED Dependencia de las condiciones de la red para la satisfaccin de las peticiones de usuario en cuanto al acceso a datos. Mientras mayor sea su alcance, mayor robustez requiere en su estructura interna y puede ser que haya nodos que no tengan los recursos suficientes para ejecutarlo. Por un lado, es bueno que sea robusto porque incluye todas las validaciones y opciones requeridas, pero tambin se puede hacer demasiado grande para que lo soporten algunos nodos con pocas capacidades de procesamiento y de almacenamiento, sobre todo lgico. Por muy bueno que sea el SW programado, si la BDD no est bien diseada, no ser eficiente su uso. TRANSACCIONES QUE SE PUEDEN REALIZAR CON BDD Una operacin de lectura es aquella que implica el acceso a una BDD o varias de ellas (A una o mltiples tablas de cada una), que implica la localizacin de ciertos datos para arrojarlos como salidas en pantalla o reportes, sin que esto altere el contenido fsico de los datos. Una operacin de escritura es aquella implica el acceso a datos de una o varias BDD (A una o ms tablas de cada una), para la cual se localiza algn dato especfico de inters para el usuario, cuyo contenido del registro deseado ser modificado total o parcialmente al trmino de la operacin. OPERACIONES DE LECTURA Consultas. Realizacin de reportes. Ordenamiento lgico de datos para la realizacin de consultas en el mayor de los casos, aunque a veces se realiza para crear una rplica. OPERACIONES DE ESCRITURA Ordenamiento fsico de los datos al realizar fragmentos y en el uso de archivos secuenciales. Altas. Bajas. Modificaciones de registros.8

27 CUNDO CONVIENE REALIZAR LAS OPERACIONES DE MANERA LOCAL Y CUNDO DE MANERA REMOTA? DE MANERA REMOTA Cuando no se cuenta con los datos localmente. Cuando a pesar de contar con los datos localmente, un nodo remoto es MUCHO ms rpido que el local. Cuando la operacin es de escritura y refiere a una BDD con rplicas, por la actualizacin automtica que se requiere. La creacin de un nuevo fragmento y/o una nueva rplica, siempre que la ubicacin fsica de los nuevos archivos de datos no sea la misma que la BD original. DE MANERA LOCAL Cuando se cuenta con la informacin en el nodo en el que se est trabajando. Cuando no hay acceso a la red. Puede ser 100% local, cuando, a pesar de contar con rplicas, la operacin es de lectura. La creacin de un nuevo fragmento y/o una nueva rplica, siempre que la ubicacin fsica de los nuevos archivos de datos sea la misma que la BD original. Se cuenta con el dato y basndose en la velocidad de procesamiento de un nodo remoto se puede pensar que sera mejor hacerlo en dicho nodo, sin embargo, el trfico de la red es alto, lo que retrasara la operacin. ENTORNOS DE RED REQUERIDOS PARA LA DISTRIBUCIN DE DATOS Para que un ambiente distribuido en cuanto a la BD opere eficientemente, se debe apoyar en estructuras de red, entre ellas, el anillo, la estrella, una red totalmente conectada, una parcialmente conectada y una jerrquica. Cada uno de esos entornos ofrece ciertas condiciones benficas para la distribucin de datos y ciertas limitantes. RED TOTALMENTE CONECTADA Conviene cuando todos los usuarios mantienen comunicacin constante con todos los otros usuarios de la red. Cuando existen transferencias de datos entre cada usuario de carcter confidencial constantemente, pues les ofrece lneas privadas entre s. Conviene slo cuando la cantidad de nodos es menor o igual a 16, porque de lo contrario, esa red se convertira en una telaraa. El funcionamiento de la red ya con muchos nodos, todos conectados con todos, termina afectando la eficiencia del sistema que manipula la BDD. En redes pequeas puedes colocarle a cada usuario prcticamente una rplica exacta de lo que necesita y la red en s la emplea para transferir datos y actualizar. RED PARCIALMENTE CONECTADA Cuando el nmero de nodos es mayor a 16. Cuando los usuarios tienen necesidades de transferencia constantes con slo algunos de los dems de la red, pero no con todos, de modo que no tiene caso usar enlaces directos entre todos.9

27 Es conveniente porque el administrador de red y de la BDD pueden llegar a un comn acuerdo de cul es la estructura de conexin de la red que ms conviene para ambos. RED JERRQUICA Cuando hay claramente identificados grupos de usuarios que mantienen mucha comunicacin entre s, pero no con otros grupos, de modo que a travs del rbol y sus niveles puedes ir clasificando a los usuarios segn la frecuencia con la que se comunican con sus vecinos. Permite dar privacidad a los fragmentos de BD que as lo requieren, ubicndolos en los nodos hoja. No se satura el acceso a las BD, dado que cada sector del rbol contendr nicamente los datos de los usuarios que pertenecen a l. RED DE ANILLO Conviene cuando el tiempo de respuesta no es prioridad. Si los datos no son altamente confidenciales, porque de alguna manera se convierten en pblicos para todos los nodos de la red. Es verdaderamente conveniente slo si cuenta con algn mecanismo que incremente la tolerancia a fallos de la topologa, como los anillos bidireccionales, porque de lo contrario la estabilidad del SW que manipula la BDD sera muy baja. RED DE ESTRELLA Cuando se quiere tener un mayor control sobre la informacin que manejan los usuarios entre s, porque aunque todos los usuarios se pueden comunicar con todos, como eso ocurre slo a travs del servidor, se controla totalmente ese aspecto de seguridad/confidencialidad/pertinencia de la informacin. La informacin compartida respecto a la BD slo la conocen en determinado momento el nodo origen y destino, esto porque no pasa por nodos intermedios de usuarios, pasa nicamente por el servidor, entonces ningn otro usuario se entera de las dems transferencias. POR QU NO VEMOS AQU EN ESTOS ENTORNOS DE RED AL BUS? Porque de cierta forma se incluye en todos los entornos cuando se establece una ruta para comunicar a dos nodos, la ruta que se forma para cada operacin remota es por s misma un bus. CUL DE LOS ENTORNOS ES EL MEJOR Y CUL EL PEOR PARA LA DISTRIBUCIN DE DATOS? Para optar por uno de esos esquemas de red depende mucho de las circunstancias especficas de la empresa que lo requiera, pero de manera natural y desde un enfoque ms general el esquema que ms favorece a la distribucin de datos es la parcialmente conectada (Porque no tiene lmite en el nmero de nodos y porque se puede adecuar a cada necesidad especfica de conexin); de igual forma, de manera natural hay dos posibles peores entornos de red para la distribucin de datos, uno de ellos es el de estrella, dado que un esquema centralizado es justamente lo opuesto a lo que se busca con la distribucin, resulta hasta contradictorio, slo lo justifica lo del control preciso de las transferencias entre10

27 usuarios, el otro es el anillo, porque para que verdaderamente sea propicio para la distribucin necesita ser un Anillo Modificado, convertido de cierta forma en estrella a travs del cable bidireccional. ARQUITECTURA DE UNA BDD ESQUEMA GLOBAL Corresponde a la vista ms externa de un sistema distribuido, con la que interactan todo tipo de usuarios, pero enfocada particularmente a contribuir a que los usuarios administradores conozcan el comportamiento del sistema una vez que fue implementado, sobre todo por la posibilidad que ellos no sean quienes lo disearon. VISIN GLOBAL Se puede decir que es la interfaz con la que interacta el usuario final para manipular la BDD, es el conjunto de aplicaciones programadas (SW) que le permiten al usuario realizar sus consultas, emitir reportes, bajas, altas, entre otras operaciones. De cierto modo, esta Visin Global da alguna idea sobre cmo est estructurada la BDD (aunque no necesariamente los usuarios finales la entiendan), esa idea general que da sobre la BDD en realidad es porque muestra la informacin de la BD clasificada por mdulos, digamos, mdulo de alumnos, mdulo de materias, de maestros, de aulas, por mencionar algunos; para algn tipo de sistema escolar, lo cual puede permitir que se sepa cules son las entidades fundamentales que integran al sistema (Alumnos, materias, maestros y dems) por ejemplo. Pareciera que es un nivel 100% pensado o diseado para el usuario final (generalmente, ignorante en el mbito de las BD y sobre todo la distribucin de datos), pero en realidad no es ese el enfoque, sino que ese nivel es de gran utilidad para un nuevo usuario experto que debe familiarizarse con un sistema que l no dise y que desconoce por completo, sin embargo, a partir de cierto momento deber encargarse de l. En s el objetivo de esta Visin Global, es dar un panorama general de cmo est estructurado el sistema, pero para quien conoce del rea, obviamente, es la misma interfaz con la que trabaja el usuario convencional. El punto PRINCIPAL de esto es que idealmente la estructura por mdulos del SW y su ejecucin (Interfaz) debe ser lo suficientemente clara y acorde al diseo de la BDD para que cuando lo emplee un nuevo usuario experto, tenga una idea ms cercana de lo que compone ese sistema (En el mbito de tablas, campos, registros, relaciones, entre otros elementos), eso suena simple pero no siempre es fcil de reflejar. Ms que dar una idea de cmo funciona el sistema (aunque obviamente tambin para ello sirve), es para que cuando tenga que ver la estructura de la BDD tenga una mejor idea de por qu est estructurada as o bien, desde que lo empiece a usar, se vaya creando ideas de cmo piensa que debiera estar estructurado y cambiar lo que crea pertinente. Ya en trminos de la vida prctica, la ideologa de quienes estn en esa situacin de llegar a administrar un sistema que ellos no crearon, generalmente se basa en definir que, si la BD no ha dado problemas, todos estn satisfechos con las salidas que genera el sistema, todos los datos se encuentran cuando se buscan, no ha habido inconsistencias o no hay algn otro problema, pues ellos no llegan y hacen cambios, an si el diseo no es tal como ellos hubiesen preferido hacerlo.11

27 ESQUEMA DE FRAGMENTACIN Tambin nombrado Esquema de Fragmentacin y Replicacin o Esquema de Fragmentacin y Repeticin, ste consiste en que, a travs de la definicin de cules son las operaciones ms comunes con la BD, se identifiquen los datos que reciben esas operaciones y quines son los usuarios que las realizan, y as se puede conocer en trminos generales cuntas rplicas puede haber de la BD, qu fragmentos se han hecho y de qu tipo, es decir, un buen sistema distribuido, adems de las opciones convencionales, incluye ciertos mdulos o apartados, a los que no tienen acceso los usuarios comunes, que llevan una especie de bitcora de las operaciones que se realizan con la BDD, especificando dnde se llevan a cabo, de parte de qu usuario, en qu consisti la operacin, la fecha y hora en que ocurri, entre otra informacin de inters. Esto es til porque as el usuario con permiso para acceder a dichos mdulos podr ver si hacen falta nuevas rplicas o fragmentos, si algunas de las que existen han dejado de utilizarse, si hay nuevas necesidades por satisfacer, qu usuarios son los de mayor demanda y dems. Pareciera que es para informacin muy interna del sistema, sin embargo, pertenece al Esquema Global porque es a travs de la interfaz; ciertamente esos mdulos le interesan mayormente al DDBA, pero tambin los puede consultar cualquier usuario y sin mucha dificultad podra comprender de qu manera se aprovecha el sistema que l emplea, tanto de su parte como por parte de los dems usuarios de la red. ESQUEMA DE LOCALIZACIN ste tiene varias similitudes con el anterior, dado que tambin, a travs de ciertos mdulos del sistema distribuido se pueden reconocer algunos datos de identidad de los usuarios y su ubicacin dentro de la red y/o subredes en las que est dividida, es decir, activando ciertas opciones se pueden conocer las IP de los nodos que participan en las operaciones de acceso a la BDD y sobre todo, da una idea ms o menos clara de cules son las partes de la red que trabajan ms activamente con la BDD. En contraste, estos mdulos, a diferencia de los del Esquema de Fragmentacin y Repeticin, realmente interesan al nuevo administrador o al personal a su cargo, porque a los usuarios finales, difcilmente les despierta inters esta informacin, al contrario, para ellos lo interesante es que no se tienen que complicar la vida pensando la ubicacin de los usuarios ni de los datos, mientras que para el administrador, s es interesante que este Esquema de Localizacin le especifique los datos en particular que se usan y las localidades donde se encuentran. No todos los sistemas distribuidos ofrecen tanta informacin en su ejecucin, de hecho, la mayora slo muestra una especie de tablas con datos muy tcnicos o grficos del comportamiento/uso de la BDD, porque mientras ms informacin dejen visible, mayor riesgo hay que se introduzcan usuarios mal intencionados y causen perjuicios a la BDD, adems, estos mdulos son los que tienen la necesidad de incluir mayores niveles de seguridad en cuanto a su acceso, mediante autenticacin de usuarios y usualmente se verifica que estos mdulos sean accedidos nicamente desde ciertos nodos especficos (Por ejemplo del servidor), para evitar que otros usuarios, violando contraseas, entren a ellos. ESQUEMA LOCAL Este esquema es en s una especificacin ms tcnica y detallada de la forma en que opera el sistema y la BDD, el cual interesa particularmente al administrador12

27 del sistema o su equipo de trabajo, difcilmente a otro tipo de usuario, porque aparte, raramente lo entendera. VISIN LOCAL Se refiere a la documentacin (Impresa o electrnica), externa a la del SW del que hablamos en todo el esquema anterior, que genera el diseador de la BDD para que el administrador pueda desempear su trabajo, sobre todo considerando que en las grandes empresas, quienes administran los sistemas usualmente no son quienes los desarrollan, slo que esta informacin es ms de carcter confidencial, por eso es que no se incluye en el Esquema Global, por ejemplo, parte de esa documentacin debe incluir cmo fueron nombradas las BD (con la indicacin de su nomenclatura correspondiente), el listado de nodos de la red con sus IP correspondientes, con la lista de usuarios asociados a cada nodo, indicando dnde se ubica cada rplica y cada fragmento, los criterios que se emplearon para seleccionar y/o proyectar, entre otras cosas. El conjunto de datos antes mencionado s debe ocultarse al usuario comn, slo la conocer el diseador (porque l la genera), el administrador (porque para l se disea) y en dado caso los programadores que intervengan en las actualizaciones del sistema y/o de la BDD. Esta Visin Local debe contar con mecanismos de seguridad fsica, como llaves, candados, incluso el cifrado de los documentos electrnicos. NIVEL DEL SMBD Consiste en todo el conjunto de datos tcnicos y operativos que se deben conocer y especificar respecto al uso del SMBD empleado para la creacin de la BDD, as como las limitantes y bondades del Lenguaje de Programacin empleado para programar el sistema, es decir, tener claros aspectos como, cuntos registros por tabla soporta como mximo el SMBD, con qu otros SMBD es compatible, en qu versiones, bajo qu sistemas operativos, qu lenguajes de manipulacin de consultas reconocen el formato del SMBD, qu tipos de datos puede manejar el SMBD, en caso que sea ms de un SMBD el que se emplee en los diversos nodos, como no siempre manejan exactamente los mismos tipos de campos, cul es la relacin de correspondencia entre los tipos de cada uno. Este esquema tambin refiere a los requerimientos mnimos de almacenamiento en HD, de procesamiento, de memoria lgica y dems que en ocasiones, por increble que parezca, no se toman en cuenta y cuando empieza a fallar el sistema en ciertos sectores de la red es porque no se tuvo en cuenta que de verdad todos los nodos cuenten con esos requerimientos mnimos, es muy comn que ocurra cuando se van agregando nuevos nodos a la red y se hacen rplicas de BD o del sistema y resulta que tienen un SO que causa problemas con el SMBD, que no cubre los requisitos mnimos o cosas as. Eso, en un sistema grande es comn, porque por poner cuidado en muchas ms cosas, se descuidan esas que son bsicas. NIVEL DE BD Se refiere a las caractersticas tcnicas especficas de la BDD global y cada una de las rplicas y fragmentos, es decir, la especificacin de qu campos componen a cada una, de qu tipo son, qu reglas de validacin llevan implcitas, su extensin/longitud, cantidad aproximada (o exacta, si se puede saber con facilidad) de registros, relaciones entre tablas, esto fundamentalmente se ilustra a travs de la construccin de Diagramas de Relaciones, Diagramas de Entidad Relacin, diccionarios de datos, DFDs, incluso13

27 Diagramas de procesos o Diagramas de Flujo referentes a los cdigos de los mdulos del sistema, notacin UML, etc. En trminos generales, consiste en hacer una especie de reporte donde contenga las especificaciones de la BD a travs de las herramientas antes mencionadas. Este nivel, obviamente es el ms interno de la arquitectura de una BDD porque ya verdaderamente debes estar 100% involucrado en la estructura de la misma para intervenir en l, en particular, toda esa documentacin que se cita, es especialmente til para ver cualquier cambio posible en la BDD, desde un campo dems, cambiar de tipo, quitar alguno, crear una nueva relacin o alguna otra operacin. Todo se debe cotejar a travs de todos esos diagramas que se mencionan, para evitar que un cambio afecte al resto de la BDD y del propio sistema, porque a veces, tan simple como cambiar un nombre o tipo de campo puede hacer que cause un error en un mdulo del sistema durante su ejecucin. Este nivel incluye los diccionarios de datos, tanto los que corresponden a la BDD como a los de las variables empleadas en el cdigo del sistema que la manipula. stos dos ltimos niveles son los que requieren el mayor nivel de especializacin para poder trabajar con ellos y ambos son los que tienen las mayores implicaciones tcnicas respecto a la operacin del sistema y su BD, lo que a su vez tambin implica mayor nivel de confidencialidad requerida, para evitar el plagio del sistema y posibles ataques. 1.2 Objetivos de las B.D.D. Autonoma local. Todas las operaciones en un sitio dado se controlan en ese sitio. No dependencia de un sitio central. No debe haber dependencia de un sitio central "maestro" para obtener un servicio central, de lo contrario el sistema sera ms vulnerable. Operacin continua. Nunca debe haber necesidad de apagar a propsito el sistema. Independencia con respecto a la localizacin. No es necesario que los usuarios sepan dnde estn almacenados fsicamente los datos. Independencia con respecto a la fragmentacin. Los datos pueden almacenarse en la localidad donde se utilizan con mayor frecuencia. Independencia de rplica. Si hay rplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario. Procesamiento distribuido de consultas. El SGBDD debe de ser capaz de procesar y optimizar las consultas distribuidas. Manejo distribuido de transacciones. El manejo de transacciones debe manejar el control de recuperacin y el control de concurrencia. Independencia con respecto al equipo. La variedad de marcas y plataformas no deben de afectar el funcionamiento. Independencia con respecto al sistema operativo. Independencia con respecto a la red. Independencia con respecto al SGBD. Objetivos de Implementacin Al implementar una base de datos distribuida se tienen ciertos objetivos comunes:14

27 * 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. (El calendarizador est encargado de ordenar un conjunto de transacciones u operaciones que se deseen realizar sobre una base de datos. Cualquier orden en el que se decida hacer este conjunto de operaciones se denomina calendarizacin). * 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. * 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 que pudieran ocurrir 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 la 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. Permite aadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el sistema de base de datos distribuida. * Fragmentacin de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir las instancias (tablas) de relaciones en otras ms pequeas. La fragmentacin se puede realizar por registros 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 completa no es una buena unidad por muchas razones. Normalmente las vistas de una relacin estn formadas por subconjuntos de relaciones.15

27 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 rplicas. 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 tablas 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 relacin se descomponen en diferentes fragmentos y stos se ubican en sitios diferentes puede ser muy costoso porque es necesario hacer bsquedas en un gran nmero de sitios. OBJETIVOS DE UNA BDD En realidad, los objetivos de una BDD no tienen absolutamente nada que ver con los usuarios finales, stos son los que perciben la mayor parte de las ventajas, sin embargo, la creacin de BDD no surgi pensando en los usuarios comunes, sino en los diseadores de BD, de sistemas computacionales y programadores, porque conforme fueron incrementndose las necesidades de los usuarios en cuanto a una mayor cantidad de datos, mayor variedad de ellos, mayores accesos simultneos, entre otras cosas, los diseadores de BD y de aplicaciones que las manipularan empezaron a tener problemas con el hecho de seguir conservando una BD nica (centralizada) y que de todos modos pudiese soportar eficientemente las nuevas y cada vez mayores exigencias de los usuarios, entonces se empez a idear el hecho de dividir esa BD centralizada, para que su trabajo empezara a ser ms simple y como consecuencia, pudiesen satisfacer de mejor manera las demandas de los usuarios de BD en redes. Por eso se dice que los objetivos de una BDD en realidad estn enfocados a sus creadores/diseadores, ante esto, podemos decir que tales objetivos son: Facilitar a las aplicaciones de SW el manejo de grandes cantidades de datos, de manera que no dependieran de las capacidades de cmputo de un solo equipo. Permitir que los SMBD trabajaran ms eficientemente al reducir la cantidad de tablas y registros implcitos en cada operacin de acceso a la BD, dado que se accedera a fragmentos de la BD total. Reducir el trabajo de bsqueda de datos de parte de los SMBD al permitir que se acceda a pequeas BD diseadas especficamente para las necesidades de un usuario o conjunto de ellos. Permitir que el administrador del sistema pueda ofrecer un menor tiempo de respuesta/acceso a los datos, dado que ese es uno de los aspectos que en mayor medida les criticaban.16

27 Lograr que los sistemas computacionales diseados para correr en red provocaran una menor congestin de los medios de conexin puesto que las consultas no necesariamente se direccionaran hacia una misma localidad. Los objetivos en realidad fueron para facilitar el trabajo de quienes empezaron a trabajar con este nuevo concepto de distribucin de datos. Cada uno de esos objetivos se fue traduciendo en beneficios para s mismos y para los usuarios finales, dado que si su trabajo mejor y fue ms eficiente, los usuarios vieron mejorados sus accesos y peticiones, por eso no es realmente correcto decir que algn objetivo de una BDD tiene que ver con mejoras para los usuarios, porque stas ms bien se dan como consecuencia. 1.3 Disciplinas de estudio. lgebra Relacional El lgebra relacional es un conjunto de operaciones que describen paso a paso cmo computar una respuesta sobre las relaciones, tal y como stas son definidas en el modelo relacional. Denominada de tipo procedimental. Describe el aspecto de la manipulacin de datos. Estas operaciones se usan como una representacin intermedia de una consulta a una base de datos y, debido a sus propiedades algebraicas, sirven para obtener una versin ms optimizada y eficiente de dicha consulta. El lgebra relacional es una notacin de nivel intermedio a los lenguajes de alto nivel y el lenguaje mquina, que permite la estructuracin de consultas bsicas sobre BD, que sirve para que los diseadores incipientes de sistemas computacionales, con mayor facilidad manipulen lenguajes de consultas tales como SQL. Existen ciertas operaciones fundamentales, como Seleccin, Proyeccin, Unin, Producto Natural y Producto Cartesiano, que a continuacin se describen. SELECCIN Es la operacin que consiste en extraer ciertos registros de una tabla, con base en el cumplimiento de una condicin establecida en relacin al contenido de alguno o algunos de los campos de la misma. Su sintaxis es: Campo=Valor (nombre tabla) PROYECCIN Esta operacin consiste en extraer todos los registros de una tabla, pero discriminando algunos de los atributos, mejor conocidos como campos o columnas de la misma. Su sintaxis es: Campo 1, Campo 2, , Campo N (Nombre de la tabla) UNIN Considrese la relacin Incentivos, y la relacin Antigedad: Incentivos Antigedad Empleado Incent Empleado Antig Juan Prez 500 Domingo Lpez 950 Laura Flores 250 Elisa Fuentes 150 Laura Flores 1,200 Se desea generar una lista que muestre los empleados que perciben ingresos por incentivos, antigedad o ambos. Se puede observar que ambas relaciones no satisfacen completamente la lista a generar. No obstante se conoce la manera de generar la lista de empleados de la relacin incentivos: Empleado (Incentivos), de igual manera en la relacin Antigedad: Empleado (Antigedad).17

27 Para generar una lista que contenga ambos listados es necesaria la operacin unin, de estos dos conjuntos; es decir, hacen falta todos los nombres de los empleados que aparecen en alguna de las dos relaciones o en ambas. Estos datos se pueden averiguar mediante la operacin binaria unin, denotada igual que en la teora de conjuntos por U. por tanto la expresin buscada es: Empleado (Incentivos) U Empleado (Antigedad) y el resultado mostrara: Empleado Juan Prez Domingo Lpez Laura Flores Elisa Fuentes Ntese que aunque en las relaciones Incentivo y Antigedad, hay dos y tres empleados respectivamente, la relacin final slo muestra cuatro empleados, esto se debe a que la operacin elimina las filas duplicadas y como el empleado Laura Flores tiene Antigedad e incentivos a la vez slo aparece una vez en la ltima relacin. Cabe sealar que la operacin de unin que efectuamos se dio entre dos relaciones que son compatibles, es decir que poseen el mismo tipo de dominio, como lo es Empleado, no tendra sentido tratar de hacer una operacin de unin entre el dominio empleado de la relacin incentivo, con el dominio NomSuc de la relacin Salarios. Adems se debe tomar en cuenta el nmero de campos de la relacin, en el caso de incentivos tiene dos campos, mientras que Salarios tiene cinco campos.Salarios CodSuc NomSuc CodEmpleado Empleado Salario

Por tanto para que la relacin que una operacin unin rUs sea vlida hay que exigir que se cumplan dos condiciones: Las relaciones r y s deben tener el mismo nmero de atributos. Los dominios de los atributos i-simos de r y de s deben ser iguales para todo i. Tngase en cuenta que r y s pueden ser en general relaciones temporales que sean resultado de expresiones de lgebra relacional. DIFERENCIA DE CONJUNTOS La operacin diferencia de conjuntos denotada por el operador aritmtico -, permite buscar los registros que estn en una relacin pero no en otra. La expresin r-s da como resultado una relacin que contiene las tuplas que estn en r pero no estn en s. Se pueden buscar todos los empleados que no tengan incentivos, o antigedad, escribiendo: Empleado (Salarios) - Empleado (Incentivos) Empleado Domingo Lpez Elisa Fuentes18

27

Ana Figueroa Lester Jirn Empleado (Salarios) - Empleado (Antigedad) Empleado Juan Prez Ana Figueroa Lester Jirn

19

27 PRODUCTO NATURAL Esta operacin implica la combinacin de cada uno de los registros de una tabla origen con cada uno de los de una tabla destino, para lo cual es necesario que exista al menos algn campo en comn entre ambas tablas. El resultado de la operacin genera otra tabla que contiene todos los campos tanto de la tabla origen como la destino, sin repetir aquellos que sean comunes. Para que un par de campos se consideren comunes entre dos tablas, debe existir correspondencia exacta tanto en nombre como en tipo. Su sintaxis es: Tabla origen |X| Tabla destino PRODUCTO CARTESIANO Este tipo de producto tambin implica la combinacin de todos los registros de una tabla origen con todos los de una tabla destino, sin la necesidad que existan campos en comn entre ambas tablas, pero en caso de existir, en la tabla resultante se duplican los campos iguales. Se sabe que si se realiza el Producto Natural entre dos tablas que no tienen campos comunes, se convierte en Producto Cartesiano. Su sintaxis es: Tabla origen X Tabla destino Minera de datos (DM, Data Mining) Consiste en la extraccin no trivial de informacin que reside de manera implcita en los datos. Dicha informacin era previamente desconocida y podr resultar til para algn proceso. En otras palabras, la minera de datos prepara, sondea y explora los datos para sacar la informacin oculta en ellos. Bajo el nombre de minera de datos se engloba todo un conjunto de tcnicas encaminadas a la extraccin de conocimiento procesable, implcito en las bases de datos. Est fuertemente ligado con la supervisin de procesos industriales ya que resulta muy til para aprovechar los datos almacenados en las bases de datos. Las bases de la minera de datos se encuentran en la inteligencia artificial y en el anlisis estadstico. Mediante los modelos extrados utilizando tcnicas de minera de datos se aborda la solucin a problemas de prediccin, clasificacin y segmentacin. Es un conjunto de tcnicas y tecnologas que permiten explorar grandes bases de datos, con el objetivo de encontrar patrones repetitivos, tendencias o reglas que expliquen el comportamiento de los datos en un determinado contexto. Surge para intentar ayudar a comprender el contenido de un repositorio de datos. De forma general, los datos son la materia prima bruta. En el momento que el usuario les atribuye algn significado especial se convierten en informacin. Cuando los especialistas elaboran o encuentran un modelo, haciendo que la interpretacin que surge entre la informacin y ese modelo represente un valor agregado, entonces nos referimos al conocimiento. Programacin orientada a objetos Paradigma de programacin que usa objetos y sus interacciones para disear aplicaciones y programas de computadora. Est basado en varias tcnicas, incluyendo herencia, modularidad, polimorfismo y encapsulamiento. Su uso se populariz a principios de la dcada de 1990. Actualmente son muchos los lenguajes de programacin que soportan la orientacin a objetos. (C++, C#, Java, JavaScript, VisualBasic, VisualFox, etc.) Introduccin20

27 Los objetos son entidades que combinan estado, comportamiento e identidad: * El estado est compuesto de datos, ser uno o varios atributos a los que se habrn asignado unos valores concretos (datos). * El comportamiento est definido por los procedimientos o mtodos con que puede operar dicho objeto, es decir, qu operaciones se pueden realizar con l. * La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto anlogo al de identificador de una variable o una constante). La programacin orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y mdulos ms fciles de escribir, mantener y reutilizar. De esta forma, un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interaccin llamados mtodos que favorecen la comunicacin entre ellos. Esta comunicacin favorece a su vez el cambio de estado en los propios objetos. Esta caracterstica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento. Los mtodos (comportamiento) y atributos (estado) estn estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de mtodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos. Hacerlo podra producir el hbito errneo de crear clases contenedoras de informacin por un lado y clases con mtodos que manejen a las primeras por el otro. De esta manera se estara realizando una programacin estructurada camuflada en un lenguaje de programacin orientado a objetos. Esto difiere de la programacin estructurada tradicional, en la que los datos y los procedimientos estn separados y sin relacin, ya que lo nico que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programacin estructurada anima al programador a pensar sobre todo en trminos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programacin estructurada slo se escriben funciones que procesan datos. Los programadores que emplean este nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitndoles que realicen sus mtodos por s mismos. La programacin orientada a objetos tom posicin como el estilo de programacin dominante a mediados de los aos ochenta, en gran parte debido a la influencia de C++, una extensin del lenguaje de programacin C. Su dominacin fue consolidada gracias al auge de las Interfaces grficas de usuario, para las cuales la programacin orientada a objetos est particularmente bien adaptada. En este caso, se habla tambin de programacin dirigida por eventos. Existen otros factores relacionados a la construccin de bases de datos distribuidas que no se presentan en bases de datos centralizadas. Entre los ms importantes se encuentran los siguientes: 1. Diseo de la base de datos distribuida. En el diseo de bases de datos distribuidas se debe considerar el problema de cmo distribuir la informacin entre diferentes sitios. Existen razones organizacionales las cuales determinan en gran medida lo anterior. Sin21

27 embargo, cuando se busca eficiencia en el acceso a la informacin, se deben abordar dos problemas relacionados. Primero, cmo fragmentar la informacin. Segundo, cmo asignar cada fragmento entre los diferentes sitios de la red. En el diseo de la BDD tambin es importante considerar si la informacin est replicada, es decir, si existen copias mltiples del mismo dato y, en este caso, cmo mantener la consistencia de la informacin. Finalmente, una parte importante en el diseo de una BDD se refiere al manejo del directorio. Si existen nicamente usuarios globales, se debe manejar un solo directorio global. Sin embargo, si existen tambin usuarios locales, el directorio combina informacin local con informacin global. 2. Procesamiento de consultas. El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD ste adquiere una relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para manipulacin de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema. As, el procesamiento de consultas presenta un problema de optimizacin para determinar el orden en el cual se hace la menor cantidad de operaciones. Este problema de optimizacin es difcil, por lo que en tiempos razonables slo se pueden obtener soluciones aproximadas. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisin de informacin al lugar en donde se solicit la consulta. 3. Control de concurrencia. Permite a los usuarios acceder a la base de datos en una forma multiprogramada mientras se preserva la ilusin de que cada usuario est utilizndola solo en un sistema dedicado. El control de concurrencia asegura que transacciones mltiples sometidas por usuarios diferentes no interfieran unas con otras de forma que se produzcan resultados incorrectos. En BDD el control de concurrencia es an ms complejo que en sistemas centralizados. Los algoritmos ms utilizados son variaciones de aquellos usados en sistemas centralizados: candados de dos fases, ordenamiento por estampas de tiempo, ordenamiento por estampas de tiempo mltiples y control de concurrencia optimista. Un aspecto interesante del control de concurrencia es el manejo de interbloqueos. El sistema no debe permitir que dos o ms transacciones se bloqueen entre ellas. 4. Confiabilidad. En cualquier sistema de bases de datos, centralizado o distribuido, se debe ofrecer garantas de que la informacin es confiable. As, cada consulta o actualizacin de la informacin se realiza mediante transacciones, las cuales tienen un inicio y fin. En sistemas distribuidos, el manejo de la atomicidad y durabilidad de las transacciones es an ms complejo, ya que una sola transaccin puede involucrar dos o ms sitios de la red. As, el control de recuperacin en sistemas distribuidos debe asegurar que todos los agentes que participan en una transaccin realicen un

22

27 compromiso (commit) al unsono o todos al mismo tiempo restablezcan la informacin anterior (roll-back).

Arquitectura de bases de datos distribuidas. En un sistema de bases de datos distribuidas, existen varios factores que se deben tomar en consideracin ya que definen la arquitectura del sistema: 1. Distribucin: Los componentes del sistema estn localizados en la misma computadora o no. 2. Heterogeneidad: Un sistema es heterogneo cuando existen en l componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc. 3. Autonoma: Se puede presentar en diferentes niveles, los cuales se describen a continuacin: * Autonoma de diseo: Habilidad de un componente del sistema para decidir cuestiones relacionadas a su propio diseo. * Autonoma de comunicacin: Habilidad de un componente del sistema para decidir cmo y cundo comunicarse con otros SMBD. * Autonoma de ejecucin: Habilidad de un componente del sistema para ejecutar operaciones locales como quiera. Tecnologa DRDA (Distributed Relational Database Architecture) Arquitectura distribuida para bases de datos relacionales desarrollada por IBM. Definiciones previas: Sistema distribuido: Un ambiente computacional se dice que es distribuido cuando sus programas o BDs estn ubicados en dos o ms computadoras. Unidad de trabajo: UOW es una sola transaccin lgica. Consiste en una secuencia de declaraciones del SQL en las cuales o todas las operaciones se realizan con xito, o la secuencia en su totalidad se considera fracasada. Unidad distribuida de trabajo: DUOW, tambin conocida como actualizacin del multisite, es una funcin que permite a sus usuarios poner al da datos en servidores alejados de la base de datos, garantizndose la integridad de los mismos. Por ejemplo, una transaccin de las actividades bancarias que implique la transferencia del dinero a partir de una cuenta a otra en diversos servidores de la base de datos. Implica ms de un servidor de la base de datos dentro de una unidad de trabajo y tiene las caractersticas siguientes: Ms de un servidor de la gestin de la base de datos son actualizados por unidad de trabajo. Puede haber peticiones mltiples por unidad de trabajo. Hay un servidor de la gestin de la base de datos por peticin. La comisin se coordina a travs de los servidores mltiples de la base de datos. Unidad remota de trabajo: Apoya el acceso a una base de datos dentro de una unidad de trabajo. Mientras que un programa de uso puede poner al da varias bases de datos remotas, puede tener acceso solamente a una base de datos dentro de una unidad de trabajo.

23

27 Peticiones distribuidas: Funcin de la base de datos distribuida que permite que los usos y los usuarios sometan declaraciones del SQL que referencian dos o ms DBMSs o bases de datos en una sola declaracin. La peticin distribuida proporciona la transparencia de la localizacin para los objetos de la base de datos. Si se mueve la informacin (en tablas), las referencias a esa informacin (llamada alias) pueden ser actualizadas sin ningn cambio a los usos o programas que solicitan la informacin. DRDA es un sistema de protocolos, o de reglas, que permiten a un usuario tener acceso a los datos distribuidos sin importar dnde residen fsicamente. Proporciona un ambiente de base de datos distribuido heterogneo, abierto y robusto. DRDA proporciona mtodos para coordinar la comunicacin entre localizaciones distribuidas. Esto permite que se tenga acceso a tablas alejadas en mltiples localizaciones, y que al usuario del otro extremo le parezca como si estuvieran todas en un mismo ente lgico. Una distincin se debe hacer, sin embargo, entre la arquitectura y la puesta en prctica: DRDA describe la arquitectura para los datos distribuidos y nada ms. Define las reglas para tener acceso a los datos distribuidos, pero no proporciona los interfaces de programacin de uso reales (APIs) para realizar el acceso. DRDA no es un programa real, sino es ms como las especificaciones para un programa. Cuando un DBMS se dice que es DRDAobediente, implica que sigue las especificaciones de DRDA. En resumen, DRDA es un estndar para distribuir la informacin de las bases de datos que tienen acceso a travs de plataformas IBM, que siguen estndares del SQL. Es una arquitectura que permite que datos relacionados sean distribuidos entre mltiples plataformas que no necesitan ser iguales. Mientras ambos se conformen con las especificaciones de DRDA, podrn comunicarse. DRDA se puede considerar una clase "de protocolo universal para realizar el distribuido de los datos." Los Cinco Niveles de DRDA Hay cinco niveles dentro de DRDA. Cada nivel representa un aumento de la distribucin. Adems, los niveles reflejan: el nmero de peticiones y de RDBMS (Relational Data Base Management System) por unidad de trabajo el nmero de RDBMS por peticin En orden creciente de complejidad, los cinco niveles de DRDA son: Distribucin Asistida por Usuario Peticin Remota Unidad remota de trabajo (RUW) Unidad distribuida del trabajo (DUW) Peticin Distribuida El resultado al ir aumentando los niveles es aditivo. Por ejemplo, la capacidad distribuida de la peticin implica la unidad distribuida del trabajo (que a su vez implica la unidad remota del trabajo). a) Distribucin Asistida por Usuario (userassisted distribution) es la forma ms simple de distribucin de los datos. Sin embargo, bajo este nivel de DRDA, el usuario final es consciente de la distribucin y es un experto y participa en los accesos distribuidos. Para lograr la distribucin Asistida por Usuario, el usuario debe: Extraer los datos necesarios del sistema original Cargar los datos extrados al sistema solicitante24

27 Este es un procedimiento intenso y costoso que debera no ser tomado a la ligera. Como ello implica replicar los datos, se debe tener cuidado con la documentacin del sistema de registros y las fechas de extracciones en casos de que estn permitidas futuras modificaciones. Incluso viendo estas limitaciones, la distribucin Asistida por Usuario es til para producir vistas de tablas y peticiones satisfactorias. Sin embargo, muchas veces, la distribucin asistida por usuario no es considerada verdaderamente un acceso distribuido a los datos. b) Peticiones remotas o alejadas (Remote Request): Las peticiones remotas son verdaderamente el primer nivel de distribucin con DRDA. Cuando un DBMS soporta DRDA con capacidad de peticiones remotas, una sola sentencia SQL pude ser distribuida para leer o modificar un nico RDBMS remoto con una nica unidad de trabajo. Simplemente, un promotor de peticiones remotas opera con un RDBMS, y remite a diferentes RDBMS. Adems, es posible utilizar capacidades de peticiones remotas para acceder a RDBMS remotos, incluso si el RDBMS local no est siendo usado. DRDA con peticiones remotas provee la capacidad de emitir slo una peticin SQL por unidad de trabajo, y slo un RDBMS por peticin SQL. c) Unidad remota de trabajo (Remote Unit of Work): Se aade a la funcionalidad de peticiones remotas. RUW permite mltiples sentencias SQL. Sin embargo, el SQL slo puede leer y/o modificar un RDBMS remoto con una unidad de trabajo. Para aclararnos, en el mbito de un commit, con RUW se puede acceder slo a un RDBMS. Por tanto, DRDA con unidad remota de trabajo provee la capacidad de emitir mltiples peticiones SQL por unidad de trabajo, pero todava se puede acceder solamente a un RDBMS por peticin SQL. d) Unidad distribuida del trabajo (Distributed Unit of Work) Se construye sobre la funcionalidad de la unidad remota de trabajo. Ahora, ms de un RDBMS puede ser accedido por unidad de trabajo. Sencillamente, DRDA con DUW permite mltiples sentencias SQL para leer y/o modificar mltiples RDBMS's con slo una unidad de trabajo. Sin embargo, slo un RDBMS puede ser especificado por sentencia SQL. Como con cualquier unidad de trabajo, todas las peticiones SQL en el mbito de un commit deben tener xito o ser canceladas. Esto requiere que est establecido el protocolo de la confirmacin en 2 fases. Cuando un programa DUW emite un commit, el protocolo de la confirmacin en 2 fases debe sincronizar todas las plataformas afectadas. e) Peticin distribuida (Distributed Request): permite la distribucin completa de los datos. Usando peticiones distribuidas, la restriccin del DUW de slo un RDBMS por sentencia SQL es eliminada. Adicionalmente, mltiples peticiones SQL, tanto distribuidas como no distribuidas, pueden ser contenidas por slo una unidad de trabajo. Sencillamente, una peticin SQL distribuida puede leer y/o actualizar mltiples RDBMSs al mismo tiempo. La siguiente Tabla muestra un pequeo resumen de los niveles de DRDA: Nivel de DRDA Op. Sql DBMS por Op. de SQL DBMS por UOW Asistido por Usuario Peticin Remotas 1 1 1 Unidad remota de trabajo >1 1 1 Unidad distribuida del trabajo > 1 >1 125

27 Peticin Distribuida >1 >1 >1 Tabla : Los Cinco Niveles de DRDA Ejemplo juntando todos estos niveles Consideramos un escenario donde son establecidas tres localizaciones de procesamiento remotos, cada uno con un RDBMS: A Durango, DF y MTY. Vamos a examinar cmo cada una de las 4 opciones de DRDA podran acceder a datos distribuidos de esas localizaciones. Consideramos una situacin en la que necesitamos accesos por columnas especficas de tablas en cada una de las localizaciones remotas. Hay cuatro tablas totales: dos en Durango, una en DF y otra en MTY. Adems, asumimos que las peticiones proceden del DF. En un escenario de peticiones remotas, nosotros podremos acceder solamente a un RDBMS de una localizacin en una sola unidad de trabajo. La peticin a una tabla del DF es una peticin local; las peticiones a Durango y MTY son remotas. Cada peticin viene incluida en una unidad de trabajo (indicado por un commit). Hay cuatro UOWs totales, una para MTY y DF, y dos para Durango, una por cada select a las dos tablas que existen en Durango. Ahora, en contraste est la funcionalidad de unidad remota de trabajo con peticiones remotas. En vez de una nica sentencia por unidad de trabajo, estn permitidas varias sentencias. Por tanto, la peticin de Durango ahora puede consistir en ambas peticiones select (una por cada tabla) con la misma unidad de trabajo. Con RUW nosotros hemos pasado de cuatro UOWs a tres. Despus, la unidad distribuida de trabajo permite mltiples RDBMSs por unidad de trabajo. Las 4 tablas de las tres localizaciones pueden ser accedidas con una unidad de trabajo usando DRDA con funcionalidad DUW. Finalmente, tenemos las peticiones distribuidas. Usando peticiones distribuidas, mltiples RDBMSs de varias localizaciones pueden ser accedidos usando slo una peticin SQL. En este escenario, la aplicacin cliente emite una peticin a la aplicacin servidor del DF, la cual enviar la peticin al servidor de base de datos del DF. Este proceso puede y es pasado a uno de los otros servidores de base de datos (por ej. Durango). Con las peticiones distribuidas no slo tenemos un UOW, sino que podemos tener una peticin SQL uniendo tablas de otras localizaciones. ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS La mayora de los sistemas de manejo de bases de datos disponibles actualmente estn basadas en la arquitectura ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) la cual divide a un sistema en tres niveles: interno, conceptual y externo. La vista conceptual, conocida tambin como vista lgica global, representa la visin de la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma en que las aplicaciones individuales observan los datos o cmo son almacenados. La vista conceptual est basada en el esquema conceptual y su construccin se hace en la primera fase del diseo de una base de datos. Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a travs de un esquema externo. La vista externa proporciona una ventana a la vista conceptual lo cual permite a los usuarios observar nicamente los datos de inters y los asla de otros datos en la base de datos. Puede existir cualquier nmero de vistas externas y ellos pueden ser completamente independientes o traslaparse entre s. El esquema conceptual se mapea a un esquema interno, el cual es el nivel de descripcin ms bajo de los datos en una base de datos. Este proporciona una interfaz al sistema de26

27 archivos del sistema operativo el cual es el responsable del acceso a la base de datos. El nivel interno tiene que ver con la especificacin de qu elementos sern indexados, qu tcnica de organizacin de archivos utilizar y cmo los datos se agrupan en el disco mediante "clusters" para mejorar su acceso.

27

27 https://sites.google.com/site/wikiarturolugo/ arturolugom@hotmail.com Reglas del juego: se nombrar lista 15 minutos despus de la hora de entrada y quien llegue despus de nombrar lista ya no tendr posibilidad de retardo, tendr inasistencia, las inasistencias generan un punto negativo. Para justificar una falta debern traer un documento oficial, constancia de servicios mdicos del sector salud, de su trabajo, etc, de otra manera no se justificar la falta. Soy exigente con la asistencia (usando un criterio similar al que una empresa usa para medir la asistencia de sus empleados) ya que incidir directamente en la calificacin. Adems les entrego el material ya desarrollado tema por tema. Se forman equipos por afinidad y les hago hincapi en que escojan bien a los integrantes porque el desempeo de cada uno afectar directamente en la calificacin. Diariamente genero un nmero al azar, del 1 al 20 por ejemplo, si son 20 alumnos, y el alumno seleccionado deber exponer el tema que corresponde a ese da. Si la exposicin es buena, suma una participacin al equipo, si no es buena queda tablas, pero si no expone, tendr un valor negativo. Deber responder a las preguntas que haga el grupo. En ocasiones, si no hay preguntas quiere decir que el tema se expuso claramente y qued bien comprendido (o que nadie entendi), por lo que si los asistentes a la exposicin no formulan preguntas, las preguntas las har yo al grupo, no al expositor, lo hago as a fin de estimular la participacin, ya que sera muy cmodo que no pregunten y asumir que todo est claro, y segn las respuestas entonces me doy cuenta si se entendi o no, y si no, le pido al expositor que lo explique o confronto las opiniones para sacar conclusiones correctas. Hago la aclaracin de que el hecho de dejar la exposicin de un tema en manos de un alumno, no me exime de mi responsabilidad de aclarar dudas y hacer que el tema se entienda, pero la intencin es que el alumno se involucre con el material. Si el expositor, a mi juicio, comete una equivocacin o da alguna informacin con la que yo no estoy de acuerdo, expongo mi punto de vista y genero el intercambio de ideas. Si hay algn punto en que el expositor se trabe, su equipo puede auxiliarlo y as ayudar a que sumen participaciones positivas. Las aportaciones que se hagan a la clase, que sean relevantes, ya sea por el expositor, su equipo o cualquiera de los asistentes, representarn puntos a quien corresponda. Al final de la unidad, el equipo tendr un total de participaciones, el cual, se convertir en el total de cada uno de los integrantes, es decir, si el equipo sum al final de la unidad 8 puntos, cada elemento tendr 8 puntos positivos.

28

27 De forma individual se contabilizarn las inasistencias, de manera que si un elemento de ese equipo obtuvo 8 participaciones y 0 faltas, su total ser de 8, si alguien del mismo equipo tuvo 10 faltas, su total ser de -2. Quien de forma individual tenga un saldo positivo despus de haber restado participaciones menos faltas, habr acreditado la unidad. La forma de establecer la calificacin ser: El total final ms alto ser 100, el total final positivo menor ser el 70, por ejemplo si el alumno que obtuvo mayor puntuacin tuvo 10 puntos a favor, tendr 100, el que haya tenido 1 punto a favor tendr 70, y los valores intermedios se tabularn para que cada alumno obtenga su calificacin en la unidad. Quien tenga un saldo de 0 o menos deber presentar examen y su calificacin la obtendr directamente del examen De esta manera trato de abarcar varios puntos, entre los cuales estn: Utilizar un sistema de control de asistencia similar al de una empresa: quien falta y no justifica la falta tendr un descuento en su salario, y en este caso, en su calificacin, as se van acostumbrando a cumplir con la responsabilidad de asistir, y de esa forma no batallo los viernes, que tradicionalmente causan conflicto en cuanto a la asistencia, porque los alumnos saben que una falta afectar directamente a la calificacin, y slo de forma individual, es decir, las faltas de un integrante no afectan al equipo. Se fomenta el trabajo en equipo porque las participaciones o negativas de participacin individuales inciden directamente en el total del equipo, y los integrantes debern participar activamente para sacar al equipo adelante. Se fomenta la lectura y la investigacin, ya que la participacin ser tomada en cuenta nicamente si tiene calidad y comprueba que el alumno se document, no basta con pasar al frente del grupo y leer, eso no da puntos. Fomenta la iniciativa, ya que al ser designados al azar, no todos tendrn posibilidad de pasar a exponer, pero si alguien desea sumar puntos, y tiene una aportacin que quiera compartir, y esta aportacin cumple con los requisitos para ser tomada en cuenta, sumar al total del equipo, as no los limito a ver slo el material que yo proporciono. Si aun as, a alguien no le alcanza su esfuerzo para obtener un saldo positivo, todava tiene la oportunidad de acreditar la unidad en un examen tradicional

29