Desarrollar un plan de base de datos
El primer paso al crear una base de datos consiste en elaborar un plan que sirva de guía para la implementación de la base de datos y, al mismo tiempo, como especificación funcional después de su implementación. La complejidad y los detalles de diseño de una base de datos dependen de la complejidad y el tamaño de la aplicación de bases de datos, así como de los usuarios.
La naturaleza y complejidad de una aplicación de bases de datos, así como el proceso de diseño, pueden variar significativamente. Una base de datos puede ser relativamente sencilla y estar diseñada para que la utilice una sola persona, o bien ser grande y compleja, y estar diseñada para procesar, por ejemplo, las transacciones bancarias de miles de clientes. En el primer caso, el diseño de la base de datos puede consistir en poco más que unas anotaciones en un papel. En el segundo caso, el diseño puede ser un documento formal de cientos de páginas que contenga todos y cada uno de los posibles detalles relacionados con la base de datos.
Al diseñar la base de datos, independientemente de su tamaño y complejidad, lleve a cabo los siguientes pasos básicos: * Recopile la información. * Identifique los objetos. * Cree modelos de los objetos. * Identifique los tipos de información para cada objeto. * Identifique las relaciones entre los objetos.
Recopilar la información

Antes de crear una base de datos, debe conocer con detalle el cometido previsto de la base de datos. Si la base de datos va a reemplazar a un sistema de información manual o en papel, dicho sistema le proporcionará la mayor parte de la información que necesita. Debería consultar a todas las personas involucradas en el sistema para determinar lo que hacen y qué necesitan de la base de datos. También es importante identificar qué es lo que desean que haga el nuevo sistema, así como los problemas, las limitaciones y los cuellos de botella del sistema existente. Recopile copias de las instrucciones del cliente, listas de inventarios, informes de administración y, en general, de todos aquellos documentos que formen parte del sistema existente, porque le servirán para diseñar la base de datos y las interfaces.

Identificar los objetos

Durante el proceso de recopilación de información, deberá identificar los objetos o las entidades más importantes que vayan a ser administrados por la base de datos. El objeto puede ser tangible (una persona o un producto, por ejemplo) o bien intangible (como una transacción empresarial, un departamento de una compañía o un período de liquidación de nóminas). Normalmente hay unos cuantos objetos principales; una vez identificados, se evidencian los elementos relacionados. Cada elemento diferenciado de la base de datos debe tener su tabla correspondiente.
El objeto principal de la base de datos de ejemplo AdventureWorks2008R2 que se incluye con SQL Server es una bicicleta. Los objetos relacionados con la bicicleta en las operaciones empresariales de esta compañía son los empleados que fabrican la bicicleta, los proveedores que venden los componentes utilizados para fabricar la bicicleta, los clientes que los compran y las transacciones comerciales realizadas con los clientes. Cada uno de estos objetos es una tabla de la base de datos.
Crear un modelo de los objetos

Cuando se identifican los objetos del sistema, debería registrarlos de una manera que represente visualmente el sistema. Puede utilizar su modelo de base de datos como referencia durante la implementación de la misma.
Con este propósito, los programadores de bases de datos utilizan herramientas que varían en complejidad técnica: desde papel y bolígrafo hasta procesadores de texto y hojas de cálculo e, incluso, programas de software creados específicamente para la elaboración de modelos de datos destinados al diseño de bases de datos. Sea cual sea la herramienta que decida utilizar, es importante que la mantenga actualizada.
Identificar los tipos de información para cada objeto

Una vez identificados los objetos principales de la base de datos como candidatos para las tablas, el siguiente paso es identificar los tipos de información que deben almacenarse para cada objeto. Estos tipos son las columnas de la tabla del objeto. Las columnas de una tabla de base de datos contienen algunos tipos de información comunes: * Columnas de datos sin procesar
Estas columnas almacenan información tangible, como por ejemplo nombres, determinada por un origen externo a la base de datos.

