Um Data Mart pode ser considerado, na visão bottom-up, uma reunião de vários Data Mining, desde que estes sejam desenvolvidos em modelos multidimensionais (MDM).

Com vistas a oferecer solução performática para casos distintos, o Oracle 11g suporta vários tipos de índices, tais como: B-tree, Hash e Reverse key indexes.

O Mysql 5 suporta tanto funções para pesquisa textual (full text) quanto índices para lidar com dados geográficos.

Caso a sintaxe INSERT INTO nome_da_views SELECT * FROM tabela1 fosse executada, seria gerado erro tanto no MySql quanto no Oracle, uma vez que é impossível realizar inserção de dados em views nesses dois SGBDs.

No Oracle 11g, é possível inabilitar uma trigger ao invés de excluí-la, não se permitindo, assim, que ela seja executada.
As sintaxes corretas para desabilitar uma trigger específica trigger1 e todas as triggers da tabela tabela1 são apresentadas a seguir.

ALTER TRIGGER trigger1 DISABLE;

ALTER TABLE tabela1

DISABLE ALL TRIGGERS;

Dado que o MySql 5 não dispõe de comando SQL específico para se renomear uma tabela, devem ser realizadas duas operações: inicialmente, a exclusão da tabela, por meio do comando DROP TABLE nome_da_tabela; e, posteriormente, sua criação, por meio do comando CREATE TABLE novo_nome_da_tabela; diferentemente, portanto, do procedimento a ser adotado no Oracle 11g, cujo comando SQL ALTER TABLE nome_da_tabela RENAME novo_nome_da_tabela é específico para essa operação.

No MySql 5.0, as views não podem conter subquery na cláusula FROM nem podem fazer referência ao sistema ou a variáveis do usuário.

De modo geral, o teste de release é um processo de teste do tipo caixa-branca em que as funcionalidades são verificadas e validadas mediante a avaliação interna dos módulos.

No teste de integração, verificam-se o funcionamento em conjunto dos componentes do sistema, se são chamados corretamente e se a transferência de dados acontece no tempo correto, por meio de suas interfaces.

Com relação a Scrum e eXtremme Programming (XP), julgue o item abaixo.

No Scrum, o Product Owner (PO) é responsável por definir a visão do produto e remover os impedimentos, enquanto o Scrum Master (SM) é responsável por elaborar e manter o Product Backlog, bem como por ajudar o PO a executar suas atividades diárias.