Denodo Logo
community
  • Q&A
    • All Questions
    • Ask a Question
    • Search by tag
  • KB
    • Overview
    • Best Practices
    • Combining Data
    • Common Errors
    • Custom Elements
    • Data Sources
    • ITPilot
    • Installation & Updates
    • Northbound Connections
    • Operation
    • Performance & Optimization
    • Publishing
    • Scheduler
    • Security
    • VQL
  • USER MANUALS
    • Denodo Platform 8.0
    • Denodo Platform 7.0
    • Denodo Platform 6.0
    • Older Versions
  • VIDEOS
    • Featured
    • Data Combination
    • Data Services
    • Operation and Source Connectivity
    • Updates
    • Cloud
    • Solution Manager
  • TUTORIALS
    • Overview
    • Data Virtualization Basics
    • Data Services
    • Big Data
    • Agile BI
    • Web Automation
    • Workload Management
    • Data Discovery
    • Custom Components
  • EXPRESS
  • DRIVERS
    • Overview
    • JDBC
    • ODBC
  • FREE TRIAL
REGISTER
SIGN IN
    Denodo Logo
    community
    Denodo Platform 8.0
    Language
    • English
    • Japanese
  • Denodo Platform インストールガイド
    • 法律に関する注意事項
    • 序文
      • 適用範囲
      • 本書の対象読者
      • 概要
    • はじめに
    • インストール前のタスク
      • ハードウェア要件
        • Denodo Platform のディスク領域の要件
        • Amazon AWS で Denodo Platform を実行する場合の推奨事項
        • Microsoft Azure で Denodo Platform を実行する場合の推奨事項
        • Docker での Denodo Platform の実行
        • Virtual DataPort Administration Tool の要件
      • ソフトウェア要件
        • サポートされるオペレーティングシステム
        • サポートされるブラウザー
        • ITPilot のソフトウェア要件
      • Denodo Platform 用のサーバーの構成
        • Denodo Platform をインストールするユーザーアカウントを選択する
        • 選択したユーザーアカウントに権限を付与する
        • PATH 環境変数を確認する (Windows)
        • 必要なポートが空いていることを確認する
        • すべてのブラウザーを閉じる
      • インストーラーのダウンロード
    • グラフィックインストールウィザードの使用
      • 一般的な設定
      • Virtual DataPort のコンポーネントと構成
      • ITPilot のコンポーネントと構成
        • Browser Pool の初期構成
        • ITPilot Wrapper Server
        • ITPilot Verification Server
      • Scheduler のインストール設定
        • Scheduler Server
        • Scheduler Index Server
      • 組み込み Web コンテナー
    • コマンドラインインストーラーの使用
    • Denodo Platform の自動インストール
      • Denodo Platform インストーラーを変更して最新の更新プログラムを含める
    • インストール後のタスク
      • 最新の更新プログラムのインストール
      • Virtual DataPort のホスト名の設定
      • License Manager での Denodo サーバーの登録
      • Denodo Platform での SSL/TLS の有効化
        • SSL/TLS 証明書の取得とインストール
        • Denodo SSL/TLS 構成スクリプト
        • Denodo Platform サーバーでの SSL/TLS の有効化
        • 組み込み Apache Tomcat での HTTPS の有効化
        • 管理ツールなどでの SSL/TLS の有効化
        • 外部クライアントに対する SSL/TLS の有効化
        • Denodo Platform サーバーでサポートされる SSL/TLS のバージョン
      • Windows サービスの構成
      • インストール後のタスク : Virtual DataPort
        • 既定のパスワードの変更
        • Kerberos 認証の設定
        • Data Catalog での Kerberos 認証の設定
        • Oracle Essbase 用コネクターのインストール
        • SAP Java Connector のインストール
        • JMS コネクターをインストールしての、SOAP Over JMS を使用する JMS リスナーと Web サービスの作成
        • VCS クライアントの構成
        • データソースの証明書のインポート (SSL/TLS 接続)
        • データソースへの接続の準備
      • インストール後のタスク : Scheduler
        • 既定のパスワードの変更
        • Scheduler での Kerberos 認証の設定
      • インストール後のタスク : Web コンテナー
        • 監視インターフェイスでの認証の有効化
      • インストール後のタスク : ITPilot
        • Generation Environment がインストールされていることの確認
        • Microsoft Internet Explorer の構成
        • Microsoft Windows Server 2008 の Internet Explorer での [Sequence Generator] ツールバーの有効化
        • Microsoft Windows Server 2008 の [Internet Explorer セキュリティ強化の構成] の無効化
        • Microsoft Windows Server 2012 の [Internet Explorer セキュリティ強化の構成] の無効化
        • Adobe Acrobat Professional の手動構成
        • 自動検証データベース
        • 高 DPI ディスプレイでの Wrapper Generator Tool の起動
      • 以前のバージョンからのアップグレード
    • 更新プログラムおよび修正プログラムのインストール
      • グラフィカルツールを使用した、更新プログラムまたは修正プログラムのインストール
      • コマンドラインからの更新プログラムまたは修正プログラムのインストール
    • Denodo Platform Control Center
      • Denodo Platform Control Center の起動
      • Platform のサーバーとツールの起動
      • Denodo Platform の構成
        • License Manager への接続の構成
      • コマンドラインからの JVM パラメーターの構成
      • Control Center のヘルプ
      • Denodo Platform のアンインストール
    • 付録
      • Denodo Platform のモジュールで使用される既定のポート
      • Denodo Express の制限事項
      • Kerberos レルムに属することなく Virtual DataPort において Kerberos 認証を利用する
      • Kerberos レルムに属することなく Data Catalog において Kerberos 認証を利用する
      • Kerberos レルムに属することなく Design Studio において Kerberos 認証を利用する
      • Kerberos レルムに属することなく Scheduler において Kerberos 認証を利用する
      • Web アプリケーションで Kerberos をデバッグする方法
        • Virtual DataPort Server と Web 管理ツールが同じインストール環境内にある場合
        • Virtual DataPort Server と Web 管理ツールが同じインストール環境内にない場合
      • Kerberos 認証用の krb5 ファイルの提供
      • Denodo Security Token の構成ファイル
        • 一般的な設定
        • 認証モジュール
      • 高 DPI ディスプレイでの Denodo スタンドアロンアプリケーションの起動
      • Denodo Platform インストーラーのトラブルシューティング
      • メタデータの透過的暗号化
      • サポートされている Java Runtime Environment (JRE)
      • 同時要求の最大数の増加
  • Denodo Platform Upgrade Guide
    • Preface
    • Introduction to Upgrading the Denodo Platform
      • Major Steps in the Upgrade Process
      • Running Both Versions in the Same Computer
      • Upgrading from Denodo Platform 6.0 or Earlier
        • Upgrading from Denodo Platform 6.0
        • Upgrading from Denodo Platform 5.5
        • Upgrading from Denodo Platform 5.0 or Earlier
    • Preparing to Upgrade
      • Common to All Modules
        • Kerberos
      • Virtual DataPort
        • Virtual DataPort: Select a Catalog/Schema for the Cache Engine
        • Virtual DataPort: Create a Repository for Version Control
      • Data Catalog: Create a Catalog/Schema on the External Database
      • Scheduler: Create a Catalog/Schema on the External Database
      • Solution Manager
        • Solution Manager: Create a Git Repository or Branch for Version Control
        • Solution Manager: Create a Catalog/Schema on the External Database
    • Pre-Upgrade Tasks for the New Installation
      • Common to All Modules
        • Enable SSL
        • Configure Windows Services
      • Virtual DataPort
        • Virtual DataPort: Metadata
        • Virtual DataPort: JDBC Data Sources that Use the Bulk Data Load API
        • Virtual DataPort: Enable the Cache Engine
        • Virtual DataPort: Install Third-Party Connectors
        • Virtual DataPort: Other Third-Party Jar Files
        • Virtual DataPort: Version Control System
      • Data Catalog: Enable the External Database
      • Scheduler: Enable the External Database
      • Solution Manager
        • Solution Manager: Enable the External Database
        • Solution Manager: High Availability
        • Solution Manager: Enable Git Support
    • Export the Settings and Metadata of the Current Installation
      • Configuration Properties of Virtual DataPort for Upgrades: "exportMigrationCompatibility" and "exportOnlyResources"
    • Review the Virtual DataPort Metadata
    • Import Settings and Metadata in to the New Installation
      • Common Errors when Importing the Metadata of Virtual DataPort 7.0 to 8.0
    • Post-Upgrade Tasks for the New Installation
      • Virtual DataPort
      • Virtual DataPort Administration Tool
      • Data Catalog
        • Data Catalog: Update the URL of Virtual DataPort
        • Data Catalog: Update the URL to the Index Server
        • Data Catalog: Synchronize Metadata
        • Data Catalog: Configure the Gathering of Statistics
      • Scheduler
      • Scheduler Index
        • Scheduler Index: Copy the Index Files
        • Scheduler Index: Configure the Indexes
      • Solution Manager
        • Solution Manager: Active Monitors
        • Solution Manager: Kerberos Configuration
    • Test the New Denodo Platform Installation
    • Backward Compatibility
      • Changes in Denodo Platform 8.0 GA
        • Changes Common to All the Modules of Denodo 8.0 GA
        • Changes in Virtual DataPort 8.0 GA
        • Changes in Solution Manager 8.0 GA
        • Features Removed from Aracne 8.0 GA
        • Features Removed from Virtual DataPort 8.0 GA
        • Features Removed from Scheduler 8.0 GA
        • Features Removed from Solution Manager 8.0 GA
      • Changes in Denodo Platform 7.0
        • Changes Common to All the Modules of Denodo 7.0
        • Changes in Virtual DataPort 7.0
        • Changes in the Privileges System in Virtual DataPort 7.0
        • Features Removed from Virtual DataPort 7.0
        • Changes Introduced in Aracne 7.0
      • Changes in Denodo Platform 6.0
        • Changes Common to All the Modules of Denodo 6.0
        • Changes in Virtual DataPort 6.0
        • Changes in Scheduler 6.0
        • Changes in the Embedded Web Container of Denodo 6.0
      • Changes in Denodo Platform 5.5
        • Changes in Virtual DataPort 5.5
        • Features Removed in Denodo 5.5
      • Changes in Denodo Platform 5.0
        • Changes in Virtual DataPort 5.0
    • Features Deprecated for Denodo Platform 8.0
      • Virtual DataPort
        • Data Type "Date"
        • VQL Syntax
        • Data Sources
        • Denodo Stored Procedures
        • Role JMXAdmin
        • Denodo Stored Procedures API: getNumOfAffectedRows Method
        • Denodo Custom Wrappers API: Deprecated Methods
        • Denodo JDBC Driver
        • Denodo Web Services
        • Widgets
        • Script Export: Deprecated Parameters
        • Launching Several Virtual DataPort Instances of the Same Installation
      • Data Catalog
        • Roles "selfserviceadmin", "selfserviceexporter"
      • ITPilot
      • Scheduler
        • Filter Sequences
        • Jobs
        • File-Repository Exporter
        • Move-File-Repository Handler
      • Solution Manager
        • REST API: Authentication Using Session
      • Denodo4Eclipse Plugin
  • Denodo Platform 新機能ガイド
    • 序文
      • 対象者
    • Solution Manager 8.0 の新機能
      • 自動構成
      • シングルアクセスポイント
      • 認証と承認
        • 新しい認証プロトコルとシングルサインオン
        • 権限システムの拡張
        • 役割と権限の管理のためのユーザーインターフェイスの統合
      • Solution Manager の Diagnostic & Monitoring Tool
        • Diagnostic & Monitoring Tool によるサーバーリストの自動作成
        • Diagnostic & Monitoring Tool の自動起動
    • Virtual DataPort 8.0 の新機能
      • Design Studio
      • 全般
        • 外部データベースへのカタログの保存
        • ドライバーおよびその他のライブラリをアップロードするときのグラフィックサポート
        • 接続時の単一ポートの利用
        • 構成プロパティの管理
        • 要素の名前変更
      • 実行エンジン
        • スマートクエリアクセラレーション :「Summary ビュー」
      • データソース
        • データの一括読み込みにおける Hadoop ディストリビューションの不要化
      • 認証とセキュリティ
        • グローバル LDAP 認証
        • 再起動せずに OAuth 2.0、SAML 2.0、および Kerberos の設定に変更を適用
      • Denodo のストアドプロシージャ
        • Create Remote Table プロシージャがさらに詳しい情報を提供
      • Administration Tool
        • OData および GraphQL サービスへのアクセスが容易に
        • 実装ビューの削除時にインターフェイスビューに関する警告を表示
        • サーバー URI ではデータベースは任意
      • ノースバウンド接続
        • 新しい Denodo GraphQL サービス
        • RESTful Web サービスで Kerberos 認証をサポート
    • Scheduler 8.0 の新機能
      • ユーザーインターフェイス
    • 8.0 のすべてのモジュールに共通の新機能
      • Java Runtime Environment
      • Denodo SSL/TLS Configurator Script
      • 新しくサポートされるオペレーティングシステム
      • すべてのコンポーネントが Windows サービスとしてインストール
      • Denodo の Web コンテナー
        • 新しいバージョンの Web コンテナー : Apache Tomcat 9.0
        • TLS 1.2 および 1.3 のみを利用可
  • Virtual DataPort Administration Guide
    • Preface
      • Scope
      • Who Should Use This Document
      • Summary of Contents
    • Introduction
    • General Architecture
      • Physical Layer
      • Logical Layer
        • Data Module: Cache
      • User Layer
    • Starting Virtual DataPort
      • Starting the Virtual DataPort Server
      • Launching the Administration Tool
        • Main Areas of the Administration Tool
        • Tool Preferences
        • Using the VQL Shell
        • Query Monitor
        • Catalog Search
        • Invalidate Cache
        • Trace Viewer
      • Starting the Design Studio
        • Main Areas of the Design Studio
        • Design Studio Preferences
        • Using the VQL Shell
        • Query Monitor
        • Catalog Search
        • Invalidate Cache
        • Trace Viewer
    • Creating Data Sources and Base Views
      • JDBC Sources
        • Importing JDBC Sources
        • Database Specific Information
        • Connecting to a JDBC Source with Kerberos Authentication
        • Creating Base Views from a JDBC Data Source
        • Importing Graphically Stored Procedures from a Database
        • Creating Base Views from SQL Queries
      • ODBC Sources
        • Creating Base Views from an ODBC Data Source
        • Enabling the Support for ODBC Sources When the Virtual DataPort Server Runs on Linux
        • Enabling the Support for ODBC Sources When Using an External JRE
      • SOAP Web Service Sources
        • Importing SOAP Web Service Sources
        • Creating Base Views from a SOAP Web Service
      • Multidimensional Database Sources
        • Creating a Base View Over a Multidimensional Data Source, Graphically
        • Creating a Base View Over a Multidimensional Data Source with an MDX Query
        • Multidimensional Data Sources to Oracle Essbase
      • Path Types in Virtual DataPort
        • Local Path
        • Path From Variable
        • HTTP Path
        • Denodo Browser Path
        • FTP / SFTP / FTPS Path
        • Compressed or Encrypted Data Sources
        • Custom Input Filters
        • Paths and Other Values with Interpolation Variables
      • XML Sources
      • JSON Sources
      • Delimited File Sources
        • Examples of How to Define a Tuple Pattern
        • Paths Using Date Ranges
      • Excel Sources
      • Web Sources (WWW)
      • LDAP Sources
      • BAPI Sources
      • Salesforce Sources
        • Registering Denodo as a Connected Application
        • Creating a Salesforce Data Source
        • Creating Base Views from a Salesforce Data Source
        • Creating Base Views from SOQL Queries
        • Binary Fields
        • Limitations of Salesforce
        • Additional Settings
      • Custom Sources
        • Using Interpolation Variables as Custom Sources’ Input Parameters
      • Viewing the Schema of a Base View
        • View the VQL of an Element
        • Used By...
        • Source Type Properties
      • Data Source Configuration Properties
        • ORDER BY Properties of the Source Configuration
      • Source Refresh
      • Working with Blob Fields of Base Views
    • Creating Derived Views
      • Creating Union Views
        • Creating Standard Union Views
        • Creating Partitioned Union Views
      • Creating Join Views
        • Join Conditions with Similarity Operators
      • Creating Selection Views
        • Creating Conditions with the Compound Values Editor
        • Parameters of Derived Views
      • Creating Flatten Views
      • Creating Intersection Views
      • Creating Minus Views
      • Creating Interface Views
      • Viewing the Schema of a Derived View
      • Tree View
      • Data Lineage
      • Advanced Configuration of Views
        • Configuring the Cache of a View
        • Search Methods, Configuration Properties and Internationalization
        • Indexes of Views
        • Statistics of the View
        • Defining the Data Movements of the View
      • Materialized Tables
      • Temporary Tables
      • Querying Views
        • Execution Trace of a Statement
      • Editing / Replacing a View
        • Views Affected by Modifications
    • Stored Procedures
      • Importing Stored Procedures
      • Executing Stored Procedures
      • Use of Stored Procedures in Creating Views
    • Publication of Web Services
      • Publishing SOAP Web Services
        • Operations Tab
        • Settings Tab (SOAP)
        • Advanced Tab (SOAP)
      • Publishing REST Web Services
        • Resources Tab
        • Settings Tab (REST)
        • Advanced Tab (REST)
      • XSLT Transformations
      • Web Services Authentication
        • HTTP Basic
        • HTTP Basic with VDP
        • HTTP Digest
        • HTTP SPNEGO (Kerberos)
        • OAuth 2.0 and OpenID
        • SAML 2.0
        • Impersonating a User
      • How Web Services Query the Virtual DataPort Server
        • Connection from the Web Services to the Server
      • Web Service Container Status Table
      • Invoking Denodo Web Services
        • Invoking Web Services with SAML Authentication
        • Types Conversion Table for REST / SOAP Published Web Services
    • RESTful Architecture
      • Primary Keys of Views
      • Associations
        • Creating an Association
        • Multiplicity of Associations
        • Referential Integrity in Associations
        • Role Preconditions
        • Why You Should Define Associations Between Views
      • RESTful Web Service
        • Representations
        • Input Parameters of the RESTful Web Service
        • IDU Requests
        • Requests with Input Compound Values
        • Status Codes
        • Obtaining the Number of Rows of a Result Set
        • Security and Access Privileges
        • Configuring the RESTful Web Service
      • Denodo OData 4.0 Service
        • Serving Metadata
        • Querying Data: The Basics
        • Navigating Associations
        • Advanced Querying
        • Pagination
        • Configuration
        • Debug Option
        • Privilege Requirements
        • Limitations
        • Features
      • Denodo GraphQL Service
        • Configuration
        • Privilege Requirements
        • Schema
        • Introspection
        • Basic Querying
        • GraphQL Names
        • Advanced Querying
        • Authentication
        • Resource Limitations
        • Limitations
        • Features
    • JMS Listeners
      • Creating a New JMS Listener
      • Who Can Create JMS Listeners
      • Advanced JMS Configuration
        • Acknowledge Mode
        • Acknowledge On Query Finish and Serialized Processing
      • Enabling Advanced Logging for JMS Listeners
    • Remote Tables
      • Managing Remote Tables
        • Creating Remote Tables
        • Editing Remote Tables
        • Refresh Data
        • Dropping Remote Tables
      • Remote Tables vs Other Mechanisms for Persisting Data
    • Server Configuration
      • Configuring the Cache
      • Limiting the Number of Concurrent Requests
      • Configuring the Default Internationalization
      • Default Configuration of HTTP Proxy
      • Identifiers Charset
        • Restricted Mode
        • Unicode Mode
      • Configuring the Memory Usage and Swapping Policy
        • Memory Usage Settings
        • Swapping Settings
        • Maximum Size of a Query
      • Privileges
        • The FILE Privilege
      • Queries Optimization
      • Server Authentication
        • LDAP Authentication
        • Kerberos Authentication
        • SAML Authentication
        • OAuth Authentication
        • Denodo Security Token Authentication
      • Server Connectivity
      • Configuring Runtime Parameters for Stored Procedures
      • Threads Pool
      • Storing the Metadata on an External Database
        • Replication Process
        • How to Configure Virtual DataPort to Store an External Database
        • Some Considerations About This Feature
        • Databases Supported
    • Memory Management
      • Streaming Vs Non-Streaming Operators
      • Swapping Parameters
      • Limit the Maximum Amount of Memory of a Query
      • Edge Cases in Streaming Operation
      • Cache Load Processes
    • Resource Manager
      • Defining a Plan
      • Defining a Rule
    • Exporting and Importing the Server Metadata
      • Exporting the Server Metadata
      • Exporting and Importing Elements Across Different Environments
        • Exporting Environment-Dependent and Independent Elements to Different Files
        • Export to a File with Properties
      • Importing Metadata into a Server
    • Importing Extensions
      • Importing a JDBC Driver
      • Importing Other Types of Elements
    • Cache Module
      • Cache Modes
        • Partial Mode
        • Full Mode
        • Incremental Mode
        • Recommended Parameters for Queries that Load the Cache
        • Caching Very Large Data Sets
        • Caching the Result of Queries that Fail
      • Cache Maintenance Task
        • Maintaining the Underlying Database
      • Specific Information about Cache Databases
        • Amazon Athena
        • Azure SQL Data Warehouse
        • Presto
        • Spark
        • Yellowbrick
        • Databases with HDFS Storage
      • Generic Support for Other Databases
    • Version Control Systems Integration
      • VCS Configuration
        • Virtual DataPort Server Configuration
        • Environment Management
        • Database Configuration
        • Importing an Existing Database from a VCS Server
      • VCS Integration Features
        • Supported Element Types
        • Integration with the Server Explorer
        • VCS Operations for Microsoft TFS and Subversion
        • VCS Operations for GIT
        • Delete Operations
        • Other Version Control Operations
        • Dependencies Management
        • VCS Settings of the Administration Tool
      • Scenarios and Recommended Uses
        • Picking a VCS Workflow
        • Centralized Workflow with Shared Databases
        • Distributed Workflow
        • Centralized Workflow with Private Databases
        • Best Practices to Manage Global Elements
        • Promoting Changes from Development to Testing and Production
        • Using VCS Environments
      • Best Practices When Using the Integration with a VCS
        • Tagging and Branching Releases
        • Recommendations for the Testing Environment
      • Uniqueness Detection
        • Enabling Uniqueness Detection
        • Examples
      • LS Optimization for Subversion
        • Activating the LS Optimization
        • Tested Environments
    • Databases, Users and Access Rights in Virtual DataPort
      • Databases in Virtual DataPort
      • User and Access Right in Virtual DataPort
        • Types of Access Rights
        • Column Privileges
        • Row Restrictions
        • Roles
      • Administration of Databases, Users, Roles and Their Access Rights
        • Creating Databases
        • Configuring and Deleting Databases
        • Creating Users
        • Modifying and Deleting Users
        • Creating Roles
    • Monitoring the Virtual DataPort Server
      • Monitoring with a Java Management Extensions (JMX) Agent
        • Using JavaTM VisualVM
        • General Information on the Server
        • Information on Data Sources
        • Information on the Cache
        • Information and Events on Catalog Access (DDL Statements)
        • Information and Events on the Running of Statements
        • Information and Events on Transactions
        • Setting the User Agent of an Application
      • Denodo Monitor
        • Local Monitors
        • Server Monitors
        • Virtual DataPort Monitors
        • Configuring the Denodo Monitor
        • Launching the Denodo Monitor
    • Cluster Architectures / Server Backup
      • Denodo Tools
      • How to Check If a Virtual DataPort Server Is Alive
        • Using the Ping Script
        • Alternatives to the Ping Script
      • Using the Import/Export Scripts for Backup And/or Replication
        • Export Script
        • Import Script
    • Bulk Data Load
      • Amazon Athena
      • Amazon Redshift
      • DB2
      • Databricks
        • Mounting External File Systems on DBFS
      • Hive
      • Impala
        • Built-in Implementation
        • External Hadoop Installation
      • MySQL
      • Oracle
      • PostgreSQL
      • Presto
      • Snowflake
      • Spark
      • Microsoft SQL Server
      • Teradata
      • Yellowbrick
      • Settings of the Generation of the Temporary Files
        • Databases with HDFS Storage
    • Optimizing Queries
      • Optimizing DF Data Sources
      • Optimizing Join Operations
        • Merge Join
        • Nested Join
        • Nested Parallel Join
        • Hash Join
      • Automatic Simplification of Queries
        • Removing Redundant Branches of Queries (Partitioned Unions)
        • Pushing Down GROUP BY Views Below JOIN Views
        • Pushing Down GROUP BY Views Below UNION Views
        • Selecting the Most Optimal Source When the Data Is Replicated in Several Sources
      • Cost-Based Optimization
        • Enabling the Cost-Based Optimization
        • Gathering the Statistics of Views
        • Tuning the Cost-Based Optimization Process
        • Current Limitations of the Cost-Based Optimization Process
      • Data Movement
        • Data Movements From/To Netezza Databases
        • Examples of Data Movement
        • Known Limitations
        • Options of the CONTEXT Clause that Control a Data Movement
      • Parallel Processing
        • Use of an MPP Engine as Cache
        • Force Movement of Views to the MPP Engine Using the CONTEXT Clause
      • Smart Query Acceleration Using Summaries
        • Managing Summaries
        • Summary Rewrite Optimization
    • Appendix
      • Supported JDBC Data Sources
      • Backward Compatibility Between the Virtual DataPort Server and Its Clients
      • Mapping Multidimensional Data to a Relational Model
        • Creating a Multidimensional Base Views Over a Multidimensional Data Source
        • Mapping the Result of MDX Queries
      • Considerations When Configuring Data Sources with Pass-Through Credentials
        • Web Services
      • Configuring the Logging System
      • Configuring the Network Interface Restriction in Virtual DataPort
      • Installing the Denodo Solution for Microsoft SharePoint
      • Transforming Incoming/Outgoing Soap/Rest Messages with XSLT Stylesheets
      • JMS Connection Details: JNDI Properties
        • Apache ActiveMQ 5.6.0
        • IBM WebSphere MQ 7.0
        • Progress SonicMQ 8.0
      • Execution Trace Information
      • Useful Tools to Debug Issues with Active Directory or Other LDAP Servers
      • Single User Mode
        • Explicit Single User Mode
        • Automatic Single User Mode
      • Resource Manager: Available Fields to Evaluate a Rule
        • Examples of Resource Manager Rules
      • Values of the Attribute “Access Interface”
      • Avoiding SQL Injections
      • Enable the "Export" Endpoint of the Web Container
      • Publication of Views as Widgets
        • Publish a View as a Widget
        • Auxiliary Web Services
        • Export to JSR-168 or JSR-286 Portlet
        • Export as Microsoft Web Part
        • Deployment of a Microsoft Web Part
        • Customizing Events and Public Render Parameters of JSR-286 Portlets
      • Launching Several Virtual DataPort Instances of the Same Installation
        • How to Configure the Secondary Instances
        • Deploying Web Services on This Configuration
        • Deploying Web Services on This Configuration
  • Virtual DataPort 開発者ガイド
    • 序文
      • 適用範囲
      • 対象読者
      • 概要
    • はじめに
      • 例
    • JDBC 経由でのアクセス
      • JDBC ドライバーのパラメーター
      • ロードバランサー経由での Virtual DataPort への接続
      • Kerberos 認証を使用した Virtual DataPort への接続
        • クライアントアプリケーションがドメインに属していない場合
      • JDBC インターフェイスの詳細
        • ビューとそのフィールドの説明
        • blob 値のコンテンツタイプの取得
        • Denodo JDBC ドライバーを使用した日時値の操作
        • Struct (レジスター) 内部のエレメント名の取得
        • 受信シリアライズデータをフィルターするアプリケーションからの接続
    • ODBC 経由でのアクセス
      • Windows での ODBC ドライバーの構成
        • Windows への ODBC ドライバーのインストール
        • Windows での DSN のセットアップ
      • Linux とその他の UNIX での ODBC ドライバーの構成
        • 適切な ODBC ドライバーの取得
        • unixODBC のインストール
        • unixODBC への Denodo ODBC ドライバーの登録
        • unixODBC へのデータソース (DSN) の登録
        • UnixODBC のコンパイル
        • 問題のトラブルシューティング
      • DSN レスコネクションの作成
      • ODBC インターフェイスの詳細
        • ODBC インターフェイスが日時型と時間間隔型をレポートする方法
      • サードパーティアプリケーションとの統合
        • 角括弧を使用したクエリのサポート
        • テキスト値の最大長
        • エラーメッセージの最大長
        • トランザクションの無効化
      • ODBC ドライバーの下位互換性
    • ADO.NET データプロバイダー経由でのアクセス
      • Kerberos 認証の使用
    • OLE DB 経由でのアクセス
    • 拡張機能の開発
      • カスタム関数の開発
        • アノテーションを使用したカスタム関数の作成
        • 名前規則を使用したカスタム関数の作成
        • 複合型
        • カスタム関数の戻り値の型
        • クエリのコンテキストに関する情報の取得
        • 日時型および時間間隔型の処理
      • ストアドプロシージャの開発
        • Denodo ストアドプロシージャでの日時値の使用
        • ストアドプロシージャの開発に必要なライブラリ
      • カスタムラッパーの開発
        • カスタムラッパーの開発に必要なライブラリ
        • AbstractCustomWrapper の拡張
        • AbstractCustomWrapper のオーバーライド
        • 条件の処理
        • ORDER BY 句の処理
        • カスタムラッパーの構成
        • カスタムラッパーの計画の更新
        • 日時型および時間間隔型の処理
      • カスタム入力フィルターの開発
        • カスタムフィルターの開発に必要なライブラリ
        • カスタムフィルターの開発
    • カスタムポリシー
      • カスタムポリシーの開発
    • 付録
      • LIST コマンドの出力スキーマ
      • DESC コマンドの出力スキーマ
      • Virtual DataPort によって返されるエラーコード
      • Denodo ODBC ドライバーのコンパイル
        • Linux で ODBC ドライバーをコンパイルするための前提条件
        • ODBC ドライバーのコンパイル (標準の方法)
        • 転送可能チケットを取得するための ODBC ドライバーのコンパイル
        • Denodo ODBC ドライバーのコンパイルのトラブルシューティング
  • Virtual DataPort VQL ガイド
    • 序文
      • 適用範囲
      • 対象読者
      • 概要
    • はじめに
    • Virtual DataPort の概要
      • データの作成と定義
        • 基本ビューの定義
        • データソースとラッパーの定義
        • グローバルスキーマのビューの定義
      • ステートメントの実行
    • データの定義と処理を行うための言語: VQL
      • データ型
        • 日付、タイムスタンプ、間隔のデータ型
        • ロケール
      • ステートメント
      • Unicode 識別子
      • 論理演算子
      • 比較演算子
        • リテラルの比較
        • 3 値論理
      • 条件と派生属性の関数
      • 構文規則
        • 関数と条件値の構文
      • コメント
    • ラッパーとデータソースの生成
      • データソースの作成
        • JDBC データソース
        • ODBC データソース
        • 多次元データソース
        • SOAP Web サービス用データソース
        • XML データソース
        • JSON ソース
        • DF データソース
        • LDAP データソース
        • BAPI データソース
        • Salesforce データソース
        • カスタムデータソース
        • データソース構成プロパティ
        • Virtual DataPort におけるパスの指定
      • ラッパーの作成
        • 実行コンテキストと補間文字列
        • ラッパーメタデータ
        • JDBC ラッパー
        • 多次元データベースラッパー
        • ODBC ラッパー
        • WWW ラッパー
        • Web サービスラッパー
        • XML ラッパー
        • JSON ラッパー
        • DF ラッパー
        • LDAP ラッパー
        • BAPI ラッパー
        • Salesforce ラッパー
        • CUSTOM ラッパー
        • ラッパー構成プロパティ
      • ラッパーの型と VDP 型との有効な変換
        • Java 型へのラッパーのネイティブ型変換
        • フィルター
      • QUERY WRAPPER ステートメント
    • 基本ビューの作成
      • クエリ機能: 検索メソッドとラッパー
        • クエリ制約
        • 検索メソッドへのラッパーの割り当て
        • 検索メソッドの作成方法の例
      • 基本ビューの変更
    • クエリ: SELECT ステートメント
      • FROM 句
        • JOIN 操作
        • INTERSECT 操作
        • MINUS 操作
        • FLATTEN ビュー (データ構造のフラット化)
        • クエリの WHERE 句で使用するサブクエリ
      • WITH 句
      • SELECT 句
        • 派生属性
      • WHERE 句
        • 複合値を使用した条件
      • Group BY 句
        • 集計関数の使用
      • HAVING 句
      • UNION 句
        • SQL 標準の Union の有効化
      • ORDER BY 句
      • OFFSET、FETCH、LIMIT
      • CONTEXT 句
      • TRACE 句
      • CASE 句
    • 派生ビューの定義
      • 派生ビューの変更
      • インターフェイスビューの定義
    • ビューの統計情報の定義
    • マテリアライズドテーブル
      • マテリアライズドテーブルの作成
      • マテリアライズドテーブルへのデータの挿入
    • 一時テーブル
      • 一時テーブルの作成
        • 必要な権限
    • リモートテーブル
      • CREATE REMOTE TABLE コマンド
    • サマリ
      • CREATE SUMMARY VIEW コマンド
    • ビューに対する挿入、更新および削除
      • INSERT ステートメント
      • UPDATE ステートメント
      • DELETE ステートメント
      • 変更された行を返す
        • 制限事項
      • WITH CHECK OPTION の使用
    • ビューの更新
      • REFRESH ステートメント
    • Virtual DataPort のトランザクション
    • ストアドプロシージャ
      • ストアドプロシージャのインポート
      • ストアドプロシージャの使用方法
      • 事前定義のストアドプロシージャ
        • CACHE_CONTENT
        • CATALOG_ELEMENTS
        • CATALOG_FKS
        • CATALOG_METADATA_VIEWS
        • CATALOG_PERMISSIONS
        • CATALOG_PKS
        • CATALOG_VDP_METADATA_VIEWS
        • CATALOG_VIEWS
        • CLEAN_CACHE_DATABASE
        • COLUMN_DEPENDENCIES
        • COMPACT_HADOOP_CACHE
        • COMPACT_METADATA_TABLES
        • CREATE_REMOTE_TABLE
        • DROP_REMOTE_TABLE
        • DUAL
        • GENERATE_SMART_STATS_FOR_FIELDS
        • GENERATE_SMART_STATS_FOR_FIELDS_BY_TABLENAME
        • GENERATE_STATS
        • GENERATE_STATS_FOR_FIELDS
        • GENERATE_VQL_TO_CREATE_JDBC_BASE_VIEW
        • GET_ACTIVE_LOGGERS
        • GET_ASSOCIATIONS
        • GET_CACHE_COLUMNS
        • GET_CACHE_CONFIGURATION
        • GET_CACHE_TABLE
        • GET_CATALOG_EFFECTIVE_PERMISSIONS
        • GET_CATALOG_METADATA_WS
        • GET_DELEGATED_SQLSENTENCE
        • GET_ELEMENTS
        • GET_EXPORTED_KEYS
        • GET_FOREIGN_KEYS
        • GET_JDBC_DATASOURCE_TABLES
        • GET_PARAMETER
        • GET_PRIMARY_KEYS
        • GET_PROCEDURE_COLUMNS
        • GET_SERVER_CONNECTIVITY
        • GET_SESSIONS
        • GET_SOURCE_CHANGES
        • GET_SOURCE_COLUMNS
        • GET_SOURCE_TABLE
        • GET_TYPE_ATTRIBUTES
        • GET_USER_DEFINED_TYPES
        • GET_VIEW_COLUMNS
        • GET_VIEW_INDEXES
        • GET_VIEW_STATISTICS
        • GET_VIEWS
        • LIST_JDBC_DATASOURCE_TABLES
        • LOGCONTROLLER
        • MIGRATE_DATE_TYPES
        • PING_DATA_SOURCE
        • SOURCE_CHANGES
        • VIEW_DEPENDENCIES
        • WAIT
        • WEBCONTAINER_ELEMENTS
        • WEBCONTAINER_ELEMENT_STATUS
        • WRITELOGERROR
        • WRITELOGINFO
    • カタログの他のエレメントの定義
      • フォルダーの作成
      • データ型の定義
      • マップの定義
      • JAR 拡張機能の定義
      • JMS リスナーの定義
    • データベース、ユーザー、ロール、およびアクセス権限の作成
      • Virtual DataPort データベースの作成と変更
      • ユーザーの管理
        • ユーザーの変更と削除
        • 他のデータベースへの接続
        • ユーザーの権限の変更
        • ユーザーのロールの管理
      • エレメントの所有権
    • カタログエレメントの記述
      • メタデータのエクスポート
      • メタデータのインポート
    • カタログ内のエレメントのリスト表示
    • カタログからのエレメントの削除
    • Web サービスの公開
      • SOAP Web サービスの作成
      • SOAP Web サービスの変更
      • REST Web サービスの作成
      • REST Web サービスの変更
      • コネクションパラメーター
      • Web サービスの認証
        • Basic および Digest
        • OAuth 2.0 および OpenID
        • SAML 2.0
        • VDP
        • WSS
      • 組み込み Web コンテナーの管理
      • SOAP および REST Web サービスのデプロイおよびエクスポート
    • RESTful アーキテクチャ
      • アソシエーション
      • ナビゲーションクエリ
    • ヘルプコマンド
    • バージョン管理システム統合コマンド
      • 集中型バージョン管理システムを操作するステートメント
        • VCSCOMMIT
        • VCSUPDATE
        • VCSCONTENTS
        • VCSSHOW
        • REVISIONS
      • GIT を操作するステートメント
        • DVCSCOMMIT
        • DVCSPUSH
        • DVCSPULL
        • DVCSREVERT
      • 環境管理用コマンド
      • その他のバージョン管理コマンド
        • VCSDISCARD
    • Resource Manager
      • Resource Manager のプランの管理
      • Resource Manager のルールの管理
    • 高度な機能
      • 複合値の管理
        • 複合型の処理: 例
      • Virtual DataPort および Web コンテナーの設定の変更
      • キャッシュの使用
        • キャッシュの無効化
        • キャッシュのコンテンツの表示
      • スワップポリシーの構成
      • ロケール構成の管理
        • ロケールマップの置き換え
        • ロケールマップの削除
      • クエリの実行コンテキストと補間文字列
      • 選択条件への変数の追加 (GETVAR および SETVAR)
    • 付録
      • 条件関数の構文
        • 算術関数
        • テキスト処理関数
        • 日時処理関数
        • XML 処理関数
        • 型変換関数
        • 集約関数
        • 分析関数 (ウィンドウ関数)
        • その他の関数
      • CASE 句の例
      • 日付と時間のパターン文字列
      • ウィジェットの公開
        • 新しいウィジェットの作成
        • ウィジェットのエクスポート
        • 補助 Web サービスのデプロイとエクスポート
  • Data Catalog ガイド
    • 序文
      • 適用範囲
      • 対象読者
      • 概要
    • はじめに
    • インストールおよび実行
      • Data Catalog の起動
    • 認可と承認
    • 管理
      • サーバー構成
        • Virtual DataPort サーバーの構成
        • Virtual DataPort サーバーへの接続設定の構成
        • Data Catalog での外部データベースの使用
      • コンテンツ検索構成
      • Kerberos 構成
      • パーソナライズ
        • ユーザーに表示するエレメント
        • 参照の構成
        • ユーザーインターフェイス
        • エクスポート形式の構成
        • データベースおよびビューの接続 URI
        • 使用状況統計
      • カタログ管理
        • カテゴリの構成
        • タグの構成
        • データベースの構成
        • エレメントの構成
        • プロパティグループの構成
      • Data Catalog のメタデータのインポートとエクスポート
        • UI からの Data Catalog のメタデータのインポートとエクスポート
        • スクリプトを使用した Data Catalog のメタデータのインポートとエクスポート
    • 構成
    • 参照
      • データベース
      • カテゴリ
      • タグ
      • 関係
      • ビュー
        • ビューの概要
        • ビューのクエリ
        • ビューのアソシエーション
        • ビューのリネージ
        • ビューの検索
        • ビューの使用状況
      • Web サービス
        • Web サービスの概要
        • Web サービスのクエリ
    • 保存されたクエリ
      • 保存されたクエリのデプロイ
      • 保存されたクエリのコピー
    • 検索
      • カタログ検索
      • コンテンツ検索
      • クエリ
    • 付録
      • クラスターへの Data Catalog のインストール: すべてのノードでの同一設定の共有
        • 共通データベースの設定
        • 共通データベースを使用するための Data Catalog の構成
      • REST API
        • サーバーとのエレメントの同期
        • 使用状況統計の計算
        • メタデータのエクスポート
        • メタデータのインポート
      • Apache Lucene 検索構文
        • 項
        • フィールド
        • 検索語の修飾子
        • ブール演算子
        • グループ化
        • フィールドへのグループ化
        • 特殊文字のエスケープ
  • Diagnostic & Monitoring Tool ガイド
    • 序文
      • 適用範囲
      • 対象読者
      • 概要
    • はじめに
    • 一般的なアーキテクチャ
    • インストールおよび実行
      • Denodo Platform の Diagnostic & Monitoring Tool の起動
      • Denodo Solution Manager の Diagnostic & Monitoring Tool の起動
    • Diagnostic & Monitoring Tool の概要
    • 認証
    • 認可
    • サーバーと環境の作成
      • サーバーの作成
      • 環境の作成
    • 監視
      • サーバーの監視
        • 監視 - リソース
        • 監視 - 状態
        • 監視 - セッション
        • 監視 - リクエスト
        • 監視 - キャッシュ
        • 監視 - データソース
        • 監視 - スレッド
      • 環境の監視
      • 概要
    • 問題の診断情報と診断間隔の定義
      • 診断情報の定義
      • 診断間隔の定義
    • 診断
      • 診断 - リソース
      • 診断 - 状態
      • 診断 - セッション
      • 診断 - リクエスト
      • 診断 - キャッシュ
      • 診断 - データソース
      • 診断 - スレッド
      • 診断 - エラー
    • エクスポートとインポート
      • エクスポート
      • インポート
    • 構成
      • ユーザー構成
        • 構成 - 全般
        • 構成 - 概要
        • 構成 - リソース
        • 構成 - 状態
        • 構成 - セッション
        • 構成 - リクエスト
        • 構成 - キャッシュ
        • 構成 - データソース
        • 構成 - スレッド
        • 構成 - エラー
      • サーバー構成
        • 通知メッセージ
  • Virtual DataPort API Javadoc
  • Scheduler Administration Guide
    • Preface
      • Scope
      • Who Should Use This Manual
      • Summary of Contents
    • Introduction
    • General Architecture
    • Installation and Execution
    • Administration
      • Authentication
        • Scheduler Server Local Authentication
        • Web Administration Tool Local Authentication
      • Web Configuration
        • Kerberos Configuration
        • Informative Message Configuration
        • Change Password
      • Scheduler Server Configuration
        • Server Set-up
        • Management
        • Import/Export Backups
        • Index Server
      • Log Configuration
    • Creating and Scheduling Jobs
      • Jobs
      • Data Sources
        • Scheduler Index Data Sources
        • CSV Data Sources
        • Elasticsearch Sources
        • JDBC Data Sources
        • VDP Data Sources
      • Configuring New Jobs
        • General Structure of a Job
        • VDP Extraction Section
        • VDPCache Extraction Section
        • VDPIndexer Extraction Section
        • Exporters Section
        • Retry Section
        • Handler Section
        • Time-based Job Scheduling Section
        • Dependencies Among Jobs
    • Developer API
      • Scheduler RMI Client API
      • Scheduler REST Client API
      • Extensions (Plugins)
        • Exporters
        • Handlers
    • Appendix
      • JDBC Drivers
      • Use of the Import/Export Scripts for Backup
        • Export
        • Import
      • Use of the Ping Script
      • Use of the ChangePassword Script
      • Scheduler index
        • Use of the ChangePassword Script
  • Scheduler API Javadoc
  • Solution Manager インストールガイド
    • 序文
      • 対象読者
    • インストール前のタスク
      • ハードウェア要件
        • Amazon AWS で Solution Manager を実行する場合の推奨事項
      • ソフトウェア要件
        • サポートされるオペレーティングシステム
        • サポートされるブラウザー
      • インストール前のその他のタスク
        • Solution Manager をインストールするユーザーアカウントを選択する
        • 必要なポートが空いていることを確認する
        • 選択したユーザーアカウントに権限を付与する
        • Windows の PATH 環境変数を確認する
      • インストーラーのダウンロード
    • グラフィックインストールウィザードの使用
      • 一般的な設定
      • Virtual DataPort のコンポーネントと構成
      • Solution Manager のコンポーネントと構成
      • 組み込み Web コンテナー
    • コマンドラインインストーラーの使用
    • Solution Manager の自動インストール
      • Solution Manager インストーラーを変更して最新の更新プログラムを含める
      • Solution Manager の自動インストール
    • インストール後のタスク
      • 最新の更新プログラムのインストール
      • ライセンスのインストール
      • デフォルトのパスワードの変更
      • Solution Manager での SSL/TLS の有効化
        • SSL 証明書の取得とインストール
        • Solution Manager サーバーでの SSL/TLS の有効化
      • Windows サービスの構成
      • インストール後のタスク: Web コンテナー
        • 監視インターフェイスでの認証の有効化
      • 高可用性
    • Denodo Platform Control Center
      • Platform のサーバーとツールの起動
      • 更新プログラムおよび修正プログラムのインストール
      • 仮想マシンと Web コンテナーの構成
      • コマンドラインからの JVM パラメーターの構成
      • Control Center のヘルプ
      • Solution Manager のアンインストール
    • 付録
      • Solution Manager のモジュールで使用されるデフォルトのポート
      • Kerberos レルムに属することなく Virtual DataPort において Kerberos 認証を利用する
      • Kerberos レルムに属することなく Solution Manager において Kerberos 認証を利用する
      • Kerberos 認証用の krb5 ファイルの提供
      • 高 DPI ディスプレイでの Denodo スタンドアロンアプリケーションの起動
      • Solution Manager インストーラーのトラブルシューティング
      • Solution Manager におけるメタデータの透過的暗号化
      • Solution Manager におけるネットワークインターフェイスの制限の構成
      • サポートされている Java Runtime Environment (JRE)
  • Solution Manager 管理者ガイド
    • 序文
      • 適用範囲
      • 対象読者
      • 概要
    • はじめに
      • アーキテクチャ
    • Solution Manager の起動
    • Solution Manager Administration Tool の概要
    • ライセンス管理
      • ライセンスのインストール
        • グローバルライセンスの情報の確認
      • ライセンスの割り当て
        • サーバーへのライセンスの割り当て
        • 環境のライセンス情報の確認
      • ライセンスが機能する仕組み
        • サーバーがライセンスを解決する方法
        • ライセンス応答受信時の Denodo サーバーの動作
      • [License Usages] テーブル
    • 構成
      • 外部データベースの設定
      • VCS の構成
      • 通知メッセージの設定
    • 認証と認可
      • ユーザーの管理
      • LDAP を使用した認証
      • シングルサインオンによる認証
        • SAML 構成
        • OAuth 構成
        • OpenID 構成
        • Kerberos 構成
      • 認可
        • グローバル権限
        • 特定の環境に対する役割に付与される権限
      • 役割の管理
        • LDAP サーバーからの役割のインポート
    • Denodo Security Token
      • アーキテクチャ
      • セキュリティ上の考慮事項
      • 外部 ID プロバイダーに関する考慮事項
      • Denodo Platform の構成
        • 管理タスク
        • Denodo Platform での Denodo Security Token の有効化
      • 認証資格情報
      • シングルサインオンの処理順序
    • 環境
      • クラスター
      • 動作モード
    • 標準モード
      • 環境の作成
      • 環境の構成
      • クラスターの作成
      • クラスターの構成
    • 自動クラウドモード (AWS)
      • モードの構成
      • 環境の作成
      • 環境の構成
      • クラスターの作成
        • グローバル構成
        • サーバー構成
      • クラスターの構成
      • クラスターの管理
        • クラスターの概要の表示
        • 最後のアクションの進行状況の表示
        • クラスターの有効化
        • クラスターの無効化
        • すべてのクラスターイベントの表示
        • クラスターの起動
        • クラスターの停止
        • クラスターの再起動
        • クラスターの再作成
        • サーバーからのクラスターの再作成
        • クラスターへの Denodo 更新プログラムのインストール
        • Diagnostic & Monitoring Tool によるクラスターの監視
    • 環境の構成
      • Virtual DataPort のプロパティの構成
      • デプロイの構成
        • 標準モード環境のデプロイの構成
        • クラウド環境のデプロイの構成
        • Data Catalog サーバーの同期
      • デプロイスクリプトの構成
        • デプロイスクリプトの例
      • 環境のログレベルの構成
    • クラスターの構成
      • クラスターの負荷分散変数の構成
      • Scheduler のプロパティの構成
      • クラスターのログレベルの構成
    • サーバー
      • サーバーの作成
      • サーバーの構成
        • サーバーの負荷分散変数の構成
        • サーバーのログレベルの構成
    • 負荷分散変数
      • 負荷分散変数の作成
      • 負荷分散変数への値の割り当て
    • 昇格
      • リビジョンの作成
        • 全般オプション
        • その他のオプション
        • リビジョンのエレメント候補
      • VQL からのリビジョンの読み込み
        • [New Revision from VQL] ダイアログ
      • [Revisions] テーブル
        • リビジョンの作成
        • リビジョンの編集
        • リビジョンの情報の確認
        • リビジョンの削除
        • テーブルでのリビジョンのフィルター
        • リビジョンのメタデータのダウンロード
        • リビジョンの検証
        • リビジョンの検証の概要の確認
        • リビジョンのコピー
        • リビジョンのデプロイ
        • リビジョンがデプロイされた環境の確認
      • 標準モードのデプロイ
        • デプロイの前提条件
        • デプロイのパラダイム
        • キャッシュに関する制限事項
      • クラウドでのデプロイ
        • クラウドでのデプロイのオプション
      • [Deployments] テーブル
        • デプロイのキャンセル
        • テーブルでのデプロイのフィルター
        • デプロイの進行状況の概要の確認
        • デプロイのエラーの確認
        • デプロイのリビジョンの確認
        • デプロイのバックアップデータのダウンロード
      • デプロイの進行状況
    • 監視
      • 監視の構成
      • JDBC ログの構成
    • インポートおよびエクスポート
    • 付録
      • REST API
        • 環境のリストの取得
        • 環境の作成
        • 利用可能なライセンスのリストの取得
        • 環境の更新
        • 環境の削除
        • 環境に関連付けられている Virtual DataPort のプロパティのリストの取得
        • 環境プロパティの作成および削除
        • クラスターのリストの取得
        • クラスターの作成
        • クラスターの取得
        • クラスターの更新
        • クラスターの削除
        • クラスターに関連付けられている Scheduler のプロパティのリストの取得
        • クラスターのプロパティの作成および削除
        • サーバーのリストの取得
        • サーバーの作成
        • サーバーの取得
        • サーバーの更新
        • サーバーの削除
        • リビジョンのリストの取得
        • VQL ファイルからのリビジョンの作成
        • デプロイのリストの取得
        • リビジョンのリストからの新規デプロイの開始
        • デプロイの進行状況の取得
        • ライセンス使用の解放
        • License Manager サーバーへの ping の実行
        • Solution Manager サーバーへの ping の実行
      • ベストプラクティス: 組織全体への更新プログラムのデプロイ
        • 高可用性構成の Solution Manager の更新
      • Solution Manager と Denodo Platform サーバーの互換性
      • Denodo Platform 用のカスタム AMI の作成
  • Denodo Express クイックスタートガイド
  • ユーザマニュアル /
  • Virtual DataPort Administration Guide /
  • Version Control Systems Integration /
  • Scenarios and Recommended Uses

Scenarios and Recommended Uses¶

Denodo proposes three workflows when working with a version control system (VCS) on the development environment:

  1. Centralized workflow with shared databases

    • There is a single Virtual DataPort server and each developer uses its Administration Tool to connect to this Server.

    • For each project, there is one single database. We recommend having one database per project.

    • The developers of each project work with the same database.

  2. Distributed workflow

    • Each developer has a local installation of the Virtual DataPort server and its administration tool. Each local installation is under control of the developer. I.e. the developer is an administrator of that server.

    • Each developer has a database for each project and they check in and out the changes from the central repository of the organization.

    • Although all the developers will be administrators on their own Denodo servers, this workflow still requires the figure of the administrator that coordinates changes in jar extensions and internationalization maps. The purpose is to avoid that changes in jar extensions or i18n maps affect other projects.

      The section Best Practices to Manage Global Elements (below) explains this in more detail.

  3. Centralized workflow with private databases

    • There is a single Virtual DataPort server and each developer uses its Administration Tool to connect to this Server.

    • For each project, there is one central database that is managed by the project manager or the administrator.

    • For each project, the administrator creates a database for each developer of the project and grants each developer the ADMIN privilege (administrator of the database) over that database.

    • When working on a project, each developer connects to her own database.

      After completing a task, the developer must check in the changes to make it available to the other developers.

