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
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
Bonsoir Ordigil,
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 ?Envoyé par ordigil
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 :
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).
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.
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.
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) :
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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).
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
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.
------------------------
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.
-------------------------------
Nous sommes d'accord sur ce point.
--------------------------------------
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.
-------------------------------------
Entièrement d'accord avec vous.
-------------------------------
Entièrement d'accord.
--------------------------------
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 ;-)
-------------------------------
Merci vous être d'un très grand secours ;-)
-----------------------------
Le nom convient parfaitement. "Address book" = "Carnet d'adresses" C'est exactement ce que nous avons.
------------------------------
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.
Bonsoir Ordigil,
Pour m’éclairer :-) dans cet exemple, quel est le nom de cette pièce dans votre table PART ?
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.
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).
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…
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é.
Je regarderai cela, mais essayons déjà d’entériner ce qui précède.
Le diagramme du jour :
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
Pièce jointe 439848
-------------------------------------
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. :-)
Ordigil, pouvez-vous jeter un coup d'œil aux tables que j'ai créées dans DZINDZIO_TRUCKS_MANAGEMENT_TEMP ?
C'est bien dans la colonne PartName ?
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Avec plaisir. Et dans DZINDZIO_TRUCK_MANAGEMENT_TEMP vous y allez d'après les normes, je peux adapter dans DZINDZIO_TRUCKS_MANAGEMENT_ENGLISH.
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]
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..
Bonjour Ordigil,
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)
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
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...
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
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..
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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.
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..
garage et shop c'est la même chose, garage est la traduction en français de shop...
Bonjour Ordigil,
points)J’ai mis à jour DZINDZIO_TRUCKS_MANAGEMENT_TEMP en ce sens.
Le 15 septembre dernier, vous écrivîtes :
Puis le 9 janvier :La marque d'huile n'est pas nécessaire puisqu'on utilise la même marque depuis 35 ans
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 :
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.
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, 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 »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
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...
je ne change jamais de OilBrand, OilRange, OilViscosity mais ok pour une table qui leur est dédié comme dans votre diagramme...
Je songe sérieusement à abandonner Windows 10 et le remplacer par Solaris ou Linux.... Quelle SGBD serait le plus près de SQL Server ???
À 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
@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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
.png)
Partager