SISTEMAS DE ADMINISTRACION DE BASES DE DATOS (DBMS)

CURSO SQL
www.senavirtual.edu.co
UNIDAD UNO
LECTURA 1:SISTEMAS DE ADMINSITRACIN DE BASES DE DATOS (DBMS)
Un sistema de administracin de bases de datos DBMS (Database Management System, por sus
siglas en Ingls) es un sistema basado en computador (software) que maneja una base de datos, o
una coleccin de bases de datos o archivos. La persona que administra un DBMS es conocida
como el DVA (Database Administrator, por sus siglas en ingles).

USOS Y FUNCIONES DE UN DBMS: Los sistemas de administracin de bases de datos son usados
para:
Permitir a los usuarios acceder y manipular la base de datos proveyendo mtodos para
construir sistemas de procesamiento de datos para aplicaciones que requieran acceso a
los datos
Proveer a los administradores las herramientas que les permitan ejecutar tareas de
mantenimiento y administracin de los datos.
Otras de las funciones de un DBMS son:
Definicin de la base de datos - como la informacin va a ser almacenada y organizada.
Creacin de la base de datos - almacenamiento de datos en una base de datos definida.
Recuperacin de los datos - consultas y reportes.
Actualizacin de los datos - cambiar los contenidos de la base de datos.
Programacin de aplicaciones de para el desarrollo de software.
Control de la integridad de la base de datos.
Monitoreo del comportamiento de la base de datos
Los sistemas de bases de datos relacionales RDBMS (Relational Database Management System,
por sus siglas en Ingls) tales comoOracle, MySQL, SQL Server, PostgreSQL, Informix, entre otros,
le permiten ejecutar las tareas que se mencionan a continuacin, de una forma entendible y
razonablemente sencilla:
1. Le permiten ingresar datos al sistema.
2. Le permiten almacenar los datos.
3. Le permiten recuperar los datos y trabajar con ellos.
4. Le proveen herramientas para capturar, editar y manipular datos.
5. Le permiten aplicar seguridad.
6. Le permiten crear reportes e informes con los datos.
CARACTERISTICAS DE UN DBMS
Control de la redundancia de datos: Este consiste en lograr una mnima cantidad de espacio de
almacenamiento para almacenar los datos evitando la duplicidad de la informacin. De esta
manera se logran ahorros en el tiempo de procesamiento de la informacin, se tendrn menos
inconsistencias, menores costos operativos y har el mantenimiento ms fcil.
Compartimiento de datos: Una de las principales caractersticas de las bases de datos, es que los
datos pueden ser compartidos entre muchos usuarios simultneamente, proveyendo, de esta
manera, mxima eficiencia.
Mantenimiento de la integridad: La integridad de los datos es la que garantiza la precisin o
exactitud de la informacin contenida en una base de datos. Los datos interrelacionados deben
siempre representar informacin correcta a los usuarios
Soporte para control de transacciones y recuperacin de fallas: Se conoce como transaccin toda
operacin que se haga sobre la base de datos. Las transacciones deben por lo tanto ser
controladas de manera que no alteren la integridad de la base de datos. La recuperacin de fallas
tiene que ver con la capacidad de un sistema DBMS de recuperar la informacin que se haya
perdido durante una falla en el software o en el hardware.
Independencia de los datos: En las aplicaciones basadas en archivos, el programa de aplicacin
debe conocer tanto la organizacin de los datos como las tcnicas que le permiten acceder a los
datos. En los sistemas DBMS los programas de aplicacin no necesitan conocer la organizacin de
los datos en el disco duro.
Seguridad: La disponibilidad de los datos puede ser restringida a ciertos usuarios. Segn los
privilegios que posea cada usuario de la base de datos, podr acceder a mayor informacin que
otros.
Velocidad: Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
Independencia del hardware: La mayora de los sistemas DBMS estn disponibles para ser
instalados en mltiples plataformas de hardware.


