Discussion :

[JohnSly]

Bonjour à tous !

J'ai un souci concernant la conception de ma base de données.
Je dois créer une relation entre deux employés pour former un binôme.

J'hésite entre :

=> Une table EMPLOYE et une table BINOME.
Dans la table BINOME, deux champs en référence à un id de la table EMPLOYE

=> Une table EMPLOYE1 et une table EMPLOYE2
Dans ces deux tables, un champ faisant référence à l'autre table.

La deuxième solution me parait moche à souhait mais dans la première solution, je ne vois pas trop comment faire pour pouvoir supprimer les deux employés, si le binôme est supprimé. (trigger ?)

Je ne demande pas qu'on me mâche le boulot, mais si vous avez quelques conseils sur la meilleure solution à adopter.

Merci d'avance.

[seabs]

Bonjour,

Je pense que ton message serait mieux placé dans le forum ALM section Modélisation Schéma.

Dans ton cas, la mise en place d'une association réflexive doit convenir. Cette approche te donnera deux tables, solution proche te ta première option. En tout état de cause, la solution 2 est à proscrire car tu auras deux tables avec les mêmes employés, c'est le début des difficultés ( Comme tu le dis Insertion, Modification et suppression vont devenir compliquées).

Pour aller plus loin, il faudrait savoir si un employé ne peut participer qu'à un seul binôme ou faire l'objet de plusieurs associations. Exemple : Binôme le matin avec Durand et binôme l'après-midi avec Dupont. Par contre, le matin, il lui sera impossible d'être avec Tartampion.

Par ce simple exemple, tu vois qu'il faut définir clairement les règles de gestion pour obtenir en retour une réponse satisfaisante.

A+

[JohnSly]

Merci pour cette rapide réponse !

J'ai bien cette asso réflexive dans mon SCD. Si j'ai bien compris, les règles de gestion sont à définir coté php pour ajouter modifier supprimer en conséquence.

Je suis peut être trop pointilleux concernant l’intégrité des données dans la BDD.

Merci encore!!

[CinePhil]

Je suis peut être trop pointilleux concernant l’intégrité des données dans la BDD.

On ne l'est jamais assez !

Un truc qui me chiffonne :

je ne vois pas trop comment faire pour pouvoir supprimer les deux employés, si le binôme est supprimé.

Cela veut dire que tout employé figurant dans un binöme ne peut pas exister en tant qu'individu et s'associer plus tard à un autre employé pour former un nouveau binöme ?

Bizarre comme gestion !

À moins que ton cas réel ne concerne pas des employés mais des entités qui ne vont effectivement que par deux ?

Selon moi...

Règle de gestion :
Un employé peut participer à un binôme et un binôme est former de deux employés.

MCD :
employe -0,1----former----(2,2)- binôme

Nota :
- J'ai supposé ici qu'on ne garde pas en mémoire les binômes supprimés et que donc chaque employé ne peut figurer qu'une seule fois dans un binôme.
- les cardinalités entre parenthèses signifient une identification relative du binôme par rapport aux employés.

Tables :
te_employe_emp (emp_id, emp_nom...)
te_binome_bnm (bnm_id_employe1, bnm_id_employe2...)

Nota :
- Il faudrait aussi matérialiser une contrainte pour empêcher un employé d'être une fois référencé en tant qu'employé 1 et une autre en tant qu'employé 2. Cette contrainte s e traduit par une contrainte CHECK en BDD. Si vous utilisez le mauvais MySQL ou tout autre mauvais SGBD ne connaissant pas les contraintes CHECK, il faudra recourir à un trigger.

[JohnSly]

Bizarre en effet !

Une fois qu'un employé est retiré de la base, le binôme doit l'être aussi ainsi que l'autre employé.

Vous avez parfaitement cerné le sujet.

Je travail sous MySQL avec une base de type InnoDB donc pour le CHECK c'est bon.

Je n'avais jamais compris comment traduire des cardinalités comme (2,2). J'ai répondu à mes questions grâce à vos message ainsi qu'à ce sujet

Je me coucherais moins bête et un grand merci pour cette solution !!

[CinePhil]

Bizarre en effet !

Une fois qu'un employé est retiré de la base, le binôme doit l'être aussi ainsi que l'autre employé.

Fais-toi quand même confirmer cette règle de gestion !

Je travail sous MySQL avec une base de type InnoDB donc pour le CHECK c'est bon.

Pas du tout !
La syntaxe CHECK est acceptée mais elle est sans effet car MySQL n'a toujours pas implémenté cette contrainte.

La doc française de MySQL dit ceci :

