Conception et

Administration des
Bases de Données
Conservatoire National des Arts et
Métiers
Aix-en-Provence

Olivier Michelet
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Les systèmes de gestion de bases de données
– Les bases de données, SGBD, Définitions
●
Conception et modélisation des Bases de Données
– La modélisation conceptuelle de données : Le modèle Entité – Association
– La normalisation
– Du modèle conceptuel au modèle relationnel
●
Architecture d’une base de données Relationnelle
– Rappels : Les systèmes de fichiers
– La Structure Physique – La Structure Logique – Le Schéma
●
Architecture d’un SGBDR
– Analyseur syntaxique, Optimiseur de Requêtes, Gestionnaire des Transactions,
Accès Concurrents, Principe de verrouillage des Données, Sécurité / Reprise
●
Mise en œuvre d’une base de données relationnelle
– Algèbre Relationnelle – Opérations Logiques
– Création / Manipulation de Bases de Données
●
Administration / Optimisation / Sécurité / Règles de programmation
●
Approche de la gestion des SI répartis et fédérés
●
Nouvelles technologies et Bases de Données
Olivier Michelet 2
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Administration d’une Base de Données

●
Optimisation
– Physique
– Logique

●
La Gestion de la Sécurité

●
Règles élémentaires de programmation

Olivier Michelet 3
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Administration d’une Base de Données

Cette fonction constitue une activité à part entière dans le Système d’Information de
l’Entreprise.
Cette tâche est dévolue en général à une personne, l’Administrateur de Bases de
Données.

Les principales missions du DBA (DataBase Administrator) sont :

la surveillance du système (temps d’accès, blocages –dead locks-, libération des
ressources)
l’optimisation des bases (gestion des volumes, index, travaux de maintenance, 6)
la garantie de bon fonctionnement (utilisation CPU, mémoire, 6)
la mise en place et l’exploitation de procédures de reprise (sauvegardes,
restaurations, 6)
le conseil au développement (définition et optimisation des schémas, règles de
codage, 6)
la mise en œuvre de la sécurité applicative (authentification, contrôles 6)
la veille technologique (évolution des technologies, ouverture sur plusieurs
systèmes)
Olivier Michelet 4
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Optimisation

– Physique
Elle doit satisfaire un ensemble de règles « triviales ».
Il faut disposer de :
- un serveur performant, de préférence multi-CPU et suffisamment de mémoire (!!!)
- disques optimisés (rapides, avec des temps d’accès en lecture minimes, une
gestion des caches en écriture, de l’espace libre pour gérer les
insertions/suppressions et les index, des systèmes RAID)
- une configuration réseau adéquate (éventuellement multiplier les cartes6)
Il faut spécialiser le serveur qui héberge le SGBD. Il ne doit pas occuper d’autre fonction.
Notamment, il est préférable que toute la partie applicative (serveur de présentation) soit
exécutée sur une autre machine.
Il faut également installer les fichiers des différentes fonctions sur des disques physiques
distincts.
- un disque pour le système d’exploitation, un autre pour la mémoire virtuelle (swap)
- un (ou plusieurs) pour les bases et un dernier pour les fichiers de log

Olivier Michelet 5
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Optimisation

– Logique
Elle doit suivre les règles suivantes :
- créer les bases avec leur taille en « régime de croisière » (éviter les processus de
croissance auto)
- adapter les tailles de pages de données (si possible) aux capacités de la machine
- une seule opération d’ouverture/fermeture de base par session
- utilisation des index appropriés
- il faut positionner les index nécessaires mais pas trop 6
- ne pas faire exécuter par le SGBD des fonctions applicatives « externes » (calculs,
conversions6)
- pas de requête « inutile »
- accéder uniquement les données (et les bases) nécessaires
- ne pas verrouiller de données inutilement (SELECT FOR UPDATE 6 sans update)
- adaptez vos besoins à la réalité (pas de champs BLOB s’il existe une autre solution)
- favorisez l’intégrité référentielle, les procédures stockées, les déclencheurs
Olivier Michelet 6
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Optimisation

– Logique
- Réindexer régulièrement les bases, faire générer les statistiques
- Défragmenter régulièrement les disques et les bases, compacter les données
- Laisser suffisamment de place libre sur les bases
- Utiliser les outils standards pour optimiser le code produit (explain, utilisation de
index, plans choisis 6)
- Forcer éventuellement l’utilisation d’un index et ne pas laisser le choix au SGBD
dans vos requêtes

Olivier Michelet 7
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Règles élémentaires de programmation

– Normaliser au maximum

– 6 mais dénormaliser si cela fait gagner du temps (jointures)

– Indexer le plus possible, mais judicieusement (pas d’excès)

– Utiliser les types et formats de données adaptés au besoin (pas de champ variable,
si possible)

– Pas de valeur NULL sur des colonnes de calcul (NULL est l’élément absorbant)

– Eviter les clés composites (si possible)

– Pas de SELECT (*) , énumérer les colonnes choisies SELECT col1, col2, 6

– Pas de SELECT COUNT(*) mais SELECT COUNT(NomCol)

– Pas de DISTINCT s ’il n’y a pas de doublon possible dans le résultat (sur des clés
par exemple)

Olivier Michelet 8
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Règles élémentaires de programmation

– Utiliser EXISTS plutôt que COUNT(*) ou IN

– Ramener le minimum d'occurrences dans les jointures (utilisation de la clause

WHERE)

– N’effectuez de jointure que si cela est strictement nécessaire

– Evitez de faire effectuer au SGBD des fonctions autres que les siennes (6)

– Utiliser BETWEEN pour comparer sur des intervalles

– Utiliser IN(val1,val2, 6) pour des valeurs distinctes et non discrètes

– Evitez les requêtes coûteuses (LIKE ‘%... », NOT LIKE 6, OR6) qui n’emploient
pas d’index

– Servez-vous des vues, pas d’ORDER BY si non nécessaire (sur des clés par
exemple6)

Olivier Michelet 9
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
Règles élémentaires de programmation

– NOT IN est peu performant, aucun index utilisé, lui préférer le NOT EXISTS

– La résolution OR est consommatrice de ressources

– Effectuer des équi-jointures sur des colonnes non transformées

– Evitez les expressions mixant des types de données distincts

– L'utilisation de conversions annule l'utilisation d'index (to_char, to_date,...)

Olivier Michelet 10
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Comme dans tout système d’information, l’accès aux données d’un SGBD doit être
particulièrement surveillé et doit garantir non seulement leur intégrité mais également
leur confidentialité.
La gestion de la sécurité est établie par l’authentification des accès :
- à la base
- aux tables
- aux vues
- aux procédures
- au schéma
en lecture, en écriture, ou interdite.
C’est le DBA qui est généralement garant de la gestion des accès selon les règles
établies par l’utilisateur responsable des données.
Aucun accès ne doit pouvoir avoir lieu sans l’autorisation explicite du propriétaire des
données.
Les environnements de développement suivent généralement des règles de sécurité
beaucoup plus souples, aucune donnée sensible ne devant y être conservée, pour
garantir une certaine liberté dans les développements.

Olivier Michelet 11
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Autorisations d'accès

* Le créateur d'une table (ou d'une vue) en est le propriétaire.

* Par défaut, les autres utilisateurs n'ont pas accès à ces objets (ni interrogation, ni mise
à jour).
* Le propriétaire d'une table ou d'une vue peut autoriser d'autres utilisateurs à effectuer
certaines opérations.
* Seul le droit de suppression (DROP VIEW ou DROP TABLE) ne peut se céder.

Olivier Michelet 12
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Autorisations d'accès

GRANT liste de droits

ON objet
TO liste d'utilisateurs
[WITH GRANT OPTION];

Les droits

SELECT, ALTER, UPDATE, INDEX, INSERT, DELETE

ALL

UPDATE peut être suivi d'une liste de colonnes

ALL autorise toutes les opérations (sauf DROP)

Olivier Michelet 13
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Autorisations d'accès

Les objets : table ou vue

pour donner un droit à tous les utilisateurs, il faut préciser PUBLIC au lieu d'une liste
d'utilisateurs

WITH GRANT OPTION donne en plus la possibilité de transmettre le droit

Olivier Michelet 14
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Autorisations d'accès

REVOKE liste de droits

ON objet
FROM liste d'utilisateurs;

• commande symétrique de GRANT

• un droit ne peut être retiré que par l'utilisateur qui l'a accordé (ou par le DBA)
• si le droit avait été transmis avec l'option WITH GRANT OPTION, la suppression est
effectuée en cascade

Exemple : interdire toute opération à tout utilisateur sur la table F

REVOKE ALL ON F
FROM PUBLIC;

Olivier Michelet 15
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité

Autorisations d'accès

Exemple : interdire toute opération à tout utilisateur sur la table F

REVOKE ALL
ON F
FROM PUBLIC;

Olivier Michelet 16
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité – les bonnes pratiques

Authentification
SQL supporte deux modes d’authentification : l’authentification interne au SGBD et
l’authentification déléguée à un annuaire. Il est conseillé et préférable de choisir
l’authentification par annuaire à moins que les applications existantes ne le supporte
pas.
L’authentification LDAP est plus sécurisée que le mode natif.
Lorsqu'elle est activée, les tickets Kerberos sont considérés comme des connexions
fiables. Les identifiants utilisent une série de messages chiffrés pour permettre de
s'authentifier et les mots de passe ne transitent pas par le réseau lors de
l’authentification.
Ainsi l’authentification est plus fiable et sa gestion minimale via les groupes de l'annuaire
pour gérer les accès par rôle (ou profil).
Dans le mode natif, les mots de passe pour SQL sont transmis à travers le réseau, les
identifiants sont ainsi moins bien protégés.

Olivier Michelet 17
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité – les bonnes pratiques

Révoquer les accès des utilisateurs invités

Par défaut, un utilisateur invité est présent dans tous les systèmes de base de données,
ce qui représente un risque potentiel pour tout environnement fermé, car il ouvre un
accès aux identifiants qui ne sont pas associés à un utilisateur dans la base de
données.
A cause de ce risque, il convient de désactiver l’accès à l’utilisateur invité pour tous les
utilisateurs et les bases (sauf bases systèmes nécessaires).
Cela permet de garantir que les membres du rôle serveur public n’ont pas accès aux
comptes utilisateurs sur les instances SQL, sauf si des accès leur ont explicitement été
attribués.

Réduire la surface d'attaque de SQL

Désactivez les fonctions non souhaitées lors de ou après l’installation via la configuration
de la surface du système.

Olivier Michelet 18
 CNAM Aix en Provence -
Conception et Administration des Bases de Données

●
La Gestion de la Sécurité – les bonnes pratiques

Renforcer les ports SQL

Une autre bonne pratique en matière de sécurité consiste à changer les ports par défaut
associés à l’installation du SGBD ou des instances.
Utilisez des ports TCP spécifiques au lieu des ports dynamiques.

Olivier Michelet 19