IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

DB2 Discussion :

Erreur dans ma requête


Sujet :

DB2

  1. #1
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2021
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2021
    Messages : 4
    Points : 2
    Points
    2
    Par défaut Erreur dans ma requête
    Bonjour,
    J'aimerais si possible avoir de l'aide pour faire une requête sur IBM DB2 ; je travaille, en tant qu'étudiant sur un projet immobilier. j'ai 3 tables
    Nom : MPD 7 .PNG
Affichages : 81
Taille : 38,3 Ko

    Des erreurs apparaissent quand je lance ma requête ( je cherche à trouver la Liste des communes où le nombre de ventes a augmenté d'au moins 20% entre le premier et le second trimestre de 2020)
    Nom : Capture.PNG
Affichages : 77
Taille : 63,0 Ko.

    Les 2 sous requêtes donnent bien des resultats , je pense que les problemes vienennt de la fin dans la division si le nb de ventes du 1er trim est de 0 ; ou bien la nomination des colonnes ambigues...

    Où si vous suggérez une autre façon d’écrire cette requête je suis preneur

    Merci

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    8 758
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 8 758
    Points : 29 206
    Points
    29 206
    Par défaut
    Bonjour,

    Les requêtes et leur résultat sont totalement illisibles sur un petit écran.
    Merci de poster le code sous forme d'un bloc de code (utiliser le bouton code (#) juste au dessus de la zone de saisie des messages) dans le message.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 258
    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 : 7 258
    Points : 23 079
    Points
    23 079
    Billets dans le blog
    2
    Par défaut
    Et accessoirement, j'espère que cette base de données n'est pas encore en production

    • Les PK de type VARCHAR sont ce qu'on peut faire de pire (id_commune, id_bien_immo)
    • Une même typologie pouvant correspondre à plusieurs locaux, on devrait avoir une table de typologie des locaux en lien avec les locaux
    • Du VARCHAR(3) ça ne devrait jamais être utilisé : l'attribut de longueur va ajouter ici un octet soit une longueur de 4 maxi.
      On a donc une longueur supérieure à du char fixe et en même temps les inconvénients liés au varchar
    • Le code commune, s'il s'agit du code insee, vient d'un référentiel externe, il ne faut donc surtout pas le définir dans un type numérique, même si aujourd'hui les valeurs sont toutes numériques : tout référentiel externe peut changer de type et le jour où ça arrivera, vous aurez à modifier votre base ! (C'est arrivé il y a quelques années avec les codes départements lors de l'ajout des codes 2A et 2B pour la corse)


    S'il n'est pas trop tard, revoyez complètement la modélisation !

  4. #4
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2008
    Messages : 47
    Points : 66
    Points
    66
    Par défaut
    Bonjour,

    Même si je vois le code j'aimerai pouvoir le copier/coller et le formater pour le rendre plus lisible, et ne vais certainement pas me taper toute la saisie pour une proposition de correction.

    Ceci dit comme je le vois :
    La raison de l'erreur est que la colonne n'existe pas avec VENTE au singulier tel qu'écrit dans le where final.
    Mais il y a plusieurs autres erreur :
    • en SQL la division de deux entier c'est la division entière, sans décimale donc, pour avoir une décimale il faut forcer le type de l'une des deux opérandes soit par un CAST soit en la multipliant par un nombre de type non entier comme 1.0.
    • le select final est un produit cartésien, la requête compare les ventes du 1er trimestre d'une commune avec les vente du deuxième trimestre de chaque commune, il faut faire des jointures et éviter autant que possible la notation avec les virgules très peu lisible et plutôt passer par des jointures explicites
    • le select final fait référence à une colonne C.COMMUNE alors que C n'est pas définie dans le contexte


    Pour le formatage, même si ça n'est pas toujours concluant avec SQL d'appliquer une méthode systématique, il y a des outils en ligne (chercher SQL formatter) qui permettent de faire en sorte que la plupart du temps ça soit lisible.

    Et comme il y a utilisation de CTE, autant leur donner un nom parlant comme T1 et T2 et faire par (T2.ventes - T1.ventes) * 1.0 / T1.ventes

  5. #5
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2021
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2021
    Messages : 4
    Points : 2
    Points
    2
    Par défaut
    Bonjour vazymimil, escartefigue, etal1_24

    je vous remercie tous d'avoir pris le temps de m'aider et effectivement ça m'a bien aidé.
    Car avec la jointure .... j'ai pu obtenir un résultat Ouf enfin....
    - entre temps, j'avais corrigé pour le S de vente; mais ca n'avait pas suffi
    - "C" est défini dans la table3 et la table 4 , fallait -il aussi le definir dans le dernier select ?
    - je suis d'accord pour le type varchar en PK moi j'avais mis integer, mais mon mentor m'a fait changer en mettant varchar (!)

    Et je prends note de tous vos conseils : pour ce type de variable varchar, le code commune INSEE à ne jamais mettre en numérique ; la nomination des tables ; l'utilsiation de SQLformater
    J'ai commencé il y a 2 mois et je sais que la route sera longue avant de maîtriser tout cet univers .

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 258
    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 : 7 258
    Points : 23 079
    Points
    23 079
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Erique1 Voir le message
    je suis d'accord pour le type varchar en PK moi j'avais mis integer, mais mon mentor m'a fait changer en mettant varchar (!)
    Je suis curieux de connaître les arguments du "mentor" !

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2008
    Messages : 47
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par Erique1 Voir le message
    Bonjour vazymimil, escartefigue, etal1_24

    - "C" est défini dans la table3 et la table 4 , fallait -il aussi le définir dans le dernier select ?
    Des noms qui sont définis à l'intérieur d'un CTE, seuls persistent les nom de colonnes sélectionnées dans les requêtes qui utilisent les CTE, qualifiables par le nom de la CTE. Donc oui pour utiliser un nom d'ensemble de données C il faut d'abord le définir dans le contexte. D'ailleurs si C pointait vers les communes dans l'une des CTE et les clients dans une autre, comment le moteur SQL aurait pu alors deviner lequel était le bon.
    Après comme l'id de commune était déjà présent dans les deux, que chacune des CTE contient chaque id de commune ayant au moins un bien et qu'aucune colonne autre que l'id n'était sélectionné alors la table n'est pas nécessaire dans le select final.
    Et comme chacune des CTE ne contient au plus qu'une fois un ID de commune, le GROUP BY sur le select final est superflu, et n'est cohérent qu'avec le produit cartésien qui n'a pas a être là, et j'imagine que le GROUP BY n'est plus là dans la version corrigée. Si une personne (y compris l'auteur) devait maintenir la requête dans quelques années et voyait ce GROUP BY, elle chercherait à comprendre la subtilité et y perdrait du temps.

  8. #8
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2021
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2021
    Messages : 4
    Points : 2
    Points
    2
    Par défaut
    rebonjour,

    Effectivement , il y a , pour moi beaucoup de subtilités , et je cherche à comprendre la logique du SGBDR; "pourquoi il y a une ambiguïté ? ", "pourquoi ile veut pas de ça ?" il faut se mettre à sa place en fait.
    j 'avais testé plein de possibilités , ajouter par ci par là des choses (comme le GROUP BY) car je n'arrivais plus à rien en réfléchissant , donc oui, je l'ai enlevé.

    Si j'ai bien compris, pour mon mentor, (à qui j'ai fait remarquer qu'aucun autre étudiant de notre plateforme de travail ne mettait VARCHAR en PK) , il me dit que tout ce qui n'est pas calculable, quantifiable , comme des codes (communes, départements..) doit être en varchar . Je me dis que ca va dans le sens de ce que vous disiez , car là en fait pour id_bien_immo et id_commune, ces 2 PK sont des concaténations d'attributs constitués de chiffres et de rares fois de lettres.
    Alors que pour id_vente, c'est une integer auto-incrementé.
    et moi j'avais créé pareillement des Pk integer autoincrementées pour les 3 tables au debut. Mais il m'a fait changer, peut être pour me faire faire des concatenations ...

    Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?

  9. #9
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 258
    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 : 7 258
    Points : 23 079
    Points
    23 079
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Erique1 Voir le message
    Si j'ai bien compris, pour mon mentor, (à qui j'ai fait remarquer qu'aucun autre étudiant de notre plateforme de travail ne mettait VARCHAR en PK) , il me dit que tout ce qui n'est pas calculable, quantifiable , comme des codes (communes, départements..) doit être en varchar . Je me dis que ca va dans le sens de ce que vous disiez , car là en fait pour id_bien_immo et id_commune, ces 2 PK sont des concaténations d'attributs constitués de chiffres et de rares fois de lettres.
    Alors que pour id_vente, c'est une integer auto-incrementé.
    et moi j'avais créé pareillement des Pk integer autoincrementées pour les 3 tables au debut. Mais il m'a fait changer, peut être pour me faire faire des concatenations ...
    La première qualité d'une PK c'est d'être stable : sa valeur se propage en cascade dans d'autres tables au travers des FK, il ne faut donc pas qu'elle fasse l'objet de mises à jour. C'est pour cette raison qu'on choisit le plus souvent une colonne "identity" attribuée par le SGBD. Une telle colonne, dénuée de sens, n'a aucune raison d'être modifiée. A l'inverse, un code commune peut changer (ça se produit régulièrement : des communes fusionnent à peu près à chaque élection municipale). Donc, la bonne démarche est celle que vous aviez choisie : définir une PK asémantique de type "identity" et donc integer (small integer suffit en l'occurrence) et définir une autre colonne non PK mais avec une contrainte unique et de type CHAR(5) et non pas VARCHAR(5) aussi encombrant que du CHAR pour cette taille et moins performant !.
    De plus, un integer c'est 4 octets pour 4 294 967 295 valeurs possibles alors qu'un char ou varchar prendra 5 octets et beaucoup moins de valeurs possibles.
    Enfin, les CHAR et VARCHAR sont sensibles à la collation contrairement aux types numériques, c'est donc très risqué.
    Votre "mentor" serait bien avisé d'apprendre les avantages et les inconvénients du VARCHAR, s'il existe deux types CHAR et VARCHAR c'est qu'il y a une raison !
    Il serait également bien avisé d'apprendre quelles sont les qualités requises d'une PK, c'est essentiel. Une PK mal construite c'est des traitements inutilement couteux et une surcharge disque, réseau et CPU...


    Citation Envoyé par Erique1 Voir le message
    Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?
    En effet, c'est le rôle des alias de table et de colonne que de lever ces ambiguïtés.

  10. #10
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2008
    Messages : 47
    Points : 66
    Points
    66
    Par défaut
    Citation Envoyé par Erique1 Voir le message
    Effectivement , il y a , pour moi beaucoup de subtilités , et je cherche à comprendre la logique du SGBDR; "pourquoi il y a une ambiguïté ? ", "pourquoi ile veut pas de ça ?" il faut se mettre à sa place en fait.
    Oui il y en a pas mal, le coup de la division entière, les comparaisons avec null qui donne UNKNOWN, etc, et parfois des messages d'erreur n'arrangent rien. Il faut se mettre à sa place en effet, mais pour ça il faut la connaître, parfois on ne comprend le sens du message qu'en connaissant bien la syntaxe, par exemple en DB2LUW where exist(select * from a) au lieu de where exists(select * from a) est compris comme un appel d'une fonction exist avec comme paramètre la multiplication des colonnes select et from et une erreur de syntaxe, le a, un éditeur avec colorisation trouvera select et from, les colorisera comme des mots clés.

    Citation Envoyé par Erique1 Voir le message
    j 'avais testé plein de possibilités , ajouter par ci par là des choses (comme le GROUP BY) car je n'arrivais plus à rien en réfléchissant , donc oui, je l'ai enlevé.Est ce que je dis juste en disant qu'il ne faut pas d'ambiguités entre les colonnes des tables des sous requête et la requête finale ?
    On est effectivement vite tenté de mettre des group by ou des distinct quand on a pas le résultat qu'on veut, mais ne pas savoir pourquoi on le met est mauvais signe, j'ai vu aussi souvent des select distinct(a), b from c, la personne semble penser qu'elle n'aura qu'une fois a et sans doute le premier alors qu'il y a aucune différence avec select distinct a, b from c.
    Comme le dit escartefique, c'est par les alias qu'on lève ces ambiguïtés. Après selon le SGBD les erreurs peuvent être trompeuses, par exemple si DB2 for I se plein que COLONNE1 n'existe pas, c'est peut être que A n'existe pas dans A.COLONNE1, DB2LUW lui dit que c'est A.COLONNE1 qui n'existe pas ce qui au moins ne met pas sur une mauvaise voie.
    Au delà des ambiguïtés, bien nommer et bien structurer les choses en SQL comme ailleurs est important pour bien comprendre ce qu'on fait, avec SQL on peut faire des requêtes complexes, parfois d'autant plus complexes qu'on a du mal à définir précisément ce qu'on veut.
    Et qualifier les colonnes dans la requête même quand il n'y a pas ambiguïté permet à quelqu'un qui découvre une requête de savoir de quelles tables viennent les colonnes sans aller chercher à chaque fois dans un diagramme

    Les alias et le formatage permettent de faire d'une requête parfaitement valide pour DB2LUW
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    with from(from) as (values 'from'), select(select) as (values  'select') select select select from select select (select) union select from from from from (from)
    Une requête stupide mais lisible assez rapidement pour un humain, ou au moins on a pas de question à se poser si un mot est une table une colonne un alias ou un mot clé
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    WITH
      from(from) AS (VALUES 'from'),
      select(select) AS (VALUES 'select')
    SELECT
      select.select AS select
    FROM select AS select (select)
    UNION
    SELECT
      from.from AS from
    FROM from AS from (from)

  11. #11
    Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2021
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2021
    Messages : 4
    Points : 2
    Points
    2
    Par défaut
    Merci encore pour vos conseils, et l'aide à ma résolution de problème bien sûr . j'ai hâte de maitriser comme vous le sujet

    Là, on a un projet avec des données sur un problème de santé publique, (nutrition dans le monde), et on doit choisir R ou Python. Lequel conseilleriez vous pour un novice ? j'ai le les cours préconisés sur les 2 langages, masi ne sait pas si l'un serait plus adapté ( à moi, débutant et :ou au thème abordé) ou peu importe ?

  12. #12
    Membre du Club
    Profil pro
    Inscrit en
    octobre 2008
    Messages
    47
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : octobre 2008
    Messages : 47
    Points : 66
    Points
    66
    Par défaut
    Je ne maitrise que quelques bases Python et rien de R, donc perso pas même un début d'avis sur la question.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [MySQL] Erreur dans la requête d'insertion
    Par paradeofphp dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 08/11/2006, 16h06
  2. #Erreur dans une requête avec une fonction personnalisée
    Par pguiheu dans le forum Requêtes et SQL.
    Réponses: 9
    Dernier message: 04/07/2006, 15h45
  3. [MySQL] Erreur dans une requête
    Par sagitarium dans le forum PHP & Base de données
    Réponses: 12
    Dernier message: 13/05/2006, 21h38
  4. [MySQL] Erreur dans une requête sql
    Par Goundy dans le forum PHP & Base de données
    Réponses: 37
    Dernier message: 30/01/2006, 16h08
  5. [VBA] Erreur dans une requête
    Par Damsou dans le forum Access
    Réponses: 31
    Dernier message: 21/06/2005, 17h04

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