Introducción

La información administrada por elServicio Nacional de Aduanas (SNA) entodo el país es almacenada actualmente enel Sistema de Información Aduanera(SIA), el cual contiene los datos de losingresos fiscales por concepto deimpuestos de importación, queconstituyen aproximadamente el 50% delpresupuesto nacional. El SIA consiste enun conjunto de aplicaciones de base dedatos sobre una plataforma Oracle”, queprocesa y registra las transaccionesaduaneras que recibe.

A pesar de que el SIA mantiene losregistros de las operaciones de losusuarios desde 1993, la información quealberga es controlada por aplicacionesdesarrolladas para el registro,seguimiento y control de transacciones,que no están diseñadas para permitir el

Palabras claves

Bases de datos, sistemas deinformacion, almacenes de datos

Resumen

El presente trabajo es un resumen delproyecto de graduación de ambosautores. Propone la aplicación de unmercado de datos para estructurar unadivisión de la Dirección General deAduanas, con el fin de realizarinvestigación fiscales y aduaneras.Presenta un prototipo basado en unesquema de bases de datos, con una tablade hechos y 11 tablas dimensionales. Losdatos son extraídos de la base de datos delSistema de Información aduanero; sontransformados e ingresados al prototipo,donde podrían ser consultados utilizandouna interfase tipo OLAP. Se implementatambién el acceso por Internet.

77Vol. 16 Nº 3

Prototipo de mercado de datos para laDivisión de Control y Fiscalización dela Dirección General de Aduanas

Ricardo Chinchilla Arley 1José Luis Vargas Murillo 2

Chinchilla Arley, Ricardo y Vargas Murillo, José Luis. Prototipo de mercado de datos para la División de Control y Fiscalización de la Dirección General de Aduanas. Tecnología en Marcha. Vol. 16 N˚ 3.

1 Ricardo Chinchilla Arley, Master en Computacion ITCR, funcionario Centro Centroamericano dePoblación, Director Biblioteca Sede del Atlántico, Universidad de Costa Rica. (richar@ccp.ucr.ac.cr).

2 José Luis Vargas Murillo, Master en Computacion ITCR, funcionario División de Control yFiscalización de la Dirección General de Aduanas. (vargasmjl@hacienda.go.cr).

La informaciónadministrada por elServicio Nacional deAduanas (SNA) entodo el país esalmacenadaactualmente en elSistema deInformación Aduanera(SIA).

funciones fiscalizadoras del SNA engeneral. Entre las funciones de la DCFse encuentra velar por la definición yaplicación oportuna y precisa decriterios de control que son los que, a finde cuentas, determinarán hacia quién,cómo y cuándo deben dirigirse losesfuerzos fiscalizadores.

Los criterios de control emanados de laDCF se basan en varias fuentes deinformación, entre las cuales están losinformes estadísticos producidos por laDivisión de Estadística, Registro yDivulgación de la DGA, generadosutilizando la información almacenada enel SIA. Debido a que este sistema no esapropiado para el trabajo de análisis, losdatos que se utilizan para satisfacer lassolicitudes de información provienen dearchivos de texto (planos) extraídos delSIA, generados por funcionarios en lasaduanas o desde la misma División deEstadística.

Estos archivos planos son producidospor rutinas con instrucciones SQL(lenguaje estructurado de peticiones)que extraen los valores de las variablesseleccionadas y registradas en unperíodo determinado. Estos valores sondescargados en tablas tipo DBF (por sussiglas en inglés de Data Base File), apartir de las cuales se extraen otrastablas con información específica, segúnlos requerimientos de la DCF y otrasoficinas o dependencias. Ninguna de lastablas tiene relación entre si.

Es necesario contar con un sistema quepermita la integración de la informaciónobtenida del SIA y provea lasherramientas necesarias para serutilizadas en el análisis y la evaluaciónde la información extraída. Esainformación contribuirá a disminuir laincertidumbre en el control de losriesgos aduaneros, tales como son ladefraudación fiscal, el contrabando y elincumplimiento de la normativaaduanera.

acceso rápido y preciso requerido en losprocesos de análisis y toma dedecisiones de la administraciónaduanera.

Este sistema tiene 10 años de estar enproducción. La versión sobre la que estádesarrollado no recibe soporte técnicodel fabricante, debido a su antigüedad;realizar modificaciones estructuralesprofundas supondrían un costo muyelevado.

Tal circunstancia dificulta también laadopción de estrategias y elestablecimiento de directrices decontrol que permitan definir con menorincertidumbre las empresas, procesos omercancías que se habrán deseleccionar como sujetos de estudiopara propósitos fiscales y aduaneros.

Es necesario contar con una tecnologíaque permita hacer comparaciones,encontrar patrones de comportamiento,hallar tendencias, establecer relacionesque ayuden a la detección o prevenciónde delitos aduaneros o el señalamientode incumplimientos de las leyes ynormas del comercio nacional einternacional. Es aquí donde eldesarrollo de un Depósito de Datos(DD), definido por González (1998a:11) como un “[...] repositorio único,completo y consistente de datosobtenidos de diferentes fuentes [...] queestán disponibles al usuario de formatal que pueda ser comprendido y usadoen un contexto de empresa”,proporcionaría al SNA una herramientacapaz de suministrar informacióntransformada, filtrada, resumida,agrupada y lista para satisfacer losrequerimientos de los usuarios.

El proceso de análisis o toma dedecisiones basado en la informaciónextraída del SIA es una tarea cotidianade la División de Control yFiscalización (DCF), la cual estáencargada de definir la pauta en laorientación y planeamiento de las

78 Vol. 16 Nº 3

hechos general. Por otro lado, elprototipo proporciona una interfase deconsulta que pretende ser unaaproximación a un OLAP (On-LineAnalytical Processing). Esta interfasepermite consultas multidimensionales,la reducción dimensional y visualizar lainformación agrupada desde distintasperspectivas, además de ofrecer salidas adistintos formatos de archivo.

Prototipo de mercado de datos

Definición de dimensiones

Las dimensiones utilizadas en estaaplicación son un subconjunto de lasvariables o campos que conforman partede la información transaccional de losimportadores que, en sociedad con lasagencias de aduana, diariamente estransmitida a las aduanas del país.

Las dimensiones descriptivas que seproponen para el Mercado de Datos son:

• Aduana• Agencia• Importador• Mercancía• Lugar de descarga• País de origen• País de procedencia• Modalidad• Trámite• Semáforo • Tiempo

Las medidas asociadas a las dimensionesindicadas son:

• Número de bultos• Valor Cif (costo, seguro y flete)• Derechos arancelarios a la

importación.• Impuesto selectivo de consumo.• Impuesto de la ley 6946.• Impuesto de ventas.• Impuesto a las mercancías con

destino al depósito libre de Golfito.• Impuesto a las mercancías del

tratado libre de comercio conMéxico.

Corey (1997: 33) define el Mercado deDatos (MD) como un “(...) subconjuntode un Depósito de Datos que se extraepara satisfacer las necesidades de unaclase particular de usuario”. Es unatecnología que resolvería la problemáticadescrita, debido a las facilidades dealmacenamiento y procesamientoanalítico de que dispone.

Un MD proporciona un esquema dealmacenamiento que permite realizarconsultas complejas, por medio de lainteracción e interrelación de múltiplesentidades, manteniendo solo unrepositorio con la información agregaday ordenada, según las necesidades de losusuarios. Además, provee de unainterfase de consulta que permite alusuario la posibilidad de análisis de lainformación para la toma de decisiones.Esto con el propósito de atacar los delitose infracciones aduaneras, así comoprocurar el ejercicio del control fiscal.

Alcances y limitaciones

El prototipo se limita a los datossuministrados en los informesestadísticos solicitados por la DCF a laDivisión de Estadística Registro yDivulgación. Dichos datos consisten enaquellos valores contenidos en loscampos del SIA correspondientes a lasdeclaraciones aduaneras de importacióndefinitiva, que la DCF ha consideradocomo necesarios para la atención de lademanda de información. Para estaaplicación se utilizó una base inicial de250 mil registros.

La herramienta que se utilizó para laconstrucción del prototipo fue VisualFoxPro 6.0, por considerar que reúnelas características necesarias para sudesarrollo.

