200508 - Bases de Datos

Base de Datos

M. Cs. Javier González Sánchez
javiergs@acm.org
febrero-junio de 2005

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

# 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

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

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

Evaluación
25% examen parcial:

25% examen final:

30% proyecto:

20% tareas (ajenas al proyecto) y ejercios en clase

100%

javiergs@acm.org 7

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

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

E1 - examen de Ubicación

javiergs@acm.org 10

01. Conceptos generales

javiergs@acm.org 11

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

Esquema del Sistema

DB aplicación

query compilador
concurrencia DBMS DDL compiler
administrador

data Meta data
catalogo

javiergs@acm.org 13

Ciclo de Desarrollo

Definir [A&D]
especificar tipos

Construir
almacenar

Manipular
consulta, actualizacion, etc

javiergs@acm.org 14

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

02. Historia

javiergs@acm.org 16

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

03. Sistemas y Arquitecturas de Bd

javiergs@acm.org 18

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

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

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

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

T1: conceptos
Lectura del libro de texto

• Conceptos generales
• Modelo Entidad - Relación

javiergs@acm.org 23

04. Modelo ER

javiergs@acm.org 25

E2 - conceptos

javiergs@acm.org 26

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

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

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

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

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

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

A practicar…

javiergs@acm.org 33

Tarea 2
Modelo ER del sistema de
encuestas en línea

javiergs@acm.org 34

05. Almacenamiento físico

javiergs@acm.org 36

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

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

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

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

Archivos

Secundario

Primario índice

Orden – sin orden
Único – combinado
Registros fijos - variables

javiergs@acm.org 41

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

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

Árbol:
como directorio primario y datos en archivo

javiergs@acm.org 44

Í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

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

multinivel
Árboles
combaten la desventaja de insertar y borrar en los
mononivel.

árbol B, hash.

javiergs@acm.org 47

06. Lenguajes

javiergs@acm.org 48

Lenguajes

javiergs@acm.org 49

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

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

Examen de Repaso

javiergs@acm.org 53

07. Modelo Relacional

javiergs@acm.org 54

Modelo Relacional

javiergs@acm.org 55

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

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

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

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

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

Tarea 4

RDBMS: MySQL

Definición de Operaciones

RDBMS: A trabajar!

javiergs@acm.org 61

08. Álgebra Relacional

javiergs@acm.org 63

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

Á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

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

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

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

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

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

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

problemas !
Selección, Proyección, Unión, Diferencia y
Producto.

Intersección =

Join =

Natural Join =

javiergs@acm.org 72

problemas !

División:
los Y atributos en R y no en S, equivale a:

T1 Py(R)
T2 Py((SXT1) –R)
T T1-T2

javiergs@acm.org 73

Tarea 5

Traducción de modelo ER a Relacional

Dudas…. a estudiar

javiergs@acm.org 74

server
ftp.dgproject.com
cucea@dgproject.com | cucea
/home/cucea/public_html/
cucea-XX

http://cucea.dgproject.com

javiergs@acm.org 76

Examen de Repaso

javiergs@acm.org 77

Operaciones adicionales

Funciones:
SUM, AVERAGE, MAX, MIN, COUNT

atributoFfuncion atributo ( relación)

javiergs@acm.org 78

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

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

Ejercicio

javiergs@acm.org 81

09. SQL

javiergs@acm.org 83

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

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

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

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

10. Herramientas

javiergs@acm.org 88

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

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

php
$db = mysql_connect("localhost", "root");

mysql_select_db("mydb",$db);

$result = mysql_query($sql);

$result = mysql_query("SELECT * FROM employees",$db);

while ($myrow = mysql_fetch_array($result)) {
echo $myrow["id"].$myrow["first"].$myrow["last"].”<BR>”;
}

javiergs@acm.org 91

11. Proyecto

javiergs@acm.org 92

publicaciones electrónicas

internet

usuarios
Editores
Árbitros
usuarios operativos

javiergs@acm.org 93

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

12. Examen Parcial

javiergs@acm.org 96

Examen parcial

javiergs@acm.org 97

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

13. Introducción a la Normalización

javiergs@acm.org 99

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

Problemas (caso 1)

Nulos o Y si los
Repetidos Repetidos
Se escriben mal


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


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)


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


