MODULO I 

Tema 3: Elementos adicionales para el diseño una base de datos SQL Server

Lo que aprenderá:

Al terminar este tema usted podrá:
· Describir los factores que se deben tener en cuenta al diseñar una base de datos SQL Server.

Al diseñar una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos de la base de datos y grupos de archivos, registros de transacciones, la instalación del SQL Server y su ambiente operativo, y la seguridad. Esta lección discute cada uno de estos temas.

Archivos y Grupos de archivos
Para definir una base de datos, SQL Server 2000 usa un conjunto de archivos del sistema operativo. Todos los datos y objetos de la base de datos, como tablas, procedimientos almacenados, desencadenadores, y vistas, se guardan dentro de los siguientes tipos de archivos del sistema operativo:
· Archivo Primario. Este archivo contiene la información de arranque para la base de datos y es usado para almacenar datos. Cada base de datos tiene un archivo de los datos primario.
· Archivo Secundario. Estos archivos mantienen todos los datos que no caben en el archivo de los datos primario. Si el archivo primario puede almacenar todos los datos da la base de datos, las bases de datos no necesitan tener archivos de los datos secundarios. Algunas bases de datos podrían ser lo suficientemente grandes para necesitar archivos de datos secundarios múltiples o usar archivos secundarios en unidades de disco separadas para distribuir datos en múltiples discos o para mejorar el rendimiento de la base de datos.
· Registros de transacciones. Estos archivos mantienen la información del registro que se usa para recuperar la base de datos. Debe haber por lo menos un archivo de registro para cada base de datos.

Una base de datos simple puede crearse con un archivo primario que contiene todos los datos y objetos y un archivo de registro que contiene la información del registro de transacciones.

Alternativamente, una base de datos más compleja puede crearse con un archivo primario y cinco archivos secundarios. Los datos y objetos de la base de datos son distribuidos por los seis archivos, y cuatro archivos de registro adicionales contienen la información del registro de transacciones.

Los grupos de archivos agrupan archivos para propósitos administrativos y de ubicación de datos. Por ejemplo, tres archivos (Data1.ndf, Data2.ndf, y Data3.ndf) pueden crearse en tres unidades de disco y pueden asignarse al grupo de archivos fgroup1. Una tabla puede crearse entonces específicamente en el grupo de archivos fgroup1. Las consultas sobre los datos de la tabla se extenderán por los tres discos y se mejorará el rendimiento. La misma mejora de rendimiento puede lograrse con un solo archivo creado sobre un arreglo redundante de discos independientes (RAID).

Los archivos y grupos de archivos, sin embargo, ayudan a agregar nuevos archivos fácilmente a los nuevos discos. Adicionalmente, si su base de datos excede el tamaño del máximo para un solo archivo Windows NT, usted puede usar un archivo de datos secundario para permitir el crecimiento de su base de datos.

Reglas para diseñar Archivos y Grupos de archivos

Cuando usted diseña archivos y grupos de archivos, debe adherir a las reglas siguientes:
· Un archivo o grupo de archivos no puede ser usado por más de una base de datos. Por ejemplo, los archivos que ventas.mdf y ventas.ndf que contienen datos y objetos de la base de datos de ventas no pueden ser usados por cualquier otra base de datos.
· Un archivo puede ser un miembro de sólo un grupo de archivos.
· Los datos y la información de registro de transacción no pueden ser parte del mismo archivo o grupo de archivos.
· Los archivos de registro de transacciones nunca son parte de un grupo de archivos.

Grupos de archivos predefinidos

Una base de datos comprende un grupo de archivos primario y varios grupos de archivo definidos por el usuario. El grupo de archivos que contiene el archivo primario es el grupo de archivos primario. Cuando una base de datos se crea, el grupo de archivos primario contiene el archivo de datos primario y cualquier otro archivo que no se pone en otro grupo de archivos. Todas las tablas del sistema se asignan en el grupo de archivos primario. Si el grupo de archivos primario se queda sin espacio, ninguna información nueva del catálogo puede agregarse a las tablas del sistema. El grupo de archivos primario sólo se llenará si la bandera de configuración "autogrow" está apagada o si todos los discos que están sosteniendo los archivos en el grupo de archivos primario se quedaron sin espacio. Si sucede esto, se deberá encender la bandera de configuración "autogrow" o mover archivos a un nuevo almacenamiento para liberar mas espacio.

Los grupos de archivos definidos por el usuario son cualquier grupo de archivos que son específicamente creados por el usuario cuando él o ella están inicialmente creando o posteriormente alterando la base de datos. Si un grupo de archivos definido por el usuario se llena, se afectarán sólo las tablas de los usuarios específicamente asignadas a ese grupo de archivos.

En cualquier momento, un grupo de archivos puede ser designado como el grupo de archivos predefinido. Cuando se crean objetos en la base de datos sin especificar a que grupo de archivos pertenecen, se asignan al grupo de archivos predefinido. Los grupos de archivos predefinidos deben ser suficiente grandes para almacenar cualquier objeto no asignado a un grupo de archivos definido por el usuario. Inicialmente, el grupo de archivos primario es el grupo de archivos predefinido.
Los grupos de archivos predefinidos pueden ser cambiados usando la sentencia ALTER DATABASE. Cuando usted cambia el grupo de archivos predefinido, cualquier objeto que no tiene un grupo de archivos especificado se asigna a los archivos de los datos en el nuevo grupo de archivos predefinido cuando se crea. La asignación para los objetos y tablas del sistema, sin embargo, se mantiene en el grupo de archivos primario y no en el nuevo grupo de archivos predefinido.
Cambiar el grupo de archivos predefinido previene que objetos del usuario que no se crean específicamente en un grupo de archivos definidos por el deban competir con los objetos y tablas del sistema para el espacio de los datos.

Recomendaciones

Al implementar una base de datos, usted debe intentar adherir a las pautas siguientes para usar archivos y grupos de archivos:
· La mayoría de las bases de datos trabajará bien con un solo archivo del datos y un solo archivo de registro de transacciones.
· Si usted usa archivos múltiples, cree un segundo grupo de archivos para los archivos adicionales y configúrelo como el grupo de archivos predefinido. De esta manera, el archivo primario contendrá sólo tablas y objetos del sistema.
· Para maximizar rendimiento, usted puede crear archivos o grupos de archivos en tantos discos físicos locales disponibles como sea posible, y ubicar grandes objetos que compiten por espacio en grupos de archivos diferentes.
· Use grupos de archivos para habilitar la colocación de objetos en discos físicos específicos.
· Ubique las diferentes tablas que se usan para una misma consulta en grupos de archivos diferente. Este procedimiento mejorará el rendimiento al tomar ventaja del procesamiento paralelo de input/output del disco (I/O) al buscar datos vinculados.
· Ponga las tablas fuertemente accedidas y los índices no-agrupados que pertenecen a esas tablas en grupos de archivos diferentes. Este procedimiento mejorará el rendimiento debido al I/O paralelo si los archivos se localizan en discos físicos diferentes.
· No ponga el archivo de registro de transacciones en el mismo disco físico con los otros archivos y grupos de archivos.

Registros de transacciones

Una base de datos en SQL Server 2000 tiene por lo menos un archivo de datos y un archivo de registro de transacciones. Los datos y la información del registro de transacciones nunca es mezclada en el mismo archivo, y archivos individuales son sólo por una única base de datos.

El SQL Server usa el registro de transacciones de cada base de datos para recuperar transacciones. El registro de transacciones es un registro serial de todas las modificaciones que han ocurrido en la base de datos así como de las transacciones que realizaron dichas modificaciones. El archivo de registro de transacciones graba el comienzo de cada transacción y archiva los cambios producidos en los datos. Este registro tiene bastante información para deshacer las modificaciones (si es necesario) que hizo durante cada transacción. Para algunas operaciones pesadas, como CREATE INDEX, el registro de transacciones registra, en cambio, los hechos a los que la operación dio lugar. El registro crece continuamente tanto como operaciones ocurran en la base de datos.
El registro de transacciones graba la asignación y liberación de las páginas y la grabación definitiva (commit) o la vuelta atrás (rollback) de cada transacción. Este capacidad permite al SQL Server rehacer (Rollup) o deshacer (Rollback) cada transacción de las siguientes maneras:
· Una transacción es rehecha cuando se aplica un registro de transacciones. El SQL Server copia la imagen posterior a cada modificación de la base de datos o vuelve a ejecutar sentencias como CREATE INDEX. Estas acciones se aplican en el mismo orden en la que ellas ocurrieron originalmente. Al final de este proceso, la base de datos está en el mismo estado que estaba en el momento en que el registro de transacciones fue copiado.
· Una transacción se deshace cuando una transacción queda incompleta por alguna causa. El SQL Server copia la imagen previa de todas las modificaciones a la base de datos desde el BEGIN TRANSACTION. Si encuentra archivos de registro de transacciones que indican que un CREATE INDEX fue ejecutado, realiza operaciones que lógicamente invierten la sentencia. Éstos imágenes previas Ye inversiones del comando CREATE INDEX son aplicados en orden inverso a la secuencia original.

A un punto de salvaguarda, el SQL Server asegura que se han grabado en el disco todos los archivos de registro de transacciones y las páginas de la base de datos que se modificaron. Durante cada proceso de recuperación de base de datos, que ocurre cuando el SQL Server se reinicia, una transacción necesita ser rehecha sólo si no se conoce si todas las modificaciones de datos de la transacción fueron realmente transferidas desde el caché de SQL Server al disco. Debido a que en un punto de salvaguarda se obliga a que todas las páginas modificadas sean efectivamente grabadas en el disco, este representa el punto que se toma como punto de inicio para el comienzo de las operaciones de recuperación. Dado que para todas las páginas modificadas antes del punto de salvaguarda se garantiza que están en el disco, no hay ninguna necesidad de rehacer algo que se hizo antes del punto de salvaguarda.

Las copias de respaldo del registro de transacciones le permiten a usted que recupere la base de datos al momento de un punto específico (por ejemplo, previo a entrar en datos no deseados) o a un punto de falla. Las copias de respaldo del registro de transacciones deben ser tenidas muy en cuenta dentro de su estrategia de recuperación de bases de datos.

Ambiente

Generalmente, cuanto más grande es la base de datos, mayores son los requisitos de hardware. El diseño de la base de datos siempre debe tomar en cuenta la velocidad del procesador, el tamaño de la memoria, y el espacio del disco duro y su configuración. Hay otros factores determinantes, sin embargo: el número de usuarios o sesiones coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la base de datos. Por ejemplo, una base de datos que contiene datos de la biblioteca escolar con escasos niveles de actualización generalmente tendrá requisitos de hardware más bajos que un almacén de datos de un-terabyte que contiene ventas, productos, e informaciones de los clientes frecuentemente analizados, para una gran corporación. Aparte de los requisitos de almacenamiento de disco, se necesitará más memoria y procesadores más rápidos para levantar en memoria grandes volúmenes de datos del almacén de datos y procesar mas rápidamente las consultas.

Estimar el Tamaño de una base de datos

Al diseñar una base de datos, usted podría necesitar estimar cuán grande será la base de datos cuando este llena de información. Estimar el tamaño de la base de datos puede ayudarle a determinar la configuración del hardware que usted necesitará para alcanzar los siguientes requisitos:
· Lograr el rendimiento requerido por sus aplicaciones
· Asegurar la cantidad física apropiada de espacio en disco para guardar los datos y índices

Estimar el tamaño de una base de datos también puede llevarlo a determinar si el diseño de la base de datos necesita mayor refinamiento. Por ejemplo, usted podría determinar que el tamaño estimado de la base de datos es demasiado grande para ser implementada en su organización y que requiere mayor normalización. Recíprocamente, el tamaño estimado podría ser más pequeño que el esperado, permitiendo denormalizar en cierto grado la base de datos para mejorar el rendimiento de las consultas.

Para estimar el tamaño de una base de datos, estime el tamaño de cada tabla individualmente y sume dichos valores. El tamaño de una tabla depende si la tabla tiene o no índices y, en este caso, qué tipo de índices.

Diseño físico de la base de datos

El subsistema de entrada/salida (motor de almacenamiento) es un componente importante de cualquier base de datos relacional. Una aplicación de base de datos exitosa normalmente requiere una planificación cuidadosa en las fases tempranas de su proyecto. El motor de almacenamiento de una base de datos relacional requiere de esta planificación que incluye a lo siguiente:
· Qué tipo de hardware de disco será utilizado
· Cómo distribuye sus datos en los discos
· Qué diseño de índices se va a utilizar para mejorar el rendimiento de las consultas.
· Cómo se van a configurar apropiadamente todos los parámetros de configuración para que la base de datos funcione correctamente.

Instalación de SQL Server

Aunque la instalación de SQL Server está más allá del alcance de este Kit de Entrenamiento, usted siempre debe tener en cuenta lo siguiente antes de realizar una instalación:
· Esté seguro que la computadora reúne los requisitos de sistema para SQL Server 2000.
· Haga copias de respaldo de su instalación actual de Microsoft SQL Server si usted está instalando SQL Server 2000 en la misma computadora.
· Si usted está instalando un failover cluster, desactive el NetBIOS en todas las tarjetas de la red privada antes de ejecutar el instalador de SQL Server.
· Repase todas las opciones de instalación de SQL Server y este preparado para hacer las selecciones apropiadas cuando ejecute el instalador.
· Si usted está usando un sistema operativo que tiene configuraciones regionales diferentes a inglés (Estados Unidos), o si usted está personalizando el juego de caracteres o la configuración del ordenamiento de los caracteres, revise los temas referidos a la configuración de colecciones.
Antes de ejecutar el instalador de SQL Server 2000, cree uno o más cuentas de usuario del dominio si usted está instalando SQL Server 2000 en una computadora con Windows NT o Windows 2000 y quiere que SQL Server 2000 se comunique con otros clientes y servidores.

