NORMALIZACION

Diseño de Bases de Datos
Normalización
Elementos básicos del MR
 RELACIÓN
Es la estructura básica del modelo relacional. Se representa
mediante una tabla.
 DOMINIO
Es el conjunto válido de valores que toma un atributo.
Existen con independencia de cualquier otro elemento.
 ATRIBUTO
Representa las propiedades de la relación. Se representa
mediante una columna.
 TUPLA
Es una ocurrencia de la relación. Se representa mediante una
fila.
EJEMPLOS
Normalizando la BD: primera
forma normal (1FN)
 Incorrecto
Clientes
IDCliente Nombre Telefono

45 Francisco 444444444
555555555,
275 Miguel
666666666
 No se permiten grupos repetidos en varias
columnas
 Esto es una variante de lo anterior: separamos los
campos de un mismo dominio en varias columnas,
haciendo un grupo difícilmente procesable a la hora
de consultarlo. En el ejemplo anterior sería tener el
campo telefono1, telefono2… y así. Es evidente que
este fallo del diseño es incluso peor que el anterior
pues habrá muchos campos nulos, y en caso de
necesitar más tendríamos que redimensionar la tabla
con un nuevo campo (telefono3). Pero la solución es
sencilla: la misma que en el anterior caso.
 No se permiten vectores de campos en una
columna.
 Un ejemplo de esto es cuando en un campo de texto
metemos varios valores del mismo dominio, como por
ejemplo tres números de teléfono, o dos direcciones
e-mail. Lo típico en estos casos es separar los datos
por comas, espacios u otro carácter y después
procesarlo mediante la aplicación. Para evitar esto hay
que definir una nueva tabla que tendrá el identificador
de la tabla de la que parte y el campo multivaluado,
haciendo juntos de clave única compuesta (se puede
definir otra incremental si se desea, pero el conjunto
de los otros dos campos tiene que ser único). Además
en esta tabla se puede agregar campos que ayuden a
describir el tipo de registro.
Ejemplo 2: Incorrecto
Clientes
IDCliente Nombre Telefono Telefono2 Telefono3
45 Francisco 444444444 NULL NULL
275 Miguel 555555555 666666666 NULL

Correcto
 Clientes telefonos_cliente
IDCliente Nombre IDCliente Telefono
45 Francisco 45 444444444
275 Miguel 275 555555555
275 666666666
 No se permiten campos nulos
 Esta regla es algo discutible, pero tiene su lógica. Para
empezar, si un campo va a tener valores nulos, ¿qué
proporción de registros tendrán ese campo con valor
nulo? En mi opinión esta regla nos ayuda a separar unas
entidades de otras, porque si una cantidad de registros
tienen unos atributos que otros no, ¿no será que
pertenecen a otra clase? Por ejemplo, si en una tabla de
productos definimos los campos talla, kilates y potencia
se ve que los productos tendrán clases diversas y
entonces habrá que crear una entidad para cada clase
(ropas, joya y eléctricos, por ejemplo) construyendo lo
que se llama una generalización.
Ejemplo3: Incorrecto
productos
IDProducto Nombre Talla Kilates Potencia
Blusa
147 44 NULL NULL
fashion
Broche
155 NULL 24 NULL
duquesa
Subwoofe
221 NULL NULL 1500
r extreme
Correcto
NORMALIZANDO LA BD:
SEGUNDA FORMA NORMAL
(2FN)
Ejemplo: Incorrecto
lineas_pedido
IDCliente IDProducto Cantidad Nombre_producto
Zapatillas deportivas de
29 42 1
tenis
Balón reglamentario de
46 9 5
baloncesto
204 42 1
tenis
144 10 1
rugby
correcto
 Como vemos en la tabla “lineas_pedido” del ejemplo
