Los formularios normales no son solo para bases de datos

También puede aplicar reglas similares a los tipos de objetos de datos.

Probablemente haya aprendido el término Forma normal en el contexto de la definición de esquemas para bases de datos relacionales. La normalización de la base de datos se esfuerza por reducir la redundancia de datos en filas y columnas de tablas. En consecuencia, es menos probable que se produzcan anomalías en los datos.

¿Qué es una anomalía de datos?

Supongamos que tuviéramos esta situación:

La Tabla A contiene valores para las propiedades X, Y, Z para una fila identificada por el id de x ; estas son afirmaciones sobre x. Digamos que se afirma que Y en la fila x es el valor 3.

La tabla B también contiene las mismas afirmaciones sobre por qué Y para x

La Tabla A se dice más tarde, “Los hechos han cambiado. Y ahora mide 4 "

Posteriormente se consulta la Tabla B y se dice que Y sigue siendo 3.

Ahora A y B afirman dos hechos diferentes sobre Y, dependiendo de la tabla que consulte.

Esa es una anomalía de datos: dos afirmaciones diferentes sobre un hecho. Y los hechos sí importan en los sistemas informáticos.

El qué y el por qué de las formas normales

Usaré el término tipo para denotar los metadatos de un objeto. Esto podría implementarse mediante una definición de clase, combinación, rasgo, sello o cualquier mecanismo que admita su preferencia y el idioma de elección. También me centraré en objetos de datos , como POJO, PODO, JSON y objetos simples similares.

Expresado informalmente, las tres primeras formas normales se describen a continuación:

Primera forma normal (1NF): sin elementos repetidos o grupos de elementos

Segunda forma normal (2NF): todos los atributos no clave dependen de todos los atributos clave

Tercera forma normal (3NF): sin dependencias de atributos no clave

Esa es una lectura bastante seca. Pero aplicar estos principios a las definiciones de tipos de objetos es bastante intuitivo. Una vez que haya internalizado estas reglas, ni siquiera volverá a pensar en ellas conscientemente.

Los objetos también son relacionales

Las bases de datos relacionales admiten asociaciones mediante restricciones de clave primaria y externa. Las jerarquías están implícitas, si es que existen. Las asociaciones son más flexibles que las jerarquías y las taxonomías, pero también es más difícil pensar en ellas.

En una jerarquía, tiene relaciones entre padres e hijos. A menudo también existe una jerarquía de tipos de datos (clase-subclase) que también se modela. Las relaciones en una jerarquía de contención de objetos son más restringidas, generalmente unidireccionales (de padre a hijo), pero también más fáciles de comprender que una asociación más general (y flexible).

1NF: Sin elementos repetidos o grupos de elementos

Digamos que tenemos la siguiente información de contacto:

¿Dónde están los elementos repetidos?

  1. Atributos de nombre: esto podría considerarse una relación de uno a muchos, donde el número de nombres es indeterminado (como la realeza británica). Sin embargo, en la práctica, el nombre, el apellido y posiblemente el segundo nombre son suficientes para la mayoría de los dominios de aplicación, por lo que no existe una necesidad real de normalizar estos campos.
  2. teléfonos: la repetición de los atributos del teléfono parece un problema potencial: ¿dos teléfonos son suficientes? ¿Y si luego se asocia más información con el número de teléfono, como el tiempo disponible?
  3. líneas de dirección: de nuevo, ¿son suficientes dos? En algunos países, las direcciones postales pueden tener cuatro líneas, pero ese es el límite. Dado que son cadenas simples, no es una tragedia si una o dos líneas de dirección más se agregan más tarde.

Aquí hay un modelo posible, con tipos de contacto y teléfono:

2NF: todos los atributos no clave dependen de todos los atributos clave

¿Qué significa esto en inglés sencillo? En una base de datos, significa que todas las columnas de una fila deben depender directamente de cualquier clave candidata de esa fila.

Así que echemos un vistazo a Contact nuevamente:

Aquí la clave es un valor de identificación generado, a veces denominado clave sustituta. ¿Los atributos de la dirección dependen del ID de contacto? Bien…

Todo depende del dominio.

Las seis propiedades de la dirección seguramente no son atributos del Contacto, sino más bien un medio para identificar una ubicación física. Es posible que un contacto tenga muchas direcciones y tal vez una dirección tenga muchos contactos.

¿Debería modelarse como una relación de varios a varios, con algún tipo de objeto ContactAddress que tenga una ID de contacto y una ID de dirección? Dependerá de lo que sea importante para el dominio de su aplicación. Algunas aplicaciones pueden tratar a los Contactos como entidades fuertes, independientes de la Dirección, pero las Direcciones como entidades débiles, que dependen de un Contacto para su existencia. En ese caso, un contacto puede tener muchas direcciones y cada dirección se refiere a un contacto, como este:

Existe una anomalía potencial en los datos: si cambia la dirección de un contacto, no cambia la misma dirección para todos los contactos. Si el contacto es su principal fuente de referencia, entonces ese puede ser el comportamiento deseado: su contacto se mueve (a otra organización, por ejemplo) y los contactos restantes permanecen en su lugar.

3NF: Sin dependencias de atributos no clave

Si vuelve a mirar Dirección, es posible que detecte los dos campos dependientes, región y país. Un país puede tener regiones o no, pero una región tiene un país: no conviene mezclarlos.

Una forma de asegurarse de que la región pertenece al país correcto es crear un identificador para cada par (país, región), luego hacer que la dirección se refiera al identificador en lugar de a la región y al país de forma independiente:

Un comentario sobre los identificadores generados

En mi opinión, los identificadores generados son un detalle de implementación y realmente solo los necesita el código del cliente cuando se modifica o elimina un registro de back-end (como una fila en una base de datos), pero nunca como parte de una consulta de solo lectura. Además, el usuario del sistema nunca debe verlos, porque no tienen sentido.

Tabla por tipo, tabla por jerarquía de tipos

Lo bueno de los tipos de objetos normalizados es que se asignan fácilmente a tablas de bases de datos relacionales. Para una implementación de base de datos relacional, las tablas reflejan los tipos de objeto (Tabla por tipo) o al menos contienen información para múltiples tipos derivados de un tipo base (Tabla por jerarquía de tipos). Esto puede sonar como si estuviera defendiendo el mapeo relacional de objetos, pero no ... solo estoy diciendo que es beneficioso que su modelo lógico comparta las mismas características del modelo físico en un nivel conceptualnivel. La implementación es un tema completamente diferente.

Referencias

Hay muchos recursos sobre la normalización de esquemas de bases de datos de relaciones:

Normalización de la base de datos: primera, segunda y tercera formas normales - Andrew Rollins

Leí una gran explicación de la primera, segunda y tercera forma normal hace unas semanas. Para aquellos que saben qué base de datos ...

www.andrewrollins.com

Segunda forma normal de la base de datos explicada en inglés simple

La segunda publicación se centró en la primera forma normal, su definición y ejemplos para recalcarlo. Ahora es el momento de ...

www.essentialsql.com

¿Qué es la segunda forma normal (2NF)? - Definición de Techopedia

Segunda forma normal Definición 2NF: la segunda forma normal (2NF) es el segundo paso para normalizar una base de datos. 2NF construye…

www.techopedia.com

Tercera forma normal de la base de datos explicada en inglés simple

La tercera publicación se centró en la segunda forma normal, su definición y ejemplos para recalcarlo. Una vez que una mesa está en ...

www.essentialsql.com

Además, al investigar esta publicación, encontré una visión algo diferente sobre cómo aplicar reglas de normalización a tipos de objetos.

Introducción a la normalización de clases

www.agiledata.org