2 DISEÑO DE LAS BDD

2.1 DEFINICIONES

Álgebra relacional

Es un conjunto de operaciones que describen paso a paso cómo 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 manipulación de datos. Estas operaciones se usan como una representación intermedia de una consulta a una base de datos y, debido a sus propiedades algebraicas, sirven para obtener una versión más optimizada y eficiente de dicha consulta.

Se van a explicar algunos operadores de álgebra relacional, que nos van a ser necesarios para entender las reglas de fragmentación.

JOIN

La sentencia join en SQL permite combinar registros de dos o más tablas en una base de datos relacional. Para hacer un join es necesario que exista un campo que relacione los datos de cada tabla.

SEMI-JOIN

También conocida como semi-combinación. Opera de la misma manera que un join, pero la relación resultante sólo tiene los atributos de la primera tabla.

Bibliográfia: Universidad Carlos III de Madrid, Pagina 20, Diseño y Construccion de bases de datos distribuidas Heterogéneas sobre Oracle y SQL Server.

2.2 ALTERNATIVAS DE DISEÑO

En todo proceso de diseño hay dos aproximaciones básicas:

• La ascendente o Top-Down.
• La descendente o Bottom-Up.

El diseño ascendente se utiliza, cuando se crea un BDD a partir de varias BBDD locales existentes. Se parte de varios esquemas lógicos locales (ELL) con ubicaciones diferentes que se integran en un único esquema lógico global (ELG).

El diseño descendente parte de un ELG y construye varios ELL definidos a partir de esquemas de fragmentación, asignación y replicación que determinan la distribución de los datos en los distintos nodos de la red.

Bibliografia: Universidad Carlos III de Madrid, Pagina 21, Diseño y Construccion de bases de datos distribuidas Heterogéneas sobre Oracle y SQL Server.

2.3. FRAGMENTACIÓN

La fragmentación es un conjunto de técnicas para dividir la BD en unidades lógicas, llamadas fragmentos, cuyo almacenamiento puede asignarse a los diversos sitios. Estas técnicas se utilizan durante el proceso de diseño de BDD. La información concerniente a la fragmentación de los datos se almacena en un catálogo global del sistema al que tiene acceso el software cliente cuando es necesario.

La fragmentación es un concepto que surge en los modelos que incluyen algún tipo de particionado y tiene implicaciones físicas y lógicas.

•      Fragmento lógico: Bloque de datos localizado en algún SGBDD que puede ser descrito (en términos relacionales) como el resultado de una proyección y/o una selección de la información contenida en la BD, de modo que resulten subconjuntos disjuntos de ella. Por tanto, una vez que la BD ha sido dividida en un conjunto de fragmentos, todos los datos aparecen en uno y sólo uno de estos fragmentos

•       Fragmento físico: Subconjunto de un fragmento lógico que se almacena completo en un nodo. Cada uno de los fragmentos físicos de un fragmento lógico se localizan en uno o más nodos dependiendo del modelo de distribución de los datos. 

El esquema de fragmentación es el conjunto de las distintas relaciones que se han obtenido del ELG y las condiciones empleadas para esta división expresado en algebra relacional. 

Existen distintas formas de fragmentar una relación:

 Fragmentación vertical

 Fragmentación horizontal

 Fragmentación mixta

Razones para la fragmentación

Los esquemas de fragmentación se diseñan teniendo en cuenta el uso que se va a hacer de los datos que se almacenan en cada una de las sedes, construyendo relaciones más pequeñas y más adaptadas a las operaciones de recuperación y actualización que utilizan las aplicaciones, tratando así de aligerar las comunicaciones entre los nodos debido al alto coste que éstas tienen.

Las cuatro razones para la fragmentación son las siguientes:

 Es útil ya que las aplicaciones de BD suelen funcionar con vistas, y por ello se pueden utilizar distintas relaciones en distintos nodos para formar la unidad distribuida.

 Se consigue una mayor eficiencia dado que los datos suelen estar almacenados cerca del nodo que más utiliza dichos datos.

 Permite aumentar el grado de concurrencia porque la fragmentación de las relaciones permite que una transacción pueda dividirse en subconsultas que operan sobre estos fragmentos.

 Aporta una mayor seguridad, dado que los datos no utilizados por un nodo local no se almacenan en él y por lo tanto no están al alcance para personas sin autorización.

Si las aplicaciones tienen requisitos conflictivos que impiden la descomposición de la relación en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas se definen en más de un fragmento pueden sufrir una degradación del rendimiento. 

El segundo problema está relacionado con el control semántico de los datos, especialmente para el control de integridad. Como resultado de la fragmentación, los atributos que participan en una dependencia pueden ser descompuestos en diferentes fragmentos que pueden ser asignados a diferentes sitios. En este caso, incluso la simple tarea de comprobar las dependencias daría lugar a la búsqueda de los datos en diferentes sitios.

Requisitos de información 

Uno de los aspectos del diseño de distribución es que contribuyen demasiados factores para conseguir un diseño óptimo. La organización lógica de la base de datos, la ubicación de las aplicaciones, las características de las solicitudes de acceso a la base de datos, y las propiedades de los sistemas informáticos en cada sitio tienen influencia sobre las decisiones de distribución. Esto hace que sea muy complicado para formular un problema de distribución.

