UNIDAD 40. DISEÑO DE BASES DE DATOS RELACIONALES.

(RESUMEN)

1. Introducción al modelo relacional

2. Diseño y modelo relacional
a. Noción intuitiva de las formas normales
i. Definición de dependencias
b. Restricciones de integridad que condicional en diseño
i. Inherentes al modelo relacional
ii. Restricciones de dominio
iii. Integridad referencial.
iv. Dependencias funcionales
1. Superclave
2. Dependencia funcional
3. Cierre de un subconjunto de dependencias funcionales. Axiomas de
Armstrong
4. Cierre de un conjunto de atributos
5. Recubrimiento canónico, minimal o irredundante.
3. Diseño de bases de datos y normalización.
a. Descomposición de producto sin perdida
b. Normalización a partir de dependencias funcionales
i. Forma normal de Boyce-Codd
ii. Tercera forma normal
iii. Segunda forma normal
iv. Primera forma normal
4. Cuarta forma normal
a. Definición de 4FN y algoritmo de descomposición.
5. Procedimiento formal de normalización
a. Objetivos de la normalización
b. Normalización por análisis y normalización por síntesis
c. Técnicas y herramientas necesarias.
i. Cierre de un descriptor
ii. Determinación de si una dependencia pertenece a un cierre de
dependencias
iii. Equivalencias de dos conjuntos de dependencias.
iv. Recubrimiento canónico.
v. Hallar si un determinante es clave candidata.
6. Ejemplo de proceso de normalización
7. Relación con el currículo
8. Bibliografía
1.INTRODUCCIÓN AL MODELO RELACIONAL

• El documento de Codd propone un modelo basado en la teoría de las relaciones. El objetivo

es mantener la independencia entre la estructura lógica y el almacenamiento
• Objetivos del modelo de Codd
1. Independencia física. El modo en que se almacenan no influye en su manipulación
2. Independencia lógica. Añadir, eliminar o modificar objetos no influye en los
programas.
3. Flexibilidad. Representar a cada usuario los datos que prefiera
4. Uniformidad

2.DISEÑO Y MODELO RELACIONAL

• Podemos hacer el diseño de dos formas

I. Obtener el esquema relacional a partir de la observación del universo del discurso
II. Realizando el diseño en dos partes
i. Realizamos el modelo conceptual
ii. Se transforma en un esquema relacional aplicando unas reglas
a. Cada tipo de entidad se transforma en un esquema de relación
b. Cada tipo de interrelación N:M se transforma en una relación que
contiene los atribuíos de la entidad u los de la interrelación
c. Cada tipo de interrelación 1: N se convierte en una relación o se
d. crean dos relaciones y se propaga la clave del lado 1 al lado N
• Las relaciones obtenidas pueden presentar problemas
I. Incapacidad para almacenar ciertos hechos
II. Redundancia
III. Perdida de información (tuplas duplicadas)
IV. Perdida de dependencias funcionales
V. Aparición en la base de datos de estados que no son validos

2.1.-Noción intuitiva de las formas normales

FORMAS NORMALES

I. PRIMERA FORMA NORMAL => Una relación R se encuentra en primera forma normal
si todos los dominios simples contienen solo valores atómicos
II. SEGUNDA FORMA NORMAL =>Una relación R se encuentra en segunda forma normal
si está en primera y todos los atributos no clave dependen funcionalmente de manera
completa de la clave primaria
Si no se encuentra en segunda aplicamos el TEOREMA: Sea R una relación
R(A,B,C) con clave primaria (A, B) y cumpliendose R.A->R.d. ,R puede
descomponerse en R1(A, D) y R2(A, B, C)
III. TERCERA FORMA NORMAL =>Una relación R se encuentra en tercera forma normal i
está en segunda y todos los atributos no clave depende de manera no transitiva de la clave
primaria
Si no se encuentra en tercera aplicamos el TEOREMA: Sea R una relación
R(A,B,C) con clave primaria A y tal que R.B->R.C., R puede descomponerse en
R1(A, B) y R2(B, C)
IV. FORMA NORMAL DE BOYCE-CODD =>Debemos introducir el concepto de
determinante.
Un determinante es un atributo del que depende funcionalmente de manera
completa otro atributo.
 Una relación está en forma de Boyce-Codd si todo determinante es una clave
