Discussion :

[nuke_y]

fsmrel à raison, le SQL-Oracle tel qu'il est n'est pas du tout une syntaxe mathématique indépendante du système comme ses inventeurs l'auraient souhaités. Peut etre faudrait-il une sorte de "SQL conceptuel" indépendant de tout, que les dévellopeurs transformerait en SQL-pratique en fonction de ce qu'il savent sur la répartition des donnée, index présents etc...

+1, je crois qu'on a atteint un point d'accord là.

[fsmrel]

On peut très bien se donner une discipline aussi bien en implémentation qu'en écriture SQL, et ne s'autoriser qu'a faire des choses conformes aux principes que vous énoncez. Par exemple, lorsqu'on veux faire une projection on utilise EXISTS, lorsqu'on veux des donnée entre 2 entités jointes, on ramène systématiquement les identifiants de chaque entité, on s'assure ainsi d'avoir bien une table comme resultat en restant conforme au principe de fermeture.

Se donner une discipline est effectivement la chose la plus raisonnable qui soit (en tout cas, c’est ce à quoi j’essaie de m’astreindre). Ainsi, s’assurer que le résultat d’une opération est toujours une table, voilà un excellent réflexe ! Dans le cas de SQL, s’il faut en passer par un EXISTS pour garantir la fermeture, alors allons-y sans hésiter.

Au niveau de la projection (je rappelle qu’il s’agit de la partie "Select col1, col2, ..., coln" des requêtes SQL), ramener systématiquement les identifiants de deux entités, ça n’est pas forcément obligé : une fois que la jointure a produit son résultat, si l’utilisateur n’a rien demandé concernant les colonnes identifiantes, la projection ne s’applique qu’aux seules colonnes demandées. Dans le cas de SQL, s’il faut en nécessairement en passer par un DISTINCT pour garantir la fermeture, alors une fois de plus, allons-y sans mégoter. Vous vous doutez maintenant qu’au niveau du Modèle relationnel ceci est inutile, le DISTINCT étant implicite, en vertu du respect imposé du principe de fermeture. Au point que, dans mon premier message, j’avais oublié le DISTINCT dans la requête SQL...

Si le puis me permettre et pour caricaturer, votre exemple sur les développeurs oracle est déja non conforme, car si vous considerez la discipline comme un axe et la ville comme un axe, alors chacune de ses informations doit être référencée dans une table indépendante.

Vous pouvez vous permettre, toutes les hypothèses sont à considérer. Mais, quand vous parlez de conformité, je pose la question : Conformité à quoi ? Pourquoi, en relation avec le pur Modèle relationnel irais-je loger les propriétés Discipline et Ville dans des tables indépendantes ? Faites-vous ici allégeance au modèle relationnel binaire ? à NIAM ?

C'est peut etre d'ailleurs là la source de nos divergences, car pour moi une colonne autre qu'indifiante n'est qu'une propriété d'élément, tant qu'il n'y a pas une table référençant de manières unique toutes ces propriétés possibles on ne peux pas la considerer comme un axe.

De fait, je ne suis pas sûr que nous parlions de la même chose. Vous parlez d’axe : j’ai le sentiment que vous vous positionnez par rapport à un système de type OLAP, donc dans un contexte spécifique. Dans le cas général, pour les théoriciens du Relationnel, une table est un prédicat au sens de la logique des prédicats. Considérons la table suivante, laquelle si j’ai bien compris ne serait pas conforme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Développeur (Dev_Id, Nom,    SGBD,   Ville)
               d1    Albert  Oracle  Paris
               d2    Albert  Oracle  Paris

L’en-tête (ou schéma, peu importe, bref la liste des colonnes) de la table peut être considéré comme un prédicat, les lignes de la table étant les propositions vraies, ayant participé à l’instanciation du prédicat.

Le prédicat se lit :

Le développeur Dev_Id ayant pour nom Nom, compétent pour le sgbd SGBD est localisé la ville Ville.

Et les instances se lisent :

Le développeur d1 ayant pour nom Albert, compétent pour le SGBD Oracle est localisé dans la ville Paris.

