Exemplo de Diagrama de Classes da UML

Diagrama de Objetos

Mostram um conjunto de objetos e seus relacionamentos em um ponto no tempo, contém objetos e vínculos e são usados para fazer a modelagem da visão de projeto estática de um sistema a partir da perspectiva de instâncias reais ou prototípicas.

Essa visão atende principalmente aos requisitos funcionais do sistema, ou seja, os serviços que o sistema deverá proporcionar aos seus usuários finais.

Os diagramas de objetos só podem ser usados de uma única maneira: para fazer a modelagem de estruturas dos objetos. Ao se utilizar estes diagramas pode-se expor significativamente apenas conjuntos interessantes de objetos concretos ou prototípicos.

Ao se fazer a modelagem de uma estrutura de objetos deve-se:

1. identificar o mecanismo cuja modelagem você deseja fazer;


2. para cada um destes mecanismos, identificar classes, interfaces e outros elementos que participam dessa colaboração e seus relacionamentos;


3. congelar o cenário em determinado momento e representar cada objeto que participa do mecanismo;


4. expor o estado e os valores dos atributos de cada um desses objetos para a compreensão do cenário; e


5. expor os vínculos existentes entre esses objetos, representando instâncias de associações entre eles.

Diagrama de Classes

1.0 - Introdução

Na modelagem de sistemas orientados a objetos, são os diagramas encontrados com maior freqüência e mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos.

Os diagramas de classes costumam conter os seguintes itens: Classes, Interfaces, Colaborações, Relacionamentos de dependências, Generalizações e Associação e também pode conter Pacotes ou Subsistemas utilizados para agrupar elementos do seu novo modelo em um conjunto maior.
Basicamente, os diagramas de classes são utilizados para fazer a modelagem da visão estática de um sistema, ou seja, oferecer suporte para os requisitos funcionais do sistema, os serviços que este fornecer aos usuários finais.

Ao se fazer a modelagem estática de um sistema o diagrama de classes será usado de três formas: para fazer a modelagem do vocabulário de um sistema; para fazer a modelagem de colaborações simples e para fazer a modelagem do esquema lógico de um banco de dados.

Na modelagem do vocabulário do sistema, o diagrama de classes visa definir os limites do sistema, o que envolve uma decisão a respeito de quais abstrações fazem parte do sistema e quais estão fora do limite representando essas abstrações e suas responsabilidades.

Uma colaboração é um conjunto de classes, interfaces e outros elementos que funcionam em conjunto proporcionando algum comportamento cooperativo, maior que a soma de todos os elementos e podem ser representados pelo diagrama de classes.

Os diagramas de classes também podem ser usados para fazer a modelagem de esquemas para banco de dados relacionais ou orientado a objetos onde se deseja armazenar informações persistentes, ou seja, que podem ser armazenadas para serem recuperadas posteriormente.

Enquanto os diagramas de Entidade-Relacionamentos clássicos têm seu foco apenas nos dados já os diagramas de classes vão um pouco além permitindo ainda a modelagem de comportamentos.

2.0 - Perspectivas:

Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:

1. Conceitual (exemplo)
   Representa os conceitos do domínio em estudo.
   Perspectiva destinada ao cliente.
   


2. Especificação (exemplo)
   Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados.
   Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.
   


3. Implementação - a mais utilizada de todas (exemplo)
   Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc.
   Perspectiva destinada ao time de desenvolvimento.

Diagramas da UML

Um diagrama é uma apresentação gráfica de um conjunto de elementos (classes, interfaces, colaborações, componentes, nós etc) e são usados para visualizar o sistema sob diferentes perspectivas.

A UML define um número de diagramas que permite dirigir o foco para aspectos diferentes do sistema de maneira independente. Se bem usados, os diagramas facilitam a compreensão do sistema que está sendo desenvolvido.

A UML define 9 tipos de diagramas, no entanto, não existe uma limitação pois podem ser criados novos diagramas com a finalidade de visualizar os elementos da UML de maneira diferente.

As partes estáticas de um sistema são visualizadas através dos diagramas de classes, objetos, componentes e implantação, já as partes dinâmicas podem ser representadas pelos diagramas de caso de uso, interação (seqüência e colaboração), estados e atividades.

