C'est fait, je les ai mis dans vos trois bases de données "Temp"
Envoyé par fsmrel
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
C'est fait, je les ai mis dans vos trois bases de données "Temp"
Bonjour Ordigil,
Je ne fais jamais de DROP DATABASE pour ces bases de données, tout comme pour Temp d’ailleurs. En effet, en ce qui me concerne, je ne vois pas pour quel motif je le ferais.
Merci ! J’ai fait un SELECT sur les deux tables dans Temp, mais elles étaient vides. Je les ai alimentées en les clonant depuis DZINDZIO_TRUCKS_MANAGEMENT_TEMP. C’est ce qu’il fallait faire ?
Donc finalement, dans le diagramme ci-dessous, la table QUANTITE_TYPE est trop contraignante, elle ne jouerait plus qu’un rôle secondaire : informer que, selon le catalogue du fabricant de camions, chacun de ses modèles est vendu avec tant de composants pour chaque type de composant (essieu, transmission, différentiel...)
Dans ce contexte, la table QUANTITE_TYPE perd beaucoup de son intérêt d’autant que le numéro de série indiquera le nombre d'essieux d'origine : cette table pourrait disparaître. C’est bien ce que vous entendez ?
Actuellement, le manufacturier et le modèle font l’objet des attributs CamionManufacturer et CamionModel de la table CAMION. Etant donné qu’un modèle ne fait référence qu’à un manufacturier, il existe ce qu’on appelle une dépendance fonctionnelle mettant en jeu ces deux attributs : {CamionModel} → {CamionManufacturer} en conséquence de quoi il y a violation de la forme normale de Boyce Codd (en fait de la deuxième forme normale), et du point de vue de la modélisation saitreslai
Pour le moment on peut rester en l’état, mais quand on aura un peu de temps, il faudra modéliser les tables FOURNISSEUR (ou FABRICANT ou MANUFACTURIER, nom à votre convenance) et MODELE, comme dans le diagramme ci-dessus.
Et vous-même ?
(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.
Si vous avez pu saisir les données d’un 2e camion avec le même CamionNumber, je suppose que c’est parce que vous avez agi directement sur la table CAMION et non pas sur la vue CAMION_LOCALISATION_V, laquelle fait l’objet des contrôles. Qu’en est-il ?
Pour la présentation, c’est effectivement plus sympathique. En corollaire, je constate que deux décimales étant suffisantes, on peut donc remplacer le type FLOAT (non déterministe) par le type DECIMAL(9,2) (ou DECIMAL(7,2), etc.) pour les attributs LitersFuel et MileAgeKm de la table FUEL_CONSUMPTION.
La syntaxe me paraît bizarre. Pourquoi la 2e occurrence de « LitersPer100Km » ?
Pour ma part, je me sens plus à l’aise avec CAST. Le code de création de la vue FUEL_CONSUMPTION_V devient en l’occurrence :
CREATE VIEW FUEL_CONSUMPTION_V (CamionVIN, FuelDateReleve, LitersFuel, MileAgeKm, LitersPer100Km, AverageMPG) AS SELECT CamionVIN, FuelDateReleve, LitersFuel, MileAgeKm , CAST(LitersPer100Km AS DECIMAL(9,2)), CAST(AverageMPG AS DECIMAL(9,2)) FROM CAMION AS x JOIN FUEL_CONSUMPTION AS y ON x.CamionId = y.CamionId ;
Je modifie donc à nouveau la structure de la vue FUEL_CONSUMPTION_V :
A noter que la forme normale de Boyce Codd est encore violée pour FUEL_CONSUMPTION_V... Mais si une vue est perçue comme une table, il s’agit en fait d’une table virtuelle, donc pas de problème, d’autant plus que par son canal on ne modifie pas le CamionNumber.CREATE VIEW FUEL_CONSUMPTION_V (CamionVIN, CamionNumber, FuelDateReleve, LitersFuel, MileAgeKm, LitersPer100Km, AverageMPG) AS SELECT CamionVIN, CamionNumber, FuelDateReleve, LitersFuel, MileAgeKm , CAST(LitersPer100Km AS DECIMAL(9,2)), CAST(AverageMPG AS DECIMAL(9,2)) FROM CAMION AS x JOIN FUEL_CONSUMPTION AS y ON x.CamionId = y.CamionId ;
(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
Content que vous soyez de retour
Oui c'est parfait mais j'ai changé un "varchar" en "int'' dans la Table CAMION
Je veux juste que vous compreniez ceci.
En fait le nombre d'essieux dépend du propriétaire du camion. Il commande son camion du fabriquant avec le nombre d'essieux qu'il veut ou il en rejoute lui-même à un camion existant. Il y a des garages spécialisés pour ça. Donc un Camion disons "Kenworth" modèle "W900L" demeure un modèle "W900L" peu importe le nombre d'essieux qu'il a.
Cette base de donnée est rendu tellement complexe que je ne comprend plus rien
Le Fournisseur ou "Manufacturier" et le modèle du camion n'ont rien à voir avec le nombres d'essieux. C'est l'utilisateur qui détermine le nombre d'essieux qu'il veut sur son Camion.
L'utilisateur peut rajouter ou enlever des essieux. Je désire conserver Manufacturier. Fournisseur c'est le vendeur et les camions n'ont rien à voir avec le fournisseur. Ici, les fournisseurs, ils vendent des crayons et du papier aux secrétaires hahaha. Alors le Manufacturier est en sous-entendu mon fournisseur. Je ne veux pas employer Fournisseur ou Vendeur car mes camions ne porte pas le nom du fournisseur ou vendeur mais le nom du Manufacturier. Le fait que les Camions aient 2, 3, 4, 5 ou 6 essieux n'a rien à voir avec nul autre que l'utilisateur.
L'utilisateur achète un Camion = "Volvo", Modèle = "VN630", VIN = VL875YT5443WETR889 neuf qui a 3 essieux.
Le lendemain il lui rejoute un essieu. Donc maintenant son camion à 4 essieux….
Ça n'a rien changé au Niveau du Manufacturier, du Modèle et du VIN du Camion. Par contre lorsque j'interrogerai la base de données je verrai bien que ce Camion a 4 essieux
Non, il faut conserver le FLOAT car le MPG est une approximation calculée à l'aide d'une constante et si on utilise autre chose que le FLOAT, il y aura une marge d'erreur appréciable. J'ai fait les tests avant. Avec un Camion, il y a une grosse différence en 6,3 Miles au Gallon et 6,4 Miles au Gallon. À 6,3 Miles au Gallon, je paye le Carburant plus cher car je perd l'escompte. J'ai utilisé FLOAT car
1- Je ne voulais pas imposer à l'utilisateur d'entrer la distance parcourue en KM et en Miles et le carburant utilisé en Litres et en Gallons
2- Je ne voulais pas convertir les KM en Miles et les Litres en Gallons pour ajouter des colonnes non nécessaires. Regardez mon calcul pour les MPG, c'est le même calcul que pour les Litres au 100KM auquel j'ai rajouter une constante. Ça fonctionne très bien. Nous conservons le FLOAT...
Pour les VIEWS, vous faites ce que vous voulez, moi, elles ne me servent à rien. Pour pouvoir faire des Insert et Update, il me faut une clé primaire, donc pour faire des Insert ou Update dans la View CAMION_LOCALISATION_V, je dois créer une clé artificielle avec CamionVIN dans mon interface WEB. Les View ne correspondent pas au besoin de l'utilisateur. Dans l'interface WEB les View comporteront des JOIN entre les Tables. L'usagé n'interroge pas directement la base de données et la base de données ne sera pas directement accessible lorsqu'elle sera terminée, le seul qui pourra s'adresser à la base de données c'est PHP. Tous les comptes SQL Server seront désactivés et la seule façon d'accéder à SQL Server sera avec une authentification WINDOWS utilisé uniquement par PHP. Pour l'interface WEB, je donne les permissions que je veux à qui je veux, soit:
Admin
Select
Update
Insert
Delete
Donc l'utilisateur final aura 3 comptes utilisateur. Un compte "Admin" qui inclus Select, Update, Insert et la gestion des autres utilisateurs, un compte "Power User" qui inclus Select, Update, Insert et un compte "Public" qui inclus seulement Select lorsqu'il désirera seulement consulter la base de données. En mode Admin, il pourra donner les permission qu'il veut à qui il veut.
hahaha Vous n'avez pas terminer de voir des choses bizarres avec moi, en plus l'Halloween s'en vient je vais être encore plus bizarre
La 2e occurrence de "LitersPer100Km" est pour afficher "LitersPer100Km" comme nom de colonne LoL, le nom de colonne disparaît avec le ROUND(y.LitersPer100Km,2)
C'est la solution que j'ai trouvée hahaha
Vous l’aviez déjà précisé dans la 1re phrase du post #326, c’est pourquoi quand j’ai écrit :
Je demandais simplement confirmation de votre part. J’interprète désormais votre réponse comme un acquiescement, en conséquence de quoi je ne mettrai pas en oeuvre la table QUANTITE_TYPE. Pour le même motif, la table actuelle COMPOSANT_TYPE peut disparaître, puisqu’un camion peut aussi avoir plus d’une transmission, etc. Cette table avait pour objet de garantir le nombre maximum de composants par type de composant pour un camion, ce qui avait déjà été rendu caduque au vu de votre post #230 :
Pour qu’in soit bien en phase : êtes-vous d’accord pour la suppression de la table actuelle COMPOSANT_TYPE ?
(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.
Quelle est la façon la plus simple d'afficher Un Camion avec son Moteur, sa Transmission et ses Essieux. Pas l'historique, mais à un moment précis, comme aujourd'hui, je veux faire une requête qui retournera disons CamionVIN, CamionNumber, CamionManufacturier, CamionModele, MoteurNumeroSerie, MoteurFabriquant, MoteurModele, MaxHorsePower, MoteurMaxTorque, TransmissionNumeroSerie, TransmissionFabriquant, TransmissionModele, TransmissionVitesse, Differentiel 2ND NumeroSerie, Fabriquant, Ratio, Lock, Differentiel 3RD NumeroSerie, Fabriquant, Ratio, Lock. On fait une vue ??? Et pour faire un update à partie de cette vue ????
L'interface WEB ne sera pas comme vous la voyez présentement, Il y aura des sous vues aux vues dans les formulaires. Je conserve le format présent pour faire des tests sur la base de données et pour voir ce que je peux détruire sur SQL Server comme attaquer la Table Camion avec un Insert et avoir deux Camions portant le même CamionNumber... hahaha
Sur le site WEB, je ne peux pas faire d'UPDATE à un Camion en passant par le VIEW CAMION_LOCALISATION_VSi je veux faire un UPDATE je dois passer par la Table CAMION. Pas de clé primaire, pas d'UPDATE
À mon professeur préféré hahaha
Vous faites ce que vous voulez avec "DZINDZIO_TRUCKS_MANAGEMENT_TEST", elle est là pour que je puisse faire des tests avec vos nouveaux développements sans que je touche à vos table à vous. J'ai fait une sauvegarde de "DZINDZIO_TRUCKS_MANAGEMENT_TEST"
En fait ça m'arrangerait beaucoup si la table actuelle COMPOSANT_TYPE disparait. Elle me complique la vie hahaha
CamionNumber serait-il concerné ?
D’accord, on conserve le FLOAT.
Quelle en est la raison ?
Ceci est à mettre en rapport avec ce qui précède ? Sinon, je rappelle pour la forme que les vues sont là pour que l’utilisateur n’ait accès qu’aux données naturelles. Elles sont là pour qu’il manipule les données d’un composant comme un tout, par exemple les données d’un moteur : non seulement le MoteurNumeroSerie, le MaxHorsePower, etc. mais aussi sa date d’achat, son modèle et son fabricant. Ainsi, pour l’utilisateur, les tables virtuelles MOTEUR_COMPOSANT_V, TRANSMISSION_COMPOSANT_V, DIFFERENTIEL_COMPOSANT_V devraient suffire, alors que COMPOSANT, MOTEUR, TRANSMISSION et DIFFERENTIEL ne devraient pas le concerner, tant en consultation qu’en mise à jour.
Par ailleurs, si vous n’utilisez pas les vues pour les mises à jour, vous pouvez avoir des CamionNumber en double, mais par sécurité, je déplacerai le contrôle actuel des doublons vers un trigger affecté à la table CAMION, afin que, quelle que soit la stratégie utilisée, les doublons ne se produisent pas (idem pour les immatriculations).
La requête correspond manifestement à une vue globale, permettant de tout visualiser d’un camion et de ses composants. C’est donc une jointure des tables CAMION, COMPOSANT_AFFECTATION, COMPOSANT, MOTEUR, TRANSMISSION, DIFFERENTIEL (et AXLE à venir), c’est une extension généralisée de la requête proposée dans le post #189. Je ne vois pas trop l’intérêt d’une telle requête, mais bon. Si vous tenez à cette requête et si elle doit être utilisée à plusieurs reprises, on peut en faire une vue. Le résultat comportera plus d’une ligne (à cause par exemple des différentiels), aussi sa mise à jour sera bien plus compliquée, il faudra que le trigger associé comporte un curseur permettant de dépiauter les lignes du résultat une par une, c’est du lourd (vous me direz, chez les poids lourds c’est normal...) Je ne suis pas très chaud, c’est comme pour le pinard, mieux vaut déguster en plusieurs petits coups que tout d’un trait.
Si on la supprime, Il faudra quand même probablement rapatrier l’attribut ComposantTypeLibelle dans la table COMPOSANT (en réduisant les valeurs à "M" (comme moteur), "T" (comme transmission), "D" comme différentiel, sans oublier d’ajouter "A" (comme essieu). Pour le moment, COMPOSANT_TYPE n’a pas dit son dernier mot, malgré notre souhait de la voir quitter la scène...
(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.
Remodelage de CAMION_LOCALISATION_V dans "DZINDZIO_TRUCKS_MANAGEMENT_GIL_TEST"
USE [DZINDZIO_TRUCKS_MANAGEMENT_GIL_TEST] GO ALTER VIEW [dbo].[CAMION_LOCALISATION_V] AS SELECT x.CamionVIN AS VIN , x.CamionNumber AS Number , x.CamionImmat AS Immat , x.CamionDateMfg AS DateMfg , x.CamionManufacturer AS Manufacturer , x.CamionModel AS Model , x.CamionWheelBase AS WheelBase , x.CamionColor AS Color , x.GVWR, x.FRGAWR , x.[2NDGAWR], x.[3RDGAWR], x.[4THGAWR], x.REARGAWR , x.USDOT, x.ICCMC , x.CamionDateAchat AS DateAchat , x.CamionDateVente AS DateSold , y.LocalisationNote AS Note FROM dbo.CAMION AS x INNER JOIN dbo.LOCALISATION AS y ON x.CamionId = y.LocalisationId ;
[QUOTE=fsmrel;10532107]CamionNumber serait-il concerné ?
D’accord, on conserve le FLOAT.
Merci ;-)
C'est ça le problème justement, en essayant d'éviter les doublons, lorsque je fais un Update, je reposte tous les champs et SQL Server voit ça comme un nouveau Insert alors il répond que j'ai déjà un Camion avec ce CamionImmat et CamionNumber…
Juste un VIEW sans mise à jour. C'est la vue qui sera utilisée le plus souvent par l'utilisateur LoL
On pourrait vivre avec cette table mais ne pas mettre de Triggers pour les doublons ????? Elle serait inutile mais en la conservant, on ne change rien à la base de données ???
CamionNumber INT NOT NULL DEFAULT ('')
Et en plus il faut remplacer tout les DEFAULT ('') par des DEFAULT ((0)) car ça occasionne des problèmes avec PHP qui voit les ('') comme des valeurs NULL.
Et peut-être que nous devrions utiliser les bons Types de Données pour les colonnes car ça commence à occasionner des problèmes. J'ai des colonnes où il ne doit pas avoir de caractère mais uniquement des chiffres. Je mets toujours des VARCHAR par défaut lors de la création des tables pour la rapidité de création des tables et pour que tout passe sans problème et sans que je doive trop réfléchir à ce détail mais aussitôt que je suis fixé sur le type et la longueur, je remplace par le bon Type de Donnée. Et en plus, même les INT ne seront pratiquement pas nécessaires mais plutôt tinyint. On déterminera le meilleur choix. Je n'ai pas besoin d'un INT pour afficher un CamionNumber. les valeurs vont de 2300 à 2799 et de 23000 à 27999 sans opération mathématique en les CamionNumber. Un 2540 restera toujours un 2540. Il ne sera jamais un 2540 * 456,87 = ?
Ave Ordigil,
Quand vous codez :
Même principe quand vous codez CAMION_LOCALISATION_V :UPDATE CAMION SET CamionNumber = valeurn , CamionImmat = valeuri , ... WHERE ...
UPDATE CAMION_LOCALISATION_V SET Number = valeurn , Immat = valeuri , ... WHERE ...
Par définition, pour chaque colonne qui suit SET, le SGBD remplacera la valeur présente dans la table CAMION par celle que vous lui proposez, mais à la condition que les contraintes qu’on a définies soient respectées.
Pour le moment avec la vue CAMION_LOCALISATION_V, le trigger CAMION_LOCALISATION_UPDATE_TR s’assure que le CamionNumber n’existera pas en double (idem pour l’immat), mais je le modifierai, de telle sorte que l’update soit rejeté seulement si le camion mis à jour n’est pas le camion porteur du CamionNumber en cause.
Question : outre Number et Immat, dans l’UPDATE, l’attribut VIN fait-il partie du SET ?
Je dois m’absenter pour cause de répétition musicale, mais dès que je rentre, je m’occuperai de cela en priorité.
(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
Bonne répétition musical.
Je vais tout revérifier et j'essayerai de vous donner une réponse plus claire à votre retour
Voici un peu la façon dont tout cela fonctionne ici. En gros ce que vous voyez sur mon site WEB, toutes les pages sont déjà des "VIEWS" des tables de SQL Server. Elles sont identiques aux Tables mais ce sont des "VIEWS" Le client reçoit du Serveur HTTP un formulaire.php contenant du code PHP, HTTP, JSCRIPT", il transmet son formulaire.php à la cible.php sur le Serveur HTTP. Le Serveur HTTP transmet la cible.php à PHP qui transmet en langage SQL à SQL Server. SQL Server répond en langage SQL à PHP qui retourne au Serveur HTTP la cible.php. Le serveur HTTP retourne au client le formulaire.php…
Un peu comme ceci :
Pièce jointe 419306
Pour l'instant vous avez un accès direct authentifié sur SQL Server mais j'aurais pu vous ouvrir un compte WINDOWS et vous vous seriez authentifier auprès de WINDOWS et c'est un autre compte WINDOWS qui aurait fait le lien entre vous et SQL Server. C'est la façon plus sécuritaire de fonctionner. Pour simplifier les choses je vous ai donné un accès direct à SQL Serveur.
Mais lorsque vous utilisez le site WEB, vous ne vous authentifiez pas sur SQL Server, SQL Serveur ignore complètement qui vous êtes. Vous vous authentifiez auprès de PHP. J'ai mis votre nom d'utilisateur et votre mot de passe encrypté dans une table sur SQL Server mais j'aurais pu les mettre ailleurs ou j'aurais pu créer une autre base de données contenant 2 tables seulement pour les noms d'utilisateurs et les mots de passe. Donc en passant par le site WEB, vous n'accédez jamais à SQL Server, vous ne dépassez pas le Serveur HTTP. PHP fait le lien entre vous et SQL Server et il n'utilise pas votre nom d'utilisateur et votre mot de passe pour communiquer avec SQL Server, il utilise les siens…. Et encore là, $_POST n'est pas plus sécuritaire que $_GET. Un formulaire demeure un formulaire et un pas gentil pourrait faire une copie du formulaire.php et le modifier et envoyer le formulaire modifié à la cible.php. Et il faut aussi tenir compte du "cross-site scripting" qui permet à un utilisateur mal intentionné d'injecter du code HTML contenant du JavaScript dans les formulaires et les faire exécuter par les utilisateurs… Il faut mettre en place un mécanisme pour tout vérifier ce qui arrive des formulaires avant d'envoyer les requêtes à SQL Server. Et pour finir, vous n'avez qu'à ouvrir les outils de développement que Microsoft offre généreusement à tous et qui permettent de voir toute la structure et les formulaires sur un site WEB. Les produits Microsoft sont des passoires au grand plaisir des hackers…
Regardez le journal de SQL Server, mon serveur se fait attaquer 24 heures par jour sans arrêt. Les attaques proviennent de la Chine et de l'Inde… Pour l'instant ça tient mais...
Pièce jointe 419313
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.
Partager