Data Bases One I-2011

Escuela de Ingeniera de Sistemas e Informtica
Curso de Bases de datos

Prof. Jaime Octavio Albarracn Ferreira
1
Objetivos del curso El estudiante aprender en este primer curso de Bases de datos, los conceptos tericos fundamentales: 1. Los conceptos matemticos relacionales 2. El lenguaje SQL para la descripcin, administracin y consulta de Bases de datos 3. Los conceptos de normalizacin de Bases de datos 4. El diseo de Bases de datos segn el modelado semntico 5. Los conceptos de integridad de las Bases de datos 6. La construccin de una base de datos especfica para una empresa de la regin
2
Contenido del curso

1. Introduccin a las Bases de datos 1.1 Definicin de una Base de datos (DB) 1.2 Definicin de un DBMS 1.3 Tipos de usuarios de una DB 1.4 Operaciones de entrada y salida en una DB 1.5 Apuntadores 2. Organizaciones bsicas de archivos 2.1 Organizacin consecutiva 2.2 Organizacin secuencial 2.3 Organizacin relativa
3
2.4 Organizacin directa 2.5 Organizacin secuencial indexada 3. Organizaciones de archivos para DBMS 3.1 Organizacin inversa 3.2 Organizacin multilista 3.3 Organizacin multianillo 4. Niveles de una Base de datos 4.1 Nivel interno 4.2 Nivel conceptual 4.3 Nivel externo 4.4 Mapeo de datos
5. Propiedades de una Base de datos 5.1 Independencia de datos 5.2 Seguridad 5.3 Integridad 5.4 Respaldo y recuperacin 5.5 Control de redundancia 5.6 Consistencia 5.7 Auditoria 5.8 Control de concurrencia 5.9 Rutas de acceso
6. Software complementario de un DBMS 6.1 Administrador de la Base de datos (DBA) 6.2 Diccionario de datos 6.3 Lenguajes de la Base de datos 6.3.1 DDL (Lenguaje de descripcin de datos) 6.3.2 DML (Lenguaje de manejo de datos) 7. Clases de DBMS 7.1 Enfoque jerrquico 7.2 Enfoque en red 7.3 Enfoque relacional
8. Modelo relacional 8.1 Nivel conceptual 8.2 Nivel externo o vistas 8.3 Nivel interno 8.4 El lenguaje de datos 9. Algebra relacional 9.1 Operaciones de conjunto 9.2 Operaciones unarias 9.3 Operaciones adicionales 10. Clculo relacional 10.1Variables de tuplas 10.2 Condiciones de comparacin
7
10.3 Condiciones de pertenencia 10.4 Condiciones compuestas 10.5 Cuantificador existencial 10.6 Cuantificador universal 10.7 Expresiones 10.8 Tipos de variables de tuplas 10.9 Ejemplos 11. Lenguajes para el manejo de datos: Oracle y SQL 11.1 Consultas simples 11.2 Consultas de reunin 11.3 Funciones integradas
11.4 Caractersticas avanzadas de SELECT 11.5 Proposiciones de actualizacin 11.6 SQL embebido 12. Diseo de Bases de datos: El modelo relacional y la normalizacin. 12.1 La relacin universal 12.2 Primera forma normal (1FN) 12.3 Dependencia funcional 12.3.1 Clave candidata 12.3.2 Clave principal 12.3.3 Clave fornea
9
12.3.4 Claves alternas 12.4 Normalizacin de la relacin 1FN 12.5 Segunda forma normal (2FN) 12.6 Normalizacin de las relaciones 2FN 12.7 Tercera forma normal (3FN) 12.8 Forma normal de Boyce & Codd (BCNF) 12.9 Cuarta forma normal (4FN) 13. El modelo semntico o modelo E/R 13.1 Las reglas lgicas o reglas del negocio 13.2 Entidades e interrelaciones 13.3 Grado de las interrelaciones 13.4 Correspondencia de las interrelaciones
10
13.5 Cardinalidad de las interrelaciones 13.6 Diagramas E/R 13.7 Conversin de un diagrama E/R a un diagrama referencial (tablas) 13.8 Valores de claves forneas segn cardinalidad 13.9 El modelo E/R extendido 13.1.8.1 La generalizacin 13.1.8.2 La agregacin 13.10 Verificacin del grado de normalidad 14. Integridad de una Base de datos 14.1 Restricciones de dominio 14.2 Integridad de las entidades 14.3 Integridad referencial
11
Sistema de notas: (Todos los previos con igual valor)

Primer previo: Captulos 1 - 10 (pupitre e individual): 14 de abril de 2011 Segundo previo: Captulo 11 (computador e individual): 12 de mayo de 2011 Tercer previo: Captulos 12 - 14 (pupitre e individual): 9 de junio de 2011 Cuarto previo: Quices orales (en cualquier clase) Trabajo: Sustentable (en grupos no mayores a 3) al finalizar el semestre.
Textos:
Diapositivas del curso. C. J. Date; Introduccin a los sistemas de bases de datos, Prentice Hall, Sptima edicin, ISBN:968-444-419-2. Siberschatz; Fundamentos de bases de datos, McGraw Hill, Quinta edicin, ISBN: 84-481-4644-1. SQL, manual de referencia, Groff & Weinberg, McGraw Hill, ISBN 84-481-3930-5.
12
Bibliografa
James R. Groff & Paul N. Weinberg; SQL Manual de referencia, McGrawHill, ISBN: 0-07-222559-9 C. J. Date; Introduccin a los sistemas de Bases de datos, PrenticeHall, ISBN: 968-444-419-2, sptima edicin Abraham Silberschatz & Henry Korth; Fundamentos de Bases de datos, McGrawHill, ISBN: 0-07-295886-3, quinta edicin Ramakrishnan Raghu & Gehrke Johannes; Sistemas de gestin de Bases de datos, McGrawHill, ISBN: 978-84-481-5638-1, tercera edicin Ramez Elmasri & Shamkant B. Navathe; Fundamentos de sistemas de Bases de datos, Pearson Addison Wesley, ISBN: 978-84-7829-085-7, quinta edicin Gillenson Mark L.; Administracin de Bases de datos, Limusa Wiley, ISBN-13: 978-968-18-6595-2 Mario G. Piattini & otros; Tecnologa y diseo de Bases de datos; Alfaomega-Rama, ISBN: 978-970-15-1268-5 Prez Csar; Oracle PL/SQL, Alfaomega-Rama, ISBN: 978-970-151374-3 Rodriguez Almeida Miguel; Bases de datos, McGrawHill, ISBN: 847615-807-6
13
1. Introduccin a las Bases de datos

1.1 Definicin de una Base de datos Una Base de datos es un conjunto de archivos almacenados de forma integrada y compartida, el cual implica el uso de un software manejador (DBMS). 1.2 Definicin de un DBMS Un DBMS es un software que tiene las siguientes funciones:
14
Funciones de un DBMS
a. b. c. d. e. f. g. h. Crear y organizar la Base de datos Establecer ndices y mantener rutas de acceso Agregar archivos nuevos a la Base de datos Insertar registros nuevos en archivos existentes Obtener datos de archivos existentes Actualizar datos en archivos existentes Borrar registros en archivos existentes Eliminar archivos de la Base de datos
15
Concurso de un DBMS en la E/S
3
16
1.3 Tipos de usuarios de una Base de datos

a) El programador de aplicaciones b) El usuario final c) El administrador de la Base de datos (DBA)
17
1.4 Operaciones de E/S en una Base de datos

X
DBMS
FS Disco Driver bloques
18
1.5 Apuntadores
Hay tres clases de apuntadores: 1. Direccin relativa. Es un entero entre 0 o 1 hasta el nmero mximo de registros de un archivo. Debe ser traducida en direccin absoluta. 2. Direccin fsica o absoluta. Es la posicin real de un registro dentro del disco, es decir, el nmero de bloque ocupado por el registro. No necesita ser traducida. 3. ndices: Es un campo propio al registro (clave principal) que lo identifica en forma nica y exclusiva. Deben ser traducidos en direccin absoluta.
19
2. Organizaciones bsicas de archivos

a) Consecutiva b) Secuencial (SAM) c) Relativa d) Directa (DAM) e) Secuencial indexada (ISAM)
2.1 Organizacin consecutiva.

Cdula 2345 1234 6781 5667 3030 1893 4567 Apellido Gmez Serrano Peralta Flrez Durn Peralta Rico Nombre Andrs Rosa Javier Luis Carmen Carlos Omar Dpto. Categora A A B A C B A 1 3 2 1 2 4 1
20
2.2 Organizacin secuencial (SAM).

Cdula 1234 1893 2345 3030 4567 5667 6781 Apellido Serrano Peralta Gmez Durn Rico Flrez Peralta Nombre Rosa Carlos Andrs Carmen Omar Luis Javier Dpto. Categora A B A C A A B 3 4 1 2 1 1 2
21
Lote
Grabacin
Movimiento Transaccin Clasificacin Movimiento clasificado Actualizacin Errores Maestra actualizada Cinta maestra
Actualizacin de archivos secuenciales

22
Correccin Digitacin Trascripcin Transaccin Si Si No
Prevencin No No No
De los errores al actualizar archivos secuenciales

(para lo cual se utilizaba el procesamiento por lotes)
23
2.3 Organizacin relativa

Dir. Rel. Cdula 1 2 3 4 5 6 7 8 9 10 1234 1893 2345 3030 4567 5667 6781 1295 1486 3827 Apellido Serrano Peralta Gmez Durn Rico Flrez Peralta Prez Mantilla Duarte Nombre Rosa Carlos Andrs Carmen Omar Luis Javier Nubia Miguel Felipe Dpt Cat. Enlace A B A C A A B A B C 3 4 1 2 1 1 2 4 3 5 8 3 4 10 6 7 # 9 2 5
Un archivo con organizacin relativa se puede procesar en forma secuencial o en forma directa
24
Al procesar un archivo en forma directa surgen tres inconvenientes: 1. Cmo conocer previamente la direccin relativa? 2. Casi nunca el valor de una clave principal tendr relacin con su direccin relativa. 3. Habra que transformar el valor de la clave principal en su direccin relativa, y el de sta en su direccin absoluta.
25
Para convertir el valor de la clave principal en direccin relativa, los mtodos ms usados son: a) Direccionamiento directo b) Direccionamiento por tablas c) Direccionamiento por algoritmos (hashing)
26
a) Direccionamiento directo
D. relativa 1 2 3 4 5 Cdula (Clave principal) 1012 1013 1014 1015 1016
D. Relativa = clave principal clave ms pequea + 1 Problema: Casi nunca las claves principales son valores consecutivos
27
b) Direccionamiento por tablas

Clave principal 1000 1037 1039 1050 1078 D. relativa 5 2 9 7 10
Problema: No es prctico mantener la tabla en orden lgico
28
c) Direccionamiento por algoritmos. Los pasos son:

Primero Convertir la clave principal en valor numrico Segundo Aplicar un algoritmo de transformacin para obtener un valor del mismo orden que el nmero de registros Tercero Ejemplo Multiplicar por un factor para obtener una direccin relativa permitida dentro del rango [0, # de registros] Aplicando un algoritmo como el de la divisin, a un archivo de 20.000 registros:
Clave principal = 1.897642.159 N de registros = 20.000 Factor (k) = 0.2 (k=20.000/99.999) Primo prximo al nmero de registros = 19.997 1.897642.159 19.997 = 94.896,340.2 = 18.979,2 Direccin relativa = 18979 Los sinnimos se guardan por separado en un rea de overflow
29
2.4 Organizacin directa (DAM).
Los registros no se almacenan, ni por clave, ni por direccin relativa, sino por direcciones absolutas, o sea direcciones de bloque en el disco.
30
2.5 Organizacin secuencial indexada (ISAM)

Archivo de ndices
Dir. rel. 1 2 3 4 5 6 7 8 9 10 Cdula 1234 1295 1486 1893 2345 3030 3827 4567 5667 6781 Enlace 2 3 4 5 6 7 8 9 10 # Puntero 1 8 9 2 3 4 10 5 6 7 Dir. rel. 1 2 3 4 5 6 7 8 9 10 Cdula 1234 1893 2345 3030 4567 5667 6781 1295 1486 3827
Archivo de datos
Apellido Serrano Peralta Gmez Durn Rico Flrez Peralta Prez Mantilla Duarte Nombre Rosa Carlos Andrs Carmen Omar Luis Javier Nubia Miguel Felipe Dpt A B A C A A B A B C Cat. 3 4 1 2 1 1 2 4 3 5
31
Archivo secuencial indexado con una insercin

Archivo de ndices
Dir. rel. 1 2 3 4 5 6 7 8 9 10 11 Cdula 1234 1295 1486 1893 2345 3030 3827 4567 5667 6781 2500 Enlace 2 3 4 5 6 7 8 9 10 # 6 Puntero 1 8 9 2 3 4 10 5 6 7 11 Dir. rel. 1 2 3 4 5 6 7 8 9 10 11 Cdula 1234 1893 2345 3030 4567 5667 6781 1295 1486 3827 2500
Archivo de datos
Apellido Serrano Peralta Gmez Durn Rico Flrez Peralta Prez Mantilla Duarte Mantilla Nombre Rosa Carlos Andrs Carmen Omar Luis Javier Nubia Miguel Felipe Diana Dpt A B A C A A B A B C D Cat. 3 4 1 2 1 1 2 4 3 5 1
Archivo secuencial indexado simple y con ndices completos

32
Archivo de datos Archivo de ndices de primer nivel

Dir. rel. 1 2 3 4 5 6 7 Cdula 1295 1893 2472 2800 3827 5667 6781 Enlace 2 3 4 5 6 7 # Puntero 15 9 20 14 4 5 19
Dir. rel. 1 2 3 4 5 6 7 8 9 10 11 12 13 Cdula 1234 1893 2345 3030 4567 5667 6781 1295 1486 3827 2500 1621 2472 2485 1190 5000 2800 3500 6500 2000 Apellido Serrano Peralta Gmez Durn Rico Flrez Peralta Prez Mantilla Duarte Mantilla Lpez Serrano Plata Manzur Mantilla Rincn Correa Echeverry Marn Nombre Rosa Carlos Andrs Carmen Omar Luis Javier Nubia Miguel Felipe Diana Julio Miguel Mara Helga Felipe Patricio Daro Esperanza La Dpt A B A C A A B A B C D A A B C A B C B D Cat. 3 4 1 2 1 1 2 4 3 5 1 5 3 5 2 2 2 3 3 4 Enlace 8 20 13 18 16 19 # 9 12 5 17 2 14 11 1 6 4 10 7 3
Archivo de ndices de segundo nivel

Dir. rel. 1 2 3 Cdula 2472 5667 6781 Enlace 2 3 # Puntero 1 4 7
14 15 16 17 18 19 20
Archivo secuencial indexado compuesto y con ndices escasos

33
Transaccin
Valida y actualiza
Archivo ISAM
Actualizacin de archivos ISAM

Correccin Digitacin Trascripcin Transaccin Si Si No Prevencin Si No No
De los errores al actualizar archivos ISAM

(Lo cual se haca en lnea)
34
3. Organizacin de archivos para DBMS

Con los archivos bsicos solo es posible el acceso directo si se conoce una clave principal. organizaciones bsicas de archivos. Un DBMS permite establecer acceso por claves mltiples en uno o varios archivos. Un DBMS emplea las siguientes organizaciones de archivos: a) Organizacin inversa b) Organizacin multilista c) Organizacin multianillo
35
Buscar acceso por claves mltiples, es difcil con las
3.1 Organizacin inversa

D. R. 1 2 Cdula 5000 6500 Enlace 2 # Puntero 1 4 D. R. 1 2
Archivo de nombres
Nombre Departamento Categora Enlace 2 # Puntero 1 5
Archivo de ndices de primer nivel

D. R. 1 2 3 4 Cdula 1893 3030 5000 6500 Enlace 2 3 4 # Puntero 1 4 7 10 D.R. 1 2 3 4 5 6 7 8
Archivo de valores
Valor A B C D 1 2 3 4 Enlace 2 3 4 5 6 7 8 # 2 3 1 5 5 1 2 3
Contina en la siguiente diapositiva
punteros 4 10 6 7 8 9
8 6 4 9 7 10
36
Archivo de datos
D. R. 1 2 3 4 5 6 7 8 9 10 Cdula 1190 1234 1893 2472 2500 3030 3500 4567 5000 6500 Apellido Manzur Serrano Peralta Serrano Mantilla Durn Correa Rico Mantilla Echeverry Nombre Helga Rosa Carlos Miguel Diana Carmen Daro Omar Felipe Esperanza Dpto. C A B A D C C A A B Cat. 2 3 4 3 1 2 3 1 2 3 Enlace 2 3 4 5 6 7 8 9 10 #
37
Archivo con organizacin inversa con una insercin

