Modélisation de données

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 :

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".

Figure 1. Les composants d'un registre

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.

Figure 2. Les tables et leurs liens

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.

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 1^er janvier 2003 peut alors s'écrire :

SELECT * FROM Domains WHERE created > '2003-01-01';