Picking a VCS Workflow¶

All the workflows we described have pros and cons, so it is important to determine which one fits better the organization’s development environment.

  1. Centralized workflow with shared databases

    With this workflow you achieve the main purposes of a version control system:

    1. Store elements on a central repository, keeping a history of all the changes.

    2. Being able to identify the author of a specific change.

    3. Restore a specific revision

    The drawback of this workflow compared to the others is that it does not provide the capability of detecting and resolving conflicting changes performed by different developers over the same element. That is because with this workflow, the developers of a project work on the same database so they must coordinate among themselves to prevent modifying the same elements simultaneously.

  2. Distributed workflow

    Use this workflow if you need the capability of several developers detecting the type of conflicts mentioned above. If two developers make different changes on the same element, the second developer to check the change into the VCS will find that the element has been modified previously and will have to resolve the conflicts. With this workflow each developer needs to install and manage a Virtual DataPort server.

  3. Centralized workflow with private databases

    This workflow also provides the conflict detection/resolution of the distributed workflow. The difference with the distributed workflow is that, in the distributed workflow, each developer has her own Virtual DataPort server; in this one, they all work with the same Virtual DataPort server, although they are connected to their own database.

The following sections provide more details about each suggested workflow:

  • Centralized workflow with shared databases

  • Distributed workflow

  • Centralized workflow with private databases

Centralized Workflow with Shared Databases¶

This workflow adapts to the majority of projects. In this workflow, all the developers of a project share the same database.

The following diagram shows a Virtual DataPort server that follows this workflow:

  • There are two projects: A and B. Each project has its own database.

Centralized workflow with shared databases

The workflow is the following:

  1. At the beginning of the project, the administrator creates the database and checks it into the VCS. It also grants the developers the privileges to access this database.

    If the administrator grants the EXECUTE and WRITE privileges to a developer over a set of views instead of the entire database, the administrator also has to grant the EXECUTE privilege over the views directly referenced by these derived views. Otherwise, the check ins of the views the user can modify will fail. The reason is that when Denodo checks a view into the VCS, it needs to obtain the VQL of that view and to do that, the user needs the EXECUTE privilege over the views referenced by this view.

    If the users have the privilege WRITE over a view V1 but do not have the privilege EXECUTE over the views directly referenced by this view:

    • They cannot modify V1.

    • They can change the settings of the Options dialog of V1.

    • They cannot check in the changes to they do in the Options dialog of V1 because they cannot obtain the VQL of V1.

  2. To check in changes to a base view, the developer needs to have the WRITE privilege over the view. In the past, the user needed to be the owner of the base view or the administrator of the database.

  3. Developers begin to work and when they complete a task, they check the changes into the VCS. The developers must coordinate among themselves to prevent modifying the same elements simultaneously.

  4. When a developer changes a view and this change invalidates other derived views (e.g. remove a field of a view and this field is used by another view), the developer must fix the affected derived views/web services. Then, do a single check in that contains all these changes.

    If the developer makes a change that invalidates other views but does not have the privileges to modify the affected views, a developer that has the privileges to modify all the affected views should fix them. Then, this same developer should do a single check in that includes the initial changes to the view and the fix to the affected views.

    If including all the changes in a single commit is not possible, the VQL of some revisions could be invalid.

  5. As a conclusion of the item above, when developers have access to different sets of views of the database, not the entire database, we recommend they check in the changes in layers. That is, the group that can modify lower-level elements (data sources and base views) should check in the changes to these first. Then, the group that can modify intermediate views, check in changes to intermediate views and then, the same with final views and web services. This will prevent the situation described above.

  6. When developers require a new extension, they request it to an administrator. The administrator imports it and checks it in using the new wizard for checking in and out global elements. As soon as the administrator adds it to the Server, it becomes immediately available to all developers. However, the administrator should check that extension into the VCS to keep a history of the changes.

