Discussion :

[escartefigue]

pour que le SGBD accepte les insertions, il faut soit insérer dans l'ordre des contraintes (et donc insérer les personnes avant leurs adresses) puisqu'il y a besoin de l'identifiant personne dans la table adresse,
soit désactiver provisoirement les contraintes mais c'est toujours un risque.

[fsmrel]

Bonjour Nerva,

Si je lance l'INSERT avec du début à la fin du script les lignes ADRESSES puis PERSONNES, l'outil SQL va buter sur la clé étrangère PER_ID de la table ADRESSES puisqu'il ne trouvera pas dans la table PERSONNES les lignes correspondantes. Pour que ça fonctionne, il faudrait insérer les lignes de PERSONNES en premier. Et évidemment, ce qui est facilement faisable avec 2 tables ne l'est plus avec plusieurs.

D’un point de vue fonctionnel, votre approche revient à dire : créons a priori des adresses, des téléphones, on verra bien ensuite à qui les affecter. Voilà qui est original ! Dans le même esprit, créons des adresses de courriel avant de créer les personnes ! Ce serait insensé et je n’y crois pas, le bon sens doit prendre le dessus. En 50 ans de modélisation et de création de bases de données dans plein de secteurs d’activité, j’ai toujours vu appliquer le raisonnement selon lequel les personnes sont créées avant les adresses. A la rigueur, un informaticien chez un marchand d’immeubles neufs peut créer une table des adresses, mais sans que le marchand ait à se demander qui y habitera un jour, son seul souci étant de vendre. Mais un agent immobilier qui vend des maisons et des appartements sait qui y réside encore pour un temps.

Bref, avant de créer une adresse, commencez par créer la personne qui y réside. Si vous ne pouvez pas le faire, expliquez pourquoi.

Cela dit, si plusieurs personnes pouvaient habiter à la même adresse, alors il faudrait mettre en oeuvre une table d’association entre PERSONNE et ADRESSE, et là on pourrait créer une adresse avant de créer les personnes y habitant, la connexion entre PERSONNE et ADRESSE étant établie ensuite au moyen de la table d’association.

[Nerva]

@fsmrel, ce que j'expliquais s'appliquait uniquement dans le cas spécifique où à partir d'une nouvelle base, je possède déjà une collection d'enregistrements que je veux insérer pour tester. Bien entendu qu'une fois dans l'action, on ne crée pas de factures pour un client inexistant ! LO Base ne veut rien entendre, je n'y peux rien...

J'ai lancé votre dernier script dans MySql mais je ne suis pas plus avancé. Chaque personne a dorénavant un code, mais toujours rien pour distinguer les clients des employés...

[Nerva]

Juste pour clôturer le hors-sujet des contraintes des clés étrangères, j'ai fini par trouver.

Début de script :

Code :

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

SET REFERENTIAL_INTEGRITY FALSE;

Fin de script :

Code :

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

SET REFERENTIAL_INTEGRITY TRUE;

https://wiki.openoffice.org/wiki/FR/...TIAL_INTEGRITY

C'est déjà ça de gagné...

[fsmrel]

toujours rien pour distinguer les clients des employés...

Normalement c’est quand même la présence dans la table EMPLOYE qui permet de savoir qui sont les employés (même principe pour les clients, toutes choses égales) :

Quelles personnes sont des employés

SELECT PER_CODE, PER_NOM, PER_PRENOM, EMP_NUM_SS
FROM   PERSONNE as x JOIN EMPLOYE as y ON x.PER_ID = y.PER_ID
;

Raoul est-il un employé ? Méthode bourrin : Comptons...

SELECT COUNT(*) 
FROM   PERSONNE as x JOIN EMPLOYE as y ON x.PER_ID = y.PER_ID
WHERE  PER_CODE = 'VOL00001' 
; 

Sinon pourriez-vous mieux préciser la nature de votre problème ?

[CinePhil]

Si je lance l'INSERT avec du début à la fin du script les lignes ADRESSES puis PERSONNES, l'outil SQL va buter sur la clé étrangère PER_ID de la table ADRESSES puisqu'il ne trouvera pas dans la table PERSONNES les lignes correspondantes. Pour que ça fonctionne, il faudrait insérer les lignes de PERSONNES en premier. Et évidemment, ce qui est facilement faisable avec 2 tables ne l'est plus avec plusieurs.

