aula 00 demonstrativa trf1 2014 tecnico informatica banco de dados 2853

TRF 1 RegioTcnico Judicirio-Informtica Banco de Dados - Aula 00

Exerccios Comentados

Luis Octvio Lima

www.tiparaconcursos.net Pgina 1 de 75

AULA 00: Abstrao e modelo de dados. Sistemas gerenciadores de banco de dados (SGBD).

Sumrio 1. Apresentao. ................................................................................................................................. 2

1.1. A Banca. ...................................................................................................................................... 2

1.2. Metodologia das aulas. ............................................................................................................... 2

1.3. Observaes finais. ..................................................................................................................... 3

3. Bibliografia ...................................................................................................................................... 4

4. Sistemas gerenciadores de banco de dados (SGBD). Abstrao e Modelo de Dados. ................... 4

5. Lista das Questes Utilizadas na Aula. .......................................................................................... 61

6. Gabarito. ....................................................................................................................................... 75

Ol futuros tcnicos do Tribunal Regional Federal !

A partir de agora vamos dar incio a to sonhada trajetria para se tornar um servidor

pblico federal, conquistando uma vaga no cargo de Tcnico Judicirio Especialidade:

Informtica do TRF 1 Regio.

O nosso principal objetivo cobrir os itens relativos ao assunto de Banco de Dados do

edital na forma de exerccios comentados, mtodo o qual julgo ser eficiente, pois possibilita

ao candidato a rpida assimilao de contedo de forma prtica e focada, porm isso no

quer dizer que o estudo prvio terico seja menos importante, nada disso, muito pelo

contrrio, o conhecimento terico prvio proporcionar ao candidato uma base de

conhecimento a qual ser lapidada, moldada e aperfeioada atravs dos exerccios, pois so

eles quem de fato vo definir se seu conhecimento para o cargo desejado est dentro do

nvel esperado.

A cada aula citarei as fontes tericas usadas para satisfazer as respostas das questes,

sendo dentre elas, os livros do Navathe, Date e Korth as mais importantes, alm de fontes

complementares.

Sobre a minha pessoa, estou no servio pblico federal a cerca de 4 anos e meio,

sendo parte deles na Fundao Nacional de Sade FUNASA, onde fiquei apenas 8 meses

trabalhando no cargo de Analista de Sistemas, atuando na rea de processos, depois fui



Luis Octvio Lima


nomeado pelo Ministrio do Planejamento, Oramento e Gesto MPOG para o cargo de

Analista em TI, o qual estou at o momento, onde atuei na rea de requisitos de negcio do

Portal dos Convnios SICONV e atualmente na gesto do Data Warehouse do Sistema de

Administrao e Servios Gerais SIASG, ambos na Secretaria de Logstica e Tecnologia da

Informao SLTI.

1. Apresentao.

1.1. A Banca.

A banca escolhida para este concurso foi a Fundao Carlos Chagas - FCC, banca que

costuma trazer suas questes no estilo mltipla escolha, o que agrada muitos candidatos

por no existir o to temido critrio de uma errada anula uma certa usado pela banca

CESPE/UnB. Porm, isso no aumenta muito as chances lquidas de aprovao do candidato,

pois o mesmo precisa estudar bem o assunto, pois a FCC costuma vez por outra trazer

questes cuja fonte da resposta encontra-se em locais menos esperados, inclusive da

Wikipedia.

As questes, no geral, trazem muitos peguinhas para provocar o erro do candidato,

alm de muitas vezes exigirem mais da capacidade de memria do candidato em decorar

alguns conceitos do que propriamente entende-los.

Vamos trabalhar, durante a resoluo das questes, todos esses aspectos sobre a

banca, a fim de conseguir xito no resultado final, que a sua aprovao.

1.2. Metodologia das aulas.

a) O curso ser todo baseado em questes comentadas, focadas no edital e na banca

escolhida para realizao da prova;

b) O conhecimento prvio sobre o assunto ajudar muito na compreenso dos

comentrios, porm sua ausncia no comprometer o entendimento dos

comentrios das questes;

c) Sempre que possvel, disponibilizarei na aula seguinte mapas mentais e/ou

esquemas para ajudar no processo de reviso da aula anterior e tambm servir

para reviso na semana que antecede a prova;



Luis Octvio Lima


d) Todos os comentrios tero por base as tendncias de cobrana da banca, procure

valorizar cada comentrio a fim de que na hora da prova possa lembra-los e partir

para o abrao;

e) Durante a sequncia de questes voc perceber que na medida em que avano nas

questes e consequentemente no assunto, tambm darei alguns passos para trs

trazendo alguma questo na sequncia que se refira a um assunto de algumas

questes feitas anteriormente. Isso de propsito, pois importante a sistemtica

da repetio, no digo a repetio da mesma questo, mas do assunto abordado

nela, pois quanto mais maduro o assunto fique em mente, melhor para o

candidato no momento da prova.

1.3. Observaes finais.

a) Este formato de aula textual procura seguir um perfil mais informal do que o de um

livro escrito sobre o assunto, isso porque tentamos, ao mximo, trazer para o texto o

mesmo cenrio de uma sala de aula, ou seja, com algumas informalidades e

descontraes, porm preservando o principal foco que o concurso em questo e,

lgico, a sua aprovao.

b) Tentem dividir bem o tempo de estudos de acordo com o contedo programtico,

pois assim ser possvel prever quando vocs estaro concluindo cada etapa e j

podendo iniciar o processo de repetio com base em revises e resolues de mais

questes, chegando assim no dia da prova com tranquilidade para assinalar

corretamente as questes e garantir a vitria.

2. Contedo programtico e planejamento das aulas (Cronograma).

O Contedo programtico est distribudo de tal forma que os alunos, mesmo que

nunca tenham tido contato com o assunto, possam compreender o contexto da disciplina e

tambm a forma com que ela se encaixa dentro das instituies e que pode ser cobrada

na prova.

As questes usadas neste material foram selecionadas criteriosamente, com a

finalidade de agregar valor de conhecimento a cada comentrio, seguindo uma escala

crescente no grau de dificuldade e reaproveitamento de conceitos.



Luis Octvio Lima


A ordem do contedo seguida nem sempre corresponder ordem que foi publicada

no edital, isso se deve ao fato de que procurei agrupar cada tpico da melhor forma para

que voc possa fazer o link entre os conceitos e conhecimentos vistos, onde o objetivo no

final ter todo o contedo em mente e com capacidade de argumentao entre eles.

Vamos ao cronograma!

Aula Contedo a ser trabalhado

Aula Demonstrativa

25/06/2014

Abstrao e modelo de dados;

Sistemas gerenciadores de banco de dados (SGBD);

Aula 1 16/07/2014

Linguagens de definio e manipulao de dados;

Linguagens de consulta (query language) SQL e PL/SQL;

Aula 2 04/08/2014

Conhecimentos de SGBD Oracle e Postgresql.

Organizao de arquivos e mtodos de acesso;

3. Bibliografia

Nesta aula utilizei as seguintes fontes, tanto em contedo, quanto em figuras:

1. Elmasri, R. & Navathe. Sistema de Banco de Dados. 6. Ed. Pearson.

2. Korth, H. & Silberschatz. A. Sistemas de Bancos de Dados. 5 Ed. Campus.

3. Helser, Carlos Alberto. Projeto de Banco de Dados. 4.Ed. Sagra Luzzatto.

4. Date, C.J. Introduo a Sistemas de Bancos de Dados. 8.Ed. Campus.

4. Sistemas gerenciadores de banco de dados (SGBD). Abstrao e Modelo

de Dados.

Apesar deste tpico do edital ser to curto, o seu contedo pode no ser e isso

muito perigoso, pois muitos candidatos tendem a estudar o assunto de forma superficial

achando que foi o suficiente para atender este tpico e na verdade esto enganados. Por

trs deste tpico existem vrios conceitos que podem ser cobrados e a banca se aproveita



Luis Octvio Lima


justamente disso para explorar o candidato e tentar derrub-lo. Esta aula extensa por

justamente tentar cobrir ao mximo todas as lacunas existentes sobre o assunto.

Vamos dar incio ao assunto conhecendo sobre o que vem a ser um Banco de Dados e

um Sistema Gerenciador de Banco de Dados SGBD. Nada melhor do que ler o que um

autor consagrado da rea tem a dizer.

Segundo Navathe:

Um banco de dados representa algum aspecto do mundo real, s vezes chamado de

minimundo. As mudanas no minimundo so refletidas no banco de dados.

Um banco de dados projetado, construdo e populado com dados para uma finalidade

especfica. Ele possui um grupo definido de usurios e algumas aplicaes previamente concebidas

nas quais esses usurios esto interessados.

Um Sistema Gerenciador de Banco de Dados SGBD uma coleo de programas que

permite aos usurios criar e manter um banco de dados. O SGBD um sistema de software de uso

geral que facilita o processo de definio, construo, manipulao e compartilhamento de banco de

dados entre diversos usurios e aplicaes.

Segundo Date:

O SGBD o software que trata de todo o acesso ao banco de dados

Um usurio faz um pedido de acesso usando uma determinada Sublinguagem de dados

(geralmente SQL). O SGBD intercepta o pedido e o analisa. O SGBD, por sua vez, inspeciona o

esquema externo (ou as verses objeto desse esquema) para esse usurio, o mapeamento

externo/conceitual correspondente, o esquema conceitual, o mapeamento conceitual/interno e a

definio do banco de dados armazenado



Luis Octvio Lima


Alm disso, um SGBD armazena o resultado das especificaes dos tipos, estruturas e

restries de dados. As definies so armazenadas no SGBD atravs do catlogo ou

dicionrio de dados, tambm chamado de metadados.

Quanto manipulao, um SGBD inclui funes de consultas aos dados armazenados,

bem como para alterao destes dados. Permite tambm realizar o compartilhamento de

seus dados para diversos usurios e programas, para que haja acesso simultneo. As

operaes sobre os dados, onde ocorrem leituras e gravaes so chamadas de transaes.

Segue uma figura abaixo retirada do livro do Navathe e que retrata bem o que

falamos at agora:

Na criao de um banco de dados em um SGBD, levado em considerao a

necessidade de satisfazer vrias vises da soluo em diferentes nveis. Tais nveis vo desde

uma viso mais alto nvel, ou seja, prxima ao usurio (menos tcnica e independente e

tecnologia) at uma viso de mais baixo nvel, ou seja, mais prximo da tecnologia, onde

ficaro todas as definies fsicas de arquivos de dados, de ndices, espao de

armazenamento, restries de integridade, dentre outras.

A arquitetura ANSI traz esta viso, atravs da arquitetura em trs nveis. Vejam

abaixo uma figura sobre a referida arquitetura:



Luis Octvio Lima


Vejamos o que Navathe fala sobre os diferentes nveis:

O nvel interno tem um esquema interno, que descreve a estrutura de armazenamento fsico

do banco de dados. Esse esquema utiliza um modelo de dado fsico e descreve os detalhes complexos

do armazenamento de dados e caminhos de acesso ao banco de dados.

O nvel conceitual possui um esquema conceitual, que descreve a estrutura de todo o banco

de dados para a comunidade de usurios. O esquema conceitual oculta os detalhes das

estruturas de armazenamento fsico e se concentra na descrio de entidades, tipos de dados,

conexes, operaes de usurios e restries. Geralmente, um modelo de dados representacional

usado para descrever o esquema conceitual quando o sistema de banco de dados for

implementado. Esse esquema de implementao conceitual normalmente baseado em um

projeto de esquema conceitual em um modelo de dados de alto nvel.

O nvel externo ou viso (view) abrange os esquemas externos ou vises de usurios. Cada

esquema externo descreve a parte do banco de dados que um dado grupo de usurios tem interesse

e oculta o restante do banco de dados desse grupo. Como no item anterior, cada esquema externo

tipicamente implementado usando-se um modelo de dados representacional, possivelmente

baseado em um projeto de esquema externo em um modelo de dados de alto nvel.

Esta arquitetura ajuda inclusive a definir o conceito entre independncia de dados,

vejamos abaixo o que o Navathe fala sobre o assunto:



Luis Octvio Lima


Independncia Lgica de Dados: a capacidade de alterar o esquema conceitual sem ter

de alterar os esquemas externos ou os programas da aplicao. Podemos alterar o esquema

conceitual para expandir o banco de dados(acrescentando um tipo de registro ou item de dado),

para alterar restries ou para reduzir o banco de dados(removendo um tipo de registro ou item de

dado).

Independncia Fsica de Dados: a capacidade de alterar o esquema interno sem ter de

alterar o esquema conceitual. Logo, os esquemas externos tambm no precisam ser alterados.

Mudanas nos esquemas internos podem ser necessrias porque alguns arquivos fsicos foram

reorganizados por exemplo, ao criar estruturas de acesso adicionais para melhorar o

desempenho da recuperao ou atualizao.

...em geral, a independncia fsica de dados existe na maioria dos bancos de dados e

ambientes de arquivo, nos quais detalhes fsicos, como a localizao exata dos dados no disco, e

detalhes de hardware sobre codificao do armazenamento, posicionamento, compactao,

diviso, mesclagem de registros, e assim por diante, so ocultados do usurio. As demais aplicaes

ignoram esses detalhes. Por sua vez, a independncia lgica de dados mais difcil de ser alcanada

porque permite alteraes estruturais e de restrio sem afetar os programas de aplicao um

requisito muito mais estrito."

O que voc candidato deve ter em mente uma viso integrada de assunto Banco de

Dados, com o assunto Engenharia de Software, mas no se assuste caso ainda no tenha

estudado a disciplina de Engenharia de Software, pois vou explicar de uma forma que voc

vai entender e sair do outro lado tranquilamente.

Vamos usar um exemplo:

Tenha em mente que uma empresa ou organizao, seja ela privada ou pblica,

precise desenvolver uma soluo a fim de melhorar ou sistematizar rotinas de trabalho de

uma determinada rea, para isso foi requisitada uma equipe para fazer o levantamento

das necessidades e particularidades do negcio que se deseja desenvolver tal soluo.

Neste momento foi iniciada a etapa de Levantamento de Requisitos. Dentre os vrios

requisitos, existem os Requisitos de Dados, onde estes sero insumo para a construo do

Modelo Conceitual de dados.



Luis Octvio Lima


O Modelo Conceitual ser formado por um esquema conceitual, que nada mais do

que uma descrio concisa dos requisitos de dados por parte dos usurios, alm dos tipos

de entidades, relacionamentos e restries. Este modelo no traz nenhum detalhe sobre a

tecnologia que ser usada na soluo de banco de dados, pois se trata ainda de um modelo

de alto nvel, ou seja, esta mais perto do usurio final do que do tcnico responsvel pela

implementao do banco de dados (baixo nvel), sendo ento marcado pela simplicidade e

com descrio de fcil entendimento. De posse deste modelo, segue-se para o processo de

mapeamento entre o Modelo Conceitual e o Modelo Lgico de dados.

Segue um exemplo:

A figura acima mostra o relacionamento(figura do losango) entre duas

entidades(Produto e Tipo de Produto), junto com seus respectivos atributos

Produto(cdigo, preo, descrio) e Tipo de Produto(cdigo, descrio), representados

pela figura do retngulo. O atributo cdigo vem representado com uma bolinha preta,

o que significa um dado nico na sua entidade respectiva, servindo de referncia para o

uso da entidade Produto e da entidade Tipo de Produto, ou seja, o cdigo do

produto e o cdigo do tipo de produto. Alm disso foi definida a cardinalidade 1:n

entre as entidades, neste caso, um(1) tipo de produto pode se relacionar com vrios

produtos(n).

O Modelo Lgico marcado pela transformao do Modelo Conceitual para um

modelo de implementao, que vai variar de acordo com a tecnologia a ser usada pelo



Luis Octvio Lima


Sistema Gerenciador de Banco de Dados-SGBD definido, como a definio de padres e

nomenclaturas, chaves primrias e estrangeiras, sempre levando em conta o modelo

conceitual criado anteriormente. Hoje em dia essa transformao j pode ser feita de

forma automtica pelas ferramentas de projeto de banco de dados existentes no mercado,

sendo possvel definir as entidades(tabelas), atributos(campos) e relacionamentos,

envolvidos no levantamento de requisitos. Este modelo j pode ser usado como entrada

para o Modelo Fsico de dados, aonde ento chegamos ao mais baixo nvel(mais perto da

tecnologia, dos arquivos).

Segue um exemplo:

Na figura acima possvel ver que as entidades definidas no Modelo Conceitual

foram mapeadas em tabelas, sendo que na tabela Produto possvel perceber a presena

de um atributo chamado CodTipoProd, tambm existente na tabela TipoDeProduto,

isso demonstra o vnculo ou relacionamento entre as tabelas, o que foi visto no modelo

conceitual atravs da figura do losango.

Outra forma de definir o Modelo lgico atravs da representao textual, ou seja, a

figura acima poderia ser vista da seguinte forma:

TipoDeProduto (CodTipoProd, DescrTipoProd)

Produto(CodProd, DescrProd, PrecoProd, CodTipoProd) CodTipoProd referencia

TipoDeProduto

O Modelo Fsico caracterizado pela definio das estruturas de armazenamento

internas, bem como a organizao de arquivos ndices, caminhos de acesso. Os parmetros

fsicos do projeto para os arquivos do banco dados sero especificados neste modelo.



Luis Octvio Lima


Agora vejam o que Date diz (FCC adora o Date viu ):

...observe que os sistemas relacionais s exigem que o banco de dados seja percebido pelo

usurio como tabelas. As tabelas so a estrutura lgica em um sistema relacional, no estrutura

fsica. No nvel fsico, de fato, o sistema livre para armazenar os dados do modo que preferir

usando arquivos sequenciais, indexao, hashing, cadeia de ponteiros, compactao, etc. desde

que ele possa mapear essa representao armazenada como tabelas no nvel lgico. Outra maneira

de dizer a mesma coisa afirmar que as tabelas representam uma abstrao do modo como os

dados esto armazenados fisicamente uma abstrao na qual diversos detalhes do nvel de

armazenamento(como posicionamento de registros armazenados, sequncia de registros

armazenados, representao de valores de dados armazenados, prefixos de registros armazenados,

estruturas de acesso armazenadas, como ndices, e assim por diante) esto todos ocultos do

usurio.

Na verdade, a teoria relacional como tal no tem absolutamente qualquer relao com o

nvel interno, ela se preocupa, vale a pena repetir, com a aparncia do banco de dados para o

usurio. A nica exigncia que, voltamos a insistir, qualquer estrutura fsica escolhida no nvel

interno deve oferecer suporte total estrutura lgica exigida.

Em segundo lugar, os bancos de dados relacionais satisfazem a um princpio muito

interessante, chamado de O Princpio da Informao: todo contedo de informao do banco de

dados representado de um e somente um modo, ou seja, como valores explcitos em posies de

colunas em linhas de tabelas. Esse mtodo de representao o nico mtodo disponvel (no nvel

lgico evidentemente) em um sistema relacional. Em particular, no existem ponteiros conectando

