soporte a la toma de decisiones

��

Presentación:

El diseño e implementación de un sistema de “Soporte a la Toma de Decisiones en la Cría de Ganado Vacuno”, como podrá comprenderse a medida que se avanza en la lectura del presente trabajo, requiere de un análisis minucioso del problema, de los datos y de los requerimientos, ya que en muchas situaciones, y en casi todas, los problemas no se ajustan a las situaciones comunes en el campo de aplicación de los DSS (Sistemas de Soporte a la toma de Decisiones); como ser contables, financieros, de recursos humanos, de mercadotecnia, sistemas médicos, etc. Pero todo trabajo es más emocionante en estas situaciones, el analizar, el innovar, utilizar la creatividad, plantear hipótesis, diseñar modelos, evaluar y medir errores, depurarlos para luego obtener los resultados esperados (éxito), ésta es la tarea de todo investigador, y el razonamiento seguido será desarrollado y explicado a continuación.

Fernando Princich.

��

Resumen

Introducción: En la actualidad, ninguna empresa u organización que se jacte de ser competitiva puede estar ajena a la realidad, y la realidad nos enseña que el recurso más importante de las empresas, es la información. Muchas organizaciones entienden por informatización o mecanización de la información, el solo proceso de almacenar datos para tener la información bien organizada – estructurada – y segura. Esto es muy cierto y es imprescindible en todo proceso de informatización, por lo menos en sistema de gestión administrativa y operativa. Pero hoy y desde hace bastante tiempo, se vienen desarrollando sistemas que sean utilizados por los tomadores de decisiones de la organización, estos sistemas dan “Soporte a la Toma de Decisiones”, y ese es el nombre con que se los denomina a éste tipo de sistemas. Estos sistema pretenden, o son diseñados, para dar soporte a las cinco funciones clásicas de los administradores: planeación, organización, coordinación, decisión y control. Los sistemas clásicos de soporte a la decisión están diseñados para que los tomadores de decisiones evalúen la rentabilidad de su empresa. En éste trabajo final de aplicación, se utilizan distintas metodologías para dar soporte a la toma de decisiones en la producción ganadera bovina. Que indirectamente también da soporte para evaluar la rentabilidad de la empresa u organización ganadera. Objetivos del Trabajo: El presente trabajo final de aplicación, tiene como objetivo principal; la investigación y aplicación de un “Sistema de Soporte a la Decisión”, en los procesos claves de la cría del ganado vacuno. Otro objetivo del trabajo es brindar a los productores ganaderos (dedicados a la cría) una herramienta para hacer de su establecimiento una empresa competitiva, que se adapte a los requerimientos de comercialización de los mercados del primer mundo, (ver capítulo: Descripción de la Aplicación y Resultados, ítem; Trazabilidad). El presente trabajo además tiene como objetivo, satisfacer las necesidades de informatización de los investigadores en producción ganadera, por ejemplo; estaciones experimentales de los Institutos Nacionales de Tecnología Agropecuaria (INTA). Se encuentra apropiada ésta sección, para comentar que a medida que se fue indagando en el trabajo, las metas del proyecto fueron creciendo enormemente, debido a la cantidad de información que puede registrarse, procesarse y analizarse en éste ámbito. Es por eso que se ha pensado en futuras implementaciones, que son nombradas y fundamentadas en el capitulo futuras implementaciones. La Cría del Ganado Vacuno. La producción ganadera bovina, puede dividirse en cuatro ramas: La Cría del Ganado, Invernada, Tambo, y Cabaña.

��

La variación en producción, en la que se optó investigar para desarrollar la aplicación fue la de Cría y Recría, por el simple hecho de que es la más practicada en la zona. Se define como Cría al proceso productivo dedicado a la obtención de terneros, que es el producto final, de Lo que dispone el criador para su venta anual. La Cría es el proceso inicial en toda la cadena de la producción de carne. La invernada o engorde, es el proceso productivo que continúa a la cría y consisten la compra de los ternero para llevarlos a otras categoría comercializables, como novillitos y/o novillos. El objetivo primario de la cría es; lograr un ternero por vaca y por año. La región del NEA, es la segunda zona de cría en importancia en el país, con un stock aproximado de 9.000.000 de cabezas de las cuales el 46.5 % son vientres. (Según Encuesta Nacional Agropecuario, año 2002). Toma de Decisión en la Cría del Ganado Vacuno. Antes de introducirnos en el tema, se dará una importante definición. Un DSS (Sistema de Soporte a la Decisión) utiliza los recursos intelectuales de los individuos y la capacidad de las computadoras, para mejorar la calidad de las Decisiones. Es un sistema de soporte basado en computadora, para Directivos que toman decisiones sobre problemas semi-estructurados, y/o estructurados. La mayoría de los datos que son necesarios registrar en ésta posibilidad de producción, la Cría del Ganado Vacuno, muchos productores de nuestro medio, no lo registran o si lo hacen lo hacen de manera desorganizada y no estructurada, en pocas palabras no utilizan la informática en sus procesos productivos. Por ende a la hora de tomar alguna decisión, las fuentes de información son muy limitadas, y si no se cuenta con un buen asesoramiento, generalmente la decisión tomada no es la más óptima y en muchos casos es desacertada. Ésta aplicación, no pretende reemplazar, ni mucho menos, a un asesor ganadero, pero es capaz de ayudar a tomar decisiones, estructuradas y semi-estructuradas, en los procesos claves de la cría del ganado vacuno. Éste proyecto es muy extenso y su desarrollo integral requiere de mucha información, muchas pruebas, y muchos datos. En el presente trabajo se han aplicado teorías de “Sistemas Expertos”, de “Sistemas de Soporte a la Toma de Decisiones”, de “Modelos y simulación”, etc. Para desarrollar aplicaciones que den soporte a la Decisión en la cría de ganado vacuno, en alguno de los procesos claves, como ser: Servicios, Preñeses, Pariciones, y Destetes. Herramientas Informáticas Utilizadas en el Presente Proyecto:

• Visual Basic, como lenguaje de programación. • Access, como manejador de base de datos transaccional. • SQL, como lenguaje estructurado de consultas a la base de datos. • Analysis Services, como herramienta OLAP (Procesamiento Analítico en Línea),

para diseñar y analizar datos a partir de la base de datos Multidimensional.

��

Capitulo I: Teorías y Métodos.

Teoría de los Sistemas Expertos.

Panorama de la Inteligencia Artificial Antecedentes culturales que han servido de base. Algunos de más importantes son: Se adopta el criterio de que la inteligencia tiene que ver principalmente con las acciones racionales. Desde un punto de vista ideal, un agente inteligente es aquel que emprende la mejor acción posible en una situación dada. Se estudiará el problema de la construcción de agentes que sean inteligentes en este sentido. Los filósofos (desde el año 400 a.C.) permitieron el poder pensar en IA, al concebir a la mente, con maneras diversas, como una máquina que funciona a partir del conocimiento codificado en un lenguaje interno y al considerar que el pensamiento servía para determinar cuál era la acción correcta que había que emprender.

Las matemáticas proveyeron las herramientas para manipular las aseveraciones de certeza lógica, así como las inciertas, de tipo probabilista. Así mismo, prepararon el terreno para el manejo del razonamiento con algoritmos.

Los psicológicos reforzaron la idea de que los humanos y otros animales podían ser considerados como máquinas para el procesamiento de información. Los lingüistas demostraron que el uso de un lenguaje ajusta dentro de este modelo.

La ingeniería de cómputo ofreció el dispositivo que permite hacer realidad las aplicaciones de IA. Los programas de IA por lo general son extensos y no funcionarían sin los grandes avances en velocidad y memoria aportados por la industria de cómputo.

La historia de la IA ha sido testigo de ciclos de éxito, injustificado optimismo y la consecuente desaparición de entusiasmo y apoyos financieros. También ha habido ciclos caracterizados por la introducción de nuevos y creativos enfoques y de un sistemático perfeccionamiento de los mejores.

Los avances recientes logrados en la comprensión de las bases teóricas de la inteligencia han ido aparejados con mejoras hechas en el potencial de los sistemas reales.

El Alcance de la Inteligencia Artificial

No es posible dar una definición de universalmente aceptable de la IA, pero lo que se puede hacer es dar una lista de los procesos que generalmente pueden ser llamados IA si son programados en un computadora. La lista no es exhaustiva, pero cubre las

��

áreas principales. SOLUCION DE PROBLEMA EN GENERAL. Esto es no simplemente programar una maquina para resolver problemas específicos tales como hallar las soluciones de una ecuación de segundo grado, sino crear un sistema capaz de hallar métodos para solucionar problemas. PERCEPCION. Las maquinas serán capaces de reaccionar a su entorno e influenciarlo mediante sensores y dispositivos de interacción como con el exterior. La visión ya se ha llevado a cabo en una escala limitada mediante aparatos de televisión y dispositivos para la percepción de imágenes sintetizadores que permiten al ordenador comunicarse mediante el lenguaje hablado en la salida y no escrito como se ha hecho hasta ahora, con el uso de pantallas o impresoras. Algunos de los progresos conseguidos con el desarrollo de circuitos integrados permitirán al computados aceptar ordenes y datos especializados, también mediante la utilización del lenguaje hablado. COMPRENSION DEL LENGUAJE NATURAL. La necesidad de comunicarse con los computadoras mediante un lenguaje ensamblador o en uno de los lenguajes especializados de alto nivel ha impedido a los no especialistas hacer un uso que no sea superficial de los ordenadores. APRENDIZAJE, DEMOSTRACION DE TEOREMAS, JUEGOS. Todos estos campos requieren cierta capacidad de mejorar la experiencia. La búsqueda de algoritmo que permitan incorporar esta capacidad a un sistema es una de las características básicas de la investigación en IA. HARDWERE PARA LA IA. El diseño tradicional de hardware no ha conseguido alcanzar, en gran medida el fin propuesto por la IA. Las técnicas de IA requieren acceso rápido a bancos de memoria, enormes según los estándares tradicionales y, por tanto, las velocidades de proceso son demasiado lentas para las aplicaciones mas exigentes. La antigua idea de solucionar un problema paso a paso mediante la ejecución de una secuencia de instrucciones esta cediendo al paso a la idea del procesamiento en paralelo, en le cual un conjunto de procesadores trabajan simultáneamente en la diferentes partes del problema. Según otros rumbos tomados se propone la inclusión de compiladores en hardware mas que en software, y la obtención de un microcodigo para procesadores en un lenguaje lógico como el Prolog . ROBOTICA. La ciencia de la robótica implica diferentes técnicas de IA. La idea de un robot "listo" con la capacidad de aprender por experiencia es el tema central de teorías e investigaciones en IA. El robot debe ser capaz de comunicarse en lenguaje natural y debe poder realizar tareas que requieran que el equivalente a la iniciativa y la originalidad, esto implica que el robot debe llegar a realizar, tras un periodo de aprendizaje cosas para las cuales no estaba inicialmente programado, a diferencia de los robots que se utilizan actualmente en la aplicación industrial, los cuales no son más que meros autómatas. La idea global en la inteligencia artificial estuvo desacreditada durante varios años debido parcialmente, al excesivo optimismo por parte de la primera teoría pero, mayormente causado por la exageración y el sensacionalismo de algunos de sus divulgadores. Los primeros robots creados en toda la historia de la humanidad, no tenían más que un solo fin: entretener a sus dueños. Estos inventores se interesaban solamente en conceder los deseos de entretener a quien les pedía construir el robot. Sin embargo, estos inventores se comenzaron a dar cuenta de que los robots podían imitar

��

movimientos humanos o de alguna criatura viva. Estos movimientos pudieron ser mecanizados, y de esta manera, se podía automatizar y mecanizar algunas de las labores más sencillas de aquellos tiempos. El origen del desarrollo de la robótica, se basa en el empeño por automatizar la mayoría de las operaciones en una fábrica; esto se remonta al siglo XVII en la industria textil, donde se diseñaron telares que se controlaban con tarjetas perforadas. CIBERNETICA. La cibernética es una ciencia interdisciplinaria, tratando con sistemas de comunicación y control sobre organismos vivos, máquinas u organizaciones. El término es una derivación del vocablo griego kybernetes que significa gobernador o piloto, y fue aplicado por primera vez en 1948 a la teoría del control de mecanismos por el matemático americano Norbet Wiener. En el cuerpo humano, el cerebro y el sistema nervioso funcionan para coordinar la información, la cual es utilizada para determinar el futuro curso de una acción; controlar los mecanismos para la autocorrección en máquinas que sirven con un propósito similar. Este principio es conocido como retroalimentación, el cual es fundamental en el concepto de automatización. La cibernética también se aplica al estudio de la psicología, servomecanismo, economía, neuropsicología, ingeniería en sistemas y al estudio de sistemas sociales, el término cibernética no es muy utilizado para describir por separado a un campo de estudio, y muchas de las investigaciones en el campo ahora se centran en el estudio y diseño de redes neuronales artificiales. SISTEMAS EXPERTOS. Para algunas persona los términos IA y sistemas expertos son sinónimos. Muchos de los sistemas expertos existentes actualmente consisten en grandes bases de conocimientos, creadas para almacenar la información de que se dispone expertos humanos en varios campos y a las que se aplica una serie de reglas de manipulación expresadas en lenguajes específicos. La diagnosis medica, la ingeniería química, la exploración geológica y el diseño de computadoras han proporcionado material para el diseño de sistemas expertos de gran éxito. Con el nacimiento de la Revolución Industrial, muchas fábricas tuvieron gran aceptación por la automatización de procesos repetitivos en la línea de ensamblaje. La automatización consiste, principalmente, en diseñar sistemas capaces de ejecutar tareas repetitivas hechas por los hombres, y capaces de controlar operaciones sin la ayuda de un operador humano. El término automatización también se utiliza para describir a los sistemas programables que pueden operar independientemente del control humano. La mayoría de las industrias han sido automatizadas o utilizan tecnología para automatizar algunas labores; en la industria de la telefonía, la marcación, la transmisión y la facturación están completamente automatizadas. Pero no todas las industrias requieren el mismo grado de automatización. La agricultura es una industria difícil de automatizar, y con esto se ha vuelto más mecanizada, esencialmente en el procesamiento y empaque de comida. De manera similar, los doctores pueden dar consulta asistiéndose en una computadora, pero finalmente el doctor, y no la computadora, termina por dar el diagnóstico final al paciente. Los robots comenzaron a aparecer en este proceso de automatización industrial hasta la aparición de las computadoras en los 40’s. Estos robots computarizados, están equipados con pequeños microprocesadores capaces de procesar la información que le proveen los sensores externos y así es como el robot puede tomar cambiar o mantener una operación en ejecución, a esto se le llama retroalimentación, y forma parte de la Cibernética. La retroalimentación es esencial en cualquier mecanismo de control automático, ya que ayuda a controlar los factores externos que le afecten en la correcta ejecución de sus operaciones normales.

��

Sistemas Expertos ¿Qué es un sistema experto? Los sistemas expertos forman parte de un firme y verdadero avance en inteligencia artificial. Los sistemas expertos pueden incorporar miles de reglas. Para una persona seria una experiencia casi "traumática" el realizar una búsqueda de reglas posibles al completado de un problema y concordar estas con las posibles consecuencias, mientras que se sigue en un papel los trazos de un árbol de búsqueda. Los sistemas expertos realizan amablemente esta tarea; mientras que la persona responde a las preguntas formuladas por el sistema experto, este busca recorriendo las ramas más interesantes del árbol, hasta dar con la respuesta a fin al problema, o en su falta, la más parecida a esta. Los sistemas expertos tienen la ventaja frente a otros tipos de programas de Inteligencia Artificial, de proporcionar gran flexibilidad a la hora de incorporar nuevos conocimientos. Para ello solo tenemos que introducir la nueva regla que deseemos hacer constar y a está, sin necesidad de cambiar el funcionamiento propio del programa. Los sistemas expertos son "auto explicativo", al contrario que en los programas convencionales, en los que el conocimiento como tal está encriptado junto al propio programa en forma de lenguaje de ordenador. Los expertos de I.A. dicen que los sistemas expertos tienen un conocimiento declarativo, mientras que en los demás programas es procedural.

Áreas de Aplicación de Los Sistemas Expertos Según la clase de problemas hacia los que estén orientados, podemos clasificar los Sistemas Expertos en diversos tipos entre los que cabe destacar diagnosis, pronóstico, planificación, reparación e instrucción; algunas de las aplicaciones existentes (o en periodo de desarrollo) para cada uno de los campos citados, son: Los sistemas de diagnosis siguen un proceso de búsqueda de las razones del funcionamiento incorrecto de un sistema a partir de la información disponible. Aquí se podrían tener en cuenta tanto aplicaciones de diagnóstico médico como de averías. En lo referente al diagnóstico médico, existe una serie de aplicaciones extensa en número (FLUIDEX, EACH, TROPICAID, SPHINX, ...), pero quizá la más conocida, a la vez que la más antigua, podría ser MYCIN. MYCIN es el primer Sistema Experto que llegó a funcionar con la misma calidad que un experto humano, dando a su vez explicaciones a los usuarios sobre su razonamiento. Antes del desarrollo de MYCIN (mediados de los 70), se criticaba a la Inteligencia Artificial por resolver únicamente problemas "de juguete", sin embargo, el éxito de MYCIN demostró que la tecnología de los Sistemas Expertos estaba suficientemente madura como para salir de los laboratorios y entrar en el mundo comercial. MYCIN es, en definitiva, un sistema de diagnóstico y prescripción en medicina, altamente especializado, diseñado para ayudar a los médicos a tratar con infecciones de meningitis (infección que produce inflamación de las membranas que envuelven al cerebro y la médula espinal) y bacteriemia (infección que implica la presencia de bacterias en la sangre). Dichas infecciones pueden ser fatales y a menudo aparecen

��

durante la hospitalización. El problema se complica por la necesidad de actuar con rapidez. Existen además en este campo Sistemas Expertos como TROPICAID, que permiten obtener información adicional sobre los medicamentos más usados. TROPICAID selecciona un conjunto de posibles diagnósticos a partir del análisis del cuadro médico, y propone un tratamiento óptimo para el caso concreto. Por otra parte, el campo de la diagnosis abarca otras aplicaciones además de las médicas (si bien pueden ser estas últimas las más conocidas). En este caso se trata de fallos, averías o anomalías que se producen generalmente en una máquina. Los sistemas de pronóstico deducen consecuencias posibles a partir de una situación. Su objetivo es determinar el curso del futuro en función de información sobre pasado y presente. Esto abarca diversos problemas, tales como predicciones meteorológicas, predicciones demográficas, o incluso previsiones de la evolución bursátil entre otros. Quizá la aplicación más conocida sea PROSPECTOR, esto es un sistema para la evaluación de emplazamientos geológicos (con el que se encontró un yacimiento de mineral importante). Existen también sistemas de planificación, pudiéndose encontrar aplicaciones en este área, que establecen una secuencia de acciones a realizar encaminadas a la consecución de una serie de objetivos. En las empresas, la Inteligencia Artificial, que se encontraba confinada en la "sala de ordenadores", se va abriendo paso hacia la junta directiva. La razón de esto es simple: a medida que el mundo empresarial se complica y se llega a la competencia internacional, el conocimiento se convierte en el factor profesional más importante para un ejecutivo. A la persona que esté planeando la estrategia a seguir por su empresa o que tome decisiones en producción, marketing, distribución o asignación de recursos, los Sistemas Expertos le pueden demostrar que se pueden tomar decisiones con más conocimiento, llevando a un aumento de ganancias así como a la obtención de beneficios importantes para la empresa, como el aumento de su capacidad. La medida de la efectividad de las operaciones de planificación y control de una organización y su sensibilidad a los cambios, son elementos importantes en la buena dirección de la producción. Los planes y las decisiones en la producción se desarrollan y llevan a cabo en un mundo de representaciones simbólicas de hechos y conjeturas, muchas de las cuales no están informatizadas y representan la experiencia y el conocimiento de expertos. En cada estadio de los procesos de planificación, decisión y control para las operaciones de producción, sea ésta automatizada o no, las personas expertas son las que asesoran, localizan los fallos y dirigen. Ellas son las que ayudan a interpretar la multitud de datos procedentes de los departamentos de diseño, de la planta de producción y de los representantes de los clientes, observan modelos procesables en dichos datos, prueban mentalmente, y con ordenadores, posibles líneas de acción, recomiendan las medidas que la gerencia debe tomar y ayudan luego a poner en marcha sistemas pensados para conseguir planificaciones mejores, operaciones más fluidas y una competencia más efectiva. Los Sistemas Expertos ofrecen procedimientos informatizados para perfeccionar la toma de decisiones de la gerencia por medio de la combinación del conocimiento que poseen los expertos acerca del tipo de acciones que tiene que efectuar y la forma y el tiempo en que debe llevarlas a cabo con la permanencia, lógica, memoria y velocidad de cálculo del ordenador. En tanto que muchos sistemas expertos se ocupan del razonamiento técnico más que del gerencial, la gerencia puede obtener ordenadores de mucha potencia, con grandes memorias, rápidos y programados para tratar problemas clave de forma efectiva en un área empresarial determinada. Hay una tendencia creciente a desarrollarlos y utilizarlos, sin embargo, los programas son caros y tienen que ser

��

analizados con cuidado para determinar su contribución potencial al resultado final. Una de tales aplicaciones es el Palladian Operations Advisor (de Palladian Software, Inc., en Estados Unidos), diseñado específicamente para la dirección de la producción. Las entradas a este programa comprenden las designaciones de procesos y máquinas de fabricación de una planta, las especificaciones de productos y el flujo de producción, a partir de lo cual puede representar gráficamente la planta industrial y el flujo de cada tipo de productos. Con estas representaciones pueden organizarse y reorganizarse las operaciones de fabricación. El programa ayuda a la planificación y programación, asesorando en lo que se refiere a los programas que reducen el trabajo no deseable en niveles de proceso, ajustan el volumen de producción a la demanda de clientes y evalúan los cambios en las operaciones desde los puntos de vista económico y de producción. Puede crear una influencia recíproca con los planificadores y directores de planta a medida que las condiciones cambian a diario o a cada hora, como consecuencia de averías mecánicas, modificaciones en los pedidos de los clientes o crisis en el exterior. El Palladian Operations Advisor puede analizar el estado de la combinación de productos para mantener la mayor eficacia y rentabilidad posible de las operaciones. Como caso concreto dentro de la CAPV, la empresa DATALDE ha desarrollado un Sistema Experto para la planificación de la producción. Dicho trabajo se centra en un taller de propósitos generales de unas características determinadas, consistiendo la planificación en ordenar en el tiempo las cargas originadas por los diferentes pedidos, de forma que se asuman los objetivos de cumplimiento de plazos, distribución eficaz del trabajo y gestión de colas y prioridades. Por su parte, la empresa ROBOTIKER ha desarrollado un sistema de planificación y control de producción integral, dentro del que se identifican algunas tareas susceptibles de resolución mediante sistemas inteligentes (es un sistema basado en MRP-II). El éxito del directivo experto en la aplicación de sistemas como los citados en las plantas de fabricación, grandes o pequeñas, se mide por resultados tales como rendimientos mayores en la calidad de los productos, entregas a los clientes dentro de plazo, reducción de los retrasos en planta, reducción de costes procedentes de errores, mejor utilización de los materiales, mejor utilización del personal y mejora en las compras y reducción en los costes de material. El diseño es también un tema de planificación. En este caso, a partir de una serie de requerimientos y restricciones, se obtiene el objeto que las satisface. En este campo, LABEIN (Laboratorio de Ensayos e Investigaciones Industriales, Centro de Investigación tutelado por el Gobierno Vasco), desarrolló un sistema inteligente para el diseño de motores eléctricos mediante la aplicación de las tecnologías clásicas de Sistemas Expertos a los sistemas de CAD/CAE de diseño y análisis. El problema que motivó este proyecto era que ciertos motores, de entre los eléctricos, son de uso frecuente en la industria exigiendo a la vez un diseño a medida de cada caso, por ello se creyó conveniente desarrollar una herramienta que asesorase o, incluso, dirigiera al operador. Otro tipo de Sistemas Expertos son los orientados a la reparación, sin embargo, no se puede decir que sea un tipo realmente nuevo, ya que este enfoque abarca diagnosis y planificación. Dentro de este grupo se incluyen sistemas como DELTA, que ayuda a los mecánicos en el diagnóstico y reparación de locomotoras diesel-eléctricas. DELTA no solo da consejos expertos, sino que también presenta informaciones por medio de un reproductor de vídeo. De hecho se podría encasillar a DELTA más en el área de la instrucción que en reparación, dado que además proporciona ayudas al trabajo que permiten al estudiante determinar si existe o no un determinado problema, proporcionando también formación específica sobre el modo de realizar ciertas reparaciones.

��

Un sistema de instrucción (Sistema Experto para formación) realiza un seguimiento del proceso de aprendizaje de un estudiante. El sistema detecta errores de los estudiantes e identifica el remedio adecuado, es decir, desarrolla un plan de enseñanza para facilitar el proceso de aprendizaje y la corrección de errores. Además de DELTA, existen numerosos sistemas de este tipo; STEAMER, por ejemplo, se creó para enseñar a los oficiales de la armada los problemas de funcionamiento de una planta de propulsión a vapor, como las que impulsan a ciertos barcos. Este era el problema de formación más importante que existía, dada la complejidad de los sistemas. El objetivo es dar al estudiante una concepción global de lo que pasa en la planta en cualquier momento, con la ventaja de que además el modelo de presentación es gráfico (utilizando Interlisp). Con un objetivo similar al de STEAMER, Construcciones Aeronáuticas S. A. (CASA) desarrolló el Proyecto Eolo CN-235. En este caso, el problema está en el hecho de que pilotar un avión que cuesta cientos de millones de pesetas es un asunto muy serio a la vez que peligroso, lo que exige mucho tiempo de entrenamiento, tanto para pilotos como mecánicos, suponiendo para las compañías aéreas un gran problema, dado el elevado coste de los cursos y la escasez de instructores. El proyecto surgió de la voluntad de Construcciones Aeronáuticas S. A. de ofrecer un curso específico para pilotos y técnicos de mantenimiento, a todos los compradores del avión CN- 235. Eolo CN-235 es un sistema de enseñanza interactivo que integra gráficos, texto y vídeo. Otro sistema de este tipo, aunque en este caso orientado a medicina, es GUIDON, pensado para que lo utilicen las Facultades de Medicina para formar a los médicos en la realización de consultas. GUIDON viene a ser una reorganización de MYCIN con intenciones educativas, por esto, tiene la ventaja adicional de disponer de toda la base de conocimientos de MYCIN además de la experiencia acumulada, por consiguiente, puede recuperar como ejemplo cualquier caso que MYCIN haya tratado. Además de las áreas de aplicación ya citadas, existen otras como las relativas a los sistemas de interpretación, que realizan tareas de inferencia a partir de una serie de datos observables (por ejemplo análisis de imágenes, o bien interpretación de señal). Para concluir con esta exposición de aplicaciones de Sistemas Expertos, solamente indicar que el futuro de dichas aplicaciones pasa por la imaginación de cada uno, siempre que el área elegida requiera la presencia de un experto para la obtención de cualquier tipo de beneficio. Nociones del funcionamiento de los Sistemas Expertos

Descripción Del Esquema Para realizar un sistema experto son necesarias dos personas, el Experto del Dominio (El veterinario, para éste trabajo en particular) y un Ingeniero de Conocimiento (programador), estos van enlazar sus experiencias almacenándolos en la Base de conocimientos que mediante la interface va a permitir al usuario llegar a comunicarse con el motor de inferencia, el cual va a tomar la decisión de aplicar todo lo almacenado en la base de conocimientos. La Base de conocimiento se halla en la base datos y ésta está compuesta por lenguajes de predicado, ésta es uno de los componentes que contiene el conocimiento del experto, su función es almacenar experiencias, conocimientos, etc., de una determinada área. Existen dos tipos de base de conocimiento: El procedural;

��

Se usa en los lenguajes estructurados como son Pascal, C, Visual Basic etc. El declarativo; Esta basado en hechos que vienen a ser acciones que se dan dentro del problema se utilizan los lenguajes Prolog y Lisp. El Motor de Inferencia Su función es administrar, como, cuando, y las reglas de producción que se aplicaran para la solución de un determinado problema Dirige y controla la implementación del conocimiento, además permite decidir que tipos de técnicas se usaran durante el diseño del sistema experto. La Interfase Parte que permite la comunicación con el usuario, en forma vi direccional. Mediante al Interfase el Motor de Inferencia reconoce la pregunta y saca datos de la Base de Conocimiento y mediante la Interfase responde la pregunta Descripción del esquema de inferencia: DEMONIO; Es la parte principal de la estructura de control el cual va seguir un encadenamiento hacia atrás y hacia delante y esta a su vez está compuesta de dos campos específicos PROCEDIMIENTOS ESPECIALES son los pasos a seguir compuestas por reglas, normas de producción, ELEMENTOS DE METACONOCIMIENTO compuestas por redes neuronales, por que está es la capacidad de aprender, entender y responder a la pregunta realizada por un usuario. Todo esto se interrelaciona a partir de cierto conocimiento deducido durante la ejecución de la aplicación. Esto nos va a conllevar a una RUPTURA en la que el demonio retorna para cumplir un FUNCIONAMIENTO SISTEMÁTICO usando tipos de búsqueda implementada y completa. Primero se da el primer funcionamiento del motor de estructura que esta dado con los procedimientos especiales y con los elementos de metaconocimiento, todo esto experimentado lo vamos a llevar al principal funcionamiento sistemático con una búsqueda implementada, para dar lugar a un respuesta satisfactoria para quien lo está usando o manejando. Explicada la arquitectura, como Base de Conocimientos vamos a tener hechos y reglas de un sistema determinado las cuales van a ser codificadas para que la computadora puede interpretar, y ser utilizada adecuadamente por los usuarios y de acuerdo a la aplicación. Estos resultados van a servir a otros sistemas y que estos van a alimentar a nuestras bases de conocimientos originales para obtener mejores resultados. Sistemas Expertos Basados en Reglas Introducción: En nuestra vida diaria encontramos muchas situaciones complejas gobernadas por reglas deterministas: sistemas de control de trafico, sistemas de seguridad, transacciones bancarias, etc. Los sistemas basados en reglas son una herramienta eficiente para tratar estos problemas. Las reglas deterministas constituyen la mas sencilla de las metodologías utilizadas en sistemas expertos. La base de conocimiento contiene las variables y el conjunto de reglas que definen el problema, y el motor de inferencia obtiene las conclusiones aplicando la lógica clásica a estas reglas. Por regla se entiende una proposición lógica que relaciona dos o mas objetos e incluye dos partes, la premisa y la conclusión. Cada una de estas partes consiste en una expresión lógica con una o mas afirmaciones objeto-valor conectadas mediante los operadores lógicos y, o, o no. Una regla se escribe normalmente como "Si premisa,

��

entonces conclusión". Como ejemplo de problema determinista que puede ser formulado usando un conjunto de reglas, considérese una situación en la que un usuario (por ejemplo, productor ganadero) desea saber si un animal X está en condiciones de seguir siendo parte del plantel de reproductoras. En cuanto el usuario ingresa la caravana del animal, el sistema verifica si la caravana ingresada es correcta. Si caravana no es verificada con éxito (por ejemplo, porque no existe), el Sistema devuelve mediante un mensaje el mensaje de error correspondiente. En otro caso, el Sistema pide al usuario que ingrese los criterios por cual desea calificar como apto o no al animal. Si el o los criterios seleccionados no pueden utilizarse porque esos datos no están registrados, el sistema obvia esos criterios. Si esos criterios pueden ser considerados, el sistema pide al usuario que ingrese los parámetros con los cuales será calificado el animal. En este caso se tienen N objetos, dependiendo de los criterios incluidos, y cada objeto puede tomar uno y solo un valor de entre sus posibles valores. La Tabla 1 muestra estos objetos y sus posibles valores. La Figura 1 muestra siete reglas que gobiernan la estrategia que el CA debe seguir cuando un usuario intenta sacar dinero de su cuenta.

Objeto Conjunto de Posibles Valores

Caravana {Verificada, No Verificada} Peso {Suficiente, Insuficiente}

Cond.Corp {Correcta, Incorrecta} Área Pelvica {Superior, No superior} Efic.Repro. {Suficiente, Insuficiente} Efectividad {Alcanzo, No Alcanzo} Se queda {Si, No }

Tabla1. Objetos y Posibles Valores para el ejemplo del Sistema de selección de animales

Regla 1 Si caravna = Verificada y Peso = Suficiente CondCorporal = correcta: y Área pélvica = Superior y Efectividad = Alcanzo => Se queda = Si

Regla 2 Regla 3

Si caravna = No Verificada => Se queda = No

Si Área pélvica = Inferior Se queda = No

Regla 4 Regla 5 Sí Peso= Insuficiente

=> Se queda = No Sí Efectividad = no Alcanzo

=> Se queda = No Regla 6

Si Cond Corp = Incorrecta => Se queda = No

Figura 1. Ejemplos de Reglas para seleccionar una hembra reproductora)

��

El motor de Inferencia Tal como se ha mencionado anteriormente existen dos tipos de elementos, los datos (hechos y evidencias) y el conocimiento (conjunto de reglas almacenadas en la base del conocimiento) El motor de inferencia usa ambos para obtener nuevas conclusiones o hechos. Por ejemplo, si la premisa de una regla es cierta, entonces la conclusión de la regla debe ser también cierta. Los datos iniciales se incrementan incorporando las nuevas conclusiones. Por ello, tanto los hechos iniciales o datos departida como las conclusiones derivadas de ellos forman parte de los hechos o datos de que se dispone en un instante dado. Para obtener conclusiones, los expertos utilizan diferentes tipos de reglas y estrategias de inferencia y control (véase, por ejemplo, Durkin [2]). En el resto de esta sección se discuten las reglas de inferencia • Modus Ponens, • Modus Tollens, y las estrategias de inferencia • Encadenamiento de reglas, • Encadenamiento de reglas orientado a un objetivo, que son utilizadas por el motor de inferencia para obtener conclusiones simples y compuestas. Modus Ponens y Modus Tollens El Modus Ponens es quizás la regla de inferencia mas comúnmente utilizada. Se utiliza para obtener conclusiones simples. En ella, se examina la premisa de la regla, y si es cierta, la conclusión pasa a formar parte del conocimiento. Como ilustración, supóngase que se tiene la regla, "Si A es cierto, entonces B es cierto" y que se sabe además que "A es cierto". La regla Modus Ponens concluye que "B es cierto." Esta regla de inferencia, que parece trivial, debido a su familiaridad, es la base de un gran número de sistemas expertos. La regla de inferencia Modus Tollens se utiliza también para obtener conclusiones simples. En este caso se examina la conclusión y si es falsa, se concluye que la premisa también es falsa. Por ejemplo, supóngase de nuevo que se tiene la regla, "Si A es cierto, entonces B es cierto" pero se sabe que "B es falso." Entonces, utilizando la regla Modus Ponens no se puede obtener ninguna conclusión pero la regla Modus Tollens concluye que "A es falso". El rendimiento del motor de inferencia depende del conjunto de reglas en su base de conocimiento. Hay situaciones en las que el motor de inferencia puede concluir utilizando un conjunto de reglas, pero no puede, utilizando otro (aunque éstos sean lógicamente equivalentes). Encadenamiento de Reglas

Una de las estrategias de inferencia más utilizadas para obtener conclusiones compuestas es el llamado encadenamiento de reglas. Esta estrategia puede utilizarse cuando las premisas de ciertas reglas coinciden con las conclusiones de otras. Cuando se encadenan las reglas, los hechos pueden utilizarse para dar lugar a nuevos hechos. Esto se repite sucesivamente hasta que no pueden obtenerse más conclusiones. El tiempo que consume este proceso hasta su terminación depende, por una parte, de los hechos conocidos, y, por otra, de las reglas que se activan. Este algoritmo puede ser implementado de muchas formas. Una de ellas comienza con las reglas cuyas premisas tienen valores conocidos. Estas reglas deben concluir y sus conclusiones dan lugar a nuevos hechos. Estos nuevos hechos se añaden al conjunto de hechos conocidos, y el proceso continúa hasta que no pueden obtenerse nuevos hechos. La

��

Figura 2 muestra un ejemplo de seis reglas que relacionan 13 objetos, del A al M. Las relaciones entre estos objetos implicadas por las seis reglas pueden representarse gráficamente, tal como se muestra en la Figura 3, donde cada objeto se representa por un nodo. Las aristas representan la conexión entre los objetos de la premisa de la regla y el objeto de su conclusión. Nótese que las premisas de algunas reglas coinciden con las conclusiones de otras reglas. Por ejemplo, las conclusiones de las Reglas 1 y 2 (objetos C y G) son las premisas de la Regla 4. Regla 1 Regla 2 Regla 3

Sí A y B => C Sí D,E y F => G Sí H e I => J

Regla 4 Regla 5 Regla 6

Sí C y G => K Sí G y J => L Sí K y L => M Figura 2. Un ejemplo de 6 Reglas relacionando 13 Objetos Supóngase que se dan los hechos H = cierto, I = cierto, K = cierto y M = falso. Supóngase, en primer lugar, que el motor de inferencia usa las dos reglas de inferencia Modus Ponens y Modus Tollens. En este caso, se obtiene 1. La Regla 3 concluye que J = cierto (Modus Ponens). 2. La Regla 6 concluye (Modus Tollens) que K = falso o L = falso, pero, puesto que K