La información necesaria para el diseño de la distribución puede dividirse en cuatro categorías: información de la base de datos, la aplicación de la información, información de la red de comunicación, y sistema informático

Reglas de fragmentación

Hay que tener en cuenta que la fragmentación podría afectar al rendimiento del SGBDD, especialmente cuando se utilizan distintos fragmentos ubicados en distintos nodos para construir una vista. También el control de la semántica de los datos puede ser más complicado por la fragmentación.

Para asegurar que la BD no sufrirá cambios semánticos durante la fragmentación de los datos, se definen las siguientes tres normas que determinen la calidad de la fragmentación de una relación :

Completitud: Sea R una relación descompuesta en fragmentos F(R) = {R1, R2,…, Rn}. Entonces cada atributo de la relación deberá encontrarse en al menos uno de los fragmentos Ri asegurando así que no hay pérdida de información.

Reconstrucción: si una relación R se descomponen en fragmentos de la forma R1, R2,.., Rn, debería ser posible definir un operador relacional ∇ tal que R = ∇ Ri para todo Ri є FR (Fragmentos de R).

El operador ∇ será diferente para cada forma de fragmentación; sin embargo es importante poder identificarlo. Esta regla asegura que las restricciones de integridad referencial están resguardadas.

Disyunción: si una relación R es fragmentada horizontalmente en R1, R2,…, Rn, y el dato di está en Rj y solo en Rj. Esta regla asegura que los fragmentos son disjuntos. Si se trata de una fragmentación vertical, sólo los atributos clave deben estar repetidos en todos los fragmentos, de modo que la propiedad disyunción se refiere únicamente a los restantes atributos

Fragmentación vertical

La fragmentación vertical divide la relación verticalmente en columnas, así cada fragmento mantiene ciertos atributos de la relación original [2].  La fragmentación se realiza mediante la operación PROYECCIÓN: ∏Li (R) donde i= 1...n y Ri es el conjunto de fragmentos en que se divide la relación original. Li es el criterio de fragmentación.

Para que la fragmentación vertical sea correcta los subconjuntos de atributos Li han de cumplir:

·         La unión de todos los Li contiene todos los atributos de la relación original.

·         La intersección de todos los Li consiste en la clave primaria de la relación original. Todos los Li tienen en común la clave primaria para poder reconstruir R mediante JOIN.

Suponiendo que en el campus de Getafe hubiera un nodo de la BD y otro nodo se ubicara en el campus de Leganés, y que por ejemplo el tratamiento y consulta de los datos personales se hiciera en el primer campus y el concerniente a los datos académicos se hiciera en el segundo, podría ser interesante realizar una fragmentación vertical en la que por un lado estuvieran: - los datos personales con los campos “Nombre”, “Apellidos” y “Edad” (L1). - y otra de datos académicos con los campos “Campus”, “Titulación” y “Cursos” (L2).

Así, se podría almacenar una subrelación (fragmento) en el campus de Getafe y otra en el campus de Leganés, quedando cada subrelación de la siguiente manera:

Fragmentación horizontal

La fragmentación horizontal divide la relación en subconjuntos de tuplas, cada uno de ellos con un significado lógico.

La fragmentación se realiza mediante la operación SELECCIÓN: σ Ci (R)  Existen dos tipos de fragmentación horizontal: primaria y derivada. En la Ilustración 3 se puede observar un esquema de la fragmentación horizontal y en Ejemplo 2 un caso de fragmentación horizontal de una tabla. - Primaria, es una selección de la relación original.  La fragmentación se realiza mediante la operación Ri = σPi (R) donde Pi es un predicado sobre uno o más atributos de R y es la condición empleada para seleccionar el contenido de los fragmentos.  

- Derivada, es una selección en función de predicados definidos sobre atributos de otras relaciones o fragmentos; esto se debe a que la relación R a fragmentar depende de la relación Q. Además, R hace referencia a Q mediante una clave

ajena. La fragmentación se realiza mediante la operación Ri = RQi donde Qi corresponde al conjunto de fragmentos en los que se ha dividido la relación Q.

La semicombinacion ( ) se hace por el atributo que relacionan estas dos tablas.

 Para que la fragmentación horizontal sea correcta se tiene que cumplir que:  La unión de todos los Ri sea la relación original (R).   La intersección de todos los Ri sea vacía. La relación original se recupera mediante UNION de los fragmentos. 

Podría ser interesante realizar una fragmentación horizontal por el campo “Campus” y almacenar cada fragmento en cada uno de los campus, suponiendo que en estos hubiera un nodo de la BD, quedando cada subrelación de la siguiente manera: 

ALUMNOS_LEG: Fragmento correspondiente a alumnos del campus de Leganés (R1 = σ (CAMPUS  = Leganés)) 

Fragmentación mixta o híbrida

La fragmentación mixta es la mezcla de fragmentación horizontal y vertical. Hay dos tipos de fragmentación mixta

·         Fragmentación VH Es una fragmentación vertical seguida de una fragmentación horizontal, sobre cada uno de los fragmentos verticales.

Ejemplo 3 fragmentación vertical-horizontal

 En la siguiente relación ALUMNOS (R)

Podría ser interesante realizar una fragmentación vertical en la que se particionaran - los datos personales con los campos “Nombre”, “Apellidos” y “Edad” (FV1) - los datos académicos con los campos “Campus”, “Titulación” y “Cursos” (FV2) Seguida de una fragmentación horizontal por el campo “Campus”. 

De este modo se obtendrían los siguientes fragmentos….  Datos personales (FV1) del Campus Leganés (FV1H1), Campus Getafe (FV1H2) y Campus Colmenarejo (FV1H3)  y datos académicos  (FV2) del Campus Leganés (FV2H1), Campus Getafe (FV2H2) y Campus Colmenarejo (FV2H3).

• ·         Fragmentación HV Es una fragmentación horizontal seguida de una fragmentaciónvertical, sobre cada uno de los fragmentos horizontales.

En la relación ALUMNOS podría ser interesante realizar una fragmentación vertical por el campo “Campus”   Campus de Leganés (FH1) Campus de Getafe (FH2) Campus de Colmenarejo (FH3)

Seguida de una fragmentación vertical (V1) en la que por un lado estuvieran  - los datos personales con los campos “Nombre”, “Apellidos” y “Edad”  (campus de Leganés FH1V1, campus Getafe FH2V1 y  campus Colmenarejo FH3V1) - y otra (V2) de datos académicos con los campos “Campus”, “Titulación” y “Cursos” (campus de Leganés FH1V2, campus Getafe FH2V2 y  campus Colmenarejo FH3V2).

bibliografia: Laura Martínez Martín. (2010). Alternativas de replicación. En Diseño y construción de base de datos distribuidas(21-28). México: Santillas.

2.3.1 ASIGNACIÓN DE FRAGMENTOS

Cada fragmento (o cada copia de un fragmento) se debe asignar a un sitio determinado en el sistema distribuido. Este proceso se denomina distribución de los datos. La elección de la sede y el grado de replicación depende de los objetivos de rendimiento y disponibilidad para el sistema y de los tipos de frecuencias de transacciones introducidas en cada sitio. Por ejemplo, si se requiere una alta disponibilidad, y si las transacciones se pueden introducir en cualquier sitio y si la mayoría de ellas son de obtención de datos, entonces una BD completamente replicada será una buena opción. Sin embargo, si por lo regular ciertas transacciones que tienen acceso a partes específicas de la BD se introducen en un solo sitio, se podría asignar el conjunto de fragmentos correspondiente exclusivamente a ese sitio. Los datos que se utilizan en múltiples sitios se pueden replicar en esos sitios. Si se efectúan muchas actualizaciones, puede ser conveniente limitar la replicación. Encontrar una solución óptima, o siquiera buena, para el reparto de datos distribuidos es un problema de optimización muy complejo.

bibliografia: Laura Martínez Martín. (2010). Alternativas de replicación. En Diseño y construción de base de datos distribuidas(28). México: Santillas.

2.3.2 ALTERNATIVAS DE REPLICACIÓN

La replicación de datos se refiere al almacenamiento de copias de datos en múltiples sitios conectados mediante una red de ordenadores. Pueden guardarse copias fragmentadas en varios sitios para satisfacer requerimientos de información específicos. Como la existencia de copias de fragmentos puede mejorar la disponibilidad de los datos y el tiempo de respuesta, estas copias reducen los costes de comunicación y de consultas totales.

Supóngase que la tabla A está dividida en dos fragmentos A1 y A2. Dentro de una base de datos distribuida replicada, es posible el escenario de la ilustración 6 en el que el fragmento A1 se guarda en los sitios S1 y S2, mientras que el A2 se guarda en los sitios S2 y S3

Los datos replicados se someten a la regla de consistencia mutua. La regla de consistencia mutua requiere que todas las copias de fragmentos de datos sean idénticas. Por consiguiente, para mantener la consistencia de los datos entre las réplicas, el SGBDD debe garantizar que se realice una actualización de la base de datos en todos los sitios donde existan réplicas.

Suponiendo que la base de datos está fragmentada correctamente, hay que decidir la asignación de los fragmentos a diversos sitios en la red. Cuando se asignan los datos, o bien se pueden replicar o mantenerse una sola copia de los mismos. Las razones para la replicación son la disponibilidad, fiabilidad y la eficiencia de consultas de sólo lectura. Si hay múltiples copias de un elemento de datos, hay una buena probabilidad de que alguna copia esté accesible en algún lugar, incluso cuando se producen fallos en el sistema. Por otra parte, las consultas de sólo lectura que acceden a los mismos elementos de datos pueden ser ejecutados en paralelo desde la salida de copias en múltiples sitios. 

Por otra parte, la ejecución de las transacciones de actualización causa problemas ya que el sistema tiene que garantizar que todas las copias de los datos se actualizan correctamente. De ahí que la decisión con respecto a la replicación dependa de la relación existente entre consultas de sólo lectura y consultas de actualización. Esta decisión afecta a casi todos los algoritmos de SGBDD y las funciones de control. 

Una base de datos no replicada (comúnmente se llama base de datos particionada) contiene fragmentos que se asignan a los diferentes sitios, y sólo hay una copia de cada fragmento en la red. En el caso de realizarse replicación, la base de datos puede ubicarse en su totalidad en cada lugar (base de datos totalmente replicada), o los fragmentos pueden distribuirse en los nodos de tal manera que las copias de un fragmento puedan residir en varios emplazamientos (base de datos parcialmente replicada). En este último caso el número de copias de un fragmento puede suponer un aumento de coste para el algoritmo de asignación.  

En la Tabla 1 se comparan estas alternativas con respecto a varias funciones de los SGBD distribuidos.

Aunque la replicación tiene algunos beneficios, también exige más complejidad de procesamiento del SGBDD, porque cada copia de datos debe ser mantenida por el sistema. Para ilustrar la complejidad de un SGBDD, se deben considerar los procesos que el SGBDD debe realizar a la hora de gestionar la base de datos:

• Si la base de datos está fragmentada, el SGBDD debe decidir qué copia acceder. • Una operación de lectura selecciona la copia más cercana para satisfacer la transacción. Una operación de escritura requiere que todas las copias se seleccionen y actualicen para satisfacer la regla de consistencia mutua.

• El procesador de transacciones envía una solicitud de datos a cada procesador de datos para su ejecución.

• El procesador de datos recibe y ejecuta cada solicitud y envía los datos de vuelta al procesador de transacciones.

• El procesador de transacciones construye las respuestas del procesador de datos.

El problema se complica más cuando se consideran factores adicionales tales como la topología de red y los protocolos de comunicación.

BIBLIOGRAFIA: DISEÑO DE BASE DE DATOS DISTRIBUIDA, AQUINO BOLIVIA - 2005.

2.4 CONTROL SEMÁNTICO DE LOS DATOS

La integridad semántica de los datos se refiere a las características del SGBD y los procesos que se pueden utilizar para asegurar la exactitud y la viabilidad del contenido de los datos de una BD. La integridad semántica de los datos se refiere a la consistencia de los datos en sí.

En general, se utilizan las funciones del SGBD para apoyar la integridad de los datos que por lo general ofrece la mejor solución. Es más fácil descubrir y mantener una regla de integridad semántica utilizando las funciones del SGBD que revisando el código del programa. Hay que tener en cuenta que el código puede estar en diferentes lenguajes en un entorno heterogéneo. Además, habrá que distinguir los datos obsoletos de los activos.

BIBLIOGRAFIA:Laura Martínez Martín. (2010). Alternativas de replicación. En Diseño y construción de base de datos distribuidas(28-30). México: Santillas.

2.5 PROCESAMIENTOS DE CONSULTAS

El éxito creciente de la tecnología de bases de datos relacionales en el procesamiento de datos de debe, en parte, a la disponibilidad de lenguajes no procedurales los cuales pueden mejorar significativamente el desarrollo de aplicaciones y la productividad del usuario final. Los lenguajes de bases de datos relacionales permiten la expresión de consultas complejas en una forma concisa y simple. Particularmente, para construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa el procedimiento que se debe seguir. Este procedimiento es llevado a cabo por un módulo del DBMS llamado el procesador de consultas (Query Processor).

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 manipulación 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 optimización en el cual se determina el orden en el cual se hace la menor cantidad de operaciones. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta.

Arquitectura del procesamiento de consultas

Metodología del procesamiento de consultas

Bibliográfica: Diseño de bases de datos distribuidas pag. 56-70, Aquino Bolivia-2005

2.5.1 DEFINICIONES

• Esquema conceptual:

Describe la estructura de toda la base de datos para una comunidad de usuarios. El esquema conceptual oculta los detalles de las estructuras físicas de almacenamiento y se concentra en describir entidades, tipos de datos, vínculos, operaciones de los usuarios y restricciones.

• Esquema Conceptual Local (ECL):

Son los esquemas conceptuales correspondientes a cada vista de usuario.

• Esquema Conceptual Global (ECG).

En el caso de SGBDDs lógicamente integrados, el ECG define la visión global de la BD completa. El ECG es la unión de los Esquemas Conceptuales Locales (ECL).

El procesamiento de consultas se puede descomponer en un número de subconsultas a los que corresponden cada uno de los niveles de un procesador de consultas genérico.

Procesamiento de una consulta

Bibliográfica: Univeridad Carlos III Diseño y Construcción de Bases de Datos Distribuidas Heterogéneas sobre Oracle Y SQL Server, pag. 31 y 32.

2.5.2 DESCOMPOSICIÓN DE CONSULTAS GLOBALES

La primera capa descompone una consulta en el cálculo relacional en una consulta en el álgebra relacional que opera sobre relaciones globales.

Consiste de cuatro partes:

1. Normalización

Involucra la manipulación de los cuantificadores de la consulta y de los calificadores de la misma mediante la aplicación de la prioridad de los operadores lógicos.

