sexta-feira, setembro 29, 2006

Deus Ex Machina

A expressão latina Deus ex machina significa literalmente "Deus surgido da máquina". A expressão é uma tradução do grego "ἀπὸ μηχανῆς θεός" (apó mechanés theós).

Sua origem encontra-se no teatro grego e refere-se a uma inesperada, artificial ou improvável personagem, artefato ou evento introduzido repentinamente em um trabalho de ficção ou drama para resolver uma situação ou desemaranhar uma trama. Este dispositivo é na verdade uma invenção grega. No teatro grego havia muitas peças que terminavam com um deus sendo literalmente baixado por um guindaste até o local da encenação. Esse deus então amarrava todas as pontas soltas da história.

A expressão é usada hoje para indicar um desenvolvimento de uma história que não leva em consideração sua lógica interna e é tão inverossímil que permite ao autor terminá-la com uma situação improvável porém mais palatável. Em termos modernos Deus ex machina também pode descrever uma pessoa ou uma coisa que de repente aparece e resolve uma dificuldade aparentemente insolúvel. Quando em uma narrativa isto pode parecer insatisfatório, na vida real este tipo de figura pode ser bem-vindo e heróico.

A noção de Deus ex machina também pode ser aplicada a uma revelação dentro de uma história vivida por um personagem, que envolva realizações pessoais complicadas, às vezes perigosas ou mundanas e, porventura, seqüência de eventos aparentemente não relacionados que conduzem ao ponto da história em que tudo é conectados por algum conceito profundo. Essa intervenção inesperada e oportuna visa a dar sentido à história no lugar de um evento mais concreto na trama.

A tragédia grega de Eurípides era notória em usar este dispositivo na trama.

quinta-feira, setembro 21, 2006

Project Management Body of Knowledge

Origem: Wikipédia, a enciclopédia livre.

Project Management Body of Knowledge (PMBOK) é um padrão de Gerência de Projetos desenvolvido pelo Project Management Institute (PMI). O PMBOK é largamente aceito por diversas indústrias como sendo o padrão de facto de Gerência de Projetos.

Índice

[esconder]

Propósito do PMBOK

O propósito principal do PMBOK é identificar o subconjunto de conhecimentos sobre a profissão que são consenso, sendo aplicáveis para a maior parte dos projetos na maior parte do tempo. Outro propósito é prover um vocabulário único para a profissão, padronizando seus termos. Também é usado como referência básica para os exames de certificação do PMI.

Estruturação do PMBOK (edição 2000)

É considerado um guia teórico para o desenvolvimento de projetos práticos, serve como orientador para o estudo de metodologias para projetos.

Seção I : Estruturação da Gerência de Projetos

Provê uma estrutura básica para o entendimento de Gerência de Projetos

