Dans la sous-section précédente, il a été noté que pour représenter adéquatement Domaine, facilité de développement et de maintenance de la base de données, la relation doit être ramenée à la troisième forme normale (il existe des formes de normalisation et d'ordres supérieurs, mais en pratique elles sont utilisées assez rarement), c'est-à-dire être fortement normalisée. Dans le même temps, les relations faiblement normalisées ont également leurs avantages, dont le principal est que si la base de données n'est accessible principalement qu'avec des requêtes, et que les modifications et les ajouts de données sont effectués très rarement, leur sélection est alors beaucoup plus rapide. Cela s'explique par le fait que dans les relations faiblement normalisées, leur connexion a déjà été établie, pour ainsi dire, et le temps du processeur n'y est pas consacré. Il existe deux classes de systèmes pour lesquels les relations fortement et faiblement normalisées conviennent mieux.

Les modèles de données fortement normalisés sont bien adaptés aux applications OLTP − Traitement des transactions en ligne (OLTP) - applications de traitement des transactions en ligne. Des exemples typiques d'applications OLTP sont des systèmes comptabilité d'entrepôt͵ commandes de billets, exploitation systèmes bancaires autre. La fonction principale de ces systèmes est d'effectuer un grand nombre opérations courtes. Les transactions elles-mêmes sont assez simples, mais les problèmes sont qu'il y a beaucoup de telles transactions, elles sont exécutées simultanément, et si des erreurs se produisent, la transaction doit revenir en arrière et ramener le système à l'état dans lequel il se trouvait avant le début de la transaction. Presque toutes les requêtes de base de données dans les applications OLTP consistent en des commandes d'insertion, de mise à jour et de suppression. Les requêtes de sélection visent principalement à fournir aux utilisateurs une sélection de données provenant de différents types d'annuaires. Bien sûr, la plupart des demandes sont connues à l'avance au stade de la conception du système. La vitesse et la fiabilité des mises à jour courtes des données sont essentielles pour les applications OLTP. Plus le niveau de normalisation des données dans les applications OLTP est élevé, plus elles sont rapides et fiables. Des écarts par rapport à cette règle peuvent survenir lorsque déjà au stade du développement, certaines requêtes fréquentes sont connues qui nécessitent la connexion de relations et dont la vitesse d'exécution affecte de manière significative le fonctionnement des applications.

Un autre type d'applications sont les applications OLAP − Processus analytique en ligne (OLAP) - applications de traitement de données analytiques en ligne. Il s'agit d'un terme général qui caractérise les principes de construction des systèmes d'aide à la décision - Decision Support System (DSS), des entrepôts de données - Data Warehouse, des systèmes de data mining - Data Mining. De tels systèmes sont conçus pour trouver des dépendances entre les données, pour effectuer une analyse dynamique sur le principe du "et si..." et des tâches similaires. Les applications OLAP fonctionnent sur de grandes quantités de données, accumulées dans l'entreprise ou provenant d'autres sources. Ces systèmes se caractérisent par les caractéristiques suivantes :

De nouvelles données sont ajoutées au système relativement rarement dans de grands blocs, par exemple, une fois par mois ou par trimestre ;

Les données ajoutées au système ne sont généralement jamais supprimées ;

avant le chargement, les données passent par diverses procédures préparatoires liées à leur mise à certains formats ;

Les demandes adressées au système sont ponctuelles et assez complexes ;

la vitesse d'exécution des requêtes est importante, mais pas critique.

Les bases de données dans les applications OLAP sont généralement représentées par un ou plusieurs hypercubes dont les dimensions sont des données de référence, et les cellules de l'hypercube lui-même stockent les valeurs de ces données. Physiquement, un hypercube peut être construit sur la base d'un modèle de données multidimensionnel spécial - OLAP multidimensionnel (MOLAP) ou représenté au moyen d'un modèle de données relationnel - OLAP relationnel (ROLA).

Dans les systèmes OLAP qui utilisent modèle relationnel données, il est opportun de stocker les données sous la forme de relations faiblement normalisées contenant des données de synthèse principales précalculées. La redondance des données et les problèmes qui y sont associés ne sont pas terribles ici, car elles sont mises à jour assez rarement et, avec la mise à jour des données, les totaux sont recalculés.

- Moyens d'assurer la fiabilité du système d'approvisionnement en eau

Assurer la fiabilité du système d'approvisionnement en eau, ainsi que d'autres systèmes de file d'attente, est l'une des principales tâches de leur conception. Le système doit être conçu et construit de manière à remplir ses fonctions pendant le fonctionnement avec un ... [en savoir plus]

- I. Concept de sécurité du système de protection

Le concept de sécurité du système en cours d'élaboration est « un ensemble de lois, de règles et de codes de conduite qui régissent la manière dont une organisation traite, sécurise et distribue les informations. En particulier, les règles déterminent dans quels cas l'utilisateur a le droit d'opérer avec ... [en savoir plus]

- Après avoir pris des décisions importantes sur la conception du système de chauffage

CONCEPTION D'UN SYSTÈME DE CHAUFFAGE D'EAU D'UN BÂTIMENT Dessiner des schémas d'unités thermiques lors du raccordement d'un système de chauffage selon les circuits ouverts et fermés. Questions d'auto-examen Lors du chauffage de plusieurs bâtiments. Des pompes et autres équipements sont installés ... [en savoir plus]

- Exigences pour assurer la sécurité incendie du système de prévention des incendies.

Bases de la sécurité la sécurité incendie procédés technologiques. Question 2. Prévention incendie de l'installation (25 min.) La prévention incendie comprend un ensemble de mesures organisationnelles et techniques visant à assurer la sécurité des personnes, ... [en savoir plus]

- Tissus et systèmes d'organes animaux

Tissus animaux. Les animaux ont également plusieurs types de tissus. Les plus importants d'entre eux sont les suivants. Les tissus épithéliaux sont des tissus de bordure qui recouvrent le corps de l'extérieur, tapissant les cavités internes et les organes qui composent le foie, les poumons, les glandes .... [en savoir plus]

Les génomes des eucaryotes supérieurs contiennent de nombreuses séquences d'ADN répétitives. Chez l'homme, par exemple, ces répétitions occupent plus de 40 % de l'ensemble du génome. Et il s'ensuit que lors de la formation des DSB, la probabilité de formation simultanée de plusieurs ruptures dans ... [lire la suite]

- Détermination des groupes sanguins du système ABO avec les coliclones anti-A, anti-B et anti-AB

DÉTERMINATION DES GROUPES SANGUINS Selon cette règle, tous les patients peuvent être transfusés avec du sang du groupe O (1), car il ne contient pas d'agglutinogènes, et les receveurs du groupe AB (IV) peuvent être transfusés avec du sang d'autres groupes, car il ne contient pas d'agglutinogènes. C'est là que les notions...

Panorama de l'informatique dédiée au traitement des données opérationnelles et analytiques

Après avoir étudié avec succès le matériel, vous saurez:

le concept et l'objectif principal des systèmes OLTP ;

concept et objectif principal des systèmes OLAP ;

classes de systèmes OLAP ;

tâches résolues par les systèmes OLTP et OLAP.

Après avoir étudié ce sujet, vous serez en mesure de :

distinguer les tâches résolues par les systèmes OLTP et OLAP ;

naviguer dans les classes des systèmes OLAP.

Après avoir étudié le matériel, vous vous aurez les compétences utilisation des systèmes OLTP et OLAP dans le travail du gestionnaire.

Concepts de base pour le sujet 7

technologies axées sur le traitement opérationnel (transactionnel) des données. Ces technologies sous-tendent le CIMS conçu pour le traitement de données en ligne. Sont appelés systèmes similaires- Systèmes OLTP (traitement des transactions en ligne) ;

technologies axées sur l'analyse des données et la prise de décision. Ces technologies constituent la base du CIMS conçu pour l'analyse des données accumulées. Ces systèmes sont appelés - systèmes OLAP (traitement analytique en ligne).

Systèmes OLAP

L'objectif principal des systèmes OLAP: dynamique analyse multivariée des données historiques et actuelles, stables dans le temps ; analyse de tendance; modéliser et prévoir l'avenir. Ces systèmes, en règle générale, se concentrent sur le traitement de demandes arbitraires et non pré-réglementées. Comme caractéristiques principales ces systèmes on peut noter ce qui suit:

prise en charge de la représentation multidimensionnelle des données, égalité de toutes les mesures, indépendance des performances par rapport au nombre de mesures ;

transparence pour l'utilisateur de la structure, des modalités de stockage et de traitement des données ;

mappage automatique de la structure de données logique vers des systèmes externes ;

traitement dynamique des matrices creuses de manière efficace.

Le terme OLAP est souvent assimilé aux systèmes d'aide à la décision DSS (Decision Support Systems). Et comme synonyme du terme "solutions", utilisez Entreposage de données - "stockages de données (entrepôts)". Il s'agit d'un ensemble de solutions organisationnelles, de logiciels et de matériel pour fournir aux analystes des informations basées sur des données provenant de systèmes de traitement des transactions de niveau inférieur et d'autres sources.

Les "entrepôts de données" permettent de traiter des données accumulées sur de longues périodes. Ces données sont hétérogènes (et pas nécessairement structurées). Pour les "entrepôts de données", la nature multidimensionnelle des requêtes est inhérente. D'énormes quantités de données, la complexité de la structure des données et des requêtes - tout cela nécessite l'utilisation de méthodes spéciales pour accéder aux informations.

Dans d'autres sources, le concept de système d'aide à la décision (DSS) est considéré comme plus large. Les entrepôts de données et les outils de traitement analytique en ligne peuvent constituer l'un des composants de l'architecture DSS.

OLAP inclut toujours le traitement interactif des requêtes et l'analyse ultérieure des informations en plusieurs passages, ce qui vous permet d'identifier diverses tendances, pas toujours évidentes, observées dans le domaine.

Parfois, OLAP se distingue au sens étroit - en tant que systèmes ne fournissant qu'une sélection de données dans diverses sections, et OLAP au sens large, ou simplement OLAP, notamment :

prise en charge de plusieurs utilisateurs éditant la base de données.

les fonctions de modélisation, y compris les mécanismes de calcul pour obtenir des résultats dérivés, ainsi que l'agrégation et la combinaison de données ;

prévisions, tendances et analyses statistiques.

Chacun de ces types de systèmes nécessite une organisation spécifique des données ainsi que des outils logiciels, garantissant la mise en œuvre effective des tâches à venir.

Les outils OLAP fournissent une analyse des informations commerciales sur une variété de paramètres, tels que le type de produit, l'emplacement géographique de l'acheteur, le moment de la transaction et le vendeur, chacun permettant la création d'une hiérarchie de vues. Ainsi, pour le temps, vous pouvez utiliser des intervalles annuels, trimestriels, mensuels et même hebdomadaires et quotidiens ; les répartitions géographiques peuvent être par villes, états, régions, pays ou, si nécessaire, par hémisphères entiers.

Les systèmes OLAP peuvent être divisés en trois classes.

1 classe. Les plus complexes et les plus coûteux d'entre eux reposent sur des technologies propriétaires. serveurs de bases de données multidimensionnelles. Ces systèmes offrent cycle complet traitement OLAP et comprennent, en plus du composant serveur, sa propre interface client intégrée, ou sont utilisés pour l'analyse des données programmes externes travailler avec des feuilles de calcul. Les produits de cette classe conviennent le mieux à une utilisation dans les grands entrepôts d'informations. Leur maintenance nécessite toute une équipe d'employés impliqués à la fois dans l'installation et la maintenance du système, ainsi que dans la formation de représentations de données pour les utilisateurs finaux. Habituellement, ces forfaits sont assez chers. Des exemples de produits de cette classe incluent Essbase d'Arbor Software, Express d'IRI (qui fait maintenant partie d'Oracle), Lightship de Pilot Software et d'autres.

Systèmes OLAP de 2 classes - systèmes OLAP relationnels(ROLA). Ici, les anciens SGBD relationnels sont utilisés pour stocker les données, et une couche de métadonnées définie par l'administrateur système est organisée entre la base de données et l'interface client. A travers cette couche intermédiaire, le composant client peut interagir avec une base de données relationnelle comme avec une base multidimensionnelle. Comme des outils de première classe, les systèmes ROLAP sont bien adaptés pour travailler avec de grandes référentiels d'informations, nécessitent des coûts de maintenance importants par des spécialistes des services informatiques et permettent de travailler en mode multi-utilisateurs. Les produits de ce type incluent IQ/Vision par IQ Software Corporation, DSS/Server et DSS/Agent par MicroStrategy, et DecisionSuite par Information Advantage.

Les outils ROLAP implémentent des fonctions d'aide à la décision au-dessus d'un processeur de base de données relationnelle.

Ces produits logiciels doivent répondre à un certain nombre d'exigences, notamment :

disposer d'un puissant générateur SQL optimisé pour OLAP qui vous permet d'utiliser des instructions SQL SELECT multi-passes et/ou des sous-requêtes corrélées ;

disposer d'outils suffisamment développés pour un traitement non trivial qui assure le classement, analyse comparative et calculer des pourcentages au sein d'une classe ;

générer des instructions SQL optimisées pour le SGBD relationnel cible, y compris la prise en charge des extensions de ce langage disponibles dans celui-ci ;

fournir des mécanismes pour décrire le modèle de données à l'aide de métadonnées et permettre l'utilisation de ces métadonnées pour construire des requêtes en temps réel ;

inclure un mécanisme permettant d'évaluer la qualité de construction des tableaux croisés dynamiques en termes de vitesse de calcul, de préférence avec l'accumulation de statistiques sur leur utilisation.

3e classe de systèmes OLAP - outils de requête et de rapport de bureau, complétées par des fonctions OLAP ou intégrées à des outils externes exécutant de telles fonctions. Ces systèmes très avancés extraient les données des sources d'origine, les transforment et les placent dans une base de données multidimensionnelle dynamique qui s'exécute sur le PC de l'utilisateur final. Cette approche, qui permet de se passer à la fois d'un serveur de base de données multidimensionnelle coûteux et d'une couche de métadonnées intermédiaire complexe nécessaire aux outils ROLAP, offre en même temps une efficacité d'analyse suffisante. Ces outils de bureau sont les mieux adaptés pour travailler avec de petites bases de données simplement organisées. Leur besoin de maintenance qualifiée est inférieur à celui des autres systèmes OLAP et correspond approximativement au niveau environnements normaux traitement de la demande. Parmi les principaux acteurs de ce secteur de marché figurent Brio Technology avec son système Brio Query Enterprise, Business Objects avec le produit du même nom et Cognos avec PowerPlay.

Systèmes OLTP

Systèmes OLTP, étant un moyen très efficace de réaliser des traitements en ligne, s'est avéré peu utile pour les tâches de traitement analytique. Ceci est causé par ce qui suit.