En MySQL version 3.23.44 et plus récent, les tables InnoDB supportent la vérification de clé étrangères.
...
Pour les autres types de tables, le serveur MySQL n'analyse pas les clauses FOREIGN KEY, CHECK et REFERENCES dans les commandes CREATE TABLE, et aucune action n'est réalisée.

Ceci laisse à penser en effet que la contrainte CHECK est prise en compte par le moteur InnoDB mais la doc originale en anglais dit autre chose :

InnoDB tables support checking of foreign key constraints.
...
For other storage engines, MySQL Server parses and ignores the FOREIGN KEY and REFERENCES syntax in CREATE TABLE statements. The CHECK clause is parsed but ignored by all storage engines.

Bref, mauvaise traduction française de la doc du mauvais SGBD MySQL !

Petit test...

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE test_check
(
	numero INTEGER NOT NULL
	CHECK (numero > 10)
) ENGINE=InnoDB;
 
INSERT INTO test_check
VALUES (1);

=> 1 ligne insérée. ( Traitement en 0.0215 sec )

Code SQL :

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

1
2
SELECT numero
FROM test_check

=> 1

Code SQL :

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

SHOW CREATE TABLE test_check

=>

Code SQL :

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

CREATE TABLE `test_check` (  `numero` int(11) NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=latin1

=> La contrainte n'est même plus là !

[JohnSly]

Je pense que je vais tout de même sauvegarder les infos dans une autre table. Ils ne se rendent pas compte... (startup )

C'est un peu bête de la part de MySQL d'avoir accepté la syntaxe CHECK et de ne pas la prendre en compte ...

C'est parti pour les triggers donc !

Par contre, (HS total je sais) j'ai encore du mal à voir la limite où s'arrête les traitements coté BDD. Dans votre exemple, en quoi le CHECK (dans un autre SGBD of course) est-il préférable à une vérification en php ? Je pense au temps d’exécution mais je ne m'explique pas pourquoi.

En deux ans, les profs du BTS n'ont pas pu me répondre clairement...

[CinePhil]

Si tu as une seule application qui accède à la BDD et si tu ne vas jamais alimenter la BDD autrement que par l'application et si tu es sûr de ton code applicatif, alors tu peux programmer les contrôles de cohérence des données dans l'application.

Mais, d'une manière générale, la cohérence des données est du ressort du SGBD car, si une des conditions ci-dessus n'est pas respectée, ça peut foutre le bordel dans les données, des incohérences, des données mortes, fausses, inexploitables, un résultat de requête, notamment de comptage ou de calcul, complètement faux alors que la requête est juste...

Dans l'exemple que j'ai donner pour tester l'utilisation du CHECK par MySQL, la contrainte était très simple et portait directement sur la colonne de la table mais d'autres contraintes peuvent être plus complexes et dépendre du résultat d'une requête sur une ou plusieurs autres tables. Par exemple, vérifier qu'en mettant à jour une donnée on n'obtient pas un nombre de lignes répondant à une condition trop grand ou trop petit dans une autre table. Les contraintes complexes développées dans l'application nécessitent une à plusieurs requêtes supplémentaires avec un aller retour entre l'application et le SGBD et un traitement sur le résultat de la requête. C'est beaucoup plus long que de faire ça dans une contrainte CHECK d'une table.

Le seul inconvénient est que au cas où la contrainte est violée, le SGBD renvoie une erreur qu'il faut interpréter et gérer dans le code applicatif alors que c'est peut-être un formulaire entier qui a été envoyé au SGBD.

L'avantage aussi des contraintes en BDD est que les contraintes applicatives peuvent être différentes pour deux applications qui utilisent la même base de données. On peut ainsi gérer les contraintes applicatives dans l'application et laisser les contraintes sur les données dans le SGBD. Par exemple, le SGBD contrôlera qu'une date de décès ne soit pas inférieure à la date de naissance mais l'application qui gère le service de gériatrie vérifiera que la date de naissance donne par exemple un âge d'au moins 70 ans alors que l'application qui gère les naissances à la maternité vérifiera que la date de naissance est d'au plus une semaine par rapport à la date du jour et l'application qui gère le personnel vérifiera qu'on n'enregistre pas un nouvel employé de moins de 16 ans. Les trois applications pourront cependant utiliser la même table des personnes.

On peut aussi aller plus loin et, comme le recommande SQLPro, adopter le principe du développement en bases de données épaisses en confiant un maximum de la gestion des données au SGBD, grâce à l'appel par l'application de procédures stockées au lieu qu'elle soumette des requêtes au SGBD.

[JohnSly]

Que dire à part MERCI !

Enfin une réponse claire et concise.

Mes profs et mes maîtres de stages sont des amateurs à coté !