Figura 1. Etapas del diseño de bases de datos
Capítulo I
El diseño de bases de datos es un proceso complejo que permite obtener una implementación de una base de datos que satisface los requisitos informacionales de un sistema de información. El diseño se realiza a partir de los requisitos del sistema de información. Este proceso guía al diseñador de bases de datos por varias etapas con el objetivo de segmentar un problema de una complejidad considerable en diferentes subproblemas de menor complejidad hasta llegar a la solución final: la implementación de una base de datos que satisface los requerimientos funcionales y no funcionales de un sistema de información.
Cada uno de los subproblemas identificados corresponde a una de las etapas del proceso de diseño de bases de datos. En este capítulo se describe el proceso global de diseño de bases de datos y las diferentes etapas que lo forman. Este es sólo un texto introductorio al diseño de bases de datos. Así pues, en este capítulo se presenta una visión general de todo el proceso de diseño. Aunque el capítulo se centra en el diseño de bases de datos relacionales, las fases pueden ser utilizadas en el diseño de bases de datos de cualquier tipo (orientadas a objetos, relacionales orientadas a objetos, etc.).
El proceso de diseño de bases de datos consiste en definir la estructura lógica y física de una o más bases de datos para responder a las necesidades de los usuarios con respecto a la información que necesita un sistema de información.
Mediante un proceso de diseño de bases de datos, se define qué información es necesaria para un sistema de información y cómo se relaciona esta información entre sí. Aparte de definir la información necesaria, también se debe tener en cuenta cómo almacenar dicha información para que los sistemas de información puedan funcionar eficientemente. Todas estas tareas forman parte del proceso de diseño de bases de datos. Para poder tomar estas decisiones de la mejor manera, hay que tener en cuenta las necesidades de información de los usuarios en relación con un conjunto concreto de aplicaciones.
Por ejemplo, supongamos que se quiere crear una base de datos para dar soporte al proceso de extracción de dinero desde cajeros automáticos para un determinado banco. Las primeras etapas del diseño de base de datos se encargarán de garantizar que la base de datos contenga la información relevante: sobre las tarjetas de crédito, sus cuentas enlazadas y el saldo de estas. Las últimas etapas del diseño de base de datos permitirán implementarlas de forma que puedan responder a la pregunta de si una cuenta tiene saldo suficiente en menos de 2 segundos, con independencia de que haya millones de cuentas en el banco.
Por lo tanto, el diseño de una base de datos es el proceso en el que se define la estructura de los datos que debe tener la base de datos de un sistema de información determinado y cómo se deben almacenar y gestionar estos datos para permitir una explotación eficiente de los mismos por los sistemas de información.
Los requisitos que debe cumplir un sistema de información y la complejidad de la información que se presenta en él provocan que el diseño de una base de datos sea un proceso complicado. Para simplificarlo, es muy recomendable utilizar la estrategia de «divide y vencerás» (divide and conquer)1.
Si se aplica este concepto, se obtienen las diferentes etapas del diseño de bases de datos. Estas son secuenciales y el resultado de cada una sirve de punto de partida de la etapa siguiente. El resultado de la última etapa será la implementación de nuestra base de datos. De este modo, un proceso complejo se descompone en diferentes procesos de menor complejidad. La figura 1 muestra las distintas etapas del diseño de bases de datos.
En primer lugar, la recogida y análisis de requisitos. Esta etapa debe permitir obtener los requisitos y las restricciones de los datos del problema. Para obtener esta información, será necesario mantener conversaciones con los diferentes usuarios de la futura base de datos y de las aplicaciones que estén relacionadas con esta. Solo si se cruzan los requisitos de los diferentes perfiles de usuarios será posible establecer un marco completo de requisitos y restricciones de los datos relacionados con la futura base de datos.
Figura 1. Etapas del diseño de bases de datos
A continuación, se inicia el diseño conceptual. En esta etapa se analizan los requisitos obtenidos en la etapa anterior para identificar la información necesaria para el sistema de información. Una vez detectada, se plasma en un esquema conceptual. El esquema conceptual es una especificación gráfica de los datos necesarios para un sistema de información y las restricciones asociadas a dichos datos.
Hasta esta etapa del diseño de bases de datos todavía no ha sido necesario escoger el tipo de base de datos (relacional, orientada a objetos, documental, etc.) ni el sistema gestor de bases de datos (SGBD)2 que se utilizará o el lenguaje concreto con el que se implementará la base de datos. Por tanto, el trabajo realizado hasta este punto será aprovechable sea cual sea el tipo de base de datos que se quiera crear.
En el momento en el que se inicia la tercera etapa del proceso de diseño, el diseño lógico, hay que determinar el tipo de base de datos3 que se utilizará. Algunos ejemplos de tipos de bases de datos que se podrían tener en cuenta son los siguientes: Relacional, Orientada a Objetos, Object-Relational, NoSQL, Geográfica, XML y Multidimensional. Es importante destacar que en este paso NO se está escogiendo un producto de base de datos concreto, como pueden ser Oracle, Sql Server, MySQL, PostgreSQL, VoldDB o MariaDB, sino un tipo de base de datos. En esta etapa el esquema conceptual se convierte en un esquema lógico adecuado al tipo de bases de datos que se pretende usar.
En este punto, y antes de iniciar la etapa de diseño físico, hay que elegir un SGBD concreto sobre el que se pretende implementar la base de datos. La etapa de diseño físico adapta el esquema lógico a las necesidades específicas de un SGBD concreto y, posteriormente, ajusta algunos parámetros para el correcto funcionamiento de la base de datos. Por base de datos concreta o SGDB concreto entendemos una aplicación concreta de bases de datos. En el caso de bases de datos relacionales, ejemplos de SGBD concretos son Oracle Database, Mysql, SQL Server o IBM Informix, entre otros. También se deberá tener en cuenta la arquitectura hardware que dará soporte a la base de datos y el uso esperado de la base de datos, ya que no es lo mismo implementar una base de datos en un ordenador personal que en un cloud de ordenadores con discos RAID, ni crear una base de datos de escritorio que una base de datos multiusuario con acceso 7x24.
Finalmente, la última etapa es la implementación y optimización de la base de datos. Esta etapa permite cargar los datos y posteriormente ajustar algunos parámetros del modelo físico para optimizar el rendimiento de la base de datos.
Estas etapas de diseño no hay que seguirlas estrictamentede manera secuencial4, y en muchos casos es habitual rehacer el diseño de la etapa anterior a partir de necesidades detectadas en fases posteriores. Estos bucles de retroalimentación son habituales y permiten afinar los diseños de las distintas etapas de una manera iterativa.
El proceso que muestra la figura 1 se basa en el modelo de diseño orientado a datos. Este modelo se centra en el diseño de los contenedores de la información y en la estructura de la base de datos. Paralelamente a este modelo existe el modelo de diseño orientado a procesos, que se centra en las aplicaciones de bases de datos para determinar los datos y el uso que de estas hacen las aplicaciones. Tradicionalmente, el diseño de aplicaciones se ha basado en este segundo modelo, pero cada vez resulta más claro que ambas actividades son paralelas y que están estrechamente interrelacionadas. Las herramientas de diseño de bases de datos y de aplicaciones se combinan cada vez con mayor frecuencia.
A continuación veremos con algo más de detalle las fases que forman el proceso de diseño de una base de datos.
La primera fase en el diseño de una base de datos consiste en conocer y analizar con detalle las expectativas, las necesidades y los objetivos de los futuros usuarios de la base de datos. Este proceso se denomina recogida y análisis de requisitos.
La fase de recogida y análisis de requisitos se puede dividir en tres subfases secuenciales: la recogida de requisitos; la estructuración y el refinamiento de los requisitos, y la formalización de los requisitos.
Para determinar los requisitos, en primer lugar hay que establecer los actores del sistema de información que interaccionarán con la base de datos. Esto incluye a los usuarios y las aplicaciones, tanto si son nuevos como si no lo son. Normalmente, un grupo de analistas se encarga de hacer el análisis de requisitos. En la mayoría de los casos, este análisis suele ser informal, incompleto e incluso incoherente en algún punto. Por lo tanto, hay que dedicar muchos esfuerzos a trabajar esta información y convertirla en una especificación lo más formal posible, para evitar ambigüedades. La especificación resultante será la base que los diseñadores utilizarán para modelar e implementar el sistema de información.
En esta fase, no solo hay que recoger y analizar los requisitos referentes a la estructura o a la forma de la información (tipos de datos y relaciones entre ítems de datos), sino que hay que capturar y analizar cualquier tipo de requisito. En el caso particular de la base de datos, hay que recoger, analizar y documentar cualquier requisito que los usuarios esperen de la base de datos. Esto incluye identificar los procesos que se deben ejecutar sobre la base de datos y estimar con qué frecuencia se ejecutarán, las restricciones a implementar sobre los datos, las restricciones sobre el rendimiento del sistema de información, las restricciones relativas a la implementación (tanto en lo que se refiere al hardware como en lo que se refiere al software), requisitos de seguridad o de rendimiento (por ejemplo, tiempo de respuesta) y volumen5 esperado de los datos, entre otros.
Algunas de las actividades más habituales de esta fase son las siguientes:
Al final de esta etapa se tendrá una lista preliminar y no formalizada de requisitos del sistema a implementar.
Se debe tener en cuenta que algunos de estos requisitos, muy probablemente, cambiarán durante el proceso de diseño y que hay que estar atentos y en contacto permanente con los usuarios de la base de datos para detectar posibles problemas. Es una buena práctica incorporar a los usuarios de la base de datos durante el proceso de desarrollo, puesto que así se incrementa su grado de implicación y satisfacción. Hay algunas propuestas de metodologías para la recogida y el análisis de requisitos basadas en el trabajo conjunto de los desarrolladores con los usuarios de la base de datos, como, por ejemplo, el diseño conjunto de aplicaciones (JAD)6.
El paso siguiente es convertir los requisitos a un formato estructurado mediante técnicas de especificación de requisitos como, por ejemplo, el análisis orientado a objetos (OOA)7, diagramas de flujo de datos (DFD)8, el lenguaje i*9 o la notación Z10. Estas técnicas utilizan diferentes tipos de recursos (diagramas, texto, tablas, gráficos, diagramas de decisión, etc.) para organizar y representar los requisitos de forma clara.
Esta fase puede representar un coste importante dentro del proceso de diseño de una base de datos, pero es muy importante y puede ser determinante para el éxito o el fracaso del sistema de información. Detectar y corregir los errores o problemas en las fases iniciales del proyecto es mucho menos costoso que arrastrar los errores hasta las fases finales, cuando corregirlos tendrá unos costes mucho más importantes. La satisfacción del usuario final vendrá determinada por la capacidad de recoger y captar sus necesidades e implementarlas de manera correcta en la solución final. Además, en caso de ser comprensibles por el cliente, los requisitos formalizados pueden ser un buen documento de compromiso entre el cliente y el diseñador de la base de datos, ya que contiene toda la información sobre lo que hay que hacer y, si están bien formalizados, dan poco margen (o ninguno) a ambigüedad.
La fase de diseño conceptual tiene como objetivo crear un esquema conceptual de alto nivel e independiente de la tecnología a partir de los requisitos, las especificaciones y las restricciones que se han recogido en la fase anterior.
En esta fase se parte de la recogida y el análisis de requisitos obtenidos en la fase anterior y tiene como objetivo diseñar un esquema conceptual de la base de datos que sea consistente con los requisitos, las especificaciones y las restricciones impuestas por la problemática que hay que resolver. Eso quiere decir que represente la información necesaria para la base de datos, junto con sus restricciones de integridad.
Un esquema conceptual es una representación gráfica que describe el conocimiento general sobre un dominio que un sistema de información debe saber para poder llevar a cabo sus funciones. Para crear un esquema conceptual, los diseñadores deben conocer muy bien el dominio del sistema de información (de aquí la necesidad de disponer de una buena lista de requisitos formalizados) y tener una gran capacidad de abstracción. Y aun cuando estas dos condiciones se cumplen, el éxito no está garantizado.
Los esquemas conceptuales describen conocimiento y, por tanto, son modelos de alto nivel y no incluyen detalles de implementación. Un esquema conceptual, además, debe servir de referencia para verificar que se han agrupado todos los requisitos y que no hay ningún conflicto entre ellos. De hecho, según el lenguaje utilizado para modelar el esquema conceptual, podemos encontrar herramientas que permiten analizar su validez y calidad, como por ejemplo la herramienta USE11 que permite evaluar si un esquema UML es correcto y si sus restricciones de integridad son satisfactibles.
En esta fase del diseño todavía no se considera el tipo de base de datos que se utilizará. Y, por lo tanto, tampoco se considera el SGBD ni el lenguaje concreto de implementación de la base de datos. En esta etapa nos concentraremos en la estructura de la información, sin resolver de momento cuestiones relacionadas con la tecnología.
Hay varios modelos de datos de alto nivel que permiten modelar los requisitos, las especificaciones y las restricciones que se han obtenido en la primera fase del diseño de una base de datos. Estos modelos disponen normalmente de lenguajes gráficos para facilitar la representación y la comprensión de sus esquemas conceptuales. Quizás hoy en día los modelos de datos más utilizados en el diseño de bases de datos son ER y UML:
Previamente a la fase de diseño lógico, se debe elegir un tipo de base de datos. Es decir, no hay que escoger todavía un SGBD concreto, sino simplemente seleccionar el tipo de base de datos que se quiere implementar. Es importante que quede claro que el tipo de base de datos determina el esquema de diseño lógico. Una vez elegido el tipo de SGBD donde se quiere implementar la base de datos, ya se puede iniciar la fase del diseño lógico.
En la fase de diseño lógico se transforma el modelo conceptual, independiente del modelo de datos que se utilizará en la base de datos, en un modelo lógico dependiente del modelo de datos (o tipo de SGBD) en el que se implementará la base de datos.
La transformación traducirá el modelo considerando el tipo de SGBD en el que se quiere implementar la base de datos. Por ejemplo, si se quiere crear la base de datos en un sistema relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, claves primarias y claves foráneas correspondientes. Mientras que si la base de datos se quiere crear en un sistema orientado a objetos, se identificarán las diferentes clases que se van a crear, sus atributos, relaciones, restricciones de integridad y la jerarquía de especializaciones entre clases y, posiblemente, entre relaciones.
El resultado de esta etapa será un modelo lógico de la estructura de la información. Generalmente, cuando este modelo lógico hace referencia a un SGBD relacional, se denomina modelo relacional.
El diseño lógico puede dividirse en tres subfases, que se aplican de manera secuencial:
Previamente a la fase de diseño físico, hay que elegir un SGBD concreto. Deben estudiarse los diferentes sistemas comerciales o libres que hay en el mercado y seleccionar un SGBD donde se pueda implementar la base de datos que se ha ido gestando en las fases anteriores del proceso de diseño. La elección del SGBD estará condicionada por el tipo de SGBD que se haya elegido en la etapa de diseño lógico.
El diseño físico de una base de datos es un proceso que, a partir de un diseño lógico y de una estimación sobre el uso esperado de los datos de la base de datos, creará una configuración física de la base de datos adaptada al entorno donde se alojará y que permita el almacenamiento y la explotación de los datos con un rendimiento adecuado.
De la definición anterior se puede extraer que también deberá tenerse en cuenta el hardware donde se ubicará la base de datos y las características de los procesos que consultan y actualizan la base de datos, como por ejemplo las frecuencias de ejecución y los volúmenes que se espera tener de los diferentes datos que se quieren almacenar con el fin de conseguir un buen rendimiento de la base de datos.
El objetivo del diseño físico es obtener un buen rendimiento de la base de datos en un entorno real. El rendimiento se refiere, básicamente, a:
Los componentes físicos que forman cada SGBD son específicos. Los fabricantes utilizan estrategias y tecnologías diferentes para maximizar el rendimiento de sus sistemas gestores de bases de datos. Incluso el lenguaje utilizado para definir el modelo físico varía de fabricante en fabricante. Eso es debido a que no existe ningún estándar para definir las construcciones adecuadas para este nivel, a diferencia a lo que pasa en los niveles anteriores. Por ejemplo, el estándar SQL incorpora la definición de todos los componentes del diseño lógico de la base de datos, más las operaciones de acceso a los datos de la base de datos, ya sea para consulta o para inserción/actualización. En cambio, no contiene ningún elemento del diseño físico. Sin embargo, existe un gran parecido entre las construcciones utilizadas por los diferentes gestores, ya que todos ellos permiten trabajar con los mismos elementos de diseño físico. Por ejemplo, en el caso relacional, los elementos de diseño físico que se utilizan son tablespaces, índices, vistas materializadas y particiones.
Por lo tanto, habrá que adaptar el esquema lógico obtenido en el paso anterior, teniendo presentes las características de cada sistema gestor. El diseñador debe considerar los aspectos de implementación física y de eficiencia que dependen específicamente del SGBD elegido. Por ejemplo, en el caso de utilizar un SGBD relacional, partiríamos de las definiciones de tablas (con toda la información relacionada; es decir, atributos, claves primarias, claves foráneas y claves alternativas). A continuación, se relacionaría cada elemento con un espacio adecuado en el nivel virtual y, finalmente, cada espacio virtual con un fichero físico, que constituye el nivel físico del sistema de información.
La última etapa es la implementación y la optimización de la base de datos.
La etapa de implementación y optimización consiste en realizar la carga de los datos y posteriormente ajustar algunos parámetros relacionados con el modelo físico de la base de datos para optimizar el rendimiento.
El objetivo principal de esta etapa es optimizar el rendimiento de la base de datos. En primer lugar, hay que realizar la carga de los datos, puesto que no es posible optimizar el acceso a los datos sin poder determinar el tamaño de las tablas, los tipos de accesos y consultas, la frecuencia de estas, etc.
Finalmente, también habrá que concretar los diferentes roles de usuarios y aplicaciones para poder determinar los permisos de los diferentes grupos. El componente de gestión de la seguridad y las vistas permiten limitar los accesos y de este modo reducir el riesgo de problemas derivados de accesos no autorizados.
El objetivo de la optimización de consultas es crear las estructuras físicas necesarias para mejorar el tiempo de respuesta de una base de datos. Normalmente, la optimización de consultas se realiza mediante la creación de índices, que son estructuras que permiten mantener un índice ordenado de acuerdo con uno o más campos de la base de datos. Los índices permiten reducir el tiempo de consulta cuando se filtra información de acuerdo con los campos indexados. Un ejemplo muy común de índices que se encuentran en los libros es el índice por capítulos, que a partir del número y el título del capítulo permite acceder rápidamente a su contenido.
Cuando la optimización de consultas se plantea en la etapa de diseño físico se puede abordar mediante otros medios, como por ejemplo el almacenamiento de determinados datos en discos de mayor velocidad, el almacenamiento ordenado de los datos, la creación de vistas materializadas o la segmentación de datos.
La optimización de consultas es un aspecto muy importante que hay que considerar cuando se diseña y se construye un SGBD relacional. Las técnicas que se utilizan para optimizar consultas condicionan el rendimiento global del sistema, puesto que determinan el tiempo que necesita el sistema gestor para resolver las consultas de los usuarios. No obstante, la mayoría de las técnicas utilizadas para la optimización de consultas son un arma de doble filo, que puede empeorar el rendimiento de la base de datos si no se utilizan convenientemente. Por ejemplo, los índices incrementan sustancialmente la velocidad de consulta, pero deben actualizarse cada vez que se añade un registro en la base de datos relacionado con el índice. Eso hace que, en determinados casos, cuando hay una frecuencia de actualización de datos muy alta, el uso de los índices puede ser contraproducente. Este sería el caso, por ejemplo, de los saldos de una cuenta corriente en una base de datos bancaria. Si se creara un índice sobre los saldos de una base de datos, cada vez que se modificara un saldo se tendría que recalcular el índice. Por tanto, en este caso probablemente se descartaría dicho índice.
Las técnicas de optimización de consultas toman incluso mayor relevancia en SGBD donde las consultas utilizan lenguajes declarativos. Los lenguajes declarativos permiten definir qué información se quiere obtener, pero sin decir cómo debe obtenerse. Es decir, se especifica el resultado que se quiere obtener a partir de una consulta realizada, en lugar de determinar el algoritmo o el método que hay que usar para obtener el resultado. Por ejemplo, el lenguaje SQL empleado por las bases de datos relacionales es declarativo.
Cuando los SGBD utilizan lenguajes declarativos, deben evaluar sistemáticamente las posibles estrategias alternativas que se pueden utilizar para acceder a los datos, y elegir la que se considera óptima. El procesamiento de consultas recoge todo el conjunto de actividades realizadas por el SGBD, que tienen como objetivo la extracción de información de la base de datos para lograr la estrategia más eficiente y proporcionar un mejor rendimiento del sistema de información.
Los SGBD relacionales disponen de técnicas para consultar los planes de resolución de consultas que van a utilizar. Estos planes proporcionan información muy útil para el diseñador de la base de datos, ya que muestran cuántos accesos a disco se realizan, cómo se combinan los datos, y si se utilizan índices u otras estructuras de soporte. Con esta información, el diseñador de la base de datos puede identificar potenciales mejoras y crear estructuras alternativas de datos (índices, vistas materializadas, etc.) para optimizar la consulta.
Este punto es uno de los más importantes que se deben tener en cuenta cuando se diseña un SGBD relacional, puesto que la opción elegida afecta directamente al rendimiento global del sistema.
Finalmente, hay que tener en cuenta las técnicas que se emplean para proteger la base de datos de los accesos no autorizados y los mecanismos para asignar y revocar privilegios a los diferentes usuarios. De estas y otras acciones se encarga el componente de seguridad del SGBD. Este componente deviene cada día más importante, dado que en la actualidad una gran cantidad de ordenadores y otros tipos de dispositivos están interconectados y, por lo tanto, cualquier persona podría convertirse en usuario, y posible atacante, de una base de datos.
Hacer un uso adecuado de las vistas es otro aspecto clave para gestionar la seguridad. Las vistas son estructuras lógicas que permiten acceder a la información de la base de datos a partir de una consulta predefinida. Por tanto, con las vistas pueden generarse diferentes visiones de los datos adaptadas a distintos usuarios, puesto que podemos ocultar información a determinados usuarios y mantener la visión del usuario independientemente de la evolución que tenga la base de datos. Así pues, utilizando vistas se podría hacer que los trabajadores del departamento de contabilidad de una empresa solo pudieran ver los datos de pago de un cliente (nombre, NIF y cuenta corriente), mientras que los trabajadores de logística pudieran ver su dirección y datos de entrega (nombre, persona de contacto, teléfono, dirección de entrega, etc.), así como que los comerciales del área geográfica de Girona solo puedan acceder a los clientes de esa zona.
En muchas organizaciones, la información es un activo intangible y de naturaleza sensible, que tiene un valor muy importante. Para preservar esta información, hay que proteger el sistema de información y conocer las obligaciones legales que hay que cumplir.