¿Agregar un campo "ID" a las tablas de la base de datos de acuerdo con la tercera forma normal se considera un error?

Question

¿Está bien agregar el campo "ID" como clave principal a todas las tablas de mi base de datos y también usarlo para hacer que las relaciones se envíen entre tablas? ¿Este diseño se consideraría como diseño 3NF (tercera forma normal)? En caso afirmativo, ¿se recomienda esto teóricamente o no?

Answer 1

El problema es que la pregunta es un poco aislada. Pero dado que le preocupa si el problema tiene una base teórica (y posiblemente un cumplimiento de las normas), la respuesta debe ser no estar tan aislado.

En caso afirmativo, ¿esto se recomienda teóricamente o no?

No. No tiene ninguna base académica o teórica en absoluto. Rompe las reglas básicas de diseño de la Base de Datos Relacional, y por lo tanto (a) no producirá una base de datos Relacional y (b) lo que se produzca, no tendrá el poder de la capacidad relacional que los usuarios (sin tener que pasar por la aplicación) esperarán las muchas herramientas simples de informes de bases de datos relacionales disponibles.

De hecho, es la desgracia muy común, instintiva, método rápido y sucio de hacer hojas de cálculo (que el desarrollador de la aplicación ha identificado para su aplicación) encaja en una "base de datos" contenedor como MS SQL. sin haciendo el trabajo de diseño o modelado de base de datos real que se requiere para que los contenidos del contenedor califiquen como una base de datos relacional. Es bueno para obtener un prototipo o prueba de concepto, pero no está listo para ninguna forma de desarrollo (codificación SQL).

¿Está bien agregar el campo "ID" como clave principal para todas las tablas de mi base de datos y también usarlo para establecer relaciones entre las tablas?

Espera. No pueden ser "tablas de bases de datos", por definición. Las tablas de la base de datos se obtienen mediante un proceso de modelado formal, y como resultado tendrán Identificadores fuertes. Y las relaciones ya definidas. En cuyo caso, la pregunta no se formulará. Por lo tanto, dado que se lo preguntan, las cosas que está preguntando no están ni cerca de "tablas de la base de datos". Son solo un bloc de notas de desarrolladores de aplicaciones para una aplicación.

Agregar una restricción FK a una hoja de cálculo, "relacionarla" con otra hoja de cálculo y agregar una PK "ID" no hace una "base de datos" relacional. No, simplemente usa la capacidad de SQL para relacionar hojas de cálculo que no están relacionadas en el contenedor. Siguen siendo hojas de cálculo no relacionadas, "vinculadas" por una columna añadida "ID".

El resultado es una duplicación sustancial de los datos; actualizar anomalías; muchos más índices; conjuntos de datos "relacionales" más grandes; bajo rendimiento; uso excesivo masivo de tablas temporales; SQL complejo, todo lo cual se puede evitar con un diseño de base de datos genuino.

¿Este diseño se consideraría como diseño 3NF (tercera forma normal)?

La normalización forma parte de (no todos) el proceso de diseño de la base de datos. 3NF se llega a través de ese proceso. 3NF o lo que sea NF, no es una etiqueta que se puede colocar en el conjunto de hojas de cálculo o contenidos parcialmente diseñados del contenedor, sin pasar por el proceso y, por lo tanto, obtener la insignia. Uno no "considera" un montón de hojas de cálculo o contenidos parcialmente diseñados 3NF; uno evalúa si se han seguido las reglas de Normalización, y si las reglas no se violan, entonces se etiqueta bastante 3NF. Como no se ha seguido el proceso de Normalización, no hay ninguna base para sugerir que pueda relacionarse con una Forma Normal.

Del mismo modo, además de la normalización, si se siguieron las reglas de la base de datos relacional durante el proceso, y no se violaron, se cumple con los estándares de la base de datos relacional. Como no se ha seguido la metodología de la Base de datos relacional, no hay ninguna base para sugerir que pueda relacionarse con ningún Estándar de base de datos relacional, o que se pueda esperar de él ninguna capacidad relacional.

La comprensión de todo el tema

"ID" son claves suplentes. Las claves sustitutas son siempre (tiene razón) una clave adicional y el índice, adicional al PK preexistente, que está a punto de ser usurpado. Por supuesto, eso tiene un costo de rendimiento considerable, en cada acceso.

Algunos preguntadores tienen la idea de que las claves sustitutas se pueden usar en sustitución de PK. Lo cual, por supuesto, es falso, y te das cuenta de que, tan agradecido, eso no tiene que abordarse aquí.

La noción de "todas las llaves sustitutas" o "sin llaves sustitutas" es el tipo de tonterías en blanco o negro, todo o nada, que es normal para los niños pero inaceptable en adultos, especialmente cualquier persona El trabajo de TI requiere precisión y comprensión. Es bastante normal que un niño pequeño piense "si papá no me deja hacer lo que quiero, él no me ama", y por lo tanto "si él no me ama, él me odia" . La mayoría de nosotros nos damos cuenta de que la vida es un poco más compleja que eso para la edad de la escuela primaria. Los desarrolladores que "me gusta" para ver "ID" en cada tabla y "no me gusta" la falta de ellos en algunas tablas, son por definición incapaces de considerar la base de datos como un todo, y las necesidades de otros desarrolladores y usuarios; solo están pensando en un código simplista de una tabla a la vez.

También es no sobre tonos de gris, o definiciones borrosas. No, las definiciones no han cambiado en 30 años (se han ampliado y se han hecho más precisas, pero no han cambiado). Tonos de gris permite a los desarrolladores evitar el cumplimiento y los estándares. Entonces eso tampoco es recomendado.

¿Qué es una base de datos relacional genuina?

La verdad es que si un modelador de datos calificado modelara y diseñara honestamente una base de datos, utilizando las metodologías que han estado disponibles durante 30 años, terminaría con una base de datos Relacional genuina. Y si no siguieron el proceso, no sería relacional ni una base de datos. Los Identificadores y las Relaciones ya estarían definidos, y el significado, el contexto, de eso sería llevado a varias tablas. Los datos se normalizarían, a 3NF o BCNF o 5NF, y no habría anomalías de actualización. En el último paso, como parte del proceso formal, y no fuera de él, al traducir el lógico al físico, el modelador puede mejorar el rendimiento de algunos identificadores al agregar claves sustitutas y evitar transportar grandes (ancho) en las tablas secundarias relacionadas (1). Esto prueba nuevamente, desde otro enfoque, por qué la noción de sustitutos nulos, o todos los sustitutos, es infantil y completamente eliminada del proceso genuino.

La base de datos relacional genuina tendrá plena capacidad relacional, logro honesto de 3NF, uso de claves relacionales naturales, con unos pocos decididamente cambiados a Surrogates.

fácilmente demostrables

Por supuesto, todo lo que he dicho se puede probar fácilmente: basta con enviar DDL de 5 a 10 de las hojas de cálculo, necesito una "profundidad" de por lo menos cuatro (great.grand. parent⇢grand.parent⇢parent⇢child).

Puede que le interese, recientemente he publicado información sobre su pregunta, en un related question, que no repito aquí.

Nota

1. Esto sólo es necesario debido a que las ofertas SQL actuales no son compatibles con el modelo relacional completa, y para eliminar los obstáculos de rendimiento conocidos que tienen. Y no será necesario si y cuando los proveedores proporcionen bases de datos relacionales en las que las claves relacionales anchas funcionen tan bien como las estrechas.

2. Estoy de acuerdo con las claves de las declaraciones de Erwin y los identificadores, y por lo tanto no las he repetido en mi respuesta.

Answer 2

Si he entendido bien,

Sí, añadir un ID de serie a una mesa y dejar que esa identificación sea la clave principal a la que se refiere a las filas de la tabla que es, en general, una buena pregunta de diseño. Si esto viola o no 3NF: no viola 3NF pero tampoco garantiza tampoco.

Prácticamente, agregar una identificación de serie y usar ese valor internamente puede tener sus ventajas. Una es que tienes el control de la ID, mientras que una clave generada externamente puede ser cambiada repentinamente por otra persona. Por otro lado, exportar una ID a otras partes "vincula" esa clave, ya que cambiarla de lado puede tener un impacto en el uso de esa clave por parte de los demás. También un número de serie es a menudo fácil de fraguar y puede colisionar con el uso de otros pueblos del número.

También en el diseño de base de datos práctico, 3NF o Boyce-Codd tiende a ser ideas teóricas que usted aspira en lugar de seguir ciegamente. La desnormalización selectiva es un truco conocido para acelerar algunas consultas al acercar los datos.

Answer 3

estoy totalmente de acuerdo con @jlouis que

3NF o Boyce-Codd tiende a ser ideas teóricas

Desde mi práctica, puedo decir que el uso de clave natural es una buena opción sólo en las tablas de búsqueda de referencia similares, siempre y cuando el campo clave en el mundo real es único y no nulo y no cambia en el tiempo. En otros casos, el uso de la clave sustituta es mucho más preferible (desde mi punto de vista): es la manera más conveniente de diseñar tablas a pesar de todo lo que nos dicen 3NF o Boyce-Codd.

Answer 4

Los formularios normales se refieren a las dependencias entre los atributos. Sin saber qué dependencias pretende representar en su tabla, no podemos decir si satisfaría alguna forma normal particular.

Si está hablando de una clave sustituta (una clave que no tiene ningún significado en el dominio comercial), para la mayoría de los propósitos, el punto importante es que dicha clave no debe ser la ÚNICA clave de ninguna tabla. Normalmente debería tener una clave natural (también conocida como clave comercial) para asegurarse de que los datos no se duplican.

Answer 5

"¿Está bien agregar el campo" ID "como clave principal a todas las tablas de mi base de datos y también usarlo para hacer que las relaciones se envíen entre tablas?"

Es evidente que tiene la intención de agregar ID sustitutos en todas partes, a ciegas y sin pensarlo dos veces. Pensar que está bien es tan tonto como hacerlo. Los identificadores "buenos" tienen las propiedades de unicidad (de lo contrario no sería un identificador, obviamente), estabilidad (sus valores cambian con poca frecuencia), y familiaridad (sus valores denotan algo significativo en el mundo del usuario: mundo fuera del sistema de TI).

Tenga en cuenta que utilicé la palabra "identificadores" en lugar de "claves" muy deliberadamente. Las claves tienen la propiedad de unicidad por definición. Por lo tanto, todas las claves son un candidato válido para actuar como un identificador. La clave que elijas para actuar como un identificador, dependerá de cuánto o cuán poco una determinada tecla también satisfaga los criterios de estabilidad y familiaridad.

teclas naturales podrían no satisface el criterio de estabilidad suficiente (pero el grado en que lo hacen es por lo general mucho exceso de estrés, por lo general por el tipo de desarrolladores que piensan muy poco sobre el lado del usuario y demasiado por su propio lado del problema). Los ID generados por el sistema violan el criterio de "familiaridad" con absoluta certeza.

Estas consideraciones deberían ser suficientes para demostrar de qué manera debería ir la balanza en su mayor parte al intercambiar una por la otra.

"¿Este diseño se consideraría como diseño de 3NF (tercera forma normal)? En caso afirmativo, ¿se recomienda esto teóricamente o no?"

Si agrega una columna de ID a un diseño existente, esto no afectará a la NF. Independientemente de la NF en la que haya estado su diseño, el diseño con la ID agregada tendrá la misma NF.