candidata.
Para que esté en 3FN y no en FBC deben darse las circunstancias
1. Existen varias claves candidatas
2. Las claves candidatas se solapan (tienen al menos un atributo
común)
3. Las claves candidatas son compuestas.
Cuando no esté en FBC aplicamos el TEOREMA: Sea R una relación R(A,B,C,D)
con claves candidatas (A,B) y (BC) y tales que R.A<-->R.B , R puede
descomponerse en una de estas dos formas
R1(A,C) y R2(B,C,D)
R1(A,C) y R2(A,B,D)
V. CUARTA FORMA NORMAL =>Una relación R se encuentra en cuarta forma normal si
está en FNBC y no existen dependencias multivaluadas.
Si no se encuentra en cuarta aplicamos el TEOREMA (de Fagin):Sea una relación
R (A,B,C) con las dependencias multivaluadas A->>B, A->>C, R puede
descomponerse en estas dos relaciones R1(A,B) y R2(A,C)
VI. QUINTA FORMA NORMAL =>Una relación se encuentra en quinta forma si toda
dependecia de reunión es consecuencia de las claves candidatas
Si no se encuentra en quinta podemos N-descomponerla para deshacer las
dependencias de reunión
DEPENDENCIAS

A. Dependencias funcionales =>Dada una relación R, el atributo Y dpende

funcionalmente del otro atributo X (R.x->R-y) si un solo valor de Y está asociado a
cada valor de X
Esto quiere decir que cada valor de X siempre lleva asociado el mismo valor
de Y
Dependencia funcional completa. El atributo Y depende funcionalmente
de manera completa de X si depende funcionalmente de X y no depende
de ningún subconjunto suyo
B. Dependencias multivaluadas =>Una relación R con atributos A,B,C tiene la
dependencia multivaluadas R.A->>B.B si el conjunto de valores de B
correspondientes a un valor de A y otro de C depende solo del valor de A.
C. Dependencias de Reunión=>La relación R satisface la dependencia de reunión
(X,Y,..,Z) si R es igual a la reunión de sus proyecciones según X,…,Z
2.2.-Restricciones de integridad que condicionan el diseño
• Las restricciones de integridad garantizan la consistencia de los datos. Alguna son:
o Inherentes al modelo relacional
o Restricciones de dominio
o Integridad referencial
o Dependencias funcionales
o Asertos
o Disparadores
o Valores nulos
• Se distinguen entre restricciones inherentes y de usuario.
i. Inherentes al modelo relacional=>Distinguimos
a. Declaración de clave (integridad de entidades): No se permiten dos tuplas de
igual valor para una clave candidata
 b. Propias de la definición matemática de relación: Indican las características de
una relación que han de cumplirse obligatoriamente y que diferencian una
relación de una tabla.
ii. Restricciones de dominio =>Restricción a los posibles valores almacenados
iii. Integridad referencial =>Sean dos relaciones r(R) y s(R) con claves primarias Kr y Ks.
Decimos que un subconjunto α de S es clave foránea (FK) de r si: Para todo α que
pertenece a S, existe un tr que pertenece a r, tal que ts(α)=tr(α)
• La sintaxis para implementarla con SQL es
o CLAVE PRIMARIA.
▪ Primary key(col1,…)
o CLAVE AJENA
▪ Foreign key (col1,..) references nomTabla_ref(col1_ref,..)
o CLAVE CANDIDATA
▪ Unique (col1,..)
iv. Dependencias funcionales =>Necesitamos definiciones formales de las dependencias
funcionales y las formas normales que permitan automatizar la normalización. Deben
definirse los conceptos
a. SUPERCLAVE: Sea R una relación, decimos que k es una superclave cuando
i. K pertenece a R y es distinta del conjunto vacio
ii. Para toda relación r(R) dada dos tuplas t1 y t2 se cumple que t1(k) es
distinto de t2(k)
b. DEPENDECIA FUNCIONAL: Sea R una relación y α y β. La dependencia
funcional α --> β se cumple si para alguna relación r(R) para todo par de tuplas
t1 y t2 se cumple que si t1(α) = ts(α) => t1(β)=t2(β). Una DF α-> β es trivial si α
es subconjunto de β
c. CIERRE DE UN SUBCONJUNTO DE DEPENDECIAS FUNCIONALES.AX
DE ARMSTRONG.
i. Dado un conjunto F de DF podemos probar que se cumplen otras
dependencias funcionales. F implica logicamente dichas dependencias.
• Sea F un conjunto de DF el cierre de F (F+) es el conjunto de DF que F
implica logicamente
• AX. DE ARMSTRONG
o Regla de reflexividad. Si α es un conjunto de atributos y β es <= α
entonces se cumple alfa ->beta
o Regla de aumento. Si se cumple que alfa -> beta y gamma es un
conjunto de atributos entonces se cumple que gamma*alfa -
>gamma*beta
o Regla de transitividad. Si se cumple que alfa->beta y se cumple
que beta->gamma se cumple que alfa ->gamma
▪ Existe reglas adicionales
o Regla de unión. Si alfa->beta y alfa->gamma entonces alfa -
>beta*gamma
o Regla de descomposición. Si alfa ->beta*gamma entonces alfa-
>beta y alfa->gamma
o Regla de pseudotransitividad.Si alfa->beta y gamma*beta->delta
entonces a*gamma ->delta
d. CIERRE DE UN CONJUNTO DE ATRIBUTOS: Si alfa es un conjunto de atributos el
conjunto de todos los atributos determinados por alfa bajo un conjunto F de DF se le llama
cierre de alfa bajo F y se denota por α+.
e. RECUBRIMIENTO CANÓNICO. Es una restricción de un conjunto de DF que
1. Minimiza el número de DF a ser probadas en caso de actualización
2. El conjunto de DF resultantes da el conjunto de tablas normalizadas
v. Asertos=>Es un predicado que siempre debe ser satisfecho
Create asertion <nombre> check <predicado>
vi. Disparadores=>
• La actividad o capacidad de respuesta de una BD a eventos se refleja en los disparadores
• En la sentencia CREATE indicamos si el disparador se dispara antes, después o en lugar del
evento
o El evento es la inserción borrado o modificación.
• Una acción disparada puede provocar el disparo de más acciones
o El modo cursor dice cuando se produce la ejecución de la acción disparada
▪ CASCADE OF Se difiere hasta hacer un COMMIT o se cierre el cursor
▪ En caso contrario se ejecuta antes, en lugar o después de la sentencia SQL
• La sintaxis de un disparador en SQL es

CREATE TRIGGER nombre_del_disparador

{BEFORE | AFTER} {INSERT | UPDATE | DELETE} ON nombre_de_la_tabla
FOR EACH ROW
BEGIN
-- Código del disparador aquí
END;

Explicación de las partes:

• nombre_del_disparador: Es el nombre que le darás al disparador y lo utilizarás para
referenciarlo posteriormente.
• BEFORE o AFTER: Indica si el disparador se ejecutará antes o después de la acción que lo
activa. Por ejemplo, BEFORE INSERT significa que el disparador se ejecutará antes de realizar
una inserción en la tabla.
• INSERT, UPDATE o DELETE: Indica la acción que activará el disparador.
• nombre_de_la_tabla: Es el nombre de la tabla a la que se asociará el disparador.
• FOR EACH ROW: Indica que el disparador se ejecutará una vez para cada fila afectada por la
acción. Esto significa que el código del disparador se ejecutará por separado para cada
fila.
Dentro del bloque BEGIN y END, es donde se coloca el código que se desea ejecutar cuando el
disparador se active
vi. Valores nulos=>Pueden ser inapropiados. La declaración NOT NULL al declarar un
dominio impide introducir nulos.

3.DISEÑO DE BASES DE DATOS Y NORMALIZACIÓN.

1. El objetivo del diseño es generar un conjunto de tablas que permitan almacenar
información sin redundancia y recuperar la información fácilmente
2. Defectos de una BD mal diseñado son
o Repetición de información
o Incapacidad para representar cierta información
 o Perdida de información
1. DESCOMPOSICIÓN SIN PERDIDA
• Una relación con muchos atributos mal diseñados se puede descomponer en do o más
esquemas con menos atributos
• El criterio para determinar si una descomposición tiene perdida es
o Sea R una relación y F un conjunto de DF
o R1 y R2 son dos descomposiciones de R será sin perdida si por lo menos una de las
siguientes DF está en F+
▪ R1 intersección R2->R1
▪ R1 intersección R2->R2
o R1 intersección R2 es clave primaria de alguna de las 2 (?)
2. NORMALIZACIÓN A PARTIE DE DF
• Conviene normalizar solo hasta la FN3
A) Forma normal de Boyce-Codd=> Un esquema de relación R respecto a un conjunto de F
de DF está en forma de BD si para todo a->b a F+ se cumplen al menos una de estas condiciones
B<=a (a->b es trivial)
A es superclave de R
Para obtener la FNBC seguimos el siguiente algoritmo (el mismo algoritmo se sigue para
la FN3 pero cambiando FNBC por FN3(
Parto de una relación r(R)
Tomo una DF cuyo antecedente no sea superclave, por ejemplo, alfa->beta yalfa
y beta disjuntos
Obtengo las proyecciones S=πalfa,beta(r), T= πalfa,ç-beta(r) hallando las DF que
se pueden aplicar a S y T a partir de F+
Alfa -> beta ya no viola la FNBC por que
1.Alfa -> beta ==>alfa U alfa -> alfa U beta => alfa ya es superclave
Si T y S no están en FNBC repito el proceso anterior
Comprobar que no se han producido perdidas de semánticas
1.Compruebo que la descomposición R={R1,...Rn} cumplen que para todo
r es r=πR1X...X πRn

B) Tercera forma normal => Una relación R está en ·FN respecto a un conjunto F de DF si
para todo a->b perteneciente a F+ se cumple al menos una de estas condiciones
1. B <=a (a->b es trivial)
2. A es superclave
3. Cada atributo A en b-a está contenido en una clave candidata de
• Para obtener una relación en 3FN aplicamos el algoritmo anterior .
C) Segunda forma normal=> Una relación está en 2FN si para todo atributo de R se cumple al
menos una de estas condiciones
A (atributo) <=(subconjunto) k, siendo k clave candidata
A no depende funcionalmente de forma parcial de una clave candidata
D. Primera forma normal =>Una relación está en 1FN si los dominios de todos los atributos
son atómicos y no hay grupos repetidos
4.CUARTA FORMA NORMAL

• Las dependencias multivaluadas pueden provocar anomalías.

• La 4FN se da cuando ningún esquema relacional presenta dependencias multivaluadas
en las que el determinante no es clave candidata
• Para obtener una relación en 4FN seguimos estos pasos
o Tomamos una dmv cuyo antecedente no sea superclave por ejemplo a ->>b
 o Obtengo S=proyección (a,b) y t=proyección(R-b), hallando las df y dmv
aplicables a S y T
o a->>b ya no viola la 4FN porque es trivial
▪ Si T o S no están aún en 4FN repetir el proceso
5.PROCEDIMIENTO FORMAL DE NORMALIZACIÓN
I) Objetivos de la normalización
• Normalizar consiste en transformar un esquema R(A,F), donde A son los atributos y F
las dependencias, en n esquemas relacionales{R1,..Rn}
• Los esquemas han de cumplir estas condiciones
1. Conservación de la información y las dependencias. =>
▪ Conservación de la información. La información contenida en R debe ser
la misma que la de las relaciones resultantes. Debe cumplirse
• La conservación de atributos
• La conservación del contenido de las tuplas
▪ Conservación de las dependencias. El conjunto de dependencias
resultante debe ser el mismo
2. Mínima redundancia de datos
3. Mínimo número de dependencias y con número de atributos mínimo
4. Mínimo número de esquemas resultantes y con número de atributos mínimo
II. Normalización por análisis y síntesis
a. La normalización por descomposición a partir del esquema original se llama
análisis y permite alcanzar formas superiores a la 3º
b. La obtención de los esquemas a partir de las dependencias se llama síntesis y
solo permite llegar a la 3º
ANALISIS

• Se divide el esquema original en sucesivas proyecciones que deben cumplir los principios
de conservación
• Pasos
1. Determinar el recubrimiento canónico de FC
2. Determinar las claves candidatas
3. Descomponer las relaciones en que existen dmv en las que el determinante no es
clave candidata mediante proyecciones usando de atributos comunes el
determinante afectado
4. Obtener proyecciones independientes hasta no poder continuar el proceso por
estar todas las DF implicadas por una clave candidata
5. Comprobar que no se pierde DF
SINTESIS

• Se realizan los siguientes pasos

1. Buscar el recubrimiento canónico
2. Agrupar las DF de Fc en pariciones con el mismo determinante
3. Formar un esquema Ri por cada partición con todos los atributos que aparecen en las
dependencias
4. Si existen atributos independientes que no son imprimantes ni implicados por Fc se
forma con ellos un esquema de relación que no tendrá DF cuya clave será el conjunto de
todos los atributos

III Técnicas y herramientas necesarias

 • Las herramientas que se emplean en el análisis y síntesis son
1. Hallar el cierre a+ de un descriptor
2. Determinar si a->b pertenece a F+
3. Encontrar procedimientos eficientes para determinar la equivalencia de conjuntos de
dependencias que no estén basados en el cálculo de los respectivos cierres
4. Hallar el recubrimiento o cierre canónico Fc de un conjunto de dependencias
5. Hallar todas las claves candidatas de un esquema
6. Verificar si un descriptor K es clave de un esquema R
1 HALLAR EL CIERRE a+ DE UN DESCRIPTOR => Usamos el algoritmo de Ullman

• Partimos del conjunto inicial de atributos del descriptor

• Creamos una lista para almacenar los atributos implicados
• Examinamos cada dependencia funcional del conjunto DF y comprobamos si se satisface
con el conjunto actual de atributos
o Una DF se satisface si los atributos determinantes están presentes en el conjunto
de atributos.
• Si una DF es satisfecha agregar los atributos determinados al conjunto de atributos
implicados
• Repetir los pasos 3 y 4 hasta no poder agregar más atributos El conjunto resultante es el
cierre del descriptor.
2.DETERMINAR SI UNA DEPENDENCIA PERTENECE A UN CIERRE DE DEPENDICAS => Para
comprobar si a-->b pertenece a F+ se calcula a+ y se comprueba se b pertenece a a+
3.EQUIVALENCIA DE DOS CONJUNTOS DE DEPENDENCIAS ==> Seguimos el siguiente algoritmo
1. Tomamos los dos conjuntos de DF
2. Comprobar si todas las DF del primer conjunto están implicadas en el 2º. Esto significa
que cada DF del 1º se pueden deducir del 2º
3. Para cada Df del 1º intentar deducirla del 2º utilizando algoritmos de inferencia como el
de cierre de atributos
4. Si todas las DF del 1º se pueden deducir de las del 2º pasar al siguiente paso
5. Repetir, pero ahora intentar las del 2º deducirlas de las del 1º
4.RECUBRIMIENTO CANÓNICO ==>Aplicamos el algoritmo de Arkins

1. Comenzamos con el conjunto original de DF

2. Para cada df considerar si se puede eliminar sin perder información semántica
Una df a->b se puede eliminar si existe otra dependencia c->b tal que c es un
subconjunto de a y de un subconjunto de b
Si hay una df más específica la más general se puede eliminar
3. Repetir hasta no poder eliminar más DF
5.VERIFICAR SIN UN DESCRIPTOR ES CLAVE CANDIDATA => Calcuar el cierre de a (a+) y comprobar si todo
atributo Ai de la relación pertenece al cierre.

6.EJEMPLO PROCESO DE NORMALIZACIÓN

7.RELACIÓN CON EL CURRICULO
8.BIBLIOGRAFÍA