GIS Clase4

La información no espacial Arq. M.
Frassia
CLASE 4: LA NATURALEZA DE LA INFORMACIÓN NO

ESPACIAL
1. Presentación.............................................................................................................................. 2
2. INTRODUCCION A LOS CONCEPTOS PRINCIPALES .......................................................... 3
3. CASO ........................................................................................................................................ 4
4. CONOCIMIENTOS.................................................................................................................... 6
4.1. LA INFORMACIÓN COMO RECURSO ............................................................................. 6
4. 2 LAS BASES DE DATOS EN EL GIS.................................................................................. 8
4.3 EL MODELO RELACIONAL ................................................................................................ 9
4. 3.1. UN POCO DE HISTORIA ........................................................................................... 9
4.3.2. TÉRMINOS TÉCNICOS ................................................................................................ 11
4.3.3. Postulados ................................................................................................................. 13
4.3.4. Relaciones entre tablas.............................................................................................. 16
4.3.5. Tipo de relaciones...................................................................................................... 17
4.3.6. Integridad relacional................................................................................................... 20
4.3.7. Vistas y Tablas........................................................................................................... 21
4.3.8. SQL - STRUCTURED QUERY LANGUAGE ............................................................. 21
5. MODELO EAR (ENTIDAD-ATRIBUTO-RELACIÓN) .......................................................... 23
1ER PASO: Se deben identificar las entidades..................................................................... 24
2DO PASO: Se debe identificar las relaciones entre tablas especificando tipo de relación . 24
3ER PASO: Se debe identificar los atributos de las entidades ............................................. 25
4TO PASO: Se deben derivar nuevas tablas ........................................................................ 26
6. VENTAJAS Y DESVENTAJAS DEL MODELO ................................................................... 30
6.1 Ventajas ......................................................................................................................... 30
6.2 Desventajas ................................................................................................................... 30
Nota final.................................................................................................................................. 31
EVALUACIÓN ............................................................................................................................. 32
GLOSARIO.................................................................................................................................. 33
1
La información no espacial Arq. M. Frassia
1. Presentación
Hasta el momento, Usted ya dispone de conocimientos básicos para comprender qué el GIS,
la naturaleza de la información geográfica, los modelos raster y vectorial para la
representación de la información y qué software resultan convenientes, entre otros temas.
Probablemente disponga también de información temática. Por lo tanto, el problema en esta
clase es tratar de comprender cuál es el modelo que posibilita la unión de esta información
con el elemento espacial.
• Debe saber que para gestionar la información temática, los GIS tienen un modelo de
bases de datos propio y además, soporta la importación de otros modelos
comerciales como Microsoft Accesss, dBASE, Oracle, etc.
• Esta aptitud es la que posibilita que los usuarios utilicen las capacidades inherentes de las
bases de datos externas, que en general son más potentes y versátiles.
En esta clase encontrará respuesta a las siguientes preguntas:

¿Cuál es el modelo general que se utiliza actualmente para guardar información?
¿Cómo hacer para unir las bases de datos de un GIS con otras bases existentes?
¿Qué es una base de datos?
¿Por qué todos los software de bases de datos declaran ser relacionales?
¿Cuáles son los términos técnicos que debo conocer?
¿Qué postulo Codd en un ya famoso artículo de 1970 que sentó las Bases de Datos
Relacionales?
Los Links recomendados para esta clase son:

• CURSOS GRATUITOS BASES DE DATOS
http://www.giscampus.org/gis.htm
http://www.abcdatos.com/tutoriales/index.html
2
2. INTRODUCCION A LOS CONCEPTOS PRINCIPALES

Estos son algunos de los conceptos centrales para la comprensión de los contenidos
de esta clase:
La información no espacial se guarda en bases de datos relacionales.
• Una base de datos esta formada por diferentes tablas que guardan información sobre
elementos semejantes (por ejemplo una tabla guarda la información sobre las parcelas y
otra sobre los edificios).
• Un identificador, también llamado
etiqueta, reconoce cada objeto: una
ciudad de otra, un río de otro, etc.
• Los identificadores deben ser únicos e
inequívocos ya que proveen el
mecanismo por el cual las tablas se unen
entre sí.
• Las etiquetas pueden ser un nombre, Ej.
"Córdoba", una descripción, "Casa de
Gobierno " o un número distintivo, Ej. "el
número del documento de identidad".
BASES DE DATOS RELACIONALES
3
3. CASO
En esta oportunidad, vamos a comenzar con el comentario del biólogo español Ángel Manuel
Felicísimo Pérez que relata las exigencias del Municipio para acceder a un puesto de trabajo
en el equipo de Sistemas de Información Geográfica municipal.
PRÓLOGO:
Aparece una plaza de funcionario para el Ayuntamiento.
NUDO:
Me acerco al citado Ayuntamiento y examino las bases de la convocatoria. Os voy a ahorrar
detalles y me limitaré a una breve síntesis (el cabreo me impidió tomar notas detalladas):
Titulación exigida: diplomado en informática
Fase de concurso de méritos: entre otros detalles no se considera siquiera la experiencia de
trabajo en SIG y sí puntúa, sin embargo, el haber trabajado como técnico en informática.
(Nota: los datos y títulos anteriores están citados de memoria por lo que pueden no ser
exactos aunque sí garantizo que no violan la esencia del asunto.)
DESENLACE:
Un técnico en SIG debe ser informático (grado medio). En conclusión, abstenerse geógrafos
y, por supuesto, biólogos, geólogos, topógrafos y demás gente espuria (que no se me juzgue
mal, yo soy biólogo).
Un técnico en SIG debe saber con exquisito detalle todos las intimidades del bus IEEE, de
gestión de redes, intranets, MSAccess (!) ...
También debe saber algo de SIG ya que los últimos 5 o 6 temas hacen referencia a ellos con
un enfoque muy general (cuando no francamente erróneo desde en punto de vista
conceptual).
Da igual que hayas trabajado en SIG durante 10 años ya que este aspecto no se considera de
interés en la fase de concurso.
En fin, saludos
Ángel Manuel Felicísimo Pérez
¿Y usted se preguntará porque comenzamos con este ejemplo?
Pues queda claro en el mensaje, que un técnico en GIS no puede dejar se saber sobre bases
de datos relacionales. Por lo cual le presentamos a continuación algunos conceptos que lo
ayudarán a comprender cómo funciona una base de datos y cuál es su importancia para el
GIS.
Pero antes de comenzar le planteamos el siguiente problema que deberá resolver una vez
finalizada la clase 8. Le proponemos que imprima esta problema y que vaya pensando en el a
medida que avanza la clase.
4
Un municipio requiere una base de datos para administrar sus registros catastrales. El
relevamiento preliminar reveló que se necesitará guardar información acerca de manzanas
(identificador, superficie, barrio al cual pertenecen), lotes (identificador, dirección, superficie,
frente), unidades funcionales (identificador, superficie, propietarios, valuación fiscal) y
propietarios (nombre y apellido y teléfonos, dirección de facturación). Por razones de
comodidad, en una tabla aparte se desea tener la información acerca de las unidades
funcionales, como una descripción de la misma y un plano escaneado).
Las “reglas de la organización” indican que:
• En una manzana hay varios lotes.
• En cada lote hay varias unidades funcionales.
• Una unidad funcional puede tener varios propietarios.
• Un mismo propietario puede tener varias unidades funcionales.
• Un mismo propietario puede tener varios teléfonos.
• Por supuesto el municipio quiere pasar de sus archivos papel a archivos digitales y
quiere que esta información se refleje en un GIS.
5
4. CONOCIMIENTOS
4.1. LA INFORMACIÓN COMO RECURSO
Los datos son observaciones que realizamos en el mundo real.
• Son recopilados como hechos ó evidencias

