Discussion :

[fsmrel]

Bonsoir,

pas de location pour les NS 90 et comme elles bénéficient d'aucune opération (installation, désinstallation) à part sav en cas de panne, et qu'elles reviennent aux même porteurs, on a pas besoin d'historisation.

D’accord. Questions complémentaires :

Q1) Prévoyez-vous de prendre en compte les périodes d’indisponibilité en cas de panne d’une balise personnelle (statut = "SAV"), ou bien cela sort-il du champ de la modélisation ?

Q2) Une balise personnelle n’est jamais louée, et resterait donc la propriété du client jusqu’à la fin des temps. J’en conclue que l’ID DW qui lui a affecté n’est jamais récupéré, pas plus que la SIM, c’est » à la vie, à la mort ».

Qu’en est-il vraiment ?

Extrapolation concernant les balises achetées et montées sur des véhicules :

Q4) Si l’ID DW dw1 est affecté à la balise b1 achetée par le client c1, balise qui équipe le véhicule v1, je suppose que dw1 n’est pas récupérable plus tard pour une balise b2 (à moins peut-être que b2 n’appartienne elle aussi à c1 auquel cas dw1 pourrait être utilisé pour b2 si b1 n’est plus utilisée ?)

Q5) Qu’en est-il concernant la SIM s1 montée sur cette même balise b1 ?


Divers...

Vous dites ici (message #63) :

« Le client peut acheter ou louer des balises [...] Une fois qu'il a acheté les balises un ID spécifique leurs est affectés. »

Je suppose que par ID spécifique, vous sous-entendez qu’il s’agit d’un identifiant attribué par l’utilisateur, selon un format qui lui convient et dont il a la maîtrise. Qu'en est-il ?

Vous dites que ce système d'identification concerne les balises achetées, mais qu’en est-il des balises louées ?

Je voudrais également faire qu'on puisse gérer le antennes GSM, car même si elle n'ont pas d'identifiant elle ont la même gestion que les antennes GPS càd une antenne a1 sur balise b1 si a1 est out on peux la remplacer par une antenne a2 dans le stock dispo. On commence par leur donner un identifiant style GSM et une partie du code représentant la balise avec laquelle elle était venu, pour toujours connaître les antécédent car après pour la gestion technique c'est primordiale de savoir quel balise sur quel véhicule à quel date et quel sim sur quel balise à quel date et quand elle a été affectée à une autre balise....etc.

Généralement, lorsqu’une antenne tombe en panne, on prend dans le lot des antennes disponibles qui sont commandées seules sans balises (il existe un petit stock antennes) dans le cas où nous ne disposons pas d'antennes dans ce stock, on va prendre une antenne venue avec sa balise dont cette dernière est en stock dispo.

Que les antennes soient GPS ou GSM, l’utilisateur doit donc les suivre, en conséquence de quoi elles doivent être identifiées : une antenne GSM devrait aussi avoir un identifiant spécifique, connu de l’utilisateur et dont il aurait la maîtrise.

[jogodepau]

Bonjour,

D’accord. Questions complémentaires :

Q1) Prévoyez-vous de prendre en compte les périodes d’indisponibilité en cas de panne d’une balise personnelle (statut = "SAV"), ou bien cela sort-il du champ de la modélisation ?

Pour cette question je vais voir. Je vous répondrais plus tard.

Q2) Une balise personnelle n’est jamais louée, et resterait donc la propriété du client jusqu’à la fin des temps. J’en conclue que l’ID DW qui lui a affecté n’est jamais récupéré, pas plus que la SIM, c’est » à la vie, à la mort ».

Qu’en est-il vraiment ?

Oui c'est le cas pour les balises personnelle, par contre si en fin de vie de la balise, le client ne veut plus en racheter une autre si on ne peut réparer la sienne dans ce cas l'ID DW est récupéré (possibilité d'une mise en quarantaine avant affectation à une autre balise, je vérifie).

Pour la SIM, en faite les SIM sont et reste toujours la propriété de la société, la société vend pas la SIM mais le service de cette dernière donc si une balise n'est plus utilisée et que le client décide de ne pas en reprendre une autre, on récupère la SIM.

Extrapolation concernant les balises achetées et montées sur des véhicules :

Q4) Si l’ID DW dw1 est affecté à la balise b1 achetée par le client c1, balise qui équipe le véhicule v1, je suppose que dw1 n’est pas récupérable plus tard pour une balise b2 (à moins peut-être que b2 n’appartienne elle aussi à c1 auquel cas dw1 pourrait être utilisé pour b2 si b1 n’est plus utilisée ?)

Je m'assure de la réponse.

Q5) Qu’en est-il concernant la SIM s1 montée sur cette même balise b1 ?

La SIM est attribuée à b1 mise sur v1 si b1 est désinstallée de v1 pour que b2 soit installée sur v1 alors on va attribuer la SIM de b1 à b2 (elle suit le véhicule car elle contient son historique) sinon cette SIM entre en quarantaine pendant 1 mois après cela on peut la mettre sur n'importe quel autre véhicule (peu importe le client).

Divers...

Vous dites ici (message #63) :

« Le client peut acheter ou louer des balises [...] Une fois qu'il a acheté les balises un ID spécifique leurs est affectés. »

Je suppose que par ID spécifique, vous sous-entendez qu’il s’agit d’un identifiant attribué par l’utilisateur, selon un format qui lui convient et dont il a la maîtrise. Qu'en est-il ?

L'ID spécifique, est l'immatriculation dans la majorité des cas, si on l'a dés le début, sinon c'est un chiffre provisoire en attendant l'immatriculation, ou c'est une nomination selon l'envie du client genre type véhicule ou type véhicule+un chiffre...etc.

Vous dites que ce système d'identification concerne les balises achetées, mais qu’en est-il des balises louées ?

C'est également le cas pour les balises louées.

Que les antennes soient GPS ou GSM, l’utilisateur doit donc les suivre, en conséquence de quoi elles doivent être identifiées : une antenne GSM devrait aussi avoir un identifiant spécifique, connu de l’utilisateur et dont il aurait la maîtrise.

Oui, l'antenne GPS porte identifiant qu'on peut utiliser (lui affecter), cela serait aussi bien si on affecte un identifiant à l'antenne GSM, qui elle n'en porte pas.

a+

[jogodepau]

Bonjour,

Q1) Prévoyez-vous de prendre en compte les périodes d’indisponibilité en cas de panne d’une balise personnelle (statut = "SAV"), ou bien cela sort-il du champ de la modélisation ?

On voudrais bien garder une trace de la date de désinstallation, date départ en sav, dans le cas ou elle a été remplacez par une autre ou non.

Q2) Une balise personnelle n’est jamais louée, et resterait donc la propriété du client jusqu’à la fin des temps. J’en conclue que l’ID DW qui lui a affecté n’est jamais récupéré, pas plus que la SIM, c’est » à la vie, à la mort ».

Oui c'est le cas pour les balises personnelle, par contre si en fin de vie de la balise, le client ne veut plus en racheter une autre si on ne peut réparer la sienne dans ce cas l'ID DW est récupéré. l'ID n'est pas mis en quarantaine et est réutilisable dans les heures qui suivent.On l'utilise pour n'importe quelle balise et n'importe quel client.(puisque sa balise n'est plus utilisée et est supprimée de la plate forme)

Extrapolation concernant les balises achetées et montées sur des véhicules :

Q4) Si l’ID DW dw1 est affecté à la balise b1 achetée par le client c1, balise qui équipe le véhicule v1, je suppose que dw1 n’est pas récupérable plus tard pour une balise b2 (à moins peut-être que b2 n’appartienne elle aussi à c1 auquel cas dw1 pourrait être utilisé pour b2 si b1 n’est plus utilisée ?)

Si le mobile v1 est concerné par une autre balise L'ID dw1 lui es affecté sinon si le mobile ne reçoit plus de balise alors il sera supprimé de la plate forme et donc on récupère l'id dw1 pour l'affecter à n'importe quel autre véhicule pour n'importe quel client dans les heure qui suivent. (en fait l’affection de l'ID DW commence quand le véhicule est déclaré sur la plate forme et fini quand il est supprimé de celle-ci)

Bonne journée à vous.

[fsmrel]

Bonsoir,


Pour essayer de se mettre d’accord au sujet des balises personnelles, avant d’attaquer les balises de type véhicule...

Q1) Prévoyez-vous de prendre en compte les périodes d’indisponibilité en cas de panne d’une balise personnelle (statut = "SAV"), ou bien cela sort-il du champ de la modélisation ?

On voudrait bien garder une trace de la date de désinstallation, date départ en sav, dans le cas ou elle a été remplacée par une autre ou non.

Qu’entendez-vous par désinstallation ? C’est une étape avant le départ en SAV ?
Dans le MLD ci-dessous, j’ai supposé qu’un passage en SAV n’impliquait pas une désinstallation, donc que les deux types d’événements étaient indépendants. A vous de préciser si, oui ou non, un passage en SAV est précédé d'une désinstallation. La table BALISE_PERSO_DESINSTAL permet de savoir si une désinstallation est en cours et si oui depuis quand. La table BALISE_PERSO_DESINSTAL_HISTO permet de savoir quelles sont les périodes (début, fin) pendant lesquelles une balise personnelle a été désinstallée. Les tables BALISE_PERSO_SAV et BALISE_PERSO_SAV_HISTO fonctionnent suivant le même principe. A vous de voir s’il faut tailler dans tout ça.

La table MODELE_BALISE permet de préciser quels sont les modèles de balises personnelles, dans la mesure où il n’y aurait pas que la NS90.

La table SIM_AFFECTEE_BALISE_PERSO n’est pas strictement nécessaire, elle est plus là pour faire le pendant de son homologue des SIM affectées à des balises de type véhicule. Il est donc possible de connecter directement la table SIM et la table BALISE_PERSO_AFFECTATION, laquelle comporte notamment l’ID DW affecté à la balise (attribut DwIdFour).

Pour connaître les ID DW affectés, il suffit de consulter la table BALISE_PERSO_AFFECTATION (et donc, par différence, connaître les ID DW disponibles).


Une suggestion de MLD (aménageable) pour les balises personnelles :

[jogodepau]

Bonjour,

Qu’entendez-vous par désinstallation ? C’est une étape avant le départ en SAV ?

En fin la désinstallation par abus de langage, c'est l’enlèvement de la balise de chez la personne qui la porte.
Oui, c'est une étape avant le départ en SAV.

Ok, pour le reste, je regarde ça de plus prêt.

Merci et bonne journée à vous.

[fsmrel]

Bonsoir,


Avant de tenter une approche de l’historisation, est-ce que le MLD des opérations ci-dessous vous convient ?

Je suis parti du principe qu’une opération donnée ne concernait pas simultanément tous les objets parties prenantes : balise, SIM, antenne, sauf par exemple dans le cas de l’installation d’une balise sur un véhicule ou de sa désinstallation.

Procéder à une installation pour la balise b1 revient à établir un lien entre celle-ci et une SIM, disons s1 (la table OPER_SIM sert à cela), établir un lien entre b1 et une antenne GPS (la table OPER_GPS sert à cela) et un lien avec une antenne GSM (la table OPER_GSM sert à cela).

Si l’on procède à une installation, celle-ci est considérée comme complète (l’ID DW peut être attribué) quand la jointure des tables OPER_SIM, OPER_GPS et OPER_GSM sur les attributs BaliseId et OperationId fournit un résultat non vide.

Procéder à une désinstallation de la balise b1 revient à supprimer les liens précédents. On sait que la SIM s1 passe dans le stock des disponibles parce que la paire <b1, s1> n’appartient plus à la table OPER_SIM. Même principe pour les antennes. On peut partir de l’exploitation de l’attribut TypeOperId de la table OPERATION pour savoir si un objet pose problème (à été placé en SAV, en quarantaine, etc.)