Take the following into account:

  • With this workflow, developers do not need to check in their changes because as they all use the same database, they all have access to the changes immediately. However, we recommend they check in their changes after completing a task in order to keep a history of all the changes.

  • From now on, only administrators and administrators of a database will be able to revert to a previous version. This behavior prevents the problems that could arise if a standard user reverted to a version that would involve executing VQL statements that the user was not allowed to execute. This rule applies to elements of a database and global elements.

  • If a database needs to be reverted to a version that requires an older version of a global element, an administrator has to revert the global elements first and then, the elements of the database. The section Best Practices to Manage Global Elements below explains these steps in detail.

  • In this workflow, when a user checks in a database or a folder, the Check in dialog may list elements that the Server Explorer (the tab on the left) does not list or are marked as synchronized (with the icon icon_vcs_synchronized). This occurs when another user created/modified elements on the database or folder the user is checking in, since the user refreshed the database (i.e. clicked the menu File > Refresh).

  • In this workflow, after doing a commit, a user may see new elements that were not there before. The reason is that after a commit, the administration tool refreshes the database (equivalent to clicking the menu File > Refresh). If another user created an element on this database since the last refresh, they will now appear in the elements tree.

Distributed Workflow¶

This is the recommended workflow in projects for which you need the capability of detecting and resolving conflicting changes performed by different developers over the same element.

In this workflow, all developers have their own Virtual DataPort server and they are administrators of their own servers. Therefore, they can manage the global elements without any restriction.

The following diagram shows a Virtual DataPort server that follows this workflow:

  • There are two projects: project A and project B. Each project has its own database.

  • The developers have their own Virtual DataPort server so they only need to check out the database of the projects they work with.

    • Developer 1 only works on project B so only checks out the database B.

    • Developer 2 works on project A and project B. In addition, there is a non-versioned database just for testing.

  • Both developers manage the global elements used by the elements of its databases.

Distributed workflow

Distributed workflow¶

The workflow is the following:

  1. At the beginning of a project, the coordinator of the project creates the database and notifies all the developers.

  2. Each developer checks that database out and begins working.

  3. When a developer wants to share work with other developers, she has to check the changes into the VCS.

  4. When developers require a new extension, they request it to an administrator. The administrator imports it and checks it in using the new wizard for checking in and out global elements. The administrator will later notify the developers of the project and they will obtain the new element using the new wizard that only checks in and out global elements.

  5. When a developer changes a view and this change invalidates other derived views (e.g. remove a field of a view and this field is used by another view), the developer should fix the affected derived views/web services and do a single check in that contains all these changes. If the developer only checks in the change in the view but not the fix for the affected views, when other developers check out changes from the VCS, they could get an error if the VQL stored in the VCS is not valid.

    In addition, this is a way of making sure that you can revert back to any revision of the project. If including all the changes in a single commit is not possible, indicate so in the commit message to prevent that in the future, someone tries to revert back to this commit.

