Discussion :

[Pierre Fauconnier]

Normalement, l'intégrité référentielle se place avant la saisie du premier enregistrement de la table. En effet, ce mécanisme d'intégrité porte aussi sur les enregistrements existants et il faut donc que ce qui existe respecte l'intégrité. Cela veut dire notamment que les valeurs du champ 1 de la relation 1:n doivent être différentes de NULL.

De plus, pour pouvoir placer l'intégrité, il faut que:

• les champs soient de type et de longueur identiques;
• le champ côté 1 de la relation 1:n soit la clé primaire ou un index unique non null.

[touche_a_tout]

Bonjour,
J'ai pondu mon dernier post avant de lire l'échange mjp/Pierre Fauconnier. Il ne faut pas perdre de vue le but du jeu: tracer (au sens anglais: suivre à la trace) le cheminement de l'évolution du langage musical à travers sa transmission (probable) d'un ou plusieurs compositeur(s) jouant le rôle de maître(s) vers un ou plusieurs autres compositeur(s) jouant le rôle d'élève(s). Leurs dates de vie et leur pays ne jouent pas de rôle dans le phénomène et servent uniquement à parfaire la description des individus-compositeurs en question. La table des relations en est (amha de profane) grandement simplifiée. Je me sens tout petit dans ce dialogue mais je persiste.
Merci d'avance de vos éclaircissements.
Cordialement
Pierre

[Pierre Fauconnier]

Si on crée une table Naissance (ou décès), il faut placer les liaisons et l'intégrité relationnelle de façon correcte, quel que soit l'usage de la table par la suite. C'est pourquoi je simplifierais le modèle en plaçant tous ces champs dans la table Personne, puisque si éclatement entre plusieurs tables, ce sera forcément en relation 1:1 (à moins de naître/mourir plusieurs fois).

Une relation 1:1 est forcément une relation entre une table principale et une table secondaire qui n'en est que l'extension. Si la création d'une relation 1:1 avait un sens lorsque l'on pouvait mettre de la protection sur les bases Access (Versions 2003 et antérieures), sa seule utilité aujourd'hui, avec Access, réside dans le fait de créer des tables "qui ont plus de 255 champs"... Autrement dit, cela ne se rencontre pas tous les jours

[mjpmjp]

bonjour,
merci Pierre ,

Solution 1 car les tables Naissance et Décès sont en fait des extensions de la table des personnes en relation 1:1, en supprimant IDNaissance (clé primaire), en mettant IDPersonne comme clé primaire non autoimplémentée et en liant les IDPersonne. Ca créerait une relation 1:1 et ce serait plus logique qu'une relation 1:n.

je manque d'expériences dans access ,
IDPersonne comme clé primaire non autoimplémentée ... çà veut dire que quand je crée une personne (IDPersonne +1) ,j'écris moi même dans la colonne IDPersonne de TblNaissance ?

dans la solution 2 , on peut "lire" : Pays -> Ville -> Naissance -> Personne -> instance Maitre ...
est ce que c'est un mirage / illusion ?

dans la solution 1 , on s’arrête à Naissance ?

@+JP

[Invité]

Bonjour,

personnellement j'opterais pour une table compositeurs vue qu'il est question de compositeurs (subtilité pas importante) même si ce sont des personne au même titre que les créateurs sont de personnes (compositeur).

un compositeur peut tour à tour être un élevés un Maître, disposer de plusieurs langage etc...

un Maître dispose d'élèves et un élève à un maître donc un compositeur qui dispose de compositeurs comme élève est forcément un maître. c'est pour cela que je fais une liaison entre un compositeur et ses élèves compositeurs également.

pas besoin d'avoir une table date pour les naissances et le décès il compositeur est né (et mort) et des champs date suffisent à matérialiser cet éventement dans la fiche d'état civil du compositeur.

1. table compositeurs
   
   1. iD Compositeur
   2. champs état civile
   3. lien table [compositeur] et [Lien langage]
   4. lien Table [Compositeur] et [Lien compositeur élevés]
   
   
2. table langage
   
   1. Id
   2. champs information Langage
   
   
3. table [lien compositeurs langage]
   
   1. Id Compositeur
   2. Id langage
   
   
4. table Lien élevés
   
   1. Maître (Id compositeur)
   2. élèves (Id compositeur)

je ne dis pas que toutes les table et tous les champs sont inutile mais il faut évaluer s important dans le projet de Pierre.

[Pierre Fauconnier]

Oui, les IDPersonne envoyés dans les tables Naissance et Décès doivent être précisés lors de la saisie. Sauf que normalement, on ne saisit jamais directement les données dans les tables, mais au travers de formulaires.

Normalement, ce sont les champs fils/champs père qui vont lier le formulaire Naissance/Décès affiché dans un sous-formulaire du formulaire Personne qui vont s'occuper d'insérer IDPersonne dans les tables Naissance/Décès.

