Cómo se estructuran los datos de la aplicación
La jerarquía y las relaciones entre componentes en que se estructuran los datos de ContractManager se describe a continuación.
Jerarquía
Puede personalizar la estructura de datos de ContractManager para adaptarla a sus necesidades. Sin embargo, hay una estructura base que debe respetar:
•A nivel raíz de la aplicación puede crear tantas bases de datos como quiera. Por ejemplo, en la estructura de la imagen siguiente hay dos: (i) Contract Database, (ii) Company Database.
•Dentro de cada una de ellas puede agregar tantos contenedores de nivel superior como quiera. En nuestra BD de ejemplo Contract Database tiene un contenedor de nivel superior (Contract), mientras que Company Database tiene dos (Company Group y Company).
•Dentro de un contenedor de nivel superior (o dentro de los de niveles inferiores) puede añadir varios contenedores secundarios. Puede seguir añadiendo contenedores secundarios a distintos niveles. Por ejemplo, el contenedor Company tiene el contenedor secundario Department, que a su ver tiene el contenedor secundario Person.
Los contenedores están vinculados con relaciones, que se describen más abajo.
Los datos de los contratos del usuario se almacenan como registros de los contenedores. Cada contenedor contiene varios campos que a su vez contienen los datos de los registros. Consulte el apartado siguiente, Almacenamiento de datos.
Relaciones
Al definir la estructura de BD lo que hace es definir relaciones entre contenedores. Estas relaciones son importantes para la jerarquía y la organización de los datos, por lo que es importante que las planee bien.
Entre contenedores puede haber dos tipos de relaciones:
•Relaciones primario-secundario
•Enlaces sueltos
Relaciones primario-secundario
Estos enlaces entre contenedores se consideran fuertes, ya que un elemento secundario se crea a partir del elemento primario y no se puede crear sin él. Un contenedor primario puede tener varios contenedores secundarios. Sin embargo, un contenedor secundario solo puede tener un contenedor primario. Estas son las consecuencias de la relación primario secundario:
•Si se borra un registro primario, se borran con él todos los registros secundarios
•Al diseñar los formularios podrá incluir los campos de todos los contenedores antecesores
•Las interdependencias de los campos dentro de una jerarquía de enlaces fuertes se crean automáticamente
•Los registros secundarios se pueden editar en los formularios primarios
Enlaces sueltos
Otra relación posible es un enlace que se crea entre dos contenedores interdependientes. Se trata de enlaces sueltos que se crean de forma independiente y sin que hagan referencia unos a otros. Los enlaces se crean manualmente durante la configuración. Por tanto, un único enlace puede tener varios enlaces sueltos que lo vinculan a otros registros. Si hay dos registros vinculados por enlaces sueltos y se borra uno de los registros, esto no afecta al otro.
Se pueden definir enlaces sueltos de varias maneras:
•Defina el campo de un contenedor como de tipo Enlace a. Este campo es el ancla del enlace al otro contenedor.
•Se puede cambiar el vínculo fuerte de los contenedores secundarios con sus respectivos contenedores primarios a enlaces sueltos.
Consulte también el apartado siguiente , Almacenamiento de datos.