Este documento proporciona una lista de elementos a considerar para el diseño, implementación y escalamiento de una base de datos. Incluye recomendaciones sobre el esquema de la base de datos, las consultas, y factores que influyen en el rendimiento y escalabilidad como normalización, tipos de datos, índices, y separación de transacciones analíticas y transaccionales.

1. CHECK L1STSOBRE MODELO DE DATOS
FUNCIONAL, DISEÑO E IMPLEMENTACiÓN
A continuación, se lista una serie de elementos a considerar durante el diseño de una
base de daros, agrupados en función del objetivo perseguido. Es importante recordar
que se trata de recomendaciones que, bajo determinadas Cjrcu.nsrancias,no es posi-
ble verificar (por ejemplo, cuando debemos trabajar sobre un diseño existente) y
donde no podemos rediseñar la base sin hacer una reingenietía de la aplicación.
No obstante, sí podemos revisar el diseño existente buscando mejorar las consultas,
los índices, los tipos de daros, etcétera.
Escalamiento
Es la característica de una base de daros que consiste en crecer y ofrecer más servi-
cios. Si el diseño es oscuro, complejo o difícil de mantener, las posibilidades de es-
calar una aplicación decrecen. La siguiente tabla muestra las principales considera-
ciones que se deben tener en cuenta a la hora de escalar una aplicación.
CHECK DETAllE
v Optimizar la aplicación antes de escalarla.
v Revisar la necesidad de crear tablas históricas de datos para reportes.
Tabla 3. Elementos a tener en cuenta que influyen
en las posibilidades de escalamiento de una aplicación.
Seguramente, la optimización de una aplicación requerirá de la asistencia del ad-
rninisrrador de la base de datos y de la red. Esto se fundamenta en que, para op-
timizar la base de datos, primero debemos tener una idea de cuáles son los ele-
memos que producen dichos problemas. Entre esos elementos podemos enume-
rar: procedimientos almacenados con sentencias mal formadas, que produzcan
scans de tablas completas; estadísticas desactualizadas; índices pobres, de poca co-
bertura, basados en campos poco selectivos o sobre campos de texto; tablas con

2. clave primaria basada en campos compuesros; bloqueos morrales por alra concu-
rrencia, bloqueo mal adminisrrado, ercérera.
Es recomendable también que, a la hora de pensar en escalar una aplicación, revi-
semos el uso de rabias de regisrros hisróricos que puedan moverse a otra base de da-
ros (dedicada, por ejemplo, a reporres y regimos hisróricos).
Esquema de la base de datos
El esquema de la base de daros refiere al diseño de tablas, campos, vistas, particio-
nes, etc., que en su conjunto definen una base de daros. SQL Server permite con-
sultar el esquema de una base de daros por medio de las vistas de INFORMATION_
SCHEMA, según veremos en el capítulo dedicado a vistas.
Si el esquema está bien definido (es decir, de acuerdo con las recomendaciones de
la tabla que se encuentra a continuación) la base de daros será escalable y rendrá un
óptimo desempeño.
.
CHECK DETALLE
v Asignar los recursos apropiados (almacenamiento) al diseño.
v Separar transacciones analíticas (BI) de transaccionales.
v Normalizar primero. Denormalizar para mejorar desempeño.
v Definir claramente claves primarías, foráneas y relaciones.
v Definir todas las constraints UNIQUE y CHECK.
v Seleccionar los tipos de datos más apropiados.
v Usar vistas indexadas de normalización.
v Partlcinnar tablas vertical y horizontalmente.
Tabla 4. Elementos que definen un buen esquema de base de datos.
Asignar los recursos apropiados al diseño implica estudiar cómo hemos de distribuir los
recursos físicosde la base de daros entre los medios de almacenamienro. En ciertas dis-
posiciones de hardware, como implemenraciones RAID (RedundalltArray of Indepen-
dent orlnexpensive Disk) de discos, sería posible distribuir los archivos de daros y el lag
de transacciones, separar los datos de las tablas y sus Índices. Incluso, se podrían parti-
cionar tablas vertical y horizonra1menre en discos separados, con el fin de obtener me-
joras generales de rendimiento, almacenamiento y desempeño de las consulras. Nos
adentraremos más en este rema en el capítulo que hemos dedicado a las rabIas.
Al separar las transacciones analíticas de las transaccionales, resolveremos también las
cuestiones mencionadas, pero, desde el PWlto de vista funcional, ya que las transaccio-
nes analíticas consumen muchos recursos de agrupanlienro y swnarización que po-

3. drían ser optimizadas si, por ejemplo, almacenamos esas tablas en otro disco del RAID.
En el capítulo dedicado a la creación de bases de datos veremos todo esto en detalle.
Por otra parte, cuando hablamos de normalizar primero y denormalizar para mejo-
rar desempeño nos referimos a los concepros ya tratados en el Capítulo 2, cuando
hablamos de las formas normales. Allí dijimos que, en algunos casos, para mejorar
el desempeño de algunas consultas, es posible incluir en el diseño campos calcula-
dos que, si bien vulneran el concepto de normalización, permiten ganar desempe-
ño y velocidad de procesamiento. No es lo mismo ejecutar una consulta que sume
los importes de rodos los írems de cada factura que crear un campo derivado Total_
Factura, en la tabla Facturas, que guarde la sumarización de aquéllos.
A la vez, al definir claramente claves primarias, foráneas y relaciones utilizando las es-
tructuras que nos provee SQL Server, evitamos la implementación por código de la
verificación de la integridad referencial al tiempo que creamos índices consistentes so-
bre los cuáles se ha de realizar la mayor parte de las consultas que utilicen esa tabla.
Aquí será de suma utilidad definir rodas las constrainrs UNIQUE y CHECK para la ve-
rificación de integridad de dominio, utilizando, en ambos casos, herramientas y ob-
jetos nativos y oprimizados de SQL Server.
SQL Server aventaja otros productos por su facilidad de insralación y uso, que se
evidencia en la rendencia a considerar la habilidad de creación y desarrollo sobre ba-
ses de datos como una competencia adicional de los programadores. Esra concep-
ción alienta la formación de profesionales mucho mejor formados pero, en ocasio-
nes, cuando los equipos de trabajo no comparten esrándares de programación, las
aplicaciones tienden a perder cohesión debido a que cada integrante del equipo
aplica lo que sabe de la mejor forma posible. El resultado suele derivar en aplicacio-
nes de baja capacidad para compartir datos, especialización y dependencia respecto
del profesional que desarrolló tal aplicación y pobre desempeño.
Uno de los problemas más usuales que se presenta es el desperdicio de recursos por
deficiente tipificación de los daros. En este sentido, seleccionar los tipos de daros
~ DISEÑO CONCEPTUAL
.~.
~
El diseño conceptual parte de las especificaciones
. . ~
de requisitos dé usuario. y su resullado es el
es.qu~ma conceptual de la base'de','datos; iodep;ndiente deLSGBD,utilizado. Un modelo conc€p-
tual e~ lenguaje
un que se utiliza p-~ra describir esquemas concepfual~,s{su objetivo es desc~jbir
.
el contenidO de jnformación"de la"bas~de datos, y no, sus estfJcturas"de a[mác~namiento,
.

4. más apropiados para cada campo y/o variable definida en la base de daros redunda-
rá en un mejor desempeño de la aplicación en genera!.
Lamenrablemente, para elegir los tipos de daros más apropiados es necesario disponer
de un modelo de daros previamente definido, a parrir del análisis funcional del sisrema
que se ha de desarrollar (tarea para la que suele falrar tiempo, entre otras cosas, porque
no se le asigna en la planificación del proyecto el valor preponderante que tiene).
Consultas
Una vez diseñado el modelo de daros, son las consultas, generalmenre bajo la for-
ma de procedimientos almacenados, las que definirán el desempeño de la aplica-
ción, tanto en términos de tiempos de respuesta frente a! usuario como en desem-
peño genera! y buena utilización de los recursos del servidor.
Es muy importante escribir el código bien formado y revisar la lista de elementos
de la tabla siguienre para obtener consultas de buen desempeño.
0., . "
CJlf,CK DErALlE" W !,j" ' V
•••• Definir de antemano la escalabilidad y los requerimientos de desempeño de las consultas .
•••• Escribir consultas bien formadas .
•••• Devolver s610 las filas y columnas requeridas .
•••• Evitar operadores costosos en términos de rendimiento como HOT lIKE .
•••• Evitar funciones implícitas o explícitas en cláusulas WHERE .
•••• Utilizar H1NT5 de bloqueo y nivel de aislamiento para minimizar los bloqueos .
•••• Usar procedimientos almacenados o consultas parametrizadas .
•••• Minimizar el uso de cursores.
•••• Evitar actualizaciones complejas en triggers.
•••• Usar apropiadamente tablas temporarias y variables de tipo tabla .
•••• Limitar el uso de HINTS en consultas e índices .
•••• calificar apropiadamente los objetos.
Tabla 5. Consideraciones sobre consultas.
Establecer de antemano la escalabilidad y los requerimientos de desempeño de las
consultas, así como la cantidad de usuarios (para entender las necesidades de con-
currencia), la posibilidad de realizar consultas distribuidas, la necesidad de reali-
zar cálculos intermedios o la necesidad de agregar datos definirá la estrategia de
desarrollo de una consulta.
Esa estrategia deberá contemplar la escritura de código claro y bien formado, que
respete la estructura del lenguaje, y evitando, siempre que sea posible, el uso de sen-
tencias de pobre desempeño. En este sentido, deberá evitarse la devolución de co-
lumnas no requeridas que saturan las redes con información redundante y atestan
sin necesidades las estructuras de daros de las aplicaciones.

5. Por otra parte, los cursores deberán reservarse para procesamientos Fila A Fila,
donde se estime más conveniente que los procese el servidor, en lugar de la apli-
cación, y se tendrá especial cuidado en el uso de los HINTS en consultas e índi-
ces que quitan a SQL Server la responsabilidad de elegir el mejor camino de eje-
cución para una consulra.
A la vez, por eficiencia en el uso de recursos, se preferirán las variables de tipo tabla
por encima de las tablas temporarias y se calificarán adecuadamente los objetos ba-
jo la forma owner.Nombre_Objeto para reducir los tiempos de búsqueda.
índices
Este puntO es fundamental en todo buen diseño, de manera que lo veremos con más
detalle en el capítulo dedicado a tablas. Las recomendaciones del siguiente cuadro
nos permitirán asegurar el óptimo desempeño de la aplicación.
,
. ;.., . • %
CHECK DETAllE P '«4<·
11 Crear los índices basándose en el uso.
11 Mantener las claves de los índices clustered 0 más pequeñas posibles.
11 Evaluar el rango de datos cubierto por el índice.
11 Crear índices en todos los FORElNG KEY.
11 Crear índices altamente selectivos.
11 Crear índices de cobertura para las consultas más usadas o de alto impacto.
11 Preferir índices estrechos a índices grandes de basta cobertura.
11 Crear indices compuestos sobre los campos más restrictivos.
11 Considerar la creación de índices sobre campos usados en cláusulas WHERE. ORDER BY. GROUP BY y DI5TINCT.
11 Remover índices no utilizados.
11 Utilizar el optimizador de índices.
Tabla 6. Consideraciones sobre índices.
Crear los índices basándose en el uso implica poseer un conocimiento bastante cer-
tero sobre el objetivo de persistencia de datos que busca nuestra aplicación. Creare-
----.DI DISEÑO LÓGICO
El diseño lóqico parte del esquema conceptual y da como resultado un esquema lógico. que es
una descripción de la estructura de la base de datos en términos de las estructuras de datos-que
puede procesar un tipo de SGBD. Un modelo lógico es un len~uaie usado para especificar esque-
mas lógicos. que depende del tipo de SGBD que se vaya a utitizar. no. del producto concreto.

6. mos índices, -preferentemente sobre los campos definidos como candidatos-, en
función de las consultas que desarrollaremos (o de las ya existentes que requieren
mejoras). Los índices clustered (físicos), almacenados en páginas de índices, debe-
rán estar basados en c<~mpos cuyo tipo de daros sea lo más pequeño posible.
A mismo tiempo, es necesario verificar el rango de cobertura y de selectividad de un
índice (un índice sobre un campo EstadoCivilserá de gran cobertura, petO de baja
selectividad). Esta recomendación también es válida para los índices compuestos
(basados en varios campos).
Para decidir los campos candidatos a ser indexados, conviene analizar las cláusulas
WHERE, RDER
O BY,GROUP BYY DI8TINCT las consultas y luego analizar los tipos
de
de daros involucrados.
Transacciones
El ambiente transaccional que demos a nuestras consultas garantizará que la ejecu-
ción de las sentencias de IN8ERT,UPDATE DELETE ellas ejecutadas se hagan ro-
y en
das o ninguna.
El desempeño de nuestras transacciones puede ser mejorado si se observan las si-
guientes recomendaciones.
CHECK DETAllE
ti' Evitar transacciones de larga duración.
ti' Evitar transacciones Que requieran intervención del usuario para realizar COMMIT.
ti' Utilizar los dalos más pesados al final de la transacción.
ti' Intentar acceder a los recursos siempre en el mismo orden.
ti' Utilizar cuidadosamente los HINTS de nivel de aislamiento para reducir bloqueos.
ti' Asegurar la existencia de sentencias COMMIT y ROlLBACK.
ti' Determinar los patrones de datos más utilizados en transacciones y organizar las tablas e índices sobre
arreglos de discos RAID.
ti' Buscar la mayor normalización posible de la base de datos para evitar redundancia.
ti' Mantener los registros históricos o de agregación en bases de datos separadas.
Tabla 7. Consideraciones sobre transacciones.
--.m DISEÑO FíSICO
El diseño físico parte del esquema lógico y resulta en un esquema físico (descripción de la imple-
mentación de una base de datos en memoria secundaria}: las estructuras de almacenamiento y los
métodos utilizados para tener un acceso eficiente a los datos ..Par eso, el diseño fislco depende del
SGBO concreto, y el esquema físico se expresa mediante su lenguaje de definición de datos.
~ $,

7. De estas recomendaciones, consideramos como más importante aquella que sugiere
evitar transacciones que requieran intervención del usuario para realizar COMMIT.
El conocido ejemplo del usuario que deja pendienre una acrualización de saldos por-
que salió a almorzar ya resulta una trivialidad para el profesional de sistemas. Pero aun
así, y dado que la práctica persisre, insistimos en este punto para resaltar que no sólo
se trata de una transacción en estado desconocido que espera una acción, sino que
involucra la adquisición de bloqueos sobre los recursos involucrados en ella, que de-
mora o directamente impide el acceso del resto de los usuarios al recurso bloqueado.
No menos importante es resaltar el cuidado que deberá tenerse al utilizar los HINTS
de nivel de aislamienro para reducir bloqueos. Aquí, para ejecutar la nuestra, Corre-
mos el riesgo de utilizar datos que están siendo modificados por otras transacciones.
Procedimientos almacenados
Respecto de los procedimientos almacenados, es importante la recomendación de
la Tabla 8, debido a que, si la variable NOCOUNT está en OFF, corremos peligro de no
poder evaluar los resultados intermedios (cantidad de filas afectadas).
CHECK "DETAllE 0.R ,', W~"W.:c"; e;;' "'2%¡.,Ji
V Utilizar set NOCOUNT ON en procedimientos almacenados.
V Verificar la necesidad de recompilación.
Tabla 8. Consideraciones sobre procedimientos almacenados.
Las recomendaciones sobre el código de los procedimientos almacenados se corres-
ponden con el de las consultas.
Planes de ejecución
En algún momento del análisis del desempeño de una consulra, rendremos la ne-
cesidad de evaluar su plan de ejecución. Al respecto, mencionamos las principa-
les recomendaciones.
CHECK' DETAllE ~' ",!'I,"" . ¡'" 0;
V Evaluar los planes de ejecución.
V Evitar seans de tablas e índices.
V Evaluar el uso de joins HASH.
V Evaluar bookmarks.
V Evaluar ordenamientos y filtros.
V Evaluar filas y ejecuciones actuales versus estimadas.
Tabla 9. Consideraciones sobre los planes de ejecución.

8. Un sean de rabla o índice señala que SQL Server está revisando dicha tabla o página
de índices fila a fila o estructura a estructura en el árbol de índices. Se producen cuan-
do la consulta no está utilizando (por falta de definición, por ejemplo) los índices ade-
cuados. Al respecro, cuando nos adentremos en el capírulo referido a tablas, evaluare-
mos en detalle las situaciones en las que se puede mejorar el plan de ejecución.
Recompilación
En la medida que una base de daros cambia debido a la creación de índices o por la
modificación sobre los daros almacenados en columnas indexadas, también cambian
los planes de ejecución compilados para acceder a esos datos. Por ello es necesario re-
compilar dichos planes para optimizarlos. En SQL Server 2005, esta recompilación
es auromática siempre que se corre por primera vez un procedimiento almacenado
luego de reiniciar el servidor o si cambia una tabla utilizada por éste. Pero si se crea
un índice nuevo sobre una tabla a partir del cual la ejecución de un procedimiento
puede verse beneficiada, la recompilación no es auromática.
La. siguieme tabla muestra recomendaciones respecro de la recompilación.
-ce .
, litÉ jjJ
CHECK '·DETAllE . "
v Utilizar procedimientos almacenados o consultas parametrizables.
v Utilizar sp executesql para consultas dinámicas.
v Evitar sentencias de definición de datos (DDl) o de manipulación de datos (DMl), aun en la tempdb, para
manipular elementos ya definidos.
v Evitar el uso de cursores en tablas temporarias.
Tabla 1.0. Recomendaciones sobre recompilación.
La. recomendación de utilizar procedimientos almacenados o consultas parametriza-
bies se refiere a la necesidad de evitar el envío de consultas T-SQL desde la aplicación.
Veremos con mayor detalle este punro en el capítulo dedicado a procedimientos al-
macenados, pero, justamente, una de las ventajas de utilizar consultas parametrizadas
y procedimientos almacenados por encima de sentencias T-SQL variables es la posi-
bilidad de compilarlos, guardar el plan de ejecución en el servidor y reutilizarlo para
---.nI EL PLAN DE EJECUCiÓN

9. cada ejecución, evitando que el servidor deba verificar la referencia a objetos y buscar
el mejor plan de ejecución pOt cada consulta que se envía desde la aplicación.
SQLXML
SQL Server ptovee soporte extensivo pata el procesamiento de datos XML. Valores
en este forrnaro pueden ser almacenados en el nuevo tipo de datos XML, tipificado
bajo diferentes esquemas XML. Este cipo de datos soporta indexado y puede ser
manipulado por XQuery y XML DML.
Ya en su versión 2000, SQL Server proveía poderosas capacidades de manipulación
de XML con SQLXML, y permitía la transformación de datos relacionales en da-
tos XML. También era posible "mapear " los resultados relacionales a XML median-
te la sentencia FOR XML de T-SQL o generar vistas de XML mediante OPENXML.
A continuación, se incluyen las consideraciones que debieran tenerse en cuenta
respectO del uso de XML en SQL Server 2005 desde dos puntOS de vista: el mo-
delado de datos y su uso.
CHECK DETAllE • • ·"c. '/ .' '", . .
V
" (semiestrueturado
La estructura de datos es flex.ible o sin estructura).
V Se desconoce la estructura de datos o ésta puede variar mucho en el futuro.
V Los datos poseen una estructura jerárqulca y recursiva.
V Importa el orden como ceractenstiea propia de los datos.
V Planea actualizar los datos basándose en su estructura.
V Planea utilizar las funciones administrativas del servidor para administrar la información XMl.
V Planea compartir, consultar y modificar los datos XMl en forma transaccional segura.
V Desea obtener Interoperabilidad entre aplicaciones relacionales y basadas en XML
V' Desea garantizar documentos bien formados mediante esquemas.
V Desea acceso a datos XML desde sus aplicaciones utilizando SOAP,AOO .NET y OLEOS.
Tabla 11. Evaluación de circunstancias para uso de tipos XM.
-.m EL REGISTRO DE TRANSACCIONES
Esta aplicación trabaja escribiendo en regjstro, anticipadamente. todos los cambios que se realicen
ante una operación de COMMIT o cuando se ejecuta un CHECKPOINTmediante el proceso lazywrit-
ter. Las políticas de backup suelen incluir el lag de transacciones, permitiendo recuperar la infor-
rnación ante una caída del sistema, sin ·'husmear" en el registro.

