Sunteți pe pagina 1din 21

Programa SQL y Modelamiento de Datos 2012

Del Modelo Fsico Relacional de


Base de Datos










Al finalizar el captulo, el alumno podr:


Analizar y reconocer las estrategias de la migracin del modelo lgico al fsico.
Aplicar las formas normales como medios de refinamiento del modelo.
Establecer un criterio para discernir cundo normalizar o desnormalizar, de acuerdo
con la evaluacin de tiempo de acceso y recursos computacionales empleados.


Temas:


1. El Modelo Fsico Relacional.
2. Generando el Modelo Fsico.
3. Normalizacin de Datos.

Del Modelo Fsico Relacional de Base de Datos 54



1. El Modelo Fsico Relacional







1.1 Definicin

El enfoque relacional es uno de los modelos matemticos ms importantes y actuales
para la representacin de las bases de datos. Se basa en la teora matemtica de las
relaciones, suministrndose por ello, una fundamentacin terica que permite aplicar
todos los resultados de dicha teora a problemas, tales como, el diseo de sub lenguajes
de datos y otros.

El trmino relacin se puede definir matemticamente, como sigue:

Relacin:
Dados los conjuntos D1, D2, ..., Dn (no necesariamente distintos), R es una relacin
sobre esos n conjuntos, si est constituida por un conjunto de n-tuplos ordenados
d1,d2,...dn tales que, d1 D1, d2 D2, ..., dn Dn.

Los conjuntos D1, D2, ..., Dn se llaman dominios de R y n constituye el grado de la
relacin. La cantidad de tuplas constituye la cardinalidad.

Es conveniente representar una relacin como una tabla bidimensional donde cada fila
representa un n-tuplo.













. . .
COLUMNAS
(atributos)
FILAS
(ocurrencias)
. . .
. . .
Del Modelo Fsico Relacional de Base de Datos 55




Cada relacin est compuesta de filas (las ocurrencias de los objetos) y se les
denomina, como tuplos, tuplas, uplos o uplas (en realidad, n-tuplos, pero en muchos
casos se suprime la n cuando no existe posibilidad de confusin).

Tambin la relacin est compuesta por columnas (los atributos o campos que toman
valores en sus respectivos dominios).

No obstante, es importante considerar lo siguiente.

1. No hay dos filas (tuplas) iguales.
2. El orden de las filas no es significativo (1 y 2 se deben a que la relacin es un
conjunto).
El orden de las columnas s es significativo, pues representa el orden de los
dominios implicados; siempre se hace referencia a una columna por su nombre y
nunca por su posicin relativa.
3. El orden de las columnas no es significativo.
4. Cada valor dentro de la relacin (cada valor de un atributo) es un dato atmico (o
elemental), es decir, no descomponible; por ejemplo: un nmero, una cadena de
caracteres. En otras palabras, en cada posicin fila o columna existe un solo valor,
nunca un conjunto de valores.

Una relacin que satisface este ltimo punto se denomina normalizada.
La teora de la normalizacin se basa en la necesidad de encontrar una representacin
del conjunto de relaciones, que en el proceso de actualizacin sea ms adecuada.
Existen diferentes niveles de normalizacin, llamadas formas normales.

Ejemplo:

El ejemplo de suministrador y producto puede ser representado fcil y claramente,
mediante el modelo relacional.

Los atributos de estas dos entidades son:

Suministrador: nmero que lo identifica, nombre, tipo y distrito donde radica.
Producto: nmero que lo identifica, nombre, precio unitario y peso.

Adems, un suministrador puede suministrar muchos productos, mientras que un
producto puede ser suministrado por varios suministradores. Adems, se conoce la
cantidad de un determinado producto que suministra un suministrador dado.

Aclaracin del autor:
En el modelo relacional, tanto los objetos o entidades como las relaciones que se establecen
entre ellos, se representan a travs de tablas, que en la terminologa relacional se
denominan relaciones.

Del Modelo Fsico Relacional de Base de Datos 56



La representacin en el modelo relacional es ms simple que con el modelo jerrquico y
el modelo reticular, ya que con 3 tablas se tiene todo el modelo representado.

En el modelo relacional el resultado de una demanda es tambin una relacin y las
demandas simtricas (en el sentido de ser una la inversa de la otra; por ejemplo,
recuperar los nmeros de los suministradores que suministran el producto P4 y
recuperar los nmeros de los productos que suministra el suministrador S2) requieren
operaciones simtricas.

Asimismo, las diversas formas de expresar las recuperaciones, dan lugar a los lenguajes
relacionales cuyas formas ms representativas son:

lgebra relacional (basado en las operaciones del lgebra de relaciones)
Clculo relacional (basado en el clculo de predicados)


1.2 Ventajas del modelo relacional

Simplicidad, pues el usuario formula sus demandas en trminos del contenido
informativo de la BD, sin tener que atender a las complejidades de la realizacin del
sistema, lo que implica gran independencia de los datos.

La informacin se maneja en forma de tablas, lo que constituye una manera familiar
de representarla.

Al igual que en el modelo reticular, si se tienen relaciones normalizadas no surgen
grandes dificultades en la actualizacin.

S P CANT
S1
S1
S1
S1
S1
S1
S2
S2
S3
S3
S4
S4
S4
P1
P2
P3
P4
P5
P6
P1
P2
P3
P5
P2
P4
P5
3
2
4
2
1
1
3
4
4
2
2
3
4
SP
PNUM PNOM PRECIO PESO
P1
P2
P3
P4
P5
P6
CLAVO
TUERCA
MARTILO
TORNILLO
ALICATE
SERRUCHO

0.10
0.15
3.50
0.20
2.00
4.00
12
17
80
10
50
90
PRODUCTO
SNUM SNOM TIPO DIST
S1
S2
S3
S4
S5
PREZ
RAMOS
ARENAS
VALLE
LPEZ
30
10
20
20
15
SAN ISIDRO
SURCO
SAN ISIDRO
LINCE
LINCE
SUMINISTRADOR
Del Modelo Fsico Relacional de Base de Datos 57



En el modelo del Suministrador-Producto, presentado anteriormente, un ejemplo de
cada tipo de operacin de actualizacin, sera de la siguiente manera.

Creacin: aadir un producto P7. Se agrega la nueva ocurrencia en la tabla
Producto. Es posible hacerlo aunque ningn suministrador lo suministre.

Supresin: se puede eliminar el suministrador S1 sin perder el producto P6, a pesar
de que es el nico que lo suministra.

Modificacin: se puede cambiar el precio del producto P2 sin necesidad de
bsquedas adicionales ni posibilidad de inconsistencias.

No obstante, el proceso de normalizacin no es suficiente.



1.3 Aspectos del modelo relacional

El Modelo Relacional est orientado hacia 3 aspectos sustanciales de los datos:

1.3.1. Estructura de datos relacional

Bajo el enfoque de la estructura, el Modelo Relacional permite analizar las relaciones,
as como, determinar los componentes que conforman cada una de ellas. Estos
componentes son:

Relaciones:
Generalmente se denomina Tabla (aunque existe una diferencia para el
modelo relacional entre Tabla y Relacin).
Cada tabla es una entidad diferente.
Las tablas almacenadas en la base de datos se denominan Tablas Bases.
Las que se crean a partir de ellas, se denominan Tablas Virtuales (Memoria).
Cada relacin posee un nombre que est asociado con los datos que
almacena.
Cada relacin est formada a su vez, por Atributos y Tuplas.

Atributos:
Es un elemento de datos que describe a la entidad representada por medio de la
tabla, que en su implementacin, conforma lo que sera una columna (campo)
de dicha tabla. Cada atributo posee un nombre que, normalmente, sugiere el
tipo de datos que se almacenar en dicho atributo.

