Zattara 2005 - Sistema Integral de Informacion de Comunidades de Peces

See
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/267811352
Desarrollo de un Sistema Integral de

Información para el análisis estructural de
comunidades de peces
Technical Report · December 2005

DOI: 10.13140/2.1.2959.7122
CITATIONS READS
0 69
1 author:
Eduardo E Zattara
Indiana University Bloomington
50 PUBLICATIONS 124 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
The Bull-headed Dung Beetle Genome Project View project
#SciArt: Exploring the Aesthetics and Feelings of Scientific Research View project
All content following this page was uploaded by Eduardo E Zattara on 06 November 2014.
The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
Desarrollo de un Sistema Integral de
Información para el análisis
estructural de comunidades de peces
LIC. EDUARDO ENRIQUE ZATTARA
INFORME FINAL
Beca de Iniciación “Dr. Gregorio Alvarez”,
Universidad Nacional del Comahue
San Carlos de Bariloche

2005
DESARROLLO DE UN SISTEMA INTEGRAL DE INFORMACIÓN
PARA EL ANÁLISIS ESTRUCTURAL DE COMUNIDADES DE PECES.
BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 2

INFORME FINAL
Tabla de Contenidos
Tabla de Contenidos ......................................................................................................... 3
Prefacio............................................................................................................................. 5
1-Introducción .................................................................................................................. 7
1.1-Patagonia, sus cuerpos de agua y su ictiofauna...................................................... 7
1.2- El Grupo de Evaluación y Manejo de Recursos Icticos ........................................ 8
1.3- Sistema Integral de Información: una base de datos relacional ............................ 9
2 - Introducción a las bases de datos .............................................................................. 12
2.1 - Definiendo qué es una base de datos.................................................................. 12
2.2- Modelos de bases de datos .................................................................................. 13
2.2.1- Bases de datos de archivo plano................................................................... 14
2.2.2- Bases de datos jerárquicas............................................................................ 14
2.2.3- Bases de datos reticulares............................................................................. 15
2.2.4- Bases de datos relacionales .......................................................................... 15
2.2.5- Bases de datos orientadas a objetos.............................................................. 16
2.3- Características de las bases de datos relacionales ............................................... 17
2.3.1- Términos básicos y definiciones .................................................................. 17
2.3.2- Las reglas de Codd ....................................................................................... 19
2.4- Relaciones ........................................................................................................... 23
2.4.1- Características básicas.................................................................................. 23
2.4.2- Uno-a-varios (1-N o 1→∞) .......................................................................... 25
2.4.3- Varios-a-varios (N-N o ∞→∞) .................................................................... 25
2.4.4- Uno-a-uno (1-1 o 1→1 ) .............................................................................. 25
2.4.5- Recursivas .................................................................................................... 26
2.5- Integridad de datos .............................................................................................. 26
2.6- Las formas normales: optimizando el diseño...................................................... 27
2.6.1- Fundamentos ................................................................................................ 27
2.6.2- Primera Forma Normal (1FN)...................................................................... 29
2.6.3- Segunda forma normal (2FN) ...................................................................... 29
2.6.4- Tercera forma normal (3FN) ........................................................................ 30
2.6.5- Forma normal de Boyce-Codd (BCFN) ....................................................... 30
2.6.6- Cuarta forma normal (4FN) ......................................................................... 30
2.6.7- Quinta forma normal (5FN) ......................................................................... 31
2.6.8- Ventajas y desventajas de conformar la base a las formas normales ........... 31
3- El punto de partida: material preexistente.................................................................. 32
3.1- Saber de dónde venimos...................................................................................... 32
3.2- Estructura de muestreo del GEMaRI .................................................................. 33
3.3- Las planillas de campo ........................................................................................ 36
3.4- Almacenamiento digital ...................................................................................... 38
3.5 - Otros tipos de datos ............................................................................................ 40
4- De bases planas al modelo relacional......................................................................... 41
4.1- Tablas centrales y accesorias............................................................................... 41
4.1.1- La tabla de capturas...................................................................................... 41
4.1.2- La tabla de lagos........................................................................................... 43
5- Sistema Integral de Información: Definiciones de Formato y Estructura.................. 48
5.1- Convenciones ...................................................................................................... 48
5.2- Tablas .................................................................................................................. 48
5.3- Relaciones ........................................................................................................... 57
6 - Expandiendo la base de datos ................................................................................... 59
6.1 - Un sistema preparado para crecer ...................................................................... 59
6.1.1- Añadiendo registros ..................................................................................... 59

INFORME FINAL
6.1.2 – Añadiendo campos nuevos a entidades existentes ..................................... 61

6.1.3- Agregando nuevas entidades........................................................................ 61
6.2- Dos ejemplos ....................................................................................................... 63
6.2.1- Añadiendo resolución espacial: CALADOS_GPS.......................................... 63
6.2.2- Anexando datos externos: el ArLaRe .......................................................... 64
7- SII+SIG: Añadiendo la dimensión espacial ............................................................... 67
7.1- Enter SIG ............................................................................................................ 67
7.1.1- Mapa digital de cuerpos de agua .................................................................. 68
7.1.2- Generando mapas de puntos......................................................................... 70
7.2- Usando SIGs y teledetección como fuentes de datos.......................................... 71
7.2.1- La cuenca del Manso.................................................................................... 71
7.2.2- Morfología de los lagos y sus cuencas de drenaje ....................................... 73
7.2.3- Temperatura superficial de los lagos: usando datos de teledetección.......... 75
8- Conclusiones .............................................................................................................. 78
8.1- Tareas a futuro..................................................................................................... 78
8.2- El SII como herramienta ..................................................................................... 78
9- Referencias Bibliográficas ......................................................................................... 80

INFORME FINAL
PREFACIO
El presente texto constituye el Informe Final del proyecto “Desarrollo de un
sistema integral de información para el análisis estructural de comunidades de peces”,
financiado mediante una Beca de Iniciación en Investigación de la Universidad
Nacional del Comahue. El proyecto original, y su desarrollo y modificaciones han sido
explicitados previamente. El presente informe, por tanto, pretende servir no sólo para
evaluar el desarrollo del Sistema Integral de Información (SII) que fue objeto del trabajo
de los últimos dos años, sino además para documentar los principios y fundamentos que
lo sustentan, los pasos lógicos que llevaron al diseño de su estructura, instrucciones
generales y específicas para su uso por parte de los integrantes del GEMaRI, directivas
para su expansión posterior, y ejemplos e ideas para aprovechar al máximo las
potencialidades del sistema.
Con esos objetivos en mente, el Informe se estructura en capítulos, cada uno de

los cuales refiere a distintas fases conceptuales en el desarrollo del SII. La idea central
es que el texto sirva como referencia documental para los usuarios del sistema (un
manual de uso), como base teórica para quienes deseen emprender desarrollos similares
o comprender más a fondo la estructura del SII, como organizador y fijador de
estándares para el almacenamiento de la información, y como seminario de ideas para la
explotación de la información almacenada y su capacidad de expansión e interrelación.
El primer capítulo es una introducción general al área temática abarcada por el
SII, y es una versión reducida y modificada de la introducción al proyecto original.
El segundo capítulo es una introducción teórica condensada sobre teoría de bases
de datos. Su objetivo es brindar un breve repaso sobre los fundamentos detrás del diseño
y la estructura de las bases de datos, haciendo énfasis en el modelo relacional, que es el
elegido para el SII.
El tercer capítulo detalla las metodologías empleadas por el Grupo de Evaluación
y Manejo de Recursos Ícticos para el estudio de los cuerpos de agua de la Patagonia, y
el tipo de información que genera. Así, resume el tipo de datos a organizar en el SII, y
describe los formatos de almacenamiento usados hasta el momento.
El cuarto capítulo describe el proceso de volcado de la información mencionada
en el capítulo anterior a una estructura de base de datos relacional. Así, este capítulo
resume los pasos conceptuales que se siguieron para organizar la información existente

INFORME FINAL
y generar la estructura contenedora que es el núcleo del SII.

El quinto capítulo documenta la estructura del SII; lista las tablas y campos, y sus
principales atributos y definiciones. Luego, lista todas las relaciones establecidas entre
las tablas. También explicita algunas convenciones que se emplean en el resto del texto.
El objetivo de esta sección es dejar documentada una estructura independiente de la
plataforma de software en la que pueda implementarse la base de datos. Dicho de otra
manera, la información que se da en este capítulo permitiría reconstruir la estructura
basal del SII usando cualquier paquete de administración de bases de datos relacionales.
El sexto capítulo versa sobre las posibilidades de expansión futura del SII, ya sea
mediante la ampliación de las tablas con nuevos registros de datos, o mediante la
creación de nuevas tablas para contener nuevos tipos de información o integrar
información de otras fuentes. Se dan indicaciones generales, y ejemplos reales de
integración de nuevos datos.
El último capítulo hace referencia a la integración entre el SII y los Sistemas de
Información Geográfica (SIGs). Señala los puntos de vinculación entre elementos
geográficos manejables desde un paquete SIG, y da algunos ejemplos de usos conjuntos
de análisis geográfico e información del SII.

INFORME FINAL
1-INTRODUCCIÓN
1.1-PATAGONIA, SUS CUERPOS DE AGUA Y SU ICTIOFAUNA
Los sistemas dulceacuícolas cubren aproximadamente el 1% de la superficie de la
Tierra, pero, como en su mayoría se componen de cuerpos de agua someros
(comparados con las profundidades oceánicas), no comprenden más del 0,01% del total
del volumen de los recursos acuáticos. Sin embargo, cerca del 40% del total de especies
de peces del mundo son normalmente encontradas viviendo en ríos y lagos (Jobling
1995).
Los cuerpos de agua de Patagonia presentan una situación de particular interés,
puesto que se ubican en un amplio rango latitudinal, abarcando regímenes notablemente
distintos, lo que genera una gran diversidad de variantes ambientales. Albergan una
ictiofauna que reviste una considerable importancia por sus valores biogeográficos y
cómo recurso turístico (Vigliano 1997). Estos ecosistemas acuáticos se han mantenido
libres de la influencia humana hasta épocas relativamente recientes, por lo que además
comprenden focos para la conservación de la biodiversidad. Las actividades económicas
que han acompañado al aumento demográfico de las últimas décadas están cambiando
esta situación, puesto que la mayoría tiene un impacto directo o indirecto en el medio
ambiente en el que se desarrollan.
Los cuerpos de agua patagónicos, en especial los lagos andinos, son un importante
recurso natural, no sólo como reservorios de agua dulce y para la generación de energía
hidroeléctrica, sino por su valor paisajístico, que los convierte en motivo de interés
turístico. Como recurso, está fuertemente expuesto a la degradación derivada de la
sobreexplotación y el manejo incorrecto, que a su vez son consecuencia de políticas
ambientales que, incluso cuando estén bien intencionadas, suelen sufrir falencias a
causa de la falta de conocimientos adecuados acerca de la estructura de los ambientes a
manejar (Parker et al, 1999).
La ictiofauna de los lagos y ríos patagónicos es un claro ejemplo de las
complejidades implícitas en el manejo sustentable de un recurso natural. Aunque la
riqueza específica de los peces patagónicos es baja, si se la compara con la de los
ecosistemas tropicales (Ringuelet 1975), la ictiofauna comprende un ensamble muy
particular, de interés biogeográfico no sólo por sus componentes endémicos, sino por la
presencia de especies compartidas con Oceanía (como es el caso del puyen chico, G.

INFORME FINAL
maculatus, o la lamprea Geotria australis). Por otro lado, hay un número

proporcionalmente importante de especies introducidas, en particular, salmónidos
originarios del hemisferio norte, que fueron sembrados intencionalmente en numerosos
cuerpos de agua por su valor para la pesca deportiva a lo largo del siglo pasado
(Pascual, et al. 2002). El impacto que ha tenido en la ictiofauna local la introducción de
especies exóticas sigue siendo en gran medida desconocido (Pascual et al. 2002), sobre
todo porque prácticamente cada cuerpo de agua presenta una situación particular. A las
siembras intencionales, se le suman los ejemplares escapados de los centros de cría, y
los movimientos migratorios desde otras poblaciones (Temporetti et al. 2001).
Es probable que esta situación de convivencia entre una fauna nativa y otra
introducida ya no sea reversible, y aunque lo fuera, el recurso económico que
representan tanto la pesca deportiva como las pisciculturas harían inviable esta
posibilidad (Pascual et al. 1998; Vigliano 1997; Vigliano et al. 2000). Sin embargo, una
política de manejo sostenible debería contemplar tanto a especies introducidas como a
las nativas, buscando en cada caso adecuar las poblaciones de especies introducidas a la
capacidad de cada ambiente de soportarla con un impacto mínimo en los ensambles
locales (Pascual et al. 2002). Está claro que esta política de manejo sólo es posible con
un conocimiento adecuadamente fundado del funcionamiento estructural de los sistemas
acuáticos patagónicos, es decir, habiendo establecido cuáles son las principales
relaciones existentes entre los distintos componentes que los integran.
1.2- EL GRUPO DE EVALUACIÓN Y MANEJO DE RECURSOS

ICTICOS
Desde 1996, el Grupo de Evaluación y Manejo de Recursos Icticos (GEMaRI)
del Centro Regional Universitario Bariloche, ha venido realizado numerosos muestreos
en cuerpos de agua de Patagonia, en el marco de los proyectos B019-Evaluación y
Manejo de Recursos Icticos: la pesquería del lago Gutiérrez (Vigliano 1996), B920-
Programa de Recursos Acuáticos en Ambientes Patagónicos (Vigliano 1999), y B940 -
Programa de Características Ópticas, Composición Química y Comunidades Bióticas de
Ambientes Acuáticos Patagónicos (Vigliano 2005). Su trabajo ha resultado en un
enorme cúmulo de información tanto fisicoquímica como biótica. La labor del GEMaRI
ha abarcado, desde el lago Quillén (Neuquén) hasta el lago Escondido (Tierra del
Fuego), todo el rango de cuerpos de agua de la región, con estudios intensivos en
Moreno, Guillermo, Gutiérrez, y Nahuel Huapi (FIGURA 1.1).

INFORME FINAL
Esta información, registrada

en planillas de campo y laboratorio,
complementada con los datos
obtenidos de los estudios posteriores
(lectura de escamas, análisis de
contenidos estomacales, etc.), fue
almacenándose en soporte digital
empleando mayoritariamente
planillas de cálculo. Datos
ambientales registrados en el campo
(tales como mapeos de los tipos de
costa, perfiles térmicos, detalles de
muestreo, etc.) muchas veces
permanecieron en soporte físico
puesto que no existía una manera
estandarizada de incorporarlos al
resto de la información. Tras casi
una década de estudios, resultó
evidente la necesidad de reorganizar
todos estos datos de modo tal que FIGURA 1.1: Estaciones de muestreo estudiadas por
fueran fácilmente accesibles y el GEMaRI desde 1995 hasta la fecha.
comparables.
1.3- SISTEMA INTEGRAL DE INFORMACIÓN: UNA BASE DE

DATOS RELACIONAL
Dada la necesidad de encontrar una metodología que permita organizar la

información existente, para facilitar su análisis comparativo, y para acomodar la llegada
de datos nuevos, se planteó la definición de un sistema integral de información;
“Sistema” porque comprende un conjunto definible de elementos y de normas que rigen
su comportamiento, “Integral” porque su objetivo es la integración de datos de distintos
tipos y orígenes en un único conjunto, y “de Información” porque los elementos del
conjunto son los datos obtenidos a partir de los estudios de los sistemas de interés. La
herramienta a usar para crear este sistema es una base de datos que combine toda la

INFORME FINAL
información existente acomodándola en una estructura que permita facilitar su

recuperación y posibilitar su empleo en formas novedosas.
El tipo de base de datos elegido es aquel que emplea el modelo relacional (Codd
1970), y cuyas características principales se describen en el CAPÍTULO 2. Este modelo,
compuesto por tablas de datos relacionadas lógicamente entre sí, permite, a través de la
normalización de la información, cumplir con los siguientes objetivos:
Estandarización
Lograr que los tipos de datos disponibles sean comparables es un punto
fundamental para el análisis de la información. Dos conjuntos de datos pueden ser no
comparables por dos motivos básicos: 1) los datos se refieren a la misma entidad, pero
se han anotado de forma distinta (por ejemplo, una tabla de pesos en kilogramos y otra
en libras); 2) los datos refieren a mediciones distintas de un fenómeno similar (p.e., dos
tablas de tamaño, una refiriendo la longitud y otra al peso), o a fenómenos distintos
(como ser una tabla de peces capturados con redes agalleras y otra de capturas con red
de arrastre). En el primer caso, la no-comparabilidad es soluble, y requiere elegir una
misma unidad y convertir todos los datos a esa unidad. En el segundo caso, la
incompatibilidad es intrínseca, y la comparación de los datos sólo es parcialmente
posible. La estructura de la base de datos obliga a reconocer las entidades naturales de
la información y permite eliminar los problemas del tipo 1 mientras que deja explícitas
las incompatibilidades del tipo 2.
Al acomodar la información disponible para que se ajuste a la estructura de la
base de datos, se obtiene como resultado un formato estándar de almacenamiento de la
información. Este estándar asegura que datos de una misma entidad son directa e
intrínsecamente comparables entre sí. La forma estándar además influye en la toma
posterior de datos, porque permite la generación de planillas de campo con la misma
estructura de la base de datos. De este modo, se asegura la comparabilidad de la
información preexistente con los nuevos datos.
Recuperación de la información
La base de datos permite una recuperación rápida y precisa de la información
almacenada. Las salidas de la base pueden hacerse en pantalla, en forma de informes, o
como exportaciones hacia otros sistemas de procesamiento. Por ejemplo, puede
visualizarse un listado de peces capturados en un ambiente determinado, puede
imprimirse un informe que detalla las capturas por unidad de esfuerzo (CPUE) por

INFORME FINAL
especie y lago, o puede exportarse un listado de peces y el tamaño de malla de los paños
en los que fueron capturados a un programa de análisis estadístico.
Consultas relacionales: datos viejos, enfoques nuevos

Aunque la estandarización y la recuperación de información son objetivos
importantes, el verdadero valor de la base de datos relacional es su capacidad casi
ilimitada para recuperar datos de diferentes entidades relacionados entre sí. A partir de
la creación de relaciones lógicas entre las distintas entidades (tablas) de la base de datos,
es posible asociar elementos de un tipo con características de elementos de otro tipo.
Por ejemplo, la tabla de peces capturados tiene datos de especie, talla y peso de cada
pez y la tabla de características químicas de cada lago puede tener valores de salinidad y
concentración de clorofila; si uno sospechara que el crecimiento para cada especie
responde de modo diferencial a la cantidad de sales y la productividad primaria de los
ambientes, necesitaría una tabla que combinara especie, talla, peso y los parámetros
químicos mencionados. La creación de tal tabla sería un trabajo largo y tedioso de
hacerse manualmente, pero es muy simple y veloz en una base de datos relacional si
existe una tabla que diga en qué lago se pescó cada pez.
La facilidad con que pueden realizarse combinaciones novedosas de los datos es
un enorme aliciente para la exploración de nuevas ideas y preguntas, y probablemente la
mayor de las contribuciones que puede hacer este Sistema Integral de Información. Sin
embargo, como toda herramienta, está limitada a la habilidad y el ingenio de quien la
utiliza.

INFORME FINAL
2 - INTRODUCCIÓN A LAS BASES DE DATOS

2.1 - DEFINIENDO QUÉ ES UNA BASE DE DATOS
Antes de seguir adelante, es importante repasar algunos conceptos generales sobre
teoría de bases de datos, el modelo relacional, y la terminología asociada. Estos
conceptos son de gran utilidad para comprender la estructura básica del Sistema Integral
de Información, para la generación de consultas originales, y para su posterior
ampliación por integración de nuevas entidades al sistema.
Una base de datos puede definirse como conjunto de datos que pertenece a un
mismo contexto, y que se almacenan sistemáticamente para su uso posterior. Según esta
definición amplia del término numerosas colecciones de información son bases de
datos, tales como las bibliotecas, los registros que mantienen numerosas instituciones
acerca de individuos, sucesos o decisiones, o la correspondencia epistolar guardada en
una caja. También entra en este contexto una serie de dispositivos de almacenamiento
(cintas, disquetes, discos rígidos, CDs o DVDs) que contienen registros en formato
dispar acerca de las actividades de un grupo de investigación.
Sin embargo, al referirnos a una base de datos, probablemente estamos pensando
en un conjunto bastante más organizado. El concepto de organización también tiene
múltiples aristas, pero podemos pensar que el nivel de orden deseado está relacionado
con la facilidad para recuperar la información almacenada. Si el sistema de
almacenamiento de los datos está orientado a la recuperación de la información, los
tiempos de búsqueda disminuyen enormemente. Como ejemplo hipotético, podemos
pensar una colección de artículos científicos reunidos a lo largo de su carrera por un
viejo investigador. Este hombre trabajó en diversos campos de su disciplina de estudio,
abocado en numerosos proyectos; los artículos que obtenía de sus colegas o de las
hemerotecas, los iba almacenando en cajas, en orden de llegada, discriminando
solamente aquellos leídos de aquellos por leer. Su memoria extraordinaria le permitía
recordar donde estaba cada artículo cuando alguno de sus tesistas se lo solicitaba. Sin
embargo, tras su muerte, quienes heredaron su colección se encontraron con que era
prácticamente imposible encontrar cualquier artículo particular sin repasar cajas y cajas
de papeles polvorientos. La información existía y estaba disponible, pero al carecer de
un almacenamiento sistematizado, la recuperación de la misma era un dolor de cabeza.
Finalmente, uno de sus tesistas se cansó de tener ese cúmulo de bibliografía

INFORME FINAL
inutilizable, y se abocó a la tarea de reorganizar todos los artículos. Estableció una

jerarquía temática dividiendo primero las principales disciplinas, y dentro de ellas, los
campos más específicos de estudio (por ejemplo, dividiendo las disciplinas de la
Biología en Ecología, Fisiología, Biología Molecular, Genética, etc.; a su vez, dentro de
Ecología podía haber distintos campos, tales como Limnología, Ecología de
Poblaciones, Ecología de Comunidades Terrestres, y así). Luego, rotuló cajas nuevas y
clasificó cada artículo en una de esas cajas. Tras un arduo trabajo, el trabajo del tesista
permitió que la información fuese más fácilmente accesible, y por lo tanto, mucho más
útil.
Aún así, algunos problemas persistían. A veces, ciertos trabajos
multidisciplinarios debían buscarse en más de una caja; otras ocurría que se tenía datos
de los autores de un trabajo, pero no se conocía bien la disciplina. Así que un tesista
más joven, pese a las quejas de su predecesor, decidió volver a organizar la colección. Y
esta vez adoptó un enfoque distinto (y más moderno): asignó un número de orden a cada
artículo, y anotó en una lista sus autores, el título, año y revista de publicación, y una
lista de palabras clave que identificaban contenidos fundamentales del artículo. Luego
elaboró una serie de índices en los que listaba alfabéticamente cada uno de estos datos,
y decía el número del artículo. Un trabajo inmenso sin lugar a dudas, y por el cual
soportó numerosas fricciones con sus colegas más viejos, quienes ya sabían donde
encontrar las cosas con el sistema viejo y estaban terriblemente perdidos con la
reorganización. Sin embargo, la velocidad de recuperación de la información era
muchísimo mayor que en el sistema viejo, y el tesista se encontró satisfecho. Había
construido una base de datos sistemática de la información almacenada por el viejo
investigador, de modo tal que el acceso a la misma fuera mucho más rápido y sencillo,
lo que la hacía muchísimo más útil que en su estado original.
El relato hipotético es una analogía adecuada para describir los distintos tipos de
base de datos, y de su valor relativo a la capacidad de recuperar información. Muestra
que hay más de una manera de almacenar la información, y más de una manera de
acceder a ella. Por último, da un ejemplo bastante simple del empleo de índices para
acelerar la recuperación de los datos.
2.2- MODELOS DE BASES DE DATOS

Un modelo de datos es básicamente una "descripción" de algo conocido como

INFORME FINAL
contenedor de datos (algo en donde se guarda la información), así como de los métodos
para almacenar y recuperar información de esos contenedores. Los modelos de datos no
son entidades físicas, sino abstracciones que permiten la implementación de un sistema
eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos
matemáticos.
Los modelos de bases de datos han ido evolucionando con el tiempo, y su
desarrollo ha sido un área activa de investigación desde el inicio de la era informática.
Un breve repaso por los principales modelos permite ver las ventajas y desventajas de
cada uno.
2.2.1- Bases de datos de archivo plano
En su forma más simple, una base de datos de archivo plano no es más que una
enorme tabla única (por ejemplo, una planilla de cálculo). Existe una única estructura de
registros, y no hay vínculos entre registros separados. El acceso a los datos se hace de
modo secuencial (se lee la información en su orden de almacenamiento); el acceso
aleatorio no tiene soporte. Esto implica que los tiempos de acceso son lentos, porque
debe repasarse el archivo completo para encontrar los datos localizados. Esto se
soluciona parcialmente si se hacen ordenamientos de los datos, pero una reordenación
mal hecha puede causar errores graves (como la mezcla de campos y registros).
Este modelo de base de datos es el más primitivo de los formatos digitales, y
además de los inconvenientes mencionados, también adolece de problemas relacionados
con la redundancia de los datos, su mantenimiento y su integridad. Aunque se lo supone
obsoleto para la mayoría de los bancos de datos modernos, es un formato muy popular
para el almacenamiento de información por parte de personas sin conocimientos sobre
otros tipos de modelos. De hecho, la mayoría de la información de campañas de campo
y laboratorio del GEMaRI se encontraba en ese formato al inicio de este trabajo
(CAPÍTULO 3).
2.2.2- Bases de datos jerárquicas
Son bases de datos que, como su nombre indica, almacenan su información en una
estructura jerárquica. En este modelo los datos se organizan en una forma similar a un
árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos.
El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los

INFORME FINAL
conoce como hojas. Un registro de la base consiste en uno o más agrupamientos de

campos denominados segmentos. Los segmentos componen los nodos individuales del
árbol. El modelo exige que cada segmento hijo esté vinculado a un único padre, y cada
hijo solo puede ser alcanzado a través de su padre. Este requisito puede resultar en
información redundante. Para resolver ese problema, la información se almacena en un
único sitio y es referenciada mediante vínculos o punteros físicos en otros sitios. Los
vínculos establecidos por los punteros son permanentes, y no pueden ser modificados,
por lo que se genera un modelo muy inflexible: un diseño optimizado para trabajar los
datos de un modo determinado puede ser totalmente ineficaz a la hora de trabajar los
datos de un modo muy distinto. Además, los vínculos físicos hacen muy difícil expandir
o modificar la base de datos sin un esfuerzo substancial de re-escritura.
2.2.3- Bases de datos reticulares
Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental

es la modificación del concepto de nodo: se permite que un mismo nodo tenga varios
padres (posibilidad no permitida en el modelo jerárquico). Fue una gran mejora con
respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de
redundancia de datos; pero, aun así, la dificultad que significa administrar la
información en una base de datos de red ha significado que sea un modelo utilizado en
su mayoría por programadores más que por usuarios finales. Puesto que actualmente el
modelo relacional (ver más abajo) ofrece la misma flexibilidad que el modelo reticular
sin sus dificultades, se lo considera obsoleto.
2.2.4- Bases de datos relacionales
Éste es el modelo más utilizado en la actualidad para modelar problemas reales y

administrar datos dinámicamente. Sus fundamentos fueron formulados por Codd (1970)
de los laboratorios IBM en San José (California), y no tardó en consolidarse como un
nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de
"relaciones", definidas originalmente en forma lógica como conjuntos de datos llamados
"tuplas". Visto de una manera más simple, una base de datos relacional consiste en un
conjunto de tablas, cada una de las cuales está compuesta por registros (las filas de una

INFORME FINAL
tabla), que representarían las tuplas, y campos (las columnas de una tabla). Las tablas se
relacionan entre sí a través de relaciones establecidas entre elementos de los campos de
cada tabla. Durante su diseño, una base de datos relacional pasa por un proceso al que
se le conoce como normalización de una base de datos, que intenta eliminar por
completo la redundancia de datos y acelerar los procesos de recuperación de la
información.
En este modelo, el lugar y la forma en que se almacenen los datos no tienen
relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la
considerable ventaja de que es más fácil de entender y de utilizar para un usuario
esporádico de la base de datos. La información puede ser recuperada o almacenada
mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la
información.
El modelo relacional se discute en detalle más abajo, puesto que es el modelo
elegido para estructurar el Sistema Integral de Información que es el núcleo de este
trabajo.
2.2.5- Bases de datos orientadas a objetos
El modelo orientado a objetos apunta a solucionar la principal limitación de las

bases de datos relacionales actuales, que es su capacidad limitada para tratar con
Grandes Objetos Binarios (GOBs). Los GOBs son tipos de datos complejos tales como
imágenes, planillas de cálculo, documentos, mensajes de correo electrónico y
estructuras de directorios. Estos datos no son “atómicos”; tienen partes y sub-partes que
no son fácilmente representables dentro del modelo relacional. Puesto que no posee
mecanismos específicos para recuperar GOBs, los mismos se almacenan por fuera de la
base de datos, y son referenciados por punteros. Esto soluciona el problema de la
recuperación, pero la manipulación de de los GOBs mismos debe hacerse con métodos
externos al administrador de la base.
El modelo de base de datos orientada a objetos, bastante reciente, y propio de los
modelos informáticos orientados a objetos, soluciona esta falencia del modelo relacional
al almacenar en la base de datos los objetos completos (estado y comportamiento). Cada
objeto es asignado a una categoría, y tiene un conjunto de propiedades y
comportamientos (métodos) que pueden ser manipulados. La noción jerárquica de
categorías y sub-categorías reemplaza el concepto de tipos de datos atómicos de las
bases relacionales, y provee un enfoque natural para representar las jerarquías presentes

INFORME FINAL
en los datos complejos típicos de los GOBs.

Una base de datos orientada a objetos es una base de datos que incorpora todos los
conceptos importantes de la programación orientada a objetos:
• Encapsulación - Ocultar datos del resto de los datos, impidiendo así accesos
incorrectos o conflictos.
• Herencia - Reusabilidad del código.
• Polimorfismo - Sobrecarga de operadores o de métodos.
2.3- CARACTERÍSTICAS DE LAS BASES DE DATOS

RELACIONALES
A partir de los modelos descritos sucintamente en la sección previa, la selección

del modelo relacional para la construcción del Sistema Integral de Información (SII) es
la más adecuada por los siguientes motivos:
- Es el modelo más similar al formato de la mayor parte de los datos de base
disponibles. Esto permite no sólo reducir el tiempo necesario para la adaptación a la
nueva estructura, sino que además resulta una aproximación más cercana a la naturaleza
de los datos.
- Es un modelo suficientemente flexible como para aceptar el agregado de nuevos
tipos de datos (además de nuevos registros) sin una alteración de la estructura
preexistente. Dicho de otro modo, el modelo relacional es fácilmente expandible.
- Pese a ser el modelo más empleado en la actualidad y contar con numerosos
paquetes de software de administración de bases de datos (database management
systems; DBMSs) que se basan en él, el diseño estructural básico es independiente de la
implementación, lo que permite una migración relativamente sencilla entre distintos
DBMSs.
2.3.1- Términos básicos y definiciones
Una base de datos relacional puede caracterizarse como un conjunto de tablas

relacionadas entre sí por valores comunes. Es decir que las dos características más
evidentes del modelo son que 1) los datos se almacenan en tablas, y 2) existen
relaciones definidas entre las tablas.
Una tabla, también denominada entidad, es un conjunto de filas y columnas. Una

INFORME FINAL
fila representa un registro (o tupla) con una serie de datos acerca de un elemento. Una
columna (denominada campo o atributo) representa una característica particular de los
elementos de la tabla. Una relación es un vínculo lógico entre dos tablas. Un sistema
relacional de administración de bases de datos (RDBMS) emplea valores coincidentes
en múltiples tablas para relacionar la información de una tabla con la información en
otra.
Típicamente, las tablas reflejan entidades reales y naturales; es decir, contienen
información sobre un conjunto de elementos existentes, por ejemplo, personas, peces
capturados, lagos, o campañas de muestreo. Del mismo modo, muchos los campos
reflejan atributos reales de esos elementos. Sin embargo, existen también campos cuya
función es proveer una identificación unívoca a cada elemento de la tabla, o establecer
FIGURA 2.1: Elementos básicos de la tabla de una base de datos relacional. Un ejemplo de la tabla
CAPTURAS que muestra cómo se almacena y como se busca el largo total (LT) del pez capturado nº 7
(ID_Pez). LT es un campo o atributo, en forma de columna, mientras que el pez conforma un registro
que se muestra como fila. La intersección entre la fila y la columna conforma el valor de dato.

INFORME FINAL
relaciones con otras tablas. En algunos casos, una tabla completa puede estar
conformada sólo por esos campos relacionales, como es en el caso de las relaciones
varios-a-varios (ver más abajo). Cabe aclarar que la presentación de la información en
tablas es una construcción lógica, independiente del modo en que los datos son
almacenados físicamente en un soporte magnético o digital.
Como ejemplo, usaremos una de las tablas centrales del SII que es la tabla de
peces capturados (CAPTURAS; FIGURA 2.1). Esta entidad almacena la información básica
acerca de los ejemplares capturados usando redes agalleras desde el año 1995 a la fecha.
Cada pescado tiene un registro, es decir, está representado por una fila de la tabla. Una
serie de atributos refieren a datos observados sobre cada uno de los peces: su especie,
largo, peso, sexo, etcétera. Estos campos, presentes en las planillas de campo,
conforman un conjunto natural: se refieren a la información que se toma de cada pez
inmediatamente tras su captura. Otras columnas de la tabla contienen los identificadores
de campo y el identificador de la base de datos. Un campo identifica el paño de red (que
indica tren y tamaño de malla) en que fue capturado el pez, y otro hace referencia al
calado de ese paño. Este calado es un elemento (registro) de otra tabla, la tabla de
calados (CALADOS), que conforma una entidad natural distinta. La referencia en la tabla
de capturas a la tabla de calados es el vínculo que permite recuperar información de
ambas tablas, y es la relación que define el modelo de base de datos.
2.3.2- Las reglas de Codd
Una base de datos relacional (BDR) va más allá de información organizada en

tablas relacionadas. El modelo original tiene un firme basamento en las teorías
matemáticas de álgebra y cálculo relacional, y fue propuesto por Codd en 1970. Codd
definió posteriormente un conjunto de 12 reglas que un DBMS debe cumplir para ser
considerado un RDBMS, que se resumen a continuación:
Regla de Codd nº 1: la información se presenta en tablas.

La base de datos consiste en un conjunto de tablas interrelacionadas, y toda la
información se representa como tablas; no hay otra manera de visualizar los datos.
Una tabla es un agrupamiento lógico de datos relacionados en forma tabular (filas y
columnas). Cada fila describe un elemento y cada fila contiene información acerca de

INFORME FINAL
un único elemento en la tabla. Cada columna describe una única característica acerca de
un elemento. Cada valor, o dato, está definido por la intersección de una fila y una
columna. Los datos son atómicos; no hay más de un valor asociado con la intersección
de una fila y una columna. Las tablas no tienen un ordenamiento jerárquico, y las
relaciones entre ellas son lógicas: no existen relaciones físicas entre tablas.
Regla de Codd nº2: los datos son accesibles lógicamente

Una BDR no referencia datos por su localización física; no existe tal cosa como la
“quinta fila en la tabla de capturas”. Cada valor debe ser accesible lógicamente haciendo
referencia a 1) una tabla, 2) un valor clave principal o único, y 3) una columna. Por
ejemplo, un paño de red particular (2450) y la información sobre sus características
(tamaño de malla, superficie, tren que integra) se almacena en una fila (registro) de la
tabla PANIOS. La superficie es una columna (campo) de esa tabla. La cantidad 12.5 m2
es un valor de datos. La superficie del paño 2450 puede recuperarse refiriendo a la tabla
PANIOS, la columna Superficie y un valor clave único, en este caso, 2450.
Regla de Codd nº3: los datos nulos son tratados uniformemente como
desconocidos
Un dato nulo (null) siempre debe interpretarse como valor desconocido. Null
significa que no se ha ingresado ningún valor; el valor no es conocido. Null no es lo
mismo que cero o una cadena vacía (“”). Como analogía, la ausencia del dato de edad
por otolitos de un pez capturado sin cabeza no implica ni que el pez carecía de otolitos
cuando estaba vivo, ni que su edad sea 0. Si no son manejados adecuadamente, los
valores nulos pueden causar confusión en la base de datos. Estos valores se propagan a
través de las expresiones aritméticas (p.e., Null +2 = Null). La comparación de un valor
nulo contra cualquier otro valor, incluyendo a él mismo, devuelve un valor nulo.
Regla de Codd nº4: la base de datos es auto-descriptiva.

Además de la información del usuario, una BDR contiene datos sobre sí misma.
Hay dos tipos de tablas en un RDBMS: tablas del usuario, que contienen los datos de
“trabajo”, y tablas de sistema, que contienen información sobre la estructura de la base
de datos. La información que describe la estructura de la base e incluye la definición de
los objetos (tablas, índices, procedimientos almacenados, etc.) y como se
interrelacionan se denomina metadatos. El conjunto de tablas del sistema también se

INFORME FINAL
denomina catálogo del sistema o diccionario de datos. Las tablas del sistema pueden
accederse del mismo modo que las tablas de usuario.
Regla de Codd nº5: un único lenguaje se usa para comunicarse con el

DBMS
Debe haber un único lenguaje que maneje todas las comunicaciones con el
DBMS. Tal lenguaje debe soportar operaciones relacionales referidas a la modificación
de datos (SELECT, INSERT, UPDATE, DELETE), definición de datos (CREATE,
ALTER, DROP) y administración (GRANT, REVOKE, DENY, BACKUP,
RESTORE). El lenguaje estándar de facto es el SQL (Structured Query Language, o
Sistema de Consulta Estructurada). SQL es un lenguaje declarativo o no procedimental,
en el sentido de que permite a los usuarios explicitar qué quieren del RDBMS sin
necesidad de especificar los detalles acerca de dónde está la base ni cómo se accede a
los datos.
Regla de Codd nº6: se proveen alternativas para visualizar los datos

Una BDR no debe limitarse a las tablas originales cuando presenta datos al
usuario. Las vistas (o consultas) son tablas virtuales, o abstracciones de las tablas
originales, que proveen un modo alternativo de mirar los datos de una o más tablas. La
definición de las vistas no duplica la información; una vista no es una copia de los datos
de las otras tablas. Una vez creada, una vista puede manipularse del mismo modo que
una tabla fuente; si se cambian los valores en la vista, también se alteran los valores de
la tabla. Las vistas simplifican el acceso a los datos mediante uniones complejas
predefinidas; permiten crear “tablas personalizadas” con objetivos específicos, y recrear
las tablas de base tras el proceso de normalización (ver más abajo).
Regla de Codd nº7: las operaciones de conjuntos o relacionales deben

ser soportadas
La BDR debe soportar operaciones básicas de álgebra relacional (selección,
proyección y junción) y operaciones de conjuntos (unión, intersección, división y
diferencia). Estas operaciones se usan para producir relaciones a partir de tablas. Las
filas son tratadas como conjuntos para las operaciones de manipulación de datos. Una
base de datos que sólo permite operaciones de una fila por vez (navegacionales) no
cumple este requisito y no puede considerarse relacional.

INFORME FINAL
Regla de Codd nº8: independencia física de los datos

Las aplicaciones que acceden a la información en una DBR no deben ser
afectadas por cambios en la manera en que se almacenan físicamente los datos.
Tampoco necesita conocer como esa información es físicamente almacenada o
alcanzada.
Regla de Codd nº9: independencia lógica de los datos

La independencia lógica significa que las relaciones entre las tablas puede
cambiar sin impedir el funcionamiento de las aplicaciones o de las consultas ad hoc.
Así, el esquema de la base o la estructura de las tablas y relaciones lógicas pueden
cambiar sin necesidad de re-crear la base o la aplicación que la utiliza.
Regla de Codd nº10: la integridad de la información es una función

del DBMS
Para ser considerado relacional, el DBMS debe incorporar la integridad de los
datos como una función interna, y no delegarla en una aplicación externa. La integridad
de los datos se refiere a la consistencia y la precisión de la información en la base.
Existen tres tipos de integridad de datos: de entidad, de dominio y referencial. Dentro de
la BD, la integridad puede aplicarse con procedimientos o de manera declarativa. En el
primer caso, se hace mediante código; en el segundo, se logra colocando o declarando
limitaciones a las columnas.
Regla de Codd nº11: existe soporte para la operación distribuida

La información de una BDR puede almacenarse de modo centralizado o
distribuido. Los usuarios pueden juntar datos de tablas en diferentes servidores
(consultas distribuidas) o desde otras BDRs (consultas heterogéneas). La integridad de
los datos debe mantenerse sin importar el número de copias de la información o dónde
se aloje.
Regla de Codd nº12: la integridad de los datos no puede ser subvertida

No puede haber otros caminos a la base de datos que subviertan la integridad de
los datos; dicho de otro modo, no es posible meterse por la “puerta trasera” y cambiar
los datos de un modo tal que viole la integridad de los datos.

INFORME FINAL
2.4- RELACIONES
2.4.1- Características básicas.
En una BDR, todos los datos están organizados en tablas, las cuales se vinculan
entre sí mediante relaciones. Una relación es un vínculo lógico entre dos entidades
(tablas) que describen de qué modo se asocia cada una con la otra. Las relaciones se
usan para implementar la integridad de los datos, y para facilitar las junciones al proveer
acceso a múltiples tablas al mismo tiempo.
Una relación se representa por valores de datos comunes almacenados en dos
tablas distintas. Por ejemplo, es posible saber las características de la red en la que se
capturó un pez dado porque tanto en la tabla CAPTURAS como en la tabla REDES hay un
campo común ID_Red. Por otro lado, el campo ID_Calado de la tabla CAPTURAS se
comparte con la tabla CALADOS, permitiendo asociar a cada pez un sitio, fecha y
esfuerzo de captura.
Típicamente, una relación se establece entre un campo con atributos codificables
de una tabla y un campo de identificadores de la otra. El campo Sexo de la tabla
CAPTURAS contiene valores de 0, 1, 2 o -99. Este campo se relaciona al campo ID_Sexo
de la tabla SEXOS_DESC, que contiene la siguiente información:
ID_Sexo Descripción
0 Indefinido
1 Hembra
2 Macho
-99 Valor nulo/Sin datos
Al realizar la junción de ambas tablas, es posible recuperar la descripción del sexo

para cada pez. Nótese que Indefinido no es lo mismo que “nulo”, puesto que en el
primer caso se trata de un pez con un desarrollo gonadal insuficiente para distinguir su
sexo, mientras que en el segundo caso, no hay datos acerca de sus gónadas (porque el
pez no se diseccionó o porque el dato se perdió). En este ejemplo, la tabla SEXOS_DESC
es denominada madre, y la tabla CAPTURAS es la tabla hija.
Los campos comunes que relacionan dos tablas son denominados claves. A veces,
la clave puede consistir en más de un campo, en cuyo caso se la conoce como clave
compuesta. El campo que identifica unívocamente cada registro de la tabla madre se

INFORME FINAL
denomina clave primaria o principal. La clave primaria no solo evita que existan
columnas duplicadas, sino que además provee un mecanismo que permite referirse a
todos los atributos de un registro específico simplemente referenciando un único valor
numérico. Esta clave típicamente consta de valores numéricos pequeños, de modo que
sea fácil de ordenar, almacenar y buscar. El campo de la tabla hija que contiene los
valores relacionados a la clave primaria de la tabla madre se denomina clave externa;
esta clave hereda la clave principal materna, y la combinación de claves primaria y
externa establece la relación entre ambas tablas.
La cardinalidad de una relación define cuantas instancias de cada entidad pueden
interrelacionarse. Existen tres tipos primarios de cardinalidad: uno-a-uno, uno-a-varios
y varios-a varios. Además, es posible establecer relaciones recursivas o reflexivas, en
las que una tabla se vincula consigo misma a través de dos de sus campos. Las
relaciones entre tablas suelen representarse gráficamente usando diagramas de
relaciones de entidades (DREs; FIGURA 2.2).
Al diseñar la base de datos, se considera una entidad a cualquier cosa que

contribuya al área de información que se desea abarcar y que pueda ser descripta en
FIGURA 2.2: Diagrama de Relaciones de Entidades (DRE) del Sistema Integral de Información. Las
relaciones se señalan como líneas que unen las claves externa y principal. En los casos en los que se
ha impuesto la integridad referencial, puede verse la cardinalidad de la relación mediante los símbolos
1 y ∞.

INFORME FINAL
términos de datos accesibles. Las relaciones entre estas entidades son lógicas y no
físicas, y se definen como el vínculo entre la clave principal de la tabla madre con la
clave externa de la tabla hija. Por tanto, la relación se crea almacenando el valor de la
clave primaria materna en el campo de clave externa de la hija. Una clave externa debe
hacer referencia a un campo de otra tabla, y dicho campo debe o bien ser la clave
principal de esa tabla, o ser unívoca (es decir, no puede tener el mismo valor asignado a
más de un registro). Por lo tanto, una clave externa puede implementar una relación
uno-a-uno o varios-a-uno, pero no uno-a-varios.
2.4.2- Uno-a-varios (1-N o 1→∞)
Esta relación es la que se da cuando se cumple que una instancia de la entidad

materna se asocia con 0 o más instancias de la entidad hija. La relación uno-a-varios es
el tipo más común de relación. Un ejemplo de este tipo de relación es la que se da entre
la tabla ESPECIES (madre) y la tabla CAPTURAS (hija): para cada especie se pueden haber
realizado muchas capturas, pero cada pez capturado tiene una sola especie. La
implementación de esta especie se logra agregando en la tabla CAPTURAS un campo
ID_Especie referido a la clave principal de la tabla ESPECIES.
2.4.3- Varios-a-varios (N-N o ∞→∞)
En este tipo de relación, varias instancias de una entidad se asocian con varias
instancias de otra entidad. Un ejemplo sería la relación entre especies y lagos: una
especie puede estar en más de un lago, y a su vez, cada lago puede tener más de una
especie. Este tipo de relación no puede establecerse directamente entre las dos tablas,
sino que requiere una tabla de junción que se usa como intermediaria. Esta tabla
contiene una clave primaria compuesta que consiste en dos o más campos, que también
funcionan como claves externas, y en la que cada registro representa una de las
combinaciones posibles (por ejemplo, un par ei;lj representando la presencia de la
especie i en el lago j). Es decir que la relación varios-a-varios se logra mediante la
combinación de dos relaciones uno-a-varios vinculadas mediante la tabla de junción.
2.4.4- Uno-a-uno (1-1 o 1→1 )
En la relación uno-a-uno, una instancia de la entidad se asocia con una única

INFORME FINAL
instancia de otra entidad. Este tipo de relación no es muy común, y para su uso debería
evaluarse por qué no resulta más conveniente usar una tabla más grande. En algunos
casos, se trata de una cuestión de seguridad: la información más delicada es dejada en
otra tabla sobre la cual pueden pesar mayores controles de seguridad. Otras veces, se
intenta mejorar el desempeño del DBMS separando campos que contienen tipos de
datos grandes y son infrecuentemente consultados. También puede usarse cuando
existen numerosos valores nulos, o cuando se trata de datos que se obtienen mucho más
tarde (por ejemplo, la edad estimada de un pez a partir de otolitos o escamas, o su
secuencia de ADNm).
2.4.5- Recursivas
Cuando un campo de una tabla hace referencia a otro campo de esa misma tabla,
se considera que esta relación de la tabla consigo misma es recursiva. La creación de
una relación recursiva se logra mediante una auto-junción. Un ejemplo sería una tabla
que refleja las relaciones hidrográficas de los lagos, indicando por ejemplo que el lago i
drena sus aguas en el lago j.
2.5- INTEGRIDAD DE DATOS

La integridad de datos es un término amplio que se refiere a la consistencia,
precisión y corrección de la información almacenada en una base de datos. No tiene que
ver con la seguridad física, la tolerancia a fallas o la preservación de la información
(copias de respaldo).
Existen cuatro tipos primarios de integridad de datos: de entidad, de dominio,
referencial y definida por el usuario. La integridad puede implementarse a nivel de la
base de datos, o en una aplicación externa. En general, es preferible la primera opción,
puesto que ahorra tiempo de programación en la aplicación, y asegura que defectos
externos a la base de datos amenacen la integridad.
La integridad de entidad especifica que cada fila en la tabla esté identificada
unívocamente, es decir, que no existan filas duplicadas. Este tipo es fundamental para el
modelo relacional: puesto que los datos son independientes del almacenamiento físico
gracias a la posibilidad de referenciar cada registro por el valor de su clave principal, es
necesario que sólo exista un registro por cada valor de la clave. El uso de claves
principales es el método más común para implementar la integridad de entidad; un

INFORME FINAL
registro no puede tener un valor de la clave igual a un valor preexistente, y tampoco

puede tener un valor nulo.
Cuando existe un dato real que puede ser usado como clave principal (por
ejemplo, el número de documento de una persona), entonces se la denomina clave
inteligente. Si el valor de la clave principal no refleja ningún dato real excepto su
identificador único, se la denomina clave substituta.
Aunque a veces es posible que haya más de un campo para el cual se puede
imponer la restricción a los valores duplicados, sólo puede haber una única clave
principal por tabla. Los otros campos con valores sin duplicados a menudo son
denominados claves alternativas, y son buenos candidatos para realizar indexados o
junciones.
La integridad de dominio exige que un conjunto de valores de datos caigan
dentro de un rango específico (dominio) para ser considerados válidos. Dicho de otra
manera, la integridad de dominio define los ingresos permisibles para un campo dado al
restringir el tipo de datos, el formato o el rango de valores posibles. Por ejemplo, puede
especificarse que el dominio del campo Peso sea un valor entero (expresado en gramos)
y positivo.
La integridad referencial se ocupa de mantener sincronizadas las relaciones
entre las tablas. Se implementa mediante una combinación de clave principal y clave
externa, de modo tal que la clave externa en la tabla hija sólo pueda aceptar valores que
existan en la clave principal de la tabla madre. El objetivo principal de la integridad
referencial es prevenir la aparición de “huérfanos”: registros en la tabla hija que no
pueden ser relacionados a ningún registro de la tabla madre. Su implementación asegura
que las relaciones entre las tablas se preserven cuando se añaden, modifican o borran
registros. Las tres aproximaciones fundamentales a la integridad referencial son: 1)
restringir, no permitiendo la modificación de datos; 2) extender en cascada a las tablas
relacionadas la modificación de los datos, y 3) anular, es decir, fijar los valores de las
claves externas coincidentes a “nulo”.
Por último, la integridad definida por el usuario abarca todas las reglas no
cubiertas por las categorías anteriores, típicamente implementadas mediante
disparadores y procedimientos almacenados.
2.6- LAS FORMAS NORMALES: OPTIMIZANDO EL DISEÑO

2.6.1- Fundamentos

INFORME FINAL
Un buen diseño de una base de datos implica, entre otras cosas, un mejor
almacenamiento y uso de la información (Prague and Irwin 2001). El proceso de
optimización de una BDR es conocido como normalización, y fue propuesto por Codd
(1972). Este autor propuso que una persona debería tomar el esquema relacional (el
sistema de tablas que se interrelacionan) y hacerlo pasar a través de una serie de pruebas
para “certificar” su concordancia con una determinada forma normal. Codd propuso tres
formas normales, que denominó primera, segunda y tercera forma normal.
Posteriormente, y junto con M. Boyce, creó una definición más fuerte conocida como
forma normal de Boyce-Codd o BCNF (Date & Fagin 1992). Más adelante, ambos
añadieron dos formas normales más (cuarta y quinta).
Estas formas normales se basan en las dependencias funcionales de los campos
dentro de una tabla, y como se interrelacionan con las otras tablas del esquema
relacional. Una dependencia funcional es una conexión entre uno o más atributos. Por
ejemplo, si conocemos la FechaMuestreo de un muestreo podemos determinar el
AñoCampaña al que pertenece. En este caso, FechaMuestreo es denominado
determinante, y se puede decir o bien que FechaMuestreo determina a AñoCampaña o
que AñoCampaña es funcionalmente dependiente de FechaMuestreo. Dicho de un
modo más general, un campo Y es funcionalmente dependiente de un campo (o campos)
X si un valor dado de X siempre debe aparecer con el mismo valor de Y. Si X es una
clave de la tabla, entonces todos los demás campos son funcionalmente independientes
de X por definición de un modo trivial, puesto que no puede haber dos registros que
tengan el mismo valor de una clave. Una extensión es la dependencia funcional
transitiva, que ocurre cuando un atributo Y que depende funcionalmente de otro X es a
su vez determinante de un tercero Z. Las dependencias funcionales sólo existen cuando
los elementos involucrados tienen valores únicos e identificadores singulares; p.e., una
tabla con nombres de personas y direcciones no cumple necesariamente con esta
condición, ya que un nombre puede representar a más de una persona (tocayos).
Los motivos para realizar la normalización de la base de datos son principalmente
dos:
Eliminar la información redundante: la repetición de los datos ingresados (en
general, nombres, descripciones y otras cadenas de texto) genera dos inconvenientes.
Por un lado, consume más espacio de almacenamiento y recursos. Por el otro, el ingreso
repetitivo de la información es un proceso sensible a errores tipográficos.
Problemas de escalabilidad imprevistos: la base de datos tiende a crecer y

INFORME FINAL
cobrar vida propia tras su creación. Si las tablas no están normalizadas, se corre el
riesgo de generar estructuras rígidas que no admiten fácilmente un cambio en la forma
de ingreso de la información. Por ejemplo, supongamos que para determinar la edad de
un pez se leen solamente dos escamas, así que se colocan dos campos en la tabla de
peces, uno para cada escama; si más adelante se decide emplear más o menos escamas
(o ambas cosas, para especies distintas), es necesario modificar toda la tabla, y
posiblemente los procedimientos almacenados que dependen de ella.
2.6.2- Primera Forma Normal (1FN)

La primera forma normal exige que los valores de los datos sean atómicos; esto
quiere decir que no puede haber una lista de datos en la intersección entre una fila y una
columna. Una tabla de lagos con un atributo Especies_Presentes en el que cada valor
lista una o más especies no se conformaría a la 1FN. Otro requisito es que un registro no
puede tener un número variable de atributos. El modelo relacional no admite tablas con
un número variable de campos entre registros.
2.6.3- Segunda forma normal (2FN)

Para que una tabla se conforme a la 2FN, todos los valores de datos deben ser
completamente dependientes de su clave primaria. Esta especificación es trivial cuando
la clave primaria es simple, es decir, cuando consta de un solo campo. Sin embargo,
cuando se emplea una clave compuesta, es requisito para la 2FN que ningún atributo
que no forme parte de la clave sea funcionalmente dependiente de otro atributo que
conforme un subconjunto de una clave candidata. Una tabla está en 2FN si y sólo si está
en 1FN y cada atributo no-clave es irreduciblemente dependiente de la clave principal
(por lo tanto, no parcialmente dependiente en una clave candidata).
Dicho de un modo más simple, la 2FN requiere una clave única: una columna de
valores que identifique unívocamente cada fila en la tabla. Si se emplea una clave
principal simple (conformada por un único campo) y la tabla cumple al 1FN, entonces
cumple la 2FN.
Para transformar una tabla 1FN en 2FN se deben seguir los siguientes pasos:
1. Identificar cualquier determinante que no sea la clave compuesta, y las
columnas que determina.
2. Crear y denominar una nueva tabla para cada determinante y las
columnas que determina.

INFORME FINAL
3. Mover las columnas determinadas de la tabla original a la tabla nueva. El

determinante se transforma en clave principal de la nueva tabla.
4. Borrar las columnas recién movidas de la tabla original, a excepción del
determinante, que pasará a funcionar como clave externa.
5. Renombrar la tabla original para mantener el significado semántico.
6. Establecer una relación entre la clave externa (determinante) de la tabla
original renombrada y la clave principal de la nueva tabla.
2.6.4- Tercera forma normal (3FN)

La conformidad con la 3FN especifica que ningún atributo no-clave puede tener
dependencias funcionales no-triviales de algo que no sea un superconjunto de una clave
candidata. Una tabla está en 3FN si ninguno de los atributos que no forman parte de la
clave principal es un hecho acerca de otro atributo que tampoco forma parte de la clave.
Dicho de otra manera, todos los atributos no-clave deben ser mutuamente
independientes (es decir, no debe haber dependencias transitivas). Además, la tabla
debe estar en 2FN.
Para transformar una tabla a la 3FN se pueden seguir pasos similares a los
descriptos para la 2FN, identificando las dependencias transitivas entre campos.
2.6.5- Forma normal de Boyce-Codd (BCFN)

Una tabla se considera conforme a la BCFN si y sólo si está en 3FN y cada
dependencia funcional (irreducible y no trivial) tiene una clave candidata como
determinante. Dicho de otra manera, es necesario que, además de conformarse a la 3FN,
todos los determinantes sean claves candidatas.
2.6.6- Cuarta forma normal (4FN)

Para conformarse a la 4FN, debe satisfacerse la BCFN, y un tipo de registro no
debería contener dos o más hechos multi-valor independientes acerca de una entidad.
Por ejemplo, una especie dada en un ambiente puede tener múltiples predadores y
múltiples presas. En este caso, se observan dos relaciones varios-a-varios: una entre la
especie y sus predadores y otra entre la especie y sus presas. Por lo tanto, deberían
crearse dos tablas distintas, en la que el campo Especie sea la clave principal y
Predador sea atributo de la primera tabla, y Presa atributo de la segunda. Es importante

INFORME FINAL
que los dos atributos que se están separando sean independientes. En el ejemplo,
Predador y Presa son independientes entre sí.
2.6.7- Quinta forma normal (5FN)

La 5FN se ocupa de casos en los que la información puede reconstruirse a partir
de fragmentos más pequeños de información que pueden mantenerse con menor
redundancia. Las formas normales segunda a cuarta también se encargan de cumplir
este objetivo, pero la 5FN generaliza a los casos no cubiertos por las anteriores.
2.6.8- Ventajas y desventajas de conformar la base a las formas

normales
Aunque el proceso de normalización de la base de datos es deseable e implica
mejoras desde el punto de vista de la optimización del espacio de almacenamiento y la
capacidad de recuperación, las formas normales multiplican el número de tablas y
relaciones y la complejidad estructural en general. Una base normalizada a 5FN puede
ser muy difícil de interpretar a primera vista a partir de las tablas individuales. Aunque
esto es un problema solucionable si la estructura está adecuadamente documentada, el
tiempo de interpretación, sumado al tiempo y complejidad del diseño, puede resultar
una desventaja importante.
Algunos autores sugieren no preocuparse demasiado por las formas normales
superiores a la tercera al diseñar una base de datos de dimensiones moderadas a
pequeñas. Esto asegura que las ventajas potenciales de la normalización completa no se
vean superadas de modo abrumador por las dificultades y complejidades del
procedimiento.
El SII es una base que cumple siempre la 2FN, y en general intenta conformarse a
la 3FN, BCFN e incluso a la 4FN.

INFORME FINAL
3- EL PUNTO DE PARTIDA: MATERIAL

PREEXISTENTE
3.1- SABER DE DÓNDE VENIMOS

Describir el tipo y formato de la información preexistente a partir de la cual se
construyó la estructura del SII es un paso previo a la documentación de la estructura de
la base de dato que permite comprender las decisiones de diseño, y en términos
generales, el formato de las tablas. Además, completa el cuadro del proceso de
sistematización y reordenamiento, de modo que todo el trabajo involucrado sirva como
ejemplo o estudio de caso para otras personas que intenten emprender tareas similares
con otros conjuntos de datos (relacionados o no con el GEMaRI).
Además de enumerar los distintos tipos de planillas y datos disponibles (Figura

3.1), es conveniente hacer un resumen del enfoque del GEMaRI respecto a la
evaluación de los recursos ícticos en los lagos de Patagonia. La descripción general de
las técnicas de muestreo, los análisis de campo y de laboratorio, y la compilación de
datos accesorios ayudará a comprender cuáles son las entidades representadas en las
Figura 3.1: Información de base. Las planillas de campo y laboratorio originales, así como mapas y
perfiles térmicos, conforman el nivel más básico de registros. A partir de estos, se generaron las
planillas de cálculo en formato digital que alimentaron al SII.

INFORME FINAL
tablas del SII. A lo largo de la descripción, se resaltan ciertos términos que conforman
elementos básicos reflejados como registros en la base de datos. En este aspecto, el
análisis de cuáles son los elementos básicos e indivisibles relacionados con los
muestreos y la información resultante es muy útil a la hora de determinar unidades
muestrales para pruebas estadísticas.
3.2- ESTRUCTURA DE MUESTREO DEL GEMARI

El Grupo de Evaluación y Manejo de Recursos Icticos (GEMaRI) del CRUB ha
realizado numerosos muestreos en cuerpos de agua de Patagonia, en el marco de los
programas de investigación de la Universidad Nacional del Comahue B019-Evaluación
y Manejo de Recursos Icticos: la pesquería del lago Gutiérrez (Vigliano 1996), B920-
Programa de Recursos Acuáticos en Ambientes Patagónicos (Vigliano 1999), y B940-
Programa de Características Ópticas, Composición Química y Comunidades Bióticas de
Ambientes Acuáticos Patagónicos (Vigliano 2005).
Las actividades enmarcadas en estos programas se agrupan informalmente en
proyectos referidos a aspectos y áreas geográficas específicos. Cada uno de estos
proyectos incluye una o más campañas de muestreo. Las campañas consisten en salidas
al campo. Cada salida establece estaciones de muestreo, definibles como un conjunto
de redes caladas en un sitio determinado (un área geográfica ambientalmente
homogénea). Estos sitios se ubican en un lago u otro tipo de cuerpo de agua (Figura
3.2).
La recolección de datos de campos se centra en las capturas de peces empleando
redes agalleras. Desde 1995, el GEMaRI ha venido haciendo uso de un diseño de
muestreo estratificado (Vigliano et al. 1999). El mismo consiste en calar baterías de
redes compuestas por paños de diferente tamaño de mallas, dispuestos de modo
paralelo a la costa y en hábitatas pelágicos y epibentónicos a diferentes profundidades, a
fin de obtener datos representativos de distintos estratos del lago (Figura 3.3). En
general, las redes se calan después del mediodía de un día, y se levantan a la mañana del
día siguiente. Cada batería de redes tiene un código identificativo que es múltiplo de
100. A su vez, cada paño de red tiene un identificador compuesto por dos partes: el
código de la red de la que forma parte, y el tamaño de malla. Así, se sabe que el paño
2560 está en la red 2500 y tiene un tamaño de malla de 60 mm. bar.

INFORME FINAL
FIGURA 3.2: Estaciones de muestreo. Mapa general (centro) del lago Nahuel Huapi, y detalle de los
sectores en los que se establecieron estaciones de pesca. Cada uno de los puntos señala la posición de
calado de un tren de redes, y el color señala el estrato de profundidad. Los sitios de muestreo se
observan como un conjunto de puntos cercanos entre sí.

INFORME FINAL
Durante el levantado de
las redes, se tiene la precaución
de asociar cada uno de los peces
capturados con el código del
paño del cual fueron
desenmallados (Figura 3.4a). La
captura es procesada en tierra,
anotándose para cada pez su
especie, talla, peso, sexo y
estadio gonadal (Figura 3.4b).
FIGURA 3.3: Esquema del diseño de muestreo estratificado.
PEL: redes pelágicas; EPIB: redes epibentónicas; EPC: redes Además, se toman muestras de
perpendiculares a la costa (modificado de Vigliano et al.
1999).
escamas y otolitos para análisis
de edad y crecimiento, y se
conservan los estómagos para estudios de dieta.
Además de las capturas con redes agalleras, a veces se realizan muestreos
complementarios usando redes de arrastre, pesca eléctrica o nasas. Esto permite obtener
información sobre los peces de tallas pequeñas (juveniles y alevinos o especies de
pequeña talla), que no son capturados por las redes agalleras. También se miden
variables ambientales, tales como los perfiles térmicos de los lagos, el pH y
conductividad del agua, la transparencia por disco de Secchi, etc.
FIGURA 3.4: Tareas de campo. A) Desenmallado sobre el bote de un ejemplar de Diplomystes

viedmensis (bagrecito aterciopelado). B) Muestreo de ejemplares capturados: los peces son medidos,
pesados y sexados, y se toman muestras de escamas, otolitos, estómagos y tejidos para análisis
posterior en laboratorio.

INFORME FINAL
FIGURA 3.5: Estudios hidroacústicos. A) Computadora de a bordo sobre la unidad de superficie de la

ecosonda. En la pantalla se visualizan en tiempo real los datos adquiridos por el equipo. B) Batimetría
preliminar de la bahía de Piedras Blancas (Isla Victoria), generada a partir de los datos hidroacústicos.
La línea señala el derrotero de la embarcación sobre la que se montaba la ecosonda.
Más recientemente, la incorporación de técnicas hidroacústicas ha permitido
obtener valiosa información sobre localización y abundancia de peces, perfiles
batimétricos y tipos de fondos, entre otras cosas (Figura 3.5). Otras potenciales fuentes
de datos sobre los ambientes son las imágenes satelitales, que permiten estimar
variables tales como temperatura superficial, contenido de clorofilas, corrientes de
turbidez, etc. Toda esta información, al encontrarse adecuadamente georreferenciada,
puede ser cruzada con la información de las capturas en busca de patrones que ayuden a
explicar la distribución y abundancia de las especies de peces en los lagos.
3.3- LAS PLANILLAS DE CAMPO

Existen dos planillas de campo: la planilla de calados y la planilla de capturas. En
la planilla de calado se consigna la fecha de calado y levantado de las redes, el sitio y
estación de muestreo, y se listan las redes caladas, consignando para cada una la hora de
calado y levantado, y el estrato ambiental en la que se la ubicó. Los estratos se dividen
en dos grandes categorías: pelágicos y epibentónicos. Dentro de los segundos, se
distinguen redes paralelas y perpendiculares a la costa. Las redes paralelas se colocan de
modo que todo el tren quede a una misma profundidad. Las perpendiculares se
acomodan desde la costa hacia el interior, de modo que la profundidad varia de acuerdo
a la pendiente del fondo (quedando el extremo opuesto a profundidades de entre 5 y 30
metros dependiendo de la pendiente).

INFORME FINAL
Estrato Hábitat Profundidad Descripcion

b0 Epibentónico 0 Bentónica 0 m
perp Epibentónico perpendicular -99 Perpendicular
pel0 Pelágico 0 Pelagica 0 m
pel10 Pelágico 10 Pelágica 10 m
La planilla de capturas, que puede ser completada en el campo o en el laboratorio

dependiendo de la logística de muestreo consigna la fecha (típicamente la fecha de
levantado), y el sitio de muestreo (Figura 3.6). Las columnas de la planilla, aunque
varían de campaña en campaña, típicamente contienen los siguientes datos:
• Nº de identificación del pez: asignado secuencialmente en orden de procesado; la
numeración suele mantenerse a lo largo de toda la campaña, aunque este
esquema es más o menos variable.
• Especie: codificada con un código de tres letras derivado en general del nombre
vulgar de la especie (por ejemplo, TAI para la trucha arco iris, o PEJ para el
pejerrey patagónico). A lo largo de los años y dependiendo de quién era el
que anotaba los datos en la
planilla, pueden
observarse más de un
código por especie (siendo
el puyen grande el que
obtuvo más
denominaciones, tales
como PUY, PLA, PLAT o
PLATEI).
• Largo: la longitud del pez
FIGURA 3.6: Registro en el campo de las planillas de
puede encontrarse medida capturas. El registro se realiza durante las tareas de
procesado inmediatamente después del levantado de las
en milímetros como largo redes.

INFORME FINAL
total, largo fork y largo estándar. Aunque casi siempre se registró el largo
estándar, las otras medidas pueden o no estar presentes según la campaña.
• Peso total: el peso total en fresco del pez, medido en gramos.
• Sexo: el sexo del pez se detemina mediante la disección del mismo, a través de la
identificación de sus gónadas. Cuando el desarrollo gonadal es insuficiente
para determinar el sexo, se lo anota como indeterminado.
• Estadio Gonadal: se anota el estado de madurez de las gónadas ubicándolo en una
tabla de 6 puntos: I-Virginal; II-Desarrollo temprano; III-Desarrollo medio;
IV-Prefreza; V-Freza; y VI: Postfreza (Nikolsky, 1963).
• Paño: indica el código del paño en el que fue capturado el pez. Permite identificar
el estrato al que se realizó la captura, y el tamaño de malla.
• Estrato: Identifica el estrato de muestreo en el que fue capturado el pez.
• Estación: Señala el sitio de muestreo general en que se localizaba la red.
• Observaciones: notas particulares, tales como presencia de parásitos o manchas
parr, códigos de etiquetas (resultado de la recaptura de un individuo
marcado).
3.4- ALMACENAMIENTO DIGITAL

Las planillas de campo y laboratorio se pasaban a formato electrónico usando
planillas de cálculo (FIGURA 3.7). El formato de las planillas de cálculo imitaba el de las
de papel, agrupándose típicamente por sitio o por campaña. Las variaciones en el orden
y tipo de columnas consignadas de los archivos resultantes son significativas, ya que al
no haber un sistema estructurado de ingreso de datos, los formatos sufrían
modificaciones que dependían del formato de la planilla de campo y de la persona que
ingresaba los datos.
Una vez guardadas como planillas de cálculo, los archivos quedaban almacenados
en un disco rígido para su posterior análisis. Esto causaba un problema de control de la
integridad de los datos: puesto que los análisis que se hacían sobre las planillas de
cálculo muchas veces se efectuaban sin hacer una copia previa de los datos de base, fue
común encontrar datos alterados o incompletos en las planillas base. La
descentralización de la información causaba además un movimiento de archivos, así

INFORME FINAL
como la aparición de múltiples copias actualizadas sin sincronía, que a la larga genera
una gran ambigüedad respecto a cuáles son las versiones originales, y cuales están
actualizadas correctamente.
Otro inconveniente de este formato es que los mismos análisis, hechos por
personas diferentes, podían arrojar conclusiones distintas. La causa de este problema es
la falta de criterios comunes estandarizados.
También vale la pena mencionar que muchas de las planillas de base estaban
modificadas con codificaciones hechas con el fin de exportar los datos a un programa de
análisis estadístico. Estas codificaciones, típicamente determinadas por la persona que
estaba haciendo el análisis, no quedaron siempre correctamente documentadas. Eso no
era un problema grave cuando los valores originales de la planilla se mantenían, pero sí
podía causar pérdida de información si se habían reemplazado los datos por los códigos.
Pese a los problemas mencionados antes, la recuperación de la información de las
planillas de capturas no tuvo grandes inconvenientes. Las planillas de calado, sin
embargo, fueron más problemáticas, básicamente porque nunca fueron ingresadas
electrónicamente como tales. En vez de eso, era posible encontrar datos derivados, tales
como las horas de captura, en hojas de cálculo adyacentes a los datos de captura, como
parte del cálculo de la captura por unidad de esfuerzo (CPUE). Así que se optó por
Figura 3.7: Almacenamiento digital original. Planilla de cálculo de capturas, correspondiente a las
campañas al lago Moreno en el año 1999. Sobre la derecha, pueden verse rangos de celdas con
información en un formato inadmisible para la tabla de una base de datos relacional.

INFORME FINAL
volver a las planillas de papel y extraer de allí directamente la información. En este

punto fue cuando se observaron faltantes importantes de información relacionada con
los calados. Para esos (numerosos) casos, resultaron prácticas las hojas adyacentes con
cálculos de CPUE, puesto que el elaborador de las mismas ya había realizado una
estimación aproximada del tiempo de operación de las redes.
Las planillas de escamas y alimentación también se almacenan como planillas de
cálculo. Debido al formato más homogénea de las planillas de papel usados en la toma
de esos datos (y al menor número de personas que se habían encargado de esos
análisis), no se encontraron las dificultades mencionadas más arriba.
3.5 - OTROS TIPOS DE DATOS

El almacenamiento de las planillas de campo de capturas fue mucho menos dispar
que el de otros datos accesorios, tales como variables ambientales, perfiles térmicos,
etcétera. Entre la abundante información de campaña, fue posible encontrar batimetrías,
mapeos de los tipos de costa, caracterizaciones ambientales, datos puntuales de
temperatura, etcétera. La conversión ordenada e ingreso al SII de fuentes tan
heterogéneas constituye un desafío para el diseño de la base de datos, y el empleo del
modelo relacional es de inmensa utilidad gracias a su flexibilidad.

INFORME FINAL
4- DE BASES PLANAS AL MODELO RELACIONAL

4.1- TABLAS CENTRALES Y ACCESORIAS
Aunque no existe jerarquía entre las tablas del modelo relacional, resulta útil al
momento de diseñar la base de datos definir tablas “nucleares” que sirvan como ejes
estructurales. Durante el diseño del SII, dos de las entidades nucleares fueron la tabla de
peces capturados y la tabla de lagos. A partir de la normalización de la información de
estas tablas, y de los datos accesorios que complementaban la información, se fue
estructurando las demás tablas y las relaciones.
4.1.1- La tabla de capturas
Tras decidir que la unidad de registro era un pez capturado con redes agalleras,
cada uno de los cuales se encontraba reflejado en una fila de las planillas de cálculo de
capturas, se comenzó por la base de datos referidas al Lago Moreno. Este cuerpo de
agua fue muestreado de forma intensiva, con campañas estacionales entre los años 1999
y 2001, y era una buena opción para comenzar. Las planillas de base consignaban en
general los siguientes campos: Nº de ejemplar, fecha, especie, LT, LF, LS, PT, sexo,
paño, estación y estrato. Con ciertas variaciones menores, esta lista de campos es la
presente en la mayoría de las planillas de base. A partir de estos datos, algunas planillas
de cálculo tenían hojas adicionales que, usando tablas dinámicas, recuperaban el total de
peces capturados por estrato, y con el dato extra de las superficies de red y el tiempo de
muestreo, permitían calcular la CPUE total y por especies.
Salta a la vista la existencia de ciertos valores repetidos, tales como la fecha de
captura, las estaciones y los estratos. El primer paso en la normalización de la tabla fue
determinar cuál sería la clave principal. El nº de ejemplar era un campo candidato. Sin
embargo, los conteos de nº de ejemplar se reinician al cambiar de lago, o incluso en un
mismo lago, para distintas campañas; dado que la tabla final incluiría registros de
múltiples lagos y campañas, iba a haber duplicados en el campo. En conjunto con un
identificador de campaña y/o de lago, podría generarse una clave principal compuesta.
Pero esta no resultaba una opción práctica, debido a que implicaba generar un campo
para un código de lago o campaña, que no existía en la tabla. Así que se decidió agregar
un nuevo campo ad hoc que funcionara como clave principal, una vez que el resto de la

INFORME FINAL
FIGURA 4.1: CAPTURAS y tablas relacionadas. El DRE muestra la tabla central de capturas
(remarcada en línea sólida) y las tablas relacionadas. Se observa la tabla CPOSAGUA (remarcada en
línea puntueada) y el camino lógico entre cada pez capturado y el cuerpo de agua al que pertenece.
tabla estuviera compilada.

La tabla asociada a las capturas era la que registraba la unidad de captura
inmediatamente superior al pez individual: esto es, cada tren de redes calado. Aquí se
recurrió a la información de las planillas de calado. A partir de las mismas se generó
una tabla que referenciaba el sitio de muestreo, el código de la red calada, estrato de
profundidad y fecha y hora de calado y levantado. Por último, se decidió agregar el
tiempo de operación de las redes como un atributo, ya que, pese a ser calculable a partir
de los datos anteriores, ciertos huecos en la información sólo eran subsanables
asignando un tiempo estimado. La normalización de esta tabla separó tablas
relacionadas de estratos, redes y estaciones.
La tabla de estratos simplemente describe los mismos a partir de los códigos de
estrato. La tabla de redes contiene información acerca de las características de cada red,
en particular, de su superficie. Se observó que a lo largo de los años, se usaron distintos
criterios para calcular la superficie de la red, según se usara la altura estirada de la red o
la altura estimada de la red correctamente armada. Tras consultar con el resto del
GEMaRI, se acordó emplear la segunda medida para todas las redes.
Se definió la estación de muestreo como una salida de pesca localizada en el
espacio y en el tiempo: esto es, en un área geográfica específica (el sitio, por ejemplo,

INFORME FINAL
Bahía López en el Nahuel Huapi) y en un momento determinado (por ejemplo,

noviembre de 1998). Para cada estación era posible calcular el número total de redes
caladas, la suma de la superficie total desplegada, y el tiempo promedio de operación.
Esto permite calcular CPUEs para toda la estación, lo que permite un nivel mayor de
agrupamiento. La estación de muestreo relaciona un sitio geográfico (descrito en otra
tabla) con un conjunto de calados y con una campaña de investigación determinada.
De la tabla de captura se derivaron dos conjuntos más de entidades. Uno es el

conjunto taxonómico, relacionado a través de la tabla ESPECIES que consigna el código
de especie (hizo falta estandarizar los códigos, que para algunas especies fueron
cambiando con los años y los planilleros) y el nombre vulgar y científico. Además,
contiene una relación con su nivel taxónomico superior: la familia1. A su vez, la familia
se relaciona con una tabla ORDEN y así sucesivamente hacia niveles superiores. El otro
es una tabla que contiene los descriptores de los códigos de sexo.
Todas las tablas resultantes de este proceso fueron creadas, asignando los tipos de
dato correspondientes en cada campo, y se crearon las relaciones correspondientes,
como se ve en la FIGURA 4.1.
4.1.2- La tabla de lagos
El segundo elemento nuclear del SII es la tabla de lagos, o más en general, de

cuerpos de agua. Puesto que cada sitio de muestreo se ubicaba en un cuerpo de agua, la
tabla SITIOS contiene un campo con el código del lago correspondiente (FIGURA 4.2). La
tabla de cuerpos de agua requirió una planificación especial, porque además de estar
vinculada a la información de capturas, y de contar con relaciones a diversas tablas de
variables morfológicas y físico-químicas, debía estar estrechamente vinculada a los
mapas de cada lago: la expresión más evidente del carácter espacialmente explícito del
SII.
Excepto para datos puntuales de localización, el almacén final de las tablas

espaciales no podía ser la base de datos (al menos, no la base de datos de Access),
debido a la capacidad limitada de manejar objetos de este DBMS. Aquí se empleó la
1
Aunque el nivel taxonómico inmediatamente superior a especie es género, una observación veloz de las
especies presentes demuestra que no es necesaria una entidad a este nivel. Si se duplicara la estructura del
SII para usarlo en áreas de mayor riqueza específica, no resultaría muy complejo interponer una entidad
GENERO entre ESPECIES y FAMILIAS.

INFORME FINAL
vinculación entre los Sistemas de Información Geográfica y el SII. Se optó por una capa
temática vectorial de polígonos, almacenada en coordenadas geográficas
(latitud/longitud), en donde el identificador de polígono coincidiera con los
identificadores de cuerpo de agua del SII. A tal fin, se podía usar una capa vectorial
preexistente o generar la información de novo a partir de mapas o imágenes satelitales.
Lógicamente, usar la información existente era un atajo obvio; sin embargo, la precisión
de las fuentes no siempre era conocida y confiable. Así que se evaluaron las fuentes
disponibles, que en principio eran las siguientes:
- SIG250: Base de datos generada por el Instituto Geográfico Militar argentino
a partir de cartografía topográfica en escala 1:250 000. Abarca todo el país.
- Atlas Digital de Recursos Hídricos Superficiales: Base de datos generada por
la Subsecretaría de Recursos Hídricos (Giraut et al. 2000). Generada a partir
de cartografía del IGM e imágenes satelitales. Abarca todo el país.
- Mapa de la Ecorregión Valdiviana (Lara et al. 1999): Mapa de tipos de
vegetación del norte de Patagonia, basado en imágenes satelitales.
- Mapas diversos, en general sueltos, generados a partir de cartografía o
imágenes satelitales.
Para determinar qué nivel de precisión y detalle tenían los mapas de las distintas
FIGURA 4.2: CPOSAGUA y tablas relacionadas. La tabla central que lista los cuerpos de agua de
Patagonia, y tablas relacionadas. A partir de este diseño básico, es posible agregar tablas con
información sobre diversas variables referidas a los cuerpos de agua.

INFORME FINAL
FIGURA 4.3: Comparación de las capas de lagos del SIG250 y el ANRH. Puede verse que los
polígonos del SIG250 ajustan mucho mejor a la imagen LandSat 7 que los polígonos del ANRH.
fuentes, fue necesario buscar un mapa de referencia que pudiera considerarse el más
“geográficamente correcto”, específicamente, el de georreferenciación más precisa. A
tal fin, se compararon los mapas con puntos tomados con un GPS Garmin Geko 301,
que determina la posición con 2-15 metros de precisión. Esto permitió definir un
conjunto de imágenes Landsat 72 adecuadamente ortorrectificadas, y sobre las cuales se
compararon los demás mapas.
De este análisis, se observó que, en términos generales, la base que mejor ajustaba
a las imágenes Landsat 7 era la del SIG250. Los polígonos del Atlas Digital de
Recursos Hídricos tenían un desplazamiento sistemático que sugiere o bien el uso de
imágenes satelitales inadecuadamente georreferenciadas, o algún error en los
parámetros geográficos de proyección (FIGURA 4.3). Los polígonos del Mapa de la
Ecorregión Valdiviana, aunque mejor ubicados, tenían bordes escaleriformes (aliasing)
muy notables, fruto de su derivación a partir de clasificación de imágenes. Del resto de
2
U.S. Geological Survey. Fechas diversas. Landsat ETM+ Scenes, Level 1G. Sioux Falls, South Dakota:
USGS. Datos obtenidos mediante el Global Land Cover Facility, http://www.landcover.org.

INFORME FINAL
los mapas, muchos sufrían de

algunos de los problemas
mencionados arriba, aunque
algunos eran más precisos y
con mayor resolución que los
del SIG250.
Así que se decidió usar

la base de cuerpos de agua
del SIG250 como base
general. Se extrajeron los
lagos de Patagonia, se
ordenaron alfabéticamente, y
se les asignó un identificador
único. Lagunas y otros
cuerpos de agua se van
agregando a continuación, a
medida que se obtienen datos
para los mismos en el SII. Es
decir que la base de datos
incluye todos los lagos de FIGURA 4.4: Cuerpos de agua de Patagonia. Ilustración de la
capa temática en formato shapefile que se derivó de la
Patagonia, y a continuación cartografía digital del SIG250.
las lagunas para las que
existen datos (FIGURA 4.4). A medida que se ingresen datos nuevos al SII, puede ser
necesario ampliar esta base con más lagunas u otros cuerpos de agua. Cuando se genera
un polígono de mejor calidad que el existente para un cuerpo de agua, es posible
incorporarlo, reemplazando el anterior.
Resuelta de este modo la expresión espacial más evidente del SII, es posible
generar mapas temáticos levantando el mapa de polígonos de los lagos de interés, y
recuperar a través de consultas a la base de datos los valores de interés. Otros tipos de
datos espaciales, en particular aquellos que contienen información continua (por
ejemplo, imágenes raster), son un poco más complicados de relacionar implícitamente
en la base. Sin embargo, la vinculación puede realizarse usando sistemas de

INFORME FINAL
almacenamiento externo que empleen códigos similares a los códigos del SII,
facilitando la asociación intuitiva de la información. Por ejemplo, los archivos con
imágenes se pueden almacenar en carpetas anidadas por cuenca y lago, cuyos nombres
estén en formato “ID_NombreLago”.
Este mismo enfoque es aplicable a otros tipos de datos u objetos relacionables
pero no directamente incorporables a la base de datos del SII, tales como fotos,
cartografía o bibliografía relacionada, etc. El empleo de punteros (enlaces blandos e
hipervínculos) en una estructura de directorios estandarizada puede complementar a la
base de datos e integrar los objetos al sistema.

INFORME FINAL
5- SISTEMA INTEGRAL DE INFORMACIÓN:

DEFINICIONES DE FORMATO Y ESTRUCTURA
5.1- CONVENCIONES
A continuación, sigue una descripción de la estructura de la base de datos que es
el núcleo del SII. Se describirán primero las entidades (tablas), luego las relaciones, y
luego algunas consultas para la obtención de información básica. Luego, se definen los
estándares y pasos a seguir para poder agregar nueva información, ya sea mediante el
uso de formularios pre-programados, o en un sentido más general. También se
contempla el agregado de nuevas entidades y cómo vincularlas a las tablas existentes.
Para facilitar el seguimiento, se emplearán algunas convenciones de formato. Las
tablas o entidades serán escritas usando VERSALES. El nombre de los campos se
escribirá en itálica. El tipo de datos se describe en negrita. Los valores de datos van en
courier. La clave principal se denotará con un ‫א‬. Las claves alternativas (campos sin
valores de datos duplicados) se demarcaran como α.
Para documentar las relaciones, se empleará la siguiente notación:
Clave_externa:TABLA_HIJA ∞→1 Clave_principal:TABLA_MADRE
Durante el diseño, se intentó que las claves primaria y externa que forman parte
de una relación tuvieran el mismo nombre en distintas tablas, pero esto no siempre se
cumplió en aras de una presentación más simple.
5.2- TABLAS
CAPTURAS
Nombre del campo Tipo de datos Descripción
‫ א‬ID_Pez Autonumérico Identificador Único de Captura
ID_Capt Número entero Identificador de Captura de la Campaña
Calado Número entero Identificador de calado
Especie Texto Código de especie de tres letras
LT Número entero Largo total medido en milímetros
LF Número entero Largo fork medido en milímetros
LS Número entero Largo estándar medido en milímetros
PT Número entero Peso húmedo total medido en gramos
Sexo Número entero Código de sexo
EG Número real Código de estadio gonadal
Panio Número entero Denominador del paño en que fue capturado

INFORME FINAL
Como se mencionó más arriba, ID_Capt podría funcionar como clave principal si
no fuera porque la numeración se reinicia entre campaña y campaña de pesca. Para
usarlo, sería necesario agregar un campo extra que permite diferenciar, por ejemplo, el
ejemplar 10 pescado en Moreno del ejemplar 10 pescado en Mascardi o en Fagnano. Es
más simple y más seguro añadir un campo extra, ID_Pez, que obre como clave principal
(substituta).
El Calado se refiere al momento y red desplegados en un sitio de captura, y es una
clave externa de la tabla CALADOS.
Se optó por mantener el código alfabético de tres letras en lugar de sustituirlo por
un código numérico, puesto que resulta simple de recordar y estandarizar, y es la
manera en que el GEMaRI está acostumbrado a ingresarlo en las planillas y referenciar
en los análisis de los datos.
En la mayoría de las planillas se consignan solo dos medidas de longitud: el largo
estándar y, o bien el largo total o el largo fork. Se optó por incluir las tres medidas para
no perder datos, y dejando en blanco las celdas sin datos3.
Aunque la escala de estadios gonadales es una tabla categórica, representada por
valores ordinales enteros, se observó que en numerosos ejemplares se había anotado en
la planilla más de un valor, refiriéndose a ejemplares que presentaban un estadio
intermedio entre dos categorías. En lugar de intentar elegir uno u otro estadio para
conformar a la 1FN, se optó por transformar el tipo de datos a número real para poder
poner valores intermedios.
CALADOS
‫ א‬ID_Calado Autonumérico Identificador Único de Calado
ID_Estacion Número entero Código de estación de muestreo
ID_Red Número entero Denominador del tren de redes empleado
Estrato Texto Código del estrato de profundidad
Fcalado Fecha/hora Fecha de calado del tren
Flevantado Fecha/Hora Fecha de levantado del tren
Hcalado Fecha/Hora Hora y minutos a los que se caló el tren
Hlevantado Fecha/Hora Hora y minutos en los que se levantó el tren
Tiempo Número real Tiempo de operación de las redes, en horas
Se identifica como elemento de la entidad CALADOS cada ocasión en que un tren

de redes fue calado en un cuerpo de agua. Como no existía un atributo natural para
3
Nótese que en la implementación en Access de la base de datos, valores que en realidad son nulos se
están representando en realidad como “” (cadenas vacías). El manejo del DBMS de los valores nulos
resulta algo confuso en este caso, y es importante verificar cómo se están manejando cuando se realicen
análisis sobre campos con valores de este tipo.

INFORME FINAL
identificar cada uno de estos calados, se creó un campo ID_calado que oficie de clave
principal. El siguiente campo de la tabla era el que ubicaba el área geográfica (estación)
dentro del cual se incluye el calado. Así, ID_Estacion es un campo relacional que
referencia a las estaciones de muestreo. El denominador de red es el mismo que se usa
en las planillas de calado y en los paños.
Estrato, al igual que el campo Especie:CAPTURAS, usa los mismos códigos de
texto que se emplean habitualmente en las planillas de campo (ver la tabla ESTRATOS).
Las fechas y horas de calado y levantado, cuando están presentes, determinan
automáticamente el valor de Tiempo. Como la ausencia de uno sólo de estos valores
impide este cálculo, se incluyó el campo Tiempo para dar la opción a ingresarlo
independientemente. En los formularios de ingreso de datos (ver más abajo) se incluye
una función que muestra al usuario cuál es el resultado del cálculo una vez que están los
cuatro valores ingresados, de modo que solo halla que copiarlo al campo Tiempo.
ESTACIONES
‫ א‬ID_Estación Autonumérico Identificador Único de Estación de
Muestreo
Campania Número entero Código de campaña de muestreo
Sitio Número entero Código del área geográfica de la estación
Ntrenes Número entero Cantidad de trenes de redes calados
SupTotal Número real Suma de las superficies de red operativas
TiempoMedio Número real Promedio de los tiempos de operación
Las estaciones, como se dijo antes, corresponden a un área geográfica

(típicamente, un sector del lago) en el cual se dispusieron trenes de redes. A fin de
poder calcular las cpues por estación, se incluyeron los dos campos suptotal y
tiempomedio. Los mismos son derivables de la información de calados, pero se optó por
ingresarlos como campos extras para facilitar la realización de los procedimientos
almacenados, puesto que Access presenta algunas complicaciones para anidar consultas
de resumen.
CAMPAIGN
‫ א‬ID_Camp Autonumérico Identificador Único de Campaña de
Muestreo
Nombre Texto Nombre descriptivo de la campaña
Lugar Texto Nombre del área (opcional)
Anho Número entero Año en que se hizo la campaña
Epoca Número entero Código de estación del año de la campaña
Proyecto Texto (temp) Proyecto

INFORME FINAL
El empleo de caracteres “no estándares” (incluyendo vocales acentuadas y la letra

ñ) es poco aconsejable, incluso si el paquete de software que se emplea en un momento
dado las acepta. Esto es porque es muy común que al intercambiar datos entre
aplicaciones, comiencen a aparecer reemplazos en estos caracteres debido a
codificaciones distintas. En esta tabla se ve que se ha evitado todo lo posible usar eñes.
El Nombre y el Lugar de las campañas son principalmente descriptivos, y sirven
para dar un marco de referencia “histórico” a las estaciones de muestreo. También para
darle un marco referido a los objetivos de investigación, a partir del campo Proyecto.
Este campo se ha dejado por el momento con texto como su tipo de datos, pero podría
transformarse en referencias a una tabla diferente sobre proyectos.
SITIOS_MUESTREOS
‫ א‬ID_Sitio Autonumérico Identificador Único de Sitio
Nombre Texto Denominador del área de muestreo
Long Número real Longitud en grados decimales
Lat Número real Latitud en grados decimales
ID_CpoAgua Número entero Código del cuerpo de agua donde se ubica
Descripcion Memo (texto) Descripción ambiental del área
Los sitios de muestreo reflejan las coordenadas geográficas aproximadas del área
donde se montaba una estación de muestreo. En cuerpos de agua pequeños, un único
sitio suele representar redes dispersas en todo el lago. Pero en cuerpos más
intensamente estudiados, suele haber varios sitios. El Nombre del sitio generalmente es
un nombre de campaña, asociado a algún elemento de la costa que resulta característico.
No necesariamente está asociado a los toponímicos cercanos (por ejemplo, un sitio
denominado Tábanos puede deber su nombre a que hay un arroyo o laguna cercano con
ese nombre, o a que había suficientes tábanos en el área como para quedar plasmados en
la planilla de campo).
Las coordenadas geográficas, expresados en grados decimales (HH.hhhhº)
siempre están referidas a un datum/elipsoide WGS84.
El ID_CpoAgua es el campo que relaciona al sitio de muestreo, y por lo tanto a
los peces capturados, con los lagos, lagunas, ríos y arroyos.

INFORME FINAL
ESTRATOS
‫ א‬IDEstrato Autonumérico Identificador Único de Estrato
α Estrato Texto Código alfanumérico de estrato
Ambiente Número entero Código de ambiente
Profundidad Número entero Profundidad en metros del piso del estrato
Descripción Texto Nombre descriptivo del estrato
El SII incorpora datos de captura realizados mediante muestreos ambientales

estratificados por ambiente (epibentónico y pelágico) y profundidad. También
incorpora datos de los calados perpendiculares a la costa. Debido a que la profundidad
es variable en estos últimos, se colocó un -99 en Profundidad. Es interesante notar que
aunque la clave principal definida en esta entidad es IDEstrato, se optó por usar Estrato
como clave alternativa, puesto que los códigos alfanuméricos son más prácticos que una
clave numérica o una búsqueda, y resultan más familiares para los usuarios.
HABITATS
‫ א‬ID_Habitat Autonumérico Identificador Único de Hábitat
Habitat Texto Nombre del hábitat
Descripción Texto Descripción y definición del hábitat
Esta tabla diferencia los ambientes epibentónico y pelágico. También diferencia

como tercer ambiente el epibentónico perpendicular, que es similar al epibentónico,
pero en el que las redes se disponen perpendicularmente a la costa en lugar de
paralelamente.
REDES
‫ א‬Red Número entero Identificador de tren de redes
Sup Número real Superficie de la red en metros cuadrados
Status Texto Situación del tren de redes
Observaciones Texto Notas sobre las redes
Este es un ejemplo de entidad con una clave principal inteligente: el número que
identifica a cada tren de redes es un atributo real y no un agregado como en los casos
anteriores4. La superficie de la red se calculó como la suma de la superficie de los paños
4
Aquí corresponde aclarar que en al menos un caso, se detectó un uso duplicado de la denominación
2000 en un tren de redes. Se denominó 2000 a una red distinta a una 2000 anterior. También puede pasar
eso cuando de un tren de redes se quita uno o más paños para reemplazarlos por otros nuevos. A menos
que los paños nuevos tengan exactamente la misma superficie que los sustituidos, es necesario cambiar la
denominación de la red e ingresar un nuevo registro en la tabla REDES. Si el cambio es sólo de algunos
paños, se puede denominar sumándole 1 (por ejemplo, la red 2000 duplicada pasó a denominarse 2001).
Esto también es útil en circunstancias en las que no todo el tren estuvo operando. Sin embargo, en el caso

INFORME FINAL
que la componen, y a partir del alto de la red cuando está armada en el agua (no el largo
estirado, que puede ser casi el doble). Status y Observaciones hacen referencia a si el
tren está o no en uso en la actualidad, y mencionan eventuales cambios de
denominación.
PANIOS
‫ א‬ID_Pan Número entero Identificador de paño
Malla Número entero Tamaño de malla bar en milímetros
Sup Número real Superficie de la red en metros cuadrados
Status Texto Situación del tren de redes
EnRed Número entero Tren de redes del que forma parte
Observaciones Texto Notas sobre las redes
La tabla de paños es muy similar a la de redes, con el agregado del campo Malla
que permite discriminar adecuadamente los distintos tipos de paños, permitiendo hacer
análisis sobre la selectividad del arte de acuerdo al tamaño de malla. Aquí también la
clave principal es inteligente.
EnRed permite asignar cada paño a un tren de redes. Históricamente, permite
asociar un paño determinado con la red en la que fue usada. También puede usarse con
paños nuevos para armar “redes virtuales” a fin de calcular superficies de trenes a
armar. La relación entre este campo y las redes es de tipo varios-a-uno, de modo que un
paño puede estar en sólo una red (aquella en la que está, o en la que estuvo hasta su
retirada del uso). Es posible cambiar esta restricción a una relación varios-a-varios, de
modo de registrar todas las redes en las que estuvo el paño, pero se consideró
innecesario ya que no existe registro histórico de esos detalles. En cualquier caso, vale
la pena remarcar que Sup:REDES no es un campo dinámicamente vinculado a campos de
PANIOS, y que por lo tanto cambios en las asociaciones marcadas por EnRed no
afectaran los valores de superficie del tren.
EPOCAS
‫ א‬ID_Epoca Número entero Identificador de estación del año
Epoca Texto Estación del año
Dado que el término “estaciones” ya estaba en uso, se denominó “épocas” a las