incorrecto, la única clave candidata es IDCliente +
IDProducto, ya que en conjunto son únicas en la tabla
(podríamos tener un IDLinea_pedido único también, pero
aún así esos dos campos segurían siendo una clave
candidata). El campo Cantidad es dependiente de la clave
candidata, pues el cliente ha pedido de ese producto una
cantidad determinada de artículos, pero el nombre en
cambio es dependiente sólo del producto, no del cliente. Si
dejaramos esa tabla como está, tendríamos por una parte una
redundancia de datos innecesaria pues el nombre del
producto lo podemos sacar uniendo la tabla de productos, y
además podrían darse inconsistencias de datos si
cambiamos el nombre del producto en un registro… ¿cuál
sería el nombre real del producto 42 si en varios registros
tiene un nombre distinto?
NORMALIZANDO LA BD:
TERCERA FORMA NORMAL
(3FN)
Ejemplo: Incorrecto
carga_diaria
Nombre_ser
IDServidor Fecha IDServicio Carga
vicio
21 2009-01-14 1 Oracle 100
21 2009-01-15 9 MySQL 100
21 2009-01-16 22 Apache 85
34 2009-01-14 3 PostgreSQL 74
34 2009-01-15 22 Apache 58
34 2009-01-16 22 Apache 67
66 2009-01-14 9 MySQL 98
66 2009-01-15 22 Apache 94
66 2009-01-16 1 Oracle 10g 84
Correcto
servicios
carga_diaria
IDServidor Fecha IDServicio Carga Nombre_servi
IDServicio
cio
21 2009-01-14 1 100
1 Oracle
21 2009-01-15 9 100
9 MySQL
21 2009-01-16 22 85
22 Apache
34 2009-01-14 3 74
3 PostgreSQL
34 2009-01-15 22 58
22 Apache
34 2009-01-16 22 67
22 Apache
66 2009-01-14 9 98
9 MySQL
66 2009-01-15 22 94
22 Apache
66 2009-01-16 1 84
1 Oracle 10g
 Imaginad que una tabla se encarga de registrar el primer
servicio que más carga los servidores cada día. Del
ejemplo incorrecto deducimos que el IDServidor y la
Fecha son la clave candidata, pues identifican de manera
única los registros. Analizando vemos que el IDServicio,
que no es un campo primario, depende únicamente de la
clave candidata, y que la carga también. Pero resulta que
el Nombre_servicio depende de esa clave candidata pero
también depende del IDServicio, pues con el IDServicio
podemos averiguar qué Nombre_servicio tiene el
registro. Para solucionar esto sacamos el campo
Nombre_servicio de la tabla, y nos llevamos el
IDServicio para que sea la clave principal pues es el
campo del que depende
 Y con este ejemplo vemos qué fácil es librarnos
de las inconsistencias de no cumplir la tercera
forma normal, y de la redundancia de datos. Si
no hubieramos normalizado tendríamos que en
un registro el IDServicio 22 es Apache y nadie
nos asegura que en otro el IDServicio 22 también
lo sea pues puede haberse modificado el campo
Nombre_servicio. Y si resulta que la tabla fuese
un histórico de 500 servidores durante 1000 días,
tendríamos 500 mil registros con un campo
innecesario que estaría duplicado muchísimas
veces.
Proceso de Construcción
de una base de datos
Minimund
o
OBTENCION Y ANALISIS DE
REQUERIMIENTOS
DISEÑO CONCEPTUAL
Modelo Entidad Relación NORMALIZACION
Extendido
Independiente del SGBD

DISEÑO LOGICO
Específico para cada SGBD Tablas
DISEÑO FISICO
¿Cómo utilizamos la normalización
nosotros?
Minimund
o
OBTENCION Y ANALISIS DE
REQUERIMIENTOS
DISEÑO CONCEPTUAL
Modelo Entidad Relación
Extendido
Independiente del SGBD

DISEÑO LOGICO NORMALIZACION
Específico para cada SGBD Tablas
DISEÑO FISICO
Normalización
Objetivo elegir “buenas” estructuras de relaciones
permitiendo
Expresar formalmente las razones por las
que una agrupación de atributos
es mejor que otra
Normalización
“Bondad” de las relaciones
Nivel lógico Nivel de

implementación
Forma en la que los usuarios Forma en la que se manipulan:

interpretan:
• cómo se almacenan las tuplas
• las estructuras de las relaciones de la relación
• el significado de sus atributos • cómo se actualizan las tuplas de
la relación
Aspectos importantes a
considerar a la hora de diseñar
1. Semántica de los atributos

