Handbook Questoes Banco de Dados

(1)

Questões comentadas

Bancos de dados

para

concursos

(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 ope-raçõ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,

(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óxi-mos 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 comuni-dade 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.

(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 http://www.handbookdeti.com.br Serviço de Atendimento

Comunique-se diretamente conosco através do e-mail faleconosco@handbookdeti.com.br Twitter do Handbook de TI

Acompanhe de perto promoções e lançamentos de produtos pelo nosso Twitter http://twitter. com/handbookdeti

(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 Rela-cional

(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 tabe-las, 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 proce-dures 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.

(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 cha-madas tablespaces, que coletivamente armazenam os dados do banco de dados. Cada ta-blespace, 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 pri-má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 infor-maçõ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

(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.

(8)

Questão: 31

São apenas tipos de objetos de um schema Oracle: (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. Solução:

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 tabe-las, 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 Ora-cle, 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 especi-car 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 materia-lized 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 propor-cionar um nível adicional de segurança, restringido acesso a determinados conjunto de

(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 compara-tivo entre os índices b-tree e bitmap do Oracle pode ser vista no estudo disponível em http://www.oracle.com/technology/pub/articles/sharma_indexes.html.

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 tabe-las, 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 clus-ter é 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 men-cionado 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.

(10)

(11)

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 ins-truçõ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 de-dicado 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 ser-ver.

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, re-cupera 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

(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 periodica-mente;

• 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.

(13)

5. Assuntos relacionados: Oracle, SQL, Banca: FCC

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 lin-guagem 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

(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 exibi-lidade e aproveita o poder das linguagens procedurais para o desenvolvimento de programas complexos que envolvam acesso ao banco de dados Oracle.

(15)

6. Assuntos relacionados: Banco de Dados, Commit, Savepoint, Rolling Back, Rolling Forward,

Banca: FCC

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, estrategica-mente, 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 alte-raçõ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.

(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.

(17)

7. Assuntos relacionados: Banco de Dados, PL/SQL, Banca: FCC

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 desen-volvedores 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 procedi-mentos.

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

(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 se-guintes 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.

(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 automati-camente 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 satis-feitas: 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 Ma-nipulação de Dados (DML - Data Manipulation Language): INSERT, DELETE e UPDATE.

(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 ne-nhum argumento e retornando o tipo TRIGGER, que é executada quando o gatilho dispara;

• FOR EACH ROW / FOR EACH STATEMENT: especica se o procedimento do ga-tilho deve ser disparado uma vez para cada linha afetada pelo evento do gaga-tilho, 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 res-pectivos 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 mu-danç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.

(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áu-sula 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 tam-bém podem executar comandos de Linguagem de Denição de Dados( DDL - Data Denition Language). Portanto, armativa correta.

(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 co-mandos 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, con-sulta 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 uti-lizaçã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 in-formar 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;

(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 ar-quivos de banco de dados. REUSE DATABASE e RESET BLOG não são comandos T-SQL.

(24)

10. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Banca: CESGRANRIO

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 fos-sem 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 EMAIL 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 en-tidades e os objetos representados por elipses são atributos.

(25)

Uma entidade é um objeto que pode ser identicado de forma unívoca a todos os outros ob-jetos. 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 2367727 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 mul-tivalorados 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 res-pectivos 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 represen-tados 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 rela-cional derivada representa uma visão ou o resultado de uma consulta.

O modelo relacional derivado do primeiro modelo entidade-relacionamento pode ser des-crito da seguinte maneira:

Funcionario(email, nome) Usuario(email, nome, login)

Segundo o enunciado, após a generalização, a variável de relação Funcionario será man-tida 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:

(26)

Isso pode ser feito, já que, na generalização, foi criado um relacionamento de muitos-para-um com a variável de relação Funcionario. Sendo assim, o campo e-mail 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 deri-vada 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 Fun-cionario 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.

(27)

11. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Banca: FCC

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 precisa-se 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 espe-ciais 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 é com-posto pelo chassis, motor, direção, câmbio etc. O motor, por sua vez, é formado pelo carbu-rador, 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

(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.

(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 de-terminado 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.

(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 candi-dato 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 atri-buto 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 con-sideraçã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 mo-delo 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 imple-mentado 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 enti-dades 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.

(31)

13. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Modelo Re-lacional, 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 inte-gridade dos dados.

Existem 3 (três) tipos básicos de relacionamento entre as entidades de acordo com a cardi-nalidade:

• 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 re-lacionar 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.

(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 car-dinalidades 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 qual-quer 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 Cardinali-dade 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 ne-nhum 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 in-clusã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

(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 enunci-ado. 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 possi-bilidade 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.

(34)

14. Assuntos relacionados: Banco de Dados, Modelo Entidade-Relacionamento, Modelo Re-lacional,

Banca: Cespe

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 den-tro de um banco de dados.

(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 atri-butos 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 corresponden-tes à 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 é re-presentado 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;

(36)

• CURSOS é administrado por DEPARTAMENTOS. Um curso é administrado por de-partamento. 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 diver-sas 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.

(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.

(38)

15. Assuntos relacionados: Banco de Dados, Modelagem de Dados, Superchave, Chave Se-cundá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 / Desenvolvi-mento 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 relaciona-das: 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 ci-fragem com o uso da chave pública e decici-fragem 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, normal-mente 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á atribu-tos redundantes. Ou seja, não é possível remover qualquer atributo desse conjunto sem quebrar a restrição da superchave identicar tuplas distintas.

(39)

(D) INCORRETA

Uma chave secundária é uma chave que, normalmente, não identica unicamente um re-gistro e que pode ser utilizada para buscas simultâneas de vários rere-gistros. 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 alter-nativa que responde de maneira correta esta questão. Por esse motivo, esse conceito não será discutido.

(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 / Desenvolvi-mento 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 cons-truçã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 repre-senta uma coleção de valores de dados relacionados. Nessa reprerepre-sentaçã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 descre-ver, 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 dis-tinguí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.

(41)

relacionamento trabalha para, por exemplo, pode relacionar empregador e empregados. A principal ferramenta do modelo de relacionamento é o diagrama de entidade-relacionamento. Nele, retângulos representam entidades, elipses representam atributos, lo-sangos representam relacionamentos e linhas ligam atributos a entidades e entidades a re-lacionamentos. 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).

Figura 3: exemplo de diagrama entidade-relacionamento. (C) INCORRETA

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, impe-dindo o acesso direto ao estado de um objeto (seus atributos), disponibilizando exter-namente 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.