-
Gostaria que alguem explicasse melhor essa questão, banco de dados não é o meu forte, mas esta questão está clara que a tabela não está na 3ªFN, mas na 1ªFN e na 2ªFN ela está, uso como base o artigo publicado nesse site:
http://www.blogdati.com.br/index.php/2010/03/normalizacao-em-banco-de-dados/
Portanto, com base no que sei o gabarito deveria ser letra A e não letra D.
1ªFN: Uma entidade estará na 1FN, se e somente se, todos seus atributos (colunas) forem atômicos, ou seja não conter grupos repetitivos ou colunas que tenham mais de um valor.
2ªFN: Uma entidade está na 2FN, se e somente se, estiver na 1FN e todos seus atributos (colunas) não chaves, dependam unicamente da chave primária. Se algum atributo depende de apenas uma parte da chave primária, isso é considerada uma violação da 2FN.
3ªFN: Uma entidade está na 3FN, se e somente se, estiver na 2FN e todos os atributos (colunas) não chave, forem mutuamente independentes, isto é, não há dependência funcional entre elas, e todas dependem única e exclusivamente da chave primária de forma irredutível.
-
Concordo com o raciocínio do colega acima. Porém, não teria só a letra A como alternativa correta, letra C também estaria.
Eu fiz essa prova e entrei com recurso nessa questão. A única justificativa que teria para ela, justificativa nem um pouco plausível, seria o fato dela não ter determinado qual sua chave primária, sendo assim poderiamos ter várias tuplas iguais, ou seja, não estaria nem na primeira forma normal.
Porém, se não existe uma chave primária determinada (por sublinhado), essa tabela não é uma relação, já que é obrigatório ter a determinação de uma super chave mínima para tal tabela ser uma relação.
Logo, se não é uma relação, não cabe a aplicação do conceito de normalização. Portanto, acho que cabe recurso.
-
Eu abri os comentários com a mesma dúvida, mas ao ler o com. do Sergio Paulo e prestar atenção no que diz a 1FN percebi o problema, a coluna fornecedor invalida a 1FN já que 1 item pode repetir-se indefinidamente em função de seus vários fornecedores, Em sequêcia se um modelo não está na 1FN não pode estar em nenhuma.
-
Concordo com o Gabriel, a questão está muito mal formulada. Não se falaria em normalização para tabelas sem PK.
Mesmo considerando-se que a tabela não tem chave primária, a tabela estaria na 1 FN, pois não temos dados aninhados. Não se pode afirmar nada quanto a 2FN e 3FN
-
Acho que seria a letra B.
Considerando que 'Código' seja a chave primária estaria na 1ªFN pois não há dados que se repetem neste exemplo.
O exemplo está em desacordo com a 2ªFN pois precisaria de outra tabela para os 'Fornecedores' e em desacordo com a 3ªFN pois há uma coluna que não depende exclusivamente da chave primaria (Valor Total).
-
Estou vendo que meu comentario não ficou claro apesar de um pouco errado já que realmente não há chave primária, a tabela não está normalizada validando o gabarito. Mas ainda que se considere o campo código como chave primária, assumir que a tabela está na 1FN é dizer que um determinado item só pode ser fornecido por 1 fornecedor, assim sendo mesmo erroneamente considerando o codigo como PK da tabela ela continua desnormalizada.
-
Bom dia pessoal,
Essa acertei de primeira e, pensei assim: no conceito de relação/tabela existe, "...é um conjunto de tuplas distintas", se não existe nenhuma PK ou UNIQUE então poderá ter registros duplicados e não estará na definição de relação e, assim não estará também na 1ª FN.
-
1) sem definição de chave primária.
2) atributo ValorTotal não precisa ser guardado, pode ser calculado no processamento da visualização do pedido.
3) atributo Fornecedor VARCHAR(40) devería estar em outra tabela, sendo usado o cod fornecedor.
-
A 1FN (primeira forma normal) tenta eliminar os grupos de repetição, exemplo, Fornecedor: Distribuidora de Bebidas SA.
Ou seja, para a tabela estar na 1FN deveria no mínimo desmembrar a tabela criando uma tabela exclusiva para Fornecedor
Create table Fornecedor (Fornecedor_Id, Nome_Fornecedor).
Create table Item (Código INT, Nome VARCHAR(40), ValorUnitario REAL, Qty INT, ValorTotal REAL)
A 2FN (segunda forma normal) elimina dependencias parciais, quando há necessidades de duas ou mais chaves primárias.
Ou seja, desmembrar o Item em:
Create table Item (Código INT, Nome VARCHAR(40), ValorUnitario REAL)
Create table Estoque (Código_Item_ID, Qty INT, ValorTotal REAL)
a 3FN (terceira forma normal) elimina dependencias transitivas, quando existe algum campo que não está diretamente dependente da chave primária:
Ou seja, desmembrar Estoque em:
Create table Estoque (Código_Item_ID, Qty INT)
e o Valor Total REAL será feito em uma consulta (query) pois não há necessidade de guardar esse valor no banco de dados, pois esse valor não está diretamente dependente da chave primária do Estoque Código_Item_ID.
Resumindo: A tabela do enunciado não está na 1FN, consequentemente não está na 2FN (pois para estar na 2FN precisaria atender a 1FN), que consequentemente não está na 3FN (pois para estar na 3FN deveria estar na 2FN).
a) está na segunda forma normal, porém não está na terceira forma normal. NÃO
b) está na primeira forma normal, porém não está na segunda forma normal. NÃO
c) está na primeira e na segunda forma normal. NÃO
d) não está na primeira forma normal. SIM
e) está na primeira, na segunda e na terceira forma normal. NÃO
Esse é o meu ponto de vista, baseado em algumas aulas sobre as formas normais, se eu estiver equivocado, por favor, me corrijam, pois estamos aqui para aprender e discutirmos.
-
1FN deve conter somente atributos atômicos, não pode conter atributos multivalorados.
Qual atributo multivalorado há nessa tabela??? Alguém poderia me dizer??
O atributo fornecedor é único (atômico).....se houvesse um campo endereço ai sim não estaria na 1FN
Outro erro da questão o atributo fornecedor não depende somente da chave primaria Cod_Item, portyanto não esta na 2FN;
A questão esta errada.
Bons estudos!!!
-
Gustavo, vc nao leu todos os comentarios?
Concordo com o q foi dito: fornecedor nao eh atributo atomico. Pode haver varios fornecedores para uma peça. Por exemplo, fornecedor de placas-mae de comptador, pode ser a Asus, a Gigabyte, a Foxxcom etc. Quando o funcionário da loja for preencher o pedido, ele pode inserir quantos fornecedores ele quiser, tornando o atributo multi-valorado. Nesse caso, NAO esta na 1FN, o que "invalida" as outras FNs tambem.
Essa questao eh uma pegadinha. Veja q o formulador aplicou uma tabela q pode ser representada assim:
Item(codigo, nome, valorUnit, valorTot, fornecedor).
Veja q ele não falou nada sobre chave primaria, embora subentenda-se codigo como tal. Independente disso, como ja explicado, o atributo fornecedor eh nao-atomico e a questao esta certa.
-
Se existe alguma explicação para essa questão ainda não encontrei nem nos comentários nem na literatura.
A 1FN é clara dizendo que não podem conter atributos multivalorados OU compostos, entretanto, para ser uma tabela não podemos ter um atributo multivalorado e apesar do campo Fornecedor ser VARCHAR não está claro que ele seria um campo composto.
Marquei a letra A e achei a letra C também como certa, mas marquei a A por achar MAIS certa.
A FCC não costuma aplicar provas decentes mesmo!!! Pra mim essa questão deveria ser anulada, pois foi muito mal formulada e não dá base nenhuma para que se possa respondê-la.
-
Pessoal, para mim a resposta é letra B. Está na 1FN porque não tem atributos multivalorado, mas não está na 2FN porque o atributo Fornecedor deveria ser uma chave estrangeira apontando outra tabela, para que todos os atributos da tabela sejam totalmente dependentes de sua chave primária. Agora, penso assim por:
- considerar Codigo como PK (nao está declarado como sendo, mas quem trabalha com BD tende a ensar que isso é lógico)
- considerar que Fornecedor não é FK (poderia ser! nâo está declarado, mas poderia ser)
O raciocínio da Banca foi: não foi declarado PK, portanto não está nem na 1FN. Quem trabalha com BD e está acostumado a NUNCA encontrar uma base sem PK, tende a ver Codigo como PK, e o campo Fornecedor pode ter uma série de interretações.
Portanto considero esta questão tão mal formulada que nem quem trabalha com BD a tempo acerta... Infelizmente estas questões que colocam tabelas e código SQL na maioria das vezes são coisas que nunca se verá em realidade, sempre são invenções malucas de acadêmico da Banca, tentando te avaliar sobre conceitos que na prática são tão naturais que você mal para para pensar sobre eles quando projeta um BD, mas simplesmente os segue por já estarem assimilados.
Fica a dica para ter atenção nestas questões na hora da prova.
-
Questão muito mal elaborada... acho melhor nem perder tempo tentando imaginar o que o elaborador pensou... não agrega conhecimento.
-
1ª FN: Uma tabela está na 1FN quando todos os seus atributos possuem apenas valores atômicos e monovalorados.
Se buscarmos o significado da palavra atômico no dicionário, ou para ser mais preciso o significado da palavra átomo, temos:
á.to.mo
sm (gr átomos) 1 Fís e Quím Parcela de um corpo simples, considerada outrora como indivisível...
Destaca-se como um dos seus adjetivos a palavra "indivisível", ou seja que não se permite mais outras derivações. Logo, penso que o elaborador dessa questão colocou o "Fornecedor" como sendo varchar propositalmente, pois sendo uma entidade, Fornecedor deveria ter uma tabela própria e ser apenas referenciado por meio de uma chave na tabela Item e não colocado como um atributo varchar, pois no conceito "Fornecedor" não está explícito apenas o seu nome e sim vários atributos, contrariando uma das regras da 1ª FN (atributos possuirem apenas valores atômicos).
Logo, apesar de confusa, a questão está correta ao afirmar a letra d), como sendo a resposta mais correta.
-
Pessoal, acredito que a resposta da questão diz respeito a um aspecto apenas. O conceito da 1FN. Segundo Date.
Primeira Forma Normal
- Determina que todos os atributos devem ter valores atômicos
- Não devem existir atributos multivalorados, compostos ou a combinação destes.
Ou seja, o problema está no campo ValorTotal = ValorUnitario * Qty
ValorTotal é um campo que é a combinação de outros dois.
-
Realmente ficar pensando em:
Fornecedor pode repetir p/ um mesmo Item..... mas pode nao repetir!!! ( é suposição )
Código do Item nao repeti..... mas pode repetir!!! ( outra suposição, nao disse se é PK)
Vou ficar com o Comentario da colega sobre atributo Composto/Derivado!!!
Abs.
-
É pressuposto que no modelo relacional, quando falamos em "tabelas", é IMPOSSÍVEL uma relação estar na primeira forma normal. Gastar tempo tendando entender o que o examinador quis dizer realmente é perda de tempo.
-
Pessoal, na minha opinião nem a visão do Jonas nem da Melissa estão corretas!
Sabe-se que a definição de 1FN está totalmente relacionada com a de tabela. Ou seja, só está na 1FN se for uma tabela. Veja a visão do professor Márcio Vitorino: "
Por definição, uma tabela é um conjunto desordenado de tupas exclusivas.
Então, como não há uma PK (campo unique e not null) isso não é uma tabela e, por isso não está na 1FN.
" Basicamente, é esse o motivo da letra d ser, realmente, a correta! Bons estudos!
-
Acho que a maior confusão esta na interpretação da 1FN.
A primeira forma normal não deve possuir atributos compostos e multivalorados.
Atributos Multivalorados: tornam-se tabelas ou é especificado um número máximo de atributo (por exemplo, telefone1 e telefone2, ou então cria-se uma tabela "telefone").
Composto: pode ser separado (nome, sobrenome);
Fornecedor pode se repetir várias vezes, sendo assim um atributo multivalorado. Não estando na 1FN.
-
Questãozinha marota essa viu. Você ter o discernimento que a tabela não tinha chave primária e por isso nem tabela poderia ser considerada foi uma sacada de gênio. Não à toa tem 62% de pessoas que erraram.
-
Questão para derrubar meio mundo! Acredito que Gabriel Atlanta matou a questão. A presença de chave primária é pressuposto para existir uma relação. Se não existe chave primária, não se pode garantir que não haverá tuplas repetidas e, portanto, não há de se falar em relação, tão pouco de formas normais.
-
Como já foi comentado por outros colegas, para ser TABELA tem que pelo menos ter CHAVE PRIMÁRIA.
Se não é tabela, não pode ser 1FN, 2FN etc...
-
Para está na 2 ou 3 Forma Normal, tem que antes está na primeira, óbvio, mas atentem para o atributo "Fornecedor VARCHAR(40)", nesse campo pode entrar o nome do Fornecedor assim com o nome da Empresa, por ex.: Joao, Google; dessa forma o campo ficaria multivalorado quebrando a regra da 1 forma normal.
Então letra D
-
Eu acho que o único atributo composto que poderia ser considerado como tal é o nome, composto de "item" e "1" que aparentemente é o mesmo número que o campo Código. Li todos os comentários e não achei explicação plausível. A questão não fala de chave primária, mas tem o campo Código que costuma ser PK, não vi problema nenhum nisso. E o Fornecedor achei fora de contexto, pois parece tratar-se de compras, o campo foi preenchido como NULL, então é um campo opcional.
-
A única lógica que eu encontrei foi a possibilidade de informar mais de um dado no campo FORNECEDOR. Do meu ponto de vista, devia ter sido anulada, ou ter tido o gabarito alterado.
-
Um "ITEM" pode ter mais de um fornecedor? SIM, então fornecedor é um atributo multivalorado e gerará uma nova entidade.
Pronto só isso já resolve a questão e você marcar a LETRA D como resposta correta e nem precisa analisar os demais atributos.
Se fornecedor está aí é porque temos um atributo multivalorado na tabela então ainda não esta na 1FN, simples pessoal.
Bons estudos.
-
O comentário do Bruno está perfeito. Foi a minha mesma análise. Um item pode ter mais de um fornecedor, logo multivalorado.
-
Questãozinha muito da sua vagabunda..
Quero saber como é que os colegas aí de baixo souberam que um item pode ter mais de um fornecedor. Me empresta a bola d cristal de vcs.
A prova é objetiva, não pode dar espaço para conjecturas e subjeções. Ele deveria ter dado o mínimo de contexto para poder dizer, inequivocamente, qual é alternativa correta!
-
Questão similar à Q236317 FCC - A relação não conta com chave primária.