Curso de base de datos para la Maestría en Tecnologias de Información del Centro Universitario de Ciencias Económico Administrativas de la Universidad de Guadalajara. Es un curso de 16 semanas que describe los fundamentos del modelo relacional y concluye con una introducción al modelo orientado a objetos y objeto-relacional.
1. Base de Datos
M. Cs. Javier González Sánchez
javiergs@acm.org
febrero-junio de 2005
2. Universidad de Guadalajara
Centro Universitario de Ciencias Económico Administrativas
Coordinación de Investigación y Postgrado
Maestría en Tecnologías de la Información
javiergs@acm.org 2
3. # clase evaluación
01. (280804) 00. Presentación del Curso Examen de ubicación
01. Conceptos Generales
02. Historia
03. Arquitectura y Sistema de BD
02. (040904) 04. Modelo ER Practica con ER
03. (110904) 05. Almacenamiento físico
06. Lenguajes
04. (180904) 07. Modelo Relacional Examen de repaso
05. (250904) 08. Álgebra Relacional
06. (021004) 08. Álgebra Relacional Examen de repaso
Ejercicio
07. (091004) 09. SQL Proyecto parcial
10. RDBMS y otras herramientas
11, Proyecto
08. (161004) Examen de periodo parcial
13. Introducción a Normalización
09. (231004) 14. Normalización (dependencias y descomposición) Modelo Relacional
15. Descomposición
16. Normalización multivaluada (dependencias y descomposición)
10. (301004) 17. Practica Relacional
11. (061104) 18. Modelo Objeto y Objeto - Relacional
19. Entrega del proyecto final
12. (131104)
13. (201104)
14. (271104)
15. (041204) 20. Examen Final
javiergs@acm.org 3
5. Objetivo
Conceptos
Diseño de base de datos
modelado y normalización
Implementación de base de datos
lenguajes y facilidades (interfaces)
estado del arte: distribuidas, espaciales, orientadas a
objetos, relacionales, otras …
javiergs@acm.org 5
6. Antecedentes
Programación
Estructura de datos
Organización computacional
pre - requisito
Sistemas operativos avanzados *
Programación avanzada *
Ingeniería de Software *
javiergs@acm.org 6
7. Evaluación
25% examen parcial:
25% examen final:
30% proyecto:
20% tareas (ajenas al proyecto) y ejercios en clase
100%
javiergs@acm.org 7
8. Bibliografía
Fundamentals of database systems
Ramez Elmasri, Shamkant B. Navathe
Addison-Wesley, 2000, 3ra edición.
Database systems : the complete book
Héctor García-Molina, Jeffrey D. Ullman, Jennifer Widom.
Prentice Hall, 2002.
An introduction to database systems
C. J. Date
Pearson / Addison Wesley, 2004. 8va. Edition.
javiergs@acm.org 8
9. Referencias
Introducción a las bases de datos
http://rinconprog.metropoliglobal.com/CursosProg/BDatos/IntroBD/index.php?cap=2
Object Oriented Data Bases
javiergs@acm.org 9
12. BD, BDMS, sistema de BD
Base de Datos
Colección de datos
Relación lógica y coherente
Diseño especifico
DBMS
Programa
Administrador
Sistema de base de datos
DBMS + DB
javiergs@acm.org 12
13. Esquema del Sistema
DB aplicación
query compilador
concurrencia DBMS DDL compiler
administrador
data Meta data
catalogo
javiergs@acm.org 13
14. Ciclo de Desarrollo
Definir [A&D]
especificar tipos
Construir
almacenar
Manipular
consulta, actualizacion, etc
javiergs@acm.org 14
15. Conceptos
Meta-datos: Relación
esquemas = intención
Restricción de
Instancias: integridad
datos = extensión
estados Backup (respaldo)
Vistas Recovery
Operación abstracta (recuperación)
Concurrencia
Transacción
Persistencia Escalabilidad
Y hablando de BD versus FileSystems …
javiergs@acm.org 15
17. Historia
1945 cintas y búsqueda lineal
1959 acceso aleatorio a datos en almacenamiento
electrónico
1960 modelo jerárquico, en red y multiusuario
1970 Ted Codd presenta el modelo relacional
1976 Chen presenta el modelo entidad relación
1976 Lenguajes de consulta: SQL, QBE, QUEL
1980 DBMS para PC (Dbase, Paradox)
1983 DBMS comerciales: Oracle, Sybase, Informix
1985 SQL estandar preliminar
1990 Incorporación de capacidades y
actividades deductivas, espaciales,
temporales y multimedia.
1990 Paralelismo
javiergs@acm.org 17
19. Modelo de Datos
Niveles de abstracción
Ocultar detalles del almacenamiento
físico
Describir conceptualmente la estructura
de la base de datos: tipos, relaciones,
restricciones, operaciones (lenguaje).
javiergs@acm.org 19
20. Modelo de Datos
Conceptual: alto nivel
MODELO ER - Entidad, atributo, relación
Representativo:
Clases, registros
MODELO RELACIONAL, RED, JERARQUICO, OOP
FISICO: nivel bajo
Rutas (paths)
Almacenamiento físico
javiergs@acm.org 20
21. Arquitectura 3 capas
Externo: (vistas de usuario)
esquema de nivel alto o medio
Independencia Conceptual:
lógica de datos esquema de nivel alto o medio
Mapeo: transformación de petición/respuesta
Independencia
física de datos Interna: almacén físico
javiergs@acm.org 21
22. Clasificación de sistemas de BD
Por modelo de datos:
Relacional (alto nivel) -> tablas, lenguaje alto nivel
Red-> registros, embebido a lenguajes varios
Jerárquico-> árboles, sin lenguaje especial
OOP -> objetos/clases,
Por Usuarios:
Simple y multiusuario
Por sitios:
Centralizado y distribuido y homogéneo o heterogéneo
Por costo:
Por propósito:
General o especial
javiergs@acm.org 22
23. T1: conceptos
Lectura del libro de texto
• Conceptos generales
• Modelo Entidad - Relación
javiergs@acm.org 23
27. Modelo ER
Modelo de alto nivel
i.e. no es un modelo representativo o de implementación.
ES UN MODELO CONCEPTUAL
para la construcción de esquemas
analicemos el modelo simple
javiergs@acm.org 27
28. Modelo ER
Datos persistentes programación
problema
transacciones Reglas del negocio
requerimientos
análisis
ALTO NINEL: UML
Diseño conceptual Diagrama de flujo
Schemas diseño Etc.
Tipos, relaciones,
constraint
implementación
Lenguaje de
DBMS Programación
Modelo de
+
Implementación
+ Compilación
Modelo Físico
javiergs@acm.org 28
29. Construcción: entidad
Tipo de Entidad (entity type) intencion
nombre + atributos
acaso es una clase ?
Entidad = dato = “cosa” en el mundo
acaso un objeto? extension
Entidad y Entidad frágil.
Sustantivo singular
javiergs@acm.org 29
30. Construcción: atributo
Tipos de Atributos:
Simple / (compuesto) una direccion
Monovaluado / {multivaluado} un color, un grado academico
Almacenado/derivado edad y fecha
Null
Llave
javiergs@acm.org 30
31. Construcción: relación
Tipo de Relación : asociación entre Tipos Entidad.
Instancia de Relacion:_________________
Grado # de participantes (binaria, ternaria)
Cardinalidad algo asi 1:N, 1:1, M:N …
Participacion total (obligada) o parcial
Rol aporte de la entidad a la relacion
Relacion Recursiva ________________
Objetos tienen o llaves foraneas ?
Atributos en relaciones
Verbo
javiergs@acm.org 31
32. Diagramas ER
Entity type Entity type frágil
Atributo
Atributo Compuesto
multivalor
Atributo Llave
Atributo
Atributo
Atributo derivado
Llave parcial
Llave parcial
relación
javiergs@acm.org 32
37. Modelo ER
Almacenamiento físico
Organización de datos en registros y archivos en un medio de
almacenamiento
Medio primario = rápido y limitado
Medio secundario = lento y extenso, de bajo costo
javiergs@acm.org 37
38. Arquitectura
Bit
Byte
Pista
Unidad de transferencia: Cilindro
Sectores HW
Bloque
format
Bloque SW
Dirección: Ínter bloques (gaps)
Superficie:pista:bloque Cluster
Medio secundario
Medio primario
CPU
Rotación
Buffer - RAM
Transferencia
latencia
javiergs@acm.org 38
39. Conceptos
Entidad registro
Tipo entidad metadato (tipos): int date, boolean,
blob (binary large object)
Archivo = secuencia de registros
mismo tamaño
tamaño distinto (separadores)
Registros insertados en bloques:
continuos, ligados, indexados
javiergs@acm.org 39
40. Operaciones sobre Archivos
de recuperación (consulta)
de actualización (inserción, borrado, …)
De 1 resultado
De 1 conjunto de resultados
Archivos volátiles cambios constantes
Archivos estáticos pocos cambios
Archivos con índices busqueda
javiergs@acm.org 40
41. Archivos
Secundario
Primario índice
Orden – sin orden
Único – combinado
Registros fijos - variables
javiergs@acm.org 41
42. Organización de Archivo Primario
Heap file (sin orden):
uso asociado a indice, buena insercion, busqueda
lineal, borrado con fragmentacion…. Reorganizacion
y/o encadenar borrados con marcas. Modificar
implica borrar e insertar. Listado de registros en
orden implica un mergeSort externo.
Sorted file (secuencial):
registros ordenados en disco por un campo dado.
Uso de busqueda binaria. Costoso borrar e insertar.
Transaccion implica copia y anexo de busqueda
lineal a la binaria existente.
javiergs@acm.org 42
43. Organización de Archivo Primario
Hash file: (rowid por registro).
Interno (en RAM): solución de colisión, abierta (sig.
posición), encadenar, multihash
Implica el uso de algoritmos propios de inserción,
borrado y selección
Externo: por posición relativa de bloque o cluster.
complica consulta secuencial. Búsqueda es cara
para campos no llave. Modificar = borrar + insertar
javiergs@acm.org 43
44. Organización de Archivo Primario
Árbol:
como directorio primario y datos en archivo
javiergs@acm.org 44
45. Índices
Índice: estructura de acceso para acelerar
recuperacion de datos
Tipos:
1.basado en archivo ordenado (mononivel)
2. basado en árbol (multinivel)
3. basado en hash
A. índice físico
B. índice lógico
Problemas para insertar y borrar
javiergs@acm.org 45
46. mononivel
Primario:
lista de índice: dirección.
Denso/No denso.
Aplica sobre primario ordenado
Clustering:
campo de orden no es llave (único).
No denso.
Aplica sobre archivo ordenado.
Secundario:
Archivo no ordenado, denso
javiergs@acm.org 46
47. multinivel
Árboles
combaten la desventaja de insertar y borrar en los
mononivel.
árbol B, hash.
javiergs@acm.org 47
50. Lenguajes
DDL (data definition languaje)
Define esquemas conceptuales e interno
SDL (storage definition languaje)
Define esquema interno
VDL (view definition languaje)
Define esquemas de usuarios
DML (data definition languaje)
Usuario, comúnmente denominado query languaje
Y el famoso SQL es un caso típico de ….¿?
javiergs@acm.org 50
51. Tarea 3
Modelo Relacional
• Conversión de ER a R
• Simbología ()
Álgebra Relacional
• Evolucionado la Teoría de conjuntos
Necesitamos un RDBMS
• Oracle, mySQL …
javiergs@acm.org 51
56. Introducción
Codd 1970
Estable y firme a nivel comercial
Considerar: restricción de integridad
Álgebra = colección de operaciones para
manipular… relaciones
Proyección de ER
javiergs@acm.org 56
57. conceptos
Entidad = tabla = relación
Datos = Renglón = tupla
Atributo = campo = atributo
Dominio = tipo = dominio: conjunto de valores atómicos (D) : nombre, tipo, formato,
adicional indicación.
Cardinalidad del dominio (# elementos)
Esquema de relación (R) = R (A1, An). Nombre, lista de atributos (ROLes de dominio)
<intención>
Grado de una relación (# atributos)
Instancia de relación (r) denota r(R) como un conjunto de tuplas (renglón), r = {t1.. tn}
<extensión>
Tupla t = <v1… vn> Lista “ordenada” de valores con vi pertenece a dom(Ai)
Dicese que r(R ) es subconjunto del producto cartesiano de los dominios de R
javiergs@acm.org 57
58. conceptos
Esquema relacional S={R1..Rn} + conjunto de
restricciones de integridad.
Instancia relacional s= {r1..rn} donde ri es instancia
de Ri y satisface las restricciones de integridad.
javiergs@acm.org 58
59. Características de relaciones
Diferencia de relación con archivo/tabla: no orden de
tuplas, tupla como lista ordenada o conjunto de
pares, valores atómicos (no compuesto, no
multivalor)
Se interpreta la relación como sugerencia de entidad,
predicado deductivo, fact.
Notación del modelo
javiergs@acm.org 59
60. constraint
De dominio.
De llave: superllave, llave (superllave
mínima), llaves candidatas, llave primaria
De integridad en entidad: no null en llaves…
De integridad referencial: llaves foraneas
javiergs@acm.org 60
61. Tarea 4
RDBMS: MySQL
Definición de Operaciones
RDBMS: A trabajar!
javiergs@acm.org 61
64. Operaciones
Datos (álgebra):
• recuperación
• Álgebra relacional
• actualización:
• insertar, (tupla) consideración a los 4 constraint
• borrar, (tupla) consideración a 1 constraint
• Modificar (atributo) consideraciones igual que borra
Meta-datos (DDL): creación de esquema
• Crear esquema
• Crear dominios
• Crear relaciones (especifica nombre, atributos, tipos y
constraints)
javiergs@acm.org 64
65. Álgebra relacional
Manipular información
relación relacion
Operaciones:
• Teoría de conjuntos (conjuntos de tuplas):
unión, intersección, diferencia, producto
cartesiano
• Especificas de BD: select, project, join
javiergs@acm.org 65
66. select
Genera un subconjunto de tuplas acorde a una condición
S attributo = valor (RELACION)
Se genera en dominios ordenados (comparación) y no
ordenados. (solo = y !=)
Operador unario (aplica a 1 relación)
Es conmutativo y aplicable en cascada
Grado = # de atributos en la relación
Selectividad = # tuplas obtenidas
javiergs@acm.org 66
67. project
Selecciona atributos descartando otros
Patributo1,…atributoN(RELACION)
Grado = # atributos
Se eliminan tuplas duplicadas como parte de
la operación
Por ello no es conmutativa la operación
javiergs@acm.org 67
68. Expresión Álgebra Relacional
Patributo(Satributo=valor(RELACION))
X Satributo=valor(RELACION);
Y Patributo(X);
Y(nombres atributos nuevos) Patributo(X);
javiergs@acm.org 68
69. Operaciones de conjuntos
Aplican a dos relaciones con el mismo tipo de
tuplas y genera una nueva relación
UNION: unir eliminando duplicados(asociativa y
conmutativa)
INTERSECCION: tuplas en ambos conjuntos
(asociativa y conmutativa)
DIFERENCIA: tupla en A y no en B (no conmutativa)
javiergs@acm.org 69
70. Operaciones de conjuntos
PRODUCTO CARTESIANO: aplicable sobre
relaciones con distintas tuplas (no
compatibles)
Se suman grado de atributos
Se multiplican grado de tuplas
El resultado no es útil. Debe combinarse con
una selección
javiergs@acm.org 70
71. Operaciones de conjuntos
JOIN |X|: combina tuplas relacionadas.
X RELACION|X|att=val RELACION
JOIN genérico: aplica operadores relacionales
EQUIJOIN: aplica solo el operador =
NATURAL JOIN: (*) es un equijoin con 1 atributo
comun
X RELACION*(atts),(atts) RELACION
javiergs@acm.org 71
79. Operadores adicionales
JOIN NATURAL tuplas que no entran a la relación
(y/o null) se eliminan
LEFT OUTER JOIN =|X|
RIGHT OUTER JOIN |X|=
FULL OUTER JOIN =|X|=
OUTER UNION: union de tuplas distintos atributos
(no compatibles)
javiergs@acm.org 79
80. y ahora … ER a Relacional
Artículos de un volumen
Autor(es) de un articulo
Articulo titulo autor edad revisor nombre
Sección nombre, articulo nombre, autor
nombre
Revisor por autor
javiergs@acm.org 80
84. SQL
Comando de SQL.
Recuperación de Datos:
SELECT.
Manipulación de Datos: (DML)
INSERT
DELETE
UPDATE
Definición de Datos (DDL)
CREATE
ALTER
DROP
Seguridad de los Datos:
GRANT
REVOKE
Confirmación
COMMIT
ROLLBACK
javiergs@acm.org 84
85. SQL -DDL
CREATE TABLE PROVEEDORES (
S# CHAR(5) NOT NULL,
SNOMBRE CHAR(20) NOT NULL,
SITUACION SMALLINT NOT NULL,
CIUDAD CHAR(15) NOT NULL,
PRIMARY KEY ( S# ) ) ;
CREATE TABLE PARTES (
P# CHAR(6) NOT NULL,
PNOMBRE CHAR(20) NOT NULL,
COLOR CHAR(6) NOT NULL,
PESO SMALLINT NOT NULL,
CIUDAD CHAR(15) NOT NULL,
PRIMARY KEY ( P# ) );
CREATE TABLE ENVIOS (
S# CHAR(5) NOT NULL,
P# CHAR(6) NOT NULL,
CANT INTEGER NOT NULL,
PRIMARY KEY ( S# , P# ),
FOREIGN KEY ( S# ) REFERENCES PROVEEDORES,
FOREIGN KEY ( P# ) REFERENCES PARTES ) ;
javiergs@acm.org 85
86. SQL-DML
SELECT S#, SITUACION SELECT SELECT *
FROM PROVEEDORES DISTINCT P# FROM
WHERE CIUDAD = ‘París’; FROM ENVIOS; PROVEEDORES;
SELECT PROVEEDORES.S#,PROVEEDORES.SITUACION
FROM PROVEEDORES
WHERE PROVEEDORES.CIUDAD = ‘París’;
SELECT PARTES.P#, ‘Peso en gramos =‘, PARTES.PESO *454
FROM PARTES;
SELECT S# , SITUACION SELECT PROVEEDORES.* ,
FROM PROVEEDOR PARTES.*
WHERE CIUDAD=‘París’ FROM PROVEEDORES, PARTES
ORDER BY SITUACION WHERE PROVEEDORES.CIUDAD =
DESC; PARTES.CIUDAD;
javiergs@acm.org 86
87. SQL-DML
SELECT PRIMERA.S#, SEGUNDA.S#
FROM PROVEEDOR PRIMERA, PROVEEDOR SEGUNDA
WHERE PRIMERA.CIUDAD = SEGUNDA.CIUDAD
AND PRIMERA.S# < SEGUNDA.S#;
SELECT PARTES.*
FROM PARTES
WHERE PARTES.NOMBRE LIKE ‘B%’;
SELECT SUM (CANT) SELECT PROVEEDORES.NOMBRE
FROM ENVIOS FROM PROVEEDORES
WHERE P# = ‘P2’; WHERE S# IN (
SELECT S#
FROM ENVIOS
SELECT P#, SUM (CANT) WHERE P# = ‘P2’
FROM ENVIOS );
GROUP BY P#;
javiergs@acm.org 87
89. Internet + DBMS
Web Server
Internet
Base de datos
Web Client
programación
HTML
Java, PHP, Perl,
Oracle, MySQL,
Python, MS.net, etc
MS-SQL, Informix,
Postgres, etc
javiergs@acm.org 89
90. mySQL
mysqladmin -u root create mydb
mysql -u root mydb < mydb.sql
mydb
Id First Last address position
1 Bob Smith 128 Here St. Marketing Manager
2 Jonh Roberts 45 There St. Telephonist
3 Brad Johnson 1/34 Nowhere Blvd Doorman
javiergs@acm.org 90
94. Tarea 7
PRODUCTOS:
ACTIVIDADES:
Mapa de navegación a
• Interfaces de Usuario
implementar
• para cada rol…
Análisis de Requerimientos
• Funcionalidades esperadas…
(simple)
• Enlaces…
Diseño (simple)
• Interacciones con la BD…
• Análisis y diseño genérico…
BD relacional (revisión)
javiergs@acm.org 94
98. dudas del examen
Como se representa una llave foránea en un
modelo E/R ?!
no existen llaves foráneas en el modelo E/R
Llave primaria, candidata, ajena/foránea
Otras?
javiergs@acm.org 98
100. terminología
relación
A1 A2 An
20
5
… ≠
1
terminología relacional
Modelo Relacional Programador Usuario
relación archivo tabla
tuple (fila) registro fila
atributo campo columna
javiergs@acm.org 100
101. Problemas (caso 1)
Nulos o Y si los
Repetidos Repetidos
Se escriben mal
javiergs@acm.org 101
102. Problemas (caso 2)
Redundancia Employee Salary Project Budget Function
• Desperdicio de Brown 20 Mars 2 technician
espacio
• Actualización Green 35 Jupiter 15 designer
complicada Green 35 Venus 15 designer
Hoskins 55 Venus 15 manager
Anomalía Hoskins 55 Jupiter 15 consultant
• de actualización Hoskins 55 Mars 2 consultant
• de Moore 48 Mars 2 manager
borrado
• de
Moore 48 Venus 15 designer
inserción Kemp 48 Venus 15 designer
Kemp 48 Jupiter 15 manager
javiergs@acm.org 102
103. diseño de base de datos
importancia del modelo relacional
• estructuras amplias y generales
• importante categoría de productos DBMS
mal diseño
• anomalías, redundancia e inconsistencias de la información
• imposibilidad para representar cierta información
metas del diseño
• evitar información redundante y anómala
• asegurar que las relaciones entre los atributos sean representadas
• facilitar la verificación de las actualizaciones
normalización
• conversión de una relación con ciertos problemas a dos o más relaciones
que no tienen tales problemas
• formas normales (Codd)
javiergs@acm.org 103
104. normalización
tipos de anomalías
1NF formas normales
2NF • técnicas para la
prevención
3NF • 1NF, 2NF, 3NF, 4NF,
5NF
BCNF
E. F. Codd (1970)
• 1NF, 2NF, 3NF
4NF Boyce-Codd
• BCNF
5NF
4NF, 5NF
javiergs@acm.org 104
106. esencia de normalización
cada relación normalizada tiene un solo tema
si tiene dos o más, deberá fragmentarse en relaciones
cada vez que se divida una relación, es probable que
surja la necesidad de crear una restricción de
interrelación
cuando se encuentra una relación con anomalías de
modificación, se las elimina dividiendo la relación en
dos o más, cada una de las cuales contendrá un solo
tema
javiergs@acm.org 106
107. Tarea 8
Normalización
Formas normales básicas 1NF, 2NF, 3NF
Adicionalmente BCNF, 4NF y 5NF
javiergs@acm.org 107
110. normalización
Dependencia funcional
1NF
• Monovaluada
2NF
3NF • Nultivaluada
Descomposición
BCNF
• Preservar atributos
• Menor perdida de union
4NF
• Preservar dependencia
5NF • No redundancia
javiergs@acm.org 110
111. dependencia funcional
restricción de integridad para el modelo relacional
describe las relacionales funcionales entre los
atributos de una relación
notación
Y→Z
Ejemplo
• el valor del atributo Salary
depende funcionalmente
del valor atributo Employee
• Employee → Salary
javiergs@acm.org 111
112. dependencia funcional
relación entre uno o más atributos
generalización de la noción de llave
∀ t1, t2 ∈ r ( t1 ≠ t2 ⇒ t1[K] ≠ t2[K] )
notación
α→β
esta dependencia funcional se verifica en R
∀ t1, t2 ∈ r (t1[α] = t2[α] ⇒ t1[β] = t2[β] )
K es un súper llave de R si K → R
K es una súper llave si t1[K]=t2[K] ⇒ t1[R]=t2[R] (es decir, t1=t2)
javiergs@acm.org 112
113. dependencia funcional
Considerando:
A → B
A → C
CG → H
CG → I
B → H
Las dependencias implican lógicamente:
A → H
A BC
CG HI
javiergs@acm.org 113
114. 1NF
cumplir con la definición de una tabla
valores atómicos
valores de un atributo ∈ dominio
cada atributo posee un nombre único
orden de los registros sin importancia
sin tuplas idénticas (llave candidata)
actividad
SID Actividad Cuota
100 Esquí 200
150 Natación 50 SID → Actividad Cuota
175 Squash 50
200 Natación 50
javiergs@acm.org 114
115. ¿ Esta en1NF?
student (matricula, nombre, fecha_nacimiento)
javiergs@acm.org 115
116. 2NF
actividad una relación está en 2NF si todos sus
atributos que no son claves dependen
SID Actividad Cuota
por completo de la clave
100 Esquí 200
100 Golf 65
150 Natación 50 SID Actividad Actividad Cuota
175 Squash 50 100 Esquí Esquí 200
175 Natación 50 100 Golf Golf 65
200 Natación 50 150 Natación Natación 50
200 Golf 65 175 Squash Squash 50
175 Natación
SID Actividad → Cuota 200 Natación Actividad → Cuota
Actividad → Cuota 200 Golf
• Cuota parcialmente dependiente SID Actividad → SID Actividad
• mismas anomalías de modificación
javiergs@acm.org 116
117. 2NF (ejercicio)
Para la relación:
PRESTAMO
( num_socio, nombre_socio, cod_libro, fec_prest, editorial, país )
las claves candidatas son:
(num_socio, cod_libro) y (nombre_socio, cod_libro)
Como 2NF se representa:
PRESTAMO1 ( num_socio, nombre_socio, cod_libro, fec_prest )
LIBRO ( cod_libro, editorial, país )
javiergs@acm.org 117
118. 2NF (conclusión)
una relación está en 2NF si todos sus
atributos que no son claves dependen por
completo de la clave.
¡no pueden existir dependencias parciales!
(en relaciones con llaves compuestas).
javiergs@acm.org 118
120. 3NF
una relación está en 3NF si está
vivienda en 2NF y no tiene dependencias
SID Edificio Cuota Transitivas :
100 Randolph 1200
los atributos que no forman parte de ninguna
150 Ingersoll 1100 clave candidata facilitan información sólo
200 Randolph 1200 acerca de la(s) clave(s) y no acerca de otros
250 Pitkin 1100 atributos
300 Randolph 1200
SID Edificio Edificio Cuota
SID → Edificio
Edificio → Cuota 100 Randolph Randolph 1200
150 Ingersoll Ingersoll 1100
200 Randolph Pitkin 1100
250 Pitkin Edificio Cuota → Edificio Cuota
300 Randolph
SID Edificio → SID Edificio
javiergs@acm.org 120
121. 3NF (ejercicio)
PRESTAMO1( num_socio, nombre_socio, cod_libro, fec_prest )
LIBRO( cod_libro, editorial, país )
¿ESTA EN 3NF ?
Solución:
LIBRO1( cod_libro, editorial )
EDITORIAL( editorial, país )
javiergs@acm.org 121
122. ¿Esta en 2NF, 3NF?
subject (clave_curso, nombre, instructor, office)
clave_curso -> nombre
clave_curso -> instructor
instructor -> office
s (clave_curso, nombre, instructor)
ins (instructor, office)
javiergs@acm.org 122
123. BCNF
• un estudiante puede tener una o más especialidades
• una especialidad puede tener varios miembros de la facultad como consejeros
• un miembro de la facultad sólo imparte asesoría en una área de especialidad
¿en 1NF?
asesor
¿en 2NF?
SID Especialidad NombreF ¿en 3NF?
100 Matemáticas Cauchy ¿existen anomalías de modificación?
150 Psicología Jung
200 Matemáticas Riemann una relación está en BCNF si
250 Matemáticas Cauchy cada determinante irreducible
300 Psicología Perls (izq) es una clave candidata
300 Matemáticas Riemann
i.e.
SID Especialidad → NombreF
SID NombreF → Especialidad X A y A no esta en X
NombreF → Especialidad X es llave
javiergs@acm.org 123
124. BCNF
una relación está en BCNF si cada determinante es una
clave candidata est-ase
SID NombreF
asesor 100 Cauchy
SID Especialidad NombreF 150 Jung
100 Matemáticas Cauchy 200 Riemann
150 Psicología Jung 250 Cauchy
200 Matemáticas Riemann 300 Perls
250 Matemáticas Cauchy 300 Riemann
300 Psicología Perls ase-materia
300 Matemáticas Riemann NombreF Materia
Cauchy Matemáticas
SID Especialidad → NombreF Jung Psicología
SID NombreF → Especialidad
NombreF → Especialidad
Riemann Matemáticas
Perls Psicología
javiergs@acm.org 124
125. 3NFvs BCNF
La mayoría de las relaciones que están en 3NF están también
en BCNF.
Infrecuentemente, una relación 3NF no está en BCNF y ésta
sucede solamente si:
(a) las llaves candidatas en la relación son llaves compuestas
(es decir, no son atributos solos),
(b) existe más de una llave candidata en la relación,
(c) las llaves no son disjuntas, es decir, algunas cualidades en
las llaves son comunes.
El BCNF difiere de 3NF solamente cuando hay mas de una
llave candidata, las llaves son compuestas y traslapadas.
javiergs@acm.org 125
128. descomposición
para poder eliminar algunas de las anomalías, es necesario
descomponer la relación en dos o más relaciones.
El proceso de la descomposición de una relación R en un sistema
de las relaciones R1 , R2 ..., se basa en identificar diversos
componentes. Las relaciones descompuestas R1 , R2 ..., R de n son
proyecciones de R
características deseables de la buena descomposición e
identificamos las dificultades que pueden presentarse si la
descomposición se hace sin cuidado adecuado.
Las características deseables de una descomposición son:
Preservación de atributos (obvio)
menor perdida de ensamble la descomposición (natural join)
Preservación de dependencia funcionales
Carencia de la redundancia
javiergs@acm.org 128
129. menor perdida de ensamble
Student
Course
Date
Room
Instructor
Satisfacer:
R1 intersection R2) -> (R1 - R2)
(R1 intersection R2) -> (R2 - R1)
javiergs@acm.org 129
130. Carencia de redundancia
Descomposición implica re-unificación
NATURAL JOIN
VS
JOIN
javiergs@acm.org 130
131. Tarea 9
Revisar descripción proyecto
Diagrama relacional a BCNF
javiergs@acm.org 131
134. Caso de estudio
A) ENCUESTAR ALUMNOS
B) ALUMNO GRUPO PERO ADEMAS TALLERES DONDE SE JUNTAN
C) MAESTROS VARIAS MATERIAS Y/O LA MISMA
MATERIA EN VARIOS GRUPOS TURNOS
D) DEPARTAMENTO Y DIRECTORES
E) GRADO, GRUPO, TURNO, CICLO
E) PROMEDIO PROFESOR POR GRUPO
F) PROMEDIO TOTAL PROFESOR
G) PREGUNTAS 10, PARA EVALUACION
H) ALUMNOS REPITEN SEMESTRE
javiergs@acm.org 134
138. 4NF
estudiante(SID, Especialidad, Actividad)
clave: (SID, Especialidad, Actividad)
SID Especialidad Actividad
100 Música Natación
100 Contabilidad Natación
100 Música Tenis
100 Contabilidad Tenis
150 Matemáticas Carrera
javiergs@acm.org 138
139. 4NF
¿relación entre SID y Especialidad?
y ¿entre SID y Actividad?
SID Especialidad Actividad
100 Música Natación
100 Contabilidad Natación
100 Música Tenis
100 Contabilidad Tenis
150 Matemáticas Carrera
dependencias de valores múltiples
javiergs@acm.org 139
140. 4NF
dependencias de valores múltiples conducen a anomalías de
modificación
dependencias múltiples:
SID →→ Especialidad
SID →→ Actividad
SID Especialidad Actividad
100 Música Natación
100 Contabilidad Natación
100 Música Tenis
100 Contabilidad Tenis
150 Matemáticas Carrera
javiergs@acm.org 140
141. 5NF
En algunos casos raros, una relación puede tener problemas como
anomalías de la información ( redundante ) y de la actualización
no puede ser descompuesto en dos relaciones para quitar los problemas.
En tales casos puede ser posible descomponer la relación en tres o más
relaciones usando el 5NF.
La quinto forma normal se ocupa de ensamblar-dependencias como una
generalización del MVD (Dependencias Multivaluadas)
R (departamento, materia, estudiante)
R1 (departamento materia) y R2 (departamento,
estudiante)
R1 (depto, materia), R2 (depto, estudiante) y
R3(materia estudiante)
javiergs@acm.org 141
142. Tarea 10
Una última exploración al modelo relaciónal:
Almacenamiento y BUSQUEDA en TEXTO
COMPLETO (full text search)
Ejemplifica con mySQL. ¿es útil para el proyecto ?
La moda de XML ¿sirve en BD?
Ejemplifica con mySQL. ¿es útil para el proyecto ?
javiergs@acm.org 142
145. MySQL
Instalar MySQL Server and Client 4.0.18
mysqladmin -u root create cucea
mysql -u root mydb < archivo.sql
Instalar EMS MySQL manager
http://ems-hitech.com/mymanager/download.phtml
javiergs@acm.org 145
146. Modelo relacional (envío)
Caso de Estudio:
a) Llevarlo a BCNF, producto a entregar PPT
b) Llevarlo a SQL-DDL, incluir a PPT
preguntas respuestas c) Construir el modelo en un R-DBMS,
/data/base de datos (cucea#)
d) Construir SQL-DML para las consultas:
reactivos alumno Calcular la calificación de examen por
alumno
Mostrar las preguntas de un examen para un
alumno en particular, con la respuesta
examen reporte correcta y la respuesta marcada por el
alumno
etc.…
javiergs@acm.org 146
148. Tarea 9
Evolucionando a Objetos:
• Generar un diagrama de clases del modelo
relacional del ejercicio anterior
• Lee el siguiente articulo:
Object-Relational Database Systems - The Road Ahead
http://www.acm.org/crossroads/xrds7-3/ordbms.html
javiergs@acm.org 148
151. respecto a su tarea
Limitaciones del modelo de datos relacional
Bases de datos con objetos
Bases de datos con tipos de dato complejos
Diferencias entre BD:
• orientado a objeto
• objeto-relacional
javiergs@acm.org 151
152. agenda
La tradición del modelo relacional
el modelo de datos con objetos
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org 152
153. necesidades para un BDMS
Considerar:
• Incremento en la cantidad y complejidad de información que las
aplicaciones deben considerar: documentos, video, multimedia,
audio, CAD, mundos virtual, etc. Inmerso todo estos con
información tradicional.
• Reducción en el tiempo para desarrollar aplicaciones
Modelos:
• Object-Oriented programming
• RDBMS: lenguaje de consultas, optimización, control de
concurrencia, tolerancia y control de fallas, indexado, etc.
javiergs@acm.org 153
155. RDBMS
Solo soporta pequeñas colecciones de datos de tipo simple (enteros,
flotantes, fechas, cadenas)
No se permiten conjuntos como tipo de atributos
No considera el concepto de herencia
No se consideran tipos complejos salvo BLOB (binary large object) y
CLOB (character large object)
Dificultad para interactuar entre el lenguaje de acceso a datos (SQL –
declarativo-) y el lenguaje de construccion de aplicaciones
(procedural C o Java).
Soluciones ….
Inconvenientes….
javiergs@acm.org 155
156. ODBMS
Una base de datos Orientada a Objetos es un gestor de
almacenamiento persistente para objetos… y los objetos se
pueden TAMBIEN crear en un lenguaje de programación
Orientado a Objetos
Sistemas de base de datos con Objetos:
• Object-Oriented Database Systems:
• alternative to relational systems
• Object-Relational Database Systems:
• Extension to relational systems
Ventas: RDBMS ( $8 billion), OODMS ($30 million) world-wide*
*2003, Zaiane O, Canadá
javiergs@acm.org 156
158. agenda
La tradición del modelo relacional
el modelo de datos con objetos
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org 158
159. Object Data Model
Modelo en la capa de implementación
Base de datos contiene una colección de objetos (similar al
concepto de tuplas)
Un objeto tiene un ID único (OID) y una colección de objetos
con propiedades similares es llamada clase.
(… y una colección de tuplas era ? )
Las propiedades de un objeto se especifican con ODL
Y los objetos son manipulados utilizando OML.
javiergs@acm.org 159
160. Propiedades de objeto
atributos: atómicos o estructurados (conjuntos, listas, arreglos )
relaciones: referencia a objeto o conjuntos de objeto
métodos: funciones que pueden ser aplicadas a objetos de una
clase
para recordar:
• Un valor tiene un tipo
• Un objeto tiene una clase
javiergs@acm.org 160
161. Abstract Data Type
Característica clave de DB con objetos es la
posibilidad para el usuario de definir nuevos tipos de
forma arbitraria.
Un nuevo tipo puede definirse con métodos
asociados para manipularlos.
El nuevo tipo y sus métodos es llamado ADT
DBMS tienen tipos pre - construidos
Pero… como crear nuevos tipos ?
javiergs@acm.org 161
162. Encapsulamiento
encapsulamiento = estructura de dato + operaciones
La principal característica de los lenguajes OO
Oculta al ADT por lo que se dice que un ADT es un
tipo opaco
El DBMS no requiere conocer como el ADT es
almacenado o como trabajan sus métodos. Solo
requiere del conocimiento de los métodos
disponibles y como comunicarse con ellos (entradas
y salidas)
javiergs@acm.org 162
163. Herencia
Jerarquia de tipos complejos (clases)
Permitir la definicion de nuevos tipos a partir de otros
tipos existentes
Sobrecarga y Sobreescritura de metodos
Herencia multiple
Herencia selectiva
javiergs@acm.org 163
164. estructuras
Tipos estructuados comunes
combinan tipos atomicos y tipos definidos por el usuario para crear
estructuras mas complejas
ROW(n1, t1, …nn,tn) : tupla de N campos
listof(base): lista de elementos de tipo base
ARRAY(base): arreglo de elementos de tipo base
setof(base): conjunto deelementos de tipo base sin duplicados
No todos estos tipos de colecciones son soportados en todos los
sistemas
javiergs@acm.org 164
165. Objeto, OID y referencia
Un objeto tiene un OID para objetos que son UNICOS en la
base de datos.
Referencias o Tipos referenciados
REF (tipo)
Tienen como valor OID
Asi que un objeto te tipo REF(base) es un apuntdor a un
objeto de la clase base
javiergs@acm.org 165
166. Agenda
La tradición del modelo relacional
el modelo de datos con objetos
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org 166
167. OODBMS
Punto de vista centrado en objetos
Localización ocasional de información en un
repositorio de objetos
No cuenta con un DML optimizado en la
practica
javiergs@acm.org 167
168. ODL en OODBMS
Soporta tipos atomicos asi como set, list, array and struct type
Interface defines a class
interface Movie (key movieName)
{
attribute date start;
attribute date end;
attribute string movieName;
relashionship Set<Theater> ShownAt inverse Theater::nowShowing;
}
interface Theater (key theaterName)
{ attribute string theaterName;
attribute string address;
attribute integer ticketPrice;
relationship Set <Movie> nowShowing inverse Movie::shownAt;
float numshowing() raises(errorCountingMovies);
}
javiergs@acm.org 168
169. OML en OODBMS
Similar a SQL: se define como una extension de SQL
Find the movies and theaters such that the theaters show more than one
movie.
SELECT mname: M.movieName, tname: T.theaterName
FROM Movies M, M.shownAt T
WHERE T.numshowing() >1
Find the different ticket prices and the average number of movies shown at
Theaters with that ticket price.
SELECT T.ticketPrice,
avgNum:AVG( SELECT P.T.numshowing() FROM partition P )
FROM Theaters T
GROUP BY T.ticketPrice
javiergs@acm.org 169
171. Agenda
La tradición del modelo relacional
el modelo de datos con objetos
Object-Oriented Database Systems
Object-Relational Database Systems
javiergs@acm.org 171
172. ORDBMS
Cual es la novedad? (SQL 1999)
soporte de almacenamiento y manipulación de tipos
de dato largos (BLOB y CLOB)
Mecanismos para extender la base de datos con
tipos específicos y métodos:
• – User defined types
• – User defined procedures
• – Operators for structured types
• – Operators for reference types
• -- Support for inheritance
javiergs@acm.org 172
173. Características OOR (oracle)
Tablas de objetos
CREATE TYPE person AS OBJECT (
name VARCHAR2(30),
phone VARCHAR2(20) );
CREATE TABLE person_table OF person;
INSERT INTO person_table VALUES
person("John Smith", "1-800-555-1212");
SELECT VALUE(p) FROM person_table p
WHERE p.name = "John Smith";
javiergs@acm.org 173
174. Características OOR (oracle)
Metodos
CREATE TYPE Rectangle_typ AS OBJECT (
len NUMBER,
wid NUMBER,
MEMBER FUNCTION area RETURN NUMBER
);
CREATE TYPE BODY Rectangle_typ AS
MEMBER FUNCTION area RETURN NUMBER IS
BEGIN
RETURN len * wid;
END area;
END;
javiergs@acm.org 174
175. Características OOR (oracle)
Referencias
CREATE TABLE people (
id NUMBER(4)
name_obj name_objtyp,
address_ref REF address_objtyp SCOPE IS
address_objtab);
juan.deref(address_ref).street
SELECT REF(po) FROM purchase_order_table po
WHERE po.id = 1000376;
javiergs@acm.org 175
176. Características OOR (oracle)
Colección: Tablas anidadas
CREATE TYPE PointType AS OBJECT (
x NUMBER,
y NUMBER);
CREATE TYPE PolygonType AS TABLE OF PointType;
CREATE TABLE Polygons (
name VARCHAR2(20),
points PolygonType)
NESTED TABLE points STORE AS PointsTable;
javiergs@acm.org 176
177. Características OOR (oracle)
Colección: VARRAY
Define una colección de máximo N elementos
del mismo tipo
Definir el tipo obviamente no consume espacio
(no genera instancias o campos por si mismo)
CREATE TYPE prices
AS VARRAY(10) OF NUMBER(12,2);
javiergs@acm.org 177
178. Características OOR (oracle)
Herencia de Tipos ó creacion de subtipos:
CREATE TYPE Person_t AS OBJECT
( ssn NUMBER,
name VARCHAR2(30),
address VARCHAR2(100)) NOT FINAL;
CREATE TYPE Student_t UNDER Person_t
( deptid NUMBER, major VARCHAR2(30)) NOT FINAL;
CREATE TYPE Employee_typ UNDER Person_t
( empid NUMBER, mgr VARCHAR2(30));
CREATE TYPE PartTimeStud_t UNDER Student_t
( numhours NUMBER);
javiergs@acm.org 178
179. Características OOR (oracle)
Sobrecarga y Sobre escritura
CREATE TYPE MyType_typ AS OBJECT (...,
MEMBER PROCEDURE Print(),
MEMBER PROCEDURE foo(x NUMBER), ...)
NOT FINAL;
CREATE TYPE MySubType_typ UNDER MyType_typ
(...,
OVERRIDING MEMBER PROCEDURE Print(),
MEMBER PROCEDURE foo(x DATE), ...);
javiergs@acm.org 179
180. Tarea 10
Oracle9i Application Developer's Guide - Object-Relational Features
Release 2 (9.2)
Part Number A96594-01
Chapter 9:
A Sample Application Using Object-Relational Features
http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96594/adobjxmp.htm
javiergs@acm.org 180