En utilisant les systèmes OLTP traditionnels, vous pouvez créer un rapport analytique et même une prévision de toute complexité, mais réglementée à l'avance. Toute étape de côté, toute exigence non réglementée de l'utilisateur final nécessite en règle générale une connaissance de la structure des données et une qualification assez élevée du programmeur;

De nombreux éléments essentiels pour les systèmes d'exploitation Fonctionnalité sont redondants pour les tâches analytiques et, en même temps, peuvent ne pas refléter le domaine. La plupart des tâches analytiques nécessitent l'utilisation d'outils externes spécialisés pour l'analyse, la prévision et la modélisation. La structure rigide de la base de données ne permet pas d'atteindre des performances acceptables dans le cas de sélections et de tris complexes et nécessite donc beaucoup de temps pour organiser les passerelles.

Contrairement aux systèmes transactionnels, les systèmes analytiques ne nécessitent pas et, par conséquent, ne prévoient pas de moyens avancés pour assurer l'intégrité des données, leur sauvegarde et leur récupération. Cela simplifie non seulement les outils de mise en œuvre eux-mêmes, mais réduit également les frais généraux internes et, par conséquent, améliore les performances lors de la récupération des données.

Tâches résolues par les systèmes OLTP et OLAP

Les tâches effectivement résolues par chacun des systèmes seront déterminées sur la base des caractéristiques comparatives des systèmes OLTP et OLAP (tableaux 7.1, 7.2).

Tableau 7.1.
Tâches résolues par les systèmes OLTP et OLAP

Caractéristique
Fréquence de mise à jour des données	Haute fréquence, petites portions	Basse fréquence, grandes "portions"
Les sources de données	Principalement interne	En ce qui concerne le système analytique, principalement externe
Âge des données	Actuel (plusieurs mois)	Historiquement (au fil des ans) et projeté
Niveau d'agrégation des données	Données détaillées	Données majoritairement agrégées
Capacités des opérations analytiques	Rapports réglementés	Séquence de rapports interactifs, changement dynamique des niveaux d'agrégation et des tranches de données
But du système	Enregistrement, recherche opérationnelle et informatique, traitement analytique réglementé	Travail avec des données historiques, traitement analytique, prévision, modélisation

Tableau 7.2.
ComparaisonOLTP etOLAP

Caractéristique
Opérations dominantes	Saisie de données, recherche	L'analyse des données
La nature des demandes	Beaucoup de transactions simples	Transactions complexes
Les données stockées	opérationnel, détaillé	couvrant une longue période de temps, agrégés
Type d'activité	opérationnel, tactique	Analytique, stratégique
Type de données	structuré	hétérogène

Principales conclusions

Dans le domaine de la gestion informatique, il existe deux domaines complémentaires :

• technologies axées sur le traitement des données opérationnelles (transactionnelles) - systèmes OLTP (traitement des transactions en ligne) ;

  technologies axées sur l'analyse des données et la prise de décision - systèmes OLAP (traitement analytique en ligne).

L'objectif principal des systèmes OLAP est l'analyse multidimensionnelle dynamique des données historiques et actuelles stables dans le temps, l'analyse des tendances, la modélisation et la prévision de l'avenir.

Les systèmes OLAP peuvent être divisés en trois classes.

1 classe. Serveurs de bases de données multidimensionnelles. Ces systèmes fournissent un cycle de traitement OLAP complet et incluent, en plus du composant serveur, leur propre interface client intégrée ou utilisent des tableurs externes pour analyser les données.

2e année Systèmes OLAP relationnels (ROLAP). Ici, les anciens SGBD relationnels sont utilisés pour stocker les données, et une couche de métadonnées définie par l'administrateur système est organisée entre la base de données et l'interface client. A travers cette couche intermédiaire, le composant client peut interagir avec une base de données relationnelle comme avec une base multidimensionnelle.

3e année Outils de requête et de rapport de bureau améliorés avec la fonctionnalité OLAP ou intégrés à des outils externes qui fournissent une telle fonctionnalité. Ces systèmes sélectionnent les données des sources originales, les convertissent et les placent dans une base de données multidimensionnelle dynamique qui fonctionne sur le PC de l'utilisateur final.

Les systèmes OLTP, étant un moyen très efficace de réaliser un traitement en ligne, se sont avérés peu utiles pour les tâches de traitement analytique.

Entreposage de données - "entrepôts de données (entrepôts)". Il s'agit d'un ensemble de solutions organisationnelles, de logiciels et de matériel pour fournir aux analystes des informations basées sur des données provenant de systèmes de traitement des transactions de niveau inférieur et d'autres sources.

question test

Quelles sont les deux directions mutuellement complémentaires dans le domaine de la gestion informatique ?

Formuler l'objectif principal des systèmes OLAP

Formuler l'objectif principal des systèmes OL T P

Que signifie le terme Data Warehousing ?

Tâches pour le travail indépendant

entrepôts de données sont constitués sur la base d'instantanés figés sur une longue période de bases de données Système d'Information et éventuellement diverses sources externes. Les entrepôts de données utilisent les technologies de base de données, OLAP, l'exploration de données, la visualisation de données.

Principales caractéristiques des entrepôts de données.

• contient des données historiques ;
• stocke des informations détaillées, ainsi que des données partiellement et complètement résumées ;
• les données sont principalement statiques ;
• manière non réglementée, non structurée et heuristique de traitement des données ;
• intensité moyenne et faible du traitement des transactions ;
• manière imprévisible d'utiliser les données ;
• conçu pour l'analyse;
• concentré sur domaines;
• soutien à la prise de décision stratégique;
• sert un nombre relativement restreint de cadres.

Le terme OLAP (On-Line Analytical Processing) est utilisé pour décrire le modèle de présentation des données et, par conséquent, la technologie de leur traitement dans les entrepôts de données. OLAP utilise une vue multidimensionnelle des données agrégées pour fournir un accès rapide aux informations stratégiques. une information importantà des fins d'analyse approfondie. Les applications OLAP doivent avoir les propriétés de base suivantes :

• multidimensionnel présentation des données;
• prise en charge des calculs complexes ;
• bonne prise en compte du facteur temps.

Avantages d'OLAP :

• promotion performance personnel de production, développeurs programmes d'application. Accès rapide aux informations stratégiques.
• donner aux utilisateurs suffisamment de pouvoir pour apporter leurs propres modifications au schéma.
• Les applications OLAP reposent sur entrepôts de données et les systèmes OLTP, recevant des données à jour de leur part, ce qui permet d'économiser contrôle d'intégrité données d'entreprise.
• réduire la charge sur les systèmes OLTP et entrepôts de données.

OLAP et OLTP. Caractéristiques et principales différences

