Bases de Datos - Departamento de Lenguajes y Sistemas Informáticos

Departamento de Lenguajes y Sistemas Informáticos
E.T.S. Ingeniería Informática. Universidad de Sevilla
Avda Reina Mercedes s/n. 41012 Sevilla
Tlf/Fax 954 557 139 E-mail lsi@lsi.us.es Web www.lsi.us.es
Bases de Datos
Tema 3
Modelos de datos
Sevilla, marzo 2005
V 2005.01.1
E.T.S. Ingeniería
Informática
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
Indice
1
INTRODUCCIÓN ......................................................................................... 3
1.1
NECESIDAD DE ESQUEMAS ........................................................................................... 3
1.2
CONCEPTOS DE MODELACIÓN DE DATOS ..................................................................... 4
1.2.1 Universo de discurso.................................................................................................................... 4
1.2.2 Modelos y esquemas..................................................................................................................... 4
1.3
CLASIFICACIÓN DE MODELOS DE DATOS ...................................................................... 6
2
COMPONENTES DE UN MODELO DE DATOS .................................... 6
2.1
FORMALIZACIÓN DEL CONCEPTO DE MODELO DE DATOS ............................................ 6
2.2
ESTÁTICA DE LOS MODELOS DE DATOS......................................................................... 7
2.2.1 Tipos de estructuras ..................................................................................................................... 7
2.2.2 Mecanismos de abstracción......................................................................................................... 8
2.2.2.1 Clasificación o generalización instanciación o particularización ................................................................................ 8
2.2.2.2
2.2.2.3
2.2.2.4
2.2.3
Agregación ..................................................................................................................................................................... 9
Jerarquías de generalización..........................................................................................................................................10
Asociación....................................................................................................................................................................11
Restricciones................................................................................................................................ 11
2.2.3.1 Clasificación.................................................................................................................................................................11
2.2.3.2 Componentes de una restricción.....................................................................................................................................13
METABASE DE DATOS BASE DE DATOS ....................................................................14
2.3
2.4
DINÁMICA ...................................................................................................................14
2.4.1 Operadores .................................................................................................................................. 14
2.4.2 Transacciones.............................................................................................................................. 15
2.4.2.1
2.4.2.2
3
Concepto ......................................................................................................................................................................15
Regla de atomicidad y puntos de sincronismo.................................................................................................................15
LOS MODELOS DE DATOS EN EL PROCESO DE DISEÑO...............16
Pág. 2 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
1 Introducción
1.1
Necesidad de esquemas
El ser humano es eminentemente simbólico; desde que nace se expresa de diversas maneras
(lenguaje hablado, lenguaje corporal) y recibe el cúmulo de sensaciones que representa la vida y,
sobre todo, la relación con nuestros semejantes. El ser humano ha evolucionado constantemente
en estas formas de expresión, creando diversos idiomas y ha inventado otras diversas maneras de
expresarse: la música, la pintura, la escultura, en definitiva: lenguajes de símbolos. En su evolución
ha llegado a crear la escritura, lenguajes matemáticos y lenguajes que permiten esquematizar. En
diversos campos de la ingeniería se representan esquemas: planos (arquitectura), esquemas
eléctricos (electricidad), esquemas de máquinas (ingeniería mecánica), Etc. Etc.
Para transmitir mensajes simples puede bastar con expresiones faciales (alegría, sorpresa, dolor,
Etc.). Para aclarar la razón de estos estados puede ser necesario y, generalmente basta, el lenguaje
hablado; necesitamos movernos en el dominio (emisor y receptor) del mismo lenguaje para poder
entendernos. Para arbitrar y dictaminar sobre conflictos entre personas (laborales, familiares,
civiles) el ser humano ha creado reglas: “el derecho civil”, “derecho administrativo”, “derecho
laboral”, Etc.. Los juristas se sirven del lenguaje escrito (la ley, la jurisprudencia, pruebas
documentales) y del lenguaje hablado (testimonios) para emitir estos dictámenes que permiten
aclarar las situaciones de conflicto. El ser humano sigue creando reglas continuamente.
En construcciones simples (un arreglo del baño de un domicilio), un pequeño arriate en el jardín
son proyectos que pueden ser especificados basándose en el lenguaje hablado o en el lenguaje
natural escrito; se trata de productos simples de obtener. Crear un programa que gestione una lista
de teléfonos puede ser una tarea equivalente en especificación de software; es decir, está muy clara
la estructura y la funcionalidad que debe tener el producto final; del mismo modo, basta con decir
¿qué datos queremos? y ¿cómo queremos que se presente la lista?.
Ahora bien, si se trata de la construcción de un hospital con capacidad para 10.000 camas, o de un
centro académico para alojar tres titulaciones universitarias y al menos 5.000 alumnos ¿qué duda
cabe que no es inmediato pasar de esta necesidad a la acción de construir?. Del mismo modo, tanto
un patinete como un buque o un avión a reacción son vehículos, pero la complejidad de su
construcción los diferencia notablemente.
En diversos campos de la ingeniería, si se ha de crear un producto complejo (edificio, máquina, etc.)
se requiere un experto en la materia. Los expertos en diversas materias han creado lenguajes
(nuevas reglas de expresión y representación) universales para aclarar y desarrollar la especificación
del producto complejo que se ha de crear. La arquitectura e ingeniería civil han creado lenguajes
para la representación de planos (elevados a nivel de estandarización nacional: ANSI, DIN, UNE e
internacional: ISO) de modo que la representación del conocimiento no es ambigua sino clara y
precisa (pues todo el mundo entiende la convención): un arquitecto no tiene que explicar a otro lo
que significa una raya o una cota en un plano, pues los símbolos son cerrados y significan lo que
para ellos se ha acordado en la semántica que encierran. Los planos se hacen a escala, con lo que
los muros, situación de puertas, ventanas, canalizaciones son precisos y obligarán al constructor
(contratista) en la fase de edificación.
El ser humano ha creado en estos campos del saber “un proceso” que va desde la necesidad de un
producto complejo expresada por el usuario hasta la puesta a disposición del mismo. Desde que
decidimos que se necesita un edificio académico hasta que se pueden dar clases lectivas en él pasa
un tiempo que se estructura en fases claramente diferenciadas: concepción o especificación
general del edificio (maquetas o modelos, planos generales (planta, alzado, perfil)), diseños
Pág. 3 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
detallados (estudios geológicos del terreno: las condiciones para construir un edificio no son las
mismas en Madrid <bajo nivel sismológico> que en San Francisco <alto nivel de riesgo
sismológico>, diseño de interiores, diseño de canalizaciones, etc.). Es decir, antes de construir es
necesario invertir un esfuerzo mental muy importante en diseñar el producto; para diseñarlo es
necesario centrarse en diferentes aspectos del mismo. Para cada uno de estos aspectos existen
lenguajes (gráficos, matemáticos, etc.) que permiten cerrar la especificación y comportamiento de
lo que pretendemos obtener. Está más que justificada la convención universal de estos lenguajes,
más cerrados que el lenguaje natural (herramienta propicia para la literatura) pero mucho más
precisos y con menos ambigüedades.
Para crear un producto software el ser humano se vale también de lenguajes (lenguajes de
programación en la fase de construcción o programación, lenguajes gráficos o matemáticos en la
fase de concepción: análisis y diseño del sistema).
Una parte estructural muy importante en un producto software complejo pueden ser las estructuras
de datos. Se requerirán lenguajes que permitan especificar la estructura de estos datos en la fase de
concepción: análisis y diseño y en la fase de implementación o construcción del sistema. Para crear
un lenguaje es necesario convenir unas reglas que permitan transmitir el conocimiento. Un modelo
de datos va a ser ese conjunto de conceptos y reglas que, dotado con una sintaxis, formalizan un
lenguaje. Con los lenguajes (p.ej. SQL es un lenguaje basado en el modelo relacional de datos, en
concreto, está basado en el cálculo relacional de tuplas) se podrán expresar diseños o concepciones
de estructuras de datos: esquemas de esos datos.
En este tema se presentan los principales conceptos de modelos de datos: esquemas, objetos,
propiedades, asociaciones, operaciones, restricciones, etc.; se realiza una clasificación de los diversos
tipos de modelos de datos y se estudian los principales mecanismos de abstracción utilizados en
esta área.
1.2 Conceptos de modelación de datos
1.2.1
Universo de discurso
Todo software ha de tener un alcance (limitado)
funcional: está dirigido a una farmacia, a una
universidad, a una petrolera, etc.
El diseñador debe establecer el contorno del
problema; es decir “lo que forma y lo que no
forma parte del problema”. Este contorno se
denomina universo de discurso y es la parte del
mundo que, para el fin del software a construir,
interesa al diseñador. Lo que está dentro del contorno forma parte del problema y lo que está fuera
no forma parte del problema. Es relevante definir claramente este contorno.
1.2.2 Modelos y esquemas
El ser humano crea modelos o simplificaciones de la realidad para poder comprenderla y
expresarla. Crear estos modelos implica tareas de simplificación o abstracción de la realidad, de
modo que representamos sólo los aspectos que interesa resaltar de esa realidad que se pretende
alcanzar; así: “una maqueta no es el edificio sino la apariencia a escala y la situación o
localización de elementos que pretendemos”. El plano de detalle de canalizaciones (agua,
electricidad, gas, telefonía, cableado inteligente) de una habitación no es la habitación sino la parte
que nos interesa resaltar para comunicar con los agentes especializados de la construcción
(electricistas, fontaneros, etc.); Por otro lado, en la maqueta no están los detalles de estos planos ni
en estos planos podemos ver la apariencia exterior y localización de elementos de un edificio (aulas,
Pág. 4 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
laboratorios, bar, jardines, etc.). Se requieren diversos esquemas (generales y de detalle) del
mismo universo (el centro académico a construir).
Un modelo/esquema1 puede definirse como “la abstracción mental de la realidad observada en
la que se resaltan los aspectos que se pretenden transmitir”. Es decir, se simplifica la
representación, desechando otras características reales que pueden estar representadas en otros
modelos/esquemas o bien que son irrelevantes para el proceso de construcción.
Tsichritzis y Lochovsky (1982) son autores que se han preocupado de formalizar el concepto
abstracto de modelo de datos: “Dispositivo de abstracción que nos permite ver el bosque (esto
es, la información contenida en los datos) en oposición a los árboles (valores individuales
de los datos)”.
Dittrich (1994) lo define como “conjunto de herramientas conceptuales para describir la
representación de la información en términos de datos. Los modelos de datos comprenden
aspectos relacionados con: estructuras, tipos de datos, operaciones y restricciones”.
De Miguel, Piattini y Marcos (1999) lo definen como “conjunto de conceptos, reglas y
convenciones que permiten describir y manipular los datos de la parcela de un cierto
mundo real que deseamos almacenar en la base de datos”.
Es decir: un modelo es el conjunto de reglas y convenciones que van a permitir cerrar una
especificación, de modo que el emisor y el receptor de la idea comprendan y asuman claramente
estas convenciones y la especificación esté exenta de ambigüedades.
Los modelos de datos son el soporte para la creación de distintos tipos de lenguajes, siendo un
lenguaje la concreción expresiva de estas reglas bajo una sintaxis o gramática concreta:
Lenguaje de datos ≡ {Modelo de datos,Sintáxis}
Es importante distinguir entre modelo de datos y esquema.
Un esquema puede definirse como:
Dittrich (1994): "Descripción específica de un determinado mini-mundo en términos de un
modelo de datos se denomina esquema (o esquema de datos) del mini-mundo. La colección
de datos que representan la información a cerca del mini-mundo constituye la base de
datos”,.
De Miguel, Piattini y Marcos (1999): “Representación de un determinado mundo real (universo
del discurso) en términos de un modelo de datos”.
Nótese la ambigüedad en el dominio de lo coloquial, pues se confunde modelo con esquema o maqueta (en el sentido
de que se trata de una simulación o representación). Se aclarará al distinguir y precisar en el terreno de la modelación de
datos.
1
Pág. 5 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
1.3 Clasificación de modelos de datos
Según el nivel de abstracción que se considere en referencia a la arquitectura ANSI/X3/SPARC
puede establecerse una clasificación de los modelos de datos en:
Externos: Orientados a cada usuario en particular.
Globales: Orientados al conjunto de usuarios (contiene el modelo integrado para toda la
organización).
Internos: Consideran la implementación física (entorno tecnológico: sistema operativo,
organización de archivos soportados, etc.).
Se utiliza la expresión “modelos lógicos” para hacer referencia tanto a los modelos globales como a
los externos, ya que ambos describen aspectos lógicos de los datos, frente a los “modelos internos”
que describen aspectos físicos.
Los modelos lógicos se pueden dividir en:
Conceptuales o semánticos: están enfocados a describir el mundo real con independencia
de la tecnología (máquinas, redes, sistemas operativos). Ej: Modelo Entidad/Interrelación de
Chen (ME/R), Orientados a Objetos (Diagramas de clases de UML).
Convencionales: están orientados a la implementación en un SGBD que soporta un
determinado modelo de datos: Relacional de Codd (RM/B Codd), Jerárquico, Red (Codasyl),
Relacional.
Modelo de datos convencional
Implementados en SGBD comerciales
Dependen del SGBD
Más próximos al ordenador
Poca capacidad semántica
Más enfocados a la implementación
Interfaz informático/sistema
Nivel de “mediación” entre nivel externo/interno
Modelo de datos conceptual
No suelen estar implementados en SGBD
Independientes del SGBD
Mayor nivel de abstracción
Mayor capacidad semántica
Más enfocados al diseño de alto nivel
(modelación conceptual)
Interfaz usuario/informático
2 Componentes de un modelo de datos
2.1 Formalización del concepto de modelo de datos
Los componentes de todo modelo de datos se pueden estructurar en estática y dinámica del modelo.
Un modelo de datos (MD) se define formalmente como el par MD = <S, D>.
S es el conjunto de reglas de generación que permiten representar la componente estática
(estructuras del modelo y sus restricciones) y
D es el conjunto de operaciones autorizadas sobre la componente estática E u operaciones que
permiten representar la componente dinámica.
La estática permite formalizar la especificación de estructuras admitidas (serán el soporte de los
lenguajes de definición de datos: LDD o DDL (data definition languages), considerándose:
Pág. 6 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
a) Elementos permitidos (Estructuras: Se)
Objetos y vínculos entre objetos (Ejemplo: Juan y María son objetos de una clase
persona, mientras que “casado con” es un predicado o vínculo que puede ligar a
Juan y María en una relación o correspondencia).
Características o propiedades de los objetos (domicilio, email de una persona), tipos
de valores admisibles (string, €, longitud_inch2, ciudades_españolas, etc..).
b) Elementos no permitidos o invalidados por restricciones (Sr)
S=< Se, Sr >, la estática del modelo permite definir determinadas estructuras e invalidar
determinados estados en la base de datos (estados inadmisibles).
La Dinámica es un componente del modelo que facilitará la manipulación de instancias de las
estructuras de la base de datos definidas con los componentes estáticos (serán el soporte de los
lenguajes de manipulación de datos LMD o DML (data manipulation languages) que permitirán
escribir transacciones). La dinámica ofrecerá operadores o expresiones para realizar acciones sobre
los datos.
2.2
Estática de los modelos de datos
2.2.1 Tipos de estructuras
Los elementos permitidos no son los mismos para todos los MD; varían especialmente en
terminología, pero en general son Objetos (entidades, relaciones, registros, etc.), vínculos entre
objetos (interrelaciones, “set”, etc.), propiedades o características de objetos o vínculos (atributos,
campos, elementos de datos, etc.), dominios o conjuntos de valores homogéneos admisibles sobre
los que se definen las propiedades.
A estos elementos permitidos se les podrán aplicar aquellas abstracciones reconocidas por el
modelo.
La representación de estos elementos depende de cada modelo de datos, pudiendo hacerse en forma
de grafos (Red CODASYL, ME/R de Chen, UML), relaciones o conjuntos (Relacional), árboles
(jerárquico), etc.
Es fundamental conocer el tipo de estructuras admisibles y la semántica que soportan. Desde un
punto de vista genérico pueden agruparse características comunes empleadas en diversos modelos
bajo el siguiente epígrafe de “mecanismos de abstracción”.
Pág. 7 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
2.2.2 Mecanismos de abstracción
Los procesos de abstracción ayudan a modelar los datos; el modelador debe centrarse en lo esencial,
pasando por alto aspectos que son irrelevantes o que caen fuera del universo de discurso.
Los MD ofrecen distintos mecanismos de abstracción para facilitar la representación de los
esquemas de datos; este esquema es el resultado de aplicar un proceso de abstracción a un
determinado mundo real (universo de discurso). Los principales mecanismos de abstracción son:
Clasificación o generalización 4 instanciación o particularización
Agregación
Jerarquías de generalización
Asociación (según algunos autores es un tipo de agregación)
Pueden combinarse entre sí ofreciendo interesantes mecanismos semánticos para estructurar datos.
La clasificación establece una vinculación entre una categoría (clase) de objetos y cada objeto en
particular (instancia) que pertenece a dicha categoría, mientras que en las otras tres (agregación,
generalización y asociación) la relación se establece entre categorías de objetos y, por tanto,
también entre los correspondientes ejemplares de dichas categorías.
Los mecanismos de abstracción los utilizamos a diario (consciente o inconscientemente). P.ej.:
El vehículo de matrícula CR-0978-Z es (especialización) de la clase ambulancia. La
ambulancia es una generalización del conjunto de vehículos utilizados en el hospital.
Una ambulancia está formada (agregación) por cuatro ruedas, un chasis, un motor.
El propietario (asociación) de la ambulancia matrícula CR-0978-Z es la empresa
CUASER; su conductor (asociación) es José Fernández.
2.2.2.1
Clasificación o generalización 4 instanciación o particularización
La generalización (clasificación) es el mecanismo de abstracción que selecciona características
comunes a un conjunto de ocurrencias o instancias para crear una categoría a la cual pertenecen
dichas ocurrencias o instancias. El mecanismo contrario se denomina instanciación (o
particularización).
Ejemplo: Se clasifican o generalizan como Vehículos al conjunto de máquinas, animales o cosas,
con medios de propulsión propios, que sirven para desplazar seres u objetos desde una posición a
otra:
Ambulancia → SI es un vehículo
Grúa → NO es un vehículo (incumple la propiedad de autopropulsión).
La
clasificación
se
corresponde con el concepto
de pertenencia a un conjunto
(es miembro de): entre el
elemento
clase
y
los
elementos miembros se
establece una correspondencia
que atiende al verbo: “es
miembro de”.
Pág. 8 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
Las instancias o ejemplares de una clase tienen características similares, por medio de las cuales se
describe la correspondiente clase; estas características toman valores concretos para cada uno de las
instancias que pertenecen a la clase.
Los mismos objetos admiten clasificaciones distintas. Por ejemplo, pueden clasificarse las
asignaturas:
obligatorias / optativas
anuales / semestrales
de primer curso, de segundo curso.
2.2.2.2 Agregación
La abstracción de agregación consiste en construir un nuevo elemento del modelo como
compuesto de otros elementos (componentes). Atiende al verbo “es parte de” entre los elementos
componentes y el elemento compuesto. El mecanismo contrario se llama desagregación.
Se pueden considerar tres tipos distintos de agregación:
Agregación de propiedades individuales para describir una clase (entidad superior).
Admitida explícita o implícitamente por todos los MD.
Agregación de propiedades para obtener una propiedad compuesta (El agregado de
datos). Admitida por algunos MD: p.ej.:Codasyl Sí; el modelo relacional básico de Codd no
admite agregados de datos.
Agregación de clases para obtener una clase compuesta. Sólo la incluyen los MD semánticos:
ER, UML.
Pág. 9 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
2.2.2.3 Jerarquías de generalización
Las jerarquías de generalización permiten abstraer características comunes a varias clases
(subclases) para constituir una clase más general (superclase) que las contiene.
El conjunto de ejemplares de una subclase “es un” subconjunto de los ejemplares de la
correspondiente superclase.
Entre los elementos subclase y el elemento superclase se establece una relación del tipo
es_un (Las jerarquías de generalización suponen un refinamiento de la abstracción de
generalización donde la interrelación o vínculo es entre clases en vez de entre objetos
(miembros. P.ej. Vehículo matrícula SE-2048-CTX) y clases (objeto genérico. P.ej.
Vehículo).
La superclase PERSONA es una generalización de las subclases PROFESOR y ESTUDIANTE.
Cada jerarquía de generalización es un árbol de un solo nivel donde la raíz es la superclase y las hojas
son las subclases.
El mecanismo inverso de la abstracción de jerarquía de generalización es la especialización (las
subclases son casos particulares o específicos de la superclase).
Todo ejemplar de una subclase es también ejemplar de la superclase y, además de poseer las
características específicas de la subclase, hereda todas las correspondientes a la superclase.
Aunque esta abstracción es intuitiva muy útil no se contempla en todos los modelos de datos (P.ej.
ni el modelo relacional básico de Codd ni en el modeló E/R básico de Chen, pero sí en modelos
extendidos de Chen o en el modelo relacional extendido de Codd RM/T o en UML).
Pág. 10 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
2.2.2.4 Asociación
La asociación es una abstracción que se utiliza para vincular dos o más clases (por tanto sus
instancias o ejemplares) creándose un elemento de un tipo distinto.
En algunos MD no aparece esta abstracción como tal, no existiendo ningún concepto especial para
representarla (Ej. Ni RM/B de Codd ni ERM de Chen, pero sí en RM/T de Codd y modelos EER).
Matrimonio
Ejemplo: Hombre ↔ Mujer , donde las clases Hombre y Mujer se asocian en una nueva clase
Matrimonio. Matrimonio es una nueva clase con entidad propia a la cual se pueden vincular tanto
propiedades (fecha y lugar de celebración) como establecer vínculos con otras entidades (p.ej., la
compra de una casa). Matrimonio no es un mero vínculo o correspondencia entre instancias de
entidades Hombre y Mujer; tiene sustantividad por si.
2.2.3
Restricciones
2.2.3.1 Clasificación
Se conocen como restricciones las reglas que impiden que determinados objetos o estados se
consoliden en la base de datos. Existen dos tipos:
Restricciones inherentes al propio modelo o estructurales (Ej.:si el modelo es jerárquico, la
única estructura es un árbol y no podrá representarse directamente una correspondencia m:n,
pues los vínculos entre padre e hijo son 1:n).
Restricciones de integridad semánticas (RIS) o explícitas, p.ej.:
restricciones de rango I 1{∀a(a : alumno) → a.edad ∈ [18, 65]}
ecuaciones lógicas


I 2 ∀d (d : debe) ∧ ∀h(h : haber ) ∧ (h.N º asiento = d .N º asiento) → ∑ h.importe =∑ d .importe 
h
d


Pueden ser:
Propias del MD (semántica integrada): su definición corresponde al diseñador, pero su
gestión es responsabilidad del modelo de datos, el cual las reconoce y recoge en el esquema.
La reusabilidad está garantizada al especificarse universalmente las reglas.
Ajenas al MD (semántica dispersa): son, por completo, responsabilidad del diseñador, ya
que el modelo de datos no las reconoce ni proporciona instrumentos para manejarlas. El
diseñador tiene que hacer código ajeno a la BD para incluirlas. Se dificulta la reusabilidad y se
pueden generar colisiones o inconsistencias de reglas.
Pág. 11 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
Restricciones propias
Las restricciones PROPIAS (B2) se especifican al definir el esquema mediante las facilidades que
proporciona la función de definición de datos (DDL), almacenándose en la metabase de datos (no
en los programas), por lo que no pueden ser violadas por ninguna aplicación, es decir, cualquier
actualización está obligada a respetarlas.
Dependiendo de que sea o no preciso definir la acción:
Acción general. Es preciso programar un procedimiento (en cualquier lenguaje) que determine la
acción que hay que llevar a cabo. Se subdividen en:
Procedimientos almacenados. Se definen de forma procedimental
Disparadores (triggers). Se formula una condición de forma declarativa y cuando se
cumple una proposición lógica; el cumplimiento de la misma "dispara" la acción que puede
ser declarativa o un método programado..
Acción específica. La acción (en general rechazo, aunque puede ser otra, bien predeterminada bien
elegida mediante opciones) está implícita en la misma restricción.
Dentro de las restricciones de acción específica es preciso distinguir entre:
Condición general. La condición se define mediante una proposición lógica. La operación
será una actualización. No se declara la acción porque este tipo de restricción lleva siempre
asociado el rechazo de la operación cuando no se cumple la condición, es decir, el sistema
evalúa la condición y si el resultado es cierto se actualiza y si no es cierto no se lleva a cabo la
operación. P.ej., en SQL 92 se incluyen dos tipos de restricciones que son de condición
general:
Pág. 12 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
Verificación. La expresión lógica mediante la cual se formula la condición está
definida sobre uno o varios atributos de un mismo elemento. Por ejemplo, una
claúsula "CHECK” dentro de un CREATE TABLE.
Aserción. Son análogas a las anteriores pero pueden estar referidas a más de un
elemento del esquema ya que tienen existencia por sí mismas (por tanto tienen un
nombre). Ej.: CREATE ASSERTION ..
Condición específica. También denominadas de "caso especial" ó "implícitas”. Se refiere a las
diversas opciones que facilitan los distintos MD cuando se definen los elementos de su esquema y
que en realidad son restricciones. Por ejemplo, en el modelo Relacional: PRIMARY KEY,
FOREIGN KEY, NOT NULL ...
2.2.3.2 Componentes de una restricción
En una restricción de integridad es posible distinguir los siguientes componentes:
La operación de actualización (inserción, borrado o modificación) cuya ejecución ha de dar
lugar a la comprobación del cumplimiento de la restricción.
La condición que debe cumplirse, la cual es en general una proposición lógica, definida sobre
uno o varios elementos del esquema, que puede tomar uno de los valores de verdad (cierto o
falso).
La acción que debe llevarse a cabo dependiendo del resultado de evaluar la condición.
Las restricciones de integridad se pueden considerar, en cierto modo, como reglas ECA (Evento,
Condición, Acción): “al ocurrir un evento (en este caso una actualización), se comprueba una condición y
dependiendo de su resultado se pone en marcha una acción (rechazar la operación, informar al usuario, corregir el
error, etc.)”.
Además de estos elementos, también pueden tener un nombre, por medio del cual es posible
identificarlas, y también puede indicarse el momento en el que ha de evaluarse la condición.
Pág. 13 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
2.3 Metabase de datos base de datos
La aplicación de la componente estática de un MD a un determinado Universo del Discurso (UD)
nos da como resultado un esquema de base de datos o metabase de datos (MBD):
G[UD] = MBD(EMBD,RMBD)
MBD es la estructura de datos que describe, en el correspondiente modelo MD, las categorías que
han resultado de las abstracciones aplicadas al mundo real (UD) así como las restricciones de
integridad que se trata de modelar. La metabase de datos está compuesta por las estructuras del
esquema (EMBD) y las restricciones de integridad definidas (RMBD).
Una base de datos (BD: conjunto de instancias de datos) es la instanciación de una metabase de
datos.
BD
Generalización
Ins tan ciación
MBD . Una instancia de la base de datos configura un estado persistente2 que
representa una situación del universo de discurso. Un estado para hacerse persistente debe satisfacer
todas las restricciones de integridad de la base de datos; a esto se denomina estado consistente.
Sea BDi un estado persistente y consistente; entonces BDi contiene a la MBD y a los valores que
definen la instancia o estado persistente (BDi= RMBD (BDi)3) del universo representado:
BDi(EMBD,RMBD,BDi= RMBD (BDi))
2.4 Dinámica
2.4.1 Operadores
La componente dinámica consta de operadores que se permiten manejar las estructuras del
correspondiente MD.
En un plano abstracto, sin seguir una sintaxis concreta, puede expresarse una sentencia del lenguaje
de manipulación de datos (LMD) con la siguiente gramática:
LOCALIZACIÓN <condición> ACCIÓN <objetivo>
Localización o “enfoque”. Consiste en localizar una instancia de un objeto indicando un camino
(lenguaje navegacional), o un conjunto de instancias definido por intensión a través de una
condición (lenguaje de especificación). <condición> representa una expresión lógica que deben
cumplir los objetos que se desea localizar o señala el camino que permite llegar a esos objetos.
Acción (Operador del LMD). Se realiza sobre la(s) instancia(s) localizada(s). Puede consistir en
una operación de recuperación o en una actualización (inserción, borrado o modificación).
<objetivo> indica los objetos (o las propiedades de éstos) sobre los que se aplica la acción.
La aplicación de un operador (O) a una instancia o estado de la base de datos, si es de actualización,
genera un nuevo estado o instancia:
BDj=O(BDi)
Un estado es persistente si puede almacenarse y ser verificado en cualquier instante. Debe diferenciarse entre estado
persistente y estado transitorio o intermedio (normalmente en memoria).
3 Esta ecuación significa que si se aplican todas las reglas de la MBD al estado de la BD se obtendrá el mismo estado, o
dicho de otro modo, cada estado persistente verifica todas las restricciones de integridad de la metabase de datos.
2
Pág. 14 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
Tanto BDi como BDj deben ser estados consistentes. Es decir BDi=RMBD(BDi) y BDj=RMBD(BDj).
Ejemplo:
Actualiza
Notas_de_alumnos
Cambia nota←5
SI nota=4.9
2.4.2
Acción
Objetivo
Enfoque y condición
Transacciones
2.4.2.1 Concepto
En general, la lógica de actualización de los datos de los sistemas de información está agrupada en
tareas ejecutables denominadas transacciones.
Una transacción (T) puede definirse como una sucesión de acciones (ai) u operaciones sobre la base
de datos; es decir T ≡ { a1, a 2, ... ai , .., a n − 1, an} ; expresado funcionalmente y partiendo de un estado
consistente (BDi) de la base de datos, esta transacción necesariamente debe llevar a un nuevo estado
consistente (BDi+1) :


(


BDi + 1 = T ( BDi ) = an  a n−1 ... ai ... a 2  a1 ( BDi ) 





(
))










Los estados intermedios pueden no ser consistentes.
2.4.2.2 Regla de atomicidad y puntos de sincronismo
Del concepto de transacción se deduce que una transacción debe comportarse como una unidad
lógica de trabajo BDi + 1 = T ( BDi ) ; es decir, una transacción si sufre una interrupción (puede suceder
pues todas las operaciones suceden en un tiempo finito y cuantificable y pueden darse causas como
fallos del medio, del sistema operativo, del propio entorno de la base de datos, comunicaciones, etc.)
no debe dejar la base de datos en ese estado intermedio, puesto que puede ser consistente.
Punto de sincronismo. Se identifican:
Comienzo. El instante o punto de inicio de la transacción (primitiva de gestión de transacciones
Begin(T)).
Terminación. La terminación puede ser normal o terminación con confirmación de los resultados
de la transacción (primitiva Commit(T)) o bien terminación anormal en caso de interrupción
(primitiva Abort(T)).
Regla de atomicidad de una transacción. “Una transacción se comporta como una unidad
lógica de trabajo, de modo que se garantiza siempre la consecución de un estado final consistente”.
Cuando la transacción ejecuta la primitiva Commit(T) se habrá alcanzado el estado final objetivo de
la transacción; sin embargo, si la transacción ejecuta (por razones diversas) la primitiva Abort(T),
entonces no se llegará al estado final objetivo BDi+1 , siendo la única opción volver al estado de
partida BDi, siendo necesario deshacer los cambios asociados a los estados intermedios
(inconsistentes por estas acciones que están vinculadas al todo o acción atómica de la transacción).
Para poder deshacer estos cambios se necesitará funcionalidad en los gestores de bases de datos
dentro del seno de los subsistemas de gestión de recuperación de la base de datos; este proceso de ir
hacia atrás deshaciendo cambios se conoce como ROLLBACK de la transacción.
Pág. 15 de 16
Bases de Datos
Modelos de datos
Sevilla, Marzo/2005, V 2005.01.1
3 Los modelos de datos en el proceso de diseño
Se conoce como proceso de diseño de una BD al conjunto de tareas necesarias para representar un
sistema objetivo (Universo de discurso) mediante un esquema. Los MD juegan un importante papel
en el proceso de diseño de una BD al ofrecer el soporte de abstracción adecuado para obtener estos
esquemas.
Los objetivos que persigue todo MD son
de dos tipos:
Formalización. El MD permite definir
formalmente las estructuras y restricciones
a través de lenguajes de datos.
Base del diseño. El MD es un elemento
fundamental en el desarrollo de una
metodología de diseño de BD; entorno al
esquema formalizado se construirán los
otros artefactos o componentes del
sistema.
Pág. 16 de 16