Seção II : As Áreas de Conhecimento da Gerência de Projetos

  • Gerência da integração do projeto – descreve os processos requeridos para certificar-se que os vários elementos do projeto estão propriamente coordenados. Consiste em:
    • Desenvolvimento do plano do projeto
    • Execução do plano do projeto
    • Controle integrado de alterações
    • Solução de conflitos entre objetivos e alternativas concorrentes.
  • Gerência do escopo do projeto – descreve os processos requeridos para garantir que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho requerido, para completar o processo com sucesso. Consiste em:
    • Iniciação (....)
    • Definição do escopo
    • Verificação de escopo
    • Controle de alterações de escopo
  • Gerência do tempo de projeto – descreve os processos requeridos para garantir que o projeto seja completado dentro do prazo. Consiste em:
    • Definição de atividades
    • Sequenciamento de atividades
    • Estimativa de duração das atividades
    • Desenvolvimento de cronograma
    • Controle de cronograma
  • Gerência do custo do projeto – descreve os processos requeridos para que o projeto seja completado dentro do orçamento aprovado. Consiste em:
    • Planejamento de recursos
    • Estimativa de custos
    • Orçamento de custos
    • Controle de custos
  • Gerência da qualidade do projeto – descreve os processos requeridos para garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Consiste em:
    • Planejamento de qualidade
    • Garantia de qualidade
    • Controle de qualidade
  • Gerência dos recursos humanos do Projeto – descreve os processos requeridos para fazer o uso mais efetivo das pessoas envolvidas no projeto. Consiste em:
    • Planejamento organizacional
    • Aquisição de equipe (staff)
    • Desenvolvimento de equipe
  • Gerência das comunicações do projeto – descreve os processos requeridos para garantir rápida e adequada geração, coleção, disseminação, armazenamento e disposição final das informações do projeto. Consiste em:
    • Planejamento de comunicações
    • Distribuição de informações
    • Relatórios de desempenho
    • Encerramento administrativo
  • Gerência dos riscos do projeto – descreve os processos relacionados a identificar, analisar e responder aos riscos do projeto, avaliando a probabilidade de ocorrência e a gravidades das conseqüências. Consiste em:
    • Planejamento do gerenciamento de riscos
    • Identificação de riscos
    • Análise quantitativa de riscos
    • Monitoramento e controle dos riscos
  • Gerência das aquisições do projeto – descreve os processos requeridos para adquirir bens e serviços de fora da organização “dona” do projeto. Consiste em:
    • Planejamento das aquisições
    • Planejamento das solicitações
    • Seleção dos fornecedores
    • Administração do Contrato
    • Encerramento do Contrato
    • iniciar progamas do prototipo pra inclusão de novos projetos

Controvérsia

Embora o PMBOK seja considerado um padrão de facto em diversas indústrias, ele também tem seus críticos. A maior fonte de críticas vem da controvérsia entre os seguidores do caminho crítico vs. os seguidores da cadeia crítica.

Outros consideram o método agile Scrum como sendo uma alternativa útil.

Ver também: ISO 10006, PRINCE2.

Referências

Pedro Porto

quarta-feira, setembro 20, 2006

Gerência de projetos

Origem: Wikipédia, a enciclopédia livre.

Gerência de Projetos (ou Gestão de Projetos) é a aplicação de conhecimentos, habilidades e técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos pré-definidos. O conhecimento e as práticas da gerência de projetos são melhores descritos em termos de seus processos componentes.

Esses processos podem ser classificados em cinco grupos de processo (iniciação, planejamento, execução, controle e encerramento) e nove áreas de conhecimento (gerência de integração de projetos, gerência de escopo de projetos, gerência de tempo de projetos, gerência de custo de projetos, gerência de qualidade de projetos, gerência de recursos humanos de projetos, gerência de comunicações de projetos, gerência de riscos de projetos e gerência de aquisições de projetos).

Reduzida à sua forma mais simples, a gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto necessário durante o ciclo de vida do projeto. O risco de fracasso aumenta de acordo com a presença de incerteza durante todos os estágios do projeto. Um ponto-de-vista alternativo diz que gerenciamento de projetos é a disciplina de definir e alcançar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço, etc).

A gerência de projetos é frequentemente a responsabilidade de um indivíduo intitulado gerente de projeto. Idealmente, esse indivíduo raramente participa diretamente nas atividades que produzem o resultado final. Ao invés disso, o gerente de projeto trabalha para manter o progresso e a interação mútua progressiva dos diversos participantes do empreendimento, de modo a reduzir o risco de fracasso do projeto.

Abordagens

Na indústria de informática, geralmente há dois tipos de abordagens comumente utilizadas no gerenciamento de projetos. As abordagens do tipo "tradicional" identificam uma sequência de passos a serem completados. Essas abordagens contrastam com a abordagem conhecida como desenvolvimento ágil de software, em que o projeto é visto como um conjunto de pequenas tarefas, ao invés de um processo completo. O objetivo desta abordagem é reduzir ao mínimo possível o overhead. Essa abordagem é bastante controversa, especialmente em projetos muito complexos. Mesmo assim, tem conquistado adeptos em números crescentes.

Nas últimas décadas, emergiram uma série de abordagens na indústria em geral. Dentre essas abordagens se destaca a abordagem do PMBOK, que tem se tornado um padrão de facto em diversas indústrias.

Abordagem tradicional

Na abordagem tradicional, distinguimos cinco estágios no desenvolvimento de um projeto:

  • Iniciação de projeto
  • Planejamento de projeto
  • Produção de projeto
  • Monitoramento de projeto
  • Fechamento (conclusão) de projeto

Nem todos os projetos vão seguir todos estes estágios, já que projetos podem ser encerrados antes de sua conclusão. Alguns projetos talvez não tenham planejamento ou monitoramento. Alguns projetos passarão pelos estágios 2, 3 e 4 múltiplas vezes.

O projeto ou empreendimento visa a satisfação de uma necessidade ou oportunidade, definida no texto acima como fase inicial na qual existem muitas áreas e/ ou pessoas envolvidas. Em geral sempre existe mais que uma solução ou alternativas para atender às mesmas necessidades. A técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas. A primeira de baixo custo que atende as necessidades mínimas para ser funcional. A segunda tenta atender a maior parte das as exigências das diversas áreas envolvidas no escopo que resulta num projeto com custo muito maior e pouco competitivo. A partir de ambas alternativas é desenvolvida uma solução intermediária entre ambas das alternativas, que atende uma boa parte das exigências com um custo competitivo.

Vários setores utilizam variações destes estágios. Por exemplo, na construção civil, os projetos tipicamente progridem de estágios como Pré-planejamento para Design Conceitual, Design esquemático, Design de desenvolvimento, construção de desenhos (ou documentos de contrato), e administração de construção. Embora os nomes difiram de indústria para indústria, os estágios reais tipicamente seguem os passos comuns à resolução de problemas (problem solving): definir o problema, balancear opções, escolher um caminho, implementação e avaliação.

O gerenciamento de projetos tenta adquirir controle sobre quatro variáveis:

  • tempo
  • custo
  • qualidade
  • escopo

Três dessas variáveis podem ser dadas por clientes externos ou internos. O(s) valor(es) das variáveis remanescentes está/estão a cargo do gerente do projeto, idealmente baseado em sólidas técnicas de estimativa. Os resultados finais devem ser acordados em um processo de negociação entre a gerência do projeto e o cliente. Geralmente, os valores em termos de tempo, custo, qualidade e escopo são definidos por contrato.

Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas, dentre as quais se destacam:

Desenvolvimento ágil de software

O desenvolvimento ágil de software reune uma série de metodologias de baixo overhead. Reconhecem que software é algo difícil de se controlar. Essas metodologias minimizam riscos garantindo que os engenheiros de software foquem em unidades menores de trabalho.

Os métodos ágeis diferenciam-se de outras metodologias mais "pesadas" (como por exemplo, o Modelo Cascata) na ênfase que dão a valores e princípios, ao invés de processos.

Ciclos típicos são de uma semana ou um mês, e no fim de cada ciclo há uma reavaliação das prioridades do projeto - característica que ele compartilha com metodologias de desenvolvimento iterativas, e com a maioria das teorias modernas de gerenciamento de projetos.

Project Management Body of Knowledge

A abordagem do PMBOK não é restrita ao desenvolvimento de sistemas, sendo largamente utilizada em diversas indústrias (notadamente nas indústrias ligadas à construção civil). De acordo com esta abordagem, a gerência de projetos aborda as seguintes áreas de conhecimento:

Padrões de Gerência de projetos

Ao longo do tempo, houve diversas tentativas para desenvolver padrões (standards) internacionais de gerência de projetos. Dentre elas, destacam-se:

segunda-feira, setembro 18, 2006

banco de dados

fonte: wikipedia

Bancos de dados, (ou bases de dados), são conjuntos de dados com uma estrutura regular que organizam informação. Um banco de dados normalmente agrupa informações utilizadas para um mesmo fim.

