Por
Hansell E. Barn Altuve
Por
Hansell E. Barn Altuve
Realizado con la Asesora de:
Ing. Fidel Gil (Tutor Acadmico)
Ing. Juan Gallardo (Tutor Industrial)
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
adyacencias de una BTS
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
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
Figura 24. Actividad de red, del computador cliente, al realizar
la prueba preliminar 1 con MySQL / Linux
112
Figura 25. Actividad de red, del computador cliente, al realizar
la prueba preliminar 1 con PostgreSQL / Linux 112
Figura 26. Actividad de CPU y memoria al realizar la prueba preliminar 1
con Microsoft Access / Windows 114
Figura 27. Actividad de CPU y memoria al realizar la prueba preliminar 1
con MySQL / Linux
115
Figura 28. Actividad de CPU y memoria al realizar la prueba preliminar 1
con PostgreSQL / Linux 115
Figura 29. Grficas del uso de CPU, del computador cliente, al ejecutar
la prueba preliminar 2 con Microsoft Access / Windows 118
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
la prueba preliminar 4 con Microsoft Access / Windows 127
Figura 36. Actividad de la red del computador cliente al ejecutar varias de las
consultas de la tabla 11 143
vi
NDICE DE TABLAS
Tabla 1. Los sistemas administradores de bases de datos en
diferentes computadores
74
Tabla 2. Resultados de la prueba preliminar 1
111
Tabla 3. Resultados de la prueba preliminar 2
117
Tabla 4. Resultados de la prueba preliminar 3
122
Tabla 5. Resultados de la prueba preliminar 4
126
Tabla 6. Resultados de la prueba preliminar 5
129
Tabla 7. Resultados de la prueba final 1
132
Tabla 8. Resultados de la prueba final 3
136
Tabla 9. Resultados de la prueba final 4
137
Tabla 10. Resultados de la prueba final 5
140
Tabla 11. Resultados de la prueba preliminar 6 (Linux)
142
Tabla 12. Resultados de la prueba preliminar 6 (Windows) 142
Tabla 13. Resultados obtenidos al realizar la consulta 1 de
la herramienta Parameter 145
Tabla 14. Resultados obtenidos al realizar la consulta 2 de
la herramienta Parameter 145
Tabla 15. Adyacencias para el sector 23ENERO1 148
Tabla 16. Adyacencias para el sector AVSUCRE1 149
Tabla 17. Adyacencias para el sector MADERERO3
150
Tabla 18. Adyacencias para el sector USBUNO1 151
Tabla 19. Adyacencias para el sector CUMBETRE2
151
Tabla 20. Caractersticas de Microsoft Access, MySQL y PostgreSQL
153
Tabla 21. Costos de implementacin de los tres DBMS estudiados 145
vii
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.
Descripcin de la Empresa
Digitel GSM es la nica empresa de telecomunicaciones en Venezuela que ofrece
2.1.1
Misin de la Empresa
Ofrecer servicios de telecomunicaciones que excedan las expectativas de nuestros
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,
2.1.4
Organigrama de la Empresa
Digitel GSM posee una estructura piramidal dividida por departamentos (Mercadeo,
2.2
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
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
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
Evolucin de GSM
En los inicios de la dcada de 1980, CEPT (Confrence Europenne des Postes et
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
1992
1993
1995
Haba 117 redes GSM operando a nivel mundial. Se implement la primera red GSM
1900 en E.E.U.U.
1998
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
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
16
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
19
20
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
Downlink: 1805-1880 MHz
GSM1900:
Uplink: 1850-1910 MHz
Downlink: 1930-1990 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]
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]
23
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]
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
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
28
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]
30
31
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.1
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
35
4.3.2
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.
37
4.3.3
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]
38
4.3.4
39
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.
41
42
4.3.5
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
44
45
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 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]
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
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
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
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
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
55
5.3
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
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
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
5.7
57
5.8
5.9
58
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.
59
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
62
63
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
6.2
65
6.2.1
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:
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.
67
6.3
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.
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
73
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
PostgreSQL
MySQL 5.0
8.0
Windows 2000
/ Computador
1
Linux SUSE
10.1 /
Computador 2
75
6.5
Pruebas preliminares
Para iniciar el estudio comparativo lo ms rpido posible, se decidi hacer unas
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
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:
1. Se inici el programa de pruebas lo cual abre las conexiones a los administradores de
bases de datos.
2. Se ejecut la consulta solamente a uno de los tres administradores de bases de datos.
3. Se esper hasta que se mostraran por pantalla los resultados.
4. Se cerr el programa de pruebas lo cual cierra todas las conexiones a los
administradores de bases de datos.
5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden especfico.
6. Se ejecut el paso anterior 5 veces.
El objetivo de esta consulta, similar a la de la prueba preliminar 1 es comparar la
capacidad de los administradores de bases de datos de procesar y enviar la 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:
1. Se inici el programa de pruebas lo cual abre las conexiones a los administradores de
bases de datos.
2. Se asign 23ENERO1 a la variable nombresectorBTS, 2005-03-01 a la variable
fecha1 y 2006-03-01 a la variable fecha2.
3. Se ejecut la consulta a uno de los tres administradores de bases de datos y se
esperaron los resultados.
4. Se ejecut la consulta a otro de los tres administradores de bases de datos y se
esperaron los resultados.
5. Se ejecut la consulta al ltimo de los tres administradores de bases de datos y se
esperaron los resultados.
6. Se cerr el programa de pruebas lo cual cierra todas las conexiones a los
administradores de bases de datos.
7. Se ejecutaron 10 veces los pasos del 1 al 6.
La prueba preliminar 3 busca comparar la capacidad de los administradores de bases
de datos de procesar grandes cantidades de datos o tablas de gran 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
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:
1. Se inici el programa de pruebas lo cual abre las conexiones a los administradores de
bases de datos.
2. Se asign 23ENERO1 a la variable nombresectorBTS, 2005-03-01 a la variable
fecha1 y 2006-03-01 a la variable fecha2
3. Se ejecut la consulta a uno de los tres administradores de bases de datos y se
esperaron los resultados.
4. Se ejecut la consulta a otro de los tres administradores de bases de datos y se
esperaron los resultados.
5. Se ejecut la consulta al ltimo de los tres administradores de bases de datos y se
esperaron los resultados.
6. Sin cerrar el programa de pruebas, se cambi el nombre de la BTS (variable
nombresectorBTS) y se repitieron los pasos del 3 al 5.
7. El paso nmero 5 se repiti 10 veces.
79
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:
1. Se inici el programa de pruebas lo cual abre las conexiones a los administradores de
bases de datos.
2. Se ejecut la consulta a uno de los tres administradores de bases de datos y se
esperaron los resultados.
3. Se ejecut la consulta a otro de los tres administradores de bases de datos y se
esperaron los resultados.
4. Se ejecut la consulta al ltimo de los tres administradores de bases de datos y se
esperaron los resultados.
5. Se cerr el programa de pruebas lo cual cierra todas las conexiones a los
administradores de bases de datos.
6. Se ejecutaron 5 veces los pasos del 1 al 5.
El objetivo de esta prueba es comparar la capacidad de los administradores de bases de
datos de procesar y buscar 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
82
83
84
85
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
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.
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
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 `objects`
(tabla)
(tabla)
(tabla)
(vista)
(vista)
(vista)
(vista)
(vista)
(vista)
90
(vista)
(vista)
91
aproximada, los costos que implica el realizar un cambio de sistema operativo y de sistema
administrador de bases de datos.
7.1
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
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
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
98
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:
99
100
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.
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.
104
Figura 20. Interfaz de la herramienta luego de calcular las adyacencias para el sector
23ENERO1.
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.
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
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.
110
8.1
111
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
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.
Figura 24. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con
MySQL / Linux.
Figura 25. Actividad de red, del computador cliente, al realizar la prueba preliminar 1 con
PostgreSQL / Linux.
113
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
117
Prueba preliminar 2
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY
FECHA.
Procedimiento:
1. Se inici el programa de pruebas.
2. Se ejecut la consulta solamente a uno de los tres administradores de bases de datos.
3. Se esper hasta que se mostraran por pantalla los resultados.
4. Se cerr el programa de pruebas.
5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden especfico.
6. Se ejecut el paso anterior 5 veces.
La tabla 3 muestra los tiempos de ejecucin, en segundos, de cada consulta para cada
administrador de bases de datos.
Microsoft
Access /
Windows
(segundos)
528,125
520,031
523,109
522,422
522,84
Microsoft
Access / Linux
(segundos)
MySQL /
Windows
(segundos)
MySQL /
Linux
(segundos)
520,333
518,751
512,986
519,324
517,932
382,698
381,157
398,042
396,078
385,188
368,123
374,852
366,96
371,375
369,686
PostgreSQL / PostgreSQL /
Windows
Linux
(segundos)
(segundos)
344,392
343,778
345,129
344,846
343,635
313,478
315,611
315,323
311,956
317,865
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
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE
FECHA BETWEEN fecha1 AND fecha2 AND celda=nombresectorBTS ORDER
BY FECHA.
Procedimiento:
1. Se inici el programa de pruebas.
2. Se asign 23ENERO1 a la variable nombresectorBTS, 2005-03-01 a la variable
fecha1 y 2006-03-01 a la variable fecha2.
3. Se ejecut la consulta a uno de los tres administradores de bases de datos.
4. Se ejecut la consulta a otro de los tres administradores de bases de datos.
5. Se ejecut la consulta al ltimo de los tres administradores de bases de datos.
6. Se cerr el programa de pruebas.
7. Se ejecutaron 10 veces los pasos del 1 al 6.
La tabla 4 muestra los tiempos de ejecucin, en segundos, de cada consulta para cada
administrador de bases de datos.
122
Microsoft
Access /
Windows
(segundos)
22,079
22,853
22,554
22,289
22,72
22,487
22,767
22,859
22,671
22,768
Microsoft
Access / Linux
(segundos)
MySQL /
Windows
(segundos)
MySQL /
Linux
(segundos)
21,845
21,905
21,911
21,886
21,891
21,851
21,86
21,873
21,89
21,857
12,321
5,696
5,783
5,778
5,738
5,802
5,692
5,765
5,712
5,753
11,468
5,344
5,359
5,343
5,327
5,32
5,299
5,362
5,333
5,311
PostgreSQL / PostgreSQL /
Windows
Linux
(segundos)
(segundos)
11,016
8,969
8,938
8,953
8,936
8,941
8,97
8,51
8,978
8,964
9,047
8,946
8,89
8,97
9,12
9
8,821
8,844
8,911
8,836
(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)
(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
126
La tabla 5 muestra los tiempos de ejecucin, en segundos, de cada consulta para cada
administrador de bases de datos.
Nombre del
sector de la
BTS
23ENERO1
MACARDOS1
MAMPORAL2
YAGUARA2
CCCTIN1
GUAREDOS3
ANA2
PIEDAZUL1
USBUNO2
ADJUNDOS1
ACACIAS1
Microsoft
Access /
Windows
(segundos)
22,62
0,985
0,937
0,984
0,953
0,92
0,937
0,938
0,954
0,953
0,937
Microsoft
Access / Linux
(segundos)
MySQL /
Windows
(segundos)
MySQL /
Linux
(segundos)
22,88
0,944
0,921
0,975
0,983
0,934
0,93
0,956
0,976
0,983
0,974
5,799
5,763
5,747
5,763
5,671
5,778
5,763
5,763
5,793
5,81
5,763
5,465
5,36
5,265
5,25
5,422
5,218
5,422
5,516
5,297
5,235
5,124
PostgreSQL / PostgreSQL /
Windows
Linux
(segundos)
(segundos)
8,81
8,793
8,75
8,734
8,678
8,735
8,75
8,689
8,771
8,715
8,786
8,85
8,853
8,776
8,916
8,689
8,756
8,811
8,764
8,738
8,722
8,685
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
8. Se ejecut la consulta a uno de los tres administradores de bases de datos.
9. Se ejecut la consulta a otro de los tres administradores de bases de datos.
10. Se ejecut la consulta al ltimo de los tres administradores de bases de datos.
11. Se cerr el programa de pruebas.
12. Se ejecutaron 5 veces los pasos del 1 al 5.
La tabla 6 muestra los tiempos de ejecucin, en segundos, de cada consulta para cada
administrador de bases de datos.
Microsoft
Access /
Windows
(segundos)
2,093
2,112
2,081
2,106
2,09
Microsoft
Access / Linux
(segundos)
MySQL /
Windows
(segundos)
MySQL /
Linux
(segundos)
2,126
2,122
2,108
2,115
2,118
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
PostgreSQL / PostgreSQL /
Windows
Linux
(segundos)
(segundos)
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
> 600
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
132
Prueba final 1
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS`.
Procedimiento:
1. Se configur el programa de pruebas para que las conexiones y los resultados tuvieran
cursores ADO manejados por el servidor.
2. Se inici el programa de pruebas.
3. Se ejecut la consulta solamente a uno de los tres administradores de bases de datos.
4. Se esper hasta que se mostraran por pantalla los resultados.
5. Se cerr el programa de pruebas
6. Se ejecutaron los pasos del 2 al 5, para los tres administradores sin orden especfico.
7. Se ejecut el paso anterior 5 veces.
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
133
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
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS`.
Procedimiento:
1. Se configur el programa de pruebas para que las conexiones y los resultados tuvieran
cursores ADO manejados por el cliente.
2. Se inici el programa de pruebas.
3. Se ejecut la consulta solamente a uno de los tres administradores de bases de datos.
4. Se esper hasta que se mostraran por pantalla los resultados.
5. Se cerr el programa de pruebas
6. Se ejecutaron los pasos del 1 al 4, para los tres administradores sin orden especfico.
7. Se ejecut el paso anterior 5 veces.
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
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS` ORDER BY
`FECHA`.
Procedimiento:
1. Se inici el programa de pruebas.
2. Se ejecut la consulta solamente a uno de los tres administradores de bases de datos.
3. Se esper hasta que se mostraran por pantalla los resultados.
4. Se cerr el programa de pruebas.
5. Se ejecutaron los pasos del 1 al 5, para los tres administradores sin orden especfico.
6. Se ejecut el paso anterior 5 veces.
La tabla 8 muestra los resultados obtenidos al realizar la prueba final 3 con MySQL y
PostgreSQL. Los resultados con Microsoft Access no se muestran debido a que los tiempos
136
PostgreSQL /
Linux
(segundos)
284,656
291,312
286,155
286,75
287,351
Prueba final 4
Se ejecut la consulta SELECT * FROM `TABLA GENERAL GPRS` WHERE
FECHA BETWEEN fecha1 AND fecha2 AND celda=nombresectorBTS ORDER
BY FECHA.
Procedimiento:
1. Se inici el programa de pruebas.
2. Se ejecut la consulta a uno de los tres administradores de bases de datos.
3. Sin cerrar el programa de pruebas, se cambi el nombre de la BTS (variable
nombresectorBTS) y se repiti el paso anterior.
137
Nombre del
sector de la
BTS
23ENERO1
MACARDOS1
YAGUARA2
CCCTIN1
GUAREDOS3
ANA2
PIEDAZUL1
USBUNO2
HIGUEROT3
TAHONA1
ESTANCIA2
Microsoft
Access /
Windows
(segundos)
28,196
28,165
27,984
27,984
28,025
27,991
27,974
27,988
27,961
27,986
27,977
MySQL /
Windows
(segundos)
MySQL / Linux
(segundos)
4,484
4,389
0,858
5
4,343
3,967
5,078
3,828
4,75
4,453
3,889
5,108
5,077
5,112
5,093
5,078
5,13
5,159
5,124
5,148
5,084
5,025
PostgreSQL / PostgreSQL /
Linux
Windows
(segundos)
(segundos)
3,326
3,375
3,276
3,25
3,205
3,346
3,312
3,241
3,318
3,303
3,21
4,639
4,405
0,922
4,891
4,325
4,764
4,323
4,412
4,586
4,734
4,412
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
Prueba final 5
Se ejecut la consulta SELECT * FROM par_hoc.
Procedimiento:
1. Se inici el programa de pruebas
2. Se ejecut la consulta a uno de los tres administradores de bases de datos.
3. Se ejecut la consulta a otro de los tres administradores de bases de datos.
4. Se ejecut la consulta al ltimo de los tres administradores de bases de datos.
5. Se cerr el programa de pruebas.
6. Se ejecutaron 5 veces los pasos del 1 al 5.
140
Microsoft
Access /
Windows
(segundos)
1,523
1,406
1,484
1,344
1,375
MySQL /
Windows
(segundos)
MySQL / Linux
(segundos)
0,345
0,343
0,338
0,353
0,35
0,734
0,719
0,735
0,75
0,734
PostgreSQL / PostgreSQL /
Linux
Windows
(segundos)
(segundos)
0,857
0,864
0,895
0,864
0,89
0,733
0,703
0,813
0,704
0,812
Prueba final 6
Se ejecutaron las siguientes consultas:
SELECT * FROM `objects`
(tabla)
(tabla)
(tabla)
(vista)
141
(vista)
(vista)
(vista)
(vista)
(vista)
(vista)
(vista)
Procedimiento:
1. Se inici el programa de pruebas.
2. Se seleccion una consulta.
3. Se ejecut la consulta a uno de los tres administradores de bases de datos.
4. Se ejecut la consulta a otro de los tres administradores de bases de datos.
5. Se ejecut la consulta al ltimo de los tres administradores de bases de datos.
6. Se escogi otra consulta y se repitieron los pasos del 3 al 5.
7. El paso nmero 6 se repiti 5 veces.
8. Se cerr el programa de pruebas.
Las tablas 11 y 12, muestran los tiempos obtenidos al ejecutar las consultas de esta
prueba final 6. Para evitar tablas grandes y engorrosas de leer, las tablas 11 y 12 solamente
muestran el promedio de los 5 tiempos de ejecucin obtenidos al ejecutar cada consulta.
142
Consulta realizada
Microsoft
PostgreSQL /
MySQL / Linux
Access / Linux
Linux
(segundos)
(segundos)
(segundos)
2,468
5,046
4,61
0,25
0,25
0,5
0,875
0,75
0,75
1,157
1,454
1,047
0,889
1,125
0,125
1,422
0,172
0,218
1,562
1,187
0,687
0,921
0,264
0,141
3,844
33,315
5,906
1,922
2,031
3,64
1,188
0,781
0,703
3,141
23,266
10,655
Consulta realizada
1 SELECT * FROM `objects`
2 SELECT * FROM `power_control`
3 SELECT * FROM `handover_control`
4 SELECT * FROM `bcf_id`
5 SELECT * FROM `bts_id`
6 SELECT * FROM `bts_id_bsc_id_name`
7 SELECT * FROM `poc_id`
8 SELECT * FROM `trx_id`
9 SELECT * FROM `par_adj_cell`
10 SELECT * FROM `par_trx`
11 SELECT * FROM `par_poc`
12 SELECT * FROM `trx_bcch`
Microsoft
Access /
Windows
(segundos)
2,89
MySQL /
Windows
(segundos)
PostgreSQL /
Windows
(segundos)
3,125
5,875
0,282
0,485
0,781
0,438
0,765
1,375
1,078
0,827
1,186
0,719
0,219
0,077
1,096
0,119
0,094
1,5
0,75
0,875
1,328
0,108
0,11
4,172
25,922
5,125
2,422
1,407
4,297
1,219
0,469
0,968
2,531
22,078
12,031
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
(a)
(b)
(c)
(d)
Figura 36. Actividad de la red en el computador cliente al ejecutar varias de las consultas de la
tabla 11. (a) SELECT * FROM `objects`. Orden de 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
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
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
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
8.2
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).
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
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
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
151
Adyacencias
reales
Adyacencias
aproximadas
(1)
Adyacencias
aproximadas
(2)
Adyacencias
aproximadas
(3)
BARUTUNO2
BONITA2
BARUTDOS2
HYWTWO2 MANZANAR2
PLACER1
SWITCH1
TRINIDOS2
TAZON1
TRINIUNO2
USBDOS1
USBUNO2
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
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
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
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
9. CONCLUSIONES Y RECOMENDACIONES
157
158
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¤tMenuOption=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>