Une permutation revient dans son principe à effectuer deux opérations, une désinstallation, puis une installation.

Remplacer la SIM s1 par la SIM s2 pour la balise s1 revient à remplacer la paire <b1, s1> par la paire <b1, s2> dans la table OPER_SIM.

Etc.



Ce MLD est donc focalisé sur les opérations. Il est évident que l’on sait quel est le véhicule concerné par une opération, par le lien existant entre BALISE_VEHICULE et VEHICULE.

Dans un de vos messages (#72), vous évoquiez le cas de balises « à batterie » (sans antennes) : leur prise en compte ne devrait pas poser de problème.

J'attends vos commentaires, à savoir si l'on garde, si l'on efface et recommence tout...

A bientôt

[fsmrel]

Bonjour,

A noter que si vous voulez savoir quelles sont les balises impliquées dans une opération de permutation, vous pourriez utiliser la représentation suivante (une seule opération au lieu de deux) :


Dans la table OPERATION on fait mention de la 1re balise et dans la table PERMUTATION on établit la relation entre la 1re et la 2e balise.

[jogodepau]

Bonjour,

J'attends vos commentaires, à savoir si l'on garde, si l'on efface et recommence tout...

A bientôt

Pour le moment j'ai aucuns commentaires, tout est OK.
Juste une question pour la relation balise véhicule et véhicule c'est une relation 1--1 n'es ce pas?

Merci.

[fsmrel]

Bonjour,

Juste une question, pour la relation balise véhicule et véhicule c'est une relation 1--1 n'est-ce pas?

En quelque sorte...

Une balise étant destinée à équiper soit un véhicule, soit une personne, la configuration initiale est la suivante, reflétant une relation de spécialisation (cf. diagramme ci-dessus) :



Mais une balise de type véhicule est soit affectée à un véhicule, soit disponible.

Je vous propose le scénario suivant:

Lors de son acquisition par votre entreprise, la balise b1 fait partie du stock disponible (en l’occurrence, elle fait l’objet d’une ligne dans la table BALISE_DISPONIBLE_V). Après telle et telle opération (bricolage d’antennes, affectation d’une SIM, tests divers) effectuées par un technicien, cette balise est réputée opérationnelle, affectée à un véhicule et dotée d’un ID DW : elle sort du stock disponible (elle fait maintenant l’objet d’une ligne dans la table BALISE_AFFECTEE_V, tandis qu’elle est effacée de la table BALISE_DISPONIBLE_V) et — si cela offre un intérêt — elle est historisée comme ayant fait partie du stock des balises disponibles pendant telle période.




Dans le diagramme ci-dessus, une balise affectée à un véhicule fait l’objet d’une ligne dans la table BALISE_AFFECTEE_V, tandis que si elle est disponible, elle fait l’objet d’une ligne dans la table BALISE_DISPONIBLE_V. Cette 2e table peut disparaître si elle n'est pas dotée de colonnes spécifiques, auquel cas une balise disponible est une balise qui figure ne figure pas dans la table BALISE_AFFECTEE_V.

La table BALISE_STATUT permet de savoir si pour une balise il n’y a rien à signaler (statut OK), ou si un événement particulier à eu lieu (SAV, ...)
L’attribut BaliseStatutDepuis permet de savoir depuis quand une balise a son statut actuel (OK, SAV, ...)

A noter que dans la table BALISE_STATUT, les statuts « Balise affectée » et « Balise disponible » ne sont pas à prendre en compte, car ils seraient redondants : on sait si une balise est affectée parce qu’elle fait l’objet d’une ligne dans la table BALISE_AFFECTEE_V (même principe pour une balise disponible).

Table BALISE_AFFECTEE_V :

Pour chaque balise affectée à un véhicule, on sait depuis quand la balise a été affectée (attribut VehiculeDepuis), ce qui correspond à la date de mise sur plate-forme. Concernant l’ID DW on part du principe que sa date d’affectation est celle de l’affectation de la balise au véhicule (attribut VehiculeDepuis).

Remarques :
La date d’affectation de la balise (attribut VehiculeDepuis) peut être redondant avec la date d’opération de l’installation (ou on verra plus tard, avec la date de début de la période en cas d’historisation). A vous de voir si vous conservez ou non l’attribut VehiculeDepuis. Si on le conserve, je note que cela permet une certaine souplesse : pouvoir avoir une date d’installation postérieure à la date de dernière opération d’installation, ne pas avoir à effectuer toutes les opérations en même temps...
La date d’affectation de la balise (attribut VehiculeDepuis) n’est pas non plus systématiquement redondante avec la date du statut de la balise (attribut BaliseStatutDepuis) : que fait-on par exemple si la balise part en SAV ?



Ce scénario vous paraît-il acceptable ? On peut modifier, varier comme bon vous semble. Réfléchissez notamment au cas des permutations.

[jogodepau]

Bonjour,

Bonjour,


Remarques :
La date d’affectation de la balise (attribut VehiculeDepuis) peut être redondant avec la date d’opération de l’installation (ou on verra plus tard, avec la date de début de la période en cas d’historisation). A vous de voir si vous conservez ou non l’attribut VehiculeDepuis. Si on le conserve, je note que cela permet une certaine souplesse : pouvoir avoir une date d’installation postérieure à la date de dernière opération d’installation, ne pas avoir à effectuer toutes les opérations en même temps...
La date d’affectation de la balise (attribut VehiculeDepuis) n’est pas non plus systématiquement redondante avec la date du statut de la balise (attribut BaliseStatutDepuis) : que fait-on par exemple si la balise part en SAV ?

Ce scénario vous paraît-il acceptable ? On peut modifier, varier comme bon vous semble. Réfléchissez notamment au cas des permutations.

Va pour garder l’attribut VehiculeDepuis, si cela apporte plus de souplesse.

Pour la question comment faire quand on a un envoie SAV d'une balise, en principe cela ne pose pas de problèmes.

Un départ en SAV nécessite une désinstallation au préalable et éventuellement on remplace la balise a la demande du client en attendant le retour du SAV; donc B1 installez sur v1 VehiculeDepuis=20/08/2010 , B1 désinstallez de v1 opérationDate=03/07/2011, envoie en SAV BaliseStatutDepuis= opérationDate ou OpérationDate+1

dans le cas ou en remplace la balsie, nous aurons B2 installez sur v1 et généralement cela se fait dans la même journée de désinstallation de B1, ce qui donne vehiculeDate=OpérationDate=03/07/2011.

Pour la permutation j'essai tout les cas de figures avant de vous en dire plus.
En ce qui concerne les attributs de ma table permutation, j'ai BaliseId, stockId, materielId, opérationId en clé primaire qui découlent de la table opération et d'un autre côté j'ai Balise2Id, stockId, MaterielsId, clientId, compteId, vehiculeId qui découlent de la table balise véhicule en clé secondaire, es ce que cela est-il correct ou faut-il changer les liens.

Je vous joint ici le MLD après avoir avoir assemblé tout les morceaux.

Merci.

[fsmrel]

Bonsoir,

Je ne vous oublie pas. Je devrais vous part de mes remarques dans la journée.

A bientôt

[fsmrel]

Bonjour,


Table MATERIEL

Selon l’association établie entre la table MATERIEL et les tables BALISE, ANTENNE et SIM, un matériel donné peut être associé à (composé de ?) plusieurs balises, plusieurs antennes et plusieurs SIM. Pourriez-vous expliquer de quoi il en retourne vraiment ? Qu’est-ce qu’un matériel ? Illustrer au besoin par l’exemple.


Table STOCK

Supposons qu’une balise soit affectée à un véhicule. Elle figure dans la table BALISE_AFFECTEE_V, mais figure-t-elle simultanément dans la table STOCK ? Si oui, il va y avoir des problèmes de redondance à régler.


Table BALISE_VEHICULE

Le sens de cette table est seulement de signifier que la balise b1 est destinée à équiper un véhicule, autrement dit qu’elle n’est pas une balise personnelle. Ainsi, la balise b1 n’est pas forcément encore affectée et les attributs servant à identifier les véhicules (ClientId, CompteId, VehiculeId) n’ont donc pas à figurer dans l’en-tête de la table BALISE_VEHICULE.


Table BALISE_DISPONIBLE_V

Cette table (qui éventuellement peut disparaître, elle est là seulement pour montrer la dichotomie balise affectée ou non) est porteuse des attributs servant à identifier les véhicules (ClientId, CompteId, VehiculeId), alors que justement, y figurent les balises disponibles : ces attributs doivent disparaître.


Table BALISE_AFFECTEE_V

Les attributs ClientId, CompteId, VehiculeId sont présents deux fois, ce qui voudrait dire qu’une balise est affectée à deux véhicules, ce dont on peut douter...

Par ailleurs, si une balise est affectée à un véhicule, ça n’est pas forcément « à la vie à la mort », elle n’est donc pas identifiée relativement au véhicule (cf. image de droite ci-dessous).

Comme nous n’avons pas encore débattu de l’entité-type MATERIEL, je gomme les attributs MaterielId et StockId.



Il y a encore pas mal de mises au point à faire, mais nous avons déjà de quoi discuter...

N.B. Au passage, renommez l’attribut ClinetId en ClientId.

Bon courage

[fsmrel]

Bonjour à nouveau,


Indépendamment des remarques précédentes :

Votre MLD est très esthétique, mais j’ai du mal à lire quand il y a une multiplicité d’objets représentés simultanément (évidemment vous n’en êtes pas au point du genre de diagramme qu’il m’arrive d’avoir à remettre à plat...)

Vous savez qu’avec MySQL Workbench vous pouvez produire des « vues » à partir du MLD. Une piqûre de rappel si nécessaire :

A titre d’exemple, j’ai défini comme vous un MLD global (appelé Global) puis les sous-MLD Opérations, etc. :

Si je veux créer une vue supplémentaire, je clique sur l’icône Add Diagram, et Workbench me propose un diagramme vide (EER Diagram) :





Si je veux une vue pour les balises, je renomme « EER Diagram » en « Balises » et je « drag-drop » les noms des tables qui figurent au catalogue (Catalog Tree) :




Autres remarques :

1) Rappel : renommer l’attribut ClinetId en ClientId.

2) Le nom d’une table doit être au singulier : BALISE et non pas BALISES. En effet, un en-tête de table est l’image d’un prédicat. Prenons l’exemple de la table Opération :



Son prédicat est le suivant :

La balise BaliseId a subi l’opération OperationId à la date OperationDate, cette opération a été effectuée par le technicien TechnicienId et elle était du type TypeOperId.

Les propositions accompagnant le prédicat (qui est une proposition-type) sont les suivantes :

La balise b1 a subi l’opération o1 à la date d1, elle a été effectuée par le technicien t1 et elle était du type ty1 ;
La balise b2 a subi l’opération o2 à la date d2, elle a été effectuée par le technicien t2 et elle était du type ty2 ;
Etc.

Et non pas :

La balise b1 a subi les opérations o1 à la date d1, elles ont été effectuées par le technicien t1 et elles étaient du type ty1 ;
...

[jogodepau]

Bonjour,

Désolé pour le retard.

Table MATERIEL et Table STOCK

Selon l’association établie entre la table MATERIEL et les tables BALISE, ANTENNE et SIM, un matériel donné peut être associé à (composé de ?) plusieurs balises, plusieurs antennes et plusieurs SIM. Pourriez-vous expliquer de quoi il en retourne vraiment ? Qu’est-ce qu’un matériel ? Illustrer au besoin par l’exemple.

