El proceso de normalización de bases de datos

relacionales
La normalización de bases de datos relacionales toma un esquema relacional y le aplica un
conjunto de técnicas para producir un nuevo esquema que representa la misma información
pero contiene menos redundancias y evita posibles anomalías en las inserciones,
actualizaciones y borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de

acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como un
conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la
relación, que se define por una serie de atributos Ai.

Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de

entidad es una restricción que nos indica que cada entidad representada por una tupla tiene
que ser diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos
valores identifiquen unívocamente las tuplas. La integridad referencial indica que una clave
ajena solo debe contener valores que o bien sean nulos, o bien existan en la relación
referenciada por la clave ajena.

El proceso de normalización

El proceso de normalización consiste en comprobar en secuencia si el esquema original está

en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado,
de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el
siguiente esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

nss nombre puesto salarioemails

111Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es
222José SánchezAdministrativo1500 jsanchez@ecn.es
333Ana Díaz Administrativo1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...
Table 1

Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos
ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición
de 1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la
cual:

• El atributo M que violaba 1FN se elimina.

• Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo
que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K].
En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación
habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores
que había en M.
• La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos,
para los valores multivaluados en M.

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a)

con clave primaria (nss, email):

nss nombre puesto salarioemail

111Juan Pérez Jefe de Área 3000 juanp@ecn.es
111Juan Pérez Jefe de Área 3000 jefe2@ecn.es
222José SánchezAdministrativo1500 jsanchez@ecn.es
333Ana Díaz Administrativo1500 adiaz@ecn.es
333Ana Díaz Administrativo1500 ana32@gmail.com
... ... ... ... ...
Table 2

Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:

sustituir R por una nueva relación modificada R' que no contiene el atributo M.

Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K
referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.

La nueva relación N tiene como clave (K, M').

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss nombre puesto salario

 111Juan Pérez Jefe de Área 3000
222José SánchezAdministrativo1500
333Ana Díaz Administrativo1500
... ... ... ...
Table 3

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

nss email
111juanp@ecn.es
111jefe2@ecn.es
222jsanchez@ecn.es
333adiaz@ecn.es
333ana32@gmail.com
... ...
Table 4

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa
respecto de todas las claves existentes en el esquema. En otras palabras, para determinar
cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más
atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla
EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el
esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de
los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son
las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son
incompletas, por lo que la relación no está en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la
clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos
con dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que
depende, que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen
dependencia incompleta:

nss nombre puesto salario

111Juan Pérez Jefe de Área 3000
222José SánchezAdministrativo1500
333Ana Díaz Administrativo1500
... ... ... ...
Table 5

Y al eliminar de la tabla original estos atributos nos quedaría:

nss email
111juanp@ecn.es
111jefe2@ecn.es
222jsanchez@ecn.es
333adiaz@ecn.es
333ana32@gmail.com
... ...
Table 6

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución
para el problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende

transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales
entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de
dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La
solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos
B, y poner como clave primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

nss nombre puesto

111Juan Pérez Jefe de Área
222José SánchezAdministrativo
333Ana Díaz Administrativo
... ... ...
Table 7

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.

PROCESO DE NORMALIZACIÓN DE UNA

RELACIÓN

En el proceso de normalización, según la propuesta original de

Codd (1972), se somete un esquema de relación a una serie de pruebas
para "certificar” si pertenece o no a una cierta forma normal. En un
principio, Codd propuso tres formas normales, a las cuales llamó
primera, segunda y tercera formas normales (1FN, 2FN, 3FN).
Posteriormente, Boyce y Codd propusieron una definición más estricta
de 3FN, a la que se conoce como forma normal de Boyce-Codd (FNBC).
Todas estas formas normales se basan en las dependencias funcionales
entre los atributos de una relación. Más adelante se propusieron una
cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los
conceptos de dependencias multivaluadas y dependencias de reunión,
respectivamente.

La normalización de los datos puede considerarse como un

proceso durante el cual los esquemas de relación que no cumplen las
condiciones se descomponen repartiendo sus atributos entre esquemas
de relación más pequeños que cumplen las condiciones establecidas. Un
objetivo del proceso de normalización es garantizar que no ocurran
anomalías de actualización.

Las formas normales, consideradas aparte de otros factores, no

garantizan un buen diseño de BD. En general no basta con comprobar
por separado que cada esquema de relación de la BD esté en, digamos,
FNBC o 3FN. Más bien, el proceso de normalización por descomposición
debe confirmar la existencia de propiedades adicionales que los
esquemas relacionales, en conjunto, deben poseer. Dos de estas
propiedades son:

• • La propiedad de reunión sin pérdida, que garantiza que no se

presentará el problema de las tuplas erróneas.

• • La propiedad de conservación de las dependencias, que asegura

que todas las dependencias funcionales estén representadas en
alguna de las relaciones individuales resultantes.

La utilidad práctica de las formas normales queda en entredicho cuando las

restricciones en las que se basan son difíciles de entender o de detectar por parte de los
diseñadores de BD y usuarios que deben descubrir estas restricciones.

Otro punto que merece la pena destacar es que los diseñadores de

BD no tienen que normalizar hasta la forma normal más alta posible. Las
relaciones pueden dejarse en formas normales inferiores por razones de
rendimiento (Ej.: la relación EMP-DEPTO (NOMBRE, NSS, FECHAN,
DIRECCION, NUMEROD, NOMBRED, NSSJEFED) la dejaríamos así, sin
dividir, si por ejemplo una consulta importante obtiene información
relativa -al departamento de un empleado, junto con los atributos del
empleado. Pero hay que tomar nota de sus anomalías y entenderlas
perfectamente de modo que, al actualizar la relación, no se produzcan
inconsistencias).

Primera forma normal (1FN):

“Una relación está en primera forma normal (1FN) si los

valores para cada atributo de la relación son atómicos”.

Esto quiere decir simplemente que cada atributo sólo puede

pertenecer a un dominio (es indivisible) y que tiene un valor único para
cada fila.

La primera forma normal se definió para prohibir los atributos

multivaluados, compuestos y sus combinaciones.

Cuando una relación no está en primera forma normal, se divide

en otras relaciones, repartiendo sus atributos entre las resultantes.
Normalmente la idea es eliminar el atributo que viola la 1ª FN de la
relación original y colocarlo en una relación aparte junto con la clave
primaría de la relación de partida.

Segunda forma normal (2FN):

 “Una relación está en segunda a normal si está en la 1ª FN y
todos los atributos no clave dependen de la clave completa
y no sólo de una parte de esta”.

Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que
están formadas por mas de un atributo. Si un esquema de relación no está en 2ªFN, se le
puede normalizar a varias relaciones en 2ªFN en las que los atributos que dependen de una
parte de la clave formarán una nueva relación que tendrá esa parte de la clave como clave
primaria.

Tercera forma normal (3FN):

"Una relación está en tercera forma normal si todos los

atributos de la relación dependen funcionalmente sólo de la
clave, y no de ningún otro atributo".

Esto significa que en una relación en 3FN, para toda DF: X

Y, X es una clave.

Podemos observar que si una relación está en tercera forma normal, está también en
segunda forma normal, sin embargo lo inverso no siempre es cierto.

Nota : Los conceptos del modelo ER (entidades, relaciones, atributos,

claves y restricciones estructurales) que hemos visto son suficientes
para modelar algunas aplicaciones sencillas de bases de datos, sin
embargo para algunas aplicaciones es necesario utilizar conceptos
adicionales si lo que se quiere es un modelado más exacto.
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.

• Evitar problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla
sea considerada como una relación tiene que cumplir con algunas restricciones:

• Cada columna debe tener su nombre único.

• No puede haber dos filas iguales. No se permiten los duplicados.
• Todos los datos en una columna deben ser del mismo tipo.

Terminología relacional equivalente [editar]

Figura 1.0: Trabajo (Código, Nombre, Posición, Salario), donde Código es la Clave
Primaria

• Relación = tabla o archivo

• Tupla = registro, fila o renglón
• Atributo = columna o campo
• Clave = llave o código de identificación
• Clave Candidata = superclave mínima
• Clave Primaria = clave candidata elegida
• Clave Ajena = clave externa o clave foránea
• Clave Alternativa = clave secundaria
• Dependencia Multivaluada = dependencia multivalor
• RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema
Gestor de Bases de Datos Relacionales.
• 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.

Los términos Relación, Tupla y Atributo derivan de las matemáticas relacionales, que
constituyen la fuente teórica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el
mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto
del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber
algunas diferencias con la analogía matemática, dado que algunos RDBMS permiten filas
duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente
como un elemento del producto cartesiano entre los dominios.

Dependencia [editar]
Dependencia funcional [editar]

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si
conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente
manera:

FechaDeNacimiento Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos

formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de
FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede
ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.

Propiedades de la Dependencia funcional [editar]

Existen 3 axiomas de Armstrong:

Dependencia funcional Reflexiva [editar]

Si "y" esta incluido en "x" entonces x y

Si la dirección o el nombre de una persona están incluidos en el dni, entonces con el dni
podemos determinar la dirección o su nombre.

Dependencia funcional Aumentativa [editar]

entonces
dni nombre

dni,dirección nombre,dirección

Si con el dni se determina el nombre de una persona, entonces con el dni más la dirección
también se determina el nombre o su dirección.

Dependencia funcional transitiva [editar]

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende

funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice que Z
depende transitivamente de X. Simbólicamente sería:

X Y Z entonces X Z

FechaDeNacimiento Edad

Edad Conducir

FechaDeNacimiento Edad Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a

Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En
muchos países , una persona necesita ser mayor de cierta edad para poder conducir un
automóvil, por eso se utiliza este ejemplo).

Propiedades deducidas [editar]

Union [editar]

y entonces

Pseudo-transitiva [editar]

y entonces

Descomposición [editar]

y z está incluido en y entonces

Claves [editar]
Una clave primaria es aquella columna (pueden ser también dos columnas o más) que
identifica únicamente a esa fila. La clave primaria es un identificador que va a ser único
para cada fila. Se acostumbra poner la clave primaria como la primera columna de la tabla
pero esto no tiene que ser necesario, si no es más una conveniencia. Muchas veces la clave
primaria es autonumérica.

En una tabla puede que tengamos más de una clave, en tal caso se puede escoger una para
ser la clave primaria, las demás claves son las claves candidatas.Además es la posible
clave primaria.

Una clave foránea es aquella columna que existiendo como dependiente en una tabla, es a
su vez clave primaria en otra tabla.

Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave
primaria, pero que también puede identificar de forma única a una fila dentro de una tabla.
Ejemplo: Si en un tabla clientes definimos el número de documento (id_cliente) como clave
primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este
caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos
los clientes.

Una clave compuesta es una clave que está compuesta por más de una columna.

Formas Normales [editar]

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) [editar]

Artículo principal: Primera forma normal

Una tabla está en Primera Forma Normal sólo 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 clave primaria.
• La tabla no contiene atributos nulos.
• Si no posee ciclos repetitivos.
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de
X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)

Esta forma normal elimina los valores repetidos dentro de una BD

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.

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 A Є X, (X – {A}) -x-> Y. Una dependencia funcional es
una dependencia parcial si hay algunos atributos que pueden ser removidos de X y
la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y .

Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente dado que ni

SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN,
PNUMBER} ENAME es parcialmente dependiente dado que SSN ENAME mantiene
la dependencia

Tercera Forma Normal (3FN) [editar]

Artículo principal: Tercera forma normal

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna
clave, depende directamente y no transitivamente, de la clave primaria.

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 via 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.

Forma Normal de Boyce-Codd (FNBC) [editar]

Artículo principal: Forma normal de Boyce-Codd

La tabla se encuentra en BCNF si cada determinante, atributo que determina

completamente a otro, es clave candidata.

Cuarta Forma Normal (4FN) [editar]

Artículo principal: Cuarta forma normal

Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no
funcionales X->->Y, siendo X una super-clave que, X es o 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 esta en 4FN

• No existen relaciones de dependencias no triviales que no siguen los criterios de las
claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si,
cada relación de dependencia se encuentra definida por las claves candidatas.

Reglas de Codd [editar]

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, 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 No. 1 - La Regla de la información [editar]

Toda la información en un RDBMS está explícitamente representada de una sola manera

por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información,
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 información constituyen el Diccionario de Datos. Esto significa que todo tiene
que estar almacenado en las 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. Por tanto los metadatos
(diccionario, catálogo) se representan exactamente igual que los datos de usuario. Y puede
usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)

Regla No. 2 - La regla del acceso garantizado [editar]

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine
el nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el
nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta
razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos [editar]

La información inaplicable o faltante puede ser representada a través de valores nulos.

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el
uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o
inaplicables.

Regla No. 4 - La regla de la descripción de la base de datos [editar]

La descripción 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 información 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 través de sentencias de SQL (o similar).

Regla No. 5 - La regla del sub-lenguaje Integral [editar]

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos,
manipulación de datos, definición de vistas, restricciones 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 actualización de vistas [editar]

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema
mismo.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los
intentos de actualizar vistas complejas.
Regla No. 7 - La regla de insertar y actualizar [editar]

La capacidad de manejar una base de datos con operandos simples aplica no sólo para la
recuperación o consulta de datos, sino también para la inserción, actualización y borrado
de datos'.

Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT,
UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables,
independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física [editar]

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación,

debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos
almacenados, o sean cambiados los métodos de acceso a los datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía

terminales debería ser predecible basados en la definición lógica de la base de datos, y éste
comportamiento debería permanecer inalterado, independientemente de los cambios en la
definición física de ésta.

Regla No. 9 - La regla de independencia lógica [editar]

Los programas de aplicación y las actividades de acceso por terminal deben permanecer
lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos
asignados) en las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las
actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los
cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad [editar]

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en
el catalogo, no en el programa de aplicación.

Las reglas de integridad [editar]

1. Ningún componente de una clave primaria puede tener valores en blanco o nulos.
(esta es la norma básica de integridad).
2. Para cada valor de clave foránea deberá existir un valor de clave primaria
concordante. La combinación de estas reglas aseguran que haya Integridad
referencial.

Regla No. 11 - La regla de la distribución [editar]

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté
distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de
aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de
relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos
sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar como
si estuviera disponible como en una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión [editar]

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 subversión (violación) de las restricciones de integridad.
Esto no debe ser permitido.