Bortzmeyer Stéphane

bortzmeyer@nic.fr

$Date: 2003-11-26 16:31:16 $

Nous allons expliquer ici les enjeux de la modélisation de données pour un registre DNS, par exemple d'un ccTLD. Un registre, a pour activité centrale la gestion d'une base de données. La publication (whois, et surtout serveur de noms) vient après et peut même parfois être sous-traitée. Mais la base de données est le cœur de métier. Les discussions doivent donc être clairement séparées en : Discussions sur le modèle de données, Discussions sur la présentation de ces données (sur une page Web ou bien via whois). Ainsi, la base de données peut stocker une date abstraite mais la présenter aussi bien comme "2003-11-26" ou bien comme "Mercredi 26 novembre 2003".

Un registre est centré autour d'une base de données, et comporte des éléments périphériques comme le serveur de noms ou bien le serveur whois. La base de données (SBGD : Système de Gestion de Base de Données) est le cœur de l'activité du registre.

Il n'existe pas une méthode unique pour faire un schéma de données. Il existe des règles techniques mais l'intuition joue quand même son rôle. Ce texte est donc surtout un avis personnel. Une grande connaissance des règles métier est nécessaire puisque ce sont elles qu'on veut modéliser. Il existe divers outils informatiques pour créer un schéma. Mais un traitemen t de texte ordinaire peut être suffisant pour les schémas simples. Un exemple de langage de modélisation simple est de représenter les données sous forme de tables. Chaque table comporte une série de champs (ou attributs). Il existe des liens entre les tables, représentés ici par des flèches.

Trois tables, Domains, Contacts et Hosts sont ici représentées. Un exemple simple avec des tables et des liens. Un domain a un contact technique, et un serveur de noms. Il pointe donc vers les tables Contacts et Hosts.

Commencez par le glossaire : des termes non définis sont souvent une cause ultérieure d'incompréhension. Exemples pour un registre : transfert et transmission. Ou bien propriétaire et titulaire. Désolé de répéter mais oubliez la présentation : les noms des attributs, par exemple, ne sont typiquement pas affichés à l'extérieur. Il n'est pas nécessaire qu'ils soient "conviviaux" ou bien "en français". Avant d'ajouter un attribut, demandez-vous : S'il est utile : les logiciels de gestion de base de données modernes ne s'inquiètent pas pour une colonne en plus. Mais chaque colonne doit être remplie au cours des processus métier et plus il y a de colonnes, plus il faut gérer de cas. S'il sera utile. On peut toujours ne pas utiliser un attribut qu'on a. Mais l'inverse est impossible donc il peut être préférable d'avoir d'avantage d'attributs que nécessaire. Pensez à la sémantique, pas uniquement à la représentation technique. Par exemple, la date de création d'un domaine est-elle remise à zéro en cas de changement de titulaire (transmission) ?

Les textes précédents étaient assez haut perchés par rapport à la réalité des bases de données, c'est normal pour une introduction. En fait, les bases sont créées et manipulées à partir d'un langage nommée SQL (Structured Query Language). Le schéma est donc un source écrit en SQL, avec des tables en nombre plus important que celles prévues pour le schéma abstrait, notamment pour mettre en œuvre les liens. Le schéma très simple vue précédemment peut ainsi s'écrire ainsi : CREATE TABLE Domains ( id SERIAL, name TEXT NOT NULL, -- Always stored in lower created TIMESTAMP DEFAULT now(), last_modified TIMESTAMP DEFAULT now(), status TEXT NOT NULL DEFAULT 'reserved' ); CREATE TABLE Contacts ( id SERIAL, handle TEXT DEFAULT new_handle () UNIQUE NOT NULL, firstname TEXT, name TEXT NOT NULL, email TEXT NOT NULL, phone TEXT, address1 TEXT NOT NULL, address2 TEXT, address3 TEXT, city TEXT NOT NULL, zipcode TEXT NOT NULL, country TEXT NOT NULL, created TIMESTAMP DEFAULT now(), last_modified TIMESTAMP DEFAULT now()); CREATE TABLE Hosts ( id SERIAL, name TEXT NOT NULL, -- Name is not unique because a host may have several addresses -- (IPv4 and IPv6 for instance) -- May be null (host outside the managed domain) address INET ); -- La table suivante est un lien CREATE TABLE Contact_Domains ( domain INTEGER REFERENCES Domains (id) NOT NULL, contact INTEGER REFERENCES Contacts (id) NOT NULL, type TEXT NOT NULL CONSTRAINT Valid_domain_contact_types CHECK (type IN ('tech', 'admin', 'billing', 'registrant')) ); -- La table suivante est un lien CREATE TABLE Nameservers ( domain INTEGER REFERENCES Domains (id) NOT NULL, nameserver INTEGER REFERENCES Hosts (id) NOT NULL); Une requête comme "tous les domaines créés depuis le 1er janvier 2003 peut alors s'écrire : SELECT * FROM Domains WHERE created > '2003-01-01';