CODIGOHTML=<font color="00000" size="15"><b>Desempeo</b>
El <i>desempeo</i> se refiere a la capacidad de recuperar informacin en un tiempo y a un costo razonable. El desempeo en una base de datos puede ser afectado por factores tales como velocidades de comunicacin, numero de usuarios concurrentes, limites de recursos, entre otros. El desempeo, principalmente medido en funcion de tiempo de respuesta a consultas de datos, generalmente se evala calculando el nmero de transacciones por segundo.
La <i>denormalizacin</i> es el proceso de procurar optimizar el desempeo de una base de datos por medio de agregar datos redundantes. A veces es necesaria porque los actuales Sistemas Gestores de Base de Datos (SGBD) implementan el modelo relacional pobremente. Un verdadero SGBD relacional debe permitir una base de datos completamente normalizada a nivel lgico, mientras proporciona el almacenamiento fsico de los datos afinado para alto rendimiento.
El acercamiento ms usual es denormalizar el diseo de datos lgico. Con cuidado, esto puede alcanzar una mejora similar en respuesta de consulta, pero a un costo - ahora es la responsabilidad del diseador de la base de datos de asegurarse de que la base de datos denormalizada no llegue a ser inconsistente. Esto es hecho creando reglas en la base de datos llamadas restricciones, que especifican cmo las copias redundantes de informacin se deben mantener sincronizadas. Es el aumento en la complejidad lgica del diseo de la base de datos y la complejidad aadida de las restricciones adicionales que hacen a este acercamiento peligroso. Por otra parte, debido a los gastos indirectos de evaluacin de restricciones al insertar, actualizar, o eliminar datos, una base de datos denormalizada puede realmente ofrecer un desempeo peor que sus funcionalmente equivalentes contrapartes normalizadas. Cuando se est seleccionado o leyendo datos a menudo el desempeo ser mejor.
Un modelo de datos denormalizado no es lo mismo que un modelo de datos que no ha sido normalizado, y la denomarlizacin debe tomar lugar solamente despus de que haya ocurrido un nivel satisfactorio de normalizacin y de que hayan sido creadas las restricciones y/o reglas requeridas para ocuparse de las anomalas inherentes en el diseo. Por ejemplo, que todas las relaciones estn en la tercera forma normal y cualquier relacin con dependencias de unin (join) y multi-valor sean manejadas apropiadamente.
Ejemplos de tcnicas de denormalizacin incluyen:
Vistas materializadas, que pueden implementar lo siguiente: 
<li>Almacenando la cuenta de "muchos" objetos en una relacin uno-a-muchos como un atributo de la relacin "uno"
Agregando atributos a una relacin de otra relacin con la cual ser unida (join)
Esquemas en estrella que tambin son conocidos como modelos hecho-dimensin y se han extendido a los esquemas de copo de nieve
Informacin de resumen preconstruida (til para informes, data warehouse o data mining) o cubos OLAP (On-Line Analytical Processing).</li>
<b>Afinamiento</b>
Cuando es indispensable asegurar el acceso en tiempo real a los datos, los usuarios del sistema se interesan al extremo en el tiempo de respuesta del sistema. En los sistemas de procesamiento por lotes, el inters se traslada al caudal de transacciones que el sistema admite al tiempo que se tarda en despachar la carga de trabajo. Estos factores dependen del tiempo necesario para acceder a los datos necesarios y dependen tambin de la organizacin de stos y su localizacin en las unidades de almacenamiento. La diferencia entre una organizacin adecuada y una organizacin inadecuada se reflejan como una gran diferencia en los tiempos de respuesta y en los caudales de transacciones. 
Cuando el almacenamiento se prev para un conjunto especifico y bien entendido de operaciones, por ejemplo: en el caso de un sistema de reservaciones de plazas en las aerolneas, es posible optimizar, para esas operaciones, la organizacin del almacn y la localizacin de los datos en el. El diseador sabe perfectamente que es lo que tiene entre manos. No siempre el proyectista es tan afortunado. En muchos casos ni siquiera sabe como se van a utilizar en realidad los archivos, como se interrogar la base o con qu frecuencia. Resulta por tanto necesario ajustar, y hasta cambiar fundamentalmente, la organizacin del almacn despus que el sistema ha entrado en servicio y se han aclarado suficientemente las pautas del uso. En muchos casos, el uso de la base de datos evoluciona contnuamente, a medida que ms personas se van familiarizando con ella y se crean ms programas de aplicacin. El ajuste de la organizacin del almacn con el objeto de mejorar su desempeo se convierte as en un proceso continuo. 
Este proceso de ajuste de la base de datos se llama afinacin (turing). En la prctica, la afinacin ha conducido a menudo a importantes economas. A veces stas han sido tan importantes como para marcar la diferencia entre una aplicacin rentable y lo que no lo es. El responsable de la afinacin de la base de datos es el administrador de su grupo, y es importante que este tenga libertad para introducir los cambios que estime necesario, sin hacer estragos en los programas de aplicacin. Sin un software apropiado, la afinacin suele incurrir en costos inadmisibles en lo que se refiere al mantenimiento y la prueba de programas. 
La correcta afinacin tiene los siguientes requisitos: 
<li>Necesita la independencia fsica de los datos.
Requiere medios para supervisar automticamente el uso de la base de datos con el fin de que puedan hacerse los ajustes necesarios.
En las futuras bases de datos se incorporan posiblemente algunos medios para la afinacin automtica. </li>


</font>