sql - tabla - title html css

Normalización en inglés simple (11)

+1 por la analogía de hablar con tu esposa. Encuentro que hablar con alguien sin una mente tecnológica necesita cierta facilidad para este tipo de conversación.

pero...

Para agregar a esta conversación, está la otra cara de la moneda (que puede ser importante en una entrevista).

Cuando se normaliza, debe observar cómo se indexan las bases de datos y cómo se escriben las consultas.

Cuando en una base de datos verdaderamente normalizada, he encontrado que en situaciones ha sido más fácil escribir consultas que son lentas debido a malas operaciones de unión, mala indexación en las tablas, y mal diseño en las tablas mismas.

Sin rodeos, es más fácil escribir malas consultas en tablas normalizadas de alto nivel.

Creo que para cada aplicación hay un término medio. En algún punto, usted desea la facilidad de sacar todo en algunas tablas, sin tener que unirse a una tonelada de tablas para obtener un conjunto de datos.

Entiendo el concepto de normalización de la base de datos, pero siempre me cuesta explicarlo en inglés sencillo, especialmente para una entrevista de trabajo. He leído la publicación de wikipedia , pero todavía me resulta difícil explicar el concepto a los no desarrolladores. "Diseñar una base de datos para no obtener datos duplicados" es lo primero que se le ocurre.

¿Alguien tiene una buena manera de explicar el concepto de normalización de base de datos en inglés simple? ¿Y cuáles son algunos buenos ejemplos para mostrar las diferencias entre la primera, segunda y tercera formas normales?

Supongamos que va a una entrevista de trabajo y la persona pregunta: Explicar el concepto de normalización y cómo diseñar una base de datos normalizada.

¿Qué puntos clave están buscando los entrevistadores?

Bueno, si tuviera que explicárselo a mi esposa, habría sido algo así:

La idea principal es evitar la duplicación de datos de gran tamaño.

Echemos un vistazo a una lista de personas y el país del que provienen. En lugar de mantener el nombre del país que puede ser tan largo como "Bosnia y Herzegovina" para cada persona, simplemente tenemos un número que hace referencia a una tabla de países. Entonces, en lugar de tener 100 "Bosnia y Herzegovina", tenemos 100 # 45. Ahora en el futuro, como sucede a menudo con los países de los Balcanes, se dividen en dos países: Bosnia y Herzegovina, tendré que cambiarlo solo en un lugar. Especie de.

Ahora, para explicar 2NF, habría cambiado el ejemplo, y supongamos que tenemos la lista de países que visitó cada persona. En lugar de sostener una mesa como:

Person CountryVisited AnotherInformation D.O.B. Faruz USA Blah Blah 1/1/2000 Faruz Canada Blah Blah 1/1/2000

Hubiera creado tres tablas, una tabla con la lista de países, una tabla con la lista de personas y otra tabla para conectar ambas. Eso me da la mayor libertad que puedo obtener cambiando la información de la persona o del país. Esto me permite "eliminar filas duplicadas" como espera la normalización.

Enseño normalización en mis cursos de Acceso y lo analizo de varias maneras.

Después de discutir los precursores de la creación de guiones o la planificación de la base de datos, profundizo en la normalización. Explico las reglas de esta manera:

Cada campo debe contener el valor significativo más pequeño:

Escribo un campo de nombre en la pizarra y luego coloco un nombre y apellido en él como Bill Lumbergh. Luego preguntamos a los estudiantes y les preguntamos con qué tendremos problemas, cuando el nombre y apellido están todos en un solo campo. Uso mi nombre como ejemplo, que es Jim Richards. Si los estudiantes no me llevan por el camino, entonces les doy la mano y los llevo conmigo. :) Les digo que mi nombre es un nombre difícil para algunos, porque tengo lo que algunas personas consideran 2 nombres y algunas personas me llaman Richard. Si intentas buscar mi apellido, será más difícil para una persona normal (sin comodines), porque mi apellido está enterrado al final del campo. También les digo que tendrán problemas para ordenar fácilmente el campo por apellido, porque de nuevo mi apellido está enterrado al final.