uma tabela a outra.

Alm disso, quando dizemos que no existem ponteiros em um banco de dados relacional,

no queremos dizer que no possam existir ponteiros no nvel fsico pelo contrrio, eles

certamente podem existir e, de fato, quase com certeza existiro. Entretanto, como j foi explicado,

todos estes detalhes de armazenamento fsico so ocultados do usurio em um sistema relacional.

Veja uma figura do livro do Navathe :



Luis Octvio Lima


Ateno !! Essa figura fala por mil palavras !!

importante observar que em paralelo ao projeto de banco de dados, ocorrer

anlise dos requisitos funcionais da soluo, indo at sua implementao. Isso quer dizer

que caso surja uma questo que negue isso ou que afirme que SEMPRE o projeto de

sistema , ou soluo, ou programa, ser iniciado aps o projeto fsico do banco de banco de

dados, essa questo est ERRADA.

Com na figura acima, vamos entrar na etapa do Projeto Lgico e falar um pouco sobre

os tipos de modelos lgicos mais conhecidos.

Vamos ver o que Korth fala sobre isto:

Modelo Relacional: Usa uma coleo de tabelas para representar os dados e as relaes

entre eles. Cada tabela possui diversas colunas, e cada coluna possui um nome nico. O modelo

relacional um exemplo de um modelo baseado em registros. Cada tabela possui registros de um

tipo especfico. Cada tipo de registro define um nmero fixo de campos, ou atributos. As colunas

das tabelas correspondem aos atributos do tipo de registro. O modelo de dados relacional o



Luis Octvio Lima


modelo de dados mais usado, e uma grande maioria dos sistemas de banco de dados atuais

baseado no modelo relacional.

Modelo de entidade/relacionamento(E-R): baseado numa percepo do mundo real que

consiste numa coleo de objetos bsicos, chamados de entidades, e as relaes entre esses

objetos. Uma entidade uma coisa ou objeto no mundo real que distinguvel dos outros

objetos. O modelo entidade/relacionamento muito usado no projeto de banco de dados.

Modelo de dados baseado em objeto: Pode ser visto como uma extenso ao modelo E-R com

noes de encapsulamento, mtodos (funes) e identidade de objeto. O modelo de dados

relacional de objeto combina recursos do modelo de dados orientado a objeto e do modelo de

dados relacional.

Modelo de dados semiestruturado: Permite a especificao dos dados em itens de dados

individuais do mesmo tipo possam ter diferentes conjuntos de atributos. Isso o oposto dos

modelos de dados mencionados anteriormente, em que todos os itens de dados de um determinado

tipo precisam ter o mesmo conjunto de atributos. A Extensible Markup Language(XML)

amplamente usada para representar dados semiestruturados.

Modelo Hierrquico e Rede: Um Banco de dados hierrquico consiste em uma coleo de

registros que so conectados uns aos outros por meio de ligaes. Um registro uma coleo de

campos, cada qual contendo apenas um valor de dados. Uma ligao uma associao entre

exatamente dois registros. O modelo hierrquico , portanto similar ao modelo de rede, no sentido

de que dados e relacionamentos entre dados so tambm representados por registros e ligaes,

respectivamente. O modelo hierrquico difere do modelo de rede na organizao de registros como

coleo de rvores em vez de grafos arbitrrios.

Dentre os modelos apresentados, destaca-se o Modelo de Dados Relacional e o

Modelo de Entidade-Relacionamento (MER), pois so os mais usados no cotidiano e com

certeza os preferidos em detalhes nas questes de concurso.

Ento, vamos conhecer alguns conceitos aplicados aos SGBDs relacionais quanto

integridade dos dados.

A integridade dos dados feita atravs de restries, que so condies obrigatrias

impostas pelo modelo. Vocs vero em outro bloco de questes sobre o conceito de



Luis Octvio Lima


normalizao, o qual preza pela integridade referencial, uma das principais formas de

restrio de dados dentro do modelo relacional.

Vamos ver os tipos de restries:

Restrio de Domnio: Um domnio formado por um conjunto de valores, os quais

so usados, num modelo relacional, nas colunas das tabelas. A restrio aplica-se quando

exigido que o uso deste atributo fosse atmico dentro do domnio ou seja nulo.

Restrio de Chave: Uma relao (tabela) deve possui uma chave, sendo esta chave a

identificao nica(no admite repetio) para um registro (tupla ou conjunto de campos).

Esta identificao pode ser composta de um campo (atributo) ou conjunto de campos. A

identificao chamada de chave primria, porm outros campos podem de alguma forma

definir um registro de forma similar chave primria, sendo estas chamadas de chaves

candidatas.

Integridade de Entidade: Tem a finalidade de garantir que a chave primria no pode

ser nula.

Integridade Referencial: Tem por finalidade garantir a consistncia entre registros

(tuplas) de tabelas diferentes (relaes). Quando uma tupla fizer referncia outra relao,

esta relao dever possuir uma tupla correspondente quela relao. Neste conceito

encontramos a implementao das chaves estrangeiras.

Bom, agora vamos deixar de lero...lero e vamos praticar !

Ah, uma dica preciosa: A partir de agora considerem os enunciados das questes

como sendo parte do seu estudo terico, ou seja, prestem bem ateno neles e se possvel

transcrevam alguns para um documento em separado, como se estivesse criando um

caderno de reviso. O que vocs estaro criando eu chamo de jurisprudncia da banca,

ou seja, vocs iro fazer um estudo direcionado tanto para o assunto quanto para o que

banca pensa do assunto e isso o mais importante, pois muitos enunciados viram

alternativas nas questes e vice-versa. Se liguem nessa !

Vamos l !!! cabea fria, mo quente !



Luis Octvio Lima


Questo 01 : FCC - 2013 DPE/RS - Analista - Informtica

Acerca de banco de dados relacionais considere:

I. Os sistemas relacionais s exigem que o banco de dados seja percebido pelo usurio

como tabelas. No nvel fsico o sistema livre para armazenar os dados usando arquivos

sequenciais, indexao, hashing etc.

II. As tabelas representam uma abstrao do modo como os dados esto armazenados

fisicamente de forma que diversos detalhes do nvel de armazenamento ficam ocultos ao

usurio.

III. Todo o contedo de informao do banco de dados representado de um e somente

um modo, ou seja, como valores explcitos em posies de colunas em linhas de tabelas.

Este princpio satisfeito pelos BDs relacionais.

IV. No existem ponteiros conectando uma tabela a outra em BDs relacionais. Com isso se

quer dizer que no existem ponteiros no nvel fsico, pois ponteiros no podem ficar

visveis ao usurio.

Est correto o que consta em.

a) I, II, III e IV.

b) I e II, apenas.

c) I, II e III, apenas.

d) I, III e IV, apenas.

e) III e IV, apenas.

Comentrios: Antes de explicar a resposta, gostaria de dizer que a FCC ama o livro do C.J.

Date. Esta questo um exemplo disso, vou transcrever abaixo trechos do livro de onde a

questo foi retirada.

A questo traz literalmente o que est escrito no livro do Date e conforme foi

transcrito no resumo.

O erro do item IV est em afirmar que no existem ponteiros no nvel fsico, e

segundo Date, isso est errado, pois podero existir sim e na maioria das vezes existe.



Luis Octvio Lima


Gabarito: c)

Questo 02 : FCC 2012 TCE/AP Analista de Controle Externo TI

Sobre um puro banco de dados orientado a objetos, considere:

I. Os dados so armazenados como objetos que podem ser manipulados por mtodos de

acesso de SGBDs relacionais ou hierrquicos, apenas.

II. Os objetos so organizados em uma hierarquia de tipos e subtipos que recebem as

caractersticas de seus supertipos.

III. Os objetos no podem conter referncias para outros objetos.

correto o que consta em:

a) I, apenas.

b) II, apenas.

c) III, apenas.

d) I e III, apenas.

e) I, II e III.

Comentrios: Um conceito importantssimo em Banco Orientado a Objetos, ou at mesmo,

nas Linguagens Orientadas a Objetos ou Modelagem Orientada a Objeto, o da herana,

onde a principal caracterstica o aproveitamento de recursos entre o subtipo e seu

supertipo, onde o subtipo herda caractersticas do seu supertipo.

O item II retrata bem isso.

J o item I comete um equvoco ao restringir o acesso ao BOO apenas atravs dos

bancos hierrquicos ou relacionais, pois possvel sim uma outra aplicao usar os dados do

BOO.

E para matar, o item III fere o conceito da herana.

Ento, conclumos que a alternativa b) est correta.

Gabarito: b)



Luis Octvio Lima


Questo 03 : FCC 2011 TCE/SE Analista de Controle Externo Cordenadorias de

Informtica

Considere:

Sua estrutura do tipo rvore e sua formao se d atravs de registros e links, onde cada

registro uma coleo de dados e o link uma associao entre dois registros. Os registros

que precedem outros so chamados de registro pai e os demais so chamados de registros

filhos. Cada registro tem suas ligaes, o registro pai pode ter vrios filhos (1:N), o registro

filho s pode ter um pai. Caso um determinado registro filho tenha a necessidade de ter

dois pais necessrio replicar o registro filho.

Tais caractersticas correspondem ao banco de dados do tipo:

a) orientado a objetos.

b) rede.

c) relacional.

d) hierrquico.

e) relacional-oo.

Comentrios: Questo tranquila, basta dar uma lida no resumo e logo voc percebe que a

alternativa d) a resposta.

Segue abaixo uma figura como exemplo do modelo hierrquico.

Gabarito: d)

Questo 04 : FCC 2010 - TRF 4 Tcnico Judicirio Informtica

Num banco de dados relacional,



Luis Octvio Lima


a) as tuplas necessitam de informaes em todas as colunas.

b) quando um campo chave de uma tabela Y inserido como um campo na tabela X, diz-

se que ele uma chave primria na tabela X.

c) um registro um atributo de uma tabela.

d) uma coluna uma instncia de uma tabela.

e) os registros no precisam conter informaes em todas as colunas

Comentrios: Vamos l !

A resposta da alternativa foi embasada nos registros do Codd:

Cada linha formada por uma lista ordenada de colunas representa um registro, ou tupla. Os

registros no precisam conter informaes em todas as colunas, podendo assumir valores nulos

quando assim se fizer necessrio. Resumidamente, um registro uma instncia de uma tabela, ou

entidade(grifo meu)

O erro da alternativa a) est em afirmar que as tuplas (linhas da tabela) necessitam de

informaes em todas as colunas, pois no existe essa obrigatoriedade. A regra de negcio

quem vai dizer isso.

A alternativa b) fala de chave estrangeira, porm erra ao afirmar que se trata de uma

chave primria.

A alternativa c) confunde registro com coluna(atributo) de uma tabela, este o erro.

A alternativa d) erra ao afirma que coluna uma instncia de uma tabela, pois o certo

seria dizer que a instncia de uma tabela apresenta toda as suas linhas e colunas.

Gabarito: e)

Questo 05: FCC 2010 - TRF 4 Tcnico Judicirio Informtica

O principal critrio para classificar um SGBD o modelo de dados no qual baseado. A

grande maioria dos SGBDs contemporneos baseada nos modelos:

a) Conceitual, Abstrato e Orientado a Objetos.



Luis Octvio Lima


b) Descritivo, Relacional e Orientado a Objetos.

c) Conceitual, Relacional e Orientado a Objetos.

d) Conceitual, Relacional e Orientado a Dados.

e) Descritivo, Abstrato e Orientado a Dados

Comentrios: No nosso resumo, conhecemos os modelos Conceitual, Relacional e Orientado

a Objetos, sendo a alternativa c) a resposta da questo.

Os termos Descritivo, Abstrato, Orientado a Dados, foram colocados para confundir o

candidato e no mantm relao com os modelos explicados anteriormente.

Gabarito: c)

Questo 06: FCC 2008 Metr/SP Analista Trainee Anlise de Sistemas

Os SGBD relacionais NO possuem uma categoria de restrio denominada integridade:

a) de chave.

b) de domnio.

c) relacional.

d) referencial.

e) de vazio.

Comentrios: No existe integridade relacional !

Existe modelo relacional, banco de dados relacional, modelagem relacional.

Conhecemos no resumo as caractersticas das restries de chave, de domnio,

integridade referencial e integridade de entidade.

A integridade de vazio, define regras de aceitao quanto ao no preenchimento de

campos, ou seja, so restries para campos no obrigatrios.

Gabarito: c)



Luis Octvio Lima


Questo 07: FCC 2007 Cmara dos Deputados Analista Legislativo Informtica

Legislativa

O armazenamento de dados, em um banco de dados relacional, realizado por um

mecanismo que envolve:

a) esquemas conceituais, externos e internos.

b) atributos, chaves primrias e chaves estrangeiras.

c) tabelas, ndices e vises.

d) tabelas, colunas e tipos de dados.

e) linhas e colunas

Comentrios: Vimos no resumo que em um BD relacional, as entidades implementadas em

forma de tabela, sendo esta tabela constituda de linhas e colunas. Alm disso preciso

definir qual o tipo e cada campo (inteiro, texto, data, nmero e assim por diante).

Sendo assim, a resposta da questo a alternativa d).

Os esquemas conceituais, externos e internos no so objetos de armazenamento e

sim de definio. Este o erro da alternativa a).

O erro da alternativa b) est em afirmar que chaves primrias e chaves estrangeiras

fazem parte do armazenamento de dados, pois estes fazem parte da definio de

integridade de dados. J seus dados, estes sim, fazem parte do armazenamento.

ndices so definies e no armazenamento. Viso uma definio de como os dados

de uma ou mais tabelas podem ser mostrado aos usurios. Isso torna a alternativa c) errada.

As linhas trazem a juno de campos e colunas de uma tabela, ou mesmo, o resultado

de uma consulta envolvendo vrias tabelas. Numa operao de armazenamento, nossa

referncia a tabela destino, os campos(colunas) da tabela e o tipo de dado a ser

armazenado. Este o erro da alternativa e).

Gabarito: d)



Luis Octvio Lima


Vamos falar um pouco mais agora sobre a forma de diagramao na modelagem

lgica, porm salutar explorar um pouco da modelagem conceitual e assim depois

mapear o seu resultado para modelagem lgica, passando pelos conceitos da modelagem

relacional.

Vamos l pessoal, fora !

Vamos comear conhecendo alguns conceitos usados num DER:

Entidade: o conjunto de objetos da realidade, os quais se deseja manter os dados

armazenados em banco de dados. representada pela figura de um retngulo.

Relacionamento: Representa o conjunto de associaes entre as entidades, ou seja,

como elas se relacionam. representada pela figura de um losango.

Neste caso, o relacionamento Lotao agregar dados de Departamento e Pessoa,

formando diversas combinaes.

Existe uma outra forma de relacionamento que de vez em quando cobrada em

questes, o qual costuma derrubar alguns candidatos , trata-se do auto-relacionamento. O

auto-relacionamento muito usado quando nos deparamos com situaes onde a relao

formada como se fosse uma hierarquia ou rvore, segue abaixo dois exemplos.

Veja que neste exemplo existe uma relao recursiva, onde a entidade Empregado se

relaciona com ela mesma, atravs de um relacionamento chamado Superviso, ou seja, um

empregado poder estar relacionado com outro empregado, e a semntica deste

relacionamento estabelece que neste caso um empregado supervisionado por outro



Luis Octvio Lima


empregado. Podemos tambm ver a entidade PRODUTO podendo se autorelacionar,

formando diferentes composies de produtos.

Cardinalidade: Representa a quantidade de ocorrncias de uma determinada

entidade atravs de um relacionamento. H duas cardinalidades que so consideradas na

representao: a cardinalidade mxima e a cardinalidade mnima. Observem a figura

abaixo, retirada do livro Projeto de Banco de Dados, do autor Carlos Alberto Heuser.

Relacionamentos Binrios: quando as ocorrncias envolvem duas entidades,

podendo ter em suas relaes as seguintes cardinalidades:

a) Muitos-para-muitos(n:n)

Neste exemplo podemos fazer a leitura de que um mdico consulta muitos

pacientes, assim como um paciente consultado por muitos mdicos. O tipo de

cardinalidade (n:n) o menos restrito dentre os outros tipos, pois admite diversas

combinaes.

b) Um-para-muitos(1:n)



Luis Octvio Lima


Neste exemplo podemos afirmar que um curso recebe a inscrio de vrios alunos,

assim como muitos alunos podem estar inscritos num mesmo curso.

c) Um-para-um(1:1)

Neste exemplo podemos interpretar que uma mesa de trabalho est alocada

apenas para um empregado, assim como um empregado utiliza apenas uma mesa.

Relacionamento Ternrio: So relacionamentos que envolvem mais do que duas

entidades. Na prtica vai ocorrer a formao de uma agregao entre duas entidades e o

resultado desta agregao relaciona-se com outra entidade ou outra agregao. Segue um

exemplo abaixo para facilitar o entendimento:

A cardinalidade no caso de relacionamentos ternrios refere-se a pares de entidades.

A interpretao obtida do exemplo acima que:



Luis Octvio Lima


O 1 na linha que liga o retngulo representativo da entidade DISTRIBUIDOR

ao losango representativo do relacionamento expressa que cada par de ocorrncias

(cidade, produto) est associado a no mximo um distribuidor. Em outros termos,

no h concorrncia pela distribuio de um produto em uma cidade.

J os dois n expressam que:

A um par (cidade, distribuidor) podem estar associados muitos produtos, ou em

outros termos, um distribuidor pode distribuir em uma cidade muitos produtos.

A um par (produto, distribuidor) podem estar associadas muitas cidades, ou em

outros termos, um distribuidor pode distribuir um produto em muitas cidades.

Confesso que o relacionamento ternrio meio chato, porm existe e muito

importante entend-lo para garantir alguns pontos em questes que pedem para

interpretar diagramas.

Cardinalidade Mnima: Vai definir o nmero mnimo de ocorrncias de uma

entidade, atravs de um relacionamento. Quando esta cardinalidade mnima igual a 1

podemos dizer que obrigatria a existncia de pelo menos uma ocorrncia de uma

determinada entidade, inclusive tal cardinalidade pode receber a denominao de

associao obrigatria. Por outro lado, quando a cardinalidade mnima igual a 0,

podemos concluir que se trata de uma associao opcional, onde no se faz obrigatria

a ocorrncia de determinada entidade.

Atributo: o dado que est representado em ocorrncias de entidades ou de

relacionamentos, sendo tais dados considerados como propriedades particulares destes

elementos. Graficamente pode ser representado por bolinhas. Veja exemplo abaixo:

Neste exemplo, um Projeto tem cdigo, nome e tipo como dados que o

representam.



Luis Octvio Lima


Na prtica, costuma-se no representar todos atributos de uma entidade ou

relacionamento num DER, pois a visualizao final do diagrama fica muito poluda, o que

pode dificultar a interpretao.

Os atributos podem receber cardinalidade, o que significa que eles podem ter limites

