El concepto más general de una base de datos es el lugar donde se guardan los datos. Vamos a suponer que somos los dueños de una librería y deseamos tener almacenados todos los datos posibles de nuestro negocio. Para poder llevar cierta organización de estos datos, no queremos que estos datos sean un montón de información almacenada sin seguir ningún orden. Deberemos seguir una estructura que permita que esa información esté enlazada, de modo que tengamos conectados unos datos con otros, para que por ejemplo no nos volvamos locos, buscando un libro que nos ha pedido un cliente.

Siguiendo con el ejemplo de la librería, podemos organizar nuestras necesidad en los siguientes puntos:

• Aspecto particular de un determinado libro, por ejemplo el precio.
• Aspectos importantes de un libro, por ejemplo Título, Autor, ISBN, Páginas, Género, etc...
• Aspectos importantes de todos los libros.
• Aspectos importantes de la librería al completo.

En este caso, hemos desglosado a primera vista, los cuatro puntos más importantes en cuanto a información se refiere de nuestra librería, podíamos haber entrado en niveles más complejos, como pueden ser clientes, proveedores, empleados, pero no es lo que deseamos para empezar a explicar los fundamentos de las bases de datos.

Como estamos diciendo, hemos separado en cuatro puntos, las necesidades que podemos tener en cuanto a información de un libro. Estos cuatro puntos, nos dan una idea muy clara de la jerarquía que sigue una base de datos, esta jerarquía la vamos a separa en cuatro niveles, y verás la lógica que tienen estos niveles respecto a los puntos de nuestra librería:

• Campo: Contiene un dato en particular, como puede ser el primer punto que hace referencia al precio de un libro.
• Registro: Almacena todos los datos de un determinado objeto de información, vemos que el segundo punto de nuestras necesidades reclama los aspectos más importantes de un libro. En este caso, el libro es el objeto de información, y sus aspectos (Título, Autor, ISBN, Páginas,...) de ese objeto de información serían un grupo de campos, al igual que sucede con el precio.
• Tabla: Almacena información de varios objetos de información que comparten aspectos similares. Estamos mencionando el tercer punto de nuestra librería, donde queremos almacenar la información de todos los libro, podemos pensar, pero cada libro es diferente al resto, y es cierto, pero todos los libros tienen en común que cada uno de ellos tiene un determinado Título, Autor, ISBN, Páginas, Género, etc... Por lo tanto, si hemos entendido bien, los conceptos de los dos anteriores niveles, podemos asegurar que una tabla almacena una serie de registros (libros).
• Base de datos: Cuarto y último nivel, de nuestro primer vistazo a la idea de base de datos, relacionada con el cuarto punto de nuestra librería el cual nos indica que queremos almacenar los aspectos de la empresa al completo, por lo tanto, este nivel guarda información de varios aspectos, no sólo de libros, sino de ventas, compras, clientes etc...Por lo tanto la base de datos, dicho de un modo muy simple y muy genérico, almacena las tablas.

Acabamos de mencionar los cuatro conceptos básicos de toda base de datos, si es la primera vez que te introduces en este mundillo deben quedarte muy claros estos cuatro pilares de información.

Tal y como hemos avisado, esta definición de base de datos es demasiado simple, decir que la base de datos se encarga de almacenar la información estructurada en esos cuatro niveles es decir demasiado poco. Muchos fabricantes ofrecen en sus servidores la posibilidad de almacenar muchas mas funcionalidades que estas cuatro.

Microsoft SQL Server 2005 ofrece una cantidad enorme de objetos, que al igual que los datos se almacenan en la base de datos, pero cuya función no es guardar información, sino trabajar con ella. Así a primera vista, puede parecer complicado,  ¿Una base de datos almacena algo más que datos? Veremos que así es, y que son de una importancia grandísima, ya que tienen tareas tan importantes como asegurar que esos datos se almacenan correctamente, de la seguridad, del rendimiento que obtenemos de esos datos, etc...Pero como te digo, los iremos viendo a lo largo del curso.

Una base de datos se almacena en varios ficheros o archivos en disco. Como mínimo tendremos dos ficheros que explicaremos más adelante.

Tenemos la posibilidad de almacenar estos ficheros en discos que no estén ni tan siquiera formateados o que no tengan una partición hecha, pero este método no es el más aconsejable. Es más razonable almacenar estos archivos en un disco ya formateado, con formato NTFS.

En empresas cuyo volumen de datos es altísimo y el trabajo que se realiza sobre la base de datos soporta una actividad elevada, se almacenan los archivos en grupos de discos denominados RAID por hardware. Este método mejora considerablemente el rendimiento, y nos asegura que en caso de fallos inesperados no perdamos esa valiosa información.

Como es lógico, nosotros para realizar nuestros ejemplos, no vamos a basarnos en esta tipo de estructuras de hardware, lo almacenaremos en nuestro disco duro, aunque veremos como asegurar nuestros datos mediante planes de mantenimiento con copias de seguridad automáticas.

Como hemos mencionado, como mínimo tendremos dos archivos donde almacenar la base de datos:

• Archivo de datos.
• Archivo de registro de transacciones.

Pero debes saber que tenemos otras posibilidades y podemos utilizar archivos extras para mejorar el rendimiento de nuestra base de datos, podemos usar varios archivos, si pensamos que nuestra base de datos va a alcanzar un tamaño grande. O si deseamos que nuestros datos se almacenen en diferentes dispositivos de almacenamiento u ordenadores, y de este modo permitir un trabajo más rápido al poder acceder a la información en paralelo.

Centrándonos en lo principal:

• El archivo de datos, o aquellos que añadimos como extras, son los archivos que tendrán almacenada la información, los datos. Pero recuerda que hemos dicho que SQL Server 2005 nos permite también crear en nuestras bases de datos, no sólo información, sino también una serie de objetos que trabajan con la información. Pues bien, esta serie de objetos también se almacena en el archivo de datos.
• Por otro lado, tenemos el archivo de registro de transacciones. Este fichero es tan importante como el anterior. Su importante tarea es garantizar que esa base de datos permanece integra. Gracias a estos archivos de registros (puede haber más de uno), en caso de ser necesario, podremos recuperar la base de datos, ya que almacena las modificaciones que se producen debido a la actividad o la explotación de la base de datos.

El modo de nombrar una base de datos, parte de una base fija, de un nombre principal que generalmente entrega el administrador de la base de datos. Una vez que tenemos este nombre principal, SQL Server 2005 se encarga de añadir terminaciones y unas determinadas extensiones, a ese nombre principal. El administrador además de seleccionar el nombre principal, puede elegir el destino donde se almacenarán los ficheros que forman la base de datos.

Vamos a suponer que estamos en una empresa como administradores, y estamos creando su base de datos. Nosotros como administradores le damos el nombre principal " miEmpresa ". Ese será el nombre de la base de datos, pero los ficheros donde se almacenará su información y el registro de transacciones, serán:

• Archivo de datos: miEmpresa_Data.MDF
• Archivo de registro de transacciones: miEmpresa_Log.LDF

En caso de tener archivos extras, nosotros como administradores también podremos darles su nombre principal, y la extensión que suele utilizarse es .NDF

Siguiendo con nuestra tarea de administrador, ahora sería el momento de seleccionar el lugar de almacenamiento, como ya sabes podemos seleccionar una determinada carpeta o directorio, incluso diferentes unidades físicas. Lo más aconsejable es guardar en diferentes unidades, por un lado el archivo de datos, y por otro el archivo de registro de transacciones. De modo que en caso de fallo, por lo menos tengamos uno de ellos.

A continuación puedes ver una figura que representa la estructura física de la base de datos, tomando como ejemplo el nombre principal "MiEmpresa".

No debes quedarte con la idea de que una base de datos, se compone sencillamente de dos archivos, es algo mucho más completo que todo eso lo que representa una base de datos como entidad.

En el momento de crear la base de datos, es casi imposible conocer la cantidad de memoria que necesitará para almacenar toda la información. Es cierto que hay ciertas técnicas que nos permiten calcular el tamaño que podrá alcanzar la base de datos, pero estas estimaciones pueden venirse a bajo, por modificaciones imprevistas, como puede ser el crecimiento de la empresa y que se intensifique la actividad realizada sobre la información, por citar un ejemplo.

Tampoco es nada aconsejable pecar de precavidos y reservar una cantidad de memoria exagerada, y pensar que con esta cantidad casi infinita no tendremos problemas de espacio para nuestros datos. De acuerdo, puede que no haya problemas de espacio (o quizá sí), pero lo que es seguro es que tendremos muchísimos problemas de rendimiento, de fragmentación etc...

SQL Server 2005 nos permite olvidarnos hasta cierto punto de este problema. Los archivos de datos y de registro, crecen automáticamente. No crecen con cada dato que se añade. Nosotros como administradores, le daremos un tamaño inicial sencillo de estimar ( una cantidad muy pequeña, unos Megabytes ), en ese momento SQL Server 2005 crea la estructura correcta para la base de datos, y una vez que nuestra base de datos está en explotación cuando alcanza el tamaño limite, lo incrementa una cantidad dada por un factor predeterminado.

Visto de modo teórico puede asustar un poco, sólo estamos comenzando a crear la base de datos, y estamos mencionando varias características a tener en cuenta. No tenemos porque asustarnos, veremos como estos parámetros se pueden dar de un modo altamente sencillo mediante el interfaz de SQL Server 2005, y como con pocos clicks, todos estos aspectos los realiza SQL Server por nosotros, así que no te preocupes y sigue leyendo.

Para entender que es la estructura lógica de una base de datos vamos a poner un sencillo ejemplo.

Cuando nosotros nos compramos un equipo de música, poco nos importa como funcionan los circuitos integrados, los elementos electrónicos que componen nuestro equipo. En este caso, esos circuitos, esos dispositivos electrónicos, sería la estructura física del equipo de música, al igual que hemos visto la estructura física de nuestra base de datos.

A lo que nosotros como usuarios vamos a dar importancia es al manejo del equipo de música: como subir el volumen, encenderlo, cambiar de emisoras, introducir un CD. De igual modo, como usuarios de la base datos, debemos conocer la estructura lógica de la base de datos para poder gestionar o trabajar con los datos.

Una estructura lógica mínima puede ser el ejemplo de la librería que hemos visto a modo de introducción en esta lección.

Lo que vamos a exponer a continuación a modo de introducción son los elementos principales que componen la estructura lógica de una base de datos, de modo que sepas de que estamos hablando en caso de que se mencionen en las diferentes lecciones. Sin embargo, los iremos viendo con más detenimiento más adelante, de momento es suficiente con que te suenen y las vayas conociendo.

Las tablas son las unidades que almacenan los datos. Como norma general se suele imponer que cada tabla, almacena información común sobre una entidad en particular (recuerda los libros). Esta norma se conoce como normalización.

La mayor parte de la actividad producida en una base de datos se produce sobre las tablas, siendo las principales tareas las siguientes:

• Añadir información.
• Eliminar información.
• Modificar y actualizar información.
• Recoger información y mostrarla.

Comúnmente estas cuatro tareas se realizan mediante el lenguaje SQL (Structured Query Language) que significa Lenguaje de consultas estructurado, que como ya sabrás es el lenguaje estándar para gestionar bases de datos.

Las tablas están compuestas de registros y campos. Si imaginamos el diseño de una tabla, como si de una cuadrícula se tratase, sabemos que está compuesta por varias filas y columnas. Las filas corresponden a los registros, mientras que las columnas serían los campos. Y cada una de las celdas que se forman de enlazar un registro (fila) con un campo (columna) formaría una celda, la cual almacena un valor.

Por lo tanto, un registro esta formado por varios campos, y cada campo almacena un determinado valor.

Acabamos de mencionar que en cada celda se almacena un valor. Pero ¿siempre debe almacenar un valor?, que sucede si estamos almacenando información de un determinado producto, y en el momento de almacenarlo desconocemos una de sus características (un valor). En ese caso ¿no podríamos almacenarlo?.  Lógicamente la respuesta a esta pregunta es que sí, por supuesto que podríamos almacenarlo. Tenemos la posibilidad de almacenar valores nulos para este caso que hemos visto y muchos otros.

Los valores nulos se conocen como NULL, pero aunque se conoce como valor nulo, no debes pensar que se almacena un valor, el concepto de NULL podría ser un marcador que informa que hay que pasar por alto los datos de esa celda, son datos que se ignoran. Como veremos, hay que tener mucho cuidado con el uso de esta "ausencia" de información, ya que si tenemos algún despiste puede ser el causante de que no recibamos la información que realmente estamos reclamando en una consulta.  Si realizamos operaciones matemáticas con varios valores de nuestra base de datos y uno de estos es NULL, el resultado siempre será NULL.

Seguimos hablando de la unidad o entidad principal de la base de datos, las tablas. Podemos tener tablas con millones de registros, si realizamos una consulta para recuperar información de un grupo de estos registros, podemos tener un rendimiento bajo debido a la gran cantidad de información que almacena esa tabla.

Sitúate en una tabla que almacena las ventas de productos que se han producido durante décadas en una gran empresa, y queremos recoger la información de una determinada venta. El proceso de búsqueda recorriendo cada uno de esos registros (ventas) de la tabla de principio a fin, puede necesitar un tiempo considerable hasta que encuentra la información deseada.

Para acelerar este tipo de consultas contamos con la ayuda de los índices. Un índice es una característica más de las tablas, el cual es una conjunto de valores clave. Este conjunto tiene una estructura estudiada para que el servidor pueda realizar las consultas con un rendimiento mucho mayor.

Estos valores claves pueden almacenar el contenido de una o varias columnas de la tabla sobre la que operan.

Además de mejorar el rendimiento, existen índices que pueden asegurar la integridad de los datos, indicando en que orden deben almacenarse los datos en un tabla. Más adelante veremos como trabajar con los índices.

Por lo tanto podemos decir que teóricamente nuestras tablas deberían todas incluir al menos un índice que asegure un mejor rendimiento. Y en la práctica, suele ser lo más común, pero debes tener en cuenta que cada vez que realizamos una tarea sobre una tabla que está relacionada con índices, el servidor, no sólo opera sobre la tabla para realizar las modificaciones que se le demanden, sino que también debe realizar operaciones sobre los índices para asegurar que la labor de estos sigue siendo la adecuado para las modificaciones realizadas sobre la información de la tabla. Por lo tanto la regla de tres es sencilla, a mayor número de índices, mas tiempo dedicará a las tareas pedidas.

Las restricciones son normas que imponemos a la información que pude ser almacenada, de modo que si no se cumple una de estas condiciones no permitamos que incluya ese valor en nuestra base de datos.

Si tenemos una tabla de clientes, podríamos poner como restricción que no se pueda almacenar un cliente cuya edad no supere los 18 años. El servidor se encargará de no permitir que se incluya ningún registro que incumpla nuestra condición.

Estas restricciones además de permitir controlar que valores pueden ser almacenados, con esta tarea aseguramos también la integridad de nuestros datos. Piensa que por descuido un usuario introduce por error un cero como el número de unidades que se han vendido a un minorista. Al calcular el precio de la venta y multiplicarlo por cero unidades, tendremos como precio de facturación cero.

Pero no sólo debemos pensar en que es el usuario quien comete el error, puede que el programador que ha desarrollado un software de facturación haya cometido un error al escribir el código. El programa por sí sólo, si no ha tenido en cuenta esta posibilidad, no lanzará ningún error, y todo parecerá ir correctamente y emitirá la factura al minorista. Pero gracias al servidor de base de datos, podemos tener controlado que uso hace el software que trabaja con nuestros datos.

