COURS DE SGBD
iut de tarbes
Département SeRéCom
Pa t r i c k Fe r r é
A N N E E U N I V E R S I T A I R E 2 0 0 4 / 2 0 0 5
Introduction... 4
PREMIÈRE PARTIE: CONCEPTS DU MONDE DES BASES DE DONNÉES... 5
Chapitre 1: L'information mise en forme par et pour l'informatique... 5
Section 1 Modéliser pour utiliser l'information traitée par des machines...5
§1 Enumération des éléments constitutifs...5
Section 2 De l'information brute en entrée jusque une information traitée en sortie... 6
$1 Les différentes catégories d’informations...6
§ 2 La validation des informations... 7
Section 3 La structure des données... 8
Sous-section 1 La structuration des données au moyen de fichiers logiques...8
$1 La notion de fichier logique...8
§ 2 Définition du fichier logique...10
Sous-section 2 La structuration des données au moyen de modèles conceptuels... 13
$1 Le modèle "entité / Association"... 13
§2 Introduction au modèle relationnel... 15
Chapitre 2 De l'organisation des données aux Bases de Données...17
Section 1 Quelques piste pour une définition avancée des Bases de Données (BD)... 18
$1) Les résultats escomptés d'une Base de Données... 18
A) Stocker de manière organisée... 18
B) Accéder au données... 18
C) Proposer une interface d'accès aux données... 18
$2 Un SGBD est organisé en couches... 18
A) Les couches internes...18
B) Les couches externes... 18
C) Bref Historique... 19
$3 Définition qui en résulte... 19
$4 Un Système de Gestion de Bases de Données est un logiciel...19
A). D'organiser, mémoriser et retrouver des données dans une base...19
B). permet de modéliser pour mieux gérer les données d'une entreprise. ...19
C). Garantir l'intégrité et la sécurités des données...20
$5 Structure et composants d'un environnement base de données...20
Section 2 Les Bases de Données Relationnelles (BDR)... 20
$1 Le modèle Relationnel de Données... 20
$2 La structure des données: des Tables et des Colonnes... 21
$3 Le problème de la valeurs NULL... 22
$4 Les Opérateurs Relationnels... 23
$5 Les opérateurs spécifiques...23
B) La restriction...23
$6 Les opérateurs classiques sur les ensembles...25
$7 Fondements de SQL...25
Section 3 Les règles d'intégrité du modèle...25
$1 La Notion de Clé...25
$2 Les deux règles d'intégrité du modèle relationnel...26
$3 Les règles de mises à jours associées...27
DEUXIÈME PARTIE: INTRODUCTION AUX OUTILS LOGICIELS DES BASES DE DONNÉES... 28
Chapitre 1 - les SGBD associés aux outils de Bureautique...28
Section 1 Les caractéristique principales des SGBD sont présents... 28
$1 Eléments de base d'Access...28
Section 2 Exemple illustrés de l'utilisation d'un SGBD comme Access...28
$1 Les étapes de création d’un BD avec Access... 29
$2 Travail réalisable en quelques clics de souris...31
Section 2 Les limites de cet outil Bureautique...33
Chapitre 2 Les SGDR basés sur SQL... 34
Section 1 : Exemple de travail (un SGBD de gestion des stages)...34
$1 Base de données StagesTD sur le serveur skatehouse.Maison... 34
$ 2 Requêtes et interface avec le « couple » d’outils MySql et php... 36
Section 2 : Objectif poursuivi... 36
Section 3 Le modèle « solution »... 37
Introduction
On admet que l’information, pour être comprise, pour faire sens, doit être décomposée en éléments basiques qui une fois réunis sont susceptibles de former de l’information. Ces éléments structurés, sous forme de relations, forment en fait des données. C'est l'utilisateur qui jugera du fait que ces données participent au fait de l'informer ou pas. Aussi si l'on peut donc douter que l'informatique produise de l'information, l'on admet que les technologies de l'information, permettent de stocker et de traiter des données organisées que l'on peut interroger !
Dans ce contexte, étudier les SGBD consiste à tenter de comprendre comment des réalités telles "un étudiant", un "cours", peuvent être représentées et constituer une base de donnée exploitable. Il convient pour aboutir à ce résultat de modéliser les réalités que sont un "étudiant", un "cours" et l'ensemble des relations entre ces "entités" initiales.
Comment modéliser de telles réalités? Et dans le but d'utiliser ces données, comment interroger ces bases de données? Telles sont les deux questions qui sont abordées lorsque l'on étudie les concepts qui régissent les bases de données!
L'on recourt pour se faire à des théories ensemblistes (issues des mathématiques). A défaut de fonctions strictes, les ingrédients des bases de données sont constitués de représentations graphiques et de langages de requêtes permettant l'accès à ces bases données. Ces dernières fournissent en retour un résultat correspondant à la demande. Soit, ce qui est l'objet de notre travail ici: Comprendre le
"comment ça marche", tout en saisissant l'utilité des bases de données. Telle est l'ambition de ce polycopié.
Ayant parcouru les aspects théoriques dans une première partie, l'on étudiera alors les outils logiciels qui permettent de vérifier la validité des concepts et des modèles. Ce sont les SGBD: Rien d'autre que des logiciels. Ce alors que nous ne pourrons qu'introduire à ce second objectif. En notant cependant que les outils logiciels sont assistés, et que ce travail est moins délicat que les modélisations qui en sont un préalable. Dit autrement, c'est la maîtrise conceptuelle qui est importante.
Enfin, pour mesurer l'importance sociale prise par les bases de données, il suffit de constater à quel point celles-ci sont présentes, souvent à notre issue. Ce jusqu'à toucher à notre vie quotidienne, à tout instant. Se lever le matin et passer un coup de téléphone et déjà s'active une myriade de computers.
Qui tout à la fois, débitent le crédit du numéro appelant, activent une série de contrôles qui transitent par les réseaux, pour finalement générer les lignes des factures téléphoniques; jusque même imprimer l'enveloppe qui contiendra la facture téléphonique.
N'est-ce pas qui suffit pour dire la prégnance des données organisées, interrogeables, et à même de constituer des données traitées. Des factures, la paye des salariés, etc., les paiements par débit d'un compte bancaire etc. Que dire alors si le second acte de nos journées tranquilles consiste dans le retrait d'espèces monétaires à un automate bancaire? L'immixtion du "traitement de données automatisées" dans notre vie de chaque jour est si forte que nous ne pouvons plus sérieusement envisager un traitement humain «
à la main » de la gestion de ces activités sociales. C'est l'efficacité et la puissance des bases de données, qui permet ce traitement automatisé de l'information.
Première partie: Concepts du monde des Bases de Données.
Chapitre 1: L'information mise en forme par et pour l'informatique.
Section 1 Modéliser pour utiliser l'information traitée par des machines.
L'on recourt à des modèles pour formaliser l'information, ou dit autrement pour lui donner une organisation adaptée au fait d’exploiter les données. Cette information et ces données nous renseignent, nous informent et nous permettent de décider. On doit noter alors, en introduction approximative que les "modélisations" que nous étudierons mettent en avant deux éléments qui constituent les composantes essentielles de l’information.
§1 Enumération des éléments constitutifs A) L’individu ou entité.
Cet individu, ou cette entité est « l'ingrédient » de base de l'information qui intéresse les Systèmes d'Information lorsqu’il s’agit d’encapsuler des « informations » dans des machines activées par des programmes. Ce sera dont la représentation d'un objet réel, d'un concept, d'un phénomène. La pomme, le fruit; est ainsi une entité (ou individu). Le client, la commande passée à une entreprise sont des entités. Soit des conteneurs qui englobent le "nécessaire" pour constituer une représentation qui informe. Pourtant l'entité ne suffit pas à elle seule à constituer une information. Si nous prenons l’exemple d’un client, aucune information n’existe encore. L'entité, est une abstraction, le client ainsi formalisé n'est qu'un "moule" qui donne une idée générale. On s'interroge alors pour savoir: Quelles caractéristiques possèdent un client? De quel client est-il question? Quelle est son adresse? Nous n’en savons rien tant que n’a pas été introduit la notions de "propriétés" ou "attributs" de l’entité client. C'est le second élément constitutif nécessaire.
B) Les propriétés ou attributs de l’entité.
Ce sont les caractéristiques de l’individu (entité) qui permettent de le décrire. Dans le cas du client (entité), son nom, son adresse, son solde sont des propriétés qui permettent une relative mais suffisante connaissance d’un client donné. Ainsi, dans un premier temps sont énumérées les propriétés types de l’entité. Notons cependant que les propriétés types ne nous renseignent que sur "l'ossature générale" de l’entité. C’est encore une abstraction. A l’aide des propriétés types, il est encore impossible de connaître un seul client réel de l’entreprise. Nous avons donc.
Fig. 1.
Pouvons nous envoyer une facture à un tel client? En l’état la chose n’est pas possible. Il est nécessaire avant de tenter une telle opération de donner des valeurs aux propriétés. Ce sont
Entité : Client Nom
Prénom Adresse Solde
Enumération des propriétés
ces dernières qui vont individualiser un client réel là où n’existe qu’un conteneur valable pour tous les clients. Le client, à ce point du développement n'est qu'une entité générique. C'est une abstraction, un point de départ très utile à l’initiation aux Bases de Données.
C) Le complément de la propriété: la valeur.
Chaque propriété (ou attribut) de l’entité prend une valeur afin de constituer une information utilisable. Ainsi la propriété "nom" de l’entité client peut prendre la valeur Durant, ou Dupond et permet enfin de savoir de quel client réel il est question. Les autres propriétés doivent, elles aussi, avoir une valeur.
Fig. 2.
Relevons alors que l'une des propriétés a un rôle très important à savoir l’identifiant, souligné en général. Il doit être unique et en conséquence ne pas être commun à plusieurs individus.
L'identifiant ne sera donc pas le nom, puisque deux ou plus individus peuvent avoir le même nom.
Section 2 De l'information brute en entrée jusque une information traitée en sortie.
Lorsqu’un minimum de connaissances est acquis relatif aux aspects sémantiques et à la syntaxe de l’information formatée, il reste à situer cette dernière relativement aux traitements effectués par des computers. On distingue les informations et les traitements dont elles sont l'objet, selon leur position dans la succession d’étapes permettant d’aboutir à une information utilisable.
$1 Les différentes catégories d’informations.
A) Les informations élémentaires ou "entrées".
Ce sont elles qui dans un système alimentent les données nécessaires aux différents traitements. Ces données sont issues d’un événement interne ou externe à l’organisation. Elles déclenchent les traitements prévus par le système. Ainsi la commande de M. ou Mm x constitue une donnée élémentaire ou une entrée. Cette commande sera le fait déclencheur des traitements classiques d’une livraison, d'une facturation, d'une imputation comptable, etc. à destination des différentes stations de l’organisation et ce faisant des agents de l'organisation.
B) Les informations résultantes ou "sorties".
Ce sont les informations après traitement. Les informations élémentaires déclenchent une série d’opérations considérées utiles et programmées. Au terme de ces traitements (calculs, opérations logiques, tris, sélections, décisions diverses) des informations de sorties sont générées. Ces différentes informations composent des factures, des bons de livraisons. Elles pourront être constituées des imputations d’écritures comptables dans les livres. Toutes ces
Entité: Client ID : 125
Nom (Dupond) Adresse (Rue Pi) Solde (1OOO)
Propriétés valorisées
sorties constituent les résultats, sous formes de documents ou de fichiers, utilisés par les services des organisations.
C) Les informations de commande ou "instructions".
Sans une série d’instructions ou commandes, les informations d’entrées ne peuvent à elles seules générer les informations de sortie utilisables. C’est donc une suite d’opérations qui transforme les informations d’entrées en informations de sorties. Le processus peut être représenté de la manière suivante.
Fig. 17
§ 2 La validation des informations.
Les traitements réalisés peuvent ne pas donner les résultats attendus, pour différentes raisons.
Cet état de fait nécessite d'introduire dans le système des techniques de validations. Parfois automatisées elles avertissent alors l'opérateur, qui doit renseigner un champ non saisi. Elles sont de plus basées sur le concept de feedback.
B) Distinction des informations calculées et des informations non calculées
La distinction est assez simple. Les informations résultantes non modifiées après un traitement sont "non calculées". Elles ont la même valeur que les informations élémentaires d’entrées dont elles sont issues. A l’inverse les informations résultantes modifiées son qualifiées de "calculées".
Traitement Info
Elémentair e
Info de sortie
Info de commande (instructions algorithmes)
Elles devront avoir la même valeur. L’ensemble du procédé peut être représenté comme dans le schéma de la figure 18.
Section 3 La structure des données.
L’information est devenue une "donnée". Les deux termes pouvaient être considérés comme équivalents. En tout cas d'un point de vue technique, l’information en général se transforme en données codées susceptibles d’être manipulées par une machine. Une fois cette
"manipulation" réalisée le résultat pourra être une information s’il est porteur de sens pour l'agent utilisateur, humain ou machine.
En fait la notion de données est plus adaptée aux domaines de l’informatique qui traite de
"fichiers logiques" et de "modèles conceptuels" qui mettent en forme l'information. On comprendra par là que l’étude de l’information n’est pas envisagée du point de vue de la linguistique, (voir cours de SI en deuxième année). Il est nécessaire d’étudier la structure des données ou l'organisation formelle, sans laquelle la "stupidité" des puces de silicium ne peut être gérée : pas plus, mais pas moins.
C’est aussi parce que les outils informatiques manipulent une logique particulière (algorithmique) qu’il est nécessaire de "structurer les données" et l’accès à ces dernières. Or ces outils, aussi puissants qu'ils soient ne peuvent comprendre un ordre du type "passe-moi cette chose". Mais ces outils calculent très vite. On aura compris que c'est ce qu'on leur demande!
Sous-section 1 La structuration des données au moyen de fichiers logiques.
$1 La notion de fichier logique
Une technique efficace de structuration des données est le fichier logique. Dés qu’il est nécessaire de structurer des réalités plus complexes l’on va recourir à des techniques plus affinées celles des "modèles conceptuels de données". Nous obtenons donc un fichier logique en réunissant deux éléments, la rubrique et l’article.
Informatio n Résultantes
Non Calculés
Calculée Décomposition Information
entrée Elémentaire
Sens de validation Fig. 18
A) La rubrique, le plus petit lot d’information possible.
C’est une propriété d’une entité. Le nom par exemple de l’entité client est une rubrique au sens des fichiers logiques. C’est en effet la donnée la plus élémentaire. Où chacune des rubriques est définie par un couple, le nom de la rubrique, et son domaine de définition.
1er) Le nom de la rubrique et son domaine de définition.
S'agissant par exemple de l'entité client, le code postal de ce dernier constitue le nom de la rubrique. Quelle étendue a le domaine de définition? Ou, autrement dit, quelle valeur pourra avoir cette rubrique? Dans le cas du code postal c’est l’ensemble des codes postaux existants.
L'on pose que l’ensemble des valeurs possibles constitue le domaine de définition. Dans des cas plus simples, telle la qualification des salariés. Si l’entreprise emploie quatre types de salariés - secrétaire, ouvrier, technicien, ingénieur -, l’ensemble de ces quatre valeurs constitue le domaine de définition de la rubrique qualification. On obtient, en conséquence, la formulation suivante :
Nom de la rubrique = qualification professionnelle
Domaine de définition = secrétaire, ouvrier, technicien, ingénieur 2er) L’occurrence ou valeur d’une rubrique.
Une valeur est donnée à chaque rubrique. A ce stade nous n’obtenons certes qu’un lot de données restreint. Pour aboutir à un fichier logique utilisable il est nécessaire de réunir les différentes rubriques susceptibles de constituer un ensemble de données plus significatif.
C’est l’article du fichier logique qui donne ce résultat.
B) L’article ou ensemble de rubriques représentant un individu.
L’article est la réunion des différentes rubriques. La notion de rubrique est très proche de celle, vue précédemment, sous le vocable de "propriétés d’une entité". C’est que comme il a été dit nous sommes passé d’une étude générale de la notion d’information à celle plus exploitable de donnée. Si l’on veut approfondir le concept l’on peut distinguer plusieurs niveaux de la structure. Une structure simple, et plus avant une structure hiérarchisée.
1er) Structure simple de fichier logique.
L’article est représenté par une structure simple lorsque toutes les rubriques sont positionnées au même niveau, ou dit autrement dans le même fichier. Ainsi le fichier logique client représenté sous la forme d’une structure simple est le suivant.
Fig. 19 2er) Structure hiérarchisée d’un fichier logique:
Si la structure simple du fichier logique est suffisante à une connaissance pour la gestion de l’entité client - ou du fichier logique client -, ce n'est que relativement à ce que l'on demande à cette formalisation de départ. Le client, pris en exemple, peut être localisé par son identifiant
Client ID (Valeur) Nom (Valeur) Adresse (Valeur) Solde (Valeur)
qui doit être unique, son nom, son adresse, son solde. Cela permet une connaissance suffisante du clients. La structure simple peut toutefois être "développée" pour obtenir une structure plus complexe. L’on considère alors certains articles du fichier logique initial comme des articles qui peuvent posséder leurs rubriques propres. C’est donc un affinement de la représentation. La structure simple devient la suivante lorsqu’elle est représentée sous la forme d’une structure hiérarchisée.
Fig. 20
Le résultat est beaucoup plus détaillé. Il permet en effet une gestion du client pour ce qui relève de son "identification". Ce faisant, un fichier logique "identification" suffit pour le courrier que l’entreprise doit lui envoyer. Le fichier logique Commandes, permettra la gestion des commandes pour tout ce qui relèvera de la facturation. La structure hiérarchique peut être détaillée encore plus en profondeur en transformant le solde (rubrique) en un fichier. Ce nouveau niveau permet une gestion plus fine du calcul: total débit, total crédit, aboutissant au solde. L’affinement de ce type de structure hiérarchisée est très employé dans le domaine des bases de données. Les rubriques des fichiers sont alors mises en relation par le biais de liens.
§ 2 Définition du fichier logique
La notion de fichier logique est déjà une bonne approche du concept. Il ne s’agit cependant que d’une description des composants élémentaires du fichier. Elle doit être complétée par une définition plus large et par une classification des fichiers logiques.
A) Définition au sens strict du fichier logique
1er) Un ensemble homogène d’articles ou de rubriques.
Un fichier logique décrit donc l’architecture d’une entité qui peut être définie ainsi: Un fichier logique est un ensemble homogène d’articles de même nature. Par exemple le fichier "client"
aura les rubriques qui lui sont particulières, qui décrivent ce qu’est un client. Soit ce qui le Client
ID
Identité (Valeur) Commandes (Valeur) Solde (Valeur)
Identification
ID
Nom (Valeur) Prénom (Valeur) Adresse (Valeur)
Commandes
ID
Quantité (Valeur) Prix Unit. (Valeur) Prix TTC (Valeur)
Solde
ID
Identité (Valeur) Commandes (Valeur) Solde (Valeur)
définit à nos yeux: Le client a un nom, un prénom, une adresse, un solde. Ces particularités ne seront pas celle du fichier Produit par exemple qui se définit par un nom de produit, par son prix.
2er) Conditions nécessaires à l’utilisation d’un fichier logique.
Deux conditions sont à réunir pour l'utilisation du fichier logique. La première consiste dans le fait que tous les articles du fichier logique doivent contenir les mêmes rubriques. La deuxième réside dans le fait qu’il doit toujours être possible d’identifier un article dans un fichier sans ambiguïté possible. Cette rubrique particulière est appelée "l'identifiant" (ID), et doit être unique. Ainsi le n° INSEE constitue un identifiant efficace dans le cas des fichiers salariés. Lorsque aucun identifiant n’est a priori isolable parmi un ensemble d’individu, l’on affectera un code numérique ou alphanumérique en fixant les règles de calcul afin que cet identifiant soit unique (par exemple chaque création d’une fiche nouvelle générera le code du client en ajoutant 1 au code numérique du précédent client ajouté au fichier. Il est alors impossible que deux clients aient le même code.
3er) Exemple général de représentation.
ID Nom Adresse Banque Débit Crédit Solde
100 Dupond Rue Pi BNP 1000 800 200
101 Olive Rue A CA 3000 3000 0
102 Durant Av… BNP 5000 2000 3000
Article (ou tuple) Fig. 21 B) Classifications des fichiers logiques.
Deux catégories de fichiers logiques sont à distinguer: Les fichiers permanents, et les fichiers temporaires. La combinaison de ces deux catégories présente des intérêts pratiques importants.
1er) Les fichiers permanents.
Il est difficile d’affirmer l’existence d’un fichier réellement permanent, un tel état qu’aurait un fichier rendrait l’information pour le moins très figée, elle ne devrait jamais changer. La définition des fichiers permanents est donc plus souple que le qualificatif de permanent, au sens courant du terme. Un fichier sera qualifié de permanent lorsqu’il réunira les éléments d’une stabilité suffisante dans le temps. De tels fichiers sont par exemple celui des clients, ou le ficher salarié d’une entreprise. La notion est en fait très proche de celle de fichier archive.
Ainsi toutes données organisées sous forme d’un fichier et qui est destinée à être utilisée plus tard, au fur et à mesure des besoins est un fichier archive, donc permanent. Il est caractérisé par une stabilité suffisante.
2er) Les fichiers mouvements:
La stabilité dans le temps des entités est quasi nulle dans le cas de cette catégorie de fichier.
La différence réside dans le fait qu’ils contiennent des informations non réutilisables. Leur durée de vie dans les systèmes sera donc limitée. Dans de nombreux cas les fichiers mouvements vont être utiles à des traitements effectués par lot, en série. Dans ce cas le fichier
regroupe des données, propres à une période, utilisés en un seul passage de traitement automatisé. L’exemple classique est le cas d’un fichier de commande de la journée. Est-il utile de conserver un tel fichier? Quels intérêts auront les commandes d’un jour le jour suivant?
Aucun et c’est pour cette raison qu'une fois les traitements nécessaires à la facturation réalisés, les fichiers mouvements sont détruits. Ne sont conservés que les résultats des traitements. Les factures par exemple sont conservées alors que le fichier des commandes de chaque jour sera remis à zéro.
Le cas des fichiers dit de liaisons est caractéristique de cette notion de fichiers mouvements.
Ces derniers regroupent les résultats d’un premier traitement et servent à un second traitement. Au terme de ce second lot d’opérations ces fichiers sont effacés. A la vitesse ou travaille les processeurs, certains fichiers mouvements peuvent avoir une durée de vie qui se réduit à quelques secondes, et souvent moins.
Exemple: Les données d’un traitement aboutissant à une facture permettent l’obtention de cette dernière. L’on conserve un court temps ce type de fichier mouvement qui contient des informations utiles à la suite des opérations comptables. Une fois les données comptables imputées, le fichier de liaison entre client et comptabilité peut être effacé. Voir concernant la logique générale de la combinaison des fichiers permanents et des fichiers mouvements la figure suivante.
Fig. 22 Fichier
Mouvement (Autres
Traitements) Document
s Utiles de Saisie
Fichier mouvement
Fichier Permanent TRAITEMENTS
Evénement (Commande)
Sous-section 2 La structuration des données au moyen de modèles conceptuels.
$1 Le modèle "entité / Association"
Le fichier logique constitue un outil de représentation déjà très puissant. La plus grande partie de l'informatique existante est basée sur cette notion. Dans un développement de type hiérarchique, les fichiers logiques permettent une description plus étendue encore d’une entité.
Que vaut cependant cette description pourtant détaillée si l’on désire décrire les relations nécessaires à une application informatique? Si par exemple l’on désire modéliser une opération comme celle de la facturation dans une organisation, la connaissance même très détaillée à l’aide des fichiers logiques est insuffisante. On a certes, des fichiers: Clients, produits, commandes mais ces fichiers sont isolés les uns des autres. Nous ne savons pas encore comment va être gérée la relation nécessaire entre eux!.
La représentation s'enrichit à l’aide de modèles conceptuels des données et des traitements.
Ceux-ci incluent des fichiers en relations en fonctions de critères fonctionnels. Parmi plusieurs types d’outils de modélisation nous retiendrons "le modèle entité / association", et le
"modèle relationnel". La plus intéressante modélisation résidant dans les modèles à "Objet", qui ne seront malgré leurs intérêts abordés qu'à titre indicatif dans cette partie du cours. Nous aborderons cependant, dans le cadre de la seconde partie les intérêts de cette dernière modélisation.
A) Présentation générale du modèle entité / association.
Ce modèle exige que soit mise en œuvre une entité fort similaire au fichier logique et une association qui traduit le rapport existant entre les entités.
1er) L’entité ou individu.
Très proche de la notion de fichier logique, les propriétés d’une entité obéissent aux même règles. La précision dans la représentation de l’entité dépend des choix retenus pour décrire les entités en relation. Graphiquement, l’entité sera représentée par un rectangle ou apparaît le nom de l’entité, et ses propriétés, dont la première sera l’identifiant.
2er) Exemple d’association type.
L’association traduit le rapport entre les entités. Graphiquement l’association est représentée par un ovale placé sur une ligne reliant les entités. Un verbe renseigne sur l'action la relation qui matérialise. Un enseignant par exemple dispense des cours.
3er) Exemple graphique.
Fig. 23 Enseigne r
Cours ID Libellé
Heure
Enseignant ID Nom Discipline
1,n 1,n
4er) Les caractéristiques d’une association:
Deux particularités sont attachées à l’association. La première consiste dans la dimension de l’association. Dans le cas de notre exemple, le cours "enseigné par" un professeur est une association de dimension 2, le nombre d’entités de l’association est de 2 (le cours, et l’enseignant). C’est dire que deux entités sont concernées par l’association "enseigner".
La seconde caractéristique réside dans la cardinalité d’une association. A savoir le nombre de fois ou chaque occurrence d’une entité donnée est impliqué dans une occurrence(1) de l’association type. Concrètement Dans notre schéma (Fig. 23), l’enseignant assure au moins 1 cours, mais peut en assurer plusieurs. La cardinalité minimum est donc de 1 la cardinalité maximum lorsqu’elle est inconnue est notée "n". La convention d’écriture est donc: 1,n.
Parfois est rajouté la valeur moyenne prévisible. L’on a alors l’écriture suivante: 0,n,5 pour une valeur 0 de la cardinalité minimum, n, pour la valeur maximum de la cardinalité.
La valeur moyenne constatée est égale à 5, dans cet exemple. Ainsi doit-on préciser au moins la cardinalité minimum et la cardinalité maximum.
B) Exemple d’un cas "complexe".
Sans développer réellement l’étude préalable à l’écriture d’un programme. La situation suivante permettra de constater la force de représentation du réel qui peut être obtenue à partir d’un modèle structurant les données. Ce travail pourrait être un point de départ de modélisation d’un traitement de gestion des fournisseurs, des commandes et du stockage des produits livrés dans une entreprise.
On a donc, au début d’un tel travail les entités suivantes: Produit (Code, désignation, prix, unité de commande...), Fournisseur (Code, nom, adresse...), Commande (N°, date, quantité),
1 La notion d'occurrence est synonyme d'individu. Par exemple, La 2CV (la voiture) est une occurrence de l'entité produit d'un concessionnaire automobile.
Produit Réf.
Désignation Prix
Dépôt Code Adresse Type
Fournisseur N°
Nom Adresse
Commande N°
Date Quantité
Passer Livrer
Stocker
Apparteni
Livrer
0,1 1,n
0,n
0,n 1,1 1,1
1,1 0,n
0,n
1,n
Fig. 24
Dépôt (Code, adresse,...). Sont dégagées les associations suivantes: Livré par (produit, fournisseur), Appartient à (produit, commande), Stocké dans (produit, dépôt), Passé à (commande, fournisseur), Livrable à (commande, dépôt). Un tel exemple, pourtant assez simple présente quelques difficultés. Le schéma résultant, basé sur le modèle entité / association est celui de la figure 24.
La notation des cardinalités obéît à une règle assez simple, mais qui déconcerte quelquefois. Il suffit de se poser la question "combien de fois l'entité x, est concernée par l'entité y".
Exemple: Combien un client peut avoir de commandes? Dans la pratique, il peut ne pas en avoir, ou en avoir un nombre illimité. On note donc: 0,n. En sens inverse, combien une commande peut avoir de client. Sauf cas très particulier une commande ne provient que d'un seul, à minima, et d'un fournisseur à maxima, donc noté: 1,1.
§2 Introduction au modèle relationnel
Il s’agit ici d’un modèle conceptuel qui peut paraître, dans un premier temps plus simple à comprendre. Nous verrons dans le cadre du chapitre suivant, qu'il n'en est rien. Cependant, la connaissance des bases proposées à ce stades éclairera les règles plus complexes étudiée plus loin. Il s'agit pour l'instant, sans autre ambition, de comprendre le principe de la notion de relation. Ce sera suffisant pour structurer en TD des Tables mises en relations. Et suffisant pour constituer nos premières armes dans le domaine des SGBD-R.
Les principes de base sont en fait très proches de ceux du modèle entité / association. On peut donc les combiner avec le modèle étudié précédemment.
A) La notion de relation.
En pratique la relation est représentée par un tableau où les valeurs d’une même rubrique sont inscrites en colonne et où chaque ligne représente une occurrence (ou une réalisation) de la relation.
Pour l’exemple de l’entité client représentée à l’aide de ce modèle. Nous avons la relation:
R1: Client [Code_client, Nom, Adresse, Solde].
Code Nom Adresse Solde
123 Durant 2, rue des Lilas 1000
124 Vergnes 3, rue des Fleurs 500
125 Alibert 3, rue des Iris 2500
126 Zanzibar 1, place Gai 0
127 Dupont 1 rue Bona 1500
Le nom constitue un attribut. Une colonne représente un domaine de définition de l’attribut.
Chaque relation possède un index ou clé d’accès qui est synonyme d’identifiant tel que nous l’avons rencontré dans le cas du modèle entité / association. Une ligne, appelé ici un tuple, représente une réalisation de l’individu type soit un client réel dans cet exemple. Le nombre de domaine va déterminer le degré de la relation (dans notre cas la relation est de degrés 4). Le nombre de réalisation indique la cardinalité de la relation (dans ce cas 5). Comme dans le cas du modèle entité / association c’est lors la mise en relation de plusieurs entités (relations ici) que les difficultés apparaissent. C’est aussi dans cette phase de travail que se révèle la
Occurrence de la relation
puissance du modèle(2). Notez que les logiciels permettant de manipuler les relations, nomment ces dernières des Tables. Ce, sans doute, pour faire simple?
B) Les opérations sur les relations.
Une description des opérations, même si elle est sommaire, donne un aperçu de ce qui peut être obtenu à partir de certains traitements simples. Le résultat de ces manipulations de l’information est représenté en parallèle sous forme de tableau. Trois opérations de base sont examinées ici.
1er) La sélection d’une relation.
Cette opération consiste à sélectionner des lignes (tuples) qui vérifient certaines conditions.
Ainsi à partir de la relation R1: clients. La liste des clients dont le solde est supérieur ou égal à 500 F. Ce type d’opération est courant en gestion et aura pour objet, par exemple, l’envoi d’un relance. Une sélection est donc l’édition d’une partie du tableau initial. On a donc comme résultat R2 :
Code Nom Adresse Solde
123 Durant 2, rue des Lilas 1000
124 Vergnes 3, rue des Fleurs 500
125 Alibert 3, rue des Iris 2500
127 Dupont 1 rue Bona 1500
2er) La projection d’une relation.
Elle consiste dans la non prise en compte de certains attributs ce qui revient à sélectionner des domaines. Ainsi, à partir de la relation R1 la liste des noms des clients et leur solde. Soit la relation R3:
Nom Solde
Durant 1000
Vergnes 500
Alibert 2500
Zanzibar 0
Dupont 1500
3er) La jointure d’une relation.
Ici, il s’agit de créer une nouvelle relation à partir de relations existantes. La nouvelle relation pourra par exemple consister dans la mise en lumière d’un nouvelle donnée, soit ici le mode de paiement. Ce dernier fait appel à une autre relation (un autre fichier), celui des Modes de paiement. On ne retient, dans cet exemple de jointure que le code et le mode de paiement. Ce qui donne la relation R4 suivante :
Code Mode Paiement
123 Chèque
124 Effet 30 jours
125 Comptant
126 Carte Bancaire
127 Chèque
L’on pourra aussi créer par jointure à partir de la relation initiale R1 la relation suivante, qui peut s’écrire ainsi :
2Pour un exemple de travail approfondi sur le modèle l'on peut lire "Les systèmes d'information" Galacsi, Dunod informatique 1984.
Code Nom Adresse Mode Paiement
Solde
123 Durant 2, rue des Lilas Chèque 1000
124 Vergnes 3, rue des Fleurs Effet 30 jours 500
125 Alibert 3, rue des Iris Comptant 2500
126 Zanzibar 1, place Gai CB 0
127 Dupont 1 rue Bona Chèque 1500
Chapitre 2 De l'organisation des données aux Bases de Données.
A ce stade nous possédons les bases d'une compréhension de l'organisation nécessaire des données pour qu'elles soient utilisables en informatique. Il faut qu'au moins les données (porteuses d'informations, qui nous sont utiles et nous permettent d'agir sur un problème donné) soient organisées en fichiers. C'est un minimum.
Nous avons noté au passage que cette organisation doit être apte à être dynamique. Quelque soient l'organisation au départ, elle doit pouvoir répondre à des requêtes du temps
"aujourd'hui, et à fortiori aux requêtes futures. Exemple pour une base de données d'étudiants, où les besoins présents sont leurs notes, leurs emplois du temps. Dans un an, à partir des mêmes données, les besoins seront soit statistiques, soit de délivrance d'un duplicata quelconque de diplôme. Ce à partir des mêmes données, éventuellement complétées.
Or personne ne sait qu'elle sera la requête de tel ou tel agent d'un organisation, tout au moins avant que cet agent ne formule cette requête. Il faut structurer les données de manière à ce que toutes les requêtes possibles soient réalisables.
Pour cela l'organisation en fichier simple (fichier logique) est insuffisante. La modélisation Merise, va beaucoup plus loin et complète les fichiers "simples". Le pas suivant vers une automatisation des traitements, se trouve dans l'organisation des données en base de données, et mieux encore en Système de Gestion de Bases de Données. On peut considérer que la succession des modèles de la méthode Merise permet déjà cette structuration. C'est surtout au plan conceptuel que la méthode Merise est très intéressante.
Plus avant, les modélisations relationnelles permettent des résultats plus poussés. Du fait d'une caractéristique importante, les données sont indépendantes du langage de requête - langage que la méthode Merise n'avait pas pour ambition de mettre en œuvre.
A partir de tables, dont on connaît la structure, parce qu'il est possible d'en demander la "vue", l'on peut déterminer un nombre infini de requête, grâce à un langage "simple" de requêtes.
C'est le cas de SQL. (Voir plus loin les bases de ce langage particulier).
Section 1 Quelques piste pour une définition avancée des Bases de Données (BD).
$1) Les résultats escomptés d'une Base de Données.
A) Stocker de manière organisée.
Une Base de données (BD) est une collection de données stockées dans des fichiers sur disques et offrant à l'utilisateur une grande variété d'utilisation. Il peut ainsi:
ajouter, modifier ou supprimer des données,
créer de nouveaux, changer ou supprimer des fichiers,
consulter ces données, par exemple les produits qui coûtent moins de 100 ,
consulter la nature (structure) de ces données, par exemple le fait qu'un produit est stocké avec son nom, son prix et son fabricant
etc ...
B) Accéder au données.
Surtout, une base de données peut être utilisée simultanément par plusieurs utilisateurs ou applications, pour des besoins différents et selon des interfaces de plus en plus évoluées:
commandes rentrées sur un terminal,
menus déroulants, formulaires de saisie
interfaces graphiques sophistiqués etc ...
C) Proposer une interface d'accès aux données.
Un SGDB (Système de Gestion de Bases de Données), apparaît donc comme un ensemble de moyens logiciels permettant de stocker, retrouver, traiter et communiquer cette collection de données. Il est la coquille autour de la BD qu'il gère. Il en assure l'accès, le partage, l'intégrité et la sécurité.
$2 Un SGBD est organisé en couches.
Il est en fait organisé en plusieurs couches, qu'on peut classer en deux catégories:
A) Les couches internes.
Ce sont elles qui gèrent les données et leurs différents liens tel qu'ils sont physiquement stockés: formats des données, groupement en articles, ordre de présentation de ces articles au sein d'un fichier, cheminements entre différents articles dans différents fichiers etc...C'est donc une vue orientée machine.
B) Les couches externes.
Elles gèrent les données tel qu'elles sont perçues par l'utilisateur: les classes des objets comme les fournisseurs et les produits, leurs caractéristiques comme le prix d'un produit ou l'adresse d'un fournisseur, et les relations que ces objets entretiennent entre eux, comme par exemple un fournisseur fournit un produit. C'est donc une vue résolument orientée utilisateur. Cet aspect constitue, à vrai dire, la principale caractéristique d'un SGBD: Assurer l'indépendance entre les données physiques et la perception que l'utilisateur en a.
C) Bref Historique.
L'idée de Base de Données est apparue quand on a exprimer le besoin de gérer des quantité importantes de données. L'objectif était double: d'une part, assurer une meilleure indépendance entre les programmes et les données (celles-ci étaient mises dans des fichiers que seuls les programmes de manipulations peuvent connaître vu la structure de ces fichiers y est explicitement programmée, ce qui les rend assez « rigides » c’est à dire difficile à faire évoluer) et d'autre part, permettre l'accès aux données à différentes catégories d'utilisateurs Une BD rend possible une organisation globale des données, permettant ainsi une meilleur gestion et un meilleur contrôle des informations. L'indépendance entre l’interface et les fichiers de données rend l'évolutivité et la maintenance des programmes plus facile.
$3 Définition qui en résulte.
Une Base de Données est un ensemble de données qui reflètent (modélisent) les objets d'un certain univers organisationnel et servant de support aux applications informatiques d'une organisation telle qu'une entreprise, ou une administration.
Ces données ont une structure, c'est à dire obéissent à un modèle, qui doit refléter le plus fidèlement possible leurs caractéristiques dans l'univers considéré.
Ces données ne sont pas indépendantes (ce n'est pas une juxtaposition de fichiers).
Justement la structure choisie implique des relations entre les différents fichiers.
Ces données sont interrogeables par leur contenue, par exemple retrouver les données qui satisfont un certain critère (un produit de prix inférieur à 100 DH).
Tout critère d'interrogation doit être possible,. soit une différence par rapport à des fichiers classiques
La structure est aussi interrogeable (par exemple savoir quelles informations a-t-on sur quels objets).
Les données sont manipulables est présentables dans différentes formes (tri, graphiques, éditions de rapports, etc....).et selon différents besoins (gestion des carrières, paie etc...)
Elles sont accessibles à l'utilisateur final, aussi bien qu'aux programmes d'applications.
$4 Un Système de Gestion de Bases de Données est un logiciel.
Ce logiciel permettant, tout à la fois:
A). D'organiser, mémoriser et retrouver des données dans une base.
Quand un utilisateur exprime dans un certain langage une requête d'accès. Le SGBD:
l'analyse,
inspecte la structure de la base pour voir si la requête est possible,
exécute les opérations nécessaires sur les données stockées.
B). permet de modéliser pour mieux gérer les données d'une entreprise.
Pour cela:
il supporte un modèle de haut niveau pour décrire les données, par exemple en termes d'objets et de relations entre objets.
dans le cadre de ce même modèle, il permet d'exprimer les différentes opérations désirées et doit donc avoir les interfaces adéquats.
il rend possible l'intégration de plusieurs vues différentes et concernant des données communes
Ainsi un SGBD doit avoir un langage de haut niveau, comme par exemple SQL pour les SGBD relationnels, qui soit le plus simple, le plus complet et en même temps, le seule moyen d'accès à la base.
C). Garantir l'intégrité et la sécurités des données.
Le SGBD doit pouvoir:
assurer l'intégrité, la confidentialité et la sécurité des données
garantir la cohérence des données aussi bien vis à vis les unes des autres que vis à vis de la réalité qu'ils représentent (traitement des contraintes d'intégrité).
permettre l'accès simultané aux mêmes données à plusieurs utilisateurs sans conflits; donc gérer des programmes concurrents (des transactions, simultanées) dont le nombre peut atteindre les milliers
savoir optimiser les recherches des données pour un temps de réponse rapide
se prémunir contre les incidents par des moyens de sauvegarde et de restauration.
$5 Structure et composants d'un environnement base de données.
Il est commode de considérer un SGBD comme composé d'un noyau de base (ou moteur) qui réalise les fonctionnalités cités et d'un ensemble d'outils qui constituent les différentes variantes d'exploitation d'une BD. Nous pouvons dégager les deux couches de programmes dans un SGBD. Le noyau, ou cœur d'un SGBD qui est interfacé de façon unique par le langage base de données sous-jacent (SQL en l'occurrence). Cela veut dire qu'il reçoit des requêtes exprimées dans ce langage, les exécute et retourne un résultat s'il y'en a un. Cette requête est préparé par l'un des outils qui gravitent autour du noyau, lequel outil récupère le résultat éventuel en retour pour le traiter. On peut noter que cette structure s'apparente bien à un modèle Client / Serveur.
Section 2 Les Bases de Données Relationnelles (BDR)
$1 Le modèle Relationnel de Données.
A) Représenter un monde réel, par les relations qu'entretiennent des entités.
Les données et leur organisation, représente une réalité. La modélisation est une abstraction ou une représentation de cette réalité. L'une des premières tâches donc de toute automatisation est la modélisation. Modéliser veut dire choisir un ensemble de concepts pour représenter une certaine réalité. Appelée aussi univers de discours ou monde réel. En exprimant cette réalité en terme de ces concepts, on obtient ce qu'on appelle un modèle. En BD on parle de modèle de données. Le modèle relationnel de données, a été défini en 1970 par E.F. CODD, un chercheur des laboratoires IBM. Ce modèle, d'une grande simplicité , intègre les deux aspects d'un monde réel:
Une structure de données pour l'aspect statique et
Un ensemble d'opérateurs de manipulations pour l'aspect dynamique.
Si la structure de données sert pour décrire les objets du monde réel, les opérateurs de manipulation servent, quand à eux, à exprimer les opérations qu'on fait sur ces objets.
L'originalité introduite par le relationnel à l'époque, est l'idée de traitement ensembliste. Une seule opération peut traiter d'un coup un ensemble de données ("un ensemble à la fois"). Plus besoin de traitements itératifs type "un article à la fois, avec des opérateurs relationnels.
Le modèle relationnel présentait dès lors de nombreux avantages. Entre autre celui de ne pas nécessiter d'informaticien, en permettant à l'utilisateur final l'accès aux données dont il a besoin sans avoir à être un programmeur, ni à recourir aux services d'un informaticien.
B) Deux préoccupations sont avancées.
1er)Rendre l'information proche et accessible à l'utilisateur final.
Il est possible à un utilisateur non informaticien d'interagir directement avec un BD sans avoir recours à un informaticien, libérant ainsi le programmeur pour d'autres tâches.
2er) Améliorer le rendement des programmeurs avec des outils adéquats.
De part sa simplicité et son haut niveau d'abstraction, la technologie relationnelle contient la réponse à ces questions. Plus avant encore, les concepts ensemblistes du relationnel, vont dans le sens des environnements de programmation de 4e génération nécessaires à une meilleure créativité et une plus grande productivité.
$2 La structure des données: des Tables et des Colonnes.
Le modèle relationnel est basé sur une idée simple, celle de relation entre données élémentaires. Soit trois personnes: Ali, Amina et Amine âgées respectivement de 25, 20 et 20 ans. On peut établir une relation (correspondance), appelée A_POUR_AGE, entre ces trois noms et ces trois valeurs:
A_POUR_AGE Amina...20 Ali...25 Amine...20
On formalise cela en considérant les ensembles, ou domaines : des noms:
NOM = {Ali, Amina, Amine} et des ages AGE= {20, 25}où le résultat compose le Produit Cartésien NOM X AGE, constitué de tous les couples <n, a> où n est un nom et a un age:
{ <Ali, 20>,
<Ali, 25>, *
<Amine, 20>, *
<Amine, 25>,
<Amina, 20>, *
<Amina, 25> }
On dit que A_POUR_AGE est une relation (au sens mathématique), c'est à dire un sous ensemble du produit cartésien ci-dessus. Lequel sous ensemble est celui constitué des éléments (n-uplets) marqués d'une *, c'est à dire les couples <n, a> tels que dans l'application la personne n est âgée de a années. (Les noms NOM et AGE sont appelés attributs, et servent à identifier les domaines intervenant dans une relation. Nous dirons indifféremment domaine ou attribut pour simplifier).
Un fichier constitués d'articles de même nature, donc ayant un nombre fixe de rubriques (champs) et qui sont identiques, peut être vue comme une relation entres valeurs prises dans ces rubriques qui sont alors les domaines de la relation. Cette vue permet d'abstraire la notion de fichier, qui est liée au format de stockage, et de raisonner sur des données à un niveau sémantique plus conceptuel.
Il est commode de représenter une relation sous la forme d'une table:
A_POUR_AGE
--- NOM AGE --- Amina 20 Ali 25 Amine 20
où chaque ligne représente un couple <nom, age> et chaque colonne, un domaine ou attribut.
On peut voir ainsi les correspondances:
Fichier ...Relation...Table Article ...n-uplet ...Ligne Rubrique... Attribut...Colonne
Dans la suite on utilisera indifféremment les termes table ou relation; cela dépend du contexte.
En répétant le procédé ci-dessus, on peut concevoir toute une base de donnée ayant cette structure en tables. Sur la figure II-1, montre un exemple de BD à propos d'une organisation constituée d'employés (avec leur nom, leur adresse, et leur salaire) affectés dans des départements. Chaque département a un nom, se trouve localisé à un étage donné et est dirigé par un chef.
EMPLOYES --- NOM ADRESSE SALAIRE DEPT --- Karim Casa 10K Compta Ali Rabat 11K Finance Amina Rabat 12K Compta Sadik Fes 9K Personnel Aziz Casa 13K Finance DEPARTEMENTS ---
NOMD ETAGE CHEF --- Compta 1 Amina Finance 2 Ali Personnel 1 Sadik
Fig II-1 Exemple de BD Relationnelle
$3 Le problème de la valeurs NULL
NULL signifie indéfini. Une valeur NULL (ne pas confondre avec nulle = 0), sert parfois quand une information est inconnue (l'adresse d'une personne n'est pas encore connue) ou inapplicable (comme le salaire pour un stagiaire ou un vacataire). C'est une valeur interne différente de toute autre, affectée par le SGBD quand une information n'est pas saisie. Certain SGBD préfèrent utiliser des valeurs par défaut, comme 0 pour les données numériques et Blanc pour les données alphanumériques. D'autres proposent un choix entre les deux solutions. Noter aussi que ces valeurs NULL nécessitent des méthodes à part quant aux opérateurs de comparaisons (SALAIRE IS NULL ou IS NOT NULL en SQL).
Pour installer la BD illustrée par la figure II-1, on doit écrire en SQL
CREATE TABLE EMPLOYES ( NOM char(15) NOT NULL, ADRESSE char(20),
SALAIRE decimal(9,2), DEPT char (10) NOT NULL );
CREATE TABLE DEPARTEMENTS ( NOMDépartement char(10) NOT NULL, ETAGE integer,
CHEF char(15) );
où on déclare le contenu, colonnes avec type, de chaque table. L'usage de NOT NULL pour NOM, NOMDépartement et DEPT sera justifié plus bas, avec les contraintes du modèle relationnel.
$4 Les Opérateurs Relationnels.
La force du modèle relationnel réside sans aucun doute dans un ensemble d'opérateurs définis par CODD pour manipuler des relations. Ces opérateurs, dit algébriques, agissent sur des relations pour produire d'autres relations. Ils représentent du point de vue formelle toute opération (interrogation, mise à jour) qu'on désire effectuer sur une BD. Surtout, et comme ces opérateurs produisent des relations, ils peuvent se combiner les un avec les autres pour exprimer diverse sortes (toutes en fait) de questions qu'on peut formuler. Pour peu que l'on admette qu'une information extraite d'une base soit représentée elle-même sous forme de table. Les langages BD étant basés sur ces opérateurs pour, on va rapidement les présenter. On considérera l'exemple de la figure II-1.
$5 Les opérateurs spécifiques.
Projection, Restriction et Jointure A) La projection
Soit une opération qui ne retient d'une table que des colonnes données. On note PROJECT (Table, Colonne, Colonne, ...)
Ou SELECT Employes, Nom, Adresse From Table.employes Exemple:
PROJECT (EMPLOYES, NOM, ADRESSE) donne comme résultat la table:
--- NOM ADRESSE --- Karim Casa
Ali Rabat Amina Rabat Sadik Fes Aziz Casa
Ce qui représente une requête comme: "Le nom et l'adresse de tous les employés"
B) La restriction.
C'est une opération qui ne retient d'une table que les lignes répondant à un critère de qualification donné. On note RESTRICT (Table, Qualification).
Exemple:
RESTRICT (EMPLOYES, ADRESSE = "Rabat")
Ou SELECT employes, Adresse FROM Table.employes WHERE Adresse =’Rabat’
donne comme résultat la table:
--- NOM ADRESSE SALAIRE DEPT --- Ali Rabat 11K Finance Amina Rabat 12K Compta
Ce qui représente une question de type: "Les informations sur les employés de Rabat. En combinant restriction et projection, on peut exprimer des questions comme: "Quels sont les noms et salaires des employés de Rabat?":
PROJECT (RESTRICT (EMPLOYES, ADRESSE="Rabat"), NOM, SALAIRE).
Ce qui donne:
--- NOM SALAIRE
--- Ali 11K
Amina 12K
L'opérateur interne RESTRICT sélectionne les employés de Rabat, et l'opérateur PROJECT n'en garde que le nom et le salaire.
C) La jointure
Qui est une opération caractéristique, permet de rapprocher des informations appartenant à deux tables. Elle traite des questions dont la réponse nécessite l'examen de plusieurs tables.
On note: JOIN (Table1, Table2, Col_Table1 = Col_Table2).
Exemple:
JOIN (EMPLOYES, DEPARTEMENTS, DEPT=NOMD) donne :
--- NOM ADRESSE SALAIRE DEPT ETAGE CHEF --- Karim Casa 10K Compta 1 Amina Ali Rabat 11K Finance 2 Ali Amina Rabat 12K Compta 1 Amina Sadik Fes 9K Personnel 1 Sadik Aziz Casa 13K Finance 2 Ali
Où on dispose dans une même table des informations sur les employés et sur leur département respectif. En pratique, la jointure s'emploie toujours en combinaison avec d'autres opérateurs.
Ainsi, et pour répondre à une question comme: "Quels les noms des employés qui ont Ali pour chef", on écrira:
PROJECT (JOIN (RESTRICT (DEPARTEMENTS, CHEF="Ali"), EMPLOYES, NOMD=DEPT),
NOM).
Ce qui donne comme résultat:
---
NOM--- AliAziz
A la lumière de ces quelques exemples, on voit l'idée de traitement ensembliste mentionné au paragraphe précédent. La dernière expression nécessiterait une boucle (sinon deux boucles imbriquées) dans un traitement type "un article à la fois". C'est là le fondement d'un langage type 4e génération. Exprimer ce qu'on désire (le Quoi), sans indiquer la manière de l'obtenir (le Comment).
$6 Les opérateurs classiques sur les ensembles.
Ce sont les opérations classiques sur les ensembles, vue qu'une relation est ensemble de n- uplets. Nous les énumérons en bref. Ce sont l'UNION, la DIFFERENCE et le PRODUIT CARTESIEN. (L'intersection n'est en fait qu'une double différence).
UNION, permet de répondre aux questions de type les employés de Rabat ou qui ont Ali comme chef (opérateur logique ou). DIFFERENCE, permet de répondre à des questions avec négation, comme les employés qui ne travaillent pas dans un département donné, ou contenant un critère portant sur tout un ensemble de données, comme par exemple les fournisseurs qui fournissent toutes les pièces. (Quantificateur logique Quelque Soit). Quand à PRODUIT CARTESIEN, il est plus général que la jointure, et est nécessaires dans certains cas, comme opérateur interne.
Signalons au passage que les mises à jour dans une BD peuvent se modéliser avec ces opérateurs. L'insertion d'un n-uplet <x, y, z> dans une relation R n'est autre que:
UNION (R, {<x, y, z>}) , et la suppression de ce n-uplet: DIFFERENCE (R, {<x, y, z>}).
$7 Fondements de SQL.
SQL (Structured Query Language), est en fait un langage algébrique, mais beaucoup plus orienté langage naturel (se rappeler qu'un langage BD doit être proche de l'utilisateur final) et disposant de fonctions de calculs additionnels (AVG, COUNT...) ainsi que d'autres facilités (GROUP BY, ORDER BY...).
Plus précisément l'algèbre relationnelle est complète dans le sens où elle permet d'exprimer, par une expression appropriée, toute sorte de requête sur une BD. Pour qu'un langage base de données puisse être opérationnel, il doit avoir au moins la puissance d'expression des opérateurs relationnels. C'est le cas de SQL dès sa conception. Par exemple , la clause EXISTS n'existe en SQL que pour une raison de complétude (elle exprime la DIFFERENCE).
Le logiciel SGBD DBASE par exemple quoique catalogué de relationnel (il gère des tables) ne dispose pas d'un langage complet dans le sens précédent.
Section 3 Les règles d'intégrité du modèle.
$1 La Notion de Clé.
Dans une table, il est toujours possible de distinguer entre deux lignes quelconques (Dans une relation, tous les n-uplets sont, par définition, différents). On appelle clé primaire ou clé tout court, une colonne (ou combinaison de colonnes) dont les valeurs sont uniques d'une ligne à une autre. (En cas de combinaison de colonnes, on prend toujours la combinaison minimale).
Dans l'exemple de la figure II-1,NOM est clé de la table EMPLOYES et NOMD est clé de la table DEPARTEMENTS. (Pour simplifier, on a supposé des personnes de noms distincts)
Remarque: En réalité, on peut avoir le choix entre plusieurs clés d'une table. On dit alors clés candidates. C'est le choix de l'une d'elles qui constitue la clé primaire. En relationnel, la clé est le seul moyen d'adresser une ligne unique dans une table.
On appelle clé étrangère pour une table, une colonne (ou combinaison de colonnes) dont les valeurs se retrouvent dans la clé primaire d'une autre table. Par exemple, toujours sur la figure II-1, la colonne DEPT est clé étrangère pour la table EMPLOYES car ses valeurs se retrouvent dans la clé primaire, NOMD, de la table DEPARTEMENTS. On dit que la colonne DEPT de la table EMPLOYES référence la table DEPARTEMENTS. On peut constater que la colonne CHEF de la table DEPARTEMENTS référence la table EMPLOYES, faisant de CHEF une clé étrangère pour la table DEPARTEMENTS.
$2 Les deux règles d'intégrité du modèle relationnel.
A) Intégrité d'entité.
Cette règle spécifie que dans une table, la valeur de la clé doit toujours être définie, c'est à dire n'est jamais NULL. Ceci se justifie par le fait que d'une part, une ligne dans une table représente un certain objet de l'univers et comme tel il est doit être identifiable, d'autre part, la valeur de la clé constitue le seul moyen d'accéder aux valeurs des autres colonnes dans la même ligne. (D'où les "NOT NULL" vus dans les CREATE TABLE).
B) Intégrité référentielle.
Cette règle spécifie que la valeur d'une clé étrangère est soit NULL, soit égale à une valeur qui doit exister comme clé dans la table référencée. Par exemple, toutes les valeurs de la colonne CHEF dans la table DEPARTEMENTS, existent comme valeur dans la colonne NOM dans la table EMPLOYES. Notez que l'inverse, n'est pas forcement vrai: un(e) employé(e) n'est pas forcément chef d'un département, voir. Aziz. Noter aussi, qu'une valeur de la colonne CHEF peut être NULL. C'est le cas par exemple d'un département sans chef, ou dont le chef est parti en retraite et qu'on n'a pas encore remplacé.
Ains l'intégrité référentielle, proposée par E.F. CODD en 1979, joue un double rôle:
1er elle permet de préserver l'intégrité de la base, et de prévenir des situations où, par exemple, un département a un chef inconnu , et de se prémunir contre la perte, par erreur, d'une information (employé) tant qu'une autre (le département dirigé) qui en a besoin existe.
2er elle représente un aspect sémantique de l'application. A savoir le lien existant entre plusieurs objets. Par exemple un employé dirige un département. En effet, le modèle relationnel étant orienté valeurs, le recoupement d'informations se fait à travers les valeurs de colonnes équivalentes dans plusieurs tables.
Une représentation graphique intéressante est:
--- --- EMPLOYES DEPARTEMENT --- --- NOM |---> NOMD
ADRESSE | ETAGE SALAIRE | CHEF DEPT --->|
--- ---
Où la flèche indique un lien existant entre les deux tables. Ici le lien dirige.
Remarque: L'intégrité référentielle joue un autre rôle, et pas des moindres, dans la rétro- conception (reengineering). En effet, il arrive qu'on désire retrouver, et cela longtemps après, la sémantique initiale d'une BDR. Or, on a peut être perdu l'analyse initiale ou elle n'est plus d'actualité, vu les nombreuses modifications qu'aurait pu subir le schéma de la base depuis sa création. L'intégrité référentielles peut se révéler d'une grande aide pour cela, en évitant d'avoir à analyser les sources des requêtes SQL, par exemple, pour essayer de retrouver la sémantique d'une BDR.
$3 Les règles de mises à jours associées
Aux contraintes référentielles, sont associées certaines règles de mise à jour permettant de les préserver. Ces règles sont à définir dès la conception d'une BD.
A) Règle 1
La première est une réponse à la question: une clé étrangère accepte-t-elle la valeur NULL? Le concepteur doit le préciser dès la création de la base en répondant oui ou non, et cela pour toutes les clés étrangères. La réponse à cette question revêt aussi un aspect sémantique. Dire si la colonne DEPT dans la table EMPLOYES peut ou ne peut pas admettre de valeur NULL, c'est dire si pour un employé il y a toujours un département où il travaille ou non. C'est à dire est-ce que cela a un sens qu'à un moment donné, un employé ne se trouve affecté à aucun département?.
B) Règle 2
La contrainte référentielle exige que les valeurs d'une clé étrangère doivent forcément figurer comme valeur de clé primaire d'une certaine table. Que doit-on faire si cette contrainte risque d'être violée, par exemple par la modification ou la suppression d'une clé primaire? Laquelle est peut être désignée par une clé étrangère. Il est défini pour cela trois classes de réponses:
"NULLIFIER":
Si une clé primaire est supprimée ou modifiée dans une table, rendre NULL toutes les valeurs clé étrangères qui lui sont égales. (Bien sûr cela dépend de la réponse à la question posée par la règle 1). Par exemple, toujours sur l'exemple de la figure II-1, si on supprime un employé, et s'il se trouve être chef d'un département, on rend NULL la valeur CHEF pour ce département.
PROPAGER ("to CASCADE"):
Si une clé primaire est modifiée (resp. supprimée) dans une table, propager cette modification vers toutes les tables où figure une clé étrangère qui lui est égale (resp. supprimer dans ces tables toutes les lignes ayant la valeur supprimée pour clé étrangère). Par exemple si on modifie le nom d'un département (colonne NOMD de la table DEPARTEMENTS), on modifie de la même façon, l'ancien nom de ce département dans la table EMPLOYES(colonne DEPT).
Dans un autre exemple, si on supprime un client, on doit supprimer en même temps toutes les commandes qu'il a faites.
REFUSER:
C'est le cas le plus simple. Si, lors de la suppression ou la modification d'une clé primaire, une contrainte référentielle est violée, alors refuser la mise à jour. Probablement, on attendra que les clés étrangères correspondantes soient modifiées pour effectuer la mise à jour. Par exemple, on refusera de supprimer un département pour ne pas supprimer tous les employés qui y travaillent. On attendra qu'ils (elles) soient affecté(e)s à un autre département, avant de le faire.