Archivo de nombres

Archivo de valores
Valor A B C D 1 2 3 4 Enlace 2 3 4 5 6 7 8 # 2 3 1 5 5 1 2 3 8 6 4 11 38 9 7 10 punteros 4 10 6 8 11 7 9
Archivo de datos
D. R. 1 2 3 4 5 6 7 8 9 10 11 Cdula 1190 1234 1893 2472 2500 3030 3500 4567 5000 6500 9876 Apellido Manzur Serrano Peralta Serrano Mantilla Durn Correa Rico Mantilla Echeverry Nstor Nombre Helga Rosa Carlos Miguel Diana Carmen Daro Omar Felipe Esperanza Surez Dpto. C A B A D C C A A B B Cat. 2 3 4 3 1 2 3 1 2 3 4 Enlace 2 3 4 5 6 7 8 9 10 11 #
Archivo con organizacin inversa despus de insertar un nuevo registro

39
Archivo con organizacin inversa con una eliminacin

Archivo de nombres

Archivo de valores
punteros 4 10 6 7 8 9
8 6 4 9 7 10
40
Archivo de datos
D. R. 1 2 3 4 5 6 7 8 9 10 Cdula 1190 1234 1893 2472 2500 FFFF 3500 4567 5000 6500 Apellido Manzur Serrano Peralta Serrano Mantilla Durn Correa Rico Mantilla Echeverry Nombre Helga Rosa Carlos Miguel Diana Carmen Daro Omar Felipe Esperanza Dpto. C A B A D C C A A B Cat. 2 3 4 3 1 2 3 1 2 3 Enlace 2 3 4 5 6 7 8 9 10 #
Archivo con organizacin inversa despus de eliminar un registro

41
Archivo con organizacin inversa con una modificacin

Archivo de nombres

Archivo de valores
punteros 4 10 6 8 7 7 9
8 6 4 9 7 10
42
Archivo de datos
D. R. 1 2 3 4 5 6 7 8 9 10 Cdula 1190 1234 1893 2472 2500 3030 3500 4567 5000 6500 Apellido Manzur Serrano Peralta Serrano Mantilla Durn Correa Rico Mantilla Echeverry Nombre Helga Rosa Carlos Miguel Diana Carmen Daro Omar Felipe Esperanza Dpto. C A B A D C B A A B Cat. 2 3 4 3 1 2 3 1 2 3 Enlace 2 3 4 5 6 7 8 9 10 #
Archivo con organizacin inversa despus de modificar un registro

43
D. R. 1 2 3 4 5 6 7 8 9 10
Valor A A B C D 1 2 3 3 4
Enla ce 2 3 4 5 6 7 8 9 10 # 2 9 3 1 5 5 1 2
Punteros 4 10 6 8 6 4 9 7 7 8
Bandera S N N N N N N S N N
10 3
Archivo de valores con registros de longitud fija para una organizacin inversa
44
3.2 Organizacin multilista

Archivo de nombres

Archivo de valores
Valor A B C D 1 2 3 4 Enlace 2 3 4 5 6 7 8 # Punteros 2 3 1 5 5 1 2 3 Contador 4 2 3 1 2 3 4 1 45
Archivo de datos
D. R. 1 2 3 4 5 6 7 8 9 10 Cdula 1190 1234 1893 2472 2500 3030 3500 4567 5000 6500 Apellido Manzur Serrano Peralta Serrano Mantilla Durn Correa Rico Mantilla Echeverry Nombre Helga Rosa Carlos Miguel Diana Carmen Daro Omar Felipe Esperanza Dpto. C A B A D C C A A B Cat. 2 3 4 3 1 2 3 1 2 3 Enlace 2 3 4 5 6 7 8 9 10 # Enla ce D 6 4 10 8 # 7 # 9 # # Enla ce C 6 4 # 7 8 9 10 # # #
46
El archivo de datos en una organizacin multilista tiene un apuntador por cada clave secundaria, que apunta al siguiente registro que la cumple. El contador del archivo de valores en una organizacin multilista es usado por el DBMS para procesar consultas por claves mltiples con el operador AND, pues comenzando por el contador ms pequeo minimiza la bsqueda. Con el operador OR utiliza una tabla de referencia adicional en donde va guardando los registros que cumplen, en las diferentes sublistas, la condicin de las claves en forma simultnea.
Dir. Relat. del registro 8 Enlace de categora #
Tabla de referencia para consulta de departamento = A OR categora = 1

47
3.3 Organizacin multianillo Un anillo es una lista enlazada en donde el ltimo nodo se encadena con el primero
A B C D
Para bsquedas en ambas direcciones se necesita un apuntador adicional que contenga la direccin del nodo anterior. As el primer nodo se encadena con el ltimo
A B C D
48
1234
2472
4567
5000
1893
6500
1190
3030
3500
2500
Archivo con organizacin multianillo

49
Transaccin
Valida y actualiza
Base de datos
Actualizacin de una Base de datos
Correccin Digitacin Trascripcin Transaccin Si Si Si
Prevencin Si Si Si
De los errores al actualizar una Base de datos

(Lo cual se suele hacer en tiempo real)
50
4. Niveles de una Base de datos

Nivel externo Esquema Vista de c/usuario externo
Esquema externo Esquema externo
Nivel conceptual Vista de todos los usuarios
Esquema conceptual
Nivel interno Vista del sistema operativo
Esquema interno
51
4.1 Nivel interno de una Base de datos Est constituido por el conjunto de bloques de disco, con sus diferentes registros y sus respectivas direcciones, apuntadores, contadores y datos. El nivel interno es el que toca al sistema operativo (el servidor del disco) y a la tarjeta controladora del disco, por lo cual es un esquema fsico binario, en la intimidad del hardware.
52
4.2 Nivel conceptual de una Base de datos Es el que corresponde a la percepcin de datos comn a todos los usuarios de una organizacin. Por lo tanto se ve como un conjunto universal de entidades vinculadas entre si, y cada una con sus propios atributos. La apariencia de este nivel salta a la vista aunque no tiene existencia fsica.
53
4.3 Nivel externo de una Base de datos Es el que corresponde a la percepcin de datos que individualmente o en grupo tienen los usuarios de una misma rea funcional de una empresa. Es una vista o subconjunto del conjunto universal, que describe nicamente la parte de los datos de inters para cada usuario y que tampoco tiene existencia fsica. Cada vista puede omitir uno o ms registros, atributos o relaciones del esquema conceptual, o tambin cambiar su orden. A diferencia de los otros esquemas, el esquema externo es mltiple.
54
4.4 Mapeo de datos La existencia de tres niveles impone al DBMS la necesidad de transformar los datos de un formato a otro. Existiendo tres niveles, existirn dos formatos de transformacin: Conceptual-interno y conceptualexterno. Tanto el formato conceptual-interno como el conceptual-externo opera en los dos sentidos: De lo conceptual a lo interno y viceversa, y de lo conceptual a lo externo y viceversa. El DBA debe indicar la correspondencia entre formatos mediante las reglas de correspondencia (mapping rules)
55
5. Propiedades de una Base de datos

5.1 Independencia de los datos. Es la capacidad de modificar los esquemas interno o conceptual sin causar cambios en los programas (que usan esquemas externos). La independencia entre lo externo y lo interno se llama Independencia fsica y, entre lo externo y lo conceptual Independencia lgica La independencia lgica sirve para el mantenimiento pero fomenta la separacin entre la estructura y la funcionalidad organizacional.
56
5.2 Seguridad. Los datos deben estar protegidos contra accesos no autorizados, y adems reservados en diferentes rangos de permisividad para accesos autorizados. 5.3 Integridad. Los datos, apuntadores, direcciones, enlaces, ndices y contadores, deben mantenerse siempre incorruptibles. La corrupcin puede aparecer por fallas del hardware, defectos del software, actualizaciones incompletas o invlidas, o la violacin a las reglas de integridad referencial.
57
5.4 Respaldo y recuperacin. Es la facilidad para obtener copias de la Base de datos (backups de respaldo) que permitan recuperar la Base de datos ante cualquier falla. 5.5 Control de redundancia. Es la propiedad por medio de la cual, la repeticin de datos es mnima y es controlable. El proceso de normalizacin busca precisamente reducir al mximo la redundancia de datos, aunque nunca al 100%
58
5.6 Consistencia. Es la propiedad que impide las contradicciones entre datos. Si la redundancia estuviera descontrolada, un mismo dato repetido en lugares diferentes podra tener valores diferentes, y por tanto inconsistentes. 5.7 Auditora. Es el examen de la Base de datos y su entorno, a fin de comprobar que se ajusta a lo establecido. Este examen no es solo a posteriori sino que tambin es a priori
59
5.8 Control de concurrencia. Es la capacidad para ejercer un riguroso control en la ejecucin simultnea de transacciones con el fin de proteger la consistencia de las actualizaciones y consultas a la Base de datos. Veamos lo que ocurrira si no hubiese control de concurrencia. Supongamos en un banco, la ejecucin simultnea de una transaccin de consignacin de un cheque de 100 (T1) en una ventanilla, y una transaccin de retiro de 50 en efectivo (T2) en otra ventanilla. Los pasos que se sucederan en Ram se muestran en la siguiente diapositiva.
60
Registro inicial
Tiempo
t=0
SAL CON RET 200 0 0 T2 Lea cuentas RET = RET 50 Regrabe cuentas
T1 Lea cuentas
CON = CON + 100 Regrabe cuentas

t=n
Registro final SAL CON RET 200 100 0

61
Observamos que el saldo en el sistema es de 300 (SAL = SAL + CON RET), mientras que el saldo real debe ser 250. Para evitar estas inconsistencias los DBMS conforman sus transacciones atmicamente por medio de seguros (locks) y puntos de sincronizacin (commit/rollback). 5.9 Rutas de acceso. Es la facilidad para obtener diferentes rutas de acceso, por medio de claves primarias y secundarias, pudiendo obtener respuesta a diferentes consultas aplicando diversos criterios de bsqueda.
62
6. Software complementario de un DBMS

Para poder llevar a cabo su funcin en forma ptima, un DBMS se apoya en: 6.1 Un administrador de la Base de datos (DBA) 6.2 Un diccionario de datos 6.3 Lenguajes de la Base de datos
63
6.1 El administrador de la Base de datos (DBA). El DBA es la persona o equipo de personas que se encarga de mantener en regla el entorno de una Base de datos (BD), para lo cual utiliza el siguiente software: a) b) c) d) e) f) De carga para crear inicialmente la BD. De reorganizacin de la BD (para liberar espacio). De registro de transacciones en bitcora (log). De recuperacin despus de un fallo. De anlisis de estadsticas de desempeo. De manejo de autorizaciones de acceso.
64
6.2 El diccionario de datos. El diccionario de datos es el conjunto de datos que describen la BD, y contiene: a) La descripcin de todos los esquemas (Externo, conceptual e interno). b) La descripcin de todos los campos (o atributos), registros (o tuplas) y referencias cruzadas entre las tuplas de varios archivos (o tablas, varrels o entidades). c) Los cdigos de autorizacin y seguridad de los datos y sus redefiniciones con las que puedan ser referidos con nombres diferentes en programas diferentes.
65
6.3 Lenguajes de una Base de datos. Estos lenguajes permiten primero (DDL) describir, y despus (DML) manipular o sea consultar y actualizar la BD. Adems proporcionan interfaces con lenguajes de programacin como Cobol, PL/1, Fortran, C, o Java, ya que los lenguajes de BD no son por si mismos de programacin, excepto por los PSM o mdulos almacenados persistentes.
6.3.1 DDL. Con este leguaje nos valemos para describir los esquemas conceptual y externo. El compilador DDL al compilar los esquemas produce el diccionario de datos y los esquemas conceptual y externo. 6.3.2 DML. Con DML nos valemos para insertar, modificar, borrar o seleccionar tuplas o atributos de una BD.
66
Las solicitudes en DML son precompiladas (o interpretadas) resultando cdigo de tercera generacin (en Cobol, PL/1, Fortran, C, Java,). Existen dos tipos de DML: a) Procedimental, con el cual el usuario especifica al DBMS, qu quiere y cmo debe hacerlo. b) No procedimental, con el cual el usuario nicamente especifica lo que quiere. SQL es un lenguaje de 4 generacin o sea 4GL (en realidad conformado por DDL y DML), por ser no procedimental. Inicialmente SQL era un sublenguaje pero con la incorporacin de los PSM (Persistent Stored Modules) en 1996, ahora es un lenguaje ms completo. Por lo tanto ya no hay necesidad de combinar SQL con algn lenguaje anfitrin.
67
7. Clases de DBMSs.
Hasta el da de hoy ha habido cuatro clases de DBMS: Jerrquicos, en Red, Relacionales y de Objetos. Los dos primeros ya han quedado obsoletos, mientras que el modelo relacional se mantiene en vigor todava. Hasta la fecha el modelo de objetos no es ms que una extensin del modelo relacional. Sin embargo, el modelo semntico contiene al modelo relacional, y sin ste, el semntico no existira.
68
7.3 El enfoque relacional. El enfoque relacional, sin lugar a dudas, es el fundamento de la tecnologa moderna de BD, y lo que hace que este campo sea una ciencia. El modelo relacional se ocupa de tres aspectos principales: Su estructura, La manipulacin de datos, La integridad. De aqu en adelante, toda la teora de este curso har referencia exclusiva al enfoque relacional.
69
8. El modelo relacional de Bases de datos