2. Cada atributo debe contener un único valor
3. Reducción de valores redundantes en las
tuplas
1. Semántica de los atributos:
Agrupación de atributos dentro de una

relación
Supone un cierta relación semántica

entre los atributos
2. Cada atributo debe ser monovaluado
Sucursales
Nro_Suc Nombre Telefonos Direccion Localidad Departamento
1 Sacramento 4234322 4234467 Toranzo 350 Norte Desamparados Capital
2 Higueras 4332323 C.Cabot 3350 Oeste Rivadavia Rivadavia
3 Espigas 4223434 4221367 Aberastain 333 Sur Concepcion Capital
4 Santa Rita 4221123 4335678 Av. Libertador 1230 Oeste Desamparados Capital
5 Excelencia 4228976 4223490 Av. Libertador 30 Oeste Capital Capital
6 Castillo 4962579 Ig. de la Roza 671 Caucete Caucete
no es válido no es válido
grupo repetitivo atributo compuesto

2.Cada atributo debe ser monovaluado:
Esto implica que la relación anterior debiera reemplazarse por las siguientes:
Sucursales
Nro_Suc Nombre Direccion Localidad Departamento
1 Sacramento Toranzo 350 Norte Desamparados Capital
2 Higueras C.Cabot 3350 Oeste Rivadavia Rivadavia
3 Espigas Aberastain 333 Sur Concepcion Capital
4 Santa Rita Av. Libertador 1230 Oeste Desamparados Capital
5 Excelencia Av. Libertador 30 Oeste Capital Capital
6 Castillo Ig. de la Roza 671 Caucete Caucete
2. Cada atributo debe ser monovaluado:
Telefonos_Suc
Nro_Suc Telefono
1 4234467
3 4221367
4 4335678
5 4223490
1 4234322
2 4332323
3 4223434
4 4221123
5 4228976
6 4962579
3. Reducción de valores redundantes:

Dentro de los principales objetivos en el
diseño de relaciones
Minimizar el espacio de Evitar anomalías de

almacenamiento actualización
que ocupan las relaciones
base (archivos)

Clientes_de_Sucursal
DNI_Cli Nombre_Cli Tel_Cli Direccion_Cli Nro_Suc Nombre_Suc Direccion_Suc
17.343.232 Ana Perez 4223465 25 de Mayo 504 Este 1 Sacramento Toranzo 350 Norte
7.432.567 Juan Flores 4223312 Av. Cordoba 107 Oeste 1 Sacramento Toranzo 350 Norte
6.987.675 Sergio Alba 4221674 Aberastain 34 Sur 3 Espigas Aberastain 333 Sur
14.878.234 Miguel Gomez 4340023 H. Yrigoyen 1171 Sur 5 Santa Rita Av.Libertador 1230 Oeste
20.333.675 Silvia Gomez 4233495 Av. Libertador 3300 Oeste 3 Espigas Aberastain 333 Sur
6.967.908 Javier Lima 4231100 H. Yrigoyen 11 Sur 6 Castillo Ig. de la Roza 671
Analicemos la redundancia:
• ¿Cuantas veces aparece la información correspondiente a
cada sucursal? ¿Qué problemas puede acarrear?

Analicemos las inserciones:
• ¿Qué sucede si queremos ingresar un nuevo cliente? De que
debemos asegurarnos?
• ¿Qué sucede si queremos ingresar una sucursal nueva que todavía
no tiene clientes? ¿Es posible?

Analicemos las supresiones:
• ¿Qué sucede si queremos eliminar el cliente Miguel Gomez?

Analicemos las modificaciones:
• ¿Qué sucede si queremos registrar que la sucursal Espigas cambio
su dirección?
Estos problemas son denominados
Anomalías de actualización
3. Reducción de valores redundantes
Analicemos los mismos interrogantes con las siguientes relaciones:
Sucursales
Nro_Suc Nombre Direccion Localidad Departamento
1 Sacramento Toranzo 350 Norte Desamparados Capital
2 Higueras C.Cabot 3350 Oeste Rivadavia Rivadavia
3 Espigas Aberastain 333 Sur Concepcion Capital
4 Santa Rita Av. Libertador 1230 Oeste Desamparados Capital
5 Excelencia Av. Libertador 30 Oeste Capital Capital
6 Castillo Ig. de la Roza 671 Caucete Caucete
Clientes
DNI_Cli Nombre_Cli Tel_Cli Direccion_Cli Localidad Departamento
17.343.232 Ana Perez 4223465 25 de Mayo 504 Este Concepcion Capital
7.432.567 Juan Flores 4223312 Av. Cordoba 107 Oeste Capital Capital
6.987.675 Sergio Alba 4221674 Aberastain 34 Sur Capital Capital
14.878.234 Miguel Rueda 4340023 H. Yrigoyen 1171 Sur Rawson Rawson
20.333.675 Silvia Gomez 4233495 Av. Libertador 3300 Oeste Rivadavia Rivadavia
6.967.908 Javier Lima 4231100 H. Yrigoyen 11 Sur Rivadavia Rivadavia
DNI_Cli Nro_Suc
Es_cliente_de 17.343.232 1
7.432.567 1
6.987.675 3
14.878.234 5
20.333.675 3
6.967.908 6
Debemos diseñar las relaciones de manera de evitar las
anomalías de inserción, eliminación y modificación en
las relaciones
Evitar la inconsistencia
de la base de datos
GUÍA PRÁCTICA 1
MODELO ENTIDAD/RELACIÓN
ENUNCIADO
 Utilizar el modelo entidad/relación para modelar:
 El Sauna XYZ requiere registrar el ingreso de los
clientes, guardando un control de fecha y hora de
ingreso; así mismo, asigna una llave numerada a de
un casillero donde el podrá dejar sus pertenencias.
 Cuando el Cliente abandone el sauna, debe entregar la
llave asignada para que el encargado registre la
hora de salida, liberando el casillero para que pueda ser
asignado a otro cliente.
CONOCIMIENTO TEÓRICO REQUERIDO.-
Para la realización de esta práctica el estudiante
debe conocer la notación gráfica del modelo
entidad-relación.
OBJETIVOS.-
 Practicar el modelamiento de bases de datos
MATERIALES Y EQUIPOS.-
 Se empleará como herramienta de trabajo la
notación del modelo entidad-relación
TÉCNICA O PROCEDIMIENTO.-
En esta práctica el estudiante debe:
 Diseñar la base de datos utilizando el modelo
entidad-relación
 Realizar varias pruebas para verificar que el
modelo propuesto este completo
TIEMPO DE DURACIÓN DE LA PRÁCTICA.-

 Se estima 2 clase
RESULTADOS ESPERADOS.-
 A la conclusión de la práctica el estudiante tendrá la habilidad
de obtener los requerimientos de los usuarios y las destrezas para
diseñar bases de datos utilizando la notación del modelo entidad-
relación.
CUESTIONARIO.-
 ¿Qué resultó más difícil para usted en la solución de los problemas
planteados?
 ¿Qué pasos aplicó en la construcción del modelo entidad/relación?
 ¿Alguno de los ejercicios requirió la utilización de entidades débiles?

NORMALIZACION

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NORMALIZACION

Transféré par

Droits d'auteur :

Formats disponibles

Diseño de Bases de Datos

IDCliente Nombre Telefono

45 Francisco 444444444 NULL NULL

275 Miguel 555555555 666666666 NULL

275 Miguel 275 555555555

Independiente del SGBD

Independiente del SGBD

Objetivo elegir “buenas” estructuras de relaciones

Nivel lógico Nivel de

Forma en la que los usuarios Forma en la que se manipulan:

1. Semántica de los atributos

Agrupación de atributos dentro de una

Supone un cierta relación semántica

grupo repetitivo atributo compuesto

3. Reducción de valores redundantes:

Minimizar el espacio de Evitar anomalías de

3. Reducción de valores redundantes:

3. Reducción de valores redundantes:

3. Reducción de valores redundantes:

3. Reducción de valores redundantes:

3. Reducción de valores redundantes:

Estos problemas son denominados

TIEMPO DE DURACIÓN DE LA PRÁCTICA.-

Vous aimerez peut-être aussi