= cierto, debería ser L = falso. 3. La Regla 5 concluye (Modus Tollens) que G = falso o J = falso, pero, puesto que J

= cierto, debería ser G = falso.

A C

B Regla 1 K

D Regla 4 M

E G Regla 6 Regla 2

F L Regla 5

H J I Regla 3

Figura 3. Una Representación Gráfica de las Relaciones entre las seis reglas fe la Figura 2.

En consecuencia, se obtiene la conclusión G = falso. Sin embargo, si el motor de inferencia solo utiliza la regla de inferencia Modus Ponens, el algoritmo se detendría en

��

la Etapa 1, y no se concluirá nada para el objeto G. Este es otro ejemplo que ilustra la utilidad de la regla de inferencia Modus Tollens.

Tratamiento de la Incertidumbre Introducción: Como en el presente se han ocupado de la manera adecuada de razonar, aunque en cada caso es diferente lo que se entiende por ello. En el caso de la lógica de primer orden, el razonamiento adecuado significa la obtención de conclusiones a partir de premisas; si la base de conocimientos original representa fidedignamente al mundo, entonces las inferencias también lo representarán fielmente. En el caso de la probabilidad, manejamos creencias, no el estado del mundo, y en este caso "razonamiento adecuado" significa contar con creencias que permiten a un agente actuar de manera racional.

Se ha visto una gran variedad de métodos para abordar el problema de la implantación de los sistemas de razonamiento lógico. El razonamiento eficiente mediante la probabilidad es tan reciente que solamente hay un método -las redes de creencia-, del que existen sólo ligeras variantes. Lo más importante es lo siguiente:

La información sobre la independencia condicional es una forma vital y sólida de estructurar información sobre un dominio incierto.

Las redes de creencia constituyen una manera natural de representar la información sobre la independencia condicional. Los vínculos entre los nodos representan los aspectos cualitativos del dominio; las tablas de probabilidad condicional representan los aspectos cuantitativos.

Una red de creencia es una representación completa de la distribución de probabilidad conjunta correspondiente a un dominio, pero su tamaño es exponencialmente menor.

La inferencia en las redes de creencia implica el cálculo de distribución de probabilidad de un conjunto de variables de consulta, a partir de un conjunto de variables de evidencia.

Las redes de creencia pueden razonar de manera causal, por diagnóstico, de modo combinado o de forma intercausal.

Ningún otro mecanismo de razonamiento bajo condiciones de incertidumbre puede manejar todos los modos anteriores.

La complejidad de la inferencia en una red de creencia dependerá de la estructura de la red. En el caso de los poliárboles (redes con una sola conexión), el tiempo de cálculo es función lineal del tamaño de la red.

Existen varias técnicas de inferencia que son utilizadas en las redes de creencia general, y en todas ellas la complejidad es exponencial en el peor de los casos. En los dominios reales, la estructura local tiende a que las cosas sean más factibles, aunque hay que poner atención para construir una red manejable en donde haya más de un centenar de nodos.

También es posible utilizar técnicas de aproximación, incluida la simulación estocástica, para obtener una estimación de las verdaderas probabilidades haciendo menos cálculos.

��

Se propusieron diversos sistemas alternos para razonar en condiciones de incertidumbre. En todos los sistemas funcionales de verdad hay serios problemas relacionados con el razonamiento mezclado o intercausal.

En la Lógica clásica, lo único que puede deducirse de una regla ("Modus Ponens" y "Modus Tollens") es que si su premisa es cierta, también lo será su conclusión (ver Figura 5). Por tanto, dada la regla: "Si A es cierto, entonces B es cierto" puede decirse que A implica B con probabilidad 1 (Figura 5)(a)). Sin embargo, este modelo tiene importantes limitaciones, porque son habituales las situaciones prácticas en las cuales no es válido el modelo anterior. Por ejemplo, la presencia de algunos síntomas no garantiza siempre la existencia de una enfermedad. Por tanto, sería muy útil generalizar la lógica clásica y por medio de una lógica "incierta". En este nuevo contexto, la regla anterior puede generalizarse de la forma siguiente: "A implica B con probabilidad P r(B|A)", donde P r(B|A) es la probabilidad de B dado A (Figura 5)(b)). Además, el otro extremo de la lógica clásica, representado por la regla: "A implica B con probabilidad 0" puede ser generalizado por "A implica B’ con probabilidad 1", donde B’ denota el complementario de B (Figura 5)(c)). Uno de los problemas relacionados con este tipo de lógica es la propagación de incertidumbre. Obsérvese que ahora cada sentencia (hecho) debe estar acompañada de una medida de incertidumbre (probabilidad, factor de certeza, etc.) y que, cuando se combinan varios hechos, ha de darse a las conclusiones obtenidas una medida de su incertidumbre. Sin embargo, el problema principal es que aunque se conozca la medida de incertidumbre asociada con las premisas, las conclusiones pueden tener, en teoría, un número infinito de valores inciertos. Además, si se permite la posibilidad de reglas inciertas la cosa se complica aún más. Este hecho muestra la necesidad del desarrollo de nuevos sistemas expertos, como los basados en la probabilidad

a) A=>B con P(B/A)=1

b) A=>B con 0 < P(B/A) > 1

c) A=> B con P(B/A) = 0

Ejemplos de implicaciones inciertas: (a) A implica B con P(B|A) = 1, (b) A implica B con

P(B|A) = p, donde 0 < p < 1, y (c) A implica B con P (B|A) = 0.

El razonamiento Bayesiano

Como anteriormente se ha mencionado el método más antiguo para el tratamiento de la incertidumbre es la probabilidad. Dentro del campo de la inteligencia artificial, surgieron críticas contra el uso de métodos probabilistas en sistemas expertos, especialmente porque las hipótesis necesarias para hacer tratable el método bayesiano clásico eran incorrectas en la mayor parte de los problemas del mundo real. Esto motivó el desarrollo de otros métodos, como los factores de certeza o la lógica difusa, en que se introducen implícitamente hipótesis y aproximaciones aún más exigentes. Afortunadamente, el desarrollo de las redes bayesianas en la década de los 80 permitió refutar las objeciones anteriores contra el uso de la probabilidad, construyendo un modelo de razonamiento causal con un sólido fundamento teórico. Por otro lado, los diagramas de influencia, que aparecen también en la década de los

��

80, pueden considerarse como una extensión de las redes bayesianas, que por tener nodos de decisión y nodos de utilidad, permiten resolver problemas de toma de decisiones. En la década de los 90 ha crecido exponencialmente el número de investigadores, universidades y empresas dedicados a este tema. A modo introductorio se dará un ejemplo esquemático del funcionamiento o el modo de procesamiento de un SE modelado mediante el razonamiento bayesiano, para el tratamiento de la incertidumbre Para una enfermedad que tiene una prevalencia del 8% existe una prueba que tiene una sensibilidad del 75% y una especificidad del 96% respecto de dicha enfermedad. ¿Cuáles son los valores predictivos de la prueba?

Primera esquematización (Red formada por nodos, y la relación entre ambos)

En este problema intervienen dos variables: Enfermedad y Prueba. La enfermedad puede tener dos valores, presente y ausente, y la prueba puede dar dos resultados, positivo y negativo. Dado que la primera variable influye causalmente sobre la segunda, vamos a trazar un enlace Enfermedad->Prueba.

Probabilidades condicionales

Para la variable Enfermedad, la (TPC) Tabla de Probabilidades Condicioneales viene dada por su prevalencia, que nos dice que P(Enfermedad=presente) = 0.08, y por tanto, P(Enfermedad=ausente) = 0.92. Para la variable Prueba, la TPC se construye teniendo en cuenta que la sensibilidad (75%) es la probabilidad de que la prueba dé positivo cuando la enfermedad está presente, y la especificidad (96%) es la probabilidad de que la prueba dé negativo cuando la enfermedad está ausente. La TPC construida debe quedar así:

Enfermedad Presente Ausente Positivo 0,75 0,04 Negativo 0,25 0,96

Enfermedad

Prueba

��

Inferencia del Sistema Una vez que se ha creado la red y asignado los respectivos valores de probabilidades para las variables, el siguiente paso, es hacer que el sistema calcule lo que el problema plantea. Primeramente el sistema debe calcular las probabilidades a priori, para que luego se puedan calcular los valores predictivos. Esto es; Probabilidades a priori P(Prueba =positivo) = P(Prueba =positivo | Enfermedad =presente) ×

P(Enfermedad =presente) + P(Prueba =positivo | Enfermedad =ausente)×P(Enfermedad =ausente) = =0.75×0.08 + 0.04×0.92 = 0.0968

P(Prueba =negativo) = P(Prueba =negativo | Enfermedad =presente)×P(Enfermedad =presente) +

P(Prueba =negativo | Enfermedad =ausente)×P(Enfermedad =ausente) = =0.25×0.08 + 0.96×0.92 = 0.9032

Internamente el esquema de la red será el siguiente Probabilidades a Posteriori La pregunta planteaba el problema inicial era calcular los valores predictivos. El valor predictivo positivo (VPP) es la certeza con que se puede diagnosticar la enfermedad cuando la prueba da positivo:

��

Presente = 0,08 Ausente = 0,92

��

Positivo = 0,10 Negativo = 0,90

��

VPP = P(Enfermedad = presente | Prueba = positivo) = [P(Prueba = positivo / Enfermedad = presente) x P(Enfermedad = presente)] / P(Prueba = positivo)

VPP=[0.75 x 0.08] / 0.0968 = 0.62 = 62 % El sistema debe arrojar éste resultado, es decir el usuario decidirá si diagnostica la enfermedad; sabiendo que la probabilidad que la enfermedad se presente, cuando la prueba es positiva, es del 62%

El valor predictivo positivo (VPN) es la certeza con que se puede descartar la enfermedad cuando la prueba da Negativo:

VPN = P(Enfermedad = ausente | Prueba = negativo) = [P(Prueba = negativo

/ Enfermedad = ausente) x P(Enfermedad = ausente)] / P(Prueba = negativo)

VPN=[0.96 x 0.92] / 0.9032 = 0.98 = 98 % Contrariamente el usuario decidirá si descarta la enfermedad; sabiendo que la probabilidad que la enfermedad esté ausente, cuando la prueba es negativa, es del 98% Esta demostración fundamenta el nombre del razonamiento, para obtener éstos valores se usa el “Teorema de Bayes”

��

Sistemas de Soporte a la toma de Decisiones (DSS)

En los setenta, muchas empresas comenzaron a desarrollar sistemas de información muy diferentes de los sistemas de información para la administración (SIA) tradicionales. Esos nuevos sistemas eran más pequeños (en términos de mano de obra y costo), eran interactivos (poco común en ese tiempo), y estaban diseñados para ayudar a los usuarios finales a utilizar datos y modelos para discutir y decidir (no resolver) problemas semiestructurados y no estructurados. A finales de los 80, estos primeros esfuerzos para ayudar a la toma de decisiones individual se extendieron a los grupos y a las empresas.

MODELO ADMINISTRATIVO.

El modelo clásico de administración que describe lo que los administradores hacen, permaneció incuestionado por mas de 70 años desde los veinte. Henry Fayol y otros autores contemporáneos fueron los primeros en describir las cinco funciones clásicas de los administradores: planeación, organización, coordinación, decisión y control. Esta descripción de las actividades administrativas, dominó la administración durante un largo periodo, y sigue siendo popular hoy día.

El modelo clásico de las funciones administrativas es planeación, organización, coordinación, decisión y control en estas cae la toma de decisiones administrativas. Los modelos conductuales afirman que el comportamiento real de los administradores parece ser menos sistemático, más informal, menos reflexivo, mas reactivo, menos organizado y mucho más frívolo que lo que los estudiantes de los sistemas de información y toma de decisiones esperan que sea.

Un estudio famoso del comportamiento real de los administradores conducido por Mintzgerg (1971), indica que el comportamiento real contrasta con la descripción clásica. Primero, los investigadores modernos han encontrado que el administrador realiza una gran cantidad de trabajo a paso veloz y trabaja con un alto nivel de intensidad. Segundo, las actividades gerenciales son fragmentadas y breves. Tercero, los administradores prefieren la especulación, el ruido, el chisme; en síntesis, les agrada al información actualizada y fresca aun cuando incierta. Cuarto, los administradores mantienen una red compleja de contactos que actúa con un sistema informal de organización. Quinto, los administradores prefieren formas verbales de comunicación a las escritas, porque las primeras proporcionan mayor flexibilidad, requieren de menor esfuerzo y conllevan a una respuesta más rápida.

A pesar del diluvio de trabajo, la presión los administradores de éxito parecen tener la capacidad de controlar sus propios asuntos, estos también pueden controlar las actividades en las que desean involucrarse sobre la base diaria. Al desarrollar sus compromisos a largo plazo, sus propios canales de información y sus propias redes, los altos directivos pueden controlar sus propias agendas personales.

��

Definición

Un DSS utiliza los recursos intelectuales de los individuos y la capacidad de las computadoras, para mejorar la calidad de las Decisiones. Es un sistema de soporte basado en computadora, para Directivos que toman decisiones sobre problemas semi-estructurados, y/o estructurados.

Tipos de Sistemas de Apoyo a las Decisiones:

• Sistema de Soporte a la toma de Decisiones (DSS) • Sistemas de Información para Ejecutivos (EIS) • Sistemas para la toma de Decisiones en Grupo (GDSS) • Sistemas Expertos de Soporte la toma de Decisiones (EDSS)

CRACTERISTICAS DE LOS SISTEMAS DE SOPORTE A LA TOMA DE DECISIONES

• Interactividad: sistema computacional con la posibilidad de interactuar en forma amigable y con respuestas a tiempo real con el encargado de tomar decisiones.

• Tipo de decisiones: Apoya el proceso de toma de decisiones estructuradas y no estructuradas.

• Frecuencia de Uso: Tiene una utilización frecuente por parte de la administración media y alta para el desempeño de su función.

• Variedad de Usuarios: Puede emplearse por usuarios de diferentes áreas funcionales como ventas, producción, administración, finanzas y recursos humanos.

• Flexibilidad: Permite acoplarse a una variedad determinada de estilos administrativos: Autocráticos, Participativos, etc.

• Desarrollo: Permite que el usuario desarrollo de manera directa modelos de decisión sin la participación operativa de profesionales en informática.

• Interacción Ambiental: Permite la posibilidad de interactuar con información externa como parte de los modelos de decisión.

• Comunicación Inter-Organizacional: Facilita la comunicación de información relevante de los niveles altos a los niveles operativos y viceversa, a través de gráficas.

• Accesoa base de Datos: Tiene la capacidad de accesar información de las bases de datos corporativos.

• Simplicidad: Simple y fácil de aprender y utilizar por el usuario final.

Componentes Funcionales que integran un DSS:

Una de las características que poseen un DSS es la facilidad que un usuario, sin tener conocimientos amplios sobre sistemas computacionales, pueda desarrollar sus propios

��

modelos de decisión. Estos modelos son construidos con ayuda de herramientas, que en términos generales se clasifican en herramientas de hardware y software. Las primeras están constituidas por todos los elementos del hardware, incluyendo microcomputadoras, monitores de alta resolución, impresoras, etc. Las herramientas de software son aquellas que permiten al usuario generar sus propias aplicaciones, manipular su información particular y, en genral, interactuar con el DSS.

El Modelo

Esta facilidad permite al usuario utilizar modelos clásicos, que se encuentran desarrollados y disponibles, formando la base de modelos. Estos pueden incluir:

• Inventarios • Control de proyectos • Programación lineal • Simulación • Colas • Análisis Estadísticos • Planeación financiera de escenarios

Es una representación abstracta en donde se ilustran los componentes o relaciones de un fenómeno. La Base de Datos.

Es una colección de datos actuales o históricos de un número de aplicaciones o grupos, organizada para un acceso fácil a partir d una gama de aplicaciones.

Otras de las facilidades de los DSS, es la posibilidad de manejar y almacenar información, incluyendo funciones tales como:

• Acceso a las bases de datos corporativas. • Generación de información privada en bases de datos locales. • Manipulación de la información a través de técnicas de manejo de información,

consolidaciones, etc.

BASES DE DATOS CORPORATIVAS. Es la base de datos que integra toda la información de la compañía, la cual pueden consultar los diferentes usuarios para construir y utilizar herramientas para la toma de decisiones.

BASES DE DATOS LOCALES Y ARCHIVOS PROPIETARIOS. Las bases de datos locales y los archivos propietarios son generados y utilizados por los usuarios, para lo cual debe de tomarse de la base de datos corporativa. Las bases de datos locales y los archivos propietarios pueden ser manipulados por el usuario, permitiendo su creación, consulta y modificación.

��

Sistema de Software

Permite una interacción fácil entre los usuarios del sistema y la base de datos del DSS y la base de modelos.

Interfase con el Usuario

Una parte fundamental de los DSS es facilidad para explorar la información a través de gráficas de alta calidad y reportes que se diseñan y obtienen en intervalos cortos de tiempo, así como la disponibilidad de lenguajes de muy alto nivel para facilitar la consulta de información que contiene la base de datos.

La mayoría de los DSS permiten a los usuarios desarrollar sus propios modelos de decisión. Esto implica la posibilidad de manejar entrada, procesamiento, almacenamiento, y salida de información.

En este sentido el usuario diseña sus propios formatos de entrada y salida, así como la estructura de almacenamiento de información y las funciones de procesamiento, de tal forma que el sistema puede evolucionar de manera permanente, a trabés de los cambios que periódicamente se van integrando a la aplicación. Esta forma de desarrollo denominada prototipo, es diferente al proceso tradicional de desarrollo de un sistema transaccional típico. En este último, el usuario tiene que definir de antemano todos los requerimientos de sus sistemas de aplicación durante las fases de análisis antes de iniciar la fase de diseño.

Otra característica que se deriva de estos Sistemas de desarrollo es el concepto de aplicaciones desechables; es decir, modelos de decisión que fueron desarrollados en un tiempo muy corto, para apoyar una decisión particular. Una vez tomada la decisión no repetitiva, el modelo que se desarrolló carece de valor y desecha, o bien, se almacena para usarse con modificaciones en una decisión posterior.

Factores para el Éxito de un DSS

• Capacitación • Involucramiento • Experiencia de los usuarios • Apoyo de la alta dirección • Nivel de utilización • Novedad de la aplicación

Aplicaciones

Una de las aplicaciones que se podrían tener en el modelo de soporte a la toma de decisiones es que puede utilizarse en la industria para desarrollar y actualizar el presupuesto de operaciones y financiero, el cual debido a la extensa gamas de

��

productos y líneas que maneja es necesario incorporarla a través de un modelo computacional. Y porque no también en la cría de ganado vacuno donde es necesario evaluar proyectar y diseñar un nuevo plan de producción en el campo. Es importante resaltar la conveniencia de que toda la información que se utiliza en este modelo provenga de los sistemas transaccionales de la empresa, tales como movimiento de animales, registro de pesos, movimientos sanitarios, cría y recría propiamente dicha, etc.

Ejemplo de Aplicaciones:

Organización Aplicación Bank of America ....................... Perfil del cliente Burlington Coat Factory............. Local del negocio e inventarios National Gypsum....................... Planeación corporativa y dirección

Tendencias Futuras

• Apoyo a las decisiones simultaneas: Los sistemas de apoyo en un futuro tendrán una fuerte tendencia a apoyar el proceso de decisiones en grupo a través de los sistemas de apoyo para la toma de decisiones en grupo. Lo cual será posible gracias al desarrollo e innovación de las comunicaciones de datos en funciones tales como correo electrónico, redes locales y tele conferencias.

• Sistemas distribuidos de apoyo a las decisiones: Lo anterior implica la existencia de sistemas de apoyo a las decisiones desarrolladas en diversas localidades remotas, reforzando las comunicaciones de datos entre los mainframes o servidores y las computadoras personales, lo cual será útil para la toma de decisiones secuenciales. En este caso se requerirá de los principales paquetes de apoyo a las decisiones secuénciales. En este caso se requerirá de los principales paquetes de apoyo a las decisiones se desarrollen para que corran en computadoras personales y mainframes, para lo cual deben resolver las interfaces entre ellas.

• Apoyo gráfico: Los soportes gráficos agilizaran la visualización de la información de la información y por ende, la velocidad con que se tomen las decisiones.

• Computadoras personales: Se seguirán utilizando las computadoras personales para el apoyo al proceso de toma de decisiones, principalmente con el uso de hojas electrónicas, gráficas y bases de datos personales.

• Reconocimiento de voz: Se tenderá a sistemas altamente compatibles que puedan incluso trabajar con patrones de reconocimiento de voz, lo cual minimizará la entrada de información por medio del teclado.

• Descentralización del proceso de toma de decisiones: Tradicionalmente el proceso de toma de decisiones ha estado centralizado en la mayoría de las organizaciones. Sin embargo, los estándares de trabajo que imponen las técnicas de calidad total y reingeniería de procesos presuponen que las decisiones deben tomarse en el nivel más bajo posible de la organización, a fin de poder reaccionar con rapidez a las continuas y cambiantes demandas de los clientes. Esto requerirá que las personas dispongan de información fresca y actualizada en todos los niveles de la empresa.

��

Sistema Manejador de Base de Datos

El DBMS es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos. Se compone de un lenguaje de definición, de datos de un lenguaje de manipulación de datos y de un lenguaje de consulta. El lenguaje de definición de datos (DDL) es utilizado para describir todas las estructuras de información y los programas que se usan para construir, actualizar, e introducir la información que se contiene en una base de datos. El DDL contiene un diccionario de datos que se utiliza para almacenar y crear las definiciones de los datos. Incluyendo localización, forma en que se almacena y algunas otras características. El lenguaje de definición de datos debe permitir describir los datos y las estructuras de los archivos del sistema, especificando la forma en que serán agrupados en registros o divididos en campos. Una vez que se tiene la definición de la base de datos, el DBMS se encarga de construir y generar las estructuras de información de manera automática. El lenguaje de manipulación de datos (DML) es utilizado para escribir programas que crean, actualizan y extraen información de las bases de datos. A pesar de que el DBMS proporciona gran ayuda al programador en ocasiones es necesario escribir programas para extraer datos dando respuestas a requisiciones especiales. El lenguaje de consulta (SQL) es empleado por el usuario para extraer información de la base de datos. El lenguaje de consulta permite al usuario hacer requisiciones de datos sin tener que escribir un programa, usando instrucciones como el SELECT, el PROJECT y el JOIN. La secuencia conceptual de operaciones que ocurren para accesar cierta información que contiene una base de datos es la siguiente: 1.- El usuario solicita cierta información contenida en la base de datos. 2.- El DBMS intercepta este requerimiento y lo interpreta. 3.- El DBMS realiza las operaciones necesarias para accesar y/o actualizar la información solicitada. Una de las ventajas del DBMS es que puede ser invocado desde programas de aplicación que pertenecen a sistemas transaccionales escritos en algún lenguaje de alto nivel para la creación o actualización de las bases de datos, o bien para efectos de consulta a través de lenguajes propios que tienen las bases de datos o lenguajes de cuarta generación.

Todo lo referido a consultas a la base de datos está ampliamente explicado en el apartado correspondiente al tema. Lenguaje de Consulta Estructurado (SQL)

Proceso de Toma de Decisiones

Para comprender las funciones que debería contemplar un SSD se revisarán las fases del proceso de toma de decisiones. Inteligencia: En esta fase se intenta definir el problema, sus síntomas, su magnitud. Se debe hacer una clasificación del mismo (estructurado, semi-estructurado, no estructurado). También se puede realizar una descomposición del problema en subproblemas para posibilitar un mejor análisis. Esta fase concluye con una sentencia que define el problema. Diseño: Esta fase involucra la generación, desarrollo y análisis de posibles cursos de acción. Aquí se construye un modelo del problema, se prueba y se valida. El modelo creado puede ser de tipo cualitativo o cuantitativo.

��

Elección: Una vez construido el modelo, esta fase incluye la búsqueda, evaluación y recomendación de una apropiada solución al mismo. Como salida de esta etapa se obtienen los distintos cursos de acción a tomar para resolver el problema. Para ello se cuenta con varias técnicas como "Múltiples Metas'', "Análisis Sensitivo'', "Búsqueda de Objetivo'', etc.

Implementación: Tal vez es esta la fase más complicada, la cual consiste en poner a trabajar la solución recomendada al problema.

Soporte a Cada Fase:

Un SSD debería dar apoyo a cada una de las distintas fases del Proceso de Toma de Decisiones. Soporte a la fase de Inteligencia: Un SSD debe proveer la habilidad de buscar en Bases de Datos internas y externas para detectar problemas y oportunidades. Para ello un SSD debe almacenar grandes volúmenes de información y proveer un acceso rápido y eficiente a la misma. La utilización de reportes (sumarizados, consolidados, comparaciones, pronósticos, etc.) son de suma utilidad en esta fase. (En la aplicación; Selección de Animales para ingresar a Servicio) Soporte a la fase de Diseño: En esta fase un SSD debe proveer la utilización de modelos (matemáticos, financieros, etc.) ya sean estándares o especiales. Por ejemplo, muchos SSD brindan métodos de pronósticos para ser aplicados a los datos contenidos en la Base de Datos Decisional de la organización. En síntesis un SSD debe brindar a esta fase la capacidad de armar modelos en función del problema definido. Soporte a la fase de Elección: Un SSD puede recomendar, pero no toma decisiones, puede identificar cual es la mejor alternativa o la más recomendada, pero el que toma la decisión es el Directivo. Un SSD da soporte a esta fase mediante técnicas como "Análisis sensitivo'', "Análisis Que-Si'', "Análisis Búsqueda de Objetivo''. Mediante estas técnicas se puede recomendar la mejor solución al problema. (En la aplicación Modulo selección de animales para descarte) Soporte a la fase de Implementación: En esta fase un SSD da soporte ayudando al

��

Directivo a explicar, justificar y comunicar la decisión tomada. Para ello se pueden utilizar reportes, gráficos, imágenes, modelos, etc.

Componentes de un SSD:

Administrador de Datos: Incluye las bases de datos que contendrán la información para la toma de decisiones (comúnmente conocido como DATA WAREHOUSE, en éste trabajo, el sistema usa una base de datos relacional (acces), y se confeccionó un modelo multidimencional a modo de explicación), el software de administración (DBMS) y los programas de traspaso de información desde la Base de Datos Transaccional (base de datos de los sistemas operativos) a la Base de Datos Decisional (Data Warehouse). La información a incluir en la Base de Datos Decisional puede ser:

Interna: Información extraída de los sistemas transaccionales, esta información se genera en el/los establecimiento/s ganadero/s y está almacenada en las bases de datos de los sistemas operativos. Por ejemplo información de alta de vacunos, información inventaria (pesos), egresos (venta de animales), planes sanitarios, etc.

Externa: Se refiere a información que no se produce en los Establecimientos Ganaderos, que no está contenida en las bases de datos transaccionales. Es información necesaria para conocer el entorno y las restricciones que impone el mismo. Esta información podría ser por ejemplo políticas económicas nacionales e internacionales, comportamiento de las bolsas de comercio en el mundo, variaciones de las monedas, tasas de interés, reportes tecnológicos, etc.. Esta información podría incorporarse a la Base de Datos Decisional y dejarla disponible para que cualquier Usuario experto desde su PC pueda consultarla. Personal: Este tipo de información incluye contribuciones personales de los expertos o gerentes, decisiones tomadas con anterioridad por los mismos, estimaciones subjetivas, opiniones, preferencias, todo tipo de información que la fuente sea de los mismos gerentes o expertos y que sirva como base de decisiones futuras. El Administrador de Base de Datos (DBMS) a utilizar puede ser del tipo relacional: Informix, SQL Server, Oracle, DB2, etc. o del tipo multidimensional (OLAP Server)

��

como Pilot, Essbase, CrossTarget, Analisys Manager, etc. Administrador de Modelos: Es un paquete de software que incluye modelos financieros, estadísticos, cuantitativos, cualitativos, etc. que proveen de capacidades analíticas al sistema. A la información contenida en la Base de Datos Decisional se le puede aplicar modelos matemáticos, enriqueciendo la información existente. Por ejemplo, en función de los ingresos y egresos de los meses anteriores, se podría aplicar un modelo de pronósticos para estimar los ingresos y egresos futuros. Administrador de Diálogo: Este componente se encarga de la interrelación entre el usuario con el Sistema de Soporte de Decisión. Aquí se deben tener en cuenta aspectos tales como accesibilidad, fácil utilización, interfaz máquina-hombre, flexibilidad, etc. que posibilite la mejor utilización de los recursos disponibles. Este componente establece un lenguaje de acción (muy simple y amigable) mediante el cual el usuario comunica el reporte que necesita. Es el lenguaje de entrada al SSD. Luego existe una representación visual, mediante la cual se le informa al usuario los resultados de la acción solicitada. Generalmente esta visualización se produce con gráficos (tortas, barras, líneas), alertas (reporte por excepción), mapas, grillas y semáforos. Mediante estos componentes un SSD colabora con las distintas fases del proceso de toma de decisiones. La construcción de cada uno de los componentes de un SSD no es una tarea sencilla, requiere fuertes conocimientos de la persona de sistemas como así también una alta participación de los Directivos.

Beneficios de los SSD

• Posibilidad de dar soporte de información a problemas complejos, generalmente problemas del tipo semi-estructurado o no estructurados.

• Permite contar con información que mejore el proceso de toma de decisiones, aportando mayor inteligencia a los problemas del usuario, pudiéndose aplicar soluciones más objetivas.

• Mejora el control y la performance de los usuarios de nivel gerencial ya que poseen información oportuna y amplia.

• Reduce costos al contar con información objetiva y oportuna para la toma de decisiones.

• Permite una rápida respuesta ante los cambios de escenarios. • Facilita la comunicación de las decisiones tomadas.

Consideraciones: El diseño e implementación de un sistema de Soporte a la Toma de Decisiones, como se explica en el apartado de “Aplicación de los DSS” en el presente trabajo, como podrá comprenderse a medida que se avanza en la lectura, requiere de un análisis minucioso del problema, de los datos y de los requerimientos, ya que en muchas situaciones, y en casi todas, los problemas no se ajustan a las situaciones comunes en éste campo de aplicación; como ser contables, financieros, de recursos humanos, de mercadotecnia, etc. Pero todo trabajo es más emocionante en estas situaciones, el analizar, el innovar, utilizar la creatividad, plantear hipótesis, diseñar modelos propios, evaluar y medir errores de los modelos, depurarlos para luego obtener los resultados esperados, ésta es la tarea de todo investigador, y el razonamiento será desarrollado y explicado a continuación.

��

Data Warehousing

Introducción Desde que se inició la era de la computadora, las organizaciones han usado los datos desde sus sistemas operacionales para atender sus necesidades de información. Algunas proporcionan acceso directo a la información contenida dentro de las aplicaciones operacionales. Otras, han extraído los datos desde sus bases de datos operacionales para combinarlos de varias formas no estructuradas, en su intento por atender a los usuarios en sus necesidades de información. Ambos métodos han evolucionado a través del tiempo y ahora las organizaciones manejan una data no limpia e inconsistente, sobre las cuales, en la mayoría de las veces, se toman decisiones importantes. La gestión administrativa reconoce que una manera de elevar su eficiencia está en hacer el mejor uso de los recursos de información que ya existen dentro de la organización. Sin embargo, a pesar de que esto se viene intentando desde hace muchos años, no se tiene todavía un uso efectivo de los mismos. La razón principal es la manera en que han evolucionado las computadoras, basadas en las tecnologías de información y sistemas. La mayoría de las organizaciones hacen lo posible por conseguir buena información, pero el logro de ese objetivo depende fundamentalmente de su arquitectura actual, tanto de hardware como de software. El data warehouse, es actualmente, el centro de atención de las grandes instituciones, porque provee un ambiente para que las organizaciones hagan un mejor uso de la información que está siendo administrada por diversas aplicaciones operacionales. Un data warehouse es una colección de datos en la cual se encuentra integrada la información de la Institución y que se usa como soporte para el proceso de toma de decisiones gerenciales. Aunque diversas organizaciones y personas individuales logran comprender el enfoque de un Warehouse, la experiencia ha demostrado que existen muchas dificultades potenciales. Reunir los elementos de datos apropiados desde diversas fuentes de aplicación en un ambiente integral centralizado, simplifica el problema de acceso a la información y en consecuencia, acelera el proceso de análisis, consultas y el menor tiempo de uso de la información. Las aplicaciones para soporte de decisiones basadas en un data warehousing, pueden hacer más práctica y fácil la explotación de datos para una mayor eficacia del negocio, que no se logra cuando se usan sólo los datos que provienen de las aplicaciones operacionales (que ayudan en la operación de la empresa en sus operaciones cotidianas), en los que la información se obtiene realizando procesos independientes y muchas veces complejos. Un data warehouse se crea al extraer datos desde una o más bases de datos de aplicaciones operacionales. La data extraída es transformada para eliminar inconsistencias y resumir si es necesario y luego, cargadas en el data warehouse. El proceso de transformar, crear el detalle de tiempo variante, resumir y combinar los extractos de datos, ayudan a crear el ambiente para el acceso a la información Institucional. Este nuevo enfoque ayuda a las personas individuales, en todos los niveles de la empresa, a efectuar su toma de decisiones con más responsabilidad. La innovación de la Tecnología de Información dentro de un ambiente data warehousing, puede permitir a cualquier organización hacer un uso más óptimo de los datos, como un ingrediente clave para un proceso de toma de decisiones más efectivo. Las organizaciones tienen que aprovechar sus recursos de información para crear la información de la operación del negocio, pero deben considerarse las estrategias

��

tecnológicas necesarias para la implementación de una arquitectura completa de data warehouse.

Teoría

Introducción al Concepto Data Warehousing

Data warehousing es el centro de la arquitectura para los sistemas de información en la década de los '90. Soporta el procesamiento informático al proveer una plataforma sólida, a partir de los datos históricos para hacer el análisis. Facilita la integración de sistemas de aplicación no integrados. Organiza y almacena los datos que se necesitan para el procesamiento analítico, informático sobre una amplia perspectiva de tiempo. Un Data Warehouse o Depósito de Datos es una colección de datos orientado a temas, integrado, no volátil, de tiempo variante, que se usa para el soporte del proceso de toma de decisiones gerenciales. Se puede caracterizar un data warehouse haciendo un contraste de cómo los datos de un negocio almacenados en un data warehouse, difieren de los datos operacionales usados por las aplicaciones de producción. Base de Datos Operacional Data Warehouse Datos Operacionales Datos del negocio para Información Orientado a la aplicación Orientado al sujeto Actual Actual + histórico Detallada Detallada + más resumida Cambia continuamente Estable

El ingreso de datos en el data warehouse viene desde el ambiente operacional en casi todos los casos. El data warehouse es siempre un almacén de datos transformados y separados físicamente de la aplicación donde se encontraron los datos en el ambiente operacional.

Sistemas de Información

Los sistemas de información se han dividido de acuerdo al siguiente esquema:

��

Sistemas Estratégicos, orientados a soportar la toma de decisiones, facilitan la labor de la dirección, proporcionándole un soporte básico, en forma de mejor información, para la toma de decisiones. Se caracterizan porque son sistemas sin carga periódica de trabajo, es decir, su utilización no es predecible, al contrario de los casos anteriores, cuya utilización es periódica. Destacan entre estos sistemas: los Sistemas de Información Gerencial (MIS), Sistemas de Información Ejecutivos (EIS), Sistemas de Información Georeferencial (GIS), Sistemas de Simulación de Negocios (BIS y que en la práctica son sistemas expertos o de Inteligencia Artificial - AI). Sistemas Tácticos, diseñados para soportar las actividades de coordinación de actividades y manejo de documentación, definidos para facilitar consultas sobre información almacenada en el sistema, proporcionar informes y, en resumen, facilitar la gestión independiente de la información por parte de los niveles intermedios de la organización. Destacan entre ellos: los Sistemas Ofimáticos (OA), Sistemas de Transmisión de Mensajería (Correo electrónico y Servidor de fax), coordinación y control de tareas (Work Flow) y tratamiento de documentos (Imagen, Trámite y Bases de Datos Documentales). Sistemas Técnico - Operativos, que cubren el núcleo de operaciones tradicionales de captura masiva de datos (Data Entry) y servicios básicos de tratamiento de datos, con tareas predefinidas (contabilidad, facturación, almacén, presupuesto, personal y otros sistemas administrativos). Estos sistemas están evolucionando con la irrupción de censores, autómatas, sistemas multimedia, bases de datos relacionales más avanzadas y data warehousing. Sistemas Interinstitucionales, este último nivel de sistemas de información recién está surgiendo, es consecuencia del desarrollo organizacional orientado a un mercado de carácter global, el cual obliga a pensar e implementar estructuras de comunicación más estrechas entre la organización y el mercado (Empresa Extendida, Organización Inteligente e Integración Organizacional), todo esto a partir de la generalización de las redes informáticas de alcance nacional y global (INTERNET), que se convierten en vehículo de comunicación entre la organización y el mercado, no importa dónde esté la organización (INTRANET), el mercado de la institución (EXTRANET) y el mercado (Red Global). Sin embargo, la tecnología data warehousing basa sus conceptos y diferencias entre dos tipos fundamentales de sistemas de información en todas las organizaciones: los sistemas técnico - operacionales y los sistemas de soporte de decisiones. Este último es la base de un data warehouse.

Sistemas Técnico - Operacionales