cuatro estaciones del año: 1-verano, 2-otoño, 3-invierno, y 4-primavera.
de redes nuevas, se recomienda seguir empleando múltiplos de 100 a partir de la denominación más alta
existente.

INFORME FINAL
SEXOS_DESC
‫ א‬COD_SEX Número entero Identificador de sexo
Sexo Texto Descripción
Los valores 1 y 2 corresponden a hembra y macho respectivamente. Se emplea 0

cuando las gónadas del ejemplar estaban tan inmaduras que no era posible distinguir el
sexo. El valor -99 corresponde a un valor nulo (sin datos).
ESPECIES
‫ א‬ID Autonumérico Identificador de especie
α Codigo Texto Código alfabético de tres letras de especie
Familia Número entero Código de familia
Especie Texto Nombre científico de la especie
Autor Texto Autor(es) de la descripción
Year_desc Número real Año de la descripción de la especie
Nom_vulg Texto Nombre vulgar principal
Nativa Booleano Especie nativa de Patagonia (sí/no)
Ilustración Objeto Contenedor para una imagen
La tabla de ESPECIES es otro ejemplo de empleo de una clave alternativa (Codigo)

en lugar de la clave principal numérica, por los mismos motivos mencionados para
Estrato:ESTRATOS. Especie refiere al nombre científico más reciente. Autor y Year_desc
hacen alusión al autor o autores y años que habitualmente se mencionan en la citación
correcta (completa) de la especie. Nom_vulg sólo admite un nombre, de acuerdo a la
conformidad con las formas normales. Si resultara de interés almacenar más nombres
vulgares (o nombres científicos sinónimos), debería hacerse en una tabla aparte
vinculada a ESPECIES. Nativa es un campo booleano (sí/no, verdadero/falso, 0/1);
qué es nativo y qué es introducido puede resultar muy claro en el caso de salmónidos y
galáxidos, pero no siempre es tan evidente en zonas ubicadas en los bordes de las
provincias zoogeográficas vecinas. Ilustración provee un puntero a una imagen externa
(jpg, bmp, tif, etc.) y sirve como ejemplo de un campo con objetos.
TAX_FAMILIA
‫ א‬ID_familia Autonumérico Identificador de familia
Orden Número entero Código de orden
Familia Texto Nombre de la familia
Autor_anio Texto Autor(es) y año de la descripción
Etimología Texto Etimología del nombre del taxón

INFORME FINAL
TAX_ORDEN
‫ א‬ID_Orden Autonumérico Identificador de orden
Subclase Número entero Código de subclase
Orden Texto Nombre del orden
TAX_SUBCLASE
‫ א‬ID_Subclase Autonumérico Identificador de subclase
Clase Número entero Código de clase
Subclase Texto Nombre de la subclase
TAX_CLASES
‫ א‬ID_Clases Autonumérico Identificador de clase
Clase Texto Nombre de la clase
Las entidades taxonómicas tienen una estructura semejante, y los campos

Autor_anio y Etimologia son solo incluidos a modo de ejemplo. Las tablas pueden
expandirse agregando campos en tanto sea necesario. La estructura simple de relaciones
entre estas tablas (como se muestra más abajo) permite reconstruir la naturaleza
jerárquica de la clasificación taxonómica.
CPOSAGUA
‫ א‬ID_CpoAgua Numérico Identificador de cuerpo de agua
Nombre Texto Nombre del cuerpo de agua
Navegable Booleano Indica si el cuerpo es navegable con
embarcaciones
Hoja Texto Refiere a la carta topográfica IGM que
incluye al cuerpo de agua
Tipo_CpoAguaId_ Número entero Código de tipo de cuerpo de agua
ProvinciasId_ Número entero Código de provincia(s) en que se ubica
Regimen_CpoAguaId_ Número entero Código de régimen hídrico
PaisesId_ Número entero Código de país (o países) en el que se
ubica
Como se dijo antes, la tabla de cuerpos de lago es un derivado de la tabla de

atributos de la capa temática de lagos, lagunas, esteros, bañados, golfos y bahías del
SIG250 del Instituto Geográfico Militar argentino. De esa capa temática se extrajeron

INFORME FINAL
todos los cuerpos de agua identificados como “lagos”, y se los numeró en orden
alfabético. La casi totalidad de los cuerpos de agua clasificados como “lagos” se
encuentran en Patagonia. Luego se incluyeron los embalses, continuando la numeración
de los lagos. Para el caso de las lagunas, se optó incluir sólo las lagunas de las que se
tenían datos de capturas, puesto que el número de lagunas es mucho más grande y
existen numerosos polígonos “sin nombre”.
La clave principal de esta tabla es crucial para poder relacionar las características
ícticas de cada lago (a partir de la sección de capturas) con sus características
morfológicas, geográficas y biogeoquímicas.
Varios registros tienen valores nulos representados como cadenas vacías (“”) en
Navegable. La hoja topográfica es la que contiene a todo el cuerpo de agua, o a su
mayor parte.
TIPO_CPOAGUA
‫ א‬ID Numérico Identificador de tipo de cuerpo de agua
Tipo Texto Tipo de cuerpo de agua
Al momento, el SII incluye tres tipos de cuerpo de agua: lagos, lagunas y

embalses.
PROVINCIAS
‫ א‬ID Numérico Identificador de provincia (s)
Provincia Texto Nombre de la(s) provincia(s)
A diferencia de otras tablas, esta no se ajusta a la 1FN, debido a que hay campos
con más de un valor. Se optó por no normalizar la tabla porque son pocos los casos que
un lago está entre dos provincias. Sin embargo, si en el futuro esta tabla no normalizada
causara inconvenientes, no es muy difícil trasladar las relaciones a la 1FN creando una
relación varios-a-varios.
REGIMEN_CPOAGUA
‫ א‬ID Numérico Identificador de régimen hídrico
Regimen Texto Tipo de regimen
Esta tabla define los regímenes hídricos (si el cuerpo de agua es temporario o
permantente). Todos los cuerpos actualmente presentes en el SII son permanentes.

INFORME FINAL
CUENCAS
‫ א‬ID_Cuenca Numérico Identificador de cuenca hídrica
Nombre_Cuenca Texto Nombre de la cuenca
Provincia Número entero Código de provincia(s)
Sistema Número entero Sistema hídrico al que se integra
Las cuencas listadas se extrajeron del Atlas Nacional de Recursos Hídricos

Superficiales.
SISTEMAS_HIDRICOS
‫ א‬ID_Sistema Numérico Identificador de cuenca hídrica
Sistema Texto Nombre del sistema
Las denominaciones de los sistemas fueron extraídas del Atlas Nacional de

Recursos Hídricos Superficiales. Una observación rápida de los registros revela que
existen registros distintos (con distinto Id_Sistema) que comparten el mismo nombre. Se
prevé cambiar los nombres de los sistemas a medida que en la bibliografía aparezcan
denominaciones particulares.
CPOSAGUA_CUENCA
‫ א‬ID_CPOAGUA Numérico Identificador de cuerpo de agua
CUENC_COD Texto Código de cuenca hídrica
Esta es la tabla de junción que efectiviza la relación varios-a-varios entre cuerpos

de agua y cuencas.
5.3- RELACIONES
La tabla a continuación describe las relaciones creadas entre las distintas tablas
descritas en el punto anterior, y su cardinalidad. El diagrama de relación entre
entidades se ilustra en la Figura 5.1.
Clave externa Tipo Clave principal

Calado:CAPTURAS ∞→1 ID_Calado:CALADOS
Sexo:CAPTURAS ∞→1 COD_SEX:SEXOS_DESC
Especie:CAPTURAS ∞→1 Codigo:ESPECIES
Panio:CAPTURAS ∞→1 ID_Pan:PANIOS
EnRed:PANIOS ∞→1 Red: REDES
ID_Estacion:CALADOS ∞→1 ID_Estacion:ESTACIONES

INFORME FINAL
ID_Red:CALADOS ∞→1 Red: REDES

Estrato:CALADOS ∞→1 Estrato:ESTRATOS
Ambiente:ESTRATOS ∞→1 ID_Habitat:HABITATS
Campania:ESTACIONES ∞→1 ID_Camp:CAMPAIGN
Sitio:ESTACIONES ∞→1 ID_Sitio:SITIOS_MUESTREO
Epoca:CAMPAIGN ∞→1 ID_Epoca:EPOCAS
Familia:ESPECIES ∞→1 ID_Familia:TAX_FAMILIA
Orden:TAX_FAMILIA ∞→1 ID_Orden:TAX_ORDENES
Subclase:TAX_ORDENES ∞→1 ID_Subclase:TAX_SUBCLASE
Clase:TAX_SUBCLASE ∞→1 ID_Clases:TAX_CLASES
ID_CpoAgua:SITIOS_MUESTREO ∞→1 ID_CpoAgua:CPOSAGUA
ID_CpoAgua:CPOSAGUA 1→1 ID_CpoAgua:CPOSAGUA_CUENCAS
Tipo_CpoAguaID_:CPOSAGUA ∞→1 ID:TIPO_CPOSAGUA
ProvinciasID_:CPOSAGUA ∞→1 ID:PROVINCIAS
Regimen_CpoAguaID_:CPOSAGUA ∞→1 ID:REGIMEN_CPOAGUA
PaisesID_:CPOSAGUA ∞→1 ID:PAISES
CUEN_COD:CPOSAGUA_CUENCAS ∞→1 ID_Cuenca: CUENCAS
Provincia: CUENCAS ∞→1 ID:PROVINCIAS
Sistema: CUENCAS ∞→1 ID_Sistema: SISTEMAS_HIDRICOS
FIGURA 5.1: Diagrama de Relación de Entidades del SII.

INFORME FINAL
6 - EXPANDIENDO LA BASE DE DATOS

6.1 - UN SISTEMA PREPARADO PARA CRECER
Tal como se presenta en las secciones anteriores, el Sistema Integral de
Información es en simplemente una base estructural preparada para integrar toda la
información nueva que se desee. El ingreso de datos nuevos puede tener tres formas
fundamentales:
1. Adición de nuevos registros a las tablas existentes
2. Adición de nuevos campos a las tablas existentes
3. Agregado de nuevas entidades
6.1.1- Añadiendo registros
Las futuras actividades de muestreo sin duda generarán información directamente

compatible con la estructura actual del SII. Ya se trate de pescas en sitios previamente
estudiados o salidas a nuevos cuerpos de agua, mientras no exista una modificación
sustancial en el diseño estratificado de muestreo mediante redes agalleras, los registros
obtenidos pueden ingresarse directamente en las tablas correspondientes. La creación de
formularios de entrada simplifica el proceso y evita al usuario del sistema tener que
lidiar con códigos de identificación (FIGURA 6.1).
El proceso de ingreso de nuevos registros requiere de cierto orden lógico. Por

ejemplo, supongamos que se hace una campaña en un lago que nunca antes fue
muestreado. Además de los nuevos peces capturados (tabla CAPTURAS), se habrán
realizado CALADOS en ESTACIONES de un nuevo SITIO_MUESTREO. Si se intenta
comenzar a pasar las planillas de campo por la tabla CAPTURAS, se verá que no existe
información de CALADOS a la que hacer referencia. A su vez, al querer ingresar los
nuevos CALADOS, se echa en falta las ESTACIONES (y SITIOS_MUESTREO)
correspondientes.
Esto ocurre porque, si bien la estructura relacional no implica relaciones
jerárquicas, la naturaleza de los datos sí mantiene jerarquías, en la que el cuerpo de agua
(CPOSAGUA) tiene un nivel superior, y las CAPTURAS tiene el nivel inferior. Por lo tanto,
el orden lógico de ingreso de datos es:

INFORME FINAL
CPOSAGUA→SITIOS_MUESTREO→CAMPAIGN→ESTACIONES→CALADOS→CAPTURAS
Es deseable que existan ciertos controles de seguridad para evitar una

modificación accidental (o maliciosa) de la información de la base de datos. Así, la
implementación del SII debe hacer una administración adecuada de los permisos de
lectura de registros, adición de información y edición de datos. Estas políticas de
seguridad deben estar acompañadas por copias de respaldo frecuentes, a fin de preservar
la base de potenciales pérdidas de información por errores humanos o informáticos
(fallas de software o hardware, ataques de virus informáticos, etc.).
FIGURA 6.1: Formularios de ingreso de datos. La implementación bajo MS Access del SII cuenta
con algunos formularios prediseñados para facilitar el ingreso ordenado de datos. Los formularios,
accesibles mediante un panel (arriba), hacen uso de las relaciones existentes para presentar al usuario
la opción de elegir valores de otras tablas en lugar de trabajar directamente con los códigos de las
claves.

INFORME FINAL
6.1.2 – Añadiendo campos nuevos a entidades existentes
Aunque es poco probable que se expandan los atributos de las tablas principales,
tales como CAPTURAS o CALADOS, es posible agregar nuevos campos a otras tablas, en
especial, a tablas que contienen información de referencia. Por ejemplo, actualmente la
tabla PROVINCIAS solo tiene dos campos: su clave principal y el nombre de la/s
provincia/s. Podrían agregarse nuevos atributos, tales como la superficie, la cantidad de
habitantes, la densidad demográfica, etc. Agregar un campo nuevo es un proceso
sencillo y no genera problemas con las relaciones preexistentes o con la estructura de
datos. Cada campo nuevo en una tabla permite la generación de consultas que realicen
combinaciones novedosas con los atributos preexistentes.
6.1.3- Agregando nuevas entidades
Añadir nuevas tablas al SII implica una modificación más profunda de la

estructura de la base de datos que el mero agregado de registros. Esto no quiere decir
que sea más complejo o problemático. Por el contrario, cada nueva entidad que se anexa
añade una nueva dimensión al conjunto, puesto que permite generar nuevas relacionas y
proponer análisis novedosos de la información. Por otro lado, una nueva entidad no
hace ningún aporte al sistema si no está relacionada con al menos una entidad
preexistente. Por ejemplo, supongamos que se desea añadir una tabla de registros de
temperatura del aire en diversos puntos geográficos de medición. Esta nueva entidad
puede contener una enorme cantidad de datos, pero no aporta al sistema si se encuentra
aislada. Es necesario encontrar una o más relaciones adecuadas con otras entidades. Un
atributo que puede generar una relación es la fecha del registro: de este modo, es posible
obtener para ciertas fechas de pesca la temperatura de ese día (o de ese mes). Otra
posibilidad es usar la información geográfica del punto de medición para asignarla a una
variable geográfica de otra entidad preexistente. Así, se podría usar un SIG para
determinar en qué cuenca hídrica se sitúa el punto de medición y crear un atributo
Cuenca que se vincule a ID_Cuenca: CUENCAS. Esto permite calcular temperaturas
medias para cada cuenca, e investigar las posibles relaciones entre el clima y los
procesos hídricos que afectan la cuenca, la calidad del agua, y, potencialmente, a los
peces.
Existen ciertas entidades en el SII que ofrecen un punto de conexión más evidente
a la hora de añadir nuevas tablas de información. Por un lado, los resultados de análisis

INFORME FINAL
adicionales de los peces capturados, como puede ser la medición de escamas, el análisis
de dietas, o la tipificación genética, pueden ser vinculados directamente con otros datos
del ejemplar mediante el identificador único de captura ID_Pez:CAPTURAS. A su vez,
una vez creada la relación, es posible hacer una consulta a la base que devuelva las
variables ambientales asociadas al sitio de muestreo donde se capturó ese pez, o datos
relacionados con la fecha de captura o el tipo de arte de captura. Otra entidad que ofrece
un punto de conexión es el sitio de muestreo (ID_Sitio:SITIOS_MUESTREO): variables
ambientales específicas de ese sitio (morfología litoral, vegetación acuática, temperatura
y variables químicas locales, etc.) pueden permitir un estudio de mayor resolución que
un análisis que tome el cuerpo de agua como unidad. Por otra parte, los cuerpos de agua
(ID_CpoAgua:CPOSAGUA) son también puntos ideales para realizar conexiones a la
base de datos. Existe mucha información limnológica que es rápidamente incorporable
al SII simplemente agregando como atributo vinculante el identificador único de lago
empleado en el SII.
Resumiendo, se sugiere tener en cuenta tres puntos principales de conexión para
la incorporación de nuevos datos al SII:
• ID_Pez:CAPTURAS: para incorporar información referida a los peces capturados
mediante redes agalleras (análisis de escamas y
otolitos, dieta, etc.).
• ID_Sitio:SITIOS_MUESTREO: para incorporar información relativa a los ambientes
de muestreo, orientada a un análisis local de las
relaciones entre variables ambientales y los peces que
allí se capturaron (como opuesto a un análisis que
adopte a cada cuerpo de agua como unidad de
estudio).
• ID_CpoAgua:CPOSAGUA: para incorporar información relacionada con los
cuerpos de agua como unidad, como pueden ser
mediciones de calidad de agua, temperaturas medias,
perfiles térmicos, etc.
La mención de estos tres campos no implica que no puedan realizarse conexiones

a través de otros atributos o entidades. Sólo se los resalta como los tres que más
frecuentemente se utilizarán. Cualquier atributo que sea una clave principal o alternativa
puede servir como conector relacional con una nueva tabla. Datos de las especies

INFORME FINAL
pueden conectarse a través del identificador específico Codigo:ESPECIES o ID:ESPECIES.

Variables a nivel de cuenca hídrica pueden relacionarse mediante ID_Cuenca:
CUENCAS. Se pueden agregar datos censales por provincias identificadas mediante
ID:PROVINCIAS. Las posibilidades son prácticamente infinitas, y el único factor
limitante es la imaginación y el ingenio de los usuarios del SII.
6.2- DOS EJEMPLOS

La flexibilidad de la base de datos relacional es uno de sus puntos fuertes. Es
posible introducir modificaciones en las estrategias de investigación sin necesidad de
alterar la estructura de la información subyacente. Se dan a continuación dos ejemplos
reales de incorporación de entidades nuevas al SII bajo dos situaciones distintas. En el
primer caso, se trata de un refinamiento de la técnica de muestreo; en el segundo, se
incorpora una tabla de datos limnológicos obtenida de la bibliografía.
6.2.1- Añadiendo resolución espacial: CALADOS_GPS
Durante sus últimas campañas al lago Nahuel Huapi, el GEMaRI incorporó el

empleo del Sistema de Posicionamiento Global (GPS) para marcar con una precisión de
entre 30 y 6 metros el punto geográfico en el que se caló cada tren de redes mediante un
receptor GPS (los puntos que se muestran en la FIGURA 3.2 fueron obtenidos de esa
manera). Esta metodología permite precisar el punto geográfico exacto en el cual
determinado ejemplar fue capturado. Además, y en conjunto con los datos batimétricos
arrojados por los sondeos hidroacústicos, permite obtener mejores mapas de la
localización de la red en el ambiente sublacustre5.
En el campo, los puntos de calado se marcaron usando un receptor GPS Garmin
Gecko 301; fueron denominados usando una letra seguida del código del tren (a veces
simplificado a las dos primeras cifras para una operación más rápida). Una vez en el
laboratorio, los puntos marcados se descargan a una computadora y pueden exportarse
como pares de coordenadas geográficas a una tabla.
Para importar esta tabla al SII, es necesario añadir un campo que funcione como
5
Además, funciona como reaseguro en caso de problemas con las planillas de calado. A veces sucede que
accidentalmente se pierde el dato del estrato en el que se caló un tren; si se cuenta con un mapa
batimétrico y una localización geográfica precisa, es posible averiguar la profundidad en ese punto, y
deducir el estrato correspondiente.

INFORME FINAL
FIGURA 6.2: Relacionando las capturas con los puntos GPS. A) Tras incorporar la tabla
Calados_GPS al SII, una consulta devuelve valores de latitud y longitud de captura para cada trucha
marrón (Salmo trutta) capturada en el Nahuel Huapi, así como sus tallas. B) Gráfico de dispersión
de largo total en función de la latitud. C) Diagrama de cajas (agrupado por estación de muestreo) de
las variables de B).
clave externa, y en el cual se consigna para cada localización el código de calado que
está en ID_Calado:CALADOS. Además, es conveniente agregar a la tabla su propia clave
principal, en caso de que querramos luego asignar variables precisas a esos sitios
particulares (lo que implicaría un análisis en una escala aún más detallada que las
variables asignadas a sitios de muestreo).
Una vez que cada registro de la tabla de localizaciones geográficas de calado tiene
un valor asignado en la clave externa, simplemente es necesario importarla al SII; en
este caso, al importarla se le dio el nombre de CALADOS_GPS a la entidad . Luego, solo
queda generar una relación ID_Calado: CALADOS_GPS 1→1 ID_Calado: CALADOS, y
ya queda la nueva tabla incorporada a la base de datos. Ahora, es posible asignar un
punto geográfico de captura para cada ejemplar pescado en una red georreferenciada
con GPS con una precisión de 30 a 6 metros (FIGURA 6.2).
6.2.2- Anexando datos externos: el ArLaRe
Dado su carácter integrador, el SII debe aceptar fácilmente el ingreso de entidades

nuevas que contengan información procedente de fuentes externas al trabajo del
GEMaRI. Se presenta como ejemplo la integración de la base de datos de Lagos y

INFORME FINAL
Reservorios de Argentina (Argentina Lakes and Reservoirs database, o ArLaRe), creada

por R. Quirós (Quirós 1987, 1988a, 1988b, 1990a, 1990b, 1991, 1995, 1998a, 1998b,
1998c, 2004; Quirós y Anderson 1993; Quirós y Boveri 1999; Quirós y Drago 1985,
1999; Quirós et al. 1988; Baigún y Delfino 1994; Baigún y Marinote 1995). La base
ArLaRe recopila numerosos datos acerca de lagos, embalses y lagunas de la Argentina:
parámetros morfológicos, mediciones físico-químicas, y niveles de factores bióticos
tales como concentración de clorofilas y capturas de peces por unidad de esfuerzo.
La base de datos, que está libremente disponible para su uso en Internet en
http://www.geocities.com/CapeCanaveral/Lab/5028/ARLARE.html, está presentada
como una planilla de cálculo, con subconjuntos referidos a cuerpos de agua pampeanos
y patagónicos. Para el SII, se descargó la planilla correspondiente a Patagonia.
El primer paso consiste en transformar la planilla de cálculo a un formato
compatible con las formas normales de una base de datos relacional. Para ello, se
eliminaron las anotaciones y otros extras a fin de que solo queden los datos, con cada
registro (en este caso, un cuerpo de agua) en una fila, y cada variable en una columna.
La fila superior contiene los títulos de cada columna. El paso siguiente fue insertar una
columna destinada a funcionar como clave principal de la tabla. Finalmente, se insertó
una columna ID_CpoAgua, para albergar la clave externa, es decir, el valor que
permitirá vincular la tabla ArLaRe con el resto del SII.
Luego se consignó en la columna ID_CpoAgua el valor del código del campo
ID_CpoAgua:CPOSAGUA que correspondía a cada espejo de agua listado en la ArLaRe.
No todos los espejos presentes en ArLaRe estaban en CPOSAGUA, así que se buscó en
los mapas digitales originales del SIG250 del IGM las lagunas faltantes y se las agregó.
A algunos cuerpos de agua no fue posible asignarle un código de identificación, o bien
porque no se encontró un elemento de nombre similar en las bases existentes, o porque
la denominación en la ArLaRe era ambigua (por ejemplo, “Roca” puede referirse a al
menos tres lagos, y hay catorce lagunas llamadas “Verde”).
Finalmente, se importó la tabla desde la planilla de cálculo al SII, definiéndose
como clave principal el campo creado a tal fin, y estableciendo la relación:
ID_CpoAgua: ARLARE 1→1 ID_CpoAgua: CPOSAGUA
Hecho esto, es posible generar consultas a la base de datos que incorporen los
campos referidos a los cuerpos de agua incluidos en el ArLaRe (FIGURA 6.3).

INFORME FINAL
FIGURA 6.3: Importando bases de datos externas. Mapa preliminar de lagos del Parque Nacional Los
Alerces ilustrando la variación en la concentración media de clorofila a (Chl-a). Los datos se recuperaron
desde la base de datos ArLaRe (Quirós, op. cit.).

INFORME FINAL
7- SII+SIG: AÑADIENDO LA DIMENSIÓN ESPACIAL

7.1- ENTER SIG
Tal como está implementado actualmente, el SII no incorpora capacidades de
análisis geográfico. Los estudios referidos a patrones espaciales deben hacerse
empleando Sistemas de Información Geográfica (SIGs) externos al SII. Esto no
representa un inconveniente, ya que la mayoría de estos sistemas incorpora numerosas
funciones para consultas a bases de datos.
Una vez más, el núcleo de las interrelaciones está en los códigos de identificación
de los elementos. Esto equivale a decir que si se manejan códigos similares para
denominar elementos que representan un mismo objeto en el SII y en la base de datos
espacial, es muy simple vincular los elementos en el espacio con sus atributos en la base
de datos relacional.
Los SIGs se manejan con dos grandes tipos de entidades espaciales: capas
temáticas vectoriales y grillas (raster). Las capas temáticas vectoriales permiten definir
elementos discretos, y según su dimensionalidad son clasificables en temas de puntos,
de arcos o de polígonos. Por otro lado, las capas raster se emplean típicamente para
variables contínuas, y consisten en cuadrículas de elementos de tamaño regular (pixels),
cada uno de los cuales tiene un valor asignado. En ambos casos, la asignación de cada
elemento a una posición determinada sobre la superficie de la tierra es lo que diferencia
a los paquetes SIG de otros tipos de software de procesamiento de imágenes o diseño
gráfico.
Las capas temáticas vectoriales son más fácilmente integrables a una base de
datos relacional, puesto que los elementos de cada capa temática tienden a ser menos
numerosos que en las capas raster. Sin embargo, no siempre permiten almacenar
adecuadamente la información de variables continuas. Muchos SIG permiten armar
mapas mixtos con capas vectoriales y rasters, de modo que se pueden efectuar consultas
e histogramas de la información contínua usando categorías discretas.
La discusión acerca de los principios de un SIG y sus potencialidades excede los
objetivos de este informe; sin embargo, se presentan algunos ejemplos de integración
entre información espacial y el SII.

INFORME FINAL
7.1.1- Mapa digital de cuerpos de agua
La tabla CPOSAGUA del SII tiene a su par espacial en la capa temática vectorial de
polígonos de cuerpos de agua de Patagonia, Igm_patagonia_cposagua.shp6 (FIGURA
4.4). Esta capa vectorial fue extraída del SIG250, como se explicó más arriba. Para que
no existan ambivalencias en la denominación de los cuerpos de agua, se adoptó la
información contenida en la tabla de atributos original para generar la tabla CPOSAGUA
del SII. Se tuvo especial atención en que los códigos de identificación (ID_CpoAgua) se
correspondieran.
Contando con esta información espacial, es posible usar las herramientas de
acceso a bases de datos del SIG para asignar información almacenada en el SII a los
elementos de la capa temática. Por ejemplo, se puede recuperarse la información de la
temperatura media superficial del agua en verano para cada cuerpo de agua, y generar
un mapa que emplee una leyenda de gradiente de colores para visualizar estos valores
dentro de un área geográfica.
Se puede visualizar la expresión espacial de una consulta al SII en solo unos

pasos (FIGURA 7.1):
1. Se genera dentro del SII una consulta que recupere las variables que
queremos visualizar para cada cuerpo de agua. No es necesario que
existan datos para todos los elementos de CPOSAGUA. La consulta
necesariamente debe incluir el campo ID_CpoAgua: CPOSAGUA, a fin de
poder usarlo como campo vinculante a los elementos de
Igm_patagonia_cposagua.shp.
2. Tras verificar que la consulta devuelve los datos de interés, se guarda y se
exporta como archivo dBase (.dbf).
3. En un SIG como el ArcView, se crea una vista y se añade la capa temática
Igm_patagonia_cposagua.shp.
4. Se importa la tabla dBase exportada en el paso anterior usando “Add
Table”, y se selecciona el campo ID_CpoAgua.
6
Toda la información vectorial digital se presenta en formato ESRI Shapefile (.SHP), el cual se ha
convertido en un estándar de facto por su amplio uso por parte de numerosos paquetes SIG. Cada capa
temática Shapefile consiste en al menos dos archivos que contienen la definición espacial de los
elementos (.shp y .shx), y un archivo en formato dBase (.dbf) que contiene la tabla de identificadores y
atributos.

INFORME FINAL
5. Se abre la tabla de atributos de y se selecciona el campo Id_CpoAgua de

esta tabla.
6. Usando el comando “Join” (Ctrl+J), se crea el vínculo entre las tablas de
atributos, y ambas se combinan en una sola.
7. Ahora, puede usarse “Edit legend…” para generar una leyenda
usando cualquiera de las variables recuperadas del SII mediante los pasos
anteriores, o usarlas para análisis posteriores.
FIGURA 7.1: Del SII al SIG. Ilustración de los pasos necesarios para llevar los resultados de una
consulta al SII a un mapa, empleando la implementación bajo MS Access del SII y el SIG ESRI
ArcView v.3.3.

INFORME FINAL
7.1.2- Generando mapas de puntos
Aún más simple que en el caso anterior es usar la información del SII que cuenta
con coordenadas puntuales. Tal es el caso de la tabla SITIOS_MUESTREO, o la tabla
CALADOS_GPS, o cualquier consulta que devuelva valores con pares de coordenadas.
Para generar mapas de puntos, es necesario crear una consulta que devuelva, entre
otros atributos, pares de coordenadas geográficas (por ejemplo, los pares de
coordenadas que figuran en SITIOS_MUESTREO o CALADOS_GPS). En este caso, no es
indispensable que exista una clave principal o código de identificación, ya que no es
necesario vincular tablas. La consulta se guarda y se exporta como archivo dBase.
Desde el ArcView, se importa la tabla usando “Add Table”. A partir de ahí, el
archivo de puntos se genera automáticamente usando el comando “Add event
theme…” y seleccionando los campos correspondientes a las coordenadas X e Y
(FIGURA 7.2). ArcView genera automáticamente una capa temática de puntos que usa el
archivo dBase como tabla de atributos, y que puede guardarse para su posterior análisis.
FIGURA 7.2: Importando mapas de puntos. Comandos usados en ESRI ArcView 3.3 para crear una
capa temática de puntos a partir de una tabla .dbf exportada desde el SII.

INFORME FINAL
7.2- USANDO SIGS Y TELEDETECCIÓN COMO FUENTES DE

DATOS
Además de los datos de campo y de la bibliografía, es posible hacer uso de los

SIGs para obtener información adicional. Los polígonos de la capa temática de cuerpos
de agua tienen datos acerca de la geometría de estos elementos: área y perímetro son
fácilmente calculables a partir de cualquier proyección que conserve las áreas. En
combinación con información espacial adicional, como pueden ser Modelos de
Elevación Digital e imágenes satelitales, es posible obtener muchos más datos. Todos
estos datos pueden ser consignados en una tabla e importados al SII mediante un
atributo vinculante ID_Lago.
Como ejemplo de este tipo de análisis, se presenta el caso de la cuenca del río
Manso, estudiada por el GEMaRI durante los veranos de 1998 y 1999.
7.2.1- La cuenca del Manso
La cuenca superior del río Manso tiene su cabecera en los hielos de la porción
sudeste del Volcán Tronador (41º10´S 71º53´W), y vuelca sus aguas a un conjunto de
lagos concatenados por el río Manso, el cual serpentea hasta dirigirse hacia el sur y
luego al este para confluir con los ríos Villegas y Puelo. Hay 6 lagos de dimensiones
considerables en la cuenca: Guillermo, Mascardi, Fonck, Julio A. Roca, Martin y Hess.
Además, existen varios lagos más pequeños, entre los que se pueden mencionar Los
Moscos, Fonck Chico y Hess.
Durante los años 1998 y 1999, el GEMaRI realizó tareas de investigación en los
lagos mencionados, que incluyeron capturas de ictiofauna, mapeos ambientales de las
costas (granulometría, vegetación y características litorales), y la elaboración de mapas
batimétricos mediante hidroacústica.
La información sobre las capturas se incluyó en el SII. Las batimetrías, que

estaban como mapas de isobatas en soporte físico, fueron digitalizadas y
georreferenciadas como capas temáticas de puntos con la profundidad como atributo. A
partir de esos puntos se generaron modelos de profundidad digital (Digital Depth
Models, DDMs) mediante interpolación Kriging, usando el paquete Surfer 7.0. Estos

