Introducción a Bases de Datos

Introducción

En estos tiempos, con las modernas aplicaciones informáticas que existen hoy en día, los programadores en ocasiones olvidamos que tanto los propios ordenadores como los programas que ejecutan sobre ellos no son más que procesadores de datos, procesadores rápidos, pero procesadores a fin de cuentas.

Los programas en realidad recojen datos del usuario, de archivos en el ordenador, de la entrada de los periféricos y los transforman para producir otros datos. Una aplicación como el photoshop por ejemplo recoje los datos almacenados en forma de bytes en un fichero y permite al usuario mediante la introducción de toda una serie de datos modificarlos para crear otra imagen distinta. La tarjeta gráfica transforma una serie de datos en forma de stream de bytes en secuencias de 24 bits que a su vez el monitor transforma en pixels en la pantalla.

No obstante, en la actualidad cuando se habla de bases de datos, casi siempre se está haciendo referencia a sistema informáticos y más concretamente a los sistemas de gestión de bases de datos como Oracle o MySql.

Base de datos y SGBD

Como he mencionado anteriormente en realidad (aunque en la práctica no suela ser así) debemos hacer una diferenciación entre base de datos y sistema de gestión de base de datos (SGBD).

El concepto de base de datos es el explicado anteriormente y responde a cualquier almacen de datos que, en el ámbito de la informática, da soporte a una determinada aplicación (o a varias). En cambio un SGBD consiste en un sistema completo que se encarga de gestionar (entendiendo gestionar como servir, modificar y mantener los datos) una base de datos.

A efectos prácticos ambas cosas son lo mismo. Hoy en día no tiene sentido hablar de una base de datos (si no somos muy puristas) sin ningún tipo de organización ni, en realidad, cabe imaginarsela sin un sistema de consultas SQL.1

Diseño de bases de datos

Introducción

Evidentemente, aunque una aplicación consuma datos de una forma muy rápida dada la velocidad de ejecución de los procesadores actuales, no es lo mismo buscar una referencia sobre Trotsky en una biblioteca donde (antiguamente) consultabas al bibliotecario y el te indicaba que Trotsky estaba situado en la sección de pensadores rusos de principios del siglo XX, estantería 1C sección 34T que hacerlo sobre una pila de libros sin ordenar apilados sobre un escritorio.

El diseño de bases de datos abarca varias aspectos de la creación de una base de datos y puede referirse tanto al diseño de la estructura de los datos como al diseño del software que mandrendrá esos datos. El primer caso suele ser al que nos refiramos en el 95% de las ocasiones mientras que el segundo nos interesará en las pocas ocasiones en las que estemos diseñando o manteniendo un SGBD (y en pocas ocasiones más).

Nivel conceptual, nivel lógico y nivel físico

En una base de datos suelen distinguirse tres niveles, desde el más alejado a los ordenadores y más cercano a los conceptos reales (el nivel conceptual) hasta el más cercano al punto de vista software pero que guarda poca relación con la conceptualización de los datos reales (el nivel físico).

El nivel conceptual modeliza la realidad que queremos captar. En toda base de datos existen unos datos reales que queremos capturar (personas, libros, posesiones, marcas de tiempos en carreras, estanterias), es decir, toda una serie de objetos del mundo real que queremos modelizar en nuestro ordenador. El nivel conceptual se dice que capta los conceptos y se "olvida" de como se representarán dichos conceptos en la base de datos, y es el primer paso en la creación de una base de datos. En el nivel conceptual uno se pregunta el qué. ¿Qué es lo que quiero representar? ¿Que partes de la realidad necesita conocer mi programa y cuales no? ¿Qué características tienen dichas partes de la realidad? ¿Qué relaciones hay entre dichas partes?.

La función del nivel lógico es aproximar el nivel conceptual a algo que el ordenador (y más concretamente un SGBD) pueda entender. Para ello se realizarán una serie de transformaciones sobre el modelo conceptual que nos permitirán obtener un modelo adecuado. Más de esto más adelante cuando veamos el paso a tablas.

Por último, por muy lógico que sea nuestro modelo, finalmente la información tiene que ser codificada en bits y almacenada en un soporte que el ordenador pueda entender. La CPU no entiende de tablas ni de conceptos, no entiende de nombres ni de caracteres, para un ordenador solo existen bits y cuando yo le digo que quiero saber la edad de Pepe debe haber un proceso que permita traducir desde mi lenguaje al suyo. El nivel físico describe la representación de los datos a nivel básico, es decir, el modelo que describe la forma de almacenar datos en el disco duro, la forma de recuperarlos, cuando deben pasar a RAM, cuando deben almacenarse en cache, etc, etc. Como ya he mencionado, esta parte es, en general, de poco interés práctico para todo aquel que no se dedique a la programación y diseño de SGBDs.

El modelo Entidad / Relación

Para hablar de bases de datos es importante hablar del modelo entidad-relación. Aunque existen muchos tipos distintos de sistemas de gestión de bases de datos (estandar, jerarquicas, orientadas a objetos, distrubidas ...) en la mayoría de ellas la información se almacena estructurada (de forma lógica) en forma de tablas y las relaciones que unen dichas tablas.

El model Entidad / Relación constituye una forma de representar conceptualmente la realidad basada en la representación de esta mediante su abstracción en entidades y relaciones. Una entidad representa un concepto del mundo real. No tiene porque ser un objeto físico (aunque en muchos casos lo es) sino que pueden ser conceptos tales como la situación del tiempo.

El modelo entidad relación está basado en, como su nombre implica, dos conceptos fundamentales, las entidades de un modelo así como las relaciones que se dan entre ellas, de esta forma intentamos representar el mundo que nos rodea, los datos de nuestro problema mediante una serie de entidades que representan objetos o conceptos así como las relaciones que se dan entre ellos tales como su uso, composición, etc.

