Sgbd
Redundância e inconsistência de dados.
Arquivos com formatos diferentes, diferentes linguagens de programação, elementos de informação duplicados em diversos arquivos; Dificuldade no acesso aos dados. Dados recuperados de forma inconveniente e ineficiente;
Isolamento de dados. Anomalias de acesso concorrente. Dados acessados por diferentes programas aplicativos à supervisão difícil; Problemas de segurança. Difícil definição de visibilidade para usuários; Problemas de integridade. Restrição de integridade nos valores dos atributos.
Vamos definir algumas regras básicas e claras para um sistema de manipulação de dados ser considerado um SGBD. Se ao menos uma das características abaixo não estiver presente no nosso "candidato" a SGBD, este poderá ser um GA (Gerenciador de Arquivo) de altíssima qualidade, "quase" um SGBD, mas não um SGBD
Auto-Contenção- Um SGBD não contém apenas os dados em si, mas armazena completamente toda a descrição dos dados, seus relacionamentos e formas de acesso. Em um GA, em algum momento ao menos, os programas aplicativos declaram estruturas (algo que ocorre tipicamente em C, Pascal e COBOL), ou geram os relacionamentos entre os arquivos (típicos do ambiente xBase). Quando se define a forma do registro dentro do próprio programa, não está se lidando com um SGBD.
Independência dos Dados- Quando as aplicações estiverem realmente imunes as mudanças na estrutura de armazenamento ou na estratégia de acesso aos dados, pode-se dizer que esta regra foi atingida. Portanto, nenhuma definição dos dados deverá estar contida nos programas da aplicação. Quando a criação de uma nova forma de acesso um novo índice precisar ser feito dentro do código da aplicação, não está se lidando com um SGBD.
Abstração dos Dados- Em um SGBD real, é fornecida ao usuário somente uma representação conceitual dos dados, o que não inclui maiores detalhes sobre sua forma de armazenamento real. O chamado