Story Transcript
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. Universidad Politécnica de Madrid
Miguel Ángel Manso
Contenido • 1.- Introducción (conceptos) • 2.- Modelos comunes de BBDD • 3.- Principios y técnicas de modelado de datos
Universidad Politécnica de Madrid
Miguel Ángel Manso
1
1.- Modelado Conceptual de los datos • What information is needed? • How should it be structured? • What kinds of algorithms will operate on the data?
Universidad Politécnica de Madrid
Miguel Ángel Manso
Introducción: def. modelo de BBDD • En este contexto modelo es: el conjunto de conceptos, lenguaje y gráficos usados para describir la estructura de una base de datos Metafóricamente plan de ordenación vs 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) Universidad Politécnica de Madrid
Miguel Ángel Manso
2
Modelado
2.- Conceptualización
3.- Documentación 1.- Abstracción
Universidad Politécnica de Madrid
Miguel Ángel Manso
Relación: modelo, esquema e instancia • Modelo: conceptos, lenguaje y gráficos • Esquema: es la 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 que sirve 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 Universidad Politécnica de Madrid
Miguel Ángel Manso
3
Modelo, esquema e instancia
Universidad Politécnica de Madrid
Miguel Ángel Manso
Niveles de Modelado • 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) Por ejemplo: tipos de datos Universidad Politécnica de Madrid
Miguel Ángel Manso
4
¿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
Universidad Politécnica de Madrid
Miguel Ángel Manso
Ejemplo de modelo Conceptual
Universidad Politécnica de Madrid
Miguel Ángel Manso
5
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
Lógico
Universidad Politécnica de Madrid
Miguel Ángel Manso
6
Nivel físico • Funciones que desempeña el nivel físico: – Almacenamiento eficiente en disco y ficheros – Aceleración en las búsquedas (índices) – Evaluación y procesamiento de consultas – Optimización de consultas, mejorar rendimiento – Concurrencia y recuperación
Universidad Politécnica de Madrid
Miguel Ángel Manso
Físico
Universidad Politécnica de Madrid
Miguel Ángel Manso
7
Resumen: La importancia del modelado • Proporciona medios para: – – – –
que el diseñador exprese los requisitos de usuario se diseñen pruebas de concepto se comparen alternativas se muestre el aspecto de la base de datos cuando se implemente
• Es una herramienta necesaria de comunicación entre diseñadores, desarrolladores, usuarios y promotores de la BBDD • Permite subdividir los problemas y abordarlos • Requiere inversión previa (coste) , pero evita riesgos Universidad Politécnica de Madrid
Miguel Ángel Manso
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) Universidad Politécnica de Madrid
Miguel Ángel Manso
8
Diseño E-R • Objetivo: – servir de medio de comunicación entre los usuarios de los datos y los equipos de desarrollo – servir de acta de las decisiones de diseño adoptadas
• Se basa en diagramas y ofrece 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 (multiplicidad, obligatoriedad y las restricciones) • los atributos pueden ser: simples/compuestos, derivados, claves y con múltiples valores Universidad Politécnica de Madrid
Miguel Ángel Manso
Flujo diseño E-R
Universidad Politécnica de Madrid
Miguel Ángel Manso
9
Modelo relacional • Más dependiente del SGBD que el diseño E-R • Se definen las tablas que materializan: las entidades y las 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 Universidad Politécnica de Madrid
Miguel Ángel Manso
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) e 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 (p.e. superficie > 0.5m2) Universidad Politécnica de Madrid
Miguel Ángel Manso
10
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) :
Afecta a las claves primarias compuestas Evitar relaciones que permitan llegar a un dato de más de una forma
Link interesante: http://www3.uji.es/~mmarques/f47/apun/node90.html Universidad Politécnica de Madrid
Miguel Ángel Manso
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
Universidad Politécnica de Madrid
Miguel Ángel Manso
11
Relacional attribute 1 entity
attribute 2
attribute n entity
entity
relationship
• Relaciones 1:1, 1:N, N:N • Cardinalidad, obligatoria u optativa, fuerte o débil Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
12
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
Universidad Politécnica de Madrid
Miguel Ángel Manso
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 de datos abstractos (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 Universidad Politécnica de Madrid
Miguel Ángel Manso
13
Componentes de un objeto • • • • • • • •
Nombre Identificador único Atributos Estado Tipo de datos base Métodos Mensajes Reglas de negocio y control Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
14
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
15
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
Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
16
Ciclo de vida de los desarrollos
Universidad Politécnica de Madrid
Miguel Ángel Manso
Ciclo de vida software
Universidad Politécnica de Madrid
Miguel Ángel Manso
17
En las bases de datos
Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
18
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 del diseño 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 Universidad Politécnica de Madrid
Miguel Ángel Manso
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 Universidad Politécnica de Madrid
Miguel Ángel Manso
19