Discussion :

[laurentSc]

Merci ; je vais m'y atteler dans la journée (ou les jours qui viennent).

[laurentSc]

Bonjour,

j'ai pas mal avancé sur la rédaction des règles de gestion. Avant d'aller très loin, je souhaite valider ce que j'ai fait :

N°	Règle (FR)	Règle (EN)	Statut
R001	Une licence a 1 date d'activation (activatedate) et 0 ou 1 date de désactivation (deactivatedate)	A license has an activate date (activatedate) and 0 or 1 deactivate date (deactivatedate)
R002a	Un utilisateur possède 1 à N licence(s) chgt 1-N au lieu de 0-N	A user owns 1 to N license(s)
R002b	Une licence est possédée par un et un seul propriétaire de licence	A license is owned by one and only one license owner
R003	Un utilisateur a un identifiant (code SESA), un prénom et un nom	A user has an identifiant (SESA code), a firstname and a lastname
R004	Il y a 3 types d'utilisateurs : les propriétaires de licence (licenseowner), les émetteurs de ticket (submitter) et les demandeurs de ticket (customer)	There are 3 types of users: license owners (licenseowner), ticket submitters (submitter) and ticket requesters (customer)
R005a	Un propriétaire de licence a 0 ou 1 manager	A license owner has 0 or 1 manager
R005b	Un manager gère 1 à N propriétaire(s) de licence	A manager manages 1 to N license owner(s)
R006a	Un propriétaire de licence est joignable par 0 ou 1 adresse mail	A license owner is joinable by 0 or 1 email
R006b	Une adresse mail appartient à 1 et 1 seul propriétaire de licence	A license owner is joinable by 0 or 1 email
R007a	Un propriétaire de licence travaille dans 1 et 1 seule business unit	A license owner works in 1 and only 1 business unit
R007b	Une business unit contient 1 à N propriétaire(s) de licence	A business unit has 1 to N license owner(s)
R008a	Une entreprise contient 1 à N business unit(s)	A company contains 1 to N business unit(s)
R008b	Une business unit appartient à 1 et 1 seule entreprise	A business unit belongs to 1 and only 1 company

A noter que cet exercice m'a fait revenir sur le MCD et je lui ai encore apporté certaines modifs :



changement de la cardinalité sur la patte entre OWN_owner_license et OWN : 1-N au lieu de 0-N car un propriétaire de licence possède au moins une licence.

ajout d'une classe BU_businessunit (une entreprise possède plusieurs business units)

J'ai créé une 3e classe qui hérite de la classe US_user : dédoublement de la classe UST_user_ticket en 2 classes : CUS_customer_ticket et SUB_submitter_ticket ; en effet, auparavant ces 2 types d'utilisateur étaient reliés aux mêmes associations alors qu'il convient de les distinguer. Mais ce point-là, on y reviendra quand j'aurai écrit les règles de gestion correspondantes.

[escartefigue]

Bonjour,

C'est au donneur d'ordre de valider les règles de gestion, la liste des attributs de chaque type d'entité (comme R001 ou R003 par exemple) n'a pas besoin d'être gérée dans ce tableau.
Par contre, le dictionnaire de données peut faire la liste des attributs avec leur définition, leur type, leur longueur, leur caractère obligatoire ou non, leurs règles de contrôle, des exemples de contenu etc.

[laurentSc]

Par contre, le dictionnaire de données peut faire la liste des attributs avec leur définition, leur type, leur longueur, leur caractère obligatoire ou non, leurs règles de contrôle, des exemples de contenu etc.

OK, donc il faut aussi que je crée un dictionnaire de données (pas fait).

[laurentSc]

Bonsoir,

j'ai terminé d'écrire les règles de gestion :

N°	indice	Règle (FR)	Règle (EN)	Statut
R001	a	Un utilisateur possède 1 à N licence(s) chgt 1-N au lieu de 0-N	A user owns 1 to N license(s)
R001	b	Une licence est possédée par un et un seul propriétaire de licence	A license is owned by one and only one license owner
R002		Il y a 3 types d'utilisateurs : les propriétaires de licence (licenseowner), les émetteurs de ticket (submitter) et les demandeurs de ticket (customer)	There are 3 types of users: license owners (licenseowner), ticket submitters (submitter) and ticket requesters (customer)
R003	a	Un propriétaire de licence a 0 ou 1 manager	A license owner has 0 or 1 manager
R003	b	Un manager gère 1 à N propriétaire(s) de licence	A manager manages 1 to N license owner(s)
R004	a	Un propriétaire de licence est joignable par 0 ou 1 adresse mail	A license owner is joinable by 0 or 1 email
R004	b	Une adresse mail appartient à 1 et 1 seul propriétaire de licence	A license owner is joinable by 0 or 1 email
R005	a	Un propriétaire de licence travaille dans 1 et 1 seule entreprise	A license owner works in 1 and only 1 company
R005	b	Une entreprise contient 0 à N propriétaire(s) de licence	A company has 0 to N license owner(s)
R006	a	Une entreprise contient 1 à N business unit(s)	A company contains 1 to N business unit(s)
R006	b	Une business unit appartient à 1 et 1 seule entreprise	A business unit belongs to 1 and only 1 company
R007	a	Un propriétaire de licence réside sur 1 et 1 seul site	A license owner resides on 1 and only 1 location
R007	b	Un site accueille 0 à N propriétaire(s) de licence	A location hosts 0 to N license owner (s)
R008	a	Un site est situé dans 1 et 1 seul pays	A location is localized in 1 and only 1 country
R008	b	Un pays contient 0 à N site(s)	A country contains 0 to N location(s)
R009	a	Une licence concerne 1 et 1 seule application	A location is localized in 1 and only 1 country
R009	b	Une application est concernée par 0 à N licence(s)	An application is concerned by 0 to N license (s)
R010	a	Une application appartient à 1 et 1 seule plateforme	An application belongs to 1 and only 1 platform
R010	b	Une plateforme contient 1 à N applications	A platform contains 1 to N applications
R011	a	Un ticket est pris en charge par 1 et 1 seul Assign Group	A ticket is assigned to 1 and only 1 Assign Group /TD][TD]
R011	b	Un Assign Group prend en charge 0 à N ticket(s)	An Assign Group supports 0 to N ticket (s)
R012	a	Un ticket est soumis par 1 et 1 seul utilisateur-submitter	A ticket is submitted by 1 and only 1 user-submitter
R012	b	Un utilisateur-submitter soumet 1 à 1 N ticket(s)	A user-submitter submits 1 to N ticket (s)
R013	a	Un ticket concerne 1 et 1 seul produit	A ticket concerns 1 and 1 single product
R013	b	Un produit est concerné par 0 à N ticket(s)	A ticket is concerned by 0 to N ticket(s)
R014		Une application a un autre nom, dit "produit" qui désigne la même chose.	An application has another name, called "product" which designates the same thing.
R015	a	Un utilisateur-customer demande la création de 1 à N tickets	A user-customer requests the creation of 1 to N tickets
R015	b	La création d'1 et 1 seul ticket est demandée par un utilisateur-customer	The creation of 1 and 1 single ticket is requested by a user-customer

Voici la dernière version du MCD :



Vos critiques sont bienvenues. Notamment, dans certaines classes, j'ai inséré un attribut "identifiant" technique (qui ne correspond à aucune donnée réelle) et je me demande s'ils sont corrects.

Je me demande aussi si la règle chk_application est utile vu que les 2 attribus AP_application_name et AP_product_name sont NOT NULL et UNIQUE.

Enfin, il doit manquer au moins une règle pour indiquer que chaque application a un produit correspondant. Donc, ça reste à compléter. Mais déjà, que vaut le reste ?

[escartefigue]

Si produit et application sont "not null" alors la contrainte check n'a plus lieu d'être.

La règle R13b impose d'avoir au moins un ticket pour un produit... Pas très réaliste, d'ailleurs le MCD n'est pas conforme à cette règle et c'est certainement le MCD qui a raison.
Quoi qu'il en soit, les règles doivent être validées par le métier

[laurentSc]

Merci pour la confirmation. J'ai supprimé la règle chk_application.

J'ai aussi modifié mon post précédent pour la règle R0013b (et le fichier Excel qui est l'original et que je soumettrai à des futurs utilisateurs quand j'aurai fini les mises à jour et aussi le dictionnaire de données (en chantier, vu que je le fais après le MCD !))

[laurentSc]

Bonjour,

comme indiqué dans une autre discussion, j'ai remis des attributs identifiant dans les classes.
Une question concernant la classe FU_file_uploaded.

Voici le DDL de la création de la table SQL :

Code sql :

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

1
2
3
4
5
CREATE TABLE FU_file_uploaded(
   FU_ident INT UNSIGNED AUTO_INCREMENT,
   FU_hash VARCHAR(128) NOT NULL,
   PRIMARY KEY(FU_ident)
);

Celle-ci a un rôle technique : en effet, quand j'importe un fichier CSV, je commence par crypter (hashage md5) son contenu et vérifie s'il n'est pas déjà en bdd (la valeur hashée est déjà en bdd). J'ignore comment écrire une règle de gestion pour cela ni comment le modéliser. Pourtant, ça me semble nécessaire vu que ça se concrétise par une table SQL. Peut-on me guider ?

Voici la dernière version du MCD :

[escartefigue]

Une simple contrainte unique sur la colonne FU_hash.
Un index sera généré automatiquement pour vérifier la contrainte.

[laurentSc]

Merci du conseil. Je l'ai rajouté. Par contre, à mon avis, ça doit aussi apparaître dans les règles de gestion (si je veux les faire valider, il faut bien que ce point apparaisse) mais là, je ne sais pas comment...

[escartefigue]

Les valeurs possibles font parties des informations collectées dans le dictionnaire de données, ainsi que les contraintes d'unicité.

[laurentSc]

OK mais je n'ai pas mis cette donnée (nommée hash), car elle n'a rien à voir (il me semble) avec l'application. Je me trompe ?

[escartefigue]

Le dictionnaire de données recense tous les attributs de la base de données en éliminant les synonymes issus du vocabulaire métier.
On se fiche complètement à ce niveau de ce que qu'en fait ou pas l'application.

[laurentSc]

Bonjour,

je m'apprête à faire valider le MCD accompagné des règles de gestion et du dictionnaire de données. Par contre, autant y a aucune difficulté pour lire les règles de gestion et le dictionnaire de données, autant le formalisme utilisé dans le MCD est assez obscur pour quelqu'un qui ne connaît pas. Je suppose que vous êtes habitué à cette situation. Comment l'expliquez vous ? (ce qu'est une entité, une classe d'entités, une association, un lien entre une classe et une association, une cardinalité, un héritage entre des classes)

[escartefigue]

La lecture du MCD demande un apprentissage, mais n'est pas réservée aux informaticiens.
Son formalisme a vocation à être partagé par la MOA et la MOE.

En tout cas, le dictionnaire de données et les règles de gestion, sont clairement intelligibles par tout un chacun, il ne devrait y avoir aucune difficulté les concernant.

[laurentSc]

On verra bien la réaction, probablement demain (je l'ai montré à la personne qui pourra le communiquer à quelques futurs utilisateurs).