Os diagramas estruturais existem para visualizar, especificar, construir e documentar os aspectos estáticos de um sistema, ou seja, a representação de seu esqueleto e estruturas relativamente estáveis. Os aspectos estáticos de um sistema de software abrangem a existência e a colocação de itens como classes, interfaces, colaborações, componentes e nós, enquanto que os diagramas comportamentais são usados para visualizar, especificar, construir e documentar os aspectos dinâmicos de um sistema que é a representação das partes que sofrem alterações, como por exemplo o fluxo de mensagens ao longo do tempo e a movimentação física de componentes em uma rede.

Tipos de diagramas:

Estruturais/Estáticos:

1. Diagramas de Classes
2. Diagramas de Pacotes
   

Comportamentais/Dinâmicos:

1. Diagramas de Use Cases
2. Diagramas de Interação
3. Diagramas de Sequência
4. Diagramas de Colaboração
5. Diagramas de Estado (Statechart)
6. Diagramas de Atividade

Databases - Home

Site da Microsoft sobre Pesquisa e Desenvolvimento na área de Banco de Dados.

Databases - Home

Fenômeno - Elemento - Interação

Um fenômeno da realidade pode ser:

1. um Elemento (Objeto, Entidade); ou
2. uma Interação (Ligação ou Relacionamento) entre Elementos.

Um Elemento (Objeto, Entidade) do mundo real apresenta algumas características básicas:

1. estado: é o próprio elemento num determinado momento do tempo;
2. estrutura ou forma: é uma abstração dos estados que ele assume ao longo do tempo;
3. localização: um elemento existem em um local e em um instante do tempo;
4. impenetrabilidade: dois elementos distintos não ocupam o mesmo local no mesmo instante do tempo, constituindo a origem do espaço;
5. interação: a característica acima propicia a existência de interações ente os elementos;
6. comportamento (mudança de estado): as interações entre elementos provoca a mudança de seus estados o que chamamos de comportamento do elemento;
7. irreversibilidade: as mudanças de estado são irreversíveis (entrópicas), constituindo a origem do tempo; e
8. incerteza: as mudanças são incertas (não determinísticas), constituindo um dos fundamentos da existência.

Regra

Uma Regra formaliza a ligação de estado de um determinado conjunto de fenômenos (causa) a outro estado do mesmo conjunto de fenômenos (efeito).

Uma Regra especifica uma restrições as possíveis mudanças de estado dos fenômenos da natureza.

Regra é uma Lei da Natureza percebida ou estabelecida por elementos cognitivos.

Regra é uma agregação de Fatos Associativos (Proposições ou Argumentos). Onde um ou mais Fatos Causadores (Causa) estão ligados com um Fato Efeito (Efeito).

Outras definições de regra em outros domínios (contextos):

1. Regra em metodologia pode ser um conjunto de coordenadas de funcionamento de um determinado sistema para fins de organização, ou seja para manter a ordem do mesmo.


2. Regra pode ser um conjunto de leis formais de prescrições e proibições, que expõem os principais requisitos quanto à atitude do indivíduo em uma sociedade.

e-Reality - Encyclopedia: Lei da Natureza

A palavra "Lei" vem do verbo "ligare" (que significa "aquilo que liga") ou "legere" (que significa "aquilo que se lê").

Uma Lei da Natureza é portando aquilo que liga um estado de um determinado conjunto de fenômenos (causa) a outro estado do mesmo conjunto de fenômenos (efeito).

Uma Lei da Natureza pode ser definida através de uma Regra, Teoria, Modelo, ...

Uma Lei da Natureza restringe as possíveis mudanças de estado dos fenômenos da natureza, fazendo emergirem padrões estruturais e de comportamento que acabam sendo formalizados como Regras, Teorias, Modelos, ...

e-Reality - Encyclopedia: Lei da Natureza

Um Meta-Modelo para o MER

1.0 - Introdução

O ponto de partida para a construção de um meta-modelo para o MER(Modelo Entidade Relacionamento) é a visão (ponto de vista, enfoque) da Realidade como uma Rede de Elementos (Fenômenos da Realidade).

Dentro dessa visão a Realidade é composta por elementos em permanente interação (relacionados).