Como indica su nombre, son los sistemas que ayudan a manejar la empresa con sus operaciones cotidianas. Estos son los sistemas que operan sobre el "backbone" (columna vertebral) de cualquier empresa o institución, entre las que se tiene sistemas de ingreso de órdenes, inventario, fabricación, planilla y contabilidad, entre otros. Debido a su volumen e importancia en la organización, los sistemas operacionales siempre han sido las primeras partes de la empresa a ser computarizados. A través de los años, estos sistemas operacionales se han extendido, revisado, mejorado y mantenido al punto que hoy, ellos son completamente integrados en la organización. Desde luego, la mayoría de las organizaciones grandes de todo el mundo, actualmente no podrían operar sin sus sistemas operacionales y los datos que estos sistemas mantienen.

��

Sistemas de Soporte de Decisiones

Por otra parte, hay otras funciones dentro de la empresa que tienen que ver con el planeamiento, previsión y administración de la organización. Estas funciones son también críticas para la supervivencia de la organización, especialmente en nuestro mundo de rápidos cambios. Las funciones como "planificación de marketing", "planeamiento de ingeniería" y "análisis financiero", requieren, además, de sistemas de información que los soporte. Pero estas funciones son diferentes de las operacionales y los tipos de sistemas y la información requerida son también diferentes. Las funciones basadas en el conocimiento son los sistemas de soporte de decisiones. Estos sistemas están relacionados con el análisis de los datos y la toma de decisiones, frecuentemente, decisiones importantes sobre cómo operará la empresa, ahora y en el futuro. Estos sistemas no sólo tienen un enfoque diferente al de los operacionales, sino que, por lo general, tienen un alcance diferente. Mientras las necesidades de los datos operacionales se enfocan normalmente hacia una sola área, los datos para el soporte de decisiones, con frecuencia, toma un número de áreas diferentes y necesita cantidades grandes de datos operacionales relacionadas. Son estos sistemas sobre los que se basa la tecnología data warehousing.

Características de un Data Warehouse

Entre las principales se tiene: � Orientado al tema � Integrado � De tiempo variante � No volátil

Orientado a Temas

Una primera característica del data warehouse es que la información se clasifica en base a los aspectos que son de interés para la empresa. Siendo así, los datos tomados están en contraste con los clásicos procesos orientados a las aplicaciones. En la Figura N° 1 se muestra el contraste entre los dos tipos de orientaciones. El ambiente operacional se diseña alrededor de las aplicaciones y funciones tales como préstamos, ahorros, tarjeta bancaria y depósitos para una institución financiera. Por ejemplo, una aplicación de ingreso de órdenes puede acceder a los datos sobre clientes, productos y cuentas. La base de datos combina estos elementos en una estructura que acomoda las necesidades de la aplicación. En el ambiente data warehousing se organiza alrededor de sujetos tales como cliente, vendedor, producto y actividad. Por ejemplo, para un fabricante, éstos pueden ser clientes, productos, proveedores y vendedores. Para una universidad pueden ser estudiantes, clases y profesores. Para un hospital pueden ser pacientes, personal médico, medicamentos, etc. La alineación alrededor de las áreas de los temas afecta el diseño y la implementación de los datos encontrados en el data warehouse. Las principales áreas de los temas influyen en la parte más importante de la estructura clave.

��

Las aplicaciones están relacionadas con el diseño de la base de datos y del proceso. En data warehousing se enfoca el modelamiento de datos y el diseño de la base de datos. El diseño del proceso (en su forma clásica) no es separado de este ambiente. Las diferencias entre la orientación de procesos y funciones de las aplicaciones y la orientación a temas, radican en el contenido de la data a escala detallada. En el data warehouse se excluye la información que no será usada por el proceso de sistemas de soporte de decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos

��

funcionales y de proceso, que pueden ser usados o no por el analista de soporte de decisiones. Otra diferencia importante está en la interrelación de la información. Los datos operacionales mantienen una relación continua entre dos o más tablas basadas en una regla comercial que está vigente. Las del data warehouse miden un espectro de tiempo y las relaciones encontradas en el data warehouse son muchas. Muchas de las reglas comerciales (y sus correspondientes relaciones de datos) se representan en el data warehouse, entre dos o más tablas.

Integración

El aspecto más importante del ambiente data warehousing es que la información encontrada al interior está siempre integrada. La integración de datos se muestra de muchas maneras: en convenciones de nombres consistentes, en la medida uniforme de variables, en la codificación de estructuras consistentes, en atributos físicos de los datos consistentes, fuentes múltiples y otros. El contraste de la integración encontrada en el data warehouse con la carencia de integración del ambiente de aplicaciones, se muestran en la Figura N° 2, con diferencias bien marcadas. A través de los años, los diseñadores de las diferentes aplicaciones han tomado sus propias decisiones sobre cómo se debería construir una aplicación. Los estilos y diseños personalizados se muestran de muchas maneras. Se diferencian en la codificación, en las estructuras claves, en sus características físicas, en las convenciones de nombramiento y otros. La capacidad colectiva de muchos de los diseñadores de aplicaciones, para crear aplicaciones inconsistentes, es fabulosa. La Figura N° 2 mencionada, muestra algunas de las diferencias más importantes en las formas en que se diseñan las aplicaciones. Codificación. Los diseñadores de aplicaciones codifican el campo GENERO en varias formas. Un diseñador representa GENERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y "femenino". No importa mucho cómo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan buenas como cualquier otra representación. Lo importante es que sea de cualquier fuente de donde venga, el GENERO debe llegar al data warehouse en un estado integrado uniforme. Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicación, donde ha sido representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse. Medida de atributos. Los diseñadores de aplicaciones miden las unidades de medida de las tuberías en una variedad de formas. Un diseñador almacena los datos de tuberías en centímetros, otros en pulgadas, otros en millones de pies cúbicos por segundo y otros en yardas. Al dar medidas a los atributos, la transformación traduce las diversas unidades de medida usadas en las diferentes bases de datos para transformarlas en una medida estándar común. Cualquiera que sea la fuente, cuando la información de la tubería llegue al data warehouse necesitará ser medida de la misma manera. Convenciones de Nombramiento. El mismo elemento es frecuentemente referido por nombres diferentes en las diversas aplicaciones. El proceso de transformación asegura que se use preferentemente el nombre de usuario.

��

Fuentes Múltiples. El mismo elemento puede derivarse desde fuentes múltiples. En este caso, el proceso de transformación debe asegurar que la fuente apropiada sea usada, documentada y movida al depósito. Tal como se muestra en la figura, los puntos de integración afectan casi todos los aspectos de diseño - las características físicas de los datos, la disyuntiva de tener más de una de fuente de datos, el problema de estándares de denominación inconsistentes, formatos de fecha inconsistentes y otros. Cualquiera que sea la forma del diseño, el resultado es el mismo - la información necesita ser almacenada en el data warehouse en un modelo globalmente aceptable y singular, aun cuando los sistemas operacionales subyacentes almacenen los datos de manera diferente. Cuando el analista de sistema de soporte de decisiones observe el data warehouse, su enfoque deberá estar en el uso de los datos que se encuentre en el depósito, antes que preguntarse sobre la confiabilidad o consistencia de los datos.

��

��

De Tiempo Variante

Toda la información del data warehouse es requerida en algún momento. Esta característica básica de los datos en un depósito, es muy diferente de la información encontrada en el ambiente operacional. En éstos, la información se requiere al

��

momento de acceder. En otras palabras, en el ambiente operacional, cuando usted accede a una unidad de información, usted espera que los valores requeridos se obtengan a partir del momento de acceso. Como la información en el data warehouse es solicitada en cualquier momento (es decir, no "ahora mismo"), los datos encontrados en el depósito se llaman de "tiempo variante". Los datos históricos son de poco uso en el procesamiento operacional. La información del depósito por el contraste, debe incluir los datos históricos para usarse en la identificación y evaluación de tendencias. (Ver Figura N° 3).

El tiempo variante se muestra de varias maneras:

1. La más simple es que la información representa los datos sobre un horizonte largo de tiempo - desde cinco a diez años. El horizonte de tiempo representado para el ambiente operacional es mucho más corto - desde valores actuales hasta sesenta a noventa días. Las aplicaciones que tienen un buen rendimiento y están disponibles para el procesamiento de transacciones, deben llevar una cantidad mínima de datos si tienen cualquier grado de flexibilidad. Por ello, las aplicaciones operacionales tienen un corto horizonte de tiempo, debido al diseño de aplicaciones rígidas.

2. La segunda manera en la que se muestra el tiempo variante en el data warehouse está en la estructura clave. Cada estructura clave en el data warehouse contiene, implícita o explícitamente, un elemento de tiempo como día, semana, mes, etc. El elemento de tiempo está casi siempre al pie de la clave concatenada, encontrada en el data warehouse. En ocasiones, el elemento de tiempo existirá implícitamente, como el caso en que un archivo completo se duplica al final del mes, o al cuarto.

3. La tercera manera en que aparece el tiempo variante es cuando la información del data warehouse, una vez registrada correctamente, no puede ser actualizada. La información del data warehouse es, para todos los propósitos prácticos, una serie larga de "snapshots" (vistas instantáneas). Por supuesto, si los snapshots de los datos se han tomado incorrectamente, entonces pueden ser cambiados. Asumiendo que los snapshots se han tomado adecuadamente, ellos no son alterados una vez hechos. En algunos casos puede ser no ético, e incluso ilegal, alterar los snapshots en el data warehouse. Los datos operacionales, siendo requeridos a partir del momento de acceso, pueden actualizarse de acuerdo a la necesidad.

��

No Volátil

La información es útil sólo cuando es estable. Los datos operacionales cambian sobre una base momento a momento. La perspectiva más grande, esencial para el análisis y la toma de decisiones, requiere una base de datos estable. En la Figura N° 4 se muestra que la actualización (insertar, borrar y modificar), se hace regularmente en el ambiente operacional sobre una base de registro por registro. Pero la manipulación básica de los datos que ocurre en el data warehouse es mucho más simple. Hay dos únicos tipos de operaciones: la carga inicial de datos y el acceso a los mismos. No hay actualización de datos (en el sentido general de actualización) en el depósito, como una parte normal de procesamiento. Hay algunas consecuencias muy importantes de esta diferencia básica, entre el procesamiento operacional y del data warehouse. En el nivel de diseño, la necesidad de ser precavido para actualizar las anomalías no es un factor en el data warehouse, ya que no se hace la actualización de datos. Esto significa que en el nivel físico de diseño, se pueden tomar libertades para optimizar el acceso a los datos, particularmente al usar la normalización y desnormalización física. Otra consecuencia de la simplicidad de la operación del data warehouse está en la tecnología subyacente, utilizada para correr los datos en el depósito. Teniendo que soportar la actualización de registro por registro en modo on-line (como es frecuente en el caso del procesamiento operacional) requiere que la tecnología tenga un fundamento muy complejo debajo de una fachada de simplicidad.

La tecnología permite realizar copias de seguridad y recuperación, transacciones e integridad de los datos y la detección y solución al estancamiento que es más complejo. En el data warehouse no es necesario el procesamiento. La fuente de casi toda la información del data warehouse es el ambiente operacional. A simple vista, se puede pensar que hay redundancia masiva de datos entre los dos ambientes. Desde luego, la primera impresión de muchas personas se centra en la gran redundancia de datos, entre el ambiente operacional y el ambiente de data warehouse. Dicho razonamiento es superficial y demuestra una carencia de entendimiento con respecto a qué ocurre en el data warehouse. De hecho, hay una mínima redundancia de datos entre ambos ambientes.

��

Se debe considerar lo siguiente: Los datos se filtran cuando pasan desde el ambiente operacional al de depósito. Existe mucha data que nunca sale del ambiente operacional. Sólo los datos que realmente se necesitan ingresarán al ambiente de data warehouse. El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La información en el ambiente operacional es más reciente con respecto a la del data warehouse. Desde la perspectiva de los horizontes de tiempo únicos, hay poca superposición entre los ambientes operacional y de data warehouse. El data warehouse contiene un resumen de la información que no se encuentra en el ambiente operacional. Los datos experimentan una transformación fundamental cuando pasa al data warehouse. La mayor parte de los datos se alteran significativamente al ser seleccionados y movidos al data warehouse. Dicho de otra manera, la mayoría de los datos se alteran física y radicalmente cuando se mueven al depósito. No es la misma data que reside en el ambiente operacional desde el punto de vista de integración. En vista de estos factores, la redundancia de datos entre los dos ambientes es una ocurrencia rara, que resulta en menos de 1%.

Estructura del Data Warehouse Los data warehouses tienen una estructura distinta. Hay niveles diferentes de esquematización y detalle que delimitan el data warehouse. La estructura de un data warehouse se muestra en la Figura N° 5. En la figura, se muestran los diferentes componentes del data warehouse y son:

• Detalle de datos actuales • Detalle de datos antiguos • Datos ligeramente resumidos • Datos completamente resumidos • Meta data •

Detalle de datos actuales. En gran parte, el interés más importante radica en el detalle de los datos actuales, debido a que:

• Refleja las ocurrencias más recientes, las cuales son de gran interés • Es voluminoso, ya que se almacena al más bajo nivel de granularidad. • Casi siempre se almacena en disco, el cual es de fácil acceso, aunque su

administración sea costosa y compleja.

Detalle de datos antiguos. La data antigua es aquella que se almacena sobre alguna forma de almacenamiento masivo. No es frecuentemente su acceso y se almacena a un nivel de detalle, consistente con los datos detallados actuales. Mientras no sea prioritario el almacenamiento en un medio de almacenaje alterno, a causa del gran volumen de datos unido al acceso no frecuente de los mismos, es poco usual utilizar el disco como medio de almacenamiento. Datos ligeramente resumidos. La data ligeramente resumida es aquella que proviene desde un bajo nivel de detalle encontrado al nivel de detalle actual. Este nivel del data warehouse casi siempre se almacena en disco. Los puntos en los que se basa el diseñador para construirlo son:

• Que la unidad de tiempo se encuentre sobre la esquematización hecha. • Qué contenidos (atributos) tendrá la data ligeramente resumida.

��

Datos completamente resumidos. El siguiente nivel de datos encontrado en el data warehouse es el de los datos completamente resumidos. Estos datos son compactos y fácilmente accesibles.

A veces se encuentra en el ambiente de data warehouse y en otros, fuera del límite de la tecnología que ampara al data warehouse. (De todos modos, los datos completamente resumidos son parte del data warehouse sin considerar donde se alojan los datos físicamente.)

��

Metadata. El componente final del data warehouse es el de la metadata. De muchas maneras la metadata se sitúa en una dimensión diferente al de otros datos del data warehouse, debido a que su contenido no es tomado directamente desde el ambiente operacional. La metadata juega un rol especial y muy importante en el data warehouse y es usada como:

• Un directorio para ayudar al analista a ubicar los contenidos del data warehouse.

• Una guía para la trazabilidad de los datos, de cómo se transforma, del ambiente operacional al de data warehouse.

• Una guía de los algoritmos usados para la esquematización entre el detalle de datos actual, con los datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc.

La metadata juega un papel mucho más importante en un ambiente data warehousing que en un operacional clásico.

En otras palabras, habría un retraso de tiempo de por lo menos veinticuatro horas, entre el tiempo en que en el ambiente operacional se haya hecho un nuevo ingreso de la venta y el momento cuando la información de la venta haya ingresado al data warehouse. El detalle de las ventas son resumidas semanalmente por línea de subproducto y por región, para producir un almacenamiento de datos ligeramente resumidos. El detalle de ventas semanal es adicionalmente resumido en forma mensual, según una gama de líneas, para producir los datos completamente resumidos. La metadata contiene (al menos):

• La estructura de los datos • Los algoritmos usados para la esquematización • La trazabilidad desde el ambiente operacional al data warehouse

La información adicional que no se esquematiza es almacenada en el data warehouse. En muchas ocasiones, allí se hará el análisis y se producirá un tipo u otro de resumen. El único tipo de esquematización que se almacena permanentemente en el data warehouse, es el de los datos que son usados frecuentemente. En otras palabras, si un analista produce un resumen que tiene una probabilidad muy baja de ser usado nuevamente, entonces la esquematización no es almacenada en el data warehouse.

Arquitectura de un Data Warehouse

Una de las razones por las que el desarrollo de un data warehouse crece rápidamente, es que realmente es una tecnología muy entendible. De hecho, data warehousing puede representar mejor la estructura amplia de una empresa para administrar los datos informacionales dentro de la organización. A fin de comprender cómo se relacionan todos los componentes involucrados en una estrategia data warehousing, es esencial tener una Arquitectura Data Warehouse.

��

Elementos constituyentes de una Arquitectura Data Warehouse

Una Arquitectura Data Warehouse (Data Warehouse Architecture - DWA) es una forma de representar la estructura total de datos, comunicación, procesamiento y presentación, que existe para los usuarios finales que disponen de una computadora dentro de la empresa. La arquitectura se constituye de un número de partes interconectadas:

• Base de datos operacional / Nivel de base de datos externo • Nivel de acceso a la información • Nivel de acceso a los datos • Nivel de directorio de datos (Metadata) • Nivel de gestión de proceso • Nivel de mensaje de la aplicación • Nivel de data warehouse • Nivel de organización de datos

Base de datos operacional / Nivel de base de datos externo

Los sistemas operacionales procesan datos para apoyar las necesidades operacionales críticas. Para hacer eso, se han creado las bases de datos operacionales históricas que proveen una estructura de procesamiento eficiente, para un número relativamente pequeño de transacciones comerciales bien definidas. Sin embargo, a causa del enfoque limitado de los sistemas operacionales, las bases de datos diseñadas para soportar estos sistemas, tienen dificultad al acceder a los datos para otra gestión o propósitos informáticos. Esta dificultad en acceder a los datos operacionales es amplificada por el hecho que muchos de estos sistemas tienen de 10 a 15 años de antigüedad. El tiempo de algunos de estos sistemas significa que la tecnología de acceso a los datos disponible para obtener los datos operacionales, es así mismo antigua. Ciertamente, la meta del data warehousing es liberar la información que es almacenada en bases de datos operacionales y combinarla con la información desde otra fuente de datos, generalmente externa. Cada vez más, las organizaciones grandes adquieren datos adicionales desde bases de datos externas. Esta información incluye tendencias demográficas, econométricas,

��

adquisitivas y competitivas (que pueden ser proporcionadas por Instituciones Oficiales - INEI). Internet o también llamada "information superhighway" (supercarretera de la información) provee el acceso a más recursos de datos todos los días.

Nivel de acceso a la información

El nivel de acceso a la información de la arquitectura data warehouse, es el nivel del que el usuario final se encarga directamente. En particular, representa las herramientas que el usuario final normalmente usa día a día. Por ejemplo: EXCEL, LOTUS 1-2-3, FOCUS, ACCESS, etc. Este nivel también incluye el hardware y software involucrados en mostrar información en pantalla y emitir reportes de impresión, hojas de cálculo, gráficos y diagramas para el análisis y presentación. Hace dos décadas que el nivel de acceso a la información se ha expandido enormemente, especialmente a los usuarios finales quienes se han volcado a los PCS monousuarios y los PCS en redes. Actualmente, existen herramientas más y más sofisticadas para manipular, analizar y presentar los datos, sin embargo, hay problemas significativos al tratar de convertir los datos tal como han sido recolectados y que se encuentran contenidos en los sistemas operacionales en información fácil y transparente para las herramientas de los usuarios finales. Una de las claves para esto es encontrar un lenguaje de datos común que puede usarse a través de toda la empresa.

Nivel de acceso a los datos

El nivel de acceso a los datos de la arquitectura data warehouse está involucrado con el nivel de acceso a la información para conversar en el nivel operacional. En la red mundial de hoy, el lenguaje de datos común que ha surgido es SQL. Originalmente, SQL fue desarrollado por IBM como un lenguaje de consulta, pero en los últimos veinte años ha llegado a ser el estándar para el intercambio de datos. Uno de los adelantos claves de los últimos años ha sido el desarrollo de una serie de "filtros" de acceso a datos, tales como EDA/SQL para acceder a casi todo los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMSs) y sistemas de archivos de datos, relacionales o no. Estos filtros permiten a las herramientas de acceso a la información, acceder también a la data almacenada en sistemas de gestión de base de datos que tienen veinte años de antigüedad. El nivel de acceso a los datos no solamente conecta DBMSS diferentes y sistemas de archivos sobre el mismo hardware, sino también a los fabricantes y protocolos de red. Una de las claves de una estrategia data warehousing es proveer a los usuarios finales con "acceso a datos universales". El acceso a los datos universales significa que, teóricamente por lo menos, los usuarios finales sin tener en cuenta la herramienta de acceso a la información o ubicación, deberían ser capaces de acceder a cualquier o todos los datos en la empresa que es necesaria para ellos, para hacer su trabajo. El nivel de acceso a los datos entonces es responsable de la interfaces entre las herramientas de acceso a la información y las bases de datos operacionales. En algunos casos, esto es todo lo que un usuario final necesita. Sin embargo, en general, las organizaciones desarrollan un plan mucho más sofisticado para el soporte del data warehousing.

Nivel de Directorio de Datos (Metadata)

A fin de proveer el acceso a los datos universales, es absolutamente necesario mantener alguna forma de directorio de datos o repositorio de la información metadata. La metadata es la información alrededor de los datos dentro de la empresa.

��

Las descripciones de registro en un programa COBOL son metadata. También lo son las sentencias DIMENSION en un programa FORTRAN o las sentencias a crear en SQL. A fin de tener un depósito totalmente funcional, es necesario tener una variedad de metadata disponibles, información sobre las vistas de datos de los usuarios finales e información sobre las bases de datos operacionales. Idealmente, los usuarios finales deberían de acceder a los datos desde el data warehouse (o desde las bases de datos operacionales), sin tener que conocer dónde residen los datos o la forma en que se han almacenados.

Nivel de Gestión de Procesos

El nivel de gestión de procesos tiene que ver con la programación de diversas tareas que deben realizarse para construir y mantener el data warehouse y la información del directorio de datos. Este nivel puede depender del alto nivel de control de trabajo para muchos procesos (procedimientos) que deben ocurrir para mantener el data warehouse actualizado.

Nivel de Mensaje de la Aplicación

El nivel de mensaje de la aplicación tiene que ver con el transporte de información alrededor de la red de la empresa. El mensaje de aplicación se refiere también como "subproducto", pero puede involucrar sólo protocolos de red. Puede usarse por ejemplo, para aislar aplicaciones operacionales o estratégicas a partir del formato de datos exacto, recolectar transacciones o los mensajes y entregarlos a una ubicación segura en un tiempo seguro.

Nivel Data Warehouse (Físico)

En el data warehouse (núcleo) es donde ocurre la data actual, usada principalmente para usos estratégicos. En algunos casos, uno puede pensar del data warehouse simplemente como una vista lógica o virtual de datos. En muchos ejemplos, el data warehouse puede no involucrar almacenamiento de datos. En un data warehouse físico, copias, en algunos casos, muchas copias de datos operacionales y/o externos, son almacenados realmente en una forma que es fácil de acceder y es altamente flexible. Cada vez más, los data warehouses son almacenados sobre plataformas cliente/servidor, pero por lo general se almacenan sobre mainframes.

Nivel de Organización de Datos

El componente final de la arquitectura data warehouse es la organización de los datos. Se llama también gestión de copia o réplica, pero de hecho, incluye todos los procesos necesarios como seleccionar, editar, resumir, combinar y cargar datos en el depósito y acceder a la información desde bases de datos operacionales y/o externas. La organización de datos involucra con frecuencia una programación compleja, pero cada vez más, están creándose las herramientas data warehousing para ayudar en este proceso. Involucra también programas de análisis de calidad de datos y filtros que identifican modelos y estructura de datos dentro de la data operacional existente.

Operaciones en un Data Warehouse

��

Sistemas Operacionales

Los datos administrados por los sistemas de aplicación operacionales son la fuente principal de datos para el data warehouse. Las bases de datos operacionales se organizan como archivos indexados (UFAS, VSAM), bases de datos de redes/jerárquicas (I-D-S/II, IMS, IDMS) o sistemas de base de datos relacionales (DB2, ORACLE, INFORMIX, etc.). Según las encuestas, aproximadamente del 70% a 80% de las bases de datos de las empresas se organizan usando DBMSS no relacional.

Extracción, Transformación y Carga de los Datos

Se requieren herramientas de gestión de datos para extraer datos desde bases de datos y/o archivos operacionales, luego es necesario manipular o transformar los datos antes de cargar los resultados en el data warehouse. Tomar los datos desde varias bases de datos operacionales y transformarlos en datos requeridos para el depósito, se refiere a la transformación o a la integración de datos. Las bases de datos operacionales, diseñadas para el soporte de varias aplicaciones de producción, frecuentemente difieren en el formato. Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por diferentes software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen formatos inconsistentes y/o ser codificados de manera diferente. Todas estas inconsistencias deben resolverse antes que los elementos de datos sean almacenados en el data warehouse.

Metadata

Otro paso necesario es crear la metadata. La metadata (es decir, datos acerca de datos) describe los contenidos del data warehouse. La metadata consiste de definiciones de los elementos de datos en el depósito, sistema(s) del (os) elemento(s) fuente. Como la data, se integra y transforma antes de ser almacenada en información similar.

Acceso de usuario final

Los usuarios acceden al data warehouse por medio de herramientas de productividad basadas en GUI (Graphical User Interface - Interface gráfica de usuario). Pueden proveerse a los usuarios del data warehouse muchos de estos tipos de herramientas. Estos pueden incluir software de consultas, generadores de reportes, procesamiento analítico en línea, herramientas data/visual mining, etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Sin embargo, una sola herramienta no satisface todos los requerimientos, por lo que es necesaria la integración de una serie de herramientas.

Plataforma del data warehouse La plataforma para el data warehouse es casi siempre un servidor de base de datos relacional. Cuando se manipulan volúmenes muy grandes de datos puede requerirse una configuración en bloque de servidores UNIX con multiprocesador simétrico (SMP) o un servidor con procesador paralelo masivo (MPP) especializado. Los extractos de la data integrada/transformada se cargan en el data warehouse. Uno de los más populares RDBMSs disponibles para data warehousing sobre la plataforma

��

UNIX (SMP y MPP) generalmente es Teradata. La elección de la plataforma es crítica. El depósito crecerá y hay que comprender los requerimientos después de 3 o 5 años. Muchas de las organizaciones quieran o no escogen una plataforma por diversas razones: el Sistema X es nuestro sistema elegido o el Sistema Y está ya disponible sobre un sistema UNIX que nosotros ya tenemos. Uno de los errores más grandes que las organizaciones cometen al seleccionar la plataforma, es que ellos presumen que el sistema (hardware y/o DBMS) escalará con los datos. El sistema de depósito ejecuta las consultas que se pasa a los datos por el software de acceso a los datos del usuario. Aunque un usuario visualiza las consultas desde el punto de vista de un GUI, las consultas típicamente se formulan como pedidos SQL, porque SQL es un lenguaje universal y el estándar de hecho para el acceso a datos.

Datos Externos

Dependiendo de la aplicación, el alcance del data warehouse puede extenderse por la capacidad de acceder a la data externa. Por ejemplo, los datos accesibles por medio de servicios de computadora en línea (tales como CompuServe y America On Line) y/o vía Internet, pueden estar disponibles a los usuarios del data warehouse.

Evolución del Depósito

Construir un data warehouse es una tarea grande. No es recomendable emprender el desarrollo del data warehouse de la empresa como un proyecto cualquiera. Más bien, se recomienda que los requerimientos de una serie de fases se desarrollen e implementen en modelos consecutivos que permitan un proceso de implementación más gradual e iterativo. No existe ninguna organización que haya triunfado en el desarrollo del data warehouse de la empresa, en un sólo paso. Muchas, sin embargo, lo han logrado luego de un desarrollo paso a paso. Los pasos previos evolucionan conjuntamente con la materia que está siendo agregada. Los datos en el data warehouse no son volátiles y es un repositorio de datos de sólo lectura (en general). Sin embargo, pueden añadirse nuevos elementos sobre una base regular para que el contenido siga la evolución de los datos en la base de datos fuente, tanto en los contenidos como en el tiempo. Uno de los desafíos de mantener un data warehouse, es idear métodos para identificar datos nuevos o modificados en las bases de datos operacionales. Algunas maneras para identificar estos datos incluyen insertar fecha/tiempo en los registros de base de datos y entonces crear copias de registros actualizados y copiar información de los registros de transacción y/o base de datos diarias. Estos elementos de datos nuevos y/o modificados son extraídos, integrados, transformados y agregados al data warehouse en pasos periódicos programados. Como se añaden las nuevas ocurrencias de datos, los datos antiguos son eliminados. Por ejemplo, si los detalles de un sujeto particular se mantienen por 5 años, como se agregó la última semana, la semana anterior es eliminada.

Transformación de Datos y Metadata

Transformación de Datos

Uno de los desafíos de cualquier implementación de data warehouse, es el problema de transformar los datos. La transformación se encarga de las inconsistencias en los

��

formatos de datos y la codificación, que pueden existir dentro de una base de datos única y que casi siempre existen cuando múltiples bases de datos contribuyen al data warehouse.

La transformación de datos también se encarga de las inconsistencias en el contenido de datos. Una vez que se toma la decisión sobre que reglas de transformación serán establecidas, deben crearse e incluirse las definiciones en las rutinas de transformación. Se requiere una planificación cuidadosa y detallada para transformar datos inconsistentes en conjuntos de datos conciliables y consistentes para cargarlos en el data warehouse.

Metadata

Otro aspecto de la arquitectura de data warehouse es crear soporte a la metadata. Metadata es la información sobre los datos que se alimenta, se transforma y existe en el data warehouse. Metadata es un concepto genérico, pero cada implementación de la metadata usa técnicas y métodos específicos. Estos métodos y técnicas son dependientes de los requerimientos de cada organización, de las capacidades existentes y de los requerimientos de interfaces de usuario. Hasta ahora, no hay normas para la metadata, por lo que la metadata debe definirse desde el punto de vista del software data warehousing, seleccionado para una implementación específica. Típicamente, la metadata incluye los siguientes ítems:

• Las estructuras de datos que dan una visión de los datos al administrador de datos.

• Las definiciones del sistema de registro desde el cual se construye el data warehouse.

• Las especificaciones de transformaciones de datos que ocurren tal como la fuente de datos se replica al data warehouse.

El modelo de datos del data warehouse (es decir, los elementos de datos y sus relaciones). Un registro de cuando los nuevos elementos de datos se agregan al data warehouse y cuando los elementos de datos antiguos se eliminan o se resumen. Los niveles de sumarización, el método de sumarización y las tablas de registros de su data warehouse. Algunas implementaciones de la metadata también incluyen definiciones de la(s) vista(s) presentada(s) a los usuarios del data warehouse. Típicamente, se definen vistas múltiples para favorecer las preferencias variadas de diversos grupos de usuarios. En otras implementaciones, estas descripciones se almacenan en un Catálogo de Información. Los esquemas y subesquemas para bases de datos operacionales, forman una fuente óptima de entrada cuando se crea la metadata. Hacer uso de la documentación existente, especialmente cuando está disponible en forma electrónica, puede acelerar el proceso de definición de la metadata del ambiente data warehousing. La metadata sirve, en un sentido, como el corazón del ambiente data warehousing. Crear definiciones de metadata completa y efectiva puede ser un proceso que consuma tiempo, pero lo mejor de las definiciones y si usted usa herramientas de gestión de software integrado, son los esfuerzos que darán como resultado el mantenimiento del data warehouse.

��

Flujo de Datos Existe un flujo de datos normal y predecible dentro del data warehouse. La Figura N° 10 muestra ese flujo. Los datos ingresan al data warehouse desde el ambiente operacional. (Hay pocas excepciones a esta regla). Al ingresar al data warehouse, la información va al nivel de detalle actual, tal como se muestra. Se queda allí y se usa hasta que ocurra uno de los tres eventos siguientes:

• Sea eliminado • Sea resumido • Sea archivado

Con el proceso de desactualización en un data warehouse se mueve el detalle de la data actual a data antigua, basado en el tiempo de los datos. El proceso de esquematización usa el detalle de los datos para calcular los datos en forma ligera y completamente resumidos. Hay pocas excepciones al flujo mostrado. Sin embargo, en general, para la mayoría de datos encontrados en un data warehouse, el flujo de la información es como se ha explicado.

��

Medios de Almacenamiento para Información Antigua El símbolo mostrado en la Figura N° 11 para medios de almacenamiento de información antigua es la cinta magnética, que puede usarse para almacenar este tipo de información. De hecho hay una amplia variedad de medios de almacenamiento que deben considerarse para almacenar datos más antiguos. En la figura se muestra algunos de esos medios. Dependiendo del volumen de información, la frecuencia de acceso, el costo de los medios y el tipo de acceso, es probable que otros medios de almacenamiento sirvan a las necesidades del nivel de detalle más antiguo en el data warehouse.

Usos del Data Warehouse Los datos operacionales y los datos del data warehouse son accedidos por usuarios que usan los datos de maneras diferentes. Uso de Base de Datos Operacionales Uso de Data Warehouse

Muchos usuarios concurrentes Pocos usuarios concurrentes Consultas predefinidas y actualizables

Consultas complejas, frecuentemente no anticipadas.

Cantidades pequeñas de datos detallados Cantidades grandes de datos detallados

Requerimientos de respuesta inmediata Requerimientos de respuesta no críticos

Maneras diferentes de uso de datos

Los usuarios de un data warehouse necesitan acceder a los datos complejos, frecuentemente desde fuentes múltiples y de formas no predecibles. Los usuarios que accedan a los datos operacionales, comúnmente efectúan tareas predefinidas que, generalmente requieren acceso a una sola base de datos de una aplicación. Por el contrario, los usuarios que accedan al data warehouse, efectúan

��

tareas que requieren acceso a un conjunto de datos desde fuentes múltiples y frecuentemente no son predecibles. Lo único que se conoce (si es modelada correctamente) es el conjunto inicial de datos que se han establecido en el depósito. Por ejemplo, un especialista en el cuidado de la salud podría necesitar acceder a los datos actuales e históricos para analizar las tendencias de costos, usando un conjunto de consultas predefinidas. Por el contrario, un representante de ventas podría necesitar acceder a los datos de cliente y producto para evaluar la eficacia de una campaña de marketing, creando consultas base o ad-hoc para encontrar nuevamente necesidades definidas.

Sólo pocos usuarios acceden a los datos concurrentemente

En contraste a la producción de sistemas que pueden manejar cientos o miles de usuarios concurrentes, al data warehouse acceda un limitado conjunto de usuarios en cualquier tiempo determinado.

Los usuarios generan un procesamiento no predecible complejo

Los usuarios del data warehouse generan consultas complejas. A veces la respuesta a una consulta conduce a la formulación de otras preguntas más detalladas, en un proceso llamado drilling down. El data warehouse puede incluir niveles de resúmenes múltiples, derivado de un conjunto principal, único, de datos detallados, para soportar este tipo de uso. En efecto, los usuarios frecuentemente comienzan buscando en los datos resumidos y como identifican áreas de interés, comienzan a acceder al conjunto de datos detallado. Los conjuntos de datos resumidos representan el "Qué" de una situación y los conjuntos de datos detallados permiten a los usuarios construir un cuadro sobre "Cómo" se ha derivado esa situación.

Las consultas de los usuarios accedan a cantidades grandes de datos

Debido a la necesidad de investigar tendencias y evaluar las relaciones entre muchas clases de datos, las consultas al data warehouse permiten acceder a volúmenes muy grandes tanto de data detallada como resumida. Debido a los requerimientos de datos históricos, los data warehouses evolucionan para llegar a un tamaño más grande que sus orígenes operacionales (de 10 a 100 veces más grande).

Las consultas de los usuarios no tienen tiempos de respuesta críticos

Las transacciones operacionales necesitan una respuesta inmediata porque un cliente puede estar esperando una respuesta. En el data warehouse, por el contrario, tiene un requerimiento de respuesta no crítico porque el resultado frecuentemente se usa en un proceso de análisis y toma de decisiones. Aunque los tiempos de respuesta no son críticos, los usuarios esperan una respuesta dentro del mismo día en que es hecha la consulta. Por lo general, los diferentes niveles de datos dentro del data warehouse reciben diferentes usos. A más alto nivel de esquematización, se tiene mayor uso de los datos. En la Figura N° 12 se muestra que hay mayor uso de los datos completamente resumidos, a diferencia de la información antigua que apenas es usada. Hay una buena razón para mover una organización al paradigma sugerido en la figura, la utilización del recurso. La data más resumida, permite capturar los datos en forma más rápida y eficiente. Si en una tarea se encuentra que se hace mucho procesamiento a niveles de detalle del data warehouse, entonces se consumirá

��

muchos recursos de máquina. Es mejor hacer el procesamiento a niveles más altos de esquematización como sea posible. Para muchas tareas, el analista de sistemas de soporte de decisiones usa la información detallada en un pre data warehouse. La seguridad de la información de detalle se consigue de muchas maneras, aun cuando estén disponibles otros niveles de esquematización. Una de las actividades del diseñador de datos es el de desconectar al usuario del sistema de soporte de decisiones del uso constante de datos con un detalle más bajo. El diseñador de datos tiene dos predisposiciones:

a. Instalar un sistema chargeback, donde el usuario final pague por los recursos consumidos

b. Señalar el mejor tiempo de respuesta que puede obtenerse cuando se trabaja con la data a un nivel alto de esquematización, a diferencia de un pobre tiempo de respuesta que resulta de trabajar con los datos a un nivel bajo de detalle.

