Pour faire simple, la gestion des données mémorisées sur un support quelconque (disque dur, DVD, CD-ROM, …) demande de gérer deux choses bien différentes : le stockage des données et leur manipulation. Pour commencer, nous allons nous intéresser au stockage des données, comment celles-ci sont organisées pour être mémorisées durablement. Les concepts que nous allons voir dans cette page sont les bases de ce cours et les connaître est très important. La plupart des termes que nous allons voir forment le vocabulaire minimal qu'il faut savoir pour aborder ce domaine.
Tables, enregistrements et attributs.
Que ce soit dans un fichier ou dans une base de données, les données à mémoriser sont ce qu'on appelle des enregistrements. Ces enregistrements mémorisent toutes les informations liées à un objet, une personne, une entité, une chose. Prenons le cas d'une entreprise qui veut mémoriser la liste des commandes qu'elle a passé à ses fournisseurs : chaque commande sera mémorisée dans l'ordinateur dans un enregistrement, qui contiendra toutes les informations liées à la commande. Prenons maintenant l'exemple d'un établissement scolaire qui veut mémoriser la liste de ses élèves : chaque élève sera mémorisé par un enregistrement, qui contiendra toutes les informations sur l'élève en question. Et enfin, prenons comme dernier exemple un biologiste qui veut établir la liste de toutes les espèces animales découvertes à ce jour : chaque espèce découverte se verra attribuer un enregistrement, qui contiendra toutes les informations sur l'espèce.
Les enregistrements sont des équivalents des structures dans les langages de programmation comme le C ou le C++.
Enregistrements et attributs.
Comme les exemples plus haut vous l'ont certainement fait remarquer, chaque entité, chaque enregistrement, est décrite par plusieurs informations : on a souvent besoin de mémoriser plusieurs informations distinctes pour chaque enregistrement.
Par exemple, une entreprise aura besoin de stocker, pour chaque client :
Comme autre exemple, un établissement scolaire devra mémoriser pour chaque élève :
Comme dernier exemple, un garage aura besoin de mémoriser, pour chaque voiture : 
Toutes ces informations sont des informations distinctes, mais qui appartiennent à la même personne, au même objet, à la même entité : on doit les regrouper dans un seul enregistrement. Pour cela, chaque enregistrement est un regroupement d'attributs, chaque attribut étant une information élémentaire, qui ne peut pas être décomposée en informations plus simples. Ces attributs sont équivalents aux variables des langages de programmation. Définir un enregistrement, c'est simplement définir l'ensemble des attributs qu'il contient : il faut préciser son type et sa valeur. Mais il faudra aussi lui donner un nom, pour pouvoir le récupérer.
Type d'un attribut.
Ces attributs peuvent prendre des valeurs bien précises, définies à l'avance : les valeurs que peuvent prendre chaque attribut sont déterminés par ce qu'on appelle le type de l'attribut. Les types autorisés par les systèmes de gestion de données sont ceux couramment utilisés en informatique, à savoir : les nombres entiers et à virgule, les caractères et autres formes de texte, les booléens, etc.
Reprenons les exemples vus plus haut, pour voir quel est le type adéquat pour mémoriser chaque attribut. Pour l'exemple d'une entreprise qui a besoin de mémoriser la liste de ses clients, voici le type de chaque attribut :
Prenons maintenant l'exemple d'une infirmerie scolaire qui veut mémoriser des informations médicales obtenues lors des visites médicales. Celui-ci doit mémoriser, pour chaque élève :
Comme l'exemple de l'établissement scolaire qui doit mémoriser pour chaque élève : 
Comme dernier exemple, un garage aura besoin de mémoriser, pour chaque voiture :
Valeur nulle.
Dans certains cas, il arrive que certaines informations ne soient pas connues lorsqu'on crée l'enregistrement. Par exemple, quand un élève rentre dans une école, on peut très bien ne pas connaître son établissement de l'année précédente. Et des cas similaires sont légions : soit l'information est inconnue, soit elle n'existe pas. On doit alors remplir l'attribut correspondant par une valeur qui indique que l'attribut a une valeur inconnue, que l'attribut n'a pas été rempli. Cette valeur est appelée la valeur NULL.
Par exemple, l'exemple suivant, qui correspond aux informations d'une personne, est parfaitement possible :
Modèles relationnel et de fichiers.
D'ordinaire, les entreprises et autres utilisateurs ont besoin de mémoriser de grandes quantités d'informations basées sur un même moule. Par exemple, les informations à mémoriser pour chaque élève d'un établissement scolaire seront identiques : tous les élèves ont un âge, un nom, un prénom, etc. Dans une liste de commandes passées par des clients, toutes les commandes sont définies par les mêmes informations : quel est le client, le produit commandé, la quantité à fournir, etc. En clair, tous les enregistrements d'une même liste ont des attributs semblables : ils ont le même type, le même nom et la même signification, seul leur valeur change. Elles ont besoin de mémoriser des listes d'enregistrements. Généralement, les informations sont classées dans plusieurs listes, par souci de simplification. Par exemple, si on prend le cas d'une librairie, celle-ci rangera les informations liées aux commandes de livres dans une liste séparée des informations sur les clients, et ainsi de suite : on aura une liste de client, une liste de commande de livre, une liste pour les livres en rayon, etc.
Les modèles de données.
Dans les cas les plus simples, on peut mémoriser chaque liste dans un fichier : les enregistrements y sont placés les uns à la suite des autres. Mais l'utilisation de fichiers a un défaut : le traitement de fichiers doit être programmé de zéro. En effet, les langages de programmation ne permettent que de récupérer les informations d'un fichier unes par unes, ou d'en ajouter à la fin du fichier, mais sans plus : on ne peut pas dire au langage de programmation qu'on ne veut récupérer que les données qui respectent une certaine condition, ni fusionner le contenu de deux fichiers, etc. Un autre défaut est que ce modèle ne permet pas de représenter les relations entre listes d'enregistrements. Et ces relations peuvent être très importantes pour interpréter les données ou permettre de les manipuler efficacement. Le modèle à base de fichier se contente de placer chaque liste dans un fichier, le programme devant connaître de lui-même les relations entre données. D'autres systèmes de gestion des données permettent cependant de représenter ces liens avec une grande efficacité.
Pour pouvoir faire cela nativement, sans avoir à programmer un morceau de programme qui le fasse à notre place, on peut utiliser ce qu'on appelle des bases de données. Ces bases de données sont en quelque sorte des fichiers, mais qui sont gérées par un logiciel qui fait le café : ces logiciels sont appelés des systèmes de gestion de base de données, ou SGBD. Avec ces SGBD, le rangement des informations dans un fichier n'est pas spécifié par le programmeur : le SGBD s'occupe de gérer tout ce qui a rapport avec la manière dont les données sont rangées sur le disque dur. En plus, les bases de données effectuent automatiquement des opérations assez puissantes et peuvent faire autre chose que lire les informations unes par unes dans un fichier, les modifier, ou y ajouter des informations : on peut décider de récupérer les données qui respectent une certaine condition, de fusionner des données, etc. Mais leur intérêt principal est de modéliser les relations entre chaque liste d'enregistrement efficacement, d'une manière qui permet de traiter les données rapidement.
Ces bases de données utilisent des méthodes assez distinctes pour représenter les relations entre informations, méthodes qui permettent de distinguer les BDD arborescentes, en réseau, relationnelles, déductives et orientées-objet. Les plus simples sont de loin les BDD en réseau et arborescentes. Celles-ci codent les relations entre listes par des pointeurs, chaque enregistrement pouvant faire référence à un autre, situé dans une autre liste. La différence entre BDD en réseau et arborescentes tient dans le fait que certaines relations sont interdites dans les BDD arborescentes, qui ont une forme d'arbre (non-binaire, le plus souvent). Le modèle relationnel sera vu plus loin : c'est lui que nous étudierons dans ce cours. Le fait est que toutes les BDDs actuelles utilisent le modèle relationnel. Les modèles orientés-objet et déductifs sont plus difficiles à décrire, du moins pour qui ne sait pas ce que sont les langages de programmation orientés-objet ou logiques.
Le modèle relationnel.
Une base de donnée relationnelle permet de gérer des listes de données, qui sont appelées des tables, sont organisées en lignes et en colonnes. Chaque ligne mémorise un enregistrement, la succession des lignes permettant de mémoriser plusieurs enregistrements les uns à la suite des autres, en liste. Comme dit plus haut, les enregistrements d'une liste ont des attributs de même nom et de même type, seul leur valeur changeant : les attributs de même nom et type sont placés sur une même colonne, par simplicité. Évidemment, tous les enregistrements d'une table ont exactement les mêmes attributs, ce qui fait que toutes les lignes d'une table ont le même nombre de colonnes.
Il existe un vocabulaire assez précis pour nommer les enregistrements, colonnes et autres particularités d'une table. Ceux-ci sont illustrés dans les deux schémas ci-dessous.
Une formulation équivalente à la précédente utilise les termes suivants :
Évidemment, ces tables ne serviraient strictement à rien si on ne pouvait pas récupérer leur contenu : on peut récupérer une ligne dans la table sans que cela pose problème. On peut aussi ajouter des lignes dans une table, ainsi qu'en supprimer : si on prend l'exemple d'une liste de commandes tenue par une entreprise, on peut ajouter des commandes quand un client passe un contrat, ou en supprimer une fois la commande honorée. Et enfin, on peut modifier certaines lignes, quand celles-ci contiennent des données erronées ou dont la valeur a changé : si on prend une liste d'employé d'une entreprise, on peut vouloir changer le nom d'une employée suite à un mariage, par exemple. Ainsi, gérer des données dans une table demande de pouvoir faire quatre opérations de base :
Ces quatre opérations sont regroupées sous l'acronyme CRUD.
Remarque de fin.
Il est évident qu'il vaut mieux éviter de mémoriser des informations inutiles dans une base de données. Par données inutiles, on veut dire : données qui peuvent se déduire à partir des données déjà présentes dans l'enregistrement. Par exemple, le prix d'une commande client peut se déduire à partir du prix unitaire d'un produit et des quantités commandées. Dans ces conditions, mieux vaut éviter de mémoriser ces données facilement déductibles : le programme qui manipulera les informations de la base de donnée les calculera lui-même, ce qui est très rapide (plus que de lire les données depuis une BDD ou un fichier). Une fois cela fait, les données de la table forment un ensemble minimal de données. Mais toutes n'ont pas le même poids, le même intérêt.
Conclusion.
Ce chapitre s'est limité au vocabulaire de base, le vocabulaire des bases de données étant assez important. Pour vous en rendre compte, vous pouvez avoir une petite idée des termes du domaine en allant en voir la liste, disponible sur wiktionnaire, via ce lien :
Une partie des termes de cette liste seront vus dans les chapitres suivants.