Denodo Associate key terms

The core Denodo server that stores metadata, connects to data sources, and executes queries against virtual views. Clients send SQL or REST requests to it, and it returns unified result sets without moving or copying source data.

A view defined in metadata as a query over other views or base views rather than as stored data. It is evaluated at query time, so it always reflects current source contents and can combine multiple heterogeneous sources.

A view created directly over a data source object such as a table, file, or API response. It maps source columns to view fields and is the lowest layer of the virtual model, on which derived views are built.

A view whose definition queries other views, adding joins, filters, aggregations, or unions. It contains no direct source connection, so changes in underlying base views propagate to it automatically at execution time.

A configured connection from the Denodo server to an external system, holding the driver, URL, credentials, and pooling settings. Views are created on top of it; the source itself is not modified by virtualization.

The Denodo connector type used for relational databases reached over a JDBC driver. It exposes schemas and tables for introspection and pushes compatible SQL to the database for execution.

A connector that reaches data sources through an ODBC driver rather than JDBC. It is used for systems whose JDBC support is weak or absent, and capabilities depend on the driver's SQL dialect and metadata reporting.

The per-source settings describing what SQL a data source can execute, such as joins, aggregations, subqueries, or functions. The optimizer consults them to decide which operations to delegate and which to run in Denodo.

Sending part of a query, such as filters, joins, or aggregations, to the source database for execution instead of processing it inside Denodo. Good pushdown reduces data transferred and usually improves performance.

The Denodo component that rewrites a user query into an execution plan, choosing join order, pushdown targets, and intermediate operations. Cost and capability information guide these choices before the plan is executed.

The concrete tree of operations the optimizer selects, showing which steps run in which source and which run in Denodo. Reading it is the primary way to diagnose slow views and unnecessary data movement.

Plan selection driven by estimated row counts and costs for alternative join orders and delegations, using table statistics. Without statistics the optimizer falls back to heuristics, so gathering stats matters for complex joins.

Metadata about row counts, distinct values, and value distributions for views and source tables. Denodo uses them to estimate intermediate result sizes and pick better join strategies and pushdown decisions.

A store of previous query results kept by the server so identical or compatible requests can be answered without hitting sources. Entries are invalidated by time, source changes, or explicit refresh depending on configuration.

The rule that decides when a cached result is stale, such as a fixed time-to-live or a check against source modification dates. Choosing the wrong mode risks returning outdated data to consumers.

A caching mode in which Denodo stores only the subset of source rows needed to answer the query, rather than the whole view. Later queries reusing that subset avoid refetching those rows.

A view whose results are physically stored and periodically refreshed, trading freshness for speed and source offload. It is a deliberate design choice, distinct from on-demand virtualization of live data.

An approach that presents data from many systems through a logical layer queried in real time, without copying it into a central store. Integration, transformation, and access control happen in that layer.

The broader discipline of governing and delivering data through semantic, logical models rather than physical consolidation. It covers virtual views, modeling standards, lineage, and consistent access policies across sources.

The set of views and interfaces that hides source-specific schemas, dialects, and locations from consumers. It lets source systems change without breaking downstream queries or reports.

The recorded relationship showing that one view is built on another. Denodo uses dependencies to detect impacts before changes, to trace lineage, and to order operations during deployment.

The traceable path from a reported field back through views to its originating source columns. It supports impact analysis, audit, and debugging of unexpected values in delivered data.

The practice of checking which downstream views, reports, or consumers would break before modifying or removing an upstream object. Denodo's dependency metadata makes this check systematic rather than guesswork.

The free entry-level edition of the platform, limited in scale and some enterprise features but built on the same core server. It is commonly used for learning, prototyping, and small deployments.

The full product suite containing the virtualization server, scheduler, monitoring tools, and web administration clients. Editions differ in scale limits, clustering support, and advanced governance features.

The Denodo component that runs jobs on a timetable, such as cache preloading, snapshot refreshes, or report generation. Jobs are defined against views and executed independently of user query traffic.

A searchable inventory of views and their descriptions, owners, tags, and lineage, exposed to consumers. It helps users find trustworthy data without knowing source systems or SQL.

A self-service portal where curated data products are published for discovery and subscription. Consumers browse, request access, and use delivered interfaces, while publishers retain control over exposure.

A packaged, documented, and governed dataset published for reuse, with defined ownership, quality expectations, and access terms. In virtualization it is usually a view or set of views exposed as a stable interface.

Enabling business users and analysts to find, query, and combine data through guided interfaces without hand-coding source connections. Governance controls still apply underneath the simplified experience.

The process of verifying a user's or application's identity, through local credentials, LDAP, Kerberos, or single sign-on. It establishes who is connecting before any authorization decision is made.

Deciding what an authenticated identity may do, such as connecting, browsing a database, or selecting from a view. Denodo grants these rights to users and roles through privilege assignments.

A named collection of privileges assigned to users so permissions can be managed in groups. Granting access through roles keeps administration consistent as staff and applications change.

A specific permission on a server object, such as execute, select, or write, granted to a user or role. Privileges are the atomic units from which effective access is computed.

Filtering rows returned to a user based on their identity or attributes, defined in the view rather than in each client. It enforces need-to-know access on shared views without duplicating them.

Restricting or masking specific fields for certain users while allowing the rest of the row. It protects sensitive attributes such as identifiers or salaries inside otherwise shareable views.

Replacing or obscuring real values, for example showing partial card numbers, so consumers see a usable but non-sensitive form. It can be applied statically at delivery or dynamically at query time.

The principle that data is governed by the laws and policies of the jurisdiction where it resides or whose subjects it describes. Designs must keep data and processing within permitted locations.

The requirement that data be stored and processed only in approved geographic locations. In virtualization it constrains where caches, materializations, and query execution may physically occur.

The policies, ownership, and controls that determine who may use which data and how it is described. In Denodo it is implemented through tags, roles, lineage, and documented view standards.

Physically transferring or copying data from a source into another store, such as a cache, snapshot, or warehouse. Virtualization minimizes it, but some latency and performance goals require deliberate movement.

A diagnostic record of how a specific query was planned and executed, including delegated SQL and timings. It is the practical tool for confirming whether pushdown actually happened.