Requerimientos del modelo relacional

Requerimientos modelo relacionalHabiendo comprendido el funcionamiento del modelo relacional es momento de pensar en los requerimientos y reglas a respetar para aprender a diseñar bases de datos relacionales.

Quiero que prestes atención a estas teorías, reglas, requisitos porque son muy importantes a la hora de diseñar, crear, mantener, actualizar, trabajar, consultar bases de datos.

Hasta aquí déjame aclararte que me gusta ir despacio con este tema en mi blog, porque considero que es un complemento muy importante, más allá de saber programar Python o cualquier lenguaje, si no dominamos bases de datos probablemente nunca podamos cumplir el 100% de requisitos de nuestras aplicaciones y además el tratamiento de la información personal, empresarial se está volviendo más importante y valiosa cada día. 

Si te resulta complejo..
No te preocupes, lee, lee y re-lee. Y no te hagas problemas, que luego cuando comencemos a trabajarlos estos conceptos se te van a arraigar hasta la médula ósea. Simplemente, cuando trabajes con bases de datos, leete es post nuevamente para estar seguro/a que no estás metiendo la pata..

 

Antes que nada, debemos diferenciar el modelo relacional del Gestor del Sistema de Bases de Datos.

 

El modelo relacional y el RDBMS

El modelo relacional es APARTE del gestor del sistema de bases de datos (Relational Data Base Managament System, RDBMS de ahora en más). Podemos usar SQL, también MYSQL, PostgreSQL, SQLite, MariaDB, etc (que son RDBMS del tipo relacional de los cuales seguro habrás oído o manipulado).

Todos los RDBMS tienen sus pequeñas variaciones, sin embargo nuestro modelo relacional basado en un diseño mediante el diagrama entidad relación que veremos más adelante debe poder aplicarse a cualquier DBMS relacional (Mysql, Sql, PostgreSQL, etc..). ¿Me explico?

Por un lado tenemos el modelo relacional y por el otro los sistemas de manejo de bases de datos que lo trabajan como MYSQL. Y con un diseño entidad relación, podemos crear nuestra DB para cualquier DBMS relacional.

¿Pero qué es un RDBMS?

NoSQLDatabase Vs RDBMS

Simplemente un DBMS o DBGS es un software de gestión de bases de datos cuya función es servir de interfaz entre la base de datos, el usuario y las distintas aplicaciones utilizadas. Además de simplificarnos el manejo de los datos en conjunto y brindarnos numerosas herramientas que optimizan la creación, actualización, mantenimiento, consultas, etc de información. En el caso de los que aplican al modelo relacional se los denomina RDBMS (Relational Data Base Management System)

Características y beneficios de los RDBMS

Un Software de gestión de bases de datos nos asegura:

  • Independencia. (De la información respecto de nuestro programa de aplicación)
  • Seguridad de los datos. (Además de una gestión segura se nos permite realizar backups automáticos entre otras.)
  • Mínima redundancia. (Evitar datos repetidos en lugares diferentes)
  • Consistencia de la información. (La información está completa, los datos se mantienen idénticos durante cualquier operación, como transferencia, almacenamiento y recuperación)
  • Abstracción de la información sobre su almacenamiento físico. (Poder aislar la información del contexto físico de almacenamiento, trasladarla a otro sistema, a otro servidor, etc.)
  • Adopción de medidas necesarias para mantener la integridad de la información. (Nos proporciona y nos obliga a respetar ciertas normas que permiten mantener la información íntegra, sin inconsistencias.)
  • Medidas de seguridad y gestión de permisos de usuario. (Admite y permite a más de un usuario leer, modificar, actualizar, mantener la información controlando sus privilegios y asegurando los beneficios anteriormente mencionado para cada uno de ellos.)
  • Nos brinda un lenguaje DCL (Lenguaje de control de datos). (Así cada RDBMS tiene su lenguaje y variación del mismo, normalmente SQL que nos permite realizar acciones con los datos almacenados de forma segura, conjunta, ágil,  y normalmente no está ligado a ningún proveedor específico. Por lo que aprender este lenguaje permite manejar muchos y diversos RDBMS)

 

Sin embargo, el modelo relacional está sujeto a ciertas restricciones, reglas y recomendaciones que debemos respetar a la hora de diseñarlo, manipularlo y mantenerlo.