Usted debe iniciar el sistema operativo bajo una cuenta de usuario que tiene permisos locales de administrador; por otra parte, usted debe asignar los permisos apropiados a la cuenta de usuario de dominio. Esté seguro de cerrar todos los servicios dependientes sobre SQL Server (incluso cualquier servicio que usa ODBC, como el Internet Information Server, o IIS). Además, cierre al Windows NT Event Viewer y a los visualizadores de la registry (Regedit.exe o Regedt32.exe).

Seguridad

Una base de datos debe tener un sistema de seguridad sólido para controlar las actividades que pueden realizarse y determinar qué información puede verse y cuál puede modificarse. Un sistema de seguridad sólido asegura la protección de datos, sin tener en cuenta cómo los usuarios obtienen el acceso a la base de datos.

Planificar la Seguridad

Un plan de seguridad identifica qué usuarios pueden ver qué datos y qué actividades pueden realizar en la base de datos. Usted debe seguir siguientes los pasos para desarrollar un plan de seguridad:
· Liste todas los items y actividades en la base de datos que debe controlarse a través de la seguridad.
· Identifique los individuos y grupos en la compañía.
· Combine las dos listas para identificar qué usuarios pueden ver qué conjuntos de datos y qué actividades pueden realizar sobre la base de datos.

Niveles de seguridad

Un usuario atraviesa dos fases de seguridad al trabajar en SQL Server: la autenticación y autorización (aprobación de los permisos). La fase de la autenticación identifica al usuario que está usando una cuenta de inicio de sesión y verifica sólo su capacidad para conectarse a un instancia de SQL Server. Si la autenticación tiene éxito, el usuario se conecta a una instancia de SQL Server. El usuario necesita entonces permisos para acceder a las bases de datos en el servidor, lo que se obtiene concediendo acceso a una cuenta en cada base de datos (asociadas al inicio de sesión del usuario). La validación de los permisos permite controlar las actividades que el usuario puede realizar en la base de datos SQL Server.

Modos de autenticación

El SQL Server puede operar en uno de dos modos de seguridad (autenticación): la Autenticación de Windows y el modo Mixto. El modo de Autenticación de Windows le permite a un usuario que se conecte a través de una cuenta de usuario Windows NT 4.0 o Windows 2000. El modo mixto (Autenticación de Windows y Autenticación de SQL) le permite a los usuarios que conecten a una instancia de SQL Server usando Autenticación de Windows o Autenticación de SQL Server. Los usuarios que se conectan a través de una cuenta del usuario Windows NT 4.0 o Windows 2000 pueden hacer uso de conexiones de confianza en el modo de Autenticación de Windows o en el modo mixto.

Resumen del tema

Al diseñar una base de datos SQL Server, se deben tener en cuenta varios factores, que incluyen los archivos de la base de datos y grupos de archivos, registros de transacciones, la instalación del SQL Server y su ambiente operativo, y la seguridad. Todos los datos y objetos de la base de datos, como tablas, procedimientos almacenados, desencadenadores, y vistas, se guardan dentro de los archivos primario, secundarios, dentro del registro de transacciones. Los grupos de archivos agrupan archivos para propósitos administrativos y de ubicación de los datos. El grupo de archivos que contiene el archivo primario es el grupo de archivos primario. Una base de datos en SQL Server 2000 tiene al menos un archivo de datos y un archivo de registro de transacciones. Datos y la información del registro de transacciones nunca se mezclan en el mismo archivo, y los archivos individuales son utilizados por solo una base de datos. El SQL Server usa el registro de transacciones de cada base de datos para recuperar transacciones. El diseño de la base de datos siempre debe tomar en consideración la velocidad de procesador, la memoria, y el espacio del disco duro y su configuración. Hay otros factores determinantes, sin embargo: el número de usuarios o sesiones coexistentes, el registro de transacciones, y los tipos de operaciones a realizar sobre la base de datos Al diseñar una base de datos, usted podría necesitar estimar cuán grande será la base de datos cuando este llena de información. Al instalar SQL Server, usted debe tener en cuenta varios problemas. Una base de datos debe tener un sistema de seguridad sólido para controlar las actividades que pueden o no realizarse y determinar qué información puede verse y cuál puede modificarse. Un diseño de seguridad identifica qué usuarios pueden ver qué datos y qué actividades pueden realizar sobre la base de datos.

< Programa               Tema 4 >