2362 - Banco de Dados

BANCO DE DADOS
Tópicos Abordados:
Ä Conceito sobre Banco de Dados e SGBD’s

Ä Arquiteturas
Ä Modelos de Dados
Ä Tipos de Softwares Gerenciadores de B. D.
AcroPDF - A Quality PDF Writer and PDF Converter to create PDF files. To remove the line, buy a license.
WBSOFTWARES (**79)8115-7557
SUMÁRIO
Introdução.................................................................................................03
1.0 – Banco de Dados...............................................................................04
2.0 – Sistema Gerenciador de Banco de Dados........................................04
2.1 – Modelo de Dados.................................................................05
2.2 – Tipos de Arquiteturas...........................................................07
2.3 – Capacidades do SGBD.........................................................08
3.0 – Arquiteturas de Banco de Dados......................................................09
3.1 – Aspectos Relevantes.............................................................10
3.2 – Vantagens dos Bancos de Dados..........................................11
3.3 – Linguagens de Base de Dados..............................................12
4.0 – O que é Modelo de Dados?..............................................................12
4.1 – Modelo Entidade Relacionamento.......................................12
4.2 – Entidades e Atributos...........................................................12
4.2.1 – Tipos de Atributos..............................................13
4.3 – Relacionamentos...................................................................15
4.4 – Entidade Fraca......................................................................19
4.5 – Modelo de Entidade Relacionamento Extendido.................20
4.5.1 – Especialização e Generalização...........................20
4.6 – Operações..............................................................................22
5.0 – Tipos de Sistemas Gerenciadores de Banco de Dados......................23
5.1 – dBase......................................................................................23
5.2 – MySQL..................................................................................25
5.3 – PostgreSQL ...........................................................................29
5.4 – Oracle.....................................................................................31
5.5 - Microsoft SQL Server.............................................................31
5.6 - Microsoft Access...................................................................32
5.7 - Data Warehouse.....................................................................34
5.7.1 – Metadado..............................................................37
5.7.2 - Data Mart.............................................................38
5.7.3 - Data Mining.........................................................43
6.0 – Alguns Conceitos Importantes...........................................................51
7.0 - Conclusão..........................................................................................55
8.0 - Bibliografia........................................................................................56
2
INTRODUÇÃO
Saber o significado de um Banco de Dados e que o SGBD é um sistema que o

gerencia não é saber o bastante, pois estamos falando de um grande volume de dados,
ou seja, informações que precisam ser armazenadas, acessadas, atualizadas por um
indefinido espaço de tempo, dando aos seus usuários agilidade e qualidade de resposta
no cruzamento das informações.
Esse armazenamento e gerenciamento surgiram para deixar de lado os primitivos
sistemas de arquivos que não conseguiam controlar os inúmeros processos e usuários
que faziam uso de seus pequenos recursos.
Atualmente os bancos de dados não impõem limites de armazenamento, em alguns
casos não necessita de muito hardware, nos proporciona segurança e até tem capacidade
de nos disponibilizar múltiplas visões dos dados.
Esses sistemas gerenciadores de arquivos seja ele “free” (gratuito) ou não, ambos
tem capacidade de nos trazer ferramentas necessárias para o gerenciamento de qualquer
tipo de informações armazenadas, independente de sua representação ou modelo pelo
qual as informações estão estruturadas.
3
1.0 – Banco de Dados
O que é um Banco de Dados?
O termo Banco de Dados foi criado para indicar coleções organizadas de dados
armazenados em computadores digitais; utilizando um conceito, Banco de Dados ou
Bases de Dados são conjuntos de dados integrados com uma estrutura que organizam
informações. Sendo essas informações utilizadas normalmente para um mesmo fim. Um
banco de dados é usualmente mantido e acessado por meio de um software conhecido
como SGBD.
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.
2.0 – Sistema Gerenciador de Banco de Dados
O que é um SGBD?
Um sistema Gerenciador de Banco de Dados ou Sistema Gestor de Base de Dados

(SGBD), é um conjunto de programas responsáveis pelo gerenciamento de uma base de
dados. È um sistema extremamente complexo, responsável pela persistência,
organização e recuperação dos dados.
Historicamente, o primeiro Sistema Gerenciador de Banco de Dados comercial
surgiu no final de 1960 com base nos primitivos sistemas de arquivos disponíveis na
época, os quais não controlavam o acesso concorrente por vários usuários ou processos.
Os SGBDs evoluíram desses sistemas de arquivos de armazenamento em disco, criando
novas estruturas de dados com o objetivo de armazenar informações.
Com o tempo, os SGBD’s passaram a utilizar diferentes formas de representação, ou
modelos de dados, para descrever a estrutura das informações contidas em seus bancos
de dados.
4
2.1 - Os modelos de dados mais utilizados pelos SGBD’s são:
Modelo Hierárquico
O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados.

Seu desenvolvimento somente foi possível devido à consolidação dos discos de
armazenamento endereçáveis, pois esses discos possibilitaram a exploração de sua
estrutura de endereçamento físico para viabilizar a representação hierárquica das
informações. Nesse modelo de dados, os dados são estruturados em hierarquias ou
árvores. Os nós das hierarquias contêm ocorrências de registros, onde cada registro é
uma coleção de campos (atributos), cada um contendo apenas uma informação. O
registro da hierarquia que precede a outros é o registro-pai, os outros são chamados de
registros-filhos.
Modelo em Rede
O modelo em rede surgiu como uma extensão ao modelo hierárquico, eliminando o

conceito de hierarquia e permitindo que um mesmo registro estivesse envolvido em
várias associações.
Esse modelo 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.
O gerenciador Data Base Task Group (DBTG) da CODASYL (Committee on Data
Systems and Languages) estabeleceu uma norma para este modelo de banco de dados,
com linguagem própria para definição e manipulação de dados. Os dados tinham uma
forma limitada de independência física. A única garantia era que o sistema deveria
recuperar os dados para as aplicações como se eles estivessem armazenados na maneira
indicada nos esquemas. Os geradores de relatórios da CODASYL também definiram
sintaxes para dois aspectos chaves dos sistemas gerenciadores de dados: concorrência e
segurança. O mecanismo de segurança fornecia uma facilidade na qual parte do banco
de dados (ou área) pudesse ser bloqueada para prevenir acessos simultâneos, quando
necessário. A sintaxe da segurança permitia que uma senha fosse associada a cada
objeto descrito no esquema. Ao contrário do Modelo Hierárquico, em que qualquer
acesso aos dados passa pela raiz, o modelo em rede possibilita acesso a qualquer nó da
rede sem passar pela raiz. No Modelo em Rede o sistema comercial mais divulgado é o
CAIDMS da Computer Associates. O diagrama para representar os conceitos do modelo
em redes consiste em dois componentes básicos: Caixas, que correspondem aos
registros e Linhas, que correspondem às associações.
Modelo Relacional
O modelo relacional é uma teoria matemática desenvolvida por Edgar Frank Codd
que surgiu na década de 1970, para descrever como as bases de dados devem funcionar.
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.
5
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.
De acordo com a arquitetura ANSI / SPARC em três níveis, os bancos de dados
relacionais possuem três camadas: um conjunto de visões compondo o nível externo;
uma coleção de estruturas de dados, a saber relações, compondo o nível conceitual; um
conjunto de índices ou métodos de acesso a dados armazenados, compondo o nível
interno.
A teoria relacional de banco de dados define um conjunto de operações lógicas, a
saber a álgebra e o cálculo relacionais. Essas operações são a base da linguagem SQL.
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.
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 a presença de atributos chave. Como
resultado, bancos de dados relacionais podem ser reorganizados e utilizados de maneira
flexível e de formas não previstas pelos projetistas originais. Por causa dessa
flexibilidade, muitos bancos de dados são baseados no modelo relacional, embora
imperfeitamente.
O modelo relacional apareceu devido às seguintes necessidades: aumentar a
independência de dados nos sistemas gerenciadores de banco de dados; prover um
conjunto de funções apoiadas em álgebra relacional para armazenamento e recuperação
de dados. Modelo que revelou-se ser o mais flexível e adequado ao solucionar os vários
problemas que se colocam no nível da concepção e implementação da base de dados. A
estrutura fundamental do modelo relacional é a relação (tabela). Uma relação é
constituída por um ou mais atributos (campos) que traduzem o tipo de dados a
armazenar. Cada instância do esquema (linha) é chamada de tupla (registro). O modelo
relacional não tem caminhos pré-definidos para se fazer acesso aos dados como nos
modelos que o precederam. O modelo relacional implementa estruturas de dados
organizadas em relações. Porém, para trabalhar com essas tabelas, algumas restrições
precisaram ser impostas para evitar aspectos indesejáveis, como: Repetição de
informação, incapacidade de representar parte da informação e perda de informação.
Essas restrições são: integridade referencial, chaves e integridade de junções de
relações.
Modelo Orientado a Objetos
Os bancos de dados orientados a objeto começaram a se tornar comercialmente

viáveis em meados de 1980. A motivação para seu surgimento está em função dos
limites de armazenamento e representação semântica impostas no modelo relacional.
Alguns exemplos são os sistemas de informações geográficas (SIG), os sistemas CAD e
CAM, que são mais facilmente construídos usando tipos complexos de dados. A
habilidade para criar os tipos de dados necessários é uma característica das linguagens
de programação orientadas a objetos.
6
Contudo, estes sistemas necessitam guardar representações das estruturas de dados

que utilizam no armazenamento permanente. A estrutura padrão para os bancos de
dados orientados a objetos foi feita pelo Object Database Management Group (ODMG).
Esse grupo é formado por representantes dos principais fabricantes de banco de
dados orientados a objeto disponíveis comercialmente. Membros do grupo têm o
compromisso de incorporar o padrão em seus produtos. O termo Modelo Orientado a
Objetos é usado para documentar o padrão que contém a descrição geral das facilidades
de um conjunto de linguagens de programação orientadas a objetos e a biblioteca de
classes que pode formar a base para o Sistema de Banco de Dados. Quando os bancos
de dados orientados a objetos foram introduzidos, algumas das falhas perceptíveis do
modelo relacional pareceram ter sido solucionadas com esta tecnologia e acreditava-se
que tais bancos de dados ganhariam grande parcela do mercado. Hoje, porém, acredita-
se que os Bancos de Dados Orientados a Objetos serão usados em aplicações
especializadas, enquanto os sistemas relacionais continuarão a sustentar os negócios
tradicionais, onde as estruturas de dados baseadas em relações são suficientes.
2.2 - Tipos de arquiteturas de SGBDs
Arquitetura Centralizada
Na arquitetura centralizada, existe um computador com grande capacidade de

processamento, o qual é o hospedeiro do SGBD e emuladores para os vários aplicativos.
Esta arquitetura tem como principal vantagem a de permitir que muitos usuários
manipulem grande volume de dados. Sua principal desvantagem está no seu alto custo,
pois exige ambiente especial para mainframes e soluções centralizadas.
Arquitetura do tipo Sistemas de Computador Pessoal – PC
Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus

processamentos sozinhos. No começo esse processamento era bastante limitado, porém,
com a evolução do hardware, tem-se hoje PCs com grande capacidade de
processamento. Eles utilizam o padrão Xbase e quando se trata de SGBDs, funcionam
como hospedeiros e terminais. Desta maneira, possuem um único aplicativo a ser
executado na máquina. A principal vantagem desta arquitetura é a simplicidade.
Arquitetura Cliente-Servidor
Na arquitetura Cliente-Servidor, o cliente executa as tarefas do aplicativo, ou seja,

fornece a interface do usuário (tela, e processamento de entrada e saída). O servidor
executa as consultas no DBMS e retorna os resultados ao cliente. Apesar de ser uma
arquitetura bastante popular, são necessárias soluções sofisticadas de software que
possibilitem: o tratamento de transações, as confirmações de transações, desfazer
transações, linguagens de consultas e gatilhos (triggers). A principal vantagem desta
arquitetura é a divisão do processamento entre dois sistemas, o que reduz o tráfego de
dados na rede.
7
Banco de Dados Distribuídos (N camadas)
Nesta arquitetura, a informação está distribuída em diversos servidores. Cada

servidor atua como no sistema cliente-servidor, porém as consultas oriundas dos
aplicativos são feitas para qualquer servidor indistintamente. Caso a informação
solicitada seja mantida por outro servidor ou servidores, o sistema encarrega-se de obter
a informação necessária, de maneira transparente para o aplicativo, que passa a atuar
consultando a rede, independente de conhecer seus servidores. Exemplos típicos são as
bases de dados corporativas, em que o volume de informação é muito grande e, por isso,
deve ser distribuído em diversos servidores. Porém, não é dependente de aspectos
lógicos de carga de acesso aos dados, ou base de dados fracamente acopladas, em que
uma informação solicitada vai sendo coletada numa propagação da consulta numa
cadeia de servidores. A característica básica é a existência de diversos programas
aplicativos consultando a rede para acessar os dados necessários, porém, sem o
conhecimento explícito de quais servidores dispõem desses dados.
2.3 - Capacidades do SGBD
Controle de Redundância
No processamento tradicional de arquivos, muitos grupos de usuários mantêm seus

próprios arquivos para manipular suas aplicações de processamento, que pode provocar
o armazenamento de informações redundantes, causando, duplicação de esforços,
desperdício de espaço, inconsistência, ou seja, alteração em alguns arquivos e em outros
não, ou em todos os arquivos, porém, de maneira independente.
Compartilhamento de Dados
SGBD’s multiusuários devem fornecer controle de concorrência para assegurar que

