Charactéristiques du SGBD

Avnt de modéliser, la base de données, il est important de connaître les caractéristiques du SGBD :

• gestion des clés primaire : quel est la philosphie du SGBD en ce qui concerne les clé primaires? Certaines base de données utilisent des auto-incrément (MySQL, SQL Server,...) d'autres des séquences comme Oracle.
• gestion des transaction : le SGBD est-il capable de gérer les commit/rollback?
• le SGBD est-il capable de gérer le Scrollable au niveau des Resultset (qui permet alors de paginer des enregistement au niveau de la base de donnée)? Oracle par exemple ne supporte pas le Scrollable.

Gestion des clés

Avant tout développement d'une application, il est important de modéliser la base de données. La plupart des tables doivent être constituées d'une clé primaire, ce qui permet d'identifier un enregistrement de la table. Prenons l'exemple d'un collaborateur modélisé par la table T_COLLABORATEUR. Un collaborateur est identifié par son login, autrement dit le login doit être unique dans la table.

Il existe deux façons de modéliser cette table :

• mettre la colonne login en tant que clé primaire. La colonne login constitue une clé métier. Cette modélisation permet de garantir l'unicité du login dans la table T_COLLABORATEUR. Cependant cette solution pose problème lors de la modification du login d'un collaborateur. En effet toutes les autres tables faisant référence à la table T_COLLABORATEUR devront aussi être modifiées.
• mettre une colonne id en tant que clé primaire. La colonne id constitue une clé technique. Cette modélisation ne garantit pas l'unicité du login, mais permet de modifier le login sans se soucier des autres tables qui feraient référence à T_COLLABORATEUR. L'unicité du login devra être gérée aux niveau applicatif.

GestCV appliquera la modélisation de tables par clé technique.

Modèle Physique de données

Voici le MPD de la base GestCV :

La modélisation des tables T_USER, et T_COLLABORATEUR_COMPETENCE peuvent apparaître à premier abord choquant. En effet, ces tables ne contiennent pas de clé primaires mais une clé étrangère :

• Conceptuellement, un utilisateur T_USER est un collaborateur T_COLLABORATEUR. La table T_USER à une clé étrangère USR_ID_N sur la clé primaire COL_ID_N de la table T_COLLABORATEUR. En SQL pur (JDBC), pour insérer un utilisateur ceci nécéssite d'effectuer 2 requêtes SQL INSERT (une dans la table T_COLLABORATEUR et une dans la table T_USER). Ceci peut s'avérer pénible à développer, mais Hibernate gère très bien ce mécanisme d'héritage; pour le développeur, ces 2 INSERT seront transparents.
• Conceptuellement, les compétences d'un collaborateur T_COLLABORATEUR_COMPETENCE est une rubrique T_RUBRIQUE. Ici encore, le mécanisme d'héritage sera utilisé.