* Columnas de categorías
Estas columnas clasifican o agrupan los datos y almacenan una selección limitada de datos, tales como verdadero o falso; casado o soltero; presidente, director o responsable de equipo; etc. * Columnas de identificadores
Estas columnas proporcionan un mecanismo para identificar cada elemento almacenado en la tabla. Estas columnas suelen incluir un Id. o un número en el nombre (por ejemplo, IdDeEmpleado, númeroDeFactura y IdDeEditor. La columna del identificador es el componente principal para los usuarios y las funciones internas de proceso de la base de datos para el acceso a una fila de datos de la tabla. Algunas veces el objeto tiene una forma tangible de Id. utilizada en la tabla (por ejemplo, un número de la seguridad social), aunque en la mayoría de los casos se puede definir la tabla para poder crear un Id. confiable y artificial para la fila. * Columnas relacionales o diferenciales
Estas columnas establecen un vínculo entre la información de una tabla y la información relacionada que se encuentra en otra tabla. Por ejemplo, una tabla que realiza el seguimiento de transacciones comerciales puede tener un vínculo con una tabla clientes, de modo que pueda asociarse toda la información del cliente a la transacción comercial.
Identificar la relación entre objetos

Uno de los puntos fuertes de una base de datos relacional es la posibilidad de relacionar o asociar información acerca de varios elementos de la base de datos. Pueden almacenarse por separado tipos aislados de información, pero el motor de base de datos puede combinar los datos cuando sea necesario. Para identificar la relación entre los objetos durante el proceso de diseño se necesita llevar a cabo un examen de las tablas con el fin de determinar sus relaciones lógicas y agregar columnas relacionales que establezcan un vínculo entre las tablas.
Por ejemplo, el diseñador de la base de datos AdventureWorks2008R2 ha creado tablas para los productos y modelos de producto de la base de datos. La tabla Production.Product contiene información de cada producto que incluye una columna de identificador denominada ProductID, así como columnas de datos para el nombre, el precio, el color, el tamaño y el peso del producto. La tabla contiene columnas de categorías, como Class o Style, que permiten agrupar los productos por estos tipos. Cada producto tiene también un modelo del producto, pero esa información se almacena en otra tabla. Por lo tanto, la tabla Production.Product tiene la columna ProductModelID solo para almacenar el Id. del modelo del producto. Cuando se agrega una fila de datos para un producto, el valor de ProductModelID debe existir en la tabla Production.ProductModel.

Muchas aplicaciones pertenecen a una de estas dos categorías de aplicaciones de base de datos: * Proceso de transacciones en línea (OLTP, Online Transaction Processing) * Ayuda a la toma de decisiones
Las características de estos tipos de aplicaciones tienen una influencia decisiva en las consideraciones del diseño de una base de datos.
Proceso de transacciones en línea

Las aplicaciones de base de datos de proceso de transacciones en línea son perfectas para administrar datos que cambian con frecuencia. Estas aplicaciones cuentan normalmente con muchos usuarios que realizan transacciones al mismo tiempo que cambian datos en tiempo real. Aunque las solicitudes de datos realizadas individualmente por los usuarios tienden a hacer referencia a pocos registros, muchas de estas peticiones se producen al mismo tiempo. Ejemplos corrientes de estos tipos de bases de datos son los sistemas de reserva de billetes y los de transacciones bancarias. Las principales preocupaciones en este tipo de aplicaciones son la simultaneidad y la atomicidad.
Los controles de simultaneidad de un sistema de base de datos aseguran que dos usuarios no puedan cambiar los mismos datos, o que un usuario no pueda cambiar un dato mientras otro usuario lo esté utilizando. Por ejemplo, si se pone en contacto con una agencia de viajes para reservar la última plaza disponible en un vuelo y el vendedor en cuestión comienza el proceso para reservar la plaza en su nombre, no debe ser posible que otro vendedor pueda informar a otro cliente de que la plaza está disponible.
La atomicidad garantiza que todos los pasos de una transacción se realicen correctamente como un grupo. Si se produce un error en algún paso, no se realizarán los pasos restantes. Por ejemplo, una transacción bancaria puede conllevar dos pasos: sacar los fondos de la cuenta corriente y colocarlos en la cuenta de los ahorros. Si el paso en el que se realiza el cargo en la cuenta corriente se cumple satisfactoriamente, deseará asegurarse de que la misma cantidad se ingresa en su cuenta de ahorro o se reintegra a la cuenta corriente.

Consideraciones acerca del diseño de procesos de transacciones en línea

Las bases de datos de proceso de transacciones deben diseñarse de manera que promuevan lo siguiente: * Una ubicación correcta de los datos
Los puntos de congestión de E/S son motivo de especial preocupación cuando se diseñan sistemas OLTP, debido al número de usuarios que modifican datos de la base de datos. Al diseñar una base de datos, debe determinar los patrones de acceso a los datos más probables y agrupar los datos de acceso más frecuente. Para facilitar la tarea, utilice grupos de archivos y sistemas RAID (matriz redundante de discos independientes). * Transacciones cortas para reducir los bloqueos de larga duración y mejorar la simultaneidad
Evite la interacción con los usuarios en las transacciones. Siempre que sea posible, ejecute un solo procedimiento almacenado para procesar toda la transacción. El orden en el que haga referencia a las tablas en las transacciones puede afectar a la simultaneidad. Coloque referencias a las tablas de acceso más frecuente al final de la transacción para reducir al mínimo la duración de los bloqueos. * Copia de seguridad en línea
Los sistemas OLTP se suelen caracterizar por la ejecución continua de operaciones en las que el tiempo de inactividad es mínimo. Es decir, funcionan 24 horas al día los 7 días de la semana. Aunque SQL Server Database Engine (Motor de base de datos de SQL Server) puede realizar una copia de seguridad de una base de datos mientras se utiliza, es recomendable planear el proceso de copia de seguridad de manera que se realice en los momentos de menor actividad para que no se vean afectadas las operaciones de los usuarios. * Alto grado de normalización de la base de datos
Reduzca la información redundante con el fin de acelerar las actualizaciones y, por tanto, mejorar la simultaneidad. La reducción de los datos también agiliza la realización de copias de seguridad, ya que es menor la cantidad de datos que es necesario copiar.

* Pocos (o ningún) dato histórico o agregado
Los datos a los que raramente se hace referencia pueden archivarse en bases de datos independientes o bien desplazarse desde las tablas que se actualizan a menudo a las que sólo contienen datos históricos. De este modo, el tamaño de las tablas se mantiene reducido, con lo que mejoran los tiempos de copia de seguridad y el rendimiento de las consultas. * Dosificar los índices
Deben actualizarse cada vez que se agrega o se modifica una fila. Para evitar una indización excesiva de tablas con un gran número de actualizaciones, limite el alcance de los índices. Utilice el Asistente para la optimización de motor de base de datos para diseñar sus índices. * Configuración de hardware óptima para controlar el gran número de usuarios con acceso simultáneo y ofrecer la rapidez en los tiempos de respuesta que necesita un sistema OLTP
Ayuda a la toma de decisiones

Las aplicaciones de base de datos de ayuda a la toma de decisiones son óptimas para las consultas de datos que no impliquen cambios en los mismos. Por ejemplo, una compañía puede resumir periódicamente sus ventas por fecha, región comercial o producto, y almacenar esa información en otra base de datos que será utilizada por los directivos para realizar un análisis. Para tomar decisiones comerciales, los usuarios necesitan determinar rápidamente la evolución de las ventas mediante consultas de los datos a partir de diversos criterios. Sin embargo, no necesitan cambiar esos datos. Las tablas de una base de datos de ayuda a la toma de decisiones se indizan a menudo, y los datos sin formato suelen ser previamente procesados y organizados para los distintos tipos de consultas que se realizan. Dado que los usuarios no cambian los datos, la simultaneidad y la atomicidad no suponen motivos de preocupación; los datos sólo se cambian mediante actualizaciones masivas que se realizan periódicamente en horas de escasa actividad de la base de datos y fuera del horario laboral.

Consideraciones acerca del diseño de toma de decisiones

Las bases de datos de sistemas de ayuda a la toma de decisiones (DSS, Decision Support System) deben diseñarse para promover lo siguiente: * Una intensa indización
Los sistemas de ayuda a la toma de decisiones exigen pocos requisitos para la actualización, pero suelen contener un gran volumen de datos. Utilice un gran número de índices para mejorar el rendimiento de las consultas. * La eliminación de la normalización de la base de datos
Introduzca datos resumidos o previamente agregados para satisfacer los requisitos de consulta más comunes y mejorar los tiempos de respuesta de las consultas. * Utilice un esquema de estrella o un esquema radial ramificado para organizar los datos dentro de la base datos.

El diseño lógico de la base de datos, que incluye las tablas y sus relaciones, es la clave de una base de datos relacional optimizada. Un buen diseño lógico de la base de datos puede ser la base de un rendimiento óptimo de la aplicación y de la base de datos. Un diseño lógico deficiente puede comprometer el rendimiento de todo el sistema.
La normalización de un diseño lógico de la base de datos implica la utilización de métodos formales para separar los datos en varias tablas relacionadas. Una característica de una base de datos normalizada es la existencia de varias tablas pequeñas con menos columnas. En las bases de datos no normalizadas, existen menos tablas más amplias con más columnas.
Por lo general, una normalización razonable permite mejorar el rendimiento. Cuando se dispone de índices útiles, el optimizador de consultas de SQL Server es una herramienta adecuada para la selección rápida y eficaz de combinaciones entre tablas.
La normalización ofrece diversas ventajas, entre las que se incluyen: * Mayor rapidez en la ordenación y en la creación de índices. * Un número mayor de índices clúster. Para obtener más información, vea Directrices para diseñar ndices clúster. * Índices más estrechos y compactos. * Menor número de índices por tabla. De esta forma, se mejora el rendimiento de las instrucciones INSERT, UPDATE y DELETE. * Menor número de valores NULL y menos oportunidades para generar incoherencias. De esta forma, aumenta el rendimiento.
A medida que progresa la normalización, también aumenta el número y la complejidad de las combinaciones necesarias para recuperar los datos. Un número muy elevado de combinaciones relacionales complejas entre demasiadas tablas puede afectar al rendimiento. Una normalización razonable suele incluir un número reducido de consultas que se ejecutan con regularidad y utilizan combinaciones en las que intervienen más de cuatro tablas.
A veces, el diseño lógico de la base de datos es fijo y su remodelación resulta inviable. No obstante, incluso en estos casos puede normalizarse de forma selectiva una tabla de gran tamaño para crear tablas más pequeñas. Si el acceso a la base de datos se realiza mediante procedimientos almacenados, este cambio del esquema puede llevarse a cabo sin que afecte a las aplicaciones. De lo contrario, puede crearse una vista que oculte el cambio de esquema a las aplicaciones.
Conseguir una base de datos bien diseñada

En la teoría del diseño de bases de datos relacionales, las reglas de normalización identifican ciertos atributos que deben estar presentes o ausentes en una base de datos bien diseñada. Una discusión completa de las reglas de normalización queda fuera del ámbito de este tema. No obstante, hay algunas reglas que pueden ayudarle a mejorar el diseño de la base de datos: * Una tabla debe tener un identificador.
La regla fundamental de la teoría del diseño de bases de datos es que cada tabla tenga un identificador único de fila, una columna o conjunto de columnas utilizados para diferenciar un registro de cualquier otro registro de la tabla. Cada tabla debe tener una columna de Id. y el valor de cada Id. no debe ser compartido por dos registros. Las columnas que funcionan como identificador único de fila para una tabla constituyen la clave principal de la tabla. En la base de datos AdventureWorks2008R2, cada tabla contiene una columna de identidad como columna de clave principal. Por ejemplo, VendorID es la clave principal de la tabla Purchasing.Vendor. * Una tabla solo debe almacenar datos para un único tipo de entidad.
Si intenta almacenar demasiada información en una tabla, la confiabilidad y la eficacia en la administración de los datos de la tabla pueden verse afectadas. En la base de datos de ejemplo AdventureWorks2008R2, la información de pedidos de ventas y de cliente está almacenada en tablas independientes. Puede disponer de columnas con información para los pedidos de ventas y el cliente en una sola tabla; sin embargo, este diseño causa varios problemas. El nombre, la dirección y la información del cliente deben agregarse y almacenarse repetidamente para cada pedido de ventas. De esta forma, la base de datos utiliza más espacio. Si cambia la dirección de un cliente, la modificación debe efectuarse en cada pedido de ventas. Además, si el último pedido de ventas de un cliente se quita de la tabla Sales.SalesOrderHeader, se pierde la información de dicho cliente. * En una tabla deben evitarse las columnas que acepten valores nulos.
Las tablas pueden tener columnas definidas para permitir valores NULL. Un valor NULL indica que no hay ningún valor. En algunos casos, puede resultar útil permitir valores NULL, pero conviene utilizarlos con moderación. Esto se debe a que precisan un control especial que aumenta la complejidad de las operaciones de datos. Si tiene una tabla con varias columnas que aceptan valores NULL y varias filas tienen valores NULL en las columnas, conviene que considere la posibilidad de colocar esas columnas en otra tabla vinculada con la tabla principal. Si almacena los datos en dos tablas distintas, el diseño de la tabla principal puede ser simple, pero seguirá controlando la necesidad ocasional de almacenar este tipo de información. * Una tabla no debe tener valores ni columnas que se repitan.
La tabla para un elemento de la base de datos no debe contener una lista de valores para una información específica. Por ejemplo, un producto de la base de datos AdventureWorks2008R2 se puede adquirir en varios proveedores. Si existe una columna en la tabla Production.Product para el nombre del proveedor, surge un problema. Una solución consiste en almacenar el nombre de todos los proveedores en la columna. Sin embargo, de esta forma resulta difícil mostrar una lista de los proveedores individuales. Otra solución consiste en cambiar la estructura de la tabla para agregar otra columna con el nombre del segundo proveedor. De esta forma, sin embargo, solo se pueden incluir dos proveedores. Si un producto cuenta con tres proveedores, es necesario agregar otra columna.
Si cree que necesita almacenar una lista de valores en una sola columna, o si tiene varias columnas para representar un solo tipo de datos, como TelephoneNumber1 y TelephoneNumber2, conviene que considere la colocación de los datos duplicados en otra tabla con un vínculo a la tabla principal. La base de datos AdventureWorks2008R2 cuenta con una tabla Production.Product para la información del producto, una tabla Purchasing.Vendor para la información de proveedor y una tercera tabla, Purchasing.ProductVendor. Esta tabla solo almacena los valores de Id. de los productos y de los proveedores de los productos. Este diseño permite la inclusión de un número indeterminado de proveedores para el mismo producto sin necesidad de modificar la definición de las tablas y sin asignar espacio de almacenamiento no utilizado para los productos con un único proveedor

La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos. Por ejemplo, si se especifica para un empleado el valor de identificador de 123, la base de datos no debe permitir que ningún otro empleado tenga el mismo valor de identificador. Si tiene una columna employee_rating para la que se prevean valores entre 1 y 5, la base de datos no debe aceptar valores fuera de ese intervalo. Si en la tabla hay una columna dept_id en la que se almacena el número de departamento del empleado, la base de datos sólo debe permitir valores que correspondan a los números de departamento de la empresa.
Dos pasos importantes en el diseño de las tablas son la identificación de valores válidos para una columna y la determinación de cómo forzar la integridad de los datos en la columna. La integridad de datos pertenece a una de las siguientes categorías: * Integridad de entidad * Integridad de dominio * Integridad referencial * Integridad definida por el usuario

Integridad de entidad

La integridad de entidad define una fila como entidad única para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.
Integridad de dominio

La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.
Integridad referencial

La integridad referencial protege las relaciones definidas entre las tablas cuando se crean o se eliminan filas. En SQL Server la integridad referencial se basa en las relaciones entre claves externas y claves principales o entre claves externas y claves exclusivas, mediante restricciones FOREIGN KEY y CHECK. La integridad referencial garantiza que los valores de clave sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos.

Cuando se exige la integridad referencial, SQL Server impide a los usuarios: * Agregar o cambiar filas en una tabla relacionada si no hay ninguna fila asociada en la tabla principal. * Cambiar valores en una tabla principal que crea filas huérfanas en una tabla relacionada. * Eliminar filas de una tabla principal cuando hay filas relacionadas coincidentes.
Por ejemplo, en las tablas Sales.SalesOrderDetail y Production.Product de la base de datos AdventureWorks2008R2, la integridad referencial se basa en la relación entre la clave externa (ProductID) de la tabla Sales.SalesOrderDetail y la clave principal (ProductID) de la tabla Production.Product. Esta relación garantiza que un pedido de ventas no pueda nunca hacer referencia a un producto que no existe en la tabla Production.Product.

Integridad definida por el usuario

La integridad definida por el usuario permite definir reglas de empresa específicas que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad admiten la integridad definida por el usuario. Esto incluye todas las restricciones de nivel de columna y nivel de tabla en CREATE TABLE, procedimientos almacenados y desencadenadores.

Estimar el tamaño de una base de datos * SQL Server 2008 * SQL Server 2005
Cuando diseña una base de datos, puede que necesite realizar una estimación del tamaño que tendrá la base de datos cuando esté llena. Esta estimación puede ayudarle a determinar la configuración de hardware que necesitará para realizar lo siguiente: * Conseguir el rendimiento que necesitan las aplicaciones. Para obtener más información, vea Consideraciones acerca del hardware en Rendimiento de la base de datos. * Asegurar la cantidad física adecuada de espacio en disco necesario para almacenar los datos y los índices.

Asimismo, la estimación del tamaño de la base de datos puede ayudarle a determinar si el diseño de su base de datos necesita reajustes. Por ejemplo, puede determinar que el tamaño estimado de la base de datos es demasiado grande para una implementación en su organización, y que se necesita un mayor grado de normalización. Por el contrario, el tamaño estimado puede inferior al esperado, con lo que podrá reducir la normalización de la base de datos para mejorar el rendimiento de las consultas.
Para realizar una estimación del tamaño de una base de datos, efectúe una estimación del tamaño de cada tabla por separado y sume los valores obtenidos. El tamaño de una tabla depende de si tiene índices y, si los tiene, del tipo de índices.

En esta sección

Tema | Descripción | Calcular el tamaño de una tabla | Define los pasos y cálculos necesarios para realizar una estimación del espacio que se necesita para almacenar los datos en una tabla y en los índices asociados. | Estimar el tamaño de un montón | Define los pasos y cálculos necesarios para realizar una estimación del espacio que se necesita para almacenar los datos en un montón. Un montón es una tabla que no contiene un índice agrupado. | Estimar el tamaño de un índice clúster | Define los pasos y cálculos necesarios para realizar una estimación del espacio que se necesita para almacenar los datos en un índice agrupado. | Estimar el tamaño de un índice no clúster | Define los pasos y cálculos necesarios para realizar una estimación del espacio que se necesita para almacenar los datos en un índice no agrupado. |

Estimar el tamaño de un montón

Los siguientes pasos pueden utilizarse para calcular el espacio necesario para almacenar datos en un montón: 1. Especifique el número de filas que habrá en la tabla:
Num_Rows = número de filas de la tabla 2. Especifique el número de columnas de longitud fija y de longitud variable, y calcule el espacio necesario para su almacenamiento:
Calcule el espacio que ocupa cada uno de estos grupos de columnas en la fila de datos. El tamaño de una columna depende del tipo y la longitud especificados para los datos. Para obtener más información, vea Tipos de datos (motor de base de datos).
Num_Cols = número total de columnas (de longitud fija y variable)
Fixed_Data_Size = tamaño total en bytes de todas las columnas de longitud fija
Num_Variable_Cols = número de columnas de longitud variable
Max_Var_Size = tamaño máximo total en bytes de todas las columnas de longitud variable 3. Una parte de la fila, conocida como el mapa de bits NULL, se reserva para administrar la nulabilidad en las columnas. Calcule el tamaño:
Null_Bitmap = 2 + ((Num_Cols + 7) / 8)
Sólo debe utilizarse la parte entera de la expresión anterior. Descarte el resto. 4. Calcule el tamaño de los datos de longitud variable:
Si hay columnas de longitud variable en la tabla, determine cuánto espacio se utiliza para almacenar las columnas en la fila:
Variable_Data_Size = 2 + (Num_Variable_Cols x 2) + Max_Var_Size
Los bytes agregados a Max_Var_Size son para el seguimiento de cada columna de longitud variable. En esta fórmula se supone que todas las columnas de longitud variable están llenas al 100%. Si prevé que va a utilizarse un porcentaje inferior del espacio de almacenamiento de columnas de longitud variable, puede ajustar el valor de Max_Var_Size en función de ese porcentaje para obtener una estimación más precisa del tamaño global de la tabla. Nota | Puede combinar las columnas varchar, nvarchar, varbinary o sql_variant de forma que el ancho de tabla total definido supere los 8.060 bytes. La longitud de cada una de estas columnas debe ajustarse al límite de 8000 bytes en columnas varchar, nvarchar, varbinary o sql_variant. Sin embargo, el ancho combinado puede superar el límite de 8060 bytes de una tabla. Para obtener más información, vea Datos de desbordamiento de fila superiores a 8 KB. |
Si no hay columnas de longitud variable, seleccione el valor 0 para Variable_Data_Size. 5. Calcule el tamaño total de la fila:
Row_Size = Fixed_Data_Size + Variable_Data_Size + Null_Bitmap + 4
El valor 4 de la fórmula representa la sobrecarga del encabezado de la fila de datos. 6. Calcule el número de filas por página (8096 bytes libres por página):
Rows_Per_Page = 8096 / (Row_Size + 2)
Dado que las filas no abarcan varias páginas, el número de filas por página debe redondearse hacia abajo a la fila completa más cercana. El valor 2 de la fórmula representa la entrada de la fila en la matriz de zonas de la página. 7. Calcule el número de páginas necesarias para almacenar todas las filas:
Num_Pages = Num_Rows / Rows_Per_Page
El número de páginas estimado debe redondearse hacia arriba a la página completa más cercana. 8. Calcule el espacio necesario para almacenar los datos en el montón (8192 bytes en total por página):
Tamaño del montón (bytes) = 8192 x Num_Pages
En este cálculo no se tiene en cuenta lo siguiente: * Crear particiones
La sobrecarga de espacio de la creación de particiones es mínima, pero resulta difícil de calcular. No es importante incluirla. * Páginas de asignación
Se utiliza al menos una página IAM para realizar un seguimiento de las páginas asignadas a un montón, pero la sobrecarga de espacio es mínima y no existe ningún algoritmo para calcular de forma determinista el número exacto de páginas IAM que se utilizarán. * Valores de objetos grandes (LOB)
El algoritmo que permite determinar exactamente la cantidad de espacio que se utilizará para almacenar los tipos de datos LOB y los valores varchar(max), varbinary(max), nvarchar(max), text, ntext xml y image es complejo. Basta con agregar solamente el tamaño medio de los valores de LOB que se esperan y agregarlo al tamaño total del montón. * Compresión
No se puede calcular previamente el tamaño de un montón comprimido. * Columnas dispersas
Para obtener información sobre los requisitos de espacio de las columnas dispersas, vea Usar columnas dispersas