Para ilustrar cómo un data warehouse puede ayudar a una organización a mejorar sus operaciones, se muestra un ejemplo de lo que es el desarrollo de actividades sin tener un data warehouse.

��

Ejemplo: Preparación de un reporte complejo

Considere un problema bastante típico en una compañía de producción grande en el que se pide una información (un reporte) que no está disponible. El informe incluye las finanzas actuales, el inventario y la condición de personal, acompañado de comparaciones del mes actual con el anterior y el mismo mes del año anterior, con una comparación adicional de los 3 años precedentes. Se debe explicar cada desviación de la tendencia que cae fuera de un rango predefinido. Sin un data warehouse, el informe es preparado de la manera siguiente: La información financiera actual se obtiene desde una base de datos mediante un programa de extracción de datos, el inventario actual de otro programa de extracción de otra base de datos, la condición actual de personal de un tercer programa de

��

extracción y la información histórica desde una copia de seguridad de cinta magnética o CD-ROM. Lo más interesante es que se ha pedido otro informe que continúe al primer informe (debido a que las preguntas se originaron a partir del anterior). El hecho es, que ninguno de los trabajos realizados hasta aquí (por ejemplo, diversos programas de extracción) se pueden usar para los próximos o para cualquier reporte subsiguiente. Imagine el tiempo y el esfuerzo que se ha desperdiciado por un enfoque anticuado. (Ver Figura N° 13). Las inconsistencias deben identificarse en cada conjunto de datos extraídos y resolverse, por lo general, manualmente. Cuando se completa todo este procesamiento, el reporte puede ser formateado, impreso, revisado y transmitido. Nuevamente, el punto importante aquí es que todo el trabajo desempeñado para hacer este informe no afecta a otros reportes que pueden solicitarse es decir, todos ellos son independientes y caros, desde el punto de vista de recursos y productividad. Al crear un data warehouse y combinar todos los datos requeridos, se obtienen los siguientes beneficios: Las inconsistencias de los datos se resuelven automáticamente cuando los elementos de datos se cargan en el data warehouse, no manualmente, cada vez que se prepara un reporte. Los errores que ocurrieron durante el proceso complejo de la preparación del informe, se minimizan porque el proceso es ahora mucho más simple. Los elementos de datos son fácilmente accesibles para otros usos, no sólo para un reporte particular. Se crea una sola fuente.

��

Consideraciones Adicionales

Hay algunas consideraciones adicionales que deben tenerse en cuenta al construir y administrar el data warehouse. La primera consideración es respecto al índice. La información de los niveles de esquematización más altos pueden ser libremente indexados, mientras que las de los niveles más bajos de detalle, por ser tan voluminosa, pueden ser indexados moderadamente. Por lo mismo, los datos en los niveles más altos de detalle pueden ser reestructurados fácilmente, mientras que el volumen de datos en los niveles más inferiores es tan grande, que los datos no pueden ser fácilmente reestructurados. Por consiguiente, el modelo de datos y el diseño clásico fundamentan que el data warehouse se aplique casi exclusivamente al nivel actual de detalle. En otras palabras, las actividades de modelamiento de datos no se aplican a los niveles de esquematización, en casi todos los casos. Otra consideración estructural es la partición de la información en el data warehouse. El nivel de detalle actual es casi siempre particionado. La partición puede hacerse de dos maneras: al nivel de DBMS y al nivel de la aplicación. En la partición DBMS, se conoce las particiones y se administra por

��

consiguiente. En el caso de la partición de las aplicaciones, sólo los programadores de las mismas conocen las particiones y la responsabilidad de su administración es asignada a ellos. Al interior de las particiones DBMS, mucho de los trabajos de infraestructura se hacen automáticamente. Pero existe un elevado grado de rigidez asociada con la gestión automática de las particiones. En el caso de las particiones de las aplicaciones del data warehouse, la mayor parte del trabajo recae sobre el programador, pero el resultado final es que la gestión de datos es más flexible.

Excepciones en el Data Warehouse

Mientras que los componentes del data warehouse trabajan de acuerdo al modelo descrito para casi todos los datos, hay pocas excepciones útiles que necesitan ser discutidas. Una de ellas es la data resumida pública, que es la data que ha sido calculada fuera del data warehouse pero es usada a través de la corporación. La data resumida pública se almacena y administra en el data warehouse, aunque su cálculo se haya hecho fuera de él. Un ejemplo clásico de data resumida pública es el archivamiento trimestral hecho por cada compañía pública. Los contadores trabajan para producir cantidades como rentas trimestrales, gastos trimestrales, ganancias trimestrales y otros. El trabajo hecho por los contadores está fuera del data warehouse. Sin embargo, esas cantidades referenciales producidas por ellos se usan ampliamente dentro de la corporación para marketing, ventas, etc. Una vez que se haya hecho el archivo, los datos se almacenan en el data warehouse. Otra excepción no considerada en este documento es la data externa. Otro excepcional tipo de datos a veces encontrados en un data warehouse es el detalle de los datos permanentes, que resulta de la necesidad de una corporación para almacenar la data a un nivel detallado permanentemente por razones éticas o legales. Si una corporación expone a sus trabajadores a sustancias peligrosas hay una necesidad de detalle de datos permanente. Si una corporación produce un producto que involucra la seguridad pública, tal como la construcción de las partes de aviones, hay una necesidad de datos permanentes. Si una corporación se compromete con contratos peligrosos, hay una necesidad de detalle de datos permanentes. La organización simplemente no puede dejar los detalles porque en futuros años, en el caso de una demanda, una notificación, un edificio en disputa, etc., se incrementaría la exposición de la compañía. Por lo tanto hay un único tipo de datos en el data warehouse conocido como detalle de datos permanentes. El detalle de datos permanentes comparte muchas de las mismas consideraciones como otro data warehouse, excepto que:

• El medio donde se almacena la data debe ser tan seguro como sea posible. • Los datos deben permitir ser restaurados. • Los datos necesitan un tratamiento especial en su indexación, ya que de otra

manera los datos pueden no ser accesibles aunque se haya almacenado con mucha seguridad.

��

Proyecto de un Data Warehouse.

Organización

La planificación es el proceso más importante que determina la clase de tipo de estrategias data warehousing que una organización iniciará.

Factores en la Planificación de un Data Warehouse

No existe una fórmula de garantía real para el éxito de la construcción de un data warehouse, pero hay muchos puntos que contribuyen a ese objetivo. A continuación, se indican algunos puntos claves que deben considerarse en la planificación de un data warehouse:

Establecer una asociación de usuarios, gestión y grupos

Es esencial involucrar tanto a los usuarios como a la gestión para asegurar que el data warehouse contenga información que satisfaga los requerimientos de la empresa. La gestión puede ayudar a priorizar la fase de la implementación del data warehouse, así como también la selección de herramientas del usuario. Los usuarios y la gestión justifican los costos del data warehouse sobre cómo será "su ambiente" y está basado primero en lo esperado y segundo, en el valor comercial real.

Seleccionar una aplicación piloto con una alta probabilidad de éxito

Una aplicación piloto de alcance limitado, con un reembolso medible para los usuarios y la gestión, establecerá el data warehouse como una tecnología clave para la empresa. Estos mismos criterios (alcance limitado, reembolso medible y beneficios claros para la empresa) se aplican a cada fase de la implementación de un data warehouse.

Construir prototipos rápida y frecuentemente

La única manera para asegurar que el data warehouse reúna las necesidades de los usuarios, es hacer el prototipo a lo largo del proceso de implementación y aún más allá, así como agregar los nuevos datos y/o los modelos en forma permanente. El trabajo continuo con los usuarios y la gestión es, nuevamente, la clave.

Implementación incremental

La implementación incremental reduce riesgos y asegura que el tamaño del proyecto permanezca manejable en cada fase.

Reportar activamente y publicar los casos exitosos

La retroalimentación de los usuarios ofrece una excelente oportunidad para publicar los hechos exitosos dentro de una organización. La publicidad interna sobre cómo el data warehouse ha ayudado a los usuarios a operar más efectivamente puede apoyar la construcción del data warehouse a lo largo de una empresa. La retroalimentación del usuario también ayuda a comprender cómo evoluciona la implementación del data warehouse a través del tiempo para reunir requerimientos de usuario nuevamente identificados.

Estrategias para el Desarrollo de un Data Warehouse

Antes de desarrollar un data warehouse, es crítico el desarrollo de una estrategia equilibrada que sea apropiada para sus necesidades y sus usuarios. Las preguntas que deben tenerse en cuenta son:

• ¿Quién es el auditorio?

��

• ¿Cuál es el alcance? • ¿Qué tipo de data warehouse debería construirse?

Existe un número de estrategias mediante las cuales las organizaciones pueden conseguir sus data warehouses.

Primera

Establecer un ambiente "data warehouse virtual", el cual puede ser creado por: • Instalación de un conjunto de facilidades para acceso a datos, directorio de

datos y gestión de proceso. • Entrenamiento de usuarios finales. • Control de cómo se usan realmente las instalaciones del data warehouse. • Basados en el uso actual, crear un data warehouse físico para soportar los

pedidos de alta frecuencia.

Segunda

Construir una copia de los datos operacionales desde un sistema operacional único y posibilitar al data warehouse de una serie de herramientas de acceso a la información. Esta estrategia tiene la ventaja de ser simple y rápida. Desafortunadamente, si los datos existentes son de mala calidad y/o el acceso a los datos no ha sido previamente evaluado, entonces se puede crear una serie de problemas.

Tercera

Finalmente, la estrategia data warehousing óptima es seleccionar el número de usuarios basados en el valor de la empresa y hacer un análisis de sus puntos, preguntas y necesidades de acceso a datos. De acuerdo a estas necesidades, se construyen los prototipos data warehousing y se prueban para que los usuarios finales puedan experimentar y modificar sus requerimientos. Una vez se tenga un consenso general sobre las necesidades, entonces se consiguen los datos provenientes de los sistemas operacionales existentes a través de la empresa y/o desde fuentes externas de datos y se cargan al data warehouse. Si se requieren herramientas de acceso a la información, se puede también permitir a los usuarios finales tener acceso a los datos requeridos usando sus herramientas favoritas propias, o facilitar la creación de sistemas de acceso a la información multidimensional de alta performance, usando el núcleo del data warehouse como base.

En conclusión

No se tiene un enfoque único para construir un data warehouse que se adapte a las necesidades de las empresas, debido a que las necesidades de cada una de ellas son diferentes, al igual que su contexto. Además, como la tecnología data warehousing va evolucionando, se aprende cada vez más y más sobre el desarrollo de data warehouses, que resulta en que el único enfoque práctico para al almacenamiento de datos es la evolución de uno mismo.

Estrategias para el Diseño de un Data Warehouse

El diseño de los data warehouses es muy diferente al diseño de los sistemas operacionales tradicionales. Se pueden considerar los siguientes puntos:

1. Los usuarios de los data warehouses usualmente no conocen mucho sobre sus requerimientos y necesidades como los usuarios operacionales.

2. El diseño de un data warehouse, con frecuencia involucra lo que se piensa en términos más amplios y con conceptos del negocio más difíciles de definir que en el diseño de un sistema operacional. Al respecto, un data warehouse está

��

bastante cerca a Reingeniería de los Procesos del Negocio (Business Process Reengineering).

3. Finalmente, la estrategia de diseño ideal para un data warehousing es generalmente de afuera hacia adentro (outside-in) a diferencia de arriba hacia abajo (top-down).

A pesar que el diseño del data warehouse es diferente al usado en los diseños tradicionales, no es menos importante. El hecho que los usuarios finales tengan dificultad en definir lo que ellos necesitan, no lo hace menos necesario. En la práctica, los diseñadores de data warehouses tienen que usar muchos "trucos" para ayudar a sus usuarios a "visualizar" sus requerimientos. Por ello, son esenciales los prototipos de trabajo.

Estrategias para la Gestión de un Data Warehouse

Los data warehouses requieren una comercialización y gestión muy cuidadosa. Debe considerarse lo siguiente:

1. Un data warehouse es una inversión buena sólo si los usuarios finales realmente pueden conseguir información vital más rápida y más barata de lo que obtienen con la tecnología actual. Como consecuencia, la gestión tiene que pensarse seriamente sobre cómo quieren sus depósitos para su eficaz desempeño y cómo conseguirán llegar a los usuarios finales.

2. La administración debe reconocer que el mantenimiento de la estructura del data warehouse es tan crítico como el mantenimiento de cualquier otra aplicación de misión crítica. De hecho, la experiencia ha demostrado que los data warehouses llegarán a ser rápidamente uno de los sistemas más usados en cualquier organización.

3. La gestión debe comprender también que si se embarcan sobre un programa data warehousing, se crearán nuevas demandas sobre sus sistemas operacionales, que son:

• Demandas para mejorar datos • Demandas para una data consistente • Demandas para diferentes tipos de datos, etc.

Desarrollo

¿Porque Construir Bloques de Data Warehouse?

Para ampliar un negocio, se necesita que la información sea comprensible. Para muchas compañías, esto significa un gran data warehouse que muestre, junto a los datos no filtrados y dispersos, nuevas formas creativas de presentación. Las herramientas para capturar y explorar los datos al detalle evolucionan, así como nuestra capacidad para encontrar las formas de explotar los datos recolectados. En los últimos 10 años se han combinado dos factores para ayudar a la difusión de los data warehouses. Ellos son:

1. Se ha reconocido los beneficios del procesamiento analítico en línea (On Line Analytical Processing - OLAP), más allá de las áreas tradicionales de marketing y finanzas. Las organizaciones saben que los conocimientos inmersos en las masas de datos que rutinariamente recogen sobre sus clientes, productos, operaciones y actividades comerciales, contribuyen a reducir los costos de operación y aumentar las rentas, por no mencionar que es más fácil la toma de decisiones estratégicas.

��

2. El crecimiento de la computación cliente/servidor, ha creado servidores de hardware y software más poderosos y sofisticados que nunca. Los servidores de hoy compiten con las mainframes de ayer y ofrecen arquitecturas de memoria tecnológicamente superiores, procesadores de alta velocidad y capacidades de almacenamiento masivas. Al mismo tiempo, los Sistemas de Gestión de Base de Datos (Data Base Management Systems - DBMS(s)) modernos, proporcionan mayor soporte para las estructuras de datos complejas. De esta renovación de hardware y software surgen los data warehouses multiterabyte que ahora se ve en ambientes de cliente/servidor.

Consideraciones Previas al Desarrollo de un Data Warehouse

Hay muchas maneras para desarrollar data warehouses como tantas organizaciones existen. Sin embargo, hay un número de dimensiones diferentes que necesitan ser consideradas:

• Alcance de un data warehouse • Redundancia de datos • Tipo de usuario final

Alcance des Data Warehouse

El alcance de un data warehouse puede ser tan amplio como toda la información estratégica de la empresa desde su inicio, o puede ser tan limitado como un data warehouse personal para un solo gerente durante un año. En la práctica, en la amplitud del alcance, el mayor valor del data warehouse es para la empresa y lo más caro y consumidor de tiempo es crear y mantenerlo. Como consecuencia de ello, la mayoría de las organizaciones comienzan con data warehouses funcionales, departamentales o divisionales y luego los expanden como usuarios que proveen retroalimentación.

Redundancia de Datos

Hay tres niveles esenciales de redundancia de datos que las empresas deberían considerar en sus opciones de data warehouse:

• Data warehouses "virtual" o "Point to Point" • Data warehouses "centrales" • Data warehouses "distribuidos"

No se puede pensar en un único enfoque. Cada opción adapta un conjunto específico de requerimientos y una buena estrategia de almacenamiento de datos, lo constituye la inclusión de las tres opciones. Data Warehouses "Virtual" o "Point to Point" Una estrategia de data warehouses virtual, significa que los usuarios finales pueden acceder a bases de datos operacionales directamente, usando cualquier herramienta que posibilite "la red de acceso de datos". Este enfoque provee flexibilidad así como también la cantidad mínima de datos redundantes que deben cargarse y mantenerse. Además, se pueden colocar las cargas de consulta no planificadas más grandes, sobre sistemas operacionales. Como se verá, el almacenamiento virtual es, frecuentemente, una estrategia inicial, en organizaciones donde hay una amplia (pero en su mayor parte indefinida) necesidad de conseguir la data operacional, desde una clase relativamente grande de usuarios finales y donde la frecuencia probable de pedidos es baja. Los depósitos virtuales de datos proveen un punto de partida para que las organizaciones determinen qué usuarios finales están buscando realmente. Data Warehouses "Centrales"

��

El concepto de data warehouses centrales es el concepto inicial que se tiene del data warehouse. Es una única base de datos física, que contiene todos los datos para un área funcional específica, departamento, división o empresa. Los data warehouses centrales se seleccionan por lo general donde hay una necesidad común de los datos informáticos y un número grande de usuarios finales ya conectados a una red o computadora central. Pueden contener datos para cualquier período específico de tiempo. Comúnmente, contienen datos de sistemas operacionales múltiples. Los data warehouses centrales son reales. Los datos almacenados en el data warehouse son accesibles desde un lugar y deben cargarse y mantenerse sobre una base regular. Normalmente se construyen alrededor de RDBMS avanzados o, en alguna forma, de servidor de base de datos informático multidimensional. Data Warehouses Distribuidos Los data warehouses distribuidos son aquellos en los cuales ciertos componentes del depósito se distribuyen a través de un número de bases de datos físicas diferentes. Cada vez más, las organizaciones grandes están tomando decisiones a niveles más inferiores de la organización y a la vez, llevando los datos que se necesitan para la toma de decisiones a la red de área local (Local Area Network - LAN) o computadora local que sirve al que toma decisiones. Los data warehouses distribuidos comúnmente involucran la mayoría de los datos redundantes y como consecuencia de ello, se tienen procesos de actualización y carga más complejos.

Tipo de Usuario Final

De la misma forma que hay una gran cantidad de maneras para organizar un data warehouse, es importante notar que también hay una gama cada vez más amplia de usuarios finales. En general, se puede considerar tres grandes categorías:

• Ejecutivos y gerentes • "Power users" o "Buzo de Información" (analistas financieros y de negocios,

ingenieros, etc.) • Usuarios de soporte (de oficina, administrativos, etc.).

Cada una de estas categorías diferentes de usuario tienen su propio conjunto de requerimientos para los datos, acceso, flexibilidad y facilidad de uso.

Elementos Claves para el Desarrollo de un Data Warehouse

Los data warehouses exitosos comienzan cuando se escogen e integran satisfactoriamente tres elementos claves. Un data warehouse está integrado por un servidor de hardware y los DBMS que conforman el depósito. Del lado del hardware, se debe combinar la configuración de plataformas de los servidores, mientras se decide cómo aprovechar los saltos casi constantes de la potencia del procesador. Del lado del software, la complejidad y el alto costo de los DBMSes fuerzan a tomar decisiones drásticas y balances comparativos inevitables, con respecto a la integración, requerimientos de soporte, desempeño, eficiencia y confiabilidad. Si se escoge incorrectamente, el data warehouse se convierte en una gran empresa con problemas difíciles de trabajar en su entorno, costoso para arreglar y difícil de justificar. Para conseguir que la implementación del depósito tenga un inicio exitoso, se necesita enfocar hacia tres bloques claves de construcción:

• Arquitectura total del depósito • Arquitecturas del servidor • Sistemas de Gestión de Base de Datos

��

A continuación se presentan algunas recomendaciones para tomar las correctas elecciones para su empresa.

Diseño de la Arquitectura

Arquitectura del Depósito El desarrollo del data warehouse comienza con la estructura lógica y física de la base de datos del depósito más los servicios requeridos para operar y mantenerlo. Esta elección conduce a la selección de otros dos ítems fundamentales: el servidor de hardware y el DBMS. La plataforma física puede centralizarse en una sola ubicación o distribuirse regional, nacional o internacionalmente. A continuación se dan las siguientes alternativas de arquitectura: Un plan para almacenar los datos de su compañía, que podría obtenerse desde fuentes múltiples internas y externas, es consolidar la base de datos en un data warehouse integrado. El enfoque consolidado proporciona eficiencia tanto en la potencia de procesamiento como en los costos de soporte.

1. La arquitectura global distribuye información por función, con datos financieros sobre un servidor en un sitio, los datos de comercialización en otro y los datos de produccion en un tercer lugar.

2. Una arquitectura por niveles almacena datos altamente resumidos sobre una estación de trabajo del usuario, con resúmenes más detallados en un segundo servidor y la información más detallada en un tercero. La estación de trabajo del primer nivel maneja la mayoría de los pedidos para los datos, con pocos pedidos que pasan sucesivamente a los niveles 2 y 3 para la resolución. Las computadoras en el primer nivel pueden optimizarse para usuarios de carga pesada y volumen bajo de datos, mientras que los servidores de los otros niveles son más adecuados para procesar los volúmenes pesados de datos, pero cargas más livianas de usuario. (Ver figura N° 18).

Arquitectura del servidor Al decidir sobre una estructura de depósito distribuida o centralizada, también se necesita considerar los servidores que retendrán y entregarán los datos. El tamaño de su implementación (y las necesidades de su empresa para escalabilidad, disponibilidad y gestión de sistemas) influirá en la elección de la arquitectura del servidor. 1° Servidores de un solo procesador Los servidores de un sólo procesador son los más fáciles de administrar, pero ofrecen limitada potencia de procesamiento y escalabilidad. Además, un servidor sólo presenta un único punto de falla, limitando la disponibilidad garantizada del depósito. Se puede ampliar un solo servidor de redes mediante arquitecturas distribuidas que hacen uso de subproductos, tales como Ambientes de Computación Distribuida (Distributed Computing Environment - DCE) o Arquitectura Broker de Objeto Común (Common Objects Request Broker Architecture - CORBA), para distribuir el tráfico a través de servidores múltiples. Estas arquitecturas aumentan también la disponibilidad, debido a que las operaciones pueden cambiarse al servidor de copia de seguridad si un servidor falla, pero la gestión de sistemas es más compleja. 2° Multiprocesamiento simétrico Las máquinas de multiprocesamiento simétrico (Symmetric MultiProcessing - SMP) aumentan mediante la adición de procesadores que comparten la memoria interna de los servidores y los dispositivos de almacenamiento de disco. Se puede adquirir la mayoría de SMP en configuraciones mínimas (es decir, con dos procesadores) y levantar cuando es necesario, justificando el crecimiento con las necesidades de procesamiento. La escalabilidad de una máquina SMP alcanza su

��

límite en el número máximo de procesadores soportados por los mecanismos de conexión (es decir, el backplane y bus compartido). 3° Procesamiento en paralelo masivo Una máquina de procesamiento en paralelo masivo (Massively Parallel Processing - MPP), conecta un conjunto de procesadores por medio de un enlace de banda ancha y de alta velocidad. Cada nodo es un servidor, completo con su propio procesador (posiblemente SMP) y memoria interna. Para optimizar una arquitectura MPP, las aplicaciones deben ser "paralelizadas" es decir, diseñadas para operar por separado, en partes paralelas. Esta arquitectura es ideal para la búsqueda de grandes bases de datos. Sin embargo, el DBMS que se selecciona debe ser uno que ofrezca una versión paralela. Y aún entonces, se requiere un diseño y afinamiento esenciales para obtener una óptima distribución de los datos y prevenir "hot spots" o "data skew" (donde una cantidad desproporcionada del procesamiento es cambiada a un nodo de procesamiento, debido a la partición de los datos bajo su control). 4° Acceso de memoria no uniforme La dificultad de mover aplicaciones y los DBMS a agrupaciones o ambientes realmente paralelos ha conducido a nuevas y recientes arquitecturas, tales como el acceso de memoria no uniforme (Non Uniform Memory Access - NUMA). NUMA crea una sola gran máquina SMP al conectar múltiples nodos SMP en un solo (aunque físicamente distribuida) banco de memoria y un ejemplo único de OS. NUMA facilita el enfoque SMP para obtener los beneficios de performance de las grandes máquinas MPP (con 32 o más procesadores), mientras se mantiene las ventajas de gestión y simplicidad de un ambiente SMP estándar. Lo más importante de todo, es que existen DBMS y aplicaciones que pueden moverse desde un solo procesador o plataforma SMP a NUMA, sin modificaciones.

Sistemas de Gestión de Bases de Datos

Los data warehouses (conjuntamente con los sistemas de soporte de decisión [Decision Support Systems - DSS] y las aplicaciones cliente/servidor), fueron los primeros éxitos para el DBMS relacional (Relational Data Base Management Systems - RDBMS). Mientras la gran parte de los sistemas operacionales fueron resultados de aplicaciones basadas en antiguas estructuras de datos, los depósitos y sistemas de soporte de decisiones aprovecharon el RDBMS por su flexibilidad y capacidad para efectuar consultas con un único objetivo concreto. Los RDBMS son muy flexibles cuando se usan con una estructura de datos normalizada. En una base de datos normalizada, las estructuras de datos son no redundantes y representan las entidades básicas y las relaciones descritas por los datos (por ejemplo productos, comercio y transacción de ventas). Pero un procesamiento analítico en línea (OLAP) típico de consultas que involucra varias estructuras, requiere varias operaciones de unión para colocar los datos juntos. La performance de los RDBMS tradicionales es mejor para consultas basadas en claves ("Encuentre bovino # P15E125C2014") que para consultas basadas en el contenido; ("Encuentre a todos los animales, de categoría Novillos, y raza Brangus, de la region NEA y de la provincia de Formosa que han superado los 400 Kg. Vivos al momento de la venta. Ademas, encuentre el nombre del productor de esos animales."). Para el soporte de depósitos a gran escala y para mejorar el interés hacia las aplicaciones OLAP, los proveedores han añadido nuevas características al RDBMS tradicional. Estas, también llamadas características super relacionales, incluyen el soporte para hardware de base de datos especializada, tales como la máquina de base de datos Teradata.

��

Los modelos super relacionales también soportan extensiones para almacenar formatos y operaciones relacionales (ofrecidas por proveedores como REDBRICK) y diagramas de indexación especializados, tales como aquellos usados por SYBASE IQ. Estas técnicas pueden mejorar el rendimiento para las recuperaciones basadas en el contenido, al pre juntar tablas usando índices o mediante el uso de listas de índice totalmente invertidos. Muchas de las herramientas de acceso a los data warehouses explotan la naturaleza multidimensional del data warehouse. Por ejemplo, los analistas de marketing necesitan buscar en los volúmenes de ventas por producto, por mercado, por período de tiempo, por promociones y niveles anunciados y por combinaciones de estos diferentes aspectos. La estructura de los datos en una base de datos relacional tradicional, facilita consultas y análisis a lo largo de dimensiones diferentes que han llegado a ser comunes. Estos esquemas podrían usar tablas múltiples e indicadores para simular una estructura multidimensional. Algunos productos DBMS, tales como ESSBASE y GENTIUM, implementan técnicas de almacenamiento y operadores que soportan estructuras de datos multidimensionales. Mientras las bases de datos multidimensionales (MultiDimensional Databases - MDDBs) ayudan directamente a manipular los objetos de datos multidimensionales (por ejemplo, la rotación fácil de los datos para verlos entre dimensiones diferentes, o las operaciones de drill down que sucesivamente exponen los niveles de datos más detallados), se debe identificar estas dimensiones cuando se construya la estructura de la base de datos. Así, agregar una nueva dimensión o cambiar las vistas deseadas, puede ser engorroso y costoso. Algunos MDDBS requieren un recargue completo de la base de datos cuando ocurre una reestructuración.

Nuevas Dimensiones

Una limitación de un RDBMS y un MDDB, es la carencia de soporte para tipos de datos no tradicionales como imágenes, documentos y clips de vídeo / audio. Por su enfoque en los valores de datos codificados, la mayor parte de los sistemas de base de datos pueden acomodar estos tipos de datos, sólo con extensiones basadas en cierta referencias, tales como indicadores de archivos que contienen los objetos. Muchos RDBMS almacenan los datos complejos como objetos grandes binarios (Binary Large Objects - BLOBs). En este formato, los objetos no pueden ser indexados, clasificados, o buscados por el servidor. Los DBMS relacional - objeto, de otro lado, almacenan los datos complejos como objetos nativos y pueden soportar las grandes estructuras de datos encontradas en un ambiente orientado a objetos. Estos sistemas de base de datos naturalmente acomodan no sólo tipos de datos especiales sino también los métodos de procesamiento que son únicos para cada uno de ellos. Pero una desventaja del enfoque relacional - objeto, es que la encapsulación de los datos dentro de los tipos especiales de datos (una serie de precios de stock a través del tiempo en cada registro de una tabla de stock, por ejemplo), requiere de operadores especializados para que hagan búsquedas simples previamente (por ejemplo, "Encontrar todas las existencias que han mostrado una disminución en el precio de Abril a Mayo 1996"). La selección del DBMS está también sujeta al servidor de hardware que se usa. Algunos RDBMS, como el DB2 Paralelo, INFORMIX XPS y el ORACLE Paralelo, ofrecen versiones que soportan operaciones paralelas. El software paralelo divide consultas, uniones a través de procesadores múltiples y corre estas operaciones simultáneamente para mejorar la performance. Se requiere el paralelismo para el mejor desempeño en los servidores MPP grandes y SMP agrupados. No es aún una opción con MDDBS o DBMS relacional - objeto.

��

En la tabla "Cómo comparar DBMS" se resume los pro y los contra de los diferentes tipos de DBMS para operaciones de data warehouse. La tabla "Matriz de Decisión del Data Warehouse" contiene algunos ejemplos de cómo afectan estos criterios de decisión en la elección de una arquitectura de servidor/ data warehouse. Matriz de Decisión para el Data Warehouse Para estos ambientes… Elija… Requerimientos comerciales

Usuarios Soporte de Sistemas

Arquitectura Servidor DBMS

Alcance: departamental Usos: análisis de datos

Pequeña - ubicación única

Local mínimo - central promedio

Consolidado - paquete

Procesador único o SMP MDDB

Alcance: departamental Usos: análisis más informática

Grande Analistas en una sola ubicación; usuarios informáticos dispersos

Local mínimo - central promedio

Seccionado - detalle en central - resumen en local

Grupos de SMP para central; SP o SMP para local

RDBMS para central - MDDB para local

Alcance: empresa Usos: análisis más informática

Grande; geográficamente disperso

Central fuerte Centralizado Grupos de

SMP

Objeto-relacional- soporte Web

Alcance: departamental Usos: investigación

Pequeña - pocas ubicaciones

Central fuerte Centralizado MPP

RDBMS con soporte paralelo

��

Combinación de la Arquitectura con el Sistema de Gestión de Bases de Datos

Para seleccionar la combinación correcta de la arquitectura del servidor y el DBMS, primero es necesario comprender los requerimientos comerciales de su compañía, su población de usuarios y las habilidades del personal de soporte. Las implementaciones de los data warehouses varían apreciablemente de acuerdo al área. Algunos son diseñados para soportar las necesidades de análisis específico para un solo departamento o área funcional de una organización, tales como finanzas, ventas o marketing. Las otras implementaciones reúnen datos a través de toda la empresa para soportar una variedad de grupos de usuarios y funciones. Por regla general, a mayor área del depósito, se requiere mayor potencia y funcionalidad del servidor y el DBMS. Los modelos de uso de los data warehouses son también un factor. Las consultas y vistas de reportes preestructuradas frecuentemente satisfacen a los usuarios informáticos, mientras que hay menos demandas sobre el DBMS y la potencia de procesamiento del servidor. El análisis complejo, que es típico de los ambientes de decisión - soporte, requiere más poder y flexibilidad de todos los componentes del servidor. Las búsquedas masivas de grandes data warehouses favorecen el paralelismo en el DBMS y el servidor. Los ambientes dinámicos, con sus requerimientos siempre cambiantes, se adaptan mejor a una arquitectura de datos simple, fácilmente cambiable (por ejemplo, una estructura relacional altamente normalizada), antes que una estructura intrincada que requiere una reconstrucción después de cada cambio (por ejemplo, una estructura multidimensional). El valor de la data fresca requerida indica cuán importante es para el data warehouse renovar y cambiar los datos. Los grandes volúmenes de datos que se refrescan a intervalos frecuentes, favorecen una arquitectura físicamente centralizada para soportar una captura de datos eficiente y minimizar el tiempo de transporte de los datos. Un perfil de usuario debería identificar quiénes son los usuarios de su data warehouse, dónde se ubican y cuántos necesita soportar. La información sobre cómo cada grupo espera usar los data warehouses, ayudará a analizar los diversos estilos de uso. Conocer la ubicación física de sus usuarios ayudará a determinar cómo y a qué área necesita distribuir el data warehouse. Una arquitectura por niveles podría usar servidores en el lugar de las redes de área local. O puede necesitar un enfoque centralizado para soportar a los trabajadores que se movilizan y que trabajan en el depósito desde sus laptops. El número total de usuarios y sus modelos de conexión determinan el tamaño de sus servidores de depósito. Los tamaños de memoria y los canales de I/O deben soportar el número previsto de usuarios concurrentes bajo condiciones normales, así como también en las horas punta de su organización. Finalmente, se debe factorizar la sofisticación del personal de soporte. Los recursos de los sistemas de información (Information System - IS) que están disponibles dentro de su organización, pueden limitar la complejidad o sofisticación de la arquitectura del servidor. Sin el personal especializado interno o consultores externos, es difícil de crear y mantener satisfactoriamente una arquitectura que requiere paralelismo en la plataforma del servidor (MPP o SMP agrupado, por ejemplo).

Planes de Expansion

Como su depósito evoluciona y los datos que contiene llegan a ser más accesible, los empleados externos al depósito podrían descubrir también el valor de sus datos. Al enlazar su data warehouse a otros sistemas (tanto internos como externos a la

��

organización), se puede compartir información con otras entidades comerciales con poco o sin desarrollo. Los mensajes de correo electrónico, servidores WEB y conexiones Intranet/Internet, pueden entregar listas por niveles a sus proveedores o según su condición, a sus socios de negocio. Como los data warehouses continúan creciendo en sofisticación y uso, los datos acumulados dentro de una empresa llegarán a ser más organizados, más interconectados, más accesibles y, en general, más disponibles a más empleados. El resultado será la obtención de mejores decisiones en el negocio, más oportunidades y más claridad de trabajo.

Confiabilidad de los Datos

La data "sucia" es peligrosa. Las herramientas de limpieza especializadas y las formas de programar de los clientes proporcionan redes de seguridad. No importa cómo esté diseñado un programa o cuán hábilmente se use. Si se alimenta mala información, se obtendrá resultados incorrectos o falsos. Desafortunadamente, los datos que se usan satisfactoriamente en las aplicaciones de línea comercial operacionales pueden ser basura en lo que concierne a la aplicación data warehousing. Los datos "sucios" pueden presentarse al ingresar información en una entrada de datos (por ejemplo, "Sistemas S. A." en lugar de "Sistemas S. A.") o de otras causas. Cualquiera que sea, la data sucia daña la credibilidad de la implementación del depósito completo. Afortunadamente, las herramientas de limpieza de datos pueden ser de gran ayuda. En algunos casos, puede crearse un programa de limpieza efectivo. En el caso de bases de datos grandes, imprecisas e inconsistentes, el uso de las herramientas comerciales puede ser casi obligatorio. Decidir qué herramienta usar es importante y no solamente para la integridad de los datos. Si se equivoca, se podría malgastar semanas en recursos de programación o cientos de miles de dólares en costos de herramientas. La limpieza de una data "sucia" es un proceso multifacético y complejo. Los pasos a seguir son los siguientes:

1. Analizar sus datos corporativos para descubrir inexactitudes, anomalías y otros problemas.

2. Transformar los datos para asegurar que sean precisos y coherentes. 3. Asegurar la integridad referencial, que es la capacidad del data warehouse,

para identificar correctamente al instante cada objeto del negocio, tales como un producto, un cliente o un empleado.

4. Validar los datos que usa la aplicación del data warehouse

��

Capitulo II: Herramientas y Metodologías Utilizadas.

Lenguaje de consulta estructurado (SQL)

INTRODUCCION:

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet (DBMS utilizado en el proyecto presentado). SQL se utiliza para crear objetos QueryDef, como el argumento de origen del método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente - servidor.

Componentes del SQL

El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos.

Comandos

Existen dos tipos de comandos SQL:

• los DLL que permiten crear y definir nuevas bases de datos, campos e índices. • los DML que permiten generar consultas para ordenar, filtrar y extraer datos de

la base de datos.

Comandos DLL

Comando Descripción

CREATE Utilizado para crear nuevas tablas, campos e índices

DROP Empleado para eliminar tablas e índices

ALTER Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

Comandos DML Comando Descripción

SELECT Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado

INSERT Utilizado para cargar lotes de datos en la base de datos en una única operación.

UPDATE Utilizado para modificar los valores de los campos y registros especificados

DELETE Utilizado para eliminar registros de una tabla de una base de datos

��

Cláusulas

Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.

Cláusula Descripción

FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros

WHERE Utilizada para especificar las condiciones que deben reunir los registros que se van a seleccionar

GROUP BY Utilizada para separar los registros seleccionados en grupos específicos

HAVING Utilizada para expresar la condición que debe satisfacer cada grupo

ORDER BY

Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

Operadores Lógicos

Operador Uso

AND Es el "y" lógico. Evalua dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas.

OR Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdar si alguna de las dos es cierta.

NOT Negación lógica. Devuelve el valor contrario de la expresión.

Operadores de Comparación

Operador Uso

< Menor que

> Mayor que

<> Distinto de

<= Menor ó Igual que

>= Mayor ó Igual que

