0% ont trouvé ce document utile (0 vote)
11 vues5 pages

Analyse des Cardinalités et Requêtes SQL

Transféré par

hajar arioua
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOCX, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
11 vues5 pages

Analyse des Cardinalités et Requêtes SQL

Transféré par

hajar arioua
Copyright
© All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOCX, PDF, TXT ou lisez en ligne sur Scribd

Objectifs : - Justifier les cardinalités.

- Les requêtes SQL sous SGBD SQL.

L’analyse des données


Madame SETAG, secrétaire comptable, vous transmet, en annexe 1, un extrait du modèle entité association
qu'elle vient de concevoir pour la gestion des clients.

Travail à faire

1. Expliquez les cardinalités.

2. Complétez le tableau d'analyse des requêtes (annexe 2).

Annexes

Annexe 1

Annexe 2

Correction :
----------------------------------------------------
Question 1 :

Cardinalité Client - 0,N - Correspondre : A un client correspond 0 ou n factures.


Cardinalité Facture - 1,1 - Client : A une facture correspond un client et un seul.
Cardinalité Facture - 1,N - Comprendre : Une facture comprend 1 ou plusieurs produits.
Cardinalité Produit - 0,N - Comprendre : A un produit peut correspondre 0 ou n factures.

Question 2:
Exercice 1. Modèle conceptuel (5 points)

1. Concevoir un modèle adéquat en donnant la représentation graphique selon les conventions du modèle entité-
[Link] rappelle qu'un type d'entité est représente par un rectangle, un attribut par un cercle et un
type d'association par un losange. (2)

2. Décrire le domaine de chaque attribut (date, chaînes de caractères, nombre entier, ...) (1)

3. Matérialiser les clés des types d'entité en soulignant dans le graphe le nom du ou des attributs qui composent
ces clés ; (1)

4. Donner la cardinalité de chaque type d'association sous la forme habituelle d'un couple (minimum, maximum).
Justifier en quelques lignes les cardinalités de chaque type d'association. (1)

Exercice 2. Schéma relationnel (5 points)


Le but de l'exercice est de passer ce modèle conceptuel à un schéma relationnel

1. Réaliser le passage à un schéma relationnel en détaillant les étapes ;


2. Indiquer et justifier les clés.
Exercice 1. Modèle conceptuel (5 points)

2. Décrire le domaine de chaque attribut (date, chaînes de caractères, nombre entier, ...) (1)

Sauf précision les propriétés des attributs sont valeurs nulles non admises,
monovalué et atomique.
3. Matérialiser les clés des types d'entité en soulignant dans le graphe le nom du ou des attributs qui composent
ces clés ; (1)

4. Donner la cardinalité de chaque type d'association sous la forme habituelle d'un couple (minimum, maximum).
Justifier en quelques lignes les cardinalités de chaque type d'association. (1)

Exercice 2. Schéma relationnel (5 points)


1. Réaliser le passage à un schéma relationnel en détaillant les étapes ;

Étape 1 :

SALLES (NumS, NomSalle, NbPlaces, Surface)


MANIFESTATION (NumM, NomM, Type, Durée)
CLIENT (NumC, NomC, NomS, Tél, Adresse, PréC)

Étape 2 : Aucune

Étape 3 : Aucune

Étape 4 :

RESERVEPOUR (NumS, NumM)


BILLET (NumC, NumM, DateB, Type)

Étape 5 :

EQUIPEMENT (NumS, Equipement)


DATE (NumM, Date)

2 Indiquer et justifier les clés. (2)

• SALLES : NumS est clé car


NumS -> NbPlaces, Surfaces, NomSalles, Equipement est un DEF par définition de
l'attribut NumS

• MANIFESTATION : NumM est clé car


NumM -> NomM, Date, Type, Durée est une DFE par définition de l'attribut NumM
• CLIENT : NumC est clé car
NumC -> NomC, PréC, Adresse, Tél, NomS est une DFE par définition de l'attribut
NumC

• RESERVEPOUR : NumS, NumM est clé car


NumS, NumM -> ? est une DFE car on n'a pas

1. NumS -> NumM, plusieurs manifestations peuvent avoir lieu dans la même salle (à
des
dates différentes)
2. NumM -> NumS, une manifestation peut avoir lieu dans plusieurs salles

• BILLET : NumC, NumM est clé car


NumC, NumM ->DateB, Type est une DFE car on n'a pas
1. NumC -> NumM, DateB, Type, un client peut avoir des billets pour plusieurs
manifestations
2. NumM -> NumC, DateB, Type, des billets pour une manifestation peuvent être
vendus à
plusieurs clients

• EQUIPEMENT : NumS, Equipement est clé car


NumS, Equipement -> ? est une DFE car on n'a pas

1. NumS -> Equipement, une salle peut être équipée de plusieurs équipements,
2. Equipement -> NumS, un même type d'équipement peut se trouver dans plusieurs
salles

Vous aimerez peut-être aussi