mnimos e mximos de ocorrncia, sendo que no caso de cardinalidade acima de 1, o

atributo considerado como sendo multivalorado. Segue exemplo:

Neste exemplo, a entidade Cliente possui alguns atributos, sendo que dentre eles, o

atributo telefone recebe cardinalidade (0,n) o que significa que um cliente pode ter

nenhum ou muitos telefones.

Neste outro exemplo, percebe-se o uso de atributos tanto nas entidades, quanto no

relacionamento. Podemos interpretar que Engenheiros podem atuar em Projetos, assim

como um Projeto pode ter vrios Engenheiros atuando, e quando atuam recebem uma

funo como atributo.

Para finalizar vamos conhecer os Atributos Identificadores, os quais so usados para

distinguir uma ocorrncia de entidade das demais ocorrncias existentes. Graficamente ele

representado por um atributo pintado de preto(em outros diagramas ele aparece

sublinhado, veremos isto nas prximas questes), sendo visivelmente diferenciado dos

demais atributos existentes. Segue um exemplo visual:

Veja que o atributo cdigo foi marcado como sendo o atributo identificador da

entidade Pessoa.



Luis Octvio Lima


Os identificadores podem ser compostos por mais de um atributo, isso vai depender

dos requisitos levantados l no incio do projeto de banco de dados. Veja um exemplo:

A entidade Prateleira tem trs atributos, sendo que dois deles so usados para

distinguir as ocorrncias de prateleiras, ou seja, no pode existir mais de uma prateleira

com mesmo nmero do corredor e mesmo nmero de prateleira.

Generalizao/Especializao: Para quem j estudou os conceitos de Modelagem

Orientada a Objetos, vai facilmente entender as propriedades de

generalizao/especializao em banco de dados, pois estas se assemelham muito com o

conceito de herana. Atravs da generalizao/especializao possvel atribuir

propriedades particulares a um subconjunto de ocorrncias, ou seja, especializa-se uma

entidade. A entidade mais genrica deve guardar atributos que sejam comuns para

entidades da mesma espcie, ao mesmo tempo as entidades mais especializadas devem

guardar atributos que so particulares (menos comuns) a sua prpria espcie.

Quando existe uma ocorrncia de uma entidade mais especializada, subentende-se

que alm dos seus atributos particulares (menos comuns) ele tambm recebe os atributos

de sua entidade mais geral, ou seja, recebe os atributos que so comuns. Para

representarmos este conceito, usamos a figura de um tringulo, vejamos o exemplo a

seguir:

Creio que neste momento voc j possa facilmente interpretar parte desta figura,

pois estamos utilizando aqui alguns elementos conhecidos, como por exemplo:



Luis Octvio Lima


Entidades(Filial, Cliente, Pessoa Fsica e Pessoa Jurdica), existe tambm um

Relacionamento entre as entidades Filial e Cliente a qual traz entre parnteses as

Cardinalidades usadas, alm disso, cada Entidade traz seus atributos representados por

bolinhas, sendo uma delas pintada de preto a fim de representar um Atributo

Identificador.

A figura tambm trs a representao das entidades especializadas(Pessoa Fsica e

Pessoa Jurdica). Uma ocorrncia de uma destas entidades vai trazer alm dos seus

atributos particulares, os atributos da entidade Cliente(cdigo, nome).

Entidade Associativa: quando um relacionamento entre entidades necessita

receber a identificao tambm de uma entidade, ou seja, o relacionamento passa a ser

interpretado como uma entidade tambm. Isso muito comum quando a cardinalidade

entre o relacionamento das entidades envolvidas do tipo n:n, pois teremos que combinar

muitas ocorrncias entre as entidades. Quando isso acontece, a Entidade Associativa, alm

de receber os atributos de identificao das entidades envolvidas na associao, ela

tambm possuir atributos prprios, que possa ento caracteriz-la como entidade e no

somente um relacionamento entre entidades. Veja o exemplo abaixo:

Veja que a figura mostra inicialmente um relacionamento CONSULTA entre as

entidades MDICO e PACIENTE, e com cardinalidade n:n entre eles, ou seja, interpreta-se

que um paciente pode ser consultado por muitos mdicos, assim como um mdico pode

consultar vrios pacientes. Mas, voc podia se perguntar: Onde ficam os dados do horrio

da consulta? Do local da consulta?, pois neste momento que voc passa a enxergar o

relacionamento consulta no somente como um relacionamento, mas tambm como uma

entidade do negcio, e realmente , pois um consultrio mdico vive financeiramente de

suas consultas, ou no? Dinheiro cai do cu ?



Luis Octvio Lima


Veja agora como ficaria a representao da figura acima, quando ento percebesse que

CONSULTA tambm uma entidade:

O relacionamento passa a receber um retngulo em sua volta, ou seja, um smbolo

de relacionamento (losango) envolvido por um smbolo de entidade (retngulo). Nesta

mesma figura a pessoa ou equipe do projeto percebeu que uma consulta pode originar

prescries de medicamentos e logo pensaram em criar uma associao entre a Entidade

Associativa CONSULTA e a Entidade MEDICAMENTO. Olha que coisa linda! Se voc

observar bem, existe um Relacionamento Ternrio se formando a, muito bom heim?!

Sacaram parada?!

Bem, agora vamos praticar !

Questo 08: FCC 2013 MPE/SE - Analista do Ministrio Pblico Informtica I

Gesto e Anlise de Projeto de Sistemas

Em projetos de Banco de Dados, o objetivo da arquitetura de trs-esquemas separar o

usurio da aplicao do banco de dados fsico. Nessa arquitetura, os esquemas podem

ser definidos por trs nveis:

I. O nvel interno tem um esquema que descreve a estrutura de armazenamento fsico do

banco de dados. Esse esquema utiliza um modelo de dado fsico e descreve os detalhes

complexos do armazenamento de dados e caminhos de acesso ao banco;



Luis Octvio Lima


II. O nvel conceitual possui um esquema que descreve a estrutura de todo o banco de

dados para a comunidade de usurios. O esquema conceitual oculta os detalhes das

estruturas de armazenamento fsico e se concentra na descrio de entidades, tipos de

dados, conexes, operaes de usurios e restries. Geralmente, um modelo de dados

representacional usado para descrever o esquema conceitual quando o sistema de banco

de dados for implementado.

Esse esquema de implementao conceitual normalmente baseado em um projeto de

esquema conceitual em um modelo de dados de alto nvel;

III. O nvel interno ainda abrange os esquemas externos ou vises de usurios. Cada

esquema interno descreve a parte do banco de dados que um dado grupo de usurios tem

interesse e oculta o restante do banco de dados desse grupo. Como no item anterior, cada

esquema tipicamente implementado usando-se um modelo de dados representacional,

possivelmente baseado em um projeto de esquema externo em um modelo de dados de

alto nvel.

Est correto o que se afirma em

a) II, apenas.

b) II e III, apenas.

c) I, II e III.

d) I e II, apenas.

e) III, apenas.

Comentrios: No resumo inicial da aula falei sobre a arquitetura em trs nveis, inclusive

trazendo uma figura ilustrativa sobre o assunto.

Os itens I e II retratam bem o que vimos no texto do Navathe, porm o item III erra

ao afirmar que O nvel interno ainda abrange os esquemas externos ou vises de



Luis Octvio Lima


usurios. Na verdade o nvel interno descreve a estrutura fsica de armazenamento

interno do banco de dados.

Gabarito: d)

Questo 09: FCC 2013 MPE/SE - Analista do Ministrio Pblico Informtica I

Gesto e Anlise de Projeto de Sistemas

A capacidade de alterar o esquema conceitual sem mudar o esquema externo ou os

programas, podendo modificar o esquema conceitual para expandir o banco de dados

(adicionando um tipo de registro ou item de dados), variar as restries ou reduzir o banco

de dados (removendo um tipo de registro ou item de dados) chamada de

a) modularidade.

b) modelo conceitual.

c) independncia lgica de dados.

d) polimorfismo.

e) agregao

Comentrios: Essa questo traz um assunto visto no resumo do incio da aula, onde

demonstra a capacidade de um SGBD em mostrar as descries dos dados em nveis

diferentes.

Vimos que esta viso em 3 nveis (externo, conceitual e externo) serve de base para o

conceito de independncia de dados.

A independncia de dados pode ser explicada atravs da Independncia Fsica de

Dados e Independncia Lgica de dados.

A questo apresenta justamente o conceito sobre Independncia Lgica de Dados,

sendo correta alternativa c) .

Gabarito: c)

Questo 10: FCC 2012 TCE/AM Analista Tcnico de Controle Externo TI

O modelo conceitual de dados



Luis Octvio Lima


a) aquele em que os objetos, suas caractersticas e relacionamentos tm a

representao de acordo com as regras de implementao e limitantes impostos por

algum tipo de tecnologia.

b) aquele em que os objetos, suas caractersticas e relacionamentos tm a

representao fiel ao ambiente observado, independente de limitaes quaisquer

impostas por tecnologias, tcnicas de implementao ou dispositivos fsicos.

c) aquele elaborado respeitando-se e implementando-se conceitos tais como chaves de

acesso, controle de chaves duplicadas, itens de repetio (arrays), normalizao,

ponteiros e integridade referencial, entre outros.

d) a fase da modelagem na qual necessrio considerar todas as particularidades de

implementao, principalmente o modelo que ser utilizado para a implementao

futura.

e) est sempre associado s fases de projeto, contrastando com o modelo lgico, que

sempre est associado fase de anlise, quando utilizado com as metodologias de

desenvolvimento de sistemas e implementado por ferramentas CASE.