Tuplas:
Se denomina as a cada fila de la relacin (tabla). Cada tupla refleja una
ocurrencia de la relacin.
Aclaracin del autor:
Se dice que una de las desventajas del modelo relacional consiste en la dificultad de lograr
productividad adecuada de los sistemas, ya que no se emplean los medios tcnicos idneos,
(tales como las memorias asociativas), siendo necesario simular este proceso, pero en
realidad, la eficiencia y productividad de los sistemas actuales resultan realmente muy
satisfactorias.

Ejemplos de SGBD relacionales:
Query By Example (QBE)(IBM)
MS Access, Informix, Oracle, SQL Server, My SQL

Del Modelo Fsico Relacional de Base de Datos 58



Dominio:
Es el conjunto de valores permitidos para un Atributo, validado por reglas
convencionales o del negocio.
Su implementacin en una base de datos, libera a la misma de los famosos
errores de los usuarios.

Existen los dominios simples, como por ejemplo:

- Sexo, cuyos valores pueden ser Masculino o Femenino.
- Estado Civil, cuyos valores pueden ser Soltero, Casado, Divorciado o
Viudo.
- Tipo de Empleado, cuyos valores pueden ser Estable o Contratado.
- Notas (evaluaciones) cuyos valores van desde 0 hasta 20.

De igual manera, existen los dominios compuestos, como por ejemplo:

- Fecha De Ingreso, compuesto por los dominios:
Da, cuyos valores van desde 1 hasta 31.
Mes, cuyos valores van desde 1 hasta 12.
Ao, cuyos valores van desde 0 hasta 9999 (dependiendo del
negocio).

Propiedades de las Relaciones:
No existen tuplas repetidas. Las tuplas y los atributos no estn ordenados,
todos los atributos tienen valores atmicos.


1.3.2. Integridad de los datos

Permite indicar ciertas restricciones propias del mundo real a la base de datos.
Por ejemplo, no permitir dentro de una Tabla de Artculos, tuplas cuyo atributo
Cdigo sea Nulo.

El modelo Relacional incluye 2 reglas generales, aplicables para todas las bases de
datos bajo este modelo. Estas 2 reglas estn asociadas a los conceptos de Llaves
Primarias y Llaves Forneas.

Llave primaria (primary key - PK)

Es una columna o grupo de columnas que identifican de manera nica a cada
rengln (fila) de la Tabla.
Como es un identificador nico, no se aceptan duplicados en la llave primaria. El
valor de la llave primaria, generalmente, no se puede cambiar.
Las llaves primarias que constan de ms de una columna se llaman Llaves
Compuestas.

Llaves alternas o Candidatas

Una tabla puede tener ms de una columna o combinacin de columnas que
pueden servir como la llave primaria de la tabla. Por ejemplo, en una tabla de
clientes se pueden establecer como llaves candidatas al cdigo del cliente y al
RUC. Tambin, dentro de una tabla de empleados, se podra elegir la llave
primaria entre el cdigo del Empleado o su DNI.
Del Modelo Fsico Relacional de Base de Datos 59



En resumen, las llaves candidatas deben cumplir 2 caractersticas:

Unicidad: garantiza que en cualquier momento no existirn 2 tuplas con la
misma Llave Primaria.
Minimalidad: garantiza que si la llave es compuesta, no se eliminar
ninguno de sus componentes sin romper la propiedad de Unicidad.

Las Llaves Primarias son importantes, ya que el nico modo que garantiza el
Modelo Relacional para acceder a una tupla especfica es por medio del valor
de su llave primaria. Adems, permitirn el manejo de las Llaves Forneas.

Llaves forneas (foreign key)

Es una columna o combinacin de columnas, dentro de una tabla que se
refieren a una Llave Primaria de otra tabla.
La relacin (tabla) que contiene la llave fornea se le conoce como Relacin
Referencial y a la que contiene la llave primaria, como Relacin Objetivo.

La llave fornea no necesariamente puede formar parte de la llave primaria de
una relacin. En la relacin Empleados la llave fornea Cargo no es parte de la
llave primaria. Sin embargo, en las relaciones producto de entidades asociativas,
la llave primaria est compuesta por las llaves forneas provenientes de las
Llaves Primarias de las Entidades que se asocian.
Las llaves forneas sirven para hacer "JOIN" (UNION) de tablas y pueden ser
repetidas o nulas.

Las megarreglas o constraints de integridad de datos

Las dos MEGARREGLAS ms importantes son:

Los Constraints de Integridad de Entidades.
Los Constraints de Integridad Referencial.

Por medio del constraint de integridad de entidades se asegura que la llave
primaria no puede ser NULA ni REPETIDA. Esto es lgico, ya que las tablas
almacenan informacin proveniente del mundo real, del cual siempre existirn
objetos distinguibles.
Por medio del constraint de integridad referencial, una llave fornea debe
coincidir con un valor de la llave primaria, es decir, el valor de la llave fornea
debe ser concordante con algn valor de la llave primaria relacionada.

Existen 3 formas de asegurar la Integridad Referencial, en caso de sufrir alguna
variacin el valor de la llave primaria de donde proviene la respectiva llave
fornea:

- Restringida.
- De cascada.
- Anulacin.


1.2.3. Operaciones con datos

Adicionar registros.
Actualizar registros.
Eliminar registros.
- Lgicamente.
- Fsicamente.
Consultar registros.
Del Modelo Fsico Relacional de Base de Datos 60



2. Generando el Modelo Fsico








A continuacin, se indicar como construir los modelos fsicos, a partir de un modelo lgico
elaborado con ERwin.


PASO A: Definiendo el Modelo Fsico

1. En el control Toggle Logical-Physical de la Barra de herramientas, seleccionar
Physical. En el Men Format, seleccionar Table Display y luego, Column
Datatype.






















Modelo Fsico
Del Modelo Fsico Relacional de Base de Datos 61



2. El modelo fsico, por defecto, utiliza el nombre de la entidad como nombre de la
tabla y adems, las columnas han sido definidas con tipos predeterminados.


PASO B: Seleccin del Software de Bases de Datos en que se generar la nueva
Base de Datos

1. En el men Database, ejecutar la opcin Choose Database.

2. En el dilogo Target Server seleccionar el software de bases de datos a emplear.
De ser necesario, seleccionar tambin la versin. Para este ejemplo, seleccionar
SQL Server.

3. En el control Default Non-Key Null Option especificar si los atributos no claves
permitirn o no, valores nulos como valores predeterminados.





4. Hacer clic en el botn OK.


PSO C: Redefinicin de los Tipos de Datos para el Modelo Fsico

1. Dar clic sobre la entidad con el botn secundario del ratn.

2. Seguidamente, en el men contextual seleccionar Columns.

3. En el dilogo Columns debe aparecer una pestaa SQL Server al costado de la
pestaa General. Seleccionar la pestaa SQL Server.

Del Modelo Fsico Relacional de Base de Datos 62





4. Utilizando la pestaa SQL Server redefinir los tipos de datos de cada atributo de la
entidad, especificando el tamao del mismo.




5. Al finalizar, hacer clic en OK.


PASO D: Generacin de los Objetos de la Base de Datos

En este punto, con la ayuda del SQL Server Managment Studio, crear una base de datos
llamada VENTA, para el ejemplo.

Del Modelo Fsico Relacional de Base de Datos 63



PASO E: Conexin de ERwin con SQL Server

1. Regresar al modelo fsico en ERwin; luego del men Database, ejecutar la opcin
Database Connection.

2. En Authenticacion, elegir Database Authentication.

3. En User Name y Password proporcionar la identificacin y la contrasea de una
cuenta SQL Server vlida. Para este caso, digitar sa en User Name y sa como
Password. (Asegurarse que el servidor de base de datos tenga autenticacin Sql
Server and Windows Authentication, habilitado el login sa y el password del login
sea sa)

4. En Server Name digitar el nombre del servidor SQL.

5. Asimismo, en Database escribir el nombre de la base de datos a la que se desea
conectar (VENTA).




6. Hacer clic en el botn Connect. Si no se recibe ningn mensaje, la conexin se ha
establecido.



PASO E: Creacin de los Objetos de la Base de Datos

Para crear los objetos de la base de datos, ERwin crea un procedimiento que contiene
todas las sentencias SQL que deben ejecutarse para crear los objetos definidos en el
modelo Fsico. Por ello, se puede:

Utilizar la conexin establecida para crear en este momento los objetos de la base de
datos.
Generar un archivo script (programa) que guarde el procedimiento que crea los
objetos de la base de datos y ejecutar posteriormente, el procedimiento desde el
cliente SQL Server.

Conectar
Del Modelo Fsico Relacional de Base de Datos 64



Para revisar el procedimiento que crea los objetos de la base de datos

1. En el men Tools, ejecutar Forward Engineer / Schema Generation.

2. En el dilogo SQL Server 2008/2012 Schema Generation, hacer clic en el botn
Preview. Se podrn ver todas las instrucciones que se ejecutarn para crear los
objetos definidos en el modelo fsico.







3. Hacer clic en el botn Close, al finalizar la revisin.


Hacer clic aqu.
Del Modelo Fsico Relacional de Base de Datos 65



Para crear un script SQL que puede ser editado y ejecutado, posteriormente

1. En el dilogo SQL Server 2008/2012 Schema Generation, dar clic en el botn
Report.

2. En el dilogo Generate SQL Server/SQL Schema Report, especificar la ubicacin
y el nombre del archivo que almacenar el script (guardarlo con extensin sql). Por
ejemplo, ObjetosVentas.sql.




3. Dar clic en el botn Guardar y luego, en OK.



Para generar los objetos de la base de datos desde ERwin

Antes de proceder a generar los objetos de la base de datos, revisar el esquema de
generacin para seleccionar las sentencias SQL a ejecutar.

1. En la lista SQL Server Schema Generation de la ficha Options, seleccionar
Schema. Luego, en la lista Schema Options a la derecha quitar la marca check a
todas las opciones que las tengan.

2. Ahora de la lista de la izquierda, seleccionar View y quitar la marca a las opciones
seleccionadas y continuar as, con las dems opciones.

3. Las nicas opciones que debern seleccionarse sern las siguientes:

Del Modelo Fsico Relacional de Base de Datos 66








4. Hacer clic en el botn Preview. Se podr notar que algunas sentencias SQL han
sido eliminadas del procedimiento original.

5. Para generar los objetos de la base de datos utilizando la conexin establecida,
hacer clic en el botn Generate.

6. La ventana siguiente mostrar un reporte con el resultado de la generacin. En este
caso, todas las sentencias se ejecutaron sin problemas. Luego, dar clic en OK.


Del Modelo Fsico Relacional de Base de Datos 67





Revisin del servidor SQL para comprobar la creacin de los objetos

1. Ingresar al SQL Management Studio; en Authentication, utilizar SQL Server
Authentication, Luego, utilizar sa para Login y Password.

2. Hacer clic sobre la base de datos Venta utilizando el botn secundario del ratn.

3. Del men contextual, ejecutar la opcin Refresh.

4. Expandir Venta y hacer doble clic sobre Tables.









Del Modelo Fsico Relacional de Base de Datos 68



3. Normalizacin de datos








3.1. Definicin

La normalizacin es la expresin formal del modo de realizar un buen diseo, pues
provee los medios necesarios para describir la estructura lgica de los datos en un
sistema de informacin.
La teora de la normalizacin se ha desarrollado para obtener estructuras de datos
eficientes que eviten las anomalas de actualizacin.

El concepto de normalizacin fue introducido por E.D. Codd y fue pensado para
aplicarse a sistemas relacionales; sin embargo, tiene aplicaciones ms amplias.


3.2. Ventajas de la normalizacin

Evita anomalas en la actualizacin.
Mejora la independencia de los datos permitiendo realizar extensiones de la BD,
afectando muy poco o nada, a los programas de aplicacin existentes que acceden
la base de datos.


3.3. Las Formas Normales

La normalizacin involucra varias fases que se realizan en orden. La realizacin de la
2da. fase supone que se ha concluido la 1ra. y as sucesivamente.
Del Modelo Fsico Relacional de Base de Datos 69



Tras completar cada fase, se dice que la relacin est en:

Primera Forma Normal (1FN)
Segunda Forma Normal (2FN)
Tercera Forma Normal (3FN)
Forma Normal de Boyce-Codd (FNBC)


Existen, adems, la Cuarta (4FN) y la Quinta (5FN) Formas Normales.

Primera Forma Normal (1FN): establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas. Las celdas de la tabla deben poseer
valores simples y no se permiten grupos ni arreglos repetidos como valores. Todos
los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Asimismo,
cada columna debe tener un nombre nico, el orden de las columnas en la tabla no
es importante. Dos hileras en una tabla no deben ser idnticas, aunque el orden de
las hileras no es importante.

Segunda Forma Normal (2FN): para que una tabla est en 2NF tiene que cumplir
con lo siguiente:

Estar en 1FN.
Todas las dependencias parciales se deben eliminar y separar dentro de sus
propias tablas. (Una dependencia parcial es un trmino que describe a aquellos
datos que no dependen de la llave primaria de la tabla para identificarlos).
La 2FN slo se aplica para llaves compuestas.


La Tercera Forma Normal (3FN): seala que hay que eliminar y separar cualquier
dato que no sea clave. El valor de esta columna debe depender de la llave. Todos
los valores deben identificarse nicamente por la llave. Del mismo modo, elimina
cualquier dependencia transitiva (aquella en la cual, las columnas que no son llave
son dependientes de otras columnas que tampoco lo son).


Ejemplo de Aplicacin:

A travs de este ejercicio se intenta afirmar los conocimientos de normalizacin, con un
ejemplo simplificado de una base de datos para una pequea biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev
1001 Variable compleja
Murray
Spiegel
McGraw Hill
Prez Gmez,
Juan
15/04/2005
1004 Visual Basic 2005
E.
Petroustsos
Anaya Ros Tern, Ana 17/04/2005
1005 Estadstica
Murray
Spiegel
McGraw Hill Roca, Ren 16/04/2005
1006 Oracle University
Autor1:
Nancy
Greenberg
Autor 2:
Priya Nathan
Oracle Corp.
Garca Roque,
Luis
20/04/2005
1007
Power Builder
10.0
Ramalho McGraw Hill
Prez Gmez,
Juan
18/04/2005
Del Modelo Fsico Relacional de Base de Datos 70



Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener
campos atmicos, pues el nombre del lector es un campo que puede (y conviene)
descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra
en la siguiente tabla.

1NF

CodLibro Ttulo Autor Editorial Paterno Materno Nombres FechaDev
1001
Variable
compleja
Murray
Spiegel
McGraw
Hill
Prez Gmez Juan 15/04/2005
1004
Visual Basic
2005
E. Petroustsos Anaya Ros Tern Ana 17/04/2005
1005 Estadstica
Murray
Spiegel
McGraw
Hill
Roca Ren 16/04/2005
1006
Oracle
University
Nancy
Greenberg
Oracle
Corp.
Garca Roque Luis 20/04/2005
1006
Oracle
University
Priya Nathan
Oracle
Corp.
Garca Roque Luis 20/04/2005
1007
Power Buider
10.0
Ramalho
McGraw
Hill
Prez Gmez Juan 18/04/2005


Como se puede ver, hay cierta redundancia caracterstica de 1NF.
La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de
otra manera, todos los atributos no clave, deben depender por completo de la clave
primaria.

Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el
nombre del lector en realidad no tiene dependencia de este cdigo, por tanto, estos
datos deben ser trasladados a otra tabla.