La base de datos fue implementada bajoel esquema estrella y sin tablas deresumen, por lo que el cálculo de lasconsultas es efectuado sobre la tabla de

79Vol. 16 Nº 3

La herramienta que seutilizó para laconstrucción delprototipo fue VisualFoxPro 6.0, porconsiderar que reúnelas característicasnecesarias para sudesarrollo.

ejemplo el de valoración de mercancías, laverificación arancelaria o los de control deprocesos aduaneros.

Para el diseño lógico del MD se utilizó lapropuesta de modelaje de hipercubosplanteado por Sonia Cortez Araniva(Cortez 1999). Las razones por la cualesse adopta este modelo son, en primertérmino, su simplicidad y fácilcomprensión, y debido a que los otrosmodelos no se han orientado, según dichaautora, a sugerir un modelomultidimensional gráfico y sinorientación a una implementaciónespecífica.

Diseño lógico

Modelo gráfico

En el Cuadro 1 muestra los elementos amodelar desde una perspectiva general:

Se implementa entonces un MD para lasimportaciones definitivas, tomando encuenta las mercancías importadas, segúnlos capítulos, partidas arancelarias, y elnivel de apertura nacional. Se considera,además, el período en que se realizanéstas. Dicho período puede ser en añosfiscales o en años calendario; estos

• Total de impuestos pagados.• Total de impuestos exonerados.

Metodología de desarrollo

La primera tarea que se llevó a cabo fuedeterminar las necesidades deinformación de los usuarios, aplicandoentrevistas e investigando en los archivoshistóricos del Departamento deEstadística todo lo relacionado con lassolicitudes de información. Esto diocomo resultado el conjunto dedimensiones descriptivas y cuantitativas.

Posteriormente, se hizo el análisis de losdatos dentro de cada dimensiónconsiderada, modelando con ellos unprimera visión del prototipo. La metaera buscar el acomodo de losrequerimientos de los usuarios alconcepto que se iba desarrollando. Enesta etapa se utilizaron datos de pruebareales, con los cuales los usuariosexploraban si la interfase que se ofrecíasatisfacía sus necesidades. Se continúocon ese tipo de evaluación hastaconsiderar que la informaciónproporcionada por las dimensiones queformaban el modelo, así como lasmedidas que las delimitaban, cumplíanaceptablemente sus pretensiones.

El concepto metodológico general que seha empleado en esta propuesta ha sidodesarrollar una solución de facilitación deinformación para análisis y toma dedecisiones, a partir de sectoresespecíficos, como es el caso de la DCF.Posteriormente, se pueden considerarnuevas etapas con la inclusiónincremental de otras áreas de interés(nuevos mercados de datos), como por

80 Vol. 16 Nº 3

Figura 1Modelo general del MD

Cuadro 1Descripciónde elementos a modelar

Importaciones Mercancías Capítulos Partidas Apertura nacionaldefinitivas Período Años calendario Trimestres Meses

Años fiscales

AduanaAgenciaImportadorTrámiteModalidadLugar de descargaSemáforo

TiempoPaís de origenPaís de procedenciaMercancíasVariables de medida

Importaciones definitivas

correspondiente de las dimensionesTiempo y Mercancías, además de losatributos de clasificación de la tabla dehechos.

Descripción del modelo

La descripción del modelo se detalla acontinuación:

Descripción del modelo

Hipercubo: Importaciones definitivas

Definición de dimensiones

Importación_defi: Variables de medidaen la importación que consideran elvalor de las mercancías, los impuestospagados, las exoneraciones y la cantidadde bultos

últimos incluyen trimestres y meses. Ladescripción anterior define las jerarquíasde las dimensiones mercancía y tiempodel prototipo.

El modelo general del MD, sería:

Por su parte, el modelo dimensionalpara el sistema propuesto sería el que semuestra en la Fig. 2.

Aquí se presenta cada una de lasdimensiones con sus respectivosatributos, todas ellas unidas a la tablaImportación_defi. Por su parte, elmodelo que representa las diferentesjerarquías se muestra en la Fig. 3.

En este modelo se despliegan lasjerarquías existentes en el MD. Sepuede apreciar el despliegue

81Vol. 16 Nº 3

Figura 2Esquema del modelo dimensional del prototipo

