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 Si Área pélvica = Inferior
=> Se queda = No Se queda = No
Regla 4 Regla 5
Sí Peso= Insuficiente Sí Efectividad = no Alcanzo
=> Se queda = No => 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)

Enfermedad

Prueba

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
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

Presente = 0,08
Ausente = 0,92

Positivo = 0,10
Negativo = 0,90

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:
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

Uso de Data Warehouse
Operacionales
Muchos usuarios concurrentes Pocos usuarios concurrentes
Consultas predefinidas y Consultas complejas, frecuentemente no
actualizables anticipadas.
Cantidades pequeñas de datos
Cantidades grandes de datos detallados
detallados
Requerimientos de respuesta
Requerimientos de respuesta no críticos
inmediata

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…
Requeri
Soporte
mientos
Usuarios de Arquitectura Servidor DBMS
comerci
Sistemas
ales
Alcance:
departa Local
mental Pequeña - ubicación mínimo - Consolidado - Procesador
MDDB
Usos: única central paquete único o SMP
análisis promedio
de datos

Alcance:
departa
Seccionado - Grupos de RDBMS
mental Grande Analistas en Local
detalle en SMP para para
Usos: una sola ubicación; mínimo -
central - central; SP o central -
análisis usuarios informáticos central
resumen en SMP para MDDB
más dispersos promedio
local local para local
informáti
ca

Alcance:
empresa
Objeto-
Usos: Grande;
Central Grupos de relacional-
análisis geográficamente Centralizado
fuerte SMP soporte
más disperso
Web
informáti
ca

Alcance:
departa RDBMS
mental Pequeña - pocas Central con
Centralizado MPP
Usos: ubicaciones fuerte soporte
investiga paralelo
ción
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
Utilizado para modificar las tablas agregando campos o cambiando la
ALTER
definición de los campos.

Comandos DML
Comando Descripción
Utilizado para consultar registros de la base de datos que satisfagan un
SELECT
criterio determinado
Utilizado para cargar lotes de datos en la base de datos en una única
INSERT
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
Utilizada para especificar la tabla de la cual se van a seleccionar los
FROM
registros
Utilizada para especificar las condiciones que deben reunir los registros
WHERE
que se van a seleccionar
GROUP
Utilizada para separar los registros seleccionados en grupos específicos
BY
HAVING Utilizada para expresar la condición que debe satisfacer cada grupo
ORDER Utilizada para ordenar los registros seleccionados de acuerdo con un orden
BY específico

Operadores Lógicos

Operador Uso
Es el "y" lógico. Evalua dos condiciones y devuelve un valor de verdad sólo
AND
si ambas son ciertas.
Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdar si
OR
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
Utilizado para especificar registros de una base de datos
In
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
Utilizada para devolver la suma de todos los valores de un campo
SUM
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
Omite los registros duplicados basándose en la totalidad del registro y
DISTINCTROW
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

Para consultas sobre tabla adjunta de productos de bases
BINARY 1 byte
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)
Un entero escalable entre 922.337.203.685.477,5808 y
CURRENCY 8 bytes
922.337.203.685.477,5807.
DATETIME 8 bytes Un valor de fecha u hora entre los años 100 y 9999.
Un valor en punto flotante de precisión simple con un rango
SINGLE 4 bytes 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.
Un valor en punto flotante de doble precisión con un rango
de -1.79769313486232*10308 a -4.94065645841247*10-324
DOUBLE 8 bytes
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.
1 byte por
LONGTEXT De cero a un máximo de 1.2 gigabytes.
carácter
Según se
LONGBINARY De cero 1 gigabyte. Utilizado para objetos OLE.
necesite
1 byte por
TEXT De cero a 255 caracteres.
caracter

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

Tipo de Dato Sinónimos
BINARY VARBINARY
BOOLEAN
LOGICAL
BIT
LOGICAL1
YESNO
BYTE INTEGER1
COUNTER AUTOINCREMENT
CURRENCY MONEY
DATE
DATETIME TIME
TIMESTAMP
FLOAT4
SINGLE IEEESINGLE
REAL
FLOAT
FLOAT8
DOUBLE IEEEDOUBLE
NUMBER
NUMERIC
INTEGER2
SHORT
SMALLINT
INT
LONG INTEGER
INTEGER4
GENERAL
LONGBINARY
OLEOBJECT
LONGCHAR
LONGTEXT MEMO
NOTE
ALPHANUMERIC
CHAR
TEXT 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 Es el nombre del campo o de los campos que se van a crear en la
campo2 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 Es una cláusula CONSTRAINT que define el tipo de indice a crear.
índice2 Esta cláusula en opcional.
Es una cláusula CONSTRAINT que define el tipo de indice multicampos
índice
a crear. Un índice multi campo es aquel que está indexado por el
multicampos
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.
Es el nombre del campo o de los campos que forman el índice de clave
únicoN
única.
Es el nombre del campo o de los campos que forman el índice externo
refN
(hacen referencia a campos de otra tabla).
Es el nombre de la tabla que contiene el campo o los campos
tabla externa
referenciados en ref.
campos Es el nombre del campo o de los campos de la tabla externa
externos 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
Descripción
Indice
Genera un índece de clave única. Lo que implica que los registros de la
UNIQUE
tabla no pueden contener el mismo valor en los campos indexados.
Genera un índice primario el campo o los campos especificados. Todos los
PRIMARY
campos de la clave principal deben ser únicos y no nulos, cada tabla sólo
KEY
puede contener una única clave principal.
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
FOREIGN los nombres de los campos referenciados en la tabla externa en el mismo
KEY 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.
Indica el orden de los valores de lso campos ASC indica un orden
ASC|DESC
ascendente (valor predeterminado) y DESC un orden descendente.
UNIQUE Indica que el indice no puede contener valores duplicados.
DISALLOW
Prohibe valores nulos en el índice
NULL
IGNORE Excluye del índice los valores nulos incluidos en los campos que lo
NULL componen.
Asigna al índice la categoría de clave principal, en cada tabla sólo puede
PRIMARY 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).
Es el nombre del índice del campo (cuando se crean campos) o el
índice
nombre del índice de la tabla que se desea eliminar.
índice Es el nombre del índice del campo multicampo (cuando se crean
multicampo campos) o el nombre del índice de la tabla que se desea eliminar.
Operación Descripción
ADD Se utiliza para añadir un nuevo campo a la tabla, indicando el nombre, el
COLUMN 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 Se utliza para borrar un campo. Se especifica únicamente el nombre del
COLUMN campo.
Se utiliza para eliminar un índice. Se especifica únicamente el nombre
DROP
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
Devuelve los cuatro dígitos correspondientes al
Year Variable=Year(Fecha)
año de Fecha
Devuelve el número del mes del parámetro
Month Variable=Month(Fecha)
fecha.
Devuelve el número del día del mes del
Day Variable=Day(Fecha)
parámetro fecha.
Devuelve un número entero que representa el
Weekday Variable=Weekday(Fecha)
día de la semana del parámetro fecha.
Devuelve un número entre 0 y 23 que representa
Hour Variable=Hour(Hora)
la hora del parámetro Hora.
Devuelve un número entre 0 y 59 que representa
Minute Variable=Minute(Hora)
los minutos del parámetro hora.
Devuelve un número entre 0 y 59 que representa
Second Variable=Second(Hora)
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:

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

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.
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:

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

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.
 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. Engorde Faena Brucelosis

Orgánica a corral para UE

Resolución 1286/93 70/01 115/02 150/02

Nro.

Medio de Indefinida Caravana Indefinida Indefinida

identificación

Sistema de Indefinida Indefinida Indefinida Indefinida

numeración

Registros Indefinida Indefinida Indefinida Indefinida

manuales

Bases de Indefinida Indefinida Indefinida Indefinida

datos

"Reglas de Indefinida Indefinida Indefinida Indefinida

juego"

Entidad Certificadora Oficina Indefinida Fundación

responsable Autorizada Local
SENASA

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$ #""

32
% )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:

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

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.
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 No
(INFERTIL)
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 No
BAJO
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 No
DESPLAZAMIENTO
45 BUENA LOCOMOCIÓN, FACILIDAD DE DESPLAZAMIENTO Sí
46 C.S. (capacidad de servicio) BAJA; 0, 1 Y 2 SERVICIOS No
(prueba 40')
47 C.S. (capacidad de servicio) MEDIA; 3, 4 Y 5 SERVICIOS Sí
(prueba 40')
48 C.S. (capacidad de servicio) ALTA; 6 O MÁS SERVICIOS Sí
(prueba 40')

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.
 Somera explicación de metodología utilizada para seleccionar animales.

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

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

Consulta BD. Para comp. Si existen registros cargados

Descarta Criterio No si Incluir criterio

Exi. Reg?

Según reg. setea variables para consulta

Combina criterios

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

Informe: Caravanas encontradas

Fin

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

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.
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