Introducción a las bases de datos

Las bases de datos también conocidas como bancos de datos no son necesariamente digitales. Una biblioteca es una base de datos compuesta por documentos y textos impresos almacenados en estanterías e indexados y catalogados para su consulta.

 

Actualmente estas bases de datos pueden estar digitalizadas completamente. Los documentos y libros pueden digitalizarse y almacenarse en discos duros en algún servidor y es posible desarrollar software que permita a los usuarios de forma presencial en una biblioteca o de forma remota desde
sus casas (por ejemplo) realizar consultas a los documentos o libros que quiere.

 

La tecnología permite esto pero por el contrario las leyes de los diferentes países en materia de copyright no permiten que esto pueda hacerse de forma legal sin miles de trabas y mucho trabajo.

 

En el caso de una Hemeroteca donde consultar prensa esta muchas veces es parte de una biblioteca pero muchas otras veces este archivo le pertenece en exclusiva al periódico que publica.
Hoy en día estas Hemerotecas están digitalizándose y es posible acceder a ellas desde casa mediante una conexión a internet.

 

Estas bases de datos por tanto tienden a digitalizarse ya que esto permite ahorrar costes y muchísima comodidad para buscar lo que se quiere.

 

Tipos de bases de datos

 

Las bases de datos se pueden separar por tipos y estas separaciones dependen de las características de las bases de datos.

 

Nos encontramos por ejemplo con bases de datos estáticas y con bases de datos dinámicas y esta separación se realiza analizando la variabilidad de los datos.

 

Una base de datos estática es la que simplemente almacena datos que no van a variar y que permiten ser consultados pero no tiene sentido actualizarlos. Un ejemplo puede ser una biblioteca.
Existen diferentes libros y en caso de una nueva edición de uno en especial este aparecerá como versión de 1932 o versión de 1988. Ambos serian datos estáticos y el libro en realidad seria diferente (contendría cambios).

 

En el caso de bases de datos dinámicas son las que sus datos son muy cambiantes permitiendo operaciones como borrado, edición, etc.
Un ejemplo pueden ser los productos de un supermercado en venta. Productos que cambian de nombre, cambian de precio, se dejan de vender, etc.

 

Estas bases de datos sirven para consulta pero al mismo tiempo son bases de datos dinámicas que podemos ir alterando. Los precios de los vuelos por ejemplo lo mismo.
También es posible encontrar diferentes tipos si nos centramos en la característica de la forma en la que se almacenan los datos. A esto se le llama “modelos de bases de datos”.
Estos modelos pueden ser:

 

  • Bases de datos jerárquicas
  • Base de datos de red
  • Bases de datos transaccionales
  • Bases de datos relacionales
  • Bases de datos multidimensionales
  • Bases de datos orientadas a objetos
  • Bases de datos documentales
  • Bases de datos deductivas

 

Las bases de datos jerárquicas pueden ser por ejemplo cuando organizamos por directorios nuestros documentos en un sistema de archivos.

 

Podemos crear un directorio llamado libros, dentro de libros crear muchos directorios llamados por ejemplo “misterio, romántica, ciencia, idiomas, química, humor, …”  y dentro de estos otros sub-directorios llamados por ejemplo “español, inglés, chino, francés, …”.

 

Esta forma de organizar estos datos es bastante problemática ya que es posible que tendremos el problema de la redundancia de datos. Un libro por ejemplo que sea de romántico y de misterio estará 2 veces en diferentes niveles de la jerarquía.

 

El resto de modelos no nos interesan salvo el de bases de datos relacionales. Estas son las bases de datos que vamos a utilizar.

 

Bases de datos relacionales

 

Existe un buen articulo sobre esto en wikipedia que podéis consultar si queréis:
https://es.wikipedia.org/wiki/Base_de_datos_relacional
Aquí simplemente vamos a hablar un poco en forma de resumen de que tiene de especial este modelo de bases de datos y los motivos por los que es el modelo más usado.
Para entender el modelo relacional vamos a partir de un ejemplo en el que previamente analizamos las relaciones entre los datos para poder diseñar previamente una estructura.
En el caso de los libros de una biblioteca usando el modelo jerárquico tenemos problemas con la redundancia de datos. En el caso de analizar las relaciones vamos a ver que esto no ocurre si no queremos.
Partimos de la base de que todo en la biblioteca son textos pero estos pueden ser de por ejemplo estos tipos: periódicos, revistas y libros.

 

