Une base Oracle… qui n’en est pas une !

Étude du modèle de donnée d’une base éditeur ou .. une base Oracle… qui n’est pas une base relationnelle

base incohérente

Même en 2013, on peut être extrêmement surpris en étudiant les données et le modèle de donnée d’un produit éditeur récent.

La base, au premier coup d’œil semble bien conçue, commentaire sur les colonnes et les tables, modèle relationnel bien conçu, etc..

1. Le constat

Mais, voici le constat après une première étude du modèle :

  •   utilisations multiples de mots-clés oracle réservés dans le nom des objets oracles (tables et colonnes)
  • nom de tables et de colonnes forcés en minuscules. Pour faire une requête, il faut mettre le nom des tables et de colonnes entre guillemets, exemple :
select "libelle", "mode" from "reference";

→ résultat, même un outil majeur du marché comme TOAD ne permet pas l’utilisation de certaines fonctionnalités (ex : filtre sur tables ou colonnes). Un outil comme Business Objects a aussi certaines difficulté !

  • dates qui ne sont ni des dates ni des timestamps Oracle (dates avec des secondes), mais des timestamps UNIX

→ la conversion de ces timestamps dans la bonne timezone (problème du changement d’heure en cours d’année) s’avère assez complexe

  • libellés qui ne sont pas des libellés, mais au format JSON.
    → ces libellés ne sont pas lisibles directement. Pas de :

    select libelles from table;
  • les règles basiques de calcul se trouvent uniquement dans le code de l’application et pas dans les tables
    → pour retrouver les règles, il ne reste plus qu’à commander le code, l’obtenir, et espérez que lors des mises à jour, on soit tenu au courant
    Oubliées les contraintes d’intégrité, puisque certaines règles sont codées en dur dans l’application
  • utilisation de JSONs qui déconstruisent le modèle relationnel
    une seule ligne pour des quantités vendues par jour va pouvoir contenir n ventes sur une même journée à des heures différentes par exemple sur une ligne : [{« 8h »: »1″, »12h »: »2″, »19h »: »1″}]
    (à 8h00, 1 quantité vendue ; à 12h00, 2 quantités vendues ; à 19h00, 2 quantités vendues)
    Autant dire qu’on est sur une base Oracle qui n’en est pas une, puisque cette base ne peut être étudiée et simplement interrogée par requêtes sans faire de transformations complexes, pour les éléments les plus basiques tels que dates, libellés et fonction d’aggrégation (compter, sommer) !

De plus une fois la transformation faite, il n’est plus possible de faire des vérifications de comparaisons par rapport à la base de donnée éditeur de production, ce qui pose de gros problèmes notamment pour la validation des données. Quand l’éditeur fournit des statistiques dans son application, il est difficile d’aller vérifier la véracité des données, et après vérification.. certaines stats sont fausses et impossible à obtenir sans transformer les données !

2. Les « raisons »

→ Bien sur, l’éditeur a ses raisons, pour les JSONS c’est de développement fait à la va-vite et de meilleures performance et pour tous les problèmes de compatibilité avec Oracle, c’est simplement une base générique qui ensuite est portée sur différentes bases de données (SQL SERVER, Oracle, etc..).
Pour moi, cela ne fait que confirmer une constatation qu’on ne peut pas se lancer dans un modèle générique multi-base.

3. Les « solutions »

Le produit est bien installé chez le client, qui est content de l’application surtout par rapport à ses performances.
Après avoir rencontré l’éditeur, il propose de faire un développement spécifique pour rendre les données lisibles dans d’autres tables.

Il faut ainsi payer pour pouvoir lire ses propres données et pas directement ! Ce produit aura un coût exponentiel au fur et à mesure des années.

Quand on achète un produit, autant bien regarder ce qu’il y a sous le capot !

produit poubelle

 

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *