Discussion :

[tanaka59]

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

[escartefigue]

Bonjour,

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" ?

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)

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 ?

[tanaka59]

Bonjour,

Une nouvelle ligne est "injectée" dans la table "abonnement" ou bien "changement_abonnement" ?

Dans "abonnement"

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

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é.

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 ...

[escartefigue]

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.

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

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

"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

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

Jusque là oui

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 :

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.

[tanaka59]

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 ...