Lugar_descarga: Lugar físico donde seencuentra la mercancía a desalmacenar

País_origen: País de donde es originariala mercancía importada

País_procedencia: País del cual procedela mercancía importada

Semáforo: Tipo de revisión al cual sesomete la mercancía

Mercancías: Descripción de lasmercancías importadas

Tiempo: Período de tiempo en el que seconsideran las variables

Modalidad: Categoría sobre el tipo demercancía y destinación

Agencia: Nombre y descripción de laagencia aduanal encargada de laimportación.

Importador: Nombre y descripción delimportador de mercancías.

Aduana: Nombre y descripción de laaduana por donde se realiza el trámitede desalmacenaje.

Trámite: Tipos de trámite para eldesalmacenaje.

82 Vol. 16 Nº 3

Figura 3Esquema del modelo de jerarquías del prototipo

[País_procedencia]: nombre de todos lospaíses de donde proceden lasmercancías.

[Cód_semaforo]: número entero de undígito, el cual puede ser 0, 1 o 2.

[Semáforo]: nombre del tipo de revisiónaplicado a la mercancía.

[Cód_capitulo]: número enterocorrespondiente a los primeros dosdígitos del arancel de mercancías.

[Cód_partida]: número enterocorrespondiente a los primeros cuatrodígitos del arancel de mercancías.

[Cód_mercancia]: número enterocorrespondiente a los 10 dígitos delSistema Arancelario Centroamericano.

[Mercancia]: nombre de las mercancías.

[Añomes]: número entero de 6 dígitos.

[Cód_año]: número entero de dosdígitos.

[Año]: número entero de cuatro dígitos.

[Cód_trimestre]: nombre de númeroordinal correspondiente a los trimestresdel año.

[Trimestre]: número y nombre deltrimestre.

[Cód_mes]: nombre de número ordinalcorrespondiente a los meses del año.

[Mes]: múmero y nombre de los mesesdel año.

[Cód_añofiscal]: número entero de dosdígitos.

[Año fiscal]: número entero de cuatrodígitos.

Definición de dominio

[Cód_modalidad]: número entero dedos dígitos.

[Modalidad]: nombre de todos los tiposde operación.

[Cód_agencia]: número entero de tresdígitos.

[Céd_jurídica_agencia]: número enterode 11 dígitos.

[Agencia]: nombre de todas lasagencias del país.

[Céd_importador]: número entero de 12dígitos.

[Importador]: nombre de todos losimportadores del país.

[Cód_aduana]: número entero de dosdígitos.

[Aduana]: nombre de todas las aduanasdel país.

[Cód_tramite]: código alfabético de uncarácter.

[Trámite]: nombre de los tipos detrámite aplicados a la mercancía

[Cód_lugar_descarga]: códigoalfanumérico de tres caracteres.

[Lugar_descarga]: nombre de los tiposde lugar de descarga de mercancías.

[Cód_país_origen]: número entero de 4dígitos correspondiente al código ISOde países.

[País_origen]: nombre de todos lospaíses de donde son originarias lasmercancías.

[Cód_país_procedencia]: númeroentero de 4 dígitos correspondiente alcódigo ISO de países.

83Vol. 16 Nº 3

Representación de operaciones

Drill Down - Roll Up

Es posible, de acuerdo con la estructurade jerarquías diseñada en este modelo,ejecutar las operaciones de Drill Down yRoll Up sobre las dimensiones Tiempo yMercancías conforme a la siguientefigura:

Definición de jerarquías

84 Vol. 16 Nº 3

Dimensión Mercancías:

J1: P1: * → capítulo Pliega todos los capítulosP2: capítulo → partida Pliega todas las partidas por capítuloP3: partida → mercancía Pliega todas las mercancía por partida

Dimensión Tiempo

J1: P1: * → años Pliega todos los años calendarioP2: año → trimestre Pliega todos los trimestres por añoP3: trimestre → mes Pliega todos los meses por trimestre

J2 P1: * → Años fiscal Pliega todos los años fiscales

J1 J2 Las jerarquías J1 y J2 son mutuamente excluyentes

Cada uno de los atributos requiere undominio, el cual se coloca junto a ellosencerrado entre corchetes.

Se han definido jerarquías en lasdimensiones de Mercancías y Tiempo.En el caso de la dimensión Tiempo lasjerarquías año calendario y año fiscalson mutuamente excluyentes; por tantose pueden hacer consultas sobre unajerarquía determinada, pero no sobreambas al mismo tiempo.

Cada una de las dimensionespropuestas está estructurada por losatributos descriptivos asociados, uno delos cuales necesariamente correspondeal que identifica unívocamente a cadaregistro, o sea su llave primaria.

Por su parte la tabla de hechos(importacion_defi) que contiene lasvariables de medida, se enlaza con lasdimensiones a través de las llavesforáneas provenientes de cada una deellas. La unión de las llaves foráneasdeclaradas en la tabla de hechosconforma su llave primaria,completando así el esquema de estrella.

Figura 4Drill Down y Roll Up

en la dimensión mercancía

representaría ningún problema técniconi funcional, y podría ser implementadosin ninguna dificultad.

Diseño físico

Base de datos

Con base en el modelo lógicorepresentado gráficamente con lossímbolos de Cortez (1999), se desarrollael modelo físico.

Para la implementación de la base dedatos se han creado tablas para cada unade las dimensiones descriptivas delmodelo conceptual, las cuales contendránlos atributos de clasificación respectivos yla llave primaria. La Fig. 6 muestra elmapeo del modelo utilizando el esquemade implementación tipo estrella, dondetodas las dimensiones se relacionan conla tabla de hechos con una cardinalidad deuno a muchos.

La tabla de hechos contiene las variablesde medida. La llave primaria de la tablade hechos está compuesta por elconjunto total de llaves foráneas, lascuales, a su vez, son llaves primarias desus respectivas dimensiones PK =(FK1+ FK2+...+FKn).

Con respecto a la integridad referencial,se debe recordar que se trabaja con unabase de datos histórica, razón por la cuallas dimensiones son raramentemodificadas o actualizadas, ejerciendoun estricto control sobre los datos desdelos procesos de carga. La integridadreferencial es administrada por losdominios de los atributos previamentedefinidos. De esta forma, no es posibleinsertar o actualizar un dato si el valorpropuesto para un atributo no satisfacelas reglas de su dominio.

Para todas las dimensiones, la tablasecundaria común es Importación_defi.En la regla de actualización se posibilitaactualizar solamente la tabla secundaria,ya que los registros de las tablasprimarias no son modificados. En la

Mientras se mantiene cualquierjerarquía de la dimensión Tiempo, sepuede profundizar o plegar desde lajerarquía de Capítulo hasta la jerarquíade Mercancía y viceversa.

Así mismo, se puede realizar la mismaoperación para la dimensión Tiempo através de la combinación de cualquierade las demás dimensiones consideradasen el modelo:

85Vol. 16 Nº 3

Figura 5Drill Down y Roll Up en la dimensión Tiempo

En este caso se mantiene cualquiercombinación de, por ejemplo, Aduana –Agencia – Importador, y los valores demedida Valor_cif e Impuestos, mientrasse profundiza o pliega desde la jerarquíaAño hasta la jerarquía Mes de ladimensión Tiempo, y viceversa.

En este caso concreto, el mínimo nivelde granularidad de la jerarquía es la demes. Esta decisión se basa en tresrazones: 1. por cuestiones académicasde demostración de la funcionalidad delprototipo, 2. por cuestiones prácticas deahorro de espacio físico y velocidad deprocesamiento, y 3. se determinó queeste último nivel satisface lasnecesidades de información de losusuarios potenciales del prototipo. Sinembargo, la incorporación del nivel dejerarquía día, o inclusive, hora, no

aplica su propio esquema de control deintegridad referencial en su operaciónnormal. Esto debería garantizar que losdatos que ingresan al sistema de carga delprototipo ya han sido depurados al nivelde integridad del sistema transaccional.

Extracción, transformación y carga de datos

El sistema de extracción del prototipoconsta de tres subsistemas: el detransformación, el de agregación y el decarga. La Fig. 7 muestra el proceso consus respectivos subsistemas. El procesode extracción, que recolecta los datos

