“sicab” sistema de información para central de alarmas de ... · el sistema sicab trabajará...
TRANSCRIPT
UUNNIIVVEERRSSIIDDAADD DDEE MMAAGGAALLLLAANNEESS FFAACCUULLTTAADD DDEE IINNGGEENNIIEERRIIAA
DDEEPPAARRTTAAMMEENNTTOO DDEE IINNGGEENNIIEERRIIAA EENN CCOOMMPPUUTTAACCIIÓÓNN
““SSIICCAABB”” SSiisstteemmaa ddee IInnffoorrmmaacciióónn ppaarraa CCeennttrraall ddee
AAllaarrmmaass ddee BBoommbbeerrooss
AAlleexxii IIssaabbeell MMaannddiioollaa GGooddooyy AAllffoonnssoo IIrrccaannoo DDííaazz MMuuññoozz
22000033
UUNNIIVVEERRSSIIDDAADD DDEE MMAAGGAALLLLAANNEESS FFAACCUULLTTAADD DDEE IINNGGEENNIIEERRIIAA DDEEPPAARRTTAAMMEENNTTOO DDEE IINNGGEENNIIEERRIIAA EENN CCOOMMPPUUTTAACCIIÓÓNN
““SSIICCAABB”” SSiisstteemmaa ddee IInnffoorrmmaacciióónn ppaarraa CCeennttrraall ddee
AAllaarrmmaass ddee BBoommbbeerrooss
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 : Roberto Uribe Paredes Ingeniero de Ejecución en
Computación e Informática Patrocinante : Cuerpo de Bomberos de Puerto
Natales
AAlleexxii IIssaabbeell MMaannddiioollaa GGooddooyy AAllffoonnssoo IIrrccaannoo DDííaazz MMuuññoozz
22000033
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).
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.3. Pantalla para el ingreso y mantención de datos de la Hoja de Vida del Personal
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)
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).
Figura 4.6. Pantalla para el ingreso y mantención de documentos llegados.
iv
4.4 MENU MANTENIMIENTO
La Figura 4.8 muestra la vista de una de las opciones del menú Mentenimiento.
Figura 4.7. Pantalla para el ingreso y mantención de especies de inventario
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. Se pulse el botón consulta
5.5 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.
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
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
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 Tipo de Dato Descripción CodAcci Numérico Código de la lesión Acci Texto 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 Tipo de Dato Descripción Run Texto Rol Único Nacional FecIni Texto Fecha de inicio de la actividad FecTer Texto Fecha de término de la actividad CodCargo Numérico Código que identifica el tipo de cargo desempeñado entre
las fechas indicadas anteriormente Obs Texto Si acaso corresponde alguna, producto de su desempeño CodCia Numérico 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 Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio Idservicio Numérico Tipo de servicio realizado Idllamado Numérico Sub tipo de servicio realizado CodInst Numérico Identifica a la Institución que concurrió al lugar Acargo Texto Nombre de la persona que estuvo a cargo de la Institución Cargo Texto Cargo o puesto que desempeña la persona en la Institución Obs Texto 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 Tipo de Dato Descripción CodAprov Numérico Código de aprobación del curso para un bombero Aprov Texto 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 Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio Idservicio Numérico Tipo de servicio realizado idllamado Numérico Sub tipo de servicio realizado Marca Texto Marca del vehículo Modelo Texto Modelo del vehículo Patente Texto Patente del vehículo Color Texto Color de la carrocería CIProp Texto RUN del propietario NomProp Texto Nombre del propietario CICond Texto RUN del Conductor NomCond Texto Nombre del conductor NroOcup Numérico Número de ocupantes del móvil NomAseg Texto Nombre de la compañía de seguros NroPol Texto Número de la póliza FecTerVig Texto 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 Tipo de Dato Descripción CodCali Numérico Código para cada una de las calidades Cali Texto 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 Tipo de Dato Descripción CodCargo Numérico Código del cargo o actividad que desempeña el personal Cargo Texto 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 Tipo de Dato Descripción CodCateg Numérico Código de la categoría Categ Texto 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 Tipo de Dato Descripción Cia Numerico Almacena el código de Compañía. CodCia Texto Identificación convencional de la Compañía NomCia Texto Almacena el nombre de la Compañía. DirCia Texto Almacena la dirección de la Compañía. FonoCia Texto Almacena el(los) teléfonos de la Compañía Bomba Texto 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 Tipo de Dato Descripción Run Texto Rol Único Nacional FecIni Texto Fecha de inicio del curso FecTer Texto Fecha de término del curso. CodCur Numérico Código del curso. CodAprov Numérico Código que identifica la situación de aprobación del
participante Obs Texto Si acaso corresponde alguna, producto de su participación
en dicho curso Cia Texto 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 Tipo de Dato Descripción CodCur Numérico Código del curso o taller realizado NomCur Texto Nombre que describe el curso o taller realizado CodOrg Numérico 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 Tipo de Dato Descripción CodDano Numérico Código del daño Dano Texto 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 Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio servicio Numérico Tipo de servicio realizado llamado Numérico Sub tipo de servicio realizado fecha_ini Texto Fecha de inicio del servicio hora_ini Texto Hora de inicio del servicio fecha_term Texto Fecha de término del servicio. hora_term Texto Hora de término del servicio Calle Numérico Código de la calle de emergencia Nro Texto Numero que identifica la casa de la calle de la emergencia inters_calle Numerico 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 Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio idservicio Numérico Tipo de servicio realizado idllamado Numérico Sub tipo de servicio realizado Origen Texto Descripción del probable origen del siniestro Causa Texto Descripción de la probable causa del siniestro CodCateg Numérico Código que identifica la categoría probable del siniestro CodMagni Numérico Código que identifica la magnitud de la emergencia CodDano Numérico Código que identifica los daños estimados a la estructura
siniestrada Porcen Numérico Estimación del porcentaje de daño y/o destrucción NomAseg Texto Nombre de la entidad que asegura la estructura NroPol Texto Número de la póliza FecTerVig Texto Fecha del término de vigencia de la póliza
UltUni Texto Ultima unidad móvil que se retiró del lugar TotBomb Numérico Total de Bomberos que asistieron OcupMay Numérico Número de ocupantes mayores de edad OcupMen Numérico Número de ocupantes menores de edad PerAten Numérico Personas atendidas en el lugar por parte de personal de la
Institución PerFall Numérico Personas fallecidas en el lugar CodAcci Numérico Código que identifica el tipo de accidente, si lo hubo. Fono Texto Número de teléfono desde donde se dio aviso de la emergencia Obs Texto Si corresponden al llamado
iv
Tabla DATPEREMER
Guarda los registros de personas que intervinieron en algún llamado, realizando alguna actividad.
Nombre del campo Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio Servicio Numérico Tipo de servicio realizado Llamado Numérico Sub tipo de servicio realizado CodActiv Numérico Código de la actividad que desarrolla la persona en el llamado NomPer Texto Nombre que identifica a la persona Run Texto 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 Tipo de Dato Descripción CodDep Numérico Código de la dependencia Dep Texto 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 Tipo de Dato Descripción CodDoc Texto Identifica a un documento en particular, dado por el ultimo
correlativo de su tipo. CodTipo Numérico Identifica el tipo de documento que se esta recibiendo NroDoc Texto El número que identifica al documento FecDoc Texto Fecha de emisión del documento(la que viene impresa en el
mismo). FecRecep Texto Fecha en que se recibe el documento Proced Texto Breve descripción de la persona o institución que envía el docto Cont Texto Breve descripción del contenido del documento Obs Texto 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 Tipo de Dato Descripción CodDoc Texto Identifica a un documento en particular, dado por el ultimo
correlativo de su tipo. CodTipo Numérico Identifica el tipo de documento que se está despachando FecEmi Texto Corresponde a la fecha de emisión del documento Dest Texto A que Institución o persona va dirigida Cont Texto Breve descripción del contenido del documento Obs Texto 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 Tipo de Dato Descripción CodEsp Numérico 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
Cant Numérico Cantidad de elementos que corresponden a la especie NomEsp Texto Nombre que identifica a la especie ValMone Numérico Valor monetario asignado a la especie Obs Texto Si corresponden, debido a la naturaleza, estado o características
de la especie CodDep Numérico Identifica la dependencia a la que está asignada la especie CodInv Texto Identifica si corresponde a un inventario de tipo OPERATIVO o
ADMINISTRATIVO FecAlt Texto Fecha en que la especie es ingresada oficialmente al inventario CodDocAlt Texto Identifica al documento que oficializa el ingreso de la especie al
inventario FecBaj Texto Fecha en que la especie es dada de baja oficialmente del
inventario CodDocBaj Texto Identifica al documento que oficializa la dada de baja de la
especie al inventario Est Texto Identifica si la especie está en BUENAS, MALAS O
REGULARES condiciones Cia Texto Identifica la compañía a la que pertenece la especie CodGrup Numérico 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 Tipo de Dato Descripción CodEstCiv Numérico Código para cada uno de los estados civiles EstCiv Texto 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 Tipo de Dato Descripción CodGrup Numérico Código del grupo de activos Grup Texto 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 Tipo de Dato Descripción CodDoc Texto 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
FecPreSan Texto Fecha en que recibe el premio o sanción Motivo Texto Descripción del motivo por el cual se hace acreedor al premio o
sanción Run Texto Rol Único Nacional CodPreSan Numérico identifica el código del premio o sanción Cia Texto 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 Tipo de Dato Descripción CodInst Numérico Código de la Institución Inst Texto 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 Tipo de Dato Descripción CodServ Numérico Identifica el código del servicio CodLlam Numérico Código del tipo de llamado Llam Texto Descripción del tipo de llamado, conforme a la clasificación del
tipo de servicio Ultimo Numérico 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 Tipo de Dato Descripción CodMagni Numérico Código de la magnitud Magni Texto 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 Tipo de Dato Descripción Folio Numérico Corresponde al último llamado por subtipo de servicio servicio Numérico Tipo de servicio realizado llamado Numérico Sub tipo de servicio realizado CodMaq Numérico 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 Tipo de Dato Descripción Cia Texto Código que identifica a la compañía a la cual esta destinada la
máquina NomMaq Texto Nombre de fábrica de la máquina CodMaq Numérico Código que identifica a la máquina Id Texto Nomenclatura de identificación Disponible Sí/No 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 Tipo de Dato Descripción CodNac Numérico Código para cada una de las nacionalidades Nac Texto 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 Tipo de Dato Descripción CodNivEsc Numérico Código que identifica al nivel escolar respectivo Nivel Texto 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 Tipo de Dato Descripción CodOrg Numérico Código de la organización que imparte el curso Org Texto 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 Tipo de Dato Descripción Folio Numérico Identifica al ultimo llamado dentro de tipo de servicio Idservicio Numérico Identifica el tipo de servicio al que pertenece el llamado Idllamada Numérico Identifica al tipo de llamado. Dir Texto Dirección de la estructura afectada Porcen Numérico Estimación del porcentaje de daño y/o destrucción CodDano Numérico Código que identifica los daños estimados a la estructura
siniestrada Obs Texto 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 Tipo de Dato Descripción CodActiv Numérico Código de la actividad que realizó la persona Activ Texto 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 Tipo de Dato Descripción RegGral Numérico Este campo guarda la información correspondiente al número de
registro general que el Bombero tiene en dicho libro NroFolio Numérico 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
Cia Texto Código con el que se identifica la compañía de pertenencia ApePat Texto Apellido paterno ApeMat Texto Apellido materno Nombres Texto Nombre(s). CodCali Numérico Código con el que se identifica la calidad de socio dentro de la
Institución FecIng Texto Fecha de ingreso a la Compañía CodNivEsc Numérico Código con el que se identifica el nivel de escolaridad CodNac Numérico Código con el que se identifica la nacionalidad Profesion Texto Descripción de la profesión o actividad que ejerce en su vida
laboral particular FecNac Texto Fecha de nacimiento LugNac Texto Lugar de nacimiento DirDom Texto Dirección del domicilio particular FonoDom Texto Teléfono(s) particular. Debe incluir los códigos de área. Run Texto Rol Único Nacional CodEstCiv Numérico Código que identifica el estado civil del Bombero RegCia Numérico Corresponde al número de registro de Compañía que tiene dentro
de la misma CodSangre Numérico Código que identifica el grupo de sangre LugTrab Texto Descripción del lugar donde desempeña sus actividades laboralesDirTrab Texto Dirección laboral FonoTrab Texto Teléfono(s) del lugar de trabajo FecBaj Texto Fecha de baja de la Institución CauBaja Texto Breve descripción por la cual se le otorgó la baja ServMil Sí/No Si realizó o no el servicio militar CodCargo Numérico Código del cargo actual ObsMed Texto 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 Tipo de Dato Descripción CodPreSan Numérico Código del premio a sanción PreSan Texto Descripción correspondiente al premio a sanción Inicial Texto 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 Tipo de Dato Descripción CodSangre Numérico Código del grupo de sangre Grupo Texto 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 Tipo de Dato Descripción CodServ Numérico Código del servicio. Serv Texto 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 Tipo de Dato Descripción Run Texto Rol Único Nacional Ano Numérico Corresponde al año en que realizó el servicio militar Unidad Texto 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 Tipo de Dato Descripción CodTipo Numérico Código del tipo de documento NomTipo Texto Descripción del nombre que recibe el tipo de
documento(CIRCULAR, ORDEN DEL DIA, OFICIO CONDUCTOR, SOLICITUD, CERTIFICADO, otros definidos por el usuario.)
CorrelSal Numérico Ultimo correlativo utilizado para los documentos salidos CorrelLleg Numérico 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 Tipo de Dato Descripción Ultimo Numérico 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 Tipo de Dato Descripción Folio Numerico Corresponde al ultimo llamado del tipo de servicio
correspondiente(ultimo correlativo por subtipo) idservicio Numerico Corresponde al código del servicio idllamada Numérico Corresponde al código de tipo de llamado FecIni Texto Fecha inicio del llamado HrIni Texto Hora inicio del llamado FecTer Texto Fecha término del llamado HrTer Texto Hora término del llamado UltUni Numérico Código de la última máquina que se retiro del lugar TotBomb Numérico Total de Bomberos que asistieron Obs Texto Si corresponden al llamado Lugar Texto Lugar o Institución a quien se realizó la emergencia Descrip Texto 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 Tipo de Dato Descripción Codigo Numérico Código que identifica a una calle Nombre Texto 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 Tipo de Dato Descripción Codigo Numérico Código identificador de un vértice(intersección de calles). Inters1 Numérico 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)
Inters2 Numérico Identificador de una calle(ídem al campo anterior) PosX Numérico Almacena posición x de un punto en un plano de
coordenadas PosY Numérico 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 Tipo de Dato Descripción Codigo Numérico Almacena el vértice de las salidas que pueden tener las
compañías de Bomberos. Inters1 Numérico Primera calle que conforma la intersección Inters2 Numérico Segunda calle que conforma la intersección CodCia Numérico Almacena el código de la compañía
iv
Tabla ARCO
Almacena los datos del arco existente entre dos vértices.
Nombre del campo Tipo de Dato Descripción Vértice1 Numérico Identifica primer vértice del arco Vértice2 Numérico Identifica segundo vértice del arco Cabeza1 lógico Identifica si vertice1 es cabeza del arco formado por los
vértices( V1 ← V2) Cabeza2 lógico 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 numérico 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 Tipo de Dato Descripción Vértice Numerico Identificador de un vértice Posx Numerico Almacena posición x de un punto en un plano de
coordenadas Posy Numerico 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
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.
Figura B.1. Arquitectura ODBC
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
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
Figura B.2. El Objeto Recordset
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:
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:
Figura C.1. Grafos
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):
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.
Figura C.2. Matriz de adyacencia del Grafo de la Figura C.1.
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)
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) Paso 3
Agregar w a S
For (cada vertice v en V-S) Paso 4
Figura C.3. Grafo dirigido donde el Nodo N es adyacente a M
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.
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
Figura C.4. Dígrafo de nodos A, B, C, D, E
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 'Crea un objeto Collection. Dim Num '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 MENU PERSONAL...................................................................................................... 27 4.2 MENU DOCUMENTOS............................................................................................... 30 4.3 MENU INVENTARIO.................................................................................................. 31 4.4 MENU MANTENIMIENTO ........................................................................................ 32 4.5 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