Initiation laborieuse à Base

fr-users
#1

Bonjour à tous,

Comme je l'indiquais dans le sujet de ce post, je tente de réaliser ma première Base.

L'idée est de réaliser un formulaire principal de saisie afin d'insérer un enregistrement dans l'unique table "HORS TELEPHONIE" , pouvoir afficher l'ensemble des enregistrements de la table dans un sous formulaire sous jacent, rechercher un enregistrement afin de le modifier et actualiser.

Un grand merci pour votre aide

Ci-joint l'ébauche de la base

Christophe

#2

Bonjour,

Comme toi, j'affronte BASE et ce n'est pas une sinécure. J'ai trouvé un tutoriel qui explique pas-à-pas comment créer et réaliser une application de Base. Tu peux le trouver à l'adresse suivante :
http://www.cuk.ch/articles/4835
Tu y trouveras aussi : "Les clés pour démarrer avec Base de Openoffice.org/LibreOffice", en version .pdf et en version .odt.

Cela devrait t'aider à démarrer dans de bonnes conditions.
  Bon courage !

Tiens nous au courant de tes progrès (ou de tes interrogations !)

#3

Bonsoir,

Un excellent tutoriel de Pierre-Yves ici : http://user.services.openoffice.org/fr/forum/ftopic6460.html

Bernard

PS : le fichier n'est pas passé. Il faut le mettre à disposition via cijoint.fr par exemple.

#4

Bonjour ;

Un excellent tutoriel de Pierre-Yves ici : http://user.services.openoffice.org/fr/forum/ftopic6460.html

Bernard

PS : le fichier n'est pas passé. Il faut le mettre à disposition via cijoint.fr par exemple.

Mon intervention n'a pas de rapport direct avec la question initiale, mais sur un détail du fil ci-dessus. Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une critique de son travail, plus exactement pas dans le sens négatif de "critique" - certainement pas ! -, mais avec le souci d'apporter quelque chose de précis à la communauté.

Du point de vue de la modélisation d'une situation donnée, la table "FournisseursProduits" ne me paraît pas répondre d'une manière satisfaisante au problème posé (un fournisseur propose plusieurs produits, un produit est proposé par plusieurs fournisseurs). En effet, l'introduction d'un identifiant spécifique peut amener à avoir dans la table une duplication de l'information réellement utile (le couple référence produit/référence fournisseur). Rien n'interdit en effet qu'on ait sous les identifiants 45 et 87 par exemple, les données F4 et P2 (fournisseur 4 et produit 2). Du point de vue du moteur, il n'y a pas de doublon, mais du point de vue de la règle d'unicité des données, c'est une erreur : la même information (le fournisseur F4 propose le produit P2) est présente deux fois.

Hypothèse plausible : si on imagine que chaque fournisseur peut proposer un prix différent pour chaque produit, et que l'organisation souhaite conserver cette information, la modélisation proposée devient inadaptée : quel est le prix exact demandé par F4 pour P2, celui de la ligne 45 ou celui de la ligne 87 ? Il faudrait rajouter un champ "Date", faire une requête pour extraire le prix le plus récent... Un peu compliqué, surtout qu'il y a manière plus simple.

En fait, si on raisonne en modèle entité-association, il n'y a pas d'entité "FournisseurProduit". C'est une association non hiérarchique reliant les entités Fournisseur et Produit, qui pourrait être éventuellement porteuse de données, si on souhaitait conserver le prix d'achat proposé par chaque fournisseur pour un produit donné.

Traduit en modèle relationnel, cela donnerait :

FOURNISSEUR (_Réf. Fournisseur_, Nom, ...)
PRODUIT (_Réf. Produit_, Désignation, ...)
PROPOSER (_#Réf. Fournisseur, #Ref. Produit_, Prix achat (éventuellement))

La relation PROPOSER traduit une association non hiérarchique (cardinalités 0,n ou 1,n sur chaque branche) et a pour clé primaire la concaténation des identifiants des deux entités qu'elle relie.

Au niveau physique, elle remplace la table "FournisseurProduit". Chaque clé composée ainsi est unique, il ne peut pas y avoir deux fois le même couple fournisseur/produit, et on peut associer à chaque couple un prix donné, qui serait le dernier prix d'achat proposé par le fournisseur pour ce produit.

Il y a une autre table, toujours dans ce modèle, qui est construite sur le même principe, c'est "DétailCommande". Mais le problème n'est pas le même. On peut en effet penser (c'est un cas que j'ai rencontré souvent) que sur une même commande le même produit figure plusieurs fois, avec des quantités et des prix différents. Un exemple vécu, chez un grossiste en matériaux : un client négocie un prix spécial sur les briques pour un chantier donné, mais conserve son prix habituel pour ses autres chantiers. Sur une même commande, il peut très bien demander des livraisons sur plusieurs de ses chantiers. On aura donc la même référence produit, mais avec deux prix différents.C'est le cas également avec des produits sous nomenclature détaillée, la même référence pouvant apparaître sur plusieurs sous-ensembles.

Dans le cas de "DétailCommande", on fait référence à une autre entité, dont l'identifiant est un numéro de ligne de commande. Pour une commande donnée, chaque ligne est indépendante des autres et peut porter sur les mêmes produits. On peut très aisément concevoir que le modèle soit adapté à ce cas de figure.

Pour la relation PROPOSER, si l'organisation veut aller plus loin et garder une historisation des prix proposés par chaque fournisseur, c'est possible, mais cela modifie sensiblement le modèle. On sort du contexte de cet article.

Il me semble important de montrer que Base est capable de traiter le problème des clés concaténés, extrêmement courant dans les bases de données qu'on peut implanter. Le problème posé par Pierre-Yves s'y prête, il suffit juste de l'adapter.

Cordialement ;
Marc Romano

#5

Bonjour

Marc Romano wrote

Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une
critique de son travail, plus
exactement pas dans le sens négatif de "critique" - certainement pas !
-, mais avec le souci d'apporter quelque chose de précis à la communauté.

C'est bien ainsi que je le prends et je suis flatté de l'attention portée à
ce tutoriel... :slight_smile:

Marc Romano wrote

Du point de vue de la modélisation d'une situation donnée...

Justement, telle n'était pas ma perspective en rédigeant ce tutoriel.

Je m'étais posé la question de son "périmètre" et m'attendait à des
remarques (constructives) de ce type.

J'avais pris la précaution de le débuter par :

Extrait du préambule du tutoriel wrote

/Il va de soi qu'il ne s'agit que d'exemples restreints *sans aucune
réalité fonctionnelle*./

J'ai donc fait des choix, que j'assume, avec comme cible des débutants et
une utilisation bureautique du module.

Contrairement à ce que je pensais, tu es la première personne (depuis 4 ans
que ce tutoriel a été mis en ligne), à souligner ce qui pourrait (devrait)
être développé...

Cela, et le fait qu'on ne peut malheureusement pas être partout, a fait que
je n'ai jamais donné la suite que j'aurais voulu à ce "Débuter...".

Par parenthèse, si je devais y repasser du temps ce serait dans l'immédiat
pour le restructurer de manière à inclure tout de suite les apports de la
version 3.3 et ce sous la forme du FAQ dans le Wiki. Je ne pense pas, au
moment où j'écris, nécessaire de revenir sur la modélisation.

Marc Romano wrote

Il me semble important de montrer que Base est capable de...
...
Le problème posé par Pierre-Yves s'y prête, il suffit juste de
l'adapter...

Nous sommes d'accord... dans l'absolu. J'ai ainsi ajouté/complété une
vingtaine de FAQ sur ce module.

Son évolution reste incertaine me semble-t-il... et j'avoue être un peu
dans l'expectative.

Autre parenthèse : tous mes remerciements à Alex et au(x ?) développeur(s ?)
s'investissant dans la question.

Cordialement
Pierre-Yves

#6

Bonjour Marc et Pierre-Yves,

J'ai signalé ce tutoriel parce qu'il constituait une excellente approche des fonctions du module Base (création des tables, des formulaires, etc.). On a bien compris que son sujet n'était pas, à partir d'une "situation donnée" parvenir à un modèle relationnel parfait mais à aider le débutant à utiliser Base. Mais j'avoue n'avoir jamais pris le temps d'étudier le modèle sur lequel avait été réalisé la base proposée par Pierre-Yves.

Ceci dit, en voulant retrouver l'url de ce tuto, j'ai vu qu'il avait été modifié par Pierre-Yves pour intégrer la correction du 'bug' sur les requêtes multi-tables. C'est bien que ce tuto continue de vivre :slight_smile:

Bonne journée,
Bernard

#7

Bonjour,

Il ne faut peut-être pas vouloir réinventer l'eau chaude.
Ceux qui en sont à ce stade peuvent parfaitement profiter de cours en ligne :
http://access.developpez.com/cours/?page=langagevba#vbabases

Cordialement,
Sandy-Pascal Andriant

#8

Bonjour, Pierre-Yves ;

Bonjour

Marc Romano wrote

Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une
critique de son travail, plus
exactement pas dans le sens négatif de "critique" - certainement pas !
-, mais avec le souci d'apporter quelque chose de précis à la communauté.

C'est bien ainsi que je le prends et je suis flatté de l'attention portée à
ce tutoriel... :slight_smile:

Marc Romano wrote

Du point de vue de la modélisation d'une situation donnée...

Justement, telle n'était pas ma perspective en rédigeant ce tutoriel.

Je m'étais posé la question de son "périmètre" et m'attendait à des
remarques (constructives) de ce type.

J'avais pris la précaution de le débuter par :

Extrait du préambule du tutoriel wrote

/Il va de soi qu'il ne s'agit que d'exemples restreints *sans aucune
réalité fonctionnelle*./

J'ai donc fait des choix, que j'assume, avec comme cible des débutants et
une utilisation bureautique du module.

Contrairement à ce que je pensais, tu es la première personne (depuis 4 ans
que ce tutoriel a été mis en ligne), à souligner ce qui pourrait (devrait)
être développé...

Cela, et le fait qu'on ne peut malheureusement pas être partout, a fait que
je n'ai jamais donné la suite que j'aurais voulu à ce "Débuter...".

Par parenthèse, si je devais y repasser du temps ce serait dans l'immédiat
pour le restructurer de manière à inclure tout de suite les apports de la
version 3.3 et ce sous la forme du FAQ dans le Wiki. Je ne pense pas, au
moment où j'écris, nécessaire de revenir sur la modélisation.

Marc Romano wrote

Il me semble important de montrer que Base est capable de...
...
Le problème posé par Pierre-Yves s'y prête, il suffit juste de
l'adapter...

Nous sommes d'accord... dans l'absolu. J'ai ainsi ajouté/complété une
vingtaine de FAQ sur ce module.

Son évolution reste incertaine me semble-t-il... et j'avoue être un peu
dans l'expectative.

Autre parenthèse : tous mes remerciements à Alex et au(x ?) développeur(s ?)
s'investissant dans la question.

Cordialement
Pierre-Yves

Je ne remets pas en question ta démarche, que je comprends tout à fait, et ce d'autant plus que je ne fournis rien à la communauté de mon côté (pas faute d'en avoir envie, mais... à la retraite, peut-être, avec du temps...).

J'ai cependant une approche différente de la tienne, en ce sens que je trouve dangereuse une approche strictement "bureautique", qui est en fait celle que Microsoft cherche à imposer : on fait des trucs, mais on ne se préoccupe pas de la conformité de ce qu'on fait avec la réalité. Le résultat de cette démarche est, de mon point de vue, assez dramatique : les utilisateurs qui comprennent la philosophie d'un traitement de texte, pour ne prendre que cet exemple, sont rarissimes, les habitudes étant purement "bureautiques", au sens "presse-bouton", et pas du tout rationnelle, en "pensant" la structure de son document, en définissant ce qu'on veut faire avant de le faire.

En ce sens, l'excellent guide "Principes du traitement de texte", de Jean-Yves Royer, est une bénédiction pour les gens qui, comme moi, sont confrontés à des cohortes d'étudiants abreuvés de "frappez au kilomètre et faites la mise en forme après" depuis leurs premiers pas sur un ordinateur, et qui ne connaissent en fait de mise en forme que les quelques boutons disponibles sur une barre d'outils (sans même savoir la plupart du temps qu'il en existe d'autres).

Je pense qu'on devrait avoir la même démarche, quelle que soit la question traité : ne pas raisonner en termes d'utilisation "simplifiée", mais ancrer les exemples dans un minimum de réalité. La complexité qu'on peut rajouter est marginale, comme par exemple pour ton tutoriel, et les exemples qu'on peut donner peuvent ensuite servir de référence sans trop de risques de grosses erreurs. Il est certain que ceux qui apprennent à utiliser un produit, quel qu'il soit, se servent ensuite des exemples qu'on leur fournit pour leurs propres réalisations. Et c'est là que, AMHA, le bât peut blesser, quelles que soient les précautions liminaires qu'on peut prendre.

Ceci dit, je reconnais que c'est une question plus philosophique qu'autre chose. Quoiqu'une récente discussion ici même à propos d'un guide réalisé pour Writer par des enseignants dans le cadre d'une formation m'a montré que les préoccupations que nous pouvions avoir dans l'EdNat en terme de documentation ne sont pas tout à fait les mêmes que celles à laquelle obéit une diffusion plus universelle. C'est d'ailleurs la raison pour laquelle j'ai toujours hésité (et je comprends mieux maintenant pourquoi j'avais de manière intuitive ces hésitations) à proposer mes propres supports à la communauté : ils sont bien trop ciblés, pour un public précis et avec un objectif très calibré, ils ne peuvent en aucun cas entrer dans un cadre plus général (il faudrait les réécrire pour cela, et ils ne répondraient plus à leur objectif premier). Je citais ci-dessus un document sur Writer (excellentissime, je le répète), je le propose à mes étudiants mais je leur fournis aussi un autre document, inspiré par celui-ci, bien plus court et plus centré sur les travaux qu'ils ont à réaliser. Mais l'approche n'est est pas simplement "bureautique", en ce sens qu'elle répond aux principes de base d'une utilisation rationnelle du TdT.

C'est en ce sens que ma démarche se différencie de celle que tu as adoptée pour ce tutoriel : je simplifie parce que cela est nécessaire pour le public visé, mais je veille à rester néanmoins ancré dans la réalité et à respecter une démarche globale bien définie (je ne dis pas en revanche que j'y arrive tout le temps, mais j'essaye, j'essaye... :-[ ).

Je le répète, ce n'est pas une critique négative, mais une réflexion qui cherche à permettre d'améliorer la qualité des documents proposés. Je serais d'ailleurs assez tenté de te proposer de le retravailler et de le faire évoluer avec toi, mais il est fort peu probable que je puisse disposer, du moins d'ici cet été, du temps nécessaire pour cela. On peut en revanche, si tu en es d'accord, y réfléchir pour cet été.

Cordialement ;
Marc

#9

/Le 17/12/2011 10:27, andriant.sandy a écrit :confused:

/Bonjour,

Il ne faut peut-être pas vouloir réinventer l'eau chaude.
Ceux qui en sont à ce stade peuvent parfaitement profiter de cours en ligne :
http://access.developpez.com/cours/?page=langagevba#vbabases

Cordialement,
Sandy-Pascal Andriant /

Merci pour la pub, mais ici c'est une liste Libre Office (Open Office à la rigueur, éventuellement) et le fil de discussion concerne le module Base.

Si les utilisateurs, quel que soit leur niveaux, souhaitent se diriger vers un autre produit (en l'occurrence Access et le langage VBA comme la pleine page vers laquelle pointe votre lien) je pense qu'ils sont capables de le faire tout seul.
J'ai, personnellement, déjà testé certains cours qui se trouvent sur cette page, et les procédures qu'ils mentionnent ne s'adaptent pas in extenso à Base. L'effort d'adaptation nécessaire demande même des connaissances plus élevées que celles auxquelles tous les membres de cette liste peuvent avoir accès, par le biais de l'assistance, gracieusement fournie, par certains utilisateurs avancés qui y sont inscrits. Alors, de grâce, épargnez-nous votre "tiédeur aquatique" :wink:

_PS_ : Pardon aux modérateurs de la liste si j'ai usurpé leur rôle.

#10

Bonjour, Pierre-Yves ;

Bonjour

Marc Romano wrote

Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une
critique de son travail, plus
exactement pas dans le sens négatif de "critique" - certainement pas !
-, mais avec le souci d'apporter quelque chose de précis à la communauté.

C'est bien ainsi que je le prends et je suis flatté de l'attention portée à
ce tutoriel... :slight_smile:

Marc Romano wrote

Du point de vue de la modélisation d'une situation donnée...

Justement, telle n'était pas ma perspective en rédigeant ce tutoriel.

Je m'étais posé la question de son "périmètre" et m'attendait à des
remarques (constructives) de ce type.

J'avais pris la précaution de le débuter par :

Extrait du préambule du tutoriel wrote

/Il va de soi qu'il ne s'agit que d'exemples restreints *sans aucune
réalité fonctionnelle*./

J'ai donc fait des choix, que j'assume, avec comme cible des débutants et
une utilisation bureautique du module.

Contrairement à ce que je pensais, tu es la première personne (depuis 4 ans
que ce tutoriel a été mis en ligne), à souligner ce qui pourrait (devrait)
être développé...

Cela, et le fait qu'on ne peut malheureusement pas être partout, a fait que
je n'ai jamais donné la suite que j'aurais voulu à ce "Débuter...".

Par parenthèse, si je devais y repasser du temps ce serait dans l'immédiat
pour le restructurer de manière à inclure tout de suite les apports de la
version 3.3 et ce sous la forme du FAQ dans le Wiki. Je ne pense pas, au
moment où j'écris, nécessaire de revenir sur la modélisation.

Marc Romano wrote

Il me semble important de montrer que Base est capable de...
...
Le problème posé par Pierre-Yves s'y prête, il suffit juste de
l'adapter...

Nous sommes d'accord... dans l'absolu. J'ai ainsi ajouté/complété une
vingtaine de FAQ sur ce module.

Son évolution reste incertaine me semble-t-il... et j'avoue être un peu
dans l'expectative.

Autre parenthèse : tous mes remerciements à Alex et au(x ?) développeur(s ?)
s'investissant dans la question.

Cordialement
Pierre-Yves

Je ne remets pas en question ta démarche, que je comprends tout à fait, et ce d'autant plus que je ne fournis rien à la communauté de mon côté (pas faute d'en avoir envie, mais... à la retraite, peut-être, avec du temps...).

J'ai cependant une approche différente de la tienne, en ce sens que je trouve dangereuse une approche strictement "bureautique", qui est en fait celle que Microsoft cherche à imposer : on fait des trucs, mais on ne se préoccupe pas de la conformité de ce qu'on fait avec la réalité. Le résultat de cette démarche est, de mon point de vue, assez dramatique : les utilisateurs qui comprennent la philosophie d'un traitement de texte, pour ne prendre que cet exemple, sont rarissimes, les habitudes étant purement "bureautiques", au sens "presse-bouton", et pas du tout rationnelle, en "pensant" la structure de son document, en définissant ce qu'on veut faire avant de le faire.

En ce sens, l'excellent guide "Principes du traitement de texte", de Jean-Yves Royer, est une bénédiction pour les gens qui, comme moi, sont confrontés à des cohortes d'étudiants abreuvés de "frappez au kilomètre et faites la mise en forme après" depuis leurs premiers pas sur un ordinateur, et qui ne connaissent en fait de mise en forme que les quelques boutons disponibles sur une barre d'outils (sans même savoir la plupart du temps qu'il en existe d'autres).

Je pense qu'on devrait avoir la même démarche, quelle que soit la question traité : ne pas raisonner en termes d'utilisation "simplifiée", mais ancrer les exemples dans un minimum de réalité. La complexité qu'on peut rajouter est marginale, comme par exemple pour ton tutoriel, et les exemples qu'on peut donner peuvent ensuite servir de référence sans trop de risques de grosses erreurs. Il est certain que ceux qui apprennent à utiliser un produit, quel qu'il soit, se servent ensuite des exemples qu'on leur fournit pour leurs propres réalisations. Et c'est là que, AMHA, le bât peut blesser, quelles que soient les précautions liminaires qu'on peut prendre.

Ceci dit, je reconnais que c'est une question plus philosophique qu'autre chose. Quoiqu'une récente discussion ici même à propos d'un guide réalisé pour Writer par des enseignants dans le cadre d'une formation m'a montré que les préoccupations que nous pouvions avoir dans l'EdNat en terme de documentation ne sont pas tout à fait les mêmes que celles à laquelle obéit une diffusion plus universelle. C'est d'ailleurs la raison pour laquelle j'ai toujours hésité (et je comprends mieux maintenant pourquoi j'avais de manière intuitive ces hésitations) à proposer mes propres supports à la communauté : ils sont bien trop ciblés, pour un public précis et avec un objectif très calibré, ils ne peuvent en aucun cas entrer dans un cadre plus général (il faudrait les réécrire pour cela, et ils ne répondraient plus à leur objectif premier). Je citais ci-dessus un document sur Writer (excellentissime, je le répète), je le propose à mes étudiants mais je leur fournis aussi un autre document, inspiré par celui-ci, bien plus court et plus centré sur les travaux qu'ils ont à réaliser. Mais l'approche n'est est pas simplement "bureautique", en ce sens qu'elle répond aux principes de base d'une utilisation rationnelle du TdT.

C'est en ce sens que ma démarche se différencie de celle que tu as adoptée pour ce tutoriel : je simplifie parce que cela est nécessaire pour le public visé, mais je veille à rester néanmoins ancré dans la réalité et à respecter une démarche globale bien définie (je ne dis pas en revanche que j'y arrive tout le temps, mais j'essaye, j'essaye... :-[ ).

Je le répète, ce n'est pas une critique négative, mais une réflexion qui cherche à permettre d'améliorer la qualité des documents proposés. Je serais d'ailleurs assez tenté de te proposer de le retravailler et de le faire évoluer avec toi, mais il est fort peu probable que je puisse disposer, du moins d'ici cet été, du temps nécessaire pour cela. On peut en revanche, si tu en es d'accord, y réfléchir pour cet été.

Cordialement ;
Marc

je trouve dangereuse une approche strictement "bureautique"

Je ne suis pas tout à fait d'accord avec toi car je pense que LO est avant tout un outil bureautique fait pour des "bureauticiens" :slight_smile: et on ne peut pas demander à ces gens d'être des experts en 3FN :-).
Si, dans une organisation, on veut un Système d'information fiable, sécurisé, normalisé on utilise des SGBD centralisés et on fait appel à des DBA pour concevoir et implémenter les bases.
De ce point de vue je trouve intéressant de trouver cette dualité dans LO :
- d'une part la possibilité d'utiliser un SGBD simple et embarqué pour les "bureauticiens" qui peuvent développer de petites bases pour leur boulot quotidien,
- d'autre part la possibilité d'accéder à des serveurs de bases de données (MySQL et bien d'autres via le connecteur ODBC) et donc, comme je disais, à un SI sécurisé et normalisé.

Je le répète, ce n'est pas une critique négative

Je ne sais pas comment le considère Pierre-Yves mais pour moi c'est positif car ça permet de procéder à des échanges de points de vue.

Bernard

#11

A en croire la page où tu nous envoies, cela veut-il dire qu'en matière bureautique il faut s'en tenir à Access, et autres produits MS ? Je n'ose croire que dans ce domaine aussi existe une "pensée unique" et que ce lien est en fait une erreur involontaire :slight_smile:

Bernard

#12

Bonjour, Pierre-Yves ;

Bonjour

Marc Romano wrote

Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une
critique de son travail, plus
exactement pas dans le sens négatif de "critique" - certainement pas !
-, mais avec le souci d'apporter quelque chose de précis à la communauté.

C'est bien ainsi que je le prends et je suis flatté de l'attention portée à
ce tutoriel... :slight_smile:

Marc Romano wrote

Du point de vue de la modélisation d'une situation donnée...

Justement, telle n'était pas ma perspective en rédigeant ce tutoriel.

Je m'étais posé la question de son "périmètre" et m'attendait à des
remarques (constructives) de ce type.

J'avais pris la précaution de le débuter par :

Extrait du préambule du tutoriel wrote

/Il va de soi qu'il ne s'agit que d'exemples restreints *sans aucune
réalité fonctionnelle*./

J'ai donc fait des choix, que j'assume, avec comme cible des débutants et
une utilisation bureautique du module.

Contrairement à ce que je pensais, tu es la première personne (depuis 4 ans
que ce tutoriel a été mis en ligne), à souligner ce qui pourrait (devrait)
être développé...

Cela, et le fait qu'on ne peut malheureusement pas être partout, a fait que
je n'ai jamais donné la suite que j'aurais voulu à ce "Débuter...".

Par parenthèse, si je devais y repasser du temps ce serait dans l'immédiat
pour le restructurer de manière à inclure tout de suite les apports de la
version 3.3 et ce sous la forme du FAQ dans le Wiki. Je ne pense pas, au
moment où j'écris, nécessaire de revenir sur la modélisation.

Marc Romano wrote

Il me semble important de montrer que Base est capable de...
...
Le problème posé par Pierre-Yves s'y prête, il suffit juste de
l'adapter...

Nous sommes d'accord... dans l'absolu. J'ai ainsi ajouté/complété une
vingtaine de FAQ sur ce module.

Son évolution reste incertaine me semble-t-il... et j'avoue être un peu
dans l'expectative.

Autre parenthèse : tous mes remerciements à Alex et au(x ?) développeur(s ?)
s'investissant dans la question.

Cordialement
Pierre-Yves

Je ne remets pas en question ta démarche, que je comprends tout à fait, et ce d'autant plus que je ne fournis rien à la communauté de mon côté (pas faute d'en avoir envie, mais... à la retraite, peut-être, avec du temps...).

J'ai cependant une approche différente de la tienne, en ce sens que je trouve dangereuse une approche strictement "bureautique", qui est en fait celle que Microsoft cherche à imposer : on fait des trucs, mais on ne se préoccupe pas de la conformité de ce qu'on fait avec la réalité. Le résultat de cette démarche est, de mon point de vue, assez dramatique : les utilisateurs qui comprennent la philosophie d'un traitement de texte, pour ne prendre que cet exemple, sont rarissimes, les habitudes étant purement "bureautiques", au sens "presse-bouton", et pas du tout rationnelle, en "pensant" la structure de son document, en définissant ce qu'on veut faire avant de le faire.

En ce sens, l'excellent guide "Principes du traitement de texte", de Jean-Yves Royer, est une bénédiction pour les gens qui, comme moi, sont confrontés à des cohortes d'étudiants abreuvés de "frappez au kilomètre et faites la mise en forme après" depuis leurs premiers pas sur un ordinateur, et qui ne connaissent en fait de mise en forme que les quelques boutons disponibles sur une barre d'outils (sans même savoir la plupart du temps qu'il en existe d'autres).

Je pense qu'on devrait avoir la même démarche, quelle que soit la question traité : ne pas raisonner en termes d'utilisation "simplifiée", mais ancrer les exemples dans un minimum de réalité. La complexité qu'on peut rajouter est marginale, comme par exemple pour ton tutoriel, et les exemples qu'on peut donner peuvent ensuite servir de référence sans trop de risques de grosses erreurs. Il est certain que ceux qui apprennent à utiliser un produit, quel qu'il soit, se servent ensuite des exemples qu'on leur fournit pour leurs propres réalisations. Et c'est là que, AMHA, le bât peut blesser, quelles que soient les précautions liminaires qu'on peut prendre.

Ceci dit, je reconnais que c'est une question plus philosophique qu'autre chose. Quoiqu'une récente discussion ici même à propos d'un guide réalisé pour Writer par des enseignants dans le cadre d'une formation m'a montré que les préoccupations que nous pouvions avoir dans l'EdNat en terme de documentation ne sont pas tout à fait les mêmes que celles à laquelle obéit une diffusion plus universelle. C'est d'ailleurs la raison pour laquelle j'ai toujours hésité (et je comprends mieux maintenant pourquoi j'avais de manière intuitive ces hésitations) à proposer mes propres supports à la communauté : ils sont bien trop ciblés, pour un public précis et avec un objectif très calibré, ils ne peuvent en aucun cas entrer dans un cadre plus général (il faudrait les réécrire pour cela, et ils ne répondraient plus à leur objectif premier). Je citais ci-dessus un document sur Writer (excellentissime, je le répète), je le propose à mes étudiants mais je leur fournis aussi un autre document, inspiré par celui-ci, bien plus court et plus centré sur les travaux qu'ils ont à réaliser. Mais l'approche n'est est pas simplement "bureautique", en ce sens qu'elle répond aux principes de base d'une utilisation rationnelle du TdT.

C'est en ce sens que ma démarche se différencie de celle que tu as adoptée pour ce tutoriel : je simplifie parce que cela est nécessaire pour le public visé, mais je veille à rester néanmoins ancré dans la réalité et à respecter une démarche globale bien définie (je ne dis pas en revanche que j'y arrive tout le temps, mais j'essaye, j'essaye... :-[ ).

Je le répète, ce n'est pas une critique négative, mais une réflexion qui cherche à permettre d'améliorer la qualité des documents proposés. Je serais d'ailleurs assez tenté de te proposer de le retravailler et de le faire évoluer avec toi, mais il est fort peu probable que je puisse disposer, du moins d'ici cet été, du temps nécessaire pour cela. On peut en revanche, si tu en es d'accord, y réfléchir pour cet été.

Cordialement ;
Marc

je trouve dangereuse une approche strictement "bureautique"

Je ne suis pas tout à fait d'accord avec toi car je pense que LO est avant tout un outil bureautique fait pour des "bureauticiens" :slight_smile: et on ne peut pas demander à ces gens d'être des experts en 3FN :-).
Si, dans une organisation, on veut un Système d'information fiable, sécurisé, normalisé on utilise des SGBD centralisés et on fait appel à des DBA pour concevoir et implémenter les bases.
De ce point de vue je trouve intéressant de trouver cette dualité dans LO :
- d'une part la possibilité d'utiliser un SGBD simple et embarqué pour les "bureauticiens" qui peuvent développer de petites bases pour leur boulot quotidien,
- d'autre part la possibilité d'accéder à des serveurs de bases de données (MySQL et bien d'autres via le connecteur ODBC) et donc, comme je disais, à un SI sécurisé et normalisé.

Je le répète, ce n'est pas une critique négative

Je ne sais pas comment le considère Pierre-Yves mais pour moi c'est positif car ça permet de procéder à des échanges de points de vue.

Bernard

Si, dans une organisation, on veut un Système d'information fiable, sécurisé, normalisé on utilise des SGBD centralisés et on fait appel à des DBA pour concevoir et implémenter les bases.

C'est un point sur lequel tu prêches un convaincu de longue date... qui fait exactement le contraire à longueur d'année. Pour une raison simple : les programmes et référentiels de certains diplômes qui n'ont à voir avec l'informatique que la notion d'outil de travail et en aucun cas celle d'outil de développement d'applications - je pense au BTS comptabilité et gestion des organisations par exemple et dans une moindre mesure au bac STG - font explicitement référence à ces notions, que ce soit les trois premières formes normales ou la modélisation du SI.

Je suis entièrement d'accord avec toi sur le fait qu'une organisation qui a besoin d'implémenter un SGBDR ne fera certainement pas appel à un comptable pour cela, mais il n'en reste pas moins que si je veux préparer efficacement mes étudiants de BTS CGO à l'examen, je leur parle de MERISE (et MERISE-II-le-retour), de relations en 1, 2 et 3FN (et même un peu plus loin, il le faudrait mais j'évite : ils sont déjà assez paumés avec ça).

Autrement dit, je ne parcours pas ces chemins par plaisir ou purisme mal placé, mais parce que je suis obligé de les suivre. Est-ce que tu accepterais qu'un des enseignants de tes enfants décide de ne pas suivre le programme parce qu'il le trouve inadapté ?

Dans ce contexte, je ne leur donnerai certainement pas le lien vers le tutoriel de Pierre-Yves, parce qu'il s'appuie sur un exemple qui est exactement quelque chose qu'il ne faut PAS faire dans le cadre de ce que je suis censé leur enseigner. Je fais quoi ? Eh bien, j'en écris un spécifique adapté à CE public. Je ne peux pas faire autrement : comment puis-je les orienter vers des exemples qui sont exactement à l'envers de ce qu'on leur demande à l'examen, sauf à passer du temps à retricoter ensuite les bonnes notions ?

De ce point de vue je trouve intéressant de trouver cette dualité dans LO :
- d'une part la possibilité d'utiliser un SGBD simple et embarqué pour les "bureauticiens" qui peuvent développer de petites bases pour leur boulot quotidien,
- d'autre part la possibilité d'accéder à des serveurs de bases de données (MySQL et bien d'autres via le connecteur ODBC) et donc, comme je disais, à un SI sécurisé et normalisé.

Sur le principe de cette dualité, je suis d'accord. Sur l'approche qu'il faut avoir au niveau des tutoriels, je ne te suis pas. Ça revient de fait à faire se développer deux séries de tutoriels, ceux spécifiques à des besoins précis et ceux destinés au grand public, ce qui est le cas actuellement en ce qui me concerne. Est-ce que ce que je demande (ancrer les exemples dans une minimum de normalisation et de réalité), qui pourrait être un début de réconciliation entre les deux approches, est vraiment inenvisageable, inconcevable et contraire à la recherche d'une certaine efficacité ?

Je ne sais pas comment le considère Pierre-Yves mais pour moi c'est positif car ça permet de procéder à des échanges de points de vue.

Tout à fait, et je pense que c'est une discussion importante, parce qu'elle détermine d'une certaine façon la manière dont une partie du monde de l'Education peut aborder LibO.

Cordialement ;
Marc

#13

Je ne sais pas ce qu'est un BTS CGO :slight_smile: et donc si à la sortie de cet enseignement on utilise Merise et on conçoit et administre des systèmes d'information. Mais si tel est le cas, il est clair que le tutoriel de Pierre-Yves n'est pas pour tes étudiants. Ce n'est pas pour eux que j'avais indiqué ce lien mais pour Michel qui voulait se construire une petite base avec LO. Je ne me suis pas trompé de cible. :slight_smile:
  Au passage, je comprends que tu évites de leur parler de la 4FN ou de la 5FN :slight_smile:

En ce qui concerne la dualité de Base et la cible des tutoriels, mon avis est qu'il n'y a pas à rechercher de convergence ou de compatibilité, chacun y trouvant son besoin :
- le "bureauticien" ayant la possibilité de se construire sa petite base et qui pourra consulter utilement lles tutoriels réalisés par les "collaborateurs" de LO,
- l'organisation (entreprise, administration) disposant avec LO d'une application cliente pouvant accéder à un serveur de bases de données et mis à disposition des "utilisateurs" qui n'ont pas besoin de connaître la 3FN :-), l'infrastructure des données étant déjà en place.
Par contre, dans ce second cas d'utilisation de LO, ce sont des concepteurs et réalisateurs de SI et des DBA qui gèrent les données de l'organisation et ont besoin d'autres choses que des tutoriels (formation, documentation, assistance de l'éditeur, etc. tous moyens pris en charge par l'organisation).

Bernard

#14

Bonjour, Pierre-Yves ;

Bonjour

Marc Romano wrote

Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une
critique de son travail, plus
exactement pas dans le sens négatif de "critique" - certainement pas !
-, mais avec le souci d'apporter quelque chose de précis à la communauté.

C'est bien ainsi que je le prends et je suis flatté de l'attention portée à
ce tutoriel... :slight_smile:

Marc Romano wrote

Du point de vue de la modélisation d'une situation donnée...

Justement, telle n'était pas ma perspective en rédigeant ce tutoriel.

Je m'étais posé la question de son "périmètre" et m'attendait à des
remarques (constructives) de ce type.

J'avais pris la précaution de le débuter par :

Extrait du préambule du tutoriel wrote

/Il va de soi qu'il ne s'agit que d'exemples restreints *sans aucune
réalité fonctionnelle*./

J'ai donc fait des choix, que j'assume, avec comme cible des débutants et
une utilisation bureautique du module.

Contrairement à ce que je pensais, tu es la première personne (depuis 4 ans
que ce tutoriel a été mis en ligne), à souligner ce qui pourrait (devrait)
être développé...

Cela, et le fait qu'on ne peut malheureusement pas être partout, a fait que
je n'ai jamais donné la suite que j'aurais voulu à ce "Débuter...".

Par parenthèse, si je devais y repasser du temps ce serait dans l'immédiat
pour le restructurer de manière à inclure tout de suite les apports de la
version 3.3 et ce sous la forme du FAQ dans le Wiki. Je ne pense pas, au
moment où j'écris, nécessaire de revenir sur la modélisation.

Marc Romano wrote

Il me semble important de montrer que Base est capable de...
...
Le problème posé par Pierre-Yves s'y prête, il suffit juste de
l'adapter...

Nous sommes d'accord... dans l'absolu. J'ai ainsi ajouté/complété une
vingtaine de FAQ sur ce module.

Son évolution reste incertaine me semble-t-il... et j'avoue être un peu
dans l'expectative.

Autre parenthèse : tous mes remerciements à Alex et au(x ?) développeur(s ?)
s'investissant dans la question.

Cordialement
Pierre-Yves

Je ne remets pas en question ta démarche, que je comprends tout à fait, et ce d'autant plus que je ne fournis rien à la communauté de mon côté (pas faute d'en avoir envie, mais... à la retraite, peut-être, avec du temps...).

J'ai cependant une approche différente de la tienne, en ce sens que je trouve dangereuse une approche strictement "bureautique", qui est en fait celle que Microsoft cherche à imposer : on fait des trucs, mais on ne se préoccupe pas de la conformité de ce qu'on fait avec la réalité. Le résultat de cette démarche est, de mon point de vue, assez dramatique : les utilisateurs qui comprennent la philosophie d'un traitement de texte, pour ne prendre que cet exemple, sont rarissimes, les habitudes étant purement "bureautiques", au sens "presse-bouton", et pas du tout rationnelle, en "pensant" la structure de son document, en définissant ce qu'on veut faire avant de le faire.

En ce sens, l'excellent guide "Principes du traitement de texte", de Jean-Yves Royer, est une bénédiction pour les gens qui, comme moi, sont confrontés à des cohortes d'étudiants abreuvés de "frappez au kilomètre et faites la mise en forme après" depuis leurs premiers pas sur un ordinateur, et qui ne connaissent en fait de mise en forme que les quelques boutons disponibles sur une barre d'outils (sans même savoir la plupart du temps qu'il en existe d'autres).

Je pense qu'on devrait avoir la même démarche, quelle que soit la question traité : ne pas raisonner en termes d'utilisation "simplifiée", mais ancrer les exemples dans un minimum de réalité. La complexité qu'on peut rajouter est marginale, comme par exemple pour ton tutoriel, et les exemples qu'on peut donner peuvent ensuite servir de référence sans trop de risques de grosses erreurs. Il est certain que ceux qui apprennent à utiliser un produit, quel qu'il soit, se servent ensuite des exemples qu'on leur fournit pour leurs propres réalisations. Et c'est là que, AMHA, le bât peut blesser, quelles que soient les précautions liminaires qu'on peut prendre.

Ceci dit, je reconnais que c'est une question plus philosophique qu'autre chose. Quoiqu'une récente discussion ici même à propos d'un guide réalisé pour Writer par des enseignants dans le cadre d'une formation m'a montré que les préoccupations que nous pouvions avoir dans l'EdNat en terme de documentation ne sont pas tout à fait les mêmes que celles à laquelle obéit une diffusion plus universelle. C'est d'ailleurs la raison pour laquelle j'ai toujours hésité (et je comprends mieux maintenant pourquoi j'avais de manière intuitive ces hésitations) à proposer mes propres supports à la communauté : ils sont bien trop ciblés, pour un public précis et avec un objectif très calibré, ils ne peuvent en aucun cas entrer dans un cadre plus général (il faudrait les réécrire pour cela, et ils ne répondraient plus à leur objectif premier). Je citais ci-dessus un document sur Writer (excellentissime, je le répète), je le propose à mes étudiants mais je leur fournis aussi un autre document, inspiré par celui-ci, bien plus court et plus centré sur les travaux qu'ils ont à réaliser. Mais l'approche n'est est pas simplement "bureautique", en ce sens qu'elle répond aux principes de base d'une utilisation rationnelle du TdT.

C'est en ce sens que ma démarche se différencie de celle que tu as adoptée pour ce tutoriel : je simplifie parce que cela est nécessaire pour le public visé, mais je veille à rester néanmoins ancré dans la réalité et à respecter une démarche globale bien définie (je ne dis pas en revanche que j'y arrive tout le temps, mais j'essaye, j'essaye... :-[ ).

Je le répète, ce n'est pas une critique négative, mais une réflexion qui cherche à permettre d'améliorer la qualité des documents proposés. Je serais d'ailleurs assez tenté de te proposer de le retravailler et de le faire évoluer avec toi, mais il est fort peu probable que je puisse disposer, du moins d'ici cet été, du temps nécessaire pour cela. On peut en revanche, si tu en es d'accord, y réfléchir pour cet été.

Cordialement ;
Marc

je trouve dangereuse une approche strictement "bureautique"

Je ne suis pas tout à fait d'accord avec toi car je pense que LO est avant tout un outil bureautique fait pour des "bureauticiens" :slight_smile: et on ne peut pas demander à ces gens d'être des experts en 3FN :-).
Si, dans une organisation, on veut un Système d'information fiable, sécurisé, normalisé on utilise des SGBD centralisés et on fait appel à des DBA pour concevoir et implémenter les bases.
De ce point de vue je trouve intéressant de trouver cette dualité dans LO :
- d'une part la possibilité d'utiliser un SGBD simple et embarqué pour les "bureauticiens" qui peuvent développer de petites bases pour leur boulot quotidien,
- d'autre part la possibilité d'accéder à des serveurs de bases de données (MySQL et bien d'autres via le connecteur ODBC) et donc, comme je disais, à un SI sécurisé et normalisé.

Je le répète, ce n'est pas une critique négative

Je ne sais pas comment le considère Pierre-Yves mais pour moi c'est positif car ça permet de procéder à des échanges de points de vue.

Bernard

Si, dans une organisation, on veut un Système d'information fiable, sécurisé, normalisé on utilise des SGBD centralisés et on fait appel à des DBA pour concevoir et implémenter les bases.

C'est un point sur lequel tu prêches un convaincu de longue date... qui fait exactement le contraire à longueur d'année. Pour une raison simple : les programmes et référentiels de certains diplômes qui n'ont à voir avec l'informatique que la notion d'outil de travail et en aucun cas celle d'outil de développement d'applications - je pense au BTS comptabilité et gestion des organisations par exemple et dans une moindre mesure au bac STG - font explicitement référence à ces notions, que ce soit les trois premières formes normales ou la modélisation du SI.

Je suis entièrement d'accord avec toi sur le fait qu'une organisation qui a besoin d'implémenter un SGBDR ne fera certainement pas appel à un comptable pour cela, mais il n'en reste pas moins que si je veux préparer efficacement mes étudiants de BTS CGO à l'examen, je leur parle de MERISE (et MERISE-II-le-retour), de relations en 1, 2 et 3FN (et même un peu plus loin, il le faudrait mais j'évite : ils sont déjà assez paumés avec ça).

Autrement dit, je ne parcours pas ces chemins par plaisir ou purisme mal placé, mais parce que je suis obligé de les suivre. Est-ce que tu accepterais qu'un des enseignants de tes enfants décide de ne pas suivre le programme parce qu'il le trouve inadapté ?

Dans ce contexte, je ne leur donnerai certainement pas le lien vers le tutoriel de Pierre-Yves, parce qu'il s'appuie sur un exemple qui est exactement quelque chose qu'il ne faut PAS faire dans le cadre de ce que je suis censé leur enseigner. Je fais quoi ? Eh bien, j'en écris un spécifique adapté à CE public. Je ne peux pas faire autrement : comment puis-je les orienter vers des exemples qui sont exactement à l'envers de ce qu'on leur demande à l'examen, sauf à passer du temps à retricoter ensuite les bonnes notions ?

De ce point de vue je trouve intéressant de trouver cette dualité dans LO :
- d'une part la possibilité d'utiliser un SGBD simple et embarqué pour les "bureauticiens" qui peuvent développer de petites bases pour leur boulot quotidien,
- d'autre part la possibilité d'accéder à des serveurs de bases de données (MySQL et bien d'autres via le connecteur ODBC) et donc, comme je disais, à un SI sécurisé et normalisé.

Sur le principe de cette dualité, je suis d'accord. Sur l'approche qu'il faut avoir au niveau des tutoriels, je ne te suis pas. Ça revient de fait à faire se développer deux séries de tutoriels, ceux spécifiques à des besoins précis et ceux destinés au grand public, ce qui est le cas actuellement en ce qui me concerne. Est-ce que ce que je demande (ancrer les exemples dans une minimum de normalisation et de réalité), qui pourrait être un début de réconciliation entre les deux approches, est vraiment inenvisageable, inconcevable et contraire à la recherche d'une certaine efficacité ?

Je ne sais pas comment le considère Pierre-Yves mais pour moi c'est positif car ça permet de procéder à des échanges de points de vue.

Tout à fait, et je pense que c'est une discussion importante, parce qu'elle détermine d'une certaine façon la manière dont une partie du monde de l'Education peut aborder LibO.

Cordialement ;
Marc

Je ne sais pas ce qu'est un BTS CGO :slight_smile: et donc si à la sortie de cet enseignement on utilise Merise et on conçoit et administre des systèmes d'information. Mais si tel est le cas, il est clair que le tutoriel de Pierre-Yves n'est pas pour tes étudiants. Ce n'est pas pour eux que j'avais indiqué ce lien mais pour Michel qui voulait se construire une petite base avec LO. Je ne me suis pas trompé de cible. :slight_smile:
Au passage, je comprends que tu évites de leur parler de la 4FN ou de la 5FN :slight_smile:

En ce qui concerne la dualité de Base et la cible des tutoriels, mon avis est qu'il n'y a pas à rechercher de convergence ou de compatibilité, chacun y trouvant son besoin :
- le "bureauticien" ayant la possibilité de se construire sa petite base et qui pourra consulter utilement lles tutoriels réalisés par les "collaborateurs" de LO,
- l'organisation (entreprise, administration) disposant avec LO d'une application cliente pouvant accéder à un serveur de bases de données et mis à disposition des "utilisateurs" qui n'ont pas besoin de connaître la 3FN :-), l'infrastructure des données étant déjà en place.
Par contre, dans ce second cas d'utilisation de LO, ce sont des concepteurs et réalisateurs de SI et des DBA qui gèrent les données de l'organisation et ont besoin d'autres choses que des tutoriels (formation, documentation, assistance de l'éditeur, etc. tous moyens pris en charge par l'organisation).

Bernard

Je ne sais pas ce qu'est un BTS CGO :slight_smile:

Désolé pour l'acronyme non expliqué : Comptabilité et Gestion des Organisations. Ce sont des comptables et des contrôleurs de gestion que l'on forme, pas du tout des informaticiens. Et la modélisation ne peut leur servir, dans le meilleur des cas, que s'ils poursuivent jusqu'au commissariat aux comptes (au minimum 5 ans après être sortis de BTS...), dans la mesure où un commissaire aux comptes est censé valider les procédures qui amènent à construire l'information comptable. Ils ont largement le temps de peaufiner leurs compétences.

Quant aux bases de données et à SQL, qui constituent une part non négligeable de leur examen final, ils ne s'en serviront jamais autrement qu'en kit prêt à l'utilisation dans le cadre de leur métier de base, qui est la comptabilité, pas l'informatique.

En ce qui concerne la dualité de Base et la cible des tutoriels, mon avis est qu'il n'y a pas à rechercher de convergence ou de compatibilité, chacun y trouvant son besoin :
- le "bureauticien" ayant la possibilité de se construire sa petite base et qui pourra consulter utilement lles tutoriels réalisés par les "collaborateurs" de LO,
- l'organisation (entreprise, administration) disposant avec LO d'une application cliente pouvant accéder à un serveur de bases de données et mis à disposition des "utilisateurs" qui n'ont pas besoin de connaître la 3FN :-), l'infrastructure des données étant déjà en place.

Je reste convaincu qu'il n'y aurait pas grand-chose à modifier pour rendre les deux approches compatibles. En quoi le fait de respecter (sans les citer ou les expliciter, ce n'est pas nécessaire) quelques principes simples compliquerait-il un exemple qui reste simple ? D'autant plus - et c'est AMHA le plus important - que la normalisation est porteuse de sens dans ce cas. Autrement dit, et pour jouer sur l'économie des moyens, pourquoi faire deux démarches lorsqu'une seule peut convenir aux deux approches ? Les besoins que j'essaie d'aborder avec mes étudiants ne sont pas fondamentalement plus complexes que ceux qui servent de support dans le tutoriel de Pierre-Yves. Ils sont simplement structurés et normalisés. Je ne vois pas en quoi cela les rend plus compliqués, moins abordables et réservés à une tranche à part de la population. Rien n'interdit de proposer des exemples simples qui restent cohérents par rapport à la normalisation des bases de données. On n'a pas besoin d'expliquer en quoi ils le sont, mais ce n'est pas pour autant qu'ils ne doivent pas l'être.

Je ne crois pas d'autre part que proposer des exemples ou des solutions qui n'aient pas une certaine rigueur professionnelle soit un bon choix. C'est sur la capacité à faire aussi bien que la concurrence qu'est prioritairement jugé LibO, Microsoft ayant réussi à rendre l'argument du prix pratiquement inexistant, en masquant celui-ci dans celui du poste de travail.

Enfin, mets-toi à la place de l'administrateur réseau d'un établissement scolaire, qui cherche (le saint homme...O:-) ou le pauvre fou :stuck_out_tongue: ) à remplacer une certaine suite bureautique proposée aux enseignants à 8 euros par son éditeur par une autre dont il évalue le coût d'achat à quelques minutes de téléchargement. Vers quelles ressources va-t-il envoyer les collègues à qui il "impose" LibO ? S'il ne dispose pas de ressources solides, adaptées aux usages et aux besoins spécifiques en matière d'enseignement, il court tout droit vers la deuxième proposition entre parenthèses ci-dessus...

C'est sur ce point que je voudrais faire évoluer les choses. Et l'enjeu est d'importance : si Office s'impose, c'est pour deux raisons : il est livré presque systématiquement avec chaque PC neuf (je viens d'en recevoir 60, la première chose que l'on fait avant même de les préparer à la mise en production, c'est désinstaller les versions d'évaluation d'Office livrées d'autorité par HP, malgré la demande expresse que j'avais formulé à la commande) et les établissements forment en très grande majorité les élèves sur Office. Les entreprises, pour qui le choix d'une suite n'est souvent pas un critère essentiel, prennent simplement celle que la main d'oeuvre qu'ils recrutent sait utiliser. C'est aussi balot que ça. Et l'un des freins majeurs qu'on rencontre en établissement (surtout en professionnel) est le "mais aucune entreprise ne s'en sert, on va pénaliser nos élèves". C'est faut, bien entendu (c'est même exactement le contraire <http://www.cafepedagogique.org/disci/stt/41.php>, mais c'est très difficile à faire comprendre).

Cordialement ;
Marc

#15

(merci aux participants à la liste de prendre le temps de couper les citations lorsqu'elles n'apportent rien)

tout plein de choses bien :wink:

C'est aussi balot que ça. Et l'un des freins majeurs qu'on rencontre en
établissement (surtout en professionnel) est le "mais aucune entreprise
ne s'en sert, on va pénaliser nos élèves".

Oui, comme si les auto-écoles ne formaient les conducteurs que sur les véhicules qu'ils vont devoir piloter.

C'est faut, bien entendu
(c'est même exactement le contraire
<http://www.cafepedagogique.org/disci/stt/41.php>, mais c'est très
difficile à faire comprendre).

que voilà un article très intéressant et utile. J'en ferai bon usage...

Amicalement,

#16

Je reste convaincu qu'il n'y aurait pas grand-chose à modifier pour rendre les deux approches compatibles.

Ce que je voulais montrer c'est qu'il y a deux façons d'utiliser LO :
- une utilisation individuelle dans laquelle l'utilisateur conçoit lui-même ses bases et, évidemment, il n'est pas dans mes intentions de l'empêcher de s'informer et de se former à la conception des bases relationnelles, et même des bases relationnelles normalisées :-);
- une utilisation en tant qu'application cliente accédant à des serveurs de (base de) données, infrastructure dans laquelle est implémenté le SI de l'organisation. Dans ce cas-là, l'utilisateur n'a pas la main sur le modèle des données, tout étant conçu et réalisé "ailleurs" (par les administrateurs de données, les DBA...).

