Types de base de données [Résolu]

[aureliegro]

Bonjour, je souhaiterai savoir quels sont les différents types de bases de données ?

Quelle différence y a t il entre les bases de données et les Systèmes de Gestion des Bases de Données ? Pouvez vous m'en citer quelques uns en exemple ?

Merci à tous ceux qui prendront le temps de me répondre.

[qi130]

Bonjour,

Il n'y a pas plusieurs types de base de données.

La base de données est une enveloppe technico-fonctionnelle qui va héberger des tables. C'est en général l'objet le plus haut dans la hiérarchie des "choses" gérées par le SGBD, bien que certains SGBD proposent aussi le tablespace.
La base est destinée à accueillir les tables.

Pour les SGBD par contre, il en existe plusieurs sortes:
- fichiers
- hiérarchiques (IMS/DB d'IBM par exemple)
- relationnels (Oracle, DB2, Interbase, MySQL, etc...)
- orientés Objets

[fsmrel]

Envoyé par qi130

La base de données est une enveloppe technico-fonctionnelle qui va héberger des tables.

Le concept de table est purement SQL : Vous traitez donc de la base de données selon SQL.

Envoyé par qi130

Il n'y a pas plusieurs types de base de données.

Si !

1) Il ya la base de données au sens très général :

Une base de données est une collection de données persistantes, utilisées par les applications d’une entreprise.

Par données persistantes, je veux dire qu’une fois que des données auront été engrangées avec succès dans la base de données par le SGBD (système de gestion de bases de données), elles seront accessibles tant que l’on n'aura pas demandé explicitement au SGBD de les supprimer.

2) Pour quitter le niveau très général (mais pour rester à un niveau "fonctionnel")

il y a les bases de données respectant le modèle hiérarchique, popularisé par IBM vers la fin des années soixante avec son système IMS (SGBD + moniteur de transactions). La définition générale peut donner lieu à la suivante :

Une base de données hiérarchique est une collection d’enregistrements persistants, utilisés par les applications d’une entreprise. Cette collection est composée de data base records (DBR), elle est décrite sous forme d’un DBD (data base descriptor), dans lequel les enregistrements (records) sont organisés en segments hiérarchisés.

Grâce au mécanisme des relations logiques entre DBD, on peut produire un réseau de hiérarchies.

3) Il y a les bases de données respectant le modèle en réseau, contemporaines des bases de données hiérarchiques, promues par le Data Base Task Group (DBTG), émanation de CODASYL, dont l’âme s’appelait Charles Bachman. Une des caractéristiques de ce genre de base de données est le système de navigation par pointeurs permettant d’emprunter des chemins (ou liens, appelés sets) pour passer d’un enregistrement d’un certain type (par exemple le contrat) à un enregistrement d’un autre type (par exemple le client).

Une base de données réseau est une collection d’enregistrements persistants, utilisés par les applications d’une entreprise. Cette collection est composée de records et de liens (sets) permettant la navigation entre les records.

4) Parmi les autres types de bases de données pré-relationnelles, il y a les bases de données respectant le modèle "liste inverse", utilisé notamment par les SGBD Datacom/DB et Abadas. Bien qu’ayant utilisé Abadas, je ne me lancerai pas à définir exactement ce qu’est une base de données liste inverse. J’ai le souvenir (ça fait 20 ans) d’un immense conteneur d’enregistrements chacun identifié par un ISN (Internal Sequence Number) invariant, sur lesquels on peut brancher le plus simplement du monde une foultitude d’index, mais que le programme doit nommer, contrairement aux index des SGBD relationnels.

Une base de données liste inverse est donc au moins un ensemble d'enregistrements et d'index.

5) Pour quitter les bases de données pré-relationnelles, on a les bases de données relationnelles, dont la définition a été donnée par Ted Codd en 1969- 1970 :

The totality of data in a data bank may be viewed as a collection of time-varying relations. These relations are of assorted degrees.

A l’époque, Ted Codd utilisait le terme "banque de données", mais depuis il l’a remplacé par celui (plus juste) de base de données. En outre, son fils spirituel Chris Date a remplacé le terme "relations variables dans le temps" par celui de variable relationnelle (relvar), car une relation, au même titre qu’un nombre est une valeur, donc invariante par définition.

Aujourd'hui, une base de données relationnelle est définie comme étant une collection de relvars et rien d’autre. En cela est respecté le principe de l’uniformité de la représentation des données.