Le développeur d2 ayant pour nom Albert, compétent pour le SGBD Oracle est localisé dans la ville Paris.

Cela dit, vous mettez le doigt sur un point important, je veux parler de la normalisation des tables. Disons que la table Développeur est irréprochable du point de vue de la théorie relationnelle car elle est en 5e forme normale. Même chose concernant la table TABLE de nuke_y (table que je rebaptise EMPLOYE parce que TABLE est un mot réservé en SQL...) Cette table qui a pour clé Matricule est en 5e forme normale :

EMPLOYE (MATRICULE, SOCIETE, SERVICE)

Si maintenant on enrichit la table des colonnes SOC_INFO et SERV_INFO :

EMPLOYE (MATRICULE, SOCIETE, SOC_INFO, SERVICE, SERV_INFO)

Du point de vue strictement relationnel elle reste valide, mais viole la 3e forme normale. En effet on a injecté les dépendances fonctionnelles dont les parties gauches ne sont pas clés :

SOCIETE --> SOC_INFO
SERVICE --> SERV_INFO

et le prédicat se lirait :

L’employé de matricule MATRICULE, émarge à la société SOCIETE dont le nom est SOC_INFO, et il fait partie du service SERVICE dont le nom est SERV_INFO

prédicat dans lequel la présence du pronom relatif "dont" (ou équivalent) est un indice de viol de la 3e forme normale.

Du point de vue Relationnel pur, c’est au nom du respect de la 5e forme normale que votre choix de ne pas polluer la table EMPLOYE est justifié, même s’il donne lieu aux 2 tables supplémentaires T_SOC et T_SERV (c’est du reste aussi ce qui se passe quand on respecte les règles de modélisation de Merise). Pour descendre d’un cran, l’utilisation que vous faites de EXISTS est valide parce que vous avez à utiliser SQL et, dans ce contexte, grâce à EXISTS vous respectez le principe de parcimonie (variante du rasoir d’Ockham) : vous économisez un DISTINCT et au plan de la performance, vous économisez des tris. On ne saurait vous en tenir grief.

Maintenant comprenez-mois bien : si dans le contexte SQL (niveau réalisation), EXISTS peut donc s’avérer utile, tout comme DISTINCT peut s’avérer nécessaire pour la projection, en revanche, ils sont sans objets dans le cadre du Modèle relationnel (niveau modèle) et c’est pour cela que je les avais qualifiés de rustines : en effet, si SQL collait au Modèle, ils pourraient disparaître. Mais puisque SQL n’adhère pas au Modèle, vous êtes en contrepartie astreint à continuer à utiliser tous les EXISTS, DISTINCT et autres mots réservés du vocabulaire SQL.

Remarque subsidiaire:
On peut regretter que la pratique du SQL se soit éloignée de la théorie des ensembles, ceci a pour moi une explication simple et bassement matérielle:
Les micro-processeurs ne fonctionnent pas de manière ensembliste mais de manière itérative, la mémoire a une strucure séquentielle.

On est bien d’accord, on n’en est pas encore aux ordinateurs quantiques et l’architecture de nos ordinateurs reste celle de Von Neumann (lequel, soit dit en passant, a "oublié" de nommer dans son rapport les co-auteurs des plans de "sa" machine, à savoir Eckert et Mauchly). De mon côté, j’avais déjà un long passé d’informaticien rompu à l’algorithmique, quand j’ai découvert le Modèle relationnel de Codd et bien que non mathématicien, ça a fait tilt tout de suite. Je me suis mis très vite à l’approche ensembliste, soupçonnant la puissance qu’elle recelait. Un jour j’en ai même eu assez d’entendre les commerciaux et technico-commerciaux de la société C* se moquer de mon SGBDR en prétendant dans tous les cocktails que le leur (très répandu par ailleurs, mais pré-relationnel) était bien supérieur : ça m’a pris 6 mois, mais sous leur contrôle j’ai effectué une étude comparative extrêmement approfondie : au vu des résultats, je me suis rassuré et eux sont devenus verts. Aujourd’hui, les revenus du SGBD I* de la société C* (qui a été rachetée) représentent quelques pourcents de ceux d’Oracle (C* osa même requalifier I* de relationnel pour des raisons purement commerciales).

Tu veux dire que l'optimiseur DB2 sait changer de startégie "à la volée"... mais dans ce cas quel critère le décide à changer de stratégie ? C'est miraculeux comme optimiseur

DB2 est un système propriétaire, qui connaît donc bien les caractéristiques des processeurs, de l'OS et des logiciels IBM avec lesquels il interagit, et il joue là-dessus. Il est capable d'apprécier les ressources machines disponibles pour chaque tâche, d’apprécier en temps réel les performances des requêtes actives (consommation CPU, consommation mémoire, rendement des caches, des accès disques en tous genres...) et il sait se comporter différemment en fonction de la machine IBM (disons des MIPS) dont il dispose. DB2 sait en cours d’exécution d’une requête basculer d’une stratégie update que j’ai définie à une stratégie read-only si les mises à jour sont en fait peu fréquentes, quitte à revenir au besoin à la stratégie initiale. Il sait de la même façon basculer à la volée du mode séquentiel au mode direct et inversement par observation de la nature des opérations et de leur fréquence. Je ne dis pas que ses choix dynamiques sont toujours les meilleurs : son optimiseur est un système expert bien rôdé mais dont les heuristiques peuvent toujours être améliorées et la performance peut s’en ressentir si l’optimiseur fait un mauvais choix. Cela dit, il transforme d’emblée certaines requêtes : je l’ai vu, entre autres, remplacer des jointures de 8 à 10 tables par des jointures impliquant deux fois moins de tables. Je n’ai hélas pas accès aux internes de l’optimiseur pour vérifier jusqu’où DB2 sait aller dans son tuning dynamique. En tout cas, il deviendra encore plus "intelligent" avec le temps. Je n’ai pas encore vérifié qu’il transforme un Minus à un Not Exists (et pour cause, Minus n’est pas encore fourni...) Mais, il dispose de tous les éléments de contrôle de la performance des requêtes pour simuler la chose. On verra bien.

[fsmrel]

fsmrel à raison, le SQL-Oracle tel qu'il est n'est pas du tout une syntaxe mathématique indépendante du système comme ses inventeurs l'auraient souhaités. Peut etre faudrait-il une sorte de "SQL conceptuel" indépendant de tout, que les dévellopeurs transformerait en SQL-pratique en fonction de ce qu'il savent sur la répartition des donnée, index présents etc...

+1, je crois qu'on a atteint un point d'accord là.

Il existe un étalon SQL, c'est le Standard. Le problème est que les éditeurs des SGBDR sont en bonne place dans les comités et que le "SQL conceptuel" indépendant évoqué par remi4444 risque de rester à l'état d'idéal. Mon ami Hugh Darwen en sait quelque chose, pour y avoir rompu bien des lances et se battre pour arriver à faire accepter certaines choses, comme les requêtes SELECT considérées comme des tables (tiens donc...) dans les FROM.

[orafrance]

Il existe un étalon SQL, c'est le Standard. Le problème est que les éditeurs des SGBDR sont en bonne place dans les comités et que le "SQL conceptuel" indépendant évoqué par remi4444 risque de rester à l'état d'idéal.

Ca je ne crois pas

En effet, tout éditeur de SGBD se doit d'être le plus proche de la concurrence pour faciliter les migrations, ainsi, ils ne peuvent se rapprocher que d'un seul dénominateur commun : la norme ANSI... c'est pas pour rien qu'Oracle abandonne le (+) au profit des OUTER JOIN dans l'écriture des jointures externes

Oracle a essayé d'imposer son SQL mais aujourd'hui il est bien obligé de revenir aux fondamentaux s'il veut piquer des parts de marché à la concurrence (Microsoft notamment ).

Donc rassure toi, le SQL conceptuel a encore de beau jour

[remi4444]

