Discussion :

[bbsebb]

Bonjour,

j'ai l'énoncé suivant :

Lors de la mise à jour d'un logiciel de facturation les modifications suivantes ont été demandées. On veut mémoriser les informations suivantes sur les clients*:
• nom
• prénom
• adresse
• pays
• numéro de téléphone fixe
• numéro de téléphone portable
• adresse e-mail

De plus sur une remise on veut mémoriser les informations suivantes*:
• un libellé
• le numéro de la facture concernée
• un montant HT
• une description

Lors de l'expression des besoins les contraintes suivantes ont été exprimées*:
• le pays doit se situer en union européenne
• au moins 1 des 2 numéros de téléphone est obligatoire
• le nom, le prénom et l'adresse e-mail des clients sont obligatoires
• la description, le numéro de facture, le libellé et le montant de la remise sont obligatoires
• le montant de la remise ne doit pas dépasser 15% du montant de la facture

Pour la dépendance fonctionnelle du client, le corrigé est :
email -> nom, prenom ....

Serai-t-il pas plus judicieux d'avoir nom,prenom,email -> rue, code postal .... ?

Par principe, si cela n'est pas dans l'énoncé, peut on ajouter un attribut du style id_client ?

merci d'avance.

[fsmrel]

Bonsoir bbsebb,

j'ai l'énoncé suivant

Commencez par étudier les dépendances fonctionnelles dans leur contexte d’origine, c’est-à-dire celui de la théorie relationnelle, comme c’est décrit dans l’article Bases de données relationnelles et normalisation

Il faut commencer par maîtriser le concept de relvar (relation variable, en français variable relationnelle) et de tuple (même référence).

Ceci fait, passer aux dépendances fonctionnelles proprement dites.

Le déterminant d’une DF est un ensemble (au sens de la théorie des ensembles), les noms des éléments qui le composent sont donc notés entre accolades "{", "}". Ainsi, on n’écrit pas :

email -> nom, prenom

Mais

{email} → {nom, prenom}

Ou encore

{email} → {nom}

{email} → {prenom}

Avec les DF, la précision est de mise. Vous avez utilisé des points de suspension pour la DF de votre corrigé, sans doute pour signifier que les attributs autres que nom et prenom autres font l’objet de dépendants de {email}.

Si tel est le cas, n’hésitez pas à écrire :

DF01 = {email} → {nom}

DF02 = {email} → {prenom}

DF03 = {email} → {adresse}

DF04 = {email} → {pays}

DF05 = {email} → {noTelFixe}

DF06 = {email} → {noTelPortable}

Définissez de la même façon les DF concernant la relvar utilisée pour les remises.

A propos de la DF qui vous paraît judicieuse :

DF07 = {nom, prenom, email} → {rue, code postal}

Vous avez décomposé l’attribut adresse en rue et code postal, donc la DF DF03 donne lieu à :

DF08 = {email} → {rue, code postal}

C’est-à-dire que DF08 est un sous-ensemble de DF07. Mathématiquement parlant, il n’y a pas de problème. Maintenant, il apparaît que la relvar CLIENT a pour clé candidate {email}, vérifiant les contraintes d’unicité et d’irréductibilité de ce type de clé. Dans ces conditions, DF07 n’est qu’une surclé, car elle ne vérifie pas la contrainte d’irréductibilité : DF07 n’apporte rien, au contraire...

En revanche, la décomposition de l’adresse, avec notamment la mise en évidence du code postal, ne relève pas de la normalisation, mais de la modélisation. Cette mise en évidence du code postal étant courante, à vous de voir (attention, le type de données doit être utilisable quel que soit le pays dans l’UE, actuel ou à venir...).

Ajouter un attribut id_client est toujours possible, mais fournissez la liste des DF dans lesquelles il est impliqué (surtout dans la mesure où vous souhaiteriez qu’il fasse lui aussi l’objet d’une clé candidate).