DISEÑO DE BASES

DE DATOS
DISEÑO DE BD RELACCIONALES A PARTIR DE NECESIDADES DE
MANEJO DE INFORMACIÓN EN LAS ETAPAS DE ANÁLISIS Y
DISEÑO DE SI
 Normalización
La normalización de datos se refiere a:
• Modelar una BDR y saber como se genera una estructura relacional de
datos válida.
• A la dependencia que se forma entre los atributos dentro de una tupla.
•A como se establecen relaciones entre entidades a través de las
estructuras de atributos.
• A la cantidad de atributos que componen la pk.
• A controlar la redundancia.
• A que se cumplan las reglas de integridad en AltasBajasCambios.

“A la creación de una estructura lógica fácil de comprender y mantener”

 Normalización
Premisas a satisfacer:

• Misma cantidad de información.

• No alterar la dependencia funcional.
• Reducir la redundancia a su mínima expresión.
• Reducir al mínimo los problemas de lógica en la administración de los
datos.
 Normalización
Objetivos:

• Reducir la redundancia de datos y por lo tanto, las inconsistencias.

• Facilitar el mantenimiento de los datos y de los programas.
• Evitar anomalías en las operaciones de manipulación de datos.
• Reducir el impacto de los cambios en los datos.
 Proceso de normalización
• Proceso de análisis de las relaciones para alcanzar la propiedades
deseables de:

• Mínima redundancia

• Mínimas anomalías de:

• Inserción/Altas(A)

• Eliminación/Bajas(B)

• Actualización/Cambios(C)
Formas normales
 Formas Normales

 1FN
 2FN Formas normales básicas, expuestas por Codd en 1972

 3FN
 FNBC (1974) Forma normal Boyce Codd, mejora la 3NF

 4FN No fueron definidas por Codd, sino por R. Fagin (1977 y

1979, respectivamente)
 5FN
 Formas Normales

 1FN
 2FN La dependencia funcional entre atributos forma la base de las
tres formas normales originales de Codd, así como de la FNBC.
 3FN
 FNBC
 4FN
Basadas en la dependencia multivaluada y dependencias de
 5FN reunión respectivamente.
1ª Forma normal (1FN)
CONJUNTO DE TODOS
LOS POSIBLES VALORES
DE UN ATRIBUTO EN UNA CADA ATRIBUTO SE
RELACIÓN DEFINE SOBRE UN SOLO
DOMINIO

“Una relación se encuentra en 1FN si, y sólo si,

todos los dominios simples subyacentes de los
atributos contienen valores atómicos y
monovalentes”

LOS VALORES NO
PUEDEN REPETIRSE,
MENOR UNIDAD SEMANTICA DE DEBEN EXPRESARSE
INFORMACIÓN = VALOR DE UN UNA VEZ POR
DATO INDIVISIBLE = OCURRENCIA
IMPOSIBILIDAD DE DIVIDIR EL
DATO QUE COMPONE EL
DOMINIO
Origen de datos / Sistema de ventas
Sucursal y Fecha de la Forma de Código del Nombre del Código del
número de factura pago factura cliente cliente artículo
factura

01-500 1/01/06 E 01 ALVAREZ 01

01-500 1/01/06 E 01 ALVAREZ 02

01-500 1/01/06 E 01 ALVAREZ 10

01-501 2/01/06 CC 107 CASTRO 08

02-500 3/01/06 E 110 LIZ 20

02-500 3/01/06 E 110 LIZ 10

Considérese una solo tabla

Nombre del Cantidad del Precio unitario Subtotal del Total de la
artículo artículo del artículo artículo factura
LÁPIZ 3 1.25 3.75 48.25

GOMA 6 0.75 4.50 48.25

HOJAS 8 5.00 40.00 48.25

COMPÁS 4 4.00 16.00 16.00

REGLA 2 2.45 4.90 14.90

HOJAS 2 5.00 10.00 14.90

 1FN - Ejemplo
