MySQL est un excellent SGBD pour commencer à travailler sur des aspects un peu plus avancés que les simples requêtes SQL.
Le minimum requis pour commencer à travailler avec SQL est de comprendre et maîtriser les deux parties :
Ces deux parties sont très proches entre les différents SGBD et elles sont le minimum nécessaire pour tout développeur des applications de gestion (les applications destinées au système opérant si on opte pour l'ancien modèle, et pour le système opérant et la ligne hiérarchique si on opte pour le modèle de Mintzberg).
Pour maîtriser ces deux niveaux, tout SGBD peut faire la tâche de plus petit comme SQLite, Microsoft Access, OpenOffice Base au plus grand Oracle, PostgreSQL, Microsoft SQL Server.
Néanmoins, cette ensemble de commande n'est pas suffisant pour un Administrateur des Bases des Données. Il faut maîtriser des commandes supplémentaires pour pouvoir voir plus loin et plus profond à l'intérieur du SGBD pour pouvoir mieux gérer une base des données et garantir, ainsi, un bon fonctionnement des applications.
Un SGBD n'est pas un simple module de gestion des fichiers : il garantit la gestion des bases des données avec toutes les contraintes qu'elles présentent et en permettant un accès concurrent tout en essayant de rester efficace (en terme d'espace de stockage et en terme de temps de réponse). Pour garantir ces fonctionnalités, il était nécessaire d'opter pour une architecture en couche :
La "visibilité" d'un développeur se limite à l'envoie des requête et la réception des résultats (c'est-à-dire qu'on n'est même pas sur ce schéma), néanmoins, un administrateur des bases des données doit pouvoir comprendre le fonctionnement de chaque couche comme il doit pouvoir accéder, surveiller et adapter (s'il est possible) le fonctionnement de chaque couche selon les besoins des applications qui consomment la base des données en question.
La difficulté rencontrée pour atteindre ce niveau découle des différences remarquables entre les différents SGBD en terme des fonctionnalités avancées offertes, des algorithmes implémentés et des techniques choisies pour chaque couche définie par l'architecture présentée ci-dessus.
Dans les articles suivants, nous allons présentés quelques commandes que nous avons utilisées durant le cours (voir article).
Le minimum requis pour commencer à travailler avec SQL est de comprendre et maîtriser les deux parties :
- LDD : le langage de définition des données. Cette partie du langage SQL découle directement du modèle relationnel avec un enrichissement obligatoire pour faire face aux limitations physiques de la machine par rapport au monde abstrait des mathématiques. Ainsi, nous avons les trois commandes :
- Create Table : qui n'est plus qu'une réécriture d'un schéma relationnel en ajoutant une déclaration local du domaine de chaque colonne et en ajoutant les contraintes,
- Alter Table : corriger une déclaration mathématique se fait en utilisant une gomme; pour une table déjà créée, la correction doit faire appel à cette commande,
- Drop Table : de même, supprimer une déclaration mathématique revient à jeter la feuille sur laquelle elle est faite; sur une machine, la suppression d'une table déjà créée se fait à travers cette commande.
- LMD : le langage de manipulation des données nous permet de manipuler les données de la base des données mais sans changer sa structure.
- Insert into : pour "remplir" la base,
- Update : pour modifier des données dans la base,
- Delete : pour supprimer des données de la base,
- Select : la requête la plus complexe par rapport aux autres. Pourquoi ? Parce qu'elle découle d'un mélange entre le calcul relationnel et le calcul prédicatif en ajoutant un étendu des opération d'agrégation (la somme, la moyenne, etc.) et c'est pourquoi c'est le type de requêtes sur lequel nous faisons le plus de pratique.
Ces deux parties sont très proches entre les différents SGBD et elles sont le minimum nécessaire pour tout développeur des applications de gestion (les applications destinées au système opérant si on opte pour l'ancien modèle, et pour le système opérant et la ligne hiérarchique si on opte pour le modèle de Mintzberg).
Pour maîtriser ces deux niveaux, tout SGBD peut faire la tâche de plus petit comme SQLite, Microsoft Access, OpenOffice Base au plus grand Oracle, PostgreSQL, Microsoft SQL Server.
Néanmoins, cette ensemble de commande n'est pas suffisant pour un Administrateur des Bases des Données. Il faut maîtriser des commandes supplémentaires pour pouvoir voir plus loin et plus profond à l'intérieur du SGBD pour pouvoir mieux gérer une base des données et garantir, ainsi, un bon fonctionnement des applications.
Un SGBD n'est pas un simple module de gestion des fichiers : il garantit la gestion des bases des données avec toutes les contraintes qu'elles présentent et en permettant un accès concurrent tout en essayant de rester efficace (en terme d'espace de stockage et en terme de temps de réponse). Pour garantir ces fonctionnalités, il était nécessaire d'opter pour une architecture en couche :
La "visibilité" d'un développeur se limite à l'envoie des requête et la réception des résultats (c'est-à-dire qu'on n'est même pas sur ce schéma), néanmoins, un administrateur des bases des données doit pouvoir comprendre le fonctionnement de chaque couche comme il doit pouvoir accéder, surveiller et adapter (s'il est possible) le fonctionnement de chaque couche selon les besoins des applications qui consomment la base des données en question.
La difficulté rencontrée pour atteindre ce niveau découle des différences remarquables entre les différents SGBD en terme des fonctionnalités avancées offertes, des algorithmes implémentés et des techniques choisies pour chaque couche définie par l'architecture présentée ci-dessus.
Dans les articles suivants, nous allons présentés quelques commandes que nous avons utilisées durant le cours (voir article).
