Base de dados

Uma declaração SQL select e seu resultado

Na computação, um banco de dados é uma coleção organizada de dados armazenados e acessados eletronicamente. Pequenos bancos de dados podem ser armazenados em um sistema de arquivos, enquanto grandes bancos de dados são hospedados em clusters de computadores ou armazenamento em nuvem. O design de bancos de dados abrange técnicas formais e considerações práticas, incluindo modelagem de dados, representação e armazenamento eficientes de dados, linguagens de consulta, segurança e privacidade de dados confidenciais e problemas de computação distribuída, incluindo suporte a acesso simultâneo e tolerância a falhas.

Um sistema de gerenciamento de banco de dados (DBMS) é o software que interage com usuários finais, aplicativos e o próprio banco de dados para capturar e analisar os dados. O software DBMS abrange adicionalmente os principais recursos fornecidos para administrar o banco de dados. A soma total do banco de dados, do DBMS e dos aplicativos associados pode ser chamada de sistema de banco de dados. Frequentemente, o termo "banco de dados" também é usado vagamente para se referir a qualquer DBMS, sistema de banco de dados ou aplicativo associado ao banco de dados.

Os cientistas da computação podem classificar os sistemas de gerenciamento de banco de dados de acordo com os modelos de banco de dados que eles suportam. Os bancos de dados relacionais tornaram-se dominantes na década de 1980. Esses dados de modelo como linhas e colunas em uma série de tabelas, e a grande maioria usa SQL para escrever e consultar dados. Nos anos 2000, os bancos de dados não relacionais se tornaram populares, chamados coletivamente de NoSQL, porque usam diferentes linguagens de consulta.

Terminologia e visão geral

Formalmente, um "banco de dados" refere-se a um conjunto de dados relacionados e à forma como eles são organizados. O acesso a esses dados geralmente é fornecido por um "sistema de gerenciamento de banco de dados" (DBMS) que consiste em um conjunto integrado de software de computador que permite aos usuários interagir com um ou mais bancos de dados e fornece acesso a todos os dados contidos no banco de dados (embora possam existir restrições que limitem o acesso a dados específicos). O DBMS fornece várias funções que permitem a entrada, armazenamento e recuperação de grandes quantidades de informações e fornece maneiras de gerenciar como essas informações são organizadas.

Devido à estreita relação entre eles, o termo "banco de dados" é frequentemente usado casualmente para se referir a um banco de dados e ao DBMS usado para manipulá-lo.

Fora do mundo da tecnologia da informação profissional, o termo banco de dados é frequentemente usado para se referir a qualquer coleção de dados relacionados (como uma planilha ou um índice de cartão), pois os requisitos de tamanho e uso geralmente exigem o uso de um sistema de gerenciamento de banco de dados.

Os SGBDs existentes fornecem várias funções que permitem o gerenciamento de um banco de dados e seus dados que podem ser classificados em quatro grupos funcionais principais:

• Definição de dados – Criação, modificação e remoção de definições que definem a organização dos dados.
• Atualização – Inserção, modificação e exclusão dos dados reais.
• Reabilitação – Fornecer informações em um formulário diretamente utilizáveis ou para processamento posterior por outras aplicações. Os dados recuperados podem ser disponibilizados em um formulário basicamente o mesmo que é armazenado no banco de dados ou em uma nova forma obtida alterando ou combinando dados existentes do banco de dados.
• Administração – Registrar e monitorar os usuários, reforçar a segurança dos dados, monitorar o desempenho, manter a integridade dos dados, lidar com o controle de confiança e recuperar informações que foram corrompidas por algum evento, como uma falha inesperada do sistema.

Tanto um banco de dados quanto seu DBMS estão em conformidade com os princípios de um modelo de banco de dados específico. "Sistema de banco de dados" refere-se coletivamente ao modelo de banco de dados, sistema de gerenciamento de banco de dados e banco de dados.

Fisicamente, os servidores de banco de dados são computadores dedicados que mantêm os bancos de dados reais e executam apenas o DBMS e o software relacionado. Os servidores de banco de dados geralmente são computadores multiprocessadores, com memória generosa e matrizes de disco RAID usadas para armazenamento estável. Aceleradores de banco de dados de hardware, conectados a um ou mais servidores por meio de um canal de alta velocidade, também são usados em ambientes de processamento de transações de grande volume. Os DBMSs são encontrados no coração da maioria dos aplicativos de banco de dados. Os DBMSs podem ser construídos em torno de um kernel multitarefa personalizado com suporte de rede integrado, mas os DBMSs modernos geralmente dependem de um sistema operacional padrão para fornecer essas funções.

Como os DBMSs compreendem um mercado significativo, os fornecedores de computadores e armazenamento geralmente levam em consideração os requisitos de DBMS em seus próprios planos de desenvolvimento.

Bancos de dados e DBMSs podem ser categorizados de acordo com o(s) modelo(s) de banco de dados que eles suportam (como relacional ou XML), o(s) tipo(s) de computador em que são executados (de um cluster de servidor a um telefone celular), o linguagens de consulta usadas para acessar o banco de dados (como SQL ou XQuery) e sua engenharia interna, que afeta o desempenho, a escalabilidade, a resiliência e a segurança.

História

Os tamanhos, recursos e desempenho dos bancos de dados e seus respectivos DBMSs cresceram em ordens de magnitude. Esses aumentos de desempenho foram possibilitados pelo progresso tecnológico nas áreas de processadores, memória de computador, armazenamento de computador e redes de computador. O conceito de banco de dados tornou-se possível com o surgimento de mídias de armazenamento de acesso direto, como discos magnéticos, que se tornaram amplamente disponíveis em meados da década de 1960; os sistemas anteriores dependiam do armazenamento sequencial de dados em fita magnética. O desenvolvimento subsequente da tecnologia de banco de dados pode ser dividido em três eras com base no modelo ou estrutura de dados: navegacional, SQL/relacional e pós-relacional.

Os dois principais modelos iniciais de dados de navegação foram o modelo hierárquico e o modelo CODASYL (modelo de rede). Estes foram caracterizados pelo uso de ponteiros (geralmente endereços de disco físico) para seguir relacionamentos de um registro para outro.

O modelo relacional, proposto pela primeira vez em 1970 por Edgar F. Codd, partiu dessa tradição ao insistir que os aplicativos deveriam procurar dados por conteúdo, em vez de seguir links. O modelo relacional emprega conjuntos de tabelas no estilo livro-razão, cada uma usada para um tipo diferente de entidade. Somente em meados da década de 1980 o hardware de computação se tornou poderoso o suficiente para permitir a ampla implantação de sistemas relacionais (DBMSs mais aplicativos). No início da década de 1990, no entanto, os sistemas relacionais dominavam todos os aplicativos de processamento de dados em larga escala e, a partir de 2018, eles permaneceram dominantes: IBM Db2, Oracle, MySQL e Microsoft SQL Server são os DBMS mais pesquisados. A linguagem de banco de dados dominante, SQL padronizado para o modelo relacional, influenciou as linguagens de banco de dados para outros modelos de dados.

Os bancos de dados de objetos foram desenvolvidos na década de 1980 para superar a inconveniência da incompatibilidade de impedância objeto-relacional, o que levou à criação do termo "pós-relacional" e também o desenvolvimento de bancos de dados objeto-relacionais híbridos.

A próxima geração de bancos de dados pós-relacionais no final dos anos 2000 ficou conhecida como bancos de dados NoSQL, introduzindo armazenamentos rápidos de valor-chave e bancos de dados orientados a documentos. Uma "próxima geração" conhecidos como bancos de dados NewSQL tentaram novas implementações que retiveram o modelo relacional/SQL enquanto visavam igualar o alto desempenho do NoSQL em comparação com os DBMSs relacionais disponíveis comercialmente.

Década de 1960, DBMS de navegação

Estrutura básica do modelo de banco de dados de CODASYL de navegação

A introdução do termo banco de dados coincidiu com a disponibilidade de armazenamento de acesso direto (discos e tambores) a partir de meados da década de 1960. O termo representava um contraste com os sistemas baseados em fita do passado, permitindo o uso interativo compartilhado em vez do processamento em lote diário. O Oxford English Dictionary cita um relatório de 1962 da System Development Corporation of California como o primeiro a usar o termo "data-base" em um sentido técnico específico.

Conforme os computadores cresceram em velocidade e capacidade, vários sistemas de banco de dados de uso geral surgiram; em meados da década de 1960, vários desses sistemas entraram em uso comercial. O interesse por um padrão começou a crescer e Charles Bachman, autor de um desses produtos, o Integrated Data Store (IDS), fundou o Database Task Group dentro do CODASYL, o grupo responsável pela criação e padronização do COBOL. Em 1971, o Database Task Group lançou seu padrão, que geralmente ficou conhecido como abordagem CODASYL, e logo vários produtos comerciais baseados nessa abordagem entraram no mercado.

A abordagem CODASYL ofereceu aos aplicativos a capacidade de navegar em um conjunto de dados vinculados que foi formado em uma grande rede. Os aplicativos podem encontrar registros por um dos três métodos:

1. Uso de uma chave primária (conhecida como uma chave CALC, normalmente implementada por hashing)
2. Navegar relacionamentos (chamado conjuntos) de um registo para outro
3. Digitalização de todos os registros em uma ordem sequencial

Sistemas posteriores adicionaram árvores B para fornecer caminhos de acesso alternativos. Muitos bancos de dados CODASYL também adicionaram uma linguagem de consulta declarativa para usuários finais (diferente da API de navegação). No entanto, os bancos de dados CODASYL eram complexos e exigiam treinamento e esforço significativos para produzir aplicativos úteis.

A IBM também tinha seu próprio DBMS em 1966, conhecido como Information Management System (IMS). IMS foi um desenvolvimento de software escrito para o programa Apollo no System/360. O IMS era geralmente semelhante em conceito ao CODASYL, mas usava uma hierarquia estrita para seu modelo de navegação de dados em vez do modelo de rede do CODASYL. Ambos os conceitos mais tarde se tornaram conhecidos como bancos de dados de navegação devido à forma como os dados eram acessados: o termo foi popularizado pela apresentação do Prêmio Turing de Bachman em 1973 O programador como navegador. O IMS é classificado pela IBM como um banco de dados hierárquico. IDMS e Cincom Systems' Os bancos de dados TOTAL são classificados como bancos de dados de rede. IMS permanece em uso a partir de 2014.

Década de 1970, DBMS relacional

Edgar F. Codd trabalhou na IBM em San Jose, Califórnia, em um de seus escritórios secundários, principalmente envolvidos no desenvolvimento de sistemas de disco rígido. Ele estava insatisfeito com o modelo de navegação da abordagem CODASYL, principalmente com a falta de uma função de "busca" instalação. Em 1970, ele escreveu vários artigos que delineavam uma nova abordagem para a construção de banco de dados que eventualmente culminou no inovador A Relational Model of Data for Large Shared Data Banks.

Neste artigo, ele descreveu um novo sistema para armazenar e trabalhar com grandes bancos de dados. Em vez de os registros serem armazenados em algum tipo de lista encadeada de registros de formato livre como no CODASYL, a ideia de Codd era organizar os dados como um número de "tabelas", cada tabela sendo usada para um tipo diferente de entidade. Cada tabela conteria um número fixo de colunas contendo os atributos da entidade. Uma ou mais colunas de cada tabela foram designadas como uma chave primária pela qual as linhas da tabela podem ser identificadas de forma única; referências cruzadas entre tabelas sempre usaram essas chaves primárias, em vez de endereços de disco, e as consultas juntariam tabelas com base nesses relacionamentos de chave, usando um conjunto de operações baseadas no sistema matemático de cálculo relacional (do qual o modelo leva seu nome). Dividir os dados em um conjunto de tabelas normalizadas (ou relações) visa garantir que cada "fato" foi armazenado apenas uma vez, simplificando assim as operações de atualização. As tabelas virtuais chamadas visualizações podem apresentar os dados de diferentes maneiras para diferentes usuários, mas as visualizações não podem ser atualizadas diretamente.

Codd usou termos matemáticos para definir o modelo: relações, tuplas e domínios em vez de tabelas, linhas e colunas. A terminologia que agora é familiar veio das primeiras implementações. Codd mais tarde criticaria a tendência das implementações práticas de se afastarem dos fundamentos matemáticos nos quais o modelo se baseava.

No modelo relacional, os registros são "ligados" usando chaves virtuais não armazenadas no banco de dados, mas definidos conforme necessário entre os dados contidos nos registros.

O uso de chaves primárias (identificadores orientados ao usuário) para representar relacionamentos entre tabelas, em vez de endereços de disco, teve duas motivações principais. Do ponto de vista da engenharia, isso permitiu que as tabelas fossem realocadas e redimensionadas sem a dispendiosa reorganização do banco de dados. Mas Codd estava mais interessado na diferença de semântica: o uso de identificadores explícitos tornou mais fácil definir operações de atualização com definições matemáticas claras e também permitiu que as operações de consulta fossem definidas em termos da disciplina estabelecida de cálculo de predicados de primeira ordem; como essas operações têm propriedades matemáticas limpas, torna-se possível reescrever consultas de maneiras comprovadamente corretas, que é a base da otimização de consultas. Não há perda de expressividade em relação aos modelos hierárquicos ou em rede, embora as conexões entre as tabelas não sejam mais tão explícitas.

Nos modelos hierárquico e de rede, os registros podem ter uma estrutura interna complexa. Por exemplo, o histórico salarial de um funcionário pode ser representado como um "grupo recorrente" dentro do cadastro do empregado. No modelo relacional, o processo de normalização fez com que essas estruturas internas fossem substituídas por dados contidos em múltiplas tabelas, conectadas apenas por chaves lógicas.

Por exemplo, um uso comum de um sistema de banco de dados é rastrear informações sobre usuários, seus nomes, informações de login, vários endereços e números de telefone. Na abordagem de navegação, todos esses dados seriam colocados em um único registro de comprimento variável. Na abordagem relacional, os dados seriam normalizados em uma tabela de usuários, uma tabela de endereços e uma tabela de números de telefone (por exemplo). Os registros seriam criados nessas tabelas opcionais apenas se o endereço ou os números de telefone fossem realmente fornecidos.

Além de identificar linhas/registros usando identificadores lógicos em vez de endereços de disco, Codd mudou a maneira como os aplicativos reuniam dados de vários registros. Em vez de exigir que os aplicativos coletem dados um registro por vez navegando pelos links, eles usariam uma linguagem de consulta declarativa que expressasse quais dados eram necessários, em vez do caminho de acesso pelo qual eles deveriam ser encontrados. Encontrar um caminho de acesso eficiente aos dados tornou-se responsabilidade do sistema de gerenciamento de banco de dados, e não do programador do aplicativo. Esse processo, chamado de otimização de consulta, dependia do fato de que as consultas eram expressas em termos de lógica matemática.

O artigo de Codd foi recolhido por duas pessoas em Berkeley, Eugene Wong e Michael Stonebraker. Eles iniciaram um projeto conhecido como INGRES usando fundos que já haviam sido alocados para um projeto de banco de dados geográfico e estudantes de programação para produzir código. Começando em 1973, o INGRES entregou seus primeiros produtos de teste que estavam geralmente prontos para uso generalizado em 1979. O INGRES era semelhante ao System R de várias maneiras, incluindo o uso de uma "linguagem" para acesso a dados, conhecido como QUEL. Com o tempo, o INGRES mudou para o padrão SQL emergente.

A própria IBM fez uma implementação de teste do modelo relacional, PRTV, e uma de produção, Business System 12, ambas já descontinuadas. Honeywell escreveu MRDS para Multics, e agora há duas novas implementações: Alphora Dataphor e Rel. A maioria das outras implementações de DBMS geralmente chamadas de relacionais são na verdade DBMSs SQL.

Em 1970, a Universidade de Michigan iniciou o desenvolvimento do MICRO Information Management System baseado em D.L. Crianças' Modelo de dados conjunto-teórico. O MICRO foi usado para gerenciar conjuntos de dados muito grandes pelo Departamento do Trabalho dos EUA, pela Agência de Proteção Ambiental dos EUA e por pesquisadores da Universidade de Alberta, da Universidade de Michigan e da Wayne State University. Ele rodava em computadores mainframe IBM usando o Michigan Terminal System. O sistema permaneceu em produção até 1998.

Abordagem integrada

Nas décadas de 1970 e 1980, foram feitas tentativas de construir sistemas de banco de dados com hardware e software integrados. A filosofia subjacente era que essa integração proporcionaria maior desempenho a um custo menor. Os exemplos foram o IBM System/38, a primeira oferta da Teradata, e a máquina de banco de dados da Britton Lee, Inc.

Outra abordagem de suporte de hardware para gerenciamento de banco de dados foi o acelerador CAFS da ICL, um controlador de disco de hardware com recursos de pesquisa programáveis. A longo prazo, esses esforços geralmente não tiveram sucesso porque as máquinas de banco de dados especializadas não conseguiam acompanhar o rápido desenvolvimento e progresso dos computadores de uso geral. Assim, a maioria dos sistemas de banco de dados hoje em dia são sistemas de software executados em hardware de uso geral, usando armazenamento de dados de computador de uso geral. No entanto, essa ideia ainda é perseguida em certas aplicações por algumas empresas como Netezza e Oracle (Exadata).

Final dos anos 1970, SQL DBMS

A IBM começou a trabalhar em um protótipo de sistema vagamente baseado nos conceitos de Codd como Sistema R no início dos anos 1970. A primeira versão ficou pronta em 1974/5, e começaram então os trabalhos em sistemas multi-tabelas nos quais os dados podiam ser divididos de forma que todos os dados de um registro (alguns dos quais são opcionais) não precisassem ser armazenados em um único grande "pedaço". Versões multiusuário subseqüentes foram testadas por clientes em 1978 e 1979, quando uma linguagem de consulta padronizada – SQL – foi adicionada. As ideias de Codd estavam se estabelecendo como funcionais e superiores ao CODASYL, levando a IBM a desenvolver uma verdadeira versão de produção do System R, conhecida como SQL/DS e, posteriormente, Database 2 (IBM Db2).

O banco de dados Oracle de Larry Ellison (ou mais simplesmente, Oracle) começou a partir de uma cadeia diferente, com base nos documentos da IBM sobre o System R. Embora as implementações do Oracle V1 tenham sido concluídas em 1978, foi o primeiro passo. t até a versão 2 do Oracle, quando Ellison venceu a IBM no mercado em 1979.

Stonebraker passou a aplicar as lições do INGRES para desenvolver um novo banco de dados, Postgres, que agora é conhecido como PostgreSQL. O PostgreSQL é frequentemente usado para aplicativos globais de missão crítica (os registros de nome de domínio.org e.info o usam como seu armazenamento de dados primário, assim como muitas grandes empresas e instituições financeiras).

Na Suécia, o artigo de Codd também foi lido e o Mimer SQL foi desenvolvido em meados da década de 1970 na Universidade de Uppsala. Em 1984, esse projeto foi consolidado em uma empresa independente.

Outro modelo de dados, o modelo entidade-relacionamento, surgiu em 1976 e ganhou popularidade para o projeto de banco de dados, pois enfatizava uma descrição mais familiar do que o modelo relacional anterior. Mais tarde, os constructos entidade-relacionamento foram adaptados como um constructo de modelagem de dados para o modelo relacional, e a diferença entre os dois tornou-se irrelevante.

Década de 1980, no desktop

A década de 1980 marcou o início da era da computação de desktop. Os novos computadores capacitaram seus usuários com planilhas como o Lotus 1-2-3 e software de banco de dados como o dBASE. O produto dBASE era leve e fácil para qualquer usuário de computador entender imediatamente. C. Wayne Ratliff, o criador do dBASE, declarou: "dBASE era diferente de programas como BASIC, C, FORTRAN e COBOL porque muito do trabalho sujo já havia sido feito. A manipulação de dados é feita pelo dBASE e não pelo usuário, para que o usuário possa se concentrar no que está fazendo, em vez de ter que se preocupar com detalhes sujos de abertura, leitura e fechamento de arquivos e gerenciamento de alocação de espaço." dBASE foi um dos títulos de software mais vendidos na década de 1980 e início de 1990.

Década de 1990, orientado a objetos

A década de 1990, juntamente com o aumento da programação orientada a objetos, viu um crescimento na forma como os dados em vários bancos de dados eram tratados. Programadores e designers começaram a tratar os dados em seus bancos de dados como objetos. Isso quer dizer que, se os dados de uma pessoa estivessem em um banco de dados, os atributos dessa pessoa, como endereço, número de telefone e idade, agora eram considerados pertencentes a essa pessoa em vez de dados estranhos. Isso permite que as relações entre os dados sejam relacionadas a objetos e seus atributos e não a campos individuais. O termo "incompatibilidade de impedância objeto-relacional" descreveu a inconveniência de traduzir entre objetos programados e tabelas de banco de dados. Os bancos de dados de objetos e os bancos de dados objeto-relacionais tentam resolver esse problema fornecendo uma linguagem orientada a objetos (às vezes como extensões do SQL) que os programadores podem usar como alternativa ao SQL puramente relacional. No lado da programação, as bibliotecas conhecidas como mapeamentos objeto-relacionais (ORMs) tentam resolver o mesmo problema.

Anos 2000, NoSQL e NewSQL

Bancos de dados XML são um tipo de banco de dados estruturado orientado a documentos que permite consultas com base em atributos de documentos XML. Os bancos de dados XML são usados principalmente em aplicativos onde os dados são convenientemente vistos como uma coleção de documentos, com uma estrutura que pode variar de muito flexível a altamente rígida: exemplos incluem artigos científicos, patentes, declarações fiscais e registros pessoais.

Bancos de dados NoSQL geralmente são muito rápidos, não requerem esquemas de tabela fixos, evitam operações de junção armazenando dados desnormalizados e são projetados para escalar horizontalmente.

