database - segunda - formas normales 3f
¿Cuál es una buena descripción de KISS de la forma normal de Boyce-Codd? (6)
¿Qué es una forma de KISS (Keep it Simple, Stupid) para recordar qué es la forma normal de Boyce-Codd y cómo tomar una tabla sin normalizar y BCNF?
Información de Wikipedia : no fue terriblemente útil para mí.
Aquí hay algunos extractos útiles de la página de Wikipedia sobre la Tercera Forma Normal :
Bill Kent define la Tercera Forma Normal de esta manera:
Cada atributo no clave "debe proporcionar un hecho sobre la clave, la clave completa y nada más que la clave".
Exigir que los atributos no clave dependan de "la clave completa" garantiza que una tabla esté en 2NF; requiriendo además que los atributos no clave dependan de "nada más que la clave" asegura que la tabla esté en 3NF.
Chris Date adapta el mnemónico de Kent para definir la forma normal de Boyce-Codd:
"Cada atributo debe representar un hecho sobre la clave, la clave completa y nada más que la clave". Aquí el requisito se refiere a cada atributo en la tabla, no solo a los atributos no clave.
Esto entra en juego cuando una tabla tiene varias claves candidatas compuestas, y un atributo dentro de una clave candidata tiene una dependencia en una parte de otra clave candidata. La tercera forma normal no lo prohibiría porque excluye atributos clave. Pero BCNF aplica la regla a los atributos clave también.
En cuanto a cómo hacer que una tabla satisfaga a BCNF, necesita representar la dependencia adicional, con otro atributo y posiblemente dividiendo los atributos en otra tabla.
La definición de Chris Date es bastante buena, siempre que entiendas lo que quiere decir:
Cada atributo
Sus datos deben dividirse en atributos / columnas / valores separados y distintos que no dependen de ningún otro atributo. Tu nombre completo es un atributo. Tu fecha de nacimiento es un atributo. Su edad no es un atributo, depende de la fecha actual que no es parte de su fecha de nacimiento.
debe representar un hecho
Cada atributo es un hecho único, no una colección de hechos. Cambiar un bit en un atributo cambia todo el significado. Tu fecha de nacimiento es un hecho. ¿Es su nombre completo un hecho? Bueno, en algunos casos lo es, porque si cambias tu apellido, tu nombre completo es diferente, ¿verdad? Pero para un genealogista tiene un apellido y un apellido, y si cambia su apellido, su apellido no cambia, por lo que son hechos separados.
sobre la llave,
Un atributo es especial, es una clave. La clave es un atributo que debe ser único para toda la información en sus datos y nunca debe cambiar. Su nombre completo no es una clave porque puede cambiar. Su número de seguro social no es una clave porque se reutilizan. Su número de seguro social más fecha de nacimiento no es una clave, incluso si la combinación no puede reutilizarse nunca, porque un atributo no puede ser una combinación de dos hechos. Un GUID es una clave. Un número que incrementa y nunca vuelve a usar es una clave.
toda la llave,
La clave sola debe ser suficiente [¡ y necesaria! ] para identificar sus valores; no puede tener los mismos datos representados por claves diferentes, ni puede un subconjunto de las columnas clave ser suficiente para identificar el hecho. Supongamos que tiene una libreta de direcciones con una clave GUID, nombre y valores de dirección. Está bien tener el mismo nombre que aparece dos veces con claves diferentes si representan personas diferentes y no son los "mismos datos". Si Mary Jones en contabilidad cambia su nombre a Mary Smith, Mary Jones en Sales no cambia su nombre también. Por otro lado, si Mary Smith y John Smith tienen la misma dirección y realmente es el mismo lugar, esto no está permitido. Debe crear un nuevo par clave / valor con la dirección y una nueva clave.
Tampoco se le permite usar la clave para esta nueva dirección de calle única como valor en la libreta de direcciones, ya que ahora la misma clave de la calle se representará dos veces. En su lugar, debe crear un tercer par de clave / valor con los valores de la clave de la libreta de direcciones y la clave de la calle; encuentra la dirección de la calle de una persona al hacer coincidir la clave de su libro y la clave de dirección en este grupo de valores.
y nada más que la clave
No debe haber nada más que la clave que identifica sus valores. Por ejemplo, si se le permite una dirección de "The Taj Mahal" (asumiendo que solo hay una), no se le permite un valor de ciudad en el mismo registro, ya que si conoce la dirección también conocería la ciudad. Esto también abriría la posibilidad de que haya más de un Taj Mahal en una ciudad diferente. En su lugar, debe volver a crear una clave de Ubicación secundaria con valores únicos como el Taj, la Casa Blanca en DC, etc., y sus ciudades. O prohíba las "direcciones" que son exclusivas de una ciudad.
Entonces ayúdame, Codd.
Busqué en Google "boyce codd normal form" y después de wikipedia este es el segundo resultado. Mi libro de texto ofrece una definición muy simple en términos de sistemas de administración de bases de datos relacionales:
El lado izquierdo de cada FD no trivial debe ser una superclave.
- "Database Systems The Complete Book" de Garcia-Molina, Ullman y Widom.
La mejor respuesta informal que he leído es que, en BCNF, cada "flecha" en cada dependencia funcional es una "flecha" de una clave candidata. No recuerdo la fuente, pero probablemente fue algo que Chris Date escribió.
Básicamente Boyce-Codd es "quinta forma normal". Es visualmente reconocible por la existencia de "Entidades atributivas" en el modelo de datos, para cosas como Tipos (por ejemplo, roles, estado, estado del proceso, tipo de ubicación, tipo de teléfono, etc.). Las entidades atributivas (sub-subtipos) son listas de conjuntos finitos de valores que categorizan aún más una entidad de nivel de clase. Entonces puede tener un tipo de cuenta de correo electrónico (''móvil'', ''escritorio'', ''VOIP'') tipo de cuenta (''negocio'', ''personal'', ''juego''), rol (gerente de proyecto, modelador de datos, supermodelo) etc. Otra clave morfológica es la existencia de super-tipos, (también conocidas como clases maestras, superclases, meta-entidades) como las Partes (subtipos que son compañía, persona, etc.).
Básicamente se trata de Taxonomy wild (... no, el video no es tan emocionante) a nivel atómico o de hoja; ver el comentario anterior de Bill Karwin para una explicación más técnica.
Los modelos de nivel Boyce-Codd son esencialmente modelos lógicos altamente detallados, derivados de modelos conceptuales basados en negocios más simplistas. ** Normalmente NO se implementan ver batim en el modelo PHYSICAL, porque la optimización de PDM para el rendimiento (o la simplicidad funcional) puede dar lugar a que los super-tipos y las entidades atributivas se administren como listas desplegables en UI o detrás de la lógica de escenas en la aplicación, o en las limitaciones de la base de datos y los métodos para hacer cumplir la integridad referencial. (es decir, pueden terminar como tablas de búsqueda en el esquema de PDM, o pueden ser manejadas por código y no representadas en la base de datos).
Entonces, ¿por qué hacerlas si no terminan en el PDM? Por la misma razón que construyes un buen modelo de 3NF antes de ''optimizar'', para que la estructura de la base de datos refleje el mundo real y sea más estable que los típicos kludges que heredamos y tengas que hacer actos heroicos para hacer que el trabajo sea nuestro negocio / clientes los requisitos cambian
Muchas veces es más fácil escuchar su intestino y esto vendrá naturalmente. En términos generales, si cumple con 3NF, se ha reunido con BCNF. Esto no cubre el análisis detallado de un ERD o tiene ejemplos, pero hay trece reglas de acuerdo con Codd. Encuentro que es mejor seguir estas reglas, pero siempre recuerdo que no hay una forma correcta de hacer las cosas, así que síguelas libremente. Entonces con respecto al RDBMS, aquí están las reglas:
http://www.87android.com/12-rules-of-relational-database-model-by-codd/
Es posible que esto no responda la pregunta directamente, pero si pregunta cómo llegar a BCNF o una manera fácil de recordarlo, entonces no comprende la normalización lo suficientemente bien. Sin embargo, eso no tiene importancia. Las bases de datos relacionales toman muchas formas y muy pocas se hacen bien. Lo mejor que puede hacer es saber qué significa ser relacional, seguir las reglas anteriores y no preocuparse por el nivel de normalización. El proceso de normalización elimina la duplicación de datos. Cada nivel más, al pasar a la migración de dependencias funcionales. Tenlo en cuenta y estarás bien, tu instinto y tu inteligencia harán el resto.