La consulta de entrada puede ser arbitrariamente compleja dependiendo de las facilidades provistas por el lenguaje. El objetivo de la normalización es transformar una consulta a una forma normalizada para facilitar su procesamiento posterior. La normalización consiste de dos partes:

El análisis léxico y sintáctico: En esta parte se verifica la validez de la expresión que da origen a la consulta. Se verifica que las relaciones y atributos invocados en la consulta estén acordes con la definición en la base de datos.

2. Análisis

Se detecta y rechazan consultas semánticamente incorrectas.

El análisis de consultas permite rechazar consultas normalizadas para los cuales no se requiere mayor procesamiento. Una consulta se puede rechazar si alguno de sus atributos o nombres de relación no están definidas en el esquema global. También se puede rechazar si las operaciones que se aplican a los atributos no son del tipo adecuado.

En una gráfica de consulta, un nodo indica la relación resultante, y cualquier otro nodo representa la relación operante. Un arco entre dos nodos que no son resultados representa una junta, mientras que un arco cuyo nodo destino es una relación resultante representa una proyección.

Una subgráfica importante de la gráfica de conectividad es la gráfica de juntas, en la cual únicamente se consideran las juntas.

La gráfica de juntas es particularmente importante durante la fase de optimización.

3. Simplificación

Elimina predicados redundantes.

La consulta en forma normal conjuntiva puede contener predicados redundantes.

Una evaluación directa de la consulta con redundancia puede llevarnos a realizar trabajo duplicado.

4. Reestructuración

Mediante reglas de transformación una consulta en el cálculo relacional se transforma a una en el álgebra relacional. Se sabe que puede existir más de una transformación. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla.

El último paso en la descomposición de consultas, reescribe la consulta en el álgebra relacional.

Esto se hace típicamente en los siguientes pasos:

a. Una transformación directa del cálculo relacional en el álgebra relacional

b. Una reestructuración de la consulta en el álgebra relacional para mejorar la eficiencia

Por claridad es costumbre representar la consulta en el álgebra relacional por un árbol del álgebra relacional, el cual es un árbol en donde una hoja representa a una relación almacenada en la base de datos y un nodo no hoja es una relación intermedia producida por una operación del álgebra relacional.

BIBLIOGRAFIA: DISEÑO DE BASE DE DATOS DISTRIBUIDA, AQUINO BOLIVIA - 2005.

2.5.3 LOCALIZACIÓN DE LOS DATOS

La entrada a esta capa es una consulta algebraica definida sobre relaciones distribuidas.

El objetivo de esta capa es localizar los datos de la consulta usando la información sobre la distribución de datos.

Esta capa determina cuales fragmentos están involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

La fragmentación de una relación se define a través de las reglas de fragmentación, las cuales pueden ser expresadas como consultas relacionales.

Una relación global puede ser reconstruida aplicando las reglas de reconstrucción y derivando un programa en el álgebra relacional cuyos operandos son los fragmentos.

A este programa se le conoce como programa de localización.

Una forma simple de localizar una consulta distribuida es generar una consulta donde cada relación global es sustituida por su programa de localización.

Esto puede ser visto como el reemplazo de las hojas del árbol del álgebra relacional de la consulta distribuida con subárboles que corresponden a los programas de localización.

A la consulta obtenida por esta forma se le conoce como una consulta genérica.

En general, el enfoque anterior puede ser ineficiente dado que varias simplificaciones y reestructuraciones de la consulta genérica aún pueden ser realizadas.

Por cada tipo de fragmentación se presentan técnicas de reducción que general consultas simples y optimizadas:

A) Reducción para fragmentación horizontal primaria.

B) Reducción para fragmentación vertical.

C) Reducción para fragmentación horizontal derivada.

D) Reducción para fragmentación híbrida.

BIBLIOGRAFIA: DISEÑO DE BASE DE DATOS DISTRIBUIDA, AQUINO BOLIVIA - 2005.

2.6 CONTROL DE CONCURRENCIA BDD

El control de concurrencia trata con los problemas de aislamiento y consistencia del

procesamiento de transacciones. El control de concurrencia distribuido de un SGBDD

asegura que la consistencia de la BD se mantiene en un ambiente distribuido

multi usuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción individualmente, una después de otra. Sin embargo, esto puede afectar en gran medida al desempeño de un SGBDD dado que el nivel de concurrencia se reduce al mínimo .El nivel de concurrencia, el número de transacciones activas es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la BD y el mantenimiento de un alto nivel de concurrencia.

Teoría de la seriabilidad.

Un programa se define sobre un conjunto de transacciones T = {T1, T2,..., Tn } y

especifica un orden entrelazado de la ejecución de las operaciones de las transacciones.

El programa puede ser especificado como un orden parcial sobre T.

Ejemplo de Teoría de la seriabilidad: Considere las siguientes tres transacciones:

T1: Read( x ) T2: Write( x ) T3: Read( x )

Write( x ) Write( y ) Read( y )

Commit Read( z ) Read( z )

Commit Commit

Un programa con las acciones de las tres transacciones anteriores puede ser:

H1 = {W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }

Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que acceden al

mismo dato de la BD x se dice que están en conflicto si al menos una de ellas es de

escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo

mismas.

Existen dos tipos de conflictos:

• de lectura-escritura (o escritura-lectura)

• de escritura-escritura.

Por tanto el orden de ejecución entre dos operaciones en conflicto es importante.

Un programa completo define el orden de ejecución de todas las operaciones en su

dominio.

Si en un programa S, las operaciones de varias transacciones no están entrelazadas,

entonces se dice que el programa es serial. Si cada transacción es consistente (obedece

las reglas de integridad), entonces se garantiza que la BD será consistente al final del

programa serial. La historia asociada a este tipo de programa se le conoce como serial.

2.7 CONTROL DE RECUPERACIÓN EN UNA BDD

Como ocurre con el control de concurrencia, en el control de recuperación surgen

numerosos problemas que no surgen en SGBD centralizados.

• Manejar múltiples copias de los elementos de información: el método de recuperación debe cuidar que una copia sea consistente con todas las demás si el sitio en el que la copia estaba almacenada falla y se recupera posteriormente.

• Fallo de sitios individuales: El SGBD debe continuar operando con sus sitios activos, si es posible, cuando fallen uno o más sitios individuales. Cuando un sitio se recupere, su BD local se deberá poner al día con los demás sitios antes de que se reincorpore al sistema.

• Fallo de enlaces de comunicaciones: El sistema debe ser capaz manejar el fallo de uno o más de los enlaces de comunicaciones entre los sitios. Un caso extremo de este problema es que puede haber partición de la red. Esto divide los sitios en dos o más particiones dentro de las cuales los sitios pueden comunicarse entre sí, pero no con sitios de otras particiones.

• Confirmación distribuida: Puede haber problemas para confirmar una transacción que está teniendo acceso a BD almacenadas en múltiples sitios si alguno de estos fallan durante el proceso de confirmación. A menudo se utiliza el protocolo de confirmación en dos fases (two phase commit) para resolver este problema.

CASO DE ESTUDIOS

CASO #1 BMW

DESCRIPCIÓN DEL CASO

Base de datos distribuida de una la empresa  BMW de en la en el estado de san Luis potosí , se cuenta con 4 fábricas ensambladoras establecidas en el país el resto está ubicado en Guadalajara, nuevo león y CDMX ,pero los servidores se encuentra en México y Nuevo león , el planteamiento es de que hay error a la hora de hacer intercambio de datos de inventario para la manufactura de los automóviles de un lugar a otro para esto aquí se usa el modelo de relación de fragmentación horizontal y vertical , esos datos están fragmentado en cada ciudad, esto ocasiona el inconforme de los ingenieros a la hora de hacer el pedido de piezas a otras fábricas.

CLASIFICACIÓN DEL SGBDD

Sistema multa base homogéneo y distribuido.

Se trabaja con esta categoría porque se trata de una sola red de computadores conectadas a un subsistema de datos que permite trabajar únicamente con los datos que se tienen almacenados. En este caso la BMW se dedica a la fabricación de automóviles, lo que requiere de piezas, esta información la trabajan únicamente ellos en distintas fabricas esto quiere decir que sus bases de datos son homogéneas.

DESCRIPCIÓN DE L SOLUCIÓN

Aquí la mejor opción será que los datos de piezas en donde se almacenan, sean más rápidos a la hora de solicitar piezas, de un estado a otro, muy probablemente hacer un mantenimiento al clúster, tendrá buenas reacciones entre los usuarios o cambiar de ubicación los servidores de la ciudad en la que están ubicados e instalados

En el desarrollo de la aplicación se necesitaron tomar las soluciones siguientes:

·    Base de datos a utilizar en el sistema, con la que debería comunicarse la aplicación servidor

·    Lenguaje de programación a utilizar tanto en la aplicación cliente como la aplicación servidor

·        Modo de comunicación entre los clientes y el servidor.

CLASIFICACIÓN SISTEMA GESTOR DE BASE DE DATOS DISTRIBUIDA

En este ejemplo se trabajó en PostgreSQL.

La última serie de producción es la 9.1. Sus características técnicas la hacen una de las bases de datos más potentes y robustas del mercado. Su desarrollo comenzó hace más de 16 años, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez al sistema.

GENERALES

·        Es una base de datos 100% ACID.

·    Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP), cadenas de bits, etc. También permite la creación de tipos propios.

·      Incluye herencia entre tablas, por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.

·        Copias de seguridad en caliente (Online/hot backups)

·        Unicode

·        Juegos de caracteres internacionales

·        Regionalización por columna

·        Multi-Version Concurrency Control (MVCC)

·        Múltiples métodos de autentificación

·        Acceso encriptado vía SSL

·        SE-postgres

·        Documentación

·        Licencia BSD

·        Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS  X, Solaris, Tru64) y Windows 32/64bit.

DESCRIBIR DE MANERA GENERAL COMO REALIZARÍA LA IMPLEMENTACIÓN EN FUNCIÓN A GBDS, PLATAFORMAS OPERATIVAS Y HERRAMIENTAS UTILIZAR.

Lo correcto sería detectar los problemas en todo caso volver a hacer nuevos datos para nuevas piezas de para actualizar información, al momento para saber que piezas hay disponibles y cuales son obsoletas, en esto es conveniente tener una computadora con Ubuntu y el SGBDD PostgreSQL, para facilitar el manejo de la información, para que los datos sean más rápidos a la hora solicitar el pedido de una pieza para un automóvil.

Existiría la posibilidad de trabajar también en MYSQL SERVER, pero, la ventaja con la que cuenta PostgreSQL es que es más fácil de manipular además de código libre y es gratuito.

Elaborado por: Germán De Jesús Díaz Villeda

CASO #2 ELEKTRA

DESCRIPCIÓN DEL CASO

La empresa Elektra busca tener un registro de las ventas y la entrada del producto, divisiones y departamentos. Por lo cual busca una estrategia para poder enlazar todos los registros en una base de datos que esté conectada a la otra tienda de electrodomésticos.

Las distintas tiendas se encuentran en las siguientes direcciones:

Tienda de electrodomésticos-Miguel Hidalgo 222.

Elektra Ciudad Valles Lomas Yuejat.
     

CLASIFICACIÓN DEL SGBDD

SGBD federado homogéneo y distribuido

SGBD es federado homogéneo porque no depende de otro y distribuido porque existe una cooperación entre los SGBD implicados en la ejecución de las solicitudes de usuarios a los datos de la BDD.

El sistema gestor de base de datos a utilizar será PostgreSQL por la facilidad para hacer replicaciones la cual será muy útil para la base de datos que se realizara en el siguiente proyecto ya que es muy completa para este trabajo.

DESCRIPCIÓN DE LA SOLUCIÓN

Desarrollar una base de datos distribuida con todos los datos de todos los departamentos, lo que se pretende es que la estructura de la base de datos refleje lo que es la empresa mediante una base de datos virtual compuesta de varias bases de datos distintas que se encuentran en lugares distintos que cuente con un acceso organizado a los datos esto se llevara a cabo mediante una replicación lo cual consiste en que cada nodo debe de tener una copia completa de la base de datos lo cual lleva un alto costo de información y de escritura pero es la mejor opción de acuerdo a la disponibilidad y fiabilidad de los datos ya que estos son de gran importancia para la empresa. 

Elaborado por: Ernesto Hernández Mar

CASO #3 FOLY MUEBLES

DESCRIPCIÓN DEL CASO

La empresa foly muebles cuenta con dos sucursales que se ubican en:

·         Galeana 48, Zona Centro, 87090 Cd Valles, S.L.P.
·         Boulevard México - Laredo, Las Lomas Oriente, 79099 Cd Valles, S.L.P.

Esta empresa tiene dificultades ya que no llevan un control y una administración adecuada en tiempo real de clientes que compran en línea y compran mercancía a crédito entre las dos sucursales.

A con respecto a esto, la empresa sufre de pérdidas de dinero y busca tener un buen rendimiento.

CLASIFICACIÓN DEL SGBDD

SGBD federado homogéneo y distribuido

SGBD es federado homogéneo y distribuido porque existe una cooperación entre los SGBD implicados en la ejecución de las solicitudes de usuarios a los datos de la BDD.

DESCRIPCIÓN DE LA SOLUCIÓN

Se desarrollará una base de datos donde se lleve el control y el registro de todos los movimientos que se realiza en la tienda en línea y los créditos otorgados hacia los clientes en cada una de las sucursales.

Para realizar esta base de datos se tendrá que utilizar mysql ya que es un sistema de base de datos almacenado en varios servidores y que es vista por el cliente como una sola, esto con el objetivo de mantener redundancia y balanceo de los datos para lograrlo se utilizara la replicación copia ya que mantiene la información de las bases de datos en las múltiples bases de datos que levantan un sistema distribuido. La replicación puede mejorar el funcionamiento y proteger la disponibilidad de las aplicaciones, por que alterna opciones de acceso de los datos existentes.

Se tendrá que registrar cada servicio que ofrece la empresa mediante la replicación de toda la información, el cual solamente la sucursal que se encuentra ubicada en Galeana 48, Zona Centro, tendrá una replicación y la sucursal ubicada en Boulevard México - Laredo, Las Lomas Oriente tendrá un fragmento de la información de la base de datos.

Elaborado por: Rubén Darío Muñoz Hernández

CASO #4 FARMACIA SIMILARES

DESCRIPCIÓN DEL CASO

Farmacias Similares, perteneciente al Grupo Por un País Mejor, es la empresa líder en venta y distribución de Medicamentos Genéricos y Productos de Salud en México y América Latina, con más de 1000 sucursales en todo México. En Ciudad valles, S.L.P. cuenta con 3 sucursales presentes en las cuales se implementará un sistema gestor de bases distribuidas.

CLASIFICACIÓN DEL SGBDD

Se encuentra que es un sistema gestor federado homogéneo y distribuido, ya que cuenta con el mismo sistema y con ciertas sucursales en la ciudad, no hay autonomía completa.

DESCRIPCIÓN DE L SOLUCIÓN   

Se propone implementar un SGBDD para unir todas las sucursales en un mismo sistema para así tener todos los productos ligados y el registro de cada uno en el inventario.

Elaborado por: Stephanie Paola Oyarvide Salas

CASO #5 COPPEL

DESCRIPCIÓN DEL CASO

La tienda departamental de Coppel ofrece servicios a los clientes que asisten a ella, que son los siguientes:

·         Crédito Coppel

·         Entrega a domicilio gratis

·         2 años de garantía gratis

·         Compras a través de Coppel.com

·         Compras telefónicas llamando al 01-800-220-7735

·         Pago de servicios (CFE, Telmex, Movistar y Crédito y Casa)

·         Préstamos en efectivo (solo si el cliente va al corriente con su crédito)

·         Envíos de dinero con DineroYa y MoneyGram (Nacional y a Estados Unidos)

·         BanCoppel.com

·         Servicios de telefonía celular (recargas)

·         Sorteos y Concursos

Los locales tienen problemas en cuanto las ventas, préstamos y los distintos tipos de servicio con los que cuenta la empresa, por motivos de pagos atrasados entre otros casos. Por estos motivos la empresa está perdiendo recursos monetarios porque no lleva el control de los clientes que están en deuda con la empresa.

La empresa busca llevar un mejor control y administración de todos los locales existentes en Cd. Valles, las cuales se encuentran en:

1.  Zona Centro, 79000 Cd Valles, S.L.P. 
2. Miguel Hidalgo 225, Zona Centro, 79000 Cd Valles, S.L.P. 
3. Ciudad Valles Centro, Venustiano Carranza 314, Zona Centro, 79000 Cd Valles, San Luis Potosí.
4. Blvd. México - Laredo 2200, Lomas del Yuejat, 79082 Cd Valles, S.L.P

CLASIFICACIÓN DEL SGBDD

SGBD federado homogéneo y distribuido

SGBD es federado homogéneo y distribuido porque existe una cooperación entre los SGBD implicados en la ejecución de las solicitudes de usuarios a los datos de la BDD.

El sistema gestor de base de datos a utilizar será PostgreSQL por la facilidad para hacer particiones la cual será muy útil para la base de datos a realizar ya que es muy completa para este trabajo.

DESCRIPCIÓN DE L SOLUCIÓN

Desarrollar una base de datos distribuida para llevar el control de la administración y la gestión de los servicios hacia los clientes que cuentan con créditos para la obtención de productos.

Se tendrá que realizar una base de datos distribuido en cada una de las sucursales que existe en Cd. Valles donde se tendrá que registrar cada servicio ofrecido por la empresa mediante una partición de toda la información las cuales solo la sucursal Miguel Hidalgo 225, Zona Centro, tendrá una replicación de las demás y las más pequeñas tendrán un fragmento de la información disjuntos de la base de datos.

Sucursales que tendrán fragmentos de información disjuntos de la BD

1.    Ciudad Valles Centro, Venustiano Carranza 314, Zona Centro, 79000 Cd Valles, San Luis Potosí.

2.    Zona Centro, 79000 Cd Valles, S.L.P.

Sucursales que contaran con la partición de toda la información

3.    Miguel Hidalgo 225, Zona Centro, 79000 Cd Valles, S.L.P.

4.    Blvd. México - Laredo 2200, Lomas del Yuejat, 79082 Cd Valles, S.L.P.

Elaborado por: Hilda González Altamirano

CASO #6 BANCO AZTECA

DESCRIPCIÓN DEL CASO:

Es un banco mexicano fundado en el año 2002 y es una compañía del Grupo Salinas. Cuenta con más de 4,000 sucursales en México, Panamá, Guatemala, Honduras, El Salvador y Perú. Es el quinto banco entre las instituciones financieras nacidas en México y 11° en un sistema de 48 instituciones de banca múltiple.

Ø  Ofrece servicios financieros
Ø  Otorga créditos al consumo de bienes (Credimax)
Ø  Ofrece tarjetas de crédito (Tarjeta Azteca)
Ø  Préstamos personales.

Actualmente en ciudad valles, S.L.P cuenta con 3 sucursales que se ubican en:

·       Carretera Mexico-Laredo Sur s/n, Lomas del Yuejat, 79082 
·        Hidalgo 222 79000
·        Abasolo 79000

Las 2 primeras operan desde las tiendas Grupo Elektra y la tercera opera fuera de estas tiendas y en el cual se necesita implementar una base de datos distribuida. 

CLASIFICACIÓN DEL SGBDD:

Es un SGBDD federado homogéneo y distribuido.

Es federado porque no tiene suficiente autonomía, homogéneo porque no depende de otra sucursal que este  fueras de la ciudad.

DESCRIBIR LA PROPUESTA DE SOLUCIÓN:

Desarrollar una base de datos distribuidas para tener un mejor control de todas las cuentas de los clientes en cada una de las sucursales y así sea más fácil realizar movimientos como depositar, retirar, hacer pagos y no haya ningún problema con ello.

Elaborado por: Reyna Olivia Hernández Loredo