12 reglas de Codd

Las 12 reglas de Codd son un sistema de reglas 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.[1]
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 las tablas, sin
estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un
verdadero sistema relacional debería tener 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.
Reglas
 Regla 0: el sistema debe ser relacional, base de datos y administrador de sistema. Ese
sistema debe utilizar sus facilidades relacionales (exclusivamente) para manejar la
base de datos.
 Regla 1: la 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: la 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: 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 es sistemática, distinto 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 debe ser accesible a los usuarios
autorizados. Es decir, los usuarios deben poder tener acceso a la estructura de la base
de datos (catálogo).
 Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe soportar
por lo menos un lenguaje relacional que;
1. Tenga una sintaxis lineal.
2. Puede ser utilizado recíprocamente y dentro de programas de uso.
3. Soporte operaciones de definición de datos, operaciones de manipulación de datos
(actualización así como la recuperación), seguridad e integridad y operaciones
de administración de transacciones.
 Regla 6: regla de actualización, todas las vistas que son teóricamente actualizables
deben ser actualizables por el sistema.
 Regla 7: alto nivel de inserción, actualización, y cancelación, el sistema debe soportar
suministrar datos en el mismo tiempo que se inserte, actualiza o esté borrando. Esto
significa que los datos se pueden recuperar de una base de datos relacional en los
sistemas construidos de datos de filas múltiples y/o de tablas múltiples.
 Regla 8: independencia física de los datos, los programas de aplicación y actividades
del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen
cambios en las representaciones de almacenamiento o métodos de acceso.
  Regla 9: independencia lógica de los datos, los cambios al nivel lógico (tablas,
columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la
estructura. 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 limitaciones de la integridad se deben
especificar por separado de los programas de la aplicación y se almacenan en la base
de datos. Debe ser posible cambiar esas limitaciones sin afectar innecesariamente las
aplicaciones existentes.
 Regla 11: independencia de la distribución, la distribución de las porciones de la base
de datos a las varias localizaciones debe ser invisible a los usuarios de la base de
datos. Los usos existentes deben continuar funcionando con éxito:
1. cuando una versión distribuida del SGBD se introdujo por primera vez
2. cuando se distribuyen los datos existentes se redistribuyen en todo el sistema.
 Regla 12: la regla de la no subversión, si el sistema proporciona una interfaz de bajo
nivel de registro, a parte de una interfaz relacional, que esa interfaz de bajo nivel no se
pueda utilizar para subvertir el sistema, por ejemplo: sin pasar por seguridad relacional
o limitación de integridad. Esto es debido a que existen sistemas anteriormente no
relacionales que añadieron una interfaz relacional, pero con la interfaz nativa existe la
posibilidad de trabajar no relacionalmente.
https://esacademic.com/dic.nsf/eswiki/4866

Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de
datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la
mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar
F. Codd.[1]

Primera Forma Normal (1FN)

Artículo principal: Primera forma normal

Una tabla está en primera forma si.

Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples
e indivisibles.

No debe existir variación en el número de columnas.

Los campos no clave deben identificarse por la clave (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.

Esta forma normal elimina los valores repetidos dentro de una base de datos.
Segunda Forma Normal (2FN) Editar

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 {\displaystyle x\rightarrow
y}{\displaystyle x\rightarrow y} es completamente funcional si al eliminar los atributos A de X
significa que la dependencia no es mantenida, esto es que {\displaystyle A\in X,X-
\{A\}\nrightarrow Y}{\displaystyle A\in X,X-\{A\}\nrightarrow Y}. Una dependencia funcional
{\displaystyle x\rightarrow y}{\displaystyle x\rightarrow y} es una dependencia parcial si hay
algunos atributos {\displaystyle A\in X}{\displaystyle A\in X} que pueden ser eliminados de X y la
dependencia todavía se mantiene, esto es {\displaystyle A\in X,X-\{A\}\rightarrow Y}{\displaystyle
A\in X,X-\{A\}\rightarrow Y}.

Por ejemplo {DNI, ID_PROYECTO} {\displaystyle \rightarrow }\rightarrow 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 funcional dado que ni DNI {\displaystyle
\rightarrow }\rightarrow HORAS_TRABAJO ni ID_PROYECTO {\displaystyle \rightarrow
}\rightarrow HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO}
{\displaystyle \rightarrow }\rightarrow NOMBRE_EMPLEADO es parcialmente dependiente dado
que DNI {\displaystyle \rightarrow }\rightarrow NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN) Editar

Artículo principal: Tercera forma normal

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva en

los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X {\displaystyle \rightarrow
}\rightarrow 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 {\displaystyle
\rightarrow }\rightarrow Z y Z {\displaystyle \rightarrow }\rightarrow Y.
Por ejemplo, la dependencia SSN {\displaystyle \rightarrow }\rightarrow 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 relación {\displaystyle R}R está en 3 Forma Normal Elmasri-

Navâthe,[2] si para toda dependencia funcional {\displaystyle X\rightarrow A}{\displaystyle
X\rightarrow A}, se cumple al menos una de las siguientes condiciones:

{\displaystyle X}X es superllave o clave.

{\displaystyle A}A es atributo primo de {\displaystyle R}R; esto es, si es miembro de alguna clave
en {\displaystyle R}R.

Además el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Cuarta Forma Normal (4FN) Editar

Artículo principal: Cuarta forma normal

Una tabla se encuentra en 4FN si, y solo si, para cada una de sus dependencias multivaluadas no
funcionales X {\displaystyle \rightarrow }\rightarrow Y, siendo X una super-clave que, X es una
clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN) Editar

Artículo principal: Quinta forma normal

Una tabla se encuentra en 5FN si:

La tabla está en 4FN

No existen relaciones de dependencias de reunión (join) no triviales que no se generen desde las
claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación
de dependencia de reunión (join) se encuentra definida por claves candidatas. Por lo que si se
aplicara una consulta entre al menos tres relaciones independientes entre sí dentro de la 4FN y se
obtuvieran tuplas espurias, entonces no estaría dentro de la 5FN.

https://es.m.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos