Exportar (0) Imprimir
Expandir todo
Personas que lo han encontrado útil: 1 de 1 - Valorar este tema

Reglas de empresa para el acceso a datos

Visual Studio .NET 2003

Se pueden utilizar reglas de empresa para controlar de forma coherente y correcta el acceso a datos de la aplicación. O mejor todavía, otras aplicaciones podrían utilizar las mismas reglas de empresa y así beneficiarse de las relaciones y dependencias de procesos integradas que se hayan creado. En general, las reglas de empresa que controlan el acceso a datos deben diseñarse con detenimiento con el fin de que proporcionen procesos independientes pero perfectamente coordinados.

Elegir la forma de exigir las reglas de empresa

Al definir las reglas de empresa para tener acceso a los datos, se eligen los mecanismos en tiempo de ejecución que la aplicación utilizará para exigir las reglas aplicables a los datos. En principio, hay que determinar el servicio o componente que debe exigir la regla y la forma exacta en que se implementará dicha regla. A la hora de tomar esta determinación deben considerarse varios puntos:

  • Qué mecanismos de exigencia están disponibles   El sistema de administración de bases de datos (DBMS), el código de los servicios de la aplicación o los componentes de interfaz de usuario como formularios Windows Forms o Web Forms pueden exigir las reglas. En el sistema de administración de bases de datos, una regla se puede exigir con tipos de datos, restricciones, desencadenadores o procedimientos almacenados. En un componente, como un objeto comercial, una regla se puede exigir mediante programación a través del control de eventos (por ejemplo, se puede exigir una regla cada vez que se desencadene el evento RowChanged). En un componente de interfaz de usuario se puede exigir una regla mediante programación o a través de los controles de interfaz de usuario que pueden controlar la edición de datos locales.
  • ¿Es deseable una exigencia redundante?   Aunque la exigencia redundante de una regla pueda parecer una pérdida de tiempo, no se debe descartar. Por ejemplo, se podría elegir la opción de exigir una regla en un formulario y en el sistema de administración de bases de datos. Mediante la exigencia de la regla en el formulario, se mejora el rendimiento de la operación de entrada de datos (evitando así la comunicación de ida y vuelta con la base de datos). Mediante la exigencia de la regla en el sistema de administración de bases de datos, se garantiza que todos los datos cumplan la regla, y no sólo los datos introducidos a través del formulario en cuestión. En un entorno de programación que exija rapidez y continua actividad, puede que otro programador cree un formulario que no exija la regla. También es posible que un usuario de bases de datos con experiencia y un alto grado de privilegios utilice SQL para insertar filas directamente en la base de datos. En un entorno de estas características, la forma más fiable de garantizar la corrección de los datos es utilizar el sistema de administración de bases de datos para exigir la regla.
  • Con qué rigor se debe exigir la regla   Es decir, si la regla requiere una exigencia rigurosa y constante o si es aceptable exigir la regla sólo periódicamente o sólo durante determinadas fases de un proceso. Por ejemplo, una regla que exija que "el número de las tarjetas de crédito tenga 16 dígitos" podría requerir una exigencia rigurosa porque la base de datos no debe contener en ningún momento un número de tarjeta de crédito incorrecto.

    Por otro lado, una regla que exija que "las órdenes de compra deben tener una dirección de envío" podría no requerir una imposición continua. Una regla de este tipo requeriría una exigencia sólo durante ciertos momentos del procesamiento de órdenes. Por ejemplo, si el agente de ventas y el cliente necesitan varios días para completar una orden de compra, a la espera de que el cliente elija exactamente los productos que desea comprar, la orden de compra puede permanecer incompleta en la base de datos durante esos días. Cuando se completa la orden de compra y se transmite al departamento de envíos, debe tener una dirección de envío. No es preciso que se exija la regla que requiere una dirección de envío durante las etapas previas del proceso de generación de órdenes.

  • Cómo afectará la exigencia al rendimiento   El tipo elegido de exigencia de una regla puede afectar al concepto que se forme el usuario sobre el rendimiento de la aplicación. Por ejemplo, si existe la posibilidad de que una regla sólo se exija en un formulario o en la base de datos, es conveniente elegir que se exija en el formulario para que los usuarios no tengan que esperar una comunicación de ida y vuelta con la base de datos antes de descubrirse un error tipográfico, por ejemplo.
  • Cómo afectará la exigencia a la capacidad de mantenimiento   Una regla especialmente compleja puede implementarse de forma que tenga un fácil mantenimiento. Es decir, se puede elegir un mecanismo de implementación que muestre una gran afinidad con la propia regla. Por ejemplo, si la regla controla las secuencias de las tareas automatizadas de la solución de software, se puede implementar en un lenguaje que disponga de mecanismos para instrucciones CASE o SWITCH complejas, y en un lenguaje que disponga de mecanismos para desencadenar eventos y responder a ellos.

Determinar las reglas de empresa

Una aplicación requiere reglas de empresa para el acceso a los datos en cualquiera de las siguientes circunstancias:

  • Insertar, actualizar, eliminar y ver los datos.
  • Validar los datos.
  • Controlar la seguridad de los datos.
  • Controlar el acceso a datos de varios archivos.
  • Proporcionar integridad referencial.

Manipulación de datos

Es posible utilizar una regla de empresa cada vez que la aplicación inserta, actualiza, elimina o ve datos. Las reglas de empresa implementadas de este modo proporcionan un control conciso sobre los datos que se pueden actualizar y la forma de actualizarlos. Por ejemplo, si la aplicación inserta nuevas órdenes de venta al archivo de facturas, una regla de empresa debería comprobar automáticamente el límite de crédito del cliente antes de aceptar e insertar los elementos de la línea de órdenes de venta.

Validar datos

La validación de datos es el proceso de comprobación de los valores de los campos (por ejemplo, si el campo numérico lo es realmente y si está dentro del intervalo) y de validación de los valores de archivos relacionados (por ejemplo, si la identificación de una editorial existe en el archivo Editoriales). Si todas las rutinas de validación de datos se colocan en reglas de empresa, la aplicación puede garantizar que los datos sean correctos y que se adapten fácilmente a los requisitos futuros. Para obtener más información, vea Validación de datos.

Controlar la seguridad de los datos

Puede que la aplicación requiera seguridad de acceso para controlar quién tiene acceso para ver y modificar datos de la aplicación. La seguridad no sólo consiste en autorizar los inicios de sesión de los usuarios; la seguridad implica también el control del acceso a todos los componentes de la arquitectura de la aplicación y el control de los procesos de acceso a datos, incluidos los siguientes servicios:

  • Servicios de interfaz de usuario.
  • Servicios del sistema operativo.
  • Servicios de procesos de empresa.
  • Servicios de transmisión de datos.
  • Servicios de base de datos.

Para obtener más información sobre la forma de controlar la seguridad de la aplicación para evitar manipulaciones y modificaciones no autorizadas, vea Creación de aplicaciones seguras.

Controlar el acceso a datos de varios archivos

Si la aplicación tiene que seguir paso a paso una cadena compleja de valores lógicos y de datos con el fin de prepararse para un proceso de decisión, se debe utilizar una regla de empresa para simplificar el acceso a varios archivos. La regla de empresa buscará automáticamente todas las estructuras de datos necesarias y volverá a empaquetarlas para facilitar su uso. Por ejemplo, supongamos que la aplicación tiene que determinar el importe máximo posible para un único procedimiento de petición de asistencia sanitaria de varias líneas. Mientras se inspecciona el elemento de línea actual, se debe buscar el historial completo de peticiones del beneficiario para utilizar previamente un procedimiento idéntico. Además, deben comprobarse los límites de duración del contrato y la fecha actual para determinar el importe permitido. Este tipo de acceso a datos de varios archivos presenta una oportunidad excelente para crear una regla de empresa reutilizable que controle la situación de forma coherente y correcta.

Proporcionar integridad referencial

Uno de los usos más comunes de las reglas de empresa es el control de la integridad referencial. La integridad referencial es importante para el caso de archivos indizados y de archivos relacionales. Como los archivos indizados (como un archivo VSAM) son generalmente motores de almacenamiento de datos sin procesar, la aplicación debe proporcionar código personalizado para controlar las restricciones, la eliminación de claves externas y otros aspectos comunes de integridad referencial. La integridad referencial basada en aplicaciones también puede ser apropiada para las bases de datos relacionales, especialmente en situaciones donde los desencadenadores, las restricciones y los procedimientos almacenados son inadecuados o demasiado complicados. Para obtener más información sobre el mantenimiento de relaciones correctas entre tablas, vea Integridad referencial.

La creación de reglas de empresa para el acceso a los datos requiere un diseño cuidadoso, sobre todo si se considera la interacción con reglas de empresa existentes que pertenecen a otras aplicaciones. La ventaja radica en que se garantiza la seguridad, la precisión y la facilidad de acceso de los datos por parte de la propia aplicación y de otras aplicaciones.

Vea también

Exigir la integridad referencial entre tablas | Componentes de una aplicación | Integridad de datos | Diseño de bases de datos lógicas | Imponer reglas de empresa con desencadenadores

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.