Y digo “casi”, porque en palabras de un gran pensador del siglo XX como ha sido y es Nicolas Cage, “Nadie quiere ver la perfección”. Búscalo en Google, de verdad que es una cita de Nicolas Cage.
En fin, como reza el título, hoy te traigo una breve guía para montar la Base de Datos CASI perfecta. Prepara palomitas y ponte cómodo, porque la lectura de hoy es un poco larga y MUY ÚTIL.
Broma aparte, cuando digo “casi”, básicamente me refiero al hecho de que cada maestrillo tiene su librillo, y donde unos te dirán negro, otros te dirán blanco. Donde unos te dirán que la desnormalización debe evitarse a toda costa, otros te dirán que es bueno que haya información redundante según con qué tipo de Base de Datos estemos trabajando. Donde unos te dirán que la convención de nomenclatura ideal es usar el guion bajo entre palabras, otros te dirán que el estilo Camel Case es lo que se llevará en la temporada Primavera/Verano 2023…
No te preocupes, es normal que aún no sepas de que estoy hablando, pero, para que puedas saberlo, he hecho una larga y exhaustiva búsqueda en el vergel de información que es internet, recopilando guías, consejos y testimonios de primera mano de nuestros ancianos para traerte esta humilde guía.
Repito de nuevo, no es un resumen definitivo, y seguramente habrá algún punto de esta lista que tendrás que saltarte a la torera, ya sea por requerimientos del cliente, porque sabes más de lo que aparentas saber o porque no has leído bien el artículo.
Además, intentaré ir a lo fundamental. Por ejemplo, en este caso vamos a descartar cualquier opción que no sea una base de datos SQL; dios me libre y guarde de ponerte en el aprieto de tener que elegir entre SQL y NoSQL…
¡Arrancamos pues!
Lo primero que debes tener en cuenta es que, si una base de datos funciona y está bien estructurada, menos trabajo tendrás a la hora de sanear errores y más contento quedará tu cliente con tu trabajo.
Por ello, una de las claves más fundamentales para diseñar tu Base de Datos es entender bien el negocio para el que la harás, así como sus requerimientos, a mayor nivel de detalle mejor.
Esto te ayudará a visualizar mucho mejor cómo estructurar los datos que genera el cliente.
Por ejemplo, una de las primeras decisiones que tendrás que tomar es, ¿Modelo Relacional o Dimensional? Según escribe Steve Hoberman en “Data Modelling Made Simple”, ambos modelos se pueden distinguir por lo siguiente:
“Los modelos relacionales de datos capturan la solución de negocio de cómo funciona una parte del negocio, también conocido como proceso comercial. Mientras que los modelos de datos dimensionales capturan los detalles que la empresa necesita para responder preguntas sobre lo bien que lo está haciendo.”
Es decir, si el cliente solo necesita tener estructurada y almacenada digitalmente la información concerniente a su negocio, y sólo necesitará insertar, borrar y modificar datos en cada una de las posibles tablas que conformen su base de datos, con un modelo relacional es más que suficiente. Ahora, si dichos datos van a ser usados de manera analítica, y, a parte de almacenarse, también serán reutilizados para la toma de decisiones, un modelo dimensional será más adecuado.
Con esto en mente, toca dibujar un boceto previo del esquema. A este boceto se le suele llamar “diseño conceptual”.
Digamos que el diseño conceptual va a ser el esqueleto en el que, como huesos, plasmarás cómo la información va a estar dividida en términos generales. Imaginemos que se nos ha pedido diseñar la base de datos interna de los empleados de una empresa (ejemplo más simple imposible ¿eh?). El diseño conceptual, constaría, por ejemplo, de los diferentes departamentos de la empresa, y dentro de cada departamento, cómo la información debería estar dividida. Por ejemplo, dentro del departamento de ventas, se podría obtener información como el puesto, el nombre y apellidos, el id dentro de la empresa, el número de contacto, si tiene coche, si tiene permiso de conducir, si tiene patinete… Aunque no te flipes, es mas que probable que la empresa no te quiera pagar para almacenar información sobre si sus empleados tienen patinetes o no. Para ello está el primer punto ya expuesto: ¡comprende el negocio!
Los diagramas entidad-relación (ERD) son una herramienta bastante útil a la hora de diseñar el concepto de nuestra base de datos, y es uno de los modelos más usados para esta fase del diseño.
Tras el diseño conceptual, tocará desarrollarlo, meterle músculo y tendones a nuestro esqueleto. Esto se entiende como “diseño lógico”. Dentro de este diseño lógico podemos desarrollar varias formas de modelo creando entidades, atributos e instancias que serán nuestras futuras tablas, columnas y filas respectivamente. Veamos unos cuantos de estos modelos para añadir luz a nuestra oscura ignorancia:
Por un lado, tenemos el modelo jerárquico, que organiza los datos en una estructura de árbol (como, por ejemplo, el organigrama de una empresa) y que rara vez se usa hoy en día por su ineficiencia operativa a la hora de estructurar cantidades masivas de datos.
Basado en el modelo jerárquico, pero añadiéndole cierta complejidad, podemos encontrar también el modelo de red, que permite las relaciones muchos a muchos entre registros que tienen un vínculo, permitiendo que dichos registros puedan ser miembro principal o secundario en múltiples conjuntos.
También tenemos el modelo de base de datos orientados a objetos, donde la base de datos se define como una colección de objetos, funciones y métodos que se relacionan entre sí; tablas, imágenes, hipertexto… Hoy en día es bastante útil si buscas montar una base de datos post-relacional.
Además, y por último en esta breve introducción a los diferentes modelos, del resultado de combinar el modelo relacional con el modelo orientado a objetos surge el modelo relacional de objetos, que permite añadir objetos en una estructura de tablas.
En esta fase del proceso entran también algunas cuestiones fundamentales para el funcionamiento de nuestra base de datos, como por ejemplo, qué atributos usaremos como claves primarias, qué vistas deben definirse, cómo resolver relaciones de varios a varios…
Si estás leyendo este artículo, seguro ya sabes qué son y cómo funcionan las Primary Keys y las Foreign Keys y como usarlas en diferentes tablas para relacionarlas entre sí, por lo que no creo que sea necesario hacer un breve repaso de ello. Mejor hablemos de la maldita normalización.
Como dice un informático argentino amigo “normalización es una palabra maravishosa”.
El objetivo de la normalización es, mediante la aplicación de ciertas reglas, que la redundancia de datos sea la mínima y la integridad de los datos esté protegida. Sintetizando, la normalización trata de dividir tablas grandes con mucha información en tablas más pequeñas categorizando dicha información y vincularlas entre ellas a través de claves tanto primarias como foráneas. Se pueden identificar 5 formas normales cuya explicación suena peor que pisar un lego, pero con imágenes todo entra mejor. En este artículo vamos a explicar las tres primeras formas, no hay plazas suficientes en psiquiátricos para todos los locos que quedaríamos tratando de entender las 5 formas normales de golpe:
– En la primera forma normal, ningún campo de la tabla puede almacenar valores múltiples. Si algún campo almacena más de dos valores, estos deben ser repartidos de manera que cada fila sea única. Fácil, ¿no?:
– La segunda forma normal ha de ser aplicada tras la primera forma, en ella debe existir una clave principal que identifique una entidad o atributo y cada uno de estos debe ser independiente entre las diferentes columnas y a su vez dependiente de la clave principal. Con esto en mente, se trataría de eliminar la información redundante dividiendo la tabla en primera forma en dos tablas. Mejor verlo visualmente:
En la primera tabla, la clave principal sería la ID del autor, y en la segunda tabla la clave principal sería el título del libro (más adelante añadiremos un código para cada libro también)
– Para la tercera forma normal, la segunda forma ha de cumplirse y, además ningún atributo puede ser dependiente transitivamente de una clave primaria u otra clave foránea. Dicha dependencia existe si al cambiar el valor de un atributo, necesariamente cambia el valor de otro. Por tanto, si queremos aplicar la tercera forma normal, tendremos que buscar un subconjunto que no tengan relación con la clave primaria, es decir, atributos no clave, y que dependan de otros atributos no claves y moverlos a una nueva relación. Más sencillo es el idioma chino, ¿no? A lo mejor con una imagen…
Como puedes ver, en esta tabla, el género depende de su nomenclatura, por lo que si quisieras modificar alguno de los géneros, la nomenclatura debería cambiar necesariamente. Para solventar este problema, estableceríamos una nueva relación donde la nomenclatura fuera la clave primaria del género, y a su vez una clave foránea en la tabla de títulos de libros:
Lo sé, es un poco lioso, pero si te fijas, al final lo que se ha hecho ha sido dividir los atributos no clave que dependen de otro atributo no clave, y establecer este como clave foránea en la tabla principal y clave primaria en la nueva tabla, siendo esta el título del libro (LIBRO = PK, ID = FK y Nomenclatura = FK), así cada atributo no clave es independiente al resto de ellos y si quisieras, por ejemplo, corregir el género de un libro en la segunda tabla, no tendrías que editar las dos columnas (de la tabla principal), sino simplemente cambiar su nomenclatura.
Si quisiéramos complicar las cosas, tenemos la cuarta y quintas formas normales. Trataremos de explicarlas en el próximo artículo, además de ensuciarnos los dedos y pasar del plano a la pala: vamos a plasmar el concepto y probarlo, es decir, vamos a hacer el diseño físico de la Base de Datos, donde vamos a optimizar el rendimiento y la integridad de nuestros valiosos datos y transformar las entidades en tablas, los atributos en columnas y las instancias en filas.
¡Gracias por leer! ¡Hasta la próxima!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