Por un lado nosotros podemos diseñar y crear nuestra propia base de datos para trabajar con ella y en otros casos puede que nos toque interactuar con una base de datos diseñada por otra persona, pero basada en el modelo relacional. Tanto en nuestros diseños como en la manipulación de cualquier base de datos correspondiente a este modelo debemos seguir ciertas reglas, o podríamos cargarnos todo el modelo y con el tiempo este podría quedar insostenible, incongruente, redundante, atomizado y nos arrastraría a tener que diseñar una nueva base de datos. Y es que una DB bien diseñada y en la que se respete su estructura y las reglas citadas, no debería tener problemas nunca, salvo su tamaño en algún determinado momento de su vida o duración. Y en esto además de reglas específicas también nos aporta el RDBMS y el diagrama Entidad – Relación al no permitirnos (en criollo “meter la pata hasta el fondo”) desobedecerlas.

 

Diagrama del proceso de creación de una base de datos y sus requerimientos.

Como siempre, te aporto mis humildes diagramas para que comprendas mejor todo lo que estoy diciendo y logres ordenar estos conocimientos en tu cabecita. Y fíjate que también te permite tener un orden mental de lo que estás aprendiendo.. En este caso, veremos esos requerimientos que son explícitos, que están escritos por personas que quieren que no comentamos errores graves con el manejo de la información. Luego, cada paso del procedimiento de crear una base de datos consiste en respetar y tener en cuenta estos requerimientos explícitos y también los implícitos de cada software utilizado, entre otros.

 

Requerimientos bases de datos relacionales

 

 

Reglas y requisitos a la hora de trabajar con el modelo relacional.

Y ahora, esto es importantísimo!!. Aunque no entiendas mucho aún, intenta leer, investigar y comprender estas reglas, requisitos y características que debe cumplir una base de datos relacional bien diseñada!.

 

Las 12 reglas de Codd para el modelo relacional.

Recordarás que Edgar Codd es el creador del modelo relacional, este tipo vino a cambiar las cosas, pero al ver que muchos programadores y diseñadores de las bases de datos cometieron errores y eran muy cochinos, decidió solucionarles la vida una vez más especificando una docena de reglas que determinan un modelo relacional exitoso. Y nos evita futuros problemas de inconsistencia, redundancia y dolores de cabeza o llamadas de la vecina de la suegra de la tía de tu ex novia (para que veas lo molestas que se pueden volver las relaciones ^^).

 

Las 12 reglas resumidas y explicadas con palabras terricolas, dicen así:

  1. Información: En el modelo relacional toda la información de la base de datos debe estar representada explícitamente en el esquema lógico. (Nada de datos ocultos o “escondidos, implícitos, etc.”. Toda la jodida información debe estar en la base de datos.)
  2. Acceso garantizado: En el modelo relacional todo dato debe ser accesible conociendo el valor de su clave primaria y el nombre de la columna (Atributo) que contiene el dato. Con esto queremos decir que no deben existir datos sin claves ni atributos que garanticen su rápido y fácil acceso.
  3. Tratamiento sistemático de valores nulos: El sistema de bases de datos debe permitir el tratamiento adecuado de los valores “null” y estos deben estar presentes en aquellos atributos no especificados. Además de especificar correctamente cuales permiten valores “null” y cuáles no. Por ejemplo, es obvio que no deberías jamar permitir valores nulos en un atributo que es clave primaria, porque en ese caso estarías no solo violandote esta regla sino también las dos anteriores, en el caso que luego quisieras acceder a ese dato. ¿Cómo carajos lo ibas a hacer si la clave primaria es “null?. Codd volverá de la tumba y te jalara de los pies!
  4. Catálogo en línea basado en el modelo relacional: Esta regla refiere a que todos los datos del modelo deben soportar un catálogo basado en relaciones que le permitan al usuario acceder a la estructura relacional total del modelo. El usuario autorizado debe poder ver completa la estructura de las relaciones entre los datos!
  5. Sublenguaje de datos completos: el modelo debe contar con un sublenguaje capaz de manipular los datos de la base de datos. Este debe permitir realizar operaciones. Recuerdas que hablamos de que antes los programadores debían desarrollar un lenguaje aparte para administrar los datos, pues en este caso se utiliza SQL que veremos más adelante.
  6. Actualización de vistas: una vista es una tabla cuyo contenido has sido generado por una consulta de un usuario, un resultado.. por ejemplo “Muéstrame los nombres de los profesores de la tabla profesores”. Esta vista debe mostrar la información más actualizada siempre.
  7. Inserciones, modificaciones, eliminaciones de alto nivel: Cualquier operación de este tipo, ya sea modificar, insertar, eliminar datos o registros debe ser en conjunto de filas o registros y no registro a registro. Con esto queremos decir que si queremos modificar el atributo “año” de todos los alumnos debemos hacerlo mejor en conjunto mediante una sentencia y no uno por uno como unos capullos. Al igual que si quisiéramos eliminar un registro, tabla, etc.
  8. Independencia física: Los datos deben poder ser accesibles desde la lógica de la BD aun se modifique el almacenamiento físico de la misma.
  9. Independencia lógica: Los programas no deben verse afectados por cambios en los datos de la base de datos. La base de datos es independiente del programa de gestión o software que la consulte. No podemos utilizar la base de datos para almacenar código o variables vitales para el funcionamiento de un programa, ya que si son borrados dejaría de funcionar. Esto es bastante obvio, y de hecho es una gran ventaja que el tratamiento de los datos sea independiente del sistema o software que los gestiona.
  10. Independencia de Integridad: Las reglas de integridad deben almacenarse en la base de datos (en el diccionario) y no en los programas de aplicación. Es obvio que quien especifica la integridad de los datos es la base de datos, no el programa que la consulta!!
  11. Independencia de la distribución: Anteriormente en otro post te dije que las bases de datos pueden estar distribuidas, una misma base de datos puede estar fragmentada y alojada en diferentes servidores para algún propósito en específico como mejorar la velocidad de acceso, etc. Pues, esta regla hace hincapié en que para el usuario que visualiza la base de datos esta debe mostrarse íntegra a pesar de estar fragmentada!. Al igual que cuando se distribuyen los datos lo hacen por todo el sistema..
  12. No subversión: Si un sistema relacional tiene un (solo registro a la vez) de bajo nivel de lenguaje, ese bajo nivel no puede ser utilizado para subvertir o pasar por alto las reglas de integridad y las limitaciones expresadas en el lenguaje relacional de alto nivel. Se refiere a violar las reglas de integridad y limitaciones de SQL mediante otro lenguaje, etc.. Lo que podría causar estragos..

 

Estas reglas las debes respetar!. Y no son las únicas, existen diversos requisitos a cumplir a la hora de trabajar con el modelo relacional!

 

Requerimientos, características de transacciones : ACID

 

IMPORTANTE: Toda base de datos debe cumplir estos requerimientos!
Los requisitos ACID deben ser cumplidos por toda base de datos relacional con la que trabajemos. Es importante que lo comprendas a fondo, cada jodida palabra!.

Transacción: Interacción con una estructura de datos compleja que está compuesta un conjunto de órdenes o instrucciones que se ejecutan una después de la otra, de una sola vez.

Podemos en un principio (porque estamos recién comenzando con bases de datos) pensar en una transacción “como un cambio mediante una instrucción o sentencia”. 🙂

Las características ACID son un requerimiento muy normal a la hora de pensar en cambios de datos dentro de bases de datos mediante transacciones, no cumplirlos implica grandes conflictos que normalmente no son de fácil solución.

Sin embargo la mayoría de los RDBMS mediante el lenguaje DCL (Lenguaje de control de datos ‘SQL’) cumplen con estos requerimientos y nos obligan a cumplirlos.

Estos son:

 

Atomicidad

La palabra se puede usar para referirse a agrupar, unificar. La atomización de la información consiste en tratarla como un conjunto, no cumplir la atomicidad de información sería como el ejemplo brindando cuando explique el modelo relacional, como tener todos los datos regados por todas partes dificultando su comprensión. Pero en este caso también refiere a las transacciones que se realiza con los datos.

Mediante el lenguaje SQL podemos realizar consultas, transferir, manipular, añadir, actualizar lo que se conoce como TRANSACCIÓN. Cada ejecución que implique una modificación de datos en nuestra DB.

Cumplir el principio de atomicidad significa realizar esas transacciones u operaciones en forma de conjunto (“Todas o Ninguna”),. O se ejecutan todas, o ninguna.

meme delete sin where

Suponiendo tenemos que actualizar diversas columnas de nuestra base de datos mediante una transacción y se produjera un error en una sola de ellas, nuestra base no debería sufrir ningún cambio. Por más que sea solo en una.. En caso contrario, que la transacción completa se pudiera ejecutar sin errores, entonces si, se ejecuta completa y se aplican los cambios!

Con esto queremos decir que si tienes un error en una línea de una transacción en SQL, no pasará nada.. No vas a arruinar todo. Ahora el problema surge cuando la transacción está mal diseñada, pero no contiene errores :B.

El clásico “Delete sin Where” (eliminar sin ninguna condición).. Es un meme.. Y fíjate, si haces un delete sin where pero surge algún error, no se ejecuta. Y la atomicidad propiedad de SQL y el RDBMS te salva las papas!!

 

Consistencia

La consistencia puede verse como “cualidad de estable, coherente“. Y este requerimiento implica que cada modificación de nuestra base de datos debe asegurar la consistencia llevando la base de datos de un estado “valido” a un estado “valido“. Cualquier dato modificado, añadido, borrado debe ser de acuerdo a todas las reglas y requerimientos definidos para nuestra base de datos.

 

Aislamiento (Isolation)

El aislamiento implica que cada transacción se debe ejecutar de forma simultánea (una tras otra) de tal manera que el estado intermedio de una transacción no sea visible por otra y de esa manera se mantengan aisladas unas de otras. Lo cual podremos ver en profundidad más adelante a la hora de trabajar con transacciones en SQL!

 

Durabilidad

La durabilidad significa que una vez que se confirmó una transacción (commit), quedará persistida, incluso ante eventos como pérdida de alimentación eléctrica, errores y caídas del sistema. Por ejemplo, en las bases de datos relacionales, una vez que se ejecuta un grupo de sentencias SQL, los resultados tienen que almacenarse inmediatamente (incluso si la base de datos se cae inmediatamente luego). Esto nos asegura que si la transacción fue realizada los cambios fueron guardados de forma persistente en la base de datos a pesar de posibles errores externos surgidos luego de aplicarlos.

R.DBMS
La mayoría de los RDBMS y lenguajes de manejo de datos como SQL cumplen con estos requisitos. Pero es importante tenerlos en cuenta a la hora de realizar transacciones para comprender su funcionamiento y elaboración.

Finalmente nos resta por conocer el famoso “concepto de normalización”.

 

Normalización en bases de datos relacionales

La normalización consiste en aplicar y designar un conjunto de reglas a las relaciones obtenidas luego de pasar nuestro Diagrama de Entidad Relación, al modelo relacional y estructurar nuestra base de datos en el RDBMS elegido.

Que justamente es lo que haremos en la siguiente entrada, no por nada te estoy torturando con toda esta información!!.

 

equerimientos RDBMS normalización

Es ese paso intermedio entre diseñar nuestra base de datos en un diagrama y hacerla “realidad” para trabajar con ella.

Pero considero mejor, verlo en profundidad en otra entrada aparte, en su debido momento!. Pero si por tu parte quieres explorarlo para tener guardados todos estos conceptos en tu mente y poder tenerlos presentes a la hora de la verdad. Puedes leer sobre ello en la Wikipedia!

Normalmente..
Dentro del concepto de normalización se suelen incluir las reglas de Codd que te mencione anteriormente!

Probablemente el proceso de NORMALIZACIÓN SEA AÑADIDO AQUÍ PRONTO.

 

Alumno al profesor: Eres vulgar y te odio.Y esto ha sido todo por ahora, se que es algo duro y difícil de entender. Intenté hacerlo lo más simple y completo posible.

Pero date tiempo, a medida que avances comprenderás mucho mejor todos estos conceptos y de hecho los voy a recalcar cada tanto sea necesario. No te asustes que los estoy plasmando aquí también como una referencia, más no quiere decir que debamos “memorizar” cada regla y concepto. Para ello existe Google, además de para espiarnos y clasificarnos como conejillos.

Nos veremos en la siguiente entrada donde, por fin. Podremos empezar a “rockear” y ya basta de tanta teoría aburrida.

 

Abrazo!

 

 

Compartir es agradecer! :)