Taller Base de datos.

Taller Base de datos
a. Primera forma normal
La primera forma normal (1FN o forma mínima) es una forma normal usada
en normalización de bases de datos. Una tabla de base de datos relacional que se
adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos
criterios se refieren básicamente a asegurarse que la tabla es una representación
fiel de una relación1 y está libre de "grupos repetitivos".2
Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras
por diferentes teóricos. Como consecuencia, no hay un acuerdo universal en
cuanto a qué características descalificarían a una tabla de estar en 1FN. Muy
notablemente, la 1FN, tal y como es definida por algunos autores excluye
"atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente
establecido por E.F. Codd) (algunos de esos autores son: Ramez Elmasri y
Shamkant B. Navathe3 ). Por otro lado, según lo definido por otros autores, la 1FN
sí los permite (por ejemplo como la define Chris Date).
Segunda forma normal
La segunda forma normal (2NF) es una forma normal usada en normalización de
bases de datos. La 2NF fue definida originalmente por E.F. Codd1 en 1971. Una
tabla que está en la primera forma normal (1NF) debe satisfacer criterios
adicionales para calificar para la segunda forma normal. Específicamente: una
tabla 1NF está en 2NF si y solo si, dada una clave primaria y cualquier atributo
que no sea un constituyente de la clave primaria, el atributo no clave depende de
toda la clave primaria en vez de solo una parte de ella.
En términos levemente más formales: una tabla 1NF está en 2NF si y solo si
ninguno de sus atributos no-principales son funcionalmente dependientes en una
parte (subconjunto propio) de una clave primaria (Un atributo no-principal es uno
que no pertenece a ninguna clave primaria).
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta
(claves candidatas consistiendo en más de un atributo), la tabla está
automáticamente en 2NF.
Tercera forma normal
La tercera forma normal (3NF) es una forma normal usada en la normalización
de bases de datos. La 3NF fue definida originalmente por E.F. Codd1 en 1971. La
definición de Codd indica que una tabla está en 3NF si y solo si las dos
condiciones siguientes se mantienen:

La tabla está en la segunda forma normal (2NF)

Ningún atributo no-primario de la tabla es dependiente transitivamente de
una clave primaria
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata.
Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no
es inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y,
que a su vez depende de X. Es decir, X → Z por virtud de X → Y e Y → Z.
Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo 2 en
1982, es ésta: Una tabla está en 3NF si y solo si, para cada una de sus
dependencias funcionalesX → A, por lo menos una de las condiciones siguientes
se mantiene:

X contiene A, ó

X es una superclave, ó