OLAP	OLTP
Magasin de données doit inclure à la fois les données internes de l'entreprise et les données externes	la principale source d'information entrant dans la base de données opérationnelle est les activités de la société, et l'analyse des données nécessite l'implication de sources d'information externes (par exemple, des rapports statistiques)
Le volume des bases de données analytiques est au moins supérieur d'un ordre de grandeur au volume des bases de données opérationnelles. pour une analyse et des prévisions fiables dans magasin de données vous devez avoir des informations sur les activités de la société et l'état du marché depuis plusieurs années	Pour le traitement opérationnel, les données des derniers mois sont requises
Magasin de données doivent contenir des informations présentées de manière uniforme et convenues, aussi proches que possible du contenu des bases de données opérationnelles. Un composant est nécessaire pour extraire et "nettoyer" les informations de différentes sources. Dans de nombreuses grandes entreprises, il existe plusieurs systèmes d'information opérationnels avec leurs propres bases de données en même temps (pour des raisons historiques).	Les bases de données opérationnelles peuvent contenir des informations sémantiquement équivalentes présentées dans différents formats, avec des indications différentes de l'heure de sa réception, parfois même contradictoires
L'ensemble des requêtes sur une base de données analytique ne peut pas être prédit. entrepôts de données existent pour répondre aux demandes ponctuelles des analystes. Vous ne pouvez que compter sur le fait que les demandes ne viendront pas trop souvent et n'affecteront pas de grandes quantités d'informations. La taille des bases de données analytiques encourage l'utilisation de requêtes avec des agrégats (somme, min, max, valeur moyenne etc.)	Les systèmes de traitement de données sont conçus pour résoudre tâches spécifiques. Les informations de la base de données sont sélectionnées fréquemment et par petites portions. Habituellement, un ensemble de requêtes vers la base de données opérationnelle est déjà connu lors de la conception
Avec une petite variabilité des bases de données analytiques (uniquement lors du chargement des données), l'ordre des tableaux, les méthodes d'indexation plus rapides pour l'échantillonnage de masse et le stockage des données pré-agrégées s'avèrent raisonnables	Les systèmes de traitement de données sont par nature très variables, ce qui est pris en compte dans le SGBD utilisé (structure de base de données normalisée, stockage des lignes dans le désordre, arbres B pour l'indexation, transactionnalité)
Les informations des bases de données analytiques sont tellement critiques pour l'entreprise qu'une grande granulation de protection est nécessaire (droits d'accès individuels à certaines lignes et/ou colonnes du tableau)	Pour les systèmes de traitement de données, il suffit généralement protection des informations au niveau du tableau

Règles Codd pour les systèmes OLAP

En 1993, Codd a publié OLAP for Analyst Users: What It Should Be Like. Dans ce document, il a décrit les concepts de base du traitement analytique en ligne et identifié 12 règles que les produits doivent respecter pour fournir un traitement analytique en ligne.

1. Représentation multidimensionnelle conceptuelle. Un modèle OLAP doit être multidimensionnel à la base. Un diagramme conceptuel multidimensionnel ou une représentation personnalisée facilite la modélisation et l'analyse ainsi que les calculs.
2. Transparence. L'utilisateur peut obtenir toutes les données nécessaires de la machine OLAP, sans même se douter d'où elles viennent. Que le produit OLAP fasse ou non partie des outils de l'utilisateur, ce fait doit être invisible pour l'utilisateur. Si OLAP est fourni par l'informatique client-serveur, alors ce fait devrait aussi, si possible, être invisible pour l'utilisateur. OLAP doit être fourni dans le vrai contexte architecture ouverte, permettant à l'utilisateur, où qu'il se trouve, de communiquer à l'aide d'un outil d'analyse avec le serveur. De plus, la transparence doit également être atteinte lorsque l'outil d'analyse interagit avec des environnements de bases de données homogènes et hétérogènes.
3. Disponibilité. OLAP doit fournir ses propres schéma logique accéder dans un environnement de base de données hétérogène et effectuer les transformations appropriées pour fournir des données à l'utilisateur. De plus, il est nécessaire de s'assurer à l'avance où et comment, et quels types d'organisation physique des données seront effectivement utilisés. Un système OLAP ne doit accéder qu'aux données réellement nécessaires et ne pas appliquer le principe général de "l'entonnoir de cuisine" qui implique une saisie inutile.
4. Constante performance lors de l'élaboration des rapports. Performance le reporting ne doit pas chuter de manière significative avec la croissance du nombre de dimensions et de la taille de la base de données.
5. Architecture client-serveur. Il est nécessaire que le produit soit non seulement client-serveur, mais aussi que le composant serveur soit suffisamment intelligent pour divers clients pourrait se connecter avec un minimum d'effort et de programmation.
6. Multidimensionnalité générale. Toutes les dimensions doivent être égales, chaque dimension doit être équivalente à la fois en structure et en capacités opérationnelles. Certes, des possibilités opérationnelles supplémentaires sont autorisées pour les mesures individuelles (apparemment, le temps est implicite), mais de telles fonctions supplémentaires doit être donné à n'importe quelle dimension. Il ne devrait pas en être ainsi que la base structures de données, les formats de calcul ou de rapport étaient plus spécifiques à une dimension.
7. Contrôle dynamique matrices creuses. Les systèmes OLAP doivent configurer automatiquement leur circuit physique selon le type de modèle, les volumes de données et la rareté de la base de données.
8. Prise en charge multi-utilisateurs. L'outil OLAP doit permettre partage(demande et ajout), intégrité et sécurité.
9. Opérations croisées illimitées. Toutes sortes d'opérations doivent être autorisées pour toute mesure.
10. Manipulation intuitive des données. La manipulation des données a été effectuée par des actions directes sur les cellules en mode visualisation sans utiliser de menus et de multiples opérations.
11. Options de rapport flexibles. Les mesures doivent être placées dans le rapport de la manière souhaitée par l'utilisateur.
12. Illimité

Tout a commencé par une histoire qui s'est produite dans ma carrière professionnelle il y a trois ans lorsque je travaillais au Kirghizistan, dans une entreprise qui était une chaîne de magasins de détail. Ensuite, j'ai eu une conversation avec mon directeur informatique, qui m'a dit : « Denis, nous avons l'une des opérations les plus importantes et les plus critiques - c'est le document de contrôle à la caisse. Comment accélérer au maximum ce processus, le paralléliser, tout en obtenant des résidus opérationnels ?

Je dois dire tout de suite qu'à l'époque nous utilisions la plateforme 8.1 et serrures automatiques. Et puis je lui ai répondu que oui, on peut passer aux serrures gérées et paralléliser ce processus au niveau de la nomenclature. A quoi il m'a posé une question naturelle : "que se passera-t-il si on a la même nomenclature à plusieurs caisses en même temps ?" Ensuite, je ne pouvais pas donner de réponse claire à cette question, mais j'espère que maintenant je réussirai.

Tendances de développement matériel

Si nous regardons développement de l'industrieinformatique au cours des dernières années, nous verrons certains tendances matérielles:

• La première tendance concerne la mémoire. Ce n'est une nouvelle pour personne que la mémoire devient moins chère avec le temps, et au ce moment nous déjà nous pouvons obtenir une assez grande quantité de mémoire pour relativement peu d'argent.
• La deuxième tendance concerne les transformateurs. Tout le monde connaît la correspondance entre l'augmentation des performances, la consommation électrique et la température allouée aux processeurs selon la loi de Moore. À un moment donné, cette correspondance au niveau d'un noyau s'est terminée (maintenant nous avons déjà un noyau longue durée je ne peux pas en faire un opération simple plus rapide qu'avant), mais cela a continué au niveau de nombreux cœurs (processeurs multicœurs). Par conséquent, tous nos espoirs et nos pensées vont à la région traitement en parallèle, et nous en tant que développeurs et architectes de SGBD, pour améliorer les performances de nos applications, nous devons prévoir un travail parallèle dans celles-ci.

Tendances de développement d'applications d'entreprise

Que se passe-t-il en ce moment au niveau de l'entreprise? On observe: un nombre croissant d'utilisateurs qui utilisent de plus en plus dispositifs, sur lequel un nombre croissant de programmes, et tout cela génère à son tour de plus en plus Les données.

Où la plupart de ces processus sont pris en charge par les nuages.

Outre les nuages, il existe également une entité telle que la mobilité, qui est une combinaison de tous appareils mobiles, ainsi que les programmes et les données qu'ils génèrent.

Les nuages ​​et la mobilité ont toujours été liés, et c'est de l'interaction de ces deux entités que nous pourrons faire des percées dans le futur. Cette interaction a conduit à l'émergence d'une stratégie bien connue en occident : Mobile-First - Cloud-First (initialement mobile et initialement cloudy).

L'industrie informatique a toujours changé, et est en train de changer, de vivre une transformation. Et dans ce monde, à l'origine mobile et à l'origine nuageux, le taux de formation augmente constamment celles-ci données, et cette croissance est exponentielle. Basé sur ceci il y a un problème de sauvegarde, d'accumulation et de mise à jour des informations, qui entre dans nos systèmes à un rythme de plus en plus rapide.

Respectivement, il faut des technologies spéciales. Et, en parlant spécifiquement d'OLTP en mémoire, ce n'est qu'une des nombreuses technologies actuellement conçues pour assurer le développement futur de l'industrie informatique.

Technologie OLTP en mémoire

Pourquoi l'OLTP en mémoire a-t-il vu le jour ? Et pourquoi est-ce important?

• Le fait est que les entreprises sont de plus en plus exigeantes :
  • à un débit sans cesse croissant :
  • au processus OLTP attendu avec une vitesse prévisible et des retards minimes et pour peu d'argent.
• À son tour, le matériel impose des exigences aux bases de données relationnelles pour suivre les dernières modifications de l'architecture matérielle.

Respectivement, Dans-MémoireOLTP- c'est: mécanisme de haute performance, lequel rencontre le matériel moderne et maximum optimisé pour la mémoire.

Et, plus important encore, l'OLTP en mémoire n'est pas un produit distinct (pas une licence distincte que vous devez payer). Commençant parSQLServeur 2014 OLTP en mémoire - ça fait partie du noyau ce produit, qui est disponible dans le cadre de l'éditionEntreprise.

Ici vous voyez trois composants principaux qui composent la technologieDans-MémoireOLTP. Ce sont eux qui lui permettent de réaliser un tel effet de rupture :

• Le premier est une déclaration claire que toutes les données sont en mémoire.
• Deuxièmement, et surtout, ces les données se trouvent dans spécialement conçu, structures de données sans verrou.
• Et le troisième est la compilation native, native. Elle représente procédures stockées contenant une logique métier qui sont compilées en code machine en mémoireServeurs SQL.

Comparaison de l'infrastructure d'interopérabilité (ancien vs OLTP en mémoire)

Si nous voyons le schéma traditionnel d'interaction entre le client et le SGBD, alors tout est clair :

• Nous avons client avec son client appelle,
• Il y a serveur 1C:Entreprise, lequel contient toute la logique métier.
• Et voici Serveur SGBD. Dans le schéma traditionnel, il est principalement utilisé pour la manipulation de données(spécifiquement - pour quatre opérations : sélection, accumulation, modification et suppression).

En cas d'application du régimeDans-MémoireOLTP dans le cadre de la plateforme 1C, le schéma change légèrement :

• Rester Le même clients avec leurs appels clients.
• Mais dans ce cas serveur 1C:Entreprise Peu se transforme. En général, toutes ses fonctions et son objectif restent complètement, mais maintenant on ne peut pas dire qu'il contrôle complètement toute la logique métier existante. Ici, je l'ai appelé la couche serveur logiciel. Pourquoi?
  • car une connexion directe externe supplémentaire au SGBD apparaît, qui appelle les procédures stockées dont j'ai parlé plus tôt.
  • Essence celles-ci procédures stockées consiste désormais pour effectuer des opérations de données conformément à jouet logique métier, que vous avez posé au niveau du SGBD.

Un exemple frappant de la façon dont la couche physique "fuite" vers la couche logique.

Principaux avantages de l'OLTP en mémoire

Cette diapositive répertorie certaines des fonctionnalités clés de la technologie OLTP en mémoire. Vous pouvez en savoir plus à ce sujet sur Internet (principalement sur le site Web de Microsoft, ainsi que dans un grand nombre de blogs de développeurs occidentaux). Ici, je veux clarifier une nuance que je n'ai pas encore mentionnée : l'OLTP en mémoire a un tout nouveau contrôle de concurrence optimiste multiversion. En son sein, complètement absent quelconque le concept de verrous lorsque vous travaillez avec des données. Dans son fonctionnement, les conflits entre différents threads sont rares, mais s'ils se produisent, ils sont rapidement résolus et il n'est pas nécessaire d'attendre très longtemps, comme dans le cas de l'utilisation d'un mécanisme de blocage standard.

Scénario de test pour vérifier le fonctionnement de la technologie OLTP en mémoire au sein de la plate-forme 1C

En analysant les opportunités offertes par la technologie OLTP In-memory, j'ai décidé de mettre en place un scénario de test assez simple pour tester le fonctionnement de cette technologie au sein de la plateforme 1C. Environnement de démonstration, que j'ai obtenu en conséquence, ressemblait à ça:

• j'ai pris très simple configuration avec un registre d'accumulation, qui prenait en compte les bilans par nomenclature dans le cadre de la quantité.
• Aussi dans cette configuration était deux documents - Revenus et dépenses, dans lequel la logique métier suivante a été implémentée :
  • Le document paroissial appuie le solde minimum.
  • Et lors de la comptabilisation du document Dépenses, l'absence de soldes nuls était contrôlée.
• Pour ça imiter la concurrence multithread charge lors de la réalisation de ces documents, je utilisé l'approche standard avec des processus d'arrière-plan, qui pour le document Dépense était la grande majorité.
• Il convient également de noter que dans mon réseau de démonstration, j'ai utilisé deux machines virtuelles:
  • Un - pour le serveur 1C : Entreprise,
  • Et un autre - pourServeurs SQL.

Mais les deux machines virtuelles étaient au sein d'un seul hôte de virtualisation.

Première mesure - ligne de base

Après la mise en place de ce schéma, j'ai effectué contrôler la mesure des indicateurs de base pour une exploitation standard et traditionnelle documents à l'aide d'outils 1C à l'aide de verrous gérés. Qu'est-ce que j'ai obtenu à la suite de la première mesure ?

La valeur de l'indicateur que j'ai reçu est soulignée sur la diapositive. : 120 documents par secondeà 64 processus d'arrière-plan, c'est la ligne de base que j'avais.

Serveurs SQL. - les processeurs se reposent, seuls les verrous gérés fonctionnent.

La deuxième mesure - migration vers des tables In-Memory uniquement

L'étape suivante que j'ai décidé de faire était de migrer les structures qui stockaient les données standard versDans-tables de mémoire. Et après les avoir migrés, j'ai exécuté mon test standard. La même chose s'y est produite: les documents ont été traités à l'aide de la plate-forme 1C, mais ce n'est que maintenant qu'ils étaient déjà stockés dans des tables en mémoire (la plate-forme elle-même ne le savait pas).

Résultat s'est avéré dans la région 150 documents par seconde, par conséquent, une petite augmentation s'est produite, mais pas significative, et sur certains systèmes, vous pouvez même ne pas voir cette augmentation. En général, dans ce cas La charge CPU n'a pas changé. donc je ne les inclurai pas ici.

Je veux ajouter à cela que si quelqu'un a essayé de mettre en œuvre la même tâche, cela pose généralement des problèmes - un peu plus tard, je vous dirai comment ces problèmes sont résolus.

La troisième mesure est la migration vers In-Memory des tables et de la logique métier

A la troisième étape, outre le fait que la migration des structures de données versDans-tables de mémoire, a également été complètement migré et que logique métier, qui était nécessaire pour conserver les documents - toutes les actions nécessaires pour :

• Formation de documents et de leurs parties tabulaires ;
• Leurs dossiers ;
• Formation de mouvements de documents ;
• Et les changements dans les soldes courants.

En conséquence, reçu résultat 250 documents par seconde. En fait, par rapport à l'indicateur de base, 120 et 250 est un gain d'un peu plus du double.

Ici on peut rire un peu et se dire qu'on peut prendre du fer deux fois plus puissant et obtenir à peu près le même résultat. Mais tout s'explique si l'on regarde la charge processeur dans ce cas :

• Server 1C:Enterprise est entièrement chargé;
• Tandis que serveurSQL est seulement un tiers occupé.

J'ai réussi à découvrir que cette charge sur le serveur 1C: Enterprise montrait qu'il n'avait tout simplement pas le temps de générer ce nombre de documents à la volée, et qu'il n'avait pas non plus le temps de les envoyer au serveur SQL pour le charger complètement.

Plus tard, nous avons réussi à découvrir que pour charger complètement le serveur SQL dans cet exemple, il faudrait environ huit de ces machines virtuelles. Mais cela n'aurait toujours aucun sens, car je n'utilisais qu'un seul hôte de virtualisation et je n'avais pas de matériel dédié supplémentaire. Mais plus tard, ce n'était pas nécessaire.

Quatrième mesure - transfert de 15 documents à conserver en un seul appel

Quatrième mesure Je l'ai fait dans l'espoir qu'il serait toujours possible d'envoyer au serveur SQL en un seul appel réseau plus de travail. Pour ce faire, la logique métier a été réécrite de telle sorte que soumettre 15 documents pour traitement à la fois en un seul appel. Par conséquent vitesse augmentée à 550 documents par seconde.

En même temps, comme on peut le voir sur les graphiques, serveur 1C:Entreprise a été encore entièrement chargé, etSQL Server a continué à "se reposer".

En fait, ce scénario est plutôt faux, car il n'a aucune utilité pratique et n'a été implémenté qu'à titre de test. Mais dans tous les cas, on voit clairement le problème de transférer suffisamment de charge au serveur SQL pour le charger complètement.

Cinquième mesure - exécuter une charge préparée du côté de SQL Server

L'étape suivante, j'ai décidé de générer la totalité de la charge à l'avance. Cette charge avait l'air sous forme de 64 fichiers générésScripts SQL pour 700 mégaoctets. JE SUIS les a transférés àserveur SQL, et avec l'aide du célèbre utilitaire OSstress, qui peut "alimenter" ces fichiers afin de démarrer un chargement parallèle, j'ai obtenu le résultat suivant.

• Par charge CPU- le temps de travail résultant rentre dans la fenêtre standard du gestionnaire de tâches : il y a un début de charge, puis complètement tous les processeurs presque
• Suite à la charge, 112 mille documents, dans le même temps, tous les processus qui étaient lors de l'exécution des documents «Dépenses» ont été complètement préservés: tous les soldes ont été contrôlés, toutes les actions ont été effectuées.
• La charge a pris 53 secondes et plus.
• Si nous faisons quelques calculs, il s'avère que temps moyen un document représentait moins d'une demi-milliseconde,
• un la vitesse moyenne de traitement des documents était supérieure à 2000 documents par seconde.

Quand j'ai eu ce résultat pour la première fois, je ne pouvais pas y croire. Imaginez quels volumes sont maintenant disponibles pour vous, vous pouvez maintenant penser à des catégories complètement différentes. Et maintenant, je peux répondre à mon ancien directeur informatique comment nous pouvons accélérer le traitement des documents Check à la caisse. Et même si en même temps nous avons des conflits, des blocages, le processus lui-même va maintenant aller très vite.

Méthodologie de migration

Si nous revenons à la méthodologie de la migration dans Dans-MémoireOLTP, il convient de noter qu'il ne convient pas à tous les cas. Il ne doit être utilisé que pour certains goulots d'étranglement de votre système où un accès rapide garanti aux données est important. ainsi avant de mettre en œuvre cette technologie, il est nécessaire de procéder à une analyse approfondie:

• Par exemple, si nous comparons les piles d'exécution (OLTP traditionnel et en mémoire), alors rien n'a changé au niveau de l'interaction réseau. Ainsi, si votre programme (votre application) est très "bavard", il échange avec le serveur du SGBD très grande quantité messages, alors la technologie In-Memory ne vous aidera pas du tout - il n'y a aucune amélioration ici.
• Aussi, si nous regardons niveau de journalisation de la base de données, alors ici aussi surtout rien n'a changé. Bien que la taille du journal des opérations OLTP en mémoire soit réduite, la latence minimale des transactions pour l'écriture dans le journal reste la même.
• Avantage principal vous ne peut être obtenu qu'au niveau de l'exécution des requêtes et de l'accès aux données.

Avantage technologiqueDans-MémoireOLTP ne pas dans que les données sont en mémoire. Bien que la technologie s'appelle In-memory, le gain ne vient pas de là - l'accélération vient du fait que que l'infrastructure de la base de données elle-même est en train de changer:

• sont utilisés nouveau, spécialement conçu structures de données dépourvues de verrous,
• aussi bien que des procédures stockées compilées nativement sont utilisées, qui stockent votre logique métier critique.

Et, si nous regardons le système standard, alors si un grand nombre de threads y sont ajoutés, ils commencent finalement à interférer les uns avec les autres, ce qui débit votre système est réduit. Dans le même temps, lors de l'utilisation de la technologie OLTP en mémoire, le système continue d'évoluer avec une augmentation du nombre d'utilisateurs, car il n'y a pas de verrous (de nouvelles structures de données sont utilisées qui en sont privées) et des stockages rapides et précompilés procédures sont également utilisées.

Que peut-on dire de la processus de migration versDans-Mémoire? Il est généralement se compose de deux étapes, qui se répètent tour à tour :

• La première étape est migration de structure de données.
• Et la deuxième étape est migration votre critique.

Résoudre le problème de l'écriture en mémoire à partir de 1C

Lorsque vous travaillez à partir de 1C avec des structures de données migrées du côté du SGBD, certaines difficultés sont possibles. Par exemple, si, avec des tables migrées au sein de la plate-forme 1C, quelqu'un essaie de faire une sorte d'enregistrement dans des tables ou des documents (revenus ou dépenses), vous verrez message d'erreur standard qui généralement parle de certains problèmes dans les niveaux d'isolement.

Qu'est ce qui cause cette erreur? Le schéma d'exécution standard prend en charge cinq niveaux d'isolation, tandis que le moteur OLTP en mémoire ne prend en charge que trois niveaux. Où La plate-forme 1C utilise le niveau d'isolement par défautReadCommited, qui tout simplement pas correspondance dans le mécanismeDans-MémoireOLTP. Il existe donc un problème de cohérence entre ces niveaux d'isolement.

J'ai passé beaucoup de temps à essayer de résoudre ce problème. Et la recherche d'une solution m'a même conduit à la rétro-ingénierie ("reverse engineering"), il me semblait qu'il faudrait intercepter dynamiquement les requêtes qui vont de la plateforme au SGBD et modifier leur texte à la volée pour qu'elles deviennent compatible avec la syntaxe In-Memory . Mais il s'est avéré que la solution est en surface - c'est trivial et simple.

Dans SQL Server 2014 lui-même, dans lequel la technologie In-Memory est apparue, il y a un tel propriété de la base de données, Comment est_Mémoire_optimisé_élever_pour_instantané_au. Par défaut, il est inactif, désactivé - cela peut être vérifié par la requête affichée sur la diapositive.

Respectivement, si vous lancez une commande qui active cette propriété, ensuite vous n'aurez pas de problèmes avec la cohérence des niveaux d'isolement.

En faisant cela, vous augmenterez le niveau d'isolement que le SGBD utilise par défaut, et il correspondra simplement au niveau d'isolement Snapshot par défaut utilisé pour les tables en mémoire. Ainsi, après avoir effectué de petites manipulations côté SGBD, tous les documents et toutes les données seront écrits dans vos tables In-Memory.

Schéma général de migration de la logique métier côté SGBD

Que peut-on dire sur le schéma général de la migration plus logique métier côté SGBD?

Il comprend en toi deux objets:

• D'abord, c'est celui procédure compilée qui fera le travail proprement dit.
• Et sur elle wrapper qui implémente soi-disant RéessayerLogique (logique de redémarrage). Pourquoi? Parce qu'il n'y a aucune garantie que votre procédure stockée s'exécutera. Au cours de son exécution, une sorte de conflit peut survenir, vous devez donc faire de sorte qu'en conséquence un réseau spécifique appelle ceci procédure, qui implémente votre logique métier, veillez à terminé jusqu'au bout.

Ici un schéma exemplaire pour la mise en œuvre du "wrapper". Ici, AddOutcome est le StandardT-SQL-(wrapper) externe. À l'intérieur de la boucle se trouve une procédure déjà directement compilée en codes machine. Vous pouvez voir le bloc TRY (Retry). En conséquence, si un conflit se produit, une exception se produit dans laquelle vous, en tant que développeur, définissez une sorte de période d'attente afin que la transaction en conflit ait le temps de s'exécuter, puis, en conséquence, la vôtre sera exécutée.

Conclusion

Eh bien, en conclusion, nous pouvons dire que migration vers des tablesDans-MémoireOLTP par rapport à 1C nécessitera l'utilisation de:

• Un grand nombre de ressources intellectuelles et financières,
• Connecter un grand nombre de spécialistes.
• Eh bien, la question la plus fondamentale est que soutien technologiqueDans-MémoireOLTP n'est pas actuellement dans la plate-forme, et à cet égard, vous ne pouvez regarder que dans la direction de la société 1C. À tout le moins, j'espère qu'ils répondront bien à l'émergence de la possibilité d'utiliser cette technologie au sein de la plate-forme.

*****************

Nous vous invitons à une nouvelle conférence.

Dans le domaine des technologies de l'information, il existe deux domaines complémentaires :

Technologies axées sur le traitement opérationnel (transactionnel) des données. Ces technologies sont au cœur de l'économie systèmes d'information pour le traitement des données en ligne. De tels systèmes sont appelés OLTP(traitement des transactions en ligne) systèmes;

Technologies axées sur l'analyse des données et la prise de décision. Ces technologies sous-tendent les systèmes d'information économique destinés à analyser

données accumulées. De tels systèmes sont appelés OLAP

(processus analytique en ligne) systèmes.

L'objectif principal des systèmes OLAP- dynamique multidimensionnelle

analyse des données historiques et actuelles, stable dans le temps, analyse

tendances, modéliser et prévoir l'avenir. Tel

les systèmes, en règle générale, se concentrent sur le traitement arbitraire,

demandes pré-régulées. En tant que principal

Les caractéristiques de ces systèmes sont les suivantes :

Prise en charge de la représentation multidimensionnelle des données, égalité de toutes les dimensions, indépendance des performances par rapport au nombre de dimensions ;

Transparence pour l'utilisateur de la structure, des méthodes de stockage et de traitement des données ;

Mappage automatique de la structure de données logique sur des systèmes externes ;

Traitement dynamique des matrices creuses de manière efficace.

Le terme OLAP est relativement nouveau et est parfois interprété différemment dans différentes sources littéraires. Ce terme est souvent identifié à l'aide à la décision (DSS (Decision Support Systems) - systèmes d'aide à la décision. Et comme synonyme de ce dernier terme, ils utilisent Data Warehousing - entrepôts de données, c'est-à-dire un ensemble de solutions organisationnelles, logicielles et matérielles pour fournir aux analystes avec des informations basées sur des données provenant de systèmes de traitement des transactions de niveau inférieur et d'autres sources

Les « entrepôts de données » permettent de traiter des données accumulées sur de longues périodes. Ces données sont hétérogènes (et pas nécessairement structurées). Pour les "entrepôts de données", la nature multidimensionnelle des requêtes est inhérente. D'énormes quantités de données, la complexité de la structure des données et des requêtes nécessitent l'utilisation de méthodes spéciales pour accéder à l'information.

Dans d'autres sources, le concept de système d'aide à la décision (DSS) est considéré comme plus large. Les entrepôts de données et les outils de traitement analytique en ligne peuvent constituer l'un des composants de l'architecture DSS.

OLAP inclut toujours le traitement interactif des requêtes et l'analyse ultérieure des informations en plusieurs passages, ce qui vous permet d'identifier diverses tendances, pas toujours évidentes, observées dans le domaine.

Parfois, il y a une distinction entre "OLAP au sens étroit" - ce sont des systèmes qui ne fournissent qu'une sélection de données dans diverses sections, et "OLAP au sens large", ou simplement OLAP, qui comprend :

Prise en charge de plusieurs utilisateurs modifiant la base de données.

Fonctions de modélisation, y compris les mécanismes de calcul pour obtenir des résultats dérivés, ainsi que pour agréger et combiner des données ;

Prévisions, tendances et analyses statistiques.

Naturellement, chacun de ces types de SI nécessite une organisation spécifique des données, ainsi que des outils logiciels spécifiques qui assurent la mise en œuvre efficace des tâches à accomplir.

OLAP - les outils fournissent une analyse des informations commerciales sur une variété de paramètres, tels que le type de produit, la situation géographique de l'acheteur, le moment de la transaction et le vendeur, chacun permettant la création d'une hiérarchie de vues. Ainsi, pour le temps, vous pouvez utiliser des intervalles annuels, trimestriels, mensuels et même hebdomadaires et quotidiens ; les répartitions géographiques peuvent être par villes, états, régions, pays ou, si nécessaire, par hémisphères entiers.

Les systèmes OLAP peuvent être divisés en trois classes.

Les plus complexes et les plus coûteux d'entre eux reposent sur des technologies propriétaires. serveurs de bases de données multidimensionnelles. Ces systèmes fournir un cycle complet de traitement OLAP et soit inclure, en plus du composant serveur, leur propre interface client intégrée, soit utiliser des tableurs externes pour l'analyse des données. Les produits de cette classe conviennent le mieux à une utilisation dans les grands entrepôts d'informations. Leur maintenance nécessite toute une équipe d'employés impliqués à la fois dans l'installation et la maintenance du système, ainsi que dans la formation de représentations de données pour les utilisateurs finaux. Habituellement, ces forfaits sont assez chers. Des exemples de produits de cette classe incluent Essbase d'Arbor Software, Express d'IRI (qui fait maintenant partie d'Oracle), Lightship de Pilot Software et d'autres.

