CAPITULO 2: “Las Reglas de Negocio en la arquitectura del sistema”
2.3. Arquitectura de tres capas para la aplicación
2.3.1. Capa servidor o de datos
Esta capa se corresponde con la representación física de la base de datos dentro de la arquitectura. Aquí residen los datos y están los métodos de acceso que se utilizan para recuperarlos y actualizarlos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento, reciben solicitudes de almacenamiento o recuperan información desde la capa de negocio.
En este epígrafe se aborda acerca del diseño de la base de datos y las modificaciones que se proponen para mejorar su diseño e implementación, además se ejemplifica con las reglas de negocio que son implementadas en esta capa.
47 2.3.1.1. Diseño de la Base de Datos
La base de datos cuenta con una entidad principal del esquema, la tabla paciente, que tiene una serie de atributos que representan los datos generales sobre un paciente y que normalmente están en cualquier historia clínica de atención secundaria. Con esta entidad base, están relacionadas todas las demás entidades (alergias medicamentosas, operaciones, transfusiones, enfermedades contraídas, adicciones, análisis, diagnósticos, examen físico, interrogatorio por aparatos, etc.) que también contienen información general acerca del paciente; lo cual permite que los submodelos (Consulta de Progresión, Hemodiálisis Ambulatoria y Trasplante Renal) se simplifiquen considerablemente, pues tan sólo contendrán la información específica de ellos. En la Figura 2. 4 se muestra el diseño de la base de datos para la entidad paciente y sus entidades relacionadas.
Este trabajo se concentra en el submodelo de trasplante renal, y para él se crean las entidades relacionadas (receptores, donantes vivos, donantes muertos, donantes potenciales, etc.).
En el submodelo de trasplante renal, tenemos como entidad principal paciente de trasplante. Es importante señalar que un paciente del área de trasplante puede ser un receptor o un donante vivo y esto se debe a que después del acto de trasplante ambos tienen que asistir a este tipo de consulta. El donante potencial es un paciente que actúa como posible donante de un receptor que espera ser trasplantado; una vez realizada la donación es que entonces el donante potencial pasa a ser también un paciente del área de trasplante.
En las entidades donante vivo y donante muerto se recoge toda la información referente a las respectivas operaciones de los donantes, y en la de trasplante se recoge la que corresponde al acto operatorio del receptor. Para este trabajo se han eliminado del diseño anterior las entidades trasplante donante muerto y trasplante donante vivo que se usaban para diferenciar el tipo de trasplante, relacionando ahora directamente las entidades donante vivo y donante muerto con trasplante y utilizando el campo que indica el tipo de donante para diferenciar ambos trasplantes.
En la Figura 2. 5se muestra el diseño de la base de datos para el submodelo Trasplante Renal y se
48
Para mayor comprensión se muestran los nombres de las entidades en español, aunque para el problema en cuestión han sido llevados al idioma inglés para aprovechar las facilidades que nos brinda el CakePHP cuando se trabaja en este idioma, porque de no ser así, muchos de los enlaces entre los modelos, controladores y vistas que se crean automáticamente habría que definirlos.
49
Figura 2. 5: Submodelo de Trasplante Renal 2.3.1.2. Capa de datos para el sistema de trasplante renal
En la capa de datos implementaremos las reglas que se ajustan según su clasificación al tipo relación.
50
Con un correcto diseño de la base de datos quedan automáticamente implementadas muchas de las reglas del sistema (validaciones), como son que la fecha, que es un atributo presente en muchas tablas, tiene que ser de tipo DATE para que nunca sea posible escoger el día que no es válido, por ejemplo el 30 de febrero.
Las reglas de relación que tienen que ver más con las regulaciones de la política del negocio son bastante estables y pueden quedar representadas en la capa de datos, un ejemplo sería:
R4: Un posible receptor debe ser asociado al menos a un donante potencial. El diseño de esta regla en la base de datos queda como sigue:
Figura 2. 6: Representación de una regla de negocio en la capa de datos.
Su implementación se realiza en el modelo receptor (receiver) cuando representamos las relaciones entre las tablas, por ejemplo esta regla se implementa como sigue:
public $hasMany = array(
'PotentialDonor' => array(
'className' => 'PotentialDonor',
'foreignKey' => 'receiver_id'
)
)
En el modelo donante potencial (potential_donor) la relación inversa debe representarse como sigue:
public $belongsTo = array(
'Receiver' => array(
'className' => 'Receiver',
'foreignKey' => 'receiver_id'
)
)
En el Error! Reference source not found. aparecen otras reglas de relación dentro del subtipo estructura de conceptos que también quedan implementadas cuando representamos las relaciones entre las tablas dentro del modelo.
Posible Receptor Donante Potencial 1 1... M
51
En contraste con el ejemplo anterior, otras reglas, como la que limita la edad de un posible receptor de donante vivo en trasplante renal, aunque pueden parecer indicadas para la capa de datos tienen el inconveniente de que aún cuando constituyen restricciones que tienen que ver con datos presentes en la base de datos, no se deben implementar en esta capa por estar muy propensas a cambios, porque los distintos hospitales hacen sus consideraciones y se mantienen las investigaciones para determinar cuál sería la más indicada.