Archives de catégorie : DB2 cours

Présentation de DB2

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
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“.

Détails de la base de données DB2

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, DETAILS 
    WHERE 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_CLIENT
    FROM  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” :

SynonymeAlias
Un autre nom pour une table ou une vue qui doit résider dans le sous-système DB2 localUn 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éateurPeut être utilisé par n’importe qui, y compris son créateur
Est supprimé lorsque la table/vue correspondante est suppriméePas 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 :

Stockage physique des données 
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

Conception de base de données DB2

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

Conception de base de données logique DB2

La conception d’une base de données logique implique trois phases :

  1. Phase d’analyse des besoins
  2. Phase de modélisation des données
  3. 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.

Normalisation DB2

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 :

  1. Première forme normale ou 1NF
  2. Deuxième forme normale ou 2NF
  3. Troisième forme normale ou 3NF
  4. Quatrième forme normale ou 4NF
  5. 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 EtudiantNom EtudiantID MatièreNom MatièreNuméro CoursNom CoursDate Cours
0001Martin, PierreMATMathématiquesMAT0011
MAT0027
ANG0010
Mathématiques
Algèbre
Anglais Classique
2022/08/01
2022/04/30
2021/12/30
0002Antoine, PaulPHLPhilosophiePHL0010
INF00100
Introduction à la Philosophie
Langages de programmation
2022/04/30
2022/04/30
0003Robert, PiresANGLittérature anglaiseANG0102Ascension de l’homme2022/08/01
0004Lee, XavierMUSMusiqueMUS0002
ANG0102
Origine du Jazz
Ascension de l’Homme
2022/04/30
2022/08/01
0005Gassama, IsaacINFInformatiqueINF00100Langages de programmation2022/04/30
0006Luigi, MarioANGLittérature anglaiseANG0010
ANG0101
Anglais Classiques
Shakespeare
2021/12/30
2022/08/01

Entité ETUDIANT en 1NF

ID EtudiantNomPrénomID MatièreNom Cours
0001MartinPierreMATMathématiques
0002AntoinePaulPHLPhilosophie
0003RobertPiresANGLittérature anglaise
0004LeeXavierMUSMusique
0005GassamaIsaacINFInformatique
0006LuigiMarioANGLittérature anglaise

Entité COURS en 1NF

ID EtudiantNuméro CoursNom CoursDate Cours
0001MAT0011Mathématiques01/08/2022
0001MAT0027Algèbre30/04/2022
0001ANG0010Anglais Classique30/12/2021
0002PHL0010Introduction à la philosophie30/04/2022
0002INF00100Langages de programmation30/04/2022
0003ANG0102Ascension de l’homme01/08/2022
0004MUS0002Origine du jazz30/04/2022
0004ANG0102Ascension de l’homme01/08/2022
0005INF00100Langages de programmation30/04/2022
0006ANG0010Anglais Classique30/12/2021
0006ANG0101Shakespeare01/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 EtudiantNuméro CoursDate Cours
0001MAT00112022-08-01
0001MAT00272022-04-30
0001ANG00102021-12-30
0002PHL00102022-04-30
0002INF001002022-04-30
0003ANG01022022-08-01
0004MUS00022022-04-30
0004ANG01022022-08-01
0005INF001002022-04-30
0006ANG00102021-12-30
0006ANG01012022-08-01

Entité COURS en 2NF

Numéro CoursNom CoursCrédits
MAT0011Mathématiques3
MAT0027Algèbre4
ANG0010Anglais Classique3
PHL0010Introduction à la philosophie3
INF00100Langages de programmation3
ANG0102Ascension de l’homme3
MUS0002Origine du jazz3

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 EtudiantNomPrénomID Matière
0001MartinPierreMAT
0002AntoinePaulPHL
0003RobertPiresANG
0004LeeXavierMUS
0005GassamaIsaacINF
0006LuigiMarioANG

Entité MATIERE en 3NF

ID MatièreNom Matière
MATMathématiques
PHLPhilosophie
ANGLittérature anglaise
MUSMusique
INFInformatique

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.

Conception de base de données physique DB2

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.

Implémentation et modification de la conception de la base de données DB2

La mise en œuvre de la conception de la base de données implique :

  1. Implémentation des objets DB2
  2. Chargement des données
  3. Gestion des données
  4. Modification de la conception si nécessaire

Modification de la conception de la base de données :

  1. Après avoir utilisé une base de données relationnelle pendant un certain temps, nous souhaiterons peut-être modifier certains aspects de sa conception.
  2. 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éristiqueDB2VSAM