Apuntamos en una hoja la palabra tipos y seguimos analizando que estos pueden estar en diferentes idiomas (independientemente del tipo) de modo que añadimos en la hoja la palabra idiomas.

Estos idiomas podrían ser por ejemplo: Inglés, esperanto, francés, castellano, gallego, catalán, …
Nos encontramos con que todos los textos dando igual el tipo o el idioma se pueden ordenar en categorías. Apuntamos por tanto la palabra categorías en nuestra hoja.

Esas categorías podrían ser por ejemplo: Terror, comedia, teatro, ensayo, poesía, misterio, literatura técnica, manuales, …
Ahora nos fijamos en que en la biblioteca los libros viene gente a llevárselos de modo que tenemos que fichar a la gente. Esto se hace haciendo carnets de la biblioteca y por tanto anotaremos usuarios a nuestra hoja.
Existen muchas más relaciones pero simplemente vamos a abstraernos y anotaremos una última llamada estados. Los libros pueden tener varios estados en la biblioteca: perdido, disponible, no-disponible.

Esto nos lleva a tener esto anotado en nuestra hoja de papel:

  • – Textos
  • – Tipos
  • – Idiomas
  • – Categorías
  • – usuarios
  • – estados

 

Y ahora podemos ir desarrollando que contenidos hemos de añadir en cada una de estas relaciones y
lo vamos a hacer como si fuese una tabla con columnas.

 

seleccion_001

seleccion_002

seleccion_003

Si nos fijamos sobre todo en esta última tabla nos damos cuenta que en ella vamos añadiendo el ID de lo que hemos definido en otras tablas. Por ejemplo el libro babilonia sabemos que es un libro por que en tipo tiene un 2 y si miramos en la tabla de tipos veremos que el 2 es para libros.

 

En el caso del mismo libro nos fijamos que vamos añadiendo el ID de otras tablas para la categoría, el estado, el idioma, etc.Esto nos permite por ejemplo hacer consultas y de esta forma obtener información como por ejemplo si el libro esta disponible o no lo esta. Podemos buscar solamente por libros que estén en castellano o solamente en la categoría aventura.

Estas relaciones y esta forma de organizar en tablas la información nos permite no duplicar datos constantemente. Si deseamos el día de mañana añadir una nueva categoría podemos hacerlo sin problemas. Se añadiría a esa tabla una nueva categoría y los libros que entren en esa categoría se
empezarían a añadir a la base de datos seleccionando esa categoría.

Este tipo de relaciones y lo que hemos realizado a boli primero sobre un papel son la forma de diseñar como será nuestra base de datos relacional. Hemos estado analizando la forma en la que queremos organizar los datos basándonos en las posibles relaciones pero se nos ha olvidado que lo
mismo queremos obtener también quien tiene un libro en un momento dado.
Esto seria crear una nueva tabla llamada por ejemplo “prestados”.
En esa tabla añadiríamos algo así como esto:

 

seleccion_004

 

En este caso vemos que el texto prestado es el 2 y podríamos mirar en la tabla de textos para ver a que categoría pertenece (mirando a su vez en la tabla categorías) y ver el nombre del libro.

Cada vez que alguien se lleva un libro de la biblioteca una persona indicaría quien se lo lleva y este pasaría a la tabla de prestados y en la tabla de textos se cambiaría el estado del libro.

De esta forma podemos hacer una consulta a la tabla textos para saber que libros/revistas/periódicos están prestados actualmente. Podríamos imprimir ese resultado y tendríamos los libros que han sido prestados pero no a quien se ha prestado.

No importa ya que es posible realizar consultas cruzadas e ir sacando más datos de modo que si que podríamos saber e incluso sacar un listado con los libros prestados y a su vez a quien y cuando se han prestado. Si en la base de datos de usuarios tuviésemos un campo con el teléfono podríamos
llamar a esas personas para avisarles de que han de entregar los libros o de lo contrario se formalizará automáticamente una multa con su nombre, apellidos, dni, …

Lo importante de este modelo es que no importa donde almacenemos la información o como ya que la vamos a recuperar mediante consultas.
El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.

Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.
Durante los años 80 la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.

 

 

Actualmente un software para gestión de bases de datos muy utilizado es MariaDB. Mucha gente conocerá esto por el nombre de Mysql server pero hemos de añadir que MariaDB es el fork libre realizado por su autor y que actualmente es lo que se usa en las comunidades de software libre.

