Discussion :

[Freedolphin]

Bonjour à tous,

Tout d'abord, j'ai hésité à choisir cette rubrique, car ma question pourrait aussi se trouver dans la section "Développement", mais bon.
Voici mon projet : créer un planning de disponibilités de bénévoles, chaque jour de l'année, par tranches dans la journée (matin, après-midi, soir).
La table des bénévoles sera classique (id du bénévole, nom, téléphone etc.).
Je ne sais pas bien comment appréhender la chose et j'aimerais avoir quelques idées. Je ne demande pas du tout à ce qu'on me fasse le job ! Mais quelques pistes seraient les bienvenues.
Faut-il créer une table par jour, avec l'id des bénévoles sur chaque tranche ? Ou une table par mois ? Comment voyez-vous cela ?

Je partirais bien sur une table contenant tous les jours de l'années, avec pour chaque ligne le jour et les 3 tranches, lesquelles seraient remplies par les id bénévoles, séparés par une virgule, pour traiter ensuite les données avec un formulaire et des cases à cocher.

Merci d'avance pour vos idées !

[CinePhil]

Bonjour,

Voici mon projet : créer un planning de disponibilités de bénévoles, chaque jour de l'année, par tranches dans la journée (matin, après-midi, soir).

Je suppose qu'il s'agit de jours calendaires ? C'est à dire que si le bénévole Dupont est disponible le 2 janvier 2024 après-midi, il ne le sera peut-être pas le 2 janvier 2025. Comment pourrait-il d'ailleurs le savoir 1 an à l'avance ?

Donc oui, il va falloir gérer un calendrier.

1ère chose à faire : écrire les règles de gestion des données.

Par exemple :
R1 : Un bénévole peut-être disponible lors d'une période et une période peut voir la disponibilité de plusieurs bénévoles.

De cette règle de gestion, on déduit le morceau de MCD suivant :
Benevole -0,n----est_disponible----0,n- Periode

Et de ce morceau de MCD, on peut déduire les tables suivantes :
te_benevole_ben (ben_id, ben_nom, ben_prenom, ben_telephone...)
te_periode_per (per_id, per_date, per_creneau)
tj_ben_disponible_per_bdp (bdp_id_benevole, bdp_id_periode)

Lors de la création de la BDD, il sera utile de créer par procédure SQL le calendrier des périodes.

[Freedolphin]

C'est exactement ça, merci pour ces pistes.
J'ai effectivement opté (entre autres) pour une table Bénévoles et une table Disponibilités, avec 1 jour par entrée, chaque jour ayant les id des bénévoles dispos séparés par une virgule, facile à afficher ensuite.

[escartefigue]

J'ai effectivement opté (entre autres) pour une table Bénévoles et une table Disponibilités, avec 1 jour par entrée, chaque jour ayant les id des bénévoles dispos séparés par une virgule, facile à afficher ensuite.

Il ne faut JAMAIS stocker une liste de valeurs dans une même colonne d'une même ligne !
C'est un viol de première forme normale qui compromet l'intégrité de la base de données, rend les requêtes comples, les performances désastreuses, la fiabilité également... Bref tout ce qu'il ne faut pas faire.

Ce n'est pas pour rien que Cinephil propose une table de jointure, c'est bien pour avoir une ligne pour chaque combinaison de personne et de période.
C'est la SEULE modélisation correcte dans votre contexte.

Pour l'affichage, il suffira de concaténer les différentes valeurs lues en table, rien de plus simple par SQL, en fonction du SGBD, vous utiliserez STRING_AGG(), GROUP_CONCAT ou autre

[Freedolphin]

C'est marrant, mais plus on me dit de ne pas faire un truc, plus j'ai envie de le faire.
Sérieusement, merci pour ces conseils, mais la modélisation plus élaborée que vous proposez est trop complexe pour moi et cette petite appli est réservée à deux ou trois utilisateurs, sur un site privé.
D'autant que je ne vois pas bien où est le danger, ce n'est qu'un champ texte contenant des "12,34,27" ou "8,17,23,24"...

[escartefigue]

Par exemple, comment savoir qui est affecté à la période 2

