Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #861
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut Table WORK_ORDER

    J'ai débuté cette nouvelle Table :

    --- USE [DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH]
    GO
    
    /****** Object:  Table [dbo].[WORK_ORDER]    Script Date: 06/01/2019 19:44:30 ******/
    SET ANSI_NULLS ON
    GO
    
    SET QUOTED_IDENTIFIER ON
    GO
    
    CREATE TABLE [dbo].[WORK_ORDER]
        (
    	[WorkOrderId] [int] IDENTITY(1,1) NOT NULL,
    	[BillNumber] [char](15) NOT NULL DEFAULT ('Dzindzio Shop'),
    	[PartCost] [numeric](8, 2) NOT NULL DEFAULT ((0)),
    	[LaborCost] [numeric](8, 2) NOT NULL DEFAULT ((0)),
     
        )
    GO
    
    

  2. #862
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Bonsoir Ordigil,


    Citation Envoyé par ordigil Voir le message
    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 signification particulière.
    Donc les accès par l’utilisateur à la table MAINTENANCE_REPAIR_CATEGORY seront faits exclusivement au moyen de l’attribut MaintenanceRepairCategory, tandis que seules les jointures avec cette table mettront en jeu l’attribut MaintenanceRepairCategoryId. Est-on d’accord ?


    Citation Envoyé par ordigil Voir le message
    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.
    Juste un copier/coller foireux dans l’image.


    De l’importance de la précision dans la description des structures :

    Dans le post pour le moment numéroté #824, la table des pièces est nommée PARTS_CATALOG (j’abrège en PART). Son nom tend à faire comprendre que cette table contient les différents types de pièces au catalogue des fournisseurs, comme dans tous les modèles de données traditionnels. Mais à y regarder de plus près, il s’agit non seulement de cela (présence des attributs PartName et PartPrice), mais aussi de votre propre stock de pièces (présence des attributs QuantityInventory et PurchaseDate).

    Un point sur lequel je tiens à ce qu’on se mette d’accord : une ligne de la table PART représente un nombre n de pièces identiques et non pas une pièce en particulier, auquel cas l’unicité du nom de ces pièces ne serait pas garantie, et QuantityInventory vaudrait seulement soit 0 (disons pièce sur un camion) soit 1 (pièce dans le stock).

    Si donc une ligne de la table PART représente un nombre n de pièces identiques, il faut quand même observer que l’attribut PurchaseDate vient perturber le jeu : les n pièces n’ont pas forcément été achetées en même temps, le prix d’achat (PartPrice) pouvant par ailleurs fluctuer avec le temps.

    Qui plus est, je constate chez vous la présence d’une table PART_ADDRESS_BOOK (que je nommerais plutôt PART_SUPPLIER), conséquence vraisemblablement de la règle suivante :

    Citation Envoyé par ordigil Voir le message
    6- Des pièces ayant le même nom peuvent avoir été achetées chez des fournisseurs différents.

    S’il en est bien ainsi, alors la date d’achat (PurchaseDate) devrait migrer dans une nouvelle table, appelons-la PURCHASE (ou tout autre nom vous convenant) attachée à la table PART_SUPPLIER). De même, les fournisseurs ne proposant pas les mêmes prix, l’attribut PartCost devrait migrer lui aussi dans cette table.
    Pour distinguer les achats, la table PURCHASE est à doter d’un attribut PurchaseId (de type IDENTITY).


    Citation Envoyé par ordigil Voir le message
    1 - Toutes maintenances et toutes réparations doivent impérativement avoir une référence à un des chapitres de la table MAINTENANCE_REPAIR_CATEGORY.
    5 - Les réparations n'ont pas toutes besoin de pièce.
    On met donc en oeuvre une table à cet effet, nommons-la M_R_SANS_PART (à angliciser...), de clé primaire {CamionId, CamionMilleageId, MaintenanceRepairId} et associant les tables MAINTENANCE_REPAIR et MAINTENANCE_REPAIR_CATEGORY.


    Citation Envoyé par ordigil Voir le message
    6 - Certaines réparations ont besoin de plusieurs pièces.
    La clé primaire de la table M_R_PART devient donc {CamionId, CamionMilleageId, MaintenanceRepairId, PartId}.
    Pour contraster avec M_R_SANS_PART, la table M_R_PART pourrait être renommée M_R_AVEC_PART.


    Citation Envoyé par ordigil Voir le message
    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.
    Soit. Cela milite pour l’externalisation des attributs relatifs au manufacturier et au modèle (table CAMION et COMPOSANT), avec à la clé le respect de la troisième forme normale.


    L’attribut PartNumber prend par défaut la valeur 0. Autrement dit, certaines pièces peuvent ne pas avoir de numéro. Je souhaiterais que vous explicitiez cette partie, comme vous l’avez fait pour le numéro des camions..

    Votre table SHOP contient une clé étrangère SHOP_MAINTENANCE_REPAIR_FK qui est une scorie à supprimer.


    Sémantiquement parlant, le nom de table ADDRESS_BOOK ne convient pas. En effet, cela laisse supposer que chaque ligne de la table décrit un carnet d’adresses et non pas une personne morale. Pour le moment, j’ai remplacé ce nom par ACTEUR, choix qui n’est probablement pas le meilleur, mais vous trouverez certainement le nom le plus approprié.


    Vous avez entamé la déclaration d’une table nommée WORK_ORDER. Il s’agit d’y engranger des commandes ? des factures ?


    La situation de mon côté est pour le moment la suivante (aux coquilles près) :

    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #863
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    ADDRESS BOOK ---->>> An address book or a name and address book (NAB) is a book or a database used for storing entries called contacts. Each contact entry usually consists of a few standard fields (for example: first name, last name, company name, address, telephone number, e-mail address, fax number, mobile phone number).

  4. #864
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Bonsoir fsmrel
    J'espère que je ne fais pas d'erreurs dans les réponses que je vous donne. C'est en effectuant des 'Insert' dans les tables que je réalise parfois que j'ai fait une erreur dans un énoncé ou que celui-ci était ambiguë… Mais vous semblez lire dans mes pensées


    Citation Envoyé par fsmrel
    Donc les accès par l’utilisateur à la table MAINTENANCE_REPAIR_CATEGORY seront faits exclusivement au moyen de l’attribut MaintenanceRepairCategory.
    Oui, seulement le nom du chapître est important. Celà permet de classifier un peu le type de réparations effectuées sur les Camions et si un inspecteur du gouvernement passe pour vérifier, il connait par coeur les noms des chapîtres.

    ------------------------
    Citation Envoyé par fsmrel
    Son nom tend à faire comprendre que cette table contient les différents types de pièces au catalogue des fournisseurs, comme dans tous les modèles de données traditionnels. Mais à y regarder de plus près, il s’agit non seulement de cela (présence des attributs PartName et PartPrice), mais aussi de votre propre stock de pièces (présence des attributs QuantityInventory et PurchaseDate).
    C'est exactement comme ça que mes fournisseurs fonctionnent.
    1 - Mes fournisseurs ont eux-mêmes beaucoup de fournisseurs.
    2 - Ils ont beaucoup de catalogues de pièces de leurs fournisseurs.
    3 - Ils achètent de différents fournisseurs pour constituer leur propre inventaire de pièces.
    4 - Ils utilisent donc généralement le numéro de pièce du manufacturier décrivant la pièce et non le numéro de pièce du fournisseur.
    Donc mes fournisseurs qui ont eux-mêmes des fournisseurs ont une table PART contenant PartName, PartPrice, QuantityInventory, PurchaseDate, Brand, Manufacturer, et à chaque fois qu'il vendent une pièce, la quantité dans leur inventaire diminue. Donc si je téléphone à un de mes fournisseurs et que je lui demande combien de lumières de type 9006 il a en inventaire, il va me dire combien il en a. Si je lui dis que j'en ai besoin de 15 et qu'il en a 12, il va me dire, j'en ai 12 et ça va prendre 2 semaines pour que j'en reçoivent d'autres. Donc que le manufacturier soit Sylvania, Wagner ou etc., etc., 9006 ne change jamais par contre Sylvania a son propre numéro de pièce, Wagner a son propre numéro de pièce, etc., etc. Je me retrouve donc avec beaucoup de numéros de pièces pour des pièces identiques ou équivalentes.

    -------------------------------

    Citation Envoyé par fsmrel
    Un point sur lequel je tiens à ce qu’on se mette d’accord : une ligne de la table PART représente un nombre n de pièces identiques et non pas une pièce en particulier, auquel cas l’unicité du nom de ces pièces ne serait pas garantie, et QuantityInventory vaudrait seulement soit 0 (disons pièce sur un camion) soit 1 (pièce dans le stock).

    Si donc une ligne de la table PART représente un nombre n de pièces identiques, il faut quand même observer que l’attribut PurchaseDate vient perturber le jeu : les n pièces n’ont pas forcément été achetées en même temps, le prix d’achat (PartPrice) pouvant par ailleurs fluctuer avec le temps.
    Nous sommes d'accord sur ce point.

    --------------------------------------

    Citation Envoyé par fsmrel
    Qui plus est, je constate chez vous la présence d’une table PART_ADDRESS_BOOK (que je nommerais plutôt PART_SUPPLIER), conséquence vraisemblablement de la règle suivante :...
    Je suis d'accord avec vous, c'est une Table que j'ai oubliée de renommer car à l'origine j'avais un ADDRESS_BOOK pour les SHOP et un ADDRESS_BOOK pour les fournisseurs de pièces que j'ai réunis dans un seul ADDRESS_BOOK.

    -------------------------------------

    Citation Envoyé par fsmrel
    S’il en est bien ainsi, alors la date d’achat (PurchaseDate) devrait migrer dans une nouvelle table, appelons-la PURCHASE (ou tout autre nom vous convenant) attachée à la table PART_SUPPLIER). De même, les fournisseurs ne proposant pas les mêmes prix, l’attribut PartCost devrait migrer lui aussi dans cette table.
    Pour distinguer les achats, la table PURCHASE est à doter d’un attribut PurchaseId (de type IDENTITY)....

    Entièrement d'accord avec vous.

    -------------------------------

    Citation Envoyé par fsmrel
    On met donc en oeuvre une table à cet effet, nommons-la M_R_SANS_PART...
    La clé primaire de la table M_R_PART devient donc {CamionId, CamionMilleageId, MaintenanceRepairId, PartId}.
    Pour contraster avec M_R_SANS_PART, la table M_R_PART pourrait être renommée M_R_AVEC_PART.
    Entièrement d'accord.

    --------------------------------

    Citation Envoyé par fsmrel
    L’attribut PartNumber prend par défaut la valeur 0. Autrement dit, certaines pièces peuvent ne pas avoir de numéro. Je souhaiterais que vous explicitiez cette partie, comme vous l’avez fait pour le numéro des camions..
    Ceci est pour contourner temporairement un problème lorsque nous ne connaissons pas le numéro de pièce mais que nous entrerons quand même dans la base de données. Ceci sera éventuellement corrigé par l'utilisateur final lorsqu'il recevra la facture du fournisseur...et peut-être jamais..s'il oublie. Car si nous installons une pièce sur un camion, il faut quelle apparaisse à quelque part cette pièce.

    Si vous avez une autre solution à proposer je vous écoute ;-)

    -------------------------------

    Citation Envoyé par fsmrel
    Votre table SHOP contient une clé étrangère SHOP_MAINTENANCE_REPAIR_FK qui est une scorie à supprimer.
    Merci vous être d'un très grand secours ;-)

    -----------------------------

    Citation Envoyé par fsmrel
    Sémantiquement parlant, le nom de table ADDRESS_BOOK ne convient pas.
    Le nom convient parfaitement. "Address book" = "Carnet d'adresses" C'est exactement ce que nous avons.

    ------------------------------

    Citation Envoyé par fsmrel
    Vous avez entamé la déclaration d’une table nommée WORK_ORDER. Il s’agit d’y engranger des commandes ? des factures ?
    En réalité c'est un peu complexe. :-( Le but est de savoir combien une réparation ou une maintenance a couté en incluant le coût des pièces et le coût de la main-d'oeuvre comme la facture que vous recever lorsque vous apportez votre voiture dans un centre de réparation (garage). Donc si la réparationest effectué dans notre atelier, il n'y aura que le coût des pièces et si la réparation a été effectué ailleur, il y aura le coût des pièces et le coût de la main-d'oeuvre. Peut-être pourrions-nous sortir Details et Notes de la Table MAINTENANCE_REPAIR et les inclure dans WORK_ORDER. J'attendais d'en discuter avec vous avant de faire quoi que ce soit... Peut-être même que vous avez une autre solution à proposer. :-)

    ---------

    J'aime beaucoup votre modèle, il semble correspondre à tous les points énumérés. C'est un peu difficile pour moi de tout reconstituer dans DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH avec toutes ces clés, je m'y perd un peu et parfois beaucoup :-( Je vais attendre que vous mettiez tout ça dans DZINDZIO_TRUCKS_MANAGEMENT_TEMPS et je traduirai pour DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH.

  5. #865
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Bonsoir Ordigil,


    Citation Envoyé par ordigil Voir le message
    je lui demande combien de lumières de type 9006 il a en inventaire.
    Pour m’éclairer :-) dans cet exemple, quel est le nom de cette pièce dans votre table PART ?



    Citation Envoyé par ordigil Voir le message
    Je me retrouve donc avec beaucoup de numéros de pièces pour des pièces identiques ou équivalentes.
    Si le besoin s’en fait sentir, vous pouvez déclarer une table, appelons-la par exemple PART_ALIAS (voyez le diagramme ci-dessous), permettant de connaître les numéros affectés par chacun de vos fournisseurs. Pour sa part, l’attribut PartNumber de la table PART permet de connaître le numéro de pièce que vous affectez vous-même à une pièce (auquel cas, histoire d’éviter les quiproquos, PartNumber pourrait y être renommé en PartDzindzioNumber ou autre nom du même genre, voyez le diagramme ci-dessous). Mais si vous ne voulez pas mettre en oeuvre votre propre numérotation des pièces, supprimez cet attribut de la table PART et, si cela suffit, utilisez la table PART_ALIAS pour vos contacts avec les fournisseurs.




    Citation Envoyé par ordigil Voir le message
    Si vous avez une autre solution à proposer je vous écoute ;-)
    Je suis tout ouïe ;-) En relation avec ce qui précède, je suis plutôt favorable à une numérotation automatique assurée par vous-même (attribut PartDzindzioNumber, faisant l’objet d’une clé candidate) outre la mise en oeuvre de la table PART_ALIAS pour retrouver les équivalences chez les fournisseurs).



    Citation Envoyé par ordigil Voir le message
    Le nom convient parfaitement. "Address book" = "Carnet d'adresses" C'est exactement ce que nous avons.
    Le quart-heure sémantique ;-)

    Du point de vue de l’utilisateur, "Address book" convient, je suis évidemment d’accord. Même chose du point de vue de l’informaticien. Même chose du point de vue de la théorie des ensembles : un carnet d’adresses est un ensemble dont les éléments sont les contacts. Mais quand on modélise une base de données relationnelle, on change de registre, on passe de l’informel au formel, on déclare des variables de type RELATION en se conformant en l’occurrence à la logique du 1er ordre et au calcul relationnel, fondements de la théorie relationnelle bâtie par Ted Codd (cf. A Relational Model for Large Shared Data Banks, paragraphe 1.5), soit :

    « L'utilisation d'un modèle relationnel de données [...] permet de développer un sous-langage universel basé sur le calcul des prédicats. Si la collection des relations est en forme normale, alors un calcul des prédicats du premier ordre est suffisant. »

    Dans ce contexte, modéliser un carnet d’adresses consiste à déclarer une variable, appelons-la CARNET, constituant un prédicat (CARNET) dont les propositions sont « carnet 1 », « carnet 2 », ..., « carnet n », mais Dzindzio n’a qu’un seul carnet à gérer ! Celui de ses fournisseurs, ateliers, garages et autres entités du même métal. Par contre, pour traiter des fournisseurs, des ateliers et compagnie, et si je reprends le terme générique « acteur » (un fournisseur est un acteur, un atelier est un acteur), les propositions de mon prédicat sont « acteur 1 », « acteur 2 », ..., « acteur n » : il s’ensuit qu’il est naturel de nommer « ACTEUR » ce prédicat.

    Je le répète, si vous avez un autre nom à proposer, n’hésitez pas, mais pas de BOOK ! Un fournisseur n’est pas un carnet !

    Vous pourriez aussi engager une disputatio et m’opposer ceci :

    « Un carnet peut faire référence à au plus un shop, et un shop fait référence à au moins et au plus un carnet, à savoir le sien ! »

    Auquel cas je m’inclinerai et conserverai le nom ADDRESS_BOOK tout en laissant tomber ACTEUR... Bien entendu, si on se situait à un niveau supérieur d’abstraction (modèle conceptuel des données (MCD) merisien par exemple, ou diagramme de classes UML), je réfuterais au nom de la spécialisation/généralisation des entités-types, mais je ne vais pas vous embêter avec ça…



    Citation Envoyé par ordigil Voir le message
    C'est un peu difficile pour moi de tout reconstituer dans DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH avec toutes ces clés
    Déjà pour que vous puissiez mieux lire le diagramme, j’ai changé la notation des associations entre table, en remplaçant les flèches par quelque chose de plus explicite (notation « patte de corbeau », comme avec MySQL Workbench, cf. le post #9, ou encore ici).

    En passant, observez l’association --|--------o-- entre ADDRESS_BOOK et SHOP : un acteur fait référence à au plus un shop, et un shop fait référence à au moins et au plus un acteur (et pas à un carnet...)

    Quant aux clés candidates (primaires ou alternatives) affectées à une table, souvenez-vous que pour une valeur de clé, on garantit qu’on a au moins et au plus une valeur pour chaque attribut de la table.

    Exemple 1 :

    La paire {CamionId, CamionMilleageId} est clé (primaire) de la table CAMION_MILLEAGE, donc pour une valeur de cette paire on a une seule valeur pour chacun des attributs CamionId, CamionMilleageId, CamionMilleageDate, CamionMilleage.

    La paire {CamionId, CamionMilleageDate} est clé (alternative) de la table CAMION_MILLEAGE, donc là aussi pour une valeur de cette paire on a une seule valeur pour chacun des attributs CamionId, CamionMilleageId, CamionMilleageDate, CamionMilleage.

    La paire {CamionId, CamionMilleage} est clé (alternative) elle aussi de la table CAMION_MILLEAGE, donc là encore pour une valeur de cette paire on a une seule valeur pour chacun des attributs CamionId, CamionMilleageId, CamionMilleageDate, CamionMilleage.

    Exemple 2 :

    Le triplet {CamionId, CamionMilleageId, MaintenanceRepairId} est clé de la table M_R_NO_PART, donc pour une valeur de ce triplet on a une seule valeur pour chacun des attributs CamionId, CamionMilleageId, MaintenanceRepairId, et MaintenanceRepairCategoryId.

    Exemple 3 :

    Le quadruplet {CamionId, CamionMilleageId, MaintenanceRepairId, PartId} est clé (primaire) de la table M_R_PART, donc pour une valeur de ce quadruplet on a une seule valeur pour chacun des attributs CamionId, CamionMilleageId, MaintenanceRepairId, PartId et MaintenanceRepairCategoryId.

    Par contre, le triplet {CamionId, CamionMilleageId, MaintenanceRepairId} n’est pas clé de la table M_R_PART, sinon pour une valeur de ce triplet on aurait une seule valeur pour l’attribut PartId, c’est-à-dire que pour une réparation on ne pourrait avoir qu’une seule pièce, contrairement à ce qui est demandé.



    Citation Envoyé par ordigil Voir le message
    Peut-être pourrions-nous sortir Details et Notes de la Table MAINTENANCE_REPAIR et les inclure dans WORK_ORDER.
    Je regarderai cela, mais essayons déjà d’entériner ce qui précède.


    Le diagramme du jour :

    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  6. #866
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Bonsoir fsmrel :-) Merci encore d'être là ;-)

    Nous avons de longs messages


    ----------------

    Envoyé par ordigil
    je lui demande combien de lumières de type 9006 il a en inventaire.

    Envoyé par fsmrel
    Pour m’éclairer :-) dans cet exemple, quel est le nom de cette pièce dans votre table PART ?


    Dans la Table PART j'aurai : Light Type 9001, Light Type 9002, Light Type 9003, Light Type 9004, Light Type 9005, Light Type 9007, etc. Ce sont toutes des lumières différentes. J'aurai aussi : Red Oval Reflector, Round Stop/Tail/Turn LED , Oval Stop/Tail/Turn LED, Miniature Lamp 3157 Orange, Miniature Lamp 3157 Clear et plusieurs autres...

    ----------------

    Envoyé par ordigil
    Je me retrouve donc avec beaucoup de numéros de pièces pour des pièces identiques ou équivalentes.

    Envoyé par fsmrel
    Si le besoin s’en fait sentir, vous pouvez déclarer une table, appelons-la par exemple PART_ALIAS

    Très bonne idée, et de cette façon vous venez de régler un problème...

    -----------------

    Envoyé par fsmrel
    Mais si vous ne voulez pas mettre en oeuvre votre propre numérotation des pièces, supprimez cet attribut de la table PART et, si cela suffit, utilisez la table PART_ALIAS


    Envoyé par Ordigil
    L'idée est excellente sauf que dans mon cas avec un inventaire minimum ça ne ferait que compliquer l'entrée des données dans la BD. Avec PART_ALIAS on règle le problème.

    L'important c'est :

    1 - Combien de lumières j'ai au total dans l'inventaire
    2 - Combien de lumières Type 9004 ou Round Stop/Tail/Turn LED j'ai dans l'inventaire. On peu faire un SELECT …. WHERE columnN LIKE %pattern%;

    ---------------

    Envoyé par ordigil
    Si vous avez une autre solution à proposer je vous écoute ;-)

    Envoyé par fsmrel
    Je suis tout ouïe ;-) En relation avec ce qui précède, je suis plutôt favorable à une numérotation automatique assurée par vous-même

    Oui la numérotation automatique mais pour l'instant je vais essayer avec uniquement la Table PART-ALIAS sans PartDzindzioNumber

    ----------------------------

    Envoyé par ordigil
    Le nom convient parfaitement. "Address book" = "Carnet d'adresses" C'est exactement ce que nous avons.

    Envoyé par fsmrel
    Le quart-heure sémantique ;-)

    Vous avez raison mais parce qu'il y a toujours un mais hahaha ADDRESS_BOOK est mon annuaire téléphonique où vos 'Acteurs' sont mes 'Contacts'. Je regroupe tous mes contacts dans une seule et unique Table que je nomme ADDRESS_BOOK. Dans la table Camion, j'ai une date d'Achat et une date de Vente ce qui implique que j'ai des Contacts pour ces transactions alors ces transactions devrons être reliées à un contant dans la Table ADDRESS_BOOK. La même chose pour la Table Composant, si j'achète un Moteur ou si je le vend, j'ai assurément un Contact pour ces transactions dans la Table ADDRESS_BOOK.

    Si vous faites ceci :

    USE DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH

    SELECT * FROM ADDRESS_BOOK ;

    Vous obtenez ceci : Et si vous me dites que ce n'est pas la façon de procéder, je vous donnerai entièrement raison mais parce qu'il y a toujours un mais, c'est la seule et unique façon qui fonctionne efficacement avec le main-libre alors j'utilise cette façon dans la base de données puisque l'utilisateur final utilise cette façon avec son celluaire, portable et son cardex.

    Nom : ADDRESS_BOOK.JPG