Indépendance matériellePC vers ordinateur central (Mainframe)Ordinateur central uniquement (Mainframe)
Indépendance du système d’exploitationNT, Unix et OS/390Uniquement OS/390
Facilité de développementProcédure stockée SQL standard
et déclencheurs
Pas si simple
Aucune option de ce type
Facilité d’entretienSQL standardDifficile
SécuritéDegrés de sécurité élevésUniquement au niveau du jeu de données
Intégrité référentielleDB2 l’appliqueResponsabilité des développeurs
Interface de requêteFacile à visualiser/modifierIndisponible
PerformanceMeilleur 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 performancesPeut ê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éorganisationRéorganisation directe Réorganisation
en ligne possible
Supprimer et recréer
les temps d’arrêt nécessaires
RécupérationGé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
SauvegardeSauvegarde en ligne possible
Sauvegarde incrémentielle
Temps d’arrêt nécessaire

Pas de sauvegarde incrémentielle
reprise après sinistrePris en charge par DB2Partie de la récupération DASD
Archivage des donnéesArchivage
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éesImages, vidéo, audio, etc.
Le contenu peut être dans le fichier
Texte uniquement
Aucune option de ce type

Les verrous DB2

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 :

  1. Espace de table simple
  2. Espace table segmenté
  3. 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.

Niveau d’isolement DB2

Avant d’examiner les types d’isolement, nous devons comprendre :

Qu’est-ce que le niveau d’isolement et pourquoi en avons-nous besoin ?

Différentes applications ou utilisateurs peuvent accéder et modifier les données stockées dans une base de données DB2 en même temps. Le gestionnaire de base de données DB2 doit donc pouvoir permettre aux utilisateurs d’apporter les modifications nécessaires tout en garantissant que l’intégrité des données n’est jamais compromise.

Le partage de ressources DB2 par plusieurs utilisateurs ou programmes d’application en même temps est appelé concurrence. L’une des façons dont DB2 applique la simultanéité consiste à utiliser des niveaux d’isolement, qui déterminent comment les données consultées et/ou modifiées par une transaction sont “isolées” des autres transactions.

Les niveaux d’isolement sont appliqués par des verrous et le type de verrou utilisé limite ou empêche l’accès aux données par des processus d’application simultanés.

Le gestionnaire de base de données prend en charge trois catégories générales de verrous :

Share (S)
Sous un verrou S, les processus d’application simultanés sont limités aux opérations en lecture seule sur les données.

Update (U) :
Sous un verrou U, les processus applicatifs concurrents sont limités aux opérations en lecture seule sur les données, si ces processus n’ont pas déclaré qu’ils pourraient mettre à jour une ligne. Le gestionnaire de base de données suppose que le processus qui examine actuellement une ligne peut la mettre à jour.

Exclusive (X) :
Sous un verrou X, les processus d’application simultanés ne peuvent en aucun cas accéder aux données. Cela ne s’applique pas aux processus d’application avec un niveau d’isolement de lecture non validée (UR), qui peut lire mais pas modifier les données.

Quel que soit le niveau d’isolement, le gestionnaire de base de données place des verrous exclusifs sur chaque ligne insérée, mise à jour ou supprimée. Ainsi, tous les niveaux d’isolement garantissent que toute ligne modifiée par un processus d’application au cours d’une unité de travail n’est pas modifiée par un autre processus d’application tant que l’unité de travail n’est pas terminée.

DB2 a quatre niveaux d’isolement de verrouillage :

  1. Lecture répétable ( RR – Repeatable Read )
  2. Stabilité de la lecture ( RS – Read Stability )
  3. Stabilité du curseur ( CS – Cursor Stability )
  4. Lecture non validée ( UR – Uncommitted Read )

Lecture répétable (RR) :

Cela maintient les verrous de page et de ligne jusqu’à ce qu’un point COMMIT soit atteint. Aucun autre programme ne peut modifier les données. Si les données sont consultées deux fois au cours de l’unité de travail, les mêmes données exactes seront renvoyées.

Stabilité de la lecture (RS):

Cela maintient les verrous de page et de ligne jusqu’à ce qu’un point COMMIT soit atteint. Mais d’autres programmes peuvent INSÉRER de nouvelles données. Si les données sont accédées deux fois au cours de l’unité de travail, de nouvelles lignes peuvent être renvoyées, mais les anciennes lignes n’auront pas changé.

Stabilité du curseur (CS) :

