Abstract: Schema incompatibilities are generating views at target data stores are detected. A view definition may be received at a view management system that specifies data to obtain from source data stores and identifies a target data store to store the view. The view management system may identify an incompatibility between a schema for the data, specified in the view definition, with a type system for the target data store. The view management system may provide an indication of the incompatibility with the type system for the target data store.

Abstract: A query that references nested data may have sub-expressions included in a subquery for nested data to perform the query. A first query engine may rewrite the query to include one or more sub-expressions that reference the nested data into a subquery for the nested data as part of generating a plan to perform the query. A second query engine may then be caused to perform the subquery for the nested data. A result of the query may be inclusive of the performance of the subquery at the second query engine.

Abstract: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: Algebraic operations are applied to change result sets for source tables to update a materialized view of a database incrementally. A procedure is determined for updating a materialized view that generates result sets for changes to source tables for a materialized view. The procedure performs one or more operations to update the materialized view using the result sets as operands in a relational algebra operator in the procedure to include the changes in the result sets in the materialized view.

Abstract: Databases may enforce foreign key constraints for efficient materialized view updates. A materialized view may be created for a database. Updates to the database may be received and performed according to a foreign key constraint enforced with respect to the updates. An update to the materialized view may be performed to make the materialized view consistent with the updates to the database. Performance of a join operation to update the materialized view that would return a result violating the foreign key constraint may be excluded from the update to the materialized view.

Abstract: Join operations may be selectively assigned from local data processing to remote data processing. Aggregation queries directed to distributed data sets may have query plans generated that include join operations. Some join operations may be executed locally while others may be assigned for remote execution at a remote data processing engine. Join operations may be identified and evaluated for remote execution according to a processing constraint for the remote data processing engine. For those join operations that satisfy the remote data processing engine, the query plan may be modified to assign the join operation for remote execution. A result for the aggregation query may be generated according to the modified query plan and the result sent in response to the aggregation query.

Abstract: A database management system receives a request to perform a transaction. The database management system commits the transaction, and in response to committing the transaction, generates a cryptographic hash based on an attribute of the transaction. The cryptographic hash is stored in a leaf-region of a hash tree. In response to a request to verify the transaction, signatures are retrieved from the tree based on a traversal of the tree to locate the node corresponding to the transaction. The retrieved signatures are used to verify the transaction.

Abstract: A database management system stores data for a table using a ledger which comprises journal and summary portions. A query processor of the database identifies a first set of operations to update a document of a table in accordance with an update command. The query processor identifies a second set of operations to update tables or views that are potentially affected by the update to the document. The query processor then causes the first and second sets of operations to be executed as an atomic unit.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: A database management system receives a request to create an index for a virtual view of a database table. In response to the request, the database management system identifies relationships between the columns of the virtual view and columns of the database table. The database management system generates an index on the database table, where columns are included in the generated index based on the identified relationships and the definition of the virtual view. Queries of the virtual view are assisted by the generated index of the underlying table.

Abstract: Managed materialized views may be generated from across heterogeneous data sources. A request to create a materialized view may be received and performed by a materialized view management platform, which may obtain and generate the materialized view from different data sources and store the materialized view in a target system. Changes to the data sources may be obtained at the materialized view management platform and updates to the materialized view may be determined. The materialized view in the target system may be updated.

Abstract: Materialized views may be generated at a managed materialized view platform that accepts data streams as a source. When updating a materialized view with a data stream as a source, a stored portion of the stream is used to maintain a history of changes to be made. When a join operation needs to utilize the data stream source to determine an update to the materialized view, the data stream is preserved to complete the join and update the materialized view.

Abstract: The maintenance of a materialized view created and managed by a materialized view management platform may be dynamically adjusted. The performance of updates to a materialized view are monitored to trigger different events to make adjustments to the performance of subsequent updates. The materialized view management platform can adequately scale to handle changes to data sources as inputs to the maintenance of the materialized view, as well as make other adjustments handle various changes in the capability of the target data store to receive updates to the materialized view (e.g., target data store outages).

Abstract: A materialized view created by a materialized view management platform may be replicated across many different target systems. The materialized view management platform allows users to specify different target systems. To create the materialized view in the different target systems, the materialized view management platform can translate the materialized view into different formats in order to store the materialized view in the different formats. Updates to the different instances of the materialized view are then made to keep the different materialized view formats in the different target systems up-to-date.

Abstract: A database management system stores data for a table as a journal of transaction. The records of the journal comprise information indicative of changes applied to a document of the table. The database receives a query on a table of transactions performed on the table. In response to the query on the table of transactions, the database generates results by retrieving and projecting the records of the journal in accordance with the query. The results of the query are indicative of changes applied to the document of the table.

Abstract: A database management system receives a request to perform a transaction. The database management system commits the transaction, and in response to committing the transaction, generates a cryptographic hash based on an attribute of the transaction. The cryptographic hash is stored in a leaf-region of a hash tree. In response to a request to verify the transaction, signatures are retrieved from the tree based on a traversal of the tree to locate the node corresponding to the transaction. The retrieved signatures are used to verify the transaction.

Abstract: A database management system receives a request to create an index for a virtual view of a database table. In response to the request, the database management system identifies relationships between the columns of the virtual view and columns of the database table. The database management system generates an index on the database table, where columns are included in the generated index based on the identified relationships and the definition of the virtual view. Queries of the virtual view are assisted by the generated index of the underlying table.

Abstract: Techniques for performing searches and presenting reports to users include receiving a user query request comprising condition classifications or text words or text phrases, receiving a user report request comprising report classification information that includes a request term, accessing an ontology providing a plurality of classifications, where each classification comprises a set of terms, accessing, using the ontology, a set of document associated with the report classification information, computing an aggregate measure of the request term based on a relationship between the request term and the set of documents, generating a requested report based on the aggregate measure of the request term and presenting the requested report.

Abstract: Probabilistic eviction of partial aggregation results may be implemented for aggregation operations performed using constrained result storage. An aggregation operation request may be received from a client and executed by scanning and applying the aggregation operation to data retrieved by scanning a data store. Partial aggregation results that are generated while executing the aggregation operation may be stored in a result store. If a partial aggregation result is generated when no further storage space in the result store is available, then one or more currently stored partial aggregation results may be evicted according to a reoccurrence probability so that the new partial aggregation result may be stored in the result store. The evicted partial aggregation results may be sent to the client.