Il est à noter qu'un des moyens d'assurer un traitement rapide des données lors de leur analyse est l'organisation des données sous forme de bases de données multidimensionnelles (MDD). Les informations dans MDD ne sont pas stockées sous forme d'enregistrements indexés dans des tables, mais sous la forme de tableaux ordonnés logiquement. Il n'existe pas de modèle unique de stockage de données multidimensionnel universellement reconnu. MDD ne dispose pas d'une méthode standardisée d'accès aux données et peut répondre à des exigences de traitement de données analytiques spécifiques.

Au total, les comparaisons entre différents produits MDD ne peuvent se faire que dans les catégories les plus généralisées. Dans le secteur le moins cher du marché, il n'y a que des mono-utilisateurs et conçus pour les petits réseaux locaux visionneuse de données multidimensionnelles. Bien qu'ils aient assez haut niveau fonctionnalité et facilité d'utilisation, ces systèmes ont une portée limitée. et ils n'ont pas les outils nécessaires pour mettre en œuvre OLAP - le traitement au sens le plus large. Les produits entrant dans cette catégorie incluent PowerPlay de Cognos, PaBlo d'Andyne et Mercury de Business Objects. Le secteur cher du marché est représenté par Acumate ES de Kenan Technologies, Express d'Oracle, Gentium de Planning Sciences et Holos de Holistic Systems. Ils diffèrent tellement dans leurs capacités que chacun d'entre eux peut être séparé en toute sécurité dans une catégorie distincte. Enfin, les systèmes MDD purs : Essbase d'Arbor Software, LightShip Server de Pilot Software et TM/1 [N. Raden (marché du logiciel)].