Avec votre méthode, pour le savoir parcourir le contenu "12,34,27", trouver les délimiteurs (les virgules), tenir compte que le chiffre "2" n'est pas la même chose que le nombre 2 etc...
Ensuite, il est impossible de faire une jointure directement entre une sous partie d'une chaine de caractères et l'identifiant de la période sans opérer une fonction, ça signifie qu'aucun index ne sera éligible et que donc les perfs seront très dégradées.
Enfin et surtout, rien ne vous interdira de créer des périodes qui n'existent pas, de créer plusieurs fois la même période dans la liste pour une même personne, etc. Bref de stocker n'importe quoi

Ce sont les fondamentaux de la modélisation d'une base de données. La modélisation que Cinéphil et moi-même proposons est très simple et évite tous ces écueils.

Parcourez l'article sur les formes normales de Wikipédia (en particulier la 1ère d'entre elles puisque c'est de celle-là qu'il s'agit ici)

[Freedolphin]

> créer des périodes qui n'existent pas : impossible, l'utilisateur a des dates proposées par un calendrier datepicker
> créer plusieurs fois la même période : impossible, une étape vérifie l'existence de la journée et renvoie une erreur si celle-ci est déjà créée

Mais je prends note de vos conseils pour améliorer mon système.

[fsmrel]

Bonjour,

Il ne faut JAMAIS stocker une liste de valeurs dans une même colonne d'une même ligne !
C'est un viol de première forme normale qui compromet l'intégrité de la base de données, rend les requêtes comple(xe)s, les performances désastreuses, la fiabilité également... Bref tout ce qu'il ne faut pas faire.

Capitaine, tu as parfaitement raison, à ceci près que si la liste de valeurs est du type qui convient (encapsulée dans du varchar par exemple), alors stricto sensu la 1NF est respectée. 

Je rappelle ce que dit le Maître (Chris Date) à ce sujet dans Database Design and Relational Theory, Second Edition)  (page 66) :

Definition (first normal form): Let relation r have attributes A1, ..., An of types T1, ..., Tn, respectively. Then r is in first normal form (1NF) if and only if, for all tuples t appearing in r, the value of attribute Ai in t is of type Ti.

To say it in different words, 1NF just means that each tuple in the relation in question contains exactly one value, of the appropriate type, for each attribute. Observe in particular, therefore, that 1NF places absolutely no limitation on what those attribute types are allowed to be. They can even be relation types! That is, relations with relation valued attributes─RVAs for short─are legal (you might be surprised to hear this, but it’s true). An example is given in Figure 4-1 below.

Et il ajoute (page 67) :

Normalized and first normal form mean exactly the same thing─all normalized relations are in 1NF, all 1NF relations are normalized. The reason for this slightly strange state of affairs is that normalized was the original (historical) term; the term 1NF wasn’t introduced until people started talking about 2NF and higher levels of normalization, when a term was needed to describe relations that weren’t in one of those higher normal forms.

Capitaine, tu sais que le nombre de définitions folkloriques est particulièrement élevé.

Par exemple, et pour la petite histoire, à la page 167 de son ouvrage, Chris Date écrit :

... a colleague recently drew my intention to the following excerpt from one of IBM’s reference manuals for its DBMS product DB2:

First normal form: A relational entity satisfies the requirement of first normal form if every instance of an entity contains only one value, never multiple repeating attributes. Repeating attributes, often called a repeating group, are different attributes that are inherently the same. In an entity that satisfies the requirement of first normal form, each attribute is independent and unique in its meaning and its name.

Example: Assume that an entity contains the following attributes:

EMPLOYEE_NUMBER
JANUARY_SALARY_AMOUNT
FEBRUARY_SALARY_AMOUNT
MARCH_SALARY_AMOUNT

This situation violates the requirement of first normal form, because JANUARY_SALARY_AMOUNT, FEBRUARY_SALARY_AMOUNT, and MARCH_SALARY_AMOUNT are essentially the same attribute, EMPLOYEE MONTHLY_SALARY_AMOUNT.

─DB2 for z/OS Administration Guide IBM Form No SC27-8844-2

Je te laisse deviner quel est le collègue qui attira l’attention de Chris...

Paradoxalement, n’en déplaise à IBM, sa table (appelons-la EMPLOYEE) respecte la cinquième forme normale ! En effet, cette table a pour seule clé candidate {EMPLOYEE_NUMBER}, et chaque dépendance de jointure à laquelle elle satisfait est une conséquence de cette clé.

