DB2 ou Database 2 est un système de gestion de base de données relationnelle proposé par IBM qui s’exécute sur IBM Mainframe, AS/400 et sur PC. Une base de données DB2 peut passer d’une petite application mono-utilisateur à un grand système multi-utilisateurs.
DB2 est conçu pour stocker, analyser et récupérer efficacement les données. Le produit DB2 est étendu avec la prise en charge des fonctionnalités orientées objet et des structures non relationnelles avec XML.
Quels sont les avantages?
Il est facile à comprendre. Les données des bases de données Db2 sont présentées aux utilisateurs sous forme de tableau. C’est l’une des manières les plus courantes d’afficher des données, telles que les annuaires téléphoniques et les horaires des transports publics.
Il permet une flexibilité de conception. Comme vous pouvez l’imaginer, un tableau de données est relativement facile à concevoir. Tout ce que vous devez savoir, ce sont les éléments clés de votre base de données, tels que le nom, l’adresse et le numéro de téléphone.
Il fournit une facilité d’accès. L’utilisateur est protégé du fonctionnement interne de Db2. Par conséquent, l’utilisateur n’a pas besoin de connaître les relations physiques de la base de données à laquelle il accède.
Qu’est-ce que la base de données ?
Une base de données est une collection de données stockées de manière organisée. La façon la plus simple d’y penser est d’imaginer une base de données comme un classeur. Le classeur est simplement un emplacement physique pour stocker des données, quelles que soient ces données ou leur organisation.
DATABASE – Un conteneur (généralement un fichier ou un ensemble de fichiers) pour stocker des données organisées.
Qu’est-ce qu’une base de données relationnelle ?
Toute base de données dont l’organisation logique est basée sur un modèle de données relationnel (Relation – Terme mathématique pour Table).
Db2 lui-même est une base de données relationnelle, qui est essentiellement une collection de données connexes stockées dans plusieurs tables qui peuvent être réassemblées pour former des données utilisateur significatives.
Chaque table est divisée en entités plus petites appelées champs. Un champ est une colonne dans une table conçue pour conserver des informations spécifiques sur chaque enregistrement de la table.
Un enregistrement, également appelé ligne, est chaque entrée individuelle qui existe dans une table. Une colonne est une entité verticale dans une table qui contient toutes les informations associées à un champ spécifique dans une table.
Groupe de stockage
Un groupe de stockage DB2 (STOGROUP) est un ensemble de volumes sur des périphériques de stockage à accès direct (DASD). Les volumes contiennent les ensembles de données VSAM dans lesquels les tables et les index sont réellement stockés.
Le nombre maximum de volumes par groupe de stockage est de 133 (idéalement 3 ou 4). Tous les volumes d’un groupe de stockage donné doivent avoir le même type de périphérique (3380, 3390, etc.). Cependant, des parties d’une même base de données peuvent être stockées dans différents groupes de stockage. Si les volumes d’un groupe de stockage sont de types différents ou si un volume n’est pas monté ou n’est pas valide, une erreur se produit lorsque vous essayez de créer un espace table ou un index. Essayez d’affecter les objets fréquemment consultés (index, par exemple) aux périphériques rapides et les tables rarement utilisées aux périphériques plus lents ; ce choix de groupes de stockage améliore les performances.
Une fois que vous avez défini un groupe de stockage, DB2 stocke les informations le concernant dans le catalogue DB2. (Ce catalogue n’est pas le même que le catalogue de l’utilitaire de catalogue intégré qui décrit les ensembles de données DB2 VSAM). La table de catalogue SYSIBM.SYSSTOGROUP a une ligne pour chaque groupe de stockage et SYSIBM.SYSVOLUMES a une ligne pour chaque volume.
Lors de l’installation, le groupe de stockage par défaut du système est défini. Ce groupe de stockage est nommé SYSDEFLT. Si vous ne gérez pas explicitement votre stockage, DB2 utilise le groupe de stockage par défaut pour allouer de l’espace.
Hiérarchie des objets DB2
La figure suivante représente la hiérarchie des objets DB2 :
hiérarchie des objets DB2
Nous verrons chaque objet DB2 de cette figure dans le chapitre “DB2 – Détails de la base de données“.
Une base de données (DB2) est un ensemble de tables de données ou d’entités associées. Par exemple, une base de données typique pour une organisation comprendrait un client, une commande et des tables de détails de commande. Toutes ces tables sont liées les unes aux autres d’une manière ou d’une autre. Dans cet exemple, les clients ont des commandes et les commandes ont des détails de commande. Même si chaque table existe par elle-même, collectivement, les tables constituent une base de données.
La base de données est un groupe d’espaces de table et d’espaces d’index logiquement liés, qui à leur tour contiennent respectivement des tables et des index.
La base de données par défaut, DSNDB04, est prédéfinie dans le processus d’installation de DB2.
Espace table (Table Space)
Les données sont en fait stockées dans une structure appelée espace table (Table Space).
Chaque espace table est corrélé à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.
Chaque espace table contient une ou plusieurs tables.
Il existe trois types d’espace table différents :
Espace de table simple
Espace table segmenté
Espace table partitionné
Nous parlerons en détail de l’espace de la table tout en traitant des ” verrous ” (Locks) au chapitre “DB2 – Verrous“.
Espace d’indexation (Index Space)
Un espace d’index est la structure de stockage sous-jacente pour les données d’index.
Chaque espace d’index correspond à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD du groupe de stockage.
Il est automatiquement créé par DB2 chaque fois qu’un index est créé. Il ne peut y avoir qu’un seul index dans un espace d’index.
Table
Les tables sont des structures logiques gérées par le gestionnaire de base de données.
Lorsque vous stockez des informations dans votre classeur, vous ne les jetez pas simplement dans un tiroir. Au lieu de cela, vous créez des fichiers dans le classeur, puis vous classez les données associées dans des fichiers spécifiques.
Dans le monde des bases de données, ce fichier s’appelle une table. Une table est un fichier structuré qui peut stocker des données d’un type spécifique. Une table peut contenir une liste de clients, un catalogue de produits ou toute autre liste d’informations.
Chaque table a un nom, et dans une table, chaque colonne a un nom. Aucun ordre particulier n’est conservé parmi les lignes d’une table, mais les lignes peuvent être récupérées dans un ordre déterminé par les valeurs de leurs colonnes. Les données d’un tableau sont logiquement liées. Toutes les données de table sont affectées à des espaces table.
Un tableau est constitué de données disposées logiquement en colonnes et en lignes.
Colonne (Column)
Les tableaux sont constitués de colonnes. Une colonne contient une information particulière dans un tableau.
La colonne est un champ unique dans une table. Tous les tableaux sont constitués d’une ou plusieurs colonnes.
La meilleure façon de comprendre cela est d’envisager les tables de base de données comme des grilles, un peu comme des feuilles de calcul. Chaque colonne de la grille contient une information particulière. Par exemple : dans une table “client“, une colonne contient le numéro de client, une autre contient le nom du client, et l’adresse, la ville, l’état et le code postal sont tous stockés dans leurs propres colonnes.
Ligne (Row)
Les données d’une table sont stockées dans des lignes.
La ligne est un enregistrement dans une table.
Encore une fois, en envisageant un tableau comme une grille de style feuille de calcul, les colonnes verticales de la grille sont les colonnes du tableau et les lignes horizontales sont les lignes du tableau.
Par exemple, une table client peut stocker un client par ligne. Le nombre de lignes dans la table est le nombre d’enregistrements qu’elle contient.
Exemple de table
Types de tableaux
Table de base : une table de base est créée avec l’instruction CREATE TABLE et est utilisée pour contenir des données utilisateur persistantes.
Table de résultats : une table de résultats est un ensemble de lignes que le gestionnaire de base de données sélectionne ou génère à partir d’une ou plusieurs tables de base pour répondre à une requête.
Table récapitulative : une table récapitulative est une table définie par une requête qui est également utilisée pour déterminer les données de la table. Les tables récapitulatives peuvent être utilisées pour améliorer les performances des requêtes. Si le gestionnaire de base de données détermine qu’une partie d’une requête peut être résolue à l’aide d’une table récapitulative, le gestionnaire de base de données peut réécrire la requête pour utiliser la table récapitulative.
Table temporaire : une table temporaire déclarée est créée avec une instruction DECLARE GLOBAL TEMPORARY TABLE et est utilisée pour contenir des données temporaires au nom d’une seule application. Cette table est supprimée implicitement lorsque l’application se déconnecte de la base de données.
Index
Un index est une aide à l’accès aux données qui peut être créée sur une table. C’est un ensemble ordonné de pointeurs vers les lignes d’une table.
Chaque index est basé sur les valeurs des données dans une ou plusieurs colonnes d’une table. Un index est un objet distinct des données de la table. Lorsque vous créez un index, le gestionnaire de base de données construit la structure et la maintient automatiquement.
Un index peut servir les objectifs suivants :
Améliorer les performances. Dans la plupart des cas, l’accès aux données est plus rapide avec un index. Fournit un moyen rapide de rechercher des lignes dans une table en fonction de leurs valeurs dans les colonnes clés.
Applique les règles d’unicité en définissant une colonne ou un groupe de colonnes en tant qu’index unique ou clé primaire.
Fournit un ordre logique des lignes d’une table en fonction des valeurs des colonnes clés.
Regroupe les lignes d’une table dans le stockage physique selon l’ordre de l’index défini.
Vue (View)
Une vue offre une manière différente d’examiner les données dans une ou plusieurs tables. La vue est une table virtuelle constituée d’une instruction SQL SELECT qui accède aux données d’une ou plusieurs tables ou vues.
Une vue ne stocke jamais de données. Lorsque vous accédez à une vue, l’instruction SQL qui la définit est exécutée pour dériver les données demandées.
Une vue comporte des colonnes et des lignes, tout comme une table de base. Toutes les vues peuvent être utilisées comme des tables de base pour la récupération de données.
Vous pouvez utiliser des vues pour contrôler l’accès aux données sensibles, car les vues permettent à plusieurs utilisateurs de voir différentes présentations des mêmes données. Par exemple, plusieurs utilisateurs peuvent accéder à une table de données sur les employés. Un responsable voit des données sur ses employés, mais pas sur les employés d’un autre service. Un chargé de recrutement voit les dates d’embauche de tous les employés, mais pas leurs salaires ; un agent financier voit les salaires, mais pas les dates d’embauche. Chacun de ces utilisateurs travaille avec une vue dérivée de la table de base. Chaque vue apparaît comme une table et a son propre nom.
Lorsque la colonne d’une vue est directement dérivée de la colonne d’une table de base, cette colonne de vue hérite de toutes les contraintes qui s’appliquent à la colonne de la table de base. Par exemple, si une vue inclut une clé étrangère de sa table de base, les opérations d’insertion et de mise à jour utilisant cette vue sont soumises aux mêmes contraintes référentielles que la table de base. De plus, si la table de base d’une vue est une table parent, les opérations de suppression et de mise à jour utilisant cette vue sont soumises aux mêmes règles que les opérations de suppression et de mise à jour sur la table de base.
Une vue peut devenir inopérante (par exemple, si la table de base est supprimée) ; si cela se produit, la vue n’est plus disponible pour les opérations SQL.
La meilleure façon de reconnaître les vues est de regarder un exemple. (Vous étudierez plus en détail les SQL. Cet exemple est juste pour vous faire comprendre le concept de vues).
Vous avez les trois tables suivantes :
Clients
Commandes
Détails de la commande
Vous devez récupérer les clients qui ont commandé un produit spécifique.
Les détails de la colonne sont les suivants :
3 Tables avec leurs colonnes respectives
La requête est la suivante :
SELECT NOM_CLIENT, PRENOM_CLIENT
FROM CLIENTS, COMMANDES, DETAILSWHERE CLIENTS.ID_CLIENT = COMMANDES.ID_CLIENT
AND DETAILS.NUM_COMMANDE = COMMANDES.NUM_COMMANDE
AND ID_PRODUIT = 'BANANE' ;
Toute personne ayant besoin de ces données devrait comprendre la structure de la table, ainsi que la façon de créer la requête et de joindre les tables. Pour récupérer les mêmes données pour un autre produit (ou pour plusieurs produits), la dernière clause WHERE devrait être modifiée.
Imaginez maintenant que vous puissiez encapsuler toute cette requête dans une table virtuelle appelée “PRODUITS”. Vous pourriez alors simplement faire ce qui suit pour récupérer les mêmes données :
SELECT NOM_CLIENT, PRENOM_CLIENTFROM PRODUITS
WHERE ID_PRODUIT = 'BANANE' ;
C’est là que les vues entrent en jeu. “PRODUITS” est une vue et, en tant que vue, elle ne contient aucune colonne ni donnée. Au lieu de cela, il contient une requête, la même requête utilisée ci-dessus pour joindre correctement les tables.
Pourquoi utiliser les vues ?
Voici quelques utilisations courantes des vues :
Pour extraire des données de plusieurs tables.
Pour réutiliser les instructions SQL.
Pour simplifier les opérations SQL complexes. Une fois la requête écrite, elle peut être réutilisée facilement, sans avoir à connaître les détails de la requête sous-jacente elle-même.
Pour exposer des parties d’un tableau au lieu de tableaux complets.
Pour sécuriser les données. Les utilisateurs peuvent avoir accès à des sous-ensembles spécifiques de tables au lieu de tables entières.
Pour modifier le formatage et la représentation des données. Les vues peuvent renvoyer des données formatées et présentées différemment de leurs tables sous-jacentes.
Pour la plupart, une fois les vues créées, elles peuvent être utilisées de la même manière que les tables. Vous pouvez effectuer des opérations SELECT, filtrer et trier des données, joindre des vues à d’autres vues ou tables, et éventuellement même ajouter et mettre à jour des données. Certaines restrictions s’appliquent à ce dernier élément. La chose importante à retenir est que les vues ne sont que cela, des vues sur des données stockées ailleurs. Les vues ne contiennent pas de données elles-mêmes, de sorte que les données qu’elles renvoient sont extraites d’autres tables. Lorsque des données sont ajoutées ou modifiées dans ces tables, les vues renverront ces données modifiées.
Il existe des problèmes de performances avec les vues car les vues ne contiennent aucune donnée, toute récupération nécessaire pour exécuter une requête et qui doit être traitée chaque fois que la vue est utilisée. Si vous créez des vues complexes avec plusieurs jointures et filtres, ou si vous imbriquez des vues, vous constaterez peut-être que les performances sont considérablement dégradées. Assurez-vous de tester l’exécution avant de déployer des applications qui utilisent beaucoup les vues.
Synonyme
Autre nom privé pour une table ou une vue.
Un synonyme ne peut être utilisé que par la personne qui l’a créé.
Lorsqu’une table ou une vue est supprimée, tous les synonymes qui y sont définis sont également supprimés.
Alias
Nom défini localement pour une table ou une vue dans le même sous-système DB2 local ou dans un sous-système DB2 distant. Les alias confèrent à DB2 une indépendance d’emplacement car un alias peut être créé pour une table sur un site distant, évitant ainsi à l’utilisateur de spécifier le site qui contient les données. Les alias peuvent également être utilisés comme un type de synonyme global car ils peuvent être consultés par n’importe qui, pas seulement par leur créateur.
Lorsqu’une table/vue est supprimée, tous les alias définis dessus ne sont PAS supprimés.
Utilisez des synonymes pour le développement de programmes, utilisez des alias pour les applications distribuées et utilisez des vues pour la sécurité et l’adhésion.
Le tableau suivant donne la différence entre “Synonyme” et “Alias” :
Synonyme
Alias
Un autre nom pour une table ou une vue qui doit résider dans le sous-système DB2 local
Un autre nom pour une table ou une vue qui peut résider dans le sous-système DB2 local ou distant
Ne peut être utilisé que par son créateur
Peut être utilisé par n’importe qui, y compris son créateur
Est supprimé lorsque la table/vue correspondante est supprimée
Pas supprimé même lorsque la table/vue correspondante est supprimée
Différences entre Synonyme et Alias
Stockage physique des données
La figure suivante représente la façon dont les données sont stockées physiquement dans le système DB2 :
Exemple de stockage de données physique
Pools de mémoire tampon (Buffer Pool)
Les pools de mémoire tampon sont des zones de stockage virtuel dans lesquelles DB2 stocke temporairement des pages d’espaces table ou d’index.
Les pools de mémoire tampon améliorent les performances de la base de données. Si une page de données nécessaire se trouve déjà dans le pool de mémoire tampon, cette page est accessible plus rapidement que si cette page devait être lue directement à partir du disque. Le gestionnaire de base de données a des agents dont les tâches consistent à récupérer les pages de données du disque et à les placer dans le pool de mémoire tampon (prefetchers), et à réécrire les pages de données modifiées du pool de mémoire tampon sur le disque (nettoyeurs de page).
La lecture et l’écriture de pages de données vers et depuis le disque sont appelées entrée/sortie disque (E/S). Éviter l’attente associée aux E/S disque est le principal moyen d’améliorer les performances de la base de données. La manière dont vous créez le pool de mémoire tampon et configurez le gestionnaire de base de données et les agents associés au pool de mémoire tampon contrôle les performances de la base de données.
Dans DB2, vous avez la possibilité d’allouer 80 pools de mémoire tampon :
50 pools de mémoire tampon 4K et
10 pools de mémoire tampon 8K, 16K et 32K.
Le pool de mémoire tampon par défaut est BP0.
Relation entre les espaces de table et les pools de mémoire tampon
Chaque espace table est associé à un pool de mémoire tampon spécifique dans une base de données. Un tablespace est associé à un bufferpool. La taille du pool de mémoire tampon et de l’espace de table doit être identique. Plusieurs pools de mémoire tampon vous permettent de configurer la mémoire utilisée par la base de données pour augmenter ses performances globales.
Tailles des pools de mémoire tampon
La taille de la page du pool de mémoire tampon est définie lorsque vous utilisez la commande “CREATE DATABASE“. Si vous ne spécifiez pas la taille de la page, elle prendra la taille de page par défaut, qui est de 4 Ko. Une fois le bufferpool créé, il n’est plus possible de modifier la taille de la page ultérieurement
Une fois ce chapitre terminé, vous serez en mesure de concevoir une base de données DB2.
Pourquoi devriez-vous vous préoccuper de la conception de la base de données ?
Vous examinerez le concept de conception de base de données avec l’exemple réel.
Dites que votre base de données est comme une maison personnalisée et que vous allez en faire construire une pour nous. Quelle est la première chose que vous allez faire ? Vous n’allez certainement pas embaucher un entrepreneur immédiatement et le laisser construire notre maison comme il le souhaite. Vous engagerez sûrement d’abord un architecte pour concevoir votre nouvelle maison, puis embaucherez un entrepreneur pour la construire.
L’architecte exprimera vos besoins sous la forme d’un ensemble de plans, enregistrant les décisions concernant la taille et la forme, et les exigences pour divers systèmes (structurels, mécaniques, électriques). Ensuite, l’entrepreneur fournira la main-d’œuvre et les matériaux, y compris les systèmes énumérés, puis les assemblera conformément aux dessins et aux spécifications.
Revenons maintenant à votre perspective de base de données et considérons la conception logique de la base de données comme les plans architecturaux et l’implémentation physique de la base de données comme la maison terminée. La conception de la base de données logique décrit la taille, la forme et les systèmes nécessaires pour une base de données ; il répond aux besoins d’information et aux besoins opérationnels de votre entreprise.
Vous construisez ensuite l’implémentation physique de la conception de la base de données logique à l’aide de votre logiciel SGBDR. Une fois que vous avez créé vos tables, configuré les relations entre les tables et établi les niveaux appropriés d’intégrité des données, notre base de données est complète. Vous êtes maintenant prêt à créer une application qui permet d’interagir facilement avec les données stockées dans la base de données et vous pouvez être sûr que ces applications fourniront des informations opportunes et surtout précises.
Il est possible de mettre en œuvre une mauvaise conception dans un SGBDR, mais une base de données bien conçue fournira des informations précises, stockera les données de manière plus efficace et plus efficace et sera plus facile à gérer et à entretenir.
Si une base de données est mal conçue, les utilisateurs auront des difficultés à récupérer certains types d’informations, et il existe un risque supplémentaire que les recherches produisent des informations inexactes. Des informations inexactes sont probablement le résultat le plus préjudiciable d’une mauvaise conception de la base de données. Cela peut avoir un impact négatif sur le résultat net d’une entreprise.
En fait, si les données conservées et utilisées dans une base de données vont affecter la façon dont une entreprise exécute ses opérations quotidiennes ou si elles vont influencer l’orientation future de l’entreprise, la conception de la base de données doit être une préoccupation.
Activités impliquées dans la conception de la base de données
La conception de la base de données implique :
la conception de base de données logique
la conception de base de données physique
l’implémentation et modification de la conception de la base de données
La conception d’une base de données logique implique trois phases :
Phase d’analyse des besoins
Phase de modélisation des données
Phase de normalisation
Phase d’analyse des besoins
La phase d’analyse des besoins consiste à examiner l’entreprise modélisée, à interroger les utilisateurs et la direction pour évaluer le système actuel et à analyser les besoins futurs, et à déterminer les informations requises pour l’entreprise dans son ensemble. Ce processus est relativement simple.
Phase de modélisation des données
La phase de modélisation des données consiste à modéliser la structure de la base de données elle-même. Cela implique l’utilisation d’une méthode de modélisation des données qui fournit un moyen de représenter visuellement divers aspects de la structure de la base de données, tels que les tables, les relations entre les tables et les caractéristiques des relations.
Certaines des méthodes de modélisation de données courantes sont :
Modélisation des relations d’entité (modélisation ER)
Modélisation objet sémantique
Modélisation des rôles d’objet
La méthode que vous utilisez ici est une version de base de la modélisation ER.
Modélisation ER
Un diagramme ER simple se présente comme suit :
Modélisation ER : Agent – Client
Cette figure représente plusieurs aspects de la base de données. Premièrement, il transmet le fait qu’il y a deux tables dans cette base de données, l’une appelée Agents et l’autre appelée Clients ; chacun des tableaux est représenté par un rectangle. Le losange représente le fait qu’il existe une relation entre ces deux tables, et le “1:N” dans le losange indique que la relation est une relation un-à-plusieurs. Enfin, le diagramme traduit le fait qu’un client doit être associé à un agent (indiqué par la ligne verticale à côté de la table AGENTS), mais un agent ne doit pas nécessairement être associé à un client (comme indiqué par le cercle à côté de le tableau CLIENTS).
Un diagramme entité-relation (ER) est un graphique spécialisé qui illustre les interrelations entre les entités dans une base de données d’une modélisation de données logiques.
Symboles utilisés dans le diagramme ER
La boîte représente l’entité
Le diamant représente la relation
L’ovale représente l’attribut
Activités clés dans la modélisation ER
Voici les principales activités impliquées dans la conception d’une base de données logique à l’aide du mode Entity-Relationship :
Définir les entités
Définir la clé primaire
Définir les relations entre les entités
Définir des attributs supplémentaires pour les entités
Définir les entités
Vous commencez le modèle ER, en définissant les entités, les objets d’intérêt significatifs
Les entités sont les éléments sur lesquels vous souhaitez stocker des informations.
Définir la clé primaire
Une clé primaire est un identifiant unique pour une entité.
Si une clé primaire est composée de plusieurs attributs, elle est appelée “clé composite”.
Définir les relations entre les entités
Une connexion établie entre une paire de tables est appelée une relation. Une relation existe lorsqu’une paire de tables est connectée par une clé primaire et une clé étrangère ou est liée par une troisième table, appelée table de liaison.
Les relations sont très importantes car elles aident à réduire les données redondantes et les données en double. Ils permettent également de définir des vues.
Chaque relation peut être caractérisée par le type de relation qui existe entre les tables, le type de participation de chaque table au sein de la relation et le degré de participation de chaque table au sein de la relation.
Types de relations (cardinalité) :
Lorsque deux tables sont liées, il existe toujours un type de relation spécifique (traditionnellement connu sous le nom de cardinalité) qui existe entre elles. Il existe trois types de relations possibles :
Un par un
relations un-à-plusieurs et plusieurs-à-un
plusieurs à plusieurs
Relations individuelles (un-à-un) :
Une relation un-à-un existe entre une paire de tables si un seul enregistrement de la première table est lié à un seul enregistrement de la deuxième table et qu’un seul enregistrement de la deuxième table est lié à un seul enregistrement de la première table.
La figure suivante montre un exemple de relation un-à-un impliquant une table EMPLOYEES et une table SALAIRES. Dans cet exemple, un seul enregistrement de la table EMPLOYEES est lié à un seul enregistrement de la table SALAIRES; de même, un seul enregistrement de la table SALAIRES est lié à un seul enregistrement de la table EMPLOYEES.
Relations un-à-plusieurs :
Une relation un-à-plusieurs existe entre une paire de tables si un seul enregistrement de la première table peut être lié à un ou plusieurs enregistrements de la deuxième table, mais qu’un seul enregistrement de la deuxième table ne peut être lié qu’à un seul enregistrement dans le premier tableau.
Une relation un-à-plusieurs impliquant une table ETUDIANTS et une table MATIERES est illustrée dans la figure suivante. Dans ce cas, un seul enregistrement de la table ETUDIANTS peut être lié à un ou plusieurs enregistrements de la table MATIERES, mais un seul enregistrement de la table MATIERES est lié à un seul enregistrement de la table ETUDIANTS.
Relation Un-à-Plusieurs
Relations plusieurs-à-un :
Une relation plusieurs-à-un existe entre une paire de tables si un seul enregistrement de la première table ne peut être lié qu’à un seul enregistrement de la seconde table, mais qu’un seul enregistrement de la seconde table peut être lié à un ou plusieurs enregistrements de le premier tableau.
Une relation plusieurs-à-un impliquant une table FILIERES et une table MATIERES est illustrée dans la figure suivante. Dans cet exemple, un seul enregistrement de la table FILIERES peut être lié à un seul enregistrement de la table MATIERES et un seul enregistrement de la table MATIERES peut être lié à un ou plusieurs enregistrements de la table FILIERES.
La figure suivante représente la relation plusieurs-à-un.
Relation Plusieurs-à-Un
Relations plusieurs-à-plusieurs :
Une relation plusieurs-à-plusieurs existe entre une paire de tables si un seul enregistrement de la première table peut être lié à un ou plusieurs enregistrements de la deuxième table, et un seul enregistrement de la deuxième table peut être lié à un ou plusieurs enregistrements dans le premier tableau.
La figure suivante montre une relation classique de plusieurs à plusieurs. Dans cet exemple, un seul enregistrement de la table EMPLOYES peut être lié à un ou plusieurs enregistrements de la table REUNION ; de même, un seul enregistrement de la table REUNION peut être lié à un ou plusieurs enregistrements de la table EMPLOYES.
La figure suivante représente la relation plusieurs à plusieurs. Ici, une relation est établie entre deux tables à l’aide d’une table de liaison PLANNING.
Relation Plusieurs-à-Plusieurs
Types de participation (facultatif):
Il existe deux types de participation qu’une table peut avoir dans une relation :
Obligatoire
Optionnel
Supposons qu’il existe une relation entre deux tables appelées TABLE A et TABLE B.
Si des enregistrements dans la TABLE A doivent exister avant que de nouveaux enregistrements puissent être saisis dans la TABLE B, la participation de la TABLE A au sein de la relation est obligatoire.
Cependant, s’il n’est pas nécessaire que des enregistrements dans la TABLE A existent pour entrer de nouveaux enregistrements dans la TABLE B, la participation de la TABLE A dans la relation est facultative.
Chaque table d’une relation peut participer d’une manière ou d’une autre. Le type de participation de chaque table au sein d’une relation est généralement déterminé par la manière dont les données de chaque table sont liées et la manière dont les données sont utilisées.
Examinez la relation entre les tables CONSEILLERS et CLIENTS dans la figure suivante. La table CONSEILLERS a une participation obligatoire dans la relation si des agents doivent exister avant qu’un nouveau client puisse être saisi dans la table CLIENTS. Mais la participation de la table CONSEILLERS est facultative s’il n’est pas nécessaire d’avoir des agents dans la table CONSEILLERS avant qu’un nouveau client puisse être saisi dans la table CLIENTS.
Le type de participation établi pour la table CONSEILLERS est déterminé par la manière dont ses données sont utilisées par rapport aux données de la table CLIENTS. Par exemple, s’il est nécessaire de s’assurer que chaque client se voit attribuer un agent disponible, la participation de la table CONSEILLERS dans la relation doit être obligatoire.
Type de participation
Représentation de la cardinalité et de l’option :
En général, les conventions suivantes sont utilisées pour représenter la cardinalité et l’optionalité,
Cardinalité :
La notion de cardinalité s’exprime soit par “un” soit par “plusieurs”
Une cardinalité « un » s’exprime par une « ligne droite » et une cardinalité « plusieurs » s’exprime à l’aide de « pattes d’oie ».
Facultatif :
La notion d’optionnalité est exprimée soit comme “obligatoire” soit comme “facultative”
Une option “Facultatif” est exprimée sous la forme d’un “cercle” et une option “Obligatoire” est exprimée sous la forme d’une “barre verticale”.
Exemple de diagramme ER :
Prenons l’exemple d’une base de données contenant des informations sur les habitants des villes. Le diagramme ER contient deux entités – Personne et Ville.
Facultatif
Une personne devrait vivre dans une ville. (C’est pourquoi une barre apparaît à côté de Ville venant de Personne). Une ville peut exister sans personne. (C’est pourquoi un cercle apparaît à côté de Personne dans la « Relation Ville – Personne »).
Exemple de Diagramme ER
Définissez des attributs supplémentaires pour les entités :
La définition des attributs d’une entité comprend les activités suivantes.
Définition du nom d’attribut.
Définition du type de données pour les attributs.
Définir les valeurs appropriées pour les attributs – quelles valeurs sont acceptables pour les différents attributs d’une table.
La normalisation est une approche de conception qui minimise la redondance des données et optimise les structures de données en plaçant systématiquement et correctement les éléments de données dans les groupements appropriés. La normalisation est le processus d’organisation efficace des données dans une base de données et le processus de décomposition de grandes tables en tables plus petites.
Objectifs de normalisation :
Le processus de normalisation a deux objectifs :
Éliminer les données redondantes (par exemple, stocker les mêmes données dans plusieurs tables).
Veiller à ce que les dépendances de données aient un sens (stocker uniquement les données associées dans une table).
Ces deux objectifs sont louables car ils réduisent la quantité d’espace consommée par une base de données et garantissent que les données sont stockées de manière logique et évitent les problèmes d’insertion, de mise à jour ou de suppression de données.
Forme normale :
Une série de lignes directrices ont été élaborées par la communauté des bases de données pour s’assurer que les bases de données sont normalisées. Ces lignes directrices sont représentées par différentes formes normales.
Les types de formes normales sont les suivants :
Première forme normale ou 1NF
Deuxième forme normale ou 2NF
Troisième forme normale ou 3NF
Quatrième forme normale ou 4NF
Cinquième forme normale ou 5NF
Dans les applications pratiques, en général, vous n’utilisez que 1NF, 2NF et 3NF.
Première forme normale :
Toutes les entités doivent avoir un identifiant ou une clé unique, qui peut être composé d’un ou plusieurs attributs.
Éliminer les groupes répétitifs et les données non atomiques d’une entité.
Le terme atomique dérive d’atome, la plus petite particule indivisible qui puisse exister par elle-même.
La première forme normale élimine les groupes répétitifs et les données non atomiques d’une entité.
Pour normaliser un modèle de données en 1NF, éliminez les groupes répétitifs en entités individuelles. En d’autres termes, n’utilisez pas plusieurs attributs dans une seule entité pour stocker des données similaires. Considérez les exemples de données présentés dans le tableau pour un système d’information ÉTUDIANT pour un collège ou une université.
Ces données contiennent plusieurs violations de 1NF. Tout d’abord, vous suivez des cours qui représentent réellement un groupe de redoublants pour les ÉTUDIANTS. Ainsi, les informations sur le cours doivent être déplacées dans des entités distinctes. De plus, vous devez spécifier des identifiants pour les deux entités. L’identifiant est la clé primaire de l’entité
Une deuxième violation de 1NF concerne les données non atomiques affichées dans l’attribut “Nom Etudiant“. Un nom d’étudiant peut être divisé en plusieurs parties : prénom, initiale et nom de famille. Il n’est pas indivisible et viole donc la première forme normale.
Données ÉTUDIANT non normalisées
ID Etudiant
Nom Etudiant
ID Matière
Nom Matière
Numéro Cours
Nom Cours
Date Cours
0001
Martin, Pierre
MAT
Mathématiques
MAT0011 MAT0027 ANG0010
Mathématiques Algèbre Anglais Classique
2022/08/01 2022/04/30 2021/12/30
0002
Antoine, Paul
PHL
Philosophie
PHL0010 INF00100
Introduction à la Philosophie Langages de programmation
2022/04/30 2022/04/30
0003
Robert, Pires
ANG
Littérature anglaise
ANG0102
Ascension de l’homme
2022/08/01
0004
Lee, Xavier
MUS
Musique
MUS0002 ANG0102
Origine du Jazz Ascension de l’Homme
2022/04/30 2022/08/01
0005
Gassama, Isaac
INF
Informatique
INF00100
Langages de programmation
2022/04/30
0006
Luigi, Mario
ANG
Littérature anglaise
ANG0010 ANG0101
Anglais Classiques Shakespeare
2021/12/30 2022/08/01
Entité ETUDIANT en 1NF
ID Etudiant
Nom
Prénom
ID Matière
Nom Cours
0001
Martin
Pierre
MAT
Mathématiques
0002
Antoine
Paul
PHL
Philosophie
0003
Robert
Pires
ANG
Littérature anglaise
0004
Lee
Xavier
MUS
Musique
0005
Gassama
Isaac
INF
Informatique
0006
Luigi
Mario
ANG
Littérature anglaise
EntitéCOURS en 1NF
ID Etudiant
Numéro Cours
Nom Cours
Date Cours
0001
MAT0011
Mathématiques
01/08/2022
0001
MAT0027
Algèbre
30/04/2022
0001
ANG0010
Anglais Classique
30/12/2021
0002
PHL0010
Introduction à la philosophie
30/04/2022
0002
INF00100
Langages de programmation
30/04/2022
0003
ANG0102
Ascension de l’homme
01/08/2022
0004
MUS0002
Origine du jazz
30/04/2022
0004
ANG0102
Ascension de l’homme
01/08/2022
0005
INF00100
Langages de programmation
30/04/2022
0006
ANG0010
Anglais Classique
30/12/2021
0006
ANG0101
Shakespeare
01/08/2022
Deuxième forme normale :
Doit être en première forme normale
Chaque attribut non clé dépend entièrement de la clé
La deuxième forme normale (2NF) garantit que tous les attributs de chaque entité dépendent de la clé primaire.
Notez que certains cours se répètent dans l’entité COURS, à savoir “Anglais Classique” et “Ascension de l’homme”. Cette situation indique une violation de 2NF. Pour corriger le problème, nous devons identifier les attributs qui ne dépendent pas de la clé entière et les supprimer. Les attributs supprimés, ainsi que la partie de la clé primaire dont ils dépendent, sont placés dans une nouvelle entité, INSCRIPTION. La clé primaire entière de l’entité d’origine reste avec l’entité d’origine.
Un autre avantage du processus de normalisation est que vous rencontrerez fréquemment de nouveaux attributs qui doivent être spécifiés pour les nouvelles entités créées. Par exemple, peut-être que la nouvelle entité COURS nous rappelle que chaque cours se voit attribuer un certain nombre de crédits qui comptent pour l’obtention du diplôme. Aucune modification n’a été nécessaire pour l’entité ÉTUDIANT :
EntitéINSCRIPTION en 2NF
ID Etudiant
Numéro Cours
Date Cours
0001
MAT0011
2022-08-01
0001
MAT0027
2022-04-30
0001
ANG0010
2021-12-30
0002
PHL0010
2022-04-30
0002
INF00100
2022-04-30
0003
ANG0102
2022-08-01
0004
MUS0002
2022-04-30
0004
ANG0102
2022-08-01
0005
INF00100
2022-04-30
0006
ANG0010
2021-12-30
0006
ANG0101
2022-08-01
EntitéCOURS en 2NF
Numéro Cours
Nom Cours
Crédits
MAT0011
Mathématiques
3
MAT0027
Algèbre
4
ANG0010
Anglais Classique
3
PHL0010
Introduction à la philosophie
3
INF00100
Langages de programmation
3
ANG0102
Ascension de l’homme
3
MUS0002
Origine du jazz
3
Troisième forme normale :
Doit être en deuxième forme normale
Chaque attribut non clé dépend de manière non transitive de la clé primaire, c’est-à-dire que chaque attribut de l’entité ne doit dépendre que de la clé et non d’autres attributs non clés.
Une règle empirique pour identifier les violations 3NF consiste à rechercher des groupes d’attributs dont les valeurs peuvent s’appliquer à plusieurs occurrences d’entité. Lorsque vous découvrez de tels attributs, déplacez-les vers une entité distincte.
Il est temps de revoir à nouveau nos informations sur les ÉTUDIANTS, cette fois à la recherche de violations 3NF. Examinez attentivement les données ÉTUDIANT. Notez que les étudiants peuvent avoir la même majeure et, à ce titre, certaines informations majeures peuvent être répétées, en particulier deux étudiants de notre petit échantillon sont des majors de littérature anglaise. Pour corriger le problème, nous devons supprimer les principaux attributs qui dépendent transitivement de la clé et créer une nouvelle entité pour eux.
Entité ETUDIANT en 3NF
ID Etudiant
Nom
Prénom
ID Matière
0001
Martin
Pierre
MAT
0002
Antoine
Paul
PHL
0003
Robert
Pires
ANG
0004
Lee
Xavier
MUS
0005
Gassama
Isaac
INF
0006
Luigi
Mario
ANG
Entité MATIERE en 3NF
ID Matière
Nom Matière
MAT
Mathématiques
PHL
Philosophie
ANG
Littérature anglaise
MUS
Musique
INF
Informatique
Un modèle de données normalisé :
Pour être complet, un diagramme doit être développé pour le modèle de données 3NF que nous venons de créer pour les données STUDENT. La figure montre un tel modèle de données. Notez que nous n’avons pas rempli le caractère facultatif des relations. Nous pourrions le faire sur la base des exemples de données que nous avons utilisés, mais nous devons vraiment poser plus de questions avant de pouvoir répondre à des questions telles que Est-ce que chaque étudiant doit avoir une majeure ? Les données actuelles montrent que c’est le cas, mais en réalité ; vous savez que la plupart des étudiants de première année, et même des étudiants de la classe supérieure, peuvent fréquenter l’université sans avoir une majeure officiellement déclarée.
Modèle de données étudiant
Autres formes normales :
La normalisation ne s’arrête pas avec 3NF. Des formes normales supplémentaires ont été identifiées et documentées. Cependant, la normalisation au-delà de 3NF ne se produit pas souvent dans la pratique normale. Voici des formes normales supplémentaires. Juste pour votre information, nous avons gardé ceci.
La forme normale de Boyce Codd (BCNF) est un raffinement supplémentaire de 3NF. En effet, dans ses écrits ultérieurs, Codd fait référence à BCNF en tant que 3NF. Une ligne est sous forme normale de Boyce Codd si et seulement si chaque déterminant est une clé candidate. La plupart des entités en 3NF sont déjà en BCNF.
La quatrième forme normale (4NF) stipule qu’aucune entité ne peut avoir plus d’une seule relation un-à-plusieurs si les attributs un-à-plusieurs sont indépendants les uns des autres. Une entité est en 4NF si et seulement si elle est en 3NF et n’a pas d’ensembles multiples de dépendances à valeurs multiples.
La cinquième forme normale (5NF) spécifie que chaque dépendance de jointure pour l’entité doit être une conséquence de ses clés candidates.
Après avoir terminé la conception logique de notre base de données, nous passons maintenant à la conception physique. Le but de construire une conception physique de notre base de données est d’optimiser les performances tout en assurant l’intégrité des données en évitant les redondances de données inutiles.
Lors de la conception physique, vous transformez les entités en tables, les instances en lignes et les attributs en colonnes. Vous devez décider de nombreux facteurs qui affectent la conception physique, dont certains sont répertoriés comme suit :
Comment traduire des entités en tables physiques
Quels attributs utiliser pour les colonnes des tables physiques
Quelles colonnes des tables définir comme clés
Quels index définir sur les tables
Quelles vues définir sur les tables
Comment dénormaliser les tables
Comment résoudre les relations plusieurs-à-plusieurs
La conception physique est le moment où vous abrégez les noms que vous avez choisis lors de la conception logique. Par exemple, vous pouvez abréger le nom de la colonne qui identifie les employés, NUMERO_EMPLOYEE, en NUMEMP.
La tâche de construire la conception physique est un travail qui ne se termine vraiment jamais. Vous devez surveiller en permanence les performances et les caractéristiques d’intégrité des données de la base de données au fil du temps. De nombreux facteurs nécessitent des améliorations périodiques de la conception physique.
Dénormalisation :
La dénormalisation est une étape clé dans la tâche de construction d’une conception de base de données relationnelle physique. Il s’agit de la duplication intentionnelle de colonnes dans plusieurs tables, et la conséquence est une redondance accrue des données.
Ceci est recommandé pour éviter que des problèmes de performances ne surviennent à la suite de la normalisation. Cela doit être fait en fonction des besoins de traitement des applications accédant aux données.
La mise en œuvre de la conception de la base de données implique :
Implémentation des objets DB2
Chargement des données
Gestion des données
Modification de la conception si nécessaire
Modification de la conception de la base de données :
Après avoir utilisé une base de données relationnelle pendant un certain temps, nous souhaiterons peut-être modifier certains aspects de sa conception.
Pour modifier la conception de la base de données, nous devons modifier les définitions des objets DB2.
Avantage de DB2 sur VSAM (ou) Différence entre DB2 et VSAM :
La liste suivante indique certaines des différences entre DB2 et VSAM.
Caractéristique
DB2
VSAM
Indépendance matérielle
PC vers ordinateur central (Mainframe)
Ordinateur central uniquement (Mainframe)
Indépendance du système d’exploitation
NT, Unix et OS/390
Uniquement OS/390
Facilité de développement
Procédure stockée SQL standard et déclencheurs
Pas si simple Aucune option de ce type
Facilité d’entretien
SQL standard
Difficile
Sécurité
Degrés de sécurité élevés
Uniquement au niveau du jeu de données
Intégrité référentielle
DB2 l’applique
Responsabilité des développeurs
Interface de requête
Facile à visualiser/modifier
Indisponible
Performance
Meilleur pour les poignées d’optimiseur de données, même volumineuses
Mieux quand les données sont moins Développeur responsable
L’optimisation des performances
Peut être réglé à tout moment Peut être au niveau SQL Outils disponibles pour aider Compétences de réglage abondantes
Dépend de la conception initiale Niveau d’application uniquement Aucune aide au réglage Les compétences en réglage sont rares
Réorganisation
Réorganisation directe Réorganisation en ligne possible
Supprimer et recréer les temps d’arrêt nécessaires
Récupération
Géré par DB2 Toujours récupérable À partir du journal/sauvegarde Récupération automatique
Géré par CICS/IMS Pas de restauration par lot A partir de la sauvegarde uniquement Restauration manuelle
Sauvegarde
Sauvegarde en ligne possible Sauvegarde incrémentielle
Temps d’arrêt nécessaire
Pas de sauvegarde incrémentielle
reprise après sinistre
Pris en charge par DB2
Partie de la récupération DASD
Archivage des données
Archivage sélectif Extraction sélective Archivage jusqu’au niveau ligne
Non Archivage sélectif Non Extraction sélective Archivage au niveau du jeu de données
Types de données
Images, vidéo, audio, etc. Le contenu peut être dans le fichier
DB2 garantit automatiquement l’intégrité des données en appliquant plusieurs stratégies de verrouillage. Ces stratégies permettent à plusieurs utilisateurs de plusieurs environnements d’accéder aux données et de les modifier simultanément. Les verrous DB2 empêchent un programme d’accéder aux données qui ont été modifiées, mais pas encore validées, par un autre programme.
Le processus de verrouillage est contrôlé par l’IRLM (Inter System Resource Lock Manager) de DB2. Cependant, chaque fois que possible, DB2 essaie de verrouiller les pages sans passer par l’IRLM. Ce type de verrous s’appelle un loquet.
Espace table – Récapitulatif
Les données sont en fait stockées dans une structure appelée espace table. Chaque espace table est corrélé à un ou plusieurs ensembles de données VSAM physiques individuels dans les volumes DASD d’un groupe de stockage. Chaque espace table contient une ou plusieurs tables.
Il existe trois différents types d’espace table et sont les suivants :
Espace de table simple
Espace table segmenté
Espace table partitionné
Espace table simple
Dans un espace table simple, l’espace est divisé en pages sans aucune structure de niveau supérieur. Un espace table simple peut contenir des données provenant de plusieurs tables. Comme les lignes de données de différentes tables peuvent résider sur la même page, la simultanéité sera considérablement réduite. Après la version 2.1 de DB2, les espaces table simples sont presque obsolètes.
Espace table segmenté
Dans un espace table segmenté, l’espace est divisé en groupes de pages de taille égale appelés “Segments”. Chaque segment peut contenir des lignes d’une seule table. Il s’agit du type d’espace table le plus efficace, car il maximise la simultanéité.
Espace table partitionné
Dans l’espace table partitionné, l’espace est divisé en unités appelées “Partitions”. Chaque partition contient une partie d’une table et réside sur un ensemble de données VSAM distinct. Chaque espace table de partition ne peut contenir qu’une seule table. Cela convient aux grandes tables contenant un million de pages ou plus.
Taille de verrouillage
Lorsqu’un espace table est défini ou modifié, la clause LOCKSIZE spécifie une taille de verrou par défaut.
La taille du verrou peut être :
ROW
PAGE
TABLE
TABLESPACE
ANY
Lorsque l’option LOCKSIZE(ANY) est utilisée, DB2 sélectionne la taille de verrou optimale pour chaque situation de traitement.
Verrouiller l’escalade
La hiérarchie des verrous est la suivante :
Si le nombre de verrous dans un niveau dépasse une valeur par défaut de l’installation, DB2 verrouille une unité plus grande. C’est ce qu’on appelle l’escalade de verrouillage.
Durée de verrouillage
La durée du verrouillage fait référence à la durée pendant laquelle un verrouillage est maintenu. La durée d’un verrou est basée sur les options BIND choisies pour le programme demandant des verrous. Les verrous peuvent être acquis soit immédiatement lorsque l’exécution du plan est demandée, soit de manière itérative selon les besoins pendant l’exécution du programme.
Paramètres de liaison affectant l’espace table et les verrous de table
ACQUIRE(ALLOCATE) : les verrous seront acquis lors de l’allocation du plan, ce qui se produit normalement lorsque la première instruction SQL est émise. Ceci est utilisé pour le traitement par lots.
ACQUIRE(USE) : les verrous seront acquis uniquement lorsqu’ils sont requis, instruction SQL par instruction SQL. Ceci est utilisé pour le traitement en ligne.
RELEASE (DEALLOCATE) : les verrous ne sont pas libérés tant que le plan n’est pas terminé et qu’il n’est pas utilisé pour le traitement par lots.
RELEASE(COMMIT) : les verrous sont libérés lorsqu’un COMMIT est émis et est utilisé pour le traitement en ligne.
Les paramètres de liaison affectant les verrous de page et de ligne sont le niveau d’isolement.
