¿En qué punto la normalización de datos se vuelve absurda?

Question

A menudo me pregunto si estoy tomando el enfoque correcto al tratar de planificar expansibilidad futura al crear bases de datos y relaciones.

que tienen la siguiente situación:

1. Tengo una tabla Donor y una mesa Recipient. Ambas tablas comparten información común como first_name, last_name, email_address, date_of_birth, etc. Ambas parecen, si perdonan mi lenguaje orientado a objetos, comparten un tipo abstracto común de Person. Es posible que alguien que se encuentra en un punto Recipient más tarde se convierta en Donor mediante una donación, por lo que es importante que la información no se duplique en las tablas. ¿Debo optar por un patrón de herencia, o debo simplemente clave externa Donor sy Recipient s a una tabla Person?

2. Inicialmente, estaba pensando simplemente mapear propiedades como email_address y las propiedades de la calle directamente en las cosas que las necesitan, pero luego puede surgir la posibilidad de que una persona tenga múltiples direcciones de correo electrónico o correo (es decir, trabajo, etc.). Lo que esto significa es que tenemos un modelo algo como esto:

   create table person(id int primary key auto increment, ..., 
       default_email_address); 
   
   create table email_address(id int primary key auto increment, 
       email varchar(255), name varchar(255), is_default bool, person_id int); 
   

   Esto hace las cosas un poco complicado, como se puede imaginar. El campo name también incluye una lista de valores predeterminados y también permite entradas personalizadas. No puedo simplemente convertirlo en un campo de enumeración, porque existe la posibilidad de que alguien tenga que enviar un montón de correos electrónicos que podrían ser diferentes ... (este es el punto en el que grito "¿ES AÚN MÁS VALOR? !?!?" y se sienten frustrados con el proyecto)

Creo que lo que realmente se reduce a lo siguiente: ¿en qué momento la normalización de datos se convierten en ridículos? Mi objetivo aquí es crear un modelo de datos realmente bueno compatible con el futuro como sea posible que no me molestaré por crear más adelante.

Answer 1

¿en qué punto la normalización de datos se vuelve absurda?

En el punto en que deja de modelar los requisitos reales.

para tomar sus ejemplos:

• Con los Donor y Recipient tablas, si es altamente probable que una sola persona se convertirá en ambos, entonces tiene sentido separar a una entidad Person. Si esto es raro, no es así. Con las situaciones email_address y street_address, depende de si necesita almacenar múltiples o no (¿cuál es la expectativa? Es posible que desee almacenar versiones separadas por unidad de negocio (por ejemplo, shipping_address frente a billing_address).

Answer 2

Creo que el problema no está en su implementación, sino en su análisis del problema.Donor y Recipient no son actores de primera clase, son roles de los actores. Si usted modela como tales, se obtendría un modelo algo más limpio:

• Tendrías una mesa persona con direcciones y así sucesivamente
• También tendríamos una tabla de direcciones con las direcciones de las personas
• También tendría una tabla person_role, con el código de función (donante, destinatario) y otra información relevante. Es posible que desee ser elegante, y agregue person_donor y person_recipient, con una clave externa en la tabla person.

Answer 3

Pondría todos los datos compartidos en una tabla Person. Las tablas Donor y Recipient solo deben contener datos que son específicos de cada una, y deben tener claves externas que señalen de nuevo a la clave principal Person.

Esto no es una normalización ridícula en absoluto; en realidad es una práctica bastante común.

Answer 4

Respuesta corta: La normalización nunca se vuelve ridícula. La mayoría de lo que estás haciendo no es normalización.

más larga responder

La "peor" (en realidad, los "mejores) mayoría de los diseñadores prácticamente puede hacer es terminar con todas las tablas de 5NF. 5NF no es ridículo en absoluto. (Sí, sé sobre 6NF. estoy haciendo caso omiso de que por razones didácticas.)

cuestionar si estoy tomando el enfoque correcto al tratar de planificar para el futuro expansibilidad

Th Es una buena pregunta para preguntarte. Sin embargo, no tiene nada que ver con la normalización. En el nivel conceptual, la normalización es algo que usted hace después de ha decidido qué atributos (columnas) y datos necesitan ingresar a su base de datos. Los diseñadores experimentados de bases de datos a menudo "piensan en 3NF", eligiendo atributos, datos y normalizando todo al mismo tiempo, más o menos.

¿Debo optar por un patrón de herencia, o debo extranjeros clave donantes y receptores a una mesa persona?

Los donantes y los destinatarios no son diferentes tipos de personas. Los donantes son personas que han hecho una donación. Los destinatarios son personas que han recibido algo.

id fullname  don_date don_amt recip_date recip_amt 
-- 
1 Jamie Hubbert 2012-01-13 $20.00 
1 Jamie Hubbert 2012-02-13 $17.00 
2 Kelly Hawkin 2012-01-13 $50.00 
2 Kelly Hawkin 2012-01-13 $20.00 
3 Neva Papke       2012-01-13 $15.00 
3 Neva Papke       2012-02-13 $15.00 
2 Kelly Hawkin      2012-01-13 $10.00 
4 Jamie Hubbert 2012-01-13 $10.00 
4 Jamie Hubbert      2012-02-13 $10.00 

Durante la normalización, identificaría estas dependencias. (Por simplicidad, asume una donación por persona por fecha).)

• person_id -> person_name
• person_id -> correo electrónico
• person_id, donation_date -> donation_amount
• person_id, recip_date -> recip_amount

Normalizar a 5NF, y que le obtener estas tres tablas.

Persons 
-- 
1 Jamie Hubbert 
2 Kelly Hawkin 
3 Neva Papke 
4 Jamie Hubbert 

Donations 
-- 
1 2012-01-13 $20.00 
1 2012-02-13 $17.00 
2 2012-01-13 $50.00 
2 2012-01-13 $20.00 
4 2012-01-13 $10.00 

Receipts (?) 
-- 
3 2012-01-13 $15.00 
3 2012-02-13 $15.00 
2 2012-01-13 $10.00 
4 2012-02-13 $10.00 

Al principio, yo estaba pensando simplemente en un mapa propiedades como propiedades email_address y la dirección directamente en las cosas que los necesitan, pero entonces la posibilidad puede surgir que una persona tendría tener múltiples direcciones de correo electrónico o direcciones de correo (es decir: casa, trabajo, etc.).

Decidir si se admiten múltiples direcciones de correo electrónico, varias direcciones de correo y diferentes direcciones de envío y envío es una decisión de diseño importante. Pero no tiene nada que ver con la normalización. La normalización, de nuevo, es algo que usted hace después de ha decidido qué atributos y datos pertenecen a su base de datos. Por lo tanto, si estaba recopilando datos de muestra del representante, podría terminar con uno de estos dos conjuntos de direcciones de correo electrónico.

Set A 
1 Jamie Hubbert jhubbert@somedomain.com 
4 Jamie Hubbert jamie.hubbert@this.com 

Set B 
1 Jamie Hubbert jhubbert@somedomain.com 
1 Jamie Hubbert jamie@my.com 
4 Jamie Hubbert jamie.hubbert@this.com 

En el conjunto A, person_id-> email. En el conjunto B, no. Elegir admitir los datos en el conjunto A o los datos en el conjunto B es una decisión grande, y afecta fuertemente lo que termina con después de normalizar a 5NF. Pero decidir qué sistema apoyar no tiene nada que ver con la normalización.

Como un lado, la elección de asignar números de identificación a direcciones de correo electrónico no únicas es otra decisión de diseño grande (y cuestionable). Al igual que otros, esta decisión no tiene nada que ver con la normalización.

(nombres al azar cortesía de The Random Name generator.)