[MCD] Dépendances fonctionnelles

Bonsoir bbsebb,

Citation:

Envoyé par 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).