El modelo relacional ha evolucionado a partir de lo publicado por Edgar Frank Codd en 1970. El modelo relacional no opera sobre registros individuales como los lenguajes de programacin, sino sobre relaciones completas Las relaciones del modelo relacional equivalen a los archivos de los lenguajes de programacin, a las tablas de SQL, a las entidades del modelo semntico, o a los objetos de los actuales modelos de objetos.
70
De acuerdo a las recomendaciones ANSI/SPARC, el modelo est conformado por las siguientes partes: el nivel conceptual, el nivel externo, el nivel interno y el lenguaje de datos. 8.1 Nivel conceptual. Est representado por todo el conjunto de tablas descritas en SQL, cada una de las cuales tiene existencia por si sola, y se traducen en un archivo almacenado a nivel fsico. C. J. Date diferencia una tabla de una varrel. La sentencia SQL para crear una tabla es create table cuyo formato se observa en la siguiente diapositiva.
71
create table nombre-tabla (nom-col1 tipo-dato [not null] tipo-dato [not null] [, nom-col2 [, primary key (nom-col1 [, nom-col2] ) [, foreign key (nom-col-ajena1) references tabla-objetivo1 [, foreing key (nom-col-ajena2) references tabla-objetivo2 ); Ejemplo: Supongamos las relaciones S (proveedores), y P (partes), en donde un proveedor puede haber suministrado varias partes, y una parte puede haber sido suministrada por varios proveedores. Estas tablas (con los mismos datos) sern utilizadas durante todo el curso.
72
S
S# snombre edo 20 10 30 20 30 ciudad Londres Pars Pars Londres Atenas S1 Salazar S2 Jaimes S3 Bernal S4 Corona S5 Aldana
SP
S# S1 S1 S1 S1 S1 S1 S2 pnombre Tuerca Perno Birlo Birlo Leva Engrane color Rojo Verde Azul Rojo Azul Rojo peso 12 17 17 14 12 19 ciudad Londres Pars Roma Londres Pars Londres
73
P# P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 P4 P5
cant 300 200 400 200 100 100 300 400 200 200 300 400
P
P# P1 P2 P3 P4 P5 P6
S2 S3 S4 S4 S4
Cuando una asociacin es muchos a muchos como se ve en lo subrayado atrs (las reglas del negocio), se requiere una tercera relacin adems de las relaciones S y P, para poder averiguar los proveedores que han suministrado cada parte, y las partes que han sido suministradas por cada proveedor. En este caso, como las reglas del negocio estn en pasado, la historia de envos, SP, puede satisfacer el requisito en cuestin. De este modo, la asociacin entre S y SP es uno a muchos, y entre P y SP uno a muchos tambin. La creacin en SQL de estas tablas est en la siguiente diapositiva.
74
create table S (s# char(2) not null, snombre char(10) not null, edo smallint not null, ciudad char(10) not null, primary key (s#)); create table P (p# char(2) not null, pnombre char(10) not null, color char(10) not null, peso smallint not null, ciudad char(12) not null, primary key (p#)); create table SP (s# char(2) not null, p# char(2) not null, cant integer, primary key (s#, p#), foreign key (s#) references S, foreign key (p#) references P);
75
Null es algo indefinido que no es igual a nada, no es igual a cero, no es igual a blanco, ni siquiera es igual a null. Por ejemplo, s# y p# deben tener valores definidos o si no sern rechazados, pero cant debe ser null para cuando no se conozca la cantidad enviada. Para modificar una tabla ya existente, est la sentencia alter table. Si queremos agregar una columna, la sentencia tendra la forma alter table nombre-tabla add nom-col tipo-dato; Ejemplo: alter table S add descuento smallint;
76
Al aadir a la tabla S el atributo descuento, S crece en lo conceptual, pero el nuevo atributo ser nulo, pues esta sentencia no permite especificar not null. Crecer en lo conceptual significa que la expansin de los registros no se da en lo fsico sino que solo se modifica su descripcin en el diccionario de datos. Al introducir un nuevo proveedor s crecer fsicamente, excepto que su descuento siga siendo nulo. Tambin se puede alterar una tabla eliminando o modificando columnas. Una tabla se puede eliminar con drop table que tiene el formato: drop table nombre-tabla;
77
8.2 Nivel externo: vistas. En este nivel la BD se percibe como una vista externa propia, o escenario particular a cada usuario. Una vista se crea en SQL con la sentencia create view cuyo formato es create view nombre-vista [(columna [, columna] )] as select columna [,columna] from nombre-tabla where condicin Una vista no existe fsicamente pero en el diccionario de datos si est guardada su definicin. Una vista es un subconjunto de una tabla.
78
Ejemplo: Obtener la vista de la tabla P cuyas partes sean de color rojo.

create view partes_rojas (codigo, nombre, peso, ciudad) as select p#, pnombre, peso, ciudad from P where color = rojo;
Por medio de las vistas se logra la independencia lgica de los datos. Adems permiten a diferentes usuarios ver los mismos datos, de distintas maneras, al mismo tiempo. Finalmente, las vistas protegen los datos, pues los no visibles para un usuario, estn a salvo de accesos indebidos.
79
Una vista se puede borrar del diccionario de datos mediante la sentencia drop que tiene el siguiente formato: drop view nombre-vista 8.3 Nivel interno: ndices. Con las sentencias SQL create index y drop index se crea y se destruye ndices, pero stas son las nicas sentencias que los manejan, pues los DBMS relacionales lo hacen en forma automtica. La sintaxis de la sentencia create index es: create [unique] index nombre-ndice on nombre-tabla (columna [orden] [,columna [orden]]) [cluster] En donde el orden puede asc (ascendente) o desc (descendente).
80
La opcin cluster indica que el ndice es de agrupamiento, o sea que los datos para un mismo ndice son reunidos en secuencia fsica igual a la lgica. Ejemplo: create unique index xsp on SP (s#, p# desc) cluster; As se crea el ndice xsp sobre la tabla SP, en el cual las entradas se ordenan segn s# ascendentemente, y segn p# descendentemente. Con unique se asegura que el ndice no se repita. Con la sentencia drop index se destruye un ndice previamente creado. El nivel interno es pues el mismo conjunto de tablas del nivel conceptual, pero almacenadas como archivos indexados.
81
El modelo relacional permite as crear, alterar y destruir tablas, vistas e ndices, en cualquier momento, pues es muy tolerante. 8.4 El lenguaje de datos. SQL incluye tanto sentencias de especificacin o descripcin de datos (DDL), como sentencias de manipulacin (DML). SQL tiene fundamentos del lgebra relacional por lo cual en algunos aspectos es procedimental. Tambin del clculo relacional por lo cual en otros aspectos es no procedimental. De ah que para continuar con SQL, sea necesario estudiar lgebra relacional y clculo relacional.
82
9. lgebra relacional
El lgebra relacional deriva del lgebra de conjuntos, por lo cual consta de operandos (que son relaciones) y operaciones sobre relaciones. Cada operacin produce siempre como resultado una nueva relacin y la relacin resultado se puede someter a nuevas operaciones. Las operaciones del lgebra relacional se clasifican en tres categoras: a) Operaciones de conjunto (unin, diferencia, y producto cartesiano). b) Operaciones unarias (proyeccin y seleccin). c) Operaciones adicionales (reunin, interseccin, y divisin). 83
9.1 Operaciones de conjunto. Estas operaciones son binarias ya que operan sobre dos relaciones para producir una tercera relacin. Unin. Construye una relacin formada por todas las tuplas que aparecen en cualquiera de las dos relaciones A y B especificadas. Se puede denotar como A U B, o A unin B.
Lo sombreado es A U B A B
84
Ejemplo
A S# s1 s4 B S# s1 s2
snombre Salazar Corona
edo 20 20
ciudad Londres Londres
snombre Salazar Jaimes
edo 20 10
ciudad Londres Pars
AUB S# snombre s1 s2 s4 Salazar Jaimes Corona
edo 20 10 20
ciudad Londres Pars Londres

85
Diferencia. Construye una relacin formada por todas las tuplas de la primera relacin A que no aparezcan en la segunda B, de las dos relaciones especificadas. Se denota A B
A B Lo sombreado es A - B
86
Ejemplo
A S# s1 s4 B S# s1 s2
snombre Salazar Corona
edo 20 20
ciudad Londres Londres
snombre Salazar Jaimes
edo 20 10 B-A S# s2
ciudad Londres Pars
A-B S# s4
snombre Corona
edo 20
ciudad Londres
snombre Jaimes
edo 10
ciudad Pars
87
Producto cartesiano. Construye una relacin a partir de dos relaciones A y B especificadas, que contiene todas las combinaciones posibles de tuplas de cada relacin. Se denota A x B o A times B
AxB ax B x y ay bx by cx cy
A a b c
88
Ejemplo. Sean las relaciones S y P de la diapositiva 71. S x P es:

SxP S#... P#... s1p1 s1 p2 s1 p3 s1 p4 s1 p5 s1 p6 s2... p1 s2 p2 s2 p3 s2 p4 S x P continuacin s2 p5 s2 p6 s3 p1 s3 p2 s3 p3 s3 p4 s3 p5 s3 p6 s4 p1 s4 p2 s4 p3 S x P continuacin s4 p4 s4 p5 s4 p6 s5 p1 s5 p2 s5 p3 s5 p4 s5 p5 s5 p6
S y P deben ser disyuntos (sin atributos comunes) por lo que se debe renombrar primero la ciudad en S o en P as: S rename ciudad as sciudad;
89
9.2 Operaciones unarias. Las operaciones unarias se realizan sobre una relacin y dan como resultado una nueva relacin. Proyeccin. Extrae los atributos especificados de una relacin A dada, eliminando los duplicados. Se denota A[x, y] o x, y
A u x v y w
Lo sombreado es la proyeccin sobre x y y, A[x, y] A[u, x, v, y, w] da la proyeccin identidad. A[ ] da la proyeccin nula
90
Ejemplo
S[ciudad] ciudad Londres Pars Atenas P[color, ciudad] color rojo verde azul azul ciudad Londres Pars Roma Pars
91
Seleccin. Extrae las tuplas especificadas de una relacin A dada, que cumple la condicin. Se denota con where condicin o condicin
A Lo sombreado es la seleccin A where condicin
Ejemplo1, S where ciudad = 'Londres'

S S# s1 s4 snombre Salazar Corona edo 20 20 ciudad Londres Londres
92
Ejemplo2, P where peso < 14

P# p1 p5 pnombre Tuerca Leva color Rojo Azul peso 12 12 ciudad Londres Pars
Ejemplo3, SP where s# = ' s1 ' and p# = ' p1 '

S# P# s1 p1 cant 300
A where c1 and c2 equivale a A where c1 or c2 equivale a A where not c equivale a
(A where c1)(A where c2) (A where c1)U(A where c2) A (A where c)

93
9.3 Operaciones adicionales. Son operaciones complementarias que ayudan a simplificar algunas consultas. Reunin (join). Toma dos relaciones que tengan en comn una o ms columnas y crea una nueva relacin concatenando tuplas que coincidan en un mismo valor en una determinada columna. La operacin join realiza el producto cartesiano especificando una condicin, o sea SxPcondicin = S join P Cuando la condicin es diferente a la igualdad, el join se conoce como reunin y se denota S x P, siendo la condicin.
94
Cuando la condicin expresa igualdad, el join se llama equireunin. Si a la equireunin se le suprimen las columnas iguales, se llega al producto natural que se denota S * P Si en el producto natural las relaciones no tienen ningn campo en comn, S * P = S x P El producto natural es tan importante que en general S join P se toma S * P
a1 a2 a3 b1 b1 b2 b1 c1 c2 c3 a1 b1 b1 b2 c1 c1 c2
b2 b3
a2 a3
95
Ejemplo: S join P
s# s1 s1 s1 s2 s2 s3 s3 s4 s4 s4 snombre edo Salazar Salazar Salazar Jaimes Jaimes Bernal Bernal Corona Corona Corona 20 20 20 10 10 30 30 20 20 20 ciudad P# pnombre Tuerca Birlo Engrane Perno Leva Perno Leva Tuerca Birlo Engrane color peso Rojo Rojo Rojo Verde Azul Verde Azul Rojo Rojo Rojo 12 14 19 17 12 17 12 12 14 19 Londres p1 Londres p4 Londres p6 Pars Pars Pars Pars p2 p5 p2 p5
Londres p1 Londres p4 Londres p6
96
Interseccin. Construye una relacin con las tuplas comunes a las dos relaciones especificadas A y B. Se denota como A B o A intersect B
Lo sombreado es A B o A intersect B
Ejemplo: Si A y B son las relaciones del la diapositiva Su interseccin es

AB s# s1 snombre Salazar edo 20 ciudad Londres
83
97
Comprobar que A B = A (A B) = A join B, si los atributos de A y B son comunes. Si no son comunes, A join B = A x B. Divisin. Sea A de grado m+n (m+n columnas) y B de grado n. La divisin entre A y B es el conjunto de tuplas (cociente) de m columnas que concatenadas con las tuplas de B producen tuplas contenidas en A.
A a a a b c
x y z x y
98
B x z
AB a
Si A es de grado m+n, y B de grado n, y tomando la relacin T = A[1,2,,m], la divisin tambin se puede expresar en funcin de la proyeccin, el producto cartesiano, y la diferencia, as: T = ((T x B) A)[1,2,,m] = A B Ejemplo1: Sea el dividendo A = SP[s#, p#], para los sucesivos divisores mostrados en la siguiente diapositiva, los respectivos cocientes son:
99
B A s# p# s1 s1 s1 s1 s1 s1 s2 s2 s3 s4 s4 s4 p1 p2 p3 p4 p5 p6 p1 p2 p2 p2 p4 p5 B p# p2 p4 B p# p1 p2 p3 p4 p5 p6 p# p1
AB s# s1 s2 AB s# s1 s4
AB s# s1
100
Ejemplos. Las tablas estn en

1 Calcular S join SP join P
71
2 Obtener el cdigo de los proveedores de Pars cuyo estado sea > 20. 3 Obtener los nombres de los proveedores que suministran la parte p2 4 Obtener los nombres de los proveedores que suministran todas las partes. 5 Obtener los nombres de los proveedores que no suministran la parte p2. 6 Obtener todas las parejas de nmeros de proveedor, digamos sx y sy, tales que suministren cada una, el mismo conjunto de partes.
101
7 Calcular la siguiente expresin algebraica

(((SP[s#,p#]) rename s# as sx) ((SP[p#,s#]) rename s# as sy) (((SP[s#,p#]) rename s# as sy) ((SP[p#,s#]) rename s# as sx)
Ejercicios. Las tablas estn en
71
1 Obtener los nombres de los proveedores y su ciudad, cuyo estado es < 20. 2 Obtener los nombres de las partes cuyo color sea azul, o se almacenen en Roma. 3 Obtener los nombres de las partes cuyos envos hayan sido inferiores a 200 unidades. 4 Listar los nombres de los proveedores que hayan suministrado alguna parte, indicando los nombres de las partes, excepto la parte p2. 102
5 Listar los nombres de los proveedores que no hayan suministrado la parte p2, pero si alguna otra parte. 71 6 Listar los nombre de los proveedores que no hayan suministrado la parte p2. 7 Listar los nombres de las partes suministradas por todos los proveedores 7 Listar los nombres de los proveedores que suministran todas las partes 8 Listar el color y el nombre de las partes que no hayan sido an suministradas por algn proveedor. 9 Obtener los envos mayores de 200, indicando el nombre del proveedor, el nombre de la parte y la ciudad desde donde se ha hecho el despacho.
103
CodigoA 05600 05700 06078 06150 07100 07203 07301
NombreA Rueda Durn Gmez Surez Lpez Prez Ardila
Cred 180 130 180 150 120 160 120
Carrera Civil Elctrica Petrleos Elctrica Sistemas Sistemas Civil
104
CodigoM NombreM 1436 Fsica 1520 Clculo 1670 Ondas 1700 Historia 1745 Mecnica 1815 Qumica 1820 Algebra
Cred Requisito 8 120 12 120 8 180 6 0 10 180 10 30 12 0
105
CodigoM Horario CodigoA 1520 A1 05700 1520 A1 07100 1670 H1 05600 1670 H1 06078 1700 D1 05600 1700 D1 07203 1815 J1 06078 1815 J2 07100 1815 J2 07301 1820 E1 06150 1820 E1 07100
Nota 4.7 3.9 3.9 3.6 3.8 5.0 4.7 4.8 2.8 4.0 4.1
106
10 Sean las relaciones A (alumnos), M (materias), C (cursos) mostradas en las anteriores diapositivas: Obtener el cdigo y el nombre de los estudiantes de Sistemas que tengan ms de 120 crditos. 11 Obtener el cdigo y el nombre de los estudiantes que estn viendo clculo. 12 Obtener el cdigo y el nombre de los estudiantes que no estn viendo historia. 13 Listar las notas de los diferentes estudiantes indicando el nombre de la materia, y el cdigo del estudiante y su nombre. 14 Obtener el cdigo y el nombre de los estudiantes que estn viendo todas las materias. 15 Obtener el cdigo y el nombre de las materias cursadas por todos los estudiantes.
107
10. Clculo relacional

Siendo el clculo relacional no procedimental, las operaciones para obtener un relacin deseada a partir de relaciones ya existentes, son implcitas a su notacin. As por ejemplo, para obtener los nombres de los proveedores que suministran la parte p2 (problema #3), una expresin de clculo formula algo como: Obtener el snombre de los proveedores para los cuales exista un envo sp con el mismo valor en s# y con el valor de p2 en p#. En cambio, algebraicamente, este problema exiga explicitar una serie de pasos (un procedimiento) consistente en: primero un join entre S y SP, segundo la seleccin de las tuplas de la parte p2, y tercero la proyeccin del resultado sobre snombre. 108
Note que en clculo, el usuario se limita a expresar las caractersticas que definen el resultado deseado, tocndole al sistema decidir exactamente cules operaciones ejecutar para construir el resultado. Mientras el clculo solo plantea el problema, el lgebra proporciona un procedimiento para resolver ese problema. Una expresin de clculo relacional (de tuplas), tiene la forma {t/P(t)} la cual se lee el conjunto de tuplas t tal que el predicado P se cumple para t. El predicado es la expresin del criterio de seleccin en la recuperacin de los datos. Una expresin se forma con variables (de tuplas), condiciones y cuantificadores.
109
10.1 Variables de tuplas. Son variables que recorren las tuplas de una relacin, las cuales son su nico dominio. Se escriben en minscula (t, u, v, ) y su notacin t[nombre-campo] denota el valor de t en el atributo. Sea t la primera tupla de la relacin S mostrada en la diapositiva 71 . Entonces t[s#] = s1 y t[snombre] = Salazar Tambin vale t[1] para indicar el valor del primer atributo en la tupla dada: t[1] = s1 y t[2] = Salazar. Etc Siendo una relacin un conjunto de tuplas, se utiliza la notacin de conjuntos t S para indicar que la tupla t est en S.
110
10.2 Condiciones de comparacin. Estas comparan componentes de tuplas o tuplas enteras, combinando variables y constantes con operadores de comparacin y aritmticos, dando como resultado el valor verdadero o falso, o nulo. Ejemplo: t[1] > t[2], t[3] = 10, t[1] = t[1] + u[2]. 10.3 Condiciones de pertenencia. Se denotan con la notacin S(t), que significa: Si la tupla t pertenece a la relacin S, entonces la condicin S(t) toma el valor verdadero, y falso en caso contrario. 10.4 Condiciones compuestas. Combinan las condiciones de comparacin y las de pertenencia con los operadores lgicos and, or y not, pudiendo ser el resultado verdadero falso.
111
Ejemplos: (t[1] > t[2]) and (t[3] = 10) (S(t) or (t[1] > 10) 10.5 Cuantificador existencial. Este se representa por t(Q(t)) y significa que existe una tupla t, tal que cumple la condicin Q(t). Toma el valor verdadero si al menos hay una tupla en la que se cumple la condicin, y falso en caso contrario. 10.6 Cuantificador universal. Se representa por _ Vt(Q(t)), que significa que para todas las tuplas t se cumple la condicin Q(t). Si para todos los valores de la variable t se cumple la condicin, el resultado ser verdadero, y falso en caso contrario. E
112
10.7 Expresiones. En general, una expresin en clculo relacional tiene la forma {t/F(t)} en donde F es una frmula bien formada o WFF (Well Formed Formula), la cual se construye con condiciones, operadores lgicos y cuantificadores. Recursivamente se define que: a) Si F es una frmula bien formada, lo es not F b) Si F y G son frmulas bien formadas, tambin lo son (F and G) y (F or G) 10.8 Tipos de variables de tuplas. En una frmula puede haber diversas variables de tuplas que pueden ser: a)Variables libres si no estn ligadas a un cuantificador b) Variables acotadas si estn unidas a un cuantificador.
113
10.9 Ejemplos. Sean sx, sy y sz variables de tuplas que recorren la relacin S, px, py y pz que reocrren P, y spx, spy, y spz que reocrren SP. Ver tablas en diapositiva 71
1) Obtener los nmeros de los proveedores de Pars cuyo estado sea mayor que 20 2) Obtener los nombres de los proveedores que suministran la parte p2 3) Obtener los nombres de los proveedores que suministran todas las partes 4) Obtener los nombres de los proveedores que no suministran la parte p2 5) Obtener los nombres de los proveedores que suministran al menos una parte roja.
114
Problemas. (tablas en
71
1) Obtener los nombres de los proveedores y su ciudad cuyo estado es menor que 20 2) Obtener los nombres de las partes cuyo color sea azul, o se almacenen en Roma 3) Obtener los nombres de las partes con envos inferiores a 200 unidades 4) Listar los nombres de los proveedores que hayan suministrado alguna parte, indicando los nombres de las partes, excepto la parte p2 5) Listar los nombres de los proveedores que no hayan suministrado la parte p2 pero si alguna otra parte 6) Listar los nombres de los proveedores que no hayan suministrado la parte p2
115
7) Listar los nombres de las partes suministradas por todos los proveedores. (Tablas en 71 ) 8) Listar el color y los nombres de las partes que no hayan sido an suministradas por algn proveedor 9) Obtener los envos mayores de 200 indicando el nombre del proveedor, el nombre de la parte, y la ciudad desde donde se ha hecho el despacho 10) Sean las relaciones alumnos A , materias M y cursos C : Obtener el cdigo y el nombre de los estudiantes de Sistemas que tengan ms de 120 crditos. 11) Obtener el cdigo y el nombre de los estudiantes que estn viendo clculo 12) Obtener el cdigo y el nombre de los estudiantes que no estn viendo historia
116
13) Listar las notas de los diferentes estudiantes indicando el cdigo y el nombre del estudiante, as como el nombre de la materia. Tablas en A M C 14) Obtener el cdigo y el nombre de los estudiantes que estn viendo todas las materias 15 Obtener el cdigo y el nombre de las materias cursadas por todos los estudiantes.
117
11. Lenguajes para el manejo de datos: SQL