Par rapport à la lecture et au fil d'Ariane qui permet de passer d'une table à l'autre, ça ne change rien puisque de toute façon, même modélisée autrement, la relation sera de facto 1:1.

Pour le reste, je rejoins Robert. Se tenir à un schéma avec les tables indispensables au but final visé. Ca fera de toute façon déjà pas mal de boulot, en gardant à l'idée qu'un table permet de stocker les données d'une et une seule entité (d'où l'utilisation des liens clé primaire - clé étrangère).

[mjpmjp]

bonjour,

Spécialement pour Touche_a_tout , voila en pièce jointe ta base de donnée .. nettoyée et ajustée pour les règles d'intégrité

attention les form sont en mode "bricolage"

2018-03-28_v1.zip

@+JP

[mjpmjp]

re,

le fichier 2018-03-28_v1 était complètement en cours de codage et non fonctionnel !!
alors voila la v2 qui , même s'il est toujours en codage , n' a pas d'erreurs

2018-03-28_v2.zip

@+JP

[touche_a_tout]

Bonjour,
Je me rapproche plutôt de l'avis de Robert et j'irais même plus loin: à l'origine, il n'y a qu'une seule table, celle des compositeurs. La table "liaison" se crée au fur et à mesure que l'on saisit des relations maître-élève et, dans la fenêtre des relations, on a deux instances de la table compositeurs, l'une "réelle" en tant que table des compositeurs_élèves, l'autre "fantôme" en tant que table des compositeurs_maîtres. Mais j'ai du mal, intellectuellement, à travailler avec une table fantôme, c'est pourquoi j'ai en réalité deux tables distinctes, T_eleves et T_maitres qui sont distinctes, je me répète, mais identiques de contenu (puisque les compositeurs, qu'ils soient maître ou élèves, sont les mêmes).
C'est là qu'apparaît le problème auquel Pierre Fauconnier m'a proposé une solution (merci), mais je ne m'en sors toujours pas. J'ai vérifié mes tables du point de vue structure. Les champs ont le même type et les mêmes caractéristiques. Seule exception: le champ ID_maitres est de type numérique (entier long) dans la table liaison parce que cette table comporte déjà un champ Numéro-auto (entier long) avec l'ID élève et on ne peut pas en avoir deux. J'ai testé en mettant le champ ID_Maitre de la table maitres soit en numéro-auto, soit en numérique avec toujours la même erreur.
Du point de vue contenu, j'ai un entier dans les champs ID des 3 tables et des textes courts (Nom et Prénom) dans les champs correspondants des 3 tables, donc pas de valeur Null. Et donc je n'arrive pas à comprendre en quoi ma table liaison ne respecte pas les conditions de l'intégrité référentielle.
Si quelqu'un peut éclairer mon lumignon...
Merci d'avance
Pierre

[Pierre Fauconnier]

Normalement, tu ne dois avoir qu'une table compositeur qui contient les maîtres et les élèves.

Si la hiérarchie élève/maître est une vraie hiérarchie (un seul parent pour plusieurs enfants), tu peux effectivement avoir un lien récursif, qui est forcément un lien de 1 à plusieurs.
Si un élève peut avoir plusieurs maîtres, tu ne peux pas avoir ce type de lien puisque, vu qu'il n'y a qu'un champ, tu ne sais avoir qu'un parent.

Dans ce cas, tu dois passer par une table qui crée les associations. Perso, je pensais que cette étape était franchie depuis longtemps (ce n'est pas agressif, c'est juste une constatation ).

[Invité]

d'accord avec ton schéma, saut car il y a un sauf, pour la notion de maître qui est implicite dès l'hors qu'il y a élève et pour le créateur qui est au choix in compositeur qui est créateur ou le langage qui est créé par un compositeur.

un créateur est l'instigateur de plusieurs langage donc personne est en lien avec la table [lien Langages] .

pour moi une personne est Maître, il dispose d'un ou plusieurs langages etc...

un élève à un maître par le seul fait qu'un Maître l'a comme élève mais c'est comme ça que je vois les chose ton schéma avec la table Tbl_InstanceMaître tien la route.




Édit:



dans ce schéma ci dessus nous trouvons Compositeur et Compositeur_1? Compositeur_1 est en réalité la table Compositeur, donc Compositeur et Compositeur_1 c'est la même chose (nom table et nom d'alias).

la table Liens_Maitreeleve permet de faire le lien entre un compositeur Maître et plusieurs Compositeur élèves ou un Compositeur élève avec plusieurs Compositeur Maîtres.

Liens_Maitreeleve est un table de relation de plusieurs (∞ Maîtres ) à plusieurs (∞ Élevés). bref c'est une table à double entrées et à double sans.