La deuxième classe d'outils OLAP - systèmes OLAP relationnels(ROLA). Ici, les anciens SGBD relationnels sont utilisés pour stocker les données, et une couche de métadonnées définie par l'administrateur système est organisée entre la base de données et l'interface client. A travers cette couche intermédiaire, le composant client peut interagir avec une base de données relationnelle comme avec une base multidimensionnelle. Comme des outils de première classe, les systèmes ROLAP sont bien adaptés pour fonctionner avec de grands entrepôts d'informations, nécessitent des coûts de maintenance importants par des spécialistes du service d'information et permettent un fonctionnement multi-utilisateurs. Les produits de ce type incluent IQ/Vision par IQ Software Corporation, DSS/Server et DSS/Agent par MicroStrategy, et DecisionSuite par Information Advantage.

ROLAP - les outils implémentent des fonctions d'aide à la décision dans un module complémentaire sur un processeur de base de données relationnelle.

Ces produits logiciels doivent répondre à un certain nombre d'exigences, notamment :

Avoir un puissant générateur SQL optimisé pour OLAP qui vous permet d'utiliser plusieurs passes Instructions SQL SELECT et/ou sous-requêtes corrélées ;

Disposer d'outils suffisamment développés pour un traitement non trivial permettant un classement, une analyse comparative et un calcul de pourcentages au sein d'une classe ;

