Discussion :

[Melvine]

salut,

J'aurai une question,quand j'install oracle il me demande donner un nom à la base,donc j'ai donner bd1;
le service qui sera lancer pour utiliser sqlplus sera bd1;
quand je me connecterai à sqlplus je serai connecter à bd1;
dans bd1 je creer une base vente avec une table client;
et dans bd1 j'ai creer une autre base voyage avec une table client;
j'utilise un etl pour pouvoir recuperer les clients de la base vente et pouvoir les integrer dans la base voyage;
donc mon etl me demande un nom de base ainsi qu'un user et mot de passe pour ma cible et ma source;
au depart je mettai bd1 comme host name;
est ce que je dois creer les bases en leur donnant des noms differents avec create database voyage;....

ou je peux utiliser bd1 comme hostname pour mes deux bases ??

merci;

[orafrance]

dans bd1 je creer une base vente avec une table client;
et dans bd1 j'ai creer une autre base voyage avec une table client;

Attention, quand tu parles de base ici, ce sont des shémas et/ou utilisateurs, le vocabulaire est important

bd1 est le nom de l'instance (le SID) installée sur une machine (le host).

[Melvine]

ok donc c'est le hostname et je peux creer autant de base que je veux en faite sur ce host;
mais est ce possible d'exporter les données d'une base dans une autre base en utilisant un etl sachant que ces 2 bases sont dans le meme host

[jokos2000]

Bonjour,

A priori l'ETL te demande l'alias de tes bases contenu dans le tnsnames.ora.

Si ton ETL est sur un host A
Tes 2 bases vente et voyage sont sur un host B.

Il te faut :

Un client Oracle à l'endroit de ton ETL (ici sur host A).
Le client Oracle a besoin d'un fichier tnsnames.ora dans lequel tu spécifies les informations de connexion aux bases.

Si ton ETL est au même endroit que tes 2 bases, il faut que tu renseignes le fichier tnsnames.ora de leur host.

Donc dans ton tnsnames utilisé par ton ETL, tu renseigne 2 entrées qui sont tes 2 bases VENTE et VOYAGE.

Une fois le tnsnames bien renseigné, tu indiques à ton ETL l'alias correspondant à la base recherchée.

Donc ton ETL pourra travailler avec les 2 bases puisqu'il saura les différencier.

J'espère avoir été assez clair et avoir répondu à ta question.

jokos2000

[orafrance]

ok donc c'est le hostname et je peux creer autant de base que je veux en faite sur ce host;
mais est ce possible d'exporter les données d'une base dans une autre base en utilisant un etl sachant que ces 2 bases sont dans le meme host

Oui mais un shema différent plutôt qu'une base différente serait peut-être plus judicieux

[nuke_y]

Je pense que toute la question est là.

As-tu 2 instances Oracle différentes ou plutôt 1 seule instance Oracle (bd1) qui possède 2 schémas (voyage et vente) qui possèdent chacun 1 table client.

Dans le 1er cas, pas le choix :
tu dois configurer 2 entrées de base dans le tnsnames.ora : 1 pour client et 1 pour voyage.

Dans le 2e cas tu as 2 solutions :

1) considérer que chacun des schémas doit être considéré de manière indépendante et configurer 2 entrées de base dans le tnsnames.ora : 1 pour client et 1 pour voyage. En fait ces 2 entrées n'auront AUCUNE différence mais pour ton ETL elles seront différentes. L'avantage c'est que si un jour tu veux déplacer Voyage ou Vente sur un autre serveur, il suffira de modifier le TNSNAMES.ORA et c'est réglé.

2) considérer que tes 2 schémas sont bien présents sur la même base de données (bd1) et ne créer qu'une seule entrée dans le TNSNAMES.ORA qui sera l'entrée de bd1. Tu accéderas depuis ton ETL à chacun des schémas par Voyages@bd1 et Vente@bd1

Après selon l'ETL que tu utilises tu peux encore rajouter tes distinctions au niveau de l'objet Connection de l'ETL.

[Melvine]

sa ressemble à cela

2 instances Oracle différentes ou plutôt 1 seule instance Oracle (bd1) qui possède 2 schémas (voyage et vente) qui possèdent chacun 1 table client.

[Melvine]

salut,

Supposons que je dispose de se DWH:
dim_commande(numcde,date)
dim_client(numclient,nom,prenom,ville,pays)
dim_vendeur(numvendeur,codechef,nomchef)
dim_produit(numproduit,nom,description,categorie,descriptionCategorie,prix)
dim_date(numdate,date,mois,année)
Fact(numcde,numclient,numvendeur,numproduit,numdate,quantite,total)

j'aurai voulu savoir ,quand je vais creer mes tables en sql,
pour mes tables de dimension j'aurai une clé primaire donc je les creerai ainsi:
create table dim_commande(numcde number(12),date date,
constraint pf_dim_cde primary key (numcde));
...
et pour ma table de fait,comment je procederai ?
est ce que je dois rajouter un identifiant qui servira de clé primaire et declarer les clé etrangere comme cela
create table fact (id number(10),numcde number (12)..........
constraint pk_fact primary key (id),
constraint fk_fact foreign key(numcde) references dim_commande(numcde),
.................
);

ou dois je ne pas declaré de clé primaire et juste les clé etrangere
comme cela
create table fact (numcde number (12)..........
constraint fk_fact foreign key(numcde) references dim_commande(numcde),
.................
);

ou encore ,dois je faire une clé primaire composé des clés des tables de dimension ?

Si quelqu'un qui a eu à realiser des DWH pouvait m'eclaircir cela ;sa me permettrait de mieux comprendre la chose ?

Merci à tous

[nuke_y]

Alors déjà il te faut savoir si tu peux créer une clé primaire basée sur le métier.

Pour ça fait une analyse sur tes données et vérifie si tu peux trouver une clé primaire (même composée). Attention car si tu choisis une clé primaire basée sur des données métier (par exemple la date, le client et le numéro de facture) tu ne pourras jamais rentrer d'autres données avec la même clé.

En gros : si tu décides que ta facture a une PK (Primary Key) basée sur Date, Client et Numéro de facture ça donne ça :
Date Client Numéro Somme
01/01/2006 toto 000010 1000
01/02/2006 titi 000011 2000
01/03/2006 toto 000012 2000
01/03/2006 tata 000012 5000

Maintenant si ton modèle exige que pour un avoir il faille générer la même facture mais avec une somme en négatif ça donne ça :
Date Client Numéro Somme
01/01/2006 toto 000010 1000
01/02/2006 titi 000011 2000
01/03/2006 toto 000012 2000
01/03/2006 tata 000012 5000
01/03/2006 tata 000012 -5000

Et c'est impossible car il y aurait 2 lignes avec la même date, le même client et le même numéro. Donc soit le modèle n'est pas bon (il ne colle pas au métier) soit le métier fait qu'il est impossible qu'un avoir soit fait le même jour qu'une facture, soit tu es bloqué.

Pour régler ce problème soit tu fais une PK qui inclue aussi d'autre choses soit tu utilises un identifiant unique du système (number + séquence + trigger), ce qui ne t'empêche pas de rajouter une contrainte d'unicité sur ton association de champs métiers.

Dans tous les cas pour moi une table doit avoir une clé primaire, qu'elle soit basée sur des données métier ou sur des identifiants système.