au total nous avons 4 tables.

[touche_a_tout]

Bonjour, Pierre Fauconnier,
Mais oui, cette étape a été franchie depuis longtemps. On en a la trace dans le post #44 du fil "Généalogie musicale sous Access" sur le forum Access, à la date du 15 février (2018). Seulement je ne suis jamais arrivé à reconstituer la solution que j'avais trouvée à l'époque ! Rgntudju !!
Je m'y colle à nouveau. Et merci de tes avis. Je n'y ai rien trouvé d'agressif.
Cordialement
Pierre

[touche_a_tout]

Bonjour,
J'y suis arrivé ! Je n'ai pas encore codé les sub événementielles mais ça devrait marcher. Mais en attendant j'ai une autre question. Dans Access 2016 je ne vois pas comment afficher ensemble le formulaire/sous-formulaire élèves-liaison ainsi que le formulaire maitres, comme je le faisais avec ma vieille version comme ceci:

J'en ai besoin car la méthode consiste, ayant un certain élève affiché dans le formulaire de gauche, à sélectionner son maitre dans le formulaire de droite puis à presser sur "Transférer" (ce qui écrit un "couple" maitre-eleve dans la table liaison).
J'espère que c'est toujours possible depuis 2016 !
Merci d'avance.
Cordialement
Pierre

[Invité]

Tu ouvres le formulaire principal en mode création ; avec la souris tu fais glisser ton sous formulaire en lieu et place sur le formulaire principal; maintenant il ne font plus qu'un; en haut à gauche du sous formulaire il y a un petit carré noir. Click dessus, si la fenêtre des propriétés ne s'affiche pas double click.

Il y a quelque part la notion d père fils il faut lui affecter Id du formulaire principal et celui du sous formulaire.


Maintenant il t'ai possible d'ouvrir mon fichier tu auras un exemple.

Pour les Id laisses access te donner un numéro auto incrément si c'est l'utilisateur qu choisi c'est source d'erreur.

En plus dans mon exemple tu verras qu'on regarde que le compositeur et c'est a ce niveau qu'on gère les élèves e l'attribution d'un groupe de langage. Je suis partis du postulat qu'un compositeur pouvait usiter plusieurs langues qu'il en soit le créateur ou non.

C'est le formulaire compositeur qui gère la plus grande partie. Langage et créateur étant une annexe.

Il y a un autre formulaire pour les langages.
Regardes pour te donner une idée et fais en ce que tu veux si ça peux t'aiguiller.

Vois mon fichier plus comme un tuto plus qu'une solution irrésistible.

Si tu ouvres la table lien_maitreeleves à la faute d'horographe près tu pourras constater qu'il y a des onglets tout en bas de la fenêtre. Click sur selui d droite et regardes sont contenue en fonction du champ sélectionné.

[touche_a_tout]

Bonsoir dysorthographie,
Merci pour tous ces détails et pour la liberté que tu me laisses. Il paraît que je n'en fais qu'à ma tête, ça tombe bien!

Il y a quelque part la notion d père fils

et je me rappelle très bien avoir vu ces mentions mais je ne les vois pas dans mon cas (ni dans ton fichier). J'ai regardé sous les différents onglets.

En plus dans mon exemple tu verras qu'on regarde que le compositeur et c'est a ce niveau qu'on gère les élèves e l'attribution d'un groupe de langage. Je suis partis du postulat qu'un compositeur pouvait usiter plusieurs langues qu'il en soit le créateur ou non.

Tout à fait d'accord avec la première phrase. Dans toute cette histoire il n'y a que des compositeurs, ils ont le premier rôle.
Par contre sur les langages on ne peut pas raisonner comme à propos des langues qu'on apprend pour devenir polyglotte (mjpmjp va de nouveau dire qu'on papote ). En fait chaque compositeur a son langage. Si on prend 3 oeuvres composées entre 1780 et 1800, à une époque où les modèles hérités du passé sont encore bien suivis, une oreille exercée distinguera ce qui est de Mozart, de Haydn ou de Woelff car chacun fait sa propre synthèse à partir de l'enseignement reçu au départ et des acquisitions ou influences reçues en même temps ou par la suite. En outre certains composent de la même manière pendant presque toute leur carrière tandis que d'autres ont ce qu'on appelle des "périodes" (comme on parle de la "période rose" - ou bleue - pour Picasso). Donc pour moi pas de liaisons compositeurs-langages, mais des langages appliqués comme des propriétés à des compositeurs.
On ne peut pas non plus parler de créateurs d'un langage car en général le langage (ou un nouvel élément du langage) émerge d'une évolution. On considère Schönberg comme le créateur du dodécaphonisme: il a été le premier à en définir systématiquement les règles, mais je ne sais plus quel compositeur largement antérieur utilisait déjà la série des 12 sons caractéristique du dodécaphonisme.
Je vais donc en rester à trois tables: compositeurs-maitres, compositeurs-élèves et liaisons maitres-élèves.
Il me reste à trouver le moyen d'afficher mon bloc élèves-liaison et mon formulaire maîtres, comme sur ma copie d'écran du post de 17 h 20. Si tu as une piste, je serai ravi.
Merci encore et bonne soirée
Cordialement
Pierre