6) Pour en arriver à SQL, on peut définir une base de données SQL comme étant une collection de tables.
Je pense que le terme collection est plus simple, plus approprié que l’expression "enveloppe technico-fonctionnelle".
A noter que le terme "table" correspond parfois à celui de relvar, parfois à celui de relation, parfois à celui de sac (bag). Une table est un sac où les doublons sont interdits. (Edit : je voulais écrire "Une table est un sac, car les doublons y sont autorisés".)

7) Dans le contexte des SGBD dits relationnels, on peut donner plus d’une définition d’une base de données : cela peut être celle qui précède (collection de tables) et correspond à la vision du développeur. Elle peut être celle qui correspond à la vision du DBA qui ajoute à la collection les objets physiques propres à son SGBD tels que les index, les structures physiques d’accueil des tables (le tablespace de DB2 ou d’Oracle, ou objet équivalent de SQL Server, etc.)

8) Pour quitter les bases de données relationnelles, il y a les bases de données adhérant strictement au modèle objet et pour lesquelles on ne raisonne pas en termes de tables, mais de classes d’objets.
Définition (Cf. M. Bouzeghoub, G. Gardarin, P. Valduriez. OBJETS. (Eyrolles, 1998)) :

Une base de données objet est une organisation cohérente d’objets persistants et partagés par des utilisateurs concurrents.

Il y a aussi des bases de données hybrides, relationnel étendu, objet-relationnel... Ça devient un peu compliqué.

9) Il y a les bases de données déductives, que l’on peut considérer comme des ensembles d’axiomes.

10) Il y a les bases de données XML, etc. toutes bases de données qui ne s’appuient pas exclusivement sur le concept de relvar ou de table...

J’espère, Aureligro, que vous n'allez pas sortir de là avec une bonne indigestion et plus de questions que vous ne vous en posiez au départ.
Retenez au moins qu’une base de données est une collection de données organisées sous une forme qu’a retenue le système (le SGBD) qui nous permet donc de structurer ces données, les manipuler sous son contrôle et qui en garantit l’intégrité, c'est-à-dire la validité. Au fond, une base de données est un ensemble d’axiomes (ou de propositions) et le SGBD nous permet d’en inférer des théorèmes, ces résultats que nous proposons aux utilisateurs...

Je n'ai pas tout dit. D'autres pourront compléter, voire corriger ce que je vous ai raconté, il y a de la matière...

[qi130]

Cher fsmrel,

je ne puis malheureusement qu'être en désaccord avec certains des éléments que tu fournis.

A pousser + loin, mon carnet d'adresse papier est aussi une base de données, et par extension, tout regroupement de données constitue de facto une base de données. Et c'est bien là la définition littérale de la base de données.

Il n'y a donc à mon sens qu'un type de base de données.

Maintenant, mettons la sémantique de coté et concentrons nous sur l'aspect informatique.
Merci au passage pour les éléments historiques que tu mentionnes...

Dans ta réponse, tu a pris le parti de faire l'amalgame entre la base de données et la solution "système" (SGBD) avec laquelle on y accède. D'où la profusion de type de bases.

C'est cette approche que je ne cautionne pas.

En effet:
Du point de vue utilisateur, une base est une base. Qu'elle soit gérée par un moteur hiérarchique, pré-relationnel, relationnel ou autre lui importe peu. La seule différence résidant in-fine dans la capacité globale du moteur ce qui influence le coût.

2) Pour quitter le niveau très général (mais pour rester à un niveau "fonctionnel")

Nous ne sommes plus du tout dans le fonctionnel à partir de là, à moins de traduire par "architectural"

on peut définir une base de données SQL

Ha !? j'ai toujours cru que SQL était un langage

le terme collection est plus simple, plus approprié que l’expression "enveloppe technico-fonctionnelle"

J'ai utilisé ce terme à dessein: il représenté quelque chose tant pour l'utilisateur que pour un DBA ou un programmeur.
A contrario, parler de collection de tables à un utilisateur,

Une table est un sac

Et sous Lotus Notes, une base aussi est un sac...
Pour ma part, la meilleure représentation d'une table serait plus sûrement une feuille de tableur (mais je n'oblige personne à partager)

un sac où les doublons sont interdits

Ce qui porte à croire qu'un mécanisme de contrôle est systématique ou obligatoire . Il n'en est rien.

[fsmrel]

Bonsoir,

Dans un premier temps, je lis :

La base de données est une enveloppe technico-fonctionnelle qui va héberger des tables.

Puis dans deuxième temps :

A pousser + loin, mon carnet d'adresse papier est aussi une base de données, et par extension, tout regroupement de données constitue de facto une base de données. Et c'est bien là la définition littérale de la base de données.

Il n'y a donc à mon sens qu'un type de base de données.

Si je comprends bien, un carnet d’adresses papier et une enveloppe technico-fonctionnelle hébergeant des tables relèvent du même type : regroupement de données, ce qui n'est pas faux mais tout de même un peu court. En conséquence, il est préférable de se donner un cadre, border l’univers du discours, sinon on ne se sortira pas d’une disputatio byzantine, on pourra trouver une foultitude de définitions toutes plus controversables les unes que les autres de ce qu’est une base de données. Pour ma part, l’architecture ANSI/SPARC me paraît être un bon cadre au sein de ce forum.
Dans ce cadre, je pourrais m'en tenir à la définition très générale : "Une base de données est une collection de données persistantes, utilisées par les applications d’une entreprise" et en rester là, mais quel intérêt pour Aureliegro ? Ça me paraît un peu sec, c’est pourquoi il m’a paru préférable de pousser plus avant.
Ainsi, au niveau externe ANSI/SPARC, il est précisé que l’on doit associer à chaque base de données un langage de requête (cela peut être SQL ou tout autre langage plus convivial) inévitablement associé plus ou moins directement à un système, un SGBD, dont la finalité est de permettre de structurer les données, les manipuler, en garantir l’intégrité, et bien entendu les partager avec la communauté des utilisateurs autorisés. A défaut, chacun a sa petite "base de données", mais ceci est sans grand intérêt pour la communauté. Quoi qu’il en soit, au moins dans le cadre fixé, parler de bases de données conduit à parler de langage de manipulation, donc plus ou moins directement de SGBD, même sur un plan très général.

Dans ta réponse, tu a pris le parti de faire l'amalgame entre la base de données et la solution "système" (SGBD) avec laquelle on y accède. D'où la profusion de type de bases.

C'est cette approche que je ne cautionne pas.

Je répète qu’après avoir défini la base de données de façon très générale : "collection de données persistantes, utilisées par les applications d’une entreprise", il ne me paraît pas inutile de fournir un inventaire des types de bases de données dignes d’intérêt pour la communauté, accessibles et partageables, celles auxquelles on associe nécessairement à un moment donné un SGBD. Je ne vois pas en quoi une association de cette nature constitue un amalgame et en l’occurrence je ne demande pas de caution (celle de Ted Codd (RIP) et de Chris Date suffisent amplement à mon bonheur). Par ailleurs, quand j'évoque les SGBD, c'est à titre de complément d'information, j'aurais pu me borner à fournir la liste des modèles les plus représentatifs : hiérarchique, réseau, liste inverse, relationnel, objet... Certes il y a encore profusion, mais qu’y pouvons-nous ?

Du point de vue utilisateur, une base est une base. Qu'elle soit gérée par un moteur hiérarchique, pré-relationnel, relationnel ou autre lui importe peu.

Bien entendu, mais on dérive vers le truisme. Concernant l’utilisateur final, s’il n’est pas informaticien, il est évident que peu lui importe qu’une base de données soit une enveloppe technico-fonctionnelle qui va héberger des tables, des objets ou que sais-je, pour lui l’essentiel est qu’on lui présente les données sous une forme ergonomique et qu'il n'ait pas à attendre une heure une réponse fournie normalement dans la seconde (comme je demande à ma voiture de rouler à une certaine allure, sans que je sache exactement ce qu'il y a sous le capot). Par contre, si cet utilisateur est un développeur (se positionnant donc au niveau externe de l’architecture ANSI/SPARC), il doit connaître le langage de manipulation des données dont il a fait mention sur son CV au paragraphe justifiant de ses compétences. La connaissance de ce langage suppose un minimum de connaissance du SGBD sur lequel s’appuie ce langage.

j'ai toujours cru que SQL était un langage

Dont acte. J’espère que vous me pardonnerez le raccourci que j’ai pris. Je rectifie donc : on peut définir une base de données au moyen des instructions fournies par SQL (Sorry Query Language), langage inspiré du modèle relationnel de données mais non conforme à ce modèle.

J'ai écrit :
Une table est un sac où les doublons sont interdits.

Lapsus malheureux de ma part ! Je voulais dire : Une table est un sac, car les doublons y sont autorisés. Ceci pour montrer une différence capitale entre relation et table, puisqu’une relation par définition ne comporte pas de doublons.
Je corrigerai dans mon message initial cette faute d’inattention, propre à semer le trouble dans les esprits !


Je me doute qu'au final, vous serez toujours en désaccord, mais tout cela n'est pas bien grave. A Aureliegro en particulier et aux forumeurs en général de se forger leur propre opinion sur le thème "qu'est-ce qu’une base de données"...