Objetivo
|
Definir el diseño físico detallado de la base de datos.
|
El diseño de bases de datos físicas incluye elementos de modelo (por ejemplo, tablas, vistas y procedimientos
almacenados) que representan la estructura física detallada de la base de datos y los elementos de modelo (por ejemplo,
esquemas y espacios de tabla) que representan el diseño de almacenamiento de datos subyacente de la base de
datos. De forma colectiva, estos elementos de modelo conforman el Modelo físico de datos de la base de
datos. Este modelo físico de datos está contenido en el Producto de
trabajo: Modelo de datos y no es un producto de trabajo de modelo diferente.
Los pasos detallados para desarrollar el diseño de bases de datos físicas son los siguientes:
Objetivo
|
Definir tipos reutilizables definidos por el usuario.
|
El diseñador de base de datos puede utilizar los dominios para aplicar estándares de tipo en el diseño de la base de
datos. Los dominios son tipos de datos definidos por el usuario que se pueden aplicar a una columna en una tabla.
Los dominios tienen las propiedades de una columna sin el nombre.
Objetivo
|
Crear las tablas y las relaciones iniciales de la base de datos.
|
El diseñador de base de datos modela los elementos del modelo físico de datos utilizando tablas y columnas en tablas,
tal como se describe en Directriz de producto
de trabajo: Modelo de datos.
Si se ha creado un modelo lógico de datos, se pueden utilizar sus entidades lógicas como base para un conjunto de
tablas iniciales.
De forma alternativa, el diseñador de base de datos puede avanzar un paso en el modelo físico de datos utilizando las
clases persistentes del modelo de diseño como punto de partida para las tablas en el modelo físico de datos. El
diseñador de base de datos modela las clases persistentes y sus atributos como tablas y columnas,
respectivamente. El diseñador de base de datos también debe definir las relaciones entre las tablas basándose en
las asociaciones entre las clases persistentes del Modelo de diseño. En Directriz de producto de trabajo: Aplicación de ingeniería directa en bases de datos
relacionales se proporciona una descripción de cómo se correlacionan los elementos y las relaciones del modelo de
diseño con los elementos y las relaciones del modelo de datos.
Si está iniciando el modelo a partir de clases persistentes, y no desde un modelo lógico de datos normalizado, deberá
aplicar alguna normalización para eliminar las redundancias de datos y las dependencias de campos no claves. Consulte
Concepto: Normalización para obtener más información sobre la normalización de bases
de datos.
Objetivo
|
Definir las tablas de referencia estándar que se utilizan en el proyecto.
|
A menudo, en el proyecto se utilizan tablas de búsqueda estándar, tablas de validación o tablas de referencia. Como
normalmente se accede con frecuencia a los datos de estas tablas y rara vez se modifican, estos datos merecen una
consideración especial. En el modelo de diseño, estas tablas pueden contener códigos de producto estándar, códigos de
estado o provincia, códigos postales o zip, tablas de impuestos, tablas de validación de código de área u otra
información de acceso frecuente. En los sistemas financieros, estas tablas pueden contener listas de códigos de
políticas, categorías de índices de políticas de seguros o índices de conversiones. Busque en el modelo de diseño las
clases que sean principalmente de sólo lectura, que proporcionan información de validación para un gran número de
clientes.
Si la tabla de referencia es pequeña, no se moleste en indexarla, ya que la indexación puede añadir unos gastos
generales adicionales a las tablas pequeñas. Una tabla pequeña a la que se accede con frecuencia también suele
permanecer en memoria, ya que los algoritmos de antememoria a menudo mantienen las tablas a las que se accede con
frecuencia en la antememoria de datos.
Si es posible, asegúrese de que la antememoria de base de datos sea lo suficientemente grande para mantener todas las
tablas de referencia en memoria, junto con un "espacio de conjunto de trabajo" normal para las consultas y
transacciones. A menudo, el secreto para aumentar el rendimiento de la base de datos es reducir la E/S de disco.
Una vez definidas las estructuras de las tablas de referencia, determine una estrategia para rellenarlas. Como
normalmente se accede a estas tablas al principio del proyecto, la determinación de los valores de referencia y la
carga de las tablas se suele realizar relativamente al principio del tiempo de ejecución de la aplicación. Aunque el
diseñador de base de datos no es responsable de obtener los datos, sí es responsable de determinar cómo y cuándo se
deben renovar las tablas de referencia.
Objetivo
|
Definir la(s) columna(s) que identifica(n) de forma exclusiva una fila en la tabla.
Definir restricciones en las columnas que garanticen la exclusividad de los datos o la recopilación de
datos.
|
Una clave primaria consta de una o varias columnas que identifican de forma exclusiva las filas de una tabla. Una tabla
tiene una única clave primaria. A menudo, existe una clave "natural" que se puede utilizar para identificar de forma
exclusiva una fila de datos (por ejemplo, el código postal en una tabla de referencia). La clave primaria no debe
contener datos que puedan cambiar con el entorno de empresa. Si la clave "natural" es un valor que puede cambiar (por
ejemplo, el nombre de una persona), se recomienda que el diseñador de base de datos cree una columna no significativa,
no especificada por el usuario, cuando cree una clave primaria. De esta forma, se crea una estructura de datos que
tiene una mayor adaptabilidad a los cambios en la estructura, las reglas o el entorno de empresa.
El uso de una columna no significativa, no especificada por el usuario, como clave primaria es un concepto fundamental
en el diseño de un depósito de datos. Los sistemas de transacciones a menudo eligen una clave primaria "natural" que
puede estar sujeta a cambios mínimos en una columna no significativa, no especificada por el usuario.
Una restricción de unicidad designa que los datos en la columna o la colección de columnas deben ser exclusivos para
cada fila. Si la restricción de unicidad se aplica en una columna, los datos de una determinada fila de la columna
especificada deben ser exclusivos respecto a los datos de otra fila en la misma columna.
Cuando se define una restricción de unicidad para un grupo de columnas, la unicidad se basa en el conjunto de los datos
de las columnas que conforman esa restricción de unicidad. Los datos de una determinada fila de una columna no tienen
que ser exclusivos respecto a los datos de otra fila en la misma columna. El diseñador de base de datos utiliza la
restricción de unicidad para garantizar la exclusividad de los datos empresariales.
Objetivo
|
Garantizar la integridad de la base de datos.
|
Las reglas de integridad de los datos, también conocidas como restricciones, garantizan que los valores de los datos
entren en unos rangos definidos. Siempre que se puedan identificar estos rangos, la base de datos puede aplicarlos.
(Esto no significa que no se deba realizar la validación de los datos en la aplicación, sólo que la base de datos puede
servidor como un "validador de último recurso" en el caso de que la aplicación no funcione correctamente). Cuando
existen reglas de validación de datos, se deben diseñar restricciones de base de datos para aplicarlas.
Una clave externa es una o varias columnas en una tabla que se correlacionan con la clave primaria en otra tabla. Una
tabla puede tener muchas claves externas, y cada clave externa es una correlación con otra tabla. Esta correlación, o
relación, entre las tablas se conoce a menudo como relación padre-hijo. La tabla hijo contiene la clave externa,
que se correlaciona con la clave primaria en la tabla padre.
El optimizador de consultas también utiliza a menudo la definición de restricciones de clave externa para acelerar el
rendimiento de las columnas. En muchos casos, las reglas de aplicación de claves externas utilizan tablas de
referencia.
Objetivo
|
Optimizar las estructuras de datos de la base de datos para el rendimiento.
|
En el caso de un modelo de datos relacional, la correlación inicial generalmente produce una correlación sencilla de
clase con tabla. Si se deben recuperar al mismo tiempo objetos de clases diferentes, RDBMS utiliza una operación
denominada "unión de tablas" para recuperar las filas relacionadas con los objetos de interés. Para los datos a los que
se accede con frecuencia, las operaciones de unión pueden implicar un gasto computacional excesivo. Para eliminar el
coste de la unión, se utiliza a menudo una técnica relacional estándar denominada "desnormalización".
Las desnormalización combina columnas de dos o más tablas diferentes en la misma tabla, para unir previamente la
información de manera eficaz. La desnormalización refleja un intercambio entre las operaciones de actualización más
costosas a favor de las operaciones de recuperación menos costosas. Esta técnica también reduce el rendimiento del
sistema en las consultas que sólo están interesadas en los atributos de uno de los objetos que están unidos
correctamente en la tabla de desnormalización, ya que normalmente se recuperan todos los atributos en cada consulta. En
aquellos casos en los que la aplicación casi siempre necesita todos los atributos, puede producirse un aumento
significativo del rendimiento.
La desnormalización de más de dos tablas es poco común y aumenta el coste de las inserciones y las actualizaciones, así
como el coste de las consultas que no son de unión. La limitación de la desnormalización a dos tablas es una buena
política, a menos que tenga una evidencia clara y convincente de que resulte ventajoso.
La desnormalización se puede inferir de las clases de
diseño en aquellos casos en los que las clases estén anidadas. Las clases anidadas se pueden correlacionar con una
tabla desnormalizada.
Algunas bases de datos de objetos permiten un concepto parecido a la desnormalización, en el que los objetos
relacionados se agrupan en clúster en disco y se recuperan en operaciones individuales. El concepto de la utilización
es parecido: reducir el tiempo de recuperación de los objetos al reducir el trabajo que debe realizar el sistema para
recuperar los objetos relacionados de la base de datos.
En algunos casos, la optimización del modelo de datos puede desenmascarar problemas en el Modelo de diseño como, por ejemplo, cuellos de botella de
rendimiento, modelado deficiente o diseños incompletos. En este caso, analice los problemas con el Diseñador de la clase y desencadene solicitudes de cambio cuando sea
necesario.
Objetivo
|
Proporcionar un acceso eficaz a los datos mediante la indexación.
Proporcionar un acceso eficaz a los datos mediante vistas de base de datos.
|
Una vez diseñada la estructura de la tabla, debe determinar los tipos de consulta que se ejecutarán en los datos. La
base de datos utiliza la indexación para acelerar el acceso. La indexación es más eficaz cuando los valores de datos de
la columna que se está indexando son relativamente diferentes.
Tenga en cuenta los siguientes principios de indexación:
-
La columna de clave primaria debe estar siempre indexada. Las columnas de clave primaria se utilizan a menudo como
claves de búsqueda y en operaciones de unión.
-
Las tablas de menos de 100 filas y con pocas columnas se benefician poco de la indexación. En general, las tablas
pequeñas entran fácilmente en la antememoria de la base de datos.
-
También se deben definir índices para las consultas que se ejecutan con frecuencia o para las consultas que deben
recuperar datos rápidamente (generalmente, en todas las búsquedas en las que una persona deba esperar). Se debe
definir un índice para cada conjunto de atributos que se utilizan conjuntamente como criterio de búsqueda. Por
ejemplo, si el sistema necesita la capacidad de encontrar todos los pedidos en los que se solicita un determinado
producto, será necesario un índice de la columna Número de producto en la tabla Elemento de línea.
-
Generalmente sólo se deben definir índices de las columnas que se utilizan como identificadores, no de los valores
numéricos como, por ejemplo, los saldos de cuenta, ni de información textual como, por ejemplo, los comentarios del
pedido. Los valores de las columnas de identificador se suelen asignar cuando se crea el objeto y, posteriormente,
permanecen sin modificar durante la vida del producto.
-
Los índices de números simples (tipos de datos numéricos y enteros) son más fáciles y rápidos que los índices de
las series. Teniendo en cuenta los grandes volúmenes de datos que se procesan en una consulta o una unión de gran
tamaño, los pequeños ahorros se suman rápidamente. Los índices de las columnas numéricas tienden a ocupar
menos espacio que los índices de caracteres.
Por otro lado, el uso de índices no es gratuito; cuantos más índices haya en una tabla, más tardan las inserciones y
las actualizaciones en procesarse. Cuando contemple el uso de índices, tenga en cuenta las siguientes precauciones:
-
No utilice la indexación para acelerar una consulta que se ejecute con poca frecuencia, a menos que la consulta se
realice en un punto crítico en el que la velocidad máxima sea fundamental.
-
En algunos sistemas, el rendimiento de las actualizaciones y las inserciones es más importante que el rendimiento
de las consultas. Un ejemplo clásico son las aplicaciones de adquisición de datos de fábrica en las que los datos
de calidad se capturan en tiempo real. En estos sistemas, sólo se ejecutan consultas en línea ocasionales, y la
mayoría de los datos se analizan periódicamente en aplicaciones de informes por lotes que ejecutan análisis
estadísticos en ellos. Para los sistemas de adquisición de datos, elimine todos los índices para obtener el máximo
rendimiento. Si los índices son necesarios, se pueden volver a crear justo antes de ejecutar las aplicaciones de
análisis e informes por lotes, y eliminarlos después cuando finalicen los informes y el análisis.
-
Recuerde siempre que los índices tienen costes ocultos. Por ejemplo, tardan tiempo en actualizarse (un gravamen que
se paga en cada inserción, actualización o supresión) y ocupan espacio de disco. Asegúrese de que su uso es
ventajoso.
Muchas bases de datos ofrecen una amplia gama de tipos de índice. Los más comunes son:
-
Índices de árboles B: los tipos más utilizados se basan en estructuras equilibradas de datos de índices de
árbol B. Son muy útiles cuando los valores de clave de índice se distribuyen de manera aleatoria y tienden a tener
una amplia variabilidad. No obstante, no funcionan tan bien cuando los datos que se están indexando están ya en
orden secuencial.
-
Índices hash: con menos frecuencia, los valores de clave de índice se basan en hash. La función hash ofrece
un mejor rendimiento cuando la gama de valores de clave de índice es conocida, exclusiva y relativamente
invariable. Esta técnica se basa en el uso del valor de clave para calcular la dirección de los datos de interés.
Debido a la necesidad de previsibilidad, los índices hash tienden a ser útiles sólo para tablas de búsqueda de
tamaño medio que cambian con muy poca frecuencia.
La elección de la estrategia de índice y el tiempo de creación de índice puede tener un gran impacto en el rendimiento.
Las cargas de datos en masa se deben ejecutar sin índices (para ello, elimine el índice, cargue los datos y vuelva a
crear el índice). El motivo de esto es que la estructura del índice se vuelve a equilibrar cada vez que se añade una
fila. Como las siguientes filas cambiarán la estructura óptima del índice, el esfuerzo de volver a equilibrar el índice
al insertar cada fila es una pérdida de tiempo. Es más rápido y más eficaz cargar los datos sin índices y volver a
crear el índice cuando finalice la carga de datos. Algunas bases de datos proporcionan cargadores de datos en masa para
realizar esta operación automáticamente.
Otra estrategia para optimizar el rendimiento del acceso a la base de datos es el uso de vistas. Las vistas de base de
datos son tablas virtuales que no tienen un almacenamiento independiente propio. No obstante, para el programa (o
usuario) que realiza la llamada, una vista se comporta como una tabla. Una vista da soporte a la recuperación de datos,
y se puede utilizar también para actualizar datos, dependiendo de la estructura y el proveedor de la base de datos. La
vista contiene datos de una o varias tablas a las que se puede acceder mediante una única sentencia select. El aumento
del rendimiento se produce durante la selección de los datos, especialmente en las tablas consultadas con frecuencia.
Los datos se recuperan de una única ubicación (la vista), en lugar de buscando en las múltiples tablas o las tablas de
gran tamaño que existen en la base de datos.
Las vistas también juegan un papel importante en la seguridad de la base de datos. Una vista que contiene partes de una
tabla puede restringir el acceso a datos confidenciales contenidos en la tabla de la base de datos.
Objetivo
|
Diseñar la asignación de espacio y la organización de páginas de disco de la base de datos.
|
Un diseñador de base de datos utiliza espacios de tabla para representar la cantidad de espacio de almacenamiento que
se asigna a las tablas, índices, procedimientos almacenados, etc. Uno o varios espacios de tabla están correlacionados
con una base de datos. El diseñador de base de datos debe analizar las tablas en el Modelo de datos para determinar
cómo distribuirlas, junto con otros elementos de base de datos de soporte, en el espacio de almacenamiento de la base
de datos.
Cuando determine las estructuras de espacios de tabla de la base de datos, tenga en cuenta que las bases de datos no
ejecutan E/S en filas, registros ni en tablas completas. Ejecutan E/S en bloques de disco. El motivo de ello es
sencillo: las operaciones de E/S de bloqueo están normalmente optimizadas en el software y el hardware del sistema.
Como resultado, la organización física de las tablas y los índices en la base de datos puede tener un efecto negativo
en el rendimiento del sistema.
Cuando planifique la asignación de espacio y la organización de páginas de disco de la base de datos, tenga en cuenta
los siguientes factores:
-
la densidad de la información en las páginas de disco
-
la ubicación de las páginas de disco en el disco o en múltiples discos
-
la cantidad de espacio de disco que se debe asignar a la tabla
Estos factores se describen en los siguientes apartados:
Densidad de páginas de discos
La densidad de las páginas de disco depende del grado de cambio que se espera de los datos en el tiempo.
Básicamente, una página menos densa tiene más capacidad de aceptar cambios en los valores o la adición de datos con
el tiempo, mientras que las páginas de datos más llenas proporcionan un mayor rendimiento de lectura, ya que se
pueden recuperar más datos por lectura de bloque.
Para simplificar la gestión de discos, el diseñador de base de datos puede agrupar las tablas según el grado en que
tienden a cambiar. Los tres grupos siguientes constituyen un buen principio para este tipo de organización:
-
tablas muy dinámicas
-
tablas un poco dinámicas
-
tablas mayoritariamente estáticas
Las tablas muy dinámicas se deben correlacionar con páginas de disco que tengan una gran cantidad de espacio vacío
(alrededor del 30%); las tablas un poco dinámicas se deben correlacionar con páginas de disco que tengan menos
espacio vacío (alrededor del 15%); y las mayoritariamente estáticas se deben correlacionar con páginas de disco que
tenga muy poco espacio vacío (alrededor del 5%). Los índices de las tablas se deben correlacionar de forma
parecida.
Ubicación de páginas de discos
Una vez correlacionados los grupos de tablas, el diseñador de base de datos debe determinar dónde colocar las
páginas de disco. El objetivo es intentar equilibrar la carga de trabajo entre varias unidades y cabezas diferentes
para reducir o eliminar los cuellos de botella. Tenga en cuenta las siguientes directrices:
-
No coloque nunca datos en el mismo disco que el sistema operativo, los archivos temporales o los dispositivos
de intercambio. Estas unidades ya tienen suficiente trabajo sin necesidad de añadirles más carga de trabajo.
-
Coloque los datos a los que se accede simultáneamente en unidades diferentes para equilibrar la carga de
trabajo. Algunos sistemas dan soporte a los canales de E/S paralelos. Si este es el caso, coloque los datos en
canales diferentes.
-
Coloque los índices en una unidad diferente de la de los datos que indexa para repartir la carga de trabajo.
-
Consulte las directrices que se incluyen en la documentación del proveedor de la base de datos.
-
El tipo de almacenamiento utilizado (por ejemplo, RAID-5, RAID-10, SAN, NAS y conectado mediante canal) afecta
al rendimiento de la base de datos. Utilice las directrices de rendimiento proporcionadas por el proveedor del
almacenamiento.
La E/S de la base de datos es generalmente el factor límite del rendimiento de la base de datos. El equilibrio de
E/S es un proceso experimental iterativo. La creación del prototipo del rendimiento de acceso de la base de datos
durante la fase de elaboración, conjuntamente con la instrumentación adecuada para supervisar la E/S física y
lógica, permite descubrir problemas de rendimiento al principio, cuando todavía tiene tiempo para ajustar el diseño
de la base de datos.
Asignación de espacio de disco
Utilizando las características del mecanismo de diseño de persistencia, calcule el número de objetos que se debe
almacenar. La cantidad de espacio de disco necesario para almacenar los objetos varía de RDBMS a RDBMS. Cuando
calcule el espacio de disco, asegúrese de tener en cuenta el rendimiento debido a las adiciones de datos.
Para calcular el espacio de disco de una base de datos, calcule primero el espacio de disco necesario para cada
tabla y, a continuación, calcule los requisitos de espacio de todas las tablas. Consulte el manual del
administrador de la base de datos del producto RDBMS específico para determinar la fórmula precisa de cálculo del
tamaño. A continuación se proporcionan algunos pasos generales para calcular los requisitos de espacio de una
tabla:
-
Calcule el tamaño medio de las filas. Este cálculo debe incluir la información de control a nivel de
registro, así como la información de control necesaria para las columnas de longitud variable.
-
Calcule el número de filas que entrarán en una página o bloque de E/S. Como la mayoría de bases de datos
almacenan sólo registros completos en una página o bloque de E/S, este debe ser el número entero de filas que
entrarán en una página o bloque de E/S.
-
Calcule el número de páginas o bloques de E/S que se necesitan para almacenar el número estimado de registros
en la base de datos. El número estimado de registros debe incluir los factores de carga.
-
Multiplique el número de páginas o bloques de E/S que se necesitan por el tamaño de la página o bloque de E/S.
-
Súmele los gastos generales de los índices adicionales.
-
Súmele los gastos generales fijos de la tabla.
Una vez definidos los requisitos de espacio de la tabla:
-
Haga la suma del espacio que necesitan las tablas.
-
Súmele la cantidad de espacio fija necesaria para la gestión de la base de datos.
-
Súmele el espacio de disco necesario para el registro de transacciones y la pista de auditoría.
En un entorno actualizado con frecuencia, los requisitos de retención de la pista de auditoría requieren una
cantidad significativa de almacenamiento. La documentación de los principales sistemas de gestión de bases de datos
comerciales normalmente proporcionan instrucciones detalladas sobre el ajuste de tamaño. Asegúrese de consultar
estas instrucciones cuando calcule los valores estimados de los requisitos de espacio de disco de la base de datos.
Objetivo
|
Determinar si se deben utilizar los procedimientos almacenados o los desencadenantes para implementar
operaciones de clase de acceso a datos.
|
La mayoría de bases de datos dan soporte a la capacidad de procedimiento almacenado. Un procedimiento almacenado es
código ejecutable que se ejecuta en el espacio de proceso del sistema de gestión de bases de datos. Ofrece la
posibilidad de ejecutar acciones relacionadas con la base de datos en el servidor sin necesidad de transferir datos en
una red. El uso correcto de los procedimientos almacenados puede aumentar el rendimiento del sistema.
Los procedimientos almacenados normalmente pueden ser de dos tipos: procedimientos reales o desencadenantes. Los
procedimientos los ejecuta explícitamente una aplicación, generalmente tienen parámetros y proporcionan un valor de
retorno explícito. Por otro lado, los desencadenantes se invocan implícitamente cuando se produce algún suceso de base
de datos (por ejemplo, se inserta, se actualiza o se suprime una fila), no tienen parámetros aparte de la fila que se
está modificando (ya que se invocan de forma implícita), y no proporcionan un valor de retorno explícito.
En los sistemas de base de datos que no tienen restricciones, los desencadenantes se utilizan a menudo para forzar la
integridad referencial y de datos. De lo contrario, tienden a utilizarse cuando un suceso debe desencadenar (o
provocar) otro suceso. Los desencadenantes también se utilizan a efectos de seguridad mediante auditorías del suceso
desencadenante.
Las clases de diseño en el Modelo de diseño se deben examinar para ver si tienen operaciones que se implementan
utilizando el procedimiento almacenado o el recurso de desencadenante. Las posibles candidatas son:
-
las operaciones que tratan principalmente con datos persistentes (crear, actualizar, recuperar o suprimir datos
persistentes).
-
las operaciones en las que hay implicada una consulta en un cálculo (por ejemplo, calcular la cantidad media y el
valor medio de un producto en el inventario).
-
las operaciones que deben acceder a la base de datos para validar los datos.
Recuerde que aumentar el rendimiento de la base de datos significa normalmente reducir la E/S. Por lo tanto, si la
realización de un cálculo en el servidor de DBMS reduce la cantidad de datos que se pasa en la red, el cálculo deberá
realizarse probablemente en el servidor.
Trabaje con el diseñador de la clase de diseño para determinar cómo se puede utilizar la base de datos para aumentar el
rendimiento. El diseñador actualizará el método de operación para indicar si se pueden utilizar uno o más
procedimientos almacenados para implementar la operación.
|