regla de inserción, se permite insertarregistros a la tabla secundaria aunque noexistan registros coincidentes en lastablas primarias, esto debido a que losdatos son previamente filtrados antes desu carga y se eliminan los registros sincoincidencias. En la regla deeliminación, es posible quitar registrosde las tablas primarias aunque esténvinculados a la secundaria, esto porque,al ser una base de datos histórica, dichosregistros nunca serán eliminados.

Por último, los datos a cargar han sidoextraídos de un sistema transaccional que

86 Vol. 16 Nº 3

Figura 6Modelo físico de la base de datos

necesario definir la secuencia lógica delas consultas, a fin de facilitar suoperación.

Se decidió establecer, como punto departida, la definición del periodo en quese desearía efectuar el análisis.Posteriormente, la selección de lasdimensiones y sus instancias, así comoel orden de aparición. Por ultimo, lasunidades de medida y su ordenamiento.

Para efectuar estas operaciones, existeun procedimiento central, que reúnetodos las distintas variablesseleccionadas a lo largo de laconstrucción de la consulta.

Todas las variables seleccionadas omodificadas en la interfase, sonmanejadas por el código de un métodode la aplicación que permite el cambiointeractivo, reflejado directamente en elresultado de la consulta. Cualquiermodificación en la interfase, envía lasnuevas variables o valores alprocedimiento llamado bldSQL, para laconstrucción interactiva y automática dela sentencia SQL que determina losresultados de la consulta final.

requeridos por el sistema alimentador,es realizado en el Departamento deEstadística.

El subsistema de transformaciónconvierte los datos en el formato dedestino y elimina los campos que no sonrequeridos. El subsistema de agregacióntotaliza los datos hasta la jerarquía deMes de la dimensión Tiempo. Elsubsistema de carga inserta los datosdentro del MD.

Un aspecto importante es el hecho deque, al provenir los datos de una solafuente (SIA), no es necesarioimplementar opciones para solucionarlos problemas de diferencias lógicas, detipo o de tamaño en los formatos de losarchivos. Por tal motivo, los datos secargan sin conciliación.

La consulta de informacion en el prototipo

El centro neurálgico de la aplicaciónprototipo lo constituye la herramientaque permite extraer los datos agregadospara un posterior análisis (Fig. 8). Parael diseño de una interfase de consultacapaz de realizar esta función, fue

87Vol. 16 Nº 3

Figura 7Proceso de transformación y carga

pretende servir de base para una futuraexpansión del prototipo, en un eventualproyecto de Data Warehouse a escalageneral.

Internet Database Connector (IDC)

Para el acceso a los datos contenidos en elMD, se utiliza un servidor con MicrosoftNT Server como sistema operativo,Internet Information Server (IIS) comoservidor web y la herramienta ODBC(Open DataBase Conectivity) InternetDatabase Connector (IDC) para el enlacea los datos.

Conceptualmente, el acceso a la basesde dato es realizado por el IIS, como semuestra en la Fig. 9. El visualizador delcliente envía las consultas al servidorWeb a través del protocolo detransferencia de hipertexto (http). Elservidor Web responde con undocumento en formato HTML montadosobre una plantilla (htx). El acceso a labase de datos es proporcionado por elcomponente IDC, que es un programaInternet Server Application ProgramInterface o DLL/ISAPI (httpodbc.dll)que utiliza ODBC para establecer dichoacceso.

Construcción del enlace

Para la construcción del enlace del MD aInternet, se definieron las consultas quepodrían requerir los altos ejecutivos delMinisterio de Hacienda, los gerentes olas jefaturas de departamento de lasaduanas. Se toman estos usuarios clavecomo base para la definición debido aque, al encontrarse geográficamentedistanciados de la DCF, no es posible elacceso directo y personal a la interfasede consulta principal.

Las consultas disponibles que seplantean son:

• Consultas generales• Aduana e importador• Aduana y agencia• Aduana y lugar de descarga

La instrucción SQL final quegenera el procedimiento bldSQL es lasiguiente:

Cada uno de los elementos, con elprefijo lc, contiene cadenas de texto quela configuran, según sean lasselecciones, filtros y restriccionesdefinidas interactivamente por elusuario.

Acceso al mercado dedatos por Internet

Con el desarrollo de un enlace porInternet al MD, se pretende facilitar elacceso de la información a los usuariosalejados en las aduanas. Además,