• La primer columna contiene una combinación de datos: Sucursal y Número
de factura, por lo tanto no son atómicos y pueden separarse en dos
columnas.
• Para que se cumpla la monovalencia debemos eliminar grupos repetidos
de datos. Para éste ejemplo encontramos que se tienen 3 diferentes
facturas, y que para cada una se repiten los valores: sucursal, número de
factura, fecha de la factura, forma de pago, código del cliente, nombre del
cliente y total de factura. Por lo que la tabla puede separarse en do una con
los datos que se repiten y otra con los que no.
 1FN - Ejemplo
• No debe olvidarse al separar en diferentes tablas:

• Dar un nombre a cada nueva relación para poder identificarlas en la nueva

estructura resultante

• Encontrar la llave primaria (pk) para cada relación

• Establecer la referencia (fk) entre las relaciones

 1FN - Ejemplo
Relación Factura
Sucursal Número Fecha de la Forma de Código del Nombre del Total de la
de factura factura pago cliente cliente factura
factura
Pk compuesta
01 500 1/01/06 E 01 ALVAREZ 48.25

01 501 2/01/06 CC 107 CASTRO 16.00

02 500 3/01/06 E 110 LIZ 14.90

Relación Detalle de Factura

Sucursal Número Código de Nombre del Cantidad Precio Subtotal
de factura artículo artículo del artículo unitario del del artículo
artículo
01 500 01 LÁPIZ 3 1.25 3.75

01 500 02 GOMA 6 0.75 4.50

01 500 10 HOJAS 8 5.00 40.00

01 501 08 COMPÁS 4 4.00 16.00

02 500 20 REGLA 2 2.45 4.90

02 500 10 HOJAS 2 5.00 10.00

Fk
2ª Forma normal (2FN)
NUNCA SE PUEDE TODOS LOS ATRIBUTOS
LLEGAR A 2FN SIN ANTES QUE NO COMPONEN LA
CUMPLIR CON LA 1FN LLAVE PRIMARIA

“Una relación se encuentra en 2FN si, y sólo si, se

encuentra en 1FN y, además, todos los atributos no
clave dependen por completo de la llave primaria”

NO EXISTEN
DEPENDENCIAS
SE REQUIERE DE UNA LLAVE PARCIALES /
COMPUESTA PARA QUE HAYA DEPENDENCIA
DEPENDENCIAS PARCIALES FUNCIONAL
 Dependencia funcional (DF)
• Establece
una relación fuerte y persistente entre dos atributos, es decir, el
cambio de valor de uno determina en su valor al otro.
• LaDF establece que los valores contenidos en un conjunto de atributos
definen el valor de otro conjunto de atributos.
 2FN - Ejemplo
• Paraque no se cumpla la 2FN, en la relación “Factura”, deberíamos
encontrar que algún atributo no clave depende de una parte de la PK.
• Por
ejemplo, que la fecha solo dependiera de la sucursal o solo del
número de factura.
• Lo cual no ocurre dado que la fecha depende por completo de la PK al igual
que las demás columnas.
 2FN - Ejemplo
• Para que no se cumpla la 2FN, en la relación “Detalle de Factura”,
deberíamos encontrar que algún atributo no clave depende de una parte de
la PK.
• Existeuna relación directa de nombre del artículo y precio unitario del
artículo con el código del artículo.
• Para resolverlo, detalle de factura debe descomponerse en dos relaciones.
• No deben olvidarse las consideraciones al separar tablas.
 Relación Factura

Sucursal Número Fecha de la Forma de Código del Nombre del Total de la

de factura factura pago cliente cliente factura
Pk compuesta factura

01 500 1/01/06 E 01 ALVAREZ 48.25

01 501 2/01/06 CC 107 CASTRO 16.00

02 500 3/01/06 E 110 LIZ 14.90

Relación Detalle de Factura