atualizações simultâneas resultem em modificações corretas. Um outro mecanismo que
permite a noção de compartilhamento de dados em um SGBD multiusuário é a
facilidade de definir visões de usuário, que é usada para especificar a porção da base de
dados que é de interesse para um grupo particular de usuários.
Restrições de Acesso Multiusuário
Quando múltiplos usuários compartilham uma base de dados, é comum que alguns
usuários não autorizados não tenham acesso a todas as informações da base de dados.
Por exemplo, os dados financeiros são freqüentemente considerados confidenciais e,
desse modo, somente pessoas autorizadas devem ter acesso. Além disso, pode ser
permitido a alguns usuários, apenas a recuperação dos dados. Já, para outros, são
permitidas a recuperação e a modificação. Assim, o tipo de operação de acesso -
recuperação ou modificação - pode também ser controlado. Tipicamente, usuários e
grupos de usuários recebem uma conta protegida por palavras chaves, que é usada para
se obter acesso à base de dados, o que significa dizer que contas diferentes possuem
restrições de acesso diferentes. Um SGBD deve fornecer um subsistema de autorização
e segurança, que é usado pelo DBA para criar contas e especificar restrições nas contas.
8
O SGBD deve então obrigar estas restrições automaticamente. Note que um controle
similar pode ser aplicado ao software do SGBD.
Fornecimento de Múltiplas Interfaces
Devido aos vários tipos de usuários, com variados níveis de conhecimento técnico,
um SGBD deve fornecer uma variedade de interfaces para atendê-los. Os tipos de
interfaces incluem linguagens de consulta para usuários ocasionais, interfaces de
linguagem de programação para programadores de aplicações, formulários e interfaces
dirigidas por menus para usuários comuns.
Representação de Relacionamento Complexo entre Dados
Uma base de dados pode possuir uma variedade de dados que estão inter-
relacionados de muitas maneiras. Um SGBD deve ter a capacidade de representar uma
variedade de relacionamentos complexos entre dados, bem como recuperar e modificar
dados relacionados de maneira fácil e eficiente.
Reforçar Restrições de Integridade
Muitas aplicações de base de dados terão certas restrições de integridade de dados.

A forma mais elementar de restrição de integridade é a especificação do tipo de dado de
cada item. Existem tipos de restrições mais complexas.
Um tipo de restrição que ocorre freqüentemente é a especificação de que um registro
de um arquivo deve estar relacionado a registros de outros arquivos. Um outro tipo de
restrição especifica a unicidade sobre itens de dados. Estas restrições são derivadas da
semântica dos dados e do mini-mundo que eles representam. Algumas restrições podem
ser especificadas ao SGBD e automaticamente executadas. Outras restrições podem ser
verificadas pelos programas de atualização ou no tempo da entrada de dados. Note que
um item de dados pode ser “inserido” erroneamente, mas ainda atender as restrições de
integridade.
Fornecer Backup e Restauração
Um SGBD deve fornecer recursos para restauração caso ocorram falhas de hardware
ou software. O subsistema de backup e restauração do SGBD é o responsável pela
restauração. Por exemplo, se o sistema de computador falhar no meio da execução de
um programa que esteja realizando uma alteração complexa na base de dados, o
subsistema de restauração é responsável por assegurar que a base de dados seja
restaurada ao estado anterior ao início da execução do programa. Alternativamente, o
subsistema de restauração poderia assegurar que o programa seja reexecutado a partir do
ponto em que havia sido interrompido.
3.0 - Arquiteturas de Banco de Dados
As primeiras arquiteturas usavam mainframes para executar o processamento

principal e de todas as funções do sistema, incluindo os programas aplicativos,
programas de interface com o usuário, bem como a funcionalidade dos SGBDs. Esta é a
razão pela qual a maioria dos usuários fazia acesso aos sistemas via terminais que não
9
possuíam poder de processamento, apenas a capacidade de visualização. Todos os

processamentos eram feitos remotamente, apenas as informações a serem visualizadas e
os controles eram enviados do mainframe para os terminais de visualização, conectados
a ele por redes de comunicação. Como os preços do hardware foram decrescendo,
muitos usuários trocaram seus terminais por computadores pessoais (PC) e estações de
trabalho. No começo os SGBDs usavam esses computadores da mesma maneira que
usavam os terminais, ou seja, o SGBD era centralizado e toda sua funcionalidade,
execução de programas aplicativos e processamento da interface do usuário eram
executados em apenas uma máquina. Gradualmente, os SGBDs começaram a explorar a
disponibilidade do poder de processamento no lado do usuário, o que levou à
arquitetura cliente-servidor.
A arquitetura cliente-servidor foi desenvolvida para dividir ambientes de
computação onde um grande número de PCs, estações de trabalho, servidores de
arquivos, impressoras, servidores de banco de dados e outros equipamentos são
conectados juntos por uma rede. A idéia é definir servidores especializados, tais como
servidor de arquivos, que mantém os arquivos de máquinas clientes, ou servidores de
impressão que podem estar conectados a várias impressoras; assim, quando se desejar
imprimir algo, todas as requisições de impressão são enviadas a este servidor. As
máquinas clientes disponibilizam para o usuário as interfaces apropriadas para utilizar
esses servidores, bem como poder de processamento para executar aplicações locais.
Esta arquitetura se tornou muito popular por algumas razões. Primeiro, a facilidade de
implementação dada a clara separação das funcionalidades e dos servidores.
Segundo, um servidor é inteligentemente utilizado porque as tarefas mais simples
são delegadas às máquinas clientes mais baratas. Terceiro, o usuário pode executar uma
interface gráfica que lhe é familiar, ao invés de usar a interface do servidor. Desta
maneira, a arquitetura cliente-servidor foi incorporada aos SGBDs comerciais.
Diferentes técnicas foram propostas para se implementar essa arquitetura, sendo que a
mais adotada pelos Sistemas
Gerenciadores de Banco de Dados Relacionais (SGBDRs) comerciais é a inclusão
da funcionalidade de um SGBD centralizado no lado do servidor. As consultas e a
funcionalidade transacional permanecem no servidor, sendo que este é chamado de
servidor de consulta ou servidor de transação. É assim que um servidor SQL é fornecido
aos clientes. Cada cliente tem que formular suas consultas SQL, prover a interface do
usuário e as funções de interface usando uma linguagem de programação. O cliente
pode também se referir a um dicionário de dados o qual inclui informações sobre a
distribuição dos dados em vários servidores SQL, bem como os módulos para a
decomposição de uma consulta global em um número de consultas locais que podem ser
executadas em vários sítios. Comumente o servidor SQL também é chamado de back-
end machine e o cliente de front-end machine. Como SQL provê uma linguagem padrão
para o SGBDRs, esta criou o ponto de divisão lógica entre o cliente e o servidor.
3.1 - Aspectos relevantes
É necessário considerar alguns aspectos relevantes para atingir a eficiência e a

eficácia dos sistemas informatizados desenvolvidos, a fim de atender seus usuários nos
mais variados domínios de aplicação: automação de escritórios, sistemas de apoio a
decisões, controle de reserva de recursos, controle e planejamento de produção,
alocação e estoque de recursos, entre outros. Tais aspectos são:
10
o Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever

o volume de informações armazenadas a curto, médio e longo prazo. Os projetos devem
ter uma grande capacidade de adaptação para os três casos mencionados;
o Deve-se ter generalidade e alto grau de abstração de dados, possibilitando

confiabilidade e eficiência no armazenamento dos dados e permitindo a utilização de
diferentes tipos de gerenciadores de dados através de linguagens de consultas
padronizadas;
o Projeto de uma interface ágil e com uma "rampa ascendente" para propiciar
aprendizado suave ao usuário, no intuito de minimizar o esforço cognitvo;
o Implementação de um projeto de interface compatível com múltiplas

plataformas (UNIX, Windows NT, Windows Workgroup, etc);
o Independência de Implementação da Interface em relação aos SGBDs que darão

condições às operações de armazenamento de informações (ORACLE, SYSBASE,
INFORMIX, PADRÃO XBASE, etc).
o Conversão e mapeamento da diferença semântica entre os paradigmas utilizados

no desenvolvimento de interfaces (Imperativo (ou procedural), Orientado a Objeto,
Orientado a evento), servidores de dados (Relacional) e programação dos aplicativos
(Imperativo, Orientado a Objetos).
3.2 - Vantagens dos Bancos de Dados
o Potencial para obrigar a Padronização
A abordagem de base de dados permite que o DBA defina e obrigue a padronização

entre os usuários da base de dados em grandes organizações. Isso facilita a comunicação
e a cooperação entre vários departamentos, projetos e usuários. Padrões podem ser
definidos para formatos de nomes, elementos de dados, telas, relatórios, terminologias,
etc. O DBA pode obrigar a padronização em um ambiente de base de dados
centralizado, muito mais facilmente que em um ambiente onde cada usuário ou grupo
tem o controle de seus próprios arquivos e programas de aplicação.
o Flexibilidade
Mudanças na estrutura de uma base de dados podem ser necessárias devido a

mudanças nos requisitos. Por exemplo, um novo grupo de usuários pode surgir com
necessidade de informações adicionais, ainda não disponíveis na base de dados. Alguns
SGBD’s permitem que tais mudanças na estrutura da base de dados sejam realizadas
sem afetar a maioria dos programas de aplicações existentes.
o Redução do Tempo de Desenvolvimento de Aplicações
Uma das principais características de venda da abordagem de base de dados é o

tempo reduzido para o desenvolvimento de novas aplicações, como a recuperação de
certos dados da base de dados para a impressão de novos relatórios. Projetar e
11
implementar uma nova base de dados pode tomar mais tempo do que escrever uma
simples aplicação de arquivos especializada. Porém, uma vez que a base de dados esteja
em uso, geralmente o tempo para se criar novas aplicações, usando-se os recursos de um
SGBD, é bastante reduzido. O tempo para se desenvolver uma nova aplicação em um
SGBD é estimado em 1/4 a 1/6 do que o tempo de desenvolvimento, usando-se apenas o
sistema de arquivos tradicional, devido às facilidades de interfaces disponíveis em um
SGBD.
o Disponibilidade de Informações Atualizadas
Tão logo um usuário modifique uma base de dados, todos os outros usuários
“sentem” imediatamente esta modificação. Esta disponibilidade de informações
atualizadas é essencial para muitas aplicações, tais como sistemas de reservas de
passagens aéreas ou bases de dados bancárias. Isso somente é possível devido ao
subsistema de controle de concorrência e restauração do SGBD.
o Economia de Escala
A abordagem de SGBD’s permite a consolidação de dados e de aplicações

reduzindo-se, desse modo, o desperdício em atividades redundantes de processamento
em diferentes projetos ou departamentos. Isto possibilita à organização como um todo
investir em processadores mais poderosos, e periféricos de armazenamento e de
comunicação mais eficientes.
3.3 - Linguagens de Base de Dados
o Linguagem de Definição de Dados (“Data Definition Language” - DDL): é

utilizada pelo DBA e projetistas de base de dados para definir seus esquemas. O SGBD
tem um compilador para processar descrições em DDL e construir a descrição do
esquema armazenado no catálogo;
o Linguagem de Manipulação de Dados (“Data Manipulation Language” - DML):

uma vez que o esquema é compilado e a base de dados preenchida com dados, os
usuários têm que ter algum modo de manipular os dados. Manipulações comuns como
recuperação, inserção, remoção e modificação de dados são realizadas pela DML.
4.0 - O que é Modelo de Dados?

É uma imagem gráfica de toda a base de informações necessárias para um
determinado empreendimento.
4.1 - Modelo Entidade Relacionamento
O Modelo Entidade-Relacionamento é um modelo de dados conceitual de alto-nível,

ou seja, seus conceitos foram projetados para serem compreensíveis a usuários,
descartando detalhes de como os dados são armazenados; modelo proposto por Peter
Chain em 1976. Sua principal finalidade é identificar entidades de dados e seus
relacionamentos.
12
4.2 - Entidades e atributos
Uma entidade representa um objeto do mundo real que possui existência própria e
cujas características ou propriedades desejamos armazenar. O objeto representado pode
ser um objeto concreto (uma pessoa, um carro, um livro, etc) ou abstrato (um
departamento, um projeto, um curso). As características do objeto que desejamos
armazenar damos o nome de atributos. Cada atributo de uma entidade possui um nome e
um valor especifico.
EMPREGADO
ð Representação de uma entidade.
Um conjunto de entidades inclui um número qualquer de entidades similares, ou

entidades do mesmo tipo. Por entidades do mesmo tipo entenda-se entidades que
possuem os mesmos atributos, cada um deles com um valor próprio. Conjuntos de
entidades são representados em um diagrama entidade-relacionamento por meio de
retângulos contendo o nome do tipo de entidade no seu interior e arestas ligando esses
retângulos aos atributos das entidades. Os atributos aparecem, normalmente, dentro de
ovais.
ENDEREÇO
TELEFONE
NOME
FUNCIONÁRIO
ð Na representação acima temos um conjunto de Entidades e seus atributos.
4.2.1 - Tipos de Atributos

Os atributos no Modelo Entidade-Relacionamento podem ser:
o Atributos Simples ou Atômicos

São os atributos que não são divisíveis.
o Atributos compostos
Podem ser divididos em várias partes (sub-atributos) com significados
independentes. O atributo Endereço de um funcionário, por exemplo, pode ser dividido
em Rua, Número e Bairro.
NÚMERO
BAIRRO
RUA
ENDEREÇO
TELEFONE
NOME
FUNCIONÁRIO 13
ð Representação dos atributos compostos do endereço de um funcionário.
o Atributos Monovalorados
São aqueles que possuem apenas um valor para aquela entidade.
o Atributos multivalorados
Podem assumir diversos valores. Como por exemplo o atributo Telefone de um
funcionário já que pode assumir diversos valores.
NÚMERO
BAIRRO
RUA
ENDEREÇO
TELEFONE
NOME
FUNCIONÁRIO
ð Atributos multivalorados são representados graficamente por uma oval de

bordas duplas.
o Atributos derivados:
Em alguns casos, dois ou mais atributos estão relacionados, por exemplo, a idade e
data de nascimento de um funcionário. Para um determinado funcionário, podemos
determinar a sua idade por meio da data de nascimento e da data atual. Atributos como a
idade são chamados de atributos derivados, ao contrário dos atributos que chamamos de
armazenados.
NÚMERO
BAIRRO
RUA
ENDEREÇO
D. NASCIMENTO
NOME TELEFONE
IDADE
FUNCIONÁRIO
14
ð Atributos derivados são representados graficamente por uma oval de bordas

pontilhadas.
Os valores correspondentes dos atributos de duas entidades não podem ser todos
iguais. A lista de atributos de um conjunto de entidades deve ser suficiente para
caracterizar completamente qualquer entidade do conjunto. Essas considerações nos
levam ao conceito de atributo-chave:
o Atributo-chave
Tipo de atributo cujos valores são distintos para cada entidade em um conjunto de
entidades. O RG de um funcionário, por exemplo, constitui um atributo-chave para o
tipo de entidades FUNCIONÁRIO. Algumas vezes, um conjunto de atributos pode
formar uma chave. Mais do que isso, alguns tipos de entidades podem ter mais que um
atributo-chave.
NÚMERO
BAIRRO
RUA
ENDEREÇO
TELEFONE
NOME
Nº DO RG
CPF FUNCIONÁRIO RG
ÓRGÃO EXP.
ð O nome do atributo chave de um tipo de entidade geralmente aparece

sublinhado.
ð No gráfico temos a representação de dois atributos-chave para o conjunto de
entidade funcionário; sendo um composto(RG) e outro simples(CPF).
4.3 – Relacionamentos
Ao definir as entidades componentes de um diagrama entidade relacionamento,

nota-se vários relacionamentos implícitos entre elas. Sempre que um atributo de um tipo
de entidade refere-se a um outro tipo de entidade, temos um relacionamento entre as
entidades.
Um conjunto de relacionamentos inclui um número qualquer de relacionamentos
similares, ou relacionamentos do mesmo tipo. Por relacionamentos do mesmo tipo
entende-se relacionamentos que associam os mesmos tipos de entidades.
15
TELEFONE NOME
ENDEREÇO
FUNCIONÁRIO TRABALHA NO DEPARTAMENTO
NOME
NÚMERO
ð Na representação acima temos o relacionamento entre o funcionário e o

departamento no qual ele trabalha.
ð Conjunto de relacionamentos são representados por meio de losangos, contendo
o nome do tipo de relacionamento, conectados aos conjuntos de entidades cujos
elementos ele associa.
Ä Os relacionamentos estão associados às definições de grau, atributos e papéis em

um relacionamento.
o Grau de um relacionamento
O grau de um relacionamento corresponde ao número de diferentes tipos de

entidades que dele participam. Os relacionamentos mais comuns são aqueles de grau
dois (relacionamentos binários). O tipo de relacionamento Trabalha NO, por exemplo,
possui grau dois.
FORNECEDOR FORNECE PROJETO
PEÇA
ð Um exemplo de tipo de relacionamento ternário é FORNECE, que associa os

tipos de entidades FORNECEDOR, PEÇA e PROJETO.
16
o Atributos de um relacionamento
Assim como no caso das entidades, relacionamentos também podem possuir certos
atributos. O número de horas que um funcionário trabalha em um projeto, por exemplo,
pode ser visto como um atributo do relacionamento DESENVOLVE.
FUNCIONÁRIO DESENVOLVE PROJETO
HORAS
o Papéis em um relacionamento
Um relacionamento pode associar entidades do mesmo tipo (relacionamentos

recursivos ou auto-relacionamentos). Nesse caso, é necessário o conceito de papel da
entidade no relacionamento. Ele corresponde a função que uma entidade cumpre dentro
de um relacionamento. O relacionamento SUPERVISIONA, corresponde a um
relacionamento recursivo que associa duas entidades de funcionários, uma no papel de
supervisor e outra no papel de supervisionado.
ENDEREÇO
TELEFONE SUPERVISOR
FUNCIONÁRIO SUPERVISIONADO
NOME SUPERVISIONADO
ð Graficamente, o papel das entidades encontra-se representado nas arestas

ligando o relacionamento ao conjunto de entidades.
Ä Relacionamentos normalmente obedecem algumas restrições determinadas pela

aplicação sendo projetada. São elas:
17
o Cardinalidade de um relacionamento(Binário)
Determina o número de relacionamentos dos quais uma entidade pode participar. O

relacionamento do tipo TRABALHA NO, por exemplo, possui cardinalidade N:1. Ou
seja, 1 departamento está associado com (ou emprega) vários funcionários, mas um
funcionário pode trabalhar em um único departamento. Além da N:1, relacionamentos
podem possuir cardinalidades 1:1, 1:N e N:M. Um exemplo de relacionamento 1:1 é o
GERENCIA, o qual relaciona um (único) departamento com o (único) funcionário que
o gerencia. Um exemplo de relacionamento M:N é o DESENVOLVE, que associa
vários funcionários a vários projetos.
TELEFONE NOME
ENDEREÇO
1 1
FUNCIONÁRIO GERENCIA DEPARTAMENTO
NOME
NÚMERO
ð Cardinalidades são representadas graficamente pelos número 1, M e N junto as

arestas que relacionam os conjuntos de entidades.
ð Representação gráfica de um relacionamento de cardinalidade 1:1.
o Restrição de Participação
Determina se a existência de uma entidade está condicionada ou não ao seu

relacionamento com outra entidade. Existem dois tipos de restrições de participação:
total e parcial. Na primeira, uma entidade existe somente quando ela se relaciona com
outra entidade via um relacionamento. Se a política da empresa determina, por exemplo,
que todo funcionário deve trabalhar em um departamento, então a participação de
FUNCIONÁRIO em TRABALHA NO é total. Caso contrário se a existência de uma
entidade independe do fato dela estar relacionada com outra, tem-se uma restrição de
participação parcial. A participação de FUNCIONÁRIO em DESENVOLVE, por
exemplo, é parcial. Ou seja, nem todo funcionário precisa desenvolver um projeto
dentro da empresa.
18
TELEFONE NOME
ENDEREÇO
FUNCIONÁRIO TRABALHA DEPARTAMENTO

NO
NOME
NÚMERO
ð A restrição de participação total é representada graficamente por meio de linhas

duplas ligando o conjunto de entidades ao conjunto de relacionamentos. Já a
participação parcial é representada por meio de linhas simples.
4.4 - Entidade Fraca
Tipo de entidade que depende de outra entidade para existir.

Tipos de entidades que não possuem atributos chaves são denominados de fracas,
diferente dos tipos de entidades que possuem (ao menos um) atributo-chave,
denominadas entidades fortes (ou regulares). Entidades pertencentes a um tipo de
entidade fraca são identificadas por seus atributos e suas relações com entidades
especificas de um outro tipo de entidade.
Esse último tipo de entidade é dito proprietário ou identificante. Um tipo de
entidade fraca sempre atende a restrição de participação total no seu relacionamento
com o tipo de entidade identificante. Isso porque uma entidade fraca não pode ser
identificada unicamente sem uma entidade forte correspondente.
Considere como exemplo o tipo de entidade DEPENDENTE que se relaciona com
FUNCIONÁRIO. Ela é utilizada na modelagem dos dependentes de cada funcionário
via um relacionamento 1:N. Os atributos de DEPENDENTE são Nome e Parentesco
(com o funcionário). Dois dependentes de dois funcionários distintos podem ter o
mesmo nome e relacionamento, mas ainda ser entidades distintas. Eles são identificados
como tal apos a determinação da entidade funcionário em particular com o qual cada
dependente esta relacionado.
Um tipo de entidade fraca tem, normalmente, uma chave parcial. Ela corresponde ao
conjunto de atributos que pode identificar unicamente as entidades fracas relacionadas a
mesma entidade proprietária. No exemplo acima, o atributo Nome do dependente é
chave parcial.
Entidades fracas são representadas por meio de retângulos com bordas duplas.
Relacionamentos envolvendo entidades fracas são representadas por meio de losangos
com bordas duplas. E, normalmente, chaves parciais são sublinhadas com linhas
pontilhadas.
19
NOME
TELEFONE
ENDEREÇO
FUNCIONÁRIO POSSUI DEPENDENTES
NOME
PARENTESCO
4.5 - Modelo Entidade Relacionamento Extendido
O modelo ER extendido inclui todos os conceitos do modelo Entidade

Relacionamento mais os de subclasse / superclasse e especialização / generalização
relacionados.
Em muitos casos, um conjunto de entidades inclui vários subconjuntos que
necessitam ser representados explicitamente dada a significância de cada um deles na
aplicação sendo desenvolvida. As entidades do tipo FUNCIONÁRIO, por exemplo,
podem ser agrupadas em SECRETÁRIO, ENGENHEIRO, TÉCNICO, etc.
O conjunto de entidades em cada um desses grupos corresponde a um subconjunto
das entidades em FUNCIONÁRIO. Em outras palavras, toda entidade em um desses
grupos também é um funcionário. Cada um desses grupos é chamado de subclasse do
tipo de entidade FUNCIONÁRIO. O tipo de entidade FUNCIONÁRIO, por sua vez, é
dito superclasse de cada uma das subclasses. Uma entidade da subclasse e da
superclasse representam a mesma entidade do mundo real. Uma entidade “João
Fernando" do tipo SECRETÁRIO, por exemplo, é também o funcionário “João
Fernando". Uma entidade não pode existir na base de dados como sendo membro
apenas de uma subclasse. Entretanto, não é necessário que toda entidade em uma
superclasse seja membro de alguma subclasse. Vale observar que uma entidade membro
de uma subclasse herda todos os atributos da entidade membro correspondente da
superclasse.
4.5.1 - Especialização e Generalização
Especialização é o processo de definir um conjunto de subclasses de um tipo de

entidade. O conjunto de subclasses que formam uma especialização é definida com base
em alguma(s) característica(s) que distingue as entidades da superclasse. O conjunto de
subclasses SECRETÁRIO, ENGENHEIRO e TÉCNICO, por exemplo, é uma
especialização da superclasse FUNCIONÁRIO onde a diferenciação entre os
funcionários faz-se por meio do tipo de emprego de cada entidade.
20
Uma especialização é representada diagramaticamente por meio de linhas ligando as

subclasses que definem a especialização a um circulo que, por sua vez, esta ligado por
uma linha à superclasse. Além disso, tem-se o símbolo de contido em cada uma das
linhas que conecta as subclasses à superclasse indicando a "direção" da especialização.
Atributos que se aplicam somente a entidades de uma subclasse em particular
encontram-se associados aos retângulos representando aquela subclasse. Esses atributos
são chamados de atributos específicos da classe. Similarmente, uma subclasse pode
participar de relacionamentos específicos. É o caso, por exemplo, de técnicos que
ministram cursos.
O processo inverso ao da especialização, ou seja, o processo onde suprimimos as
diferenças entre vários tipos de entidades, identificamos suas características em comum
e as generalizamos em uma única superclasse é chamado de generalização. Por
exemplo, os tipos de entidades CARRO DE PASSEIO e CAMINHÃO podem ser
generalizados no tipo de entidade VEÍCULOS.
NÚMERO
BAIRRO
RUA
ENDEREÇO
NOME
TELEFONE
CPF FUNCIONÁRIO
GRAU ESCOLAR
TÉCNICO SECRETÁRIA ENGENHEIRO
DATA NASC. TIPO
MINISTRA
CURSO
ð Representação de uma especialização de Funcionário.
21
4.6 – Operações:
Exemplos de algumas operações para atualização de bases de dados relacionais:
o Insert
A operação Insert prove uma lista de valores de atributos de uma nova tupla a ser
inserida em uma relação.
Exemplo: Insert <José, 68760317502, 09/09/1979, 2> em FUNCIONÁRIO.
o Delete
A operação Delete executa a remoção de uma ou mais tuplas especificadas por meio
de condições associadas a determinados atributos da relação.
Exemplo: Delete a tupla de FUNCIONÁRIO com CPF = '68760317502’.
o Update
A operação Update modifica os valores de um ou mais atributos de uma tupla de

uma certa relação. Aqui também a tupla é especificada por meio de condições
associadas a determinados atributos da relação.
Exemplo: Update o CPF da tupla de FUNCIONÁRIO com CPF = '68760317502'
para '79871428613'.
Cada uma das três operações acima pode violar uma ou mais restrições de
integridade. A operação Insert, por exemplo, pode violar quatro restrições integridade
(de domínio, de chave, de integridade e de integridade referencial). Quando isso
ocorre, é comum rejeitar a inserção da nova tupla. Com relação a operação Delete, ela
pode violar a restrição de integridade referencial. Quando isso ocorre, ou a operação de
remoção é rejeitada ou propagada por meio da remoção das tuplas que referenciam a
tupla inicialmente removida.
Assim como a Insert, a operação Update também pode violar as quatro restrições de
integridade citadas.
5.0 - Tipos de Sistemas Gerenciadores de Banco de Dados
5.1 - dBASE
dBASE foi o primeiro SGBD largamente utilizado industrialmente, pelo Apple II,
Apple Macintosh e PC's IBM para DOS, onde se tornou um dos softwares mais
vendidos durante alguns anos. O dBASE nunca conseguiu migrar com sucesso para a
plataforma Microsoft Windows, e foi, em alguns casos, substituído por novos produtos,
como Paradox, Clipper, FoxPro e Microsoft Access. dBase foi vendido para a Borland
em 1991, que vendeu os direitos da linha de produtos, em 1999, para a recém-formada
dBASE Inc.
22
A partir de meados dos anos oitenta, muitas outras companhias produziram seus
próprios "dialetos" ou variações do produto e da linguagem. Entre esses, estão: FoxPro
(atual Visual FoxPro), Arago, Force, Recital, dbFast, dbXL, QuickSilver, Clipper,
xBase++, FlagShip e Harbour. Todos foram chamados de xBase.
O formato de arquivo do dBase, o DBF, é muito usado por diversos aplicativos que
precisam somente de um formato para armazenar seus dados estruturadamente.
A licença do dBase foi entregue aos usuários com a validade de 50 anos,
prevenindo-se contra a improvável chance de um usuário utilizar sua cópia do dBase
por um extenso período de tempo.
Ä Origens
O desenvolvedor original do dBase foi Wayne Ratliff. Em 1978, enquanto

trabalhava no Jet Propulsion Laboratory, Ratliff escreveu um programa de banco de
dados em linguagem assembly para microcomputadores rodando CP/M para ajudá-lo a
ganhar uma aposta realizada no escritório sobre quem seria o ganhador de um
campeonato de futebol. O programa foi baseado no JPLDIS (Jet Propulsion Laboratory
Display Information System) de Jeb Long e intitulado "Vulcan", em homenagem ao Sr.
Spock de Jornada nas Estrelas. De acordo com Ratliff, a linguagem utilizada no JPLDIS
era uma linguagem simples, orientada a comandos, que objetivava o uso interativo em
terminais de impressão. Existem alguns indícios de que JPLDIS foi influenciado por um
produto de banco de dados de mainframe chamado RETRIEVE.
No final dos anos 1980, George Tate, da Ashton-Tate, firmou um contrato de
marketing com Ratliff. Vulcan foi renomeado para dBase, e o software rapidamente se
tornou um grande sucesso.
Ä A linguagem de programação dBASE
Depois deportar o Vulcan para o IMSAI 8080 e depois para o CP/M e MS-DOS
(como dBase), Ratliff adicionou comandos para acomodar a interface de vídeo, bem
como comandos mais avançados para controle de fluxo (tais como DO WHILE /
ENDDO) e lógica condicional (tais como IF / ENDIF).
Para manipulação de dados, dBase oferecia comandos e funções procedurais
sofisticados para abrir e pesquisar arquivos (p.ex: USE, SKIP, GO TOP, GO BOTTOM,
e GO recno), manipular o valor de campos (REPLACE e STORE), e manipular strings
(p.ex.: STR() e SUBSTR()), números e datas. Sua capacidade de abrir e manipular
simultaneamente diversos arquivos contendo dados relacionados levou a Ashton-Tate a
rotular o dBase como uma "base de dados relacional", muito embora o produto não
atendesse os critérios definidos pelo modelo relacional do Dr. Edgar F. Codd.
O dBase era uma linguagem interpretada, que permitia ao usuário executar
comandos digitando-se em uma linha de comando. Digitando um comando e
pressionando a tecla Entra, o interpretador imediatamente iria executá-lo. De maneira
similar, programas (arquivos texto com extensão PRG) rodavam em um interpretador
(com o comando DO), onde cada comando e variável eram processados em tempo de
execução. Isso fazia com que os programas dBase fossem simples e rápidos de escrever
e testar porque os programadores não tinham que primeiro compilá-los antes de
executá-los. (Em outras linguagens, esses passos eram tediosos nos tempos das CPUs
com apenas algumas dezenas de megahertz). O interpretador também gerenciava
automaticamente e dinamicamente a memória (não havia pré-alocação de memória nem
23
notação hexadecimal), o que, mais do que outras funcionalidades, tornava possível para
um usuário sem experiência de programação desenvolver aplicações.
Por outro lado, a facilidade de uso e a simplicidade apresentada pelo dBase começou
a se tornar uma limitação à medida que seus usuários tornavam-se mais especializados e
programadores profissionais eram chamados para utilizá-lo. Aplicações mais complexas
e mais críticas demandaram funcionalidades de programação profissional para maior
robustez e desempenho, bem como maior produtividade do programador.
Com o tempo, os competidores da Ashton-Tate introduziram os chamados produtos
e compiladores "clones", que introduziam funcionalidades de programação mais
robustas, tais como funções definidas pelo usuário (UDFs) para complementar as
funções básicas contidas no produto, variáveis com escopo definido, com menor
possibilidade de serem afetadas por processos externos, arrays para manuseio de dados
complexos, funcionalidades de empacotamento para a entrega de aplicações na forma de
arquivos executáveis sem interpretadores em tempo de execução, sintaxe orientada a
objeto, e interfaces para o acesso aos dados de gerenciadores de bancos de dados
externos. A Ashton-Tate também implementou diversas dessas funcionalidades, com
graus variáveis de sucesso. A Ashton-Tate e seus competidores também começaram a
incorporar SQL, a linguagem padrão ANSI/ISO para criação, alteração e recuperação de
dados armazenados em SGBDs.
No final dos anos 1980, grupos de desenvolvedores criaram um padrão para a
linguagem dBase (IEEE 1192). Foi então que a linguagem passou a ser chamada de
"Xbase" para distinguí-la do produto da Ashton-Tate. Centenas de livros foram escritos
sobre programação dBase e Xbase.
Atualmente, implementações da linguagem dBase incluem muitas funcionalidades
direcionadas para aplicações de negócios, incluindo a manipulação de interface de
usuário gráfica (GUI), manipulação de dados remotos e distribuídos, uso da Internet e
interação com dispositivos modernos. A despeito de sua funcionalidade e facilidade de
uso, o legado da linguagem dBase de ter sido "embutida" dentro de um produto
comercial popular é uma das razões pela qual ela não é um padrão dominante hoje em
dia.
Ä Formato de arquivo .dbf
Um dos maiores legados do dBase é seu formato de arquivo .dbf, que foi
amplamente adotado.
O sistema de banco de dados dBase foi um dos primeiro a prover uma seção de
cabeçalho (header) para descrever a estrutura dos dados dentro do arquivo. Isso
significa que o programa não mais necessitava conhecimento avançado da estrutura de
dados, mas poderia perguntar diretamente ao arquivo de dados como este estava
estruturado.
24
5.2 - MySQL
Ä História do MySQL
O MySQL surgiu a partir da necessidade da equipe que criou o SGBD, de utilizar

algum mecanismo que permitisse a conexão de tabelas criadas na linguagem SQL para
um determinado fim. A princípio, o grupo iria utilizar o mSQL, mas logo perceberam
que esta ferramenta não era rápida o suficiente para atender às necessidades do projeto.
O jeito foi criar uma solução própria. Nascia o MySQL.
O MySQL foi criado por Michael Widenius na companhia suíça TcX. Por volta de
1979 Michael desenvolveu um banco de dados chamado UNIREG, sendo rescritos em
várias linguagens desde então" . Em 1994, a empresa TcX começou o desenvolvimento
de aplicações baseadas na Web, tendo como base o banco UNIREG, porém esse banco
possuía muito "overhead" para obter sucesso em uma aplicação para geração de páginas
dinâmicas na Web. Então a empresa TcX começou a procurar por outro banco o mSQL,
uma ferramenta baseada em SQL mas com características pobres não possuindo por
exemplo suporte a índices, e com desempenho inferior ao UNIREG.
Foi então que o desenvolvedor do banco UNIREG contatou o David Hughes criador
do mSQL, para saber do interesse dele em unir os dois bancos. Sendo positivo o
interesse de David , a empresa TcX resolveu desenvolver um novo banco, mas
mantendo ao máximo a compatibilidade com mSQL. TcX foi esperta o suficiente para
não reinventar o que já estava bem feito, ela construiu seu servidor baseado na estrutura
que já estava montada do UNIREG e utilizou grande número de utilitários escritas para
mSQL e fez API's para o novo servidor praticamente iguais ao mSQL. Como resultado
usuários do mSQL que decidissem mudar para o novo servidor da TcX, teriam apenas
que fazer pequenas e simples mudanças nos códigos existentes.
Então foi em maio de 1995 que, definitivamente, a primeira versão do MySQL foi
lançada. Um dos parceiros da TcX sugeriu a distribuição do servidor na Internet, o
objetivo disso era a utilização de um modelo pioneiro desenvolvido por Aladdin Peter
Deutsch. O resultado foi um maior flexibilidade em sem "copyright", que fez do
MySQL mais difundido gratuitamente do que mSQL.
25
Ä O Banco de Dados MySQL
Desenvolvido pela TCX em 1996. Atualmente a MySQL AB desenvolve o

