EXERCICE 1 RELATION, DEGRÉ, CARDINALITÉ
Comme le produit cartésien est une combinaison de tous les tuples des deux relations, le nombre de tuples sera le produit du nombre de tuples des deux relations. Tous les champs sont intégrés dans le résultat en une sorte de juxtaposition : le nombre de champs du produit cartésien est égal à la somme du nombre de champs des deux relations. Enfin, le produit cartésien est une opération symétrique ; le résultat sera le même pour les deux questions. La relation Garage possède 3 tuples de 7 champs et la relation Film possède 15 tuples de 2 champs. Le résultat est une relation qui possède 45 tuples et 9 champs. On peut également dire que le résultat est une table qui possède 45 lignes et 9 colonnes.
CLÉ D’UNE RELATION
Si l’on considère simplement le contenu de la relation, il n’y a pas de clé constituée par un seul champ. Il semble que la combinaison de deux champs, ‘Prix’ et ‘Nombre’ est une clé et que c’est la seule qui contient deux champs. On pourrait trouver des combinaisons avec trois champs qui fonctionnent : par exemple ‘Prix’ et ‘Format’ et ‘Couleur’. Ce serait alors une clé candidate, mais on choisit celle qui est la plus ‘atomique’ possible. On peut s’interroger en revanche sur le bien-fondé d’une clé constituée des deux champs ‘Prix’ et ‘Nombre’ si l’on considère leur sens dans le monde réel. Il semble évident que l’on puisse avoir deux films différents avec le même prix et le même nombre. Comment choisir la clé dans ce cas ? On ne peut donc en général pas choisir une clé sans tenir compte des dépendances fonctionnelles entre les champs. Même si les données présentes dans On considère deux relations. La première Garage est de degré 7 et de cardinalité 3. La seconde Film est de degré 2 et de cardinalité 15. Quels sont le degré et la cardinalité du produit cartésien de Garage par Film ? Quels sont le degré et la cardinalité du produit cartésien de Film par Garage ? Quelle est la clé de cette relation (voir figure 3.37) ? Film(Prix, Format, Type, Nombre) P Exercices 3 Chapitre la relation semblent confirmer qu’il s’agit bien d’une clé, il n’y a pas ici de dépendance entre les champs ‘Prix’ et ‘Nombre’. Sauf si le commanditaire de la base de données vous affirme le contraire pour son cas particulier. Sans faire une analyse exhaustive des dépendances entre tous les champs, il semble qu’il n’y a pas dans cette relation de « bons » candidats pour identifier un tuple. Une solution est d’ajouter un champ spécifique ; c’est ce que proposent la plupart des SGBD lorsque vous ne définissez pas de clé pour une relation.
EXERCICE 3 CONTRAINTES D’INTÉGRITÉ
Pour les champs de type numérique comme ‘Prix’ et ‘Nombre’, on peut proposer des limites d’appartenance à un intervalle. Le prix doit être compris entre 0 et 1 000, et le nombre entre 0 et 10 000. Pour les champs de type caractère comme ‘Format’ et ‘Couleur’, il semble que les valeurs puissent être incluses dans des ensembles énumérés. Le format peut être compris dans l’ensemble (3 :4,16 :9) et la couleur dans l’ensemble (‘Couleur’,’Noir/Blanc’) . Le contenu du champ ‘Numéro_Film’ peut être défini par rapport au contenu du champ correspondant dans la relation ‘catalogue’. Cela revient à imposer la contrainte suivante : on n’entre pas de numéro de films qui ne se trouveraient pas dans le catalogue. Dans tous les cas, ces valeurs sont à déterminer avec les usagers de la base de données.
EXERCICE 4 OPÉRATION ENSEMBLISTE
Pour réaliser ces opérations, il faut que les relations possèdent le même schéma. L’intersection entre deux ensembles peut se concevoir de la manière suivante en utilisant l’opéOn considère la relation Film(Prix, Format, Type, Nombre) de l’exemple précédent. Proposez des contraintes d’intégrité pour chaque champ. On suppose que l’on ajoute un champ ‘Numéro_Film’ qui correspond à son identifiant dans une relation descriptive qui est un catalogue de films. Que proposez-vous comme contrainte pour ce champ ? Exprimez l’intersection entre deux relations à partir des opérations d’union et de différence. Donnez-en une illustration avec ses deux relations (voir figure 3.38). ma_cuisine(Appareil, Couleur) Appareil Couleur Réfrigérateur rouge Robot mauve Cuisinière jaune sa_cuisine(Appareil, Couleur) Appareil Couleur Réfrigérateur mauve Cuisinière jaune Hotte bleue Figure 3.38 Relations ‘ma_cuisine’ et ‘sa_cuisine’. 84 Création de bases de données rateur de différence : ma_cuisine ∩ sa_cuisine = ma_cuisine – (ma_cuisine – sa_cuisine) [voir figure 3.39]. ma_cuisine – sa_cuisine ma_cuisine – (ma_cuisine – sa_cuisine) On obtient bien le résultat de l’intersection de ma_cuisine ∩ sa_cuisine. Vérifiez par la même méthode que sa_cuisine ∩ ma_cuisine peut s’écrire sa_cuisine – (sa_cuisine – ma_cuisine) et que l’opération est symétrique bien que l’opération de différence ne le soit pas.