Discussion :

[emirov]

Bonjour j'ai un modele de base relationelles et je fois le corriger afin de respecter les 3 formes normales e je voudrais demander votre aide afin de pouvoir le corriger et de savoir si j'ai trouvé les bonnes erreurs.....

les 3 formes normales a respecter:

1FN - première forme normale :

* tout attribut contient une valeur atomique
* tous les attributs sont non répétitifs
* tous les attributs sont constants dans le temps.

2FN - deuxième forme normale

* elle respecte la première forme normale
* tous les attributs non-clés sont totalement dépendants fonctionnellement de la totalité de la clé primaire.

3FN - troisième forme normale

* elle respecte la deuxième forme normale
* tous les attributs n'appartenant pas à une clé ne dépendent pas d'un attribut non-clé


merci beaucoup les amis j'attends votre aide


Voila les tables qui sont presentes dans le model relationel :












si vous voulez mieux voir les tables il suffit de telecharger l'image et sur votre pc sa sortira tres bien....

ou sinon voila le fichier en access : http://www.mediafire.com/?z9w1ejelhjw


merci les amis

P.S.: le forum est exceptionnel je n'ai jamais vu mieux !

[fsmrel]

Bonsoir,


Je n’ai pas réussi à ouvrir votre fichier emirov(Epi_d'or_2008.mdb.accdb).accdb
En tout cas, puisque vous utilisez Access, vous pourriez fournir le modèle logique de vos tables (icône Relations).

Quelques observations :

Définissez des clés primaires non porteuses d’information et non modifiables par l’utilisateur.

Par exemple, concernant la table Client (ce que vous appelez Liste des clients), sa structure devient la suivante, dans laquelle Id_Client est clé primaire (soulignée en trait continu ci-dessous), tandis que No_Client devient clé alternative (en bleu), garantissant l’unicité des valeurs :

{Id_Client, No_Client, Categorie_Client, Nom_Client, Adresse_Client, No_de_téléphone}

Toujours concernant la table Client, avant de pouvoir parler de normalisation, il est nécessaire de définir l’ensemble des clés candidates. On en connaît deux, mais peut-être en existe-t-il d’autres, en fonction des réponses données aux questions suivantes :

Peut-on avoir deux clients à la même adresse ? deux clients ayant même numéro de téléphone ? deux clients ayant le même nom ?

Par ailleurs, si ce n’est déjà fait, il serait bon de définir une table CategorieClient (clé primaire soulignée) :

{Id_Categorie, Libelle_Categorie, ...}

afin de mettre un procédé classique de modélisation. La table Client devient la suivante (clé étrangère en italiques) :

{Id_Client, No_Client, Id_Categorie, Nom_Client, Adresse_Client, No_de_téléphone}

Le libellé de la catégorie est obtenu par jointure naturelle des tables Client et CategorieClient.

Etc. Même principe pour les autres tables.

(Et surtout, n'oubliez pas de nous mettre quelques croissants de côté...)

[emirov]

Bonjour


Merci pour votre aide concernant la table clients...

pour les questions sur cette table:

-non on ne peut pas avoir des clients avec la meme adresse
-pas de clients avec le meme numero de telephone
-pas de clients avec le meme nom.



merci becauoup pour votre aide sinon voila j'ai remis le fichier ca serait gentil de m'aider avec les autres tables...

merci beaucoup


Fichier: http://rapidshare.com/files/10219771...00887.mdb.html

quand vous ouvrer le fichier une fenetre va peut etre apparaitre cliquez plusieurs fois sur ok et ca devrait marcher.


merci encore

[fsmrel]

Bonjour,


Je n'arrive toujours pas à ouvrir le fichier Epi_or_200887.mdb. J'utilise Access 2003.

A ceci près, d'après vos réponses, on peut considérer que les attributs Nom_Client, Adresse_Client et No_de_téléphone sont des clés candidates. La table Client est en 3e forme normale.

Concernant la table des produits, est-ce que pour une valeur de l'attribut Designation_du_produit on peut avoir plus d'une valeur pour l'attribut Reference_du_produit ?

De même que je vous ai conseillé de définir une table CategorieClient, je le fais à nouveau concernant une table CategorieProduit.

[emirov]

merci de votre aide si precieuse

sinon:

-pour la designation d'un produit on ne peut avoir qu'une seule reference du produit

-par contre pour une categorie de produit on peut avoir plusieurs references de produits et aussi designations de produits.



merci de votre aide


essayer de retelecharger ce fichier peut eter ac va marcher :

http://rapidshare.com/files/10231345...d_or_2008.html




desolé de vous deranger c'est vraiment gentil de m'aider


merci infiniment

[emirov]

Bonsoir,


Je n’ai pas réussi à ouvrir votre fichier emirov(Epi_d'or_2008.mdb.accdb).accdb
En tout cas, puisque vous utilisez Access, vous pourriez fournir le modèle logique de vos tables (icône Relations).

Quelques observations :

Définissez des clés primaires non porteuses d’information et non modifiables par l’utilisateur.

Par exemple, concernant la table Client (ce que vous appelez Liste des clients), sa structure devient la suivante, dans laquelle Id_Client est clé primaire (soulignée en trait continu ci-dessous), tandis que No_Client devient clé alternative (en bleu), garantissant l’unicité des valeurs :

{Id_Client, No_Client, Categorie_Client, Nom_Client, Adresse_Client, No_de_téléphone}

Toujours concernant la table Client, avant de pouvoir parler de normalisation, il est nécessaire de définir l’ensemble des clés candidates. On en connaît deux, mais peut-être en existe-t-il d’autres, en fonction des réponses données aux questions suivantes :

Peut-on avoir deux clients à la même adresse ? deux clients ayant même numéro de téléphone ? deux clients ayant le même nom ?

Par ailleurs, si ce n’est déjà fait, il serait bon de définir une table CategorieClient (clé primaire soulignée) :

{Id_Categorie, Libelle_Categorie, ...}

afin de mettre un procédé classique de modélisation. La table Client devient la suivante (clé étrangère en italiques) :

{Id_Client, No_Client, Id_Categorie, Nom_Client, Adresse_Client, No_de_téléphone}

Le libellé de la catégorie est obtenu par jointure naturelle des tables Client et CategorieClient.

Etc. Même principe pour les autres tables.

(Et surtout, n'oubliez pas de nous mettre quelques croissants de côté...)

je n'ai pas compris ce que c'est Id_client quelles valeurs on y met vu que ce n'est pas Num_client.... ?


merci beaucoup de votre aide

[emirov]

personne pour m'aider avec les 3 formes normales?

merci les amis

[fsmrel]

Bonsoir,

personne pour m'aider avec les 3 formes normales?

Si, mais laissez-nous souffler...

Je change un peu la définition de la 1re forme normale (1NF), en partant du principe qu’une table est un ensemble. La définition que je donne est celle de Ted Codd, père du Modèle Relationnel de Données :

Une table est en première forme normale si aucun de ses attributs ne peut prendre de valeur qui soit elle-même un ensemble.

On peut dire que vos tables sont en 1NF, puisque leurs attributs prennent des valeurs du type Caractère, Entier, Date, etc., elles sont simples, "atomiques". Sinon, pour ne pas être normalisées, il faudrait qu’elles soient du type Table ou tout autre type complexe.

Votre définition de la 2e forme normale (2NF) est incomplète, aussi je la remplace par celle de Codd :

Une table est en 2e forme normale si elle est en 1re forme normale et si chaque attribut qui n’appartient pas à une clé candidate est en dépendance totale de chaque clé candidate de cette table.

Je rappelle d'abord qu'une clé candidate est un ensemble d'attributs K d'une table T vérifiant les deux règles :

Unicité : Pour une valeur de K, chaque attribut de T ne peut prendre qu'une seule valeur.
Irréductibilité : il n'existe pas de sous-ensemble K' strictement inclus dans K qui vérifie lui aussi la règle d'unicité.

Prenons le cas de la table Client : elle a pour clé candidate l’attribut No_Client, mais aussi l’attribut No_de_Telephone (vous avez précisé qu’un n° de téléphone est celui d’au plus un client, ce qui paraît normal), ainsi que l’attribut Adresse_Client (attention aux clients qui habiteraient dans la même tour) ou encore l’attribut Nom_Client (attention quand même aux clients homonymes).

Concernant la dépendance totale : Un attribut A d'une table T dépend (fonctionnellement) d’un ensemble d’attributs E de T si pour une valeur de E, on a une seule valeur pour A. La dépendance est totale si A ne dépend pas que d’une partie de E. Par exemple, il est vrai que {Adresse_Client} dépend du couple C représenté par {No_Client, Categorie_Client}, c'est-à-dire que pour une valeur de C il ne peut y avoir qu’une valeur pour Adresse_Client, mais la dépendance n’est pas totale, car il existe aussi une dépendance entre le sous-ensemble {No_Client} de C et {Adresse_Client} : la dépendance entre {No_Client, Categorie_Client} et {Adresse_Client} est dite partielle. En revanche, la dépendance entre {No_Client} et {Adresse_Client} est totale, parce qu’’il n’y a pas de sous-ensemble de {No_Client} garantissant la dépendance (cet ensemble serait du reste l’ensemble vide).

Je pense que vous avez maintenant les éléments pour vérifier que la table Client est en 2e forme normale.

Vous devriez arriver à montrer qu’elle est aussi en 3e forme normale.

J’ai noté que la table Detail_des_Commandes n’a pas de clé : ça n’est qu’un sac. Dépêchez vous de dresser le catalogue de ses clés candidates, avant de vérifier la normalisation.

[fsmrel]

Bonsoir,

essayer de retelecharger ce fichier peut eter ac va marcher :

C’est bon.

je n'ai pas compris ce que c'est Id_client quelles valeurs on y met vu que ce n'est pas N°_client.... ?

J’avais déjà précisé que la clé primaire d’une table ne doit pas être porteuse d’information que l’on puisse interpréter. Cette règle n’est pas absolue, mais il s’agit de prendre de bonnes habitudes dès le départ. Ainsi, que se passera-t-il quand l’utilisateur éprouvera le besoin de modifier le numéro de client 411003 parce qu’à son sens ce numéro n’est pas le bon ? Dans votre cas, le travail de garantie de la cohérence des tables est assez simple, car il s’agit seulement de remplacer ce numéro de client par le nouveau numéro dans la table Client et d’en faire autant dans la table Commande. Mais c’est là le hic, il y a double modification (dans votre cas, mais parfois, pour une modification d’une clé primaire, il peut y avoir de nombreuses tables impactées et ça devient moins drôle).

L’enjeu est donc de n’avoir que la seule table Client qui soit à modifier, pas la table Commande. Autrement dit, le numéro de client ne doit pas figurer dans cette dernière. On utilise alors un nouvel attribut, en l’occurrence Id_Client, qui figure à la fois dans les tables Client et Commande et qui a surtout pour propriété fondamentale de ne jamais changer de valeur. C’est Id_Client qui composera à lui seul la clé primaire de la table Client, tandis que N°_Client sera ravalé au rang de clé alternative. L’utilisateur pourra toujours accéder au client École Buridan via son numéro 411003 (voire modifier ce numéro), mais la navigation dans la base de données se fera par le canal de Id_Client. La valorisation de Id_Client est à confier à Access.

Si vous décidez de me suivre,

1) Pour modifier la structure de la table Client et la mettre à niveau :

a) En mode Création, désactivez la propriété clé primaire pour l’attribut N°_Client. Vérifiez que cet attribut est indexé avec l’option "sans doublons". Vérifiez que les nulls y sont interdits.

b) Ajoutez l’attribut Id_Client et utilisez le type de données NuméroAuto (Access se chargera par la suite de valoriser l’attribut, pour chaque client : 1, 2, 3, etc.) et faites-en la clé primaire de la table.

c) Regardez ensuite le contenu de la table Client, vous devriez voir les valeurs attribuées par Access à Id_Client.

