Bases de Datos

Bases de Datos
Notas de Curso
Miguel Murguía
miguelmurguía@gmail.com
México, D.F.
Mayo, 2004
Junio, 2005
Contenido
I Introducción......................................................................6
I. Conceptos Básicos de Bases de Datos...........................................6
1.1 Panorama de las Bases de Datos.............................................................. 6
1.2 Modelos de Datos: 3 Niveles...................................................................... 9
1.3 Los Lenguajes en las Bases de Datos ..................................................... 12
1.4 Arquitectura general de un DBMS............................................................ 14
Preguntas....................................................................................................... 16
2. El Modelo Entidad-Relación .........................................................17
Generalidades del Modelo Entidad-Relación ................................................. 17
Dominios y Atributos ...................................................................................... 27
Restricción en las relaciones.......................................................................... 28
Relaciones (papeles y recursividad) .............................................................. 29
II El Modelo Relacional de Bases de Datos ....................30
1. Introducción al Modelo Relacional................................................30
Antecedentes y orígenes del Modelo Relacional ........................................... 30
Conceptos del Modelo Relacional .................................................................. 31
Tuplas ............................................................................................................ 32
Diagrama E-R para una escuela .................................................................... 36
Otra definición de relación.............................................................................. 37
Esquemas de relaciones ................................................................................ 38
Esquema de una Base de Datos.................................................................... 40
Notación ......................................................................................................... 41
2. Principales características del Modelo Relacional .......................42
Restricciones del Modelo Relacional.............................................................. 42
Relación: el único tipo de dato compuesto..................................................... 43
Críticas al modelo Entidad-Relación .............................................................. 44
Evolución del Modelo Relacional ................................................................... 45
Diferencias entre las Matemáticas y en el Modelo Relacional del concepto de
relación y terminología ................................................................................... 46
Objetivos del Modelo Relacional .................................................................... 47
Interrelación de información entre relaciones distintas .................................. 47
Transacción.................................................................................................... 48
SQL (Structured Query Language) ................................................................ 49
DBMS relacionales......................................................................................... 50
La relación universal ...................................................................................... 51
Razones para soportar dominios ................................................................... 52
Recuerde que … ............................................................................................ 54
Bases de Datos. Miguel Murguía. FAR.
2
III Álgebra Relacional ......................................................55
1. Operadores básicos del Álgebra Relacional ................................55
Introducción.................................................................................................... 55
Los operadores .............................................................................................. 56
Proyección ..................................................................................................... 58
Theta-Selección ............................................................................................. 60
Combinando selección y proyección .............................................................. 62
Select y Theta-Select ..................................................................................... 63
Theta-selección extendido ............................................................................. 65
Producto cartesiano ....................................................................................... 66
Renombrar ..................................................................................................... 71
Unión.............................................................................................................. 72
Compatibilidad de unión................................................................................. 73
Diferencia ....................................................................................................... 74
Definición formal del álgebra relacional.......................................................... 75
Intersección.................................................................................................... 76
Producto natural............................................................................................. 77
Theta Join ...................................................................................................... 79
Theta Join extendido ...................................................................................... 81
Join natural..................................................................................................... 81
División........................................................................................................... 82
División (Reforzamiento) ................................................................................ 85
Asignación...................................................................................................... 86
Ejercicios I...................................................................................................... 88
Ejercicios II..................................................................................................... 89
2. Modificación de la Base de Datos ................................................90
Asignación...................................................................................................... 90
Inserción......................................................................................................... 91
Actualización .................................................................................................. 92
Borrar ............................................................................................................. 93
3. Vistas ............................................................................................93
Definición de vistas ........................................................................................ 93
Modificabilidad de las Vistas .......................................................................... 95
Algoritmo VU .................................................................................................. 96
IV Diseño de bases de Datos Relacionales .......................97
1. Normalización ...............................................................................97
Dependencia funcional................................................................................... 97
1a. forma normal ............................................................................................ 99
2a. forma normal ............................................................................................ 99
3a. forma normal .......................................................................................... 101
Forma normal de Boyce-Codd ..................................................................... 103
4a. forma normal .......................................................................................... 105
Dependencia multivaluada ........................................................................... 107
Limitaciones de la normalización ................................................................. 109
Dependencia de reunión (join) ..................................................................... 110
5NF o PR/NF (forma normal de proyección-reunión)................................... 111
Bases de Datos. Miguel Murguía. FAR.
3
Resumen de Formas Normales ................................................................... 115
Dependencias Funcionales .......................................................................... 116
Axiomas de Armstrong ................................................................................. 117
Análisis......................................................................................................... 119
Síntesis ........................................................................................................ 120
Ejercicios...................................................................................................... 121
2. Árboles, redes y relaciones recursivas .......................................123
Árboles ......................................................................................................... 123
Relaciones recursivas .................................................................................. 124
Redes........................................................................................................... 126
3. Integridad....................................................................................127
Integridad de dominio................................................................................... 127
Integridad intra-relacional............................................................................. 129
Integridad referencial ................................................................................... 129
Integridad semántica intra-relacional ........................................................... 130
Análisis de consistencia en bases de datos geográficas.............................. 130
Afirmaciones ................................................................................................ 131
Disparadores................................................................................................ 132
4. Autorizaciones ............................................................................132
5. Catálogo .....................................................................................135
On-line.......................................................................................................... 135
Concurrencia................................................................................................ 135
Descripción de dominios, relaciones base y vistas ...................................... 137
Restricciones de integridad .......................................................................... 138
Funciones definidas por el usuario............................................................... 139
Datos de autorización .................................................................................. 139
Estadísticas.................................................................................................. 139
V Lógica y Cálculo Relacional de Tuplas ......................141
1. Lógica .........................................................................................141
Operadores lógicos ...................................................................................... 141
Tablas de verdad ......................................................................................... 143
Tautologías .................................................................................................. 145
Reglas de inferencia .................................................................................... 145
Equivalencias lógicas ................................................................................... 149
2. Lógica de predicados .................................................................150
Lenguaje de 1er orden o de predicados....................................................... 150
Reglas de la negación:................................................................................. 150
Reglas de cuantificación .............................................................................. 151
3. Cálculo relacional de tuplas........................................................153
Bibliografía .......................................................................156
Páginas WWW .................................................................157
Temarios ...................................................................................................... 157
Bases de Datos. Miguel Murguía. FAR.
4
Modelo Relacional........................................................................................ 157
ANEXO 1. Prolog como Base de Datos ..........................158
A) Código del Programa .................................................................158
B) Resultado de Querys .................................................................160
Bases de Datos. Miguel Murguía. FAR.
5
I Introducción
I. Conceptos Básicos de Bases de Datos
1.1 Panorama de las Bases de Datos
Orígenes del modelo relacional
La era de las bases de datos relacionales se inicia con la publicación de una serie de
artículos de Codd; el primero es:
Codd, E. F. 1970. A relational model of data for large shared data banks.
Communications of the ACM 13:377-387.
Previo al modelo relacional existían otros, los más populares eran el modelo de red y el
modelo jerárquico. Actualmente se puede decir que esos modelos fueron un camino
recorrido que llevó al modelo relacional. Aunque los modelos jerárquico y de red son la
base de algunos DBMS usados en la actualidad, se puede decir, en general, que esos
modelos son historia.
A inicios de los años 60’s se construyó lo que se puede considerar el primer DBMS, el
sistema “Integrated Data Store”, por Charles Bachman de la General Electric que sentó las
bases del modelo de red. A finales los años 60’s nace el IMS (Information Management
System) de IBM y que fue base del modelo de jerárquico.
El modelo relacional soluciona varios de los problemas no resueltos por otros modelos
previos, sin embargo, se debe de considerar que el correcto planteamiento de los problemas
es en sí un avance hacia su solución. Así, los modelos jerárquico y de red pueden
considerarse como escalones en la construcción de modelos eficientes de bases de datos.
El modelo relacional es robusto debido a la formalidad con que se plantea, pues está
fundamentado matemáticamente en el álgebra de relaciones. En la actualidad, una de las
principales alternativas al modelo relacional es el modelo orientado a objetos, sin embargo,
el modelo relacional aún se considera más importante por su fundamento, la cantidad de
usuarios, herramientas y sistemas comerciales existentes.
Bases de Datos. Miguel Murguía. FAR.
6
Los “Turing Award”
Los reconocimientos “Turing Award” son el equivalente en computación al premio Nobel.
El área de Bases de Datos ha recibido ya tres de ésos reconocimientos: el primero para
Bachman, por haber puesto las bases del modelo de red; el segundo para Codd por su
Modelo Relacional, y el tercero para James Gray por sus trabajos sobre el concepto de
transacción en Bases de Datos.
Objetivos de los DBMS
Los sistemas manejadores de bases de datos (DBMS por sus siglas en inglés) son un tipo
de sistemas informáticos enfocados a la tarea del almacenamiento y recuperación de
información, por lo que pueden ser sujetos a las metodologías de desarrollo de sistemas,
por ejemplo UML. Existe una amplia gama de DBMS comerciales, como por ejemplo MSAccess, MS-SQL_Server, Oracle, Informix o Sybase; También existen alternativas de
DBMS libres como MySQL o PosgreSQL.
Los DBMS pueden ser vistos como “esqueletos” de bases de datos, en los que sólo es
necesario incorporar los datos específicos de nuestra aplicación, por ejemplo, los nombres
de los alumnos de una escuela, las calificaciones para cada materia, las claves de los grupos
y los nombres de los profesores. Sin embargo, también es necesario definir la “estructura”
de los datos, es decir el modelo de datos. Ese modelo de datos debe construirse de acuerdo
a las necesidades de información, ya que para un mismo dominio (escuela o un sistema de
control de inventario, por ejemplo) existen varias maneras de definir el modelo de acuerdo
al nivel de precisión que se requiera.
Los principales objetivos de los DBMS son:
•
•
•
Almacenamiento de grandes volúmenes de información.
Procesamiento de la información (generación de reportes, análisis, reportes
ejecutivos).
Seguridad, eficiencia y oportunidad en la información.
Los DBMS dan facilidades para realizar varias tareas comúnmente asociadas a la
información de una base de datos, como son la definición de la estructura de las tablas
donde se almacenará la información, el tipo de datos a almacenar, la creación de pantallas
de captura, la generación de reportes, clasificaciones, filtros, actualizaciones, entre otras.
Por ejemplo, para una base de datos de una escuela, el DBMS debe dar facilidades para:
•
•
•
•
•
•
Registro de calificaciones.
Impresión de listas de los grupos.
Captura de calificaciones finales.
Corrección de calificaciones.
Reportes de materias que adeuda un estudiante.
Promedios de calificaciones por materia.
Bases de Datos. Miguel Murguía. FAR.
7
• Generación de historias académicas.
Se puede generar un programa para cada tarea que funcione de manera independiente para
constituir un “sistema procesador de archivos”. Pero se tienen los problemas de:
Redundancia e inconsistencia de datos. Las direcciones de los clientes pueden estar
almacenados en dos archivos (por ejemplo, en el de “cuentas de ahorro” y en el de “cuentas
de cheques”), lo que hace que ocupen doble espacio, además de que se puede generar la
situación de que se actualice sólo en un archivo generando una inconsistencia.
Dificultad en el acceso. Casi todas las consultas son planeadas. Para hacer consultas no
planeadas se necesitan escribir nuevos programas.
Aislamiento de los datos. Los datos están repartidos en varios archivos, por lo que pueden
tener diferentes formatos y es necesario escribir programas para cada nuevo proceso.
Seguridad. No todos los usuarios del sistema deben tener acceso a todas las operaciones
(v.g. actualización de saldos, ver ciertas cuentas, etc.).
Integridad. Los valores de los campos de las tablas deben satisfacer ciertas “restricciones
de dominio”. Por ejemplo, las cuentas de ahorro no deben contener cantidades negativas.
Las ventajas de los DBMS con respecto a los sistemas de archivos son:
•
•
•
•
•
•
•
Independencia de Datos
Eficiencia en el Acceso
Integridad y Seguridad
Administración de Datos
Acceso Concurrente
Recuperación de Crash
Desarrollo de Aplicaciones en tiempos reducidos
La independencia de datos se refiere a que los programas de aplicación están aislados de la
forma en que estructuran los datos, y a su vez, la forma en que estructuran los datos tiene
cierta independencia de cómo se almacenan físicamente. Se logra gracias a la existencia de
“esquemas”, que se revisarán más adelante.
Bases de Datos. Miguel Murguía. FAR.
8
1.2 Modelos de Datos: 3 Niveles
Abstracción de datos
Uno de los objetivos de los sistemas de bases de datos es mostrar una visión abstracta de
los datos, es decir, se esconden ciertos detalles de cómo se almacenan y manejan los datos,
para mostrar sólo aquellos aspectos de utilidad práctica al usuario.
Esa visión abstracta de los datos puede clasificarse en tres niveles:
Nivel físico. Se describe el almacenamiento digital de los datos en la memoria principal y
secundaria de la computadora. Se debe de considerar la arquitectura y atributos de los
sistemas y medios de almacenamiento.
Nivel conceptual. Se describe la información que se almacena en la base de datos, hasta
cierto punto independientemente del sistema físico en el que se implemente. En este nivel,
la información ya tiene un carácter semántico concreto y directo para los usuarios (v.g. un 7
no se ve como una representación decimal de 0111 en binario, sino como la calificación de
un alumno en cierta materia).
Nivel de visión. Aunque en el nivel conceptual se describe la manera de almacenar
información que tiene un significado concreto en el dominio de aplicación, en el nivel de
visión se centra aún más en el significado para el usuario. La información se clasifica de
acuerdo al tipo de usuario, cambiando el formato de presentación y seleccionando sólo
aquella de interés directo.
Modelos de datos
Los modelos de datos son herramientas para describir la estructura de una base de datos:
los datos y las relaciones entre ellos, la semántica asociada y las restricciones de
consistencia.
Se clasifican en tres grupos según el nivel de abstracción.
•
•
•
Semántico: Modelos basados en objetos
Lógico:
Modelos lógicos basados en registros
Físico:
Modelos físicos de datos
Bases de Datos. Miguel Murguía. FAR.
9
Nivel SEMÁNTICO:
Niveles conceptual y de visión. Permiten expresar restricciones de datos explícitamente.
Hay muchos modelos, entre ellos:
•
•
•
•
•
•
•
UML
Modelo entidad-relación
Modelo orientado a objetos
Modelo binario
Modelo semántico de datos
Modelo infológico
Modelo funcional de datos
De los anteriores, los más usados en la actualidad son el modelo entidad relación y el
orientado a objetos. Algunos conceptos manejados en el modelo entidad relación son:
Entidades
Relaciones
Conjunto de Entidades
Conjunto de Relaciones
Cardinalidad de Asignación
Diagrama E-R
Conceptos manejados en el modelo orientado a objetos son:
Clases
Instancias
Métodos
Mensaje
Herencia
Polimorfismo
Nivel LÓGICO
Los modelos lógicos basados en registros correspondes a los niveles de abstracción
conceptual y físico. Se llaman basados en registros porque la base de la representación son
los registros de formato fijo, donde cada campo normalmente es de longitud fija, lo que
simplifica su implementación. En el modelo orientado a objetos se utilizan registros de
longitud variable, generando una estructura más rica en el nivel físico.
Los tres modelos de datos más aceptados actualmente son el relacional y el de objetos. Los
modelos de red y jerárquico se consideran, como ya se comento, un escalón histórico para
la concepción del relacional.
Bases de Datos. Miguel Murguía. FAR.
10
Nivel FÍSICO
Los modelos físicos corresponden al nivel de abstracción físico. Hay muy pocos modelos
físicos en uso, a diferencia de los modelos lógicos; dos de los más conocidos son el modelo
unificado y la memoria de elementos.
Esquema: operación de los niveles de abstracción
Los niveles de abstracción de datos son una estrategia para organizar los datos
considerando desde la plataforma física hasta el nivel de usuario. Los esquemas son las
estructuras diseñadas para resolver cada nivel de abstracción, así, los sistemas de bases de
datos soportan varios esquemas:
Nivel de abstracción
Físico
Conceptual
Visión
Esquema
Esquema físico
Esquema conceptual
Esquema externo
En el nivel de visión pueden existir varios subesquemas, ya que su función es brindar una
forma especializada de acceso a la información a cada tipo de usuario.
Figura 2. Los tres niveles de esquemas en los modelos de Bases de Datos.
El esquema es en sí una estructura capaz de almacenar un conjunto de datos. Uno de los
problemas que debe resolver una base de datos es el cambio de la información a través del
tiempo, por esa razón se define el concepto de instancia, que es una colección de datos
almacenada en un determinado instante. Por lo que la instancia, por definición cambiaa
través del tiempo, mientras que el esquema, el diseño global de la BD, normalmente no
cambia o cambia poco y en intervalos de tiempo mucho mayores.
Bases de Datos. Miguel Murguía. FAR.
11
Haciendo una analogía con los lenguajes de alto nivel,el esquema corresponde a la nocón
de tipo, mientras que la instancia a la de valor que adquiere determinada variable.
Independencia de datos
Independencia de datos es la capacidad de modificar la definición de un esquema sin
afectar la definición de un nivel superior.
Independencia Lógica: Modificar el esquema conceptual sin provocar que se necesiten
escribir los programas de aplicación.
Independencia Física: Modificar el esquema físico sin provocar que se necesiten escribir
los programas de aplicación.
La independencia lógica es más difícil de lograr que la física, pues los programas de
aplicación son fuertemente dependientes de los datos que acceden.
La independencia de datos es análoga a los tipos abstractos de datos de los lenguajes de
programación.
1.3 Los Lenguajes en las Bases de Datos
Los DBMS pueden responder a una amplia gama de preguntas sin necesidad de mucho
esfuerzo por parte del usuario. Estas preguntas a la BD se llaman “Queries”. Los lenguajes
para trabajar con datos se pueden dividir en dos tipos, o bien tiene dos funciones:
Lenguaje de definición de datos
Lenguaje de manipulación de datos
Lenguaje de definición de datos
DDL (data definition language): Lenguaje de definición de datos. Especifica un esquema
de base de datos. El resultado de la compilación de un conjunto de instrucciones de DDL
son un conjunto de tablas cuya definición se almacena en el diccionario de datos (o
directorio). El diccionario contiene metadatos (datos sobre los datos).
Lenguaje de manipulación de datos
DML (data manipulation language): Lenguaje que permite a los usuarios acceder los datos
y permite:
• Recuperar información almacenada en la BD
• Incorporar nueva información
• Borrar información
Bases de Datos. Miguel Murguía. FAR.
12
• Modificar información almacenada en la BD
Se pueden dividir en dos tipos:
•
•
Procedimentales (qué datos y cómo obtenerlos)
No procedimentales (qué datos y no cómo obtenerlos)
Lenguaje de consulta: subconjunto del DML que permite sólo consultas, pero no
modificaciones.
El lenguaje usado actualmente como DML y DDL es SQL. Aunque existen sistemas cion
otros lenguajes, se puede de decir que para fines prácticos SQL “es” el lenguaje que
utilizan los DBMS.
Los fundamentos para los lenguajes de “queries” son el Cálculo Relacional y el Álgebra
Relacional, ambos son equivalentes, el primero es declarativo, mientras que el segundo se
concibe con base en operadores.
El administrador de la base de datos
La persona que se encarga del control central del sistema es el “administrador de la base de
datos” (DBA). Sus funciones son:
•
•
•
•
•
•
Definición del esquema.
Definición de la estructura de almacenamiento y del método de acceso.
Modificación del esquema y de la organización física.
Concesión de autorizaciones para el acceso a los datos.
Especificación de las restricciones de integridad.
Aspectos de seguridad
Usuarios de bases de datos
Se pueden clasificar en cuatro:
Programadores de aplicaciones. Generan programas de aplicación en DML, en ocasiones
inmerso en algún lenguaje de alto nivel.
Usuarios sofisticados. No escriben programas de aplicación, pero sí realizan preguntas
sofisticadas en el lenguaje DML.
Usuarios especializados. Usuarios interesados en aplicaciones sofisticadas, como sistemas
expertos, sistemas de Información para Ejecutivos, Sistemas Multimedia (video, sonido,
etc.).
Usuarios finales. Únicamente hacen uso de los programas o “queries” ya establecidos.
Bases de Datos. Miguel Murguía. FAR.
13
1.4 Arquitectura general de un DBMS
En la figura 3 se muestra la arquitectura básica de un DBMS, los diferentes módulos se
pueden agrupar en cuatro grandes clases:
Máquina de evaluación
Gestor de Base de Datos
Administrador de Recuperación
Control de Concurrencia
Figura 3. Arquitectura de un DBMS (tomada de Ramakrishnan y Gehrke, 2003).
Máquina de evaluación. Traduce instrucciones del lenguaje de consultas a instrucciones de
bajo nivel que entiende el gestor de base de datos. Intenta transformarla en una pregunta
equivalente pero eficiente.
Parser
Optimizador
Plan de ejecución
Evaluador. Traduce las instrucciones del DML a comandos de manipulación de
archivos de bajo nivel.
Bases de Datos. Miguel Murguía. FAR.
14
Gestor de Base de Datos. Interfaz entre los datos de bajo nivel y los programas de
aplicación y consultas al sistema:
Métodos de acceso
Administrador del buffer
Administrador de espacio en disco: Asignación de espacio en disco. Estructuras de
datos usadas para representar información.
Administrador de Recuperación. Todos los sistemas informáticos están sujetos a fallas
lógicas y físicas (daño del disco, alteraciones en el suministro de energía, errores de
software, etc.), el DBMS debe ser capaz de detectar estas fallas y tomar las medidas
necesarias para reestablecer la base de datos, normalmente mediante copias de seguridad o
bitácoras (archivos “log”).
Control de Concurrencia. Cuando varios usuarios actualizan la base de datos es posible que
no se conserve la consistencia de los datos. El DBMS debe controlar estas concurrencias,
que es los que permite a los usuarios pensar como si ellos estuvieran trabajando de manera
aislada.
Administrador de transacciones
Administrador de Bloqueos. “protocolo de bloqueo”
Otros elementos que administra el DBMS son:
Precompilador DML. Convierte las instrucciones de DML en un programa de
aplicación, en llamadas normales a procedimientos en lenguaje de alto nivel.
Compilador DDL. Convierte instrucciones de DDL (Data Definition Language) en
un conjunto de tablas con metadatos.
Archivos de Datos. Almacenan la base de datos.
Diccionario de Datos. Almacenan metadatos: datos o información sobre la
estructura de la base de datos.
Índices. Proporcionan acceso rápido a los datos.
Bases de Datos. Miguel Murguía. FAR.
15
Preguntas
1.
2.
3.
4.
5.
¿Cuáles son los niveles de esquemas de una BD?
¿Qué relación tiene la independencia de datos y los esquemas?
¿Cuáles son las ventajas de usar un DBMS?
Identifica cada ventaja con los datos que manipulas en tu trabajo
Explica el concepto de TRANSACCION y su importancia en el manejo de
información.
6. Explica la arquitectura de los DBMS.
7. Define con tus palabras los siguientes conceptos:
• BD Relacional
• Bloqueo
• Concurrencia
• DBA
• DBMS
• DML
• Esquema
• Independencia de Datos
• Nivel de abstracción
• Protocolo de bloqueo
• Recuperación
• Registro de Transacciones
• SQL
Bases de Datos. Miguel Murguía. FAR.
16
2. El Modelo Entidad-Relación
Generalidades del Modelo Entidad-Relación
El modelo entidad relación es un “modelo lógico basado en objetos” que resuelve el
problema de la descripción de datos en los niveles conceptual y de visión. Consiste en un
conjunto de objetos básicos llamados Relaciones y Entidades.
Entidades y Relaciones
Entidad. Objeto que existe y es distinguible de otros. Puede ser físico (v.g. persona o libro)
o abstracto (v.g. día festivo o conceptos).
Conjunto de Entidades. Grupo de entidades del mismo tipo, por ejemplo, el conjunto
(ALUMNO) de todas las personas que toman cursos en la FAR. Los conjuntos
de entidades no necesariamente deben ser disjuntos, por ejemplo ALUMNO y
PROFESOR pueden compartir entidades.
Atributo. Características de las entidades. Una entidad está representada por un conjunto de
atributos. Los atributos representan el uso de un dominio. Por ejemplo,
Nombre_alumno es una atributo del conjunto de entidades ALUMNO.
Dominio. Conjunto de valores permitidos para cada atributo. Por ejemplo, el dominio del
atributo calificación podría ser el conjunto de todos los reales entre 0 y 10.
Relación. Asociación entre dos o más entidades.
Bases de Datos. Miguel Murguía. FAR.
17
Por ejemplo, a continuación se muestra una relación entre las entidades
PROVEEDOR y PRODUCTO:
PRODUCTO
Nombre_producto
LAPIZ
GOMA
CHOCOLATE
CHAMOI
PROVEEDOR
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
MAGO DE OZ
Teléfono
645 4523
234 5467
545 3421
534 6756
Que puede representarse por la tupla:
Nombre_producto
LAPIZ
Nombre_proveedor
LUMEN
Teléfono
234 5467
y podría significar, por ejemplo, que LUMEN vende el producto LAPIZ.
Formalmente:
• Dados los conjuntos D1, D2, ..., Dn, se dice que R es una relación
sobre estos n conjuntos si es un conjunto de n elementos ordenados
(d1, d2, ..., dn) tales que d1 ∈ D1, d2 ∈ D2, ..., dn ∈ Dn.
• Los conjuntos D1, D2, ..., Dn son los dominios de R.
• El valor n es el grado de R.
Dada esa definición, el término relación, también suele usarse para denotar a una
tabla o conjunto de entidades, pues si:
D1= Nombre_proveedor
D2= Teléfono
entonces, la siguiente es una relación:
PROVEEDOR
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
MAGO DE OZ
Teléfono
645 4523
234 5467
545 3421
534 6756
Se dice que PROVEEDOR es una relación de grado 2 y tiene una cardinalidad de 4
(número de tuplas).
Posteriormente se revisará otra definición de relación.
Bases de Datos. Miguel Murguía. FAR.
18
Relación binaria. Relación de grado 2, i.e. entre dos entidades:
R= {di, dj}
Cardinalidad de una relación. Número de entidades que contiene una relación.
Conjunto de Relaciones
Conjunto de relaciones: Conjunto de relaciones del mismo tipo.
Por ejemplo, la relación CATALOGO entre las entidades PROVEEDOR y
PRODUCTO:
PRODUCTO
Nombre_producto
LAPIZ
GOMA
CHOCOLATE
CHAMOI
CATALOGO PROVEEDOR
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
MAGO DE OZ
Teléfono
645 4523
234 5467
545 3421
534 6756
que puede representarse por la tabla:
CATALOGO
Nombre_producto
LAPIZ
LAPIZ
LAPIZ
GOMA
GOMA
CHOCOLATE
CHOCOLATE
CHAMOI
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
LUMEN
EXPENDIO LUPITA
EXPENDIO LUPITA
MAGO DE OZ
EXPENDIO LUPITA
Un conjunto de relaciones puede definirse como un subconjunto de:
R={(e1, e2,... en) | e1 ∈ E1, e2 ∈ E2, ... en ∈ En,}
donde:
Bases de Datos. Miguel Murguía. FAR.
19
e1, e2,... en son entidades;
E1, E2,... En son conjuntos de entidades y
(e1, e2,... en) es una relación.
Cardinalidad de asignación
Cardinalidad de asignación: Número de entidades con las que puede asociarse otra
entidad, dentro de un conjunto de relaciones.
Si A y B son conjuntos de entidades, la cardinalidad de asignación de un conjunto
de relaciones entre ellas, puede ser:
1:1
Si la entidad a∈A está asociada a lo más con una b∈B y la entidad b∈B está
asociada a lo más con una a∈A.
1:N
Si la entidad a∈A está asociada a lo más con una b∈B y la entidad b∈B está
asociada con un número cualquiera de entidades a∈A.
N:M
Si la entidad a∈A está asociada con un número cualquiera de entidades b∈B
y la entidad b∈B está asociada con un número cualquiera de entidades a∈A.
Dependencia de existencia. La entidad x es dependiente por existencia de y, si es necesaria
la existencia de la entidad y para la existencia de x. (Si se borra y, también se
debe borrar x). Se dice que y es la entidad dominante y x la entidad
subordinada.
Bases de Datos. Miguel Murguía. FAR.
20
Cardinalidad de asignación: ejemplos
Cardinalidad de asignación 1:1
ALUMNO
Nombre_alumno
...
DIRECCION
Calle_y_número
Colonia
...
Cardinalidad de asignación 1:N
CARRERA
Nombre_carrera
ALUMNO
Nombre_alumno
...
Cardinalidad de asignación N:M
PRODUCTO
Nombre_producto
LAPIZ
GOMA
CHOCOLATE
CHAMOI
CATALOGO PROVEEDOR
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
MAGO DE OZ
Teléfono
645 4523
234 5467
545 3421
534 6756
Dependencia de existencia: ALUMNO (entidad subordinada) podría ser dependiente de
CARRERA (entidad dominante).
Bases de Datos. Miguel Murguía. FAR.
21
Claves
Superclave. Conjunto de atributos que permiten distinguir de forma única a una entidad
dentro del conjunto de entidades. Por ejemplo, {Rfc} es una superclave de la
entidad CONTRIBUYENTE, también {Rfc, Nombre} es una superclave, pero
{Nombre} no es una superclave, pues varios contribuyentes pueden tener el
mismo nombre.
Clave candidata. Superclave, tal que ningún sobconjunto propio es una superclave. El
concepto de clave candidata sirve para definir conjuntos con cardinalidad
mínima de atributos que identifiquen a las entidades. Pueden existir varias
claves candidatas para cada entidad.
Clave primaria. Clave candidata que elige el diseñador para distinguir a las entidades
dentro del conjunto de entidades.
Clave alterna. Clave candidata que no es la clave primaria.
Conjunto débil de entidades. Conjunto de entidades para el que no se puede definir una
clave candidata.
Conjunto fuerte de entidades. Conjunto de entidades para el que sí se puede definir al
menos una clave candidata.
Entidad dominante. Entidad que pertenece a un conjunto fuerte de entidades.
Entidad subordinada. Entidad que pertenece a un conjunto débil de entidades.
Discriminador. Conjunto de atributos que el diseñador crea de manera artificial para
permitir distinguir de manera única a cada entidad de un conjunto débil de
entidades.
Por ejemplo, el conjunto débil de entidades
TRANSACCION = {Número_de_cuenta,
Número_transacción,
Fecha}
contiene el atributo Número_transacción como discriminador. Así, la clave
primaria de un conjunto débil de entidades está formada por la clave primaria
del conjunto de entidades fuerte del que depende su existencia y el
discriminador.
Bases de Datos. Miguel Murguía. FAR.
22
Por ejemplo,
{Número_de_cuenta, Número_transacción }
distingue entidades TRANSACCION dentro de una misma CUENTA.
Atributos de relaciones
Sea R un conjunto de relaciones que involucran a los conjuntos de
entidades E1, E2, ...En y sea Ei los atributos que conforman a la clave
primaria de Ei, entonces los atributos de R son:
la clave primaria de E1,
la clave primaria de E2,
...
y
la clave primaria de En
es decir:
{E1, E2, ..., En}
R puede tener atributos descriptivos (adicionales), por lo que el
conjunto de atributos de la relación R sería:
{E1, E2, ..., En, a1, a2, ..., an}
E1=PRODUCTO
Nombre_producto
LAPIZ
GOMA
CHOCOLATE
CHAMOI
Clase
PAPELERIA
PAPELERIA
DULCERIA
DULCERIA
E2=PROVEEDOR
Clase
PAPELERIA
PAPELERIA
DULCERIA
DULCERIA
Nombre_proveedor
OFIMAX
LUMEN
EXPENDIO LUPITA
MAGO DE OZ
Teléfono
645 4523
234 5467
545 3421
534 6756
Por ejemplo, los atributos de la relación PEDIDO
Bases de Datos. Miguel Murguía. FAR.
23
PEDIDO
E1
E2
Nombre_producto
LAPIZ
CHOCOLATE
Nombre_proveedor
LUMEN
LUPITA
a1
Cantidad
100
20
Reglas de integridad
La interpretación del mundo real que se hace de una relación, lleva a considerar la
imposición de reglas de integridad. Es decir, hay cosas que el modelo teórico permite, pero
que no se dan en la realidad.
1: Integridad de la Entidad. Ningún valor de un componente de la llave primaria puede ser
nulo.
2: Integridad de Referencia. Sea D un dominio primario y R una relación con atributo A
que se define sobre D. Cada valor de A en R debe ser un valor de la llave
primaria de alguna relación con llave primaria sobre D.
Dominio Primario. Dominio para el que existe una llave primaria de un sólo
atributo.
Clave foránea. Atributo con las propiedades de A.
Extensión. Conjunto de tuplas que tiene una relación en un instante dado.
Comprensión. Esquema de la relación.
Por ejemplo, considerando los conjuntos de entidades PRODUCTO y PROVEEDOR de
la tabla 2.1:
E1 = PRODUCTO
E2 = PROVEEDOR
(E1)= NOMBRE_PRODUCTO
(E2)= NOMBRE_PROVEEDOR
a1 = CANTIDAD
Entonces, el conjunto de atributos de R es:
R= PEDIDO = {(E1), (E2), a1}
El conjunto de atributos de un conjunto R de relaciones es una superclave.
Bases de Datos. Miguel Murguía. FAR.
24
La clave primaria de un conjunto de relaciones depende de la cardinalidad de la asignación.
Relación normalizada. Relación en la que todo valor de cada atributo es atómico, no
compuesto por un conjunto de valores.
Diagramas E-R
Los elementos usados en los diagramas Entidad-Relación son:
Se puede indicar la cardinalidad gráficamente por:
Una a muchas
Muchas a una
Muchas a muchas
Una a una
←—⎯
⎯—→
⎯—⎯
←—→
Bases de Datos. Miguel Murguía. FAR.
25
De los diagramas E-R a Tablas
Cada conjunto de entidades y cada conjunto de relaciones se puede representar mediante
una tabla.
Conjunto fuerte de entidades. Cada atributo corresponde a una columna y cada entidad a un
renglón (tupla o fila).
Conjunto débil de entidades. Cada atributo se representa por una columna y se deben
añadir una columna por cada atributo de la clave primaria del conjunto de entidades fuerte
del que depende.
Conjuntos de relaciones. Una tabla con una columna por cada atributo.
EJERCICIOS
1. Defina un esquema para el control de un negocio.
2. Realiza un diagrama E-R. Utilice adecuadamente la simbología revisada en clase.
3. Indique algunos ejemplos de atributos que podrían definirse como entidades y viceversa,
de acuerdo a diferentes necesidades de control.
4. Ejemplifique: relaciones recursivas, atributos multivaluados y compuestos, restricciones
de participación total y parcial.
Bases de Datos. Miguel Murguía. FAR.
26
Dominios y Atributos
Atributo. Características de las entidades. Una entidad está representada por un conjunto de
atributos. Los atributos representan el uso de un dominio. Por ejemplo,
Nombre_alumno es una atributo del conjunto de entidades ALUMNO.
Dominio. Conjunto de valores permitidos para cada atributo. Por ejemplo, el dominio del
atributo calificación podría ser el conjunto de todos los reales entre 0 y 10.
Cada atributo simple de un tipo de entidad está asociado con un conjunto de valores o
dominio.
El atributo A de un tipo de entidad E cuyo conjunto de valores es V, puede definirse como
una función de E hacia el conjunto potencia de V:
A: E → P(V)
El conjunto potencia P(V) de un conjunto V es el conjunto de todos los subconjuntos de V.
Atributo derivado. Atributo que puede ser calculado a partir de otro almacenado. Por
ejemplo, la Edad puede derivarse del atributo Fecha_de_nacimiento.
Atributo almacenado. Atributo que se graba físicamente en los archivos y que puede servir
de base para calcular otros. Por ejemplo el atributo Sueldo puede servir para
calcular el Impuesto.
Atributo compuesto. Atributo que está formado por otros atributos. Por ejemplo,
Dirección puede componerse de Calle, Número, Colonia y Cp.
Atributo multivaluado. Atributo que puede adquirir más de un valor para una misma
entidad. Por ejemplo, el atributo Color de un coche puede tener hasta 3
valores.
Bases de Datos. Miguel Murguía. FAR.
27
Restricción en las relaciones
Cardinalidad de asignación. Número de entidades con las que puede asociarse otra entidad,
mediante un conjunto de relaciones.
Restricción de participación. Especifica si la existencia de una entidad depende de la de
otra via relación. Puede ser total o parcial.
Dependencia de existencia (participación total). Especifica que toda entidad está
relacionada a alguna(s) de la del otro conjunto. Por ejemplo, todo
MUNICIPIO pertenece a un ESTADO.
Participación parcial. Especifica que algunas entidades (pero no necesariamente
todas) están relacionadas a alguna(s) de la del otro conjunto. Por
ejemplo, algunos MUNICIPIOS tienen PUERTOS
Restricción estructural. Cardinalidad de asignación y restricciones de participación.
Restricción estructural
Restricción de participación
Cardinalidad
total
parcial
1:1
1:N
N:M
Bases de Datos. Miguel Murguía. FAR.
28
Relaciones (papeles y recursividad)
Papel. Una entidad que participa en una relación, desempeña un papel. El nombre del tipo
de la entidad no necesariamente es el mismo que el del papel (v.g. en las
relaciones recursivas).
Ejemplos de papeles que puede desempeñar un EMPLEADO
ENTIDAD
RELACION
ENTIDAD
EMPLEADO
PARTICIPACION
PROYECTO
Colaborador
EMPLEADO
DIRECCION
PROYECTO
SUPERVISION
EMPLEADO
Director
EMPLEADO
Supervisor
Supervisado
Relación recursiva. Relación en la que participan entidades del mismo conjunto (tipo). Una
entidad que participa en una relación recursiva puede tener dos papeles
distintos.
Bases de Datos. Miguel Murguía. FAR.
29
II El Modelo Relacional de Bases de Datos
1. Introducción al Modelo Relacional
Antecedentes y orígenes del Modelo Relacional
1969
Primera publicación de Codd sobre el modelo relacional
1970
Publicación de Codd que consolida al modelo relacional
1971
Codd publica sus 1NF, 2NF y 3NF
1970-1988 Codd publica varios artículos para consolidar el modelo
1976
Ronald Fagin inventa 4NF y 5NF
1976
Chen publica su modelo “Entidad-Relación”
1979
Codd presenta la versión extendida de su modelo
1990
Codd sintetiza su “segunda versión” que es un subconjunto
de su versión extendida
Bases de Datos. Miguel Murguía. FAR.
30
Conceptos del Modelo Relacional
Informalmente, en el modelo relacional una relación es una tabla. Cada
renglón de la tabla puede interpretarse como una colección de datos que
describen una entidad del mundo real.
Los nombres de las tablas y de las columnas se utilizan para ayudar a
interpretar el significado de cada valor. Por ejemplo, la tabla ALUMNO
contiene datos de los alumnos de la escuela y cada renglón representa una
entidad del mundo real. Los nombres de cada columna especifican cómo
interpretar los valores de cada renglón. Todos los valores de una columna son
del mismo tipo de dato.
En la terminología del modelo relacional, a cada renglón se le llama tupla, al
encabezado de cada columna atributo y a la tabla relación. El tipo de datos
que describe los tipos de valores que pueden aparecer en cada columna se la
llama dominio.
Dominio. Un dominio D es un conjunto de valores atómicos. Por atómico se
entiende que cada valor es indivisible. Por ejemplo, el dominio de
los números de cuenta es el conjunto de las cadenas de 6 dígitos; el
dominio de las calificaciones son los reales entre 0 y 10.
Relación. Una relación r de un esquema de relación R(A1, A2 ..., An), también
denotada por r(R), es un conjunto de n-tuplas r={t1, t2, ..., tm}. Cada
n-tupla t es una lista ordenada de valores <v1,v2, ...,vn> donde cada
valor vi 1 ≤ i ≤ n es un elemento del dominio dom(Ai) o es un valor
especial nulo.
Bases de Datos. Miguel Murguía. FAR.
31
Tuplas
Orden de las tuplas en una relación
El orden de las tuplas en una relación no es parte de la definición de la
relación, pues en teoría, una relación es un conjunto de tuplas y
matemáticamente, los elementos de un conjunto no están ordenados.
Figura. Las tuplas son elementos de un conjunto (colección no ordenada).
Aunque en la implementación física de una relación, los renglones si tiene un
orden, en el sentido de que se puede distinguir al primero y al segundo, etc. o
al sucesor y al predecesor, una relación intenta representar hechos en un nivel
abstracto o lógico.
En un archivo físico, una relación puede estar ordenada por diversos criterios,
por ejemplo, por los valores de un atributo; sin embargo, una relación
ordenada con dos criterios distintos sigue siendo la misma relación.
Figura. Un conjunto de tuplas es el mismo, aunque las tuplas se ordenen de
manera diferente.
Bases de Datos. Miguel Murguía. FAR.
32
Cuando una relación se concibe como una tabla:
• Cada renglón representa una tupla de R.
• El orden de los renglones no es importante
• Todos los renglones se distinguen de los demás por su contenido.
Renglones repetidos
Las tablas que tienen renglones repetidos no representan relaciones,
particularmente son llamadas relaciones corruptas o relaciones impropias.
Existen varias razones para no permitir tuplas repetidas:
• Reducen la optimización de los comandos relacionales.
• Generan problemas conceptuales severos al usuario así como
restricciones.
Además, una base de datos puede ser utilizada por cientos o miles de usuarios,
por lo que debe existir un significado común para todos los datos que accecen.
No existe una interpretación precisa, aceptada e independiente del contexto
para los renglones repetidos.
En general, cada tupla o renglón asociado al nombre de la relación a la que
pertenece implica una aseveración. Por ejemplo, cada renglón de la relación
ALUMNO es una aseveración de que una persona en específico es un alumno
de la escuela. Este hecho hace a las bases de datos relacionales compatibles
con las bases de conocimientos.
Bases de Datos. Miguel Murguía. FAR.
33
Orden de los valores en una tupla
De acuerdo a una de las definiciones de relación, una n-tupla es una lista
ordenada de n valores, por lo que el orden de los valores en la tupla si es
importante, y por lo tanto, también lo es el orden de los atributos en la
definición de un esquema de relación.
Adicionalmente, una tupla puede ser considerada como un conjunto de pares
(<atributo>,<valor>), donde cada par da el valor de mapeo de un atributo Ai
un valor vi del dom(Ai). Así las siguientes tuplas son idénticas:
t= <(Numero-cuenta, 950001), (Nombre-alumno, Oscar
Martínez), (Año-ingreso, 95), (Carrera,Biología)>
t= < (Nombre-alumno, Oscar Martínez), (Carrera,Biología),
(Numero-cuenta, 950001), (Año-ingreso, 95)>
Con esa concepción de tupla, el orden de los atributos dentro de ella no es
importante. De hecho, existen razones adicionales para nombrar, de manera
única, a las columnas:
• El nombre de las columnas dan al usuario una idea del significado de
los datos que almacena.
• Permite a los usuario no tener que recordar el orden de cada columna.
• De una manera de distinguir el significado de la columna del de su
dominio, pues una columna usa a un dominio.
Bases de Datos. Miguel Murguía. FAR.
34
Instancia de la base de datos con
esquema ESCUELA
ALUMNO
Numerocuenta
950001
950002
970001
970002
950003
950004
950005
970003
970004
970005
Nombre-alumno
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel Valderrama
Ma. Elena Cañedo
Carmen Díaz
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
MATERIA
Clave-materia
01002
01003
02001
02002
03001
03002
02003
EXAMEN
Numerocuenta
950001
950005
970002
970005
Nombre-materia
Algebra
Cálculo
Estadística
Botánica
Física relativista
Partículas
elementales
Bioquímica
Clavemateria
02002
03001
01002
03002
AñoCarrera
ingreso
95 Biología
95 Biología
97 Biología
97 Matemáticas
95 Matemáticas
95 Biología
95 Física
97 Biología
97 Matemáticas
97 Física
Nivel Créditos Carrera
2
7 Matemáticas
1
10 Matemáticas
1
5 Biología
3
8 Biología
4
10 Física
3
9 Física
2
12 Biología
Orden-de-pago Fechaexamen
3567
6/2/97
3678
4/2/97
3676
5/6/97
3789
3/6/97
Bases de Datos. Miguel Murguía. FAR.
35
HISTORIA
Numero-cuenta
950001
950002
950002
950004
950004
970003
970003
Clave-materia Semestre-curso Calificacion
02001
96
8.2
02001
96
9
02003
96
7
02002
96
9
02003
95
10
02002
95
8
02003
96
9
Diagrama E-R para una escuela
Bases de Datos. Miguel Murguía. FAR.
36
Otra definición de relación
Si se considera a la tabla ALUMNO, se puede observar que tiene los atributos
Numero-cuenta, Nombre-alumno, Año-ingreso y Carrera.
Para cada atributo existe un conjunto de posibles valores: su dominio. Por
ejemplo, el dominio del atributo Carrera son todos los nombres de las
carreras que se imparten en la escuela.
Así, podemos definir los dominios D1, D2 D3 y D4, donde D1 es el conjunto
de todos los números de cuenta, D2 de todos los nombres posibles de alumnos,
D3 todos los años y D4 todas las carreras.
Cada uno de los renglones de la tabla ALUMNO consta de cuatro valores (v1,
v2, v3, v4), donde v1 es el número de cuenta, v2 el nombre del alumno, v3 el
año de ingreso y v4 la carrera. Por lo anterior, la tabla ALUMNO es un
subconjunto de:
D1 x D2 x D3 x D4
Desde el punto de vista matemático, una relación se define como un
subconjunto del producto cartesiano de una lista de dominios.
En la terminología matemática, los términos de relación y tupla son análogos
a los de tabla y fila en el Modelo Relacional..
La relación ALUMNO tiene 10 tuplas. Sea t la primera tupla de la relación, se
usará la notación t[Nombre-del-atributo] para indicar el valor de ese atributo
en la tupla, así t[Nombre-alumno]=“Oscar Martínez”, t[Año-ingreso]=95.
Es necesario que todos los dominios de todos los atributos de todas las
relaciones sean atómicos, es decir, que los valores sean unidades indivisibles.
Bases de Datos. Miguel Murguía. FAR.
37
Esquemas de relaciones
Esquema de una relación. El esquema de una relación es la estructura de
atributos que contiene, por ejemplo, el esquema de la relación
ALUMNO es (Numero-cuenta, Nombre-alumno, Año-ingreso,
Carrera).
En general, se usará la notación esquema-alumno para referirse al esquema
de la relación alumno, así:
esquema-alumno=(Numero-cuenta, Nombre-alumno, Año-ingreso,
Carrera)
También, se indicará que una relación se construye sobre un esquema
mediante:
nombre-de-la-relacion(nombre-del-esquema)
Así, si se quiere indicar que la relación ALUMNO tiene el esquema esquemaalumno se escribe:
alumno (esquema_alumno)
El esquema de la relación EXAMEN es
esquema-examen = (Numero-cuenta, Clave-materia, Orden-de-pago, Fechaexamen)
El hecho de que pueda aparecer el mismo atributo en diferentes relaciones
permite relacionar a las tuplas entre esas relaciones.
Para la explicación de los conceptos sobre el modelo relacional se utilizarán
como ejemplo el conjunto de relaciones ESCUELA, derivadas de la figura.
Así, se tienen las relaciones ALUMNO, MATERIA, HISTORIA y EXAMEN.
Sus esquemas son:
Bases de Datos. Miguel Murguía. FAR.
38
esquema-alumno = (Numero-cuenta, Nombre-alumno, Año-ingreso,
Carrera)
esquema-materia = (Clave-materia, Nombre-materia, nivel, Créditos,
Carrera)
esquema-examen = (Numero-cuenta, Clave-materia, Orden-de-pago,
Fecha-examen)
esquema-historia = (Numero-cuenta, Clave-materia, Semestre-curso,
Calificación)
con claves primarias:
Numero-cuenta
Clave-materia
Numero-cuenta, Clave-materia
Numero-cuenta, Clave-materia
respectivamente.
Bases de Datos. Miguel Murguía. FAR.
39
Esquema de una Base de Datos
Esquema de una base de datos relacional. El esquema de una base de datos
relacional es el conjunto de esquemas de relaciones
S={ R1, R2, ..., Rm } y un conjunto de restricciones de integridad RI.
Por ejemplo, el esquema de la base de datos ESCUELA es:
ALUMNO
Numero-cuenta Nombre-alumno
Año-ingreso
MATERIA
Clave-materia
Nivel
Nombre-materia
Carrera
Créditos Carrera
EXAMEN
Numero-cuenta
Clave-materia Orden-de-pago
HISTORIA
Numero-cuenta
Clave-materia Semestre-curso Calificacion
Fecha-examen
Bases de datos ricas. Bases de datos relacionales con muchas relaciones
y generalmente pocas tuplas.
Bases de datos extensas. Bases de datos relacionales con pocas
relaciones y generalmente muchas tuplas.
Por ejemplo, las bases de conocimiento son ricas, mientras que la mayoría de
las comerciales son extensas.
Bases de Datos. Miguel Murguía. FAR.
40
Notación
Se utilizará la siguiente notación para describir al modelo relacional:
• Un esquema de relación de grado n se denota por R(A1, A2 ..., An).
• Una n-tupla ten una relación r(R) se denota por t= <v1,v2, ...,vn donde
vi es el valor correspondiente al atributo Ai.
• t[Ai] se refiere al valor vi en t para el atributo Ai.
• t[Au,Aw, ..., Az] donde Au, Aw, ...,Az es una lista de atributos de R, se
refiere a la subtupla de valores <vu,vw, ...,vz> de t correspondientes a
los atributos especificados en la lista.
• Las letras Q, R y S denotan nombres de relaciones.
• Las letras q, r, s denotan instancias de relaciones.
• Las letras t, u, v denotan tuplas.
• En general, el nombre de una relación, como por ejemplo
ALUMNO, indica el conjunto actual de tuplas en esa relación
(estado actual de la relación o instancia), mientras que
ALUMNO(Numero-de-cuenta, Nombre-alumno, ...) se refiere al
esquema.
Bases de Datos. Miguel Murguía. FAR.
41
2. Principales características del Modelo Relacional
Restricciones del Modelo Relacional
El Modelo Relacional contempla la imposición de restricciones que se asocian
a un esquema, algunas de ellas son:
•
•
•
•
Integridad de Dominio
Integridad de Claves
Integridad de la Entidad
Integridad Referencial
A continuación se explica cada tipo:
Integridad de Dominio. Todo valor del atributo A debe ser un valor
atómico que pertenece al dominio dom(A) de ese atributo.
Integridad de Claves. No pueden existir un par de tuplas que tengan los
mismos valores en cada uno de sus atributos.
Integridad de la Entidad. Ningún valor de un componente de la llave
primaria puede ser nulo.
Dominio Primario. Dominio para el que existe una llave primaria de un
sólo atributo.
Integridad de Referencia. Sea D un dominio primario y R una relación
con atributo A que se define sobre D. Cada valor de A en R
debe ser un valor de la llave primaria de alguna relación con
llave primaria sobre D.
Las restricciones de integridad de referencia pueden expresarse mediante
flechas sobre el esquema de la base de datos, que conectan a atributos entre los
esquemas de las relaciones.
Bases de Datos. Miguel Murguía. FAR.
42
Relación: el único tipo de dato compuesto
En el modelo relacional todas las operaciones se realizan sobre relaciones y
como resultado producen relaciones.
El único tipo de dato compuesto en el modelo relacional es la relación, pues
los valores de los dominios en cada relación deben ser atómicos
La razón por la que el modelo relacional permite sólo un tipo de dato
compuesto es que los datos compuestos agregan complejidad sin agregar
poder.
Por ejemplo, las cuatro operaciones básicas de un lenguaje de manipulación de
datos (DML) son:
retrieve
insert
update
delete
Si existieran n tipos de datos compuestos, entonces se requerirían 4n
comandos para cubrir las operaciones básicas.
En general, en los modelos de bases de datos relacionales hay una tendencia a
crear cada vez más y más tipos de datos compuestos y con ella se complican
más los lenguajes de manipulación de datos, haciéndolos más difíciles de usar
o programar.
Bases de Datos. Miguel Murguía. FAR.
43
Críticas al modelo Entidad-Relación
El modelo Entidad Relación fué propuesto posteriormente al Modelo
Relacional. Codd, en su segunda versión del Modelo Relacional, critica al
modelo ER diciendo:
• Sólo se describen aspectos de la estructura, no de las operaciones sobre
estas estructuras ni de restricciones de integridad. Por lo tanto no es un
modelo de datos.
• La distinción de entidades y relaciones no ha sido definida con
precisión, como consecuencia, una entidad persona es otra relación
persona.
• Aún si esta distinción se puede definir, añadiría complejidad sin añadir
poder.
Bases de Datos. Miguel Murguía. FAR.
44
Evolución del Modelo Relacional
Aceptación
Las nuevas versiones del Modelo Relacional son más proscriptivas, es decir,
se imponen más restricciones. Estas imposiciones permitirán, dice Codd,
avanzar de un estado primitivo a uno básico. Lo analoga a la discusión en
programación en la que Dijkstra rechazaba el uso del comando GO TO.
La versión modificada “Tasmania” del modelo de Codd incorpora nuevas
características que dan potencia adicional a su primera versión, sin embargo,
se ha integrado parcialmente en una segunda versión con la finalidad de dar
oportunidad a los desarrolladores de asimilar estas adiciones.
Nuevas características
La segunda versión incorpora más aspectos sobre la semántica. Por ejemplo,
se hace una distinción explícita entre los conceptos columna y dominio y hace
una distinción entre los tipos de datos básicos y los extendidos. Además, se da
una descripción, semántica, de las características de un lenguaje relacional.
Aunque en la versión original ya se habían definido tres valores de verdad,
TRUE, FALSE, MAYBE, se extienden a 4:
TRUE,
FALSE,
MAYBE BUT APPLICABLE y
MAYBE BUT INAPPLICABLE.
MAYBE BUT APPLICABLE hace referencia a valores que no se han
introducido a la base de datos, mientras que MAYBE BUT INAPPLICABLE
hace referencia a valores que no se encuentran debido a que la propiedad es
inaplicable al objeto.
Bases de Datos. Miguel Murguía. FAR.
45
Diferencias entre las Matemáticas y en el Modelo Relacional del
concepto de relación y terminología
Matemáticas
Modelo Relacional
Concepto de relación
Valores sin restricciones
Valores atómicos
Columnas sin nombres
Cada columna tiene un nombre
Las columnas se diferencian por Las columnas se diferencian por
posición
nombre y dominio
Constantes
Varían en el tiempo
Terminología
Relación de grado n
Tabla-R con n columnas
Atributo
Columna de tabla-R
Dominio
Tipo de dato
Tupla
Renglón de tabla-R
Cardinalidad de relación
Número de renglones en una tabla-R
Bases de Datos. Miguel Murguía. FAR.
46
Objetivos del Modelo Relacional
• Simplificar la interacción de los usuarios con los datos:
para bases de datos extensas,
que no están familiarizados con la programación,
que conciben las interacciones independientemente de los demás
usuarios.
• Incrementar la productividad de los usuarios que son programadores
profesionales
• Soportar herramientas más poderosas para el administrador de la base
de datos, para controlar el acceso de los usuarios a la información: quién
accesa qué información y para qué propósito, así como para controlar la
integridad de la base de datos.
Interrelación de información entre relaciones distintas
Comparación de valores vs. apuntadores
En el modelo relacional las relaciones no se asocian mediante ligas explícitas
o apuntadores, como se hace en modelos anteriores. El principio fundamental
del modelo relacional es que la interrelación se realiza mediante comparación
de valores. Dos valores se pueden compara sólo si pertenecen al mismo
dominio.
Aparentemente, la restricción de que los valores a comparar sean del mismo
dominio se ve innecesaria, pero en realidad es una manera de proteger al
usuario de cometer errores cuando los operadores de relaciones incorporan
esta restricción.
Bases de Datos. Miguel Murguía. FAR.
47
Transacción
Una transacción es un conjunto de actividades que involucran cambios en la
base de datos. Cada una se debe ejecutar si se desea realizar cambios
permanentes a la base de datos, y no se debe ejecutar ninguna si alguna de
ellas falla.
La colección de actividades está representada por una secuencia de comandos
relacionales, en donde se marca el inicio de la transacción y el fin de ella, el
final es un comando que realiza físicamente los cambios (COMIT).
Por ejemplo, la transacción para transferir $1000.00 de una cuenta de cheques
a una de ahorro debe de:
•
•
•
•
verificar que exista dinero disponible en la cuenta de cheques,
restar $1000.00 a la cuenta de cheques,
verificar que exista la cuenta de ahorro y
aumentar en $1000.00 a la cuenta de ahorro.
Cada una de las actividades anteriores, se debe poder realizar con éxito para
poder ejecutar la transacción, basta con que alguna de ellas falle, para que no
se realice la transacción.
Existen dos estrategias para el manejo de transacciones:
1) Almacenar cada resultado de la transacción en una copia temporal, y
utilizarla después de que se verificó cada una de las acciones para
actualizar la base de datos.
2) Almacenar la descripción de cada acción de la transacción en un
archivo log para tener una manera de “revertir” las acciones en el
momento de que una falle.
Bases de Datos. Miguel Murguía. FAR.
48
SQL (Structured Query Language)
• SQL es un lenguaje relacional de datos creado por IBM en 1972.
• Está basado en los principios del Modelo Relacional.
• No incluye todas las características del modelo.
• Algunas de las características están implementadas de manera
incorrecta.
Uno de los errores de implementación del SQL es que permite la existencia de
renglones duplicados, esto tiene repercusiones serias en la base de datos. De
hecho, SQL no soporta más de la mitad del modelo relacional.
Aunque se han desarrollado otros lenguajes relacionales, se ha prestado más
atención al SQL debido a que se ha adoptado como un estándar ANSI, además
de que muchos DBMS lo soportan.
Bases de Datos. Miguel Murguía. FAR.
49
DBMS relacionales
Se suele hablar mucho sobre la condición “relacional” de un producto DBMS.
Por ejemplo, los vendedores alegan que su producto” es relacional”.
El que un DBMS sea relacional no solo implica que pueda manipular datos
relacionándolos mediante claves primarias y claves foráneas, implica de
hecho que cumpla con “todas” las características del modelo relacional.
Al respecto hay una regla cero que dice:
“Todo sistema del que se diga que es ´relacional’ debe tener la
capacidad de manejar bases de datos totalmente de manera
relacional, no importando si brinda capacidades adicionales.”
Es decir, si un producto provee de capacidades adicionales o novedosas, es
relacional sólo si manipula los datos de acuerdo al modelo relacional.
Para evaluar un producto DBMS se debe de observar la fidelidad al modelo
relacional, por lo que debe de soportar las operaciones de insert, update y
delete en un plano relacional.
Como otra consecuencia, un DBMS “relacional”, debe de poder manipular
relaciones con cualquier número de tuplas, incluyendo una o cero tuplas, es
decir, se deben de poder aplicar las operaciones insert, update y delete a
relaciones con cero o una tuplas, sin tratamiento especial, ya que el modelo
relacional no marca casos especiales para ello.
Bases de Datos. Miguel Murguía. FAR.
50
La relación universal
En 1988 surgió la propuesta de utilizar una sola relación para las bases de
datos: la “relación universal”. La relación universal es un join (equi-join) de
todas las tablas-R, basada en las claves.
La idea de la relación universal se generó quizá, por la necesidad de no
realizar operaciones join.
El DBMS no debe tratar a la base de datos como una sola relación universal
aunque sí debe poder generarla como una de las posibles vistas.
Algunas de las desventajas del enfoque de la relación universal son:
Pérdida de espacio
La relación universal desperdicia mucho espacio de almacenamiento debido,
principalmente, a los valores “inaplicable”.
Dependencia de datos
Se ve involucrado de manera mayor aspectos de almacenamiento físico, por lo
que al modificar el esquema físico afectará al lógico.
Dependencia lógica
Al modificar el esquema, es muy probable que se requieran modificar los
programas de aplicación.
Sólo un tipo de join
Una de las ventajas del modelo relacional respecto a la relación universal es
que permite join de varios tipos, y no sólo equi-join basada en claves.
Dificultad para modificar el esquema
Cuando se desea agregar información a la base de datos, por ejemplo, agregar
una columna, es muy complicado hacerlo con el esquema de la relación
universal. Mientras que con el enfoque relacional, se puede agregar fácilmente
o incluso, crear nuevas tablas-R.
Bases de Datos. Miguel Murguía. FAR.
51
Razones para soportar dominios
Una de las deficiencias más serias de los DBMS es que no tienen un soporte
adecuado de dominios. Si un DBMS no soporta dominios, tampoco podrá
soportar otras características importantes del modelo.
1) Los dominios son el elemento fundamental que hace que una base de
datos tenga unidad
Si dos relaciones no comparten ningún dominio, no pueden relacionarse. Una
base de datos, concebida como un conjunto de relaciones CR y otro de
dominios CD, puede dividirse en dos bases de datos sin pérdida de
información, si no comparten ningún dominio, formalmente:
Si
CR es un conjunto de relaciones;
CD un conjunto de dominios;
cr ⊂ CR;
cd ⊂ CD
y
1) las relaciones en cr utilizan sólo los dominios en cd
2) las relaciones en CR-cr utilizan sólo los dominios en CD-cd
Entonces:
la base de datos se puede dividir en dos (CR-cr, CD-cd) y (cr, cd) sin
pérdida de información.
Además, los dominios permiten detectar las comparaciones que tienen sentido
y las que no lo tienen.
2) Son necesarios para declarar el tipo de dato permitido en cada
columna
En el diccionario de datos se debe almacenar una descripción extensa del tipo
de dato almacenado. Sin el soporte del dominio, esta descripción debe
repetirse para cuanta columna tenga el mismo tipo de dato.
3) Son necesarios para soportar integridad de dominio
Bases de Datos. Miguel Murguía. FAR.
52
La integridad de dominio se refiere a la restricción de que todos los valores de
una columna pertenezcan al dominio que se asoció a esa columna. Algunos
tipos de restricciones de dominio son: a) tipo de datos regulares; b) intervalo
de valores permitido; c) aplicabilidad de la función sucesor o predecesor
(operadores > y <).
4) Permiten restringir la aplicabilidad de operadores
Para cada comparación entre valores, el DBMS debe verificar que esos valores
sean semánticamente comparables. Si un usuario necesita comparar “peras con
manzanas”, entonces el DBA deberá dar autorización, pero sólo por un
periodo corto de tiempo, para que deshabilite, por ejemplo, el DOMAIN
CHECK.
5) Permiten especificar de forma implícita las columnas en las que se
buscará un valor
Los dominios permiten especificar un grupo de columnas de manera implícita,
lo que facilita las consultas. Por ejemplo, si se desea buscar todos los registros
en los que esté involucrada una cierta persona, no importando el papel que
desempeñe en la relación, se puede indicar que busque sobre un dominio y no
sobre columnas específicas. Actualmente, SQL no soporta esta característica.
6) Facilitan algunas restricciones de integridad definidas por el usuario
Por ejemplo, si se requiere que los valores de una columna C1 sean un
subconjunto de los valores contenidos en la columna C2, entonces C1 y C2
deben tomar valores de un mismo dominio.
7) El concepto de dominio participa en muchas definiciones del modelo
relacional
Incluyendo las definiciones de dominio primario, llave foránea, integridad de
dominio, integridad referencial, entre otras.
8) Son necesarios para realizar las operaciones de UNION o similares
Bases de Datos. Miguel Murguía. FAR.
53
Cuando se realiza una UNION de S con R, es necesario que ambas tablas
tengan el mismo número de columnas, pero además, que exista un “mapeo”
uno a uno entre las columnas de R y S, debiendo tener cada par el mismo
dominio. Si todas las columnas de R tiene un dominio diferente, entonces el
DBMS deberá saber hacer el mapeo de las columnas entre R y S, dejando
menos trabajo al usuario.
9) Permiten la generación de los “índices basados en dominios”
Los índices basados en dominios”, aunque no son parte del modelo relacional,
son una herramienta que aumenta el desempeño del DBMS. Indican, para cada
columna, de qué dominio extraen sus valores, permiten encontrar todas las
ocurrencias de un valor.
Recuerde que …
• Toda relación es un conjunto.
• No todo conjunto es una relación.
• Toda relación puede concebirse como una tabla.
• No toda tabla es una representación correcta de una relación.
Bases de Datos. Miguel Murguía. FAR.
54
III Álgebra Relacional
1. Operadores básicos del Álgebra Relacional
Introducción
Lenguaje formal
El álgebra relacional es un leguaje “puro” de procedimiento, es decir, es un
lenguaje definido formalmente del que se pueden hacer diversos tipos de
implementaciones.
Las operaciones son cerradas
Las operaciones del álgebra relacional involucran como operandos a una o dos
relaciones y siempre devuelven como resultado otra relación, es decir son
“cerradas”. Manejar bases de datos con lenguajes que no respeten la
“cerradura” es casi imposible.
La propiedad de “cerradura” del álgebra relacional facilita el uso del lenguaje,
pues en una misma expresión se pueden contatenar los resultados de las
operaciones haciéndolos participar como operandos de otras operaciones.
Lenguaje flexible y potente
Los operadores relacionales permiten a los usuarios consultar información de
una base de datos de una manera flexible y potente, pero sin necesidad de que
tenga conocimientos de programación.
Diseñado para trabajar con tablas-R
Cada operador relacional del modelo relacional está diseñado para trabajar
sobre relaciones que no tienen renglones duplicados y para generar relaciones
sin renglones duplicados.
Bases de Datos. Miguel Murguía. FAR.
55
Los operadores
Clasificación de los operadores
Para su estudio los operadores se dividen en tres grupos:
• Operadores básicos
• Operadores de manipulación
• Operadores avanzados
Cuatro operadores provienen directamente de la teoría de conjuntos, aplicables
a las relaciones porque las relaciones se definen como un conjunto de tuplas,
ellos son:
•
•
•
•
unión,
intersección,
diferencia y
producto cartesiano
Los demás operadores se desarrollan específicamente para el álgebra
relacional.
Operadores básicos
• proyección
• theta-selección
• theta-selección extendido
• producto cartesiano*
• unión
• diferencia
• intersección
• producto natural*
• theta-join
• theta-join extendido
• natural-join
• división
*Estos operadores ya no se consideran indispensables en la segunda versión.
Bases de Datos. Miguel Murguía. FAR.
56
Operadores de manipulación
• asignación relacional
• insert
• update
• delete
Operadores avanzados
• framing
• extend
• semi-join
• outer-join
• outer-union
• outer-difference
• outer-intersección
• T-joins
• user-defined-selects
• user-defined-joins
• recursive-join
Bases de Datos. Miguel Murguía. FAR.
57
Proyección
Π
R[a1, a2, ...]
SELECT a1, a2,... FROM R;
Es un operador unario que omite algunas columnas, eliminando los renglones
repetidos que se pudieran generar.
En la notación de cálculo de predicados, la proyección de las columnas
Nombre_alumno y Carrera de la tabla ALUMNO se escribe:
Πnombre-alumno, carrera (alumno)
En notación algebraica:
Z ← ALUMNO [Nombre_alumno, Carrera]
En SQL:
SELECT nombre_alumno, carrera FROM Alumno;
El resultado:
Nombre-alumno
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel Valderrama
Ma.Elena Cañedo
Carmen Díaz
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
Carrera
Biología
Biología
Biología
Matemática
s
Matemática
s
Biología
Física
Biología
Matemática
s
Física
Bases de Datos. Miguel Murguía. FAR.
58
Se puede explicar al operador de proyección en dos etapas, en la primera se
genera una tabla (que no es una tabla-R) con las columnas que formarán parte
del resultado, y en la segunda etapa se eliminan los renglones repetidos. Por
ejemplo, si se desea obtener una lista de las carreras:
Π carrera (alumno)
o en notación algebraica:
Z ← ALUMNO [Carrera]
Primero se genera una tabla con la columna Carrera, pero con renglones
repetidos:
Carrera
Biología
Biología
Biología
Matemática
s
Matemática
s
Biología
Física
Biología
Matemática
s
Física
Después se genera la tabla-R resultado, eliminando los renglones repetidos:
Carrera
Biología
Matemática
s
Física
SQL no elimina renglones repetidos, a menos de que explícitamente se incluya
el comando DISTINCT.
En SQL:
SELECT DISTINCT carrera FROM Alumno;
Bases de Datos. Miguel Murguía. FAR.
59
Theta-Selección
σ
R[a=cte]
SELECT a1, a2,... FROM R WHERE a1=cte;
La selección es un operador unario. Selecciona tuplas que satisfacen un
predicado. Por ejemplo, si se desea obtener los registros dela tabla ALUMNO
que cursan la carrera de Matemáticas, se debe cumplir la condición
Carrera=“Matemáticas”.
En notación de predicados:
σcarrera=“Matemáticas” (alumno)
En notación algebraica:
Z ← ALUMNO [Carrera=“Matemáticas”]
El resultado:
Numerocuenta
970002
950003
970004
Nombrealumno
Isabel
Valderrama
Ma.Elena
Cañedo
José Malo
Añoingreso
Carrera
97 Matemática
s
95 Matemática
s
97 Matemática
s
En SQL:
SELECT * FROM Alumno WHERE carrera=“Matemáticas”
Otro ejemplo, “los alumnos de la generación 97”:
σaño-ingreso=97 (alumno)
En notación algebraica:
Bases de Datos. Miguel Murguía. FAR.
60
Z ← ALUMNO [Año_ingreso=97]
El resultado:
Numerocuenta
970001
970002
970003
970004
970005
NombreAñoalumno
ingreso
Emilio Vera
Isabel
Valderrama
Miguel Romero
José Malo
Salvador
Pascual
Carrera
97 Biología
97 Matemátic
as
97 Biología
97 Matemátic
as
97 Física
En SQL:
SELECT * FROM Alumno WHERE año_ingreso=97
Bases de Datos. Miguel Murguía. FAR.
61
Combinando selección y proyección
Ahora podemos combinar los operadores selección y proyección. Por ejemplo,
se pueden obtener los nombres de los alumnos que cursan la carrera de
Matemáticas:
Πnombre-alumno (σ carrera=“Matemáticas” (alumno))
ó
Z ← (ALUMNO [Carrera=“Matemáticas”]) [Nombre_alumno]
El resultado:
Nombre-alumno
Isabel
Valderrama
Ma.Elena Cañedo
José Malo
En SQL:
SELECT DISTINCT nombre_alumno
FROM Alumno
WHERE carrera=“Matemáticas”
La selección produce un resultado con el mismo esquema de relación que su
operando, mientras que la proyección si modifica el esquema, regresando
como resultado una relación con menor número de columnas.
Ambos operadores pueden regresar una relación resultado con cardinalidad
menor a la del operando, pues en la selección es uno de sus objetivos y en la
proyección debido a la eliminación de renglones repetidos.
Bases de Datos. Miguel Murguía. FAR.
62
Select y Theta-Select
Normalmente, si se omite el prefijo “theta” al operador theta-select se
sobrentiende que la selección se realiza mediante una igualdad (“=“), por
ejemplo:
Z ← ALUMNO [Carrera=“Matemáticas”]
pero theta-select puede realizarse utilizando otros operadores, donde theta
puede ser alguno de los siguientes comparadores:
1. EQUALITY
2. INEQUALITY
3. LESS THAN
4. LESS THAN OR EQUAL TO
5. GREATHER THAN
6. GREATHER THAN OR EQUAL TO
7. GREATEST LESS THAN
8. GREATEST LESS THAN OR EQUAL TO
9. LEAST GREATER THAN
10. LEAST GREATER THAN OR EQUAL TO
Por ejemplo, se pueden buscar las materias que tengan asignados 10 ó más
créditos. Así, se utiliza una theta-selección en donde la theta es GREATHER
THAN OR EQUAL TO (>=).
En notación de predicados:
σ créditos>=10 (materia)
ó
Z ← MATERIA [Créditos >=10]
El resultado:
Clavemateria
01003
03001
02003
Nombre-materia Nivel
Cálculo
Física relativista
Bioquímica
Bases de Datos. Miguel Murguía. FAR.
Créditos
1
4
2
10
10
12
63
En SQL:
SELECT * FROM Materia WHERE créditos>=10
En la selección también pueden realizarse comparaciones entre columnas, lo
cual significa que se deben comparar los valores de esos atributos en cada
registro. Es decir, se pueden construir expresiones del estilo:
σ atributo1=atributo2 (alumno)
Por ejemplo, suponiendo la existencia de una relación RESUMEN que
contiene los totales de alumnos acreditados y no acreditados en cada materia:
Z ← RESUMEN [Aprobados >= Reprobados]
En SQL:
SELECT * FROM Materia WHERE aprobados >= reprobados
En este caso, el DBMS debe verificar que los dominios de ambas columnas
sean los mismos.
En el caso de que en la comparación intervengan valores calculados se deberá
verificar que ambos sean del mismo tipo de dato básico.
Bases de Datos. Miguel Murguía. FAR.
64
Theta-selección extendido
Si
@ denota cualquiera de los 10 “comparadores” revisados anteriormente,
A y B son columnas de la relación R y
x una variable del lenguaje o una constante
entonces
R[A @ x] y R[A @ B] pueden ser operaciones theta-selección válidas y
también pueden considerarse como “términos de comparación” si
ambos
se conectan mediante un OR, NOT, AND ó IMPLIES.
Por ejemplo, la pregunta “los alumnos de Matemáticas de la generación 97”
puede expresarse utilizando theta-selección extendida:
σcarrera=“Matemáticas” ^ año-ingreso=97 (alumno)
o bien:
Z ← ALUMNO [Carrera=“Matemáticas” ^ Año_ingreso=97]
El resultado:
Numerocuenta
970002
970004
Nombrealumno
Isabel
Valderrama
José Malo
Añoingreso
Carrera
97 Matemáticas
97 Matemáticas
En SQL:
SELECT *
FROM Alumno
WHERE carrera = “Matemáticas” AND año_ingreso=97
Esa pregunta también puede expresarse en términos de theta-selección (no
extendida):
σcarrera=“Matemáticas” (σ año-ingreso=97 (alumno))
ó
Bases de Datos. Miguel Murguía. FAR.
65
Z ← (ALUMNO [Carrera=“Matemáticas” ]) [Año_ingreso=97]
Producto cartesiano
x
Los operadores de selección y proyección actúan sobre una relación, es decir,
son unarios. Un operador que permite combinar información de dos relaciones
-binario- es el producto cartesiano.
Por ejemplo, si se quiere encontrar a los registros de los alumnos que han
cursado la materia “Bioquímica” así como su número de cuenta, se debe
extraer información de las tablas alumno y materia.
La relación resultado de un producto cartesiano tiene por esquema a la unión
de los atributos de las relaciones que se están operando. Así, la relación
r=alumno x materia tiene el esquema:
esquema-r(número-cuenta, nombre-alumno, año-ingreso, carrera, clavemateria, nombre-materia, nivel, créditos)
Si existen atributos con el mismo nombre en ambas tablas, se antepone como
prefijo el nombre de la relación para distinguir a cada uno, por ejemplo, para
distinguir el atributo número-cuenta de la tabla alumno y de la tabla examen,
se escribe:
alumno.número-cuenta
examen.número-cuenta
Lo anterior funciona sólo si los nombres de las relaciones son distintos. En el
caso de los nombres de las relaciones involucradas sean iguales, entonces, se
agregará un número subfijo, por ejemplo:
alumno1.número-cuenta
alumno2.número-cuenta
El operador producto cartesiano puede ser útil para responder la pregunta
“encontrar las tuplas de los alumnos que hayan presentado un examen”:
Bases de Datos. Miguel Murguía. FAR.
66
σ alumno.numero-cuenta=examen.numero.cuenta(alumno x examen)
ó
Z ← (ALUMNO x EXAMEN)
[ALUMNO.Número_cuenta=EXAMEN.Número_cuenta]
Bases de Datos. Miguel Murguía. FAR.
67
Alumno.
Numero-cuenta
950001
950002
970001
970002
950003
950004
950005
970003
970004
970005
950001
950002
970001
970002
950003
950004
950005
970003
970004
970005
950001
950002
970001
970002
950003
950004
Nombre-alumno Año-ingreso
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel
Ma.Elena
Camen Díaz
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel
Ma.Elena
Camen Díaz
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel
Ma.Elena
Camen Díaz
Carrera
95
95
97
97
95
95
95
97
97
97
95
95
97
97
95
95
95
97
97
97
95
95
97
97
95
95
Biología
Biología
Biología
Matemáticas
Matemáticas
Biología
Física
Biología
Matemáticas
Física
Biología
Biología
Biología
Matemáticas
Matemáticas
Biología
Física
Biología
Matemáticas
Física
Biología
Biología
Biología
Matemáticas
Matemáticas
Biología
Examen.
Numero-cuenta
950001
950001
950001
950001
950001
950001
950001
950001
950001
950001
950005
950005
950005
950005
950005
950005
950005
950005
950005
950005
970002
970002
970002
970002
970002
970002
Clavemateria
02002
02002
02002
02002
02002
02002
02002
02002
02002
02002
03001
03001
03001
03001
03001
03001
03001
03001
03001
03001
01002
01002
01002
01002
01002
01002
Orden-de-pago Fecha-examen
3567
3567
3567
3567
3567
3567
3567
3567
3567
3567
3678
3678
3678
3678
3678
3678
3678
3678
3678
3678
3676
3676
3676
3676
3676
3676
Resultado de alumno x examen
continúa...
Bases de Datos. Miguel Murguía. FAR.
68
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Jun-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
02-Apr-97
06-May-97
06-May-97
06-May-97
06-May-97
06-May-97
06-May-97
...continuación
Alumno.
Numero-cuenta
950005
970003
970004
970005
950001
950002
970001
970002
950003
950004
950005
970003
970004
970005
Nombre-alumno Año-ingreso
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
Oscar Martínez
Mario Sánchez
Emilio Vera
Isabel
Ma.Elena
Camen Díaz
Jorge Soto
Miguel Romero
José Malo
Salvador Pascual
Carrera
95
97
97
97
95
95
97
97
95
95
95
97
97
97
Física
Biología
Matemáticas
Física
Biología
Biología
Biología
Matemáticas
Matemáticas
Biología
Física
Biología
Matemáticas
Física
Examen.
Numero-cuenta
970002
970002
970002
970002
970005
970005
970005
970005
970005
970005
970005
970005
970005
970005
Clavemateria
01002
01002
01002
01002
03002
03002
03002
03002
03002
03002
03002
03002
03002
03002
Orden-de-pago Fecha-examen
Examen.
Numero-cuenta
950001
950005
970002
970005
Clavemateria
02002
03001
01002
03002
Orden-de-pago Fecha-examen
3676
3676
3676
3676
3789
3789
3789
3789
3789
3789
3789
3789
3789
3789
06-May-97
06-May-97
06-May-97
06-May-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
06-Mar-97
Resultado de alumno x examen
Alumno.
Numero-cuenta
950001
950005
970002
970005
Nombre-alumno Año-ingreso
Oscar Martínez
Jorge Soto
Isabel
Salvador
Carrera
95
95
97
97
Biología
Física
Matemáticas
Física
3567
3678
3676
3789
02-Jun-97
02-Apr-97
06-May-97
06-Mar-97
Resultado de:
σ alumno.numero-cuenta=examen.numero.cuenta(alumno x examen)
Z ← (ALUMNO x EXAMEN) [ALUMNO.Número_cuenta=EXAMEN.Número_cuenta]
Bases de Datos. Miguel Murguía. FAR.
69
También se puede aplicar la proyección a
Πalumno.nombre-alumno, fecha-examen
(σ alumno.numero-cuenta=examen.numero.cuenta(alumno x examen))
ó
Z ← ((ALUMNO x EXAMEN)
[ALUMNO.Número_cuenta=EXAMEN.Número_cuenta])
[ALUMNO.Nombre_alumno, ALUMNO.Fecha_examen]
El resultado:
Nombre-alumno Fechaexamen
Oscar Martínez
02-Jun-97
Jorge Soto
02-Apr-97
Isabel Valderrama
06-May-97
Salvador Pascual
06-Mar-97
El producto cartesiano es conmutativo, así, si S y R son relaciones, se puede
establecer la siguiente equivalencia:
SxT=TxS
El producto cartesiano no es muy utilizado en la práctica, sino más bien puede
implementarse como un caso especial del operador theta-join, que se
explicará más adelante.
El producto cartesiano es útil como una herramienta conceptual, pero no es
necesario que se implemente en los DBMS. Sin embargo, se deberá poder
substituir como el resultado de un caso extremo de otro operador (v.g. thetajoin).
Bases de Datos. Miguel Murguía. FAR.
70
Renombrar
ρ
SELECT * FROM R AS S
La operación renombrar permite evitar ambigüedades cuando se hace
referencia a un mismo atributo pero con diferente uso, por ejemplo, al intentar
contestar “Nombres de los alumnos que tengan la misma carrera que Emilio
Vera”.
Con la siguiente expresión se encuentra la carrera de “Emilio Vera”:
Π carrera (σ nombre-alumno=“Emilio Vera”(alumno))
Pero para encontrar los nombres de los alumnos con esa carrera, se debe hacer
referencia otra vez al atributo nombre-alumno:
σ p(alumno x Π carrera (σ nombre-alumno=“Emilio Vera”(alumno)))
donde p es un predicado que indica que el valor de carrera en alumno es el
mismo que el que se obtiene en Π carrera.
Por esa razón es necesario cambiar de nombre a una relación para poder hacer
esa distinción.
La operación:
ρx(r)
renombra a la relación r con x.
Π carrera
(σ alumno2.carrera=alumno.carrera
(alumno x Π carrera (σ nombre-alumno=“Emilio Vera”( ρalumno2(alumno)))))
Bases de Datos. Miguel Murguía. FAR.
71
Unión
∪
R union S
SELECT * FROM R UNION S
El operador unión es binario: permite agregar las tuplas de dos relaciones.
Por ejemplo, la pregunta “los números de cuenta de los alumnos que han
cursado la materia 02002 o que han hecho un examen” puede responderse
auxiliándose del operador unión, pues es necesario encontrar tuplas de la tabla
examen así como de la tabla historia:
Πnumero-cuenta(σclave-materia=02002 (examen))
∪ Πnumero-cuenta(σclave-materia=02002 (historia))
En álgebra relacional:
Z ← (EXAMEN[Clave_materia=02002])[Número_cuenta] unión
(HISTORIA[Clave_materia=02002])[Número_cuenta]
En SQL
SELECT numero_cuenta
FROM Examen
WHERE clave_materia=“02002”
UNION
SELECT numero_cuenta
FROM Historia
WHERE clave_materia=“02002”;
El resultado:
Numerocuenta
950001
950004
970003
Bases de Datos. Miguel Murguía. FAR.
72
Compatibilidad de unión
Se refiere a que los renglones de las relaciones a unir sean del mismo tipo para
asegurar que el resultado de sea una relación, es decir una tabla-R.
Es decir, existe la restricción de que las relaciones que intervienen en una
operación de unión deben de tener el mismo esquema. Así, para aplicar la
operación unión s ∪ r, las relaciones s y r deben de tener el mismo esquema.
Si S y T son dos relaciones, son compatibles para la unión si:
• tiene el mismo grado y
• es posible establecer un mapeo uno a uno, entre las columnas en S y
T, tal que las columnas de cada par tengan el mismo dominio.
El DBMS debe ser capaz de definir ese mapeo cuando todas las
columnas de la relación tengan un dominio distinto.
En el caso de que exista cuando menos una columna en una relación que
tenga un dominio que no tenga ninguna columna de la otra relación, el
DBMS deberá enviar un mensaje de error.
En el caso de que sí se pueda establecer el mapeo y de que existan más
de una posibilidad de conformarlo, el DBMS deberá preguntarlo al
usuario.
Finalmente, el DBMS podrá aceptar un mapeo explícito del usuario,
caso en el que el DBMS deberá verificar que sea válido.
El operador unión relacional no es tan general como en matemáticas, pues el
relacional permite unir, por ejemplo, números de cuenta con números de
cuenta, nombres de alumnos con nombres de alumnos, etc., mientras que en
matemáticas, la unión sí permite unir, por ejemplo, números de cuenta con
nombres de alumnos.
La unión también elimina renglones duplicados en la relación resultado.
Bases de Datos. Miguel Murguía. FAR.
73
Diferencia
⎯
SELECT * FROM R MINUS S
El operador diferencia encuentra tuplas que están en una relación pero no en
otra. Así, R ─ S devuelve una relación con las tuplas que se encuentran en R y
que no están en S. Por ejemplo, “encontrar los números de cuenta de los
alumnos que no han hecho exámenes”:
Πnumero-cuenta (alumno) ─ Πnumero-cuenta (examen)
Z ← ALUMNO[Número_cuenta] ─ EXAMEN[Número_cuenta]
SELECT numero_cuenta FROM Alumno
WHERE numero_cuenta
MINUS
SELECT numero_cuenta FROM Examen;
ó bien:
SELECT numero_cuenta FROM Alumno
WHERE numero_cuenta
NOT IN
(SELECT numero_cuenta FROM Examen);
El resultado:
Numero-cuenta
950002
970001
950003
950004
970003
970004
Por la manera en que opera, la diferencia da como resultado una tabla sin
renglones repetidos.
Las dos relaciones operandos que intervienen en una diferencia deben de
cumplir los requisitos de compatibilidad de unión.
Bases de Datos. Miguel Murguía. FAR.
74
Definición formal del álgebra relacional
El álgebra relacional forma sus expresiones a partir de operadores y de
relaciones.
Una expresión general del álgebra relacional se construye a partir de
subexpresiones.
Si E1 y E2 son expresiones del álgebra relacional, entonces las siguientes
también lo son:
E1 ∪ E2
E1 ─ E2
E1 x E2
σp(E1) donde P es un predicado con atributos de E1.
Π s(E1) donde s es una lista que consta de algunos de los atributos de E1.
ρ x(E1) donde x es el nuevo nombre de la relación E1.
Bases de Datos. Miguel Murguía. FAR.
75
Operaciones no básicas
Las operaciones definidas en las secciones anteriores son las básicas, es decir
que con ellas se tiene toda la potencia del álgebra relacional, sin embargo, para
fines prácticos, se definen otras operaciones muy utilizadas que se construyen
a partir de éstas básicas.
Intersección
∩
SELECT * FROM R INTERSECT S
La intersección sirve para encontrar las tuplas que se encuentran en dos
relaciones a la vez. Por ejemplo, “encontrar las claves de las materias que ya
han sido cursadas por algún alumno y para las que se ha presentado al menos
un examen”:
Πclave-materia (historia) ∩ Π clave-materia (examen)
Z ← HISTORIA[Clave_materia] intersección
EXAMEN[Clave_materia ]
SELECT clave_materia
FROM Historia
INTERSECT
SELECT clave_materia
FROM Examen;
El resultado:
Clave-materia
02002
Para mostrar que no es una operación básica del álgebra relacional, obsérvese
que la intersección puede calcularse a partir de la diferencia:
r ∩ s = r ─ (r ─ s)
Las dos relaciones operandos que intervienen en una intersección deben de
cumplir los requisitos de compatibilidad de unión.
Bases de Datos. Miguel Murguía. FAR.
76
Producto natural
|x|
Aunque el producto natural no es parte explícita del modelo relacional, es
conveniente su explicación para formalizar otras operaciones así como para
entenderlas mejor.
Reconsidérese la pregunta “encontrar las tuplas de los alumnos que hayan
presentado un examen”:
σ alumno.numero-cuenta=examen.numero.cuenta(alumno x examen)
Como puede observarse, típicamente a una operación de producto cartesiano
se le aplica una selección.
El producto natural realiza automáticamente una selección sobre los
atributos en común, poniendo la restricción de que los valores sean iguales en
los atributos de ambas tablas.
Así al realizar el producto natural
alumno |x| examen
se seleccionan automáticamente sólo aquellas tuplas que coincidan en el
atributo numero-cuenta, pues ese atributo es común a ambas relaciones. Si hay
más de un atributo en común, entonces las tuplas deberán coincidir en ambos
valores de cada par de atributos.
Adicionalmente, el producto natural realiza una proyección sobre la unión
de los atributos, evitando repetir columnas. Así, para el ejemplo anterior, el
esquema de la relación resultante del producto natural es:
(numero-cuenta, nombre-alumno, año-ingreso, carrera, clave-materia, ordende-pago, fecha-examen)
Como puede observarse, el atributo numero-cuenta no se repite en el esquema.
Bases de Datos. Miguel Murguía. FAR.
77
El producto natural es una operación muy importante en el modelo
relacional, pues es una de las principales maneras de “relacionar” tablas en la
práctica.
Formalmente el producto natural se define como:
r|x|s = ΠR∪S(σ r·A1=s·A1^ r·A2=s·A2^ ... ^r·An=s·An r x s)
donde R y S son los conjuntos de atributos de las relaciones r y s
respectivamente
y A1, A2, ... An ∈ R ∩ S
Es decir, el producto natural es una proyección de una selección de un
producto cartesiano.
La operación producto natural es asociativa, es decir:
(r |x| s) |x| t = r |x| (s |x| t)
por lo que se puede escribir como:
r |x| s |x| t
Por ejemplo, “encontrar los nombres de los alumnos y los nombres de las
materias que hayan aprobado con más de 8.0:
Πnombre-alumno, nombre-materia (σ calificacion>8 (alumno |x| materia |x| historia))
Nombre-alumno nombremateria
Oscar Martínez
Estadística
Mario Sánchez
Estadística
Carmen Díaz
Botánica
Carmen Díaz
Bioquímica
Miguel Romero
Bioquímica
Bases de Datos. Miguel Murguía. FAR.
78
Theta Join
Z ← R [ R.atributo=S.atributo ] S
SELECT *
FROM R
JOIN S ON R.A=S.A
En la práctica, los operadores de producto cartesiano y de producto natural
son incluidos en el de join.
El operador join realiza la misma acción que el producto natural, pero se
deben indicar explícitamente las columnas de ambas relaciones a comparar,
pues en el producto natural las columnas a comparar son aquellas que tienen
el mismo nombre.
Por ejemplo, si se desea obtener una tabla de los nombres de los alumnos junto
con las claves de las materias que han cursado se debe extraer información de
las tablas ALUMNO e HISTORIA y comparar el número de cuenta:
Z ← ALUMNO[Número_cuenta=Número_cuenta ]HISTORIA
La expresión anterior regresa una relación de grado n+m, siendo n y m los
grados de ALUMNO e HISTORIA.
Si se desea obtener únicamente las columnas de nombre_alumno y
clave_materia, es necesario realizar una proyección:
Z ← (ALUMNO[Número_cuenta=Número_cuenta ]HISTORIA)
[Nombre_alumno, Clave_materia]
SELECT nombre_alumno, clave_materia
FROM Historia
JOIN Examen
ON Historia.número_cuenta=Examen.número_cuenta;
Bases de Datos. Miguel Murguía. FAR.
79
El resultado:
Nombrealumno
Oscar Martínez
Mario Sánchez
Mario Sánchez
Carmen Díaz
Carmen Díaz
Miguel Romero
Miguel Romero
Clavemateria
02001
02001
02003
02002
02003
02002
02003
Análogamente al operador theta selección, el operador theta join hace uso de
los 10 comparativos listados en la explicación del primero.
Cuando de habla del operador join se sobrentiende que se está comparando
mediante EQUALITY.
Al operador theta join que compara mediante EQUALITY se le llama equi
join.
El equi join es conmutativo, es decir:
R[A=B]S = S[B=A]R
Bases de Datos. Miguel Murguía. FAR.
80
Theta Join extendido
La extensión del theta join es análoga a la de la selección, es decir, añade la
posibilidad de utilizar los conectivos lógicos NOT, OR, AND e IMPLIES.
Mediante un theta join extendido se pueden averiguar los casos en que un
alumno que haya cursado y hecho examen de la misma materia
Z ← HISTORIA [HISTORIA.Calificación<EXAMEN.Calificación ^
HISTORIA.Número_cuenta=EXAMEN.Número_cuenta ^
HISTORIA.Clave_materia=EXAMEN.Clave_materia]
EXAMEN
Join natural
En el equi join, las columnas que se comparan aparecen en el resultado
añadiendo redundancia, ya que ambas columnas contienen exactamente los
mismos valores, esta redundancia no se dá con los otros 9 tipos de theta join.
Con la finalidad de eliminar esa redundancia en el equi join se define el join
natural, en el que se elimina una de las columnas que se usan en la
comparación.
El join natural genera una relación resultado de grado menor que el equi
join, utilizando los mismos operandos.
Bases de Datos. Miguel Murguía. FAR.
81
División
÷
El operador división sirve para encontrar las tuplas que satisfacen una relación
“para todo”. Por ejemplo, “encontrar los números de cuenta de los alumnos
que han cursado todas la materias de la carrera de Biología”.
La expresión, utilizando división, que contesta esa pregunta es:
Π numero-cuenta, clave-materia (historia) ÷ Π clave-materia (σ carrera=“Biología” (materia))
Así, una expresión del tipo:
r÷s
tiene como esquema a R-S. Si r tiene como esquema a R=(A1, A2) y s a
S=(A2), entonces r ÷ s da como resultado una relación con los valores A1
tales que el par (A1,A2) aparecen en r para todos los valores de A2 que
aparecen en s.
Por ejemplo:
r
A1
a
a
a
a
b
b
b
c
c
c
r÷s
s
A2
x
y
z
w
v
x
z
x
z
w
÷
Bases de Datos. Miguel Murguía. FAR.
A2
x
z
w
=
A1
a
c
82
Formalmente:
r ÷ s = Π R-S (r) - Π R-S ((Π R-S(r) x s) - r
donde r(R) y s(S) son relaciones y S ⊆ R
Obsérvese que:
(Π R-S(r) x s)
tiene esquema R, pues rxs tiene esquema R∪S y si a ese producto se
aplica una proyección R-S se obtiene el esquema R. Además es
condición necesaria que coincidan los esquemas para poder operar una
diferencia.
La expresión
Π R-S ((Π R-S(r) x s) - r)
da como resultado una relación de esquema R-S y obtiene todas las
tuplas que deben eliminarse de r para cumplir con la definición de la
división, pues obtiene todas las tuplas en r que no tienen una igual en s.
Así, si observamos la expresión:
Π numero-cuenta, clave-materia (historia) ÷ Π clave-materia (σ carrera=“Biología” (materia))
dará como resultado los números de cuenta (i.e. {numero-cuenta, clave-materia} {clave-materia}) que estén asociados a cada una de las claves de materia que
se encuentren en:
Π clave-materia (σ carrera=“Biología” (materia))
Así, la respuesta a “los números de cuenta de los alumnos que han cursado
todas la materias de la carrera de Biología”, puede mostrarse
esquemáticamente:
Bases de Datos. Miguel Murguía. FAR.
83
R
S
número-cuenta
950001
950002
950002
950004
950004
970003
970003
relación
R
S
T
clave-materia
02001
02001
02003
02002
02003
02002
02003
÷
clave-materia
02002
02003
esquema
Esquema-R
Esquema-S
Esquema-R - Esquema-S
Bases de Datos. Miguel Murguía. FAR.
T
=
número-cuenta
950004
970003
(número_cuenta, clave_materia)
(clave_materia)
(número_cuenta)
84
División (Reforzamiento)
A continuación se ejemplifica la equivalencia de la división:
r ÷ s = Π R-S (r) - Π R-S ((Π R-S(r) x s) - r)
Esquemas:
R = {A1, A2}
S = {A2}
R-S = {A1}
Nótese que Π R-S(r) x s tiene esquema R, pues S ⊆ R.
Π R-S(r) x s
Π R-S(r)
Π R-S(r) x s
s
A1
a
b
c
x
A2
x
z
w
A1
a
a
a
b
b
b
c
c
c
=
A2
x
z
w
x
z
w
x
z
w
(Π R-S(r) x s) - r
Π R-S(r) x s
A1
a
a
a
b
b
b
c
c
A2
x
z
w
x
z
w
x
z
(Π R-S(r) x s) - r
r
-
A1
a
a
a
a
b
b
b
c
Bases de Datos. Miguel Murguía. FAR.
A2
x
y
z
w
v
x
z
x
=
A1
b
A2
w
85
c
w
c
c
z
w
Recuerde que:
Π R-S (r) - Π R-S ((Π R-S(r) x s) - r)
ΠR-S(r)
A1
a
b
c
Π R-S((Π R-S(r) x s) - r)
-
A1
b
=
Π R-S (r) - Π R-S ((Π R-S(r) x s) - r)
A1
a
c
Asignación
Z←R
SELECT * FROM R INTO S
SELECT * FROM R AS S
El operador asignación es útil para expresar consultas complejas, pues
permite dividir la pregunta en módulos.
Por ejemplo, para expresar de una manera más entendible a la equivalencia de
la división en términos de operaciones básicas se pueden realizar las siguientes
asignaciones:
A <- Π R-S (r)
B <- A - Π R-S ((Π R-S(r) x s) - r
La asignación se puede observar en dos ámbitos:
Uno en donde la variable a la que se asigna sólo se requiere de manera
temporal, por ejemplo, como medio para realizar un “query” complejo.
Bases de Datos. Miguel Murguía. FAR.
86
Otro, donde se desea que el valore de la variable (la relación asignada)
se almacene en la base de datos, ésta operación requiere una
modificación al diccionario de datos, es decir al esquema de la base de
datos, además de que se deberá especificar la(s) columna(s) que
conforma a la llave primaria.
Bases de Datos. Miguel Murguía. FAR.
87
Ejercicios I
1. Considere la siguiente pregunta:
“Clave de las materias que han sido cursadas por todos los alumnos”
¿Qué operador relacional ayuda a contestar esta pregunta directamente?
¿Cuál es una equivalencia en SQL de ese query?
2. ¿En que sentido los operadores de diferencia, unión e intersección no son
equivalentes a su contraparte en la teoría de conjuntos?
3. ¿Qué es compatibilidad de unión?
¿A qué operadores aplica?
¿Porqué el modelo relacional lo pone como una restricción en esos casos?
4. ¿Qué significa que los operadores del modelo relacional sean cerrados?
¿Cómo esa propiedad ayuda en la práctica?
5. ¿Es más complicado actualizar llaves primarias que otros atributos? ¿Por
qué?
Bases de Datos. Miguel Murguía. FAR.
88
Ejercicios II
1. Construya una tabla de los operadores relacionales indicando si son unarios
o binarios y si son o no conmutativos. Asimismo, indique si es requisito
que los operandos cumplan la restricción de compatibilidad de unión.
2. Para el esquema de una base de datos de un negocio que desarrolló,
muestre una consulta en donde se utilice el producto natural de tres
tablas.
3. Construya la consulta equivalente del ejercicio anterior pero utilizando
producto cartesiano.
4. Explique la equivalencia de la operación división utilizando sólo
operaciones básicas.
5. Construya una expresión del álgebra relacional para obtener los nombres
de las materias que ha cursado Carmen Díaz.
6. Construya una expresión del álgebra relacional para obtener los nombres
de los alumnos que han cursado Bioquímica pero no Estadística.
Bases de Datos. Miguel Murguía. FAR.
89
2. Modificación de la Base de Datos
Asignación
Z←R
SELECT * FROM R INTO S
SELECT * FROM R AS S
El operador asignación es útil para expresar consultas complejas, pues
permite dividir la pregunta en módulos.
Por ejemplo, para expresar de una manera más entendible a la equivalencia de
la división en términos de operaciones básicas se pueden realizar las siguientes
asignaciones:
A ← Π R-S (r)
B ← A - Π R-S ((Π R-S(r) x s) - r
La asignación se puede observar en dos ámbitos:
Uno en donde la variable a la que se asigna sólo se requiere de manera
temporal, por ejemplo, como medio para realizar un “query” complejo.
Otro, donde se desea que el valore de la variable (la relación asignada)
se almacene en la base de datos, ésta operación requiere una
modificación al diccionario de datos, es decir, al esquema de la base de
datos, además de que se deberá especificar la(s) columna(s) que
conforma a la llave primaria.
Bases de Datos. Miguel Murguía. FAR.
90
Inserción
insert
Z←Z∪R
INSERT INTO R VALUES (v1, v2, ..., vn)
El operador insert permite agregar un renglón o una colección de renglones a
una relación. Aunque físicamente se insertan en algún orden, para el modelo
relacional no es importante si se insertan al inicio o al final o en algún otro
orden.
Si la colección de renglones a insertar contiene renglones que están
duplicados, entonces, el DBMS debe insertar sólo uno de ellos.
Si la colección de renglones a insertar incluye alguno de los de la relación en
que se insertan, entonces, el DBMS no debe insertarlo.
Como una relación no debe tener renglones que repitan la llave primaria,
entonces no deberán de insertarse los renglones que ocasionen este problema.
Si la relación en al que se insertan tiene índices, éstos deben de actualizarse
automáticamente, para que los nuevos renglones sean incluidos.
Si los renglones a insertar se obtienen de una expresión del álgebra relacional,
entonces se puede utilizar la unión y la asignación para subsitutir a la
inserción:
Z ← Z UNION E
donde E es una expresión del álgebra relacional.
SQL:
INSERT INTO HISTORIA
VALUES (970003, 02001, 97, 9);
Bases de Datos. Miguel Murguía. FAR.
91
Actualización
update
UPDATE R SET A=a WHERE B=b;
El operador update substituye a la eliminación e inserción de renglones
cuando se desean cambiar los valores de una porción pequeña de las
columnas.
La información necesaria para realizar una actualización es:
• el nombre de la relación a actualizar,
• la especificación de los renglones a actualizar, y
• los nombres de las columnas que se desean actualizar en los
renglones y los nuevos valores de esos componentes.
Para identificar a los renglones que se desean actualizar, el usuario puede
brindar una lista de las claves primarias, o una condición válida para el
operador selección.
Los índices existentes deben de actualizarse.
La integridad referencial puede dañarse si se actualizan las llaves primarias o
las llaves foráneas.
Actualización de llaves primarias
El modelo relación define un operador para este caso especial: primary-key
update.
Este operador busca en todas las columnas de la base de datos que tengan el
mismo dominio de la columna que el usuario desea actualizar y cambia, en
cascada, todos los valores que coincidan (llaves foráneas).
SQL: UPDATE MATERIA
SET NOMBRE_MATERIA=“Cálculo Integral”
WHERE NOMBRE_MATERIA=“Cálculo”;
Bases de Datos. Miguel Murguía. FAR.
92
Borrar
delete
DELETE R WHERE P
El operador delete permite eliminar renglones de una relación. El caso
particular de borrar cero renglones no debe tratarse especialmente.
El usuario puede especificar los renglones mediante una lista de llaves
primarias o mediante una expresión de selección válida.
Los índices existentes deben de actualizarse automáticamente.
La integridad referencial puede dañarse si existen llaves foráneas con valores
que coincidan con las llaves primarias de los renglones eliminados.
DELETE EXAMEN
WHERE ORDEN_DE_PAGO=NULL;
delete with cascade deletion
En el modelo relacional se define el operador delete with cascade deletion
que produce una propagación de la eliminación de renglones ligados mediante
llaves foráneas que coinciden con las llaves primarias de los renglones
eliminados.
3. Vistas
Definición de vistas
Las vistas permiten personalizar la interface con cada tipo de usuario.
También permiten confinar la interacción con la Base de Datos a una o más
vistas como la única manera de acceder a los datos.
Las vistas “relaciones virtuales” representadas por su nombre y su definición.
La definición de una vista puede estar basada en:
Bases de Datos. Miguel Murguía. FAR.
93
a) tablas-R
b) vistas
c) tablas-R y vistas
Por ejemplo, se puede definir una vista que considere a los alumnos de la
carrera de Biología. Esa vista puede estar representada en el catálogo bajo la
fórmula:
ALUMNO [Carrera=“Biología”]
VISTA_1
Numerocuenta
950001
950002
970001
950004
970003
NombreAñoCarrera
alumno
ingreso
Oscar Martínez
95 Biología
Mario Sánchez
95 Biología
Emilio Vera
97 Biología
Carmen Díaz
95 Biología
Miguel Romero
97 Biología
Otro ejemplo de vista es el equi-join entre ALUMNO e HISTORIA sobre el
atributo Número_de_cuenta.
ALUMNO [Número_de_cuenta=Número_de_cuenta] HISTORIA
VISTA_2
Numerocuenta
950001
....
970003
Nombre...
alumno
Oscar Martínez ...
Número_cuen ...
ta
950001
...
Calificació
n
8.2
Miguel Romero ...
970003
8
Bases de Datos. Miguel Murguía. FAR.
...
94
Modificabilidad de las Vistas
Las vistas no deben definirse en términos de procedimientos (v.g.
involucrando loops), esto hace que los usuarios puedan definir vistas aunque
no sean programadores.
Las vistas se definen utilizando lenguaje relacional.
La definición de las vistas deben de poder almacenarse en el catálogo, pues en
general, son de interés para una comunidad de usuarios y no solo para un
usuario en particular.
El DBMS y el lenguaje relacional no deben hacer distinción en el tratamiento
de relaciones y de vistas, excepto porque:
• algunas vistas no aceptan inserción de renglones, eliminación y/o
actualización.
• algunas vistas no tienen llaves primarias, por lo que no aceptan
aquellos operadores que requieren de una llave primaria en sus
operandos.
Modificabilidad
El término “modificable” se refiere a que una vista pueda aceptar operaciones
de delete, update e insert.
No todas las vistas son modificables, pues en algunos casos, el dar esas
libertades puede producir daños en la integridad.
Por ejemplo, si una vista se define como una proyección de atributos no
primos, entonces no está definido cómo operar un delete.
Bases de Datos. Miguel Murguía. FAR.
95
Algoritmo VU
Considérese la siguiente definición de una vista:
VISTA_3:
HISTORIA [Clave_materia, Calificación]
Clave-materia Calificacio
n
02001
8.2
02001
9
02003
7
02002
9
02003
10
02002
8
02003
9
La vista anterior no puede aceptar delete, pues cada renglón de la vista pueden
corresponder a más de uno en la relación base (HISTORIA), así, la
eliminación de un renglón en la vista podría considerar la eliminación de
varios en la relación base.
En términos generales, una vista es modificable en términos de tres
operadores: delete, update e insert.
Para cada uno de esos operadores se puede definir si la vista es modificable.
Así, se puede definir para cada vista si se le pueden borrar tuplas, insertar
tuplas o actualizar componentes.
El modelo relacional define el algoritmo VU (View Updatability) para definir
si una vista es modificable o no en cada uno de los tres aspectos: delete,
update e insert.
El algoritmo VU debe estar implementado en los DBMS y puede ejecutarse al
momento de definir una vista. Es decir, el algoritmo VU opera en tiempo de la
definición de la vista, no en el de la ejecución.
El algoritmo VU recibe como parámetros la definición de la vista en un
lenguaje relacional y el conjunto de restricciones de integridad. Con esos dos
elementos se puede decidir la modificabilidad de la vista.
El DBMS debe de almacenar en el catálogo los estados reportados por el VU
para la modificabilidad de cada vista.
Bases de Datos. Miguel Murguía. FAR.
96
IV Diseño de bases de Datos Relacionales
1. Normalización
Dependencia funcional
Dada una relación R, su atributo B es funcionalmente dependiente del
atributo A (denotado por AÆ B) si y sólo sí, siempre que dos tuplas de R
coinciden en su valor A, también lo hacen en su valor B.
También se dice que A determina funcionalmente a B.
Por ejemplo:
A
1
1
2
3
3
3
4
4
B
22
22
50
10
10
10
22
22
Las dependencias funcionales definen una de las maneras en que se
relacionan entre sí los atributos.
Pueden ser vistas como un conjunto de restricciones al modelo de datos, ya
que son condiciones que se deben de cumplir en el modelo de datos.
ALUMNO
Numerocuenta
Nombrealumno
Añoingreso
Bases de Datos. Miguel Murguía. FAR.
Carrera
97
En esa relación el atributo NOMBRE_ALUMNO es funcionalmente
dependiente del NUMERO_CUENTA, pues para cada valor de
NUMERO_CUENTA hay sólo uno de NOMBRE_ALUMNO.
Obsérvese que la dependencia funcional es direccional, por ejemplo, se
permite que para cada valor de NOMBRE_ALUMNO si haya más de uno en
NUMERO_CUENTA.
Supóngase que se tiene una relación con el siguiente esquema:
HISTORIA(ALUMNO#, GRUPO#, MATERIA, PROFESOR,
SALON, CALIFICACION)
con llave primaria (ALUMNO#, GRUPO#); en la que se cumplen las
siguientes relaciones funcionales:
1.- (ALUMNO#, GRUPO#) Æ CALIFICACION
Lo que implica que para cada par de valores ALUMNO#, GRUPO#
existe un sólo valor de CALIFICACION.
2.- GRUPO# Æ MATERIA
3- GRUPO# Æ PROFESOR
4.- GRUPO# Æ SALON
Lo que implica que para cada valor GRUPO# hay un sólo valor de
MATERIA, PROFESOR y SALON.
5.- PROFESOR Æ SALON
y para cada valor de PROFESOR hay sólo uno de SALON.
Las dependencias funcionales son un elemento importante en el diseño de
bases de datos relacionales, pues ponen restricciones al modelo por construir.
Además, en varios de los conceptos de normalización la dependencia
funcional está involucrada como idea fundamental.
Bases de Datos. Miguel Murguía. FAR.
98
1a. forma normal
Una relación está en primera forma normal (1FN) si todos los valores de los
atributos son atómicos.
Generalmente esta propiedad es inherente a la definición de relación.
2a. forma normal
Una relación está en segunda forma normal (2FN) si está en 1FN y cada
atributo no-primo depende completamente de la llave primaria.
Dependencia completa se refiere a que si en la llave primaria participa más
de un atributo, entonces el atributo debe depender de la combinación de todos
los atributos de la llave y no sólo de alguno de ellos.
Por ejemplo, CALIFICACION depende completamente de la llave primaria:
1.- (ALUMNO#, GRUPO#) Æ CALIFICACION
mientras que SALON no:
4.- GRUPO# Æ SALON
Así, para transformar la relación HISTORIA a 2FN es necesario separar los
atributos que dependan parcialmente de la llave:
CALIF (ALUMNO#, GRUPO#, CALIFICACION)
CURSO (GRUPO#, MATERIA, PROFESOR, SALON)
La descomposición garantiza que se haga sin “pérdida de información”, es
decir, que no contenga menos información que:
HISTORIA(ALUMNO#, GRUPO#, MATERIA, PROFESOR,
SALON, CALIFICACION)
Bases de Datos. Miguel Murguía. FAR.
99
Nótese que para que una relación que esté en 1FN no esté en 2NF debe tener
una llave compuesta.
La relación HISTORIA, que está 1NF pero no en 2NF, tiene la dificultad de
que:
• No se puede registrar un curso sin que se conozca cuando menos un
alumno que esté inscrito. Pues no se puede tener un valor nulo en el
atributo ALUMNO#.
• Si se desea actualizar el nombre del PROFESOR se deberá hacerlo en
varias tuplas de la relación.
• Si todos los alumnos de un curso se dan de baja entonces se perderá
la información de ese curso.
Bases de Datos. Miguel Murguía. FAR.
100
3a. forma normal
Una relación está en tercera forma normal (3FN) si está en 2FN y cada
atributo no-primo depende no-transitivamente la llave primaria.
Por ejemplo, el atributo SALON es dependiente transitivamente del atributo
GRUPO#, pues:
3- GRUPO# Æ PROFESOR, y
5.- PROFESOR Æ SALON
Así, la relación CURSO no está en 3NF:
CURSO (GRUPO#, MATERIA, PROFESOR, SALON)
y presenta los siguientes problemas:
• En el caso de que los salones sean cubículos personalizados, no se
puede asignar un cubículo (SALON) a un PROFESOR hasta se habrá
un curso.
• Si el PROFESOR cambia de cubículo, habrá que actualizarlo en cada
grupo asignado a ese profesor.
• Si un profesor deja de dar clases, entonces no se tiene información de
él y en qué cubículo encontrarlo.
Para transformarla a 3NF, se debe dividir la relación CURSO para evitar que
SALON dependa transitivamente de la llave primaria:
CALIF (ALUMNO#, GRUPO#, CALIFICACION)
CURSO (GRUPO#, MATERIA, PROFESOR)
CATEDRA (PROFESOR, SALON)
En este proceso de partir la relación original en otras, se conoce como
descomposición sin pérdida de información.
En general, una relación R(A,B,C) en la que existe una dependencia funcional
Bases de Datos. Miguel Murguía. FAR.
101
AÆ B,
puede descomponerse sin pérdida de información en las proyecciones:
R1(A,B) y
R2(A,C)
que se conoce como el “teorema de Heath”, descrito en 1971.
No se pierde información en la descomposición, pues la relación original se
puede reconstruir reuniendo (join) las proyecciones.
Bases de Datos. Miguel Murguía. FAR.
102
Forma normal de Boyce-Codd
Una relación está en la forma normal de Boyce-Codd (BCFN) si y sólo sí
cada determinante es una llave candidata.
Un determinante es un atributo o grupo de ellos, de los que algunos otros
atributos son funcionalmente dependientes, es decir, si:
AÆ B,
entonces A es un determinante.
Como ejemplo, considérese una escuela en la que:
• cada materia puede ser impartida por varios profesores,
• cada profesor enseña sólo una materia,
• cada estudiante toma varias materias y tiene sólo un profesor para una
materia dada.
Lo anterior puede representarse mediante el esquema:
INSCRIPCION(ALUMNO#, PROFESOR, MATERIA)
con clave primaria (ALUMNO#, PROFESOR) y las dependencias:
PROFESOR Æ MATERIA
ALUMNO# Æ PROFESOR
Esa relación no está en 2NF, pues existe la dependencia parcial:
PROFESOR Æ MATERIA
lo cual se puede resolver mediante:
INSCRIPCION(ALUMNO#, MATERIA, PROFESOR)
Bases de Datos. Miguel Murguía. FAR.
103
La relación:
INSCRIPCION(ALUMNO#, MATERIA, PROFESOR)
sí está en 2NF y aún en 3NF, pero no en BCFN, pues se tiene la dependencia:
PROFESOR Æ MATERIA
y PROFESOR no es una llave candidata (y es un determinante, por lo que
viola la definición de BCFN).
Como puede observarse, existe redundancia en el hecho de que cada profesor
sólo imparte una materia, y en esa relación aparecerá el PROFESOR junto con
la MATERIA que imparte cada que un alumno toma una clase con él.
Lo anterior puede resolverse mediante la descomposición:
CLASE(ALUMNO#, PROFESOR)
PROFESOR(PROFESOR, MATERIA)
Bases de Datos. Miguel Murguía. FAR.
104
4a. forma normal
Una relación está en cuarta forma normal (4FN) si y sólo sí, siempre que
exista una dependencia multivaluada en R, AÆÆ B, todos los atributos de R
son funcionalmente dependientes de A.
Como ejemplo considérese la relación:
PROVEEDOR(COMPAÑIA, PRODUCTO, PAIS)
con llave primaria (COMPAÑIA, PRODUCTO, PAIS) sin dependencias
funcionales; y que significa que una COMPAÑIA vende un PRODUCTO en
cierto PAIS.
Esa relación está en BCFN. Sin embargo, es evidente la redundancia de
información cuando cada empresa vende todos sus productos a cada país al
que exporta. Por ejemplo, si IBM vende computadoras a Francia, entonces
vende todo sus productos en Francia.
Así, si quisiéramos agregar el hecho de que IBM exporta a España, tendríamos
que agregar una tupla <IBM, p. España> para cada producto p que produce
IBM.
Ahora considérese la siguiente descomposición sin pérdida de información:
PRODUCE(COMPAÑIA, PRODUCTO)
EXPORTA(COMPAÑIA, PAIS)
con claves primarias COMPAÑIA, PRODUCTO) y (COMPAÑIA, PAIS)
respectivamente.
La redundancia no era debida a la existencia de dependencias transitivas ni
parciales, sino a las dependencias multivaluadas:
COMPAÑIA ÆÆ PRODUCTO
COMPAÑIA ÆÆ PAIS
Bases de Datos. Miguel Murguía. FAR.
105
Ejemplos de tuplas de la relación PROVEEDOR
COMPAÑIA
IBM
IBM
IBM
IBM
IBM
IBM
DEC
DEC
DEC
DEC
ICL
ICL
PRODUCTO
PC
PC
PC
MAINFRAME
MAINFRAME
MAINFRAME
PC
PC
MINI
MINI
MAINFRAME
MAINFRAME
PAIS
FRANCIA
ITALIA
UK
FRANCIA
ITALIA
UK
FRANCIA
IRLANDA
FRANCIA
IRLANDA
ITALIA
FRANCIA
Alternativa, después de aplicar 4 forma normal:
PRODUCE
COMPAÑIA
IBM
IBM
DEC
DEC
ICL
PRODUCTO
PC
MAINFRAME
PC
MINI
MAINFRAME
EXPORTA
COMPANY
IBM
IBM
IBM
DEC
DEC
ICL
ICL
PAIS
FRANCIA
ITALIA
UK
FRANCIA
IRLANDA
ITALIA
FRANCIA
Bases de Datos. Miguel Murguía. FAR.
106
Dependencia multivaluada
Dada una relación R(A, B. C), la dependencia multivaluada
A ÆÆ B
se cumple en R sí y sólo sí, el conjunto de los valores de B que corresponden a
un par dado (valor de A, valor de C) en R depende sólo del valor de A y es
independiente de C.
La relación PROVEEDOR se puede considerar como una combinatoria entre
los atributos COMPAÑIA-PRODUCTO-PAIS
COMPAÑIA
IBM
PRODUCTO
PC
MAINFRAME
DEC
PC
MINI
MAINFRAME
ICL
PAIS
FRANCIA
ITALIA
UK
FRANCIA
IRLANDA
ITALIA
FRANCIA
Es decir, se exige la existencia de tuplas dada la existencia de otras, por
ejemplo, dado que existen las tuplas
<IBM, PC, FRANCIA> y
<IBM, MAINFRAME, ITALIA>
entonces también deben existir las tuplas:
<IBM, PC, ITALIA> y
<IBM, MAINFRAME, FRANCIA>
En general, si en una relación se cumple A ÆÆ B, entonces se cumple que
dado que existen la tuplas:
<a, b1, c1 > y
<a, b2, c2 >
Bases de Datos. Miguel Murguía. FAR.
107
también deben existir las tuplas:
<a, b1, c2 > y
<a, b2, c1 >
Una dependencia multivaluada se da en relaciones de 3 o más atributos, pues
la definición hace referencia a relaciones entre A, B y C. Se puede demostrar
que siempre que se da:
A ÆÆ B
también se da:
A ÆÆ C
por lo que suele usarse la notación:
A ÆÆ B | C
Nótese que si una relación R no satisface una dependencia multivaluada, se
puede construir una R’ que sí la satisfaga añadiendo tuplas a R. Por lo que se
dice que mientras que las dependencias funcionales son restrictivas (por
ejemplo dado A Æ B y la tupla < a, b1> no puede existir la tupla < a, b2>), las
dependencias multivaluadas son generadoras de tuplas.
Bases de Datos. Miguel Murguía. FAR.
108
Limitaciones de la normalización
• El proceso de normalización ayuda a representar los hechos en la Base de
datos de una manera más cercana al mundo real.
• Sin embargo, en ocasiones no es necesario normalizar “al extremo” las
relaciones de la base de datos, inclusive, será conveniente mantener algunas
sin normalizar.
Por ejemplo, la relación:
CLIENTE (NOMBRE, CALLE, CIUDAD, PC)
con llave primaria (NOMBRE), no está en 3NF, pues se dan las
dependencias transitivas:
NOMBRE Æ CP
CP Æ CALLE
CP Æ CIUDAD
• Aunque una relación normalizada soluciona aspectos de actualización de la
información, en ocasiones incrementa los problemas de recuperación o
consulta, ya que en una base de datos normalizada la información se tendrá
que recuperar de varias relaciones, por lo que una no-normalizada podrá
tener mejor desempeño.
Bases de Datos. Miguel Murguía. FAR.
109
Dependencia de reunión (join)
El concepto de dependencia de reunión es necesario para entender la 5a forma
normal.
La dependencia de reunión es un concepto más general que el de dependencia
funcional y aún que el de multivaluada.
Así como una dependencia funcional puede ser vista como un caso especial de
la dependencia multivaluada, la dependencia multivaluada es un caso especial
de la de reunión.
Se dice que una relación R satisface una dependencia de reunión (A, B) si A
join B reproducen exactamente a R.
Considérese a la relación PROVEEDOR:
(S#, Noms, Estado, Ciudad)
con claves candidatas S# y Noms. La relación PROVEEDOR satisface la
dependncia re reunión:
((S#, Noms, Estado), (S#, Ciudad))
pues (S#, Noms, Estado) join (S#, Ciudad) reproduce a PROVEEDOR.
También satisface la dependencia de reunión:
((S#, Noms,), (S#, Estado), (Noms, Ciudad))
pues (S#, Noms) join (S#, Estado) join (S#, Ciudad) también reproduce a
PROVEEDOR.
Bases de Datos. Miguel Murguía. FAR.
110
5NF o PR/NF (forma normal de proyección-reunión)
Quinta forma normal:
Una relación R está en quinta forma normal (5NF) (también llamada de
proyección-reunión) si y sólo si toda dependencia de reunión en R está
implicada por las llaves candidatas de R.
Considere la relación SPJ(S, P, J) con llave primaria (S,P,J):
SPJ
S
S1
S1
S2
S1
P
P1
P2
P1
P1
J
J2
J1
J1
J1
La relación SPJ no contiene dependencias funcionales ni dependencias
multivaluadas, por lo que se encuentra en 4NF, sin embargo, se observa
redundancia en la información, pudiéndose producir anomalías al actualizarla.
Considérese las proyecciones SP y PJ:
SP
S
S1
S1
S2
S1
PJ
P
P1
P2
P1
P1
P
P1
P2
P1
P1
J
J2
J1
J1
J1
y el join de SP y PJ:
SP join PJ
S
S1
S1
S1
S2
P
P1
P1
P2
P1
J
J2
J1
J1
J2
Bases de Datos. Miguel Murguía. FAR.
111
S2
P1
J1
como puede observarse SP join PJ no reproduce a SPJ, pues contiene una
tupla de más.
Ahora considere a la proyección SJ:
SJ
S
S2
S1
S1
J
J1
J1
J2
El join SP join PJ join SJ reproduce a SPJ, por lo que existe la dependencia de
reunión (SP, PJ, SJ), y por lo tanto SPJ no está en 5NF.
En general:
Si
<s1, p1> aparce en SP
<p1, j1> aparce en PJ
<s1, j1> aparce en SJ
entonces
<s1, p1, j1> aparece en SPJ.
o bien:
Si
<s1, p1, j2>,
<s1, p2, j1>,
<s2, p1, j1> aparecen en R
entonces
<s1, p1, j1> también debe aparecer en R.
Es decir, la dependencia de reunión es un tipo de restricción adicional a la
dependencia funcional y a la multivaluada.
Bases de Datos. Miguel Murguía. FAR.
112
Cuando existe una dependencia de reunión en una relación, sí debe
descomponerse para así transformar a 5NF.
Bases de Datos. Miguel Murguía. FAR.
113
DK/NF (Dependencia de dominio-clave)
Forma normal de dominio-clave:
Una relación está en forma normal de dominio-clave si cada restricción en la
afinidad es consecuencia lógica de la definición de las claves y dominios.
Cuando se diseña una base de datos y se intenta “normalizarla” se hace
respecto a un conjunto de restricciones. Por ejemplo, para normalizar a 2NF,
3NF y BCNF se deben de considerar las dependencias funcionales en el
modelo de datos; para normalizar a 4NF se deben de considerar las
dependencias multivaluadas; para normalizar a 5NF se deben de considerar las
dependencias de reunión.
Sin embargo, existen otros tipos de restricciones que se imponen al modelo,
entendiendo por restricción cualquier regla que gobierna los valores estáticos
de atributos.
De manera informal, una relación está en forma normal de dominio-clave si al
aplicar las restricciones de clave y de dominio se provoca que se cumplan
todas las restricciones.
Bases de Datos. Miguel Murguía. FAR.
114
Resumen de Formas Normales
1NF
Valores atómicos
2NF
Los atributos no primos dependen completamente de la llave
primaria
3NF
No hay dependencias transitivas
BCNF
Cada determinante es una clave candidata
4NF
No hay dependencias multivaluadas
5NF
Dependencias de reunión implicadas por las llaves candidatas
Bases de Datos. Miguel Murguía. FAR.
115
Dependencias Funcionales
Además de que es útil conocer el conjunto de dependencias funcionales que se
utilizarán como restricción para diseñar la estructura de la base de datos,
también es útil conocer todas las posibles dependencias funcionales que se
puedan derivar lógicamente.
Es decir, dado un conjunto F de dependencias funcionales, se pueden deducir
otras, siguiendo un conjunto de reglas deductivas, y se dice que F implica
lógicamente a dicho conjunto.
Cierre de un conjunto de dependencias funcionales
El cierre de F es el conjunto de dependencias funcionales F+ que F implica
lógicamente.
Para calcular el cierre F+ dado un conjunto F, se utilizan los axiomas de
Armstrong, que son un conjunto de reglas de transformación, para las que se
ha demostrado su validez.
Los axiomas de Armstrong son seguros porque no generan dependencias
funcionales incorrectas y son completos porque para un conjunto F de
dependencias funcionales permiten generar F+ completo.
Bases de Datos. Miguel Murguía. FAR.
116
Axiomas de Armstrong
Reflexividad:
Si α es un conjunto de atributos y β ⊆ α,
entonces se cumple αÆβ
Aumento:
Si se cumple αÆβ y γ es un conjunto de atributos,
entonces se cumple γαÆγβ
Transitividad:
Si se cumple αÆβ y se cumple βÆγ,
entonces se cumple αÆγ
Otras reglas que se deducen a partir de los axiomas de Armstrong son:
Unión:
Si se cumple αÆβ y se cumple αÆγ,
entonces se cumple αÆβγ
Descomposición:
Si se cumple αÆβγ,
entonces se cumplen αÆβ y αÆγ
Pseudotransitividad:
Si se cumple αÆβ y se cumple βγÆδ,
entonces se cumple αγÆδ
Ejemplo:
Considérese a la relación R:
R(A, B, C, G, H, I)
y al conjunto de F dependencias funcionales:
AÆB
AÆC
Bases de Datos. Miguel Murguía. FAR.
117
CG Æ H
CG Æ I
BÆH
Podemos generar algunos miembros de F+:
A Æ H,
transitividad A Æ B y B Æ H;
CG Æ HI, unión
CG Æ H y CG Æ I;
AG Æ I,
AG Æ CG aumento A Æ C y G.
AG Æ I transitividad AG Æ CG y CG Æ I
Bases de Datos. Miguel Murguía. FAR.
118
Análisis
La metodología para diseño de bases de datos relacionales se puede clasificar
en dos tipos de estrategias: Análisis y Síntesis.
Los ejemplos revisados en clase sobre las diferentes etapas de normalización,
utilizan una estrategia analítica porque dada una relación se iba dividiendo,
generando relaciones con menor número de atributos, con la finalidad de
avanzar en el proceso.
Análisis significa distinguir y separar las partes de un todo hasta llegar a
conocer sus principios o elementos.
En el caso extremo de la metodología de análisis, se parte de una relación
universal y se va dividiendo para ir cumpliendo con diferentes grados de
normalización.
Casos intermedios y más comunes son partir de un conjunto de relaciones en
las que cada una se estudia para establecer si cumple con una determinada
forma normal.
En el análisis se generan conceptos más específicos a partir de conceptos
generales. Por ejemplo, a partir de Curso se pueden “descubrir” las relaciones
Alumno, Profesor y Salón.
Bases de Datos. Miguel Murguía. FAR.
119
Síntesis
Síntesis significa formar un todo mediante la reunión de sus partes.
En la síntesis se generan conceptos más generales a partir de conceptos
específicos. Por ejemplo, se puede generar el concepto (relación) Curso a
partir de las relaciones Alumno, Profesor y Salón.
Caso teórico extremo es partir de un conjunto de atributos y de dependencias
funcionales, e ir agregando a los atributos guiado por las restricciones de
dependencias funcionales.
Bases de Datos. Miguel Murguía. FAR.
120
Ejercicios
1.- Defina 30 términos o conceptos del modelo relacional revisados en clase.
2.- Mencione algunas características del modelo relacional en las que esté
involucrado el concepto de dominio.
3.- Considere a la relación R(A, B, C, D, E) y dependencias funcionales:
A Æ BD
CD Æ E
BÆD
EÆA
a) Demuestre que (A, B, C) (A, D, E) es una descomposición sin
pérdida de información.
b) Demuestre que (A, B, C) (C, D, E) no es una descomposición sin
pérdida de información.
c) Normalice R hasta BCNF justificando cada paso.
4.- Para el ejemplo de la escuela revisado en clase, proponga un conjunto de
restricciones mediante dependencias funcionales, justificando cada una.
Bases de Datos. Miguel Murguía. FAR.
121
5.- Considere la relación PROYECTO:
esquema:
PROYECTO(IDProyecto, NombreEmpleado, SalarioEmpleado)
extensión:
PROYECTO
IDProyecto
NombreEmpleado
SalarioEmpleado
100A
100A
100B
200A
200B
200C
200C
200D
Juan
Samuel
Samuel
Juan
Juan
Pedro
Samuel
Pedro
6400
5100
5100
6400
6400
2800
5100
2800
Suponga que todas las dependencias funcionales son evidentes en la extensión.
¿Cuál de las siguientes dependencias funcionales se cumplen?
a) IDProyecto Æ NombreEmpleado
IDProyecto Æ SalarioEmpleado
(IDProyecto, NombreEmpleado) Æ SalarioEmpleado
NombreEmpleado Æ SalarioEmpleado
SalarioEmpleado Æ IDProyecto
SalarioEmpleado Æ IDProyecto, NombreEmpleado
b) ¿En qué forma normal está? Explique.
c) ¿El atributo SalarioEmpleado es un determinante?
d) ¿El atributo NombreEmpleado es un determinante?
e) ¿El atributo IDProyecto es un determinante?
f) ¿Existen dependencias transitivas?
g) Considerando el conjunto de dependencias funcionales que se cumplen,
rediseñe normalizando.
Bases de Datos. Miguel Murguía. FAR.
122
2. Árboles, redes y relaciones recursivas
Árboles
Un árbol se puede representar mediante relaciones con cardinalidad de
asignación 1:N.
Se representan almacenando la clave de padre en el hijo. Los nodos raíz tienen
valor nulo en ese atributo. Cada nodo tiene cuando mucho un padre.
Por ejemplo, la estructura de división política puede representarse mediante un
árbol, implementándola como:
País 1:N Estado 1:N Municipio
lo que significa que un país contiene varios estados y un estado contiene
varios municipios.
Si los diferentes niveles del árbol son del mismo tipo, entonces se puede
representar mediante relaciones recursivas.
Por ejemplo, si se tiene una relación Cliente y se desea registrar qué persona
recomendó a qué otra, entonces:
Cliente 1:N Cliente
que podría implementarse a través de los campos ClvCliente y
RecomendadoPor:
Cliente
ClvCliente
1
2
3
4
5
6
Nombre
...
Bases de Datos. Miguel Murguía. FAR.
RecomendadoPor
NULL
1
1
3
3
4
123
Relaciones recursivas
Relación recursiva: Relación que existe entre entidades de la misma clase.
1:1
Persona
A
B
C
D
E
Se relaciona hacia
B
D
E
A
nulo
Persona
B
D
E
A
Se relaciona desde
A
E
C
D
1:N
Cliente
A
B
C
D
E
No normalizado:
Cliente
A
A
B
B
C
D
E
Recomendado por
nulo
A
B
B
A
Recomienda a
B
E
C
D
nulo
nulo
nulo
N:M
Dos tablas:
Bases de Datos. Miguel Murguía. FAR.
124
Empresa
A
B
C
D
E
Atributos...
...
...
...
...
...
y
Tabla de intersección:
Empresa
A
B
C
D
E
Vende a
C
D
B
A
A
Bases de Datos. Miguel Murguía. FAR.
125
Redes
Análogamente, una red se puede representar mediante cardinalidades de
asignación N:M.
Si los nodos son del mismo tipo, entonces se debe representar mediante una
relación recursiva, pero como la cardinalidad es N:M, entonces se debe de
añadir una relación que contenga a las claves primaria y foránea.
Por ejemplo, si se quiere representar la red de partidos que han jugado una
serie de equipos, entonces se deben de relacionar por
Equipo
ClvEquipo
Nombre
Técnico
...
Partidos
ClvEquipoCasa
ClvEquipoVisita
...
Una red también puede servir para representar listas de materiales, por
ejemplo, para indicar de qué partes están formadas otras partes.
Listas
Una lista de elementos del mismo tipo puede representarse con una relación
recursiva 1:1.
Por ejemplo, una lista de los clientes que se han ido incorporando a la cartera
se puede representar agregando un campo ClvSigCliente. Obviamente, en
muchos casos se puede añadir un campo que establezca un criterio de orden,
por ejemplo la fecha de la primera venta.
Bases de Datos. Miguel Murguía. FAR.
126
3. Integridad
El mantenimiento de la integridad de una base de datos, está relacionado con
el mantenimiento de la consistencia de los datos y con su validez. Este es un
aspecto muy importante, sobre todo en bases de datos en ambientes
multiusuarios.
Algunos manejadores comerciales contienen un subsistema de integridad que
monitorea las operaciones de actualización con el fin de detectar violaciones a
la integridad. Cuando se detecta una violación a la integridad, el sistema
realiza algunas acciones apropiadas, como rechazar la operación causante de la
violación, reportar la violación y, de ser necesario, regresar a la base de datos
a un estado consistente.
Sin embargo, los subsistemas de integridad en general son primitivos, por lo
que esta tarea queda principalmente en manos del implementador.
Podemos agrupar a las diferentes estrategias del mantenimiento de la
integridad en:
Reglas de integridad de dominio.
Su objetivo es mantener valores correctos de los atributos. Por ejemplo, la
regla de integridad de entidad verifica que los valores de los atributos que
pertenecen a la llave primaria no deben ser nulos.
Reglas de integridad de Intra-relación.
Verifican la validez entre los valores de los atributos de una misma relación y
el mantenimiento de llaves únicas.
Reglas de integridad de referencia.
Mantienen la validez y consistencia entre relaciones.
Integridad de dominio
Una relación se define como un subconjunto de un producto cartesiano de n
dominios D1, D2, ...Dn, no necesariamente distintos. Así, los valores que
aparecen en la columna i de la relación deben pertenecer a Di, es decir, cada
atributo de cada relación R tiene un dominio subyacente Di, por lo que cada
valor candidato para R.A debe pertenecer a Di.
Bases de Datos. Miguel Murguía. FAR.
127
Una regla de integridad de dominio es simplemente una definición del tipo del
dominio. La integridad de dominio está relacionada con el concepto de
verificación de tipo de los lenguajes de programación.
La definición del tipo de un dominio debe ser lo más precisa posible con el fin
de evitar violaciones a la integridad de dominio. Por ejemplo, el dominio del
atributo EDAD puede definirse como:
DOMINIO DOM_EDAD = ENTERO
pero es más conveniente aún definirlo como:
DOMINIO DOM_EDAD = ENTERO-POSITIVO
y aún mejor como:
DOMINIO DOM_EDAD = ENTERO-POSITIVO:[0-150]
Desafortunadamente, la mayoría de los manejadores comerciales sólo proveen
tipos simples para los dominios. Por ejemplo, ORACLE tiene los tipos
NUMBER (números enteros y reales), CHAR (cadenas), DATE, TIME y
MONEY.
Varios atributos pueden tener el mismo dominio, por ejemplo, NOMBREALUMNO y PROFESOR tienen el dominio de los nombres de las personas.
Sin embargo, para efectos de implementación, en la práctica se definen los
dominios como cadenas de caracteres.
Surge un problema cuando se definen a los dominios de NOMBRE-ALUMNO
y MATERIA como cadenas de caracteres, por ejemplo, el sistema no puede
detectar que la pregunta:
“Todos los alumnos que tienen el nombre de alguna
de las materias que han cursado”
es improcedente, pues contiene una comparación entre dos atributos con
dominios diferentes:
Bases de Datos. Miguel Murguía. FAR.
128
ALUMNO.Nombre=MATERIA.Nombre
Así, las restricciones de dominio sirven, no sólo para validar la información
contenida en cada atributo, sino también para verificar que tienen sentido las
comparaciones incluidas en preguntas a la base de datos.
Integridad intra-relacional
Las reglas de integridad intra-relación verifican la validez entre los atributos
de una relación, por ejemplo llaves únicas o el hecho de que toda relación no
debe contener dos tuplas con los mismos valores en todos sus atributos.
Cuando se agrega una tupla se debe checar que no exista otra tupla con los
mismos valores en todos sus atributos primos. Asimismo, también se debe
verificar esa condición, no sólo cuando se agregan tuplas, sino también
cuando se actualizan.
De hecho, actualizar los valores de los atributos primos es una operación que
debe tomarse con cuidado, pues una operación inválida tiene serias
consecuencias en la base de datos.
Integridad referencial
La integridad de referencia mantiene la validez de las relaciones entre las
tablas. Por ejemplo, verificar que las llaves foráneas sean nulas o iguales a
alguna llave primaria de la tabla que se relaciona.
Las llaves foráneas desempeñan un papel muy importante, pues mantienen
ciertas relaciones definidas en el modelo.
La cardinalidad de asignación también es una restricción de integridad. Las
cardinalidades 1:1, N:1 o N:M que se definen en un modelo, deben de
mantenerse en la implementación, por ejemplo, una relación con cardinalidad
1:1 no puede contener dos tuplas con los mismos valores en los atributos de la
llave foránea.
De manera general, la integridad referencial permite asegurar que un valor que
aparece en una relación, también aparezca en otra.
Bases de Datos. Miguel Murguía. FAR.
129
Integridad semántica intra-relacional
Verificar la consistencia entre los valores de dos atributos de cada tupla. Por
ejemplo, los atributos EDAD y ANTIGÜEDAD de una tabla con datos de
profesores, deben de cumplir la restricción
EDAD > ANTIGÜEDAD
o más específicamente:
EDAD > ANTIGÜEDAD + C
donde C es un valor constante que es la edad mínima a la que un profesor
comienza a laborar.
La integridad semántica debe de fundamentarse en el análisis sobre el
significado de los atributos dentro del dominio de aplicación, es decir, en el
significado de las interrelaciones entre atributos.
Análisis de consistencia en bases de datos geográficas
Dentro del registro
ClvEstado
Lat
Lon
...
El punto (Lat,Lon) debe de estar dentro de los límites estatales de ClvEstado,
de acuerdo a una cartografía de referencia.
ClvEstado
Lat
Lon
Altitud
...
El punto (Lat,Lon) debe estar a una altitud igual a Altitud.
Bases de Datos. Miguel Murguía. FAR.
130
(La altitud registrada en Altitud debe ser igual a la altitud del punto (Lat,Lon)
en el mapa.)
El estado ClvEstado debe contener a Altitud en sus intervales de altitudes
Entre registros
Dos registros con el mismo (Lat,Lon) deben coincidir en sus valores ClvEstado
y Altitud.
Afirmaciones
Una afirmación puede verse como un procedimiento mediante el cual se
verifica que cierto atributo, o conjunto de ellos, cumpla con ciertas
restricciones.
Por ejemplo, verificar que un alumno no puede realizar más de dos
extraordinarios para una misma materia. Así, cuando se incorpora un registro
sobre un examen extraordinario habría que contar las ocurrencias para ese
mismo alumno en esa misma materia y sólo se aceptaría la operación en el
caso de que el número de ocurrencias no supere a uno.
De hecho, las restricciones de integridad de dominio, referencial e intrarelacional pueden verse como casos específicos de afirmaciones.
En general, las afirmaciones realizan un consumo de recursos considerable. La
definición original de SQL incluía la instrucción assert para definir
afirmaciones, pero fué eliminada de las implementaciones, y aún del SQL
estándar actual, debido a la gran cantidad de tiempo que consume la
verificación de una afirmación.
Como alternativa a las afirmaciones, se puede establecer un programa de
validación en el que el administrador defina un calendario para aplicar rutinas
de validación, que detecten violaciones a la integridad. Esta estrategia tiene la
ventaja de que el tiempo de acceso en linea no disminuye, pero tiene la
desventaja de que es más dificil reestablecer la integridad de la base de datos
días después de hacer las actualizaciones que en el momento de la captura.
Bases de Datos. Miguel Murguía. FAR.
131
Disparadores
Los disparadores son estrategias de integridad en los que se pueden especificar
instrucciones a ejecutar cuando se cumple un conjunto de instrucciones
predeterminadas. Por ejemplo, añadir un registro en una tabla cuando se
incluya un valor que no existía.
Los disparadores son análogos a los demonios del sistema operativo UNIX.
4. Autorizaciones
Los diferentes tipos de instituciones establecen diferentes procedimientos para
salvaguardar su información.
El enfoque de seguridad y autorización que se incorpora en el modelo
relacional es lo suficientemente flexible para que las instituciones puedan
mantener los procedimientos que utilizan, sin ningún cambio, o bien, con
pequeños cambios.
En los DBMS actuales, existe una relación estrecha entre autorización y vistas.
Un beneficio de este enfoque es que disminuye la complejidad de la
implementación.
Algunos usuarios pueden estar autorizados para manipular ciertas columnas o
renglones de una relación, así, el alcance de la autorización puede expresarse
en términos de una vista que contenga sólo esos renglones y columnas. Así,
pueden existir vistas sólo por motivos de autorización, sin embargo, la
mayoría de los DBMS son pobres en la implementación de actualización de
vistas.
Filosofía afirmativa
En el modelo relacional, el enfoque en cuanto a autorización es “afirmativo”,
es decir, se expresa explícitamente los permisos, mientras que en muchos
enfoques no relacionales se expresa explícitamente los accesos denegados.
Bloque de actualización que eliminan renglones de una vista
Bases de Datos. Miguel Murguía. FAR.
132
Supóngase que un usuario tiene acceso s una vista V y a actualizar los valores
de una de sus columnas A. de una vista. El DBA debe poder bloquear las
actualizaciones que hacen que algunos renglones “salgan” de la vista.
Acciones que necesitan autorización de más de un usuario
Algunas actividades o actualización de la base de datos son de crucial
importancia para la empresa, por ejemplo, eliminar los datos de toda una tabla,
para ese tipo de actividades se debe tener la autorización de DBA y del
gerente, por ejemplo.
Algunas de las actividades que pueden requerir la autorización de más de un
usuario son:
• alguna ejecución del comando DROP (desechar)
• alguna ejecución del comando DELETE
• algún cambio a los “periodos de gracia”
Eliminaciones retardadas (“Periodos de gracia”)
Las eliminación de relaciones mediante la ejecución del comando DROP
RELATION tiene como consecuencia almacenarla por un periodo mínimo de
7 días. También las eliminación de un porcentaje elevado de renglones
también pueden estar sujetas a esta estrategia. El “default” es un periodo de 7
días, pero se puede especificar un valor mayor.
Actividades autorizables: control de la base de datos
Algunas de las actividades que se deben de poder autorizar de manera
separada o combinada son:
• crear y eliminar (drop) un dominio
•
una tabla R base
•
una columna de una tabla R existente
•
una vista
•
una restricción de integridad
•
una función definida por el usuario
•
un índice
Bases de Datos. Miguel Murguía. FAR.
133
• crear una llave foránea en una tabla R
• activar o desactivar una autorización
• establecer el modo UP o DOWN para el redondeo de pseudofechas
(v.g. Febrero 30, Marzo 32, Enero 0)
Actividades autorizables: Querys y manipulación
•
•
•
•
•
consultar una tabla R específica
insertar renglones en una tabla R específica
actualizar componentes específicos de una tabla R específica
actualizar llaves primarias de tablas específicas
borrar renglones de tablas R específicas
Bases de Datos. Miguel Murguía. FAR.
134
5. Catálogo
El catálogo almacena la descripción de la estructura de la base de datos.
Forma parte del diccionario de datos. El diccionario de datos además
almacena información sobre los programas de aplicación.
El catálogo debe soportar las siguientes características:
•
•
•
•
•
•
•
•
On-line
Concurrencia
Descripción de dominios, relaciones base y vistas
Restricciones de integridad definidas por el usuario
Restricciones de integridad referencial
Funciones definidas por el usuario
Datos de autorización
Estadísticas
On-line
El DBMS debe soportar un catálogo on-line basado en el modelo relacional.
La descripción de la base de datos de debe representar exactamente como
datos ordinarios, permitiendo a los usuarios autorizados aplicar el mismo
lenguaje relacional para consultar la descripción de la base de datos como se
puede hacer con los datos regulares.
Esta característica por lo general la tienen todos los DBMS.
El que se permita usar el mismo lengaje y sobre un mismo tipo de estructura,
hace que el DBA y los usuarios autorizados a accesar el catálogo, tengan que
aprender un sólo modelo de datos (estructura y lenguaje) y no dos ( uno para
datos ordinarios y otro para el catálogo), como sucedía con manejadores prerelacionales.
Concurrencia
Bases de Datos. Miguel Murguía. FAR.
135
El catálogo debe soportar varias consultas al mismo tiempo (consultas
propiamente y actualizaciones).
Al catálogo lo pueden acceder usuarios o programas de aplicación y se debe
de cuidar de no elevar el número de usuarios autorizados para actualizarlo, ya
que el DBMS lo accesa cuando se realizan consultas a datos regulares.
Bases de Datos. Miguel Murguía. FAR.
136
Descripción de dominios, relaciones base y vistas
Los dominios, las relaciones, las vistas las restricciones de integridad y las
funciones definidas por el usuario se describen cada una por separado, pues su
existencia es independiente:
• Muchas relaciones puden utilizar un mismo dominio.
• Las vistas pueden hacer referencias a más de una relación base.
• Las restricciones de integridad pueden involucrar a más de una
relación.
Dominios
Para cada dominio, el catálogo debe almacenar:
•
•
•
•
el nombre del dominio
su tipo de datos base
el intervalo de valores permitido
y una indicación de si el comparador MENOR QUE (<) es aplicable
Relaciones base
Para cada tabla R, se debe almacenar:
•
•
•
•
•
•
•
•
•
el nombre de la tabla R
sinónimos si los tiene
el nombre de cada columna
para cada columna, el nombre de un dominio previamente definido
si se permiten valores ausentes
si se requiere que los valores sean distintos
restricciones adicionales a las aplicables al dominio
si forma parte de la llave primaria
para cada llave foránea, las columnas y su secuenia de las que se
compone.
Vistas
Bases de Datos. Miguel Murguía. FAR.
137
Para cada vista, el catálogo debe registrar:
•
•
•
•
•
•
•
el nombre de la vista
sinónimos, si los hay
el nombre de cada columna
la expresión en lenguaje relacional que define a la vista
si se permite la inserción de renglones
si se permite borrar renglones
para cada columna, si se permite la actualización de valores
No es requisito registrar el dominio de las columnas de valores calculados, ya
que es difícil deducirlo, pero si es necesario indicar el tipo de datos base.
Restricciones de integridad
Restricciones de integridad definidas por el usuario
Las restricciones de integridad definidas por el usuario normalmente las
incorpora el DBA. Pueden representar reglas y políticas de la compañía o
regulaciones impuestas por el gobierno, o bien, pueden representar factores de
diseño que son necesarios debido al significado de los datos.
Para cada restricción de integridad definida por el usuario, el catálogo debe
almacenar:
•
•
•
•
su nombre
el evento que la dispara
la condición lógica a probar
las acciones ante un intento de violación
Restricciones de integridad referencial
Para cada restricción de integridad referencial, el catálogo debe almacenar:
• su nombre
• el evento que la dispara
Bases de Datos. Miguel Murguía. FAR.
138
• las llaves involucradas
• las acciones ante un intento de violación
Funciones definidas por el usuario
Para cada función definida por el usuario, el catálogo debe almacenar:
•
•
•
•
su nombre
el código fuente
el código compilado
los nombres de las relaciones de las que la función requiere acceso
de lectura
• si la función tiene una inversa, su nombre
• el código fuente y compilado de la función inversa
Datos de autorización
El catálogo debe almacenar qué usuarios, terminales y progrmas de aplicación
están autorizados para tener acceso a qué parte de la base de datos, para qué
tipos de operaciones y bajo qué condiciones.
El modelo relaciones establece los accesos mediante acciones permitidas y no
mediante acciones denegadas, lo que significa que el usuaio no tiene ninún
permiso a menos que se indique en el catálogo explícitamente.
Estadísticas
El catálogo también debe almacenar información estadística que se utiliza para
optimizar las consultas del lenguaje relacional:
• el número de renglones en cada tabla R
• el número de valores distintos en cada columna de cada tabla R
Bases de Datos. Miguel Murguía. FAR.
139
Metodología general
1) Análisis de requerimientos
• Datos requeridos para el dominio de aplicación.
• Descripción informal de la información a almacenar, tanto de los objetos como
de sus relaciones.
• Generalización de las vistas sinónimas.
• Identificación de sinónimos y homónimos (tanto de vistas como de objetos y
relaciones).
• Identificación de los procesos y operaciones que la BD deberá realizar.
2) Modelación EER de los requerimientos
• Definición de: Entidades, Atributos y Relaciones.
• Identificación de Claves.
• Diagramas ER.
• Cardinalidades del las relaciones.
3) Transformación del modelo EER al esquema relacional
• Mapear el modelo EER a un conjunto de relaciones.
• Poner atención en la cardinalidad y el tipo de relación (1:1; 1:N; N:M).
4) Normalización del esquema relacional
• Descripción de las dependencias funcionales para cada relación.
• Reducir cada relación al más conveniente estado de normalización.
Bases de Datos. Miguel Murguía. FAR.
140
V Lógica y Cálculo Relacional de Tuplas
1. Lógica
La lógica es un conjunto de conocimientos fundamental para el manejo de bases de datos.
Las condiciones que se especifican al hacer una consulta a una base de datos pueden
contener operadores lógicos. Por ejemplo, seleccionar aquellos registros que cumplan con
la condición A y la condición B, pero que no cumplan la C:
“Todos los municipios del estado de OAXACA que tengan una población mayor a 10,000
ha. pero que la superficie sea menor a 50,000 km2”.
Las sustituciones de condiciones de esta consulta son:
A = Municipio del estado de OAXACA
B = Población > 10,000
C = Superficie < 50,000
Operadores lógicos
Los operadores lógicos permiten crear enunciados compuestos a partir de enunciados
simples. Por ejemplo el operador “y” o “conjunción” puede utilizarse para unir las
proposiciones:
P = Los habitantes de Michoacán tienen un ingreso promedio de 4 salarios mínimos.
Q = Loa habitantes de Michoacán tiene una edad promedio de 20 años.
P y Q = Los habitantes de Michoacán tienen un ingreso promedio de 4 salarios mínimos y
una edad promedio de 20 años.
El significado es que se dan ambos elementos de la fórmula, que los dos elementos simples
son verdaderos. En la tabla n se muestran las notaciones más frecuentes para los operadores
lógicos. En español, las palabras “además”, “aún”, aunque”, “pero”, “sin embargo” y
“también” tienen un significado de conjunción, sin embargo, dan un matiz a la oración, que
desafortunadamente se pierde en lógica al sustituirlos por el operador “y”. En la tabla n se
ejemplifica en tres diferentes lenguajes el uso de la conjunción.
El operador ”o” o “disyunción” también conecta a dos elementos, pero su significado es
que se cumple alguno de los dos elementos (o ambos). En español, la palabra “o” tiene dos
significados, uno “exclusivo” y otro “inclusivo”. El inclusivo se utiliza cuando se desea
connotar que cuando menos uno de los dos elementos es verdadero, es decir, ya sea que los
dos sean verdaderos, o sólo uno, por ejemplo, “La mayoría de los clientes tiene coche o
casa”. El exclusivo se utiliza cuando se desea expresar que sólo uno de los dos es
Bases de Datos. Miguel Murguía. FAR.
141
verdadero, es decir que la verdad de un enunciado excluye la posibilidad de que el otro
también lo sea. Por ejemplo, en el enunciado:
P=Las personas que votaron por el PRI o por el PAN para el presidente de la república.
se entiende que cada persona emite un sólo voto para presidente de la república, y que por
lo tanto ninguna persona puede votar por el PRI y por el PAN.
En el operador “si ... entonces ...” o “implicación”, es importante el orden de los operandos.
A diferencia de la conjunción y de la disyunción, la implicación no es conmutativa, es
decir, no es lo mismo
P -> Q que Q -> P
mientras que sí es lo mismo
P y Q que Q y P
En la implicación al elemento que está antes del operador se le llama antecedente y al que
está después consecuente. Así, en la fórmula P -> Q, P es el antecedente y Q es el
consecuente. El significado más general es que cuando el antecedente es verdadero el
consecuente es verdadero, sin embargo, como puede observarse en su tabla de verdad,
también tiene el significado de que cuando el consecuente es falso también es falso el
antecedente. Por ejemplo, el enunciado:
P = Si trabaja entonces gana más de cero salarios mínimos
es verdadero cuando el antecedente es verdadero y también el consecuente. De hecho, es
falso solamente si el consecuente es falso y el antecedente verdadero, como así se puede
apreciar en la tabla de verdad del operador “->“.
La negación es un operador lógico unario, es decir, que afecta a sólo un argumento, a
diferencia de la conjunción, la disyunción y la implicación que son binarios. Una fórmula
negada es verdadera si la fórmula no negada es falsa y viceversa. Por ejemplo, si
P = Tiene coche compacto
la negación de P es:
¬ P = No tiene coche compacto
Bases de Datos. Miguel Murguía. FAR.
142
Símbolo
Nombres
^
Y
AND
CONJUNCI
ON
Tabla n. Operadores lógicos
v
¬
O
OR
DISYUNCIO
N
NO
NOT
NEGACION
˜
->
IMPLICACION
SI ... ENTONCES ...
LENGUA SENTENCIA
JE
ESPAÑO
L
Número de personas que tienen coche compacto y que viven en el estado
de Aguascalientes
Dbase
COUNT FOR COCHE=“COMPACTO” .AND. EDO=“AGS”
SQL
SELECT * FROM PERSONA WHERE COCHE=“COMPACTO” AND
EDO=”AGS” GROUP COUNT
Tabla n. Ejemplificación del operador lógico “Y” en tres lenguajes.
Tablas de verdad
Una tabla de verdad es una manera de conocer los posibles valores de verdad que puede
adquirir una fórmula “compuesta”, dependiendo de los valores de verdad que adquiere cada
uno de sus elementos “simples”. Para cada variable se crea una columna y cada renglón
representa un caso de sustitución. Por ejemplo, en la tabla de verdad del operador “y”, en el
encabezado se colocan las fórmulas, y en los siguientes renglones se especifican las
posibles combinaciones de valores de verdad de cada fórmula simple, para así calcular el
valor de verdad de la fórmula compuesta; en particular, en el segundo renglón se especifica
el valor de verdad “Verdadero” para las fórmulas simples P y Q, el valor de verdad
resultante para la fórmula compuesta P^Q también es “Verdadero”.
Bases de Datos. Miguel Murguía. FAR.
143
“Y” (AND)
P
V
V
F
F
Q
V
F
V
F
P^Q
V
F
F
F
“O” (OR)
P
V
V
F
F
Q
V
F
V
F
PvQ
V
V
V
F
“IMPLICACIÓN”
P
Q
V
V
V
F
F
V
F
F
P -> Q
V
F
V
V
“NEGACION”
P
¬P
V
F
F
V
“Tablas de verdad” para los operadores lógicos Y, O, IMPLICACION y NO.
Bases de Datos. Miguel Murguía. FAR.
144
Tautologías
Las tautologías son expresiones lógicas que siempre son verdaderas. Lo son por su
estructura, independientemente del significado. Cuando se hace una consulta a una base de
datos y esa consulta es una tautología, entonces el resultado serán todos los registros de la
base de datos, pues todos los registros cumplirán la condición. Por ejemplo, la siguiente
consulta es una tautología:
COUNT FOR COCHE=“COMPACTO” .OR. (.NOT. COCHE=“COMPACTO”)
por lo que el resultado será el número de registros de la base de datos, pues todos cumplirán
la condición de “coche compacto O coche no compacto”
Reglas de inferencia
Las tablas de verdad son una manera de verificar el valor de verdad de una fórmula
compuesta, dado los valores de verdad de las fórmulas simples, o bien, una manera de
probar que un conjunto de premisas son válidas respecto a una conclusión. Pero cuando el
número de premisas es grande se vuelve impráctico ese método, en su lugar se utiliza el
“método de deducción”. El método de deducción permite establecer la validez de
conclusiones a partir de las premisas y “reglas de inferencia”.
Las reglas de inferencia son argumentos para los que ya se ha establecido su validez. Las
reglas de inferencia son un medio para deducir conclusiones válidas a partir de premisas
válidas. Las reglas de inferencia son:
1) Modus Ponens
2) Modus Tolens
3) Silogismo hipotético
4) Silogismo disyuntivo
5) Dilema constructivo
6) Dilema destructivo
7) Simplificación
8) Conjunción
9) Adición
A continuación se enuncia cada una de las reglas de inferencia, ejemplificándolas mediante
proposiciones del español. Las proposiciones de los ejemplos muestran la utilidad de las
reglas de inferencia al construir consultas a bases de datos.
Bases de Datos. Miguel Murguía. FAR.
145
1) Modus Ponens
P->Q
P
-----Q
P=“gana más de tres salarios mínimos”
Q=“ es sujeto de crédito”
1) Si gana más de tres salarios mínimos entonces es sujeto de crédito
2) Gana más de tres salario mínimos
Por lo tanto:
3) Es sujeto de crédito
2) Modus Tolens
P -> Q
¬Q
-----¬P
1) Si gana más de tres salarios mínimos entonces es sujeto de crédito
2) No es sujeto de crédito
Por lo tanto:
3) No gana más de tres salarios mínimos
3) Silogismo hipotético
P -> Q
Q -> R
-----P -> R
1) Si gana más de tres salarios mínimos entonces es sujeto de crédito
2) Si es sujeto de crédito entonces enviar correspondencia
Por lo tanto:
3) Si gana más de tres salarios mínimos entonces enviar correspondencia
Bases de Datos. Miguel Murguía. FAR.
146
4) Silogismo disyuntivo
P v ¬Q
¬P
-----Q
1) Gana más de tres salarios mínimos o no es sujeto de crédito
2) No gana más de tres salario mínimos
Por lo tanto:
3) Es sujeto de crédito
5) Dilema constructivo
(P -> Q) ^ (R -> S)
PvR
-----QvS
1) Si gana más de tres salarios mínimos entonces es sujeto de crédito
y Si tiene coche lujoso entonces enviar correspondencia
2) Gana más de tres salarios mínimos o tiene coche lujoso
Por lo tanto:
3) Es sujeto de crédito o enviar correspondencia
6) Dilema destructivo
(P -> Q) ^ (R -> S)
¬Q v ¬S
-----¬P v ¬R
1) Si gana más de tres salarios mínimos entonces es sujeto de crédito
y Si tiene coche lujoso entonces enviar correspondencia
2) No es sujeto de crédito o no enviar correspondencia
Por lo tanto:
3) No gana más de tres salarios mínimos o no tiene coche lujoso
7) Simplificación
P^Q
Bases de Datos. Miguel Murguía. FAR.
147
-----P
1) Gana más de tres salarios mínimos y tiene coche
Por lo tanto:
2) Gana más de tres salario mínimos
8) Conjunción
P
Q
-----P^Q
1) Gana más de tres salarios mínimos
2) Tiene coche
Por lo tanto:
3) Gana más de tres salario mínimos y tiene coche
9) Adición
P
-----Pv Q
1) Gana más de tres salarios mínimos
Por lo tanto:
3) Gana más de tres salario mínimos o tiene coche
Bases de Datos. Miguel Murguía. FAR.
148
Equivalencias lógicas
Una fórmula es equivalente a otra cuando sus tablas de verdad son iguales, es decir, que
cuando una fórmula es verdadera, dado ciertos valores de verdad a sus fórmulas simples,
también la otra es verdadera, y cuando una fórmula es falsa la otra también lo es. En la
Tabla n se muestran las equivalencias lógicas básicas.
10
<->
<->
<->
<->
<->
<->
<->
<->
<->
¬P v ¬Q
¬P ^ ¬Q
QvP
Q^R
(P v Q) v R
(P ^ Q) ^ R
(P^Q) v (P^R)
(PvQ) ^ (PvR)
¬¬P
Teoremas de De Morgan
14
¬(P ^ Q)
¬(P v Q)
PvQ
P^R
P v (Q v R)
P ^ (Q ^ R)
P ^ (Q v R)
P v (Q ^ R)
P
15
P -> Q
<->
¬Q -> ¬P
Transposición
16
P -> Q
<->
¬P v Q
Implicación material
17
<->
<->
(P -> Q) ^ (Q -> P)
(P ^ Q) v (¬P ^ ¬Q)
PvP
Equivalencia material
18
P <-> Q
P <-> Q
P
19
P
<->
P^P
Tautología
11
12
13
Conmutación
Asociación
Distribución
Doble negación
Exportación
Tabla n. Equivalencias lógicas básicas.
Bases de Datos. Miguel Murguía. FAR.
149
2. Lógica de predicados
Lenguaje de 1er orden o de predicados
Símbolos:
Propios del lenguaje
Predicados
P1, P2, P3, ...
Funciones
f, g, h, ...
Constantes
c1, c2, c3, ...
Otros símbolos:
Variables
X, Y, Z
Cuantificadores
∀
Universal
∃
Existencial
Conectivos ¬, ^, v, →, ↔
Igualdad
=
Auxiliares
( ) .
Hay representaciones del lenguaje de Lógica de 1er orden donde no hay funciones y son
vistas como relaciones.
La interpretación de los “otros símbolos” es siempre la misma, la de los símbolos propios
del lenguaje es la que permite hacer referencia a lo que se quiere representar.
Una fórmula es ...
Se dice que una variable es libre cuando no está dentro del alcance de un cuantificador, de
otra manera, se dice que está cuantificada.
Un enunciado es una fórmula que no tiene variables libres, por ejemplo:
∀x(P(x))
P(x)
si es un enunciado
no es enunciado
Al interpretar un enunciado, éste es verdadero o es falso, lo que no sucede con las fórmulas
que no son enunciados.
Reglas de la negación:
¬∀xA ≡ ∃x¬A
¬∃xA ≡ ∀x¬A
Donde A es una FBF
Bases de Datos. Miguel Murguía. FAR.
150
Reglas de cuantificación
Instanciación Universal (IU)
∀x Φx
∴Φv
donde v es cualquier símbolo individual
Ejemplo:
∀x (Hombre(x) → Mortal(x) )
∴ Hombre(sócrates) → Mortal(sócrates)
Generalización Universal (GU)
Φy
∴∀x Φx
donde y denota cualquier individuo arbitrariamente elegido
Generalización Existencial (GE)
Φv
∴∃x Φx
donde v es cualquier símbolo individual
Instanciación Existencial (IE)
∃x Φx
∴Φv
donde v es una constante individual diferente de y, que no aparece anteriormenteen el
contexto.
Bases de Datos. Miguel Murguía. FAR.
151
Ejemplo: demostración formal:
Todos los perros son carnívoros; algunos animales son perros, por lo tanto algunos,
animales son carnívoros”
1. ∀x(Px → Cx)
2. ∃x(Ax ^ Px)
3. Aw ^ Pw
4. Pw → Cw
5. Pw ^ Aw
6. Pw
7. Cw
8. Aw
9. Aw ^ Cw
10.∃x(Ax ^ Cx)
2. IE
1. IU
3. Conm
5. Simp
4, 6 MP
3 Simp
8, 7 Conj
9 GE
Bases de Datos. Miguel Murguía. FAR.
152
3. Cálculo relacional de tuplas
{ t| P(t) }
El conjunto de las tuplas t tales que el predicado P(t) es verdadero. Por ejemplo:
{ t| t ∈ alumno }
obtiene a toda las tuplas de la relación alumno. Si únicamente requiere un atributo de
todas las tuplas, por ejemplo nombre-alumno, es decir una operación análoga a la
proyección del álgebra relacional, se debe hacer uso del cuantificador existencial,
escribiendo expresiones del tipo:
∃t ∈ r(P(t))
lo que se lle como “existe una tupla t en la relación r tal que el predicado P(t) es
verdadero”. Para el problema en particular de encontrar los nombres de alumnos se puede
escribir de la siguiente manera:
{ t | ∃s ∈ alumno(s[nombre-alumno]=t[nombre-alumno] ) }
pues se están obteniendo las tuplas t, que como puede observarse en la expresión sólo se
hace referencia al atributo nombre-alumno. Es decir, se están obteniendo todas las tuplas
t[nombre-alumno] que cumplan con:
∃s ∈ alumno(s[nombre-alumno]=t[nombre-alumno]
Para realizar una operación análoga a la selección, por ejemplo obtener las tuplas en que el
año de ingreso sea 97, se puede escribir de la siguiente manera:
{ t | ∃s ∈ alumno(s[nombre-alumno]=t[nombre-alumno]
^ s[año-ingreso]=”97”)}
es decir, el conjunto de tuplas t[nombre-alumno] tal que año-ingreso en la relación
alumno es 97 en aquellas tuplas en donde t[nombre-alumno]= nombre-alumno.
El esquema de la relación anterior es (nombre-alumno), pues se está haciendo referencia
únicamente al atributo de t t [nombre-alumno].
También podremos escribir una expresión que involucre a dos predicados, cada uno
haciendo referencia a relaciones diferentes, por ejemplo, “encontrar los alumnos de la
carrera de Biología
Bases de Datos. Miguel Murguía. FAR.
153
Encontrar los números de cuenta de los alumnos que hayan cursado o hecho examen de la
materia con clave 02002.
{ t | ∃s ∈ historia(s[numero-cuenta]=t[numero-cuenta]
^ s[clave-materia]=”02002”)
v ∃u ∈ examen(u[numero-cuenta]=t[numero-cuenta]
^ u[clave-materia]=”02002”)}
Encontrar los números de cuenta de los alumnos que hayan cursado y hecho examen de la
materia con clave 02002.
{ t | ∃s ∈ historia(s[numero-cuenta]=t[numero-cuenta]
^ s[clave-materia]=”02002”)
^ ∃u ∈ examen(u[numero-cuenta]=t[numero-cuenta]
^ u[clave-materia]=”02002”)}
Es decir, el número de cuenta aparece en alguna tupla de la relación historia asociado a la
clave de la materia 02002 y el número de cuenta aparece en alguna tupla de la relación
examen asociado a la clave de la materia 02002
Encontrar los números de cuenta de los alumnos que hayan cursado pero no hecho examen
de la materia con clave 02002.
{ t | ∃s ∈ historia(s[numero-cuenta]=t[numero-cuenta]
^ s[clave-materia]=”02002”)
^ ¬ ∃u ∈ examen(u[numero-cuenta]=t[numero-cuenta]
^ u[clave-materia]=”02002”)}
Está mal:
Encontrar el número de la orden de pago de exámenes que han hecho los alumnos de
Biología.
{ t | ∀s ∈ alumno(s[carrera]=”Biología”
→ ∃u ∈ examen(u[numero-cuenta]=s[numero-cuenta]
^ u[clave-materia]= t[clave-materia])) }
Números de cuenta de los alumnos que han cursado todas las materias de Biología:
{t | ∀x ∈ materia(x[carrera=“Biología”]
→∃y ∈ historia(x[clave-materia]=y[clave-materia]
^ y[número-cuenta]=t[número-cuenta]))}
Bases de Datos. Miguel Murguía. FAR.
154
Nombres de los alumnos que han cursado todas las materias de Biología:
{t | ∀x ∈ materia(x[carrera=“Biología”]
→ ∃y ∈ historia(x[clave-materia]=y[clave-materia]
^ ∃z ∈ alumno(y[número-cuenta]=z[número-cuenta]))}
^ z[nombre]=t[nombre])))}
Bases de Datos. Miguel Murguía. FAR.
155
Bibliografía
DATE, C. J. 1986.
Introducción a los Sistemas de Bases de Datos. Addison-Wesley. México.
HUGHES, J.G. 1991.
Object-Oriented Databases. Prentice Hall. UK.
KORTH, H., SILVERSCHATZ, A, & SUDARSHAN. 2003.
Fundamentos de bases de datos. Cuarta Edición. McGraw-Hill.
KROENKE, D. M. 1996.
Procesamiento de Bases de Datos. Prentice Hall. México.
PIATETSKY-SHAPIRO, G & W.J. FRAWLEY. 1991.
Knowledge Discovery in Databases. AAAI Press. 525 p.
RAMAKRISHNAN, R. & J. GEHRKE. 2003
Database Management Systems. Tercera Ed. McGrawHill.
TECHGUIDE.COM. 2000.
A practical guide to achieving enterprise data quality. The Technology Guide
Series, techquide.com.
ULLMAN, J.D. 1979.
Principles of Databases Systems. Computer Science Press. Washington.
Bases de Datos. Miguel Murguía. FAR.
156
Páginas WWW
Temarios
FCA Licenciado en Informática
http://server.contad.unam.mx/planes/info/basesdt.html
Modelo Relacional
Acordeón de Normalización:
http://www.cba.neu.edu/~mwarkentin/normaliz.htm
UCB DBMS Research Group
ftp://s2k-ftp.cs.berkeley.edu/pub/postgres/otherdbms.html
SQL Standard Home Page
http://www.jcc.com/sql_stnd.html
Bases de Datos. Miguel Murguía. FAR.
157
ANEXO 1. Prolog como Base de Datos
A) Código del Programa
esquema(alumno,'numero-cuenta','nombre-alumno','a¤o-ingreso','carrera').
esquema(materia,'clave-materia','nombre-materia','nivel','creditos').
esquema(examen,'numero-cuenta','clave-materia','orden-de-pago','fechaexamen').
esquema(historia,'numero-cuenta','clave-materia','semestrecurso','calificacion').
alumno(950001,'Oscar Mart¡nez',95,biologia).
alumno(950002,'Mario S nchez',95,biologia).
alumno(950003,'Ma.Elenea Ca¤edo',95,matematicas).
alumno(950004,'Camen D¡az',95,biologia).
alumno(950005,'Jorge Soto',95,fisica).
alumno(970001,'Emilio Vera',97,biologia).
alumno(970002,'Isabel Valderrama',97,matematicas).
alumno(970003,'Miguel Romero',97,biologia).
alumno(970004,'Jos‚ Malo',97,matematicas).
alumno(970005,'Salvador Pascual',97,fisica).
materia(01002,algebra,2,7).
materia(01003,calculo,1,10).
materia(02001,estadistica,1,5).
materia(02002,botancia,3,8).
materia(02003,bioquimica,2,12).
materia(03001,fisica_relativista,4,10).
materia(03002,particulas_elementales,3,9).
examen(950001,02002,3567,02-jun-97).
examen(970002,01002,3676,06-may-97).
examen(950005,03001,3678,02-abr-97).
examen(970005,03002,3789,06-mar-97).
historia(950001,02001,96,8.2).
historia(950002,02001,96,9).
historia(950002,02003,96,7).
historia(950004,02002,96,9).
historia(950004,02003,95,10).
historia(970003,02002,95,8).
historia(970003,02003,96,9).
% Seleccion: Carrera=biologia
q0:alumno(Cuenta,Nombre,Ingreso,biologia),
print(Cuenta), print(-),
print(Nombre), print(-),
print(Ingreso),print(-),nl,
fail.
% Seleccion: Materias con m s de 8 creditos
q1:materia(Clv,Nombre,Nivel,Creditos),
Creditos > 8,
print(Clv),print(-),
print(Nombre),print(-),
print(Nivel),print(-),
print(Creditos),print(-),nl,
fail.
Bases de Datos. Miguel Murguía. FAR.
158
% Proyeccion: Numero de cuenta y Nombres
q2:alumno(Cuenta,Nombre,_,_),
print(Cuenta),print(-),
print(Nombre),nl,
fail.
%Producto cartesiano alumno x materia
q3:alumno(Cuenta,Nombre,Ingreso,Carrera),
materia(Clv,Materia,Nivel,Creditos),
print(Cuenta),print(-),
print(Nombre),print(-),
print(Ingreso),print(-),
print(Carrera),print(-),
print(Clv),print(-),
print(Materia),print(-),
print(Nivel),print(-),
print(Creditos),print(-),nl,
fail.
% Interseccion: Numero de cuenta de alumnos que han hecho examen y
cursado
% la misma materia
q4:examen(Cuenta,_,_,_),
historia(Cuenta,_,_,_),
print(Cuenta),nl,
fail.
% Producto natural: Alumnos que han hecho examen
q5:examen(Cuenta,_,_,_),
alumno(Cuenta,Nombre,_,_),
print(Nombre),nl,
fail.
% Diferencia: Alumnos que han hecho examen sin haber cursado la materia
q6:examen(Cuenta,_,_,_),
not(historia(Cuenta,_,_,_)),
print(Cuenta),nl,
fail.
% Ejemplo: Nombres de alumnos y materias que han acrediatdo con mas de 8
q7:materia(Clv,Materia,_,_),
alumno(Cuenta,Alumno,_,_),
historia(Cuenta,Clv,_,Calif),
Calif>8,
print(Alumno),print(-),
print(Materia),nl,
fail.
% Ejemplo OR: Nombre de los alumnos que han cursado o hecho examen de la
%materia con clave 02002
q8:(historia(Cuenta,02002,_,_);
examen(Cuenta,02002,_,_)),
alumno(Cuenta,Nombre);
print(Nombre),nl,
fail.
Bases de Datos. Miguel Murguía. FAR.
159
B) Resultado de Querys
?- consult('escuela.pro').
?- q1.
'Q0: Seleccion: Carrera=biologia'
950001-'Oscar Martínez'-95950002-'Mario Sánchez'-95950004-'Camen Díaz'-95970001-'Emilio Vera'-97970003-'Miguel Romero'-97?- q1.
'Q1: Seleccion: Materias con más de 8 creditos'
1003-calculo-1-102003-bioquimica-2-123001-fisica_relativista-4-103002-particulas_elementales-3-9?- q2.
'Q2: Proyeccion: Numero de cuenta y Nombres'
950001-'Oscar Martínez'
950002-'Mario Sánchez'
950003-'Ma.Elenea Cañedo'
950004-'Camen Díaz'
950005-'Jorge Soto'
970001-'Emilio Vera'
970002-'Isabel Valderrama'
970003-'Miguel Romero'
970004-'José Malo'
970005-'Salvador Pascual'
?- q3.
'Q3: Producto cartesiano alumno x materia'
950001-'Oscar Martínez'-95-biologia-1002-algebra-2-7950001-'Oscar Martínez'-95-biologia-1003-calculo-1-10950001-'Oscar Martínez'-95-biologia-2001-estadistica-1-5950001-'Oscar Martínez'-95-biologia-2002-botanica-3-8950001-'Oscar Martínez'-95-biologia-2003-bioquimica-2-12950001-'Oscar Martínez'-95-biologia-3001-fisica_relativista-4-10950001-'Oscar Martínez'-95-biologia-3002-particulas_elementales-3-9950002-'Mario Sánchez'-95-biologia-1002-algebra-2-7950002-'Mario Sánchez'-95-biologia-1003-calculo-1-10950002-'Mario Sánchez'-95-biologia-2001-estadistica-1-5950002-'Mario Sánchez'-95-biologia-2002-botanica-3-8950002-'Mario Sánchez'-95-biologia-2003-bioquimica-2-12950002-'Mario Sánchez'-95-biologia-3001-fisica_relativista-4-10950002-'Mario Sánchez'-95-biologia-3002-particulas_elementales-3-9950003-'Ma.Elenea Cañedo'-95-matematicas-1002-algebra-2-7950003-'Ma.Elenea Cañedo'-95-matematicas-1003-calculo-1-10950003-'Ma.Elenea Cañedo'-95-matematicas-2001-estadistica-1-5950003-'Ma.Elenea Cañedo'-95-matematicas-2002-botanica-3-8950003-'Ma.Elenea Cañedo'-95-matematicas-2003-bioquimica-2-12950003-'Ma.Elenea Cañedo'-95-matematicas-3001-fisica_relativista-4-10950003-'Ma.Elenea Cañedo'-95-matematicas-3002-particulas_elementales-3-9950004-'Camen Díaz'-95-biologia-1002-algebra-2-7-
Bases de Datos. Miguel Murguía. FAR.
160
950004-'Camen Díaz'-95-biologia-1003-calculo-1-10950004-'Camen Díaz'-95-biologia-2001-estadistica-1-5950004-'Camen Díaz'-95-biologia-2002-botanica-3-8950004-'Camen Díaz'-95-biologia-2003-bioquimica-2-12950004-'Camen Díaz'-95-biologia-3001-fisica_relativista-4-10950004-'Camen Díaz'-95-biologia-3002-particulas_elementales-3-9950005-'Jorge Soto'-95-fisica-1002-algebra-2-7950005-'Jorge Soto'-95-fisica-1003-calculo-1-10950005-'Jorge Soto'-95-fisica-2001-estadistica-1-5950005-'Jorge Soto'-95-fisica-2002-botanica-3-8950005-'Jorge Soto'-95-fisica-2003-bioquimica-2-12950005-'Jorge Soto'-95-fisica-3001-fisica_relativista-4-10950005-'Jorge Soto'-95-fisica-3002-particulas_elementales-3-9970001-'Emilio Vera'-97-biologia-1002-algebra-2-7970001-'Emilio Vera'-97-biologia-1003-calculo-1-10970001-'Emilio Vera'-97-biologia-2001-estadistica-1-5970001-'Emilio Vera'-97-biologia-2002-botanica-3-8970001-'Emilio Vera'-97-biologia-2003-bioquimica-2-12970001-'Emilio Vera'-97-biologia-3001-fisica_relativista-4-10970001-'Emilio Vera'-97-biologia-3002-particulas_elementales-3-9970002-'Isabel Valderrama'-97-matematicas-1002-algebra-2-7970002-'Isabel Valderrama'-97-matematicas-1003-calculo-1-10970002-'Isabel Valderrama'-97-matematicas-2001-estadistica-1-5970002-'Isabel Valderrama'-97-matematicas-2002-botanica-3-8970002-'Isabel Valderrama'-97-matematicas-2003-bioquimica-2-12970002-'Isabel Valderrama'-97-matematicas-3001-fisica_relativista-4-10970002-'Isabel Valderrama'-97-matematicas-3002-particulas_elementales-39970003-'Miguel Romero'-97-biologia-1002-algebra-2-7970003-'Miguel Romero'-97-biologia-1003-calculo-1-10970003-'Miguel Romero'-97-biologia-2001-estadistica-1-5970003-'Miguel Romero'-97-biologia-2002-botanica-3-8970003-'Miguel Romero'-97-biologia-2003-bioquimica-2-12970003-'Miguel Romero'-97-biologia-3001-fisica_relativista-4-10970003-'Miguel Romero'-97-biologia-3002-particulas_elementales-3-9970004-'José Malo'-97-matematicas-1002-algebra-2-7970004-'José Malo'-97-matematicas-1003-calculo-1-10970004-'José Malo'-97-matematicas-2001-estadistica-1-5970004-'José Malo'-97-matematicas-2002-botanica-3-8970004-'José Malo'-97-matematicas-2003-bioquimica-2-12970004-'José Malo'-97-matematicas-3001-fisica_relativista-4-10970004-'José Malo'-97-matematicas-3002-particulas_elementales-3-9970005-'Salvador Pascual'-97-fisica-1002-algebra-2-7970005-'Salvador Pascual'-97-fisica-1003-calculo-1-10970005-'Salvador Pascual'-97-fisica-2001-estadistica-1-5970005-'Salvador Pascual'-97-fisica-2002-botanica-3-8970005-'Salvador Pascual'-97-fisica-2003-bioquimica-2-12970005-'Salvador Pascual'-97-fisica-3001-fisica_relativista-4-10970005-'Salvador Pascual'-97-fisica-3002-particulas_elementales-3-9-
Bases de Datos. Miguel Murguía. FAR.
161
?- q4.
'Q4: Interseccion: Numero de cuenta de alumnos que han hecho examen '
'
y cursado % la misma materia'
950001
?- q5.
'Q5: Producto natural: Alumnos que han hecho examen'
'Oscar Martínez'
'Isabel Valderrama'
'Jorge Soto'
'Salvador Pascual'
?- q6.
'Q6: Diferencia: Alumnos que han hecho examen sin haber cursado '
'
la materia'
970002
950005
970005
?- q7.
'Q7: Ejemplo: Nombres de alumnos y materias '
'
que han acrediatdo con mas de 8'
'Oscar Martínez'-estadistica
'Mario Sánchez'-estadistica
'Camen Díaz'-botanica
'Camen Díaz'-bioquimica
'Miguel Romero'-bioquimica
?- q8.
'Q8: Ejemplo OR: Nombre de los alumnos que han cursado '
'
o hecho examen de la materia con clave 02002'
'Camen Díaz'
'Miguel Romero'
'Oscar Martínez'
?-
Bases de Datos. Miguel Murguía. FAR.
162