Discussion :

[escartefigue]

Ne pas créer de classe PLATFORM et ASSIGN_GROUP c'est accepter la redondance et donc risquer des incohérences.

La complexité des requêtes est toute relative (l'ajout d'une table ce n'est pas grand chose) et si ça peut poser des difficultés, il suffit de stocker la jointure ad hoc dans une vue et ce sera complètement indolore pour les développeurs peu aguerris

Une base de données relationnelle n'est pas un tableur, il est très important de modéliser les types d'entité avec soin (y voir là une forme de talibanisme serait une grande erreur)

Tout mettre dans une seule table présente l'inconvénient d'augmenter le nombre d'accès concurrents ce qui pénalise les perfs.
Plus il y a de données dans une même table, plus les différents traitements qui utilisent les différents sous-ensemble fonctionnels regroupés dans cette table se gênent les uns les autres.

De plus, le jour ou l'organisation de l'entreprise change, par exemple le groupe de compétence "MACHIN" est renommé "TRUC", vous devrez modifier par update toutes les lignes TICKET affectées à "MACHIN", ça peut représenter des millions d'update inutiles alors qu'un seul aurait suffi...

[laurentSc]

Faut-il être owner d'une licence pour (faire)déposer un ticket (en tant que customer...) ? Question pour valider l'intérêt de l'association concern_t...

C'est exact, seul les propriétaires de licence peuvent aussi être customer. En quoi cela peut-il concerner l'association concern_t ?

En remarque si héritage il n'est pas possible que id_user, id_customer et id_submitter n'aient pas le même format (on ne peut pas mixer INT et SMALINT du fait des foreign keys).

Il n'y a pas de mélange des types. Si je prend en exemple la plus simple des classes (qui a le moins d'attributs) :

Code sql :

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

1
2
3
4
5
6
CREATE TABLE submitter(
   id_submitter SMALLINT,
   id_user INT NOT NULL,
   PRIMARY KEY(id_submitter),
   FOREIGN KEY(id_user) REFERENCES user_table(id_user)
);

Son attribut id_user de type INT est une clé étrangère avec pour référent le id_user de type INT aussi de la table user_table.

Au passage, il est bien que les entiers auto-incrémentés soit non signés, histoire de ne pas perdre la moitié des clés.....

Si elle existe, je n'ai pas vu la propriété UNSIGNED dans Looping...

L'entité licence_owner me semble bizarre. Lorsque l'on regarde les attributs:

- email devrait être une propriété multi-valuée de user_table (Externalisation par exemple d'une entité coordonnnées, en association avec user_table)

- company et buunitname devraient probablement également être sortis de cette entité)

- Finalement license_owner se transformerait donc en association entre license et customer

A mon avis, les 3 classes license_owner, customer et submitter sont justifiées car dans les fichiers CSV que je traite, ces 3 sortes d'utilisateur sont présents, mais chacun avec des attributs différents. Par exemple, l'attribut email ne peut pas être remonté dans user_table car il n'est donné que pour les license_owner et pas pour les 2 autres types d'utilisateur. Pareil pour company et buunitname, donc je ne vois pas l'intérêt de les sortir de license_owner.

Une base de données relationnelle n'est pas un tableur, il est très important de modéliser les types d'entité avec soin (y voir là une forme de talibanisme serait une grande erreur)

Ce n'est pas clair pour moi. Pouvez-vous appuyer votre phrase par un exemple pris dans mon MCD ?

Tout mettre dans une seule table présente l'inconvénient d'augmenter le nombre d'accès concurrents ce qui pénalise les perfs.

C'est quoi les accès concurrents ? Les perfs ont-elles de l'importance vu la puissance des machines actuelles ?

Pour 'country', vous devriez utiliser la codification ISO 3166-1 alpha-3 (pas en tant qu'identifiant où il convient de rester sur un entier auto-incrémenté mais comme attribut ayant une propriété d'unicité).

Pour la plupart des codes (pays, unités de mesure, devises etc.) il existe une norme ISO, pratique car internationale et exhaustive.
Vous pouvez ici appliquer la norme ISO 3166 qui propose 3 codes pays (vous pouvez n'en retenir qu'un seul), alpha 2, alpha 3 et num 3.
L'usage le plus courant étant l'alpha 3.

OK, pris en compte.

Au vu de vos multiples remarques, j'ai fait évoluer le MCD : Qu'est-ce qu'il vaut ?

[escartefigue]

Bonjour LaurentSc

Ce n'est pas clair pour moi. Pouvez-vous appuyer votre phrase par un exemple pris dans mon MCD ?

C'est quoi les accès concurrents ? Les perfs ont-elles de l'importance vu la puissance des machines actuelles ?

les accès concurrents
Une base de données est très rarement utilisée par une seule personne ou un seul traitement. Le cas le plus fréquent est que plusieurs traitements batch ou TP s'exécutent simultanément. Si un traitement T1 modifie les coordonnées d'une personne, le traitement T2 qui a besoin de lire ces données devra attendre que T1 termine sa modification pour pouvoir lire ces informations. C'est ce fonctionnement qui garantit l'intégrité et le partage des données.
Dans les faits, c'est plus compliqué :

• les traitements posent des "verrous" dont le type (exclusif ou pas) et la portée (une ligne seulement, une page c'est à dire plusieurs lignes, toute la table) varie.
• les modifications s'exécutent au sein de "transactions" dont la durée est variable. Plus une transaction est longue, plus elle peut potentiellement provoquer l'attente d'autres transactions qui cherchent à lire ou modifier les données communes aux traitements qui s'exécutent en parallèle

Quelle est la différence entre l'organisation des données d'un tableur et d'une base relationnelle
Dans un tableur, on répète autant de fois les données que nécessaire.
Si par exemple j'ai un tableau de suivi des absences des employés par service, il se présentera sous la forme
n° Service; Libellé service; Matricule; Prénom; Nom; Date début; Date fin; Type absence
Ce faisant, le matricule, le nom et le prénom sont répétés autant de fois qu'une même personne a une période d'absence
On n'est donc pas à l'abri d'orthographes différentes d'une ligne à l'autre, de matricules différents pour une même personne, de matricules identiques pour des personnes différentes etc.
Dans une base relationnelle, on organise les données (c'est tout l'intérêt de la phase de modélisation conceptuelle) par objet de gestion (les types d'entité) et on tisse des liens entre ces objets (les associations).
Pour faire le lien avec ce qui concerne les accès concurrents.
Avec un modèle à plat type tableur, le traitement qui veut modifier le libellé d'un service devra lire toutes les lignes concernées par ce service (et peut être même toutes les lignes si aucun index n'est éligible pour rechercher le service) les verrouiller unitairement ou par paquets pour effectuer ses mises à jour et les libérer ensuite. Un autre traitement en parallèle qui recherche simplement le nom et le prénom d'un employé à partir de son matricule est bloqué, car ces informations sont dans les mêmes lignes que celles modifiées par le premier traitement.


Les perfs ont-elles de l'importance vu la puissance des machines actuelles ?
Même avec une machine très puissante, la différence de durée de traitement peut être extrêmement spectaculaire.
Un modèle de données mal conçu, des index manquants ou pléthoriques et des requêtes mal construites peuvent multiplier par 1 000, 10 000 et plus la durée d'un traitement. Et ce quelque soit la puissance de la machine.

[laurentSc]

Merci pour vos explications claires.

Par contre, encore 2 choses :

• Une base de données relationnelle n'est pas un tableur, il est très important de modéliser les types d'entité avec soin (y voir là une forme de talibanisme serait une grande erreur)

  Je comprends pas la fin de la phrase
• Vous ne faites pas de remarque sur mon MCD...

[escartefigue]

Certains pensent que respecter les règles de modélisation et donc les formes normales, est une forme d'intégrisme.
C'est le sens de la fin de ma phrase.

Pour le MCD, j'y reviendrai quand j'aurai accès à un autre écran que celui de mon portable, sur lequel j'ai du mal à déchiffrer les MCD, ma vue n'est plus ce qu'elle était, malheureusement

[isabelle.letrong]

C'est exact, seul les propriétaires de licence peuvent aussi être customer. En quoi cela peut-il concerner l'association concern_t ?

C'est juste que votre MCD ne permet pas d'associer simplement un ticket à une licence mais seulement à une application (pour trouver la licence liée au ticket il faudra rechercher parmi toutes les licences du customer, celle qui correspond à l'application et encore, car dans le modèle rien n'interdit à un customer d'avoir plusieurs licences de la même application !).
Il serait à mon sens préférable de supprimer concern_t et d'associer le ticket à une licence qui détermine l'application...

C'est exact, seul les propriétaires de licence peuvent aussi être customer. En quoi cela peut-il concerner l'association concern_t ?

Il n'y a pas de mélange des types. Si je prend en exemple la plus simple des classes (qui a le moins d'attributs) :

Code sql :

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

1
2
3
4
5
6
CREATE TABLE submitter(
   id_submitter SMALLINT,
   id_user INT NOT NULL,
   PRIMARY KEY(id_submitter),
   FOREIGN KEY(id_user) REFERENCES user_table(id_user)
);

Son attribut id_user de type INT est une clé étrangère avec pour référent le id_user de type INT aussi de la table user_table.

submitter hérite de user_table, ces 2 tables ont donc la même clé primaire
Cela veut dire qu'il est inutile de définir id_submitter ET id_user. Puisque vous souhaitez appeler la clé primaire de submitter 'id_submitter', 'id_submitter' doit être de type INT, être la clé primaire de submitter et également une clé étrangère vers user_table. Le DDL de la table submitter devient donc :

Code sql :

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

1
2
3
4
5
6
CREATE TABLE submitter(
   id_submitter INT NOT NULL,
 
   PRIMARY KEY(id_submitter),
   FOREIGN KEY(id_submitter) REFERENCES user_table(id_user)
);

Vous gagnez un index et un attribut parfaitement inutiles !

Si elle existe, je n'ai pas vu la propriété UNSIGNED dans Looping...

Je n'utilise pas Looping pour l'instant mais je crois que c'est paramétrable....

A mon avis, les 3 classes license_owner, customer et submitter sont justifiées car dans les fichiers CSV que je traite, ces 3 sortes d'utilisateur sont présents, mais chacun avec des attributs différents. Par exemple, l'attribut email ne peut pas être remonté dans user_table car il n'est donné que pour les license_owner et pas pour les 2 autres types d'utilisateur. Pareil pour company et buunitname, donc je ne vois pas l'intérêt de les sortir de license_owner.

Vous pouvez parfaitement distribuer comme bon vous semble les données du fichier d'import en les ventilant dans vos différentes tables...
L'idée est juste de construire un modèle pérenne.
Il ne reste pas moins que l'email est bel et bien conceptuellement une propriété, en général multivaluée, du 'user'. Donc en toute rigueur, vous devriez avoir dans votre modèle une entité (faible) mail ou coordonnee, attachée au user, qui a en particulier comme attributs identifiant, et valeur du mail (ou de la coordonnée si on élargit le mail à la notion de coordonnée (mail, téléphone fixe, téléphone portable,...).
Cela vous permet parfaitement de ne pas connaitre l'email de certains user(s) !

[laurentSc]

Il serait à mon sens préférable de supprimer concern_t et d'associer le ticket à une licence qui détermine l'application...

Au moment où je traite les données d'un fichier CSV "ticket", même si le customer est forcément propriétaire d'une licence, aucune garantie que celle-ci soit déjà renseignée. Pareil pour l'application, mais si elle n'existe pas encore, on l'insère (seulement id_application et appli_name car on ne connaît que ceux-là). Donc comment gérer ça ?

submitter hérite de user_table, ces 2 tables ont donc la même clé primaire
Cela veut dire qu'il est inutile de définir id_submitter ET id_user. Puisque vous souhaitez appeler la clé primaire de submitter 'id_submitter', 'id_submitter' doit être de type INT, être la clé primaire de submitter et également une clé étrangère vers user_table.
Vous gagnez un index et un attribut parfaitement inutiles !

merci.

Vous pouvez parfaitement distribuer comme bon vous semble les données du fichier d'import en les ventilant dans vos différentes tables...
L'idée est juste de construire un modèle pérenne.
Il ne reste pas moins que l'email est bel et bien conceptuellement une propriété, en général multivaluée, du 'user'. Donc en toute rigueur, vous devriez avoir dans votre modèle une entité (faible) mail ou coordonnee, attachée au user, qui a en particulier comme attributs identifiant, et valeur du mail (ou de la coordonnée si on élargit le mail à la notion de coordonnée (mail, téléphone fixe, téléphone portable,...).
Cela vous permet parfaitement de ne pas connaitre l'email de certains user(s) !

Si je faisais ça, il y aurait donc une clé étrangère dans user_table vers mail mais celle-ci serait NULL dans le cas où ne connait pas le mail. C'est ça ?

Selon, cette logique, il faudrait aussi créer une classe d'entité company avec les attributs company et buunitname. OK ?

[isabelle.letrong]

Pas le temps de répondre à tout , mais pour ce qui concerne :

Si je faisais ça, il y aurait donc une clé étrangère dans user_table vers mail mais celle-ci serait NULL dans le cas où ne connait pas le mail. C'est ça ?

Non, le jour où vous me verrez conseiller d'autoriser un DEFAULT NULL n'est pas encore arrivé !

En fait c'est le contraire : mail est une entité faible associée à user_table. Cela veut dire que si une occurence de user_table est supprimée, tous les mails qui lui sont attachés sont également supprimés !
Quand on passe au DDL de mail il y a une clé étrangère 'user_id' dans mail . La 'faiblesse' de mail se caractérise par la clause ON DELETE CASCADE au niveau de la définition de cette clé étrangère.

Donc on ne définit pas de colonne 'mai_id' à NULL dans user_table et par construction on ne trouve que des valeur connues de mails dans mail qui se rapporte à un user...

A plus tard....

[escartefigue]

Bonsoir,

Pour compléter les explications d'Isabelle, on parle d'entité type faible, quand l'entité-type n'a pas d'existence seule.
Cas typiques : la ligne de facture qui ne saurait exister sans sa facture ou la ligne de commande sans sa commande

Dans les MCD on trouve plusieurs symboliques possibles : cardinalités entre parenthèses (power-AMC) ajout d'un (R) à coté des cardinalités (Looping)

Au niveau tabulaire, on trouve, coté entité-type faible (ex : la ligne de facture), une PK composée de la PK de l'entité-type forte (ex : la pK de la facture) et d'une colonne supplémentaire. L'unicité est donc établie sur ce couple.

Note : la clause "ON DELETE CASCADE" n'est pas spécifique aux entités-type faibles, mais elle est recommandée en ce cas, une ligne de facture sans sa facture serait une situation bien fâcheuse

[laurentSc]

Merci pour vos explications.

Comme je ne connaissais cela, j'ai regardé https://sgbd.developpez.com/tutoriel...ation#LIII-F-3.

Pour être sûr d'avoir compris, j'ai créé un MCD test :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE entite_forte(
   id_entite_forte INT AUTO_INCREMENT UNSIGNED,
   PRIMARY KEY(id_entite_forte)
);
 
CREATE TABLE entite_faible(
   id_entite_forte INT AUTO_INCREMENT UNSIGNED,
   id_locale INT AUTO_INCREMENT UNSIGNED,
   PRIMARY KEY(id_entite_forte, id_locale),
   FOREIGN KEY(id_entite_forte) REFERENCES entite_forte(id_entite_forte)
);

Est-ce correct ?

[escartefigue]

Bonsoir Laurent

C'est correct, mais je n'ai aucun exemple qui me vienne à l'esprit d'une entité-type forte acceptant aucune (cardinalité mini zéro donc) occurrence de son entité-type faible.
La facture sans ligne de facture n'existe pas, la commande sans ligne de commande non plus, l'hotel sans chambre pas plus...
Pour autant, ça ne signifie pas que c'est une vérité absolue... à méditer !

J'aurais donc plutôt modélisé, en tout cas pour les cas les plus courants :

[ET_FORTE] 1,n --- (contenir)--- 1,1(R) [ET_FAIBLE]

[isabelle.letrong]

Bonsoir Laurent

C'est correct, mais je n'ai aucun exemple qui me vienne à l'esprit d'une entité-type forte acceptant aucune (cardinalité mini zéro donc) occurrence de son entité-type faible.

Et bien justement, et c'est quand même courant, une personne physique (user), l'entité forte, et ses mails (l'entité faible)…On peut très bien avoir un utilisateur sans mail..
En général on définira plutôt une entité faible plus large comme coordonnee qui supportera un type (mail, téléphone, fax,...) et la valeur elle-même de la coordonnée. Dans ce cas on a en général au moins une coordonnée, au moins à terme.
Dans cette approche, le fait de ne pas connaitre une coordonnée ou un mail n'impose pas un NULL

[escartefigue]

Bonsoir Isabelle

On peut effectivement avoir un utilisateur sans mail, mais il n'est pas aberrant de conserver un mail alors qu'on a supprimé son émetteur
L'émetteur est un prestataire de l'entreprise dont la mission est terminée depuis suffisamment longtemps pour ne pas conserver sa trace, mais l'un de ses messages est conservé quelque en soit la raison, c'est tout à fait possible.

Si on élargit l'exemple à d'autres média, par exemple le n° de téléphone, l'exemple me semble plus probant, quoique toujours pas incontournable, conserver un n° de téléphone alors que l'abonné n'est plus connu n'a sans doute guère d'intérêt mais pas impossible.

Pour les cas ci-dessus, on peut donc remplacer "ON DELETE CASCADE" par "ON DELETE SET NULL" sous réserve bien entendu que la colonne FK concernée soit "nullable"

A l'inverse si on supprime une commande toutes ses lignes disparaissent. Là c'est incontournable il FAUT le faire . Une ligne sans commande n'a véritablement aucun sens.

[laurentSc]

Et bien justement, et c'est quand même courant, une personne physique (user), l'entité forte, et ses mails (l'entité faible)…On peut très bien avoir un utilisateur sans mail..

Effectivement, il y a le cas du user et de son email (qu'il n'a pas forcément) et autre cas : pays (entité forte) et les sites d'une entreprise multinationale ; il y a bien des pays qui n'abritent aucun site...
Par contre, l'entité forte company possède au moins un employé...

Comme ces 3 cas me concernent, j'en ai fait le MCD :

Mais je me pose une question : dans mon modèle, la classe user_table est entité forte par rapport au mail (entité faible) ; par contre, logiquement, elle serait entité faible par rapport à company qui serait entité forte. Est-ce que ça tient la route ?

Ca me donne les DDL suivants :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
CREATE TABLE country(
   id_country INT AUTO_INCREMENT,
   country CHAR(3),
   PRIMARY KEY(id_country)
);
 
CREATE TABLE location(
   id_country INT,
   id_location INT AUTO_INCREMENT,
   location VARCHAR(30),
   PRIMARY KEY(id_country, id_location),
   FOREIGN KEY(id_country) REFERENCES country(id_country)
);
 
CREATE TABLE company(
   id_company INT AUTO_INCREMENT UNSIGNED,
   buunitname VARCHAR(50),
   company VARCHAR(30),
   PRIMARY KEY(id_company)
);
 
CREATE TABLE user_table(
   id_company INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   firstname VARCHAR(30),
   lastname VARCHAR(30),
   PRIMARY KEY(id_company, id_user),
   FOREIGN KEY(id_company) REFERENCES company(id_company)
);
 
CREATE TABLE mail(
   id_company INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   id_mail INT AUTO_INCREMENT UNSIGNED,
   email VARCHAR(150),
   PRIMARY KEY(id_company, id_user, id_mail),
   FOREIGN KEY(id_company, id_user) REFERENCES user_table(id_company, id_user)
);

La PK de mail est la concaténation de 3 colonnes...

Autre question : les cardinalités qu'on définit dans le MCD ont disparu dans les DDL. Donc, à quoi elles servent ?

Au fait, quand vous aurez le temps, n'oubliez pas ma 1e question du post #47.

[isabelle.letrong]

On peut effectivement avoir un utilisateur sans mail, mais il n'est pas aberrant de conserver un mail alors qu'on a supprimé son émetteur

Bonsoir escartefigue,
J'ai probablement une approche plus rigide que la votre mais à mon sens le mail est typiquement une propriété multivaluée et une propriété multivalué est toujours une entité faible en relation avec une entité plus forte.
Une occurrence de propriété multivalué n'a pas de raison d'exister sans l'existence de l'occurrence de l'entité forte propriétaire.

Dans ce qui suit, j'appelle objet une occurrence d'entité.

Ceci étant, si pour une raison quelconque on a besoin de référencer dans un objet a (comme le message dont vous parlez) une propriété P_b ayant appartenu à un objet b cela doit se traduire par le fait qu'il existe une propriété P_a de a pour laquelle la valeur de P_a est P_b. En d'autres termes : on duplique, car le fameux email est en réalité une propriété de a, ceci étant d'autant plus vrai que la valeur de P_b a pu changer dans b ultérieurement à l'émission du message a dans lequel il convient d'avoir conservé la valeur originale de l'email.

Mais là on pourrait lancer un débat sur les données de nature temporelle. Pas à minuit passé....

[isabelle.letrong]

Mais je me pose une question : dans mon modèle, la classe user_table est entité forte par rapport au mail (entité faible) ; par contre, logiquement, elle serait entité faible par rapport à company qui serait entité forte. Est-ce que ça tient la route ?

Oui, mais il faut se poser la question de la dynamique : je suppose que dans le monde réel, vous ne pouvez pas supprimer une occurence de company lorsque celle ci possède un submitter (user) détenteur d'une licence.
Donc si votre DDL est bien conçu/codé, en supprimant en cascade depuis company les objets via les FK vous devez immanquablement tomber à un moment sur un objet ayant une FK vers licence avec la propriété 'ON DELETE RESTRICT', ce qui provoquera l'interdiction de supprimer l'occurrence de company et de tous les objets impliqués en cascade !

Un exemple de la puissance des FK de SGBDR qu'il est typiquement impossible de mettre en œuvre via du code spécifique PHP....

[isabelle.letrong]

Au moment où je traite les données d'un fichier CSV "ticket", même si le customer est forcément propriétaire d'une licence, aucune garantie que celle-ci soit déjà renseignée. Pareil pour l'application, mais si elle n'existe pas encore, on l'insère (seulement id_application et appli_name car on ne connaît que ceux-là). Donc comment gérer ça ?

Forcément je vois cela d'un peu haut mais en général il s'agit juste d'une question de procédure.
Il convient d'importer vos CSV tels quel dans des tables temporaires en faisant éventuellement au passage un traitement de la qualité des données (ce qui est présenté comme un email est-il bien un email par exemple…). Une fois cet import fait, vous réalisez l'import final dans les tables de production dans une approche ensembliste avec toute la puissance du SQL dont vous disposez...

[laurentSc]

Il convient d'importer vos CSV tels quel dans des tables temporaires en faisant éventuellement au passage un traitement de la qualité des données (ce qui est présenté comme un email est-il bien un email par exemple…). Une fois cet import fait, vous réalisez l'import final dans les tables de production dans une approche ensembliste avec toute la puissance du SQL dont vous disposez...

Quand je disais aucune garantie que la licence soit déjà créée, le fait de passer par des tables temporaires ne changerait rien, car il ne s'agit pas d'un souci de la chronologie des INSERT : les licences sont écrites en bdd après la lecture d'un autre fichier CSV, et au besoin, la licence d'un customer arrivera en bdd après la création de ce customer. De ce fait, je pense que je ne peux pas faire la modif du MCD que vous conseillez...

[laurentSc]

Bonjour,

voici la dernière version de mon MCD, avec héritage, les attributs qui devaient être externalisés le sont, création de plusieurs entités faibles, forte réduction du nombre de colonnes nullables.
Merci de me dire ce que vous en pensez :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
CREATE TABLE country(
   id_country INT AUTO_INCREMENT UNSIGNED,
   country CHAR(3) NOT NULL,
   region CHAR(4) NOT NULL,
   PRIMARY KEY(id_country),
   UNIQUE(country)
);
 
CREATE TABLE file_uploaded(
   id_hash INT AUTO_INCREMENT UNSIGNED,
   hash VARCHAR(128) NOT NULL,
   PRIMARY KEY(id_hash)
);
 
CREATE TABLE location(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   location VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_country, id_location),
   UNIQUE(location),
   FOREIGN KEY(id_country) REFERENCES country(id_country)
);
 
CREATE TABLE user_table(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   sesa INT NOT NULL,
   firstname VARCHAR(30) NOT NULL,
   lastname VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_country, id_location, id_user),
   UNIQUE(sesa),
   FOREIGN KEY(id_country, id_location) REFERENCES location(id_country, id_location)
);
 
CREATE TABLE submitter(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   PRIMARY KEY(id_country, id_location, id_user),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES user_table(id_country, id_location, id_user)
);
 
CREATE TABLE platform(
   id_platform INT AUTO_INCREMENT UNSIGNED,
   platform VARCHAR(30) NOT NULL,
   platformowner VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_platform)
);
 
CREATE TABLE assign_group(
   id_assign_group INT AUTO_INCREMENT UNSIGNED,
   assign_group VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_assign_group)
);
 
CREATE TABLE company(
   id_company INT AUTO_INCREMENT UNSIGNED,
   company VARCHAR(30) NOT NULL,
   buunitname VARCHAR(30),
   PRIMARY KEY(id_company)
);
 
CREATE TABLE application(
   id_platform INT AUTO_INCREMENT UNSIGNED,
   id_application INT AUTO_INCREMENT UNSIGNED,
   appli_name VARCHAR(30) NOT NULL,
   publisher VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_platform, id_application),
   UNIQUE(appli_name),
   FOREIGN KEY(id_platform) REFERENCES platform(id_platform)
);
 
CREATE TABLE license_owner(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   id_country_manager INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_location_manager INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_user_manager INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_company INT AUTO_INCREMENT UNSIGNED NOT NULL,
   PRIMARY KEY(id_country, id_location, id_user),
   UNIQUE(id_country_manager, id_location_manager, id_user_manager),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES user_table(id_country, id_location, id_user),
   FOREIGN KEY(id_country_manager, id_location_manager, id_user_manager) REFERENCES license_owner(id_country, id_location, id_user),
   FOREIGN KEY(id_company) REFERENCES company(id_company)
);
 