Centralized Workflow with Private Databases¶

This is the recommended workflow for when you only have a Virtual DataPort server available and you also need the capability of detecting and resolving conflicting changes performed by different developers over the same element.

In this workflow, there is a single Virtual DataPort server for development. For each project, there is one central database that is managed by the project manager and one database for each developer of the project. All these databases point to the same database in the VCS.

The following diagram shows a Virtual DataPort server that follows this workflow:

  • There are two projects: project A and project B. Each project has its own database.

  • Developer 1 and Developer 2 work on project A, so for this project we have these databases:
    project_a, project_a_developer1 and project_a_developer2.
  • Only Developer 1 works on project B, so for this project we have these databases:
    project_b and project_b_developer1.
Centralized workflow with private databases

Centralized workflow with private databases¶

The workflow is the following:

  1. At the beginning of a project, an administrator creates these databases:

    • The main database of the project is called canonical database. The coordinator will be the administrator of the database and will check out all the changes to this database periodically. When a database needs to be promoted to another environment, the coordinator will check out the database and export it to a VQL file.

      The administrator will create this database, enable version control for this database and check in the change. This will create the database in the repository.

    • One database for each developer of the project. Each database that will be assigned to a developer. The administrator will grant the privilege “administrator of the database” over each database to the developer assigned to that database. This is the privilege ADMIN you can assign to users.

      To replicate each database, we recommend using the wizard Import database of the menu VCS Management because that will locate the available databases in the repository and the administrator only has to select it and provide a local name for it. This local name should follow the convention:

      <name of the project>_<username of the developer>.
      
  2. The developers of the project connect to their own database and began working.

  3. When a developer wants to share work with other developers, she has to check the changes into the VCS.

  4. The other developers need to do a check out of their database to see the changes performed by others.

  5. When the developers need to create a derived view over a view of another database, they have to point to the views of canonical database, not the developer databases. That is, if developer 2 needs to create a selection view over the view employee of project B, developer 2 has to create the derived view over the view employee of the database project_b, not project_b_developer1. The reason is that in other environments (testing, QA, etc.), only the canonical databases will exist, so the references between databases have to be created with them.

    The administrator has to grant the developers the privileges CONNECT and EXECUTE over the canonical databases over whose views, they will have to create views.

  6. When a developer changes a view and this change invalidates other derived views or web services (e.g. remove a field of a view and this field is used by another view), the developer should fix the affected elements. Then, do a single check in that contains all these changes. If the developer only checks in the change to the view but not the fix for the affected elements, when other developers check out these changes from the VCS, they will get an error because the VQL stored in the VCS is not valid.

    In addition, this is a way of making sure that you can revert back to any revision of the project. If including all the changes in a single commit is not possible, indicate so in the commit message to prevent that in the future, someone tries to revert back to this commit.

  7. When the developers require a new extension, they request it to an administrator. The administrator imports into the canonical database and checks it into the VCS using the new wizard for checking in and out global elements. As soon as the administrator add it to the Server, it becomes immediately available to all developers. However, the administrator should check that extension into the VCS to keep a history of the changes.

  8. If a database needs to be reverted to a version that requires an older version of a global element, an administrator has to revert the global elements first and then, the elements of the database. The section Best Practices to Manage Global Elements (below) explains these steps in detail.

Best Practices to Manage Global Elements¶

Global elements are elements that do not belong to a specific database. For example, users, roles, server settings, etc.

In this section, when we discuss global elements, we are only speaking of the two types of global elements that Virtual DataPort stores on a VCS: jar extensions and internationalization maps (i18n maps).

Follow these best practices to manage global elements when using the VCS support:

  • Administrators of the Denodo server must be in charge of managing the global elements. This is:

    • Uploading jar extensions

    • Managing internationalization maps (i18n maps)

    The aim is to avoid affecting other projects that also use these elements. Only administrators can manage jar extensions and i18n maps. They do that by right-clicking on the database > VCS > Global elements. From this menu, administrators can check in changes to the jar extensions and the i18n maps.

  • When the administrators create, modify or delete global elements, they must check the changes into the VCS. That way, they keep a history of these changes. In addition, when using the distributed workflow, the check in is necessary so the developers have access to the new elements.

  • When developers need to create or modify or delete global elements, they have to ask one of the administrators to do it.

    When working with the distributed workflow, after the administrator that coordinates the project changes in global elements checks in a global element, the developers must do a check out to obtain it. The reason is that each developer has her own Server. In the distributed workflow, the developers are the administrators of their Denodo servers so they can successfully check out global elements.

    This is not necessary in any of the centralized workflows because the elements are already in the Server once the administrator loads them.

  • If a database needs to be reverted to a version that requires an older version of a global element, the process has to be done in two steps:

    1. Revert the global element using a new wizard whose function will be just this (this wizard will be available in the next update).

      Only administrators will be able to use this wizard.

    2. Revert the elements that depend on the database. To do this operation, all the elements have to be checked in or discard the modifications (there cannot be local changes). The dialog to revert changes only shows commits over elements of that database, not global elements or elements from other databases.

  • Developers can check in elements that depend on global elements. E.g. derived views that use a custom function included in an extension.

  • Folders only can be created by an administrator or an administrator of the database where it is created, so it is recommended to check in the folders just after be created.

As all the databases share the global elements, there may be problems when you need different versions of the same extension. For example, let us say there are two projects project A and project B and each require a different version of a jar extension. Another example: you need to revert project A to a previous version that requires an older version of a jar extension and project B requires a newer one. If you run into these scenarios, consider using these naming conventions:

  • When a project needs a new version of a jar extension and another project still needs the old version, load the new version of the extension with a new name. This new name should be the name of the extension followed by the name of the project that needs this new version. The developers of this project will need to know that from now on, they need to use that new jar extension and not the existing one.

    We only recommend doing this when it is necessary to avoid having many versions of the same library loaded.

  • If a project needs to modify a map that is being used by another project, the administrator should create a new map, adding a suffix to its name so developers can distinguish it.

More Information about Global Elements¶

Virtual DataPort manages jars extensions and internationalization (i18n) maps as global elements, common to all databases. The reasons why they do not belong to an individual database are:

  • Jar extensions are global because they extend the capabilities of the Virtual DataPort server, not a specific database. If they were linked to a single database, on many occasions, they would have to be loaded several times. Having the same extension replicated would increase the resources needed to store and use these extensions.

  • Internationalization (i18n) maps are global because usually they are used across all the databases. Therefore, if you create one, it can be used in all databases instead of having to replicate it across all of them.

Administrators are in charge of managing global elements and checking them into the VCS.

To avoid these problems, Denodo provides these features to manage i18n maps and jar extensions:

  1. There is a wizard just for checking in and out global elements. This wizard is only available to administrators. To open it, right-click on a database > VCS > Global elements.

  2. Developers are not be able to check in or out global elements from the VCS. The implications are:

    • When a developer checks changes into the VCS, the commit will never include modifications to global elements, even if they have been modified by an administrator.

    • When a developer checks out changes from the VCS, the Virtual DataPort server ignores the changes to these elements.

    • The wizard to revert elements of a database (not global elements) will only list commits that contain changes to the elements of that database.

      Because of the wizard described in step 1, there will not be commits that modify global elements and elements of a database. A commit will only modify one type of element or the other.

Promoting Changes from Development to Testing and Production¶

After the development team has finished its work, it is time for testing.

The best way to promote a database or a set of changes from the development server to the testing server is to use the Solution Manager to create a revision. Then deploy the revision to the testing environment. After testing that the new views work as expected, deploy the same revision to the production environment. With previous versions of Denodo, the recommended way to promote elements was creating a script that invoked the scripts "export" and "import" of Denodo. However, doing it with the Solution Manager is better because:

  • The GUI of the Solution Manager makes it easier for developers to select the elements to promote.

  • It provides capabilities to promote elements to a cluster of Virtual DataPort servers, not just one server.

  • The revisions are persisted so you can review them later and keep a history of the changes.

  • ...

Promoting a Database Using Scripts Instead of the Solution Manager¶

If you want to promote changes using the scripts "export" and "import" instead of the Solution Manager, the administrator must follow these steps:

  1. Connect to the central database of the project (in our example, project1 or project2) and check out the changes from the VCS.

  2. Export to a file the entire database with the option “Export environment specific properties separately”.

  3. Edit the generated properties file to adapt its values to the testing environment. E.g. Modify the URL of the JDBC data sources to point to the testing databases along with new credentials, etc.

    On subsequent promotions of a database, the administrator can use the properties file created on previous occasions. If the administrator imports a VQL file and the properties file does not have all the properties, the import process will fail without changing anything on the Server. If this happens, the import process will return a list of the properties that are missing so the administrator can add them to the properties file.

  4. Import the VQL file with the properties file into the testing server.

After this, the users can begin testing the views they have created.

Regarding this process, we recommend the following:

  • To promote a database from one environment to the other, develop a script that invokes the scripts "import" and "export" of the Denodo Platform.

  • The process (e.g. the script) to promote a database from development to testing, and from testing to production should be the same. That way, when promoting to testing, you make sure that the process works.

  • To promote changes from one environment to another (e.g. from development to testing), we recommend promoting the entire database and not just a set of views. This avoids that some changes are not promoted accidentally.

  • To promote a database from testing to production use a VQL file and not VCS because the process of importing a database from a VCS repository takes longer than from a VQL file.

  • Because of the recommendation above, we also recommend promoting databases from development to testing using a VQL file. That way, when you migrate a database from development to testing, you test that the script that migrates databases between environments works.

Using VCS Environments¶

Defining several VCS environments is useful when:

  • The development team is geographically distributed. For example, there is a team of Denodo developers in London and another in Denver.

  • And on each location, there is a replica of the data sources they use. For example, there is one Oracle database in London and another Oracle database in Denver and their views, tables... are the same (although it's data may be different).

  • And the teams of each location want to point to the data sources of their location.

If your organization does not meet all these conditions, we recommend creating only one environment in the server called "development".

Best Practices When Using the Integration with a VCS VCS Settings of the Administration Tool

  • Denodo Site
  • Support Site
  • Partner Portal
  • Contact Us
  • Terms of Use
  • Privacy & Cookies Policy
  • ©  Denodo Technologies