Creación de una base de datos
Ahora que ya hemos instalado SQL Server y conocemos el manejo básico de las herramientas que trae consigo, vamos a ver cómo realizar las operaciones más habituales.La creación de una base de datos es una de las tareas básicas dentro de SQL Server 2008. Esta tarea comienza con el diseño del modelo lógico y físico, que darán paso al modelo entidad – relación. Lo primero que debemos hacer es recabar toda la información posible sobre el sistema que queremos representar. Luego procederemos a organizar toda esta información, para que la manipulación, recuperación y custodia de los datos sea lo más segura, escalable y eficiente posible, y desde luego, responda a las necesidades requeridas. Una vez que tenemos listo el diseño de la base de datos, procederemos a su creación en SQL Server 2008.
¿Qué es una Base de Datos?
Una base de datos es un contenedor para un conjunto de objetos que sirven para almacenar datos, que se encargan de mantener la integridad de los datos y que permiten su manipulación y extracción manteniendo unos criterios de seguridad sobre ellos.
Archivos de una Base de Datos
SQL Server 2008 organiza las bases de datos en archivos que se almacenan dentro de la estructura de carpetas de los discos duros que contiene el servidor.
Como mínimo, todas las bases de datos de SQL Server 2008 tienen dos archivos: un archivo de datos y un archivo de registro. Los archivos de datos contienen los datos que queremos almacenar, y además contienen la descripción de los objetos de la base de datos, como tablas, índices, funciones, vistas o procedimientos almacenados. Los archivos de registro contienen la información necesaria para recuperar todas las transacciones de la base de datos.
Podemos distinguir tres tipos de archivos en SQL Server 2008:
Principal: El archivo de datos principal contiene la información de inicio de la base de datos, así como un registro del resto de los archivos de la base de datos. Este archivo también puede contener datos y objetos de usuario. La extensión de estos archivos es *.MDF.
Secundario: Los archivos de datos secundarios únicamente almacenan datos de usuario. Son opcionales y se pueden utilizar para distribuir datos en varios discos físicos, (o lógicos, si tenemos montado un sistema RAID), colocando cada archivo en una unidad diferente. La extensión de estos archivos es *.NDF.
Registro: Los archivos de registro de transacciones contienen la información que se utiliza para recuperar la base de datos. Cada base de datos debe tener, como mínimo, un archivo de registro de transacciones, y su extensión es *.LDF.
De forma predeterminada, los archivos de la base de datos se colocan dentro de la misma ruta, lo que en muchas ocasiones no será lo más óptimo en cuestión de rendimiento. Durante el proceso de creación de la base de datos, veremos cómo modificar las rutas de los archivos.
Páginas
Los archivos de datos de una base de datos tienen una estructura que permite a SQL Server 2008 almacenar los datos en ellos de manera organizada y recuperarlos de una forma eficiente.
La unidad más pequeña de almacenamiento es la página. El espacio reservado en disco para un archivo de datos se divide en páginas numeradas secuencialmente de 0 a n, y SQL Server realiza todas las operaciones de E/S a nivel de página, es decir, lee o escribe páginas enteras. Además, SQL Server organiza las páginas en extensiones, que son un conjunto de 8 páginas físicamente contiguas.
El tamaño de cada página es de 8KB, o lo que es lo mismo, todas las bases de datos de SQL Server tienen 128 páginas por megabyte. Cada página empieza con un encabezado de 96 bytes, que se utiliza para almacenar la información del sistema acerca de esa página. Esta información incluye el número de página, el tipo, el espacio libre en la página y el ID de unidad de asignación del objeto propietario de la página.
El funcionamiento del proceso de lectura y almacenado es muy simple. Las filas de datos se colocan en las páginas una a continuación de la otra, empezando justo después del encabezado. Al final de la página comienza una tabla de desplazamiento de fila, y cada una de esas tablas contiene una entrada para cada fila de la página. Cada entrada registra la distancia del primer byte de la fila desde el inicio de la página. Las entradas de la tabla de desplazamiento de fila están en orden inverso a la secuencia de las filas de la página.
En una página, como hemos dicho, puede estar almacenadas una o varias filas, sin embargo, una fila no puede estar almacenada en más de una página. Esto tiene como consecuencia que la cantidad máxima de datos que puede contener una fila son 8.060 bytes (8KB). En SQL Server 2000, esta restricción no se aplicaba a los campos de tipo text, ntext o image, ya que esos se almacenan en páginas especiales. En SQL Server 2008 se ha suavizado esta restricción también para los tipos de datos varchar, nvarchar, varbinary o sql_variant, es decir, los tipos de datos de longitud variable.
Cuando el tamaño de la fila excede el límite de 8KB, SQL Server 2008 mueve dinámicamente una o más columnas de longitud variable a páginas de la unidad de asignación ROW_OVERFLOW_DATA, empezando por la columna con el mayor ancho. En la página original se mantiene un puntero de 24 bytes de la unidad de asignación IN_ROW_DATA que apunta a la unidad de asignación ROW_OVERFLOW_DATA, donde se encuentran almacenados los datos. Si una operación posterior reduce el tamaño de la fila, SQL Server vuelve a mover las columnas dinámicamente a la página de datos original.
Como acabo de decir, existen varios tipos de página. Veamos cuales son:
Datos: almacenan las filas de datos, exceptuando los tipos de datos grandes (text, ntext, image).
Índice: almacena las entradas de los índices de las tablas de la base de datos.
Texto o BLOB: Almacenan los datos correspondientes a los tipos de datos grandes, como text (varchar(max)), ntext (nvarchar(max)), image (varbinary(max)) o xml. También almacenan los datos de las columnas de longitud variable, cuando la fila de datos sobrepasa los 8KB.
Mapa de asignación global: guardan información acerca de si se han asignado las extensiones.
Mapa de asignación de índices: informan acerca de las páginas utilizadas por los índices de las tablas.
Mapa cambiado masivamente: guardan información acerca de las extensiones modificadas por operaciones masivas desde la última instrucción BACKUP LOG por unidad de asignación. Mapa cambiado diferencial: informa acerca de las extensiones que se han cambiado desde la última instrucción BACKUP DATABASE por unidad de asignación.
Espacio disponible en páginas: guarda información acerca de la asignación de páginas y del espacio libre disponible en ellas.
Por último, merece la pena aclarar que todo esto se refiere a la estructura de los archivos de datos de una base de datos de SQL Server 2008. Los archivos de registro de transacciones no contienen páginas. En su lugar, contienen series de registros.
Extensiones
Las extensiones son la unidad básica de administración de espacio en SQL Server 2008. Una extensión consta, como he dicho anteriormente, de ocho páginas contiguas físicamente, es decir, de 64KB. Esto significa que las bases de datos de SQL Server tienen 16 extensiones por megabyte.
Para hacer que la asignación de espacio sea eficaz, SQL Server no asigna extensiones completas a tablas con pequeñas cantidades de datos. Podemos distinguir dos tipos de extensiones dentro de SQL Server:
Uniformes: las extensiones uniformes son propiedad de un único objeto. Solo el objeto propietario de la extensión puede utilizar sus ocho páginas.
Mixtas: pueden estar compartidas hasta por ocho objetos, por lo que cada una de las páginas de la extensión puede ser propiedad de un objeto diferente.
A las tablas o índices nuevos se les suele asignar páginas de extensiones mixtas. Cuando la tabla o el índice crecen hasta el punto de ocupar ocho páginas, se trasladan a extensiones uniformes para las asignaciones posteriores. Si al crear alguno de estos dos tipos de objetos, SQL Server comprueba que
contiene filas suficientes como para generar ocho páginas, todas las asignaciones del objeto se colocan en extensiones uniformes.
Objetos de la Base de Datos
En una base de datos dentro de SQL Server 2008 podemos encontrar, entre otros, los siguientes objetos:
Tablas: son los objetos donde se almacenan los datos dentro de la base de datos. Existen dos tipos básicos de tablas: de usuario y de sistema. Las tablas de sistema contienen información acerca de la base de datos que utiliza SQL Server 2008 para poder gestionarla.
Columnas: son los elementos que componen la estructura de las tablas. Cada una tiene un nombre y un tipo de dato asociado, de tal manera que la información que se almacena en cada columna está restringida por el tipo de dato asociado. Una columna también determina la longitud máxima de los datos que almacena.
Filas: también conocidas como registros, se ajustan al esquema de columnas de la tabla a la que pertenecen. Cada fila define una unidad de información, una instancia del objeto definido por la tabla a la que pertenece. Por ejemplo, cada fila de la tabla Clientes, representa un único cliente.
Procedimientos Almacenados: son bloques de instrucciones Transact-SQL compiladas. Las ventajas son muchas, como por ejemplo ejecutar el mismo código repetidas veces, utilizando su nombre, o ventajas relativas a seguridad.
Vistas: funcionan como tablas, y se utilizan como tablas. También se las conoce como tablas virtuales. Pueden combinar información de una o varias tablas, y se utilizan sobre todo porque facilitan en gran medida la administración de la seguridad.
Funciones: una función es similar a un procedimiento almacenado. Hay de varios tipos: algunas simplemente devuelven un valor, mientras que otras, devuelven un conjunto de resultados.
Índices: son una copia de los datos de una o varias columnas de una tabla. Pueden ser considerados como una lista predefinida de información que indica cómo están ordenados y almacenados los datos de la tabla, y que sirve para que las consultas sean más eficientes. Podemos comparar estos índices con los de un libro: los dos nos ayudan a encontrar más rápido los datos.
Ensamblados: son objetos nuevos en SQL Server 2008, y son paquetes de objetos de la base de datos que han sido escritos utilizando código .NET. Estos objetos pueden ser procedimientos almacenados, funciones, tipos de datos definidos por el usuario, agregados o desencadenadores.
Además de estos objetos, podemos encontrarnos con otros, como usuarios, tipos, reglas o valores predeterminados.
Dentro de cada base de datos se incluye un conjunto de tablas de sistema, que son utilizadas por SQL Server para el mantenimiento de la base de datos. Estas tablas almacenan información sobre cada elemento de la base de datos, como tablas, columnas de tablas, usuarios, permisos de los usuarios, etc. Se suele decir que estas tablas contienen los metadatos de la base de datos. En SQL Server 2008 se ha mejorado mucho la seguridad de las tablas de sistema, de tal manera que ahora solo se puede acceder a ellas a través de vistas de sistema, nunca directamente.
Bases de Datos de Sistema
Antes de pasar a describir el proceso de creación de las bases de datos en SQL Server, vamos a repasar cuales son las bases de datos de sistema en SQL Server 2008, y cuál es su funcionalidad. Estas bases de datos son creadas durante la instalación de la instancia del servidor.
Master
La base de datos master es la más importante dentro de SQL Server, ya que constituye el núcleo del servidor, junto con el motor relacional. Si esta base de datos se corrompe, con toda probabilidad SQL Server 2008 dejará de funcionar, por lo que no está de más realizar una copia de seguridad de esta base de datos. De hecho, es recomendable hacer un backup de master justo después de la instalación, así como después de realizar algún cambio importante dentro de la instancia, como crear una nueva base de datos.
La base de datos master guarda información crítica, por ejemplo: Los Inicios de sesión del servidor.
Los roles y los usuarios asociados al inicio de sesión.
Todas las variables de configuración del sistema, como idioma, reglas de intercalación, modo de autenticación, etc.
Los nombres y las ubicaciones de todas las bases de datos. Mensajes de error de sistema.
TempDB
La base de datos tempdb es una base de datos permanente que sirve para almacenar datos temporales. Los objetos contenidos en tempdb son permanente, pero la información que se almacena en sus tablas es temporal, excepto las de sistema, claro. Toda la información contenida en las tablas de usuario de esta base de datos se pierde cuando se cierra la sesión de SQL Server, ya que la base de datos se elimina del sistema, y cuando se reinicia el servicio, la base de datos se vuelve a crear, por lo que está limpia y lista para volver a ser utilizada.
En ocasiones necesitamos almacenar ciertos datos de manera temporal. Por ejemplo, si estamos trabajando con una tabla que almacena millones de registros, puede resultar beneficioso particionar esa tabla horizontalmente, de tal manera que tendremos que trabajar con tres o cuatro tablas más pequeñas y manejables. También podemos querer almacenar el resultado de ejecutar una función, el cual pasaremos como parámetro de un procedimiento almacenado. Todos los objetos que utilizaremos en estos casos, como tablas o variables temporales, se almacenan en la base de datos tempdb, lo que nos permite mantener los datos a nuestra disposición por un periodo de tiempo, y no tenemos que crear los objetos en nuestra base de datos.
Esta base de datos no sólo está a disposición del usuario, sino que también es utilizada por el propio SQL Server para realizar muchos de sus procesos internos. Al igual que otra base de datos, tempdb está sujeta a las restricciones de espacio de las bases de datos en SQL Server, por lo que debemos ser previsores y dimensionar correctamente el espacio disponible para la base de datos temporal, ya que si los archivos de datos y de registro, (sobre todo este último), llegaran a llenarse, el servidor entero se pararía.
Model
En mi modesta opinión, la base de datos model en realidad debería haberse llamado “template”, ya que sirve como plantilla para las nuevas bases de datos. Cuando creamos una nueva base de datos, SQL Server la crea haciendo una copia de la base de datos model.
Esto puede resultar útil cuando hemos realizado un diseño de varias bases de datos que serán creadas en una misma instancia de SQL Server, y todas ellas tienen objetos comunes, como tablas, usuarios, etc. Al llevar a cabo la implementación de ese modelo, nuestro trabajo será más fácil si primero creamos los objetos comunes en la base de datos model, ya que al crear las nuevas bases de datos, todas ellas tendrán una copia de esos objetos.
También hemos de tener en cuenta que esta base de datos sirve como plantilla para la base de datos tempdb, por lo que cualquier objeto que creemos en ella será recreado en tempdb.
MSDB
Esta base de datos proporciona al Agente de SQL Server toda la información necesaria para ejecutar todas las tareas de mantenimiento programadas, así como alertas, etc, por lo que no debe ser accedida directamente, al igual que ocurre con master. Si así lo hiciéramos, podrían dejar de funcionar todas las tareas automáticas, como desfragmentación de índices, backups de bases de datos, etc.
Elementos básicos para la creación de bases de datos
Para crear una base de datos, tenemos dos posibles caminos en SQL Server 2008: 1. Utilizando las herramientas gráficas de SQL Server Management Studio. 2. Utilizando código Transact-SQL.
Ambos métodos tienen sus ventajas y sus inconvenientes. En cualquier caso, ninguno es el correcto, por tanto, debemos utilizar el método con el que nos sintamos más cómodos, sin olvidar que resulta imprescindible conocer el otro, ya que nunca sabemos cuándo puede ser necesario utilizarlo. Como ventaja, T-SQL permite configurar un mayor número de opciones de forma más rápida.
Management Studio
Veamos cómo crear la base de datos a través de Management Studio. En primer lugar, debemos acceder al Explorador de Objetos, y desplegar el árbol correspondiente a nuestro servidor. En segundo lugar haremos click derecho sobre el nodo Bases de Datos, y seleccionaremos la opción “Nueva Base de datos” en el menú contextual (Figura 1).
Figura 1
La ventana de creación de Nueva base de datos tiene tres páginas de propiedades. En la página General podemos establecer tanto el nombre de la base de datos como su propietario (Figura 2). También tenemos a nuestra disposición una casilla de verificación con la que podemos decidir si activamos esta base de datos para utilizar índices de texto.
Figura 2
Más abajo, tenemos una tabla que nos permite configurar los archivos de la base de datos, y añadir cuantos queramos, pulsando sobre el botón Agregar. Toda base de datos debe tener como mínimo un archivo de datos y un registro de transacciones, por lo que los dos primeros archivos no podremos eliminarlos. Lo que sí que podemos hacer con estos archivos es elegir su nombre, su tamaño inicial, su ubicación y sus opciones de crecimiento automático (Figura 3).
Figura 3
El nombre lógico representa el nombre de ese archivo dentro de SQL Server 2008. El tipo de archivo indica si es un archivo de datos o de registro.
El grupo de archivos indica en que grupo se encuentra ese archivo. Veremos más información más adelante dentro de este capítulo.
El tamaño inicial expresa el tamaño que se reserva en disco al crear el archivo. Esto no quiere decir que todo ese tamaño esté lleno de datos. (De hecho, como hemos comentado antes, nunca debería llegar a darse esta situación).
El crecimiento automático resuelve la cuestión planteada anteriormente, ya que nos permite especificar los parámetros de la operación de crecimiento que SQL Server llevará a cabo cuando el archivo esté cerca de estar lleno. Podemos elegir el tamaño en porcentaje o en MB, y el límite de crecimiento, si es que tenemos alguna limitación de espacio (Figura 4).
También podemos elegir la ubicación física de los archivos, especificando la ruta de acceso. Esta ruta puede ser diferente para cada uno de los archivos de la base de datos.
Por último, podemos especificar el nombre del archivo. Este nombre será el que utilicemos para referirnos al archivo dentro del sistema Operativo y, por tanto, fuera de SQL Server 2008.
Una vez hemos rellenado todos estos datos, podemos hacer click sobre el botón Aceptar. Esto iniciará el proceso de creación de la base de datos, que incluye el registro de toda la información relativa a ella en la base de datos master, creación y ubicación de los archivos de la base de datos, etc.
CREATE DATABASE
También podemos crear una base de datos haciendo uso de código Transatc-SQL. La instrucción CREATE sirve para crear objetos en el servidor local. Para crear una base de datos, acompañamos a esta instrucción con la cláusula DATABASE. La sintaxis básica la detallo a continuación:
-- Sintáxis básica.
CREATE DATABASE Odyssey ON PRIMARY ( NAME = 'Odyssey_Data', FILENAME = 'C:\BBDD\Odyssey_Data.MDF', SIZE = 10MB, MAXSIZE = 25, FILEGROWTH = 2MB ) LOG ON ( NAME = 'Odyssey_Log', FILENAME = 'C:\BBDD\Odyssey_Log.LDF', SIZE = 4MB, MAXSIZE = 10MB, FILEGROWTH = 20% )
En el ejemplo, hemos escrito el código necesario para crear una base de datos llamada “Odyssey”. Como podemos ver, hemos creado la base de datos con las opciones básicas, es decir, con un archivo de datos, y otro archivo de registro de transacciones.
El archivo de datos lo hemos asociado al grupo de archivos PRIMARY, que es el grupo de archivos por defecto. Los parámetros de configuración del archivo están escritos entre paréntesis, y van separados entre sí por comas, excepto el último:
NAME: este parámetro representa el nombre lógico del archivo, es decir, el nombre del archivo en SQL Server. Si no se especifica, tomará el valor del nombre del archivo físico. FILENAME: especifica la ubicación del archivo en el disco duro. La ruta que escribamos debe ser completa, no valen rutas virtuales o relativas, y debemos especificar el nombre del archivo, incluyendo la extensión del mismo. En general, el nombre físico y el lógico deben coincidir, para facilitar la administración de los archivos. Este parámetro es obligatorio. SIZE: representa el espacio inicial que SQL Server 2008 reservará en disco al crear el archivo. Si no especificamos ninguna unidad de tamaño para el archivo, por defecto se tomará en megabytes (MB), aunque también se pueden utilizar otras unidades, como kilobytes (KB), o gigabytes (GB). Si no se especifica un valor, se tomará por defecto un tamaño inicial de 3MB.
MAXSIZE: representa el tamaño máximo que puede alcanzar el archivo. Mientras que el espacio ocupado en disco por el archivo no alcance esta cifra, cada vez que el archivo esté próximo a llenarse SQL Server aumentará su tamaño automáticamente. Una vez que haya alcanzado el tamaño máximo, SQL Server no podrá volver a realizar el aumento de tamaño automático, por lo que corremos el riesgo de que el archivo se llene, y el servidor se detenga. Lo más habitual es no especificar ningún valor para este parámetro, ya que si así lo hacemos, no habrá restricción de tamaño máximo para el archivo.
FILEGROWTH: sirve para determinar la cantidad de espacio que SQL Server usará para incrementar un archivo de base de datos en una operación de crecimiento automático. Se puede especificar en una unidad de tamaño o bien en porcentaje sobre el tamaño actual del archivo. Si no se especifica se tomará por defecto un 10%.
Los parámetros que acabamos de detallar se aplican tanto a los archivos de datos como a los archivos de registro de transacciones.
Si quisiéramos crear una base de datos con varios archivos, podríamos hacerlo con el siguiente script: -- Base de datos con varios archivos.
CREATE DATABASE Odyssey ON PRIMARY ( NAME = 'Odyssey_Data', FILENAME = 'C:\BBDD\Odyssey_Data.MDF', SIZE = 10MB, MAXSIZE = 25, FILEGROWTH = 2MB ), ( NAME = 'Odyssey_Data2', FILENAME = 'C:\BBDD\Odyssey_Data2.MDF', SIZE = 10MB, MAXSIZE = UNLIMITED, FILEGROWTH = 2MB ) LOG ON ( NAME = 'Odyssey_Log', FILENAME = 'C:\BBDD\Odyssey_Log.LDF', SIZE = 4MB, MAXSIZE = 10MB, FILEGROWTH = 20% )
Si además queremos incluir varios grupos de archivos: -- Base de datos con varios grupos de archivos. CREATE DATABASE Odyssey
ON PRIMARY ( NAME = 'Odyssey_Data', FILENAME = 'C:\BBDD\Odyssey_Data.MDF', SIZE = 10MB, MAXSIZE = 25, FILEGROWTH = 2MB ), ( NAME = 'Odyssey_Data2', FILENAME = 'C:\BBDD\Odyssey_Data2.MDF', SIZE = 10MB, MAXSIZE = UNLIMITED, FILEGROWTH = 2MB ),
FILEGROUP Histórico ( NAME = 'Odyssey_Hist', FILENAME = 'C:\BBDD\Odyssey_Hist.MDF', SIZE = 5MB, MAXSIZE = UNLIMITED, FILEGROWTH = 10% ), ( NAME = 'Odyssey_Hist2', FILENAME = 'C:\BBDD\Odyssey_Hist2.MDF', SIZE = 5MB, ), FILEGROUP Crítico ( NAME = 'Odyssey_Cri', FILENAME = 'C:\BBDD\Odyssey_Cri.MDF', SIZE = 1GB, MAXSIZE = UNLIMITED, FILEGROWTH = 5% ) LOG ON ( NAME = 'Odyssey_Log', FILENAME = 'C:\BBDD\Odyssey_Log.LDF', SIZE = 4MB, MAXSIZE = 10MB, FILEGROWTH = 20% ) Parámetros adicionales
Acabamos de ver los parámetros básicos para crear una base de datos dentro de SQL Server 2008. Sin embargo, existen parámetros adicionales que servirán para optimizar la configuración de la base de datos.
Primero vamos a echar un vistazo a los parámetros dentro de la ventana de creación de la nueva base de datos. Tal y como podemos ver en la Figura 5, estos parámetros están agrupados en la página de propiedades llamada “Opciones”. En la parte superior de la ventana podemos ver tres opciones de configuración. La primera sirve para configurar la intercalación del servidor. Ya hemos hablado de esto en el capítulo que trata sobre la instalación de SQL Server 2008, y en aquel proceso se establecieron las reglas de intercalación del servidor. Esa será la opción que veremos para esta propiedad, ya que, por defecto, toda nueva base de datos toma las reglas de intercalación del servidor donde está siendo creada. Esta es la opción que debemos elegir en casi todos los casos, aunque si queremos modificarla no tenemos más que desplegar la lista de opciones y elegir la que más nos convenga.
Figura 5
Otra de las opciones que podemos configurar es el modelo de recuperación. Este parámetro determina como se recuperan los datos de la base de datos cuando ocurre un fallo inesperado, como falta de fluido eléctrico, o cualquier otra situación que afecte al funcionamiento del servidor. Veremos este concepto en detalle en el capítulo sobre recuperación de datos. Tenemos tres opciones (Figura 6):
Completa. Registro Masivo. Simple.
El último de los tres parámetros superiores es el nivel de compatibilidad de la base de datos. Por defecto, para todas las nuevas bases de datos de SQL Server 2008 aparece el nivel 90 (QSL Server 2008). Esto quiere decir que la base de datos es compatible con todas las características de SQL Server 2008, pero no tiene porqué soportar características de versiones anteriores. En caso de que hayamos migrado una base de datos de otra versión, por ejemplo SQL Server 2000, debemos seleccionar el nivel de compatibilidad 80, ya que si no, nos resultará imposible ejecutar ciertas instrucciones que ya están obsoletas en SQL Server 2008.
Figura 6
Estas tres opciones podemos configurarlas también utilizando código T-SQL:
-- Establecer reglas de intercalación, modelo de recuperación y nivel de compatibilidad. ALTER DATABASE Odyssey COLLATE SQL_Latin1_General_CP1_CI_AS
GO
ALTER DATABASE Odyssey SET RECOVERY FULL GO
EXEC dbo.sp_dbcmptlevel @dbname='Odyssey', @new_cmptlevel=90 GO
La instrucción ALTER DATABASE se puede utilizar una vez que la base de datos en cuestión ya ha sido creada. A diferencia de versiones anteriores, en SQL Server 2008 es posible modificar las reglas de intercalación de una base de datos una vez esta ha sido creada.
El resto de las opciones que podemos modificar las podemos encontrar en la ventana de creación de la base de datos, dentro de la página de opciones. Por su puesto, estas opciones se pueden modificar después de haber creado la base de datos, accediendo a su ventana de propiedades.
A continuación vamos a detallar todas las opciones de la ventana de propiedades de la base de datos, con su correspondiente instrucción en Transact-SQL.
Para habilitar la búsqueda de texto en la base de datos, una vez esta ha sido creada, haremos uso del procedimiento almacenado sp_fulltext_database:
-- Habilitar búsqueda de texto. USE Odyssey
GO
EXEC sp_fulltext_database @action = 'enable' GO
En numerosas ocasiones, algunas de las columnas de una tabla pueden no tener datos. En esos casos, el dato contenido en la celda recibe el nombre de NULL. El estándar ANSI establece que si existen dos columnas con el valor NULL, y comparamos ambas columnas, esa comparación fallará. Si no queremos que esto ocurra, podemos establecer el valor del parámetro ANSI_NULLS a off. En la página de opciones, aparece como “Valores NULL ANSI habilitados”:
-- Deshabilitar los valores NULL ANSI.
ALTER DATABASE Odyssey SET ANSI_NULLS OFF GO
Otra opción relativa a los valores NULL ANSI se refiere a si el valor predeterminado para una columna es NULL o NOT NULL:
-- Valores NULL ANSI predeterminados.
ALTER DATABASE Odyssey SET ANSI_NULL_DEFAULT OFF GO
Existen algunos tipos de datos de longitud variable, ya que permiten establecer un máximo de longitud para el campo al que son asignados. Por ejemplo, si en la tabla Clientes existe el campo Nombre, que tiene asociado el tipo de dato VARCHAR(30), significa que ese campo admite un valor de hasta 30 caracteres. Si un determinado cliente se llama Pepe, al insertar el dato, este solo consumirá 4 caracteres de longitud. (Si hubiéramos definido ese campo con un tipo de longitud fija, como CHAR(30), el espacio que ocuparía en disco serían 30 caracteres, aunque el nombre Pepe solo ocupe cuatro). Si queremos inhibir este comportamiento, podemos establecer la propiedad “Relleno ANSI habilitado” a su valor true. Evidentemente, lo más habitual es establecerlo a false, y además, es el valor por defecto.
-- Relleno ANSI habilitado.
ALTER DATABASE Odyssey SET ANSI_PADDING OFF GO
Si la base de datos genera una advertencia o un error ANSI, como por ejemplo una división por cero, podemos suprimir el efecto de estos mensajes estableciendo la propiedad “Advertencias ANSI” a false. En esos casos, en lugar de retornar un mensaje de error, el sistema devolverá un valor NULL: -- Advertencias ANSI habilitadas.
ALTER DATABASE Odyssey SET ANSI_WARNINGS OFF GO
Si hemos habilitado las advertencias ANSI en nuestra base de datos, y realizamos una división por cero, o cualquier otra operación aritmética no permitida, el batch que esté ejecutando ese código fallará y se detendrá su ejecución. Para evitar esto, podemos indicar a SQL Server que no habilite la “Anulación aritmética”:
-- Anulación aritmética habilitada.
ALTER DATABASE Odyssey SET ARITHABORT OFF GO
Normalmente, cualquier base de datos en producción está activa en un régimen de 24x7. Sin embargo, puede haber situaciones en las que no nos interese que ese sea el estado de la base de datos, pues esta no contiene información crítica, sino información de análisis que es consultada de manera esporádica por los usuarios. En esos casos, si la base de datos está cerrada cuando no está siendo usada no consumirá recursos de servidor. Lo habitual es que el cierre automático esté deshabilitado, y es su valor por defecto:
-- Cierre automático de la base de datos.
ALTER DATABASE Odyssey SET AUTO_CLOSE OFF GO
En ocasiones, puede ocurrir que el volumen de los datos almacenados se reduzca, debido a procesos periódicos de archivo de datos históricos, o cualquier otra razón. En esos casos podemos hacer que nuestra base de datos reduzca automáticamente su tamaño habilitando la reducción automática de la misma. En todo caso, lo más adecuado es desactivar esta opción ya que, una vez hemos reducido el
volumen de datos, la propia actividad del negocio que soporta hará que el volumen de datos vuelva a crecer y ocupe el espacio liberado.
-- Reducir automáticamente
ALTER DATABASE Odyssey SET AUTO_SHRINK OFF GO
Cuando queremos recuperar datos de alguna tabla, SQL Server utiliza unas estadísticas sobre los datos de la tabla para ejecutar la lectura de los datos de la manera más eficiente. Si las estadísticas no están disponibles a la hora de ejecutar una consulta, y queremos que SQL Server 2008 las cree automáticamente si se produce ese caso, debemos habilitar la creación automática de estadísticas: -- Crear estadísticas automáticamente.
ALTER DATABASE Odyssey SET AUTO_CREATE_STATISTICS ON GO
Las estadísticas se crean para cada tabla o índice de una base de datos de SQL Server, tomando muestras de los datos almacenados. Cuando añadimos o modificamos los datos, las estadísticas pueden no resultar válidas, por no responder a un modelo adecuado. En estos casos, las estadísticas deben actualizarse para que las consultas que se realizan sobre los datos sigan siendo lo más eficiente posible. Podemos elegir entre actualizar las estadísticas manual o automáticamente. Esta última opción suele ser la más adecuada ya que, aunque impone cierta pérdida de eficiencia en operaciones de edición de datos, esta se ve compensada por el aumento de eficacia a la hora de recuperar los datos. -- Actualizar estadísticas automáticamente
ALTER DATABASE Odyssey SET AUTO_UPDATE_STATISTICS ON GO
Otra opción sobre las estadísticas es la de actualización automática y asíncrona. Esta opción es similar a la anterior, solo que implica que la consulta que origina la actualización de las estadísticas no espera a que las estadísticas de los objetos a los que accede se actualicen, sino que se ejecuta directamente. Aún así, las estadísticas se actualizan en paralelo.
-- Actualizar estadísticas automática y asíncronamente.
ALTER DATABASE Odyssey SET AUTO_UPDATE_STATISTICS_ASYNC OFF GO
Un cursor es un tipo de repositorio de datos especial, ya que existe sólo durante su ámbito de definición. En realidad, es una tabla temporal que reside en memoria y aporta ciertas características operativas. El tiempo de vida lo determinamos nosotros. Una de las opciones es que el cursos se cierre automáticamente cuando la operación en la que está implicado se confirma o deshace.
-- Cierre de cursor al confirmar habilitado.
ALTER DATABASE Odyssey SET CURSOR_CLOSE_ON_COMMIT OFF GO
Un cursor puede existir en un ámbito local o global. En SQL Server, la diferencia entre local y global está en que local se refiere a que el objeto está disponible solo para la sesión que lo crea, mientras que global está disponible para todas. Si creamos un cursor global, este podrá ser utilizado por numerosas aplicaciones, y no solo por la que lo cree.
-- Cursor predeterminado.
ALTER DATABASE Odyssey SET CURSOR_DEFAULT GLOBAL GO
Si estamos concatenando campos de caracteres, y establecemos la opción Concatenar valores NULL produce NULL a true, si uno de los campos que estamos concatenando contiene un valor NULL, el resultado de toda la concatenación será NULL. Por tanto, salvo alguna razón de peso, lo mejor es tener esa opción deshabilitada.
-- Concatenar valores NULL produce NULL.
ALTER DATABASE Odyssey SET CONCAT_NULL_YIELDS_NULL OFF GO
Cuando estamos trabajando con algún tipo de dato numérico existe la posibilidad de perder precisión al realizar operaciones aritméticas. Si establecemos la opción Anulación exacta numérica a false, el dato se truncará, sin embargo si lo establecemos a true, se generará un error y la operación no se realizará.
-- Anulación exacta numérica.
ALTER DATABASE Odyssey SET NUMERIC_ROUNDABORT OFF GO
En teoría, todos los nombres de objetos (identificadores) deben cumplir una serie de reglas. En ese caso, el identificador se dice que es regular. Sin embargo, SQL Server también admite identificadores no regulares, como por ejemplo aquellos que tienen un espacio en medio, o que comienzan por un carácter numérico. Lo único que tenemos que hacer es encerrar todo el nombre entre corchetes. También es posible utilizar comillas dobles en lugar de corchetes para hacer referencia al objeto de identificador no regular, sin embargo, para eso debemos activar la opción “Identificadores entre comillas”. En cualquier caso, esto no suele ser demasiado útil, ya que hemos de tener en cuenta que los identificadores se utilizan para hacer referencia a los objetos en consultas que se lanzan desde aplicaciones externas escritas en algún lenguaje de programación como C# (C Sharp), o Visual Basic .NET, y lo más habitual es que todos esos lenguajes utilicen las comillas dobles para representar las cadenas de texto.
-- Identificadores entre comillas deshabilitados.
ALTER DATABASE Odyssey SET QUOTED_IDENTIFIER OFF GO
La siguiente opción es relativa a los desencadenadores (triggers). Un desencadenador es un objeto similar a un procedimiento almacenado, con la diferencia de que este no puede ser invocado explícitamente en ninguna instrucción, sino que se ejecuta automáticamente en respuesta a alguna acción que previamente hemos especificado. Una característica de estos objetos es que, debido a su carácter automático, la ejecución de un desencadenador puede provocar la ejecución de otro, y este a su vez la ejecución de un tercero, y así sucesivamente. Este hecho seguramente provocará la para da del servidor debido a falta de recursos para llevar a cabo todos los procesos automáticos. Si queremos que esto no ocurra, debemos establecer la opción “Desencadenadores recursivos habilitados” a false. -- Desencadenadores recursivos deshabilitados.
ALTER DATABASE Odyssey SET RECURSIVE_TRIGGERS OFF GO
Cuando se activa la “Optimización de correlación de fechas”, SQL Server 2008 mantiene las estadísticas de correlación entre dos tablas cualesquiera de la base de datos que estén vinculadas mediante una clave externa y tengan algún campo de tipo DATETIME.
-- Optimización de correlación de fechas habilitada.
ALTER DATABASE Odyssey SET DATE_CORRELATION_OPTIMIZATION ON GO
Puede que en algún momento queramos habilitar una copia de una base de datos para que los usuarios puedan consultarla, pero no modificarla. Esto podemos conseguirlo habilitando la opción “Base de datos de solo lectura”. (Las opciones de T-SQL con READ_ONLY y READ_WRITE).
-- Base de datos de solo lectura.
ALTER DATABASE Odyssey SET READ_ONLY GO
Otra opción de la base de datos es la de “Restringir acceso”. Esta opción establece el acceso por parte de todos los usuarios a la base de datos, y admite tres valores posibles: Multiusuario, Monousuario y Acceso Restringido. El valor habitual es el de multiusuario. Podemos utilizar, por ejemplo, la opción Acceso Restringido para impedir que los usuarios no puedan acceder a la base de datos después de un fallo en el sistema, o alguna otra situación que requiera que el administrador realice las tareas de comprobación correspondientes para asegurarse de que todo funciona correctamente. Una vez hecho, el administrador volverá a habilitar el acceso a todos los usuarios. (Las opciones de T-SQL son MULTI_USER, SINGLE_USER y RESTRICTED_USER).
-- Restringir acceso a la base de datos.
ALTER DATABASE Odyssey SET MULTI_USER GO
En ocasiones puede ocurrir algún error de lectura o escritura en el dispositivo de almacenamiento físico. En esos casos conviene utiliza la opción de comprobación de página, ya que esto permite detectar y avisar de este tipo de errores. Las opciones son NONE, CHECKSUM y TORN_PAGE_DETECTION.
-- Verificación de páginas.
ALTER DATABASE Odyssey SET PAGE_VERIFY CHECKSUM GO
Otra de las opciones es la relativa a las cadenas de propiedad entre bases de datos. Cuando la habilitamos, la base de datos puede constituir el origen o el destino de una cadena de propiedad entre bases de datos. Si está deshabilitada, la base de datos no puede participar en el encadenamiento de propiedad entre bases de datos.
-- Encadenamiento de propiedad entre bases de datos. ALTER DATABASE Odyssey SET DB_CHAINING OFF GO
La última de estas opciones se refiere a la seguridad de la base de datos. La opción “De confianza”, si se habilita, permite que los ensamblados desarrollados con .NET que utilizan un contexto de suplantación tengan acceso a recursos externos a la base de datos, como el sistema de archivos del servidor. Por defecto, este valor está deshabilitado.
-- De confianza
ALTER DATABASE Odyssey SET TRUSTWORTHY ON GO
Grupos de archivos
Como ya hemos visto, SQL Server 2008 asigna una base de datos a un conjunto de archivos que se ubican en la estructura de archivos del sistema operativo. Estos archivos se pueden organizar, dentro de SQL Server, en objetos llamados grupos de archivos. Los grupos de archivos son colecciones con
nombre de archivos de datos que se utilizan en tareas de colocación de los datos, operaciones de copia de seguridad o restauración, y demás tareas administrativas. El ámbito de acción de los grupos de archivos es interno a SQL Server.
Existen dos tipos de grupos de archivos:
Principal: el grupo de archivos principal contiene el archivo de datos principal y los demás archivos asignados específicamente a este grupo de archivos. Todas las páginas de las tablas de sistema están asignadas al grupo de archivos principal. Su nombre por defecto es PRIMARY.
Definidos por el usuario: los grupos de archivos definidos por el usuario son grupos de archivos especificados mediante la palabra clave FILEGROUP en las instrucciones CREATE o ALTER DATABASE.
Los archivos de registro nunca pueden formar parte de un grupo de archivos. El espacio del registro se administra de forma independiente del espacio de datos.
Ningún archivo puede pertenecer a más de un grupo de archivos. Las tablas, los índices y los datos de objetos grandes se pueden asociar a un grupo de archivos específico. En ese caso, todas sus páginas se asignarán a dicho grupo de archivos. Los datos de las tablas e índices con particiones se dividen en unidades y cada una de ellas se puede colocar en un grupo de archivos independiente de una base de datos.
Cuando se crea una tabla o un índice sin especificar un grupo de archivos, se supone que todas las páginas se asignarán a partir del grupo de archivos predeterminado. Sólo un grupo de archivos puede ser el predeterminado, y éste puede ser cambiado por usuarios que sean miembros de la función fija de base de datos db_owner.
Creación de un grupo de archivos
Se pueden crear grupos de archivos cuando se crea la base de datos, o bien posteriormente, cuando se agregan más archivos a la base de datos. Sin embargo, una vez se han creado y agregado los archivos a la base de datos no es posible moverlos a otro grupo de archivos. En cada base de datos pueden crearse hasta 32.767 grupos de archivos, los cuales, como ya he dicho, solo pueden contener archivos de datos.
Debe quedar claro que no es posible crear grupos de archivos independientemente de los archivos de la base de datos. El grupo de archivos es un objeto administrativo que sirve para agrupar los archivos dentro de la base de datos con propósitos administrativos.
Al crear la base de datos podemos especificar los archivos de datos que queremos asignar a la misma, y por tanto, también podemos especificar el grupo de archivo a los que pertenece cada archivo de datos. El procedimiento se puede realizar tanto con la ventana de creación de Nueva base de datos, disponible desde el Management Studio, o bien haciendo uso de código Transact-SQL. Los dos métodos los hemos tratado al comienzo de este capítulo, por lo que se puede consultar la sección correspondiente para repasar los ejemplos.
Sin embargo, también es posible crear los grupos de archivos una vez creada la base de datos. Esto lo haremos al agregar un nuevo archivo de datos. Conviene volver a remarcar que, una vez hemos asignado un archivo a un determinado grupo, no podremos asignarlos posteriormente a otro. Por tanto, debemos tener claro cuál será la disposición de los archivos dentro de los grupos.
-- Crear un nuevo grupo de archivos. ALTER DATABASE Odyssey
ADD FILEGROUP OD2001 GO
-- Añadir un archivo de base de datos a un grupo de archivos. ALTER DATABASE Odyssey
ADD FILE ( NAME = 'Odyssey_2001', FILENAME = 'C:\BBDD\Odyssey_2001.NDF', SIZE = 5, MAXSIZE = UNLIMITED, FILEGROWTH = 5% )
Uso de los grupos de archivos
Los grupos de archivos utilizan una estrategia de relleno proporcional entre todos los archivos que lo forman. A medida que se añaden datos al grupo de archivos, el motor de base de datos escribe una cantidad proporcional al espacio libre de cada archivo. De esa manera, todos los archivos se irán llenando al mismo tiempo y por igual.
Si tenemos un grupo de archivos formado por varios archivos que tienen habilitado el crecimiento automático, SQL Server también aprovecha esta característica. Cuando se llenen todos los archivos, el motor relacional ampliará la capacidad del primer archivo. Cuando este se llene ampliará el segundo, y así sucesivamente. Al llegar al final, comenzará de nuevo el ciclo.
El uso de grupos de archivos también permite mejorar el rendimiento de la base de datos. La razón es que, al crear los archivos que componen el grupo, podemos ubicar cada uno en distintas unidades de disco. Por ejemplo, si nuestro servidor tiene cuatro unidades de disco, podemos crear un archivo de registro y tres archivos de datos, y colocar cada archivo en una unidad diferente. Al acceder a los datos del disco, existen cuatro unidades que pueden acceder a los datos en paralelo, es decir, a la vez, con lo que se aceleran todas las operaciones de la base de datos. Si además combinamos esta estrategia con un sistema de dispositivos RAID, las cifras de aumento de rendimiento pueden rondar el 40%, en relación a sistemas idénticos que no utilicen esos dispositivos.
Además, los grupos de archivos permiten elegir en que grupo queremos colocar una determinada tabla, o incluso sus índices. De ese modo, el rendimiento aumenta dado que todas las operaciones de lectura y escritura para una tabla específica pueden dirigirse a un disco específico. Suele ser bastante habitual crear dos grupos de archivos: uno para las tablas que gestionan datos críticos, y otro para las tablas menos utilizadas. O incluso, si nuestra infraestructura lo permite, crear varios grupos de archivos para repartir en ellos las tablas críticas.
Otro de los beneficios de los grupos de archivos resulta al implementar estrategias de copia de seguridad y restauración de bases de datos. En SQL Server 2008, las bases de datos formadas por varios grupos de archivos se pueden restaurar por partes mediante un proceso denominado restauración por etapas. La restauración por etapas funciona con todos los modelos de recuperación, aunque el modelo que menos adecuado resulta en estos casos es el modelo de recuperación simple. Cuando se utilizan varios grupos de archivos es posible hacer una copia de seguridad y una restauración individual de los archivos de una base de datos. En el modelo de recuperación simple, las copias de seguridad de los archivos sólo se permiten para los archivos de solo lectura. El uso de las
copias de seguridad de archivos puede aumentar la velocidad de recuperación, dado que nos permite recuperar sólo los archivos de datos, y no tener que recuperar la base de datos completa.
No conviene hacer un esfuerzo desmedido en el diseño de los grupos de archivos para una base de datos, si esta no requiere una alta disponibilidad, o el rendimiento no es crítico, ya que la mayor parte de las bases de datos funcionarán correctamente con un solo archivo de datos y otro de registro de transacciones.
Si utilizamos varios archivos, conviene crear un segundo grupo de archivos para los archivos adicionales y convertir este grupo en el predeterminado. De esa manera, todos los objetos que se creen, como nuevas tablas o índices, irán a parar a ese grupo de archivos, por lo que el archivo principal de la base de datos sólo almacenará las tablas y objetos de sistema.
También podemos utilizar los grupos de archivos para mejorar el rendimiento de las consultas, ya que si colocamos las tablas que intervienen en una consulta de combinación en diferentes unidades de disco, SQL Server podrá acceder a ellas en paralelo.
Otra de las utilidades de los grupos de archivos es la relativa a los índices. Al desarrollar la estrategia de diseño del índice, debemos tener en cuenta la ubicación de los índices en los grupos de archivos, ya que esto puede mejorar el rendimiento de las consultas.
De forma predeterminada, los índices se almacenan en el mismo grupo de archivos que la tabla base en la que se crea el índice. Un índice agrupado sin particiones siempre se encuentra en el mismo grupo de archivos, y no existe ninguna opción para modificar eso. Pero aún así, tenemos otras opciones. Si creamos los índices agrupados en un grupo de archivos diferente que en el que se encuentra la tabla a la que hace referencia, y ambos grupos de archivos utilizan distintas unidades físicas con su propia controladora, o distintas unidades de reflejo en un sistema RAID, la información del índice puede leerse a la vez que la información de la tabla. Esta operación tendríamos que repetirla para cada tabla, teniendo en cuenta los índices de cada una. Como eso es impensable, lo más adecuado consiste en repartir todas las tablas e índices en todos los grupos de archivos. Esto garantiza el acceso a todos los discos, ya que todos los datos e índices están repartidos por igual entre todos los discos independientemente de la forma de acceso a los datos. Además, facilita el trabajo al administrador de sistema.
Otra de las ventajas de los grupos de archivos es que cada grupo se puede marcar como sólo lectura, sin que esto afecte al resto de grupos asociados a la base de datos. El único grupo de archivos que no admite esta opción es el principal, por razones obvias. Esto resulta útil si nuestra base de datos no es lo suficientemente voluminosa como para que el conjunto de datos históricos justifique el crear una nueva base de datos. En ese caso, con el simple hecho de agrupar todas las tablas de histórico en un grupo de archivos es suficiente, ya que configurando el grupo de archivos como de sólo lectura, nos aseguraremos de que nadie puede modificarlos accidentalmente.
La configuración de un grupo de archivos como de solo lectura permite, como ventaja adicional, comprimir los datos contenidos en él, haciendo uso de la compresión NTFS. SQL Server es compatible con la compresión NTFS en caso de utilizar un grupo de archivos de sólo lectura, o de que la base de datos entera sea de sólo lectura. Para poder comprimir una base de datos que cumpla uno de los dos requisitos, además la base de datos debe estar sin conexión. Las bases de datos de sistema son las únicas que no admiten compresión.
Esquemas
Una vez hemos creado la base de datos, el modelo de la misma debe indicarnos el conjunto de objetos que debemos crear. Podemos crear todos esos objetos como si fueran pequeñas porciones de una solución global. Sin embargo, si esos objetos se pudieran clasificar en subconjuntos dentro de esa solución global, probablemente todo sería mucho más fácil, ya que, por ejemplo, podríamos crear agrupaciones de tablas por departamento.
Estos conjuntos reciben el nombre de esquemas en SQL Server 2008, y son fundamentales en la gestión de la seguridad de los objetos de una base de datos. En definitiva, un esquema es un grupo de objetos, que puede ser utilizado para conceder o denegar permisos a determinados usuarios. Estos permisos serán efectivos sobre todos los objetos que estén incluidos en el esquema.
En versiones anteriores a SQL Server 2008, los objetos eran propiedad de una cuenta de usuario. Esto significaba que, si la cuenta de usuario era dada de baja, había que trasladar la propiedad de cada objeto a otra cuenta. En función del tamaño del sistema, es decir, del número de objetos que hubiese que manipular, estas tareas podían consumir grandes cantidades de tiempo.
Con la inclusión de los esquemas en SQL Server 2008, cada objeto es propiedad de un esquema. Aunque cada esquema es, a su vez, propiedad de un usuario de base de datos, el número de esquemas que podamos tener en un sistema, por muy grande que este sea, será muy inferior al número de objetos que éste contenga, por lo que si una cuenta de usuario es eliminada, las tareas administrativas que eso conlleva se reducen enormemente.
Por tanto, el hecho de tener esquemas dentro de nuestra solución, y asignar todos los objetos a algún esquema, permite no sólo mejorar las tareas administrativas, o aumentar la seguridad, sino también que nuestra solución sea más fácil de entender y de utilizar, ya que tendremos los objetos organizados en unidades lógicas, que están representadas por los esquemas.
El hecho de utilizar esquemas nos obliga a utilizar nombres completos al referirnos a los objetos. Al utilizar cualquier objeto en un script de código T-SQL, debemos hacer referencia a él indicando primero el esquema al que pertenece. Esto es así, debido a que los esquemas nos dan la posibilidad de que podamos tener dos objetos con el mismo nombre en la misma base de datos, siempre y cuando pertenezcan a esquemas diferentes. De hecho, para referirnos a los objetos de la base de datos, debemos utilizar el esquema al que pertenecen.
Como usuarios de la base de datos, podemos tener asignada la pertenencia de uno o varios esquemas dentro de la base de datos. En ese caso, no será necesario que hagamos referencia al esquema, simplemente nos hará falta referenciar al objeto. A pesar de esto, debido a que diferentes usuarios serán propietarios de diferentes esquemas, lo mejor que podemos hacer es escribir todas nuestras consultas utilizando los nombres de esquema.
-- Uso de los esquemas en consultas. USE AdventureWorks
GO
SELECT c.FirstName, c.LastName, e.Title, sp.SalesYTD FROM HumanResources.Employee AS e
INNER JOIN Person.Contact AS c ON e.ContactID = c.ContactID
INNER JOIN Sales.SalesPerson AS sp ON e.EmployeeID = sp.SalesPersonID GO
anterior no sería necesario hacer referencia a la tabla SalesPerson si la ejecutáramos bajo el contexto de seguridad del usuario Hugo.
El estándar ANSI para el lenguaje SQL define de alguna manera el concepto de esquema. Ese concepto ha sido incluido en anteriores versiones de SQL Server, pero no como tal, sino como parte del usuario de base de datos. Otros sistemas de bases de datos relacionales, tales como Oracle, también hacen uso de los esquemas. Sin embargo, SQL Server 2008 da mucha importancia a los esquemas, ya que no sólo se utilizan como simples objetos organizativos, sino que también intervienen en otras facetas de SQL Server, como por ejemplo los Servicios de Notificación.
El esquema por defecto para toda base de datos es el dbo. Este esquema tiene un usuario correspondiente, que es aquél que ha creado la base de datos. Si este usuario crea una tabla en la base de datos sin especificar un esquema para ella, se le asignará por defecto al esquema dbo. Si el usuario Hugo (volviendo al escenario de ejemplo) crea una tabla en la base de datos AdventureWorks llamada Pedidos, el nombre cualificado para este objeto será Sales.Pedidos, ya que Sales es el esquema por defecto para ese usuario.
