Redes GSM Celular

UNIVERSIDAD SIMN BOLVAR
Decanato de Estudios Profesionales

Coordinacin de Ingeniera Electrnica
OPTIMIZACIN DE LAS HERRAMIENTAS DE ANLISIS DE LA RED CELULAR

DE DIGITEL GSM
Por
Hansell E. Barn Altuve
Sartenejas, Noviembre 2006


DE DIGITEL GSM
Por
Realizado con la Asesora de:
Ing. Fidel Gil (Tutor Acadmico)
Ing. Juan Gallardo (Tutor Industrial)
Informe Final de Cursos en Cooperacin Tcnica y Desarrollo Social

Presentado ante la Ilustre Universidad Simn Bolvar
como requisito parcial para optar al ttulo de Ingeniero Electrnico


DE DIGITEL GSM
Informe Final de Cursos en Cooperacin Tcnica y Desarrollo Social presentado por
REALIZADO CON LA ASESORIA DE:

Ing. Fidel Gil (Tutor Acadmico)
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 anlisis usadas por la Coordinacin de Optimizacin de Digitel GSM.
Dicha optimizacin se realiz a travs de: la migracin de las bases de datos a un nuevo
sistema administrador (PostgreSQL) como resultado de un estudio comparativo entre
Microsoft Access, MySQL y PostgreSQL, la modificacin 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 ms del 90%.
La segunda parte del proyecto de grado consisti en desarrollar una herramienta capaz de
calcular las adyacencias de una estacin base. La herramienta, desarrollada en Visual Basic,
hace uso de modelos de propagacin, ecuaciones matemticas y fundamentos de geometra
para automatizar, sustituir y agilizar el procedimiento manual y engorroso utilizado por el
personal de la Coordinacin de Optimizacin. 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
Comparacin entre administradores de bases de datos, MySQL, PostgreSQL, Microsoft
Access, Clculo automtico de adyacencias de una estacin base.
Aprobado con mencin:_______
Postulado para el premio:_______
A mi pap, Estefan,
quien con sus enseanzas, ayuda y apoyo, hoy en da no sera 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 sueos.
A mi hermana, Heidell,
quien me ense que el xito y que todas nuestras metas las podemos alcanzar
con esfuerzo, dedicacin y perseverancia.
NDICE GENERAL
ndice General
i
ndice de Figuras
iv
ndice de Tablas
vi
Smbolos y abreviaturas
vii
1. INTRODUCCIN
1
2. DESCRIPCIN Y ANTECEDENTES DEL PROBLEMA
5
2.1 Descripcin de la Empresa 5
2.1.1 Misin de la Empresa 6
2.1.2 Visin 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 especficos 11
4. FUNDAMENTOS TERICOS 12
4.1 Introduccin 12
4.2 Principios bsicos de GSM 12
4.2.1 Evolucin de GSM
12
4.2.2 Arquitectura de una red celular GSM 14
4.2.2.1 Subsistema de estacin base
15
4.2.2.2 Subsistema de conmutacin de la red
16
4.2.2.3 Subsistema de administracin de la red
19
4.2.3 Interfaz de Aire 20
4.2.3.1 Canales fsicos y lgicos 21
4.2.3.2 Handover 25
4.2.4 Planificacin y optimizacin de una red GSM 25
4.2.4.1 Planificacin de los recursos de radiofrecuencia 27
4.2.4.2 Modelos de propagacin para la planificacin 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 Desempeo 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 Mtodos de acceso a orgenes de datos 52
METODOLOGA
54
5.1 Investigacin preliminar
54
5.2 Anlisis preliminar de las herramientas y bases de datos
54
5.3 Migracin inicial de las bases de datos
55
5.4 Desarrollo inicial del programa de pruebas 55
5.5 Ejecucin de las pruebas preliminares a los administradores
de bases de datos
56
5.6 Anlisis de las pruebas preliminares a los administradores
de bases de datos
56
5.7 Investigacin detallada acerca de los administradores de bases de datos,
sistemas operativos, conexiones de red, controladores o drivers y
lenguaje de programacin
56
5.8 Ejecucin de las pruebas finales a los administradores de bases de datos 57
5.9 Anlisis de las pruebas finales a los administradores de bases de datos
57
5.10 Modificaciones a las herramientas Daily Optimizer y Parameter de la
Coordinacin de Optimizacin
57
5.11 Pruebas finales a las herramientas Daily Optimizer y Parameter de la
Coordinacin de Optimizacin
58
5.12 Investigacin detallada acerca del procedimiento para el clculo de las
adyacencias de una BTS
58
5.13 Desarrollo de la herramienta para el clculo automtico de las adyacencias
de una BTS 58
5.14 Ejecucin de las pruebas a la herramienta para el clculo automtico de las
59
ESTUDIO COMPARATIVO ENTRE TRES ADMINISTRADORES DE
BASES DE DATOS
60
6.1 Condiciones previas 61
6.2 Migracin 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 parmetros de configuracin y pruebas finales
81
6.6.1 Cambios realizados a los parmetros de configuracin 81
6.6.2 Pruebas finales 87
HERRAMIENTA PARA AUTOMATIZAR EL CLCULO DE LAS
ADYACENCIAS DE UNA ESTACIN BASE 92
7.1 Procedimiento para el clculo de las adyacencias 92
7.2 Interfaz grfica de la herramienta
97
7.3 Pruebas realizadas
107
RESULTADOS Y ANLISIS 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 clculo de adyacencias 147
8.2.1 Resultados obtenidos 147
9. CONCLUSIONES Y RECOMENDACIONES 156
Referencias Bibliogrficas 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. Relacin 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 lgicos de la interfaz de aire de GSM
24
Figura 8. Diferentes configuraciones de BTS
28
Figura 9. Patrn de reuso en una red GSM con 9 frecuencias disponibles 29
Figura 10. Modelos de propagacin y su rango vlido de frecuencias
30
Figura 11. Representacin grfica del modelo de propagacin
emprico Okumura-Hata 31
Figura 12. Relacin o tabla de una base de datos relacional 36
Figura 13. Relacin 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 comunicacin con una
base de datos
49
Figura 16. Arquitectura de ODBC 51
Figura 17. Arquitectura MDAC
53
Figura 18. Interfaz grfica del programa de pruebas desarrollado con
Visual Basic 6 para la comparacin de los tres DBMS 68
Figura 19. Interfaz grfica de la herramienta desarrollada para el
clculo de adyacencias
98
Figura 20. Interfaz de la herramienta luego de calcular las adyacencias
para el sector 23ENERO1 104
Figura 21. Interfaz para la administracin 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
la prueba preliminar 1 con MySQL / Linux
112
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
con MySQL / Linux
115
con PostgreSQL / Linux 115
Figura 29. Grficas del uso de CPU, del computador cliente, al ejecutar
Figura 30. Grfica del uso de CPU, del computador servidor, al ejecutar
la prueba preliminar 2 con MySQL / Windows 119
Figura 31. Grfica 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
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
117
122
126
129
Tabla 7. Resultados de la prueba final 1
132
136
137
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. Caractersticas de Microsoft Access, MySQL y PostgreSQL
153
Tabla 21. Costos de implementacin de los tres DBMS estudiados 145
vii
GLOSARIO, SMBOLOS Y ABREVIATURAS

AuC: Authentication Center. Centro de autenticacin.
BCC: Base Transceiver Station Color Code. Cdigo de color de una estacin base que forma
parte del cdigo de identificacin de una estacin base.
BSC: Base Station Controller. Controlador de base estacin
BSIC: Base Transceiver Station Identity Code. Cdigo de identificacin de una estacin base.
BSS: Base Station Subsystem. Subsistema de base estacin.
BTS: Base Transceiver Station. Estacin 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 vehculo
por sectores de la ciudad donde la red celular tiene cobertura y monitorear parmetros como
potencia de recepcin, calidad de la voz, seales y niveles de interferencia, facilidad y
efectividad de HandOvers, etc.
GSM: Global System for Mobile Communications. Uno de los estndares de comunicacin
celular usado a nivel mundial.
HandOver: Proceso mediante el cual se transfiere la comunicacin o el enlace entre una
estacin base y una estacin mvil a otra estacin base con la misma estacin mvil mientras
sta hace uso de algn servicio de la red celular.
KPI: Key Performance Indicator. Indicador Clave de Desempeo.
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. Estacin Mvil.
MTU: Maximum Transfer Unit o Maximum Transmission Unit. Unidad mxima de
transferencia.
NCC: Network Color Code. Cdigo de color de la red
ODBC: Open DataBase Connectivity. Estndar que permite a cualquier aplicacin acceder a
la informacin 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. Mdulo de Identidad del Subscriptor.
1. INTRODUCCIN
En general, cualquier empresa o compaa que desee medir su desempeo o que desee
cuantificar el cumplimiento de sus metas planteadas, debe disponer de Indicadores Claves de
Desempeo (KPI; Key Performance Indicator). Estos indicadores deben ser capaces de medir
cuantitativamente las metas fijadas en la empresa.
Toda empresa que se encarga de disear, planificar, administrar y desarrollar una red
celular debe poseer indicadores capaces de medir cuantitativamente el desempeo 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 cadas o bloqueadas, cantidad o porcentaje de
HandOvers fallidos, calidad de la voz, etc., estn 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
desempeo de la red celular.
Para mejorar el desempeo 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 informacin obtenida de
los indicadores de desempeo.
El desempeo normal o desempeo 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 energa y se destruyeron equipos de transmisin, 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 desempeo 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 razn que el anlisis de los KPI se debe realizar cuando se dispone de un
acumulado histrico de los mismos, es decir, se dispone de informacin obtenida o de KPI
acumulados durante varios das, semanas, meses o aos. Disponer de una base de datos donde
se acumule esta informacin facilita la tarea de analizar el desempeo de una red celular. Para
lograr un anlisis eficaz, sin embargo, es necesario contar con herramientas que permitan al
especialista en optimizacin de la red, ver rpidamente cualquier informacin acerca de
cualquier estacin base (BTS; Base Transceiver Station) y durante cualquier perodo de
tiempo.
La Coordinacin de Optimizacin de la empresa Digitel de Venezuela ha desarrollado
herramientas de anlisis y monitoreo de la red celular. Estas herramientas hacen uso de bases
de datos que acumulan informacin 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 desempeo de la red celular.
Las bases de datos diseadas por el personal de la Coordinacin de Optimizacin
contienen informacin desde el ao 2005 y han estado creciendo constantemente. Hoy en da
algunas de las bases de datos contienen tablas con ms de 500.000 filas y 50 columnas de
informacin.
Como consecuencia de este crecimiento en el tamao de las bases de datos, se crea la
necesidad de procesar mayor cantidad de informacin 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 anlisis de la Coordinacin de
Optimizacin de Digitel. Reducir los tiempos de procesamiento es un objetivo fundamental
para la Coordinacin de Optimizacin ya que esto permite al personal tener una mayor
velocidad de respuesta y lograr una utilizacin ms eficiente del tiempo invertido en el
anlisis del desempeo de la red.
Por esto, es importante optimizar el desempeo tanto del DBMS como de las
herramientas de anlisis, para que la informacin sea procesada en el menor tiempo posible.
Sumado a la necesidad de optimizar las herramientas de anlisis, la Coordinacin de
Optimizacin tiene la necesidad de automatizar tareas manuales, en particular la de calcular
adyacencias de una estacin base, para que el personal pueda dedicar mayor parte del tiempo
al anlisis y resolucin de problemas de la red celular.
La tarea de generar, seleccionar y calcular las estaciones base que son adyacentes a un
punto geogrfico determinado, juega un papel importante en el proceso de planificacin y
optimizacin de la red. Al crear una nueva BTS, es necesario identificar cules son las
adyacencias de sta ya que es una informacin necesaria para operaciones fundamentales e
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 geogrfico. Esta seleccin manual consume mucho
tiempo ya que se deben considerar canales de transmisin, orientacin de las antenas, reuso de
frecuencia, etc. La segunda etapa en la seleccin de las BTS adyacentes es la de realizar una
prueba de campo o drive test, en donde se seleccionan las BTS adyacentes definitivas,
basndose en los niveles de potencia recibidos provenientes de las seales de otras BTSs.
El objetivo de desarrollar una herramienta capaz de automatizar el proceso de
seleccin de adyacencias es acelerar y mejorar la primera etapa del mismo. Para el desarrollo
de esta herramienta, fue necesario el uso de modelos de propagacin para redes celulares y
ecuaciones matemticas 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 geogrfico determinado basndose en la distancia
geogrfica, canal de transmisin 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 seleccin de las adyacencias de una BTS.
En este proyecto de grado se logr realizar la optimizacin a las herramientas de
anlisis, ya que se logr reducir en ms del 50% el tiempo de respuesta y procesamiento de las
bases de datos usadas por las herramientas de anlisis de la Coordinacin de Optimizacin.
A lo largo de este libro se exponen los procedimientos que se siguieron para lograr la
optimizacin de las herramientas y tareas de la Coordinacin de Optimizacin. En el captulo
2 se presenta la descripcin de la empresa y el planteamiento del problema. Los objetivos del
proyecto de grado se exponen en el captulo 3. Toda la informacin y fundamentos tericos
necesarios para comprender el desarrollo y ejecucin del proyecto se encuentran en el captulo
4. En el captulo 5 se expone la metodologa que se utiliz a lo largo del desarrollo del
proyecto para lograr los objetivos planteados. En el captulo 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 captulo 7 muestra todo lo relacionado al desarrollo de la herramienta
utilizada para calcular automticamente las adyacencias de una BTS. Todos los resultados
obtenidos, tanto del estudio comparativo como del desarrollo de la herramienta de clculo de
adyacencias, se presentan en el captulo 8 acompaados con su anlisis y discusin. Por
ltimo, en el captulo 9, se presentan las conclusiones y recomendaciones a las que se llegaron
luego de analizar los resultados del proyecto.
2. DESCRIPCIN Y ANTECEDENTES DEL PROBLEMA

2.1
Descripcin de la Empresa
Digitel GSM es la nica empresa de telecomunicaciones en Venezuela que ofrece
servicios de telefona inalmbrica bsica, pblica y mvil basados en la tecnologa GSM. La

tecnologa GSM est basada en el uso de una tarjeta SIM (Subscriber Identity Module) que
permite almacenar todos los datos del usuario como nmero telefnico, directorio telefnico,
claves de seguridad y acceso, mensajes de texto, etc. La tarjeta SIM tambin 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 regin central de Venezuela (los
estados Distrito Federal, Miranda, Carabobo, Aragua, Falcn, Yaracuy, Cojedes, Gurico 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 regin central de Venezuela. [1]
La empresa Digitel se inici en Julio de 1997 cuando CONATEL (Comisin Nacional
de Telecomunicaciones), ente regulador del sector de las telecomunicaciones en Venezuela,
entreg a la compaa
una multiconcesin para prestar servicios bsicos de
telecomunicaciones y telefona pblica. Seis meses despus, en Enero de 1998, se firm el

contrato. Ese mismo ao, Digitel firm un contrato de suministro para la construccin de la
red en Caracas y su zona metropolitana con la empresa Nokia. En enero del ao 1999 un
acuerdo similar se concret con la compaa Siemens para la expansin 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 compaa TIM (Telecom Italia
Mobile) que fue accionista nico hasta mediados de este ao momento en el cual Oswaldo
Cisneros Fajardo se convierte en accionista nico de Digitel GSM.
2.1.1
Misin de la Empresa
Ofrecer servicios de telecomunicaciones que excedan las expectativas de nuestros
clientes y accionistas, distinguindonos por una vocacin de servicio, innovacin, calidad y

compromiso social.[3]
2.1.2
Visin de la Empresa
Ser la empresa modelo de telecomunicaciones venezolana en trminos de calidad,
innovacin y rentabilidad, manteniendo una relacin clida y humana entre nosotros y con
nuestros clientes.[3]
2.1.3
Valores de la Empresa
Orientacin al Cliente, Integracin, Proactividad, Velocidad, Transparencia,
Innovacin, Excelencia Profesional y Espritu Emprendedor. [3]

Orientacin al cliente: El cliente es lo principal y su satisfaccin un valor
fundamental. Escuchamos a nuestros clientes para anticipar y responder sus
necesidades.
Integracin: Cooperamos y actuamos en conjunto para minimizar los conflictos y
maximizar el intercambio de informacin promoviendo y aprovechando la
contribucin de todos para el logro de un resultado comn.
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
optimizacin impacta los costos y el servicio que ofrecemos a nuestros clientes.
Transparencia: Actuamos de manera transparente y tica, para fortalecer las

relaciones con nuestras audiencias. Nuestras relaciones estn basadas en la lealtad y el
intercambio de informacin.
Innovacin: Desarrollamos soluciones innovadoras, promovemos nuevos caminos
para mejorar procesos y sistemas.
Excelencia Profesional: Desarrollamos las competencias requeridas transmitiendo
seguridad y credibilidad.
Espritu Emprendedor: Somos responsables directos del alcance de resultados
concretos. Asumimos los desafos 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 (Gestin Organizacional y Humana), Operaciones, etc.). De igual manera, cada

departamento est divido en gerencias que a su vez estn divididas en coordinaciones. Cada
departamento posee un vicepresidente como lder del mismo, cada gerencia tiene un gerente
de rea y cada coordinacin tiene un coordinador como lderes respectivos de sus secciones.
El nmero de especialistas que trabaja para cada coordinacin depende de las necesidades de
cada coordinacin.
En la figura 1 se puede ver el organigrama del Departamento de Operaciones en el cual
se aprecia la divisin en gerencias y coordinaciones.
El proyecto de grado que se desarrolla en este libro se hace bajo la Coordinacin de
Optimizacin que forma parte de la Gerencia de Operaciones y Mantenimiento. La
Coordinacin de Optimizacin es la encargada de monitorear, analizar y mejorar el
desempeo de la red celular operativa de Digitel GSM.
Figura 1. Organigrama del Departamento de Operaciones de Digitel GSM.
2.2
Planteamiento del Problema.

El crecimiento y expansin de una red de telefona celular crea, a su operadora, la
necesidad de tener que almacenar, manipular y procesar cada vez mayor cantidad de
informacin, por ejemplo, acerca del desempeo de la red celular.
Para que una empresa que ofrece servicios de telefona celular pueda posicionarse
como empresa lder entre sus competidores, adems de cumplir con estndares de calidad,
debe diferenciarse entre sus competidores y debe ofrecer a sus usuarios el ms variado y
mejor servicio posible.
Tratar de establecer cul es el mejor servicio posible que una empresa de
telecomunicaciones puede ofrecer puede ser una tarea imposible sin embargo, existen
parmetros 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 parmetros que comnmente se
usan para determinar cul es el mejor servicio de telefona celular se pueden nombrar los
siguientes: Precio de los servicios ofrecidos, rea de cobertura de la red celular, tipo y
variedad de los servicios ofrecidos, cantidad de llamadas bloqueadas y llamadas cadas,

calidad de la voz, velocidad de transmisin de datos, cantidad de errores en la transmisin,
niveles de interferencia en las seales, etc.
La Coordinacin de Optimizacin de Digitel GSM ha usado algunos de los indicadores
o KPIs anteriormente mencionados para mejorar el desempeo de la red celular. Es de hacer
notar que debido a que la Coordinacin de Optimizacin pertenece al Departamento de
Operaciones, los KPI usados estn 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 Coordinacin de Optimizacin ha diseado y desarrollado
herramientas y bases de datos para almacenar y analizar la informacin proveniente de la red
celular. Informacin acerca de la configuracin, trfico y desempeo 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 expansin de la corporacin Digitel GSM, las bases de datos
usadas por la Coordinacin de Optimizacin tambin sufrieron un crecimiento. Este
crecimiento trajo como consecuencia la necesidad de tener que procesar y analizar mayor
cantidad de informacin en el menor tiempo posible.
El problema que enfrenta actualmente la Coordinacin de Optimizacin es que las
herramientas de anlisis y las bases de datos desarrolladas no fueron diseadas para manipular
y procesar grandes cantidades de informacin.
Es por esta razn 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
Coordinacin de Optimizacin.
2.3 Alcance y limitaciones del proyecto

El proyecto se divide en dos partes fundamentales. La primera de ellas comprende la
realizacin de una evaluacin comparativa entre el DBMS usado actualmente por la
Coordinacin de Optimizacin 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 informacin. Luego, se deber realizar
la migracin, 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
debern realizar las modificaciones necesarias a las herramientas Daily Optimizer y
Parameter para que sean capaces de procesar con mayor rapidez la informacin de las bases
de datos.
La segunda parte del proyecto corresponde al desarrollo de una herramienta capaz de
calcular automticamente las adyacencias de una BTS. Esta herramienta debe servir como una
primera aproximacin en el proceso de seleccin de las adyacencias de una BTS. Adems,
esta herramienta debe servir como interfaz grfica para poder administrar la base de datos que
almacena la configuracin de las BTS Nokia de la red celular de Digitel GSM, es decir, a
travs de la herramienta, se debe poder modificar informacin 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 eleccin
del usuario, de generar un reporte en el que se encuentre la informacin de la nueva BTS y sus
adyacencias. Este reporte es denominado Datafill por la Coordinacin de Optimizacin.
No queda dentro del alcance del proyecto, explicar los mtodos y procedimientos que
se deben seguir para mejorar el desempeo de un sistema administrador de bases de datos. En
el captulo 4 se presentan los fundamentos tericos que ayudan a entender los factores que
afectan el desempeo de un DBMS. Tambin se recomienda al lector, consultar las referencias
bibliogrficas en donde podr encontrar mucha ms informacin relacionada a la optimizacin
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 automatizacin de tareas manuales.

3.2
Objetivos especficos
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
Coordinacin de Optimizacin (Microsoft Access).
Basado en la comparacin anterior, seleccionar el administrador de bases de datos ms
adecuado para la Coordinacin de Optimizacin.
De ser necesario, migrar y modificar todas las bases de datos usadas por dos de las
herramientas de la Coordinacin de Optimizacin (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 Coordinacin de
Optimizacin Daily Optimizer para disminuir los tiempos de consulta y
procesamiento de datos.
Realizar las modificaciones a la herramienta de la Coordinacin de Optimizacin
Parameter para disminuir los tiempos de consulta y procesamiento de datos.
Desarrollar una herramienta capaz de automatizar el clculo de las adyacencias de una
estacin base.
4. FUNDAMENTOS TERICOS
4.1 Introduccin
A lo largo de este captulo se presentar informacin fundamental para entender el
proyecto desarrollado en este libro. Conocimientos de telecomunicaciones, de bases de datos y
programacin, son fundamentales para el claro entendimiento del proyecto.
Este
captulo
empieza
por
presentar
fundamentos
tericos
generales
de
telecomunicaciones, luego se hace un recorrido acerca de la tecnologa y arquitectura del

estndar de comunicaciones mviles GSM, y por ltimo se dan a conocer los fundamentos
tericos de los sistemas administradores de bases de datos, haciendo mencin de los tres que
se estudian en este libro.
4.2 Principios Bsicos de GSM

4.2.1
Evolucin de GSM
En los inicios de la dcada de 1980, CEPT (Confrence Europenne des Postes et
Telecommunications) fund un grupo encargado de disear un sistema de telecomunicaciones

comn a Europa occidental. El grupo se llam Groupe Spciale Mobile y creci el nombre
de sistema GSM. Las siglas GSM se han interpretado de muchas maneras, pero la ms comn
es la de "Global System for Mobile communications". [4]
Durante el diseo del sistema se consideraron tres factores fundamentales: [4]
En cada pas deben existir varios operadores de redes de comunicacin, lo que
garantiza la competencia en cuanto a tarifas y servicios ofrecidos. Se supuso que sta
era la mejor manera para asegurar la rpida expansin de GSM.
El sistema GSM deba ser un sistema abierto cuyas interfaces entre cada una de las
partes del sistema deban estar bien definidas, de manera tal que varios equipos de
13
diferentes fabricantes pudieran coexistir y por lo tanto mejorar la relacin costoeficiencia del sistema desde el punto de vista del operador.
Las redes GSM debern ser construidas sin que hayan cambios grandes en las redes
telefnicas conmutadas pblicas (PSTN; Public Switching Telephone Networks)
existentes.
El sistema deber mantener una buena calidad de voz.
El sistema deber hacer uso del espectro radio elctrico de la manera ms 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 comunicacin 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 ms interferencias.
La calidad de voz es mejor que la de sistemas celulares analgicos.
Se garantiza la seguridad del suscriptor a travs de la encriptacin de la voz.
Se ofrece una mayor cantidad de servicios debido a la compatibilidad con ISDN.
Roaming internacional es posible entre los pases que usen GSM.
A continuacin se presenta una breve cronologa en la evolucin de GSM: [4]
1982
CEPT inici un nuevo sistema celular a travs del grupo GSM. La comisin europea
(EC) indic que los pases miembros deban reservar la banda de los 900 MHz para
GSM.
14
1987
Se asignaron las frecuencias 890 915 MHz para comunicacin desde la estacin
mvil a la base estacin (uplink), y 935 960 MHz para la comunicacin desde la
estacin base a la estacin mvil (downlink).
1991
El primero de Julio, se realiz la primera llamada en el mundo a travs 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,
existan 13 redes en 7 reas geogrficas distintas, y operadores en Australia fueron los
primeros aliados no-europeos de GSM.
1993
En Diciembre ya haban 32 redes GSM operando en 18 reas geogrficas distintas.
1995
Haba 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. Ms 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 ao, ms 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
estacin base y la estacin mvil, llamada interfaz de aire (Air Interface). La segunda es entre
la central de conmutacin de servicios mviles (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 haban completado cuando se lanzaron los sistemas comerciales. [4]
La inteligencia de la red GSM, a diferencia de las redes analgicas que posean una
inteligencia centralizada, se distribuye en tres subsistemas: Subsistema de estacin base,
subsistema de conmutacin de la red, subsistema de administracin de la red y el subsistema
de operacin y mantenimiento.
15
Otro componente fundamental en cualquier red celular es la estacin mvil (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 mvil (TE; Terminal
Equipment) y un mdulo de identificacin de suscriptor (SIM; Subscriber Identity Module).
Cada SIM posee un nmero de identificacin internacional de suscriptor mvil (IMSI;
International Mobile Subscriber Identity) y una identificacin internacional de equipo mvil
(IMEI; International Mobile Equipment Identity). [5] [4] [6]
La figura 2 muestra la arquitectura bsica de una red GSM. [6]
Figura 2. Arquitectura de una red GSM
4.2.2.1 Subsistema de estacin base

El Subsistema de estacin 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 estacin base, la estacin base de transmisin-recepcin

y el transformador de codificacin. [4] [5] [6] [7]
La estacin de transmisin-recepcin (BTS; Base Station Transceiver): Formada por
transmisores, receptores, antenas, etc., se encarga de conectar las estaciones mviles a
la red GSM. Debe proveer la encriptacin y codificacin de los datos y asegurarse de
mantener una comunicacin libre de errores entre las MS.
El controlador de estacin base (BSC; Base Station Controller): Constituye el
elemento central del BSS y se encarga de controlar la manera en que varias BTSs
(generalmente un nmero 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 codificacin (TC; Transcoder): Se encarga de hacer los ajustes
necesarios a los datos, para que pueda existir una comunicacin entre la BSC y el NSS.
4.2.2.2 Subsistema de conmutacin de la red

El Subsistema de conmutacin 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 conmutacin de servicios mviles, registro de ubicacin usuarios
casa (HLR; Home Location Register), registro de ubicacin de usuarios visitantes (VLR;
Visitor Location Register), centro de autentificacin (AuC; Authentication Center) y el
registro de identidad de equipos (EIR; Equipment Identity Register). [4] [5] [6] [7]
La central de conmutacin de servicios mviles (MSC; Mobile Switching Center): Se
encarga de realizar las funciones de registro y autenticacin de usuarios, enrutamiento
de llamadas, sealizacin, etc. Bsicamente cumple las mismas funciones que una
central de una red digital fija ISDN (Integrated Services Digital Network) o la ms
17
conocida red telefnica fija PSTN (Public Switched Telephone Network). Cuando la
funcin de una MSC es servir como puente entre una red fija y una red mvil (PLMN;
Public Land Mobile Network), generalmente se conoce como GMSC (Gateway MSC).
(figura 2)
El registro de ubicacin de usuarios casa (HLR; Home Location Register): Puede ser
considerado como una base de datos en donde se almacena, de forma permanente, la
informacin 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 informacin que
permiten manejar la seguridad de la informacin de un usuario. Cada PLMN o red
mvil, 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 ubicacin de usuarios visitantes (VLR; Visitor Location Register): Es
una base de datos en donde se almacena informacin dinmica de los usuarios o
suscriptores. Cuando un suscriptor se mueve de una cierta ubicacin a otra, la
informacin 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 informacin
adicional. La diferencia fundamental entre el VLR y el HLR es que el VLR se asigna
una zona geogrfica especfica y el HLR es independiente de la ubicacin geogrfica
del suscriptor. An cuando el usuario se encuentra en su red de origen, el VLR que
abarca su ubicacin geogrfica es quien maneja los datos dinmicos 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 relacin entre MSC y VLR.
[6] [7]
18
Figura 3. Diferencias entre HLR y VLR
Figura 4. Relacin entre MSC y VLR
19
El registro de identificacin de equipos (EIR; Equipment Identity Register): Sirve para

controlar el uso de equipos en la red. Debido a la separacin en la identificacin del
suscriptor (a travs del IMSI) y la identificacin del equipo (a travs del IMEI), es
posible la creacin de un mercado negro de equipos robados ya que es posible operar
cualquier equipo GSM con cualquier SIM GSM vlido. 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 sern permitidos en la red. El EIR
mantiene esta informacin 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 tcnicas y la lista gris (Gray list) que contiene los
equipos a los cuales se les debe hacer seguimiento.
El centro de autenticacin (AuC; Authentication Center): Generalmente integrado en
el HLR, guarda las claves de autenticacin de usuarios y las claves para la encriptacin
de la voz.
4.2.2.3 Subsistema de administracin de la red

El subsistema de administracin de la red (NMS; Network Management Subsystem)
tambin conocido como subsistema de operacin y mantenimiento (OMSS; Operation and
Maintenance SubSystem), se encarga de realizar, a travs del centro de operacin y
mantenimiento (OMC; Operation and Maintenance Center), funciones de monitoreo, control y
administracin de la red. Entre sus funciones se pueden mencionar: [7]
La administracin y control de los suscriptores, de la cobranza, de la recoleccin de
estadsticas, etc.
Manejo y administracin de la seguridad en la red.
20
Manejo de la configuracin, operacin y desempeo de todos los componentes de la

red.
Realizar tareas de mantenimiento.
4.2.3
Interfaz de Aire
La unin internacional de telecomunicaciones (ITU; International Telecommunication
Union) es el ente internacional encargado, entre otras cosas, de asignar el uso del espectro
radioelctrico. 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
GSM1900:
Uplink: 1850-1910 MHz
Para hacer uso de los recursos limitados del espectro radioelctrico, GSM usa una
combinacin entre el acceso mltiple por divisin de tiempo (TDMA; Time Division Multiple
Access) y el acceso mltiple por divisin 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 duracin
aproximada de 577 microsegundos. Cada ranura de tiempo puede ser ocupada por una rfaga
(Burst) de 156,25 bits, cada uno con una duracin 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 duracin es de 4,616 milisegundos. La figura 5 muestra la configuracin
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 fsicos y lgicos

Para poder transmitir los datos por la interfaz de aire, GSM utiliza cada ranura de
tiempo para transmitir diferente informacin a distintas MS. Para poder identificar el tipo de
informacin en una ranura de tiempo determinada, se usan los conceptos de canales fsicos y
lgicos.
Los canales fsicos 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 fsico.
Los canales lgicos se usan para identificar el tipo de informacin que se encuentra en
un canal fsico. En GSM los canales lgicos se pueden dividir en canales de trfico y canales
de sealizacin.
22
Los canales de trfico (TCH; Traffic Channels) son usados para la transmisin de voz
o de datos. Existen dos tipos de canales de trfico 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
transmisin es la mxima, 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 transmisin 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 sealizacin se pueden dividir ms an en canales de difusin

(Broadcast), canales dedicados y canales comunes.
Los canales broadcast o canales para la comunicacin punto-multipunto, son usados
solamente en el enlace de bajada (direccin downlink; desde la BTS a la MS) y son
responsables principalmente de la sincronizacin y correccin de frecuencia. Los siguientes
canales estn en esta categora: [4] [5]
Broadcast Control Channel (BCCH): Usado por las BTS para enviar informacin
general especfica a todas las MS al alcance, por ejemplo, cdigo de rea local (LAC;
Local Area Code), parmetros 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
correccin de las frecuencias de una MS.
Synchronization Channel (SCH): Usado por la BTS para sincronizar las tramas TDMA
en una MS. Con la recepcin vlida de un burst completo de SCH, una MS obtendr
toda la informacin necesaria para sincronizarse con una BTS.
Los canales comunes son utilizados para llevar informacin de la red a la MS y para
permitir el acceso a la red. Los siguiente canales entran en esta categora: [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 peticin para que
se le asigne un canal SDCCH luego de recibir, por ejemplo, un llamado de atencin
(paging). La MS escoge un tiempo aleatorio en el cual enva informacin por este
canal. Esto puede ocasionar colisiones entre MS.
24
Por ltimo estn los canales lgicos dedicados. stos son usados para realizar
operaciones tales como encriptacin, roaming, handovers, etc. En esta categora estn los
siguiente canales: [4] [5]
Stand-alone Dedicated Control Channel (SDCCH): Usado principalmente para la
sealizacin entre MS y BTS antes de que sea asignado un canal TCH.
Slow Associated Control Channel (SACCH): Usado para transmitir continuamente
mediciones de alineacin 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
sealizacin 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 lgicos usados en GSM. [7]
Figura 7. Canales lgicos 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 conexin activa entre una BTS y una MS.
Esto puede ocurrir, por ejemplo, cuando una MS que tiene una conexin activa con una BTS,
sale del rea de cobertura de esa BTS. Como es necesario que la comunicacin permanezca
activa, la conexin de la MS debe ser entregada a otra BTS para que sta contine. En GSM
se han definido al menos cuatro tipos de handover. [4] [5] [7]
Handover intra-BTS: Ocurre cuando se transfiere la conexin entre dos canales
distintos dentro de una misma BTS.
Handover inter-BTS: Ocurre cuando la conexin se transfiere entre dos BTS
distintas que son controladas por la misma BSC.
Handover inter-BSC: Ocurre cuando se transfiere la conexin entre dos BTS
distintas, controladas por diferentes BSC, pero bajo un mismo MSC.
Handover inter-MSC: Ocurre cuando la conexin 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 trfico,
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 seales recibidas. Esta informacin se pasa al BSC y al MSC, al
menos una vez por segundo, y es usada en el algoritmo para decidir el handover. La decisin
para realizar el handover, generalmente se basa en la calidad y los niveles de recepcin. En
GSM, un handover puede llevarse a cabo a velocidades de hasta 250 km/h. [5]
4.2.4
Planificacin y optimizacin de una red GSM.

Planificar una red celular es un proceso complejo y continuo que involucra el anlisis
y estudio de muchas variables como los costos de construccin de la red, capacidad de la red,
26
cobertura y ubicacin de los elementos de la red, calidad de las llamadas, desarrollos a futuro
en la red, distribucin de la poblacin, estadsticas de uso telefnico en la poblacin, etc. [4]
Los pasos fundamentales para planificar una red son:
1. Recolectar informacin acerca de: leyes y regulaciones, informacin demogrfica,
niveles de ingresos de la poblacin, predicciones de expansin geogrfica,
disponibilidad de frecuencias de microondas, requerimientos de conexin con otros
sistemas, principios de enrutamiento, direccionamiento y numeracin, mapas
topogrficos, infraestructura existente, etc.
2. Dimensionar la red basndose en los requerimientos de cobertura y capacidad, para lo
cual se necesita informacin detallada acerca de las estimaciones de crecimiento,
infraestructura disponible y necesitada, metas de calidad y desempeo, cantidad y tipos
de equipos necesitados, etc.
3. Seleccionar la ubicacin de los MSC, BSC y BTS.
4. Evaluar las diferentes ubicaciones de los MSC, BSC y BTS para ver si la ubicacin
cumple con los requerimientos necesarios. Por ejemplo, al evaluar la ubicacin de una
BTS se debe tomar en cuenta los alrededores, obstculos geogrficos y estructurales y
equipos de radiofrecuencia existentes en la zona.
5. Planificacin detallada de la red. Utilizar sistemas y herramientas con diseo ayudado
por computadora (CAD; Computer Aided Design) para la prediccin del rea de
cobertura, anlisis de interferencia, planificacin de frecuencia, planificacin de
enlaces de microondas, etc.
Existen tres reas fundamentales en la planificacin de una red celular [4]. La
planificacin de la red conmutada (Switching Network Planning), en donde se deben analizar
los requerimientos de calidad, niveles de desempeo, interconexin con otras redes, cantidad
de usuarios, cantidad de servicios ofrecidos, desarrollos y expansin futura de la red, etc. La
planificacin de la red de transmisin celular (Cellular Transmission Network Planning) es la
segunda rea a tomar en cuenta y se enfoca en el diseo de los enlaces de microondas, por
ejemplo, entre BTS y BSC. La ltima rea que se debe tomar en cuenta es la planificacin de
27
la red de radiofrecuencia (Radio Network Planning) o la planificacin de los recursos de

radiofrecuencia, la cual ser discutida con ms detalle a continuacin.
4.2.4.1 Planificacin de los recursos de radiofrecuencia.

El factor fundamental en esta fase de la planificacin de una red celular es la
ubicacin, configuracin y tipo de BTS que se usarn. Se deben realizar anlisis acerca del
tipo de ciudad, volmenes de trfico y distancias de cobertura para identificar la BTS ms
adecuada que se debe utilizar.
En GSM, el rea geogrfica de cobertura de la red celular se divide en celdas. Una
celda corresponde al rea geogrfica cubierta por una BTS. Tericamente, el tamao mximo
de una celda, medido desde el centro de la BTS hasta el borde de la celda, es de 35 km, sin
embargo, el tamao depende de varios factores como nmero de usuarios, tipo y tamao de la
ciudad, frecuencia de transmisin, condiciones geogrficas, topologa, etc. [4]
Para dimensionar una celda, es necesario conocer cuantos canales de trfico (TCH) son
necesarios. Para determinar esto, es necesario calcular un estimado de la capacidad de trfico
necesario, lo cual se hace a travs del nmero de Erlangs necesarios. Un Erlang es la unidad
de medida del trfico de una red y equivale al uso continuo de un canal de comunicacin por
una hora, sin embargo, la cantidad de trfico es independiente al tiempo de observacin por lo
que se puede definir un Erlang como el uso continuo de un canal de comunicacin por tiempo
de observacin. Para calcular el nmero de Erlangs necesarios se usa la siguiente frmula: [4]
Erlangs =
(llamadas. por.tiempo.de.observacion ) (tiempo. promedio.de.conversacion)

(tiempo.de.observacion )
En esta frmula es necesario que el tiempo promedio de conversacin o tiempo

promedio de uso de un canal de comunicacin y el tiempo de observacin estn en las mismas
unidades (segundos, minutos, horas). Por ejemplo, si se tiene un promedio de 540 llamadas
por hora y el tiempo promedio de conversacin es de 100 segundos, entonces la capacidad de
trfico es de 15 Erlangs. Si se decide utilizar un tiempo de observacin de 15 minutos, por
ejemplo, entonces se deben tomar el nmero de llamadas por 15 minutos y el tiempo de
observacin ser de 900 segundos. [4]
28
Otro factor importante al planificar la red de radiofrecuencia es la configuracin de las

BTS que se va a usar. Tres tipos de configuraciones son los ms conocidos y son: La
configuracin omnidireccional, en donde la antena de la BTS puede transmitir y recibir en
360, es decir, el patrn de radiacin de la antena muestra la misma intensidad en todas
direcciones. Existen tambin BTS sectorizadas en dos o tres, esto significa que una BTS posee
dos o tres antenas que transmiten en una determinada direccin, es decir, el patrn de
radiacin de la antena muestra mayor intensidad en un rango determinado de direcciones. La
figura 8 muestra la configuracin 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 ms escasos es el espectro radioelctrico. Solamente hay un nmero limitado
de frecuencias asignadas a un BSS y ste nmero 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 mtodo consiste en asignar las frecuencias
de modo tal de obtener la menor interferencia posible. La asignacin de las frecuencias se
realiza a travs de un patrn de reuso, y en la figura 9 se muestra uno de los muchos que
29
existen. Otros mtodos para optimizar una red celular pueden ser usados, como por ejemplo el
uso de saltos de frecuencia (Frequency hopping), sin embargo, no se mencionarn en este
libro.
Figura 9. Patrn de reuso en una red GSM con 9 frecuencias disponibles. [4]
4.2.4.2 Modelos de propagacin para la planificacin de una red celular

Como se mencion anteriormente, es necesario hacer uso de herramientas que faciliten
la tarea de planificacin a travs del diseo ayudado por computadora (CAD). Tambin 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 seal de radiofrecuencia como la reflexin, refraccin, difraccin, dispersin y las
prdidas de espacio libre, sin embargo, existen muchos modelos utilizados para predecir y
calcular tericamente el rea de cobertura de una BTS. En la figura 10 se muestra un grfico
con algunos de los modelos que existen.
30
Figura 10. Modelos de propagacin y su rango vlido de frecuencias. [8]
El modelo que se presenta a continuacin, es el modelo utilizado en el desarrollo del

proyecto. Se utiliz este modelo debido a que todos los parmetros del modelo, pueden ser
obtenidos de las bases de datos de la Coordinacin de Optimizacin. El modelo escogido fue
el de Okumura-Hata.
Modelo de Okumura-Hata
En la dcada de 1960, estaba en marcha en Japn, una gran campaa orientada a
realizar mediciones en las prdidas en la comunicacin entre dos antenas. Las mediciones de
Yoshihisha Okumura consistieron en hacer calcular la atenuacin de espacio libre entre dos
antenas isotrpicas y luego hacer ajustes y correcciones por excesos de prdida y alturas de la
estacin base y la estacin mvil. Durante las pruebas Okumura vari los siguientes
parmetros: [9] [10]
Frecuencia: 100 3000 MHz
Distancia: 1 100 km
Altura de la estacin mvil: 1 10m
31
Altura de la estacin base: 20 100m

Ambiente o rea: ciudades pequeas, medianas, grandes, etc.
Los valores de prdidas de propagacin se dan como valores medios, 50% del tiempo
y 50% de las reas.
En 1980, Masaharu Hata public un modelo de propagacin parametrizado basado en
las mediciones de Okumura. Las limitaciones o rangos vlidos para el modelo de Hata o
modelo Okumura-Hata son menores a los originales como se muestran a continuacin:
Frecuencia: 150 1500 MHz
Distancia: 1 20 km
Altura de la estacin mvil: 1 10m
Altura de la estacin base: 30 200m
La figura 11 muestra grficamente algunos de los parmetros del modelo OkumuraHata. [10]
Figura 11. Representacin grfica del modelo de propagacin emprico de Okumura-Hata.
La frmula usada para calcular las prdidas de propagacin 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 estacin base
hMS es la altura de la estacin mvil
a(hMS) es un factor de correccin
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 prdidas de propagacin en una zona suburbana se usa la siguiente
ecuacin: [9] [10]
2
LP SUBURBANA
f
= LP 2 log 5.4
28
Para calcular las prdidas de propagacin en una zona rural se usa la siguiente
ecuacin: [9] [10]
LP RURAL = LP 4,78(log( f )) + 18,33 log( f ) 40,94
2
Todo lo expuesto en esta seccin, slo forma parte del inicio de un proceso constante y
continuo de optimizacin 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 ms pequea 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 tamao de la red ya que sta debe ser lo suficientemente grande y lo
suficientemente pequea 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 percepcin como los son la cantidad de llamadas cadas, calidad de la voz,
cantidad de llamadas fallidas, etc. Por ltimo, la red debe ser analizada constantemente en
bsqueda 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 tecnologas 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
coleccin 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 estn
organizados en libros y clasificados segn el tipo o al gnero 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 aos de la dcada de 1960, cuando el primer sistema administrador
de bases de datos de propsito general fue creado por Charles Bachman en General Electric
[12], se han desarrollado varios modelos que son usados para representar la informacin
almacenada en una base de datos. El modelo de red de datos (en ingls network data model),
34
el modelo de datos jerrquicos (hierarchical data model), el modelo de datos orientados a

objetos, el modelo de datos entidad-relacin y el modelo relacional de bases de datos
(relational data model) son algunos de los ejemplos que muestran la evolucin de las bases de
datos. Hoy en da, el modelo de bases de datos ms aceptado a nivel mundial es el modelo
relacional desarrollado por Edgar Codd en los laboratorios de investigacin de IBM en San
Jos, California, durante la dcada de 1970. [12] [13]
Antes de que se desarrollaran los conceptos de bases de datos y de administradores de
bases de datos, la informacin 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 modificacin 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 debera
ocurrir.
Para evitar tamaos 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 tendrn problemas de inconsistencia y redundancia si no se
realiza un diseo 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 informacin de la cuenta corriente y la cuenta de ahorros de sus clientes, es
probable que tanto el nmero telefnico como la direccin de los clientes aparezcan
en ambos archivos (problemas de redundancia), lo que hace que las bases de datos
crezcan de manera desmesurada.
Para realizar bsquedas o consultas de informacin 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 bsqueda a las diseadas originalmente, es

necesario desarrollar otro programa que satisfaga la nueva o nuevas necesidades. Otra
opcin casi impensable, debido a la cantidad de tiempo invertido, es la de realizar la
bsqueda manual de la informacin deseada.
Puede ocurrir que los archivos hayan sido diseados con diferentes formatos lo que
hace que la tarea de desarrollar un nuevo programa sea ms complicada.
Pueden tambin 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 diseo, tratar de cambiar las polticas 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 aparicin de diferentes modelos de bases de datos, y con el desarrollo y
aparicin 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 mltiples usuarios.
Asegurar la integridad de los datos.
Administrar procesos de respaldo y recuperacin de datos.
4.3.2
Modelo relacional de bases de datos

Un modelo de datos es una representacin 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 informacin. Las entidades pueden ser objetos fsicos o abstractos como por ejemplo una
persona, un lugar, un evento, un producto, una ruta de vuelo, etc.
Un atributo es una caracterstica de una entidad. Por ejemplo, una entidad llamada
PERSONA puede ser descrita o identificada a travs de atributos tales como nombre, apellido,
telfono, direccin, nmero de cdula, etc.
Una relacin, componente principal del modelo relacional de bases de datos, permite
mostrar y almacenar la informacin 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 combinacin nica de los
atributos de la relacin. Existe tambin lo que se conoce como schema, que describe las
caractersticas de una relacin 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 relacin o tabla de una base de datos
relacional.
Figura 12. Relacin 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 ms 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 mtodo sistemtico para crear, actualizar, buscar y
almacenar informacin en una base de datos. Adems, un administrador de bases de datos
debe tener la capacidad de ofrecer la integridad y seguridad de los datos as como tambin la
capacidad de optimizar y controlar el acceso a los datos [11]. En la figura 13 se muestra la
relacin entre un DBMS y una base de datos [11]
Figura 13. Relacin 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).
Bsicamente el administrador de almacenamiento se encarga de hacer el mejor uso
posible de los datos almacenados. Existen empresas cuyas bases de datos pueden alcanzar
tamaos 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 informacin, 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 segn 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 mdulos o componentes de un sistema de bases de datos es el
administrador de almacenamiento el cual, adems 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 funcin del administrador de
almacenamiento, por lo tanto, traducir declaraciones en lenguaje de manipulacin 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 autorizacin e integridad (Authorization and Integrity Manager)
el cual comprueba que se satisfagan ciertos niveles de integridad y verifica la
autorizacin 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 despus 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 ubicacin de los datos en el disco.
El administrador de bferes (Buffer Manager) el cual se encarga de llevar datos desde
el disco hasta la memoria principal del equipo, y decide cuntos y cules datos deben
permanecer en ella. El administrador de bferes es una parte crtica del sistema de
bases de datos ya que ste permite que se puedan usar bases de datos que son mucho
ms 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 informacin 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 descripcin de cada una de las tablas o
relaciones.
ndices (Indexes) que permiten acceder a datos que poseen valores especficos 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 bsqueda 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 evaluacin que debe ser analizado por el evaluador de consultas. Una
consulta, generalmente, puede ser ejecutada a travs de distintos planes de evaluacin,
por lo tanto, es una funcin del compilador DML realizar una optimizacin de la
consulta, es decir, escoger el plan de evaluacin que resulte en el menor costo posible.
El motor de evaluacin de consultas (query evaluation engine), el cual ejecuta las
instrucciones de bajo nivel generadas por el compilador DML.
Como se ver ms adelante, el DDL y DML tambin 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 simultneamente
sin que se produzca una prdida 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 caractersticas fundamentales denominadas
propiedades ACID, por sus siglas en ingls. Estas propiedades son: [13]
Atomicidad (Atomicity): Es necesario, que todas las transacciones se ejecuten, o que
ninguna lo haga. Esto asegura que ninguna operacin realizada puede quedar a medias.
Consistencia (Consistency): Se refiere al estado de una base de datos cuando se inicia
y se finaliza una transaccin. Existen reglas o limitaciones de integridad o consistencia
que no pueden ser rotas por una transaccin. Por ejemplo, una limitacin o condicin
de consistencia para una aerolnea puede ser que un asiento no puede ser asignado a
dos pasajeros distintos. A pesar de que sto puede ocurrir durante la asignacin 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 ms transacciones se ejecutan de forma
concurrente o simultnea, sus efectos deben estar aislados entre ellas, es decir, los
efectos de dos transacciones ejecutndose simultneamente, deben ser los mismos a
los efectos que se obtendran si se ejecuta una transaccin primero y la otra despus.
Durabilidad (Durability): Si una transaccin se ha completado exitosamente, sus
efectos debern persistir (no se deben perder) incluso si el sistema falla
inmediatamente despus de que la transaccin 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 expresin de lgebra relacional. Existen cuatro
categoras fundamentales en las operaciones de lgebra relacional: [15]
Operaciones tpicas de conjuntos: unin, interseccin y diferencia, aplicadas a
relaciones o tablas.
Operaciones que eliminan parte de una relacin: Operacin de seleccin elimina tuples
(filas) y la operacin de proyeccin 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 relacin sino
que cambia la schema de la relacin, es decir, se modifican los nombres de los
atributos y/o el nombre de la misma relacin.
Existe otra gran cantidad de operaciones adicionales a las mencionadas anteriormente,
como por ejemplo operaciones de eliminacin, insercin y actualizacin, y operaciones de
creacin 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 funcin de una vista o view ya que stas son usadas en el desarrollo del
proyecto.
Una vista o view es una relacin o tabla que no existe fsicamente en una base de
datos, en otras palabras, una vista es una relacin virtual de una base de datos [13]. Una vista
puede tener varias funciones entre las cuales se pueden mencionar la capacidad de aadir
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 relacin 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 creacin de
esta vista tiene dos funciones. La primera es que podemos restringir al acceso a la relacin
r1 y permitir el acceso a la vista v1, de esta forma podemos proteger los datos de la
relacin r1 que no son utilizados por la vista v1. Otra de las funciones es simplificar la
ejecucin del comando SQL necesitado. Con la creacin de la vista, slo 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 ms
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 Estndares (ANSI; American National Standards Institute) y
la Organizacin Internacional para la Estandarizacin (ISO; International Organization for
Standarization) desarrollaron el primer estndar SQL denominado SQL-86. Hoy en da el
estndar ms reciente desarrollado por ANSI / ISO es el SQL:1999, tambin conocido como
SQL3. [13] [15]
A pesar de que la mayora de los sistemas administradores de bases de datos no dan
soporte a todas las caractersticas especificadas en el estndar SQL:1999, la mayora de los
fabricante dirigen sus esfuerzos para incorporar stas caractersticas en sus sistemas
administradores. Es evidente que SQL, siendo el lenguaje ms usado actualmente en los
sistemas administradores de bases de datos, casi todos los fabricantes ofrecen las
caractersticas bsicas y componentes que se mencionan a continuacin: [13] [15]
44
Lenguaje de definicin de datos (DDL; Data-Definition Language): Esta parte de SQL

provee los comandos necesarios para crear, borrar o modificar schemas de una relacin
o tabla.
Lenguaje de manipulacin de datos (DML; Data-Manipulation Language): El SQL
DML incluye un lenguaje de consulta basado en el lgebra relacional y en el clculo
relacional de tuples.
Definicin de vistas (View definition): El SQL DDL incluye comandos que permiten
definir vistas o views. Las vistas proporcionan la simplificacin de comandos SQL que
son ejecutados con frecuencia.
Control de transaccin (Transaction control): SQL incluye comandos para especificar
el inicio y el final de una transaccin.
SQL nativo y SQL dinmico (Embedded SQL and dynamic SQL): Tanto el SQL nativo
como el dinmico definen la forma en que las declaraciones SQL pueden ser
incorporadas dentro de lenguajes de programacin 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 sern permitidas.
Autorizacin (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, tpico para la bsqueda de informacin en una base de datos consta
generalmente de tres partes. stas son: SELECT, FROM y WHERE [13]
La clusula SELECT corresponde a la operacin de proyeccin del lgebra relacional.
La clusula FROM corresponde al producto Cartesiano del lgebra relacional.
La clusula WHERE corresponde a la operacin de seleccin del lgebra relacional.
Como se puede ver el trmino SELECT tiene un significado diferente en lenguaje SQL
que en el lgebra relacional. Finalmente a continuacin se da un ejemplo de comando SQL:
45
SELECT a1, a2, a3, a4 FROM r1 WHERE a2 = x

Este comando selecciona de la relacin (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 relacin, 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 travs de la ejecucin 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 transaccin es una unidad de ejecucin de programa que puede acceder y
actualizar varios elementos en una relacin [13].
Generalmente, una transaccin 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 segn el DBMS utilizado). La
transaccin 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 seccin 4.3.4.3, para garantizar la correcta ejecucin de
todos los comandos SQL involucrados en la transaccin. [13]
4.3.7
Desempeo de un sistema administrador de bases de datos

Un administrador de bases de datos (DBA; DataBase Administrator) puede mejorar el
desempeo al modificar los parmetros de un DMBS (por ejemplo, el tamao del conjunto de
bferes o la frecuencia de puntos de verificacin) y al identificar y eliminar cuellos de botella
en el sistema [12]. Para analizar el desempeo de un sistema de bases de datos, es necesario
tomar en cuenta cinco factores: Carga de trabajo, tasa de transferencia o rendimiento,
recursos, optimizacin y contencin [11] [12]
Carga de trabajo (Workload): Es una combinacin 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, cules son las relaciones
(tablas) ms consultadas o modificadas, cules son los atributos (columnas) ms
consultados o modificados y cules son los atributos que tienen condiciones en
operaciones de seleccin o de unin.
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
disposicin del sistema de bases de datos, por ejemplo, ncleo del sistema, dispositivos
de almacenamiento, mdulos de memoria RAM, controladores de cach, microcdigo
del CPU, etc.
Optimizacin (Optimization): Hace referencia a todos aquellos factores que afectan al
sistema de bases de datos en la manera de crear el camino ms eficiente para el acceso
47
a los datos, por ejemplo, optimizacin de consultas, parmetros del sistema y de las
bases de datos, etc.
Contencin (Contention): Es la condicin donde dos o ms componentes de la carga de
trabajo intentan usar un mismo recurso de una forma conflictiva (por ejemplo, realizar
actualizaciones simultneas a un dato especfico). A medida que aumenta la
contencin, disminuye la tasa de transferencia.
En resumen se puede definir el desempeo de un sistema administrador de bases de
datos como el uso optimizado de recursos para aumentar la tasa de transferencia y minimizar
la contencin, permitiendo el procesamiento la carga de trabajo ms grande posible.
4.3.7.1 ndices
En una forma general, un ndice es una estructura de datos que hace ms eficiente la
bsqueda de informacin en una tabla. Los ndices se asignan a los atributos (columnas) de
una relacin (tabla), y ayudan en bsquedas 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 pgina del libro hasta
encontrar el tema deseado. Es mucho ms rpido y simple buscar en el ndice del libro la frase
Modelo relacional y el encontrarla, ir directamente a las pginas 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 relacin, por entidades con valores de
atributos especficos, resulta una tarea que requiere mucho tiempo. La estructura de un ndice
es la que ayuda en este tipo de bsquedas, 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 relacin que contienen el valor especificado en el
index key. Esto se puede ver con un ejemplo: Si se tiene una relacin que contiene datos
acerca de pelculas de cine, como por ejemplo el ttulo de la pelcula, el ao de estreno, el tipo
de pelcula, la clasificacin de la pelcula, etc. Al atributo ao de estreno contiene valores
que van desde 1980 hasta 2006. Obviamente, existen entidades o filas en las que el valor para
ao de estreno puede ser igual. Si se define un ndice en esta columna ao de estreno,
entonces las claves de ndices o index key tendrn valores de por ejemplo, 1981, 1990, 2000,
2001, etc., es decir, tendrn los valores de todos los aos de estreno diferentes que aparezcan
en la columna ao de estreno. Cada index key tendr asociado un conjunto de apuntadores
dependiendo del valor de la columna ao de estreno al cual se haga referencia, es decir, si
un index key hace referencia al valor 1990 de la columna ao 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 ao de estreno el valor 1990. Para buscar todas las pelculas
estrenadas en el ao 1990 slo 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 mtodo de bsqueda es mucho ms rpido y eficiente, que leer cada fila
de la tabla, en la que pueden haber cientos de miles de pelculas, y escoger las pelculas
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 cmo 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 interaccin 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 comunicacin con una base de datos. [15]
Un proceso cliente-servidor se inicia cuando el cliente interacta con un usuario y
enva una peticin al servidor. ste se encarga de recibir, programar y ejecutar la peticin
recibida y selecciona solamente aquellos datos necesitados por el cliente. El servidor enva los
datos al cliente slo cuando ste lo solicita. A continuacin 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 grficas (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 fcil
interaccin 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 ms complicado en donde diferentes plataformas (LANs, sistemas
operativos, etc.) son difciles de administrar.
Un aumento en el nmero 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 crculo de usuarios mucho ms

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 comunicacin con un sistema administrador
de bases de datos, es necesario que exista un componente fundamental entre el DBMS y la
aplicacin 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
estndar desarrollado por Microsoft que permite acceder a cualquier dato desde cualquier
aplicacin, sin importar el DBMS que almacene los datos [16]. ODBC habilita la integracin
de SQL en lenguajes de propsito general como C y expone las capacidades de un sistema
administrador de bases de datos a travs de una interfaz de programacin de aplicacin (API;
Application Programming Interface). A diferencia del lenguaje SQL nativo, ODBC permite el
acceso a diferentes DBMS sin la necesidad de recompilar el DBMS. Adems, con el uso de
ODBC, una aplicacin puede acceder a los datos de varios DBMS simultneamente. [12]
ODBC logra alcanzar su gran flexibilidad al introducir un nivel adicional en la
interaccin entre la aplicacin y el DBMS. Cualquier interaccin directa con el DBMS deber
pasar por un controlador o driver especfico 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, especficas para el DBMS para el que fue diseado. [12]
Una aplicacin que interacta con un origen de datos a travs de ODBC debe realizar
los siguientes pasos: Seleccionar un origen de datos (puede ser un archivo de texto, una hoja
de clculo o un sistema administrador de bases de datos (DBMS)), cargar dinmicamente el
controlador adecuado y establecer la conexin con el origen de dato. Mientras la conexin
permanezca abierta, se pueden realizar transacciones a travs de comandos SQL, recuperar
51
resultados, procesar errores y finalmente ejecutar (commit) o deshacer (rollback) las

transacciones realizadas. Por ltimo, la aplicacin debe desconectarse del origen de datos para
finalizar la interaccin. [12]
4.4.1.1 Arquitectura de ODBC

La arquitectura de ODBC tiene cuatro componentes principales: La aplicacin
(Application), el administrador de controladores (Driver Manager), los controladores
especficos para cada origen de datos (ODBC Driver) y los orgenes de datos propiamente
dichos (Data Source). La figura 16 muestra los cuatro componentes de la arquitectura ODBC.
[17]
Figura 16. Arquitectura de ODBC.
La aplicacin se encarga de iniciar y terminar las conexiones con el origen de datos y

debe enviar consultas y recuperar sus resultados, todo esto a travs 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 aplicacin al
controlador adecuado. Adems, el administrador de controladores debe inicializar la interfaz
ODBC, permitir apuntar o anotar las llamadas a funciones realizadas y debe hacer verificacin
de errores. El controlador establece la conexin con el origen de datos y adems de enviar
consultas y recibir los resultados, debe traducir los datos, cdigos de error, etc., de una forma
52
que es especfica para cada origen de datos al estndar ODBC. Finalmente, el origen de datos
es quien procesa y recibe los comandos del controlador y entrega los resultados necesarios.
4.4.2
Mtodos de acceso a orgenes de datos

Visual Basic puede usar varios mtodos para interactuar con un origen de datos a
travs de ODBC. Tres de los mtodos ms comunes son: RDO, DAO y ADO. Como no es
objetivo discutir las ventajas y desventajas de cada uno de estos mtodos, solamente se
presentar una breve descripcin 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 travs de ODBC. DAO se adapta mejor a aplicaciones bajo
sistemas nicos o para desarrollos pequeos 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 travs 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 ms propiedades, mtodos y eventos. La
funcionalidad de ADO es ms similar a la de RDO, sin embargo, se basa en la interfaz
OLE DB para acceder a orgenes de datos (generalmente a travs 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.

Segn [22], DAO trabaja mejor con bases de datos que el motor Microsoft Jet puede
leer, estas bases de datos no incluyen los orgenes 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
ejecucin del proyecto de grado presentado en este libro se hicieron usando ADO. Una
importante caracterstica entre ADO, RDO y DAO es que, segn [24] y [25], RDO y DAO son
ya tecnologas obsoletas y no sern compatibles o no estarn disponibles para sistemas con
procesadores de 64-bits, como lo ser ODBC y ADO.
5. METODOLOGA
La estrategia metodolgica usada durante el desarrollo de este proyecto de grado se
fundament en el diseo de etapas secuenciales que permitieran lograr todos los objetivos
planteados.
El proyecto se dividi en 14 etapas diferentes las cuales se mencionan a continuacin:
5.1
Investigacin preliminar
Durante esta primera etapa se identificaron claramente las necesidades, problemas,
limitaciones y alcance del proyecto as como tambin los recursos disponibles para desarrollar
el mismo.
Para lograr el desenvolvimiento adecuado del proyecto es necesario recopilar toda la
informacin posible acerca del funcionamiento de la empresa. En este sentido, se indag
acerca de las polticas, normas y procedimientos que se deben cumplir tanto en la
Coordinacin de Optimizacin como en la corporacin Digitel GSM.
En esta etapa tambin se incluye la identificacin del personal de la Coordinacin de
Optimizacin y de todas aquellas personas involucradas en el proyecto adems de los recursos
usados por el personal para realizar el trabajo del da a da. Tambin se identificaron
procedimientos manuales llevados a cabo por el personal de la Coordinacin de Optimizacin
que pudieran ser automatizados, especficamente el procedimiento para realizar el clculo de
las adyacencias de una BTS.
5.2
Anlisis preliminar de las herramientas y bases de datos

Con el objetivo de iniciar rpidamente el desarrollo del proyecto, en esta etapa se
estudiaron, analizaron e identificaron los componentes crticos en las herramientas de trabajo

usadas por la Coordinacin de Optimizacin as como tambin el funcionamiento bsico y el
uso regular de las mismas.
55
Un anlisis bsico 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 programacin 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
Migracin inicial de las bases de datos

Para poder desarrollar el programa de pruebas, luego de identificar las consultas ms
frecuentes y las bases de datos ms usadas, se llev a cabo la migracin de stas bases de
datos a los dos administradores de licencia libre (PostgreSQL y MySQL) escogidos. Adems,
debido a una de las necesidades por parte de la Coordinacin de Optimizacin, 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 anlisis preliminar de las herramientas y bases de datos sirvi como base para el
diseo 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 ejecucin
de las consultas realizadas.
La herramienta desarrollada tambin permite realizar diferentes tipos de consulta,
cambiar parmetros de conexin a las bases de datos y modificar los controladores o drivers
ODBC (Open DataBase Connectivity) usados para realizar la conexin a los administradores.
56
5.5
Ejecucin 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 rpidamente una diferenciacin entre
los mismos.
Las pruebas se basaron en los anlisis 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
Anlisis de las pruebas preliminares a los administradores de bases de datos

En esta etapa se identificaron las diferencias ms 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
Investigacin detallada acerca de los administradores de bases de datos, sistemas

operativos, conexiones de red, controladores o drivers y lenguaje de programacin
Luego del anlisis de los resultados preliminares a los administradores de bases de
datos, se investig en detalle el funcionamiento de stos as como tambin el de los

componentes y factores involucrados en su uso como lo son el sistema operativo, la conexin
de red, el lenguaje de programacin y el controlador para lograr la conexin a las bases de
datos.
La investigacin se enfoc principalmente en identificar los parmetros de los factores
antes mencionados que pudieran afectar la velocidad de procesamiento de los administradores
de bases de datos.
57
5.8
Ejecucin de las pruebas finales a los administradores de bases de datos

Luego de realizarse una investigacin detallada acerca del funcionamiento de los
administradores de bases de datos y de los parmetros que afectan su velocidad de

procesamiento, se realizaron pruebas en donde se ejecutaron diferentes consultas con
diferentes parmetros de configuracin de manera de comparar y establecer el administrador
ms adecuado para la Coordinacin de Optimizacin.
Las pruebas incluyeron cambios en: La configuracin de MySQL y PostgreSQL, los
parmetros de funcionamiento del sistema operativo Linux, las conexiones de red, los
controladores de conexin a los administradores (controladores ODBC), las consultas
realizadas por el programa de pruebas y el mtodo usado en el programa de prueba para
consultar informacin en las bases de datos.
5.9
Anlisis de las pruebas finales a los administradores de bases de datos

El anlisis se bas principalmente en comparar los tiempos de procesamiento de datos
de los diferentes administradores y seleccionar la configuracin de aquel que result realizar

el procesamiento de datos en menor tiempo.
5.10 Modificaciones a las herramientas Daily Optimizer y Parameter de la Coordinacin

de Optimizacin
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. Tambin se modificaron las
herramientas para eliminar redundancia de variables y cdigo, eliminar variables y funciones
innecesarias, crear funciones o realizar modificaciones para compactar el cdigo, sin embargo,
la modificacin ms significativa fue la de crear el cdigo 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 Coordinacin

de Optimizacin
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 informacin presentada estuviera acorde con la informacin procesada por
versiones anteriores de las herramientas.
5.12 Investigacin detallada acerca del procedimiento para el clculo de las adyacencias
de una BTS
Durante esta etapa se recopil toda la informacin acerca del procedimiento manual
que realiza el personal de la Coordinacin de Optimizacin para calcular las adyacencias de
una BTS. Adems, se investig acerca de los modelos y ecuaciones matemticas necesarias
para desarrollar la herramienta.
5.13 Desarrollo de la herramienta para el clculo automtico de las adyacencias de una

BTS
Basado en la investigacin previamente realizada, se desarroll en Visual Basic 6 la
herramienta para el clculo 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 interseccin entre las reas de cobertura de dos BTS cualquiera y por supuesto, las
adyacencias de una BTS. Los clculos se realizan con datos provenientes de una base de datos
y datos introducidos por el usuario. Adems, la herramienta es capaz de agregar, modificar o
eliminar una BTS o informacin de la misma de la base de datos.
59
5.14 Ejecucin de las pruebas a la herramienta para el clculo automtico de las

En esta fase se comprueba que las adyacencias calculadas al usar la herramienta
coincidan en ms del 50% con las adyacencias actualmente definidas para cada BTS. Si una
BTS posee 10 adyacencias definidas por el personal de la Coordinacin de Optimizacin, al
menos 5 de estas adyacencias deben ser iguales a las calculadas con la herramienta.
Esta metodologa basada en la metodologa de ensayo y error, se utiliz debido a la
rapidez que ofrece al desarrollar un proyecto. Debido a la inmensa cantidad de informacin y
conocimientos que involucra el configurar y administrar un sistema de bases de datos y un
sistema operativo, es imposible, en un perodo de 3 meses, adquirir todos los conocimientos
necesarios para configurar correctamente un servidor de bases de datos. La metodologa usada
en este proyecto, permite adquirir los conocimientos necesarios para resolver e identificar
problemas tanto en la configuracin 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 Coordinacin de Optimizacin, es decir, las consultas sean fundamentalmente selecciones y
bsqueda de informacin en las bases de datos.
Adems, la metodologa diseada 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 ms rpida 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 Coordinacin de Optimizacin de la corporacin Digitel GSM, se ha visto en la
necesidad de almacenar y procesar cada vez mayor cantidad de informacin debido al
constante crecimiento y expansin de la red celular sobre la cual trabaja. Analizar y mejorar el
desempeo y funcionamiento de la red celular, trabajo que se lleva a cabo en la Coordinacin
de Optimizacin, es fundamental para posicionar a la empresa como lder entre sus
competidores. Este trabajo de anlisis 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 Coordinacin de
Optimizacin, est relacionado con un crecimiento en la cantidad de informacin que sta
debe almacenar, procesar y analizar. El personal de la Coordinacin de Optimizacin
desarroll un conjunto de herramientas y bases de datos para facilitar la tarea de anlisis del
desempeo de la red, sin embargo, estas herramientas y bases de datos no se disearon para
procesar grandes cantidades de informacin.
El objetivo de este estudio es poder seleccionar un administrador de bases de datos que
sea de licencia libre que sea capaz de procesar informacin con mayor rapidez que el
administrador que actualmente usa la Coordinacin de Optimizacin.
Este estudio comparativo comprende las primeras 9 etapas de la metodologa 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 ejecucin del mismo. En este sentido, se
estableci la condicin de que los administradores de bases de datos de licencia libre se deban
probar bajo un sistema operativo Linux, ya que las bases de datos de muchas de las
61
Coordinaciones (incluyendo la Coordinacin de Optimizacin) del Departamento de

Operaciones de Digitel GSM sern migradas a un servidor en el cual se instalarn
exclusivamente programas de licencia libre.
Para la ejecucin y desarrollo del estudio comparativo se dispuso de tres computadores
con las siguientes caractersticas:
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 limitacin encontrada durante el desarrollo de este estudio fue la asignacin
inamovible del uso de estos tres computadores. El computador 1 es un servidor basado en
Windows 2000 en el cual estn ubicadas las bases de datos de la Coordinacin de
Optimizacin. El computador 2 es un servidor basado en Linux en donde se realizarn las
pruebas de los nuevos administradores de bases de datos de licencia libre. El computador 3 es
una estacin de trabajo de donde se administran las bases de datos.
Los administradores de bases de datos que sern sometidos a una comparacin se
presentan a continuacin 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
dependern 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 simultneamente.
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
simultneamente.
o Windows 2000 Professional: 64 MB de RAM y adicionalmente, 8 MB de
RAM por cada programa de Office (como Word) que se ejecute
simultneamente.
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 simultneamente.
Disco duro: Los requerimientos de espacio en el disco duro varan dependiendo de la
configuracin; las opciones en una instalacin personalizada pueden necesitar ms o
menos. A continuacin se muestran los requerimientos mnimos 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 ms de espacio
en el disco duro para actualizacin 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 resolucin.
MySQL 5.0
Los recursos usados por MySQL son determinados por el tamao de las bases de datos
y por la configuracin de los parmetros del DMBS. A medida que el tamao de las
bases de datos crece, MySQL necesitar ms memoria, ms velocidad de procesador,
ms espacio en el disco duro. Sin embargo, el uso de recursos puede ser limitado por el
administrador del sistema modificando la configuracin 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 tamao de las bases de
datos y por la configuracin del DBMS. A medida que el tamao de las bases de datos
crece, PostgreSQL necesitar ms memoria, ms velocidad de procesador, ms espacio
en el disco duro. Sin embargo, el uso de recursos puede ser limitado por el
administrador modificando la configuracin 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
Migracin de las bases de datos necesarias para el programa de pruebas

Luego de realizar un anlisis preliminar sobre las herramientas y bases de datos se
determin que se migraran los siguientes componentes de las bases de datos:

Tablas
TABLA_GENERAL_GPRS (estadsticas_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 Coordinacin de Optimizacin 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 instalacin 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 adquisicin de un
servidor HP Blade que ser usado no slo por la Coordinacin de Optimizacin, sino por el
resto de las coordinaciones del Departamento de Optimizacin de Digitel GSM. Todas las
bases de datos sern 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 instalacin se presentaron problemas que postergaron una
semana, aproximadamente, la migracin de las bases de datos y el desarrollo de la herramienta
de pruebas. A continuacin se describen los problemas que se encontraron:
Actualizacin del sistema operativo Red Hat Linux 8

El computador 2 inicialmente tena como sistema operativo Red Hat Linux 8. Este
sistema operativo no permite ni la instalacin de PostgreSQL (versiones superiores a la 7.3) ni
la de MySQL (versiones posteriores a la 3.23). Esto se debe a que el ncleo o kernel y las
66
libreras del sistema operativo no estn actualizadas para realizar la instalacin de estos
programas.
La actualizacin de las libreras y del kernel de Red Hat Linux 8 requiri un arduo
trabajo de investigacin y documentacin, 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 actualizacin de Red Hat Linux 8 deba ser ejecutada por el personal de la Coordinacin de
Optimizacin el cual no tiene experiencia usando sistemas operativos Linux.
Instalacin de dos sistemas operativos Linux; Debian y SUSE

El sistema operativo Linux Debian se instal por recomendacin de personas dentro
del Departamento de Operaciones pero fuera de la Coordinacin de Optimizacin debido a su
mejor estabilidad y desempeo. Linux Debian realiza la instalacin por defecto de las
versiones 3.23 de MySQL y 7.3 de PostgreSQL. A travs del administrador de paquetes de
Debian (apt-get) se puede obtener la versin 4.1 de MySQL y la 7.4 de PostgreSQL, sin
embargo, luego de realizar la instalacin de Linux Debian se descubri que a pesar de que el
ncleo del sistema operativo era una versin actualizada, existan libreras desactualizadas
necesarias para la instalacin de versiones superiores de MySQL y PostgreSQL. Aunque esta
actualizacin necesaria no era complicada y no requera de mucho tiempo para realizarla, se
decidi instalar el sistema operativo SUSE Linux 10.1 luego de realizar una investigacin
acerca de la gran variedad de sistemas operativos Linux existentes y disponibles. Se escogi
SUSE Linux principalmente debido a que las versiones del ncleo y de las libreras instaladas
son las ms recientes. Existen otros motivos como facilidad de manejo y de actualizacin, que
motivaron la seleccin definitiva de SUSE Linux 10.1 como sistema operativo para el sistema
administrador de bases de datos de la Coordinacin de Optimizacin.
67
Versin 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 Coordinacin de Optimizacin utilizan vistas para
consultar las tablas de las bases de datos. Las vistas son un recurso que se introduce a partir de
la versin 5.0 de MySQL [29] y permiten realizar o ejecutar consultas de forma abreviada. El
concepto de vista se mencion en el captulo 4, sin embargo, a continuacin se muestra otro
ejemplo de cmo 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
continuacin,
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 migracin inicial de las bases de datos, es decir, se migraron las
tablas y consultas ms 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 travs de una misma interfaz grfica, y que se pudieran
visualizar los tiempos transcurridos despus de enviar una consulta o comando SQL a los
DBMS.
En la figura 18 se muestra la interfaz grfica del programa usado para comparar la
velocidad de procesamiento de los administradores de bases de datos.
Figura 18. Interfaz grfica del programa de pruebas desarrollado con Visual Basic 6 para la
comparacin de los tres DBMS.
Como se mencion en el captulo 4, Visual Basic 6 es capaz de acceder a datos de

diferentes fuentes (archivos, bases de datos, etc.) usando tres mtodos distintos: A travs del
uso de objetos RDO, a travs del uso de objetos DAO o a travs del uso de objetos ADO.
69
Tambin se mencion en el captulo 4 que de acuerdo con [25] y [26], ADO es ms poderoso
y que RDO y DAO son tecnologas obsoletas. Por esto se escogi ADO.
Para realizar una conexin 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
conexin. Por lo tanto, en el computador 3 se instalaron los controladores ODBC ms
recientes tanto de MySQL (ODBC versin 3.51) y PostgreSQL (ODBC versin 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 descripcin y el controlador que se debe usar para conectarse a un
origen de datos. Se decidi crear la conexin a las bases de datos sin usar un DSN ya que de
esta forma se pueden controlar y variar los parmetros de los controladores desde el programa
de Visual Basic. Adems, para realizar una conexin con DSN es necesario que cada
computador que ejecute el programa, deba tener creado el mismo DSN. sto, adems de ser
engorroso, es indeseable si los usuarios que harn uso de las herramientas, tienen poca
experiencia en manejar la configuracin de sistemas operativos Windows. A continuacin se
muestra un ejemplo del cdigo 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 cdigo anterior se muestra la diferencia entre una conexin con DSN (las lneas
que empiezan con ) y una conexin sin DSN. Como se puede ver, a pesar de que al usar
DSNs el cdigo se simplifica y se hace ms fcil, no se pueden controlar los parmetros de los
controladores ODBC a travs 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 travs de campos de texto y botones enva las consultas
deseadas a los diferentes administradores de bases de datos. La interfaz grfica se explica a
continuacin: (hacer referencia a la figura 18)
71
Botn Connect to MySQL: Con este botn se enva 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.
Botn Connect to PostgreSQL: Con este botn se enva 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.
Botn Connect to Access: Con este botn se enva 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 .
Botn Clear datagrid: Este botn sirve para borrar los datos de la tabla que muestra
la informacin obtenida luego de ejecutar una consulta.
Botn Reset: Este botn 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).
Botn Change PostgreSQL ODBC Driver Settings: Este botn permite cambiar los
parmetros 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 envo de un comando SQL o
consulta al administrador de bases de datos MySQL y la finalizacin de su ejecucin.
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 envo de un
comando SQL o consulta al administrador de bases de datos PostgreSQL y la
72
finalizacin de su ejecucin. 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 envo de un comando SQL o
consulta al administrador de bases de datos Microsoft Access y la finalizacin de su
ejecucin. 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
ejecucin 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 ejecucin de un
comando SQL y la presentacin por pantalla de los resultados.
Cuadro de texto Text7: Ubicado bajo el nombre Number of rows in query, este
cuadro de texto muestra el nmero de filas devueltas despus de ejecutar un comando
SQL.
Cuadro de texto T:\estadsticas_gprs.mdb: En este cuadro de texto se debe colocar
la ruta o ubicacin 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 numrico de fecha (ao-mes-da) 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 continuacin
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 botn que se presione).
73
tabla: Se obtiene de cualquiera de los cuadros de texto bajo la etiqueta Query

table or view (depende del botn que se presione).
Fecha 1: Se obtiene de la etiqueta Fecha 1.
Fecha 2: Se obtiene de la etiqueta Fecha 2.
nombreBTS: Se obtiene de la lista desplegable Combo1
Para cambiar cualquiera de las etiquetas por una fecha vlida, se debe seleccionar una
fecha en el calendario y a continuacin 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 numrico de fecha ao-mes-da.
Cuadro de seleccin o CheckBox Use Client Cursors: Esto permite cambiar una de
las opciones del mtodo de conexiones ADO. Si este cuadro de seleccin se encuentra
marcado, entonces todas las conexiones y consultas usarn cursores manejados por el
cliente, al contrario, si este cuadro no se encuentra marcado, las conexiones y
consultas usarn cursores manejados por el servidor.
Cuadro de seleccin o CheckBox Restart connection to databases after every query:
Al seleccionar o marcar esta opcin, el programa de pruebas cerrar y abrir
nuevamente la conexin a cada uno de los administradores de bases de datos despus
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 despus de ejecutar una o varias consultas.
Debido a la metodologa usada para llevar a cabo el proyecto de grado desarrollado en
este libro, el programa de pruebas tuvo un diseo inicial que no inclua algunos de los
componentes antes mencionados (por ejemplo, los cuadros de seleccin de cursores y de
74
reiniciar las conexiones a las bases de datos). La interfaz grfica descrita anteriormente hace
referencia a la ltima versin del programa de pruebas utilizada para realizar el estudio
comparativo de los tres administradores de bases de datos. Esta versin 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 migracin no slo del administrador de bases de datos sino del sistema
operativo usado por el personal de la Coordinacin de Optimizacin 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 comparacin al momento de elegir el administrador de
base de datos ms adecuado para la Coordinacin de Optimizacin. 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 extrao 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 ms rpido 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 parmetros de configuracin de los
administradores de bases de datos, ni en los parmetros de configuracin de los controladores
ODBC, ni en los parmetros de las conexiones de red, ni en los parmetros 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 continuacin se muestra una descripcin 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 enva por
red al cliente que pide la informacin. La tabla TABLA GENERAL GPRS posee 55
columnas y ms de 500.000 filas de informacin. Esta prueba se realiz 5 veces para cada
administrador de base de datos siguiendo el procedimiento que se describe a continuacin:
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 especfico.
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 envan. Esta prueba se hace abriendo y cerrando las conexiones a
los administradores de bases de datos imitando el mtodo usado por las herramientas de la
Coordinacin de Optimizacin 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 segn los valores de la columna FECHA y enva los resultados al
cliente que pide la informacin. Esta prueba se realiz 5 veces para cada administrador de
base de datos siguiendo el procedimiento que se describe a continuacin:
bases de datos.
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 informacin
contenida en tablas de gran tamao, es decir, los datos se leen, se procesan de alguna manera
(en este caso se ordenan) y se envan. Esta prueba se hace abriendo y cerrando las conexiones
a los administradores de bases de datos imitando el mtodo usado por las herramientas de la
Coordinacin de Optimizacin 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 informacin deseada, el administrador de base
de datos debe ordenar los resultados segn la columna FECHA y enviar la informacin al
cliente. Esta prueba se realiz 10 veces para cada administrador de base de datos siguiendo el
procedimiento que se describe a continuacin:
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
5. Se ejecut la consulta al ltimo de los tres administradores de bases de datos y se
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 tamao y entregar como
resultado solamente una pequea parte de la informacin contenida en la tabla, es decir, los
datos de la tabla se leen, se procesan todos los datos pero se selecciona solamente una pequea
parte (menos del 1% de las filas en la tabla) de la informacin contenida en la tabla, se ordena
78
esta informacin y se envan los datos. Esta prueba se hace abriendo y cerrando las
conexiones a los administradores de bases de datos imitando el mtodo usado por las
herramientas de la Coordinacin de Optimizacin para consultar las bases de datos.
Prueba preliminar 4
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 informacin deseada, el administrador de base
de datos debe ordenar los resultados segn la columna FECHA y enviar la informacin al
cliente. Esta prueba se realiz 10 veces para cada administrador de base de datos siguiendo el
procedimiento que se describe a continuacin:
bases de datos.
fecha1 y 2006-03-01 a la variable fecha2
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 nmero 5 se repiti 10 veces.
79

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 desempeo de las consultas cuando siempre existe una conexin 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")='<ACTUAL>'));
80
Como se puede ver, el comando SQL contenido en la vista par_hoc es una consulta
compleja que realiza una bsqueda de datos que requiere unir tablas con vistas o tablas con
tablas y seleccionar valores especficos en cada una de estas tablas y vistas.
Luego de seleccionar la informacin deseada, el administrador de base de datos enva
la informacin al cliente. Esta prueba se realiz 5 veces para cada administrador de base de
datos siguiendo el procedimiento que se describe a continuacin:
bases de datos.
El objetivo de esta prueba es comparar la capacidad de los administradores de bases de
datos de procesar y buscar informacin especfica en varias tablas y varias vistas (que a su vez
buscan informacin en otras tablas y vistas), ordenar la informacin 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 parmetros de configuracin y pruebas finales

Luego de realizar las pruebas preliminares se hizo un anlisis previo de los resultados
obtenidos. Este anlisis se enfoc fundamentalmente en 3 aspectos de la relacin entre el

sistema operativo, el administrador de bases de datos y la aplicacin cliente. Estos aspectos
son los siguientes: La velocidad de transmisin 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 ejecucin de una consulta.
Las pruebas finales consistieron en realizar las mismas consultas preliminares y otras
ms modificando parmetros que pudieran afectar el desempeo de los administradores de
bases de datos, del sistema operativo, de la conexin de red, del programa cliente y los
controladores. Solamente los cambios que tuvieron un efecto significativo en la ejecucin de
las pruebas y en el desempeo de los administradores de bases de datos se describen a
continuacin, sin embargo, se mencionarn todos los cambios realizados y sus efectos
producidos.
6.6.1 Cambios realizados a los parmetros de configuracin

Existe una extensa cantidad de factores que pueden causar que un sistema administrador de
bases de datos tenga un bajo desempeo. Entre estos factores estn: [11]
Escaneos o bsquedas de tablas completas.
Estadsticas acerca de las bases de datos estn desactualizadas.
Operaciones de orden innecesarias.
Falta o uso inapropiado de ndices.
Tablas son unidas en un orden no ptimo.
Asignacin de bferes (cach de datos, comandos SQL, autorizaciones, etc.)
Opciones de rastreo de eventos (logging) (tamao 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.

Adems de estos factores, existen tambin los relacionados a la configuracin de la
red, al desempeo del sistema operativo, tipo de sistema de archivos usado por el sistema
operativo, configuracin detallada de los parmetros de los sistemas administradores de bases
de datos, factores relacionados a la aplicacin cliente como tcnicas de programacin y tipo de
controladores o drivers utilizados. Debido a la extensa variedad de parmetros involucrados en
el funcionamiento de un servidor de bases de datos, se nombrarn algunas de las
modificaciones realizadas. Se resalta el hecho de que no se explicar el procedimiento
realizado para modificar cada uno de los parmetros 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.
Parmetros de la conexin de red

Las modificaciones realizadas no tuvieron efectos significativos en el desempeo de
los administradores de bases de datos. La conexin de red se realiz a travs de tarjetas de red
ethernet de 10Mbps/100Mbps. Tanto bajo sistemas operativos Windows como Linux, la
velocidad de transmisin mxima (10Mbps 100Mbps) se establece por un proceso
automtico. Este proceso dependiendo de las condiciones de la red puede establecer la
conexin a 10Mbps an cuando los dos extremos de una conexin 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 transmisin a 100Mbps, sin embargo, este cambio no tuvo efecto alguno.
Otro parmetro modificado fue el MTU o unidad mxima de transferencia que permite
establecer el tamao en bytes del paquete ms grande que puede pasar por una capa de un
protocolo de comunicaciones [31]. La configuracin para el computador 3 y 4 era de
MTU=1500 (mximo nmero posible para este parmetro en una conexin 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 transmisin de datos.
83
Tambin se modificaron parmetros del protocolo TCP/IP relacionados al buffer de

transmisin y recepcin y a la frecuencia de los paquetes de reconocimiento (paquetes Ack o
acknowledge). Los valores de los buffers de recepcin y transmisin 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 conexin de la red. Bajo
el sistema operativo Linux no se observ cambio alguno, sin embargo, la velocidad de
transmisin de datos de la conexin 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 ms de un 10% y que adems se debe realizar en todos los computadores clientes,
se decidi no efectuar este cambio y dejar los valores por defecto.
Parmetros de los administradores de bases de datos
Existe una vasta cantidad de parmetros que se pueden modificar en un administrador
de bases de datos para cambiar su desempeo. Entre los muchos que se pueden encontrar en
administradores de bases de datos como PostgreSQL y MySQL, estn: memoria compartida,
memoria de trabajo, memoria de almacenamiento, cantidad de conexiones permitidas,
cantidad de procesos concurrentes permitidos, cantidad y tamao mximo de consultas que se
guardan en memoria, cantidad de memoria usada por operaciones de bsqueda, memoria
usada para almacenar ndices de las tablas, memoria usada para realizar bsquedas
secuenciales de datos y de ndices, etc.
Los parmetros que tuvieron los efectos ms significativos en las pruebas realizadas
son los siguientes: La cantidad de memoria usada para realizar operaciones de bsqueda y
cantidad de memoria usada para realizar operaciones de clasificacin. A pesar de que se puede
llegar a pensar que asignar ms memoria es mejor, la realidad es que esta asignacin de
memoria se hace a cada operacin, de clasificacin que se realizaba. Esto quiere decir que si
una consulta realiza 5 operaciones de clasificacin, 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 clasificacin. Esto puede ocasionar un deterioro del desempeo del
administrador de bases de datos. Similares efectos se observan con la cantidad de memoria
asignada a operaciones de bsqueda.
84
En PostgreSQL, los dos parmetros mencionados anteriormente son shared_buffers

y work_mem los cuales fueron fijados a 4096 y 32768 respectivamente. En MySQL, los
parmetros 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 documentacin que ofrece tanto PostgreSQL como MySQL
relacionada a la optimizacin de los administradores de bases de datos sirve como punto de
partida para fijar sus parmetros.
Adems de la gran cantidad de parmetros, es importante mencionar que la
configuracin de un administrador de bases de datos depende de los recursos disponibles para
ste. Tambin 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 mayora
comandos o consultas de bsqueda, seleccin y clasificacin de datos, a otro que deber
procesar comandos de insercin, eliminacin y actualizacin de los registros o filas de las
tablas de las bases de datos. Para configurar adecuadamente un administrador de bases de
datos tambin 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 anlisis y ejecucin de las pruebas, tambin se estudi la estructura y
definicin de las relaciones de las bases de datos y se modificaron en varios casos los ndices
de las tablas (eliminndolos por completo y reasignndolos de nuevo). Se analizaron todas las
consultas que se realizan la mayora 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 evaluacin de
la consulta que ejecutar el procesador de consultas de PostgreSQL. Mediante la informacin
obtenida por este comando, se pueden hacer modificaciones a los parmetros de PostgreSQL
para mejorar la consulta. Por ejemplo, si al ejecutar un EXPLAIN de una consulta vemos que
el plan a ejecutar tiene bsquedas de datos en tablas completas (Table scans o Sequential
scans), y la tabla posee ndices que deberan ser utilizados en la bsqueda, entonces se pueden
modificar parmetros como random_page_cost o effective_cache para que PostgreSQL
use los ndices de la tabla en lugar de realizar la bsqueda completa.
85
Se recomienda al lector ir a la referencia [11] para obtener mayores conocimientos

acerca de la optimizacin de sistemas administradores de bases de datos.
Parmetros del sistema operativo

Un parmetro fundamental en sistemas operativos Linux es la cantidad de memoria
compartida que los procesos en ejecucin 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 parmetro, generalmente se asigna un valor
equivalente al 50% de la memoria RAM del equipo. Esto no significa que los DBMS usarn
esta cantidad de memoria, solamente significa que el sistema operativo Linux permitir que
los programas que se ejecuten puedan utilizar un mximo de la memoria asignada a este
parmetro. Por defecto, SUSE Linux 10 configura el parmetro shmmax (memoria
compartida mxima) en menos de 64 MB. Se asign un valor equivalente al 100% de la
memoria RAM del equipo, ya que durante la ejecucin de las pruebas, se permiti a los
DBMS usar el 100% de la memoria del computador para observar los efectos sobre el
desempeo de los mismos.
Parmetros de programacin
El parmetro fundamental que se modific en el programa de pruebas fue el uso de
cursores. El mtodo utilizado para realizar la conexin 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 captulo 8,
sto resulta ser una ventaja cuando el resultado de un comando o consulta devuelve una gran
cantidad de datos suficientes para ocupar ms del 25% de la memoria del equipo.
86
Parmetros de los controladores

Para realizar conexiones y ejecutar consultas a PostgreSQL y MySQL desde Visual
Basic, es necesario contar con los controladores ODBC diseados para ese propsito. Estos
controladores tienen parmetros 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 parmetros de los controladores ODBC tanto de MySQL como
de PostgreSQL, aquellos que tuvieron mayor efecto en el desempeo de los administradores
de bases de datos fueron los siguientes: [29] [30]
Use Declare / Fetch (PostgreSQL): Este parmetro hace que el controlador ODBC
busque y almacene en memoria una cantidad especfica de los resultados de una
consulta. Este parmetro es necesario habilitarlo si el resultado de una consulta no
cabe por completo en la memoria del computador que hace la consulta. Si este
parmetro est deshabilitado entonces el controlador almacenar todo el resultado
obtenido de una consulta. La velocidad de transmisin tambin se ve afectada cuando
este parmetro est activado. Cuando este parmetro 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 bsqueda de otros datos) lo que hace que el controlador sea ms 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 captulo 8).
Dont Cache Result (MySQL): Similar al parmetro de PostgreSQL Use Declare /
Fetch, en MySQL es necesario activar esta opcin si se desea que el controlador no
almacene completamente los resultados en memoria. A diferencia de PostgreSQL, este
parmetro no afecta la velocidad de transmisin de datos, sin embargo, el desempeo
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 parmetro hace que MySQL use un
protocolo comprimido entre cliente y servidor. No se debe activar esta opcin ya que
adems de generar mayor carga tanto en el cliente como en el servidor, tambin
deteriora la velocidad de transmisin de tener un uso de aproximadamente 10%-11% a
tener un uso de aproximadamente 2%-3% en una conexin de 100 Mbps.
6.6.2 Pruebas finales

A continuacin 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 tamao de
la tabla (ms de 500.000 filas ocupando un espacio de disco de ms 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 despus de modificar parmetros de
configuracin y poder optimizar el desempeo 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, idntica 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:
bases de datos.
esperaron los resultados y se cerr la conexin a ese administrador de bases de datos.
89
Al igual que la mayora de las pruebas finales, esta prueba se realiz para comparar
resultados entre la configuracin por defecto de los DBMS y la configuracin 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 ms, se hace mencin al hecho de que se modificaron los parmetros de
configuracin para obtener el mejor desempeo 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 Coordinacin de Optimizacin. 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 informacin. El procedimiento que se sigue en esta prueba se muestra a
continuacin:
Consultas escogidas:
SELECT * FROM òbjects`
(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)

bases de datos.
2. Se seleccion una consulta.
esperaron los resultados y se cerr la conexin.
6. Se escogi otra consulta y se repitieron los pasos del 3 al 5.
No es un objetivo de este proyecto instruir acerca de todos los procedimientos y
parmetros que se deben modificar para lograr la optimizacin de los DBMS. La optimizacin
de un DBMS, depende de una extensa variedad de factores, solamente con la experiencia y
conocimiento es posible lograr la correcta configuracin de un sistema de bases de datos. Se
recomienda al lector que consulte las referencias bibliogrficas si quiere obtener
conocimientos slidos acerca del proceso de optimizacin y mejora del desempeo de
sistemas de bases de datos.
Durante el captulo 8, se muestran los resultados obtenidos de todas las pruebas
mencionadas anteriormente. Segn sea necesario, durante el anlisis de los resultados, se
mencionarn los efectos significativos de algunas de las modificaciones realizadas a los
parmetros de configuracin de los DBMS, bases de datos, sistemas operativos, controladores,
etc.
Tambin, al final del captulo 8, se presenta una tabla en donde se comparan las
caractersticas y limitaciones de los DBMS estudiados, y otra en donde se evala de forma
91
aproximada, los costos que implica el realizar un cambio de sistema operativo y de sistema
7. HERRAMIENTA PARA AUTOMATIZAR EL CLCULO DE LAS

ADYACENCIAS DE UNA ESTACIN BASE
La segunda parte del proyecto de grado desarrollado en este libro, se presenta en este
captulo. La Coordinacin de Optimizacin 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
aproximacin para la seleccin 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
Coordinacin de Optimizacin debe hacer uso de su lgica e intuicin para calcular las
adyacencias de una BTS.
7.1
Procedimiento para el clculo de las adyacencias

El personal de la Coordinacin de Optimizacin, 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 gua para calcular las adyacencias de un sector de una BTS.
A continuacin se presenta el conjunto de pasos que sirven de gua al personal de la
Coordinacin de Optimizacin 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
calcularn las adyacencias.
Identificar cules son las BTS o los sectores de las BTS ms cercanos.
Identificar la orientacin o azimuth de la antena del sector de la BTS al cual se le
calcularn las adyacencias.
Trazar unas lneas imaginarias que identifiquen y limiten el rea de cobertura del
sector de la BTS al cual se le calcularn las adyacencias.
Descartar como adyacencia a los sectores que no apunten hacia el sector de la BTS al
cual se le calcularn las adyacencias.
93
Las adyacencias que son seleccionadas corresponden a los sectores ms cercanos y que
apuntan ms 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 parmetros exactos para la
seleccin de las adyacencias. Una serie de preguntas surgen al analizar este procedimiento:
Cuntos sectores cercanos se deben escoger?
Existe algn lmite de distancia para considerar un sector de BTS no cercano?
Cuntos grados se debe abrir el sector de la BTS a la cual se le calcularn las
adyacencias?
Cmo es eso de que apuntan?
Hacia dnde deben apuntar, hacia el centro de la BTS o hacia alguna parte del rea de
cobertura del sector?
Cmo se puede saber si un sector afecta ms que otro que apuntan ms o menos
igual?
Adems de estas preguntas, muchas otras pueden surgir al analizar el procedimiento
que realiza el personal de la Coordinacin de Optimizacin 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 aproximacin preliminar que
permite seleccionar rpidamente las adyacencias. Esta parte es la que se realiza manualmente
y es la parte en donde la experiencia del personal de la Coordinacin de Optimizacin 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 seales recibidas en un determinado punto geogrfico. Al igual que en la primera
parte del proceso de seleccin de adyacencias, la experiencia del personal es fundamental para
analizar y establecer las rutas y puntos geogrficos 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
Coordinacin de Optimizacin. En este sentido, la herramienta desarrollada a lo largo de la
ejecucin del proyecto de grado presentado en este libro, est limitada a ser una primera
aproximacin en el proceso de seleccin 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 clculos deben ser realizados por un computador, el procedimiento para
calcular adyacencias se transform en un algoritmo con menos libertades y ms limitaciones
que el procedimiento manual.
A continuacin se presenta una breve descripcin de los pasos del algoritmo
desarrollado para el clculo de las adyacencias de una BTS o un sector de una BTS:
Identificar un nmero especfico de BTS que estn geogrficamente ms cercanas al
sector de una BTS al cual se le calcularn las adyacencias: El usuario debe escoger un
nmero mximo de BTS que sern procesadas. El programa calcula la distancia entre
cada una de las BTS de la red celular y un punto geogrfico 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 calcularn las adyacencias, sea la menor posible. La
cantidad de BTS seleccionadas depende del nmero introducido previamente por el
usuario. Aunque el programa no impone limitaciones respecto al nmero de BTS que
se procesarn, generalmente, por restricciones de hardware y software, un sector de
una BTS puede ser configurado para tener solamente un cierto nmero de adyacencias.
Calcular la orientacin o azimuth de las lneas imaginarias que limitan el rea de
cobertura del sector al cual se le calcularn las adyacencias: Por medio de ecuaciones
matemticas y el uso de la geometra, la herramienta calcula la orientacin de las
lneas que delimitan el rea de cobertura de un sector. Se debe mencionar que es
necesario realizar una aproximacin para calcular los lmites del rea de cobertura de
95
un sector. Esta aproximacin 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 transmisin se
aproxima a cero. Lo expuesto anteriormente se puede por medio de patrones de
radiacin 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 transmisin de seales 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 calcularn las adyacencias: Usando
modelos de propagacin, el programa es capaz de calcular aproximadamente la
distancia mxima a la que podr llegar la seal de un sector de una BTS con una cierta
potencia. Para hacer esto, es necesario que el usuario introduzca toda la informacin
necesaria para usar las ecuaciones del modelo de propagacin. Esta informacin
incluye potencia de transmisin, potencia de recepcin, alturas de las antenas, prdidas
en las lneas de transmisin y recepcin, frecuencia de la seal transmitida, zona y tipo
de ciudad en la que viaja la seal de radiofrecuencia, etc. Para calcular el rea de
cobertura se hace la siguiente aproximacin:
o La potencia de transmisin de todas las antenas de todas las BTS de la red
celular es igual en cualquier direccin de toda su apertura. Todas las antenas
poseen lo que se denomina como patrn de radiacin. Este patrn representa la
intensidad de los campos electromagnticos emitidos por la antena a diferentes
ngulos. En redes celulares, generalmente, se usan antenas que poseen un
patrn de radiacin 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 aproximacin supone que la antena es capaz
de transmitir la misma potencia en direccin del lbulo principal (a 0) y en
cualquier otra direccin, 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 clculo de las distancias, por lo tanto, el
clculo del rea de cobertura se reduce a encontrar el rea de un sector de
crculo. Esta aproximacin facilita los clculos geomtricos.
Calcular si existen puntos de interseccin entre las reas de cobertura de los sectores
de las BTS seleccionadas y el sector de la BTS al cual se le calcularn las adyacencias:
El programa desarrollado se basa en ecuaciones geomtricas sencillas para determinar
si hay solapamiento, interferencia o interseccin entre el rea de cobertura de dos
sectores diferentes. Usando la ecuacin de la recta, y la ecuacin de crculo, se puede
calcular los puntos de interseccin 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 clculos realizados, como por ejemplo hacer que el nmero
0 sea igual a 1-12. Si al momento de calcular los puntos de interseccin entre el rea de
cobertura de un sector de una BTS seleccionada y el rea de cobertura del sector al
cual se le calcularn las adyacencias ocurre que no existen dichos puntos, entonces el
programa toma la decisin de descartar el sector de la BTS como posible adyacencia.
Verificar que el lbulo principal de los sectores de las BTS seleccionados est en
direccin al centro de la BTS a la cual se le calcularn las adyacencias: De todos los
sectores procesados, se seleccionan aquellos que tienen puntos en comn con el sector
al cual se le calcularn las adyacencias y de stos, se seleccionan los que tengan su
lbulo principal en direccin al centro del sector de la BTS al cual se le calcularn 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 calcularn las
adyacencias est ubicado en las coordenadas x=0 y=0 y su orientacin 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 interseccin 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 opcin 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
sera 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 grfica de la herramienta

La herramienta para el clculo automtico de las adyacencias se desarroll usando
Visual Basic 6 como lenguaje de programacin. Se escogi este lenguaje principalmente

porque todas las herramientas de la Coordinacin de Optimizacin han sido desarrolladas con
Visual Basic 6 pero adems, este lenguaje de programacin ofrece una gran facilidad y
rapidez para desarrollar aplicaciones bajo sistemas operativos Windows.
Como se mencion anteriormente en este captulo, debido a la gran cantidad de
variables involucradas en el proceso de calcular adyacencias, es necesario la intervencin de
la lgica y de la experiencia humana, por lo tanto, la interfaz grfica de la herramienta
presenta al usuario un conjunto de parmetros que se deben introducir antes de realizar los
clculos.
Al ejecutar el programa para el clculo de adyacencias, se mostrar una pantalla
solamente con un men. Esto se hace debido a que la herramienta consta de dos mdulos
principales, el mdulo para el clculo de adyacencias y el mdulo para la administracin 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 grfica en donde se hacen los clculos de las
adyacencias, es decir, muestra la interfaz grfica del mdulo de clculo de adyacencias. En la
segunda opcin, View BTS Information, muestra la pantalla en donde se administran las
BTS, es decir, muestra la interfaz grfica del mdulo de administracin de BTS, y la tercera
opcin, Exit, hace que el programa finalise.
98
En la figura 19 se puede apreciar la interfaz grfica del mdulo para el clculo de

adyacencias.
Figura 19. Interfaz grfica de la herramienta desarrollada para el clculo de adyacencias.
Como se puede ver, la interfaz grfica del mdulo para el clculo de adyacencias est
formada por una gran cantidad de componentes. La funcin de cada uno de ellos se explica a
continuacin:
Seccin New BTS Sector Name

En esta seccin, existe un cuadro de texto (New BTS Name) en donde se debe
introducir el nombre y nmero del sector de una nueva BTS. El formato de este cuadro de
texto puede ser cualquiera, siempre que el ltimo carcter del nombre sea el nmero del
sector. A la derecha de esta seccin, se puede ubicar un cuadro de seleccin New BTS y una
99
lista desplegable BTS. El cuadro desplegable permite seleccionar si la BTS a la cual se le

calcularn las adyacencias es nuevo o ya existe. Si el cuadro de seleccin 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 informacin necesaria del
sector de la BTS escogido y llenar todos los campos automticamente. En caso de marcar la
opcin New BTS, entonces el programa deshabilita la lista desplegable obligando al usuario
a introducir todos los datos necesarios para el clculo de adyacencias.
Seccin New BTS Geographic Coordinates

En esta seccin, hay un conjunto de casillas permiten al usuario introducir las
coordenadas geogrficas del sector de la BTS al cual se le calcularn las adyacencias. La lista
desplegable ubicada a la derecha de esta seccin permite al usuario introducir las coordenadas
geogrficas en dos formatos distintos; Decimal Degrees y Deg Min' Sec''. El formato
Decimal Degrees permite al usuario introducir las coordenadas como un nmero 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 nmeros deben llevar signo, por ejemplo, si la latitud es norte (N) o la longitud
es este (E), el nmero 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 nmeros 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 geogrficas 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 automticamente (para
que no se produzcan errores) las casillas correspondientes al formato seleccionado en la lista
desplegable Latitude - Longitude format.
100
Seccin New BTS Sector Parameters

En esta seccin el usuario debe llenar todas las casillas relacionadas a los parmetros
de diseo de una BTS.
La casilla Coverage Radius (km) no debe ser llenada ya que esta cumple la funcin
de notificar cul es la distancia mxima terica y aproximada que viajar la seal transmitida
antes de que su potencia alcance el valor indicado en la casilla Rx Power (dB/dBm) en la
seccin Receiver Model Parameters.
Entre los parmetros que el usuario debe suministrar en esta seccin 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
transmisin (Tx Power (Watts)), el canal GSM de transmisin usado (Tx Channel
Number), las prdidas en las lneas de transmisin (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 parmetros, entre otros, son necesarios para poder utilizar el modelo
de propagacin de Okumura-Hata.
La lista desplegable Type of City permite seleccionar tres modelos de ciudad
diferentes segn se establece en el modelo de propagacin de Okumura-Hata. Los tres
modelos son: Modelo de ciudad grande con frecuencia de transmisin mayor a 300 MHz
(Large, with f > 300MHz), ciudad grande con frecuencia de transmisin menor a 300 MHz
(Large, with f < 300MHz) y modelos de ciudades pequeas o medianas (Small and
Medium). La lista desplegable que permite seleccionar el tipo de rea en el modelo de
propagacin de Okumura-Hata presenta tambin tres opciones: rea urbana (Urban), rea
sub-urbana (Sub-Urban) y rea abierta o rural (Open).
Seccin Receiver Model Parameters

El modelo de propagacin de Okumura-Hata usa los valores de estas casillas para
calcular la distancia terica que viajar la seal 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 prdidas en las lneas de transmisin (Rx Feeder Loss (dB / dBm)). Existe una
cuadro de seleccin, Receiver is a MS, que hace que el programa llene las casillas
automticamente considerando que el punto de recepcin es una estacin mvil.
Seccin Adjacencies Options

Ya en esta seccin el usuario debe tomar las decisiones finales antes de calcular las
adyacencias.
La casilla Number of Geographic Adjacencies permite al usuario seleccionar un
nmero especfico de BTS que estn geogrficamente ms cerca de la nueva BTS.
La opcin Auto hace que el programa calcule automticamente en nmero 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 calcularn las adyacencias. Dos formas o mtodos de clculo se implementaron en el
programa. La primera forma corresponde a un clculo basado exclusivamente en la distancia
geogrfica 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 mtodo para calcular las adyacencias se escoge con la opcin Nearest Overlapping &
HandOver sectors de la lista desplegable Adjacency Calculation Mode. Este mtodo es el
que se debe usar para obtener una primera aproximacin en el clculo 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 interseccin entre las reas de cobertura.
Los resultados obtenidos luego de realizar los clculos son mostrados por el programa
en dos tablas distintas. En la tabla Nearest Overlapping sectors se muestran los sectores de
las BTS geogrficamente ms 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 adems de tener zonas de
solapamiento con la nueva BTS, el azimuth de su antena est dirigido hacia las coordenadas
geogrficas de la nueva BTS.
La casilla Angle Tolerance (deg) permite introducir una variacin en la direccin
del azimuth de las antenas y en los ngulos de las lneas que limitan el rea de cobertura, por
ejemplo, si para una BTS cualquiera, llamada BTS2, la direccin 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 tambin con el ngulo de las lneas 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 clculos. La casilla for New BTS se usa para aadir 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 aadir o aumentar el valor de la apertura de la antena de todas las
BTS consideradas en el clculo de adyacencias. Esta casilla tambin permite flexibilizar los
lmites tericos y clculos 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 funcin de la casilla es simple: Si
existen BTS cuya distancia, en kilmetros, con la nueva BTS es menor o igual al valor de la
casilla, entonces el programa, automticamente, considerar esas BTS como adyacencias, sin
necesidad de calcular puntos de interseccin o reas de solapamiento.
Una vez que se hayan seleccionado e introducido todos los parmetros necesarios, se
puede pulsar el botn Calculate Adjacencies para hacer que el programa inicie el proceso
de clculo de adyacencias.
103
Opciones de Datafill
El programa tambin es capaz de generar un reporte denominado Datafill. La
Coordinacin de Optimizacin genera estos reportes manualmente luego de realizar la primera
aproximacin en el proceso de seleccionar las adyacencias de un sector de una BTS. Este
reporte incluye informacin acerca de la BTS as como tambin las adyacencias de la misma.
A travs del botn Generate Datafill, el programa es capaz de generar un Datafill y las
adyacencias que se incluirn en el reporte se tomarn de cualquiera de las dos tablas del
programa. La lista desplegable ubicada debajo del botn Generate Datafill permite al
usuario seleccionar cualquiera de estas dos tablas. Si se escoge la opcin Overlapping Only
la tabla que ser usada como fuente de informacin para incluir las adyacencias en el reporte
ser Nearest Overlapping sectors y si se escoge la opcin 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 cdigo de identificacin de una BTS (BSIC; Base Transceiver Station Identity
Code). Los valores de estos dos parmetros permiten modificar el reuso de frecuencias en la
red celular. Para escoger estos dos parmetros y asignrselos 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 combinacin NCC-BCC menos usada o la combinacin que est
usada una menor cantidad de veces y que adems 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 seleccin de este par de parmetros se deja a discrecin y
experiencia del usuario, sin embargo, el programa facilita la tarea de seleccin al presentar
tres tablas luego de que se han calculado las adyacencias. En la figura 20 se muestra la
interfaz grfica 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 transmisin 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 transmisin.
Haciendo referencia a la figura 20, existen 4 sectores con la combinacin 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 transmisin. Adems, se
puede ver la distancia de cada una de stas BTS a la nueva BTS y su combinacin NCC-BCC.
Una caracterstica 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 automtico que muestra todas las
combinaciones posibles de NCC-BCC, reduce considerablemente el tiempo utilizado para
escoger dicha combinacin 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
(ms de 500 BTS y ms de 1000 sectores) para escoger la combinacin NCC-BCC deseada.
Como se mencion anteriormente, la herramienta consta de dos mdulos. La interfaz

grfica del segundo mdulo, para la administracin de BTS, se muestra en la figura 21.
Figura 21. Interfaz para la administracin de BTS de la herramienta desarrollada.
106
La interfaz se desarroll para ofrecer la mayor facilidad de uso y por esto slo consta
de cuatro botones y una lista desplegable. La funcin de estos componentes se describe a
continuacin:
Botn Reload BTS List: Al presionar este botn, 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 aadida con el botn . Adems, permite verificar
que la nueva BTS haya sido creada o eliminada con xito.
Botn View BTS Info: La funcin de este botn es mostrar la informacin de todos
los sectores de una BTS seleccionada de la lista desplegable.
Botn Add New BTS: Permite agregar un nuevo sector o una nueva BTS a la base
de datos que contiene la informacin de las BTS. Luego pulsar este botn, el programa
llenar automticamente algunos campos que coincidan con la informacin
suministrada en la interfaz grfica del mdulo para el clculo de adyacencias como por
ejemplo, las coordenadas geogrficas de la nueva BTS, el nombre de la nueva BTS, la
orientacin, ganancia y altura de la antena, etc. Si no se ha introducido ninguna
informacin, 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 informacin de las dos BTS con el mismo nombre. Queda como decisin
del usuario cambiar el nombre de alguna de las dos BTS.
Botn Delete BTS: Luego mostrar por pantalla la informacin 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 botn Delete
BTS. Esta es una operacin que no se puede deshacer y borrar de la base de datos
toda la informacin correspondiente al sector seleccionado.
Lista desplegable BTS: Esta lista contiene todos los sectores de todas las BTS que
estn registradas en la base de datos. Al seleccionar cualquiera de estos sectores, el
107
programa automticamente muestra toda la informacin 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 informacin 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 funcin de servir como
primera aproximacin en el proceso de seleccin 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 Coordinacin de Optimizacin, se realizaron pruebas con el objetivo de
comparar las adyacencias calculadas por la herramienta con las adyacencias seleccionadas por
el personal de la Coordinacin de Optimizacin luego de realizar las pruebas de campo.
Antes de observar y analizar resultados, se puede conocer una caracterstica comn en
todos los resultados y es el hecho de que el 100% de las adyacencias calculadas por la
herramienta no sern las mismas que las calculadas luego de realizar pruebas de campo. Esto
se debe a que los clculos realizados por la herramienta, estn basados en modelos tericos 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 Coordinacin de Optimizacin, estn entre las adyacencias
calculadas por la herramienta. Se seleccionaron 5 sectores cuyas adyacencias hayan han sido
seleccionadas por el personal de la Coordinacin de Optimizacin a travs 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 captulo 8.
8. RESULTADOS Y ANLISIS
A lo largo de este captulo 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 anlisis de los mismos tambin se divide en dos partes. En la primera parte,
que corresponde a la seccin 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, seccin 8.2, muestra los resultados de las pruebas realizadas con la
herramienta para el clculo automtico de adyacencias.
Antes de presentar los resultados, se deben hacer ciertas observaciones respecto al
origen de los mismos. Las grficas presentadas fueron obtenidas a travs del administrador de
tareas de Windows, el cual muestra grficas acerca de la actividad de CPU, red y memoria, en
tiempo real y sin escala horizontal o vertical. Las grficas poseen una cuadrcula en el fondo y
sobre sta se trazan las curvas.
A pesar de que no existe una escala vertical con una buena resolucin, el administrador
de tareas de Windows posee una escala que va desde 0% hasta 100% para la grfica del uso
del procesador o CPU del equipo. Tambin, el administrador de tareas puede generar las
grficas correspondientes a la actividad de red con una escala automtica, en donde slo se
pueden ver tres valores (valor mximo, valor mnimo 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 caractersticas de las grficas obtenidas a travs 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
grficas, debido a la comparacin relativa que se hace entre ellas, a continuacin se presenta
una aproximacin para ubicar los valores en las grficas: El eje vertical se encuentra dividido
en 17 recuadros, el punto ms bajo de la escala equivale a 0% y el punto ms alto de la escala
equivale a 100%, por lo tanto, cada recuadro recorrido verticalmente equivale
aproximadamente a 5,882%, en otras palabra, cada lnea divisoria horizontal de la grfica
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 grficas
se obtuvieron seleccionando la velocidad de actualizacin alta, y se encontr, a travs de
pruebas empricas, que el tiempo de actualizacin es de aproximadamente 0,5 segundos y el
tiempo que transcurre entre la visualizacin de una lnea vertical y la siguiente es de
aproximadamente 3 segundos, es decir, cada lnea divisoria vertical equivale a 3 segundos
aproximadamente. El la figura 22 se muestra la interfaz grfica 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 grficas fue modificado para
permitir una mejor impresin en papel. Como se dijo antes, todas las figuras muestran
solamente una parte de toda la interfaz grfica del administrador de tareas de Windows. Por
ejemplo, una grfica puede tener solamente parte del Historial de uso del CPU y adems el
recuadro de Memoria fsica (KB) que se muestran en la figura 22.
110
8.1
Estudio comparativo entre tres administradores de bases de datos

En esta seccin 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 acompaada
con un breve anlisis y discusin. A lo largo de este captulo se har referencia a frases como
tabla de gran tamao, resultados de gran tamao o gran nmero de filas. Para evitar
explicar cual es el significado de cada una de estas frases cada vez que se utilizan, a
continuacin se presenta una descripcin: La frase tablas de gran tamao hace referencia a
todas aquellas tabla cuyo espacio en disco sea de ms del 25% de la memoria fsica total del
computador, es decir, para un computador con 768 MB de RAM una tabla de gran tamao
es una tabla cuyo espacio ocupado en el disco es de ms de 192 MB. La frase resultados de
gran tamao est relacionada con la frase tablas de gran tamao y corresponde al conjunto
de resultados de una consulta que ocupan ms del 25% de la memoria fsica total del
computador que pide los resultados. La frase gran cantidad de filas no tiene significado por
s sola y siempre estar acompaada de la frase tabla de gran tamao 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 pequea 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.
111

4. Se cerr el programa de pruebas
La tabla 2 muestra los tiempos de ejecucin, en segundos, de cada consulta para cada
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 conexin de la red es de 100 Mbps, es decir, 100% equivale a 100 Mbps.
Como se mencion anteriormente, la grfica se obtuvo del Administrador de Tareas de
Windows o Windows Task Manager en la pestaa 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.
MySQL / Linux.
PostgreSQL / Linux.
113
No se muestran las grficas del computador cliente, con MySQL/Windows o

PostgreSQL/Windows ya que las valores para las grficas obtenidas, varan menos de un 5%
en comparacin con las grficas mostradas. En el caso de MySQL/Windows, la actividad
permanece igual. Para PostgreSQL, la actividad de red vara entre 12% y 14%, y para
Windows/Linux, la actividad vara entre 76% y 81%. Por esta misma razn, las grficas 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 duracin que la actividad de red que PostgreSQL,
cmo es posible que la ejecucin de la consulta haya tomado ms 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 estadsticas de memoria, del computador cliente, durante la
ejecucin 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%. Tambin se puede observar el crecimiento en el archivo de pgina (Page
file) y la baja cantidad de memoria fsica disponible (a menos de un 15% del total). La misma
situacin ocurre con Microsoft Access y PostgreSQL, pero con la diferencia que el archivo de
pgina deja crecer cuando la actividad de CPU cae a menos del 10% (Esto ocurre cuando la
transmisin de los datos ha finalizado, es decir, actividad de red 0%). Sin embargo, con
MySQL, la actividad de CPU aumenta a ms del 25% cuando la transmisin 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 situacin se cambi al habilitar la opcin Dont Cache Result
(forward only cursors) del controlador ODBC de MySQL. Lo que hace esta opcin 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, tambin almacena en memoria los resultados recibidos.
Otro aspecto que se debe mencionar, es que sin importar si la opcin Dont Cache
Result (forward only cursors) esta habilitada o deshabilitada, MySQL usa el 100% del CPU
mientras ejecuta la transmisin de datos. Esto trae como consecuencia que el servidor no
responda o responda muy lentamente, durante el perodo que dure la transmisin de datos. Por
ejemplo si se quiere cambiar de ventana o tratar de abrir el bloc de notas de Windows, esta
operacin podra tardar ms de 1 minuto (si la transmisin de datos se realiza en ms de un
minuto), cuando normalmente puede tardar a lo sumo 5 segundos.
Una situacin similar se presenta con el controlador ODBC de PostgreSQL. Cuando la
opcin Use Declare/Fetch no est habilitada, el controlador trata de almacenar todo el
resultado en memoria. Cuando esta opcin est habilitada, la velocidad de transmisin se
reduce en 5% aproximadamente, situacin que no ocurre con el controlador ODBC de
MySQL. Lo que es importante mencionar es que debido al tamao 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 lnea: Out of memory while reading tuples y
seguidamente se cancel la operacin. Por lo tanto, para poder ejecutar la prueba preliminar 1
con PostgreSQL, se tuvo que habilitar la opcin 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 transmisin de Microsoft Access.
Prueba preliminar 2
FECHA.
Procedimiento:
4. Se cerr el programa de pruebas.
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
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 variacin de menos del 3% durante la ejecucin de esta
prueba.
118
Dado que esta tarea involucra procesamiento por parte del servidor (debido a la
clusula ORDER BY), en las figuras 30 y 31 se muestran las grficas 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. Grficas del uso de CPU, del computador cliente, al ejecutar la prueba preliminar 2
con Microsoft Access / Windows. (a) Recepcin de los datos transmitidos por red; (b)
Procesamiento de los datos; (c) Procesamiento antes de mostrar los datos por pantalla.
119
Figura 30. Grfica del uso de CPU, del computador servidor, al ejecutar la prueba preliminar 2
con MySQL / Windows.
Figura 31. Grfica 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
ejecucin 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
transmisin de datos. Una vez que finaliza la transmisin, la actividad de CPU cae a menos de
5% y la memoria fsica disponible se reduce a un nmero similar al que se muestra en la
figura 26 de la prueba preliminar 1 (con una variacin de 15%).
En la figura 29.a, se puede ver el uso del CPU del computador cliente durante la
recepcin de datos. El tiempo que transcurre al realizar la transmisin de datos es similar a los
tiempos de la prueba preliminar 1 con Microsoft Access / Windows (una variacin de no ms
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 espordicos 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, segn la aproximacin
presentada al principio de este captulo se puede decir que el perodo de tiempo que Microsoft
Access usa para procesar los datos de la tabla es de ms de 300 segundos (haciendo la
aproximacin de que cada lnea 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 recepcin de datos,
es decir, el uso del CPU en el cliente, permaneci por debajo de 5% hasta que se inici la
recepcin 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 transicin entre la finalizacin del procesamiento de los datos, el inicio de la
transmisin de los mismos y el final de la transmisin. El procesamiento de datos corresponde
a la parte de la grfica que va desde el inicio (parte izquierda de la grfica) hasta que la
actividad de CPU sube a 100%. El tiempo de procesamiento es de aproximadamente 200
segundos. La transmisin de datos se puede observar al final de la grfica cuando la actividad
de CPU sube a 100%. Como se mencion anteriormente, mientras MySQL realiza la
transmisin de datos, el computador servidor no responde a ninguna otra accin o proceso que
se est ejecutando en l. Esto queda evidenciado en el hecho de que la grfica de la figura 30
muestra que luego de haber transcurrido entre 3 y 6 segundos, la transmisin 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 razn de este aparente corto perodo de transmisin de
datos, es que MySQL toma posesin 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 recepcin de datos y luego se puede ver una grfica como la
mostrada en la figura 24 de la prueba preliminar 1.
PostgreSQL muestra en la figura 31 una situacin similar a la de MySQL, es decir, hay
una actividad de CPU que identifica el procesamiento de datos y otra que identifica la
transmisin de datos. El perodo de procesamiento se puede identificar en la grfica de la
121
figura 31 por los puntos en donde la actividad de CPU sube a 100%. Este perodo 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 transmisin de datos. Se
puede ver que el perodo de procesamiento de PostgreSQL es mucho menor al de MySQL
(aproximadamente 55% menor) y al de Microsoft Access (al menos 70% menor). An as, los
tiempos obtenidos, por ejemplo, con PostgreSQL / Windows no difieren a los obtenidos con
MySQL / Windows en ms de un 15%. Esto se debe a que el tiempo de transmisin 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 transmisin 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
BY FECHA.
Procedimiento:
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.
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
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 grficas de uso de CPU y de

red tanto del cliente como del servidor. En la figuras 32, 33 y 34 se muestran las grficas 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. Continuacin.
(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 grficas de las figuras 32, 33 y 34,
especialmente en las grficas 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 ms de 500.000 registros o filas (alrededor de 350 filas son seleccionadas).
Las grficas 32.b, 33.b y 34.b muestran la actividad de red en el servidor, y las grficas
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 grficas
32.a, 33.a y 34.a muestran el uso del CPU en el servidor, y las grficas 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 ms diferencia a las grficas

de las figuras 32, 33 y 34, an cuando tambin existe una notable desigualdad en la forma de
las grficas que indican el uso del CPU. Se puede ver claramente que los tiempos de ejecucin
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 transmisin de los datos, es
mayor. Se observ que esta marcada diferencia, en el tiempo de envo 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 nmero de bytes enviados a travs de una
conexin de red).
Las diferencias entre MySQL y PostgreSQL se podran 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 parmetros de configuracin 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
BY FECHA.
Procedimiento:
fecha1 y 2006-03-01 a la variable fecha2
8. Se cerr el programa.
126
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
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
A pesar de que se puede pensar que la prueba es idntica 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
grficas 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 continuacin 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 (grfica a de la figura 35) como el uso de la red
(grfica b de la figura 35), para Microsoft Access, han disminuido notablemente (100% para
el uso de la red) comparados con los resultados y grficas de la prueba preliminar 3. Sin
embargo, llama la atencin 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 podra llegar a la conclusin de que el comportamiento
obedece al valor de la variable nombresectorBTS, es decir, si sta tiene el valor de
23ENERO1, la consulta toma mucho ms tiempo en ejecutarse.
Durante esta prueba se pudo observar que cuando se ejecuta una consulta sobre una
tabla de Microsoft Access, ste enva 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 grficas
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
obligacin 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 informacin 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 ms de 500.000 registros, ocupando ms
128
de 200 MB de espacio en disco, la memoria fsica disponible del computador cliente se puede
reducir a menos del 15%, haciendo que el desempeo del computador cliente se reduzca
notablemente. Por ejemplo, el tiempo para abrir el programa Adobe Acrobat Reader 6, puede
aumentar ms de 10 veces. Esto ocurre porque el sistema operativo, para permitir a otro
programa hacer uso de la memoria fsica, debe vaciar parte de sta y asignrsela al programa
que quiere ejecutarse, lo que hace que la tarea se ejecute en ms 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 informacin 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 travs de la red. La caracterstica que se debe resaltar en esta prueba, es que la
cantidad de datos que se piden de la tabla consultada, no llega a ser ms 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 tambin se carga con la informacin de la tabla, es
decir, el computador servidor, al igual que el computador cliente, almacenan los datos de la
tabla en la memoria. Adems, el archivo bases de datos de Microsoft Access (archivos con
extensin MDB) en donde est ubicada la tabla, queda bloqueado con un atributo de slo
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 ejecucin 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 informacin y
luego se libera. Adems, la cantidad de memoria que usan para procesar la informacin 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
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
Windows
Linux
(segundos)
(segundos)
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600

Los resultados de la tabla 6 son impresionantes. La consulta realizada, como se
mencion en el captulo 6, pone a prueba la capacidad de procesar mltiples tablas
simultneamente, y de ejecutar varios procesos anidados. Con resultados como los mostrados
en la tabla 6 se pudiera llegar a la conclusin 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 parmetros 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 desempeo, caractersticas 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 optimizacin.
Para resumir esta seccin, se puede decir lo siguiente:
Microsoft Access ofrece menores tiempos de ejecucin que MySQL o PostgreSQL,
cuando se trata de buscar y enviar informacin de una tabla de gran tamao.
PostgreSQL posee mayor velocidad de procesamiento que Microsoft Access o
MySQL, cuando se trata de ordenar los datos de una tabla de gran tamao y con un
gran nmero de registros.
MySQL busca con mayor rapidez que Microsoft Access o PostgreSQL, cuando se
quiere seleccionar una pequea parte de una tabla que posee un gran tamao.
Microsoft Access es mucho ms rpido que MySQL o PostgreSQL, cuando existe la
necesidad de procesar varias tablas simultneamente.
Hay que recordar que estas pruebas fueron realizadas desde el computador 3. Los
resultados de algunas de estas pruebas pueden variar en ms 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 ms.
Otro factor que afecta los resultados y que a pesar de ser obvio hay que mencionarlo, es
la cantidad de procesos que se estn ejecutando tanto en el cliente como en el servidor.
Programas de antivirus, de procesamiento grfico, de navegacin en Internet, an cuando no
estn ejecutando alguna tarea, estn haciendo uso de la memoria del computador. Aunque no
se muestran tablas o grficas, se realizaron algunas de las pruebas con varios de estos
131
programas en ejecucin, y efectivamente los tiempos de ejecucin en algunos casos

aumentaron en ms del 100%.
8.1.2 Resultados de las pruebas finales

Antes y durante la ejecucin de estas pruebas, se realizaron modificaciones a varios
componentes involucrados en el desempeo de los sistemas administradores de bases de datos
(principalmente la configuracin 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
bsqueda, 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 captulo 6, no se presentarn los procedimientos seguidos
para realizar las modificaciones, ni los valores de los parmetros modificados ya que muchas
de las modificaciones realizadas dependen de las caractersticas, capacidades y limitaciones
del equipo y del sistema operativo en donde estn instalados los administradores de bases de
datos. A travs 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 desempeo de los DBMS MySQL y PostgreSQL. Cuando sea
necesario, sin embargo, se mencionar el efecto de las modificaciones realizadas cuyo efecto
fue el ms significativo en los resultados.
132
Prueba final 1
Procedimiento:
1. Se configur el programa de pruebas para que las conexiones y los resultados tuvieran
cursores ADO manejados por el servidor.
Los tiempos de ejecucin 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 slo 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 variacin mayor al 10%) a los mostrados en la tabla 7 para MySQL / Linux y
PostgreSQL / Linux, respectivamente.
En comparacin con los resultados de la tabla 2 de la prueba preliminar 1, la tabla 7
muestra tiempos de ejecucin considerablemente menores (aproximadamente 65% menores
para MySQL y 25% menores para PostgreSQL). Esto se debe, como se dijo al inicio de la
133
seccin 8.1.2, a modificaciones hechas a la configuracin de los administradores de bases de

datos, entre las cuales estn el aumento de la memoria compartida usada por los DBMS,
eliminacin de escritura automtica de los datos en memoria al disco, aumento de la memoria
compartida de los sistemas operativos, modificacin de los parmetros de los controladores
ODBC (Use Declare / Fetch y Dont Cache Result, por ejemplo), modificacin de la
configuracin 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 segn [29], es un motor de bsqueda no
transaccional que ofrece alta velocidad de almacenamiento y recuperacin de datos. Tambin
se aument la cantidad de memoria destinada a realizar operaciones de bsqueda 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 parmetro que indica relativamente el tiempo de
bsqueda 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
disminucin del tiempo de ejecucin de la prueba, sin embargo, el objetivo principal de esta
prueba fue el de observar el efecto de los cursores ADO en el desempeo 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 configuracin sobre Microsoft Access es que adems de cargar la
memoria fsica disponible en el computador cliente, la memoria fsica en el computador
servidor tambin se llena con los datos de la tabla.
En MySQL, la configuracin 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 opcin Use Declare/Fetch est habilitada ya que sta permite que el
controlador ODBC de PostgreSQL almacene en memoria solamente una cantidad especfica
de informacin, 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 travs de la red.
El efecto de usar cursores en el servidor tambin trae otras consecuencias para
PostgreSQL. Debido a que es el controlador ODBC quien enva los comandos SQL para abrir,
mover y cerrar los cursores que mantiene el servidor, se genera un exceso de informacin que
debe ser transmitida a travs de la red (el controlador ODBC enva comandos para mover los
cursores, por ejemplo, y el servidor los responde entregando los datos de la fila del cursor e
informacin 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. Adems, si el servidor es consultado por varios
clientes al mismo tiempo, entonces los recursos disponibles se reducirn muy rpidamente
haciendo que el desempeo general del servidor sea bajo.
Prueba final 2
Procedimiento:
1. Se configur el programa de pruebas para que las conexiones y los resultados tuvieran
cursores ADO manejados por el cliente.
135
Al igual que la prueba final 1, con la ejecucin de esta prueba se quiso observar el
efecto de los cursores ADO en el desempeo de los sistemas administradores de bases de
datos. Los resultados obtenidos en esta prueba no tuvieron una variacin de ms 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 operacin de transmisin de datos a travs 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 situacin 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
`FECHA`.
Procedimiento:
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 ms 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 parmetros de configuracin 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 ejecucin se redujeron en ms del 50%. Esta reduccin 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 ms del 5%) ni en
PostgreSQL (diferencias de no ms del 10%).
Prueba final 4
BY FECHA.
Procedimiento:
nombresectorBTS) y se repiti el paso anterior.
137

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 conexin abierta
con una tabla de Microsoft Access que tenga un gran tamao (que ocupe ms del 25% de la
memoria total), puede deteriorar el desempeo 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 Coordinacin de Optimizacin de
Digitel GSM usa el mtodo 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
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

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 desempeo y mayor velocidad, sin embargo, como tambin 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 tambin 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 ms de 25% con MySQL / Windows.
Con PostgreSQL / Linux, la diferencia fue de ms del 60% y con PostgreSQL / Windows la
diferencia fue de aproximadamente 45%.
Durante la ejecucin 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 ejecucin 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 ejecucin 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
buscarn 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, segn [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 tamao 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 envo del comando SQL y la recepcin 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

desempeo 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 informacin de las bases de
datos, ya que la mayora de la memoria asignada a MySQL por el sistema operativo, est
destinada para almacenar comandos y resultados, por lo tanto, el desempeo 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 genticos (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 ejecucin mucho menores. Adems, el controlador posee
una cach de datos que se modifica con la opcin Cache size. Con estas dos caractersticas
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
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
Linux
Windows
(segundos)
(segundos)
0,857
0,864
0,895
0,864
0,89
0,733
0,703
0,813
0,704
0,812
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%.
Tambin se puede observar una diferencia, en algunos casos, de ms del 50% entre los
resultados obtenidos con MySQL bajo Windows y los resultados obtenidos con MySQL /
Linux. Otra observacin 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 ms 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
parmetros de los optimizadores de consultas para que hicieran bsquedas de datos a travs de
los ndices (Index scan), en lugar de hacer bsquedas secuenciales de los datos de las tablas
(Table scan o sequential scan).
Prueba final 6
Se ejecutaron las siguientes consultas:
SELECT * FROM òbjects`
(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:
2. Se seleccion una consulta.
6. Se escogi otra consulta y se repitieron los pasos del 3 al 5.
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 ejecucin obtenidos al ejecutar cada consulta.
142
Consulta realizada
Microsoft
PostgreSQL /
MySQL / Linux
Access / Linux
Linux
(segundos)
(segundos)
(segundos)
1 SELECT * FROM òbjects`

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 òbjects`
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 atencin 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 òbjects`. Orden de ejecucin: PostgreSQL, MySQL y
Microsoft Access. (b) SELECT * FROM `poc_id` Orden de ejecucin: Microsoft Access,
MySQL (identificada por los dos picos unidos) y PostgreSQL (ltimo pico). (c) SELECT *
FROM `par_trx`. Orden de ejecucin: PostgreSQL, Microsoft Access y MySQL. (d) SELECT
* FROM `trx_bcch`. Orden de ejecucin: MySQL, PostgreSQL y Microsoft Access. (Slo se
muestra la actividad de la red con Microsoft Access, ya que con MySQL y PostgreSQL, sta
fue menor al 2%, segn se observ, en tiempo real, en el administrador de tareas).
Haciendo referencia a las grficas de la figura 25 de la prueba preliminar 1, la
velocidad de transmisin promedio de PostgreSQL es de aproximadamente 17%, esto se
puede ver tambin 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 grficas 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 ejecucin de esta prueba final 6, se pudo observar que no se present la
situacin en donde Microsoft Access carga la memoria del computador cliente, debido a que
las tablas consultadas son pequeas (poseen un tamao menor al 5% de la memoria fsica del
computador cliente), lo que se evidencia con la corta duracin de la transmisin de datos
respecto a las grficas 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 desempeo de Microsoft
Access se ve afectado negativamente ya que ste siempre enva 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 (ms de 30.000), solamente selecciona 2 de las 35 columnas que sta posee. Cabe
destacar que estas dos columnas seleccionadas almacenan datos numricos y que el resto de
las columnas almacenan otros tipos de datos como cadenas de texto y marcas de tiempo o
timestamps. Los datos numricos de mayor tamao manejados por los DBMS bajo estudio,
poseen 8 bytes (datos del tipo float 8 o doble precisin (double precision)), en cambio, cada
carcter en una cadena de texto ocupa un tamao 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 direccin geogrfica 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
Coordinacin de Optimizacin realiza las siguientes consultas:
1. SELECT * FROM parameters.par_adj_cell WHERE
"bts_id_NAME"='nombresectorBTS' AND "OBJECT_INSTANCE"='nmero'
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 nmero). 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
Coordinacin de Optimizacin. Esta vista, llamada par_bts, selecciona ms de 255
columnas de una tabla. Con Microsoft Access esto no es posible, ya que existen limitaciones
en cuanto al nmero mximo de columnas que puede tener una tabla o una fila de resultados.
El personal de la Coordinacin de Optimizacin tuvo que recurrir a la separacin de estas
columnas en tres vistas separadas, y luego unirlas de nuevo para ser mostradas por pantalla.
MySQL y PostgreSQL pueden almacenar tablas con ms de 255 columnas, lo que representa
claramente una mejora u optimizacin al momento de procesar y mostrar los datos de la tabla.
Tambin 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 travs de un controlador
ODBC. Esto quiere decir, que el procesamiento de datos no es realizado por Access,
solamente el envo de la informacin.
De todas las pruebas realizadas anteriormente y del anlisis presentado, se pueden
hacer las siguientes observaciones finales:
Microsoft Access realiza la transmisin de datos a travs 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 ms del 50% de las pruebas
realizadas).
Las consultas que involucran procesamiento de tablas grandes y seleccin 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 informacin
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
conexin 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 parmetros de configuracin, 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 envan los resultados de la consulta.
En las pruebas en donde se requiere procesamiento simultneo de varias tablas, y
seleccin de una pequea parte de todas las tablas y filas procesadas, PostgreSQL
ofrece menores tiempos de consulta que Microsoft Access y MySQL.
147
En el captulo 9 se mencionan las conclusiones del estudio comparativo realizado y

desarrollado a lo largo de este libro.
8.2
Herramienta para el clculo de adyacencias

Para probar el funcionamiento correcto de la herramienta desarrollada para el clculo
automtico de las adyacencias, fue suficiente comparar las adyacencias calculadas por la
herramienta con las adyacencias seleccionadas por el personal de la Coordinacin de
Optimizacin luego de realizar las pruebas de campo necesarias. En la seccin 8.2.1 se
muestran tablas en donde aparecen las adyacencias seleccionadas por el personal de la
Coordinacin de Optimizacin (columna Adyacencias reales y las adyacencias calculadas
con la herramienta (Adyacencias aproximadas).
8.2.1 Pruebas realizadas

A continuacin se presentan todos los resultados de las pruebas realizadas. Como se
mencion anteriormente, las pruebas se basan en la comparacin de dos mtodos para la
seleccin de adyacencias. Las tablas muestran los nombres de las adyacencias seleccionadas
por el personal de la Coordinacin de Optimizacin 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 Coordinacin de
Optimizacin, se utiliza el smbolo . Tambin 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) Clculos realizados con: Nmero 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.
(3) Clculos realizados con: Nmero de adyacencias = 20, Error de ngulo = 60, Apertura de antena adicional
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.

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.

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.

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.

152
Todos los resultados de las tablas mostradas anteriormente, permiten comprobar que el
objetivo planteado al desarrollar la herramienta para el clculo automtico de las adyacencias
de una estacin base. Este objetivo fue lograr ms de un 50% de coincidencia con las
adyacencias existentes y seleccionadas por el personal de la Coordinacin de Optimizacin,
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 Coordinacin de Optimizacin, para
el uso e interpretacin 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 parmetros y analizar los resultados que entrega la
herramienta), para lograr un correcto clculo de adyacencias, se presenta el siguiente ejemplo
realizado. Al calcular las adyacencias del sector ADJUNDOS1, la herramienta indic que su
radio de cobertura terico era de aproximadamente 2,725 km. Los parmetros 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 parmetros, la herramienta
slo 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 geogrficas de
ADJUNDOS1, y se observ que la BTS ms cercana a ADJUNDOS se encontraba a
3,448 km aproximadamente. Luego de analizar brevemente esta informacin, se decidi
ampliar el radio de cobertura de ADJUNDOS1 para aumentar las probabilidades de
solapamiento y por lo tanto la posibilidad de tener ms adyacencias. Para aumentar el radio de
cobertura se decidi reducir la potencia de recepcin 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 propagacin para realizar los clculos. Luego de
realizar las modificaciones y calcular las adyacencias nuevamente, se logr obtener 18
adyacencias, de las cuales 9 pertenecan a las adyacencias reales.
153
Para finalizar este captulo, se presentan a continuacin dos tablas en donde se realiza
una comparacin adicional entre Microsoft Access, MySQL y PostgreSQL. La tabla 20,
compara las caractersticas y limitaciones de los DBMS [29] [30] [31] [32]. La segunda tabla,
tabla 21, muestra una comparacin subjetiva en donde se comparan los costos de
implementacin de los distintos DBMS.
Microsoft
Access
Tamao mximo
de base de datos
Nmero mximo
de usuarios
concurrentes
Nmero mximo
de columnas en
una tabla
Tamao mximo
de una tabla
Tamao mximo
de una fila
Tamao mximo
de un campo
Nmero mximo
de ndeces en
una tabla
Nmero mximo
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. Caractersticas 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
actualizacin
Microsoft
Access 2003
&
Microsoft
Windows XP
Costo del
sistema
operativo
Costo del
DBMS
Costo de
entrenamient
o bsico de 1
persona
$1.000
$1.000
$1.000
$1.000
Tabla 21. Costos de implementacin de los tres DBMS estudiados.
Se recomienda al lector visitar las pginas web que se presentan a continuacin para
obtener informacin ms detallada acerca de los precios y licencias de los programas
mencionados en la tabla 21.
El costo de entrenamiento bsico mostrado en la tabla, corresponde al costo mnimo
estimado que se debe invertir en una persona, para que sta adquiera conocimientos bsicos
acerca de la administracin de los sistemas operativos y de los sistemas manejadores de bases
de datos. Este costo es una estimacin, y corresponde a un salario de $500 mensuales en un
perodo de dos meses.
La tabla 21 muestra los precios ms bajos de los productos ofrecidos, que en general
son los que ofrecen menor cantidad de caractersticas. Se escogieron los productos, tomando
en cuenta la disponibilidad de ellos para equipos con procesadores de 64-bit compatibles con
las tecnologas 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 conexin y el acceso al servidor. Dependiendo de las
necesidades en el nmero de CALs, algunos de los precios de la tabla 21 se pueden elevar a
ms 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
migracin a un sistema operativo Linux y a un DBMS de licencia libre, se pueden reducir en
ms 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 ms de $10.000.
A continuacin se muestran las pginas web que se recomiendan al lector para
conseguir ms informacin 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 optimizacin de las herramientas Daily Optimizer y Parameter de la

Coordinacin de Optimizacin 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 seccin del
servidor HP Blade asignada a la Coordinacin de Optimizacin.
Se realiz un estudio comparativo entre el sistema administrador de bases de datos
actualmente usado por la Coordinacin de Optimizacin (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 grfica
de esta herramienta, mostr los tiempos de ejecucin y procesamiento de las consultas
realizadas a los tres DBMS. La herramienta permiti realizar consultas a estos tres DBMS, a
travs de la misma interfaz grfica lo que facilit y agiliz la realizacin del estudio.
Se realiz un anlisis 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
ms cortos se obtuvieron con el DBMS PostgreSQL.
Se seleccion PostgreSQL, como nuevo administrador de bases de datos para la
Coordinacin de Optimizacin, basado en los resultados del estudio comparativo y en las
necesidades de la Coordinacin de Optimizacin de utilizar un sistema operativo Linux.
Se realiz la migracin 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 automticamente
las bases de datos de PostgreSQL.
157
Se modific la estructura de las bases de datos con lo cual se increment la velocidad

de bsqueda 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 optimizacin deseada de las herramientas, al obtener una reduccin en el tiempo
de consulta y procesamiento de ms del 80%.
Se desarroll una completa documentacin tcnica en donde se especifican los
procedimientos necesarios para realizar la migracin de las bases de datos y la instalacin del
sistema operativo SUSE Linux en el servidor HP Blade.
Se desarroll una herramienta que automatiz el procedimiento inicial para la
seleccin de las adyacencias de una BTS o de una nueva BTS.
Se desarroll la interfaz grfica de la herramienta para permitir al personal de la
Coordinacin de Optimizacin escoger la combinacin NCC-BCC de una nueva BTS, sin la
necesidad de buscar esta informacin en las tablas de las bases de datos, es decir, se
automatiz el proceso de seleccin de los parmetros NCC y BCC.
Se desarroll una interfaz grfica de la herramienta que permite al personal de la
Coordinacin de Optimizacin, administrar las bases de datos en donde se almacena la
informacin acerca de las BTS Nokia de la red celular de Digitel GSM.
La herramienta desarrollada para el clculo automtico de las adyacencias, genera los
reportes Datafill necesarios al crear una nueva BTS.
Como recomendacin general, se plantea que la seleccin del sistema operativo y del
sistema administrador de bases de datos que se van a instalar en el servidor HP Blade, sea una
decisin 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
ms eficiente posible, ya que toda la informacin estar bajo un formato y estructura nica.
158
Para ayudar en este proceso de unificacin, 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 seleccin 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 seleccin de un DBMS de licencia libre.
Se realiz una comparacin estimada de los algunos de los costos implicados en la
migracin y cambio de OS y DBMS, y se concluy que Digitel GSM, puede evitar costos de
ms de $10.000, dependiendo del OS y el DBMS seleccionados.
159
REFERENCIAS BIBLIOGRFICAS
[1] Digitel GSM. Portal de Digitel.
<http://www.digitel.com.ve/PortalDeDigitelTIM/DigitelTIM.portal?_nfpb=true&_pageLabel=
corporacion>. (2006)
[2] Nuestra Historia. Digitel GSM <http://intranet.corp.digitel.com.ve>. (2006)
[3] Nuestros Valores. Digitel GSM. Portal de Digitel.
<http://www.digitel.com.ve/PortalDeDigitelTIM/DigitelTIM.portal?_nfpb=true&_pageLabel=
corporacion&archivoSeleccionado=corp_mision.jsp&currentMenuOption=null>
[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] Eberspcher, Jrg, et al. GSM Switching, Services and Protocols. John Wiley & Sons
Ltd. Segunda Edicin. 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] Gtz, Roland. Supporting Network Planning Tools II. Presentacin en Power Point. LS
Telcom AG. (2002).
[9] Edfors, Ove. Channel models and antennas. Presentacin en Power Point de la clase
nmero 4 del curso ETI 051. Departamento de Electrociencia, Universidad de Lund, Suecia.
(2006).
[10] Loyka, Sergey. Introduction to Mobile Communications. Notas de la clase nmero 3
del curso ELG7178A. Escuela de la Tecnologa de Informacin e Ingeniera, 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
Edicin. 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 Edicin. McGrawHill. pp. 1-27, 79-189, 393-565, 683-709.
160
[14] Rob, Peter and Coronel Carlos. Database Systems: Design, Implementation and
Management. Quinta edicin. 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. <http://es.wikipedia.org/wiki/ODBC>.
[17] ODBC Architecture. Red para Desarrolladores de Microsoft (MSDN; Microsoft
Developer Network). <http://msdn.microsoft.com/library/default.asp?url=/library/enus/odbc/htm/odbcoverview_of_odbc_architecture.asp>
[18] ADO, DAO and RDO in Visual Basic. Red para Desarrolladores de Microsoft
(MSDN; Microsoft Developer Network).
<http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon98/html/vbconusingadodaordoinvisualbasic.asp>
[19] ADO Compared with RDO and DAO. Ayuda de Visual Basic 6 o MSDN en
<http://msdn.microsoft.com/library/default.asp?url=/library/enus/vbcon98/html/vbconadocomparedwithrdodao.asp>
[20] ActiveX Data Objects (ADO) Frequently Asked Questions. Red para Desarrolladores
de Microsoft (MSDN; Microsoft Developer Network).
<http://support.microsoft.com/default.aspx?scid=kb;EN-US;q183606>
[21] Pooling in the Microsoft Data Access Components. Red para Desarrolladores de
Microsoft (MSDN; Microsoft Developer Network).
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmdac/html/pooling2.asp>
[22] What Data Sources Can I Access with DAO and ODBC?. Red para Desarrolladores de
Microsoft (MSDN; Microsoft Developer Network).
<https://msdn.microsoft.com/library/default.asp?url=/library/enus/vccore/html/_core_what_data_sources_can_i_access_with_dao_and_odbc.3f.asp>
[23] Data Access: ADO and RDO. Red para Desarrolladores de Microsoft (MSDN;
Microsoft Developer Network).
<http://msdn.microsoft.com/library/default.asp?url=/library/enus/vccore/html/vcrefrdodatabindingvsadodatabinding.asp>
161
[24] Why Should I Use DAO or ODBC. Red para Desarrolladores de Microsoft (MSDN;
Microsoft Developer Network). <http://msdn2.microsoft.com/en-us/library/ttc6chk1.aspx>
[25] Data Access Technologies Road Map.Red para Desarrolladores de Microsoft (MSDN;
Microsoft Developer Network).
<http://msdn.microsoft.com/library/default.asp?url=/library/enus/Dnmdac/html/data_mdacroadmap.asp>
[26] Principio de Pareto. <http://es.wikipedia.org/wiki/Principio_de_Pareto>
[27] Office XP System Requirements. Microsoft Office Online.
<http://www.microsoft.com/office/previous/xp/sysreqs.asp>
[28] Access 2003 System Requirements. Microsoft Office Online.
<http://www.microsoft.com/office/access/prodinfo/sysreq.mspx>
[29] Manual de referencia de MySQL 5.0.
[30] Documentacin de PostgreSQL 8.0.
[31] MTU
<http://es.wikipedia.org/wiki/MTU>
[32] Access specifications
<http://office.microsoft.com/en-us/assistance/HP051868081033.aspx>
[33] Frequently Asked Questions (FAQ) for PostgreSQL
<http://www.postgresql.org/docs/faqs.FAQ.html>

Redes GSM Celular

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Redes GSM Celular

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD SIMN BOLVAR

Decanato de Estudios Profesionales

OPTIMIZACIN DE LAS HERRAMIENTAS DE ANLISIS DE LA RED CELULAR

Sartenejas, Noviembre 2006

UNIVERSIDAD SIMN BOLVAR

OPTIMIZACIN DE LAS HERRAMIENTAS DE ANLISIS DE LA RED CELULAR

Informe Final de Cursos en Cooperacin Tcnica y Desarrollo Social

UNIVERSIDAD SIMN BOLVAR

OPTIMIZACIN DE LAS HERRAMIENTAS DE ANLISIS DE LA RED CELULAR

REALIZADO CON LA ASESORIA DE:

8.1 Estudio comparativo entre tres administradores de bases de datos 110

GLOSARIO, SMBOLOS Y ABREVIATURAS

2. DESCRIPCIN Y ANTECEDENTES DEL PROBLEMA

servicios de telefona inalmbrica bsica, pblica y mvil basados en la tecnologa GSM. La

una multiconcesin para prestar servicios bsicos de

telecomunicaciones y telefona pblica. Seis meses despus, en Enero de 1998, se firm el

clientes y accionistas, distinguindonos por una vocacin de servicio, innovacin, calidad y

Innovacin, Excelencia Profesional y Espritu Emprendedor. [3]

Transparencia: Actuamos de manera transparente y tica, para fortalecer las

GOH (Gestin Organizacional y Humana), Operaciones, etc.). De igual manera, cada

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

Planteamiento del Problema.

variedad de los servicios ofrecidos, cantidad de llamadas bloqueadas y llamadas cadas,

2.3 Alcance y limitaciones del proyecto

los tiempos de procesamiento de datos y lograr la automatizacin de tareas manuales.

telecomunicaciones, luego se hace un recorrido acerca de la tecnologa y arquitectura del

4.2 Principios Bsicos de GSM

Telecommunications) fund un grupo encargado de disear un sistema de telecomunicaciones

El primero de Julio, se realiz la primera llamada en el mundo a travs de GSM.

Se lanz la primera red GSM en Finlandia. Se asignaron nuevas frecuencias para

En Diciembre ya haban 32 redes GSM operando en 18 reas geogrficas distintas.

Se realizaron las primeras pruebas de datos de circuito conmutado de alta velocidad

Arquitectura de una red celular GSM

Otro componente fundamental en cualquier red celular es la estacin mvil (MS;

Figura 2. Arquitectura de una red GSM

4.2.2.1 Subsistema de estacin base

est compuesto por el controlador de estacin base, la estacin base de transmisin-recepcin

4.2.2.2 Subsistema de conmutacin de la red

Figura 3. Diferencias entre HLR y VLR

Figura 4. Relacin entre MSC y VLR

El registro de identificacin de equipos (EIR; Equipment Identity Register): Sirve para

4.2.2.3 Subsistema de administracin de la red

Manejo de la configuracin, operacin y desempeo de todos los componentes de la

Figura 5. Interfaz de aire de GSM

4.2.3.1 Canales fsicos y lgicos

Figura 6. Time slots y tramas TDMA en GSM.

Los canales de sealizacin se pueden dividir ms an en canales de difusin

Figura 7. Canales lgicos de la interfaz de aire de GSM

Planificacin y optimizacin de una red GSM.

la red de radiofrecuencia (Radio Network Planning) o la planificacin de los recursos de

4.2.4.1 Planificacin de los recursos de radiofrecuencia.

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

En esta frmula es necesario que el tiempo promedio de conversacin o tiempo

Otro factor importante al planificar la red de radiofrecuencia es la configuracin de las

Figura 8. Diferentes configuraciones de BTS.

4.2.4.2 Modelos de propagacin para la planificacin de una red celular

Figura 10. Modelos de propagacin y su rango vlido de frecuencias. [8]

El modelo que se presenta a continuacin, es el modelo utilizado en el desarrollo del

Altura de la estacin base: 20 100m

Figura 11. Representacin grfica del modelo de propagacin emprico de Okumura-Hata.

4.3 Fundamentos de las bases de datos y sistemas de bases de datos

Historia de las bases de datos

el modelo de datos jerrquicos (hierarchical data model), el modelo de datos orientados a