• Adquieren significado a partir de su procesamiento
DIFERENCIAS ENTRE DATOS E INFORMACION
• Hay claras diferencias entre datos e información aunque generalmente se los confunde.
Para tratar de entender la diferencia utilizaremos un ejemplo:
Dato: 36 Como es simplemente un número no tiene en sí mismo ningún

significado especial. Para que sea de utilidad es necesario
interpretarlo en referencia a algún contexto particular. Como por
ejemplo, especificar que ésta es la temperatura máxima registrada
en la ciudad de Buenos Aires, en determinado año.
Información: 36° Temperaturas máxima registradas en la ciudad de Buenos Aires, en

el año 1994.
De este ejemplo podemos inferir que la información es cualitativamente más que los datos
y esto es necesariamente así porque la información debe servirle al usuario para tomar
decisiones. Debe tener utilidad para él, condición que no siempre se cumple con los datos. La
información, por lo tanto, es siempre contextuada y refiere a un proceso analítico sobre el dato.
6
Desde el punto de vista tecnológico, la Integración de Aplicaciones, la reutilización y el fácil

acceso a los datos son factores críticos de mucha importancia.
Al contar con Datos confiables y consistentes podemos generar Información que nos permita
tomar las decisiones más convenientes. A partir de la información podemos generar
Conocimiento (que no es más que Información + Valor), hasta llegar al tope de la pirámide de
valor, la Sabiduría, estatus en el cual contamos con la información valiosa en el momento,
lugar y tiempo adecuados para la generación de ventajas competitivas.
En las últimas décadas se han realizado importantes avances en la formalización de los

modelos que definen la estructura organizativa de los datos, permitiendo su almacenamiento,
manipulación y consulta. Así se ha llegado al concepto de base de datos relacional.
Una base de datos es un conjunto de información relacionada que pertenece a una

organización (por Ej. una empresa) y que está agrupada como un todo. En la base de datos
de una juguetería, por ejemplo, estará reunida la información de los juguetes (precio, cantidad
en stock), así como los datos de los proveedores (dirección, teléfono, saldo deudor), clientes (si
se desea llevar información individualizada de cada uno de ellos), empleados (salarios,
presentismo, comisiones de los vendedores), de la contabilidad (cobranzas, pagos,
liquidaciones), etc.
Tener “agrupada como un todo” esta información trae muchos beneficios, como reducir la
redundancia y la inconsistencia de los datos guardados.
7
4. 2 LAS BASES DE DATOS EN EL GIS
El GIS tiene la capacidad de tomar datos y procesarlos, para entregar información útil. Por
ese motivo que los GIS despiertan gran entusiasmo: tienen la habilidad de agregar valor a los
datos existentes.
El GIS se caracteriza por que utiliza bases de datos asociadas. Cada objeto gráfico
representado tiene atributos asociados. Volviendo al ejemplo de la Escuela 23 podemos
presuponer que sin duda la base de datos incluye información como el nombre, la dirección,
cantidad de alumnos, cantidad de cargos, teléfonos, tipo, etc.
Probablemente usted ya disponga de información de este tipo en tablas, por lo cual el problema
se remite a tratar de comprender cual es el modelo que posibilita la unión de esta información
con el elemento espacial.
TABLA CON INFORMACIÓN
En principio, debe saber que:
• Para gestionar la información temática, los GIS tiene un modelo de bases de datos propio
y soporta la importación de otros modelos comerciales como Microsoft Accesss,
dBASE, Oracle, etc. Esta aptitud es la que posibilita que los usuarios utilicen las
capacidades inherentes de las bases de datos externas, que en general son más
potentes y versátiles.
• Las tablas se conectan a través de un campo común que ambos archivos poseen:
específicamente el identificador que posibilita la unión entre los elementos espaciales y
las tablas externas que habitualmente tienen las organizaciones. En nuestro ejemplo el
identificador Escuela 23 debería posibilitar la unión del elemento gráfico con las bases
provistas por el Ministerio de Educación.
• Pero antes de relacionar tablas es importante comprender las posibles relaciones que
entablan entre ellas, ya que los fabricantes de software presuponen que cuando se opera
un GIS se conoce el modelo relacional.
8
4.3 EL MODELO RELACIONAL
4. 3.1. UN POCO DE HISTORIA
En los años 60, cuando comenzaron los primeros desarrollos con computadoras, la atención
estaba centrada en la resolución de problemas particulares: si era necesario procesar
información se programaba especialmente una aplicación particular que solucionaba el
problema requerido. El ejemplo típico es la liquidación de sueldos de los empleados: una tarea
manual muy repetitiva que se automatiza para bajar el costo del procesamiento.
Como el objetivo era la resolución de problemas, se prestaba poca consideración al

almacenamiento de datos. Normalmente, se archivaban en un formato específico (no-
estándar) para cada aplicación.
Este modelo fue adecuado mientras las aplicaciones permanecieron independientes. Los
problemas comenzaron cuando se hizo necesario compartir información y los formatos
entre aplicaciones no eran compatibles. Por ejemplo, “Compras” tenía los artículos comprados,
“Almacén” los que estaban en stock y “Ventas” los artículos vendidos; pero por más que los
tres refirieran a los mismos datos (los artículos que la empresa comercializaba), no podían
compartir esa información porque la aplicación que cada sector usaba, guardaba la información
en un formato distinto.
Podrá imaginarse el sin número de problemas que esto acarreaba. En principio, las
organizaciones se veían obligadas a mantener varias copias de la misma información en los
diferentes formatos que requerían las aplicaciones existentes. Esto inevitablemente creaba
redundancia de información (imaginen en una municipalidad la cantidad de veces que era
necesario guardar nombre y dirección de los contribuyentes), que a su vez traía aparejado la
inconsistencia de la información, ya que múltiples copias conllevan inevitablemente a errores
y a un altísimo costo de mantenimiento (¡sí un contribuyente cambiaba de domicilio había que
cambiar el dato en tantos archivos como aplicaciones hubiera!).
Cuando la ciencia de la computación y la tecnología avanzaron, se volvió imperiosa la

necesidad de crear un sistema que concentrara los archivos en uno, al cual accederían todas
las aplicaciones de la organización. Se buscaba en definitiva, que todas las aplicaciones en
una organización (los sistemas de ventas, contabilidad, compras, etc.) compartieran un solo
almacén de datos.
El objetivo era la disminución de los graves problemas de inconsistencia y duplicidad de

información: se pretendía, por ejemplo, que al ingresan los datos del contribuyente, este
registro sirviera a todas las aplicaciones. De esa forma, si este contribuyente cambiaba de
domicilio, todas las aplicaciones lo registraban a pesar de que se cambiaba en un solo lugar.
9
Es así como nacen el Database Management System (DBMS) o Sistema de Gestión de

Base de Datos. La base de este modelo fue propuesto originariamente un matemático de IBM
llamado Edward Codd en un ya famoso artículo del año 1970. Aunque previamente habían
surgido otros modelos (como el modelo jerárquico de datos, o el de red), fueron las “Bases de
Datos Relacionales” las que fueron adoptadas virtualmente por todos sistemas comerciales
conocidos. Gracias a su coherencia y facilidad de uso, el modelo se ha convertido a partir de
los años 80 en el más usado.
Aporta las siguientes ventajas
• Independencia lógica y física de los datos de las aplicaciones

• Redundancia mínima ya que la base de datos funciona como repositorio común de datos
para distintas aplicaciones.
• Acceso concurrente por parte de múltiples usuarios y control de concurrencia
mediante técnicas de bloqueo y permisos.
• Distribución espacial de los datos ya que la independencia lógica y física facilita las
bases de datos distribuidas. Los datos pueden encontrarse en otra habitación, otro edificio
e incluso otro país. El usuario no tiene por qué preocuparse de la localización espacial de
los datos a los que accede.
• Integridad de los datos ya que se puede adoptar medidas de seguridad que impiden que
se introduzcan datos erróneos. Esto puede suceder tanto por motivos físicos (defectos de
hardware, actualización incompleta debido a causas externas), como de operación
(introducción de datos incoherentes, por ejemplo, poner 1456 como año de nacimiento de
un votante).
• Consultas complejas por más de una condición
• Seguridad de acceso y auditoria que posibilita otorgar derecho de acceso diferenciados a
personas y organismos. El sistema de auditoria mantiene el control de acceso a la base de
datos, con el objeto de saber qué o quién realizó una determinada modificación y en qué
momento.
• Respaldo y recuperación que posibilita a un sistema de base de datos recuperar su
estado en un momento previo a la pérdida de datos.
• Acceso a través de lenguajes de programación estándar que brindan la posibilidad ya
mencionada de acceder a los datos de una base de datos mediante lenguajes de
programación ajenos al sistema de base de datos propiamente dicho.
10
4.3.2. TÉRMINOS TÉCNICOS
Es importante que preste especial atención a esta sección ya que introduce los términos
técnicos a los cuales haremos referencia en la próxima clase.
• Datos: Los datos son hechos o cosas del mundo lo suficientemente importante como para
ser registrados. Son recopilados como hechos o evidencias. Adquieren significado a partir
de su procesamiento para convertirse en información. Al hablar de datos, hacemos
referencia a un concepto amplio que puede incluir texto, imágenes, sonido, reglas de
decisión, etc.
• Información: Es el resultado del análisis de los datos. Por ejemplo, un satélite colecciona
datos (valores numéricos) que una vez volcados en un mapa, son interpretados por una
persona que identifica los diferentes usos del suelo en determinada región.
• Inconsistencia de datos: utilizaremos un ejemplo. Digamos que empleamos un archivo
para almacenar la información de clientes. Supongamos que tenemos varios programas
que utilizan esa información y que en un momento dado se pueden tener registros
duplicados con atributos diferentes. Por ejemplo, una persona cambia de dirección y al no
tener una estructura bien definida, no alteramos el registro, sino que lo agregamos una
segunda vez con la nueva dirección. De esta manera, tendremos a la misma persona con
dos datos diferentes y sin posibilidad de saber cual es la correcta.
• Base de datos: Una base de datos es un conjunto de información relacionada con un
asunto o con una finalidad.
Se compone de entidades (cosas u objetos del mundo real distinguibles de todos los
demás objetos) que poseen atributos (propiedades o características de las que se quiere
llevar registro).
Las entidades pueden ser cosas concretas, como una persona o un libro, o abstractas,
como un préstamo o una venta.
Los atributos de Los atributos de la

la entidad entidad “Venta”
“Alumno” podrían ser Fecha,
podrían ser DNI, Tipo de Factura, Nº de
nombre, Factura, Nombre del
apellido, carrera, Vendedor, Artículos
materias Comprados, etc.
cursadas, notas
obtenidas, etc.
• Manejador de Bases de Datos (DBM por sus siglas en inglés)

De acuerdo a Ullman 1999: ``Un modelo de datos es un sistema formal y abstracto que
permite describir los datos de acuerdo con reglas y convenios predefinidos. Es formal pues
los objetos del sistema se manipulan siguiendo reglas perfectamente definidas y utilizando
exclusivamente los operadores definidos en el sistema, independientemente de lo que
estos objetos y operadores puedan significar. ‘‘
En definitiva es un programa que corre en una computadora que intermedia entre los datos
y las aplicaciones que los utilizan, y permite:
- Crear, modificar y borrar estructuras de datos
- Ingresar, actualizar y borrar registros
- Recuperar información
- Mantener la seguridad e integridad de los datos
• Query o consulta: es una declaración o grupo de declaraciones en idioma formal que
permite comunicarse con el DBMS para recuperar la información almacenada.
11
Para comprender su utilidad analicemos este caso: tenemos un registro de personas donde
almacenamos datos como: nombre, puesto, salario base, dirección, teléfono, fecha de
nacimiento, gustos musicales, aficiones, nombre, fecha de nacimiento y ocupación del
conjugue, nombres y fechas de nacimiento de sus hijos, nombres de sus mascotas, autos
que posee (con todas las características), etc.
Frecuentemente sólo utilizaremos nombre, puesto y salario base para generar una nómina,
esto implica que en cada vez que recuperamos información visualizamos datos que no
necesitamos, con la de que tenemos que traer registros inmensos para utilizar sólo cuatro
campos. El problema no es el almacenaje en disco, sino el tiempo desperdiciado en
recuperar registros de tal magnitud. Para solucionar esta dificultad se construye una
consulta que sólo muestra los datos necesarios.
Otro ejemplo: en muchos casos nos interesa que ciertas gentes tengan acceso sólo a parte
de la información. Es de mal gusto que todos los empleados sepan cuál es el salario del
director.
• SQL (Structured Query Language): el más conocido de los llamados “lenguajes de
consulta” que posibilitan la manipulación de la información. Entre sus ventajas
encontramos que es completo, simple, en seudo ingles, y está sostenido por una sólida
base matemática.
• identificadores: volviendo al ejemplo anterior del registro de personas donde coexisten
datos que usamos frecuentemente, con otros que se usan esporádicamente, un diseño un
poco más inteligente tendría dos tablas, una con los datos más frecuentemente
empleados de cada persona y la otra con el resto de la información que se emplea quizá
sólo para fines estadísticos o para enviar tarjetas de felicitación. Por supuesto, ambas
tablas estarían relacionadas mediante un identificador que sea inequívoco.
Se llama identificador a todo atributo o grupo de atributos cuyo valor identifica la entidad
bajo análisis. Si nos encontramos con una entidad que no tiene un atributo que lo
identifique inequívocamente, podemos “inventar” un atributo que sirva como identificador.
Si la entidad es Si la entidad es
“Personas”, su “Aulas”, se crea el
DNI suele atributo Código de
usarse como Aula.
identificador
Si son “Autos”, Si un botánico

su patente. quiere tener
identificada cada
planta, se crea un
identificador.
• Usuarios de una base de datos: una base de datos típica conlleva la existencia de tres
tipos de usuario con relación a su diseño, desarrollo y uso:
El administrador de bases de datos, que diseña y mantiene la Base.
El desarrollador de aplicaciones que implementa las transacciones e interfaces.
Los usuarios finales que consultan y editan los datos de la Base mediante un lenguaje de
consulta de alto nivel.
12
4.3.3. Postulados
En el modelo relacional se establece los siguientes postulados:
• Una base de datos relacional siempre está compuesta de tablas que se conectan
(relacionan) entre sí para compartir información.
Una tabla es un conjunto de datos

sobre una entidad específica: por
ejemplo en si un colegio guarda
información sobre los profesores, los
alumnos, las aulas, por cada una de
estos elementos se crea una tabla.
Las tablas organizan la información

en columnas llamadas campos y
filas llamadas registros.
Cada registro debe contener

información de una sola unidad de
análisis: por ejemplo en una tabla
“Alumnos”, una fila por cada alumno
y tantas filas como alumnos.
• Los campos (columnas) guardan los atributos del registro.

• Los campos pueden ser de distintos tipos: numéricos (Nº de legajo, cantidad de hijos),
alfanuméricos (Nombre, Dirección), de fechas (fecha de nacimiento, fecha de ingreso a la
compañía), verdadero / falso (Posee auto propio, cumplió el servicio militar), etc.
• Todos los datos registrados en una columna deben ser del mismo tipo.
13
El nombre del campo debe ser

único e inequívoco.
En otras palabras, no puede haber

dos campos llamados nombre. Si
tuviéramos esa necesidad se
debería crear el campo nombre1,
nombre2, nombre3, etc.
Tomemos el ejemplo de una escuela, donde se llena una ficha para cada alumno,
especificando los datos personales del mismo. Esto se guarda en la tabla “Alumnos”, que
tendrá tantos registros (filas) como estudiantes distintos tenga el establecimiento educativo.
Cada registro se compondrá de un cierto número de campos (columnas), como ser Nº de
Documento del alumno, Nombre, Apellido, Edad, Dirección, Teléfono.
TABLA ALUMNOS
Nº de Nombre Apellido Edad Dirección Teléfono
Documento
10.552.356 Juana Martínez 8 Av. Cabildo 2424 4321-1234
22.658.569 Adrián González 5 Chorroarín 125 4444-1111
32.568.857 Héctor Gómez 6 Padilla 627 9999-2222
• Así como cuando organizamos una biblioteca se crea un índice que permite hacer una
referencia a un libro fichado, en las bases de datos es necesario la creación de un campo
denominado identificador que permita localizar la unidad de análisis.
En este caso Nº de Documento de Alumno es el atributo identificador que permite
reconocer al escolar en forma inequívoca.
• En ningún momento dos filas de la misma tabla pueden tener el mismo valor de
identificador.
• Los identificadores pueden estar formados por una sola columna. Pero a veces no
alcanza con un solo o atributo para identificar un elemento de una base de datos: en esos
casos se utiliza un conjunto de atributos. Tomemos el ejemplo el identificador de una tabla
“Venta”. Normalmente una venta se identifica mediante el número de factura que se emitió,
pero si la empresa tiene distintos talonarios de facturas (Responsable Inscripto – A – o
Consumidor Final – B –), deben usarse conjuntamente los atributos Tipo de Factura +
Número de factura ya que el número sólo no alcanza para identificar una venta.
14
En el ejemplo de alumno, con el

número de documento tampoco
alcanza: solamente la
combinación de número de
documento y tipo de documento,
crea un identificador único.
CONVENCIÓN UTILIZADA PARA REFERIRSE A UNA TABLA

A partir de este momento, utilizaremos como notación la siguiente convención para
referirnos a una tabla.
• Nombre de la tabla: en
mayúsculas y negrita
• Campos: dentro de paréntesis,
en minúscula.
• Identificador: subrayado
Ejemplo: ALUMNO (Nº de Alumno, Nombre, Apellido, Edad, Dirección, Teléfono)
• Este modelo introduce el concepto de valor nulo, para hacer alusión a valores que no son
todavía conocidos. Por ejemplo, en la tabla alumnos, la columna estatura puede estar
vacía para determinado registro, no indicando esto que no tenga altura sino que no se
conoce la misma. En este ejemplo se ve claramente la diferencia entre “cero” y “nulo”.
¿Por qué es el concepto de valor nulo tan
importante? Porque los registros con valor
nulo se excluyen de las estadísticas.
Promedio de estatura sin noción de valor

nulo: 1.16
Promedio considerando valores nulos: 1.74
• El orden de las columnas y las filas no tiene importancia: Se podrá recuperar la

información en el orden que se desee, sin importar el orden en que fue ingresada.
• Las entradas de información deben ser atómicas. En otras palabras, debe ser información
que no pueda ser divisible. Por ejemplo, en una ficha papel es admisible registrar dos
idiomas (ingles, francés) en un mismo casillero, pero en el modelo relacional esto es
inadmisible.
Una posible solución, aunque altamente desaconsejable, seria la creación de diferentes
columnas: idioma 1, idioma 2, etc.
¿Por qué es desaconsejable? Porque si alguna persona no habla dos idiomas, estaremos
desperdiciando espacio (creamos una columna que no tendrá datos). Y si habla más de
dos... ¿dónde lo escribimos? Este problema se denomina de atributos repetidos o de
grupos repetitivos Volveremos a este tema y daremos una solución más adelante en esta
misma clase.
15
4.3.4. Relaciones entre tablas
Si ahora agregáramos en la tabla “Alumnos” al maestro a cargo del grado, con sus datos
personales, surgiría una enorme cantidad de problemas. Además de tener que ingresar todos
los datos del maestro por cada alumno (redundancia), si algún educador cambia de teléfono
deberíamos actualizar la información en muchos registros, tantos como alumnos tenga el
grado, lo que se presta a generar inconsistencias (que en un registro figure el teléfono viejo y
en otro el nuevo). También se agrandaría el tamaño de la base, lo que haría más costoso el
medio de almacenamiento (discos rígidos) y más largas las búsquedas (porque tiene que pasar
por más registros).
Todos estos problemas se solucionan si se crea

una tabla de “Maestros” donde cada registro
corresponda a un educador.
Por supuesto, cada registro debe tener un

identificador único (podría ser el legajo interno
del colegio).
Por otra parte, se deberían relacionar esta nueva

tabla con la tabla alumnos
Nueva tabla Maestro
Para relacionar esta tabla con la base alumnos, en la tabla alumnos creamos un campo
donde se ubica el identificador del maestro que nos remite a los datos personales del mismo.
16
Resumiendo, en general en una base de datos hay más de una tabla, que generalmente están
relacionadas entre ellas. Las tablas se conectan a través de un campo común que ambas
poseen: específicamente el identificador de una tabla puede ser el atributo de otra con la
finalidad de proveer un vínculo entre ambas.
Ese fue el caso de los Alumnos y los Maestros.
El identificador primario de “Alumnos” era DNI, el identificador primario de “Maestros” era el