En fait, j 'ai créé cette table on me disant, puisqu'on a beaucoup de matériels (balise, sim, antennes et de temps en temps des boîtiers étanches et autres) et que chaque matériels a son propre stock ou plusieurs stock différents exemple balise doit avoir son code matériel et chaque balise fait partie d'un stock spécifique, stock client, stock sav....etc.

Table STOCK

Supposons qu’une balise soit affectée à un véhicule. Elle figure dans la table BALISE_AFFECTEE_V, mais figure-t-elle simultanément dans la table STOCK ? Si oui, il va y avoir des problèmes de redondance à régler.

quand j'ai pensé à cette modélisation je m'étais dis que chaque fois qu'une balise passée d'un stock B a un stock B on faisait de tel sorte que cette dernière n'y figure plus dans A. je suppose que j'ai tout faux. (je résonne programmation!)

Donc les deux tables n'ont aucune utilité?

Je réarrange le schéma.

Merci beaucoup.

[fsmrel]

Bonsoir,

En fait, j 'ai créé cette table on me disant, puisqu'on a beaucoup de matériels (balise, sim, antennes et de temps en temps des boîtiers étanches et autres)

Je comprends. Mais on s’intéresse pour le moment aux matériels essentiels, à savoir les balises, les SIM et les antennes. Pour les boitiers étanches les antennes à batteries et autres inventions (compte non tenu de ce qui sortira dans années à venir ), il est préférable de différer, sinon si on prend tout en même temps, à tous les coups on partira dans le mur...

