Discussion :

[ordigil]

Bonjour fsmrel.

1 - Nous n'avons pas de 'MfgDate' pour les 'COMPONENT'. C'est triste Il me semble qu'à l'origine, nous devions en avoir une mais elle nous a sans doute filé d'entre les doigts la coquine.
2 - Nous n'avons pas non plus de 'SaleDate' pour les 'COMPONENT', ce qui cause problème car j'ai un 'Moteur' et une 'Transmission' à vendre ici mais impossible de les vendre à cause de la base de données.
3 - Dans la vue 'DIFFERENTIAL_LOCALISATION', nous avons une colonne 'DifferentialDatePurchase' au lieu de 'DifferentialPurchaseDate'

Les Vues 'TRUCK_COMPOSITION_V' et 'TRUCK_COMPOSITION_V2' sont identiques puisque il y a déjà un bout de temps que nous avions renommer 'TRUCK_COMPOSITION_V2' en 'TRUCK_COMPOSITION_V' . Nous avons simplement négligé d'effacer 'TRUCK_COMPOSITION_V2'...

Par contre il y a un petit quelque chose qui est irritant avec cette vue. Bien qu'il soit important de mentionner si un 'AXLE' est conçu ou non pour recevoir un 'Differential', cela nous rajoute des lignes lors de l'affichage de la vue. Donc nous pouvons nous retrouver avec une multitude de lignes affichées pour un Camion donné dans le cas d'un camion avec 8 'AXLE' . Ne pourrions-nous pas simplement ajouter une Colonne dans la Table 'AXLE' qui spécifierait si le 'AXLE' est conçu pour recevoir un 'DIFFERENTIAL' ou pas ? Bien sûr que ça ajouterait 3 Colonnes dans la Vue 'TRUCK_COMPOSITION_V' mais je trouverait cela mois gênant qu'afficher une infinité de lignes pour un même Camion… Dans la vue lorsqu'un 'AXLE' n'a pas de 'DIFFERENTIAL', nous le voyons déjà et nous voyons aussi déjà de quel Type de 'AXLE' il s'agit lorsqu'il n'y a pas de 'SerialNumber' dans la colonne 'DIFFERENTIAL' associée à cet 'AXLE' Alors tout ce qui manque c'est une colonne pour chacun des 'AXLE' qui mentionnerait si l''AXLE' est conçu pour recevoir un 'DIFFERENTIAL' ou non… Il faudrait aussi revoir le trigger pour interdire l'installation d'un 'DIFFERENTIAL' dans les 'AXLE' non conçus pour en recevoir un.

Qu'en pensez-vous ???

[fsmrel]

Les Vues 'TRUCK_COMPOSITION_V' et 'TRUCK_COMPOSITION_V2' sont identiques puisque il y a déjà un bout de temps que nous avions renommer 'TRUCK_COMPOSITION_V2' en 'TRUCK_COMPOSITION_V' . Nous avons simplement négligé d'effacer 'TRUCK_COMPOSITION_V2'...

Par contre il y a un petit quelque chose qui est irritant avec cette vue. Bien qu'il soit important de mentionner si un 'AXLE' est conçu ou non pour recevoir un 'Differential', cela nous rajoute des lignes lors de l'affichage de la vue. Donc nous pouvons nous retrouver avec une multitude de lignes affichées pour un Camion donné dans le cas d'un camion avec 8 'AXLE' . Ne pourrions-nous pas simplement ajouter une Colonne dans la Table 'AXLE' qui spécifierait si le 'AXLE' est conçu pour recevoir un 'DIFFERENTIAL' ou pas ? Bien sûr que ça ajouterait 3 Colonnes dans la Vue 'TRUCK_COMPOSITION_V' mais je trouverait cela mois gênant qu'afficher une infinité de lignes pour un même Camion… Dans la vue lorsqu'un 'AXLE' n'a pas de 'DIFFERENTIAL', nous le voyons déjà et nous voyons aussi déjà de quel Type de 'AXLE' il s'agit lorsqu'il n'y a pas de 'SerialNumber' dans la colonne 'DIFFERENTIAL' associée à cet 'AXLE' Alors tout ce qui manque c'est une colonne pour chacun des 'AXLE' qui mentionnerait si l''AXLE' est conçu pour recevoir un 'DIFFERENTIAL' ou non… Il faudrait aussi revoir le trigger pour interdire l'installation d'un 'DIFFERENTIAL' dans les 'AXLE' non conçus pour en recevoir un.

Qu'en pensez-vous ???

Fonctionnellement parlant, il est légitime qu’on sache à partir de la base de données qu’un axle puisse héberger un différentiel en fonction de son type ('front', etc.)

Vu le ménage que je suis en train de faire, je ne me prononce pas définitivement, mais reprenons la contrainte définie pour la table AXLE :

CONSTRAINT AXLE_COMPOSANT_TYPE_CHK CHECK (LOWER(AxleType) IN ('front', '2ndfront', 'forward', 'rear', 'pusher', 'tag'))

En théorie, cet ensemble de valeurs devrait faire l’objet d’une table, appelons-la AXLE_TYPE, dans laquelle une colonne « DifferentialAble » (ou autre nom moins barbare) préciserait si le type d’axle ('front', etc.) est conçu pour pouvoir héberger un différentiel.

Cela dit, si vu l’état d’avancement de vos travaux, si la mise en oeuvre de la table AXLE_TYPE vous pose un problème, et si en revanche on installe directement cette colonne DifferentialAble dans l’en-tête de la table AXLE, on violera la troisième forme normale, il faudra donc aménager les triggers AXLE_COMPOSANT_INSERT_TR et AXLE_COMPOSANT_UPDATE_TR pour pallier, et ainsi s’assurer par exemple qu’on n’a pas rendu un pusher « differential able »...

Votre position ?

Pour le moment je n’en suis pas aux axles et à TRUCK_COMPOSITION_V, je garde donc tout ça sous le coude.

[ordigil]

Même si je pousse tout à la limite, nous essayons quand même de ne rien violer Nous essayons de rester le plus près possible de toutes les règles et formes normales… Alors on introduira une autre table plus tard lorsque le moment sera venu. Pour l'instant il y a amplement à faire et encore beaucoup de triggers sont manquants. Vous ne vous éloignerez pas de moi aussi facilement Je pense qu'il y a encore de la matière jusqu'à Pâques LoL
Je pensais que nous aurions terminer à Noël mais oupsssss ce projet est en fait un cours complet que vous me donnez et je l'apprécie sincèrement. Vos triggers sont tellement bien fait et bien documentés que je peux en prendre des parties pour concevoir de nouvelles table. Qui y aurait cru ? Lorsque les gens me demanderont la différence entre une Table et un Trigger sur une Table, je répondrai : Je ne sais pas, j'utilise des Triggers pour concevoir mes Tables hahaha J'ai toujours opter pour le côté modulaire des choses. Lorsque les choses sont bien faites, nous pouvons réutiliser une partie d'un appareil pour en concevoir un autre. Vous y allez à fond dans cette base de données mais elle a ceci de particulier, tout le code est récupérable pour concevoir toutes sortes d'autres bases de données. C'est un trésor inestimable. Alors même si je rechigne un peu des fois, il en demeure quand même très important de respecter le plus fidèlement possible les formes normales dans la conception de cette base de données. Le terme anglais pour 'DifferentialAble ' serait 'DifferentialCapability' ou 'DifferentialAdapted' ou 'DifferentialSuitable' ou 'DifferentialDesigned' ou 'DifferentialCapable' ou 'DifferentialFitTo', on a le choix

Fonctionnellement parlant, il est légitime qu’on sache à partir de la base de données qu’un axle puisse héberger un différentiel en fonction de son type ('front', etc.)

Vu le ménage que je suis en train de faire, je ne me prononce pas définitivement, mais reprenons la contrainte définie pour la table AXLE :

CONSTRAINT AXLE_COMPOSANT_TYPE_CHK CHECK (LOWER(AxleType) IN ('front', '2ndfront', 'forward', 'rear', 'pusher', 'tag'))

En théorie, cet ensemble de valeurs devrait faire l’objet d’une table, appelons-la AXLE_TYPE, dans laquelle une colonne « DifferentialAble » (ou autre nom moins barbare) préciserait si le type d’axle ('front', etc.) est conçu pour pouvoir héberger un différentiel.

Cela dit, si vu l’état d’avancement de vos travaux, si la mise en oeuvre de la table AXLE_TYPE vous pose un problème, et si en revanche on installe directement cette colonne DifferentialAble dans l’en-tête de la table AXLE, on violera la troisième forme normale, il faudra donc aménager les triggers AXLE_COMPOSANT_INSERT_TR et AXLE_COMPOSANT_UPDATE_TR pour pallier, et ainsi s’assurer par exemple qu’on n’a pas rendu un pusher « differential able »...

Votre position ?

Pour le moment je n’en suis pas aux axles et à TRUCK_COMPOSITION_V, je garde donc tout ça sous le coude.

[fsmrel]

[QUOTE=ordigil;10674073]Même si je pousse tout à la limite, nous essayons quand même de ne rien violer Nous essayons de rester le plus près possible de toutes les règles et formes normales… Alors on introduira une autre table plus tard lorsque le moment sera venu. Pour l'instant il y a amplement à faire et encore beaucoup de triggers sont manquants.

D’accord pour différer la mise en oeuvre de la table AXLE_TYPE, qui aurait la (fière) allure suivante :

CREATE TABLE AXLE_TYPE
(
        AxleTypeId                  INT   IDENTITY    NOT NULL
      , AxleType                    VARCHAR(16)       NOT NULL
      , AxleDifferentialDesigned    CHAR(1)           NOT NULL
    , CONSTRAINT AXLE_TYPE_PK PRIMARY KEY (AxleTypeId)
    , CONSTRAINT AXLE_TYPE_TYPE_CHK CHECK (LOWER(AxleDifferentialDesigned) IN ('y', 'n'))
)

Et prendrait les valeurs (à vous de corriger...) :

INSERT INTO AXLE_TYPE (AxleType, AxleDifferentialDesigned) 
    VALUES ('front', 'y')
         , ('2ndfront', 'y')
         , ('forward', 'y')
         , ('rear', 'y')
         , ('pusher', 'n')
         , ('tag', 'n')
;

. Quant à normaliser, cela vaut pour les modèles des fabricants, souvenez-vous du 3e diagramme du post #317, dans lequel j’avais écrit :

Dans un 2e temps, on pourrait donc brancher la table COMPOSANT sur la table MODELE

Bon, pour le moment on garde tout ça sous le coude, à moins que ça ne vous prenne comme une envie de p... et que ça devienne urgent...

[ordigil]

Oui, ça sera mieux ainsi mais pour l'instant j'ai besoin que les triggers fonctionnent alors je ne changerai rien tant qu'on n'aura pas terminé ce qui est déjà commencé. Pour les

Oui pour les fabricants j'avais déjà regardé et on pourrait aller encore plus loin que ça, histoire que la base de données ne soit pas seulement fonctionnelle et respectueuse des formes normales mais aussi pousser à la limite le côté éducationnel. J'avais commencé à concevoir un modèle avant que vous vous intéressiez à ma base de données mais j'ai abandonné pour suivre votre développement. L'idée à l'époque était une table par thème. À première vue ça semble idiot mais de cette façon je pouvais enchaîner toutes mes tables et regrouper dans une même table tous les numéros de série, tous les manufacturiers, etc. Lorsqu'on regarde en haut de la pyramide, on se rend compte qu'il n'y a pas beaucoup de manufacturiers, la majorité des entreprises appartiennent à des fonds d'investissements… Ainsi donc, Volvo appartient à des Chinois et appartenait auparavant à FORD et bla bla bla. Ça fait quand même étrange qu'il y ait beaucoup de redondance dans nos Tables comme les Numéros de séries dans chacune des Tables Truck, Engine, Transmission, Axle, Differential... Nous avons une colonne Manufacturier dans toutes les Tables alors que tous les Manufacturiers pourraient être regroupés dans une seule Table.


Pièce jointe 437427

Code fsmrel :

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

Quant à normaliser, cela vaut pour les modèles des fabricants, souvenez-vous du 3e diagramme du post

[QUOTE=fsmrel;10674253]

Même si je pousse tout à la limite, nous essayons quand même de ne rien violer Nous essayons de rester le plus près possible de toutes les règles et formes normales… Alors on introduira une autre table plus tard lorsque le moment sera venu. Pour l'instant il y a amplement à faire et encore beaucoup de triggers sont manquants.

D’accord pour différer la mise en oeuvre de la table AXLE_TYPE, qui aurait la (fière) allure suivante :

CREATE TABLE AXLE_TYPE
(
        AxleTypeId                  INT   IDENTITY    NOT NULL
      , AxleType                    VARCHAR(16)       NOT NULL
      , AxleDifferentialDesigned    CHAR(1)           NOT NULL
    , CONSTRAINT AXLE_TYPE_PK PRIMARY KEY (AxleTypeId)
    , CONSTRAINT AXLE_TYPE_TYPE_CHK CHECK (LOWER(AxleDifferentialDesigned) IN ('y', 'n'))
)

Et prendrait les valeurs (à vous de corriger...) :

INSERT INTO AXLE_TYPE (AxleType, AxleDifferentialDesigned) 
    VALUES ('front', 'y')
         , ('2ndfront', 'y')
         , ('forward', 'y')
         , ('rear', 'y')
         , ('pusher', 'n')
         , ('tag', 'n')
;

. Quant à normaliser, cela vaut pour les modèles des fabricants, souvenez-vous du 3e diagramme du post #317, dans lequel j’avais écrit :

Bon, pour le moment on garde tout ça sous le coude, à moins que ça ne vous prenne comme une envie de p... et que ça devienne urgent...

[fsmrel]

Bonsoir Ordigil,

Ça fait quand même étrange qu'il y ait beaucoup de redondance dans nos Tables comme les Numéros de séries dans chacune des Tables Truck, Engine, Transmission, Axle, Differential...

Dans le contexte des bases de données il y a redondance quand, pour une information donnée, la même valeur est présente plus d’une fois. Or le numéro de série d’un camion n’est pas redondant puisqu’il ne figure qu’une seule fois, à savoir dans la colonne TruckVIN de la table TRUCK, unicité garantie par la clé candidate définie pour cette colonne. De même, le numéro de série d’une transmission n’est pas redondant puisqu’il ne figure qu’une seule fois, à savoir dans la colonne TransmissionSerialNumber de la table TRANSMISSION, unicité garantie par la clé candidate définie pour cette colonne. Même principe pour les numéros de série des moteurs, des axles et des différentiels. Ainsi il n’y a pas de redondance des numéros de série.

Ce que vous mettez en cause, c’est l’éparpillement des numéros de série : numéros de série des camions dans la table TRUCK, numéros de série des transmissions dans la table TRANSMISSION, etc. Mais cet éparpillement est sémantiquement justifié, ne serait-ce que parce qu’on ne peut quand même pas comparer le numéro de série d’un camion avec celui d’une transmission, etc., tout comme on ne compare pas des choux et des navets bien que ce soient des légumes.

Cela dit, si vous souhaitez une présentation de tous les numéros de série regroupés, il suffit d’en passer par une table virtuelle, autrement dit une vue en SQL :

CREATE VIEW SERIAL_NUMBER_V (SerialNumber)
AS
        SELECT TruckVIN FROM TRUCK
    UNION
        SELECT EngineSerialNumber FROM ENGINE
    UNION
        SELECT TransmissionSerialNumber FROM TRANSMISSION
    UNION
        SELECT AxleSerialNumber FROM AXLE
    UNION
        SELECT DiffSerialNumber FROM DIFFERENTIAL

Dans les pages 521-522 de son ouvrage Date on Database Writings 2000-2006, C. J. Date fait mention de ce qu’a écrit Charles Babcock (Charles Babcock’s “Commentary” column from Computerworld (“Relational Backlash,” June 28th, 1993)) :

Relational systems can store objects, but to do so, they must break them down into components and store them in tables. In an analogy that originated with Esther Dyson, editor of the newsletter “Release 1.0,” this is like driving your car home and then disassembling it to put it in the garage. It can always be reassembled again in the morning, but one eventually asks whether this is the most efficient way to park a car.

Pour sa part, Date écrit :

the analogy of disassembling your car to park it and reassembling it in the morning is just as hoary—and what’s more, it’s WRONG. Relational technology does not necessarily require complex objects to be broken down into components to be stored in the database (see my article “A Fruitful Union” [CW, June 14]).

Je suis évidemment bien d’accord avec Date quant à l’analogie en cause, révélatrice d’une grande ignorance de la théorie relationnelle, ce qui à mon sens rend cette analogie fallacieuse, fielleuse et surtout bête. En ce qui concerne nos numéros de série, elle sous-entend qu’il faudrait définitivement remplacer la table virtuelle SERIAL_NUMBER_V par une table de base ; je pense que le Charles et sa collègue n’ont jamais étudié sérieusement les vues et méconnaissent leur souplesse et leur puissance. Pour notre part, en quittant la vraie technologie relationnelle nous nous enquiquinons avec SQL Server et ses triggers pour pallier ses lacunes (mise à jour des vues de jointure, d’union, etc.), mais il a le droit de s’améliorer…

Pour continuer avec l’analogie, c’est encore comme si, sous le capot, on imposait qu’une table soit physiquement hébergée par un seul fichier, ce qui serait bien sûr handicapant, absurde.

Pour ma part, tant qu’on respecte la cinquième forme normale, donc qu’on a évacué des redondances grossières, rien n’empêche de procéder à l’optimisation de la base de données, c’est-à-dire à un changement de la structure des tables, par exemple pour des raisons de performance.

Ainsi, au prix d’une perte de sémantique (mélange des choux et des navets), on pourrait très bien expulser les numéros de série des composants (moteurs, transmissions, axles, différentiels) des tables qui les hébergent aujourd’hui, et les regrouper dans une colonne unique SerialNumber de la table COMPOSANT (COMPONENT). Cette colonne devrait bien sûr être dotée d’une clé candidate garantissant l’unicité des numéros de série, mais comme on n’est pas à l’abri de l’existence d’homonymes, cette clé devrait être a minima composée de la paire {Serial Number, Manufacturer}, voyez le diagramme ci-dessous.

Nous avons une colonne Manufacturier dans toutes les Tables alors que tous les Manufacturiers pourraient être regroupés dans une seule Table.

Toujours par référence au 3e diagramme du post #317 vieux de plus de 2 mois, en aménageant on arriverait à la situation suivante :

Où la paire {SerialNumber, FournisseurId} est clé candidate (mickey <ak>) de la table COMPOSANT.


