[Access] La relation de type « un à un » (suite)

1 réponse

suite à l’article: [Access] La relation de type « un à un »,

voici pourtant ce qu’on peut lire dans le livre : Access 2007 et VBA (paru en 03/2008)
par Bernard Minot, Jean-Michel Léry

dont l’extrait ci-dessous est disponible chez Google books à la page 42:

Les relations de 1 à 1
Nous supposons la présence de deux tables contenant des données relatives, par exemple, à vos contacts professionnels, d’une part, et à vos contacts personnels, d’autre part. La conjugaison de ces deux tables peut se décliner ainsi :
– Un contact professionnel correspond soit à zéro, soit à un et au plus un contact personnel (un partenaire commercial peut aussi être un ami !) ;
– Un contact personnel correspond soit à zéro, soit à un et au plus un contact personnel (même raison).
Nous sommes ici devant une relation de un à un. A priori, et pourvu que les uns et les autres n’aient pas de rôle particulier à jouer dans le système d’information à mettre en place, il n’y a aucune raison pour ne pas fusionner purement et simplement les deux fichiers. La seule opération à mettre en place avant ladite fusion consiste à créer une propriété particulière à la table qui fusionne les deux fichiers pour distinguer les « commerciaux » des « amis personnels ». Cet exemple peut être généralisé : les relations de un à un dans une base bien conçue n’existent pas(1).

(1). Seul cas de figure possible : si la table doit compter plus de 255 colonnes, il sera nécessaire de créer une table « fille ».

grrrmffff…

[Access SQL] le cas DISTINCTROW

2 réponses

Si vous avez déjà cherché des solutions pour éliminer les doublons dans vos tables/requêtes, vous connaissez probablement déjà le mot-clé DISTINCT qui fait partie de la norme SQL.

Mais connaissez-vous le prédicat Access DISTINCTROW ?

Certains, oui :
DISTINCTROW ou l’exemple parfait de l’absurdité d’Access !

Rideau… ;-)

Lire la suite →

[Access SQL] Requêtes complexes avec l’assistant QBE (Exercice 1)

3 réponses

Le but des exercices proposés dans cette rubrique est de s’exercer à la construction de requêtes complexes sous Access.
J’essaierais donc de proposer des exercices couvrant le maximum des possibilités offertes par le langage SQL Access, c.-à-d. des jointures internes, externes, des fonctions de regroupement, des filtres, des sous-requêtes, des analyses croisées etc.

Par contre j’aimerais que les solutions aux exercices restent à la portée du débutant.
Le gros code SQL tout rouge et qui tâche est donc proscrit ici tout comme l’usage de fonctions VBA personnalisées.

Seules les solutions obtenues avec l’assistant QBE (Query By Example) d’Access seront retenues.
Lire la suite →

[Access] La relation de type « un à un »

1 réponse

…ou réhabilitation de la relation de type « un à un » sous Access (modeste tentative):

Résumé: Autant le dire tout de suite. La relation de type « un à un » (-1——-1-) n’a pas la cote chez les développeurs Access et est souvent ignorée chez le débutant qui n’y verrait de toute façon qu’une source de complications supplémentaires dans ses développements.
Tantôt perçue comme une « erreur de conception », tout au plus un artifice permettant de franchir la barre des 255 champs pour une table Access (ce qui rend pourtant la conception suspecte), la relation « un à un » sera ignorée aux profits de traitements peut être allégés mais souvent aux dépends de l’intégrité, de la cohérence des données et des performances.
Lire la suite →