Unité de temps, de lieu et d’action dans le théâtre et dans FileMaker ?

Maintenant que je ai vous immergé dans l’univers du théâtre, je vous propose d’aller plus loin avec un article écrit à quatre mains.

Nous vous proposons dans un premier temps de découvrir à travers une règle d’écriture historique bien connue : la règle des trois unités, qui s’impose peut à peu au XVII° siècle pour être ouvertement contestée au XIX° siècle par des auteurs romantiques tels que Victor Hugo ou Stendhal.

Dans un second temps, nous verrons que la création de base de données FileMaker possède lui aussi une règle, finalement assez proche de celle du théâtre 😉

La règle de l’unité dans le théâtre

En 1674, Boileau, dans son Art Poétique (Chant III), en parle en ce termes :
Qu’en un lieu, qu’en un jour, un seul fait accompli /
Tienne jusqu’à la fin le théâtre rempli.

Avec cette règle, l’organisation d’une pièce de théâtre pouvait donc paraitre plus simple.

Voici un petit précis sur ces trois unités :

L’unité d’action :
Il n’y avait qu’une intrigue principale et les intrigues secondaires y étaient rattachées pour permettre une bonne compréhension de l’action par le spectateur.

L’unité de temps :
L’action se concentrait sur 24h.

L’unité de lieu :
L’action se déroulait dans un lieu unique (et donc un décor unique).

Poussons la comparaison avec votre Data serviteur encore plus loin avec les règles de saisie d’une données.

La règle de l’unité concernant FileMaker…

La transposition dans l’univers FileMaker ne paraît pas aller de soi.
Et pourtant… FileMaker est un éditeur de bases de données relationnelles.

Qu’est-ce que cela veut dire concrètement ?
Cela veut dire que les données sont liées entre elles. Qu’elles sont en relation.

Dans quel objectif ?

Pour trouver partout où l’on se trouve les informations dont on a besoin sans avoir à les saisir en plusieurs lieux.

Là, vous me voyez venir…

Les habitués de FileMaker voient parfaitement de quoi je veux parler, mais je vais prendre un exemple, pour me faire comprendre de tous.

Imaginons que je sois une troupe de théâtre et que j’ai créé un fichier dans lequel je saisis tous mes contacts et mes clients.
Imaginons en outre que je suis débutante et que mon fichier est ce qu’on appelle un « fichier plat », c’est-à-dire monotable (une seule table, avec des tas de rubriques pour pouvoir faire tout ce que j’ai à faire).

J’ai une rubrique Raison sociale, une autre Prénom, une autre Nom… Je saisis donc mes contacts. Si plusieurs appartiennent à la même société, Dupont SA par exemple, je suis obligée de saisir Dupont SA autant de fois qu’il y a de contacts appartenant à cette société, alors même que cette information, d’un salarié à l’autre, est strictement la même !

Imaginons maintenant, qu’en plus de mon fichier de contacts, j’ai un fichier, également monotable, pour réaliser les factures.

Si je facture mes prestations à la société Dupont SA, je dois saisir cette information dans la facture. Si je réalise plusieurs factures pour cette même société, je dois saisir autant de fois que nécessaire cette même information.

Vous pressentez ici ce qu’a d’aberrant et de dangereux cette situation.

Aberrant, car l’informatique est là pour nous faire gagner du temps et non en perdre à saisir plusieurs fois la même chose et à rechercher l’information lorsqu’on ne l’a pas sous la main rapidement…

Dangereux, car inévitablement, le fait de devoir saisir plusieurs fois la même information en des endroits différents (enregistrements / fichiers) est un facteur d’erreurs de saisie ou d’oubli. D’accord, Dupont SA, ce n’est pas trop compliqué, mais il faut déjà savoir si Dupont s’écrit avec un « t » ou un « d » à la fin ! Et si vous tombez sur un nom genre Pichtchalnikov, pour nous autres dont la langue est d’origine latine, cela devient un peu compliqué à mémoriser 😉

Aussi, le développement de bases de donnés relationnelles possède une règle simple, que l’on pourrait finalement très bien mettre en parallèle avec celle de Boileau pour le théâtre :

• Une seule saisie (unité d’action)
• à un seul endroit (unité de lieu)
• à un seul moment (unité de temps)

même si cette règle génère une situation paradoxale : pour obtenir cette unité, il nous faut passer du mono-table au multi-table !

Si je reprends mon exemple ci-dessus, qu’est-ce que cela donne ?

D’abord, je n’ai pas deux fichiers (ou N fichiers) mais un seul. Ce qui simplifie du coup la maintenance  de la base (sauvegardes, partage et sécurisation des données…).

Chaque fichier, grosso modo, est remplacé par une table. Ainsi, je vais avoir au minimum une table Contact et une table Facture. Mais d’autres tables vont s’ajouter à celles-ci : celle dans laquelle on saisit la raison sociale et toutes les informations relatives à la société (1), une autre pour les adresses, de même pour les moyens de télécommunication, les produits ou services facturés…

Une fois conçue ainsi, la fiche d’un contact possédera des données provenant d’une table Société, d’une table Adresse et d’une table Telecom, en plus des données natives de sa propre table Contact.

Une facture utilisera des données provenant de Société, Adresse et Produits, en plus des données de la table Facture.

Et ainsi de suite…

En résumé, pour obtenir la simplicité et la sécurité de la saisie des données, il faut réaliser un travail important en amont, travail que l’on appelle « modélisation » (mise en modèle de la circulation des données à travers des liens 2)…

Mais le retour sur investissement de tout ce travail est évident !

Comme pour les pièces de théâtre de la période classique… l’unité d’action, de lieu et de temps fait que tout est concentré, centralisé en une seule base et facilement accessible pour l’utilisateur.

En revanche, la possibilité de créer des tables à l’infini, et donc des liens entre les tables, et donc d’ajouter des modules à une première version de votre base, éloigne toute menace de monotonie et ouvre la porte à la créativité en laquelle les romantiques se reconnaîtraient bien ;-).

Alors, est-ce que FileMaker réconcilierait les Anciens et les Modernes (3), Racine, Corneille, Hugo et Stendhal ?

Dénissa Baudouin et Marie-Charlotte Potton

(1) : Certains développeurs ne créent pas deux tables distinctes pour saisir les sociétés et les personnes. Ils jouent sur une relation particulière qui lie une table à elle-même. Dans notre exemple, il est plus simple pédagogiquement parlant de présenter deux tables différentes plutôt qu’une seule et même table…

(2) : La modélisation est au coeur de la formation Personne-ressource FileMaker. C’est très certainement la partie la plus délicate à s’approprier versus FileMaker.
Certains tutoriels d’auto-formation peuvent également vous aider sur ces questions mais nous vous conseillons vivement d’être accompagné pour cette partie de votre projet FileMaker.

(3) : Je fais bien entendu allusion ici à la querelle des Anciens et des Modernes qui opposaient, du temps du Roi Soleil, ceux qui pensaient que les auteurs de l’Antiquité étaient indépassables et qu’il fallait dès lors les imiter ou tout au moins s’en inspirer – d’où la règle des trois unités énoncée par Boileau – et leurs contemporains, qui, quant à eux, s’autorisaient à plus d’indépendance par rapport au modèle antique et qu’il convenait de s’adapter à son temps et à son époque !

Premier article / Article précédent / Article suivant

Tags: Analyse, liens, modélisation, Relationnel, théâtre