Discussion :

[habasque]

salut à tous,

est-ce que quelqu'un pourrait me valider/critiquer le MCD que j'ai mis en pièce jointe ?

les règles sont les suivantes :

1- Un UBM peut être constitué de plusieurs régions

2- Une région est composée de plusieurs cellules

3- Un UBM est constitué de plusieurs cellules

merci d'avance

[fsmrel]

Bonsoir Habasque,

Une région est composée de plusieurs cellules

Ce qui est compatible avec le MCD. Mais, le MCD dit à son tour :

Une cellule est en relation avec plusieurs régions

=> Prenez l'habitude de fournir des règles de gestion complètes.

Cela dit, merci de préciser ce qu'est un UBM, une région, une cellule. Sinon autant remplacer ces termes ambigus par X,Y, Z.

[ypicot]

D'accord avec fsmrel. Le MCD est beaucoup trop vague (il n'y a même aucun attribut), et les règles de gestions trop floues.
Le point formel qui me gêne est la relation UBM - Cellule qui contient un 1 des deux cotés. Je préfère un (0,n), plus souple à l'utilisation.

Yvan

[fsmrel]

Bonjour Habasque, bonjour Yvan,

Le point formel qui me gêne est la relation UBM - Cellule qui contient un 1 des deux cotés. Je préfère un (0,n), plus souple à l'utilisation.

Holà ! On ne dénature pas impunément une règle de gestion (niveau conceptuel) au nom de la facilité de programmation ! (niveau réalisation).

Entre (1,n) et (0,n) il y a une sacrée différence, celle qui existe entre l'ensemble vide et un autre ensemble.

Pour garantir la cardinalité (1,n), on écrit par exemple en Tutorial D, c’est-à-dire en relationnel pur :

CONSTRAINT Rx UBM {UBM_No} = CELLULE {UBM_No} ;

Ce qui se lit : la projection sur la clé primaire UBM_No de la table UBM doit être égale à la projection sur la clé étrangère UBM_No de la table CELLULE (en supposant que l'attribut UBM_No soit clé primaire de UBM).

Et quand on créée un UBM (toujours en Tutorial D), on crée en même temps une cellule :

INSERT UBM RELATION {TUPLE {UBM_No ubmno, ...}},
INSERT CELLULE RELATION {TUPLE {Cellule_No cellno, ... , UBM_No ubmno, ...} ;

Les deux INSERT sont séparés par une virgule, ce qui signifie qu’ils font partie d’un même paquet et que la règle Rx ne pourra être déclenchée qu’en fin de paquet (en l’occurrence marqué par un point-virgule).
Il n’y a rien de bien compliqué.

Je reconnais qu’avec le Monstre (ou Sorry Query Language, comme vous préférez) les choses ne sont pas aussi simples. Au niveau du Standard (disons SQL:1999), il faut définir une assertion assez simple en soi, mais dont on doit prévoir le déclenchement seulement après exécution du 2e Insert (à l'aide d'une instruction Set Constraint) ou en fin de transaction, ce qui n’est pas très « souple d’utilisation » pour reprendre l’expression citée.

Quant aux SGBD du marché, il n’est pas sûr qu’ils permettent une réalisation de la contrainte. Mais ça n’est pour autant qu’il faille la dénaturer au niveau conceptuel...

[ypicot]

Holà ! On ne dénature pas impunément une règle de gestion (niveau conceptuel) au nom de la facilité de programmation ! (niveau réalisation).

Ca, c'est ce qui s'appelle se faire renvoyer dans les cordes
Merci pour cette petite piqure de rappel, c'est toujours salutaire.

Conceptuellement,

Yvan

[fsmrel]

Bonjour Yvan,

Pardonnez-moi si j'ai été un peu sévère, mais qui aime bien châtie bien (et croyez-moi, je ne suis pas à mon tour à l'abri d'un revers décroisé...)

Que celui qui vous voudrait vous accuser d'être pêcheur nous balance la première pierre...

En attendant, j'apprécie l'élégance de votre réponse.

Amicalement,

Fsmrel

[habasque]

Bonjour à tous et merci pour vos remarques,

En pièce jointe un schéma expliquant les notions présentées dans mon premier message.
Il s'agit du scan d'une tranche des fonds marins effectuées par un bâteau sur une distance et une période donnée.
L'ensemble de la zone sondée correspond à UBM, region correspond à un banc de poissons, celda à une portion bien définie de l'UBM.

Je pense que ces informations suffisent pour la compréhension de mon problème. Je n'ai pas ajouté d'attributs sur le schéma afin de le simplifier au maximum. Il est vrai que j'aurais pu au moins y mettre les identifiants !

Avec le schéma fournit, pouvez-vous alors y voir plus clair et me faire part de vos remarques ?

Merci d'avance.

[fsmrel]

Bonjour Habasque,

Concernant la modélisation traditionnelle

Pour les identifiants, on part du principe que l’UBM a pour identifiant un attribut artificiel, du genre Ubm_Id. Les autres attributs (attributs naturels) sont donc ceux qui sont intéressants.

Maintenant, une cellule n’a pas d’existence autonome : elle n’est qu’une propriété multivaluée de l’UBM, son identifiant est donc celui de l’UBM, plus un attribut permettant de distinguer une cellule d’une autre dans l’UBM.

Utilisation de coordonnées cartésiennes

Ce que je viens d’écrire peut faire l’objet d'un aménagement. Pour chaque UBM, vous avez N fois M cellules, 15 fois 15 = 225 cellules dans l’exemple, toutes identiques. Peut-être pourriez-vous envisager de définir ces cellules uniquement à partir des coordonnées cartésiennes de l’UBM (x1 = abscisse du côté gauche de l’UBM par rapport à l’origine, x2 = abscisse de son côté droit, y1 et y2 étant les ordonnées). Ainsi, au lieu de décrire 225 (ou mille) cellules, on n’en décrirait systématiquement que 4. (Une entité Cellule est-elle alors justifiée ?)

Vous pourriez appliquer le principe des coordonnées cartésiennes à chaque région de l’UBM où l’on trouve les petits poissons.
Évidemment, il faut contrôler qu’un banc est bien situé dans un UBM donné, que deux bancs ne se mélangent pas dans un UBM, que deux UBM ne se recouvrent pas, etc.

D’après le dessin, vous prenez manifestement l’aspect temporel : s’agit-il de la situation de l’UBM à un instant donné ?

Question :

Pourquoi avoir associé une cellule à plusieurs régions ? 2 bancs peuvent à un instant donné partager une cellule ?

[habasque]

Bonjour fsmrel,

Si je vous comprends bien d'un point de vue modélisation, mon MCD est correct ? il suffit simplement de rajouter un identifiant pour chaque table ?

Quant à l'utilisation des coordonnées cartésiennes, ce n'est pas faisable car la table Cellule contiendra un champ "Quantité sondée", un champ "latitude", un champ "longitude", "profondeur". Il faut bien décrire l'ensemble des cellules. Par ailleurs, pour le moment je ne suis pas certain que le nombre de 255 cellules soit fixe.

Concernant l'aspect temporel présenté sur le schéma, il s'agit de l'avancée du bâteau au cours du temps. Par exemple, la colonne de gauche peut représenter le scan des 10 premières secondes.

Enfin pour répondre à votre question, une cellule peut correspondre à plusieurs régions car 2 bancs peuvent à un instant donné partager une même cellule.

Peux t-on alors valider le schéma qui est en pièce jointe ?

[ypicot]

Bonjour,

La première chose qui me gène est le codage en dur des poissons. Que se passe-t-il si, lors d'une évolution de l'appli, il faut aussi tenir compte des maquereaux ?

Par ailleurs, il y a redondance entre les différentes quantités de poisson. La qté "ubm" peut être recalculée à partir de la somme des qté "région" et/ou "cellule".

De plus, si une cellule dénombre la population de plusieurs bancs, comment savoir ce qui appatient à tel ou tel banc ? (ou bien on s'en moque et le ratio entre bancs n'a pas d'importance)

Maintenant, une question plus orientée métier : quel est le contexte d'utilisation ? et notamment, si on est sur un système situé à bord du bateau, quelle est la source des données ? Est-ce le nombre de poisson dans chaque cellule ? Dans ce cas, il faudrait pouvoir enregistrer les données venant du capteur. Y a-t-il des contraintes de volume des données ? Comment seront exploitées les données ?

Toutes ces questions peuvent modifier de façon assez profonde le modèle de la base de données.

Donc, pour résumer, sur l'aspect formel :
- il me semble qu'il y a redondance d'information
- le codage en dur des espèces me gêne
sur l'aspect métier :
- il faudrait en savoir beaucoup plus sur le contexte

Merisement,

Yvan

[fsmrel]

Bonsoir Habasque,

Le Yvan est un coriace, il ne laisse rien passer, mais ses remarques sont tout à fait pertinentes. Il vaut mieux que ce genre d’observations soient faites avant la mise en œuvre du système, après ça risque de faire très mal si elles s’avèrent tout ou partie justifiées.

Permettez-moi encore d’en rajouter un peu...

1) Identification des cellules.

Question : une cellule est-elle une entité autonome ou seulement une propriété de l’UBM ? Autrement dit, est-il sensé d’affirmer qu’une cellule n’a pas d’existence propre et qu’elle ne peut pas non plus changer UBM ? Dans l’affirmative, la cellule est une propriété de l’UBM et son identifiant est logiquement celui de l’UBM. Pour éviter les doublons, l’identifiant de la cellule est composé du couple {UBM_Id, Cellule_Id}, dans lequel Cellule_Id est relatif : démarre à 1 pour chaque UBM (identification relative) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
UBM_Id      Cellule_Id 
 ubm1           1
 ubm1           2
 ...           ...
 ubm1          n1
 ubm2           1
 ubm2           2
 ...           ...
 ubm2          n2

2) Relation Appartient (entre UBM et Région)

Une région est en relation avec un seul UBM. Par ailleurs, par la relation EstConstituéeDe, on sait déterminer l’ensemble des cellules de cette région : comme on sait aussi retrouver l’UBM de cet ensemble de cellules, soit par le biais de la relation EstComposéeDe, soit directement au niveau Cellule si on utilise l’identification relative, la relation Appartient est quelque part redondante et pourrait disparaître. Évidemment, (dans tous les cas de figures) il faut s’assurer par une contrainte portant essentiellement sur la relation EstConstituéeDe que les cellules référencées par une région appartiennent bien toutes à la même UBM.

Allez Habasque, courage ! (C’est en forgeant que l’on devient forgeron et c’est en sciant que Léonard devint ...)

Fsmrel