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