Je rappelle qu’aujourd’hui, la présence des colonnes Manufacturer et Model dans les tables COMPOSANT et CAMION font que la troisième forme normale est violée et qu’un jour il faudra donc procéder au regroupement que vous souhaitez (c’est-à-dire mise en oeuvre des tables MODEL et MANUFACTURER, à l’image du diagramme ci-dessus).

Donc, il serait préférable de corriger cette lacune car il pourrait très bien arriver comme dans le passé que je change un pneu sur un camion le matin et que le soir le même camion revient avec une crevaison à nouveau sur la même roue… Bon ça sera un autre pneu neuf mais ce sera quand même le même jour par contre il serait surprenant que ce soit le même Kilométrage…. Si avec KM le matin plus 1 KM je peux effectuer la même réparation, alors pas de problème, on peut ajouter 1 KM pour la réparation mais si ça ne passe pas à cause de la date, là il y aura un problème….

A ce stade, il est nécessaire de bien distinguer les maintenances des réparations.

Si une maintenance M1 du type de maintenance T1 ne peut être effectuée qu’au jour J1 par le garage G1, alors la clé primaire de la table MAINTENANCE_REPAIR se limite fonctionnellement au triplet {TruckId, TruckMilleageId, MaintenanceRepairTypeId} : exit ShopId de la clé (à moins que deux garages ou plus puissent être parties prenantes dans la maintenance M1, vous me direz).

Quant aux réparations, changement de chanson évident, car la poisse aidant (passage sur des clous semés par un malfaisant, etc.), le besoin se fait sentir de se débarrasser du carcan trop restrictif de la clé {TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId}, et de passer à une clé primaire {TruckId, TruckMilleageId, MaintenanceRepairId} où MaintenanceRepairId est une nouvelle colonne dont les valeurs s’incrémentent de 1 en 1 (IDENTITY) au fil des réparations.

Ainsi, le besoin n’est pas le même pour les maintenances et pour les réparations : qui peut le plus peut le moins, a priori va pour la nouvelle clé {TruckId, TruckMilleageId, MaintenanceRepairId}, mais si l’intervention est une maintenance, on devra garantir (trigger en vue...) la contrainte d’unicité pour le triplet {TruckId, TruckMilleageId, MaintenanceRepairTypeId}.

Votre point de vue ?

Parmi les lignes de la table MAINTENANCE_REPAIR_TYPE, il est fait mention des composants : 'engine', 'transmission', 'differential', 'axle'. Je suppose qu’il s’agit d’être en conformité avec le manuel du gouvernement. Quoi qu’il en soit, si par exemple un moteur fait l’objet d’une réparation ou d’une maintenance, il faudra savoir de quel moteur il s’agit, donc établir un lien avec la table MOTEUR ou la table COMPOSANT. Intéressant...

[ordigil]

Pour 'engine', 'transmission', 'differential', 'axle', ça ne fait pas partie du manuel du gouvernement, je les ai ajoutés pour la convenance… Par contre je ne sais pas encore si je vais les conserver… Et par contre et encore par contre, le manuel du gouvernement concerne l'état mécanique du camion afin que les camions soient sécuritaires sur la route. Donc, il y a quand même des choses manquantes dans le manuel d'où l'ajout de 'engine', 'transmission', 'differential', 'axle'. Si je les conserve alors oui on attribuera des liens vers les tables concernées.

Parmi les lignes de la table MAINTENANCE_REPAIR_TYPE, il est fait mention des composants : 'engine', 'transmission', 'differential', 'axle'. Je suppose qu’il s’agit d’être en conformité avec le manuel du gouvernement. Quoi qu’il en soit, si par exemple un moteur fait l’objet d’une réparation ou d’une maintenance, il faudra savoir de quel moteur il s’agit, donc établir un lien avec la table MOTEUR ou la table COMPOSANT. Intéressant...

Pour les réparations, il faut toujours envisager le pire du pire alors on fait en sorte que le même garage puisse effectuer la même réparation sur le même camion à la même date et au même kilométrage sans restriction. Un camion, il faut que ça roule. Par contre il serait intéressant que l'on puisse avoir un suivi . On pourrait inclure une colonne avec le numéro de facture mais le problème est qu'à mon atelier nous n'avons pas de bon de travail ou de facture. On ne se facture pas nous-même. Donc on entre 3 fois ou 5 fois au même garage pour la même réparation pour le même camion le même jour, il faudra 3 ou 5 entrées différentes dans la base de données. Nous pouvons ajouter une colonne NumeroFacture et la valeur par défaut = '0' donc pour notre atelier, la colonne sera toujours '0'. On dit la même réparation mais en fait, ce sont toutes des réparations différentes mêmes si c'est la même pièce ou le même problème à réparer à nouveau. Donc même si j'aurai toujours NumeroFacture = '0' dans mon atelier, ça ne doit pas m'empêcher de refaire la même réparation 2 fois ou de réparer le même camion autant de fois que nécessaire dans la même journée.

Pour les maintenance, il n'y a pas d'horaire pour les maintenance, on y va avec le kilométrage pour les changements d'huile et graissage et pour les autres maintenances, c'est un peu aléatoire si ça ne concerne pas l'aspect sécuritaire du véhicule. Il va de soi lors des changements d'huile, nous effectuons quand même d'autres maintenances. Puisqu'une maintenance est une maintenance, je ne vois pas la raison qui justifierait de faire 2 fois la même maintenance sur le même camion la même journée.

A ce stade, il est nécessaire de bien distinguer les maintenances des réparations.

Si une maintenance M1 du type de maintenance T1 ne peut être effectuée qu’au jour J1 par le garage G1, alors la clé primaire de la table MAINTENANCE_REPAIR se limite fonctionnellement au triplet {TruckId, TruckMilleageId, MaintenanceRepairTypeId} : exit ShopId de la clé (à moins que deux garages ou plus puissent être parties prenantes dans la maintenance M1, vous me direz).

Quant aux réparations, changement de chanson évident, car la poisse aidant (passage sur des clous semés par un malfaisant, etc.), le besoin se fait sentir de se débarrasser du carcan trop restrictif de la clé {TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId}, et de passer à une clé primaire {TruckId, TruckMilleageId, MaintenanceRepairId} où MaintenanceRepairId est une nouvelle colonne dont les valeurs s’incrémentent de 1 en 1 (IDENTITY) au fil des réparations.

