Bancos de dados. para concursos. Questões comentadas

Transcrição

1 Bancos de dados para concursos Questões comentadas

2 Prefácio Banco de Dados é um dos conceitos mais importantes de Ciência da Computação. Ele agrupa informações utilizadas para um mesmo m, ou melhor, podemos entender um banco de dados como um conjunto de informações estruturadas e que podem ser organizadas para facilitar operações como inserção, busca e remoção. Em geral, um software é responsável em gerenciar a estrutura dessas informações e as operações que nelas possam ser realizadas. Devido a sua grande importância, torna-se, sem dúvida, um dos assuntos mais cobrados nos concursos de TI. Ligado na importância do assunto, o Grupo Handbook de TI preparou este volume, que traz uma série de questões comentadas sobre Banco de Dados para você se preparar muito bem nessa área. Bons estudos, Grupo Handbook de TI Página 1 de 120

3 Direitos Autorais Este material é registrado no Escritório de Direitos Autorais (EDA) da Fundação Biblioteca Nacional. Todos os direitos autorais referentes a esta obra são reservados exclusivamente aos seus autores. Os autores deste material não proíbem seu compartilhamento entre amigos e colegas próximos de estudo. Contudo, a reprodução, parcial ou integral, e a disseminação deste material de forma indiscriminada através de qualquer meio, inclusive na Internet, extrapolam os limites da colaboração. Essa prática desincentiva o lançamento de novos produtos e enfraquece a comunidade concurseira Handbook de TI. A série Handbook de Questões de TI Comentadas para Concursos Além do Gabarito é uma produção independente e contamos com você para mantê-la sempre viva. Grupo Handbook de TI Página 2 de 120

4 Canais de Comunicação O Grupo Handbook de TI disponibiliza diversos canais de comunicação para os concurseiros de TI. Loja Handbook de TI Acesse a nossa loja virtual em Serviço de Atendimento Comunique-se diretamente conosco através do faleconosco@handbookdeti.com.br Twitter do Handbook de TI Acompanhe de perto promoções e lançamentos de produtos pelo nosso Twitter com/handbookdeti Página 3 de 120

5 1. Assuntos relacionados: Banco de Dados, SGBD, Dicionário de Dados (DD), Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 34 O catálogo (ou dicionário de dados) de um Sistema Gerenciador de Bancos de Dados Relacional (a). visa a propiciar o acesso rápido a dados com um determinado valor. (b). é um item opcional do banco de dados, que pode ser removido caso o usuário deseje. (c). é raramente utilizado, sendo sua organização pouco inuente no desempenho do sistema. (d). contém informações descritivas sobre os diversos objetos do sistema. (e). tem seus dados organizados segundo um esquema hierárquico, para maior eciência no acesso. Solução: O dicionário de dados (DD) é a parte do sistema gerenciador de bancos de dados (SGBD) responsável por armazenar informações sobre a estrutura geral do banco de dados, incluindo cada um dos seus elementos de dados. Tais informações são conhecidas como metadados. Diz-se que o DD é um banco de dados sobre o banco de dados. No contexto dos bancos de dados relacionais, exemplos de elementos de dados são tabelas, colunas, relacionamentos, índices, entre outros. No DD são armazenados os nomes das tabelas, os relacionamentos entre elas, bem como os nomes das colunas, os tipos e os domínios de dados. Além de informações estruturais, o DD também armazena informações de segurança, que indicam as permissões de acesso aos elementos de dados, assim como informações físicas, indicando onde e como os dados são armazenados. Elementos como funções e stored procedures também são armazenados nos dicionários de dados do SGBD. As implementações de dicionário de dados podem variar de acordo com a tecnologia do SGBD. No caso dos bancos de dados relacionais, os dicionários de dados, geralmente, são implementados como tabelas. A forma como essas tabelas são indexadas e organizadas em disco é fator fundamental para o desempenho do banco de dados, pois elas são acessadas na maior parte das operações realizadas pelos SGBD. Página 4 de 120

6 2. Assuntos relacionados: Banco de Dados, Oracle, Banca: FCC Instituição: TRT 15a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2009 Questão: 30 Cada database Oracle tem I um ou mais datales. II um control le. III um conjunto de dois ou mais redo log les. Está correto o que consta em (a). I, II e III. (b). I, somente. (c). II, somente. (d). I e II, somente. (e). I e III, somente. Solução: A resposta da questão é a alternativa A. Primordialmente, um banco de banco Oracle é formado por três tipos de arquivos que são: datales, redo log les e control les. Um banco de dados Oracle contém uma ou mais unidades lógicas de armazenamento chamadas tablespaces, que coletivamente armazenam os dados do banco de dados. Cada tablespace, por sua vez, consiste de um ou mais arquivos chamados datales, que são arquivos físicos estruturados de acordo com o sistema operacional em que o Oracle está rodando. Os Redo Log Files armazenam os logs do sistema. Esse arquivo consiste de um buer circular assim como o redo log buer, que é mantido em memória pelo Oracle. A função primária dos redo log les é armazenar toda e qualquer mudança realizada nos dados do banco de dados. Se houver alguma falha, como o corrompimento de um datale, as informações podem ser recuperadas utilizando o redo log les e os datales de backup. O Oracle grava os redo log les de forma circular. Isto signica que, quando o arquivo redo log le atual ca cheio o banco de dados passa para o próximo arquivo redo. Quando o último arquivo do redo log le for preenchido o banco de dados volta para o primeiro, apagando informações já existentes e continuando o ciclo. Para que não se percam informações quando o ciclo for reiniciado, os arquivos de redo são arquivados periodicamente. A quantidade de arquivos de redo utilizados e a frequência do processo de arquivamento devem ser denidas de acordo com as características do banco de dados, de modo que dados não sejam perdidos e nem seja prejudicado o desempenho do sistema. Já os Control Files servem para descrever a estrutura e o status do banco de dados. São eles que contém a identicação dos arquivos de log e de dados, o nome do banco e informações de sincronismo entre os arquivos que o compõe. Como regra geral, cada banco de dados Oracle possui um único control le associado. No entanto, o Oracle possui um recurso chamado multiplexed control les, que permite o armazenamento de múltiplas cópias do control le Página 5 de 120

7 em vários discos diferentes, com o objetivo proporcionar redundância. Embora na arquitetura do Oracle o banco de dados seja composto somente por esses três arquivos, uma série de outros arquivos são importantes para colocar uma instância no ar. Exemplos desses arquivos são: Parameter File: Arquivo texto que contém todos os parâmetros necessários para colocar uma instância do Oracle no ar, por exemplo, quantidade de memória alocada para o SGA, nome e localização de arquivos de controle, tamanho de buers e de blocos etc; Alert File: Arquivo de log onde são registrados os erros ocorridos (processo, blocos corrompidos, deadlock etc.), tarefas administrativas além dos valores de parâmetros de inicialização no momento em que a instância é colocada no ar; Trace File: Arquivo de log onde são armazenadas informações detalhadas sobre os problemas ocorridos. A utilização desse arquivo é opcional. Página 6 de 120

8 3. Assuntos relacionados: Banco de Dados, Oracle, Banca: FCC Instituição: TRT 15a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2009 Questão: 31 São apenas tipos de objetos de um schema Oracle: Solução: (a). table, index, cluster e prole. (b). table, index, cluster e view. (c). table, tablespace, index e cluster. (d). tablespace, index, cluster e directory. (e). tablespace, index, cluster e view. Conceitualmente, um schema é uma estrutura lógica, criada pelos usuários, utilizada para conter ou referenciar os seus dados. É importante lembrar que, boa parte, mas nem todos SGBDs, utilizam o conceito de schema. No caso do Oracle, exemplos de objetos que são armazenados em um schema são tabelas, visões, índices e clusters. No Oracle, não há relação entre os tablespaces e o schema, de modo que objetos do mesmo schema podem estar em diferentes tablespaces, e um único tablespace podem conter objetos de diferentes schemas. Portanto, a resposta da questão é a alternativa B. Agora, vamos aproveitar a questão para rever algumas denições importantes sobre os bancos de dados Oracle. Table Uma table (tabela) é uma unidade básica de armazenamento do banco de dados Oracle, e são elas que contém possuem todos os dados acessíveis pelos usuário. Cada tabela é formada por um conjunto de colunas, cada um uma delas com um nome (ID, FULLNAME, BIRTHDAY etc) e um tipo de dado (NUMBER, VARCHAR2, DATE etc) associados. Uma linha (row) da tabela é formada pelas informações das colunas e corresponde a um registro único do banco de dados. Os usuários podem ainda especicar regras, chamadas restrições de integridade, para cada uma das colunas das tabelas. Um exemplo típico de regra é restrição de integridade NOT NULL, que força a coluna a conter um valor em todas as linhas. Views As views (visões) são apresentações customizadas de dados de uma ou mais tabelas ou outras views. Um view pode ser considerada uma query de armazenamento. De modo geral, as views não contém dados, sendo os dados por ela apresentados derivados das chamadas base tables (tabelas base). Existem tipos especiais de views, as materialized views, que contém dados de fato. Esse tipo de view geralmente é utilizada para aumentar o desempenho de determinadas consultas. As views são utilizadas geralmente para responder a consultas, e também para proporcionar um nível adicional de segurança, restringido acesso a determinados conjunto de Página 7 de 120

9 linhas e colunas de uma tabela. No entanto, as views também podem ser denidas para aceitar inserções, atualizações e exclusões. Nesses casos, todas as operações efetuadas na view afetam também as base tables. Index Os indexes (índices) são estruturas de dados utilizadas para melhorar o desempenho das operações sobre uma tabela do banco de dados. Os índices podem ser criados com base em uma ou mais colunas da tabela, sendo essa denição baseada nas consultas que o SGBD terá que responder com eciência. No Oracle, os índices mais populares são baseados em árvores B (b-trees) e nos mapas de bits (bitmaps), sendo que a melhor escolha depende do tipo de dado a ser indexado e, primordialmente, do perl de operações da aplicação. Um ótimo teste comparativo entre os índices b-tree e bitmap do Oracle pode ser vista no estudo disponível em Embora sirvam para aumentar o desempenho das operações sobre as tabelas, o que é positivo, os índices também possuem aspectos negativos, como o consumo de espaço e a diminuição do desempenho das operações de inserção dados, já que, além das tabelas, os índices precisam ser atualizados. Portanto, os índices não devem ser utilizados indiscriminadamente, mas apenas nos casos em que os seus benefícios superem seus aspectos negativos. Cluster Os clusters (agrupamentos) são grupos de duas ou mais tabelas que são sicamente armazenados próximas umas das outras, de modo a proporcionar maior desempenho das operações que referenciem ambas as tabelas. Assim como os índices, os clusters não afetam a lógica da aplicação. O fato de uma tabela pertencer ou não a um cluster é transparente para o usuário, sendo relevante apenas para ns de desempenho da aplicação. Por m, vamos falar um pouco sobre o conceito de Proles (pers) do Oracle, que foi mencionado na alternativa A da questão. O prole é um recurso do Oracle que permite denir limites de utilização de recursos do sistema e parâmetros de segurança para os usuários do SGBD. Quando um usuário é criado, por padrão ele recebe o prole Default, que dá acesso ilimitado aos recursos do sistema. Para limitar o acesso do usuário aos recursos, é necessário criar um prole e associá-lo ao usuário. Alguns exemplos de parâmetros (cujos nomes são auto-explicativos) que podem ser controlados através de prole são mostrados a seguir. Página 8 de 120

10 Parâmetros de Recursos [SESSIONS_PER_USER n UNLIMITED DEFAULT] [CPU_PER_SESSION n UNLIMITED DEFAULT] [CPU_PER_CALL n UNLIMITED DEFAULT] [CONNECT_TIME n UNLIMITED DEFAULT] [IDLE_TIME n UNLIMITED DEFAULT] [LOGICAL_READS_PER_SESSION n UNLIMITED DEFAULT] [LOGICAL_READS_PER_CALL n UNLIMITED DEFAULT] [COMPOSITE_LIMIT n UNLIMITED DEFAULT] [PRIVATE_SGA n [K M] UNLIMITED DEFAULT] Parâmetros de Password [FAILED_LOGIN_ATTEMPTS [PASSWORD_LIFE_TIME [PASSWORD_REUSE_TIME [PASSWORD_REUSE_MAX [PASSWORD_LOCK_TIME [PASSWORD_GRACE_TIME [PASSWORD_VERIFY_FUNCTION expr UNLIMITED DEFAULT] expr UNLIMITED DEFAULT] expr UNLIMITED DEFAULT] expr UNLIMITED DEFAULT] expr UNLIMITED DEFAULT] expr UNLIMITED DEFAULT] function_name NULL DEFAULT] Página 9 de 120

11 4. Assuntos relacionados: Banco de Dados, Oracle, Banca: FCC Instituição: TRT 15a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2009 Questão: 32 NÃO é um processo do tipo background contido em uma instância Oracle: (a). system monitor process. (b). checkpoint process. (c). archiver process. (d). server process. (e). recoverer process Solução: O Oracle possui três tipos básicos de processo que são: processos User, processos server e processos em background. Com isso, a resposta da questão é alternativa D, server process. Agora, vamos conhecer um pouco mais dos processos do Oracle. Os processos server recebem as requisições dos processos user, realizam o parse das instruções SQL, vericam as permissões de acesso do usuário, traz os dados do disco para o DBBC, caso necessário, e retorna os dados para o usuário. Um processo server pode ser dedicado para um processo user (dedicated server process) ou compartilhado entre múltiplos processos user (shared server process). Os processos server compartilhados só são possíveis em sistemas multithreaded. As funções desempenhadas pelos processos user são se conectar com os processos server, enviar instruções SQL e receber os resultados. Caso o servidor suporte processos server compartilhados, diversos processos server podem ser atendidos por um mesmo processo server. Já os os processo em background não realizam nenhuma comunicação com os processos user. Os processos em backgound são responsáveis pelas tarefas de apoio para garantir o funcionamento do sistema de gerenciamento de banco de dados como um todo. Um sistema Oracle tem inúmeros processos em background, porém apenas 4 deles são obrigatórios. São eles: Process Monitor (PMON): Realiza a recuperação quando algum processo falha, além de liberar o cache, locks e demais recursos que o processo estava utilizando; System Monitor (SMON): Realiza o processo de recuperação da instância durante o processo de inicialização, limpa segmentos temporários que não estão mais em uso, recupera transações terminadas de forma anormal e realiza desfragmentação nos arquivos de dados para facilitar a alocação; Database Writer (DBWR): A função principal do DBWR é escreve os blocos de dados modicados (dirty) do DBBC para o disco. Isso é feito nas seguintes situações: (i) quando a lista de blocos modicados atinge um tamanho congurado; (ii) quando o processo percorre um quantidade congurada de blocos e não encontra nenhum bloco livre; (iii) quando ocorre um timeout; (iv) quando ocorre um checkpoint ou (v) quando Página 10 de 120

12 o DBWR recebe um sinal do processo LGWR. Dessa forma, o processo DBWR além de garantir que as alterações feitas em buer serão persistidas, também gerencia o espaço em buer para melhorar o desempenho do banco; Log Writer (LGWR): é o responsável por copiar as informações do redo log buer para o o redo log le (arquivo de log com a mesma estrutura do redo log buer). O LGWR também é responsável por atualizar os headers dos arquivos de dados quando ocorre um checkpoint. O LGWR é disparado nas seguintes situações: (i) quando ocorre um commit; (ii) quando ocorre um checkpoint; (iii) quando ocorre um timeout ou (iv) quando o redo log buer atinge um terço de sua capacidade. Além desses quatro, o Oracle possui uma série de outros processos em background que são de instalação e uso opcionais. Os mais importantes são os seguintes: CKPT: Atualiza os headers dos arquivos de dados quando ocorre um checkpoint. A utilização desse processo pode ajudar a melhorar o desempenho do sistema permitindo que o processo LGWR se concentre apenas na cópia do redo log buer para o disco; RECO: Responsável pela recuperação de falhas envolvendo transações distribuídas. Esse processo é necessário quando o Oracle está rodando de forma distribuída; ARCH: Responsável por copiar o redo log le (que é um buer circular) para um dispositivos de armazenamento oine para que os logs não sejam perdidos; Pnnn: Processo responsável pela execução de consultas paralelas; SNPn: Controla a replicação de objetos dos banco de dados em outro site. Essas cópias são chamadas snapshots. Esse processo pode ser escalonado para executar periodicamente; LCKn: Realiza o controle de locks entre múltiplas instâncias; Dnnn: Esse processo funciona como um dispatcher quando o sistema está utilizando processos server compartilhados. é necessário um dispatcher para cada protocolo de comunicação utilizado. Página 11 de 120

13 5. Assuntos relacionados: Oracle, SQL, Banca: FCC Instituição: TRT 16a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2009 Questão: 25 Os programas PL/SQL são constituídos por blocos que executam operações lógicas e cada bloco tem três partes que denem as: I. declarações de variáveis e itens. II. instruções procedurais e SQL. III. instruções de tratamento de erros. No bloco é obrigatória a presença da seção que se arma em (a). I e II, apenas. (b). II e III, apenas. (c). I, II e III (d). I, apenas. (e). II, apenas. Solução: A linguagem PL/SQL é uma linguagem procedural da Oracle. Ela é uma extensão da linguagem SQL padrão. Ela serve para criar programas complexos e poderosos, não só para o banco de dados, mas também em diversas ferramentas Oracle. Os blocos de PL/SQL são processados por um uma PL/SQL Engine, que ltra os comandos SQL e os manda individualmente para o SQL Statement Executor no Oracle Server. A unidade básica de um programa PL/SQL é um bloco, que possui a seguinte estrutura: DECLARE Seção para declaração de variáveis, tipos e subprogramas locais. BEGIN Seção executável. Nesta seção, cam as instruções procedurais e SQL. Esta é a única seção do bloco que é indispensável e obrigatória. EXCEPTION Seção onde cam as instruções de tratamento de erro. Por denição, apenas a seção executável é requerida. As outras seções são opcionais. Logo, somente a armativa II está correta e alternativa a ser marcada é a letra E. Aprofundando mais na linguagem, podemos dizer que as únicas instruções SQL que são permitidas em um programa PL/SQL são SELECT, INSERT, UPDATE, DELETE e várias Página 12 de 120

14 outras instruções de manipulação de dados e de controle de transação. Além disso, PL/SQL não é caso sensitivo, ou seja, não diferencia maiúsculas de minúsculas. Instruções de denição de dados como CREATE, DROP ou ALTER não são permitidas. A seção executável, citada anteriormente, também contém construções tais como atribuições, desvios, loops, chamadas a procedimentos e triggers. A capacidade de usar laços(loops) é uma das principais diferenças entre SQL e PL/SQL. A instrução SELECT no PL/SQL funciona apenas se o resultado da consulta contém uma única tupla. Se a consulta retorna mais do que uma tupla, será necessário usar um cursor. Um cursor é uma variável que itera sobre as tuplas de alguma relação. Essa relação pode ser uma tabela armazenada ou pode ser a resposta para alguma consulta. Enm, a linguagem PL/SQL possui mais recursos que o padrão e visa fornecer mais exibilidade e aproveita o poder das linguagens procedurais para o desenvolvimento de programas complexos que envolvam acesso ao banco de dados Oracle. Página 13 de 120

15 6. Assuntos relacionados: Banco de Dados, Commit, Savepoint, Rolling Back, Rolling Forward, Banca: FCC Instituição: TRT 18a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2008 Questão: 46 Antes do Oracle terminar uma transação deve acontecer explicitamente uma operação de (a). commit ou savepoint, apenas. (b). commit ou rolling back, apenas. (c). commit ou rolling forward, apenas. (d). rolling back ou rolling forward, apenas. (e). commit, rolling back, rolling forward ou savepoint. Solução: Vamos, primeiramente, apresentar o que cada operação signica: commit: operação que efetiva, no banco de dados, as alterações (insert, delete e update) realizadas em uma transação. Ou seja, as alterações de uma transação somente são enxergadas por outras transações de outras sessões após um commit. Veja abaixo um exemplo de utilização deste operador: SQL> insert into alunos (matricula, nome) values (1, `Ricardo Vargas`); 1 row created. SQL> commit; Commit complete. savepoint: marca um ponto (estado) na transação para onde se pode voltar com um rollback. Portanto, em transações mais complexas, se utiliza alguns savepoints para marcar pontos para os quais seja possível realizar rollback. Dessa forma, estrategicamente, apenas parte das alterações da transação é desfeita. Veja abaixo um exemplo de utilização deste operador: SQL> insert into alunos (matricula, nome) values (2, `Diogo Gobira`); 1 row created. SQL> savepoint estado_1; Savepoint created. SQL> insert into alunos (matricula, nome) values (3, `André Camatta`); 1 row created. SQL> savepoint estado_2; Savepoint created. rolling back: em uma transação sem savepoints, esta operação desfaz todas as alterações realizadas. Já em um transação com savepoints, um rollback desfaz todas as alterações realizadas após o último savepoint (volta-se ao estado do último savepoint). Veja abaixo um exemplo de utilização deste operador: SQL> rollback to estado_1; Rollback complete. Página 14 de 120

16 rolling forward: é um recurso utilizado em caso de falha de banco de dados para que o seu estado imediatamente antes da falha seja restabelecido. Durante o funcionamento normal de um banco de dados, todas as informações sobre operações são armazenadas em arquivos do tipo RedoFiles. Em situações de falha, logo após o banco de dados voltar a operar, esses arquivos são lidos e, então, as operações são refeitas. Como se pode concluir dos itens acima, as operações savepoint e rolling forward não são obrigatórios até o término de cada transação. Isso porque savepoint é opcional e rolling forward somente é utilizado em casa do falha de bando de dados. Tendo em vista o exposto, para que toda operação seja atômica e o banco de dados seja mantido consistente, é necessária ao nal de cada transação a execução de um commit ou um rollback. Portanto, a alternativa que deve ser escolhida é a letra B. Página 15 de 120

17 7. Assuntos relacionados: Banco de Dados, PL/SQL, Banca: FCC Instituição: TRT 18a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2008 Questão: 47 A estrutura de controle Iteração pode ser utilizada em PL/SQL com os comandos (a). LOOP, CASE-LOOP, WHILE-LOOP e FOR-LOOP. (b). LOOP, CASE-LOOP e WHILE-LOOP. (c). LOOP, CASE-LOOP e FOR-LOOP. (d). CASE-LOOP, WHILE-LOOP e FOR-LOOP. (e). LOOP, WHILE-LOOP e FOR-LOOP. Solução: PL/SQL é o acrônimo para Procedural Language/Structured Query Language. Ou seja, PL/SQL é uma linguagem procedural que estende SQL. Ela foi desenvolvida pela Oracle Corporation e, portanto, é utilizada em banco de dados Oracle. O surgimento da PL/SQL aconteceu em 1991 para o Oracle 6.0. Antes disso, os desenvolvedores tinham que embutir instruções do tipo SQL nos códigos-fonte procedurais (por exemplo, dentro de códigos C). Com o aparecimento da PL/SQL isso mudou. Todo o código procedural e também as instruções relacionadas ao banco podem ser escritos diretamente em PL/SQL. Essa linguagem suporta variáveis, condições, loops, arrays, exceções, funções e procedimentos. A estrutura básica do PL/SQL é chamada de bloco. Portanto, um programa escrito nessa linguagem é composto por blocos. Geralmente, um bloco é desenvolvido para efetuar uma ação lógica no programa. Cada bloco é estruturado da seguinte forma: DECLARE Seção onde são feitas as declaradas locais: subprogramas e variáveis e seus tipos. Esta seção não é obrigatória. BEGIN Seção que contém o que será executado de fato: instruções procedurais e SQL. Esta seção é obrigatória. EXCEPTION Seção onde ficam as instruções de tratamento de erro. Esta seção também não é obrigatória. END Um exemplo bem básico é apresentado a seguir: DECLARE i NUMBER := 1; BEGIN LOOP Página 16 de 120

18 INSERT INTO T1 VALUES(i,i); i := i+1; EXIT WHEN i>100; END LOOP; END; Especicamente com relação a estrutura de controle do tipo iteração, PL/SQL possui os seguintes recursos: LOOP, WHILE, FOR e Cursor FOR. Os três primeiros são bem conhecidos e geralmente estão presentes nas linguagem procedurais. Já o quarto é um tipo especial de FOR em que uma variável assume o lugar de registros de uma relação. Abaixo um exemplo para facilitar o entendimento. DECLARE CURSOR cursor_person IS SELECT person_code FROM people_table; BEGIN FOR RecordIndex IN cursor_person LOOP DBMS_OUTPUT.PUT_LINE(RecordIndex.person_code); END LOOP; END; Nesta questão, a alternativa E é a única que traz apenas comandos PL/SQL relacionados a controle de iteração. Portanto, é essa a alternativa correta. Página 17 de 120

19 8. Assuntos relacionados: Banco de Dados, Triggers, Gatilhos, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas - Infraestrutura Ano: 2008 Questão: 59 Para os gatilhos (triggers) utilizados em bancos de dados, são feitas as armativas a seguir. I - Os triggers podem ser congurados para disparar antes ou após a execução de uma ação de Update, Delete ou Insert em uma tabela. II - A cláusula When no comando Create Trigger é válida somente para triggers de nível de linha. III - Os chamados triggers autônomos são executados como uma transação autônoma, sendo que as modicações no banco de dados por eles efetuadas podem ser conrmadas ou revertidas, independente do estado da instrução que desencadeou a chamada do trigger. Está(ão) correta(s) as armativas (a). I, apenas. (b). II, apenas. (c). I e II, apenas. (d). II e III, apenas. (e). I, II e III. Solução: Um gatilho (trigger) é um tipo especial de procedimento armazenado (stored procedure) que está associado a uma tabela, e é executado pelo sistema de banco de dados automaticamente quando um determinado evento ocorre para a tabela a qual o gatilho está associado. Para um gatilho ser implementado em um banco de dados, duas exigências devem ser satisfeitas: i) especicar as condições sob as quais o gatilho deve ser executado; e ii) especicar as ações que devem ser realizadas quando um gatilho for disparado. Por exemplo, suponha que em vez de permitir saldos negativos em uma conta corrente, o banco crie condições para que a conta seja zerada e o saldo negativo seja transferido para a conta empréstimo de mesmo número que a conta corrente. Neste exemplo, a condição para o disparo do gatilho é o saldo negativo da conta corrente, e a ação a ser realizada é a transferência do saldo negativo para a conta empréstimo. CREATE [DEFINER = {user CURRENT_USER}] TRIGGER trigger_name trigger_time trigger_event ON table_name FOR EACH ROW trigger_stmt Tabela 1: exemplo de CREATE TRIGGER em MySQL. Os eventos no banco de dados que ativam um gatilho são os comandos de Linguagem de Manipulação de Dados (DML - Data Manipulation Language): INSERT, DELETE e UPDATE. Página 18 de 120

20 Um gatilho é criado utilizando a função CREATE TRIGGER que especica a tabela a qual está associado, a condição para ocorrência do evento e o tipo de ação (nome da função) que será executada com o evento. A sintaxe da função CREATE TRIGGER no MySQL e no Postgree é apresentada na Tabela 1 e na Tabela 2, respectivamente. Note que os sistemas de bancos de dados possuem seus próprios recursos de gatilho não padronizados. A seguir, explicamos cada um dos parâmetros: DEFINER: cláusula opcional para denir o usuário para criar o gatilho; trigger_name: dene o nome do gatilho; trigger_time: dene se o gatilho será ativado antes (BEFORE) ou depois (AFTER) do comando que o disparou; trigger_event: dene qual será o evento: INSERT, DELETE ou UPDATE. Podem ser especicados vários eventos utilizando OR; table_name: nome da tabela cujos eventos podem disparar o gatilho; trigger_stm: uma função fornecida pelo usuário, declarada como não recebendo nenhum argumento e retornando o tipo TRIGGER, que é executada quando o gatilho dispara; FOR EACH ROW / FOR EACH STATEMENT: especica se o procedimento do gatilho deve ser disparado uma vez para cada linha afetada pelo evento do gatilho, ou apenas uma vez por comando SQL; arguments: uma lista opcional de argumentos, separados por vírgula, a serem fornecidos para a função quando o gatilho for executado. O gatilho pode ser especicado para disparar antes (BEFORE) de realizar uma operação na linha (antes das restrições serem vericadas e os respectivos comandos de DML serem executados), ou após a operação estar completa (após as restrições serem vericadas e os respectivos comandos terem completado). Se o gatilho for disparado antes do evento, o gatilho pode fazer com que a operação não seja realizada para a linha corrente, ou pode modicar a linha sendo inserida. Se o gatilho for disparado depois (AFTER) do evento, todas as mudanças, incluindo a última inserção, atualização ou exclusão, estarão visíveis para o gatilho. Um gatilho que está marcado FOR EACH ROW é chamado uma vez para cada linha que a operação modica. Diferentemente, um gatilho que está marcado FOR EACH STATE- MENT somente executa uma vez para uma determinada operação, não importando quantas linhas foram modicadas. Em particular, uma operação que não modica nenhuma linha ainda assim resulta na execução de todos os gatilhos FOR EACH STATEMENT aplicáveis. CREATE TRIGGER trigger_name {BEFORE AFTER} {trigger_event [OR...]} ON table_name [ FOR [ EACH ] { ROW STATEMENT }] EXECUTE PROCEDURE trigger_stm (arguments) Tabela 2: exemplo de CREATE TRIGGER em Postgree. Os gatilhos são usados com enorme eciência para impor e manter integridade referencial de baixo nível, e não para retornar resultados de consultas. A principal vantagem é que eles podem conter uma lógica de processamento complexa. Os sistemas de bando de dados possuem algumas restrições em relação aos gatilhos: Página 19 de 120

21 Não se pode chamar diretamente um gatilho; Não é permitido iniciar ou nalizar transações em meio a execução de um gatilho; Não se pode criar um gatilho para uma tabela temporária ou para uma visão; Não é possível criar gatilhos para o comando SELECT, pois este comando não modica nenhuma linha. Com base no explicado anteriormente, analisaremos as armações da questão: I - Os triggers podem ser congurados para disparar antes ou após a execução de uma ação de UPDATE, DELETE ou INSERT em uma tabela. Isso é especicado no comando CREATE TRIGGER com os parâmetros BEFORE ou AFTER, respectivamente. Portanto, armativa correta. II - Conforme apresentamos, a cláusula WHEN não está presente no comando CREATE TRIGGER para o MySQL e PostgreeSQL. Entretanto, no Oracle SQL e SQLite é possível utilizar a cláusula WHEN no comando CREATE TRIGGER. Quando a condição da cláusula WHEN é válida, o gatilho é executado para cada linha modicada, isto é, a execução do gatilho ocorre em nível de linha. Portanto, alternativa correta. III - Os triggers autônomos (autonomous triggers) estão presentes no sistema de banco de dados Oracle SQL. Diferente dos triggers normalmente existentes nos sistemas de banco de dados, os triggers autônomos são executados como uma transação autônoma. Por meio das transações autônomas, um trigger pode conter comandos de controle de transação como COMMIT e ROLLBACK. Com os comandos COMMIT E ROLLBACK as modicações no banco de dados efetuadas por um gtilho podem ser conrmadas ou revertidas, independente do estado da instrução que desencadeou a chamada do trigger. Os triggers autônomos também podem executar comandos de Linguagem de Denição de Dados( DDL - Data Denition Language). Portanto, armativa correta. Todas as armativas feitas estão corretas. Logo, a resposta desta questão é a letra E. Página 20 de 120

22 9. Assuntos relacionados: Banco de Dados, SQL, Transact SQL, Banca: ESAF Instituição: Superintendência de Seguros Privados (SUSEP) Cargo: Analista Técnico da SUSEP - Tecnologia da Informação Ano: 2010 Questão: 33 Em relação às operações em bancos de dados SQL, é correto armar que (a). o Transact-SQL não permite alterar a credencial de login. (b). o Transact-SQL permite redenir a senha desde que seja fornecida a senha antiga. (c). para executar consultas de Transact-SQL pode-se emitir instruções ao se iniciar o SQL/CMD. (d). pode-se criar bancos de dados utilizando-se Transact-SQL, por meio do comando START DATABASE. (e). pode-se restaurar bancos de dados utilizando-se Transact-SQL, por meio dos comandos REUSE DATABASE e RESET BLOG. Solução: A Structured Query Language, ou SQL é uma linguagem de banco de dados desenvolvida para gerenciar dados em Sistemas de Gerência de Banco de Dados Relacional (RDBMS), e foi originalmente baseada em álgebra relacional. Seu escopo inclui inserção, remoção, consulta de dados, criação e modicação de esquemas e controle de acesso a dados. SQL é uma linguagem declarativa, ao contrário de linguagens de programação como C ou Pascal que são imperativas. Apesar de haver padrões para o SQL (ANSI SQL92, SQL99 por exemplo), a maioria das implementações utilizam extensões que incluem funcionalidades de linguagens de programação procedural, como controle de uxo, por exemplo. Transact SQL ou TSQL é a extensão proprietária Microsoft e Sybase do SQL. Para a utilização do T-SQL é necessário o Microsoft SQL Server. Toda aplicação que se comunique com um SQL Server utiliza instruções T-SQL. Entre as funcionalidades adicionais que o Transact SQL oferece em relação ao SQL, pode-se citar: Controle de uxo, variáveis locais, funções adicionais para tratamento de strings, processamento de datas, funções matemáticas etc. a) ERRADO: uma credencial é um registro que contém informações de autenticação necessárias para se conectar a serviços fora do SQL Server. É criada pelo comando CREATE CREDENTIAL e as propriedades das credenciais podem ser alteradas pelo comando ALTER CREDENTIAL. Uma credencial pode ser mapeada para um login do SQL Server através do comando CREATE LOGIN; b) ERRADO: transact-sql permite redenir a senha através da instrução ALTER LO- GIN. Para alterar senha de outros usuários é necessário a permissão ALTER ANY LOGIN. Se o usuário atual tiver permissão CONTROL SERVER, ele não precisa informar o antigo password; c) CORRETO: o SQL/CMD é um utilitário que permite que instruções SQL e TSQL sejam escritas e enviadas ao servidor SQL Server, inclusive consultas; Página 21 de 120

23 d) ERRADO: cria-se banco de dados através do comando CREATE DATABASE. START DATABASE não é um comando T-SQL; e) ERRADO: o comando para restaurar backups é o RESTORE. Ele permite restaurar banco de dados inteiros, fazer restaurações parciais, apenas arquivos ou grupo de arquivos de banco de dados. REUSE DATABASE e RESET BLOG não são comandos T-SQL. Página 22 de 120

24 10. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 24 Um modelo entidade-relacionamento foi reestruturado conforme mostrado na gura acima. Concluiu-se que todos os usuários eram funcionários, embora nem todos os funcionários fossem usuários. O modelo relacional derivado desse modelo conceitual possuía originalmente duas variáveis de relação básicas, com os mesmos nomes das entidades correspondentes, tendo ambas como chave primária. Considerando que a variável de relação FUN- CIONARIO não será modicada e que a independência de dados lógica será honrada, a variável de relação USUARIO (a). terá que manter todos os seus atributos originais. (b). dispensará o uso de chaves candidatas. (c). será substituída por uma variável de relação básica e uma derivada. (d). será substituída por uma variável de relação básica, apenas. (e). será substituída por uma variável de relação derivada, apenas. Solução: O modelo entidade-relacionamento é um padrão para modelagem conceitual de banco de dados. Na gura da questão, os objetos representados por retângulos são conjuntos de entidades e os objetos representados por elipses são atributos. Página 23 de 120

25 Uma entidade é um objeto que pode ser identicado de forma unívoca a todos os outros objetos. A entidade pode representar tanto algo concreto, como uma pessoa, ou algo abstrato, como um empréstimo, por exemplo. Um conjunto de entidades reúne todas as entidades de um mesmo tipo, ou seja, que possuem as mesmas propriedades: atributos. Os atributos são propriedades que descrevem cada entidade de um conjunto de entidades. Dizemos ainda que cada entidade pode ter seu próprio valor para cada atributo. Exemplo: uma determinada entidade que representa uma pessoa pode ter o valor João Assis para o atributo nome e o número para o atributo número de inscrição. O modelo entidade-relacionamento pode descrever diversos outros objetos importantes para a modelagem de banco de dados, como os conjuntos de relacionamentos, os atributos multivalorados e a participação de entidades em um conjunto de relacionamentos. Há, ainda, os conceitos de generalização e especialização. Generalização é o resultado da união de dois ou mais conjuntos de entidades, produzindo um conjunto de entidades de nível mais alto. Por outro lado, especialização é o resultado da separação de um subconjunto de entidades, formando conjuntos de entidades de nível mais baixo. A generalização é usada para enfatizar as semelhanças entre entidades de nível mais baixo e ocultar suas diferenças. A especialização é o inverso: ela enfatiza as diferenças entre as entidades. Verica-se que, no primeiro modelo, existem duas entidades independentes com seus respectivos atributos. A transformação realizada para se chegar ao segundo modelo conceitual nada mais é do que um processo de generalização. Já o modelo relacional ao qual a questão se refere é uma maneira de representar o banco de dados logicamente, e não conceitualmente. No modelo relacional, os dados são representados como relações matemáticas, isto é, como um subconjunto do produto cartesiano de n conjuntos. Na etapa de transformação do modelo conceitual para o modelo lógico, será permitido ao projetista criar um modelo consistente da informação a ser armazenada por meio do processo de normalização, por exemplo. No modelo relacional, uma variável relacional, também conhecida como relvar, é uma variável que representa uma relação. Para tornarmos a explicação bem simples, podemos dizer que uma variável relacional básica representa uma tabela no SQL e uma variável relacional derivada representa uma visão ou o resultado de uma consulta. O modelo relacional derivado do primeiro modelo entidade-relacionamento pode ser descrito da seguinte maneira: Funcionario( , nome) Usuario( , nome, login) Segundo o enunciado, após a generalização, a variável de relação Funcionario será mantida sem modicações. Já, para a variável de relação Usuario, criaremos uma nova variável de relação básica da seguinte forma: UsuarioTabela( , login) Página 24 de 120

26 Isso pode ser feito, já que, na generalização, foi criado um relacionamento de muitos-paraum com a variável de relação Funcionario. Sendo assim, o campo será suciente para representar o usuário na variável de relação Funcionario. Note que, dessa maneira, a independência lógica ainda não está honrada, já que a variável de relação UsuarioTabela não possui a informação do atributo nome. Para garantirmos a independência lógica, precisamos criar uma variável relacional derivada que chamaremos de UsuarioVisao ou simplesmente Usuario. No SQL, essa variável de relação representará uma junção das tabelas geradas pelas variáveis de relação básica Funcionario e UsuarioTabela e representará todos os usuários, mas, dessa vez, com o atributo nome advindo da tabela que representa o conjunto de funcionários. Dada as explicações imediatamente acima, a resposta correta é a alternativa C. Página 25 de 120

27 11. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Banca: FCC Instituição: TRT 2a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2008 Questão: 39 Em um diagrama entidade relacionamento, uma situação de composição tal qual empregado gerencia empregado, geralmente é apresentada como (a). entidade fraca. (b). relacionamento associativo. (c). auto relacionamento. (d). relacionamento interativo. (e). relacionamento restritivo. Solução: A resposta da questão é a alternativa C, auto relacionamento. O Modelo de Entidades e Relacionamentos (MER) é um modelo abstrato cuja nalidade é descrever, de maneira conceitual, os dados a serem utilizados no projeto de um sistema de informação. A principal ferramenta do modelo é o diagrama Entidade Relacionamento. O primeiro conceito fundamental do MER é o de entidade. Uma entidade corresponde à representação de todo e qualquer substantivo, concreto ou abstrato, sobre o qual precisase armazenar e recuperar informações. Em um sistema de vendas, por exemplo, algumas entidades comuns seriam Vendas, Produtos e Clientes. O segundo conceito fundamental é o de relacionamento. No MER, um relacionamento mostra como as entidades se relacionam entre si. Em um sistema de vendas, a entidade Vendas estaria relacionada com a entidade Produtos, bem como com a entidade Clientes. Os auto relacionamentos (também chamados relacionamentos recursivos) são casos especiais onde uma entidade se relaciona com si própria. Apesar de serem relacionamentos muito raros, a sua utilização é muito importante em alguns casos. Os auto relacionamentos podem ser do tipo 1:1, 1:N ou N:M. Exemplos deste relacionamento podem ser encontrados nas chamadas explosões de materiais, nas quais itens compostos são formados por muitos itens componentes. Os itens compostos, por sua vez, podem ser componentes de outros itens maiores. Para exemplicar melhor, vamos utilizar um exemplo concreto. O item automóvel é composto pelo chassis, motor, direção, câmbio etc. O motor, por sua vez, é formado pelo carburador, velas, platinado etc. Esta explosão de composição dos itens pode ser representada por um auto relacionamento N:M da entidade itens, sendo que o papel de um determinado item ora é de componente, ora é de composto. Um outro exemplo típico de auto relacionamento é o gerenciamento de funcionários, trazido na questão. Um gerente nada mais é que um funcionário que possui um relacionamento com Página 26 de 120

28 outros funcionários que lhe são subordinados. Esta relação pode ser representada por um auto relacionamento 1:N da entidade funcionários, sendo que o papel de um determinado funcionário ora é de gerente, ora é de subordinado. Página 27 de 120

29 12. Assuntos relacionados: Banco de Dados, DER, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 48 Um analista de sistemas recebe o seguinte trecho de descrição de um sistema: Uma empresa contrata um prossional para trabalhar em um projeto recebendo um determinado salário. Sabe-se que um projeto pode ter a participação de diversas empresas e que um prossional pode desempenhar várias atividades nesse projeto (p.ex. operador de guindaste e pedreiro). Que modelo ER representa corretamente essa descrição? (O símbolo (*) representa atributo multivalorado). (a). Modelo 1 (b). Modelo 2 (c). Modelo 3 (d). Modelo 4 (e). Modelo 5 Figura 1: Modelos ER Solução: Esta é uma questão polêmica, pois seu enunciado é um tanto quanto pobre de informações. Quando isso acontece, a melhor estratégia é tentar identicar quais alternativas estariam mais erradas e eliminá-las. Uma consideração muito importante para uma resolução consciente desta questão que o Página 28 de 120

30 enunciado deveria trazer seria a denição se um prossional pode ser contratado por mais de uma empresa e, por consequência, poder trabalhar em mais de um projeto. Se o candidato zer uma consideração diferente da imaginada pelo autor desta questão, suas chances de acertar esta questão diminuem consideravelmente. Vamos às alternativas. (A) ERRADA Considerando que um determinado prossional pode ser contratado por diferentes empresas para trabalhar em diversos projetos, este modelo é inapropriado. Isso por conta do atributo atividade, que está relacionado ao prossional. Em outras palavras, teríamos que um determinado prossional somente poderia exercer as mesmas atividades em todos os seus eventuais contratos, o que não é apropriado. Por outro lado, caso a consideração acima não seja feita, este modelo se mostra adequado, porém limitado. (B) ERRADA A argumentação para esta alternativa é similar à feita na alternativa anterior. Se a consideração supracida for feita, um determinado prossional somente poderia ter um único salário para seus eventuais contratos, o que não é apropriado. Caso contrário, o modelo desta alternativa também atende, apesar de ser limitado. (C) e (D) ERRADA Estas deveriam ser as primeiras alternativas a serem eliminadas. Perceba que a relação existente entre os conjuntos de entidades empresa e projeto, denominada possui, não se encaixa na descrição do sistema apresentada no enunciado. (E) CORRETA Esta é a alternativa menos errada e, portanto, a escolha mais segura possível. Como o atributo atividade está associado ao conjunto de relacionamentos contrato, este modelo não se limita ao cenário de que um prossional somente pode ter um contrato para trabalhar em apenas uma empresa para participar de um único projeto. De qualquer forma, cabe ressaltar que o nível de normalização deste modelo não é bom. Em um banco de dados relacional, o conjunto de relacionamentos contrato seria implementado por meio de uma tabela. Imagine o caso em que um prossional execute 5 tarefas em um contrato com uma determinada empresa. Nesse caso, teríamos nessa tabela 5 linhas com os 4 campos com valores repetidos: salário e chaves estrangeiras dos conjuntos de entidades envolvidos. Essa repetição desnecessária de valores pode ser onerosa, mas ela pode ser eliminada com um processo de normalização deste modelo, que resultaria em outro modelo mais adequado. Página 29 de 120

31 13. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Modelo Relacional, Projeto Lógico de Banco de Dados, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas Pleno - Processos Ano: 2006 Questão: 23 Considere o modelo entidade-relacionamento representado abaixo. Na transformação deste modelo conceitual Entidade-Relacionamento em um modelo lógico relacional, as cardinalidades do relacionamento entre as entidades exercem papel importante. Dado que se deseja gerar um modelo relacional que atenda à terceira forma normal, pode-se armar que sempre darão origem a uma tabela para cada uma das entidades relacionadas os relacionamentos do tipo: (a). (0,n) x (0,n), podendo ou não gerar uma tabela para o relacionamento. (b). (0,1) x (0,n), podendo ou não gerar uma tabela para o relacionamento. (c). (0,1) x (1,1), gerando uma tabela para o relacionamento. (d). (1,n) x (1,n), podendo ou não gerar uma tabela para o relacionamento. (e). (1,1) x (1,n), devendo gerar uma tabela para o relacionamento. Solução: Uma entidade corresponde à representação de todo e qualquer substantivo, concreto ou abstrato, sobre o qual precisa-se armazenar ou recuperar informações. No modelo Entidade- Relacionamento é representado por um retângulo. Já o relacionamento é a forma como os objetos que compõem a realidade se relacionam. É representado por um losango, mas há um conceito importante a ser entendido que é a cardinalidade do relacionamento. Consiste de números cardinais colocados ao lado do nome do relacionamento e dimensiona o número de ocorrências de uma entidade que pode estar envolvido em um relacionamento, sendo útil para extrair daí regras de consistência e integridade dos dados. Existem 3 (três) tipos básicos de relacionamento entre as entidades de acordo com a cardinalidade: Um-para-um (1:1): representa que uma única ocorrência de uma entidade pode se relacionar com apenas uma única ocorrência de outra entidade; um-para-muitos (1:N): representa que uma ocorrência de uma entidade pode se relacionar com muitas ocorrências de outra entidade. No entanto, a recíproca não é verdadeira; muitos-para-muitos (N:M): representa que várias ocorrências de uma entidade pode se relacionar com muitas ocorrências de outra entidade. Página 30 de 120

32 Há ainda os relacionamentos recursivos onde uma entidade se relaciona com si própria e são relacionamentos mais raros. Para que o modelo E-R pudesse representar melhor os conceitos foi observado que cardinalidades genéricas do tipo 1:N (um-para-muitos) e N:M (muitos-para-muitos) não são sucientes. Isto porque o conceito de muitos é um conceito vago, podendo ser um ou qualquer número acima de um, existindo, ainda, o valor zero, pois, em alguns casos, nem todas as ocorrências das entidades participam do relacionamento. Para que isso seja resolvido, o modelo E-R propõe que seja utilizado o conceito de Cardinalidade Mínima e de Cardinalidade Máxima. Para um melhor entendimento das Cardinalidades Mínimas e Máximas, vamos analisar os tipos de relacionamento de cada uma das alternativas aplicadas ao problema do enunciado. Na letra (A), a cardinalidade do tipo (0,n) x (0,n) quer dizer o seguinte: uma pessoa pode lavar um, vários carros ou nenhum e um carro pode não ser lavado ou ser lavado por uma ou mais pessoas. Já na letra (B), uma pessoa pode lavar nenhum, um ou vários carros, mas um carro pode não ser lavado ou ser lavado por, no máximo, uma pessoa. A letra (C) indica que um carro deve ser levado por exatamente uma pessoa, mas que uma pessoa pode não ter lavado nenhum carro. Na letra (D), uma pessoa deve ter lavado, no mínimo, um carro e todo carro deve ter sido lavado por uma ou mais pessoas. E, para nalizar, na letra (E): um carro deve ter sido lavado por exatamente uma pessoa e uma pessoa deve ter lavado um ou mais carros. Ao passarmos um relacionamento para o modelo relacional, temos três opções: 1. Entidades relacionadas podem ser fundidas em uma única tabela; 2. tabelas podem ser criadas para o relacionamento; 3. chaves estrangeiras podem ser criadas em tabelas a m de representar adequadamente o relacionamento. Na letra (C), que é o único caso de mapeamento um-para-um, a melhor alternativa para atender a terceira forma normal é incluir a chave primária de Pessoa como chave estrangeira na tabela Carro (opção 3). Sendo assim, todo registro da tabela Carro terá representado uma pessoa, que será a pessoa que lava o carro. Caso o relacionamento fosse do tipo (1,1) x (1,1), uma tabela poderia representar as duas entidades sem problemas (opção 1). Neste caso, não haveria o problema de redundância indesejado para a terceira forma normal e nenhum dado seria perdido. Gerar uma tabela denitivamente não é uma opção para a letra (C), que está incorreta. Os relacionamentos muitos-para-muitos estão representados nas letras (A) e (D). Nestes casos, a única solução possível é utilizar uma tabela para o relacionamento (opção 2). Não é possível representar esse tipo de relacionamento através de uma chave-estrangeira em uma tabela que representa uma entidade e nem mesmo fundir tabelas de entidade sem que haja problemas de redundância. As alternativas (A) e (D) estão erradas, pois a tabela deve ser criada para o relacionamento e não é uma opção não tê-la. Na letra (E), a melhor alternativa é criar chave estrangeira para representar a pessoa que lavou o carro na tabela Carro (opção 3). Entretanto, ainda é necessário garantir que uma pessoa só exista na tabela Pessoa se já houver lavado um carro. Isso pode ser feito com inclusão de regra adicional de integridade. A opção 1 não é aceitável, pois representaria dados redundantes. A opção (2) também tem a possibilidade de representar um modelo relacional Página 31 de 120

33 que atenda o que a questão está pedindo e também deve ter adicionada a restrição de que toda pessoa da tabela Pessoa tenha um registro na tabela que representa o relacionamento Lava. Sem dúvida, é uma opção, mas não deve gerar uma tabela conforme diz o enunciado. A letra (E) está errada. Na alternativa (B), só o fato de não ser um relacionamento muitos-para-muitos, sabemos que o uso de tabela para representar o relacionamento Lava não é obrigatório. Há a possibilidade de se criar uma chave estrangeira que represente uma pessoa na tabela Carro (opção 3). Neste caso, a tabela Carro deve permitir que o valor da chave estrangeira também possa ser nulo, pois um carro não necessariamente é lavado por alguma pessoa. Há controvérsias se, neste caso, a terceira forma normal é obedecida. Se optássemos por criar uma tabela para o relacionamento, não haveria problemas, pois, para garantir que um carro seja lavado por no máximo uma pessoa, basta adotar a chave primária de Carro para garantir a unicidade do mesmo. A opção 1 não é adequada para o caso, pois as informações das pessoas iriam ser redundantes na nova tabela fundida. Embora haja a controvérsia de a permissão do uso de valor nulo não garantir a terceira forma normal e nem mesmo a primeiro, vamos adotar que o uso de chave estrangeira é factível para o problema e que o uso de tabela para o relacionamento também é possível. Sendo assim, a alternativa (B) é a alternativa correta. Página 32 de 120

34 14. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Modelo Relacional, Banca: Cespe Instituição: Petrobras Cargo: Analista de Sistemas Júnior - Infraestrutura Ano: 2007 Questão: 8082 Considerando que, nas tabelas acima, FK e PK sejam, respectivamente, chaves estrangeira e primária em um banco relacional, julgue os itens subseqüentes. 80 Se ALUNO em MATRICULAS referencia MATRICULA em ALUNOS, e TURMA em MATRICULAS referencia CODIGO em TURMAS, então a cada registro em ALUNOS podem estar associados vários registros em TURMAS e a cada registro em TURMAS podem estar associados vários registros em ALUNOS. 81 Se DEPARTAMENTO em CURSOS referencia CODIGO em DEPARTAMENTOS, então a cada registro em DEPARTAMENTOS podem estar associados vários registros em CURSOS e a cada registro em CURSOS podem estar associados vários registros em DEPARTAMENTOS. 82 Em um diagrama de entidades-relacionamentos do banco de dados composto pelas tabelas apresentadas, MATRICULAS será representada por uma classe de entidades e será muitos para muitos o relacionamento entre as classes de entidades que representem DISCIPLINAS e CURSOS. Solução: Os itens 80, 81 e 82 estão relacionados ao conceito de mapeamento de um esquema E-R (Entidade-Relacionamento) em tabelas no banco de dados no modelo relacional. Um banco de dados de acordo com o modelo E-R pode ser representado por uma coleção de tabelas. Para cada conjunto de entidades e para cada conjunto de relacionamentos, existe uma tabela única registrando o nome do conjunto de entidade ou relacionamento dentro de um banco de dados. Página 33 de 120

35 Para realizar a conversão da representação do banco de dados em um modelo E-R para um banco de dados relacional, as seguintes regras gerais devem ser seguidas: conjunto de entidades fortes: seja E um conjunto de entidades fortes descrito pelos atributos a1, a2,..., an. Representamos essa entidade por uma tabela E com n colunas distintas, cada uma delas correspondendo a um dos atributos de E; conjunto de entidades fracas: seja A um conjunto de entidades fracas com os atributos a1, a2,..., an. Seja B um conjunto de entidades fortes, do qual A é dependente. Representamos a entidade fraca por uma tabela A, onde as colunas dessa tabela são atributos da entidade A mais os atributos que formam a chave primária do conjunto B; relacionamentos: seja R um conjunto de relacionamentos; seja a1, a2,..., an o conjunto de atributos formados pela união das chaves primárias de cada conjunto de entidades participantes de R; e seja os atributos descritivos b1, b2,..., bn (se existir) de R. Representamos o conjunto R por uma tabela R, onde as colunas dessa tabela são as chaves primárias da entidades participantes mais os atributos descritivos de R, caso existam; atributos multivalorados: para um atributo multivalorado, criamos uma tabela T com uma coluna que corresponde ao atributo multivalorado e as colunas correspondentes à chave primária do conjunto de entidades ou conjunto de relacionamentos do qual o atributo multivalorado é atributo. No caso dos relacionamentos no modelo E-R, existem alguns tratamentos especiais em função da cardinalidade do relacionamento entre as entidades como forma de eliminar tabelas redundantes: um conjunto de relacionamentos que possuem cardinalidade um para um não precisa ser representado no modelo relacional, pois esse relacionamento não cria uma nova relação. Em geral, caso existam atributos descritivos do relacionamento, esses são acrescentados como atributos da tabela de uma das entidades participantes; um conjunto de relacionamentos que possuem cardinalidade muitos para um e não possui atributos descritivos não precisa ser representado por uma tabela no modelo relacional. Em geral, isso ocorre no relacionamento entre um conjunto de entidades fracas e um conjunto de entidades forte. A chave primária do conjunto de entidades fortes funciona como um atributo no conjunto de entidades fracas (chave estrangeira); um conjunto de relacionamentos que possuem cardinalidade muitos para muitos é representado no modelo relacional por uma tabela, pois esse relacionamento cria uma nova relação, conforme descrito anteriormente na regra geral. No nosso caso, em vez de partirmos do modelo E-R para o modelo relacional, temos que partir do modelo relacional para o modelo E-R para resolvermos os itens 80, 81 e 82. Em nosso modelo relacional temos as tabelas ALUNOS, MATRICULAS, TURMAS, DIS- CIPLINAS, CUROS e DEPARTAMENTOS. Por inferência nossa, acreditamos que as setas indicam o sentido do relacionamento entre as tabelas: ALUNOS está inscrito em CURSOS. Um aluno se inscreve em um curso, e em um curso pode estar inscrito vários alunos. Ou seja, temos um relacionamento um para muitos. Note que a tabela ALUNOS possui uma chave estrangeira CURSO, o que demonstram a relação de dependência entre as entidades ALUNOS e CURSOS. Neste relacionamento, CURSOS é uma entidade forte e ALUNOS é uma entidade fraca; Página 34 de 120

36 CURSOS é administrado por DEPARTAMENTOS. Um curso é administrado por departamento. Um curso é administrado por um departamento, e um departamento pode administrar vários cursos. Ou seja, temos um relacionamento um para muitos. Note que a tabela CURSOS possui uma chave estrangeira DEPARTAMENTO, o que demonstram a relação de dependência entre as entidades CURSOS e DEPARTAMEN- TOS. Neste relacionamento, CURSOS é uma entidade fraca e DEPARTAMENTOS é uma entidade forte; DISCIPLINAS está vinculada a CURSOS. Uma disciplina pode está vinculada somente a um curso ou mais de um curso, e um curso possui várias disciplinas. Note que neste relacionamento surge a dúvida se temos um relacionamento um para muitos ou muitos para muitos. Caso tivéssemos um relacionamento muitos para muitos, outra tabela representa o relacionamento entre CURSOS e DISCIPLINAS deveria existir no modelo relacional. Porém, não existe essa tabela, e portanto, o relacionamento entre CURSOS e DISCIPLINAS é um para muitos. Note que a tabela DISCIPLINAS possui uma chave estrangeira CURSO, o que demonstram a relação de dependência entre as entidades CURSOS e DISCIPLINAS. Neste relacionamento, CURSOS é uma entidade forte e DISCIPLINAS é uma entidade fraca; TURMAS está vinculada a DISCIPLINAS. Uma turma está vinculada a uma disciplina, e uma disciplina pode ter várias turmas. Ou seja, temos um relacionamento um para muitos. Note que a tabela TURMAS possui uma chave estrangeira DISCIPLINA, o que demonstram a relação de dependência entre as entidades TURMAS e DISCIPLINAS. Neste relacionamento, DISCIPLINAS é uma entidade forte e TURMAS é uma entidade fraca; ALUNOS está matriculado em TURMAS. Um aluno pode estar matriculado em diversas turmas, e uma turma pode ter vários alunos. Ou seja, temos um relacionamento muitos para muitos. Como temos esse tipo de relacionamento, devemos representá-lo no modelo relacional como uma tabela, no caso MATRICULAS. Observe que, a tabela MATRICULAS possui as chaves primárias de ALUNOS e CURSOS. De acordo com os relacionamentos descritos e as respectivas cardinalidade, podemos montar o nosso modelo E-R. A Figura 2 ilustra o modelo E-R obtido a partir do modelo relacional. Figura 2: Modelo Entidade-Relacionamento com base no modelo relacional. Página 35 de 120

37 A seguir analisamos os itens: 80 CERTO Conforme descrevemos anteriormente, o relacionamento entre ALUNOS e TURMAS é muitos para muitos, isto é, cada registro em ALUNOS pode estar associado a vários registros em TURMAS. Assim como, cada registro em TURMAS pode estar associado a vários registros em ALUNOS. A tabela MATRICULAS representa o relacionamento entre as entidades ALUNOS e TURMAS. Portanto, este item está certo. 81 ERRADO Conforme descrevemos anteriormente, o relacionamento entre CURSOS e DEPAR- TAMENTOS é um para muitos, isto é, um registro em CURSOS pode estar associado a um único registro em DEPARTAMENTO, e um registro em DEPARTAMENTOS pode estar associado a vários registros em CURSOS. Portanto, este item está errado, pois arma que cada registro em CURSOS pode estar associado a vários registros em DEPARTAMENTOS. 82 ERRADO Conforme mostrado no modelo E-R a partir do modelo relacional, a tabela MATRICU- LAS é representada como um relacionamento de ALUNOS e TURMAS no modelo E-R, e não como uma entidade. No caso do relacionamento entre DISCIPLINAS e CUR- SOS, o relacionamento não é muitos para muitos, mas um para muitos, pois no modelo relacional não existe uma tabela representando o relacionamento entre DISCIPLINAS e CURSOS. Portanto, este item está errado. Página 36 de 120

38 15. Assuntos relacionados: Banco de Dados, Modelagem de Dados, Superchave, Chave Secundária, Segurança da Informação, Criptograa, Chave Assimétrica, Chave Simétrica, Banca: ESAF Instituição: Agência Nacional de Águas (ANA) Cargo: Analista Administrativo - Tecnologia da Informação e Comunicação / Desenvolvimento de Sistemas e Administração de Banco de Dados Ano: 2009 Questão: 17 Um conjunto de um ou mais atributos, tomados coletivamente, para identicar unicamente uma tupla numa relação, é denominado (a). chave assimétrica. (b). chave simétrica. (c). superchave. (d). chave secundária. (e). chave de tupla. Solução: (A) INCORRETA Algoritmos que usam chaves assimétricas fazem parte da criptograa de chave pública. As chaves assimétricas são usadas para a criação de um par de chaves criptográcas relacionadas: uma chave pública e uma chave privada (secreta). Com o uso da criptograa de chave pública é possível vericar a autenticidade de mensagens, através da criação de assinaturas digitais e, também, proteger a condencialidade e integridade da mensagem, através da cifragem com o uso da chave pública e decifragem através da chave privada. O enunciado do problema se refere a bancos de dados relacionais, não a criptograa e, portanto, essa opção é incorreta. (B) INCORRETA Assim como as chaves assimétricas, chaves simétricas também são conceitos de criptograa. No entanto, nos algoritmos de criptograa de chave simétrica, chaves semelhantes, normalmente idênticas, são usadas para cifrar e decifrar uma mensagem, donde decorre o nome simétrica. (C) CORRETA Uma superchave é qualquer subconjunto de atributos de um esquema de relação com a propriedade de que duas tuplas, em qualquer estado de relação r de R, não tenham a mesma combinação de valores para esse subconjunto de atributos. Em outras palavras, sejam e tuplas distintas e seja SK um subconjunto de atributos de um esquema de relação. Neste caso, para quaisquer e. Note, ainda, que toda relação possui ao menos uma superchave: a padrão (default), o conjunto de todos os atributos da relação. Superchaves mais úteis, no entanto, são as superchaves mínimas. Nelas, não há atributos redundantes. Ou seja, não é possível remover qualquer atributo desse conjunto sem quebrar a restrição da superchave identicar tuplas distintas. Página 37 de 120

39 (D) INCORRETA Uma chave secundária é uma chave que, normalmente, não identica unicamente um registro e que pode ser utilizada para buscas simultâneas de vários registros. Normalmente implementadas como índices em bancos de dados, são usadas para busca e recuperação de dados. (E) INCORRETA O conceito chave de tupla não é amplamente conhecido na literatura e há outra alternativa que responde de maneira correta esta questão. Por esse motivo, esse conceito não será discutido. Página 38 de 120

40 16. Assuntos relacionados: Banco de Dados, Modelo Relacional, Modelo Entidade-Relacionamento, Modelo Objeto-Relacionamento, Banca: ESAF Instituição: Agência Nacional de Águas (ANA) Cargo: Analista Administrativo - Tecnologia da Informação e Comunicação / Desenvolvimento de Sistemas e Administração de Banco de Dados Ano: 2009 Questão: 22 O modelo de dados baseado numa coleção de tabelas que representam dados e as relações entre eles é denominado modelo (a). relacional. (b). entidade/relacionamento. (c). baseado em objetos. (d). de dados semiestruturados. (e). objeto/relacionamento. Solução: (A) CORRETA O modelo relacional usa o conceito de uma relação matemática como seu bloco de construção básica e tem sua base teórica na teoria dos conjuntos e na lógica de predicados de primeira ordem. No modelo relacional, o banco de dados é representado como uma coleção de relações. Quando uma relação é pensada como uma tabela de valores, cada linha na tabela representa uma coleção de valores de dados relacionados. Nessa representação, cada linha na tabela representa um fato que corresponde a uma entidade ou relacionamento do mundo real. O nome da tabela e os nomes das colunas são usados para auxiliar na interpretação dos dados da coluna e todos os valores em uma coluna são do mesmo tipo de dado. Por isso, essa é a solução correta para a questão. (B) INCORRETA O modelo de entidade-relacionamento é um modelo abstrato com a nalidade de descrever, conceitualmente, as entidades e os relacionamentos de um domínio. Esse modelo, e suas variações, é normalmente empregado para o projeto conceitual de aplicações de um banco de dados, e muitas ferramentas de projeto de um banco de dados também aplicam seus conceitos. Neste modelo, uma entidade é um objeto que existe no mundo e que é facilmente distinguível de outros. Uma entidade pode ser tanto concreta, como um livro, uma pessoa ou um lugar, quanto abstrata, como um feriado. Uma entidade, por sua vez, é composta por atributos. Um atributo é uma função que mapeia um conjunto de entidades em um domínio em particular. Cada entidade é descrita por um conjunto de pares (atributo, valor) e existe um par para cada um dos atributos da entidade. Um relacionamento, por sua vez, é uma associação qualquer entre diversas entidades. Um Página 39 de 120

41 relacionamento trabalha para, por exemplo, pode relacionar empregador e empregados. A principal ferramenta do modelo de entidade-relacionamento é o diagrama de entidaderelacionamento. Nele, retângulos representam entidades, elipses representam atributos, losangos representam relacionamentos e linhas ligam atributos a entidades e entidades a relacionamentos. A Figura 3 exibe um exemplo de diagrama entidade-relacionamento. Nela, existem duas entidades, Cliente e Conta. A entidade Cliente possui os atributos Nome, Endereço e CPF, já a entidade Conta possui os atributos Número e Balanço. Ambas são relacionadas pela relação Possui, que indica que um ou mais clientes podem possuir uma ou mais contas (que, por sua vez, podem ser possuídas por um ou mais clientes). (C) INCORRETA Figura 3: exemplo de diagrama entidade-relacionamento. Modelos baseados em objetos têm sua origem nas linguagens orientadas a objetos. Nelas, um objeto possui, tipicamente, dois componentes: estado (valor) e comportamento (operações). Em linguagens de programação, objetos existem somente durante a execução do programa. Já em bancos de dados orientados a objetos, a existência dos objetos pode ser estendida de modo que sejam armazenados de forma permanente; portanto, os objetos continuam a existir mesmo após o término do programa, podendo ser posteriormente recuperados e compartilhados por outros programas. No modelo orientado a objetos, um conceito comum é o de classe, que representa um conjunto de objetos com características ans e dene o comportamento dos objetos através de seus métodos, e quais estados ele é capaz de manter através de seus atributos. Alguns conceitos importantes em orientação a objetos são: Encapsulamento: os aspectos internos e externos de um objeto são separados, impedindo o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente apenas métodos que alteram esses estados; Herança: permite a especicação de novos tipos ou classes que herdam parte de suas estruturas e/ou operações de classes ou tipos previamente denidos, o que torna mais fácil desenvolver os tipos de dados de um sistema de modo incremental e reutilizar denições de tipos na criação de novos tipos de objetos; Sobrecarga de operador: se refere à propriedade de uma operação de ser aplicada a diferentes tipos de objetos. Em tal situação, um nome de operação pode se referir a várias implementações diferentes, dependendo do tipo de objetos aos quais é aplicada. Essa característica também é conhecida como polimorsmo de operador. Página 40 de 120

42 Em bancos de dados tradicionais, a informação sobre objetos complexos é, normalmente, distribuída em várias relações ou registros, levando à perda de correspondência direta entre um objeto do mundo real e sua representação no banco de dados. O mesmo não ocorre em bancos de dados orientados a objetos, que são capazes de manter estruturas de objetos com complexidade arbitrária. (D) INCORRETA O modelo de dados semiestruturados é um modelo de bancos de dados em que não há separação entre dados e esquema e sua estruturação depende do propósito da aplicação. Por não haver essa separação, o esquema é normalmente associado em conjunto com os dados. Em outros casos, o esquema existe apenas para denir restrições fracas aos dados. Um compromisso feito quando bancos de dados que usam esse modelo são adotados é que as consultas podem não ser tão ecientes quanto a alternativa em bancos de dados relacionais, devido à forma típica como esses bancos de dados são implementados. Neles, os registros são normalmente armazenados com identicadores únicos referenciados por ponteiros para suas posições no disco. Como é necessário percorrer o disco seguindo os ponteiros, suas consultas podem não ser tão ecientes. (E) INCORRETA O modelo objeto-relacionamento (OR) é baseado no modelo de entidade-relacionamento (ER). No modelo OR, o mundo é visto como um conjunto de objetos e seus relacionamentos. A diferença entre esse e o modelo de ER é que no modelo OR os atributos são tratados como objetos e, com isso, os benefícios da orientação a objetos são unidos aos benefícios do modelo relacional (ambos modelos descritos acima). Essa resposta é incorreta porque o modelo objeto-relacional é usado para modelagem de sistemas de bancos de dados, não para representar os dados. Fonte: Symposium on Applied Computing Proceedings of the 1992 ACM/SIGAPP Symposium on Applied computing: technological challenges of the 1990's table of contents Kansas City, Missouri, United States Páginas: Ano de publicação: 1992 ISBN: X Disponível em: Página 41 de 120

43 17. Assuntos relacionados: Banco de Dados, Álgebra Relacional, SGBD, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 56 Sobre bancos de dados relacionais é INCORRETO armar que (a). fornecem outra tabela, como resultado de consulta a uma tabela. (b). possuem um otimizador que é responsável por implementar de forma eciente as consultas relacionais realizadas pelo usuário. (c). armazenam dados organizados logicamente em tabelas e sicamente em arquivos. (d). disponibilizam estruturas para manutenção de integridade dos dados. (e). permitem a realização de operações de junção e união de conjuntos, mas não de projeção e restrição. Solução: Em bancos de dados relacionais as tabelas são estruturas lógicas que têm por objetivo simplicar a modelagem e a visualização dos dados, que sicamente são armazenados como arquivos. O diagrama de tabelas é um nível de abstração de dados também conhecido como modelo lógico de dados. Independente do formato dos arquivos e dos métodos de acesso utilizados, o usuário - nal sempre enxerga os dados organizados em tabelas. Quando uma consulta é submetida ao SGBD relacional, pode ser necessário unir dados de vários arquivos para fornecer o resultado. No entanto, o usuário nal não precisa tomar conhecimento dessa necessidade, pois o resultado da consulta será fornecido como uma tabela, essa montada dinamicamente de acordo com os critérios da operação. A otimização das consultas, assim como a manutenção da integridade dos dados, é papel do SGBD. Como atribuições dos SGBDs, podemos citar também a manutenção da segurança e o controle de concorrência, permitindo que vários usuários ou processos usem o banco de dados simultaneamente sem prejuízo aos dados. Em grande parte dos sistemas, os projetistas não precisam se preocupar com aspectos físicos do armazenamento de dados. Geralmente, isso se faz necessário quando o otimizador de consultas do SGBD por si só não é suciente para responder aos requisitos de desempenho do sistema. Com base nos argumentos apresentados, podemos dizer que as alternativas A, B, C e D apresentam informações corretas sobre os SGBDs relacionais. Portanto, por eliminação chegamos à alternativa E. A resposta também pode ser alcançada de forma direta, sendo necessário para isso o conhecimento das operações básicas da Álgebra Relacional, base conceitual dos bancos e da linguagem de SQL. As operações de junção nada mais são que as realizadas pelo operador JOIN, da linguagem SQL. Enquanto as operações de união são realizadas pelo operador UNION. As restrições são denidas pela cláusula WHERE. Página 42 de 120

44 Já as projeções se referem a seleção de um subconjunto N de colunas, onde N é menor que o número total de colunas da relação. Ou seja, se tabela ALUNOS possui 5 colunas, o comando SELECT NOME,IDADE FROM ALUNOS é uma projeção, pois só foram selecionadas 2 das 5 colunas na consulta. Página 43 de 120

45 18. Assuntos relacionados: Banco de Dados, Nível de Abstração, Nível Físco, Nível de Visão, Nível Lógico, Banca: ESAF Instituição: Agência Nacional de Águas (ANA) Cargo: Analista Administrativo - Tecnologia da Informação e Comunicação / Desenvolvimento de Sistemas e Administração de Banco de Dados Ano: 2009 Questão: 18 O nível de abstração, que visa simplicar a interação entre usuários e o sistema de banco de dados, é o (a). físico. (b). de visão. (c). lógico. (d). de esquema. (e). de modelo. Solução: Um sistema de banco de dados é a junção de uma coleção de arquivos inter-relacionados com um conjunto de programas que permitem aos usuários acessarem e modicarem tais arquivos. Seu maior objetivo é proporcionar aos usuários uma visão abstrata dos dados, o que signica ocultar determinados detalhes de como os dados são efetivamente armazenados e gerenciados. Para que o sistema tenha um bom nível de usabilidade, é preciso que os dados sejam recuperados ecientemente. A necessidade de eciência levou os desenvolvedores a utilizar estruturas de dados complexas para representar os dados na base de dados. Para ocultar dos usuários essa complexidade, níveis de abstração foram denidos, simplicando a interação com o sistema: Nível Físico. Nível mais baixo de abstração que descreve como os dados são verdadeiramente armazenados. O nível físico descreve detalhadamente as complexas estruturas de dados de baixo nível; Nível Lógico. Nível intermediário de abstração que descreve quais dados são armazenados na base de dados, além dos relacionamentos existentes entre tais dados. Neste nível, todo o banco de dados é descrito em termos de um pequeno número de estruturas relativamente simples. Os administradores de bancos de dados usam os nível lógico de abstração para decidir quais informações serão armazenadas; Nível de Visão. Nível mais alto de abstração, descreve apenas parte do banco de dados. Apesar de utilizar estruturas simples, o nível lógico possui bastante complexidade, haja vista a variedade de informações armazenadas. Muitos usuários não necessitam de toda essa informação e, assim, o nível de visão proporciona diversas visões para a mesma base de dados, simplicando a interação com o sistema. O esquema de um banco de dados diz respeito aos objetos (tabelas, visões, índices, procedimentos armazenados, etc.) disponibilizados para um determinado grupo de usuários, não guardando relação com os níveis de abstração. Semelhantemente, o modelo de um banco de dados é a especicação das estruturas de dados e regras de negócio de um banco de dados, Página 44 de 120

46 incluindo Modelo Conceitual, Modelo Lógico e Modelo Físico. A armativa de acordo com a teoria apresentada encontra-se na opção B. Página 45 de 120

47 19. Assuntos relacionados: Banco de Dados, Indexação de Registros, Banca: ESAF Instituição: Secretaria do Tesouro Nacional (STN) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 17 Em termos de Bancos de Dados, a indexação mais adequada para o acesso eciente aos registros, em consultas que considerem intervalos, para um pequeno número de linhas, corresponde ao uso de índices (a). de junção. (b). de hashing. (c). em árvores B. (d). booleanos. (e). funcionais. Solução: (A) INCORRETA Um índice de junção é uma estrutura de dados usada para o processamento de consultas de junção (join queries) em bancos de dados. Os índices de junção usam técnicas de pré-computação para aumentar o desempenho do processamento online de consultas e são úteis para conjuntos de dados que são atualizados com pouca frequência. Como essa opção apresenta uma restrição aos bancos de dados (e como há uma opção melhor, como será visto), essa alternativa é incorreta. 1 (B) INCORRETA Índices de hashing são índices que usam tabelas hash para indexação. Neles, as chaves de pesquisa são organizadas como uma tabela hash, em que as chaves de pesquisa são associadas às entradas onde essas chaves ocorrem. Uma tabela hash (ou tabela de dispersão), por sua vez, é uma estrutura de dados que associa chaves de pesquisa a valores. Seu objetivo é, a partir de uma chave simples, fazer uma busca rápida e obter o valor desejado. Por mapearem uma chave de pesquisa a um determinado índice de forma direta, as tabelas hash proporcionam um tempo médio de busca constante, ou seja, O(1). Em virtude de seu alto desempenho, as tabelas hash são tipicamente utilizadas na indexação de grandes volumes de informações em bancos de dados e na criação de esquemas associativos de acesso às memória cache. Após a construção do índice, quando uma consulta é realizada, a função hash é aplicada à chave de pesquisa para identicação do slot onde as chaves ocorrem. As entradas das ocorrências são, então, recuperadas. Apesar de ecientes para buscar um único valor e como valores próximos são normalmente mapeados para posições distantes na tabela, uma abordagem de tabelas hash para consultas 1 Fonte: Ecient Join-Index-Based Join Processing: A Clustering Approach, disponível em Página 46 de 120

48 com intervalos se mostrará ineciente, visto que a conferência dos valores nos intervalos será custosa. (C) CORRETA Índices em árvores B, como o nome diz, são índices que usam árvores B. Uma árvore B é uma estrutura de dados baseada em árvores que mantém os dados ordenados e que permite buscas, acesso sequencial, inserções e remoções em tempo logarítmico amortizado. Por ser otimizada para sistemas que leem e escrevem grandes quantidades de dados, elas são bastante utilizadas na implementação de bancos de dados e sistemas de arquivos. As árvores B são uma generalização das árvores de busca binárias, pois cada nó pode possuir mais de dois lhos. Mais formalmente, uma árvore B de ordem m (com m o número máximo de lhos de um nó) é uma árvore que satisfaz as seguintes propriedades: 1. Cada nó possui, no máximo, m lhos; 2. Cada nó (exceto a raiz), possui, no mínimo, m/2 lhos; 3. A raiz possui pelo menos dois lhos quando não for um nó folha; 4. Todas as folhas aparecem no mesmo nível; 5. Um nó não folha com k lhos possui k-1 chaves. Como exemplo, a Figura 4 exibe o desenvolvimento de uma árvore B de ordem 3 à medida que os elementos 1, 2, 3, 4, 5, 6 e 7 são adicionados a ela. Como exibido, sempre que um nó não é capaz de armazenar mais elementos, aquele nó é dividido e a árvore, rebalanceada, de modo que suas propriedades ainda sejam mantidas. A altura de uma árvore B é, sempre, O(log n) e uma busca por um valor exato em uma árvore B é, também, O(log n). No entanto, quando é necessário buscar por um intervalo, como, internamente os nós das árvores B estão ordenados e a busca pelos limites é O(log n), a recuperação dos valores do intervalo buscado é feita rapidamente, tornando as árvores B a melhor estrutura de dados para criação do índice nesse caso e, portanto, a alternativa c é a correta. (D) INCORRETA Índice booleano não é um conceito amplamente divulgado na literatura. No entanto, existem índices chamados índices bitmap que armazenam seus dados como vetores de bits e respondem a consultas através da execução de operações lógicas bit a bit nesses vetores de bits. Esse tipo de índice foi projetado para casos em que os valores de uma variável se repetem com grande frequência. Devido a forma como são construídos, o índice de bitmap possui vantagens de desempenho para esse caso, mas não na busca de intervalos. (E) INCORRETA Índices funcionais são índices denidos pelo usuário do sistema de banco de dados. Com eles, é possível que o usuário do banco de dados dena suas próprias funções de indexação. Esse tipo de índice adiciona exibilidade ao banco de dados e pode ser usado com tipos denidos pelo usuário. Por poderem ser implementados da forma que melhor convier ao usuário e não um algoritmo propriamente dito, índices funcionais não são a solução para esta questão. Página 47 de 120

49 Figura 4: desenvolvimento de uma árvore B de ordem 3 à medida que os elementos 1, 2, 3, 4, 5, 6 e 7 são adicionados. Página 48 de 120

50 20. Assuntos relacionados: Banco de Dados, ACID, Banca: ESAF Instituição: Controladoria-Geral da União (CGU) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 54 O termo integridade se refere à precisão ou correção de dados. Em um banco de dados relacional, as restrições de integridade têm importância crucial, pois fornecem uma forma de garantir que as mudanças realizadas pelos usuários não resultem na perda de consistência dos dados. Com relação às restrições de integridade, é incorreto armar que uma restrição de (a). variável de relação especica os valores válidos para uma determinada variável de relação, e é vericada quando essa variável de relação é atualizada. (b). tipo especica os valores válidos para um determinado tipo, e é vericada durante invocações do seletor correspondente. (c). atributo especica os valores válidos para um determinado atributo, e nunca deve ser violada. (d). banco de dados especica os valores válidos para um determinado banco de dados, e é vericada no instante de COMMIT. (e). domínio especica que o valor de um atributo não pode pertencer a mais de um domínio. Solução: Autores diferentes costumam classicar as restrições de integridade de forma diferente. Em [1], por exemplo, as restrições de integridade são classicadas como restrições de tipo (domínio), de atributo, de variáveis de relação, de banco de dados, de transição de estados, de chaves, de integridade referencial e restrições quanto ao momento de vericação. Em [2] as encontramos como restrições de domínio, de chave, de formas de relacionamento e de integridade referencial. Já em [3] elas são classicadas como restrições de domínio, de chave, de integridade referencial, de integridade de entidade e não-nulo. Para a elaboração desta questão, há indícios de que as denições encontradas em [1] foram usadas. Nela, o conceito apresentado de maneira incorreta é o descrito na alternativa e, dado que a descrição apresentada dene, de maneira errônea, o que é uma restrição de domínio. Uma restrição de domínio é uma restrição que especica que, dentro de cada tupla do banco de dados relacional, o valor de cada atributo A deve ser um valor pertencente ao domínio de A. Em outras palavras, uma restrição de domínio testa os valores inseridos no banco de dados e as consultas realizadas para garantir que os valores inseridos sejam condizentes com os domínios das variáveis armazenadas. O domínio de um atributo envolve seu tipo de dados, o intervalo de valores possível que esse atributo pode possuir, seu tamanho máximo, e se existe a possibilidade de valores nulos em A. Os tipos de dados associados aos domínios incluem os tipos de dados numéricos padrão (como inteiros e números reais de representados por ponto utuante), caracteres, booleanos, Página 49 de 120

51 strings de comprimento xo e variável, data, hora, timestamp e, em alguns casos, moeda. É possível, também, como citado, especicar subconjuntos de valores de um tipo de dado ou por uma enumeração de valores. Um domínio, por sua vez, é um conjunto de valores atômicos. Por atômico entendemos que cada valor no domínio é indivisível no que diz respeito ao modelo relacional. Um método comum para a especicação de um domínio é denir um tipo de dados do qual os valores de dados que formam o domínio sejam retirados. Também é útil especicar um nome para esse domínio, de modo a ajudar na interpretação de seus valores. Alguns exemplos de domínio são (com o nome do domínio à esquerda e sua descrição à direita): Número de CPF: o conjunto de onze dígitos válidos do número de CPF; Média de pontos: possíveis valores de médias computadas para um determinado aluno. As médias devem ser não-negativas e inferiores à média máxima atingível. Em SQL é possível criar um domínio através do comando CREATE DOMAIN. No exemplo abaixo, é exibido um comando para a criação do domínio NUMERO_CPF em SQL: CREATE DOMAIN NUMERO_CPF AS CHAR(11); Esclarecimentos sobre as outras Alternativas Apesar de sabermos que as outras alternativas estão corretas, convém fazer comentários adicionais sobre cada uma delas para melhor compreensão dos conceitos. Restrição de variável de relação A restrição de variável de relação, ou de tuplas, é uma restrição sobre uma tupla individual e pode incorporar restrições sobre atributos da mesma. Como essa restrição é vericada sempre que a variável de relação é atualizada, é possível adicionar restrições como um aluno somente poder ter estado de formado caso tenha cumprido o número mínimo de créditos de um curso. Restrição de tipo Uma restrição de tipo, como o nome diz, especica que um atributo deva pertencer ao tipo especicado e, portanto, a suas restrições. Restrição de atributo Uma restrição de atributo, como descrito no enunciado da questão, descreve os possíveis valores válidos que o atributo deve assumir. Um exemplo é que o atributo SEXO só faça sentido para os valores F (feminino) e M (masculino). Restrição de banco de dados Uma restrição de banco de dados é uma restrição que relaciona duas ou mais tuplas distintas e, portanto, é necessário que todas as restrições das tuplas envolvidas sejam atendidas. Um exemplo desse tipo de restrição é um pedido em uma loja virtual: o somatório das quantidades de todos os itens não pode ser maior que a quantidade total de elementos do pedido. Página 50 de 120

52 Referências [1] Introdução a Sistemas de Banco de Dados, C. J. Date. 7a edição. [2] Sistemas de Banco de Dados, A. Silberchatz et al. 3a edição. [3] Sistemas de Banco de Dados, Ramez Elmasri e Shamkant B. Navathe. 4a edição. Página 51 de 120

53 21. Assuntos relacionados: Banco de Dados, ACID, Banca: ESAF Instituição: Secretaria do Tesouro Nacional (STN) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 14 Se uma restrição de integridade, classicada como restrição de banco de dados, ocorrer no momento de um COMMIT de uma transação, imediatamente é executado um (a). DROP. (b). ROLLBACK. (c). BEGIN_TRANSACTION. (d). END_TRANSACTION. (e). LOCKING. Solução: A integridade é a qualidade de garantir que os dados em um banco de dados estejam corretos. Geralmente, as restrições de integridade são denições de valores permitidos de serem atribuídos a determinadas variáveis. No momento de uma inserção de dados, ou mesmo de uma atualização em dados já existentes, as restrições de integridade devem ser respeitadas e, para tanto, vericações são efetuadas antes da inserção/atualização serem concretizadas. A questão natural que surge é o momento da vericação e da consequente execução da operação solicitada (inserção/atualização). A concorrência de operações em um banco de dados, isto é, a execução simultânea de operações sobre uma mesma parte da base de dados disponível, é situação corriqueira a ser tratada por SGBDs (Sistemas de Gerenciamento de Banco de Dados). Essa concorrência sobre a base de dados, se mal gerenciada, pode provocar inconsistências nos dados alterados. Neste contexto, o conceito de transação surge como uma opção de solução ao problema da manutenção da integridade face a concorrência de operações. A transação, isto é, um conjunto de operações sobre uma base de dados, deve possuir 4 características essenciais com o intuito de auxiliar a garantia da integridade dos dados. Uma transação deve ser atômica, ou seja, todas as operações (ou comandos) que a compõem são executadas de uma maneira única (todas as operações são executadas com sucesso ou nenhuma delas é executada). Uma transação deve ser isolada de outras transações e, consequentemente, ser executada de forma independente das demais. Além disso, toda transação precisa ser durável, característica que garante a manutenção das alterações decorrentes de uma transação concluída, mesmo que ocorra alguma falha após essa conclusão (inclusive de fornecimento de energia elétrica). E, por m, mas não com menos importância, uma transação deve ser consistente, ou seja, deve fornecer a garantia de consistência dos dados em relação a um conjunto de regras de negócio previamente estabelecidas. Para uma adequada execução, operações de controle sobre as transações são utilizadas. São elas: BEGIN_TRANSACTION: sinaliza o início da execução de uma transação; Página 52 de 120

54 END_TRANSACTION: determina o término das operações de uma transação. Contudo, a partir deste ponto é necessário vericar se as modicações introduzidas pela transação podem ser permanentemente aplicadas à base de dados (comando COMMIT) ou se a transação deve ser abortada (comando ROLLBACK) devido a algum problema ocorrido; COMMIT (ou COMMIT_TRANSACTION): indica o término da transação com sucesso, isto é, todas as alterações na base de dados foram executadas e não serão desfeitas; ROLLBACK (ou ABORT): sinaliza que a transação terminou sem sucesso e nenhuma modicação na base de dados foi efetuada. Nas opções de resposta fornecidas na questão, os itens b), c) e d) citam operações de transações dentre as quais encontra-se a operação ROLLBACK, resposta para a pergunta, conforme a teoria explanada até aqui. Mesmo de posse da resposta, cabe um comentário sobre os outros dois termos citados dentre as opções de resposta: DROP e LOCKING. O comando DROP faz parte da DDL (Data Denition Language) de um banco de dados, sendo responsável por apagar itens do catálogo do banco em conjunto com outras diretivas, como pode ser observado, por exemplo, no comando DROP TABLE que serve para apagar uma tabela do banco de dados, ou ainda no comando DROP DATABASE que serve para apagar o próprio banco de dados. LOCKING (ou congelamento) é um mecanismo presente em SGBDs para tentar garantir o controle de concorrência. Nada mais é do que a ação, tomada mediante uma transação, de indisponibilizar temporariamente parte da base de dados para as demais transações. É uma atitude que deve ser evitada por propiciar a ocorrência de deadlocks, isto é, impasses gerados por várias transações que disputam recursos e acabam provocando uma dependência circular, sem conseguirem atingirem o nal de suas execuções. Página 53 de 120

55 22. Assuntos relacionados: Banco de Dados, Categorias de Linguages de Banco de Dados, Data Denition Language (DDL), Data Manipulation Language (DML), Data Control Language (DCL), Data Query Language (DQL), Transaction Control Language (TCL), SQL, Banca: ESAF Instituição: Secretaria do Tesouro Nacional (STN) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 11 Um SBGD (Sistema Gerenciador de Bancos de Dados) possui um compilador para uma determinada linguagem, cuja função é o processamento de declarações, a m de identicar as descrições dos componentes do esquema conceitual do Banco de Dados. Tal linguagem é de (a). consulta estrutura (SQL). (b). denição de armazenamento (SDL). (c). manipulação de dados (DML). (d). denição de visão (VDL). (e). denição de dados (DDL). Solução: Os sistemas gerenciadores de bancos de dados utilizam diferentes linguagens para denir e manipular o banco de dados, além de realizar outras atividades. Tais linguagens podem ser classicadas diversas categorias, entre as quais as mais populares são: DDL (Data Denition Language) ou (Linguagem de Denição de Dados); DML (Data Manipulation Language) ou (Linguagem de Manipulação de Dados); DCL (Data Control Language) ou (Linguagem de Controle de Dados); DQL (Data Query Language) ou (Linguagem de Consulta de Dados); TCL (Transaction Control Language) ou (Linguagem de Controle de Transações). Para denir e exemplicar cada uma das categorias, vamos nos ater aos bancos de dados relacionais, pois são estes os mais populares e cobrados em provas de concursos. No entanto, vale ressaltar que estas e outras categorias de linguagens de SGBDs existem para as demais tecnologias de bancos de dados, como a hierárquica, a de rede, a orientada a objetos etc. DDL (Data Defnition Language) Em termos conceituais, a DDL contém o conjunto de comandos utilizados para descrever e criar a estrutura do banco de dados. Os comandos que compõe a DDL são os que permitem criar novas tabelas, views, índices, e outros elementos de dados. Exemplos típicos de comandos DDL são mostrados a seguir. CREATE TABLE (Cria uma tabela) DROP TABLE (Exlui uma tabela) ALTER TABLE ADD COLUMN (Adiciona uma coluna a uma tabela) CREATE INDEX (Cria um índice) ALTER INDEX (Altera um índice) CREATE VIEW (Cria uma view) Página 54 de 120

56 DML (Data Manipulation Language) A DML contém o conjunto de comandos utilizados para manipular os dados, o que deve ser entendido como a criação de novos registros nas tabelas, além da atualização e da exclusão de registros já existentes. Os comandos que compõe a DML são, basicamente, os seguintes. INSERT (Cria um novo registro de dados) UPDATE (Atualiza um registro de dados) DELETE (Exclui um registro de dados) DCL (Data Control Language) Os comandos que compõe a DCL têm por nalidade, basicamente, permitir o controle de aspectos não funcionais do banco de dados, como a segurança dos dados. São os comandos DCL que permitem a criação e exclusão de usuários, a criação de pers de acesso, a alteração de senhas, e as operações de concessão e revogação de acesso aos diversos elementos de dados. Exemplos típicos de comandos DCL são mostrados a seguir. GRANT (Autoriza ao usuário executar uma operação sobre algum elemento de dado) REVOKE (Revoga do usuário o direito de executar uma operação) ALTER PASSWORD (Altera a senha de um usuário) CREATE ROLE (Cria um perfil de acesso) DQL (Data Query Language) A DQL é formada pelo conjunto de comandos e operadores que permitem a realização de consultas no banco de dados. No âmbito dos bancos de dados relacionais, o único comando DQL é o SELECT. No entanto, a DQL engloba uma vasta quantidade de cláusulas e operadores, que permite consultar o banco de dados de inúmeras formas. As principais cláusulas da DQL são as seguintes: FROM (Utilizada para especificar a tabela que se vai selecionar os registros) WHERE (Utilizada para especificar as condições que devem reunir os registros que serão selecionados) GROUP BY (Utilizada para separar os registros selecionados em grupos específicos) HAVING (Expressar a condição que deve ser satisfeita por cada grupo selecionado) ORDER BY (Ordena os registros selecionados) DISTINCT (Selecionar dados sem repetição) Com relação aos operadores lógicos e de comparação, merecem destaque os seguintes: AND (E lógico) OR (OU lógico) NOT (Negação lógica) < (Menor que) > (Maior que) <> (Diferente de) <= (Menor ou Igual que) >= (Maior ou Igual que) = (Igual a) BETWEEN (Utilizado para especificar um intervalo de valores) LIKE (Utilizado na comparação de padrões de cadeias de caracteres) Página 55 de 120

57 Por m, merecem destaque as funções de agregação, que adicionam à DQL a capacidade de agregar os resultados de uma consulta em um único valor. As principais funções de agregação são as seguintes: AVG (Calcula a média dos valores de um campo determinado) COUNT (Calcula o número de registros da seleção) SUM (Calcula a soma de todos os valores de um campo determinado) MAX (Calcula o valor mais alto de um campo determinado) MIN (Calcula o menor valor de um campo determinado) TCL (Transaction Control Language) Finalizando as categorias de linguagens, temos a TCL, cujos comandos permitem controlar a execução das transações em um SGBD. Os comandos TCL mais comuns são os seguintes: BEGIN TRANSACTION (Define o início de uma transação de banco de dados) COMMIT (Confirma todas as mudanças permanentemente) ROLLBACK (Descarta todas as mudanças nos dados desde que o último COMMIT) SET TRANSACTION (Modifica opções da transação, como o nível de isolamento) Diante de toda a teoria exposta, podemos armar que a resposta da questão é a alternativa E DDL (Data Denition Language). Página 56 de 120

58 23. Assuntos relacionados: SGBD, Otimizador de Consultas, Data Manipulation Language (DML), Data Denition Language (DDL), Banca: ESAF Instituição: Secretaria do Tesouro Nacional (STN) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 13 Em um SGBD (Sistema Gerenciador de Bancos de Dados), as requisições de manipulação de dados são processadas por um componente capaz de determinar uma maneira eciente de implementá-las. Tal componente é o (a). processador da linguagem de manipulação de dados (DML). (b). gerenciador tem tempo de execução. (c). otimizador. (d). processador da linguagem de denição de dados (DDL). (e). esquema físico. Solução: Um Sistema Gerenciador de Bancos de Dados (SGBD) é composto por vários módulos, com atribuições especícas. A Linguagem de Denição de Dados (DDL Data Denition Language), responsável por construções declarativas dos objetos da base de dados, precisa de um processador de DDL (ou compilador) que lhe interprete os comandos. Tal compilador processa as denições de esquema, especicados na DDL, e armazena descrições dos esquemas (meta-dados) no catálogo do SGBD. Da mesma forma, a Linguagem de Manipulação de Dados (DML Data Manipulation Language), que permite o processamento ou manipulação dos dados armazenados, faz uso de um processador de DML dedicado à tarefa de compilar os comandos DML em códigos-objeto para acesso à base de dados. Essas requisições de acesso são gerenciadas pelo processador da base de dados em tempo de execução (runtime database processor), que recebe as operações de atualização ou obtenção de dados e, quando necessário, transporta tais dados para fora do banco de dados, em atendimento às consultas efetuadas. Um consulta expressa em uma linguagem de alto-nível, como a linguagem SQL, deve primeiramente ser escaneada, parseada e validada. O processo de escaneamento identica os tokens da linguagem no texto da consulta, ao passo que o parser verica a sintaxe da pesquisa para determinar se houve uma formulação segundo as regras gramaticais impostas. A etapa de validação verica se os atributos e relações presentes na consulta são válidos e se fazem sentido semanticamente face ao esquema do banco de dados. Em seguida, uma estratégia de execução para recuperação do resultado da consulta precisa ser denida. Geralmente, uma consulta possui diversas estratégias de execução. O módulo otimizador de consultas é responsável por elaborar um plano de execução mais adequado para obter o resultado desejado da forma mais eciente possível. As quatro primeiras alternativas apresentadas como possíveis respostas à questão apresentam elementos que constituem um SGBD, sendo que o item c) exibe a resposta correta, conforme à teoria explanada. A alternativa e) exibe não um elemento de SGBD, mas sim um componente da arquitetura de um banco de dados baseada em três esquemas: esquema Página 57 de 120

59 físico (ou esquema interno, ou nível interno), esquema conceitual (ou nível conceitual) e esquema(s) externo(s) (ou nível de visão). O objetivo dessa arquitetura em três esquemas é separar as aplicações de usuário da estrutura física do banco de dados. Página 58 de 120

60 24. Assuntos relacionados: Bancos de Dados Distribuídos, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 68 A fragmentação de dados utilizada em um banco de dados distribuído tem como objetivo dividir as informações de uma determinada relação R. Sobre essa fragmentação de dados, tem-se que (a). os dados estão sempre replicados pelos diversos nós existentes, no caso das fragmentações horizontal e vertical. (b). não é possível reconstruir a relação original R por meio dos diversos fragmentos existentes. (c). na fragmentação vertical, ocorre a decomposição de atributos de R em um ou mais fragmentos. (d). na fragmentação vertical, ocorre a decomposição de R em subconjuntos de dados selecionados a partir de um critério comum de ltragem relativo a um atributo de R. (e). a reconstrução dos dados de uma fragmentação horizontal é possível através da interseção dos subconjuntos de dados fragmentados. Solução: Como mencionado no enunciado da questão, a fragmentação de dados é uma técnica utilizada em bancos de dados distribuídos, e tem como objetivo dividir as informações de uma determinada relação R por vários servidores (chamados nós) de banco de dados. A fragmentação permite o processamento paralelo, que proporciona ganho de desempenho, especialmente, nas operações de consulta. Os dois métodos de fragmentação mais comuns são a fragmentação horizontal e a fragmentação vertical, ilustrados na Figura 5. Figura 5: fragmentação de dados. As características da fragmentação horizontal são as seguintes: cada fragmento contém um subconjunto das tuplas da relação completa; cada tupla de uma relação precisa ser armazenada em pelo menos um servidor; a relação completa pode ser obtida fazendo a união dos fragmentos; não há necessidade de replicação de dados entre os nós. Página 59 de 120

61 Já na fragmentação vertical: relações são decompostas em conjuntos de atributos mantidos em servidores diferentes; cada fragmento é uma projeção da relação completa; a relação completa pode ser obtida fazendo a junção de todos os fragmentos; há necessidade de replicação da chave primária entre os nós para que seja possível a operação de junção. Como podemos notar, para se obter a relação completa é necessário realizar operações de união (no caso da fragmentação horizontal) ou de junção (no caso da fragmentação vertical). Tais operações são de responsabilidade do SGBD, de modo a permitir aos usuários utilizarem o banco de dados de forma transparente, como se estivessem utilizando um SGBD nãodistribuído. Página 60 de 120

62 25. Assuntos relacionados: Sistemas Distribuídos, Independência de Localização, Independência de Fragmentação, Independência do Sistema Operacional, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas - Processos de Negócio Ano: 2008 Questão: 64 Sistemas de informações distribuídos são aqueles em que dados são armazenados e processados em diferentes localizações. Um banco de dados distribuído é um exemplo deste tipo de sistema. Para o usuário, um sistema de banco de dados distribuído deve parecer exatamente como um sistema não distribuído. Para que tal meta seja alcançada, alguns objetivos secundários são normalmente estabelecidos, entre os quais NÃO se inclui a (a). independência de localização. (b). independência de fragmentação. (c). independência do sistema operacional. (d). operação contínua. (e). coordenação em um nó central. Solução: Operação contínua Uma vantagem dos sistemas distribuídos (SD) é que eles devem fornecer maior conabilidade e maior disponibilidade. A conabilidade em SD implica no funcionamento sem queda em qualquer momento, isto acontece, porque sistemas distribuídos podem continuar a funcionar mesmo diante da falha de algum componente individual, como um servidor isolado. A disponibilidade refere se ao funcionamento continuamente sem queda do sistema durante um período, isso porque existe a possibilidade de replicação dos dados. Não será preciso desligar o sistema para a execução de alguma tarefa, como adicionar um servidor ou atualizar o sistema de banco de dados. Esta característica é fundamental, uma vez que os sistemas garantem o funcionamento/acesso dos dados/metadados, independente do tempo necessário para manipulá-los. Como os metadados estarão distribuídos (replicados) em todos os servidores, mesmo na presença de uma falha, algum servidor disponibilizará os metadados para serem manipulados. Independência de localização Também conhecida por transparência de localização, é quando os usuários não precisam saber onde estão sicamente armazenados os dados. É uma característica desejável, pois simplica programas e atividades em aplicações e permite que dados migrem de um servidor para outro, sem invalidar qualquer desses programas e atividades. Essa capacidade de migração é desejável porque permite que dados sejam deslocados pela rede em resposta a alterações de exigências de desempenho. Utilizando-se de metadados, a transparência de armazenamento faz com que os usuários das aplicações desconheçam a forma (em que local) como os metadados são mantidos, simplicando a adição de novos servidores no sistema distribuído. Página 61 de 120

63 Independência de fragmentação Um sistema admite fragmentação de dados se uma dada variável de relação armazenada pode ser dividida em pedaços (fragmentos) para ns de armazenamento físico. A fragmentação é desejável por razões de desempenho: os dados podem ser armazenados no local em que são mais freqüentemente utilizados, de modo que a maior parte das operações seja apenas local e o tráfego na rede seja reduzido. Independência de sistema Operacional O suporte a um sistema de banco de dados distribuídos implica que uma única aplicação seja capaz de operar de modo transparente sobre dados dispersos em uma variedade de banco de dados diferentes, gerenciados por vários SGBDs diferentes, em execução em uma variedade de máquinas diferentes que podem estar rodando em diversas plataformas diferentes e uma variedade de sistemas operacionais. Onde o modo transparente diz respeito à aplicação operar sob um ponto de vista lógico como se os dados fossem gerenciados por um único SGBD, funcionando em uma única máquina com apenas um sistema operacional. Assim, um sistema distribuído consiste em adicionar o poder computacional de diversos computadores interligados por uma rede de computadores ou mais de um processador trabalhando em conjunto no mesmo computador, para processar colaborativamente determinada tarefa de forma coerente e transparente, ou seja, como se apenas um único e centralizado computador estivesse executando a tarefa, portanto a alternativa E está incorreta. Página 62 de 120

64 26. Assuntos relacionados: Banco de Dados, Normalização de Banco de Dados, Primeira Forma Normal (1FN), Segunda Forma Normal (2FN), Terceira Forma Normal (3FN), Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 46 A relação Vendas, apresentada a seguir, foi montada para armazenar os dados de um sistema de vendas. Considere que atributo sublinhado representa o identicador da relação, e item marcado com * representa atributo multi-valorado. Vendas(NumeroNota, CodProduto, DescProduto, NomeCliente, CPFCliente, Data, QtdeVendida, ValorUnitVendido, Peso, Telefone*) Foram especicadas as seguintes dependências funcionais: CodProduto DescProduto, Peso NumeroNotaFiscal Data, CPFCliente NumeroNotaFiscal, CodProduto QtdeVendida, ValorUnitVendido CPFCliente NomeCliente Considerando-se que para um dado valor em CPFCliente podem existir vários telefones associados e vice-e-versa, qual o conjunto de tabelas que armazena as informações apresentadas, atende às dependências funcionais e se encontra na terceira forma normal? (a). Produtos(CodProduto, DescProduto, Peso) Vendas(NumeroNota, CodProduto, CPFCliente, QtdeVendida, ValorUnitVendido) Clientes(CPFCliente, NomeCliente, Data, Telefone*) (b). Clientes(CPFCliente, NomeCliente) Telefone(CPFCliente, Telefone) NotasDeVenda(NumeroNota, CodProduto, CPFCliente, Data) Produtos(CodProduto, DescProduto, ValorUnitVendido, Peso) ProdutosVendas(NumeroNota, CodProduto, CPFCliente, QtdeVendida) (c). Clientes(CPFCliente, NomeCliente) Telefone(CPFCliente, Telefone) Nota(NumeroNota, CPFCliente, Data) Produtos(CodProduto, DescProduto, Peso) NotasProdutos(NumeroNota, CodProduto, QtdeVendida, ValorUnitVendido) (d). Vendas(NumeroNota, CodProduto, QtdeVendida, ValorUnitVendido, CPFCliente, Data) Produtos(CodProduto, DescProduto, Peso) Cliente(CPFCliente, NomeCliente) Telefone(CPFCliente, Telefone) (e). Cliente(CPFCliente, Telefone, NomeCliente) Nota(CPFCliente, NumeroNota, CodProduto, QtdeVendida, ValorUnitVendido, Data) Produtos(CodProduto, DescProduto, Peso) Solução: Página 63 de 120

65 Uma dependência funcional da forma A B revela que cada valor do atributo A determina exatamente um valor do atributo B. Por exemplo, na dependência funcional CodProduto DescProduto, Peso, supomos CodProduto = 1001, a esse CodProduto estará associada exatamente uma dupla da forma DescProduto, Peso, por exemplo: Sabão em Pó Mix, 500g. Nenhuma outra dupla será permitida para ser representada pelo CodProduto Um conjunto de tabelas está na terceira forma normal se todas as suas relações satisfazem as condições da terceira forma normal. Uma relação que está na terceira forma normal necessariamente satisfaz as condições previstas na primeira e na segunda forma normal. A primeira forma normal proíbe a existência de campos multivalorados. Logo, a alternativa A já pode ser eliminada, visto que o atributo Telefone da tabela Clientes é multivalorado. Uma relação satisfaz as condições da segunda forma normal se atender as condições da primeira forma normal e, além disso, respeitar a seguinte restrição: todos os atributos nãoprimo (atributos que não fazem parte de nenhuma chave candidata) só podem depender funcionalmente de conjuntos formados por todos os campos de qualquer chave candidata, e não somente de uma parte deles. Exemplo: na tabela NotasDeVenda, os campos CPFCliente e Data dependem funcionalmente somente do campo NumeroNota, e não de toda a chave primária (NumeroNota, CodProduto), que por denição é uma chave candidata. Logo, a alternativa B também pode ser eliminada, uma vez que não atende nem à segunda forma normal. Analisando a denição acima, podemos concluir que as relações da alternativa C satisfazem às condições da segunda forma normal. O que mais é necessário para que essas relações estejam na terceira forma normal? Para responder essa pergunta é necessário conhecer mais algumas denições. A primeira delas é o de atributo não-primo, que, basicamente, é um atributo que não pertence a nenhuma chave candidata da relação. Outro conceito é o de dependência funcional transitiva: quando uma dependência funcional X Z é determinada indiretamente da forma X Y e Y Z. Voltando à denição da terceira forma normal. Ela exige que todo atributo não-primo da relação seja diretamente dependente (ou seja, não seja transitivamente dependente) de qualquer chave candidata. Não existe nenhuma relação transitiva dos atributos não-primo nas relações descritas na alternativa C. Logo, essa é a resposta correta para a questão. Finalizando, a relação Vendas da alternativa D e as relações Cliente e Nota da alternativa E não satisfazem as condições da segunda forma normal. Portanto, também não estão na terceira forma normal. Página 64 de 120

66 27. Assuntos relacionados: Banco de Dados, Modelo Relacional, Normalização de Banco de Dados, Primeira Forma Normal (1FN), Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 23 É correto armar que qualquer relação válida de um modelo relacional: (a). pode apresentar tuplas duplicadas, desde que não haja chaves candidatas denidas. (b). em seus atributos ordenados da esquerda para a direita, de acordo com a denição. (c). tem suas tuplas naturalmente ordenadas, para ns de localização. (d). tem um índice físico para cada chave candidata, incluindo a chave primária. (e). está, pelo menos, na primeira forma normal. Solução: Conceitualmente, em um banco de dados relacional, as relações podem ser denidas como um conjunto de tuplas. Uma tupla é uma sequência ordenada de atributos e representa, usualmente, um objeto do mundo real e suas informações. Todas as tuplas em uma mesma relação possuem o mesmo conjunto de atributos. Entretanto, em uma relação, elas devem preservar o que é chamado de integridade existencial, que, basicamente, implica que tuplas iguais (com todos os valores dos seus atributos iguais) não são permitidas. Caso contrário, não temos uma relação. A forma de garantir a integridade existencial é denir uma chave primária, que, obrigatoriamente, deve ser não-nula e única em toda relação. Logicamente, sendo a chave primária única, as tuplas duplicadas não serão permitidas e a relação estará garantida. Deve car clara a diferença entre tabela e relação. Uma tabela nada mais é do que um conjunto de linhas e colunas. Já as relações, que já foram denidas acima, são implementadas sicamente em tabelas, que, obviamente, devem atender às condições exigidas em uma relação. Ou seja, nem toda tabela representa uma relação. Na denição da primeira forma normal dada por Date, uma tabela está na primeira formal normal se, e somente se, for isomórca à alguma relação. Isso quer dizer que, especicamente, a tabela deve atender às cinco condições abaixo: não existe uma ordenação das linhas de cima para baixo; não existe uma ordenação das colunas da direita para esquerda; não existem linhas duplicadas; qualquer interseção linha-coluna deve conter exatamente um valor no domínio aplicável e nada mais; todas as colunas são regulares, no sentido de não possuírem componentes ocultos como identicadores de linhas, identicadores de colunas, identicadores de objetos ou timestamps ocultos. Veja nas Tabelas 3, 4 e 5 um exemplo de cenário em que a informação contida em uma tabela que não está na 1FN é transportada para outras tabelas que estão na 1FN. Página 65 de 120

67 idpessoa nmpessoa dtaniversario nrtelefones 1 João Roberto 01/05/ Juliana Gomes 28/02/ Talita Brandão 03/12/ Tabela 3: exemplo de tabela que não está na 1FN. idpessoa nmpessoa dtaniversario 1 João Roberto 01/05/ Juliana Gomes 28/02/ Talita Brandão 03/12/1988 Tabela 4: exemplo de tabela que está na 1FN. idtelefone idpessoa nrtelefone Tabela 5: exemplo de tabela que está na 1FN. Dada a exposição teórica, podemos analisar as alternativas da questão: a. falsa, uma relação válida não permite tuplas duplicadas. b. falsa, a ordenação dos atributos não dene a relação. c. falsa, a ordenação das linhas não dene a relação. d. falsa, a relação é uma denição no nível conceitual. Os índices físicos são denidos no nível físico e não inuenciam no conceito de relação. Geralmente, esses índices podem ser livremente criados para qualquer conjunto de atributos, já a obrigação citada de serem criados para cada chave candidata não existe e não faz nenhum sentido. e. verdadeira, pois, por denição, uma tabela representa uma relação se, e somente se, a tabela está na primeira forma normal. Página 66 de 120

68 28. Assuntos relacionados: Banco de Dados, Normalização de Banco de Dados, Primeira Forma Normal (1FN), Segunda Forma Normal (2FN), Terceira Forma Normal (3FN), Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 25 As informações a seguir são comuns às questões de número 5 ao 8 Considere as tabelas de um banco de dados relacional descritas abaixo, onde os campos que compõem chaves primárias estão assinalados com *. TABELA CLIENTE PRODUTO VENDA CAMPOS *CODIGO_C, CPF, NOME, CIDADE *CODIGO_P, DESCRICAO, PRECO *CODIGO_C, *CODIGO_P, CPF, DATA, QUANTIDADE Há uma chave estrangeira de VENDA para CLIENTE com base nos campos CODIGO_C e de VENDA para PRODUTO com base nos campos CODIGO_P. O campo CPF é chave candidata para CLIENTE e também é armazenado na tabela VENDA. Os campos NOME e DESCRICAO também são chaves candidatas de suas respectivas tabelas. Os campos CI- DADE, PRECO, DATA e QUANTIDADE admitem valores repetidos. Sobre as formas normais a que as tabelas satisfazem, assinale a armativa correta. (a). CLIENTE satisfaz à segunda forma normal (2FN), mas não à terceira (3FN). (b). PRODUTO satisfaz à segunda forma normal (2FN), mas não à terceira (3FN). (c). VENDA satisfaz à segunda forma normal (2FN), mas não à terceira (3FN). (d). VENDA não satisfaz à segunda forma normal (2FN). (e). As três tabelas satisfazem à terceira forma normal (3FN). Solução: Primeiramente, vamos denir o que é dependência funcional. Dizemos que B é funcionalmente dependente de A (A B) se, para cada valor de A, existe exatamente um atributo B. Um exemplo prático é cidade estado, uma cidade A implicará em exatamente um estado B correspondente. No caso, A é o determinante e B é o dependente. A dependência funcional trivial indica que um determinante com mais de um atributo pode determinar seus próprios membros quando isolado. Exemplo: {banco, agencia} {agencia}. A dependência funcional não-trivial indica que um determinante identica outro atributo qualquer {banco, agencia} {cidade}. Se um atributo A determina B e se B determina C, podemos dizer que A determina C de forma transitiva. Isto é, existe uma dependência funcional transitiva de A para C. Exemplo: cidade estado, estado pais, então cidade pais. Uma chave candidata é um atributo ou conjunto de atributos que é único dentre todos os registros. Já a chave primária é uma chave escolhida entre as chaves candidatas para ser o identicador principal da tabela. Página 67 de 120

69 Outra denição importante é a do atributo não-primo, que é um atributo que não ocorre em nenhuma das chaves candidatas da tabela. Sabemos que uma tabela está na segunda forma normal se ela está na primeira forma normal e não existe atributo não-primo na tabela que seja funcionalmente dependente de algum subconjunto próprio de qualquer chave candidata. Melhor dizendo: todas as colunas que não fazem parte de nenhuma chave candidata dependem de todas as colunas que compõem qualquer chave candidata. Quando só há uma chave candidata (no caso a primeira) e ela é composta por somente um atributo, automaticamente a tabela estará na segunda forma normal se já tiver atendido às condições da primeira forma normal. Sendo assim, já podemos notar que a tabela CLIENTE e a tabela PRODUTO estão na segunda forma normal garantidamente. Já ao analisarmos a tabela VENDA poderíamos nos enganar ao acharmos que pelo fato de CPF ser dependente funcionalmente de CODIGO_C, estaríamos violando a condição exigida da segunda forma normal, já que CODIGO_C é um subconjunto próprio da chave primária. Essa conclusão seria verdadeira se não fosse pelo fato de {CPF,CODIGO_P} ser uma chave candidata, tornando o atributo CPF primo, ou seja não não-primo. Concluímos, assim, que a tabela VENDA está na segunda forma normal. Uma tabela está na terceira forma normal se qualquer atributo não-primo é não transitivamente dependente de qualquer chave candidata da tabela. Ao analisarmos a tabela CLIENTE, notamos que o atributo CIDADE é o único não-primo, sendo impossível, dessa maneira, haver dependência funcional em que uma chave candidata não seja o atributo determinante. Ou seja, todas as dependências funcionais são diretas a partir de qualquer chave candidata e a tabela CLIENTE está na terceira forma normal. O único atributo não-primo da tabela PRODUTO é PRECO. Portanto, seguindo o mesmo raciocínio anterior, concluímos que PRODUTO está na terceira forma normal. A tabela VENDA tem 2 atributos não-primo: DATA e QUANTIDADE. Como não há dependência funcional entre eles, essa tabela também está na terceira forma normal. Logo, concluímos que todas as tabelas satisfazem à terceira forma normal e a alternativa a ser marcada é a alternativa E. Se continuássemos a analisar quais formas normais são atendidas pelas tabelas da questão, chegaríamos à conclusão de que as tabelas CLIENTE e PRODUTO satisfazem à forma normal de Boyce Codd (FNBC), ao contrário da tabela VENDA, que não satisfaz. Uma tabela que não satisfaz a forma normal de Boyce Codd (FNBC) pode ser identicada com as seguintes características: encontramos duas ou mais chaves candidatas ({CODIGO_C, CODIGO_P} e {CPF, CODIGO_P}, no caso da tabela VENDA); as chaves candidatas apresentam mais de um atributo (são compostas); todas as chaves candidatas têm um atributo em comum (CODIGO_P, no caso das chaves candidatas da tabela VENDA). Página 68 de 120

70 29. Assuntos relacionados: Modelo Relacional, Banco de Dados, Normalização de Banco de Dados, Banca: FCC Instituição: TRT 2a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2008 Questão: 40 Para eliminar a condição de existência de valores não atômicos em uma coluna de tabela relacional, (a). deve ser aplicada, no mínimo, a primeira Forma Normal. (b). devem ser aplicadas, no mínimo, as quatorze regras de Codd. (c). deve ser aplicada, no mínimo, a Forma Normal Boyce-Codd. (d). deve ser aplicada, no mínimo, a terceira Forma Normal. (e). devem ser aplicadas, no mínimo, as regras de integridade referencial. Solução: Para resolvermos a presente questão é bom relembrarmos alguns tipos de atributos existentes no Modelo Entidade-Relacionamento (MER), o signicado de Normalização de Dados, Super-chave, Chave-candidata, Chave-primária, dependência Funcional e dependência não- Transitiva entre atributos: cada entidade em um MER tem propriedades particulares, chamadas atributos, que a descrevem. Por exemplo, uma entidade EMPREGADO pode ser descrita pelo seu nome, o trabalho que realiza, idade, endereço e salário. Uma entidade em particular terá um valor para cada um de seus atributos. Alguns atributos podem ser divididos em subpartes com signicados independentes. Por exemplo, Endereço de uma entidade pode ser dividido em Endereço da Rua, Cidade, Estado e CEP. Um atributo que é composto de outros atributos mais básicos é chamado composto. Já, atributos que não são divisíveis são chamados simples ou atômicos. Muitos atributos têm apenas um único valor. Tais atributos são chamados atributos univalorados (exemplo, Data de Nascimento de uma entidade qualquer). Em outros casos, um atributo pode ter um conjunto de valores. Tais atributos são chamados de atributos multivalorados (exemplo, Telefone de Contato de uma entidade qualquer). Atributos multivalorados podem possuir uma multiplicidade, indicando as quantidades mínima e máxima de valores; a Normalização de Dados é um processo formal, passo a passo, de análise dos atributos de uma relação com o objetivo de evitar redundância de informação, eliminando as chamadas anomalias de atualização (Inclusão, Exclusão Modicação). Baseia-se no conceito de FORMAS NORMAIS. Uma relação (tabela) é dita estar em uma determinada forma normal, se ela satiszer a um conjunto especíco de restrições; Super-chave: é qualquer subconjunto dos atributos de uma relação R cujos valores não se repetem em R; Chave-candidata: é uma super-chave que possua a menor quantidade possível de atributos (uma das Chaves-Candidatas deve ser eleita como Chave-primária); Dependência Funcional entre Atributos: se o valor de uma Atributo A permite descobrir o valor de um outro Atributo B, dizemos que A determina funcionalmente B (A B). Por exemplo: NroMatricula NomeAluno, idade, curso. Assim, sempre que o NroMatricula se repetir tem-se a repetição de NomeAluno, idade e curso; Página 69 de 120

71 Dependência Não-Transitiva: ocorre quando cada atributo for funcionalmente dependente apenas dos atributos componentes da chave primária ou se todos os seus atributos não chave forem independentes entre si. (A) CORRETA Uma relação se encontra na Primeira Forma Normal (1FN) se todos os domínios de atributos possuem apenas valores atômicos (indivisível), e que o valor de cada atributo na tupla seja simples. A 1FN não permite a construção de relações que apresentem atributos compostos e nem possibilita a existência de atributos multivalorados em suas tuplas. Os únicos valores de atributos permitidos devem ser simples e atômicos. Para normalizar para a Primeira Forma Normal deve-se: Atributos compostos: cada um dos atributos compostos (ou não atômicos) deve ser dividido em seus atributos componentes; Atributos multivalorados: quando a quantidade de valores for pequena e conhecida a priori, substitui-se o atributo multivalorado por um conjunto de atributos de mesmo domínio, cada um monovalorado representando uma ocorrência do valor; quando a quantidade de valores for muito variável, desconhecida ou grande, retirase da relação o atributo multivalorado, e cria-se uma nova relação que tem o mesmo conjunto de atributos chave, mais o atributo multivalorado também como chave, porém agora tomado como monovalorado. (B) ERRADA Na verdade, Edgard F. Codd, em 1985, estabeleceu 12 regras (As 12 Regras de Codd) que determinam o quanto um banco de dados é relacional. São elas: 1. Regra das informações em tabelas; 2. Regra de acesso garantido; 3. Regra de tratamento sistemático de valores nulos; 4. Regra do catálogo relacional ativo; 5. Regras de atualização de alto-nível; 6. Regra de sublinguagem de dados abrangente; 7. Regra de independência física; 8. Regra de independência lógica; 9. Regra de atualização de visões; 10. Regra de independência de integridade; 11. Regra de independência de distribuição; 12. Regra não-subversiva. Algumas vezes as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas. Além de o número de regras estar errado, tal alternativa também não representa a aplicação mínima necessária para atender o requisito da questão. Logo, a alternativa está ERRADA. Página 70 de 120

72 (C) ERRADA Um relação é considerada estar na Forma Normal de Boyce-Codd (FNBC), quando: estiver na Primeira Forma Normal (1FN); e para cada chave candidata, todos os atributos que não participam da chave candidata são dependentes não transitivos de toda a chave candidata. Para Normalizar para a Forma Normal de Boyce-Codd seguem-se os mesmos passos da Terceira Forma Normal (3FN). No entanto, tal alternativa, assim como a alternativa D, também não representa a aplicação mínima necessária para atender o requisito da questão. Logo, a alternativa também está ERRADA. (D) ERRADA Que tal antes relembrarmos um pouco sobre relação na Segunda Forma Normal (2FN) e na Terceira Forma Normal (3FN)? Uma relação está na 2FN quando: estiver na Primeira Forma Normal e; todos os atributos que não participam da chave primária são dependentes funcionalmente (diretos ou transitivos) de toda a chave primária. Um relação é considerada estar na 3FN, quando: estiver na Segunda Forma Normal e; todos os atributos que não participam da chave primária são dependentes não transitivos de toda a chave primária. Como vimos, uma relação que está na 3FN também estará na 2FN. Do mesmo modo, uma relação na 2FN também estará na 1FN. Como mencionamos na alternativa A, basta estar na 1FN para atender ao requisito da questão. Assim, concluímos que a alternava está ER- RADA por aplicar duas operações de normalização a mais do que o mínimo necessário. (E) ERRADA A Integridade Referencial é utilizada para garantir a Integridade dos dados entre as tabelas relacionadas. Por exemplo, considere um relacionamento do tipo Um-para-Vários entre a tabela Clientes e a tabela Pedidos (um cliente pode fazer vários pedidos). Com a Integridade Referencial, o banco de dados não permite que seja cadastrado um pedido para um cliente que ainda não foi cadastrado. Em outras palavras, ao cadastrar um pedido, o banco de dados verica se o código do cliente que foi digitado já existe na tabela Clientes. Se não existir, o cadastro do pedido não será aceito. Assim, a integridade referencial garante a não corrupção dos dados, de modo a não haver como existir um registro lho sem um registro pai. Página 71 de 120

73 30. Assuntos relacionados: Banco de Dados, Primeira Forma Normal (1FN), Segunda Forma Normal (2FN), Terceira Forma Normal (3FN), Banca: FCC Instituição: TRT 18a Região Cargo: Analista Judiciário - Tecnologia da Informação Ano: 2008 Questão: 45 Dadas as tabelas abaixo com os respectivos atributos, sendo chave os atributos grifados: I PEDIDO (num-ped, data-ped, total-ped, cod-cliente, nome-cli, endereço-cli) II ITEM (num-ped, cod-produto, qtde-prod, preço-total) III PRODUTO (cod-produto, nome-prod, preço-unitário) Encontra-se na 3FN o que consta em (a). I, II e III. (b). I, apenas. (c). II, apenas. (d). III, apenas. (e). II e III, apenas. Solução: Como este assunto é muito cobrado nos concursos em geral, vamos explorar diversos conceitos importantes para se resolver esta questão com conança. superchave: é um conjunto de um ou mais atributos que permite a identicação unívoca de cada entidade em um conjunto de entidades. Na nomenclatura desta questão, uma superchave identica de forma única cada linha de uma tabela. Por exemplo, na relação (conceito que o enunciado deveria utilizar no lugar de tabela) ITEM, o conjunto {num-ped; preço-total} é uma superchave, pois ele pode identicar de forma única cada item dessa relação. É importante perceber que toda relação tem pelo menos uma superchave: conjunto de todos os seus atributos; chave candidata: é uma superchave tal que nenhum dos seus subconjuntos de atributos é uma superchave. Ou seja, se pudermos retirar pelo menos um atributo de uma superchave e ela continuar sendo uma superchave, a superchave inicial não é uma chave candidata. Por exemplo, quando tiramos o atributo preço-total da superchave {numped; preço-total}, continuamos com uma superchave num-ped, pois num-ped identica univocamente cada elemento da relação ITEM. Portanto, {num-ped; preço-total} não é uma chave candidata. Outra forma de entender o signicado de chave candidata é pensar que ela é um subconjunto mínimo de atributos capaz de identicar de forma única cada item de uma relação. Não se esqueça que um relação pode ter mais de uma chave candidata; chave primaria: é simplesmente uma das chaves candidatas de uma relação. É o projetista que faz essa escolha, quando há mais de uma chave candidata; dependência funcional: se para cada valor de um atributo A, existe exatamente um valor para o atributo B, dizemos que B é dependente funcional de A (A B) e que A é o determinante de B. Um bom exemplo é formado pelos atributos CIDADE A e ESTADO B. Como toda cidade implica em somente um estado, temos que A B; Página 72 de 120

74 dependência funcional parcial: em uma dependência do tipo A B, se existir um subconjunto de A tal que ele determine B, dizemos que B é dependente funcional parcial de A. Exemplo: em {CIDADE; BAIRRO} ESTADO, como CIDADE ESTADO, dizemos que ESTADO é dependente funcional parcial de {CIDADE; BAIRRO}. Caso não exista esse tipo de subconjunto de A, dizemos que B é dependente funcional total de A; dependência funcional trivial: indica que um determinante com mais de um atributo determina seus próprios membros quando isolado. Exemplo: {banco; agencia} {agencia} dependência funcional não-trivial: indica que um determinante identica outro atributo qualquer {banco; agencia} {cidade}; dependência funcional transitiva: se um atributo A determina B e B determina C, então, A determina C de forma transitiva. Exemplo: cidade estado, estado país, então cidade país; atributo primo: atributo membro de qualquer chave candidata (pelo menos uma). Dois exemplos dentro desta questão são: cod-produto e num-ped. Perceba que todos os atributos de uma chave primária são primos; atributo não-primo: atributo que não ocorre em nenhuma chave candidata de uma relação. O atributo preço-unitário da relação PRODUTO é um exemplo de atributo não-primo; 1FN: ela diz respeito a atributos. Para que uma relação esteja na 1FN, ela não pode ter nem atributos multivalorados nem relações aninhadas (objetos representados em mais de um registro); 2FN: ela diz respeito a dependência funcional parcial. Uma relação somente está na 2FN se não houver atributo não-primo dependente funcional parcial de qualquer chave candidata. Ou seja, se houver pelo menos um atributo não-primo dependente funcional parcial de pelo menos uma chave candidata, a relação não estará na 2FN. Lembrando também que para uma relação estar na 2FN, ela também deve estar na 1FN; 3FN: ela diz respeito a dependência funcional transitiva. Para que uma relação esteja na 3FN, ela não pode ter atributo não-primo dependente transitivamente de qualquer chave candidata. Ou seja, se houver pelo menos um atributo não-primo com dependência funcional transitiva de pelo menos uma chave candidata, a relação não estará na 3FN. Uma consequência é que para uma relação estar na 3FN, todos os atributos não-primo devem depender somente de atributos primos. Lembrando também que para uma relação estar na 3FN, ela também deve estar na 2FN e na 1FN; As dependência funcional de uma relação são determinadas pelo negócio, e não pelo o banco de dados em si. Por isso, o ideal seria o enunciado trazer quais são as dependências funcionais existentes em cada relação. Na falta dessa especicação, o que nos resta é apelar para o bom-senso. Vamos analisar agora cada relação. Como o enunciado não menciona que algum atributo pode ser multivalorado, concluímos que as 3 relações estão na 1FN. PEDIDO (num-ped, data-ped, total-ped, cod-cliente, nome-cli, endereço-cli) Como não há nenhuma chave candidata composta por mais de um atributo nesta relação, não há como existir dependência funcional parcial. Portando, esta relação está na 2FN. Perceba que cod-cliente nome-cli e que esses dois atributos são não-primos. Isso já basta Página 73 de 120

75 para concluirmos que esta relação NÃO está na 3FN. ITEM (num-ped, cod-produto, qtde-prod, preço-total) Nesta relação, há dois atributos não-primos (qtde-prod e preço-total) e uma chave candidata {num-ped; cod-produto}. Veja que (1) num-ped não determina nem qtde-prod nem preço-total; (2) cod-produto não determina nem qtde-prod nem preço-total. Portanto, não há dependência funcional parcial e, por consequência, esta relação está na 2FN. Como não há dependência funcional transitiva, esta relação está na 3FN. PRODUTO (cod-produto, nome-prod, preço-unitário) Pelo mesmo motivo da relação PEDIDO, concluímos também que esta relação está na 2FN. Como só há um atributo não-primo, não há como existir dependência funcional transitiva. Concluímos, portanto, que esta relação também está na 3FN. Pelo o exposto, é possível identicar facilmente que a alternativa correta é a letra e. Página 74 de 120

76 31. Assuntos relacionados: Banco de Dados, Consulta SQL, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 60 As relações abaixo compõem uma base de dados em que atributos sublinhados são identicadores e atributos em itálico são chaves estrangeiras. Autor (CPFAutor, Nome, DataNascimento) Obra (TituloObra, DataConclusao, CPFAutor, CodigoAssunto) Editora (CNPJEditora, Nome, Local) Publicacao (TituloObra, CNPJEditora, DataLancamento ) Assunto (CodigoAssunto, Descricao) Que comando SQL apresenta como resultado a quantidade de publicações do assunto `Policial' por editora? (a). Select P.CNPJEditora, count(p.tituloobra) from Publicacao P inner join Obra O on P.TituloObra = Obra.TituloObra inner join Assunto A on O.CodigoAssunto = A.CodigoAssunto where A.Descricao = `Policial' (b). Select P.CNPJEditora, count(p.tituloobra) from Publicacao P, Obra O, Assunto A where P.TituloObra = O.TituloObra and O.CodigoAssunto = A.CodigoAssunto and A.Descricao = `Policial' group by P.CNPJEditora (c). Select P.CNPJEditora, count(p.tituloobra) from Publicacao P, Obra O, Assunto A, Editora E group by P.CNPJEditora having A.Descricao = `Policial' (d). Select P.CNPJEditora, sum(p.tituloobra) from Publicacao P inner join Obra O on P.TituloObra = Obra.TituloObra inner join Assunto A on O.CodigoAssunto = A.CodigoAssunto where A.Descricao = `Policial' group by P.CNPJEditora (e). Select P.CNPJEditora, count(p.tituloobra) from Publicacao P left outer join Obra O on P.TituloObra = Obra.TituloObra left outer join Assunto A on O.CodigoAssunto = A.CodigoAssunto group by P.CNPJEditora Solução: Para encontrarmos o resultado da quantidade de publicações do assunto Policial por editora, devemos ter em mente que precisamos utilizar a função de agrupamento groupby para Página 75 de 120

77 agrupar as editoras com mesmo CNPJ, e a função agregada count para contabilizar o número de registros de um determinado CNPJ. (A) ERRADA Inner join é uma operação de composição de relações condicionais e é usada na cláusula from. Sua sintaxe é relacao1 inner join relacao2 on condição. O select em questão explora as relações de chave estrangeira entre os relacionamentos, e a execução dos dois inner join produzem um relacionamento de onde é possível extrair os CNPJs cujos valores do atributo Descricao de Assunto são Policial. O problema desse select é que ele não agrupa os registros para contabilizar a quantidade de um determinado CNPJ. Portanto, esta alternativa é errada. (B) CORRETA Os predicados da cláusula where do select em questão produzem a mesma relação obtida na alternativa A. Com uma diferença, ao obter os registros que contém a Descricao de Assunto igual a Policial, agrupa-se as editoras de mesmo CNPJ para contabilizar a quantidade de editoras para cada CNPJ por meio da função count no select. Portanto, esta é a alternativa correta. Vale destacar que na cláusula where as operações de = exploram os relacionamentos entre as relações existentes. Então, quando selecionamos os registros com Descricao igual a Policial, as operações de = garantem que estamos selecionando registros com mesmo TituloObra e CodigoAssunto. (C) ERRADA O candidato desatento tende a marcar esta alternativa, pois se esquece dos relacionamentos existentes entre as relações. O select desta alternativa agruparia atributos CNPJEditora da relação Publicacao diferentes do atributo CNPJEditora da relação Editora. O mesmo é válido para os atributos de TituloObra de Obra e Publicacao. Portanto, esta alternativa não é a correta. (D) ERRADA O select desta alternativa utiliza a função sum para contabilizar a quantidade de um determinado CNPJ. Primeiramente, a função correta para essa nalidade é a count, e segundo, a função sum aceita como entrada um conjunto de números. Nesse select, a função sum recebe o parâmetro P.TituloObra, que não é um número. Portanto, esta alternativa é errada. (E) ERRADA O select desta alternativa não possui uma cláusula where que restringe o atributo Descrição da relação Assunto à palavra Policial. Portanto, esta alternativa também não é a correta. Página 76 de 120

78 32. Assuntos relacionados: Banco de Dados, SQL, Banca: CESGRANRIO Instituição: Petrobras Cargo: Analista de Sistemas - Eng. de Software Ano: 2008 Questão: 26 Considere o comando em SQL apresentado a seguir. SELECT C.CIDADE, AVG(P.PRECO) FROM CLIENTE C, PRODUTO P, VENDA V WHERE C.CODIGO_C = V.CODIGO_C AND P.CODIGO_P = V.CODIGO_P AND P.PRECO > 100 GROUP BY C.CIDADE HAVING AVG(P.PRECO) < 200 O que exibe esse comando? (a). Para cada cidade, a média de preço de produtos vendidos a clientes da cidade com valores acima de 100, se a média for menor que 200. (b). Para cada cidade, a média de preço dos produtos vendidos a clientes da cidade com valores entre 100 e 200. (c). Para cada cidade, a quantidade de produtos vendidos com valores entre 100 e 200. (d). Para cada cidade, a média de preço dos produtos vendidos a clientes da cidade que compraram produtos de valores maiores do que 100 e cuja média de compra é menor do que 200. (e). Apenas a cidade cuja média de preço dos produtos vendidos é a mais alta dentre as que tiveram média menor do que 200 e produtos vendidos com valores acima de 100. Solução: A primeira cláusula WHERE (C.CODIGO_C = V.CODIGO_C) irá implementar uma junção entre as tabelas CLIENTE e VENDA. Essa junção, caso fosse considerada sozinha, iria listar registros em que cada um iria representar uma venda de produto, mas com informações adicionais do cliente: NOME e CIDADE. Adicionando mais uma cláusula de junção (P.CODIGO_P = V.CODIGO_P ), será realizada uma junção com a relação já obtida anteriormente. Nesse caso, todos os produtos vendidos serão listados com suas respectivas informações de descrição, preço, data de quando foi realizada a venda e as informações completas do cliente. Entretanto, ao se usar a cláusula P.P RECO > 100, nem todos os produtos vendidos serão listados. Serão listados somente aqueles cujo valor preço unitário for superior a 100. A cláusula GROUP BY C.CIDADE irá agrupar as vendas dos produtos por cidade e reunirá informações, de acordo com AV G(P.P RECO), do preço médio unitário de cada produto, dentro, é claro, dos produtos que já possuem valor unitário maior do que 100. Exemplicando: caso os clientes de uma determinada cidade X tenham comprado exatamente 6 produtos com os preços 1000, 500, 120, 120, 100 e 50, somente serão considerados os produtos com valor maior do que 100, que são os de 1000, 500, 120 e 120. A média Página 77 de 120

79 unitária desses produtos é ( )/4 = 435. Já a última cláusula HAVING AV G(P.P RECO) < 200 irá permitir que somente as cidades cujo preço médio dos produtos adquiridos seja menor que 200. A cidade X anteriormente citada não irá entrar na relação nal, já que a média dos preços unitários de seus produtos adquiridos é maior do que 200 (435). Podemos concluir que a alternativa correta é a letra A. A letra D pode confundir um pouco, mas ela está errada, pois o que está sendo considerado é a média do preço do produto HAVING AV G(P.P RECO) < 200 e não a média de compra. Página 78 de 120

80 33. Assuntos relacionados: Banco de Dados, SQL, Banca: FCC Instituição: MPU Cargo: Analista de Desenvolvimento de Sistemas Ano: 2007 Questão: 64 Funções de um banco de dados relacional que operam contra uma coleção de valores, mas retornam um único valor, são (a). agregadas tal como, por exemplo, MAX. (b). escalares tal como, por exemplo, COUNT. (c). escalares tal como, por exemplo, SUM. (d). agregadas tal como, por exemplo, MID. (e). agregadas tal como, por exemplo, LEFT. Solução: Um banco de dados relacional usa um conjunto de tabelas para representar tanto os dados como as relações entre eles. As consultas em um sistema de banco de dados, tipicamente, são realizadas segundo a linguagem SQL (Structured Query Language Linguagem de Consulta estruturada), que possui diversas partes, sendo que as principais são a: Linguagem de denição de dados (DDL). A DDL proporciona comandos para a denição de esquemas de relações, exclusão de relações, criações de índices e modicação nos esquemas das relações; Linguagem interativa de manipulação de dados (DML). A DML engloba comandos para inserção, exclusão e modicação de registros no banco de dados. A estrutura básica de uma expressão em SQL é formada por três cláusulas: select, from e where. A cláusula select é utilizada para relacionar atributos desejados nos resultados das consultas. A cláusula from associa as relações que serão pesquisadas, e cláusula where consiste em um predicado (expressão booleana). Tipicamente, uma consulta tem a seguinte forma: select a1, a2 from r1, r2 where p Onde a1 e a2 representam os atributos a serem mostrados no resultado da consulta, r1 e r2 as relações (tabelas) do banco e p o predicado. As funções escalares são funções que retornam um único valor como resultado, baseado sobre um valor de entrada. Estão relacionadas à manipulação de strings, de números, de data, funções do sistema e funções de conversão de tipos de dados. Alguns exemplos de funções escalares: UCASE (converte uma string para maiúsculo), LCASE (converte uma string para minúsculo) e LEN (retorna o tamanho da string). As funções agregadas são funções que tem como entrada um conjunto de valores (valores Página 79 de 120

81 de uma coluna de uma tabela), e retornam um valor simples. Algumas funções agregadas: AVG (average média), MIN (minimum minímo), MAX (maximum máximo), SUM (total - total) e COUNT (contagem). (A) A função MAX é uma função agregada da linguagem SQL. Portanto, alternativa correta. (B) A função COUNT também é uma função agregada. A função COUNT é muito utilizada para contar o número de registros de uma tabela. A SQL não permite utilizar a função COUNT com a cláusula distinct. (C) A função SUM também é uma função agregada. A entrada para SUM e para AVG precisa ser um conjunto de números, mas as outras funções agregadas aceitam também tipos de dados não-numéricos (como strings). (D) A função MID é uma função escalar que extrai caracteres de uma string. (E) A função LEFT é uma função escalar que retorna os caracteres mais a esquerda de uma string de acordo com a quantidade especicada. Página 80 de 120

82 34. Assuntos relacionados: Banco de Dados, SQL, Banca: FCC Instituição: TCE/CE Cargo: Analista de Controle Externo - Auditoria de Tecnologia da Informação Ano: 2008 Questão: 75 Considere o seguinte requisito: Para cada departamento com menos de 1000 funcionários devem ser listados os salários médios de cada departamento. As cláusulas SQL-ANSI vinculadas a uma única expressão SELECT, uma que calcula o salário médio e a outra que restringe a quantidade de empregados são, respectivamente, (a). MID e COUNT. (b). AVG e COUNT. (c). AVG e HAVING. (d). MID e WHERE. (e). MID e HAVING. Solução: No SQL-ANSI, a função que calcula a média de um conjunto de valores é a AVG (que vem de average, que em inglês signica média). Portanto, essa já é uma pista de que a resposta só pode ser a alternativa B ou C. A função COUNT, que aparece na alternativa B, é utilizada para fazer uma contagem simples da quantidade de elementos retornados em uma consulta SQL. Portanto, por eliminação, já seria possível chegar a resposta da questão, que é a alternativa C. No entanto, ela será necessária a consulta para contar o número de empregados por departamento. A cláusula HAVING, assim como a cláusula WHERE, é utilizada para restringir os resultados das consultas SQL. No entanto, o HAVING só é utilizado em consultas que retornam resultados agrupados pela cláusula GROUP BY. Pensemos no que poderia ser um modelo de dados para o caso ilustrado na questão: DEPARTAMENTOS (DPTO_ID, DPTO_NOME) FUNCIONARIOS (FUNC_ID, FUNC_NOME, FUNC_SALARIO) DEPARTAMENTOS_FUNCIONARIOS (DPTO_ID, FUNC_ID) Portanto, a consulta que retornaria o nome e o salário médio dos departamentos com menos de 1000 funcionários seria: SELECT D.DPTO_NOME, AVG(F.FUNC_SALARIO) AS SALARIO_MEDIO // Calcula média salarial FROM FUNCIONARIOS F, DEPARTAMENTOS_FUNCIONARIOS DF, DEPARTAMENTOS D, ( SELECT DPTO_ID, COUNT(FUNC_ID) AS FUNCS_POR_DPTO // Contagem de funcionários Página 81 de 120

83 FROM DEPARTAMENTOS_FUNCIONARIOS GROUP BY DPTO_ID // Agrega contagem por departamento HAVING FUNCS_POR_DPTO < 1000 // Restringe resultado ) AS T1 WHERE F.FUNC_ID = DF.FUNC_ID AND DF.DPTO_ID = T1.DPTO_ID AND T1.DPTO_ID = D.DPTO_ID GROUP BY D.DPTO_NOME // Agrega média salarial por departamento Página 82 de 120

84 35. Assuntos relacionados: Banco de Dados, Consulta SQL, Operações de Composição de Relações, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 42 Observe as seguintes tabelas de um sistema: Pessoa (nomepessoa, endereço) Filme (nomefilme, estúdio, verba) Trabalha (nomepessoa(fk), nomefilme(fk), atividade, salário) Um administrador de dados deseja fazer o seguinte relatório: Todas as pessoas, os lmes nos quais já trabalharam e o total recebido por cada lme. Se uma pessoa nunca trabalhou num lme, ela deve aparecer no relatório. A atividade que a pessoa exerceu no lme (ex: ator, diretor, câmera etc.) não é importante para o relatório. Qual consulta retorna o conjunto resposta correto? (a). SELECT P.nomePessoa, T.nomeFilme, sum(t.salário) total FROM Pessoa P LEFT OUTER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa GROUP BY P.nomePessoa, T.nomeFilme (b). SELECT T.nomePessoa, T.nomeFilme, sum(t.salário) total FROM Pessoa P INNER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa GROUP BY T.nomePessoa, T.nomeFilme (c). SELECT P.nomePessoa, T.nomeFilme, sum(t.salário) total FROM Pessoa P LEFT OUTER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa GROUP BY P.nomePessoa, T.nomeFilme HAVING sum(t.salário) > 0 (d). SELECT P.nomePessoa, F.nomeFilme, sum(t.salário) total FROM Pessoa P INNER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa INNER JOIN Filme F ON F.nomeFilme = T.nomeFilme WHERE T.atividade IS NOT NULL AND T.salário > 0 GROUP BY P.nomePessoa, F.nomeFilme (e). SELECT T.nomePessoa, T.nomeFilme, sum(t.salário) total FROM Pessoa P LEFT OUTER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa LEFT OUTER JOIN Filme F Página 83 de 120

85 ON F.nomeFilme = T.nomeFilme Solução: Esta questão tenta explorar o conhecimento do candidato em relação às operações INNER JOIN e LEFT OUTER JOIN devido à restrição se uma pessoa nunca trabalhou num lme, ela deve aparecer no relatório. A operação INNER JOIN é usada tipicamente na cláusula FROM para composição de relações. Sua sintaxe é <tabela A> INNER JOIN <tabela B> ON <condição desejada>. A operação INNER JOIN cria uma nova tabela, combinando os valores das duas tabelas (tabela A e tabela B) com base na condição desejada de junção das tabelas. A consulta com INNER JOIN compara cada linha da tabela A com cada linha da tabela B para encontrar todos os pares de linhas que satisfazem a condição desejada. Quando a condição desejada é satisfeita, valores da coluna para cada par de linha encontrado das tabelas A e B são combinados em uma linha da nova tabela. Note que, a operação INNER JOIN retorna as linhas das tabelas somente quando a condição desejada é satisfeita, isto é, se na tabela A existe uma linha que não satisfaz a condição desejada, esta linha não aparece no resultado da operação INNER JOIN. Como na operação INNER JOIN, a operação LEFT OUTER JOIN também é usada tipicamente na cláusula FROM para composição de relações. Sua sintaxe é <tabela A> LEFT OUTER JOIN <tabela B> ON <condição desejada>. O LEFT OUTER JOIN é processado conforme mostrado anteriormente para o INNER JOIN. Entretanto, o LEFT OUTER JOIN retorna todas as linhas da tabela da esquerda (tabela A), mesmo se a condição desejada não encontrar nenhuma linha correspondente na tabela da direita (tabela B). Ou seja, o LEFT OUTER JOIN retorna todas linhas da tabela da esquerda, mais as linhas da tabela da direita que satisfazem a condição desejada ou, nulo caso não satisfaça. Se a tabela da esquerda retorna uma linha e a tabela da direita retornar mais que uma linha para a condição desejada, a linha da tabela esquerda será repetida para cada linha encontrada da tabela da direita. Existem outras operações relacionadas à cláusula JOIN, como: EQUI-JOIN - mesma funcionalidade do operador INNER JOIN, mas aceita somente comparação de igualdade na condição desejada NATURAL JOIN - uma especialização da operação EQUI-JOIN, porém a condição desejada está implícita na operação. Por exemplo, SELECT * FROM employee NA- TURAL JOIN department CROSS JOIN - retorna o produto cartesiano do conjunto de linhas das tabelas associadas. É equivalente à operação INNER JOIN, onde a condição desejada é sempre verdadeira RIGHT OUTER JOIN - retorna todas as linhas da tabela da direita, mesmo se a condição desejada não encontra nenhuma linha correspondente na tabela da esquerda FULL OUTER JOIN é uma combinação dos tipos das operações LEFT OUTER JOIN e RIGHT INNER JOIN, isto é, ao resultado nal são adicionadas as linhas da tabela esquerda que não correspondem a nenhuma linha da tabela direita, e similarmente para as linhas da tabela da direita Conforme explicado anteriormente, para a nossa consulta retorna o conjunto de resposta correto, devemos utilizar a operação LEFT OUTER JOIN para satisfazer a restrição se uma Página 84 de 120

86 pessoa nunca trabalhou num lme, ela deve aparecer no relatório, pois existe a possibilidade uma pessoa nunca ter trabalho em um lme. Então, a operação LEFT OUTER JOIN deve ser entre as tabelas P essoa e T rabalha, onde a tabela P essoa é a tabela esquerda, isto é, a consulta SQL deve conter a seguinte trecho: Pessoa P LEFT OUTER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa. A seguir, analisamos as alternativas desta questão: (A) CORRETA Esta consulta retorna o conjunto de resposta correto, pois faz uso da operação LEFT OU- TER JOIN entre as tabelas P essoa e T rabalha na cláusula FROM, sendo que a tabela P essoa está do lado esquerdo da operação, satisfazendo a restrição do enunciado. Além disso, esta consulta utiliza a cláusula GROUP BY para formar grupos de P.nomeP essoa e T.nomeP essoa. Isso é utilizado para somar os salários das pessoas que trabalharam nos lmes na cláusula SELECT (sum(t.salário)). E, por m, esta consulta exibe o resultado na cláusula SELECT P.nomePessoa, T.nomeFilme, sum(t.salário) total como o enunciado solicitou. Portanto, alternativa correta. (B) ERRADA Esta consulta não retorna o conjunto de resposta correto, pois faz uso da operação INNER JOIN na cláusula FROM, conforme explicado anteriormente. Então, alternativa errada. (C) ERRADA Esta consulta é semelhante à consulta da alternativa (A), com a diferença do uso da cláusula HAVING com a condição sum(t.salário) > 0. A utilização desta condição na consulta, não satisfaz a restrição imposta pelo enunciado (se uma pessoa nunca trabalhou num lme, ela deve aparecer no relatório), pois o resultado nal não conterá as pessoas que nunca trabalharam em um lme. Portanto, alternativa errada. (D) ERRADA Esta consulta não retorna o conjunto de resposta correto, pois faz uso da operação INNER JOIN na cláusula FROM, conforme explicado anteriormente. Então, alternativa errada. (E) ERRADA Esta consulta faz uso duas vezes da operação LEFT OUTER JOIN. Uma nova tabela (tabela A) é produzida pela operação Pessoa P LEFT OUTER JOIN Trabalha T ON P.nomePessoa = T.nomePessoa. Esta nova tabela (tabela A) é utilizada para gerar outra nova tabela (tabela B) pela operação tabela A LEFT OUTER JOIN Filme F ON F.nomeFilme = T.nomeFilme. Observe que esta última operação é desnecessária, pois com a primeira operação é possível gerar o conjunto resposta correto. A alternativa está errada, pois não utiliza a cláusula GROUP BY para formar grupos P.nomeP essoa e T.nomeP essoa para somar os salários das pessoas que trabalharam nos lmes na cláusula SELECT (sum(t.salário)). Página 85 de 120