CREATE TABLE customer(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   id_company INT AUTO_INCREMENT UNSIGNED NOT NULL,
   PRIMARY KEY(id_country, id_location, id_user),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES user_table(id_country, id_location, id_user),
   FOREIGN KEY(id_company) REFERENCES company(id_company)
);
 
CREATE TABLE mail(
   id_country INT AUTO_INCREMENT UNSIGNED,
   id_location INT AUTO_INCREMENT UNSIGNED,
   id_user INT AUTO_INCREMENT UNSIGNED,
   id_mail INT AUTO_INCREMENT UNSIGNED,
   email VARCHAR(30) NOT NULL,
   PRIMARY KEY(id_country, id_location, id_user, id_mail),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES license_owner(id_country, id_location, id_user)
);
 
CREATE TABLE license(
   id_license INT AUTO_INCREMENT UNSIGNED,
   activate_date DATE NOT NULL,
   deactivate_date DATE,
   id_country INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_location INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_user INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_platform INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_application INT AUTO_INCREMENT UNSIGNED NOT NULL,
   PRIMARY KEY(id_license),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES license_owner(id_country, id_location, id_user),
   FOREIGN KEY(id_platform, id_application) REFERENCES application(id_platform, id_application)
);
 
CREATE TABLE ticket(
   id_assign_group INT AUTO_INCREMENT UNSIGNED,
   id_ticket INT AUTO_INCREMENT UNSIGNED,
   num_ticket BIGINT NOT NULL,
   submitted_date DATE NOT NULL,
   last_resolved_date DATE NOT NULL,
   summary VARCHAR(200) NOT NULL,
   priority CHAR(6) NOT NULL,
   status CHAR(13) NOT NULL,
   type_incident CHAR(10) NOT NULL,
   source CHAR(12) NOT NULL,
   first_country VARCHAR(30) NOT NULL,
   id_country INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_location INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_user INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_country_1 INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_location_1 INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_user_1 INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_platform INT AUTO_INCREMENT UNSIGNED NOT NULL,
   id_application INT AUTO_INCREMENT UNSIGNED NOT NULL,
   PRIMARY KEY(id_assign_group, id_ticket),
   UNIQUE(num_ticket),
   FOREIGN KEY(id_assign_group) REFERENCES assign_group(id_assign_group),
   FOREIGN KEY(id_country, id_location, id_user) REFERENCES submitter(id_country, id_location, id_user),
   FOREIGN KEY(id_country_1, id_location_1, id_user_1) REFERENCES customer(id_country, id_location, id_user),
   FOREIGN KEY(id_platform, id_application) REFERENCES application(id_platform, id_application)
);