Pour en revenir au tutoriel de Pierre-Yves, ta principale observation porte sur la relation "FournisseursProduits", avançant l'idée qu'une commande pourrait porter sur plusieurs occurrences d'un même produit mais affectées de prix différents. C'est quand même un cas assez particulier et je suppose que la base exemple de Pierre-Yves se voulait relativement courante.

Quant à la relation "DétailCommande" proposée par Pierre-Yves, là aussi c'est assez classique d'identifier cette relation par un numéro de ligne.

D'autre part

du point de vue de la règle d'unicité des données, c'est une erreur

Je ne suis pas tout à fait d'accord avec cette affirmation : ce n'est pas toujours une erreur car cela peut être le résultat d'une dénormalisation volontaire de la relation. J'ai appris par la formation et l'expérience que dans certains cas il était intéressant, pour des raisons de simplification et de performance, de procéder à une certaine dénormalisation.

Pour en terminer, concernant le point que tu soulèves quant aux difficultés à imposer LO face à MS Office, il me semble que les administrations et entreprises qui se tournent vers LO le font essentiellement pour les modules Writer et Calc et c'est plutôt de ce côté-là que se situe leur besoin de formation et de documentation, plus que pour le module Base (parce que dans les organisations importantes le Système d'information est "ailleurs").

