Discussion :

[Erwy]

C'est une affirmation un peu rapide.

Non, c'est la somme d'observation, en echec comme en reussite, de quelques années de travail dans ce milieu.
quand on voit toujours échouer pour les même raisons, et que d'autres projets évitant cet écueil fonctionnent (en tout cas bien mieux que les précédents), on peut aller plus loin que de croire aux coïncidences.
Mais il est toujours "amusant" de constater que certains n'apprennent jamais de leurs erreurs, enfin cela reste amusant tant qu'on n'est pas sur leur projet...
Maintenant, comme précisé avant, je ne fais pas de la robotique, du calcul scientifique, de l'imagerie ou autre, simplement de l'informatique de gestion plutot basique avec du fonctionnel qui consiste en facture, formulaire et autre réglementation...

[fsmrel]

Vous faites comment quand le process métier change et que votre modèle de données ne convient pas/plus?
Parce que partir de rien c'est somme toute plus facile.

Ben voyons... Croyez-vous qu’en quarante ans de modélisation de bases de données, d’audit, de rattrapage de situations catastrophiques (batchs quotidiens durant 240 heures et autres joyeusetés...) j’ai passé mon temps à bâtir à partir de rien ? Quand vous aurez de la bouteille, quand — sur de gros projets — vous aurez la responsabilité d’engager votre entreprise en ce qui concerne les pénalités (robustesse de la base de données, performances attendues, aptitude à évoluer, ...) alors vous prendrez conscience de la légèreté de votre propos.

A l’occasion, méditez sur la courbe du soleil, même si celle-ci à quelque chose d’un peu académique...

quand on voit toujours échouer pour les même raisons, et que d'autres projets évitant cet écueil fonctionnent (en tout cas bien mieux que les précédents), on peut aller plus loin que de croire aux coïncidences.

Vous avez parfaitement raison. Ainsi, des trois petits cochons, il y a Naf-Naf qui prévoit et construit une maison en briques, résistant aux assauts du loup et à l’épreuve du temps, tandis que ses frères n’ont aucunement conscience de l’inanité de leur entreprise (l’auront-ils un jour ?)





Erwy, keep up the good job, vous allez dans le sens de Goethe et de tous les sages qui rappellent que « Ceux qui ne tiennent pas compte du passé sont condamnés à le revivre.»

[Erwy]

Vous avez parfaitement raison. Ainsi, des trois petits cochons, il y a Naf-Naf qui prévoit et construit une maison en briques, résistant aux assauts du loup et à l’épreuve du temps, tandis que ses frères n’ont aucunement conscience de l’inanité de leur entreprise (l’auront-ils un jour ?)

J'espère qu'il n'y a aucun sous-entendu comme quoi je coderais comme un porc ?

[Jester]

Ben voyons... Croyez-vous qu’en quarante ans de modélisation de bases de données, d’audit, de rattrapage de situations catastrophiques (batchs quotidiens durant 240 heures et autres joyeusetés...) j’ai passé mon temps à bâtir à partir de rien ? Quand vous aurez de la bouteille, quand — sur de gros projets — vous aurez la responsabilité d’engager votre entreprise en ce qui concerne les pénalités (robustesse de la base de données, performances attendues, aptitude à évoluer, ...) alors vous prendrez conscience de la légèreté de votre propos.

Merci pour cette réponse légère qui ne renseigne pas sur le fond. Une entreprise qui évolue voit forcément (enfin c'est mon postulat et ce que je constate) des refontes de services et autres décisions qui à mon sens ont un impact sur le modèle de données même si celui-ci était parfait au début. Si la spécification change, il est fort possible que le modèle de données doive changer aussi. Après vous semblez penser ici que non. Soit.

[B.AF]

Meric pour les petits cochons : un fou rire.


Pour le propos, même sur une application de gestion il peut y avoir des évolutions ou des modifications. Et ...C'est normal, puisqu'une application est conçue pour répondre à un existant et pas à une prédiction.
Ca n'a rien d'un postulat technologique ou d'une bonne pratique. Une application répond à un métier, ce métier ou l'organisation qui exerce ce métier peut changer, donc l'application changera. C'est "un ordre normal".

Cependant, je pense qu'un bon design est aussi un design qui arrive à tenir compte de la capacité du sujet de l'application à évoluer (qui est relativement facile à percevoir si l'existant est bien analysé). En tous cas beaucoup d'éditeurs en finance par exemple se sont cassées les mains sur ces problématiques : systèmes bien conçus en T mais trop rigides et bloquant le time to market des nouvelles fonctionnalités parce que croissance exponentielle du coût de l'ajout fonctionnel.

Avec généralement :
- La reprise des données historiques (et souvent si il y a des paliers, il y a une règle définissant le comportement de l'existant et du nouveau)
- La non régression de ce qui existait
- L'adhérence de la nouveauté.

Je ne pense pas que partir du principe qu'un modèle sera statique soit une bonne approche. En revanche je suis pour le réemploi de ce qui est éprouvé, mais c'est un autre sujet.

Une application qui est codé sur un L4G avec un bon framework de tests unitaires et de tests de charge devient sur ce type de conception beaucoup plus productif qu'un SGBD avec des procs stocks (Qui quoi qu'on puisse en dire ne sont pas par définition testables). Il faut donc faire très attention à ces choix.

[SQLpro]

Mais il n'y a rien qui évolue plus facilement qu'un modèle de données, puisque c'est quelque chose de strictement dynamique contrairement au code itératif qu'il soit objet ou non...
Par exemple je peut rajouter une table et des procédures stockée à la volée, ce qui est infaisable en code itératif. Je peut aussi modifier la structure d'une table et la refactoriser par une vue. Un objet nécessite l'arrêt du code itératif que ce soit un service ou une application, ce qui n'est pas le cas du SGBDR !

Le problème est que les développeurs savent rarement que les vues existent et lorsqu'il sont conscient qu'il existe des vues ils ne savent même pas qu'on peut les mettre à jour ! Or pour que ceci soit intéressant il faut faire un modèle externe de données à base de vues SQL.

J'ai fait le test il y a moins d'une semaine dans une conférence chez Microsoft de spécialiste BD (réunion du GUSS). très peu savaient qu'une vue pouvait être misajourable et pratiquement aucun qu'on pouvait mettre à jour n'importe quelle vue, même la plus complexe via des trigger INSTEAD OF !

A +

[B.AF]

Mais il n'y a rien qui évolue plus facilement qu'un modèle de données, puisque c'est quelque chose de strictement dynamique contrairement au code itératif qu'il soit objet ou non...
Par exemple je peut rajouter une table et des procédures stockée à la volée, ce qui est infaisable en code itératif. Je peut aussi modifier la structure d'une table et la refactoriser par une vue. Un objet nécessite l'arrêt du code itératif que ce soit un service ou une application, ce qui n'est pas le cas du SGBDR !

Le problème est que les développeurs savent rarement que les vues existent et lorsqu'il sont conscient qu'il existe des vues ils ne savent même pas qu'on peut les mettre à jour ! Or pour que ceci soit intéressant il faut faire un modèle externe de données à base de vues SQL.

J'ai fait le test il y a moins d'une semaine dans une conférence chez Microsoft de spécialiste BD (réunion du GUSS). très peu savaient qu'une vue pouvait être misajourable et pratiquement aucun qu'on pouvait mettre à jour n'importe quelle vue, même la plus complexe via des trigger INSTEAD OF !

A +

INSTEAD OF est un effectivement puissant et utile, oui on peut ajouter des objets à la volée (encore que la portée soit quand même limitée). Mais ça reste des logiques de développement.
Ca n'en fait pas un outil testable.Je ne veux pas dire que le SQL ou que SQL Server n'est pas un bon produit, je dis simplement que la testabilité n'est pas un point fort des SGBD et du SQL.

Maintenant dans ce que je connais des bases objet, c'est aussi un calvaire, et dans le NoSql, la question se pose aussi parce qu'il y a toujours une transposition dans un langage tiers (aka la client) et que ce client aujourd'hui est principalement un langage objet. Donc il y a toujours un changement de paradigme.

Mais je veux bien passer par un exemple pour que l'on étudie les possibilités, parce qu'à vous lire, j'ai l'impression que certains d'entre vous ont trouvé la possibilité pour tester correctement la logique métier dans la base de données. Donc je suis assez preneur.

[fsmrel]

Si la spécification change, il est fort possible que le modèle de données doive changer aussi.

Quand vous aurez participé à des fusions d’entreprises ayant le même métier, donc à l’union-intersection-différence de leurs SI, vous constaterez qu’une structure de base de données bien conçue, solide, à la Naf-Naf, connaît évidemment une évolution mais pas de révolution (je ne parle évidemment pas des conséquences sur le plan humain). Faites l’expérience, c’est extrêmement intéressant.

Et le rôle du SGBD n'est pas neutre dans cette affaire. Pour avoir joué à cela avant et après l'arrivée des SGBD relationnels, je peux dire que l'utilisation d'un SGBDR fait gagner énormément de temps : d'expérience, je confirme ce que dit SQLpro.

[B.AF]

Quand vous aurez participé à des fusions d’entreprises ayant le même métier, donc à l’union-intersection-différence de leurs SI, vous constaterez qu’une structure de base de données bien conçue, solide, à la Naf-Naf, connaît évidemment une évolution mais pas de révolution (je ne parle évidemment pas des conséquences sur le plan humain). Faites l’expérience, c’est extrêmement intéressant.

Et le rôle du SGBD n'est pas neutre dans cette affaire. Pour avoir joué à cela avant et après l'arrivée des SGBD relationnels, je peux dire que l'utilisation d'un SGBDR fait gagner énormément de temps : d'expérience, je confirme ce que dit SQLpro.

D'où justement, peut être chez moi une méconnaissance du SGBD, mais comment justement au design laisser de la place à l'évolution ce qui veut dire penser à la possibilité que la base évolue, tout en garantissant sa fiabilité ?

[fsmrel]

D'où justement, peut être chez moi une méconnaissance du SGBD, mais comment justement au design laisser de la place à l'évolution ce qui veut dire penser à la possibilité que la base évolue, tout en garantissant sa fiabilité ?

Faire évoluer un Modèle Conceptuel de Données ou un diagramme de classes, c’est élaguer, couper les branches mortes, faire des greffes, etc., c'est-à-dire supprimer des entités-types, en ajouter, y ajouter des attributs, même chose pour les associations-types, et les contraintes (disons assertions au sens SQL, contraintes référentielles, etc.) Cela a un impact immédiat sur la structure de la base de données. Mais tout SGBD relationnel (le mien en tout cas) gère son propre catalogue actif (organisé sous forme de vues, donc accessible à coup de requêtes SQL), que l’on peut interroger pour connaître à tout moment l’impact du moindre changement sur les tables, les vues, les assertions, les triggers, les contraintes référentielles, les procédures, les programmes contenant des requêtes SQL, etc. Si par exemple vous supprimez une table, si vous en modifiez la structure ou ses relations avec les autres tables, en deux coups de cuiller à pot, par requête, vous serez à même de connaitre exactement les conséquences de cette action, donc d’agir en toute sérénité. En revanche, si votre SGBD n’a pas de catalogue, vous serez mal et devrez tout contrôler manuellement, ce qui peut prendre beaucoup de temps et n’est pas d'une fiabilité à toute épreuve.

[B.AF]

Faire évoluer un Modèle Conceptuel de Données ou un diagramme de classes, c’est élaguer, couper les branches mortes, faire des greffes, etc., c'est-à-dire supprimer des entités-types, en ajouter, y ajouter des attributs, même chose pour les associations-types, et les contraintes (disons assertions au sens SQL, contraintes référentielles, etc.) Cela a un impact immédiat sur la structure de la base de données. Mais tout SGBD relationnel (le mien en tout cas) gère son propre catalogue actif (organisé sous forme de vues, donc accessible à coup de requêtes SQL), que l’on peut interroger pour connaître à tout moment l’impact du moindre changement sur les tables, les vues, les assertions, les triggers, les contraintes référentielles, les procédures, les programmes contenant des requêtes SQL, etc. Si par exemple vous supprimez une table, si vous en modifiez la structure ou ses relations avec les autres tables, en deux coups de cuiller à pot, par requête, vous serez à même de connaitre exactement les conséquences de cette action, donc d’agir en toute sérénité. En revanche, si votre SGBD n’a pas de catalogue, vous serez mal et devrez tout contrôler manuellement, ce qui peut prendre beaucoup de temps et n’est pas d'une fiabilité à toute épreuve.

Ok je veux bien reconnaitre que le sysobjet et ses amis permettent de vérifier pas mal de choses.

Cependant imaginons que vous ayez une entité lambda.
Jusqu'à j, tout va bien, l'entité se suffit, et pour la traiter, il existe un jeu d'UDF ou de SP qui déterminent un résultat qui peut être exploité dans d'autres traitements métiers et éventuellement des triggers assurant un complément d'intégrité ou une validation métier le cas échéant.
Un jour, la règle métier change avec un motif légal qui fait que n attributs de l'entité existent sur une plage de date valide. Cette règle spécifie un moyen de déterminer à J+3 les nouvelles données, sachant qu'il faut que chaque règle métier soit modifiée de façon à tenir compte des nouveaux attributs, correctement inscrits dans le temps.
Naturellement, il existe aussi une relation fonctionnelle avec d'autres éléments.

Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

Merci parce que je me pose beaucoup de questions là dessus.

[Erwy]

Mais tout SGBD relationnel (le mien en tout cas) gère son propre catalogue actif (organisé sous forme de vues, donc accessible à coup de requêtes SQL), que l’on peut interroger pour connaître à tout moment l’impact du moindre changement sur les tables, les vues, les assertions, les triggers, les contraintes référentielles, les procédures, les programmes contenant des requêtes SQL, etc.

Pour ma culture, ou est-ce qu'on peut trouver de la doc sur ce sujet.
C'est l'un de mes gros points faibles en base de donnée

Par rapport à l'évolution d'un modèle de donnée je pense que j'ai mal exprimer ma pensée, ce n'est pas mon domaine d'origine donc je manque un peu de vocabulaire théorique...
Le mieux est peut être que reprenne l'analogie de la construction de la maison
Si on considère une maison,percer une fenêtre, une porte , constuire une annexe comme un garage ne change pas réellement la nature de ma maison ( à condition de respecter certaines contraintes comme faire attention au mur porteur prévoir les lintaux dalles etc...) de même que rajouter des tables et , à la limite des colonnes (à conditions qu'il n'y ait pas un couillon qui ait laissé trainer un select * ).De mon point de vue ce n'est pas une vrai évolution du modéle (toutes proportions gardées).
Par contre rajouter un étage, là c'est un problème et si ce n'était pas prévu dès l'origine , tu risque fort en plus un jour , de pouvoir visiter ton grenier sans avoir besoin d'y monter, de même qu'éclater des tables ou concaténer des colonnes.Si on en arrive là , il y a de fortes chances que quelqu'un ce soit planté dans son analyse des données (si analyse il y a eu )

Pour ce qui est de l'analyse métier pour le modèle de donnée, de mon point de vue (et par rapport à mon milieu professionnel), il faut s'en méfier.
Il vaut mieux chercher à obtenir et analyser les données qu'ils utilisent en priorité (formulaire facture...).
Les métiers changent, évoluent et surtout , même quand ils sont théoriquement une "chaîne", cela ne marche pas forcement comme ça.
Je m'explique: soit 3 personnes A,B,C qui se transmettent l'information et F l'info origianl.
On doit faire une application pour B, et, dans un futur proche C.
A à l'information originale F il la traite et transmet le résultat à B qui effetue la même tâche et le transmet à C pour l'utilisation finale.
Dans ce magnifique fonctionnement théorique, il suffit de connaitre le format des données fournit par A pour avoir un schema de données utilisable pour B et C mais , dans ma réalité , si on creuse un peu , on s'aperçoit que :
- pour affiner et simplifier leur tavail on s'aperçoit que B et C utilisent F partiellement
- les rôles entre A et B ne sont pas toujours aussi clair que sur le papier pour
des raisons d'échelles d'effectifs et sont peut être amené à évoluer.
etc...
Donc à court terme, en basant son étude sur la production de A, on va dans le mur et il faudrait plutôt basé son modèle sur celui de F, même si on n'en utilise pas tout à l'instant T , il sera plus facile à faire évoluer à l'instant T+1.
J'ai un avantage c'est vrai.Dans ma branche, la nature de F bouge peu, et quand il y a changement, les concertations , et les implications, sont telles qu'on est prévenu au minimum 1 ou 2 ans avant, mais les "métiers" eux sont plutot "volatiles" , je ne pense pas néanmoins être une exception en informatique de gestion.

[SQLpro]

...
Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

Le faire sur un serveur de test avec un sauvegarde...
Quand à la couverture complète des cas, ne rêvez pas c'en est toujours au stade théorique quelque soit la technique, l'outil et les langages utilisés !
Mais il existe des robots de test pour SQL (non régression).

Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

Un outil de modélisation comme Power AMC est fait pour cela !

A +

[B.AF]

Le faire sur un serveur de test avec un sauvegarde...
Quand à la couverture complète des cas, ne rêvez pas c'en est toujours au stade théorique quelque soit la technique, l'outil et les langages utilisés !
Mais il existe des robots de test pour SQL (non regeression).

Un outil de modélisation comme Power AMC est fait pour cela !

A +

PowerAmc fait des choses mais il ne peut pas créer de l'intelligence métier.
La couverture complète des cas, c'est une des applis que j'ai créé qui tient plusieurs milliers de transactions par jour avec un sla sur la latence et la qualité. 100% des domaines fonctionnels de l'application sont testés et testables. Et mine de rien, le temps perdu à le faire et un vrai temps gagné à la maintenance. Ce n'est pas un rêve c'est parfaitement possible.

[SQLpro]

Pour ma culture, ou est-ce qu'on peut trouver de la doc sur ce sujet.
C'est l'un de mes gros points faibles en base de donnée

Par défaut ce sont les vues d'information de schéma : http://sqlpro.developpez.com/cours/s...age=partie2#L9

Par rapport à l'évolution d'un modèle de donnée je pense que j'ai mal exprimer ma pensée, ce n'est pas mon domaine d'origine donc je manque un peu de vocabulaire théorique...
Le mieux est peut être que reprenne l'analogie de la construction de la maison
Si on considère une maison,percer une fenêtre, une porte , constuire une annexe comme un garage ne change pas réellement la nature de ma maison ( à condition de respecter certaines contraintes comme faire attention au mur porteur prévoir les lintaux dalles etc...) de même que rajouter des tables et , à la limite des colonnes (à conditions qu'il n'y ait pas un couillon qui ait laissé trainer un select * ).De mon point de vue ce n'est pas une vrai évolution du modéle (toutes proportions gardées).
Par contre rajouter un étage, là c'est un problème et si ce n'était pas prévu dès l'origine , tu risque fort en plus un jour , de pouvoir visiter ton grenier sans avoir besoin d'y monter, de même qu'éclater des tables ou concaténer des colonnes.Si on en arrive là , il y a de fortes chances que quelqu'un ce soit planté dans son analyse des données (si analyse il y a eu )

Relisez les règles de CODD... en créant la théorie des SGBDR CODD avait tout prévue depuis le départ. Lisez en particulier les règles 8 à 11 et surtout la 9... Vous comprendrez que l'utilisation du modèle externe combiné au respect de cette règle permet une très grande souplesse !

Pour ce qui est de l'analyse métier pour le modèle de donnée, de mon point de vue (et par rapport à mon milieu professionnel), il faut s'en méfier.
Il vaut mieux chercher à obtenir et analyser les données qu'ils utilisent en priorité (formulaire facture...).
Les métiers changent, évoluent et surtout , même quand ils sont théoriquement une "chaîne", cela ne marche pas forcement comme ça.
Je m'explique: soit 3 personnes A,B,C qui se transmettent l'information et F l'info origianl.
On doit faire une application pour B, et, dans un futur proche C.
A à l'information originale F il la traite et transmet le résultat à B qui effetue la même tâche et le transmet à C pour l'utilisation finale.
Dans ce magnifique fonctionnement théorique, il suffit de connaitre le format des données fournit par A pour avoir un schema de données utilisable pour B et C mais , dans ma réalité , si on creuse un peu , on s'aperçoit que :
- pour affiner et simplifier leur tavail on s'aperçoit que B et C utilisent F partiellement
- les rôles entre A et B ne sont pas toujours aussi clair que sur le papier pour
des raisons d'échelles d'effectifs et sont peut être amené à évoluer.
etc...
Donc à court terme, en basant son étude sur la production de A, on va dans le mur et il faudrait plutôt basé son modèle sur celui de F, même si on n'en utilise pas tout à l'instant T , il sera plus facile à faire évoluer à l'instant T+1.
J'ai un avantage c'est vrai.Dans ma branche, la nature de F bouge peu, et quand il y a changement, les concertations , et les implications, sont telles qu'on est prévenu au minimum 1 ou 2 ans avant, mais les "métiers" eux sont plutot "volatiles" , je ne pense pas néanmoins être une exception en informatique de gestion.

J'ai mis en gras le point ou vous vous trompez.... On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....
A partir de là, votre modèle sera plus souple car il contiendra des données "purifiées" et non spécifique à un usage.
Chaque fois que l'on modélise pour un usage on se trouve bloqué.
C'est pourquoi il faut modéliser les données intrinsèquement et non spécifiquement, exercice en général difficile à faire pour des personnes orientées fonctionnel !
Ce qui ne veut pas dire que certaines entités et associations clairement identifiées et bien distinctes des autres ne soit spécifique au fonctionnel.

Par exemple dans mes modèles de données, je tague différemment les entités data, les entités pilotant les traitement ou les IHM et les entités contenant des données "externes".


A +

[B.AF]

On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....
A partir de là, votre modèle sera plus souple car il contiendra des données "purifiées" et non spécifique à un usage.
Chaque fois que l'on modélise pour un usage on se trouve bloqué.
C'est pourquoi il faut modéliser les données intrinsèquement et non spécifiquement, exercice en général difficile à faire pour des personnes orientées fonctionnel !

A +

Ca il faudrait le mettre en note que tout le monde puisse le lire et le relire. C'est excellent.

[fsmrel]

Imaginons que vous ayez une entité lambda.
Jusqu'à j, tout va bien, l'entité se suffit, et pour la traiter, il existe un jeu d'UDF ou de SP qui déterminent un résultat qui peut être exploité dans d'autres traitements métiers et éventuellement des triggers assurant un complément d'intégrité ou une validation métier le cas échéant.

Vous parlez de l’exploitation des données. On est donc hors de la modélisation des données proprement dite.

Un jour, la règle métier change avec un motif légal qui fait que n attributs de l'entité existent sur une plage de date valide.

Vous faites allusion aux données datées : une entité-type E comporte des attributs A1, .., Am dont les valeurs changent au fil du temps. E doit donc faire l’objet de m+1 entités-types. Tout d’abord E elle-même où chaque attribut A1, ..., Am, est accompagné d’un attribut T1, ..., Tm, tels que Ti est associé à Ai et est du type Date, cet attribut permettant de savoir à partir de quelle date la valeur prise par Ai prend effet. Par ailleurs, pour chaque Ai on met en œuvre une entité-type Hi associée à E par une relation de composition. Au niveau logique, Hi fait l’objet d’une table de structure {Ek, Ai, Di), où Ek représente la clé de la table E, Ai l’attribut de facto historisé et Di l’intervalle de temps, la période de validité de Ai.

A supposer que l’attribut Ek soit du type te, Ai du type tai, Ti du type Date et Di du type Intervalle_date, la structure correspondante est la suivante, dans le style de Tutorial D (qui n’est pas SQL !) :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
 
E {Ek te, A1 ta1, ..., Am tam, T1 date, ..., Tm date, ...} 
    KEY {Ek} ;

H1 {Ek te, A1 ta1, D1 intervalle_date}
    KEY {Ek, D1}
    FOREIGN KEY {Ek} REFERENCES E {Ek} ;
...
Hm {Ek te, Am tam, Dm intervalle_date}
    KEY {Ek, Dm}
    FOREIGN KEY {Ek} REFERENCES E {Ek} ;

Évidemment, les traitements ne doivent pas se contenter de manipuler l’attribut Ai, mais la paire {Ai, Ti} en ce qui concerne la table E et la paire {Ai, Di} en ce qui concerne la table Hi. C’est le prix à payer (conséquence d'une modélisation Naf-Naf) pour traiter des données temporelles (ou plus généralement intervallaires). Du point de vue de la théorie relationnelle, la table E doit respecter la cinquième forme normale et la table Hi la sixième forme normale. Pour plus d’informations sur cette approche, je vous renvoie à l’ouvrage suivant : « C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data and the Relational Model » où sont consacrées près de 400 pages à l'étude des bases de données temporelles.

Comment faites vous pour rendre cela testable, sans exploiter la base existante, avec un jeu de données permettant de répondre à l'ensemble des cas de production ?

Je demande à la Production informatique de me dupliquer dans un environnement dédié les seuls objets qui me sont nécessaires (tables, programmes, etc.), sur la base du contenu du catalogue relationnel. Ainsi pourrai-je effectuer mes tests en toute sérénité.

Comment faites vous les versionings ? (Modification de structure, plus modification de la donnée)

Ceci n’est pas de mon ressort mais celui de la Production informatique (les DBA de cette direction étant particulièrement impliqués). Une Production informatique digne de ce nom est rodée à ce genre d’exercice.

[Erwy]

J'ai mis en gras le point ou vous vous trompez.... On ne "formate" pas les données pour un usage. On format les données parc ce qu'elles ont intrinsèquement une signification au regard de la sémantique qu'elle contiennent....

Ben non, je suis tout à fait d'accord avec et c'est ce que je préconise même si ce n'est pas le point que j'abordais ici.Quand je disais que mon manque de connaissance théorique du sujet m'amène à mal exprimer ma pensée...

[gene69]

comment il faut traduire et comprendre les "eventualy consistant" ?

passer d'un moteur "cher" mais qui offre toutes les garanties vers un modèle moins cher mais qui offre moins de prestation. C'est ça le deal de NoSql?

[CinePhil]

comment il faut traduire et comprendre les "eventualy consistant" ?

La discussion fait à ce jour 10 pages. Ce serait bien de citer le passage d'oû tu sors cette expression.

passer d'un moteur "cher" mais qui offre toutes les garanties vers un modèle moins cher mais qui offre moins de prestation. C'est ça le deal de NoSql?

Qu'entends-tu par "cher" ?
Postgresql est gratuit, plutôt dans la moyenne haute quant au respect de la norme SQL et performant.