LECTURA 2: DEFINICIN Y TERMINOLOGIA DE UN RDBMS
Los sistemas de bases de datos relacionales son aquellos que almacenan y administran de manera
lgica los datos en forma de tablas. Una TABLA es, a su vez, un mtodo para presentar los datos
en la forma de filas y columnas.
Cada columna representa un campo nico de registro. Varias de estas columnas o campo
componen un registro, proveyendo informacin significativa e interrelacionada. Cada registro es
representado en una fila. Una tabla puede consistir en varias columnas. Muchas de las tablas que
poseen datos interrelacionados e interdependientes son agrupadas por medio del establecimiento
de relaciones entre ellas. Al administrar las tablas y sus relaciones, encontramos los medios para
insertar, borrar, consultar y actualizar la informacin de un sistema RDBMS
TABLA EMPLEADOS
NUM-EMP NOMBRE-EMP NUM-DEPT
1001 Andres AB101
1002 Maria AB102
1003 Jose AB103
Figura Nmero 1
TABLA DEPARTAMENTOS
NUM-DEPT NOMBRE-DEPT
AB101 Finanzas
AB102 Contabilidad
AB103 Ventas
Figura Nmero 2
En la tabla anterior, la tabla Empleados est compuesta por tres columnas y tres filas. Las
columnas o campos conforman un registro lgico, correspondiente a un empleado. La tabla
empleados est relacionada con la tabla Departamentos por medio de una columna Numero de
Departamento que aparece en ambas tablas.
Llave Primaria
Hemos visto que los datos son almacenados de manera lgica en tablas en las Bases de Datos
relacionales. Cada tabla tiene un nombre nico. Para identificar una fila particular en una tabla,
se una columna o combinacin de columnas. Esta columna debe ser tal que identifique de manera
nica e inequvoca cada fila. No puede haber mas de dos filas (registros) en una tabla que tengan
el mismo valor para la columna que haya sido elegida como llave primaria. Una columna
identificada como la llave primaria no puede tener valores duplicados no nulos. Por ejemplo,
considerando la tabla de Empleados presentada en la Figura N0. 1, podemos ver que cada
empleado tiene un nico numero de empleado. La columna NUM-EMP puede ser escogida
como la llave primaria. Similarmente, la columna NUM-DEPT en la tabla de Departamentos
puede ser igualmente una llave primaria.

Llave Fornea
La llave primaria y la llave fornea son usadas para establecer relaciones entre tablas. En la figura
nmero 1 el dominio de los valores de la columna NUM_DEPT de la tabla Empleados se
encuentra dentro del rango de valores de la columna NUM_DEPT de la tabla Departamentos.
Un empleado debe pertenecer a un Departamento que est listado en la tabla Departamentos. Se
considera entonces que la columna NUM_DEPT en la tabla Empleados es una llave fornea. De
esta manera, la existencia de esta llave fornea en la tabla Empleados controla que no pueda ser
ingresado un nuevo registro de un empleado si este no pertenece primero a un Departamento. Si
el empleado que desea ingresarse a la tabla trabaja en un Departamento que no est listado en la
tabla Departamentos, primero debe crearse el registro del Departamento en su respectiva tabla, y
luego si procedemos a ingresar al empleado. Este tipo de control que impone la asignacin de una
llave fornea en una tabla es de mucha utilidad.
En la figura nmero 2 hemos establecido la siguiente convencin: En los esquemas de tablas, las
llaves primarias estn subrayadas. Igualmente diagramaremos restricciones de integridad
referencial a travs de lneas de conexin que van desde cada llave fornea hasta la llave primaria
que referencie. Para que haya mejor claridad, la punta de la flecha deber apuntar hacia la llave
primaria de la tabla referenciada
NUM_EMP NOMBRE-EMP APELLIDO CARGO SALARIO EXTENSION NUM-DEPT
Empleados

NUM-DEPT NOMBRE-DEPT UBICACION
Departamentos

Nulos
Un Nulo se puede interpretar como un valor indefinido o como ningn valor. Los nulos son usados
en las columnas donde se desconozca su valor. Un nulo no significa espacios en blanco. Un valor
nulo no puede ser usado para hacer ningn clculo u operaciones de comparacin. Un nulo
puede ser comparable a un infinito. Un nulo no es igual a otro nulo
Vistas
Los RDBMS gestionan la estructura fsica de los datos y su almacenamiento. Con esta
funcionalidad, el RDBMS se convierte en una herramienta de gran utilidad. Sin embargo, desde el
punto de vista del usuario, se podra discutir que los RDBMS han hecho las cosas ms complicadas,
ya que ahora los usuarios ven ms datos de los que realmente quieren o necesita, puesto que ven
la base de datos completa. Conscientes de ese problema, los RDBMS proporcionan un mecanismo
de vistas que permite que cada usuario tenga su propia vista o visin de la base de datos. El
lenguaje de definicin de datos permite definir vistas como subconjuntos de la base de datos. Las
vistas, adems de reducir la complejidad permitiendo que cada usuario vea slo la parte de la base
de datos que necesita, tienen otras ventajas:
Las vistas proporcionan un nivel de seguridad, ya que permiten excluir datos para que
ciertos usuarios no los vean. Las vistas proporcionan un mecanismos para que los
usuarios vean los datos en el formato que deseen
Una vista representa una imagen consistente y permanente de la base de datos, incluso si
la base de datos cambia su estructura