Um banco de dados é usualmente mantido e acessado por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou extendida. Muitas vezes o termo banco de dados é usado como sinônimo de SGDB.

O modelo de dados mais adotado hoje em dia ó o modelo relacional, onde as estruturas têm a forma de tabelas, compostas por linhas e colunas.


Definições

O termo banco de dados foi criado inicialmente pela comunidade de computação, para indicar coleções organizadas de dados armazenados em computadores digitais, porém o termo é atualmente usado para indicar tanto bancos de dados digitais como bancos de dados disponíveis de outra forma. No Brasil, é mais comum usar o termo base de dados quando se mencionam outros tipos de bancos de dados senão aqueles armazenados em um computador e gerenciados por um SGBD.

Aceitando uma abordagem mais técnica, um banco de dados é uma coleção de registros salvos em um computador em um modo sistemático, de forma que um programa de computador possa consultá-lo para responder questões.

Normalmente um registro está associado a um conceito completo e é dividido em campos, ou atributos, que dão valores a propriedades desses conceitos. Possivelmente alguns registros podem apontar diretamente ou referenciar indiretamente outros registros, o que faz parte da caracterização do modelo adotado pelo banco de dados.

A descrição de quais são os tipos de registros existentes em um banco de dados e ainda quais são os campos de cada registro é conhecida como esquema do banco de dados.

Estritamente falado, o termo banco de dados deve ser aplicado apenas aos dados, enquanto o termo sistema gerenciador de bancos de dados deve ser aplicado ao software com a capacidade de manipular bancos de dados de forma geral. Porém, é comum misturar os dois conceitos.


Modelos de Dados dos Bancos de Dados

A maneira mais prática de classificar bancos de dados é de acordo com a forma que seus dados são vistos pelo usuário, ou seja, seu modelo de dados. Diversos modelos foram e vem sendo utilizados ao longo da história, com vantagens para um ou para outro por determinados períodos.

Atualmente, a classificação mais comum citaria 4 modelos básicos:

Porém, outros modelos podem ser citados, incluindo:

Historicamente, o modelo de bancos de dados em rede foi implementado primeiro; porém o primeiro produto comercial usava o modelo de bancos de dados hierárquico, que nada mais é que uma versão simplificada do primeiro. Ambos os modelos foram resultado da busca de usar mais efetivamente os novos dispositivos de memória secundária de acesso direto, que substituiam os cartões perfurados e as fitas magnéticas. Isso aconteceu na década de 1960.

Em 1970 E.F. Codd propôs o modelo de bancos de dados relacional que surgiu e ganhou destaque teórico imediato. Porém, a implementação do modelo exigia pesquisas e só na década de 1980 eles iam começar a ganhar o mercado, se estabilizando totalmente como líder do mercado a partir da década de 1990.

Podemos identificar o aparecimento do que pode ser chamado modelo plano (tabular) para fins mais diretos e simples. Nesse caso, os dados estão simplesmente arranjados em uma única matriz bi-dimensional de elementos de dados na qual todos os membros de uma dada coluna possuem valores de mesmo tipo, e todos os membros de uma linha estão relacionados entre si. Seu melhor exemplo são as planilhas eletrônicas.

O único modelo que foi extensamente tratado de forma teórica foi o modelo relacional. Os modelos pré-existentes foram fruto de implementações, enquanto os modelos subsequentes, como o modelo orientado a objetos, não apresentavam um campo tão rico para novas teorias, mas apresentam grandes desafios para a implementação eficiente das operações necessárias.

Modelos Navigacionais

No modelo em redes, os dados são organizados em registros, que são coleções de itens de dados, e podem ser armazenados ou recuperados de um banco de dados de forma conjunta. É possível que um registro possua uma estrutura interna, e elementos (itens de dados) contínuos podem ser agrupados, que também podem formar outros grupos. Dessa forma, um registro pode ter uma construção hierárquica. Os registros com a mesma estrutura formam um tipo de registro, que podem ser considerados equivalentes a uma tabela fora da primeira forma normal, ou ainda a um objeto complexo. Os tipos de registro possíveis em um banco de dados são definidos em seu esquema.

