C'est une clé composée.
Et je suis d'accord : avec OOo Base on peut faire des petites choses sympa.
Je souhaite bonne continuation à l'association et à l'animateur !
Bonne soirée,
Bernard
Le 04/06/2010 18:15, Claude FRICARD a écrit :
Bernard,
Pour ce qui est des *"relations un à un"* nous sommes d'accord :peu
d'intérêt.
A ta question " est-ce qu'ACCESS admet deux clés PRIMAIRES " la
réponse est dans cet copie d'écran
Pour chaque relation il est possible de définir en plus du type de
jointure certains contraintes et dispositions caractérisant la relation.
Avec le profil des personnes qui sont à l'association nous ne faisons
pas de choses aussi complexes et en utilisant OOo Base pour des
applications simples on peut s'en tirer, c'est que j'essaie avec mes
moyens de faire passer comme message... ;-)
Cordialement
Claude
Le 04/06/2010 16:30, ribotb a écrit :
J'ai lu trop rapidement et n'avait pas vu que cette table "suite"
n'était là que dans un but pédagogique. Mea culpa...
Ceci dit, de façon générale, je pense que ça n'a aucun intérêt,
l'opération de projection étant là pour sélectionner des colonnes
dans le tuple.. Nécessaire éventuellement à cause de contraintes
techniques imposées par un SGBD (longueur limitée pour un
enregistrement par exemple)...
Sinon, pour ma culture générale :-)) , est-ce qu'ACCESS admet deux
clés PRIMAIRES ? Si c'est le cas cela conforterait mon idée qu'ACCESS
n'est pas un vrai SGBD relationnel (en tout cas non conforme au
modèle relationnel de Codd). Je me demande bien d'ailleurs dans le
cas où ce serait réellement deux clés primaires comment fonctionnent
les règles de suppression et mises à jour de clés primaires (surtout
les opérations en "cascade").
Bonne fin de journée,
Bernard
Le 04/06/2010 14:09, Claude FRICARD a écrit :
Bernard,
Ainsi que je l'ai précisé c'est seulement parce que quelqu'un parmi
les élèves me demandait un exemple de *relation un a un* que j'ai
crée cette table T_ouvrages_suite en relation avec ouvrages. Cette
table a été enlevée ensuite pour continuer à construire ensemble
une base de gestion de bibliothèque. Mon propos était de dire que s'
il devait y avoir beaucoup d'informations dans une table , on peut
en créer 2 et les mettre en relation. Ceci présentant l' intérêt
d'avoir un formulaire basé sur une des tables. Je me suis empressé
de rajouter que si ce type de relation existe il n'est en pratique
que peu utilisé.
La possibilité de mettre 2 clés dans une table existe avec Access
mais étant donné que c'est d'un intérêt très limité ce point peut
très bien ne pas faire l'objet d'une implémentation.
Je note tout de même les liens proposés par François.
Claude
Le 04/06/2010 12:33, ribotb a écrit :
Bonjour Claude et François,
Je viens de prendre connaissance votre échange sur OOo Base, et
j'ai deux petites remarques à faire à Claude.
La première réflexion qui m'est venue est : pourquoi cette table
"suite" car j'ai l'impression que "lieu de publication" est un
attribut de la clé primaire "ID" de la table "ouvrages".
Et 2ème remarque : dans le modèle relationnel il ne peut y avoir
qu'une seule clé primaire. Par contre il existe dans le modèle
relationnel le concept de clé alternée (pour faire simple : sorte
de clé primaire qui n'a pas été choisie comme... clé primaire),
mais je ne pense que ce concept soit implémentée dans HSQL..
Bonne journée,
Bernard
Le 04/06/2010 08:59, Claude FRICARD a écrit :
L'exemple que j'ai mis a été utilisé pour montrer à mes "élèves" à
l'association ce que pourrait être une relation 1 à 1. (en plus de
la relation 1 à plusieurs). Mon but dans ce cadre est d'apprendre
à faire une base simple, pour une application domestique. IL est
probable que la base développée ensemble ne respecte pas tous les
fondamentaux et les principes de Merise ...(Merise sur le G...)
;-) . Jusqu'à maintenant j'ai développé plusieurs bases soit avec
Access soit avec OOo Base, elle fonctionnent.
Dans le cadre d'un Projet, ces principes sont utiles j'en suis
convaincu. Il reste que l'amélioration des assistants rendrait cet
outil plus accessible au plus grand nombre.
Merci François pour ces indications et recommandations
Claude
Le 03/06/2010 18:53, Francois Gatto a écrit :
Bonsoir,
Le 03/06/2010 14:30, Claude FRICARD a écrit :
François, (et autres)
Effectivement en mode ébauche la relation entre tables est bien
établie.
Il est clair que je ne considérais pas ceci comme un bug mais
comme une
amélioration.
Puis-je en profiter pour demander si le fait de ne pas pouvoir
mettre 2
clés Primaires sur la même table, peut être considéré comme une
"undocumented feature" ... ;-)
Exemple :
Je peux mettre la table OUVRAGES en relation avec
T_OUVRAGES_SUITE parce
que la clé primaire est du côté 1 de la relation avec la table
:AUTEURS,
par contre si j'avais souhaité établir une relation 1 à 1 avec
la Table
AUTEURS je n'aurais point pu ...(en tout cas pas en 3.1.1)
Certes on peut s'organiser pour ne pas avoir ce contexte, mais ...
Claude
Il me semble que ta base ne suit pas les fondamentaux des SGBD[-R].
Peut-être ne serait-il pas inutile que tu repenses l'architecture
de ton projet en respectant les règles de modélisation comme
celles issues de Merise et/ou d'UML
http://fr.wikipedia.org/wiki/Merise_(informatique)
http://fr.wikipedia.org/wiki/Unified_Modeling_Language
Il existe de nombreuses sources d'informations sur le Net dont
celles-ci :
http://sgbd.developpez.com/
http://merise.developpez.com/faq/?page=MCD
http://www.buvetteetudiants.com/downloads/documents_par_categories.php?categorie_id=21
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
