Discussion :

[kabbaj.med]

J'ai deux tables, la première table : ILOTS et la 2ème table : POSTES

un ILOT peut contenir plusieurs postes.
Un poste appartient à un seul ilot.

Mais le problème, c'est que: par exemple, dans ILOT 1 : j'ai Nom poste: POSTE1 , OBjectif POSTE :350
dans ILOT 2 : j'ai, Nom poste : POSTE 1, Objectif POSTE: 400
comment gérer cela?

merci

[Malick]

Voici une proposition prenant en compte votre relation un à plusieurs :

[kabbaj.med]

NOM_ILOT est unique, donc il doit être obligatoirement clé primaire.
Dans la table POSTES, le NOM_POSTE doit être unique pour un ILOT, et non unique pour plusieurs ilots

[fsmrel]

Bonjour,

NOM_ILOT est unique, donc il doit être obligatoirement clé primaire.

Non. Une clé candidate garantissant l’unicité, l’attribut NOM_ILOT fait donc l’objet d’une clé candidate, nuance !


Dans le digramme de milkoseck, la table POSTE est dotée de deux clés candidates : {idPoste} et {nomPoste}.

Un clé primaire est une des clés candidates de la table, on la choisit de préférence parce qu’elle est non significative et invariante. Dans ces conditions, {idPoste} étant seule à remplir ces conditions, c’est elle qui doit jouer le rôle de clé primaire (concept du reste évacué de la théorie relationnelle qui ne conserve que celui de clé candidate), tandis que {nomPoste} devient clé alternative. Tout ceci est transparent pour l’utilisateur de la base de données.

[kabbaj.med]

le même problème réapparaît.
Il faut que:
Pour chaque NOM_ILOT, on a plusieurs NOM_POSTE
Mais le NOM_POSTE est unique pour un seul NOM_ILOT.
Si je saisi un nouvel Ilot, il faut que le NOM_POSTE sera enregistré
Le NOM_POSTE est unique pour un seul NOM_ILOT

[fsmrel]

Pour chaque NOM_ILOT, on a plusieurs NOM_POSTE
Mais le NOM_POSTE est unique pour un seul NOM_ILOT.

« NOM_POSTE est unique pour un seul NOM_ILOT » : cette formulation est bizarre. Il faudrait que vous l’expliquiez.

Mais le problème, c'est que: par exemple,
dans ILOT 1 : j'ai Nom poste : POSTE 1, Objectif POSTE :350
dans ILOT 2 : j'ai Nom poste : POSTE 1, Objectif POSTE: 400

POSTE 1 est donc en relation à la fois avec ILOT 1 et ILOT 2. Dans ces conditions, les règles deviennent les suivantes :

Un îlot peut être associé à plusieurs postes ;

Un poste peut être associé à plusieurs îlots ;

Pour un îlot et un poste donnés il y a un seul objectif.

Le diagramme devient :





Bien entendu, {nomPoste} est clé alternative de la table POSTE et {nomIlot} est clé alternative de la table ILOT.

[kabbaj.med]

je vais t'expliquer avec un autre exemple pour mieux comprendre:

On a 3 tables: VILLE, ECOLE, CLASSE.

les tables sont présentées comme suit:

VILLE(NOM_VILLE)

ECOLE(NOM_ECOLE;NB_ETUDIANTS)

CLASSE(NOM_CLASSE,NB_ETUDIANTS_CLASSE)

On a :
- Le nom de la ville est unique.
- Le nom de l'école est unique au sein de la ville ( on ne peut pas trouver deux écoles portant le même nom dans la même ville, par contre, on peut trouver le même nom de l'école dans une autre ville).

-le nom de la classe est unique au sein de l'école, au sein de la ville aussi ( mais on peut trouver le même nom de classe dans une école dans une autre ville)
- le nombre des étudiants dans l'école est la somme des étudiants des classes qu'ils appartiennent.

En attente d'une réponse.
Merci de me joindre la réponse dans un fichier MDB

[fsmrel]

Bonsoir,


La situation n’a rien à voir avec la précédente. Quoi qu’il en soit, le diagramme ACCESS correspondant à votre dernier exemple est le suivant :

le nombre des étudiants dans l'école est la somme des étudiants des classes qu'ils appartiennent.

Donc l’attribut NB_ETUDIANTS de votre table ECOLE provoque une redondance. La redondance étant l’ennemie des bases de données, cet attribut NB_ETUDIANTS doit disparaître de la table ECOLE.

Pour connaître le nombre d’étudiants pour chaque école, une requête suffit :

SELECT NomVille, NomEcole, SUM(NbEtudiantsClasse) AS NbEtudiantsEcole
FROM   CLASSE
GROUP BY NomVille, NomEcole ;

Pour étudier tout ça, vous pouvez exécuter la macro GO du fichier joint. Cette macro permet de créer les tables et les peupler.