Del Modelo Fsico Relacional de Base de Datos 71



2NF

CodLibro Ttulo Autor Editorial
1001 Variable compleja Murray Spiegel McGraw Hill
1004 Visual Basic 2005 E. Petroustsos Anaya
1005 Estadstica Murray Spiegel McGraw Hill
1006 Oracle University Nancy Greenberg Oracle Corp.
1006 Oracle University Priya Nathan Oracle Corp.
1007 Power Buider 10.0 Ramalho McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector Paterno Materno Nombres
501 Prez Gmez Juan
502 Ros Tern Ana
503 Roca Ren
504 Garca Roque Luis

Se ha creado una tabla para contener los datos del lector y tambin se cre la columna
CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva
disposicin de la base de datos necesita que exista otra tabla para mantener la
informacin de qu libros estn prestados y a qu lectores.

CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005


Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems, los
atributos no clave, deben ser mutuamente independientes y dependientes por completo,
de la clave primaria. Esto significa que las columnas en la tabla deben contener
solamente informacin sobre la entidad definida por la clave primaria y, por tanto, las
columnas en la tabla deben contener datos acerca de una sola cosa.
En el ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores
y editoriales, por lo cual, se debern crear nuevas tablas para satisfacer los requisitos de
3NF.
Del Modelo Fsico Relacional de Base de Datos 72



3NF

CodLibro Titulo
1001 Variable compleja
1004 Visual Basic 2005
1005 Estadstica
1006 Oracle University
1007 Power Builder 10.0


CodAutor Autor
801 Murray Spiegel
802 E. Petroustsos
803 Nancy Greenberg
804 Priya Nathan
806 Ramalho


CodEditorial Editorial
901 McGraw Hill
902 Anaya
903 Oracle Corp.


Aunque se han creado nuevas tablas para que cada una tenga informacin acerca de
una entidad, tambin se ha perdido la informacin acerca de qu autor ha escrito qu
libro y las editoriales correspondientes, por ende, se debern crear otras tablas que
relacionen cada libro con sus autores y editoriales.


CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806





Del Modelo Fsico Relacional de Base de Datos 73















El resto de las tablas no necesitan modificacin.






























CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903
1007 901
CodLect
or
Patern
o
Matern
o
Nombre
s
501 Prez Gmez Juan
502 Ros Tern Ana
503 Roca Ren
504 Garca Roque Luis
CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005

Normalizacin vs. Desnormalizacin:
Cmo sera si en vez de normalizar las tablas de las bases de datos, se desnormalizarn; suena
incoherente para alguien que ha seguido el dogma de diseo de bases de datos.
Sin entrar en grandes detalles, uno de los resultados casi directos de la normalizacin tiende a ser la
obtencin de varias tablas relacionadas unas con otras de una manera fsica.

El normalizar una base de datos, depende de la aplicacin que se desarrolle. Si el diseo slo tiene una
clase persistente, generalmente, se debera tener una tabla representndola.

Uno de los principales mitos respecto a las consecuencias de normalizar una BBDD es pensar que en un
motor relacional es costoso procesar un join.
Esto incide en el hecho de tener tres tablas (resultado de una normalizacin) y luego, realizar una consulta
sobre las tres tablas, entonces se tendrn que hacer 2 joins.

El tiempo de respuesta es menor si slo se consulta una tabla. En una aplicacin pequea esto pasa
desapercibido, pero en una aplicacin que maneja grandes volmenes de acceso a datos, de seguro que si
se toma en cuenta. Sin embargo, las consultas a una BBDD son solo una pequea parte de lo que una
aplicacin hace con ellas.

Por otro lado, si se quiere eliminar un registro en una tabla, y esa tabla est relacionada con otras, se
tendr que eliminar tambin el registro de esas tablas.

S-ar putea să vă placă și