• Author / Uploaded
• Ruber Martin

Citation preview

UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica

OPTIMIZACIÓN DE LAS HERRAMIENTAS DE ANÁLISIS DE LA RED CELULAR DE DIGITEL GSM

Por Hansell E. Barán Altuve

Sartenejas, Noviembre 2006

UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica

OPTIMIZACIÓN DE LAS HERRAMIENTAS DE ANÁLISIS DE LA RED CELULAR DE DIGITEL GSM

Por Hansell E. Barán Altuve Realizado con la Asesoría de: Ing. Fidel Gil (Tutor Académico) Ing. Juan Gallardo (Tutor Industrial)

Informe Final de Cursos en Cooperación Técnica y Desarrollo Social Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Noviembre 2006

UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica

OPTIMIZACIÓN DE LAS HERRAMIENTAS DE ANÁLISIS DE LA RED CELULAR DE DIGITEL GSM Informe Final de Cursos en Cooperación Técnica y Desarrollo Social presentado por Hansell E. Barán Altuve

REALIZADO CON LA ASESORIA DE: Ing. Fidel Gil (Tutor Académico) Ing. Juan Gallardo (Tutor Industrial) RESUMEN El proyecto de grado que se presenta en este libro consta de dos partes fundamentales. La primera de ellas consistió en optimizar y disminuir el tiempo de consulta y procesamiento de dos herramientas de análisis usadas por la Coordinación de Optimización de Digitel GSM. Dicha optimización se realizó a través de: la migración de las bases de datos a un nuevo sistema administrador (PostgreSQL) como resultado de un estudio comparativo entre Microsoft Access, MySQL y PostgreSQL, la modificación de las bases de datos y de las herramientas usadas. Al finalizar el proyecto se logró disminuir el tiempo de procesamiento y consulta, en algunos casos en más del 90%. La segunda parte del proyecto de grado consistió en desarrollar una herramienta capaz de calcular las adyacencias de una estación base. La herramienta, desarrollada en Visual Basic, hace uso de modelos de propagación, ecuaciones matemáticas y fundamentos de geometría para automatizar, sustituir y agilizar el procedimiento manual y engorroso utilizado por el personal de la Coordinación de Optimización. Dicha herramienta permite generar documentos de reportes, denominados “Datafill”, y administrar (agregar, modificar o eliminar) las estaciones base, Nokia, de la red celular de Digitel GSM. PALABRAS CLAVES Comparación entre administradores de bases de datos, MySQL, PostgreSQL, Microsoft Access, Cálculo automático de adyacencias de una estación base. Aprobado con mención:_______ Postulado para el premio:_______ Sartenejas, Noviembre 2006

A mi papá, Estefan, quien con sus enseñanzas, ayuda y apoyo, hoy en día no sería una exitosa persona y estudiante, y no hubiese podido realizar y terminar este libro. A mi mamá, Maria Luisa, quien con sus palabras alentadoras e innumerables consejos me han motivado a seguir adelante y a seguir mis sueños. A mi hermana, Heidell, quien me enseñó que el éxito y que todas nuestras metas las podemos alcanzar con esfuerzo, dedicación y perseverancia.

ÍNDICE GENERAL Índice General ………………………………………………………………………i Índice de Figuras ………………………………………………………………………iv Índice de Tablas ………………………………………………………………………vi Símbolos y abreviaturas ………………………………………………………………vii 1. INTRODUCCIÓN ………………………………………………………………1 2. DESCRIPCIÓN Y ANTECEDENTES DEL PROBLEMA ………………………5 2.1 Descripción de la Empresa ………………………………………………………5 2.1.1 Misión de la Empresa ………………………………………………………6 2.1.2 Visión de la Empresa ………………………………………………………6 2.1.3 Valores de la Empresa ………………………………………………………6 2.1.4 Organigrama de la Empresa ………………………………………………7 2.2 Planteamiento del Problema ………………………………………………………8 2.3 Alcance y limitaciones del proyecto ………………………………………………9 3. OBJETIVOS ………………………………………………………………………11 3.1 Objetivo general ………………………………………………………………11 3.2 Objetivos específicos ………………………………………………………………11 4. FUNDAMENTOS TEÓRICOS ………………………………………………………12 4.1 Introducción ………………………………………………………………………12 4.2 Principios básicos de GSM ………………………………………………………12 4.2.1 Evolución de GSM ………………………………………………………12 4.2.2 Arquitectura de una red celular GSM ………………………………………14 4.2.2.1 Subsistema de estación base ………………………………………15 4.2.2.2 Subsistema de conmutación de la red ………………………………16 4.2.2.3 Subsistema de administración de la red ………………………19 4.2.3 Interfaz de Aire ………………………………………………………………20 4.2.3.1 Canales físicos y lógicos ………………………………………………21 4.2.3.2 Handover ………………………………………………………………25 4.2.4 Planificación y optimización de una red GSM ………………………………25 4.2.4.1 Planificación de los recursos de radiofrecuencia ………………………27 4.2.4.2 Modelos de propagación para la planificación de una red celular ………29 4.3 Fundamentos de las bases de datos y sistemas de bases de datos ………………33 4.3.1 Historia de las bases de datos ………………………………………………33 4.3.2 Modelo relacional de bases de datos ………………………………………35 4.3.3 Sistemas administradores de bases de datos ………………………………37 4.3.4 Estructura de un administrador de bases de datos ………………………38 4.3.4.1 El administrador de almacenamiento (Storage Manager) ………………39 4.3.4.2 El procesador de consultas (Query Manager) ………………………40 4.3.4.3 El administrador de transacciones (Transaction Manager) ………………41 4.3.5 Álgebra relacional y sus operaciones ………………………………………42 4.3.6 Lenguaje estructurado de consultas (SQL) ………………………………43 4.3.6.1 Cursores ………………………………………………………………45 4.3.6.2 Transacciones ………………………………………………………45 4.3.7 Desempeño de un sistema administrador de bases de datos ………………46

ii

5.

6.

7.

8.

4.3.7.1 Índices ………………………………………………………………47 4.4 Visual Basic y el acceso a bases de datos ………………………………………48 4.4.1 Interfaz ODBC ………………………………………………………………50 4.4.1.1 Arquitectura ODBC ………………………………………………51 4.4.2 Métodos de acceso a orígenes de datos ………………………………………52 METODOLOGÍA ………………………………………………………………54 5.1 Investigación preliminar ………………………………………………………54 5.2 Análisis preliminar de las herramientas y bases de datos ………………………54 5.3 Migración inicial de las bases de datos ………………………………………55 5.4 Desarrollo inicial del programa de pruebas ………………………………………55 5.5 Ejecución de las pruebas preliminares a los administradores de bases de datos ………………………………………………………………56 5.6 Análisis de las pruebas preliminares a los administradores de bases de datos ………………………………………………………………56 5.7 Investigación detallada acerca de los administradores de bases de datos, sistemas operativos, conexiones de red, controladores o drivers y lenguaje de programación ………………………………………………………56 5.8 Ejecución de las pruebas finales a los administradores de bases de datos ………57 5.9 Análisis de las pruebas finales a los administradores de bases de datos ………57 5.10 Modificaciones a las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización ………………………………………………57 5.11 Pruebas finales a las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización ………………………………………………58 5.12 Investigación detallada acerca del procedimiento para el cálculo de las adyacencias de una BTS ………………………………………………………58 5.13 Desarrollo de la herramienta para el cálculo automático de las adyacencias de una BTS ………………………………………………………………………58 5.14 Ejecución de las pruebas a la herramienta para el cálculo automático de las adyacencias de una BTS ………………………………………………………59 ESTUDIO COMPARATIVO ENTRE TRES ADMINISTRADORES DE BASES DE DATOS ………………………………………………………………60 6.1 Condiciones previas ………………………………………………………………61 6.2 Migración de las bases de datos necesarias para el programa de pruebas ………64 6.2.1 Problemas antes de migrar las bases de datos ………………………………65 6.3 Desarrollo del programa de pruebas ………………………………………………67 6.4 Condiciones de los administradores de bases de datos ………………………74 6.5 Pruebas preliminares ………………………………………………………………75 6.6 Modificaciones a los parámetros de configuración y pruebas finales ………81 6.6.1 Cambios realizados a los parámetros de configuración ………………………81 6.6.2 Pruebas finales ………………………………………………………………87 HERRAMIENTA PARA AUTOMATIZAR EL CÁLCULO DE LAS ADYACENCIAS DE UNA ESTACIÓN BASE ………………………………………92 7.1 Procedimiento para el cálculo de las adyacencias ………………………………92 7.2 Interfaz gráfica de la herramienta ………………………………………………97 7.3 Pruebas realizadas ………………………………………………………………107 RESULTADOS Y ANÁLISIS ………………………………………………………108

iii

8.1 Estudio comparativo entre tres administradores de bases de datos ………………110 8.1.1 Resultados de las pruebas preliminares ………………………………………110 8.1.2 Resultados de las pruebas finales ………………………………………131 8.2 Herramienta para el cálculo de adyacencias ………………………………………147 8.2.1 Resultados obtenidos ………………………………………………………147 9. CONCLUSIONES Y RECOMENDACIONES ………………………………………156 Referencias Bibliográficas ………………………………………………………………159

iv

ÍNDICE DE FIGURAS Figura 1. Organigrama del Departamento de Operaciones de Digitel GSM ………………8 Figura 2. Arquitectura de una red celular GSM ………………………………………15 Figura 3. Diferencias entre HLR y VLR ………………………………………………18 Figura 4. Relación entre MSC y VLR ………………………………………………18 Figura 5. Interfaz de aire en GSM ………………………………………………………21 Figura 6. Time slots y tramas TDMA en GSM ………………………………………22 Figura 7. Canales lógicos de la interfaz de aire de GSM ………………………………24 Figura 8. Diferentes configuraciones de BTS ………………………………………28 Figura 9. Patrón de reuso en una red GSM con 9 frecuencias disponibles ………………29 Figura 10. Modelos de propagación y su rango válido de frecuencias ………………30 Figura 11. Representación gráfica del modelo de propagación empírico Okumura-Hata ………………………………………………………31 Figura 12. Relación o tabla de una base de datos relacional ………………………………36 Figura 13. Relación entre un DBMS y varias bases de datos ………………………37 Figura 14. Estructura general de un sistema administrador de bases de datos ………38 Figura 15. Arquitectura cliente/servidor en la comunicación con una base de datos ………………………………………………………………49 Figura 16. Arquitectura de ODBC ………………………………………………………51 Figura 17. Arquitectura MDAC ………………………………………………………53 Figura 18. Interfaz gráfica del programa de pruebas desarrollado con Visual Basic 6 para la comparación de los tres DBMS ………………………68 Figura 19. Interfaz gráfica de la herramienta desarrollada para el cálculo de adyacencias ………………………………………………………98 Figura 20. Interfaz de la herramienta luego de calcular las adyacencias para el sector 23ENERO1 ………………………………………………………104 Figura 21. Interfaz para la administración de BTS de la herramienta desarrollada ………105 Figura 22. Administrador de tareas de Windows mostrando el uso de CPU y memoria de un computador ………………………………………………109 Figura 23. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con Microsoft Access / Windows ………………………112 Figura 24. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con MySQL / Linux ………………………………112 Figura 25. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con PostgreSQL / Linux ………………………………112 Figura 26. Actividad de CPU y memoria al realizar la prueba preliminar 1 con Microsoft Access / Windows ………………………………………………114 Figura 27. Actividad de CPU y memoria al realizar la prueba preliminar 1 con MySQL / Linux ………………………………………………………115 Figura 28. Actividad de CPU y memoria al realizar la prueba preliminar 1 con PostgreSQL / Linux ………………………………………………………115 Figura 29. Gráficas del uso de CPU, del computador cliente, al ejecutar la prueba preliminar 2 con Microsoft Access / Windows ………………………118 Figura 30. Gráfica del uso de CPU, del computador servidor, al ejecutar la prueba preliminar 2 con MySQL / Windows ………………………………119

v

Figura 31. Gráfica del uso de CPU, del computador servidor, al ejecutar la prueba preliminar 2 con PostgreSQL / Windows ………………………119 Figura 32. Uso del CPU y actividad de la red al realizar la prueba preliminar 3 con Microsoft Access / Windows …………………………………………122-123 Figura 33. Uso del CPU y actividad de la red al realizar la prueba preliminar 3 con MySQL / Windows ………………………………………………………123 Figura 34. Uso del CPU y actividad de le red al realizar la prueba preliminar 3 con PostgreSQL / Windows ………………………………………………124 Figura 35. Uso del CPU (a) y actividad de la red (b) del computador cliente al realizar la prueba preliminar 4 con Microsoft Access / Windows ………………………127 Figura 36. Actividad de la red del computador cliente al ejecutar varias de las consultas de la tabla 11 ………………………………………………………143

vi

ÍNDICE DE TABLAS Tabla 1. Los sistemas administradores de bases de datos en diferentes computadores ………………………………………………………74 Tabla 2. Resultados de la prueba preliminar 1 ………………………………………111 Tabla 3. Resultados de la prueba preliminar 2 ………………………………………117 Tabla 4. Resultados de la prueba preliminar 3 ………………………………………122 Tabla 5. Resultados de la prueba preliminar 4 ………………………………………126 Tabla 6. Resultados de la prueba preliminar 5 ………………………………………129 Tabla 7. Resultados de la prueba final 1 ………………………………………………132 Tabla 8. Resultados de la prueba final 3 ………………………………………………136 Tabla 9. Resultados de la prueba final 4 ………………………………………………137 Tabla 10. Resultados de la prueba final 5 ………………………………………………140 Tabla 11. Resultados de la prueba preliminar 6 (Linux) ………………………………142 Tabla 12. Resultados de la prueba preliminar 6 (Windows) ………………………………142 Tabla 13. Resultados obtenidos al realizar la consulta 1 de la herramienta Parameter ………………………………………………………145 Tabla 14. Resultados obtenidos al realizar la consulta 2 de la herramienta Parameter ………………………………………………………145 Tabla 15. Adyacencias para el sector 23ENERO1 ………………………………………148 Tabla 16. Adyacencias para el sector AVSUCRE1 ………………………………………149 Tabla 17. Adyacencias para el sector MADERERO3 ………………………………150 Tabla 18. Adyacencias para el sector USBUNO1 ………………………………………151 Tabla 19. Adyacencias para el sector CUMBETRE2 ………………………………151 Tabla 20. Características de Microsoft Access, MySQL y PostgreSQL ………………153 Tabla 21. Costos de implementación de los tres DBMS estudiados ………………………145

vii

GLOSARIO, SÍMBOLOS Y ABREVIATURAS AuC: Authentication Center. Centro de autenticación. BCC: Base Transceiver Station Color Code. Código de color de una estación base que forma parte del código de identificación de una estación base. BSC: Base Station Controller. Controlador de base estación BSIC: Base Transceiver Station Identity Code. Código de identificación de una estación base. BSS: Base Station Subsystem. Subsistema de base estación. BTS: Base Transceiver Station. Estación Base. CPU: Central Processing Unit. Unidad Central de Procesamiento. Procesador DBMS: DataBase Management System. Sistema Administrador de Base de Datos. Drive Test: Prueba de campo que se realiza utilizando equipos especiales para monitorear en tiempo real las condiciones de una red celular. Esta prueba consiste en conducir un vehículo por sectores de la ciudad donde la red celular tiene cobertura y monitorear parámetros como potencia de recepción, calidad de la voz, señales y niveles de interferencia, facilidad y efectividad de HandOvers, etc. GSM: Global System for Mobile Communications. Uno de los estándares de comunicación celular usado a nivel mundial. HandOver: Proceso mediante el cual se transfiere la comunicación o el enlace entre una estación base y una estación móvil a otra estación base con la misma estación móvil mientras ésta hace uso de algún servicio de la red celular. KPI: Key Performance Indicator. Indicador Clave de Desempeño. Mainframe: Computador central con mayores capacidades de procesamiento, memoria y almacenamiento que un minicomputador y que es usado para procesar grandes cantidades de datos. Microcomputador: Computador que posee un Microprocesador. Generalmente se conoce como computador u ordenador personal (PC; Personal Computer). Minicomputador: Actualmente son conocidos como servidores, tiene mayor capacidad de procesamiento que los microcomputadores MS: Mobile Station. Estación Móvil. MTU: Maximum Transfer Unit o Maximum Transmission Unit. Unidad máxima de transferencia. NCC: Network Color Code. Código de color de la red ODBC: Open DataBase Connectivity. Estándar que permite a cualquier aplicación acceder a la información almacenada bajo cualquier administrador de bases de datos. OS: Operating System. Sistema Operativo. PC: Personal Computer. Computador personal QoS: Quality of Service. Calidad de Servicio. RAM: Random Access Memory. Memoria de acceso aleatorio. SIM: Subscriber Identity Module. Módulo de Identidad del Subscriptor.

1. INTRODUCCIÓN En general, cualquier empresa o compañía que desee medir su desempeño o que desee cuantificar el cumplimiento de sus metas planteadas, debe disponer de Indicadores Claves de Desempeño (KPI; Key Performance Indicator). Estos indicadores deben ser capaces de medir cuantitativamente las metas fijadas en la empresa. Toda empresa que se encarga de diseñar, planificar, administrar y desarrollar una red celular debe poseer indicadores capaces de medir cuantitativamente el desempeño de la red. Muchos de los KPI usados en una red celular, entre los cuales se pueden mencionar el área de cobertura, cantidad o porcentaje de llamadas caídas o bloqueadas, cantidad o porcentaje de HandOvers fallidos, calidad de la voz, etc., están relacionados a la calidad de servicio (QoS; Quality of Service) que brinda el proveedor del servicio celular a sus clientes. La calidad de servicio que percibe el usuario, por lo tanto, está relacionada directamente con la calidad y el desempeño de la red celular. Para mejorar el desempeño de una red celular, ésta debe ser sometida a modificaciones o cambios que afecten el comportamiento de los KPI, por lo tanto, estas modificaciones deben estar fundamentadas en los resultados obtenidos luego de analizar la información obtenida de los indicadores de desempeño. El desempeño normal o desempeño promedio de una red celular no se puede medir en instante de tiempo determinado debido a que existen muchos factores que la pueden afectar, como por ejemplo, el personal de mantenimiento se encuentra cambiando los transmisores de una zona y por lo tanto los usuarios no pueden hacer uso de la red en ese sector, hubo una baja de energía y se destruyeron equipos de transmisión, hay una concurrencia anormal de usuarios en un determinado sector de la red celular y no es posible dar servicio a la totalidad de los usuarios en esa zona, etc. Generalmente, se desea analizar el desempeño promedio de una red celular debido a que este comportamiento es el que manifestará la red celular la mayor parte del tiempo en que se encuentre operativa. Es por esta razón que el análisis de los KPI se debe realizar cuando se dispone de un acumulado histórico de los mismos, es decir, se dispone de información obtenida o de KPI acumulados durante varios días, semanas, meses o años. Disponer de una base de datos donde se acumule esta información facilita la tarea de analizar el desempeño de una red celular. Para

2

lograr un análisis eficaz, sin embargo, es necesario contar con herramientas que permitan al especialista en optimización de la red, ver rápidamente cualquier información acerca de cualquier estación base (BTS; Base Transceiver Station) y durante cualquier período de tiempo. La Coordinación de Optimización de la empresa Digitel de Venezuela ha desarrollado herramientas de análisis y monitoreo de la red celular. Estas herramientas hacen uso de bases de datos que acumulan información de todas las estaciones base Nokia de la red celular de Digitel. En estas bases de datos se encuentran los KPI usados por Digitel para analizar, optimizar o mejorar el desempeño de la red celular. Las bases de datos diseñadas por el personal de la Coordinación de Optimización contienen información desde el año 2005 y han estado creciendo constantemente. Hoy en día algunas de las bases de datos contienen tablas con más de 500.000 filas y 50 columnas de información. Como consecuencia de este crecimiento en el tamaño de las bases de datos, se crea la necesidad de procesar mayor cantidad de información y de hacerlo en el menor tiempo posible. Esta exigencia se impone tanto en el sistema administrador de bases de datos (DBMS; DataBase Management System) como en las herramientas de análisis de la Coordinación de Optimización de Digitel. Reducir los tiempos de procesamiento es un objetivo fundamental para la Coordinación de Optimización ya que esto permite al personal tener una mayor velocidad de respuesta y lograr una utilización más eficiente del tiempo invertido en el análisis del desempeño de la red. Por esto, es importante optimizar el desempeño tanto del DBMS como de las herramientas de análisis, para que la información sea procesada en el menor tiempo posible. Sumado a la necesidad de optimizar las herramientas de análisis, la Coordinación de Optimización tiene la necesidad de automatizar tareas manuales, en particular la de calcular adyacencias de una estación base, para que el personal pueda dedicar mayor parte del tiempo al análisis y resolución de problemas de la red celular. La tarea de generar, seleccionar y calcular las estaciones base que son adyacentes a un punto geográfico determinado, juega un papel importante en el proceso de planificación y optimización de la red. Al crear una nueva BTS, es necesario identificar cuáles son las adyacencias de ésta ya que es una información necesaria para operaciones fundamentales e

3

importantes como los son los procesos de handover en la red celular. El proceso para calcular las adyacencias consta de dos partes fundamentales. La primera de ellas que se hace manualmente y consume gran cantidad del tiempo del personal, consiste en seleccionar las posibles BTS adyacentes de un mapa geográfico. Esta selección manual consume mucho tiempo ya que se deben considerar canales de transmisión, orientación de las antenas, reuso de frecuencia, etc. La segunda etapa en la selección de las BTS adyacentes es la de realizar una prueba de campo o drive test, en donde se seleccionan las BTS adyacentes definitivas, basándose en los niveles de potencia recibidos provenientes de las señales de otras BTSs. El objetivo de desarrollar una herramienta capaz de automatizar el proceso de selección de adyacencias es acelerar y mejorar la primera etapa del mismo. Para el desarrollo de esta herramienta, fue necesario el uso de modelos de propagación para redes celulares y ecuaciones matemáticas para calcular interferencia entre todas las BTS Nokia de la red celular de Digitel y la BTS a la cual se quiere calcular las adyacencias. La herramienta es capaz de calcular las BTS adyacentes a un punto geográfico determinado basándose en la distancia geográfica, canal de transmisión e interferencia o solapamiento de áreas de cobertura de las BTS de la red celular. La herramienta desarrollada logró automatizar al mismo tiempo que reducir el tiempo de desarrollo de la primera etapa de selección de las adyacencias de una BTS. En este proyecto de grado se logró realizar la optimización a las herramientas de análisis, ya que se logró reducir en más del 50% el tiempo de respuesta y procesamiento de las bases de datos usadas por las herramientas de análisis de la Coordinación de Optimización. A lo largo de este libro se exponen los procedimientos que se siguieron para lograr la optimización de las herramientas y tareas de la Coordinación de Optimización. En el capítulo 2 se presenta la descripción de la empresa y el planteamiento del problema. Los objetivos del proyecto de grado se exponen en el capítulo 3. Toda la información y fundamentos teóricos necesarios para comprender el desarrollo y ejecución del proyecto se encuentran en el capítulo 4. En el capítulo 5 se expone la metodología que se utilizó a lo largo del desarrollo del proyecto para lograr los objetivos planteados. En el capítulo 6 se presenta un estudio comparativo entre tres administradores de bases de datos como requisito indispensable para lograr los objetivos del proyecto. Aquí se explican todas las pruebas realizadas para comparar los administradores. El capítulo 7 muestra todo lo relacionado al desarrollo de la herramienta

4

utilizada para calcular automáticamente las adyacencias de una BTS. Todos los resultados obtenidos, tanto del estudio comparativo como del desarrollo de la herramienta de cálculo de adyacencias, se presentan en el capítulo 8 acompañados con su análisis y discusión. Por último, en el capítulo 9, se presentan las conclusiones y recomendaciones a las que se llegaron luego de analizar los resultados del proyecto.

2. DESCRIPCIÓN Y ANTECEDENTES DEL PROBLEMA 2.1

Descripción de la Empresa Digitel GSM es la única empresa de telecomunicaciones en Venezuela que ofrece

servicios de telefonía inalámbrica básica, pública y móvil basados en la tecnología GSM. La tecnología GSM está basada en el uso de una tarjeta SIM (Subscriber Identity Module) que permite almacenar todos los datos del usuario como número telefónico, directorio telefónico, claves de seguridad y acceso, mensajes de texto, etc. La tarjeta SIM también permite al usuario acceder a los servicios ofrecidos por la red celular de Digitel GSM. La red celular de Digitel GSM abarca parte de la región central de Venezuela (los estados Distrito Federal, Miranda, Carabobo, Aragua, Falcón, Yaracuy, Cojedes, Guárico y Vargas). La empresa cuenta con aproximadamente 1,8 millones de suscriptores a nivel nacional en un mercado calculado en 7 millones aproximadamente lo que representa un tercio del mercado en la región central de Venezuela. [1] La empresa Digitel se inició en Julio de 1997 cuando CONATEL (Comisión Nacional de Telecomunicaciones), ente regulador del sector de las telecomunicaciones en Venezuela, entregó a la compañía

una multiconcesión para prestar servicios básicos de

telecomunicaciones y telefonía pública. Seis meses después, en Enero de 1998, se firmó el contrato. Ese mismo año, Digitel firmó un contrato de suministro para la construcción de la red en Caracas y su zona metropolitana con la empresa Nokia. En enero del año 1999 un acuerdo similar se concretó con la compañía Siemens para la expansión de la red celular de Digitel a Valencia. En Septiembre de 1999 se realizó el lanzamiento comercial de los servicios ofrecidos por Digitel al mercado venezolano. [2] Digitel se convirtió progresivamente en propiedad de la compañía TIM (Telecom Italia Mobile) que fue accionista único hasta mediados de este año momento en el cual Oswaldo Cisneros Fajardo se convierte en accionista único de Digitel GSM.

6

2.1.1

Misión de la Empresa “Ofrecer servicios de telecomunicaciones que excedan las expectativas de nuestros

clientes y accionistas, distinguiéndonos por una vocación de servicio, innovación, calidad y compromiso social.”[3]

2.1.2

Visión de la Empresa “Ser la empresa modelo de telecomunicaciones venezolana en términos de calidad,

innovación y rentabilidad, manteniendo una relación cálida y humana entre nosotros y con nuestros clientes.”[3]

2.1.3

Valores de la Empresa Orientación al Cliente, Integración, Proactividad, Velocidad, Transparencia,

Innovación, Excelencia Profesional y Espíritu Emprendedor. [3] − Orientación al cliente: El cliente es lo principal y su satisfacción un valor fundamental. Escuchamos a nuestros clientes para anticipar y responder sus necesidades. − Integración: Cooperamos y actuamos en conjunto para minimizar los conflictos y maximizar el intercambio de información promoviendo y aprovechando la contribución de todos para el logro de un resultado común. − Proactividad: Anticipamos e influenciamos positivamente los eventos. Captamos y desarrollamos las oportunidades que se nos presentan. − Velocidad: Estamos concientes de que el tiempo es un recurso importante cuya optimización impacta los costos y el servicio que ofrecemos a nuestros clientes.

7

− Transparencia: Actuamos de manera transparente y ética, para fortalecer las relaciones con nuestras audiencias. Nuestras relaciones están basadas en la lealtad y el intercambio de información. − Innovación: Desarrollamos soluciones innovadoras, promovemos nuevos caminos para mejorar procesos y sistemas. − Excelencia Profesional: Desarrollamos las competencias requeridas transmitiendo seguridad y credibilidad. − Espíritu Emprendedor: Somos responsables directos del alcance de resultados concretos. Asumimos los desafíos y riesgos como una oportunidad de crecimiento.

2.1.4

Organigrama de la Empresa Digitel GSM posee una estructura piramidal dividida por departamentos (Mercadeo,

GOH (Gestión Organizacional y Humana), Operaciones, etc.). De igual manera, cada departamento está divido en gerencias que a su vez están divididas en coordinaciones. Cada departamento posee un vicepresidente como líder del mismo, cada gerencia tiene un gerente de área y cada coordinación tiene un coordinador como líderes respectivos de sus secciones. El número de especialistas que trabaja para cada coordinación depende de las necesidades de cada coordinación. En la figura 1 se puede ver el organigrama del Departamento de Operaciones en el cual se aprecia la división en gerencias y coordinaciones. El proyecto de grado que se desarrolla en este libro se hace bajo la Coordinación de Optimización que forma parte de la Gerencia de Operaciones y Mantenimiento. La Coordinación de Optimización es la encargada de monitorear, analizar y mejorar el desempeño de la red celular operativa de Digitel GSM.

8

Figura 1. Organigrama del Departamento de Operaciones de Digitel GSM.

2.2

Planteamiento del Problema. El crecimiento y expansión de una red de telefonía celular crea, a su operadora, la

necesidad de tener que almacenar, manipular y procesar cada vez mayor cantidad de información, por ejemplo, acerca del desempeño de la red celular. Para que una empresa que ofrece servicios de telefonía celular pueda posicionarse como empresa líder entre sus competidores, además de cumplir con estándares de calidad, debe diferenciarse entre sus competidores y debe ofrecer a sus usuarios el más variado y mejor servicio posible. Tratar de establecer cuál es el mejor servicio posible que una empresa de telecomunicaciones puede ofrecer puede ser una tarea imposible sin embargo, existen parámetros y variables que se pueden utilizar como indicadores de la calidad de servicio que reciben los usuarios de una red celular. Entre muchos de los parámetros que comúnmente se usan para determinar cuál es el mejor servicio de telefonía celular se pueden nombrar los siguientes: Precio de los servicios ofrecidos, área de cobertura de la red celular, tipo y

9

variedad de los servicios ofrecidos, cantidad de llamadas bloqueadas y llamadas caídas, calidad de la voz, velocidad de transmisión de datos, cantidad de errores en la transmisión, niveles de interferencia en las señales, etc. La Coordinación de Optimización de Digitel GSM ha usado algunos de los indicadores o KPIs anteriormente mencionados para mejorar el desempeño de la red celular. Es de hacer notar que debido a que la Coordinación de Optimización pertenece al Departamento de Operaciones, los KPI usados están relacionados a la estructura y funcionamiento de la red celular de Digitel GSM y no a la cantidad, precio o variedad de servicios ofrecidos. El personal de la Coordinación de Optimización ha diseñado y desarrollado herramientas y bases de datos para almacenar y analizar la información proveniente de la red celular. Información acerca de la configuración, tráfico y desempeño de cada una de las BTS Nokia de la red celular de Digitel GSM se puede analizar por medio del uso de las herramientas anteriormente mencionadas. Debido al crecimiento y expansión de la corporación Digitel GSM, las bases de datos usadas por la Coordinación de Optimización también sufrieron un crecimiento. Este crecimiento trajo como consecuencia la necesidad de tener que procesar y analizar mayor cantidad de información en el menor tiempo posible. El problema que enfrenta actualmente la Coordinación de Optimización es que las herramientas de análisis y las bases de datos desarrolladas no fueron diseñadas para manipular y procesar grandes cantidades de información. Es por esta razón que surge la necesidad de optimizar o mejorar la capacidad y velocidad de procesamiento tanto de las herramientas como de las bases de datos de la Coordinación de Optimización.

2.3 Alcance y limitaciones del proyecto El proyecto se divide en dos partes fundamentales. La primera de ellas comprende la realización de una evaluación comparativa entre el DBMS usado actualmente por la Coordinación de Optimización y otros dos DBMS (MySQL y PostgreSQL) de licencia libre. Dependiendo de los resultados del estudio, se deberá seleccionar el sistema administrador de

10

bases de datos capaz de procesar con mayor rapidez la información. Luego, se deberá realizar la migración, en caso de ser necesaria, de las bases de datos utilizadas por las herramientas Daily Optimizer y Parameter, al nuevo administrador de bases de datos. Por último, se deberán realizar las modificaciones necesarias a las herramientas Daily Optimizer y Parameter para que sean capaces de procesar con mayor rapidez la información de las bases de datos. La segunda parte del proyecto corresponde al desarrollo de una herramienta capaz de calcular automáticamente las adyacencias de una BTS. Esta herramienta debe servir como una primera aproximación en el proceso de selección de las adyacencias de una BTS. Además, esta herramienta debe servir como interfaz gráfica para poder administrar la base de datos que almacena la configuración de las BTS Nokia de la red celular de Digitel GSM, es decir, a través de la herramienta, se debe poder modificar información parcial o total acerca de una BTS e incluso se debe poder agregar o eliminar una BTS de la base de datos. Sumado a esto, cuando se calculen las adyacencias de una BTS, la herramienta debe ser capaz, como elección del usuario, de generar un reporte en el que se encuentre la información de la nueva BTS y sus adyacencias. Este reporte es denominado “Datafill” por la Coordinación de Optimización. No queda dentro del alcance del proyecto, explicar los métodos y procedimientos que se deben seguir para mejorar el desempeño de un sistema administrador de bases de datos. En el capítulo 4 se presentan los fundamentos teóricos que ayudan a entender los factores que afectan el desempeño de un DBMS. También se recomienda al lector, consultar las referencias bibliográficas en donde podrá encontrar mucha más información relacionada a la optimización de un sistema administrador de bases de datos.

3. OBJETIVOS 3.1

Objetivo general Modificar y crear las herramientas y bases de datos necesarias para lograr disminuir

los tiempos de procesamiento de datos y lograr la automatización de tareas manuales. 3.2