Luego les hago saber que lo significativo se basa en la audiencia que también va a utilizar la base de datos. Nosotros, en nuestro trabajo, no necesitaremos un campo separado para el número de apartamento o suite si almacenamos las direcciones de las personas, pero las compañías de envío como UPS o FEDEX pueden necesitar que se separen para retirar fácilmente el departamento o suite a donde necesitan ir cuando están en la carretera y van desde la entrega hasta la entrega. Entonces no es significativo para nosotros, pero definitivamente es significativo para ellos.

Evitar espacios en blanco:

Utilizo una analogía para explicarles por qué deben evitar los espacios en blanco. Les digo que Access y la mayoría de las bases de datos no almacenan espacios en blanco como lo hace Excel. A Excel no le importa si no tiene nada escrito en la celda y no aumentará el tamaño del archivo, pero Access reservará ese espacio hasta el momento en que realmente usará el campo. Entonces, incluso si está en blanco, entonces seguirá usando espacio y les explicará que también ralentiza sus búsquedas hacia abajo también.
La analogía que uso es cajas de zapatos vacías en el armario. Si tiene cajas de zapatos en el armario y está buscando un par de zapatos, tendrá que abrir y buscar en cada uno de los cuadros un par de zapatos. Si hay cajas de zapatos vacías, estás desperdiciando espacio en el armario y también estás perdiendo el tiempo cuando necesitas mirar a través de ese cierto par de zapatos.

Evitar redundancia en datos:

Les muestro una tabla que tiene muchos valores repetidos para la información del cliente y luego les digo que queremos evitar los duplicados, porque tengo dedos de salchicha y escribiré mal los valores si tengo que escribir la misma cosa una y otra vez. Esta "digitación de grasa" de los datos llevará a que mis consultas no encuentren los datos correctos. En su lugar, dividiremos los datos en una tabla separada y crearemos una relación utilizando un campo clave primario y externo. De esta forma, estamos ahorrando espacio porque no estamos escribiendo el nombre del cliente, la dirección, etc. varias veces y, en su lugar, solo estamos usando el número de ID del cliente en un campo para el cliente. Luego discutiremos las listas desplegables / cuadros combinados / listas de búsqueda o cualquier otra cosa que Microsoft quiera nombrar más adelante. :) Usted como usuario no querrá buscar y escribir el número del cliente cada vez en ese campo de cliente, por lo que configuraremos una lista desplegable que le dará una lista de clientes, donde puede seleccionar su nombre y completará la identificación del cliente por usted. Esta será una relación de 1 a muchos, mientras que 1 cliente tendrá muchos pedidos diferentes.

Evitar grupos repetidos de campos:

Lo demuestro cuando hablo de relaciones de muchos a muchos. Primero, dibujo 2 tablas, 1 que contendrá información del empleado y 1 que contendrá información del proyecto. Las tablas se colocan de forma similar a esto.

(Table1) tblEmployees * EmployeeID First Last (Other Fields)…. Project1 Project2 Project3 Etc. ********************************** (Table2) tblProjects * ProjectNum ProjectName StartDate EndDate …..

Les explico que esta no sería una buena forma de establecer una relación entre un empleado y todos los proyectos en los que trabajan. Primero, si tenemos un nuevo empleado, entonces no tendrán ningún proyecto, por lo que estaremos desperdiciando todos esos campos, segundo, si un empleado ha estado aquí mucho tiempo, entonces podrían haber trabajado en 300 proyectos, entonces tendríamos para incluir 300 campos de proyectos. Aquellas personas que son nuevas y solo tienen 1 proyecto tendrán 299 campos de proyectos desperdiciados. Este diseño también es defectuoso porque tendré que buscar en cada uno de los campos del proyecto para encontrar todas las personas que han trabajado en un determinado proyecto, porque ese número de proyecto podría estar en cualquiera de los campos del proyecto.

Cubrí una buena cantidad de conceptos básicos. Avíseme si tiene otras preguntas o si necesita ayuda con la aclaración / desglose en inglés sencillo. La página wiki no se lee como un simple inglés y puede ser desalentador para algunos.

