“SICAB” Sistema de Información para Central de Alarmas de

UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA
EN COMPUTACIÓN
“SICAB”
Sistema de Información para Central de
Alarmas de Bomberos
Alexi Isabel Mandiola Godoy
Alfonso Ircano Díaz Muñoz
2003
UNIVERSIDAD DE MAGALLANES
FACULTAD DE INGENIERIA
DEPARTAMENTO DE INGENIERIA
EN COMPUTACIÓN
“SICAB”
Sistema de Información para Central de
Alarmas de Bomberos
Trabajo de titulación presentado en conformidad a los
requisitos para obtener el título de Ingeniero(a) de
Ejecución en Computación e Informática.
Profesor Guía
Patrocinante
: Roberto Uribe Paredes
Ingeniero
de
Ejecución
en
Computación e Informática
: Cuerpo de Bomberos de Puerto
Natales
Alexi Isabel Mandiola Godoy
Alfonso Ircano Díaz Muñoz
2003
La presente memoria de titulación ha sido aprobada con la siguiente calificación:
Alumna Alexi Isabel Mandiola Godoy
Memoria
:
Examen de título
:
Nota Final
:
Alumno Alfonso Ircano Díaz Muñoz
Memoria
:
Examen de título
:
Nota Final
:
Sr. Carlos Arias Méndez
Director Departamento
De Ingeniería En Computación
29 de Agosto de 2003
i
AGRADECIMIENTOS
Los autores del presente informe desean en esta sección agradecer en primer término a los
Oficiales y Bomberos del Cuerpo de Bomberos de Puerto Natales quienes, han entregado las
facilidades necesarias para que se desarrolle este trabajo de titulación. Sin la disposición de ellos,
no habría sido posible cumplir con el objetivo del proyecto, considerando el tiempo que demando
la toma de requerimientos de la información necesaria para llevarla cabo
Por otra parte se desea agradecer al Profesor Guía, Señor Roberto Uribe Paredes, quién pese a sus
responsabilidades y obligaciones como docente del Departamento de Ingeniería en Computación,
de la Facultad de Ingeniería de la Universidad de Magallanes, ha demostrado una excelente
disposición en cuanto a la orientación que se le debía dar al tema propuesto, para llevarlo a buen
término.
ii
RESUMEN
SICAB es un sistema administrativo que opera bajo el ambiente Windows y que permite el
ingreso, almacenamiento y mantención de información relevante para el funcionamiento de los
Cuerpos de Bomberos, tanto en su funcionamiento Administrativo como Operativo.
Está compuesto por módulos que permiten la administración de datos que dicen relación con el
inventario, documentación y datos personales e institucionales(lo que se conoce comúnmente con
el nombre de Hojas de Vida) de los bomberos que integran a estas instituciones.
Además, sirve como herramienta de apoyo gráfico para la parte operativa del Cuerpo de
Bomberos, toda vez que facilita información referente a los accesos a lugares en que deben
eventualmente intervenir los medios materiales y humanos de la Institución ante la ocurrencia de
una emergencia o servicio especial en que tengan que actuar.
Consta de una Base de Datos Relacional, diseñada en Microsoft Access 2000, la cual es
administrada a través de una aplicación creada en Visual Basic 6.0.
El sistema está complementado con la utilización del Sistema de Información Geográfica
Arcview, el cual permite mostrar el plano urbano de la ciudad de Puerto Natales, visualizando los
caminos mínimos que deben seguir las unidades motorizadas del Cuerpo de Bomberos, al
momento de dirigirse a una emergencia.
En su ejecución, se pusieron en práctica conceptos que permiten una eficiente y rápida
gestión de datos y la aplicación de algoritmos diseñados para manejar grafos dirigidos
que permiten dar respuesta a la necesidad de contar con herramientas de apoyo al
servicio bomberil, sobre todo en lo que se refiere a emergencias.
iv
CAPITULO I. INTRODUCCION
iv
1 Introducción
El fuerte y acelerado avance de la tecnología de información, ha llevado a que muchas
instituciones de servicio público hayan tenido que, sin necesidad de perder su objetivo principal,
adecuarse a ellas para lograr una gestión de información de una manera más segura, rápida y
eficiente.
Lo anterior ha llevado a que los autores del presente trabajo, en conjunto con el Cuerpo de
Bomberos de Puerto Natales, hayan tenido que hacer un estudio de los procesos aplicados a la
administración y gestión de información que se realiza en la institución antes mencionada, sobre
todo basándose en la necesidad de contar con procedimientos o sistemas que permitan acceder a
los datos de una manera más eficiente y rápida en lo que se refiere a los entes Administrativos y
Operativos de dicha Institución.
Es así como nace la necesidad de contar con un software capaz de permitir el ingreso,
almacenamiento y mantención de los datos y/o información relacionada con los inventarios,
documentación y del personal que integra el Cuerpo de Bomberos. Pero además de lo anterior,
que permita las mismas funciones para aquellos datos que nacen de las actividades que le dieron
origen hace ya más de siglo y medio: se habla entonces de las emergencias y servicios especiales
a los que acuden en ayuda de la comunidad.
Lo anterior resulta en el nacimiento de SICAB(Sistema de Información para Central de Alarmas
de Bomberos), una aplicación cuyo objetivo principal es permitir la gestión de información
administrativa y operativa del Cuerpo de Bomberos de Puerto Natales, disminuyendo tiempo
considerable ocupado hasta entonces por personal, quienes además de las funciones propias del
iv
servicio bomberil(de carácter cien por ciento voluntario en Chile), deben cumplir con
obligaciones de tipo laboral y familiar, las que sin lugar a dudas tiene un carácter prioritario por
sobre las anteriores.
Como consecuencia de todo lo anterior, el desarrollo del presente informe muestra los pasos
realizados para diseñar un sistema que se ajusta en su fondo a cualquier Institución Bomberil del
país, y que sirve de base para la ejecución de otros proyectos similares que apunten a su
mejoramiento y/o complementación.
iv
CAPITULO II. ESPECIFICACION DEL
PROBLEMA Y TOMA DE REQUERIMIENTOS
iv
2 Especificación del problema y
Toma de Requerimientos
En lo sucesivo del presente documento, se tendrán en cuenta las técnicas preescritas en lo que se
refiere a los procesos para desarrollos de Sistemas de Información Administrativas.
2.1
IDENTIFICACION DEL PROBLEMA
Como se explicó en el CAPITULO I. INTRODUCCION, la necesidad de contar con
herramientas informáticas para automatizar, apoyar y complementar los procesos administrativos
del Cuerpo de Bomberos de Puerto Natales, hicieron posible que se pusiera en marcha el
proyecto SICAB, el cual da respuesta a estas necesidades.
2.2
MEDIO AMBIENTE DE OPERACIÓN
El sistema SICAB trabajará bajo un ambiente de Sistema Operativo Windows, en en computador
de tipo Personal de Escritorio, con su configuración de hardware para tales efectos. Deberá contar
con impresoras para la entrega de informes.
Los usuarios directos del sistema serán el personal de radiooperadoras(es) que la Institución
designe para tales efectos, los que deberán contar con conocimientos de computación
básicos(nivel usuario), más las correspondientes capacitaciones que se realicen una vez instalado
el sistema.
Este sistema interactúa con los equipos de radiocomunicaciones y telefonía, por lo que se debe
considerar una instalación eléctrica especial, o dentro de las posibilidades económicas de la
iv
institución, la adquisición de una Unidad de Respaldo de Energía(UPS) compatible con el tipo de
computador que se esté utilizando.
2.3
ESPECIFICACION Y TOMA DE REQUERIMIENTOS
La estructura orgánica y funcional del Cuerpo de Bomberos de Puerto Natales(así como la de la
gran mayoría de los Cuerpos del País), funciona con dos líneas de mando: una Línea de Mando
Administrativa, a cargo del Superintendente, quién es además el representante legal de la
Institución; y una Línea de Mando Operativa, a cargo del Primer Comandante, quien asume el
mando total y absoluto de todas y cada una de las operaciones de emergencias o servicios
especiales en los que participe material logístico y humano.
Lo anterior hace necesario dividir la toma del sistema en dos partes, una para cada área de
funcionamiento.
Para los requerimientos del área administrativa, se entrevistaron a los Oficiales Administrativos y
personal administrativo rentado. Por otra parte, para los requerimientos del área operativa, se han
entrevistado a los Oficiales Operativos de Cuerpo y Compañía, personal Administrativo y
Operadoras Centrales de Alarma y Despacho.
Los requerimientos que a continuación se describen, definen desde ya los datos de entrada que
tendrá el sistema para su funcionamiento.
2.3.1.
ESPECIFICACIONES Y TOMA DE REQUERIMIENTOS PARA EL SISTEMA
ADMINISTRATIVO
El mando administrativo del Cuerpo de Bomberos de Puerto Natales(CBPN), es la encargada de
llevar el control de las siguientes áreas:
•
Registro del personal que integra la institución, en las calidades de ACTIVO y
COOPERADOR, premios obtenidos, sanciones, cursos realizados, cargos ocupados,
actividades realizadas, todos con sus respectivas observaciones.
iv
•
Control del inventario administrativo y operativo, tanto del CBPN como de cada una de las
Compañías que lo conforman.
•
Control del movimiento de documentación entrada a la Institución y salida de la misma.
Conforme lo descrito anteriormente, el software del sistema administrativo debe contar con
cuatro módulos, que se denominarán:
•
PERSONAL
•
CONTROL DE INVENTARIO
•
DOCUMENTOS
2.3.1.1. REQUERIMIENTOS PARA EL MODULO “PERSONAL”
Este módulo será el encargado de llevar los registros correspondientes a cada uno de los
bomberos, tanto cooperadores como activos.
Los datos básicos que se manejarán para tales efectos son:
•
Número de registro general.
•
Número de folio.
•
Compañía.
•
Apellido Paterno
•
Apellido Materno
•
Nombres
•
Calidad(activo, cooperador)
iv
•
Fecha de incorporación
•
Estudios (básica incompleta o completa, media incompleta o completa, superior incompleta o
completa)
•
Nacionalidad
•
Profesión y/o actividad
•
Fecha de nacimiento.
•
Lugar de Nacimiento.
•
Domicilio particular(calle, población, número, teléfono(s))
•
RUN.
•
Estado civil.
•
Número de registro de compañía.
•
Grupo sanguíneo.
•
Lugar de Trabajo(Nombre de la empresa y/o dirección, teléfono(s)).
•
Fecha de baja.
•
Causa de baja.
•
Servicio militar(si/no, año, unidad)
Además debe incluir el ingreso de los siguientes ítem:
iv
•
Premios y/o sanciones obtenidas, en donde se debe registrar además: el documento que
acredita el premio o sanción, la fecha del documento, el tipo de premio o sanción, y el
motivo de la misma.
•
Cargos o actividades desempeñadas en su carrera como bombero, incluyendo la fecha o
fechas entre las cuales ocupó dicha actividad o cargo, y las observaciones necesarias.
•
Cursos o talleres realizados, considerando la fecha, el nombre del curso, situación de
aprobación, entidad que impartió el curso, observaciones.
Este módulo debe ser capaz de entregar un informe actualizado de los datos correspondientes a
cada bombero, separados en:
•
Informe de datos personales e institucionales.
•
Informe de premios y/o sanciones obtenidas.
•
Informe de cargos o actividades desempeñadas.
•
Informe de cursos realizados.
También debe entregar un listado de bomberos por categoría(activo, cooperador, honorario,
aspirante, etc.)
Por otra parte este módulo debe ser capaz de calcular e informar, si corresponde entregar o no,
premios de constancia por años de servicio a algún miembro de la institución. Estos premios se
entregan cada cinco años de servicios, contados desde la fecha de ingreso a la Compañía, para lo
cual se toma como referencia el día y mes de fundación del CBPN, que es el 20 de JULIO.
2.3.1.2. REQUERIMIENTOS PARA EL MODULO “CONTROL DE INVENTARIO”
A éste modulo le corresponde la función de mantener un efectivo control de inventario, en el que
una vez ingresadas las especies y cada uno de los datos que corresponden a ellas, puedan ser
iv
objeto de un efectivo y a la vez fácil mantenimiento en cuanto a lo que alta(ingreso) o baja del
activo fijo(especie) se refiere.
Para dar cumplimiento a lo anterior, es necesario clasificar estos activos fijos, en los siguientes
grupos:
•
Bienes raíces.
•
Instalaciones.
•
Vehículos motorizados.
•
Material motorizado.
•
Material menor.
•
Vestuario y equipo.
•
Muebles de oficina.
•
Artículos eléctricos o electrónicos.
•
Artículos computacionales.
•
Equipos de radiocomunicaciones y telecomunicaciones.
•
Otros equipos.
•
Otros activos fijos.
Conforme a lo anterior, cada una de las especies que se ingresen al inventario, debe ser
identificada por un código de grupo y un código de especie. El código de grupo estará dado por la
clasificación anterior, y que tiene relación con los grupos de activos fijos, y el código de especie
será un número correlativo para cada especie dentro de un grupo.
iv
En un contexto general, la presentación de las especies de inventario debe contemplar para cada
una de ellas, los siguientes datos:
•
Cantidad de la especie.
•
Código de la especie
•
Nombre de la especie.
•
Valor monetario(en pesos).
•
Observaciones.
•
Compañía en la que se encuentra asignada.
•
Dependencia en la que se encuentra ubicada, dentro de la Compañía.
•
Tipo de inventario(administrativo u operativo).
•
Fecha de alta y/o baja de la especie.
•
Número y fecha del documento de alta o baja.
Este módulo debe ser capaz de entregar los siguientes tipos informes:
•
Listados de especies:
¾ General del Cuerpo.
¾ Por grupo.
¾ Por compañía.
¾ Por dependencia.
iv
¾ Por tipo de inventario(administrativo u operativo).
•
Informe patrimonial; que corresponde a una sumatoria de los valores monetarios de cada una
de las especies, agrupadas según los siguientes criterios:
¾ General del Cuerpo.
¾ Por grupo.
¾ Por compañía.
¾ Por dependencia.
¾ Por tipo de inventario(administrativo u operativo).
En el caso de los valores monetarios de las especies, se debe permitir la modificación de estos, ya
que con el paso del tiempo, exceso de uso, reparaciones y la consiguiente pérdida de vida útil, las
especies en cuestión de devalúan, y por consiguiente en patrimonio físico de la Institución
disminuye.
Para las fechas de alta de una especie al inventario, se considerará como criterio de asignación a
este dato, la fecha de incorporación al servicio para en cual fue adquirido.
2.3.1.3. REQUERIMIENTOS PARA EL MODULO “DOCUMENTOS”
Se tendrá en cuenta que cada documento está definido por un grupo al cual pertenece.
Para lo anterior, se clasifican los tipos de documentos que se manejan en la institución. Estos son:
•
Oficio conductor.
•
Circular.
•
Solicitud.
iv
•
Certificado.
•
Informe Técnico.
•
Acta.
•
Orden del Día.
El manejo de este tipo de documentos, involucra tanto a aquellos que salen de la institución,
como a aquellos que llegan a la misma.
Para cada uno de los oficios salidos se debe llevar un registro con la siguiente información:
•
Nro. De documento.
•
Fecha.
•
Destino
•
Resumen del contenido o materia.
•
Observaciones.
•
De igual manera, los documentos que llegan a la institución deben tener un registro con el
siguiente detalle:
•
Nro. De documento.
•
Fecha del documento.
•
Fecha de recepción del documento.
•
Procedencia.
•
Glosa del contenido o materia.
iv
•
Observaciones.
Con lo anterior, este módulo debe ser capaz de entregar informes acumulativos, separados en
documentación recibida y despachada.
Lo anterior significa que además debe permitirse la entrega de información dado un rango de
fechas.
2.3.2.
ESPECIFICACIONES Y TOMA DE REQUERIMIENTOS DEL SISTEMA PARA
INGRESO DE FORMACION DE SERVICIOS DE EMERGENCIAS
Básicamente este módulo permitirá manejar en forma automática, toda la información que pueda
emanar de una emergencia, y lograr de esta manera tener acceso rápido a datos estadísticos, como
por ejemplo: cantidad de emergencias por tipo, referencias rápidas a informes técnicos de
emergencias, personal que acudió y/o estuvo a cargo de instituciones de apoyo, entre otro tipo de
información.
Por otro lado, este sistema debe trabajar paralelamente con un sistema que permita manejar
información gráfica del área en la que están interviniendo los medios bomberiles. Es decir, un
sistema que muestre el área geográfica en que ocurren las emergencias, en el plano local de la
ciudad.
Se asume que inicialmente la base da datos debe disponer en sus registros de los datos que
establecen el número de Compañías existentes, los vehículos y condición operativa de los
mismos, actualizada.
Para lograr una buena comprensión en los requerimientos de este módulo, se explicará la
secuencia desde el inicio del llamado(es decir, cuando se recibe un aviso de emergencia ), hasta
la finalización del servicio(cuando se retira la última unidad del área de intervención).
iv
2.3.2.1. RECEPCIÓN DEL LLAMADO
El aviso de una emergencia se puede realizar por los siguientes medios:
•
Vía telefónica: a la central(teléfono 132) o a algún cuartel(a un teléfono de cuartel).
•
Radial: ingresando a la frecuencia VHF bomberil.
•
Aviso personal: cuando la persona avisa directamente de la ocurrencia de una emergencia.
Cuando se hace la recepción del llamado, se debe ingresar:
•
Nro. Telefónico.
•
Nombre completo, RUN y dirección de la persona que da la alerta.
•
Hora del llamado.
•
Ubicación(rural o urbana, calle, número, esquina más cercana, kilómetro, ruta o camino)
Aunque esta información es recomendable que se obtenga con los procedimientos establecidos,
no es vital(salvo contadas excepciones) para la información estadística o los informes finales, por
lo que puede ser ingresada en el momento del llamado o posteriormente, una vez que este haya
finalizado. En algunos casos, hay datos que no son necesarios ingresar, y que se explicarán en lo
sucesivo del presente informe.
Conforme a la información que se obtiene del llamado respecto a la emergencia, esta se clasifica,
para despachar posteriormente a las unidades que según los procedimientos de la institución,
atenderá más eficientemente la situación, de acuerdo al tipo de emergencia y a la ubicación
geográfica.
A continuación se procede a detallar la clasificación de los tipos de servicios:
•
EMERGENCIAS
iv
•
-
Principio de incendio estructural
-
Incendio declarado estructural
-
Incendios en vehículos
-
Incendio en pastizal
-
Incendio forestal
-
Incidente HAZMAT
-
Falsa alarma de ...
-
Rescate convencional
-
Rescate vehicular
-
Apoyo a vehículos volcados y otros
-
Emanación de gas
-
Anegamiento de vivienda y otros
-
Salvataje de animales
-
Recuperación de cadáver
-
Emergencia por viento
ESPECIALES
-
Abastecimiento de agua, riego a SS.PP. y particulares
-
Apoyo a SS.PP. y particulares en trabajos de altura
iv
•
•
•
•
-
Otras prestaciones a Instituciones y/o particulares
-
Peritaje de incendio
-
Labores internas de compañía
INSPECCION Y VISITAS
-
Charlas de seguridad a establecimientos educacionales
-
Visitas e inspecciones a Brigada contra incendios de la Comuna Torres del Payne
-
Revisión de seguridad de edificios
CAPACITACION
-
Academias y/o instrucción a otras instituciones
-
Cursos a personal de fuera de la ciudad
-
Ejercicios instrucción teórico/práctica al personal
-
Academias y/o charlas al personal
APOYO
-
Apoyo de seguridad SSEI
-
Apoyo recolección de ropa, enseres, víveres para damnificados
-
Apoyo competencias automovilísticas, pedestres y otras.
REUNIONES Y OTROS
-
Reuniones generales y consejos de oficiales
iv
-
Reuniones D.E.T.
-
Desfiles y/o ceremonias, con medios humanos y material mayor
OBSERVACIONES:
2.3.2.2. DESPACHO DE LAS UNIDADES
Una vez que se ha clasificado el llamado de emergencia y se tiene clara el área de intervención,
se procede al despacho de las máquinas y personal que debe concurrir hasta el lugar. Para ello se
debe considerar tener en el sistema la presentación de cada una de las máquinas existentes en el
parque automotriz, considerando su estado actual de operación, el que puede ser descrito por el
mismo sistema de claves que se utiliza en la institución.
2.3.2.3. INFORMACION DEL SERVICIO
En esta sección se debe permitir el ingreso del máximo de información del servicio al que se está
concurriendo, a fin de poder obtener los datos para los registros que permitirán concluir informes
técnicos, estadísticas, recuperación de información histórica, y otros datos de interés para la
institución.
La información y datos que el sistema debe permitir ingresar en esta sección se detalla a
continuación:
•
Día, Mes, Año y hora de comienzo y termino del servicio.
•
Identificación y hora de retirada de la última unidad del lugar.
•
Horas trabajadas.
•
Oficial o Bombero a cargo del servicio.
iv
•
Concurrencia de organismos de apoyo(Hospital, Carabineros, Gasco, etc.)
•
Total de Bomberos que asistieron.
•
Tipo de emergencia: debe considerar inicialmente el tipo de emergencia con la que se
clasificó el llamado. Este puede ser cambiado, ya que en muchas oportunidades se sale para
un tipo de emergencia y se llega a confirmar otra muy distinta.
•
Identificación de propietario y/o ocupante(Nombre completo y RUN, Domicilio).
•
Origen probable.
•
Causa probable.
•
Categoría probable(accidental, natural, intencional, otra)
•
Magnitud(grande, mediana, pequeña, no trabajo)
•
Daños a otros edificios(identificación del lugar, y si fue afectado por agua, fuego, labores
propias del servicio, explosión, humo).
•
Cantidad de ocupantes(mayores y menores de edad).
•
Personas rescatadas y/o atendidas.
•
Número de Bomberos lesionados.
•
Seguros comprometidos(nombre aseguradora, número de póliza, fecha de termino vigencia)
•
Persona entrevistada(nombre, RUT, dirección)
Cabe considerar que cada llamado(o tipo de servicio prestado) tendrá un código correlativo que
debe estar compuesto por un número correlativo y el código correspondiente al grupo de servicio
al que pertenece(para efectos de informes históricos).
iv
Se debe considerar la posibilidad de realizar un formulario distinto para los casos de accidente
vehicular, que debe considerar los siguientes ítem:
•
Tipo de accidente vehicular(colisión, choque, volcamiento, atropello, caída, otro).
•
Breve descripción del trabajo realizado.
•
Datos de los vehículos involucrados(si los hay):número, marca, modelo, patente, color,
nombre y RUT del propietario y conductor, número de ocupantes, aseguradora, número de
póliza y fecha de término vigencia.
•
Número de personas fallecidas.
•
Persona entrevistada(nombre, RUT, dirección)
•
Personas rescatadas y/o atendidas.
iv
CAPITULO III. DISEÑO DE LA BASE DE DATOS
iv
3 Diseño de la Base de Datos
Una vez establecidos los requerimientos del sistema, tanto para el área administrativa como para
el área operativa, se procede al análisis de los datos, y el diseño de las tablas que contendrán la
información de la base de datos.
3.1
DISEÑO DE LA BASE DE DATOS PARA EL AREA ADMINISTRATIVA
Dada la cantidad de información que se maneja en el sistema, es necesario contar con una base
datos sólida y diseñada de tal manera que permita adaptarse a los requerimientos del usuario, sin
la necesidad de optar por la contratación de personal especialista en informática para hacer
cambios en el sistema, salvo situaciones excepcionales que impliquen un cambio en las políticas
de administración de los datos.
Al momento de diseñar la base de datos se tuvieron en cuenta dos factores fundamentales, que se
describen a continuación.
El primero de ellos tiene relación con uno de los objetivos propuesto al momento de diseñar el
proyecto, cual es el de dar satisfacción a la necesidad de las instituciones Bomberiles o Cuerpos
de Bomberos, de contar con sistemas computacionales que le permitieran manejar su información
de una manera más rápida, cómoda y segura.
El segundo factor tiene que ver con la autonomía de los Cuerpos de Bomberos. Si bien es cierto,
como se ha explicado anteriormente, estas instituciones están optando por normalizar(de manera
interna) la gran mayoría de sus procedimientos administrativos y operacionales, no es menos
iv
cierto que siguen siendo legalmente instituciones autónomas y que adoptan políticas propias. Por
esto el sistema y la base de datos debe ser capaz de adaptarse a los cambios internos de la
institución.
Con respecto al segundo factor, y para lograr clarificar el concepto, se grafica el siguiente
ejemplo.
“Supongamos que existe una tabla de la base de datos que almacene la información relativa al
personal(tabla PERSONAL), en la cual, uno de los campos definidos en el del cargo actual que
desempeña el bombero(campo Cargo). Por la estructura de la organización puede existir uno o
más bomberos que ostenten un mismo cargo o responsabilidad: por ejemplo, el cargo de
maquinista.
Lo anterior supone que si por razones de orden institucional, la nomenclatura del cargo
maquinista, es cambiada por la de conductor, en la tabla PERSONA, se deben recorrer todos los
registros existentes y editar aquellos que tienen en el campo Cargo, el dato maquinista,
cambiándolo por el de conductor.”
El ejemplo anterior, se traduce en un diseño poco eficiente desde el punto de vista de la
administración de los datos informáticos, por lo que se tuvo que pensar en una solución general,
que permita un buen mantenimiento de los datos, no solo para el contexto de este ejemplo, sino
también para todos aquellos problemas que puedan ocurrir al administrar los datos.
Como consecuencia de lo anterior, se diseño un módulo destinado al mantenimiento de los datos.
Este módulo de Mantenimiento, viene a ser la columna vertebral del sistema, ya que permite un
real y eficiente control en el ingreso y mantención de los datos fundamentales en la
administración de los registros del sistema.
El diseño de la base de datos se realizó en Microsoft Access 2000, y para tratar los datos que se
encuentran en esta base de datos, se utilizó la herramienta ODBC, disponible en el Panel de
Control del sistema operativo Microsoft Windows.
iv
3.2
DISEÑO DE LA BASE DE DATOS PARA EL AREA OPERATIVA Y LA
ADMINISTRACION DEL SISTEMA GEOGRAFICO(PLANO DE LA CIUDAD)
3.2.2.
PLANTEAMIENTO
Una parte de este proyecto consiste en que dada una emergencia se pueda obtener un apoyo para
la(s) Compañía(s) de Bomberos que acude(n) al lugar de la emergencia. Esto consiste en obtener
un “camino mínimo” desde el cuartel donde se encuentran las máquinas, hasta el lugar de la
emergencia.
Para dar satisfacción a lo anterior, se implementará el Algoritmo de Dijkstra que consiste en
calcular los costos mínimos
de un
nodo a
otro pertenecientes a un grafo. Para su
implementación se deben obtener los vértices que conforman el grafo y sus relaciones entre ellos
(arcos) con sus respectivos costos(pesos). Estos datos estarán almacenados en tablas de la base
de datos que conforma el sistema.
Una vez obtenido el “camino mínimo” deberá ser visualizado gráficamente en el plano de la
ciudad y mostrar información adicional como por ejemplo, caminos de costo mínimo y los
estados de los grifos que existen en el lugar de la emergencia.
Para poder implementar esta parte del sistema se deben tener en cuenta los conocimientos y
contenidos que se proceden a resumir a continuación.
3.2.3.
ESTRUCTURA DE LA BASE DE DATOS
Los detalles de las estructuras de las tablas y los campos definidos en cada una de ellas, se
pueden observar en el ANEXO A. DISEÑO DE TABLAS DE LA BASE DE DATOS.
iv
CAPITULO IV. DISEÑO DE LA INTERFAZ
GRAFICA Y PANTALLAS
iv
4 Diseño de la Interfaz Gráfica y Pantallas
En el desarrollo del presente capítulo se detallan los pasos adoptados para la implementación del
sistema, pasando por el diseño de pantallas y aspectos relevantes de la codificación.
En primer término, se recuerda que las tablas que contienen los datos del sistema, han sido
diseñadas y configuradas en Microsoft Access 2000.
Para la construcción del sistema se ha optado por el gestor de base de datos Microsoft Visual
Basic versión 6.0, Edición profesional.
El fundamento de las anteriores elecciones tiene que ver con:
•
Conocimiento previo de algunos aspectos generales de cada uno de los software.
•
Facilidad en la adaptación a los equipos computacionales disponibles en el Cuerpo de
Bomberos de Natales, y en la mayoría de sus similares del país.
•
Posibilidad de construir interfaces gráficas amigables y conocidas por la mayoría de los
usuarios.
•
Ahorro de tiempo y en la instrucción y/o capacitación, al adaptar otras plataformas de
trabajo, como por ejemplo LINUX, en lo que se refiere a la recuperación del sistema ante
una posible falla, que sea posible de solucionar a nivel usuario.
Para efectos prácticos de la construcción de la aplicación, se adoptó una estrategia que permitiera
utilizar el reciclaje de código, estableciéndose de esta manera la construcción en primer término
de un módulo completo(módulo MANTENIMIENTO), para posteriormente, y en base a este
iv
módulo, construir los siguientes, utilizando los procedimientos y funciones ya estudiados y
probados.
A continuación se muestran las imágenes que describen el diseño y presentación de cada una de
las pantallas y/o formularios que permiten la administración del sistema y de los datos que allí se
manejan, entregando de esta manera la estructura del sistema y los componentes de cada uno de
ellos.
4.1
MENU PERSONAL
La opción Ingreso/Mantención Datos Personales permite pueden administrar los datos
personales de los integrantes de la Institución(ver Figura 4.1).
Figura 4.1. Pantalla para ingreso y mantenimiento de datos
personales
iv
La opción Ingreso/Mantención de Cursos ofrece, a través de su diseño la administración de los
cursos que realiza el personal de bomberos(ver Figura 4.2).
Figura 4.2. Pantalla para el ingreso y mantención de cursos
del personal.
iv
La opción Hoja de Vida permite operar los datos relativos a la hoja de vida del personal, en lo
que se refiere a los premios y sanciones obtenidas(ver Figura 4.3).
Figura 4.3. Pantalla para el ingreso y mantención
de datos de la Hoja de Vida del Personal
La Cargos desempeñados, permite administrar los registros que tienen que ver con los cargos
que desempeña(o ha desempañado) cada bombero.(ver Figura 4.4).
Figura 4.4. Pantalla para el ingreso y mantención cargos y
actividades desarrolaladas por el personal
iv
4.2
MENU DOCUMENTOS
La opción de Ingreso/Mantención doctos. salidos. Salidos permite la administración de la
documentación que despecha la Institución a otros estamentos internos o también externos(ver
Figura 4.5).
Figura 4.5. Pantalla para el ingreso y
mantención de documentos salidos
iv
Por otra parte la opción Ingreso/Mantención doctos. llegados. Llegados permite la
manipulación de los datos relativos a los documentos que llegan desde otros estamentos internos
y/o externos, hacia la Secretaría General de la Institución(ver Figura 4.6)
Figura 4.6. Pantalla para el ingreso y mantención de
documentos llegados.
4.3
MENU INVENTARIO
La opción Ingreso/Mantenimiento de inventario permite la administración de los datos
relativos a las especies de inventario se manejan en una sola pantalla o formulario, a través de la
opción(ver Figura 4.7).
iv
Figura 4.7. Pantalla para el ingreso y mantención de especies
de inventario
4.4
MENU MANTENIMIENTO
La Figura 4.8 muestra la vista de una de las opciones del menú Mentenimiento.
Figura 4.8. Vista de una de las opciones
correspondientes al menú Mantenimiento
iv
A continuación se detallan los submenús de la opción Mantenimiento del sistema.
•
Opción Del Personal: Permite ingresar datos claves en la administración de registros que
tienen que ver con el personal de la Institución tales como nacionalidades, estados civiles,
nivel de estudio, calidad de ingreso, cargos, grupo de sangre, cursos(organizaciones de
capacitación, nombre de cursos, estados de aprobación), premios/sanciones.
•
Opción Emergencias: Permite ingresar datos claves en la administración de registros que
tienen que ver con la información que se maneja en alguna emergencia, tales como servicios,
categorías de siniestros, daños, magnitud, persona(actividad que desarrolla en la emergencia),
instituciones de apoyo, accidentes, tipos de llamados.
•
Opción Inventario: Permite ingresar datos claves en la administración de registros que tienen
que ver con la información que se maneja para las especies del inventario. Básicamente
permite en el ingreso de los nombres de los grupos de activos y los nombres de los tipos de
dependencias existentes.
•
Opción Documentos: Permite ingresar datos claves en la administración de registros que
tienen que ver con la información que se maneja para los documentos, específicamente la
descripción de los tipos de documentos.
•
Opción Compañías/Brigadas: permite en ingreso de los datos de las diferentes compañías o
brigadas que forman parte de la Institución.
•
Opción Máquinas: permite en ingreso de los datos de las diferentes máquinas que forman
parte de la Institución y que están a cargo de alguna compañía o brigada.
4.5
MENU SERVICIOS
iv
La Figura 4.9 muestra el formulario de presentación de los servicios en una grilla de datos, desde
donde se puede seleccionar uno de ellos, para posteriormente editar o borrar el registro de esa
emergencia(o servicio especial) y todos los registros asociados.
Figura 4.9. Vista de la grilla de datos de servicios
registrados en el sistema y botones de opción para
ingresar, editar y borrar.
iv
La Figura 4.10 muestra el formulario principal para el ingreso y edición de datos relacionados
con la emergencia o servicio especial que se esté ingresando.
Figura 4.10. Pantalla para el ingreso y edición de datos de servicios
iv
CAPITULO V. TRABAJANDO CON ARCVIEW
iv
5 Trabajando con ArcView 3.1
El GIS ArcView es un potente software de Sistema de Información Geográfica(GIS) y trazado
de mapas para computadores personales. Brinda la capacidad de visualizar, explorar, consultar y
analizar datos en forma espacial.
5.1
¿QUÉ SE PUDE HACER CON ARCVIEW?
Este programa trae un conjunto útil de datos preparados para utilizarse de inmediato, a fin de
crear con ellos centenares de mapas diferentes. Pidiéndolos a ESRI, a otras organizaciones y a
través de Internet se consiguen datos adicionales. Es posible emplear ArcView para acceder a
datos almacenados en el formato de archivos de formas del programa, en el formato de
ARC/INFO y en muchos otros. También se puede servir de ArcView
para crear datos
geográficos propios.
Una vez que se haya trazado el mapa deseado, resulta fácil añadirle datos en forma de tablas,
tales como archivos de dBase y los suministros por servidores de bases de datos, a fin de que se
los pueda visualizar, consultar, resumir y organizar geográficamente.
5.2
COMENZANDO A TRABAJAR CON ARCVIEW
Se creará un proyecto(nom_proyecto.apr), el cual contendrá todas las vistas, tablas, gráficos
estadísticos, las composiciones de mapa y los scripts que se utilizan para la determinada
aplicación.
iv
Una vista es un mapa interactivo que permite visualizar, explorar, consultar y analizar los datos
geográficos en ArcView. Una vista se compone de capas de información geográfica acerca de un
área o lugar, las cuales se llaman “temas”.
En la tabla de materias de una vista se enumeran todos los temas que esta contiene. La tabla de
materias muestra también los símbolos empleados para trazar los elementos en cada tema.
La casilla de verificación junto a cada tema indica si está o no “marcado”, es decir, si se
encuentra o no trazado en el mapa. También importa el orden en que se enumeran los temas en la
tabla de materias. Los que figuran más arriba en la tabla son trazados por encima de los que
aparecen debajo.
5.3
¿SE GUARDAN CON EL PROYECTO LOS DATOS ESPACIALES QUE SE
HAN AÑADIDO AL MAPA?
Un archivo de proyecto de ArcView no contiene los datos espaciales y datos en forma de tablas
que uno añade a los mapas. En cambio, almacena referencias al lugar donde se conservan las
fuentes de los datos en disco. De esta forma, pueden emplearse los mismos datos en una serie de
proyectos sin duplicación y, si los datos cambian, las actualizaciones se reflejarán en todos los
proyectos donde sean utilizados esos datos.
Cuando se abre un proyecto existente, ArcView verifica todas las referencias a datos espaciales y
datos en forma de tablas que contiene. Si ArcView no encuentra alguno de los datos, presentará
un cuadro de dialogo donde le preguntará dónde están los que no puede localizar. Este proceso se
llama reparación de proyectos.
5.4
CARGAR DATOS EN FORMA DE TABLAS DESDE BASES DE DATOS
Utilizando la característica de conexión SQL de Arc View, es posible conectar con un servidor de
bases de datos y ejecutar una consulta SQL para recuperar registros del mismo. Los registros a
los que acceda se convierten en una tabla dentro del proyecto.
iv
Para cargar datos mediante un conexión con una base de datos
1.
Se activa la ventana del proyecto
2.
Desde el menú proyecto, se elige Conectar SQL
3.
En el cuadro de diálogo que aparece, la lista conexión muestra todas las conexiones con
bases de datos que están disponibles. Se elija la base de datos cuyos datos desea cargar en
ArcView y se pulsa el botón Conectar. Esto permite iniciar la conexión con la base de datos
seleccionada.
4.
La lista tablas muestra todas la tablas disponibles en la base de datos con la que se está
conectado. Se puede hacer clic en una tabla para que se enumeren las columnas (campos)
que contiene. Se utilizan las listas tablas y columnas para componer una consulta SQL,
especificando qué columnas de qué tablas se desea traer a ArcView. Al hacer doble clic en el
nombre de una columna, se añade al cuadro “Select:” , mientras que si se hace doble clic en
el nombre de una tabla, se añade al cuadro “from:” .
5.
Si se desea que los registros que se van a recuperar se limiten a un subconjunto específico, se
teclea una expresión de selección en el cuadro “where”.
6.
En el cuadro Tabla resultado, se especifica un nombre para la tabla que creará ArcView a fin
de almacenar allí estos datos.
7.
5.5
Se pulse el botón consulta
PRESENTACION DE LOS VERTICES DE CALLES GRAFICADOS EN EL
MAPA(ANTES Y DESPUES DE DIJSKTRA) PARA EL SISTEMA SICAB
Después de la ejecución del algoritmo de Dijkstra sobre los datos de los vértices que se
encuentran en la base de datos, la aplicación es capaz de cargar un plano, abriendo la Aplicación
GIS ArcView.
iv
La visualización del plano de la ciudad en la pantalla del equipo en la que se encuentra el sistema
SICAB, constituye una de las principales salidas del sistema, transformándose desde ese
momento en la principal herramienta de apoyo a las operaciones de emergencia o servicios
especiales en los que participan las unidades operativas(material motorizado y humano) del
Cuerpo de Bomberos.
Como se puede ver en la Figura 5.1, los vértices(correspondientes a las intersecciones de calles),
se muestran con círculos de color azul, antes de la ejecución de Dijsktra(Las estrellas rojas,
indican la ubicación de las Compañías).
Figura 5.1. Vista de una sección del plano de la ciudad de Natales, antes del
cálculo del Algoritmo de Dijsktra realizado por SICAB
iv
Después de ingresadas las direcciones(calle de la emergencia y la intersección más cercana), la
presentación del mapa en ArcView cambia(como se aprecia en la Figura 5.2), marcando los
vértices que forman el camino mínimo con color rojo.
Figura 5.2. Vista de una sección del plano de la ciudad de Natales, después del
cálculo del Algoritmo de Dijsktra ejecutado por SICAB
De esta manera, el operador de la central de alarmas, puede indicar al personal de servicio que
atiende la emergencia, que camino tomar para llegar más rápido a ella.
Datos suficientes y necesarios para el funcionamiento del cálculo del camino mínimo realizado
por la implementación del Algoritmo de Dijkstra, son la calle de la emergencia y su intersección
más próxima. SICAB es capaz de determinar si las calles ingresadas constituyen o no una
intersección en el plano de la ciudad. Realizada esta verificación y una vez que se ha determinado
iv
que si constituyen una intersección, Dijkstra calcula el camino mínimo para que el operador(a)
despache a las unidades. En caso que la verificación arroje un resultado negativo, se le comunica
al usuario mediante un mensaje de información, para que este determine los pasos a seguir,
aplicando los criterios relacionados con verificación y/o confirmación de llamados por posibles
falsas alarmas.
iv
CAPITULO VI. CONCLUSIONES
iv
6 Conclusiones
En el presente trabajo se han descrito los principales pasos que han permitido obtener como
resultado el “Sistema de Información para Central de Alarmas de Bomberos, SICAB”.
Con lo anterior se a logrado obtener un prototipo de sistema que puede ser aplicado a cualquier
Cuerpo de Bomberos del país, con una funcionalidad que nace de la base de una detallada toma
de requerimientos y un cuidadoso análisis y diseño, basados en las estructuras funcionales
administrativas y operativas de una Institución que por años se ha mantenido en una constante
evolución profesional y técnica.
Uno de los resultados destacables, es el de lograr hacer trabajar a dos aplicaciones distintas(la
aplicación administrativa creada en Microsoft Visual Basic 6.0 y el plano que se visualiza en
ArcView), sobre una misma base de datos creada en Microsoft Access 2000.
Además, en el desarrollo de la presente documentación se han establecido las bases para lograr
complementar o automatizar aún más el sistema SICAB, sobre la base de que se trata de una
aplicación que, conforme al avance y desarrollo de los procedimientos, técnicas y trabajos
realizados por las Instituciones Bomberiles, debe irse adaptando para ser cada vez más eficiente.
Es así como podemos pensar en una ampliación del sistema que permita a los usuarios, ir
actualizando los planos, agregando nuevas poblaciones, o cambiar direcciones de calles, opciones
que el actual prototipo no presenta, pero que en base al diseño del sistema, son posibles de
realizar, sirviendo incluso como nuevos desafíos para futuros alumnos memoristas de las carreras
que tienen relación con el área de la computación e informática de la Universidad de Magallanes
iv
Desde el punto de vista de las técnicas relacionadas con el desarrollo de Sistemas de Información
Administrativa se pueden destacar los siguientes aspectos:
•
En el desarrollo del código fuente del programa se utilizaron los elementos necesarios de tal
manera de hacer fácil y entendible su comprensión a programadores que quieran realizar
modificaciones y/o actualizar el sistema.
•
PORTABILIDAD Y REUSABILIDAD: El sistema es absolutamente modificable. Como se
sabe, esta es una característica que hace que sistema sea portable. Además el diseño del
sistema hace que tanto su código fuente, como también sus formularios y pantallas sean
reutilizadas para futuras modificaciones, incluso para estructurar nuevas aplicaciones que
se relacionen con Sistemas de Información Administrativa o administración de base de
datos relacionandas con sistemas gráficos.
•
Se han establecido criterios para lograr que el sistema sea inmune a algunos errores
comunes de utilización por parte de los usuarios. También se han establecido las rutinas de
validación de datos necesarias para evitar la inconsistencia en la Base de Datos.
Es importante destacar que aún cuando el sistema fue diseñado para una institución específica, es
posible utilizarlo para otras instituciones u organismos que requieren de apoyos para el
desplazamiento de sus medios o la toma de decisiones, como por ejemplo Policía, Servicios de
Urgencia, Radio taxis, Dirección de Tránsito, Oficinas Provinciales o Comunales de Emergencia,
entre otras.
iv
ANEXOS
iv
ANEXO A. DESCRIPCION DE TABLAS Y DATOS DE LA BASE
DE DATOS SICAB DISEÑADA EN MICROSOFT ACCESS 2000
Tabla ACCIDENTE
Almacena los registros de aquellas situaciones que provocan lesiones, y que son informadas y/o
confirmadas al personal de bomberos, y que pueda sufrir tanto personal de bomberos o civiles.
Nombre del campo
CodAcci
Acci
Tipo de Dato
Numérico
Texto
Descripción
Código de la lesión
Descripción de la lesión (VOLCAMIENTO, ATROPELLO,
CHOQUE, CAIDA DE ALTURA, CAIDA DE VEHICULO
EN MOVIMIENTO, SUMERSION, QUEMADURA,
ELECTROCUCION, etc.)
Tabla ACTIVIDAD
Almacena la información correspondiente a cada una de las funciones que el personal ejerza
dentro de la Institución, como por ejemplo, cargos de Oficial de Cuerpo o Compañía, integrante
del Depto. De Estudios Técnicos, comisiones de servicio especiales, etc.
Nombre del campo
Run
FecIni
FecTer
CodCargo
Tipo de Dato
Texto
Texto
Texto
Numérico
Obs
CodCia
Texto
Numérico
Descripción
Rol Único Nacional
Fecha de inicio de la actividad
Fecha de término de la actividad
Código que identifica el tipo de cargo desempeñado entre
las fechas indicadas anteriormente
Si acaso corresponde alguna, producto de su desempeño
Código de la compañía a la que pertenece el bombero
iv
Tabla APOYO
Guarda la información referente aquellas instituciones concurrieron a la emergencia, y que
formaron parte del equipo que actuó para solucionarla.
Nombre del campo
Folio
Idservicio
Idllamado
CodInst
Acargo
Cargo
Obs
Tipo de Dato
Numérico
Numérico
Numérico
Numérico
Texto
Texto
Texto
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Identifica a la Institución que concurrió al lugar
Nombre de la persona que estuvo a cargo de la Institución
Cargo o puesto que desempeña la persona en la Institución
Si son necesarias de acuerdo al tipo de apoyo o actividad que
desempeñaron
Tabla APROV
Encargada de almacenar los registros correspondientes a los códigos de situación de
aprobación(APROBADO, REPROBADO, EXAMEN PENDIENTE, ETC.) del personal que
realiza cursos, y las correspondientes descripciones de esos códigos.
Nombre del campo
CodAprov
Aprov
Tipo de Dato
Numérico
Texto
Descripción
Código de aprobación del curso para un bombero
Descripción de la situación de aprobación, correspondiente al
código anterior
iv
Tabla AUTOS
Es la encargada de llevar los registros de los vehículos involucrados en emergencias de
accidentes vehiculares y a los que se solicita la concurrencia de bomberos.
Nombre del campo
Folio
Idservicio
idllamado
Marca
Modelo
Patente
Color
CIProp
NomProp
CICond
NomCond
NroOcup
NomAseg
NroPol
FecTerVig
Tipo de Dato
Numérico
Numérico
Numérico
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Texto
Numérico
Texto
Texto
Texto
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Marca del vehículo
Modelo del vehículo
Patente del vehículo
Color de la carrocería
RUN del propietario
Nombre del propietario
RUN del Conductor
Nombre del conductor
Número de ocupantes del móvil
Nombre de la compañía de seguros
Número de la póliza
Fecha de término de vigencia de la póliza
Tabla CALIDAD
Almacena los códigos que establecen la calidad de los integrantes de la Institución. Estas
calidades pueden ser: ACTIVO, COOPERADOR, HONORARIO DE CUERPO, HONORARIO
DE COMPAÑÍA, ETC., permitiendo ingresar otras calidades de integrantes, que puedan irse
generando según sea el desarrollo de la Institución.
Nombre del campo
CodCali
Cali
Tipo de Dato
Numérico
Texto
Descripción
Código para cada una de las calidades
Nombre de la calidad correspondiente al código.
iv
Tabla CARGOS
Registra los códigos y descripciones correspondientes de cada uno de los cargos o actividades
que haya desempeñado el personal.
Nombre del campo
CodCargo
Cargo
Tipo de Dato
Numérico
Texto
Descripción
Código del cargo o actividad que desempeña el personal
Descripción del cargo o actividad asociada al código antes
descrito
Tabla CATEG
La tabla contiene los códigos y descripciones de las posibles categorías atribuibles a las
emergencias. Estas pueden ser NATURALES, INTENCIONALES, ACCIDENTALES, etc.
Nombre del campo
CodCateg
Categ
Tipo de Dato
Numérico
Texto
Descripción
Código de la categoría
Descripción de la categoría asociada al código
Tabla CIA
Esta tabla guarda la información que identifica a cada una de las Compañías, permitiendo
establecer para este módulo en particular la Unidad a la que pertenece un integrante de la
Institución. Además sirve para indicar(en el módulo inventario) a que unidad operativa pertenece
una especie determinada.
Nombre del campo
Cia
CodCia
NomCia
DirCia
FonoCia
Bomba
Tipo de Dato
Numerico
Texto
Texto
Texto
Texto
Texto
Descripción
Almacena el código de Compañía.
Identificación convencional de la Compañía
Almacena el nombre de la Compañía.
Almacena la dirección de la Compañía.
Almacena el(los) teléfonos de la Compañía
Almacena el nombre distintivo de la Compañía
iv
Tabla CURSOS
Lleva los registros correspondientes a los Cursos que haya realizado el personal, tanto por
entidades Bomberiles, como por organizaciones externas.
Nombre del campo
Run
FecIni
FecTer
CodCur
CodAprov
Tipo de Dato
Texto
Texto
Texto
Numérico
Numérico
Obs
Texto
Cia
Texto
Descripción
Rol Único Nacional
Fecha de inicio del curso
Fecha de término del curso.
Código del curso.
Código que identifica la situación de aprobación del
participante
Si acaso corresponde alguna, producto de su participación
en dicho curso
Código que identifica la compañía a la que pertenece el
bombero
Tabla CURSOS1
Esta tabla es la encargada de almacenar los registros correspondientes a los nombres de cursos
que se realizan en institución, la organización que imparte el curso, la que está referenciada por el
código de la organización
Nombre del campo
CodCur
NomCur
CodOrg
Tipo de Dato
Numérico
Texto
Numérico
Descripción
Código del curso o taller realizado
Nombre que describe el curso o taller realizado
Código de la institución que imparte el curso
Tabla DANOS
Contiene los códigos y descripciones de los daños estimados a la estructura siniestrada.
Nombre del campo
CodDano
Dano
Tipo de Dato
Numérico
Texto
Descripción
Código del daño
Descripción del daño asociado al código anterior(MENORES,
MADIANA CONSIDERACIÓN, MAYORES, TOTALES)
iv
EMERGENCIAS1
La tabla lleva los registros de datos básicos para los distintos tipos de llamados.
Nombre del campo
Folio
servicio
llamado
fecha_ini
hora_ini
fecha_term
hora_term
Calle
Nro
inters_calle
Tipo de Dato
Numérico
Numérico
Numérico
Texto
Texto
Texto
Texto
Numérico
Texto
Numerico
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Fecha de inicio del servicio
Hora de inicio del servicio
Fecha de término del servicio.
Hora de término del servicio
Código de la calle de emergencia
Numero que identifica la casa de la calle de la emergencia
Código que identifica la calle de intersección más próxima
EMERGENCIAS2
La tabla lleva los registros de datos básicos para los distintos tipos de llamados.
Nombre del campo
Folio
idservicio
idllamado
Origen
Causa
CodCateg
CodMagni
CodDano
Tipo de Dato
Numérico
Numérico
Numérico
Texto
Texto
Numérico
Numérico
Numérico
Porcen
NomAseg
NroPol
FecTerVig
UltUni
TotBomb
OcupMay
OcupMen
PerAten
Numérico
Texto
Texto
Texto
Texto
Numérico
Numérico
Numérico
Numérico
PerFall
CodAcci
Fono
Obs
Numérico
Numérico
Texto
Texto
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Descripción del probable origen del siniestro
Descripción de la probable causa del siniestro
Código que identifica la categoría probable del siniestro
Código que identifica la magnitud de la emergencia
Código que identifica los daños estimados a la estructura
siniestrada
Estimación del porcentaje de daño y/o destrucción
Nombre de la entidad que asegura la estructura
Número de la póliza
Fecha del término de vigencia de la póliza
Ultima unidad móvil que se retiró del lugar
Total de Bomberos que asistieron
Número de ocupantes mayores de edad
Número de ocupantes menores de edad
Personas atendidas en el lugar por parte de personal de la
Institución
Personas fallecidas en el lugar
Código que identifica el tipo de accidente, si lo hubo.
Número de teléfono desde donde se dio aviso de la emergencia
Si corresponden al llamado
iv
Tabla DATPEREMER
Guarda los registros de personas que intervinieron en algún llamado, realizando alguna actividad.
Nombre del campo
Folio
Servicio
Llamado
CodActiv
NomPer
Run
Tipo de Dato
Numérico
Numérico
Numérico
Numérico
Texto
Texto
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Código de la actividad que desarrolla la persona en el llamado
Nombre que identifica a la persona
Rol Único Nacional de la persona
Tabla DEPEND
Encargada de llevar los registros de los códigos y nombre asociados a cada una de las
dependencias que existen en los Cuarteles(incluidas las máquinas).
Nombre del campo
CodDep
Dep
Tipo de Dato
Numérico
Texto
Descripción
Código de la dependencia
Nombre que identifica a la dependencia
Tabla DOCLLEG
Almacena los datos correspondientes a la documentación llegada al Cuerpo de Bomberos, desde
otras Instituciones o personas.
Nombre del campo
CodDoc
Tipo de Dato
Texto
CodTipo
NroDoc
FecDoc
Numérico
Texto
Texto
FecRecep
Proced
Cont
Obs
Texto
Texto
Texto
Texto
Descripción
Identifica a un documento en particular, dado por el ultimo
correlativo de su tipo.
Identifica el tipo de documento que se esta recibiendo
El número que identifica al documento
Fecha de emisión del documento(la que viene impresa en el
mismo).
Fecha en que se recibe el documento
Breve descripción de la persona o institución que envía el docto
Breve descripción del contenido del documento
Si corresponde, conforme al documento que se emite.
iv
Tabla DOCSAL
Tabla encargada de almacenar los datos correspondientes a la documentación salida desde el
Cuerpo de Bomberos hacia otras Instituciones o personas.
Nombre del campo
CodDoc
Tipo de Dato
Texto
CodTipo
FecEmi
Dest
Cont
Obs
Numérico
Texto
Texto
Texto
Texto
Descripción
Identifica a un documento en particular, dado por el ultimo
correlativo de su tipo.
Identifica el tipo de documento que se está despachando
Corresponde a la fecha de emisión del documento
A que Institución o persona va dirigida
Breve descripción del contenido del documento
Si corresponde, conforme al documento que se emite.
iv
Tabla ESPECIE
Almacena la información que identifica a cada especie ingresada en el inventario.
Nombre del campo
CodEsp
Tipo de Dato
Numérico
Cant
NomEsp
ValMone
Obs
Numérico
Texto
Numérico
Texto
CodDep
CodInv
Numérico
Texto
FecAlt
CodDocAlt
Texto
Texto
FecBaj
Texto
CodDocBaj
Texto
Est
Texto
Cia
CodGrup
Texto
Numérico
Descripción
Es el número con el que se identifica a las diferentes especies, el
cual debe estar dado por el campo Correl de la tabla
GRUPACTIV
Cantidad de elementos que corresponden a la especie
Nombre que identifica a la especie
Valor monetario asignado a la especie
Si corresponden, debido a la naturaleza, estado o características
de la especie
Identifica la dependencia a la que está asignada la especie
Identifica si corresponde a un inventario de tipo OPERATIVO o
ADMINISTRATIVO
Fecha en que la especie es ingresada oficialmente al inventario
Identifica al documento que oficializa el ingreso de la especie al
inventario
Fecha en que la especie es dada de baja oficialmente del
inventario
Identifica al documento que oficializa la dada de baja de la
especie al inventario
Identifica si la especie está en BUENAS, MALAS O
REGULARES condiciones
Identifica la compañía a la que pertenece la especie
Código que identifica al grupo de activos al que pertenece
Tabla ESTCIVIL
Guarda los códigos que identifican cada uno de los posibles estados civiles que tiene el personal.
Estos pueden ser: SOLTERO(A), CASADO(A), SEPARADO(A), VIUDO(A), otros que puedan
ser ingresados al sistema.
Nombre del campo
CodEstCiv
EstCiv
Tipo de Dato
Numérico
Texto
Descripción
Código para cada uno de los estados civiles
Descripción del estado civil correspondiente al código
iv
Tabla GRUPACTIV
Es la tabla encargada de guardar los registros correspondientes a los diferentes grupos activos,
dentro de los cuales se pueden clasificar cada una de las diferentes especies inventariadas.
Nombre del campo
CodGrup
Grup
Tipo de Dato
Numérico
Texto
Descripción
Código del grupo de activos
Nombre correspondiente al grupo de activos
Tabla HOJAVIDA
Leva el(los) registro(s) por el cual es posible mantener la trayectoria del personal, en cuanto a los
premios y/o sanciones que este recibe en el transcurso de su permanencia como bombero.
Nombre del campo
CodDoc
Tipo de Dato
Texto
FecPreSan
Motivo
Texto
Texto
Run
CodPreSan
Cia
Texto
Numérico
Texto
Descripción
Identifica el tipo de documento que respalda o hace oficial el
premio a sanción. Este campo se refiere a una tabla del módulo
DOCUMENTOS, que se describirá más adelante
Fecha en que recibe el premio o sanción
Descripción del motivo por el cual se hace acreedor al premio o
sanción
Rol Único Nacional
identifica el código del premio o sanción
Identifica el código de la compañía
Tabla INST
Encargada de llevar los registros correspondientes a los códigos y nombres de las instituciones
que eventualmente prestan apoyo o trabajan en conjunto con personal bomberil.
Nombre del campo
CodInst
Inst
Tipo de Dato
Numérico
Texto
Descripción
Código de la Institución
Nombre de la Institución
iv
Tabla LLAMADO
Guarda información relativa al tipo de llamado, asociada a una clasificación de servicio. Por
ejemplo, para los tipo de servicios de EMERGENCIAS hay llamados de RESCATES,
INCENDIOS, MATERIALES PELIGROSOS, EMENACIONES DE GASES, etc.
Nombre del campo
CodServ
CodLlam
Llam
Tipo de Dato
Numérico
Numérico
Texto
Ultimo
Numérico
Descripción
Identifica el código del servicio
Código del tipo de llamado
Descripción del tipo de llamado, conforme a la clasificación del
tipo de servicio
Corresponde al último llamado que se ha recibido de esa
clasificación
Tabla MAGNI
Contiene los códigos y descripciones de las posibles magnitudes que alcancen las emergencias.
Nombre del campo
CodMagni
Magni
Tipo de Dato
Numérico
Texto
Descripción
Código de la magnitud
Descripción de la magnitud asociada al código(PAQUEÑA,
MEDIANA CONSIDERACIÓN, GRANDE, OTRA)
Tabla MAQLLAM
Guarda los registros con la clave de llamado y las unidades que asistieron a ese llamado.
Nombre del campo
Folio
servicio
llamado
CodMaq
Tipo de Dato
Numérico
Numérico
Numérico
Numérico
Descripción
Corresponde al último llamado por subtipo de servicio
Tipo de servicio realizado
Sub tipo de servicio realizado
Código de la máquina que asistió al llamado
iv
Tabla MAQUINA
Guarda los registros con los datos de las máquinas existentes en la institución, y su código
correspondiente.
Nombre del campo
Cia
Tipo de Dato
Texto
NomMaq
CodMaq
Id
Disponible
Texto
Numérico
Texto
Sí/No
Descripción
Código que identifica a la compañía a la cual esta destinada la
máquina
Nombre de fábrica de la máquina
Código que identifica a la máquina
Nomenclatura de identificación
Estado de disponibilidad de la máquina
Tabla NACIÓN
Encargada de guardar los códigos que identifican la nacionalidad de origen de cada Bombero.
Nombre del campo
CodNac
Nac
Tipo de Dato
Numérico
Texto
Descripción
Código para cada una de las nacionalidades
Descripción de la nacionalidad correspondiente al código
Tabla NIVELESCOLAR
Esta tabla es la encargada de almacenar la información relativa a los diferentes niveles escolares
que puede tener un integrante de la institución, y que se identifica con su código correspondiente.
Nombre del campo
CodNivEsc
Nivel
Tipo de Dato
Numérico
Texto
Descripción
Código que identifica al nivel escolar respectivo
Descripción del nivel escolar correspondiente
Tabla ORG
Lleva los registros de las organizaciones han prestado o están prestando servicios de capacitación
a la institución.
Nombre del campo
CodOrg
Org
Tipo de Dato
Numérico
Texto
Descripción
Código de la organización que imparte el curso
Nombre de la organización asociada al código anterior
iv
Tabla OTROEDIF
Cumple la función de almacenar los registros relacionados con los daños que se pudieron
ocasionar a otras estructuras o edificios, y que no son consecuencia directa del siniestro.
Nombre del campo
Folio
Idservicio
Idllamada
Dir
Porcen
CodDano
Tipo de Dato
Numérico
Numérico
Numérico
Texto
Numérico
Numérico
Obs
Texto
Descripción
Identifica al ultimo llamado dentro de tipo de servicio
Identifica el tipo de servicio al que pertenece el llamado
Identifica al tipo de llamado.
Dirección de la estructura afectada
Estimación del porcentaje de daño y/o destrucción
Código que identifica los daños estimados a la estructura
siniestrada
Observaciones adicionales que correspondan
Tabla PERSONA
Almacena los registros de los códigos de actividad y sus correspondientes descripciones
asociadas, y que tienen relación con aquella función que haya realizado en el lugar del siniestro.
Nombre del campo
CodActiv
Activ
Tipo de Dato
Numérico
Texto
Descripción
Código de la actividad que realizó la persona
Descripción de la actividad que le tocó realizar, o que se le
realizó en la emergencia, como por ejemplo: BOMBERO A
CARGO, BOMBERO ACCIDENTADO(NO ATENDIDO,
ATENDIDO POR BOMBEROS, ATENDIDO POR OTRA
INSTITUCION), etc.
iv
Tabla PERSONAL
Es la encargada de almacenar todas los datos personales de los integrantes de la Institución.
Nombre del campo
RegGral
Tipo de Dato
Numérico
NroFolio
Numérico
Cia
ApePat
ApeMat
Nombres
CodCali
Texto
Texto
Texto
Texto
Numérico
FecIng
CodNivEsc
CodNac
Profesion
Texto
Numérico
Numérico
Texto
FecNac
LugNac
DirDom
FonoDom
Run
CodEstCiv
RegCia
Texto
Texto
Texto
Texto
Texto
Numérico
Numérico
CodSangre
LugTrab
DirTrab
FonoTrab
FecBaj
CauBaja
ServMil
CodCargo
ObsMed
Numérico
Texto
Texto
Texto
Texto
Texto
Sí/No
Numérico
Texto
Descripción
Este campo guarda la información correspondiente al número de
registro general que el Bombero tiene en dicho libro
Correspondiente al número de folio con el que se identifica a la
hoja del Registro General en el que se encuentran los datos
personales
Código con el que se identifica la compañía de pertenencia
Apellido paterno
Apellido materno
Nombre(s).
Código con el que se identifica la calidad de socio dentro de la
Institución
Fecha de ingreso a la Compañía
Código con el que se identifica el nivel de escolaridad
Código con el que se identifica la nacionalidad
Descripción de la profesión o actividad que ejerce en su vida
laboral particular
Fecha de nacimiento
Lugar de nacimiento
Dirección del domicilio particular
Teléfono(s) particular. Debe incluir los códigos de área.
Rol Único Nacional
Código que identifica el estado civil del Bombero
Corresponde al número de registro de Compañía que tiene dentro
de la misma
Código que identifica el grupo de sangre
Descripción del lugar donde desempeña sus actividades laborales
Dirección laboral
Teléfono(s) del lugar de trabajo
Fecha de baja de la Institución
Breve descripción por la cual se le otorgó la baja
Si realizó o no el servicio militar
Código del cargo actual
Observaciones médicas del bombero(enfermedades,
medicamentos contraindicados.
iv
Tabla PRESAN
Esta tabla guarda los códigos y descripciones correspondientes de cada uno de los premios y
sanciones a que se hace acreedor el personal. Para ello se establecen los siguientes campos:
Nombre del campo
CodPreSan
PreSan
Inicial
Tipo de Dato
Numérico
Texto
Texto
Descripción
Código del premio a sanción
Descripción correspondiente al premio a sanción
Identifica si el registro que se asocia a CodPreSan, corresponde a
un premio o una sanción.
Tabla SANGRE
La tabla SANGRE es la encargada de guardar la información correspondiente al grupo de sangre
de cada uno de los integrantes de la Institución.
Nombre del campo
CodSangre
Grupo
Tipo de Dato
Numérico
Texto
Descripción
Código del grupo de sangre
Descripción del grupo de sangre correspondiente al código
Tabla SERVICIO
Almacena la información correspondiente a los códigos de servicios y cada una de sus
descripciones. Estas pueden ser: EMEREGENCIAS, ESPECIALES, VISITAS/INSPECCIONES,
etc.
Nombre del campo
CodServ
Serv
Tipo de Dato
Numérico
Texto
Descripción
Código del servicio.
Descripción del Tipo de Servicio
Tabla SERVMIL
Encargada de guardar los registros correspondientes a información concerniente al servicio
militar del personal, en caso de que este lo haya realizado.
Nombre del campo
Run
Ano
Unidad
Tipo de Dato
Texto
Numérico
Texto
Descripción
Rol Único Nacional
Corresponde al año en que realizó el servicio militar
Unidad militar en que sirvió
iv
Tabla TIPDOCTO
Esta tabla cumple la función de guardar la información relativa a los códigos y descripciones de
cada uno de los tipo de documentos ingresados.
Nombre del campo
CodTipo
NomTipo
Tipo de Dato
Numérico
Texto
CorrelSal
CorrelLleg
Numérico
Numérico
Descripción
Código del tipo de documento
Descripción del nombre que recibe el tipo de
documento(CIRCULAR, ORDEN DEL DIA, OFICIO
CONDUCTOR, SOLICITUD, CERTIFICADO, otros definidos
por el usuario.)
Ultimo correlativo utilizado para los documentos salidos
Ultimo correlativo utilizado para los documentos llegados
Tabla ULTIMOINV
Almacena un solo registro, que le da el orden a la ultima especie de inventario ingresada al
sistema.
Nombre del campo
Ultimo
Tipo de Dato
Numérico
Descripción
Ultima especie ingresada al inventario de la institución
Tabla OTROSERVICIO
Almacena los registros correspondientes a aquellas actividades Bomberiles o servicios que no
corresponden a emergencias
Nombre del campo
Folio
Tipo de Dato
Numerico
idservicio
idllamada
FecIni
HrIni
FecTer
HrTer
UltUni
TotBomb
Obs
Lugar
Descrip
Numerico
Numérico
Texto
Texto
Texto
Texto
Numérico
Numérico
Texto
Texto
Texto
Descripción
Corresponde al ultimo llamado del tipo de servicio
correspondiente(ultimo correlativo por subtipo)
Corresponde al código del servicio
Corresponde al código de tipo de llamado
Fecha inicio del llamado
Hora inicio del llamado
Fecha término del llamado
Hora término del llamado
Código de la última máquina que se retiro del lugar
Total de Bomberos que asistieron
Si corresponden al llamado
Lugar o Institución a quien se realizó la emergencia
Descripción del trabajo realizado
iv
Tabla CALLES
Tabla que se encarga de almacenar los registros de calles con sus respectivos códigos.
Nombre del campo
Codigo
Nombre
Tipo de Dato
Numérico
Texto
Descripción
Código que identifica a una calle
Nombre de la calle
Tabla VERTICES
Tabla que almacena los registros de los pares de calle que forman intersecciones, es decir, que se
cortan una a la otra en algún punto de plano.
Nombre del campo
Codigo
Inters1
Tipo de Dato
Numérico
Numérico
Inters2
PosX
Numérico
Numérico
PosY
Numérico
Descripción
Código identificador de un vértice(intersección de calles).
Identificador de una calle (código de una calle que en
conjunto con otro darán la intersección formando el vértice.
Inters1∩Inters2 = Vértice)
Identificador de una calle(ídem al campo anterior)
Almacena posición x de un punto en un plano de
coordenadas
Almacena posición y de un punto en un plano de
coordenadas
Tabla VERTCIAS
Tabla que almacena los vértices de salida(o intersecciones de salida) de los carros de una
Compañía determinada.
Nombre del campo
Codigo
Tipo de Dato
Numérico
Inters1
Inters2
CodCia
Numérico
Numérico
Numérico
Descripción
Almacena el vértice de las salidas que pueden tener las
compañías de Bomberos.
Primera calle que conforma la intersección
Segunda calle que conforma la intersección
Almacena el código de la compañía
iv
Tabla ARCO
Almacena los datos del arco existente entre dos vértices.
Nombre del campo
Vértice1
Vértice2
Cabeza1
Tipo de Dato
Numérico
Numérico
lógico
Cabeza2
lógico
Peso
numérico
Descripción
Identifica primer vértice del arco
Identifica segundo vértice del arco
Identifica si vertice1 es cabeza del arco formado por los
vértices( V1 ← V2)
Identifica si vertice2 es la cabeza del arco formado por los
vértices( V1 → V2)
NOTA: Con los campos Cabeza1 y Cabeza2 podremos
determinar los sentidos de los vectores, es decir, V1→V2;
V1←V2 o V1↔V2
Peso de Arco(Tiempo)
Tabla TEMPCAMINO
Guarda los registros temporales en los cuales se almacenan los vértices de van conformando el
camino mínimo.
Nombre del campo
Vértice
Posx
Tipo de Dato
Numerico
Numerico
Posy
Numerico
Descripción
Identificador de un vértice
Almacena posición x de un punto en un plano de
coordenadas
Almacena posición y de un punto en un plano de
coordenadas
iv
ANEXO B. ODBC Y LA MANIPULACIÓN DE LOS DATOS DEL
SISTEMA
B.1.
ACCESO A DATOS MEDIANTE CONECTIVIDAD ABIERTA DE BASES DE
DATOS (ODBC)
La Conectividad abierta de bases de datos (ODBC) proporciona una interfaz de programación de
aplicaciones (API) de conectividad universal de bases de datos que permite a las aplicaciones
tener acceso a una amplia gama de bases de datos propietarias. Basada en la especificación
X/Open SQL Access Group's Call Level Interface (CLI), ODBC es una manera abierta,
independiente de proveedor, de tener acceso uniforme a datos almacenados en diferentes
formatos y con diferentes motores de base de datos.
ODBC es la interfaz más utilizada para datos relacionales. También es muy rápida, pero puede
pagar el acceso rápido con código de aplicación complejo.
Las características generales de ODBC son:
•
Rendimiento muy eficaz.
•
Dificultad de programación.
•
Requisitos de memoria razonables.
•
Compatibilidad con tecnologías existentes de base de datos.
•
Portabilidad entre muchas plataformas de sistemas operativos.
•
Un modelo de conexión que admite diferentes redes, sistemas de seguridad y opciones de
base de datos.
iv
Como interfaz estándar para datos relacionales, ODBC permite a una aplicación tener acceso a
una gran cantidad de datos. Sin embargo, ODBC requiere que los datos parezcan una base de
datos relacional, por lo que no siempre es la mejor manera de exponer datos. Si no se tiene una
base de datos relacional, puede ser muy difícil escribir un controlador ODBC para exponer los
datos porque se tiene que escribir un motor relacional sobre la estructura de datos existente.
B.2.
DESCRIPCIÓN DE LA ARQUITECTURA ODBC
La arquitectura ODBC consta de cuatro componentes, como se describe en la lista siguiente.
•
Interfaz de programación de aplicaciones (API). Llama a las funciones de ODBC para
conectar con un origen de datos, enviar y recibir datos y desconectar.
•
Administrador de controladores. Proporciona información a una aplicación (como una
lista de orígenes de datos disponibles), carga controladores dinámicamente cuando sean
necesarios y proporciona comprobación de argumentos y transiciones de estados.
•
Controlador Procesa llamadas de funciones de ODBC y administra todos los
intercambios entre una aplicación y una base de datos relacional especifica. En caso de que sea
necesario, el controlador puede traducir la sintaxis estándar SQL a SQL nativo del origen de
datos de destino.
•
Origen de datos Consta de los datos y su motor de base de datos asociado.
Su aplicación utiliza la API de ODBC para conectar con un origen de datos, enviar instrucciones
SQL, buscar datos y desconectar. Un administrador de controladores está entre la aplicación y los
controladores ODBC, decide qué controlador se debe cargar y administra las comunicaciones a
medida que se llama a funciones del controlador. Finalmente, los controladores implementan las
funciones de la API de ODBC para la base de datos. El dibujo siguiente muestra como
interactúan estas funciones.
iv
La arquitectura ODBC significa para una aplicación poder tener acceso a diferentes orígenes de
datos ODBC, en ubicaciones diferentes, mediante las mismas llamadas de función disponibles en
la API de ODBC. Cuando se tenga código para tener acceso a un origen de datos relacional, el
código se puede extender fácilmente para tener acceso a otros orígenes de datos.
B.3.
ACCESO A DATOS MEDIANTE ODBC
ODBC proporciona una API uniforme para tener acceso a todos los orígenes de datos
relacionales. Como ODBC ofrece amplia compatibilidad con proveedores de aplicaciones y bases
de datos, el resultado es una única API que proporciona toda la funcionalidad que necesitan los
programadores de aplicaciones. Esta arquitectura de acceso a datos uniforme asegura la
interoperabilidad y una aproximación común al acceso a datos para los muchos orígenes de datos
relacionales diferentes.
Una aplicación utiliza las siguientes llamadas de función y procesos para tener acceso a un origen
de datos mediante la utilización de la API de ODBC.
•
Asignar controlador de entorno. Identifica la ubicación en la memoria para datos
globales e información de estado para las conexiones definidas.
•
Asignar conexión. Identifica la ubicación en la memoria para datos sobre una conexión
determinada.
•
Conectar. Especifica información de autorización de conexión (como el nombre del
origen de datos, la identificación del usuario y la contraseña).
•
Asignar instrucción. Asocia una instrucción SQL a una conexión. Pueden asociarse a
una conexión muchas instrucciones SQL diferentes, pero solo una cada vez.
•
Ejecutar instrucción SQL. Procesa la instrucción SQL con el motor de base de datos.
iv
•
Buscar conjunto de resultados. Recibe los resultados de la instrucción SQL (como todas
las filas, o sólo la primera, la última, la siguiente o la anterior) y también obtiene información
acerca de los resultados (como el número de filas o el número de columnas).
•
Liberar instrucción. Elimina la instrucción de la conexión. Ahora puede asociar alguna
otra instrucción SQL a la misma conexión.
•
Desconectar. Quita de la conexión el nombre del origen de datos e información de
autorización.
•
Liberar conexión. Elimina la conexión.
•
Liberar controlador de entorno. Elimina los datos globales y libera toda la memoria
asociada.
Al programar con la API de ODBC, se puede crear código independiente de la base de datos que
se adapte automáticamente a una gran variedad de bases de datos. Sin embargo, existe una
consideración importante al adoptar esta aproximación. Mientras cualquier controlador ODBC
específico puede aprovechar las funciones de origen de datos únicas, puede que otros
controladores no admitan las mismas funciones. Si su aplicación se ha diseñado para su uso a
través con varias bases de datos, debe usar con cuidado estas funciones ampliadas o no usarlas.
B.4.
¿CUÁNDO SE DEBE UTILIZAR ODBC?
Varios factores influyen en la elección de la aproximación ODBC. Incluyen la necesidad de alto
rendimiento, más control granular sobre la interfaz y una pequeña huella.
iv
La API de ODBC(Figura B.1) es considerablemente más difícil de programar que las interfaces
basadas en objetos, pero proporciona un control más sensible del origen de datos. A diferencia de
otras tecnologías de acceso a datos (como ADO, RDO u ODBCDirect), la API de ODBC no está
hecha "a prueba de balas". Aunque es bastante fácil producir errores de ODBC durante la
programación,
la
API
del
ODBC
proporciona un control de errores excelente
con mensajes de error detallados. En
general, programar, depurar y dar soporte a
una aplicación basada en la API de ODBC
requiere muchos conocimientos, experiencia
y muchas líneas de código. Como regla
general, los programadores prefieren tener
acceso a datos mediante la utilización de una
interfaz de objetos de más alto nivel y más
Figura B.1. Arquitectura ODBC
sencilla, como ADO.
ODBC no es apropiado para datos no relacionales, como ISAM (Indexed Sequential Access
Method) porque no tiene interfaces para buscar registros, establecer intervalos o examinar
índices. ODBC no se ha diseñado para tener acceso a datos de tipo ISAM. Aunque puede utilizar
el controlador ODBC de Microsoft Jet para controlar datos de ISAM y datos nativos del motor
Microsoft Jet, lo que realmente pasa es que el motor de base de datos Microsoft Jet convierte los
datos de ISAM a datos relacionales y proporciona funcionalidad limitada de tipo ISAM. El
rendimiento en esta situación es lento debido a la capa adicional impuesta por el motor Microsoft
Jet.
Si su aplicación requiere un acceso muy rápido a datos ODBC existentes y desea escribir muchas
líneas de código complejo (o ya tiene un lote de código ODBC disponible para reutilizarlo),
ODBC es una buena elección.
iv
B.5.
RECORDSET (OBJETO)
Para la administración de los datos a nivel del código fuente del programa, se optó por la
utilización de los objetos RECORDSET, debido a las características que se proceden a describir.
Un objeto Recordset representa los registros de una tabla de
base de datos Microsoft Jet o los registros que se generan al
ejecutar una consulta.
Se utilizan los objetos Recordset para manipular datos en
una base de datos a nivel de registro. Cuando utiliza objetos
de acceso de datos, interactúa con los datos prácticamente
Figura B.2. El Objeto Recordset
utilizando objetos Recordset. Todos los objetos Recordset se construyen utilizando registros
(filas) y campos (columnas). Existen tres tipos de objetos Recordset:
•
Recordset de tipo Table - una representación en código de una tabla base que puede
utilizarse para añadir, cambiar o eliminar registros desde una única tabla de base de datos
(sólo espacios de trabajo Microsoft Jet).
•
Recordset de tipo Dynaset - el resultado de una consulta cuyos registros pueden
actualizarse. Un objeto Recordset de tipo Dynaset es un conjunto dinámico de registros que
puede utilizarse para añadir, cambiar o eliminar registros desde una tabla o tablas
subyacentes de una base de datos. Un objeto Recordset de tipo Dynaset puede contener
campos de una o más tablas de una base de datos. Este tipo corresponde a un cursor de tipo
keyset ODBC.
•
Recordset de tipo Snapshot - una copia estática de un conjunto de registros que puede
utilizar para encontrar datos o generar informes. Un objeto Recordset de tipo Snapshot puede
iv
contener campos de una o más tablas de una base de datos pero no se puede actualizar. Este
tipo corresponde a un cursor de tipo static ODBC.
•
Recordset de tipo Forward-only - idéntico a un tipo Snapshot excepto que no se
proporciona ningún cursor. Sólo puede avanzar en los registros. Esto mejora el rendimiento
en situaciones donde sólo necesita hacer una pasada sencilla en el conjunto de resultado. Este
tipo corresponde a un cursor de tipo forward-only ODBC.
•
Recordset de tipo Dynamic - un conjunto de resultado de una consulta de una o más tablas
base en las que puede agregar, cambiar o eliminar registros de una consulta que devuelve
filas. Además, también aparecen en el objeto Recordset los registros que agregan, eliminan o
modifican otros usuarios en la tablas base. Este tipo corresponde a un cursor de tipo dynamic
ODBC (sólo espacios de trabajo ODBCDirect).
Se puede elegir el tipo de objeto Recordset que se quiere crear usando el argumento tipo del
método OpenRecordset.
En un espacio de trabajo Microsoft Jet, si no especifica un tipo, DAO intenta crear el tipo de
objeto Recordset con la mayor funcionalidad disponible, comenzando con tabla. Si no está
disponible este tipo, DAO intenta un Dynaset, después un Snapshot y por último un objeto
Recordset de tipo Forward-only.
En un espacio de trabajo ODBCDirect, si no especifica un tipo, DAO intenta crear el tipo de
objeto Recordset con la respuesta de consulta más rápida, comenzando con Forward-only. Si no
está disponible este tipo, DAO intenta un Snapshot, después un Dynaset y por último un objeto
Recordset de tipo Dynamic.
Cuando se crea un objeto Recordset utilizando un objeto TableDef no adjunto, se crean objetos
Recordset de tipo Table. Sólo pueden crearse Recordset de tipo Dynaset o Snapshot con tablas
adjuntas o tablas de bases de datos externas ODBC.
iv
Cuando abre el objeto se agrega automáticamente un nuevo objeto Recordset a la colección
Recordsets y se elimina automáticamente cuando lo cierra.
NOTA: Si se utiliza variables para representar un objeto Recordset y el objeto Database que
contiene el conjunto de registros, compruebe que las variables tengan el mismo alcance o
duración. Por ejemplo, si establece una variable global que representa un objeto Recordset, debe
asegurarse de que la variable que represente la base de datos que contiene el conjunto de registros
también sea global o se encuentra en un procedimiento Sub o Function con la palabra clave
Static.
En la aplicación se puede crear tantas variables objeto Recordset como se necesiten. Un objeto
Recordset puede hacer referencia a una o más tablas o consultas y los campos sin conflictos.
Los Recordset de tipo Dynaset y Snapshot se almacenan en la memoria local. Si no hay suficiente
espacio en la memoria local para almacenar los datos, el motor de base de datos Microsoft Jet
guarda los datos adicionales en el disco TEMP. Si este espacio está agotado, se producirá un
error.
La colección predeterminada de un objeto Recordset es la colección Fields y la propiedad
predeterminada de un objeto Field es la propiedad Value. El código puede simplificarse
utilizando estos valores predeterminados.
Cuando se crea un objeto Recordset, el registro activo se coloca como primer registro si existen
varios registros. Si no hay registros, el valor de la propiedad RecordCount será 0 y los valores de
la propiedad BOF y EOF serán True.
Se pueden utilizar los métodos MoveNext, MovePrevious, MoveFirst y MoveLast para volver a
establecer el registro activo. Los objetos Recordset de tipo Forward-only sólo admiten el método
MoveNext. Cuando se utilizan los métodos Move para moverse entre los registros (o "andar" a
través del objeto Recordset), se puede utilizar las propiedades BOF y EOF para comprobar el
inicio o el fin del objeto Recordset.
iv
Con los objetos Recordset de tipo Dynaset y Snapshot en un espacio de trabajo Microsoft Jet,
también se pueden utilizar los métodos Find, como FindFirst, para localizar un registro específico
basado en un criterio. Si no se encuentra el registro, la propiedad NoMatch se establece a True.
Para objetos Recordset de tipo Table, se pueden buscar registros utilizando el método Seek.
La propiedad Type indica el tipo de objeto Recordset creado y la propiedad Updatable indica si
puede cambiar los registros del objeto.
La información acerca de la estructura de la tabla base, como los nombres y los tipos de datos de
cada objeto Field y cualquier objeto Index, se almacenan en un objeto TableDef.
Para hacer referencia a un objeto Recordset en una colección por su número de orden o por el
valor de la propiedad Name, se utiliza cualquiera de los formatos de sintaxis siguientes:
Recordsets(0)
Recordsets("nombre")
Recordsets![nombre]
NOTA: Se puede abrir un objeto Recordset del mismo origen de datos o base de datos más de
una vez creando nombres duplicados en la colección Recordsets. Se deben asignar objetos
Recordset a variables de objeto y hacer referencia a ellos por el nombre de variable.
iv
ANEXO C. GRAFOS
Un grafo se compone de un conjunto de puntos llamados
“vértices o nodos” y líneas que unen estos puntos llamados
“aristas o arcos”.
Cada arco de un grafo se especifica
mediante un par de vértices o nodos. Además, en un grafo
pueden haber 1, 2 o n nodos.
Ejemplo:
Figura C.1. Grafos
El conjunto de nodos para el grafo de la Figura C.1 es: {A, B, C, D, E, F, G, H} y el conjunto de
arcos serían todos aquellos pares que estén unidos: {(A,B); (A,C); (B,G); (B,D); (C,D); (E,F);
(A,A); etc.}
Un grafo G = (V, E) es una “estructura algebraica” en la cual V es un conjunto finito no vacío de
vértices o nodos y E es la relación sobre V, que satisface las propiedades:
1.- Irreflexiva (V E V)
2.- Simétrica (V E W) ⇒ (W E V) ∀ v, w ∈ V
Dado que la relación E es un subconjunto de V x V (E ⊆ VxV), podemos decir que el par (v,w)
∈ E. Luego v y w son adyacentes.
Los pares (v,w) que pertenecen a E son pares no ordenados los que llamaremos aristas o arcos, es
decir, E ⊂ VxV = { (v,w) / v≠w ∧ (v,w) = (w,v) }
D.1.
MATRIZ DE ADYACENCIA
Sea V el conjunto de vértices de un grafo, donde V={v1, v2, v3, v4, ..., vn} y supongamos que E
la representaremos en forma de matriz, E(ei,j), entonces:
iv
ei,j = 1 si (vi,wj) ∈ E ∨
ei,j = 0 si (vi,wj) ∉ E
Para la Figura C.1, la matriz de adyacencia correspondiente sería la siguiente(ver Figura C.2):
Figura C.2. Matriz de adyacencia del
Grafo de la Figura C.1.
D.2.
CAMINOS
A) Camino
Sea el grafo G=(V,E) un camino del nodo v0→ vk es un conjunto de aristas o arcos del tipo (v0,
v1) (v1, v2) (v2, v3)... (vk-1, vk), donde vi ∈ V y (vi-1, vi) ∈ E.
B) Camino Simple
Se llamará camino simple si todas las aristas o arcos del camino son diferentes. Si no se repite
ningún nodo se llamará camino elemental.
iv
D.3.
GRAFOS DIRIGIDOS O DIGRAFOS
Los dígrafos son aquellos en que los arcos o aristas tienen una dirección, es decir:
<M,N> ; M = cola del arco, N = cabeza del arco
“N” es adyacente a “M” ssi ∃ arco de “M”a “N”. (Figura C.3)
Figura C.3. Grafo dirigido donde el
Nodo N es adyacente a M
D.4.
PSEUDO CODIGO DEL ALGORITMO DE DIJKSTRA
V = {1,2,3,...,n} (Vertices)
S = {1}(Nodo Inicial)
Paso 1(Para el ejemplo)
For i = 2 to n
Paso 2
D[i] = C(1,i)
Donde C(i,j) pertenece a la matriz de adyacencia. Se
calculan los caminos directos desde el nodo Inicial al
resto de los nodos pertenecientes al grafo
For i = 1 to n-1
{
Elegir un vertice w en V-S (D[w] es mínimo)
Agregar w a S
For (cada vertice v en V-S)
Paso 4
Paso 3
iv
D[v] = minimo ( D[v] , D[w] + C[w,v] )
}
Ejemplo:
OBSERVACION : Para el siguiente ejemplo en que explica el funcionamiento del Algoritmo de
Dijkstra para calcular el camino mínimo de un grafo Dirigido, téngase presente el Digrafo de la
Figura C.4.
Figura C.4. Dígrafo de nodos A, B, C, D,
E
Paso 1:
S = {A} ( es el conjunto que contiene al nodo inicial A ); V - S = {B, C, D, E}
Paso 2:
De acuerdo a la matriz de adyacencia se obtiene la relación entre los nodos, es decir el camino
directo de un nodo al resto de los nodos del grafo. Para el caso del nodo inicial A, se tiene:
D[B] = C(A, B) = 20 (D[w] es mínimo)
D[C] = C(A, C) = -1 (considerado como infinito)
D[D] = C(A, D) = 50
iv
D[E] = C(A, E) = -1 (considerado como infinito)
Paso 3:
W = B ⇒ S = {A, B}; V = {C, D, E}
Paso 4:
D[C] = mínimo(D[C],D[B] + C(B, C))
= mínimo(-1, 20 + -1)
= -1 (infinito)
D[D] =mínimo(D[D], D[B] + C(B, D))
=ínimo(50, 20 + 10)
= 30
D[E] = mínimo(D[E], D[B] + C(B, E))
= mínimo(-1, 20 + -1)
= -1 (infinito)
Luego, el siguiente w será el vértice D.
Entonces S = {A, B, D} y V – S = {C, E}
repetir desde el Paso 3.
La tabla resumen se aprecia en la Figura C.5.
Figura C.5. Tabla resumen del algoritmo de
Dijkstra, aplicado al dígrafo de la Figura
C.4.
iv
ANEXO D. TRABAJANDO EN VISUAL BASIC 6.0
D.1.
MATRICES
D.1.1
CARACTERÍSTICAS AVANZADAS DE MATRICES
Aunque las matrices se usan normalmente para almacenar grupos de variables, hay otros casos en
los que las matrices son útiles: se puede asignar el contenido de una matriz a otra, crear funciones
que devuelvan matrices y crear propiedades que devuelvan matrices. En muchos casos estas
técnicas pueden mejorar el rendimiento de la aplicación.
D.1.2
ASIGNAR MATRICES
De la misma forma que se puede asignar el contenido de una variable a otra, por ejemplo strA =
strB, también se puede asignar el contenido de una matriz a otra. Imagínese, por ejemplo, que se
quiere copiar una matriz de bytes de una ubicación a otra. Se puede hacer copiando un byte cada
vez, de la siguiente manera:
Sub ByteCopy(oldCopy() As Byte, newCopy() As Byte)
Dim i As Integer
ReDim newCopy (Lbound(oldCopy) To UBound(oldCopy)
For I = Lbound(oldCopy) To Ubound(oldCopy)
newCopy(i) = oldCopy(i)
Next
End Sub
Una forma mucho más eficiente es asignar una matriz a otra:
Sub ByteCopy(oldCopy() As Byte, newCopy() As Byte)
newCopy = oldCopy
End Sub
Con la asignación de matrices hay ciertas reglas que se deben tener en cuenta. Por ejemplo,
aunque se puede asignar una variable creada como Integer a una variable declarada como Long
iv
sin ningún problema, asignar un Long a un Integer puede producir fácilmente un error de
desbordamiento. Además de los tipos de datos, la asignación de matrices tiene reglas adicionales
que tienen que ver con el número de dimensiones, el tamaño de las dimensiones y si la matriz es
fija o dinámica.
La instrucción ReDim se utiliza para asignar o cambiar el tamaño de una matriz dinámica que ya
se ha declarado formalmente mediante las instrucciones Private, Public o Dim con paréntesis
vacíos (sin subíndices de dimensiones).
Se puede utilizar la instrucción ReDim repetidamente para cambiar el número de elementos y
dimensiones de una matriz. Sin embargo, no se puede declarar una matriz de un tipo de datos y
luego usar ReDim para cambiar la matriz a otro tipo de datos, a menos que la matriz esté
contenida en una Variant. Si la matriz está contenida en una Variant, el tipo de los elementos se
puede cambiar mediante una cláusula As tipo, a menos que esté utilizando la palabra clave
Preserve, en cuyo caso no se permiten cambios al tipo de datos.
Si se utiliza la palabra clave Preserve sólo se puede cambiar el tamaño de la última dimensión de
la matriz y no es posible cambiar el número de dimensiones. Por ejemplo, si la matriz sólo tiene
una dimensión, se puede cambiar el tamaño de esa dimensión porque es la última y única
dimensión. Sin embargo, si la matriz tiene dos o más dimensiones, sólo se puede cambiar la
dimensión de la última y todavía conservar el contenido de la matriz. El ejemplo siguiente
muestra cómo se puede aumentar el tamaño de la última dimensión de una matriz dinámica sin
borrar ninguno de los datos existentes contenidos en la matriz.
ReDim X(10, 10, 10)
...
ReDim Preserve X(10, 10, 15)
De modo parecido, cuando se utiliza el argumento Preserve se puede cambiar el tamaño de la
matriz sólo cambiando el límite superior; cambiar el límite inferior produce un error.
iv
Si hace que una matriz sea más pequeña de lo que era, se perdern los datos de los elementos
eliminados. Si se transfiere una matriz a un procedimiento por referencia, no se puede cambiar el
tamaño de la matriz dentro del procedimiento.
Cuando se inicializan las variables, una variable numérica se inicializa a 0, una cadena de
longitud variable se inicializa a una cadena de longitud cero ("") y una cadena de longitud fija se
rellena con ceros. Las variables Variant se inicializan a Empty. Cada elemento de una variable de
un tipo definido por el usuario se inicializa como si fuera una variable distinta. A una variable
que se refiere a un objeto se le debe asignar un objeto existente mediante la instrucción Set antes
de que se pueda usar. Hasta que se asigna a un objeto, la variable de objeto declarada tiene el
valor especial Nothing, el cual indica que no se refiere a ninguna instancia en particular de un
objeto.
Precaución: La instrucción ReDim actúa como una instrucción declarativa si la variable que
declara no existe en el nivel de módulo o nivel de procedimiento. Si más tarde se crea otra
variable con el mismo nombre, incluso con un alcance mayor, ReDim hará referencia a la creada
más tarde y no causará necesariamente un error de compilación, incluso aunque Option Explicit
esté en efecto. Para evitar estos conflictos, ReDim no se debe utilizar como una instrucción
declarativa, sino sólo para cambiar el tamaño de las matrices.
NOTA: Para cambiar el tamaño de una matriz contenida en una Variant, se debe declarar
explícitamente la variable Variant antes de intentar cambiar el tamaño de una matriz.
D.2.
COLECCIONES DE OBJETO
Un objeto Collection es un conjunto ordenado de elementos a los que se puede hacer referencia
como una unidad.
El objeto Collection permite hacer referencia de forma sencilla a un grupo de elementos
relacionados como un único objeto. Los elementos o miembros de una colección sólo tienen que
iv
estar relacionados por el hecho de existir en la colección. Los miembros de una colección no
tienen que compartir el mismo tipo de dato.
Los objetos Collection se pueden crear de la misma forma que el resto de los objetos. Por
ejemplo:
Dim X As New Collection
Una vez creado un objeto Collection, se le pueden agregar miembros con el método Add y
quitárselos con el método Remove. Pueden obtenerse miembros específicos del objeto Collection
con el método Item, y hacer una iteración sobre la colección completa con la instrucción For
Each (objeto) In (colección)... Next.
Ejemplo del objeto Collection:
En este ejemplo se crea un objeto Collection (MisClases), y luego se crea un cuadro de diálogo
en el que los usuarios pueden agregar objetos a la colección. Para ver cómo funciona, se elije el
comando Módulo de clase en el menú Insertar y se declara una variable pública llamada
NombreInstancia al nivel del módulo de Clase1 (se escribe Public NombreInstancia). Esta
variable guardará los nombres de cada instancia. Se deja el nombre predeterminado Clase1. Se
copia y pega el código siguiente en la sección General de otro módulo, y luego se inicializa con la
instrucción DenominadorClase desde otro procedimiento. (Este ejemplo sólo funcionará con
aplicaciones principales que admitan clases)
Sub DenominadorClase()
Dim MisClases As New Collection
Dim Num
'Crea un objeto Collection.
'Contador de claves
'individuales.
Dim Msj As String
'Variable para cadena de petición.
Dim ElNombre, MiObjeto, NombreLista ' Variables de información.
Do
Dim Inst As New Clase1
' Crea nueva instancia de Clase1.
Num = Num + 1
' Incrementa Num, y obtiene un nombre.
Msj = "Escriba un nombre para el objeto." & Chr(13) _ & "Presione
Cancelar para ver los nombres de la colección."
ElNombre = InputBox(Msj, "Nombre los elementos de la colección ")
Inst.NombreInstancia = ElNombre 'Nombrar la instancia del objeto
iv
' Si se ha especificado un nombre, lo agrega a la colección.
If Inst.NombreInstancia <> "" Then
' Agrega el objeto con nombre a la colección.
MisClases.Add item := Inst, key := CStr(Num)
End If
' Borra la referencia actual para preparar la siguiente.
Set Inst = Nothing
Loop Until ElNombre = ""
For Each MiObjeto In MisClases
' Crea lista de nombres.
NombreLista = NombreLista & MiObjeto.NombreInstancia & Chr(13)
Next MiObjeto
' Muestra la lista de nombres en un cuadro de mensaje.
MsgBox NombreLista, 'Nombres de instancias de la colección
'MisClases
For Num = 1 To MisClases.Count
Quita un nombre de la colección.
MisClases.Remove 1 'Como las colecciones se reindexan
automáticamente,se quita el primer miembro en cada iteración.
Next
End Sub
D.3.
EL ALGORITMO DE DIJKSTRA IMPLEMENTADO EN VISUAL BASIC
Public Sub Dijkstra(inicial As Variant)
Dim Cont, Menor, Band, V, W, Peso As Integer
Fila = 0
Columna = 0
Paso = 0
Anterior = inicial
Inicializar_Objetos
'Inicializamos las colecciones de objetos
'Insertar los vértices a una colección de objetos (oList - Inicial)
'Se tomarán los índices del grafo que contienen los vert. (no
necesariamente
correlativos)
For Fila = 1 To UBound(aGrafo, 2)
If aGrafo(Fila, 0) <> inicial Then
Set oNodo = New clsNodo
oList.Add oNodo
Set oNodo = Nothing
Else
'obtenemos el índice del vértice en el grafo
indice = Fila
End If
Next
For Columna = 1 To vbNodos
Set oDj = New clsCamino
oD.Add oDj
'
iv
Set oDj = Nothing
Next
For Each oDj In oD
If oDj.Vertice = inicial Then
oDj.Marca = 1
End If
Next
While oList.Count > 1
Band = 0
'Obtener el indice(vertice) de Peso mínimo " Sólo los que quedan
en oList"
For Each oDj In oD
If oDj.Peso <> -1 And oDj.Marca = 0 Then
If Band = 0 Then
W = oDj.Vertice
Menor = oDj.Peso
Band = 1
Else
If oDj.Peso <= Menor Then
W = oDj.Vertice
Menor = oDj.Peso
End If
End If
End If
Next
For Each oDj In oD
If oDj.Vertice = W Then
oDj.Marca = 1
End If
Next
'Sacar de oList el indice de Peso mínimo
Cont = 1
For Each oNodo In oList
If oNodo.Dato = W Then
oList.Remove (Cont)
Exit For
End If
Cont = Cont + 1
Next
For Each oNodo In oList
V = oNodo.Dato
For Each oDj In oD
If oDj.Vertice = V Then
Peso = oDj.Peso
oDj.Peso = Minimo(oDj.Peso, Menor, aGrafo(W, V))
If oDj.Peso <> Peso Then
oDj.Ant = W
End If
Exit For
End If
Next
iv
Next
Wend
frmEmergencia1.cmdSalir.SetFocus
End Sub
iv
BIBLIOGRAFIA
iv
DATOS BIBLIOGRÁFICOS
[1] Pressman, Roger S., “Ingeniería de Software: un enfoque práctico”, Editorial Mc Graw Hill,
1988
[2] Murdick, Robert G., “Sistemas de Información Administrativa”, Editorial Prentice Hall, 1988
[3] Aho, Alfred V., “Estructuras de datos y algoritmos”, Editorial Sistemas Técnicos de edición,
1988
[4] Ayuda en Línea de Microsoft Visual Basic 6.0
[5] Ayuda en Línea de GIS ArcView 3.11
[6] Manual de Procedimientos MultiInstitucional ” ABC” (Ambulancia, Bomberos, Carabineros).
[7] Apuntes de Sistemas de Información Administrativa, Asignatura SIA I y SIA II, de la Carrera
de Ingeniería de Ejecución en Computación e Informática de la Universidad de Magallanes.
iv
INDICE
CAPITULO I. INTRODUCCION......................................................... 1
CAPITULO II. ESPECIFICACION DEL
PROBLEMA Y TOMA DE REQUERIMIENTOS........... 4
2.1
IDENTIFICACION DEL PROBLEMA.......................................................................... 5
2.2
MEDIO AMBIENTE DE OPERACIÓN......................................................................... 5
2.3
ESPECIFICACION Y TOMA DE REQUERIMIENTOS............................................... 6
2.3.1.
ESPECIFICACIONES Y TOMA DE REQUERIMIENTOS PARA EL SISTEMA
ADMINISTRATIVO .................................................................................................................. 6
2.3.1.1.
REQUERIMIENTOS PARA EL MODULO “PERSONAL”.................................. 7
2.3.1.2.
REQUERIMIENTOS PARA EL MODULO “CONTROL DE INVENTARIO”.... 9
2.3.1.3.
REQUERIMIENTOS PARA EL MODULO “DOCUMENTOS” ........................ 12
2.3.2.
ESPECIFICACIONES Y TOMA DE REQUERIMIENTOS DEL SISTEMA PARA
INGRESO DE FORMACION DE SERVICIOS DE EMERGENCIAS .................................... 14
2.3.2.1.
RECEPCIÓN DEL LLAMADO............................................................................ 15
2.3.2.2.
DESPACHO DE LAS UNIDADES ...................................................................... 18
2.3.2.3.
INFORMACION DEL SERVICIO ....................................................................... 18
CAPITULO III. DISEÑO DE LA BASE DE DATOS . 21
3.1
DISEÑO DE LA BASE DE DATOS PARA EL AREA ADMINISTRATIVA............. 22
3.2
DISEÑO DE LA BASE DE DATOS PARA EL AREA OPERATIVA Y LA
ADMINISTRACION DEL SISTEMA GEOGRAFICO(PLANO DE LA CIUDAD)............... 24
3.2.2.
PLANTEAMIENTO ................................................................................................. 24
3.2.3.
ESTRUCTURA DE LA BASE DE DATOS ............................................................ 24
CAPITULO IV. DISEÑO DE LA INTERFAZ
GRAFICA Y PANTALLAS........................................................................ 25
4.1
4.2
4.3
4.4
4.5
MENU PERSONAL...................................................................................................... 27
MENU DOCUMENTOS............................................................................................... 30
MENU INVENTARIO.................................................................................................. 31
MENU MANTENIMIENTO ........................................................................................ 32
MENU SERVICIOS...................................................................................................... 33
CAPITULO V. TRABAJANDO CON ARCVIEW ......... 36
iv
5.1
¿QUÉ SE PUDE HACER CON ARCVIEW?............................................................... 37
5.2
COMENZANDO A TRABAJAR CON ARCVIEW .................................................... 37
5.3
¿SE GUARDAN CON EL PROYECTO LOS DATOS ESPACIALES QUE SE HAN
AÑADIDO AL MAPA?............................................................................................................ 38
5.4
CARGAR DATOS EN FORMA DE TABLAS DESDE BASES DE DATOS............ 38
5.5
PRESENTACION DE LOS VERTICES DE CALLES GRAFICADOS EN EL
MAPA(ANTES Y DESPUES DE DIJSKTRA) PARA EL SISTEMA SICAB ....................... 39
CAPITULO VI. CONCLUSIONES .................................................. 43
ANEXOS ........................................................................................................................... 46
ANEXO A. DESCRIPCION DE TABLAS Y DATOS DE LA BASE
DE DATOS SICAB DISEÑADA EN MICROSOFT ACCESS 2000 ... 47
ANEXO B. ODBC Y LA MANIPULACIÓN DE LOS DATOS DEL
SISTEMA ............................................................................................................................ 65
B.1. ACCESO A DATOS MEDIANTE CONECTIVIDAD ABIERTA DE BASES DE
DATOS (ODBC) ....................................................................................................................... 65
B.2. DESCRIPCIÓN DE LA ARQUITECTURA ODBC .................................................... 66
B.3. ACCESO A DATOS MEDIANTE ODBC ................................................................... 67
B.4. ¿CUÁNDO SE DEBE UTILIZAR ODBC?.................................................................. 68
B.5. RECORDSET (OBJETO) ............................................................................................. 70
ANEXO C. GRAFOS .................................................................................................... 74
D.1. MATRIZ DE ADYACENCIA ...................................................................................... 74
D.2. CAMINOS..................................................................................................................... 75
D.3. GRAFOS DIRIGIDOS O DIGRAFOS ......................................................................... 76
D.4. PSEUDO CODIGO DEL ALGORITMO DE DIJKSTRA ........................................... 76
ANEXO D. TRABAJANDO EN VISUAL BASIC 6.0 ............................... 79
D.1. MATRICES ................................................................................................................... 79
D.1.1
CARACTERÍSTICAS AVANZADAS DE MATRICES ......................................... 79
D.1.2
ASIGNAR MATRICES ............................................................................................ 79
D.2. COLECCIONES DE OBJETO ..................................................................................... 81
D.3. EL ALGORITMO DE DIJKSTRA IMPLEMENTADO EN VISUAL BASIC ........... 83
BIBLIOGRAFIA ..................................................................................................... 86
DATOS BIBLIOGRÁFICOS ..................................................................................................... 87