Niveau d’isolement par défaut. Cela acquiert et libère les verrous de page ou de ligne au fur et à mesure que les pages ou les lignes sont lues et traitées. Cela fournit le plus haut niveau de simultanéité. Mais il est possible que des données différentes soient renvoyées par le même curseur s’il est traité deux fois au cours de la même unité de travail.

Lecture non validée (UR) :

Ceci est également connu sous le nom de traitement de lecture sale. UR évite complètement le verrouillage. Il est possible de lire des données qui n’existent peut-être jamais réellement dans la base de données. Nous pouvons l’utiliser pour travailler avec la table qui est rarement mise à jour.

Quel que soit le niveau d’ISOLEMENT choisi, tous les verrous de page sont libérés lorsqu’un COMMIT est rencontré.

Intégrité des données DB2

L’intégrité des données fait référence à la validité, la cohérence et l’exactitude des données dans une base de données. On ne saurait trop insister sur le fait que le niveau de précision des informations extraites de la base de données est directement proportionnel au niveau d’intégrité des données imposé dans la base de données.

L’intégrité des données est l’un des aspects les plus importants du processus de conception de bases de données, et il ne doit pas être sous-estimé, négligé ou même partiellement négligé. Faire l’une de ces erreurs entraînerait un risque élevé d’erreurs indétectables

Il existe trois types d’intégrité des données et sont les suivants :

  1. Intégrité de l’entité
  2. Intégrité référentielle
  3. Intégrité du domaine

Intégrité de l’entité :

Il s’agit de “l’intégrité au niveau de la table” qui garantit que le champ qui identifie chaque enregistrement dans la table est unique et ne manque jamais sa valeur.

L’intégrité d’entité nécessite la spécification d’une clé primaire (PK – Primary Key) pour chaque table.

Remarques clés sur la clé primaire :

  1. Chaque table peut avoir zéro ou une clé primaire.
  2. La clé primaire ne doit pas être Null et si la clé primaire est une clé composite, assurez-vous que chaque composant ne doit pas être Null.
  3. Chaque clé primaire explicitement définie pour une table doit être associée à un index unique correspondant.
  4. Si vous ne créez pas d’index unique pour une clé primaire, une clé incomplète est définie pour la table, rendant la table inaccessible.

Contrainte unique:

Une contrainte unique est similaire à une contrainte de clé primaire qui applique également des valeurs uniques sur un individu ou un groupe de colonnes. Chaque table peut avoir zéro, une ou plusieurs contraintes uniques composées chacune d’une ou plusieurs colonnes. Les valeurs stockées dans la colonne unique ou la combinaison de colonnes doivent être uniques dans la table. La colonne de contrainte unique ne doit pas être Null.

Un index unique doit être créé sur les colonnes de la contrainte unique pour garantir l’unicité. La seule différence entre la contrainte de clé primaire et la contrainte unique est qu’une table ne peut avoir qu’une seule contrainte de clé primaire, mais peut avoir plusieurs contraintes uniques.

Index unique :

En plus de créer un index unique dans la colonne de clé primaire ou la colonne de contrainte unique (ce qui est obligatoire), vous pouvez créer autant d’index uniques que nécessaire sur toutes les autres colonnes de la table pour garantir l’unicité.

Le tableau suivant montre la différence entre l’index unique sur la colonne de contrainte de clé primaire/unique et une autre colonne autre que la colonne de contrainte primaire/unique.

Clé primaire ou colonne de contrainte uniqueColonne autre que la contrainte primaire/unique mais définie avec un index unique
Une table ne peut contenir qu’une seule contrainte de clé primaire et plusieurs contraintes uniquesUne table peut contenir plusieurs index uniques
Impossible d’autoriser les valeurs NULLPeut autoriser les valeurs NULL
Prend en charge l’intégrité référentielleNe peut pas prendre en charge l’intégrité référentielle

Intégrité référentielle :

Il s’agit d’une « intégrité au niveau de la relation » qui garantit que la relation entre une paire de tables est saine et qu’il y a une synchronisation entre les deux tables chaque fois que des données sont saisies, mises à jour ou supprimées.

L’intégrité référentielle est obtenue grâce à la clé étrangère.

Clé étrangère ( Foreign Key ) :

Une clé étrangère (FK – Foreign Key) est une colonne ou une combinaison de colonnes utilisée pour établir et appliquer un lien entre les données de deux tables.

Un lien est créé entre deux tables en ajoutant la ou les colonnes contenant les valeurs de clé primaire d’une table à l’autre table. Cette colonne devient une clé étrangère dans la deuxième table.

La table avec la clé primaire est appelée table parent et la table avec la clé étrangère est appelée table dépendante (ou table enfant ).