Fermez le ban.

[escartefigue]

Bonjour,

@François :
Dans le cas présent, la discussion porte non pas sur la modélisation conceptuelle, mais sur le niveau tabulaire, or, ce que propose Freedolphin, c'est de stocker une liste d'identifiants de périodes séparés par des virgules dans un unique attribut.
En d'autres termes une liste de foreign keys.

Ce faisant on a bel et bien un viol de 1NF si on tente de reconstituer un MCD à partir de ce modèle tabulaire.


@Freedolphin, à propos de ceci :

> créer des périodes qui n'existent pas : impossible, l'utilisateur a des dates proposées par un calendrier datepicker
> créer plusieurs fois la même période : impossible, une étape vérifie l'existence de la journée et renvoie une erreur si celle-ci est déjà créée

Mais je prends note de vos conseils pour améliorer mon système.

Ce que vous croyez impossible l'est tout à fait, une base de données n'est pas une application mono tache ni mono utilisateur, les ressources sont partagées et le multi-threading est chose courante.
Dans ce contexte, seul le moteur de la base de données peut garantir l'intégrité, l'application ne peut pas le faire.

[Freedolphin]

Oui, bien sûr, si l'on se met dans la peau d'un hacker à capuche décidé à détruire le monde, mais dans le cas d'une utilisation par trois bénévoles inexpérimentés, l'appli est conçue pour éviter les erreurs.

@François : bon, là, tu m'as perdu. Je vous laisse régler votre désaccord en MP

[CinePhil]

Il est quand même curieux que vous veniez chercher ici des conseils ; que vous appréciiez de les avoirs reçus et que finalement vous décidiez de ne pas en tenir compte !

Tel que vous allez finalement faire, vous n'avez même pas besoin d'une base de données ! Mais je ne veux pas être celui qui viendra réparer votre outil quand il sera planté ou donnera des résultats faux... parce qu'il faudra tout refaire. À moins que vous payiez bien...

Bonne continuation quand même !

[Freedolphin]

Je vous l'accorde, je suis allé un peu vite à demander des conseils et j'ai rapidement avancé sur ce projet, avant la première réponse.
Cela étant, je n'ai jamais dit que je ne tiendrai pas compte des conseils, bien au contraire, j'ai bien compris le message sur la jointure et le garde dans un coin de ma tête.
Mais si tel un magicien, vous savez proposer une appli sur internet sans base de données, je vous laisse écrire un livre sur le sujet qui se vendra comme des petits pains.
Et non, ça ne paie pas bien, c'est un projet bénévole pour une association caritative.
Merci toutefois pour vos bons présages qui font chaud au cœur en ce début d'année.

[fsmrel]

Bonsoir,

Dans le cas présent, la discussion porte non pas sur la modélisation conceptuelle, mais sur le niveau tabulaire, or, ce que propose Freedolphin, c'est de stocker une liste d'identifiants de périodes séparés par des virgules dans un unique attribut.
En d'autres termes une liste de foreign keys.

Ce faisant on a bel et bien un viol de 1NF si on tente de reconstituer un MCD à partir de ce modèle tabulaire.

Capitaine,

Reprenons la définition de ChrisDate :

Definition (first normal form): Let relation r have attributes A1, ..., An of types T1, ..., Tn, respectively. Then r is in first normal form (1NF) if and only if, for all tuples t appearing in r, the value of attribute Ai in t is of type Ti.

To say it in different words, 1NF just means that each tuple in the relation in question contains exactly one value, of the appropriate type, for each attribute. Observe in particular, therefore, that 1NF places absolutely no limitation on what those attribute types are allowed to be.

Quand tu écris :
 
« ce que propose Freedolphin, c'est de stocker une liste d'identifiants de périodes séparés par des virgules dans un unique attribut »
 
Eh bien, foin du niveau, conceptuel ou tabulaire, l’attribut en question est manifestement du type VARCHAR. Selon la définition canonique ci-dessus la 1NF est respectée.
 
Bien qu’il soit calamiteux d’encapsuler une liste d’éléments — fussent-ils des plus complexes — pour constituer une valeur de ce type ne provoque en rien un viol 1NF.