Comentrios: J vimos que o modelo conceitual deve ser implementado conforme o que

observado na vida real, abstrado de tal forma que o resultado seja independente de

tecnologia e numa linguagem de fcil interpretao. O resultado do modelo conceitual vai

servir de insumo para elaborao do modelo lgico, sendo este dependente da tecnologia

que ser utilizada.

Diante ento deste comentrio, conclumos que alternativa b) a correta.

O erro da alternativa a) est em afirmar que o modelo conceitual apresenta

dependncia com a tecnologia que ser utilizada.

O erro da alternativa c) que o modelo conceitual implementa ponteiros, arrays,

integridade referencial, dentre outras coisas que so tpicas do modelo lgico e fsico.



Luis Octvio Lima


O erro da alternativa d) erra ao afirmar que no modelo conceitual preciso

considerar todas as particularidades de implementao, sendo esta uma caracterstica do

modelo fsico.

Por fim, o erro da alternativa e) est em dizer que o modelo conceitual tem relao

com as metodologias de desenvolvimento de sistema.

Gabarito: b)

Questo 11: FCC 2012 BANESE Tcnico Bancrio III Informtica/Desenvolvimento

Dentre os requisitos de um sistema cartorial civil est a definio da entidade pessoa e

do casamento entre elas.

Assim, o modelo conceitual de banco de dados deve especificar:

a) a entidade casamento como relacionamento fraco de pessoa.

b) uma entidade associativa entre pessoa e casamento.

c) a entidade casamento e a entidade pessoa.

d) a entidade pessoa e o autorrelacionamento casamento.

e) um relacionamento ternrio entre pessoa, casamento e pessoa.

Comentrios: Essa boa, vamos l !

Este assunto est resumido no incio do tpico das questes e l pudemos conhecer

alguns tipos de relacionamentos.

A questo trs como informao apenas uma entidade chamada de PESSOA, creio

que nesta entidade venha existir alguns atributos bvios como nome, data de

nascimento, entre outros que possam caracterizar uma pessoa. Alm disso, a questo

tambm afirma que uma pessoa pode ser casada com outra. neste ltimo ponto onde

voc j pode perceber que necessrio relacionar a entidade pessoa com ela mesma,

sendo este vnculo (afetivo ) chamado de casamento.



Luis Octvio Lima


Este um caso clssico de auto-relacionamento, o que torna a alternativa d) como

correta.

Vejam abaixo como ficaria a soluo:

Gabarito: d)

Questo 12: FCC 2010 Assembleia Legislativa/SP Agente Tcnico Legislativo

Administrao de Banco de Dados e Arquitetura de Dados

Na modelagem conceitual, os atributos de uma entidade

a) so caractersticas (propriedades) dessa entidade.

b) simbolizam os relacionamentos.

c) definem a quantidade de elementos de uma entidade associado com a quantidade de

elementos de outra entidade.

d) simbolizam as cardinalidades.

e) simbolizam o tamanho das entidades

Comentrios: J vimos isso no resumo, o que torna a questo fcil !

Uma entidade representa algo do mundo real: pessoas, cargos, objetos, dentre outas

coisas. Cada um destes elementos possuam dados prprios, caractersticas prprias, as

quais so descritas nos seus atributos. Isso torna alternativa a) certa.



Luis Octvio Lima


A letra b) fala de relacionamento entre entidades.

A letra c) fala do conceito de cardinalidade.

A letra d) afirma que atributo a mesma coisa que cardinalidade.

A letra e) s foi para confundir o candidato.

Gabarito: a)

Questo 13: FCC 2010 Assembleia Legislativa/SP Agente Tcnico Legislativo

Administrao de Banco de Dados e Arquitetura de Dados

A principal meta da arquitetura de trs esquemas separar as aplicaes do usurio do

banco de dados fsico. Os esquemas so de nveis

a) internos, descritivos e externos.

b) internos, conceituais e externos.

c) independentes, conceituais e externos.

d) internos, conceituais e independentes.

e) independentes, conceituais e descritivos.

Comentrios: Conforme j visto anteriormente no resumo, a letra b) a correta.

Para refrescar a memria, segue a figura abaixo:

Gabarito: b)



Luis Octvio Lima


Questo 14: FCC 2008 TRF 5 Analista Judicirio Informtica

Com respeito ao nvel lgico (conceitual e externo) dos bancos de dados relacionais

normalizados correto afirmar que:

a) As conexes entre tabelas so vistas pelo usurio, na forma de ponteiros.

b) Todo o contedo de informao representado de um e somente um modo, ou seja,

como valores explcitos de colunas em linhas de tabelas.

c) Um relacionamento do tipo N:M implicar em chaves estrangeiras multivaloradas nas

tabelas relacionadas.

d) Um relacionamento do tipo 1:N implicar em que as chaves do lado N sero chaves

estrangeiras multivaloradas na tabela representada pelo lado 1.

e) Um relacionamento do tipo 1:1 no pode ser implementado em tabelas relacionais.

Comentrios: Olha s, trouxe essa questo de propsito!

Vejam o que a alternativa b) afirma e voltem l na Questo 01 desta aula e vejam o

seguinte item:

III. Todo o contedo de informao do banco de dados representado de um e

somente um modo, ou seja, como valores explcitos em posies de colunas em linhas de

tabelas. Este princpio satisfeito pelos BDs relacionais.

Viram? Como j falei antes, importantssimo gerar um material de resumo com os

enunciados de questes e alternativas verdadeiras, pois elas tm grande chance de se

repetirem em diversas provas.

A alternativa b) a correta, mas vamos avaliar as demais.

A letra a) est errada pois os usurios no enxergam a implementao de ponteiros

que foi feita no nvel fsico.

A letra c) esta errada e vamos explorar com mais detalhes no prximo tpico, porm

adianto que as chaves das tabelas relacionadas so primrias, sendo elas estrangeira na

tabela associativa(N:M).



Luis Octvio Lima


A letra d) esta errada, pois no lado N que ficaro as chave multivalorada e no no

lado 1.

A alternativa e) est errada, pois como j vimos no resumo, existe o relacionamento

1:1 em tabelas relacionais.

Gabarito: b)

Questo 15: FCC 2009 TRT 7 Analista Judicirio TI

Considere: Cada funcionrio associado para um projeto trabalha em apenas um local

para esse projeto, mas pode estar em um local diferente para um projeto diferente. Em

determinado local, um funcionrio trabalha em apenas um projeto. Em um local em

particular, pode haver muitos funcionrios associados a um determinado projeto.

Para tanto o modelo conceitual de dados deve prever um relacionamento ternrio com

as cardinalidades atribudas respectivamente no lado das entidades Local, Projeto e

Funcionrio como

a) 1, 1 e N.

b) 1, N e N.

c) 1, N e 1.

d) N, 1 e 1.

e) N, 1 e N.

Comentrios: Essa bem complicadinha heim?!

Vamos por partes:

A questo diz que cada funcionrio associado para um projeto, trabalha em apenas

um local para esse projeto. Podemos concluir neste caso que a cardinalidade de Local 1.

A questo tambm fala que em determinado local, um funcionrio trabalha em

apenas um projeto. Neste caso, podemos afirmar que a cardinalidade de Projeto 1.



Luis Octvio Lima


A questo finaliza afirmando que em um local em particular, pode haver muitos

funcionrios associados a um determinado projeto. Neste ltimo ponto, podemos afirmar

que a cardinalidade de Funcionrio N.

Fazendo um diagrama, chegamos seguinte soluo.

Gabarito: a)

Questo 16: FCC 2007 TER/MS Analista Judicirio Anlise de Sistemas

So elementos da representao de um modelo conceitual de dados (MCD):

a) identificador, relacionamento, atributo, entidade.

b) entidade, coluna, ndice primrio, relacionamento.

c) tabela, coluna, ndice primrio, relacionamento.

d) entidade, relacionamento, identificador, chave estrangeira.

e) relacionamento, chave estrangeira, ndice secundrio, ndice nico

Comentrios: Prestem bem ateno, a questo fala em Modelo Conceitual.

A alternativa a) traz todos elementos encontrados num modelo conceitual e j visto

nos resumos, a resposta da questo.

A letra b) erra ao trazer coluna (modelo lgico) e ndice primrio (modelo fsico),

como sendo elementos do modelo conceitual.

A letra c) erra ao trazer coluna e tabela (modelo lgico) e ndice primrio (modelo

fsico) como sendo do modelo conceitual



Luis Octvio Lima


A letra d) erra ao trazer chave estrangeira (modelo lgico) como sendo do modelo

conceitual.

A letra e) erra ao afirmar que chave estrangeira (modelo lgico) e ndice secundrio,

ndice nico (modelo fsico) so do modelo relacional.

Gabarito: a)

Trago baixo mais um resumo, agora dando nfase ao modelo relacional e os

diagramas entidade-relacionamento.

Alm destes dois assuntos, achei por bem abordar o assunto normalizao, pois

apesar de no estar explcito no edital a sua cobrana, a banca costuma cobrar alguma

questo por entender que este ser um conhecimento inerente ao tpico Diagramas de

Entidade e Relacionamentos.

Vamos l! Respira fundo, t acabando!

Vejamos antes dos conceitos, uma figura retirada do livro do Navathe, onde consta

os elementos mais comuns de se observar em Diagrama de Entidade-Relacionamento -

DER.



Luis Octvio Lima


Agora vejamos alguns conceitos e elementos com o que vamos nos deparar daqui

para frente.

Tabela: um conjunto no ordenado de linhas (tambm chamada tupla), sendo