Nos últimos anos, houve uma forte demanda por bancos de dados massivamente distribuídos com alta tolerância à partição, mas de acordo com o teorema CAP, é impossível para um sistema distribuído fornecer simultaneamente garantias de consistência, disponibilidade e tolerância à partição. Um sistema distribuído pode satisfazer quaisquer duas dessas garantias ao mesmo tempo, mas não todas as três. Por esse motivo, muitos bancos de dados NoSQL estão usando o que é chamado de consistência eventual para fornecer garantias de disponibilidade e tolerância de partição com um nível reduzido de consistência de dados.

NewSQL é uma classe de bancos de dados relacionais modernos que visa fornecer o mesmo desempenho escalável dos sistemas NoSQL para cargas de trabalho de processamento de transações online (leitura-gravação), enquanto ainda usa SQL e mantém as garantias ACID de um sistema de banco de dados tradicional.

Casos de uso

Os bancos de dados são usados para dar suporte às operações internas das organizações e para sustentar as interações online com clientes e fornecedores (consulte Software empresarial).

Os bancos de dados são usados para armazenar informações administrativas e dados mais especializados, como dados de engenharia ou modelos econômicos. Os exemplos incluem sistemas de bibliotecas computadorizadas, sistemas de reservas de voos, sistemas de inventário de peças computadorizadas e muitos sistemas de gerenciamento de conteúdo que armazenam sites como coleções de páginas em um banco de dados.

Classificação

Uma forma de classificar bases de dados envolve o tipo de seu conteúdo, por exemplo: bibliográfico, documento-texto, estatístico ou objetos multimídia. Outra maneira é por sua área de aplicação, por exemplo: contabilidade, composições musicais, filmes, bancos, manufatura ou seguros. Uma terceira forma é por algum aspecto técnico, como a estrutura do banco de dados ou o tipo de interface. Esta seção lista alguns dos adjetivos usados para caracterizar diferentes tipos de bancos de dados.

• Um banco de dados em memória é um banco de dados que reside principalmente na memória principal, mas é tipicamente apoiada pelo armazenamento de dados de computador não volátil. Os principais bancos de dados de memória são mais rápidos do que os bancos de dados de disco, e por isso são frequentemente usados onde o tempo de resposta é crítico, como nos equipamentos de rede de telecomunicações.
• Um banco de dados ativo inclui uma arquitetura orientada para eventos que pode responder a condições dentro e fora do banco de dados. Os possíveis usos incluem monitoramento de segurança, alerta, coleta de estatísticas e autorização. Muitos bancos de dados fornecem recursos de banco de dados ativos na forma de gatilhos de banco de dados.
• Um banco de dados em nuvem depende da tecnologia de nuvem. Tanto o banco de dados como a maioria de seus DBMS residem remotamente, "na nuvem", enquanto seus aplicativos são desenvolvidos por programadores e mais tarde mantidos e usados por usuários finais através de um navegador da web e APIs abertas.
• Os armazéns de dados arquivam dados de bases de dados operacionais e muitas vezes de fontes externas, como empresas de pesquisa de mercado. O armazém torna-se a fonte central de dados para uso por gerentes e outros usuários finais que podem não ter acesso a dados operacionais. Por exemplo, os dados de vendas podem ser agregados a totais semanais e convertidos de códigos de produtos internos para usar UPCs para que possam ser comparados com dados ACNielsen. Alguns componentes básicos e essenciais do armazenamento de dados incluem extração, análise e dados de mineração, transformação, carregamento e gerenciamento de dados para torná-los disponíveis para uso adicional.
• Um banco de dados dedutivo combina programação lógica com um banco de dados relacional.
• Um banco de dados distribuído é um em que os dados e o DBMS abrangem vários computadores.
• Um banco de dados orientado a documentos é projetado para armazenar, recuperar e gerenciar informações orientadas a documentos ou semiestruturadas. As bases de dados orientadas para documentos são uma das principais categorias de bases de dados NoSQL.
• Um sistema de banco de dados incorporado é um DBMS que está firmemente integrado com um software de aplicação que requer acesso a dados armazenados de tal forma que o DBMS está escondido dos usuários finais da aplicação e requer pouca ou nenhuma manutenção em curso.
• Bancos de dados de usuário final consistem em dados desenvolvidos por usuários finais individuais. Exemplos destes são coleções de documentos, planilhas, apresentações, multimídia e outros arquivos. Vários produtos existem para apoiar tais bancos de dados.
• Um sistema de banco de dados federado compreende vários bancos de dados distintos, cada um com seu próprio DBMS. Ele é tratado como um único banco de dados por um sistema de gerenciamento de banco de dados federado (FDBMS), que integra transparentemente vários DBMS autônomos, possivelmente de diferentes tipos (em que caso também seria um sistema de banco de dados heterogêneo), e fornece-lhes uma visão conceitual integrada.
• Às vezes o termo multi-base de dados é usado como sinônimo de banco de dados federado, embora possa se referir a um grupo de bancos de dados menos integrado (por exemplo, sem FDBMS e um esquema integrado gerenciado) que cooperam em uma única aplicação. Neste caso, tipicamente middleware é usado para distribuição, que normalmente inclui um protocolo de commit atômico (ACP), por exemplo, o protocolo de commit de duas fases, para permitir transações distribuídas (globais) em todas as bases de dados participantes.
• Um banco de dados de gráficos é um tipo de banco de dados NoSQL que usa estruturas de gráficos com nós, bordas e propriedades para representar e armazenar informações. Bancos de dados de gráficos gerais que podem armazenar qualquer gráfico são distintos de bancos de dados de gráficos especializados, como triplestores e bancos de dados de rede.
• Um array DBMS é um tipo de DBMS NoSQL que permite modelagem, armazenamento e recuperação de arrays multidimensionais (geralmente grandes), como imagens de satélite e saída de simulação climática.
• Em um banco de dados de hipertexto ou hipermedia, qualquer palavra ou um texto que represente um objeto, por exemplo, outra peça de texto, um artigo, uma imagem ou um filme, pode ser hiperligado a esse objeto. Os bancos de dados de hipertexto são particularmente úteis para organizar grandes quantidades de informações diferentes. Por exemplo, eles são úteis para organizar enciclopédias on-line, onde os usuários podem convenientemente saltar ao redor do texto. O World Wide Web é, portanto, um grande banco de dados de hipertexto distribuído.
• Uma base de conhecimento (abbreviada KB, kb ou Δ) é um tipo especial de banco de dados para gerenciamento de conhecimento, fornecendo os meios para a coleta, organização e recuperação de conhecimento informatizados. Também uma coleção de dados representando problemas com suas soluções e experiências relacionadas.

• Um banco de dados móvel pode ser carregado ou sincronizado a partir de um dispositivo de computação móvel.
• As bases de dados operacionais armazenam dados detalhados sobre as operações de uma organização. Eles normalmente processam volumes relativamente altos de atualizações usando transações. Exemplos incluem bancos de dados de clientes que registram contato, crédito e informações demográficas sobre clientes de uma empresa, bancos de dados de pessoal que possuem informações como salário, benefícios, dados de habilidades sobre funcionários, sistemas de planejamento de recursos empresariais que registram detalhes sobre componentes de produto, inventário de peças e bancos de dados financeiros que acompanham o dinheiro, contabilidade e negócios financeiros da organização.
• Um banco de dados paralelo procura melhorar o desempenho através da paralelização para tarefas como carregar dados, construir índices e avaliar consultas.

As principais arquiteturas paralelas do DBMS que são induzidas pela arquitetura de hardware subjacente são:

• Arquitetura de memória compartilhada, onde vários processadores compartilham o espaço de memória principal, bem como outro armazenamento de dados.
• Arquitetura de disco compartilhada, onde cada unidade de processamento (tipicamente composta por múltiplos processadores) tem sua própria memória principal, mas todas as unidades compartilham o outro armazenamento.
• Arquitetura compartilhada, onde cada unidade de processamento tem sua própria memória principal e outro armazenamento.

• Bases de dados probabilísticas empregam lógica fuzzy para desenhar inferências de dados imprecisos.
• Os bancos de dados em tempo real processam transações rápidas o suficiente para o resultado voltar e ser acionado imediatamente.
• Um banco de dados espacial pode armazenar os dados com características multidimensionais. As consultas sobre esses dados incluem consultas baseadas em localização, como "Onde está o hotel mais próximo na minha área?".
• Um banco de dados temporal tem aspectos de tempo incorporados, por exemplo, um modelo de dados temporais e uma versão temporal do SQL. Mais especificamente os aspectos temporais geralmente incluem tempo válido e tempo de transação.
• Um banco de dados orientado para a terminologia baseia-se em um banco de dados orientado a objetos, muitas vezes personalizado para um campo específico.
• Um banco de dados de dados não estruturado destina-se a armazenar de forma gerenciável e protegida objetos diversos que não se encaixam naturalmente e convenientemente em bases de dados comuns. Pode incluir mensagens de e-mail, documentos, revistas, objetos multimídia, etc. O nome pode ser enganoso, pois alguns objetos podem ser altamente estruturados. No entanto, toda a coleção de objetos possíveis não se encaixa em uma estrutura estrutura estruturada predefinida. Os DBMS mais estabelecidos agora suportam dados não estruturados de várias maneiras, e novos DBMS dedicados estão surgindo.

Sistema de gerenciamento de banco de dados

Connolly e Begg definem o sistema de gerenciamento de banco de dados (DBMS) como um "sistema de software que permite aos usuários definir, criar, manter e controlar o acesso ao banco de dados". Exemplos de DBMS incluem MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, Oracle Database e Microsoft Access.

O acrônimo DBMS às vezes é estendido para indicar o modelo de banco de dados subjacente, com RDBMS para o relacional, OODBMS para o objeto (orientado) e ORDBMS para o modelo objeto-relacional. Outras extensões podem indicar algumas outras características, como DDBMS para sistemas de gerenciamento de banco de dados distribuído.

A funcionalidade fornecida por um DBMS pode variar enormemente. A funcionalidade principal é o armazenamento, recuperação e atualização de dados. Codd propôs as seguintes funções e serviços que um SGBD de propósito geral completo deve fornecer:

• Armazenamento, recuperação e atualização de dados
• Catálogo acessível ao usuário ou dicionário de dados descrevendo os metadados
• Apoio às transacções e concurrência
• Instalações para recuperar o banco de dados se ele se tornar danificado
• Suporte para autorização de acesso e atualização de dados
• Suporte de acesso a locais remotos
• O reforço das restrições para garantir que os dados na base de dados estejam em conformidade com determinadas regras

Também é de se esperar que o DBMS forneça um conjunto de utilitários para os propósitos necessários para administrar o banco de dados de forma eficaz, incluindo utilitários de importação, exportação, monitoramento, desfragmentação e análise. A parte principal do DBMS que interage entre o banco de dados e a interface do aplicativo, às vezes chamada de mecanismo de banco de dados.

Muitas vezes, os DBMSs terão parâmetros de configuração que podem ser ajustados estática e dinamicamente, por exemplo, a quantidade máxima de memória principal em um servidor que o banco de dados pode usar. A tendência é minimizar a quantidade de configuração manual e, para casos como bancos de dados incorporados, a necessidade de direcionar a administração zero é fundamental.

Os principais DBMSs corporativos tendem a aumentar em tamanho e funcionalidade e envolvem até milhares de anos humanos de esforço de desenvolvimento ao longo de sua vida útil.

Os primeiros DBMS multiusuário geralmente permitiam apenas que o aplicativo residisse no mesmo computador com acesso por meio de terminais ou software de emulação de terminal. A arquitetura cliente-servidor foi um desenvolvimento em que o aplicativo residia em um desktop cliente e o banco de dados em um servidor permitindo que o processamento fosse distribuído. Isso evoluiu para uma arquitetura multicamadas que incorpora servidores de aplicativos e servidores da Web com a interface do usuário final por meio de um navegador da Web com o banco de dados conectado diretamente apenas à camada adjacente.

Um DBMS de uso geral fornecerá interfaces de programação de aplicativos (API) públicos e, opcionalmente, um processador para linguagens de banco de dados, como SQL, para permitir que os aplicativos sejam escritos para interagir e manipular o banco de dados. Um DBMS de finalidade especial pode usar uma API privada e ser especificamente personalizado e vinculado a um único aplicativo. Por exemplo, um sistema de e-mail executa muitas das funções de um DBMS de uso geral, como inserção de mensagem, exclusão de mensagem, manipulação de anexos, pesquisa de lista de bloqueio, associação de mensagens a um endereço de e-mail e assim por diante; no entanto, essas funções são limitadas ao que é necessário para lidar e-mail.

Aplicativo

A interação externa com o banco de dados será por meio de um programa aplicativo que faz interface com o SGBD. Isso pode variar de uma ferramenta de banco de dados que permite aos usuários executar consultas SQL textual ou graficamente, a um site que usa um banco de dados para armazenar e pesquisar informações.

Interface do programa aplicativo

Um programador codificará as interações com o banco de dados (às vezes chamado de fonte de dados) por meio de uma interface de programa de aplicativo (API) ou por meio de uma linguagem de banco de dados. A API ou linguagem específica escolhida precisará ser suportada pelo DBMS, possivelmente indiretamente por meio de um pré-processador ou uma API de ponte. Algumas APIs visam ser independentes do banco de dados, sendo o ODBC um exemplo comumente conhecido. Outras APIs comuns incluem JDBC e ADO.NET.

Idiomas de banco de dados

As linguagens de banco de dados são linguagens de finalidade especial, que permitem uma ou mais das seguintes tarefas, às vezes distinguidas como sublinguagens:

• Língua de controle de dados (DCL) – controla o acesso aos dados;
• linguagem de definição de dados (DDL) – define tipos de dados como criar, alterar ou soltar tabelas e as relações entre eles;
• Língua de manipulação de dados (DML) – executa tarefas como inserção, atualização ou exclusão de ocorrências de dados;
• A linguagem de consulta de dados (DQL) permite procurar informações e informações derivadas de computação.

As linguagens de banco de dados são específicas para um determinado modelo de dados. Exemplos notáveis incluem:

• SQL combina os papéis da definição de dados, manipulação de dados e consulta em um único idioma. Foi uma das primeiras línguas comerciais para o modelo relacional, embora partindo em alguns aspectos do modelo relacional como descrito por Codd (por exemplo, as linhas e colunas de uma tabela podem ser ordenadas). O SQL tornou-se um padrão do American National Standards Institute (ANSI) em 1986, e da International Organization for Standardization (ISO) em 1987. Os padrões foram regularmente aprimorados desde e são suportados (com diferentes graus de conformidade) por todos os DBMS relacionais comerciais tradicionais.
• OQL é um padrão de linguagem de modelo de objeto (do Object Data Management Group). Ele influenciou o design de algumas das mais recentes linguagens de consulta como JDOQL e EJB QL.
• XQuery é uma linguagem de consulta XML padrão implementada por sistemas de banco de dados XML, como MarkLogic e eXist, por bancos de dados relacionais com capacidade XML, como Oracle e Db2, e também por processadores XML em memória, como o Saxon.
• SQL/XML combina XQuery com SQL.