Ainsi, le besoin n’est pas le même pour les maintenances et pour les réparations : qui peut le plus peut le moins, a priori va pour la nouvelle clé {TruckId, TruckMilleageId, MaintenanceRepairId}, mais si l’intervention est une maintenance, on devra garantir (trigger en vue...) la contrainte d’unicité pour le triplet {TruckId, TruckMilleageId, MaintenanceRepairTypeId}.

Votre point de vue ?

Merci fsmrel. Quand le patron ne saura pas quoi est quoi.

CREATE VIEW [dbo].[SERIAL_NUMBER_V]
AS
SELECT        TruckVIN AS 'Serial Number', 'Truck Number  ' + TruckNumber AS 'Component Type'
FROM            TRUCK
UNION
SELECT        EngineSerialNumber, 'Engine'
FROM            ENGINE
UNION
SELECT        TransmissionSerialNumber, 'Transmission'
FROM            TRANSMISSION
UNION
SELECT        AxleSerialNumber, 'Axle'
FROM            AXLE
UNION
SELECT        DifferentialSerialNumber, 'Differential'
FROM            DIFFERENTIAL
UNION
SELECT        PartNumber, PartName
FROM            PARTS_CATALOG

SELECT * FROM SERIAL_NUMBER_V

Pièce jointe 437701


[QUOTE=fsmrel;10676549]Bonsoir Ordigil,

CREATE VIEW SERIAL_NUMBER_V (SerialNumber)
AS
        SELECT TruckVIN FROM TRUCK
    UNION
        SELECT EngineSerialNumber FROM ENGINE
    UNION
        SELECT TransmissionSerialNumber FROM TRANSMISSION
    UNION
        SELECT AxleSerialNumber FROM AXLE
    UNION
        SELECT DiffSerialNumber FROM DIFFERENTIAL

Je pense que je vais dropper les Tables 'SHOP_LIST' et 'PARTS_SUPPLIER' et créer une seule table 'ADDRESS_BOOK'. Quand pensez-vous ???

Ça ne peut pas être FOURNISSEUR. J'ai besoin de 'MANUFACTURER'. Un Fournisseur c'est un Vendeur ou un Distributeur et un Manufacturier c'est un Fabricant. En haut de 'MANUFACTURER', ça serait utile d'avoir 'HEADQUARTERS'. Ainsi Daimler est le HeadQuarters de Freightliner, Detroit Diesel, Western Star. Navistar est le HeadQuarters de International, Anhui, MWM, Blue Diamond, NC2. Paccar est le HeadQuarters de Peterbilt, Kenworth, DAF.

Pièce jointe 437702

[fsmrel]

Bonjour Ordigil,

Je pense que je vais dropper les Tables 'SHOP_LIST' et 'PARTS_SUPPLIER' et créer une seule table 'ADDRESS_BOOK'. Quand pensez-vous ???

Je n’ai pas encore regardé PARTS_SUPPLIER. Je vais examiner ça de plus près.

Puisqu'une maintenance est une maintenance, je ne vois pas la raison qui justifierait de faire 2 fois la même maintenance sur le même camion la même journée.

On entérine donc les règles :

Pour le type de maintenance T1, le camion C1 fait l’objet d’au plus une maintenance au kilométrage K1 (c’est-à-dire au jour J1).

Pour le type de maintenance T1, le moteur E1 fait l’objet d’au plus une maintenance au kilométrage K1 (c’est-à-dire au jour J1). Ce qui vaut pour les moteurs vaut pour les autres composants (transmissions, axles et différentiels).

On pourrait inclure une colonne avec le numéro de facture mais le problème est qu'à mon atelier nous n'avons pas de bon de travail ou de facture. On ne se facture pas nous-même. Donc on entre 3 fois ou 5 fois au même garage pour la même réparation pour le même camion le même jour, il faudra 3 ou 5 entrées différentes dans la base de données.

Partons de la structure suivante (non définitive...) :

CREATE TABLE MAINTENANCE_REPAIR
(
        CamionId             INT           NOT NULL
      , CamionMilleageId     INT           NOT NULL
      , MaintenanceRepairId  INT IDENTITY  NOT NULL
      , MaintenanceTypeId    INT           NOT NULL
      , ShopId               INT           NOT NULL DEFAULT 1
      , Details              VARCHAR(512)  NOT NULL DEFAULT '-'
      , LaborPrice           DECIMAL(8,2)  NOT NULL DEFAULT 0 
    , CONSTRAINT MAINTENANCE_REPAIR_PK PRIMARY KEY (CamionId, CamionMilleageId, MaintenanceRepairId)
    , CONSTRAINT MAINTENANCE_REPAIR_MILLEAGE_FK FOREIGN KEY (CamionId, CamionMilleageId)
          REFERENCES CAMION_MILLEAGE (CamionId, CamionMilleageId)
    , CONSTRAINT MAINTENANCE_REPAIR_MAINTENANCE_TYPE_FK FOREIGN KEY (MaintenanceTypeId)
          REFERENCES MAINTENANCE_TYPE (MaintenanceTypeId)
    , CONSTRAINT MAINTENANCE_REPAIR_SHOP_FK FOREIGN KEY (ShopId)
          REFERENCES SHOP (ShopId)
)

Quelques réparations :

INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment') 
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Etablisements Ordigil')

INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment') 
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Entreprise fsmrel')

INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment') 
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Etablisements Ordigil')

INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Tires wear') 
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Chez Escartefigue')
 
INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '314')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 3000) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment')  
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Ets Oishiiii')

Pour savoir combien de fois la réparation du type Brake Adjustment a été effectuée au kilométrage 2470 pour le camion 156 :

SELECT COUNT(*) AS RepairsQty 
FROM   MAINTENANCE_REPAIR 
WHERE  CamionId = (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
   AND CamionMilleageId = (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470)
   AND MaintenanceTypeId = (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment')

=>

Nous pouvons ajouter une colonne NumeroFacture et la valeur par défaut = '0' donc pour notre atelier, la colonne sera toujours '0'.

L’existence de cette colonne sous-entend qu’il y a une relation avec la table FACTURE à cause des réparations non effectuées chez vous…

Est-ce essentiel ?

[fsmrel]

Je n’ai pas vu de relation entre les réparations (table MAINTENANCE_REPAIR) et les pièces (table PART), on ne sait donc pas quelles pièces ont été éventuellement utilisées. Qu’en est-il ?

[ordigil]

Bien qu'un 'Parts Supplier' n'est pas une 'Shop', une 'Shop' peut être un 'Parts Supplier' alors dans mon cas j'aurai beaucoup de similitudes entre les deux Tables alors aussi bien n'en faire qu'une seule et la nommer 'ADDRESS_BOOK' et ajouter une colonne pour indiquer si c'est une 'Shop', un 'Parts Supplier' ou une 'Shop et Parts Supplier'. Alors cette Table servira pour notre future développement de 'COMPOSANT' -> 'MODEL' -> 'BRAND' ou 'MANUFACTURER' -> 'HEADQUARTERS'. Et en parallèle avec 'MANUFACTURER' nous aurons 'DEALER'... 'Du genre 'Prostar' -> 'International' -> 'Navistar International' .

Bonjour Ordigil,


Je n’ai pas encore regardé PARTS_SUPPLIER. Je vais examiner ça de plus près.

[ordigil]

Il y en a une pourtant ??? Puisque nous ne vendons pas de pièces, j'ai fait en sorte que pour sortir une pièce de l'inventaire elle doit passer par une réparation. De cette façon, si une pièce n'est plus dans l'inventaire, elle doit obligatoirement être sur un camion, sinon quelqu'un a volé la pièce. Le propriétaire sait tout ce qu'il y a sur les tablettes ici alors s'il cherche une pièce et ne la trouve pas, il pourra demander au mécano où est la pièce... Si le mécano dit qu'il a installé la pièce sur un camion, le propriétaire pourra vérifier si le mécano dit la vérité en regardant 'TRUCK_MAINTENANCE_REPAIR et en regardant si la pièce a réellement été installée sur le camion. La méthode que j'ai utilisée n'est peut-être pas très orthodoxe par contre. Elle ne suit probablement pas les normes SQL Vous pourrez jeter un coup d'oeil sur les Tables 'MAINTENANCE_REPAIRS_TYPE' et PARTS_CATEGORY_CATALOG'.


Pièce jointe 437846

Je n’ai pas vu de relation entre les réparations (table MAINTENANCE_REPAIR) et les pièces (table PART), on ne sait donc pas quelles pièces ont été éventuellement utilisées. Qu’en est-il ?

[ordigil]

Disons que le mécano fait une maintenance sur le moteur d'un camion du genre 'Dégraisser le moteur' Est-ce que ça veut dire que moi je ne pourrai pas faire une seconde maintenance du genre 'Ajustement des valves' sur ce même moteur cette journée-là ? Peut-être devrions-nous tout simplement tout mettre dans réparations y compris les maintenances. La Table se nomme déjà 'Maintenance_Repairs' alors on pourrait tout traiter comme des Repairs mais en conservant le nom de la Table 'Maintenance_Repairs'. Peut-être qu'on se casse trop la tête

On entérine donc les règles :

Pour le type de maintenance T1, le camion C1 fait l’objet d’au plus une maintenance au kilométrage K1 (c’est-à-dire au jour J1).

Pour le type de maintenance T1, le moteur E1 fait l’objet d’au plus une maintenance au kilométrage K1 (c’est-à-dire au jour J1). Ce qui vaut pour les moteurs vaut pour les autres composants (transmissions, axles et différentiels).

J'ai déjà une colonne 'LaborPrice' qui devrait plutôt être nommé 'LaborCost' alors nous pourrions faire quelque petites modifications et ajouter une Table 'FACTURATION' effectivement. Par contre il n'y a pas de facture pour les réparations que nous effectuons nous-même dans notre atelier. Si la réparation a été effectuée dans notre atelier, le numéro de facture pourrais s'appeler
'JerryShop' alors si JerryShop = pas de facture ou facture = 0$

L’existence de cette colonne sous-entend qu’il y a une relation avec la table FACTURE à cause des réparations non effectuées chez vous…

Est-ce essentiel ?

[fsmrel]

Ordigil,

On nous a fait plein de misères aujourd'hui, mais fi ! Je vous souhaite une bonne année 2019, en attendant que nous reprenions les choses calmement. Je devrais pouvoir retrouver les triggers et autres codes qui ont disparu. Une question de temps...

A bientôt !

P.S. Il y a des conversations bien plus longues que la nôtre, voyez par exemple https://www.developpez.net/forums/d1...on-se-demande/

[ordigil]

Par contre les triggers, je peux les récupérer à même la base de données. Ils sont tous dans 'DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH' en version anglais. Votre dernier trigger CAMION_HUILE_SUIVI_INSERT_TR figure encore dans nos messages sur le site… Je me demande bien ce que nous avons perdu… Bonne année cher fsmrel :-):-);-)

Ordigil,

On nous a fait plein de misères aujourd'hui, mais fi ! Je vous souhaite une bonne année 2019, en attendant que nous reprenions les choses calmement. Je devrais pouvoir retrouver les triggers et autres codes qui ont disparu. Une question de temps...

A bientôt !

P.S. Il y a des conversations bien plus longues que la nôtre, voyez par exemple https://www.developpez.net/forums/d1...on-se-demande/

[ordigil]

J'ai une Table 'MAINTENANCE_REPAIR_TYPE'. À chaque fois que j'effectue une Maintenance ou un Repair, je dois m'y référer. Nous ne pouvons rien rajouter et rien retrancher dans cette Table car ce sont les chapitres du manuel d'inspection mécanique du gouvernement. Donc 'Brake Adjustment' concerne 'Brake' dans la Table ''MAINTENANCE_REPAIR_TYPE' qui donne 'MaintenanceRepairTypeId = 5. Dans votre Table 'MAINTENANCE_REPAIR', qu'arrive-t-il si le mécanicien effectue un Repair et non une Maintenance puisque la colonne 'MaintenanceTypeId INT NOT NULL' ????

INSERT INTO MAINTENANCE_REPAIR (CamionId, CamionMilleageId, MaintenanceTypeId, ShopId)
    SELECT  (SELECT CamionId FROM CAMION WHERE CamionNumber = '156')
          , (SELECT CamionMilleageId FROM CAMION_MILLEAGE WHERE CamionMilleage = 2470) 
          , (SELECT MaintenanceTypeId FROM MAINTENANCE_TYPE WHERE MaintenanceType = 'Brake Adjustment') 
          , (SELECT ShopId FROM SHOP WHERE ShopName = 'Etablisements Ordigil')

[ordigil]

USE DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH
GO

BEGIN TRANSACTION

INSERT INTO TRUCK_MILLEAGE (TruckId, TruckMilleageDate, TruckMilleage)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2540'), ('2018-12-01'), (579284)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2540')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 579284 AND TruckMilleageDate = '2018-12-01') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Brakes') 
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'Camion Lague Dorval')
          , (SELECT Details = 'Brake Adjustment')
          , (SELECT LaborCost = 48.95)

INSERT INTO TRUCK_MILLEAGE (TruckId, TruckMilleageDate, TruckMilleage)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2532'), ('2018-12-01'), (98098)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2532')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 98098 AND TruckMilleageDate = '2018-12-01') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Brakes') 
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'GloboCam Boucherville')
          , (SELECT Details = 'Brake Adjustment')
          , (SELECT LaborCost = 48.95)

INSERT INTO TRUCK_MILLEAGE (TruckId, TruckMilleageDate, TruckMilleage)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '25467'), ('2018-12-08'), (563894)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '25467')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 563894 AND TruckMilleageDate = '2018-12-08') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Brakes') 
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'Dzindzio Shop')
          , (SELECT Details = 'Brake Adjustment')
          , (SELECT LaborCost = 48.95)

INSERT INTO TRUCK_MILLEAGE (TruckId, TruckMilleageDate, TruckMilleage)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2540'), ('2018-12-12'), (585029)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2540')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 585029  AND TruckMilleageDate = '2018-12-12') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Frame And Fiftwheel') 
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'GloboCam Anjou')
          , (SELECT Details = 'Grease')
          , (SELECT LaborCost = 97.38)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2540')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 585029  AND TruckMilleageDate = '2018-12-12') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Tires And Budwheels') 
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'GloboCam Anjou')
          , (SELECT Details = 'Check Tires Wear')
          , (SELECT LaborCost = 24.68)

INSERT INTO TRUCK_MILLEAGE (TruckId,  TruckMilleageDate, TruckMilleage)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2532'), ('2018-12-08'), (99004)

INSERT INTO MAINTENANCE_REPAIRS (TruckId, TruckMilleageId, MaintenanceRepairTypeId, ShopId, Details, LaborCost)
    SELECT  (SELECT TruckId FROM Truck WHERE TruckNumber = '2532')
          , (SELECT TruckMilleageId FROM Truck_MILLEAGE WHERE TruckMilleage = 99004 AND TruckMilleageDate = '2018-12-08') 
          , (SELECT MaintenanceRepairsTypeId FROM MAINTENANCE_REPAIRS_TYPE WHERE MaintenanceRepairsType = 'Brakes')  
          , (SELECT ShopId FROM SHOP_LIST WHERE ShopName = 'Camion Lague Anjou')
          , (SELECT Details = 'Brake Adjustment')
          , (SELECT LaborCost = 48.95)


SELECT COUNT(*) AS [Brake Ajustment Qty] 
FROM   MAINTENANCE_REPAIRS 
WHERE  TruckId = (SELECT TruckId FROM TRUCK WHERE TruckNumber = '2540')
---   AND TruckMilleageId = (SELECT TruckMilleageId FROM TRUCK_MILLEAGE WHERE TruckMilleage = 579284)
   AND Details LIKE 'Brake%'



SELECT *
FROM MAINTENANCE_REPAIRS
WHERE Details LIKE 'Brake%'
AND TruckId = (SELECT TruckId FROM TRUCK WHERE TruckNumber = '2540')
;

SELECT *
FROM MAINTENANCE_REPAIRS
WHERE Details LIKE 'Brake%'
--AND TruckId = (SELECT TruckId FROM TRUCK WHERE TruckNumber = '2540')
;

SELECT       v.TruckNumber 
           , x.TruckMilleageDate AS Date 
           , x.TruckMilleage AS Milleage 
           , y.MaintenanceRepairsType AS [Maintenance Type] 
           , w.Details 
           , w.Note 
           , w.LaborCost AS [Labor Cost] 
           , z.ShopName AS [Shop Name] 
FROM 
              dbo.MAINTENANCE_REPAIRS AS w 
  INNER JOIN  dbo.TRUCK AS v ON w.TruckId = v.TruckId 
  INNER JOIN  dbo.SHOP_LIST AS z ON w.ShopId = z.ShopId 
  INNER JOIN  dbo.MAINTENANCE_REPAIRS_TYPE AS y ON w.MaintenanceRepairTypeId = y.MaintenanceRepairsTypeId  
  INNER JOIN  dbo.TRUCK_MILLEAGE AS x ON w.TruckId = x.TruckId 
         AND  w.TruckMilleageId  = x.TruckMilleageId 
WHERE Details LIKE 'Brake%' 
;

SELECT * FROM TRUCK_MAINTENANCE_REPAIRS_V ;

ROLLBACK

Pièce jointe 437928

[fsmrel]

Suite à vos observations concernant le manuel, je propose ceci :

La table MAINTENANCE_REPAIR_TYPE change de nom et devient : MAINTENANCE_REPAIR_CATEGORY. Ses attributs sont renommés en MaintenanceRepairCategoryId et MaintenanceRepairCategory. Pour que les chapitres du manuel soient pris en compte, cette table est dotée d’un attribut à cet effet : MaintenanceRepairChapter (faisant l’objet d’une clé candidate). Je rappelle la règle d’or de Tabourier, selon laquelle on ne doit pas attribuer une quelconque signification aux attributs artificiels, à savoir MaintenanceRepairCategoryId en l'occurrence. Par contre, l’attribut MaintenanceRepairChapter est un attribut naturel qui servira donc pour numéroter les chapitres.


Concernant les maintenances/réparations, si certaines interventions ne nécessitent pas de pièces, on peut utiliser le diagramme suivant, dans lequel les interventions pour lesquelles on utilise des pièces sont concernées par la table M_R_PART. Si les interventions « sans pièces » nécessitent une relation avec MAINTENANCE_REPAIR_CATEGORY, on mettra en oeuvre une table supplémentaire, petite soeur de M_R_PART mais non concernée par les pièces.

[ordigil]

Bonjour fsmrel

Il n'y a aucune utilité à ajouter l'attribut MaintenanceRepairChapter dans la Table MAINTENANCE_REPAIR_CATEGORY. La seule chose qui est importante à retenir est que l'utilisateur ne peut ni rajouter, ni retrancher, ni modifier cette table pour quelques raisons que ce soit à l'exception de l'administrateur advenant que le gouvernement apporte des modifications au manuel. Je me sers des attributs artificiels dans le cadre du développement de la base de données par la suite ils n'auront aucune significations particulières.

1 - Toutes maintenances et toutes réparations doivent impérativement avoir une référence à un des chapitres de la table MAINTENANCE_REPAIR_CATEGORY. Il y aura un ComboBox à cet effet dans les formulaires du site WEB.
2 - Il y a des Catégories de réparations qui ne sont pas incluses dans le manuel du gouvernement d'où l'ajout de chapitres supplémentaires dans la Table MAINTENANCE_REPAIR_CATEGORY. EX: Réparation de l'antenne du radio. Ou remplacement du réfrigérateur. Ou réparation de l'alternateur. J'ajouterai un Chapitre nommé Accessories.
3 - Les pièces de l'inventaires doivent avoir une référence à un des Chapitres de la table MAINTENANCE_REPAIR_CATEGORY. EX : [PART].[PartName] 'Pneu Michelin Steering' = [MAINTENANCE_REPAIR_CATEGORY].[MaintenanceRepairCategory] 'Tires And Budwheels' ou [PART].[PartName] 'Park/Brake light Prostar 2010' = [MAINTENANCE_REPAIR_CATEGORY].[MaintenanceRepairCategory] 'Light And Signalisation'. Je vais aussi ajouter des attributs dans la Table PART pour savoir sur quels Marque de véhicule, Modèle de véhicule et Année de véhicule les pièces vont.
4 - Puisque je ne suis pas un marchant de pièces, lorsqu'une pièce sort de la Table PART, elle doit se retrouver sur un des véhicules de la Table TRUCK alors elle doit sortir de l'inventaire par la Table MAINTENANCE_REPAIR.
5 - Les réparations n'ont pas toutes besoin de pièce.
6 - Certaines réparations ont besoin de plusieurs pièces.
7 - Il y a des pièces qui sont universelles, c'est à dire qu'elles peuvent être installées sur n'importe quel Camion.

P.S. Juste pour être certain qu'on introduit pas des erreurs. Dans votre schéma je vois DiffGVWR dans la Table CAMION. Le GVWR de la Table CAMION concerne le Camion et non un différentiel du Camion.

Suite à vos observations concernant le manuel, je propose ceci :

La table MAINTENANCE_REPAIR_TYPE change de nom et devient : MAINTENANCE_REPAIR_CATEGORY. Ses attributs sont renommés en MaintenanceRepairCategoryId et MaintenanceRepairCategory...

Concernant les maintenances/réparations…

[ordigil]

USE --- [DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH]

SET ANSI_NULLS ON

SET QUOTED_IDENTIFIER ON

CREATE TABLE [dbo].[ADDRESS_BOOK]
    (
    [BusinessId]    [int] IDENTITY(1,1) NOT NULL,
    [BusinessName]  [varchar](50)       NOT NULL,
    [CivicNumber]   [char](10)          NOT NULL    DEFAULT ('-'),
    [StreetName]    [varchar](50)       NOT NULL    DEFAULT ('_'),
    [City]          [varchar](50)       NOT NULL    DEFAULT ('_'),
    [Province]      [char](3)           NOT NULL    DEFAULT ('--'),
    [PostalCode]    [char](7)           NOT NULL    DEFAULT ('--- ---'),
    [PhoneNumber]   [char](12)          NOT NULL    DEFAULT ('000-000-0000'),
    [FaxNumber]     [char](12)          NOT NULL    DEFAULT ('000-000-0000'),
    [CellNumber]    [char](12)          NOT NULL    DEFAULT ('000-000-0000'),
    [WebSite]       [varchar](50)       NOT NULL    DEFAULT ('www.xxxxxxxx.com'),
    [ContactName]   [varchar](50)       NOT NULL    DEFAULT ('-')
    )

GO

[ordigil]

Bonjour fsmrel,

J'ai ça pour MAINTENANCE_REPAIR_V : Version modifiée

USE DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH
GO

SELECT        r.TruckVIN AS [Truck VIN]
            , r.TruckNumber AS [Truck Number]
            , s.TruckMilleageDate AS Date
            , s.TruckMilleage AS [Milleage(Km)]
            , c.MaintenanceRepairCategory AS [Repair Category]
            , h.Details AS [Repair Details]
            , h.Note AS [Repair Note]
            , x.PartNumber AS [Part Number]
            , x.PartName AS [Part Name]
            , f.BusinessName AS [Part Supplier]
            , f.City AS [Supplier City]
            , x.PartPrice AS [Part Cost]
            , g.BusinessName AS [Shop Name]
            , g.City AS [Shop City]
            , h.LaborCost AS [Labor Cost]

FROM            dbo.TRUCK AS r
    INNER JOIN  dbo.TRUCK_MILLEAGE AS s ON r.TruckId = s.TruckId
    INNER JOIN  dbo.MAINTENANCE_REPAIR AS h ON s.TruckId = h.TruckId AND s.TruckMilleageId = h.TruckMilleageId
    INNER JOIN  dbo.M_R_PART AS a ON h.TruckId = a.TruckId
            AND h.TruckMilleageId = a.TruckMilleageId
            AND h.MaintenanceRepairId = a.MaintenanceRepairId
    INNER JOIN dbo.PART_CATEGORY AS b ON a.MaintenanceRepairCategoryId = b.MaintenanceRepairCategoryId
            AND a.PartId = b.PartId
    INNER JOIN dbo.MAINTENANCE_REPAIR_CATEGORY AS c ON b.MaintenanceRepairCategoryId = c.MaintenanceRepairCategoryId
    INNER JOIN dbo.PART AS x ON b.PartId = x.PartId
    INNER JOIN dbo.PART_ADDRESS_BOOK AS d ON x.PartId = d.PartId
    INNER JOIN dbo.SHOP AS e ON h.ShopId = e.ShopId
    INNER JOIN dbo.ADDRESS_BOOK AS f ON d.SupplierId = f.BusinessId
    INNER JOIN  dbo.ADDRESS_BOOK AS g ON e.ShopId = g.BusinessId