Je réarrange le schéma.

D’accord. Mais sans précipitation, même si d'aventure il y avait le feu au lac...

[jogodepau]

Bonjour,

J'ai refait le MLD, voilà le résultat.

Je vous ai mis trois parties de MLD. Je joindrais le MLD globale ainsi que le code après que vous ayez, vu les MLD, pas assez d'espace.

Merci de me donner votre avis.

Bon week-end à vous.

[fsmrel]

Bonsoir,



Ça a bougé !

Je vous ai mis trois parties de MLD. Je joindrai le MLD global.

Je préfère les vues, Le MLD global serait bien pénible à lire.


Dans votre dernière version, la relation entre VEHICULE et COMPTE a carrément disparu. Que se passe-t-il ?


Pourtant, vous aviez écrit :

un véhicule n'appartient qu'à un seul client c'est sûr

Et par ailleurs, un véhicule à instant T est rattaché à seul compte du client.

Il y a donc quelque chose qui ne va pas...


A l’époque, l’entité-type VEHICULE était identifiée relativement à l’entité-type COMPTE :


L’identification de VEHICULE peut devenir absolue au cas où les véhicules pourraient changer de propriétaire (client) tout en gardant leur immatriculation, mais de là à rompre les liens... En effet, deux clients ne peuvent quand même pas être propriétaires en même temps d’un même véhicule (sauf nouvelles règles qui n’ont pas été écrites jusqu’ici...)

Pour le moment, je considère qu’à un instant T un véhicule est en relation avec un seul compte, quitte à utiliser l’identification absolue, par exemple :




Dans un message précédent, j’avais fait apparaître une relation entre MODELE_BALISE et BALISE_PERSO_AFFECTATION, mais cette relation est entre MODELE_BALISE et BALISE.

Après corrections et avant de traiter des historiques, le MLD vous permet-il de répondre complètement aux autres besoins de l’application ?

[jogodepau]

Bonjour,

Un peu!

Dans votre dernière version, la relation entre VEHICULE et COMPTE a carrément disparu. Que se passe-t-il ?

C'est un oubli de ma part!!

l’entité-type VEHICULE était identifiée relativement à l’entité-type COMPTE :

L’identification de VEHICULE peut devenir absolue au cas où les véhicules pourraient changer de propriétaire (client) tout en gardant leur immatriculation, mais de là à rompre les liens... En effet, deux clients ne peuvent quand même pas être propriétaires en même temps d’un même véhicule (sauf nouvelles règles qui n’ont pas été écrites jusqu’ici...)

Pour le moment, je considère qu’à un instant T un véhicule est en relation avec un seul compte, quitte à utiliser l’identification absolue, par exemple :

Je préfère qu'on garde la relation relative, entre la table véhicule et la table compte, pour la simple raison que chaque véhicule doit faire référence au compte auquel il appartient et qu'un véhicule peut changer de service mais jamais de client.

j’avais fait apparaître une relation entre MODELE_BALISE et BALISE_PERSO_AFFECTATION, mais cette relation est entre MODELE_BALISE et BALISE.

Je ne comprend pas, j'ai effectivement commis une erreur sur l’appellation BALISE_PERSO_AFFECTEE au lieu de BALISE_PERSO_AFFECTATION (j'ai cru que BALISE_PERSO_AFFECTEE=BALISE_PERSO_AFFECTATION) mais es-ce que vous ne vouliez pas dire qu'il manque la table BALISE_PERSO_AFFECTEE
comme pour BALISE_AFFECTEE_V?
Si c'est le cas alors je n'est pas compris quelque chose ou es-ce que cela voudrais dire que BALISE_PERSO_AFFECTATION remplace operation dans le cas des véhicules?

Après corrections et avant de traiter des historiques, le MLD vous permet-il de répondre complètement aux autres besoins de l’application ?

Pour le moment ok pour ce que j'ai compris de la chose mais comme la responsable vient de reprendre son poste, je vais en discuter avec elle si jamais elle a d'autres changement ou rajout à effectuer.

Je vous remercie encore pour tout

PS: je joint le MLD pour le lien entre véhicule et compte ainsi que la rectification de la table BALISE_PERSO_AFFECTATION.

[jogodepau]

Re:

Un truc dont je n'avais pas posé une question quand on effectue une permutation celle-ci est effectuée sur une balise déjà installé sur un véhicule et une opération concerne forcément un véhicule, donc le liens qui est actuellement entre table BALISE_VEHICULE et OPERATION devrait -être netre BALISE8AFFECTEE_V et OPERATION AINSI QUE PERMUTATION de ce que j'ai compris BALISE_VEHICULE fait référence au balise dans le stock non? (ou je mélange encore une fois!)

Merci .

[fsmrel]

Bonsoir,

Je préfère qu'on garde la relation relative, entre la table véhicule et la table compte, pour la simple raison que chaque véhicule doit faire référence au compte auquel il appartient et qu'un véhicule peut changer de service mais jamais de client.

La relation entre BALISE_AFFECTEE_V et COMPTE est redondante et doit disparaître : si l’on veut connaître le compte pour une balise, il suffit d’effectuer une jointure entre BALISE_AFFECTEE_V et VEHICULE. Par ailleurs, en cas de changement du compte auquel fait référence le véhicule, ce changement serait à répercuter dans BALISE_AFFECTEE_V comme il l’est précisé ci-dessous.

En effet, d'après ce que j'ai compris, chaque service fait l'objet d'un compte et quand un véhicule change de service, il change donc de compte. Mais la composition de la clé primaire de VEHICULE, à savoir le triplet {ClientId, CompteId, VehiculeId} revient à dire d’un point de vue sémantique qu’un véhicule ne change pas de compte, même si techniquement ce triplet est légal. Le problème est que l’attribut CompteId figurant dans la clé primaire de COMPTE, il fera partie des attributs de BALISE_AFFECTEE_V (clé étrangère oblige) : quand un véhicule change de service, la modification doit être répercutée dans BALISE_AFFECTEE_V.




En fait, on peut identifier VEHICULE relativement à CLIENT en se contentant de prendre pour clé primaire le couple {ClientId, VehiculeId}, tandis que le couple {ClientId, CompteId} est clé étrangère relativement à COMPTE. En conséquence, l’attribut CompteId disparaît de facto de BALISE_AFFECTEE_V et cette table n’est plus concernée quand un véhicule change de compte.





Je regarderai demain l’embrouille des balises personnelles et celle des permutations...