[escartefigue]

Bonjour Laurent

Dans cette nouvelle version de MCD, on a de nouveau des héritages disjoints (plusieurs triangles) de [customer] vers [user_table], de [license_owner] vers[user_table] et de [submitter] vers [user_table].
Ce faisant, une même personne peut appartenir à chaque sous-type simultanément.
Comme [customer] a perdu son attribut "organization" qui était présent dans votre réponse n°38, on peut désormais simplifier l'héritage pour ces deux sous-types et utiliser la modélisation que j'ai proposée dans ma réponse n° 37 et que je reproduis ici :
Pièce jointe 599253

Je rappelle l'intérêt des rôles RQ et ES ajoutés sur les "pattes" et qui permettent de suffixer les identifiants FK dans la table TI_Ticket dans laquelle on saura que la FK US_ident_ES identifie la personne qui a soumis le ticket (establish) et la FK US_ident_RQ identifie la personne qui a demandé le ticket (requester). Par défaut, on aura des noms comme US_ident et US_ident_1, ce qui n'est pas très parlant .

Dans votre réponse n°36, vous aviez dit

Je ne pense pas car même si un customer est toujours aussi un license_owner, les attributs sont différents.

Mais ici, ni l'un ni l'autre n'ont d'attribut. Du coup là aussi les deux ne font plus qu'un seul et on applique la logique ci-dessus.

Le modèle devient donc :
Pièce jointe 599255
La cardinalité mini zéro de US vers LI permet de savoir si une personne est "license_owner" ou pas, pas besoin de sous-type.

Quand à la relation reflexive (manage), si elle sert à connaître les liens hiérarchiques entre employés, pourquoi la restreindre aux employés qui sont détenteurs de licences ?

La présence d'un attribut "region" dans la table des pays mérite des explications.
S'il s'agit de régions telles que la Franche Comté ou l'Alsace pour la France, la Catalogne ou l'Andalousie pour l'Espagne, alors il y a plusieurs régions par pays et on ne peut donc pas positionner cet attribut ici.
S'il s'agit de régions du monde telles que l'Eurasie ou l'Amérique du nord, comme plusieurs pays sont dans cette même région du monde, il faut modéliser [PAYS] 1,1 --- (situer) --- 1,n [REGION]

Quel est le rôle de l'attribut "first_country" de l'entité-type [TICKET].
Vu qu'il existe une entité-type [COUNTRY], un lien entre [TICKET] et [COUNTRY] est à priori la bonne modélisation.