L’intégrité référentielle (RI) signifie que chaque ligne d’une table dépendante doit avoir une clé étrangère égale à une clé primaire dans la table parent.

Règles assurant l’RI :

Insert :

Lors de l’insertion d’une ligne avec une clé étrangère dans la table dépendante, DB2 vérifie les valeurs de la colonne de clé étrangère par rapport aux valeurs de la colonne de clé primaire dans la table parent. S’il existe une colonne de clé primaire correspondante, l’insertion est autorisée. S’il n’y a pas de colonne de clé primaire correspondante, l’insertion n’aura pas lieu.

Une nouvelle ligne peut être insérée dans la table parent tant que la valeur de clé primaire de la nouvelle ligne est unique.

Update :

Lors de la mise à jour des valeurs de clé étrangère dans la table dépendante, DB2 vérifie s’il existe ou non une clé primaire correspondante dans la table parent. S’il existe une clé primaire correspondante, la mise à jour est autorisée. S’il n’y a pas de clé primaire correspondante, la mise à jour n’est pas autorisée.

La clé primaire de la table parent ne peut pas être mise à jour si des lignes des tables dépendantes y font référence.

Delete :

La suppression d’une ligne avec une clé étrangère dans la table dépendante est autorisée.

Lors de la suppression d’une ligne avec une clé primaire dans la table parent, DB2 effectue l’une des actions suivantes comme indiqué lors de la définition de la table.

RESTRICT: 
Interdit la suppression de la ligne de clé primaire si des clés étrangères se rapportent à cette ligne.

CASCADE: 
Permet la suppression de la ligne de clé primaire et supprime également les lignes de clé étrangère qui s’y rapportent.

SET TO NULL: 
Autorise la suppression de la ligne de clé primaire et, au lieu de supprimer toutes les lignes de clé étrangère associées, définit les colonnes de clé étrangère sur NULL.

OpérationTableau enfantTableau parent
InsertAutorisé si la valeur de la clé étrangère correspond à la valeur de la clé primaire de la table parentAutorisé tant que la valeur de la clé primaire est unique
UpdateAutorisé si la valeur de la clé étrangère correspond à la valeur de la clé primaire de la table parentAutorisé s’il n’y a pas de références de clé étrangère dans les tables enfants
DeleteAutoriséSelon l’action spécifiée lors de la définition de la table

Restrict: non autorisé s’il existe des références de clé étrangère
Cascade : autorisé et supprime les références de clé étrangère, le cas échéant, dans les tables enfants
SET TO NULL : autorisé et une valeur Null sera définie dans les références de clé étrangère des tables enfants

Intégrité du domaine :

Il s’agit de “l’intégrité au niveau du champ” qui garantit que la structure de chaque champ est saine, que les valeurs de chaque champ sont valides, cohérentes et précises, et que les champs du même type (tels que les champs Ville) sont définis de manière cohérente dans toute la base de données.

L’intégrité du domaine est appliquée à l’aide de :

  • Type de données et longueur
  • Les valeurs par défaut
  • Valeurs NULL
  • Vérifier la contrainte

Type de données et longueur :

En spécifiant le type de données et la longueur maximale de chaque colonne lors de la création d’une table, le SGBD s’assurera automatiquement que seul le type de données correct avec la longueur maximale autorisée est stocké dans cette colonne.

Les valeurs par défaut:

Lorsque des colonnes sont créées dans des tables, on peut leur attribuer une valeur par défaut qui sera utilisée lors de l’insertion ou du chargement des données qui ne fournissent pas de valeur explicite pour cette colonne. Chaque colonne ne peut avoir qu’une seule valeur par défaut. L’utilisateur peut fournir une valeur par défaut pour une colonne. S’il n’y a pas de valeur par défaut spécifique à l’utilisateur, DB2 attribue la valeur par défaut en fonction du type de données de cette colonne.