programa. MySQL AB é a companhia dos fundadores e principais desenvolvedores do
MySQL. Eles criaram-no porque precisavam de um banco de dados relacional que
pudesse tratar grandes quantidades de dados em máquinas de custo relativamente
barato. O MYSQL é um dos bancos de dados relacionais mais rápidos do mercado,
apresenta quase todas as funcionalidades dos grandes bancos de dados . MySQL é uma
linguagem simples, em que você facilmente pode gravar, alterar e recuperar
informações num web site com segurança e rapidez O MYSQL é executado,
principalmente, em sistemas que participam da filosofia UNIX, embora outros sistemas
S.O também fornecem suporte, como Windows, por exemplo.
O MYSQL é um sistema de gerenciamento de banco de dados relacional
multiencadeado, de código fonte aberto e nível corporativo. O MySQL não é apenas um
banco de dados, mas sim um gerenciador de banco de dados. Com este SGBD (Sistema
Gerenciador de Banco de Dados), também pode ser utilizado para aplicações
corporativas, o qual, necessitam de varias conexões simultâneas, que possibilita 101
conexões simultâneas. Uma conexão é o tempo que leva para o usuário receber o dado
solicitado.
MySQL é a solução robusta para quase todo tipo de aplicação, combine a
estabilidade do MySQL com seu baixo custo de propriedade e rapidamente você irá
considerá-lo indispensável. O MySQL oferece o melhor cenário de todos SGBD,
executa em muitas plataformas, oferece um baixo TCO (custo total de propriedade) e é
muito estável .
O MySQL é um sistema de gerenciamento de bancos de dados relacional.
Um banco de dados relacional armazena dados em tabelas separadas em vez de
colocar todos os dados um só local. Isso proporciona velocidade e flexibilidade.
O Servidor MySQL foi desenvolvido originalmente para lidar com bancos de dados
muito grandes de maneira muito mais rápida que as soluções existentes e tem sido
usado em ambientes de produção de alta demanda por diversos anos de maneira bem
sucedida. Apesar de estar em constante desenvolvimento, o Servidor MySQL oferece
hoje um rico e proveitoso conjunto de funções. A conectividade, velocidade, e
segurança fazem com que o MySQL seja altamente adaptável para acessar bancos de
dados na Internet.
O Programa de Banco de Dados MySQL é um sistema cliente/servidor que consiste
de um servidor SQL multitarefa que suporta acessos diferentes, diversos programas
clientes e bibliotecas, ferramentas administrativas e diversas interfaces de programação
(API's). Também concedemos o Servidor MySQL como uma biblioteca multitarefa que
você pode ligar à sua aplicação para chegar a um produto mais rápido, menor e mais
facilmente gerenciável.
26
Ä Características do MySQL
o Multi-plataforma, portanto suporta diferentes plataformas: Win32, Linux,

FreeBSD, Unix, etc...
o Suporte a múltiplos processadores
o Um sofisticado sistema de senhas criptografadas flexível e Seguro.
o Suporta até 16 índices por tabela
o Código fonte escrito em C e C++ e testado com uma variedade de diferentes
compiladores
o As tabelas criadas podem ter tamanho de até 4 GB
o Banco de dados de código aberto e gratuito
o Suporte às API´s das Seguintes linguagens: PHP, Perl, C,C++,Java, Pynthon,
etc...
o Suporte à ODBC, você pode facilmente conectar o Access a um banco de dados
do MySQL
o O Cliente conecta no MySQL através de conexões TCP/IP.
o Nenhum problema com o Y2K, visto que o MySQL usa o relógio do Unix que
não apresentará problemas até 2069
o Capacidade para manipular bancos com até 50 milhões de registros
o Reduz a administração, engenharia e a sustentação custa por até 50%.
Ä Segurança no MySQL
O MySQL possuí componentes de segurança contra ameaças externas como

crackers e outros, e também proteger os dados dos próprios usuários. O mysql apresenta
vários níveis de segurança em relação ao acesso. Todas as informações de segurança
estão armazenadas no banco mysql,
A filosofia de segurança em banco de dados refere-se a fornecer ao usuário apenas o
que é essencial para o seu trabalho.
Ä O MySQL é gratuito?
Pessoas confundem "free" com "grátis" o que é comum aqui no Brasil. Mas em se
tratando de software este "free" é de open source e não gratuito. Para poder utilizar o
MySQL sob a licença GPL e não precisar pagar, o produto desenvolvido precisa ser
GPL também, senão, orientamos a compra da licença comercial, com baixo custo, sendo
comercializada por servidor, sem limites de usuários e processadores e ainda com
garantia perpétua de atualização de versão para o resto da vida.
27
Ä O MySQL é um banco de dados departamental?
O MySQL é regido pela licença GPL, portanto é open source. Muitas e analisarmos o
investimento necessário para aquisição do mesmo, podemos dizer que cabe como uma
solução departamental. Entretanto o que muitos assustam é que empresas como Nasa,
Cisco, Telefônica da Suécia, Yahoo Finance, Nokia e outras mais tem utilizado o
MySQL em aplicações de missão crítica.
Ä COMANDOS
Todo comando SQL termina com um ' ; '.
o CREATE DATABASE
Cria um banco de dados. Este comando cria uma área lógica, diretório, onde estarão
armazenadas todas as tabelas do banco de dados.
Ex: mysql>CREATE DATABASE funcionários;
o DROP DATABASE
Apaga um banco de dados.

Ex: mysql>DROP DATABASE funcionários;
o CREATE TABLE
Comando utilizado para criar tabelas.

Ex: mysql>CREATE TABLE alunos (matricula UNSIGNED INT(10) NOT NULL,
nome CHAR(40) NOT NULL,turma CHAR(20) NOT NULL,
PRIMARY KEY (matricula));
o ALTER TABLE
Altera Tabela
Ex: mysql>ALTER TABLE alunos ADD COLUMN turno char(10) NOT NULL
o DROP TABLE
Apaga uma tabela.

Ex: mysql>DROP TABLE alunos;
o INSERT
Comando utilizado para inserir valores numa tabela.

Ex: mysql>INSERT INTO alunos(matricula,nome,turma,turno)values
(127423,'Fred Cox Junior','Eng. Eletrônica','Manhã');
28
o SELECT
Comando usado para recuperar valores de uma tabela. Este poderoso comando, em
conjunto com funções, possibilita a recuperação de qualquer valor de uma tabela.
Ex: mysql>SELECT * FROM alunos where nome='Fred Cox Junior';
mysql>SELECT matricula,turno FROM alunos ORDER BY matricula asc;
o DELETE
Apaga registros em uma tabela. Se não for especificada a condição where, todos os
dados serão apagados.
Ex: Mysql>DELETE FROM alunos WHERE turno='Manhã';
o UPDATE
Altera dados numa tabela.

Ex: mysql>DROP TABLE alunos;
5.3 - PostgreSQL
O PostgreSQL é um banco de dados relacional e orientado a objetos. Seu grande

triunfo é possuir recursos comuns à banco de dados de grande porte, o que o deixa apto
a trabalhar, inclusive, com operações de missão crítica. Além disso, trata-se de um
banco de dados versátil, seguro e gratuito.
É possível utilizar o PostgreSQL em vários sistemas operacionais, dentre os quais o
Windows, Linux, BSDs ou em qualquer sistema compatível com as especificações
POSIX (Portable Operating System Interface). Segundo informações do site oficial, o
PostgreSQL permite a criação de uma base de dados de tamanho infinito. Cada tabela
pode ter até 16 TB, sendo que cada linha pode ter até 1,6 TB e cada campo 1 GB. O
banco de dados ainda conta com conexões SSL, MVCC, triggers, integridade
referencial, entre outros recursos, além de ser compatível com uma série de linguagens,
tais como PHP, Python, Java, Perl, etc.
O uso do PostgreSQL é muito amplo, pois várias empresas perceberam que com ele
podem criar bases de dados complexas sem a necessidade de gastar altos valores na
29
aquisição de licenças. Outra vantagem, é que o PostGreSQL possui uma documentação

muito abrangente, o que permite suporte adequado às necessidades. Uma das empresas
que são citadas como exemplo do uso deste banco de dados é a Afilias, entidade
responsável por manter e registrar domínios .org na Internet.
Breve história do PostgreSQL
O PostgreSQL teve seu início na University of California at Berkeley, no ano de
1986, onde Michael Stonebraker liderou um projeto para a criação de um servidor de
banco de dados relacionais, chamado de Postgres. Essa tecnologia foi então comprada
pela Illustra, empresa posteriormente adquirida pela Informix. Porém, mesmo diante
disso, dois estudantes de Berkeley (Jolly Chen e Andrew Yu) compatibilizaram o
Postgres à linguagem SQL (Structured Query Language). Este projeto recebeu o nome
de Postgres95. Em 1996, quando o projeto estava estável, o banco de dados recebeu o
nome de PostgreSQL. No entanto, enquanto ainda possuia o nome Postgres95, o banco
de dados teve várias mudanças. O seu código foi totalmente revisado e a linguagem
SQL foi definida como padrão.
O banco de dados PostgreSQL é mantido por várias pessoas do mundo,
principalmente por colaboradores dos Estados Unidos, Canadá, Rússia e Japão. Neste
grupo, estão empresas que patrocinam o projeto, pesquisadores de universidades e
companhias de computação.
PostgreSQL x MySQL
Ambos os bancos de dados são eficientes e gratuitos. A grande dúvida que surge, é
saber qual desses SGBDs utilizar para certas aplicações. Como o PostgreSQL foi criado
para ter vários recursos e assim proporcionar suporte a tarefas complexas, seu uso é
mais indicado em aplicações com grande volume de dados ou que tratam de
informações críticas, onde o banco de dados é grande, ou seja, possui uma quantidade
alta de tabelas e campos. Assim, para uma loja de comércio eletrônico, por exemplo,
cujo volume de pedidos é alto, o PostgreSQL é muito eficiente para tratar dos dados.
O MySQL, por sua vez, tem como foco a agilidade. Assim, se sua aplicação
necessita de respostas rápidas e não é complexa, o MySQL é uma escolha muito
interessante, pois sua otimização permite velocidade alta de processamento e tempo
curto de resposta. Se você precisa de um banco de dados para trabalhar com o conteúdo
do seu site, fórum, cadastro de usuários, entre outros, o MySQL é uma escolha
adequada. Isso porque aplicações como estas não necessitam dos recursos sofisticados
que o PostgreSQL oferece, por exemplo.
Para escolher entre um destes dois SGBDs, primeiro procure o foco de cada um.
Como já dito, o PostGreSQL busca oferecer recursos avançados. O foco principal do
MySQL é a agilidade. Assim, analise primeiro os recursos de que vai precisar. Se baseie
no seguinte exemplo: você não precisa comprar um ônibus se sua família pode muito
bem ser transportada num carro de 5 lugares. A grande resposta da questão é verificar
quais os recursos necessários e escolher o SGBD que melhor se adapta a eles. Se você
escolher o PostgreSQL para operações simples, poderá perder tempo e desperdiçar
recursos. Da mesma forma, se escolher o MySQL para aplicações de porte maior,
poderá ter problemas com o gerenciamento dos dados.
30
5.4 - Oracle
O sistema gerenciador de banco de dados Oracle surgiu no final dos anos 70,
quando Larry Ellison vislumbrou uma oportunidade que outras companhias não haviam
percebido, 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.
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 Oracel 10g, mais recente, se baseia na tecnologia de grid.
Além do base de dados, a Oracle desenvolve uma suíte de desevolvimento chamada
de Oracle Developer Suite, utilizada na construção de programas de computador que
interagem com a sua base de dados.
A Oracle também criou a linguagem de programação PL/SQL, utilizada no
processamento de transações.
5.5 - Microsoft SQL Server
Criado pela Microsoft, o MS SQL Server é um gerenciador de Banco de dados

relacional. É um Banco de dados, muito robusto e usado muito em empresas e por
grandes sistemas corporativos. Atualmente encontra-se na versão 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 tem versões unicamente para as diversas versões do sistema
operacional Windows, da Microsoft, ao contrário do seu grande concorrente, Oracle,
que funciona em diversas plataformas e sistemas operacionais diferentes.
Suas ferramentas de gerenciamento são nativas, não necessitando que sejam
adquiridas separadamente. São elas : MS SQL Enterprise Manager (Console Central
que integra num único painel, a maioria das funções que um DBA poderá utilizar-se
para configurar e gerenciar esse RDBMS, o Query Analyzer que permite executar
querys e auxilia o gerenciamento, inclusive em Tunning, o Profile que é uma espécie de
Trace, descortinando os comandos que o gerenciador está executando, além de outras
ferramentas.
31
5.6 - Microsoft Access
O Microsoft Access (Microsoft Office Access), também conhecido por MSAccess, é

um sistema relacional de administração de banco de dados da Microsoft, incluído no
pacote do Microsoft Office Professional, que combina o Microsoft Jet Database Engine
com uma interface de usuário gráfica. Ele permite o desenvolvimento rápido de
aplicações que envolvem tanto a modelagem e estrutura de dados como também a
interface a ser utilizada pelos usuários.
Microsoft Access é capaz de usar dados guardados em Access/Jet, Microsoft SQL
Server, Oracle, ou qualquer recipiente de dados compatível com ODBC.
Desenvolvedores de software e arquitetos de dados experientes costumam usá-lo para
desenvolver complexos e potentes programas de aplicação.
O desenvolvimento da estrutura de dados se dá de forma muito intuitiva, bastando
que o desenvolvedor possua conhecimetos básicos em modelagem de dados e lógica de
programação.
Programadores relativamente inexperientes e usuários determinados podem usá-lo
para construir aplicações simples, sem a necessidade de utilizar ferramentas
desconhecidas. O programa oferece suporte substancial para técnicas de orientação-
objeto (OO), porém não chega a ser uma ferramenta completa de desenvolvimento OO.
Ä Utilização
Geralmente uma aplicação desenvolvida com o Access através da linguagem de

programação VBA (Visual Basic for Applications) consiste em dois arquivos, um que
se denomina BackEnd, onde ficam armazenadas todas as tabelas com seus respectivos
relacionamentos, e outro denominado FrontEnd, onde ficam armazenados os códigos
fontes, formulários, módulos, consultas, macros, etc.
O código fonte pode ser compilado, mas não é possível gerar um executável. Para
rodar os aplicativos desenvolvidos é necessário que o usuário possua em sua estação de
trabalho o MSAccess instalado ou pelo menos o seu Runtime que vem a ser uma versão
enxuta do MSAccess que servirá apenas para rodar os aplicativos sem a possibilidade de
desenvolvimento.
Com o Microsoft Access é possível desenvolver desde aplicações simples como por
exemplo, um cadastro de clientes, controle de pedidos até aplicações mais complexas,
como por exemplo, todo o controle operacional, administrativo e financeiro de uma
pequena ou até mesmo de uma média ou grande empresa, pois os aplicativos
desenvolvidos podem rodar perfeitamente em uma rede de computadores e os dados
armazenados pelo sistema podem ser publicados na Intranet ou até mesmo na Internet.
Access é pouco escalável se o acesso aos dados for feito via uma rede, portanto
qualquer aplicação que seja usado por mais de um punhado de pessoas tende à depender
em soluções com base no Cliente-Servidor. Porém, um Access do tipo "front end" (as
formas, os relatórios, pedidos de busca e códigos VB) pode ser usado paralelamente à
diversos tipos de "back ends", incluindo o próprio Access, o Microsoft SQL Server, o
Oracle ou qualquer outro produto compatível com ODBC. Esse método permite ao
desenvolvedor a mudança dos dados de uma aplicação madura para um servidor mais
avançado sem sacrificar o projeto em andamento.
32
Ä Características
Um dos benefícios do Access é sua relativa compatibilidade com o SQL – buscas

podem ser visualizadas e editadas como sendo indicações de SQL, e estes por sua parte
podem ser usados diretamente em Macros e Módulos VBA para manipular tabelas do
próprio Access. Usuários podem misturar e usar ao mesmo tempo VBA e Macros para
formulários de programação e lógica, além de serem oferecidos possibilidades com
técnicas de orientação-objeto.
A função "cortar e colar"(cut and paste) do Access pode torná-lo uma ferramenta
útil para a conexão entre diversos bancos de dados (por exemplo, entre o Oracle e o
Microsoft SQL Server durante conversões de dados ou bancos de dados).
Access disponibiliza várias funções de exportação e importação (import and export),
que permitem a integração entre o Windows e outras aplicações de plataforma, muitas
das quais podem ser executadas dentro das próprias aplicações ou manualmente pelo
usuário.
A partir do MS Access 2000, há uma sintaxe que permite a criação de pedidos de
busca com parâmetros, semelhante à criação de procedimentos armazenados, porém tais
procedimentos são limitados à uma declaração por procedimento.
O Microsoft Access permite que formulários contenham códigos que são ativados à
medida que mudanças são feitas à uma tabela subjacente (contanto que as modificações
são feitas apenas com aquele formulário), e é comum usar buscas "pass-through" e
outras técnicas no Access para ativar procedimentos armazenados em RDBMSs que
suportam este tipo de sistema.
Em arquivos de projeto de banco de dados do Access ADP (suportado em MS
Access 2000 e adiante), as ferramentas relacionadas aos bancos de dados são
completamente diferentes, uma vez que este tipo de arquivo é conectado ao MSDE ou
ao Microsoft SQL Server, ao invés de usar o motor Jet. Deste modo, ele suporta a
criação de quase qualquer objeto no servidor subjacente (tabelas com restrições e
gatilhos, visualizações, procedimentos armazenados e UDF's).
Contudo apenas formulários, relatórios, macros e módulos são armazenados no
arquivo ADP (outros objetos são armazenados no banco de dados "back end").
Ä Desenvolvimento
A linguagem de programação disponível no access é a Microsoft Visual Basic for

Applications, igualmente à outros produtos da série Microsoft Office.
Duas bibliotecas de componentes COM de acesso de banco de dados são
providenciadas: a legacy Data Access Objects (DAO), apenas disponível com o Access,
e o novo ActiveX Data Objects (ADO).
Microsoft Access é facilmente aplicado à projetos pequenos porém sofre problemas
de escala com projetos maiores se as aplicações forem mal desenvolvidas.
Todas as buscas no banco de dados, formulários e relatórios são armazenados no
banco de dados, e visando os ideais de um modelo relacional, não há possibilidade de
montar uma hierarquia estruturada fisicamente a partir deles.
Uma técnica de desenvolvimento é dividir uma aplicação Access entre dados e
programas. Um banco de dados deve conter apenas tabelas e relações, enquanto outro
contém todos os programas, formulários, relatórios e pedidos de busca, assim como as
conexões para as tabelas do primeiro banco de dados.
33
Infelizmente, o Access não permite trilhas quando são feitas as conexões, e o

ambiente de desenvolvimento deve ter a mesma trilha do ambiente de produção, embora
seja possível escrever sua própria rotina de "conexão dinâmica" em VBA, que pode
procurar um arquivo "back end" específico através de uma pesquisa dentro da árvore do
diretório, se não puder encontrá-lo no caminho atual.Esta técnica também permite que o
desenvolvedor divida a aplicação entre arquivos diferentes, sendo então possível uma
certa estrutura.
5.7 - Data Warehouse
O que é um Data Warehouse?
Um data warehouse (ou armazém de dados, ou depósito de dados) é um sistema de

computação utilizado para armazenar informações relativas às atividades de uma
organização em bancos de dados, de forma consolidada. Caracteriza-se de um ambiente
estruturado, extensível, projetado para a análise de dados não voláteis, lógica e
fisicamente transformados, provenientes de diversas aplicações, alinhados com a
estrutura da empresa, atualizados e mantidos por um longo período de tempo.
Antes da popularização dos data warehouse e das ferramentas ERP (Enterprise
Resource Planning), uma verdadeira integração dos dados não existia, pois os antigos
“sistemas integrados” trocavam dados na forma que atendesse ás necessidades de cada
um deles, mas essa pequena integração sequer se aproxima do que se vê hoje nos ERP.
Cada aplicativo tinha uma visão do que era um cliente, um produto ou uma operação,
uma visão corporativa das informações disponiveis era praticamente ficção.
A ERP e o data warehouse podem suprir estas deficiencias, integrando dados,
provendo dados históricos, e permitindo a recuperação de informações de forma
sintética ou analítica.
O data warehouse possibilita a análise de grandes volumes de dados, coletados dos
sistemas transacionais . São as chamadas séries históricas que possibilitam uma melhor
análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a
previsão de eventos futuros. Por definição, os dados em um data warehouse não são
voláteis, ou seja, eles não mudam, salvo quando é necessário fazer correções de dados
previamente carregados. Os dados estão disponíveis somente para leitura e não podem
ser alterados.
Ä Características
Um sistema de Data Warehouse possui quatro características básicas:
o Organizado por Temas
Um DW orientado por temas armazena informações sob a forma de assuntos

diferentes entre si e que são considerados importantes para o negócio da empresa.
Alguns exemplos de temas utilizados em projetos deste tipo são: produtos, atividades,
contas, clientes, etc.
Nos projetos de sistemas tipicamente transacionais há uma organização norteada por
aplicações funcionais. Num hospital, por exemplo, temos os sistemas de admissão de
pacientes (internação), o sistema de faturamento, o sistema de controle de estoque,
controle de infecção hospitalar, entre muitos outros. Estes sistemas estão organizados
34
pela função desempenhada por cada setor a fim de suprir as necessidades de controle
das informações do dia a dia da entidade.
o Integrado
A integração do DW diz respeito à consistência de denominações, das unidades dos

valores contidos nas tabelas e outras padronizações aplicadas aos dados no sentido de
que estes sejam transformados até estarem num estado uniforme.
Um exemplo clássico refere-se à variável sexo do paciente. Em uma determinada
aplicação transacional podemos ter codificado o sexo do indivíduo com "M" para
masculino e "F" para feminino, já em outra aplicação podemos representar este item
com "1" para masculino e "0" para feminino, chegando até mesmo a uma terceira
configuração com "H" para homens e "M" para mulheres. Este último caso poderia
acarretar em uma duplicidade de dados que não podem ser considerados iguais, que é o
caso do "M" que tanto pode representar Mulheres como o sexo Masculino.
À medida que os dados são carregados no DW, é necessário convertê-los para um
estado uniforme, ou seja, codificar a variável sexo com apenas um formato, por
exemplo, "M" para masculino e "F" para feminino.
A padronização ou integração serve para fornecer uma maior confiabilidade nas
comparações que serão feitas durante as análises solicitadas pelos usuários do sistema
de DW.
o Variante no Tempo
Os dados contidos num DW são temporais, ou seja, referem-se a períodos de tempo

bem definidos, e isto auxilia na análise e na confirmação de acontecimentos sazonais
dentro de uma determinada atividade ou ramo de negócio.
As séries temporais empregam características específicas ao ambiente do DW que
deve ser programado para permitir o gerenciamento dos dados representativos da
coexistência de intervalos de tempo com informações que serão analisadas e
comparadas constantemente. Muitas vezes é possível verificar a presença em sistemas
de processamento analítico os dados representativos de dias e meses, sendo necessário
controlar por exemplo o número de dias contidos em um mês ou em um ano, em que dia
da semana está o primeiro dia do mês ou ainda quantas semanas tem o mês ou o ano.
o Não Volátil
Um sistema de DW deve permitir apenas uma carga inicial dos dados e

posteriormente oferecer estes mesmos dados para consultas dos usuários. Este ambiente
é conhecido por "load-and-access" (carga e acesso). Os dados integrados e
transformados são carregados para o DW na forma de blocos de informações, ficando à
disposição dos usuários para consultas e comparações. Já no ambiente operacional
temos uma situação diferente: os dados são atualizados de forma atômica, registro a
registro, em várias transações durante todo o tempo de uso das aplicações.
Para assegurar a integridade e confiabilidade dos dados são necessárias diversas
operações como rollback, recuperação de falhas, commits e bloqueios. Os controles
tradicionais dos sistemas orientados a transações não são necessários em DWs uma vez
que os dados carregados são quase sempre oriundos daqueles sistemas e,
conseqüentemente, já passaram pelo crivo de controle.
35
Ä Arquitetura de armazenamento
Um Data Warehouse pode armazenar grandes quantidades de informação, às vezes

divididas em unidades lógicas menores que são chamadas de Data Marts. O esquema de
dados mais utilizado é o ‘’Star Schema’’ (Esquema Estrela), também conhecido como
Modelagem Multidimensional. Apesar de bastante utilizado, não existe um padrão na
indústria de software para o armazenamento de dados. Existem, na verdade, algumas
controvérsias sobre qual a melhor maneira para estruturar os dados em um Data
Warehouse.
Geralmente, o Data Warehouse não armazena informações sobre os processos
correntes de uma única atividade de negócio, mas sim cruzamentos e consolidações de
várias unidades de negócios de uma empresa.
Ä Modelagem
Os sistemas de base de dados tradicionais utilizam a padronização no formato de

dados para garantir consistência dos dados e uma minimização do espaço de
armazenamento necessário. Entretanto, frequentemente as transações e consultas em
bases de dados normalizadas são lentas. Um Data Warehouse utiliza dados em formato
mais de-normalizados (formato livre). Isto aumenta a performance das consultas e,
como benefício adicional, o processo torna-se mais intuitivo para os utilizadores
usuários comuns.
5.7.1 – Metadado
O conceito Metadado é considerado como sendo os "dados sobre dados", isto é, os

dados sobre os sistemas que operam com estes dados. Um repositório de metadados é
uma ferramenta essencial para o gerenciamento de um Data Warehouse no momento de
converter dados em informações para o negócio. Entre outras coisas, um repositório de
metadados bem construído deve conter informações sobre a origem dos dados, regras de
transformação, nomes e alias, formatos de dados, etc. Ou seja, esse "dicionário" deve
conter muito mais do que as descrições de colunas e tabelas: deve conter informações
que adicionem valor aos dados.
Ä Tipo de Informação considerada Metadado
Os metadados são utilizados normalmente como um dicionário de informações e,

sendo assim, devem incluir:
o Origem dos dados
Todo elemento de dado precisa ser identificado, sua origem ou o processo que o
gera. Esta identificação é muito importante no caso de se necessitar saber informações
sobre a fonte geradora do dado. Esta informação deve ser única, ou seja, cada dado deve
ter uma e somente uma fonte de origem.
36
o Fluxo do dado
Todo elemento de dado precisa ter identificado os fluxos nos quais sofre
transformações. É importante saber que dados servem de base para que processos.
o Formato dos dados
Todo elemento de dados deve ter identificado seu tamanho e tipo de dado.
o Nomes e alias
Todo elemento de dados deve ser identificado por um nome. Este nome pode ser da
‘área de negócios’ ou um nome técnico. No caso de serem usados alias para os nomes,
pode-se ter os dois. Devem existir padrões para criação de nomes e alias (ex.:
convenções para abreviações), evitando assim ambigüidades.
o Definiçôes de negócio
Estas definições são as informações mais importantes contidas nos metadados. Cada
elemento de dado deve ser suportado por uma definição do mesmo no contexto da ‘área
de negócio’. O método de manutenção destas informações também deve ser muito
consistente, de forma que o usuário possa obter facilmente definições para as
informações desejadas. Nestas definições devem ser evitadas referências a outros
metadados que necessitem de uma segunda pesquisa para melhor entendimento.
o Regras de transformação
São consideradas como sendo as Regras de Negócio codificadas. Estas regras são
geradas no momento da extração, limpeza e agrupamento dos dados dos Sistemas
Operacionais. Cada regra de transformação codificada, deve estar associada a um
elemento de Metadado. Se mais de uma aplicação contiver a mesma regra de
transformação, deverá ser garantido que estas sejam idênticas.
o Atualização dos dados
O histórico das atualizações normalmente é mantido pelo próprio banco de dados,

mas ter definido um elemento de metadado indicando as datas de atualização dos dados,
pode facilitar o usuário no momento de verificar a atualidade dos dados e a consistência
da dimensão tempo do Data Warehouse.
o Requisitos de teste
Identifica os critérios de julgamento de cada elemento de dado. Valores possíveis e

intervalos de atuação. Deve conter também padrões para procedimentos de teste destes
dados.
37
o Indicadores de qualidade de dados
Podem ser criados índices de qualidade, baseados na origem do dado, número de

processamentos feito sobre este dado, valores atômicos X valores sumariados, nível de
utilização do dado etc.
o Triggers automáticos
Podem existir processos automáticos associados aos metadados definidos. Estes

processos ou triggers devem estar definidos de forma que possam ser consultados por
usuário e desenvolvedores, para que os mesmos não venham a criar situações
conflitantes entre as regras definidas nestes processos.
o Responsabilidade sobre informações
Deve ser identificado o responsável por cada elemento de dados do Data Warehouse
e também o responsável pela entrada de metadados.
o Acesso e segurança
Os metadados devem conter informação suficiente para que sejam determinados

perfis de acesso aos dados. Deve-se poder identificar que usuários podem ler, atualizar,
excluir ou inserir dados na base. Deve haver também informações sobre quem gerencia
estes perfis de acesso e como se fazer contato com o Administrador da Base de Dados.
5.7.2 - Data Mart
Data mart (entreposto ou bazar de dados) é sub-conjunto de dados de um Data

warehouse (armazém de dados). Geralmente são dados referentes a um assunto em
especial (ex: Vendas, Estoque, Controladoria) ou diferentes níveis de sumarização (ex:
Vendas Anual, Vendas Mensal, Vendas 5 anos), que focalizam uma ou mais áreas
específicas. Seus dados são obtidos do DW, desnormalizados e indexados para suportar
intensa pesquisa. Data marts extraem e ajustam porções de DWs aos requisitos
específicos de grupos/departamentos.
As questões de planejamento, projeto e implementação são as mesmas encontradas
em qualquer fase da implementação de um DW, pois uma parte dos especialistas
argumenta que o DW é uma evolução natural de um Data Mart que começou localizado
e cresceu para atender um escopo maior. Essa visão tem defesa menos técnica e mais
intuitiva do que sua contra-parte: o Data Mart é criado a posteriori do DW, pois ele seria
montado com dados extraídos do DW para atender especificamente um setor da
organização.
Numa visão comparativa dos dados, onde consideramos os quesitos escopo,
integração, tempo, agregação, análise e dados voláteis, percebemos que a diferença está
no escopo, pois enquanto o DW é feito para atender uma empresa como um todo, o data
mart é criado para atender um sub-conjunto da empresa. Repare que atender um sub-
conjunto da empresa pode significar reunir dados de outros setores, já que, na prática,
raramente um único setor possui ou gera toda informação que precisa. Vem dessa
observação a defesa da tese de que o Data Mart é construído após o DW.
38
Não se pode dizer que um Data warehouse é um conjunto de Data Marts. Seria o
mesmo que dizer que o armazém geral de um supermercado, onde todos os itens vão
antes de seguir para as lojas, é o agrupamento de supermercados.
Ä Extração de Dados
Os dados introduzidos num Data Warehouse geralmente passam por uma área
conhecida como área de stage. O stage de dados ocorre quando existem processos
periódicos de leitura de dados de fontes como sistemas OLTP. Os dados podem passar
então por um processo de qualidade, denormalização e gravação dos dados no Data
Warehouse. Esse processo geralmente é realizado por ferramentas ETL.
Ä OLAP
OLAP é um acrônimo em inglês para Online Analytical Processing, ou

processamento analítico on-line. É uma abordagem tecnológica para gerar respostas
rápidas a consultas analíticas de natureza tipicamente dimensional. A tecnologia OLAP
é parte de uma categoria mais abrangente, Business intelligence, que também inclui
Data warehouse, ETC (Extração transformação e carga) e Data mining. Aplicações
típicas de OLAP são relatórios de negócios, marketing, relatórios gerenciais, business
performance management (BPM), budgeting e previsão, relatórios financeiros e áreas
similares. O termo OLAP foi criado como uma ligeira variação de um termo tradicional
em bancos de dados, OLTP (On Line Transaction Processing, ou processamento de
transações on-line).
Bases de dados mais adequadas para OLAP empregam um modelo de base de dados
dimensional, que permite consultas analíticas complexas ou ad-hoc, com um tempo de
execução pequeno. Nigel Pendse sugeriu que um termo alternativo e talvez mais
descritivo para o conceito de OLAP seja Fast Analysis of Shared Multidimensional
Information, (Análises Rápidas de Informação Multidimensional Compartilhada). A
FASMI empresta aspectos de bancos de dados navegacionais e de bancos de dados
hierárquicos, que são mais rápidos que seu semelhante relacional.
Funcionamento
Um software OLAP trabalha tomando uma "foto" da fonte de dados e
reestruturando-a em um cubo OLAP. As consultas são então feitas sobre esse cubo. Já
foi afirmado que, para consultas complexas, um software OLAP pode dar uma resposta
em cerca de 0,1% do tempo gasto pela mesma consulta feita em bases de dados
relacionais usadas em sistemas OLTP.
O cubo é criado a partir de um esquema estrela (star schema) de tabelas. No centro
está a tabela de fatos (fact table) que lista os fatos principais de que consiste a pesquisa.
Várias tabelas dimensionais estão ligadas às tabelas de fatos. Estas tabelas indicam
como as agregações de dados relacionais podem ser analisadas. O número de
agregações possíveis é determinado por todas as maneiras possíveis em que os dados
originais podem ser conectados hierarquicamente.
Por exemplo, um conjunto de clientes pode ser agrupado por cidade, por distrito ou
por país; com 50 cidades, 8 distritos e 2 países, há três níveis hierárquicos com 60
membros. Esses clientes podem ser estudados em relação a produtos; se há 250
produtos com 20 categorias, três famílias e três departamentos, então há 276 membros
de produto. Com apenas duas dimensões, localização geográfica e produto, há 16.560
39
agregações possíveis. À medida que os dados considerados aumentam, o número de

agregações pode facilmente chegar às dezenas de milhões ou mais.
O cálculo de agregações e a base de dados combinada fazem um cubo OLAP, que
pode potencialmente conter todas as respostas para cada consulta que pode ser
respondida com os dados. Devido ao potencial número de agregações para ser
calculado, freqüentemente apenas um número predeterminado é completamente
calculado enquanto o restante é resolvido sob demanda.
Ä Tipos de OLAP
Há três tipos de OLAP:
o OLAP Multidimensional
MOLAP é a forma clássica do OLAP e algumas vezes é referida como

simplesmente OLAP. MOLAP usa estruturas de bancos de dados que são atributos
genéricos otimizados, como período de tempo, localidade, produto ou código de conta.
A forma como cada dimensão vai ser agregada é definida a priori por uma ou mais
hierarquias.
o OLAP Relacional
ROLAP trabalha diretamente com bancos de dados relacionais. Os dados e as

tabelas de dimensões são armazenadas como tabelas relacionais e novas tabelas são
criadas para receber a informação agregada.
o OLAP Híbrido
Não há consenso claro na indústria sobre o que é "OLAP Híbrido", exceto que um
banco de dados vai dividir dados entre armazenamento relacional e especial. Para
alguns fornecedores, por exemplo, um banco de dados HOLAP usa tabelas para manter
as grandes quantidades de dados detalhados, e um armazenamento especializado para
pelo menos alguns aspectos dos dados das quantidades menores, que são menos
agregadas ou detalhadas.
Ä Comparação entra os tipos:
Cada tipo tem suas características, apesar de não haver consenso sobre os detalhes
dos benefícios entre os fornecedores. MOLAP é melhor com pequenas bases de dados,
calcula rapidamente as agregações e repostas e precisa de menos espaço de
armazenamento.
ROLAP é considerado mais escalável. Entretanto, é difícil implementar
eficientemente um pré-processamento para grandes volumes e por isso é frequentemente
deixado de lado. A performance das consultas ROLAP pode, portanto, sofrer com
grandes volumes.
HOLAP está entre os dois em todas as áreas, mas tem um pré-processo rápido e
escalona bem. Todos os tipos estão sujeitos à explosão de bases de dados. Esse
fenômeno causa a alocação de grandes volumes de memória pelas bases OLAP, quando
certas (e frequentes) condições são satisfeitas: grande número de dimensões, resultados
pré-calculados e dados multidimensionais esparsos. A dificuldade em implementar
40
OLAP vem da formação das consultas, da escolha dos dados de base e do

desenvolvimento do esquema(-estrela). Como resultado disso, muitos dos modernos
produtos OLAP vêm com vastas bibliotecas de consultas pré-configuradas. Outro
problema é a qualidade do conjunto dos dados de base: ele deve ser completo e
consistente.
Ä OLTP versus OLAP
Os termos OLTP (on-line transaction processing – processamento on-line de

transações) e OLAP (on-line analytical processing – processamento analítico on-line)
descrevem o modo de processamento de cada uma das componentes da divisão proposta
para os sistemas de Bancos de Dados.
Bancos de dados operacionais atingem proporções de centenas de megabytes e até
mesmo gigabytes. Consistência e capacidade de recuperação de dados são críticas, e a
maximização do poder de processar transações é requerida para minimizar os problemas
que podem ser causados pela concorrência de processos.
Analisando sistemas OLAP, sistemas que dão apoio à decisão, pode-se notar o
contraste com OLTP. No caso do processamento analítico deve-se dar maior
importância aos dados históricos, totalizados e consolidados em detrimento dos dados
detalhados ou individualizados.
Uma vez que os DW contêm dados referentes a longos períodos de tempo, estes
podem atingir dimensões muito maiores do que os bancos de dados operacionais,
chegando a conter centenas de gigabytes e até mesmo terabytes de informações.
A tabela ilustra as diversidades apresentadas pelos dois tipos de sistemas, DW e
Bancos de Dados Operacionais:
Diferenças entre os tipos de sistemas.
Características BDs Operacionais DW

Objetivo Operações diárias do negócio Analisar o negócio
Uso Operacional Informativo
Tipo de processamento OLTP OLAP
Unidade de trabalho Inclusão, alteração, exclusão Carga e consulta
Número de usuários Milhares Centenas
Tipo de usuário Operadores Comunidade gerencial
Interação do usuário Somente pré-definida Pré-definida e ad-hoc
Condições dos dados Dados operacionais Dados Analíticos
Volume Megabytes – gigabytes Gigabytes – terabytes

Histórico 60 a 90 dias 5 a 10 anos
Granularidade Detalhados Detalhados e resumidos
Redundância Não ocorre Ocorre
41
Características BDs operacionais DW
Estrutura Estática Variável

Manutenção desejada Mínima Constante
Acesso a registros Dezenas Milhares
Atualização Contínua (tempo real) Periódica (em batch)
Integridade Transação A cada atualização
Número de índices Poucos/simples Muitos/complexos
Intenção dos índices Localizar um registro Aperfeiçoar consultas
Ä Business intelligence
O termo "Business Inteligence (BI)", pode ser traduzido como "Inteligência de

negócios", refere-se ao processo de coleta, organização, análise, compartilhamento e
monitoração de informações que oferecem suporte a gestão de negócios.
o Processo Empresarial
As organizações tipicamente recolhem informações com a finalidade de avaliar o

ambiente empresarial, completando estas informações com pesquisas de marketing,
industriais e de mercado, além de análises competitivas. Organizações competitivas
acumulam "inteligência" à medida que ganham sustentação na sua vantagem
competitiva, podendo considerar tal inteligência como o aspecto central para competir
em alguns mercados.
Geralmente, os coletores de BI obtêm as primeiras fontes de informação dentro das
suas empresas. Cada fonte ajuda quem tem que decidir a entender como o poderá fazer
da forma mais correta possível. As segundas fontes de informação incluem as
necessidades do consumidor, processo de decisão do cliente, pressões competitivas,
condições industriais relevantes, aspectos económicos e tecnológicos e tendências
culturais. Cada sistema de BI determina uma meta específica, tendo por base o objetivo
organizacional ou a visão da empresa, existindo em ambos objetivos, sejam eles de
longo ou curto prazo.
o Tecnologia de BI
Alguns observadores consideram que o processo de BI realça os dados dentro da

informação e também dentro do conhecimento. Pessoas envolvidas em processos de BI
podem usar softwares ou outras tecnologias para obter, guardar, analisar, provendo
acesso aos dados, seja ele simples ou de muito uso. O software "cura" a performance de
gerenciamento do negócio e ajuda no alvo das pessoas tomarem as melhores decisões
pela exatidão, atuais e relevantes com as informações viáveis a quem quiser quando for
necessário. Algumas pessoas utilizam o termo "BI" intercâmbiando ele com "livros de
reunião" ou "sistemas de informações executivas", de acordo com a informação que
42
cada um contém. É nesse sentido, que cada pode considerar um sistema de BI como um
sistema de suporte para tomada de decisão (decision-support system).
o Tipos de software
As pessoas que trabalham com o BI tem que desenvolver ferramentas em cada caso,
especificadamente quando a inteligência envolve recolhimento e análise de largas
quantidades de dados desestruturados. Existem inúmeros softwares para gerenciamentos
destas informações, em diversas categorias. Uma pesquisa nas ferramentas de busca da
internet podem trazer diversas informações sobre cada um destes programas.
5.7.3 - O que é o Data Mining?
È o processo de descoberta de novas correlações, padrões e tendências entre as

informações de um empresa, através da análise de grandes quantidades de dados
armazenados em um banco de dados usando técnicasde reconhecimento de padrões,
estatísticas e matemáticas.
As duas ultimas décadas acompanharam um aumento dramático na quantia de
informações ou dados que são armazenados em formato eletrônico. Esta acumulação de
dados aconteceu a uma taxa explosiva. Esses dados crus raramente tem benefícios
diretos. Seu valor verdadeiro é verificado na habilidade de extrair informações úteis
para suporte de decisão ou exploração e atender o fenômeno do gerenciamento de fonte
de dados.
O armazenamento de dadosficou mais fácil com a grande capacidade computacional
a baixo custo, isto é, o custo da capacidade de processamento e armazenamento sofreu
sensível queda. Houve também a introdução de novos métodos de aprendizado de
máquina para representação do conhecimento baseado em programação lógica, além da
tradicional análise estatística dos dados.
Tendo concentrado muita atenção no armazenamento de dados o problema passou a
ser o que fazer com esse recurso valioso? Foi reconhecido que a informação esta no
coração de operações empresariais e que empresários poderiam fazer uso dos dados
armazenados e assim obter sucesso no ramo dos negócios. Sistemas de administração de
banco de dados deram acesso aos dados armazenados, mas essa era só uma pequena
parte do que poderia ser obtido dos dados. Sistemas tradicionais de processamento de
transações on-line, OLTPs, são ferramentas boas no que se refere a repor dados
rapidamente, seguramente e eficazmente em banco de dados mas não são boas para
retornar uma análisesignificativa relativa aos dados.
Dados analisados podem prover conhecimento adicional sobre um negócio, indo
explicitamente além dos dados armazenados, para derivar conhecimento sobre o
negócio. Isto é onde o Data Mining tem benefícios obvios para qualquer
empreendimento.
O Data Mining se preocupa com a análise dos dados e com o uso de tecnicas de
software responsáveis por achar padrões e regularidades no conjunto de dados. È o
computador que é o responsável por achar os padrões identificando as regras
subjacentes e as características nos dados. A idéia é que é possível achar ouro em
lugares inesperados, tal como os softwares de data mining extraem padrões não
previamente encontrados ou tão obvios que nenhum os notou antes.
Análise de data mining tende a trabalhar nos dados e as melhores tecnicas são essas
desenvolvidas com uma orientação para volumes grandes de dados e fazem uso de
43
muito dos dados colecionados como ´possíveis a chegar á conclusão fidedignas e

decisões.O processo de análise começa com um conjunto de dados, usa-se uma
metodologia para desenvolver uma otima representação da estrutura dos dados durante
o tempo em que o conhecimento é adquirido. Uma vez que o conhecimento foi
adquirido, isto pode ser estendido a conjuntos maiores de dados que trabalham na
suposição de que o conjunto de dados maior tem uma estrutura semelhante aos dados da
amostra.
Os seguintes requisitos resumem alguns dos processos do Data Mining. As fases
descritas a seguir começam com os dados crus e terminam com o conhecimento
extraído que era adquirido como resultado das fases seguintes:
o Seleção
Selecionando ou segmentando os dados de acordo com algum critério, por exemplo

todas as pessoas que possuem um carro, deste modo subconjuntos dos dados podem ser
determinados.
o Pré-processamento
Esta é a fase de limpesa dos dados onde sertas informações são removidas desde que
sejam julgadas desnecessárias. Estas informações não pertinentes podem reduzir a
velocidade de “queries” como por exemplo é desnecessário notar o sexo de um paciente
quando está estudando gravidez. Também os dados são reconfigurados para assegurar
um formato consistente pois há uma possibilidade de formatos incompatíveis. Isto
porque os dados são tirados de várias fontes, como exemplo, sexo pode ser registrado
como “F” ou “M” e também como como “1” ou “0”.
o Transformação
Os dados não são somente transferidos mas transformados em dados úteis, tais como
dados demográficos comumente usados em pesquisas de mercado. Então os dados
tornam-se utilizáveis e navegáveis.
o Data Mining
Esta fase se preocupa com a extração de padrões de dados. Um padrão pode ser
definido como determinado conjunto de fatos(dados) F, uma linguagem L, e alguma
medida de certeza C. Um padrão é uma declaração S em L que descreve relações entre
conjuntos F’s de F com uma certeza C tal aquele S é mais simples em um sensação que
a enumeração de todos os fatos em F’s.
o Interpretação e avaliação
Os padrões identificados pelo sistema são interpretados em conhecimento que pode

então ser usado para apoiar decisões humanas como por exemplo classificar tarefas,
resumir os conteúdos de um banco de dados ou explicar fenômenos observados.
ð Os principais motivos que tem levado as empresas a investir nessa tecnologia

tem sido a obtenção de uma melhor visão sobre a extensão base de dados e a revelação
44
de relações implicítas e padrões entre os dados que nam sempre são visíveis através da
simples observação. Há três razões principais para se desenvolver um projeto em Data
Mining.
o Visualização dos dados
As empresas precisam da significado a uma quantidade cada vez maior de

informações em seus bancos de dados. Antes de realisar qualquer análise, o objetivo é
qualificar e armazenar os dados a serem trabalhados e encontrar novas formas de
visualiza-los de forma mais natural e transparente para os usuários.
o Descoberta de novos conhecimentos
A maior parte das aplicações atuais de DM se enquadram nesta tecnologia cujo o

objetivo é explicitar relacionamentos ocultos, padrões e correlações entre os diferentes
dados existentes no BD da empresa.
o Acuracidade dos dados
Muitas vezes as empresas descobrem que seus dados são imcompletos, errados ou
contraditórios. Decorre disso a necessidade de obter dados cada vez mais consistentes
para processamento e análise futura.
Exemplos práticos do Data Mining:
ð Um caso bem conhecido que identificou um hábito crioso dos consumidores ao

procurar eventuais relações entre o volume de vendas e dos dias da semana, o software
data mining apontou que ás sextas-feira, as vendas de cervejas cresciam na mesma
proporção que as de fraldas. Uma relação mais detalhada apontou que, ao comprar
fraldas para seus bebês, os pais aproveitavam para abastecer o estoque de cerveja para o
final de semana.
ð Para conseguir detectar fraudes, cortar gastos ou aumentar a receita da empresa.

O Bank of Americana usou essas técnicas para selecionar entre seus 36 milhões de
clientes aqueles com o menor risco de dar calote num emprestimo. A partir desses
relatórios, enviou cartas oferecendo linhas de crédito para os correntistas cujos filhos
tivessem entre 18 e 21 anos e, portando, precisassem de dinheiro para ajudar os filhos a
comprar o próprio carro, uma casa ou arcar com os gastos da faculdade. Resultado: em
três anos, o banco lucrou 30 milhões de dólares.
45
Ä Arquiteturas do Data Warehouse
Pode-se definir duas formas de apresentação da arquitetura de Data Warehouse, uma

conceitual e outra física do modelo relacional que representa o sistema.
o Visão Conceitual
ð Arquitetura do sistema de DW.
Além do DW podem existir vários Data Marts (DMs), que departamentalizam os

dados separando-os por setor dentro da organização.
Os dados contidos no DW e nos DMs são gerenciados por um ou mais servidores de
warehouse, os quais apresentam visões multidimensionais dos dados para uma
variedade de ferramentas front end.
A visão multidimensional em forma de cubo de dados indica que as informações são
visualizadas em linhas e colunas como o formato tradicional das planilhas, porém
existem mais dimensões, sendo que o cubo teria apenas mais uma dimensão. Esta
característica organiza e facilita a consulta aos dados de maneira que se pode ter, por
exemplo, numa dimensão do cubo os meses do ano, na segunda dimensão estariam as
cidades de origem dos clientes e na terceira dimensão o médico que encaminhou o
cliente para o hospital.
o Visão em Camadas
Camada de Bancos de Dados Operacionais e Fontes Externas: contém as bases de

dados operacionais e pode ser composta também de informações de fontes externas,
estes dados recebem um tratamento especial para poderem ser incorporados ao DW;
46
ð Arquitetura em camadas.
o Camada de Acesso aos Dados
Compõe o elo de ligação entre as ferramentas de acesso à informação e os bancos de

dados operacionais, comunicando-se com diversos Sistemas de Gerenciamento de
Banco de Dados (SGBDs) e sistemas de arquivos, sendo que a este conjunto de
características dá-se o nome de acesso universal de dados;
o Camada de Transporte ou Middleware
Tem a função de gerenciar a transmissão das informações pelo ambiente de rede que
serve de suporte para o sistema como um todo, separando as aplicações operacionais do
formato real dos dados, realiza ainda a coleta de mensagens e transações e se encarrega
de entregá-las nos locais e nos tempos determinados;
o Camada do Data Warehouse
Constitui-se do armazenamento físico dos dados oriundos dos sistemas operacionais

da empresa e externos, permitindo um acesso mais rápido e seguro aos dados do DW,
além de prover maior flexibilidade de tratamento e facilidade manipulação;
47
o Camada de Acesso à Informação
Proporciona a interação com os usuários finais através de ferramentas visuais

tradicionais, tais como sistemas de planilhas de cálculo, browsers, entre outras;
o Camada de Metadados (Dicionário de Dados)
Os metadados descrevem os dados e a organização do sistema, podem ser ainda

fórmulas utilizadas para cálculo, descrições das tabelas disponíveis aos usuários,
descrições dos campos das tabelas, permissões de acesso, informações sobre os
administradores do sistema, entre outras;
o Camada de Gerenciamento de Processos
Faz o controle destas tarefas que mantêm o sistema atualizado e consistente,

gerenciando as diversas tarefas que são realizadas durante a construção e a manutenção
dos componentes de um sistema de DW;
o Camada de Gerenciamento de Replicação
Serve para selecionar, editar, resumir, combinar e carregar no DW as informações a

partir das bases operacionais e das fontes externas, envolvendo programação bastante
complexa, sendo que existem ferramentas poderosas que permitem que estes processos
sejam gerenciados de forma mais amigável, além do controle da qualidade dos dados
que serão carregados.
o Estrutura Física dos Dados do D. W.
A respeito da disposição física dos dados, o DW pode ter uma estrutura centralizada
em um único local ou então ser implementado de forma distribuída. Se optarmos pelo
modelo centralizado, teremos um warehouse consolidado e o Banco de Dados formará
um DW integrado. Definindo o projeto desta forma pode-se maximizar o poder de
processamento e acelerar os processos de busca por informações analíticas.
Definindo-se uma arquitetura federativa, pode-se distribuir a informação por função,
separando os dados do setor financeiro em um servidor, os dados de marketing em outro
local, e dados de manufatura em um terceiro lugar.
Existe ainda uma terceira metodologia, na qual considera-se uma arquitetura de DW
separada por camadas, armazenando os dados mais resumidos em um servidor,
dispondo os dados um pouco mais detalhados, em nível de detalhe intermediário, em
um segundo servidor, e por fim colocamos os dados mais detalhados (atômicos) em um
terceiro servidor.
48
Ä Granularidade em camadas
O primeiro servidor geralmente atende à maior parte das consultas, sendo que
teremos um menor número de pedidos de acesso solicitados para a camada 2 e camada
3.
O dimensionamento dos servidores é o seguinte: na primeira camada podemos ter
uma configuração para suportar um grande número de usuários que farão diversas
consultas, as quais trabalharão com um volume relativamente pequeno de dados. Já os
servidores das outras duas camadas devem ser configurados para permitir processar
grandes volumes de dados, porém não é necessária uma preocupação em configurar o
sistema para suportar o acesso de um número maior de usuários. Isto explica-se pelo
fato de que a maioria dos usuários terá suas perguntas respondidas pelas consultas
iniciais da camada 1. Se algum usuário não se satisfizer com o nível de detalhe das
respostas da camada 1, pode buscar maiores informações na camada 2 e até mesmo na
camada 3. Concluímos então que poucos usuários farão acessos regulares à última
camada, sendo que alguns nunca o farão além do nível inicial.
o Arquitetura em duas camadas
Existe uma arquitetura de implantação de sistemas de DW que consiste em utilizar

um computador de alta capacidade como servidor. Este método disponibiliza aplicações
aos usuários finais na forma de ferramentas front end, que servem para realizar as
consultas, em conjunto com os componentes do servidor com ferramentas back end, que
servem para municiar o DW com informações.
Organizações que podem crescer com a incorporação de outras empresas do mesmo
ramo ou ainda de outro ramo de negócio, gradualmente acumulam diversos sistemas de
computação legados, cada um com suas incompatibilidades de definições dos dados.
Esta redundância e falta de consistência dos dados dificulta a administração das bases
de dados, resultando numa dificuldade também para desenvolver-se novas aplicações
front end.
49
Esta arquitetura pode ser chamada de "sistema guarda-chuva", a qual possui um

formato em que o cabo do guarda-chuva representa o servidor principal e as hastes
representam os sistemas de consulta a este servidor.
A arquitetura ilustrada pode ser usada para construir um sistema de DW em duas

camadas, o qual possui os componentes dos clientes (front end) e os componentes do
servidor (back end).
Esta arquitetura é bastante conveniente, uma vez que utiliza os sistemas já existentes
na empresa bem como os servidores de bancos de dados e requer um pequeno
investimento em hardware e software.
Um dos grandes problemas que existe neste tipo de arquitetura é o fato de não ser
permitido o seu escalonamento, o que resulta, com o aumento do número de usuários,
numa performance ruim pelo gargalo existente entre os clientes e o servidor. Estas
anomalias podem ocorrer pelo uso de estações clientes muito lentas e com muitos
processos rodando simultaneamente.
o Arquitetura de Três Camadas
Para tentar solucionar os problemas de performance resultantes do gargalo da

arquitetura de duas camadas, existe uma arquitetura de informação em múltiplas
camadas. Esta arquitetura é bastante flexível e suporta um grande número de serviços
integrados, onde a interface do usuário (ferramentas front end), as funções de
processamento do negócio e as funções de gerenciamento do BD são separadas em
processos, os quais podem ser distribuídos através da arquitetura de informação.
Este tipo de arquitetura em três camadas é bastante utilizado. Na primeira camada
ficam as aplicações de interface com os usuários, que devem ser gráficas e baseadas em
rede. Dados e regras de negócio podem ser compartilhados pela organização, assim
como o BD para o DW, ficam armazenados em servidores de alta velocidade na
segunda camada, a camada central. Na terceira e última camada estão localizadas as
fontes de dados.
50
Analisando o ambiente do DW, os servidores de BD e os servidores de aplicações

da camada central provêem um acesso eficiente e rápido aos dados compartilhados.
Com a separação dos servidores em transacional e analítico pode-se obter uma boa
performance nas consultas e no processamento, sendo que deve haver disponibilidade
de equipamentos e recursos satisfatórios de conexão entre os diversos componentes do
sistema.
6.0 - Alguns Conceitos Importantes

Ä A Linguagem SQL
Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma

linguagem de pesquisa declarativa para banco de dados relacional (bases de dados
relacionais). Muitas das características originais do SQL foram inspiradas na álgebra
relacional.
SQL é normalmente pronunciado em português como "esse-quê-ele", porém sua
pronúcia correta deveria se "síquel", do inglês "sequel", ou "alguma coisa que segue
outra coisa". SQL é uma brincadeira com o nome da primeira linguagem de consulta
QUEL.
Embora o SQL tenha sido originalmente criado pela IBM, rapidamente surgiram
vários "dialectos" desenvolvidos por outros produtores. Essa expansão levou à
necessidade de ser criado e adaptado um padrão para a linguagem. Esta tarefa foi
realizada pela American National Standards Institute (ANSI) em 1986 e ISO em 1987.
51
O SQL foi revisto em 1992 e a esta versão foi dado o nome de SQL-92. Foi revisto
novamente em 1999 e 2003 para se tornar SQL:1999 (SQL3) e SQL:2003,
respectivamente. O SQL:1999 usa expressões regulares de emparelhamento, queries
recursivas e gatilhos (triggers). Também foi feita uma adição controversa de tipos não-
escalados e algumas características de orientação a objeto. O SQL:2003 introduz
características relacionadas ao XML, sequências padronizadas e colunas com valores de
auto-generalização (inclusive colunas-identidade).
Tal como dito anteriormente, o SQL, embora padronizado pela ANSI e ISO, possui
muitas variações e extensões produzidos pelos diferentes fabricantes de sistemas
gerenciadores de bases de dados. Tipicamente a linguagem pode ser migrada de
plataforma para plataforma sem mudanças estruturais principais.
Outra aproximação é permitir para código de idioma processual ser embutido e
interagir com o banco de dados. Por exemplo, o Oracle e outros incluem Java na base de
dados, enquanto o PostgreSQL permite que funções sejam escritas em Perl, Tcl, ou C,
entre outras linguagens.
Ä Palavras-chaves em SQL
DML - Linguagem de Manipulação de Dados
Primeiro há os elementos da DML (Data Manipulation Language - Linguagem de

Manipulação de Dados). A DML é um subconjunto da linguagem usada para selecionar,
inserir, atualizar e apagar dados.
o SELECT
É o comumente mais usado do DML, comanda e permite ao usuário especificar uma

query como uma descrição do resultado desejado. A questão não especifica como os
resultados deveriam ser localizados.
o INSERT
É usada para somar uma fila (formalmente uma tupla) a uma tabela existente.
o UPDATE
Para mudar os valores de dados em uma fila de tabela existente.
o DELETE
Permite remover filas existentes de uma tabela.
o BEGIN WORK (ou START TRANSACTION, dependendo do dialeto SQL)
Pode ser usado para marcar o começo de uma transação de banco de dados que pode
ser completada ou não.
52
o COMMIT
Envia todos os dados das mudanças permanentemente.
o ROLLBACK
Faz com que as mudanças nos dados existentes desde que o último COMMIT ou
ROLLBACK sejam descartadas.
o COMMIT e ROLLBACK
Interagem com áreas de controle como transação e locação. Ambos terminam

qualquer transação aberta e liberam qualquer cadeado ligado a dados. Na ausência de
um BEGIN WORK ou uma declaração semelhante, a semântica de SQL é dependente
da implementação.
DDL - Linguagem de Definição de Dados
O segundo grupo é a DDL (Data Definition Language - Linguagem de Definição de

Dados). Uma DDL permite ao usuário definir tabelas novas e elementos associados. A
maioria dos bancos de dados de SQL comerciais tem extensões proprietárias no DDL.
Os comandos básicos da DDL são:
o CREATE cria um objeto (uma Tabela, por exemplo) dentro do base de dados.
o DROP apaga um objeto do banco de dados.
DCL - Linguagem de Controle de Dados
O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de

Dados). DCL controla os aspectos de autorização de dados e licenças de usuários para
controlar quem tem acesso para ver ou manipular dados dentro do banco de dados.
Duas palavras-chaves da DCL:
o GRANT - autoriza ao usuário executar ou setar operações.
o REVOKE - remove ou restringe a capacidade de um usuário de executar

operações.
DQL - Linguagem de Consulta de Dados
Embora tenha apenas um comando a DQL é a parte da SQL mais utilizada. O comando
SELECT é composta de várias cláusulas e opções, possibilitando elaborar consultas das
mais simples as mais elaboradas.
53
Ä Í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.
Ä Gatilho
Gatilho ou trigger é um recurso de programação presente na maioria dos sistemas de

gerenciamento de banco de dados, utilizado para associar um procedimento armazenado
a um evento do banco de dados (inclusão, exclusão, atualização de registro, por
exemplo) de modo que o procedimento armazenado seja executado automaticamente
sempre que o evento associado ocorrer.
54
CONCLUSÃO
O papel de um Banco de Dados dentro de uma empresa ou qualquer outro tipo de

organização é muito importante e fundamental para o andamento da mesma; pois nele
esta contido desde os dados dos seus clientes até a vida documental da própria empresa.
Para o gerenciamento de todas essas informações, temos no mercado diversos
softwares com grande capacidade para gerenciar com rapidez e grande performace
todos esses dados independente de sua plataforma de sistema operacional.
Dentre os sistemas gerenciadores podemos citar desde os mais robustos como o
ORACLE, SQL e até mesmo o MySQL que apesar de ser um SGBD gratuito tem uma
performace comparativa as outras.
Com todas essas ferramentas e o grande poder de gerenciamento das informações e
cruzamento das mesmas, precisamos apenas conhecê-las melhor para poder desfrutar de
todas as vantagens que elas podem nos proporcionar, utilizando-as no sentido lucrativo,
comercial ou para simples consultas como é o caso dos gerenciadores de banco de dados
que disponibilizam informações para a Internet.
55
BIBLIOGRAFIA
www.wikipedia.org
www.apostilando.com
www.maxarte.com.br/eduardocustodiohp/DataWareHouse.htm
Apostilas;
Material da Profª Luana Vachelli.
56

2362 - Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

2362 - Banco de Dados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2362 - Banco de Dados

Enviado por

Direitos autorais:

Formatos disponíveis

BANCO DE DADOS

Ä Conceito sobre Banco de Dados e SGBD’s

Saber o significado de um Banco de Dados e que o SGBD é um sistema que o

1.0 – Banco de Dados

O que é um Banco de Dados?

2.0 – Sistema Gerenciador de Banco de Dados

Um sistema Gerenciador de Banco de Dados ou Sistema Gestor de Base de Dados

2.1 - Os modelos de dados mais utilizados pelos SGBD’s são:

O modelo hierárquico foi o primeiro a ser reconhecido como um modelo de dados.

O modelo em rede surgiu como uma extensão ao modelo hierárquico, eliminando o

Modelo Orientado a Objetos

Os bancos de dados orientados a objeto começaram a se tornar comercialmente

Contudo, estes sistemas necessitam guardar representações das estruturas de dados

2.2 - Tipos de arquiteturas de SGBDs

Na arquitetura centralizada, existe um computador com grande capacidade de

Arquitetura do tipo Sistemas de Computador Pessoal – PC

Os computadores pessoais trabalham em sistema stand-alone, ou seja, fazem seus

Na arquitetura Cliente-Servidor, o cliente executa as tarefas do aplicativo, ou seja,

Banco de Dados Distribuídos (N camadas)

Nesta arquitetura, a informação está distribuída em diversos servidores. Cada

2.3 - Capacidades do SGBD

No processamento tradicional de arquivos, muitos grupos de usuários mantêm seus

SGBD’s multiusuários devem fornecer controle de concorrência para assegurar que

Restrições de Acesso Multiusuário

Fornecimento de Múltiplas Interfaces

Representação de Relacionamento Complexo entre Dados

Reforçar Restrições de Integridade

Muitas aplicações de base de dados terão certas restrições de integridade de dados.

Fornecer Backup e Restauração

3.0 - Arquiteturas de Banco de Dados

As primeiras arquiteturas usavam mainframes para executar o processamento

possuíam poder de processamento, apenas a capacidade de visualização. Todos os

3.1 - Aspectos relevantes

É necessário considerar alguns aspectos relevantes para atingir a eficiência e a

o Os projetos Lógico e Funcional do Banco de Dados devem ser capazes de prever

o Deve-se ter generalidade e alto grau de abstração de dados, possibilitando

o Implementação de um projeto de interface compatível com múltiplas

o Independência de Implementação da Interface em relação aos SGBDs que darão

o Conversão e mapeamento da diferença semântica entre os paradigmas utilizados

3.2 - Vantagens dos Bancos de Dados

o Potencial para obrigar a Padronização

A abordagem de base de dados permite que o DBA defina e obrigue a padronização

Mudanças na estrutura de uma base de dados podem ser necessárias devido a

o Redução do Tempo de Desenvolvimento de Aplicações

Uma das principais características de venda da abordagem de base de dados é o

o Disponibilidade de Informações Atualizadas

A abordagem de SGBD’s permite a consolidação de dados e de aplicações

3.3 - Linguagens de Base de Dados

o Linguagem de Definição de Dados (“Data Definition Language” - DDL): é

o Linguagem de Manipulação de Dados (“Data Manipulation Language” - DML):

4.0 - O que é Modelo de Dados?

4.1 - Modelo Entidade Relacionamento

O Modelo Entidade-Relacionamento é um modelo de dados conceitual de alto-nível,

4.2 - Entidades e atributos

ð Representação de uma entidade.

Um conjunto de entidades inclui um número qualquer de entidades similares, ou

ð Na representação acima temos um conjunto de Entidades e seus atributos.

4.2.1 - Tipos de Atributos

o Atributos Simples ou Atômicos