[fr-users] [base] questions d'éternel débutant
Bonjour, Je compte pendant cet été essayer pour la énième fois de transformer la feuille de calcul qui me sert de base de données en vraie base de données relationnelle. Pour éviter de me planter une fois de plus, je soumets aux surdoués de la liste quelques questions. Quand je passe de Calc à Base, c'est-à-dire quand je crée un odb à partir d'un ods, je n'arrive pas à mettre de clé primaire, ce qui est apparemment indispensable pour créer des relations. Est-ce possible ? Sinon, comment faire autrement qu'en créant "ex nihilo" et en retapant 200 enregistrements avec de très nombreux champs ? À (très) long terme, si j'arrive à créer quelque chose qui fonctionne, je voudrais le proposer à mes collègues. Actuellement, chacun utilise sa propre disposition de colonnes, ce qui ne facilite pas les échanges. Est-il envisageable d'échanger des enregistrements ? A priori, il faudrait transmettre les données de la table principale et reconstruire les liens avec les tables secondaires (dont le contenu change pour chaque collègue) ; Base est-il capable de s'y retrouver dans les index ? À chacun de mes essais, je me suis rendu compte en cours de travail (malgré une longue préparation sur papier) que j'avais besoin de modifier la structure de la base, ce qui n'était plus possible (ou plutôt, il aurait fallu utiliser des commandes SQL auxquelles je ne comprenais rien). Est-il vraiment impossible de corriger simplement des erreurs de conception ? J'utilise actuellement dans ma feuille de calcul des listes déroulantes (merci Pierre-Yves !) qui vont piocher leurs valeurs dans d'autres onglets. Est-il possible (facile ?) de créer plusieurs tables liées à partir des différents onglets ? J'arrive bien à créer des tables différentes mais elles sont dans des odb différents alors qu'il faudrait qu'elles soient dans le même. Je ne comprends pas les discussions sur tous ces moteurs internes, externes… Concrètement, si je crée une base (sans doute avec la version 3.6, je vais faire ça au mois d'août) et que le "moteur interne" change dans un an ou deux, est-ce que je risque de ne plus pouvoir travailler avec ma base ? Est-ce que les données enregistrées avec le moteur interne peuvent éventuellement être traitées avec un moteur externe ? Le wiki n'a apparemment rien sur Base. À part les anciens docs de OOo, auriez-vous des conseils pour des lectures répondant aux questions ci-dessus ? Merci d'avance, Henri -- Envoyez un mail à users+h...@fr.libreoffice.org pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
Re: [fr-users] [base] questions d'éternel débutant
Bonjour, Henri ;
Il est difficile de te répondre sans avoir les données elles-mêmes sous
les yeux. Je vais essayer toutefois d'apporter quelques réponses simples
aux questions les plus simples.
Le 06/07/2012 01:30, Henri Boyet a écrit :
>
> Quand je passe de Calc à Base, c'est-à-dire quand je crée un odb à
> partir d'un ods, je n'arrive pas à mettre de clé primaire, ce qui est
> apparemment indispensable pour créer des relations. Est-ce possible ?
> Sinon, comment faire autrement qu'en créant "ex nihilo" et en retapant
> 200 enregistrements avec de très nombreux champs ?
Oui, c'est possible. Je suppose que tu passes par un simple
copier/coller à partir de Calc dans Base, et je suppose de même que la
première ligne de ta plage de cellule contient les noms des champs.
Lorsque l'assistant d'importation te demande "Formatage de type", te
permettant de choisir le format des champs dans Base, il suffit de faire
un clic droit dans la fenêtre de gauche sur le champ qui doit devenir
clé primaire dans Base et de sélectionner l'entrée "clé primaire" (il
n'y a qu'une entrée, pas grand risque de se tromper...).
Si la clé primaire de la table est composée de deux champs (clé
concaténée) il faut sélectionner les deux champs (Ctrl + clic) avant de
faire le clic droit.
>
> À (très) long terme, si j'arrive à créer quelque chose qui fonctionne,
> je voudrais le proposer à mes collègues. Actuellement, chacun utilise
> sa propre disposition de colonnes, ce qui ne facilite pas les
> échanges. Est-il envisageable d'échanger des enregistrements ? A
> priori, il faudrait transmettre les données de la table principale et
> reconstruire les liens avec les tables secondaires (dont le contenu
> change pour chaque collègue) ; Base est-il capable de s'y retrouver
> dans les index ?
Pas de réponse possible sans examiner les différentes sources. A priori,
oui, mais en bricolant (et ça n'a rien à voir avec Base ou un autre
outil, c'est une question de structure et de logique : un ordinateur est
un tas de ferraille, il est rigoureusement incapable d'"interpréter" les
données qu'il voit). Il serait infiniment plus simple que les tables
secondaires aient la même structure, ça sera infiniment moins compliqué.
>
> À chacun de mes essais, je me suis rendu compte en cours de travail
> (malgré une longue préparation sur papier) que j'avais besoin de
> modifier la structure de la base, ce qui n'était plus possible (ou
> plutôt, il aurait fallu utiliser des commandes SQL auxquelles je ne
> comprenais rien). Est-il vraiment impossible de corriger simplement
> des erreurs de conception ?
Je ne vois pas quel est le problème. Si des liaisons ("relations", mais
je n'aime pas le terme qui induit une confusion) ont été définies et que
la modification remet en cause des l'intégrité des données, oui, c'est
normal que ce soit refusé. Il faut dans ce cas supprimer les liaisons
avant de faire toute modification de structure et les recréer ensuite.
En y réfléchissant, il me semble avoir eu un problème similaire,
précisément lorsque les liaisons sont définies. Base n'accepte plus de
modification de structure dans ce cas. La solution est celle que je
décris ci-dessus.
>
> J'utilise actuellement dans ma feuille de calcul des listes
> déroulantes (merci Pierre-Yves !) qui vont piocher leurs valeurs dans
> d'autres onglets. Est-il possible (facile ?) de créer plusieurs tables
> liées à partir des différents onglets ? J'arrive bien à créer des
> tables différentes mais elles sont dans des odb différents alors qu'il
> faudrait qu'elles soient dans le même.
Pour créer plusieurs tables par copier/coller à partir de Calc, il
suffit de répéter l'opération dans Base, dans la même base de données.
Sinon, je ne comprends pas ton problème. Peux-tu être plus explicite ?
>
> Je ne comprends pas les discussions sur tous ces moteurs internes,
> externes… Concrètement, si je crée une base (sans doute avec la
> version 3.6, je vais faire ça au mois d'août) et que le "moteur
> interne" change dans un an ou deux, est-ce que je risque de ne plus
> pouvoir travailler avec ma base ? Est-ce que les données enregistrées
> avec le moteur interne peuvent éventuellement être traitées avec un
> moteur externe ?
Il existe plusieurs possibilités. Il est toujours possible de faire
l'opération inverse à celle de la création des tables à partir de Calc
(copier/coller de Base vers Calc), on récupère les données ce qui est
quand même le plus important.
La seconde est que les développeurs prévoient un outil de transfert des
anciennes bases vers le nouveau moteur. Possible mais ça risque d'être
un peu long à développer, il n'est donc pas certain que ce soit une
priorité et je le comprends assez.
La troisième est que dès le départ tu raisonnes avec un moteur externe,
comme MySQL par exemple. Ce n'est pas très difficile à installer et à
paramétrer, tu trouveras, ici ou sur les forums spécialisés MySQL,
suffisamment d'aide pour le faire. Les avantages sont multiples : tu
t'affranchis tout
Re: [fr-users] [base] questions d'éternel débutant
Le 06/07/2012 06:27, Marc Romano a écrit :
Bonjour, Henri ;
Il est difficile de te répondre sans avoir les données elles-mêmes sous
les yeux. Je vais essayer toutefois d'apporter quelques réponses simples
aux questions les plus simples.
Bonjour Marc,
Merci pour ta longue réponse très détaillée. Je ne vais pas avoir le
temps pour l'instant de l'exploiter, je vais m'y plonger dans trois
semaines.
Le 06/07/2012 01:30, Henri Boyet a écrit :
Quand je passe de Calc à Base, c'est-à-dire quand je crée un odb à
partir d'un ods, je n'arrive pas à mettre de clé primaire, ce qui est
apparemment indispensable pour créer des relations. Est-ce possible ?
Sinon, comment faire autrement qu'en créant "ex nihilo" et en retapant
200 enregistrements avec de très nombreux champs ?
Oui, c'est possible. Je suppose que tu passes par un simple
copier/coller à partir de Calc dans Base, et je suppose de même que la
première ligne de ta plage de cellule contient les noms des champs.
Lorsque l'assistant d'importation te demande "Formatage de type", te
permettant de choisir le format des champs dans Base, il suffit de faire
un clic droit dans la fenêtre de gauche sur le champ qui doit devenir
clé primaire dans Base et de sélectionner l'entrée "clé primaire" (il
n'y a qu'une entrée, pas grand risque de se tromper...).
Si la clé primaire de la table est composée de deux champs (clé
concaténée) il faut sélectionner les deux champs (Ctrl + clic) avant de
faire le clic droit.
En fait, lors de mes essais, je ne faisais pas forcément de
copier/coller de Calc dans Base. Je ne me souviens plus pourquoi j'avais
abandonné cette méthode, il me semble que c'était une question de
formats des champs. J'avais essayé une autre démarche : créer une
nouvelle base, se connecter à une base existante, tableur. C'est sans
doute là que je n'avais pas de clé primaire. À creuser.
À (très) long terme, si j'arrive à créer quelque chose qui fonctionne,
je voudrais le proposer à mes collègues. Actuellement, chacun utilise
sa propre disposition de colonnes, ce qui ne facilite pas les
échanges. Est-il envisageable d'échanger des enregistrements ? A
priori, il faudrait transmettre les données de la table principale et
reconstruire les liens avec les tables secondaires (dont le contenu
change pour chaque collègue) ; Base est-il capable de s'y retrouver
dans les index ?
Pas de réponse possible sans examiner les différentes sources. A priori,
oui, mais en bricolant (et ça n'a rien à voir avec Base ou un autre
outil, c'est une question de structure et de logique : un ordinateur est
un tas de ferraille, il est rigoureusement incapable d'"interpréter" les
données qu'il voit). Il serait infiniment plus simple que les tables
secondaires aient la même structure, ça sera infiniment moins compliqué.
Je constate que je me suis mal exprimé. Je ne parlais pas d'échanges
entre des bases de types différents mais entre des bases de mêmes
structures. Supposons que la même commune a un emplacement différent
dans la table «T_Commune» de deux utilisateurs différents. Si j'importe
des enregistrements de la table «T_Eleves», le champ «Commune» ne
contient pas le nom de la commune mais un index vers la ligne de la
table «T_Communes». Que se passe-t-il puisque l'index ne pointe plus
vers la bonne valeur ? Je ne sais pas si je suis clair…
À chacun de mes essais, je me suis rendu compte en cours de travail
(malgré une longue préparation sur papier) que j'avais besoin de
modifier la structure de la base, ce qui n'était plus possible (ou
plutôt, il aurait fallu utiliser des commandes SQL auxquelles je ne
comprenais rien). Est-il vraiment impossible de corriger simplement
des erreurs de conception ?
Je ne vois pas quel est le problème. Si des liaisons ("relations", mais
je n'aime pas le terme qui induit une confusion) ont été définies et que
la modification remet en cause des l'intégrité des données, oui, c'est
normal que ce soit refusé. Il faut dans ce cas supprimer les liaisons
avant de faire toute modification de structure et les recréer ensuite.
En y réfléchissant, il me semble avoir eu un problème similaire,
précisément lorsque les liaisons sont définies. Base n'accepte plus de
modification de structure dans ce cas. La solution est celle que je
décris ci-dessus.
Ce n'était pas un problème de relations. Il me semble me rappeler que le
problème principal était de rajouter un champ. Mais je n'arrivais pas
non plus à corriger des formats de champs qui ne s'étaient pas importés
correctement, en particulier les booléens.
J'utilise actuellement dans ma feuille de calcul des listes
déroulantes (merci Pierre-Yves !) qui vont piocher leurs valeurs dans
d'autres onglets. Est-il possible (facile ?) de créer plusieurs tables
liées à partir des différents onglets ? J'arrive bien à créer des
tables différentes mais elles sont dans des odb différents alors qu'il
faudrait qu'elles soient dans le même.
Pour créer plusieurs tables par copier/coller à partir de Calc, il
suf
Re: [fr-users] [base] questions d'éternel débutant
Bonjour, Henri ; Le 07/07/2012 00:26, Henri Boyet a écrit : > > En fait, lors de mes essais, je ne faisais pas forcément de > copier/coller de Calc dans Base. Je ne me souviens plus pourquoi > j'avais abandonné cette méthode, il me semble que c'était une question > de formats des champs. J'avais essayé une autre démarche : créer une > nouvelle base, se connecter à une base existante, tableur. C'est sans > doute là que je n'avais pas de clé primaire. À creuser. Cet élément donne, me semble-t-il, l'explication à plusieurs de tes problèmes. Ceux-ci d'abord, mon interprétation ensuite : > (1) Je constate que je me suis mal exprimé. Je ne parlais pas > d'échanges entre des bases de types différents mais entre des bases de > mêmes structures. Supposons que la même commune a un emplacement > différent dans la table «T_Commune» de deux utilisateurs différents. > Si j'importe des enregistrements de la table «T_Eleves», le champ > «Commune» ne contient pas le nom de la commune mais un index vers la > ligne de la table «T_Communes». Que se passe-t-il puisque l'index ne > pointe plus vers la bonne valeur ? Je ne sais pas si je suis clair… > (2) Ce n'était pas un problème de relations. Il me semble me rappeler > que le problème principal était de rajouter un champ. Mais je > n'arrivais pas non plus à corriger des formats de champs qui ne > s'étaient pas importés correctement, en particulier les booléens. En fait, tu ne crées pas de "nouvelle" base de données avec la méthode que tu utilises. Tu crées un simple "conteneur" qui va conserver les paramètres de connexion à la "vraie" base de données et les objets spécifiques que tu pourras y rajouter (requêtes, formulaires, rapports). Mais les données elles-mêmes ainsi que la structure de la base restent conservées dans la source originelle, c'est-à-dire le classeur dans ton cas. Base fonctionne de la même façon pour la connexion vers n'importe quelle source externe, que ce soit un classeur, une base MySQL ou autre. C'est assez simple à vérifier : il suffit de regarder la taille du fichier odb entre une base "native" et une base externe. Elle varie considérablement, et c'esr encore plus net lorsque les données sont les mêmes, avec une base sous HSQL et les mêmes données sous MySQL par exemple. C'est aussi facile à vérifier autrement : fais une modification dans le classeur d'origine et réouvre la base : la modification sera apparente dans Base. Les données ne sont donc pas conservées dans Base, celle-ci se comporte comme une simple "fenêtre" vers les données d'origine. Ça peut paraître enquiquinant selon le problème que tu as à résoudre, mais en réalité c'est très bien comme ça. C'est même ça qui va permettre de partager une base de données entre plusieurs utilisateurs, et de permettre à chacun d'utiliser les données selon ses besoins propres : le "conteneur" odb pourra être personnel à chacun mais les données seront les mêmes pour tous. Pédagogiquement (je suis très égoïste...), ça ouvre de très intéressantes possibilités. Ça veut dire aussi que selon le type de la source, tu pourras ou ne pourras pas modifier la structure de la base. Ce sera possible par exemple sur une base MySQL (en fonction des droits utilisateurs sur la base et depuis peu, il me semble, parce que je me souviens que ce n'était pas possible sous OpenOffice), mais pas une une base de type "classeur", qui ne possède pas les caractéristiques (clé primaire, nature de champ, etc.) d'une table de base de données. AMHA, la connexion vers une feuille de calcul ne doit pas être retenue lorsqu'on veut construire une base de données relationnelle. Si dans les deux outils on parle de "table", la nature même de ces tables, leurs caractéristiques propres sont trop éloignées l'une de l'autre pour qu'une transition complète soit possible. La possibilité de transférer des tables de Calc vers Base est très intéressante, par exemple pour récupérer de gros volumes de données d'une autre source non directement compatible, ou si on veut "manipuler cette source différemment de ce que permet la version originelle. Dans un tel cas, exporter les données d'origine au format texte, les importer dans Calc puis dans Base, représente un gain de temps considérable par rapport à la saisie ex nihilo de ces mêmes données. La possibilité de se connecter directement sur une feuille de calcul est aussi intéressante, mais dans des cas particulier : je veux faire par exemple un publipostage à partie d'une liste d'adresses saisies dans un classeur. Je crée un "conteneur" Base lié à la feuille de calcul et j'utilise ce fichier odb comme source de données dans Writer. Pas de problème, c'est ultra-rapide et ça marche très bien. Mais à partir du moment où je veux pouvoir manipuler les adresses (quelles qu'en soient les raisons, la simple connexion vers la table ne suffit plus, il faut créer une "vraie" base relationnelle. > J'avais acheté un livre qu'on m'avait recommandé, "Pratique de MySQL > et PHP" mais ça dépassait mes capacités. E
Re: [fr-users] [base] questions d'éternel débutant
Bonjour Marc, Merci pour tes nouvelles explications (on sent le pédagogue ;-) ) ; j'ai maintenant compris ma principale erreur. Je créerai donc une nouvelle base et non un simple conteneur ! Dans un premier temps, je pense plus sage de me limiter à LibreOffice. Peut-être que plus tard, si j'arrive à maîtriser cet outil, je passerai au niveau supérieur avec MySQL… Bonne journée, Henri -- Envoyez un mail à users+h...@fr.libreoffice.org pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
