Discussion :

[escartefigue]

Bonjour

Tout attribut d'une entité-type doit être en dépendance fonctionnelle directe de son identifiant.
Or,

• le nom du poulailler dépend de l'ET "POULAILLER" et non de l'ET "POULE"
• le nombre de décès n'est pas une valeur à stocker, mais à calculer, sauf s'il s'agit d'une valeur à une date précise (inventaire par exemple)
• le stock restant (stock de quoi ?) n'est pas non plus dépendant de l'identifiant de la poule

Il en va de même pour les attributs de l'entité-type OEUFS

Les cardinalités sont erronées un oeuf ne peut être pondu que par une et une seule poule, vous devriez donc modéliser
OEUF 1,1 --- Pondre --- 0,n POULE

Le nom du poulailler n'a rien à faire dans la relation "NOURRIT"

Une société qui contient zéro poulaillers, pourquoi pas (nouvelle société en cours de création) par contre, je pense que tout poulailler doit appartenir à une société, donc mini UN

Concernant la nomenclature

• utilisez des singuliers sans article pour les entité-types : "SOCIETE" plutôt que "LA SOCIETE", "POULE" plutôt que "POULES" etc...
• utilisez des verbes à l'infinitif pour les relations : "PONDRE" au lieu de "AYANT PONDU" , "CONTENIR" à la place de "QUI CONTIENNENT"

Concernant la nourriture donnée aux poules, est elle gérée individuellement par poule (mesure faite pour chaque poule) ou par poulailler comme je le suppose.
Vous avez modélisé par poule, il me semble que seuls les grands animaux (vaches par exemple) ont une alimentation mesurée individuellement.
A confirmer

[Super2016]

Bonjour escartefigue :

Merci pour ta réponse; je me suis inspiré de tes remarques et voici un nouveau MCD :



Dans ce MCD , l'attribut date est unique : chaque jour , le responsable :

donne la médication, fait l'inventaire, comptabilise les décès et donner la nourriture.

L'unité prise en compte est le nombre total de poule / Poulailler : stock total de poules / Poulailler.

CDT.

[escartefigue]

Bonjour,