87 36. Assuntos relacionados: Banco de Dados, SQL, JOIN, HAVING, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 49 Seja o seguinte grupo de tabelas de um sistema: fabricante (idfabricante, nome, endereço) peça (idmodelo, nome, descrição) constrói (idmodelo (FK), idfabricante (FK), data, quantidade, cor) Um programador monta a seguinte consulta SQL: SELECT f.nome, count(distinct c.idmodelo) as num FROM fabricante f \textbf{inner JOIN} constroi c ON f.idfabricante = c.idfabricante WHERE c.cor = 'VERMELHO' GROUP BY f.nome HAVING count(distinct c.idmodelo) > 10 ORDER BY num DESC Qual o retorno dessa consulta? (a). Os nomes dos fabricantes e a respectiva quantidade total de peças construídas na cor vermelha, desde que, em cada data, a quantidade construída seja maior que 10; o relatório estará ordenado de forma descendente pela quantidade de peças construídas. (b). Os nomes dos fabricantes que já construíram mais de 10 modelos diferentes de peças na cor vermelha e a quantidade de modelos diferentes, mostrando a lista ordenada de forma descendente pela quantidade. (c). Os nomes dos fabricantes que já construíram pelo menos uma peça na cor vermelha; o relatório estará ordenado de forma descendente na quantidade de modelos diferentes construídos. (d). Todos os nomes dos fabricantes e a respectiva quantidade de modelos diferentes de peças vermelhas que já construíram; se um fabricante nunca construiu uma peça na cor vermelha, a contagem mostrará zero. (e). Todos os nomes dos fabricantes e a respectiva quantidade de modelos diferentes construídos, não importando a quantidade de peças, cor ou a data da construção; o relatório estará ordenado de forma descendente na quantidade de peças. Solução: Para resolver esta questão, é necessário conhecer os conceitos de chave primária, chave estrangeira e, por m, entender o que os principais comandos SQL fazem e o resultado deles sobre os dados manipulados de uma ou mais tabelas. Por ser mais essencial, vamos começar entendendo o que são chave primária e estrangeira. Tabelas são coleções de dados que possuem identidade entre si pela semântica. Isso signica Página 86 de 120

88 que as linhas (ou tuplas) de uma tabela referem-se a coisas que guardam semelhança entre si. Entretanto, apesar das semelhanças, cada tupla é única e deve ser assim, para que os dados armazenados façam sentido à aplicação e ao usuário. Para garantir essa unicidade, foi desenvolvido o conceito de chave primária nos bancos de dados. A chave primária pode ser composta por um ou mais campos da tabela. O SGBD (Sistema Gerenciador de Banco de Dados) irá garantir que haverá apenas uma tupla com uma determinada combinação dos campos que compõe a chave primária. Ilustrando como exemplo, podemos supor uma tabela que armazene os produtos de uma mercearia. A tabela, poderia ser: produto (nome, quantidade, precounitario) O campo nome foi utilizado como chave primária. Sabemos disso, pois, por convenção, os campos de uma tabela que aparecem sublinhados são os considerados como chave primária. Nesse exemplo, o SGBD, ao tratar as operações de inserção permitiria que cada produto aparecesse uma vez na tabela. Isso quer dizer que, se por descuido, o usuário já tivesse cadastrado o produto 'banana' e tentasse cadastrar novamente 'banana' o sistema receberia um erro por chave duplicada. Repare que isso é extremamente útil. Na hora de fazer a contabilidade e de gerar relatórios de reposição de estoque, 'banana' é um único produto da mercearia e não queremos que ela apareça repetidamente. Para entender o conceito de chave estrangeira, podemos utilizar o exemplo da mercearia também. Sabemos que, além do cadastro do estoque, o comerciante precisa manter o histórico de suas vendas, de modo que possa atualizar sua contabilidade e prestar contas ao governo. Para tal, podemos supor que o desenvolvedor do aplicativo de controle comercial tenha criado uma tabela que irá registrar todas as vendas feitas. Para isso, ele criará as tabelas: venda (idvenda, data) itemvenda (idvenda (FK), nomeproduto (FK), quantidade) Veja que a tabela venda possui também um campo de chave primária. Como vendas não possuem nomes, podemos imaginar que esse campo pode ser numérico e sequencial, de modo a impedir que vendas sejam sobrescritas. A tabela itemvenda é criada por um motivo muito simples: repare que cada venda poderá ter mais de um item nela; o freguês pode levar, na mesma compra, 6 bananas e 3 maçãs. Se não tivéssemos a tabela itemvenda, para cada produto vendido teríamos que, além de armazenar o identicador da venda, armazenar também a data dela. Isso causaria uma repetição de valores indesejada, aumentando desnecessariamente o tamanho do banco, além de prejudicar a velocidade de processamento de algumas consultas sobre ele. Repare que a tabela itemvenda possui uma chave primária composta de 2 campos: id- Venda e nomeproduto. Ambas aparecem com um (FK) após seu nome. Isso indica que esses campos são chaves estrangeiras importadas de outras tabelas. no caso de idvenda, ela é importada da tabela venda, do campo de mesmo nome; nomeproduto vem da tabela produto, do campo 'nome'. O controle realizado pelo SGBD sobre chaves estrangeiras visa a garantir a integridade referencial entre os diversos dados armazenados no banco de dados. No caso de nosso exemplo, a existência das chaves estrangeiras na tabela itemvenda pretende garantir que só existam itens de venda para vendas que realmente existam e que Página 87 de 120

89 os produtos das vendas estejam cadastrados antes de serem vendidos. (Além desse controle, há também outros sobre a exclusão de itens em cascata, onde, por exemplo, a remoção de um produto poderia desencadear a deleção dos itens de venda cadastrados para ele). A chave primária composta, conforme o exemplo da tabela itemvenda tem a seguinte semântica: para cada item de venda cadastrado na tabela itemvenda só poderá existir uma única referência a um produto para cada venda distinta. Em outras palavras, na venda de número '10' poderá aparecer apenas uma vez o item 'banana'. Veja que isso não limita a compra do cliente a apenas uma banana, pois o campo 'quantidade' permite que várias bananas sejam vendidas para o cliente. A diferença estará apenas no armazenamento dessa informação no sistema, pois o item banana aparecerá apenas uma vez, com a quantidade comprada registrada no campo especíco para isso. Fica claro que essa medida evita que várias linhas para o mesmo produto sejam repetidas para expressar a mesma compra. Utilizando esse artifício, economiza-se muito espaço, além de se aumentar também a velocidade das consultas, visto que, em qualquer hipótese, uma quantidade maior de linhas em uma tabela resultará, impreterivelmente, em maior tempo de consulta. (Este tipo de preocupação com otimização de tempos de consulta e quantidade de armazenamento deu origem ao estudo das formas normais. Complemente seu aprendizado buscando por essa informação). Com essas informações, passamos a entender a estrutura das tabelas apresentadas: fabricante (idfabricante, nome, endereço) Cada fabricante cadastrado será identicado pelo seu id (idfabricante) respectivo. peça (idmodelo, nome, descrição) Cada peça cadastrada será identicada pelo seu id (idmodelo) respectivo. constrói (idmodelo (FK), idfabricante (FK), data, quantidade, cor) Cada linha da tabela constrói terá a quantidade e a cor de uma única peça fabricada por um fabricante especíco em uma determinada data. Além disso, em uma determinada data, um fabricante só produzirá uma determinada peça em uma única cor. Com essas denições, podemos passar à segunda parte da questão que envolve entender os comandos SQL. Nessa questão são utilizados os seguintes comandos: SELECT: indica quais os campos das tabelas que são listadas no comando FROM se deseja exibir; FROM: indica as tabelas que fazem parte da consulta em questão; INNER JOIN: esse comando, sempre que aparecer, estará entre duas tabelas e logo após o comando FROM. Ele é um indicador que informa que os dados da tabela anterior a ele serão cruzados com os dados da tabela posterior, utilizando a comparação descrita no campo ON. Este comando é um caso especíco do comando JOIN. O prexo INNER indica que apenas os registros que casarem na comparação do campo ON deverão ser retornados; WHERE: dene os ltros que deverão ser aplicados na consulta. De todos os registros resultantes da junção das tabelas envolvidas na consulta, apenas aqueles que atenderem às restrições descritas aqui deverão ser considerados para o resultado; GROUP BY: o resultado da consulta será agrupado pelo(s) campo(s) indicados neste comando. Este comando é utilizado em conjunto com funções de agregação, que, de Página 88 de 120

90 modo geral, geram estatísticas sobre outros campos que não os listados aqui. No caso de nosso exemplo, deseja-se contar os modelos diferentes resultantes da consulta agrupados pelo nome do fabricante; HAVING: esta é outra cláusula de restrição ao resultado da consulta. Aqui, pode-se denir parâmetros para os campos agregados. A diferença primordial entre a cláusula HAVING e WHERE é que os ltros descritos na segunda são aplicados no cálculo da consulta enquanto que os da primeira são aplicados apenas ao resultado pronto. De um modo geral, ltros colocados em WHERE geram consultas mais rápidas do que aqueles denidos em HAVING; ORDER BY: os campos aqui descritos serão utilizados como parâmetro de ordenação do resultado da consulta. Por padrão, os campos são ordenados seguindo em que aparecem. Assim, o SGBD ordena o resultados sobre o primeiro campo, depois, considerando essa primeira ordem, sobre o segundo e assim por diante. A ordenação pode ser ascendente - do menor para o maior - utilizando o suxo ASC após o campo em questão, ou descendente - utilizando o suxo DESC. Por padrão, a ordenação é ascendente em todos os campos listados. Vistos os comandos utilizados, basta agora que analisemos a consulta em questão combinandoa com as informações que são armazenadas nas tabelas de acordo com o estudo das chaves. Vejamos a Figura 6. Figura 6: cláusulas SQL e suas interpretações. Portanto, a resposta da questão é a letra (B). Página 89 de 120

91 37. Assuntos relacionados: Banco de Dados, SQL, Consulta SQL, Banca: Cesgranrio Instituição: IBGE Cargo: Analista de Sistemas - Suporte Ano: 2010 Questão: 45 Considere uma tabela em um banco de dados relacional. A tabela apresenta três atributos do tipo texto, sendo CPF o campo chave. Cliente(CPF, Nome, Endereco) Considerando-se que homônimos são pessoas que possuem o mesmo nome, mas CPF diferentes, a expressão SQL que resulta na lista dos Clientes que têm homônimos, juntamente com o número de homônimos, é: (a). SELECT DISTINCT C1.Nome, C1.CPF, COUNT(C2) FROM Cliente C1, Cliente C2 WHERE C1.Nome = C2.Nome AND C1.CPF <> C2.CPF (b). SELECT Nome, CPF, (SELECT COUNT(*) FROM Cliente C1 WHERE C.Nome = C1.Nome AND C.CPF <> C1.CPF) FROM Cliente C (c). SELECT Nome, CPF, COUNT(Cliente) FROM Cliente GROUP BY Nome, CPF HAVING COUNT(*) > 1 (d). SELECT TOP 1 C1.Nome, C1.CPF, COUNT(*) FROM Cliente C1, Cliente C2 WHERE C1.Nome = C2.Nome AND C1.CPF <> C2.CPF (e). SELECT C1.Nome, C1.CPF, COUNT(*) FROM Cliente C1, Cliente C2 WHERE C1.CPF <> C2.CPF AND C1.Nome = C2.Nome GROUP by C1.Nome, C1.CPF HAVING count(*) > 0 Solução: A resposta da questão é alternativa E. Para compreendê-la, vamos analisar cada uma das partes da consulta mostrada na alternativa. Para facilitar a explicação, abaixo a consulta é mostrada novamente, porém com as linhas numeradas. 1 SELECT C1.Nome, C1.CPF, COUNT(*) 2 FROM Cliente C1, Cliente C2 3 WHERE C1.CPF <> C2.CPF AND C1.Nome = C2.Nome 4 GROUP by C1.Nome, C1.CPF 5 HAVING count(*) > 0 Página 90 de 120

92 Na linha 1, é utilizado o comando SELECT, que indica quais serão as colunas retornadas pela consulta. Foram selecionadas as colunas CPF, NOME. A terceira coluna que será retornada na consulta é a coluna COUNT(*). Na linguagem SQL, o operador COUNT serve para contar a quantidade de ocorrências de uma determinada combinação de valores das colunas. Na consulta em questão, a expressão COUNT(*) irá retornar a quantidade de vezes que uma determinada combinação dos valores da colunas NOME e CPF se repete no resultado da consulta. Para que o operador COUNT funcione, é necessário ainda que se utilize a cláusula GROUP BY, enumerando a combinação de colunas que se deseja agrupar. Na consulta em questão, essa exigência é cumprida na linha 4. Já na linha 2, temos a cláusula FROM, que é utilizada para enumerar as tabelas que serão necessárias para a execução da consulta. Como deseja-se descobrir os clientes homônimos, é necessário que se compare o nome de um cliente com o nome dos demais. Portanto, na cláusula FROM o programador teve que trabalhar com duas tabelas CLIENTE. Em outras palavras, na linha 2 gerou um produto cartesiano da tabela CLIENTE com ela mesma. Para restringir o produto cartesiano mencionado, na linha 3 o programador teve que adicionar algumas restrições. Na primeira delas (C1.CPF <> C2.CPF), o programador garante que o nome de um dado cliente (que é identicado unicamente pelo CPF) só será comparado com o nome dos demais, e não com seu próprio nome. Já na segunda restrição (C1.Nome = C2.Nome), o programador verica se os clientes possuem o mesmo nome. Na linha 5 o programador faz uso da cláusula HAVING, que tem como função restringir os resultados em consultas que façam uso de operadores de agregação, como SUM, COUNT, MEDIA, DEVPAD, entre outros. Na consulta em questão, a expressão utilizada foi HA- VING count(*) > 0, que garante que a consulta só retornará combinações de NOME e CPF que possuam no mínimo 1 ocorrência. Ou seja, só retornará clientes que possuam no mínimo 1 homônimo. Por m, vale ressaltar que a consulta retornará um registro para cada cliente que possuir um homônimo, contendo o CPF do cliente, o seu nome, e a quantidade de homônimos associada. Um exemplo do resultado que poderia ser retornado pela consulta segue abaixo: JOSE DA SILVA JOSE DA SILVA JOSE DA SILVA MICHAEL PAULO MICHAEL PAULO ALEX DA COSTA ALEX DA COSTA ALEX DA COSTA ALEX DA COSTA Página 91 de 120

93 38. Assuntos relacionados: Banco de Dados, SQL, Banca: ESAF Instituição: Agência Nacional de Águas (ANA) Cargo: Analista Administrativo - Tecnologia da Informação e Comunicação / Desenvolvimento de Sistemas e Administração de Banco de Dados Ano: 2009 Questão: 23 Em SQL, a cláusula check aplicada a uma declaração de domínio Solução: (a). permite especicar um predicado que deve ser satisfeito por qualquer valor atribuído a uma variável de determinado domínio. (b). especica um predicado que deve ser satisfeito por uma tupla em uma relação. (c). proíbe a inserção de um valor nulo para as variáveis do domínio. (d). verica se os atributos considerados formam uma chave candidata. (e). não tem efeito, pois não se aplica esta cláusula a declarações de domínio. Uma tabela em um banco de dados é denida por um nome e pelos seus campos (atributos) e restrições. Por exemplo: create table carro ( ) nome placa char (20) not null, char (7) not nul, marca char (50) not nul, ano integer Como pode ser observado, o nome da tabela é carro e possui os seguintes atributos: nome, placa, marca e ano cada um com seu tipo de dado. Cada tipo de dado representa um domínio (intervalo) de valores para um determinado atributo. Assim, um domínio é a coleção de valores permitidos para um atributo. A cláusula check na SQL pode ser aplicada a declarações de domínio. Quando aplicado a um domínio, a cláusula check permite especicar um predicado que precisa ser satisfeito para qualquer valor atribuído a uma variável cujo tipo é o domínio. Por exemplo, uma cláusula check pode garantir que um domínio de idade permita apenas valores maiores do que um valor especicado (pessoa maior de idade). create domain Idade numeric (5,2) constraint teste-valor-idade check (value >= 18) O domínio Idade possui uma restrição que garante que o atributo idade seja maior ou igual a 18 anos. A cláusula constraint teste-valor-idade é opcional usada para atribuir o nome teste-valor-idade a restrição. O nome é usado pelo sistema para indicar a restrição que uma atualização violou. Outro exemplo sobre a cláusula check: um domínio pode ser restrito para conter apenas um conjunto especicado de valores usando a cláusula in: Página 92 de 120

94 create domain TipoConta char(10) constrait teste-valor-idade check(value in ('Corrente','Poupança') ) Desse modo, a cláusula check permite que atributos e domínios sejam restritos, descrevendo um predicado que deve ser satisfeito por qualquer valor atribuído a uma variável de domínio. Portanto, a questão correta é a letra A. Página 93 de 120

95 39. Assuntos relacionados: Banco de Dados, SQL, Data Manipulation Language (DML), Data Denition Language (DDL), Data Control Language (DCL), Banca: ESAF Instituição: Controladoria-Geral da União (CGU) Cargo: Analista de Finanças e Controle - Tecnologia da Informação / Desenvolvimento de Sistemas de Informação Ano: 2008 Questão: 51 Em um banco de dados que utiliza a linguagem SQL para denição, manipulação e controle de dados, é correto armar que os comandos (a). CREATE, DROP e INSERT fazem parte da DML (Linguagem de Manipulação de Dados). (b). GRANT e REVOKE fazem parte da DCL (Linguagem de Controle de Dados). (c). INSERT, UPDATE e SELECT fazem parte da DDL (Linguagem de Denição de Dados). (d). ALTER, DELETE e REVOKE fazem parte da DML (Linguagem de Manipulação de Dados). (e). CREATE, GRANT e DROP fazem parte da DCL (Linguagem de Controle de Dados). Solução: Os Bancos de Dados, em geral, possuem diversos tipos de usuários, desde administradores de bancos de dados (DBAs) até usuários casuais, passando por projetistas de bancos de dados e programadores/analistas de sistemas. Para cada uma desta variedade de usuários, o Sistema de Gerenciamento de Banco de Dados (SGBD) deve proporcionar linguagens e interfaces apropriadas. Em muitos SGBDs onde não há uma clara separação entre os níveis interno e conceitual, uma linguagem chamada Linguagem de Denição de Dados (DDL Data Denition Language) é utilizada pelo DBA e pelos projetistas para denir ambos os esquemas. Em SGBDs onde é mantida uma separação clara entre os dois níveis, a DDL é utilizada para especicar apenas o esquema conceitual e uma outra linguagem, a Linguagem de Denição de Armazenamento (SDL Storage Denition Language), é utilizada para especicar o esquema interno. Para especicar visões de usuários e seus mapeamentos para o esquema conceitual, a Linguagem de Denição de Visão (VDL View Denition Language). Entretanto, na maioria dos SGBDs a DDL é utilizada para denir tanto o esquema conceitual quanto o esquema externo. Os SGBDs oferecem um conjunto de operações para manipulação de dados, como pesquisa, inserção, exclusão e modicação, através de uma linguagem conhecido por Linguagem de Manipulação de Dados (DML Data Manipulation Language). A SQL (Structured Query Language Linguagem de Consulta Estruturada) representa uma combinação de DDL, VDL e DML, além de diretivas para especicar restrições e outras características. A SDL foi um componente da SQL em versões antigas, mas foi removida da linguagem para mantê-la apenas nos níveis conceitual e externo. Em SQL, a DML é composta pelos comandos INSERT, UPDATE e DELETE, que são Página 94 de 120

96 utilizados para inserir, atualizar e excluir registros de uma tabela, respectivamente. Já a DDL possui os comandos básicos CREATE, ALTER e DROP que criam, alteram ou apagam objetos (tabelas, índices e visões) do banco de dados. Para alguns autores, os comandos CREATE VIEW e DROP VIEW comporiam a VDL de SQL. Um outro grupo de comandos de SQL serve para controlar aspectos de autorização de acesso de dados por usuários. Este grupo é chamado de DCL (Data Control Language Linguagem de Controle de Dados) e é composto pelas diretivas GRANT e REVOKE. A primeira, autoriza um usuário a executar operações e a segunda remove ou restringe o acesso. Tem-se ainda a DTL (Data Transaction Language Linguagem de Transação de Dados) que controla as transações em SQL e é composta por BEGIN WORK, COMMIT e ROLL- BACK. A primeira diretiva inicia uma transação e as outras duas nalizam, sendo que COMMIT conclui a execução dos comandos e ROLLBACK desfaz as operações executadas. Embora com apenas um único comando (o comando SELECT), a DQL (Data Query Language Linguagem de Consulta de Dados) é a parte da SQL mais utilizada, permitindo que consultas sejam efetuadas ao banco de dados. Pela teoria exposta, percebe-se que a alternativa b) é a única que apresenta o correto agrupamento de comandos componentes de uma das partes da SQL, sendo a resposta para a questão. Página 95 de 120

97 40. Assuntos relacionados: Banco de Dados, SQL, Triggers, Banca: ESAF Instituição: Receita Federal (RF) Cargo: Técnico da Receita Federal - Tecnologia da Informação Ano: 2006 Questão: 32 Analise as seguintes armações relacionadas a Bancos de Dados e à linguagem SQL: I. A cláusula GROUP BY do comando SELECT é utilizada para dividir colunas em conjuntos maiores de dados relacionados entre si. II. Uma view é uma forma predeterminada de visualizar dados de uma ou mais tabelas como se fosse apenas uma tabela. III. Quando o comando DROP TABLE é executado, as estruturas da tabela e os dados são excluídos. Porém, quando o DROP VIEW é executado, nenhum dado referenciado pela view é afetado. IV. O trigger é um tipo de view criado quando um evento em particular ocorre. Indique a opção que contenha todas as armações verdadeiras. (a). I e II (b). III e IV (c). II e III (d). I e III (e). II e IV Solução: Para esta questão o melhor caminho é tratar item por item para chegar na tão esperada resposta correta. I. ERRADA. A cláusula GROUP BY do comando SELECT é utilizada para agrupar LINHAS em conjuntos de dados relacionados entre si. Cada grupo será formado por linhas que tenham o mesmo valor do atributo denido pela cláusula; II. CORRETA. A view facilita a vida para o usuário sendo que ele pode fazer consultas ou atualizações e estas vão reetir nas respectivas tabelas que estão sendo utilizadas. Uma view proporciona mais segurança, ajuda na prevenção de erros, melhora a performance e faz com que os dados sejam mais compreensíveis para o usuário; III. CORRETA. O comando DROP é utilizado para eliminar tabelas, esquemas, domínios ou restrições. No caso do DROP TABLE duas opções de comportamento podem ser selecionadas: CASCADE: todas as restrições e views que referenciam a tabela são eliminadas juntamente com os dados da tabela e suas estruturas; RESTRICT: a tabela será eliminada somente se ela não for referência em nenhuma restrição ou view. O comando DROP VIEW elimina a view e, como este tipo de tabela é virtual e seus dados são referencia à dados existentes em outras tabelas, nenhum conteúdo será perdido. Uma view também pode ser atualizada e esta atualização é reetida nas tabelas utilizadas na denição da mesma, porém alguns fatores devem ser observados: Página 96 de 120

