-
Acredito que robusto está voltado mais a questões internas do SGDB como transações que precisam garantir consistência, atomicidade, independência e durabilidade, além da recuperação em caso de falhas.
-
Acredito que o erro está em dizer que está voltado para a aplicação, creio que seja independente da aplicação.
-
A robustez do projeto de banco de dados está ligado à sua independência e resiliência, o que leva a pensar também no seu ciclo de vida: quanto mais longo, mais robusto, que significa dizer que ele continua útil com o passar do tempo, sem a necessidade remodelação em função das mudanças das aplicações a que serve. É um aspecto de baixo acoplamento.
-
Para que um projeto de banco de dados seja considerado robusto, é de vital importância que ele seja voltado para a aplicação na qual os dados serão usados (1º ERRO):
Se a questão especificasse "projeto físico de banco de dados" esta parte poderia está correta, mas como ela generalizou "projeto de banco de dados" deixou essa parte incorreta porque durante o processo geral de projeto e implementaçaõ de banco de dados nós temos duas fases entre as seis que são: 2. Projeto Conceitual do banco de dados; 5. Projeto Físico do Banco de dados. Na fase 2 citada anteriormente nós vamos produzir um esquema conceitual (Modelo E/R) e que seja independente de SGBD específico, no momento isso não é interessante para o usuário.
assegurando-se, dessa forma, que a aplicação será atendida em suas necessidades relacionadas a dados (2º ERRO):
quer dizer que se eu escolher a aplicação (SGBD) em que os dados serão manipulados isso vai me garantir que vai atender as necessidades relacionadas ao dados? Não faz o menor sentido, porque na fase de levantamento e análise de requisitos, basta que 1 dado seja levantado errado para que não seja atendindo as necessidades.
Gab: ERRADO
-
Para que um projeto de banco de dados seja considerado robusto, é de vital importância que ele seja voltado para a aplicação na qual os dados serão usados, assegurando-se, dessa forma, que a aplicação será atendida em suas necessidades relacionadas a dados.
Não é necessáriamente voltado para aplicação, pode ser que seja ou não.
-
"Segundo Navathe, são quatro as principais características da abordagem de banco de dados que o fazem sobressair em relação às abordagens de processamento de arquivo:
1 - natureza de autodescrição (dicionário)
2 - isolamento entre programas e dados (abstração de dados)
3 - suporte a múltipla visões de dados
4 - compartilhamento de dados e processamento de transação multiusuário."
fonte: estrategia
Assim, não há que se falar de aplicação para garantir a robustez de um Banco de dados.
-
Robusto != válido para clientes
Questão errada
-
Complementando:
Segundo Navathe,
No processamento tradicional de arquivos, a estrutura do arquivo de dados está embutida no programa da aplicação, sendo assim, qualquer mudança na estrutura de um arquivo pode exigir alterações de todos os programas que acessam esse arquivo. Ao contrário, os programas para acesso ao SGBD não exigem essas alterações na maioria dos casos. A estrutura dos arquivos de dados é armazenada no catálogo do SGDB separadamente do programa de acesso. Denominaremos essa propriedade independência programa-dados.
-
Para que um projeto de banco de dados seja considerado robusto, é de vital importância que ele seja voltado para a aplicação na qual os dados serão usados, assegurando-se, dessa forma, que a aplicação será atendida em suas necessidades relacionadas a dados.
Bom, tive que ler várias vezes para entender, então vamos lá, pois a questão induz mesmo ao erro.
O projeto de BD ao qual a questão está se referindo está relacionado ao modelo conceitual de BD, traduzindo, aquela parte que não depende do SGBD, sendo feito apenas um esposo/layout de como será tudo!
Por conseguinte, na teoria em si essa parte **** para a implementação, mas na prática é outros quinhentos.
AVANTE