Bases de Datos I. Tema V. Diseño de Bases de Datos Relacionales

Tema V.
Diseño de Bases de Datos

Relacionales
::Universidad del Mar::

::Campus Puerto Escondido ::
Bases de Datos I
MTI Remedios Fabián Velasco
Ver. 1.1
Cuarto Semestre
Licenciatura en Informática
Temario
5 Diseño de bases de datos relacionales.
5.1 Objetivos del diseño de bases de datos.
5.2 Dependencias funcionales.
5.3 Normalización.
5.3.1 Primera forma normal.
5.3.2 Segunda forma normal.
5.3.2.1 Dependencia funcional de los datos.
5.3.2.2 Dependencia funcional completa.
5.3.2.3 Dependencia transitiva.
5.3.3 Tercera forma normal.
5.3.3.1 Forma normal de Boyce-Codd.
5.3.3.2 Atributos multivaluados.
5.3.3.3 Dependencias multivaluadas.
5.3.4 Cuarta forma normal.
5.3.5 Quinta forma normal.
5.4 Enfoques alternativos al diseño de bases de datos.
Bases de Datos I
5.5 Modelado semántico.
Universidad del Mar 07/2008 MTI Remedios Fabián Velasco
5.1 Objetivos del diseño de bases
de datos.
El objetivo principal es crear una
REPRESENTACION PRECISA de los DATOS, de las
RELACIONES entre los datos y de las
RESTRICCIONES aplicables a los datos que sean
pertinentes para la organización.
Para conseguir este objetivo empleamos técnicas

como el Modelo Entidad – Relación.
Otra técnica de diseño de base de datos se
denomina Normalización.
Bases de Datos I Universidad del Mar 07/2008 MTI Remedios Fabián Velasco
5.2 Dependencias funcionales.
Concepto asociado con la Normalización, describe

la relación entre atributos.
Dependencia funcional
Describe la relación existente entre atributos de una
relación R, B será funcionalmente dependiente de A (lo
que se denota A → B) si cada valor de A esta asociado con
exactamente un valor de B (A y B puede consistir casa uno
de ellos de uno o más atributos.
Determinante: Hace referencia al atributo o grupo de atributos en el
lado izquierdo de la flecha que describe una dependencia funcional.
A determina funcionalmente a B
B depende funcionalmente de A
A B
Cuando existe una dependencia funcional, el atributo o grupo de

atributos en el lado izquierdo de la flecha se denomina determinante.
Dependencia funcional completa: Indica que si A y B son atributos
de una relación, B depende funcionalmente de manera completa de A
si B depende funcionalmente de A pero no de ningún subconjunto
propio de A.
Una dependencia funcional A → B es una dependencia funcional

completa si la eliminación de cualquier atributo de A hace que la
dependencia deje de existir.
Una dependencia funcional A → B es una dependencia parcial si existe
algún atributo que puede eliminarse de A y la dependencia continua
verificándose.
Dependencia transitiva: Una condición en la que A → B y
B → C, entonces C depende transitivamente de A a
través de B (supuesto que A no sea funcionalmente
dependiente de B o C).
Considere:
noPersonal → sNombre, puesto, salario, noSucursal. bDireccion
noSucursal→ bDireccion
La dependencia transitiva noSucursal → bDireccion

existe en noPersonal a través de noSucursal .
5.3. Normalización
Es una técnica para producir un conjunto

de relaciones con una serie de propiedades
deseables, partiendo de los requisitos de
datos de una organización.
Incluye:
El número mínimo de atributos necesarios para
soportar los requisitos de datos de la
organización.
Los atributos con una relación lógica fuerte
(conocida como dependencia funcional) se
encuentran en la misma relación.
Redundancia mínima, estando cada atributo
representado una sola vez, con la excepción de
los atributos que formen parte de las claves
Bases de Datos I externas. Universidad del Mar 07/2008 MTI Remedios Fabián Velasco
Redundancia de Datos
Si se consigue agrupar los atributos en

relaciones de modo que minimice la
redundancia de los datos, se obtienen las
siguientes ventajas:
Las actualizaciones de los datos almacenados
en la BD pueden llevarse a cabo con un número
mínimo de operaciones, reduciendo
incoherencia en los datos.
Reduce espacio de almacenamiento de archivos
requerido por las relaciones base, minimiza
costos.
Primera Forma Normal
Un dominio es atómico si se considera que

los elementos del dominio son unidades
indivisibles.
Se dice que el esquema de una relación R
está en la primera forma normal (1FN) si
los dominios de todos los atributos de R
son atómicos.
Un conjunto de nombres es un ejemplo de
valor no atómico. Por ejemplo, si el
esquema de la relación empleado incluyera
el atributo hijos, los elementos de cuyo
dominio son conjuntos de nombres, el
esquema no se hallaría en la primera forma
Los atributos compuestos, como el
atributo dirección con sus atributos
componentes calle y ciudad, tienen
también dominios no atómicos.
Considérese una organización que asigna a
los empleados números de identificación así:
dos primeras letras especifican el
departamento y las cuatro cifras restantes
son un número único para el empleado
dentro de ese departamento.
Ejemplos de estos números pueden ser
IN0012 y EE1127.
Estos números de identificación pueden
dividirse en unidades menores y, por tanto,
no son atómicos.
UFN - 1FN
Forma NO Normalizada (UFN). Tabla que

contiene uno o más grupos repetitivos.
Primera Forma Normal (1FN) Una relación
en la que la inserción de toda fila y
columna contiene un valor y sólo un valor
(valores atómicos)
Para transformar de UFN a 1FN tenemos
que identificar y eliminar los grupos
repetitivos dentro de la tabla.
Un atributo repetitivo es aquel, dentro de una tabla que
presente múltiples valores para un mismo valor de los
atributos designados como clave principal de esa tabla.
Hay dos técnicas para eliminar grupos

repetitivos:
Introduciendo datos apropiados en las columnas
vacías de las filas que contienen los datos repetitivos.
Colocando los datos repetitivos, junto con una copia
de los atributos originales en una relación
independiente.
UFN
noClie cNom noPropie pDireccion inicioRen finRenta rent noPropiet oNombre

nte bre dad ta a ario
CR76 John PG4 6 Lawrence St 1-Jul-03 31-Ago- 350 CO40 Tina
Kay Glasgow 04 Murphy
PG16 1-Sep-04 450 CO93
5 Novar Dr. 1-Sep-05 Tony
Glasgow Shaw
CR56 Aline PG4 6 Lawrence St 1-Sep-02 10-Jun- 350 C040 Tina
Stewa Glasgow 03 Murphy
rt
PG36 10-Oct- 375 CO93
2 Manor Rd. 03 1-Dic-04 Tony
Glasgow Shaw
PG16 450 CO93
1-Nov-05 10-Ago-
5 Novar Dr. 06 Tony
Glasgow Shaw
Tabla NO normalizada ClienteRenta
1FN
noClie cNom noPropi pDireccion inicioRe finRent rent noPropie oNomb
nte bre edad nta a a tario re
CR76 John PG16 5 Novar Dr. 1-Sep- 1-Sep- 450 CO93 Tony
Kay Glasgow 04 05 Shaw
CR56 Aline PG4 6 Lawrence St 1-Sep- 10-Jun- 350 C040 Tina
Stewa Glasgow 02 03 Murphy
rt
CR56 Aline PG36 2 Manor Rd. 10-Oct- 1-Dic- 375 CO93 Tony
Stewa Glasgow 03 04 Shaw
rt
CR56 Aline PG16 5 Novar Dr. 1-Nov- 10-Ago- 450 CO93 Tony
Stewa Glasgow 05 06 Shaw
rt
Tabla normalizada ClienteRenta Primera Forma Normal
noClient cNombre Cliente Relaciones alternativas de la
e
CR76 John Kay Primera Forma Normal
CR56 Aline Stewart
PropietariosPropiedadesRentas
noClie cNomb noPropie pDireccion inicioRenta finRenta rent noPropiet oNombre
nte re dad a ario
CR76 John PG16 5 Novar Dr. 1-Sep-04 1-Sep- 450 CO93 Tony
Kay Glasgow 05 Shaw
CR56 Aline PG4 6 Lawrence St 1-Sep-02 10-Jun- 350 C040 Tina
Stewa Glasgow 03 Murphy
rt
CR56 Aline PG36 2 Manor Rd. 10-Oct- 1-Dic-04 375 CO93 Tony
Stewa Glasgow 03 Shaw
rt
CR56 Aline PG16 5 Novar Dr. 1-Nov-05 10-Ago- 450 CO93 Tony
Stewa Glasgow 06 Shaw
rt
Segunda forma normal.
5.3.2.1 Dependencia funcional de los datos.

5.3.2.2 Dependencia funcional completa.
5.3.2.3 Dependencia transitiva.
La segunda forma normal (2FN) se basa
en el concepto de dependencia
funcional completa
Se aplica a las relaciones con claves
compuestas.
2FN: Una relación que esta en primera
forma normal y en la que todo atributo
que no sea clave principal depende
funcionalmente de manera completa de
la clave principal.
2FN Relaciones en segunda forma
normal derivadas de la
relación ClienteRenta
noPropieda pDireccion rent noPropietar oNombre

d a io
PG4 6 Lawrence St 350 CO40 Tina
Glasgow Murphy
PG16 5 Novar Dr. Glasgow 450 CO93 Tony Shaw
PG36 2 Manor Rd. 375 CO93 Tony Shaw

Glasgow
PropietariosPropiedades
Renta
noClient noPropieda inicioRent finRenta
e d a noClient cNombre
CR76 PG4 1-Jul-03 31-Ago- e
04 CR76 John Kay
CR76 PG16 1-Sep-04 1-Sep-05
CR56 Aline
CR56 PG4 1-Sep-02 10-Jun-03 Stewart
CR56 PG36 10-Oct-03 1-Dic-04
Cliente
CR56 PG16 1-Nov-05 10-Ago-
06
Concepto
Una dependencia funcional es un tipo de

restricción que constituye una generalización del
concepto de clave.
Las dependencias funcionales son restricciones
del conjunto de relaciones legales. Permiten
expresar hechos sobre la empresa que se modela
con la base de datos.
Se dice que K es una superclave de R si K →R
Las dependencias funcionales nos permiten
expresar las restricciones que no se pueden
expresar con las superclaves.
Las dependencias funcionales se utilizarán de
dos maneras:
Para probar las relaciones y ver si son legales según

un conjunto dado de dependencias funcionales. Si
una relación r es legal según el conjunto F de
dependencias funcionales, se dice que r satisface F.
Para especificar las restricciones del conjunto de

relaciones legales. Así, sólo habrá que preocuparse
por las relaciones que satisfagan un conjunto dado
de dependencias funcionales. Si uno desea
restringirse a las relaciones del esquema R que
satisfagan el conjunto F de dependencias
funcionales, se dice que F se cumple en R.
Tercera Forma Normal 3FN
Una relación que esta en primera y segunda
formas normales y en la que ningún atributo que
no sea de clave principal depende transitivamente
de la clave principal
noPropietar oNombre Relaciones en tercera forma
io
CO40 Tina normal derivadas de la
Murphy
CO93 Tony Shaw relación
Propietarios PropiedadesPropietarios
noPropiedad pDireccion renta noPropietario

PG4 6 Lawrence St Glasgow 350 CO40
PG16 5 Novar Dr. Glasgow 450 CO93
PG36 2 Manor Rd. Glasgow 375 CO93
Propiedades
Relaciones en 3FN
noPropietar oNombre Un resumen de las relaciones
io
CO40 Tina 3NF derivadas de la relación
Murphy
CO93 Tony Shaw ClienteRenta
Propietarios
noPropiedad pDireccion renta noPropietario

PG4 6 Lawrence St Glasgow 350 CO40
PG16 5 Novar Dr. Glasgow 450 CO93
PG36 2 Manor Rd. Glasgow 375 CO93
Propiedades
noClient noPropieda inicioRent finRenta

e d a noClient cNombre
CR76 PG4 1-Jul-03 31-Ago- e
04 CR76 John Kay
CR76 PG16 1-Sep-04 1-Sep-05
CR56 Aline
CR56 PG4 1-Sep-02 10-Jun-03 Stewart
CR56 PG36 10-Oct-03 1-Dic-04
Cliente
CR56 PG16 1-Nov-05 10-Ago-
06
Renta
Forma normal de Boyce-Codd
Una de las formas normales mas deseables que se

pueden obtener es la forma normal de Boyce-Codd
(FNBC ).
Un esquema de relación R está en FNBC respecto
a un conjunto de dependencias funcionales F si,
para todas las dependencias funcionales de F+ de
la forma α → β, donde α ⊆ R y β ⊆ R, se cumple al
menos una de las siguientes condiciones:
• α → β es una dependencia funcional trivial (es
decir, β ⊆ α)
• α es una superclave del esquema R.
Un diseño de base de datos está en FNBC si cada
miembro del conjunto de esquemas de relación
que constituye el diseño está en FNBC.
Una relación esta en FNBC, si y sólo si
todo determinante es una clave
candidata.
Esquema-cliente = (nomCliente,
calleCliente, ciudadCliente)
nomCliente → calleCliente ciudadCliente
Esquema-sucursal = (nomSucursal,
activo, ciudadSucursal)
nomSucursal → activo ciudadSucursal
Esquema-info-préstamo = (nomSucursal,
nomCliente, noPrestamo, importe)
noPrestamo → importe nomSucursal
Puede afirmarse que Esquema-cliente
está en FNBC. Obsérvese que una clave
candidata para el esquema es
nomCliente.
Las únicas dependencias funcionales no
triviales que se cumplen en Esquema-
cliente tienen a nombre-cliente a la
izquierda de la flecha.
Dado que nombre-cliente es una clave
candidata, las dependencias funcionales
con nomCliente en la parte izquierda no
violan la definición de FNBC.
Lo mismo sucede con Esquema-sucursal.
El esquema Esquema-info-préstamo, sin
embargo, no está en FNBC. Obsérvese que
noPrestamo no es una superclave de Esquema-
infopréstamo, ya que puede que haya un par de
tuplas que representen a un solo préstamo
concedido a dos personas, por ejemplo,
(Centro, Sr. Pinilla, P-44, 1.000)
(Centro, Sra. Pinilla, P-44, 1.000)
Como no se ha relacionado ninguna
dependencia funcional que descarte el caso
anterior, noPrestamo no es una clave candidata.
Sin embargo, la dependencia funcional
noPrestamo → importe es de tipo no trivial.
Por lo tanto, Esquema-info-prestamo no
satisface la definición de FNBC.
Considérese la descomposición de
Esquemainfo-préstamo en dos esquemas:
Esquema-préstamo = (noPrestamo,
nomSucursal, importe)
Esquema-prestatario = (nomCliente,
noPrestamo)
Esta descomposición es una
descomposición de reunión sin pérdida.
Comparación entre FNBC y
3FN
3FN se sabe que siempre resulta posible
obtener un diseño en 3FN sin sacrificar la
reunión sin pérdida o la conservación de
las dependencias.
Sin embargo, hay inconvenientes en 3FN: si
no se eliminan todas las dependencias
transitivas de las relaciones de los
esquemas, puede que se tengan que
emplear valores nulos para representar
algunas de las relaciones significativas
posibles entre los datos, y está el problema
de repetición de la información.
La posibilidad de violar las condiciones
FNBC puede aparecer cuando:
La relación contenga dos o más claves
candidatas compuestas.
Las claves candidatas se solapen, es decir,
tengan atributos en común.
Cuarta Forma Normal 4FN
Considérese el ejemplo bancario. Supóngase que,
en un diseño alternativo del esquema de la base
de datos, se tiene el esquema
Esquema-BC = (noPrestamo, nomCliente,
calleCliente, ciudadCliente)
No está en FNBC debido a la dependencia
funcional
nomCliente → calleCliente ciudadCliente
que se estableció anteriormente, y debido a que
nombre-cliente no es una clave de Esquema-BC.
Sin embargo, supóngase que el banco está
atrayendo a clientes ricos que tienen varios
domicilios (por ejemplo, una residencia de invierno
y otra de verano). Entonces ya no se deseará
hacer que se cumpla la dependencia funcional
nomCliente → calleCliente ciudadCliente.
Para tratar este problema hay que definir
una nueva forma de restricción,
denominada dependencia multivalorada.
Como se hizo para las dependencias
funcionales, se utilizarán las dependencias
multivaloradas para definir una forma
normal para los esquemas de relación.
Esta forma normal, denominada cuarta
forma normal (4FN), es más restrictiva
que FNBC. Se verá que cada esquema 4FN
se halla también en FNBC, pero que hay
esquemas FNBC que no se hallan en 4FN.
Dependencia Multivalorada
Representa una dependencia entre

atributos (por ejemplo A, B y C) en
una relación de modo que para cada
valor de A hay un conjunto de valores
B y un conjunto de valores C.
Sin embargo, los conjuntos de valores
de B y C son independientes entre sí.
4NF
Una relación se encuentra en Cuarta

Forma Normal, si está en forma
normal Boyce-Codd y no contiene
dependencias multivaloradas no
triviales.
Quinta Forma Normal 5FN
Cada vez que descomponemos una

relación en dos relaciones, las relaciones
resultantes tienen la propiedad
denominada de combinación sin pérdidas.
Dependencia de combinación sin pérdidas:

Una propiedad de la descomposición que
garantiza que no se generen tuplas
espurias (falsas) al volver a combinar las
relaciones mediante una operación de
combinación natural.
5FN
Una relación 5FN, es aquella que no tiene
dependencias de combinación.
También se denomina forma normal de

proyección-combinación (FNPC).
Dependencia de combinación: Describe un tipo de

dependencia. Por ejemplo, para que una relación R
compuesta por una serie de subconjuntos de los
atributos de R denomina A, B…, Z, la relación R
exhibirá una dependencia de combinación si sólo
si todo valor legal e R es igual a la combinación de
sus proyecciones sobre A, B, …, Z.
5.4 Enfoques alternativos al diseño
de bases de datos.
Metodología de Diseño:
Es un enfoque estructurado que utiliza
procedimientos, técnicas, herramientas
y ayudas para la generación de
documentación con el fin de facilitar el
proceso de diseño y servirle de soporte.
Diseño conceptual de la base de
datos:
El proceso de construcción de un modelo
de los datos utilizados en una
organización, independientemente de
todas las consideraciones físicas.
Diseño lógico de la base de datos:
El proceso de construir un modelo de los datos
utilizados en una organización basándose en un
modelo de datos específico, pero con
independencia del SMBD concreto que se vaya
a utilizar y a cualquier otra consideración física.
Diseño físico de la base de datos
El proceso de generar una descripción de la
implementación de la base de datos en
almacenamiento secundario; describe las
relaciones base, la organización de los archivos
y los índices utilizados para conseguir un
acceso eficiente a los datos; así como
cualesquiera restricciones de integridad
asociadas y medidas de seguridad utilizadas.
Factores críticos del diseño
Trabajar interactivamente con los usuarios

lo más que se pueda.
Metodología estructurada durante todo el
proceso.
Emplear técnica centrada en los datos.
Preciso incorporar las consideraciones
estructurales y de integridad dentro de los
modelos de datos.
Combinar técnicas de conceptualización,
normalización y validación de transacciones en la
metodología del modelado de los datos.
Emplear diagramas para representar una parte
mayor posible de los modelos de datos.
Usar lenguaje de diseño de base de datos para
representar información semántica acerca de los
datos que no puedan representarse fácilmente en
un diagrama.
Construir diccionario de datos para complementar
diagramas
Estar dispuesto a repetir diversos pasos en
determinadas ocasiones.
Pasos
1. Construir el modelo conceptual

Identificar tipos de entidad
Identificar tipos de relación
Identificar y asociar los atributos con los tipos de
entidad y relación
Determinar el dominio de los atributos
Determinar los atributos de la clave candidata,
principal y alternativa
Considerar el uso de conceptos del modelo
avanzado
Comprobar si el modelo tiene redundancia
Paso 2 Construir y validar el modelo lógico
de los datos
Determinar las relaciones para el modelo lógico
de los datos
Validar las relaciones mediante técnicas de
normalización
Validar las relaciones comprobando
transacciones de usuarios
Comprobar las restricciones de integridad
Repasar el modelo lógico de los datos con los
usuarios
Combinar los modelos lógicos en un modelo
global
Verificar las consideraciones de crecimiento
futuro.
Paso 3. Traducir el modelo lógico de los
datos al SMBD seleccionado
Diseñar relaciones base
Diseñar representación de datos variados
Diseñar restricciones generales
Paso 4. Diseñar la organización de los
archivos y de los índices
Estimar requisitos de espacio
Paso 5. Diseñar vistas de usuarios
Paso 6. Considerar mecanismos de
seguridad
Paso 7. Considerar control de redundancia
Paso 8. Monitorizar el sistema final
5.5 Modelado semántico.
Consiste en estudiar los datos que se

pretenden almacenar en la base de
datos antes de elegir el modelo de
datos concreto que se va a usar en la
base de datos.
Bibliografía utilizada
Libros:
Fundamentos de Bases de Datos. Abraham
Silberschatz, Henry F. Korth, S. Sudarshan
Sistemas de Bases de Datos. Thomas Conolly y
Carolyn Begg

Bases de Datos I. Tema V. Diseño de Bases de Datos Relacionales

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bases de Datos I. Tema V. Diseño de Bases de Datos Relacionales

Uploaded by

Copyright:

Available Formats

Tema V.

Diseño de Bases de Datos

::Universidad del Mar::

Para conseguir este objetivo empleamos técnicas

Concepto asociado con la Normalización, describe

Cuando existe una dependencia funcional, el atributo o grupo de

Una dependencia funcional A → B es una dependencia funcional

La dependencia transitiva noSucursal → bDireccion

Es una técnica para producir un conjunto

Si se consigue agrupar los atributos en

Un dominio es atómico si se considera que

Forma NO Normalizada (UFN). Tabla que

Hay dos técnicas para eliminar grupos

noClie cNom noPropie pDireccion inicioRen finRenta rent noPropiet oNombre

Tabla NO normalizada ClienteRenta

Tabla normalizada ClienteRenta Primera Forma Normal

5.3.2.1 Dependencia funcional de los datos.

noPropieda pDireccion rent noPropietar oNombre

PG36 2 Manor Rd. 375 CO93 Tony Shaw

Una dependencia funcional es un tipo de

Se dice que K es una superclave de R si K →R

Para probar las relaciones y ver si son legales según

Para especificar las restricciones del conjunto de

noPropiedad pDireccion renta noPropietario

noPropiedad pDireccion renta noPropietario

noClient noPropieda inicioRent finRenta

Una de las formas normales mas deseables que se

Representa una dependencia entre

Una relación se encuentra en Cuarta

Cada vez que descomponemos una

Dependencia de combinación sin pérdidas:

También se denomina forma normal de

Dependencia de combinación: Describe un tipo de

Trabajar interactivamente con los usuarios

1. Construir el modelo conceptual

Consiste en estudiar los datos que se

You might also like