Hugues,
Désolé d'avoir été aussi lent, mais le temps me manque.
Pour commencer avec un embryon de maquette, j'ai concocté ce qui suit. Bien des choses sortent
purement de mon chapeau, mais ça pose un socle sur lequel cogiter pour élaborer une structure
qui tienne la route, aujourd'hui et demain.
A) Les tables
a) une table des lignes
b) une table des stations
c) une table des postes
d) une table des fournisseurs
e) une table de
description des équipements (qu'ils soient disponibles ou pas)
f) une table du parc des équipements physiquement disponibles
g) une table de demandeurs
h) une table de maintenance
i) une table hors données applicatives pour la configuration et intendance interne
j) une table des anomalies relevées par le soft
B) Un peu plus en détail
NOTE : j'ai fait des copier/coller décalés dans le temps, donc il pourrait exister des
différences entre le SQL qui figure ici et la base jointe, qui seule fait autorité.
a) Rien de spécial
CREATE TABLE "Lignes" (
"LigneId" INTEGER NOT NULL PRIMARY KEY,
"LigneNom" CHAR NOT NULL);
b) RAS non plus, sauf une chose : comprendre station au sens station de métro !
L'analogie étant qu'une station de métro a parfois des correspondances sur plusieurs lignes.
Si on convient d'un rdv, il faut préciser la station ET la ligne (et le quai pour le métro).
Plus bas, le regroupement de ces deux informations est appellé un poste.
CREATE TABLE "Stations" (
"StationId" INTEGER NOT NULL PRIMARY KEY,
"StationNom" CHAR NOT NULL);
J'ai ajouté à ça une colonne temporaire StationNom5 avec des noms de stations compatibles avec un tri.
c) Petite subtilité donc : on lie un poste à la station et à la ligne. Par la suite on verra qu'on
peut ainsi différencier les postes selon leur ligne car il n'est pas évident qu'une station
commune à plusieurs lignes utilise tout son équipement pour chaque ligne à laquelle elle appartient.
Cette notion de poste est donc plus précise et plus facile à manipuler que le couple {ligne, station}.
Chaque poste est simplement décrit par son Id propre et les clés étrangères vers sa ligne et sa station.
CREATE TABLE "Postes" (
"PosteId" INTEGER NOT NULL PRIMARY KEY,
"LigneId" INTEGER NOT NULL CONSTRAINT "fkPostesLigne" REFERENCES "Lignes"("LigneId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"StationId" INTEGER NOT NULL CONSTRAINT "fkPostesStation" REFERENCES "Stations"("StationId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED);
d) RAS de spécial, on va y mettre ce qu'il faudra (nom, adresse, contacts technique, SAV et commercial, ...)
CREATE TABLE "Fournisseurs" (
"FournId" INTEGER NOT NULL PRIMARY KEY,
"FournNom" CHAR NOT NULL);
e) Ah, les équipements ! Ici on stocke leur définition mais pas leur identité matérielle.
Outre un Id, une référence fournisseur, une description, une Id fournisseur, la version, je mets
une colonne Classe qui peut contenir A S ou M pour indiquer si l'équipement est Automatique (robot)
Semi-automatique (machine à sertir) ou Manuel (marteau). Je n'ai aucune idée de l'intérêt en pratique
pour ton contexte mais c'est une notion qui peut peut-être s'avérer utile ou servir de modèle à une
toute autre idée. C'est plus pour montrer comment ça peut marcher avec une contrainte d'entrée.
Si ça a un sens, je pense qu'il faudrait ajouter une classe O pour outillage, mais bon.
une Id de l'équipement parent : c'est l'Id du bras pour un outillage de bras et l'Id du robot pour un
bras et c'est NULL pour un tournevis comme pour un robot. Avec cette colonne on peut donc indiquer
ainsi que l'objet ne peut avoir d'existence sur un poste que comme partie d'un ensemble plus vaste.
Par contre ce mécanisme ne permet pas tel quel de lister par exemple tout ce que doit comporter un
robot de soudure par points, par exemple. On verra ce qui s'avère nécessaire.
On peut loger un chemin complet sur une photo (il n'est pas judicieux de placer des paquets d'images
dans la base, un sous-répertoire sera bien plus adequat).
CREATE TABLE "Equipements" (
"EquipId" INTEGER NOT NULL PRIMARY KEY,
"Reference" CHAR NOT NULL,
"Description" CHAR COLLATE NOCASE DEFAULT '',
"FournId" INTEGER CONSTRAINT "fkEquipementFournisseur" REFERENCES "Fournisseurs"("FournId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"Version" CHAR DEFAULT '',
"Classe" CHAR NOT NULL DEFAULT 'A',
"ParentId" INTEGER CONSTRAINT "fkEquipParent" REFERENCES "Equipements"("EquipId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"Photo" CHAR NOT NULL DEFAULT '',
CONSTRAINT "ckEquipClasse" CHECK(EquipClasse in ('A', 'S', 'M')));
f) Notre parc physique. On y trouve normalement tout ce qui est soit installé sur un poste soit
en stock (posteId à 0). Chaque équipement est assigné à un poste ou au stock, avec son
numéro de série le cas échéant. On peut par exemple convenir que le matos hors d'usage soit assigné
à un poste fictif lié à une ligne et une station fictives 'Atelier de réparation'. On peut en
créer plusieurs selon qu'on prévoit une réparation sur place dans un atelier d'électricité, de tests,
de mécanique, d'entretien, ... ou un retour chez le fournisseur. C'est ce que j'ai finalement créé,
quitte à scratcher si ça n'a vraiment pas de sens potentiel.
CREATE TABLE "Parc" (
"ParcId" INTEGER NOT NULL PRIMARY KEY,
"ParcEquipId" INTEGER NOT NULL CONSTRAINT "fpParcEquip" REFERENCES "Equipements"("EquipId") ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"ParcSerial" CHAR NOT NULL DEFAULT '',
"ParcPosteId" INTEGER CONSTRAINT "fkParcPoste" REFERENCES "Postes"("PosteId") ON DELETE SET NULL ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED);
g) Qui demande d'intervenir ? C'est ici que ça se passe.
Table des personnes/services habilités à requérir une intervention. J'ai mis des colonnes au pif.
CREATE TABLE "Demandeurs" (
"DemandeurId" INTEGER NOT NULL PRIMARY KEY,
"DemandeurNom" CHAR NOT NULL DEFAULT '',
"DemandeurService" CHAR NOT NULL DEFAULT '',
"DemandeurFonction" CHAR NOT NULL DEFAULT '');
h) La maintenance de tout ça.
Outre le sempiternel Id, une date d'intervention, la référence à un poste, celle à un demandeur (par Id
car pas question de mettre des noms ici et ça permet d'éviter que le personnel de ménage ne soit à
l'origine d'un remplacement de robot).
J'ai pifométré la possibilité d'enregistrer l'heure de début et de fin d'intervention, ainsi bien sûr
que les Ids de l'équipement déposé (ou Null pour une nouvelle installation) et de celui qui a pris sa
place (ou NULL si dépose seule). Un mémo de commentaire complète la table.
On peut aussi y stocker la planification des interventions à réaliser, éventuellement avec une colonne en
indiquant l'urgence ou autre détail.
CREATE TABLE "Maintenance" (
"MaintId" INTEGER NOT NULL PRIMARY KEY,
"Date" CHAR NOT NULL DEFAULT (date('now')),
"PosteId" INTEGER NOT NULL CONSTRAINT "fkMaintPoste" REFERENCES "Postes"("PosteId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"DemandeurId" INTEGER NOT NULL CONSTRAINT "fkMaintDemandeur" REFERENCES "Demandeurs"("DemandeurId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"HeureDebut" CHAR DEFAULT (time('now')),
"ParcIdOut" INTEGER NOT NULL CONSTRAINT "fkMaintParcOut" REFERENCES "Parc"("ParcId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"ParcIdIn" INTEGER NOT NULL CONSTRAINT "fkMaintParcIn" REFERENCES "Parc"("ParcId") ON DELETE RESTRICT ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
"HeureFin" CHAR DEFAULT (time('now')),
"Comment" MEMO DEFAULT '');
i) On va stocker ici tout un tas de paramètres utiles un peu comme dans un fichier .INI
L'appli n'a plus qu'à savoir où aller chercher la base et tout est dedans. Une seule valeur
dans un fichier .INI du nom de l'appli permet de passer d'une base de test à une base réelle.
CREATE TABLE "_Registre" (
"Id" INTEGER NOT NULL PRIMARY KEY,
"Clef" CHAR NOT NULL,
"Valeur" CHAR NOT NULL);
j) Il n'est pas inutile de prévoir cette table qui permet au soft de noter dans un coin des choses
bizarres sans qu'elles ne soient des erreurs bloquantes. Une boîte de dialogue peut rappeler de
temps à autre (e.g. au lancement du soft) que certains points sont à traiter.
CREATE TABLE "_Anomalies" (
"Id" INTEGER NOT NULL PRIMARY KEY,
"Date" CHAR NOT NULL DEFAULT (Datetime('now')),
"Anomalie" CHAR NOT NULL DEFAULT '',
"Résolue" BOOLEAN NOT NULL DEFAULT 0);
Si on veut gérer les choses de façon un peu carrée, on devrait gérer des demandes dans une table séparée
car une demande devrait pouvoir porter sur plusieurs choses, par exemple la remise à niveau de plusieurs
postes avec un nouveau jeu d'équipements, à réaliser sur une quinzaine de jours.
J'ai créé quelques entrées pour qu'on puisse jouer avec le tout.
Il y a aussi quelques vues. Une vue SQL est en fait un SELECT prédéfini qu'on peut consulter ou utiliser
dans une requête plus complexe comme si c'était une table.
Vue des postes par ligne et station. On s'aperçoit que le fait d'avoir un "nom" de station numérique (et si
je comprends bien des sous-stations mais je m'en suis aperçu plus tard, avec les stations 56 que je croyais
commentées) ne permet pas une vue hiérarchique idéale. On peut corriger ça, ce n'est pas grave. J'ai mis
une "béquille" pour contourner l'obstable avec la colonne StationNom5, mais c'est temporaire et non important.
CREATE VIEW "LesPostes" AS
select posteid ID,
case when posteid > 0
then lignenom || '_' || stationnom
else stationnom
end Poste
from postes natural join lignes natural join stations
order by ligneid, stationnom5;
Vues des équipements connus, par fournisseur, référence et appartenance à un sur-ensemble. J'ai volontairement
introduit le contrôleur de robot Stäubli CS8C pour montrer que l'appartenance peut être un graphe (orienté et
acyclique), visible dans la colonne résultat "Associé à".
CREATE VIEW "LesEquipements" AS
select equipid ID,
nom Fournisseur,
Référence,
description Description,
case when parentid isnull
then ''
else (select référence from equipements E where E.equipid = EQ.parentid)
end "Associé à"
from fournisseurs join equipements EQ using (fournid)
order by nom, référence, parentid;
Vue du parc physique. On y trouve le poste où se trouve l'équipement, les informations sur
cet équipement précis avec son n° de série. J'ai créé des exemples d'équipements hors lignes
réelles, supposé se trouver dans certains ateliers pour remise en état ou retour fournisseur.
Ce n'est qu'un exemple de ce qu'on peut mettre en place.
CREATE VIEW "LeParc" AS
select posteid,
case when parcposteid > 0
then lignenom || '_' || stationnom
else stationnom
end Poste,
equipid,
description,
référence,
parcserial "N° de série"
from parc
left join postes on parcposteid = posteid
natural join lignes
natural join stations
join equipements E on E.equipid = parcequipid
order by Poste;
C'est en consultant les vues qu'on peut mieux se rendre compte de ce qu'on peut obtenir.
Je vais m'arrêter là pour ce ... soir ou matin, je ne sais plus trop !
Suivront rapidement des exemples de requêtes jouables sur la base de démo, même si les données sont bidon.
Mais je ne sais pas trop quelle requêtes seraient parlantes/utiles pour toi. Tu me diras.
Une fois ce squelette un peu dégrossi et quand la poussière sera retombée, on va mettre en ligne la
maintenance avec quelques exemples d'utilisation. Il y a encore beaucoup de finesses à régler, comme les
requêtes en texte désaccentué, les triggers (déclencheurs) et plus technique, les clauses d'action sur
modification ou suppression de clé étrangères [pour l'instant presque tout est à ON DELETE RESTRICT]. Ce
point peut sembler obscur mais il va s'éclairer par la suite et conditionne des aspects en réalité
fondamentaux du fonctionnement de l'ensemble. On y reviendra.
L'habillage de tout ça (joli GUI et tout) est bien ultérieur et à envisager seulement quand la base sera
stable et utilisable "à la main" via SQLite Expert. Note, la version payante de Expert permet l'utilisation
de scripts LUA ou Pascal qui peuvent parfaitement se substituer à un habillage AutoIt au niveau fonctionnel
mais certes pas au niveau cosmétique (ce dont je me fous éperdument, à dire vrai).
- Hugues.zip
- Base exemple
- (6.83 Kio) Téléchargé 119 fois
La cryptographie d'aujourd'hui c'est le taquin plus l'électricité.
Je vais y aller par étapes 
) et pas moyen d'avoir la moindre idée de comment doit être traité le contenu de ces tables, ni à quoi ça peut bien servir
) le fonctionnement d'une base SQL (et fichtre que c'est puissant et jouissif pour quelqu'un qui maîtrise ce langage...) .