= Igual que

BETWEEN Utilizado para especificar un intervalo de valores.

LIKE Utilizado en la comparación de un modelo

In Utilizado para especificar registros de una base de datos

��

Funciones de Agregado

Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único valor que se aplica a un grupo de registros.

Función Descripción

AVG Utilizada para calcular el promedio de los valores de un campo determinado

COUNT Utilizada para devolver el número de registros de la selección

SUM Utilizada para devolver la suma de todos los valores de un campo determinado

MAX Utilizada para devolver el valor más alto de un campo especificado

MIN Utilizada para devolver el valor más bajo de un campo especificado

Consultas de Selección

Las consultas de selección se utilizan para indicar al motor de datos que devuelva información de las bases de datos, esta información es devuelta en forma de conjunto de registros que se pueden almacenar en un objeto recordset. Este conjunto de registros es modificable.

Consultas básicas

La sintaxis básica de una consulta de selección es la siguiente:

SELECT Campos FROM Tabla;

En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los mismos, por ejemplo:

SELECT Nombre, Telefono FROM Clientes;

Esta consulta devuelve un recordset con el campo nombre y teléfono de la tabla clientes.

Ordenar los registros

Adicionalmente se puede especificar el orden en que se desean recuperar los registros de las tablas mediante la claúsula ORDER BY Lista de Campos. En donde Lista de campos representa los campos a ordenar. Ejemplo:

SELECT Caravana, Foto, Nombre FROM Vacunos ORDER BY Nombre;

Esta consulta devuelve los campos Caravana, Foto, Nombre de la tabla Vacunos ordenados por el campo Nombre.

��

Se pueden ordenar los registros por mas de un campo, como por ejemplo:

SELECT Caravana, Foto, Nombre FROM Vacunos ORDER BY Nombre; Caravana

Incluso se puede especificar el orden de los registros: ascendente mediante la claúsula (ASC -se toma este valor por defecto) ó descendente (DESC)

SELECT Caravana, Foto, Nombre FROM Vacunos ORDER BY Caravana DESC, Nombre ASC;

Consultas con Predicado

El predicado se incluye entre la claúsula y el primer nombre del campo a recuperar, los posibles predicados son:

Predicado Descripción

ALL Devuelve todos los campos de la tabla

TOP Devuelve un determinado número de registros de la tabla

DISTINCT Omite los registros cuyos campos seleccionados coincidan totalmente

DISTINCTROW Omite los registros duplicados basándose en la totalidad del registro y no sólo en los campos seleccionados.

ALL

Si no se incluye ninguno de los predicados se asume ALL. El Motor de base de datos selecciona todos los registros que cumplen las condiciones de la instrucción SQL. No se conveniente abusar de este predicado ya que obligamos al motor de la base de datos a analizar la estructura de la tabla para averiguar los campos que contiene, es mucho más rápido indicar el listado de campos deseados.

SELECT ALL FROM Pesos; SELECT * FROM Pesos; TOP

Devuelve un cierto número de registros que entran entre al principio o al final de un rango especificado por una cláusula ORDER BY. Supongamos que queremos recuperar los nombres de los 25 primeros vacunos del Rodeo:

SELECT TOP 25 Nombre, Foto FROM Vacunos ORDER BY Caravana DESC;

Si no se incluye la cláusula ORDER BY, la consulta devolverá un conjunto arbitrario de 25 registros de la tabla Vacunos .El predicado TOP no elige entre valores iguales. Se puede utilizar la palabra reservada PERCENT para devolver un cierto porcentaje de registros que caen al principio o al final de un rango especificado por la cláusula ORDER BY. Supongamos que en lugar de los 25 primeros Vacunos deseamos el 10 por ciento del Rodeo:

��

SELECT TOP 10 PERCENT Caravana, Peso FROM Pesos ORDER BY Peso DESC;

El valor que va a continuación de TOP debe ser un Integer sin signo. TOP no afecta a la posible actualización de la consulta.

DISTINCT

Omite los registros que contienen datos duplicados en los campos seleccionados. Para que los valores de cada campo listado en la instrucción SELECT se incluyan en la consulta deben ser únicos.

Por ejemplo, varios empleados listados en la tabla Vacunos pueden tener el mismo Nombre. Si dos registros contienen Margarita en el campo Nombre, la siguiente instrucción SQL devuelve un único registro:

SELECT DISTINCT Nombre FROM Vacunos;

Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la cláusula SELECT posean un contenido diferente. El resultado de una consulta que utiliza DISTINCT no es actualizable y no refleja los cambios subsiguientes realizados por otros usuarios.

DISTINCTROW

Devuelve los registros diferentes de una tabla; a diferencia del predicado anterior que sólo se fijaba en el contenido de los campos seleccionados, éste lo hace en el contenido del registro completo independientemente de los campo indicados en la cláusula SELECT.

SELECT DISTINCTROW Nombre FROM Vacunos;

Alias

En determinadas circunstancias es necesario asignar un nombre a alguna columna determinada de un conjunto devuelto, otras veces por simple capricho o por otras circunstancias. Para resolver todas ellas tenemos la palabra reservada AS que se encarga de asignar el nombre que deseamos a la columna deseada. Tomado como referencia el ejemplo anterior podemos hacer que la columna devuelta por la consulta, en lugar de llamarse Nombre (igual que el campo devuelto) se llame Vacuno. En este caso procederíamos de la siguiente forma:

SELECT DISTINCTROW Nombre AS Vacuno FROM Vacunos;

Recuperar Información de una base de Datos Externa

Para concluir este capítulo se debe hacer referencia a la recuperación de registros de bases de datos externa. Es ocasiones es necesario la recuperación de información que

��

se encuentra contenida en una tabla que no se encuentra en la base de datos que ejecutará la consulta o que en ese momento no se encuentra abierta, esta situación la podemos salvar con la palabra reservada IN de la siguiente forma:

SELECT DISTINCTROW Nombre AS Vacuno FROM Vacunos IN 'c:\Toma_de_decisiones\e-ganadero.mdb';

En donde c:\databases\gestion.mdb es la base de datos que contiene la tabla Empleados

Criterios de Selección

En el capítulo anterior se vio la forma de recuperar los registros de las tablas, las formas empleadas devolvían todos los registros de la mencionada tabla. A lo largo de este capítulo se estudiarán las posibilidades de filtrar los registros con el fin de recuperar solamente aquellos que cumplan una condiciones preestablecidas.

Antes de comenzar el desarrollo de este capítulo hay que recalcar tres detalles de vital importancia. El primero de ellos es que cada vez que se desee establecer una condición referida a un campo de texto la condición de búsqueda debe ir encerrada entre comillas simples; la segunda es que no se posible establecer condiciones de búsqueda en los campos memo y; la tercera y última hace referencia a las fechas. Las fechas se deben escribir siempre en formato mm-dd-aa en donde mm representa el mes, dd el día y aa el año, hay que prestar atención a los separadores -no sirve la separación habitual de la barra (/), hay que utilizar el guión (-) y además la fecha debe ir encerrada entre almohadillas (#). Por ejemplo si deseamos referirnos al día 3 de Septiembre de 2002 deberemos hacerlo de la siguente forma; #09-03-02# ó #9-3-02#.

Operadores Lógicos

Los operadores lógicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepción de los dos últimos todos poseen la siguiente sintaxis:

<expresión1> operador <expresión2>

En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado de la operación varía en función del operador lógico. La tabla adjunta muestra los diferentes posibles resultados:

<expresión1> Operador <expresión2> Resultado

Verdad AND Falso Falso

Verdad AND Verdad Verdad

Falso AND Verdad Falso

Falso AND Falso Falso

Verdad OR Falso Verdad

Verdad OR Verdad Verdad

��

Falso OR Verdad Verdad

Falso OR Falso Falso

Verdad XOR Verdad Falso

Verdad XOR Falso Verdad Falso XOR Verdad Verdad

Falso XOR Falso Falso

Verdad Eqv Verdad Verdad

Verdad Eqv Falso Falso

Falso Eqv Verdad Falso

Falso Eqv Falso Verdad

Verdad Imp Verdad Verdad

Verdad Imp Falso Falso

Verdad Imp Null Null

Falso Imp Verdad Verdad

Falso Imp Falso Verdad Falso Imp Null Verdad

Null Imp Verdad Verdad

Null Imp Falso Null

Null Imp Null Null Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la operación será el contrario al devuelto sin el operador NOT.

El último operador denominado Is se emplea para comparar dos variables de tipo objeto <Objeto1> Is <Objeto2>. este operador devuelve verdad si los dos objetos son iguales

SELECT * FROM Vacunos WHERE Edad > 4 AND Edad < 8; SELECT * FROM Vacunos WHERE (Edad > 3 AND Edad < 4) OR ETAPA_CRIA= 8; SELECT * FROM Vacunos WHERE NOT Procedencia = 'PANELLI';

Intervalos de Valores

Para indicar que deseamos recuperar los registros según el intervalo de valores de un campo emplearemos el operador Between cuya sintaxis es:

campo [Not] Between valor1 And valor2 (la condición Not es opcional)

En este caso la consulta devolvería los registros que contengan en "campo" un valor incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condición Not devolverá aquellos valores no incluidos en el intervalo.

SELECT * FROM Pesos WHERE pesol Between 150 And 300; (devuelve todos los animales que pesan entre 150 y 200 KG)

��

SELECT IIf(caravana Between 1 And 200, 'Compradas', 'Locales') FROM Vacunos; (Devuelve el valor 'Compradas' si la caravana se encuentra en el intervalo, 'Locall' en caso contrario)

El Operador Like

Se utiliza para comparar una expresión de cadena con un modelo en una expresión SQL. Su sintaxis es:

expresión Like modelo

En donde expresión es una cadena modelo o campo contra el que se compara expresión. Se puede utilizar el operador Like para encontrar valores en los campos que coincidan con el modelo especificado. Por modelo puede especificar un valor completo (Margarita 1), o se pueden utilizar caracteres comodín como los reconocidos por el sistema operativo para encontrar un rango de valores (Like Ma*).

El operador Like se puede utilizar en una expresión para comparar un valor de un campo con una expresión de cadena. Por ejemplo, si introduce Like C* en una consulta SQL, la consulta devuelve todos los valores de campo que comiencen por la letra C. En una consulta con parámetros, puede hacer que el usuario escriba el modelo que se va a utilizar.

El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido de cualquier letra entre A y F y de tres dígitos:

Like 'P[A-F]###'

Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la A a la D seguidas de cualquier cadena.

Like '[A-D]*'

En la tabla siguiente se muestra cómo utilizar el operador Like para comprobar expresiones con diferentes modelos.

Tipo de coincidencia Modelo Planteado Coincide No coincide

Varios caracteres 'a*a' 'aa', 'aBa', 'aBBBa' 'aBC'

Carácter especial 'a[*]a' 'a*a' 'aaa'

Varios caracteres 'ab*' 'abcdefg', 'abc' 'cab', 'aab'

Un solo carácter 'a?a' 'aaa', 'a3a', 'aBa' 'aBBBa'

Un solo dígito 'a#a' 'a0a', 'a1a', 'a2a' 'aaa', 'a10a'

Rango de caracteres '[a-z]' 'f', 'p', 'j' '2', '&'

Fuera de un rango '[!a-z]' '9', '&', '%' 'b', 'a'

Distinto de un dígito '[!0-9]' 'A', 'a', '&', '~' '0', '1', '9'

Combinada 'a[!b-m]#' 'An9', 'az0', 'a99' 'abc', 'aj0'

��

El Operador In

Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de los en una lista. Su sintaxis es:

expresión [Not] In(valor1, valor2, . . .)

SELECT * FROM ubicación WHERE potrero In ('Bañado', 'Chiquito', 'Garzas');

La cláusula WHERE La cláusula WHERE puede usarse para determinar qué registros de las tablas enumeradas en la cláusula FROM aparecerán en los resultados de la instrucción SELECT. Depués de escribir esta cláusula se deben especificar las condiciones expuestas en los partados 3.1 y 3.2. Si no se emplea esta cláusula, la consulta devolverá todas las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir a continuación de FROM.

SELECT Caravana, Peso FROM Pesos WHERE Peso > 21000;

SELECT caravana, Tot FROM Eficiencia WHERE tot <= 30;

SELECT * FROM Pesos WHERE Fecha = #5/10/94#;

SELECT Nombre FROM Vacunos WHERE Nombre = 'King';

SELECT Nombre FROM Vacunos WHERE Nombre Like 'S*';

SELECT Caravana, Area FROM Area_Pelvica WHERE cm2 Between 100 And 200;

Agrupamiento de Registros

GROUP BY

Combina los registros con valores idénticos, en la lista de campos especificados, en un único registro. Para cada registro se crea un valor sumario si se incluye una función SQL agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:

SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo

GROUP BY es opcional. Los valores de resumen se omiten si no existe una función SQL agregada en la instrucción SELECT. Los valores Null en los campos GROUP BY se agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de las funciones SQL agregadas.

Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la cláusula HAVING para filtrar los registros una vez agrupados.

��

A menos que contenga un dato Memo u Objeto OLE , un campo de la lista de campos GROUP BY puede referirse a cualquier campo de las tablas que aparecen en la cláusula FROM, incluso si el campo no esta incluido en la instrucción SELECT, siempre y cuando la instrucción SELECT incluya al menos una función SQL agregada.

Todos los campos de la lista de campos de SELECT deben o bien incluirse en la cláusula GROUP BY o como argumentos de una función SQL agregada.

SELECT caravana, Sum(peso) FROM Pesp GROUP BY caravana;

Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING.

HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a mostrar.

SELECT caravana Sum(peso) FROM Peso GROUP BY caravana HAVING Sum(peso) > 275;

AVG

Calcula la media aritmética de un conjunto de valores contenidos en un campo especificado de una consulta. Su sintaxis es la siguiente

Avg(expr)

En donde expr representa el campo que contiene los datos numéricos para los que se desea calcular la media o una expresión que realiza un cálculo utilizando los datos de dicho campo. La media calculada por Avg es la media aritmética (la suma de los valores dividido por el número de valores). La función Avg no incluye ningún campo Null en el cálculo.

SELECT Avg(peso) AS Promedio FROM Peso WHERE peso > 273;

Count

Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente

Count(expr)

En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.

Aunque expr puede realizar un cálculo sobre un campo, Count simplemente cuenta el número de registros sin tener en cuenta qué valores se almacenan en los registros. La función Count no cuenta los registros que tienen campos null a menos que expr sea el carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el número total de registros, incluyendo aquellos que contienen campos null. Count(*) es

��

considerablemente más rápida que Count(Campo). No se debe poner el asterisco entre dobles comillas ('*').

SELECT Count(*) AS Total FROM Pedidos;

Si expr identifica a múltiples campos, la función Count cuenta un registro sólo si al menos uno de los campos no es Null. Si todos los campos especificados son Null, no se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).

SELECT Count(Fecha & cod_con_corp) AS Total FROM Cond_Corp;

Max, Min

Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo especifico de una consulta. Su sintaxis es:

Min(expr) Max(expr)

En donde expr es el campo sobre el que se desea realizar el cálculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

StDev, StDevP

Devuelve estimaciones de la desviación estándar para la población (el total de los registros de la tabla) o una muestra de la población representada (muestra aleatoria) . Su sintaxis es:

StDev(expr) StDevP(expr)

En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)

StDevP evalúa una población, y StDev evalúa una muestra de la población. Si la consulta contiene menos de dos registros (o ningún registro para StDevP), estas funciones devuelven un valor Null (el cual indica que la desviación estándar no puede calcularse).

Sum

Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis es:

Sum(expr)

��

En donde expr respresenta el nombre del campo que contiene los datos que desean sumarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).

SELECT Sum(Peso) AS Total FROM Peso;

Var, VarP Devuelve una estimación de la varianza de una población (sobre el total de los registros) o una muestra de la población (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:

Var(expr) VarP(expr)

VarP evalúa una población, y Var evalúa una muestra de la población. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)

Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica que la varianza no puede calcularse). Puede utilizar Var y VarP en una expresión de consulta o en una Instrucción SQL.

Consultas de Acción

Las consultas de acción son aquellas que no devuelven ningún registro, son las encargadas de acciones como añadir y borrar y modificar registros.

DELETE

Crea una consulta de eliminación que elimina los registros de una o más de las tablas listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta consulta elimina los registros completos, no es posible eliminar el contenido de algún campo en concreto. Su sintaxis es:

DELETE Tabla.* FROM Tabla WHERE criterio

DELETE es especialmente útil cuando se desea eliminar varios registros. En una instrucción DELETE con múltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si especifica más de una tabla desde la que eliminar registros, todas deben ser tablas de muchos a uno. Si desea eliminar todos los registros de una tabla, eliminar la propia tabla es más eficiente que ejecutar una consulta de borrado.

Se puede utilizar DELETE para eliminar registros de una única tabla o desde varios lados de una relación uno a muchos. Las operaciones de eliminación en cascada en

��

una consulta únicamente eliminan desde varios lados de una relación. Por ejemplo, en la relación entre las tablas Clientes y Pedidos, la tabla Pedidos es la parte de muchos por lo que las operaciones en cascada solo afectaran a la tabla Pedidos. Una consulta de borrado elimina los registros completos, no únicamente los datos en campos específicos. Si desea eliminar valores en un campo especificado, crear una consulta de actualización que cambie los valores a Null.

Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la operación. Si desea saber qué registros se eliminarán, primero examine los resultados de una consulta de selección que utilice el mismo criterio y después ejecute la consulta de borrado. Mantenga copias de seguridad de sus datos en todo momento. Si elimina los registros equivocados podrá recuperarlos desde las copias de seguridad.

DELETE * FROM Tactos WHERE cod_tacto = ' 1';

INSERT INTO

Agrega un registro en una tabla. Se la conoce como una consulta de datos añadidos. Esta consulta puede ser de dos tipo: Insertar un único registro ó Insertar en una tabla los registros contenidos en otra tabla.

Para insertar un único Registro:

En este caso la sintaxis es la siguiente:

INSERT INTO Tabla (campo1, campo2, .., campoN) VALUES (valor1, valor2, ..., valorN)

Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así sucesivamente. Hay que prestar especial atención a acotar entre comillas simples (') los valores literales (cadenas de caracteres) y las fechas indicarlas en formato mm-dd-aa y entre caracteres de almohadillas (#).

Para insertar Registros de otra Tabla:

En este caso la sintaxis es:

INSERT INTO Tabla [IN base_externa] (campo1, campo2, ..., campoN) SELECT TablaOrigen.campo1, TablaOrigen.campo2, ..., TablaOrigen.campoN FROM TablaOrigen

En este caso se seleccionarán los campos 1,2, ..., n dela tabla origen y se grabarán en los campos 1,2,.., n de la Tabla. La condición SELECT puede incluir la cláusula WHERE para filtrar los registros a copiar. Si Tabla y TablaOrigen poseen la misma estrucutra podemos simplificar la sintaxis a:

INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen

De esta forma los campos de TablaOrigen se grabarán en Tabla, para realizar esta operación es necesario que todos los campos de TablaOrigen estén contenidos con

��

igual nombre en Tabla. Con otras palabras que Tabla posea todos los campos de TablaOrigen (igual nombre e igual tipo).

En este tipo de consulta hay que tener especial atención con los campos contadores o autonuméricos puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo homólogo en la tabla origen, no incrementandose como le corresponde.

Se puede utilizar la instrucción INSERT INTO para agregar un registro único a una tabla, utilizando la sintaxis de la consulta de adición de registro único tal y como se mostró anteriormente. En este caso, su código específica el nombre y el valor de cada campo del registro. Debe especificar cada uno de los campos del registro al que se le va a asignar un valor así como el valor para dicho campo. Cuando no se especifica dicho campo, se inserta el valor predeterminado o Null. Los registros se agregan al final de la tabla.

También se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra tabla o consulta utilizando la cláusula SELECT ... FROM como se mostró anteriormente en la sintaxis de la consulta de adición de múltiples registros. En este caso la cláusula SELECT especifica los campos que se van a agregar en la tabla destino especificada.

La tabla destino u origen puede especificar una tabla o una consulta.

Si la tabla destino contiene una clave principal, hay que segurarse que es única, y con valores no-Null ; si no es así, no se agregarán los registros. Si se agregan registros a una tabla con un campo Contador , no se debe incluir el campo Contador en la consulta. Se puede emplear la cláusula IN para agregar registros a una tabla en otra base de datos.

Se pueden averiguar los registros que se agregarán en la consulta ejecutando primero una consulta de selección que utilice el mismo criterio de selección y ver el resultado. Una consulta de adición copia los registros de una o más tablas en otra. Las tablas que contienen los registros que se van a agregar no se verán afectadas por la consulta de adición. En lugar de agregar registros existentes en otra tabla, se puede especificar los valores de cada campo en un nuevo registro utilizando la cláusula VALUES. Si se omite la lista de campos, la cláusula VALUES debe incluir un valor para cada campo de la tabla, de otra forma fallará INSERT.

UPDATE

Crea una consulta de actualización que cambia los valores de los campos de una tabla especificada basándose en un criterio específico. Su sintaxis es:

UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, ... CampoN=ValorN WHERE Criterio;

UPDATE es especialmente útil cuando se desea cambiar un gran número de registros o cuando éstos se encuentran en múltiples tablas. Puede cambiar varios campos a la vez.

��

UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar, hay que examinar primero el resultado de una consulta de selección que utilice el mismo criterio y después ejecutar la consulta de actualización.

Si en una consulta de actualización suprimimos la cláusula WHERE todos los registros de la tabla señalada serán actualizados.

UPDATE Peso SET Peso = Peso * 1.1

Tipos de Datos

Los tipos de datos SQL se clasifican en 13 tipos de datos primarios y de varios sinónimos válidos reconocidos por dichos tipos de datos.

Tipos de datos primarios:

Tipo de Datos Longitud Descripción

BINARY 1 byte Para consultas sobre tabla adjunta de productos de bases de datos que definen un tipo de datos Binario.

BIT 1 byte Valores Si/No ó True/False

BYTE 1 byte Un valor entero entre 0 y 255.

COUNTER 4 bytes Un número incrementado automáticamente (de tipo Long)

CURRENCY 8 bytes Un entero escalable entre 922.337.203.685.477,5808 y 922.337.203.685.477,5807.

DATETIME 8 bytes Un valor de fecha u hora entre los años 100 y 9999.

SINGLE 4 bytes Un valor en punto flotante de precisión simple con un rango de -3.402823*1038 a -1.401298*10-45 para valores negativos, 1.401298*10-45 a 3.402823*1038 para valores positivos, y 0.

DOUBLE 8 bytes

Un valor en punto flotante de doble precisión con un rango de -1.79769313486232*10308 a -4.94065645841247*10-324 para valores negativos, 4.94065645841247*10-324 a 1.79769313486232*10308 para valores positivos, y 0.

SHORT 2 bytes Un entero corto entre -32,768 y 32,767.

LONG 4 bytes Un entero largo entre -2,147,483,648 y 2,147,483,647.

LONGTEXT 1 byte por carácter De cero a un máximo de 1.2 gigabytes.

LONGBINARY Según se necesite De cero 1 gigabyte. Utilizado para objetos OLE.

TEXT 1 byte por caracter De cero a 255 caracteres.

La siguiente tabla recoge los sinonimos de los tipos de datos definidos:

��

Tipo de Dato Sinónimos

BINARY VARBINARY

BIT

BOOLEAN LOGICAL LOGICAL1 YESNO

BYTE INTEGER1

COUNTER AUTOINCREMENT

CURRENCY MONEY

DATETIME DATE TIME TIMESTAMP

SINGLE FLOAT4 IEEESINGLE REAL

DOUBLE

FLOAT FLOAT8 IEEEDOUBLE NUMBER NUMERIC

SHORT INTEGER2 SMALLINT

LONG INT INTEGER INTEGER4

LONGBINARY GENERAL OLEOBJECT

LONGTEXT LONGCHAR MEMO NOTE

TEXT

ALPHANUMERIC CHAR CHARACTER STRING VARCHAR

VARIANT (No Admitido) VALUE

SubConsultas

Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta.

Puede utilizar tres formas de sintaxis para crear una subconsulta:

��

comparación [ANY | ALL | SOME] (instrucción sql) expresión [NOT] IN (instrucción sql) [NOT] EXISTS (instrucción sql)

En donde:

comparación

Es una expresión y un operador de comparación que compara la expresión con el resultado de la subconsulta.

expresión

Es una expresión por la que se busca el conjunto resultante de la subconsulta.

instrucción sql

Es una instrucción SELECT, que sigue el mismo formato y reglas que cualquier otra instrucción SELECT. Debe ir entre paréntesis.

Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos de una instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta, se utiliza una instrucción SELECT para proporcionar un conjunto de uno o más valores especificados para evaluar en la expresión de la cláusula WHERE o HAVING.

Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para recuperar registros de la consulta principal, que satisfagan la comparación con cualquier otro registro recuperado en la subconsulta.

El predicado ALL se utiliza para recuperar únicamente aquellos registros de la consulta principal que satisfacen la comparación con todos los registros recuperados en la subconsulta.

El predicado IN se emplea para recuperar únicamente aquellos registros de la consulta principal para los que algunos registros de la subconsulta contienen un valor igual.

Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos registros de la consulta principal para los que no hay ningún registro de la subconsulta que contenga un valor igual.

El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en comparaciones de verdad/falso para determinar si la subconsulta devuelve algún registro.

Se puede utilizar también alias del nombre de la tabla en una subconsulta para referirse a tablas listadas en la cláusula FROM fuera de la subconsulta.

��

Consultas de Referencias Cruzadas

Una consulta de referencias cruzadas es aquella que nos permite visualizar los datos en filas y en columnas, estilo tabla, por ejemplo:

Categoria / Año 1996 1997

Vacas 1.250 3.000

Novillos 8.560 1.253

Terneros/as 4.369 2.563

Si tenemos una tabla de Vacunos y otra tabla de Categorias, podemos visualizar en total de Vacunos producidos por año para una categorìa determinada, tal y como se visualiza en la tabla anterior.

La sintaxis para este tipo de consulta es la siguiente:

TRANSFORM función agregada instrucción select PIVOT campo pivot [IN (valor1[, valor2[, ...]])]

En donde:

función agregada

Es una función SQL agregada que opera sobre los datos seleccionados.

instrucción select

Es una instrucción SELECT.

campo pivot

Es el campo o expresión que desea utilizar para crear las cabeceras de la columna en el resultado de la consulta.

valor1, valor2

Son valores fijos utilizados para crear las cabeceras de la columna.

Para resumir datos utilizando una consulta de referencia cruzada, se seleccionan los valores de los campos o expresiones especificadas como cabeceras de columnas de tal forma que pueden verse los datos en un formato más compacto que con una consulta de selección.

TRANSFORM es opcional pero si se incluye es la primera instrucción de una cadena SQL. Precede a la instrucción SELECT que especifica los campos utilizados como encabezados de fila y una cláusula GROUP BY que especifica el agrupamiento de las filas. Opcionalmente puede incluir otras cláusulas como por ejemplo WHERE, que especifica una selección adicional o un criterio de ordenación .

��

Los valores devueltos en campo pivot se utilizan como encabezados de columna en el resultado de la consulta. Por ejemplo, al utilizar las cifras de ventas en el mes de la venta como pivot en una consulta de referencia cruzada se crearían 12 columnas. Puede restringir el campo pivot para crear encabezados a partir de los valores fijos (valor1, valor2) listados en la cláusula opcional IN.

También puede incluir valores fijos, para los que no existen datos, para crear columnas adicionales.

Otras posibilidades de fecha de la cláusula pivot son las siguientes:

1. Para agrupamiento por Trimestres PIVOT "Tri " & DatePart("q",[Fecha]);

2. Para agrupamiento por meses (sin tener en cuenta el año) PIVOT Format([Fecha],"mmm") In ("Ene", "Feb", "Mar", "Abr", "May", "Jun", "Jul", "Ago", "Sep", "Oct", "Nov", "Dic");

3. Para agrupar por días PIVOT Format([Fecha],"Short Date");

Consultas de Unión Internas

Las vinculaciones entre tablas se realiza mediante la cláusula INNER que combina registros de dos tablas siempre que haya concordancia de valores en un campo común. Su sintaxis es:

SELECT campos FROM tb1 INNER JOIN tb2 ON tb1.campo1 comp tb2.campo2

En donde:

tb1, tb2

Son los nombres de las tablas desde las que se combinan los registros.

campo1, campo2

Son los nombres de los campos que se combinan. Si no son numéricos, los campos deben ser del mismo tipo de datos y contener el mismo tipo de datos, pero no tienen que tener el mismo nombre.

comp

Es cualquier operador de comparación relacional : =, <, >, <=, >=, o <>.

Se puede utilizar una operación INNER JOIN en cualquier cláusula FROM. Esto crea una combinación por equivalencia, conocida también como unión interna. Las combinaciones Equi son las más comunes; éstas combinan los registros de dos tablas siempre que haya concordancia de valores en un campo común a ambas tablas. Se puede utilizar INNER JOIN con las tablas Departamentos y Empleados para

��

seleccionar todos los empleados de cada departamento. Por el contrario, para seleccionar todos los departamentos (incluso si alguno de ellos no tiene ningún empleado asignado) se emplea LEFT JOIN o todos los empleados (incluso si alguno no está asignado a ningún departamento), en este caso RIGHT JOIN.

Si se intenta combinar campos que contengan datos Memo u Objeto OLE, se produce un error. Se pueden combinar dos campos numéricos cualesquiera, incluso si son de diferente tipo de datos. Por ejemplo, puede combinar un campo Numérico para el que la propiedad Size de su objeto Field está establecida como Entero, y un campo Contador.

El ejemplo siguiente muestra cómo podría combinar las tablas Categorías y Productos basándose en el campo IDCategoria:

SELECT Nombre_etapa_cria, caravana FROM vacunos INNER JOIN des_etapa_cria ON Vacunos.etapa_cria = des_etapa_cria.cod_etapa;

En el ejemplo anterior, etapa_cria es el campo combinado, pero no está incluido en la salida de la consulta ya que no está incluido en la instrucción SELECT. Para incluir el campo combinado, incluir el nombre del campo en la instrucción SELECT, en este caso, des_etapa_cria.cod_etapa.

También se pueden enlazar varias cláusulas ON en una instrucción JOIN, utilizando la sintaxis siguiente:

SELECT campos FROM tabla1 INNER JOIN tabla2 ON tb1.campo1 comp tb2.campo1 AND ON tb1.campo2 comp tb2.campo2) OR ON tb1.campo3 comp tb2.campo3)];

También puede anidar instrucciones JOIN utilizando la siguiente sintaxis:

SELECT campos FROM tb1 INNER JOIN (tb2 INNER JOIN [( ]tb3 [INNER JOIN [( ]tablax [INNER JOIN ...)] ON tb3.campo3 comp tbx.campox)] ON tb2.campo2 comp tb3.campo3) ON tb1.campo1 comp tb2.campo2;

Un LEFT JOIN o un RIGHT JOIN puede anidarse dentro de un INNER JOIN, pero un

Si empleamos la cláusula INNER en la consulta se seleccionarán sólo aquellos registros de la tabla de la que hayamos escrito a la izquierda de INNER JOIN que contengan al menos un registro de la tabla que hayamos escrito a la derecha. Para solucionar esto tenemos dos cláusulas que sustituyen a la palabra clave INNER, estas cláusulas son LEFT y RIGHT. LEFT toma todos los registros de la tabla de la izquierda aunque no tengan ningún registro en la tabla de la izquierda. RIGHT realiza la misma

��

operación pero al contrario, toma todos los registros de la tabla de la derecha aunque no tenga ningún registro en la tabla de la izquierda.

Consultas de Unión Externas

Se utiliza la operación UNION para crear una consulta de unión, combinando los resultados de dos o más consultas o tablas independientes. Su sintaxis es:

[TABLE] consulta1 UNION [ALL] [TABLE] consulta2 [UNION [ALL] [TABLE] consultan [ ... ]]

En donde:

consulta1, consulta2, consultan

Son instrucciones SELECT, el nombre de una consulta almacenada o el nombre de una tabla almacenada precedido por la palabra clave TABLE.

Puede combinar los resultados de dos o más consultas, tablas e instrucciones SELECT, en cualquier orden, en una única operación UNION.

Si no se indica lo contrario, no se devuelven registros duplicados cuando se utiliza la operación UNION, no obstante puede incluir el predicado ALL para asegurar que se devuelven todos los registros. Esto hace que la consulta se ejecute más rápidamente. Todas las consultas en una operación UNION deben pedir el mismo número de campos, no obstante los campos no tienen porqué tener el mismo tamaño o el mismo tipo de datos.

Se puede utilizar una cláusula GROUP BY y/o HAVING en cada argumento consulta para agrupar los datos devueltos. Puede utilizar una cláusula ORDER BY al final del último argumento consulta para visualizar los datos devueltos en un orden específico.

Estructuras de las Tablas

Creación de Tablas Nuevas

Si se está utilizando el motor de datos de Microsoft para acceder a bases de datos access, sólo se puede emplear esta instrucción para crear bases de datos propias de access. Su sintaxis es:

CREATE TABLE tabla (campo1 tipo (tamaño) índice1 , campo2 tipo (tamaño) índice2 , ..., índice multicampo , ... )

En donde:

��

Parte Descripción tabla Es el nombre de la tabla que se va a crear.

campo1 campo2

Es el nombre del campo o de los campos que se van a crear en la nueva tabla. La nueva tabla debe contener, al menos, un campo.

tipo Es el tipo de datos de campo en la nueva tabla. (Ver Tipos de Datos)

tamaño Es el tamaño del campo sólo se aplica para campos de tipo texto.

índice1 índice2

Es una cláusula CONSTRAINT que define el tipo de indice a crear. Esta cláusula en opcional.

índice multicampos

Es una cláusula CONSTRAINT que define el tipo de indice multicampos a crear. Un índice multi campo es aquel que está indexado por el contenido de varios campos. Esta cláusula en opcional.

CREATE TABLE Desc_caract (descripcion TEXT (25) , cod_etapa INTEGER);

Crea una nueva tabla llamada Desc_caract s con dos campos, uno llamado descripcion de tipo texto y longutid 25 y otro llamado cod_etapa de tipo entero

La cláusula CONSTRAINT

Se utiliza la cláusula CONSTRAINT en las instrucciones ALTER TABLE y CREATE TABLE para crear o eliminar índices. Existen dos sintaxis para esta cláusula dependiendo si desea Crear ó Eliminar un índice de un único campo o si se trata de un campo multiíndice. Si se utiliza el motor de datos de Microsoft, sólo podrá utilizar esta cláusula con las bases de datos propias de dicho motor.

Para los índices de campos únicos:

CONSTRAINT nombre {PRIMARY KEY | UNIQUE | REFERENCES tabla externa [(campo externo1, campo externo2)]}

Parte Descripción

nombre Es el nombre del índice que se va a crear.

primarioN Es el nombre del campo o de los campos que forman el índice primario.

únicoN Es el nombre del campo o de los campos que forman el índice de clave única.

refN Es el nombre del campo o de los campos que forman el índice externo (hacen referencia a campos de otra tabla).

tabla externa Es el nombre de la tabla que contiene el campo o los campos referenciados en ref.

campos externos

Es el nombre del campo o de los campos de la tabla externa especificados por ref1, ref2, ..., ref.

��

Si se desea crear un índice para un campo cuando se esta utilizando las instrucciones ALTER TABLE o CREATE TABLE la cláusula CONTRAINT debe aparecer inmediatamente después de la especificación del campo indexeado.

Si se desea crear un índice con múltiples campos cuando se está utilizando las instrucciones ALTER TABLE o CREATE TABLE la cláusula CONSTRAINT debe aparecer fuera de la cláusula de creación de tabla.

Tipo de Indice Descripción

UNIQUE Genera un índece de clave única. Lo que implica que los registros de la tabla no pueden contener el mismo valor en los campos indexados.

PRIMARY KEY

Genera un índice primario el campo o los campos especificados. Todos los campos de la clave principal deben ser únicos y no nulos, cada tabla sólo puede contener una única clave principal.

FOREIGN KEY

Genera un índice externo (toma como valor del índice campos contenidos en otras tablas). Si la clave principal de la tabla externa consta de más de un campo, se debe utilizar una definición de índice de múltiples campos, listando todos los campos de referencia, el nombre de la tabla externa, y los nombres de los campos referenciados en la tabla externa en el mismo orden que los campos de referencia listados. Si los campos referenciados son la clave principal de la tabla externa, no tiene que especificar los campos referenciados, predeterminado por valor, el motor Jet se comporta como si la clave principal de la tabla externa fueran los campos referenciados .

Creación de Índices

Si se utiliza el motor de datos Jet de Microsoft sólo se pueden crear índices en bases de datos del mismo motor. La sintaxis para crear un índice en ua tabla ya definida en la siguiente:

CREATE [ UNIQUE ] INDEX índice ON tabla (campo [ASC|DESC][, campo [ASC|DESC], ...]) [WITH { PRIMARY | DISALLOW NULL | IGNORE NULL }]

En donde:

Parte Descripción

índice Es el nombre del índice a crear.

tabla Es el nombre de una tabla existentes en la que se creará el índice.

campo Es el nombre del campo o lista de campos que consituyen el índice.

ASC|DESC Indica el orden de los valores de lso campos ASC indica un orden ascendente (valor predeterminado) y DESC un orden descendente.

��

UNIQUE Indica que el indice no puede contener valores duplicados.

