Normalización
La normalización (también
denominada estandarización) es el proceso de elaborar, aplicar y
mejorar las normas que se aplican a distintas actividades científicas,
industriales o económicas, con el fin de ordenarlas y mejorarlas. Por su parte,
la asociación estadounidense para pruebas de materiales (ASTM), define la
estandarización como el proceso de formular y aplicar reglas, para una
aproximación ordenada a una actividad específica, para el beneficio y con la
cooperación de todos los involucrados.
Según
la ISO (International Organization for
Standarization), la normalización es la actividad que tiene por objeto
establecer, ante problemas reales o potenciales, disposiciones destinadas a
usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo
en un contexto dado, que puede ser tecnológico, político, o económico.
Objetivos
La 'Normalización' persigue
fundamentalmente tres objetivos:
·
Simplificación:
se trata de reducir el número de modelos y de normas, para quedarse únicamente
con los más necesarios.
·
Unificación:
se trata de permitir los intercambios y las comparaciones a nivel
internacional.
·
Especificación:
se persigue evitar errores de identificación, creando un lenguaje claro y
preciso.
Las elevadas sumas de dinero
que los países desarrollados invierten en los organismos normalizadores, tanto
nacionales como internacionales, es un indicio o una prueba de la importancia
que se da a esta cuestión.
Normalización
de bases de datos
La normalización
de bases de datos es un proceso que consiste en designar y 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.
·
Disminuir problemas de
actualización de los datos en las tablas.
·
Proteger la integridad de datos.
En el modelo
relacional es frecuente llamar tabla a
una relación, para que una tabla sea considerada como una relación tiene que
cumplir con algunas restricciones:
·
Cada tabla 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.
Fundamentos de la
normalización
La normalización es
el proceso de organizar los datos de una base de datos. Se incluye la creación
de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas
tanto para proteger los datos como para hacer que la base de datos sea más
flexible al eliminar la redundancia y las dependencias incoherentes.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal". Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
En las descripciones siguientes se incluyen ejemplos.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una "forma normal". Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal". Si se cumplen las tres primeras reglas, la base de datos se considera que está en la "tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
En las descripciones siguientes se incluyen ejemplos.
Primera forma normal
·
Elimine los grupos repetidos de las tablas individuales.
·
Cree una tabla independiente para cada conjunto de datos
relacionados.
·
Identifique cada conjunto de datos relacionados con una clave
principal.
No use varios campos en una sola tabla para almacenar datos
similares. Por ejemplo, para realizar el seguimiento de un elemento del
inventario que proviene de dos orígenes posibles, un registro del inventario
puede contener campos para el Código de proveedor 1 y para el Código de
proveedor 2.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
Segunda forma normal
·
Cree tablas independientes para conjuntos de valores que se
apliquen a varios registros.
·
Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea una clave
principal de una tabla, una clave compuesta si es necesario. Por ejemplo,
considere la dirección de un cliente en un sistema de contabilidad. La
dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos,
Envíos, Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la
dirección de un cliente como una entrada independiente en cada una de estas
tablas, almacénela en un lugar, ya sea en la tabla Clientes o en una tabla
Direcciones independiente.
Tercera forma normal
·
Elimine los campos que no dependan de la clave.
Los valores de un registro que no sean parte de la clave de
ese registro no pertenecen a la tabla. En general, siempre que el contenido de
un grupo de campos pueda aplicarse a más de un único registro de la tabla,
considere colocar estos campos en una tabla independiente.
Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
Otras formas de normalización
La cuarta forma normal, también llamada Forma normal de Boyce
Codd (BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero
rara vez se consideran en un diseño real. Si no se aplican estas reglas, el
diseño de la base de datos puede ser menos perfecto, pero no debería afectar a
la funcionalidad.
Normalización de una tabla de ejemplo
Estos pasos
demuestran el proceso de normalización de una tabla de alumnos ficticia.
1.
Tabla sin normalizar:
Nº
alumno
|
Tutor
|
Despacho-Tut
|
Clase1
|
Clase2
|
Clase3
|
1022
|
García
|
412
|
101-07
|
143-01
|
159-02
|
4123
|
Díaz
|
216
|
201-01
|
211-02
|
214-01
|
2.
Primera forma normal: no hay grupos repetidos
Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
Nº
alumno
|
Tutor
|
Despacho-Tut
|
Nº clase
|
1022
|
García
|
412
|
101-07
|
1022
|
García
|
412
|
143-01
|
1022
|
García
|
412
|
159-02
|
4123
|
Díaz
|
216
|
201-01
|
4123
|
Díaz
|
216
|
211-02
|
4123
|
Díaz
|
216
|
214-01
|
3.
Segunda forma normal: eliminar los datos redundantes
Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.
Las dos tablas siguientes demuestran la segunda forma normal:
Alumnos:
Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.
Las dos tablas siguientes demuestran la segunda forma normal:
Alumnos:
Nº
alumno
|
Tutor
|
Despacho-Tut
|
1022
|
García
|
412
|
4123
|
Díaz
|
216
|
4.
Registro:
Registro:
Nº
alumno
|
Nº clase
|
1022
|
101-07
|
1022
|
143-01
|
1022
|
159-02
|
4123
|
201-01
|
4123
|
211-02
|
4123
|
214-01
|
5.
Tercera forma normal: eliminar los datos no dependientes de la
clave
En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:
Alumnos:
En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:
Alumnos:
Nº
alumno
|
Tutor
|
1022
|
García
|
4123
|
Díaz
|
6.
Personal:
Personal:
Nombre
|
Habitación
|
Dept
|
García
|
412
|
42
|
Díaz
|
216
|
42
|
Georreferenciación
La georreferenciación1 es la técnica de posicionamiento espacial
de una entidad en una localización geográfica única y bien definida en un sistema de coordenadas y datum específicos.
Es una operación habitual dentro de los sistema
de información geográfica (SIG) tanto para objetos ráster
(imágenes de mapa de píxeles) como para objetos vectoriales (puntos, líneas,
polilíneas y polígonos que representan objetos físicos).
La georreferenciación es un aspecto
fundamental en el análisis de datos geoespaciales, pues es la base para la
correcta localización de la información de mapa y, por ende, de la adecuada
fusión y comparación de datos procedentes de diferentes sensores en diferentes
localizaciones espaciales y temporales. Por ejemplo, dos entidades
georreferenciadas en sistemas de coordenadas diferentes pueden ser combinables
tras una apropiada transformación afín (bien al sistema de coordenadas del
primer objeto, bien al del segundo).
Referencias:
https://es.wikipedia.org/wiki/
https://es.wikipedia.org/wiki/
https://support.microsoft.com/
https://es.wikipedia.org/wiki/
Referencias:
https://es.wikipedia.org/wiki/
https://es.wikipedia.org/wiki/
https://support.microsoft.com/
https://es.wikipedia.org/wiki/
No hay comentarios.:
Publicar un comentario