Affichages : 41
Taille : 129,5 Ko


    -------------------------------------

    Envoyé par ordigil
    C'est un peu difficile pour moi de tout reconstituer dans DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH avec toutes ces clés

    Envoyé par fsmrel
    Déjà pour que vous puissiez mieux lire le diagramme, j’ai changé la notation des associations entre table, en remplaçant les flèches par quelque chose de plus explicite (notation « patte de corbeau », comme avec MySQL Workbench, cf. le post #9, ou encore ici).

    Juste comme ça...
    MySQL est en fin de vie....., Oracle va le faire mourir qu'on le veule ou non... C'est la réalité... Oracle ne développera pas deux produits qui ont la même fonction alors qu'un est gratuit et entre en compétition direct avec son produit phare payant. La version 8.0 de MySQL n’est pas prise en charge par Solaris aussi bien Sparc que x86. Les processeurs Sparc vont probablement disparaître eux aussi. Le HIC c'est qu'une entreprise a acheté des serveurs Sparc et ils lui sont complètement inutiles puisque MySQL 8 n'est pas prise en charge par Solaris. Petite surprise en douceur d'Oracle...


    Merci pour les nouvelles notations des associations entre tables. ----0 et ----1 c'est plus facile à suivre que ----> hehehe

    Mon problème est que nous effectuons beaucoup de changement dans la base de données et oups j'oublie d'enlever les associations désuètes ou j'oublie de compléter les nouvelles. Nous semblons faire du surplace mais nous évoluons rapidement hahaha...

    -------------------------

    Merci pour le nouveau diagramme, alors je prend PART_ALIAS et mais l'instant je ne prend pas PartDzindzioNumber bien que ce soit une bonne idée, je vais voir si je peux m'en passer et utiliser unique PART_ALIAS.

    À chaque fois que vous trouvez une solution, je crée un nouveau défit, c'est la magie d'internet :-) À chaque fois que vous mettez le schéma à jour, je réalise que nous pouvons nous en servir pour compléter d'autres Tables. :-)

  7. #867
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Ordigil, pouvez-vous jeter un coup d'œil aux tables que j'ai créées dans DZINDZIO_TRUCKS_MANAGEMENT_TEMP ?


    Citation Envoyé par ordigil
    Dans la Table PART j'aurai : Light Type 9001, Light Type 9002, Light Type 9003, Light Type 9004, Light Type 9005, Light Type 9007, etc.
    C'est bien dans la colonne PartName ?
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  8. #868
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Avec plaisir. Et dans DZINDZIO_TRUCK_MANAGEMENT_TEMP vous y allez d'après les normes, je peux adapter dans DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH.


    Citation Envoyé par fsmrel Voir le message
    Ordigil,pouvez-vousjeteruncoupd'œilauxtablesquej'aicrééesdansDZINDZIO_TRUCKS_MANAGEMENT_TEMP?

  9. #869
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Oui, ce sont tous des noms différents pour des pièces différentes.

    Light Type 9001, Light Type 9002, Light Type 9003, Light Type 9004, Light Type 9005, Light Type 9007, etc.

    [QUOTE =fsmrel] C'est bien dans la colonne PartName ?[/QUOTE]

  10. #870
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Dans PART_SUPPLIER votre 'Acteur' représente mon 'Supplier' = Magasin #1, Magasin #2, Magasin #3, etc...
    Dans PART_ALIAS votre 'Acteur' représente mon 'Brand' = Wagner, Sylvania, Pionner, RCA, Phillips, etc...



    Dans AXLE et DIFFERENTIAL, j'ai enlevé AxleSeries et DiffSerie car nous devons faire une recherche sur le site internet des Manufacturiers pour les trouver à l'aide des numéros de série. Le Model et le Numéro de série sont suffisants.

    Dans Composant j'ai ajouté ComposantMfgDate et ComposantSaleDate, ceux-ci sont importants.

    Dans OIL_CHANGE, j'ai ajouté OilBrand, OilRange, OilViscosity qui sont importants.

    Dans Camion, j'ai enlevé tous les GAWR, je n'ai conservé que le GVWR, nous ferons une table dédiées au GAWR plus tard..

  11. #871
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Bonjour Ordigil,



    Citation Envoyé par ordigil Voir le message
    Dans la table Camion, j'ai une date d'Achat et une date de Vente ce qui implique que j'ai des Contacts
    Ce qui incite à peut-être renommer ADDRESS_BOOK en CONTACT. En effet, un camion n’a pas été acheté à un carnet d’adresses ! :-)

    En attendant, le diagramme ci-dessous prend en compte les dates d’achat et de vente en relation avec les contacts impliqués dans ces opérations, avec les règles de gestion suivantes :

    Un contact peut vendre plusieurs camions,
    Un camion ne peut être vendu qu’à un et un seul contact,

    Un contact peut acheter plusieurs camions,
    Un camion ne peut être acheté que par un et un seul contact,

    Un contact peut vendre plusieurs composants,
    Un composant ne peut être vendu qu’à un et un seul contact,

    Un contact peut acheter plusieurs composants,
    Un composant ne peut être acheté que par un et un seul contact.

    Dans l’état du modèle, vous ne pourrez pas acheter ou vendre à nouveau un matériel (camion, composant) que vous avez déjà acheté ou vendu, sinon en remplaçant les anciennes valeurs (contact, date) par les nouvelles.



    A cette occasion, je constate que la table LOCAL joue un rôle de moins en moins important, pour ne pas dire nul. De mon côté, je n’aurai pas d’état d’âme à la supprimer. Cela conduirait à supprimer la table LOCALISATION et brancher directement COMPOSANT_AFFECTATION sur CAMION. Evidemment, cela conduirait nécessairement à modifier certaines vues et certains triggers.

    Votre point de vue sur tout cela ?


    Table PART

    Actuellement, la table PART n’a pas de clé candidate naturelle, or pour que l’utilisateur puisse accéder à une pièce en particulier, il en faut une, sinon les doublons seront à l’affût et ficheront la patouille. Pour le moment il n’y a que PartName qui puisse tenir le rôle (à moins que PartDzindzioNumber et la numérotation automatique soient mis en oeuvre de telle sorte qu’on ait là une clé naturelle) :


    CONSTRAINT PART_AK UNIQUE (PartName)
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #872
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Citation Envoyé par fsmrel
    Ce qui incite à peut-être renommer ADDRESS_BOOK en CONTACT. En effet, un camion n’a pas été acheté à un carnet d’adresses ! :-)
    Ok je vous accorde CONTACT ce qui fait plus représentatif que ACTEUR. Bien que le camion n'a pas été acheté à un carnet d'adresses, il a été acheté d'un contact dans ce carnet d'adresses. Alors lorsque je regarde la Table CONTACT, c'est un carnet d'adresse. Lorsque j'appellerai la Table CONTACT sur le site WEB, elle sera tout simplement nommée Address Book dans le Titre. Alors la base de données conservera les standards et en plus je ne veux pas que vous me fassiez des concessions pour me faire plaisir, lorsque c'est possible on le fait, sinon je m'arrange avec le site WEB. L'important c'est la base de données elle-même. On y va avec CONTACT . Le seul hic c'est l'utilisation des mêmes noms de colonnes dans différentes Tables mais je peux contourner le problème comme je l'ai fait dans la vue TRUCK_MAINTENANCE_REPAIR_V à moins qu'il y ait une autre façon plus Orthodoxe de procéder.


    Citation Envoyé par fsmrel
    A cette occasion, je constate que la table LOCAL joue un rôle de moins en moins important, pour ne pas dire nul. De mon côté, je n’aurai pas d’état d’âme à la supprimer. Cela conduirait à supprimer la table LOCALISATION et brancher directement COMPOSANT_AFFECTATION sur CAMION. Évidemment, cela conduirait nécessairement à modifier certaines vues et certains triggers.

    Votre point de vue sur tout cela ?

    Et si j'enlève un moteur et une transmission d'un Camion et que je ne les vend pas ? Disons que je les entrepose dans mon garage pour usage futur ??? Ce qui est le cas présentement...



    Citation Envoyé par fsmrel
    Table PART

    Actuellement, la table PART n’a pas de clé candidate naturelle, or pour que l’utilisateur puisse accéder à une pièce en particulier, il en faut une, sinon les doublons seront à l’affût et ficheront la patouille. Pour le moment il n’y a que PartName qui puisse tenir le rôle (à moins que PartDzindzioNumber et la numérotation automatique soient mis en oeuvre de telle sorte qu’on ait là une clé naturelle) :


    CONSTRAINT PART_AK UNIQUE (PartName)

    Alors allons-y avec 'PartDzindzioNumber' ou 'DzindzioPartNumber' qui dans la plupart de cas sera le numéro de pièce d'un des fabricants ce qui implique que j'aurai de toute façon plusieurs numéros de pièce pour une même pièce ou bien une numérotation automatique qui ne veut rien dire mais qui permettra d'éviter les doublons.

    Ce qui est important c'est de savoir c'est combien j'ai de 'Lumières Type 9004' dans mon inventaire et qui me les a vendu et à quel prix et non le nom du fabricant.

    On se rapproche tranquillement d'une vraie base de données

  13. #873
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Bonjour Ordigil,


    Retour sur le diagramme proposé hier (9 janvier) :

    Je propose finalement que les dates d’achat et de vente des matériels (camions, composants) retrouvent leur place initiale, c’est-à-dire dans les tables CAMION et COMPOSANT. En effet, si par exemple on ne se souvient pas de la date d’achat d’un composant, de sa date de vente (ou s’il n’a pas été vendu), conceptuellement parlant ça n’a pas de sens de faire figurer une date absente dans les tables associatives (TRUCK_SALE, TRUCK_PURCHASE, COMPONENT_SALE, COMPONENT_PURCHASE), autant avoir accès directement à l’information dans les tables CAMION et COMPOSANT comme ça été le cas jusqu’ici (date '9999-12-31' en l’occurrence). Ainsi, les tables associatives ont pour seul rôle de dire à qui on a acheté ou vendu.

    Nouveau diagramme :


    J’ai renommé ADDRESS_BOOK en CONTACT :-)



    Citation Envoyé par ordigil Voir le message
    Lorsque j'appellerai la Table CONTACT sur le site WEB, elle sera tout simplement nommée Address Book dans le Titre.
    Bien vu, c’est parfaitement logique, séparation, indépendance des domaines oblige !



    Citation Envoyé par ordigil Voir le message
    Et si j'enlève un moteur et une transmission d'un Camion et que je ne les vend pas ? Disons que je les entrepose dans mon garage pour usage futur ??? Ce qui est le cas présentement...
    Si vous précisez le garage où vous entreposez un composant, histoire de bétonner le modèle et de sémantiser, on pourrait considérer vos garages comme des shops :




    Citation Envoyé par ordigil Voir le message
    Alors allons-y avec 'PartDzindzioNumber' ou 'DzindzioPartNumber' qui dans la plupart de cas sera le numéro de pièce d'un des fabricants ce qui implique que j'aurai de toute façon plusieurs numéros de pièce pour une même pièce ou bien une numérotation automatique qui ne veut rien dire mais qui permettra d'éviter les doublons.
    La multiplicité des numéros de pièces empêche de faire figurer ceux-ci dans la table PART : c’est notamment pour ça que la table PART_ALIAS a été définie.

    Quant à la numérotation automatique (colonne DzindzioPartNumber), sa mise en oeuvre n'a d'intérêt que si l’utilisateur s’en sert pour accéder à une pièce spécifique autrement que par son nom, si tant est qu’il ait besoin d’y accéder, c’est-à-dire s’il utilise plutôt PART_ALIAS..
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  14. #874
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Bonjour fsmrel :-)

    OK pour tout, je ne suis pas très en forme cette semaine. Je n'ai pas consacré beaucoup de temps à la BD. Par contre je vous lis et j'étudie vos diagrammes. Je vais commencer à modifier DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH à partir de DZINDZIO_TRUCKS_MANAGEMENT_TEMP et essayer quelques Inserts. Mon MacBook Pro est en panne alors avec le vieux TOSHIBA ce n'est pas très rapide.


    Citation Envoyé par fsmrel Voir le message
    Bonjour Ordigil,


    Retour sur le diagramme proposé hier (9 janvier) :

    Je propose finalement que les dates d’achat et de vente des matériels (camions, composants) retrouvent leur place initiale, c’est-à-dire dans les tables CAMION et COMPOSANT. En effet, si par exemple on ne se souvient pas de la date d’achat d’un composant, de sa date de vente (ou s’il n’a pas été vendu), conceptuellement parlant ça n’a pas de sens de faire figurer une date absente dans les tables associatives (TRUCK_SALE, TRUCK_PURCHASE, COMPONENT_SALE, COMPONENT_PURCHASE), autant avoir accès directement à l’information dans les tables CAMION et COMPOSANT comme ça été le cas jusqu’ici (date '9999-12-31' en l’occurrence). Ainsi, les tables associatives ont pour seul rôle de dire à qui on a acheté ou vendu.

    Nouveau diagramme :


    J’ai renommé ADDRESS_BOOK en CONTACT :-)




    Bien vu, c’est parfaitement logique, séparation, indépendance des domaines oblige !




    Si vous précisez le garage où vous entreposez un composant, histoire de bétonner le modèle et de sémantiser, on pourrait considérer vos garages comme des shops :






    La multiplicité des numéros de pièces empêche de faire figurer ceux-ci dans la table PART : c’est notamment pour ça que la table PART_ALIAS a été définie.

    Quant à la numérotation automatique (colonne DzindzioPartNumber), sa mise en oeuvre n'a d'intérêt que si l’utilisateur s’en sert pour accéder à une pièce spécifique autrement que par son nom, si tant est qu’il ait besoin d’y accéder, c’est-à-dire s’il utilise plutôt PART_ALIAS..

  15. #875
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Citation Envoyé par fsmrel
    Si vous précisez le garage où vous entreposez un composant, histoire de bétonner le modèle et de sémantiser, on pourrait considérer vos garages comme des shops :
    garage et shop c'est la même chose, garage est la traduction en français de shop...

  16. #876
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    6 580
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 6 580
    Points : 23 316
    Points
    23 316
    Billets dans le blog
    16

    Par défaut

    Bonjour Ordigil,


    points)
    Citation Envoyé par ordigil Voir le message
    Dans AXLE et DIFFERENTIAL, j'ai enlevé AxleSeries et DiffSerie car nous devons faire une recherche sur le site internet des Manufacturiers pour les trouver à l'aide des numéros de série. Le Model et le Numéro de série sont suffisants.

    Dans Composant j'ai ajouté ComposantMfgDate et ComposantSaleDate, ceux-ci sont importants.
    J’ai mis à jour DZINDZIO_TRUCKS_MANAGEMENT_TEMP en ce sens.



    Le 15 septembre dernier, vous écrivîtes :

    Citation Envoyé par ordigil Voir le message
    La marque d'huile n'est pas nécessaire puisqu'on utilise la même marque depuis 35 ans
    Puis le 9 janvier :

    Citation Envoyé par ordigil Voir le message
    Dans OIL_CHANGE, j'ai ajouté OilBrand, OilRange, OilViscosity qui sont importants.

    Cela dit, pour un composant donné (moteur M1, axle A1, etc.) utilise-t-on toujours la même marque ? La même gamme ? la même viscosité ? (Merci de préciser pour chacun de ces 3 points).


    Toujours dans la série « NBA, Portland Blazers », pour éviter des saisies approximatives d’huile, remet-on dans le circuit une table du genre de celle que j’ai décrite le 14 septembre ? (En l’aménageant cette fois-ci, en y faisant figurer par exemple le code-barres). Je rappelle l’ébauche faite à l’époque :



    Rappel de la situation folklorique des Blazers, selon laquelle Nicola Batum n’a manifestement rien mangé depuis qu’il a quitté Le Mans :





    Citation Envoyé par ordigil Voir le message
    garage et shop c'est la même chose, garage est la traduction en français de shop...
    Je sais cela. Ce que je veux dire, c’est qu’il s’agit cette fois-ci de ne plus pouvoir mettre n’importe quoi dans la table LOCAL, mais via SHOP d’y imposer une référence à votre garage, lequel est présent dans CONTACT.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  17. #877
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Citation Envoyé par fsmrel
    Puis le 9 janvier :

    Citation Envoyé par ordigil Voir le message
    Dans OIL_CHANGE, j'ai ajouté OilBrand, OilRange, OilViscosity qui sont importants.

    Cela dit, pour un composant donné (moteur M1, axle A1, etc.) utilise-t-on toujours la même marque ? La même gamme ? la même viscosité ? (Merci de préciser pour chacun de ces 3 points).
    Il y a des choses qui ont changé ici... :-( J'ai 4 camions qui ont de gros problèmes de moteur (moteurs sautés), ces 4 camions sortaient tous de chez le concessionnaire pour réparation... Il y a un problème quelque part..... Et nous utilisons la meilleure huile sur le marché pour les moteurs, transmission, différentiel... En gros, les concessionnaires n'ont pas de mécaniciens compétents pour réparer leur propres marques moteurs..... Alors on va inclure OilBrand, OilRange, OilViscosity dans la base de données. Moteur = 50 000 dollars canadiens...

    Citation Envoyé par fsmrel
    Rappel de la situation folklorique des Blazers, selon laquelle Nicola Batum n’a manifestement rien mangé depuis qu’il a quitté Le Mans :
    je ne change jamais de OilBrand, OilRange, OilViscosity mais ok pour une table qui leur est dédié comme dans votre diagramme...


    Citation Envoyé par fsmrel
    Je sais cela. Ce que je veux dire, c’est qu’il s’agit cette fois-ci de ne plus pouvoir mettre n’importe quoi dans la table LOCAL, mais via SHOP d’y imposer une référence à votre garage, lequel est présent dans CONTACT.
    Oui, c'est pour cette raison que j'ai inclus notre 'SHOP' dans 'CONTACT'

  18. #878
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    Je songe sérieusement à abandonner Windows 10 et le remplacer par Solaris ou Linux.... Quelle SGBD serait le plus près de SQL Server ???

  19. #879
    Membre actif
    Homme Profil pro
    Étudiant
    Inscrit en
    juillet 2018
    Messages
    557
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juillet 2018
    Messages : 557
    Points : 286
    Points
    286

    Par défaut

    À l'origine cette base de données devait être très banale servant pour les changements d'huile et nous avons créé un monstre mutant dont les fonctionnalités rivalisent avec tout ce qu'il y a sur le marché dans ce domaine... Elle a même des fonctionnalités qui n'existent pas dans les logiciels commerciaux... Et je suis persuadé que dans les logiciels commerciaux il y a des tonnes de code JScript ou de C# dans l'interface utilisateur pour compenser les faiblesses de leur modèle. Dans votre approche, tout ce passe dans la base de données elle-même ou entre SQL et PHP ce qui me permet de réduire au minimum les lignes de code dans l'interface utilisateur et de diminuer au minimum le trafic sur le réseau. Compatible avec tous les systèmes d'exploitation sans installation de logiciel ou de PlugIns puisque l'interface graphique utilise n'importe quel navigateur web. Merci fsmrel. J'ai beaucoup de plaisir avec vous.

    Il y aura beaucoup de travail à refaire dans les VUES pour les mettre à jour avec les Tables

  20. #880
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 991
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 991
    Points : 9 154
    Points
    9 154
    Billets dans le blog
    1

    Par défaut

    @Ordigil : je confirme que de nombreux de logiciels du commerce s'appuient sur un modèle de données défaillant, voire catastrophique dans certains cas et pas seulement les logiciels adressés aux petites entreprises, les grands compte chez qui j'interviens depuis de nombreuses années en sont aussi victimes. Pourtant ces très grandes sociétés disposent d'équipes informatiques internes qui devraient être en mesure de jauger la qualité du produit avant de signer le contrat, mais elles sont rarement consultées, l'enjeu financier et les relations privilégiées des fournisseurs avec les décideurs, ont bien plus de poids que la qualité et la robustesse du produit !

    @François : je ne viens sur ce fil qu'épisodiquement, pour distribuer quelques points amplement mérités vu la qualité des interventions - comme à l'accoutumée - la pertinence et la précision du propos, le temps consacré et tout ça dans la bonne humeur.
    Que dire d'autre que Bravo, Bravissimo !

    @Ordigil : à ce propos, vous avez oublié quelques +1 au bénéfice de votre bienfaiteur, à corriger d'urgence, les votes positifs quand ils sont mérités sont toujours les bienvenus

Discussions similaires

  1. Ajout dans une table et relation avec d'autres
    Par climz dans le forum Access
    Réponses: 5
    Dernier message: 12/05/2006, 16h32
  2. Création table et relations
    Par ptitdragon_eric dans le forum Langage SQL
    Réponses: 3
    Dernier message: 10/09/2005, 14h37
  3. table de relation
    Par tanjonaravelson dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 21/06/2005, 19h20
  4. Table de relation et sélection via jointure
    Par 73672 dans le forum Langage SQL
    Réponses: 11
    Dernier message: 09/11/2004, 10h33
  5. Problème avec mes tables de relation...
    Par mmike dans le forum PostgreSQL
    Réponses: 4
    Dernier message: 02/06/2003, 16h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo