Solutions

Ne ratez aucune nouveauté MarkLogic

Soyez au courant avant tout le monde !Les nouveautés, informations produits et rendez-vous directement dans votre boîte mail.

M'inscrire

Formations

Ne ratez aucune nouveauté MarkLogic

Soyez au courant avant tout le monde !Les nouveautés, informations produits et rendez-vous directement dans votre boîte mail.

M'inscrire

Communauté

Ne ratez aucune nouveauté MarkLogic

Soyez au courant avant tout le monde !Les nouveautés, informations produits et rendez-vous directement dans votre boîte mail.

M'inscrire

Société

Ne ratez aucune nouveauté MarkLogic

Soyez au courant avant tout le monde !Les nouveautés, informations produits et rendez-vous directement dans votre boîte mail.

M'inscrire

Sortez de la matrice

Libérez vos données avec une base de données multi-modèle.

Les bases de données relationnelles vous enferment dans un environnement fragmenté fait de lignes et de colonnes. C'est une matrice rigide qui contrôle toutes vos opérations. Vous êtes esclave des machines, vous conformez à leurs règles strictes contre votre volonté et adaptez votre environnement à la tyrannie de leur structure. Il est temps de vous échapper de la matrice des bases de données relationnelles, d'adopter une approche moderne et multi-modèle de l'intégration des données qui libère vos données et ouvre la voie à des possibilités infinies.

Ce qu'il vous faut, c'est une vue à 360 degrés de votre entreprise

Les données doivent être intégrées rapidement

Vous possédez désormais une plus grande quantité de données sur votre entreprise, provenant d'un nombre de sources qui n'a jamais été aussi élevé. Toutefois, il est fort probable que ces données soient réparties dans des silos et stockées dans des modèles de données relationnels, tels que les bases de données d'enregistrement, les systèmes d'exécution et CRM, ainsi que les plates-formes de serveur publicitaire. À moins de pouvoir les intégrer rapidement pour créer une vue à 360 degrés de votre entreprise, ces données ne sont pas exploitables.

Les processus ETL anéantissent l'agilité

À chaque fois que vous fusionnez des données à partir de différentes bases de données relationnelles, vous devez les extraire, les transformer et les charger (ETL). C'est un processus lent, complexe et onéreux.

Les données changent en permanence

Chaque nouvelle application nécessite une vue unique de vos données. Une fusion ou une acquisition modifie la quantité et le type de données que vous gérez. Lorsque la règle de conformité change, la manière dont vous gérez les données change également. Et lorsque votre entreprise subit une transformation numérique, il est essentiel que vos données soient accessibles en temps réel.

Vous devez exécuter et observer l'activité

Les données opérationnelles "nécessaires à l'activité" sont utilisées en temps réel plus que jamais lorsque les entreprises subissent une transformation numérique. Ces données peuvent concerner plusieurs secteurs d'activité et existent dans différentes bases de données. Si vous êtes dans l'incapacité d'intégrer les données de ces silos opérationnels suffisamment rapidement ou avec une agilité suffisante pour répondre aux nouvelles exigences, cela peut être fatal à votre transformation numérique.

Parallèlement, vous souhaitez également gérer les silos dans vos fonctions d'observation analytiques, sans pour autant augmenter le nombre de silos de données spécifiques.

Le problème est que les bases de données relationnelles rendent l'utilisation et l'intégration de données en temps réel complexes et onéreuses.

Problèmes avec les bases de données relationnelles

Dans les modèles relationnels, ce qui est simple peut devenir complexe

Prenons un simple diagramme de relations entre entités : un client qui effectue une transaction impliquant un produit. Théoriquement, c'est une relation très simple. Toutefois, en raison de la rigidité des bases de données relationnelles, même de simples relations entre entités peuvent devenir complexes. En outre, dans une base de données relationnelle, des informations similaires peuvent être modélisées différemment, ce qui rend l'intégration de données difficile.

Les jointures n'ont pas toutes un sens

En observant le schéma simple de Blue Gear Auto Parts, vous remarquerez un problème. Il comporte une table de jointure, "Tlines", qui ne correspond pas à notre compréhension conceptuelle de la transaction. Étant donné que les transactions peuvent inclure plusieurs produits et que des produits peuvent être inclus dans plusieurs transactions, des tables de jointure séparées sont nécessaires pour stocker les informations sur ces produits. Ces tables de jointure existent parce que les bases de données relationnelles sont rigides et imposent la disposition des données en colonnes et en lignes.

Les schémas ne sont pas toujours intuitifs

Les schémas relationnels sont également difficiles à comprendre de façon intuitive. Par exemple, à quoi correspond "Addr" dans cette table client ? Il vous faudrait l'examiner de plus près pour comprendre que "Addr" désigne la rue correspondant à cette adresse.

Lorsque ces informations changent, la nature rigide des modèles de données relationnels présente d'autres problèmes. Par exemple, supposons que vous souhaitiez ajouter une seconde adresse ou un second numéro de téléphone à l'enregistrement d'un client. Dans un modèle relationnel, cela nécessite de nouvelles tables de jointure, ce qui complique davantage votre schéma.

La rigidité des schémas peut aboutir à des données erronées

La nature rigide des modèles de données relationnels crée un autre dilemme. Une fois que vous avez conçu un schéma, le seul moyen de le modifier est de le diviser et de recommencer. Sachant cela, comment créer un schéma capable de prévoir vos besoins futurs ? Que se passe-t-il si votre activité évolue et que vous avez besoin de modéliser vos données différemment ?

Vous avez le choix entre un processus lent et onéreux, au cours duquel vous concevez un nouveau schéma puis extrayez, transformez et chargez vos données, et un processus raccourci qui force l'intégration de vos données dans votre schéma existant. Toutefois, cela compromettrait la qualité des données, car votre schéma n'en serait pas le reflet.

Ce schéma n'autorise qu'un seul numéro de téléphone, car Blue Gear Auto Parts n'a pas pris en compte les téléphones mobiles. Au lieu de reconcevoir le schéma, les développeurs ont imposé deux numéros dans le champ.

Les modèles de données relationnels présentent donc un défaut majeur : ils sont rigides et ne facilitent pas le changement. Cela entrave l'agilité de l'entreprise.

La modélisation des mêmes relations aboutit différemment à la complexité

À la différence de Blue Gear Auto Parts, le schéma de Red Motor Equipment autorise plusieurs numéros de téléphone et adresses pour les clients. Cette division de Red Motor Equipment traite peut-être les informations de facturation et d'expédition. De ce fait, elle a besoin des deux adresses, alors que Blue Gear Auto Parts ne traite que les adresses d'expédition.

Schémas complexes

Un schéma de données qui semble plus réaliste

Les schémas de données se révèlent beaucoup plus complexes dans la réalité. Voici ce à quoi pourrait ressembler un schéma d'une application d'entreprise simple. Imaginez la complexité d'un schéma d'application ERP avec des dizaines de milliers de tables.

L'intégration de schémas crée davantage de complexité

Supposons que Blue Gear Auto Parts acquière Red Motor Equipment et souhaite intégrer les données des deux entreprises.

Pour ce faire, Blue Gear Auto Parts aurait besoin de créer un schéma unique pour recueillir toutes les données des schémas source de ces deux entreprises. Cette opération créera un schéma "uber" plus complexe. Et au cours du processus, Blue Gear Auto Parts devra déterminer les informations à conserver et celles à éliminer.

Read Motor Equipment possède plus d'informations que Blue Gear Auto Parts. Peut-être qu'elle n'a pas besoin d'adresses de facturation pour le moment. Mais que se passera-t-il si la situation évolue ?

La complexité est inévitable

Voici à quoi pourrait ressembler le schéma "uber". Comme vous pouvez le constater, ce schéma comporte plusieurs tables et plusieurs jointures, ce qui le rend beaucoup plus complexe.

En réalité, Blue Gear Auto Parts souhaiterait le simplifier afin de faciliter sa gestion, mais le seul moyen d'y parvenir, c'est de concevoir un schéma pour un cas d'utilisation spécifique. Si Blue Gear Auto Parts procédait ainsi, elle perpétuerait un cycle continu de silos de données et d'extractions, transformations et chargements.

Qu'entraînent les silos ?

Lorsque votre activité évolue, la vue de vos données doit également changer