Comme mes collègues ont déjà bien répondu sur ce cas particulier, je vais répondre pour le cas général...
L'ordre de création des tables est en principe le suivant :
1) Toutes les tables qui n'ont pas de clé étrangère
2) Les tables issues d'entités types du MCD ayant une clé étrangère, y compris les tables fille d'un héritage, et bien sûr dans l'ordre de l'arbre de l'héritage : du plus général (ex. Personne) au plus particulier (ex. Employe, qui hérite de personne physique qui hérite de personne).
3) Les tables associatives (ou tables de jointure) parce que leur clé primaire est composée de clés étrangères.

[Nerva]

@cinephil, avec mon habitude de tout classer par ordre alphabétique..........

@fsmrel, désolé mais je ne comprends pas les petits x et y.

[escartefigue]

x et y sont des alias : dans la requête, plutôt que de désigner la table in extenso (c'est parfois pénible, certains modèles utilisent des noms de table à rallonge), on utilise un alias, un pseudonyme quoi.

Par exemple

Code :

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

1
2
3
4
5
6
7
select T1.Colonne1
     , T1.Colonne2
     [...]
     , T2.ColonneX
from TX1_vxwc_R000455_ZER87BV_TU01  as T1
inner join RCZ_U48063_BAXSZEE_GX25  as T2
   on T2.ColonneA=T1.Colonne1

C'est plus facile à écrire que

Code :

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

1
2
3
4
5
6
7
select TX1_vxwc_R000455_ZER87BV_TU01.Colonne1
     , TX1_vxwc_R000455_ZER87BV_TU01.Colonne2
     [...]
     , RCZ_U48063_BAXSZEE_GX25.ColonneX
from TX1_vxwc_R000455_ZER87BV_TU01  as T1
inner join RCZ_U48063_BAXSZEE_GX25  as T2
   on RCZ_U48063_BAXSZEE_GX25.ColonneA=TX1_vxwc_R000455_ZER87BV_TU01.Colonne1

Sachant que le mot clef "AS" est facultatif mais il est parlant

[Nerva]

Oui pardon, ça je sais, mais je ne comprends pas comment les données sont filtrées.

[escartefigue]

À mon tour je ne comprends pas cette question

En SQL, "filtrer" c'est utiliser une clause WHERE ou une restriction dans les critères de jointure ON ou encore dans le résultat du groupage avec HAVING

[Nerva]

C'est ce que je voulais dire. La clause WHERE, d'accord, mais basée sur quoi dans ce script ? Les lignes ont été saisies manuellement. Pour les 12 personnes, il y a 7 clients et 5 employés. Mais une fois dans le formulaire, rien ne distingue les uns des autres.

Rappel des copies d'écran.

- 1 formulaire principal PERSONNES + sous-formulaire EMPLOYES
- 1 formulaire principal PERSONNES + sous-formulaires CLIENTS

Dans chaque sous-formulaire figurent les colonnes spécifiques mais tel quel, j'ai 12 entrées (personnes) dans chaque. Aucune clause pour différencier les clients des employés. C'est pourquoi dans la table PERSONNES j'ai ajouté une colonne TYPE (1 pour les employés, 2 pour les clients) afin d'appliquer la clause sur la dite colonne. Il y a peut-être plus judicieux comme façon de faire mais je n'ai rien trouvé d'autre.

[escartefigue]

François (Fsmrel) a expliqué ce point hier (réponse n°45)

il a proposé deux méthodes
- par equi jointure
- par comptage

on peut en proposer d'autres
-test d'existence (exists)
-exclusion de la sous-population non désirée (except)

La méthode la plus simple reste l'équi jointure, la première proposition de François donc

[Nerva]

La méthode la plus simple reste l'équi jointure, la première proposition de François donc

Je ne comprends pas comment ça fonctionne.

[escartefigue]

Là on est sur les fondamentaux !

Voici un tuto sur les jointures, à lire et relire
https://sqlpro.developpez.com/cours/sqlaz/jointures/

[Nerva]

Pour les jointures, il me semble que depuis le temps j'ai les bases, mais je bute sur ce script : je ne comprends pas où la distinction s'opère entre clients et employés. Peut-être que c'est tout bête mais je ne vois pas.

[fsmrel]

je ne comprends pas où la distinction s'opère entre clients et employés.

Utilisons le marteau-pilon :

CREATE VIEW TUTTI (typePersonne, perCode, Nom, Prenom, DateEntree, DateNais, NIR, cliNum)
as
SELECT 'employé', PER_CODE, PER_NOM, PER_PRENOM, PER_DATE_ENTREE, PER_DATE_NAIS, EMP_NUM_SS, 'sans objet !'
FROM   PERSONNE as x JOIN EMPLOYE as y ON x.PER_ID = y.PER_ID 
union
SELECT 'client', PER_CODE, PER_NOM, PER_PRENOM, PER_DATE_ENTREE, PER_DATE_NAIS, 'sans objet !', CLI_NUM
FROM   PERSONNE as x JOIN CLIENT as y ON x.PER_ID = y.PER_ID 
;

SELECT * FROM TUTTI ; 

=>

typePersonne  perCode    Nom        Prenom     DateEntree   DateNais     NIR               cliNum
employé       JEA00001   Jean       Jean       1962-10-22   1903-07-19   103077937012355   sans objet !
employé       NAU00001   Naudin     Fernand    1962-10-21   1919-07-14   121077500514586   sans objet !
employé       ANT00001   Antoine    Delafoy    1962-10-22   1929-02-08   129026700014801   sans objet !
employé       PAT00001   Patricia   Patricia   1962-10-22   1942-08-18   242085700200444   sans objet !
client        VOL00001   Volfoni    Raoul      1962-12-14   1916-01-11   sans objet !      0007
client        VOL00002   Volfoni    Paul       1962-12-14   1919-10-03   sans objet !      0008
client        PAS00001   Pascal     Pascal     1963-01-07   1930-04-17   sans objet !      0014
client        BAS00001   Bastien    Mac        1963-01-07   1913-06-20   sans objet !      0015
client        MAD00001   Mado       Mado       1963-01-07   1919-01-27   sans objet !      0020
client        THE00001   Théo       Théo       1963-01-07   1929-07-28   sans objet !      0035
client        TOM00001   Tomate     Tomate     1962-12-21   1914-07-22   sans objet !      0048

[Nerva]

Alors finalement j'arrive à relier tout ce monde avec ce que j'avais imaginé : une colonne PERSONNE_TY_ID pour identifier les groupes (message #28).

Je récapitule.

1) À la base, j'avais besoin de savoir comment insérer une table de liaison afin de relier plusieurs entités, possédant chacune des adresses, des téléphones, etc. J'ai eu la réponse dans le message #13, avec les relations 1:1 auxquelles je n'avais pas pensé.
2) J'ai défini l'incrémentation automatique sur PER_ID de T_PERSONNES.
3) Lors des premiers tests dans les formulaires clients et employés (chacun un formulaire PERSONNES + un sous-formulaire correspondant), ne pouvant faire aucune distinction entre les deux entités, l'ajout d'une table T_PERSONNES_TY et du champ PER_TY_ID m'a paru la seule méthode pour les différencier grâce à une clause WHERE dans chaque formulaire. Telle qu'est la base, je peux ainsi adapter la méthode à plusieurs entités, les clients, employés, fournisseurs et transporteurs évoqués dans le sujet initial.