88 Vol. 16 Nº 3

lcSelect = “SELECT “+ lcCamposGrl + lcDimMedida+;

“ FROM “+ lcFromGrl+;

lcWhereGrl+;

lcGroupBy+;

lcOrderBy

Figura 8Interfase de consulta

El cuarto paso fue crear los formulariosde captura de la consulta. Dichosformularios envían parámetrosingresados por el usuario en elementosselect tipo multiple, y controlados porJava Script. Este último realiza dichocontrol por medio de funciones llamadaspor el manejador de eventos onChange.

Por último, para el despliegue de losdatos se utilizan plantillas HTX paracada una de las consultas, las cualescontienen las etiquetas HTML<%BeginDetail%> y <%EndDetail%>que proporcionan una estructura debucle que se ejecutará a través del cursorresultante. Cualquier HTML que estéentre estas dos etiquetas, se genera paracada uno de los registros y los nombresde los campos se pueden incrustarempleando la sintaxis <%nombrecampo%>.

Conclusiones

La implementación de la solucióncontribuirá significativamente en lalabor de investigación y en el ejerciciodel control fiscal, en primer término enel rendimiento y tiempo de análisis y ensegundo término en la calidad de loshallazgos derivados de su aplicación.Esto gracias a la interfase de consulta, lacual facilita el análisis multidimensionalde los datos, mediante la construcciónde tablas de resultados que almacenan lainformación de las distintas dimensiones

• Consultas específicas por aduana ylugar de descarga• Aduana e importador• Aduana y agencia• Aduana y lugar de descarga poragencia

• Consulta por mercancías• General por aduana• Aduana e importador• Aduana y agencia• Aduana y lugar de descarga• Aduana y país de origen

• Consulta por tipo de revisión• Mayores importadores mensuales

Una vez especificadas, se ejecuta elprimer paso, en el cual se construye unatabla libre agregada sobre la cual serealizarán las consultas

El segundo paso es la configuración delorigen de datos ODBC mediante eladministrador de orígenes de datosODBC de NT. Para ello se define unorigen tipo sistema, utilizando MicrosoftVisualFoxPro Drivers direccionado aldirectorio de la tabla libre.

Como tercer paso se encuentra lacreación de los archivos IDC, los cualesespecifican los parámetros quecontienen información empleada paraacceder una base de datos ODBC y elSQL para la ejecución de una consultadeterminada. Para la interfase seconstruyó un archivo IDC para cada unade ellas, los cuales reciben losparámetros enviados por losformularios. Un archivo IDC tiene lasiguiente estructura:

89Vol. 16 Nº 3

Figura 9Acceso a bases de datos por IIS

Datasource: <nombre del origen dedatos>

Template: <nombre del archivo deplantilla htx donde se enviarán losdatos>

SQLStatement:

+<estatutos SQL para el acceso a losdatos>

Chinchilla Arley, Ricardo; Vargas Murillo, JoséLuis. Prototipo de mercado de datos para laDivisión de Control, y Fiscalización de laDirección General de Aduanas. Cartago.ITCR. 2002.

Corey, Michael; Abbey, Michael. Oracle DataWarehousing: guía práctica para analizar,construir e implantar con éxito un sistemadata warehouse. Madrid. McGraw-Hill.1997.

Cortés, Carlos; Meléndez, Jaime; Tobar,Mercedes. “Internet Database Connector”.Interfaz CGI para Servidores Web y Sistemasde Administración de Bases de Datos. SanSalvador: Universidad Centroamericana JoséSimeón Cañas. 1997. http:// 168.243.1.4/investigacion/ bdweb/reportes/ idc.html.

Cortez Araniva, Sonia Elizabeth. Desarrollo deun Modelo para el Diseño de Bases de DatosMultidimensionales. Cartago. ITCR. 1999.

Cox Alvarado, Alexander. Propuesta de unálgebra para modelar bases de datosmultidimensionales. Cartago. ITCR. 2000.

González Alvarado, Carlos. Depósito dedatos. Cartago. ITCR. (1998a).

González Alvarado, Carlos. Procesamientoanalítico en línea. Cartago. ITCR. 1998b.

