Comment faire une Base de Données proprement...

Si tu es jeune, tu te poses des questions existentielles qui ramènent Spinoza aux conversations de pochtrons qui se terminent à l'alcool de bois à 5 h du mat' au Macumba.

Si tu es vieux (comme moi), tu as vu tellement d'horreurs qui feraient passer l'Enfer de Dante pour le dernier film de Bob l'Eponge.

Alors, comme faire ?

Rassure-toi, point n'est besoin de se farcir l'Algèbre Relationnelle d'Edgar Codd (1).

Pas plus que des diagrammes UML (2), mais ça viendra après.

On a dû vous parler des Formes Normales, surtout les 3 premières, mais, connaissez-vous celle de Boyce-Codd ? la 4ème ? la 5ème ? Les définitions formelles sont assez obscures.

Alors, je vais vous parler plutôt des Dépendances Fonctionnelles (3) (4), et surtout de graphes de dépendances fonctionnelles, car c'est une approche simple et sûre pour modéliser une base de données.

Car arriver à une base de données normalisée à partir d'un schéma UML me semble franchement difficile.
Il est bien sûr très intéressant de raisonner de manière abstraite dans un premier temps, et un schéma d'objet est tout à fait approprié.
Quand on arrive à la phase plus concrète d'implémentation de schéma base de données, on se retrouve vite avec des redondances vicieuses bien cachées qui sont de véritables bombes à retardement.

Il vaut mieux partir d'une base de données normalisées et introduire des redondances après les avoir mûrement réfléchies que se retrouver des années plus tard avec une BdD complètement pourrie et bricoler du code pour corriger les données...

Les Dépendances Fonctionnelles

Et avant tout, qu'est-ce qu'une dépendance fonctionnelle ? 

Avec des mots simples que peuvent comprendre les gens normaux que nous sommes qui se promènent avec des Santiag ou des Doc Marten's et qui écoutent de la musique avec des vrais instruments, c'est ceci :

"Si une caractéristique A permet de déterminer une autre caractéristique B, alors il y a une dépendance fonctionnelle entre A et B que l'on notera A --> B."

Prenons un exemple tout simple avec une plaque d'immatriculation et un véhicule.

Qui de la poule et l'œuf était avant ?... le dinosaure !

Euh... est-ce que c'est le véhicule qui permet de connaître la plaque ?
Si je vous dis "Fiat 500 Abarth rouge", arriverez-vous à trouver la plaque d'immatriculation, sachant qu'il y a une foule de Fiat 500 de ce modèle et cette couleur ?

Ne serait-ce pas plutôt la plaque d'immatriculation qui me permet d'identifier, de retrouver "LA Fiat 500 Abarth rouge" bien particulière que je recherche... ?

Plaque Immatriculation --> Véhicule

Autre exemple : N° INSEE (ou n° de sécurité sociale) et Personne.

Est-ce le fait de connaître Pierre Martin me permet de déterminer facilement son n° INSEE ?
J'en doute...

Par contre, si j'ai le n° INSEE "1 65 05 13 155 666", je retrouve bien LE Pierre Martin que je recherche.

N° INSEE --> Personne

Précisons maintenant la limite des exemples précédents, il s'agissait de vulgariser le concept, et dans les faits, on va réfléchir un peu plus finement, car dans la théorie des Bases de Données Relationnelles que je vous dispense de dévorer pour justement vous simplifier la vie la définition des "caractéristiques" est très précise.

Je vais donc vous proposer en apéro (ouais !!!) sans alcool (...ooooh...) un petit exercice de modélisation qui permettra d'arriver à un graphe de dépendances fonctionnelles, et de là, la définition d'une entité de base de donnée coulera de source.

Voici l'exercice : "Comment modéliser une personne ?", soit plus simplement : 

• Comment représenter abstraitement une personne ?
• Quelles sont les informations qui caractérisent une personne ?
• Et en particulier, quelles sont les informations qui m'intéressent pour définir une personne ?
  Car je ne vais pas avoir besoin des mêmes infos si je gère une salle de sport, ou un club de musique. C'est un point important à garder dans le coin de la tête, mais...

Restons très simple.

Une personne a un prénom, un nom, est née quelque part à une date bien précise.

Contentons nous de ceci:

• PRENOM,
• NOM,
• DATE DE NAISSANCE,
• LIEU DE NAISSANCE,

Est-ce que ceci est suffisant pour définir précisément une personne ? D'un point de vue abstrait bien, n'entrons pas dans des considérations philosophiques, complexes !

Voici les 5 premiers noms de famille les plus répandus en France :

1. Martin :   250 013 
2. Bernard : 131 330 
3. Thomas : 118 331 
4. Petit :      115 217 
5. Robert :   112 998 

Et voici les prénoms :

1. Marie       2 231 347
2. Jeanne           564 247
3. Françoise      401 427
4. Monique       399 616
5. Catherine      394 699

1. Jean    1 911 457
2. Pierre      892 384
3. Michel    820 560
4. André     712 248
5. Philippe  538 712

Il risque d'y avoir de fortes probabilités pour trouver plus d'une "Marie Bernard" et plus d'un "Pierre Martin"...

C'est bien pour ça qu'a été inventé le n° INSEE qui est unique et attribué à une seule et unique personne. Il faut rajouter cette information à notre liste:

• N° INSEE,
• PRENOM,
• NOM,
• DATE DE NAISSANCE,
• LIEU DE NAISSANCE,

En reprenant la notation des dépendances fonctionnelles "A --> B", on a ceci :

• N° INSEE --> PRENOM,
• N° INSEE --> NOM,
• N° INSEE --> DATE DE NAISSANCE,
• N° INSEE --> LIEU DE NAISSANCE,

Regardez donc votre compte Ameli et celui de quelqu'un d'autre.

Votre n° INSEE détermine de manière UNIQUE votre nom, votre prénom, votre date de naissance, votre lieu de naissance, pas les informations de l'autre personne.

Si l'on poursuit la réflexion sur ce petit exemple, qu'est-ce qu'un lieu de naissance ?

C'est une commune.

Oui, mais il y a :

• 13 Saint-Sauveur
• 12 Sainte-Colombe 
• 11 Beaulieu

Donc la commune ne suffit pas, il faut préciser le département pour faire la différence entre Mars dans la Loire (42) et Mars dans l'Ardèche (07).

Oui, en France, on peut aller sur Mars. Deux fois... Elon Musk en rêve...

Voici notre liste mise à jour : 

• N° INSEE --> PRENOM,
• N° INSEE --> NOM,
• N° INSEE --> DATE DE NAISSANCE,
• N° INSEE --> COMMUNE DE NAISSANCE,
• N° INSEE --> DEPARTEMENT DE NAISSANCE,
• N° INSEE --> PAYS DE NAISSANCE

Et on peut ajouter le pays de naissance.

Représentation graphique avec le Graphe des D.F.

Le graphe des dépendances fonctionnelles se dessine comme suit :

Et... de ce graphe à la définition d'une entité "Personne", il n'y a qu'un pas !

PERSONNE( N° INSEE , PRENOM, NOM, DATE DE NAISSANCE, COMMUNE DE NAISSANCE, DEPARTEMENT DE                         NAISSANCE, PAYS DE NAISSANCE)

Voici l'entité "PERSONNE", une conceptualisation, une définition abstraite d'une personne dans une système d'information, et plus particulièrement, dans une base de données.

L'identifiant est, vous vous en doutez, le N° INSEE.

Si vous ne voyez pas encore l'intérêt de passer par les Dépendances Fonctionnelles et le Graphe qui le représente, ça va sera peut-être plus clair avec l'exemple suivant.

 Comment faire une Base de Données proprement...

Si tu es jeune, tu te poses des questions existentielles qui ramènent Spinoza aux conversations de pochtrons qui se terminent à l'alcool de bois à 5 h du mat' au Macumba.

Si tu es vieux (comme moi), tu as vu tellement d'horreurs qui feraient passer l'Enfer de Dante pour le dernier film de Bob l'Eponge.

Alors, comme faire ?

Rassure-toi, point n'est besoin de se farcir l'Algèbre Relationnelle d'Edgar Codd (1).

Pas plus que des diagrammes UML (2), mais ça viendra après.

On a dû vous parler des Formes Normales, surtout les 3 premières, mais, connaissez-vous celle de Boyce-Codd ? la 4ème ? la 5ème ? Les définitions formelles sont assez obscures.

Alors, je vais vous parler plutôt des Dépendances Fonctionnelles (3) (4), et surtout de graphes de dépendances fonctionnelles, car c'est une approche simple et sûre pour modéliser une base de données.

Car arriver à une base de données normalisée à partir d'un schéma UML me semble franchement difficile.
Il est bien sûr très intéressant de raisonner de manière abstraite dans un premier temps, et un schéma d'objet est tout à fait approprié.
Quand on arrive à la phase plus concrète d'implémentation de schéma base de données, on se retrouve vite avec des redondances vicieuses bien cachées qui sont de véritables bombes à retardement.

Il vaut mieux partir d'une base de données normalisées et introduire des redondances après les avoir mûrement réfléchies que se retrouver des années plus tard avec une BdD complètement pourrie et bricoler du code pour corriger les données...

Les Dépendances Fonctionnelles

Et avant tout, qu'est-ce qu'une dépendance fonctionnelle ? 

Avec des mots simples que peuvent comprendre les gens normaux que nous sommes qui se promènent avec des Santiag ou des Doc Marten's et qui écoutent de la musique avec des vrais instruments, c'est ceci :

"Si une caractéristique A permet de déterminer une autre caractéristique B, alors il y a une dépendance fonctionnelle entre A et B que l'on notera A --> B."

Prenons un exemple tout simple avec une plaque d'immatriculation et un véhicule.

Qui de la poule et l'œuf était avant ?... le dinosaure !

Euh... est-ce que c'est le véhicule qui permet de connaître la plaque ?
Si je vous dis "Fiat 500 Abarth rouge", arriverez-vous à trouver la plaque d'immatriculation, sachant qu'il y a une foule de Fiat 500 de ce modèle et cette couleur ?

Ne serait-ce pas plutôt la plaque d'immatriculation qui me permet d'identifier, de retrouver "LA Fiat 500 Abarth rouge" bien particulière que je recherche... ?

Plaque Immatriculation --> Véhicule

Autre exemple : N° INSEE (ou n° de sécurité sociale) et Personne.

Est-ce le fait de connaître Pierre Martin me permet de déterminer facilement son n° INSEE ?
J'en doute...

Par contre, si j'ai le n° INSEE "1 65 05 13 155 666", je retrouve bien LE Pierre Martin que je recherche.

N° INSEE --> Personne

Précisons maintenant la limite des exemples précédents, il s'agissait de vulgariser le concept, et dans les faits, on va réfléchir un peu plus finement, car dans la théorie des Bases de Données Relationnelles que je vous dispense de dévorer pour justement vous simplifier la vie la définition des "caractéristiques" est très précise.

Je vais donc vous proposer en apéro (ouais !!!) sans alcool (...ooooh...) un petit exercice de modélisation qui permettra d'arriver à un graphe de dépendances fonctionnelles, et de là, la définition d'une entité de base de donnée coulera de source.

Voici l'exercice : "Comment modéliser une personne ?", soit plus simplement : 

• Comment représenter abstraitement une personne ?
• Quelles sont les informations qui caractérisent une personne ?
• Et en particulier, quelles sont les informations qui m'intéressent pour définir une personne ?
  Car je ne vais pas avoir besoin des mêmes infos si je gère une salle de sport, ou un club de musique. C'est un point important à garder dans le coin de la tête, mais...

Restons très simple.

Une personne a un prénom, un nom, est née quelque part à une date bien précise.

Contentons nous de ceci:

• PRENOM,
• NOM,
• DATE DE NAISSANCE,
• LIEU DE NAISSANCE,

Est-ce que ceci est suffisant pour définir précisément une personne ? D'un point de vue abstrait bien, n'entrons pas dans des considérations philosophiques, complexes !

Voici les 5 premiers noms de famille les plus répandus en France :

1. Martin :   250 013 
2. Bernard : 131 330 
3. Thomas : 118 331 
4. Petit :      115 217 
5. Robert :   112 998 

Et voici les prénoms :

1. Marie       2 231 347
2. Jeanne           564 247
3. Françoise      401 427
4. Monique       399 616
5. Catherine      394 699

1. Jean    1 911 457
2. Pierre      892 384
3. Michel    820 560
4. André     712 248
5. Philippe  538 712

Il risque d'y avoir de fortes probabilités pour trouver plus d'une "Marie Bernard" et plus d'un "Pierre Martin"...

C'est bien pour ça qu'a été inventé le n° INSEE qui est unique et attribué à une seule et unique personne. Il faut rajouter cette information à notre liste:

• N° INSEE,
• PRENOM,
• NOM,
• DATE DE NAISSANCE,
• LIEU DE NAISSANCE,

En reprenant la notation des dépendances fonctionnelles "A --> B", on a ceci :

• N° INSEE --> PRENOM,
• N° INSEE --> NOM,
• N° INSEE --> DATE DE NAISSANCE,
• N° INSEE --> LIEU DE NAISSANCE,

Regardez donc votre compte Ameli et celui de quelqu'un d'autre.

Votre n° INSEE détermine de manière UNIQUE votre nom, votre prénom, votre date de naissance, votre lieu de naissance, pas les informations de l'autre personne.

Si l'on poursuit la réflexion sur ce petit exemple, qu'est-ce qu'un lieu de naissance ?

C'est une commune.

Oui, mais il y a :

• 13 Saint-Sauveur
• 12 Sainte-Colombe 
• 11 Beaulieu

Donc la commune ne suffit pas, il faut préciser le département pour faire la différence entre Mars dans la Loire (42) et Mars dans l'Ardèche (07).

Oui, en France, on peut aller sur Mars. Deux fois... Elon Musk en rêve...

Voici notre liste mise à jour : 

• N° INSEE --> PRENOM,
• N° INSEE --> NOM,
• N° INSEE --> DATE DE NAISSANCE,
• N° INSEE --> COMMUNE DE NAISSANCE,
• N° INSEE --> DEPARTEMENT DE NAISSANCE,
• N° INSEE --> PAYS DE NAISSANCE

Et on peut ajouter le pays de naissance.

Représentation graphique avec le Graphe des D.F.

Le graphe des dépendances fonctionnelles se dessine comme suit :

Et... de ce graphe à la définition d'une entité "Personne", il n'y a qu'un pas !

PERSONNE( N° INSEE , PRENOM, NOM, DATE DE NAISSANCE, COMMUNE DE NAISSANCE, DEPARTEMENT DE                         NAISSANCE, PAYS DE NAISSANCE)

Voici l'entité "PERSONNE", une conceptualisation, une définition abstraite d'une personne dans une système d'information, et plus particulièrement, dans une base de données.

L'identifiant est, vous vous en doutez, le N° INSEE.

Si vous ne voyez pas encore l'intérêt de passer par les Dépendances Fonctionnelles et le Graphe qui le représente, ça va sera peut-être plus clair avec l'exemple suivant.