LECTURA 3: PROPIEDADES DE UN RDBMS REGLAS DE CODD
Un sistema de bases de datos (DBMS) puede ser considerado como relacional si sigue las tres
reglas de oro, las cuales se enuncian a continuacin:
1. Toda la informacin debe estar representada en tablas
2. La recuperacin de los datos debe ser posible usando sentencias de SELECT, JOIN y
PROJECT
3. Todas las relaciones entre los datos deben ser explcitamente representadas en los
mismos datos
Para definir los requerimientos de una base de datos relacional RDBMS mas rigurosamente, Codd
ha formulado 12 reglas comnmente conocidas como las Reglas de Codd. De un producto se
puede decir que es real y completamente relacional si sigue todas las reglas, pero no existe
ninguno que efectivamente si las cumpla. Por eso es que se ha generalizado el uso de la regla No.
0 que reza: Cualquier base de datos relacional verdadera debe ser administrable enteramente a
travs de sus propias capacidades relacionales.
Regla No. 1 La Regla de la informacin
Toda la informacin en un RDBMS est explcitamente representada de una sola manera, por
valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la
informacin, incluyendo nombres de tablas, nombres de vistas, nombres de columnas y los datos
de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que
contienen tal informacin constituyen el Diccionario de Datos.
Regla No. 2 La regla del acceso garantizado
Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el
nombre de la tabla, su llave primaria y el nombre de la columna. Esto significa que dado un
nombre de tabla, dado el valor de la llave primaria y dado el nombre de la columna requerida,
deber encontrase uno y solamente un valor. Por esta razn la definicin de llaves primarias para
todas las tablas es prcticamente obligatoria.
Regla No. 3 Tratamiento sistemtico de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de valores nulos. Un RDBMS debe
ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o
inaplicables.
Regla N0. 4 La regla de la descripcin de la base de datos
La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en
tablas y columnas y debe ser accesible a los usuarios autorizados. La informacin de tablas, vistas,
permisos de acceso de usuarios autorizados, etc., debe ser almacenada exactamente de la misma manera:
En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de sentencias de SQL.
Regla No. 5 La regla del sub-lenguaje integral
Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de
datos, definicin de vistas, restriccin de integridad y control de autorizaciones y transacciones. Esto
significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para
administrar completamente la base de datos.
Regla No. 6 La regla de la actualizacin de vistas
Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo. La
mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas
complejas.
Regla No. 7 La regla de insertar y actualizar
La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperacin o
consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos. Esto significa que las
clusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros
independientemente del tipo de relaciones y restricciones que haya entre las tablas.
Regla No. 8 La regla de la independencia fsica
El acceso de usuarios a la base de datos, a travs de terminales o programas de aplicacin, debe
permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean
cambiados los mtodos de acceso a los datos. El comportamiento de los programas de aplicacin y de la
actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de
datos y este comportamiento debera permanecer inalterado, independientemente de los cambios en la
definicin fsica de sta.
Regla No. 9 La regla de independencia lgica
Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente
inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de
datos. La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de
terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica
no deben alterar o modificar estos programas de aplicacin.
Regla No. 10 La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definibles sin los datos y almacenables en el catlogo, no en
el programa de aplicacin. Las reglas de integridad son: 1. Ningn componente de una llave primaria
pueden tener valores en blanco o nulos. (esta es la norma bsica de integridad). 2. Para cada valor de llave
fornea deber existir un valor de llave primaria concordante. La combinacin de estas reglas aseguran que
haya Integridad referencial.
Regla No. 11 La regla de la distribucin
El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos este distribuida
fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin. El soporte para
bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en
una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada por una variedad de
redes, pueda funcionar como si estuviera disponible como una nica base de datos en una sola mquina.
Regla No. 12 Regla de la no-subversin
Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para
violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).
Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo
que hace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.
RESUMEN
Un RDBMS debe proporcionar a los usuarios la capacidad de almacenar datos en la base de datos,
acceder a ellos y actualizarlos. Esta es la funcin fundamental de un RDBMS y por supuesto, el
RDBMS debe ocultar al usuario la estructura fsica interna (la organizacin de los archivos y las
estructuras de almacenamiento).
Un RDBMS debe proporcionar un catlogo en el que se almacenen las descripciones de los datos y
que sea accesible por los usuarios. Este catlogo es lo que se denomina diccionario de datos y
contiene informacin que describe los datos de la base de datos (metadatos). Normalmente, un
diccionario de datos almacena: Nombre, tipo y tamao de los datos y nombre de las relaciones
entre los datos.
Un RDBMS debe proporcionar un mecanismo que garantice que todas las actualizaciones
correspondientes a una determinada transaccin se realicen, o que no se realice ninguna. Una
transaccin en el sistema informtico de los empleados de una empresa (por ejemplo) sera dar de
alta a un empleado o eliminar un cargo. Una transaccin un poco ms complicada sera eliminar un
Departamento o divisin y reasignar todos sus empleados a otro Departamento. En este caso hay
que realizar varios cambios sobre la base de datos. Si la transaccin falla durante su realizacin,
por ejemplo porque falla el hardware (o se va la energa elctrica), la base de datos quedar en un
estado inconsistente. Algunos de los cambios se habrn hecho y otros no, por lo tanto, los cambios
realizados debern ser deshechos para devolver la base de datos a un estado consistente.
Un RDBMS debe proporcionar un mecanismo capaz de recuperar la base de datos en caso de que
ocurra algn suceso que la dae. Como se ha comentado antes, cuando el sistema falla en medio
de una transaccin, al base de datos se debe devolver a un estado consistente. Este fallo puede ser
a causa de un fallo en algn dispositivo hardware o un error del software, que hagan que el RDBMS
aborte o puede ser a causa de que el usuario detecte un error durante la transaccin y la aborte
antes de que finalice. En todos estos casos, el RDBMS debe proporcionar un mecanismo capaz de
recuperar la base de datos llevndola a un estado consistente.
Un RDBMS debe proporcionar un mecanismo que garantice que slo los usuarios autorizados
pueden acceder a la base de datos. La proteccin debe ser contra accesos no autorizados, tanto
intencionados como accidentales
Un RDBMS debe ser capaz de integrarse con algn software de comunicacin. Muchos usuarios
acceden a la base de datos desde terminales. En ocasiones estos terminales se encuentran
conectados directamente a la mquina sobre la que funciona el RDBMS. En otras ocasiones los
terminales estn en lugares remotos, por lo que la comunicacin con la mquina que alberga al
RDBMS se debe hacer a travs de una red. En cualquiera de los dos casos, el RDBMS recibe
peticiones en forma de mensajes y responde de modo similar. Todas estas transmisiones de
mensajes las maneja el gestor de comunicaciones de datos. Aunque este gestor no forma parte del
RDBMS, es necesario que el RDBMS se pueda integrar con l para que el sistema sea
comercialmente viable.
Un RDBMS debe proporcionar los medios necesarios para garantizar que tanto los datos de la base
de datos, como los cambios que se realizan sobre estos datos, sigan ciertas reglas. La integridad de
la base de datos requiere la validez y consistencia de los datos almacenados. Se puede considerar
como otro modo de proteger la base de datos, pero adems de tener que ver con la seguridad,
tiene otras implicaciones. La integridad se ocupa de la calidad de los datos. Normalmente se
expresa mediante restricciones, que son una serie de reglas que la base de datos no puede violar.
Por ejemplo, se puede establecer la restriccin de que el nmero de cdula de un empleado no
puede tener caracteres alfanumricos, o por ejemplo que para dar de alta a un empleado ste debe
pertenecer obligatoriamente a un Departamento. En este caso sera deseable que el RDBMS
controlara que no se violen esas reglas cada vez que se ingresen los datos de un empleado a la base
de datos de la empresa.


