Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

La Forma Normal de Boyce

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 4

-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 términos menos formales, una tabla está en FNBC si está en 3FN y los únicos
determinantes son claves candidatas.

La única clave candidata es IDTrabajador (que será por tanto la clave primaria).

Si añadimos la limitación de que el responsable sólo puede serlo de un departamento, este


detalle produce una dependencia funcional ya que: Responsable ? Departamento

Por lo tanto, hemos encontrado un determinante (IDResponsable) que sin embargo no es clave
candidata. Por ello, esta tabla no está en FNBC. En este caso la redundancia ocurre por mala
selección de clave. La repetición del par [IDDepartamento + IDResponsable] es innecesaria y
evitable.

Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la FNBC. Un
ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener más de un
tutor):

Otro ejemplo a observar es la tabla tutor- estudiante la cual tendremos como referencia la
siguiente:

El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las claves
candidatas de la tabla son: {ID Tutor, ID Estudiante}, {Número de seguro social del tutor, ID
Estudiante}
-La cuarta forma normal (4FN) es una forma normal usada en la normalización de bases de
datos. La 4FN se asegura de que las dependencias multivaluadas independientes estén
correctas y eficientemente representadas en un diseño de base de datos.

Sea R un esquema de relación. La dependencia multivaluada X ->> Y vale en R si los pares de


tuplas t1 y t2 en R, tal que t1[X] = t2[X] existen las tuplas t3 y t4 en R tales que:

En otras palabras se puede decir que: X ->> Y si dado un valor de X, hay un conjunto de valores
de Y asociados y este conjunto de valores de Y NO está relacionado (ni funcional ni
multifuncionalmente) con los valores de R - X -Y (donde R es el esquema), es decir Y es
independiente de los atributos de R-X-Y. (Cátedra de Base de Datos 1, 2009) Una dependencia
multivaluada de la forma X->> Y, es trivial cuando el conjunto de atributos {X,Y} conforma el
total de los atributos del esquema.

-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 diseñado para reducir redundancia en
las bases de datos relacionales que guardan hechos multi-valores aislando semánticamente
relaciones múltiples relacionadas.

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la


condición dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla
que restrinja las combinaciones válidas posibles de psiquiatra, asegurador, y condición, la tabla
de tres atributos Psiquiatra-para-Asegurador-para-Condición es necesaria para modelar la
situación correctamente.

-Las 12 reglas de Codd son un sistema de reglas (numeradas del 0 al 12) propuestas por Edgar
F. Codd, del modelo relacional para las bases de datos, diseñado para definir qué requiere un
sistema de administración de base de datos.

Codd se percató de que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en tablas, sin estar estas
tablas literalmente normalizadas; entonces publicó 13 reglas que un verdadero sistema
relacional debería cumplir, aunque en la práctica algunas de ellas son difíciles de realizar. Un
sistema podrá considerarse "más relacional" cuanto más siga estas reglas.

Regla 0: Regla de fundación. Cualquier sistema que se proclame como relacional, debe ser
capaz de gestionar sus bases de datos enteramente mediante sus capacidades relacionales.

Regla 1: Regla de la información. Toda la información en la base de datos es representada


unidireccionalmente por valores en posiciones de las columnas dentro de filas de tablas. Toda
la información en una base de datos relacional se representa explícitamente en el nivel Lógico
exactamente de una manera: con valores en tablas.

Regla 2: Regla del acceso garantizado. Todos los datos deben ser accesibles sin ambigüedad.
Esta regla es esencialmente una nueva exposición del requisito fundamental para las llaves
primarias. Dice que cada valor escalar individual en la base de datos debe ser lógicamente
direccionable especificando el nombre de la tabla, la columna que lo contiene y la llave
primaria.

Regla 3: Regla del tratamiento sistemático de valores nulos. El sistema de gestión de base de
datos debe permitir que haya campos nulos. Debe tener una representación de la
"información que falta y de la información inaplicable" que sea sistemática y distinta de todos
los valores regulares.
Regla 4: Catálogo dinámico en línea basado en el modelo relacional. El sistema debe soportar
un catálogo en línea, el catálogo relacional, que da acceso a la estructura de la base de datos y
que debe ser accesible a los usuarios autorizados.

Regla 5: Regla comprensiva del sublenguaje de los datos. El sistema debe soportar por lo
menos un lenguaje relacional que:

Tenga una sintaxis lineal.

Puede ser utilizado de manera interactiva.

Tenga soporte de operaciones de definición de datos, operaciones de manipulación de datos


(actualización así como la recuperación), de control de la seguridad e integridad y operaciones
de administración de transacciones.

Regla 6: Regla de actualización de vistas. Todas las vistas que son teóricamente actualizables
deben poder ser actualizadas por el sistema.

Regla 7: Alto nivel de inserción, actualización y borrado. El sistema debe permitir la


manipulación de alto nivel en los datos, es decir, sobre conjuntos de tuplas. Esto significa que
los datos no solo se pueden recuperar de una base de datos relacional a partir de filas
múltiples y/o de tablas múltiples, sino que también pueden realizarse inserciones,
actualización y borrados sobre varias tuplas y/o tablas al mismo tiempo y no solo sobre
registros individuales.

Regla 8: Independencia física de los datos. Los programas de aplicación y actividades del
terminal permanecen inalterados a nivel lógico aunque realicen cambios en las
representaciones de almacenamiento o métodos de acceso.

Regla 9: Independencia lógicas de los datos. Los programas de aplicación y actividades del
terminal permanecen inalterados a nivel lógico aunque se realicen cambios a las tablas base
que preserven la información. La independencia de datos lógica es más difícil de lograr que la
independencia física de datos.

Regla 10: Independencia de la integridad. Las restricciones de integridad se deben especificar


por separado de los programas de aplicación y almacenarse en la base de datos. Debe ser
posible cambiar esas restricciones sin afectar innecesariamente a las aplicaciones existentes.

Regla 11: Independencia de la distribución. La distribución de porciones de base de datos en


distintas localizaciones debe ser invisible a los usuarios de la base de datos. Los usos existentes
deben continuar funcionando con éxito:

cuando una versión distribuida del SGBD se carga por primera vez

cuando los datos existentes se redistribuyen en el sistema.

Regla 12: La regla de la no subversión. Si el sistema proporciona una interfaz de bajo nivel de
registro, aparte de una interfaz relacional, esa interfaz de bajo nivel no debe permitir su
utilización para subvertir el sistema. Por ejemplo para sortear las reglas de seguridad relacional
o las restricciones de integridad. Esto es debido a que a algunos sistemas no relacionales
previamente existentes se les añadió una interfaz relacional pero, al mantener la interfaz
nativa, seguía existiendo la posibilidad de trabajar no relacionalmente.

También podría gustarte