Esta no es una explicación completa, pero uno de los objetivos de la normalización es permitir el crecimiento sin incomodidad.

Por ejemplo, si tiene una tabla de user , y cada usuario tendrá un solo número de teléfono, está bien tener una columna de phonenumber en esa tabla.

Sin embargo, si cada usuario va a tener una cantidad variable de números de teléfono, sería incómodo tener columnas como phonenumber1 , phonenumber2 , etc. Esto se debe a dos razones:

Si sus columnas suben a phonenumber3 y alguien necesita agregar un cuarto número, debe agregar una columna a la tabla.
Para todos los usuarios con menos de 3 números de teléfono, hay columnas vacías en sus filas.

En su lugar, desea tener una tabla de números de teléfono, donde cada fila contiene un número de teléfono y una referencia de clave externa a qué fila de la tabla de user pertenece. No se necesitan columnas en blanco, y cada usuario puede tener el número de teléfono que sea necesario.

Esto es lo que les pido a los entrevistados:

¿Por qué no utilizamos una sola tabla para una aplicación en lugar de usar varias tablas?

La respuesta es, por supuesto, la normalización. Como ya se dijo, es para evitar la redundancia y por anomalías de actualización.

He leído los enlaces de la wiki sobre normalización muchas veces, pero he encontrado una mejor visión general de la normalización de este article . Es una explicación simple y fácil de entender de la normalización hasta la cuarta forma normal. ¡Dale una lectura!

Avance:

¿Qué es la normalización?

La normalización es el proceso de organizar datos de manera eficiente en una base de datos. Hay dos objetivos del proceso de normalización: eliminar datos redundantes (por ejemplo, almacenar los mismos datos en más de una tabla) y garantizar que las dependencias de datos tengan sentido (solo almacenar datos relacionados en una tabla). Ambos son objetivos valiosos, ya que reducen la cantidad de espacio que consume una base de datos y garantizan que los datos se guarden de manera lógica.

article

La normalización de la base de datos es un proceso formal de diseño de su base de datos para eliminar datos redundantes. El diseño consiste en:

planificar qué información almacenará la base de datos
delineando qué información solicitarán los usuarios de ella
documentando las suposiciones para su revisión

Use un data-dictionary u otra representación de metadatos para verificar el diseño.

El mayor problema con la normalización es que terminas con varias tablas que representan lo que conceptualmente es un solo elemento, como un perfil de usuario. No se preocupe por normalizar los datos en la tabla que tendrá registros insertados pero no actualizados, como registros de historial o transacciones financieras.

Referencias

La normalización es un conjunto de reglas que se utilizan para diseñar tablas conectadas a través de relaciones.

Ayuda a evitar entradas repetitivas, reduciendo el espacio de almacenamiento requerido, evitando la necesidad de reestructurar las tablas existentes para acomodar nuevos datos, aumentando la velocidad de las consultas.

Primera forma normal: los datos deben dividirse en las unidades más pequeñas. Las tablas no deben contener grupos repetitivos de columnas. Cada fila se identifica con una o más claves principales. Por ejemplo, hay una columna llamada ''Nombre'' en una tabla ''Personalizada'', debe dividirse en ''Nombre'' y ''Apellido''. Además, ''Custom'' debe tener una columna llamada ''CustiomID'' para identificar una costumbre en particular.

Segunda forma normal: cada columna que no sea clave debe estar directamente relacionada con la clave primaria completa. Por ejemplo, si una tabla ''personalizada'' tiene una columna llamada ''ciudad'', la ciudad debe tener una tabla separada con la clave principal y el nombre de la ciudad definidos, en la tabla ''personalizada'', reemplace la columna ''ciudad'' con ''CityID'' y hacer ''CityID'' la clave externa en el cuento.

Tercera forma normal: cada columna no clave no debe depender de otras columnas que no sean clave. Por ejemplo, en una tabla de órdenes, la columna ''Total'' depende de ''Precio unitario'' y ''cantidad'', por lo que la columna ''Total'' debe eliminarse.

Las relaciones uno a muchos deben representarse como dos tablas separadas conectadas por una clave externa. Si intenta meter una relación lógica de uno a varios en una sola tabla, está violando la normalización que conduce a problemas peligrosos.

Supongamos que tiene una base de datos de sus amigos y sus gatos. Dado que una persona puede tener más de un gato, tenemos una relación uno a muchos entre personas y gatos. Esto requiere dos tablas:

( Cats.OwnerId es una clave externa para Friends.Id )

El diseño anterior está completamente normalizado y se ajusta a todos los niveles de normalización conocidos.

Pero digamos que intenté representar la información anterior en una sola tabla como esta:

(Este es el tipo de diseño que podría haber hecho si estuviera acostumbrado a las hojas de Excel pero no a las bases de datos relacionales). Un enfoque de tabla única me obliga a repetir cierta información si deseo que los datos sean consistentes. El problema con este diseño es que algunos hechos, como la información que la dirección de Bob es "El campanario", se repite dos veces, lo cual es redundante y hace que sea difícil consultar y cambiar datos y (lo peor) posible introducir incoherencias lógicas.

P.ej. si Bob se mueve, tengo que asegurarme de cambiar la dirección en ambas filas. Si Bob tiene otro gato, debo asegurarme de repetir el nombre y la dirección exactamente como se escriben en las otras dos filas. Por ejemplo, si hago un error tipográfico en la dirección de Bob en una de las filas, de repente la base de datos tiene información inconsistente sobre dónde vive Bob. La base de datos no normalizada no puede evitar la introducción de datos incoherentes y contradictorios, y por lo tanto la base de datos no es confiable. Esto claramente no es aceptable.

La normalización no puede evitar que ingrese datos incorrectos. Lo que la normalización impide es la posibilidad de datos inconsistentes .

Es importante tener en cuenta que la normalización depende de las decisiones comerciales. Si tiene una base de datos de clientes y decide registrar solo una dirección por cliente, entonces el diseño de la tabla (#CustomerID, CustomerName, CustomerAddress) está bien. Sin embargo, si decide que permite que cada cliente registre más de una dirección, entonces el mismo diseño de tabla no se normaliza, porque ahora tiene una relación uno a muchos entre el cliente y la dirección. Por lo tanto, no puede simplemente mirar una base de datos para determinar si está normalizada, debe entender el modelo comercial detrás de la base de datos.

Un punto de vista lateral a tener en cuenta sobre la normalización: una base de datos totalmente normalizada es eficiente desde el punto de vista del espacio , pero no es necesariamente la disposición de datos más eficiente en función del tiempo en función de los patrones de uso.

Saltar a varias tablas para buscar todas las piezas de información de sus ubicaciones desnormalizadas lleva tiempo. En situaciones de carga elevada (millones de filas por segundo volando, miles de clientes simultáneos, como el procesamiento de transacciones con tarjeta de crédito) donde el tiempo es más valioso que el espacio de almacenamiento, las tablas apropiadamente desnormalizadas pueden dar mejores tiempos de respuesta que las tablas completamente normalizadas.

Para obtener más información sobre esto, busque libros SQL escritos por Ken Henderson.

Yo diría que la normalización es como mantener notas para hacer las cosas de manera eficiente, por así decirlo:

Si tenía una nota que decía que tenía que ir a comprar helado sin normalización, entonces tenía otra nota que decía que tenía que ir a comprar helado, uno solo en cada bolsillo.
Ahora, en la vida real, nunca harías esto, entonces ¿por qué hacerlo en una base de datos?

Para la parte de diseño e implementación, es cuando puede volver a "la jerga" y mantenerla alejada de los términos comunes, pero supongo que podría simplificar. Al principio dirías lo que necesitabas y luego, cuando llega la normalización, dices que te asegurarás de lo siguiente:

No debe haber grupos repetitivos de información dentro de una tabla
Ninguna tabla debe contener datos que no dependan funcionalmente de las tablas clave principal
Para 3NF, me gusta la opinión de Bill Kent: cada atributo que no sea clave debe proporcionar un hecho sobre la clave, la clave completa y nada más que la clave.

Creo que puede ser más impresionante si también hablas de desnormalización, y el hecho de que no siempre puedes tener la mejor estructura Y estar en formas normales.