-
Acho que a questão aborda o fato que não é porque um banco está normatizado é que ele vai garantir um bom projeto de banco de dados.
-
A normalização, independente dos outro fatores de concepção do projeto de banco de dados, tende a gerar um bom projeto a medida que aprimora as relações entre os dados em termos de redundância e consistência. Porém esta verdade não é absoluta. Se considerarmos os DataMarts, por exempo, os mesmos são desnormalizados e indexados para suportar a intensidade das consultas.
-
As formas normais, quando consideradas isoladamente de outros fatores, garantem um bom projeto de banco de dados.
Penso que geralmente garantem sim, não foi usada a palavra SEMPRE. Estaria errado se fosse:
As formas normais, quando consideradas isoladamente de outros fatores, SEMPRE garantem um bom projeto de banco de dados.
-
Navathe, 6edição, pagina 348 "Definição. A forma normalde uma relação refere-se à condição da mais alta forma normal alcançada e, consequentemente, indica o grau no qual foi normalizada. As formas normais, quando consideradas isoladamente de outros fatores, não garantem um bom projeto de banco de dados"
-
Acho sacanagem essa questão, segundo nosso amigo, somos obrigados a decorar um paragrafo de um livro. No fundo o enunciado está correto, só que está em desacordo com a opinião de um autor... A questão não avalia ninguem.
-
Quem já trabalhou com banco de dados sabe que nem sempre devemos normalizar
-
O grau de um relacionamento é o número de entidades que participam desse relacionamento.
O grau de uma relação é o número de atributos do esquema dessa relação.
As formas normais sozinhas não garantem um bom projeto.
-
É só pensar em Bancos Multidimensionais em Estrela ou bancos relacionais que precisam de realizar muitos selecta e joins. Para ambos os casos, ter um banco normalizado é desvantajoso.
-
" A forma normal de uma relação refere-se à condição da mais alta forma normal alcançada " SQN né, té doido é !!!!
pode-se alcançar forma normal na 3FN por exemplo...
-
CESPE + TI = nada garante nada!
-
Mateus Lima,
Essa afirmação está correta. Foi retirada do Navathe.
Att,
-
Conforme a colega Futura mencionou a afirmação "A forma normal de uma relação refere-se à condição da mais alta forma normal alcançada e, consequentemente, indica o grau no qual foi normalizada" está correta.
Imaginemos que as formas normais são os degraus de uma escada:
1) Ao subirmos no 1º degrau estaremos na 1ª FN;
2) No segundo degrau, estaremos na 2ª FN;
3) No terceiro degrau, na 3ª FN;
Por consequência, se estivermos no 3ª degrau, estamos na condição mais alta alcançada (refere-se à condição da mais alta forma normal alcançada) até o momento, indicando a posição em que nos encontramos(indica o grau no qual foi normalizada)
-
Complementando a resposta do Jorge Moreira. O que garante então? Tirando no Navathe 6th também: "Normal forms, when considered in isolation from other factors, do not guarantee a good database design. It is generally not sufficient to check separately that each relation schema in the database is, say, in BCNF or 3NF. Rather, the process of normalization through decomposition must also confirm the existence of additional properties that the relational schemas, taken together, should possess. These would include two properties:
- The nonadditive join or lossless join property
- The dependency preservation property
Não tenho garantia de que banco normalizado + essas duas propriedades GARANTEM um bom design de banco de dados. Às vezes performance pode ser muito mais importante do que evitar algumas eventuais anomalias. Se alguém puder complementar, seria bom.
-
Tem uma questão do CESPE q responde a esta:
Ano: 2013 Banca: CESPE / CEBRASPE Órgão: ANTT Prova: CESPE - 2013 - ANTT - Analista Administrativo - Infraestrutura de TI
Julgue os próximos itens, relativos a becape e tunning de banco de dados em um sistema de gerenciamento Oracle.
O uso de uma tabela, mesmo na terceira forma normal (3FN), pode ser indesejável para alguns ambientes, visto que, ao considerar-se o desempenho de um banco de dados, não é suficiente apenas que se mostre como os dados de uma aplicação estão relacionados aos outros, é necessário que, no projeto da aplicação, também se mostre o caminho que os usuários percorrerão para acessar os dados.
Ou seja, não é apenas as FNs que contam...há outros fatores que se devem levar em consideraçao para um bom projeto de BD.
-
Acredito que não podemos tratar as formas normais "isoladamente" para garantir um bom projeto. Afinal, todas elas tem uma relação de interdepedência, ou seja, para estar na 4FN, é preciso estar na 3FN, que é preciso estar 2FN...etc etc.