esencia de normalización = anomalías
de modificación solución:
anomalía de eliminación descomposición
anomalía de inserción

actividad est-act act-cost
SID Actividad Cuota SID Actividad Actividad Cuota
100 Esquí 200 100 Esquí Esquí 200
150 Natación 50 150 Natación Natación 50
175 Squash 50 175 Squash Squash 50
200 Natación 50 200 Natación

SID → Actividad Cuota SID → Actividad Actividad → Cuota


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

Tarea 8
Normalización

Formas normales básicas 1NF, 2NF, 3NF

Adicionalmente BCNF, 4NF y 5NF


14. Normalización simple
(dependencias y descomposición)

normalización
Dependencia funcional
1NF
• Monovaluada
2NF
3NF • Nultivaluada

Descomposición
BCNF
• Preservar atributos
• Menor perdida de union
4NF
• Preservar dependencia
5NF • No redundancia


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


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)


Considerando:
A → B

A → C

CG → H

CG → I

B → H

Las dependencias implican lógicamente:
A → H

A BC

CG HI


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


¿ Esta en1NF?

student (matricula, nombre, fecha_nacimiento)


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


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 )


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).


¿Esta en 2NF?
student (matricula#, nombre, clave_curso#, curso)
matricula -> nombre
clave_curso -> curso

S1 (matricula, nombre)
S2 (clave_curso, curso)
SC (matricula, clave_curso)


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


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 )


¿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)


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


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


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.


¿Esta en 3NF, BCNF?
enrol (sno, sname, cno, cname, date-enrolled)

Llaves candidatas:

(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)

Problemas: Solucion:

sno -> sname (sno, sname)
cno -> cname (cno, cname)
(sno, cno, date-of-enrolment)


15. Descomposición


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


menor perdida de ensamble
Student
Course
Date
Room
Instructor

Satisfacer:

R1 intersection R2) -> (R1 - R2)

(R1 intersection R2) -> (R2 - R1)


Carencia de redundancia

Descomposición implica re-unificación

NATURAL JOIN

VS

JOIN


Tarea 9
Revisar descripción proyecto

Diagrama relacional a BCNF


16.Caso de Estudio
(encuestas a preparatoria)

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


propuesta


16. Normalización multivaluada
(dependencias y descomposición)

dependencias multivaluadas
Un atributo multivaluado (proyecto):

emp (e#, dept, salary, proyecto)

Dos atributos multivaluados independientes

programmer (emp_name, qualifications, languages)

¿sera 3NF? ¿sera BCNF?


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


4NF
¿relación entre SID y Especialidad?
y ¿entre SID y Actividad?

100 Música Tenis
dependencias de valores múltiples

4NF
dependencias de valores múltiples conducen a anomalías de
modificación

dependencias múltiples:
SID →→ Especialidad
SID →→ Actividad

100 Música Tenis

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)


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 ?


17. Practica Relacional


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


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.…


SQL-DDL
CREATE TABLE `tabla` (
ìd` tinyint(4) unsigned NOT NULL auto_increment,
`referencia` tinyint(4) unsigned NOT NULL default '0',
PRIMARY KEY (ìd`),
UNIQUE KEY (`referencia`),
FOREIGN KEY (`referencia`) REFERENCES `catalogo` (ìd`)
) TYPE=InnoDB

CREATE TABLE `catalogo` (
ìd` tinyint(4) unsigned NOT NULL auto_increment,
`nombre` varchar(20) default NULL,
PRIMARY KEY (ìd`),
UNIQUE KEY (ìd`)
) TYPE=InnoDB

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


18. Modelo objeto y objeto-relacional


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


agenda

La tradición del modelo relacional

el modelo de datos con objetos

Object-Oriented Database Systems

Object-Relational Database Systems


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.


relaciones vs objetos


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….


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á


DBMS clasificación


agenda





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.


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


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 ?


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)


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


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


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


Agenda





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


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);
}


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


lenguajes procedurales


Agenda





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


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";


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;


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;


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;


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);


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);


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), ...);


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


practica


19. Entrega de proyecto final


20. Examen final


200508 - Bases de Datos

Más contenido relacionado

Similar a 200508 - Bases de Datos

Más de Javier Gonzalez-Sanchez

Último

200508 - Bases de Datos