La meilleure façon d’apprendre quelque chose est de pratiquer des exercices. Nous avons préparer ces exercices corrigés pour les personnes (débutantes ou intermédiaires) qui sont familières avec les dépendances fonctionnelles et normalisation des bases de données. Nous espérons que ces exercices vous aideront à améliorer vos compétences sur les Dépendances fonctionnelles et Normalisation. Les exercices corrigés suivantes sont actuellement disponibles, nous travaillons dur pour ajouter plus d’exercices. Bon apprentissage!
1. Lors de la normalisation d’une BD relationnelle, on peut toujours décomposer une relation afin d’obtenir des relations en BCNF. Cependant, une telle décomposition ne garantit pas la préservation de toutes les dépendances fonctionnelles.
A VRAI
B FAUX
A
Toute relation peut être décomposée en plusieurs relations respectant la BCNF. Cependant, la décomposition en BCNF peut entraîner la perte de certaines dépendances fonctionnelles. C’est pourquoi, dans certains cas, on préfère une décomposition en 3FN, qui permet notamment de préserver les dépendances fonctionnelles.
2. Dans un diagramme Entité-Association (ER), un ensemble d’entités faibles représente une collection d’entités pour lesquelles aucune clé n’a encore été découverte. Plus tard, au cours de la conception, cet ensemble pourra être transformé en un ensemble d’entités fortes en ajoutant les attributs nécessaires à la définition d’une clé.
A VRAI
B FAUX
B
Une entité faible n’est pas une entité dont la clé n’a pas encore été découverte. Elle possède généralement une clé partielle, mais celle-ci ne permet pas, à elle seule, d’identifier une occurrence de manière unique. Son identification complète dépend de la clé d’une entité forte (propriétaire) avec laquelle elle est associée.
3. Une relation peut posséder plusieurs clés candidates, mais une seule d’entre elles est choisie comme clé primaire.
A VRAI
B FAUX
A
Une clé candidate est un ensemble minimal d’attributs permettant d’identifier de manière unique chaque tuple d’une relation. Une relation peut donc avoir plusieurs clés candidates.
Parmi ces clés candidates, une seule est choisie comme clé primaire. Les autres sont appelées clés candidates alternatives (ou clés secondaires/uniques selon le contexte).
4. Si chaque attribut d’une table dépend fonctionnellement de la clé primaire, alors la table est nécessairement en 3FN.
A VRAI
B FAUX
B
Le fait que les attributs dépendent de la clé primaire ne suffit pas à garantir la 3FN. Il faut également vérifier l’absence de dépendances transitives entre les attributs non-clés. Par exemple:
NumEmploye → CodeService
CodeService → NomService
On a donc:
NumEmploye → CodeService → NomService
NomService dépend indirectement de la clé NumEmploye par l’intermédiaire de CodeService. Il existe donc une dépendance transitive, ce qui viole la 3FN.
5. Une relation composée de seulement deux attributs et dont chaque attribut est une valeur atomique est nécessairement en 1FN, 2FN, 3FN et BCNF.
A VRAI
B FAUX
A
Considérons une relation R(A, B). Si les valeurs sont atomiques, la relation respecte la 1FN.
Pour la 2FN, une dépendance partielle ne peut pas apparaître de manière problématique avec seulement deux attributs dans une relation.
Pour la 3FN, il ne peut pas exister une dépendance transitive impliquant un troisième attribut non-clé.
Pour la BCNF, toute dépendance fonctionnelle non triviale doit avoir un déterminant qui est une super-clé. Avec seulement deux attributs, toute dépendance fonctionnelle non triviale comme: A → B implique que A est une clé de la relation. De même pour B → A. La relation respecte donc la BCNF.
6. Une relation est en deuxième forme normale (2FN) si elle est en 1FN et si aucun attribut non-clé ne dépend fonctionnellement d’une partie propre (sous-ensemble strict) d’une clé candidate.
A VRAI
B FAUX
A
La 2FN vise à éliminer les dépendances fonctionnelles partielles. Lorsqu’une clé candidate est composée de plusieurs attributs, aucun attribut non-clé ne doit dépendre d’une partie seulement de cette clé. Exemple:
INSCRIPTION(Etudiant, Cours, NomEtudiant, Note)
avec:
(Etudiant, Cours) → Note
Etudiant → NomEtudiant
La clé candidate est: (Etudiant, Cours), mais: Etudiant → NomEtudiant
NomEtudiant dépend uniquement d’une partie de la clé (Etudiant, Cours).
Il existe donc une dépendance partielle et la relation n’est pas en 2FN.
7. Soient r(A, C) et s(A, D) deux relations quelconques. Les deux expressions d’algèbre relationnelle suivantes sont-elles équivalentes ?
A VRAI
B FAUX
A
Les deux expressions sont équivalentes si elles produisent exactement le même ensemble de tuples pour toutes les instances possibles de r et s. L’expression d’algèbre relationnelle ci-dessus représente une jointure entre les deux relations. Une jointure permet de combiner les tuples de deux relations en fonction d’une condition de correspondance.
8. Considérons le diagramme Entité-Association (ER) suivant:
Où A, B et C sont des entités.
Quelles conditions doivent être satisfaites pour représenter les trois ensembles d’entités A, B et C à l’aide d’une seule table relationnelle ?
Dans une relation de spécialisation/généralisation, A représente le supertype tandis que B et C représentent ses sous-types. Pour représenter les trois ensembles d’entités dans une seule table, les attributs communs et les attributs spécifiques aux sous-types doivent pouvoir être regroupés dans une même relation. Les attributs qui ne concernent pas un sous-type peuvent être laissés à NULL, et un attribut discriminant peut être utilisé pour indiquer le sous-type de chaque occurrence.
9. Considérons le schéma R = (A, B, C, D, E) avec les dépendances fonctionnelles suivantes:
A -> C
A, B -> D
C, D -> E
On décompose R en deux relations :
R1 = (A, B, C, D)
et
R2 = (A, D, E)
Montrer que cette décomposition est une décomposition sans perte d’information.
L’ensemble des attributs communs à R1 et R2 (A, D) est une clé pour R2. Preuve:
1. A → C Donnée
2. AD → CD Augmentation de (1)
3. CD → E Donnée
4. AD → E Transitivité de (2) et (3)
5. AD → ADE Réflexivité + (4)
Donc AD est une clé de R2.La décomposition R → R1, R2 est donc sans perte.
10. Supposons que nous définissions une base de données sur les clients d’une banque et les prêts qu’ils ont reçus de la banque. Pour chaque client, nous devons enregistrer des informations sur son nom, son adresse, son numéro de téléphone et l’entreprise pour laquelle il travaille. Pour chaque prêt, nous devons enregistrer le montant, le taux d’intérêt, la date de délivrance du prêt et la date à laquelle le prêt doit être remboursé.
10.1) Est-il préférable de représenter l’entreprise pour laquelle un client travaille comme un attribut du client ou comme une relation ? Justifiez brièvement votre réponse.
Il est préférable de représenter l’entreprise comme un attribut de CLIENT, si chaque client travaille pour une seule entreprise et si aucune information supplémentaire sur les entreprises n’est nécessaire. Dans ce cas, l’entreprise peut être enregistrée directement dans la table CLIENT. En revanche, si plusieurs clients travaillent pour la même entreprise ou si l’on souhaite stocker des informations supplémentaires sur chaque entreprise (nom, adresse, secteur d’activité, téléphone, etc.), il est préférable de créer une entité ENTREPRISE distincte et de la relier à CLIENT. Exemple: CLIENT(NumClient, Nom, Adresse, Telephone, Entreprise)
10.2) Quelle est la meilleure façon de représenter la relation entre le client et ses prêts ?
en définissant le prêt comme un attribut du client, ou
en définissant le prêt comme un ensemble d’entités distinct et en définissant un ensemble de relations entre lui et le client ?
Justifiez brièvement votre réponse.
Le prêt doit être représenté comme une entité distincte, reliée au client par une relation, car un même client peut contracter plusieurs prêts et chaque prêt possède ses propres informations, telles que le montant, le taux d’intérêt, la date de délivrance et la date de remboursement. Représenter le prêt comme un simple attribut du client ne permettrait pas de gérer correctement plusieurs prêts ni leurs informations spécifiques. Exemple de modélisation: