D:\Introduccion A Sql 2000 Server

953 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
953
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

D:\Introduccion A Sql 2000 Server

  1. 1. Bases de Datos y SQL
  2. 2. Índice <ul><li>Introducción: Bases de datos </li></ul><ul><li>Modelo relacional </li></ul><ul><li>SQL </li></ul><ul><ul><li>Repaso de comandos principales </li></ul></ul><ul><ul><li>Lenguaje de definición de datos (DDL) </li></ul></ul><ul><ul><li>Lenguaje de manipulación (DML) </li></ul></ul><ul><li>Demostraciones </li></ul><ul><li>Extensiones de SQL para el mundo SIG </li></ul><ul><li>Problemas con el modelo relacional </li></ul>
  3. 3. ¿Porque las bases de datos? <ul><li>Parece obvio hoy en día </li></ul><ul><li>Tradicionalmente sistemas trabajaban a base de ficheros sueltos, y procedimientos sobre ellos </li></ul><ul><ul><li>sistemas a medida de cada aplicación (pág. 2-9) </li></ul></ul><ul><li>Bdatos: separación de datos e su implementación (hardware/software) </li></ul><ul><ul><li>Independencia </li></ul></ul><ul><ul><li>Protección (permite sistema multiusuario) </li></ul></ul><ul><ul><li>Flexibilidad (conectar la bdatos a todo) </li></ul></ul><ul><ul><li>Eficiencia (minimiza duplicidad de datos) </li></ul></ul><ul><ul><li>Integridad (minimiza errores lógicos) </li></ul></ul>
  4. 4. Papel de BBDD en los SIG <ul><li>Típicamente mucha énfasis en cursos de SIG en la parte cartográfica </li></ul><ul><ul><li>digitalización, depuración, conversión de mapas digitales... </li></ul></ul><ul><ul><li>enfoque geométrico </li></ul></ul><ul><ul><li>“ y se puede enlazar atributos a cada elemento geográfico...línea, polígono etc.” </li></ul></ul><ul><ul><li>típico ejemplo: segmento de calle (línea) con 6 atributos: longitud, anchura, 4 números de policía </li></ul></ul><ul><li>La parte cartográfica es más visual, interesante </li></ul><ul><li>(transparencias) </li></ul>
  5. 5. Papel de BBDD (2) <ul><li>La creación de la base de datos SIG supone la recogida de datos carto(geo)gráficos y atributos </li></ul><ul><li>Ocupa gran parte del tiempo/presupuesto </li></ul><ul><li>Durante la explotación de un SIG, a largo plazo, la actualización cartográfica juega un papel trivial </li></ul><ul><li>Explotación del SIG sinónimo con consultar ...a la base de datos (transparencias) </li></ul><ul><ul><li>la geometría se mantiene relativamente fija, los atributos no </li></ul></ul><ul><ul><li>el SGBDR permite combinaciones de consultas casi sin limite </li></ul></ul><ul><ul><li>limitación: del diseño de la base de datos </li></ul></ul><ul><ul><li>esta en vuestros manos </li></ul></ul>
  6. 6. Papel de BBDD (3) <ul><li>Un experto en BBDD puede determinar el éxito de (o salvar) un proyecto SIG; un cartógrafo no </li></ul><ul><li>UNIGIS ofrece dos asignaturas (módulos) dedicadas a las BBDD </li></ul><ul><li>Aconsejables los dos módulos </li></ul><ul><li>Y si puede ser, un curso de Oracle después de Unigis </li></ul><ul><li>Si no puede ser, utilización de MS-Access (en adición a Quasar) para el primer módulo </li></ul>
  7. 7. Modelos de bases de datos <ul><li>Modelo jerárquico </li></ul><ul><ul><li>estructura de árbol: relaciones 1:muchos </li></ul></ul><ul><ul><li>requiere duplicación de datos </li></ul></ul><ul><li>Modelo en red </li></ul><ul><ul><li>permiten mejor relación entre los datos </li></ul></ul><ul><ul><li>todo conectado a todo </li></ul></ul><ul><ul><li>muy utilizado en aplicaciones COBOL (empresarial) </li></ul></ul><ul><li>Dibujos en la página 2-30 </li></ul><ul><li>Modelo relacional </li></ul><ul><ul><li>modelo dominante hoy en día </li></ul></ul>
  8. 8. Modelo relacional <ul><li>Dr Edgar (Ted) Codd, de la IBM </li></ul><ul><li>1970 “A relational model of data for large shared data banks” Communications of the ACM 13(6). </li></ul><ul><li>Modelo muy simple, flexible hasta cierto punto </li></ul><ul><li>Todo en tablas, con columnas y filas </li></ul><ul><li>Operaciones para crear, borrar, modificar tablas </li></ul><ul><li>Otras operaciones (álgebra relacional) para manipular (consultar) estas tablas... </li></ul><ul><li>El modelo se caracteriza por tres elementos </li></ul>
  9. 9. Características del modelo <ul><li>Elemento estructural : forma de guardar datos </li></ul><ul><ul><li>todo en tablas, y nada más que tablas </li></ul></ul><ul><ul><li>sin duplicar registros (filas, tuplas) </li></ul></ul><ul><ul><li>campos (columnas) con nombres únicos </li></ul></ul><ul><ul><li>entradas en un campo de solo un tipo </li></ul></ul><ul><ul><ul><li>numérico (entero, real..), texto, fecha, etc. </li></ul></ul></ul><ul><ul><li>todas las entradas serán datos atómicos </li></ul></ul><ul><ul><li>orden de filas/columnas no importa </li></ul></ul><ul><ul><li>valores nulos soportados (<> 0) </li></ul></ul><ul><ul><li>claves para crear relaciones (solo una es clave primaria) </li></ul></ul>
  10. 10. Características (2) <ul><li>Elemento de manipulación : que se puede hacer </li></ul><ul><ul><li>Entrada: una o mas tablas </li></ul></ul><ul><ul><li>Salida: una tabla nueva </li></ul></ul><ul><ul><li>Codd define álgebra y cálculo relacional (el usuario no los vea) </li></ul></ul><ul><ul><li>En la práctica, solo son 3 operadores fundamentales: </li></ul></ul><ul><ul><ul><li>SELECT : especificar “criterios de búsqueda” y crear una nueva tabla con solo los datos que buscábamos </li></ul></ul></ul><ul><ul><ul><li>PROJECT : copia un subconjunto de campos a una tabla nueva </li></ul></ul></ul><ul><ul><ul><li>JOIN : “pega” dos tablas para crear una nueva </li></ul></ul></ul><ul><ul><li>Select y Join: operaciones críticas en el SIG vectorial </li></ul></ul>
  11. 11. Características (3) <ul><li>Elemento de integridad : control lógico </li></ul><ul><ul><li>Integridad de entidades </li></ul></ul><ul><ul><ul><li>garantiza que los campos clave tengan datos (no nulos) y que si existe un registro se puede localizar </li></ul></ul></ul><ul><ul><li>Integridad referencial </li></ul></ul><ul><ul><ul><li>mantiene intactas relaciones (referencias) de clave a clave </li></ul></ul></ul><ul><ul><ul><li>no puedes borrar un registro al que depende otra tabla </li></ul></ul></ul><ul><ul><ul><li>los dos campos clave deben ser del mismo tipo </li></ul></ul></ul>
  12. 12. Grado = 5 Cardinalidad = 2155
  13. 15. ¿Como manipular los datos/tablas? <ul><li>Structured Query Language, SQL </li></ul><ul><li>Viene de Sequel (IBM, 1974), todavía se pronuncia “siquel”, aunque oficialmente es “S.Q.L.” </li></ul><ul><li>Un estándar ANSI, ISO pero... </li></ul><ul><ul><li>Los fabricantes han creado sus propias versiones no exactamente estándares... </li></ul></ul><ul><ul><li>PL/SQL de Oracle <> SQL de MS Access (Jet) </li></ul></ul><ul><ul><li>Muchos SIG utilizan ficheros DBF o MDB, que los manipulan sin los gestores dBase o Access </li></ul></ul><ul><ul><li>Ningún fabricante soporta el 100% del estándar </li></ul></ul>
  14. 16. SQL y el modelo relacional <ul><li>SQL no forma parte del modelo relacional </li></ul><ul><li>Query-By-Example (QBE), otros lenguajes de consulta pueden aplicarse también al modelo </li></ul><ul><li>SQL ha sido aceptado como el lenguaje de facto </li></ul><ul><li>SQL aceptado por Codd, con matices </li></ul><ul><li>Sirve como lenguaje completo: de definición (DDL) y de manipulación (DML) de datos según el modelo relacional </li></ul><ul><li>Tiene una estructura “pseudo inglésa” </li></ul><ul><li>Se utiliza como lingua franca entre sistemas </li></ul>
  15. 17. Repaso de comandos SQL <ul><li>DDL: </li></ul><ul><ul><li>CREATE <tabla> </li></ul></ul><ul><ul><li>DROP <tabla> </li></ul></ul><ul><li>DML: </li></ul><ul><ul><li>SELECT <columna(s) de datos> </li></ul></ul><ul><ul><li>FROM <tabla(s)> </li></ul></ul><ul><ul><li>WHERE <condición lógica> </li></ul></ul>
  16. 18. Ejemplos del sintaxis SQL <ul><li>create table zona ( </li></ul><ul><li>IdZona smallint not null unique, </li></ul><ul><li>NomZona char(30) not null unique, </li></ul><ul><li>Superf smallint, </li></ul><ul><li>IdOfCD smallint not null </li></ul><ul><li>); </li></ul><ul><li>create table tipo ( </li></ul><ul><li>IdTipo smallint not null unique, </li></ul><ul><li>DescTipo char(30) not null unique </li></ul><ul><li>); </li></ul>
  17. 19. Mas ejemplos... <ul><li>SELECT DISTINCT NomCons </li></ul><ul><li>FROM ofarea,relacion,ofcd,zona,parcela,construc </li></ul><ul><li>WHERE NomAr=’Central’ </li></ul><ul><li>AND ofarea.IdAr=relacion.IdAr </li></ul><ul><li>AND relacion.IdOfCD=zona.IdOfCD </li></ul><ul><li>AND zona.IdZona=parcela.IdZona </li></ul><ul><li>AND parcela.IdCons=construc.IdCons; </li></ul>
  18. 20. 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;
  19. 22. Relaciones <ul><li>Son BBDD relacionales, ¿no? </li></ul><ul><li>Dividimos los datos entre varias tablas (específicas) para minimizar la duplicación de datos, y también las dependencias entre campos </li></ul><ul><ul><li>proceso conocido como normalización (sección 4.1.3) </li></ul></ul><ul><li>Hay relaciones de 3 tipos entre atributos </li></ul><ul><ul><li>1:1, una persona tiene un DNI </li></ul></ul><ul><ul><li>1:M, una persona tiene muchos amigos </li></ul></ul><ul><ul><li>M:N, una tienda tiene muchos clientes, cada uno de los cuales es cliente de muchas tiendas </li></ul></ul>
  20. 23. Relaciones (2) <ul><li>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 </li></ul><ul><li>Ejemplo de la Videoteca: </li></ul><ul><ul><li>tabla “clientes” (cada cliente es único) </li></ul></ul><ul><ul><li>tabla “películas” (cada película es única) </li></ul></ul><ul><ul><li>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? </li></ul></ul><ul><li>Solución: nueva tabla “movimientos”, con campos en común con “clientes” y “películas” </li></ul>
  21. 24. Claves <ul><li>Para enlazar tablas mediante un campo en común </li></ul><ul><li>Claves primarias (campo único), como DNI en la tabla “clientes” </li></ul><ul><li>Claves externas (foráneas), como DNI en la tabla “movimientos” </li></ul><ul><li>Ejemplo de Neptuno en Access </li></ul>
  22. 25. Diseño de la Base de Datos <ul><li>Cuales son las entidades (y sus atributos ) de importancia </li></ul><ul><li>Cuales son las relaciones entre ellas </li></ul><ul><li>Creación de modelos E-A-R tratada en detalle en la sección 4 del libro Unigis </li></ul><ul><li>Luego diseñar una bdatos física de acuerdo con el modelo </li></ul><ul><li>Este diseño no es una tarea trivial </li></ul><ul><li>La explotación del SIG (consultas posibles) se basa en este diseño !! </li></ul><ul><li>Rediseñar una base de datos a posteriori MUY caro !! </li></ul>
  23. 26. SQL en el ámbito SIG <ul><li>Se utiliza (SQL es un estándar de facto ) </li></ul><ul><ul><li>Cuando sabes SQL, sabes el 30% de cualquier SIG vectorial </li></ul></ul><ul><li>Pero no es lenguaje óptimo para representar las relaciones espaciales (basadas en la geometría) </li></ul><ul><ul><li>cerca de, pasando por, intersección con, dentro de </li></ul></ul><ul><li>Y no permite interacción multimodal </li></ul><ul><ul><li>¿Cuáles son las carreteras que pasan por este <señalizando con ratón> barrio? </li></ul></ul><ul><li>En general: SQL es para tablas de texto </li></ul><ul><li>“ SQL sirve para modelar como la gente utiliza tablas” </li></ul>
  24. 27. Problemas con SQL <ul><li>Normalmente el SIG maneja datos alfanuméricos (en tablas relacionales) y gráficos (en ficheros propietarios)... </li></ul><ul><li>Ejemplos de Arc/INFO, MapInfo </li></ul><ul><li>SQL no ofrece herramientas para la parte gráfica </li></ul><ul><ul><li>No es eficiente guardar miles (millones) de coords x,y,z en columnas largas </li></ul></ul><ul><ul><li>Para representar un polígono hace falta crear por lo menos 5 tablas y sus relaciones correspondientes </li></ul></ul><ul><ul><li>Demasiado complicado y lento </li></ul></ul>
  25. 28. Problemas con SQL (2) <ul><li>¿Como optimizar almacenamiento de datos espaciales? </li></ul><ul><ul><li>Puedes ordenar un campo y definir un índice (que siempre es unidimensional) sobre este campo </li></ul></ul><ul><ul><li>Contra la norma de Codd, que el orden no importa </li></ul></ul><ul><ul><li>Y ¿qué campo vas a elegir? Sólo coord-x, sólo coord-y... </li></ul></ul><ul><ul><li>En general, lectura de tablas relacionales es muy lenta (olvídalo para dibujar elementos geográficos) </li></ul></ul><ul><li>Indices bidimensionales </li></ul><ul><ul><li>Quadtree, KDB-tree (van Oosterom) </li></ul></ul><ul><ul><li>Decomposición/indexación regular en 2-D del espacio </li></ul></ul>
  26. 29. Problemas con SQL (3) <ul><li>No se puede definir “tipos de datos abstractos” </li></ul><ul><li>Modelo relacional define CHAR, ENTERO, REAL, FECHA, etc. </li></ul><ul><li>Sería útil poder definir tipos geométricos por ejemplo: </li></ul><ul><ul><li>línea, nodo, rectángulo... </li></ul></ul><ul><li>Reconocida hace 20 años la necesidad de extensiones especiales al SQL para servir los campos SIG, CAD, diseño... </li></ul>
  27. 30. Solución 1: Pseudo-SQL <ul><li>Ejemplo de MapInfo </li></ul><ul><ul><li>Han definido extensiones para “objetos geográficos” </li></ul></ul><ul><ul><ul><li>aquí objeto = entidad (no es OO) </li></ul></ul></ul><ul><ul><ul><li>obj contiene otro obj, tiene intersección con, esta completamente dentro... </li></ul></ul></ul><ul><ul><li>Gestor de base de datos hecho por MapInfo, que entiende estas extensiones, y que trabaja con ficheros DBF </li></ul></ul><ul><ul><li>No cumple con muchas normas del ANSI SQL </li></ul></ul><ul><ul><li>Pero funciona... </li></ul></ul>
  28. 32. Solución 2: “SQL espacial” <ul><li>Bundock y otros (Smallworld) </li></ul><ul><li>Herring y otros (Intergraph>>Oracle) </li></ul><ul><li>van Oosterom (en libro anexo Unigis) </li></ul><ul><li>SQL-3 algo más flexible, permite algo de OO </li></ul><ul><li>SQL-MM (multimedia) </li></ul><ul><li>Oracle Spatial (todos los datos en tablas relacionales) </li></ul><ul><li>Basado en un nuevo modelo objeto-relacional </li></ul><ul><li>Soporta algo de SQL, algo de conceptos OO, programación desde Java, C++, etc. </li></ul>
  29. 33. Ejemplos, Oracle Spatial <ul><li>¿Cuales son los parques con ríos? </li></ul><ul><ul><li>SELECT parks.name </li></ul></ul><ul><ul><li>FROM parks, rivers </li></ul></ul><ul><ul><li>WHERE </li></ul></ul><ul><ul><li>sdo_geom.relate(parks.geometry, rivers.geometry, </li></ul></ul><ul><ul><li>’ OVERLAPBDYINTERSECT’) = ’OVERLAPBDYINTERSECT’; </li></ul></ul>
  30. 34. Otro de Oracle Spatial <ul><li>Parques por donde pasa la carretera I-93 </li></ul><ul><ul><li>SELECT Parks.Name FROM Parks, Roads </li></ul></ul><ul><ul><li>WHERE </li></ul></ul><ul><ul><li>MDSYS.SDO_RELATE(Parks.Geometry, Roads.Geometry, </li></ul></ul><ul><ul><li>’ MASK=ANYINTERACT’) = ’TRUE’ </li></ul></ul><ul><ul><li>AND Roads.Name = ’I-93’; </li></ul></ul>
  31. 35. BBDD objeto-relacional <ul><li>En su infancia </li></ul><ul><li>Oracle liderando el campo, empujando fuerte </li></ul><ul><ul><li>tiene grupo de 200 trabajando en temas especiales </li></ul></ul><ul><li>BD relacionales poseen una masa crítica sustancial </li></ul><ul><li>Todos los sistemas utilizan indexación 2-D (o n-D) para mejorar rendimiento </li></ul><ul><ul><li>tema tratado en otro modulo de Unigis </li></ul></ul>
  32. 36. El futuro de las BBDD <ul><li>Ya que vivimos en tiempo de Internet, nadie sabe </li></ul><ul><li>¿Será la propia Internet (web) nuestra base de datos? </li></ul><ul><ul><li>Todo distribuido </li></ul></ul><ul><ul><li>Todo conectado </li></ul></ul><ul><li>Faltan nuevos índices, buscadores </li></ul><ul><li>Es una base de datos con dominio abierto </li></ul><ul><ul><li>crece al ritmo de 100.000 páginas (recursos) al día </li></ul></ul><ul><ul><li>no es posible la consulta “Dame un listado de todos los recursos sobre tal tema” </li></ul></ul><ul><li>Otros tiempos, otros SIGs </li></ul>
  33. 37. Gracias por vuestra atención.

×