A principal característica do modelo em redes é permitir a navegação entre os registros, por meio de Conjuntos de Dados, que possui um registro proprietário e registros membros, implementados por meio de ponteiros. Basicamente, registros equivalem a entidades e conjuntos de dados equivalem a descrição dos relacionamentos. Como não há limitação na topologia criada pelos registros e conjuntos, o modelo permite a criação de redes, de onde ganhou o nome.

Um subconjunto particular do modelo de rede, o modelo hierárquico, limita os relacionamentos a uma estrutura de árvore, ao contrário da estrutura aplicada pelo modelo de rede completo.

O modelo em redes foi definido formalmente em 1971, pela Conference on Data Systems Languages (CODASYL), de onde ganhou seu outro nome: modelo CODASYL.

Modelo Relacional

O modelo relacional é uma teoria matemática desenvolvida por Edgar Frank Codd para descrever como as bases de dados devem funcionar. Embora esta teoria seja a base para o software de bases de dados relacionais, muito poucos sistemas de gestão de bases de dados seguem o modelo de forma restrita, e todos têm funcionalidades que violam a teoria, desta forma variando a complexidade e o poder. A discussão se esses bancos de dados merecem ser chamados de relacional ficou esgotada com tempo, com a evolução dos bancos existentes.

De acordo com a arquitetura ANSI / SPARC em três níveis, os Bancos de dados relacionais consistem de três componentes:

  • uma coleção de estruturas de dados, formalmente chamadas de relações, ou informalmente tabelas, compondo o nível conceitual;
  • uma coleção dos operadores, a álgebra e o cálculo relacionais, que cosntituem a base da linguagem SQL; e
  • uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de dados e de alterações de estados. As restrições de integridade podem ser de quatro tipos:
    • domínio (também conhecidas como type),
    • atributo,
    • relvar e
    • restrições de base de dados.

Diferentemente dos modelos hierárquico e de rede, não existem quaisquer apontadores, de acordo com o Princípio de Informação: toda informação tem de ser representada como dados; qualquer tipo de atributo representa relações entre conjuntos de dados.

Diferentemente dos bancos de dados em rede, nos bancos de dados relacionais os relacionamentos entre as tabelas não são codificados explicitamente na sua definição. Em vez disso, se fazem implicitamente pela presença de atributos chave. As bases de dados relacionais permitem aos utilizadores (incluindo programadores) escreverem consultas (queries), reorganizando e utilizando os dados de forma flexível e não necessariamente antecipada pelos projetistas originais. Esta flexibilidade é especialmente importante em bases de dados que podem ser utilizadas durante décadas, tornando as bases de dados relacionais muito populares no meio empresarial.

Um dos pontos fortes do modelo relacional de banco de dados é a possibilidade de definição de um conjunto de restrições de integridade. Estas definem os conjuntos de estados e mudanças de estado consistentes do banco de dados, determinando os valores que podem e os que não podem ser armazenados.

Bancos de Dados Orientados a Objetos

Na década de 90, o modelo baseado na orientação a objeto foi aplicado também aos bancos de dados, criando um novo modelo de programação conhecido como bancos de dados orientados a objeto. Os objetos são valores definidos segundo classes, ou tipos de dados complexos, com seus próprios operadores (métodos).

Com o passar do tempo, os sistemas gestores de bancos de dados orientados a objeto e os bancos de dados relacionais baseados na linguagem SQL se aproximaram. Muitos sistemas orientados a objeto são implementados sobre bancos de dados relacionais baseados em linguagem SQL.

O resultado comercial, porém, foi pequeno. Atualmente vários princípios de orientação a objeto foram adotados pelos bancos de dados relacionais, gerando o que pode ser chamado de banco de dados relacional extendido.

Bancos de Dados Semi-Estruturados

Mais recentemente ainda, apareceram os bancos de dados semi-estruturados, onde os dados são guardados e manipulados na forma de XML (ao contrário da forma de tabelas). Novamente, os produtores de bancos de dados relacionais responderam estendendo suas capacidades para tratar dados semi-estruturados.

Índices

Todos os tipos de bancos de dados podem ter seu desempenho melhorado pelo uso de índices. O tipo mais comum de índice é uma lista ordenada dos valores de uma coluna de uma tabela, contendo ponteiros para as linhas associadas a cada valor. Um índice permite que o conjunto das linhas de uma tabela que satisfazem determinado critério sejam localizadas rapidamente. Há vários métodos de indexação utilizados comumente, como árvores B, hashes e listas encadeadas.

Utilização

Os bancos de dados são utilizados em muitas aplicações, abrangendo praticamente todo o campo dos programas de computador. Os bancos de dados são o método de armazenamento preferencial para aplicações multiusuário, nas quais é necessário haver coordenação entre vários usuários. Entretanto, são convenientes também para indivíduos, e muitos programas de correio eletrônico e organizadores pessoais baseiam-se em tecnologias padronizadas de bancos de dados.

Um banco de dados é um conjunto de informações com uma estrutura regular. Um banco de dados é normalmente, mas não necessariamente, armazenado em algum formato de máquina lido pelo computador. Há uma grande variedade de bancos de dados, desde simples tabelas armazenadas em um único arquivo até gigantescos bancos de dados com muitos milhões de registros, armazenados em salas cheias de discos rígidos.

Bancos de dados caracteristicamente modernos são desenvolvidos desde os anos da década de 1960. Um pioneiro nesse trabalho foi Charles Bachman.

Apresentação dos Dados

A apresentação dos dados pode ser semelhante à de uma planilha eletrônica, porém os sistemas de gestão de banco de dados possuem características especiais para o armazenamento, classificação e recuperação dos dados.

Direitos de propriedade

A Diretiva CE de Bases de Dados (EU Database Directive), estabelecida pelo Parlamento Europeu em de 11 de março de 1996, fixa os termos de proteção jurídica a bancos de dados, em particular os direitos de propriedade sobre a base.

Mesmo para os paises que não a adotam explicitamente, ou não possuam normas mais específicas sobre o tema, como o Brasil, tem sido a principal referência.

Modelos de base de dados

O modelo plano (ou tabular) consiste de matrizes simples, bidimensionais, compostas por elementos de dados: inteiros, números reais, etc. Este modelo plano é a base das planilhas eletrônicas.

O modelo em rede permite que várias tabelas sejam usadas simultaneamente através do uso de apontadores (ou referências). Algumas colunas contêm apontadores para outras tabelas ao invés de dados. Assim, as tabelas são ligadas por referências, o que pode ser visto como uma rede. Uma variação particular deste modelo em rede, o modelo hierárquico, limita as relações a uma estrutura semelhante a uma árvore (hierarquia - tronco, galhos), ao invés do modelo mais geral direcionado por grafos.

Bases de dados relacionais consistem, mas de três componentes: uma coleção de estruturas de dados, nomeadamente relações, ou informalmente tabelas; uma coleção dos operadores, a álgebra e o cálculo relacionais; e uma coleção de restrições da integridade, definindo o conjunto consistente de estados de base de dados e de alterações de estados. As restrições de integridade podem ser de quatro tipos: domínio (também conhecidas como type), atributo, relvar e restrições de base de dados.

Diferentemente dos modelos hierárquico e de rede, não existem quaisquer apontadores, de acordo com o Princípio de Informação: toda informação tem de ser representada como dados; qualquer tipo de atributo representa relações entre conjuntos de dados. As bases de dados relacionais permitem aos utilizadores (incluindo programadores) escreverem consultas (queries) que não foram antecipadas por quem projetou a base de dados. Como resultado, bases de dados relacionais podem ser utilizadas por várias aplicações em formas que os projetistas originais não previram, o que é especialmente importante em bases de dados que podem ser utilizadas durante décadas. Isto tem tornado as bases de dados relacionais muito populares no meio empresarial.

O modelo relacional é uma teoria matemática desenvolvida por Ted Codd para descrever como as bases de dados devem funcionar. Embora esta teoria seja a base para o software de bases de dados relacionais, muito poucos sistemas de gestão de bases de dados seguem o modelo de forma restrita e todos têm funcionalidades que violam a teoria, desta forma variando a complexidade e o poder. A discussão se esses bancos de dados merecem ser chamados de relacional ficou esgotada com tempo, com a evolução dos bancos existente.

Aplicações de bancos de dados

Bancos de dados são usados em muitas aplicações, enquanto atravessando virtualmente a gama inteira de software de computador. Bancos de dados são o método preferido de armazenamento para aplicações multiusuárias grandes donde coordenação entre muitos usuários é necessária. Até mesmo usuários individuais os acham conveniente, entretanto, e muitos programas de correio eletrônico e os organizadores pessoais estão baseado em tecnologia de banco de dados standard.

Aplicativo de Banco de Dados

Um Aplicativo de Banco de dados é um tipo de software exclusivo para gerenciar um banco de dados. Aplicativos de banco de dados abragem uma vasta variedade de necessidades e objectivos, de pequenas ferramentas como uma agenda, até complexos sistemas empresariais para desempenhar tarefas como a contabilidade.

O termo "Aplicativo de Banco de dados" usualmente se refere a softwares que oferecem uma interface para o banco de dados. O software que gerencia os dados é geralmente chamado de sistema gerenciador de banco de dados (SGBD) ou (se for embarcado) de "database engine".

Exemplos de aplicativos de banco de dados são Microsoft Visual FoxPro, Microsoft Access, dBASE, FileMaker , (em certa medida) HyperCard, MySQL, PostgreSQL, Microsoft SQL Server e Oracle.

Em Março, 2004, AMR Research (como citado em um artigo da CNET News.com listado na secção de "Referências") previu que aplicações de banco de dados de código aberto seriam amplamente aceitas em 2006.

Transação

É um conjunto de procedimentos que é executado num banco de dados, que para o usuário é visto como uma única ação. A integridade de uma transação depende de 4 propriedades, conhecidas como ACID.

  • Atomicidade
    • Uma transação não pode ser executada pela metade, isto é, ou se executa ela por inteiro, ou se retorna para o estado anterior a transação, onde nada foi executado. Também chamado de Princípio do "Tudo ou Nada".
  • Consistência:Consistência de dados é quando não há informações conflitantes no banco.
    • Uma transação só executa se o estado do Banco de Dados permanecer consistente após seu fim.
  • Isolamento
    • Sua necessidade surge em execuções concorrentes, a intercalação das diversas transações que ocorrem simultaneamente, não podem ser intercaladas de forma a gerar um estado inconsistente.
  • Durabilidade
    • Quando ocorre falha no banco de dados, apos a execução com sucesso de uma transação, a durabilidade garante por algum mecanismo a recuperação das informações perdidas.

Na prática, alguns SGBDs relaxam na implementação destas propriedades buscando desempenho.

Controle de concorrência é um método usado para garantir que as transações são executadas de uma forma segura e segue as regras ACID. Os SGBD devem ser capazes de assegurar que nenhuma ação de transações completadas com sucesso (committed transactions) seja perdida ao desfazer transações abortadas (rollback). Uma transação é uma unidade que preserva consistência. Requeremos, portanto, que qualquer escalonamento produzido ao se processar um conjunto de transações concorrentemente seja computacionalmente equivalente a um escalonamento produzindo executando essas transações serialmente em alguma ordem. Diz-se que que um sistema que garante esta propriedade assegura a seriabilidade.

Funções internas comuns em BDs