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. #1
    Membre chevronné

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 805
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 805
    Points : 1 948
    Points
    1 948
    Par défaut Créer un referentiel unique avec jointure VERSUS fusion des tables
    Bonsoir ,

    Voici une image qui vaudra mieux qu'un long discours :



    J'ai une table "abonnement" qui comme son nom l'indique stocke des abonnements en mode "archive" . Des qu'un abonnement est sujet à "modification" , je précise bien "modification" une nouvelle ligne est injectée dans la table.

    Lors de l'instruction "create table", la primary key est un id de ligne auto incremente. Num_abo lui est indexé et declaré aussi en "key" , noter ce champ Num_abo est aussi déclaré en "unique key" pour définir la combinaison d'une ligne qui est unique.

    Pour la table "changement_abonnementé c'est la même logique de construction cette fois pour de la création,migration,reactivation.

    Je dois faire transiter les données d'une grosse base vers un datawarehouse en mode "relationnel". Problème je n'ai aucun control pour m'assurer que le num_abo est bien présent dans chacune des 2 tables :

    2 solutions s'offrent à moi :

    cas 1 : créer un réferentiel unique ou je mets le num_abo + un date insertion, des qu'un nouvelle abonnement est détecté il est inséré . Si déjà existant , je ne fais rien .

    Cas 2 : j'empile les données de 2 tables pour m'affranchir de la contrainte relationnelle et n'en garder qu'une seule au final.

    J'ai quand même 2 choses à noter :

    - l'absence de contrainte en mode relationnel est très dangereuse ... risque du manque de contrôle pour m'assurer que tout est bien dans le referentiel
    - l'empilement des données okay ... mais cela a surtout l'air d'être un bricolage comment c'est pensé ...

    Merci d'éclairer ma lanterne

  2. #2
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 995
    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 : 4 995
    Points : 14 295
    Points
    14 295
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Citation Envoyé par tanaka59 Voir le message
    J'ai une table "abonnement" qui comme son nom l'indique stocke des abonnements en mode "archive" . Des qu'un abonnement est sujet à "modification" , je précise bien "modification" une nouvelle ligne est injectée dans la table.
    Une nouvelle ligne est "injectée" dans la table "abonnement" ou bien "changement_abonnement" ?

    Citation Envoyé par tanaka59 Voir le message
    Pour la table "changement_abonnementé c'est la même logique de construction cette fois pour de la création,migration,reactivation.
    Il semble qu'il manque des acteurs, par exemple, vous parlez d'abonnement mais jamais d'abonné. On peut supposer que les abonnés vous intéressent aussi. Qu'en est-il ?
    En quoi consistent les modifications d'abonnement ? Peut être s'agit il de souscription de nouvelles options ou de suppression d'autres options, auquel cas il manque également l'acteur "option" dans votre présentation
    Une fois le périmètre cerné, il faudra rédiger les règles de gestion sous la forme :

    R001 - abonnements et abonnés
    R001a : un abonné possède au moins un abonnement
    R001b : un abonnement est possédé par un et un seul abonné

    R002 - abonnements et options
    R002a : un abonnement peut être concerné par des options
    R002b : une option peut concerner plusieurs abonnements
    R002c : une option pour un abonnement est valide pour une période (du... au...)

    à partir de ces règles de gestion, on peut modéliser
    ABONNE 1,n --- posseder --- 1,1(R) ABONNEMENT 0,n --- concerner --- 0,n OPTION
    ..........................................................................................│
    ..........................................................................................└-- 0,n DATE

    Ce mini MCD donnerait les tables suivantes (PK soulignées, FK suffixées #)
    AB_ABONNE (AB_id, AB_nom, AB_prenom...)
    AO_ABONNEMENT(AB_id#, AO_id, AO_datedb, AO_datefn...) <-- abonnement identifié relativement à l'abonné, d'où la présence de AB_id dans la PK
    OP_OPTION(OP_id, OP_reference, OP_libelle...)
    CO_CONCERNER(AB_id#, AO_id#, OP_ID#, CO_datedb, CO_datefn)


    Citation Envoyé par tanaka59 Voir le message
    Je dois faire transiter les données d'une grosse base vers un datawarehouse en mode "relationnel". Problème je n'ai aucun control pour m'assurer que le num_abo est bien présent dans chacune des 2 tables
    De quelles 2 tables s'agit il ? Celles de la database d'origine ?

  3. #3
    Membre chevronné

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 805
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 805
    Points : 1 948
    Points
    1 948
    Par défaut
    Bonjour,


    Citation Envoyé par escartefigue Voir le message
    Une nouvelle ligne est "injectée" dans la table "abonnement" ou bien "changement_abonnement" ?
    Dans "abonnement"

    Citation Envoyé par escartefigue Voir le message
    Il semble qu'il manque des acteurs, par exemple, vous parlez d'abonnement mais jamais d'abonné. On peut supposer que les abonnés vous intéressent aussi. Qu'en est-il ?
    Effectivement il aussi une notion d'abonné , peut avoir un ou plusieurs abonnements

    Citation Envoyé par escartefigue Voir le message
    En quoi consistent les modifications d'abonnement ?
    Une date de resiliation, une date de creation de l'abonnement dans la base de données , une date d'activation de l'abonnement dans la base la base de données, une date d'activation lié au produit que le client a entre les mains, qui résilie (le client, l'entreprise, le contrat est actif ...), l'option courante lié à l'abonnement , la toute premiere option historique que l'abonné a eu lié au numéro d'abonnement concerné.

    Citation Envoyé par escartefigue Voir le message
    De quelles 2 tables s'agit il ? Celles de la database d'origine ?
    "abonnement" et "changement_abonnement" sont dans ma BDD d'origine

    "changement_abonnement" trace 4 type d'evenements :

    la date de vente/souscription de l'abonnement
    la date de migration (migration a l'initiative du client ou migration à l'initiative de l'entreprise par exemple une migration en lot)
    la date de reactivation (quand un abonnement est reactivé, suite à une suspension par exemple après un incident de paiement ou de facture )

    Ai je été clair ? ou bien faut il plus d'explication ?

    En somme les "abonnement" et "changement_abonnement" doivent me servir en bout de chaine d'un modele relationnel ... hors la je m’aperçois que j'ai 2 tables et la logique sql/informatique m'en impose 1 seule ...

  4. #4
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    4 995
    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 : 4 995
    Points : 14 295
    Points
    14 295
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par tanaka59 Voir le message
    Effectivement il aussi une notion d'abonné , peut avoir un ou plusieurs abonnements
    Il faut donc en tenir compte dans le modèle cible en créant une entité-type abonné comme suggéré dans ma première réponse.



    Citation Envoyé par tanaka59 Voir le message
    Citation Envoyé par escartefigue Voir le message
    En quoi consistent les modifications d'abonnement ?
    Une date de resiliation, une date de creation de l'abonnement dans la base de données , une date d'activation de l'abonnement dans la base la base de données, une date d'activation lié au produit que le client a entre les mains, qui résilie (le client, l'entreprise, le contrat est actif ...), l'option courante lié à l'abonnement , la toute premiere option historique que l'abonné a eu lié au numéro d'abonnement concerné.
    Dans le modèle cible, les dates liées à l'abonnement lui même seront des attributs de l'entité-type abonnement, alors que les dates liées à des événements facultatifs comme la résiliation seront externalisées. Cf. modèle proposé plus bas



    Citation Envoyé par tanaka59 Voir le message
    Citation Envoyé par escartefigue Voir le message
    Une nouvelle ligne est "injectée" dans la table "abonnement" ou bien "changement_abonnement" ?
    "abonnement" et "changement_abonnement" sont dans ma BDD d'origine
    au temps pour moi, j'avais cru qu'il s'agissait du modèle cible
    C'est moins grave puisqu'il s'agit de la source, mais le nom de cette table est inadapté : dans la table abonnement, l'identifiant PK devrait caractériser l'abonnement et non les événements que l'abonnement a subi



    Citation Envoyé par tanaka59 Voir le message
    "changement_abonnement" trace 4 type d'evenements :

    la date de vente/souscription de l'abonnement
    la date de migration (migration a l'initiative du client ou migration à l'initiative de l'entreprise par exemple une migration en lot)
    la date de reactivation (quand un abonnement est reactivé, suite à une suspension par exemple après un incident de paiement ou de facture )
    Là aussi le modèle source est inadapté. Soit la table concerne des modifications, auquel cas la date de souscription n'a rien à y faire : c'est une date unique et connue au moment de la création de l'abonnement. Soit la table concerne l'abonnement lui même et dans ce cas ce sont les autres dates (résiliation, migration), facultatives, qui n'ont rien à y faire.
    Mais bon, parlons plutôt du modèle cible



    Citation Envoyé par tanaka59 Voir le message
    Ai je été clair ? ou bien faut il plus d'explication ?
    Jusque là oui



    Citation Envoyé par tanaka59 Voir le message
    En somme les "abonnement" et "changement_abonnement" doivent me servir en bout de chaine d'un modele relationnel ... hors la je m’aperçois que j'ai 2 tables et la logique sql/informatique m'en impose 1 seule ...
    Par contre ici, je ne comprends pas pourquoi une seule table s'imposerait. C'est même tout le contraire.
    Reprenons le modèle conceptuel cible en tenant compte de vos explications, voici ce qu'on peut proposer

    ABONNE 1,n --- posseder --- 1,1(R) ABONNEMENT 0,n --- concerner --- 0,n EVENEMENT 1,1 --- typer --- 0,n TYPE_EVENEMENT
    La nouvelle entité-type "EVENEMENT", permet de connaître les migrations et résiliations. La cardinalité mini est zéro côté ABONNEMENT puisque migration et résiliation sont facultatives.
    Dans cette entité-type, on aura notamment pour attribut la date de l'événement
    La nouvelle entité-type "TYPE_EVENEMENT" permet de savoir s'il s'agit d'un événement de type résiliation, migration ou autre. On y trouvera, outre une pk technique, un code type et un libellé et éventuellement d'autres attributs (date de début de validité par exemple)



    Je n'ai pas compris la signification de la remarque suivante dans votre premier message :
    Citation Envoyé par tanaka59 Voir le message
    Problème je n'ai aucun control pour m'assurer que le num_abo est bien présent dans chacune des 2 tables
    Le plus important c'est que la PK soit bien présente et cohérente entre les deux tables, si j'ai bien compris, num_abo n'est pas la PK mais une clef fonctionnelle alternative.
    Si num_abo est absent dans l'une des deux tables, il suffira de le récupérer dans celle où il est présent grâce à la jointure sur la PK.

  5. #5
    Membre chevronné

    Profil pro
    Inscrit en
    janvier 2011
    Messages
    1 805
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations forums :
    Inscription : janvier 2011
    Messages : 1 805
    Points : 1 948
    Points
    1 948
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Je n'ai pas compris la signification de la remarque suivante dans votre premier message :

    Le plus important c'est que la PK soit bien présente et cohérente entre les deux tables, si j'ai bien compris, num_abo n'est pas la PK mais une clef fonctionnelle alternative.
    Si num_abo est absent dans l'une des deux tables, il suffira de le récupérer dans celle où il est présent grâce à la jointure sur la PK.
    C'est cela "num_abo" n'est pas une PK ... résultat dans la table j'avais vraiment du mal à faire ou concevoir des jointures ...

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

Discussions similaires

  1. requete avec jointure comparaison de 2 tables
    Par salluste dans le forum Requêtes
    Réponses: 14
    Dernier message: 10/03/2014, 11h24
  2. [MySQL] SELECT * avec jointure sur une même table
    Par Oprichnik dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 09/03/2011, 14h17
  3. Requete avec jointure sur la même table
    Par CaptainChoc dans le forum Langage SQL
    Réponses: 3
    Dernier message: 21/04/2009, 13h30
  4. requête avec jointure qui renvoie des résultats bizarres
    Par Canari74 dans le forum Requêtes et SQL.
    Réponses: 0
    Dernier message: 20/05/2008, 03h13
  5. [MySQL] requête avec jointure sur la même table
    Par gwena54 dans le forum PHP & Base de données
    Réponses: 7
    Dernier message: 08/05/2007, 12h22

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