Comme je le mentionnais dans ma réponse précédente, vous devez toujours vérifier que l'identifiant d'une ENTITE-TYPE permet de connaitre à coup sur l'occurrence de cette entité-type
Or comment l'identifiant d'un oeuf peut il permettre de connaitre un nombre d'oeufs ?
Un nombre d'oeufs n'a de sens que dans un lieu (tel poulailler ou tel ensemble de poulaillers) et à un instant "t"
Comme déjà indiqué, les valeurs calculées ne doivent jamais être stockées (nombre d'oeufs, nombre de poules, etc....) sauf s'il s'agit d'une valeur à une date particulière : date d'arrêté, date d'inventaire, date de clôture etc...
Auquel cas il faut stocker ce nombre et la date correspondante

Concernant la relation "Pondre", un stock ne pond pas :aie: , c'est une poule qui pond effectivement à date, la bonne relation est donc par exemple
POULE (id, nom, date d'entrée, date décès....) 0,n --- Pondre (nombre d'oeufs) --- 1,1 CALENDRIER (date)

Avant de vous lancer dans la modélisation, je vous recommande de consulter l'ouvrage "Parlez vous Merise" de Michel Diviné, ouvrage gratuit que vous pourrez télécharger ici :
http://michel-divine.developpez.com/

[HAMIDOU AMERI]

Salam, Bonjour

Merci encore une fois pour le MCD (Mr Sammy)
Merci encore une fois pour le Lien (Mr Escartefigue)
je propose ce schema, mais j'ai pa pu faire les relations , j'ai fait des bulle pour montre les relations

merci enco une fois

[Super2016]

Ben faut faire 35000 insert dans la table "poule".

Une autre solution est de gérer les poules sous forme de stock, avec une ligne par poulailler et par date avec le nombre de nouvelles poules et le nombre de décès sur la journée.

Mais niveau traçabilité il peut être préférable de savoir descendre à la poule si on sait les identifier (bague, numéro de box, etc.)

Bonsoir escartefigue :

Ci - dessus la réponse de StringBuilder :

L'idéal serait de modéliser à l'unité. Mais dans le cas pratique de HAMIDOU AMERI , il est en face de 35 000 Poules réparties sur les 6 Poulailler : ~ 5 800 poules/Poulailler .

Personnellement, je ne vois pas comment on peut les identifier.

Votre réponse est trés juste, mais on se trouve devant un problème pratique d'identification.

CDT.

[escartefigue]

il suffit d'utiliser un identifiant technique attribué par la base de données (identity column), qui a le mérite d'être concis, fiable et performant.
Ainsi chaque poule possède un identifiant unique et il n'est pas nécessaire de s'en préoccuper dans l'application.

[Super2016]

Bonjour,

Comme je le mentionnais dans ma réponse précédente, vous devez toujours vérifier que l'identifiant d'une ENTITE-TYPE permet de connaitre à coup sur l'occurrence de cette entité-type
Or comment l'identifiant d'un oeuf peut il permettre de connaitre un nombre d'oeufs ?
Un nombre d'oeufs n'a de sens que dans un lieu (tel poulailler ou tel ensemble de poulaillers) et à un instant "t"
Comme déjà indiqué, les valeurs calculées ne doivent jamais être stockées (nombre d'oeufs, nombre de poules, etc....) sauf s'il s'agit d'une valeur à une date particulière : date d'arrêté, date d'inventaire, date de clôture etc...
Auquel cas il faut stocker ce nombre et la date correspondante

Concernant la relation "Pondre", un stock ne pond pas , c'est une poule qui pond effectivement à date, la bonne relation est donc par exemple
POULE (id, nom, date d'entrée, date décès....) 0,n --- Pondre (nombre d'oeufs) --- 1,1 CALENDRIER (date)

Avant de vous lancer dans la modélisation, je vous recommande de consulter l'ouvrage "Parlez vous Merise" de Michel Diviné, ouvrage gratuit que vous pourrez télécharger ici :
http://michel-divine.developpez.com/

Bonjour :

Ok identifiant unique technique mais le problème réside dans le moment de la visite : s'il y'a cent poules décédées dans chaque poulailler, on doit dans la table poule (ID, nom , date entrée , date décés..) écrire 100 fois la date du jour !!!!!!!!!!!.
Ton idée est bien mais point de vue pratique ça pose des problèmes pour répertorier les décès .
CDT.

[escartefigue]

Tout SGBD digne de ce nom, dispose de fonction(s) pour récupérer automatiquement la date du jour, donc aucun souci. De plus tous les langages ont également ce type de fonction

Exemple :

Code :

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

1
2
3
UPDATE Ma_Table
SET date_deces = current date
WHERE POULE_ID = 123456

Pour ce qui concerne d'identifier la poule par son ID, je suppose que dans un élevage, il existe un badge pour reconnaitre chaque individu
Si c'est un un code barre, un coup de douchette et hop, le tour est joué

[Super2016]

Bonsoir escartefigue :

Merci de nous avoir donner la piste du code :
UPDATE Ma_Table
SET date_deces = current date
WHERE POULE_ID = 123456

Ce code peut être par exemple inséré dans un bouton qui va activer cette requête mise à jour , on peut même y ajouter une partie pour l’appliquer pour 10 ou 15 ID.

Ma question est : quel code vous proposez pour créer un table de 35 000 ID : CREATE...................... pour la table POULE (id, nom, date d'entrée, date décès....)?.

Comme vous pouvez l'imaginer il est impossible de donner des références et de taper sur une table access 35 000 Entrées : il nous faut trouver un code pour créer cette table automatiquement .


CDT.

[escartefigue]

Le DDL de création d'une table n'est absolument pas impacté par le volume qu'elle doit contenir, c'est strictement le même pour une table d'une seule ligne ou une table de 100 milliards de lignes.
Seule la notion de partitionnement peut intervenir pour les tables fortement volumineuses, mais ce n'est pas votre cas, 35 000 lignes c'est tout petit pour un SGBD

Si vous utilisez un outil de modélisation (Power AMC, DB-Main, JMerise etc...) le DDL sera produit automatiquement lors de la génération du MPD en fonction du choix du SGBD (la syntaxe est différente selon le choix du SGBD et sa version)

Quoi qu'il en soit, vous en êtes au modèle conceptuel, ces considérations sont donc prématurées

[StringBuilder]

Je pense que le souci des 5800 poules par poulailler réside non pas dans la volumétrie, mais dans l'identification (intérêt ?) des poules et la quantité de données à traiter.

En effet, si chaque poule est baguée avec un numéro, alors, et à mon sens ça devrait même être une obligation légale, il faut que chaque poule soit identifiée dans le système.
=> On a ainsi, pour chaque poule sa date de naissance/arrivée dans le poulailler, son nombre d'oeufs pondus, sa quantité de médication (en fonction de sa durée de présence dans le poulailler), etc.

Dans ce cas, quand on trouve 2000 poules mortes un soir de canicule, il faut lire et saisir les 2000 identifiants des poules mortes.
Si on n'a pas un système de RFID ou de code barre sur les bagues, c'est alors impossible à traiter en termes de volume.


Cependant, dans une usine à oeufs avec le broyeur à poussins qui tourne à plein régime, les poules sont inidentifiables (comme des cailloux dans une benne) et à ce moment, effectivement, on a uniquement une gestion au niveau du poulailler (ou du box si les poules sont réparties en box, comme c'est le cas dans un entrepôt).

Donc on n'a plus d'entité poule mais :
- une entité "poulailler" avec NB_FEMELLES, NB_MALES
- une entité "relevé" avec DATE, NB_PONTE, NB_DECES_FEMELLE, NB_DECES_MALE
- une entité "arrivée" avec DATE, NB_FEMELLE, NB_MALE (du moment qu'on ne remplace par les poules mortes au jour le jour, sinon on peut coller ces deux infos dans l'inventaire)

Mais je l'avoue, sans être végan, ça me choque de faire aussi peu de cas des poules.

[Super2016]

Je pense que le souci des 5800 poules par poulailler réside non pas dans la volumétrie, mais dans l'identification (intérêt ?) des poules et la quantité de données à traiter.


Donc on n'a plus d'entité poule mais :
- une entité "poulailler" avec NB_FEMELLES, NB_MALES
- une entité "relevé" avec DATE, NB_PONTE, NB_DECES_FEMELLE, NB_DECES_MALE
- une entité "arrivée" avec DATE, NB_FEMELLE, NB_MALE (du moment qu'on ne remplace par les poules mortes au jour le jour, sinon on peut coller ces deux infos dans l'inventaire)

Bonjour StringBuilder :

Merci de votre réponse ; Votre réponse semble réaliste et réalisable vue la presque impossibilité de saisir tous les cas de décès.
Le point qui pose problème dans ce cas est l’identification des poules;
Une approche par Poulailler semble la plus indiquée.
Il n'y a aucun remplacement: en début d'année on répartit 35 000 Poules et coqs sur 6 Poulailler ; Et la saisie des infos se fait journalièrement ;
Quatre sujets sont traités : 4 Axes :

1. Les décés / Poulailler;
2. La fécondité : nombre d'oufs produits;
3. La Nourriture : quantité de nourriture par jour.
4. La médication: quantité de médicament par jour.

On peut imaginer ce que vous avez dit :

1. une entité "poulailler" avec Nom poulailler, NB_FEMELLES, NB_MALES.
2. une entité "relevé" avec DATE, NB_PONTE, NB_DECES_FEMELLE, NB_DECES_MALE
3. une entité "médicament " avec DATE,Type de Médicament ,Nombre d'Unités .
4. une entité "nourriture" avec DATE , TYPE DE NOURRITURE, Quantité.

NB: Vue qu'on a considéré une entité poulailler, on va considérer les œufs en totalité selon le nombre total / poulailler;
On n'a pas d'entité poule et entité oeuf .
On peut même unifier l'Attribut DATE : Vue qu'au moment de la collecte d'informations : il y'a toutes les saisies .
CDT.

[Super2016]

Bonsoir HAMIDOU AMERI :


Essayes avec les MCD et MLD suivants :



Concernant les calculs , ils devraient se faire par requête et dans les formulaires.


CDT.