Guderian, Dave; Leer, Doug; Molini, Steve.“Keepeing the data warehouse in track”Database programming and design. January,1998.

Harinarayan, V.; Rajaraman, A.; Ullman, J.“Implementing data cubes efficiently”SIGMOD’96 6/96, Montreal. Canada. 1996.h t t p : / / w w w - d b . s t a n f o r d . e d u / p u b /harinarayan/ 1995/cube.ps

Herrán Gascón, Manuel de la; Castellar-Busó,Vicent. “Cómo diseñar grandes variables enbases de datos multidimensionales” Revistadigital universitaria, jul, 2000.http://www.revista.unam.mx/vol.1/art5/index.html

Kimball, Ralph. “A dimensional modelingmanifesto”. DBMS. August, 1997.

Madsen, Mark. “Warehouse Design in theAgregate”. Database programming anddesign. July, 1996. http://www.dbpd.com/vault/julytoc.htm

Oracle Corporation. Design a database forOLAP. March/April, 1996. http://www.oramag.com/oracle/96-mar/26meth.html

Parsaye, Kamran. “OLAP and Data Mining:

de forma agrupada y utilizandoreducción dimensional.

Cabe destacar que la metodologíadefinida por Cortez constituye un aportepara realizar el diseño conceptual ydefine un rumbo que facilita eldesarrollo de la tecnología de DD.Laincorporación de algunas consultasgenerales a través de Internet, pormedio del acceso a una tabla agregada,especialmente construida para este fin,se ha enfocado en resolver problemaspuntuales de información de aquellosusuarios que requieren accesar elMercado de Datos de forma remota.Esta facilidad proporciona una mayorcobertura del servicio y acceso; sinembargo, puede ser ampliadoincorporando mayor flexibilidad en losformularios y en los programasasociados que efectúan la extracción deinformación de la tabla agregada. Afuturo, es recomendable una conexióndirecta al Mercado de Datos completo

Para una implementación final se debenincorporar tablas agregadas y registrossumarizados para cada una de lascombinaciones posibles. Esto, con el finde permitir una mayor velocidad en elprocesamiento de consultas. Además, esnecesaria la incorporación de funcionesgraficadoras y de sumarización a lainterfase de consulta, a fin deconvertirla en un OLAP relacional yaumentar el potencial de análisis de losusuarios.

Una vez instalado el prototipo y evaluadassus capacidades y posibilidades de apoyoa la administración, es recomendable sudesarrollo futuro sobre tecnologías debase de datos multidimensionales másrobustas.

BibliografíaCataldo, Joseph. “Care feeding data

warehouse”. Database programming anddesign. December, 1997. http://www.dbpd.com/vault/9712toc.htm.

90 Vol. 16 Nº 3

Una vez instalado elprototipo y evaluadassus capacidades yposibilidades de apoyoa la administración, esrecomendable sudesarrollo futuro sobretecnologías de basede datosmultidimensionalesmás robustas.

work overtime”. Database programmingdesign. September, 1997.

Simon, Alan. “Beyond the warehouse”. Databaseprogramming desing. december, 1996.

Weldon, Jay; Weldon, Louise. “Managingmultidimensional data”. Databaseprogramming and design. august., 1995.

Weldon, Jay; Weldon, Louise. “ChoosingTools for Multidimensional Data”. Databaseprogramming and design. February, 1996.

Wolff, Carmen. “Implementando unDataWarehouse”. Revista IngenieríaInformática: revista electrónica del DIICC.Edición 5, año 3 [2000]. http://www.inf.udec.cl/revista/edicion5/cwolff.htm

Bridging the Gap”. Database programmingdesign. February, 1996. http://www.dbpd.com/vault/parsfeb.htm

Parsaye, Kamran “Surveying DecisionSupport: New Realms of Analysis”.Database programming desing. April, 1996.

Pérez Martínez, Cayetano. Replicación debases de datos por Internet. México:Instituto Politécnico Nacional, 1999.http://148.204.20.3/PROYECTOS/TESIS/cayetano/DTeMae.htm

Poe, Vidette. Building a data warehouse fordecision support. New Jersey: Prentice-Hall, 1998.

Reese, Joseph. “Making the datawarehouse

91Vol. 16 Nº 3