A es un atributo primario (es decir, A está contenido dentro de una clave
candidata)
La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia
entre la 3NF y la más rigurosa forma normal de Boyce-Codd (BCNF). La BCNF
simplemente elimina la tercera alternativa ("A es un atributo primario").
Forma normal de Boyce-Codd
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en
la normalización de bases de datos. Es una versión ligeramente más fuerte de
la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no
existan dependencias funcionales no triviales de los atributos que no sean un
conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen
de una clave, de la clave completa y de ninguna otra cosa excepto de la clave
(excluyendo dependencias triviales, como
). Se dice que una tabla está
en FNBC si y solo si está en 3FN y cada dependencia funcional no trivial tiene una
clave candidata como determinante. En terminos menos formales, una tabla está
en FNBC si está en 3FN y los únicos determinantes son claves candidatas.
Cuarta forma normal
La cuarta forma normal (4NF) es una forma normal usada en la normalización de
bases de datos. La 4NF se asegura de que las dependencias multivaluadas
independientes estén correcta y eficientemente representadas en un diseño de
base de datos. La 4NF es el siguiente nivel de normalización después de la forma
normal de Boyce-Codd (BCNF).
Quinta forma normal
(Redirigido desde 5NF)
La quinta forma normal (5FN), también conocida como forma normal de
proyección-unión (PJ/NF), es un nivel de normalización de bases de
datos designado para reducir redundancia en las bases de datos relacionales que
guardan hechos multi-valores aislando semánticamente relaciones múltiples
relacionadas. Una tabla se dice que está en 5NFsi y sólo si está en 4NF y cada
dependencia de unión (join) en ella es implicada por las claves candidatas.
Forma normal de dominio/clave
La forma normal de dominio/clave (DKNF) es una forma normal usada
en normalización de bases de datos que requiere que la base de datos contenga
restricciones de dominios y de claves.
Una restricción del dominio especifica los valores permitidos para un atributo dado,
mientras que una restricción clave especifica los atributos que identifican
únicamente una fila en una tabla dada.
Esta es el santo grial de la Base de datos y es alcanzado cuando cada restricción
en la relación es una consecuencia lógica de la definición de claves y dominios, y,
haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa
que sean satisfechas todas las restricciones. Así, esto evita todas las anomalías
no-temporales.
Es mucho más fácil construir una base de datos en forma normal de dominio/clave
que convertir pequeñas bases de datos que puedan contener numerosas
anomalías. Sin embargo, construir con éxito una base de datos en forma normal
de dominio/clave sigue siendo una tarea difícil, incluso para programadores
experimentados de bases de datos. Así, mientras que la forma normal de
dominio/clave elimina los problemas encontrados en la mayoría de las bases de
datos, tiende para ser la forma normal más costosa de alcanzar. Sin embargo, el
no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a
largo plazo, debido a anomalías que aparecen con el tiempo en las bases de datos
que solamente se adhieren a formas normales más bajas.
Una violación de DKNF ocurre en la siguiente tabla:
Persona rica
Persona rica
Tipo de persona rica
Valor neto en dólares
Steve
Millonario excéntrico
124,543,621
Roderick
Multimillonario malvado
6,553,228,893
Katrina
Multimillonario excéntrico 8,829,462,998
Gary
Millonario malvado
495,565,211
Asuma que el dominio para la 'Persona rica consiste en los nombres de toda la
gente rica en una muestra predefinida de gente rica; el dominio para el Tipo de
persona ricaconsiste de los valores 'Millonario excéntrico', 'Multimillonario
excéntrico', 'Millonario malvado', y 'Multimillonario malvado'; y el dominio para
el Valor neto en dólares consiste de todos los números enteros mayor que o
igual a 1.000.000.
Hay una restricción que liga el Tipo de persona rica al Valor neto en dólares,
incluso aunque no podemos deducir uno del otro. La restricción dicta que
un Millonario excéntrico oMillonario malvado tendrá un valor neto de 1.000.000
a 999.999.999 inclusive, mientras que un Multimillonario excéntrico o
un Multimillonario malvado tendrá un valor neto de 1.000.000.000 o más. Esta
restricción no es ni una restricción de dominio ni una restricción de clave; por lo
tanto no podemos confiar en las restrcciones de dominio y las de clave para
garantizar que una combinación de anómala de Tipo de persona rica / Valor
neto en dólares no tenga cabida en la base de datos.
La violación de la DKNF podría ser eliminada alterando dominio Tipo de
persona rica para hacer que sea consistente con solo dos valores, 'Malvado' y
'Excéntrico' (el estatus de persona rica como un millonario o un multimillonario
es implícito en su Valor neto en dólares, así que no se pierde ninguna
información útil).
DKNF es frecuentemente difícil de alcanzar en la práctica.
b. La integración de datos se centra en la información, no en los archivos. En
realidad, la integración de datos es una disciplina complicada. No hay un enfoque
estándar a esta tecnología y muchos de los expertos en información tecnológica
todavía están evolucionando con ello. Algunas técnicas para usar este sistema
pueden funcionar mejor que otros para una organización, dependiendo de lo que
necesite la organización. Para comprender esto, lo mejor es ver algunas
estrategias utilizadas por los profesionales para integrar varias fuentes de datos y
entrar en el mundo de la gestión de las bases de datos.
c. Clave primaria
En el diseño de bases de datos relacionales, se llama clave primaria a un campo
o a una combinación de campos que identifica de forma única a cada fila de
una tabla. Una clave primaria comprende de esta manera una columna o conjunto
de columnas. No pueden haber dos filas en una tabla que tengan la misma clave
primaria.
Una clave primaria debe identificar unívocamente a todas las posibles filas de una
tabla y no solo a las filas que se encuentran en un momento determinado.
Ejemplos de claves primarias son DNI (asociado a una persona) o ISBN (asociado
a un libro). Las guias telefónicas y diccionarios no pueden usar nombres o
palabras o números del sistema decimal de Dewey como claves candidatas,
porque no identifican unívocamente números de teléfono o palabras.
Una clave primaria es un caso especial de clave única. La mayor diferencia es
que para claves únicas, no se impone automáticamente la restricción
implícita NOT NULL, mientras que para claves primarias, sí. Así, los valores en
columnas de clave única pueden o no ser NULL. Otra diferencia es que las claves
primarias deben definirse por medio de otra sintaxis.
El modelo relacional, según se lo expresa mediante cálculo relacional y álgebra
relacional, no distingue entre clave primaria y otros tipos de claves. Las claves
primarias fueron agregadas al estándar SQL principalmente para conveniencia del
programador.
Tanto claves únicas como claves primarias pueden referenciarse con claves
foráneas.
d. Primera Forma Normal (1FN)
Artículo principal: Primera forma normal.
Una tabla está en Primera Forma Normal si:








Todos los atributos son atómicos. Un atributo es atómico si los elementos del
dominio son indivisibles, mínimos.
La tabla contiene una llave primaria única.
La llave primaria no contiene atributos nulos.
No debe existir variación en el número de columnas.
Los Campos no llave deben identificarse por la llave (Dependencia Funcional)
Debe Existir una independencia del orden tanto de las filas como de las
columnas, es decir, si los datos cambian de orden no deben cambiar sus
significados
Una tabla no puede tener múltiples valores en cada columna.
Los datos son atómicos (a cada valor de X le pertenece un valor de Y y
viceversa).
Esta forma normal elimina los valores repetidos dentro de una BD
e. Clave foránea
En el contexto de bases de datos relacionales, una clave foránea o clave
ajena (o Foreign Key FK) es una limitación referencial entre dos tablas. La clave
foránea identifica unacolumna o grupo de columnas en una tabla (tabla hija o
referendo) que se refiere a una columna o grupo de columnas en otra tabla (tabla
maestra o referenciada). Las columnas en la tabla referendo deben ser la clave
primaria u otra clave candidata en la tabla referenciada.
Los valores en una fila de las columnas referendo deben existir solo en una fila en
la tabla referenciada. Así, una fila en la tabla referendo no puede contener valores
que no existen en la tabla referenciada. De esta forma, las referencias pueden ser
creadas para vincular o relacionar información. Esto es una parte esencial de la
normalización de base de datos. Múltiples filas en la tabla referendo pueden hacer
referencia, vincularse o relacionarse a la misma fila en la tabla referenciada.
Mayormente esto se ve reflejado en una relación uno (tabla maestra o
referenciada) a muchos (tabla hija o referendo).
La tabla referendo y la tabla referenciada pueden ser la misma, esto es, la clave
foránea remite o hace referencia a la misma tabla. Esta clave externa es conocida
en SQL:2003 como auto-referencia o clave foránea recursiva. Una tabla puede
tener múltiples claves foráneas y cada una puede tener diferentes tablas
referenciadas. Cada clave foránea es forzada independientemente por el sistema
de base de datos. Por tanto, las relaciones en cascada entre tablas pueden
realizarse usando claves foráneas. Configuraciones impropias de las claves
foráneas o primarias o no forzar esas relaciones son frecuentemente la fuente de
muchos problemas para la base de datos o para el modelamiento de los mismos.
Por ejemplo, digamos que hay dos tablas, una tabla CONSUMIDOR que incluye
todos los datos de los consumidores, y otra que es la tabla de ORDENES. La
intención es que todas las órdenes estén asociadas a la información del
consumidor y que viven en su propia tabla. Para lograr esto debemos colocar una
clave foránea en la tabla ORDENES con relación a la llave primaria de la tabla
CONSUMIDOR.
La clave foránea identifica una columna(s) en una TABLA REFERENCIANTE a
una columna(s) en la TABLA REFERENCIADA.
f. Segunda Forma Normal (2FN)
Artículo principal: Segunda forma normal.
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los
atributos que no forman parte de ninguna clave dependen de forma completa de la
clave principal. Es decir que no existen dependencias parciales. (Todos los
atributos que no son clave principal deben depender únicamente de la clave
principal).
En otras palabras podríamos decir que la segunda forma normal está basada en el
concepto de dependencia completamente funcional. Una dependencia
funcional
es completamente funcional si al eliminar los atributos A de X
significa que la dependencia no es mantenida, esto es
que
. Una dependencia funcional
es una
dependencia parcial si hay algunos atributos
que pueden ser eliminados
de X y la dependencia todavía se mantiene, esto es
.
Por ejemplo {DNI, ID_PROYECTO}
HORAS_TRABAJO (con el DNI de un
empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana
trabaja un empleado en dicho proyecto) es completamente dependiente dado que
ni DNI
HORAS_TRABAJO ni ID_PROYECTO
HORAS_TRABAJO
mantienen la dependencia. Sin embargo {DNI,
ID_PROYECTO}
NOMBRE_EMPLEADO es parcialmente dependiente dado
que DNI
NOMBRE_EMPLEADO mantiene la dependencia.
g. Tercera Forma Normal (3FN)
Artículo principal: Tercera forma normal.
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia
funcional transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un
esquema de relación R es una dependencia transitiva si hay un conjunto de
atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X>Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en
EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el
atributo clave SSN es transitiva vía DNUMBER porque las dependencias
SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es
un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la
dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado
que DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relacion
está en 3 Forma Normal Elmasri2
Navathe, si para toda dependencia funcional
, se cumple al menos una
de las siguientes condiciones:
1.
2.
es superllave o clave.
es atributo primo de ; esto es, si es miembro de alguna clave en
Además el esquema debe cumplir necesariamente, con las condiciones de
segunda forma normal.
.