Tendo essa visão como ponto de partida podemos emergir para um novo nível do nosso meta-modelo.

Nesse nível (Nível do Conhecimento) que emerge a partir dos Elementos da Realidade, podemos estabelecer, de forma simplista, que a Realidade ou o nosso Conhecimento sobre a Realidade é composto de Conceitos.

Assim como os elementos da realidade interagem entre si (relacionam-se), os conceitos também interagem entre si (relacionam-se), através de um tipo específico (mecanismo específico) o qual iremos chamar de abstração (mecanismo de abstração).

Conceitos são construídos (emergem) a partir dos Elementos da Realidade. Em outras palavras, Conceitos representam um conjunto (classe) de Elementos da Realidade.


Conceitos são construídos (emergem) a partir dos Elementos da Realidade, por meio de um tipo específico de interação – abstração do tipo classificação.

O próprio Conhecimento, então, também pode ser visto como uma Rede de Conceitos em Interação. Essas Interações são os Mecanismos de Abstração.

2.0 - Componentes Estruturais do MER

Os Componentes Estruturais do MER visam representar (modelar) a visão (aspecto ou enfoque) estrutural (estruturas) da Realidade.

Os Componentes Estruturais do MER podem ser classificados através da seguinte hierarquia:

1. Componentes a nível de elemento (representam ou modelam Elementos da Realidade) :
   •Entidade
   •Relacionamento
   •Valor
   


2. Componentes a nível de classe ou conceito (representam ou modelam Conceitos que representam ou modelam o Conhecimento sobre os Elementos da Realidade)
   •Entidade Tipo
   •Relacionamento Tipo
   •Atributo

3.0 - Componentes Comportamentais do MER

Os Componentes Comportamentais do MER visam representar (modelar) a visão (aspecto ou enfoque) comportamental (comportamento ou processos) da Realidade.

Nesse ponto podemos acrescentar outro componente da Realidade – as Leis da Natureza as quais incorporamos ou representamos em nosso conhecimento como Regras (Teorias, Modelos, Conjecturas, ...).

Os Componentes Comportamentais do MER podem ser classificados através da seguinte hierarquia:

1. Regras de Restrição de Integridade (representam ou modelam Regras de Negócio que restringem as mudanças de estado atuais dos Elementos da Realidade) :
   •Identificação
   •Cardinalidade
   •Repetição
   •Cobertura



2. Regras de Derivação, Inferência ou Cálculo (representam ou modelam Regras de Negócio que estabelecem um estado futuro para os Elementos da Realidade)
   

As Regras de Negócio (RN), dentro do domínio dos bancos de dados, podem ser especializadas em Regras de Restrição de Integridade ou mais simplesmente Restrições de Integridade (RI) e Regras de Derivação (RD).

Podem existir outros tipos de Regra de Negócio, não tão relevantes para o domínio dos bancos de dados.

As Restrições de Integridade podem ser mais especializadas em: Cardinalidade, Repetição, Identificação e Cobertura.

Podem existir outros tipos de Restrições de Integridade além das acima mencionadas e serão tratadas genericamente como RI.

Outros modelos possuem RI próprias que não existem no MER.

4.0 - Mini-Mundo – Domínio do Problema – Domínio do Conhecimento Organizacional

Uma outra forma de enfocarmos a Realidade é por meio do conceito de Conhecimento.

O Conhecimento pode ser definido, de forma simplista, como um conjunto de Fatos (informações) e um Conjunto de Regras.

O Conhecimento Organizacional pode ser definido por especialização de Conhecimento como sendo composto de Requisitos de Informação (Fatos Organizacionais) e Regras de Negócio (Regras a Nível de Negócio).

Um Mini-Mundo (Parcela da Realidade, Domínio do Problema, Domínio do Conhecimento Organizacional) é composto de Regras de Negócio e Requisitos de Informação.

Os Conceitos que constituem a base do nosso Conhecimento compõem os Requisitos de Informação e as Regras de Negócio.

Livro - Projeto de Banco de Dados - Heuser

PROJETO DE BANCO DE DADOS 4 (S.LIVROS DIDATICOS)

1. CARLOS ALBERTO HEUSER


2. ISBN: 8524105909


3. Editora: SUPER NOVA DISTR. DE UTILIDADES DOMESTIC


4. Número de páginas: 208


5. Encadernação: Brochura


6. Edição: 1998

Livro - PRINCIPIOS DE SISTEMAS DE BANCOS DE DADOS DISTRIBUIDOS

1. PRINCIPIOS DE SISTEMAS DE BANCOS DE DADOS DISTRIBUIDOS
2. M.TAMER OZSU
3. ISBN: 8535207139
4. Editora: ELSEVIER EDITORA LTDA
5. Número de páginas: 736
6. Encadernação: Brochura
7. Edição: 2001
   

Livro - INTRODUÇÃO A SISTEMAS DE BANCOS DE DADOS

1. INTRODUCAO A SISTEMAS DE BANCOS DE DADOS
2. C. J. DATE
3. ISBN: 8535212736
4. Editora: ELSEVIER EDITORA LTDA
5. Número de páginas: 864
6. Encadernação: Brochura
7. Edição: 2003

Livro - SISTEMAS DE BANCO DE DADOS

1. SISTEMAS DE BANCO DE DADOS
2. ELMASRI, NAVATHE
3. ISBN: 8588639173
4. Editora: PEARSON EDUCATION DO BRASIL LTDA
5. Número de páginas: Não cadastrado
6. Encadernação: Brochura
7. Edição: 2005

Livro - SISTEMA DE BANCO DE DADOS

1. SISTEMA DE BANCO DE DADOS
2. HENRY F. KORTH, ABRAHAM SILBERSCHATZ, S. SUDARSHAN
3. ISBN: 8535211071
4. Editora: ELSEVIER EDITORA LTDA
5. Número de páginas: 808
6. Encadernação: Brochura
7. Edição: 2006

Site da Revista SQL - Magazine

=> Site da Revista SQL Magazine

BD e PBD - Material Didático Complementar

1. Curso de Introdução a Modelagem de Dados (Inglês)
2. Tutoriais diversos sobre BD e PBD da revista SQL-MAGAZINE
3. Apostila sobre Banco de Dados
4. Apostila sobre Projeto de Banco de Dados

MER - Notação da Engenharia da Informação

Um exemplo mais completo =>
Outro exemplo =>

Edgar Frank Codd

Liks importantes:

1. Wikipédia (Port.)=> Edgar Frank Codd
2. Wikipédia (Eng.)=> Edgar Frank Codd
3. Codd's 12 rules
4. Database normalization
5. Relational Model/Tasmania (RM/T)
6. OLAP cube
7. Christopher J. Date
8. Hugh Darwen
   

Referências:

1. Codd, E.F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM 13 (6): 377–387 (Artigo Original sobre o MDR).
2. Codd, E.F. (1990). The Relational Model for Database Management, Version 2, Addison Wesley Publishing Company. ISBN 0-201-14192-2.
3. National Academy of Sciences (1999). "Chapt. 6: The Rise of Relational Databases", Funding a Revolution: Government Support for Computing Research. Washington DC, USA: National Academy Press.
4. Date, C.J. (2000). The Database Relational Model: A Retrospective Review and Analysis: A Historical Account and Assessment of E. F. Codd's Contribution to the Field of Database Technology. Addison Wesley Longman. ISBN 0-201-61294-1.
5. Codd, E.F.; Codd S.B. and Salley C.T. (1993). Providing OLAP to User-Analysts: An IT Mandate. Retrieved on 2007-08-08.

Peter Chen

Links importantes:

1. Homepage
2. Wikipédia => Peter Chen
3. Artigo original do Modelo Entidade Relacionamento (MER)
4. Artigo sobre a evolução do MER até 2001

Modelo de Dados Relacional - MDR - Codd - 1970

O Modelo de Dados Relacional (MDR) foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared Data Banks", foi o primeiro modelo de dados descrito teoricamente, os bancos de dados já existentes passaram então a ser conhecidos como (modelo hierárquico, modelo em redes ou Codasyl e modelo de listas invertidas). Posteriormente o MDR foi aprimorado por Chris Date e Hugh Darwen como um modelo geral de dados. No Terceiro Manifesto (1995) eles mostraram como o MDR pode ser extendido com características de orientação à objeto sem comprometer os seus princípios fundamentais.

Historicamente ele é o sucessor do modelo hierárquico e do modelo em rede. O MDR foi o primeiro modelo de banco de dados formal. Somente depois seus antecessores, os bancos de dados hierárquicos e em rede, passaram a ser também descritos em linguagem formal.

O MDR é um modelo de dados que tem como fundamento teórico a lógica/cálculo de predicados e a teoria dos conjuntos e baseia-se no princípio prático de que todos os dados em um banco de dados serão armazenados em tabelas (ou, matematicamente falando, relações). A principal proposição do modelo relacional é que todos os dados são representados como relações matemáticas, isto é, um subconjunto do produto Cartesiano de n conjuntos.

O princípio básico do MDR é o princípio da informação: toda informação é representada por valores em relações. O MDR permite ao projetista criar um modelo lógico consistente da informação a ser armazenada. Este modelo lógico pode ser refinado através de um processo de normalização. Um banco de dados construído puramente baseado no modelo relacional estará inteiramente normalizado.

Os blocos básicos (elementos/componentes de modelagem) do MDR são:

1. domínio, ou tipo de dado
2. tupla: é um conjunto de atributos que são ordenados em pares de domínio e valor.
3. relação é um conjunto desordenado de tuplas.

Apesar destes conceitos matemáticos, eles correspondem basicamente aos conceitos tradicionais dos bancos de dados. Uma relação é similar ao conceito de tabela e uma tupla é similar ao conceito de linha.

A linguagem padrão para os bancos de dados relacionais, SQL, do inglês Structured Query Language, é apenas vagamente remanescente do modelo matemático. Atualmente ela é adotada, apesar de suas restrições, porque ela é antiga e muito mais popular que qualquer outra linguagem de banco de dados.

Flexibilidade

Um Diagrama de Entidades e Relacionamentos é flexível se as mudanças nos Requisitos de Informação e nas Regras de Negócio tiverem pouco ou nenhum impacto no DER.

Se o DER for correto, minimal e simples (legível) ele provavelmente será flexível.

Formas de garantir a flexibilidade:

1. Procurar generalizar ou agregar ao máximo as Entidades Tipo, os Relacionamento Tipo e os Atributos visando relaxar as Regras de Restrição de Integridade;
2. Procurar especializar ou decompor ao máximo as Entidades Tipo, os Relacionamento Tipo e os Atributos visando facilitar a inclusão de uma característica específica;
3. Procurar decompor Relacionamentos Tipo de grau superior a 2 em outros Relacionamentos Tipo ou em outras Entidades Tipo;
4. Procurar obter, aplicando o mecanismo acima, os valores de cardinalidade (0,N);
5. Procurar obter, aplicando o mecanismo acima, os valores de repetição N; e
6. Procurar obter, aplicando o mecanismo acima os valores, de cobertura de generalização (P,S).

Legibilidade

Um Diagrama de Entidades e Relacionamentos é legível se os conceitos existentes nos Requisitos de Informação e as Regras de Negócio estão representados sem sobrecarregar com detalhes desnecessários o DER e sem o desorganizar graficamente (atender a determinados critérios gráficos).

A legibilidade determina a simplicidade do DER e costuma ser inversa a expressividade.

Formas de garantir a legibilidade:

a) Procurar seguir as seguintes diretrizes gráficas:

1. representar as entidades tipo com maior quantidade de relacionamentos tipo no centro do diagrama;
2. procurar evitar o cruzamento de relacionamentos tipo criando, se for o caso, réplicas de entidades-tipo;
3. representar os conceitos genéricos e agregados acima dos específicos e de seus componentes;
4. dar ênfase a representações simétricas do ponto de vista gráfico; eprocurar representar as entidades tipo e os relacionamentos tipo nas interseções de uma grade “imaginária”.

b) Procurar seguir as seguintes diretrizes sintáticas/semânticas:

1. Procurar generalizar ou agregrar ao máximo as Entidades Tipo, os Relacionamento Tipo e os Atributos, desde que sejam gerados conceitos expressivos dentro do domínio do problema;
2. não representar atributos a partir de um certo grau de complexidade do diagrama (ilegibilidade);
3. eliminação de especializações ou componentes sem características específicas;
4. eliminação de generalizações e agregações com semântica dúbia ou irrelevante;
5. eliminação de entidades-tipo com um único atributo, desde que não afete a consistência do Banco de Dados;
6. substituição de entidades-tipo fracas por atributos agregados multivalorados, desde que elas não se relacionem com mais nada.

Expressividade

Um Diagrama de Entidades e Relacionamentos é expressivo se os conceitos existentes nos Requisitos de Informação e nas Regras de Negócio estão representados da forma mais detalhada possível.

Um DER é expressivo se ele representa os Requisitos de Informação e as Regras de Negócio de uma forma natural e possa ser facilmente entendido através do significado dos componentes e construtores utilizados no diagrama, sem a necessidade de especificações complementares.

Formas de garantir a expressividade:

1. Procurar representar Regras de Restrição de Integridade através dos componentes e construtores do MER;
2. Procurar especializar e particionar ao máximo as Entidades Tipo, os Relacionamento Tipo e os Atributos;
3. Evitar, aplicando os mecanismos acima, os valores de cardinalidade (0,N); e
4. Evitar, aplicando os mecanismos acima os valores, de cobertura de generalização (P,S).

Minimalidade

Um Diagrama de Entidades e Relacionamentos é minimal se os conceitos existentes nos Requisitos de Informação e nas Regras de Negócio estão representados uma única vez.

Formas de garantir a minimalidade:

1. Não representar relacionamentos tipo que incorporem atributos de entidades-tipo criando dependências funcionais não triviais (parciais);
2. Não representar entidades tipo que incorporam atributos de outras entidades-tipo criando dependências funcionais não triviais (transitivas);
3. Não representar relacionamentos tipo que incorporam outros relacionamentos tipo criando dependências multivaloras ou dependências de junção não triviais; e
4. Não representar atributos, entidades tipo ou relacionamentos tipo: derivados (dependências de existência não triviais).

Completeza

Um Diagrama de Entidades e Relacionamentos (Modelo Conceitual de Dados) é completo se TODOS os conceitos contidos nos Requisitos de Informação e nas Regras de Negócio estão representados no DER.

Correção

Um Diagrama de Entidades e Relacionamentos (Modelo Conceitual de Dados) é correto se os conceitos contidos nos Requisitos de Informação e nas Regras de Negócio estão representadas através dos componentes e dos construtores apropriados.

Ex: Um convênio entre um Laboratório e um Hospital, para existir depende da existência de um Hospital e de um Laboratório, ou para ser identificado, depende do identificador do Hospital e do identificador do laboratório.

Regras para utilização do MER

As regras para utilização do MER são baseadas em critérios de qualidade do MER e serão detalhadas a partir deles:

1. Correção
2. Completeza
3. Minimalidade
4. Expressividade
5. Legibilidade
6. Flexibilidade

MS-SQL Server

O MS SQL Server é um gerenciador de Banco de dados relacional feito pela Microsoft. É um Banco de dados robusto e usado por sistemas corporativos dos mais diversos portes. Sua versão atual é a 2005. Entre os novos recursos está a integração com o Framework .Net, que possibilita construir rotinas utilizando as linguagens do .Net como VB.Net e C#.
O MS SQL Server funciona apenas sob algumas das várias versões do sistema operacional Windows, da Microsoft, ao contrário de seus grandes concorrentes, Oracle e Postgres, que funcionam em diversas plataformas e sistemas operacionais diferentes.

O que é o SQL Server 2005?

O SQL Server 2005 é uma plataforma abrangente de banco de dados que fornece recursos de gerenciamento de dados de classe empresarial com ferramentas de BI (Business Intelligence) integradas. O mecanismo de banco de dados do SQL Server 2005 oferece um armazenamento mais seguro e confiável tanto para dados relacionais quanto estruturados, permitindo que você crie e gerencie aplicativos de dados altamente disponíveis e eficientes para uso em seus negócios.

O mecanismo de dados do SQL Server 2005 é a parte central dessa solução de gerenciamento de dados empresariais. Além disso, o SQL Server 2005 combina os melhores recursos de análise, geração de relatórios, integração e notificação. Isso permite que sua empresa crie e implante soluções de BI econômicas que ajudem sua equipe a distribuir os dados por todos os cantos da empresa, através de scorecards, painéis, serviços da Web e dispositivos móveis.

O diagrama a seguir ilustra os principais componentes do SQL Server 2005, mostrando como ele se integra à plataforma Microsoft Windows — inclusive ao Microsoft Office System e ao Visual Studio — para oferecer soluções que disponibilizam dados em todos os cantos da sua organização.

1. SQL SERVER - Home
2. SQL SERVER - BR

Postgre SQL - 1996

O PostgreSQL é um dos resultados de uma ampla evolução que se iniciou com o projeto Ingres, desenvolvido na Universidade de Berkeley, Califórnia. O lider do projeto, Michael Stonebraker, um dos pioneiros dos bancos de dados relacionais, deixou a universidade em 1982 para comercializar o Ingres, porém retornou a ela logo em seguida.

Após seu retorno a Berkeley, em 1985, Stonebraker começou um projeto pós-Ingres com o objetivo de resolver problemas com o modelo de banco de dados relacional. O principal problema era a incapacidade do modelo relacional compreender “tipos” (atualmente, chamados de objetos), ou seja, combinações de dados simples que formam uma única unidade.

O projeto resultante, chamado Postgres, era orientado a introduzir a menor quantidade possível de funcionalidades para completar o suporte a tipos. Estas funcionalidades incluiam a habilidade de definir tipos, mas também a habilidade de descrever relações - as quais até este momento eram amplamente utilizadas mas completamente mantidas pelo usuário. No Postgres, o banco de dados "compreendia" as relações e podia obter informações de tabelas relacionadas utilizando regras.

Iniciando em 1986, a equipe divulgou uma série de documentos descrevendo a base do sistema e em 1988 o projeto possuía um protótipo funcional. A versão 1 foi liberada para um grupo pequeno de usuários em junho de 1989, seguida pela versão 2 com um sistema de regras reescrito em junho de 1990. Para a versão 3, liberada em 1991, o sistema de regras foi reescrito novamente, mas também foram adicionados suporte para múltiplos gerenciadores de armazenamento e um melhorado motor de consultas. Já em 1993, Postgres havia crescido imensamente em popularidade e possuía uma grande demanda por suporte e por novas funcionalidades. Após a liberação da versão 4, a qual era uma simples versão de limpeza, o
projeto foi oficialmente abandonado pela Universidade de Berkeley.

Entretanto, devido ao fato do seu código fonte estar sob uma licença BSD, o seu desenvolvimento foi continuado. Em 1994, dois estudantes de Berkeley, Andrew Yu e Jolly Chen, adicionaram um interpretador SQL para substituir a linguagem QUEL (desenvolvida para o Ingres) e o projeto foi renomeado para Postgres95. Com a divulgação de seu código pela Internet, Postgres95 iniciou uma nova vida como software open source.

Em agosto de 1996, Marc Fournier, Bruce Momjian e Vadim B. Mikheev lançaram a primeira versão externa da Universidade de Berkeley e deram início à tarefa de estabilizar o código herdado. Também em 1996, o projeto foi renomeado para PostgreSQL a fim de refletir a nova linguagem de consulta ao banco de dados: SQL. A primeira versão de PostgreSQL, a 6.0, foi liberada em janeiro de 1997. Desde então, um grupo de desenvolvedores e de voluntários de todo o mundo, coordenados pela Internet, têm mantido o software e desenvolvido novas funcionalidades.

As principais características acrescentadas nas versões 6.x são o MVCC (Multiversion Concurrency Control – Controle de Concorrência Multiversões), melhorias no SQL e novos tipos de dados nativos (novos tipos de datas e hora e tipos geométricos).

Em maio de 2000 foi liberada a versão 7.0. As versões 7.x trouxeram as seguintes novas funcionalidades: Write-Ahead Log (WAL), esquemas SQL, outer joins, suporte a IPv6, indexação por texto, suporte melhorado a SSL e informações estatísticas do banco de dados.

A versão 8.0 foi lançada em janeiro de 2005 e entre outras novidades, foi a primeira a ter suporte nativo para Microsoft Windows (tradicionalmente, o PostgreSQL só rodava de forma nativa em sistemas Unix e, em sistemas Windows - através da biblioteca Cygwin). Dentre as muitas novidades da versão 8.x, pode-se destacar o suporte a tablespaces, save points, point-in-time recovery, roles e Two-Phase Commit (2PC). Em dezembro de 2006 foi lançada a versão mais recente: 8.2.

Fonte: Wikipédia

Ver aqui =>

MYSQL

O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada) como interface.

É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de instalações pelo mundo.

1) Histórico:

O MySQL foi criado na Suécia por dois suecos e um finlandês: David Axmark, Allan Larsson e Michael "Monty" Widenius, que trabalham juntos desde a década de 1980. Hoje seu desenvolvimento e manutenção empregam aproximadamente 70 profissionais no mundo inteiro, e mais de mil contribuem testando o software, integrando-o a outros produtos, e escrevendo a respeito do mesmo.

O sucesso do MySQL deve-se em grande medida à fácil integração com o PHP incluído, quase que obrigatoriamente, nos pacotes de hospedagem de sites da Internet oferecidos atualmente.

2) Arquitetura do MYSQL

3) Características:

-Portabilidade (suporta praticamente qualquer plataforma atual);

- Compatibilidade (existem drivers ODBC, JDBC e .NET e módulos de interface para diversas linguagens de programação, como Delphi, Java, C/C++, Python, Perl, PHP e Ruby);

- Excelente desempenho e estabilidade;

- Pouco exigente quanto a recursos de hardware;

- Facilidade de uso;

- Suporte a vários tipos de tabelas (como MyISAM e InnoDB), cada um específico para um fim;
Faltam alguns recursos quando comparados como outros banco de dados, como o PostgreSQL.

- Código aberto e funcionar em um grande número de sistemas operacionais : Windows, Linux, FreeBSD, BSDI, Solaris, Mac OS X, SunOS, SGI, etc; e

- É reconhecido pelo seu desempenho e robustez e também por ser multi-tarefa e multi-usuário. A própria Wikipédia, usando o programa MediaWiki, utiliza o MySQL para gerenciar seu banco de dados, demostrando que é possível utilizá-lo em sistemas de produção de alta exigência e em aplicações sofisticadas.

4) Tipos de tabelas suportadas:

ORACLE 11G

Oracle Announces General Availability of Oracle Database 11g.

Oracle Database 11g, the latest release of the world's most popular database, is now generally available on the Linux platform. Oracle Database 11g delivers the next generation of enterprise information management, helping customers tackle the demands of rapid data growth, changing environments, and the need to deliver higher quality of services while reducing and controlling IT costs.

Ver aqui=>

ORACLE

O SGBD Oracle surgiu no final da década de 70. Criado por Larry Ellison, quando encontrou uma descrição de um protótipo funcional de um banco de dados relacional e descobriu que nenhuma empresa tinha se empenhado em comercializar essa tecnologia.

Em 1977, em parceria com um antigo supervisor da Ampex chamado Robert Miner, fundou a Software Development Labs. A dupla aproveitou um conceito que a IBM não quis explorar e montou uma base de dados compatível com centrais de computadores e diversos terminais em simultâneo. Nessa altura renomeou a empresa para Oracle e encontrou os dois primeiros clientes: uma base da força aérea dos EUA e a CIA.

Ellison e os co-fundadores da Oracle Corporation, Bob Miner e Ed Oates, perceberam que havia um tremendo potencial de negócios no modelo de banco de dados relacional tornando assim a maior empresa de software empresarial do mundo. O SGBD da Oracle é líder de mercado.

O Oracle 9i foi pioneiro no suporte ao modelo web. O Oracle 10g, mais recente, se baseia na tecnologia de grid.

Fonte: Wikipédia

Zoho - Banco de Dados para a WEB

Zoho DB & Reports é uma ferramenta de banco de dados para pequenas aplicações com instruções SQL que funciona diretamente na Internet. Todos que desejam possuir uma suite de produtividade, seja na Internet, seja fora dela, precisam de um banco de dados. Ela já possui quase todos os aplicativos, inclusive Wiki. O BD da Zoho é o primeiro que eu conheço que é baseado na Internet. Uma empresa pequena começa a se tornar uma pedra no sapato de várias gigantes, sempre em benefício do consumidor.