200$
2018-06-24 
300$ 2019-07-01
800$ 2020-12-25Copyright © 2021 Yves MARCOUX; dernière modification : 2021-09-06; corrections mineures : 2021-11-17.
Yves MARCOUX - EBSI - Université de Montréal
Une base de données (BD) est souvent définie comme un ensemble structuré d’informations se rapportant à une collection d’objets de même nature. Reprenons les concepts-clés de cette définition :
Cela étant dit, il arrive souvent que les objets couverts par une BD aient une certaine variabilité faisant en sorte que certains des éléments descriptifs peuvent ne pas être applicables à certains des objets de la collection. Par exemple, dans une BD couvrant une collection de chaussures, la longueur des lacets requis est un élément descriptif applicable à plusieurs des objets, mais pas tous, puisque certaines chaussures ne comportent pas de lacets. Dans ce cas, selon le type de structuration utilisé, l’élément descriptif pour cet objet sera simplement absent de la BD, ou il sera présent, mais avec une valeur prédéterminée qui, par convention, signifiera « N/A » (non applicable).
Le choix des éléments descriptifs représentés dans une BD est, comme sa couverture, un élément très important de la BD et doit être établi en fonction de ce que l’on veut accomplir exactement avec la BD. Il est normalement réalisé très tôt, du moins sommairement, dans un projet de BD. Ce choix se retrouvera lui aussi, comme la couverture, dans le dictionnaire de données de la BD après sa mise en service.
Une influenceuse spécialisée dans la promotion de chaussures sur Instagram possède une centaine de paires de chaussures, collection qui s’accroît de jour en jour. Pour avoir un meilleur aperçu du contenu de sa collection, mieux l’exploiter et notamment mieux orchestrer l’apparition des différents items dans ses publications, elle désire disposer d’une BD qui répertoriera certaines informations-clés concernant sa collection.
La couverture de la BD envisagée est ici la collection des chaussures que possède l’influenceuse. Dès le début du projet il faudra statuer sur certains détails (en vérifiant plus précisément auprès de la « cliente » ses besoins réels), comme par exemple s’il faut prévoir l’enregistrement dans la BD des chaussures commandées mais non encore reçues, puisque cela pourrait influer sur le choix des éléments descriptifs retenus (par exemple, inclure ou non une date de livraison prévue).
Le choix des éléments descriptifs sera lui aussi établi en fonction des besoins précis de la cliente. On peut présumer qu’il inclura des choses comme la couleur, le style, la date d’acquisition, le prix d’achat (même s’il s’agit d’un don, de façon à pouvoir le mentionner dans les publications), le fabricant, le pays d’origine, la date de dernière parution dans une publication (avec un lien vers la publication) et sûrement une photo ou plusieurs. Notez que l’élément descriptif donné en exemple tout à l’heure (la longueur des lacets) ne sera peut-être pas retenu, puisque cette information est probablement peu utile compte tenu des besoins de l’influenceuse. Dans un autre contexte, cependant (par exemple celui d’un magasin de chaussures), elle pourrait être pertinente.
Un système de gestion de bases de données (SGBD) est un outil logiciel spécialisé permettant à un spécialiste de l’information de définir, créer, interroger et gérer une base de données. Des exemples de SGBD sont Microsoft Access, DB/TextWorks, Oracle, MySQL, SQLite, MarkLogic, BaseX et MongoDB.
Chaque SGBD offre différentes possibilités de structuration de l’information, mais pratiquement sans exception, ils offrent une structure élémentaire que l’on appelle la table de données. Aussi est-il utile de s’attarder à cette structure en elle-même, indépendamment d’un SGBD spécifique. Ce qui suit est une présentation intuitive et informelle de cette structure élémentaire.
En plus de la structuration de l’information, un SGBD offre de nombreuses autres fonctionnalités comme la validation, le tri et l’interrogation des données selon divers critères, les calculs, statistiques ou autres, la production de rapport, de même que le contrôle d’accès, la gestion des accès simultanés par plusieurs utilisateurs et la tolérance aux pannes de diverses natures (matériel, logiciel, réseau, etc.). Ces fonctionnalités ne sont pas discutées dans le présent texte.
En principe, n’importe quel outil informatique capable d’enregistrer des informations sous les formes appropriées (texte, nombres, images, sons) pourrait être utilisé pour constituer une « base de données ». Les logiciels de traitement de texte des suites bureautiques modernes sont tous capables d’enregistrer du texte, des nombres, des images et des sons, et permettraient donc de stocker en vrac dans un document toutes les informations d’une BD.
Explorons cette possibilité théorique avec un minuscule exemple, peu réaliste, mais suffisant pour illustrer l’idée. Imaginons que, pour notre influenceuse, on commence modestement avec une BD couvrant seulement trois paires de chaussures et constituée de seulement trois éléments descriptifs : photo, prix d’achat et date d’acquisition. Les neufs informations correspondantes pourraient très bien être placées dans un document de traitement de texte, par exemple comme suit :
200$
2018-06-24 300$ 2019-07-01
800$ 2020-12-25Évidemment, pour constituer une base de données telle que nous l’avons définie plus haut, il manque à ces informations un élément crucial : une structuration adéquate.
Pour mettre en évidence le rôle de la structuration dans une BD, demandons-nous ce qu’il faudrait ajouter au document pour obtenir une « structuration adéquate ». Même si l’exercice peut sembler futile, il nous aidera entre autres à mieux comprendre le pourquoi de certaines des étapes de création d’une BD dans un outil spécialisé comme un SGBD.
Rappelons que la structuration des informations a pour objectifs que :
Dans notre document, les informations concernant un même objet sont déjà regroupées dans le sens qu’elles se suivent; cependant, elle ne sont pas clairement séparées des informations concernant les objets qui précèdent ou suivent. Pour nous assurer que les regroupements sont sans équivoque, une approche possible est d’ajouter une séparation claire entre les objets, ce qui donnerait par exemple :
200$
2018-06-24 300$
2019-07-01 800$
2020-12-25Pour qu’il soit possible d’interpréter chaque information comme une caractéristique d’un objet spécifique de la collection, une première chose à faire est d’ajouter des intitulés à côté des informations elles-mêmes pour indiquer de quoi il s’agit. Cela est nécessaire, puisque même s’il est assez clair que « 200$ » représente un montant d’argent, rien dans le document n’indique qu’il s’agit du prix d’achat. On obtiendrait donc quelque chose comme :
Vous vous dites peut-être : Ces intitulés ne sont pas vraiment nécessaires; on aurait simplement pu statuer que les informations concernant un objet seront toujours inscrites dans l’ordre photo, prix d’achat, date d’achat. Dans l’absolu, cette observation est juste. Cependant, il faut réaliser que de procéder ainsi rendrait l’interprétation des données plus « fragile », dans le sens qu’en l’absence de cette information additionnelle (donc, si on ne connaît pas l’ordre implicite présupposé des informations), on ne peut simplement pas interpréter avec certitude les informations contenues dans le document. L’approche consistant à inclure explicitement les intitulés dans le document est donc nettement préférable, et c’est sans surprise celle que l’on retrouve dans les outils spécialisés de bases de données comme les SGBD. C’est donc celle que nous adoptons.
Toujours dans l’optique de faciliter l’interprétation non ambiguë des informations de notre document, il ne serait pas mauvais d’ajouter un titre à notre document, indiquant qu’il ne s’agit pas d’informations sur n’importe quelle collection de chaussures, mais sur celle spécifique d’Esguelle Setra (en supposant que ce soit le nom de notre influenceuse) :
Peut-on dire maintenant que le second objectif de la structuration est atteint, à savoir qu’il est possible d’interpréter chaque information du document comme une caractéristique qui s’applique à un objet de la collection ? Par exemple, est-ce que le fait de voir ceci dans le document :
permet à l’influenceuse d’aller chercher physiquement dans sa collection la boîte précise contenant la paire de chaussures en question (pour en faire ce qu’elle veut, par exemple les prêter à une amie) ? Imaginons que les boîtes sont disposées un peu pêle-mêle dans une pièce, est-ce que le fait de voir une photo de la paire recherchée suffit pour la localiser ? En principe, oui, mais ça risque d’être difficile, car il faudra ouvrir une à une les boîtes jusqu’à ce qu’on aperçoive la paire en question… pas très pratique ! Pire encore, imaginons qu’Esguelle possède deux paires identiques du modèle illustré et qu’elle recherche spécifiquement celle achetée le 25 décembre 2020 ! Clairement, une photo ne suffit pas à retrouver la paire voulue, peu importe le temps qu’on est prêt à mettre pour ouvrir les boîtes !
Comment, alors, s’assurer que l’on peut rattacher chaque information de notre document à une boîte spécifique de la collection ? Une partie de la solution réside dans l’organisation de la collection en elle-même, indépendamment de tout projet de BD. L’idée est d’attribuer un identifiant unique à chaque objet de la collection et de faire en sorte que cette identifiant unique permette de localiser l’objet dans le « vrai monde ».
Un identifiant unique peut se résumer à un simple un numéro inscrit sur chaque objet de la collection (ici, des boîtes de chaussures). Si l’on prend soin de ranger physiquement la collection dans l’ordre des identifiants, on peut non seulement repérer sans ambiguïté un objet spécifique à partir de son identifiant, mais on peut aussi le faire facilement.
Voici de quoi pourrait avoir l’air physiquement la collection après cette opération :
Pour pouvoir faire le lien entre les informations dans notre document de traitement de texte et un objet spécifique de la collection, il suffit d’inscrire l’identifiant unique de l’objet comme « entête » du regroupement d’informations correspondant à cet objet dans notre document :
Ce que nous avons fait est d’introduire dans nos regroupements un élément descriptif « spécial » Chaussure #. En le plaçant en entête du regroupement, nous mettons en évidence le fait qu’il identifie l’objet de la collection réelle auquel se rapportent les informations présentes dans le regroupement. Grâce à cet entête et à la présence des autres intitulés, il est possible d’interpréter avec certitude chaque information de notre document comme un élément descriptif spécifique d’un objet spécifique de la collection. Le second objectif de la structuration est donc atteint.
Du coup, comme la photo ne sert plus à identifier l’objet, nous la traitons maintenant sur le même pied que les autres informations descriptives, d’où l’intitulé « Photo : ».
À retenir :
La création d’une BD pour gérer une collection demande souvent de revoir l’organisation des objets de la collection elle-même, indépendamment de la BD, en particulier de mettre en place des identifiants uniques des objets, servant non seulement à identifier les objets dans la BD, mais également à les localiser dans « le monde réel ». Il peut arriver que de tels identifiants existent déjà, mais souvent – et en particulier pour des collections qui n’ont jamais fait l’objet de BD – il faudra les créer, avant ou en même temps que la BD.
À quoi notre petit exercice théorique nous a-t-il menés ? Il nous a d’abord permis d’illustrer concrètement comment les objectifs de la structuration dans une BD permettent effectivement d’interpréter les informations sans ambiguïté en lien avec le monde réel. Ensuite, il nous a montré certaines façons précises d’atteindre ces objectifs en ajoutant à des informations brutes, a priori simplement juxtaposées l’une à l’autre, certains éléments structurants (séparateurs, intitulés, entêtes, etc.).
Structurellement, ce à quoi nous sommes arrivés correspond essentiellement à la structuration de base offerte par la grande majorité des SGBD : la table de données. Évidemment, il n’y a rien d’automatisé dans la structuration que nous avons introduite et elle s’appuie principalement sur une interprétation humaine des éléments structurants. Dans un SGBD, la structuration est imposée et uniformisée, et certains contrôles de l’information sont automatisés, mais il est intéressant de noter que l’interprétation humaine continue de jouer un rôle fondamental dans la réalisation du second objectif, celui de pouvoir interpréter avec certitude chaque information de la BD comme un élément descriptif spécifique applicable à un objet spécifique de la collection couverte. En ce sens, l’explication intuitive du second objectif donnée ci-dessus garde tout son sens, même avec un SGBD.
Dans la plupart des SGBD, l’affichage et la saisie des informations relative à un objet peut s’effectuer dans une interface qui ressemble essentiellement à un formulaire (rempli ou à remplir) dont la forme est semblable à celle d’une des sections (regroupements) de notre hypothétique document de traitement de texte. Voici par exemple à quoi pourrait ressembler une interface pour la saisie d’information d’une nouvelle paire de chaussures dans une table de données structurée comme l’était notre hypothétique document :
Dans la plupart des SGBD, l’affichage peut aussi s’effectuer pour tous les objets de la collection d’un coup, dans une interface qui est essentiellement un tableau à deux dimensions où les intitulés sont utilisés comme entêtes des colonnes, plutôt que d’être répétés pour chaque objet de la collection. Par exemple, les données de notre hypothétique document de traitement de texte seraient présentées comme suit :
COLLECTION DE CHAUSSURES D’ESGUELLE SETRA Chaussure # Photo Prix d’achat Date d’achat 1 200$ 2018-06-24 2 300$ 2019-07-01 3 800$ 2020-12-25
C’est une telle présentation en tableau qui justifie le nom de « table de données ».
Peu importe la façon dont elle est représentée ou stockée de façon interne dans un SGBD, une table de données consiste toujours, au niveau conceptuel, en une telle structure bidimensionnelle, incluant le titre, les entêtes et les informations enregistrées dans les différentes cases.
Il est utile de donner des noms spécifiques à certains des éléments d’une table de données.
Le titre que l’on retrouve au haut d’une table de données est le nom de la table.
Les colonnes d’une table s’appellent les champs de cette table. Les entêtes des colonnes sont les noms des champs.
Les lignes d’une table (excluant les lignes de titre et d’entêtes) s’appellent les fiches (ou parfois enregistrements) de la table. Normalement, les champs sont déterminés à la création de la table et ne changent pas durant la vie de la table. Les fiches, cependant, varient au cours de la vie de la table : à la création de la table, celle-ci est vide, dans le sens qu’elle ne possède aucune fiche. Au fur et à mesure de son utilisation, des fiches y seront ajoutées, modifiées ou détruites, ce qui fait que le nombre de fiches dans la table peut varier tout au long de la vie de la table.
Chaque table possède un champ identifié comme correspondant à l’identifiant unique des objets de la collection couverte. Les informations inscrites dans ce champ doivent être différentes pour chaque fiche. Ce champ est appelé la clé primaire de la table. Dans nos exemples de tables de données, la clé primaire est montrée avec son nom souligné dans la ligne d’entêtes de la table.
C’est la conceptrice d’une BD qui, au moment de la création de la table, décide du nom de la table, des noms de champ et détermine quel champ est la clé primaire de la table. Elle effectue ces choix en fonction des besoins de gestion d’information à satisfaire.
Comme nous avons déjà dit, pratiquement tous les SGBD offrent la structuration d’informations sous forme de table de données. Certains offrent en plus d’autres possibilités de structuration, par exemple, sous forme de graphes ou de réseaux. Selon l’éventail de possibilités de structuration qu’il offre, un SGBD se conforme à ce qu’on appelle un certain modèle de données.
Le modèle de données probablement le plus répandu dans le monde est le modèle relationnel. Un autre modèle, extrêmement populaire pour la gestion d’information documentaire (bibliographique, catalographique, etc.), est le modèle textuel. Microsoft Access est un exemple de SGBD relationnel; DB/TextWorks est un exemple de SGBD textuel. Un autre modèle important est celui des documents structurés, par exemple XML. Les SGBD conformes à ces trois modèles font partie de la vaste majorité des SGBD qui offrent effectivement la structuration d’informations sous forme de table de données.
Même à l’intérieur d’un même modèle de données, chaque SGBD a ses particularités propres, qui déterminent ses fonctionnalités exactes et la façon de s’en servir, notamment son interface. Il y a donc une limite à ce qu’on peut dire en général sur les SGBD d’un certain modèle. Néanmoins, on peut énoncer certaines caractéristiques typiques des SGBD d’un certain modèle. C’est ce que nous ferons ci-dessous pour les modèles textuel et relationnel.
Soulignons que, puisque tous les SGBD relationnels et textuels offrent la structuration d’informations sous forme de table de données, la table COLLECTION DE CHAUSSURES D’ESGUELLE SETRA ci-dessus peut être créée et exister telle quelle dans n’importe quel SGBD textuel ou relationnel.
D’abord, une caractéristique partagée par tous les SGBD textuels et relationnels.
Tous les SGBD textuels et relationnels offrent la possibilité d’attribuer à chaque champ un type de données, qui permet à la conceptrice d’une BD de limiter à certaines formes particulières les informations que l’on peut retrouver dans ce champ. Par exemple, la conceptrice pourrait décider qu’un certain champ ne peut contenir que des dates sous une forme spécifique (par exemple AAAA-MM-JJ). Les types les plus courants sont :
Tous les SGBD offrent un type de données correspondant à du texte sans limite de longueur. Ce serait le type de données à utiliser pour un champ destiné par exemple à contenir le texte intégral d’un document textuel.
La plupart des SGBD offrent à la conceptrice d’autres moyens que l’attribution d’un type pour contrôler le contenu d’un champ. Ces mécanismes, dits de validation, permettent au SGBD de vérifier automatiquement, au moment où l’information est saisie, que le contenu du champ est conforme à certaines règles. Mentionnons par exemple la possibilité de spécifier des valeurs minimum et maximum acceptables, ou encore un masque de saisie, que les données saisies doivent respecter (par exemple 999-999-9999 pour un numéro de téléphone).
Dans la plupart des SGBD textuels, une BD consiste en une seule table. Le nom de la table est alors aussi le nom de la BD.
Tous les SGBD textuels permettent à la conceptrice d’une BD de définir certains champs comme acceptant les occurrences multiples. Intuitivement, si un champ est à occurrences multiples, la case d’une fiche correspondant à ce champ peut être subdivisée en « sous-cases », chacune contenant une valeur distincte. Cette possibilité permet donc d’enregistrer plusieurs valeurs dans le même champ d’une même fiche.
À titre d’exemple, reprenons la table de données ci-dessus, correspondant à la collection de chaussures d’Esguelle Setra. Imaginons que l’on veuille enregistrer dans la BD toutes les dates auxquelles une paire de chaussures est apparue dans une publication Instagram. La conceptrice de la BD ajoutera donc un nouveau champ, appelé par exemple Dates d’apparition. Comme une paire peut apparaître à plusieurs dates différentes, il faudra que la conceptrice définisse ce champ comme acceptant les occurrences multiples. Cela permettra donc de saisir plusieurs dates pour la même paire de chaussures.
Notre but n’est pas de montrer comment définir ce champ dans un SGBD spécifique, mais bien d’illustrer ce qui se passe au niveau conceptuel. Visuellement, la situation peut être représentée par la possibilité de subdiviser, au moment de la saisie, le champ Dates d’apparition d’une fiche en plusieurs « sous-cases ». Voici ce que cela pourrait donner une fois des données saisies dans le nouveau champ :
COLLECTION DE CHAUSSURES D’ESGUELLE SETRA modifiée Chaussure # Photo Prix d’achat Date d’achat Dates d’apparition 1 200$ 2018-06-24 2018-06-30
2019-12-31
2021-09-302 300$ 2019-07-01 2019-12-31 3 800$ 2020-12-25 2022-01-01
2022-03-15
Comme on peut voir, le fait de définir un champ comme acceptant les occurrences multiples n’oblige pas à inscrire plusieurs valeurs dans le champ, mais en offre simplement la possibilité au moment de saisir l’information.
Tous les SGBD relationnels permettent la création de BD à plusieurs tables. Encore ici, il n’est pas obligatoire pour la conceptrice d’une BD de créer plusieurs tables, mais la chose est possible.
La BD possède son propre nom, distinct de celui des tables qui la composent. Chaque table correspond à une « collection » distincte, reliée d’une certaine façon aux autres collections couvertes par les autres tables de la BD. La possibilité de BD à plusieurs tables est une des caractéristiques les plus importantes des SGBD relationnels et permet la création de BD adaptées à des besoins de gestion de l’information très complexes.
Contrairement aux SGBD textuels, les SGBD relationnels ne permettent pas les champs à occurrences multiples. En fait, certains SGBD relationnels – dont Microsoft Access – permettent une certaine forme d’occurrences multiples, mais cette possibilité dépasse le cadre du modèle relationnel et son utilisation est souvent déconseillée par les experts.
À première vue, cela semble être une limite vraiment majeure. En effet, les situations où l’on veut associer plusieurs valeurs au même élément descriptif d’un objet ne sont pas rares. Le champ Dates d’apparition du dernier exemple illustre une telle situation. Pensons aussi à des références bibliographiques, qui doivent chacune pouvoir comporter plusieurs auteurs. Si on ne peut utiliser de champs à occurrences multiples, comment représenter ces situations dans une BD relationnelle ?
On pourrait envisager comme solution de faire inscrire dans un seul champ toutes les valeurs applicables, séparées l’une de l’autre par une espace ou un autre caractère délimiteur prédéterminé, comme une virgule. L’idée serait d’ajouter à la table COLLECTION DE CHAUSSURES D’ESGUELLE SETRA un champ « normal », sans occurrences multiples (puisque cela n’existe pas en relationnel), de type texte sans longueur limite (puisque le nombre de valeurs à inscrire est a priori illimité) et dans lequel on inscrirait les multiples dates d’apparition, séparées l’une de l’autre par un caractère séparateur convenu, par exemple une virgule. Ce champ contiendrait donc des choses comme :
2018-06-30,2019-12-31,2021-09-30
En plus de donner des contenus difficiles à lire, dans les faits, cette approche ne tient pas la route, car elle amène de sérieuses difficultés pour l’interrogation de la BD à l’aide de requêtes de recherche, de même que pour la production de rapports. Elle n’est donc pas satisfaisante.
La vraie solution est d’utiliser deux tables différentes, liées par une clé externe, pour représenter l’information. Illustrons l’approche avec la collection de chaussures et les Dates d’apparition multiples.
D’abord, profitons du fait que le relationnel nous offre la possibilité de nommer la BD séparément des tables qui la composent pour renommer la table COLLECTION DE CHAUSSURES D’ESGUELLE SETRA à quelque chose de plus simple : CHAUSSURES. Le nom COLLECTION DE CHAUSSURES D’ESGUELLE SETRA sera utilisé pour la BD elle-même. Le lien explicite avec le « monde réel » permettant d’interpréter sans ambiguïté les informations de la BD est donc préservé.
Au lieu d’ajouter un champ à la table CHAUSSURES, nous la gardons telle quelle, sans aucun ajout. Puis, nous créons une seconde table, correspondant à la « collection » des dates d’apparition. Cette table, que nous pourrons appeler DATES D’APPARITION, ne contiendra que deux champs : un numéro de chaussure et une date d’apparition applicable à cette chaussure. Si plusieurs dates sont applicables à une même chaussure, alors il y aura autant de fiches avec ce numéro de chaussure dans la table DATES D’APPARITION.
Par « numéro de chaussure », on veut dire bien entendu l’identifiant unique qui identifie une paire de chaussures particulière dans la table CHAUSSURES.
Voici les tables résultantes :
CHAUSSURES Chaussure # Photo Prix d’achat Date d’achat 1 200$ 2018-06-24 2 300$ 2019-07-01 3 800$ 2020-12-25
DATES D’APPARITION Numéro de chaussure Date d’apparition 1 2018-06-30 1 2019-12-31 1 2021-09-30 2 2019-12-31 3 2022-01-01 3 2022-03-15
Le champ Numéro de chaussure contient donc des identifiants qui se retrouvent dans le champ Chaussure #, clé primaire de la table CHAUSSURES. On dit alors que Numéro de chaussure est une clé externe vers la table CHAUSSURES.
Toutes les dates d’apparition d’une paire donnée peuvent donc être retrouvées en sélectionnant dans DATES D’APPARITION les fiches dont le Numéro de chaussure est égal à l’identifiant de la paire en question. Les SGBD relationnels excellent à effectuer très efficacement ce genre d’appariement entre les tables, appelé jointure. Les jointures sont une des opérations de base du langage d’interrogation des SGBD relationnels.
Vous vous demandez peut-être pourquoi nous avons souligné les deux noms de champ Numéro de chaussure et Date d’apparition dans la table CHAUSSURES… C’est qu’en fait, nous utilisons une possibilité des SGBD relationnels (que l’on ne retrouve pas dans les SGBD textuels) qui est de définir une combinaison de champs comme clé primaire d’une table (on parle alors de clé multichamp). Cela veut dire que c’est la combinaison des valeurs que l’on retrouve dans les champs en question qui permettent d’identifier de façon unique chaque fiche de la table. C’est bien le cas ici : un Numéro de chaussure seul ou une Date d’apparition seule n’identifie pas nécessairement une unique fiche. Par contre la combinaison d’un Numéro de chaussure et d’une Date d’apparition identifie à coup sûr au plus une fiche.
Nous avons déjà mentionné le dictionnaire de données d’une BD. Il s’agit d’un document auquel se réfèrent tous les intervenants d’une BD pour en comprendre le fonctionnement. Il est élaboré tout au long de la mise sur pied de la BD et doit être complété au plus tard au moment où la BD est mise en service.
Les éléments suivants doivent être documentés le plus précisément possible dans le dictionnaire de données :
Selon le SGBD spécifique utilisé, plusieurs autres renseignements doivent aussi se retrouver dans le dictionnaire de données, notamment les éventuels paramètres de validation des champs.
Le dictionnaire de données est l’élément de documentation le plus important d’une BD. C’est en quelque sorte la bible de la BD.