Type de donnéesCOBOL PICCOBOL USAGEPar DéfautDescription
CHAR (n)PIC X(n)DISPLAYBlancsDonnées de caractères de longueur fixe (EBCDIC)
VARCHAR (n)PIC X(n)DISPLAYVide / NULLDonnées de caractères de longueur variable
SMALLINTPIC S9(4)COMP ou
COMP-4
0Entier de faible étendue
INTEGERPIC S9(9)COMP ou
COMP-4
0Entier habituel
DECIMAL (p,s)PIC S9(p)V9(s)
COMP-30Données d’un nombre décimal
p : nb de décimal avant la virgule
s : nb de décimal après la virgule
DATEPIC X(10)DISPLAYDate ActuelleDate (aaaa-mm-jj)
TIMEPIC X(8)DISPLAYHeure ActuelleHeure (hh.mm.ss)
TIMESTAMPPIC X(26)DISPLAYTimestamp ActuelleDate et Heure avec les microsecondes
(aaaa-mm-jj-hh.mm.ss.mmmmmm)
GRAPHICPIC G(n)DISPLAY-1BlancsChaîne de caractères à deux octets de longueur fixe
VARGRAPHICPIC G(n)DISPLAY-1Vide / NULLChaîne de caractères à deux octets de longueur variable avec indicateur de longueur de chaîne à 2 octets
FLOAT (n)N/ACOMP-1 ou
COMP-2
0Virgule flottante dans une simple ou double précision

Valeurs NULL :

Certaines colonnes ne peuvent pas avoir une valeur significative dans chaque ligne. DB2 utilise un indicateur de valeur spécial, la valeur nulle, pour représenter une valeur inconnue ou manquante. Une valeur nulle est une valeur spéciale que DB2 interprète comme signifiant qu’aucune donnée n’est présente.

Si vous ne spécifiez rien d’autre, DB2 autorise n’importe quelle colonne à contenir des valeurs NULL. Les utilisateurs peuvent créer des lignes dans le tableau sans fournir de valeur pour la colonne.

L’utilisation de la clause NOT NULL vous permet d’interdire les valeurs NULL dans la colonne. Les clés primaires doivent être définies comme NOT NULL.

Voyons un exemple pour bien comprendre :

Identifiant ProduitDescription ProduitCatégoriePrixStockValeur Totale
001ASport70.00
002B5.0020100.00
003CSport6.00100600.00
004DComposants23.5016376.00
005EOutils300.00
006F7.4517.45
Table PRODUITS

Si une valeur nulle est utilisée dans une expression mathématique, cette expression sera évaluée à Null. Dans la figure Produits, la Valeur Totale est dérivée de l’expression mathématique “[Prix] * [Stock].”

Notez cependant que la valeur du champ Valeur Totale est manquante là où la valeur Stock est Null, ce qui entraîne également une valeur nulle pour le champ Valeur Totale. C’est logiquement, si le nombre est inconnu, la valeur sera nécessairement inconnue.

De plus, une grave erreur non détectée se produit si toutes les valeurs du champ Valeur Totale sont ensuite additionnées : un total inexact. La seule façon d’obtenir un total précis est de fournir une valeur pour les entrées dans le champ Stock qui sont actuellement nulles.

Les fonctions d’agrégation telles que COUNT, SUM, AVG, MAX et MIN ne gèrent pas NULL de la même manière que les fonctions et opérateurs ordinaires. Au lieu de renvoyer NULL, ils ne prennent en compte que les champs non NULL lors du calcul du résultat.

Par exemple , Sum(Stock ) renvoie la valeur 137 (20+10+16+1). Si les six lignes avaient été additionnées, le résultat aurait été NULL.

Il existe une exception à cette règle : COUNT(*) renvoie le nombre de toutes les lignes, même les lignes dont les champs sont NULL. Mais COUNT(Name) se comporte comme les autres fonctions d’agrégation en ce sens qu’il ne compte que les lignes où le champ spécifié n’est pas NULL. COUNT(*) et COUNT(Name) ne renvoient jamais NULL. S’il n’y a pas de lignes dans la sortie, les deux fonctions renvoient 0. COUNT(Name) renvoie également 0 si tous les champs Name de la sortie sont NULL.

La figure suivante montre les résultats d’une requête récapitulative qui compte le nombre total d’occurrences de chaque catégorie dans la table PRODUITS présentée ci-dessus. La valeur du nombre total d’occurrences dans la requête récapitulative est le résultat de l’expression de la fonction “Count([Total Occurrences]).” Notez que la requête récapitulative affiche 0 occurrences d’une catégorie non spécifiée, ce qui implique qu’une catégorie a été attribuée à chaque produit. Ces informations sont clairement inexactes car il y a deux produits dans la table PRODUITS qui n’ont pas été assignés à une catégorie.

CatégorieTotal Occurrences
0
Sport2
Outils1
Composants1

Vérifier la contrainte :

Une contrainte de vérification est une règle qui spécifie les valeurs autorisées dans une ou plusieurs colonnes de chaque ligne d’une table. La contrainte de vérification applique les règles métier directement dans la base de données sans nécessiter de logique d’application supplémentaire. Cela peut être défini lors de la définition de la colonne.