CHECK L1STSOBRE MODELO DE DATOSFUNCIONAL, DISEÑO E IMPLEMENTACiÓN

A continuación, se lista una serie de elementos a considerar durante el diseño de unabase de daros, agrupados en función del objetivo perseguido. Es importante recordarque se trata de recomendaciones que, bajo determinadas Cjrcu.nsrancias,no es posi-ble verificar (por ejemplo, cuando debemos trabajar sobre un diseño existente) ydonde 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.

EscalamientoEs 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 DETAllEv 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 produzcanscans de tablas completas; estadísticas desactualizadas; índices pobres, de poca co-bertura, basados en campos poco selectivos o sobre campos de texto; tablas con

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 datosEl 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 dela 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 recursosapropiados al diseño implica estudiar cómo hemos de distribuir losrecursos 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 lagde transacciones, separar los datos de las tablas y sus Índices. Incluso, se podrían parti-cionar tablas vertical y horizonra1menreen discos separados, con el fin de obtener me-joras generales de rendimiento, almacenamiento y desempeño de las consulras. Nosadentraremos más en este rema en el capítulo que hemos dedicado a las rabIas.

Al separar las transacciones analíticas de las transaccionales, resolveremostambién lascuestiones mencionadas, pero, desde el PWltode vista funcional, ya que las transaccio-nes analíticas consumen muchos recursos de agrupanlienro y swnarización que po-

A la vez, al definir claramente clavesprimarias, foráneas y relaciones utilizando las es-tructuras que nos provee SQL Server, evitamos la implementación por código de laverificació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.

drían ser optimizadas si, por ejemplo, almacenamos esastablas 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, cuandohablamos de las formas normales. Allí dijimos que, en algunos casos, para mejorarel 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 sumelos 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.

SQL Server aventaja otros productos por su facilidad de insralación y uso, que seevidencia 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, lasaplicaciones tienden a perder cohesión debido a que cada integrante del equipoaplica 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 respectodel 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 pordeficiente 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~un lenguaje que se utiliza p-~radescribir esquemas concepfual~,s{su objetivo es desc~jbir

el contenidO de jnformación"de la"bas~de datos, y no, sus estf\Jcturas"de a[mác~namiento,. .

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 disponerde un modelo de daros previamente definido, a parrir del análisis funcional del sisremaque se ha de desarrollar (tarea para la que suele falrar tiempo, entre otras cosas, porqueno se le asigna en la planificación del proyecto el valor preponderante que tiene).

ConsultasUna 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 elementosde la tabla siguienre para obtener consultas de buen desempeño.

CJlf,CK DErALlE" W !,j" '0., . 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 lasconsultas, 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 dedesarrollo de una consulta.

Esa estrategia deberá contemplar la escritura de código claro y bien formado, querespete 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 atestansin necesidades las estructuras de daros de las aplicaciones.

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 tablapor 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.

índicesEste puntO es fundamental en todo buen diseño, de manera que lo veremos con másdetalle en el capítulo dedicado a tablas. Las recomendaciones del siguiente cuadronos 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. Unmodelo lógico es un len~uaie usado para especificar esque-mas lógicos. que depende del tipo de SGBD que se vayaa utitizar. no. del producto concreto.

mos índices, -preferentemente sobre los campos definidos como candidatos-, enfunción de las consultas que desarrollaremos (o de las ya existentes que requierenmejoras). Los índices clustered (físicos), almacenados en páginas de índices, debe-rán estar basados en c<~mposcuyo 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 bajaselectividad). 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áusulasWHERE,ORDERBY,GROUPBYY DI8TINCTde las consultas y luego analizar los tiposde daros involucrados.

TransaccionesEl ambiente transaccional que demos a nuestras consultas garantizará que la ejecu-ción de las sentencias de IN8ERT,UPDATEy DELETEen ellas ejecutadas se hagan ro-das o ninguna.El desempeño de nuestras transacciones puede ser mejorado si se observan las si-guientes recomendaciones.

CHECK DETAllEti' 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.~ $,

De estas recomendaciones, consideramos como más importante aquella que sugiereevitar 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 aunasí, y dado que la práctica persisre, insistimos en este punto para resaltar que no sólose trata de una transacción en estado desconocido que espera una acción, sino queinvolucra 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 HINTSde 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 almacenadosRespecto de los procedimientos almacenados, es importante la recomendación dela Tabla 8, debido a que, si la variable NOCOUNT está en OFF, corremos peligro de nopoder 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ónEn 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.

Un sean de rabla o índice señala que SQL Server está revisando dicha tabla o páginade í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ónEn la medida que una base de daros cambia debido a la creación de índices o por lamodificación sobre los daros almacenados en columnas indexadas, también cambianlos 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ónes auromática siempre que se corre por primera vez un procedimiento almacenadoluego de reiniciar el servidor o si cambia una tabla utilizada por éste. Pero si se creaun índice nuevo sobre una tabla a partir del cual la ejecución de un procedimientopuede verse beneficiada, la recompilación no es auromática.La. siguieme tabla muestra recomendaciones respecro de la recompilación.

CHECK '·DETAllE , litÉ jjJ-ce .

".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 parametrizadasy 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

cada ejecución, evitando que el servidor deba verificar la referencia a objetos y buscarel mejor plan de ejecución pOt cada consulta que se envía desde la aplicación.

SQLXMLSQL Server ptovee soporte extensivo pata el procesamiento de datos XML. Valoresen este forrnaro pueden ser almacenados en el nuevo tipo de datos XML, tipificadobajo diferentes esquemas XML. Este cipo de datos soporta indexado y puede sermanipulado por XQuery y XML DML.

Ya en su versión 2000, SQL Server proveía poderosas capacidades de manipulaciónde 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 cuentarespectO 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 La estructura de datos es flex.ible (semiestrueturado 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 XMLV' 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

Estaaplicación trabaja escribiendo en regjstro, anticipadamente. todos los cambios que se realicenante 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.

TunningEn 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.

TestingLa 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 elaspecto 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ó eltamaño prefijado como si no queda espacio disponible en el Server (suele sucederen ambientes de desarrollo), no se dispondrá de resguardo transaccional sobre labase 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 ñsicosd~tpervid9r, ejecutar tareas>de~~anteJ¡'ir'niento y asigna2íón'de espacio e.ndisco en la base, mGni"to~

• '. " .,y . .re%;el uso ydesempeño del 'sistema y n~garse a a~igná'r~e:.pef~os sa a los desarrolladores.~·

,j~, 'k'.'·z 5k-- ~ .~

MonitoreoLas tareas de monitoreo refieren a las acciones que normalmente efectúa el DBA pa-ra verificar el desempeño de! servidor y de las bases de datos en él administradas. LaTabla 13 muestra las recomendaciones de monitoreo para realizar un buen análisis.

nirniento que se ocupe, entre otras cosas, de! backup (resguardo) de la base y queesté configurado para truncar e! registro.También es importante tratar de utilizar un conjunto real de datos con el fin deverificar 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.

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ónde la base de datos. Entre ellas, se destaca la de asignar DBA, que normalmente esquien conoce el servidor de destino, asign los recursos necesarios y ocuparse de losaspectos 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.