Objetivos específicos − Evaluar y comparar dos administradores de bases de datos de licencia libre (MySQL y PostgreSQL) con el administrador de bases de datos que actualmente se utiliza en la Coordinación de Optimización (Microsoft Access). − Basado en la comparación anterior, seleccionar el administrador de bases de datos más adecuado para la Coordinación de Optimización. − De ser necesario, migrar y modificar todas las bases de datos usadas por dos de las herramientas de la Coordinación de Optimización (Daily Optimizer y Parameter) para que funcionen bajo el nuevo administrador de base de datos seleccionado. − Realizar las modificaciones necesarias a la herramienta de la Coordinación de Optimización “Daily Optimizer” para disminuir los tiempos de consulta y procesamiento de datos. − Realizar las modificaciones a la herramienta de la Coordinación de Optimización “Parameter” para disminuir los tiempos de consulta y procesamiento de datos. − Desarrollar una herramienta capaz de automatizar el cálculo de las adyacencias de una estación base.

4. FUNDAMENTOS TEÓRICOS 4.1 Introducción A lo largo de este capítulo se presentará información fundamental para entender el proyecto desarrollado en este libro. Conocimientos de telecomunicaciones, de bases de datos y programación, son fundamentales para el claro entendimiento del proyecto. Este

capítulo

empieza

por

presentar

fundamentos

teóricos

generales

de

telecomunicaciones, luego se hace un recorrido acerca de la tecnología y arquitectura del estándar de comunicaciones móviles GSM, y por último se dan a conocer los fundamentos teóricos de los sistemas administradores de bases de datos, haciendo mención de los tres que se estudian en este libro.

4.2 Principios Básicos de GSM 4.2.1

Evolución de GSM En los inicios de la década de 1980, CEPT (Conférence Européenne des Postes et

Telecommunications) fundó un grupo encargado de diseñar un sistema de telecomunicaciones común a Europa occidental. El grupo se llamó “Groupe Spéciale Mobile” y creció el nombre de sistema GSM. Las siglas GSM se han interpretado de muchas maneras, pero la más común es la de "Global System for Mobile communications". [4] Durante el diseño del sistema se consideraron tres factores fundamentales: [4] − En cada país deben existir varios operadores de redes de comunicación, lo que garantiza la competencia en cuanto a tarifas y servicios ofrecidos. Se supuso que ésta era la mejor manera para asegurar la rápida expansión de GSM. − El sistema GSM debía ser un sistema abierto cuyas interfaces entre cada una de las partes del sistema debían estar bien definidas, de manera tal que varios equipos de

13

diferentes fabricantes pudieran coexistir y por lo tanto mejorar la relación costoeficiencia del sistema desde el punto de vista del operador. − Las redes GSM deberán ser construidas sin que hayan cambios grandes en las redes telefónicas conmutadas públicas (PSTN; Public Switching Telephone Networks) existentes. − El sistema deberá mantener una buena calidad de voz. − El sistema deberá hacer uso del espectro radio eléctrico de la manera más eficiente posible. − El sistema deberá tener una alta-adecuada capacidad. − El sistema deberá ser compatible con servicios integrados de redes digitales (ISDN; Integrated Services Digital Networks). − El sistema deberá ser compatible con otras especificaciones de comunicación de datos. − El sistema deberá mantener una buena seguridad respecto al suscriptor y a los datos transmitidos. Estas necesidades impuestas sobre GSM, se pueden alcanzar muchas ventajas, como por ejemplo: [4] − GSM usa las radiofrecuencias eficientemente y debido al uso digital en el radio canal, el sistema tolera más interferencias. − La calidad de voz es mejor que la de sistemas celulares analógicos. − Se garantiza la seguridad del suscriptor a través de la encriptación de la voz. − Se ofrece una mayor cantidad de servicios debido a la compatibilidad con ISDN. − Roaming internacional es posible entre los países que usen GSM. A continuación se presenta una breve cronología en la evolución de GSM: [4] 1982

CEPT inició un nuevo sistema celular a través del grupo GSM. La comisión europea (EC) indicó que los países miembros debían reservar la banda de los 900 MHz para GSM.

14

1987

Se asignaron las frecuencias 890 – 915 MHz para comunicación desde la estación móvil a la base estación (uplink), y 935 – 960 MHz para la comunicación desde la estación base a la estación móvil (downlink).

1991

El primero de Julio, se realizó la primera llamada en el mundo a través de GSM.

1992

Se lanzó la primera red GSM en Finlandia. Se asignaron nuevas frecuencias para uplink (1710 – 1785 MHz) y para downlink (1805 – 1880 MHz). En Diciembre, existían 13 redes en 7 áreas geográficas distintas, y operadores en Australia fueron los primeros aliados no-europeos de GSM.

1993

En Diciembre ya habían 32 redes GSM operando en 18 áreas geográficas distintas.

1995

Había 117 redes GSM operando a nivel mundial. Se implementó la primera red GSM 1900 en E.E.U.U.

1998

Se realizaron las primeras pruebas de datos de circuito conmutado de alta velocidad (HSCSD; High Speed Circuit Switched Data) en Singapur. Más de 120 millones de usuarios a nivel mundial de GSM 900/1800/1900.

1999

Se realizó la primera llamada con datos usando GPRS (General Packet Radio Service) en una red activa. A finales de este año, más de 250 millones de usuarios estaban con operadoras de redes GSM.

4.2.2

Arquitectura de una red celular GSM GSM posee dos interfaces que son realmente abiertas. La primera de ellas, entre la

estación base y la estación móvil, llamada interfaz de aire (Air Interface). La segunda es entre la central de conmutación de servicios móviles (MSC; Mobile services Switching Center) y el controlador de base estaciones (BSC; Base Station Controller), llamada interfaz A (A Interface). Existen otras interfaces definidas, pero no son realmente abiertas ya que las especificaciones no se habían completado cuando se lanzaron los sistemas comerciales. [4] La inteligencia de la red GSM, a diferencia de las redes analógicas que poseían una inteligencia centralizada, se distribuye en tres subsistemas: Subsistema de estación base, subsistema de conmutación de la red, subsistema de administración de la red y el subsistema de operación y mantenimiento.

15

Otro componente fundamental en cualquier red celular es la estación móvil (MS; Mobile Station) que es la que hace uso de los servicios de una red GSM. Sin embargo, en GSM, una MS está compuesta por un equipo terminal o equipo móvil (TE; Terminal Equipment) y un módulo de identificación de suscriptor (SIM; Subscriber Identity Module). Cada SIM posee un número de identificación internacional de suscriptor móvil (IMSI; International Mobile Subscriber Identity) y una identificación internacional de equipo móvil (IMEI; International Mobile Equipment Identity). [5] [4] [6] La figura 2 muestra la arquitectura básica de una red GSM. [6]

Figura 2. Arquitectura de una red GSM

4.2.2.1 Subsistema de estación base El Subsistema de estación base (BSS; Base Station Subsystem) está encargado de controlar el radio canal de todas las llamadas y los recursos disponibles en el sistema. El BSS

16

está compuesto por el controlador de estación base, la estación base de transmisión-recepción y el transformador de codificación. [4] [5] [6] [7] − La estación de transmisión-recepción (BTS; Base Station Transceiver): Formada por transmisores, receptores, antenas, etc., se encarga de conectar las estaciones móviles a la red GSM. Debe proveer la encriptación y codificación de los datos y asegurarse de mantener una comunicación libre de errores entre las MS. − El controlador de estación base (BSC; Base Station Controller): Constituye el elemento central del BSS y se encarga de controlar la manera en que varias BTSs (generalmente un número alrededor de 100) usan los recursos disponibles. El BSC debe encargarse de mantener la movilidad y el mantenimiento de las llamadas, y dar soporte a la interfaz de aire y la interfaz A. − El transformador de codificación (TC; Transcoder): Se encarga de hacer los ajustes necesarios a los datos, para que pueda existir una comunicación entre la BSC y el NSS.

4.2.2.2 Subsistema de conmutación de la red El Subsistema de conmutación de la red (NSS; Network Switching Subsystem), está encargado de realizar todas las funciones necesarias para el control de llamadas. El NSS está compuesto por: Central de conmutación de servicios móviles, registro de ubicación usuarios casa (HLR; Home Location Register), registro de ubicación de usuarios visitantes (VLR; Visitor Location Register), centro de autentificación (AuC; Authentication Center) y el registro de identidad de equipos (EIR; Equipment Identity Register). [4] [5] [6] [7] − La central de conmutación de servicios móviles (MSC; Mobile Switching Center): Se encarga de realizar las funciones de registro y autenticación de usuarios, enrutamiento de llamadas, señalización, etc. Básicamente cumple las mismas funciones que una central de una red digital fija ISDN (Integrated Services Digital Network) o la más

17

conocida red telefónica fija PSTN (Public Switched Telephone Network). Cuando la función de una MSC es servir como puente entre una red fija y una red móvil (PLMN; Public Land Mobile Network), generalmente se conoce como GMSC (Gateway MSC). (figura 2) − El registro de ubicación de usuarios casa (HLR; Home Location Register): Puede ser considerado como una base de datos en donde se almacena, de forma permanente, la información de todos los usuarios o suscriptores de una operadora de red GSM, de todos los servicios que cada usuario puede acceder en la red e información que permiten manejar la seguridad de la información de un usuario. Cada PLMN o red móvil, posee un solo HLR, y cada usuario es asignado solamente a un HLR incluso si éste se encuentra en otra red GSM que no sea su red de origen. − El registro de ubicación de usuarios visitantes (VLR; Visitor Location Register): Es una base de datos en donde se almacena información dinámica de los usuarios o suscriptores. Cuando un suscriptor se mueve de una cierta ubicación a otra, la información de éste se transfiere del VLR viejo al VLR nuevo. Existen momentos en que el nuevo VLR debe consultar el HLR del usuario para obtener información adicional. La diferencia fundamental entre el VLR y el HLR es que el VLR se asigna una zona geográfica específica y el HLR es independiente de la ubicación geográfica del suscriptor. Aún cuando el usuario se encuentra en su red de origen, el VLR que abarca su ubicación geográfica es quien maneja los datos dinámicos del usuario. Un VLR puede servir a varios MSCs. La figura 3 muestra algunos de los diferentes datos almacenados en el HLR y VLR, y la figura 4 muestra la relación entre MSC y VLR. [6] [7]

18

Figura 3. Diferencias entre HLR y VLR

Figura 4. Relación entre MSC y VLR

19

− El registro de identificación de equipos (EIR; Equipment Identity Register): Sirve para controlar el uso de equipos en la red. Debido a la separación en la identificación del suscriptor (a través del IMSI) y la identificación del equipo (a través del IMEI), es posible la creación de un mercado negro de equipos robados ya que es posible operar cualquier equipo GSM con cualquier SIM GSM válido. Para evitar este mercado negro, el EIR almacena entre otras cosas el IMEI (ya que no existe forma de cambiarlo sin destruir el equipo) de aquellos equipos que no serán permitidos en la red. El EIR mantiene esta información generalmente en tres listas: La lista blanca (White list) que almacena el tipo de todos los equipos GSM aprobados, es decir, que pueden ser usados en la red, la lista negra (Black list) que contiene los IMEIs de equipos robados o que no deben ser permitidos por razones técnicas y la lista gris (Gray list) que contiene los equipos a los cuales se les debe hacer seguimiento. − El centro de autenticación (AuC; Authentication Center): Generalmente integrado en el HLR, guarda las claves de autenticación de usuarios y las claves para la encriptación de la voz.

4.2.2.3 Subsistema de administración de la red El subsistema de administración de la red (NMS; Network Management Subsystem) también conocido como subsistema de operación y mantenimiento (OMSS; Operation and Maintenance SubSystem), se encarga de realizar, a través del centro de operación y mantenimiento (OMC; Operation and Maintenance Center), funciones de monitoreo, control y administración de la red. Entre sus funciones se pueden mencionar: [7] − La administración y control de los suscriptores, de la cobranza, de la recolección de estadísticas, etc. − Manejo y administración de la seguridad en la red.

20

− Manejo de la configuración, operación y desempeño de todos los componentes de la red. − Realizar tareas de mantenimiento.

4.2.3

Interfaz de Aire La unión internacional de telecomunicaciones (ITU; International Telecommunication

Union) es el ente internacional encargado, entre otras cosas, de asignar el uso del espectro radioeléctrico. Para GSM, la ITU ha asignado las siguientes frecuencias: [5] [6] GSM900 Uplink: 890-915 MHz Downlink: 935-960 MHz GSM1800: Uplink: 1710-1785 MHz Downlink: 1805-1880 MHz GSM1900: Uplink: 1850-1910 MHz Downlink: 1930-1990 MHz Para hacer uso de los recursos limitados del espectro radioeléctrico, GSM usa una combinación entre el acceso múltiple por división de tiempo (TDMA; Time Division Multiple Access) y el acceso múltiple por división de frecuencia (FDMA; Frequency Division Multiple Access). La parte FDMA de GSM divide el ancho de banda tanto del enlace de subida (Uplink) como del enlace de bajada (Downlink) de 25 MHz, en 124 frecuencias portadoras separadas entre sí por un ancho de banda igual a 200 KHz. La parte TDMA de GSM divide cada una de estas frecuencias en 8 ranuras de tiempo (Time slots) con una duración aproximada de 577 microsegundos. Cada ranura de tiempo puede ser ocupada por una ráfaga (Burst) de 156,25 bits, cada uno con una duración de 3,69 microsegundos aproximadamente. Esto hace que la rata de bits en la interfaz de aire sea de aproximadamente 270Kbits/s (En

21

realidad está definida como 270,833 Kbps).Si se combinan 8 time slots, se forma una trama (Frame) TDMA cuya duración es de 4,616 milisegundos. La figura 5 muestra la configuración de la interfaz de aire y la figura 6 muestra como se combinan las ranuras de tiempo para formar tramas. [5] [6] [7]

Figura 5. Interfaz de aire de GSM

4.2.3.1 Canales físicos y lógicos Para poder transmitir los datos por la interfaz de aire, GSM utiliza cada ranura de tiempo para transmitir diferente información a distintas MS. Para poder identificar el tipo de información en una ranura de tiempo determinada, se usan los conceptos de canales físicos y lógicos. Los canales físicos son todas las ranuras de tiempo disponibles en una BTS, es decir, cada ranura de tiempo que puede ser usada para enviar o recibir datos, es un canal físico. Los canales lógicos se usan para identificar el tipo de información que se encuentra en un canal físico. En GSM los canales lógicos se pueden dividir en canales de tráfico y canales de señalización.

22

Los canales de tráfico (TCH; Traffic Channels) son usados para la transmisión de voz o de datos. Existen dos tipos de canales de tráfico que son el fullrate (TCH/F; 22,8 Kbps) y el halfrate (TCH/H; 11,4 Kbps). Cuando se usa el canal completamente, es decir, la velocidad de transmisión es la máxima, se dice que es un canal fullrate. Con el uso de canales TCH/H, es posible transmitir dos llamadas en un mismo canal. Esto se puede lograr ya que la capacidad de transmisión del canal TCH/H es la mitad de la del canal TCH/F. [5]

Figura 6. Time slots y tramas TDMA en GSM.

23

Los canales de señalización se pueden dividir más aún en canales de difusión (Broadcast), canales dedicados y canales comunes. Los canales broadcast o canales para la comunicación punto-multipunto, son usados solamente en el enlace de bajada (dirección downlink; desde la BTS a la MS) y son responsables principalmente de la sincronización y corrección de frecuencia. Los siguientes canales están en esta categoría: [4] [5] − Broadcast Control Channel (BCCH): Usado por las BTS para enviar información general específica a todas las MS al alcance, por ejemplo, código de área local (LAC; Local Area Code), parámetros de acceso, lista de BTS adyacentes, frecuencias usadas por la BTS, secuencia de saltos de frecuencia (Frequency Hopping), etc. − Frequency Control Channel (FCCH): Usado por la BTS principalmente para la corrección de las frecuencias de una MS. − Synchronization Channel (SCH): Usado por la BTS para sincronizar las tramas TDMA en una MS. Con la recepción válida de un burst completo de SCH, una MS obtendrá toda la información necesaria para sincronizarse con una BTS. Los canales comunes son utilizados para llevar información de la red a la MS y para permitir el acceso a la red. Los siguiente canales entran en esta categoría: [4] [5] − Paging Channel (PCH): Usado por la BTS para informar a la MS de, por ejemplo, una llamada entrante. − Access Grant Channel (AGCH): Usado por la BTS para asignar un canal TCH o SDCCH a la MS y permitirle el acceso a la red. − Random Access Channel (RACH): Usado por la MS para hacer una petición para que se le asigne un canal SDCCH luego de recibir, por ejemplo, un llamado de atención (paging). La MS escoge un tiempo aleatorio en el cual envía información por este canal. Esto puede ocasionar colisiones entre MS.

24

Por último están los canales lógicos dedicados. Éstos son usados para realizar operaciones tales como encriptación, roaming, handovers, etc. En esta categoría están los siguiente canales: [4] [5] − Stand-alone Dedicated Control Channel (SDCCH): Usado principalmente para la señalización entre MS y BTS antes de que sea asignado un canal TCH. − Slow Associated Control Channel (SACCH): Usado para transmitir continuamente mediciones de alineación de tramas o mediciones de potencia, por ejemplo. Funciona en paralelo con cada canal TCH y SDCCH. − Fast Associated Dedicated Control Channel (FDCCH): Usado para transmitir datos de señalización generalmente cuando se necesita realizar un handover. El FDCCH reemplaza un TCH durante el handover. En la figura 7 se muestra un resumen de los canales lógicos usados en GSM. [7]

Figura 7. Canales lógicos de la interfaz de aire de GSM

25

4.2.3.2 Handover Un handover está definido como el cambio del radio canal (TCH o SDCCH) actualmente en uso a otro radio canal durante una conexión activa entre una BTS y una MS. Esto puede ocurrir, por ejemplo, cuando una MS que tiene una conexión activa con una BTS, sale del área de cobertura de esa BTS. Como es necesario que la comunicación permanezca activa, la conexión de la MS debe ser entregada a otra BTS para que ésta continúe. En GSM se han definido al menos cuatro tipos de handover. [4] [5] [7] − Handover intra-BTS: Ocurre cuando se transfiere la conexión entre dos canales distintos dentro de una misma BTS. − Handover inter-BTS: Ocurre cuando la conexión se transfiere entre dos BTS distintas que son controladas por la misma BSC. − Handover inter-BSC: Ocurre cuando se transfiere la conexión entre dos BTS distintas, controladas por diferentes BSC, pero bajo un mismo MSC. − Handover inter-MSC: Ocurre cuando la conexión entre dos BTS controladas por diferentes BSC y éstas a su vez controladas por distintos MSC. Los handover son originados o por las BSC o por los MSC (para balancear el tráfico, por ejemplo) Durante el estado sin actividad, la MS escanea los canales BCCH de hasta 16 BTS adyacentes y conforma una lista con los 6 mejores candidatos para realizar el handover, basado en los niveles de las señales recibidas. Esta información se pasa al BSC y al MSC, al menos una vez por segundo, y es usada en el algoritmo para decidir el handover. La decisión para realizar el handover, generalmente se basa en la calidad y los niveles de recepción. En GSM, un handover puede llevarse a cabo a velocidades de hasta 250 km/h. [5]

4.2.4

Planificación y optimización de una red GSM. Planificar una red celular es un proceso complejo y continuo que involucra el análisis

y estudio de muchas variables como los costos de construcción de la red, capacidad de la red,

26

cobertura y ubicación de los elementos de la red, calidad de las llamadas, desarrollos a futuro en la red, distribución de la población, estadísticas de uso telefónico en la población, etc. [4] Los pasos fundamentales para planificar una red son: 1. Recolectar información acerca de: leyes y regulaciones, información demográfica, niveles de ingresos de la población, predicciones de expansión geográfica, disponibilidad de frecuencias de microondas, requerimientos de conexión con otros sistemas, principios de enrutamiento, direccionamiento y numeración, mapas topográficos, infraestructura existente, etc. 2. Dimensionar la red basándose en los requerimientos de cobertura y capacidad, para lo cual se necesita información detallada acerca de las estimaciones de crecimiento, infraestructura disponible y necesitada, metas de calidad y desempeño, cantidad y tipos de equipos necesitados, etc. 3. Seleccionar la ubicación de los MSC, BSC y BTS. 4. Evaluar las diferentes ubicaciones de los MSC, BSC y BTS para ver si la ubicación cumple con los requerimientos necesarios. Por ejemplo, al evaluar la ubicación de una BTS se debe tomar en cuenta los alrededores, obstáculos geográficos y estructurales y equipos de radiofrecuencia existentes en la zona. 5. Planificación detallada de la red. Utilizar sistemas y herramientas con diseño ayudado por computadora (CAD; Computer Aided Design) para la predicción del área de cobertura, análisis de interferencia, planificación de frecuencia, planificación de enlaces de microondas, etc. Existen tres áreas fundamentales en la planificación de una red celular [4]. La planificación de la red conmutada (Switching Network Planning), en donde se deben analizar los requerimientos de calidad, niveles de desempeño, interconexión con otras redes, cantidad de usuarios, cantidad de servicios ofrecidos, desarrollos y expansión futura de la red, etc. La planificación de la red de transmisión celular (Cellular Transmission Network Planning) es la segunda área a tomar en cuenta y se enfoca en el diseño de los enlaces de microondas, por ejemplo, entre BTS y BSC. La última área que se debe tomar en cuenta es la planificación de

27

la red de radiofrecuencia (Radio Network Planning) o la planificación de los recursos de radiofrecuencia, la cual será discutida con más detalle a continuación.

4.2.4.1 Planificación de los recursos de radiofrecuencia. El factor fundamental en esta fase de la planificación de una red celular es la ubicación, configuración y tipo de BTS que se usarán. Se deben realizar análisis acerca del tipo de ciudad, volúmenes de tráfico y distancias de cobertura para identificar la BTS más adecuada que se debe utilizar. En GSM, el área geográfica de cobertura de la red celular se divide en celdas. Una celda corresponde al área geográfica cubierta por una BTS. Teóricamente, el tamaño máximo de una celda, medido desde el centro de la BTS hasta el borde de la celda, es de 35 km, sin embargo, el tamaño depende de varios factores como número de usuarios, tipo y tamaño de la ciudad, frecuencia de transmisión, condiciones geográficas, topología, etc. [4] Para dimensionar una celda, es necesario conocer cuantos canales de tráfico (TCH) son necesarios. Para determinar esto, es necesario calcular un estimado de la capacidad de tráfico necesario, lo cual se hace a través del número de Erlangs necesarios. Un Erlang es la unidad de medida del tráfico de una red y equivale al uso continuo de un canal de comunicación por una hora, sin embargo, la cantidad de tráfico es independiente al tiempo de observación por lo que se puede definir un Erlang como el uso continuo de un canal de comunicación por tiempo de observación. Para calcular el número de Erlangs necesarios se usa la siguiente fórmula: [4] Erlangs =

(llamadas. por.tiempo.de.observacion ) × (tiempo. promedio.de.conversacion) (tiempo.de.observacion )

En esta fórmula es necesario que el tiempo promedio de conversación o tiempo promedio de uso de un canal de comunicación y el tiempo de observación estén en las mismas unidades (segundos, minutos, horas). Por ejemplo, si se tiene un promedio de 540 llamadas por hora y el tiempo promedio de conversación es de 100 segundos, entonces la capacidad de tráfico es de 15 Erlangs. Si se decide utilizar un tiempo de observación de 15 minutos, por ejemplo, entonces se deben tomar el número de llamadas por 15 minutos y el tiempo de observación será de 900 segundos. [4]

28

Otro factor importante al planificar la red de radiofrecuencia es la configuración de las BTS que se va a usar. Tres tipos de configuraciones son los más conocidos y son: La configuración omnidireccional, en donde la antena de la BTS puede transmitir y recibir en 360º, es decir, el patrón de radiación de la antena muestra la misma intensidad en todas direcciones. Existen también BTS sectorizadas en dos o tres, esto significa que una BTS posee dos o tres antenas que transmiten en una determinada dirección, es decir, el patrón de radiación de la antena muestra mayor intensidad en un rango determinado de direcciones. La figura 8 muestra la configuración de los tres tipos de BTS. [4]

Figura 8. Diferentes configuraciones de BTS.

Es importante en toda red celular poder optimizar los recursos disponibles en ella. Uno de los recursos más escasos es el espectro radioeléctrico. Solamente hay un número limitado de frecuencias asignadas a un BSS y éste número es siempre mucho menor que la cantidad de celdas que tiene o que tendrá la red celular. Debido a esto se hace necesario hacer un reuso de las frecuencias disponibles (Frequency reuse). Este método consiste en asignar las frecuencias de modo tal de obtener la menor interferencia posible. La asignación de las frecuencias se realiza a través de un patrón de reuso, y en la figura 9 se muestra uno de los muchos que

29

existen. Otros métodos para optimizar una red celular pueden ser usados, como por ejemplo el uso de saltos de frecuencia (Frequency hopping), sin embargo, no se mencionarán en este libro.

Figura 9. Patrón de reuso en una red GSM con 9 frecuencias disponibles. [4]

4.2.4.2 Modelos de propagación para la planificación de una red celular Como se mencionó anteriormente, es necesario hacer uso de herramientas que faciliten la tarea de planificación a través del diseño ayudado por computadora (CAD). También se mencionó que es necesario hacer predicciones o estimaciones acerca del área de cobertura de una red, en particular, el área de cobertura de una BTS. Es imposible calcular exactamente el área de cobertura de una BTS ya que existen muchas variables que afectan el comportamiento de la señal de radiofrecuencia como la reflexión, refracción, difracción, dispersión y las pérdidas de espacio libre, sin embargo, existen muchos modelos utilizados para predecir y calcular teóricamente el área de cobertura de una BTS. En la figura 10 se muestra un gráfico con algunos de los modelos que existen.

30

Figura 10. Modelos de propagación y su rango válido de frecuencias. [8]

El modelo que se presenta a continuación, es el modelo utilizado en el desarrollo del proyecto. Se utilizó este modelo debido a que todos los parámetros del modelo, pueden ser obtenidos de las bases de datos de la Coordinación de Optimización. El modelo escogido fue el de Okumura-Hata. Modelo de Okumura-Hata En la década de 1960, estaba en marcha en Japón, una gran campaña orientada a realizar mediciones en las pérdidas en la comunicación entre dos antenas. Las mediciones de Yoshihisha Okumura consistieron en hacer calcular la atenuación de espacio libre entre dos antenas isotrópicas y luego hacer ajustes y correcciones por excesos de pérdida y alturas de la estación base y la estación móvil. Durante las pruebas Okumura varió los siguientes parámetros: [9] [10] − Frecuencia: 100 – 3000 MHz − Distancia: 1 – 100 km − Altura de la estación móvil: 1 – 10m

31

− Altura de la estación base: 20 – 100m − Ambiente o área: ciudades pequeñas, medianas, grandes, etc. − Los valores de pérdidas de propagación se dan como valores medios, 50% del tiempo y 50% de las áreas. En 1980, Masaharu Hata publicó un modelo de propagación parametrizado basado en las mediciones de Okumura. Las limitaciones o rangos válidos para el modelo de Hata o modelo Okumura-Hata son menores a los originales como se muestran a continuación: − Frecuencia: 150 – 1500 MHz − Distancia: 1 – 20 km − Altura de la estación móvil: 1 – 10m − Altura de la estación base: 30 – 200m La figura 11 muestra gráficamente algunos de los parámetros del modelo OkumuraHata. [10]

Figura 11. Representación gráfica del modelo de propagación empírico de Okumura-Hata.

La fórmula usada para calcular las pérdidas de propagación en una zona o área urbana es la siguiente: [9] [10] LP = 66,55 + 26,16 log( f ) − 13,82 log(hBTS ) − a (hMS ) + (44,9 − 6,55 log(hBTS )) log(d )

32

Donde: f es la frecuencia de la portadora en MHz d es la distancia en km hBTS es la altura de la antena de la estación base hMS es la altura de la estación móvil a(hMS) es un factor de corrección ⎧ ⎫ 2 ⎪3,2(log(11,75hMS )) − 4,97; f ≥ 400 MHz ciudades grandes ⎪ ⎪⎪ ⎪⎪ 2 a (hMS ) = ⎨8,29(log(1,54hMS )) − 1,1; f < 200 MHz ciudades grandes ⎬ ⎪ ⎪ ⎪(1,1 log( f ) − 0,7 )hMS − (1,56 log( f ) − 0,8); ciudades medianas y pequen~as ⎪ ⎩⎪ ⎭⎪

Para calcular las pérdidas de propagación en una zona suburbana se usa la siguiente ecuación: [9] [10] 2

LP SUBURBANA

⎛ ⎛ f ⎞⎞ = LP − 2⎜⎜ log⎜ ⎟ ⎟⎟ − 5.4 ⎝ ⎝ 28 ⎠ ⎠

Para calcular las pérdidas de propagación en una zona rural se usa la siguiente ecuación: [9] [10] LP RURAL = LP − 4,78(log( f )) + 18,33 log( f ) − 40,94 2

Todo lo expuesto en esta sección, sólo forma parte del inicio de un proceso constante y continuo de optimización de la red. Una red celular debe ser monitoreada constantemente para poder realizar expansiones de la red en lugares y en momentos adecuados. Al mismo tiempo en que la red debe ser lo más pequeña posible (para poder reducir costos), es decir, la capacidad de la red no debe estar sobredimensionada o no debe ser mucho mayor a la necesitada, se debe hacer que los suscriptores perciban una elevada calidad de servicio (QoS; Quality of Service), lo que hace que la red deba ser grande (mayor cobertura y calidad). Esto crea un compromiso en el tamaño de la red ya que ésta debe ser lo suficientemente grande y lo suficientemente pequeña para ofrecer el mejor servicio. Debido a que se desea que los

33

usuarios perciban la mejor calidad de servicio posible, se deben eliminar o reducir factores que afecten esta percepción como los son la cantidad de llamadas caídas, calidad de la voz, cantidad de llamadas fallidas, etc. Por último, la red debe ser analizada constantemente en búsqueda de satisfacer todas las necesidades y demandas presentes y futuras de servicios complementarios. Por ejemplo, se pueden hacer cambios a las redes GSM para obtener mayores tasas de transferencia de bits con tecnologías como High Speed Circuit Switched Data (HSCSD), General Packet Radio Service (GPRS) y Enhanced Data Rates for Global Evolution (EDGE).

4.3 Fundamentos de las bases de datos y sistemas de bases de datos Para poder hablar de bases de datos y de administradores o sistemas administradores de bases de datos (DBMS; DataBase Management System) se deben conocer claramente los conceptos que los definen. Una base de datos puede ser definida simplemente como una colección o un conjunto de datos, almacenados bajo una determinada estructura, persistentes en el tiempo y un sistema administrador como el conjunto de herramientas que permiten el acceso y uso de los datos almacenados [11]. Por ejemplo, una libreta de direcciones es considerada como una base de datos, o incluso una biblioteca en donde los datos están organizados en libros y clasificados según el tipo o al género al cual pertenecen, sin embargo, generalmente al hablar de bases de datos, se hace referencia a los datos que son almacenados en un computador en forma digital. A lo largo de este libro se utilizará esta referencia de bases de datos, es decir, las que se almacenan en un computador.

4.3.1

Historia de las bases de datos Desde los primeros años de la década de 1960, cuando el primer sistema administrador

de bases de datos de propósito general fue creado por Charles Bachman en General Electric [12], se han desarrollado varios modelos que son usados para representar la información almacenada en una base de datos. El modelo de red de datos (en inglés network data model),

34

el modelo de datos jerárquicos (hierarchical data model), el modelo de datos orientados a objetos, el modelo de datos entidad-relación y el modelo relacional de bases de datos (relational data model) son algunos de los ejemplos que muestran la evolución de las bases de datos. Hoy en día, el modelo de bases de datos más aceptado a nivel mundial es el modelo relacional desarrollado por Edgar Codd en los laboratorios de investigación de IBM en San José, California, durante la década de 1970. [12] [13] Antes de que se desarrollaran los conceptos de bases de datos y de administradores de bases de datos, la información se almacenaba en archivos de computadora. Usar el sistema de archivos del sistema operativo para almacenar datos, posee, entre muchas, las siguientes desventajas: [12] [13] − No hay control en el acceso y modificación de datos, es decir, no hay control en la concurrencia de acceso de usuarios. Por ejemplo, dos clientes de un banco quieren hacer retiros de una cuenta cuyo estado inicial es de 100. Un cliente hace un retiro de 60 y otro de 30. El sistema de archivo no tiene forma de asegurar que el estado de la cuenta será correcto (habrá inconsistencia). Dependiendo de cual sea el último retiro escrito en el archivo, la cuenta puede quedar en 40 o en 70 y no en 10 como debería ocurrir. − Para evitar tamaños de archivos muy grandes (mayores a la capacidad de memoria del computador, por ejemplo.), es necesario dividir los datos en varios archivos los cuales seguramente tendrán problemas de inconsistencia y redundancia si no se realiza un diseño adecuado de los programas que consultan y modifican los archivos. El problema de la inconsistencia se mencionó en el punto anterior, sin embargo, la redundancia está en que si por ejemplo, un banco tiene dos archivos en donde almacena información de la cuenta corriente y la cuenta de ahorros de sus clientes, es probable que tanto el número telefónico como la dirección de los clientes aparezcan en ambos archivos (problemas de redundancia), lo que hace que las bases de datos crezcan de manera desmesurada. − Para realizar búsquedas o consultas de información en los archivos, es necesario crear uno o varios programas que realicen las consultas deseadas. Si luego de desarrollar el

35