INFORME FINAL
FIGURA 7.3: DEM “seco” de la cuenca del río Manso. Modelo de relieve generado a partir de la
combinación del DEM SRTM y los DDM generados a partir de las batimetrías hidroacústicas. Se
agregó una capa con los ríos y arroyos y el contorno de los lagos para mejor referencia.
modelos se exportaron como archivos USGS DEM y se importaron en el paquete de
SIG ArcView usando la extensión Spatial Analyst que permite el trabajo combinado
entre grillas raster y capas vectoriales. La información topográfica se obtuvo a partir de
grillas raster derivadas del programa SRTM (Shuttle Radar Topography Mission7),
como un Modelo de Elevación Digital, (Digital Elevation Model, DEM). Además del
mapa de batimetrías, se realizó una combinación entre el DDM y el DEM de modo de
integrar ambos modelos en un modelo topográfico que incorpora los datos batimétricos.
El resultado es un mapa de relieve en el que el agua de los lagos parece haber sido
drenada (FIGURA 7.3).
7
La Misión Topográfica de Radar del Transbordador Endeavour (Shuttle Radar Topography Misión,
SRTM) fue un proyecto internacional encabezado por la Agencia Nacional de Inteligencia Espacial
(NGA) y la Administración Nacional Espacial y Aeronáutica (NASA) del gobierno de los Estados
Unidos. La SRTM obtuvo datos de elevación en una escala cuasi global a fin de generar una base de datos
topográfica de alta resolución del planeta. La misión se basó en un sistema de radar modificado para tal
fin que sobrevoló el planeta durante 11 días a bordo del Transbordador Espacial Endeavour en Febrero
del 2000. Los datos resultantes se volcaron a una grilla de 3 segundos de arco, equivalentes a un tamaño
de celda aproximado de 90×90 metros. (USGS. Reprocessing by the GLCF. 2004. 3 Arc Second SRTM
Elevation, Reprocessed to GeoTIFF. College Park, Maryland: The Global Land Cover Facility,
http://www.landcover.org. Version 1.0. ).

INFORME FINAL
7.2.2- Morfología de los lagos y sus cuencas de drenaje
De la combinación de los polígonos de los lagos y la información del DEM y del

DDM se calcularon para cada lago las profundidades máximas (Zmax) y media (Zmed), el
volumen de agua en Hm3, área y perímetro del espejo de agua, la altura del lago sobre el
nivel del mar, el área del espejo de agua correspondiente a zonas someras (profundidad
menor a 10 m.) y el porcentaje que representa del total, y el área real del lecho lacustre.
A partir del DEM del área, y empleando la extensión de análisis hidrológico de
ArcView, se hizo un análisis de la cuenca hídrica, obteniendo su superficie total,
estructura, área de drenaje total para cada lago, área de drenaje exclusiva, distancia
media de flujo y altitud y pendiente medias para cada subcuenca (FIGURA 7.4).
FIGURA 7.4: Estructura hídrica de la cuenca del río Manso. Mapa que ilustra las subcuencas
exclusivas de cada lago (es decir, las áreas de drenaje exclusivo hacia el lago), y las microcuencas
que la componen.

INFORME FINAL
Estos datos se volcaron en dos tablas.
MORFOLOGIA_LAGOS_DDM
‫ א‬ID_Lago Número entero Identificador de lago
Z_MAX Número entero Profundidad Máxima
Z_MED Número real Profundidad Media
Z_MEDIANA Número entero Mediana de la profundidad
VOL_HM3 Número entero Volumen de agua contenida en el lago
AREA_KM2 Número real Área del espejo de agua
PERIMETRO Número real Perímetro de la costa
Número entero Altura sobre el nivel del mar (según el
ALTURA_DEM DEM)
AreaSomera_km2 Número real Área con profundidad menor a 10 metros
Area_fondo_km2 Número real Superficie real del lecho lacustre
CUENCAS_LACUSTRES_DEM
‫ א‬ID_Lago Número entero Identificador de lago al que drena la
subcuenca
Area_Km2 Número real Área de la subcuenca de drenaje exclusivo
Número real Perímetro de la subcuenca de drenaje
Perimetro_Km exclusivo
MeanFlowDist Número real Distancia media al punto de descarga
Número real Altitud media sobre el nivel del mar de la
AltitudMedia subcuenca de drenaje exclusivo
Número real Pendiente media de la subcuenca de drenaje
PendienteCuenca exclusivo
Area_km2_total Número real Área de la subcuenca completa
Perimetro_km_total Número entero Perímetro de la subcuenca completa
Las tablas se integran al SII mediante la generación de las siguientes relaciones:
ID_Lago: MORFOLOGIA_LAGOS_DDM 1→1 ID_CpoAgua: CPOSAGUA
ID_Lago: CUENCAS_LACUSTRES_DEM 1→1 ID_CpoAgua: CPOSAGUA
A medida que se genera nueva información sobre otras áreas de Patagonia, es

posible ir completando estas tablas con información adicional generada de un modo
similar.

INFORME FINAL
7.2.3- Temperatura superficial de los lagos: usando datos de

teledetección.
Como ejemplo adicional de aplicación de SIGs para obtener información sobre los
cuerpos de agua para su integración al SII, emplearemos el uso de imágenes obtenidas
mediante sensores remotos satelitales para obtener mapas de temperatura superficial de
los lagos de la cuenca del Manso. El mismo procedimiento que se describe es válido
para otros lagos.
La imagen base que se empleó corresponde a datos obtenidos por el sensor ETM+
(Enhanced Thematic Mapper Plus) del satélite LandSat 7 para la banda 6.2 (10.40 µm-
12.5µm) el día 8/12/20018. Esta banda detecta las emisiones al espacio de infrarrojo
térmico, es decir, el calor emitido por los cuerpos en tierra, y está compuesto por celdas
(pixels) de datos de 60x60 metros. Las características físicas de emisión de los cuerpos
de agua los hacen ideales como objeto de análisis mediante teledetección (citar papers
de Schott y otros).
Cada píxel de la imagen satelital tiene un valor que se encuentra entre 0 y 255.
Estos valores deben convertirse a valores de radiancia usando la siguiente ecuación
(Landsat Project Science Office 2005):
× (QCAL − QCALMIN ) + LMIN λ

LMAXλ - LMINλ
Lλ =
QCALMAX − QCALMIN
donde: Lλ = radiancia spectral a la apertura del sensor en watts/(m2 × ster × µm)
QCAL = valor de pixel calibrado en DN (Número digital)
LMINλ = radiancia espectral que está en escala a QCALMIN en watts/(m2 × ster

× µm)
LMAXλ = radiancia espectral que está en escala a QCALMAX en watts/(m2 × ster

× µm)
QCALMIN = valor de pixel calibrado mínimo (correspondiente a LMINλ) en DN
QCALMAX = valor de pixel calibrado máximo (correspondiente a LMINλ) en DN

= 255
Los valores de las variables mencionadas habitualmente se especifican en un
8
U.S. Geological Survey. 12-08-2000. Landsat ETM+ Scene, WRS-2 Path 232, Row 89, Level 1G.
Sioux Falls, South Dakota: USGS. Datos obtenidos mediante el Global Land Cover Facility,
http://www.landcover.org.

INFORME FINAL
archivo de texto anexo al set de datos satelitales, y varían con cada set.
Aplicando esta fórmula a todos los pixels de la imagen para el área de interés, se
obtiene una imagen con valores de radiancia reales (medidos en watts/(m2 × ster × µm)).
A partir de los valores de radiancia, la temperatura al satélite puede calcularse (Landsat
Project Science Office 2005) usando la ecuación
K2
T=
⎛K ⎞
ln⎜⎜ 1 + 1⎟⎟
⎝ Lλ ⎠
Donde:
T = Temperatura efectiva al-satélite en grados Kelvin (temperatura absoluta)
K2 = Constante de calibración 2 (=1282.71ºK)
K1 = Constante de calibración 1 (=666.09 watts/(m2 × ster × µm))
Lλ = Radiancia espectral in watts/(m2 × ster × µm)
La aplicación de la fórmula a la imagen de radiancia resulta en una termografía. A
FIGURA 7.5: Temperatura superficial de los lagos de la cuenca del Manso. Valores obtenidos
mediante teledetección para fines de la primavera de 2001.Tm representa la temperatura media
obtenida de promediar los valores de todas las celdas de cada lago.

INFORME FINAL
partir de esta imagen, y usando los polígonos de los lagos como máscara de análisis, es
posible recortar los datos referidos a los cuerpos de agua, obteniendo un mapa de la
distribución espacial de temperaturas superficiales del agua en todos los lagos de la
cuenca (FIGURA 7.5).
Una consulta al mapa temático de temperatura superficial generado empleando los

polígonos de los lagos permite obtener valores de temperatura media, mínima, máxima,
rango y desvío estandar para cada espejo de agua. Estos valores fueron consignados en
una tabla para su importación desde el SII.
TEMP_LAGOS_L7B6_20011208
‫ א‬ID_Lago Número entero Identificador de lago
Tmed Número real Temperatura superficial media
Tmin Número real Temperatura superficial mínima
Tmax Número real Temperatura superficial máxima
Trng Número real Rango de temperatura superficial
Número real Desvío estándar de la temperatura
Tsd superficial
Al igual que en los casos anteriores, esta tabla se integra al SII mediante la
relación
ID_Lago: TEMP_LAGOS_L7B6_20011208 1→1 ID_CpoAgua: CPOSAGUA
Esta tabla representa valores de temperatura para una única fecha. Contando con
información de otras fechas, sería posible realizar un seguimiento de la evolución
térmica superficial de los lagos. Para tal caso, convendría generar una clave principal en
la tabla, y agregar un campo Fecha a fin de poder incluir en la tabla múltiples registros
para cada cuerpo de agua.

INFORME FINAL
8- CONCLUSIONES
A lo largo de los dos años que duró este proyecto, se cumplió su objetivo general
y muchos de los objetivos parciales. El SII es una realidad, actualmente implementado
como una base de datos Microsoft Access, pero planteado en una estructura
independiente de la plataforma. Su uso permite obtener datos estandarizados y
comparables entre distintos puntos geográficos y temporales. Conjuntamente a su
desarrollo, se llevaron a cabo tareas de formación y entrenamiento en los fundamentos
de su uso, a fin de maximizar su empleo y su aprovechamiento.
8.1- TAREAS A FUTURO

Pese a que las bases estructurales del SII están asentadas, aún quedan numerosas
tareas por realizar. Por un lado, la integración de la información derivada de estudios
posteriores sobre los peces capturados, tal como los datos de escamas y otolitos, los
análisis de contenidos estomacales, o los datos obtenidos mediante hidroacústica, debe
estandarizarse, tabularse e integrarse al sistema, usando los identificadores de captura
como elemento vinculante. Por otro, comenzar a usar las consultas al SII para realizar
una evaluación de sus posibilidades: estudios de selectividad de mallas, curvas de
largo/peso, estratificación de la distribución de los peces, matrices de presencia y
ausencia, etc.
Otro objetivo pendiente es implementar el SII mediante un administrador de bases
de datos de Código Abierto (Open Source) que cumpla con todos los estándares, y que
permita usar el lenguaje SQL para realizar consultas locales y remotas. Esto permitirá la
integración de la base de datos a aplicaciones de acceso remoto, y podría permitir
generar un sitio de consultas dinámicas permanente disponible a través de Internet.
8.2- EL SII COMO HERRAMIENTA

El Sistema de Información Integral desarrollado a lo largo de este proyecto aúna
en una única estructura datos de diversa naturaleza relacionados con los cuerpos de agua
de Patagonia y su ictiofauna. Estos datos se originaron en una década de trabajos de
investigación del Grupo de Evaluación y Manejo de Recursos Ícticos, o a partir de
análisis bibliográficos o geográficos. Es una herramienta para ordenar el
almacenamiento de la información, y facilitar la integración de datos externos y la
recuperación de datos para su análisis. Las propiedades de las bases de datos

INFORME FINAL
relacionales permiten usar el SII como medio para realizar consultas novedosas e
indagar nuevos enfoques y relaciones entre las numerosas variables bióticas y abióticas
que conforman las distintas escalas de los ecosistemas de agua dulce.
Como toda herramienta, su utilidad depende siempre de la habilidad de quien la
usa. Buena parte del uso adecuado de una herramienta está dado por el conocimiento de
sus principios de funcionamiento: este aspecto intenta ser cubierto por el presente
informe. El texto también intenta resaltar las potencialidades de expansión del SII:
efectivizar tal expansión es una tarea a futuro encomendable a quienes deseen hacer
crecer y sacar el máximo provecho a este desarrollo.

INFORME FINAL
9- REFERENCIAS BIBLIOGRÁFICAS
BAIGUN, C.R., Y R.O. ANDERSON. 1993. Structural indices for stock assessment of
and management recomendations for pejerrey (Odontesthes bonariensis) in Argentina.
North Amer. J. Fish. Manag.: 600-608.
BAIGUN, C., Y R.L. DELFINO. 1994. Relación entre factores ambientales y biomasa
relativa de pejerrey en lagos y embalses templado-calidos de la Argentina. Acta Biol.
Venez. 15: 47-57.
BAIGUN, C., Y M.C. MARINONE. 1995. Cold-temperate lakes of South America: do they
fit northern hemisphere models? Arch. Hydrobiol. 135:23-51.
CODD, E.F. 1970. A relational model of data for large shared data banks.
Communications of the ACM 13(6): 377-387.
CODD, E. F.1972. Further Normalization of the Data Base Relational Model. En Data
Base Systems, Courant Computer Science Symposia 6. Prentice-Hall.
DATE, C.J. Y R. FAGIN. 1992. Simple conditions for guaranteeing higher normal forms
in relational databases. ACM Transactions on Database Systems 17(3):465-476.
GIRAUT, M., S. LUDUEÑA, A. POSTIGLIONI, C. REY, M. DENTE Y I. SOL. 2000.

Cartografía hídrica superficial digital de la República Argentina. Subsecretaría de
Recursos Hídricos, Buenos Aires.
JOBLING, M. 1995. Enviromental Biology of Fishes. Chapman & Hall, London.
LANDSAT PROJECT SCIENCE OFFICE. 2005. Landsat-7 Science Data User's Handbook.
Landsat Project Science Office, Goddard Space Flight Center, National AeroSpatial
Agency. Greenbelt, Maryland.
http://ltpwww.gsfc.nasa.gov/IAS/handbook/handbook_toc.html
LARA, A. P. RUTHERFORD, C. MONTORY, D. BRAN, A. PÉREZ, S. CLAYTON, J. AYESA, D.

BARRIOS, M. GROSS Y G. IGLESIAS. 1999. Mapeo de la Eco-Región de los Bosques
Valdivianos. Escala 1:500.000. Boletín Técnico de la Fundación Vida Silvestre
Argentina, nº 51. 27 pp. Fundación Vida Silvestre Argentina, Buenos Aires.

INFORME FINAL
PARKER, I.M., D. SIMBERLOFF, W.M. LONSDALE, K. GOODELL, M. WONHAM, P.M.

KAREIVA, M.H. WILLIASON, B. VON HOLLE, P.B. MOYLE, J.E. BYERS Y L.
GOLDWASSER. 1999. Impact: toward a framework for understanding the ecological
effects of invaders. Biological Invasions 1: 3-19.
PASCUAL, M., P. MACCHI, J. URBANSKI, F. MARCOS, C. RIVA ROSSI, M. NOVARA Y P.

DELL´ARCIPRETE. 2002. Evaluating potential effects of exotic freshwater fishes from
incomplete species presence-absence data. Biological Invasions 4:101-113.
PASCUAL, M.A., J.M. ORESANZ, A.M. PARMA Y S.L. Saba. 1998. The patagonian
challenge: melding conservation with development. En: Fiedler, P.L., and P.M. Kareiva
(eds) Conservation Biology for the Coming Decade, 2nd edition, pp. 410-425.
Chapman & Hall, New York/London.
PRAGUE, C.N. Y M.R. IRWIN. 2001. Access 2002 Bible. Hungry Minds, New York.
QUIROS, R. 1988. Mapas batimétricos y parámetros morfométricos de lagos

patagónicos del Neuquén, de Río Negro y del Chubut (Argentina).. Informes
Técnicos del Departamento de Aguas Continentales No 5,48pp. Instituto Nacional de
Investigacion y Desarrollo Pesquero, Mar del Plata.
QUIROS, R. 1988. Relationships between air temperature, depth, nutrients and

chlorophyll in 103 Argentinian lakes. Verh. Internat. Verein. Limnol. 23: 647-658.
QUIROS, R. 1987. Factores que afectan la distribución de salmónidos en Argentina. En

Vila, I. (ed.) (p: 163-183) Segundo Taller Internacional sobre Ecología y Manejo de
Peces en Lagos y Embalses. Doc. Tec. 9, 196 pp. Santiago, Chile. 28 septiembre - 2
octubre 1987. COPESCAL/FAO.
QUIROS, R.1990a. Predictors of relative fish biomass in lakes and reservoirs of

Argentina. Can. J. Fish Aquat. Sci. 47: 928-939.
QUIROS, R. 1990b. Factors related to variance of residuals in chlorophyll total

phosphorus regressions in lakes and reservoirs of Argentina. In R.D. Gulati,
E.H.R.R.Lammers, M.L. Meijer, and E. van Donk (eds.) Biomanipulation - Tool for
Water Management. Hydrobiología 200-201: 343-355.
QUIROS, R. 1991. Empirical relationships between nutrients, phytoplankton and

INFORME FINAL
zooplankton, and relative fish biomass in lakes and reservoirs of Argentina. Verh.
Internat. Verein. Limnol. 24: 1198-1206.
QUIROS, R. 1995. The effects of fish assemblage composition on lake water quality.
Lake and Reservoir Management 11: 291-298.
QUIROS, R. 1998a. Classification and state of the environment of the Argentinean lakes.
In ILEC Study Report for the the Lake Environment Conservation in Developing
Countries. Argentina. Chapter 2. Lakes of Argentina. Section 1. Papers presented
at ILEC Workshop on Better Management of the Lakes of Argentina. San Martin
de los Andes, Argentina, 24-25 October, 1997. pp 29-50. International Lake
Environment Committee Foundation (ILEC). Japan. 229p.
QUIROS, R. 1998b. Fish effects on trophic relationships in the pelagic zone of lakes.
Hydrobiologia 361: 101-111.
QUIROS, R. 1998c. Trophic cascade effects in a temperate - subtropical water body

continuous. Verh. Internat. Verein. Limnol. 26 (5): 2315-2319.
QUIROS, R. 2004. Cianobacterias en lagos y embalses de Argentina: década del 80. Serie
de Documentos de Trabajo del Área de Sistemas de Producción Acuática. Documento
No 2, 23 p. Departamento de Producción Animal, Facultad de Agronomía, Universidad
de Buenos Aires, Buenos Aires.
QUIROS, R., C.R.M. BAIGUN, S. CUCH, R. DELFINO, A. DE NICHILO, C. GUERRERO, M.C.

MARINONE, S. MENU MARQUE, Y M.C. SCAPINI. 1988. Evaluación del rendimiento
pesquero potencial de la República Argentina I: Datos 1. Informes Técnicos del
Departamento de Aguas Continentales. Informe Técnico No 7, 55p. Instituto Nacional
de Investigación y Desarrollo pesquero, Mar del Plata.
QUIROS, R., Y M.B. BOVERI. 1999. Fish effects on reservoir trophic relationships (p:
529-546). In J.G. Tundisi and M.Straskraba (eds.) Theoretical Reservoir Ecology and
Its Applications. 585 pp. International Institute of Ecology, Brazilian Academy of
Sciences, Backhuys Publishers, Leiden, Netherlands.
QUIROS, R., S. CUCH, Y C.R.M. BAIGUN. 1986. Relación entre abundancia de peces y
ciertas propiedades fisicas, químicas y biológicas, en lagos y embalses patagónicos

INFORME FINAL
(Argentina), (p: 180-202). En Vila, I. y E. Fagetti (eds.). Trabajos presentados al

Taller Internacional sobre Ecología y Manejo de Peces en Lagos y Embalses.
Doc.Tec., (4): 237 pp. Santiago, Chile, 5-10 de noviembre de 1984. COPESCAL/FAO.
QUIROS, R., Y E. DRAGO. 1985. Relaciones entre variables físicas, morfométricas y

climáticas en lagos patagónicos. Rev. Asoc. Cs. Nat. Litoral 16: 181- 199.
QUIROS, R., Y E. DRAGO. 1999. The environmental state of the Argentinean Lakes: An
overview. Lakes and Reservoirs: Research & Management 4: 55-64.
RINGUELET. R.A. 1975. Zoogeografía y ecología de los peces de las aguas continentales
de la Argentina, y consideraciones sobre las áreas ictiológicas de América del Sur.
Ecosur 2(3), pp. 1-122.
TEMPORETTI, P.F., M.F. ALONSO, G. BAFFICO, M.M. DIAZ, W. LÓPEZ, F.L. PEDROZO Y
P.H. VIGLIANO. 2001. Trophic state, fish community and intensive production of
salmonids in Alicura Reservoir (Patagonia, Argentina). Lakes & Reservoirs: Research
and management 6: 259-267.
VIGLIANO, P.H. 1996. Informe final Proyecto B019 Evaluación y Manejo de

Recursos Icticos: la pesquería del lago Gutiérrez. CRUB-UNC, Bariloche.
VIGLIANO, P.H. 1997. Pesca deportiva y recreacional, un recurso poco conocido. Actas I
Jornadas Regionales Sobre Medio Ambiente, La Plata 1: 53-60.
VIGLIANO, P.H. 1999. Informe de avance Subproyecto B923 Evaluación y Manejo

de Recursos Icticos, Proyecto B920 Programa de Recursos Acuáticos en Ambientes
Patagónicos. CRUB-UNC, Bariloche.
VIGLIANO, P.H. 2005. Informe final Proyecto B940 - Programa de Características

Ópticas, Composición Química y Comunidades Bióticas de Ambientes Acuáticos
Patagónicos. CRUB-UNC, Bariloche.
VIGLIANO, P.H., G. LIPPOLT, A. DENEGRI, M. ALONSO, P. MACCHI Y C.O. DYE. 2000.

The human factors of the sport and recreational fishery of San Carlos de Bariloche, Río
Negro, Argentina. Fisheries Research 49: 141-153.

INFORME FINAL
View publication stats

Zattara 2005 - Sistema Integral de Informacion de Comunidades de Peces

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Zattara 2005 - Sistema Integral de Informacion de Comunidades de Peces

Cargado por

Copyright:

Formatos disponibles

See

Desarrollo de un Sistema Integral de

Technical Report · December 2005

The Bull-headed Dung Beetle Genome Project View project

San Carlos de Bariloche

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 2

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 3

6.1.2 – Añadiendo campos nuevos a entidades existentes ..................................... 61

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 4

Con esos objetivos en mente, el Informe se estructura en capítulos, cada uno de

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 5

y generar la estructura contenedora que es el núcleo del SII.

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 6

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 7

maculatus, o la lamprea Geotria australis). Por otro lado, hay un número

1.2- EL GRUPO DE EVALUACIÓN Y MANEJO DE RECURSOS

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 8

Esta información, registrada

1.3- SISTEMA INTEGRAL DE INFORMACIÓN: UNA BASE DE

Dada la necesidad de encontrar una metodología que permita organizar la

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 9

información existente acomodándola en una estructura que permita facilitar su

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 10

Consultas relacionales: datos viejos, enfoques nuevos

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 11

2 - INTRODUCCIÓN A LAS BASES DE DATOS

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 12

inutilizable, y se abocó a la tarea de reorganizar todos los artículos. Estableció una

2.2- MODELOS DE BASES DE DATOS

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 13

2.2.1- Bases de datos de archivo plano

2.2.2- Bases de datos jerárquicas

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 14

conoce como hojas. Un registro de la base consiste en uno o más agrupamientos de

2.2.3- Bases de datos reticulares

Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental

2.2.4- Bases de datos relacionales

Éste es el modelo más utilizado en la actualidad para modelar problemas reales y

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 15

2.2.5- Bases de datos orientadas a objetos

El modelo orientado a objetos apunta a solucionar la principal limitación de las

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 16

en los datos complejos típicos de los GOBs.

2.3- CARACTERÍSTICAS DE LAS BASES DE DATOS

A partir de los modelos descritos sucintamente en la sección previa, la selección

2.3.1- Términos básicos y definiciones

Una base de datos relacional puede caracterizarse como un conjunto de tablas

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 17

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 18

2.3.2- Las reglas de Codd

Una base de datos relacional (BDR) va más allá de información organizada en

Regla de Codd nº 1: la información se presenta en tablas.

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 19

Regla de Codd nº2: los datos son accesibles lógicamente

Regla de Codd nº4: la base de datos es auto-descriptiva.

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 20

Regla de Codd nº5: un único lenguaje se usa para comunicarse con el

Regla de Codd nº6: se proveen alternativas para visualizar los datos

Regla de Codd nº7: las operaciones de conjuntos o relacionales deben

BECA DE INICIACIÓN “DR. GREGORIO ALVAREZ” 21

Regla de Codd nº8: independencia física de los datos

Regla de Codd nº9: independencia lógica de los datos

Regla de Codd nº10: la integridad de la información es una función

Regla de Codd nº11: existe soporte para la operación distribuida