Curiosidades sobre bases de datos

En este artículo vamos a hablar un poco acerca de lo que son las bases de datos, y específicamente nos vamos a centrar en explicar en qué consiste el modelo de entidad relación, o modelo relacional, y cuál es su vínculo con el desarrollo de las bases de datos. Para ello vamos a mencionar 5 curiosidades sobre bases de datos. Los temas que vamos a estar tratando en este artículo, son los siguientes:

Curiosidades sobre bases de datos – índice

1. Las bases de datos como bibliotecas
2. Organización de una base de datos
3. ¿ Cómo se crea una base de datos ?
4. ¿ Qué es un modelo ?
5. Ejemplo de un modelo

1. Las bases de datos como bibliotecas

biblioteca imagen.

imagen del artículo.

Hay muchas maneras de explicar qué es una base de datos, y quizás la más común de ellas sea acudir a su definición técnica o formal. Sin embargo, en este post vamos a responder a esa pregunta con un ejemplo sencillo y fácil de comprender.

Una base de datos es un lugar en donde se almacena información para luego utilizarla. Imagínense como ejemplo una biblioteca. En un lugar como ese existen decenas de miles de libros de diferentes autores, que tratan sobre los temas más variados. Puedes buscar un libro específico, leerlo, e incluso podrías donar tus propios libros a la biblioteca, con lo cual la institución se beneficiaría, ya que aumentaría la información disponible para sus lectores.

Viendo las cosas desde este punto de vista, podríamos pensar que una biblioteca es como una base de datos, ya que es un lugar en el cual se almacena información periódicamente (año a año se compran o se donan libros, con lo cual crece su inventario), al tiempo que dicha información también puede ser consultada con frecuencia (es decir, el público en general puede acceder a ella en busca de un libro específico para leer).

2. Organización de una base de datos

Los datos de una base necesitan estar bien organizados y estructurados, ya que eso facilita su consulta y almacenamiento posterior.

Siguiendo con nuestro ejemplo de la biblioteca, la misma se suele organizar en estanterías (puede que estén ordenadas alfabéticamente), las cuales a su vez contienen filas y filas de libros. Dentro de cada libro se encuentran los textos a consultar. En el caso de las bases de datos, lo más común es que se organicen en lo que se conoce como tablas. Las tablas son conjuntos de registros que tienen características en común, lo que hace que puedan ser agrupados en ese conjunto. Podríamos hacer una analogía entre una tabla de una base de datos, y un libro. Un libro trata sobre un tema específico, por lo tanto cada una de sus páginas (siguiendo con la analogía, las páginas serían como los registros de una tabla) contiene información sobre una misma temática, y además respeta un único formato (tipo y tamaño de letra por ejemplo), ya que todas ellas pertenecen al mismo libro. Algo similar sucede con las tablas en una base de datos.

3. ¿ Cómo se crea una base de datos ?

El desarrollo de una base de datos depende del contexto en el cual se crea. No es lo mismo diseñar una base de datos para almacenar estadísticas de fútbol, que una base de datos para manejar datos de historiales de pacientes en un hospital. La información a ser persistida es totalmente diferente en un caso u otro, y por lo tanto se necesita analizar cada caso en particular para conocer cuáles son los elementos que se van a representar (si son futbolistas o pacientes) en la base de datos, sus características, etcétera. Para poder llevar a cabo este análisis, es necesario crear un modelo que nos permita en primer lugar diseñar la base de datos antes de desarrollarla.

4. ¿ Qué es un modelo ?

Modelar significa crear una representación abstracta de la realidad. La representación en sí misma (denominada modelo) suele ilustrarse en forma de un esquema o dibujo, el cual varía según el propósito por el cual se desea modelar. Para el caso particular del diseño de bases de datos, se suele utilizar el llamado Modelo Relacional, o Modelo de Entidad-Relación (abreviado a través de su sigla MER).

Primero se hace un análisis en detalle de cómo es la realidad que se quiere representar, tratando de extraer cuáles son sus principales características. Luego estas características son plasmadas mediante papel y lápiz (o una buena herramienta informática de diseño de modelos) en un modelo relacional, que posteriormente servirá como ayuda o paso previo para la creación de la base de datos.

5. Ejemplo de un modelo

Supongamos que por algún motivo que se desconoce, necesitamos desarrollar un programa para gestionar información sobre todos los libros del mundo. Primero que nada debemos tener conocimientos suficientes sobre las propiedades de los libros. Recurriendo un poco a nuestro sentido común y conocimiento general, podríamos partir del supuesto de que un libro tiene un título, un autor, y en todo caso podría tener información sobre la cantidad de páginas, la editorial, y su número de serie. Todos estos elementos que acabo de mencionar (título, autor, cantidad de páginas, editorial, serie) son atributos del libro. Podemos asumir entonces que todos los libros del mundo comparten este conjunto de atributos. Ahí es donde surge el concepto de la entidad (o más técnicamente hablando, la Clase) Libro.

Clase Libro

Modelo para representar a la entidad Libro.

Por lo general, en el diseño de bases de datos, las entidades se terminan transformando en tablas de la base de datos, por lo que en este ejemplo, la entidad Libro va a tener su propia tabla en nuestra base de datos (llamémosle la Tabla Libro). Una tabla en donde se va a guardar un registro por cada libro que existe en el mundo.

Sin embargo, mi libro (por más que se trate del mismo título) no es el mismo que el que tienes tú en tu casa, ni tampoco es el mismo libro que aquél que tiene José, que lo compró en otra librería, y por lo tanto al ser una copia distinta de la que tenemos nosotros, su libro tiene otro número de serie. Diremos entonces, que tanto tu libro, como el mío y el de José, son instancias de la clase Libro, y que cada una de ellas será almacenada como un registro diferente en la tabla Libro de la base de datos.

No quiero seguir siendo repetitivo ni redundante, pero déjenme agregar una nueva suposición a este ejemplo: supongamos que, además de almacenar los datos de todos los libros, se necesita también registrar la información de las personas a las cuales pertenecen. Al hacer esto, nos vemos obligados a agregar una nueva entidad, a saber, la clase Persona. Y aquí es donde tenemos que comenzar a deducir cuáles serían los atributos de una persona que son necesarios o importantes para almacenar en nuestra base de datos (podría ser el nombre, la edad, su identificación, su grupo sanguíneo tal vez ?, etcétera).

Clase Persona

Modelo para representar a la entidad Persona.

En este punto tenemos dos entidades o clases: la entidad Libro y la entidad Persona. Ahora, ¿ Cómo dejamos registrada la información de cuáles son los libros que posee una persona ? Para eso no nos alcanza con tener solamente dos entidades separadas. Vamos a tener que definir entonces una relación entre ambas entidades. Una relación es aquello que se encarga de vincular dos entidades entre sí, y existen muchos tipos de relaciones, dependiendo de cuál es la naturaleza de ese vínculo. Supongamos que existe en el mundo una ley que dice que una persona no puede tener en su posesión más de un libro a la vez. Es obvio que tal ley no existe, pero supongamos que es cierto solo para entender el ejemplo. En ese caso, la relación Persona-Libro sería una relación N a 1 (también se suele decir muchos a uno, o many to one en inglés), esto se puede expresar como: N personas pueden tener a lo sumo 1 solo libro cada una. La mejor forma de representar esto sería definir un identificador de libro directamente como un atributo más de la entidad persona. Si además nos dijeran que en la realidad que está siendo objeto de estudio, toda persona tiene que tener sí o sí un libro, entonces sería conveniente fijar como obligatorio el atributo identificador de libro en la entidad Persona (lo que significa que el atributo no puede quedar vacío o sin valor, o lo que es lo mismo no existe una persona que no tenga libro).

N a 1

Modelo para representar a la relación N a 1 entre Persona y Libro.

Sin embargo, esto en la vida real no es así. Por lo general no existe restricción alguna sobre la cantidad de libros que cada persona puede poseer, escenario en el cual se tiene una relación de tipo 1 a N (uno a muchos, o one to many), que puede entenderse como: una persona puede tener N libros diferentes, y cada libro a su vez está asignado a una sola persona. En esta situación resulta conveniente agregar un atributo más a la entidad Libro que sea un identificador de la persona que lo posee. Podría incorporarse además (si es que tiene sentido para la realidad analizada) la restricción de que no es posible que exista un libro sin dueño, ante lo cual se debería establecer como obligatorio el atributo identificador de persona dentro de la entidad Libro.

1 a N

Modelo para representar a la relación 1 a N entre Persona y Libro.

Vayamos ahora a un caso más realista que este: supongamos que cada persona puede tener en su propiedad más de un libro, pero que cada libro puede ser compartido por más de una persona. Suena como si dos personas se pusieran de acuerdo en comprar un libro a medias, y lo utilizaran la mitad del tiempo cada uno. En esta situación, nos encontraríamos frente a una relación Persona-Libro de tipo N a N (muchos a muchos, o many to many), que a grandes rasgos significa: cada persona puede tener N libros, y cada libro a su vez puede ser asignado a (o compartido por) N personas. Este tipo de relaciones se suele modelar como una entidad nueva que representa a la misma relación (llamémosle entidad Persona-Libro), en donde se agregan dos atributos: un identificador de persona, (que hace referencia a uno de los propietarios del libro), y un identificador del libro, (que menciona a uno de los libros que esta persona “comparte” o “posee”).

N a N

Modelo para representar a la relación N a N entre Persona y Libro.

La realidad que se está analizando en este ejemplo es siempre la misma. Lo que varía es el modelo con el cual se representa a la hora de almacenar su información. Eso depende de cómo se interpreta la realidad a modelar, de cómo entendemos que son las relaciones entre las entidades, y de cuáles son los requerimientos que se nos solicitan a la hora de modelar. Si existen tantas variantes posibles de atributos y relaciones para representar una realidad sencilla en donde solo hay dos entidades (en este post se mencionan personas y libros solo para fijar ideas, pero bien podría tratarse de otra pareja de entidades cualesquiera), imagínese lo complejo que sería modelar escenarios del mundo real, en donde se suelen tener mucho más que solamente dos entidades y una relación.

Sin más nada que escribir, me tengo que retirar. Tengo que leer mi libro favorito.