software, es necesario realizar otro tipo de búsqueda a las diseñadas originalmente, es necesario desarrollar otro programa que satisfaga la nueva o nuevas necesidades. Otra opción casi impensable, debido a la cantidad de tiempo invertido, es la de realizar la búsqueda manual de la información deseada. − Puede ocurrir que los archivos hayan sido diseñados con diferentes formatos lo que hace que la tarea de desarrollar un nuevo programa sea más complicada. − Pueden también existir problemas de seguridad en cuanto a cuales datos pueden ser usados por cuales usuarios. A pesar de que esto se puede implementar en un sistema de archivos desde el diseño, tratar de cambiar las políticas de seguridad de las bases de datos puede ser una tarea engorrosa y complicada. Todos los problemas mencionados anteriormente, entre otros, fueron solucionados con el desarrollo y la aparición de diferentes modelos de bases de datos, y con el desarrollo y aparición de los sistemas administradores de bases de datos cuyas funciones se pueden resumir en: [12] [13] [14] − Asegurar y controlar el correcto almacenamiento de los datos. − Garantizar la seguridad de los datos. − Controlar el acceso a los datos de múltiples usuarios. − Asegurar la integridad de los datos. − Administrar procesos de respaldo y recuperación de datos.

4.3.2

Modelo relacional de bases de datos Un modelo de datos es una representación simple de la estructura de una base de datos.

En él se describe la forma en que se deben mostrar los diferentes tipos de datos y las relaciones entre ellos. El modelo relacional de bases de datos propuesto por Edgar Codd, está basado en tres componentes principales para representar los datos: Entidades, atributos y relaciones. [12] [13] [14]

36

Una entidad representa cualquier cosa de la cual se quiere recolectar y almacenar datos o información. Las entidades pueden ser objetos físicos o abstractos como por ejemplo una persona, un lugar, un evento, un producto, una ruta de vuelo, etc. Un atributo es una característica de una entidad. Por ejemplo, una entidad llamada PERSONA puede ser descrita o identificada a través de atributos tales como nombre, apellido, teléfono, dirección, número de cédula, etc. Una relación, componente principal del modelo relacional de bases de datos, permite mostrar y almacenar la información en forma de una tabla de dos dimensiones. Cada fila o “tuple” de la tabla representa una entidad única. Las columnas de la tabla corresponden a los atributos de las entidades y no pueden existir dos atributos o columnas con el mismo nombre. Igualmente, dos filas, tuples o entidades no pueden ser exactamente las mismas, al menos un atributo debe ser diferente, es decir, cada entidad debe poseer una combinación única de los atributos de la relación. Existe también lo que se conoce como schema, que describe las características de una relación o tabla, es decir, el nombre de la tabla, el nombre de cada una de las columnas de la tabla y el tipo de datos que se deben almacenar en cada columna. [12] [13] [14] En la figura 12, se muestra un ejemplo de una relación o tabla de una base de datos relacional.

Figura 12. Relación o tabla de una base de datos relacional.

37

4.3.3

Sistemas administradores de bases de datos El concepto de sistema administrador de bases de datos en el sentido más amplio

define al conjunto de herramientas utilizadas para compartir y hacer uso de los datos almacenados en una base de datos. Al igual que las bases de datos, cuando se habla de un administrador de bases de datos, se hace referencia a un programa o software que permite manejar y compartir datos, y provee de un método sistemático para crear, actualizar, buscar y almacenar información en una base de datos. Además, un administrador de bases de datos debe tener la capacidad de ofrecer la integridad y seguridad de los datos así como también la capacidad de optimizar y controlar el acceso a los datos [11]. En la figura 13 se muestra la relación entre un DBMS y una base de datos [11]

Figura 13. Relación entre un DBMS y varias bases de datos

38

4.3.4

Estructura de un sistema administrador de bases de datos Cualquier sistema de bases de datos se puede dividir a grandes rasgos en dos partes

fundamentales: El administrador de almacenamiento (Storage Manager) y el administrador o procesador de consultas (Query Processor). Básicamente el administrador de almacenamiento se encarga de hacer el mejor uso posible de los datos almacenados. Existen empresas cuyas bases de datos pueden alcanzar tamaños de varios cientos de gigabytes e incluso terabytes. Debido a que la memoria principal de las computadoras no es capaz de almacenar tal cantidad de información, los datos son almacenados en discos duros. Los sistemas administradores de bases de datos deben ser capaces de mover entre el disco y la memoria según se necesite. Dado que los tiempos de acceso a los datos del disco son relativamente lentos comparados con los tiempos de acceso a los datos de la memoria, los DBMS deben estructurar y almacenar los datos de manera que se reduzca la necesidad de mover datos entre el disco y la memoria. En la figura 14 se muestra la estructura general de un sistema administrador de bases de datos: [13]

Figura 14. Estructura general de un sistema administrador de bases de datos.

39

4.3.4.1 El administrador de almacenamiento (Storage Manager) Uno de los módulos o componentes de un sistema de bases de datos es el administrador de almacenamiento el cual, además de proveer la interfaz entre los datos almacenados a bajo nivel y los programas que hacen uso de ellos, es responsable de interactuar con otra parte llamada el manejador o administrador de archivos (file manager), de manera tal de poder almacenar los datos en el disco, usando el sistema de archivos proporcionado por el sistema operativo del equipo. Es una función del administrador de almacenamiento, por lo tanto, traducir declaraciones en lenguaje de manipulación de datos (DML; Data-Manipulation Language) a comandos de bajo nivel compatibles con el sistema de archivos del sistema operativo. El administrador de almacenamiento está formado por una serie de componentes que le permiten almacenar, recuperar y actualizar los datos de una base de datos; éstos son: [13] − El administrador de autorización e integridad (Authorization and Integrity Manager) el cual comprueba que se satisfagan ciertos niveles de integridad y verifica la autorización de los usuarios para acceder a los datos. − El administrador de transacciones (Transaction Manager) el cual asegura que las bases de datos permanezcan en un estado consistente o correcto incluso después de una falla de sistema y que no existan conflictos al ejecutar operaciones en forma concurrente. − El administrador de archivos (File Manager) el cual se encarga de manejar el espacio y la ubicación de los datos en el disco. − El administrador de búferes (Buffer Manager) el cual se encarga de llevar datos desde el disco hasta la memoria principal del equipo, y decide cuántos y cuáles datos deben permanecer en ella. El administrador de búferes es una parte crítica del sistema de bases de datos ya que éste permite que se puedan usar bases de datos que son mucho más grandes que la memoria principal del computador. Generalmente, el administrador de almacenamiento usa tres formas para almacenar los datos en una base de datos, éstas son:

40

− Archivos de datos (Data File), en donde se almacenan los datos propiamente dichos. − Diccionario de datos (Data Dictionary), en donde se almacena información acerca de las bases de datos; en una base de datos relacional, el diccionario de datos almacena las schemas de las bases de datos, es decir, la descripción de cada una de las tablas o relaciones. − Índices (Indexes) que permiten acceder a datos que poseen valores específicos dentro de una base de datos.

4.3.4.2 El procesador de consultas (Query Processor) La importancia del procesador de consultas radica en la capacidad que éste debe tener para simplificar, facilitar y agilizar la búsqueda de datos en las bases de datos. Los componentes de procesador de consultas incluyen: [13] − El interpretador DDL (Data-Definition Language) el cual traduce declaraciones DDL y registra las definiciones en el diccionario de datos. El lenguaje DDL permite definir las schemas de una base de datos. − El compilador DML (Data-Manipulation Language) el cual traduce comandos DML en un lenguaje de consultas a una serie de instrucciones de bajo nivel que conforman un plan de evaluación que debe ser analizado por el evaluador de consultas. Una consulta, generalmente, puede ser ejecutada a través de distintos planes de evaluación, por lo tanto, es una función del compilador DML realizar una optimización de la consulta, es decir, escoger el plan de evaluación que resulte en el menor costo posible. − El motor de evaluación de consultas (query evaluation engine), el cual ejecuta las instrucciones de bajo nivel generadas por el compilador DML. Como se verá más adelante, el DDL y DML también forman parte del lenguaje estructurado de consultas o SQL.

41

4.3.4.3 El administrador de transacciones (Transaction Manager) La importancia de este componente del sistema administrador de bases de datos, como se mencionó anteriormente, es permitir a varios usuarios realizar consultas simultáneamente sin que se produzca una pérdida en la integridad de los datos incluso si el sistema falla repentinamente. Para que las transacciones se ejecuten adecuadamente, el administrador de transacciones debe cumplir con cuatro características fundamentales denominadas propiedades ACID, por sus siglas en inglés. Estas propiedades son: [13] − Atomicidad (Atomicity): Es necesario, que todas las transacciones se ejecuten, o que ninguna lo haga. Esto asegura que ninguna operación realizada puede quedar a medias. − Consistencia (Consistency): Se refiere al estado de una base de datos cuando se inicia y se finaliza una transacción. Existen reglas o limitaciones de integridad o consistencia que no pueden ser rotas por una transacción. Por ejemplo, una limitación o condición de consistencia para una aerolínea puede ser que un asiento no puede ser asignado a dos pasajeros distintos. A pesar de que ésto puede ocurrir durante la asignación de puestos, el administrador de transacciones debe asegurarse de que una vez que hayan finalizado todas las transacciones, dos pasajeros distintos no reciban el mismo asiento. − Aislamiento (Isolation): Cuando dos o más transacciones se ejecutan de forma concurrente o simultánea, sus efectos deben estar aislados entre ellas, es decir, los efectos de dos transacciones ejecutándose simultáneamente, deben ser los mismos a los efectos que se obtendrían si se ejecuta una transacción primero y la otra después. − Durabilidad (Durability): Si una transacción se ha completado exitosamente, sus efectos deberán persistir (no se deben perder) incluso si el sistema falla inmediatamente después de que la transacción haya culminado.

42

4.3.5

Álgebra relacional y sus operaciones El álgebra relacional es un álgebra especial que permite construir nuevas relaciones o

tablas a partir de otras. Una consulta es una expresión de álgebra relacional. Existen cuatro categorías fundamentales en las operaciones de álgebra relacional: [15] − Operaciones típicas de conjuntos: unión, intersección y diferencia, aplicadas a relaciones o tablas. − Operaciones que eliminan parte de una relación: Operación de selección elimina tuples (filas) y la operación de proyección elimina atributos (columnas). − Operaciones que combinan los tuples de dos relaciones, incluyendo el producto Cartesiano, el cual combina dos tuples o filas de dos relaciones distintas en todas las formas posibles, y varios tipos de operaciones de empalme o juntura (join) que combinan tuples de dos relaciones distintas en forma selectiva. − Operaciones de cambio de nombre (rename) que no afectan tuples de la relación sino que cambia la schema de la relación, es decir, se modifican los nombres de los atributos y/o el nombre de la misma relación. Existe otra gran cantidad de operaciones adicionales a las mencionadas anteriormente, como por ejemplo operaciones de eliminación, inserción y actualización, y operaciones de creación de vistas (views). Debido a que no es objetivo de este libro ahondar en lo referente al álgebra relacional ni a la gran variedad de comandos SQL existentes, solamente se mencionará la función de una vista o view ya que éstas son usadas en el desarrollo del proyecto. Una vista o view es una relación o tabla que no existe físicamente en una base de datos, en otras palabras, una vista es una relación virtual de una base de datos [13]. Una vista puede tener varias funciones entre las cuales se pueden mencionar la capacidad de añadir seguridad a los datos y la capacidad de simplificar la complejidad del comando para realizar una consulta. Por ejemplo, la consulta SELECT a1, a2, a3, a4, a5 FROM r1 WHERE a2 = x AND a7 = y, puede servir como seguridad para evitar que un usuario pueda tener acceso a todos los atributos y entidades de la relación “r1” o simplemente es una consulta que se desea

43

realizar. Cada vez que se desee realizar esta consulta, se debe escribir el comando SQL completo. Aquí es donde pueden ser útiles las vistas: CREATE VIEW v1 AS SELECT a1, a2, a3, a4, a5 FROM r1 WHERE a2 = x AND a7 = y. Este comando SQL crea una vista llamada “v1” que ejecuta el mismo comando SQL mencionado al inicio del ejemplo. La creación de esta vista tiene dos funciones. La primera es que podemos restringir al acceso a la relación “r1” y permitir el acceso a la vista “v1”, de esta forma podemos proteger los datos de la relación “r1” que no son utilizados por la vista “v1”. Otra de las funciones es simplificar la ejecución del comando SQL necesitado. Con la creación de la vista, sólo basta con ejecutar SELECT * FROM v1 para obtener los datos del comando SQL definido en la vista. [15]

4.3.6

Lenguaje estructurado de consultas (SQL) El lenguaje estructurado de consultas, SQL (Structured Query Language), es el más

usado en sistemas administradores de bases de datos que usan el modelo relacional. El lenguaje SQL fue desarrollado por IBM y fue denominado originalmente lenguaje SEQUEL al implementarlo como parte del proyecto System-R. Con el paso del tiempo, el lenguaje SEQUEL evolucionó y se convirtió en lo que hoy se conoce como lenguaje SQL. En 1986, el Instituto Nacional Americano de Estándares (ANSI; American National Standards Institute) y la Organización Internacional para la Estandarización (ISO; International Organization for Standarization) desarrollaron el primer estándar SQL denominado SQL-86. Hoy en día el estándar más reciente desarrollado por ANSI / ISO es el SQL:1999, también conocido como SQL3. [13] [15] A pesar de que la mayoría de los sistemas administradores de bases de datos no dan soporte a todas las características especificadas en el estándar SQL:1999, la mayoría de los fabricante dirigen sus esfuerzos para incorporar éstas características en sus sistemas administradores. Es evidente que SQL, siendo el lenguaje más usado actualmente en los sistemas administradores de bases de datos, casi todos los fabricantes ofrecen las características básicas y componentes que se mencionan a continuación: [13] [15]

44

− Lenguaje de definición de datos (DDL; Data-Definition Language): Esta parte de SQL provee los comandos necesarios para crear, borrar o modificar schemas de una relación o tabla. − Lenguaje de manipulación de datos (DML; Data-Manipulation Language): El SQL DML incluye un lenguaje de consulta basado en el álgebra relacional y en el cálculo relacional de tuples. − Definición de vistas (View definition): El SQL DDL incluye comandos que permiten definir vistas o views. Las vistas proporcionan la simplificación de comandos SQL que son ejecutados con frecuencia. − Control de transacción (Transaction control): SQL incluye comandos para especificar el inicio y el final de una transacción. − SQL nativo y SQL dinámico (Embedded SQL and dynamic SQL): Tanto el SQL nativo como el dinámico definen la forma en que las declaraciones SQL pueden ser incorporadas dentro de lenguajes de programación como C, C++, Java, etc. − Integridad (Integrity): El SQL DDL ofrece comandos para especificar limitaciones o exigencias en la integridad o consistencia que deben tener los datos almacenados en la base de datos. Modificaciones que violen esas exigencias, no serán permitidas. − Autorización (Authorization): El SQL DDL incluye comandos para especificar derechos de acceso a relaciones y vistas, es decir, existen comandos que restringen el acceso a los datos basados en permisos y derechos concedidos. Un comando SQL, típico para la búsqueda de información en una base de datos consta generalmente de tres partes. Éstas son: SELECT, FROM y WHERE [13] − La cláusula SELECT corresponde a la operación de proyección del álgebra relacional. − La cláusula FROM corresponde al producto Cartesiano del álgebra relacional. − La cláusula WHERE corresponde a la operación de selección del álgebra relacional. Como se puede ver el término SELECT tiene un significado diferente en lenguaje SQL que en el álgebra relacional. Finalmente a continuación se da un ejemplo de comando SQL:

45

SELECT a1, a2, a3, a4 FROM r1 WHERE a2 = x Este comando selecciona de la relación (tabla) “r1”, solamente los atributos (columnas) “a1”, ”a2”, ”a3” y “a4”, y solamente las entidades (filas) que contengan el valor “x” en el atributo “a2”.

4.3.6.1 Cursores Uno de los principales problemas al tratar de incorporar el lenguaje SQL en otros lenguajes, es que SQL opera directamente sobre conjuntos de registros y el lenguaje C, por ejemplo, no soporta directamente operaciones sobre conjuntos de registros. Por lo tanto se hace necesario en SQL tener un mecanismo que permita recuperar solamente una entidad o fila a la vez. Este mecanismo se conoce como cursor. Un cursor se puede declarar sobre una tabla o relación, o sobre una consulta SQL (ya que toda consulta devuelve filas), por ejemplo, con el comando SQL “DECLARE nombredelcursor CURSOR FOR comandoSQL”. Una vez que se declara un cursor, éste se puede abrir, mover, cerrar o hacer que busque una determinada fila o conjunto de filas, a través de la ejecución de un comando SQL, por ejemplo, “FETCH NEXT FROM nombredelcursor”, comando que busca la siguiente fila de una tabla que contiene un cursor abierto. [12] [13]

4.3.6.2 Transacciones Una transacción es una unidad de ejecución de programa que puede acceder y actualizar varios elementos en una relación [13]. Generalmente, una transacción se inicia cuando el usuario ejecuta un comando SQL, por ejemplo, “START TRANSACTION” y finaliza cuando se ejecuta el comando SQL, por ejemplo, “COMMIT” (Los comandos SQL pueden variar según el DBMS utilizado). La transacción consiste en todos los comandos ejecutados entre el comando “START TRANSACTION” y el comando “COMMIT”.

46

La importancia de las transacciones radica en que el DBMS, deber hacer cumplir las propiedades ACID mencionadas en la sección 4.3.4.3, para garantizar la correcta ejecución de todos los comandos SQL involucrados en la transacción. [13]

4.3.7

Desempeño de un sistema administrador de bases de datos Un administrador de bases de datos (DBA; DataBase Administrator) puede mejorar el

desempeño al modificar los parámetros de un DMBS (por ejemplo, el tamaño del conjunto de búferes o la frecuencia de puntos de verificación) y al identificar y eliminar cuellos de botella en el sistema [12]. Para analizar el desempeño de un sistema de bases de datos, es necesario tomar en cuenta cinco factores: Carga de trabajo, tasa de transferencia o rendimiento, recursos, optimización y contención [11] [12] − Carga de trabajo (Workload): Es una combinación de todas las transacciones, consultas, operaciones y comandos ejecutados en el sistema en un momento dado. Se debe poder describir una carga de trabajo al analizar y observar la lista de consultas y sus frecuencias, la lista de actualizaciones y sus frecuencias, cuáles son las relaciones (tablas) más consultadas o modificadas, cuáles son los atributos (columnas) más consultados o modificados y cuáles son los atributos que tienen condiciones en operaciones de selección o de unión. − Tasa de transferencia (Throughput): Define la capacidad global de procesamiento de datos. Es una mezcla entre la velocidad de los dispositivos de entrada y salida (I/O), velocidad del CPU, capacidades de procesamiento paralelo, eficiencia del sistema operativo y del software. − Recursos (Resources): Son todas aquellas herramientas de hardware y software a disposición del sistema de bases de datos, por ejemplo, núcleo del sistema, dispositivos de almacenamiento, módulos de memoria RAM, controladores de caché, microcódigo del CPU, etc. − Optimización (Optimization): Hace referencia a todos aquellos factores que afectan al sistema de bases de datos en la manera de crear el camino más eficiente para el acceso

47

a los datos, por ejemplo, optimización de consultas, parámetros del sistema y de las bases de datos, etc. − Contención (Contention): Es la condición donde dos o más componentes de la carga de trabajo intentan usar un mismo recurso de una forma conflictiva (por ejemplo, realizar actualizaciones simultáneas a un dato específico). A medida que aumenta la contención, disminuye la tasa de transferencia. En resumen se puede definir el desempeño de un sistema administrador de bases de datos como el uso optimizado de recursos para aumentar la tasa de transferencia y minimizar la contención, permitiendo el procesamiento la carga de trabajo más grande posible.

4.3.7.1 Índices En una forma general, un índice es una estructura de datos que hace más eficiente la búsqueda de información en una tabla. Los índices se asignan a los atributos (columnas) de una relación (tabla), y ayudan en búsquedas o consultas en donde se compare el valor de los atributos con una constante, por ejemplo, atributo1 = constante o incluso atributo1 < constante. Los índices en el modelo relacional de bases de datos, funcionan de manera similar a los índices que se pueden encontrar en los libros de texto. Si se desea encontrar el tema “Modelo Relacional” en un libro, no tiene mucho sentido buscar cada página del libro hasta encontrar el tema deseado. Es mucho más rápido y simple buscar en el índice del libro la frase “Modelo relacional” y el encontrarla, ir directamente a las páginas del libro en donde se encuentra desarrollado el tema “Modelo relacional”. [15] [13] Los índices son especialmente útiles en relaciones o tablas que contienen una gran cantidad de entidades o filas, ya que buscar en toda la relación, por entidades con valores de atributos específicos, resulta una tarea que requiere mucho tiempo. La estructura de un índice es la que ayuda en este tipo de búsquedas, debido a que cada índice está formado por un conjunto de puntos de referencia o claves (index keys) y por un conjunto de apuntadores. El conjunto de claves del índice o index keys, son todos los posibles valores, diferentes, del atributo al cual está asignado el índice. El conjunto de apuntadores son datos de cada index

48

key, en donde se indica el o los lugares en la relación que contienen el valor especificado en el index key. Esto se puede ver con un ejemplo: Si se tiene una relación que contiene datos acerca de películas de cine, como por ejemplo el título de la película, el año de estreno, el tipo de película, la clasificación de la película, etc. Al atributo “año de estreno” contiene valores que van desde 1980 hasta 2006. Obviamente, existen entidades o filas en las que el valor para “año de estreno” puede ser igual. Si se define un índice en esta columna “año de estreno”, entonces las claves de índices o index key tendrán valores de por ejemplo, 1981, 1990, 2000, 2001, etc., es decir, tendrán los valores de todos los años de estreno diferentes que aparezcan en la columna “año de estreno”. Cada index key tendrá asociado un conjunto de apuntadores dependiendo del valor de la columna “año de estreno” al cual se haga referencia, es decir, si un index key hace referencia al valor 1990 de la columna “año de estreno”, entonces éste index key tendrá asociados todos los apuntadores que indiquen cuales son las filas de la tabla que tienen en la columna “año de estreno” el valor 1990. Para buscar todas las películas estrenadas en el año 1990 sólo es necesario buscar el index key que haga referencia a este valor, y luego buscar las filas indicadas por los apuntadores del index key. Se puede ver claramente que éste método de búsqueda es mucho más rápido y eficiente, que leer cada fila de la tabla, en la que pueden haber cientos de miles de películas, y escoger las películas estrenadas en 1990 a medida que se vayan encontrando. [12] [13] [14] [15]

4.4 Visual Basic y el acceso a bases de datos Para poder hablar de cómo hace Visual Basic para acceder a los datos de un sistema administrador de bases de datos, es necesario entender la arquitectura cliente-servidor de éstos. En una forma general, una arquitectura cliente-servidor hace referencia a un equipo que ha hace uso de recursos o servicios, el cliente, y a un equipo que provee servicios, el servidor, en otras palabras, el cliente se encarga de la interacción con el usuario, y el servidor se encarga del procesamiento de datos. La figura 15 muestra la arquitectura cliente-servidor al usar una base de datos.

49

Figura 15. Arquitectura cliente/servidor en la comunicación con una base de datos. [15] Un proceso cliente-servidor se inicia cuando el cliente interactúa con un usuario y envía una petición al servidor. Éste se encarga de recibir, programar y ejecutar la petición recibida y selecciona solamente aquellos datos necesitados por el cliente. El servidor envía los datos al cliente sólo cuando éste lo solicita. A continuación se presentan ventajas y desventajas de una arquitectura cliente-servidor: [14] Ventajas − Suele tener un menor costo que soluciones que involucren un minicomputador o un computador central (mainframe). − Permite al usuario utilizar las interfaces gráficas (GUI; Graphical User Interface) del microcomputador lo cual mejora la funcionalidad y simplicidad. − Existe mayor cantidad de personas con habilidades para usar un microcomputador (PC) que un minicomputador o un mainframe. − El PC está bien establecido en los lugares de trabajo. − Existe una gran variedad de herramientas disponibles para PC que permiten una fácil interacción con numerosos DBMS. − Hay una ventaja considerable de costo al trasladar el desarrollo de aplicaciones de los mainframes a los PC. Desventajas − Se crea un ambiente más complicado en donde diferentes plataformas (LANs, sistemas operativos, etc.) son difíciles de administrar. − Un aumento en el número de usuarios usualmente genera las condiciones necesarias para que aparezcan problemas de seguridad.

50

− Se hace posible expandir el acceso a los datos a un círculo de usuarios mucho más amplio. Esto aumenta la demanda de personas con un amplio conocimiento de computadores y aplicaciones de software. Los costos para mantener éstas condiciones aumentan debido a la carga de entrenar personal.

Para que Visual Basic pueda establecer una comunicación con un sistema administrador de bases de datos, es necesario que exista un componente fundamental entre el DBMS y la aplicación de Visual Basic. Este componente se denomina ODBC.

4.4.1

Interfaz ODBC Las siglas ODBC significan Open DataBase Connectivity y hacen referencia a un

estándar desarrollado por Microsoft que permite acceder a cualquier dato desde cualquier aplicación, sin importar el DBMS que almacene los datos [16]. ODBC habilita la integración de SQL en lenguajes de propósito general como C y expone las capacidades de un sistema administrador de bases de datos a través de una interfaz de programación de aplicación (API; Application Programming Interface). A diferencia del lenguaje SQL nativo, ODBC permite el acceso a diferentes DBMS sin la necesidad de recompilar el DBMS. Además, con el uso de ODBC, una aplicación puede acceder a los datos de varios DBMS simultáneamente. [12] ODBC logra alcanzar su gran flexibilidad al introducir un nivel adicional en la interacción entre la aplicación y el DBMS. Cualquier interacción directa con el DBMS deberá pasar por un controlador o driver específico para cada DBMS. Un controlador o driver ODBC, debe ser capaz de traducir las llamadas a funciones o procedimientos ODBC, en llamadas a funciones o procedimientos, específicas para el DBMS para el que fue diseñado. [12] Una aplicación que interactúa con un origen de datos a través de ODBC debe realizar los siguientes pasos: Seleccionar un origen de datos (puede ser un archivo de texto, una hoja de cálculo o un sistema administrador de bases de datos (DBMS)), cargar dinámicamente el controlador adecuado y establecer la conexión con el origen de dato. Mientras la conexión permanezca abierta, se pueden realizar transacciones a través de comandos SQL, recuperar

51

resultados, procesar errores y finalmente ejecutar (commit) o deshacer (rollback) las transacciones realizadas. Por último, la aplicación debe desconectarse del origen de datos para finalizar la interacción. [12]

4.4.1.1 Arquitectura de ODBC La arquitectura de ODBC tiene cuatro componentes principales: La aplicación (Application), el administrador de controladores (Driver Manager), los controladores específicos para cada origen de datos (ODBC Driver) y los orígenes de datos propiamente dichos (Data Source). La figura 16 muestra los cuatro componentes de la arquitectura ODBC. [17]

Figura 16. Arquitectura de ODBC.

La aplicación se encarga de iniciar y terminar las conexiones con el origen de datos y debe enviar consultas y recuperar sus resultados, todo esto a través de interfaces bien definidas por el API ODBC. El objetivo principal del administrador de controladores es cargar los controladores ODBC necesarios y pasar todas las llamadas a funciones desde la aplicación al controlador adecuado. Además, el administrador de controladores debe inicializar la interfaz ODBC, permitir apuntar o anotar las llamadas a funciones realizadas y debe hacer verificación de errores. El controlador establece la conexión con el origen de datos y además de enviar consultas y recibir los resultados, debe traducir los datos, códigos de error, etc., de una forma

52

que es específica para cada origen de datos al estándar ODBC. Finalmente, el origen de datos es quien procesa y recibe los comandos del controlador y entrega los resultados necesarios.

4.4.2

Métodos de acceso a orígenes de datos Visual Basic puede usar varios métodos para interactuar con un origen de datos a

través de ODBC. Tres de los métodos más comunes son: RDO, DAO y ADO. Como no es objetivo discutir las ventajas y desventajas de cada uno de estos métodos, solamente se presentará una breve descripción de ellos. [18] [19] [20] − DAO (Data Access Objects): Fue la primera interfaz orientada a objeto que expuso el motor de bases de datos Microsoft Jet (usado por Microsoft Access) y permitió a los programadores de Visual Basic conectarse directamente a tablas de Access, al igual que otras bases de datos, a través de ODBC. DAO se adapta mejor a aplicaciones bajo sistemas únicos o para desarrollos pequeños y locales. − RDO (Remote Data Objects): Es una interfaz a ODBC para el acceso a datos orientada a objetos que provee virtualmente toda la funcionalidad y flexibilidad del bajo nivel de ODBC. RDO no maneja muy bien bases de datos Jet o ISAM y solamente puede acceder a bases de datos relacionales a través de controladores ODBC. − ADO (Activex Data Objects): ADO es el sucesor de DAO/RDO y transforma el modelo de éstos para obtener menos objetos y más propiedades, métodos y eventos. La funcionalidad de ADO es más similar a la de RDO, sin embargo, se basa en la interfaz OLE DB para acceder a orígenes de datos (generalmente a través del proveedor de funcionalidades OLE DB para controladores ODBC de Microsoft). En la figura 17 se muestra la arquitectura MDAC (Microsoft Data Access Components) en donde aparecen las diferentes interfaces entre ADO y un origen de datos. [21]

53

Figura 17. Arquitectura MDAC. Según [22], DAO trabaja mejor con bases de datos que el motor Microsoft Jet puede leer, estas bases de datos no incluyen los orígenes de datos ODBC. Debido a que Microsoft no tiene planeado hacer desarrollos adicionales a RDO, y a que se recomienda a los usuarios que usen los objetos ADO en lugar de los RDO [23], los programas desarrollados durante la ejecución del proyecto de grado presentado en este libro se hicieron usando ADO. Una importante característica entre ADO, RDO y DAO es que, según [24] y [25], RDO y DAO son ya tecnologías obsoletas y no serán compatibles o no estarán disponibles para sistemas con procesadores de 64-bits, como lo será ODBC y ADO.

5. METODOLOGÍA La estrategia metodológica usada durante el desarrollo de este proyecto de grado se fundamentó en el diseño de etapas secuenciales que permitieran lograr todos los objetivos planteados. El proyecto se dividió en 14 etapas diferentes las cuales se mencionan a continuación:

5.1

Investigación preliminar Durante esta primera etapa se identificaron claramente las necesidades, problemas,

limitaciones y alcance del proyecto así como también los recursos disponibles para desarrollar el mismo. Para lograr el desenvolvimiento adecuado del proyecto es necesario recopilar toda la información posible acerca del funcionamiento de la empresa. En este sentido, se indagó acerca de las políticas, normas y procedimientos que se deben cumplir tanto en la Coordinación de Optimización como en la corporación Digitel GSM. En esta etapa también se incluye la identificación del personal de la Coordinación de Optimización y de todas aquellas personas involucradas en el proyecto además de los recursos usados por el personal para realizar el trabajo del día a día. También se identificaron procedimientos manuales llevados a cabo por el personal de la Coordinación de Optimización que pudieran ser automatizados, específicamente el procedimiento para realizar el cálculo de las adyacencias de una BTS.

5.2

Análisis preliminar de las herramientas y bases de datos Con el objetivo de iniciar rápidamente el desarrollo del proyecto, en esta etapa se

estudiaron, analizaron e identificaron los componentes críticos en las herramientas de trabajo usadas por la Coordinación de Optimización así como también el funcionamiento básico y el uso regular de las mismas.

55

Un análisis básico acerca de la estructura y el uso de las bases de datos permitió identificar las bases de datos y consultas que necesitan mayor procesamiento al momento de ser ejecutadas o utilizadas. Se realizó un estudio preliminar acerca del lenguaje de programación usado para desarrollar las herramientas existentes, para poder implementar el programa de pruebas bajo el mismo lenguaje y así obtener resultados compatibles con los obtenidos por las herramientas.

5.3

Migración inicial de las bases de datos Para poder desarrollar el programa de pruebas, luego de identificar las consultas más

frecuentes y las bases de datos más usadas, se llevó a cabo la migración de éstas bases de datos a los dos administradores de licencia libre (PostgreSQL y MySQL) escogidos. Además, debido a una de las necesidades por parte de la Coordinación de Optimización, se instalaron los administradores de bases de datos bajo sistemas operativos (OS u Operating System) Windows como Linux.

5.4

Desarrollo inicial del programa de pruebas El análisis preliminar de las herramientas y bases de datos sirvió como base para el

diseño y desarrollo inicial del programa de pruebas y de las pruebas necesarias para comparar los administradores de bases de datos. La herramienta o programa de pruebas desarrollado en Visual Basic 6 se diseñó para que se pudieran realizar conexiones y consultas a los tres administradores de bases de datos (Microsoft Access, MySQL y PostgreSQL) y se pudieran visualizar los tiempos de ejecución de las consultas realizadas. La herramienta desarrollada también permite realizar diferentes tipos de consulta, cambiar parámetros de conexión a las bases de datos y modificar los controladores o drivers ODBC (Open DataBase Connectivity) usados para realizar la conexión a los administradores.

56

5.5

Ejecución de las pruebas preliminares a los administradores de bases de datos Durante esta fase, se realizaron pruebas preliminares comparativas a los

administradores de bases de datos con el fin de obtener rápidamente una diferenciación entre los mismos. Las pruebas se basaron en los análisis previamente realizados y consistieron fundamentalmente en realizar diferentes consultas a los administradores de bases de datos y medir los tiempos de procesamiento de datos.

5.6

Análisis de las pruebas preliminares a los administradores de bases de datos En esta etapa se identificaron las diferencias más resaltantes en los resultados

obtenidos al ejecutar las pruebas preliminares a los administradores de bases de datos. Estas diferencias encontradas junto con sus posibles causas se investigaron en la siguiente etapa.

5.7

Investigación detallada acerca de los administradores de bases de datos, sistemas operativos, conexiones de red, controladores o drivers y lenguaje de programación Luego del análisis de los resultados preliminares a los administradores de bases de

datos, se investigó en detalle el funcionamiento de éstos así como también el de los componentes y factores involucrados en su uso como lo son el sistema operativo, la conexión de red, el lenguaje de programación y el controlador para lograr la conexión a las bases de datos. La investigación se enfocó principalmente en identificar los parámetros de los factores antes mencionados que pudieran afectar la velocidad de procesamiento de los administradores de bases de datos.

57

5.8

Ejecución de las pruebas finales a los administradores de bases de datos Luego de realizarse una investigación detallada acerca del funcionamiento de los

administradores de bases de datos y de los parámetros que afectan su velocidad de procesamiento, se realizaron pruebas en donde se ejecutaron diferentes consultas con diferentes parámetros de configuración de manera de comparar y establecer el administrador más adecuado para la Coordinación de Optimización. Las pruebas incluyeron cambios en: La configuración de MySQL y PostgreSQL, los parámetros de funcionamiento del sistema operativo Linux, las conexiones de red, los controladores de conexión a los administradores (controladores ODBC), las consultas realizadas por el programa de pruebas y el método usado en el programa de prueba para consultar información en las bases de datos.

5.9

Análisis de las pruebas finales a los administradores de bases de datos El análisis se basó principalmente en comparar los tiempos de procesamiento de datos

de los diferentes administradores y seleccionar la configuración de aquel que resultó realizar el procesamiento de datos en menor tiempo.

5.10 Modificaciones a las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización Luego de seleccionar el administrador de bases de datos que ofreciera menores tiempos de respuesta, se procedió a modificar las herramientas para que fueran capaces de trabajar con el nuevo administrador de bases de datos. También se modificaron las herramientas para eliminar redundancia de variables y código, eliminar variables y funciones innecesarias, crear funciones o realizar modificaciones para compactar el código, sin embargo, la modificación más significativa fue la de crear el código capaz de realizar las conexiones y consultas a las bases de datos.

58

5.11 Pruebas finales a las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización Fundamentalmente durante esta etapa de pruebas, se corroboró el funcionamiento adecuado de las herramientas, es decir, que los datos procesados se obtuvieran en menor tiempo y que la información presentada estuviera acorde con la información procesada por versiones anteriores de las herramientas.

5.12 Investigación detallada acerca del procedimiento para el cálculo de las adyacencias de una BTS Durante esta etapa se recopiló toda la información acerca del procedimiento manual que realiza el personal de la Coordinación de Optimización para calcular las adyacencias de una BTS. Además, se investigó acerca de los modelos y ecuaciones matemáticas necesarias para desarrollar la herramienta.

5.13 Desarrollo de la herramienta para el cálculo automático de las adyacencias de una BTS Basado en la investigación previamente realizada, se desarrolló en Visual Basic 6 la herramienta para el cálculo de las adyacencias. Esta herramienta debe ser capaz de calcular la distancia entre dos BTS cualquiera, calcular el área de cobertura de cualquier BTS, los puntos de intersección entre las áreas de cobertura de dos BTS cualquiera y por supuesto, las adyacencias de una BTS. Los cálculos se realizan con datos provenientes de una base de datos y datos introducidos por el usuario. Además, la herramienta es capaz de agregar, modificar o eliminar una BTS o información de la misma de la base de datos.

59

5.14 Ejecución de las pruebas a la herramienta para el cálculo automático de las adyacencias de una BTS En esta fase se comprueba que las adyacencias calculadas al usar la herramienta coincidan en más del 50% con las adyacencias actualmente definidas para cada BTS. Si una BTS posee 10 adyacencias definidas por el personal de la Coordinación de Optimización, al menos 5 de estas adyacencias deben ser iguales a las calculadas con la herramienta. Esta metodología basada en la metodología de ensayo y error, se utilizó debido a la rapidez que ofrece al desarrollar un proyecto. Debido a la inmensa cantidad de información y conocimientos que involucra el configurar y administrar un sistema de bases de datos y un sistema operativo, es imposible, en un período de 3 meses, adquirir todos los conocimientos necesarios para configurar correctamente un servidor de bases de datos. La metodología usada en este proyecto, permite adquirir los conocimientos necesarios para resolver e identificar problemas tanto en la configuración de un administrador de bases de datos como en la estructura de las bases de datos siempre que los comandos o consultas que sean procesadas por el administrador de bases de datos, sean similares a las realizadas por las herramientas de la Coordinación de Optimización, es decir, las consultas sean fundamentalmente selecciones y búsqueda de información en las bases de datos. Además, la metodología diseñada para desarrollar el proyecto que se presenta en este libro, permite enfocar todos los esfuerzos y recursos a resolver el problema principal y lograr los objetivos planteados de la manera más rápida posible, en otras palabras, se utilizó el principio de Pareto o la regla 80/20, en donde se dice que el 20% de cualquier cosa producirá el 80% de los efectos, y el otro 80% solamente producirá un 20% de resultados, por lo tanto, durante el desarrollo del proyecto se identificó y se concentraron los esfuerzos en ese 20%. [11] [26]

6. ESTUDIO COMPARATIVO ENTRE TRES ADMINISTRADORES DE BASES DE DATOS La Coordinación de Optimización de la corporación Digitel GSM, se ha visto en la necesidad de almacenar y procesar cada vez mayor cantidad de información debido al constante crecimiento y expansión de la red celular sobre la cual trabaja. Analizar y mejorar el desempeño y funcionamiento de la red celular, trabajo que se lleva a cabo en la Coordinación de Optimización, es fundamental para posicionar a la empresa como líder entre sus competidores. Este trabajo de análisis se debe realizar constantemente y con la mayor rapidez posible de manera tal de que los problemas que se presenten en la red celular, sean atendidos y solucionados en el menor tiempo posible, brindando así una mejor calidad de servicio a los usuarios de la red. El crecimiento de la red celular de Digitel GSM, para la Coordinación de Optimización, está relacionado con un crecimiento en la cantidad de información que ésta debe almacenar, procesar y analizar. El personal de la Coordinación de Optimización desarrolló un conjunto de herramientas y bases de datos para facilitar la tarea de análisis del desempeño de la red, sin embargo, estas herramientas y bases de datos no se diseñaron para procesar grandes cantidades de información. El objetivo de este estudio es poder seleccionar un administrador de bases de datos que sea de licencia libre que sea capaz de procesar información con mayor rapidez que el administrador que actualmente usa la Coordinación de Optimización. Este estudio comparativo comprende las primeras 9 etapas de la metodología para desarrollar el proyecto de grado que se expone en este libro.

6.1

Condiciones previas Antes de iniciar el estudio comparativo fue necesario identificar los recursos

disponibles y las condiciones especiales para la ejecución del mismo. En este sentido, se estableció la condición de que los administradores de bases de datos de licencia libre se debían probar bajo un sistema operativo Linux, ya que las bases de datos de muchas de las

61

Coordinaciones (incluyendo la Coordinación de Optimización) del Departamento de Operaciones de Digitel GSM serán migradas a un servidor en el cual se instalarán exclusivamente programas de licencia libre. Para la ejecución y desarrollo del estudio comparativo se dispuso de tres computadores con las siguientes características: Computador 1 − Procesador: Pentium III 1000 MHz − Memoria RAM: 1024 MB − Sistema Operativo: Microsoft Windows 2000 Computador 2 − Procesador: Intel Pentium III 866 MHz − Memoria RAM: 256 MB − Sistema Operativo: Basado en Linux (Debian 3r1, Red Hat 8, SUSE 10 para x86-32) Computador 3 − Procesador: Intel Pentium 4 Dual Core 3 GHz / 800 MHz − Memoria RAM: 768 MB − Sistema Operativo: Microsoft Windows XP Una limitación encontrada durante el desarrollo de este estudio fue la asignación inamovible del uso de estos tres computadores. El computador 1 es un servidor basado en Windows 2000 en el cual están ubicadas las bases de datos de la Coordinación de Optimización. El computador 2 es un servidor basado en Linux en donde se realizarán las pruebas de los nuevos administradores de bases de datos de licencia libre. El computador 3 es una estación de trabajo de donde se administran las bases de datos. Los administradores de bases de datos que serán sometidos a una comparación se presentan a continuación junto con sus requerimientos: [27] [28] [29] [30]

62

Microsoft Access 2002 (Office XP) − Equipo y Procesador: Computador con un procesador Pentium 133 megahertz (MHz) o superior; se recomienda Pentium III. − Memoria: Para todos los paquetes de Office XP los requerimientos de memoria RAM dependerán del sistema operativo usado: o Windows 98, o Windows 98 Second Edition: 24 MB de RAM y adicionalmente, 8 MB de RAM por cada programa de Office (como Microsoft Word) que se ejecute simultáneamente. o Windows Me, o Microsoft Windows NT®: 32 MB de RAM y adicionalmente, 8 MB de RAM por cada programa de Office (como Word) que se ejecute simultáneamente. o Windows 2000 Professional: 64 MB de RAM y adicionalmente, 8 MB de RAM por cada programa de Office (como Word) que se ejecute simultáneamente. o Windows XP Professional, o Windows XP Home Edition: 128 MB de RAM y adicionalmente, 8 MB de RAM por cada programa de Office (como Word) que se ejecute simultáneamente. − Disco duro: Los requerimientos de espacio en el disco duro varían dependiendo de la configuración; las opciones en una instalación personalizada pueden necesitar más o menos. A continuación se muestran los requerimientos mínimos de los paquetes de Office XP: o Office XP Standard: 210 MB de espacio disponible en el disco duro. o Office XP Professional y Professional Special Edition: 245 MB de espacio disponible en el disco duro. o Se requieren 115 MB adicionales en el disco duro donde está instalado el sistema operativo. Los usuarios sin Windows XP, Windows 2000, Windows Me, u Office 2000 Service Release 1 (SR-1) necesitan 50 MB más de espacio en el disco duro para actualización de archivos de sistema (System Files Update)

63

− Sistema Operativo: Windows 98, Windows 98 Second Edition, Windows Millennium Edition (Windows Me), Windows NT 4.0 con Service Pack 6 (SP6) o posterior, Windows 2000, o Windows XP o posterior. − Pantalla: Super VGA (800 × 600) o monitor con 256 colores de mayor resolución.

MySQL 5.0 − Los recursos usados por MySQL son determinados por el tamaño de las bases de datos y por la configuración de los parámetros del DMBS. A medida que el tamaño de las bases de datos crece, MySQL necesitará más memoria, más velocidad de procesador, más espacio en el disco duro. Sin embargo, el uso de recursos puede ser limitado por el administrador del sistema modificando la configuración del DBMS. − Sistema Operativo: PostgreSQL es capaz de trabajar bajo diversos sistemas operativos entre los cuales se pueden mencionar: [29] o Linux o Windows o Linux 2.0+ con LinuxThreads 0.7.1+ o glibc 2.0.7+ para distintos tipos de arquitecturas de CPU. o Windows 9x, Me, NT, 2000, XP, and Windows Server 2003.

PostgreSQL 8.0 − Los recursos usados por PostgreSQL son determinados por el tamaño de las bases de datos y por la configuración del DBMS. A medida que el tamaño de las bases de datos crece, PostgreSQL necesitará más memoria, más velocidad de procesador, más espacio en el disco duro. Sin embargo, el uso de recursos puede ser limitado por el administrador modificando la configuración del DBMS.

64

− Sistema Operativo: PostgreSQL es capaz de trabajar bajo diversos sistemas operativos entre los cuales se pueden mencionar: [30] o Linux o Windows

6.2

Migración de las bases de datos necesarias para el programa de pruebas Luego de realizar un análisis preliminar sobre las herramientas y bases de datos se

determinó que se migrarían los siguientes componentes de las bases de datos: Tablas − TABLA_GENERAL_GPRS (estadísticas_gprs.mdb) − adjacent_cell (parametros en linea.mdb) − bcf (parametros en linea.mdb) − bsc (parametros en linea.mdb) − bts (parametros en linea.mdb) − handover_control (parametros en linea.mdb) − objects (parametros en linea.mdb) − power_control (parametros en linea.mdb) − trx (parametros en linea.mdb) Vistas o Views − bcf_id (parametros en linea.mdb) − bsc_id (parametros en linea.mdb) − bts_id (parametros en linea.mdb) − bts_id_bsc_id_name (parametros en linea.mdb) − hoc_id (parametros en linea.mdb) − par_adj_cell (parametros en linea.mdb) − par_bts (parametros en linea.mdb)

65

− par_hoc (parametros en linea.mdb) − par_poc (parametros en linea.mdb) − par_trx (parametros en linea.mdb) − poc_id (parametros en linea.mdb) − trx_id (parametros en linea.mdb)

6.2.1

Problemas antes de migrar las bases de datos Debido a la necesidad de la Coordinación de Optimización de migrar las bases de

datos a un administrador que funcione bajo un sistema operativo Linux, el primer paso que se llevó a cabo fue realizar la instalación de los administradores de bases de datos en cada uno de los computadores en donde se realizaron las pruebas, es decir, tanto MySQL como PostgreSQL se instalaron en el computador 1 bajo Windows 2000 y en el computador 2 bajo Linux. Esta necesitad de usar sistemas operativos Linux se creó debido a la adquisición de un servidor HP Blade que será usado no sólo por la Coordinación de Optimización, sino por el resto de las coordinaciones del Departamento de Optimización de Digitel GSM. Todas las bases de datos serán migradas, a corto plazo, a este servidor cuyas capacidades de almacenamiento, memoria y procesamiento son mayores que cualquiera de los servidores utilizados actualmente por cualquiera de las coordinaciones del Departamento de Operaciones de Digitel GSM. Durante este proceso de instalación se presentaron problemas que postergaron una semana, aproximadamente, la migración de las bases de datos y el desarrollo de la herramienta de pruebas. A continuación se describen los problemas que se encontraron:

Actualización del sistema operativo Red Hat Linux 8 El computador 2 inicialmente tenía como sistema operativo Red Hat Linux 8. Este sistema operativo no permite ni la instalación de PostgreSQL (versiones superiores a la 7.3) ni la de MySQL (versiones posteriores a la 3.23). Esto se debe a que el núcleo o kernel y las

66

librerías del sistema operativo no están actualizadas para realizar la instalación de estos programas. La actualización de las librerías y del kernel de Red Hat Linux 8 requirió un arduo trabajo de investigación y documentación, y a pesar de que se logró instalar exitosamente PostgreSQL 8.0 y MySQL 4.1, se decidió instalar otro sistema operativo Linux debido a que la actualización de Red Hat Linux 8 debía ser ejecutada por el personal de la Coordinación de Optimización el cual no tiene experiencia usando sistemas operativos Linux.

Instalación de dos sistemas operativos Linux; Debian y SUSE El sistema operativo Linux Debian se instaló por recomendación de personas dentro del Departamento de Operaciones pero fuera de la Coordinación de Optimización debido a su mejor estabilidad y desempeño. Linux Debian realiza la instalación por defecto de las versiones 3.23 de MySQL y 7.3 de PostgreSQL. A través del administrador de paquetes de Debian (apt-get) se puede obtener la versión 4.1 de MySQL y la 7.4 de PostgreSQL, sin embargo, luego de realizar la instalación de Linux Debian se descubrió que a pesar de que el núcleo del sistema operativo era una versión actualizada, existían librerías desactualizadas necesarias para la instalación de versiones superiores de MySQL y PostgreSQL. Aunque esta actualización necesaria no era complicada y no requería de mucho tiempo para realizarla, se decidió instalar el sistema operativo SUSE Linux 10.1 luego de realizar una investigación acerca de la gran variedad de sistemas operativos Linux existentes y disponibles. Se escogió SUSE Linux principalmente debido a que las versiones del núcleo y de las librerías instaladas son las más recientes. Existen otros motivos como facilidad de manejo y de actualización, que motivaron la selección definitiva de SUSE Linux 10.1 como sistema operativo para el sistema administrador de bases de datos de la Coordinación de Optimización.

67

Versión 5.0 o superior de MySQL La necesidad de tener que instalar versiones de MySQL posteriores a la 5.0 surgió debido a que las bases de datos de la Coordinación de Optimización utilizan vistas para consultar las tablas de las bases de datos. Las vistas son un recurso que se introduce a partir de la versión 5.0 de MySQL [29] y permiten realizar o ejecutar consultas de forma abreviada. El concepto de vista se mencionó en el capítulo 4, sin embargo, a continuación se muestra otro ejemplo de cómo funciona una vista. Si se tiene la consulta: SELECT columna1, columna2, columna3, columna4, columna5 FROM tabla1 WHERE columna3=ciertovalor Cada vez que se quiera ejecutar esta consulta, obviamente se debe escribir todo el comando completo. La ventaja de definir o crear una vista como la que se muestra a continuación, CREATE OR REPLACE VIEW vista1 AS SELECT columna1, columna2, columna3, columna4, columna5 FROM tabla1 WHERE columna3=ciertovalor es que cada vez que se quiera ejecutar la consulta, solamente de deberá escribir: SELECT * FROM vista1

6.3

Desarrollo del programa de pruebas Luego de realizar una migración inicial de las bases de datos, es decir, se migraron las

tablas y consultas más utilizadas, se procedió a desarrollar el programa en Visual Basic 6 con el cual se compararon los tres administradores de bases de datos; Microsoft Access, MySQL y PostgreSQL.

68

Este programa se desarrolló de manera tal que se pudieran consultar los tres administradores de bases de datos a través de una misma interfaz gráfica, y que se pudieran visualizar los tiempos transcurridos después de enviar una consulta o comando SQL a los DBMS. En la figura 18 se muestra la interfaz gráfica del programa usado para comparar la velocidad de procesamiento de los administradores de bases de datos.

Figura 18. Interfaz gráfica del programa de pruebas desarrollado con Visual Basic 6 para la comparación de los tres DBMS.

Como se mencionó en el capítulo 4, Visual Basic 6 es capaz de acceder a datos de diferentes fuentes (archivos, bases de datos, etc.) usando tres métodos distintos: A través del uso de objetos RDO, a través del uso de objetos DAO o a través del uso de objetos ADO.

69

También se mencionó en el capítulo 4 que de acuerdo con [25] y [26], ADO es más poderoso y que RDO y DAO son tecnologías obsoletas. Por esto se escogió ADO. Para realizar una conexión exitosa desde un programa de Visual Basic a una base de datos de Microsoft Access, MySQL o PostgreSQL es necesario que el computador que ejecuta el programa de Visual Basic tenga los controladores ODBC necesarios para efectuar la conexión. Por lo tanto, en el computador 3 se instalaron los controladores ODBC más recientes tanto de MySQL (ODBC versión 3.51) y PostgreSQL (ODBC versión 08.02.0002). Para crear las conexiones con las bases de datos, ADO permite al programador usar lo que se denomina como nombre de origen de datos (DSN o Data Source Name), que es simplemente el nombre, la descripción y el controlador que se debe usar para conectarse a un origen de datos. Se decidió crear la conexión a las bases de datos sin usar un DSN ya que de esta forma se pueden controlar y variar los parámetros de los controladores desde el programa de Visual Basic. Además, para realizar una conexión con DSN es necesario que cada computador que ejecute el programa, deba tener creado el mismo DSN. Ésto, además de ser engorroso, es indeseable si los usuarios que harán uso de las herramientas, tienen poca experiencia en manejar la configuración de sistemas operativos Windows. A continuación se muestra un ejemplo del código desarrollado para crear las conexiones a las bases de datos: Set MySQLconn = New ADODB.Connection Set PostgreSQLconn = New ADODB.Connection Set Accessconn = New ADODB.Connection Set SQLrs = New ADODB.Recordset ADOCursor = adUseServer MySQLconn.CursorLocation = ADOCursor MySQLconn.ConnectionString = ”SERVER=10.21.10.100;PORT=4915;DATABASE=gprs_statistics;UID=invitado;PWD=invi tado;DRIVER={MySQL ODBC 3.51 Driver}; OPTION=43;” MySQLconn.Open ‘ MySQLconn.ConnectionString = “DSN=MySQL”

70

PostgreSQLconn.CursorLocation = ADOCursor PostgreSQLconn.ConnectionString = “SERVER=10.21.10.100;PORT=4916;DATABASE=optimizacion;UID=invitado;PWD=invit ado;DRIVER={PostgreSQL};SSLmode=disable;ReadOnly=0;Protocol=7.41;FakeOidIndex=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSettin gs=;Fetch=100;Socket=8192;UnknownSizes=0;MaxVarcharSize=254;MaxLongVarcharSize =8190;Debug=0;CommLog=0;Optimizer=1;Ksqo=1;UseDeclareFetch=0;TextAsLongVarch ar=1;UnknownsAsLongVarchar=1;BoolsAsChar=1;Parse=1;CancelAsFreeStmt=0;ExtraSys TablePrefixes=_dd;LFConversion=0;UpdatableCursors=1;DisallowPremature=0;TrueIsMin us1=1;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=0;LowerCaseIdentifier=0;” PostgreSQLconn.Open ‘ PostgreSQLconn.ConnectionString = “DSN=PostgreSQL” Accessconn.CursorLocation = ADOCursor Accessconn.ConnectionString = “Driver={Microsoft Access Driver (*.mdb)};DBQ=T:\BTS_DATA_B.mdb” Accessconn.Open ‘ Accessconn.ConnectionString = "DSN=MSAccess" En el código anterior se muestra la diferencia entre una conexión con DSN (las líneas que empiezan con ‘) y una conexión sin DSN. Como se puede ver, a pesar de que al usar DSNs el código se simplifica y se hace más fácil, no se pueden controlar los parámetros de los controladores ODBC a través de variables en el programa. Luego de crear y establecer las conexiones con los tres administradores de bases de datos, el programa de pruebas, a través de campos de texto y botones envía las consultas deseadas a los diferentes administradores de bases de datos. La interfaz gráfica se explica a continuación: (hacer referencia a la figura 18)

71

− Botón “Connect to MySQL”: Con este botón se envía una consulta al administrador de base de datos MySQL. Las consultas tienen la siguiente estructura: SELECT columna FROM tabla donde la variable columna se obtiene del primer cuadro de texto bajo el nombre o etiqueta “Query column” y la variable tabla se obtiene del primer cuadro de texto bajo el nombre o etiqueta “Query table or view”. − Botón “Connect to PostgreSQL”: Con este botón se envía una consulta al administrador de base de datos PostgreSQL. Las consultas tienen la siguiente estructura: SELECT columna FROM tabla donde la variable columna se obtiene del segundo cuadro de texto bajo el nombre o etiqueta “Query column” y la variable tabla se obtiene del segundo cuadro de texto bajo el nombre o etiqueta “Query table or view”. − Botón “Connect to Access”: Con este botón se envía una consulta al administrador de base de datos Microsoft Access. Las consultas tienen la siguiente estructura: SELECT columna FROM tabla donde la variable columna se obtiene del tercer cuadro de texto bajo el nombre o etiqueta “Query column” y la variable tabla se obtiene del tercer cuadro de texto bajo el nombre o etiqueta “Query table or view ”. − Botón “Clear datagrid”: Este botón sirve para borrar los datos de la tabla que muestra la información obtenida luego de ejecutar una consulta. − Botón “Reset”: Este botón cierra el programa (cerrando las conexiones a los administradores de bases de datos) y seguidamente lo reinicia (abriendo las conexiones a los administradores de bases de datos). − Botón “Change PostgreSQL ODBC Driver Settings”: Este botón permite cambiar los parámetros del controlador ODBC de PostgreSQL. − Cuadro de texto “Text1”: Este cuadro de texto ubicado debajo del nombre “MySQL query time” muestra el tiempo que transcurre entre el envío de un comando SQL o consulta al administrador de bases de datos MySQL y la finalización de su ejecución. No se toma en cuenta el tiempo transcurrido para mostrar los datos. − Cuadro de texto “Text2”: Este cuadro de texto ubicado debajo del nombre “PostgreSQL query time” muestra el tiempo que transcurre entre el envío de un comando SQL o consulta al administrador de bases de datos PostgreSQL y la

72

finalización de su ejecución. No se toma en cuenta el tiempo transcurrido para mostrar los datos. − Cuadro de texto “Text3”: Este cuadro de texto ubicado debajo del nombre “Access query time” muestra el tiempo que transcurre entre el envío de un comando SQL o consulta al administrador de bases de datos Microsoft Access y la finalización de su ejecución. No se toma en cuenta el tiempo transcurrido para mostrar los datos. − Cuadro de texto “Text4”: Este cuadro de texto muestra el tiempo total que duró la ejecución de un comando SQL. Este tiempo incluye el que se muestra en el cuadro de texto “Text1” e incluye el tiempo que transcurre entre el final de la ejecución de un comando SQL y la presentación por pantalla de los resultados. − Cuadro de texto “Text5”: Este cuadro de texto muestra el tiempo total que duró la ejecución de un comando SQL. Este tiempo incluye el que se muestra en el cuadro de texto “Text2” e incluye el tiempo que transcurre entre el final de la ejecución de un comando SQL y la presentación por pantalla de los resultados. − Cuadro de texto “Text6”: Este cuadro de texto muestra el tiempo total que duró la ejecución de un comando SQL. Este tiempo incluye el que se muestra en el cuadro de texto “Text3” e incluye el tiempo que transcurre entre el final de la ejecución de un comando SQL y la presentación por pantalla de los resultados. − Cuadro de texto “Text7”: Ubicado bajo el nombre “Number of rows in query”, este cuadro de texto muestra el número de filas devueltas después de ejecutar un comando SQL. − Cuadro de texto “T:\estadísticas_gprs.mdb”: En este cuadro de texto se debe colocar la ruta o ubicación de la base de datos de Microsoft Access que se va a consultar. − Nombres o etiquetas “Fecha 1” y “Fecha 2”: Cuando estas etiquetas muestran un formato numérico de fecha (año-mes-día) y si se presionan los botones de consulta a los administradores de bases de datos, la consulta o comando SQL que se ejecuta tiene la siguiente estructura: SELECT columna FROM tabla WHERE ‘FECHA’ BETWEEN ‘Fecha 1’ AND ‘Fecha 2’ AND ‘CELDA’=nombreBTS. A continuación se explica de donde se obtienen las variables de esta consulta: o

columna: Se obtiene de cualquiera de los cuadros de texto bajo la etiqueta “Query column” (depende del botón que se presione).

73

o

tabla: Se obtiene de cualquiera de los cuadros de texto bajo la etiqueta “Query table or view” (depende del botón que se presione).

o

Fecha 1: Se obtiene de la etiqueta “Fecha 1”.

o

Fecha 2: Se obtiene de la etiqueta “Fecha 2”.

o

nombreBTS: Se obtiene de la lista desplegable “Combo1”

Para cambiar cualquiera de las etiquetas por una fecha válida, se debe seleccionar una fecha en el calendario y a continuación presionar la etiqueta en donde se colocará la fecha. Inmediatamente la etiqueta cambiará a la fecha seleccionada en el calendario, por ejemplo, si el calendario tiene seleccionada la fecha 22 de Enero de 2005 y se presiona la etiqueta “Fecha 1”, ésta cambiará a “2005-01-22”. Si el calendario no tiene fecha seleccionada y se presiona cualquiera de las dos etiquetas, la etiqueta presionada mostrará “0-0-0”. − La lista desplegable, Drop Down List o ComboBox “Combo1”: Esta lista permite seleccionar cualquier BTS Nokia de la red celular de Digitel GSM. El nombre de esta BTS sirve como variable para ejecutar la consulta realizada cuando las etiquetas “Fecha 1” y ”Fecha 2” muestran el formato numérico de fecha “año-mes-día”. − Cuadro de selección o CheckBox “Use Client Cursors”: Esto permite cambiar una de las opciones del método de conexiones ADO. Si este cuadro de selección se encuentra marcado, entonces todas las conexiones y consultas usarán cursores manejados por el cliente, al contrario, si este cuadro no se encuentra marcado, las conexiones y consultas usarán cursores manejados por el servidor. − Cuadro de selección o CheckBox “Restart connection to databases after every query”: Al seleccionar o marcar esta opción, el programa de pruebas cerrará y abrirá nuevamente la conexión a cada uno de los administradores de bases de datos después de haber ejecutado y mostrado por pantalla los resultados obtenidos luego de ejecutar una consulta o comando SQL. Si este cuadro no está marcado, entonces las conexiones permanecen abiertas incluso después de ejecutar una o varias consultas. Debido a la metodología usada para llevar a cabo el proyecto de grado desarrollado en este libro, el programa de pruebas tuvo un diseño inicial que no incluía algunos de los componentes antes mencionados (por ejemplo, los cuadros de selección de cursores y de

74

reiniciar las conexiones a las bases de datos). La interfaz gráfica descrita anteriormente hace referencia a la última versión del programa de pruebas utilizada para realizar el estudio comparativo de los tres administradores de bases de datos. Esta versión se desarrolló luego de analizar pruebas preliminares realizadas a los administradores de bases de datos.

6.4

Condiciones de los administradores de bases de datos Debido a que la migración no sólo del administrador de bases de datos sino del sistema

operativo usado por el personal de la Coordinación de Optimización puede resultar ser un cambio engorroso, los administradores de bases de datos se instalaron bajo diferentes sistemas operativos. El funcionamiento de los administradores de bases de datos bajo diferentes sistemas operativos da otro punto de comparación al momento de elegir el administrador de base de datos más adecuado para la Coordinación de Optimización. La tabla 1 muestra los computadores y sistemas operativos en donde se instalaron los administradores de bases de datos antes de realizar el estudio comparativo: Microsoft Access

PostgreSQL MySQL 5.0 8.0

Windows 2000 / Computador 1 Linux SUSE 10.1 / Computador 2

Tabla 1. Los sistemas administradores de bases de datos en diferentes computadores. Puede parecer extraño que el administrador de bases de datos Microsoft Access se pueda instalar bajo un sistema operativo Linux, sin embargo, esto es posible debido a que Microsoft Access mantiene las bases de datos en archivos y no necesita que el equipo en donde se encuentren estos archivos tenga controladores o requerimientos especiales.

75

6.5

Pruebas preliminares Para iniciar el estudio comparativo lo más rápido posible, se decidió hacer unas

pruebas preliminares a los administradores de bases de datos. Estas pruebas se denominaron preliminares ya que no se hicieron ajustes ni en los parámetros de configuración de los administradores de bases de datos, ni en los parámetros de configuración de los controladores ODBC, ni en los parámetros de las conexiones de red, ni en los parámetros de los objetos ADO, ni en la estructura de las bases de datos. Estas pruebas preliminares consistieron fundamentalmente en ejecutar diversos comandos SQL o consultas a cada uno de los administradores de bases de datos bajo diferentes sistemas operativos. A continuación se muestra una descripción de todas las pruebas preliminares realizadas:

Prueba preliminar 1 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` la cual selecciona todas las columnas y filas de la tabla “TABLA GENERAL GPRS” y las envía por red al cliente que pide la información. La tabla “TABLA GENERAL GPRS” posee 55 columnas y más de 500.000 filas de información. Esta prueba se realizó 5 veces para cada administrador de base de datos siguiendo el procedimiento que se describe a continuación: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 3. Se esperó hasta que se mostraran por pantalla los resultados. 4. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. 5. Se ejecutaron los pasos del 1 al 4, para los tres administradores sin orden específico. 6. Se ejecutó el paso anterior 5 veces.

76

Con esta consulta se probó la capacidad de los servidores o administradores de bases de datos de enviar grandes cantidades de datos a sus clientes sin ser procesados, es decir, los datos solamente se leen y se envían. Esta prueba se hace abriendo y cerrando las conexiones a los administradores de bases de datos imitando el método usado por las herramientas de la Coordinación de Optimización para consultar las bases de datos.

Prueba preliminar 2 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY ‘FECHA’ la cual selecciona todas las columnas y filas de la tabla “TABLA GENERAL GPRS”, ordena las filas según los valores de la columna “FECHA” y envía los resultados al cliente que pide la información. Esta prueba se realizó 5 veces para cada administrador de base de datos siguiendo el procedimiento que se describe a continuación: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 3. Se esperó hasta que se mostraran por pantalla los resultados. 4. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. 5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden específico. 6. Se ejecutó el paso anterior 5 veces. El objetivo de esta consulta, similar a la de la prueba preliminar 1 es comparar la capacidad de los administradores de bases de datos de procesar y enviar la información contenida en tablas de gran tamaño, es decir, los datos se leen, se procesan de alguna manera (en este caso se ordenan) y se envían. Esta prueba se hace abriendo y cerrando las conexiones a los administradores de bases de datos imitando el método usado por las herramientas de la Coordinación de Optimización para consultar las bases de datos.

77

Prueba preliminar 3 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE ‘FECHA’ BETWEEN ‘fecha1’ AND ‘fecha2’ AND ‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’ la cual selecciona todas las columnas y solamente aquellas filas de la tabla “TABLA GENERAL GPRS” cuyo valor para la columna “FECHA” se encuentre entre los valores “fecha1” y “fecha2” y el valor para la columna “celda” sea exactamente igual a “nombresectorBTS”. Luego de seleccionar la información deseada, el administrador de base de datos debe ordenar los resultados según la columna “FECHA” y enviar la información al cliente. Esta prueba se realizó 10 veces para cada administrador de base de datos siguiendo el procedimiento que se describe a continuación: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se asignó “23ENERO1” a la variable “nombresectorBTS”, “2005-03-01” a la variable “fecha1” y “2006-03-01” a la variable “fecha2”. 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos y se esperaron los resultados. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos y se esperaron los resultados. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos y se esperaron los resultados. 6. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. 7. Se ejecutaron 10 veces los pasos del 1 al 6. La prueba preliminar 3 busca comparar la capacidad de los administradores de bases de datos de procesar grandes cantidades de datos o tablas de gran tamaño y entregar como resultado solamente una pequeña parte de la información contenida en la tabla, es decir, los datos de la tabla se leen, se procesan todos los datos pero se selecciona solamente una pequeña parte (menos del 1% de las filas en la tabla) de la información contenida en la tabla, se ordena

78

esta información y se envían los datos. Esta prueba se hace abriendo y cerrando las conexiones a los administradores de bases de datos imitando el método usado por las herramientas de la Coordinación de Optimización para consultar las bases de datos.

Prueba preliminar 4 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE ‘FECHA’ BETWEEN ‘fecha1’ AND ‘fecha2’ AND ‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’ la cual selecciona todas las columnas y solamente aquellas filas de la tabla “TABLA GENERAL GPRS” cuyo valor para la columna “FECHA” se encuentre entre los valores “fecha1” y “fecha2” y el valor para la columna “celda” sea exactamente igual a “nombresectorBTS”. Luego de seleccionar la información deseada, el administrador de base de datos debe ordenar los resultados según la columna “FECHA” y enviar la información al cliente. Esta prueba se realizó 10 veces para cada administrador de base de datos siguiendo el procedimiento que se describe a continuación: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se asignó “23ENERO1” a la variable “nombresectorBTS”, “2005-03-01” a la variable “fecha1” y “2006-03-01” a la variable “fecha2” 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos y se esperaron los resultados. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos y se esperaron los resultados. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos y se esperaron los resultados. 6. Sin cerrar el programa de pruebas, se cambió el nombre de la BTS (variable “nombresectorBTS”) y se repitieron los pasos del 3 al 5. 7. El paso número 5 se repitió 10 veces.

79

8. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. Esta prueba es similar a la prueba preliminar 3, sin embargo, las conexiones a los administradores de bases de datos permanecen abiertas entre consultas consecutivas. Esto permite comparar el desempeño de las consultas cuando siempre existe una conexión al administrador de bases de datos.

Prueba preliminar 5 Se ejecutó la consulta SELECT * FROM par_hoc la cual selecciona todas las columnas y filas de la vista o view “par_hoc”. Esta vista está definida por el siguiente comando SQL: CREATE OR REPLACE VIEW parameters.par_hoc AS SELECT parameters.bts_id_bsc_id_name."bts_id_OBJECT_INSTANCE", parameters.bts_id_bsc_id_name."PARENT_INT_ID", parameters.bsc_id."OBJECT_INSTANCE" AS "bsc_id_OBJECT_INSTANCE", parameters.bts_id_bsc_id_name."NAME", parameters.c_handover_control.* FROM (parameters.c_handover_control INNER JOIN (parameters.hoc_id INNER JOIN parameters.bts_id_bsc_id_name ON parameters.hoc_id."PARENT_INT_ID" = parameters.bts_id_bsc_id_name."INT_ID") ON parameters.c_handover_control."INT_ID" = parameters.hoc_id."INT_ID") INNER JOIN parameters.bsc_id ON parameters.bts_id_bsc_id_name."PARENT_INT_ID" = parameters.bsc_id."INT_ID" WHERE (((parameters.c_handover_control."CONF_NAME")=''));

80

Como se puede ver, el comando SQL contenido en la vista “par_hoc” es una consulta compleja que realiza una búsqueda de datos que requiere unir tablas con vistas o tablas con tablas y seleccionar valores específicos en cada una de estas tablas y vistas. Luego de seleccionar la información deseada, el administrador de base de datos envía la información al cliente. Esta prueba se realizó 5 veces para cada administrador de base de datos siguiendo el procedimiento que se describe a continuación: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se ejecutó la consulta a uno de los tres administradores de bases de datos y se esperaron los resultados. 3. Se ejecutó la consulta a otro de los tres administradores de bases de datos y se esperaron los resultados. 4. Se ejecutó la consulta al último de los tres administradores de bases de datos y se esperaron los resultados. 5. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. 6. Se ejecutaron 5 veces los pasos del 1 al 5. El objetivo de esta prueba es comparar la capacidad de los administradores de bases de datos de procesar y buscar información específica en varias tablas y varias vistas (que a su vez buscan información en otras tablas y vistas), ordenar la información y enviarla. Todas las pruebas anteriormente mencionadas se realizaron a todos los administradores de bases de datos considerando la tabla 1, es decir, bajo los diferentes sistemas operativos.

81

6.6

Modificaciones a los parámetros de configuración y pruebas finales Luego de realizar las pruebas preliminares se hizo un análisis previo de los resultados

obtenidos. Este análisis se enfocó fundamentalmente en 3 aspectos de la relación entre el sistema operativo, el administrador de bases de datos y la aplicación cliente. Estos aspectos son los siguientes: La velocidad de transmisión de los datos entre el servidor y el cliente, la memoria usada tanto por el cliente como por el servidor, la estructura y componentes de la tablas de las bases de datos y obviamente el tiempo que duró la ejecución de una consulta. Las pruebas finales consistieron en realizar las mismas consultas preliminares y otras más modificando parámetros que pudieran afectar el desempeño de los administradores de bases de datos, del sistema operativo, de la conexión de red, del programa cliente y los controladores. Solamente los cambios que tuvieron un efecto significativo en la ejecución de las pruebas y en el desempeño de los administradores de bases de datos se describen a continuación, sin embargo, se mencionarán todos los cambios realizados y sus efectos producidos.

6.6.1 Cambios realizados a los parámetros de configuración Existe una extensa cantidad de factores que pueden causar que un sistema administrador de bases de datos tenga un bajo desempeño. Entre estos factores están: [11] − Escaneos o búsquedas de tablas completas. − Estadísticas acerca de las bases de datos están desactualizadas. − Operaciones de orden innecesarias. − Falta o uso inapropiado de índices. − Tablas son unidas en un orden no óptimo. − Asignación de búferes (caché de datos, comandos SQL, autorizaciones, etc.) − Opciones de rastreo de eventos (logging) (tamaño del archivo de rastreo, caché de este archivo, etc.) − Trabajo de carga general en el servidor.

82

− Definiciones de las schemas de las relaciones o tablas de la base de datos. Además de estos factores, existen también los relacionados a la configuración de la red, al desempeño del sistema operativo, tipo de sistema de archivos usado por el sistema operativo, configuración detallada de los parámetros de los sistemas administradores de bases de datos, factores relacionados a la aplicación cliente como técnicas de programación y tipo de controladores o drivers utilizados. Debido a la extensa variedad de parámetros involucrados en el funcionamiento de un servidor de bases de datos, se nombrarán algunas de las modificaciones realizadas. Se resalta el hecho de que no se explicará el procedimiento realizado para modificar cada uno de los parámetros ya que está fuera de las limitaciones del proyecto. A pesar de que muchas modificaciones fueron realizadas, se utilizó la regla 80/20 o principio de Pareto para enfocar adecuadamente los esfuerzos.

Parámetros de la conexión de red Las modificaciones realizadas no tuvieron efectos significativos en el desempeño de los administradores de bases de datos. La conexión de red se realizó a través de tarjetas de red ethernet de 10Mbps/100Mbps. Tanto bajo sistemas operativos Windows como Linux, la velocidad de transmisión máxima (10Mbps ó 100Mbps) se establece por un proceso automático. Este proceso dependiendo de las condiciones de la red puede establecer la conexión a 10Mbps aún cuando los dos extremos de una conexión sean capaces de transmitir a 100Mbps. Se configuraron las tarjetas de red en los computadores 1, 2 y 3 para que fijaran su velocidad de transmisión a 100Mbps, sin embargo, este cambio no tuvo efecto alguno. Otro parámetro modificado fue el MTU o unidad máxima de transferencia que permite establecer el tamaño en bytes del paquete más grande que puede pasar por una capa de un protocolo de comunicaciones [31]. La configuración para el computador 3 y 4 era de MTU=1500 (máximo número posible para este parámetro en una conexión de red ethernet) pero para el computador 1 y 2 era de 1472. Se incrementó el MTU de los computadores 1 y 2 a 1500 y no se obtuvieron incrementos notables en la velocidad de transmisión de datos.

83

También se modificaron parámetros del protocolo TCP/IP relacionados al buffer de transmisión y recepción y a la frecuencia de los paquetes de reconocimiento (paquetes Ack o acknowledge). Los valores de los buffers de recepción y transmisión se cuadruplicaron (tanto en Windows como en Linux) y el valor de frecuencia de paquetes de reconocimiento se redujo a la mitad, esperando observar un cambio (positivo o negativo) en la conexión de la red. Bajo el sistema operativo Linux no se observó cambio alguno, sin embargo, la velocidad de transmisión de datos de la conexión de 100Mbps aumentó aproximadamente 2% (2Mbps) bajo el sistema operativo Windows. Debido a que este es un cambio que no mejoró el tiempo de consulta en más de un 10% y que además se debe realizar en todos los computadores clientes, se decidió no efectuar este cambio y dejar los valores por defecto. Parámetros de los administradores de bases de datos Existe una vasta cantidad de parámetros que se pueden modificar en un administrador de bases de datos para cambiar su desempeño. Entre los muchos que se pueden encontrar en administradores de bases de datos como PostgreSQL y MySQL, están: memoria compartida, memoria de trabajo, memoria de almacenamiento, cantidad de conexiones permitidas, cantidad de procesos concurrentes permitidos, cantidad y tamaño máximo de consultas que se guardan en memoria, cantidad de memoria usada por operaciones de búsqueda, memoria usada para almacenar índices de las tablas, memoria usada para realizar búsquedas secuenciales de datos y de índices, etc. Los parámetros que tuvieron los efectos más significativos en las pruebas realizadas son los siguientes: La cantidad de memoria usada para realizar operaciones de búsqueda y cantidad de memoria usada para realizar operaciones de clasificación. A pesar de que se puede llegar a pensar que asignar más memoria es mejor, la realidad es que esta asignación de memoria se hace a cada operación, de clasificación que se realizaba. Esto quiere decir que si una consulta realiza 5 operaciones de clasificación, entonces el administrador de bases de datos tratará de reservar 5 veces la cantidad de memoria establecida en la variable de memoria para operaciones de clasificación. Esto puede ocasionar un deterioro del desempeño del administrador de bases de datos. Similares efectos se observan con la cantidad de memoria asignada a operaciones de búsqueda.

84

En PostgreSQL, los dos parámetros mencionados anteriormente son “shared_buffers” y “work_mem” los cuales fueron fijados a 4096 y 32768 respectivamente. En MySQL, los parámetros son “sort_buffer_size”, “read_buffer_size” los cuales se fijaron en 64M y 64M respectivamente. Estos valores se fijaron luego de ver la memoria disponible en el computador y analizar la concurrencia de usuarios durante las pruebas ejecutadas. El procedimiento y la forma en que se deben fijar estos valores no se discutirá en este libro ya que se encuentra fuera del alcance del mismo. La documentación que ofrece tanto PostgreSQL como MySQL relacionada a la optimización de los administradores de bases de datos sirve como punto de partida para fijar sus parámetros. Además de la gran cantidad de parámetros, es importante mencionar que la configuración de un administrador de bases de datos depende de los recursos disponibles para éste. También influye la carga de trabajo que tendrá el sistema administrador, por ejemplo, no es igual configurar un administrador de bases de datos el cual procesará en su mayoría comandos o consultas de búsqueda, selección y clasificación de datos, a otro que deberá procesar comandos de inserción, eliminación y actualización de los registros o filas de las tablas de las bases de datos. Para configurar adecuadamente un administrador de bases de datos también es necesario observar la carga ejercida en el procesador y la memoria disponible en el computador en el cual opera el administrador de base de datos. Durante el análisis y ejecución de las pruebas, también se estudió la estructura y definición de las relaciones de las bases de datos y se modificaron en varios casos los índices de las tablas (eliminándolos por completo y reasignándolos de nuevo). Se analizaron todas las consultas que se realizan la mayoría del tiempo de manera tal de obtener una base para poder hacer modificaciones a los sistemas administradores de bases de datos, por ejemplo, en PostgreSQL mediante el comando SQL EXPLAIN, se puede obtener el plan de evaluación de la consulta que ejecutará el procesador de consultas de PostgreSQL. Mediante la información obtenida por este comando, se pueden hacer modificaciones a los parámetros de PostgreSQL para mejorar la consulta. Por ejemplo, si al ejecutar un EXPLAIN de una consulta vemos que el plan a ejecutar tiene búsquedas de datos en tablas completas (Table scans o Sequential scans), y la tabla posee índices que deberían ser utilizados en la búsqueda, entonces se pueden modificar parámetros como “random_page_cost” o “effective_cache” para que PostgreSQL use los índices de la tabla en lugar de realizar la búsqueda completa.

85

Se recomienda al lector ir a la referencia [11] para obtener mayores conocimientos acerca de la optimización de sistemas administradores de bases de datos.

Parámetros del sistema operativo Un parámetro fundamental en sistemas operativos Linux es la cantidad de memoria compartida que los procesos en ejecución pueden utilizar. Tanto PostgreSQL como MySQL hacen uso de esta memoria para realizar operaciones y procesar datos. A pesar de que no existe un valor determinado y óptimo para este parámetro, generalmente se asigna un valor equivalente al 50% de la memoria RAM del equipo. Esto no significa que los DBMS usarán esta cantidad de memoria, solamente significa que el sistema operativo Linux permitirá que los programas que se ejecuten puedan utilizar un máximo de la memoria asignada a este parámetro. Por defecto, SUSE Linux 10 configura el parámetro “shmmax” (memoria compartida máxima) en menos de 64 MB. Se asignó un valor equivalente al 100% de la memoria RAM del equipo, ya que durante la ejecución de las pruebas, se permitió a los DBMS usar el 100% de la memoria del computador para observar los efectos sobre el desempeño de los mismos.

Parámetros de programación El parámetro fundamental que se modificó en el programa de pruebas fue el uso de cursores. El método utilizado para realizar la conexión a los administradores de bases de datos, consiste en usar objetos ADO. Una de las propiedades de las conexiones ADO es el uso de cursores que pueden ser manejados por el cliente o por el servidor. Usar cursores manejados por el cliente, libera al servidor o administrador de bases de datos de una carga que implica manejar el cursor que identifica la fila de una tabla que está en uso y evita que el servidor almacene en memoria los resultados de una consulta. Como se verá en el capítulo 8, ésto resulta ser una ventaja cuando el resultado de un comando o consulta devuelve una gran cantidad de datos suficientes para ocupar más del 25% de la memoria del equipo.

86

Parámetros de los controladores Para realizar conexiones y ejecutar consultas a PostgreSQL y MySQL desde Visual Basic, es necesario contar con los controladores ODBC diseñados para ese propósito. Estos controladores tienen parámetros que afectan entre otras cosas la forma en que son procesados los datos provenientes del servidor. A pesar de que se realizaron numerosas pruebas modificando cada uno de los parámetros de los controladores ODBC tanto de MySQL como de PostgreSQL, aquellos que tuvieron mayor efecto en el desempeño de los administradores de bases de datos fueron los siguientes: [29] [30] − Use Declare / Fetch (PostgreSQL): Este parámetro hace que el controlador ODBC busque y almacene en memoria una cantidad específica de los resultados de una consulta. Este parámetro es necesario habilitarlo si el resultado de una consulta no cabe por completo en la memoria del computador que hace la consulta. Si este parámetro está deshabilitado entonces el controlador almacenará todo el resultado obtenido de una consulta. La velocidad de transmisión también se ve afectada cuando este parámetro está activado. Cuando este parámetro está activado, el controlador debe realizar mayor cantidad de operaciones (buscar los datos, almacenarlos, entregarlos al programa que los pide, descartar los datos previamente almacenados y empezar de nuevo la búsqueda de otros datos) lo que hace que el controlador sea más lento y por lo tanto reciba a menor velocidad los datos enviados por el servidor (Esto se podrá observar en los resultados mostrados en el capítulo 8). − Don’t Cache Result (MySQL): Similar al parámetro de PostgreSQL “Use Declare / Fetch”, en MySQL es necesario activar esta opción si se desea que el controlador no almacene completamente los resultados en memoria. A diferencia de PostgreSQL, este parámetro no afecta la velocidad de transmisión de datos, sin embargo, el desempeño del computador cliente se deteriora significativamente debido a que el controlador tratará de almacenar todo el resultado de una consulta. Esto se hace notable cuando el resultado de una consulta ocupa gran cantidad de la memoria o incluso no cabe por completo en ella.

87

− Use Compressed Protocol (MySQL): Este parámetro hace que MySQL use un protocolo comprimido entre cliente y servidor. No se debe activar esta opción ya que además de generar mayor carga tanto en el cliente como en el servidor, también deteriora la velocidad de transmisión de tener un uso de aproximadamente 10%-11% a tener un uso de aproximadamente 2%-3% en una conexión de 100 Mbps.

6.6.2 Pruebas finales A continuación se presentan las pruebas finales realizadas: Prueba final 1 Esta prueba se realizó para observar el efecto de los dos tipos de cursores, cursores manejados por el cliente y cursores manejados por el servidor, disponibles en los objetos ADO de Visual Basic 6. Se decidió hacer esta prueba usando la consulta SELECT * FROM `TABLA GENERAL GPRS` ya que es la que utiliza mayor cantidad de memoria debido al tamaño de la tabla (más de 500.000 filas ocupando un espacio de disco de más de 200 MB). Para realizar esta prueba se siguieron los mismos pasos que para la prueba preliminar 1.

Prueba final 2 Esta prueba es igual a la prueba final 1 con la diferencia que en el paso 2, se usaron cursores manejados por el cliente. Ambas pruebas finales 1 y 2 se realizaron después de modificar parámetros de configuración y poder optimizar el desempeño de los DBMS.

88

Prueba final 3 La consulta ejecutada en esta prueba fue la siguiente: SELECT * FROM `TABLA GENERAL GPRS` ORDER BY `FECHA`. Esta prueba, idéntica a la prueba preliminar 2, se realizó para observar los efectos de las modificaciones hechas en los DBMS, bases de datos, sistemas operativos, etc.

Prueba final 4 En esta prueba se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS`

WHERE

‘FECHA’

BETWEEN

‘fecha1’

AND

‘fecha2’

AND

‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’. Similar a la consulta ejecutada en las pruebas preliminares 3 y 4, pero el procedimiento cambió ligeramente: 1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se ejecutó la consulta a uno de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión a ese administrador de bases de datos. 3. Se ejecutó la consulta a otro de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión a ese administrador de bases de datos. 4. Se ejecutó la consulta al último de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión a ese administrador de bases de datos. 5. Sin cerrar el programa de pruebas, se cambió el nombre de la BTS (variable “nombresectorBTS”) y se repitieron los pasos del 2 al 4. 6. El paso número 5 se repitió 10 veces. 7. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos.

89

Al igual que la mayoría de las pruebas finales, esta prueba se realizó para comparar resultados entre la configuración por defecto de los DBMS y la configuración optimizada que se asignó.

Prueba final 5 Se ejecutó la misma consulta y se usó el mismo procedimiento que para la prueba preliminar 5. Una vez más, se hace mención al hecho de que se modificaron los parámetros de configuración para obtener el mejor desempeño posible de los DBMS.

Prueba final 6 Para esta prueba se decidió ejecutar varias consultas a los tres administradores de bases de datos. Las consultas seleccionadas se obtuvieron de las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización. El objetivo de esta prueba es comparar la capacidad de los administradores de bases de datos de procesar distintas bases de datos, tablas, consultas, vistas e información. El procedimiento que se sigue en esta prueba se muestra a continuación: Consultas escogidas: SELECT * FROM `objects`

(tabla)

SELECT * FROM `power_control`

(tabla)

SELECT * FROM `handover_control`

(tabla)

SELECT * FROM `bcf_id`

(vista)

SELECT * FROM `bts_id`

(vista)

SELECT * FROM `bts_id_bsc_id_name`

(vista)

SELECT * FROM `poc_id`

(vista)

SELECT * FROM `trx_id`

(vista)

SELECT * FROM `par_adj_cell`

(vista)

90

SELECT * FROM `par_trx`

(vista)

SELECT * FROM `par_poc`

(vista)

1. Se inició el programa de pruebas lo cual abre las conexiones a los administradores de bases de datos. 2. Se seleccionó una consulta. 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos y se esperaron los resultados y se cerró la conexión. 6. Se escogió otra consulta y se repitieron los pasos del 3 al 5. 7. El paso número 6 se repitió 5 veces. 8. Se cerró el programa de pruebas lo cual cierra todas las conexiones a los administradores de bases de datos. No es un objetivo de este proyecto instruir acerca de todos los procedimientos y parámetros que se deben modificar para lograr la optimización de los DBMS. La optimización de un DBMS, depende de una extensa variedad de factores, solamente con la experiencia y conocimiento es posible lograr la correcta configuración de un sistema de bases de datos. Se recomienda al lector que consulte las referencias bibliográficas si quiere obtener conocimientos sólidos acerca del proceso de optimización y mejora del desempeño de sistemas de bases de datos. Durante el capítulo 8, se muestran los resultados obtenidos de todas las pruebas mencionadas anteriormente. Según sea necesario, durante el análisis de los resultados, se mencionarán los efectos significativos de algunas de las modificaciones realizadas a los parámetros de configuración de los DBMS, bases de datos, sistemas operativos, controladores, etc. También, al final del capítulo 8, se presenta una tabla en donde se comparan las características y limitaciones de los DBMS estudiados, y otra en donde se evalúa de forma

91

aproximada, los costos que implica el realizar un cambio de sistema operativo y de sistema administrador de bases de datos.

7. HERRAMIENTA PARA AUTOMATIZAR EL CÁLCULO DE LAS ADYACENCIAS DE UNA ESTACIÓN BASE La segunda parte del proyecto de grado desarrollado en este libro, se presenta en este capítulo. La Coordinación de Optimización del Departamento de Operaciones de Digitel GSM, se vio en la necesidad de automatizar y acelerar el proceso llevado a cabo para calcular las adyacencias de una BTS. Este proceso realizado manualmente sirve como una primera aproximación para la selección de las adyacencias de una BTS. No existe un algoritmo que identifique los pasos a seguir para calcular las adyacencias de una BTS. El personal de la Coordinación de Optimización debe hacer uso de su lógica e intuición para calcular las adyacencias de una BTS.

7.1

Procedimiento para el cálculo de las adyacencias El personal de la Coordinación de Optimización, a pesar de la dificultad que implica

desarrollar un algoritmo para calcular las adyacencias de una BTS, ha logrado establecer una serie de pasos que sirven de guía para calcular las adyacencias de un sector de una BTS. A continuación se presenta el conjunto de pasos que sirven de guía al personal de la Coordinación de Optimización para calcular las adyacencias de una BTS: − Ubicar en un mapa las coordenadas de la BTS o del sector de la BTS al cual se le calcularán las adyacencias. − Identificar cuáles son las BTS o los sectores de las BTS más cercanos. − Identificar la orientación o azimuth de la antena del sector de la BTS al cual se le calcularán las adyacencias. − Trazar unas líneas imaginarias que identifiquen y limiten el área de cobertura del sector de la BTS al cual se le calcularán las adyacencias. − Descartar como adyacencia a los sectores que no apunten hacia el sector de la BTS al cual se le calcularán las adyacencias.

93

− Las adyacencias que son seleccionadas corresponden a los sectores más cercanos y que apuntan más hacia el área de cobertura del sector de la BTS. Como se puede observar, el procedimiento para calcular las adyacencias de una BTS es engorroso, confuso y complicado debido a que no existen parámetros exactos para la selección de las adyacencias. Una serie de preguntas surgen al analizar este procedimiento: − ¿Cuántos sectores cercanos se deben escoger? − ¿Existe algún límite de distancia para considerar un sector de BTS no cercano? − ¿Cuántos grados se debe abrir el sector de la BTS a la cual se le calcularán las adyacencias? − ¿Cómo es eso de que “apuntan”? − ¿Hacia dónde deben apuntar, hacia el centro de la BTS o hacia alguna parte del área de cobertura del sector? − ¿Cómo se puede saber si un sector afecta más que otro que apuntan más o menos igual? Además de estas preguntas, muchas otras pueden surgir al analizar el procedimiento que realiza el personal de la Coordinación de Optimización para calcular las adyacencias a una BTS. Se debe mencionar que el procedimiento para seleccionar las adyacencias de un sector de una BTS consta de dos partes, la primera de ellas es una aproximación preliminar que permite seleccionar rápidamente las adyacencias. Esta parte es la que se realiza manualmente y es la parte en donde la experiencia del personal de la Coordinación de Optimización juega un papel importante. La segunda parte, consiste en realizar mediante pruebas de campos y utilizar equipos especializados capaces de medir, entre muchas cosas, la potencia de las diferentes señales recibidas en un determinado punto geográfico. Al igual que en la primera parte del proceso de selección de adyacencias, la experiencia del personal es fundamental para analizar y establecer las rutas y puntos geográficos en donde se deben realizar las pruebas de campo.

94

El procedimiento para calcular adyacencias involucra una gran cantidad de variables que hacen imposible desarrollar, a corto plazo, una herramienta de trabajo que tome en cuenta todas esas variables y que sea capaz de imitar la experiencia adquirida por el personal de la Coordinación de Optimización. En este sentido, la herramienta desarrollada a lo largo de la ejecución del proyecto de grado presentado en este libro, está limitada a ser una primera aproximación en el proceso de selección de adyacencias. La herramienta se desarrolló fundamentalmente para agilizar el proceso manual y engorroso que se debe seguir para calcular en primera instancia las adyacencias de una BTS. Debido a que los cálculos deben ser realizados por un computador, el procedimiento para calcular adyacencias se transformó en un algoritmo con menos libertades y más limitaciones que el procedimiento manual. A continuación se presenta una breve descripción de los pasos del algoritmo desarrollado para el cálculo de las adyacencias de una BTS o un sector de una BTS: − Identificar un número específico de BTS que estén geográficamente más cercanas al sector de una BTS al cual se le calcularán las adyacencias: El usuario debe escoger un número máximo de BTS que serán procesadas. El programa calcula la distancia entre cada una de las BTS de la red celular y un punto geográfico que puede ser una BTS o un sector de una BTS existente o una nueva BTS o sector de una BTS. Se ordenan de mayor a menor todas las distancias calculadas y se escogen aquellas BTS cuya distancia con el sector al cual se le calcularán las adyacencias, sea la menor posible. La cantidad de BTS seleccionadas depende del número introducido previamente por el usuario. Aunque el programa no impone limitaciones respecto al número de BTS que se procesarán, generalmente, por restricciones de hardware y software, un sector de una BTS puede ser configurado para tener solamente un cierto número de adyacencias. − Calcular la orientación o azimuth de las líneas imaginarias que limitan el área de cobertura del sector al cual se le calcularán las adyacencias: Por medio de ecuaciones matemáticas y el uso de la geometría, la herramienta calcula la orientación de las líneas que delimitan el área de cobertura de un sector. Se debe mencionar que es necesario realizar una aproximación para calcular los límites del área de cobertura de

95

un sector. Esta aproximación supone que las antenas son capaces de transmitir solamente en ciertas direcciones, por ejemplo, en las direcciones que abarcan la apertura de la antena. Fuera de esas direcciones, la potencia de transmisión se aproxima a cero. Lo expuesto anteriormente se puede por medio de patrones de radiación de la siguiente manera: Si una antena puede radiar a -30º, -14º, -6º, 0º, +8º, +16º y 28º (sin tomar en cuenta las intensidades) y la antena tiene una apertura de 30º, entonces la transmisión de señales para posiciones angulares menores a los -15º o mayores a los +15º será nula, en otras palabras, la potencia transmitida para ángulos fuera de la apertura de la antena será cero. − Calcular aproximadamente el área de cobertura de cada uno de los sectores tanto de las BTS seleccionadas como del sector al cual se le calcularán las adyacencias: Usando modelos de propagación, el programa es capaz de calcular aproximadamente la distancia máxima a la que podrá llegar la señal de un sector de una BTS con una cierta potencia. Para hacer esto, es necesario que el usuario introduzca toda la información necesaria para usar las ecuaciones del modelo de propagación. Esta información incluye potencia de transmisión, potencia de recepción, alturas de las antenas, pérdidas en las líneas de transmisión y recepción, frecuencia de la señal transmitida, zona y tipo de ciudad en la que viaja la señal de radiofrecuencia, etc. Para calcular el área de cobertura se hace la siguiente aproximación: o La potencia de transmisión de todas las antenas de todas las BTS de la red celular es igual en cualquier dirección de toda su apertura. Todas las antenas poseen lo que se denomina como patrón de radiación. Este patrón representa la intensidad de los campos electromagnéticos emitidos por la antena a diferentes ángulos. En redes celulares, generalmente, se usan antenas que poseen un patrón de radiación en el cual la mayor intensidad está a 0º y en los extremos de la apertura de la antena la intensidad puede llegar a ser la mitad. Estas son llamadas antenas direccionales. La aproximación supone que la antena es capaz de transmitir la misma potencia en dirección del lóbulo principal (a 0º) y en cualquier otra dirección, por ejemplo -15º y +15º si se supone una antena con apertura de 30º.

96

o Se considera el modelo de Tierra plana, es decir, no se toma en cuenta la curvatura de la Tierra para hacer el cálculo de las distancias, por lo tanto, el cálculo del área de cobertura se reduce a encontrar el área de un sector de círculo. Esta aproximación facilita los cálculos geométricos. − Calcular si existen puntos de intersección entre las áreas de cobertura de los sectores de las BTS seleccionadas y el sector de la BTS al cual se le calcularán las adyacencias: El programa desarrollado se basa en ecuaciones geométricas sencillas para determinar si hay solapamiento, interferencia o intersección entre el área de cobertura de dos sectores diferentes. Usando la ecuación de la recta, y la ecuación de círculo, se puede calcular los puntos de intersección entre cualquiera de estas dos curvas. Existen casos en que los resultados no pueden ser procesados por un computador, como es el caso de calcular la pendiente de una recta paralela al eje vertical. En estos casos es necesario hacer aproximaciones a los cálculos realizados, como por ejemplo hacer que el número 0 sea igual a 1-12. Si al momento de calcular los puntos de intersección entre el área de cobertura de un sector de una BTS seleccionada y el área de cobertura del sector al cual se le calcularán las adyacencias ocurre que no existen dichos puntos, entonces el programa toma la decisión de descartar el sector de la BTS como posible adyacencia. − Verificar que el lóbulo principal de los sectores de las BTS seleccionados esté en dirección al centro de la BTS a la cual se le calcularán las adyacencias: De todos los sectores procesados, se seleccionan aquellos que tienen puntos en común con el sector al cual se le calcularán las adyacencias y de éstos, se seleccionan los que tengan su lóbulo principal en dirección al centro del sector de la BTS al cual se le calcularán las adyacencias. Esto se puede entender mejor mediante el siguiente ejemplo: Supongamos un eje de coordenadas x,y. El sector de la BTS al cual se le calcularán las adyacencias está ubicado en las coordenadas x=0 y=0 y su orientación o azimuth es de 30º (0º es el eje y positivo). Otro sector de otra BTS, ubicado en x=3 y=3, tiene puntos de intersección con el sector de la BTS ubicado en x=0 y=0. Para que el sector ubicado en x=3 y=3 pueda ser considerado una adyacencia del sector en x=0 y=0, su azimuth debe tener un valor aproximado de 225º. El usuario del programa tiene la opción de

97

introducir grados de error para ampliar los sectores que pueden ser considerados como adyacencias. Haciendo referencia al ejemplo anterior, si el sector ubicado en x=3 y=3 tuviera un azimuth de 200º y el usuario introduce 30 grados de error, entonces el sector sería considerado como adyacencia. Por el contrario, si el usuario introduce un grado de error igual a 20º, entonces el sector ubicado en x=3 y=3 no será tomado en cuenta como una adyacencia.

7.2

Interfaz gráfica de la herramienta La herramienta para el cálculo automático de las adyacencias se desarrolló usando

Visual Basic 6 como lenguaje de programación. Se escogió este lenguaje principalmente porque todas las herramientas de la Coordinación de Optimización han sido desarrolladas con Visual Basic 6 pero además, este lenguaje de programación ofrece una gran facilidad y rapidez para desarrollar aplicaciones bajo sistemas operativos Windows. Como se mencionó anteriormente en este capítulo, debido a la gran cantidad de variables involucradas en el proceso de calcular adyacencias, es necesario la intervención de la lógica y de la experiencia humana, por lo tanto, la interfaz gráfica de la herramienta presenta al usuario un conjunto de parámetros que se deben introducir antes de realizar los cálculos. Al ejecutar el programa para el cálculo de adyacencias, se mostrará una pantalla solamente con un menú. Esto se hace debido a que la herramienta consta de dos módulos principales, el módulo para el cálculo de adyacencias y el módulo para la administración de BTS, los cuales deben ser seleccionados mediante el uso del menú “File”. En este menú desplegable se presentan tres opciones. La primera de ellas, “Calculate Adjacencies”, hace que el programa muestre la pantalla o interfaz gráfica en donde se hacen los cálculos de las adyacencias, es decir, muestra la interfaz gráfica del módulo de cálculo de adyacencias. En la segunda opción, “View BTS Information”, muestra la pantalla en donde se administran las BTS, es decir, muestra la interfaz gráfica del módulo de administración de BTS, y la tercera opción, “Exit”, hace que el programa finalise.

98

En la figura 19 se puede apreciar la interfaz gráfica del módulo para el cálculo de adyacencias.

Figura 19. Interfaz gráfica de la herramienta desarrollada para el cálculo de adyacencias.

Como se puede ver, la interfaz gráfica del módulo para el cálculo de adyacencias está formada por una gran cantidad de componentes. La función de cada uno de ellos se explica a continuación:

Sección “New BTS Sector Name” En esta sección, existe un cuadro de texto (“New BTS Name”) en donde se debe introducir el nombre y número del sector de una nueva BTS. El formato de este cuadro de texto puede ser cualquiera, siempre que el último carácter del nombre sea el número del sector. A la derecha de esta sección, se puede ubicar un cuadro de selección “New BTS” y una

99

lista desplegable “BTS”. El cuadro desplegable permite seleccionar si la BTS a la cual se le calcularán las adyacencias es nuevo o ya existe. Si el cuadro de selección no se marca, entonces el usuario podrá seleccionar cualquier sector de cualquier BTS de la lista desplegable. Una vez escogido el sector, el programa extrae la información necesaria del sector de la BTS escogido y llenará todos los campos automáticamente. En caso de marcar la opción “New BTS”, entonces el programa deshabilita la lista desplegable obligando al usuario a introducir todos los datos necesarios para el cálculo de adyacencias.

Sección “New BTS Geographic Coordinates” En esta sección, hay un conjunto de casillas permiten al usuario introducir las coordenadas geográficas del sector de la BTS al cual se le calcularán las adyacencias. La lista desplegable ubicada a la derecha de esta sección permite al usuario introducir las coordenadas geográficas en dos formatos distintos; “Decimal Degrees” y “Degº Min' Sec''”. El formato “Decimal Degrees” permite al usuario introducir las coordenadas como un número decimal en donde la parte entera corresponde a los grados de latitud o longitud y la parte decimal corresponde a los minutos y segundos de las coordenadas. Dependiendo de la latitud o longitud, los números deben llevar signo, por ejemplo, si la latitud es norte (N) o la longitud es este (E), el número no lleva signo (12.3456 N = 12.3456; 12.3456 E = 12.3456), pero si la latitud es sur (S) o la longitud es oeste (W) entonces los números deben llevar un signo menos (-) (12.3456 S = -12.3456; 12.3456 W = -12.3456). Si se selecciona el formato “Degº Min' Sec''” el usuario debe introducir en casillas separadas los grados (Degrees), minutos (Minutes) y segundos (Seconds) de las coordenadas geográficas de la nueva BTS. La casilla de los grados debe incluir el signo menos (-) si se trata de una coordenada de latitud sur o de una coordenada de longitud oeste. El programa habilitará y deshabilitará automáticamente (para que no se produzcan errores) las casillas correspondientes al formato seleccionado en la lista desplegable “Latitude - Longitude format”.

100

Sección “New BTS Sector Parameters” En esta sección el usuario debe llenar todas las casillas relacionadas a los parámetros de diseño de una BTS. La casilla “Coverage Radius (km)” no debe ser llenada ya que esta cumple la función de notificar cuál es la distancia máxima teórica y aproximada que viajará la señal transmitida antes de que su potencia alcance el valor indicado en la casilla “Rx Power (dB/dBm)” en la sección “Receiver Model Parameters”. Entre los parámetros que el usuario debe suministrar en esta sección se incluyen el azimuth (“Antenna Azimuth (deg)”), apertura (“Antenna apertura (deg)”), altura (“Antenna Height (m)”) y ganancia de la antena (“Antenna Gain (dB / dBm)”), la potencia de transmisión (“Tx Power (Watts)”), el canal GSM de transmisión usado (“Tx Channel Number”), las pérdidas en las líneas de transmisión (“Tx Feeder Loss (dB/dBm)”), el tipo de área en la que se encuentra la BTS (“Type of Area”) y el tipo de ciudad en donde está la BTS (“Type of City”). Estos parámetros, entre otros, son necesarios para poder utilizar el modelo de propagación de Okumura-Hata. La lista desplegable “Type of City” permite seleccionar tres modelos de ciudad diferentes según se establece en el modelo de propagación de Okumura-Hata. Los tres modelos son: Modelo de ciudad grande con frecuencia de transmisión mayor a 300 MHz (“Large, with f > 300MHz”), ciudad grande con frecuencia de transmisión menor a 300 MHz (“Large, with f < 300MHz”) y modelos de ciudades pequeñas o medianas (“Small and Medium”). La lista desplegable que permite seleccionar el tipo de área en el modelo de propagación de Okumura-Hata presenta también tres opciones: área urbana (“Urban”), área sub-urbana (“Sub-Urban”) y área abierta o rural (“Open”).

Sección “Receiver Model Parameters” El modelo de propagación de Okumura-Hata usa los valores de estas casillas para calcular la distancia teórica que viajará la señal transmitida antes de que su potencia caiga al valor especificado en la casilla “Rx Power (dB/dBm)”. El usuario debe introducir los valores

101

de la ganancia (“Rx Antenna Gain (dB / dBM)”) y altura de la antena (“Rx Antenna Height (m)”) y las pérdidas en las líneas de transmisión (“Rx Feeder Loss (dB / dBm)”). Existe una cuadro de selección, “Receiver is a MS”, que hace que el programa llene las casillas automáticamente considerando que el punto de recepción es una estación móvil.

Sección “Adjacencies Options” Ya en esta sección el usuario debe tomar las decisiones finales antes de calcular las adyacencias. La casilla “Number of Geographic Adjacencies” permite al usuario seleccionar un número específico de BTS que estén geográficamente más cerca de la nueva BTS. La opción “Auto” hace que el programa calcule automáticamente en número de BTS. El programa incluirá todas las BTS cuya distancia sea menor o igual al radio de cobertura de la nueva BTS. La lista desplegable “Adjacency calculation mode” permite seleccionar la forma en la que se calcularán las adyacencias. Dos formas o métodos de cálculo se implementaron en el programa. La primera forma corresponde a un cálculo basado exclusivamente en la distancia geográfica entre las BTS de la red y la nueva BTS, es decir, el programa solamente calcula la distancia entre la nueva BTS y el resto de las BTS en la red, y selecciona una cantidad de BTS especificada por la casilla “Number of Geographic Adjacencies” con la menor distancia posible. El programa muestra los resultados en la tabla “Nearest Overlapping Sectors”. El otro método para calcular las adyacencias se escoge con la opción “Nearest Overlapping & HandOver sectors” de la lista desplegable “Adjacency Calculation Mode”. Este método es el que se debe usar para obtener una primera aproximación en el cálculo de las adyacencias ya que éstas se calculan tomando en cuenta las áreas de cobertura de los sectores de las BTS, las orientaciones de las antenas y los puntos de intersección entre las áreas de cobertura. Los resultados obtenidos luego de realizar los cálculos son mostrados por el programa en dos tablas distintas. En la tabla “Nearest Overlapping sectors” se muestran los sectores de las BTS geográficamente más cercanas cuya área de cobertura interfiere o se solapa con el área de cobertura de la nueva BTS. En la tabla “Nearest Overlapping and HandOver

102

sectors”, el programa muestra los sectores de las BTS que además de tener zonas de solapamiento con la nueva BTS, el azimuth de su antena está dirigido hacia las coordenadas geográficas de la nueva BTS. La casilla “Angle Tolerance (deg)” permite introducir una variación en la dirección del azimuth de las antenas y en los ángulos de las líneas que limitan el área de cobertura, por ejemplo, si para una BTS cualquiera, llamada BTS2, la dirección en donde se encuentra la nueva BTS es de 137º, entonces el valor en la casilla “Angle Tolerance (deg)” permite que el programa considere a BTS2 como adyacencia si el azimuth de su antena está entre los valores 117º y 157º si la casilla “Angle Tolerance (deg)” tiene un valor de 20, por ejemplo. Esto ocurre también con el ángulo de las líneas imaginarias que limitan el área de cobertura del sector. Junto a la etiqueta “Additional Aperture Angle (deg):” hay dos cuadros de textos que tiene un efecto significativo en los cálculos. La casilla “for New BTS” se usa para añadir o aumentar el valor de la apertura de la antena de la nueva BTS (“Antena apertura (deg)”). Esto se hace para dar mayor flexibilidad al área de cobertura de una nueva BTS. El cuadro de texto “for other BTS” se usa para añadir o aumentar el valor de la apertura de la antena de todas las BTS consideradas en el cálculo de adyacencias. Esta casilla también permite flexibilizar los límites teóricos y cálculos realizados por el programa. La casilla que se encuentra ubicada a la derecha de la etiqueta “All BTSs closer than this distance Hill be considered adyacencias (km):”. La función de la casilla es simple: Si existen BTS cuya distancia, en kilómetros, con la nueva BTS es menor o igual al valor de la casilla, entonces el programa, automáticamente, considerará esas BTS como adyacencias, sin necesidad de calcular puntos de intersección o áreas de solapamiento. Una vez que se hayan seleccionado e introducido todos los parámetros necesarios, se puede pulsar el botón “Calculate Adjacencies” para hacer que el programa inicie el proceso de cálculo de adyacencias.

103

Opciones de “Datafill” El programa también es capaz de generar un reporte denominado “Datafill”. La Coordinación de Optimización genera estos reportes manualmente luego de realizar la primera aproximación en el proceso de seleccionar las adyacencias de un sector de una BTS. Este reporte incluye información acerca de la BTS así como también las adyacencias de la misma. A través del botón “Generate Datafill”, el programa es capaz de generar un “Datafill” y las adyacencias que se incluirán en el reporte se tomarán de cualquiera de las dos tablas del programa. La lista desplegable ubicada debajo del botón “Generate Datafill” permite al usuario seleccionar cualquiera de estas dos tablas. Si se escoge la opción “Overlapping Only” la tabla que será usada como fuente de información para incluir las adyacencias en el reporte será “Nearest Overlapping sectors” y si se escoge la opción “Overlapping and HandOver”, la tabla usada será “Nearest Overlapping and HandOver sectors”.

Cuadros de texto “BCC” y “NCC” Estas dos casillas se deben llenar con los valores de los componentes NCC y BCC que forman el código de identificación de una BTS (BSIC; Base Transceiver Station Identity Code). Los valores de estos dos parámetros permiten modificar el reuso de frecuencias en la red celular. Para escoger estos dos parámetros y asignárselos a un nuevo sector de una BTS, el personal debe analizar cada uno de los sectores que transmiten en el mismo canal que la nueva BTS y se debe escoger la combinación NCC-BCC menos usada o la combinación que está usada una menor cantidad de veces y que además esté asignada a un sector cuya distancia con la nueva BTS sea la mayor posible. Debido a la gran posibilidad de combinaciones NCC-BCC que se pueden presentar, la selección de este par de parámetros se deja a discreción y experiencia del usuario, sin embargo, el programa facilita la tarea de selección al presentar tres tablas luego de que se han calculado las adyacencias. En la figura 20 se muestra la interfaz gráfica de la herramienta luego de calcular las adyacencias a un sector existente en la red celular llamado “23ENERO1”.

104

Figura 20. Interfaz de la herramienta luego de calcular las adyacencias para el sector 23ENERO1.

En esta figura se pueden observar tres nuevas tablas que no se encuentran en la pantalla inicial del programa. La primera de ellas, “Overlapping BTS”, muestra la cantidad de BTS que transmiten en el mismo canal que la nueva BTS, que tienen áreas de cobertura solapadas con la nueva BTS y que usan las combinaciones NCC-BCC mostradas (En el ejemplo de la figura 20, no existen BTS en el sistema que transmitan en el mismo canal que el sector “23ENERO1” y que al mismo tiempo tengan áreas de cobertura solapadas). La segunda tabla, “All BTS”, muestra la cantidad de BTS con las distintas combinaciones NCC-BCC cuyo canal de transmisión es el mismo que el de la nueva BTS. No importa si estas BTS tienen áreas solapadas o no, solamente se muestran las BTS con el mismo canal de transmisión. Haciendo referencia a la figura 20, existen 4 sectores con la combinación NCC=4 BCC=1 (las columnas equivalen a los valores de NCC, del 4 al 6, y las filas a los valores de BCC, del 0 al 7). La última tabla a pesar de no tener nombre, se puede identificar ya que aparece encima de

105

la tabla “Nearest Overlapping sectors”. Similar a la tabla “All BTS”, en esta tabla superpuesta aparecen los nombres de todas las BTS que tienen el mismo canal de transmisión. Además, se puede ver la distancia de cada una de éstas BTS a la nueva BTS y su combinación NCC-BCC. Una característica que resalta en la figura 20 es el hecho de que la etiqueta “NCC” aparece con fondo amarillo. Esto indica al usuario que si hace clic en ella, se puede cambiar el estado de la tabla “flotante” entre oculta y visible. Claramente se puede ver que este procedimiento automático que muestra todas las combinaciones posibles de NCC-BCC, reduce considerablemente el tiempo utilizado para escoger dicha combinación para la nueva BTS. De no hacer uso de esta capacidad de la herramienta, se tiene que buscar y comparar, manualmente, todas las BTS en la base de datos (más de 500 BTS y más de 1000 sectores) para escoger la combinación NCC-BCC deseada.

Como se mencionó anteriormente, la herramienta consta de dos módulos. La interfaz gráfica del segundo módulo, para la administración de BTS, se muestra en la figura 21.

Figura 21. Interfaz para la administración de BTS de la herramienta desarrollada.

106

La interfaz se desarrolló para ofrecer la mayor facilidad de uso y por esto sólo consta de cuatro botones y una lista desplegable. La función de estos componentes se describe a continuación: − Botón “Reload BTS List”: Al presionar este botón, el contenido de la lista desplegable se elimina por completo y luego se agrega nuevamente. Esto se hace con el objetivo de mostrar una BTS que haya sido añadida con el botón “”. Además, permite verificar que la nueva BTS haya sido creada o eliminada con éxito. − Botón “View BTS Info”: La función de este botón es mostrar la información de todos los sectores de una BTS seleccionada de la lista desplegable. − Botón “Add New BTS”: Permite agregar un nuevo sector o una nueva BTS a la base de datos que contiene la información de las BTS. Luego pulsar este botón, el programa llenará automáticamente algunos campos que coincidan con la información suministrada en la interfaz gráfica del módulo para el cálculo de adyacencias como por ejemplo, las coordenadas geográficas de la nueva BTS, el nombre de la nueva BTS, la orientación, ganancia y altura de la antena, etc. Si no se ha introducido ninguna información, entonces el programa llenará las casillas con valores por defecto y si el nombre de la nueva BTS es igual al nombre de una BTS existente, el programa mostrará la información de las dos BTS con el mismo nombre. Queda como decisión del usuario cambiar el nombre de alguna de las dos BTS. − Botón “Delete BTS”: Luego mostrar por pantalla la información de un sector de una BTS, de todos los sectores de una BTS o de todos los sectores de todas las BTS, el usuario puede seleccionar cualquiera de los sectores y presionar el botón “Delete BTS”. Esta es una operación que no se puede deshacer y borrará de la base de datos toda la información correspondiente al sector seleccionado. − Lista desplegable “BTS”: Esta lista contiene todos los sectores de todas las BTS que están registradas en la base de datos. Al seleccionar cualquiera de estos sectores, el

107

programa automáticamente muestra toda la información correspondiente al sector seleccionado. El primer elemento en la lista lleva el nombre de “All BTS”. Si este elemento se selecciona, el programa mostrará la información de todos los sectores de todas la BTS registradas en la base de datos.

7.3 Pruebas realizadas Se debe recordar que la herramienta se desarrolló con la función de servir como primera aproximación en el proceso de selección de adyacencias de una BTS y por lo tanto, para verificar que la herramienta desarrollada fuera capaz de entregar resultados aceptables para el personal de la Coordinación de Optimización, se realizaron pruebas con el objetivo de comparar las adyacencias calculadas por la herramienta con las adyacencias seleccionadas por el personal de la Coordinación de Optimización luego de realizar las pruebas de campo. Antes de observar y analizar resultados, se puede conocer una característica común en todos los resultados y es el hecho de que el 100% de las adyacencias calculadas por la herramienta no serán las mismas que las calculadas luego de realizar pruebas de campo. Esto se debe a que los cálculos realizados por la herramienta, están basados en modelos teóricos y aproximaciones cuyo efecto se observa en los resultados obtenidos luego de realizar una prueba de campo, sin embargo, se espera que por lo menos el 25% de las adyacencias seleccionadas por el personal de la Coordinación de Optimización, estén entre las adyacencias calculadas por la herramienta. Se seleccionaron 5 sectores cuyas adyacencias hayan han sido seleccionadas por el personal de la Coordinación de Optimización a través de pruebas de campo, y se compararon con las adyacencias calculadas por el programa de los mismos 5 sectores. Todos los resultados se presentan en el capítulo 8.

8. RESULTADOS Y ANÁLISIS A lo largo de este capítulo se presentan todos los resultados obtenidos de las diferentes pruebas realizadas durante el desarrollo del proyecto. Al igual que el desarrollo del proyecto, los resultados y el análisis de los mismos también se divide en dos partes. En la primera parte, que corresponde a la sección 8.1, se muestran los resultados obtenidos de las pruebas realizadas durante el desarrollo del estudio comparativo entre tres administradores de bases de datos. La segunda parte, sección 8.2, muestra los resultados de las pruebas realizadas con la herramienta para el cálculo automático de adyacencias. Antes de presentar los resultados, se deben hacer ciertas observaciones respecto al origen de los mismos. Las gráficas presentadas fueron obtenidas a través del administrador de tareas de Windows, el cual muestra gráficas acerca de la actividad de CPU, red y memoria, en tiempo real y sin escala horizontal o vertical. Las gráficas poseen una cuadrícula en el fondo y sobre ésta se trazan las curvas. A pesar de que no existe una escala vertical con una buena resolución, el administrador de tareas de Windows posee una escala que va desde 0% hasta 100% para la gráfica del uso del procesador o CPU del equipo. También, el administrador de tareas puede generar las gráficas correspondientes a la actividad de red con una escala automática, en donde sólo se pueden ver tres valores (valor máximo, valor mínimo y valor medio de la escala), sin embargo, se puede configurar el administrador de tareas de Windows para que la escala en la actividad de red siempre esté entre 0% y 100%. Para enfocar ciertas características de las gráficas obtenidas a través administrador de tareas de Windows, solamente se muestra parte de ellas. Por lo tanto, no poseen ni una escala horizontal ni vertical. A pesar de que no es necesario obtener valores precisos de éstas gráficas, debido a la comparación relativa que se hace entre ellas, a continuación se presenta una aproximación para ubicar los valores en las gráficas: El eje vertical se encuentra dividido en 17 recuadros, el punto más bajo de la escala equivale a 0% y el punto más alto de la escala equivale a 100%, por lo tanto, cada recuadro recorrido verticalmente equivale aproximadamente a 5,882%, en otras palabra, cada línea divisoria horizontal de la gráfica equivale a 5,882% aproximadamente. De igual forma podemos establecer un eje horizontal: El administrador de tareas de Windows puede ser configurado para que actualice los datos en la

109

pantalla con tres frecuencias o velocidades diferentes: Alta, normal y baja. Todas las gráficas se obtuvieron seleccionando la velocidad de actualización alta, y se encontró, a través de pruebas empíricas, que el tiempo de actualización es de aproximadamente 0,5 segundos y el tiempo que transcurre entre la visualización de una línea vertical y la siguiente es de aproximadamente 3 segundos, es decir, cada línea divisoria vertical equivale a 3 segundos aproximadamente. El la figura 22 se muestra la interfaz gráfica del administrador de Windows mostrando actividad de CPU y memoria de un computador.

Figura 22. Administrador de tareas de Windows mostrando el uso de CPU y memoria de un computador. Es importante mencionar que el color de todas las gráficas fue modificado para permitir una mejor impresión en papel. Como se dijo antes, todas las figuras muestran solamente una parte de toda la interfaz gráfica del administrador de tareas de Windows. Por ejemplo, una gráfica puede tener solamente parte del “Historial de uso del CPU” y además el recuadro de “Memoria física (KB)” que se muestran en la figura 22.

110

8.1

Estudio comparativo entre tres administradores de bases de datos En esta sección se presentan los resultados de las pruebas preliminares, pruebas

finales, y al final se muestran un cuadro que contiene las especificaciones y limitaciones de cada uno de los administradores de bases de datos. Cada prueba realizada está acompañada con un breve análisis y discusión. A lo largo de este capítulo se hará referencia a frases como “tabla de gran tamaño”, “resultados de gran tamaño” o “gran número de filas”. Para evitar explicar cual es el significado de cada una de estas frases cada vez que se utilizan, a continuación se presenta una descripción: La frase “tablas de gran tamaño” hace referencia a todas aquellas tabla cuyo espacio en disco sea de más del 25% de la memoria física total del computador, es decir, para un computador con 768 MB de RAM una “tabla de gran tamaño” es una tabla cuyo espacio ocupado en el disco es de más de 192 MB. La frase “resultados de gran tamaño” está relacionada con la frase “tablas de gran tamaño” y corresponde al conjunto de resultados de una consulta que ocupan más del 25% de la memoria física total del computador que pide los resultados. La frase “gran cantidad de filas” no tiene significado por sí sola y siempre estará acompañada de la frase “tabla de gran tamaño” ya que 100.000 filas de una tabla que contiene una sola columna del tipo entero, requerirá menor cantidad de espacio y memoria que 100.000 filas de una tabla con 100 columnas de diferentes tipos (texto, entero, punto flotante o decimal, fecha, etc.). La frase “pequeña cantidad” generalmente se menciona cuando se hace referencia a parte de una tabla y su significado es que del total de las filas de una tabla, menos del 10% son usadas o seleccionadas.

8.1.1 Resultados de las pruebas preliminares Prueba preliminar 1 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS`. Procedimiento: 1. Se inició el programa de pruebas. 2. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos.

111

3. Se esperó hasta que se mostraran por pantalla los resultados. 4. Se cerró el programa de pruebas 5. Se ejecutaron los pasos del 1 al 4, para los tres administradores sin orden específico. 6. Se ejecutó el paso anterior 5 veces. La tabla 2 muestra los tiempos de ejecución, en segundos, de cada consulta para cada administrador de bases de datos. Microsoft Access / Windows (segundos) 24,8 24,993 24,753 24,045 24,55

Microsoft Access / Linux (segundos)

MySQL / Windows (segundos)

MySQL / Linux (segundos)

23,276 24,178 23,532 23,166 22,993

351,472 350,174 353,54 355,845 350,297

321,33 323,546 322,013 319,638 323,126

PostgreSQL / PostgreSQL / Windows Linux (segundos) (segundos) 321,573 329,285 329,322 321,548 320,786

264,621 260,862 263,351 261,589 260,87

Tabla 2. Resultados de la prueba preliminar 1. Consulta (SELECT * FROM `TABLA GENERAL GPRS`)

Las figuras 23, 24, 25 muestran la actividad de red al ejecutar la consulta con Microsoft Access/Windows, MySQL/Linux y PostgreSQL/Linux respectivamente. La velocidad de la conexión de la red es de 100 Mbps, es decir, 100% equivale a 100 Mbps. Como se mencionó anteriormente, la gráfica se obtuvo del “Administrador de Tareas de Windows” o “Windows Task Manager” en la pestaña “Funciones de red” o “Networking”. Para la figura 23, el administrador de tareas indicó una actividad de red de aproximadamente 78%, es decir, 78 Mbps (oscilaba entre 77% y 79%). En la figura 24, la actividad de red indicada fue entre 11% y 13%, y la actividad de red indicada por el administrador de tareas en la figura 25 fue entre 16% y 20%.

112

Figura 23. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con Microsoft Access / Windows.

Figura 24. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con MySQL / Linux.

Figura 25. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con PostgreSQL / Linux.

113

No se muestran las gráficas del computador cliente, con MySQL/Windows o PostgreSQL/Windows ya que las valores para las gráficas obtenidas, varían menos de un 5% en comparación con las gráficas mostradas. En el caso de MySQL/Windows, la actividad permanece igual. Para PostgreSQL, la actividad de red varía entre 12% y 14%, y para Windows/Linux, la actividad varía entre 76% y 81%. Por esta misma razón, las gráficas del servidor de Windows no se muestran. Al observar las figuras anteriores, una de las preguntas que pueden surgir es: Si la actividad de red en MySQL tiene menor duración que la actividad de red que PostgreSQL, ¿cómo es posible que la ejecución de la consulta haya tomado más tiempo en MySQL que en PostgreSQL? Para responder esta pregunta se deben observar las figuras 26, 27 y 28 en donde se indica la actividad de CPU y estadísticas de memoria, del computador cliente, durante la ejecución de las consultas.

114

Figura 26. Actividad de CPU y memoria al realizar la prueba preliminar 1 con Microsoft Access / Windows.

115

Figura 27. Actividad de CPU y memoria al realizar la prueba preliminar 1 con MySQL / Linux.

Figura 28. Actividad de CPU y memoria al realizar la prueba preliminar 1 con PostgreSQL / Linux.

116

En la actividad de CPU de la figura 27 se pueden distinguir dos partes. Una en donde la actividad de CPU no es mayor al 25% aproximadamente, y otra en donde la actividad sobrepasa el 25%. También se puede observar el crecimiento en el archivo de página (Page file) y la baja cantidad de memoria física disponible (a menos de un 15% del total). La misma situación ocurre con Microsoft Access y PostgreSQL, pero con la diferencia que el archivo de página deja crecer cuando la actividad de CPU cae a menos del 10% (Esto ocurre cuando la transmisión de los datos ha finalizado, es decir, actividad de red 0%). Sin embargo, con MySQL, la actividad de CPU aumenta a más del 25% cuando la transmisión de datos finaliza. Esto se debe a que el controlador ODBC de MySQL trata de almacenar todo el conjunto de resultados en la memoria. Este situación se cambió al habilitar la opción “Don’t Cache Result (forward only cursors)” del controlador ODBC de MySQL. Lo que hace esta opción es obligar al controlador a almacenar todos los resultados en memoria. Esto hace que los resultados sean almacenados en memoria en forma duplicada ya que el programa de pruebas desarrollado, también almacena en memoria los resultados recibidos. Otro aspecto que se debe mencionar, es que sin importar si la opción “Don’t Cache Result (forward only cursors)” esta habilitada o deshabilitada, MySQL usa el 100% del CPU mientras ejecuta la transmisión de datos. Esto trae como consecuencia que el servidor no responda o responda muy lentamente, durante el período que dure la transmisión de datos. Por ejemplo si se quiere cambiar de ventana o tratar de abrir el bloc de notas de Windows, esta operación podría tardar más de 1 minuto (si la transmisión de datos se realiza en más de un minuto), cuando normalmente puede tardar a lo sumo 5 segundos. Una situación similar se presenta con el controlador ODBC de PostgreSQL. Cuando la opción “Use Declare/Fetch” no está habilitada, el controlador trata de almacenar todo el resultado en memoria. Cuando esta opción está habilitada, la velocidad de transmisión se reduce en 5% aproximadamente, situación que no ocurre con el controlador ODBC de MySQL. Lo que es importante mencionar es que debido al tamaño de los resultados de esta consulta, el controlador ODBC de PostgreSQL, antes de entregar todos los resultados, mostró un mensaje de error con la siguiente línea: “Out of memory while reading tuples” y seguidamente se canceló la operación. Por lo tanto, para poder ejecutar la prueba preliminar 1 con PostgreSQL, se tuvo que habilitar la opción “Use Declare/Fetch” en el controlador ODBC de PostgreSQL.

117

Luego de realizar esta prueba preliminar, se puede observar la superioridad en cuanto a velocidad de transmisión de Microsoft Access.

Prueba preliminar 2 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY ‘FECHA’. Procedimiento: 1. Se inició el programa de pruebas. 2. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 3. Se esperó hasta que se mostraran por pantalla los resultados. 4. Se cerró el programa de pruebas. 5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden específico. 6. Se ejecutó el paso anterior 5 veces. La tabla 3 muestra los tiempos de ejecución, en segundos, de cada consulta para cada administrador de bases de datos. Microsoft Access / Windows (segundos) 528,125 520,031 523,109 522,422 522,84

Microsoft Access / Linux (segundos)

MySQL / Windows (segundos)

MySQL / Linux (segundos)

520,333 518,751 512,986 519,324 517,932

382,698 381,157 398,042 396,078 385,188

368,123 374,852 366,96 371,375 369,686

PostgreSQL / PostgreSQL / Windows Linux (segundos) (segundos) 344,392 343,778 345,129 344,846 343,635

313,478 315,611 315,323 311,956 317,865

Tabla 3. Resultados de la prueba preliminar 2. Consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY `FECHA`. Se pueden utilizar las figuras 26, 27 y 28 de la prueba preliminar 1 para identificar la actividad de red, ya que ésta tuvo una variación de menos del 3% durante la ejecución de esta prueba.

118

Dado que esta tarea involucra procesamiento por parte del servidor (debido a la cláusula “ORDER BY”), en las figuras 30 y 31 se muestran las gráficas del uso del CPU en el servidor con sistema operativo Windows. Sin embargo, en la figura 29 se muestra el uso de CPU en el computador cliente.

(a)

(b)

(c) Figura 29. Gráficas del uso de CPU, del computador cliente, al ejecutar la prueba preliminar 2 con Microsoft Access / Windows. (a) Recepción de los datos transmitidos por red; (b) Procesamiento de los datos; (c) Procesamiento antes de mostrar los datos por pantalla.

119

Figura 30. Gráfica del uso de CPU, del computador servidor, al ejecutar la prueba preliminar 2 con MySQL / Windows.

Figura 31. Gráfica del uso de CPU, del computador servidor, al ejecutar la prueba preliminar 2 con PostgreSQL / Windows. La figura 29 muestra el uso de CPU y memoria del computador cliente durante la ejecución de la prueba con Microsoft Access bajo Windows. No se muestra la actividad del computador servidor ya que el único procesamiento realizado por éste, es durante la transmisión de datos. Una vez que finaliza la transmisión, la actividad de CPU cae a menos de 5% y la memoria física disponible se reduce a un número similar al que se muestra en la figura 26 de la prueba preliminar 1 (con una variación de ±15%). En la figura 29.a, se puede ver el uso del CPU del computador cliente durante la recepción de datos. El tiempo que transcurre al realizar la transmisión de datos es similar a los tiempos de la prueba preliminar 1 con Microsoft Access / Windows (una variación de no más de ±20%). Luego de finalizar la actividad de red, el uso del CPU del computador cliente cae a menos del 20% y permanece en ese estado (con esporádicos picos que no sobrepasan el 50% de uso), como se observa en la figura 29.b, hasta que comienza el procesamiento de los datos para ser mostrados por pantalla, figura 29.c, caracterizado por un aumento en la actividad del

120

CPU. A pesar de que las figuras no tienen escalas de tiempo, según la aproximación presentada al principio de este capítulo se puede decir que el período de tiempo que Microsoft Access usa para procesar los datos de la tabla es de más de 300 segundos (haciendo la aproximación de que cada línea divisoria vertical equivale a 3 segundos). Al ejecutar la consulta con MySQL y PostgreSQL, no se observó actividad considerable en el CPU del computador cliente antes de que se iniciara la recepción de datos, es decir, el uso del CPU en el cliente, permaneció por debajo de 5% hasta que se inició la recepción de datos. Es por esto que en las figuras 30 y 31, se observa el uso de CPU en el servidor. La actividad de CPU mostrada en la figura 30 corresponde al procesamiento de datos realizado por MySQL antes de transmitir el resultado al computador cliente. En esta figura se puede ver la transición entre la finalización del procesamiento de los datos, el inicio de la transmisión de los mismos y el final de la transmisión. El procesamiento de datos corresponde a la parte de la gráfica que va desde el inicio (parte izquierda de la gráfica) hasta que la actividad de CPU sube a 100%. El tiempo de procesamiento es de aproximadamente 200 segundos. La transmisión de datos se puede observar al final de la gráfica cuando la actividad de CPU sube a 100%. Como se mencionó anteriormente, mientras MySQL realiza la transmisión de datos, el computador servidor no responde a ninguna otra acción o proceso que se esté ejecutando en él. Esto queda evidenciado en el hecho de que la gráfica de la figura 30 muestra que luego de haber transcurrido entre 3 y 6 segundos, la transmisión de datos finalizó. Esto contradice los resultados obtenidos en la figura 24 en donde el tiempo que toma MySQL para transmitir la misma cantidad de datos es mucho mayor a 3 segundos (en la figura 24 es de aproximadamente 102 segundos). La razón de este aparente corto período de transmisión de datos, es que MySQL toma posesión única del CPU (haciendo que la actividad sea de 100%) y ni siquiera se pueden actualizar los datos del administrador de tareas, es decir, el sistema operativo Windows no cumple o descuida otros procesos. En el computador cliente, no se observa actividad antes de la recepción de datos y luego se puede ver una gráfica como la mostrada en la figura 24 de la prueba preliminar 1. PostgreSQL muestra en la figura 31 una situación similar a la de MySQL, es decir, hay una actividad de CPU que identifica el procesamiento de datos y otra que identifica la transmisión de datos. El período de procesamiento se puede identificar en la gráfica de la

121

figura 31 por los puntos en donde la actividad de CPU sube a 100%. Este período se extiende (aproximadamente por 90 segundos) hasta que la actividad de CPU se mantiene alrededor de un valor de 70% aproximadamente, momento en el que se inicia la transmisión de datos. Se puede ver que el período de procesamiento de PostgreSQL es mucho menor al de MySQL (aproximadamente 55% menor) y al de Microsoft Access (al menos 70% menor). Aún así, los tiempos obtenidos, por ejemplo, con PostgreSQL / Windows no difieren a los obtenidos con MySQL / Windows en más de un 15%. Esto se debe a que el tiempo de transmisión de datos de MySQL es mucho menor que el de PostgreSQL (aproximadamente 45% menor). Una diferencia fundamental entre PostgreSQL y MySQL es que el servidor donde está instalado PostgreSQL no deja de responder durante la transmisión de datos, es decir, el CPU puede dividir su capacidad de procesamiento entre varios procesos. Inclusive, el administrador de tareas de Windows puede seguir mostrando los datos por pantalla en tiempo real. Prueba preliminar 3 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE ‘FECHA’ BETWEEN ‘fecha1’ AND ‘fecha2’ AND ‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’. Procedimiento: 1. Se inició el programa de pruebas. 2. Se asignó “23ENERO1” a la variable “nombresectorBTS”, “2005-03-01” a la variable “fecha1” y “2006-03-01” a la variable “fecha2”. 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos. 6. Se cerró el programa de pruebas. 7. Se ejecutaron 10 veces los pasos del 1 al 6. La tabla 4 muestra los tiempos de ejecución, en segundos, de cada consulta para cada administrador de bases de datos.

122

Microsoft Access / Windows (segundos) 22,079 22,853 22,554 22,289 22,72 22,487 22,767 22,859 22,671 22,768

Microsoft Access / Linux (segundos)

MySQL / Windows (segundos)

MySQL / Linux (segundos)

21,845 21,905 21,911 21,886 21,891 21,851 21,86 21,873 21,89 21,857

12,321 5,696 5,783 5,778 5,738 5,802 5,692 5,765 5,712 5,753

11,468 5,344 5,359 5,343 5,327 5,32 5,299 5,362 5,333 5,311

PostgreSQL / PostgreSQL / Windows Linux (segundos) (segundos) 11,016 8,969 8,938 8,953 8,936 8,941 8,97 8,51 8,978 8,964

9,047 8,946 8,89 8,97 9,12 9 8,821 8,844 8,911 8,836

Tabla 4. Resultados de la prueba preliminar 3.

Al igual que en la prueba preliminar 2, se muestran las gráficas de uso de CPU y de red tanto del cliente como del servidor. En la figuras 32, 33 y 34 se muestran las gráficas de actividad de red y uso de CPU, tanto del cliente como del servidor, al realizar la prueba con los tres DBMS: Microsoft Access / Windows, MySQL / Windows y PostgreSQL / Windows.

(a)

(b)

Figura 32. Uso del CPU y actividad de la red al realizar la prueba preliminar 3 con Microsoft Access / Windows. (a) Uso del CPU del servidor. (b) Actividad de red del servidor. (c) Uso del CPU del cliente. (d) Actividad de red del cliente.

123

(c)

(d)

Figura 32. Continuación.

(a)

(c)

(b)

(d)

Figura 33. Uso del CPU y actividad de la red al realizar la prueba preliminar 3 con MySQL / Windows. (a) Uso de CPU del servidor. (b) Actividad de red del servidor. (c) Uso de CPU del cliente. (d) Actividad de red del cliente.

124

(a)

(c)

(b)

(d)

Figura 34. Uso del CPU y actividad de le red al realizar la prueba preliminar 3 con PostgreSQL / Windows. (a) Uso de CPU del servidor. (b) Actividad de red del servidor. (c) Uso de CPU del cliente. (d) Actividad de red del cliente.

Se puede observar una gran diferencia entre las gráficas de las figuras 32, 33 y 34, especialmente en las gráficas que muestran la actividad en el computador cliente. En esta prueba, el administrador de bases de dato debe seleccionar menos del 0,1% de las filas de una tabla que contiene más de 500.000 registros o filas (alrededor de 350 filas son seleccionadas). Las gráficas 32.b, 33.b y 34.b muestran la actividad de red en el servidor, y las gráficas 33.d, 33.d y 33.d muestran la actividad de red en el cliente cuando la prueba se realiza con Microsoft Access, MySQL y PostgreSQL respectivamente. De forma similar, las gráficas 32.a, 33.a y 34.a muestran el uso del CPU en el servidor, y las gráficas 32.c, 33.c y 34.c muestran el uso de CPU en el cliente cuando la prueba se realiza con Microsoft Access, MySQL y PostgreSQL respectivamente.

125

Como ya se mencionó, la actividad de red es el factor que más diferencia a las gráficas de las figuras 32, 33 y 34, aún cuando también existe una notable desigualdad en la forma de las gráficas que indican el uso del CPU. Se puede ver claramente que los tiempos de ejecución de Microsoft Access, mostrados en la tabla 4, son mayores a los de MySQL y PostgreSQL debido a que la actividad de red, es decir, el tiempo que dura la transmisión de los datos, es mayor. Se observó que esta marcada diferencia, en el tiempo de envío de datos, se produce porque Microsoft Access debe enviar todos los datos de la tabla cada vez que ésta se consulta (el administrador de tareas permite observar el número de bytes enviados a través de una conexión de red). Las diferencias entre MySQL y PostgreSQL se podrían atribuir a las capacidades y limitaciones de estos dos sistemas administradores de bases de datos, sin embargo, hasta el momento, no se han hecho cambios, por ejemplo, en los parámetros de configuración ni de MySQL ni de PostgreSQL, es decir, no han sido configurados adecuadamente para el computador y sistema operativo en donde trabajan. Prueba preliminar 4 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE ‘FECHA’ BETWEEN ‘fecha1’ AND ‘fecha2’ AND ‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’. Procedimiento: 1. Se inició el programa de pruebas. 2. Se asignó “23ENERO1” a la variable “nombresectorBTS”, “2005-03-01” a la variable “fecha1” y “2006-03-01” a la variable “fecha2” 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos. 6. Sin cerrar el programa de pruebas, se cambió el nombre de la BTS (variable “nombresectorBTS”) y se repitieron los pasos del 3 al 5. 7. El paso número 6 se repitió 10 veces. 8. Se cerró el programa.

126

La tabla 5 muestra los tiempos de ejecución, en segundos, de cada consulta para cada administrador de bases de datos.

Nombre del sector de la BTS 23ENERO1 MACARDOS1 MAMPORAL2 YAGUARA2 CCCTIN1 GUAREDOS3 ANA2 PIEDAZUL1 USBUNO2 ADJUNDOS1 ACACIAS1

Microsoft Access / Windows (segundos) 22,62

0,985 0,937 0,984 0,953 0,92 0,937 0,938 0,954 0,953 0,937

Microsoft Access / Linux (segundos)

MySQL / Windows (segundos)

MySQL / Linux (segundos)

22,88 0,944 0,921 0,975 0,983 0,934 0,93 0,956 0,976 0,983 0,974

5,799 5,763 5,747 5,763 5,671 5,778 5,763 5,763 5,793 5,81 5,763

5,465 5,36 5,265 5,25 5,422 5,218 5,422 5,516 5,297 5,235 5,124

PostgreSQL / PostgreSQL / Windows Linux (segundos) (segundos) 8,81 8,793 8,75 8,734 8,678 8,735 8,75 8,689 8,771 8,715 8,786

8,85 8,853 8,776 8,916 8,689 8,756 8,811 8,764 8,738 8,722 8,685

Tabla 5. Resultados de la prueba preliminar 4.

A pesar de que se puede pensar que la prueba es idéntica a la prueba preliminar 3, existe una sutil diferencia en el procedimiento que hizo que algunos de los resultados obtenidos en la tabla 5 fueran totalmente distintos a los de la tabla 4. La diferencia fundamental respecto a la prueba preliminar 3 es que las conexiones con los sistemas administradores de bases de datos nunca se cerraron mientras se cambiaba la variable “nombresectorBTS” y se ejecutaba de nuevo la consulta. Los resultados de la tabla 5, al realizar la prueba con MySQL y PostgreSQL, son similares a los de la tabla 4 de la prueba preliminar 3, de hecho, se puede hacer referencia a las gráficas de las figuras 33 y 34 de la prueba preliminar 3 para identificar el uso de red o el uso de procesador de esta prueba preliminar 4. Con Microsoft Access, sin embargo, el uso de la red y el uso del CPU muestran una notable diferencia como se muestra a continuación en la figura 35.

127

(a)

(b)

Figura 35. Uso del CPU (a) y actividad de la red (b) del computador cliente al realizar la prueba preliminar 4 con Microsoft Access / Windows.

Se puede ver que tanto el uso del CPU (gráfica a de la figura 35) como el uso de la red (gráfica b de la figura 35), para Microsoft Access, han disminuido notablemente (100% para el uso de la red) comparados con los resultados y gráficas de la prueba preliminar 3. Sin embargo, llama la atención que en la tabla 5, la primera fila de las columnas con Microsoft Access tiene un valor que es por lo menos 2000% mayor que el resto de los valores de la tabla 5. Comparando este valor con los resultados de la tabla 4 de la prueba preliminar 3, se puede ver que no es un resultado anormal. Se podría llegar a la conclusión de que el comportamiento obedece al valor de la variable “nombresectorBTS”, es decir, si ésta tiene el valor de “23ENERO1”, la consulta toma mucho más tiempo en ejecutarse. Durante esta prueba se pudo observar que cuando se ejecuta una consulta sobre una tabla de Microsoft Access, éste envía todos los datos de la tabla y el cliente los almacena por completo en memoria. Esto hace que la actividad de la red y el uso del CPU tengan gráficas similares a las de la figura 32 de la prueba preliminar 3, al menos durante esta consulta inicial. Como las conexiones con Microsoft Access no se cierran, el controlador no se ve en la obligación de eliminar de la memoria los resultados almacenados, y el efecto es que al momento de realizarse otra consulta sobre la misma tabla, el controlador buscará y procesará la información que se encuentra almacenada en la memoria. Existe un problema, sin embargo, en no cerrar las conexiones con Microsoft Access. Debido a que la tabla que se está consultando, tiene más de 500.000 registros, ocupando más

128

de 200 MB de espacio en disco, la memoria física disponible del computador cliente se puede reducir a menos del 15%, haciendo que el desempeño del computador cliente se reduzca notablemente. Por ejemplo, el tiempo para abrir el programa Adobe Acrobat Reader 6, puede aumentar más de 10 veces. Esto ocurre porque el sistema operativo, para permitir a otro programa hacer uso de la memoria física, debe vaciar parte de ésta y asignársela al programa que quiere ejecutarse, lo que hace que la tarea se ejecute en más tiempo debido a la actividad adicional del CPU. Otro efecto que se observó al ejecutar un programa mientras la memoria del computador cliente está ocupada con la información de una tabla, es que el programa puede hacer que el CPU elimine de la memoria parte de los datos de la tabla, por lo tanto, el controlador al tratar de buscar en memoria esos datos eliminados, deberá buscarlos en el servidor a través de la red. La característica que se debe resaltar en esta prueba, es que la cantidad de datos que se piden de la tabla consultada, no llega a ser más del 0,1% del total y por lo tanto no debe existir la necesidad de enviar todos los datos de la tabla, almacenarlos en memoria y mostrar solamente el 0,1% de los datos enviados y almacenados en memoria. Evidentemente, este comportamiento hace un uso ineficiente e inadecuado de los recursos disponibles. Un último efecto que se observó al mantener las conexiones abiertas con Microsoft Access, es que la memoria del servidor también se carga con la información de la tabla, es decir, el computador servidor, al igual que el computador cliente, almacenan los datos de la tabla en la memoria. Además, el archivo bases de datos de Microsoft Access (archivos con extensión MDB) en donde está ubicada la tabla, queda bloqueado con un atributo de “sólo lectura”, es decir, no se pueden realizar modificaciones en los datos que contiene el archivo. Ninguno de los efectos anteriormente mencionados se observó al ejecutar la consulta a MySQL o a PostgreSQL, es decir, el computador servidor no almacenó en memoria los datos de la tabla consultada y solamente envió al cliente los datos que resultaron de la ejecución y procesamiento de la consulta (no se enviaron los datos de toda la tabla). Obviamente, esto no quiere decir que ni MySQL ni PostgreSQL usan la memoria del computador. Sin duda alguna, estos DBMS hacen uso de la memoria del computador para procesar las consultas y comandos recibidos, la diferencia está en que la memoria se usa mientras se procesa la información y luego se libera. Además, la cantidad de memoria que usan para procesar la información puede

129

ser modificada e incluso, se puede modificar la cantidad de memoria que usan para almacenar los resultados.

Prueba preliminar 5 Se ejecutó la consulta SELECT * FROM par_hoc. Procedimiento: 7. Se inició el programa de pruebas 8. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 9. Se ejecutó la consulta a otro de los tres administradores de bases de datos. 10. Se ejecutó la consulta al último de los tres administradores de bases de datos. 11. Se cerró el programa de pruebas. 12. Se ejecutaron 5 veces los pasos del 1 al 5. La tabla 6 muestra los tiempos de ejecución, en segundos, de cada consulta para cada administrador de bases de datos. Microsoft Access / Windows (segundos) 2,093 2,112 2,081 2,106 2,09

Microsoft Access / Linux (segundos)

MySQL / Windows (segundos)

MySQL / Linux (segundos)

2,126 2,122 2,108 2,115 2,118

> 600 > 600 > 600 > 600 > 600

> 600 > 600 > 600 > 600 > 600

PostgreSQL / PostgreSQL / Windows Linux (segundos) (segundos) > 600 > 600 > 600 > 600 > 600

> 600 > 600 > 600 > 600 > 600

Tabla 6. Resultados de la prueba preliminar 5. Los resultados de la tabla 6 son impresionantes. La consulta realizada, como se mencionó en el capítulo 6, pone a prueba la capacidad de procesar múltiples tablas simultáneamente, y de ejecutar varios procesos anidados. Con resultados como los mostrados en la tabla 6 se pudiera llegar a la conclusión apresurada de descartar a MySQL y a PostgreSQL como posible sistemas administradores de bases de datos y coronar a Microsoft

130

Access como el mejor. Nuevamente, se debe recordar que los parámetros de los administradores de bases de datos no han sido modificados. La idea fundamental de realizar estas pruebas preliminares fue la de tener una idea inicial acerca del desempeño, características de funcionamiento y efectos de distintas consultas en los distintos administradores de bases de datos. Al mismo tiempo, se buscó identificar situaciones clave en el proceso de optimización. Para resumir esta sección, se puede decir lo siguiente: − Microsoft Access ofrece menores tiempos de ejecución que MySQL o PostgreSQL, cuando se trata de buscar y enviar información de una tabla de gran tamaño. − PostgreSQL posee mayor velocidad de procesamiento que Microsoft Access o MySQL, cuando se trata de ordenar los datos de una tabla de gran tamaño y con un gran número de registros. − MySQL busca con mayor rapidez que Microsoft Access o PostgreSQL, cuando se quiere seleccionar una pequeña parte de una tabla que posee un gran tamaño. − Microsoft Access es mucho más rápido que MySQL o PostgreSQL, cuando existe la necesidad de procesar varias tablas simultáneamente. Hay que recordar que estas pruebas fueron realizadas desde el computador 3. Los resultados de algunas de estas pruebas pueden variar en más del 50% dependiendo de las capacidades del computador que ejecuta el programa de pruebas, por ejemplo, con un computador con un procesador AMD Sempron de 1.6 GHz, y 448 MB de memoria RAM (512 MB – 64 MB de video), los resultados para la prueba preliminar 1 con Microsoft Access tuvieron valores de 76 segundos o más. Otro factor que afecta los resultados y que a pesar de ser obvio hay que mencionarlo, es la cantidad de procesos que se estén ejecutando tanto en el cliente como en el servidor. Programas de antivirus, de procesamiento gráfico, de navegación en Internet, aún cuando no estén ejecutando alguna tarea, están haciendo uso de la memoria del computador. Aunque no se muestran tablas o gráficas, se realizaron algunas de las pruebas con varios de estos

131

programas en ejecución, y efectivamente los tiempos de ejecución en algunos casos aumentaron en más del 100%.

8.1.2 Resultados de las pruebas finales Antes y durante la ejecución de estas pruebas, se realizaron modificaciones a varios componentes involucrados en el desempeño de los sistemas administradores de bases de datos (principalmente la configuración de éstos) para optimizar y mejorar su funcionamiento y reducir los tiempos de procesamiento. El objetivo principal de las modificaciones fue la de hacer que los administradores de bases de datos hicieran mejor uso de los recursos disponibles, por ejemplo, usar mayor cantidad de memoria para realizar operaciones de búsqueda, evitar que los datos que se encuentran en memoria se escriban constantemente en el disco, reducir la cantidad de memoria que se reserva para un proceso para que éste no use toda la memoria y sature al procesador, modificar las definiciones de algunas tablas, agregar, modificar o eliminar índices de las tablas, hacer que los controladores o drivers almacenen o no los resultados de las consultas, etc. Como se mencionó en el capítulo 6, no se presentarán los procedimientos seguidos para realizar las modificaciones, ni los valores de los parámetros modificados ya que muchas de las modificaciones realizadas dependen de las características, capacidades y limitaciones del equipo y del sistema operativo en donde están instalados los administradores de bases de datos. A través de las referencias de este libro, en particular [29] y [30] (manuales de MySQL y PostgreSQL), el lector se puede iniciar en el proceso de convertirse en un administrador de bases de datos para optimizar el desempeño de los DBMS MySQL y PostgreSQL. Cuando sea necesario, sin embargo, se mencionará el efecto de las modificaciones realizadas cuyo efecto fue el más significativo en los resultados.

132

Prueba final 1 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS`. Procedimiento: 1. Se configuró el programa de pruebas para que las conexiones y los resultados tuvieran cursores ADO manejados por el servidor. 2. Se inició el programa de pruebas. 3. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 4. Se esperó hasta que se mostraran por pantalla los resultados. 5. Se cerró el programa de pruebas 6. Se ejecutaron los pasos del 2 al 5, para los tres administradores sin orden específico. 7. Se ejecutó el paso anterior 5 veces. Los tiempos de ejecución de esta prueba se muestran en la tabla 7. MySQL / Linux (segundos) 112,575 107,813 111,629 111,99 109,217

PostgreSQL / Linux (segundos) 194,26 196,879 205,423 201,774 196,331

Tabla 7. Resultados de la prueba final 1. La tabla 7 sólo muestra los resultados obtenidos al ejecutar la prueba con MySQL / Linux y PostgreSQL / Linux. Esto se debe a que los resultados con Microsoft Access / Windows y Microsoft Access / Linux son similares a los de la tabla 2 de la prueba preliminar 1. Los resultados con MySQL / Windows y PostgreSQL / Windows fueron similares (no se observó una variación mayor al 10%) a los mostrados en la tabla 7 para MySQL / Linux y PostgreSQL / Linux, respectivamente. En comparación con los resultados de la tabla 2 de la prueba preliminar 1, la tabla 7 muestra tiempos de ejecución considerablemente menores (aproximadamente 65% menores para MySQL y 25% menores para PostgreSQL). Esto se debe, como se dijo al inicio de la

133

sección 8.1.2, a modificaciones hechas a la configuración de los administradores de bases de datos, entre las cuales están el aumento de la memoria compartida usada por los DBMS, eliminación de escritura automática de los datos en memoria al disco, aumento de la memoria compartida de los sistemas operativos, modificación de los parámetros de los controladores ODBC (“Use Declare / Fetch” y “Don’t Cache Result”, por ejemplo), modificación de la configuración de la red y del protocolo TCP/IP de los sistemas operativos, etc. En MySQL, por ejemplo, las bases de datos se crearon usando el motor de almacenamiento (Storage Engine) MyISAM que según [29], es un motor de búsqueda no transaccional que ofrece alta velocidad de almacenamiento y recuperación de datos. También se aumentó la cantidad de memoria destinada a realizar operaciones de búsqueda en bases de datos del tipo MyISAM (“myisam_sort_buffer_size”), se redujo la cantidad de procesos almacenados en memoria (“thread_cache_size”) y la cantidad de memoria reservada para procesar tablas y bases de datos creadas con el motor de almacenamiento InnoDB (skipinnodb). En PostgreSQL, se aumentó un parámetro que indica relativamente el tiempo de búsqueda de datos en disco (“random_page_cost”), se aumentó la cantidad de memoria usada para efectuar operaciones de ordenamiento (“sort_mem”), se redujo la cantidad de archivos que cada proceso puede mantener abiertos (“max_files_per_process”), se aumentó la cantidad disponible de memoria compartida (“shared_buffers”), se aumentó el tiempo entre ejecuciones de procesos de mantenimiento de las bases de datos (“bg_writter_delay”), etc. Todas las modificaciones mencionadas anteriormente, entre otras, contribuyeron a la disminución del tiempo de ejecución de la prueba, sin embargo, el objetivo principal de esta prueba fue el de observar el efecto de los cursores ADO en el desempeño de los sistemas administradores de bases de datos. En Visual Basic los cursores ADO se asignan a objetos que almacenan los resultados llamados “recordsets”. Para esta prueba, se estableció la siguiente propiedad de un objeto “recordset”: “ADOrecordset.CursorLocation=adUseServer”, es decir, el programa de pruebas se modificó para que los cursores fueran manejados por el servidor. El efecto de esta configuración sobre Microsoft Access es que además de cargar la memoria física disponible en el computador cliente, la memoria física en el computador servidor también se llena con los datos de la tabla. En MySQL, la configuración del cursor no tiene efecto alguno.

134

En PostgreSQL, sin embargo, la memoria del cliente no se llena con los resultados de la consulta. Es la memoria del servidor quien almacena los resultados. Esto es posible solamente si la opción “Use Declare/Fetch” está habilitada ya que ésta permite que el controlador ODBC de PostgreSQL almacene en memoria solamente una cantidad específica de información, por ejemplo, 512 KB. Si se quiere buscar registros o filas que no hayan sido almacenadas por el controlador ODBC, éste debe buscarlas en el servidor a través de la red. El efecto de usar cursores en el servidor también trae otras consecuencias para PostgreSQL. Debido a que es el controlador ODBC quien envía los comandos SQL para abrir, mover y cerrar los cursores que mantiene el servidor, se genera un exceso de información que debe ser transmitida a través de la red (el controlador ODBC envía comandos para mover los cursores, por ejemplo, y el servidor los responde entregando los datos de la fila del cursor e información adicional para que el controlador pueda saber en donde se encuentra el cursor). En cualquier caso, no es recomendable cargar la memoria del servidor ya que en éste se pueden estar realizando tareas que son fundamentales para una empresa y que requieren grandes cantidades de memoria, por ejemplo. Además, si el servidor es consultado por varios clientes al mismo tiempo, entonces los recursos disponibles se reducirán muy rápidamente haciendo que el desempeño general del servidor sea bajo.

