207 lines
7.4 KiB
TeX
207 lines
7.4 KiB
TeX
\chapter{Introduction}
|
|
|
|
\section{Définitions}
|
|
|
|
Une base de données, c'est collection de données qui reflète un aperçu du monde
|
|
réel.
|
|
|
|
Le SGBD c'est tout le système logiciel qui gére au moins une base de
|
|
données. Il peut être mono ou multi-utilisateur (plutôt multi). Il peut être
|
|
mono ou multi-utilisateur
|
|
|
|
Les plus utilisés~:
|
|
\begin{itemize}
|
|
\item Oracle
|
|
\item Microsoft SQL Server
|
|
\item IBM db2
|
|
\item Sybase
|
|
\item ...
|
|
\end{itemize}
|
|
|
|
\begin{itemize}
|
|
\item PostgreSQL
|
|
\item MySQL
|
|
\end{itemize}
|
|
|
|
En Français, on appelle \textbf{banque de données} une base de données et le
|
|
système de gestion ainsi que ses services associés.
|
|
|
|
\section{Objectifs et fonctions d'un SGBD}
|
|
|
|
Un SGBD sert principalement à séparer les données du programme dans le but
|
|
d'armoniser les données. On ne veut pas de redondances des données (partage
|
|
limité au niveau des fichiers, problèmes de cohérences globale (stocker deux
|
|
informations contradictoires)).\\
|
|
|
|
Le SGBD s'occupe de la gestion du stockage et assure l'interface entre les
|
|
programmes et les données. L'accès se fait au moyen d'un langage déclaratif, on
|
|
appelle cela une requête.
|
|
|
|
Les requêtes sont regroupées en transations qui sont atomiques (tout est
|
|
exécuté ou rien).
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Indépendance des programmes aux données~:} d'un point de vue du
|
|
développeur, on ne sait pas où les données sont stockées ni comment elles
|
|
le sont.
|
|
\item \textbf{Simplicité~:} utilisation d'un langage non procédural.
|
|
\item \textbf{Efficacité des accès aux données~:} temps de réponse proche
|
|
d'une application dédiées. Les débits globaux sont très bons maintenant.
|
|
\item \textbf{Partage et sécurité~:} multi-utilisateurs avec des droits très
|
|
fins. Tout le monde ne peut pas faire des modifications ou lire
|
|
toutes les données.\\
|
|
Gestion de la concurence des transactions.
|
|
\item \textbf{Conception facilité des applications~:} sauvegarde facilité des
|
|
données. Redondance contrôlée des données.
|
|
\item \textbf{Facilité de l'administration des SGBD~:} conception visuelle
|
|
des BDD, outils d'audit et de tunning, statistiques, \ldots
|
|
\end{itemize}
|
|
|
|
\subsection{Langages des SGBDs}
|
|
|
|
\subsubsection{Langage de définition des données}
|
|
|
|
Définition de la base, des tables, les types des champs, etc.
|
|
|
|
\subsubsection{Langage de manipulation de données}
|
|
|
|
Il peut être autonome comme SQL ou intégré dans un langage de programmation.
|
|
|
|
\subsection{Utilisateurs d'un SGBD}
|
|
|
|
\paragraph{L'utilisateur final} il va effectuer des recherches, accéder à la
|
|
base par des interfaces applicatives ou web. Voire utiliser des langages
|
|
simples comme QBE.
|
|
|
|
\paragraph{Le programmeur d'application} Spécialiste SQL, conçoit et implémente
|
|
des applications qui accédent à la BD
|
|
|
|
\section{Architecture d'un SGBD}
|
|
|
|
Premièrement, on doit avoir un gestionnaire de disques ou de fichiers (si on se
|
|
sert du système de fichiers du système). Mais les objectifs ne sont pas les
|
|
mêmes, ce n'est pas le bon choix.
|
|
|
|
La partie interne va gérer la communication, gestionnaire de verrou,
|
|
réwcupération en cas de panne, \ldots
|
|
|
|
La partie externe va faire l'interface avec les applications.\\
|
|
|
|
|
|
On trouve 4 grands modules~:
|
|
\begin{itemize}
|
|
\item \textbf{L'évaluateur de requête~:} parse, planifie, évalue les
|
|
opérateurs, optimisation
|
|
\item \textbf{Gestion de la concurence~:} gestionnaire des transaction et des
|
|
verrous
|
|
\item \textbf{Récupération en cas de panne}
|
|
\item \textbf{Gestion des données~:} gestionnaire de l'espace disque, du
|
|
tampon, méthode d'accès et fichiers.
|
|
\end{itemize}
|
|
|
|
Le \textbf{catalogue} est une base de données contenant des données sur les
|
|
bases de données~: type des colonnes, tables, \ldots
|
|
|
|
\subsection{Objectifs du gestionnaire de transaction}
|
|
|
|
Il préserve les propriétés \textbf{acid} des transactions~:
|
|
\begin{itemize}
|
|
\item Atomicité~: tout est exécuté correctement ou rien (du coup, annuler :D)
|
|
\item Cohérence de la base~: toutes les conditions des tables doivent être
|
|
validées.
|
|
\item Isolation~: on fait comme si l'on était seul dans la base.
|
|
\item Durabilité~: gérer tous les cas de pannes, \ldots
|
|
\end{itemize}
|
|
|
|
Il doit aussi gérer les verrous et les journaux.
|
|
|
|
\section{Organisation d'une BD}
|
|
|
|
On distingue trois niveaux~:
|
|
\begin{itemize}
|
|
\item Niveau interne~: on a des fichiers dans lesquelles les données sont
|
|
stockées.
|
|
\item Niveau conceptuel~: il s'occupe de la modélisation du monde réel, en
|
|
prennant appuis sur le niveau interne pour regrouper les données.
|
|
\item Niveau externe~: on a des shémas externes, c'est à destination de
|
|
l'utilisateur. Cela ne correspond pas toujours à ce qui est enregistré dans
|
|
les fichiers (prix HT/TTC par exemple).
|
|
\end{itemize}
|
|
|
|
\section{Histoire des SGBD}
|
|
|
|
\subsection{Modéle hiérarchique (fin des années 60)}
|
|
|
|
IBM lança IMS. Les associations entre les données sont représentées par un
|
|
arbre. Chaque enregistrement possède une clé~; dans l'arbre, chaque
|
|
enregistrement a un seul père.
|
|
|
|
On a beaucoup de redondance d'informations (un même client qui achète deux
|
|
produits par exemple).
|
|
|
|
\subsection{Modèle réseau (années 70)}
|
|
|
|
Ce modèle a été proposée par Richard Bachman. Elle a été implémentée par
|
|
Honeywell sous le nom IDS, standardisée en 1969.
|
|
|
|
Les associations entre les données sont représentées par un graphe.
|
|
|
|
Beaucoup de problématique ne sont pas gérées comme la dépendance d'éléments.
|
|
|
|
\subsection{Modèle relationnel (1970-80)}
|
|
|
|
C'est Ted Codd qui définit ce modèle lorsqu'il travaillait pour IBM. Il s'en
|
|
suit deux projets majeurs~:
|
|
\begin{itemize}
|
|
\item \textbf{INGRES~:} à l'université de Berkley. Par la suite PostGreSQL
|
|
\item \textbf{System R.~:} dans un labo d'IBM, qui deviendra le produit DB2
|
|
qui inspira Oracle.
|
|
\end{itemize}
|
|
|
|
Le succès du modèle relationnel tient dans l'implémentation multi-plateforme
|
|
car son concurent~: le modèle réseau qui ne fonctionnait que sur les mainframe
|
|
d'IBM exclusivement.\\
|
|
|
|
De nombreux points de Ted Codd ont cependant été abandonnées~: le langage de
|
|
base (alpha) était très mathématique et peu adapté. Au final, la première norme
|
|
de SQL est parrue en 86.
|
|
|
|
\subsection{Modèle entité/association}
|
|
|
|
Proposé par Peter Chen~: chaque enregistrement est une entitée qui sont reliées
|
|
entre-elles par des associations. Personne n'a implémentés ces idées, seul
|
|
l'outils de modélisation a été conservé.
|
|
|
|
\subsection{Modèle R++, Relationel++}
|
|
|
|
Nouvelles briques~: notion d'attribut d'un certain type (couleur issue d'un
|
|
ensemble particulier: un domaine), aggrégation, \ldots
|
|
|
|
Pas non plus de grand succès. Mais le modèle relationel a absorpé pas mal de
|
|
concepts.
|
|
|
|
\subsection{Modèle sémantique}
|
|
|
|
Notion d'héritage, de classe, de propriétés, poussant le modèle relationnel à
|
|
implémenter de la gestion objet.
|
|
|
|
\subsection{Modèle orienté objet}
|
|
|
|
Reprise des idées du modèle sémantique. Implémentée par une société française
|
|
(O2) par François Bancilhon. Il crée un langage déclaratif OQL.
|
|
|
|
La compta de l'école est toujours gérée sous Orion \o/
|
|
|
|
Le problème de la boîte fut qu'elle soit française~!
|
|
|
|
\subsection{Modèle relationnel objet}
|
|
|
|
Débuté avec l'intérêt d'INGRES.\\
|
|
|
|
C'est actuellement le modèle actuel.
|
|
|
|
\subsection{Recherches actuelles}
|
|
|
|
XML, Internet et web, multimédia, aide à la prise de décision, interrogation
|
|
par le contenu d'objet multimédia, système d'informations géographique.
|