Bases de Datos y SQL Michael Gould

Índice n Introducción: Bases de datos n Modelo relacional n SQL –Repaso de comandos principales –Lenguaje de definición de datos (DDL) –Lenguaje de manipulación (DML) n Demostraciones n Extensiones de SQL para el mundo SIG n Problemas con el modelo relacional

¿Porque las bases de datos? n Parece obvio hoy en día n Tradicionalmente sistemas trabajaban a base de ficheros sueltos, y procedimientos sobre ellos –sistemas a medida de cada aplicación (pág. 2-9) n Bdatos: separación de datos e su implementación (hardware/software) –Independencia –Protección (permite sistema multiusuario) –Flexibilidad (conectar la bdatos a todo) –Eficiencia (minimiza duplicidad de datos) –Integridad (minimiza errores lógicos)

Papel de BBDD en los SIG n Típicamente mucha énfasis en cursos de SIG en la parte cartográfica –digitalización, depuración, conversión de mapas digitales... –enfoque geométrico –“ y se puede enlazar atributos a cada elemento geográfico...línea, polígono etc.” –típico ejemplo: segmento de calle (línea) con 6 atributos: longitud, anchura, 4 números de policía n La parte cartográfica es más visual, interesante (transparencias)

Papel de BBDD (2) n La creación de la base de datos SIG supone la recogida de datos carto(geo)gráficos y atributos n Ocupa gran parte del tiempo/presupuesto n Durante la explotación de un SIG, a largo plazo, la actualización cartográfica juega un papel trivial n Explotación del SIG sinónimo con consultar...a la base de datos (transparencias) –la geometría se mantiene relativamente fija, los atributos no –el SGBDR permite combinaciones de consultas casi sin limite –limitación: del diseño de la base de datos –esta en vuestros manos

Papel de BBDD (3) n Un experto en BBDD puede determinar el éxito de (o salvar) un proyecto SIG; un cartógrafo no n UNIGIS ofrece dos asignaturas (módulos) dedicadas a las BBDD n Aconsejables los dos módulos n Y si puede ser, un curso de Oracle después de Unigis n Si no puede ser, utilización de MS-Access (en adición a Quasar) para el primer módulo

Modelos de bases de datos n Modelo jerárquico –estructura de árbol: relaciones 1:muchos –requiere duplicación de datos n Modelo en red –permiten mejor relación entre los datos –todo conectado a todo –muy utilizado en aplicaciones COBOL (empresarial) n Dibujos en la página 2-30 n Modelo relacional –modelo dominante hoy en día

Modelo relacional n Dr Edgar (Ted) Codd, de la IBM n 1970 “A relational model of data for large shared data banks” Communications of the ACM 13(6). n Modelo muy simple, flexible hasta cierto punto n Todo en tablas, con columnas y filas n Operaciones para crear, borrar, modificar tablas n Otras operaciones (álgebra relacional) para manipular (consultar) estas tablas... n El modelo se caracteriza por tres elementos

Características del modelo n Elemento estructural: forma de guardar datos –todo en tablas, y nada más que tablas –sin duplicar registros (filas, tuplas) –campos (columnas) con nombres únicos –entradas en un campo de solo un tipo n numérico (entero, real..), texto, fecha, etc. –todas las entradas serán datos atómicos –orden de filas/columnas no importa –valores nulos soportados (<> 0) –claves para crear relaciones (solo una es clave primaria)

Características (2) n Elemento de manipulación: que se puede hacer –Entrada: una o mas tablas –Salida: una tabla nueva –Codd define álgebra y cálculo relacional (el usuario no los vea) –En la práctica, solo son 3 operadores fundamentales: n SELECT: especificar “criterios de búsqueda” y crear una nueva tabla con solo los datos que buscábamos n PROJECT: copia un subconjunto de campos a una tabla nueva n JOIN: “pega” dos tablas para crear una nueva –Select y Join: operaciones críticas en el SIG vectorial

Características (3) n Elemento de integridad: control lógico –Integridad de entidades n garantiza que los campos clave tengan datos (no nulos) y que si existe un registro se puede localizar –Integridad referencial n mantiene intactas relaciones (referencias) de clave a clave n no puedes borrar un registro al que depende otra tabla n los dos campos clave deben ser del mismo tipo

Grado = 5 Cardinalidad = 2155

¿Como manipular los datos/tablas? n Structured Query Language, SQL n Viene de Sequel (IBM, 1974), todavía se pronuncia “siquel”, aunque oficialmente es “S.Q.L.” n Un estándar ANSI, ISO pero... –Los fabricantes han creado sus propias versiones no exactamente estándares... –PL/SQL de Oracle <> SQL de MS Access (Jet) –Muchos SIG utilizan ficheros DBF o MDB, que los manipulan sin los gestores dBase o Access –Ningún fabricante soporta el 100% del estándar

SQL y el modelo relacional n SQL no forma parte del modelo relacional n Query-By-Example (QBE), otros lenguajes de consulta pueden aplicarse también al modelo n SQL ha sido aceptado como el lenguaje de facto n SQL aceptado por Codd, con matices n Sirve como lenguaje completo: de definición (DDL) y de manipulación (DML) de datos según el modelo relacional n Tiene una estructura “pseudo inglésa” n Se utiliza como lingua franca entre sistemas

Repaso de comandos SQL n DDL: –CREATE –CREATE –DROP –DROP n DML: –SELECT –SELECT –FROM –FROM –WHERE –WHERE

Ejemplos del sintaxis SQL create table zona ( IdZonasmallint not null unique, IdZonasmallint not null unique, NomZonachar(30) not null unique, NomZonachar(30) not null unique, Superfsmallint, Superfsmallint, IdOfCDsmallint not null IdOfCDsmallint not null); create table tipo ( IdTiposmallint not null unique, IdTiposmallint not null unique, DescTipochar(30) not null unique DescTipochar(30) not null unique);

Mas ejemplos... SELECT DISTINCT NomCons FROM ofarea,relacion,ofcd,zona,parcela,construc WHERE NomAr=’Central’ AND ofarea.IdAr=relacion.IdAr AND relacion.IdOfCD=zona.IdOfCD AND zona.IdZona=parcela.IdZona AND parcela.IdCons=construc.IdCons;

Mas ejemplos... SELECT NomAr,AVG(Superf),SUM(Superf) FROM ofarea,relacion,zona WHERE ofarea.IdAr=relacion.IdAr AND relacion.IdOfCD=zona.IdOfCD GROUP BY NomAr;

Relaciones n Son BBDD relacionales, ¿no? n Dividimos los datos entre varias tablas (específicas) para minimizar la duplicación de datos, y también las dependencias entre campos –proceso conocido como normalización (sección 4.1.3) n Hay relaciones de 3 tipos entre atributos –1:1, una persona tiene un DNI –1:M, una persona tiene muchos amigos –M:N, una tienda tiene muchos clientes, cada uno de los cuales es cliente de muchas tiendas

Relaciones (2) n El modelo relacional no permite relaciones M:N, por eso a veces hay que crear nuevas tablas (auxiliares) como “puentes” entre una tabla y otras n Ejemplo de la Videoteca: –tabla “clientes” (cada cliente es único) –tabla “películas” (cada película es única) –Problema: ¿Como modelar el caso en que una película esta en manos de muchos clientes, y que cada cliente puede haber alquilado muchas películas? n Solución: nueva tabla “movimientos”, con campos en común con “clientes” y “películas”

Claves n Para enlazar tablas mediante un campo en común n Claves primarias (campo único), como DNI en la tabla “clientes” n Claves externas (foráneas), como DNI en la tabla “movimientos” n Ejemplo de Neptuno en Access

Diseño de la Base de Datos n Cuales son las entidades (y sus atributos) de importancia n Cuales son las relaciones entre ellas n Creación de modelos E-A-R tratada en detalle en la sección 4 del libro Unigis n Luego diseñar una bdatos física de acuerdo con el modelo n Este diseño no es una tarea trivial n La explotación del SIG (consultas posibles) se basa en este diseño !! n Rediseñar una base de datos a posteriori MUY caro !!