Prueba final 2 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS`. Procedimiento: 1. Se configuró el programa de pruebas para que las conexiones y los resultados tuvieran cursores ADO manejados por el cliente. 2. Se inició el programa de pruebas. 3. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 4. Se esperó hasta que se mostraran por pantalla los resultados. 5. Se cerró el programa de pruebas 6. Se ejecutaron los pasos del 1 al 4, para los tres administradores sin orden específico. 7. Se ejecutó el paso anterior 5 veces.

135

Al igual que la prueba final 1, con la ejecución de esta prueba se quiso observar el efecto de los cursores ADO en el desempeño de los sistemas administradores de bases de datos. Los resultados obtenidos en esta prueba no tuvieron una variación de más del 5% respecto a los resultados de la prueba final 1, sin embargo, la mayor diferencia se encontró en el manejo de memoria en el servidor y en el cliente. Usando cursores ADO manejados por el cliente, el servidor solamente se encarga de enviar los datos y el cliente de almacenarlos. Esto ocurre con MySQL y con PostgreSQL, es decir, cuando ellos reciben la consulta, usan memoria para buscar y enviar los datos. Luego de que finaliza la operación de transmisión de datos a través de la red, liberan la memoria usada. Con Microsoft Access, sin embargo, tanto el cliente como el servidor almacenan los resultados en memoria (como en las pruebas preliminares). Como ya se mencionó anteriormente, ésta es una situación indeseable ya que se usan ineficientemente los recursos de los computadores especialmente los recursos del servidor quien el que debe ser capaz de realizar mayor cantidad de tareas.

Prueba final 3 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY `FECHA`. Procedimiento: 1. Se inició el programa de pruebas. 2. Se ejecutó la consulta solamente a uno de los tres administradores de bases de datos. 3. Se esperó hasta que se mostraran por pantalla los resultados. 4. Se cerró el programa de pruebas. 5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden específico. 6. Se ejecutó el paso anterior 5 veces. La tabla 8 muestra los resultados obtenidos al realizar la prueba final 3 con MySQL y PostgreSQL. Los resultados con Microsoft Access no se muestran debido a que los tiempos

136

obtenidos fueron similares (no cambiaron en más de un 10%) a los de la tabla 3 de la prueba preliminar 2. MySQL / Linux (segundos) 175,265 179,5 177,023 181,491 177,874

PostgreSQL / Linux (segundos) 284,656 291,312 286,155 286,75 287,351

Tabla 8. Resultados obtenidos al realizar la prueba final 3. Los efectos de las modificaciones realizadas a los parámetros de configuración de los DBMS se pueden ver al comparar los resultados de la tabla 8 con los de la tabla 3 de la prueba preliminar 2. La diferencia en los resultados es notable con MySQL y se puede ver que los tiempos de ejecución se redujeron en más del 50%. Esta reducción se observó en el tiempo de procesamiento de los datos, el cual se redujo de aproximadamente 200 segundos en la prueba preliminar 2, a 70 segundos en esta prueba final 3. No obstante, en esta prueba no hubo cambios significativos ni en Microsoft Access (diferencias de no más del 5%) ni en PostgreSQL (diferencias de no más del 10%).

Prueba final 4 Se ejecutó la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE ‘FECHA’ BETWEEN ‘fecha1’ AND ‘fecha2’ AND ‘celda’=’nombresectorBTS’ ORDER BY ‘FECHA’. Procedimiento: 1. Se inició el programa de pruebas. 2. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 3. Sin cerrar el programa de pruebas, se cambió el nombre de la BTS (variable “nombresectorBTS”) y se repitió el paso anterior.

137

4. El paso número 3 se repitió 10 veces. 5. Se cerró el programa 6. Se repitieron los pasos del 1 al 5 cambiando el administrador de bases de datos en el paso 2. 7. Se repitieron los pasos del 1 al 5 cambiando el administrador de bases de datos en el paso 2. Como se mencionó en las pruebas preliminares 3 y 4, mantener una conexión abierta con una tabla de Microsoft Access que tenga un gran tamaño (que ocupe más del 25% de la memoria total), puede deteriorar el desempeño del computador cliente considerablemente, ya que toda la tabla es almacenada en la memoria de ese computador. Debido a que esto no ocurre ni con MySQL ni con PostgreSQL, solamente se abren y cierran las conexiones con Microsoft Access (la herramienta Daily Optimizer de la Coordinación de Optimización de Digitel GSM usa el método de abrir y cerrar las conexiones para evitar sobrecargar los clientes o estaciones de trabajo que son los PC usados por el personal). En la tabla 9 se muestran los resultados de la prueba realizada con Microsoft Access / Windows, MySQL / Linux y PostgreSQL / Linux.

Nombre del sector de la BTS 23ENERO1 MACARDOS1 YAGUARA2 CCCTIN1 GUAREDOS3 ANA2 PIEDAZUL1 USBUNO2 HIGUEROT3 TAHONA1 ESTANCIA2

Microsoft Access / Windows (segundos) 28,196 28,165 27,984 27,984 28,025 27,991 27,974 27,988 27,961 27,986 27,977

MySQL / Windows (segundos)

MySQL / Linux (segundos)

4,484 4,389 0,858 5 4,343 3,967 5,078 3,828 4,75 4,453 3,889

5,108 5,077 5,112 5,093 5,078 5,13 5,159 5,124 5,148 5,084 5,025

PostgreSQL / PostgreSQL / Linux Windows (segundos) (segundos) 3,326 3,375 3,276 3,25 3,205 3,346 3,312 3,241 3,318 3,303 3,21

4,639 4,405 0,922 4,891 4,325 4,764 4,323 4,412 4,586 4,734 4,412

Tabla 9. Resultados de la prueba final 4. Si se hace referencia a los resultados de la tabla 5 de la prueba preliminar 4, y se comparan con los de la tabla 9, se puede ver claramente que Microsoft Access es el DBMS

138

que ofrece mejor desempeño y mayor velocidad, sin embargo, como también se mencionó en la prueba preliminar 4, la memoria del cliente se llena con los datos de la tabla y el se ve afectado negativamente. Nuevamente, como también se mencionó en la prueba preliminar 4, cuando se ejecuta la consulta de esta prueba con MySQL y PostgreSQL, el servidor es quien realiza todas las operaciones necesarias sobre las tablas y solamente entrega al cliente los datos o filas necesarias. Los resultados de la tabla 9, comparados con los resultados de las tablas 4 y 5 de las pruebas preliminares 3 y 4, muestran una diferencia de menos del 15% con MySQL / Linux y en algunos casos, una diferencia de más de 25% con MySQL / Windows. Con PostgreSQL / Linux, la diferencia fue de más del 60% y con PostgreSQL / Windows la diferencia fue de aproximadamente 45%. Durante la ejecución de la prueba se observó que al realizar consultas similares a las anteriores, es decir, el mismo valor para la variable “nombresectorBTS” pero diferentes valores para las variables “fecha1” y “fecha2”, los tiempo de ejecución tanto para PostgreSQL como para MySQL re reducen en algunos casos a menos del 10% (en general, menos de 0,5 segundos) de los valores mostrados en la tabla 9. Esto se debe a la capacidad de los DBMS PostgreSQL y MySQL, de mantener en memoria, parte de las tablas que se consultan, historial de consultas, planes de ejecución de consultas, etc. Este comportamiento se conoce en MySQL como “query cache” o caché de consulta que permite al administrador de bases de datos almacenar en memoria la estructura (el comando SQL) de la consulta y los resultados enviados al cliente, de manera que si esa consulta se ejecuta nuevamente, los resultados se buscarán inmediatamente en la memoria y no habrá necesidad de ejecutar la consulta nuevamente. En MySQL, esto ocurre solamente si la consulta es exactamente igual a otra previamente realizada, en este sentido, según [29] las siguientes consultas no son iguales para los efectos del “query cache” o caché de consulta: SELECT * FROM tbl_name Select * from tbl_name La velocidad con que MySQL entrega los resultados almacenados por la caché de consulta depende, obviamente, de la cantidad y tamaño de los datos almacenados ya que éstos deben ser enviados al cliente. Para consultas como la ejecutada en esta prueba, el tiempo transcurrido, entre el envío del comando SQL y la recepción de los resultados, puede llegar a ser menor a 0,1 segundos. Sin embargo, si se asigna demasiada memoria a esta caché de

139

consulta y las consultas realizadas no son siempre exactamente iguales, entonces el desempeño de MySQL se ve afectado negativamente ya que éste ocupa mucho de su tiempo en almacenar los resultados y las consultas en la caché, y descuida el procesamiento de las bases de datos. Otro efecto de reservar “demasiada” memoria a la caché de consulta, es que MySQL no hace uso efectivo de la memoria para procesar la información de las bases de datos, ya que la mayoría de la memoria asignada a MySQL por el sistema operativo, está destinada para almacenar comandos y resultados, por lo tanto, el desempeño de MySQL disminuye. A pesar de que PostgreSQL no posee una caché de consulta, si es capaz de recordar los planes escogidos para realizar o ejecutar una consulta. PostgreSQL usa un planificador y optimizador de consultas basado en algoritmos genéticos (GEQO; Genetic Query Optimizer) [30], el cual almacena los planes ejecutados para realizar las consultas y como resultado de esto, se pueden obtener tiempos de ejecución mucho menores. Además, el controlador posee una caché de datos que se modifica con la opción “Cache size”. Con estas dos características de PostgreSQL, se obtuvieron tiempos similares a los que se obtuvieron con MySQL cuando la caché de consulta se habilitó, es decir, los tiempos obtenidos fueron de menos de 0,5 segundos y en algunos casos tiempos menores a 0,1 segundos.

Prueba final 5 Se ejecutó la consulta SELECT * FROM par_hoc. Procedimiento: 1. Se inició el programa de pruebas 2. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 3. Se ejecutó la consulta a otro de los tres administradores de bases de datos. 4. Se ejecutó la consulta al último de los tres administradores de bases de datos. 5. Se cerró el programa de pruebas. 6. Se ejecutaron 5 veces los pasos del 1 al 5.

140

Microsoft Access / Windows (segundos) 1,523 1,406 1,484 1,344 1,375

MySQL / Windows (segundos)

MySQL / Linux (segundos)

0,345 0,343 0,338 0,353 0,35

0,734 0,719 0,735 0,75 0,734

PostgreSQL / PostgreSQL / Linux Windows (segundos) (segundos) 0,857 0,864 0,895 0,864 0,89

0,733 0,703 0,813 0,704 0,812

Tabla 10. Resultados de la prueba final 5.

Los resultados de la tabla 10 comparados con los de la tabla 6 de la prueba preliminar 5, son impactantes. Los tiempos para MySQL y PostgreSQL se redujeron a menos del 0,15%. También se puede observar una diferencia, en algunos casos, de más del 50% entre los resultados obtenidos con MySQL bajo Windows y los resultados obtenidos con MySQL / Linux. Otra observación acerca de los resultados de la tabla 10 es que MySQL tiene tiempos que son 75% menores a los de Microsoft Access, y PostgreSQL tiene tiempos que son 50% menores a los de Microsoft Access. Las modificaciones más importantes que se hicieron antes de realizar esta prueba fueron eliminar, modificar y crear índices en las tablas procesadas por la consulta, asignar mayor cantidad de memoria al buffer que almacena los índices de las tablas, y modificar parámetros de los optimizadores de consultas para que hicieran búsquedas de datos a través de los índices (Index scan), en lugar de hacer búsquedas secuenciales de los datos de las tablas (Table scan o sequential scan).

Prueba final 6 Se ejecutaron las siguientes consultas: SELECT * FROM `objects`

(tabla)

SELECT * FROM `power_control`

(tabla)

SELECT * FROM `handover_control`

(tabla)

SELECT * FROM `bcf_id`

(vista)

141

SELECT * FROM `bts_id`

(vista)

SELECT * FROM `bts_id_bsc_id_name`

(vista)

SELECT * FROM `poc_id`

(vista)

SELECT * FROM `trx_id`

(vista)

SELECT * FROM `par_adj_cell`

(vista)

SELECT * FROM `par_trx`

(vista)

SELECT * FROM `par_poc`

(vista)

Procedimiento: 1. Se inició el programa de pruebas. 2. Se seleccionó una consulta. 3. Se ejecutó la consulta a uno de los tres administradores de bases de datos. 4. Se ejecutó la consulta a otro de los tres administradores de bases de datos. 5. Se ejecutó la consulta al último de los tres administradores de bases de datos. 6. Se escogió otra consulta y se repitieron los pasos del 3 al 5. 7. El paso número 6 se repitió 5 veces. 8. Se cerró el programa de pruebas. Las tablas 11 y 12, muestran los tiempos obtenidos al ejecutar las consultas de esta prueba final 6. Para evitar tablas grandes y engorrosas de leer, las tablas 11 y 12 solamente muestran el promedio de los 5 tiempos de ejecución obtenidos al ejecutar cada consulta.

142

Consulta realizada

Microsoft PostgreSQL / MySQL / Linux Access / Linux Linux (segundos) (segundos) (segundos)

1 SELECT * FROM `objects` 2 SELECT * FROM `power_control` 3 SELECT * FROM `handover_control`

2,468

5,046

4,61

0,25

0,25

0,5

0,875

0,75

0,75

4 SELECT * FROM `bcf_id` 5 SELECT * FROM `bts_id` 6 SELECT * FROM `bts_id_bsc_id_name`

1,157

1,454

1,047

0,889

1,125

0,125

1,422

0,172

0,218

7 SELECT * FROM `poc_id` 8 SELECT * FROM `trx_id` 9 SELECT * FROM `par_adj_cell`

1,562

1,187

0,687

0,921

0,264

0,141

3,844

33,315

5,906

10 SELECT * FROM `par_trx` 11 SELECT * FROM `par_poc` 12 SELECT * FROM `trx_bcch`

1,922

2,031

3,64

1,188

0,781

0,703

3,141

23,266

10,655

Tabla 11. Resultados de la prueba final 6 (Linux).

Consulta realizada 1 SELECT * FROM `objects` 2 SELECT * FROM `power_control` 3 SELECT * FROM `handover_control` 4 SELECT * FROM `bcf_id` 5 SELECT * FROM `bts_id` 6 SELECT * FROM `bts_id_bsc_id_name` 7 SELECT * FROM `poc_id` 8 SELECT * FROM `trx_id` 9 SELECT * FROM `par_adj_cell` 10 SELECT * FROM `par_trx` 11 SELECT * FROM `par_poc` 12 SELECT * FROM `trx_bcch`

Microsoft Access / Windows (segundos) 2,89

MySQL / Windows (segundos)

PostgreSQL / Windows (segundos)

3,125

5,875

0,282

0,485

0,781

0,438

0,765

1,375

1,078

0,827

1,186

0,719

0,219

0,077

1,096

0,119

0,094

1,5

0,75

0,875

1,328

0,108

0,11

4,172

25,922

5,125

2,422

1,407

4,297

1,219

0,469

0,968

2,531

22,078

12,031

Tabla 12. Resultados de la prueba final 6 (Windows).

En las tablas 11 y 12 se pueden ver varios valores que llaman la atención y son los que corresponden a MySQL cuando se ejecutaron las consultas 9 y 12, y los que corresponden a

143

PostgreSQL al ejecutarse la consulta 12. Para estas consultas, los tiempos de MySQL son por lo menos dos veces mayores a los tiempos de PostgreSQL. En varias de las consultas mostradas en las tablas 11 y 12,

se observó un

comportamiento interesante en la actividad de red del computador cliente. En la figura 36, se muestra la actividad de red en el cliente al ejecutar varias de las consultas mostradas en la tabla 11. Por ejemplo, en la figura 36.a, se muestra la actividad de red del cliente al ejecutar la consulta 1 (SELECT * FROM objects).

(a)

(b)

(c)

(d)

Figura 36. Actividad de la red en el computador cliente al ejecutar varias de las consultas de la tabla 11. (a) SELECT * FROM `objects`. Orden de ejecución: PostgreSQL, MySQL y Microsoft Access. (b) SELECT * FROM `poc_id` Orden de ejecución: Microsoft Access, MySQL (identificada por los dos picos “unidos”) y PostgreSQL (último pico). (c) SELECT * FROM `par_trx`. Orden de ejecución: PostgreSQL, Microsoft Access y MySQL. (d) SELECT * FROM `trx_bcch`. Orden de ejecución: MySQL, PostgreSQL y Microsoft Access. (Sólo se muestra la actividad de la red con Microsoft Access, ya que con MySQL y PostgreSQL, ésta fue menor al 2%, según se observó, en tiempo real, en el administrador de tareas). Haciendo referencia a las gráficas de la figura 25 de la prueba preliminar 1, la velocidad de transmisión promedio de PostgreSQL es de aproximadamente 17%, esto se puede ver también en la figura 36.a. MySQL tiene una actividad de red similar, sin embargo, luego de 3 segundos aproximadamente, la actividad de la red cae por debajo de 5.88% y se prolonga por otros tres segundos aproximadamente. La actividad de la red durante la consulta a Microsoft Access alcanza el 50% y se prolonga por aproximadamente 3 segundos. Este uso

144

de la red, como se dijo anteriormente, es la principal diferencia entre Microsoft Access y los otros dos DBMS; MySQL y PostgreSQL. El resto de las gráficas muestra como Microsoft Access, con cada consulta, transmite mayor cantidad de datos que MySQL y PostgreSQL. Esto se debe, como se ha mencionado varias veces, a que Access debe enviar todos los datos de una tabla cada vez que se consulta. Durante la ejecución de esta prueba final 6, se pudo observar que no se presentó la situación en donde Microsoft Access carga la memoria del computador cliente, debido a que las tablas consultadas son pequeñas (poseen un tamaño menor al 5% de la memoria física del computador cliente), lo que se evidencia con la corta duración de la transmisión de datos respecto a las gráficas de las pruebas preliminar 3, por ejemplo. Sin embargo, sí ocurre algo similar a las pruebas preliminares 3 y 4 y a la prueba final 4, en donde menos del 5% de las filas y/o columnas de una tabla son seleccionadas, entonces el desempeño de Microsoft Access se ve afectado negativamente ya que éste siempre envía todos los datos de la tabla consultada. Esto se puede ver en los resultados de la consulta 7 de las tablas 11 y 12, y en la figura 36.b, en donde “poc_id” es una vista que a pesar de seleccionar todas las filas de una tabla (más de 30.000), solamente selecciona 2 de las 35 columnas que ésta posee. Cabe destacar que estas dos columnas seleccionadas almacenan datos numéricos y que el resto de las columnas almacenan otros tipos de datos como cadenas de texto y marcas de tiempo o “timestamps”. Los datos numéricos de mayor tamaño manejados por los DBMS bajo estudio, poseen 8 bytes (datos del tipo float 8 o doble precisión (double precision)), en cambio, cada carácter en una cadena de texto ocupa un tamaño de 1 byte. En el caso de la tabla usada por la consulta 7 de las tablas 11 y 12, algunas de las columnas de tipo cadena de texto, su usan para almacenar la dirección geográfica de una BTS, la cual puede ocupar hasta 80 caracteres. Debido a los resultados de la consultas 9 y 12 de las tablas 11 y 12, se decidió hacer una prueba adicional que involucrara estas consultas. La herramienta Parameter de la Coordinación de Optimización realiza las siguientes consultas: 1. SELECT * FROM parameters.par_adj_cell WHERE "bts_id_NAME"='nombresectorBTS' AND "OBJECT_INSTANCE"='número' 2. SELECT * FROM parameters.trx_bcch WHERE "NAME"='nombresectorBTS'

145

La prueba consistió en ejecutar las consultas 1 y 2 de la herramienta Parameter con diferentes valores para las variables involucradas (“nombresectorBTS” y “número”). Las tablas 13 y 14 muestran los resultados obtenidos.

Nombre del sector de la BTS OCUMAUNO3 AEROINTER4 DOSCAMIN1 TRINIDOS1 GUAIRA2

Microsoft Access / Windows (segundos) 3,375 3,139 3,125 3,078 3,203

MySQL / Linux (segundos)

PostgreSQL / Linux (segundos)

2,889 2,432 2,468 2,704 2,359

0,094 0,047 0,062 0,047 0,094

Tabla 13. Resultados obtenidos al realizar la consulta 1 de la herramienta Parameter.

Nombre del sector de la BTS SILENDOS3 BETANIA1 USBDOS1 FLORIDA2 VEGA3

Microsoft Access / Windows (segundos) 2,407 2,375 2,625 2,485 2,391

MySQL / Linux (segundos)

PostgreSQL / Linux (segundos)

0,086 0,064 0,118 0,25 0,077

0,112 0,123 0,11 0,125 0,094

Tabla 14. Resultados obtenidos al ejecutar la consulta 2 de la herramienta Parameter.

Se debe mencionar una vista o view, en particular, usada por las herramientas de la Coordinación de Optimización. Esta vista, llamada “par_bts”, selecciona más de 255 columnas de una tabla. Con Microsoft Access esto no es posible, ya que existen limitaciones en cuanto al número máximo de columnas que puede tener una tabla o una fila de resultados. El personal de la Coordinación de Optimización tuvo que recurrir a la separación de estas columnas en tres vistas separadas, y luego unirlas de nuevo para ser mostradas por pantalla. MySQL y PostgreSQL pueden almacenar tablas con más de 255 columnas, lo que representa claramente una mejora u optimización al momento de procesar y mostrar los datos de la tabla. También se debe mencionar que las tablas usadas por las consultas de la prueba preliminar 5, de la prueba final 5 y de la prueba final 6, son tablas enlazadas, es decir, las

146

tablas pertenecen a otro DBMS que no es Microsoft Access (en este caso, pertenecen al sistema administrador de bases de datos Oracle) y son consultadas a través de un controlador ODBC. Esto quiere decir, que el procesamiento de datos no es realizado por Access, solamente el envío de la información. De todas las pruebas realizadas anteriormente y del análisis presentado, se pueden hacer las siguientes observaciones finales: − Microsoft Access realiza la transmisión de datos a través de la red con mayor velocidad que MySQL y que PostgreSQL. − Los tiempos obtenidos con MySQL bajo Windows, son menores que los obtenidos con MySQL bajo Linux. Contrario a esto, los tiempos de PostgreSQL bajo Windows son mayores a los tiempos de PostgreSQL bajo Linux (en más del 50% de las pruebas realizadas). − Las consultas que involucran procesamiento de tablas grandes y selección de una cantidad de filas menor al 10% del total de las filas de la tabla, se realizan en menor tiempo en MySQL y PostgreSQL que en Microsoft Access. − Cuando se realiza una consulta a Microsoft Access, éste almacena toda la información contenida en la tabla consultada, tanto en la memoria del computador cliente como en la memoria del servidor. Los resultados permanecen en memoria hasta que se cierra la conexión con Microsoft Access. − Al ejecutar una consulta a MySQL o PostgreSQL, éstos hacen uso de la memoria del computador para procesar los datos, y solamente almacenan en memoria los resultados de la consulta. Dependiendo de los parámetros de configuración, los resultados se almacenan en la memoria del cliente (cursores manejados por el cliente), del servidor (cursores manejados por el servidor), o de ambos (caché de consulta). − Microsoft Access siempre debe enviar al cliente todos los datos de la tabla que se está consultando. MySQL y PostgreSQL, solamente envían los resultados de la consulta. − En las pruebas en donde se requiere procesamiento simultáneo de varias tablas, y selección de una pequeña parte de todas las tablas y filas procesadas, PostgreSQL ofrece menores tiempos de consulta que Microsoft Access y MySQL.

147

En el capítulo 9 se mencionan las conclusiones del estudio comparativo realizado y desarrollado a lo largo de este libro.

8.2

Herramienta para el cálculo de adyacencias Para probar el funcionamiento correcto de la herramienta desarrollada para el cálculo

automático de las adyacencias, fue suficiente comparar las adyacencias calculadas por la herramienta con las adyacencias seleccionadas por el personal de la Coordinación de Optimización luego de realizar las pruebas de campo necesarias. En la sección 8.2.1 se muestran tablas en donde aparecen las adyacencias seleccionadas por el personal de la Coordinación de Optimización (columna “Adyacencias reales” y las adyacencias calculadas con la herramienta (“Adyacencias aproximadas”).

8.2.1 Pruebas realizadas A continuación se presentan todos los resultados de las pruebas realizadas. Como se mencionó anteriormente, las pruebas se basan en la comparación de dos métodos para la selección de adyacencias. Las tablas muestran los nombres de las adyacencias seleccionadas por el personal de la Coordinación de Optimización y las adyacencias calculadas por la herramienta desarrollada con tres configuraciones distintas. Para indicar que la herramienta pudo calcular la misma adyacencia que fue seleccionada por el personal de la Coordinación de Optimización, se utiliza el símbolo “ ”. También se muestran las adyacencias calculadas por la herramienta que no aparecen en la lista de las “adyacencias reales”.

148

Adyacencias reales

Adyacencias aproximadas (1)

23ENERO2 23ENERO3 AGUASALU1 AGUASALU2 PZOLEARY2 AVBARALT2 AVSUCRE1 AVSUCRE2 AVSUCRE3 CATIAUNO1 CATIAUNO2 COTAMIL2 DIEX2 FERMTORO2 FLOREUNO1 FLOREUNO2 MANICOMI1 MIRAFLOR2 MIRAFLOR3 PAROESTE1 PASTODOS2 PASTODOS3 PASTOUNO2 QTACPDOS1 QTACPDOS3

Adyacencias aproximadas (2)

Adyacencias aproximadas (3)

PAROESTE2

MARTIUNO1 NVACCUNO1

Tabla 15. Adyacencias para el sector 23ENERO1. (1) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 15º, apertura de antena adicional para la nueva BTS = 0º, apertura de antena adicional para el resto de las BTS = 0º. (2) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 30º, apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º. (3) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 60º, Apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º.

149

Adyacencias aproximadas (1) 23ENERO1 AVBARALT2 23ENERO2 CATIADOS1 AGUASALU1 FERMTORO2 AGUASALU2 AVSUCRE2 AVSUCRE3 FLOREUNO1 MANICOMI1 FLOREDOS1 MIRAFLOR3 PASTODOS1 PAROESTE2 PASTODOS2 PZOLEARY2 PASTODOS3 PASTOUNO2 Adyacencias reales

Adyacencias aproximadas (2) CARMELIT3

Adyacencias aproximadas (3) CARMELIT1 CATIAUNO2

FLOREDOS1 NVACCUNO1

Tabla 16. Adyacencias para el sector AVSUCRE1. (1) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 15º, apertura de antena adicional para la nueva BTS = 0º, apertura de antena adicional para el resto de las BTS = 0º. (2) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 30º, apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º. (3) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 60º, Apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º.

150

Adyacencias reales AVBARALT1 CAPITOL2 CAPUCHIN1 CAPUCHIN2 CARMELIT2 CARMELIT3 DIEX1 DIEX2 ESQHOSP3 MADERERO1 MADERERO2 MARTIUNO1 MIRAFLOR2 MIRAFLOR3 MONZON1 MONZON3 PZOLEARY1 PZOLEARY2 QTACPDOS1 QTACPDOS3 QTACPUNO1 ROSALIA3 SILENUNO3 SOCIEDAD1

Adyacencias aproximadas (1)

Adyacencias aproximadas (2)

Adyacencias aproximadas (3)

AVBOLIVA3

SOCIEDAD2

FRANCIA2

HOYAUNO2 METROCEN1 QTACPTRE2

QTACPUNO3

Tabla 17. Adyacencias para el sector MADERERO3. (1) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 15º, apertura de antena adicional para la nueva BTS = 0º, apertura de antena adicional para el resto de las BTS = 0º. (2) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 30º, apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º. (3) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 60º, Apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º.

151

Adyacencias reales

Adyacencias aproximadas (1)

Adyacencias aproximadas (2)

Adyacencias aproximadas (3)

BARUTUNO2 BONITA2 BARUTDOS2 HYWTWO2 MANZANAR2 PLACER1 SWITCH1 TRINIDOS2 TAZON1 TRINIUNO2 USBDOS1 USBUNO2

Tabla 18. Adyacencias para el sector USBUNO1. (1) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 15º, apertura de antena adicional para la nueva BTS = 0º, apertura de antena adicional para el resto de las BTS = 0º. (2) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 30º, apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º. (3) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 60º, Apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º.

Adyacencias reales

Adyacencias aproximadas (1)

COLBEDOS1 COLMONIC1 COLBETRE2 CONCRESA3 CUMBEDOS1 FEUNO2 CUMBEDOS2 MINDEF1 CUMBETRE1 CUMBEUNO1 MONICUNO3 CUMBEUNO2 VALLETRE1 PESTEDOS1 PESTEDOS2 PESTEUNO2 TZHIPUNO3

Adyacencias aproximadas (2)

Adyacencias aproximadas (3)

CAMPITOS3

CONCRESA2

Adyacencias aproximadas (3)

FEUNO3 MONICDOS2 SERVPANA1

Tabla 19. Adyacencias para el sector CUMBETRE2. (1) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 15º, apertura de antena adicional para la nueva BTS = 0º, apertura de antena adicional para el resto de las BTS = 0º. (2) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 30º, apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º. (3) Cálculos realizados con: Número de adyacencias = 20, Error de ángulo = 60º, Apertura de antena adicional para la nueva BTS = 30º, apertura de antena adicional para el resto de las BTS = 0º.

152

Todos los resultados de las tablas mostradas anteriormente, permiten comprobar que el objetivo planteado al desarrollar la herramienta para el cálculo automático de las adyacencias de una estación base. Este objetivo fue lograr más de un 50% de coincidencia con las adyacencias existentes y seleccionadas por el personal de la Coordinación de Optimización, luego de realizar pruebas de campo. Es muy importante resaltar el hecho de que el programa desarrollado posee una gran cantidad de variables que pueden afectar el resultado, por lo tanto, es imprescindible la experiencia del personal de la Coordinación de Optimización, para el uso e interpretación de las variables y resultados de la herramienta. Los resultados que muestran las tablas presentadas anteriormente, fueron obtenidos con los valores que lograron generar la mayor cantidad de adyacencias que coinciden con las adyacencias “reales”. Para tener una idea de la importancia que tienen los conocimientos y la experiencia del usuario (al momento de modificar los parámetros y analizar los resultados que entrega la herramienta), para lograr un correcto cálculo de adyacencias, se presenta el siguiente ejemplo realizado. Al calcular las adyacencias del sector “ADJUNDOS1”, la herramienta indicó que su radio de cobertura teórico era de aproximadamente 2,725 km. Los parámetros utilizados para calcular este radio de cobertura, fueron los mismos que se usaron para calcular las “adyacencias aproximadas (2)” de las tablas 15-19. Usando éstos parámetros, la herramienta sólo logró calcular 2 adyacencias, “ADJUNDOS2” y “RPINEUNO3” que coincidieron con las “adyacencias reales”. Se observó que “RPINEUNO3” se encuentra a 5,447 km de distancia aproximadamente de “ADJUNDOS1”. Se procedió a calcular 20 adyacencias geográficas de “ADJUNDOS1”, y se observó que la BTS más cercana a “ADJUNDOS” se encontraba a 3,448 km aproximadamente. Luego de analizar brevemente esta información, se decidió ampliar el radio de cobertura de “ADJUNDOS1” para aumentar las probabilidades de solapamiento y por lo tanto la posibilidad de tener más adyacencias. Para aumentar el radio de cobertura se decidió reducir la potencia de recepción a -110 dB (por defecto el programa asigna el valor -95 dBm a esta variable), pero se pudo haber escogido cambiar el tipo de área y/o ciudad que se usa en el modelo de propagación para realizar los cálculos. Luego de realizar las modificaciones y calcular las adyacencias nuevamente, se logró obtener 18 adyacencias, de las cuales 9 pertenecían a las “adyacencias reales”.

153

Para finalizar este capítulo, se presentan a continuación dos tablas en donde se realiza una comparación adicional entre Microsoft Access, MySQL y PostgreSQL. La tabla 20, compara las características y limitaciones de los DBMS [29] [30] [31] [32]. La segunda tabla, tabla 21, muestra una comparación subjetiva en donde se comparan los costos de implementación de los distintos DBMS.

Microsoft Access Tamaño máximo de base de datos Número máximo de usuarios concurrentes Número máximo de columnas en una tabla Tamaño máximo de una tabla Tamaño máximo de una fila Tamaño máximo de un campo Número máximo de índeces en una tabla Número máximo de filas en una tabla

2 Gigabytes

MySQL

PostgreSQL

ILIMITADO (existen bases de 65536 Terabytes datos de 32 Terabytes)

255

ILIMITADO

ILIMITADO

255

-

250-1600

2 Gigabytes

65536 Terabytes

32 Terabytes

1 Gigabyte

-

400 Gigabytes

1 Gigabyte

1 Gigabyte

1 Gigabyte

32

64

ILIMITADO

-

existen tablas con 5.000.000.000 filas

ILIMITADO

Tabla 20. Características de Microsoft Access, MySQL y PostgreSQL

154

Microsoft SQL MySQL 5.0 PostgreSQL 8.1 Server 2005 & & & SUSE Linux SUSE Linux Microsoft 10.1 10.1 Windows Server 2003 $999 con 5 CALs. $199 por Gratis Gratis $169,99 cada 5 CALs adicionales $739 con 5 $229 para usuarios nuevo; CALs. $146 por Gratis Gratis cada CAL $109 para adicional actualización Microsoft Access 2003 & Microsoft Windows XP

Costo del sistema operativo Costo del DBMS Costo de entrenamient o básico de 1 persona

$1.000

$1.000

$1.000

$1.000

Tabla 21. Costos de implementación de los tres DBMS estudiados.

Se recomienda al lector visitar las páginas web que se presentan a continuación para obtener información más detallada acerca de los precios y licencias de los programas mencionados en la tabla 21. El costo de entrenamiento básico mostrado en la tabla, corresponde al costo mínimo estimado que se debe invertir en una persona, para que ésta adquiera conocimientos básicos acerca de la administración de los sistemas operativos y de los sistemas manejadores de bases de datos. Este costo es una estimación, y corresponde a un salario de $500 mensuales en un período de dos meses. La tabla 21 muestra los precios más bajos de los productos ofrecidos, que en general son los que ofrecen menor cantidad de características. Se escogieron los productos, tomando en cuenta la disponibilidad de ellos para equipos con procesadores de 64-bit compatibles con las tecnologías AMD64 / EM64T, ya que el servidor HP Blade, que aquirirá Digitel GSM, tendrá este tipo de procesadores.

155

En la tabla 21 se hace referencia a las siglas CAL. El significado de estas siglas es licencia de acceso al cliente (Client Access License), y limita la cantidad de usuarios o clientes a los cuales se les permite la conexión y el acceso al servidor. Dependiendo de las necesidades en el número de CALs, algunos de los precios de la tabla 21 se pueden elevar a más de $10.000 (como es el caso de Microsoft SQL Server 2005 con 25 CALs que tiene un costo venta de $13.969). Se puede ver directamente de la tabla, que los costos aproximados de implementar la migración a un sistema operativo Linux y a un DBMS de licencia libre, se pueden reducir en más de $1000 y si se decide utilizar el mismo OS y el mismo DBMS (en el servidor HP Blade) para todas las coordinaciones del Departamento de Operaciones de Digitel GSM, en donde hay mas de 20 usuarios o clientes, se pueden evitar costos de más de $10.000. A continuación se muestran las páginas web que se recomiendan al lector para conseguir más información acerca de las licencias y precios de los productos mostrados en la tabla 21: http://www.microsoft.com/windowsxp/default.mspx http://www.microsoft.com/windowsserver2003/default.mspx http://www.microsoft.com/windowsserver2003/howtobuy/licensing/pricing.mspx http://www.microsoft.com/sql/default.mspx http://www.microsoft.com/sql/howtobuy/default.mspx http://www.novell.com/products/suselinux/ http://www.novell.com/products/suselinux/eula.html http://www.mysql.org/ http://www.mysql.com/company/legal/licensing/ http://www.postgresql.org/ http://www.postgresql.org/about/licence

9. CONCLUSIONES Y RECOMENDACIONES

Se logró la optimización de las herramientas Daily Optimizer y Parameter de la Coordinación de Optimización del Departamento de Operaciones de Digitel GSM. Se estudiaron y compararon tres sistemas operativos Linux: SUSE, Debian, Red Hat. Se seleccionó SUSE Linux como sistema operativo para ser instalado en la sección del servidor HP Blade asignada a la Coordinación de Optimización. Se realizó un estudio comparativo entre el sistema administrador de bases de datos actualmente usado por la Coordinación de Optimización (Microsoft Access), y otros dos sistemas administradores de licencia libre, MySQL y PostgreSQL. Se desarrolló un programa en Visual Basic que funcionó como herramienta en el estudio comparativo de los tres sistemas administradores de bases de datos. La interfaz gráfica de esta herramienta, mostró los tiempos de ejecución y procesamiento de las consultas realizadas a los tres DBMS. La herramienta permitió realizar consultas a estos tres DBMS, a través de la misma interfaz gráfica lo que facilitó y agilizó la realización del estudio. Se realizó un análisis de la estructura de las bases de datos y se realizaron modificaciones a éstas. Se realizaron pruebas con la herramienta desarrollada para comparar los tiempos de procesamiento y consulta entre Microsoft Access, MySQL y PostgreSQL. Al usar un sistema operativo Windows, los menores tiempos de procesamiento y consulta se obtuvieron con el DBMS MySQL. Con un sistema operativo Linux, los tiempos de consulta y procesamiento más cortos se obtuvieron con el DBMS PostgreSQL. Se seleccionó PostgreSQL, como nuevo administrador de bases de datos para la Coordinación de Optimización, basado en los resultados del estudio comparativo y en las necesidades de la Coordinación de Optimización de utilizar un sistema operativo Linux. Se realizó la migración de las bases de datos usadas por las herramientas Daily Optimizer y Parameter, al DBMS PostgreSQL. Se modificaron estas herramientas para que hicieran uso de las bases de datos almacenadas en el nuevo DBMS, PostgreSQL. Se modificaron y crearon nuevas herramientas capaces de actualizar automáticamente las bases de datos de PostgreSQL.

157

Se modificó la estructura de las bases de datos con lo cual se incrementó la velocidad de búsqueda de datos. Se realizaron pruebas sobre las herramientas Daily Optimizer y Parameter ya modificadas para comprobar una mejora en el tiempo de procesamiento y consulta de datos. Se logró la optimización deseada de las herramientas, al obtener una reducción en el tiempo de consulta y procesamiento de más del 80%. Se desarrolló una completa documentación técnica en donde se especifican los procedimientos necesarios para realizar la migración de las bases de datos y la instalación del sistema operativo SUSE Linux en el servidor HP Blade. Se desarrolló una herramienta que automatizó el procedimiento inicial para la selección de las adyacencias de una BTS o de una nueva BTS. Se desarrolló la interfaz gráfica de la herramienta para permitir al personal de la Coordinación de Optimización escoger la combinación NCC-BCC de una nueva BTS, sin la necesidad de buscar esta información en las tablas de las bases de datos, es decir, se automatizó el proceso de selección de los parámetros NCC y BCC. Se desarrolló una interfaz gráfica de la herramienta que permite al personal de la Coordinación de Optimización, administrar las bases de datos en donde se almacena la información acerca de las BTS Nokia de la red celular de Digitel GSM. La herramienta desarrollada para el cálculo automático de las adyacencias, genera los reportes “Datafill” necesarios al crear una nueva BTS. Como recomendación general, se plantea que la selección del sistema operativo y del sistema administrador de bases de datos que se van a instalar en el servidor HP Blade, sea una decisión tomada en conjunto entre las diferentes coordinaciones del Departamento de Operaciones de Digitel GSM. Esto se plantea para evitar la necesidad de tener que invertir costos en entrenar a varias personas para que cumplan las funciones de administrador del servidor HP Blade. Tener un solo sistema operativo y un solo administrador de bases de datos hace que el intercambio de datos entre las diferentes coordinaciones se realice de la manera más eficiente posible, ya que toda la información estará bajo un formato y estructura única.

158

Para ayudar en este proceso de unificación, las herramientas desarrolladas en el proyecto, y las herramientas modificadas, se programaron para que fueran capaces de utilizar bases de datos almacenadas en PostgreSQL y MySQL. Cabe destacar la importancia que tiene el proyecto desarrollado en este libro, en el proceso de selección de un sistema administrador de bases de datos único para todas las coordinaciones del Departamento de Operaciones de Digitel GSM. El proyecto sirve como base para hacer la selección de un DBMS de licencia libre. Se realizó una comparación estimada de los algunos de los costos implicados en la migración y cambio de OS y DBMS, y se concluyó que Digitel GSM, puede evitar costos de más de $10.000, dependiendo del OS y el DBMS seleccionados.

159

REFERENCIAS BIBLIOGRÁFICAS [1] “Digitel GSM”. Portal de Digitel. . (2006) [2] “Nuestra Historia. Digitel GSM” . (2006) [3] “Nuestros Valores. Digitel GSM”. Portal de Digitel.

[4] “SYSTRA. GSM System Training”. Nokia Networks Oy, pp. 9-15, 38-44, 55-60, 69-74, 125-131, 135-139, 157-166. (2001). [5] Kahabka, Marc. “Pocket Guide for Fundamentals and GSM Testing”. Acterna Eningen GmbH, Vol. 2, pp. 8-10, 13-20, 37-43. [6] Eberspächer, Jörg, et al. “GSM Switching, Services and Protocols”. John Wiley & Sons Ltd. Segunda Edición. Inglaterra. pp. 29-47, 57-95. (2001). [7] Heine, Gunnar. “GSM Networks: Protocols, Terminology and Implementation”. Artech House, Inc., E.E.U.U., pp. 13-37, 89-107, 251-275. (1999). [8] Götz, Roland. “Supporting Network Planning Tools II”. Presentación en Power Point. LS Telcom AG. (2002). [9] Edfors, Ove. “Channel models and antennas”. Presentación en Power Point de la clase número 4 del curso ETI 051. Departamento de Electrociencia, Universidad de Lund, Suecia. (2006). [10] Loyka, Sergey. “Introduction to Mobile Communications”. Notas de la clase número 3 del curso ELG7178A. Escuela de la Tecnología de Información e Ingeniería, Universidad de Ottawa, Canadá. [11] Mullins, Craig. “Database Administration: The Complete Guide to Practices and Procedures”. Addison Wesley. E.E.U.U., pp. 5-7, 18-20, 236-340. (2002) [12] Ramakrishan, Raghu y Gehrke, Johannes. “Database Management Systems”. Segunda Edición. McGraw-Hill. E.E.U.U, pp. 3-15, 51-119, 153-161, 359-415, 456-497. (2002). [13] Silberschatz, Abraham, et al. “Database System Concepts”. Cuarta Edición. McGrawHill. pp. 1-27, 79-189, 393-565, 683-709.

160

[14] Rob, Peter and Coronel Carlos. “Database Systems: Design, Implementation and Management”. Quinta edición. Thomson Learning Course Technology. pp. 4-26, 33-55, 8692, 224-243. (2004). [15] Ullman, Jeffrey y Widom, Jennifer. “A First Course in Database Systems”. Prentice Hall, Inc. pp. 1-18, 85-90, 173-194, 243-262, 294-303. (1997). [16] “ODBC”. . [17] “ODBC Architecture”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network). [18] “ADO, DAO and RDO in Visual Basic”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

[19] “ADO Compared with RDO and DAO”. Ayuda de Visual Basic 6 o MSDN en

[20] “ActiveX Data Objects (ADO) Frequently Asked Questions”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

[21] “Pooling in the Microsoft Data Access Components”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

[22] “What Data Sources Can I Access with DAO and ODBC?”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

[23] “Data Access: ADO and RDO”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

161

[24] “Why Should I Use DAO or ODBC”. Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network). [25] “Data Access Technologies Road Map”.Red para Desarrolladores de Microsoft (MSDN; Microsoft Developer Network).

[26] “Principio de Pareto”. [27] “Office XP System Requirements”. Microsoft Office Online.

[28] “Access 2003 System Requirements”. Microsoft Office Online.

[29] Manual de referencia de MySQL 5.0. [30] Documentación de PostgreSQL 8.0. [31] “MTU”

[32] “Access specifications”

[33] “Frequently Asked Questions (FAQ) for PostgreSQL”