que cada linha composta por campos (so os atributos no modelo ER);

Campos: Fazem parte das tabelas, geralmente tem uma correlao direta com os

atributos de um modelo ER. Cada campo possui um nome apropriado, e os dados das

vrias linhas que sejam de um mesmo campo formam uma Coluna.

Veja o exemplo de uma tabela chamada Emp:

Chave Primria(PK): Num banco de dados relacional comum o uso de campo

(Chave Primria) ou grupo de campos (Chave Primria Composta), cujos valores sejam

usados para distinguir uma linha das demais. No exemplo acima temos no campo

CdigoEmp um exemplo do uso de chave primria, pois ele pode ser usado como

identificador nico de cada linha. J a chave primria composta formada por mais de um

campo, mas com mesma finalidade de distinguir uma linha das demais. Na modelagem ER

o atributo sublinhado indica que do tipo identificador, ou seja, tem propriedade de uma

chave primria.

Veja abaixo um exemplo de tabela Dependente com chave primria composta:



Luis Octvio Lima


Observem que os campos CdigoEmp e NoDepen so usados como forma de

identificar cada linha como sendo nica. possvel notar tambm que o campo

CdigoEmp o mesmo campo presente na tabela Emp mostrada anteriormente, ou

seja, estas duas tabelas mantm uma relao.

Uma caracterstica importante a ser dita sobre o uso de chave primria que alm

dela ser usada como campo identificador, possui tambm papel importante na restrio

de integridade, ou seja, deve-se garantir que a chave seja nica (sem repetio) e no

nula (deve sempre existir numa linha).

Chave Estrangeira(FK): Trata-se de um campo tambm utilizado como identificador,

porm um identificador de uma tabela sendo armazenado em outra tabela. O uso deste

tipo de chave permite a implementao de relacionamentos em um banco de dados

relacional. Necessariamente uma chave estrangeira vai ser representada como chave

primria na sua tabela origem.

Vejamos um exemplo:

Observe que o campo CodigoDepto (chave primria) da tabela Dept est sendo

usado na tabela Emp como chave estrangeira. Isso significa que a partir da tabela Emp

possvel conhecer os dados da tabela Dept. Semanticamente, podemos interpretar que

um empregado (tabela Emp) pode visualizar dados do departamento (tabela Dept),

fazendo uso da chave estrangeira CodigoDepto. Outra forma de usar a chave estrangeira

dentro da mesma tabela de origem, muito usado quando se deseja fazer auto-

relacionamento, formando uma hierarquia de dados. Observe o exemplo abaixo:



Luis Octvio Lima


Observe no exemplo acima que o campo CdigoEmp usado como chave primria

e se autorelaciona com CodigoEmpGerente, onde a interpretao dada neste caso que

existem empregados que so vinculados a outros empregados, sendo estes ltimos

considerados gerentes. Por exemplo, empregado de nome Souza no tem relao com

nenhum CodigoEmpGerente, porm ele aparece como gerente dos empregados

Santos e Silva.

Chave Alternativa: Quando mais de um campo pode servir para distinguir uma linha

na tabela escolhe-se uma delas para ser a Chave Primria, sendo a outra uma chave

alternativa. Veja exemplo de uma tabela contendo chave primria e alternativa.

O campo CIC foi escolhido para ser a chave alternativa, ficando o campo

CdigoEmp como sendo a chave primria escolhida. (para quem no sabe, CIC era a sigla

usada antes do CPF...meio velhinho, eu sei, mas serviu no exemplo.. :)) ).

Entidade Forte: a entidade que possui uma chave primria, existe de forma

independente.

Entidade Fraca: uma entidade que depende de outra entidade, sendo esta ltima

uma entidade forte. Uma entidade fraca no pode existir se ela no estiver ligada a uma

entidade forte. A entidade fraca no possui chave primria prpria. Na modelagem ER a

entidade fraca representada por um retngulo de linha dupla.

Atributo Derivado: Tambm chamado de atributo calculado, trata-se de um atributo

que resultante do clculo de outros atributos: Ex: Idade, geralmente no um dado

informado, e sim um dado calculado com base no clculo da data de nascimento e data

atual.



Luis Octvio Lima


Atributo Multivalorado: So atributos que podem armazenar mais de uma

ocorrncia, quando mapeado para o um banco relacional , gera-se uma nova tabela com

campos correspondentes ao dado desejado e com chave para se relacionar com a tabela

que far uso destes atributos. Sua representao no modelo ER de uma elipse com linha

dupla.

Vejamos agora algumas notaes diferentes aplicadas em alguns diagramas entidade-

relacionamento.

Vejamos abaixo exemplos da notao p-de-galinha criada por James Martin.

Fiquem atentos em alguns detalhes da figura, como as linhas tracejadas para

relacionamentos no identificadores, o smbolo de generalizao/especializao(a figura



Luis Octvio Lima


trouxe como supertipo/subtipo) e as entidades com bordas arredondadas(entidades fracas)

e bordas retas(entidades fortes).

Existem tcnicas para realizar o mapeamento dos relacionamentos para um modelo

relacional, vamos conhec-las:

1-Tabela Prpria: Comumente usada para representar os relacionamentos n:n, onde

ser criada uma tabela que conter os atributos chaves de cada entidade participante do

relacionamento, alm de atributos prprios da tabela criada.

2-Colunas adicionais dentro de tabela de entidade: Usada na construo de

relacionamentos 1:n, onde uma coluna inserida em uma das entidades envolvidas no

relacionamento, sendo tal coluna uma chave estrangeira(FK) da outra entidade.

3-Fuso de tabelas de entidades: Usada nas relaes 1:1, onde se escolhe em qual das

entidades sero inseridas as colunas da outra entidade, onde no final teremos apenas uma

entidade(tabela).

Classificaes de Entidades e Atributos : Alguns autores costumam classificar as

Entidades e Atributos, a fim de distinguir cada uma delas, vamos conhecer quais so estas

formas de classificao:

Entidades:

Coisas Tangveis: Representa todos os elementos que existam de forma

concreta ou fsica. Exemplo: Casa, carro, produto, animal, pessoa.

Funes: Representa um papel ou atuao. Exemplo: Departamento,

professor, turma.

Eventos ou Ocorrncias: Representa alguma ao em andamento e somente

so percebidos nestas circunstncias. Exemplo: Lanamento em conta

corrente.



Luis Octvio Lima


Atributos:

Atributos Descritivos: Representam caractersticas de algum objeto.

Atributos Nominativos: So atributos que desempenham papel descritivo e ao

mesmo tempo de identificao dos objetos: Exemplo: Matricula, CPF, Cdigo.

Atributos Referenciais: Atributos que no pertencem a uma entidade, mas que

so usados como forma de estabelecer vnculo entre esta entidade e outra.

Exemplo: Chaves Estrangeiras.

Vamos conhecer agora alguns conceitos necessrios antes de entrar em

normalizao:

Dependncia Funcional: Em uma tabela, num banco de dados relacional, quando o

dado de uma coluna(C1) sempre ocorre juntamente com um dado de outra coluna(C2),

em diferentes linhas, isso indica que C2 depende funcionamento de C1, ou, que C1

determina C2(C1 C2). Vejam um exemplo simples:

Note que sempre que o campo Cdigo igual a E1, o valor do campo Salrio

igual a 10 e assim por diante com relao aos outros cdigos. Isso Dependncia

Funcional, blz?!

Anomalias de Insero: A forma mais fcil de entender visualmente. Vamos

comentar a figura abaixo copiada do livro do Navathe Sistema de Banco de Dados 6ed.:



Luis Octvio Lima


A tabela FUNC_DEP traz dados que so tanto de funcionrios (Fnome, Cpf,

DataNasc, Endereo), quanto departamento onde lotado(Dnome, Cpf_gerente). O

grande problema que so dados de entidades fisicamente diferentes, mas que esto

numa mesma tabela, gerando dependncias funcionais redundantes(repetidas).

A anomalia da insero vai surgir quando ao tentar incluir dados do funcionrio que

no tenha departamento, teremos que atribuir nulo (null) aos campos relativos ao

departamento. A mesma coisa aconteceria se um departamento existe e no tenha ainda

funcionrios , ou seja, os dados relativos aos funcionrios ficaro com valor nulo (null)

neste caso. O pior de tudo vai ser quando existir posteriormente mais de um funcionrio

no mesmo departamento. Neste caso os dados do departamento sero includos todas as

vezes que um funcionrio for cadastrado, gerando muita repetio(redundncia) de dados.

J imaginou o rolo que isso vai dar?, pois !

Anomalia de Excluso: Levando em considerao a mesma figura, esta anomalia

ocorre quando ao tentar excluir funcionrios da tabela FUNC_DEP, os dados de toda

linha(tupla) sero excludos, inclusive os dados do departamento. O pior de tudo vai

acontecer quando chegar ao ltimo funcionrio de um mesmo departamento, ao exclu-lo

no teremos mais os dados do departamento no banco de dados, simplesmente deixa de

existir. Isso coerente? O que acha?

Anomalia de Modificao (atualizao): Ainda aproveitando a mesma figura, esta

anomalia vai acontecer quando ao tentar alterar um dado do departamento, por exemplo,

ser necessrio percorrer todas as linhas(tuplas) da tabela(relao) a fim de alterar o dado

para o seu estado desejado. Isso provocar um trabalho enorme, apenas para modificar

um dado de um departamento.



Luis Octvio Lima


Integridade Referencial: a restrio que define que os valores dos campos que

aparecem em uma chave estrangeira devem aparecer na chave primria da tabela

referenciada.

Normalizao:

Segundo Navathe:

A normalizao de dados pode ser considerada um processo de analisar os esquemas de

relao dados com base em suas dependncias funcionais e chaves primrias para conseguir as

propriedades desejadas de minimizao da redundncia e minimizao das anomalias de insero,

excluso e atualizao(modificao).

Formas Normais: So regras que se seguidas ajudam a minimizar as ocorrncias de

anomalias e redundncias nas tabelas do banco de dados. Vamos conhecer as formas

normais e observar exemplos visuais.

a)Primeira Forma Normal(1FN):

Segundo Navathe:

Historicamente, a 1FN foi definida para reprovar atributos multivalorados, atributos

compostos e suas combinaes. Ela afirma que o domnio de um atributo deve incluir apenas

valores atmicos(simples, indivisveis) e que o valor de qualquer atributo em uma tupla deve ser um

nico valor do domnio desse atributo..... Em outras palavras, a 1FN reprova relaes dentro de

relaes.

Carlos Alberto Heuser define que:

..uma tabela est na primeira forma normal, quando ela no contm tabelas aninhadas.

Veja o exemplo abaixo:



Luis Octvio Lima


Esta tabela mostra dados dos funcionrios e projetos onde estes funcionrios esto

envolvidos. As colunas Projnumero e Horas guardam uma relao de dependncia

funcional entre elas, causando sua repetio desnecessria. Para solucionar isso, deve-se

colocar esta tabela na 1FN, criando-se uma tabela apenas com dados do projeto, porm se

relacionando com os dados dos funcionrios em tabela separada. Veja a soluo dada a

seguir:

Veja que a tabela FUNC_PROJ1 possui colunas com dados dos funcionrios, sendo

a coluna Cpf a chave primria. J a tabela FUNC_PROJ2 traz os dados relativos aos

projetos do funcionrio, formando uma chave primria composta (Cpf e Projnumero),

onde atravs desta chave ser possvel manter uma relao com a tabela FUNC_PROJ1

acabando com toda a redundncia existente em FUNC_PROJ1.

b)Segunda Forma Normal(2FN): quando a tabela alm de est na 1FN, no

mantm dependncias funcionais parciais entre atributos no chaves e parte da chave

primria, ou seja, todos os outros atributos no chaves devem depender da chave

primria completa. Veja um exemplo abaixo:



Luis Octvio Lima


Perceba que FUNC_PROJ est na 1FN, porm existem colunas (Projnome e Projlocal)

que guardam relao com parte da chave primria composta(Cpf, Projnumero) e no com

a chave toda. Este o cenrio propcio para se construir a 2FN, e foi construdo , criando

as tabelas FP1, FP2 e FP3, atribuindo a cada uma das chaves primrias especficas a fim de

garantir o relacionamento entre elas, eliminando as dependncias parciais.

c)Terceira Forma Normal(3FN): quando uma tabela alm de est na 2FN, no

guarda dependncia transitiva. Este tipo de dependncia ocorre quando atributos no

chaves dependem de outros atributos no chaves e tambm da chave primria da tabela.

A soluo criar outra tabela contendo tais atributos no chaves, elegendo um deles para

ser chave primria e esta chave primria vai ser usada como chave estrangeira na tabela

existente anteriormente. Vejam o exemplo abaixo:

Veja que a tabela FUNC_DEP possui colunas(Dnumero, Dnome,Cpf_gerente) que

no depende da chave primria (Cpf), ou seja, esto num estado de dependncia

transitiva. Para eliminar tal dependncia, transformou-se esta tabela em duas, sendo uma

com os dados do funcionrio(DF1), porm guardando a coluna Dnumero como chave

estrangeira para tabela DF2, sendo a referida coluna chave primria nesta tabela,

garantindo assim a relao entre ambas.

.

Vamos praticar !

Questo 17: FCC 2011 TER/RN Analista Judicirio Analista de Sistemas

Considere uma entidade associativa entre Mdico e Paciente (n:m) intitulada Consulta

que, por sua vez, se relaciona com Medicamento em n:m. No projeto lgico de banco de

dados relacional normalizado, este modelo de dados completo ser derivado para



Luis Octvio Lima


a) trs tabelas.

b) quatro tabelas.

c) cinco tabelas.

d) seis tabelas.

e) sete tabelas.

Comentrios: Sobre o conceito de entidade associativa ns j vimos no resumo, trata-se de

um relacionamento entre duas entidades que mantm uma cardinalidade N:N , sendo

necessrio criar uma tabela para armazenar as chaves primrias de ambas as tabelas,

sendo ento chamada de tabela associativa.

Normalmente a tabela associativa traz alguns atributos que sero especficos dela,

alm das chaves primrias das outras duas tabelas.

No caso desta questo, a tabela associativa Consulta ir receber as chaves primrias

de Mdico e Paciente, s a j foram trs tabelas.

A questo diz que Consulta se relaciona com uma tabela chamada Medicamento,

numa cardinalidade n:m, ou seja, precisamos de mais uma tabela associativa entre estas.

Como a questo no deu nome para esta tabela, vamos nome-la de Receita Mdica.

Bom, temos cinco tabelas (Mdico, Paciente, Consulta, Medicamento e Receita

Mdica), o que faz com que a resposta da questo seja a letra c).

Vamos ver abaixo como ficaria sua representao:



Luis Octvio Lima


Gabarito: c)

Questo 18: FCC 2014 TRF 3 Analista Judicirio Informtica/Banco de Dados

Uma tabela encontra-se na segunda forma normal (2FN), quando, alm de estar na

primeira forma normal (1FN),

a) no contm dependncias parciais de colunas no chave em relao chave

primria.

b) no contm chave primria composta de mais de uma coluna.

c) no contm dependncia completa de colunas no chave em relao chave

primria.

d) contm chave estrangeira composta de mais de uma coluna.

e) contm tabelas aninhadas.

Comentrios: Vimos no resumo o assunto Normalizao.

A alternativa a) est correta, pois trs exatamente o conceito sobre 2 FN.

A alternativa b) est errada porque no possvel garantir que na 2FN exista chave

primria simples ou composta.

A alternativa c) est errada , pois esse seria o passo para 3 FN.



Luis Octvio Lima


A alternativa d) est errada, pois para 2FN no h tal exigncia.

A alternativa e) est errada por infligir a 1FN.

Gabarito: a)

Questo 19: FCC 2012 ARCE Analista de Regulao Analista de Sistemas

A tabela Inscrio contm as seguintes colunas:

Cdigo do Curso

Cdigo do Aluno

Data de Inscrio

Nmero da Sala

Nome do Aluno

Considerando-se que a chave primria dessa tabela formada pelas colunas Cdigo do

Curso e Cdigo do Aluno, correto afirmar que ela

a) encontra-se na primeira, segunda e terceira formas normais.

b) encontra-se na segunda forma normal.

c) encontra-se na terceira forma normal.

d) no se encontra na primeira forma normal.

e) no se encontra na segunda forma normal.

Comentrios: Vamos l !

Vou colocar os campos aqui abaixo num linha s, representando as colunas:

Cdigo do Curso , Cdigo do Aluno, Data de Inscrio, Nmero da Sala ,Nome do Aluno

Primeiramente, nota-se que a tabela no possui atributos multivalorados, o que

caracterizaria um aninhamento e isso infligiria a 1FN. Ento a tabela est na 1FN.



Luis Octvio Lima


Vamos para adiante, note que a tabela possui alguns atributos que dependem de

parte da chave composta (Cdigo do Curso, Cdigo do Aluno), o caso de Nome do

Aluno, que depende de Cdigo do Aluno, mas no tem relao direta com Cdigo do

Curso, ou seja, encontramos um caso de dependncia parcial. Isso caracteriza que a tabela

no est na 2FN.

E se no est na 2FN, no est tambm na 3FN.

Sendo assim, a alternativa certa a letra e).

Gabarito: e)

Questo 20: FCC 2012 TJ/RJ Analista Judicirio Analista de Sistemas

Considere um Banco de Dados com as relaes R1, R2 e R3 abaixo, onde VALOR_PAGO

o valor pago de imposto de renda no ano e atributos sublinhados formam a chave.

R1 = {CPF, NOME, CPF_CONJUGE, NOME_CONJUGE}

R2 = {CPF, NOME, CIDADE, NUMERO_DEPENDENTES}

R3 = {CPF, ANO, NOME, VALOR_PAGO}

R1, R2 e R3 esto, respectivamente, na:

a) primeira, terceira e segunda forma normal.

b) primeira, segunda e terceira forma normal.

c) segunda, terceira e primeira forma normal.

d) segunda, primeira e terceira forma normal.

e) terceira, primeira e segunda forma normal.

Comentrios: Vamos por partes.

R1 apresenta dois atributos com dependncia entre eles (CPF_CONJUGE

NOME_CONJUGE), o que conceitualmente definido como dependncia transitiva, alm



Luis Octvio Lima


disso, no se percebe a existncia de dependncia parcial. Isso demonstra que R1 est na

2FN.

R2 apresenta atributos que no mostram dependncia parcial com a chave primria

e nem dependncia transitiva entre atributos no chaves da relao. Isso caracteriza que

R2 est na 3FN.

R3 apresenta dependncia parcial entre o atributo VALOR_PAGO e ANO, onde isso

demonstra que a relao no est na 2FN, estando na 1FN.

Sendo assim, letra c) a resposta.

Gabarito: c)

Questo 21: FCC 2011 INFRAERO Analista Superior III Administrador de Banco de

Dados

Considere: uma entidade A que se relaciona com uma en

aula 00 demonstrativa trf1 2014 tecnico informatica banco de dados 2853

Documents