DISALLOW NULL Prohibe valores nulos en el índice

IGNORE NULL

Excluye del índice los valores nulos incluidos en los campos que lo componen.

PRIMARY Asigna al índice la categoría de clave principal, en cada tabla sólo puede existir un único indice que sea "Clave Principal". Si un índice es clave principal implica que que no puede contener valores nulos ni duplicados.

Se puede utilizar CREATE INDEX para crear un pseudo índice sobre una tabla adjunta en una fuente de datos ODBC tal como SQL Server que no tenga todavía un índice. No se necesita permiso o tener acceso a un servidor remoto para crear un pseudo índice, además la base de datos remota no es consciente y no es afectada por el pseudo índice. Se utiliza la misma sintaxis para las tabla adjunta que para las originales. Esto es especialmente útil para crear un índice en una tabla que sería de sólo lectura debido a la falta de un índice.

CREATE INDEX MiIndice ON vacunos (nombre, procedencia);

Crea un índice llamado MiIndice en la tabla vacunos con los campos nombre y Procedencia

Modificar el Diseño de una Tabla

Modifica el diseño de una tabla ya existente, se puden modificar los campos o los índices existentes. Su sintaxis es:

ALTER TABLE tabla {ADD {COLUMN tipo de campo[(tamaño)] [CONSTRAINT índice] CONSTRAINT índice multicampo} | DROP {COLUMN campo I CONSTRAINT nombre del índice} }

En donde:

Parte Descripción

tabla Es el nombre de la tabla que se desea modificar.

campo Es el nombre del campo que se va a añadir o eliminar.

tipo Es el tipo de campo que se va a añadir.

tamaño El el tamaño del campo que se va a añadir (sólo para campos de texto).

índice Es el nombre del índice del campo (cuando se crean campos) o el nombre del índice de la tabla que se desea eliminar.

índice multicampo

Es el nombre del índice del campo multicampo (cuando se crean campos) o el nombre del índice de la tabla que se desea eliminar.

��

Operación Descripción

ADD COLUMN

Se utiliza para añadir un nuevo campo a la tabla, indicando el nombre, el tipo de campo y opcionalmente el tamaño (para campos de tipo texto).

ADD Se utliza para agregar un índice de multicampos o de un único campo.

DROP COLUMN

Se utliza para borrar un campo. Se especifica únicamente el nombre del campo.

DROP Se utiliza para eliminar un índice. Se especifica únicamente el nombre del índice a continuación de la palabra reservada CONSTRAINT.

Consultas con Parámetros

Las consultas con parámetros son aquellas cuyas condiciones de búsqueda se definen mediante parámetros. Si se ejecutan directamente desde la base de datos donde han sido definidas aparecerá un mensaje solicitando el valor de cada uno de los parámetros. Si deseamos ejecutarlas desde una aplicación hay que asignar primero el valor de los parámetros y después ejecutarlas. Su sintaxis es la siguiente:

PARAMETERS nombre1 tipo1, nombre2 tipo2, ... , nombreN tipoN Consulta

En donde:

Parte Descripción nombre Es el nombre del parámetro

tipo Es el tipo de datos del parámetro

consulta Una consulta SQL

Puede utilizar nombre pero no tipo de datos en una cláusula WHERE o HAVING.

El ejemplo siguiente muestra como utilizar los parámetros en el programa de Visual Basic:

Bases de Datos Externas

Para el acceso a bases de datos externas se utiliza la cláusula IN. Se puede acceder a base de datos dBase, Paradox o Btrieve. Esta cláusula sólo permite la conexión de una base de datos externa a la vez. Una base de datos externa es una base de datos que no sea la activa. Aunque para mejorar los rendimientos es mejor adjuntarlas a la base de datos actual y trabajar con ellas.

��

Para especificar una base de datos que no pertenece a Access Basic, se agrega un punto y coma (;) al nombre y se encierra entre comillas simples. También puede utilizar la palabra reservada DATABASE para especificar la base de datos externa. Por ejemplo, las líneas siguientes especifican la misma tabla:

FROM Tabla IN '[dBASE IV; DATABASE=C:\DBASE\DATOS\VACAS;]'; FROM Tabla IN 'C:\DBASE\DATOS\VACAS' 'dBASE IV;'

Acceso a una base de datos externa de Microsoft Access:

SELECT caravana FROM Vacunos IN e-ganadero.MDB WHERE caravana = 256

En donde e-ganadero.MDB es el nombre de una base de datos de Microsoft Access que contiene la tabla vacunos.

Omitir los Permisos de Ejecución

En entornos de bases de datos con permisos de seguridad para grupos de trabajo se puede utilizar la cláusula WITH OWNERACCESS OPTION para que el usuario actual adquiera los derechos de propietario a la hora de ejecutar la consulta. Su sintaxis es:

instrucción sql WITH OWNERACCESS OPTION

SELECT caravana, nombre, procedencia FROM vacunos ORDER BY caravana WITH OWNERACCESS OPTION;

Esta opción requiere que esté declarado el acceso al fichero de grupo de trabajo (generalmente system.mda ó system .mdw) de la base de datos actual

La Cláusula PROCEDURE

Esta cláusula es poco usual y se utiliza para crear una consulta a la misma vez que se ejecuta, opcionalmente define los parámetros de la misma. Su sintaxis es la siguiente:

PROCEDURE NombreConsulta Parámetro1 tipo1, .... , ParámetroN tipon ConsultaSQL En donde:

Parte Descripción NombreConsulta Es el nombre con se guardará la consulta en la base de datos.

Parámetro Es el nombre de parámetro o de los parámetros de dicha consulta.

tipo Es el tipo de datos del parámetro

ConsultaSQL Es la consulta que se desea grabar y ejecutar.

��

ANEXOS

Resolución de Problemas

Buscar Información duplicada en un campo de una tabla.

Para generar este tipo de consultas lo más sencillo es utilizar el asistente de consultas de Access, editar la sentencia SQL de la consulta y pegarla en nuestro código. No obstante este tipo de consulta se consigue de la siguiente forma:

SELECT DISTINCTROW Lista de Campos a Visualizar FROM Tabla WHERE CampoDeBusqueda In (SELECT CampoDeBusqueda FROM Tabla As psudónimo GROUP BY CampoDeBusqueda HAVING Count(*)>1 ) ORDER BY CampoDeBusqueda;

Un caso práctico, si deseamos localizar aquellos Vacunos con igual procedencia y visualizar su código correspondiente, la consulta sería la siguiente:

SELECT DISTINCTROW Vacunos.Procedencia, Vacunos.caravana FROM vacunos WHERE vacunos.procedencia In (SELECT procedencia FROM Vacunos As Tmp GROUP BY procedencia HAVING Count(*)>1) ORDER BY Vacunos.procedencia;

Recuperar Registros de una tabla que no contengan registros relacionados en otra.

Este tipo de consulta se emplea en situaciones tales como saber que Animales (Vacas) no han quedado preñadas en un determinado periodo de tiempo,

SELECT DISTINCTROW Vacunos.caravana, Vacunos.procedencia FROM vacunos LEFT JOIN Tactos ON Vacunos.caravana = Tactos.Caravana WHERE (Tactos.caravana Is Null) AND (tactos.Fecha Between #10-9-97# And #31-12-97#);

La sintaxis es sencilla, se trata de realizar una unión interna entre dos tablas seleccionadas mediante un LEFT JOIN, establecimiendo como condición que el campo relacionado de la segunda sea Null.

Utilizar SQL desde Visual Basic

Existen dos tipos de consultas SQL: las consultas de selección (nos devuelven datos) y las consultas de acción (aquellas que no devuelven ningún registro). Ambas pueden ser tratadas en Visual Basic pero de forma diferente.

Las consultas de selección se ejecutan recogiendo la información en un recordset previamente definido mediante la instrucción openrecordset(), por ejemplo:

Dim SQL as String Dim RS as recordset

��

SQL = "SELECT * FROM Vacunos;" Set RS=MiBaseDatos.OpenRecordSet(SQL)

Si la consula de selección se encuentra almacenada en una consulta de la base de datos:

Set RS=MiBaseDatos.OpenRecordset("MiConsulta")

Las consultas de acción, al no devolver ningún registro, no las podemos asignar a ningún recordset, en este caso la forma de ejecutarlas es mediante los métodos Execute y ExecuteSQL (para bases de datos ODBC), por ejemplo:

Dim SQL as string

SQL = "DELETE * FROM vacunos WHERE etapa_cria = '13';" MiBaseDatos.Execute SQL

Funciones de Visual Basic utilizables en una Instrucción SQL

Función Sintaxis Descripción Now Variable= Now Devuelve la fecha y la hora actual del sistema

Date Variable=Date Devuelve la fecha actual del sistema

Time Variable=Time Devuelve la hora actual del sistema

Year Variable=Year(Fecha) Devuelve los cuatro dígitos correspondientes al año de Fecha

Month Variable=Month(Fecha) Devuelve el número del mes del parámetro fecha.

Day Variable=Day(Fecha) Devuelve el número del día del mes del parámetro fecha.

Weekday Variable=Weekday(Fecha) Devuelve un número entero que representa el día de la semana del parámetro fecha.

Hour Variable=Hour(Hora) Devuelve un número entre 0 y 23 que representa la hora del parámetro Hora.

Minute Variable=Minute(Hora) Devuelve un número entre 0 y 59 que representa los minutos del parámetro hora.

Second Variable=Second(Hora) Devuelve un número entre 0 y 59 que representa los segundos del parámetro hora.

DatePart

Esta función devuelve una parte señalada de una fecha concreta. Su sintaxis es:

DatePart(Parte, Fecha, ComienzoSemana, ComienzoAño)

��

Parte representa a la porción de fecha que se desea obtener, los posibles valores son:

Valor Descripción

yyyy Año

q Trimestre

m Mes

y Día del año

d Día del mes

w Día de la semana

ww Semana del año

h Hora

m Minutos

s Segundos

ComienzoSemana indica el primer día de la semana. Los posibles valores son:

Valor Descripción 0 Utiliza el valor pode efecto del sistema

1 Domingo (Valor predeterminado)

2 Lunes

3 Martes

4 Miércoles

5 Jueves

6 Viernes

7 Sábado

ComienzoAño indica cual es la primera semana del año; los posibles valores son:

Valor Descripción 0 Valor del sistema

1 Comienza el año el 1 de enero (valor predeterminado).

2 Empieza con la semana que tenga al memos cuatro días en el nuevo año.

3 Empieza con la semana que esté contenida completamente en el nuevo año.

��

Evaluar valores antes de ejecutar la Consulta.

Dentro de una sentencia SQL podemos emplear la función iif para indicar las condiciones de búsqueda. La sintaxis de la función iif es la siguiente:

iif(Expresion,Valor1,Valor2)

En donde Expresión es la sentencia que evaluamos; si Expresión es verdadera entonces se devuelve Valor1, si Expresión es falsa se devuelve Valor2.

��

Simulación Introducción Puede definirse la simulación de un fenómeno real como el procesamiento de un modelo simulado, material o formal, que pueda someterse a manipulaciones que serian imposibles realizar, cuando no demasiado costosas e impracticas, con el sistema original. Los resultados de un procesamiento de un modelo pueden examinarse y con ello, inferirse las propiedades concernientes al comportamiento del sistema o fenómeno real que se pretende estudiar. El porque de su uso. En éste trabajo se implementó el uso de un modelo de generación de números aleatorios, que simula la medición de pesos, condiciones corporales y área pélvica de los animales registrados. La razón de utilizar ésta herramienta se debe a que fue imposible obtener datos reales medianamente estructurados, de mediciones de éstas características, lo que hace pensar que el presente trabajo no tiene precedentes en el ámbito local, o por lo menos no se han dado a conocer, o no son utilizados en nuestra zona. La finalidad del uso de datos simulados en el presente trabajo se debe a que como se mencionó los datos reales no están registrados, y éstos datos son necesarios para implementar un sistema de soporte a la toma de decisiones, es decir que el sistema desarrollado utiliza los datos simulados como si fuesen reales, ya que el usuario moldea los datos simulados mediante parámetros que condicionan los valores simulados. No obstante las utilidades desarrolladas para generar valores simulados, pueden ser usadas para realizar un planeamiento o predicción del tipo “que pasaría si”, es decir que futuro tendría el establecimiento en cuestión, si los animales tuviesen estos pesos, o estas condiciones corporales, o el área pélvica de las hembras midiese entre X cm2 y X cm2 , éstas simulaciones pueden ser ajustadas, dependiendo de variables incontrolable, como ser lluvias, sequías, enfermedades, etc. Es decir ajustar los parámetros presuponiendo que por ejemplo, para los 2 meses siguientes se pronosticó que una sequía asecharía a la región, o que aumentaría el precio de los suplementos alimenticios que son ingeridos por las hembras, para prepararlas para los próximos servicios. Por lo tanto se deben disminuir los parámetros de pesos, inferior y superior, respectivamente. O Aumentar en el caso contrario o sea cuando exista un pronóstico optimista. Metodología empleada La metodología implementada en ésta trabajo final, consiste en la construcción de una muestra artificial, mediante la utilización del Método de los Números Índice, que simule los valores de la distintas características que pueden ser simuladas, como ser Peso, Condición Corporal, y Área Pélvica, para los distintos animales que intervienen el procesos de la cría de vacunos propiamente dicha, utilizando para ello números al azar. Para la generación de estos números aleatorios se utiliza el método pseudo-aleatorio: Aditivo de Congruencias. Que genera números al azar dependiendo de valores máximos y mínimos tomados como parámetros, de la base de conocimiento del experto. Y de otros parámetros como ser las “semillas”, implícitas, tomadas arbitrariamente.

��

Teoría del método Aditivo de Congruencias: Formula que presupone dados k+1 valores enteros y positivos, iniciales, para dar origen al procedimiento. Las propiedades estadísticas de la sucesión obtenida tienden a mejorar a medida que el valor numérico de k se incrementa. Si k= 2 se deben tomar 3 valores iniciales es decir que el primer numero que se obtiene es el de orden 4. Los números que dan inicio a la serie se denominan semilla, y conviene tomarlos primos, para que la serie no sea recurrente. Descripción de la Metodología adoptada para la generación de variables aleatorias: 1. Simulación de mediciones de pesos de los animales.

Posibilidades: a) Utilizar el experto: El usuario selecciona la etapa de la cría en la que se

quiere simular el/las mediciones de peso, de la base del conocimiento se rescatan los valores máximos y mínimos de peso, según la etapa de la cría, entre estos valores se debe ejecutar la simulación. El usuario debe ingresar la fecha, que desee para que quede registrada en cada registro de la simulación. El sistema consulta todos los animales en ésta etapa de la cría, para los cuales efectuar la simulación. Se simulan los datos utilizando el método aditivo de las congruencias, con los parámetros predeterminados. Se muestran todos los pesos simulados junto con la caravana y la fecha correspondiente. Nota: el usuario podrá editar/modificar cualquier registro utilizando el módulo de ingreso y edición manual de mediciones de pesos (valores reales)

b) Obviar el experto: Ésta posibilidad se incluyó como una alternativa parra casos excepcionales, por ejemplo intervención de variables incontrolables, como ambientales, económicas, enfermedades, plagas, etc. El usuario debe ingresar en éste caso cinco parámetros;

I. La fecha que será registrada. II. Número de caravana inferior, para el grupo de animales.

III. Numero de caravana superior, para el grupo de animales. IV. Peso inferior a simular. V. Peso superior a simular.

El procedimiento sigue como en la alternativa anterior.

V(i+1) = Vi + V(i-k) (mod M)

��

2. Simulación de Condiciones Corporales.

Posibilidades: a) Seleccionar grupos de animales según intervalos de fecha de

nacimiento: El usuario debe ingresar en éste caso cinco parámetros.

I. La fecha que será registrada la condición corporal del animal. II. Fecha inferior de nacimiento del grupo de animales.

III. Fecha superior de nacimiento del grupo de animales. IV. Condición corporal inferior a simular. V. Condición corporal superior a simular.

El procedimiento de simulación es sencillo,el sistema genera una serie de numero pseudo aleatorios utilizando una función del lenguaje de programación (Random) que genera un valor menor que 1 pero mayor o igual que cero. El valor de cada simulación se obtiene de la siguiente manera: Donde Cond(x): es la condicion corporal del elemeto X de la matriz, correspondiente a la caravana X. MiUltimo es una variable entera que contiene el parámetro de condicion corporal superior ingresado por el usuario. MiPrimero es una variable entera que contiene el parámetro de condicion corporal inferior ingresado por el usuario. Y la instrucción Int; devuelve un valor numérico entero. Se muestran todos los pesos simulados junto con la caravana y la fecha correspondiente.

b) Seleccionar grupos de animales según intervalos caravana: El usuario debe cinco parámetros.

I. La fecha que será registrada la condición corporal del animal. II. Número de caravana inferior, para el grupo de animales.

III. Numero de caravana superior, para el grupo de animales. IV. Condición corporal inferior a simular. V. Condición corporal superior a simular.

El sistema selecciona todas las caravanas entre estos intervalos, y ejecuta la simulación de identica manera que la alternativa anterior.

Cond(X) = Int((MiUltimo - MiPrimero + 1) * Rnd + MiPrimero)

��

Capítulo III: Descripción de la Aplicación y Resultados

Informatización en la Producción Ganadera

Resumen:

Para evaluar la rentabilidad de una empresa es necesario registrar datos, que convenientemente analizados, brindarán la información necesaria sobre el nivel productivo alcanzado y permitirá la toma de decisiones mejor fundamentada. La producción animal de carne se determina mediante un balance anual en kilos que incluye datos sobre el inventario inicial y el final, salidas por venta, traslados y consumo en el establecimiento y entradas por compras y traslados de otra procedencia. Palabras clave: análisis de datos, recopilación de información, rentabilidad de producción de carne, producción animal Toma y valor de la información La finalidad de cualquier empresa es obtener renta. La medición de dicha renta implica, necesariamente, disponer de la información relativa al nivel productivo alcanzado, sobre la cual se asentará el análisis económico. Es decir, es necesario tener datos de producción física, de gastos e ingresos, para saber dónde se está situado en cuanto a rentabilidad. Un ejemplo: Si analizamos el nivel de información que maneja cualquier pequeña empresa comercial (un kiosco grande por ejemplo), es probable que se nos consigne que su ingreso proviene de 4 ó 5 rubros principales que aportan en forma diferencial al ingreso total. Quizá, el rubro que tenga mayor aporte a ese ingreso sea el que tiene un menor margen, pero su inclusión es el "gancho" indispensable para que ese pequeño comercio funcione. Y si requerimos acerca de los gastos, se nos informará que el 20% se lo lleva el rubro alquiler del local, el 32% el personal, el 15% los impuestos y el resto se va en reposición de mercadería. Si lo solicitamos, podremos obtener hasta un balance diario de ese negocio. Al analizar el capital invertido, vemos que sumando instalaciones, mercadería y llave de comercio, esa pequeña empresa no supera los $ 40.000, pero su porcentaje de liquidez es alto. Pasemos ahora a una empresa agropecuaria, cuyos ingresos provienen también de 4 rubros: producción de carne, maíz, soja y eventualmente cosecha fina. Si buscamos conocer el aporte de cada actividad al ingreso total, chocamos con el primer problema: es fácil saber el ingreso de las actividades agrícolas, pero al intentar saber el de la ganadería, se comienzan a confundir salidas con producción, no se recuerda con exactitud el stock de hacienda al comienzo del ejercicio, no se sabe a ciencia cierta si en ese período hubo liquidación o retención, etc. Al requerir la información de egresos, no hay certeza acerca de la distribución de esos gastos entre costos directos de cada actividad y costos de administración. Esa empresa, a diferencia de la anteriormente analizada, tiene una muy reducida liquidez,

��

con los agravantes que ello implica y un capital invertido de más de $ 500.000 para un campo mixto de 250 ha, por ejemplo. De ser ciertos estos supuestos, llegamos a la conclusión que la pequeña empresa cuyo capital total era de $ 40.000, maneja un nivel de información muy superior al del establecimiento agropecuario que tiene medio millón de dólares en juego. Hasta aquí hemos hablado de información igualándolo al concepto de datos, cuando en realidad son cosas distintas. Así como una pila de ladrillos no es una casa, un montón de datos no es información. Los datos, convenientemente analizados con la metodología que corresponde, se transforman en información, herramienta valiosa para conocer lo que pasó y en base a ese análisis proyectar hacia el futuro. Disponiendo de información suficiente y confiable, la eventualidad tendrá menor impacto en los resultados y nuestra decisión tiene mayor fundamento. Cuando la información es pobre, por escasez de datos o mala interpretación de los mismos, nuestro resultado está muy ligado al azar. Nuestra labor como asesores debe incluir una gran dedicación a motivar la toma de datos por parte del productor, que luego se transformarán en información, herramienta indispensable para la toma de decisiones. Normas para medir la producción de carne La producción anual se determina mediante un balance anual en kilos, que comprende: Diferencia entre el inventario inicial y el final. Salidas por ventas, traslados a otro destino y consumo en el establecimiento. Entradas por compras y traslados de otras procedencias. Se adopta el ejercicio comprendido entre el 1º de julio y el 30 de junio del año siguiente. Esto se debe a que en cría ya han terminado las pariciones, no comenzaron las nuevas, se han vendido los terneros y es, por lo tanto, el momento más estable y de menor cantidad de animales en el campo. El inventario final pasa a ser siempre el inicial del ejercicio siguiente, o sea que a partir del primer inventario inicial sólo deberá efectuarse una pesada general por año. La producción en kilos se calcula de la siguiente manera: Al total de salidas se debe restar el total de entradas. A ese resultado se debe sumar o restar, según corresponda, la diferencia en kilos entre inventarios. Si el inventario final arroja una existencia de kilos mayor que el inventario inicial, la diferencia de inventarios será positiva; si por el contrario, hubiera una existencia menor, la diferencia será de signo negativo y deberá ser restada. Las mortandades son producción perdida, y por lo tanto no se consideran en el cálculo de la producción (se reflejan en una menor existencia final).

��

Un gran volumen de salidas no implica necesariamente una alta producción. Si la diferencia de inventario es negativa, puede ocurrir que se esté vendiendo parte de la existencia permanente (reducción de stock). El caso inverso puede ocurrir si las salidas son reducidas porque se está reteniendo (aumento de stock). En este caso, parte de la producción real se expresará como diferencia de inventario positiva. Inventario Final (kg) - Inventario Inicial (kg) = Diferencia de Inventario (kg) Producción de carne (kg) = Salidas + Consumo - Entradas ± Diferencia de Inventario Para la medición de los inventarios inicial y final se recomienda pesar el total de la hacienda por lotes. Si los lotes son muy numerosos, se puede tomar una muestra al azar de por lo menos el 20 % de cada lote. Para asentar las entradas por compra o traslado desde otro campo, se toma el peso sin desbaste, pesando los novillos a los 3 a 7 días de su ingreso al campo (ver las técnicas de pesadas en el capítulo VII: invernada). Toda hacienda que entre al campo debe ser pesada. En el caso de salidas por ventas o traslados a otro campo, se toma el peso de destino desbastado. En el caso de ventas en el Mercado Nacional de Haciendas de Liniers, frigoríficos o remates ferias, el peso puede tomarse directamente de las liquidaciones de venta. En el caso de ventas en el campo o traslados, se pesan los animales al salir del campo, sin desbaste, restando el porcentaje promedio normal de desbaste que registra el establecimiento. Este porcentaje promedio normal surge de establecer una diferencia pesando toda la hacienda que se venda sin desbaste y comparándola con las liquidaciones de venta de mercados o remates ferias. El peso en campo sin desbaste, antes del embarque, además de establecer el porcentaje de desbaste normal, permite realizar un buen control sobre el desbaste de las operaciones de venta. Referencias: Lange, A. 1977. Carga animal. AACREA, Cuaderno de Actualización Técnica Nª 15. Torroba, J. P. 1985. Invernada. AACREA, Cuaderno de Actualización Técnica Nº 35:14-63.

��

Trazabilidad

Identificación del ganado en Argentina

Legislación actual y necesidades

La identificación de los animales y la Trazabilidad han sido materia de discusión en nuestro país en los últimos cinco años. Sin embargo a pesar de su importancia, no se han generado propuestas con la participación de todos los eslabones de la cadena productiva, participación que es necesaria en forma transparente y horizontal para alcanzar el consenso de todos los sectores involucrados. Si observamos a nuestros competidores en los mercados internacionales, veremos que es la única forma de contribuir en forma efectiva a la competitividad de nuestras carnes. Este objetivo no será posible sin el trabajo conjunto del sector público y el privado

Las necesidades crecientes en distintas áreas han determinado la puesta en vigencia de resoluciones que intentan resolver problemas en forma parcial, sin llegar a las cuestiones de fondo que las originan. El problema básico es el flujo de información en la cadena de valor de la carne que involucra a los criadores, invernadores, comercializadores, procesadores, distribuidores, exportadores y finalmente los consumidores.

La crisis que vivimos en nuestro país y la potencialidad de la cadena de valor de la carne deberían ser un llamado al sentido común para resolver el problema en forma integral en el sector ganadero, evitando introducir normativas parciales, de difícil cumplimiento y control, que finalmente aumentan los costos sin agregar valor al producto. Las cuestiones de identificación animal y los controles de los movimientos de hacienda tienen implicancias múltiples, involucrando cuestiones tanto obligatorias como voluntarias y que van desde los aspectos sanitarios y de seguridad alimentaría a la genética, de la certificación de las condiciones de producción a las buenas prácticas de manejo, de la carne con marca a la promoción integral del producto argentino, entre otras.

Los sistemas de identificación animal requieren la definición de un medio o dispositivo de identificación. Casi todos los sistemas utilizados en el mundo se basan en caravanas, con colores y especificaciones técnicas definidas, que pueden ser provistas solamente por proveedores aprobados. Una vez definido el medio de identificación y establecidas sus especificaciones técnicas ( tamaño, color, espesor, resistencia a radiación u.v., etc.) es necesario determinar qué información se incluirá en ese medio (número del establecimiento, número individual del animal, etc), información que debe quedar registrada en algún lado (registros manuales, bases de datos, etc) para permitir el control y la auditoria del sistema. Como es lógico deben existir "reglas de juego" conocidas que cubran todas las situaciones posibles, incluso aquellas con baja probabilidad de ocurrencia, para que el sistema funcione en forma coherente. Con todas estas definiciones finalmente llega el momento de asignar responsabilidades : quiénes numeran y entregan los dispositivos, quienes administran y controlan , quienes auditan y castigan en caso de ser necesario, etc.

��

Estas notas no tienen otro objetivo que describir la situación actual en la materia, intentando resaltar la necesidad del trabajo conjunto entre el sector privado y el público, con la esperanza de transitar algún día un camino de crecimiento

Seguidamente se incluyen cuatro resoluciones que involucran la identificación del ganado bovino, junto con una trascripción del artículo respectivo. Salvo el caso de la producción orgánica, que es la primera disposición legal de nuestro país sobre identificación individual (1993), las restantes han sido sancionadas en los últimos doce meses.

RESOLUCIÓN 1286/93. GANADO EN PRODUCCION ORGANICA

Art. 1° - ...Los animales provenientes de una explotación ecológica deben estar identificados en forma individual o por lotes en el caso de las aves de corral, de manera que puedan ser rastreados desde el nacimiento hasta la matanza y comercialización de sus productos y subproductos...

RESOLUCIÓN 70/01 GANADO EN ENGORDE A CORRAL

Art. 16. — Los animales ingresados a un establecimiento de engorde a corral deberán ser identificados individualmente con una caravana colocada en la oreja en el momento de su ingreso, y su registro deberá constar en la ficha de inscripción que estará en cada Oficina Local del SERVICIO NACIONAL DE SANIDAD Y CALIDAD AGROALIMENTARIA.

RESOLUCIÓN 115/02 GANADO PARA LA UNION EUROPEA

Art. 5° — Se establece la obligatoriedad de identificación de origen de los animales que no hayan nacido en el establecimiento rural habilitado para UNION EUROPEA. El sistema a utilizar debe ser de fácil auditoria y estar aprobado por este Servicio Nacional.

RESOLUCIÓN 150/02 BRUCELOSIS

Art. 8° - La identificación de todas las terneras vacunadas, será responsabilidad de los Entes Sanitarios mediante un método uniforme para cada predio, pudiéndose optar entre aquellos permanentes y fácilmente auditadles; no podrán inmovilizarse terneras vacunadas sin encontrarse previamente identificadas.

Sin pretender hacer un análisis exhaustivo, veamos un simple cuadro comparativo de las cuestiones enunciadas anteriormente.

CUADRO COMPARATIVO DE DEFINICIONES NECESARIAS

OBJETIVO Prod. Orgánica

Engorde a corral

Faena para UE

Brucelosis

Resolución Nro.

1286/93 70/01 115/02 150/02

Medio de identificación

Indefinida Caravana Indefinida Indefinida

Sistema de numeración

Indefinida Indefinida Indefinida Indefinida

Registros Indefinida Indefinida Indefinida Indefinida

��

manuales

Bases de datos


"Reglas de juego"


Entidad responsable

Certificadora Autorizada

Oficina Local SENASA

Indefinida Fundación

La comparación anterior tiene un solo objetivo, poner "manos a la obra" para llegar a un sistema coherente, con definiciones claras, transparente, auditable y uniforme para todo el sector ganadero. No es posible pensar que la producción de un mismo criador tenga sistemas distintos por el sexo del ternero, o que la producción de un invernador reciba distinto tratamiento según el manejo o el mercado de destino.

La aplicación de "parches" solamente sirve para resolver una emergencia, pero la aplicación de "parches" sobre "parches" lo único que hace es aumentar los costos sin resolver finalmente nada. Extraiga el lector sus propias conclusiones.

Daniel Musi Asesor de SRA

La situación en Argentina y en el mundo

La Unión Europea en su reglamento 820/97 del 21 de abril de 1997 fija la obligatoriedad de implementar un sistema de Trazabilidad en los vacunos, su carne y subproductos, para su mercado interno y sus proveedores internacionales, fue así como algunos exportadores argentinos "compraron" rápidamente la idea para estar a tono con sus clientes. Pero no es sencillo andar tras el rastro de un producto, haciendo el seguimiento de los animales (mediante identificación y registro) desde el campo hasta el frigorífico y luego de los cortes hasta el supermercado y el consumidor, con la correspondiente etiqueta que identifique su origen. En la Argentina, sumarse a un sistema de este tipo implicaría un costo adicional para los productores y aún muchos lo viven como una imposición europea. Pero si consideramos la necesidad de garantizar las exportaciones a la Comunidad Europea, y poder darle un valor agregado, a pesar de estar transitando un camino tan sinuoso como novedoso se puede transformar a la carne en un producto donde la denominación de origen y la calidad sean consideradas especiales

La identificación del ganado y la carne, de todas formas, es una herramienta comercial para algunos que exportan a la UE. Aseguran, también, que la UE otorga beneficios. Dicen que Holanda es un buen ejemplo: premia con un plus del

��

5 al 15% a los cortes que van con la "ruta" marcada. A principios del 2000 las carnes provenientes de nuestro país llevaban solamente la denominación AAA, pasando por alto los malos recuerdos, significa A de vacunos provenientes de Argentina, A de criados en Argentina y A de faenados en nuestro país. Sin embargo las cosas cambian y los problemas sanitarios asechan. Para la Argentina significaría una inversión inicial de 100 millones de dólares y 25 millones más por año. El Gobierno quiere que los pongan los productores y los productores quieren que se haga cargo el Gobierno. Estos últimos miran a Europa: allá se encara la Trazabilidad con fondos oficiales ¿Por qué invertir en Trazabilidad?

1. Brindar seguridad al consumidor, asegurar los mercados ya existentes e introducirnos en los nuevos mercados que por temores a no poder canalizar y controlar enfermedades y erradicación de las mismas han dejado de comprar carne.

2. Lograr una mayor competitividad, agregando a la carne Argentina un valor agregado.

3. Minimizar las perdidas ocasionadas por los problemas sanitarios. Por año se pierden aproximadamente entre 140/150 millones de pesos, por problemas sanitarios reflejados en el manejo, llamados abortos, terneros más chicos y hasta un menor numero de ellos.

4. Registrar la propiedad del bien, con los consiguientes beneficios frente a reclamos por hurtos, posibilidad de utilizarlo como garantía crediticias, etc.

5. Para el fisco por su parte constituye una herramienta adecuada para el seguimiento comercial potenciando la erradicación de la faena clandestina.

6. Permite un contralor de la introducción de animales ingresados al país en forma ilegal, complementando la labor sanitaria de los organismos pertinentes

En España existe un sistema que, una vez comprado el producto el consumidor puede ingresar a Internet a través del número que individualiza al corte de carne vacuna y leer la siguiente información:

Ejemplo:

��

��

��

�� ! ��"##$��

%��& ��'()��*�+��*,+��- ��)��.//�$.,��

��0��%��#.��.�$1��

��,��*��0��2,��*��%�3��%��%��4��*��5��6$ #""��

��

3�2��

��%)�7�� ) ��

�� 8��! �"###��

��

Formas de identificación de los bovinos

Básicamente existen tres formas de obtener la información necesaria requerida para la trazabilidad: las clásicas caravanas, el microchip y el bolo de identificación. En cuanto al microchip podemos decir que es pequeñísimo y tiene un número de identificación programado dentro de el y esta encapsulado con un material biocompatible, caben aproximadamente 7 en una aguja hipodérmica y puede ser inyectado bajo la piel de los animales. El peso de una marca del mercado es de entre 0,06 a 025 gramos. Por otro lado el bolo de identificación se compone de un circuito integrado, bovina y condensador herméticamente sellados en una cápsula de cerámica biocompatible. Se aloja en el retículo del animal, peso 68 gramos y una vez faenado es recuperable y su duración es de 75 años. Cuando leamos o escuchemos hablar sobre este tema, no nos olvidemos que hay dos aspectos importantísimos a considerar, por un lado lo que hasta ahora estuvimos desarrollando que es acerca de cómo inciden estas cuestiones en la economía tanto personal como en la de nuestro país, y por el otro lado la salud.

Fuente: http://www.agroconnection.com

��

Resultados

Proyecto��

�� !��!��"�#�!��

Introducción: Este documento explica, las utilidades incluidas en el Trabajo Final de Aplicación “Toma de Decisiones”, para el proyecto “e-ganadero”. Se ha adoptado denominarlo proyecto a la aplicación, por la obvias razones de seguir implementado herramientas no solo de uso gerencial, como los Sistemas de Soporte a la Decisión o Sistemas Expertos, sino también herramientas de Gestión Operativas, a medida que se siguen realizando investigaciones en éste amplio campo de aplicación informática que es la Producción Ganadera, basada en la Trazabilidad. Las futuras implementaciones están fundamentadas en el capítulo correspondiente a Futuras Implementaciones, valga la redundancia. Ya se han explicado oportunamente las definiciones y metodologías de los temas citados en éste capítulo como ser; Sistemas Expertos, Sistemas de Soporte a la Decisión, Inteligencia Artificial, Trazabilidad, etc. Por lo tanto no se sobrará en éstos temas.

��

Inicio de la Aplicación. Cuando la aplicación inicia muestra la siguiente imagen a modo de bienvenida.

��

Autentificación de Usuario. Descripción: Para brindar seguridad a la aplicación, el sistema cuenta con dos niveles de usuarios.

1. Admin.: (Administrador), éste usuario no tiene restricciones de uso del sistema, es decir éste nivel de usuario está pensado tanto para productores como para profesionales (ingenieros, veterinarios, productores, etc.).

Para iniciar una sesión en modo Admin, se debe seleccionar éste usuario desde el cuadro, e introducir la palabra clave correspondiente. Luego presionar Aceptar. 2. Invitado; éste usuario está limitado a realizar operaciones de consulta y de

simulación u obtener Soporte a la Decisión, en casi todos los módulos de de la aplicación, pero no puede agregar o modificar registros de la base de datos.

Para iniciar una sesión en modo Invitado, seleccione desde el cuadro el usuario Invitado y luego presione Aceptar. O simplemente presione Cancelar y la aplicación iniciara la sesión en modo Invitado.

Metodología: Cuando la aplicación inicia por primer vez en un ordenador, edita la configuración del registro del sistema operativo en el que se ejecuta (ambiente Windows de 32 bits), agrega las nuevas claves con los nombres de usuario y la contraseña del usuario Admin. Para brindar un nivel más de seguridad, estas claves no se pueden modificar desde la aplicación. Es decir que la aplicación inicia una sesión en modo Admin. con la única palabra clave otorgada por el autor de la aplicación. No obstante, si la base de datos ha sido resguardada, pueden hacerse modificaciones en la misma, luego de resguardar los datos, realizando una restauración de la base de datos, luego, en caso de que se haya cometido algún error operativo, o simplemente se desea desechar los cambios realizados. Esto brinda un nivel más de seguridad a la aplicación. Las utilidades y modos de operación de, Resguardo y Restauración de datos serán explicadas en el capítulo correspondiente. La siguiente figura muestra la apariencia de la interfaz de la autentificación de usuario.

��

Pantalla o Menú Principal. La ubicación de los menús fueron distribuidas conforme a las distintas utilidades del sistema, así primero se ubican las utilidades de administración de la aplicación; como ser Backup, Restauración, (no están disponibles en modo Invitado) y Cambiar de usuario. Luego se ubican las utilidades de Gestión operativas (algunas no están implementadas), y mas a la izquierda las utilidades de nivel Gerencial o de Soporte a la Decisión.

��

Cambio de Sesión. En cualquier momento se puede cambiar de sesión en la aplicación. Se accede a ésta utilidad desplegando el menú archivo y haciendo clic en Cambiar de Sesión. Una vez seleccionado el usuario, ingresar la contraseña en caso de usuario Admin. y luego presionar Entrar. La siguiente figura muestra la apariencia de la interfaz Cambiar Usuario.

La aplicación cambia de configuración.

��

Copia de Seguridad de la Base de Datos. Cuando se utiliza ésta herramienta administrativa de la aplicación, se guarda la configuración del backup de la base de datos, esto es ruta del archivo backup, y fecha de backup, en el registro del sistema operativo. Los pasos a seguir son:

1. Seleccionar el destino del archivo de backup. 2. Presionar el botón con la imagen de un disco.

La utilidad muerta los papeles volando, al estilo de Windows, hasta que la copia de seguridad haya concluido. Prevéngase de realizar otra operación mientras se ejecuta el backup de la base de datos. La siguiente figura muestra la apariencia de la interfaz de backup de base de datos.

Nota: Realice el resguardo de sus datos, cada vez que haya realizado una importante modificación en la base de datos.

��

Restauración de la Base de Datos. Si se ha realizado previamente un resguardo de la base de datos, la misma puede ser restaurada, con ésta utilidad. La metodología es totalmente estructurara, se rescata la configuración del backup de la base de datos, esto es ubicación del archivo, y la fecha del backup, si estos datos son correctos la restauración se efectúa, de lo contrario se informa de la situación conforme se haya encontrado algún inconveniente. Los pasos a seguir son:

1. Presione el botón restaurar 2. Lego confirme la acción.

Se muestran unos papeles volando al estilo de Windows hasta que la restauración se efectúe. La siguiente figura muestra la apariencia de la interfaz de Restauración de la base de datos, junto con el mensaje de confirmación.

��

Alta y Modificaciones de Vacunos. A pesar de que ésta utilidad está calificada como una herramienta de Gestión Operativa, cabe destacar que en algunas situación se utilizan técnicas de Sistemas Expertos, que serán explicados oportunamente. Movimiento de Vacunos provenientes de otros establecimientos. Escenario: En éste modulo se agregan y editan registros de animales que han sido adquiridos desde otros productores. Razón de ser de la disgregación del modulo: Para no complicar la operatividad de la aplicación, ya que existen diferencias de atributos entre los animales que provienen de otros establecimientos y los de origen local, se decidió separar en dos módulos los procesos de carga y modificación de datos de animales.

• Alta de vacunos: A la izquierda de la ventana del módulo; movimientos de vacunos provenientes de otros establecimientos, haciendo clic en opción “Dar de alta a un animal”, se visualizará un marco que presenta los controles donde se deben introducir los datos del nuevo animal adquirido, automáticamente �� , genera un número secuencial mayor que el número (caravana) del último animal que fue registrado en la base de datos. Ver próxima figura. Luego de ingresar cada dato, presione la tecla Enter, para validar el ingreso del dato. Los datos que pueden ingresarse son:

1. Etapa de la Cría: Etapa de cría o categoría actual del animal. 2. Raza: El tipo racial del animal. 3. Fecha de Nacimiento: Si no se conoce ingrese una fecha estimativa. 4. Nombre: si no quiere asignar un nombre ingrese “S/N” 5. Procedencia: El lugar geográfico de procedencia del animal, por ejemplo un

nombre de una provincia, pueblo, ciudad, etc. 6. La marca del Ultimo Propietario: Seleccione del cuadro alguna marca, si no

posee ninguna, seleccione “Sin Dato” 7. Si el animal posee una contra marca o no.

Luego de ingresar todos los datos, presione el botón “Aceptar” si desea agregar el nuevo registro del animal. O presione cancelar, en caso contrario. Nota: Para asignar una marca anterior, debe haber registrado y dibujado esa marca con la utilidad “Movimiento de Marcas de Otros Propietarios” La siguiente figura muestra la apariencia de la interfaz Movimiento de vacunos proveniente de otros establecimientos

��

• Modificar Datos de un Animal. Para modificar los datos de un animal, haga clic en la opción “Modificar Datos de un Animal”, y a continuación ingrese en el cuadro “Caravana”, la caravana del animal en cuestión. Podrá modificar todos los datos excepto, la caravana del animal. Ya que éste es un número de identificación única del animal, y todos los demás datos están relacionados por éste atributo. Nota: tenga cuidado cuando modifique, especialmente, la etapa de la cría y la fecha de nacimiento del animal. La siguiente figura muestra la apariencia de la interfaz, “Movimientos de vacunos procedentes de otros establecimientos”, con la opción; “Modificaciones”

��

Movimiento de Registros de Animales de Origen Local Escenario: Con ésta utilidad se pueden dar de alta y modificar registros de vacunos de origen local, en otros palabras realizar movimientos de animales nacidos en el establecimiento loca. Razón de ser: Retomando la explicación anterior del porque la disgregación de los módulos de movimientos de animales; una de las causas por las cuales se ha optado por separarlos fue el hecho de brindar al productor la posibilidad de ingresar la caravana de la madre del animal, y la caravana o el nombre del padre del animal. Se ha hecho la diferencia de poder agregar el nombre del animal, porque puede darse la posibilidad de que el animal haya sido gestado por Inseminación Artificial (I.A.), y que el toro proveedor del semen no esté registrado en la base de datos del establecimiento. Contrariamente a esto, es imprescindible que la madre del animal esté registrada en la base de datos del establecimiento. Esta utilidad da la posibilidad de implementar a futuro, procesamiento de los datos para obtener estadísticas de evolución racial en el establecimiento, para conocer el “Árbol Genealógico” del animal. Estudiar comportamiento de los genes de los animales, etc. Pasos a seguir: La diferencia operativa de éste módulo, respecto al de movimiento de vacunos provenientes de otros establecimientos, reside en que en éste módulo no se ingresan la procedencia, ni la marca anterior. Pero deben ingresarse la caravana de la madre y la caravana o nombre del padre. – Para ésta situación aplicativa, solo se pueden ingresar caravanas o nombres registrados en la base de datos, de modo que si el animal ha nacido por Inseminación Artificial, se recomienda primero registrar al toro proveedor del semen, especificando en la procedencia o marca anterior o nombre, alguna observación explicativa. De todos modos �� informa en el caso de que deba registrar al toro padre del animal – La figura muestra la apariencia de la interfaz, “Movimientos de vacunos de origen local”

��

Registro de Características Fenotípicas. Ésta herramienta es particularmente útil, porque al igual que el peso y la condición corporal, de los animales, las características fenotípicas condicionan la permanencia de un animal en el plantel, si estos datos son oportunamente registrados, después se pueden utilizar herramientas de toma de decisiones para descartar animales o para enviarlos a servicio. Escenario: Con ésta utilidad, el productor podrá registrar las características fenotipicas de los animales en etapa de reproducción. Tanto para Machos como para Hembras. Pasos a seguir: En el menú principal, despliegue el menú; vacunos y luego haga clic en el submenú “Caract. Feno”. En el cuadro caravana; ingrese la caravana del animal en cuestión. Según la etapa de la cría del animal, se podrán seleccionar distintos tipos de características fenotípicas. Aquí también actúa el experto, ya que el la aplicación debe diferenciar entre las distintas características para presentar las características fenotipicas correspondientes a esa etapa de la cría. Puede apreciarse que en una misma fila de las posibles características fenotipicas se encuentran las dos opciones a ingresar, siempre, en la columna de la derecha estarán las características de tipo fértil, y en la otra columna las características de tipo infértil. Seleccione una sola característica de la misma fila. Nota: Para poder ingresar los datos de características fenotipicas de un animal, primero debe ingresar o simular un peso y una condición corporal del animal. La siguiente figura muestra la apariencia de la interfaz “Movimiento de Características Fenotípicas” para la etapa de la Cría “Vaquilla de Reposición de 2-3 años”

��

La siguiente figura muestra la apariencia de la interfaz “Movimiento de Características Fenotípicas” para las etapas de Cría “Vaquilla de Primer servicio”, también esta interfaz es apta para las siguientes etapas; “Vaca Mayor”, “Vaca de Segundo Servicio”, “Vaca CUT”, y “Vaca de Invernada”.

La siguiente figura muestra la apariencia de la interfaz “Movimiento de Características Fenotípicas” para la etapa de la Cría “Toro” y “Torito”

��

Si a éste animal se le asignaron anteriormente características fenotipicas, se pueden ver las misma presionando el botón “Caract. Anteriores” Luego de seleccionar las distintas características fenotipicas. Presione el botón Guardar si desea registrar las características seleccionadas. Luego �� , informa la cantidad de características agregadas. Cada característica fenotipica, de tipo fértil, tiene asignada un porcentaje de eficiencia reproductiva, así las características fenotipicas tiene asignado una cantidad cero. Esto es transparente para el usuario, y se usan estos porcentajes al momento de apoyar a la toma de decisiones (cuando se seleccionan animales). Nota: los botones pequeños que tienen la imagen de una varita mágica, tendrán utilidad a futuro, en futuras implementaciones, para acudir al experto de edades y de pesos.

��

Alta y Modificaciones de Registros de Pesos. Escenario: Con ésta herramienta el usuario puede registrar y modificar mediciones de pesos de vacunos, junto con la fecha de medición y alguna observación si fuese necesaria. Razón de ser de ésta Utilidad: Las razones salen a la luz, registrar los pesos de los animales implica conocer el capital con que se cuenta en el establecimiento, la evolución o involución en algunas etapas de la cría, y se aclara que “en algunas” ya que, en cría y recría solo se registra el peso de los animales que están en la etapa de Ternero/as, novillos, novillitos, vaquillas o vaquillonas, ya que para tomar decisiones de elección del plantel estos datos son imprescindibles. No obstante la medición de los pesos no está demás en otras etapas, solo que los productores lo hacen en las etapas mencionadas por una cuestión de costos. Par otras etapas utilizan la condición corporal como parámetro más significativo. Además registrar el peso de los vacunos, permite obtener informes de la rentabilidad del negocio, para ciertas estrategias. Obtener estadísticas maestrales y poblacionales. Y por que no a largo plazo llegar a poder predecir el inventario de peso para alguna estación o situación. (Futuras implementaciones). Alta de mediciones de pesos: Pasos a seguir: Haga clic en la opción Registrar el peso de un Vacuno, y a continuación ingrese la caravana del animal en cuestión, en el cuadro caravana, �� informa el último peso registrado junto con la fecha de la medición del peso. Ingrese el peso medido junto con la fecha, y la observación (opcional). Lego haga clic en el botón aceptar para guardar el registro. Modificaciones de Registros de pesos: Pasos a seguir: Haga clic en la opción “Editar el peso de un vacuno”, y luego ingrese, en el cuadro caravana, la caravana del animal. �� muestra el último peso del animal, y un botón con flecha hacia atrás y adelante, en el caso de que existan mas de un registro de peso, para que el productor elija cual peso editar. Modifique en el registro correspondiente los datos que crea conveniente. A continuación presione el botón Aceptar.

��

La siguiente figura muestra la apariencia de la interfaz “Registro de pesos de vacunos”, con la utilidad de “Edición”

��

Movimientos de Marcas.

Escenario: Con ésta herramienta, el productor podrá registrar con nombres y dibujo, tanto marcas propias como de otros productores. Para poder luego tener otra alternativa de identificación de sus animales, o al momento de efectuar una venta contar con un informe del animal, junto con el la imagen de la marca actual y la anterior, en el caso de que el animal haya sido adquirido de otro establecimiento. Razón de ser de ésta utilidad: En algunas situaciones, en un establecimiento ganadero se agrupan a los animales según alguna marca, que podría ser de propiedad o de manejo del rodeo. Para el caso de propiedad, supongamos el caso de que un establecimiento pertenece a varios dueños, o más de uno, cada dueño tiene una marca de propiedad distinta, y distingue a sus animales con esa marca; por eso es importante registra esa marcación del animal en la base de datos del establecimiento. Por otro lado, también es importante registrar la marca anterior de los animales adquiridos desde otros establecimientos, ya que al momento de la venta, en la guía (ficha del animal), debe quedar registrado el dibujo de esa marca, y si posee contra marca o no, para no tener complicaciones de propiedad del animal en el futuro. Por lo tanto si el productor registra éste dato, cada animal adquirido tendrá asociada una marca anterior, la de su dueño anterior, y la marca actual, la del dueño actual. Que sumada a la Trazabilidad brinda al productor un mayor control del negocio. Pasos a seguir: Pulse el botón Agregar para agregar una nueva marca, o ingrese el código de la marca que desea editar y a continuación presione la tecla Enter, y luego el botón Editar. Complete los datos de nombre de la marca y del propietario, presionando Enter después de entrar cada dato. Luego con la herramienta Lápiz dibuje la marca en cuestión. Puede utilizar la herramienta Borrador para modificar el dibujo, y la herramienta Tamaño, para aumentar o disminuir el trazo del Lápiz. Luego de Completar éstos requerimientos pulse el botón Aceptar, para guardar la imagen, o modificar la imagen anterior. La siguiente figura muestra la apariencia de la interfaz “Movimientos de marcas de otros propietarios”, con la utilidad Edición. Una interfaz análoga se tiene con la utilidad “Movimiento de marcas locales”

��

Asignar o cambiar la Fotografía de un animal. Escenario: Mediante la utilización de ésta herramienta, el productor podrá asociar a cada caravana, la fotografía del animal. Para esto el archivo de imagen debe estar guardado en algún medio de almacenamiento accesible por el ordenador donde se ejecuta la aplicación. Razón de ser de ésta utilidad: Es razonable pensar que no todos los animales de un establecimiento contarán con una fotografía, por razones de costo y tiempo que ello demanda. Imaginemos que un establecimiento cuenta con un plantel de 2000 animales, sería muy laborioso tomar una fotografía a cada uno de los 2000 vacunos. Pero en muchas situaciones, ya sea para promociones o simplemente contar con una referencia más del animal, se podrían tomar fotografías de los Toros, animales que serán destinados a venta, etc. En caso de que la aplicación sea utilizada por alguna cabaña, el hecho de contar con un informe detallado del historial de algún animal, junto con su fotografía actualizada, puede resultar muy competitivo a la hora de promocionar su producción, enviando por ejemplo éste informe por correo electrónico o publicándolo en un sitio de Internet, o simplemente imprimirlo para publicidad, etc. Pasos a seguir: Acceda a ésta utilidad desde el menú principal, haciendo clic en “Fotos de Vacunos”. Cuando se activa el formulario ingrese la caravana a la cual se va a asignar una foto. Si el animal ya cuenta con alguna fotografía, la aplicación brinda la posibilidad de cambiar esa foto. La aplicación guarda la imagen seleccionada en la base de datos en formato de Binario Largos, es decir luego de guardar la fotografía del animal, puede eliminar el archivo ya que éste queda almacenado en la base de datos. La siguiente figura muestra la apariencia de la interfaz de la utilidad “Registro de Fotos de vacunos”.

��

Herramientas de Soporte a la Decisión Simulación:

I. Simulación de mediciones de pesos de los animales.

Escenario: La simulación de pesos de los animales, puede ser realizada de dos manera, utilizando un experto, o ingresando los parámetros de pesos máximos y mínimos, entre los cuales se efectuará la simulación.

Posibilidades y pasos a seguir: c) Utilizar el experto: El usuario selecciona la etapa de la cría en la que se

quiere simular el/las mediciones de peso, de la base del conocimiento se rescatan los valores máximos y mínimos de peso, según la etapa de la cría, entre estos valores se debe ejecutar la simulación.

El usuario debe ingresar la fecha, que desee para que quede registrada en cada registro de la simulación. Una vez completado los datos solicitados se debe pulsar el botón “Ejecutar Simulación”. Se simulan los datos utilizando el método aditivo de las congruencias, con los parámetros predeterminados. La aplicación consulta todos los animales en ésta etapa de la cría, para los cuales efectuar la simulación. Para ver los valores simulados, para cada caravana, junto con la fecha de simulación. Presionar el botón que se encuentra en el extremo izquierdo del formulario.

��

Los parámetros de pesos de las distintas etapas de la cría pueden ser modificados, solo por un experto, en la base del conocimiento. Se muestran todos los pesos simulados junto con la caravana y la fecha correspondiente.

El paso siguiente es guardar los datos simulados, presionando el gotón Guardar.

Nota: el usuario podrá editar/modificar cualquier registro utilizando el módulo de ingreso y edición manual de mediciones de pesos (valores reales)

d) Obviar el experto: Ésta posibilidad se incluyó como una alternativa para casos excepcionales, por ejemplo intervención de variables

��

incontrolables, como ambientales, económicas, enfermedades, plagas, etc. El usuario debe ingresar en éste caso cinco parámetros;

I. La fecha que será registrada. II. Número de caravana inferior, para el grupo de animales.

III. Numero de caravana superior, para el grupo de animales. IV. Peso inferior a simular. V. Peso superior a simular.

El procedimiento sigue como en la alternativa anterior.

2. Simulación de Condiciones Corporales.

Escenario: La simulación de condiciones corporales de los animales, puede ser realizada de dos manera, seleccionando para la simulación grupos de animales según fecha de nacimiento; se incluyó esta opción por que en manejo de ganado de Cría, un buen criterio para agrupar animales es la fecha o año de nacimiento. Algunas veces los productores denominan a ésta característica; “Carimbo”, señalando a los animales con un número que indica el año de nacimiento del animal, esto es conveniente en el caso de que se efectúe un solo servicio por año. La otra posibilidad de simulación es por intervalos de de caravanas, se puede observar que mediante ésta utilidad se pueden registrar condiciones corporales reales, utilizando como parámetros máximos y mínimos de caravanas el mismo número, y también los mismos números para intervalos de condiciones corporales.

Posibilidades y pasos a seguir: a) Seleccionar grupos de animales según intervalos de fecha de

nacimiento:

��

El usuario debe ingresar en éste caso cinco parámetros. i. La fecha que será registrada la condición corporal del

animal. ii. Fecha inferior de nacimiento del grupo de animales. iii. Fecha superior de nacimiento del grupo de animales. iv. Condición corporal inferior a simular. v. Condición corporal superior a simular.

El procedimiento de simulación es sencillo,el sistema genera una serie de numero pseudo aleatorios utilizando una función del lenguaje de programación (Random) que genera un valor menor que 1 pero mayor o igual que cero. El valor de cada simulación se obtiene de la siguiente manera: Donde Cond(x): es la condición corporal del elemento X de la matriz, correspondiente a la caravana X. MiUltimo es una variable entera que contiene el parámetro de condición corporal superior ingresado por el usuario. MiPrimero es una variable entera que contiene el parámetro de condición corporal inferior ingresado por el usuario. Y la instrucción Int; devuelve un valor numérico entero. Se muestran todos los pesos simulados junto con la caravana y la fecha correspondiente.

b) Seleccionar grupos de animales según intervalos caravana: El usuario debe ingresar cinco parámetros.

i. La fecha que será registrada la condición corporal del animal.

ii. Número de caravana inferior, para el grupo de animales. iii. Numero de caravana superior, para el grupo de animales. iv. Condición corporal inferior a simular. v. Condición corporal superior a simular.

Cond(X) = Int((MiUltimo - MiPrimero + 1) * Rnd + MiPrimero)

��

El sistema selecciona todas las caravanas entre estos intervalos, y ejecuta la simulación de idéntica manera que la alternativa anterior.

��

Estrategias de “Soporte a la Decisión”, aplicadas a la selección de animales para Servicios, basadas en políticas de producción. Escenario: Con ésta importante utilidad, los productores tienen la posibilidad de utilizar un experto para apoyarlos en la decisión acerca de que animales están aptos para el servicio. Generalmente, en los establecimientos de cría y recría, solo se efectúa un servicio, natural o artificial, en el año. Es conveniente realizar el servicio la primavera, por razones climáticas y de estado de los animales.

Situaciones estudiadas. I. Dar apoyo en la toma de decisiones cuando las vacas tienen mala performance,

esto es cuando el animal no está rindiendo lo suficiente en cuanto a la reproducción propiamente dicha. El productor debería recibir apoyo en la decisión acerca de cuando una vaca o un grupo de vacas deben venderse, faenarse, etc. En pocas palabras el usuario desea que el sistema periódicamente le informe de las vacas que no cumplen con las condiciones de seguir perteneciendo a su establecimiento. Éste tipo de decisión es importante por el simple hecho de que una animal que no representa ningún rédito para el establecimiento debe ser dado de baja, ya que si sigue en el establecimiento, implica gastos; de personal, de productos sanitarios, consume alimentos (pastos del campo), y otros gastos de carácter administrativo. Para tomar ésta decisión, el productor muchas veces necesita del asesoramiento de un experto, el experto recaba datos de observaciones realizadas a las vacas, evalúa esos datos, junto con otros datos propios del animal y le informa al productor cuales de sus vacas no se ajustan a los requerimientos o estrategia empleada en la cría de los vacunos. Existen varias causas por las cuales una vaca no debe seguir en el establecimiento, éstas son.

1. Edad (medio diente). 2. Vacas con bajas preformase productivas:

I. Primera Causa (vacas salteadoras). a) Con el primer servicio (año 1) la vaca queda preñada y desteta un

ternero. b) En el segundo servicio (año2) la vaca está vacía. c) En el tercer servicio (año 3) la vaca vuelve a preñarse y destetar un

ternero. d) Y así sucesivamente o Decisión o Consecuencia: Si el porcentaje de destete está por debajo

del 50 %, generalmente ésta vaca sigue en el proceso productivo. En cambio si el porcentaje de destete, es superior al 50 % lo conveniente es eliminar ésta categoría de vacas.

II. Segunda Causa. a) Que la vaca no produzca ningún ternero en dos años sucesivos. o Decisión o consecuencia: la vaca debería ser dada de baja.

• Posibles causas que hacen que las vacas tengan bajas preformase productivas:

I. Problemas sanitarios

��

II. Abortos III. Perdidas de ternero (poca habilidad materna, no desteta el ternero) IV. Pezones de gran tamaño. (caract. Fenotipicas)

II. Una situación similar al primer problema, con características parecidas, pero de

otro contexto, o influyentes en otra categoría de animales, son las decisiones que se deben tomar cuando se presentan anomalías en los animales que pertenecen a la categoría “Vaquillonas”. Él seguimiento de los comportamientos de los animales que pertenecen a ésta categoría, es un proceso importante en la cría de vacunos. Ya que las vaquillas del establecimiento son las futuras reproductoras, y por lo tanto es imprescindible conocer los problemas que pueden padecer o que padecen. Ya que si se toman decisiones erróneas, el futuro del establecimiento estaría en serios problemas. Por ejemplo que pasaría si, aunque el productor registre todos los datos de sus animales, observaciones, estados, etc., pero en el momento de tomar una decisión, por ejemplo que nuevo plan sanitario implementar, cuales vaquillas deben ser dadas de baja porque presentan una perspectiva desfavorable, no se cuenta con los conocimientos como para tomar una decisión adecuada. Y si estas decisiones tienen sus consecuencias a mediano y largo plazo, influyen en las estrategias y en el planeamiento productivo del establecimiento. Criterios para la selección de Vaquillas: 1. Edad y Peso Vivo:

• Edad: de acuerdo a la fecha de nacimiento del animal, una función calcula su edad, cada vez que se haga una consulta. En nuestra zona las vaquillas alcanzan su peso de entore entre el año y medio a tres años de edad.

• Peso Vivo: el peso de las vaquillas se amacena en la tabla Pesos, juntamente con la fecha en que se midió el peso del animal. Considerando solamente el peso de la vaquilla, ésta está apta para el entore cuando su peso es mayor a las 2/3 parte de su peso final. Si las vacas adultas pesan 400 kilos, en promedio, el peso mínimo de entore de las vaquillas debe ser 270 kilos.

2. Características Fenotípicas: • Tienen que ver con la raza o tipo racial, registrar las observaciones.

3. Examen ginecológico preservicio:

• Desarrollo Genital: se registran el la tabla tacto las posibles patologías (problemas en los genitales.)

• Preñez por robo: En la tabla tactos se registra ésta anomalía. • Área pélvica: En la tabla área pélvica se registra ésta observación tomando

el ancho y el largo de la pelvis, una función calcula el área. El resultado estará asociado a una acotación que informa de si la vaquilla está apta para la reproducción según ésta característica, que se observa mediante el tacto.

• Si la hembra está ciclando

4. Eficiencia funcional: se registran las Características fenotípicas del animal

��

Criterios para la selección de Machos (Padres/Toros)

1. Características: • En los corrales: Donde se observa el aspecto general. desplazamiento.

estado nutricional. adaptación al ambiente, Caracteres secundarios y conformación, características fenotípicas del animal

• En la casilla de operar: las diferentes observaciones (características fenotipicas) o Bloqueo o Ojos o Genitales externos o Tono o consistencia testicular o Prueba de la capacidad del servicio o Genitales internos o Examen sanitario, sanguíneo, etc. o Posible enfermedades que asechan a los machos; brucelosis,

tuberculosis, trichomoniasis, campylobacteriosis o Calidad Seminal: (examen de laboratorio)

��

La siguiente tabla contiene las distintas descripciones de las características que influyen en la capacidad reproductiva de los animales vacunos, (Vaquillas, Vacas y Toros en ese orden). El campo fértil indica si la capacidad reproductiva lo caracteriza como apta/o o no para la reproducción. Cuando se observan a los animales, en las distintas situaciones, se almacenan éstos códigos (cod_caract) en la tabla CARAC (características fenotípicas) asociadas a los animales (caravana) almacenando la fecha y también Observaciones si fuesen necesarias.

DESC_CARACT cod_caract descripción fértil

1�CABEZA DELICADA Y FEMENINA (FERTIL)� Sí�2�CABEZA TOSCA (INFERTIL)� No�3�PELO SUAVE, LUSTROSO, UNTUOSO (FERTIL)� Sí�4�PELO GRUEZO, LARGO, SECO EN EL TUZTEZ (INFERTIL)� No�5�MANDÍBULA FINA (FERTIL)� Sí�6�MANDÍBULA PESADA, ASPECTO REDONDEADO

(INFERTIL)�No�

7�CAÑAS CORTAS� Sí�8�CAÑAS ALARGADAS Y FINAS� No�9�ESPALDA LIVIANA, BORDE SUPERIOR ALTO� Sí�

10�ESPALDA PESADA, MUSCULOSA, BORDE SUPERIOR BAJO�

No�

11�GRUPA LARGA� Sí�12�GRUPA CORTA� No�13�CUELLO DESCORNADO� Sí�14�MUSCULOSO� No�15�PELOS de la UBRE CORTOS Y UNTUOSOS� Sí�16�PELOS de la UBRE LARGOS, SECOS Y OPACOS� No�17�UBRE BUENA CONFORMACIÓN Y DESARROLLO� Sí�19�UBRE MAL DESARROLLADA� No�20�VACA CON DIFICULTAD EN EL PARTO� No�21�VACA SIN DIFICULTAD EN EL PARTO� Sí�22�VACA CON PEZONES GRUESOS� No�23�VACA SIN PEZONES GRUESOS� Sí�24�BLOQUEO; DIENTE ENTERO� Sí�25�BLOQUEO; MEDIO DIENTE� No�26�BLOQUEO; CUARTO DIENTE� No�27�BLOQUEO; SIN DIENTES� No�28�OJOS NORMALES� Sí�29�OJOS ANORMALES� No�30�CIRCUNSF. ESCROTAL MENOR A 32 CM (1 AÑO)� No�31�CIRCUNSF. ESCROTAL MAYOR A 32 CM (1 AÑO)� Sí�32�CIRCUNSF. ESCROTAL MENOR A 33,5 CM (1,5 AÑOS)� No�

��

DESC_CARACT cod_caract descripción fértil

33�CIRCUNSF. ESCROTAL MAYOR A 33,5 CM (1,5 AÑOS)� Sí�34�CIRCUNSF. ESCROTAL MENOR A 34 CM (2 AÑOS)� No�35�CIRCUNSF. ESCROTAL MAYOR A 34 CM (2 AÑOS)� Sí�36�CONSIST. TESTICULAR; BLANDO Y ESPONJOSO� No�37�CONSIST. TESTICULAR; MUY BLANDO Y ESPONJOSO� No�38�CONSIST. TESTICULAR; MUY FIRME Y ELÁSTICO� Sí�39�CONSIST. TESTICULAR; FIRME Y ELÁSTICO� Sí�40�ARTICULACIONES; TARAS, DOLOR� No�41�ARTICULARIONES; SIN TARAS Y SIN DOLOR� Sí�42�PEZUÑAS DESPAREJAS, CRECIMIENTO ANORMAL� No�43�PEZUÑAS PAREJAS, CRECIMIENTO NORMAL� Sí�44�MALA LOCOMOCIÓN, POCA FACILIDAD DE

DESPLAZAMIENTO�No�

45�BUENA LOCOMOCIÓN, FACILIDAD DE DESPLAZAMIENTO� Sí�46�C.S. (capacidad de servicio) BAJA; 0, 1 Y 2 SERVICIOS

(prueba 40')�No�

47�C.S. (capacidad de servicio) MEDIA; 3, 4 Y 5 SERVICIOS (prueba 40')�

Sí�

48�C.S. (capacidad de servicio) ALTA; 6 O MÁS SERVICIOS (prueba 40')�

Sí�

Metodología aplicada:

Introducción: La metodología aplicada para la selección de animales es compleja, se hicieron una serie de pruebas para seleccionar la que mejor se adapte a la situación y los requerimientos del experto (Veterinario). Para la implementacion de la base del conocimiento se decidió incluir estos datos en la propia base de datos relacional que utiliza el sistema por una cuestión de simplificación de los procesos y de uso de los recursos, físicos y de implementación. Partiendo de la base de que un sistema de toma de decisiones es generalmente aplicado en los sistemas gerenciales utilizados por empresas y/o entidades que utilizan esta información para mejorar su producción, por ejemplo, empresas que cuentan con varias sucursales y acaparan un gran espectro del mercado. No es común implementar un sistema de toma de decisiones en la cría de ganado vacuno, o por lo menos los antecedentes no son muy conocidos. Metodología: Se han implementado en el proyecto, en los módulos de toma de decisiones, las siguientes metodologías: • Sentencias de selección y decisión:

Sentencias Select, If, else, else if. (Teoría de toma de decisiones)

��

• Lenguaje de consulta estructurado (SQL) Consultas a la base de datos relacional. Creación de vistas, variables condicionales, etc. (Herramientas utilizadas)

• Combinación de ambas: En ciertas situaciones fue imprescindible combinar las consultas a la base de datos, con variables que dependían de cierta condición, y en muchos casos de más de una condición. Es decir dependiendo del camino lógico seguido, luego de ejecutar ciertas condiciones, las variables toman cierto valor y esas variables son utilizadas para obtener la consulta a la base de datos. La razón de utilizar esta metodología se debe a la necesidad de que el sistema se adapte a la información que sea cargada en la base de datos, por ejemplo si el productor solo carga los pesos de sus vaquillas, los criterios de selección de vaquillas para entrar a servicio deberían ser el peso, la raza (opcional), es decir el sistema se adapta a los criterios de selección que desea usar el productor independientemente de que la información de cierta característica este cargada o no. Obsérvese el sig. grafico.

��

Dependiendo si existe un set de registros, por ejemplo de condiciones corporales registradas, o de pesos, o de eficiencia reproductiva (según características fenotipicas), etc. Para la etapa de cría seleccionada, y la raza del animal (opcional, se pueden seleccionar todas las razas) entonces el sistema incluye éste criterio para seleccionar animales. Si no se ingresan datos para algún criterio de selección el sistema interpreta que el productor no desea incluir este criterio para seleccionar animales, por lo tanto el sistema descarta este criterio y no lo incluye en la selección. Por otro lado si el productor ingresa parámetros de selección de características que no fueron cargadas a la base de datos, el sistema informa de que el criterio no será incluido en la consulta SQL.

Ejecuta script SQL (único), para cualquier situación y/o combinación de criterios

Ingreso de parámetros (criterios de selección/elección)

Consulta BD. Para comp. Si existen registros cargados

Exi. Reg? Incluir criterio Descarta Criterio si No

Experto, actúa según etapa de la cría seleccionada

Según reg. setea variables para consulta

Informe: Caravanas encontradas

Combina criterios

Fin

Nota: Para comprender mejor la metodología utilizada ver código fuente de la aplicación (modulo servicios)

Somera explicación de metodología utilizada para seleccionar animales.

��

Nota: en el proyecto, no se implementaron todas las causas que influyen en la toma de decisiones, acerca de que animales se van a seleccionar para que vayan a servicio. No obstante pueden ser incluidas sin muchas modificaciones en el código, ya que la estructura de los datos y de la aplicación así lo permite. Algunos de los datos que no se incluyeron son; examen sanitario de los animales; exámenes sanguíneos, etc. ya que si se lleva un buen plan sanitario, es poco probable que los animales sufran de alguna enfermedad, por supuesto que puede haber excepciones. Otros criterios no se han tenido en cuenta por falta de datos reales, ya que algunos datos no pueden ser simulados, porque dependen de la ocurrencia de múltiples variables que dependen de la situación, manejo, variables ambientales, etc., etc.

Las siguientes figuras muestran algunos flujos de pantallas cuando se combinan ciertas características o criterios.

En éste caso solo se selecciona, la etapa de la cría (Toro), obligatorio, y un intervalo de pesos, propuesto por el experto (se pueden modificar), opcional.

En éste caso se selecciono la categoría Vaquilla de 1º servicio, los parámetros de pesos y parámetros de condiciones corporales.

��

En este caso se selecciono la etapa de cría Vaquilla de primer servicio, y se dejaron en blanco todos los parámetros de criterios, es decir que la aplicación selecciona todas las vaquillas de primer servicio, sin importar incluir los demás criterios de selección. Presionando el botón con la imagen de un rayo, la aplicación pone en funcionamiento el motor de inferencia que combina los criterios y filtra la base de datos para encontrar los animales.

Aquí se selecciona la misma etapa de la cría del ejemplo anterior, pero se desea que la aplicación además incluya el criterio de que el tipo racial de las vaquillas sea “Brangus Europeizado”, e-ganadero informa que 152 animales cumplen con las características especificadas.

��

Aquí “e-ganadero”, informa que ninguna vaquilla de primer servicio, de cualquier raza, se encuentra entre éstas condiciones corporales (7 y 9), por lo tanto informa que los parámetros de condiciones corporales no formarán parte del criterio de selección, es decir que se obvia este criterio, o no se lo incluye cuando se pone en funcionamiento el motor de inferencia.

Si se reducen los extremos de los parámetros de condiciones corporales “e-ganadero”, incluye este criterio en la ejecución del motor de inferencia, porque existen vaquillas de reposición de cualquier raza que están entre estos parámetros, e informa que encontró 111 animales, luego de Aceptar se muestran las caravanas encontradas (ver próxima figura).

��

Aquí “e-ganadero”, incluyó en el motor de inferencia, los criterios de condición corporal y de peso, para todos los toros de cualquier raza, y encontró 9 animales, luego de aceptar se muestran los animales que están aptos según estos parámetros de criterios.

��

En ésta situación en que se ingresaron todos los criterios de selección, “e-ganadero”, determina que un solo animal cuenta con éstas características, esto se debe, particularmente para éste ejemplo, de que solo se registraron áreas pélvicas y eficiencias reproductivas para un animal. Y como por lo menos un animal cumple con todas las condiciones ingresadas, entonces el motor de inferencia incluye todos los criterios en su ejecución. Mediante el último ejemplo se puede observar que ésta utilidad es totalmente flexible, al tipo de política o estrategia de producción del usuario, como así también en la cantidad de datos que son cargados en la aplicación.

��

¿Como registrar el envío a servicio de los animales que cumplen con la estrategia de producción o con la propuesta del experto? Supongamos ahora que se realizó la siguiente combinación de criterios. Etapa de la cría = “Vaquilla de Primer Servicio” Raza = “Todas” Condición corporal entre: 2 y 8 Eficiencia Reproductiva = “null”, o no se especifico => se obvia. Peso entre: 270 y 350, los propuestos por el experto. Para obtener los siguientes resultados

Si se tilda Caravanas se seleccionan todos los encontrados por “e-ganadero”, o se pueden seleccionar de anuas. Presionando el botón “A Servicio” (solo disponible en sesión Admin.), se visualizará una interfaz, donde se pueden ingresar las fechas entre las cuales los animales seleccionados entrarán a servicio, también se puede agregar una observación opcional. Luego de esto presione Aceptar para registrar que éstos animales ingresaron a servicio entre éstas fechas.

��

Estrategias de “Soporte a la Decisión” y “Sistemas Expertos”, aplicadas a la selección de animales para Descarte Escenario: Ya se ha visto como “e-ganadero” ayuda a los usuarios finales a seleccionar los animales, que según el experto o la política de producción, están aptos o cumplen con las condiciones prefijadas para algún manejo en la cría, en el caso anterior el “Servicio”. La herramienta que se explicará a continuación, es la antítesis de la anterior, es decir mientras que la anterior ayudaba a seleccionar animales aptos, ésta da soporte a la decisión, para descartar los animales que no rinden en la producción propiamente dicha. Razón de ser de ésta utilidad: En cualquier etapa de la producción, ya sea después de los servicios, las preñeses o los destetes, es imprescindible para un eficiente manejo del rodeo o plantel de reproductores/as, descartar aquellos animales que no presentan buena performance reproductiva. En los ítems de “Situaciones estudiadas”, del punto “Estrategias de Soporte a la Decisión, aplicadas a la selección de animales para Servicios, basadas en políticas de producción” se explicó en que situaciones los animales deben ser descartados. En el campo los animales que no representan una ganancia en la producción y reproducción deben ser descartados, porque implican gastos de medicamentos, cuidado, y consumen los alimentos de los otros animales que si producen. Esta utilidad además de brindar soporte a la decisión del tipo; qué animales descartar, brinda al usuario una serie de opciones de que hacer con esos animales que tiene baja eficiencia reproductiva; no siempre la decisión será vender o descartar todos los animales que no producen un ternero por año, algunas veces existen otras opciones que pueden ser más rentables que la venta. Estas opciones son dadas por técnicas de sistemas expertos, basadas en la reglas de decisión. Para futuras implementaciones se tiene pensado aplicar sistemas expertos basados en probabilidades, para ésta utilidad, si es que se cuentan con una cantidad considerable de datos históricos, bien estructurados. Metodología Empleada: Las metodologías empleadas, utilizan técnicas de sistemas expertos basados en reglas de decisión combinadas con consultas estructuradas a la base de datos. Para ello, “e-ganadero”, pone a disposición algunas opciones de descartes, o bien dejar que mediante técnicas estructuradas “e-ganadero” decida que animales descartar. Si se elige ésta última opción “e-ganadero” elige todos aquellos animales que no cumplen con ninguna condición como para seguir perteneciendo al plantel de reproductoras, y por consiguiente propone descartar éstos animales, ya que las probabilidades de que en éstas condiciones los animales puedan “recomponerse” son muy bajas. En las otras opciones a los animales, como opciones menos aceptables, se les puede dar la oportunidad de seguir en el plantel, siempre y cuando esto la política o estrategia aplicada sea rentable para el negocio.

��

Pasos a seguir: 1. Seleccione una de las cuatro opciones. 2. Si desea que “e-ganadero” actúe respecto al último servicio, tilde ésa opción. De lo

contrario ingrese los parámetros de fecha en los cuales se desea que actúe el experto, esto último se aplica en el caso que en decisiones anteriores no se descartaron algunos animales propuestos por el experto, y siguieron con baja eficiencia reproductiva.

3. Pulse el botón “Ejecutar”, para poner en marcha el motor de inferencia, y “e-ganadero” encuentre los animales según la opción elegida.

4. “e-ganadero”, muestra las caravanas seleccionadas, e informa la cantidad de animales seleccionados.

5. Pulsando sobre el botón “Experto”, “e-ganadero” propone algunas alternativas o decisiones a tomar, siendo las de primer orden las más aconsejables por el experto. En el caso de que se seleccione, la última opción para los criterios de selección de animales, el experto propone una sola opción, por la razón que fue explicada anteriormente. Nota: Se debe tener siempre presente que el experto “propone” las alternativas, esto no quiere decir que sean las más aconsejables ya que como las decisiones no son estructuradas, algunas veces las propuestas no se ajustarán a la visión de un experto o productor.

Las siguientes figuras muestran el flujo de pantallas de ésta herramienta.

En éste caso “e-ganadero” seleccionó 20 animales para descarte porque no fueron al último servicio.

��

Presionando el botón experto, se visualiza un marco que presenta las alternativas aconsejables. Supongamos, ahora que el productor necesite que la aplicación le ayude a decidir que hacer con las hembras, y cuales son las hembras, que se registraron como vacías, en el año 1997.

��

Pero si se selecciona el último servicio, ocurre lo siguiente:

Ahora; si se selecciona la opción de que “e-ganadero”, proponga que animales descartar, basándose en bases del conocimiento, ocurre lo siguiente

En el caso de que algún animal, no cuente con un registro de peso, entonces el experto estima el registro del peso del animal, de acuerdo a la etapa de la cría del mismo, basándose en reglas de decisión y la base del conocimiento. Los cálculos de rentabilidad en moneda, se hacen a partir de valores almacenados en la base del conocimiento, que pueden no estar actualizados debidos a las condiciones inestables

��

del mercado. No obstante estos valores pueden ser modificados en la base del conocimiento.

��

Herramientas OLAP para “Soporte a la Decisión” Acerca de OLAP Mientras que los almacenes y puestos de datos son los almacenes donde se analizan los datos, el Proceso analítico en línea (OLAP) es la tecnología que permite a las aplicaciones de cliente el acceso eficiente a estos datos. OLAP proporciona muchas ventajas a los usuarios que realizan análisis, por ejemplo: Un modelo de datos intuitivo y multidimensional que facilita la selección, recorrido y exploración de los datos. Un lenguaje analítico de consulta que proporciona la capacidad de explorar las complejas relaciones existentes entre los datos empresariales. Un precálculo de los datos consultados con más frecuencia que permite una rápida respuesta a las consultas ad hoc. Analysis Services de Microsoft® SQL Server™ 2000 constituye una eficaz herramienta OLAP que se puede utilizar con los datos almacenados en diversas bases de datos, incluidas las de SQL Server, Microsoft Access y Oracle. Almacén de datos y OLAP Aunque en ocasiones se utilizan indistintamente, los términos almacén de datos y proceso analítico en línea (OLAP, Online Analytical Processing) se aplican a diferentes componentes de sistemas conocidos como sistemas de ayuda a la toma de decisiones o sistemas de inteligencia empresarial. Los componentes de estos tipos de sistemas incluyen bases de datos y aplicaciones que proporcionan las herramientas que necesitan los analistas para tomar decisiones en relación con el soporte técnico de la organización. Un almacén de datos es una base de datos que contiene la información que, normalmente, representa el historial empresarial de una organización. Estos datos históricos se utilizan para realizar análisis que apoyen las decisiones empresariales a diferentes niveles, desde el diseño estratégico a la evaluación del rendimiento de una unidad determinada de la organización. Los datos contenidos en un almacén de datos se encuentran organizados para permitir el análisis más que para procesar transacciones en tiempo real como ocurre en los sistemas de proceso de transacciones en línea (OLTP, Online Transaction Processing). La tecnología OLAP permite un uso más eficaz de los almacenes de datos para el análisis en línea, lo que proporciona respuestas rápidas a consultas analíticas complejas e iterativas. Los modelos de datos multidimensionales de OLAP y las técnicas de agregados de datos organizan y resumen grandes cantidades de datos para que puedan ser evaluados con rapidez mediante el análisis en línea y las herramientas gráficas. La respuesta a una consulta realizada sobre datos históricos a menudo suele conducir a consultas posteriores en las que el analista busca respuestas más concretas o explora posibilidades. Los sistemas OLAP proporcionan la velocidad y la flexibilidad necesarias para dar apoyo al analista en tiempo real.

��

©1988-2002 Microsoft Corporation. El propósito de las herramientas OLAP (Analysis Services de Microsoft, como herramienta utilizada) El propósito de Analysis Services es proporcionar un rápido acceso analítico a los datos de un almacén de datos. Para lograr este propósito, se deben crear cubos multidimensionales a partir de los datos contenidos en las tablas de hechos y las tablas de dimensiones del almacén de datos. Las medidas numéricas se resumen también en valores agregados previamente durante la construcción del cubo. Los cubos se almacenan en estructuras multidimensionales diseñadas para dar respuesta rápida a las consultas, combinando la información agregada previamente con datos de hechos sin procesar para dar respuesta a una amplia variedad de consultas. Los cubos pueden contener datos resumidos, copiados o leídos directamente desde el almacén de datos. Los cambios en la estructura del almacén de datos o en los datos contenidos en el mismo pueden afectar a la integridad y precisión de los cubos que se hayan creado a partir del almacén de datos. Como las mayorías de la herramientas OLAP proporcionan un acceso en línea continuo a los cubos, los cambios realizados en el almacén de datos subyacente deberán llevarse a cabo teniendo claro cuáles serán los efectos de estos cambios en los cubos y cómo se administrará la sincronización de los datos contenidos en el almacén de datos con los contenidos en los cubos. Los datos OLAP deben actualizarse cuando cambien los datos del almacén de datos. Se deberán procesar los cubos, dimensiones y particiones OLAP para incorporar datos nuevos o modificados desde el almacén de datos. El método que se deberá utilizar para procesar un objeto OLAP depende del objeto y del tipo de cambio realizado en el almacén de datos, por ejemplo, agregar datos, cambiar datos o cambiar la estructura. La función OLAP en tiempo real utiliza cubos en tiempo real para sincronizar automáticamente los datos de los cubos con los cambios de la base de datos relacional subyacente. Los cubos en tiempo real se pueden usar para las aplicaciones que tienen que supervisar y analizar datos en directo, y su finalidad es ampliar la capacidad OLAP en lugar de sustituir los diseños y las aplicaciones tradicionales de los cubos. Cambios en el almacén de datos Normalmente los datos se agregan periódicamente al almacén de datos para incluir la información más reciente acerca de las actividades empresariales de la organización. Los cambios en los datos que ya se encuentren en el almacén de datos son menos frecuentes y, normalmente, se realizan únicamente para corregir errores detectados en el origen del que se extrajeron los datos o para reestructurar los datos debido a

��

cambios organizativos. Normalmente, los cambios estructurales en el diseño del almacén de datos son los menos frecuentes. Agregados de datos Es común agregar nuevos datos al almacén de datos. La información del cubo de la que disponen en línea las aplicaciones cliente se puede ver afectada cuando se agregan datos al almacén de datos debido a interacciones entre los datos y las particiones del cubo. Podrá administrar los efectos de agregar datos al almacén de datos si define con cuidado los filtros de la partición y diseña una estrategia para sincronizar OLAP y los datos del almacén de datos. Cambios de datos Podrá reducir la cantidad de cambios necesarios para corregir errores en un almacén de datos si tiene el máximo cuidado durante las operaciones de transformación, validación y eliminación de datos. Otros cambios a realizar sobre los datos existentes en el almacén de datos pueden deberse a los cambios en la estructura de una organización o en sus productos. Por ejemplo, reorganizar productos en diferentes categorías puede implicar cambios significativos en los datos del almacén de datos, así como en los informes derivados del almacén de datos. En algunos casos, tales cambios pueden requerir que se vuelvan a diseñar los cubos por completo. En otros casos, sólo será necesario volver a diseñar las dimensiones y procesar todos los cubos que las utilizan. Los cambios realizados para corregir errores en los datos básicos también se deben incorporar a la base de datos de origen, normalmente la base de datos empresarial OLTP, y después, se deben migrar al almacén de datos de manera controlada. Muchos diseños de bases de datos empresariales OLTP requieren que los cambios se efectúen mediante una transacción que elimina los datos incorrectos y aplica nuevos datos correctos. Con frecuencia, suele ser más sencillo administrar el efecto de dichas operaciones de corrección sobre datos OLAP. Los cubos pueden incorporar nuevas transacciones de datos que corrijan valores erróneos, como un valor de pesos incorrecto. Sin embargo, las transacciones que mueven un hecho de un miembro de dimensión a otro, por ejemplo una venta enviada al cliente erróneo, pueden afectar a los resultados de ciertas funciones de agregado, tal como Avg. Este hecho también es cierto para bases de datos distintas de OLAP; si se elimina una orden original de venta pero su registro permanece en la base de datos, será incluida en el recuento de registros de ventas y afectará al cálculo. Dependiendo del diseño de almacenamiento del cubo, los cambios en los datos de la tabla de hechos pueden afectar a la exactitud de las consultas realizadas a un cubo hasta que éste se procese. Se puede utilizar la opción de proceso Actualizar datos para volver a cargar los datos del cubo y volver a calcular las agregaciones. Como el diseño de la agregación sigue siendo el mismo, la opción de proceso Actualizar datos es más rápida que la opción Proceso completo. Los cambios en los datos de las tablas de dimensiones del almacén de datos pueden afectar a las jerarquías de dimensiones incluso aunque se siga conservando el esquema de la tabla. La jerarquía de dimensiones está basada en las relaciones existentes entre los miembros de una tabla de dimensiones. Cuando se modifican estas relaciones, por ejemplo al reorganizar las ciudades en diferentes regiones de ventas, será necesario volver a generar la estructura de la dimensión. Se deberá mantener la integridad referencial cuando se agreguen, cambien o eliminen datos del almacén de datos. La pérdida de integridad referencial puede dar como resultado errores durante el procesamiento del cubo, que se pasen por alto registros de la tabla de hechos o información OLAP inexacta.

��

Cambios en la estructura La estructura de los cubos y dimensiones OLAP puede verse afectada por los cambios en el diseño del almacén de datos, por ejemplo al agregar, borrar o alterar tablas o las relaciones existentes entre las tablas. Cuando la estructura cambia, deberá modificar el diseño de los cubos y dimensiones afectados, volver a definir las particiones y agregaciones y procesar por completo los cubos y dimensiones que se hayan modificado. Sincronizar OLAP con los datos del almacén de datos Los cubos válidos se encontrarán en línea y estarán disponibles para las aplicaciones cliente siempre que Analysis Server esté en ejecución. Debido a la posibilidad de interacción de las particiones de cubo OLAP con los datos del almacén de datos, el diseño de este almacén debe incluir una estrategia de sincronización que permita la inclusión de datos sin que los cubos proporcionen respuestas incorrectas a las consultas realizadas en los cubos disponibles para las aplicaciones cliente en pantalla. Una estrategia para administrar los nuevos datos agregados al almacén y a OLAP es diseñar un sistema de actualización por lotes. En esta estrategia, todos los datos contenidos en el almacén de datos incluyen un número de lote en cada registro. Cuando se diseña un cubo, se agregue una expresión al filtro para que en cada una de las particiones del cubo se especifique el mayor número de lote aplicable, por ejemplo, "... AND DWBatch <= 33 ..." Cuando se necesite agregar nuevos datos a la tabla de hechos, se debe incluir un número de lote nuevo y superior en los registros nuevos. Los cubos no se verán afectados por los nuevos registros que acaba de agregar porque las particiones del cubo sólo leerán los datos correspondientes a los números de lote anteriores. Los datos agregados a una tabla de dimensiones no afectan a las dimensiones privadas o compartidas del cubo existente hasta que se procesen las dimensiones. No se necesitan números de lote en los registros de la tabla de dimensiones, pero pueden ser útiles para asegurar una integridad referencial constante. Las dimensiones y los cubos o las particiones se pueden procesar de forma que incorporen los datos nuevos después de agregar un lote de datos a la tabla de hechos y a las tablas de dimensiones. Se deberán procesar las dimensiones compartidas antes que los cubos que las utilizan. Para agregar nuevos miembros a una dimensión sin que ello afecte a la estructura de la dimensión, se puede utilizar la opción Actualización incremental. Para agregar nuevos miembros y volver a generar la estructura de la dimensión, se debe utilizar la opción Volver a generar la estructura de la dimensión. Se puede observar que cuando se procesa una dimensión compartida con la opción Volver a generar la estructura de la dimensión, todos los cubos que contienen esa dimensión dejan de estar disponibles inmediatamente para las aplicaciones cliente y se deben procesar para que vuelvan a estar disponibles. Sin embargo, cuando se procesa una dimensión compartida mediante la opción Actualización incremental, cualquier cubo que utilice la dimensión compartida mostrará los nuevos miembros, pero las celdas asociadas con esos miembros permanecerán vacías hasta que se actualice el cubo con los nuevos datos de la tabla de hechos que está relacionada con los nuevos miembros. Para incorporar un nuevo lote de datos a un cubo, se deberá actualizar la expresión de filtro contenida en cada una de las particiones del cubo para incluir el nuevo número de proceso por lotes y, a continuación, procesar o actualizar el cubo de forma incremental. Si los datos del cubo están divididos entre varias particiones, se podrá utilizar una de las particiones para acumular nuevos lotes de datos y procesar únicamente esa partición. Las demás particiones del cubo deberán contar con filtros para excluir los nuevos datos de forma que dichos datos se agreguen únicamente a la partición de acumulación.

��

Técnicas OLAP aplicadas a la “Toma de Decisiones” en la cría de ganado vacuno. Usando como herramienta el Analysis Services de Microsoft, se han creado un par de cubos de almacenamiento de datos, uno a partir de la tabla de hechos de peso, llamado Inventario, y otro a partir de la tabla de hechos de Condiciones Corporales, llamado Condición Corporal. Los cubos creados, están netamente compuestos por los datos provenientes de la base de datos transaccional (diseñada en Access). El Cubo Condición Corporal: El cubo cuenta con las siguientes dimensiones y niveles.

• Etapas (de la tabla etapa_cria) o Descripción

• Razas (de la tabla razas) o Descripción

• Vacunos (de la tabla vacunos) o Caravanas

Y con la siguiente medida de la tabla de hechos. • Código de condición corporal. (de la tabla Cond_Corp)

El cubo Inventario: El cubo cuenta con las siguientes dimensiones y niveles.

• Tiempo (de la tabla peso) o Año o Trimestre o Mes o Día

• Razas (de la tabla razas) o Descripción

• Vacunos (de la tabla vacunos) o Caravanas

• Tactos. (de la tabla tactos y des_tactos) o Decisión o Descripción o Fecha

• Etapa (de la tabla etapa cría) o Descripción

• Raza (de la tabla razas) o Descripción

• Procedencia (de la tabla Vacunos) o Procedencia

Y con la siguiente medida de la tabla de hechos. • Peso. (de la tabla Peso)

��

Examinar los datos del cubo Se expondrá como ejemplo el cubo Inventario. Razón de este paso El Examinador de cubos le permite ver los datos de varias formas diferentes: puede filtrar la cantidad visible de datos de dimensión, aumentar el detalle de visualización o reducirlo.

Escenario: Antes que nada deben procesarse los cubos, luego se tienen los datos disponibles para realizar los análisis. En esta sección, se utiliza el Editor de cubos para dividir en rebanadas y subcubos los datos de Pesos. Cómo ver los datos del cubo mediante el Examinador de cubos Para examinar datos se debe acceder al Examinador de cubos, que muestra una cuadrícula formada por una dimensión y las medidas del cubo. Las cinco dimensiones adicionales aparecerán en la parte superior del examinador.

��

Intercambiar dimensiones en la cuadrícula Arrastrando una de las dimensiones que se encuentran en la parte superior hacia la columna donde se desea intercambiar. Con esta técnica, se puede intercambiar la dimensión etapa por la dimensión raza. Las dimensiones Etapa y Razas intercambiarán sus posiciones en el Examinador de cubos.

��

Cómo filtrar los datos por días Haciendo clic en la flecha hacia abajo situada junto a la dimensión Tiempo. Expanda Todos Tiempo y 1998 y, a continuación, haga clic en Trimestre 1. Luego en Agosto. Y luego en 28. Se filtran los datos de la cuadrícula para que sólo reflejen las cifras correspondientes a ese día.

��

Cómo aumentar el detalle Se pueden agregar dimensiones mediante la técnica de arrastrar y colocar. Por ejemplo arrastrando la dimensión Tactos, se puede obtener por decisión (des), la cantidad de kilogramos, observe la siguiente figura. Nota: para cerrar esta columna de subcategoría, haga doble clic en una celda expandida.

Se pueden utilizar las técnicas anteriores para agregar y quitar dimensiones a la cuadrícula. Mediante éste se puede comprender cómo la herramienta Analysis Manager proporciona información acerca de relaciones de datos complejas. Nota: La herramienta Analysis Manager, proporciona muchísimas utilidades. A modo de conocer la herramienta se han utilizado solo las aplicaciones más simples y se deja como futuras investigaciones, aplicaciones tales como miembros calculados, acciones, celdas calculadas, consultas de predicción, y la implementación directa en la aplicación desarrollada,�� , de consultas y acceso a los cubos mediante consultas MDX (instrucción de expresiones multidimensionales). Y una de las implementaciones más importantes, y que requiere de una investigación mas a fondo, el modelo de minerías de datos. �

�

��

Futuras Implementaciones Algunas de las futuras implementaciones pensadas requieren de un análisis de sistema más minucioso en el ámbito de la producción ganadera. Para algunas implementaciones ya se cuenta toda la información como para comenzar al diseñarlas, de hecho, algunas ya están diseñadas (todas de gestión operativa), pero no se incluyeron en la aplicación porque exceden los alcances del presente trabajo. Ciertas futuras implementaciones tienen mas prioridad que otras, como ser; Informes Gráficos, Informes Estadísticos, todo esto considerando como más prioritaria las aplicaciones de usos gerenciales. Obviamente que para analizar datos primero deben ser cargados, es decir es inconcebible pensar un sistema de uso gerencial, sin un sistema de gestión operativa que sea el “INPUT” de los mismos. Las futuras implementaciones planificadas son: Aplicaciones de Planificación:

• Pronóstico, basado en probabilidades, de animales que se preñan, en un cierto período. Para aplicar esto se utilizan sistemas expertos basados en probabilidades, utilizando el razonamiento bayesiano (explicado en el Capítulo I: Sistemas expertos – Tratamiento de la incertidumbre). Para ello son necesario los siguientes datos, los más relevantes, de muestras estadísticas; Condiciones Corporales, Razas, Características Genéticas, y Etapa de la Cría.

Por ejemplo, según experimentos realizados, en campos de la provincia del Chaco, por el INTA, Colonia Benítez, una condición corporal promedio = 3, en la reproductoras, en la etapa Vaquillas de Reposición, de raza Criolla. Implica que solo el 30 % de las reproductoras quedarán preñadas. Fuente: Dr. Oscar Mastandrea, INTA Colonia Benítez. Chaco

• Utilizar técnicas de Modelado y Simulación, considerando los animales que

quedaron preñados, como resultado de la explicación anterior, para obener un pronóstico de los animales que destetarán un ternero. Para aplicar ésta utilidad se tomarán los animales que supuestamente quedarán preñados, obtenidos a partir del pronóstico que se obtuvo con la implementación de pronóstico de preñeses. Los variables intervenientes son simuladas según algún criterio de parámetrización, que pueden ser Optimista, Medio o Pesimista, por ejemplo. Para Obtener una proyección de cuantos terneros se van a producir para un período determinado.

Esto es importante porque permite al productor, dar soporte a la incertidumbre del tipo; “Que pasaría sí”, y las consecuencias que implicaría, si ocurriesen éstos supuestos.

Aplicaciones Expertas para el Soporte a la Decisión: • Si se tienen los datos de abortos de las reproductoras, se pueden obtener un

indicar de enfermedades. • Otra posible implementación, sería; dar soporte a la decisión, sobre que tipo de

destete utilizar, de acuerdo a la condición corporal de la madre, durante el período que ésta se encuentra con el ternero al píe.

• Registrando los datos de la ubicación de los animales, junto con los datos de los potreros donde se ubican los mismos. Éstos datos son: Superficie, Especie

��

(pastizal) predominante, Porcentaje de matéria seca obtenida del pastizal (examen de laboratorio), Distancia entre aguadas, Receptibilidad (Unidades ganaderas o Cabezas por hectárea. Esto es cuantos animales pueden habitar una hectárea), etc. Registrando éstos datos, y por otro lado las condiciones corporales, los pesos, la etapa de la cría actualizada de los animales, una “Aplicación Experta” podría dar al productor un soporte a la decisión del tipo, a que potrero enviar a cierto grupo de animales, o cual es el potrero apto para enviar a los animales para pre-servicio, o que potreros están muy deteriorados y deben tener un período de descanso (no ser habitado por animales) etc. Nota: para una mayor precisión del soporte a la decisión, se debería considerar también pronósticos ambientares. Y registros de variables ambientales anteriores.

• Siguiendo con el tema de los potreros, una Implementación seria que se tiene pensada es la implementación de Sistemas de Información Gráfica (G.I.S). Para conocer la ubicación de los animales. Estos sistemas tienen particular uso en países desarrollados de Europa, donde en lugar de identificación por caravana utilizan un microchip, ubicado en el bulbo de la oreja del bovino. Los animales son monitoreados por satélite y mediante la ID del animal se conocen todos sus datos en tiempo real. Nota: la identificación por caravana es igual a la utilizada mediante el microchip, los dos tipos de ID dan información del número del animal. La diferencia radica en que los microchips emiten una señal electromagnética que son interpretadas por dispositivos especiales. Y las caravanas deben ser observadas por alguna persona, para luego ingresarlas al sistema para obtener la entrada de datos.

Implementaciones de Generación de Informes. Las futuras implementaciones que más prioridades tienen, son la generación de distintos tipos de informes. Algunos informes ya están diseñados, y codificados solo que requieren de algunas modificaciones que debieron hacerse a último momento y aún no están terminadas. Para la generación de los informes se está utilizando la herramienta Crystal Reort, de Seagate, en su versión 8.0. Ésta es una potente herramienta mediante la cual se pueden obtener todo tipo de informes, incluyendo informes estadísticos, gráficos, de resultados, etc. Además ésta herramienta se adapta perfectamente a las necesidades del proyecto, ya que permite utilizar fuentes de datos OLAP. Y además se puede utilizar directamente desde la aplicación diseñada en Visual Basic, utilizando el control OCX del Crystal Report, o la nueva herramienta para crear informes directamente desde Visual Basic, utilizando algún tipo de conexión a al base de datos, por ejemplo conexiones mediante el objeto ADO. Y utilizando para las filtrar los datos del reporte, por ejemplo consultas SQL o MDX. Los Siguientes informes pretenden ser incluidos en el proyecto en futuras implementaciones:

• Informes de Vacunos (datos particulares) * • Informes de Pesos * • Informes de condiciones Corporales • Informes de ubicaciones (potreros) • Informes de servicios

��

• Informes de preñeses • Informes de pariciones • Informes de Destetes • Informes de Planes Sanitarios. * • Informes de Productos Sanitarios Aplicados. * • Informes para Trazabilidad (para información del producto) • Informes de Árboles Genealógicos. • Otros

Los informes con (*) ya están diseñados. Los informes presentaran eventualmente; datos estadísticos, gráficos, de resultados, etc. Todos los informes pueden tener múltiples filtros de consultas, por supuesto debe que se utiliza un filtro por vez y por reporte. Los informes utilizarán como fuente de datos los cubos multidimencionales, y eventualmente la base de datos transaccional.

��

Conclusiones

Las herramientas informáticas de soporte a las decisiones son y serán cada vez más utilizadas por todo tipo de empresas y organizaciones, fundamentándose en que la información se ha convertido hoy por hoy en el recurso más importante de las organizaciones. Las empresas Argentinas dedicadas a la Cría del Ganado Vacuno, como así también investigadores de la producción ganadera, no deberían permanecer inmunes a éstos adelantos tecnológicos. El Nordeste Argentino, puede transformarse en un importante proveedor mundial de carne vacuna, pero para esto son necesarias varías normativas que se ajusten a estándares mundiales. Una de éstas normativas es la “Trazabilidad”, etc. Empresas Europeas utilizan tecnologías informáticas para cumplir con éstas normativas. Todas las condiciones están dadas para que esto ocurra, la naturaleza y nuestra tierra así lo demuestran. Un recurso más para contribuir al crecimiento de la producción es la información. Para esto es necesario contar con herramientas que hagan que la información sea útil. Almacenar datos, procesarlos y obtener resultados, para tomar decisiones a partir de éstos es hoy por hoy una necesidad imperiosa en la producción e investigación de la cría del ganado vacuno. Y si éstos sistemas dan soporte a la “Toma de Decisiones”, simplifican y hacen más efectivos los procesos claves en la producción. El razonamiento seguido en el desarrollo del proyecto “e-ganadero”, para el Trabajo Final de Aplicación de la carrera Licenciatura en Sistemas, de la Fa.C.E.N.A, U.N.N.E. está pensado para éstos propósitos.

��

Bibliografía

• Artificial Intelligence.

Elaine Rich.

• El directivo experto. David Bendel Hertz.

• Sistemas Expertos.

Arantza Díaz de Ilarraza / Isabel Fernández de Castro.

• http://personales.unican.es/gutierjm/cursos/expertos/: Sistemas Expertos Basados en Reglas Prof. José Manuel Gutiérrez Dpto. de Matemática Aplicada. Universidad de Cantabria

• Conocimiento es Futuro. Valdes, Luigi.. Conamin, CCTC y Funtec. Junio de 1997.

• Manuel Mendoza Ramírez La estadística y los retos del presente http://www.jornada.unam.mx/

• http://ia-serv.dia.uned.es (sitio de publicación del proyecto Elvira, o Entorno de Desarrollo para Modelos Gráficos Probabilísticas)

• J.A. Gámez y J.M. Puerta (Eds.). Sistemas Expertos Probabilísticos.

Universidad de Castilla-La Mancha, Cuenca, 1998��

• http://www.isoft.com.uy/web/empresa (publicaciones sobre adelantos de los DSS orientado a las empresas, herramientas utilizadas, utilidades, etc.)

• http://www.utec.edu.sv/campus/intelecto/ Sistemas de información,

conocimiento y toma de decisiones Por: Lic. Miguel Ángel Meléndez Campus UNITEC, Tegucigalpa, Honduras

• Teorías de la cátedra Modelos y Simulación (Fa.C.E.N.A)

• http://www.microsoft.com/spanish/MSDN/estudiantes/

Publicaciones y apuntes sobre la producción en el ganado vacuo

• http://www.larural.es/cercosoft/ • http://www.agroconnection.com • http://www.ruralarg.org.ar/comision.htm • http://www.inta.gov.ar • http://www.zoetecnocampo.com/

��

• “Cría Bovina”. Apuntes de la Cátedra: Zootecnia Especial, Facultad de Veterinaria, U.N.N.E.

• “Normas para Medir la Producción de Carne”. Apuntes de la Cátedra: Zootecnia Especial, Facultad de Veterinaria, U.N.N.E.

• Manual del Usuario del “Balanceador Automático de Raciones para Novillos”. Estación Experimental Agropecuario Reconquista (Santa Fe)

• La Unidad de Cría de la EEA Corrientes. Arias, A. – Manunta, O. – Slobodzian, A – Peruchena, C.

��

Tabla de Contenidos. Presentación……………………………………………………………………………....

1

Resumen……………………………………………………………………………........... 2

Capitulo I: Teorías y Métodos…………………………………….. 4

Teoría de los Sistemas Expertos……………………………………………... 4

Inteligencia Artificial………………………………………………………………….. 4

Panorama de la Inteligencia Artificial…………………………………………. 4

Alcance de la Inteligencia Artificial……………………………………………. 4

Sistemas Expertos…………………………………………………………………… 7

¿Que es un Sistema Experto?.................................................................... 7

Áreas de Aplicación de los Sistemas Expertos……………………………… 7

Nociones de funcionamiento de los Sistemas Expertos…………………… 10

Descripción del Esquema……………………………………………………… 10

Sistemas Expertos Basados en Reglas………………………………………..

11

Introducción……………………………………………………………………… 11

El motor de Inferencia…………………………………………………………..

13

Modus Ponens y Modus Tollens……………………………………………….

13

Encadenamiento de Reglas……………………………………………………

14

Tratamiento de la Incertidumbre………………………………………………..

15

Introducción………………………………………………………………………

15

El razonamiento Bayesiano…………………………………………………….

16

��

Probabilidades condicionales…………………………………………………..

17

Inferencia del Sistema…………………………………………………………..

18

Probabilidades a Priori………………………………………………………….

18

Probabilidades a Posteriori……………………………………………………..

18

Sistemas de Soporte a la Toma de Decisiones (DSS)…………………..

20

Modelo Administrativo………………………………………………………….

20

Definición…………………………………………………………………………

21

Tipos de Sistemas de Apoyo a las Decisiones……………………………… 21

Características de los DSS……………………………………………........... 21

Componentes Funcionales que integran un DSS…………………………..

21

El Modelo……………………………………………………………………….. 22

La Base de Datos………………………………………………………........... 22

Sistema de Software…………………………………………………………… 23

Interfase con el Usuario………………………………………………………..

23

Factores para el Éxito de un DSS……………………………………………. 23

Aplicaciones…………………………………………………………………….. 23

Tendencias Futuras……………………………………………………………. 24

Sistema Manejador de Base de Datos………………………………………. 25

Proceso de Toma de Decisiones…………………………………………….. 25

Soporte a Cada Fase………………………………………………………….. 26

Componentes de un DSS…………………………………………………….. 27

��

Beneficios de un DSS…………………………………………………………. 28

Data Warehousing…………………………………………………………….. 29

Introducción…………………………………………………………………….... 29

Teoría……………………………………………………………………............. 30

Sistemas de Información……………………………………………………….. 30

Características de un Data Warehousing……………………………………. 32

Estructura del Data Warehouse………………………………………............ 40

Arquitectura del Data Warehouse…………………………………………….. 42

Elementos constituyentes de una Arquitectura Data Warehouse………….

43

Operaciones en un Data Warehouse ………………………………………… 45

Plataforma de un Data Warehouse…………………………………………… 46

Transformación de Datos y Metadata………………………………………… 47

Flujo de Datos…………………………………………………………………… 49

Medios de Almacenamiento para Información Antigua…………………….. 50

Uso del Data Warehouse………………………………………………………. 50

Consideraciones Adicionales………………………………………………….. 55

Excepciones del Data Warehouse……………………………………............ 56

Proyecto de un Data Warehouse………………………………………………

57

Capitulo II: Herramientas y Metodologías Utilizadas……….. 68

Lenguaje de Consulta Estructurado (SQL)……………………………... 68

��

Introducción……………………………………………………………………...

68

Componentes del SQL …………………………………………………

68

Cláusulas……………………………………………………………………….. 69

Operadores…………………………………………………………………….. 69

Funciones………………………………………………………………………. 70

Consultas de Selección……………………………………………………….. 70

Criterios de Selección…………………………………………………………. 73

Agrupamiento de Registros…………………………………………………… 76

Consultas de Acción…………………………………………………………… 79

Tipos de Datos…………………………………………………………………. 82

SubConsultas…………………………………………………………………… 83

Consultas de Referencias Cruzadas………………………………………… 85

Consultas de Unión Interna…………………………………………………… 86

Consultas de Unión Externa…………………………………………………. 88

Estructuras de las Tablas…………………………………………………….. 88

Consultas Con Parámetros…………………………………………………… 92

Bases de Datos Externas……………………………………………………... 92

Omitir los Permisos de Ejecución……………………………………………. 93

Cláusula Procedure……………………………………………………………. 93

Anexos………………………………………………………………………….. 94

Simulación……………………………………………………………………. 98

��

Introducción…………………………………………………………………... 98

El por qué de su uso………………………………………………………… 98

Metodología Empleada……………………………………………………… 98

Teoría del Método Aditivo de las Congruencias…………………………. 99

Generación de Variables Aleatorias……………………………………….. 99

Simulación de Mediciones de Pesos………………………………………. 99

Simulación de Condiciones Corporales…………………………………… 100

Capítulo III: Descripción de la Aplicación y Resultados… 101

Informatización en la Producción Ganadera…………………………. 101

Resumen……………………………………………………………………… 101

Un Ejemplo…………………………………………………………………… 101

Normas para Medir la Producción de Carne……………………………… 102

Trazabilidad………………………………………………………………… 104

Identificación del ganado en Argentina……………………………...

104

Legislación Actual y necesidades………………………………………….. 104

Situación de Argentina y el Mundo………………………………………….. 106

Pro qué Invertir en Trazabilidad……………………………………………… 107

Formas de Identificación de los bovinos…………………………………... 108

Resultados Proyecto �� ……………......................... 109

Herramientas Informáticas Aplicadas a la Trazabilidad……………. 109

��

Introducción…………………………………………………………………... 109

Herramientas de Gestión Operativas…………………………………...... 111

Autentificación de Usuario………………………………………………….

111

Pantalla o Menú Principal…………………………………………………..

112

Cambiar de Sesión…………………………………………………………..

113

Copia de Seguridad de la Base de Datos…………………………………

114

Restauración de la Base de Datos…………………………………………

115

Alta y Modificaciones de registros de Pesos………………………………

116

Registro de Características Fenotipicas…………………………………... 119

Alta y Modificaciones de Registros de Pesos…………………………….. 122

Movimientos de Marcas……………………………………………………..

124

Asignar o cambiar la Fotografía de un animal……………………………

125

“Herramientas de Soporte a la Decisión”……………………………. 126

Simulación…………………………………………………………………...... 126

Simulador de Pesos…………………………………………………………. 126

Simulador de Condiciones Corporales……………………………………. 128

Estrategias de “Soporte a la Decisión”, para medir eficiencia……….

131

Estrategias de “Soporte a la Decisión” y “Sistemas Expertos” para descartar Descartes……………………………………………………

144

Herramientas OLAP para “Soporte a la Toma a la Decisión”……... 149

Acerca de OLAP…………………………………………………………….. 149

Almacén de datos y OLAP…………………………………………………..

149

��

El propósito de las herramientas OLAP…………………………………… 150

Agregados de datos………………………………………………………….

151

Cambios de datos…………………………………………………………….

151

Cambios en la estructura…………………………………………………….

152

Técnicas OLAP aplicadas en la cría de ganado vacuno…………………

153

El Cubo Condición Corporal………………………………………………..

153

El Cubo Inventario…………………………………………………………… 153

Examinar los datos del cubo……………………………………………….

154

Cómo ver los datos del cubo……………………………………………….

154

Intercambiar dimensiones en la cuadrícula……………………………….

155

Cómo filtrar los datos por días………………………………………………

156

Cómo aumentar el detalle…………………………………………………..

157

Futuras Implementaciones………………………………………………. 158

Conclusiones………………………………………………………………. 161

Bibliografía…………………………………………………………………….. 162

Tabla de Contenidos……………………………………………………….... 164

soporte a la toma de decisiones

Documents