J'attends encore un peu avant de clôturer, au cas où...

Merci à tous pour vos réponses conséquentes et surtout pour votre patience...

[escartefigue]

Bonsoir les mousquetaires

Bonjour François,

Une petite question relative à cette notation "crow's foot" : pour la représentation des MLD, vu que la notation permet de préciser les cardinalités minimales à 0, quel est l'intérêt des liaisons en pointillés ?
Au niveau MLD, je ne vois que 6 cas de liaison : 1,1---1,N / 0,1---1,N / 1,1---0,N / 0,1---0,N / 0,1---0,1 / 0,1---1,1
Merci pour ton éclairage !

Dans MySQL Workbench, les liens pleins sont les "identifying relationships". Cas typique : table associative. Les autres sont pour les clés étrangères simples.

Donc...
A -0,n----association----0,n- B => Table associative avec trait plein => A -||----o< table_associative >o|----||- B
A -0,n----association----1,1- B => Association avec trait pointillé => A -||- - - -o< B

C’est une représentation propre à MySQL Workbench (qui se situe en fait au niveau MLD) : aucun intérêt pour Looping au niveau MCD. A voir au niveau MLD, a priori je ne dis pas non...

Compte tenu de la restriction de MySQL qui n'accepte que les PK mono-colonne , cette symbolique ne concerne finalement que les cas d'héritage.
Comme a priori seul workbench l'utilise, je pense comme François qu'il est inutile de s'en encombrer, l'information étant disponible par ailleurs et nettement plus facile à lire dans le MCD (en ce qui me concerne c'est bien là le plus important )

[CinePhil]

Compte tenu de la restriction de MySQL qui n'accepte que les PK mono-colonne

Euh... non ! J'ai plein de tables avec PK multi-colonnes, et pas seulement des tables associatives mais aussi des identifiants relatifs + une autre colonne.

[escartefigue]

Le problème c'est d'avoir une pk avec un identifiant relatif qui est un auto_increment + une autre colonne, c'est là que ça ne fonctionne pas, or, c'est le cas le plus fréquent.