SQL en el ámbito SIG n Se utiliza (SQL es un estándar de facto) –Cuando sabes SQL, sabes el 30% de cualquier SIG vectorial n Pero no es lenguaje óptimo para representar las relaciones espaciales (basadas en la geometría) –cerca de, pasando por, intersección con, dentro de n Y no permite interacción multimodal –¿Cuáles son las carreteras que pasan por este barrio? n En general: SQL es para tablas de texto n “SQL sirve para modelar como la gente utiliza tablas”

Problemas con SQL n Normalmente el SIG maneja datos alfanuméricos (en tablas relacionales) y gráficos (en ficheros propietarios)... n Ejemplos de Arc/INFO, MapInfo n SQL no ofrece herramientas para la parte gráfica –No es eficiente guardar miles (millones) de coords x,y,z en columnas largas –Para representar un polígono hace falta crear por lo menos 5 tablas y sus relaciones correspondientes –Demasiado complicado y lento

Problemas con SQL (2) n ¿Como optimizar almacenamiento de datos espaciales? –Puedes ordenar un campo y definir un índice (que siempre es unidimensional) sobre este campo –Contra la norma de Codd, que el orden no importa –Y ¿qué campo vas a elegir? Sólo coord-x, sólo coord-y... –En general, lectura de tablas relacionales es muy lenta (olvídalo para dibujar elementos geográficos) n Indices bidimensionales –Quadtree, KDB-tree (van Oosterom) –Decomposición/indexación regular en 2-D del espacio

Problemas con SQL (3) n No se puede definir “tipos de datos abstractos” n Modelo relacional define CHAR, ENTERO, REAL, FECHA, etc. n Sería útil poder definir tipos geométricos por ejemplo: –línea, nodo, rectángulo... n Reconocida hace 20 años la necesidad de extensiones especiales al SQL para servir los campos SIG, CAD, diseño...

Solución 1: Pseudo-SQL n Ejemplo de MapInfo –Han definido extensiones para “objetos geográficos” n aquí objeto = entidad (no es OO) n obj contiene otro obj, tiene intersección con, esta completamente dentro... –Gestor de base de datos hecho por MapInfo, que entiende estas extensiones, y que trabaja con ficheros DBF –No cumple con muchas normas del ANSI SQL –Pero funciona...

Solución 2: “SQL espacial” n Bundock y otros (Smallworld) n Herring y otros (Intergraph>>Oracle) n van Oosterom (en libro anexo Unigis) n SQL-3 algo más flexible, permite algo de OO n SQL-MM (multimedia) n Oracle Spatial (todos los datos en tablas relacionales) n Basado en un nuevo modelo objeto-relacional n Soporta algo de SQL, algo de conceptos OO, programación desde Java, C++, etc.

Ejemplos, Oracle Spatial ¿Cuales son los parques con ríos? SELECT parks.name FROM parks, rivers WHERE sdo_geom.relate(parks.geometry, rivers.geometry, ’OVERLAPBDYINTERSECT’) = ’OVERLAPBDYINTERSECT’;

Otro de Oracle Spatial Parques por donde pasa la carretera I-93 SELECT Parks.Name FROM Parks, Roads WHERE MDSYS.SDO_RELATE(Parks.Geometry, Roads.Geometry, ’MASK=ANYINTERACT’) = ’TRUE’ AND Roads.Name = ’I-93’;

BBDD objeto-relacional n En su infancia n Oracle liderando el campo, empujando fuerte –tiene grupo de 200 trabajando en temas especiales n BD relacionales poseen una masa crítica sustancial n Todos los sistemas utilizan indexación 2-D (o n-D) para mejorar rendimiento –tema tratado en otro modulo de Unigis

El futuro de las BBDD n Ya que vivimos en tiempo de Internet, nadie sabe n ¿Será la propia Internet (web) nuestra base de datos? –Todo distribuido –Todo conectado n Faltan nuevos índices, buscadores n Es una base de datos con dominio abierto –crece al ritmo de páginas (recursos) al día –no es posible la consulta “Dame un listado de todos los recursos sobre tal tema” n Otros tiempos, otros SIGs

Gracias por vuestra atención. Seminario Unigis 21 de Enero 2000