Avec les bases de données relationnelles, cela aboutit à différentes versions de vos données dans des silos distincts : données source d'origine, versions modifiées de vos données source et autres adaptations de vos données pour chaque besoin spécifique. De plus, à chaque fois que vous modifiez vos données, vous en laissez de côté une partie, ce qui complique le lignage des données.

Examinons notre cas simplifié de Blue Gear Auto Parts. Lorsque Blue Gear Auto Parts achète Red Motor Equipment, la consolidation des données prend du sens. Étant donné que le processus ETL est onéreux, complexe et qu'il évite difficilement les interruptions du système, il est probable que l'entreprise ne fusionne pas les données tant que cela ne s'avère pas nécessaire pour une application spécifique.

Vous ajoutez uniquement les données nécessaires en raison des coûts du processus ETL

Supposons que Blue Gear Auto Parts a maintenant besoin de disposer d'une vue de ses clients pour comprendre leur profil. Elle va devoir exécuter un processus ETL sur les données clients de Blue Gear Auto Parts et Red Motor Equipment. Par la suite, elle pourrait souhaiter analyser ses produits et clients afin de mieux prévoir ce qui est susceptible d'intéresser les clients potentiels. Plus tard dans l'année, Blue Gear Auto Parts doit consolider ses données de vente pour un organisme de réglementation. Elle exécute à nouveau un processus ETL sur les données, en supprimant les informations dont l'organisme de réglementation n'a pas besoin, puis elle exécute un dernier processus ETL pour envoyer les données de vente dans un tableau de bord de revenus.

Aucune entreprise n'envisage d'utiliser des silos

Mais que se passera-t-il ensuite ? À chaque nouveau besoin métier, Blue Gear Auto Parts devra exécuter un processus ETL sur les données, ce qui ralentira son activité.

L'existence de différentes sources de données est due à la trop grande rigidité des bases de données relationnelles

À chaque fois qu'un processus ETL est exécuté, un nouveau silo est créé. Par conséquent, il n'existe aucune source de données centralisée. Au lieu de cela, les données existent en différentes versions dans l'entreprise : données source initiales, versions modifiées des données source et autres adaptations des données pour chaque besoin métier spécifique. Cette diversité rend également la gouvernance des données cauchemardesque, car il est impossible d'effectuer un suivi du lignage, de la provenance et de la qualité des données dans les différents silos.

Approche de MarkLogic

Un approche flexible de la modélisation des données

Les bases de données de documents, telles que MarkLogic, disposent d'un modèle de données plus flexible. L'enregistrement client sur la gauche, représenté dans un modèle de données relationnel, est inséré de manière contrainte dans des lignes et des colonnes rigides.

Le même enregistrement est représenté sous la forme d'un document JSON sur la droite. Il illustre la structure hiérarchique d'un modèle de document, qui organise les données naturellement, comme un document. Il comporte des tableaux (adresse d'expédition, adresse de facturation) et des tableaux imbriqués (numéro de téléphone).

MarkLogic est incroyablement flexible

Lorsque vous ajoutez des informations dans MarkLogic, vous ajoutez simplement celles que vous possédez et ne vous souciez pas de celles dont vous ne disposez pas. Vous pouvez représenter des attributs hiérarchiques récurrents tels que les numéros de téléphone et les adresses naturellement, sans avoir à concevoir de tables séparées. De plus, vos données peuvent faire l'objet de requêtes immédiatement, car MarkLogic les indexe dès que vous les ajoutez.

Harmonisez les données en toute simplicité

Au lieu de recourir aux processus ETL traditionnels qui transforment les données avant de les charger dans une base de données, vous pouvez utiliser le modèle de données de document flexible de MarkLogic, qui vous permet d'harmoniser les données dont vous avez besoin, quand vous le souhaitez. Cette harmonisation se produit dans une base de données entièrement transactionnelle dans laquelle les données peuvent être suivies et gérées.

Dans cet exemple, le code postal est harmonisé. Dans le modèle canonique harmonisé, les deux modèles de données sont nommés uniformément "Postal".

MarkLogic vous permet de regrouper facilement des éléments de données dans un modèle canonique afin que les données puissent faire l'objet de requêtes homogènes. Vous pouvez faire évoluer votre modèle au fil du temps, en fonction de l'évolution de vos besoins métier. À aucun moment vous n'êtes contraint de détruire vos données brutes.

Maîtrisez le lignage de vos données

MarkLogic utilise un motif d'enveloppe pour modéliser les données. Les métadonnées sont ajoutées au document afin de préserver la provenance et le lignage des données. Il vous permet de stocker et de rechercher des métadonnées, des données source et des données canoniques dans un même document.

Entités = Documents

Le modèle de données de document offre l'approche la plus flexible et itérative pour la modélisation des entités commerciales.

Les bases de données relationnelles rendent la signification floue

Les bases de données relationnelles n'excellent pas dans l'illustration de la signification des relations entre entités. Par exemple, cet enregistrement client de Red Motor Equipment illustre de nombreuses jointures indiquant les relations entre les tables. En revanche, il est difficile de comprendre la signification de ces relations.

Relations entre entités dans MarkLogic

Voici une vue du même enregistrement client dans MarkLogic.

Vous pouvez rapidement constater que le client a terminé une transaction qui incluait les entités "Battery" et "Jump Starter". Les relations entre ces entités sont beaucoup plus faciles à comprendre.

La puissance de la sémantique

Trouvez davantage de données avec la sémantique

Les modèles de données relationnels nécessitent que vous compreniez votre schéma pour rechercher vos données. Ce n'est pas le cas dans MarkLogic.

Grâce à la puissance de la sémantique, MarkLogic simplifie la compréhension des relations, ce qui facilite et accélère la recherche et la détection des données.  La signification des relations sémantiques dans MarkLogic est riche : vous pouvez les définir de façon explicite et rechercher leur signification directement. Vous pouvez également tirer des conclusions de la signification des relations afin de créer de nouvelles informations.

Les triplets sont utilisés pour établir des relations entre les entités et les concepts

Une base de données relationnelle assemble les données en associant des relations de clés primaires ou étrangères. Toutefois, ces relations ne nous disent rien sur la nature réelle de la relation. Celle-ci est enfouie dans le code de l'application. Certaines de ces jointures représentent de réelles relations telles que nous les comprendrions dans le contexte métier, et certaines sont de fausses relations qui existent uniquement parce que le modèle relationnel n'est pas suffisamment riche pour traiter un contenu autre qu'une ligne dans une table. Comment les distinguer ? Sans un minimum de connaissances sur la sémantique du modèle, c'est impossible.

En revanche, avec la sémantique, nous pouvons donner un contexte et une signification explicite à cette transaction. Par exemple, dans MarkLogic, les mêmes données peuvent être définies comme suit : Karen Bender, client 2001, a acheté le produit 7001, une batterie.

En s'appuyant sur des triplets, la sémantique constitue le meilleur moyen de modéliser les relations dans vos données. Les triplets se composent d'un sujet, d'un prédicat et d'un objet. Ils éliminent le recours à des clés étrangères, des requêtes imbriquées et des jointures complexes. Lorsque vous associez un modèle de document à la sémantique, vous obtenez une approche multi-modèle pour toutes vos données.

Les relations sémantiques dans MarkLogic sont riches en termes de signification. Vous pouvez définir la signification de façon explicite et la rechercher directement. Vous pouvez tirer des conclusions de cette signification et créer de nouvelles informations.

La sémantique permet l'existence de nombreuses applications différentes

Elle donne de l'intelligence à vos données et vous permet de les utiliser pour exécuter des opérations qui étaient difficiles précédemment. Par exemple :

La sémantique peut être utilisée pour définir des concepts qui pourraient être identiques mais portent des noms différents dans différentes sources de données. Ainsi, Blue Gear Auto Parts aurait pu appeler un bloc d'alimentation pour démarrage de secours "Bloc pour démarrage de secours", alors que Red Motor Equipment l'appelle "Pack de démarrage de secours". Grâce à la sémantique, les deux entreprises peuvent définir ces concepts comme étant identiques. Lorsque Blue Gear Auto Parts recherchera les achats de bloc d'alimentation pour démarrage de secours après la fusion avec Red Motor Equipment, elle obtiendra les résultats qu'elle attendait.

Vous pouvez lier les informations de telle sorte qu'un produit accessoirise un autre pour créer un système de recommandations ou mieux comprendre les achats de vos clients. Pour Blue Gear Auto Parts, peut-être que vous associez la batterie et le bloc d'alimentation pour démarrage de secours en tant qu'articles qui se complètent. Grâce à la sémantique, il est possible de créer cette relation, et lorsque Karen achète une batterie sur le magasin en ligne, le système de recommandations peut lui suggérer d'acheter un bloc d'alimentation pour démarrage de secours en complément de sa batterie.

Ces deux exemples ne sont qu'un aperçu de ce que vous permet de faire la sémantique. Vous pouvez également l'utiliser pour dissocier des informations, lier des informations dans le but de créer un graphique à partir de vos données, créer des alertes et bien d'autres tâches encore.

Comparaison entre une base de données relationnelle et MarkLogic

Dans une base de données relationnelle

Étape 1
Regroupez tous les schémas que vous souhaitez intégrer. Déterminez ce que les schémas signifient, comment ils fonctionnent et ce qu'ils ont en commun.

Étape 2
Déterminez les données à éliminer. Concevez un nouveau schéma qui peut contenir toutes les données que vous avez décidé de conserver.

Étape 3
Écrivez le code ETL pour extraire les données de la source, les transformer dans votre nouveau schéma, puis les charger dans une nouvelle base de données avec ce schéma cible.

Étape 4
Créez les index qui permettent de lancer la recherche.

Étape 5
Développez l'application.

Étapes de redémarrage 1-5
À chaque fois que votre activité requiert un changement.

Dans MarkLogic :

Étape1
Sélectionnez quelques schémas source avec lesquels démarrer et supprimez quelques exemples d'enregistrement.

Étape 2
Chargez ces schémas dans MarkLogic en l'état et utilisez la fonctionnalité de recherche intégrée pour comprendre ce dont vous disposez.

Étape 3
Harmonisation itérative et développement de modèle agile.

Étape 4
Accédez aux données quand vous le souhaitez.

La base de données MarkLogic

Enterprise-ready. Flexibilité sans précédent.

Avec MarkLogic, vous ne faites pas que développer une application. Vous développez une plate-forme pour toutes vos données avec des possibilités infinies. Peut-être que vous commencez par un cas d'utilisation spécifique, mais les données sont accessibles à de nombreux cas d'utilisation. Vous ne créez pas simplement un nouveau silo qui fonctionne uniquement pour une application.

Hub de données opérationnelles de MarkLogic

Vous pouvez voir ici comment le hub de données opérationnelles de MarkLogic pourrait être incorporé à votre architecture pour ingérer les données de différentes sources de données et fournir de la valeur. La plate-forme MarkLogic stocke diverses données, notamment des triplets JSON, XML, texte, géospatiaux et sémantiques avec indexation pour une recherche rapide. Par ailleurs, elle fournit des API permettant d'accéder aux données et de développer des applications rapidement afin de valoriser au plus vite votre entreprise. Avec le hub de données opérationnelles de MarkLogic, la modification des données n'empêchera pas votre entreprise d'avancer.

Une vue complète à 360 degrés de votre entreprise

MarkLogic offre des fonctionnalités à la pointe du secteur en termes de sécurité, de confidentialité et de gestion du cycle de vie afin de garantir l'application de vos règles de gouvernance des données. Vous disposerez d'un système transactionnel, avec des transactions ACID multi-documents, qui garantira également fiabilité et disponibilité. Que ce soit sur site ou dans le cloud, MarkLogic a démontré sa haute disponibilité et met en avant des fonctionnalités de réplication qui maintiendront votre flux de données même dans les environnements les plus exigeants.

Avec MarkLogic, vous pouvez modifier vos données au fil du temps, quand vous le souhaitez. Vous pouvez ainsi intervenir plus rapidement avec un risque moindre. Et pour couronner le tout, une fois le projet terminé, vous aurez créé pour votre entreprise une ressource qui continuera d'évoluer en fonction de vos besoins.

Vos données méritent mieux !

Le modèle de données flexible de MarkLogic vous permet d'intégrer les données plus rapidement et de façon plus économique. Libérez vos données avec MarkLogic.

Télécharger une version gratuite de MarkLogic

En savoir plus sur les solutions MarkLogic

Télécharger l'e-book pour en savoir plus sur ce thème