Sobre bases de datos relacionales

Tos comentarios me ayudan a mejorar el contenido de mis publicaciones para que sean de mayor utilidad e interés. Agradezco tu aportación.

Hablando de Bases de Datos Relacionales, para algunos programadores, el proceso de normalización y sus niveles son objeto de discusión.

Para mí, está claro que un buen diseño de base de datos debe incluir claves foraneas (por supuesto, si el motor de base de datos lo permite). Al menos para el diseño conceptual, las conexiones entre relaciones (o tablas) deben ser claras. Por lo tanto, aquí voy a explicar lo que es normalizar una base de datos, beneficios, desventajas y otros conceptos relacionados con este proceso. Comencemos.

La normalización es el proceso por el cual una colección de datos se organiza en pedazos más pequeños para evitar información duplicada y reducir posibles errores humanos y de sistema. Es importante intentar realizar este proceso al principio, antes de seleccionar el motor de base de datos e independiente de los lenguajes y herramientas de desarrollo.

Por ejemplo: Puedes tomar tu agenda (de tu teléfono inteligente o a la usanza antigüa, de un libro físico). Observa qué datos pueden registrarse para cada contacto: nombre, dirección, ciudad, grupo, teléfono celular, correo electrónico, etc. Podemos crear una lista larga con una cierta cantidad de columnas (campos para los términos de la base de datos) y veremos que Ciudad tiene información repetitiva, tal vez escrita en diferentes formas, para el grupo es el mismo caso. Por lo tanto, vamos a normalizar nuestra guía telefónica o lista de contactos.

Nuestro primer paso será asignar un número a cada contacto. Debido a que este número está destinado a ser único y cada contacto tendrá uno, lo llamaremos nuestra clave principal.

El siguiente paso será extraer una lista de ciudades y asignar números a cada ciudad, al igual que nuestro paso anterior. Después de eso, reemplazaremos el nombre de la ciudad en nuestra lista de contactos con el nuevo número. Esta lista de ciudades nuevas será un catálogo, y ahora también tiene una clave primaria. El número de la ciudad para la lista principal se llama Llave Foranea, y se refiere a la clave principal en nuestro catálogo de la ciudad. Vamos a repetir el proceso con nuestro campo de grupo.

Ahora, si nos fijamos en la nueva organización de los datos, podemos ver que para cada ciudad en nuestro catálogo, tenemos algunos registros de contactos, lo mismo con la relación entre nuestro catálogo de grupos y la lista principal.

De ahora en adelante, siempre que queramos agregar un nuevo contacto, sólo tenemos que escribir el número de ciudad y número de grupo, en lugar de escribir el nombre o la abreviatura, u otra cosa similar, y nuestra información se mantendrá coherente.

Este es el proceso básico de normalización. Puedes repetir estos pasos cada vez que necesites.

Los beneficios de este proceso incluyen: evitar información repetitiva, datos claros, menos requerimiento de memoria y capacidad de almacenamiento. Tal vez un par de desventajas será que el motor tendrá que navegar a través de diferentes tablas para obtener la información solicitada y el nivel de complejidad en el diseño.

Talking of Relational Databases, for some programmers, the normalization process and its levels are the subject of discussion.

For me, its clear that a good database design must include foreign keys (of course, if the database engine allows it). At least for conceptual design, the connections between relationships (or tables) must be clear. So, here I will explain what it is to normalize a database, benefits, disadvantages and other concepts related to this process. Let's start.

Normalization is the process by which a collection of data is organized into smaller pieces in order to avoid duplicated information and reduction of possible human and system errors. This process is important to try to do at the beginning, before selectioning the database engine and independient from development languages and tools.

For example: You can take your phonebook (from your smartphone or in an old style, a physical book). Observe what data can you register for each contact: name, address, city, group, cel phone, e-mail, etc. We can create a long list with a certain amount of columns (fields for database terms) and we will see that city has repetitive information, maybe wrote in different forms, for group is the same case. So, let's normalize our phone book or contact list.

Our first step will be to assign a number to each contact. Because this number is meant to be unique and each contact will have one, we will call it our primary key.

The next move will be to extract a list of cities and assign numbers to each city, just like our previous step. After that, we will replace the name of the city in our contact list with the new number. This list of new cities will be a catalog, and now has a primary key as well. The city number for the main list is called Foreign Key, and refers to the main key in our city catalog. Let's repeat the process with our group field.

Now, if we look at the new organization of data, we can see that for each city in our catalog, we have some records of contacts, the same with the relationship between our catalog of groups and the main list.

From now on, whenever we want to add a new contact, we just have to type the city number and group number, instead of write the name or abreviation, or something similar, and our information will keep consistent.

This is the basic normalization process. You can repeat this steps every time you will need.

The benefits of this process include: avoiding repetitive information, clear data, less memory requirement and storage capacity. Perhaps a couple of disadvantages will be that the engine will have to navigate through different tables to get the information requested and the level of complexity in the design.