Legajo Maestro.
Y se relacionaban mediante el campo Legajo Maestro.
El campo que relaciona las tablas es el identificador primario de la tabla maestros y el

identificador secundario de la tabla alumnos.
DEFINICIÓN
Identificador primario (o clave primaria):
El campo que identifica inequívocamente a
una entidad.
Identificador secundario (o clave foránea):

El campo de una tabla que está vinculado con
el identificador primario de otra tabla,
creando así una relación.
4.3.5. Tipo de relaciones
Son varios los tipos de relaciones que pueden entablar entre dos tablas:
TIPOS DE RELACIONES
17
Uno a uno:
• Si cada unidad de la entidad A

está relacionada con una
sola unidad de la entidad B,
y viceversa, entonces la
relación es uno a uno.
• En este ejemplo, cada capitán
comanda sólo un barco y cada
barco es comandado por sólo
un capitán (la relación –rombo-
se denominaría “comanda” y
es del tipo uno a uno)
• En estos casos los
identificadores primarios de
ambas tablas permiten cruzar
información entre tablas
• Este tipo de relación se utiliza frecuentemente para guardar información diferenciando

entre datos frecuentes de ocasionales, como por ejemplo la necesaria para
almacenamos datos en un registro de personas.
• Con tal motivo se crean dos tablas: una tabla donde se archivan los datos usados
frecuentemente, como: nombre, puesto, salario base, dirección, teléfono, fecha de
nacimiento y otra tabla donde se almacena aquellos datos usados en forma excepcional
como gustos musicales, aficiones, nombre, fecha de nacimiento y ocupación del cónyuge,
nombres y fechas de nacimiento de sus hijos, nombres de sus mascotas, autos que
posee (con todas las características).
• En este caso los identificadores primarios coincidentes permiten cruzar información
entre tablas.
18
Uno a Muchos:
• Si una unidad cualquiera de A

está relacionada con varias
de B, pero cada unidad de B
está en relación con sólo
una unidad de A se dice que
la relación es uno a muchos.
• En este ejemplo, cada barco
tiene varios tripulantes pero
cada tripulante puede estar
asignado a un sólo un barco
(la relación se llamaría
“emplea”).
• En este caso las tablas se conectan a través de un campo común que ambas poseen:
específicamente el identificador de una tabla puede ser el atributo de otra con la
finalidad de proveer un vínculo entre ambas.
• El campo que relaciona las tablas es el identificador secundario de la tabla tripulantes
y el identificador primario de la tabla maestros.
Muchos a Muchos:
• En este caso cada unidad de A

puede estar en relación con
varias unidades B y
viceversa.
• En este ejemplo, varios barcos
pueden patrullar una región y
cada región puede estar
patrullada por varios barcos (la
relación se llama “patrulla”).
• Por ejemplo el barco Libertad
patrulla la Región 1 y 2,
mientras que el barco
Argentina patrulla solo la 3, y
el barco Santa Ana patrulla la
2 y la 3
• En el modelo relacional este tipo de relación no esta permitida y el modelo ofrece
soluciones para estos casos. Volveremos sobre este tema mas adelante
19
4.3.6. Integridad relacional
Ahora que ya conocemos el funcionamiento de las claves primarias y las claves ajenas
estamos en posición de estudiar las reglas de integridad. Con este nombre se designa
aquellas reglas que han de ser aplicadas a una base de datos para asegurar que los datos
introducidos sean consistentes con la realidad que se pretenden modelar. Existen dos
reglas generales que aporta el modelo relacional. Estas dos reglas son muy simples:
• Regla de integridad de las entidades: ningún componente de la clave primaria de una

relación base puede aceptar valores nulos.
• Regla de integridad referencial: la base de datos no debe contener valores de clave
ajena o secundaria sin concordancia con una clave principal.
La primera de estas reglas impide la existencia de un registro sin identificador único. La

segunda impide que, por ejemplo, en nuestra base de datos académica, exista un profesor
adscrito a un departamento inexistente, o un alumno sin profesor, o un curso impartido por un
profesor inexistente.
Además, muchos RDBMSs añaden un buen número de características que ayudan a mantener
más fácilmente la integridad de los datos. Mediante estos mecanismos es posible añadir reglas
específicas para cada base de datos; éstas son las denominadas restricciones de integridad
definidas por el usuario. Por ejemplo, podríamos determinar que un profesor no pueda ser
menor de x años o que un curso sólo pueda pertenecer a los niveles 1, 2 ó 3. El resultado sería
que al intentar introducir un valor fuera de este rango, el DBMS rechazaría la información
introducida mostrando un mensaje de error.
20
La naturaleza de la información no espacial Arq. M. Frassia
4.3.7. Vistas y Tablas
En el modelo relacional se puede distinguir distintos perfiles de usuarios (operador,

administrador, Gerente) y asignándole a cada uno de ellos distintos tipos de permisos (sólo
lectura, lectura y escritura pero sólo de ciertas tablas, etc).
Con este objetivo, las tablas pueden ser de dos tipos: tablas y vistas.
• Las tablas son reales en el sentido que contienen información y una estructura física
determinada.
• Las vistas son tablas virtuales, siendo una combinación de filas y columnas de una o
más tablas. El objetivo de las mismas es presentarse a un particular usuario en la forma
que es útil para su propósito. Una vista puede ocultar los datos que el usuario no necesita o
no debe ver.
Supongamos que en un banco, hay una Base de Datos con las siguientes tablas:
CLIENTE (Nº de Cliente, Nombre, Apellido, Nº de Préstamo, etc.)

PRÉSTAMO (Nº de Préstamo, Nº de Sucursal, Monto, Cantidad Cuotas, etc.)
Un empleado a nivel gerencial necesita saber los nombres de todos los clientes que tiene cada
sucursal que tiene préstamos otorgados. Sin embargo, el empleado no está autorizado a ver la
información concerniente a los préstamos concretos que pueda tener cada cliente (monto,
cuotas, etc). Por lo tanto, se le debe negar el acceso a la información de la tabla Préstamo.
Pero se puede crear una Vista que cuando sea llamada, muestre solamente los campos
Nombre y Apellido (de Cliente) y Nº de Sucursal (de Sucursales).
4.3.8. SQL - STRUCTURED QUERY LANGUAGE
El lenguaje de consulta de bases de datos relacionales por antonomasia, es, como ya

anticipábamos, el llamado SQL (Structured Query Language).
Las ventajas de este lenguaje son:
• Es ampliamente usado y en general todos los software comerciales lo reconocen.

