View
268
Download
3
Category
Preview:
DESCRIPTION
En este documento encontraran como desarrollar la normalización en una base de datos paso a paso y explicando cada una de sus formas existentes
Citation preview
ELECCIÓN DEL SGBD
(DBMS: DATA BASE MANAGEMENTE SYSTEM)
Es el software con capacidad para definir, mantener y utilizar bases de datos. Es aquel que
depende del modelo de con el que deseamos trabajar.
1. Elección del modelo de datos:
Relacional (se establece entre dos o más entidades).
Orientado a objetos
Objeto relacional
Multidimensional
2. Modelo del SGBD (Sistema Gestor de Base de Datos):
Para el modelo relacional existen varios tipos de software para las bases de datos
relacionales, entre ellos anotamos:
Oracle
DB2 de IBM
Interbase de Borland
ACCESS
Hay que tener en cuenta dos tipos de factores al momento de crear una base de datos:
Factores Técnicos:
Fiabilidad
Recuperación – Fallos
Seguridad
Capacidad
Herramientas
Factores No Técnicos:
Costo del software (Licencias)
Costo del Hardware
Costo de mantenimiento
Costo del personal (DBA: Data Base Administrator)
DISEÑO LÓGICO
Es el conjunto de estructuras propias del modelo elegido, por el cual, debe ser acondicionado al
Modelo de Entidad Relacional (MER). Es decir, convertir el modelo a tablas y su resultado será
el Modelo Relaciona o Modelo de Entidad Relacional Normalizado.
Clientes
IdCliente
tipo_documento
numero_documento
nombres
apellidos
dirección
telefono_casa
Celular
Correo
Este diseño contiene una base de datos la cual todavía no está normalizada.
PREPARACIÓN DEL MODELO RELACIONAL MER NORMALIZADO:
Del MER al Modelo Relacional se deben realizar tres pasos para pasar del modelo contextual al
modelo lógico.
Animales
IdAnimal
Nombre
Especie
Raza
color
tamaño
fecha_naciemiento
Facturas
IdFactura
fecha
Servicios
IdServicio
Tipo
Tarifa
1 *
*
*
*
*
*
1
ESQUEMA
CONCEPTUAL
FALTA NORMALIZAR
Registra
Registra
Tiene Tiene
1. Revisión de las relaciones:
Muchos a muchos
Uno a uno
Uno a muchos
2. Revisión de las relaciones (Atributos)
3. Normalización: Existen 6 tipos de normalización, pero se exigen la 3 primeras.
1FN – Primera Forma Normal
2FN – Segunda Forma Normal
3FN – Tercera Forma Normal
Revisión de las Relaciones:
Relación muchos a muchos.- Digamos que tenemos dos tablas, una llamada Profesor y
otra llamada Grupos; en donde la tabla Profesores tiene muchos grupos y la tabla
Grupos puede tener muchos profesores.
En las relaciones muchos a muchos se da origen a una nueva taba y se generan dos
relaciones tipo uno a muchos.
Profesores
(PK)IdProfesor
primernombre
………
Grupos
(PK)IdGrupo
nombre
………
Profesores
(PK)IdProfesor
primernombre
……… ProfesoresGrupos
(FK)IdProfesor
(FK)IdGrupo Grupos
(PK)IdGrupo
nombre
………
Enseña
* *
*
1
*
1
Los atributos de la nueva tabla están compuestos por las Llaves Primarias (PK: Prime Key) de
cada una de las tablas de las relación, más los atributos propios de la relación en las llaves
primarias de ñas tablas, pasan a convertirse en Llaves Foráneas (FK: Foreign Key).
Ahora vemos como quedan las relaciones quitando la relación directa entre profesores y grupos,
y se crea una nueva tabla llamada profesoresgrupos (siempre usar un nombre acorde a la
función que vaya a cumplir dicha tabla), en donde las tablas Profesores y Grupos están
relacionadas con la tabla ProfesoresGrupos. Esta tabla hereda las relaciones de muchos a
muchos, dejando a las otras que interceden en uno a muchos; recordemos que las relaciones
muchos a muchos no deben existir.
Profesores
(PK)IdProfesor Primernombre
1 Robinson
2 Mayra
3 Fernando
Relación uno a uno.- En este tipo de relación se dice que las tablas se deben combinar
y que no deben existir relación uno a uno.
ProfesoresGrupos
(FK)IdProfesor (FK)IdGrupo
1 2
2 5
1 1
3 2
3 1
Grupos
(PK)IdGrupo nombre
2 10-1
1 10-2
5 8
*
1
*
1
Una entidad hereda la clave primaria de las entidades que intervienen en la relación, es
decir, si tenemos dos entidades una de ellas hereda la llave primaria de la otra.
En la opción 1 vemos que la tabla Trabajador hereda la llave primaria de Departamento
y en la opción 2 Departamento hereda la llave primaria de Trabajador.
A continuación mostraremos lo que puede suceder en cada opción que se escoja y así
decidir cuál es la mejor opción a escoger.
Profesores
(PK)IdTrabajador
nombre
………
Profesores
(PK)IdTrabajador
nombre
(FK)IdDepartamento
………
Departamento
(PK)IdDepartamento
nombre
………
Departamento
(PK)IdDepartamento
Nombre
………
Profesores
(PK)IdTrabajador
nombre
………
Departamento
(PK)IdDepartamento
nombre
(FK)IdTrabajador
………
1
1
Dirige
Opción 1
1
1
Dirige
Opción 2
1
1
Dirige
Opcion 1
Trabajador
(PK)IdTrabajador Nombre (FK)IdDepartamento
1 Robinson 1
2 Mayra Null
3 Fernando Null
4 Constain 2
5 Libia Null
Los valores nulos (Null) no son convenientes en este diseño. En el gráfico notamos que
la opción 1 no es la más apropiada ya que solo existen dos departamentos y solo dos
personas en cada uno de ellos, dejando con valores nulos a los demás.
Opción 2
En esta opción podemos fijarnos que es la más óptima, ya que no se generan por ningún
motivo valores nulos.
Departamento
(PK)IdDepartamento Nombre
1 Sistemas
2 Ventas
Trabajador
(PK)IdTrabajador Nombre
1 Robinson
2 Mayra
3 Fernando
4 Constain
5 Libia
Departamento
(PK)IdDepartamento Nombre (FK)IdTrabajador
1 Sistemas 1
2 Ventas 4
Uno a muchos.- La entidad con cardinalidad muchos hereda la llave primaria de la
entidad con cardinalidad uno.
Analizando las relaciones en tablas quedaría:
A este tipo de relaciones se la conoce como Entidades Fuertes y Entidades Débiles, es
decir, la entidad débil no existe si no está la entidad fuerte. Por ejemplo en el caso
Cliente
(PK)IdCliente
nombre
………
Cliente
(PK)IdCliente
nombre
………
Pedido
(PK)IdPedido
fecha
………
Pedido
(PK)IdPedido
fecha
(FK)IdCliente
Pedido
(PK)IdPedido Nombre (FK)IdCliente
1 19/01/14 1
2 12/05/14 1
3 16/06/14 2
4 10/09/14 3
9 01/10/14 4
20 24/12/14 4
25 25/12/14 5
Clientes
(PK)IdCliente Nombre
1 Robinson
2 Mayra
3 Fernando
4 Constain
5 Libia
Hace
1
*
Hace
1
*
Entidad
Débil
Entidad
Fuerte
Clientes y Pedido, un pedido no existe si no hay un cliente, o sea, que son dependientes
una de la otra.
Supongamos que en el ejemplo anterior se borra a Robinson, automáticamente se
borran todos los registros que tengan relación con ese nombre, porque como son
dependientes, no puede existir algo en la tabla que no exista en la otra, a eso se le
conoce con el nombre de Integridad Referencial.
Volviendo al Diseño Lógico de las tablas, podemos notar que necesitamos aplicar las
normas que hemos aprendido, quedando de esta manera:
Relación uno a muchos – Ejemplo:
Ahora vamos a resolver como debemos trabajar con las tablas que tienen relaciones de
uno a muchos y cuál es la opción más óptima que debemos utilizar en este tipo de
relación.
Clientes
IdCliente
tipo_documento
numero_documento
nombres
apellidos
dirección
telefono_casa
Celular
Correo
Animales
IdAnimal
Nombre
Especie
Raza
color
tamaño
fecha_naciemiento
Servicios
IdServicio
Tipo
Tarifa
Facturas
IdFactura
fecha
1
*
*
*
* *
*
1
ESQUEMA
CONCEPTUAL
FALTA NORMALIZAR
Registra
Registra
Tiene Tiene
Notemos que tanto la tabla Animales como la tabla Facturas heredan como llaves
foráneas a IdCliente de la tabla Cliente.
Relación muchos a muchos – Ejemplo:
Recordemos que procedimiento debemos utilizar para poder resolver este tipo de
relaciones.
Vemos con claridad que para poder resolver este tipo de casos, debemos crear una
nueva tabla y le asignamos un nombre que vaya de acuerdo a la función que cumpla, en
Clientes
(PK)IdCliente
tipo_documento
numero_documento
Animales
(PK)IdAnimal
(FK)IdCliente
Nombre
Especie
Facturas
(PK)IdFactura
(FK)IdCliente
fecha
Animales
(PK)IdAnimal
(FK)IdCliente
Nombre
Especie
Servicios
(PK)IdServicio
Tipo
Tarifa
Historial
(FK)IdAnimal
(FK)IdServicio
fecha
Servicios
(PK)IdServicio
Tipo
Tarifa
Facturas
(PK)IdFactura
(FK)IdCliente
Fecha
Detalle
(FK)IdFactura
(FK)IdServicio
cantidad
*
1
*
1
1
* *
1
1
* *
1
este caso son “Historial” en las tablas Animales con Servicios, y “Detalle” en las tablas
Facturas con Servicios. Notemos que las nuevas tablas se colocan llaves foráneas en cada
una de ellas y se agregaron nuevos atributos para tener un mejor control en el manejo
de las relaciones.
NORMALIZACIÓN
La normalización permite obtener un conjunto adecuado de relaciones de tal forma que:
El esquema de la Base de Datos incluya el mínimo número de atributos necesarios para
dar soporte a los requerimientos del sistema.
Resulta más fácil acceder a las Bases de Datos y, sobre todo, mantener los datos
(redundancia mínima: salvo los atributos que forman parte de claves externas, los
demás representaran una única vez en la base de datos).
Si todo lo realizado está bien y teniendo en cuenta que un atributo pertenece a una tabla y no a
otra, entonces la normalización no es necesaria, pero en ocasiones uno no está claro con qué
atributo debe ir a que tabla, entonces si debemos utilizar los métodos de normalización.
En Base de Datos Normalizada:
Las actualizaciones se consiguen realizar con un número mínimo de operaciones
(mejorando la eficiencia de la base de datos y reduciendo la posibilidad de que
aparezcan inconsistencias).
Se reduce al mínimo el espacio de almacenamiento necesario para almacenar los datos
de la base de datos (reduciendo los costes de operación de la base de datos).
Las relaciones que almacenan datos redundantes presentan anomalías de actualización
(la inserción, eliminación o modificación de los datos puede provocar la aparición de
inconsistencias).
Básicamente la normalización nos permite que no haya redundancia en la Base de Datos, que
las consultas sean más fácil de hacer, que sean más entendibles, que si se desea hacer algún
cambio, sea más sencillo y no nos cueste tanto trabajo, mejorando la eficiencia y reduciendo el
almacenamiento de datos repetidos, evitando la redundancia; o sea, que no guardamos datos
que ya están repetidos por ejemplo. No es lo mismo almacenar un nombre en un registro, que
tener que cambiarlo varias veces, ya que nos va a consumir mucho tiempo. Y nos ayuda
eliminando anomalías de actualización cuando insertamos o eliminamos algún dato.
De este gráfico podemos diferenciar los seis tipos de normalización que existen, de las cuales
solo utilizaremos las tres primeras.
Si las tres primeras formas están bien, la Base de Datos está lista para ser implementada en
cualquier sistema gestor y no hay necesidad de usar las otras, salvo el caso en donde si se las
necesite.
1FN – Primera Forma Normal.- Se dice que una taba está en Primera Forma Normal (1FN) si y
solo si, cada uno de los campos contiene un único valor para un registro determinado (Valores
Atómicos).
1FN – Primera Forma Normal: Ejemplo
Creando la nueva tabla auxiliar tendríamos:
C_alumno N_alumno N_asignatura
01 Manuel ADIG
02 Juan PLE, ADIG
03 María ADIG, SIMM
AlumnosAsignaturas
C_alumno N_asignaturas
01 ADIG
02 PLE
02 ADIG
03 ADIG
03 SIMM
Alumnos
C_alumno N_alumno
01 Manuel
02 Juan
03 María
Primera Forma Normal (1FN)
Segunda Forma Normal (2FN)
Tercera Forma Normal (3FN)
Forma Normal de Boyce – Cood (BCNF)
Cuarta Forma Normal (4FN)
Quinta Forma Normal (5FN)
La primera túpla si cumple la primera forma
normal, cada campo de la túpla contiene un
único dato, pero no ocurre así con las túplas
2 y 3 ya que en el campo asignatura contiene
más de un valor.
La solución en este caso es crear dos tablas.
Ahora todos los registros de ambas tablas contienen valores únicos en sus campos, por lo tanto
ambas tablas cumplen la Primera Forma Normal.
2FN – Segunda Forma Normal:
Se denomina clave o Llave Primaria al subconjunto mínimo y no vacío de atributos que permiten
en forma unívoca una túpla dentro de la relación.
Si existen varios conjuntos que cumplan esta condición se denominan claves o Llaves
Candidatas.
Los atributos que conforman parte de la clave primaria o candidata, se denominan atributos
primos, los atributos que no forman parte de ninguna de estas claves se denominan atributos
no primos.
Se define Dependencia Funcional A B, si para cualquier valor de A le corresponde un único
valor de B.
Por ejemplo; si A es el DNI, y B nombre, está claro que cualquier DNI le corresponde un único
nombre del titular.
Se define como Dependencia Funcional Completa; si B depende de A en su totalidad.
Se dice que una tamba se encuentra en Segunda Forma Normal (2FN) si y solo si:
Está en 1FN.
Todos sus atributos No primos dependen funcionalmente de forma completa de la
clave primaria (Existe dependencia funcional).
2FN – Segunda Forma Normal: Ejemplo
Codigo_empleado Codigo_Dpto Nombre Departamento Años
1 6 Juan Contabilidad 6
2 3 Pedro Sistemas 3
3 2 Sonia Ventas 1
4 3 Verónica Sistemas 10
2 6 Pedro Contabilidad 5
Sea la clave primaria de esta tabla formada por los campos Codigo_empleado y Codigo_Dpto,
podemos decir que la tabla se encuentra en 1FN, por tanto vamos a estudiar si está en segunda
forma normal.
Las dependencias funcionales de las relaciones son las siguientes:
Codigo_empleado Nombre
Codigo_Dpto Departamento
Codigo_empleado, Codigo_empleadoNombre
Realizamos su gráfico de dependencia:
Por tanto, al no existir dependencias funcionales totales respecto a la clave de todos los campos
de la relación no está en Segunda Forma Normal, por ello debemos proceder a normalizarla, se
aplica la descomposición de dependencia sólo a aquellas que no se encuentran en Segunda
Forma Normal:
Codigo_Empleado
Codigo_Dpto
Nombre
Departamento
Años
Codigo_Empleado Nombre
Codigo_Dpto Departame
nto
Codigo_Empleado
Codigo_Dpto
Años
Expresando el gráfico en tablas quedaría:
TABLA R1
Codigo_empleado Nombre
1 Juan
2 Pedro
3 Sonia
4 Verónica
Notemos que la Tabla R3 hereda las claves primarias de R1 y R2 y se agrega un atributo llamado
años, esto es igual a la relación muchos a muchos.
3FN – Tercera Forma Normal:
Se define Dependencia Transitiva, en la que existen las siguientes descendencias funcionales:
X Y
Y Z
Se dice que Z tiene una dependencia transitiva respecto a X a través de Y.
Se dice que una tabla se encuentra en 3FN si y solo si:
Está en 2FN.
TABLA R2
Codigo_Dpto Departamento
6 Juan
3 Pedro
6 Sonia
TABLA R3
Codigo_empleado Codigo_Dpto Años
1 6 6
2 3 3
3 2 1
4 3 10
2 6 5
X Y Z Esto no se debe dar para que exista
una 3FN
Ningún atributo no primos dependen no transitivamente de la clave primaria (no existe
dependencia transitiva). Es decir ningún atributo puede depender de otro que no sea la
llave primaria.
3FN – Tercera Forma Normal: Ejemplo
Cogido_alumno Nombre Curso Aula
1 Marcos Informática Aula A
2 Lucas Inglés Aula B
3 Marta Contabilidad Aula C
Dependencias:
Codigo_alumno Nombre Curso;
Curso Aula;
La tabla está en 1FN y comprobamos que también está en 2FN, pero existe Dependencia
Transitiva por lo cual no está en 3FN.
Aplicamos la descomposición sin pérdidas para la dependencia que impide la 3FN obtenemos:
TABLA R2
Codigo Nombre Curso
1 Marcos Informática
2 Lucas Inglés
3 Marta Contabilidad
TABLA R1
Curso Aula
Informática Aula A
Inglés Aula B
Contabilidad Aula C
Codigo_alumno Nombre
Curso Aula
Codigo_alumno Nombre
Curso
Curso Aula
Bibliografía
http://www.youtube.com/watch?v=22iP_0dVW10
http://www.youtube.com/watch?v=Ouuia3eQKRI
Recommended