Bases de datos espaciales introducción

21/09/2010
Bases de datos espaciales
Tema 2: Modelado de datos y
modelos de bases de datos
Miguel Ángel Manso
ETSI en Topografía, Geodesia y
Cartografía - UPM
Basado en Yeung, A. & Hall B. “Chapter 3: Database models and data modeling”,
Spatial Database Systems.
Contenido
• 1.- Introducción (conceptos)
• 2.- Modelos comunes de BBDD
• 3.- Principios y técnicas de modelado de datos
1
21/09/2010
1.- Modelado Conceptual de los datos
• What information is needed?
• How should it be structured?
• What kinds of algorithms will operate on the
data?
Introducción: def. modelo de BBDD
• En este contexto modelo es: conjunto de
conceptos, lenguaje y gráficos usados para
describir la estructura de una base de datos.
Metafóricamente plan de ordenación vs frente a un proyecto constructivo.
• Los conceptos son: objetos y fenómenos
(reales o abstractos) relevantes sobre la
información que demandan los usuarios.
– Entidades (ER) u objetos (OO)
– “data object” e instancia (BBDD)
2
21/09/2010
Modelado
2.- Conceptualización
3.- Documentación
1.- Abstracción
Relación: modelo, esquema e instancia
• Modelo: conceptos, lenguaje y gráficos
• Esquema: descripción de una base de datos
• Instancia: un conjunto de datos que $ en una base de datos en un t
metafóricamente:
• Modelo de la base de datos: idioma (vocabulario y reglas
lingüísticas para describir aspectos del mundo)
• Esquema es una representación de una parte específica del mundo
en la BBDD (instantánea invariante en el tiempo para describir la
estructura de los datos y las operaciones)
• Instancia: ocurrencia de unos datos (objetos) en la bbdd.
(instantánea de los datos invariantes almacenados en la bbdd). Si
los datos cambian cambia la instancia.
3
21/09/2010
Modelo, esquema e instancia
Modelados
• Conceptual: representación abstracta del mundo
a alto nivel (independiente del Hw y Sw)
• Esquema Lógico: es un esquema conceptual que
tiene presentes las consideraciones del software
al definir el esquema de la base de datos
(dependiente del DBMS)
• Modelado Físico de los datos: aspecto técnico en
el que se relacionan los esquemas lógicos y físicos
(dependiente del Hw) como tipos de datos,
4
21/09/2010
¿Qué es el modelado conceptual?
• Conceptual Data Model
– Expression (enumerar, declarar) of structure, data
types and relationships (a static view)
– Expression of dynamic or operational behavior
– Expression of integrity constraints
– A source of system metadata
– A vehicle to describe the system to users
Ejemplo de modelo Conceptual
5
21/09/2010
Modelado: nivel lógico
• Primera tarea y consiste en definir el esquema
de la base de datos, esto depende del modelo
lógico de datos soportados por el SGBD
• Modelos lógicos existentes:
– Entidad Relación (ER)
– Modelo Entidad Relación extendido (Objeto
relacional)
– Orientados a objeto
Lógico
6
21/09/2010
Nivel físico
• Funciones que desempeña el nivel físico:
– Almacenamiento eficiente en disco y ficheros
– Aceleración en las búsquedas (índices)
– Procesamiento de consultas (o evaluación)
– Optimización de consultas, para obtener mejores
rendimientos
– Concurrencia y recuperación
Físico
7
21/09/2010
Resumen: Importancia del modelado
• Proporciona los medios para que el diseñador
exprese los requisitos de usuario, se diseñen
pruebas de concepto, se comparen alternativas y
se muestre el aspecto de la base de datos cuando
se implemente
• Es una herramienta necesaria para que se
comuniquen diseñadores, desarrolladores,
usuarios y promotores de BBDD
• Permite subdividir los problemas y abordarlos
• Requiere inversión previa (coste) , pero evita
riesgos
2.- Modelos comunes de BBDD
•
•
•
•
Modelo E/R
Modelo Relacional
Modelo Orientado a Objeto
Modelo Objeto-Relacional
Spatial database with application to GIS, Rigaux (pg 5)
8
21/09/2010
Diseño E-R
• Objetivo: servir de medio de comunicación entre
los usuarios de los datos y los equipos de
desarrollo y como acta de las decisiones de
diseño adoptadas. Se basa en diagramas y existe
un flujo de trabajo en el proceso de diseño
• Focaliza en la identificación de las entidades, la
definición de los atributos, y el establecimiento
de las relaciones con sus características
(cardinalidad, obligatoriedad y las restricciones)
• los atributos pueden ser: simples/compuestos,
derivados, claves y con múltiples valores
Flujo diseño E-R
9
21/09/2010
Modelo relacional
• Más dependiente del SGBD que el diseño E-R
• Se definen tablas para: datos y relaciones
• Filas | tuplas | registros contienen columnas |
atributos |campos
• Una o varias columnas sirven de clave para la
tabla
• Cada celda de una tabla sólo puede contener un
valor o el valor null
• Los valores de los datos que se almacenan en una
celda pertenecen a un dominio de valores
Restricciones en el diseño Relacional
• de dominio: valores permitidos para un atributo
• de entidad: un atributo != null si es clave
• referencial: aplica a las claves secundarias (SK) o
externas (FK) y que implica la existencia de un
registro en la otra tabla que adopte el valor de
esta clave (PK)
• reglas de negocio: otras restricciones que deben
satisfacer los atributos para poder realizar una
operación con un registro (i.e. superficie > 0.5m2)
10
21/09/2010
Implementación M. Relacional
(Normalización)
• Para poder garantizar las restricciones de integridad
y las reglas de negocio, existen un conjunto de tareas
de normalización denominadas formas normales
• Existen 3 formas normales (1NF, 2NF y 3NF) :
Link interesante: http://www3.uji.es/~mmarques/f47/apun/node90.html
Diseño Relacional
• Consta de:
– Modelado conceptual: tipos de entidades y
relaciones. Herramientas: ER, UML, OMT
– Nivel lógico: mediante DDL (lenguaje de definición
de datos) se traslada el modelo conceptual al
modelo de la base de datos
11
21/09/2010
Relacional
attribute 1
entity
attribute 2
attribute n
entity
relationship
entity
• Relaciones 1:1, 1:N, N:N
• Cardinalidad, obligatoria u optativa, fuerte o débil
Entidad relación extendido
• Añade a ER la generalización y la especialización
• Por tanto algo similar a la orientación de objetos
– Specialization
• Types with generic attributes
• Subtypes with specialized attributes and methods
• Disjoint or overlapping relationships
– Generalization
• The opposite of specialization
• Identifies common properties of entities and captures them
in a super-class
– Specialization and generalization may result in the
same model but may be derived differently
12
21/09/2010
Modelado de datos espaciales con ER
– Entities: nodes, arcs, areas
– Attributes: node, arc, area ids
– Relationships: bound, begin, end
– Subtypes: left/right_area, begin/end_node
Modelo orientado a objeto
• ¿Por qué? Las aplicaciones necesitan manejar
distintos tipos de objetos no solo texto y
números: gráficos, vídeo, sonidos y mapas
• Los tipos abstractos de datos (ADT) permiten
modelar este tipo de contenidos y desarrollar las
tecnologías orientadas a objetos
• Un objeto puede definirse como un dato
conceptualmente autónomo en un ordenador
que representa una entidad real del mundo con
la capacidad de actuar por sí mismo e interactuar
con otros objetos
13
21/09/2010
Componentes de un objeto
•
•
•
•
•
•
•
•
Nombre
Identificador único
Atributos
Estado
Tipo de datos base
Métodos
Mensaje
Reglas de negocio y control
El modelado OO destaca por
• Object-Oriented Paradigm
– Programming Languages
– Analysis and Design Methodologies
– Databases and DBMS
• O-O Advantages
– More modeling power
– Additional constructs
– Better transition to implementation models
14
21/09/2010
Fundamentos Modelo OO
• Static data-oriented representation as well as
dynamic behavior
– The E-R model is static only
• The dynamic behavior of an object is expressed
by the operations (or methods) allowed on it
• Object = state + functionality
– The object region = a set of coordinates + operations
to calculate its area, display itself, create an instance
of itself or delete itself
• Objects request services from one another
through messages
Características Modelos OO
•
•
•
•
•
An Object Identity (identificador único)
Encapsulation (aislamiento y reutilización)
Inheritance (facilita la construcción)
Composition (asociaciones y agregaciones)
Polymorphism (implementar las mismas operaciones en
distintos objetos)
• Object Declaration
• General Object Operations
15
21/09/2010
3. - Principios y técnicas de modelado
• Los cuatro principios del modelado
• El ciclo de vida de los desarrollos en sistemas y
BBDD
• Herramientas CASE
• Diseño conducido por el usuario
• Documentación de los modelos de datos
Los cuatro principios del modelado
• Elección del modelo influencia decisivamente
cómo se aproxima y se forma la solución
• Todos lo modelos deben poder expresarse con
distintos niveles de detalle
• Los mejores modelos están conectados con la
realidad
• No es suficiente un solo modelo: la
interrelación de varios modelos es mejor que
cualquiera de las soluciones simples
16
21/09/2010
Ciclo de vida de los desarrollos
Ciclo de vida software
17
21/09/2010
En las bases de datos
Herramientas CASE
• Se componen de:
– Entornos de desarrollo de sistemas (principalmente
herramientas gráficas para definir esquemas)
– Repositorio donde almacenar e integrar todos los
desarrollos y las tomas de decisiones
– Diccionario de datos completo
• Tipos:
– Front-end: ayuda en planificación, análisis y diseño
– Back-end: soporte en desarrollo e implantación
– Cross life cicle: soporta todas las actividades incluidas
las de soporte a la gestión y documentación
18
21/09/2010
Diseño conducido por el usuario
• El diseño tradicionalmente ha estado supeditado a la
tecnología.
• También es usual que se centre en la usabilidad de
los sistemas (friendliness)
• De aquí surge la idea de centrado en el usuario (UCD)
y sus méritos son:
– Proporcionar un marco bien estructurado compatible con los
conceptos de diseño de los ciclos de vida del desarrollo
– Participación de los usuarios en el proceso de modelización
– Fuerte interacción entre usuario y diseñador en el proceso de
modelado
– El Modelo se construye por aproximaciones sucesivas
Documentación de los modelos de datos
• Cualidades deseables de la documentación del
modelado:
– Expresividad: considerando el gran abanico de
conceptos anotaciones sintácticas y diagramas
– Simplicidad: fácilmente entendible por todos los
actores (usuarios, analistas, desarrolladores,..)
– Minimalista: garantizar que no hay ambigüedad entre
los conceptos
– Formal: especificar los datos y su estructura
• UML
19