Si el lgebra y el clculo relacional preparan para el estudio de SQL, SQL prepara y predispone para el estudio de modelar y disear Bases de datos. SQL est constituido por dos grupos de instrucciones: De definicin de datos (DDL) ya estudiadas atrs, y las de manipulacin de datos (DML) SQL ofrece cuatro proposiciones DML para manipular tablas y vistas: Select (seleccionar), Update (actualizar), Delete (eliminar) e Insert (insertar).
118
11.1 Consultas simples. Ante todo, el formato de la instruccin select es el siguiente: select [distinct] atributos from relaciones [where condicin] [group by atributos] [having condicin] [order by atributos]; Ejemplos: 1. Obtener el cdigo y el estado de todos los proveedores de Pars (tablas en 71 ): select s#, edo from S where ciudad = Pars;
119
El ejemplo anterior tambin pudiera haber sido escrito: select S.s#, edo from S where S.ciudad = Pars; Un nombre calificado de campo se compone de un nombre de tabla (o nombre de variable de recorrido) y un nombre de campo, separados por punto (.) 2. Obtener el cdigo de la parte de todas las partes suministradas: select distinct p# from SP;
Probar con y sin la opcin distinct.
120
71
3. Obtener de las partes el cdigo de la parte y su peso en gramos (estando en la tabla el peso en libras y siendo una libra igual a 454 grs.): select P.p#, peso en gramos = , peso*454 from P; 4. Obtener todos los datos de los proveedores: select * from S; tambin select s#, snombre, edo, S.ciudad from S;
121
71
5. Obtener los cdigos de los proveedores de Pars cuyo estado sea mayor que 20: select s# form S where ciudad = Paris and edo > 20;
71
6. Obtener el cdigo y el estado de los proveedores radicados en Pars en orden descendente de estado: select s#, edo from S where ciudad = Paris order by edo desc;
122
7. Obtener de las partes, el nmero de parte y su peso en gramos en orden ascendente por el peso en gramos: select P.p#, peso en gramos = , peso *454 from P 71 order by 3; 11.2 Consultas de reunin. Una reunin ocurre cuando la consulta se obtiene de ms de una tabla: 8. Obtener todo de los proveedores y partes que estn situados en la misma ciudad: select S.*, P.* from S, P where S.ciudad = P.ciudad;
123
En la anterior consulta se repiten las columnas ciudad, por lo que se llama equireunin simple. 9. Obtener de los proveedores el cdigo, el nombre, el estado, y su ciudad, y de las partes el cdigo, el nombre, el color y su peso, donde los proveedores radiquen en la misma ciudad donde se almacena la parte: select s#, snombre, edo, S.ciudad, p#, pnombre, color, peso from S, P 71 where S.ciudad = P.ciudad; En este resultado no se repiten las columnas ciudad, por lo que se llama equireunin natural.
124
10. Obtener todo de los proveedores y partes donde la ciudad del proveedor siga a la ciudad de la parte en orden alfabtico: select S.*, P.* from S, P where S.ciudad > P.ciudad
71
11. Obtener todo de los proveedores y partes que estn en la misma ciudad, pero omitiendo los proveedores cuyo estado sea 20: select S.*, P.* from S, P where S.ciudad = P.ciudad and edo <> 20;
125
12. Obtener todas las parejas de ciudades tal que un proveedor situado en la primera ciudad suministre una parte almacenada en la segunda ciudad: select distinct S.ciudad, P.ciudad from S, SP, P where S.s# = SP.s# and P.p# = SP.p#;
71
13. Obtener todas las parejas de cdigo de proveedor tal que ambos proveedores estn en la misma ciudad: select primera.s#, segunda.s# from S primera, S segunda where primera.ciudad = segunda.ciudad and primera.s# < segunda.s#
126
Las anteriores variables primera y segunda son de recorrido sobre la misma tabla S. Adems, la condicin primera.s# < segunda.s# suprime las parejas de la forma (x, x) y deja una sola de las parejas (x, y) (y, x). 11.3 Funciones integradas. Aunque la instruccin select ya es poderosa, no es adecuada por si sola para consultas tan sencillas como cuntos proveedores hay? Para cosas como estas existen las funciones integradas: Count, cuenta el nmero de valores de una columna. Sum, suma los valores de una columna. Avg, promedia los valores de una columna. Max, toma el valor ms grande de una columna. Min, toma el valor ms pequeo de una columna
127
1. Obtener la cantidad total de proveedores: select count (*) from S; Count ir con distinct si no debe contar los duplicados. 2. Obtener la cantidad total de proveedores que suministran partes en la actualidad: select count (distinct s#) 71 from SP; 3. Obtener la cantidad de envos de la parte p2: select count (*) from SP where p# = p2;
128
4. Obtener la cantidad total suministrada de la parte p2: select sum (cant) from SP where p# = p2; 5. Obtener el cdigo de parte y la cantidad total suministrada de cada parte: select p#, sum(cant) from SP 71 group by p#; 6. Obtener los cdigos de partes suministradas por ms de un proveedor: select p# from SP group by p# having count (*) > 1;
129
La clusula having siempre va con group by pues trabaja con grupos lo mismo que where con las tuplas. Cmo sera la respuesta sin having? 11.4 Caractersticas avanzadas de select. 1. Obtener todas las partes cuyos nombres comiencen con la letra b select P.* 71 from P where pnombre like b%; Los atributos usados en like deben ser de tipo char o graphic. El comodn _ representa cualquier carcter individual. % representa cualquier cadena de caracteres. Los dems caracteres se representan as mismos. Tambien se puede usar not like (diferente a)
130
2. Supongamos que el proveedor s5 tiene un nulo en el campo edo, en lugar de 30. Obtener el cdigo de los proveedores cuyo estado sea mayor que 25: select s# from S 71 where edo > 25; El resultado ser s3 porque en s5 el resultado es desconocido, pues edo no es > 25, ni edo es < 25, ni edo es = 25, ni edo es <> 25, ni edo es = null, ni edo es <> null. Para detectar la presencia de nulos habra que decir: select s# from S where edo is null;
131
3. Obtener los nombres de los proveedores que suministran la parte p2: select snombre from S where s# in (select s# from SP where p# = p2); select snombre from S where s# in (s1, s2, s3, s4); select snombre fron S, SP where S.s# = SP.s# and SP.p# = p2;
71
132
4. Obtener los nombres de los proveedores que suministren por lo menos una parte roja select snombre from S where s# in (select s# from SP where p# in (select p# from P where color = rojo)); select distinct S.snombre from S, SP, P where S.s# = SP.s# and P.p# = SP.p# and P.color = rojo;
133
71
5. Obtener el cdigo de los proveedores situados en la misma ciudad que el proveedor s1: select s# from S where ciudad = (select ciudad 71 from S where s# = s1); Si el resultado de una subconsulta es exactamente un valor se puede utilizar un operador como =, >, etc, en vez de in. 6. Obtener los cdigos de los proveedores cuyo estado sea menor que el valor mximo actual de estado: select s# from S where edo < (select max(edo) from S);
134
7. De nuevo, obtener los nombres de los proveedores que suministran la parte p2. select snombre from S where exists 71 (select * from SP where s# = S.s# and p# = p2); Nota: exists es el cuantificador existencial que implica una bsqueda. As para cada snombre en S se busca en SP una tupla que satisfaga la condicin de la subconsulta.
E
135
8. Obtener los nombres de los proveedores que no suministran la parte p2. select snombre from S where no exists (select * from SP where s# = S.s# and p# = p2); select snombre from S where s# not in (select s# from SP where p# = p2);
136
71
9. Obtener los nombres de los proveedores que suministran todas las partes. select snombre from S where not exists (select * 71 from P where not exists (select * from SP where s# = S.s# and p# = P.p#));
Da lo mismo decir no existe una condicin en un conjunto que todo el conjunto cumple la no condicin. Por ejemplo no existen partes que no estn en envos es igual a todas las partes estn en envos. not exists no es igual, aqu, a not in porque las subconsultas sobre P y SP no dan conjuntos definidos de valores. En general in se puede expresar con exists pero no al contrario.
137
10. Obtener los cdigos de los proveedores que suministran por lo menos todas las partes suministradas por el proveedor s2. select distinct s# from SP spx where not exists (select * from SP spy where s# = s2and not exists ( select * from SP spz where spz.s# = spx.s# and spz.p# = spy.p#));
71
138
11. Obtener los cdigos de las partes que pesen ms de 16 libras o sean suministradas por el proveedor s2, o las dos cosas. select p# from P where peso > 16 union select p# from SP where s# = s2;
71
139
12. Obtener los cdigos de las partes que pesen ms de 16 libras y sean suministradas por el proveedor s2. select p# from P where peso > 16 intersect select p# from SP where s# = s2;
71
140
13. Obtener los cdigos de las partes que pesen ms de 16 libras que no sean suministradas por el proveedor s2. select p# from P where peso > 16 minus select p# from SP where s# = s2;
71
11.5 Proposiciones de actualizacin. update tabla set campo = expresin [, campo = expresin] [where condicin];
141
1.Cambiar a amarillo el color de la parte p2, aumentar su peso en 5, e indicar que su ciudad es desconocida (null). update P set color = marillo, peso = peso + 5, ciudad = null 71 where p# = p2;
Si se omitiera la clusula where se modificaran todas tuplas de la tabla.
142
2. Duplicar el estado de todos los proveedores de Londres update S set edo = 2*edo where ciudad = Londres; 3. Poner en ceros la cantidad enviada por todos los proveedores de Londres update SP set cant = 0 where Londres = (select ciudad from S where S.s# = SP.s#);
71
143
4. Cambiar el cdigo del proveedor s2 a s9. update S set s# = s9 where s# = s2; update SP set s# = s9 where s# = s2;
71
Con update solo se puede actualizar una tabla, siendo entonces necesarios tantos update como tablas se deseen modificar. Por lo tanto cada update, insert delete ponen en peligro cada vez la integridad referencial.
144
insert into tabla [(campo [, campo] )] values (literal [, literal] );
insert into tabla [(campo [,campo] )] subconsulta;

En el primer formato se inserta en la tabla una tupla tal que a cada campo de la tabla le corresponda un literal, en el mismo orden. En el segundo formato se evala la subconsulta y se insertan las tuplas del resultado en la tabla. La i-sima columna del resultado es el i-simo campo de la tabla. Omitir la lista de campos equivale a especificar todos los campos de la tabla de izquierda a derecha.
145
1. Aadir la parte p7 (ciudad Atenas, peso 24, nombre y color desconocidos) a la tabla P. insert into P (p#, ciudad, peso) values (p7, Atenas, 24);
El nombre y el color se crean nulos asumiendo que en create table no se hubiera especificado not null.
71
2. Aadir la parte p8 con nombre cadena, color rosa, peso 14 y ciudad Niza, a la tabla P. insert into P values (p8, cadena,rosa, 14, Niza);
146
3. Insertar un nuevo envo con cdigo de proveedor s20, cdigo de parte p20, y cantidad 1000. insert into SP (s#, p#, cant) 71 values (s20, p20, 1000);
Esto causara problemas con la integridad referencial si antes no se inserta el proveedor s20 en S, y la parte p20 en P.
delete from tabla [where condicin];

147
1. Eliminar el proveedor s5. delete from S where s# = s5;

Este resultado tambin violara la integridad referencial si en SP hubiese un envo de s5.
2. Eliminar todos los envos cuya cantidad sea mayor que 300. 71 delete from SP where cant > 300;
148
3. Eliminar todos los embarques. delete from SP;

Este resultado deja la tabla vaca. Con drop se eliminara tambin la tabla.
4. Eliminar todos los envos de los proveedores situados en Londres. 71 delete from SP where Londres = (select ciudad from S where S.s# = SP.s#);
149
5. Eliminar todos los proveedores que no hayan suministrado partes rojas. delete from S where not exists (select * 71 from SP where S.s# = SP.s# and SP.p# in (select p# from P where color = rojo));
Cuando se usa el SQL embebido dentro de un lenguaje husped, es necesario usar ciclos y cursores para apuntar a cada tupla, por la des-adaptacin de impedancias entre SQL y los lenguajes de tercera generacin, pues estos solo entienden registros por vez y no tablas.
150
Problemas 1.Obtener los nombres de los proveedores y su ciudad, cuyo estado sea menor que 30. 71 2. Obtener los nombres de las partes cuyo color sea azul, o se almacenen en Roma. 3. Obtener los nombres de las partes con envos inferiores a 200 unidades. 4. Listar los nombres de los proveedores que hayan suministrado alguna parte, indicando los nombres de las partes, excepto el de la parte p2. 71 5. Listar los nombres de los proveedores que no hayan suministrado la parte p2 pero si alguna otra parte.
151
6. Listar los nombres de los proveedores que no hayan suministrado la parte p2. 71 7. Listar los nombres de las partes suministradas por todos los proveedores. 8. Listar el color y el nombre de las partes, que no hayan sido an suministradas por algn proveedor 9. Obtener los envos mayores de 200 indicando el nombre del proveedor, el nombre de la parte, y la ciudad desde donde se ha hecho el despacho. 10. Sumar 5 a la cantidad enviada por todos los proveedores de tuercas. 71 11. Eliminar todos los proveedores que hayan suministrado partes verdes almacenadas en Pars.
152
12. Insertar el proveedor de cdigo s20, nombre Ulloa, estado 10, y residente en Girn. 71 13. Sean las tablas A alumnos, M materias y C cursos. Obtener el cdigo y el nombre de los estudiantes de sistemas que tengan ms de 120 crditos. 14. Obtener el cdigo y el nombre de los estudiantes que estn viendo clculo. 15. Obtener el cdigo y el nombre de los estudiantes que no estn viendo historia. 16. Listar las notas de los estudiantes cuyo promedio sea mayor o igual a 3.8, agrupando y ordenando ascendentemente por cdigos de estudiante, indicando su cdigo, su nombre, su promedio, y el nombre de cada materia.
153
17. Obtener el cdigo y el nombre de los estudiantes que estn viendo todas las materias. 18. Obtener los cdigos de los estudiantes que estn viendo alguna materia vista por el estudiante de cdigo 07100.
A
19. Sumar 0.5 a la nota de clculo obtenida por todos los estudiantes de sistemas.
M
20. Eliminar todos los estudiantes que hayan obtenido notas inferiores a 1.0 en lgebra.
C
21. Insertar la materia con cdigo 1900, deportes, de 2 crditos y sin requisitos.
154
12. Diseo de Bases de datos: El modelo relacional y la normalizacin

Cmo poder conseguir las relaciones o tablas ms adecuadas a las exigencias de un problema real? Y cmo poder determinar los atributos que deben pertenecer a cada una de estas relaciones o tablas? En general, Cmo plantear un conjunto conceptual de relaciones con el cual mantener todos los datos de una empresa, con un mnimo de redundancia, pero al mismo tiempo con la mayor facilidad para su actualizacin y recuperacin? Para resolver estos interrogantes hay dos caminos:
155
Uno intuitivo y natural que se aproxima a objetos en cuanto determina la estructura de las tablas (los atributos que les pertenecen y las identifican), pero no su funcionalidad. Este camino produce, relaciones bastante normales por si solas. El otro camino aunque extrao es ms oficial, y es el seguido en este captulo. Parte de una mezcla anormal de todos los atributos posibles en una misma relacin, la cual es llamada la relacin universal. Por este motivo es necesario hacer normal (normalizar) la relacin universal, mediante una serie de pasos de descomposicin. As pues, la normalizacin consiste en descomponer tablas aislando atributos y reagrupndolos en nuevas relaciones que se parezcan ms a objetos de la vida real. 156
12.1 La relacin universal. Supongamos que se desea implantar una Base de datos (simplificada al extremo) para el suministro de partes a una empresa. Los datos (atributos) a mantener son los siguientes: La identificacin del proveedor (s#), el nombre del proveedor (snombre), el estado del proveedor (edo), la ciudad donde reside el proveedor (ciudad), la cantidad suministrada por el proveedor en cada envo (cant), la identificacin de cada parte (p#), el nombre de cada parte (pnombre), su color (color), su peso (peso), y la ciudad en donde se almacena la parte (ciudad). Todos estos atributos arreglados en una misma tabla produce la relacin universal (U).
157
U
s# snombre edo 20 ciudad cant p# pnombre p1 tuerca p2 perno p3 birlo p4 birlo p5 leva p6 engrane p1 tuerca p2 perno p2 perno p2 perno p4 birlo p5 leva 200 400 200 100 100 s2 Jaimes s3 Bernal s4 Corona 10 30 20 Pars Pars 300 400 200 300 400 Londres 200 color rojo azul rojo azul rojo rojo peso 12 17 14 12 19 12 ciudad Londres Pars Roma Londres Pars Londres Londres Pars Pars Pars Londres Pars
158
s1 Salazar
Londres 300
verde 17
verde 17 verde 17 verde 17 rojo azul 14 12
La principal anormalidad de la relacin U consisten en que para cada proveedor se abre una lista de partes enviadas, por lo cual los atributos cant, p#, pnombre, color, peso y ciudad, no son atmicos, o sea que se pueden dividir en varias sub-tuplas. Adems, en algunas tuplas los atributos s#, snombre, edo y ciudad no quedan definidos, pero en otras tuplas si. As, con DDL no podra ser creada la tabla U expresando null y simultneamente not null, en estos atributos. La correccin de las anteriores anomalas normalizar la relacin U, resultando una nueva relacin que se suele llamar la relacin 1NF (First Normal Form).
159
12.2 La primera forma normal (1NF).
Una relacin est en primera forma normal cuando el valor de sus atributos en cada tupla es atmico.
En otras palabras, en la interseccin de cada tupla con cada columna, siempre hay exactamente un valor, nunca un conjunto de valores. Entonces, para obtener la 1NF es necesario determinar valores nicos o atmicos en cada interseccin. As, la relacin U queda transformada en la relacin 1NF que se muestra en la siguiente diapositiva. Para las explicaciones subsiguientes, se ha incluido el atributo fecha, y el estado de s3 se ha cambiado de 30 a 10. Adems, es necesario repasar los conceptos de claves y dependencia funcionales.
160
1NF
s# s1 s1 s1 s1 s1 s1 s2 s2 s3 s4 s4 s4 snombre Salazar Salazar Salazar Salazar Salazar Salazar Jaimes Jaimes Bernal Corona Corona Corona edo 20 20 20 20 20 20 10 10 30 20 20 20 ciudad cant fecha 10/5 10/8 11/9 p# p1 p2 p4 pnombre tuerca perno birlo birlo leva engrane tuerca perno perno perno birlo leva color rojo verde azul rojo azul rojo rojo verde verde verde rojo azul peso 12 17 17 14 12 19 12 17 17 17 14 12 ciudad Londres Pars Roma Londres Pars Londres Londres Pars Pars Pars Londres Pars Londres 300 Londres 200 Londres 400 Londres 200 Londres 100 Londres 100 Pars Pars Pars 300 400 200
10/12 p3 11/15 p5 11/18 p6 10/7 10/2 11/3 11/8 p1 p2 p2 p4 10/10 p2
Londres 200 Londres 300 Londres 400
11/10 p5
161
12.3 Qu es una dependencia funcional (DF)? El concepto de dependencia funcional viene de las matemticas, y significa que si el valor de una variable y est siempre determinado por el valor de otra variable x, se dice que y est en funcin de x, y se denota y = f(x). Entonces, dados dos atributos A y B de una relacin R, B ser funcionalmente dependiente de A si para cada valor de A existe un valor de B y solo uno, o sea que al conocer el valor de A se podr conocer el valor de B. Esto se denota tambin A B. A y B deben pertenecer a la misma relacin pues no tiene sentido la dependencia funcional entre atributos de diferentes relaciones.
162
Al analizar las dependencias funcionales de los atributos entre si, se encontrarn atributos simples o compuestos cuyos valores son nicos, y entonces pueden ser usados para identificar las tuplas de una relacin. Tales atributos se llaman claves. Existen diferentes clases de claves. 12.3.1 Clave candidata. Es cualquier atributo simple o compuesto que puede ser utilizado para identificar las tuplas de una relacin, por lo que su valor debe ser nico an en el caso de ser compuesto. 12.3.2 Clave principal. Es la clave candidata elegida como identificador, en la que ningn componente puede tomar el valor nulo. Toda relacin debe tener una calve principal. 12.3.3 Clave fornea. Tambin llamada clave ajena o clave externa, es un campo de una relacin que acta como clave principal en otra relacin.
163
12.3.4 Clave alterna. Es la clave candidata que no es clave principal. Como s# es nico en S, es una clave candidata. Si snombre fuera nico, tambin sera una clave candidata. Si se elige s# como clave principal, snombre sera una clave alterna. Toda relacin tiene al menos una clave candidata ya que ninguna relacin puede contener tuplas repetidas. Los dems atributos no clave deben depender funcionalmente de la clave candidata. 12.4 Normalizacin de la relacin 1NF. La relacin 1NF tiene una estructura indeseable. Para apreciar esto se utilizan los llamados diagramas de dependencias funcionales o diagramas DF. El diagrama DF para la relacin 1NF es el siguiente:
164
Diagrama DF de la relacin 1NF

snombre
2 3
edo
5
s# cant
1
ciudad p# fecha
6 7 8 9
pnombre color peso ciudad
165
Sobre el diagrama DF anterior vemos que la nica clave candidata es el atributo compuesto (s#, p#, fecha). En una relacin normal cualquier atributo no clave debe depender funcionalmente de la clave candidata, pero esto no se cumple en la relacin 1NF. El nico atributo que depende por completo de la clave candidata es cant pero los dems no, como se ve en el diagrama DF. Si hay atributos no clave que no dependen de la clave candidata, entonces para qu la clave candidata? Sin embargo, se ve cierta dependencia no completa de los restantes atributos a la clave candidata: flechas 2, 3, 4, 6, 7, 8, 9.
166
Una dependencia funcional completa se define cuando un atributo B depende funcionalmente de A, pero no de ningn subconjunto propio de A. Por ejemplo, snombre depende de la clave candidata (s#, p#, fecha) pero no completamente porque tambin depende de s# solo. Estas otras dependencias diferentes a la clave candidata hacen anormal la relacin 1NF, generando redundancias obvias: Por ejemplo, todas las tuplas con s# = s1 indican que la ciudad es Londres; y las tuplas con ciudad de proveedor = Londres indican que el estado (edo) es 20. Estas redundancias provocan las conocidas anomalas de actualizacin, que son problemas surgidos al actualizar la Base de datos con insert, delete o update.
167
La primera redundancia se origina por la dependencia no completa s# ciudad (flecha4) y causa que no se pueda insertar (insert) un nuevo proveedor hasta que no suministre al menos una parte. De ah que en la relacin 1NF no se haya podido incluir el proveedor s5 situado en Atenas, pues sin un suministro no se puede tener una valor apropiado para la clave primaria. Adems, al eliminar (delete) la nica tupla de un cierto proveedor se perder no solo la informacin del envo sino tambin la del proveedor. De ah que al eliminar la tupla cuyo s# = s3 se eliminen los datos del envo pero tambin los del proveddor en los que dice que s3 est en Pars. El problema radica en que la relacin 1NF contiene demasiados datos y as, al eliminar una tupla de elimina demasiado.
168
La solucin a este problema es desempacar, o sea separar los datos de envos en una relacin y los de proveedores en otra. As pues, la normalizacin es un proceso de desempaque que coloca datos separados en relaciones separadas. Igualmente, no se puede actualizar (update) la relacin 1NF sin tener que recorrer todas sus tuplas para evitar las inconsistencias. Por ejemplo, si el proveedor s1 se cambia de Londres a Amsterdam. La correccin de todas estas anormalidades transforma la relacin 1NF en un conjunto de relaciones en segunda forma normal (2NF), en las cuales los datos quedan desempaquetados al eliminar las dependencias funcionales no completas.
169
12.5 La segunda forma normal (2NF).
Una relacin est en segunda forma normal (2NF) si y solo si est en 1NF y todos sus atributos no clave dependen por completo de la clave principal.
Se puede ver que las siguientes relaciones corresponden a las relaciones 2NF, en las cuales, s es posible incluir datos del proveedor s5 aunque no haya hecho envos. Adems, las redundancias han desaparecido y se pueden aplicar operaciones insert, delete y update sin los problemas ya vistos.
170
S
S# snombre edo ciudad S1 Salazar S2 Jaimes S3 Bernal S4 Corona S5 Aldana 20 Londres 10 Pars 10 Pars 20 Londres 30 Atenas
SP
S# S1 S1 S1 S1 S1 S1 pnombre Tuerca Perno Birlo Birlo Leva Engrane color Rojo Verde Azul Rojo Azul Rojo peso 12 17 17 14 12 19 ciudad Londres Pars Roma Londres Pars Londres
171
P# P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 P4 P5
fecha 10/5 10/8 10/12 11/9 11/15 11/18 10/7 10/10 10/2 11/3 11/8 11/10
cant 300 200 400 200 100 100 300 400 200 200 300 400
P
P# P1 P2 P3 P4 P5 P6
S2 S2 S3 S4 S4 S4
Finalmente es posible apreciar en la relaciones 2NF que las dependencias funcionales son completas, como se muestra en los diagramas DF a continuacin: SP
2
snombre s# p# fecha
1
S
s# cant
3 4
edo
5
ciudad p#
6 7 8 9
pnombre color peso ciudad

172
Las relaciones 2NF representan mejor el mundo real que la relacin 1NF y cualquier informacin derivable de sta lo ser tambin de las relaciones 2NF, aunque lo contrario no se cumple. Por ejemplo, el proveedor s5 no puede ser representado en la relacin 1NF. 12.6 Normalizacin de las relaciones 2NF. Aunque las relaciones P y SP son satisfactorias, la relacin S tiene todava una dependencia mutua entre sus atributos no clave (flecha 5 en el diagrama DF de la 2NF). En trminos ms especficos, la dependencia del atributo edo con respecto a s#, aunque es funcional y completa, es transitiva a travs de ciudad.
173
Si en una relacin R, R.A R.B y R.B R.C, por transitividad R.A R.C Por causa de la transitividad no se puede insertar (insert) el estado de una ciudad hasta que no haya un valor no nulo para la clave s#. Por ejemplo, no se puede insertar Roma con edo 50, si no hay un proveedor all. Tampoco se puede eliminar (delete) una tupla sin perder ms datos de la cuenta. Por ejemplo, si se elimina Aldana se pierde la ciudad Atenas y tambin el hecho de que a Atenas le corresponde el estado 30. Como S todava tiene redundancias es necesario recorrerla toda al actualizar (update) algo, para no dejar inconsistencias. Por ejemplo, si a Londres se le cambia el estado de 20 a 40.
174
La correccin de la transitividad transforma la
relacin S en dos relaciones 3NF, las cuales desempaquetan ms datos eliminando las dependencias transitivas.
12.7 Tercera forma normal (3NF).
Una relacin est en tercera forma normal (3NF) si y solo si est en segunda forma normal (2NF) y todos los atributos no clave dependen de manera no transitiva de la clave principal.
175
S
S# S1 S2 S3 S4 S5 snombre Salazar Jaimes Bernal Corona Aldana ciudad Londres Pars Pars Londres Atenas
C
ciudad Atenas Londres Pars Roma edo 30 20 10 50
Ahora s es posible incluir el estado 50 para Roma. Se puede eliminar Aldana sin borrar los datos de Atenas. Las redundancias desaparecieron bastando modificar el estado de Londres en una sola tupla.
176
As, las dependencias transitivas han desaparecido, como se puede observar en los diagramas DF para las relaciones S y la nueva relacin C (ciudad): S
s#
4
snombre ciudad
C
ciudad edo
Si en 3NF se puede representar datos que en 2NF no se poda, 3NF representa mejor el mundo real que 2NF.
177
12.8 Forma Normal de Boyce & Codd (BCNF). Pero, la 3NF originalmente debida a Codd, no satisface el caso en el cual una relacin tiene: a) Varias claves candidatas b) Claves candidatas compuestas c) Claves candidatas traslapadas Por esto, la definicin original de 3NF se sustituy por una definicin ms adecuada que tuviese en cuenta el caso abc. Pero como Ronald Fagin ya haba definido la 4NF, la nueva 3NF no se pudo llamar 4NF sino Forma Normal de Boyce & Codd o BCNF.
Las condiciones abc casi no se dan en la prctica y

cuando no existen, BCNF se reduce a la antigua 3NF.
178
Cuando un atributo depende por completo de otro atributo, ste determina al primero y se le llama un determinante. Por ejemplo, el snombre y la ciudad del proveedor dependen por completo de s# en la relacin S. Tambin el pnombre, el color, el peso y la ciudad de las partes dependen por completo de p# en P. Igualmente en SP, la cantidad enviada depende por completo de (s#, p#, fecha). Y en C, el estado depende por completo de ciudad. Por lo tanto, s#, p#, (s#, p#, fecha) y ciudad son todos determinantes en sus respectivas relaciones.
179
Una relacin est en forma normal de Boyce y Codd (BCNF), si y solo si todo determinante es una clave candidata.
Esta definicin es ms sencilla que la antigua 3NF puesto que no hace referencia explcitamente a la 1NF, ni a la 2NF, ni a la dependencia transitiva. De acuerdo a esta definicin, las relaciones S, P, SP y C, estn en 3NF, pero tambin en BCNF. Pero la relacin 1NF (ver su diagrama DF) contiene 4 determinantes, s#, p#, ciudad y (s#, p#, fecha), de los cuales solo (s#, p#, fecha) es clave candidata, y por esto que la relacin 1NF n est en BCNF.
180
Tampoco las relaciones en 2NFestn en BCNF porque ciudad es determinante pero no es clave candidata (ver el respectivo diagrama DF). Las relaciones S, P, SP, y C por el contrario, estn todas en BCNF porque en todos los casos la clave principal es el nico determinante en cada relacin. Pero consideremos ahora un caso en que haya varias claves candidatas (sin atributos comunes). Supongamos que en la relacin S cada s# tiene un nombre nico. Entonces el diagrama DF sera:
s# ciudad snombre
181
Ahora, aunque hay varias claves candidatas, los nicos determinantes son dichas claves candidatas, o sea que las nicas flechas son las que salen de las claves candidatas, lo cual significa que la relacin S est en BCNF. Consideremos ahora la relacin estudiante (E) para el caso en que haya varias claves candidatas que se traslapan (que tienen atributos comunes). Supngase que E tiene los atributos cdigo de estudiante (ce), nit (n#), cdigo de carrera (cc) y promedio (p), es decir, E(ce, n#, cc, p). Las claves candidatas son (ce, cc) y (n#, cc). Est E en BCNF? No porque contiene dos determinantes, ce y n#, que no son claves candidatas, pero si se determinan el uno al otro.
182
La relacin E est en 3NF porque ningn atributo no clave es transitivamente dependiente de la clave principal, y el atributo no clave (p) es totalmente dependiente de la clave principal, ya sea (ce, cc) (n#, cc). Sin embargo, E no est en BCNF. Admtase la relacin E con los siguientes datos:
ce
071 071 071 072 072
n# cc
n1 n1 n1 n2 n2 10 11 12 10 13
p
3.7 3.9 3.5 3.8 3.3
183
Puede verse que la relacin E contiene el mismo tipo de redundancias vistas atrs y por lo tanto est sujeta al mismo tipo de anomalas de actualizacin. La solucin es normalizar la relacin E, es decir, descomponer la relacin en dos proyecciones, que en este caso seran las proyecciones Estudiantes (E) y Promedios (P), de la siguiente manera: E(ce, n#) y P(ce, cc, p) o bien E(ce, n#) y P(n#, cc, p). En la siguiente diapositiva se muestran de la relacin E, los diagramas DF, primero en 3NF pero n en BCNF, y segundo en BCNF.
184
ce cc n#
Diagrama DF de E en 3NF pero no en BCNF
ce ce n# cc
Diagrama de E en BCNF
185
12.9 Cuarta Forma Normal (4NF). A veces se presentan en la vida real, relaciones muy singulares, en las cuales no es posible identificar las dependencias funcionales convencionales. Por ejemplo, sea la relacin con los atributos curso, profesor, texto, por lo cual se puede denominar la relacin CPT (curso, profesor, texto). Se puede observar que: Dado un curso, no se puede saber, ni el profesor, ni el texto, porque un curso puede ser dictado por varios profesores y utilizar varios textos. Tambin que, dado un profesor, no se puede saber, ni el curso, ni el texto, porque un profesor puede dictar varios cursos, y utilizar varios textos.
186
Finalmente que, dado un texto, no se puede saber, ni el curso, ni el profesor, porque un texto puede ser utilizado por varios profesores en distintos cursos. Al tabular algunos datos, la relacin CPT no normalizada se vera as: CPT
curso Fsica profesor Rosas Ramos Matemticas Rosas texto Mecnica ptica Mecnica ptica Mecnica Vectores Funciones
187
La nica operacin normalizadora disponible sera aplanar la relacin CPT, de la siguiente manera: CPT
curso Fsica Fsica Fsica Fsica Matemticas Matemticas Matemticas profesor Rosas Rosas Ramos Ramos Rosas Rosas Rosas texto Mecnica ptica Mecnica ptica Mecnica Vectores Funciones
188
Las redundancias que muestra la relacin CPT lleva a anomalas de actualizacin, a pesar de que CPT est en BCNF al ser toda clave. Pero no se puede utilizar DF para descomponer CPT ya que no existen DF. Solo hasta 1977 Ronald Fagin estableci el concepto de dependencias multivaluadas (DMV), con el cual es posible normalizar la relacin CPT. Una DMV es una generalizacin de DF, ya que toda DF es una DMV, aunque no al contrario. En CPT se puede considerar las siguientes DMV:
CPT.curso CPT.profesor CPT.curso CPT.texto
189
La primera DMV significa que aunque un curso no es determinante de un profesor, de cualquier manera un curso determina un conjunto muy bien definido de profesores. De la misma manera se interpreta la segunda DMV.
Una relacin est en 4NF si y solo si est en BCNF y no contiene dependencias multivaluadas (DMV).
Aunque de CPT no se puede eliminar las DMV, s se puede descomponer para eliminar las redundancias y las anomalas de actualizacin.
190
En general, una relacin R(A, B, C) con las DMV, AB, y AC, se puede descomponer sin prdidas en R1(A, B) y R2(A, C). De ah que la relacin CPT se haya descompuesto en las relacioes CP (curso, profesor) y CT (curso, texto), o sea: CT CP
Curso Fsica Fsica Matemticas Profesor Rosas Ramos Rosas Curso Fsica Fsica Matemticas Matemticas Texto Mecnica ptica Mecnica Vectores
Matemticas Funciones
191
Al ir ms all de esta descomposicin, para este caso, se salta a la conversin de cada uno de los atributos de CP y CT en relaciones individuales, cada una, a su vez, con sus propios atributos. O sea las relaciones: C (cursos) con sus propios atributos, P (profesor) con sus propios atributos, y T (textos) con sus propios atributos. Al concebir, en otra alternativa, entidades normales en lugar de relaciones anormales susceptibles de ser descompuestas, el diseo de una BD puede ajustarse mejor a un mundo real compuesto de objetos, ya que una entidad es una aproximacin a un objeto,
192
En el siguiente captulo se tratar el modelo semntico, en el cual se habla de entidades mas no de relaciones, por lo que al modelo semntico tambin se le llama modelo entidad/relacin.
193
Taller 1-12: Analizar las DF de las relaciones Bancos (B), Cuentas (C), Cheques (Ch) y Transacciones (T).
B
nit nombre telefono saldo
C
cuenta# retiros consignaciones saldo nit
Ch
cheque# Valor_ch Fecha_ch cuenta#
T
tr fecha_tr horatr usuatr valortr cheque#
194
Taller 2-12: Analizar las DF de las relaciones Depositarios (D), Contratos (C), Hatos (H) y Ventas (V).
D
cedula nombre_d val_con_d telef_d
C
contra# fechac clasec valorc cedula
H
contra# nombre_h cab_h kilos_h
V
contra# nombre_h fechav valorv cabv kilosv
195
13 El Modelo semntico o modelo E/R.
E/R = Entity (Entidad), Relacin o Tabla E/R = Vnculo o interrelacin, NO Relacin
Modelo semntico = {entidades, interrelaciones}
196
13.1 Las reglas lgicas o reglas del negocio:

Reglas del Negocio describen las polticas, normas, operaciones, definiciones y restricciones presentes en una organizacin. Las organizaciones funcionan siguiendo mltiples reglas de negocio, explcitas o tcitas, que estn embebidas en procesos, aplicaciones informticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el cdigo fuente de programas informticos. En las reglas del negocio se esconde el modelo E/R: Los sustantivos pertinentes al negocio son entidades y/o atributos de las entidades (rectngulos) Los verbos son interrelaciones (flechas, rombos, tringulos o recuadros) Las restricciones (la correspondencia entre entidades y su cardinalidad) sern las restricciones de dominio y de integridad En la siguiente URL se encuentra el manifiesto de las reglas del negocio:
http://www.businessrulesgroup.org/brmanifesto/BRManifiesto%5Bv1%5B1%5D.0%5D.pdf
197
Las
13.2 Entidades e interrelaciones

Una entidad es aproximadamente un objeto, con: Identidad (clave primaria) Estructura (atributos) Pero sin funcionalidad o comportamiento Al igual que un objeto, una entidad puede ser concreta como un cliente, una factura, una materia, o abstracta como un concepto.
Una entidad se representa por un rectngulo:
198
Una interrelacin es un enlace entre entidades y describe: Asociacin: Oficina y representante Generalizacin: Cliente, representante Agregacin: Pedido y producto (tem), Computador, pantalla y teclado Una interrelacin es representada por flechas y rombos, tringulos y recuadros.
199
13.3 Grado de las interrelaciones

Es el nmero de entidades participantes en la interrelacin, y puede ser binario directo, binario indirecto o n-ario.
Entidad 1
Entidad 2
Entidad 1
vnculo
Entidad 2
grado binario directo
grado binario indirecto
Entidad 1
Entidad 2
entidad n
vnculo
grado n-ario
200
13.4 Correspondencia de las interrelaciones

Expresa el nmero de tuplas que de una entidad corresponden a las de otra entidad. La correspondencia de la cardinalidad puede ser Una a una, 1:1 Una a muchas, 1:N Muchas a muchas (grado dos), M:N Muchas a muchas a muchas (grado tres), etc. L:M:N Una a una. Es cuando a cada tupla de la entidad 1 le corresponde a lo sumo una tupla de la entidad 2, y a cada tupla de la entidad 2 le corresponde a lo sumo una tupla de la entidad 1 1:1
oficina director
201
Una a muchas. Es cuando a cada tupla de una entidad 1 le corresponden varias tuplas de una entidad 2, pero a cada tupla de la entidad 2 le corresponde a lo sumo una tupla de la entidad 1. 1:N
clientes pedidos
Muchas a muchas (grado dos). Es cuando a cada tupla de una entidad 1 le corresponde varias tuplas de una entidad 2, y a cada tupla de la entidad 2 le corresponde varias tuplas de la entidad 1. M:N
clientes productos
202
Muchas a muchas a muchas (grado tres), etc. Es cuando a cada tupla de una entidad 1 le corresponde varias tuplas de una entidad 2 y varias tuplas de una entidad 3, y a cada tupla de la entidad 2 le corresponde varias tuplas de la entidad 1 y varias tuplas de la entidad 3, y a cada tupla de la entidad 3 le corresponde varias tuplas de la entidad 1 y varias tuplas de la entidad 2. L:M:N
clientes repventas
productos
13.5 Cardinalidad de las interrelaciones

En todas las correspondencias anteriores, adems se considera la cardinalidad misma que expresa un mnimo y un mximo de tuplas que de una entidad le corresponden a cada tupla de la otra, o de las otras entidades. Se acostumbra anotar como un par entre parntesis: (mnimo, mximo).
203
13.6 Diagramas E/R (Entity/Relationship)

El diagrama E/R es sacado de las reglas del negocio, pero esta fuente no es suficiente y es necesario completar con otras fuentes como la investigacin organizacional y el descubrimiento de requisitos. Un elemento de la ingeniera del software es la especificacin de requisitos o ingeniera de requisitos. sta ingeniera es una gua para extraer, analizar, especificar y validar los requisitos de un proyecto. Como experiencia personal, tambin es considerable la utilidad del catlogo de cuentas que toda organizacin debe mantener. Tal catlogo es el conjunto de cuentas de contabilidad que una empresa utiliza. Cada cuenta tiene un nombre que es el nombre de una entidad del modelo E/R que se busca.
204
Reglas del negocio de la empresa distribuidora. Volviendo a la

empresa distribuidora de pedidos, del captulo 1 del libro de Csar Prez, reconstruyamos su modelo E/R, desde su reglas del negocio: La empresa consta de varias oficinas distribuidas por todo el pas, cada una de las cuales est dirigida por no ms de un representante, o eventualmente por nadie, aunque un representante, si ha sido designado, debera dirigir al menos una oficina. Igualmente un representante puede trabajar sin una oficina asignada aunque siga contratado como tal, y ser dirigido por un solo director aunque podra no tener un director como ocurrira con la cabeza de la jerarqua. Adems, un representante puede ser director de al menos un representante o de ninguno como ocurrira con los ltimos de abajo en la jerarqua. Un cliente es atendido por un solo representante o por ninguno, pero un representante debe atender mnimo a un cliente. Un pedido debe ser tomado por un solo representante o por ninguno, pero un representante debe tomar al menos un pedido. Tambin un pedido debe ser hecho por un solo cliente, y ste debe tener al menos un pedido, o si no pierde el carcter de cliente. En un mismo pedido solo puede ser solicitado un producto y solo uno, pero un mismo producto puede haber sido solicitado en diferentes pedidos, al menos en uno. Si un producto no aparece solicitado en algn pedido ser ipso facto dado de baja. 205
Trabaja en
oficinas
repventas
Es dirigido
Dirigida por Es atendido por Tomado por
clientes
Es hecho por
pedidos
solicita
productos 206
Error frecuente 1: Aunque a veces s es posible considerar un sustantivo como una interrelacin (en este caso pedidos), no se puede dejar una contradiccin como la que se ve entre la lnea verde y la roja
Trabaja en
oficinas
repventas
Es dirigido
Dirigida por Es atendido por
clientes
pedidos
productos 207
Error frecuente 2: Tampoco se puede eliminar la interrelacin es atendido por para unificarla con pedidos en una interrelacin uno a muchos a muchos. Una interrelacin uno a muchos a muchos son dos interrelaciones uno a muchos diferentes.
Trabaja en
oficinas
repventas
Es dirigido
Dirigida por Es atendido por
clientes
pedidos
productos 208
Error frecuente 3: Si en un modelo E/R aparece un ciclo, no se puede decir que alguno de sus caminos sea redundante sin un previo anlisis de sus cardinalidades para todas las posibles consultas. Analcese el siguiente caso:
1:N clientes (1,1) (1,N)
Es atendido por
(1,1)
repventas (1,1)
1:N
hecho por
(1,N)
pedidos
(1,N)
Tomado por
1:N
Redundante (?)
Ciclo con relativa redundancia

1:N
Redundante (?)
clientes (1,1)
(1,N)
Es atendido por
(1,1)
repventas (1,1)
1:N
hecho por
(0,N)
pedidos
(1,N)
Tomado por
1:N
No redundante
Ciclo sin redundancia
No redundante 209
En el ciclo con redundancia, si el representante de un cliente dado ha tomado pedidos, tal cliente ha hecho pedidos, porque la cardinalidad (1,N)(1,1) obliga a que el cliente siempre tenga al menos un pedido. El camino tomado por y hecho por seran caminos redundantes pues para una consulta se podra obtener la misma informacin por cualquiera de ellos. En el ciclo sin redundancia, si el representante de un cliente dado ha tomado pedidos, no se puede saber si tal cliente ha hecho o no ha hecho pedidos, porque la cardinalidad (0,N)(1,1) permite que el cliente exista sin pedidos. Si el representante de un cliente dado ha tomado pedidos y el cliente ha sido atendido por su representante, no se puede deducir que el cliente haya hecho pedidos, y es necesario el camino hecho por al menos para sta consulta. Siempre es necesario tener mucha cautela con los caminos aparentemente redundantes.
210
13.7 Conversin del diagrama E/R a diagrama referencial (tablas).

Como los rombos, los rectngulos y las flechas no pueden ser descritos para un computador, es necesario convertirlos a algo que pueda ser descrito en un lenguaje compilable. Este algo son tablas que puedan ser creadas con create table. As, cuando la correspondencia es 1:1, la conversin a tablas de acuerdo a su cardinalidad es:
S
(1,1) 1:1 (1,1)
S
(1,1)
1:1 (0,1)
S S
(0,1) 1:1
P
(0,1)
SP P
13. Modelo semntico.
211
Cuando la correspondencia es 1:N o M:1, segn su cardinalidad:

S (1,*) M:1 (1,1) P S P
S S (0,*) M:1 (1,1) P P SP
S S (0,*) M:1 (0,1) P SP P
S (1,*)
M:1
P (0,1)
212
Cuando la correspondencia es M:N, segn su cardinalidad

S S (1,M) M:N P (1,N) P SP
S S (0,M) M:N P (1,M) P SP
S S (0,M) M:N P (0,M) P SP
213
Cuando la correspondencia L:M:N, segn su cardinalidad

S S L:M:N P SPC P C C
214
13.8 Valores de claves forneas segn cardinalidad

El caso S(1,1)P(1,1) lleva a la unificacin de entidades que en apariencia se vean separadas. Pero si se quieren ver dos entidades distintas, es como si una virtual clave fornea de la entidad referente no permitiese nulos y su valor fuese nico, propiedades stas de clave candidata que reclaman su unificacin. S (proveedores)
s# S1 S2 S3 S4 s5 snombre Salazar Jaimes Bernal Corona Aldana p# (no nulo y nico) P1 P3 P5 P2 P4
(partes)
pnombre Tuerca Perno Birlo Leva Engrane
p# P1 P2 P3 P4 P5
Corresponde exactamente 1 tupla de S a cada tupla de P, y 1 tupla de P a cada tupla de S.

215
El caso S(1,1)P(0,1) se convierte en dos entidades en donde la entidad referente s permite valores nulos en la clave fornea, pero de valor nico si es no nulo, propiedades stas que le impiden ser clave candidata en S. S
(proveedores)
s# S1 S2 S3 S4 S5 S6 snombre Salazar Jaimes Bernal Corona Aldana Forero p# (nulo o nico) P3 P5 P1 P2 P4 nulls
P (partes)
p# P1 P2 P3 P4 P5 pnombre Tuerca Perno Birlo Leva Engrane
Corresponden exactamente 1 tupla de S a cada tupla de P, y 1 ninguna tupla de P a cada tupla de S.
216
El caso S(0,1)P(0,1) se convierte en tres entidades con una entidad referente que permite valores nulos en las dos claves forneas, con valores nicos si son no nulos. S (proveedores) SP S# snombre
S# (nulo o nico) nulls S2 S1 S3 S4 S5 S6 nulls P# (nulo o nico) P3 nulls P1 P2 P4 nulls nulls P5 S1 S2 S3 S4 S5 S6 Salazar Jaimes Bernal Corona Aldana Forero
P (partes)
P# P1 Pnombre Tuerca Perno Birlo Leva Engrane
Corresponde 1 o ninguna tupla de S a cada tupla de P, y 1 o ninguna tupla de P a cada tupla de S.
P2 P3 P4 P5
217
El caso S(1,M)P(1,1) se convierte en dos entidades en donde la entidad con (1,M) es la entidad referente con no nulos en la clave fornea, y adems de valor no nico. S
(proveedores)
s# S1 S2 S3 S4 S5 S6 S7 snombre Salazar Jaimes Bernal Corona Aldana Forero Prez p# (no nulo y no nico) P3 P5 P1 P2 P4 P2 P1
P (partes)
Corresponden muchas tuplas de S mnimo 1 a cada tupla de P, y 1 tupla de P exactamente a cada tupla de S.
218
El caso S(0,M)P(1,1) se convierte en tres entidades con la nueva entidad como referente de dos claves forneas. La clave referida a S con un valor nulo nico, y la clave referida a P con no nulo y no nico. S (proveedores) SP
S# (nulo o nico) S1 S2 null S5 S4 S3 P# (no nulo y no nico) P1 P1 P2 P3 P4 P5 s# S1 S2 S3 S4 S5 snombre Salazar Jaimes Bernal Corona Aldana
P (partes)
p# P1 P2 P3 pnombre Tuerca Perno Birlo Leva Engrane
Corresponden muchas ninguna tupla de S a cada tupla de P, y 1 tupla de P a cada tupla de S exactamente.
P4 P5
219
El caso S(0,M)P(0,1) se convierte en tres entidades con la nueva entidad como referente de dos claves forneas. La clave referida a S con un valor nulo nico, y la clave referida a P con nulo pero no nico. S (proveedores) SP
S# (nulo o nico) S1 S2 null S5 S4 null S3 P# (nulo o no nico) P1 P1 P2 P3 null P4 P5 s# S1 S2 S3 S4 S5 snombre Salazar Jaimes Bernal Corona Aldana
P (partes)
p# P1 P2 P3 pnombre Tuerca Perno Birlo Leva Engrane
Corresponden muchas ninguna tupla de S a cada tupla de P, y 1 o ninguna tupla de P a cada tupla de S.
P4 P5
220
El caso S(1,M)P(0,1) se convierte en dos entidades en donde la entidad con (1,M) es la entidad referente con nulos en la clave fornea, y adems de valor no nico. S
(proveedores)
s# S1 S2 S3 S4 S5 S6 S7 snombre Salazar Jaimes Bernal Corona Aldana Forero Prez p# (nulo o no nico) P3 P5 P1 P2 null P4 P1
P (partes)
Corresponden muchas tuplas de S mnimo 1 a cada tupla de P, y 1 tupla de P o ninguna a cada tupla de S.
221
El caso S(1,M)P(1,N) se convierte en tres entidades con la nueva entidad como referente de dos claves forneas. La clave referida a S con un valor no nulo y no nico, y la clave referida a P con no nulo y no nico. S (proveedores) SP
s# snombre Salazar Jaimes Bernal Corona Aldana S# (no nulo y no nico) S1 S1 S1 S2 S3 S3 S4 S5 S5 S5 P# (no nulo y no nico) P1 P2 P4 P3 P2 P5 P1 P1 P2 P4 S1 S2 S3 S4 S5
P (partes)
Corresponden muchas tuplas de S, mnimo 1, a cada tupla de P, y muchas tuplas de P mnimo 1, a cada tupla de S.
222
Volviendo a nuestro diagrama E/R, ste quedar convertido a tablas, en lo que C. J. Date llama el Diagrama referencial de la siguiente diapositiva. Segn el diagrama referencial del libro, las cardinalidades son las mostradas aqu:
Trabaja en (0,1) (1,N) (0,1) Es dirigido
oficinas
(1,N) Dirigida por Es atendido por (0,1)
repventas
(1,N)
Tomado por (1,N) (1,1) (1,N) Es hecho por (1,N)
clientes
pedidos
(1,N) solicita (1,1)
productos
223
Diagrama referencial
oficinas oficina
ciudad region dir objetivo ventas
repventas num_empl
nombre edad oficina_rep titulo contrato director cuota ventas
Directores
Dirije_a Dirigido_por
clientes num_clie
empresa rep_clie lim_credito
pedidos num_pedido
fecha_pedido clie rep fab producto cant importe
productos id_fab id_producto

descripcion precio existencia
224
13.9 El modelo E/R extendido

El modelo ER tradicional solo incluye interrelaciones de asociacin pero no las de generalizacin ni las de agregacin. El modelo E/R extendido considera la generalizacin representndola mediante un tringulo (ISA), y la agregacin mediante un recuadro que contiene las entidades componentes. Si en nuestro problema hubisemos considerado que tanto los representantes de ventas como los clientes son personas, personas podra ser una clase y repventas y clientes seran instancias de esta clase, lo cual sera representado en el diagrama E/R de la siguiente manera:
personas
isa
repventas
clientes
225
De esta manera, con solo indicar que is a class al crear la tabla personas, y que is a persona al crear tanto la tabla repventas como la tabla clientes, estas tablas (repventas y clientes) heredaran de la tabla personas todos los atributos propios de una persona (como la cdula, los nombres, los apellidos, el telfono, el celular, la direccin, etc. etc.), sin necesidad de declararlos como atributos explcitos en las tablas repventas y clientes. Lo anterior se podra rudimentariamente implementar, si el motor no reconoce herencia, mediante claves forneas en las tablas repventas y clientes haciendo referencia a personas. Para ver la implementacin de la agregacin, analcese el caso de proyectos en una empresa, desarrollados por diferentes departamentos y en donde cada departamento puede estar desarrollando ms de un proyecto. Supngase adems que el departamento financiero no desarrolla proyectos pero si est encargado del control financiero del desarrollo; no del control de cada proyecto ni de cada departamento. Para llevar a cabo este control nombra uno o ms de sus funcionarios para esta tarea. El diagrama E/R para este caso se muestra en la siguiente diapositiva.
226
funcionarios
controla
!?
proyectos
desarrolla
departamentos
funcionarios
controla
proyectos
desarrolla
departamentos
227
La interrelacin entre los rombos controla y desarrolla no es permitida en los modelos E/R. Pero, controla debe convertirse en tabla porque tiene atributos propios como la fecha hasta la que el funcionario asignado tiene la facultad de controlar y el presupuesto general a controlar por cada funcionario. El rombo desarrolla debe convertirse en otra tabla diferente porque tambin tiene atributos propios como la fecha en que cada departamento inici el desarrollo de cada proyecto. El rombo desarrolla se convierte a una tabla que tiene como claves forneas la clave primaria de la entidad proyectos y la clave primaria de la entidad departamentos. El rombo controla queda interrelacionado al recuadro entero (una entidad compuesta), y no meramente al rombo desarrolla. Por lo tanto, el rombo controla se convierte a una tabla que tiene como claves forneas la clave primaria de la tabla desarrolla, y la clave primaria de la entidad funcionarios.
228
El diagrama referencial, para este caso, puede ser analizado a continuacin:

funcionarios Cedula
Nombre Telefono
controla Control#
Cedula Desa# Presup Hasta
proyectos Proy#
Nombre Valor
desarrolla Desa#
Proy# Dep# Inicio
departamentos Dep#
Nombre Telefono
229
Aunque es posible que la interrelacin desarrolla tenga como clave primaria la concatenacin de Dep# y Proy# (las claves primarias de la entidades interrelacionadas), aqu se prefiere que la clave primaria de desarrolla sea un nmero consecutivo (Desa#) para cada desarrollo. As los atributos Dep# y Proy# como claves forneas en desarrolla quedan en libertad para poder tomar valores nulos o no nicos si las reglas del negocio as lo demandaran. Similarmente, aunque la interrelacin controla podra tener como clave primaria la concatenacin de (Dep#, Proy#) a la sazn clave primaria de la entidad compuesta desarrolla, y Cedula clave primaria de la entidad funcionarios, aqu se prefiere que la clave primaria de controla sea un nmero consecutivo (Control#) para cada control. As los atributos Desa# (que es Dep# y Proy#), y Cedula como claves forneas en controla quedan en libertad para poder tomar valores nulos o no nicos si las reglas del negocio as lo demandaran.
230
13.10 Verificacin del grado de normalidad.

El modelado semntico ha sido desarrollado sobre los cimientos del modelo relacional. Pero, los modelos E/R podran ser vistos en realidad como el complemento lgico y necesario del modelo relacional. Porque que teniendo listo el conjunto interrelacionado de entidades, es preciso determinar sus atributos contenidos de tal forma que cada una de tales entidades sea normal a la luz de la teora de la normalizacin. Considerando cada tabla obtenida tras la conversin del modelo E/R a tablas, cada una de tales tablas debe ser verificada individualmente y conjuntamente para asegurar un grado de normalidad al menos hasta Boyce & Codd.
231
Considerando cada tabla obtenida tras la conversin del modelo E/R a tablas, cada una de tales tablas debe ser verificada individualmente y conjuntamente para asegurar un grado de normalidad al menos hasta Boyce & Codd. Individualmente verificando que las dependencias funcionales de los atributos de cada tabla sean las permitidas, y solo las permitidas, con respecto a su clave primaria. Adicionalmente debe ser verificado el hecho por el que cada uno de sus atributos debe ser mantenido por obligacin dentro de sus dominios permitidos. Conjuntamente verificando que los valores de sus claves forneas sean los permitidos con respecto a las claves primarias de las dems tablas con las que se interrelaciona cada tabla en particular, segn las restricciones de la integridad referencial. Pero tambin verificando que los valores de sus claves forneas sean los permitidos segn la cardinalidad de cada una de sus interrelaciones.
232
Taller 1-13. Se desea construir una Base de datos para llevar los asuntos acadmicos de una universidad. Las siguientes son las reglas acadmicas (conocidas en general como reglas del negocio):
Un estudiante cursa semestralmente diversas materias, an de distintas carreras. Por cada materia de cada carrera tiene una nota que debe permanecer en la Base de datos hasta que el estudiante se grade. Ya matriculado, en general a cada estudiante le dictan clase diversos profesores, de diferentes materias, en distintos das, a diferentes horas y en distintos salones, a travs de cursos.
13. Modelo semntico. 233
As mismo, un profesor pertenece a una sola escuela (o carrera) pero puede dictar varias materias a muchos estudiantes en distintos das, a distintas horas y en distintos salones, es decir, que cada profesor puede dictar varios cursos. Un curso es vigente solo por un semestre pues, una vez actualizada la Base de datos con las diferentes actas de notas, el cuso desaparece para permitir la creacin de nuevos cursos en el siguiente semestre. Cada materia es ofrecida por una sola escuela segn su pensum, pero puede ser dictada por distintos profesores, a muchos estudiantes, en el mismo o en diferentes das, a la misma o a diferentes horas y en el mismo o en diferentes salones: O sea que, una materia puede ser ofrecida en varios cursos pero sin ninguna interferencia.
Para que un estudiante pueda matricular una materia, l debe cumplir distintos requisitos, unos son otras materias, y otros son crditos cursados. Un materia puede ser requisito para varias materias, y una materia puede tener varias materias como requisitos. Estrategia: Si el requisito son crditos, el cdigo del requisito puede ser menor o igual de
400, y si es una materia el cdigo del requisito es el cdigo de la materia y ser mayor de 400.
En cada saln, en un da especfico, a una hora especfica, solo se puede dictar una materia. Sin embargo, pueden ser dictadas diferentes materias, por el mismo o por diferentes profesores, a muchos estudiantes, siempre y cuando el da y/o la hora sean distintos. Lo cierto es que al finalizar cada semestre todos los salones deben quedar libres y disponibles para el siguiente semestre. Finalmente, a una hora especfica en un da especfico un saln ..
puede estar libre u ocupado, pero en este caso lo estar por un solo profesor quien estar dictando una sola materia a varios estudiantes. Con todo, a una hora especfica en diferentes das, habr muchos salones ocupados por muchos estudiantes asistiendo a cursos de diferentes materias dictados por diferentes profesores.
1. Construir el diagrama E/R 2. Convertir las entidades resultantes en el diagrama a relaciones (normales) con atributos y claves. 3. Crear las tablas correspondientes a las relaciones. 4. Actualizar la Base de datos con las matrculas, teniendo en cuenta los requisitos de cada materia y la pertenencia del estudiante a la escuela.
5. Actualizar la Base de datos con las notas definitivas de las distintas materias cursadas, re calculando el promedio ponderado y los crditos cursados. 6. Eliminar los estudiantes cuyo promedio ponderado sea menor de 3.2 por tercera vez consecutiva. 7. Listar los estudiantes cuyo promedio ponderado haya sido mayor a 4.5 8. Producir los polgrafos.
237
Modelo E/R para asuntos acadmicos de una universidad

Carrera = Escuela
empleado
carrera
trabajador
tiene
estudia
pensum
da
hora
saln
profesor
estudiante
tiene notas
materias requisito
cursos 13. Modelo semntico. 238
Diagrama referencial del modelo

(Las interrelaciones han sido convertidas a tablas)
carrera da currcula hora saln profesor estudiante notas materias requisitos pensum
cursos
239
Modelo relacional para asuntos acadmicos

(Cada relacin es normal)
Da Nomb_dia Carrera Codi_car Nomb_car Cred_car Currcula Estudiante Codi_est Nomb_est Cedu_est Dire_est Tele_est Codi_est Codi_car Fecha_ini Prom_est Cred_apr Veces_con Fecha_con Materias Codi_mat Codi_car Nomb_mat Cred_mat Requisitos Codi_req Codi_mat Pensum Codi_car Codi_mat
Hora Hora Salon Codi_sal Nomb_sal Edif_sal Capa_sal
Notas Codi_est Codi_car Codi_mat Nota_mat Fecha_not
Profesor Codi_pro Cedu_pro Dedi_pro Cate_pro Codi_car
Cursos Codi_mat Codi_gru Codi_pro Codi_est Codi_hor Codi_dia Codi_sal
Llave primaria Llave fornea Parte de ambas 240
Taller 2-13. Reglas del negocio de una librera Una librera desea desarrollar su propia Base de datos. Los libros estn dispuestos en estantes por temas. Cada estante est rotulado con el nombre del tema de los libros que alberga, el cual es fcilmente visible a simple vista. En dicha librera se sabe que una editorial usualmente publica muchos libros sobre diferentes temas y de diferentes autores. Sin embargo, de un mismo tema pueden escribir muchos autores de diferentes editoriales y por lo tanto pueden existir muchos libros de un tema determinado. Por otra parte un libro solo trata de un tema especfico y es editado por una editorial especfica, aunque puede ser
escrito por varios autores. Del mismo modo, un autor puede escribir muchos libros sobre diferentes temas y an en diferentes editoriales. 1. Construya a partir de estas reglas un modelo E/R. 2. Convierta a tablas el modelo obtenido, proponiendo usted los atributos que debe contener cada relacin. 3. Cree las tablas de esta Base de datos. 4. Pueble la Base de datos obtenida. 5. Liste los libros de cada editorial en orden alfabtico del nombre de libro, indicando el nombre del autor.
242
14. Integridad de una base de datos.

La integridad de las Bases de datos es muy importante porque si sta no pudiera mantenerse garantizada se desplomara toda la anterior teora semntico-relacional. El concepto de integridad conlleva a que la BD debe quedar siempre, en todo momento y lugar, incorruptible, para lo cual se debe velar por el estricto cumplimiento de las reglas de integridad. Existen reglas de integridad especficas y reglas de integridad generales. Las reglas especficas se refieren a la validez de cada uno de los valores guardados en la interseccin de cada fila y de cada columna de cada tabla.
243
Las reglas generales se refieren a la validez de las interrelaciones entre las entidades de un modelo E/R, o sea, a la correspondencia entre las claves primarias y las claves forneas de las respectivas tablas de una BD.
14.1 Restricciones de dominio.

Las reglas especficas son conocidas tambin como restricciones de dominio, ya que limitan los valores posibles que pueden tomar los diferentes atributos de las entidades. Por ejemplo, son restricciones de dominio: Que el cdigo del estudiante sea de diez caracteres y que no pueda ser ignorado, o sea, char (10) not null. Que el estado de los proveedores sea un entero entre 1 y 100. Que los das de la semana deban ser seleccionados de una lista. Que las notas de los estudiantes sean reales positivos de una cifra entera y otra decimal.
244
Que la cantidad despachada no sea mayor que la existencia. Que el mes sea uno de los valores alfanumricos 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11 o 12. Que el nombre del cliente sea alfanumrico de diez caracteres y no pueda ser ignorado, o sea, char (10) not null. Etc.
Muchas son las reglas de integridad especficas las cuales se codifican en la descripcin de las tablas con create table como restricciones de dominio. Con SQL2 se usa la clusula check como se ilustra en el siguiente ejemplo: Create table empleado ( edad smallint not null check (edad >=18); El conjunto de las reglas especficas o restricciones de dominio puede ser distinguido aqu como la regla 0 y puede ser enunciada as:
245
Regla 0: Los valores de cualquier atributo de una BD siempre deben ajustarse a su correspondiente dominio.
14.2 Integridad de las entidades.

Las reglas de integridad referencial generales, por su lado se subdividen en dos: Una que se refiere a las claves primarias (la regla 1), y otra que se refiere a las claves forneas (la regla 2). Regla 1: Ningn componente de la clave primaria de una tabla puede aceptar nulos. En efecto, no puede haber tuplas cuya clave de identificacin total o parcial sea desconocida, es decir cuyo valor sea nulo o contenga nulos, pues nunca podran ser localizadas. La anterior regla significa que en una BD jams se podr registrar algo, ni entidades ni tuplas, que no puedan ser identificadas. La regla 1 se denomina como la regla de integridad de las entidades.
246
14.3 Integridad referencial.

La integridad referencial hace alusin a la validez de las interrelaciones entre entidades, y por lo tanto cuestiona la validez de los valores de las claves forneas ajustados a la cardinalidad establecida en las reglas del negocio. La restriccin por la cual los valores de una clave fornea deben concordar con los valores de la clave primaria correspondiente, se conoce como restriccin referencial. La entidad que contiene la clave fornea se llama entidad referente y la que contiene la clave primaria entidad referida o entidad objetivo, lo cual se puede representar mediante un diagrama referencial como el mostrado a continuacin:
cursos
profesor
escuela
247
Cada flecha significa que existe una clave fornea en la entidad de la cual sale la flecha, que hace referencia a la clave primaria de la entidad a la cual apunta la flecha. A diferencia de una clave primaria, una clave fornea si puede tomar valores nulos si la cardinalidad expresada en las reglas del negocio consideran la opcionalidad. Pero si el valor de una clave fornea es no nulo, debe ser idntico al valor de la clave primaria de alguna tupla en la entidad referida. La entidad referida y la referente pueden llegar a ser la misma entidad, y entonces se le llama una entidad autorreferencial. Este es el caso de los representantes y sus directores para la empresa distribuidora de pedidos. A veces, la clave fornea puede simultneamente componer la clave primaria en la relacin que la contiene. Por ejemplo, en la relacin SP, s# y p# son ambas claves forneas y simultneamente componen la clave primaria (s#, p#). Pero a menudo, la clave fornea es distinta de la clave primaria, como en el caso de la agregacin de atrs con la relacin desarrolla en donde la clave primaria fue Desa#, y las claves forneas Dep# y Proy#.
248
Las claves forneas que no constituyen la clave primaria tienen toda la libertad para que sus dominios incluyan valores nulos o repetidos y as puedan reflejar con mayor exactitud las reglas del negocio. Observe tambin que, una relacin dada puede contener muchas claves forneas. En general, si en una interrelacin hay n entidades participantes, la entidad de la interrelacin contendr n claves forneas. Sean las relaciones R1, R2, , Rn-1, Rn, tal que existe una restriccin referencial de R1 a R2, otra de R2 a R3, y otra de Rn-1 a Rn produciendo el diagrama referencial: R1R2 R3 Rn-1 Rn. La sucesin de entidades y flechas desde R1 hasta Rn representa un camino o ruta referencial de R1 a Rn. En un diagrama referencial puede haber muchas rutas referenciales en las que las claves forneas deben concordar con las claves primarias. Entonces, la regla 2 dice: Regla 2: Una Base de datos no puede contener valores de clave fornea sin concordancia.
249
O sea, si R1 hace referencia a R2, R2 debe existir. Y si R2 va a ser eliminada (delete), R1 debe impedirlo, eliminarse tambin o, poner nulos en su respectiva clave fornea, segn sea la cardinalidad expresada en las reglas del negocio, para mantener la integridad referencial. El mismo cuidado hay que tener al hacer inserciones (insert) y modificaciones (update), para mantener la concordancia entre claves forneas y claves primarias. Pero quin debe tener cuidado al realizar operaciones con las claves forneas? Lo ideal es que el control est a cargo del DBMS y no del sujeto programador, aunque ste debe dar al DBMS las indicaciones adecuadas. As, el DBMS debera entender por si solo, que al cancelar una cuenta corriente, por ejemplo, los cheques girados posteriormente buscando ser insertados, deben ser rechazados. O que si un cliente cancela su deuda total, el DBMS debe eliminar (delete) automticamente y en cascada todas las facturas pendientes de dicho cliente.
250
Entonces, el usuario debe cuestionar por cada clave fornea, cuales operaciones (insert, delete o upadate) han de rechazarse, y cuales han de aceptarse y con qu operaciones de compensacin si es el caso. Por ejemplo Insertando una tupla, puede aceptar nulos su clave fornea? Esto se sabra revisando la cardinalidad y los valores posibles para las claves forneas. Y Qu debe suceder si hay intento de eliminar una tupla referida por una clave fornea? Al analizar este caso, hay tres posibilidades de eliminacin: Eliminacin restringida (restricted), si el delete a la tupla se puede realizar solo si no existen otras tuplas que en sus claves forneas la referencien. Si existen se rechaza. Eliminacin propagada (cascade), si el delete a la tupla se propaga (en cascada) eliminando tambin las tuplas que hacen la referencia. El programador no necesita as codificar sucesivos deletes. Eliminacin anulada (set null), si el delete a la tupla se permite pero asignando nulos a las claves forneas. El programador no necesita codificar sucesivos updates.
251
Y Qu debe suceder si hay un intento de modificar la clave primaria referida en una clave fornea? Una vez ms hay tres posibilidades como en la eliminacin. Modificacin restringida (restricted): Solo podr estar permitida la modificacin si no est referida, pero se rechazar si lo est. Modificacin en cascada: La modificacin se propagar (en cascada) modificando tambin la clave fornea. Modificacin anulada (set null): Se asignarn nulos a la clave fornea.
Observe que la respuesta a cada pregunta depende de lo que expresen las reglas del negocio en la organizacin que se est modelando. Para responder cada pregunta, en DDL se considera la siguiente sintaxis de create table:
create table foreign key (clave) references tabla objetivo on delete efecto on update efecto
En donde el efecto puede ser no action o sea restricted, cascades o set null.
252
Por ejemplo:
create table facturas (factura# char(5) not null, fecha date not null, valor number(9) not null, cedula# char(10) not null, primary key factura#, foreign key (cedula#) references clientes on deletes cascades on update cascades);
Las anteriores preguntas tambin se pueden responder con DML si su respuesta no fue clara al momento de describir las tablas con DDL. Para responder cada pregunta con DML, particularmente si la operacin es restringida por una condicin, se utilizan las afirmaciones o asertos (assert) y los disparadores (trigger), cuya sintaxis es:
create assertion nombre del aserto check condicin;
Ejemplo, para que la cantidad de parte p1 enviada sea mayor a 100:

Create assertion envio_valido Check (SP.s#=S.s# and SP.p#=P.p# and SP.p#=p1and SP.cant>=100);
253
Ejemplo para asegurar que el objetivo de cuota de cada oficina no supere la suma de las cuotas de sus representantes:
create assertion cuota_valida check (oficinas.objetivo <= sum(repventas.cuota) and repventas.oficina_rep = oficinas.oficina);
Ejemplo para asegurar que el total de los pedidos de cualquier cliente no supera su lmite de crdito.
create assertion control_pedidos check (clientes.limite_credito >= select sum(pedidos.importe) from pedidos where pedidos.clie = clientes.num_clie);
Los asertos describen restricciones que pueden definirse como diferidas al fin de cada transaccin aunque inicialmente sean declaradas inmediatas, o al contrario. No obstante, tales caractersticas pueden ser modificadas dinmicamente con la instruccin set constraints.
254
Por ejemplo, supongamos que la anterior asercin sea declarada diferible al terminar una transaccin pero inicialmente inmediata:
create assertion control_pedidos check (clientes.limite_credito >= select sum(pedidos.importe) from pedidos where pedidos.clie = clientes.num_clie) deferrable initially immediate;
Esta restriccin ser procesada automticamente instruccin por instruccin (lneas negras) pero despus del set constraints control_pedidos deferred ser procesada diferida (deferred) al terminar la transaccin (lneas rojas), inmediatamente despus del commit.
set constraints control_pedidos deferred
Commit;
255
Los trigger son fragmentos de cdigo que se ejecutan en forma implcita con la ejecucin de un insert, de un update o de un delete sobre una tabla. Aunque los conceptos de los trigger son muy consistentes de unos motores a otros, sus particularidades sintcticas si varan bastante de un motor a otro. Para oracle, su sintaxis es la siguiente:
create [or replace] trigger
nombre del trigger
{beforeafter} suceso disparo on tabla [for each row [when condicin ]]

cuerpo del trigger
Suponiendo definidas las tablas cursos (C), estudiantes (E) y matriculas (M), veamos el trigger para actualizar los atributos total_matriculas y total_crditos matriculados en cada curso, creando el curso si no existe, cada vez que se inserte, se actualice o se borre una tupla de matriculas. Tambin se asume C(1,*)E(1,*) como cardinalidad.
Cursos (C)
cod_c total_matriculas total_creditos
Estudiantes (E) Matriculas (M)

cod_e nombre_e cod_c cod_e creditos
256
create or replace trigger actualiza_cursos after insert or delete or update on M declare cursor c_Totales is select cod_c, count(*) totalmatriculas, sum(creditos) totalcreditos from M group by cod_c begin for v_Totales in c_Totales loop update C set total_matriculas = v_Totales.totalmatriculas total_creditos = v_Totales.totalcreditos where cod_c = v_Totales.cod_c; if sql%notfound then insert into C (cod_c, total_matriculas, total_creditos) values(v_Totales.cod_c, v_Totales.totalmatriculas, v_Totales.totalcreditos); end if; end loop; End actualiza_cursos;
257

Data Bases One I-2011

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Data Bases One I-2011

Transféré par

Droits d'auteur :

Formats disponibles

Escuela de Ingeniera de Sistemas e Informtica

Curso de Bases de datos

Contenido del curso

Sistema de notas: (Todos los previos con igual valor)

1. Introduccin a las Bases de datos

Concurso de un DBMS en la E/S

1.3 Tipos de usuarios de una Base de datos

1.4 Operaciones de E/S en una Base de datos

FS Disco Driver bloques

2. Organizaciones bsicas de archivos

2.1 Organizacin consecutiva.

2.2 Organizacin secuencial (SAM).

Actualizacin de archivos secuenciales

Correccin Digitacin Trascripcin Transaccin Si Si No

De los errores al actualizar archivos secuenciales

2.3 Organizacin relativa

b) Direccionamiento por tablas

Problema: No es prctico mantener la tabla en orden lgico

c) Direccionamiento por algoritmos. Los pasos son:

2.4 Organizacin directa (DAM).

2.5 Organizacin secuencial indexada (ISAM)

Archivo secuencial indexado con una insercin

Archivo secuencial indexado simple y con ndices completos

Archivo de datos Archivo de ndices de primer nivel

Archivo de ndices de segundo nivel

Archivo secuencial indexado compuesto y con ndices escasos

Actualizacin de archivos ISAM

De los errores al actualizar archivos ISAM

3. Organizacin de archivos para DBMS

Buscar acceso por claves mltiples, es difcil con las

3.1 Organizacin inversa

Archivo de ndices de primer nivel

Archivo con organizacin inversa con una insercin

Archivo de ndices de primer nivel

Contina en la siguiente diapositiva

Archivo con organizacin inversa despus de insertar un nuevo registro

Archivo con organizacin inversa con una eliminacin

Archivo de ndices de primer nivel

Archivo con organizacin inversa despus de eliminar un registro

Archivo con organizacin inversa con una modificacin

Archivo de ndices de primer nivel

Archivo con organizacin inversa despus de modificar un registro

3.2 Organizacin multilista

Archivo de ndices de primer nivel

Contina en la siguiente diapositiva

Tabla de referencia para consulta de departamento = A OR categora = 1

Archivo con organizacin multianillo

Actualizacin de una Base de datos

Correccin Digitacin Trascripcin Transaccin Si Si Si

De los errores al actualizar una Base de datos

4. Niveles de una Base de datos

Nivel conceptual Vista de todos los usuarios

Nivel interno Vista del sistema operativo

5. Propiedades de una Base de datos

CON = CON + 100 Regrabe cuentas

Registro final SAL CON RET 200 100 0

6. Software complementario de un DBMS

8. El modelo relacional de Bases de datos

Ejemplo: Obtener la vista de la tabla P cuyas partes sean de color rojo.

snombre Salazar Corona

ciudad Londres Londres

snombre Salazar Jaimes

ciudad Londres Pars

AUB S# snombre s1 s2 s4 Salazar Jaimes Corona