LECTURA 4: NORMALIZACIN
Una base de datos tiene que ser diseada antes de que pueda ser creada y usada. El diseo debe
ajustarse a estndares que permitan ahorro de memoria, acceso rpido, fcil mantenimiento,
portabilidad, facilidad de futuros mejoramientos, buen desempeo y eficiencia de costos, entre
otros. El diseo lgico final de una base de datos debe ser tal que equilibre un desempeo ptimo
junto con la integridad de la informacin. Esto puede ser logrado a travs de un proceso conocido
como Normalizacin. La base de datos debe estar en un estado de Forma completamente
normalizada
Definicin de Normalizacin
Normalizacin es una serie de reglas que involucra anlisis y transformacin de las estructuras de
los datos en relaciones que exhiban propiedades nicas de consistencia, mnima redundancia y
mxima estabilidad.
La necesidad para normalizar puede ser mejor comprendida al mencionar las distintas anomalas o
desventajas de los datos NO NORMALIZADOS. Consideremos la tabla en la figura 3. La tabla
contiene todos los detalles de los empleados de una compaa y los detalles del Departamento al
que pertenecen.
numEmp nombre salario ingreso numDept descDept
1001 Andres $500.000 1-Ene-01 AB101 Sistemas
1002 Maria $700.000 16-Mar-02 AB101 Sistemas
1003 Carlos $350.000 5-Dic-01 AB101 Finanzas
1004 Felipe $800.000 15-Jun-01 AB103 Finanzas
1005 Oscar $500.000 1-Ene-03 AB102 Contabilidad
1006 Martha $700.000 5-Dic-01 AB104 Ventas
1007 Beatriz $800.000 1-Ene-01 AB110 Gerencia
Figura Nmero 3
A primera vista, parece conveniente almacenar todos los detalles en una sola tabla. Pero ciertas
anomalas se pueden manifestar durante la insercin, actualizacin y borrado de datos. La
normalizacin provee un mtodo de remover todas estas indeseables anomalas haciendo la base
de datos ms confiable y estable.
Anomala de insercin (INSERT)
Suponga que un nuevo Departamento ha sido creado, el cual no tiene empleados todava, por lo
tanto, en nuestra tabla original, los datos correspondientes al empleado estaran vacos (nulos) y
solo tendramos la informacin del Departamento: Columnas numDept y descDept