98 caso seja for formada a partir de uma única tabela, ela deve conter a chave primária e todos os outros atributos com restrição NOT NULL que não tenham um valor DEFAULT especicado; normalmente não é atualizável se for formada por diversas tabelas utilizando-se JOIN; não é atualizável se for denida utilizando a função GROUP BY, HAVING ou funções agregadas (ex.: COUNT, SUM, MAX, MIN e AVG); deve-se adicionar a cláusula WITH CHECK OPTION no momento da especicação da view para que o sistema verique a capacidade de atualização e dena uma estratégia de atualização da view. IV. ERRADA. O trigger é uma função e é utilizada para executar uma ação (execução de SQL's ou de algum programa externo ao Banco de Dados) após a ocorrência de um evento (operações de atualização por exemplo) que atenda uma condição (expressão que retorna um valor VERDADEIRO ou FALSO) especicada durante a denição do trigger. Sendo assim, a resposta correta é a letra C. Página 97 de 120

99 41. Assuntos relacionados: Banco de Dados, Níveis de Isolamento, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 49 Considere o ambiente de uma aplicação multiusuário que acessa um sistema de gerência de banco de dados relacional. Os usuários acessam a aplicação em simultâneo, submetendo transações concorrentes ao banco de dados. Todas as transações realizadas na base de dados, pela referida aplicação, estão denidas com o nível de isoladamente READ COMMITTED (leitura com efetivação). O usuário João está executando, através da aplicação, uma transação T1, composta por vários comandos SQL. Neste caso, é correto armar que (a). o nível de isolamento adotado não irá impedir o aparecimento de linhas fantasmas (phantom) durante a execução de T1. (b). as atualizações de dados realizadas por João dentro de T1 podem ser lidas por outros usuários imediatamente, mesmo antes de João efetivar sua transação. (c). se João abortar a execução de T1 após ter executado, como parte da transação, comandos de atualização de dados, as referidas atualizações não poderão ser desfeitas. (d). no ambiente descrito, a execução intercalada de qualquer conjunto de transações será serializável. (e). devido à utilização do nível de isolamento especicado, enquanto João executar T1, nenhum outro usuário poderá executar comandos no banco de dados. Solução: (A) CORRETA O nível de isolamento de uma determinada transação dene o tipo de bloqueio em relação às operações de leitura. No caso de um nível de isolamento READ UNCOMMITTED (leitura sem efetivação), a transação poderá ler dados que foram modicados por outras transações e que ainda não foram conrmadas. Esses são fenômenos conhecidos como dirty reads (leituras sujas). Já o nível de isolamento READ COMMITTED impede que ocorra dirty reads. Há dois tipos de anomalias que não são resolvidas por esse nível de isolamento: leitura não-repetível e leitura fantasma (phantom). Suponha que duas consultas sejam executadas uma após a outra dentro da mesma transação. No nível de isolamento READ COMMITTED, nada impede que outra transação efetive suas alterações durante a execução da primeira consulta. O comando SELECT, nesse nível de isolamento, enxerga apenas os dados conrmados antes da consulta ser executada. Nesse caso, os resultados das duas consultas realizadas uma após a outra, mesmo pertencentes à mesma transação, podem ser diferentes. Já o fenômeno de leitura fantasma é semelhante à leitura não-repetível no sentido em que Página 98 de 120

100 são necessárias duas consultas com os mesmos critérios para que o fenômeno possa ser observado. Quando os retornos contém as mesmas linhas, mas com dados diferentes, o fenômeno é de leitura não-repetível. Quando a diferença no resultado indica que as linhas não são as mesmas, diz-se que ocorreu uma leitura fantasma. O padrão ISO dene mais dois níveis de isolamento: leitura repetível e leitura serializável. O fenômeno de leitura fantasma só é eliminado no nível serializável, que é o nível mais restrito. (B) ERRADA Para que o citado ocorra, o nível de isolamento deveria ser READ UNCOMMITTED. (C) ERRADA Todo sistema gerenciador de banco de dados deve garantir que uma transação possa ser desfeita para manter a propriedade de atomicidade, que é essencial para a recuperação dos dados em casos de desastre e para a resolução de conitos entre transações. Logo, tal fato é impensável. (D) ERRADA O nível de isolamento citado não permite a serialização em relação as outras transações. Mas vale lembrar que tal nível propicia melhoria do desempenho do sistema. (E) ERRADA Várias transações podem ser executadas simultaneamente, mas respeitando-se os bloqueios que garantem o modo de serialização adotado. Página 99 de 120

101 42. Assuntos relacionados: Banco de Dados, Concorrência entre Transações, SGBD, Banca: CESGRANRIO Instituição: BNDES Cargo: Analista de Suporte Ano: 2008 Questão: 67 Em ambiente de Sistema Gerenciador de Banco de Dados (SGBD) multi-usuários, bloqueios e controles por timestamp (registro de tempo) são mecanismos utilizados para a manutenção da integridade das transações. Sobre tais mecanismos e sua utilização em SGBD relacionais, tem-se que (a). a utilização de intenções de bloqueio visa aumentar a capacidade de concorrência do sistema, no qual são permitidos somente bloqueios e intenções de bloqueio em linhas individuais. (b). a utilização de bloqueios pode ocorrer tanto em linhas de dados quanto em estruturas de maior granularidade, como tabelas, podendo, também, ocorrer em estrutura de índices. (c). o protocolo de bloqueio em duas fases foi desenvolvido para utilização em banco de dados distribuídos, e nele um nó coordenador realiza uma eleição para que cada nó participante indique se pode ou não concluir uma transação. (d). o protocolo de ordenação por timestamp (registro de tempo) é baseado no momento em que um bloqueio foi obtido por uma transação, indicando que esse bloqueio somente pode ser mantido por determinado período de tempo. (e). o protocolo de ordenação por timestamp (registro de tempo) garante que não ocorrerão deadlocks, pois esse protocolo impede que transações mantenham o bloqueio de um objeto por tempo indenido. Solução: Bloqueios permitem que apenas uma única transação manipule (altere) um item de dados em um momento particular. Também é possível o bloqueio multigranular, que permite a uma transação bloquear diferentes tipos de recursos como tabelas e estruturas de índices e, geralmente, esse bloqueio se dá de forma hierárquica, onde o bloqueio explícito de um determinado objeto implica no bloqueio implícito dos seus sub-objetos. Concluímos, assim, que a alternativa B é a alternativa correta e excluímos a alternativa A. O protocolo de bloqueio de duas fases pode ser utilizado em qualquer SGBD, ou seja, ele não foi especicamente desenvolvido para uso em bancos de dados distribuídos, e sim para garantir a serialização de transações. Logo, a alternativa C está errada. O protocolo de ordenação por timestamp atribui um timestamp para cada transação antes que ela inicie e serve para garantir que quaisquer execuções de leitura e escrita sejam executadas por ordem de timestamp. Nesse protocolo não é possível que ocorram deadlocks, pois não é um método baseado em bloqueios de recursos. Entretanto, uma transação pode ser cancelada várias vezes. A alternativas D e E estão erradas, pois não há bloqueios no processo de ordenação por timestamp. O que existem são métodos que se baseiam em timeout para a manutenção do bloqueio por um tempo denido e são especicamente para manuseio de deadlocks, e não um protocolo que garanta a serialização como o protocolo de timestamp. Página 100 de 120

102 43. Assuntos relacionados: Banco de Dados, ACID, Banca: FCC Instituição: MPU Cargo: Analista de Desenvolvimento de Sistemas Ano: 2007 Questão: 63 A classicação das propriedades ACID, em transações de BD, signicam (a). Activity, Commit, Integrity e Direccion. (b). Apresentação, Conclusão, Inferência e Diálogo. (c). Atomicidade, Consistência, Isolamento e Durabilidade. (d). Alteração, Consulta, Inserção e Deleção. (e). Apresentação, Consistência, Independência e Duração. Solução: Uma transação é uma unidade de execução de programa que acessa e, possivelmente, atualiza vários itens de dados em um banco de dados. Para assegurar a integridade dos dados e da própria transação, o sistema de banco de dados deve manter as seguintes propriedades: Atomicidade, Consistência, Isolamento e Durabilidade. Essas propriedades são chamadas de ACID. Para um sistema garantir a propriedade de Atomicidade, ou todas as operações da transação são reetidas corretamente no banco de dados ou nenhuma será, ou seja, uma transação é indivisível. Qualquer ação que constitui falha no sistema, a transação deve ser desfeita (rollback). Quando todas as ações são efetuadas com sucesso, a transação pode ser efetivada (commit). A Atomicidade é garantida pelo próprio sistema de banco de dados, mais especicamente do componente chamado de Gerenciamento de Transações. Na propriedade de Consistência, a execução de uma transação isolada (isto é, sem a execução concorrente de outra transação) preserva a consistência do banco de dados. A Consistência garante que uma transação deve ser um programa correto, e suas ações não devem resultar em violações de restrições de integridade denidas para o banco de dados. Assegurar a propriedade de Consistência após uma transação é tarefa do programador que codica a transação. Embora diversas transações possam ser executadas de forma concorrente (simultânea), o sistema garante que cada transação não toma conhecimento de outras transações concorrentes no sistema. Isto é, a propriedade de isolamento garante que nenhuma outra transação, operando no mesmo sistema, pode interferir no funcionamento da transação corrente. Assegurar a propriedade de Isolamento é de responsabilidade de um componente do sistema de banco de dados chamado Controle de Concorrência. Na propriedade de Durabilidade, depois de uma transação completar com sucesso (commit), as mudanças que ela fez no banco de dados persistem, até mesmo se houver falhas no sistema. A Durabilidade é assegurada também pelo próprio sistema de banco de dados, mais especicamente pelo componente de Gerenciamento de Recuperação. Conforme explicado anteriormente, a alternativa correta da questão é a letra C. Página 101 de 120

103 44. Assuntos relacionados: Banco de Dados, Transações de Banco de Dados, Serialização, Controle de Concorrência, Grafo de Precedências, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 41 Duas transações (T1 e T2) de banco de dados executam as seguintes seqüências de operações: T1: Na tabela DEPARTAMENTO, bloqueia a linha N em modo compartilhado; Na tabela DEPARTAMENTO, lê a coluna DESPESA da linha N; Na tabela DEPARTAMENTO, desbloqueia a linha N; Na tabela PROJETO, bloqueia a linha M em modo compartilhado; Na tabela PROJETO, lê a coluna VERBA da linha M; Na tabela PROJETO, desbloqueia a linha M; Na tabela PROJETO, bloqueia a linha M em modo exclusivo; Na tabela PROJETO, escreve a coluna VERBA da linha M com o valor VERBA + DES- PESA; Na tabela PROJETO, desbloqueia a linha M; T2: Na tabela PROJETO, bloqueia linha M em modo compartilhado; Na tabela PROJETO, lê a coluna VERBA da linha M; Na tabela PROJETO, desbloqueia a linha M; Na tabela DEPARTAMENTO, bloqueia a linha N em modo compartilhado; Na tabela DEPARTAMENTO, lê a coluna DESPESA da linha N; Na tabela DEPARTAMENTO, desbloqueia a linha N; Na tabela DEPARTAMENTO, bloqueia a linha N em modo exclusivo; Na tabela DEPARTAMENTO, es creve a coluna DESPESA da linha N com o valor DES- PESA + VERBA; Na tabela DEPARTAMENTO, desbloqueia a linha N; É correto armar que essas transações (a). não são serializáveis e, portanto, não podem ser executadas concorrentemente. (b). não podem entrar em bloqueio innito porque obedecem ao protocolo de bloqueio em duas fases (two-phase locking). (c). podem entrar em bloqueio innito (deadlock) se executadas concorrentemente. (d). obedecem ao protocolo de bloqueio em duas fases (two-phase locking). (e). são serializáveis e obedecem ao protocolo de bloqueio em duas fases (two-phase locking). Solução: Para resolvermos essa questão, é necessário conhecer, primeiramente o conceito de serialização e concorrência de transações. Todo sistema gerenciador de banco de dados (SGBD) deve garantir que qualquer transação executada por ele atenda aos 4 atributos ACID das transações: Página 102 de 120

104 A - Atomicidade: uma transação é considerada como um elemento único. Isso quer dizer que ela só pode ser efetivada quando todos os comandos nela contidos forem executados sem falhas e na ordem em que foram programados. Em caso de erro, todas as operações devem ser desfeitas. A atomicidade garante que a ideia do usuário de estar executando uma única ação se concretize, muito embora, no banco de dados, essa ação se traduza em uma sequência de comandos e operações; C - Consistência: ao nal de uma transação o banco de dados deve estar em um estado consistente; um estado que esteja de acordo com o esperado pelo sistema a que ele atende, considerando o estado inicial logo anterior à transação; I - Isolamento: as transações não devem afetar o funcionamento umas das outras nem devem enxergar os resultados parciais entre si; D - Durabilidade: o resultado nal de cada transação deve ser permanente. Uma vez completa, o SGBD deve garantir que o novo estado do banco seja o mesmo para qualquer outra transação seguinte. Para garantir essas características das transações, os SGBD's implementam mecanismos de controle de concorrência. Há várias propostas de mecanismos de controle de concorrência. A concorrência de transações é algo desejado, uma vez que possibilita um melhor aproveitamento dos recursos computacionais. Na maioria dos casos, transações irão atuar em dados distintos e, portanto, a paralelização delas permite que os recursos computacionais disponíveis sejam administrados entre elas, aumentando a eciência da máquina. Por exemplo, enquanto uma transação busca dados no disco, outra pode trabalhar com os que já buscou realizando cálculos no processador. A capacidade de um SGBD de paralelizar transações garantindo que o resultado nal do banco seja consistente, ou seja, equivalente a execução serial das transações (isto é, uma após a outra) é conhecida como seriabilidade. A ordem que as operações de transações concorrentes é executada dene um escalonamento dessas transações. Quem dene o escalonamento é o SGBD. A seriabilidade de um escalonamento de transações é ditada pelo grafo de precedência gerado a partir dos tipos de acesso aos dados comuns envolvidos nas transações. Grafos de precedência que gerem ciclos não são serializáveis. Para montar o grafo de precedências de um escalonamento deve-se seguir os seguintes passos: 1. para cada transação Ti participante do esquema S criar um nó Ti no grafo de precedência; 2. para cada operação em S onde Tj executa um read (X) após um write (X) executado por Ti, criar um arco Ti -> Tj no grafo; 3. para cada operação em S onde Tj executa um write (X) após um read (X) executado por Ti, criar um arco Ti -> Tj no grafo; 4. para cada operação em S onde Tj executa um write (X) após um write (X) executado por Ti, criar um arco Ti -> Tj no grafo; 5. um esquema S é serializável se e somente se o grafo de precedência não contiver ciclos. Para chegarmos ao gabarito da questão, o conceito de seriabilidade e a ideia contida na análise de grafos de precedência será essencial. A questão em tela menciona em 3 de suas opções (B, D e E) um tipo de mecanismo de controle de concorrência conhecido como two-phase locking. Este mecanismo prevê duas fases durante a execução da transação: fase de expansão e fase de encolhimento. Página 103 de 120

105 Na fase de expansão, a transação vai realizando bloqueios (locks) nos objetos em que precisa de acesso e não os desbloqueia até a fase seguinte. Esses bloqueios podem ser de 2 tipos: Compartilhado (shared) - onde a própria transação e todas as outras concorrentes podem apenas ler os objetos bloqueados e nenhuma pode alterá-los; Exclusivo (exclusive) - o objeto ca acessível apenas para a transação tendo ela direitos de alterá-lo inclusive. Na fase de encolhimento, a transação não executa mais nenhum bloqueio sobre nenhum objeto e vai gradativamente liberando os bloqueios que conseguiu na fase de expansão conforme não necessita mais deles. Considerando essa característica, é possível ver com um simples exemplo que esse tipo de controle de concorrência pode levar a casos de bloqueio innito (deadlock). Suponha duas transações T3 e T4 escalonadas conforme Figura 7: Figura 7: escalonamento. Nesse escalonamento, ambas as transações cam esperando a liberação de recursos comuns a elas que já foram previamente alocados transversalmente. Nenhuma das duas conseguirá o recurso esperado e nunca terminarão. Esse tipo de problema pode ser corrigido através de outros mecanismos de controle de transações, mas não estão no escopo da questão. Retornando à análise das opções da questão, vemos claramente que as assertivas (B), (D) e (E) estão erradas, visto que as transações não utilizam o mecanismo de two-phase locking. A letra (B) inclusive diz que tal mecanismo impede a ocorrência de bloqueio innito, o que já foi visto que está errado. A letra (E) menciona ainda que as transações são serializáveis, o que também é falso e será mostrado em breve. A opção (C) diz que há possibilidade de bloqueio innito na execução concorrente das transações. Entretanto isso é completamente impossível. As transações da questão mantém bloqueado apenas um objeto por vez. Logo, mesmo que o escalonamento levasse uma a precisar do objeto bloqueado pela outra, eventualmente a transação que detinha o bloqueio o liberaria, permitindo o retorno da execução da que aguardava. Página 104 de 120

106 Durante a prova, é importante utilizar a eliminação de opções erradas como feito acima pois nesse caso os erros estão bastante visíveis. Isso economiza um tempo precioso que você poderá gastar em outras questões ou revisando a prova. A conclusão da exatidão da assertiva (A) depende da análise das operações contidas nas transações e da geração dos grafos de precedência de vários escalonamentos possíveis. Isso demanda muito tempo e, dependendo da situação, pode ser até mesmo impossível. Nesse caso, deve-se reparar que, em qualquer escalonamento proposto, alguma das transações terminará escrevendo em um dos dados que foi lido anteriormente pela outra. Esta, por sua vez, utilizará um dado inconsistente para seus cálculos. Esse fenômeno é conhecido como leitura suja (dirty read), e também deve ser impedido pelos SGBDs. Dessa observação, vê-se que as transações não são serializáveis. Página 105 de 120

107 45. Assuntos relacionados: Banco de Dados, SQL, Gerência de Transações, Visões de Banco de Dados, Banca: Cesgranrio Instituição: BNDES Cargo: Analista de Sistemas - Desenvolvimento Ano: 2008 Questão: 46 Um funcionário, encarregado de vericar o correto funcionamento de uma base de dados relacional, faz o seguinte teste: select nome from emp where matr = 123; O resultado é vazio. Então ele executa: insert into emp(matr, nome, salario, ativo) values (123, `José da Silva', 2000, `N'); commit; Por m, para ve- O banco de dados não retorna erro e informa que inseriu uma linha. ricar, ele consulta novamente: select nome from emp where matr = 123; O resultado continua vazio. Supondo que o sistema gerenciador de banco de dados esteja funcionando corretamente, que opção explica o ocorrido? (a). Como o funcionário executou o primeiro SELECT momentos antes de executar o INSERT, o resultado cou na memória cache do computador e não foi executado pelo banco de dados na segunda vez. Somente após protocolo LRU ter retirado do cache o resultado do SELECT é que ele será novamente executado. (b). Como emp é uma visão e uma visão é nada menos que uma consulta gravada no banco de dados, nunca é possível usá-la em operações de manipulação de dados. O COMMIT ignora a inserção anterior. (c). emp é uma visão que retorna todos os empregados ativos (ativo='s'), mas foi criada sem a expressão WITH CHECK OPTION, que evitaria o problema acima. (d). emp não é uma tabela, mas uma visão que retorna todos os empregados ativos (ativo='s') e foi criada com a expressão WITH CHECK OPTION. Dessa forma, como o empregado José da Silva não está ativo, o banco de dados não gravou o registro no momento do COMMIT. (e). O funcionário executou o SELECT pouco tempo após a inserção do registro. Mesmo nalizando a transação com o COMMIT, o registro está em memória e ainda não foi gravado no disco. Somente após o CHECKPOINT é que o registro estará disponível para consulta. Solução: O comando COMMIT efetiva a transação sendo executada. Todas as modicações efetuadas pela transação se tornam visíveis para os outros, e existe a garantia de permanecerem se uma falha ocorrer, pois o sistema gerenciador de banco de dados mantém um registro, chamado log, de todos os dados que foram escritos no bando de dados. O log é utilizado Página 106 de 120

108 para garantir a propriedade de durabilidade se o sistema sofrer uma queda antes que as alterações geradas por uma transação que foi executada satisfatoriamente forem persistidas em disco, o log é utilizado para restaurar essas informações quando o sistema for normalizado. Eventualmente, a transação pode não ter sido efetivada com sucesso, neste caso o sistema gerenciador de banco de dados se encarrega em desfazer as alterações. Entretanto, não é o caso da questão, pois a informação de que uma linha foi inserida e a existência do COMMIT indica que a transação foi efetivada com sucesso. No COMMIT, os dados que foram alterados ou inseridos na transação são imediatamente visíveis para consultas que são executadas depois. Esse fato elimina as alternativas (A) e (E). Views são consultas SQL que, em situações diversas, podem ser utilizadas no papel de tabelas relacionais. Entretanto, diferentemente das tabelas, os registros de uma view não são armazenados na base de dados. Podemos imaginar uma view como uma tabela que tivesse uma instância virtual, que é construída cada vez que a mesma é invocada. Quando uma view é referenciada em expressões SQL, o gerenciador de bancos de dados manipula o resultado da consulta que dene a view como se fosse uma tabela normal. A similaridade com tabelas estende-se ao ponto de permitir atualizações sobre os virtuais registros de uma view. Quando um novo registro é inserido, ou quando um registro existente é alterado ou removido, na verdade o SQL inclui, altera ou remove registros nas tabelas que compõem a view. Esse fato elimina a alternativa (B). Cada implementação tem critérios ligeiramente diferentes para decidir se uma view pode ou não ser atualizada. Como norma geral, entretanto, as seguintes restrições devem ser observadas na construção de uma view para que a mesma seja atualizável. Uma coluna atualizável não pode ser resultante de: funções de agregação, tais como sum, avg, etc.; funções escalares, tais como sin, trim, etc.; expressões aritméticas; expressões condicionais, tais como case, iif, etc.; literais; subconsultas. Uma view atualizável deve conter pelo menos uma fonte de registros atualizável referenciada na cláusula from. Uma view atualizável não pode conter: operadores algébricos, tais como union; a cláusula group by; a cláusula distinct. As restrições acima formam um conjunto genérico de características das views atualizáveis. Essas regras, entretanto, devem ser analisadas à luz das operações pretendidas. Por exemplo, uma view que tenha algumas colunas baseadas em expressões aritméticas talvez não possa ser objeto de um comando update nesses atributos, mas pode permitir a remoção de registros. Por este e outros motivos, a lida de cada implementação com essa questão varia bastante, e cada caso merece uma análise cuidadosa. Página 107 de 120

109 Em views atualizáveis, temos a opção CHECK OPTION no momento de sua criação. Todos os comandos INSERT e UPDATE em uma view serão vericadas para garantir que os dados satisfazem as condições que denem a visão. Se não satiszer, a atualização será rejeitada. Analisando as alternativas que ainda não foram eliminadas (C e D), supomos que a view em questão representa todos empregados ativos (ativo='s'). Como a inserção trata da inserção de um empregado inativo, a existência da opção CHECK OPTION impediria a sua inserção, mas não foi o que ocorreu, já que fomos informados de que uma linha foi inserida. Logo, concluímos que a opção CHECK OPTION não foi utilizada na denição da view emp e, portanto, a alternativa C representa a alternativa correta. Página 108 de 120

110 46. Assuntos relacionados: Banco de Dados, Escalonamento de Banco de Dados, Serializabilidade, Durabilidade, Leitura Limpa, Clean Read, Leitura Suja, Dirty Read, Missing Deadlock, Deadlock Ausente, Commit Alcançado, Reached Commit, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas - Processos de Negócio Ano: 2008 Questão: 28 A execução de um conjunto de transações em um banco de dados é chamado de escalonamento. O critério para um escalonamento ser considerado correto é a(o) (a). serializabilidade. (b). durabilidade. (c). leitura limpa (clean read). (d). deadlock ausente (missing deadlock). (e). commit alcançado (reached commit). Solução: A serializabilidade consiste em, dado um conjunto de transações, independentemente da forma como seus comandos são intercalados na execução, o resultado obtido equivale à execução serial das transações. O escalonamento de transações em um SGBD (Sistema Gerenciador de Bancos de Dados) deve ter como alvo a serializabilidade, de forma a garantir a integridade das informações. Sendo assim, a opção correta é a letra (A). As demais opções tratam de características das transações em si ou mesmo de características que, juntas, traduzem a intenção da serializabilidade. A durabilidade, citada na letra (B), é uma das 5 características ACID desejadas para as transações em si. Ela diz que as alterações geradas por uma transação devem permanecer no banco após a efetivação da mesma, garantindo sua efetivação real. No caso de uma falha do sistema, a transação que tiver sido efetivada deve permanecer efetivada no banco para que a durabilidade seja atendida. Repare que essa característica é imprescindível para as transações e não para o escalonamento. A leitura limpa é uma das características que compõe a serializabilidade. Ela prevê que, diferentemente da leitura suja, os dados lidos pelas transações estejam sempre coerentes com o estado do início da transação e sejam sempre coerentes. O deadlock ausente é outra característica que compõe a serializabilidade. Nesse caso, o escalonamento, tal qual a execução serial das transações, deve impedir que os recursos cedidos à transações concorrentes não gerem conitos de interesse entre ambas e impeça mutuamente a execução destas. Estas características são tratadas no controle de concorrência. Entretanto, estão intimamente ligadas ao escalonamento, visto que inuenciarão diretamente nele. Página 109 de 120

111 47. Assuntos relacionados: Banco de Dados, Concorrência entre Transações, Banca: Cesgranrio Instituição: Petrobras Cargo: Analista de Sistemas - Infraestrutura Ano: 2008 Questão: 57 Considere as duas transações (T1 e T2) de banco de dados abaixo. read_lock - implementa bloqueio compartilhado no item de banco de dados write_lock - implementa bloqueio exclusivo no item de banco de dados unlock - desbloqueia o item de banco de dados read_item - executa a leitura do item write_item - executa a escrita do item É correto armar que estas transações (a). seguem o protocolo de bloqueio em duas fases e não entram em impasse (deadlock), se executadas concorrentemente. (b). podem entrar em impasse (deadlock), se executadas concorrentemente. (c). são serializáveis e não seguem o protocolo de bloqueio em duas fases. (d). não são serializáveis e, portanto, podem ser executadas concorrentemente. (e). não seguem o protocolo de bloqueio em duas fases, não sendo portanto serializáveis. Solução: Uma transação é uma unidade lógica de processamento que pode incluir uma ou mais operações sobre o Banco de Dados. Entende-se por transações concorrentes aquelas que são executadas ao mesmo tempo e pelo menos uma operação WRITE é executada por alguma das transações. Podemos observar que estas duas transações implementam o protocolo de bloqueio de duas fases (Two-Phase Locking - 2PL), pois ambas possuem uma fase de crescimento (growning) e uma fase de encolhimento (shrinking), em que todos os read_locks e write_locks ocorrem na primeira fase, enquanto que os unlocks ocorrem na segunda fase (na verdade, tão logo a transação libera um bloqueio, ela entra na fase de encolhimento e não poderá solicitar novos bloqueios). Portanto, podemos descartar as alternativas C e E. Lembre-se que a instrução read_lock permite que outras transações apenas leiam o mesmo item de dado e a write_lock impede que qualquer operação de escrita ou leitura possa ser realizada por outra transação sobre um item que esteja bloqueado para escrita. Além disso, a qualquer hora podem ser feitos diversos bloqueios compartilhados (read_lock) simultaneamente (por diferentes transações) sobre um item de dado particular. Já uma solicitação de Página 110 de 120