Conformité à quoi ? Pourquoi, en relation avec le pur Modèle relationnel irais-je loger les propriétés Discipline et Ville dans des tables indépendantes ? Faites-vous ici allégeance au modèle relationnel binaire ? à NIAM ?

J'avoue que je ne suis pas pointu dans la désignation et le vocabulaire exact de la théorie des ensembles, c'est très loin pour moi, faudrait que je me replonge dans les livres... pourtant j'ai fait des études de math mais ça fait bien longtemps que j'ai trahi mes codisciplinaires en mettant les mains dans le cambouï du développement informatique

Les principes auquels je me réfère sont très généraux, il s'agit du principe roi du traitement de l'information qui est "CHAQUE INFORMATION A UNE SOURCE UNIQUE" et de son corrolaire "L'IDENTIFIANT NE DOIT PAS ETRE UN SIGNIFIANT". Le 2ieme principe est issus du premier car si on donne une signification à l'identifiant, étant donné que ce dernier est voué à apparaitre dans des tables de relations un peu partout, c'est donc le signifiant qui est par là même dupliqué c'est donc une information qui est répliquée un peu partout. D'après les quelques autres post de vous que j'ai pu lire, je crois savoir qu'on sera d'accord sur ce principe.

Pourtant, les merisiens pur sucre d'il y a quelques années étaient je crois pour le principe inverse considérant que si une combinaison de propriétés désignaient de manière unique un objet, alors pas besoin de rajouter une autre colonne, et c'est cette clef candidate qui faisait office d'indentifiant. Cette methode à conduit à quelques catastrophes par le manque de souplesse des modèles générés. (ex: numérotation france-télécom)

Ce principe de séparation entre l'identifiant et le "désignant" rejoint le principe philosophique du mot et de la chose. La chose a son existence propre, et les mots ne sont qu'une interface plus ou moins précises pour permettre à un être humain de désigner la chose. Lorsque le mot se substitue à la chose, alors il y a un grand danger de confusion et de mal-entendu. (ça peu paraitre un peu décalé de parler philo dans un forum informatique mais c'est noel alors tout est permis )

Revenons à l'exemple simple de la tables des développeurs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Développeur (Dev_Id, Nom,    SGBD,   Ville)
               d1    Albert  Oracle  Paris
               d2    Albert  Oracle  Paris

Pour moi les colonne SGBD et Ville contiennent des désignations de choses et non des identifiants, c'est en ça qu'il y a une non conformité avec les principes de bases du traitement de l'information car dans la table des développeurs, on a décidé que Paris s'écrivait "Paris" et pas "PARIS" ni "Lutece" ni "La capitale de la france" et on répète cette règle orthographique à chaque développeur. D'un autre coté, comment savoir si les 2 mots "Paris" se rapporte à la même chose, peut etre y a-t-il Paris au Texas et Paris en france... Les trois colonnes Ville, SGBD et NOM respectivement désignent une ville, désignent un SGBD et désignent un développeur. Sur ces 3 colonnes, une seule est à sa place, celle du nom car le mot (Colonne nom) est associé à la chose (colonne Dev_id), cette colonne est une interface humaine, un commentaire, donc un truc imparfait possiblement éroné ou imprécis, instable, bref un truc sur lequel il ne faut pas trop compter...

Pour illustrer cette différence de nature qu'on attend de ces 3 colonnes, voici un jeu de questions / réponses à propos de ce mini modèle de données à 2 lignes:

"Quels sont les SGBD ?" -> il n'y a qu'Oracle
"Quelles sont les villes ?" -> il n'y a que Paris
"Quels sont les développeurs" -> il y a Albert et Albert

La réponse à la troisieme question est importante car elle dit qu'il y a bien 2 personnes mais qu'ils s'appellent tous les 2 Albert. En revanche, on s'attends à ce que la liste des villes ne nous renvoit qu'un élément puisqu'une seule ville est concernée par la table. Mais comment le SQL va-t-il deviner qu'il ne pas faut répondre "Paris et Paris" alors qu'on trouve normal qu'il réponde "Albert et Albert". Dans tintin "Dupond et Dupond" ça signifiait quelque chose non ? (ok je sais que ça s'écrivait pas pareil mais j'aimais trop l'exemple )

Le hic, c'est que, quand on demande: "quelles sont les villes apparaissant dans la table", implicitement on suppose que les villes sont des choses qui existent indépendament des développeurs et que ensuite ces développeurs travaillent dans ces choses qui n'ont pas besoin d'eux pour exister... et c'est là qu'il y a un manque dans le modèle, il manque la référence des villes. Il faut donc référencer la chose-ville et ne pas se contenter des mots...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Ville (vil_Id, Nom,   Etat)
        v1      Paris       France
        v2      Paris       Texas
        v3      Toulouse  France

Comme cette référence est pour moi obligatoire si on veut se servir de l'information ville ailleur que dans de simples commentaires, alors il n'y a plus d'ambiguité dans l'utilisation SQL puisqu'il faut s'adresser à la table des villes si on veut une liste de villes et ensuite filtrer éventuellement par les EXISTS.

joyeux noel à tous

[fsmrel]

tout éditeur de SGBD se doit d'être le plus proche de la concurrence pour faciliter les migrations, ainsi, ils ne peuvent se rapprocher que d'un seul dénominateur commun : la norme ANSI... c'est pas pour rien qu'Oracle abandonne le (+) au profit des OUTER JOIN dans l'écriture des jointures externes

Je voulais dire que les loups ne se mangent pas forcément entre eux. Un SQL conforme au Modèle relationnel ne les intéresse pas si j’en crois Hugh Darwen qui a vu les choses de l’intérieur. Ils mènent le bal de la norme ISO/ANSI qui au passage devient obèse et mériterait une cure d’amaigrissement.
Quant à l’OUTER JOIN, permettre de coder LEFT (ou RIGHT) OUTER JOIN au lieu de (+), il ne s’agit que d’un problème de syntaxe, impliquant le parser, c’est donc un problème mineur alors que décider de mettre en œuvre l’opérateur lui-même est un problème d’une autre dimension, car on touche à la logique même du SGBD.

Donc rassure toi, le SQL conceptuel a encore de beau jour

A ceci près que le SQL officiel ressemble à Quasimodo et comme lui a certes un bon fond, mais on attend quand même que la bonne fée qui pourra le transformer en prince charmant puisse arriver jusqu’à lui. Je cite Andrew Warden (alias Hugh Darwen) qui écrivait en 1988 (The Relational Journal, Issue 3, March 1988) et considérait avoir été dans la position privilégiée d’avoir utilisé un SGBD authentiquement relationnel :

I have seen Ted Codd’s ideas come true! Let me assure you, everybody, they do work; his promises are not in vain.
I say "privileged", because I suspect that precious few of you can say you’ve had an experience anything like that; for the truth is that no such DBMSs have yet surfaced to the marketplace to reach a wide public. The one I used made a brief, shining appearance in a small scene, and was then abruptly and brutally murdered by a monstrous, grotesque parody of itself.
Unfortunately, this Monster has remarkable powers of self-replication (not true replication, for the clones do tend to have their warts in different places.) and threatens to engulf the planet. However, al is not lost, for the Words, for the Monster, like all the good monsters, has a kind heart, and just a few Magic Words, from a Beautiful Maiden, will turn him and all his clones into Handsome Princes, strutting and wooing and vying for the place in the Maiden heart.
But, and here’s the glitch, the words do have to come from a Beautiful Maiden. The Monster doesn’t listen to Wise Old Men. The Wise Old Men have to teach the Beautiful Maiden the Magic Words, take her by the hand, lead her to the Monster’s Lair and trust to luck.

Je suppose que vous aurez identifié le Monstre qui, chez IBM UK, à Peterlee, a tué ISBL (Information Systems Base Language).

[fsmrel]

"CHAQUE INFORMATION A UNE SOURCE UNIQUE"

Certes. J’interprète ceci comme : La colonne "Ville" correspond à ce que l’on appelle en Merise une propriété naturelle or, les valeurs prises par ce genre de propriétés sont engrangées dans la base de données à partir de sources externes (programmes et/ou utilisateurs finaux). Il est évident qu’un processus peut transmettre la valeur "Paris" aussi bien que la valeur "Parris" (par exemple parce que l’utilisateur a laissé traîner son doigt sur la touche "r" de son clavier. Votre souci est donc de minimiser au maximum la propagation d’anomalies.

Considérons votre table

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Ville (vil_Id, Nom,        Etat)
        v1     Paris       France
        v2     Paris       Texas
        v3     Toulouse    France

Je suis donc d’accord avec votre utilisation de propriétés artificielles (vil_Id en l’occurrence), sachant que si vil_Id est clé primaire de Ville, Nom doit nécessairement être clé alternée (UNIQUE au sens SQL (Create Table)) puisque vil_Id joue le rôle de substitut contrôlé par le seul système (surrogate dans le Relational Model/Tasmania de Ted Codd).

En passant, la colonne Etat doit elle aussi se conformer à la règle et faire l’objet d’une table, puisqu’à un état peuvent être associées plusieurs villes (Paris et Toulouse dans le cas de la France) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Ville (vil_Id, Nom,        Etat_Id)
        v1     Paris       e1
        v2     Paris       e2
        v3     Toulouse    e1

Etat  Etat_Id, Nom   )
        e1     France
        e2     Texas

Cela dit, a priori rien n’interdit de retrouver en table la valeur "Parris" (avec deux "r") :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Ville (vil_Id, Nom,        Etat_Id)
        v1     Paris       e1
        v2     Paris       e2
        v3     Toulouse    e1
        v4     Parris      e1

Votre système permet donc très certainement d’évacuer des anomalies, mais ne garantit pas le zéro-erreur. Il présente un intérêt quand on utilise les opérateurs d’agrégation pour traiter des requêtes du genre : "Quel le pourcentage de développeurs habitant Paris", avec le minimum d’erreurs, dans le cas de données de type alphanumérique. Dans le cas de données du type numérique, il me paraît douteux de devoir mettre en œuvre un surrogate par exemple pour le salaire des développeurs, c’est-à-dire de remplacer la colonne salaire par une colonne Salaire_Id qui renvoie à une table des salaires (dans la mesure où la table des développeurs respecte bien sûr la 3e forme normale, c’est-à-dire qu’il n’existe pas de colonne Date_Salaire telle qu’il existe la dépendance fonctionnelle transitive Dev_Id --> Salaire --> Date_Salaire).

Il n’en demeure pas moins vrai que dans un univers du discours réel, votre remarque reste tout à fait pertinente, surtout quand les concepteurs déclinent Ville en : Ville du client, Ville du fournisseur, Ville du développeur, Ville de ceci, Ville de cela...

"L'IDENTIFIANT NE DOIT PAS ETRE UN SIGNIFIANT" ...
Pourtant, les merisiens pur sucre d'il y a quelques années étaient je crois pour le principe inverse considérant que si une combinaison de propriétés désignaient de manière unique un objet, alors pas besoin de rajouter une autre colonne, et c'est cette clef candidate qui faisait office d'indentifiant. Cette methode à conduit à quelques catastrophes par le manque de souplesse des modèles générés.

Que l’identifiant ne soit pas un signifiant, nous sommes parfaitement en phase. Par ailleurs, ce ne sont quand même pas tous les merisiens pur sucre qui ne tiennent pas compte de cette règle de bon sens. Par exemple, dans les années quatre-vingts, Yves Tabourier écrivait dans De l’autre côté de MERISE (Les éditions d’organisation, 1986), page 80 :

Considérer l’identifiant comme une propriété particulière est donc, selon moi, un abus de langage, malgré l’usage consacré par de nombreux auteurs. Une raison plus profonde pour laquelle l’identifiant «a l’aspect d’une propriété mais n’est pas une propriété» est que la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques. L’expérience montre d’ailleurs que l’usage des «identifiants significatifs» (ou «codes significatifs») a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets.

Je rappelle aussi ce que j’ai écrit sur ce site :

Je me souviens du système préconisé par les concepteurs dans une grande banque pour identifier les entreprises : leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par ailleurs, le Siren était propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. J’ai fait observer que l’INSEE envoyait tous les mois les nombreux correctifs modifiant le Siren des entreprises. Aussitôt, l’identifiant de l’entreprise fit l’objet d’une propriété nouvelle et artificielle, Entreprise_Id. Le numéro de Siren devint un simple point d'entrée dans la table, à usage de l'utilisateur.

Cf. message #19, http://www.developpez.net/forums/sho...=225898&page=2

Ce principe de séparation entre l'identifiant et le "désignant" rejoint le principe philosophique du mot et de la chose.

Certes, et le grand philosophe et logicien Willard Van Orman Quine a écrit des choses importantes sur le sujet ("Word and Object"), mais qui risqueraient de nous emmener bien au-delà de ce débat (qui avait initialement EXISTS pour thème...) J’effleure quand même le thème un peu plus loin dans ce message.

comment savoir si les 2 mots "Paris" se rapporte à la même chose, peut etre y a-t-il Paris au Texas et Paris en France.

Il est évident que dans le cas de ma table Développeur (Dev_Id, Nom, SGBD, Ville), je ne me suis sans doute limité aux villes texanes (Why not?) auquel cas la notion d’état n’a pas lieu d’être prise en considération. Mon exemple est simpliste, car l’objet n’était pas de modéliser un univers du discours réel, lequel aurait conduit à ce que Ville et SGBD fissent l’objet de propriétés dans des entités-types dédiées.

Typage des données

Tant qu’à essayer d’éliminer le plus possible les anomalies des la base de données, je suis partisan du typage des données tel que le propose le Modèle relationnel, c’est-à-dire en y développant des contraintes.
Supposons que nous définissions le type Ville pour les noms de villes et que la contrainte définie par le concepteur soit : "Le nom de la ville doit mesurer au moins 2 caractères, le 1er caractère doit être une majuscule et les suivants des minuscules" (on peut évidemment raffiner la contrainte, mais notre objet n’est pas là, nous voulons simplement illustrer par un exemple simple).

Le type Ville peut être ainsi défini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
TYPE Ville POSSREP {X CHAR CONSTRAINT
                               IF LENGTH(X)>1 THEN
                                     IS_UPPERCASE SUBSTR (X,1,1) 
                                     AND IS_LOWERCASE SUBSTR (X,2,LEN(X)-1)
                               ...
                               END IF
                   } ;

Dans ce modeste exemple, IF et END IF font partie de la grammaire. LENGTH, SUBSTR IS_UPPERCASE et IS_LOWERCASE sont des fonctions définies par le SGBD ou développées par nous-mêmes.

Ne vous préoccupez pas du mot-clé POSSREP (possible representation), qui permet au développeur d’utiliser différentes représentations pour un type donné (cas du type POINT pour lequel on voudrait représenter les coordonnées d’un point aussi bien sous forme de coordonnées cartésiennes que polaires).

cette colonne est une interface humaine, un commentaire, donc un truc imparfait possiblement éroné ou imprécis, instable, bref un truc sur lequel il ne faut pas trop compter

J’en sais quelque chose, puisque pour l’INSEE Albert habite 12 B BAGNEUX, alors qu’en réalité il habite 12 bis, rue de Bagneux...

voici un jeu de questions / réponses à propos de ce mini modèle de données à 2 lignes:
"Quels sont les SGBD ?" -> il n'y a qu'Oracle
"Quelles sont les villes ?" -> il n'y a que Paris
"Quels sont les développeurs" -> il y a Albert et Albert
La réponse à la troisieme question est importante car elle dit qu'il y a bien 2 personnes mais qu'ils s'appellent tous les 2 Albert. En revanche, on s'attends à ce que la liste des villes ne nous renvoit qu'un élément puisqu'une seule ville est concernée par la table. Mais comment le SQL va-t-il deviner qu'il ne pas faut répondre "Paris et Paris" alors qu'on trouve normal qu'il réponde "Albert et Albert". Dans tintin "Dupond et Dupond" ça signifiait quelque chose non ? (ok je sais que ça s'écrivait pas pareil mais j'aimais trop l'exemple )