2) Ensuite, il faut synchroniser la table Commande :

a) Ajoutez l’attribut Id_Client, en retenant le type numérique (entier long).

b) Exécutez une requête permettant de répercuter les valeurs de l’attribut Id_Client dans la table Commande. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Update Commande
      Set  Id_Client = (Select Id_Client
                        From   Client b
                        Where  b.Num_Client = Numéro_du_client)

En cas de problème, faites le travail à la main, il n’y en a pour longtemps, mais soyez vigilant.

c) Pour vérifier visuellement que les commandes sont affectées aux bons clients, exécutez une requête SQL du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Select  Numéro_de_la_commande, No_Client, Nom_Client
From    Commande, Client
Where   Commande.Id_Client = Client.Id_Client

(Vous aurez noté que l'on n'a même pas besoin d'afficher Id_Client qui reste invisible pour l'utilisateur.)

d) Quand tout est bon, supprimez la colonne Numéro_du_client de la table Commande.

A terme, Quand tout sera terminé pour la base de données, n’oubliez pas de déclarer les contraintes d’intégrité référentielle, en partant de l’icône Relations.
A ce sujet, voyez par exemple les manips faites avec Myogtha

Vous devriez arriver à un résultat qui ressemble à quelque chose comme ceci :

[emirov]

merci beaucoup ma base de données marche a la perfection !

c'est très gentil de m'avoir aidé je ne l'oublierais jamais.....



J'ai un autre petit souci:

-je voudrais faire une requete graphique ou je veux simuler la baisse du prix de vente (PUTCC_du_produit) de 15% je voudrais comment le faire en mode graphique(quoi mettre dans la case critére du champ( PUTTC_du_produit) ou en SQL.


merci beaucoup encore une fois

[fsmrel]

Bonsoir emirov,

C'est une bonne chose que votre base de données vous donne désormais satisfaction.

Concernant l'aspect graphique, je suis malheureusement totalement incompétent, aussi j'espère que quelqu'un d'autre prendra le relais pour vous aider dans la suite de vos aventures au pays d'Access...

Good luck!

[emirov]

merci beaucoup je vais ouvrir un autre topic je crois et celui la on pourra mettre resolu!

merci l'ami!

good luck!