Le développement des traitements informatiques nécessite la manipulation de données de plus en plus nombreuses. Leur organisation et leur stockage constituent un enjeu essentiel de performance. Le recours aux bases de données relationnelles est aujourd’hui une solution très répandue. Ces bases de données permettent d’organiser, de stocker, de mettre à jour et d’interroger des données structurées volumineuses utilisées simultanément par différents programmes ou différents utilisateurs. Cela est impossible avec les représentations tabulaires étudiées en classe de première. Des systèmes de gestion de bases de données (SGBD) de très grande taille (de l’ordre du pétaoctet) sont au centre de nombreux dispositifs de collecte, de stockage et de production d’informations. L’accès aux données d’une base de données relationnelle s’effectue grâce à des requêtes d’interrogation et de mise à jour qui peuvent par exemple être rédigées dans le langage SQL (Structured Query Language). Les traitements peuvent conjuguer le recours au langage SQL et à un langage de programmation. Il convient de sensibiliser les élèves à un usage critique et responsable des données.
Le père des bases de données relationnelles est Edgar Frank Codd. Chercheur chez IBM à la fin des années
1960, il étudiait alors de nouvelles méthodes pour gérer de grandes quantités de données, car les
modèles et les logiciels de l'époque
ne le satisfaisaient pas. Mathématicien de formation, il était persuadé qu'il pourrait utiliser des
branches spécifiques des mathématiques (la théorie des ensembles et la logique des prédicats du premier
ordre) pour résoudre des difficultés
telles que la redondance des données, l'intégrité des données ou l'indépendance de la structure de la
base de données avec sa mise en œuvre physique.
En 1970, il publia un article où il proposait de
stocker des données hétérogènes dans
des tables, permettant d'établir des relations entre elles. De nos jours, ce modèle est extrêmement
répandu, mais en 1970, cette idée était considérée comme une curiosité intellectuelle. On doutait que
les tables puissent être jamais gérées
de manière efficace par un ordinateur.
Ce scepticisme n'a cependant pas empêché Codd de poursuivre ses
recherches. Un premier prototype de Système de gestion de bases de données relationnelles (SGBDR) a été
construit dans les laboratoires
d'IBM.
Depuis les années 80, cette technologie a mûri et a été adoptée par l'industrie. En 1987, le
langage SQL, qui étend l'algèbre relationnelle, a été standardisé. C'est dans ce type de modèle que se
situe ce cours de base de données.
En
savoir plus
De nombreuses activités ont besoin de stocker des informations. Vous avez de nombreux exemples autour de vous : le lycée et son ENT, les clubs, les jeux en ligne que vous utilisez, etc. Les informations doivent être disponibles pour certains, protégées, modifiables, indépendantes d'un point de vue matériel et logiciel, etc.
Une base de données stocke des informations en rapport avec une activité.
Ces
informations peuvent être de natures très hétérogènes.
Les informations sont structurées et cette structure permet
d'insérer, de supprimer, de mettre à jour et d'interroger les informations contenues.
Un SGBD (système de gestion de base de données) est une interface entre l'utilisateur et les données.
Voici deux exemples de SGBG : MySql et Oracle.
Imaginez les situations développées dans les exemples ci-dessous :
Vous organisez un tournoi avec des joueurs. Les joueurs s'affrontent dans des duels. Vous voulez avoir des informations sur les joueurs, récupérer les scores, connaître les vainqueurs, etc.
Vous êtes cinéphile et vous voulez vous construire une base de données contenant des informations sur vos
films préférés : année de sortie, titre, genre, nom du réalisateur, etc.
Vous voulez également associer à
cette base des informations
sur les acteurs principaux.
Vous êtes passionné de séries et vous voulez construire une base de données qui contient des informations sur les hébergeurs, les séries, les acteurs et vos notations.
Imaginons le problème suivant : nous voulons construire une base de données contenant les élèves de seconde, première et de terminale pour les matières suivantes : physique, chimie, NSI, SNT, enseignement scientifique et mathématiques. Les élèves viennent de plusieurs lycées de l'académie. On veut stocker dans notre base de données des questions et/ou QCM.
On peut dans ce problème, s'intéresser à la phrase suivante : Galème GANBLAIN, élève de terminale F au lycée Saint-Exupéry, a passé le QCM intitulé "piles_files" dont les résultats sont stockés dans le fichier appelé "resultat_GANBLAIN.csv"
Cette phrase contient des informations qu'il va falloir structurer dans une base de données.
Pour concevoir une telle base de données, il va falloir respecter une démarche en étapes afin de définir les objets qui composent notre base de données ainsi que les relations entre ces objets.
La première approche de ces différents exemples serait une approche 'tableur'. Vous pouvez relire au passage le chapitre de première sur les tables : accès direct au chapitre table de première.
L'approche tableur pourrait être efficace sur un faible nombre de données mais notre base d'informations deviendrait vite instable ;
La modélisation de ces différents exemples se réalise en trois étapes principales qui correspondent à trois niveaux d'abstraction :
Dans la phase de conception nous pouvons réaliser un tableau qui recense les données issues de notre analyse. Ce tableau correspond à l'analyse du côté matière.
Concept/objet | Code/attribut | Description | type | Taille/domaine | Commentaire |
---|---|---|---|---|---|
Matière | idMatiere | Identifiant de la matière | Entier | La matière sera identifiée de manière unique par un nombre. Ce nombre sera appelé clé primaire. | |
Matière | nomMatiere | Nom de la matière | Texte | 30 caractères | Physique, chimie, SNT, NSI, mathématiques, SI et enseignement scientifique |
Niveau | idNiveau | Identifiant du niveau | Entier | Comme pour la matière, le niveau sera identifié par un nombre. | |
Niveau | nomNiveau | Nom du Niveau | Texte | 30 caractères | Seconde, première, terminale, BTS_1, BTS 2 |
Type de la question | idTypeQuestion | Identifiant du type de question | Entier | Le type de question sera identifié par un nombre. | |
Type de la question | nomTypeQuestion | Nom du type de question | Texte | 30 caractères | QCM, exercice |
Thème de la question | idTheme | Identifiant du thème | Entier | Le thème sera identifié par un nombre. | |
Thème de la question | nomTheme | Nom du thème | Texte | 30 caractères | Structure de données, ihm, algo... |
Description du thème de la question | desTheme | Description du thème | Texte | Texte qui décrit le thème |
Nous cherchons maintenant à décrire une question (exercice et/ou QCM). Pour écrire une question, il faut :
On traitera de manière particulière les champs niveau, matière et thème car ils existent déjà dans notre analyse. Il va falloir les relier à l'objet. Ce lien sera traité par un mécanisme que l'on appellera clé étrangère. Pour renseigner ces champs il suffira d'aller chercher les identifiants correspondants.
Concept/objet | Code/attribut | Description | type | Taille/domaine | Commentaire |
---|---|---|---|---|---|
Question | idQuestion | Identifiant de la Question | Entier | La Question sera identifiée de manière unique par un nombre. Ce nombre sera appelé clé primaire. | |
Question | idTypeQuestion | Identifiant du type de question | Entier | Ce nombre permet de relier le type de question à la question . Ce nombre sera appelé clé étrangère. | |
Question | idNiveau | Identifiant du Niveau | Entier | Ce nombre permet de relier le niveau à la question . Ce nombre sera appelé clé étrangère. | |
Question | idMatiere | Identifiant de la matière | Entier | Ce nombre permet de relier la matière à la question . Ce nombre sera appelé clé étrangère. | |
Question | idTheme | Identifiant du thème | Entier | Ce nombre permet de relier le thème à la question . Ce nombre sera appelé clé étrangère. | |
Question | Question | Question écrite en HTML | Texte | La question est écrite en langage HTML | |
Question | reponse | Réponse écrite en HTML | Texte | La réponse est écrite en langage HTML | |
Question | solution | La solution est une liste ou un tableau de vrai/faux |
Voici une représentation sous forme graphique de nos différents objets :
Indiquez sur le diagramme, ci-dessus, par une flèche les différents liens entre ces objets.
Faire l'analyse d'une base de données dans laquelle vous voulez stocker :
Le nom d'une série à regarder.
Le réalisateur de cette série (Nom, prénom).
La date de sortie de cette série.
Le nombre de saisons.
L'âge légal à partir duquel on peut visionner la série.
La plateforme qui héberge cette série (nom).
Un descriptif de la série (texte bref).
Questions :
Quels objets peut-on mettre en évidence pour cette base de données que l'on pourrait appeler series ?
Établir un tableau de vos données.
Représenter vos données à l'aide d'une représentation du type de l'exercice précédent.
Établir les liens entre vos données.
Vous pouvez vous aider de ce type de graphique :
Vous pouvez utiliser l'outil yEd qui possède une version live et une version à installer. Cet outil vous servira pour les graphes et les arbres.
Vous pouvez utiliser différents logiciels pour modéliser vos bases de données, en voici un libre et gratuit : Accès au logiciel gratuit looping.
Nous venons de mettre en évidence des objets et des relations entre ces objets. Il y a un certain nombre de notions à définir autour de ce concept de base de données relationnelles. Nous allons définir les notions de :
Attribut
Entité
Domaine
Identifiant/clé
Association
Une base de données relationnelle est la mise en action de toutes ces notions.
On appelle entité un objet unique qui peut être identifié distinctement par l'ensemble de ces attributs.
Dans la BDD "question", Matière ou Thème sont des entités.
Dans une BDD "élève du lycée", l'entité Élève est une entité.
Un attribut est une information élémentaire qui dépend de l'activité modélisée. Un attribut a un nom et une valeur typée.
idMatiere et nomMatiere sont des attributs de l'entité Matière.
La première est de type entier et la seconde de type chaîne de caractères.
Ainsi, l'attribut nomMatiere de type chaîne de caractères.
On appelle domaine d'un attribut l'ensemble des valeurs possibles que peut prendre un attribut.
Par exemple, le domaine de l'attribut nomMatiere est l'ensemble des chaînes de caractères : NSI, Maths, Français, Philo,....
De plus, le domaine de l'attribut idMatiere pourrait être les entiers de 20 à 40, celui de idThème les entiers de 41 à 100.
Autre exemple : le domaine de l'attribut DateNaissance d'un élève doit être l'ensemble des dates comprises entre deux valeurs choisies.
On appelle identifiant ou clé un attribut qui permet d'identifier de manière unique l'entité.
idMatiere est l'attribut correspondant au clé de l'entité Matière.
Autre exemple : idEleve est un nombre entier unique associé à chaque élève.
L'identifiant ou la clé sera appelée clé primaire quand on la considère dans la table qui lui est associée. idMatière est une clé primaire dans la table Matière alors qu'elle devient clé étrangère dans la table Question.
À quel concept (entité ou attribut ou identifiant/clé) pouvez-vous identifier une plaque immatriculation d'un véhicule ?
Une entité est souvent représentée sous la forme :
Nom |
---|
identifiant |
attribut |
attribut |
... |
Dans notre projet, on définit une entité Eleve (On prendra comme convention de ne pas utiliser les accents). Cette entité possède plusieurs attributs :
L'entité Eleve sera représentée de la manière suivante :
Eleve |
---|
IdEleve |
Nom |
Prenom |
Quelques conventions d'écriture pour les entités et les attributs.
Le nom d'une entité, d'une association, d'un attribut doit être unique. Par exemple, il faut écrire
comme attribut de l'entité Eleve
: nomEleve
au lieu de nom
.
Pour les identifiants
, il vaut mieux choisir un identifiant de type entier qui deviendra
une clé primaire
dans le schéma relationnel. Il vaut mieux éviter les identifiants de type
chaîne de caractères ou composés de
plusieurs attributs.
Un attribut ne peut en aucun cas être partagé par plusieurs type entité.
Ne pas utiliser d'accents, ni de caractères particuliers.
Ne pas utiliser de mots réservés au langage d'interrogation et de manipulation des données (nous utiliserons SQL).
Une fois qu'une entité est définie, les occurrences de cette entité sont appelées instances ou enregistrements ou tuples ou n-uplets.
Eleve
Une autre instance
Eleve
On représente souvent ces tuples dans un tableau.
IdELeve | Nom | Prenom |
---|---|---|
3 | Beau | Gosse |
2 | Enfaillite | Mélusine |
1 | Térèz | Pascual |
Les attributs sont les noms se trouvant dans l'en-tête, la première ligne d'un tel tableau.
Les tuples ou enregistrements correspondent aux lignes suivantes d'un tel tableau.
Définir l'entité lycee
. Quels sont ses attributs ? Penser à typer les attributs.
Définir l'entité Niveau
.
Une association
définit un lien entre deux entités. Une association possède un nom et
éventuellement des attributs qui la caractérisent.
Nom |
---|
attribut |
attribut |
... |
Dans notre projet, nous avons les entités Eleve
, Lycee
et Niveau
.
Nous pouvons définir l'association "scolariser".
En effet, un élève est scolarisé dans un établissement ainsi qu'un niveau. De plus, il a un numéro ou un nom de classe.
Cette association permet de relier les entités Eleve
, Lycee
et
Niveau
Cette association peut s'écrire :
Nom : scolariser
Attribut : nomClasse
Cette association est en lien avec les entités Eleve
, Lycee
et
Niveau
. Ce lien sera effectif lors du passage au modèle relationnel. On parlera alors de
clés étrangères.
Voici une représentation de nos entités et de notre association :
Établir les liens entre les entités et l'association scolariser.
Reprenez votre analyse de la base de données series.
Définir les entités avec leurs attributs
de la base de données series de l'exercice 2 à partir de vos
données.
Une base de données est un ensemble d'informations, souvent hétérogènes, qui sont structurées de telle sorte que l'insertion, la suppression et l'interrogation d'informations soient possibles.
Un Système de Gestion de Bases de Données (SGBD) est une interface entre un utilisateur et une base de données.
Une entité d'une base de données est un objet unique identifié par l'ensemble de ses attributs.
Un attribut est une information élémentaire liée à une entité portant un nom et une valeur typée.
Le domaine est l'ensemble des valeurs autorisées pour un attribut donné.
L'identifiant ou clef est un attribut permettant d'identifié de manière unique une entité.
Les enregistrements ou tuples sont les instances d'une entité.
Une association est une liaison entre deux entités. Elle possède un nom et éventuellement des attributs.
Il existe de nombreux schémas et différents types de modélisations qui ne sont pas toutes au programme de NSI.
Ce modèle est hors programme dans le cadre de NSI.
Une vidéo d'introduction au modèle relationnel
Dans le modèle relationnel, les entités et les associations sont transformés en tableaux. Ces tableaux sont
appelés relations
.
On appelle relation un tableau à deux dimensions dans lequel les attributs correspondent aux colonnes et les $n$-uplets aux lignes.
Dans cet exemple, nous avons accès à une base de données Films
qui est composée de plusieurs
entités et associations :
Une entité artiste
Une entité film
Une entité internaute
Une entité pays
Une association rôle
Une entité notation
Vision synthétique de la base de données :
Voici quelques exemples de relations.
La relation artiste
La relation rôle
La relation film
Dans la relation artiste ci-dessus :
Dans la relation film ci-dessus :
Dans l'association rôle ci-dessus :
Observer dans les trois tables les correspondances entre les identifiants.
Une clé primaire est un ensemble d'attributs dont les valeurs permettent de
distinguer les tuples les uns des autres.
Une clé primaire peut être simple ou composée (de plusieurs
attributs).
On utilise souvent un nombre entier (avec le préfixe id) pour prendre le rôle de clé primaire.
Dans la relation Eleve
, la clé primaire est l'attribut idEleve
,
attibut qui est bien de type entier.
Dans l'exemple sur la relation artiste :
Quel attribut est une clé primaire ?
Cette clé primaire est-elle simple ou composée ?
L'ensemble d'attributs (nom, prénom) peut-il être vu comme clé primaire pour cette relation ?
Une clé étrangère est un attribut qui est la clé primaire d'une autre relation. Elle est indiquée par (FK : "foreign key") ou précédée d'un #.
On retrouve les clés étrangères dans la transformation des associations en relations.
Reprenons notre exemple avec la base de données Eleve :
On s'intéresse à l'association scolariser
. Cette association a des liens vers :
eleve
par l'intermédiaire de idEle
lycee
par l'intermédiaire de idLycee
idEle
, idLycee
sont des clés étrangères
dans l'association scolariser
.
Quelle est la troisième clé étrangère de l'association scolariser
de l'exemple ci-dessus ?
Vers quelle entité établit-elle la
liaison ?
Un schéma relationnel d'une relation est la donnée pour cette relation :
d'un nom,
de l'ensemble des attributs en précisant leur domaine propre,
de (ou des) l'attribut servant de clé primaire et des attributs étant éventuellement des clés étrangères.
Un tel schéma relationnel peut être écrit sous la forme d'un tableau ou sous forme textuelle.
On peut transformer une entité en relation donnée par son schéma relationnel.
Les attributs de l’entité deviennent les attributs du schéma relationnel (de même nom que l’entité).
L’identifiant devient clé primaire.
Dans un schéma relationnel la clé primaire est mise en évidence soit avec l'indication CP (ou PK pour Primary Key), soit en étant soulignée, soit avec le dessin d'une clé, soit indiquée à l'aide d'une remarque.
On peut transformer en relation donnée par son
schéma relationnel, l'entitéEleve
.
Eleve |
---|
IdEleve |
Nom |
Prenom |
Eleve |
---|
(CP)IdEleve |
Nom |
Prenom |
On peut également retrouver une notation textuelle où la clé primaire est soulignée : Eleve(IdEleve, Nom, Prenom)
Dans un schéma relationnel, une clé étrangère est mise en évidence soit avec l'indication FK (pour Foreign Key), soit en étant précédée d'un #.
scolariser |
---|
nomClasse |
scolariser |
---|
(FK)idLycee |
(FK)idEleve |
(FK)idNiveau |
nomClasse |
En notation textuelle où les clés étrangères sont précédées d'un symbole # : scolariser(#idLycee, #idEleve, #idNiveau, nomClasse)
La relation scolariser étant une association ne possède pas de clé primaire.
Une base de données relationnelle est un ensemble de relations.
L'ensemble des schémas relationnels appelé schéma de la base de données.
Vous verrez parfois le mot relation utilisé à la place de schéma relationnel.
Vous cherchez à modéliser un annuaire téléphonique.
Établir le schéma de la base de données d'un tel
annuaire. Vous pouvez faire simple en écrivant une seule relation dans laquelle le numéro de téléphone
devient clé primaire. Vous pouvez également
compliquer un peu les choses en écrivant deux relations : une pour les personnes et une autre pour les
numéros. Il faudra dans ce cas utiliser une clé étrangère pour relier ces deux tables.
Établir le schéma relationnel de la base de données series travaillée depuis l'exercice 2.
Il existe un certain nombres de règles à respecter pour respecter l'intégrité d'une base de données. Ces règles visent à préserver la cohérence des données et garantir une stabilité de notre base dans le temps.
Il existe des catégories de contraintes d'intégrité à respecter :
L'existence et l'unicité des clés primaires : une clé primaire ne peut être vide et il ne peut y avoir de doublons dans une relation. Toute relation doit posséder une clé unique que l'on appelle clé primaire. Cela définit la contrainte d'entité (appelée aussi contrainte de relation).
Le problème typique est l'utilisation de l'attribut nomEle
dans notre entité Eleve
.
Cet attribut ne peut définir de manière unique un élève car plusieurs élèves peuvent avoir le même nom.
Nous ne pouvons donc pas utiliser
cet attribut comme clé primaire. Dans notre exemple nous avons utilisé un attribut idEle
.
Chaque élève est donc identifié par un numéro unique (unicité); de plus, chaque a nécessairement un tel numéro
d'identification (existence).
Les données que nous souhaitons stocker dans notre base de données ont des formats différents. On parle alors
de domaine
. On peut s'inspirer des types de données des langages de programmation que nous
avons étudiés (integer, booléens,
float, char, string).
Les contraintes de domaines doivent permettre de :
représenter les données sans perte d'information,
d'éviter les erreurs de saisies.
Tout attribut d'un n-uplet doit prendre une valeur appartenant à l'ensemble des valeurs possibles prédéfinies pour cet attribut : on parle de contrainte de domaine.
La relation Eleve(IdEleve, Nom, Prenom) a trois attributs :
L'attribut IdEleve est nécessairement un entier,
Les attributs Nom et Prenom sont nécessairement des chaînes de caractères.
Ainsi, le n-uplet (3, "Beau", "Gosse")
peut être un tuple de la relation Eleve.
Par contre, ("trois", "Go", "Boss")
ne peut pas être un tuple de la relation Eleve
car "trois" n'est pas un nombre entier.
On peut inventer ses propres domaines de données, mais souvent on utilise des domaines prédéfinis dans le logiciel d'implémentation de notre base.
Lorsque les contraintes de domaines deviennent sophistiquées, on parle alors de
contraintes utilisateurs
:
on veut qu'une donnée soit un élément d'une liste (liste des lycées par exemple),
on veut qu'une donnée numérique soit bornée (âge d'un personne),
on veut qu'une donnée possède un nombre de caractères défini à l'avance (code postal),
Les logiciels d'implémentation proposent des solutions à ce type de contraintes.
Nous utilisons les clés primaires afin de distinguer de manière unique nos entités. Ces clés primaires servent également de références dans les autres relations. Il faut veiller à ce que les références soient effectives. On ne peut pas définir une entité qui fait référence par une clé étrangère à une entité qui n'existe pas.
La valeur d'un attribut qui est une clé étrangère doit nécessairement faire référence à un n-uplet existant dans la relation dont cette clé étrangère est la clé primaire : on parle de contrainte de référence.
Reprenons notre relation scolariser
: scolariser(#idLycee, #idEleve,
#idNiveau, nomClasse)
Dans cette relation : idLycee, idEleve, idNiveau sont des clés étrangères. On ne peut scolariser que des
élèves connus dans des lycées connus sur des niveaux connus. Pour ajouter une nouvelle scolarisation d'un
élève fictif, il faudra que l'élève
soit existant, que son lycée soit existant et que sa classe soit connue. Il sera également impossible de
supprimer les entités Lycee
ou Eleve
On propose un tableau qui donne les occurrences d'une relation Joueur définie par le schéma relationnel : Joueur(IdJoueur,nomJoueur,pNomJoueur,dNaissanceJoueur)
IdJoueur | nomJoueur | pNomJoueur | dNaissanceJoueur |
---|---|---|---|
1 | Terez | Pascual | 124 |
1 | Gosse | 452 | |
4 | Terez | Pascual | 124 |
Repérez les anomalies dans ces occurrences. Quelles sont les contraintes non respectées et/ou à mettre en œuvre ?
Une relation est un tableau à deux dimmensions dans lequel les attributs sont les colonnes et les tuples ou enregistrements sont les lignes.
Une clef primaire est un ensemble d'attributs non vide qui permet d'identifier de manière unique une relation.
Une clef étrangère d'une relation est un attribut étant aussi la clé primaire d'une autre relation.
Un schéma relationnel d'une relation est un ensemble formé du nom de la relation, de ses attributs en précisant le domaine et les clef primaire et éventuellemnt étrangères.
Une clé primaire est reconnaissable soit par un soulignement, soit par une dessin de clé, soit par les lettres CP ou PK.
Une clé primaire peut être simple (définie par un seul attribut) ou composée (définie par un ensemble de plusieurs attributs)
Une clé étrangère est reconnaissable soit par le symbole #, soit par les lettres FK.
La contrainte d'entité ou contrainte de relation est le fait que toute relation doit avoir une clé primaire unique.
La contrainte de domaine est le fait que tout atttribut d'enregistrement doit prendre ses valeurs dans un ensemble de valeurs possibles précis.
La contrainte de référence est le fait que toute valeur de clé étrangère doit faire référence à un enregistrement existant dans la relation dont cette clef étrangère est la clef primaire.
Voici comment le logiciel phpMyadmin représente les bases de données :
Repérez les différentes entités et/ou associations.
Repérez les clés primaires et les clés étrangères de la relation question.
Repérez les domaines des différents attributs de cette relation question. En faisant l'analogie avec vos connaissances sur les langages de programmation, donnez les différents types.
En utilisant la représentation du logiciel :
Établir les schémas relationnels des entités et/ou associations présentées.
Vous pouvez réfléchir à une base de données qui donnera naissance à un mini-projet.
Une analyse du projet avec une brève description.
Un minimum de quatre entités.
Un minimum de deux associations.
Une restauratrice a mis en place un site Web pour gérer ses réservations en ligne. Chaque
client peut s’inscrire en saisissant ses identifiants. Une fois connecté, il peut effectuer une
réservation en renseignant le jour et l’heure. Il peut également commander son menu en ligne
et écrire un avis sur le restaurant.
Le gestionnaire du site Web a créé une base de données associée au site nommée restaurant
,
contenant les quatre relations du schéma relationnel ci-dessous :
Quelle est la clef primaire de la relation Plat
?
Cette clé primaire est-elle simple ou composée ?
Quel est le domaine de cette clef ?
Quelle est la clef primaire de la relation Commande
?
Cette clé primaire est-elle simple ou composée ?
L'attribut idClient
peut-il être la clé primaire de la relation Reservation
?
Pourquoi ?
Le couple passwd, nom
peut-il être la clé primaire de la relation Client
?
Pourquoi ?
La clef primaire de la relation Plat
est l'attribut souligné idPlat
.
Cette clé primaire est simple car elle est constituée d'un seul attribut.
Le domaine de l'attribut idPlat
est le type entier.
La clef primaire de la relation Commande
est le couple d'attributs soulignés
idPlat, idReservation
Cette clé primaire est composée car elle est constituée de plusieurs attributs.
L'attribut idClient
ne peut pas être la clé primaire de la relation Reservation
car cet attribut n'est pas différent pour chaque réservation : un même client peut effectuer plusieurs
réservations.
Le couple passwd, nom
ne peut pas être la clé primaire de la relation Client
car il ne permet pas d'identifier de manière unique un client. Deux clients différents peuvent porter
le même nom et avoir choisi par hasard le même mot de passe, quand bien même la probabilité de cela
soit très faible.
Une restauratrice a mis en place un site Web pour gérer ses réservations en ligne. Chaque
client peut s’inscrire en saisissant ses identifiants. Une fois connecté, il peut effectuer une
réservation en renseignant le jour et l’heure. Il peut également commander son menu en ligne
et écrire un avis sur le restaurant.
Le gestionnaire du site Web a créé une base de données associée au site nommée restaurant
,
contenant les quatre relations du schéma relationnel ci-dessous :
Quelles relations admettent des clefs étrangères ?
Quelle est la clef étrangère de la relation Reservation
?
Vers quelle relation cette étrangère établit-elle une liaison ?
Quel est le domaine de cette clef ?
Combien de clefs étrangères apparaissent dans la relation Commande
?
Les relations Reservation
et Commande
admettent des clefs étrangères, ce sont
les attributs matérialisés par le symbole #.
La clef étrangère de la relation Reservation
est l'attribut idClient
.
La clef étrangère idClient
établit une liaison vers la relation Client
.
Le domaine de la clef étrangère idClient
est une chaîne de caractères (d'après le type VARCHAR).
Deux clefs étrangères apparaissent dans la relation Commande
: idPlat
et
idReservation
.
Vous créez un jeu vidéo en ligne. Vous voulez gérer les comptes des joueurs avec une base de données.
Cette base de données contient plusieurs entités :
Une entité Joueur
qui contient le nom, le mot de passe, le statut du joueur et le héros
joué en ligne.
Une entité statut
qui permet de savoir si le joueur a un compte premium ou nom grâce à un
attribut de type booléen.
Une entité Heros
qui permet de savoir le type de héros choisi, son niveau d'expérience,
son nom choisi par le joueur.
Établir le schéma relationnel de cette base de données en précisant le type (INT, STRING ou BOOLEAN) de chaque attribut.
Cliquer pour afficher la solutionVoici le schéma relationnel de la base de données :
L'entité Joueur
est modélisée par la relation Joueur(idJoueur:INT,nomJoueur:STRING
,password:STRING,#idStatut:INT,#idHeros:INT).
L'entité Statut
est modélisée par la relation Statut(idStatut:INT,premium:BOOLEAN).
L'entité Heros
est modélisée par la relation Heros(idHeros:INT,typeHeros:STRING,
nivExpHeros:INT,nomHeros:STRING).
Vous avez créé un jeu en ligne et vous gérez le compte des joueurs inscrits par l'intermédiaire d'une base de données.
Suite à une tentative d'attaque informatique, votre base de données a peut-être été corrompue.
Pour le savoir vous étudiez des extraits des cinq relations définissant votre base de données :
Joueur(IdJoueur:INT,nomJoueur:STRING,pseudoJoueur:STRING,ageJoueur:INT,#idPersonnage:INT),
Personnage(IdPersonnage:INT,nomPersonnage:STRING,typePersonnage:STRING,experiencePersonnage:INT,#idArme:INT,#idVisuel:INT),
Arme(IdArme:INT,nomArme:STRING),
Visuel(IdVisuel:INT,#idGenre:INT,typeVisuel:STRING).
Genre(IdGenre:INT,nomGenre:STRING).
Voici :
un extrait de la relation Joueur qui représente les cinq premières lignes de la table ordonnée par ordre croissant des valeurs de l'attribut idJoueur :
un extrait de la relation Personnage qui représente les cinq premières lignes de la table ordonnée par ordre croissant des valeurs de l'attribut idPersonnage :
un extrait de la relation Arme qui représente les cinq premières lignes de la table ordonnée par ordre croissant des valeurs de l'attribut idArme :
un extrait de la relation Visuel qui représente les cinq premières lignes de la table ordonnée par ordre croissant des valeurs de l'attribut idVisuel :
la relation Genre :
Repérez-vous des anomalies dans ces tables ? Si oui, quelles contraintes ne sont pas respectées ?
Cliquer pour afficher la solutionÀ la deuxième ligne de la table Joueur manque la référence idPersonnage : la contrainte de référence n'est pas respectée.
À la troisième ligne de la table Joueur l'âge n'est pas de type entier : la contrainte de domaine n'est pas respectée.
À la quatrième ligne de la table Joueur la référence 4 de la clé étrangère idPersonnage correspond à aucune valeur de la clé primaire idPersonnage de la table Personnage (puique les n-uplets sont rangés dans l'ordre croissant des valeurs de idPersonnage) : la contrainte de reférence n'est pas respectée.
Les quatrième et cinquième ligne de la table Personnage sont identifiées par la même valeur de la clé primaire idPersonnage : la contrainte d'entité (ou de relation) n'est pas respectée.
Il existe des logiciels pour représenter les relations et les entités et les associations.
"test d'alignement"
Les différents
auteurs mettent l'ensemble du site à disposition selon les termes de la licence Creative
Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0
International