miércoles, 12 de septiembre de 2018

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.

martes, 11 de septiembre de 2018

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.


jueves, 6 de septiembre de 2018

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éxicoPanamáGuatemalaHondurasEl 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