A voir également:
- Fusion table base de donnée
- Table ascii - Guide
- Table des matières word - Guide
- Formules excel de base - Guide
- Fusion pdf - Guide
- Afficher les tables d'une base de données sql ✓ - Forum Programmation
3 réponses
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
30 mai 2017 à 21:36
30 mai 2017 à 21:36
peux-tu donner un exemple avec des données, qui nous montre comment déterminer le fournisseur de chaque produit?
Les tables sont fictives ainsi que leurs données. Du coup, c'est pas vraiment la problématique. Les vraies tables sont : TabBoard, TabPannello, TabTestComp .
Enfaite j'essaye de reproduire proprement ce qui a déjà été fait dans l'entreprise, pour "tester".
Les machines de l'entreprise ont une base de donnée a laquelle je n'ai pas accès (pour le moment). Mes prédécesseur ont créer une base de donnée test.mdb qui est sans doute liée a la base de donnée des machines. Entre autre, lorsque la machine effectue des test, elle écrit dans sa base de donnée originelle, qui ensuite modifie la base test.mdb. Donc j'imagine que les deux bases ont du être liées pour que les modifications s'effectuent.
Pourquoi faire deux base de données qui ont les mêmes champs, tables, ect ? Par sécurité. Si on modifie test.mdb, cela ne modifiera pas la base de donnée originelle. Du coup, tout les travaux de BDD se font sur test.mdb qui est un miroir de la VRAI BDD.
Ensuite, dans cette base de donnée, il y a 3 tables. Si j'utilise la fonction de schématisation de Access, je vois que dans la première on a 3 clée primaire : NomePann, BarCodeBoard, BoardID. Et aucune clée primaire dans les 2 autres (y a pas l'icône de clée a cotès du champs). Par contre "NomePann" est un champ dans les 3 tables.
Je suis un peu perdu. J'imagine que ca doit être une clée étrangère. Je dis ca car y a aucun icône de clée étrangère dans le schéma.
Aussi, un truc bizarre, j'ai des redondances dans le schéma : par exemple, j'ai 2 fois la même table dans le schéma => TabBoard, TabBoard1, TabBoard2. Auriez-vous une idée du pourquoi du comment ?
J'espère vous avoir éclaircit.
Merci d'avance.
Enfaite j'essaye de reproduire proprement ce qui a déjà été fait dans l'entreprise, pour "tester".
Les machines de l'entreprise ont une base de donnée a laquelle je n'ai pas accès (pour le moment). Mes prédécesseur ont créer une base de donnée test.mdb qui est sans doute liée a la base de donnée des machines. Entre autre, lorsque la machine effectue des test, elle écrit dans sa base de donnée originelle, qui ensuite modifie la base test.mdb. Donc j'imagine que les deux bases ont du être liées pour que les modifications s'effectuent.
Pourquoi faire deux base de données qui ont les mêmes champs, tables, ect ? Par sécurité. Si on modifie test.mdb, cela ne modifiera pas la base de donnée originelle. Du coup, tout les travaux de BDD se font sur test.mdb qui est un miroir de la VRAI BDD.
Ensuite, dans cette base de donnée, il y a 3 tables. Si j'utilise la fonction de schématisation de Access, je vois que dans la première on a 3 clée primaire : NomePann, BarCodeBoard, BoardID. Et aucune clée primaire dans les 2 autres (y a pas l'icône de clée a cotès du champs). Par contre "NomePann" est un champ dans les 3 tables.
Je suis un peu perdu. J'imagine que ca doit être une clée étrangère. Je dis ca car y a aucun icône de clée étrangère dans le schéma.
Aussi, un truc bizarre, j'ai des redondances dans le schéma : par exemple, j'ai 2 fois la même table dans le schéma => TabBoard, TabBoard1, TabBoard2. Auriez-vous une idée du pourquoi du comment ?
J'espère vous avoir éclaircit.
Merci d'avance.
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
31 mai 2017 à 09:25
31 mai 2017 à 09:25
si je comprends bien, tu ne souhaites plus extraire des données de deux tables, et tu souhaites comprendre la structure d'une base de test.
et tu sembles être novice dans ce domaine.
je te suggère de commencer par des exercices plus simples, pour que tu comprennes en réalisant toi-même.
et tu sembles être novice dans ce domaine.
je te suggère de commencer par des exercices plus simples, pour que tu comprennes en réalisant toi-même.
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
31 mai 2017 à 09:31
31 mai 2017 à 09:31
tu devrais plutôt, dans ta base Produit_deux:
- créer deux liens vers les tables qui t'intéressent dans la base Produits
- créer une requête exploitant les données des deux tables liées
tu utiliseras ensuite cette requête comme tu utiliserais une table
chaque fois que tu ouvres la requête, elle ira chercher les données dans l'autre base
- créer deux liens vers les tables qui t'intéressent dans la base Produits
- créer une requête exploitant les données des deux tables liées
tu utiliseras ensuite cette requête comme tu utiliserais une table
chaque fois que tu ouvres la requête, elle ira chercher les données dans l'autre base
Enfaite je suis actuellement en stage de licence dans une entreprise. Et j'ai déjà fais pas mal de SQL mais c'est la premiere fois en pratique. Le cahier des charges est inexistant et mon tuteur ne s'y connait pas plus que ca.
Okay je vois. Mais comment je peux utiliser une requête? une requête est un résultat pas une table ?
Okay je vois. Mais comment je peux utiliser une requête? une requête est un résultat pas une table ?
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
>
Ecxtazy
31 mai 2017 à 17:52
31 mai 2017 à 17:52
une requête a un nom, tu peux utiliser ce nom comme si c'était un nom de table.
yg_be
Messages postés
22720
Date d'inscription
lundi 9 juin 2008
Statut
Contributeur
Dernière intervention
23 avril 2024
1 476
>
Ecxtazy
1 juin 2017 à 08:49
1 juin 2017 à 08:49
en effet, tu peux utiliser une requête comme source d'un select.
pour faire simple, la requête est comme une table dont tu ne peux pas modifier le contenu.
pour faire simple, la requête est comme une table dont tu ne peux pas modifier le contenu.