Una de las propiedades interesantes del modelo es que resulta muy sencillo pasar de este a otros modelos, como por ejemplo el modelo relacional que es, a dia de hoy, el modelo de representación más extendido y utilizado para la representación lógica de datos.

El modelo relacional y las formas normales

El modelo relacional constituye el estandar a nivel lógico hoy en día. Su modelización matemática (y la consecuente formalización que ello conlleva) ha permitido al modelo relacional situarse como el más utilizado hoy en día gracias a la posibilidad de su verificación mediante procedimientos formales.

El modelo relacional organiza la información de acuerdo a relaciones entre la información. Cada relación se modeliza como una tabla que agrupa conceptos que están relacionados entre si. Así, por ejemplo, la tabla clientes agrupa datos de un cliente que están relacionados entre si. Cada entrada en la tabla, cada fila de la tabla, representa un conjunto de datos dado, en nuestro ejemplo anterior un cliente. Las columnas de la tabla son los atributos de los datos, esto es, caracteristicas de cada una de las entradas. Es más fácil ver esto con un ejemplo:

NIF Nombre Telefono de contacto Dirección
48399834-D Martín Inanaria 938766756 C/ Marea 23
53449982-N Alvar Ralnsis 913324432 C/ Dalí 31
64222123-A Garete Donovoan 92554332 C/ Gareth 23

Cada una de las columnas representa atributos de nuestro cliente, su DNI, su nombre, su telefono de contacto. Cada fila de la tabla representa un grupo de conceptos que tienen relación entre si, es decir, atributos en este caso de un mismo concepto.

¿Que es la clave de una tabla

Denominamos la clave de una tabla al conjunto de atributos de esta que determinan unívocamente cada entrada de la tabla. Es decir, aquellos atributos que determinan de forma absoluta el resto de los valores. Se ve facilmente con un ejemplo.

Pais Ciudad Dirección Sede Telefono Contacto
España Madrid Pº Extremadura 32 915586541
España Barcelona Puente de marfil 2 934483968
España Toledo Manel 17 925542321
Francia Paris Versalles 14 25542321

Aunque esta tabla sea bastante evidente, en realidad no lo es tanto, hay una serie de relaciones que damos por echas y que son: Pais, Ciudad -> Dirección Sede y Pais, Ciudad, Dirección -> Teléfono de Contacto por lo que la clave sería la tupla (Pais, Ciudad) ya que con eso obtenemos la dirección y con las tres anteriores el telefono por lo que el conjunto mínimo de valores que permiten determinar los demás será nuestra clave. Si no nos hubieran especificado dichas relaciones (o no fueran tan obvias) no podríamos deducir nada y la clave sería la combinación de los cuatro atributos.

¿Qué son las formas normales?

Cuando se habla de modelo relacional es necesario hacer también referencia a las distintas formas normales. Un modelo se dice que está en una determinada forma normal cuando cumple una serie de requisitos. Aunque voy a enumerarlas tanto formalmente como con una descripción textual conviene decir que en general la mayor parte de las bases de datos que se modelas se ajustan a la tercera forma normal (3FN). El cálculo de las formas normales es un proceso relativamente complejo, aquí daremos tan solo una descripción aproximada de las tres primeras formas normales.2

  • Primera forma normal (1FN). No hay campos múltiples.
  • Segunda forma normal (2FN). Una tabla está en segunda forma normal cuando está en primera forma normal y todos sus atributos no principales tienen dependencia funcional total con una clave. Explicado en lenguaje normal esto significa que cada uno de los atributos o bien forma parte de la clave o bien tiene una relación total con la clave al completo, es decir, la combinación única de los elementos de la clave determinan un solo valor para dicho atributo.
  • Tercera forma normal (3FN). Una tabla esta en 3FN cuando está en segunda forma normal y además cumple que todos sus atributos no primos dependen no transitivamente de la llave primaria. Es decir, en lenguaje un poco más llano cuando todos su elementos no primos dependen únicamente de los elementos de la clave (y no por ejemplo de otros elementos)

El nivel físico. Una pequeña introducción

Hasta ahora hemos estado hablando fundamentalmente de dos niveles de base de datos. El nivel conceptual y el nivel lógico. Estos dos niveles son los más próximos al usuario y los únicos que realmente le preocupan a la hora de acceder a los datos.

El nivel físico engloba la representación física a nivel bajo de la base de datos, esto engloba conceptos tales como la organización de la información en el disco duro, la organización de las estructuras de memoria, la gestión de los indices de la base de datos, gestión de transacciones y varios conceptos más.

Por si sola la descripción del modelo físico puede dar para uno o varios libros con detalles sobre técnicas de implementación que analizan entre otras cosas conceptos relacionados con la velocidad de acceso, protección frente a fallos, respuesta en situaciones de carga, etc

Algunas de las técnicas que se utilizan consisten en la creación de indices que permiten acceder rápidamente a determinados valores considerados comunes (por ejemplo es casi obligado la creación de un indice por cada clave de la tabla), el alineamiento de ciertos datos en el disco (por ejemplo asociando a cada dato un desplazamiento único que nos indique en que cluster exacto está el dato de forma que podamos ir directamente a la dirección indicada y recuperar el dato) o la implementación de arquitecturas multihilo o distribuidas para mejorar el tiempo de respuesta por poner algunos ejemplos.

  1. 1. A no ser que nuestro trabajo sea precisamente imaginar y diseñar nuevos sistemas como los mencionados
  2. 2. El resto de formas normales se tratarán junto con las tres primeras con mayor profundidad en otros artículos de la serie
0
No votes yet
Your rating: None