You can see cardinality as the size of the array that contains objects. For
your examples:

1) The summed max-"occurrences" may never surpass the max-"cardinality"
They might, specially as things like occurrences of 0..* or 1..* are a
thing. Nothing wrong with having a cardinality that further constraints
that.

2) the summed min-"occurrences" may never be less than the
min-"cardinality"
They also might, even if all your objects are optional (i.e. 0..1) you
could have a cardinality of [1..*] to say that you need at least one.

However, I would say that in normal cases you could just sum them and be
fine, but this duality allows for some cool tricks at validation time

Regards

El vie., 11 oct. 2019 a las 9:29, Georg Fette (<georg.fe...@uni-wuerzburg.de>)
escribió:

> Hello,
> Constrained Container RM-Types can define a "cardinality" for their
> list/array fields and the contained types can define "occurrences" for
> themselves inside the array.
> The summed max-"occurrences" may never surpass the max-"cardinality and
> the summed min-"occurrences" may never be less than the min-"cardinality".
> The min-max-"occurrences" could perhaps even be calculated from the
> "occurrences".
> What information gain does the "cardinality" provide ?
> Or what is the usecase where a given "cardinality" is needed, because
> the information is not already given by the all "occurrences" ?
> Greetings
> Georg
>
> --
> ---------------------------------------------------------------------
> Dipl.-Inf. Georg Fette      Raum: B001
> Universität Würzburg        Tel.: +49-(0)931-31-85516
> Am Hubland                  Fax.: +49-(0)931-31-86732
> 97074 Würzburg              mail: georg.fe...@uni-wuerzburg.de
> ---------------------------------------------------------------------
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] <https://htmlsig.com/t/000001C268PZ>

[image: Twitter]  <https://htmlsig.com/t/000001C47QQH> [image: LinkedIn]
<https://htmlsig.com/t/000001C4DPJG> [image: Maps]
<https://htmlsig.com/t/000001BZTWS7>

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to