DIRECTIVE N° 5/DEF/DGSIC portant sur les systèmes de gestion de base de données relationnelle.
Du 07 avril 2008NOR D E F M 0 8 5 0 7 2 1 X
1. Présentation générale et guide d'usage.
1.1. Présentation.
Cette directive précise les critères de choix pour l\'acquisition d\'un système de gestion de base de données relationnelle (SGBDR*) (1) et définit les règles de mise en oeuvre des SGBDR au sein du ministère de la défense. Elle s\'inscrit dans les missions de la direction générale des systèmes d\'information et de communication (DGSIC), aux termes du décret n° 2006-497 du 2 mai 2006 portant création de la direction générale des systèmes d\'information et de communication et fixant l\'organisation des systèmes d\'information et de communication du ministère de la défense.
Elle s\'inspire du cadre commun d\'interopérabilité [CCI] (2) du 4 décembre 2002, du projet de [RGI] dans sa version provisoire V0.98 de juin 2007 prévu par l\'ordonnance n° 2005-1516 [ORD] du 8 décembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives, et entre les autorités administratives. Elle décline la directive n° 1/DEF/DGSIC du 17 octobre 2006 portant sur les logiciels [DGSIC001] du ministère de la défense.
1.2. Niveau de préconisation.
Les règles définies dans ce document ont différents niveaux de préconisation et sont conformes au [RGI] et à la [RFC 2119] :
- obligatoire : ce niveau de préconisation signifie que la règle édictée indique une exigence absolue de la directive ;
- recommandé : ce niveau de préconisation signifie qu\'il peut exister des raisons valables, dans des circonstances particulières, pour ignorer la règle édictée mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente ;
- déconseillé : ce niveau de préconisation signifie que la règle édictée indique une prohibition qu\'il est toutefois possible, dans des circonstances particulières, de ne pas suivre mais les conséquences doivent être comprises et le cas soigneusement pesé ;
- interdit : ce niveau de préconisation signifie que la règle édictée indique une prohibition absolue de la directive.
1.3. Modalités d'application.
La présente directive s\'applique à l\'ensemble des SGBDR au sein du ministère de la défense à l\'exception des SGBD post relationnel* ou objet*. Ses règles définissent la cible et sont applicables à tout nouveau projet ou toute évolution majeure.
Les directions et services transposent les exigences de la présente directive dans les cahiers des charges des marchés publics relatifs aux SGBDR.
1.4. Gestion des dérogations pour les projets.
Elles sont instruites par la CMTSIC* et font l\'objet d\'une approbation par le directeur général de la DGSIC.
2. Cadre documentaire.
2.1. Documents applicables.
- [CCI] : recommandations nationales du cadre commun d\'interopérabilité.
- [RGI] : référentiel général d\'interopérabilité et [RGS] référentiel général de sécurité.
- [ORD] : ordonnance n° 2005-1516 du 8 décembre 2005.
- [PRIS] : politique de référencement intersectoriel de sécurité.
- [DGSIC001] : directive n° 1 sur les logiciels.
- [DGSIC002] : directive n° 2 sur le système d\'annuaires.
2.2. Normes et standards applicables.
- [ISO*/CEI 9075 1992*] : SQL*92 ou SQL2.
- [ISO/CEI 10646 2003*] : jeu universel de caractères codés sur plusieurs octets (UNICODE version 5.0.0).
- [REC-XML-19980210*] : spécifications XML* 1.0.
- [REC-XML11-20060816*] : spécifications XML 1.1 (seconde édition).
- [JSR-054*] : Java JDBC* 3.0 specification.
- [JSR-114*] : Java JDBC Rowset implementations.
3. Domaine couvert et emploi.
Un SGBDR est un ensemble de logiciels permettant de créer, gérer et interroger une base de données en s\'appuyant sur les principes de l\'algèbre relationnelle, quelque soit le domaine d\'application. Il est accessible de manière sécurisée et garantit la pérennité, l\'intégrité et la cohérence des données.
Le présent chapitre décrit les fonctionnalités que doit détenir un SGBDR.
3.1. Services attendus du système.
3.1.1. Support des concepts définis au niveau du modèle de données.
Le SGBDR doit permettre de représenter les propriétés des données par des définitions spécifiques ou des règles de cohérence, indépendamment de la représentation interne sous forme de fichiers.
3.1.2. Transparence du partage des données entre différents utilisateurs.
Le SGBDR doit permettre à plusieurs utilisateurs de pouvoir se servir de la base de façon concurrente et transparente. Cet aspect concerne aussi bien le respect des critères ACID* (atomicité, cohérence, isolation, durabilité) que l\'optimisation des performances (partage de la puissance du ou des processeurs par exemple).
3.1.3. Confidentialité des données.
Le langage SQL permet la définition des droits des utilisateurs en termes d\'accès, modification et suppression de tout ou partie des données. Le SGBDR doit être en mesure de supporter ces règles et donc permettre de se prémunir contre de mauvaises manipulations qu\'elles soient intentionnelles ou accidentelles.
3.1.4. Respect des règles de cohérence définies sur les données.
Toute modification des données provoquée par l\'utilisateur doit être réalisée dans le respect des règles de cohérence définies dans le schéma de données* considéré. Ces traitements font partie intégrante de l\'opération de mise à jour par le système dans le respect des critères ACID.
3.1.5. Disponibilité et cohérence des données.
Le SGBDR doit assurer la protection des données contre tout incident matériel ou logiciel qu\'il soit intentionnel ou fortuit. Il garantit à cette fin la cohérence de l\'information et des traitements en cas de panne.
Les applications peuvent être amenées à opérer des traitements longs sur d\'importants volumes de données. Les possibilités de panne en cours de traitement sont dans ce cas nombreuses. Le SGBDR doit alors fournir des mécanismes de reprise.
Pour les applications qui le nécessitent, le SGBDR est doté de mécanismes assurant une très haute disponibilité de la base tout en préservant sa cohérence.
3.1.6. Capacité de stockage élevé.
Le SGBDR doit garantir un niveau de performance optimal et gérer le volume de données adapté au besoin considéré. Les capacités des infrastructures informatiques tiennent compte de l\'augmentation croissante des besoins des utilisateurs en matière de stockage de données et de l\'essor des données multimédias (texte, image, son, vidéo).
3.1.7. Réponse aux requêtes avec un niveau de performances adapté.
Une requête est une recherche d\'information à effectuer sur une base de données. Elle peut s\'effectuer selon les caractéristiques descriptives de l\'information ou selon les relations entre les données.
Deux solutions sont envisageables en cas de problèmes de performance du système : augmenter la puissance des serveurs mais aussi décomposer la requête en opérations élémentaires. Dans ce dernier cas, l\'ordre d\'exécution des opérations en fonction de leurs propriétés (associativité, commutativité) et le regroupement de certaines opérations utilisant le même ensemble de données diminueront significativement le temps d\'exécution d\'une requête et, donc concourront à son optimisation.
3.1.8. Gestion des méta-données.
Le SGBDR doit fournir un catalogue dans lequel les méta-données sont décrites.
Les méta-données sont les données qui décrivent le schéma de la base de données (relations*, attributs*, contraintes*, vues*), les données (vues), les utilisateurs (identification, droits) et le système (statistiques). Elles doivent être accessibles à des utilisateurs ciblés (administrateurs). Ce type d\'information permet notamment à l\'administrateur ou au SGBDR lui-même d\'adapter la politique de stockage en fonction du contenu de la base de données.
3.2. Périmètre et limites.
Les SGBDR peuvent également offrir la possibilité d\'exécuter des procédures écrites au moyen d\'un langage propriétaire. L\'utilisation de procédures stockées écrites au moyen d\'un langage propriétaire est déconseillée afin de garantir l\'indépendance de l\'application vis-à-vis du SGBDR utilisé et de faciliter la gestion des compétences. Leur emploi éventuel est limité aux interventions d\'ordre technique (optimisation de performances, cohérence des données...).
3.3. Interopérabilité et interface.
3.3.1. Avec l'application.
Un accès standard de l\'application au SGBDR est recherché pour l\'indépendance entre les traitements et la gestion des données.
En environnement Java, le SGBDR doit disposer d\'un connecteur JDBC conforme à la norme 3.0.
3.3.2. Avec les autres systèmes de gestion de base de données relationnelle.
Les SGBDR ne sont pas nativement interopérables. L\'utilisation d\'un outil tiers (ETL*) est nécessaire pour réaliser l\'échange automatique de données entre SGBDR.
Les exportations de base de données au format XML doivent être privilégiées.
4. Les règles.
La directive est déclinée sous 3 angles : technique (RT), organisationnel (RO) et sémantique (RS) ; les règles sont numérotées séquentiellement par catégorie.
4.1. Règles techniques.
4.1.1. Administration.
- RT 01 : il est obligatoire que l\'outil implémente le standard SQL92* ou SQL2*.
- RT 02 : il est recommandé de disposer d\'un outil graphique d\'administration du serveur de base de données.
- RT 03 : il est recommandé de disposer d\'un outil graphique d\'administration des bases de données.
- RT 04 : il est obligatoire de disposer d\'un outil d\'administration global accessible en réseau par de multiples processeurs.
- RT 05 : il est obligatoire de disposer d\'un outil de configuration des accès.
- RT 06 : il est recommandé de disposer d\'un ordonnanceur de tâches autonome ou compatible avec un ordonnanceur tiers.
4.1.2. Pérennité des données.
- RT07 : il est obligatoire de disposer d\'un outil de sauvegarde / restauration.
- RT08 : il est obligatoire de disposer d\'un outil de récupération des données (à base de journaux log ou autres).
- RT09 : si une stratégie de réplication est mise en œuvre dans le cadre du secours, il est obligatoire de disposer d\'un outil de réplication fonctionnant en mode asynchrone.
4.1.3. Échanges.
- RT 10 : il est recommandé de disposer d\'un outil d\'importation / exportation des données en mesure de structurer l\'information sous format XML.
- RT 11 : il est recommandé de disposer d\'un outil de migration de base de données.
4.1.4. Analyse et optimisation de performance.
- RT 12 : il est obligatoire de disposer d\'outils qui permettent d\'analyser l\'activité du service de base de données.
- RT 13 : il est obligatoire de disposer d\'outils de mesure et d\'analyse des ordres SQL.
- RT 14 : il est recommandé de disposer d\'un outil de défragmentation de table et d\'index.
4.1.5. Sécurité.
- RT 15 : il est obligatoire de disposer d\'un moyen de gestion et de supervision des utilisateurs.
- RT 16 : il est recommandé de disposer d\'un moyen de chiffrement des données stockées.
4.1.6. Formation, support.
- RT 17 : il est obligatoire de disposer des moyens de formation en rapport avec la version du SGBDR utilisé.
- RT 18 : il est obligatoire de conserver la capacité de souscrire à un support technique adapté à la criticité de l\'application.
- RT 19 : il est obligatoire de sensibiliser l\'administrateur de bases de données à la sécurité des systèmes d\'information.
4.2. Règles organisationnelles.
4.2.1. Général.
- RO 01 : il est recommandé de décrire l\'organisation des données à l\'aide de modèles conceptuel et relationnel résultant d\'une analyse de type MERISE* ou basée sur UML 2.0.
- RO 02 : il est déconseillé d\'utiliser des bases de données réparties.
- RO 03 : il est déconseillé d\'utiliser les procédures stockées*.
4.2.2. Sécurité.
- RO 04 : il est obligatoire d\'authentifier les administrateurs et les utilisateurs.
- RO 05 : il est recommandé de tracer les actions des administrateurs.
- RO 06 : il est obligatoire de mettre en œuvre une politique de gestion des correctifs du SGBDR.
- RO 07 : il est recommandé de filtrer les ports utilisés par le SGBDR.
- RO 08 : il est obligatoire de changer les mots de passe par défaut et de désactiver ou supprimer les comptes inutiles.
- RO 09 : il est obligatoire de sécuriser les accès distants des administrateurs au SGBDR (chiffrement des flux...).
4.3. Règles sémantiques.
Sans objet.Pour le ministre de la défense et par délégation :
Le directeur général des systèmes d'information et de communication,
Henri SERRES.
Annexes
Annexe I. Glossaire et acronymes.
ACID :
- A comme atomicité :
une transaction s\'effectue ou pas (tout ou rien), il n\'y a pas de demi-mesure. Par exemple l\'augmentation des prix de 10 p.100 de tous les articles d\'une table des produits ne saurait être effectuée partiellement, même si le système connaît une panne en cours d\'exécution de la requête. En clair, si tout se passe correctement, toutes les actions de la transaction sont validées sinon, on retourne à l\'état initial ;
- C comme cohérence :
le résultat ou les changements induits par une transaction doivent impérativement préserver la cohérence des données. Par exemple lors d\'une fusion de société, la concaténation des informations des clients des différentes entités ne doit pas entraîner la présence de plusieurs clients ayant le même identifiant ;
- I comme isolation :
les transactions sont isolées les unes des autres. Par exemple la mise à jour des prix des articles ne sera visible pour d\'autres transactions que si ces dernières ont démarré après la validation de la transaction de mise à jour des données. Il n\'y aura donc pas de vue partielle des données pendant toute la durée de la transaction de mise à jour. En clair, les effets de la transaction ne sont pas perceptibles tant que celle-ci n\'est pas terminée ; une transaction n\'est pas affectée par le traitement d\'autres transactions ;
- D comme durabilité :
une fois validée, une transaction doit perdurer, c\'est-à-dire que les données sont persistantes même s\'il s\'ensuit une défaillance dans le système. Par exemple, dès lors qu\'une transaction a été validée, comme la mise à jour des prix, les données modifiées doivent être physiquement stockées pour qu\'en cas de panne, ces données soient conservées dans l\'état où elles ont été spécifiées à la fin de la transaction.
Attribut : dans une base de données, dénomination d\'un élément d\'une ligne (ou enregistrement) d\'une table.
Bean : dans le monde Java, un Bean est un composant logiciel réutilisable qui, pour obtenir ce « label », doit respecter certaines conventions sur le nommage des méthodes, la construction et le comportement.
Clé étrangère : représente la référence d\'une clé primaire dans une autre table.
Clé primaire : élément permettant d\'identifier comme unique une ligne (ou enregistrement) d\'une table.
CMTSIC : commission ministérielle technique des systèmes d\'information et de communication.
Commission ministérielle spécialisée instaurée par l\'arrêté DEFD0600690A du 6 juin 2006.
Contrainte : une contrainte est une clause activée lors de la modification d\'une table afin de garantir des exigences telles que l\'intégrité des données. À titre d\'exemple, une clé primaire ne peut pas être nulle ; une tentative d\'insertion d\'une ligne dont la clé est nulle sera refusée par le SGBDR.
ETL : extract, transform and loading. Outil permettant d\'extraire les informations d\'une base de données, de les modifier et d\'alimenter une autre base de données. L\'ETL est également utilisé pour les migrations de données entre systèmes opérants, les opérations de reprise de données existantes et les projets de consolidation de référentiels métiers.
Intranet : utilisation des technologies de l\'internet à des fins internes à une entreprise. L\'intranet permet de bénéficier de l\'économie d\'échelle acquise par les logiciels sur l\'internet et d\'outils de développement orientés « Objet ». On peut réaliser maintenant sur l\'intranet la totalité des applications métiers et services communs. L\'intranet nécessite une administration soigneuse des droits d\'accès.
ISO : organisation internationale de normalisation, non gouvernementale, qui constitue un réseau d\'instituts nationaux de normalisation de 157 pays, selon le principe d\'un membre par pays.
ISO/CEI 9075 1992 : révision majeure du langage normalisé et standardisé SQL.
Elle est connue sous le nom de SQL2 ou SQL-92.
ISO/CEI 10646 2003 : normalise le jeu universel de caractères codés sur plusieurs octets. Elle s\'applique à la représentation, à la transmission, à l\'échange, au traitement, au stockage, à la saisie et à la présentation des langues du monde sous forme écrite et de symboles complémentaires.
IP : internet protocol.
Protocole de communication correspondant globalement au niveau 3 du modèle OSI. Protocole utilisé par le réseau Internet et sur les réseaux intranet et extranet.
JDBC : java database connectivity.
Ensemble de classes « Java » qui permet aux applications développées selon cette technologie d\'accéder par le biais d\'une interface commune à une base de données relationnelle pour laquelle il existe un pilote JDBC.
JSR-054 : java spécification request n° 54, éditée sous l\'égide de la société Sun, décrivant la norme JDBC 3.0 qui introduit, entre autres, la notion d\'ensemble de connexions partagées (pool de connexions).
JSR-114 : Cette JSR complète la JSR-054 en encapsulant l\'accès aux données dans un seul bean* nommé rowset.
MERISE : méthode française de conception des systèmes d\'information.
Elle a comme objectif de jeter un pont entre les besoins des utilisateurs et les solutions des informaticiens. Sa finalité est de faciliter la conception des projets informatiques en permettant d\'analyser et de formaliser très tôt les besoins des utilisateurs
MCD : modèle conceptuel des données.
Dans la méthode MERISE, le MCD se matérialise par un schéma représentant la structure du système d\'information du point de vue des données. Ainsi sont décrites les dépendances ou les relations entre les différentes données (par exemple : le client, la facture, la ligne de la facture).
MPD : modèle physique des données.
Le MPD est issu du MCD. Il permet la conception des bases de données et la mise en œuvre de structures physiques et de requêtes portant sur les données
Objet : ce sont des données, des caractéristiques propres à un élément qui ont été regroupés dans une entité appelée « Objet ».
Il existe des langages « Objet » ou orientés « Objet » comme « Java ». « L\'Objet » rassemble alors les données et les procédures qui sont membres de l\'entité.
Procédure stockée : ensemble d\'instructions écrit en langage propriétaire (PL/SQL pour Oracle) et stocké directement dans la base de données. Une procédure stockée peut être lancée directement par l\'utilisateur ou de façon automatique par un évènement déclencheur.
REC-XML-19980210 : recommandation du W3C* concernant le langage de balisage extensible XML en version 1.0.
REC-XML11-20060816 : recommandation du W3C concernant le langage de balisage extensible XML en version 1.1.
Relation : dans un schéma de base de données relationnelle, une relation désigne une table qui contient des données organisées par affinité. Une relation désigne également un lien entre deux tables caractérisé généralement par un couple clé primaire* - clé étrangère*.
Schéma de données : le schéma de données concerne tout ce qui a trait à la donnée dans un système d\'information. Il revêt deux formes selon que l\'on se place au niveau de l\'analyse ou au niveau du SGBDR. Dans le premier cas, il prend le nom de schéma ou modèle conceptuel des données et son aspect visuel constitue un support / moyen de communication entre les différents acteurs du projet (fonctionnels et techniques). Le second cas découle du premier et se nomme schéma ou modèle physique des données. Il représente un ensemble de structures logiques et cohérentes adapté au SGBDR utilisé.
SGBD post relationnel : SGBD implémentant la norme SQL3 ou SQL-99 qui introduit des notions propres à « l\'Objet ».
SGBD Objet : système de gestion de base de données qui stocke et restitue les informations au format purement « Objet ». Cette technologie est en phase avec le principe du développement « Objet ».
SGBDR : système de gestion de base de données relationnelle.
Une base de données construite selon le modèle relationnel stocke les informations dans des structures tabulaires à deux dimensions formées de colonnes et d\'enregistrements. Chaque colonne représente un domaine de valeurs et les valeurs des colonnes d\'un même enregistrement entretiennent une relation. Des relations sont également définies entre les tables ; elles permettent d\'obtenir rapidement une vue logique des informations.
SQL : structured query language ou langage structuré de requêtes.
Le SQL est un pseudo langage informatique de type requête standard et normalisé, destiné à interroger ou à manipuler une base de données relationnelle. SQL a été adopté comme recommandation par l\'institut de normalisation américaine (ANSI) en 1986, puis comme norme internationale par l\'ISO en 1987 sous le nom de ISO/CEI 9075, technologie de l\'information, langage de base de données, SQL.
SQL92 ou SQL2 : version du langage SQL synthétisant le mieux le modèle relationnel. À ce jour, c\'est la version la mieux implémentée par les éditeurs de SGBDR.
Vue : une vue est un objet virtuel de la base de données (une table temporaire par exemple).
XML : extensible markup language ou langage de balisage extensible.
Méta-langage, standardisé par le W3C, permettant de décrire et de structurer des données de manière hiérarchisée au moyen de balises.
W3C : world wide web consortium.
Le W3C est un consortium fondé en octobre 1994 pour promouvoir la compatibilité des technologies liées à Internet. Le W3C émet des recommandations qui ont valeur de standards auprès des industriels.
Annexe II. Références.
[CCI] : recommandations nationales du cadre commun d\'interopérabilité des systèmes d\'information publics. Circulaires du Premier Ministre du 21 janvier 2002 et du 4 décembre 2002.
[RGI] : référentiel général d\'interopérabilité défini par ordonnance n° 2005-1516 du 8 décembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives, et entre les autorités administratives.
[ORD] : ordonnance n° 2005-1516 du 8 décembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives et entre les autorités administratives.
[DGSIC001] : directive n° 1/DEF/DGSIC du 17 octobre 2006 portant sur les logiciels du ministère de la défense.
[DGSIC002] : directive n° 2/DEF/DGSIC du 9 mars 2007 portant sur le système d\'annuaire du ministère de la défense.
[RFC 2119] : key words for use in RFCs to indicate requirement levels (best current practice 03/1997).
[ISO*/CEI 9075 1992*] : SQL*-92 ou SQL2.
[ISO/CEI 10646 2003*] : jeu universel de caractères codés sur plusieurs octets (UNICODE version 5.0.0).
[REC-XML-19980210*] : spécifications XML* 1.0.
[REC-XML11-20060816] : spécifications XML 1.1 (seconde édition).
[JSR-054*] : java JDBC* 3.0 specification.
[JSR-114*] : java JDBC rowset implementations.