Las consultas que se realizan sobre algunas de las tablas de la base de datos pueden ser repetitivas, de modo que día tras día cientos de usuarios realizan las mismas consultas sobre la tabla. Todas esas consultas repetitivas reciben el mismo grupo de datos.

Para evitar la repetición de este tipo de consultas tenemos las vistas.

Podemos pensar que una vista es un conjunto de registros determinados de una o varias tablas. De hecho se trabaja sobre ella como una tabla, pero no es una tabla. Lo que almacena en realidad es una consulta.  Pero debes tener claro que no almacena datos sino que los extrae.

Una vista puede crear los enlaces necesarios para obtener información de varias tablas como si fuese una única tabla. Esto puede facilitar mucho la tarea al desarrollador de software que no tiene que preocuparse de las tablas donde se almacena la información que quiere recoger, ya que lo tiene todo en una vista sobre la que puede operar como si fuese una tabla. Por lo tanto se olvida de construir complicadas sentencias de SQL que recoja esa información de múltiples tablas, con diferentes enlaces entre ellas.

Las consultas y las tareas de gestión que se realizan durante la explotación de una base de datos vienen escritas en lenguaje SQL, Structured Query Language, que como ya hemos mencionado significa Lenguaje de Consulta Estructurado.

El ANIS (Instituto Nacional de Normalización Estadounidense) ideo este lenguaje estándar, denominado ASNI SQL, o también SQL-92, por el último año en el que ANSI aceptó modificaciones sobre el estándar.

Como suele ocurrir en tantas ocasiones en el mundo del mercado informático. Este estándar fue recogido por los fabricantes para personalizarlos y crear sus propias extensiones para sus productos. Microsoft así lo hizo, para crear Transact-SQL, o más comúnmente conocido por su abreviatura T-SQL para sus servidores de base de datos SQL Server.

Como veremos, SQL Server 2005 y sus antecesores, pueden trabajar con SQL, pero gracias a T-SQL podemos realizar sentencias más completas que solventarán fácilmente problemas. Por lo tanto T-SQL no es un sucesor de SQL para nosotros, sino una ampliación, una herramienta extra que utilizaremos para fines más avanzados.

SQL Server no sólo puede ejecutar las consultas de las tablas, o las vistas que ya hemos visto. También permite que desarrollemos procedimientos con código escrito íntegramente en SQL o con la ayuda extra de T-SQL. Tanto con el estándar como con la versión de Microsoft, podemos crear sentencias que vayan más allá de consultas, ya que como lenguajes de programación que son, pueden contener sentencias condicionales, bucles, etc... Si nunca te has introducido en ningún lenguaje de programación, no te preocupes porque veremos estos conocimientos con detenimiento, y si ya conoces otros lenguajes de programación, aprenderás la sintaxis específica de este lenguaje.

Los procedimientos almacenados, como cualquier función de otro lenguaje, pueden recibir parámetros de entrada y de salida, o no recibir ni devolver nada. Además de devolver parámetros, pueden devolver incluso tablas virtuales, vistas, etc...

Los procedimientos almacenados los almacena SQL Server 2005 del modo más optimo para sacarles el mejor rendimiento posible. De este modo las instrucciones quedan almacenadas en la propia base de datos. Esto es una gran ventaja, en cuanto a seguridad y rendimiento, ya que los programas desarrollados por los programadores no necesitan tener estas sentencias SQL en el código de su software, y por lo tanto esta información que supone el propio código SQL, no tiene que "viajar" del programa a la base de datos. Y como es lógico pensar, cuanta menos información "viaje" del programa del cliente al servidor, ganaremos en seguridad y en rendimiento.

Además de los elementos que hemos ido numerando de la estructura lógica de una base de datos, tenemos otros muchos que como siempre se almacenan en nuestra base de datos y que sirven para realizar diversas tareas. Algunos de estos elemenos los iremos estudiando, pero para poder continuar con la lección sin problemas ya tenemos los conocimientos básicos, que ampliaremos más adelante.