10. Tunning
En la siguiente rabia, se resumen las acciones recomendadas para evaluar el desem-
peño de una consulta.
CHEC~ DETAllE'" ., .
'+ . 'W '?ii;¡o¡ .
•••• Utilizar el Profiler para identificar consultas de larga duración .
•••• Registrar las consultas pequeñas realizadas varias veces .
•••• Utilizar sp-who2 Y sp lock para analizar bloqueos .
•••• Evaluar waittype y walttime en master..sysprocesses .
•••• Utilizar DBCe OPENTRAN para localizar transacciones de larga duración.
Tabla 12. Recomendaciones para el refinamiento del diseño.
Testing
La fase de Análisis y Desarrollo es tan importante como la fase de Testing. En la si-
guiente tabla se muestra un resumen de las acciones recomendadas para testear el
aspecto técnico de una base de daros.
CHECK DETALLE , '<' ,t:,,' ., .. .: J%, :,¡;,¡
•••• Revisar que no se llene el Transaction lag .
•••• Presupuestar el tamaño de la base de datos .
•••• Utilizar herramientas para popular datos .
•••• Utilizar datos de producción .
•••• Utilizar escenarios de usuario común, con un apropiado balance entre lecturas y escrituras .
•••• Usar herramientas de test de stress sobre el sistema.
Tabla 13. Recomendaciones para el testlng de diseño y desempeño.
Si el Transacrion log (registro de transacciones) se llena, ya sea porque alcanzó el
tamaño prefijado como si no queda espacio disponible en el Server (suele suceder
en ambientes de desarrollo), no se dispondrá de resguardo transaccional sobre la
base de daros y fallará la aplicación. Es importante disponer de un plan de mante-
-uD FUNCIONES DEL DBA
Un'buen administrador de bases de datos [OBA) será de gran ayuda para.prptegerlos datos medían-'
te·backups, asegurarse de qljién y cómo accede a la base de'datos; administrar los recursos ñsicos
d~tpervid9r, ejecutar tareas>de~~anteJ¡'ir'niento y asigna2íón'de espacio e.ndisco en la base, mGni"to~
• '. " .,y . .
re%;el uso y desempeño del 'sistema y n~garse a a~igná'r~e:.pef~os sa a los desarrolladores.~·
,j~, 'k'.'·z 5k-- ~ .~

11. nirniento que se ocupe, entre otras cosas, de! backup (resguardo) de la base y que
esté configurado para truncar e! registro.
También es importante tratar de utilizar un conjunto real de datos con el fin de
verificar el diseño (excepto que se trate de una aplicación nueva). Esto nos brin-
dará la posibilidad de proyectar el uso real de ésta.
Monitoreo
Las tareas de monitoreo refieren a las acciones que normalmente efectúa el D BA pa-
ra verificar el desempeño de! servidor y de las bases de datos en él administradas. La
Tabla 13 muestra las recomendaciones de monitoreo para realizar un buen análisis.
ClIECK DEfAIll._ @ ~ . .'
"
01 Mantener las estaoísucas al día.
01 Utilizar el Profiler para afinar consultas de larga duración.
01 Utilizar el Profiler para consultar scans de tablas e índices.
01 Utilizar el Performance Monitor para analizar el uso de recursos del sistema.
01 Analizar las comunicaciones de red en consultas de larga duración.
01 Analizar recursos de memoria del server en consultas de larga duración.
01 Analizar la falta de estadísticas actualizadas en consultas de larga duración.
01 Analizar la falta de índices en consultas de larga duración.
Tabla 14. Recomendaciones para el monitoreo del servidor.
Deployment (distribución)
La Tabla 14 resume las recomendaciones para la distribución y/o pase a Producción
de la base de datos. Entre ellas, se destaca la de asignar DBA, que normalmente es
quien conoce el servidor de destino, asign los recursos necesarios y ocuparse de los
aspectos relacionados con el resguardo y la recuperación de la información.
CHECK DETALLE
01 Utilizar la configuración del seoer para las aplicaciones.
01 Ubicar ellog y la tempdb en distintos dispositivos del de datos.
01 Proveer dispositivos separados para [as tablas y los índices mas accesacos.
01 Usar la configuración RAID correcta.
01 Usar múltiples controladores de discos.
01 Dimensionar las bases de datos y sus logs de manera de evitar las opciones de autocrecimiento automático.
01 Maximizar la memoria disponible del servidor.
01 Administrar la fragmentación de índlces,
01 Asignar un DBA.
Tabla 15. Recomendaciones para la distribución de bases de datos.