Content d'avoir échangé avec toi, mais peut-être devrions-nous nous en tenir là, la discussion se réduisant à nous deux seulement :slight_smile:

Bon dimanche et à un prochain fil de discussion :slight_smile:

Bernard

#17

Je plussoie abondamment

Jean-Michel

#18

Il y aurait en effet de quoi alimenter encore une discussion intéressante, notamment sur une erreur d'interprétation que tu commets concernant ce que je dis de la relation "FournisseurProduit" et sur la dénormalisation volontaire possible dans certains cas.

Mais quelques réactions montrent en effet que cette discussion n'intéresse personne. Autant en rester là, par conséquent.

Bon dimanche, et bonnes fêtes à tous.
M.

#19

Bonjour à tous,
Cette discussion m'intéressait énormément étant peu habitué aux bases de données. Vous m'avez ouvert de nombreuses pistes de recherche pour apprendre.
D'ailleurs j'ai repris cette discussion sous writer et cherche à me la présenter d'une manière plus assimilable à mon niveau faible.

Encore merci à tous.
Jacques
D'ailleurs

#20

Désolé de vous avoir offensé. De plus ce n'était pas le bon lien.
Cela dit, je comprends votre agacement après avoir lu le très intéressant article de Marc Romano. Etant moi-même enseignant en retraite, je comprends tout à fait son propos procédure contre presse-bouton.
Je vous renouvelle toutes mes excuses.

Cordialement,
Sandy-Pascal Andriant