• Es un idioma completo que implementa todas las operaciones del modelo relacional.
• Es un idioma sencillo con menos de 30 comandos.
• El usuario no necesita ser programador para poder usarlo.
• Adicionalmente a estas ventajas, es el lenguaje utilizado cuando se quiere pasar
información de un software a otro en bases de datos ubicadas en un sistema de red.
Claro ejemplo de esta habilidad es Microsoft ODBC (OPEN DATABASE CONNECTIVITY).
Las bases de datos relacionales para las cuales hay ODBC drivers pueden intercambiar
información en este formato.
• Esta implementado en ingles y puede ser pensado como una frase estructurada en este
idioma. Las sentencias comienzan siempre con un verbo (SELECT, INSERT, UPDATE o
DELETE) que le dice al software la acción a realizar. Hay siempre un objeto, usualmente
una tabla, que es sujeto de la acción. Termina no en un punto, sino en punto y coma.
21
• La curva de aprendizaje de SQL es realmente rápida.
La historia de SQL (que se pronuncia deletreando en inglés las letras que lo componen, es
decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en 1974 con la definición, por
parte de Donald Chamberlin y de otras personas que trabajaban en los laboratorios de
investigación de IBM, de un lenguaje para la especificación de las características de las bases
de datos que adoptaban el modelo relacional.
Este lenguaje se llamaba SEQUEL (Structured English Query Language) y se implementó en

un prototipo llamado SEQUEL-XRM entre 1974 y 1975. Las experimentaciones con ese
prototipo condujeron, entre 1976 y 1977, a una revisión del lenguaje (SEQUEL/2), que a partir
de ese momento cambió de nombre por motivos legales, convirtiéndose en SQL.
El prototipo (System R), basado en este lenguaje, se adoptó y utilizó internamente en IBM y lo
adoptaron algunos de sus clientes elegidos. Gracias al éxito de este sistema, que no estaba
todavía comercializado, también otras compañías empezaron a desarrollar sus productos
relacionales basados en SQL. A partir de 1981, IBM comenzó a entregar sus productos
relacionales y en 1983 empezó a vender DB2.
En el curso de los años ochenta, numerosas compañías (por ejemplo Oracle y Sybase, sólo
por citar algunos) comercializaron productos basados en SQL, que se convierte en el
estándar industrial de hecho por lo que respecta a las bases de datos relacionales.
En 1986, el ANSI adoptó SQL (sustancialmente adoptó el dialecto SQL de IBM) como
estándar para los lenguajes relacionales y en 1987 se transformó en estándar ISO. Esta
versión del estándar va con el nombre de SQL/86. En los años siguientes, éste ha sufrido
diversas revisiones que han conducido primero a la versión SQL/89 y posteriormente, a la
actual SQL/92.
El hecho de tener un estándar definido por un lenguaje para bases de datos relacionales abre
potencialmente el camino a la intercomunicabilidad entre todos los productos que se
basan en él.
Desde el punto de vista práctico, por desgracia las cosas fueron de otro modo. Efectivamente,
en general cada productor adopta e implementa en la propia base de datos sólo el
corazón del lenguaje SQL.
Actualmente, está en marcha un proceso de revisión del lenguaje por parte de los comités
ANSI e ISO, que debería terminar en la definición de lo que en este momento se conoce como
SQL3. Las características principales de esta nueva encarnación de SQL deberían ser su
transformación en un lenguaje stand-alone (mientras ahora se usa como lenguaje
hospedado en otros lenguajes) y la introducción de nuevos tipos de datos más complejos
que permitan, por ejemplo, el tratamiento de datos multimediales.
22
5. MODELO EAR (ENTIDAD-ATRIBUTO-RELACIÓN)
Este modelo fue creado en 1976 por Peter Chen del “Massachusetts Institute of Tecnology” y
es ampliamente usado como un medio de modelado de bases de datos.
En el modelo Entidad/Relación, la realidad se representa mediante un número muy reducido de

conceptos semánticos básicos:
• El mundo está compuesto de entidades; una entidad es cualquier objeto distinguible

relevante en el mundo en cuestión (los profesores y cursos en el mundo académico de
nuestro ejemplo anterior).
• Estas entidades poseen un número indeterminado de propiedades, que son "trozos" de
información que describen a las entidades de uno u otro modo.
• Cada una de las entidades tiene una identidad, en otras palabras, son identificables de
forma única.
• Grupos de entidades relacionadas mantienen relaciones con otros grupos de
entidades.
Se supone que mediante estos simples componentes se puede modelar cualquier "sección de
realidad".
El modelo EAR aporta una herramienta de modelado para representar las entidades,
propiedades y relaciones: los diagramas Entidad/Relación.
Mediante éstos, el esquema conceptual abstracto puede ser mostrado gráficamente y

mantener una independencia conceptual con respecto a la implementación propiamente dicha.
En realidad, podemos hacer que los diagramas sean un reflejo fiel de las relaciones,
interrelaciones y atributos del modelo relacional de datos.
• Las entidades se dibujan como rectángulos
• Sus atributos como elipses atadas a los

rectángulos por líneas
• Las relaciones como rombos
• El tipo de relación entre dos entidades se

representa mediante las siguientes convenciones
(Uno a Muchos en este ejemplo)
23
• Una propiedad cuyo nombre está subrayado

señala que ésa es la propiedad que identifica de
forma única a la entidad, y que se corresponderá
con la clave primaria de una relación en la
implementación relacional.
• Finalmente, un rectángulo doble, significa que esa
entidad es dependiente o débil, es decir, su
existencia depende de la existencia de otra entidad.
Por ejemplo podremos establecer la restricción de
que un capitán no puede existir sin estar adscrito a
ningún barco.
Incluye varios pasos, los cuales ejemplificaremos con un modelo de datos simplificado para la
Prefectura Naval:
1ER PASO: Se deben identificar las entidades
Las entidades son objetos o cosas que pueden identificarse y tener una existencia
independiente y sobre que la organización necesita información.
Son en general sustantivos. En nuestro ejemplo, luego de un primer tanteo en la Prefectura,

encontramos que había BARCOS, que cada uno era comandado por un CAPITÁN; que los
barcos tenían TRIPULACIÓN y que patrullaban una o varias REGIONES.
• Cada una de las entidades es

representada como un rectángulo que
contienen el nombre de entidad en
singular.
• En este ejemplo hay 4 entidades: BARCO, CAPITÁN, TRIPULACIÓN y
REGIÓN
2DO PASO: Se debe identificar las relaciones entre tablas especificando

tipo de relación
Una relación es una asociación entre dos objetos. Las relaciones son representadas por un
rombo entre los rectángulos (a veces se coloca el nombre de la relación dentro del rombo).
Es importante en este momento reconocer el tipo de relaciones:
• Uno-a-uno
• Uno-a-muchos
• Muchos-a-muchos
24
Afortunadamente, las reglas para transformar las relaciones del diagrama en relaciones del
modelo relacional son bastante directas.
Uno a uno:
• Si la relación es Uno-a-Uno es aceptable unir estas entidades en una sola tabla,
considerando al Capitán como un atributo de la tabla Barco.
• Alternativamente, puede ser más conveniente guardar las dos entidades separadas
en dos tablas, usando el identificador común para cruzar información entre tablas. En
este ejemplo ambas tablas podrían estar unidas por el identificador “Barco” (en la tabla
Barco será clave primaria y en la tabla capitán clave secundaria).
Uno a Muchos:
• Si la relación es Uno-a-Muchos se resuelve agregando la llave primaria de la tabla de
uno (Barco) a la tabla de muchos (Tripulante), que automáticamente se convierte en
llave secundaria.
• En este ejemplo la llave o identificador principal de la tabla Barco pasa a ser un atributo
de la tabla Tripulante.
Muchos a Muchos:
• Las relaciones muchos a muchos no son aceptadas por el sistema.
• Por ejemplo, varios barcos pueden patrullar una región y cada región puede estar
patrullada por varios barcos (el barco Libertad patrulla la Region 1 y 2, mientras que el
barco Argentina patrulla solo la 3, y el barco Santa Ana patrulla la 2 y la 3)
• En este caso se debe pasar al 4TO PASO: se deben derivar nuevas tablas
3ER PASO: Se debe identificar los atributos de las entidades
En este paso se asignan atributos a las entidades. Son en general adjetivos, características de
las entidades que queremos registrar. En el diagrama se muestran como elipses atadas a los
rectángulos por líneas.
25
El sentido común nos dice que los atributos elegidos dependerán del uso que se deba dar a la
base de datos. De una misma persona puede interesarnos grupo y factor sanguíneo si estamos
diseñando el modelo de datos de un Hospital, o la carrera y promedio de notas si el diseño es
para una Universidad.
En este momento es fundamental, prestar especial atención a los identificadores. En este

Donde no exista identificador, se debe crear uno artificial, que en la mayoría de los casos no
será nada más que un numero único (Número de... o Código de... son lo más común).
4TO PASO: Se deben derivar nuevas tablas
El proceso esencial para organizar datos en tablas relacionales es el de normalización.

Consiste en convertir relaciones complejas en otras más simples que cumplan las condiciones
del modelo relacional. Sin embargo, al descomponer la información en tablas normalizadas,
reduce la velocidad de las búsquedas, por lo que ha de asumirse un compromiso entre rigor
organizativo y rapidez en la gestión.
26
Muchos a Muchos:
• Si la relación es Muchos-a-Muchos, el modelo propone la descomposición de esta
relación en dos relaciones Uno-a-Muchos usando las llaves primarias de las tablas como
atributo en la tabla de conexión (o “asociativa”) creada.
• En este ejemplo se crea una tabla de conexión con una llave primaria compuesta por
las dos llaves primarias de las respectivas tablas, la de la Región y la de Barco.
• La combinación de ambas llaves constituye la llave principal de la tabla de conexión, que
llamaremos Patrulla.
• Esta tabla de conexión intermedia posibilita convertir una relación Muchos a Muchos
en relaciones Uno a muchos y Muchos a Uno
27
• El problema denominado de atributos repetidos o de grupos repetitivos se soluciona en

forma similar
• ¿Recuerda la tabla ALUMNOS y el campo idiomas? Se crea una tabla que se relaciona
con la existente donde la clave principal de la segunda tabla es la combinación del
campo DNI e Idiomas.
• Las tablas se relacionan a través del identificador DNI. Y mediante la consulta al DNI
puedo recuperar la información de los idiomas que habla cada alumno.
Tabla N° 1: ALUMNO (DNI, Apellido, Nombre, Cargo, Edad)

Tabla N° 2: IDIOMAS (DNI, Idiomas)
28
SOLUCIÓN DEFINITIVA
Así queda el diagrama EAR una vez resuelto el ejercicio
• Este modelo especifica la existencia de cuatro entidades, BARCO, CAPITÁN,
TRIPULACIÓN y REGIÓN, que se corresponden con otras tantas relaciones.
• Un BARCO tiene muchos TRIPULANTES (Uno a Muchos) pero solo 1 CAPITÁN (Uno a
Uno).
• Como REGIÓN y BARCO mantenían relación Muchos a Muchos se descompuso esta
relación en dos relaciones Uno-a-Muchos usando las llaves primarias de las tablas como
atributo en la tabla de conexión (o “asociativa”) creada. El resultado fue la tabla
PATRULLA
• Para cada una de las entidades existe un campo que las identifica únicamente y al cual se
denomina clave primaria de cada una de las tablas.
• Las entidades tienen otras propiedades que las describen y que se corresponden con los
distintos campos de la tabla.
Así quedan las tablas una vez resuelto el ejercicio

• BARCO (Nº de Barco, Nombre, Eslora)
• CAPITÁN (Nº de Legajo Capitán; Nombre Capitán, Nacionalidad Capitán, Nº de Barco).
Se habría podido optar por considerar al Capitán como un atributo de la tabla Barco.
• TRIPULANTE (Nº de Tripulante, Nombre, Cargo, Edad, Nº de Barco)
• REGIÓN (Nº de Región, Nombre)
• PATRULLA (Nº de Barco, Nº de Región)
29
6. VENTAJAS Y DESVENTAJAS DEL MODELO
6.1 Ventajas
• El modelo relacional es eficiente en la organización y manejo de grandes colecciones

de datos
• Permite restricciones de seguridad, distinguiendo distintos perfiles de usuarios

(operador, administrador, Gerente) y asignándole a cada uno de ellos distintos tipos de
permisos (sólo lectura, lectura y escritura pero sólo de ciertas tablas, etc).
• Posibilitan múltiples vistas de una misma base según los requerimientos de información
del sistema (¿Recuerda el modelo bancario?).
• Posibilitan bases de datos distribuidas, como bases divididas en partes que residen en
lugares geográficamente distantes, pero que están fuertemente vinculadas funcionando
como una base de datos (sino, no sería una bases de datos sino muchas separadas).
• Reducen los datos duplicados y redundantes evitando inconsistencias.
• Mantienen la integridad y calidad del sistema ya que los datos están separados de
las aplicaciones (toda lectura o escritura de información debe pasar por el DBMS).
• Permiten el acceso de varios usuarios en el mismo momento.
• No requieren conocimientos de programación para acceder a los datos.
6.2 Desventajas
• No soportan las relaciones complejas que existen en el mundo real. Por ejemplo,
objetos conformados de otros objetos (ejemplo: objeto propiedad compuesto de objetos
edificio, terreno y cerca).
• No tienen conocimiento semántico, es decir, no entienden qué significan los datos que
guardan. Por ejemplo, las bases de datos con información hidrológica no “saben” que el
agua fluye en declive. El conocimiento semántico es tan básico que debe ser compensado
por los programadores, creando aplicaciones a medida del usuario que hagan amigable al
sistema.
• Los tipos de datos son limitados (numéricos, alfanuméricos, etc.) y no reconoce tipos de
datos más complejos. Para dar ejemplos triviales, sería bueno que fueran capaces de
reconocer un dato de tipo Votante que seleccionara de una base de personas a los
30
individuos mayores de 18 años de edad, o un tipo de datos Día que sólo aceptara valores
de texto cuyos valores varíen entre domingo y lunes.
• Tienen dificultades con el tiempo considerado como una sucesión natural. Una
secuencia de hechos donde los eventos pasan antes o después de otros son muy difíciles
de modelar en una base de datos relacional.
Nota final
Es importante recalcar que mientras los modelos relacionales soportan relaciones uno a uno,
uno a muchos y muchos a uno, los GIS como Arcview 3.X sólo permiten relaciones uno a uno,
siendo está una de sus grandes debilidades. Imaginen la dificultad que significa para un
catastro no poder consultar las partidas de las múltiples unidades funcionales de un lote
Este problema esta resuelto en los GIS de última Generación, como el ArcView 8.1 que
reconoce relaciones 1 a 1 y las llama “Joints” y relaciones 1 a muchos a las cuales llama
“Relates”.
31
EVALUACIÓN
Actividad
A partir del problema planteado en el apartado 3 cree un diagrama Entidad-Atributo-Relación:
Si tiene alguna duda acerca de las ‘reglas de la organización’ que no haya sido aclarada, haga
una suposición y explicítela por escrito. Envíe este diagrama al tutor.
Si todavía está con ánimo, vuelva a su propio caso, tal como lo ha ido pensando a lo largo de
todas las clases. Elabore un diagrama para el mismo.
Una vez que haya concluido guarde la actividad en el mismo documento que uso para la
evacuación de la clase 1 y remita este documento al tutor para su corrección al finalizar el
curso.
Solicite la siguiente clase
32
GLOSARIO
Base de datos: Una base de datos es un conjunto de información relacionada con un asunto o
con una finalidad.
Datos: Los datos son hechos o cosas del mundo lo suficientemente importante como para ser
registrados. Son recopilados como hechos o evidencias. Adquieren significado a partir de su
procesamiento para convertirse en información. Al hablar de datos, hacemos referencia a un
concepto amplio que puede incluir texto, imágenes, sonido, reglas de decisión, etc.
Campos: se denomina así a las columnas de una tabla.
Entidades; una entidad es cualquier objeto distinguible relevante en el mundo en cuestión.
Identificador: Se llama identificador a todo atributo o grupo de atributos cuyo valor identifica
la entidad bajo análisis. Posibilita la unión entre los elementos espaciales y las tablas externas
que habitualmente tienen las organizaciones.
Identificador primario El campo que identifica inequívocamente a una entidad.
Identificador secundario El campo de una tabla que está vinculado con el identificador
primario de otra tabla, creando así una relación
Inconsistencia de datos: utilizaremos un ejemplo. Digamos que empleamos un archivo

secuencial para almacenar la información de clientes. Supongamos que tenemos varios
programas que utilizan esa información y que en un momento dado se pueden tener registros
duplicados con atributos diferentes. Por ejemplo, una persona cambia de dirección y al no tener
una estructura bien definida, no alteramos el registro, sino que lo damos de alta de nuevo con
la nueva dirección. De esta manera, tendremos a la misma persona con dos datos diferentes y
sin posibilidad de garantizar que todos los programas tendrán en cuenta que la dirección válida
es la del segundo registro que aparece.
Información: Es el resultado del análisis de los datos. Por ejemplo, un satélite colecciona
datos (valores numéricos) que una vez volcados en un mapa, son interpretados por una
persona que identifica los diferentes usos del suelo en determinada región.
Propiedades: que son "trozos" de información que describen a las entidades de uno u otro
modo.
Query o consulta: es una declaración o grupo de declaraciones en idioma formal que permite
comunicarse con el DBMS para recuperar la información almacenada.
Registros: se denomina con este nombre a las filas de una tabla
SQL (Structured Query Language): el más conocido de los llamados “lenguajes de consulta”
que posibilitan la manipulación de la información
Valor nulo: Es la ausencia de un valor. Si una columna particular de una fila es nula, quiere
decir que no se conocen los valores para esta información. Nulo no es lo mismo que cero. Este
concepto es importante en el momento de realizar estadísticas ya que los valores nulos no son
computados.
33

GIS Clase4

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

GIS Clase4

Cargado por

Copyright:

Formatos disponibles

La información no espacial Arq. M.

CLASE 4: LA NATURALEZA DE LA INFORMACIÓN NO

En esta clase encontrará respuesta a las siguientes preguntas:

Los Links recomendados para esta clase son:

2. INTRODUCCION A LOS CONCEPTOS PRINCIPALES

BASES DE DATOS RELACIONALES

4.1. LA INFORMACIÓN COMO RECURSO

Los datos son observaciones que realizamos en el mundo real.

• Son recopilados como hechos ó evidencias

DIFERENCIAS ENTRE DATOS E INFORMACION

Dato: 36 Como es simplemente un número no tiene en sí mismo ningún

Información: 36° Temperaturas máxima registradas en la ciudad de Buenos Aires, en

Desde el punto de vista tecnológico, la Integración de Aplicaciones, la reutilización y el fácil

En las últimas décadas se han realizado importantes avances en la formalización de los

Una base de datos es un conjunto de información relacionada que pertenece a una

4. 2 LAS BASES DE DATOS EN EL GIS

TABLA CON INFORMACIÓN

En principio, debe saber que:

4.3 EL MODELO RELACIONAL

4. 3.1. UN POCO DE HISTORIA

Como el objetivo era la resolución de problemas, se prestaba poca consideración al

Cuando la ciencia de la computación y la tecnología avanzaron, se volvió imperiosa la

El objetivo era la disminución de los graves problemas de inconsistencia y duplicidad de

Es así como nacen el Database Management System (DBMS) o Sistema de Gestión de

Aporta las siguientes ventajas

• Independencia lógica y física de los datos de las aplicaciones

4.3.2. TÉRMINOS TÉCNICOS

Los atributos de Los atributos de la

• Manejador de Bases de Datos (DBM por sus siglas en inglés)

Si son “Autos”, Si un botánico

En el modelo relacional se establece los siguientes postulados:

Una tabla es un conjunto de datos

Las tablas organizan la información

Cada registro debe contener

• Los campos (columnas) guardan los atributos del registro.

El nombre del campo debe ser

En otras palabras, no puede haber

En el ejemplo de alumno, con el

CONVENCIÓN UTILIZADA PARA REFERIRSE A UNA TABLA

Ejemplo: ALUMNO (Nº de Alumno, Nombre, Apellido, Edad, Dirección, Teléfono)

Promedio de estatura sin noción de valor

• El orden de las columnas y las filas no tiene importancia: Se podrá recuperar la

4.3.4. Relaciones entre tablas

Todos estos problemas se solucionan si se crea

Por supuesto, cada registro debe tener un

Por otra parte, se deberían relacionar esta nueva

Nueva tabla Maestro

Ese fue el caso de los Alumnos y los Maestros.

El identificador primario de “Alumnos” era DNI, el identificador primario de “Maestros” era el

Y se relacionaban mediante el campo Legajo Maestro.

El campo que relaciona las tablas es el identificador primario de la tabla maestros y el

Identificador secundario (o clave foránea):

4.3.5. Tipo de relaciones

• Si cada unidad de la entidad A

• Este tipo de relación se utiliza frecuentemente para guardar información diferenciando

• Si una unidad cualquiera de A

• En este caso cada unidad de A

4.3.6. Integridad relacional

• Regla de integridad de las entidades: ningún componente de la clave primaria de una

La primera de estas reglas impide la existencia de un registro sin identificador único. La

4.3.7. Vistas y Tablas

En el modelo relacional se puede distinguir distintos perfiles de usuarios (operador,

CLIENTE (Nº de Cliente, Nombre, Apellido, Nº de Préstamo, etc.)

4.3.8. SQL - STRUCTURED QUERY LANGUAGE