Lorsque SAP a développé la base de données en mémoire HANA, ils ont découvert que leurs propres applications étaient les pires ennemis de la nouvelle base de données en mémoire. SAP a réalisé que leurs applications devaient être optimisées afin de bénéficier de HANA. Mais alors que SAP n'avait que HANA à l'esprit, les bases de données riches en fonctionnalités telles qu'Oracle peuvent prendre en charge les mêmes optimisations et en bénéficier.
SAP considérait une base de données comme un simple dépôt de données. Chaque fois qu'un utilisateur veut faire quelque chose d'utile avec les données, il doit être transféré, car l'intelligence se trouve dans le serveur d'applications SAP.
Les inconvénients de cette approche sont évidents : si la somme de 1 million de valeurs doit être calculée et si ces valeurs représentent de l'argent dans différentes devises, 1 million de valeurs individuelles sont transférées du serveur de base de données au serveur d'applications - pour être ensuite rejetées une fois le calcul effectué. Le trafic réseau causé par cette approche est responsable des mauvaises performances.
En réponse à ces informations, SAP a développé la stratégie "Push down" : propager le code qui nécessite des calculs gourmands en données de la couche application vers la couche base de données. Ils ont développé un tout nouveau modèle de programmation qui permet au code ABAP d'appeler (implicitement ou explicitement) des procédures stockées dans la base de données. Ils ont également défini une bibliothèque de procédures standard, appelée SAP NetWeaver Core Data Services (CDS).
20 ans auparavant, Oracle avait déjà eu la même idée et pris la même décision. Depuis la version 7, Oracle Database permet aux développeurs de créer des procédures et des fonctions qui peuvent être stockées et exécutées dans la base de données. Il était donc possible de rendre le CDS également disponible pour Oracle Database, et aujourd'hui, les développeurs d'applications SAP peuvent l'utiliser.
Les modèles de données de SAP (l'ensemble des tables utilisées par une application et les relations entre elles) avaient été définis il y a 15 ou 20 ans et optimisés pour les bases de données orientées disque. Mais, comme il s'est avéré, ce qui était une optimisation à l'ère de l'informatique sur disque est un obstacle à l'ère de l'informatique en mémoire.
L'exemple le plus célèbre est probablement la structure interne d'un cube SAP BW. Du point de vue de l'entreprise ou de l'utilisateur, ce qui ressemble à un seul "cube" est en fait un ensemble de plusieurs tables, et les relations entre elles peuvent être décrites comme une hiérarchie à plusieurs niveaux (schéma "star" ou "snowflake"). Cette structure complexe, qui nécessite de nombreuses jointures lors de l'exécution d'une requête ou d'un rapport, ralentit considérablement les bases de données en mémoire. Par conséquent, SAP a conçu un nouveau modèle de données plus simple pour SAP BW sur HANA et l'a donc appelé HANA-Optimized InfoCubes. Mais ce nouveau modèle de données n'est pas seulement optimisé pour HANA. Il est optimisé pour le calcul en mémoire en général. Par conséquent, les utilisateurs SAP sur Oracle qui ont activé Oracle Database In-Memory peuvent également l'implémenter, la seule différence étant le nom (Flat InfoCubes ou simplement Flat Cubes).
Une optimisation moins célèbre, néanmoins importante, est la déclusterisation de tables. Une table de cluster stocke un enregistrement complet (logique) dans une seule colonne de table (physique). Une telle valeur complexe peut être interprétée par le serveur d'applications SAP, mais pas par un serveur de base de données, ce qui signifie que la propagation du code n'est pas possible si une table de cluster est impliquée. Par conséquent, SAP prend désormais en charge Table Declustering, pour HANA ainsi que pour Oracle Database.
Les avantages de la structure CDS qui vient d'être décrite ne sont en aucun cas limités aux applications SAP (c'est-à-dire aux applications standard créées par les développeurs SAP). Pour les clients, les applications développées en interne sont une partie essentielle de leur environnement SAP. Bon nombre de ces applications pourraient grandement bénéficier de l'utilisation des fonctionnalités CDS.
Les vues CDS peuvent être affichées via OData. Sur la base de l'exposition OData du CDS, il est alors assez simple de créer des applications SAP Fiori à l'aide du framework de développement SAP WEB IDE. Pour plus de détails, reportez-vous au rapport ABAP Core Data Services sur anyDB.