Générer des instructions SQL optimisées pour le SGBD relationnel cible, y compris la prise en charge des extensions de ce langage disponibles dans celui-ci ;

Fournir des mécanismes de description du modèle de données à l'aide de métadonnées et permettre l'utilisation de ces métadonnées pour construire des requêtes en temps réel ;

Inclure un mécanisme permettant d'évaluer la qualité de construction des tableaux croisés dynamiques en termes de vitesse de calcul, de préférence avec l'accumulation de statistiques sur leur utilisation.

Troisièmement, relativement nouveau genre OLAP -outils - outils de requête et de rapport de bureau, complétées par des fonctions OLAP ou intégrées à des outils externes exécutant de telles fonctions. Ces systèmes très avancés extraient les données des sources d'origine, les transforment et les placent dans une base de données multidimensionnelle dynamique qui s'exécute sur le PC de l'utilisateur final. Cette approche, qui permet de se passer à la fois d'un serveur de base de données multidimensionnelle coûteux et d'une couche de métadonnées intermédiaire complexe nécessaire aux outils ROLAP, offre en même temps une efficacité d'analyse suffisante. Ces outils de bureau sont les mieux adaptés pour travailler avec de petites bases de données simplement organisées. Le besoin d'une maintenance qualifiée pour eux est inférieur à celui des autres systèmes OLAP et correspond approximativement au niveau des environnements de traitement de requêtes conventionnels. Parmi les principaux acteurs de ce secteur de marché figurent Brio Technology avec son système Brio Query Enterprise, Business Objects avec le produit du même nom et Cognos avec PowerPlay.

Le nombre de produits OLAP compatibles avec le Web est actuellement en augmentation.

Une question importante est l'adaptation d'OLAP au reste du logiciel. Bien que les fournisseurs OLAP commencent à proposer des moyens d'interagir avec SQL-SGBD et d'autres outils, les utilisateurs et les analystes avertissent que le niveau d'intégration varie et nécessitera probablement une quantité importante de codage, y compris l'écriture de requêtes dans Langage SQL. De plus, pour intégrer OLAP avec le reste Logiciel entreprises il n'y a pas de norme de l'industrie.

La solution à ce problème peut être la suivante. Par exemple, de nombreuses entreprises positionnent les bases de données OLAP comme front-end de leurs entrepôts de données. Avec cette approche, les référentiels alimentent le cœur de l'OLAP multidimensionnel avec des échantillons de données auxquels les utilisateurs peuvent accéder ultérieurement pour exécuter rapidement des requêtes complexes. L'objectif est de créer un environnement de requête qui masque l'emplacement des données à l'utilisateur. Cet environnement exécutera automatiquement des requêtes complexes sur le moteur de traitement multidimensionnel ou recherchera des informations détaillées et requêtes simples sur des serveurs relationnels. Pour les entreprises qui ne peuvent emprunter cette voie, les cabinets de conseil jouent un rôle important dans la mise en place de liens entre les outils OLAP et d'autres logiciels.

Systèmes OLTP, étant un moyen très efficace de réaliser des traitements opérationnels, s'est avéré peu utile pour les tâches de traitement analytique. Ceci est causé par ce qui suit :

1. En utilisant les systèmes OLTP traditionnels, vous pouvez créer un rapport analytique et même une prévision de toute complexité, mais réglementée à l'avance. Toute étape de côté, toute exigence non réglementée de l'utilisateur final nécessite en règle générale une connaissance de la structure des données et une qualification assez élevée du programmeur;

2. De nombreuses fonctionnalités nécessaires aux systèmes opérationnels sont redondantes pour les tâches analytiques et, en même temps, peuvent ne pas refléter le domaine. La plupart des tâches analytiques nécessitent l'utilisation d'outils externes spécialisés pour l'analyse, la prévision et la modélisation. La structure rigide de la base de données ne permet pas d'atteindre des performances acceptables dans le cas de sélections et de tris complexes et nécessite donc beaucoup de temps pour organiser les passerelles.

3. contrairement aux systèmes transactionnels, les systèmes analytiques ne nécessitent pas et, par conséquent, ne prévoient pas de moyens avancés pour assurer l'intégrité des données, leur sauvegarde et leur récupération. Cela simplifie non seulement les outils de mise en œuvre eux-mêmes, mais réduit également les frais généraux internes et, par conséquent, améliore les performances lors de la récupération des données.

La gamme de tâches effectivement résolues par chacun des systèmes sera déterminée sur la base des caractéristiques comparatives des systèmes OLTP et OLAP (tableau 8).