Je pense que vous voulez en faire dire plus à la base de données qu’elle ne peut le faire. Personnellement, pour en revenir à mes instances de la logique des prédicats, je dirai que mon univers est composé de deux instances de développeurs lesquels ont même nom, utilisent le même SGBD et sont localisés dans la même ville. "Albert" reste une chaîne de caractères, contrairement à Albert. En outre, selon l’utilisateur, l’information importante de la table n’est peut-être pas le nom des développeurs, mais le fait de savoir qu'il peut présenter à ses clients des gens qui connaissent le SGBD Oracle.

Quant au mot et au nom, pour citer à nouveau Quine :

Lorsque nous écrivons :

Le quatrième mot de «L’invitation au voyage» rime avec le huitième

nous mentionnons les mots 'sœur' et 'douceur', mais utilisons des noms de ces mots. Nous écrivons 'rime avec' non entre des mots qui riment mais entre leurs noms. Nous pouvons également écrire :

'sœur' rime avec 'douceur',

mais ici à nouveau nous utilisons des noms pour les mots assurant la rime — les noms étant alors formés par l’adjonction de guillemets simples. Il ne serait pas seulement erroné, mais contraire à la grammaire et dépourvu de sens d’écrire :

Sœur rime avec douceur.

En poussant le bouchon comme le font D & D (je veux dire Date et Darwen plutôt que Dupond et Dupont...) le mot 'table' en SQL est ambigu et doit faire l’objet d’un dédoublement : 'variable de table' et 'valeur de table'. Quand vous écrivez 'Create Table Développeur...', vous définissez la variable de table Développeur, prenant pour valeur l’ensemble vide. Après une opération réussie de mise à jour telle qu’'Insert Into Table Développeur...', la variable a pris une autre valeur. Il en est de même à chaque fois que je modifie au moins un bit dans la table.

[nuke_y]

Qui se dévoue pour synthétiser tout ce qui a été dit ici dans un tutoriel ?

[remi4444]

Bonjour,
ça me démange de faire une longue réponse argumentée mais j'ai pas le temps malheureusement... et je reviendrai plus tard sur la question des données numériques (salaires) et aussi des dates.

Pour aller à l'essentiel, je rebondirai simplement sur l'argument suivant:

je dirai que mon univers est composé de deux instances de développeurs lesquels ont même nom, utilisent le même SGBD et sont localisés dans la même ville. "Albert" reste une chaîne de caractères, contrairement à Albert. En outre, selon l’utilisateur, l’information importante de la table n’est peut-être pas le nom des développeurs, mais le fait de savoir qu'il peut présenter à ses clients des gens qui connaissent le SGBD Oracle.

Pour moi ces 3 informations n'ont pas la meme nature. Du moment que l'application n'a pas pour but de faire des stats sur les usages de prénoms ou de noms, alors l'information "nom" n'est qu'un commentaire, une explication attachée à l'employé et à rien d'autre. Lorqu'on parle de la ville ou du SGBD, et dans la mesure ou on compte faire recherches ou comptages sur ces données, alors implicitement, on fait référence à des choses ayant leurs existances propres indépendement de celles des employés. Si on dit "roger et albert travaillent dans la même ville", c'est dire qu'il font référence à la meme chose-ville, donc que quelque part il y a une référence des villes. Peu importe si l'identifiant de ville est signifiant ou non, peu importe qu'il soit de type numérique majuscule minuscule, c'est un identifiant donc il doit etre le meme pour la meme ville et différent pour 2 villes différentes. Si on ne faisait pas cette référence implicite alors on dirais "roger travaille dans une ville portant le meme nom que la ville dans laquelle travaille albert" nuance...
En revanche "albert" et "albert" travaillent dans la même ville, dupond et dupond sont parti dans la même fusée dans l'album "on a marché sur la lune"...