Las diferencias frente a mysql no son muchas y al final de cuentas utiliza SQL como lenguaje para realizar las consultas.
Esto va a ser lo que vamos a ver. Como montar un servidor de bases de datos (que nos permita gestionarlas) y como empezar a administrar estas y realizar consultas.

 

Normalización de bases de datos

El proceso de normalización de una base de datos es un proceso en el que aplicamos una serie de reglas para entre otras cosas:

 

  • – Evitar la redundancia de los datos.
  • – Disminuir problemas de actualización de los datos en las tablas.
  • – Proteger la integridad de los datos.

 

Estamos diseñando las tablas y para esto es bueno pensar en que deseamos obtener. Podemos crear tablas con las relaciones como hemos realizado y en el proceso de normalización tener en cuenta que datos deseamos obtener.

 

Es un momento en el que tenemos que pensar en consultas posibles que nos ofrezcan los datos que deseamos y comprobar si con las tablas que tenemos esto es posible.
En el proceso de normalización vamos a buscar sobre todo errores y duplicidad de datos.
Las tablas han de tener todas una columna clave. Normalmente para que esto suceda en todas las tablas se suele poner (no necesariamente) una columna llamada id para identificar los datos.
Esa columna clave no necesariamente tienen que ser números correlativos pero es muy normal que
esto se haga así para evitar problemas.

En el supuesto caso de una tabla donde almacenamos los usuarios de la biblioteca que se han registrado podríamos usar la columna DNI en vez de crear una columna llamada id_usuario (por ejemplo). Sabemos que no pueden existir 2 personas con el mismo número y letra de DNI pero lo
cierto es que quizás el DNI no lo solicitamos obligatoriamente y por tanto esa columna no valdría ya que algunos usuarios podrían no tener DNI.

 

Puede darse el caso de una tabla de usuarios donde tengamos un campo llamado edad y otro llamado fecha de nacimiento.
En el proceso de normalización de la base de datos esto es un error. Con saber la fecha de nacimiento podemos sacar en cualquier momento la edad de modo que es un dato que no necesitamos.

Analizaremos por tanto todas las tablas para ver que datos son necesarios, que datos podemos deducirlos a partir de otros y sobre todo evitar que existan tablas con datos duplicados.

Las claves primarias no necesariamente son una columna. Es posible usar varias columnas para generar una clave primaria que nos sirva de identificador. Un ejemplo es usar en una tabla de usuarios las columnas “nombre, apellido1, apellido2, fecha de nacimiento, localidad”. La probabilidad de que existan en nuestra tabla personas que se llaman igual, tienen los mismos apellidos, han nacido el mismo día y viven en la misma localidad es muy
poca.

 

Este riesgo de duplicidad podría asumirse en casos donde por ejemplo el listado de personas
será muy reducido y la probabilidad de que ocurriese una duplicidad es improbable.
Usaríamos todas esas columnas como identificativo sin precisar por tanto de una columna llamada
id.
En el proceso de normalización vamos a tener en cuenta estas cosas y a analizarlas. Es muy
importante que el acceso a los datos este garantizado en nuestras búsquedas.

 

Cuando alguien (ya sea humano o sea software) realice una consulta a la base de datos partiendo de
un nombre de tabla, el valor de la clave primaria y el nombre de la columna requerida tendría que
obtener solamente un valor. Si se encuentra con más de un valor es que la cosa ha ido mal y esto es
un error al diseñar la clave primaria seguramente.

Si por ejemplo tomásemos como clave primaria el DNI y por error alguien metiese el mismo que el
de otra persona la consulta retornaria 2 datos en vez de 1. Esto supondría un error.

Las consultas tendrían que poder leer, escribir, eliminar y agregar registros (SELECT, UPDATE,
DELETE e INSERT en SQL). En el proceso de normalización de la base de datos analizaremos en que casos se precisan todas las que sean distintas a select para ir diseñando que tipos de usuarios se
van a necesitar.

Ningún componente de una clave primaria puede tener valores en blanco o nulos (ésta es la norma básica de integridad).

Si se diese el caso de que usásemos el DNI como clave primaria en una tabla es posible que si un
usuario no añade el DNI o la aplicación que introduce los datos estuviese mal programada (permitiendo por ejemplo no meter el DNI como requerimiento) tuviésemos un campo null. Esto no sucedería si se usase un identificativo o clave primaria que no dependiese de los campos que rellena un usuario.

Deja un comentario