[touche_a_tout]

Post Scriptum:
J'ai ouvert ton formulaire liens_maitreleve mais je n'ai pas vu les onglets que tu mentionnes. IL y a toujous des mystères...
Bonne soirée
P.

[Invité]

Non je parlais pas du formulaire mais de la table.

Dernière image du poste #172

Et image de ce poste là
https://www.developpez.net/forums/d1.../#post10119173

Édit:
Je pense qu'il y a incompréhension sur la notion de base de données relationnel.

Toi tu considères la table Maître et la table Élèves.

Tu entres le pédigrée d'un Maitre et le pédigrée d'un Élèves qui peut être Maître également.

Bref si j'ai bien compris tu saisie un fois le compositeur si il est Maître et une deuxième fois le compositeur si il est Élevé. Tu ne parle pas du cas ou il serait n'y l'un n'y l'autre.

Moi je te propose que tous les compositeurs soient dans la même table. Il est Maître dès l'hors qu'il dispose d'élèves il est élevé dès l'instant ou un Maître l'a pris sous sa coupe,ou n'y l'un n'y l'autre si il n'est sous la coupe de personne ou si il n'a personne sous sa coupe.

J'ai bien deux tables une compositeurs avec tous les acteur Maître ou pas,Élèves ou pas.

J'ai une deuxième table qui fait le lien entre les Maîtres de la table compositeurs et les Élèves de la table compositeurs.

Pierre Fauconnier help me

[Invité]

Bonjour,

[touche_a_tout]

Bonsoir dysorthographie,
J'espère que tu as pu faire une pause.
Je reviens à mes amours: Access et les relations. Je suis incapable de reconstituer ce que pourtant j'ai réussi une fois. Que je suive tes exemples illustrés ou que je cherche mon chemin, ma table de liaison ne lie rien sauf le premier "couple" maitre_élève. Ensuite je n'ai que des champs vides. Je ne sais pas si je dois mettre une ou plusieurs clés primaires dans chaque table. Il me semble avoir lu sur un site (mais pas DVP) qu'il fallait en mettre le plus possible. Ca paraît bizarre.
Il me semble aussi que j'obtenais automatiquement (du moins sans le chercher) des relations 1 à plusieurs (avec le signe infini ou lemniscate) mais je n'y arrive plus ! Je suis décidément un grand débutant sur Access ! J'ai cherché des tutoriels sur divers sites mais sans trouver de réponse à ces questions ci-dessus.
Je vais laisser en sommeil et voir venir. Je sature.
Bonne soirée
Cordialement
Pierre

[Pierre Fauconnier]

Il ne peut y avoir qu'une clé primaire par table. Cela n'aurait d'ailleurs pas d'intérêt, sur un plan théorique, qu'il y en ait plusieurs. Mais quoi qu'il en soit, les SGBDR n'acceptent qu'une clé primaire.

Cette clé primaire peut être composée, en ce qu'elle peut être constituée de la concaténation de plusieurs champs. Ainsi, si on interdire qu'il y ait plusieurs relations Prof P/Elève E, on aura une clé primaire composée des deux clés étrangères. Dans le schéma qui suit, il y a deux symboles de clé sur la table ProfEleve, mais cela veut dire que l'unique clé primaire de la table est composée des valeurs des deux clés étrangères, interdisant plus d'une liaison entre le prof P et l'élève E.

Cela dit, normalement (je n'ai pas repris toute la discussion ), prof et élève doivent normalement faire partie de la même table, et il me semblerait logique qu'un prof puisse avoir plusieurs élèves, voire même qu'un élève soit aussi un prof (principe même d'une arborescence, ceci dit, ce qui me met mal à l'aise avec l'intitulé de la discussion)

Mon illustration ne vaut donc que pour illustrer l'idée d'une clé primaire composée et pour valider le fait qu'une table doit avoir une clé primaire mais ne sait en avoir qu'une seule, éventuellement composée de plusieurs champs.

J'ajoute pour conclure sur les clés primaires que pour moi, la clé primaire doit être technique et uniquement technique, c'est-à-dire qu'elle ne doit avoir aucune signification métier. C'est juste une donnée technique dont le SGBD a besoin pour assurer les liaisons et l'intégrité référentielle. Il ne faut pour moi jamais utiliser comme clé primaire une info métier (matricule, plaque minéralogique, code de produit, ...) et privilégier les clés primaires numériques autoincrémentées.