Sucursal Núm. Código Precio Cantidad Subtotal Relación Artículos
de de unitario del del del
factur artículo artículo artículo artículo Código Nombre del Precio
a de artículo unitario
01 500 01 1.25 3 3.75 artículo del
artículo
01 500 02 0.75 6 4.50 01 LÁPIZ 1.25
01 500 10 5.00 8 40.00 02 GOMA 0.75
01 501 08 4.00 4 16.00 10 HOJAS 5.00
02 500 20 2.45 2 4.90 08 COMPÁS 4.00
02 500 10 5.00 2 10.00 20 REGLA 2.45
Fk
 2FN - Ejemplo
El precio del artículo es un caso particular, donde no se maneja un valor
constante ya que, para un artículo se tendrá un precio actual y en el pasado
(momento en que se realizo la venta) puede tenerse uno distinto, por lo que
se recomienda mantener la columna en ambas relaciones.
3ª Forma normal (3FN)

NUNCA SE LLEGA A 3FN ATRIBUTOS QUE NO

SIN CUMPLIR CON LA 2FN PERTENECEN A LA CLAVE
PRIMARIA
“Una relación se encuentra en 3FN si, y sólo si, se
encuentra en 2FN; y si ningún subconjunto de
atributos no claves tienen dependencias
funcionales entre sí”

NO EXISTEN
DEPENDENCIAS
TRANSITIVAS
 3FN - Ejemplo
• Loque buscamos en las relaciones del ejemplo es subconjuntos de datos
con dependencias transitivas, que ninguno pertenezca a la PK y que al
cambiar el valor de un atributo cambie el valor de otro atributo.
• Lo cual puede observarse en la relación factura, en el subconjunto
formado por código del cliente y nombre del cliente, entre ambos existe
una dependencia funcional. Por lo que se procede a descomponer la
relación.
 Relación Factura Relación Clientes
Pk
Sucursal Número Fecha de la Forma de Código del Total de la Código Nombre del
de factura factura pago cliente factura del cliente
factura cliente

01 500 1/01/06 E 01 48.25 01 ALVAREZ

01 501 2/01/06 CC 107 16.00 107 CASTRO

02 500 3/01/06 E 110 14.90 110 LIZ

Relación Detalle de Factura Relación Artículos

Sucursal Núm. Código Precio Cantidad Subtotal Código Nombre del Precio
de de unitario del del del de artículo unitario
factur artículo artículo artículo artículo artículo del
a artículo
01 500 01 1.25 3 3.75 01 LÁPIZ 1.25
01 500 02 0.75 6 4.50 02 GOMA 0.75
01 500 10 5.00 8 40.00 10 HOJAS 5.00
01 501 08 4.00 4 16.00 08 COMPÁS 4.00
02 500 20 2.45 2 4.90 20 REGLA 2.45
02 500 10 5.00 2 10.00

Fk
 FNBC – Forma Normal Boyce-Codd
• Unarelación está en FNBC si, y solo si, todo determinante es una clave
candidata. Determinante es el atributo del que depende, funcionalmente y
de manera completa, otro atributo o conjunto de éstos.

• Una relación esta en FNBC si esta en 3FN y si y solo si, las únicas
dependencias funcionales triviales se encuentran dadas entre la clave
primaria y uno o varios.
 4FN
• Una relación está en 4FN si esta en FNBC y además, todas las
dependencias multivaluadas en esta relación son “dependencias
funcionales”.

• El
concepto de dependencia multivaluada, pero que no son dependencias
funcionales, es lo que impide que una relación se encuentre en 4FN.
 5FN
• Una relación R está en 5FN si y solo si, toda dependencia de
reunión en R es una consecuencia de las claves candidatas en R.

• Una relación R está en 5FN si y solo si, toda dependencia de

reunión está condicionada por las claves candidatas de R.
 Diccionario de Datos
• Consiste de un conjunto de metadatos (datos sobre los datos) sobre los
datos utilizados o producidos por el sistema:
• Nombre: Relaciones-plural, atributos-singular, NO ” ” ni caracteres
especiales(excepto _) o acentos
• Descripción
• Alias
• Longitud
• Valores/Dominio
• Tipo de dato
• PK
• FK
• Índice
• Nulos

• También se puede incluir otro tipo de información como: la fecha de

creación, el creador,…