Anomala de actualizacin (UPDATE)
Suponga que el nmero del Departamento de Sistemas ha sido cambiado a AB108. Esto
involucra tener que cambiar el nmero del departamento para todos los empleados que
pertenezcan al departamento de Sistemas, lo cual representa tiempo y recursos de sistema
adicionales
Anomala de borrado (DELETE)
Si todos los empleados en el Departamento de Finanzas abandonan la compaa, todos los
registros de estos tendran que ser borrados. Hecho as, los detalles del Departamento Finanzas
se perderan. Los datos en la tabla entonces no representan una informacin correcta sobre el
estado de la compaa y por lo tanto se pierde la integridad de los datos
PROPIEDADES DE UNA BASE DE DATOS DESPUS DE LA NORMALIZACIN
Una base de datos normalizada debe representar las siguientes propiedades:
Los requerimientos para almacenamiento de datos se minimizan, dado que el proceso de
normalizacin sistemticamente elimina la duplicacin de los datos
Desde que los datos son almacenados en el mnimo nmero de lugares, las posibilidades
de inconsistencias en la informacin son reducidas al mnimo
Las estructuras normalizadas son ptimas para efectuar actualizaciones de los datos.
Dado que los datos existen en el mnimo nmero de lugares, una operacin de
actualizacin (UPDATE) necesitar acceder a una mnima cantidad de datos
PROCEDIMIENTOS DE NORMALIZACIN
El proceso de normalizacin involucra bsicamente tres pasos. Despus de cada paso, la base de
datos se convierte en formas llamadas formas normales. Generalmente, la tercera forma
normal es el estado que debe alcanzar una base de datos para que se diga que est totalmente
normalizada. La cuarta y la quinta forma normal tambin existen, pero no son usadas en el diseo
de una base de datos.
A continuacin, consideremos un pequeo ejercicio acerca de un Documento de Orden de
Compra, el cual trataremos de convertirlo a una forma normalizada. Pero antes explicaremos
unas pequeas reglas:
Propiedades de una relacin: Una tabla debe satisfacer ciertos criterios previos antes de calificar
para convertirse en una relacin
No duplicados: No debe haber nunca dos columnas o filas totalmente idnticas, entonces hacen
falta algunos atributos que las haga diferentes y distinguibles. Ejemplo: Dos registros de discos
compactos en una tienda seran idnticos si son dos copias del ltimo lbum de Shakira, si no
fuera porque cada disco compacto tiene un nmero cdigo que los hace diferentes
Clave nica: Cada registro tiene que tener una llave nica que lo identifique. Cualquier atributo
puede ser una llave, pero en lo posible trataremos de elegir como llave nica al atributo que tenga
una longitud menor y fija, como por ejemplo un numero de ID. Si un atributo es insuficiente para
identificar un registro de manera nica, entonces ms de un atributo puede conformar la llave
nica. En tal caso, el nmero de atributos que conformen una llave debe ser el mnimo necesario
y suficiente
Insignificancia del orden: La secuencia en la cual los atributos son escritos no debe importar.
Podemos escribir el ID del empleado de primero o el nombre y el apellido de primero y esto no
afectar las relaciones que establezcamos con otras tablas. Por otro lado, los registros deben ser
totalmente independiente de su secuencia o posicin en la base de datos (dependencia
posicional). Esto significa que si intentamos identificar un registro por su posicin dentro de la
tabla, estaremos creando una llave
Forma no-normalizada: Los datos, en su forma elemental, no estn normalizados. Por lo tanto, lo
primero con lo que debemos comenzar es con los datos elementales o bsicos que conformarn el
diccionario de datos. El diccionario de datos es creado a partir de los documentos o diagramas de
flujo de la compaa. Se deben listar los elementos uno debajo del otro. As, obtendremos la
forma no-normalizada para el ejercicio de ARD (Anlisis Relacional de Datos), con el cual
deberemos obtener al final distintos grupos de elementos. Ms tarde, dichos grupos se
combinarn con los grupos de otros documentos al cual tambin se les ha hecho el anlisis ARD y
se establecern relaciones entre ellos

LECTURA 5: EJERCICIO
Consideremos el documento ORDEN DE COMPRA de la figura 4, usado para colocar una orden de
pedido al proveedor de discos compactos

Figura Nmero 4
FORMA UNF (UNNORMALIZED FORM) O NO-NORMALIZADA
ORD-NO: Nmero de Orden de Compra
ORD-DATE: Fecha de la Orden de Compra
PROV-NO: Numero del Proveedor
PROV-NAME: Nombre del Proveedor
PROV-DIR: Direccin del Proveedor
PROV-NIT: NIT o Cdula del Proveedor
CODIGO: Cdigo del CD o lbum
TITULO: Titulo del CD o lbum
CANT: Cantidad de CDs a pedir
VR-UNIT: Valor unitario del CD o lbum
Incluso las formas no normalizadas deben tener una llave. En el ejemplo de arriba, podemos
deducir que ORD-NO es la llave. Las llaves usualmente son subrayadas durante el anlisis ARD
PRIMERA FORMA NORMAL (1FN)
Regla 1. Separar el grupo repetitivo:
En la lista de arriba, los tems despus de PROV-NIT son repetitivos, esto quiere decir, que para
una misma orden aparecen varias veces, dado que en una misma orden se pueden encargar varias
categoras o varios ttulos de la misma categora.
Los grupos repetitivos deben ser separados de la UNF y ser escritos como un grupo independiente
con su respectiva llave. Este grupo debe relacionarse con el grupo no repetitivo enlazando la llave
del grupo no repetitivo junto con la llave del repetitivo. De esta manera tenemos:

El grupo repetitivo tiene a CODIGO como llave. Sin embargo, esta llave no es nica, dado que se
puede repetir en otros nmeros de orden. Necesita ser combinada con la llave del primer grupo.
Al combinar el campo ORD-NO junto con el campo CODIGO para el segundo grupo, podemos
deducir que esta combinacin puede actuar como llave nica, ya que no puede haber una misma
orden que tenga 2 cdigos iguales. Por lo tanto, despus de aplicar la primera forma normal,
obtenemos estos grupos:


SEGUNDA FORMA NORMAL (2FN)
Regla 2. Separar dependencias de las llaves compuestas.
Solo aquellos grupos de datos que tengan llaves combinadas son analizados (llaves que tengan
ms de un campo o atributo para lograr unicidad). Por lo tanto, para la segunda forma normal,
nos concentraremos solo en el grupo 2, el cual tiene una llave compuesta.
En el grupo 2, cualquier atributo que no dependa enteramente de la llave compuesta (es decir,
que no dependa de todos los atributos de la llave a la vez sino de uno solo de ellos) es separado
del grupo principal y es aislado en un grupo independiente junto con el atributo de la llave inicial
del cal si es dependiente. Veamos el proceso para que haya mayor claridad:
Al analizar el grupo 2, encontramos que el campo TITULO depende enteramente del campo
CODIGO y no de la llave compuesta. Llegamos a esta conclusin deduciendo que el ttulo del CD
est asociado a un nico cdigo, por lo cual podramos pensar que CODIGO y TITULO son campos
redundantes ya que con cualquiera de ellos podemos identificar al elemento, pero pensemos en
que el diseo no nos permite deshacernos de ninguno de los campos, ya que las instrucciones nos
obligan a usar y almacenar TODA la informacin disponible en el diccionario de datos.
Por ello, lo que si podemos hacer, aplicando la segunda forma normal, es aislar un tercer grupo,
que tenga a CODIGO como llave y TITULO como campo de la tabla. Igual sucede con el campo
VLR-UNIT; este ampo est asociado exclusivamente al campo CODIGO. Esto es, cada Titulo de CD
con un cdigo determinado, debe corresponder a un valor de venta que se establece una sola vez
por cada elemento. De esta manera, si en algn momento necesitamos alterar el valor unitario de
un CD, slo debemos hacerlo en la tabla del grupo 3, una nica vez por elemento.
En conclusin, despus de aplicar la segunda forma normal, obtenemos estos grupos:

En este nivel, ya nos podemos imaginar mentalmente la utilidad de separar el diccionario de datos
en distintos grupos. Imaginmonos que queremos ingresar 50 rdenes al sistema y en todas est
incluido el CD de Juanes, cuyo cdigo es 1520. El ttulo asociado al cdigo 1520 es Fjate Bien. Si
no existiera el grupo 3, para cada una de las rdenes estaramos ingresando no slo 50 veces el
cdigo 1520, sino que tambin nos toca digitar 50 veces el texto Fjate bien. Consideramos que
esto ltimo es un trabajo que se puede ahorrar al aplicar la segunda forma normal, ya que si
dejamos una tabla separada para CODIGO y TITULO, al ingresar las rdenes solo nos toca digitar 50
veces el cdigo 1520 en la tabla del grupo 2 (cada vez asociado a un nmero de orden distinto y
nico) y una sola vez el mismo cdigo en la tabla 3, con lo cual el texto
que ser digitado una vez. En el evento en que se n
de la tabla 2, simplemente usaremos el valor del campo CODIGO de dicho registro para trasladar la
consulta a la tabla 3, quien nos devolver la informacin buscada del
Si han logrado entender la justificacin
gran terreno ganado en el proceso de
TECERA FORMA NORMAL (3FN)
Todos los campos o atributos en cada grupo
chequear que no existan interdependencias entre ellos.
dependencias deben ser separadas en distintos grupos cuya llave debe ser el campo del cual son
dependientes, dejando este campo llav
Si analizamos el grupo 1, encontramos que los campos PROV
enteramente dependientes del campo PROV
Del grupo 2 ya sacamos las interdependencias durante la segunda forma normal y el grupo tre
precisamente el resultado de esa separacin de la segunda forma normal, por lo
ignoramos en esta etapa. Nos concentramos solo en el grupo 1
Al separar en un grupo la informacin del proveedor, dejando un cuarto grupo con esta
informacin, obtenemos la tercera forma normal, la cual queda de la siguiente manera: en
conclusin, despus de aplicar la segunda forma normal, obtenemos estos grupos

dejamos una tabla separada para CODIGO y TITULO, al ingresar las rdenes solo nos toca digitar 50
tabla del grupo 2 (cada vez asociado a un nmero de orden distinto y
nico) y una sola vez el mismo cdigo en la tabla 3, con lo cual el texto Fjate bien
el evento en que se nos pida consultar el ttulo del CD en un registro
usaremos el valor del campo CODIGO de dicho registro para trasladar la
nos devolver la informacin buscada del Ttulo.
justificacin de la normalizacin con el ejemplo anterior, tenemos ya un
gran terreno ganado en el proceso de aprender a disear bases de datos.

