Vidéo: How The Economic Machine Works by Ray Dalio 2024
Alors que l'informatique se déplaçait sur le marché commercial, les données étaient stockées dans des fichiers plats qui n'imposaient aucune structure. Aujourd'hui, le big data nécessite des structures de données gérables. Lorsque les entreprises avaient besoin d'un niveau de compréhension détaillé des clients, elles devaient appliquer des méthodes de force brute, y compris des modèles de programmation très détaillés pour créer de la valeur.
Plus tard dans les années 1970, les choses ont changé avec l'invention du modèle de données relationnelles et du système de gestion de base de données relationnelle (SGBDR) qui imposait une structure et une méthode pour améliorer les performances. Plus important encore, le modèle relationnel a ajouté un niveau d'abstraction qui a permis aux programmeurs de satisfaire plus facilement les demandes croissantes des entreprises pour extraire de la valeur des données.
Le modèle relationnel offrait un écosystème d'outils provenant d'un grand nombre de sociétés de logiciels émergentes. Il répondait à un besoin croissant d'aider les entreprises à mieux organiser leurs données et à pouvoir comparer les transactions d'une géographie à l'autre.
En outre, il a aidé les chefs d'entreprise qui voulaient être en mesure d'examiner des informations telles que les stocks et de les comparer aux informations de commande des clients à des fins de prise de décision. Mais un problème est apparu à la suite de l'explosion de la demande de réponses: stocker ce volume croissant de données était coûteux et son accès était lent. Pire encore, il y avait beaucoup de duplication de données et la valeur commerciale réelle de ces données était difficile à mesurer.
Lorsque le volume de données que les organisations devaient gérer devenait hors de contrôle, l'entrepôt de données offrait une solution. L'entrepôt de données a permis à l'organisation informatique de sélectionner un sous-ensemble des données stockées, de sorte qu'il serait plus facile pour l'entreprise d'essayer d'obtenir des informations.
L'entrepôt de données avait pour but d'aider les entreprises à traiter des volumes de données structurés de plus en plus importants qu'elles devaient pouvoir analyser en réduisant le volume des données à quelque chose de plus petit et plus concentré sur un secteur particulier de l'entreprise. Il répondait au besoin de séparer le traitement de l'aide à la décision opérationnelle et l'aide à la décision - pour des raisons de performance.
Les entrepôts stockent souvent des données des années précédentes pour comprendre la performance organisationnelle, identifier les tendances et aider à exposer les modèles de comportement. Il fournissait également une source intégrée d'informations provenant de diverses sources de données pouvant être utilisées pour l'analyse. Aujourd'hui, les systèmes de gestion de contenu et les entrepôts de données peuvent tirer parti des améliorations de l'évolutivité du matériel, des technologies de virtualisation et de la capacité à créer des systèmes matériels et logiciels intégrés.
Parfois, ces entrepôts de données eux-mêmes étaient trop complexes et trop volumineux et n'offraient pas la rapidité et l'agilité dont l'entreprise avait besoin. La réponse a consisté en un affinement supplémentaire des données gérées par les centres de données. Ces centres de données étaient axés sur des problèmes commerciaux spécifiques et répondaient aux besoins de l'entreprise en matière de requêtes rapides. L'entrepôt a évolué pour prendre en charge les technologies émergentes telles que les systèmes intégrés et les appareils de données.
Les entrepôts de données et les data marts ont résolu de nombreux problèmes pour les entreprises qui ont besoin d'une méthode cohérente pour gérer des données transactionnelles massives. Mais lorsqu'il s'agissait de gérer d'énormes volumes de données non structurées ou semi-structurées, l'entrepôt n'était pas en mesure d'évoluer suffisamment pour répondre aux demandes changeantes.
Pour compliquer les choses, les entrepôts de données sont généralement alimentés en intervalles de traitement, généralement hebdomadairement ou quotidiennement. C'est bien pour la planification, les rapports financiers et les campagnes de marketing traditionnelles, mais c'est trop lent pour les environnements commerciaux et de consommation de plus en plus en temps réel.
Comment les entreprises pourraient-elles transformer leurs méthodes traditionnelles de gestion des données pour gérer le volume croissant d'éléments de données non structurés? La solution n'a pas émergé du jour au lendemain. Au fur et à mesure que les entreprises ont commencé à stocker des données non structurées, les fournisseurs ont commencé à ajouter des fonctionnalités telles que les
Essentiellement, un élément de données non structuré serait stocké dans une base de données relationnelle sous la forme d'un bloc de données contigu. Cet objet pourrait être étiqueté mais vous ne pouviez pas voir ce qu'il y avait à l'intérieur de cet objet. Clairement, cela n'allait pas résoudre les besoins changeants des clients ou des entreprises.
Entrez le système de gestion de base de données d'objets (ODBMS). La base de données d'objets stockait le BLOB sous la forme d'un ensemble adressable de pièces afin que vous puissiez voir ce qu'il y avait dedans. Contrairement au BLOB, qui était une unité indépendante ajoutée à une base de données relationnelle traditionnelle, la base de données d'objets fournissait une approche unifiée pour traiter les données non structurées.
Les bases de données d'objets incluent un langage de programmation et une structure pour les éléments de données afin de faciliter la manipulation de divers objets de données sans programmation ni jointures complexes. Les bases de données d'objets ont introduit un nouveau niveau d'innovation qui a contribué à la deuxième vague de gestion des données.