Uma linguagem de banco de dados também pode incorporar recursos como:

• Configuração e gerenciamento de mecanismos de armazenamento específicos do DBMS
• Computações para modificar resultados de consulta, como contagem, soma, média, classificação, agrupamento e referências cruzadas
• Aplicação de restrições (por exemplo, em um banco de dados automotivo, permitindo apenas um tipo de motor por carro)
• Aplicação versão de interface de programação da linguagem de consulta, para conveniência do programador

Armazenamento

O armazenamento de banco de dados é o recipiente da materialização física de um banco de dados. Compreende o nível interno (físico) na arquitetura do banco de dados. Ele também contém todas as informações necessárias (por exemplo, metadados, "dados sobre os dados" e estruturas internas de dados) para reconstruir o nível conceitual e o nível externo do nível interno quando necessário. Bancos de dados como objetos digitais contêm três camadas de informações que devem ser armazenadas: os dados, a estrutura e a semântica. O armazenamento adequado de todas as três camadas é necessário para preservação futura e longevidade do banco de dados. Colocar dados em armazenamento permanente geralmente é responsabilidade do mecanismo de banco de dados, também conhecido como "mecanismo de armazenamento". Embora normalmente acessado por um DBMS por meio do sistema operacional subjacente (e geralmente usando os sistemas de arquivos do sistema operacional como intermediários para o layout de armazenamento), as propriedades de armazenamento e as definições de configuração são extremamente importantes para a operação eficiente do DBMS e, portanto, estão intimamente relacionadas mantidos por administradores de banco de dados. Um SGBD, enquanto está em operação, sempre tem seu banco de dados residindo em diversos tipos de armazenamento (por exemplo, memória e armazenamento externo). Os dados do banco de dados e as informações adicionais necessárias, possivelmente em grandes quantidades, são codificados em bits. Os dados geralmente residem no armazenamento em estruturas que parecem completamente diferentes da aparência dos dados nos níveis conceitual e externo, mas de maneiras que tentam otimizar (o melhor possível) esses níveis. reconstrução quando necessário por usuários e programas, bem como para computar tipos adicionais de informações necessárias dos dados (por exemplo, ao consultar o banco de dados).

Alguns DBMSs suportam a especificação de qual codificação de caracteres foi usada para armazenar dados, portanto, várias codificações podem ser usadas no mesmo banco de dados.

Várias estruturas de armazenamento de banco de dados de baixo nível são usadas pelo mecanismo de armazenamento para serializar o modelo de dados para que ele possa ser gravado no meio de sua escolha. Técnicas como indexação podem ser usadas para melhorar o desempenho. O armazenamento convencional é orientado a linhas, mas também há bancos de dados de correlação e orientados a colunas.

Visualizações materializadas

Muitas vezes, a redundância de armazenamento é empregada para aumentar o desempenho. Um exemplo comum é o armazenamento de visualizações materializadas, que consistem em visualizações externas frequentemente necessárias ou resultados de consultas. Armazenar tais exibições economiza o dispendioso cálculo delas sempre que elas são necessárias. As desvantagens das visualizações materializadas são a sobrecarga incorrida ao atualizá-las para mantê-las sincronizadas com os dados originais atualizados do banco de dados e o custo da redundância de armazenamento.

Replicação

Ocasionalmente, um banco de dados emprega redundância de armazenamento por replicação de objetos de banco de dados (com uma ou mais cópias) para aumentar a disponibilidade de dados (para melhorar o desempenho de vários acessos simultâneos de vários usuários finais ao mesmo objeto de banco de dados e para fornecer resiliência em caso de falha parcial de um banco de dados distribuído). As atualizações de um objeto replicado precisam ser sincronizadas nas cópias do objeto. Em muitos casos, todo o banco de dados é replicado.

Virtualização

Com a virtualização de dados, os dados usados permanecem em seus locais originais e o acesso em tempo real é estabelecido para permitir análises em várias fontes. Isso pode ajudar a resolver algumas dificuldades técnicas, como problemas de compatibilidade ao combinar dados de várias plataformas, diminuindo o risco de erro causado por dados incorretos e garantindo que os dados mais recentes sejam usados. Além disso, evitar a criação de um novo banco de dados contendo informações pessoais pode facilitar o cumprimento dos regulamentos de privacidade. No entanto, com a virtualização de dados, a conexão com todas as fontes de dados necessárias deve estar operacional, pois não há cópia local dos dados, o que é uma das principais desvantagens da abordagem.

Segurança

A segurança do banco de dados lida com todos os vários aspectos da proteção do conteúdo do banco de dados, seus proprietários e usuários. Ele varia desde a proteção contra usos intencionais não autorizados do banco de dados até acessos não intencionais ao banco de dados por entidades não autorizadas (por exemplo, uma pessoa ou um programa de computador).

O controle de acesso ao banco de dados lida com o controle de quem (uma pessoa ou um determinado programa de computador) tem permissão para acessar quais informações no banco de dados. As informações podem incluir objetos de banco de dados específicos (por exemplo, tipos de registro, registros específicos, estruturas de dados), certos cálculos sobre certos objetos (por exemplo, tipos de consulta ou consultas específicas) ou usando caminhos de acesso específicos para o primeiro (por exemplo, usando índices específicos ou outras estruturas de dados para acessar informações). Os controles de acesso ao banco de dados são definidos por pessoal autorizado especial (pelo proprietário do banco de dados) que usa interfaces DBMS de segurança protegidas dedicadas.

Isso pode ser gerenciado diretamente de forma individual, ou pela atribuição de indivíduos e privilégios a grupos, ou (nos modelos mais elaborados) pela atribuição de indivíduos e grupos a papéis aos quais são concedidos direitos. A segurança dos dados impede que usuários não autorizados visualizem ou atualizem o banco de dados. Usando senhas, os usuários têm permissão para acessar todo o banco de dados ou subconjuntos dele chamados "subesquemas". Por exemplo, um banco de dados de funcionários pode conter todos os dados sobre um funcionário individual, mas um grupo de usuários pode ser autorizado a visualizar apenas os dados da folha de pagamento, enquanto outros têm permissão para acessar apenas o histórico de trabalho e dados médicos. Se o DBMS fornecer uma maneira de inserir e atualizar interativamente o banco de dados, bem como interrogá-lo, esse recurso permitirá o gerenciamento de bancos de dados pessoais.

A segurança de dados em geral lida com a proteção de blocos específicos de dados, tanto fisicamente (ou seja, de corrupção, destruição ou remoção; por exemplo, consulte segurança física), ou a interpretação deles ou partes deles para informações significativas (por exemplo, observando as sequências de bits que eles compreendem, concluindo números de cartão de crédito válidos específicos; por exemplo, consulte criptografia de dados).

Change and access logging registra quem acessou quais atributos, o que foi alterado e quando foi alterado. Os serviços de registro permitem uma auditoria forense do banco de dados posteriormente, mantendo um registro das ocorrências e alterações de acesso. Às vezes, o código no nível do aplicativo é usado para registrar as alterações, em vez de deixá-lo no banco de dados. O monitoramento pode ser configurado para tentar detectar violações de segurança. Portanto, as organizações devem levar a segurança do banco de dados a sério devido aos muitos benefícios que ela oferece. As organizações serão protegidas contra violações de segurança e atividades de hackers, como invasão de firewall, propagação de vírus e resgate. Isso ajuda a proteger as informações essenciais da empresa, que não podem ser compartilhadas com terceiros em hipótese alguma.

Transações e simultaneidade

As transações de banco de dados podem ser usadas para introduzir algum nível de tolerância a falhas e integridade de dados após a recuperação de uma falha. Uma transação de banco de dados é uma unidade de trabalho, normalmente encapsulando uma série de operações em um banco de dados (por exemplo, ler um objeto de banco de dados, escrever, adquirir ou liberar um bloqueio, etc.), uma abstração suportada no banco de dados e também em outros sistemas. Cada transação tem limites bem definidos em termos de quais execuções de programa/código são incluídas nessa transação (determinado pelo programador da transação por meio de comandos de transação especiais).

O acrônimo ACID descreve algumas propriedades ideais de uma transação de banco de dados: atomicidade, consistência, isolamento e durabilidade.

Migração

Um banco de dados construído com um SGBD não é portável para outro SGBD (ou seja, o outro SGBD não pode executá-lo). No entanto, em algumas situações, é desejável migrar um banco de dados de um DBMS para outro. As razões são principalmente econômicas (diferentes DBMSs podem ter diferentes custos totais de propriedade ou TCOs), funcionais e operacionais (diferentes DBMSs podem ter diferentes capacidades). A migração envolve a transformação do banco de dados de um tipo de DBMS para outro. A transformação deve manter (se possível) o aplicativo relacionado ao banco de dados (isto é, todos os programas aplicativos relacionados) intacto. Assim, os níveis conceitual e arquitetural externo do banco de dados devem ser mantidos na transformação. Pode-se desejar que também alguns aspectos do nível interno da arquitetura sejam mantidos. Uma migração de banco de dados grande ou complexa pode ser um projeto complicado e caro (único) por si só, que deve ser levado em consideração na decisão de migrar. Isso ocorre apesar do fato de que podem existir ferramentas para ajudar na migração entre DBMSs específicos. Normalmente, um fornecedor de DBMS fornece ferramentas para ajudar a importar bancos de dados de outros DBMSs populares.

Construir, manter e ajustar

Depois de projetar um banco de dados para um aplicativo, o próximo estágio é construir o banco de dados. Tipicamente, um DBMS de propósito geral apropriado pode ser selecionado para ser usado para este propósito. Um DBMS fornece as interfaces de usuário necessárias para serem usadas pelos administradores de banco de dados para definir as estruturas de dados do aplicativo necessário dentro do respectivo modelo de dados do DBMS. Outras interfaces de usuário são usadas para selecionar os parâmetros de DBMS necessários (como relacionados à segurança, parâmetros de alocação de armazenamento, etc.).

Quando o banco de dados está pronto (todas as suas estruturas de dados e outros componentes necessários são definidos), ele é normalmente preenchido com os dados iniciais do aplicativo (inicialização do banco de dados, que normalmente é um projeto distinto; em muitos casos usando DBMS especializado interfaces que suportam inserção em massa) antes de torná-lo operacional. Em alguns casos, o banco de dados torna-se operacional enquanto está vazio de dados do aplicativo e os dados são acumulados durante sua operação.

Depois que o banco de dados é criado, inicializado e preenchido, ele precisa ser mantido. Vários parâmetros do banco de dados podem precisar ser alterados e o banco de dados pode precisar ser ajustado (tuning) para melhor desempenho; as estruturas de dados do aplicativo podem ser alteradas ou adicionadas, novos programas de aplicativos relacionados podem ser escritos para adicionar à funcionalidade do aplicativo, etc.

Backup e restauração

Às vezes, deseja-se trazer um banco de dados de volta a um estado anterior (por vários motivos, por exemplo, casos em que o banco de dados está corrompido devido a um erro de software ou se foi atualizado com dados incorretos). Para conseguir isso, uma operação de backup é feita ocasionalmente ou continuamente, onde cada estado desejado do banco de dados (ou seja, os valores de seus dados e sua incorporação nas estruturas de dados do banco de dados) é mantido em arquivos de backup dedicados (existem muitas técnicas para fazer isso efetivamente). Quando é decidido por um administrador de banco de dados trazer o banco de dados de volta a esse estado (por exemplo, especificando esse estado em um ponto desejado no tempo em que o banco de dados estava nesse estado), esses arquivos são usados para restaurar esse estado.

Análise estática

Técnicas de análise estática para verificação de software podem ser aplicadas também no cenário de linguagens de consulta. Em particular, a estrutura de interpretação *Abstract foi estendida ao campo de linguagens de consulta para bancos de dados relacionais como uma forma de suportar técnicas de aproximação sólidas. A semântica das linguagens de consulta pode ser ajustada de acordo com as abstrações adequadas do domínio concreto dos dados. A abstração de sistemas de banco de dados relacionais tem muitas aplicações interessantes, em particular, para fins de segurança, como controle de acesso refinado, marca d'água, etc.

Recursos diversos

Outros recursos do DBMS podem incluir:

• Registros de banco de dados – Isso ajuda a manter um histórico das funções executadas.
• Componente gráfico para a produção de gráficos e gráficos, especialmente em um sistema de armazenamento de dados.
• Otimizador de consultas – Realiza otimização de consultas em cada consulta para escolher um eficiente plano de consulta (uma ordem parcial (árvore) das operações) a ser executada para calcular o resultado da consulta. Pode ser específico para um determinado motor de armazenamento.
• Ferramentas ou ganchos para design de banco de dados, programação de aplicativos, manutenção de programas de aplicativos, análise de desempenho e monitoramento de banco de dados, monitoramento de configuração de banco de dados, configuração de hardware DBMS (um banco de dados DBMS e banco de dados relacionados podem abranger computadores, redes e unidades de armazenamento) e mapeamento de banco de dados relacionados (especialmente para um DBMS distribuído), alocação de armazenamento e monitoramento de layout de banco de banco de dados, migração de armazenamento, etc.

Cada vez mais, há pedidos de um único sistema que incorpore todas essas funcionalidades principais na mesma estrutura de construção, teste e implantação para gerenciamento de banco de dados e controle de origem. Tomando emprestado de outros desenvolvimentos na indústria de software, alguns comercializam ofertas como "DevOps para banco de dados".

Design e modelagem

A primeira tarefa de um designer de banco de dados é produzir um modelo de dados conceitual que reflita a estrutura das informações a serem mantidas no banco de dados. Uma abordagem comum para isso é desenvolver um modelo entidade-relacionamento, muitas vezes com o auxílio de ferramentas de desenho. Outra abordagem popular é a Unified Modeling Language. Um modelo de dados bem-sucedido refletirá com precisão o possível estado do mundo externo sendo modelado: por exemplo, se as pessoas puderem ter mais de um número de telefone, isso permitirá que essas informações sejam capturadas. Projetar um bom modelo de dados conceitual requer um bom entendimento do domínio do aplicativo; normalmente envolve fazer perguntas profundas sobre as coisas de interesse para uma organização, como "um cliente também pode ser um fornecedor?", ou "se um produto é vendido com duas formas diferentes de embalagem, são o mesmo produto ou produtos diferentes?", ou "se um avião voa de Nova York para Dubai via Frankfurt, é um voo ou dois (ou talvez até três)?". As respostas a essas perguntas estabelecem definições da terminologia usada para entidades (clientes, produtos, voos, segmentos de voos) e seus relacionamentos e atributos.

Produzir o modelo de dados conceitual às vezes envolve informações de processos de negócios ou a análise do fluxo de trabalho na organização. Isso pode ajudar a estabelecer quais informações são necessárias no banco de dados e quais podem ser omitidas. Por exemplo, pode ajudar ao decidir se o banco de dados precisa conter dados históricos, bem como dados atuais.

Depois de produzir um modelo de dados conceitual que agrade aos usuários, o próximo estágio é traduzi-lo em um esquema que implemente as estruturas de dados relevantes no banco de dados. Esse processo geralmente é chamado de projeto de banco de dados lógico e a saída é um modelo de dados lógico expresso na forma de um esquema. Considerando que o modelo de dados conceitual é (pelo menos em teoria) independente da escolha da tecnologia de banco de dados, o modelo de dados lógico será expresso em termos de um modelo de banco de dados específico suportado pelo DBMS escolhido. (Os termos modelo de dados e modelo de banco de dados geralmente são usados de forma intercambiável, mas neste artigo usamos modelo de dados para o design de um banco de dados específico, e modelo de banco de dados para a notação de modelagem usada para expressar esse design).

O modelo de banco de dados mais popular para bancos de dados de uso geral é o modelo relacional ou, mais precisamente, o modelo relacional representado pela linguagem SQL. O processo de criação de um design de banco de dados lógico usando esse modelo usa uma abordagem metódica conhecida como normalização. O objetivo da normalização é garantir que cada "fato" é registrado apenas em um local, para que inserções, atualizações e exclusões mantenham a consistência automaticamente.

O estágio final do projeto do banco de dados é tomar as decisões que afetam o desempenho, escalabilidade, recuperação, segurança e afins, que dependem do DBMS específico. Isso geralmente é chamado de projeto de banco de dados físico, e a saída é o modelo de dados físico. Um objetivo fundamental durante esta fase é a independência de dados, o que significa que as decisões tomadas para fins de otimização de desempenho devem ser invisíveis para usuários finais e aplicativos. Existem dois tipos de independência de dados: independência de dados físicos e independência de dados lógicos. O projeto físico é orientado principalmente por requisitos de desempenho e requer um bom conhecimento da carga de trabalho esperada e dos padrões de acesso, além de um profundo entendimento dos recursos oferecidos pelo DBMS escolhido.

Outro aspecto do design de banco de dados físico é a segurança. Envolve a definição do controle de acesso aos objetos do banco de dados, bem como a definição dos níveis e métodos de segurança para os próprios dados.

Modelos

Colagem de cinco tipos de modelos de banco de dados

Um modelo de banco de dados é um tipo de modelo de dados que determina a estrutura lógica de um banco de dados e determina fundamentalmente de que maneira os dados podem ser armazenados, organizados e manipulados. O exemplo mais popular de um modelo de banco de dados é o modelo relacional (ou a aproximação SQL de relacional), que usa um formato baseado em tabela.

Modelos de dados lógicos comuns para bancos de dados incluem:

• Bases de dados de navegação
  • Modelo de banco de dados hierárquico
  • Modelo de rede
  • Banco de dados gráfico
• Modelo relacional
• Modelo de Entidade-Relacionamento
  • Modelo aprimorado de entidade-relação
• Modelo de objeto
• Modelo de documento
• Modelo de entidade-atributo-valor
• Xeque de estrelas

Um banco de dados objeto-relacional combina as duas estruturas relacionadas.

Os modelos de dados físicos incluem:

• Índice invertido
• Arquivo plano

Outros modelos incluem:

• Modelo multidimensional
• Modelo de matriz
• Modelo multivalor

Os modelos especializados são otimizados para determinados tipos de dados:

• banco de dados XML
• Modelo semântico
• Loja de conteúdo
• Loja de eventos
• Modelo de série de tempo

Visões externas, conceituais e internas

Vista tradicional dos dados

Um sistema de gerenciamento de banco de dados fornece três visualizações dos dados do banco de dados:

• O nível externo define como cada grupo de usuários finais vê a organização de dados no banco de dados. Um único banco de dados pode ter qualquer número de visualizações no nível externo.
• O nível conceitual (ou nível lógico) unifica as várias visões externas numa visão global compatível. Ele fornece a síntese de todas as visões externas. Ele está fora do escopo dos vários usuários finais de banco de dados, e é um pouco de interesse para desenvolvedores de aplicativos de banco de dados e administradores de banco de dados.
• O nível interno (ou nível físico) é a organização interna de dados dentro de um DBMS. Trata-se de custos, desempenho, escalabilidade e outros assuntos operacionais. Ele lida com o layout de armazenamento dos dados, usando estruturas de armazenamento, como índices para melhorar o desempenho. Ocasionalmente, ele armazena dados de visualizações individuais (visão materializada), computada a partir de dados genéricos, se a justificativa de desempenho existe para tal redundância. Ele equilibra todos os requisitos de desempenho das visualizações externas, possivelmente conflitantes, na tentativa de otimizar o desempenho global em todas as atividades.

Embora normalmente haja apenas uma visão conceitual e interna dos dados, pode haver várias visões externas diferentes. Isso permite que os usuários vejam as informações do banco de dados de uma maneira mais relacionada aos negócios, em vez de um ponto de vista técnico e de processamento. Por exemplo, um departamento financeiro de uma empresa precisa dos detalhes de pagamento de todos os funcionários como parte das despesas da empresa, mas não precisa de detalhes sobre funcionários que sejam de interesse do departamento de recursos humanos. Assim, diferentes departamentos precisam de diferentes visualizações do banco de dados da empresa.

A arquitetura de banco de dados de três níveis está relacionada ao conceito de independência de dados, que foi uma das principais forças motrizes iniciais do modelo relacional. A ideia é que as alterações feitas em um determinado nível não afetem a exibição em um nível superior. Por exemplo, as mudanças no nível interno não afetam os programas aplicativos escritos usando interfaces de nível conceitual, o que reduz o impacto de fazer mudanças físicas para melhorar o desempenho.

A visão conceitual fornece um nível de indireção entre interno e externo. Por um lado, fornece uma visão comum do banco de dados, independente de diferentes estruturas de visão externa e, por outro lado, abstrai detalhes de como os dados são armazenados ou gerenciados (nível interno). Em princípio, cada nível, e até mesmo cada visão externa, pode ser apresentado por um modelo de dados diferente. Na prática, geralmente um determinado SGBD usa o mesmo modelo de dados para os níveis externo e conceitual (por exemplo, modelo relacional). O nível interno, que fica oculto dentro do SGBD e depende de sua implementação, requer um nível de detalhamento diferenciado e utiliza tipos próprios de estrutura de dados.

Pesquisa

A tecnologia de banco de dados tem sido um tópico de pesquisa ativo desde a década de 1960, tanto na academia quanto nos grupos de pesquisa e desenvolvimento de empresas (por exemplo, IBM Research). A atividade de pesquisa inclui teoria e desenvolvimento de protótipos. Tópicos de pesquisa notáveis incluíram modelos, o conceito de transação atômica, técnicas de controle de simultaneidade relacionadas, linguagens de consulta e métodos de otimização de consulta, RAID e muito mais.

A área de pesquisa de banco de dados tem várias revistas acadêmicas dedicadas (por exemplo, ACM Transactions on Database Systems-TODS, Data and Knowledge Engineering-DKE) e conferências anuais (por exemplo,, ACM SIGMOD, ACM PODS, VLDB, IEEE ICDE).