Todos los campos o atributos en cada grupo que no sean llaves, deben ser examinados para
chequear que no existan interdependencias entre ellos. Si se encuentran algunas, tales
dependencias deben ser separadas en distintos grupos cuya llave debe ser el campo del cual son
dependientes, dejando este campo llave tambin en el grupo original.
analizamos el grupo 1, encontramos que los campos PROV-NAME, PROV-DIR y PROV
enteramente dependientes del campo PROV-NO
grupo 2 ya sacamos las interdependencias durante la segunda forma normal y el grupo tre
precisamente el resultado de esa separacin de la segunda forma normal, por lo
concentramos solo en el grupo 1.
separar en un grupo la informacin del proveedor, dejando un cuarto grupo con esta
acin, obtenemos la tercera forma normal, la cual queda de la siguiente manera: en
de aplicar la segunda forma normal, obtenemos estos grupos

dejamos una tabla separada para CODIGO y TITULO, al ingresar las rdenes solo nos toca digitar 50
tabla del grupo 2 (cada vez asociado a un nmero de orden distinto y
Fjate bien solo tendra
os pida consultar el ttulo del CD en un registro
usaremos el valor del campo CODIGO de dicho registro para trasladar la
con el ejemplo anterior, tenemos ya un
llaves, deben ser examinados para
se encuentran algunas, tales
dependencias deben ser separadas en distintos grupos cuya llave debe ser el campo del cual son
DIR y PROV-NIT son
grupo 2 ya sacamos las interdependencias durante la segunda forma normal y el grupo tres es
precisamente el resultado de esa separacin de la segunda forma normal, por lo tanto lo
separar en un grupo la informacin del proveedor, dejando un cuarto grupo con esta
acin, obtenemos la tercera forma normal, la cual queda de la siguiente manera: en

RESUMEN DE LA NORMALIZACIN
UNF FROMA NO NORMALIZADA Diccionario de datos
1NF PRIMERA FORMA NORMAL Separar el grupo repetitivo
2NF SEGUNDA FORMA NORMAL Separar dependencias de llaves compuestas
3NF TERCERA FORMA NORMAL Separar dependencias de los campos no llaves
REGLAS NO ESCRITAS PARA UN BUEN DISEO DE BASE DE DATOS
Mantener los datos bien diferencias (por ejemplo, el primero y el ltimo de los nombres
van separados) Acercar unas columnas a otras posteriormente sobre la marcha es, en
general, bastante fcil pero separarlas no
Primero, definir la clave primaria. Utilizar un nombre descriptivo (EMPLEADO_ID, no slo
ID)
El uso de nombres descriptivos permite que los nuevos usuarios tengan alguna
oportunidad de adivinar lo que es cada una de las columnas (por ejemplo utilizar
CUENTA_BANCO en lugar de CTBC)
Siempre que sea posible, utilizar una sola columna para la clave primaria; las claves
primarias de ms de una columna son adecuadas para las interrelaciones de muchos a
muchos
Utilizar tablas de referencia en lugar de almacenar valores de gran longitud
Emplear claves de tipo numrico siempre que sea posible
Evitar claves auto numricas (salvo en las tablas de referencia)
No incluir dos columnas cuyos valore estn entrelazados (por ejemplo el nombre del
Departamento y el ID de Departamento), salvo que una de las columnas sea la clave
primaria de la tabla
Evitar utilizar varias tablas con estructuras similares para representar pequeas
variaciones de la misma entidad (por ejemplo poner las Universidades de Atlntico y las de
Cundinamarca en distintas tablas)
Plantear con antelacin la transferencia de datos a una base de datos distinta. Por
ejemplo, puede que nos interese mover algunos datos de Oracle a DBF, o de Microsoft
Access a Oracle. Esto es:
o Evitar poner en los nombres de las columnas caracteres que no sean maysculas
(A-Z), nmeros (0-9) o el subrayado (_). Cualquier otro carcter puede no ser
aceptado por la base de datos. Algunos sistemas de bases de datos son sensibles
al uso de maysculas y minsculas en los nombres de las columnas, otros no
o Procurar que los nombres de las columnas sean relativamente cortos. Cada tipo
de base de datos soporta un nmero distinto de caracteres (por ejemplo 30 en el
caso de Oracle, 64 para Microsoft Access o 10 si es DBF y 8 para nuestro WinSQL).
Intentar que los nombres de las columnas varen en los primeros caracteres y no
en los ltimos, con el fin de evitar que se duplique alguno de los nombres por
error al cortarlos para abreviar durante el proceso de conversin (por ejemplo
utilizar COL1 y COL2, en lugar de NOMBRE_COLUMNA_LARGA_1 y
NOMBRE_COLUMNA_LARGA_2)