Matéria de apoio (Base de dados)

2.
2 Bases de Dados

• De uma forma genérica podemos dizer que uma base
de dados é um conjunto de dados relacionados,
acessíveis a uma comunidade de utilizadores
utilizadores.

• Desde tempos imemoriais o homem guardou em
armários, gavetas (...) os dados importantes relativos às
suas diversas actividades – as primeiras bases de
d e sas ac dades p e as
dados.

2

2.
2 Bases de Dados
• A partir d meados d século XX verificou-se um grande
ti de d do é l ifi d
crescimento das organizações o que provocou um
g
grande aumento no volume dos dados nelas utilizados.

• Ao mesmo tempo
p verificou-se um g
grande
desenvolvimento dos computadores, que se tornaram
mais acessíveis.

• Surge assim, de forma natural, a introdução dos
computadores nas organizações com o objectivo de
servir de suporte às bases de dados nelas existentes.

3

2.
2 Bases de Dados
• Numa primeira fase surgem os chamados Sistemas de
fase,
Ficheiros e só posteriormente são desenvolvidos os
Sistemas de Bases de Dados.

• Com ambos se pretende obter acesso rápido aos dados
gerando a informação necessária às diversas
actividades.

• O d d
Os dados são guardados em fi h i
d d ficheiros e a partir d l
i deles
são gerados relatórios com a informação pretendida.

• Actualmente, quando nos referimos a bases de dados,
queremos referir-nos às bases de dados em suporte
informático.
informático
4

2.
2 Bases de Dados

• Embora se possa considerar que os Sistemas de
Ficheiros estão desactualizados e que não fará sentido
abordá-los,
abordá los só se podem compreender as
potencialidades de um Sistema de Bases de Dados se
houver a compreensão dos Sistemas de Ficheiros, que
p ,q
os antecederam.

5

2.
2 Bases de Dados
• Neste capítulo iremos começar por abordar em 2 1 as
capítulo, abordar, 2.1,
raízes históricas das bases de dados, nomeadamente,
os Sistemas de Ficheiros.

• Em 2.2, veremos as características de um Sistema de
Bases de Dados e os seus intervenientes Abordaremos
intervenientes.
ainda alguns aspectos importantes de um Sistemas de
Gestão de Bases de Dados.

• Os modelos de Bases de Dados serão abordados em
2.3.

• Por fim, em 2.4, abordaremos algumas tendências de
evolução na área das bases de dados
dados.
6

2.1 As Raízes Históricas: Ficheiros e
Sistemas de Ficheiros
• Num Sistema de Ficheiros guardam-se diversos
registos, de forma permanente, em vários ficheiros.
• Existem também diversas aplicações ou programas que
permitem efectuar uma variedade de operações com
esses ficheiros: inserir dados, recuperar dados, alterar
dados e apagar dados (Figura I.2.1).
g ( g )

7

2.1.1 Gestão de dados nos Sistemas de
Ficheiros
• Os ficheiros de um Sistema de Ficheiros possuem uma
determinada estrutura física, que tem de ser conhecida
para que possa ser elaborada cada uma das aplicações
do sistema.
• Na figura I 2 2 apresenta-se um exemplo do ficheiro
I.2.2, apresenta se
Clientes, pertencente ao sistema de ficheiros
apresentado na figura I.2.1.

8

Ficheiros
Antes d
A t de avançarmos, vamos d fi i alguma
definir l
terminologia básica sobre ficheiros:

· Dado - factos em “bruto”, ou seja, a mais pequena
p
porção de dados q o computador reconhece; p
que p pode ser
um número, um caracter,...;
· Campo - um caracter ou conjunto de caracteres com um
significado específico como por exemplo um nome;
específico,
· Registo - um conjunto de um ou mais campos
relacionados, que descrevem uma pessoa, um lugar ou
um objecto (concreto ou abstracto);
· Ficheiro - conjunto de registos relacionados.
9

Ficheiros
Cada ficheiro presente no sistema de gestão de ficheiros
precisa, pelo menos, de cinco aplicações que permitam:

· Criar a estrutura do ficheiro;
· Adicionar d d ao fi h i
Adi i dados ficheiro;
· Eliminar dados do ficheiro;
· Modificar d d contidos no fi h i
M difi dados id ficheiro;
· Listar o conteúdo do ficheiro.

10

Ficheiros
Cada uma dessas aplicações envolve várias operações,
mais ou menos complexas. Por exemplo, para eliminar o
cliente Ana do ficheiro de clientes do exemplo será
Ana, exemplo,
necessário:

· Abrir o ficheiro de clientes;
· Procurar o registo relativo ao cliente Ana;
· Eliminar o registo encontrado;
· Fechar o ficheiro clientes
clientes.

11

Ficheiros
• Podemos, através deste exemplo simples, reconhecer a
dificuldade e morosidade existentes na implementação
de um sistema de ficheiros se pensarmos que todo este
ficheiros,
trabalho terá de ser multiplicado pelo número de
ficheiros existentes no sistema.

12

Ficheiros
• P outro l d a sua manutenção t bé é difí il
Por t lado, t ã também difícil.

• Consideremos novamente o exemplo da figura I 2 1I.2.1.
Depois de implementado o sistema, os gestores da
empresa onde ele foi implementado, consideram
p p
importante obter relatórios mensais, contendo
informações sobre os valores das encomendas
realizadas por cada um dos clientes
clientes.

• Passa a haver a necessidade de, em cada mês,
elaborar uma aplicação que possa produzir esse
relatório.

13

Ficheiros
• C f
Conforme se conseguem satisfazer
ti f algumas
l
necessidades surgem imediatamente novas
necessidades, o que implica a escrita de novas
, q p
aplicações.

• Muitas vezes torna-se incomportável fazer uma gestão
eficiente do sistema, devido ao elevado número de
aplicações necessárias à sua manutenção
manutenção.

14

Ficheiros
• Outro aspecto a ter em conta na gestão dos dados
prende-se com a integridade dos dados, isto é, os
valores guardados nos ficheiros devem satisfazer
determinadas regras – as restrições d i t id d
d t i d t i õ de integridade.

• No exemplo já apresentado considerando o ficheiro
apresentado,
encomendas, “só pode existir uma encomenda se
contiver algum produto” ou “só são aceites encomendas
de valor superior a 5 €”, são exemplos de duas
€
restrições de integridade.

• Estas restrições são introduzidas no sistema
adicionando código apropriado em várias aplicações,
implicando um grande esforço adicional.
p g ç
15

Ficheiros
• T d
Todas estas considerações tê a ver com sistemas
t id õ têm i t
utilizados por um utilizador.

• Imagine-se o esforço necessário para implementar e
manter um sistema no qual exista a possibilidade de
q p
vários utilizadores (não simultâneos).

• N
Neste caso, seria preciso d fi i para, cada utilizador, se
i i definir d ili d
ele poderia ou não aceder aos dados, se poderia acedê-
los apenas para consulta ou se poderia alterar os dados,
etc.

16

2.1.2
2 1 2 Dependência dados-aplicações
dados aplicações

• N
Num sistema d
i t de fi h i
ficheiros, as aplicações estão
li õ tã
directamente relacionadas com os ficheiros, isto é,
q
quando uma aplicação acede a um ficheiro, deve “dizer”
p ç ,
ao computador não só “a que aceder” mas também
“como acedê-lo”.

• Assim sendo, qualquer alteração na estrutura dos
ficheiros provocará alterações em todas as aplicações
que com ela se relacionam, com todos os
inconvenientes daí resultantes.

17

2.1.3
2 1 3 Redundâncias nos dados

• N
Nos sistemas d fi h i
i t de ficheiros é difí il evitar que existam
difícil it i t
dados repetidos em diversos ficheiros.

• Quando isto acontece, diz-se que existe redundâncias
nos dados.

• No exemplo da figura I.2.1, os dados relativos a cada
cliente no fi h i clientes, surgem repetidos no fi h i
li ficheiro li id ficheiro
encomendas.

• Estas redundâncias conduzem a custos mais elevados
ao gravar e ao aceder aos dados.
g
18

2.1.3
• U aspecto i
Um t importante a considerar é o f t d estas
t t id facto de t
redundâncias poderem gerar inconsistências nos dados,
isto é, várias cópias do mesmo dado não serem
, p
coincidentes.

• Consideremos, no exemplo da figura I.2.1, a situação
de, ao realizar uma encomenda se verificar que a
morada do cliente que fez essa encomenda foi alterada
alterada.

• Como o utilizador está a efectuar o pedido de
encomenda com a aplicação destinada para esse efeito,
inclui a nova morada apenas no ficheiro encomendas.

19

2.1.3
• Nesse momento surge um pedido de encomenda de um
outro cliente.

• Como, para efectuar a alteração da morada do cliente
anterior, é necessário recorrer a outra aplicação, o
utilizador aproveita o facto de estar a utilizar a aplicação
destinada ao pedido de encomendas para efectuar a
nova encomenda.

• Entretanto esqueceu-se da alteração que deveria ter
sido realizada! Desta forma, os dados relativos à
morada do referido cliente não são coincidentes, isto é,
são inconsistentes.

20

2.2
2 2 Sistemas de Bases de Dados

• U Si t
Um Sistema d B
de Bases d D d
de Dados (SBD) é um sistema
i t
baseado em computador(es) que tem como principal
objectivo armazenar dados de modo a permitir aos
j p
utilizadores consultar e actualizar a informação
solicitada.

• Os Sistemas de Bases de Dados surgiram como
resposta aos problemas apresentados pelos sistemas
de ficheiros. Ao contrário destes, aqueles caracterizam-
se por um repositório de dados que é acedido pelos
diversos utilizadores através d um sistema – o Si t
di tili d t é de i t Sistema
de Gestão de Bases de Dados (SGBD) (figura I.2.3).

21

2.2
2 2 Sistemas de Bases de Dados

22

2.2.1 Características de um Sistema
de Bases de Dados
Várias características distinguem os Sistemas de Bases
de Dados dos Sistemas de Ficheiros:

1. Catálogo do sistema: uma das características
fundamentais dos Sistemas de Bases de Dados é que
contém,
contém não só a base de dados mas também a
dados,
definição completa ou descrição da base de dados – o
catálogo do sistema ou dicionário de dados. A
informação contida no catálogo é chamada de
metadata (dados sobre dados). O catálogo do sistema
está acessível ao Sistema de Gestão de Bases de
Dados e aos utilizadores e é automaticamente criado
pelo sistema. A existência do catálogo do sistema
permite que um só SGBD possa ser eficientemente
utilizado com diversas bases de dados;
23

de Bases de Dados
2. Independência Dados-Programas: outra
característica importante dos Sistemas de Bases de
Dados é a independência dados programas: a
dados-programas:
estrutura dos ficheiros de dados está gravada no
catálogo do SGBD, separada dos programas que lhe
g , p p g q
acedem;

24

de Bases de Dados
3. Abstracção dos dados: o Sistema de Base de Dados
deve fornecer ao utilizador uma representação abstracta
dos dados isto é o sistema deve esconder detalhes
dados, é,
sobre a forma como os dados são fisicamente
armazenados e mantidos – abstracção dos dados.
ç

25

de Bases de Dados
4. Vistas múltiplas dos dados: normalmente, uma base
de dados t
d d d tem vários utilizadores. C d utilizador
ái tili d Cada tili d
necessita de ter acesso a perspectivas diferentes da
base de dados – vista da base de dados (Figura I 2 4)
I.2.4).
Uma vista pode ser um subconjunto da base de dados,
como por exemplo, a área de produção, do marketing, g
etc.

26

2.2.2 Intervenientes num Sistema de
Bases de Dados
Podemos classificar as pessoas intervenientes num
Sistema de Bases de Dados em quatro categorias (que
por vezes se sobrepõem):

1. Administrador de Dados e Administrador da Base de
Dados: o Administrador de Dados é o gestor
responsável pela administração dos recursos da base
de dados, passando pela planificação, pelo
estabelecimento de políticas e procedimentos O
procedimentos.
Administrador da Base de Dados tem o controlo
centralizado dos dados e dos programas que acedem a
esses dados É o responsável técnico que assegura que
dados.
todo o sistema funciona de forma conveniente. Em
algumas organizações não existe distinção entre estes
dois papéis
papéis.
27

Bases de Dados
2. Analistas da base de dados: são as pessoas que
fazem o desenho da base de dados.

São os responsáveis pela identificação dos dados a
serem armazenados na base de dados e pela
definição das estruturas físicas necessárias para
a a e a
armazenar esses dados.
dados

Para que a sua função seja cumprida de forma
efectiva, os analistas devem estar envolvidos com as
regras do negócio e com os utilizadores finais.
28

Bases de Dados
3. Programadores d aplicações: i l
3 P d de li õ implementam as
t
funcionalidades pretendidas pelos utilizadores finais,
obtidas a partir de especificações fornecidas pelo
p p ç p
analista de sistemas.

Além disso, testam, corrigem erros, documentam e
mantêm os programas escritos.

Podem utilizar linguagens de programação de 3ª
geração (por exemplo, C) ou de 4ª geração (por
4
exemplo, INFORMIX-4GL).

29

Bases de Dados
4.
4 Utilizadores finais: são as pessoas que acedem ao
sistema para obter a informação necessária ao seu
desenvolvimento na organização.

Alguns desses utilizadores acedem à base de dados a
partir de programas e interfaces já definidos que
definidos,
pretendem tornar o acesso o mais simplificado
possível.

Existem outros utilizadores mais sofisticados,
familiarizados com as facilidades fornecidas pelo
p
SGBD que podem eles próprios escrever as suas
aplicações.

30

2.2.3 As funções do Sistema de
Gestão de Bases de Dados
• O Sistema de Gestão de Bases de Dados (SGBD) é
uma aplicação informática que faz a gestão de toda a
base de dados fornecendo aos seus utilizadores
fornecendo, utilizadores,
acessos controlados.

• Vamos, de seguida, apresentar algumas das funções de
u SG
um SGBD.

31

1. Gestão do
1 G tã d armazenamento d t dos d d
dados: o SGBD cria i
as estruturas necessárias ao armazenamento, e
utilização dos dados, libertando o utilizador da difícil
ç ,
tarefa de definir e programar as suas características
físicas.

É criado o dicionário de dados que facilita este
processo.
processo

32

2.
2 Gestão da Interface: o SGBD formata os dados
consultados de modo a que tenham um aspecto
facilmente perceptível pelo utilizador.

São disponibilizadas determinadas linguagens de
programação que permitem essa interface
interface.

Os SGBD’s mais recentes apresentam interfaces
amigáveis que f ili
i á i facilitam grandemente o acesso à b
d base
de dados por parte de utilizadores não especializados.

Fornecem também capacidades para comunicar em
ambiente de redes de computadores, nomeadamente
através da Internet
Internet.
33

3.
3 Gestão da Segurança: o SGBD cria um sistema de
segurança que protege a base de dados de acessos não
autorizados.

São impostas regras que definem quais os utilizadores
que podem ter acesso à base de dados e para os
dados,
utilizadores autorizados a forma como pode ser feito
esse acesso, isto é, quais os ficheiros que podem ser
acedidos e as operações permitidas (ler adicionar
(ler, adicionar,
apagar ou modificar).

Deverão existir procedimentos que efectuem cópias de
segurança e recuperação dos dados em caso de falhas,
de modo a assegurar a segurança e a integridade dos
g g ç g
dados.
34

4.
4 Manutenção da Integridade dos dados: o SGBD
assegura a verificação de restrições de integridade de
modo a que a base de dados contenha sempre dados
válidos,
válidos minimizando a redundância nos dados e
maximizando a sua consistência. Existem restrições de
integridade intrínsecas ao SGBD e outras definidas
pelos utilizadores do sistema
sistema.

35

(4.
(4 continuação)

Outro aspecto a considerar é a gestão das
transacções. Uma transacção é uma série de acções
levada a cabo por um utilizador ou por uma aplicação,
como por exemplo inserir um novo cliente na base de
exemplo,
dados. Se uma transacção é interrompida antes do
seu fim (devido, por exemplo, a uma falha de energia
ou um sector danificado no disco) a base de dados
disco),
estará num estado de inconsistência, isto é, algumas
alterações foram efectuadas e outras não. O SGBD
deverá ser capaz de desfazer o que foi feito até essa
altura, de modo a devolver a base de dados a um
estado de consistência.

36

5. Controlo de acessos por vários utilizadores em
simultâneo: em bases de dados multi-utilizador, pode
acontecer que tentem aceder aos mesmos dados mais
do que um utilizador em simultâneo.

O SGBD deve fornecer mecanismos que assegurem
que a base de dados é actualizada correctamente,
ac ua ada co ec a e e,
quando isso acontece – controlo da concorrência.

37

2.2.4 Arquitectura do Sistema de Gestão
de Bases de
Dados e Independência dos Dados
• Um dos objectivos de um Sistema de Base de Dados é
o de fornecer aos utilizadores uma visão abstracta dos
dados,
dados isto é o sistema esconde detalhes sobre a forma
é,
como os dados são armazenados e mantidos.

• Na arquitectura ANSI/SPARC7, em 1975, são propostos
três níveis de abstracção que podemos ver na figura
ês es abs acção pode os e a gu a
I.2.5.

38

de Bases de

39

de Bases de
• Ní l I t
Nível Interno: é o nível mais b i
í l i baixo d abstracção.
de b t ã
Existe um esquema interno, o qual descreve a forma
como os dados são fisicamente armazenados. Neste
nível as estruturas d b i
í l de baixo nível d
í l dos d d
dados sãoã
descritas em pormenor.
• Nível conceptual: no nível seguinte existe um esquema
conceptual que descreve a estrutura dos dados para
uma comunidade de utilizadores: quais os dados que
estão armazenados e quais as relações existentes entre
esses dados.
• Nível externo: o nível mais elevado de abstracção inclui
um número de esquemas externos ou vistas do
utilizador, que descrevem apenas uma parte da base de
dados.
40

de Bases de
• E t arquitectura d t ê níveis pode ser utilizada para
Esta it t de três í i d tili d
explicar o conceito de independência dos dados, a qual
p
pode ser definida como a capacidade de alterar o
p
esquema de um determinado nível do sistema de base
de dados sem alterar o esquema do próximo nível
[Elmasri e Navathe 1989]
Navathe, 1989].

• Podemos definir dois tipos de independência dos dados
que são a Independência lógica e a Independência
física.

41

de Bases de
• Independência lógica: é a capacidade de alterar o
esquema conceptual sem ter de alterar os esquemas
externos ou programas de aplicação.

Podemos alterar o esquema conceptual para expandir a
base de dados ou para a reduzir No segundo caso os
reduzir. caso,
esquemas externos, relativamente aos dados que se
mantêm inalterados, não devem ser afectados.

Num SGBD que suporta independência lógica, apenas é
p
preciso alterar as definições de vistas e as
ç
correspondências entre os dois níveis [Elmasri e
Navathe, 1989]. Podem também ocorrer mudanças nas
restrições existentes, sem que sejam afectados os
ç , q j
esquemas externos.
42

de Bases de
• Independência física: é a capacidade de alterar o
esquema interno sem alterar o esquema conceptual (ou
o externo) [Elmasri e Navathe, 1989].

As alterações no esquema interno podem ser feitas por
ser necessário reorganizar fisicamente os ficheiros para
ficheiros,
melhorar o desempenho do sistema. Se a base de
dados continuar a ter os mesmos dados, não deverão
haver alterações no esquema conceptual
conceptual.

É mais fácil conseguir a independência física do que a
g p q
independência lógica, porque aquela tem apenas a ver
com o isolamento das aplicações e das estruturas
físicas armazenadas.
43

2.2.5
2 2 5 Linguagens fornecidas pelo SGBD

O SGBD coloca ao di
l dispor d cada utilizador várias
de d tili d ái
linguagens. Cada uma dessas linguagens inclui uma
sublinguagem de dados que consiste de duas partes:
g g q p
• uma linguagem para manipulação de dados – DML
(Data Manipulation Language);
• uma linguagem de definição de dados – DDL (Data
Definition Language).

Alguns SGBD`s permitem que as sublinguagens sejam
embutidas numa linguagem de alto nível como por
exemplo COBOL, PASCAL ou C (linguagens de 3ª
geração).

44

2.2.5

• U
Uma DDL é utilizada para d fi i um esquema ou para
tili d definir
modificar um esquema já existente.

• Uma DML é utilizada para efectuar todas as operações
básicas de manipulação de dados, tais como, inserir
p
novos dados, modificar os dados armazenados ou
apagar dados da base de dados.

45

2.2.5

• Existem DML`s imperativas que permitem que o
DML s imperativas,
utilizador diga ao sistema como se devem efectuar as
operações pretendidas e DML`s não imperativas, que
permitem ao utilizador d fi i o que é necessário mas
it tili d definir ái
não como obtê-lo (linguagens de 4ª geração).

• Exemplos deste último tipo de DML`s são a SQL
(Structured Query Language), QBE (Query By Example),
geradores de formulários geradores de relatórios (na
formulários,
parte II veremos exemplos para o SGBD Access).

46

2.2.6
2 2 6 Classificação dos SGBD s
SGBD`s

• A classificação d um SGBD pode ser f it atendendo a
l ifi ã de d feita t d d
vários critérios, nomeadamente, o modelo no qual o
SGBD se baseia, o número de utilizadores e o número
,
de locais pelos quais a base de dados está distribuída.

• Atendendo ao modelo, os SGBD`s classificam-se em
relacionais, em rede, hierárquicos ou outros.

• Em 2.3 abordaremos mais em pormenor estes modelos.

47

2.2.6
2 2 6 Classificação dos SGBD`s
SGBD s
• Quanto ao número de utilizadores podemos classificar
utilizadores,
os SGBD`s em SGBD`s mono-utilizador, se suportam
apenas um utilizador de cada vez, ou multi-utilizador, se
suportam a utilização simultânea de vários utilizadores
utilizadores.

• Os SGBD`s mono-utilizador estão normalmente ligados
SGBD s mono utilizador
à utilização dos computadores pessoais. Exemplos de
SGBD`s multi-utilizador encontram-se em sistemas para
reservas de viagens de avião ou sistemas para gestão
de contas correntes em bancos, etc.

• U SGBD multi-utilizador d
Um lti tili d deverá possuir capacidades
á i id d
de controlo da concorrência, isto é, possibilitar o acesso
simultâneo de vários utilizadores mantendo a base de
dados
d d num estado d i
d de integridade.
id d
48

2.2.6
2 2 6 Classificação dos SGBD`s
SGBD s
• Q
Quanto à di t ib i ã os SGBD` podem-se classificar
t distribuição, SGBD`s d l ifi
em centralizados, se os dados estiverem armazenados
apenas num local, ou SGBD`s distribuídos se a base de
p ,
dados e as suas aplicações estiverem distribuídas por
diversos locais, ligados através de uma rede.

• Os SGBD`s distribuídos apresentam características
internas específicas e uma maior complexidade que os
SGBD`s centralizados.

• No entanto, isso não deve ser visível para os
utilizadores.

49

2.2.7 Vantagens e desvantagens dos
Sistemas de Bases de Dados
Ao longo deste capítulo, foram já apresentadas algumas
g p , j p g
vantagens da utilização dos Sistemas de Bases de
Dados, tais como:

• tornar mais fácil a eliminação de inconsistências e de
anomalias de dados presentes nos Sistemas de
Ficheiros;
Fi h i
• eliminar as dependências estruturais presentes nos
sistemas de ficheiros;;
• reduzir o tempo destinado ao desenvolvimento de
aplicações;
• aumentar a flexibilidade do sistema permitindo uma
sistema,
maior facilidade nos procedimentos necessários para
efectuar alterações na sua estrutura;
• facilitar a obtenção de informação actualizada.
50

2.2.7 Vantagens e desvantagens dos
Sistemas de Bases de Dados
No entanto os Sistemas de Bases de Dados
entanto,
apresentaram algumas desvantagens que dificultaram a
sua generalização imediata, como por exemplo:

• o SGBD é um sistema de grande complexidade, ocupa
muito espaço em disco e é mais caro;
• existem custos adicionais de hardware aquando da
conversão do sistema existente para um Sistema de
Bases de Dados além dos custos inerentes à própria
Dados,
conversão;
• em caso de falha do sistema, existem normalmente
maiores impactos, visto que um Sistema de Bases de
Dados é mais abrangente, embora existam mecanismos
e procedimentos que minimizam esses impactos.
p q p
51

2.3
2 3 MODELOS DE BASES DE DADOS
• Diz-nos Chiavenato que “para se estudar ou analisar um
q p
sistema, utilizam-se modelos” e que “modelo é a
representação de um sistema”.

• Ao longo dos anos, têm vindo a ser delineados vários
modelos para representar um Sistema de Bases de
Dados.
Dados

• Podemos distinguir entre dois tipos de modelos, os
modelos conceptuais e os modelos de implementação.

• O modelos conceptuais são utilizados para se obter
Os d l t i ã tili d bt
uma descrição lógica do sistema. Um dos mais
populares é o modelo Entidade- Relacionamento (E-R).
52

2.3
2 3 MODELOS DE BASES DE DADOS

• O modelos d i l
Os d l de implementação d
t ã descrevem a f forma
como os dados estão representados na base de dados.
Podemos dividir estes modelos em três gerações.
g ç

• Na primeira geração colocam-se o modelo hierárquico,
p g q
que abordaremos em 2.3.1, e o modelo em rede, que
será abordado em 2.3.2.

• Na segunda geração temos o modelo relacional, que
será abordado em 2.3.3.

• No ponto 2.4 abordaremos os modelos de 3ª geração.
p g ç
53

2.3.1
2 3 1 Modelo hierárquico

• As duas estruturas básicas do modelo hierárquico são
os registos e os relacionamentos pai-filhos.

• Como o próprio nome do modelo indica, existem vários
registos relacionados através de uma estrutura
hierárquica do tipo pai-filhos com vários níveis
pai filhos, níveis.

• Cada registo fornece informação sobre uma entidade ou
instância de
i â i d um relacionamento.
l i

54

2.3.1

• Um relacionamento do tipo pai-filhos é um
relacionamento de 1:M (um para muitos), entre dois
registos.
registos

• O primeiro registo é o registo pai e os registos que com
ele estão relacionados são os registos filhos.

• O esquema de uma base de dados hierárquica pode ser
representado por uma estrutura como a apresentada na
figura I.2.6, que representa uma parte da base de dados
de uma empresa.
55

2.3.1

56

2.3.1

• Neste diagrama cada registo é representado por um
diagrama,
rectângulo e o relacionamento por uma linha que liga o
registo pai ao registo filho.

• Ao registo que se encontra no nível 0, chama-se raiz.

• O acesso a qualquer um dos registos deve ser feito a
partir da raiz e correndo cada um dos nós da árvore da
esquerda para a di i e d cima para b i
d direita de i baixo.

• No exemplo considerado para aceder ao registo
considerado,
projecto (P), teria de se percorrer os registos D, E, S, R
e P.

57

2.3.1

Existem algumas restrições i
E i t l ti õ inerentes
t ao modelo
d l
hierárquico, como por exemplo:

• apenas o registo raiz pode ocorrer sem estar
relacionado com um registo pai;
g p

• se um registo filho tem dois ou mais registos pai, então o
filho deve ser d li d para cada um d pais.
filh d duplicado d dos i

58

2.3.1

As bases d d d
A b de dados hi á i
hierárquicas apresentam alguns
t l
problemas, tais como:

• dificuldades de representação de relacionamentos do
tipo M:N (muitos para muitos);
p ( p )
• existem redundâncias nos dados, inerentes ao próprio
modelo, pois quando um registo filho tem mais do que
um pai deve ser repetido para cada um dos pais;
pai,
• ao eliminar um registo, eliminam-se os seus filhos,
correndo se
correndo-se o risco de eliminar informação relevante;
• a programação nos Sistemas de Bases de Dados
hierárquicos é muito exigente.
59

2.3.1

• Um dos mais difundidos SGBD`s concebidos segundo o
modelo hierárquico, comercialmente disponível, foi
desenvolvido pela IBM na década de 70 e ficou
conhecido como IMS (Information Management
System).
y )

60

2.3.2
2 3 2 Modelo em rede

• O modelo em rede surgiu tendo por base o modelo
hierárquico; assim sendo, apresenta com ele algumas
semelhanças.

• Neste modelo, um relacionamento chama-se set e é-lhe
atribuído um nome
nome.

• O registo pai chama-se owner e o registo filho chama-
se member.
b

• Ao contrário do que acontece no modelo hierárquico no
hierárquico,
qual um registo filho só pode ter um pai, um member
pode ter mais do que um owner.

61

2.3.2

• O acesso aos dados é feito de forma semelhante ao do
modelo hierárquico.

• O esquema de dados em rede pode ser representado
por uma estrutura como a representada na figura I 2 7
I.2.7.

62

2.3.2

63

2.3.2

• Existem algumas restrições que devem ser impostas
aos membros de um set e que devem ser definidas no
momento do desenho da base de dados dependendo
dados,
da forma como queremos que eles se comportem.

• Existem opções chamadas de inserção (manuais e
au o á cas)
automáticas) e opções chamadas de retenção
c a adas e e ção
(opcionais, mandatórias ou fixas).

64

2.3.2

• Apesar de apresentar várias vantagens nomeadamente
vantagens,
possibilitar a representação de relacionamentos de M:N
e do acesso aos dados ser mais flexível do que no
modelo hi á i
d l hierárquico, o modelo em rede apresenta
d l d t
também algumas desvantagens.

• Uma das grandes desvantagens tem a ver com o facto
de o sistema ser muito complexo, exigindo um
conhecimento profundo por parte dos programadores
programadores,
para que a sua utilização seja feita de forma eficiente, e
um grande esforço na sua manutenção, devido ao facto
de não existir verdadeiramente independência funcional
funcional.

• Além disso, o ambiente é pouco amigável para os
, p g p
utilizadores finais.
65

2.3.2

• Ao contrário daquilo que acontecia no modelo
hierárquico, para o qual não existiam normas definidas,
o modelo em rede surgiu a partir das normas
estabelecidas pelo DBTG, indicado pela CODASYL em
1971.

66

2.3.3
2 3 3 O Modelo Relacional

• O modelo relacional d b
d l l i l de bases d d d
de dados, apresentado
t d
por Edgar F. Codd em 1970, num artigo intitulado “A
Relational Model of Data for Large Shared Data Banks”,
g ,
representa uma quebra com os modelos anteriores e
uma verdadeira revolução.

• A estrutura básica do modelo relacional é a tabela,
também chamada relação
relação.

• Uma base de dados relacional é formada por um
conjunto de tabelas que se relacionam através da
partilha de atributos comuns. (Figura I.2.8)

67

2.3.3

• Apesar da tabela do modelo parecer um ficheiro, existe
uma diferença fundamental entre eles: uma tabela
fornece total independência quer dos dados quer
funcional, pois é uma estrutura puramente lógica.

68

2.3.3

• Um dos motivos que levaram ao grande sucesso do
modelo relacional é a facilidade que possui para
responder a questões Ad hoc através de uma
Ad-hoc,
linguagem própria – SQL (Structured Query Language).

• Devido à sua importância abordaremos mais em
po e o es e ode o o p ó
pormenor este modelo no próximo capítulo.
o cap u o

69

2.3.3

• A
Apesar d t d as vantagens apresentadas, o modelo
de todas t t d d l
relacional apresenta também algumas desvantagens.

• Uma delas tem a ver com o facto de o SGBD relacional
ser muito exigente quer a nível do hardware, quer a
g q q
nível do sistema operativo, devido à sua complexidade.

• E
Este aspecto tem vindo a ser ultrapassado d id à
i d l d devido
crescente capacidade dos computadores.

70

2.3.3

• O t aspecto a considerar é o f t d d id ao seu
Outro t id facto de, devido
ambiente amigável, os SGBD`s relacionais serem
utilizados sem ter em linha de conta o desenho cuidado
das estruturas necessárias, gerando muitas vezes
problemas semelhantes aos dos sistemas de ficheiros.

71

2.3.4 Novos modelos: Modelos
Orientados a Objectos e
Extensões ao Modelo Relacional
• As bases de dados relacionais têm tido grande
aceitação em aplicações clássicas nas organizações,
nomeadamente no processamento de ordens de
encomendas, no controlo d i
d t l de inventários, marcação d
tá i ã de
reservas e muitas outras.

• Nos últimos anos, as bases de dados têm aumentado
quer em tamanho quer em complexidade nas suas
aplicações,
aplicações colocando exigências com as quais é difícil
lidar com a utilização de tecnologias relacionais
clássicas.

72

• Nestas aplicações, incluem-se os Sistemas de
Informação Geográfica (SIG), aplicações médicas e
científicas,
científicas os sistemas CAD e CAM os sistemas
CAM,
multimédia, entre outras.

• Em qualquer destes casos, o volume de informação a
tratar é grande e o tipo de objectos a guardar na base
aa g a de po objec os gua da a
de dados é complexo.

73

• D t f
Desta forma, surgiram novos modelos d representação
i d l de t ã
de dados, nomeadamente os modelos orientados a
objectos, que têm origem nas linguagens de
j , q g g g
programação orientadas a objectos.

• Como resposta surgiram também extensões ao modelo
relacional, de modo a suportarem características de
modelos orientados a objectos
objectos.

74

• U objecto é uma representação conceptual d uma
Um bj t t ã t l de
entidade do mundo real, contendo os atributos que o
descrevem e o seu comportamento, ou seja, as acções
p , j , ç
que lhe estão associadas – encapsulamento significa
que um objecto contém quer a estrutura dos dados quer
o conjunto de operações que podemos definir
definir.

• Estas acções chamam-se métodos
métodos.

75

• U atributo pode ser uma referência a outro objecto.
Um t ib t d f ê i t bj t

• Cada objecto contém um identificador único que é
único,
independente dos seus atributos e invisível para o
utilizador.

• O estado de um objecto é o conjunto de valores que os
atributos d objecto têm num d d momento.
ib do bj ê dado

76

• Os métodos podem ser utilizados para alterar o estado
dos objectos.

• Os objectos comunicam entre si através de mensagens.

• Uma mensagem é um pedido de um objecto a outro
(pode ser o mesmo objecto) solicitando lhe que execute
solicitando-lhe
um dos seus métodos.

77

• Uma classe é uma colecção de objectos semelhantes
que partilham a estrutura e o comportamento, permitindo
que os atributos e os métodos associados possam ser
definidos uma vez para a classe em vez d
d fi id l de
separadamente para cada objecto.

• As classes estão organizadas através de uma estrutura
hierárquica, na qual os objectos de uma classe herdam
os atributos e métodos das suas super-classes –
herança – além de possuírem atributos e métodos
próprios.

78

• A h
herança permite que uma classe seja d fi id como
it l j definida
caso especial de uma classe mais geral.

• Os casos especiais são conhecidos como sub-classes e
os casos mais gerais são conhecidos como super-
g p
classes.

• P d
Podemos f l d h
falar de herança simples, sendo que neste
i l d
caso um objecto pode ter apenas uma superclasse pai e
de herança múltipla, sendo que neste caso um objecto
pode ter duas ou mais super-classes pai.

79

• O polimorfismo é uma característica i
li fi t í ti importante d
t t dos
sistemas orientados a objectos.

• Significa que a mesma mensagem enviada a objectos
p
pertencentes a classes diferentes, origina a resposta
g p
correcta em cada caso, ou seja, podemos utilizar o
mesmo nome para métodos em classes diferentes, pois
o seu comportamento será adequadamente diferente em
resposta à mesma mensagem.

80

• O processo de seleccionar o método apropriado
baseado num tipo de objecto chama-se binding.

• Quando este tem lugar ao executar o programa, diz-se
que existe binding dinâmico
dinâmico.

81

• Um SGBD orientado a objectos resulta da combinação
das características tradicionais de um SGBD (tais como
gestão do armazenamento dos dados gestão da
dados,
segurança, manutenção da integridade dos dados) e
das características de sistemas orientados a objectos,
j ,
tais como, herança, encapsulamento e polimorfismo.

82

• O “M if t
“Manifesto d
dos sistemas d
i t de bbases d de d d
dados
orientados a objectos” apresentado por Atkison, et all
em 1989 e citado por [Connolly e Beg, 1999], apresenta
p [ y g, ], p
treze regras que descrevem todas as características
desejáveis de um SGBD Orientado a Objectos.

• O manifesto contém dois conjuntos de regras
apresentadas na figura I 2 9
I.2.9.

• Já na década de 90, foi formado por vários vendedores
de SGBD`s um grupo de trabalho que pretendeu definir
normas no que concerne a este assunto – o Object
Database Management Group (ODMG)
(ODMG).
83

Este
E t grupo propõe um modelo d d d
õ d l da dados orientado a
i t d
objectos que consiste de três partes:

• um modelo de objectos;

• uma linguagem de definição de objectos (equivalente a
uma linguagem de definição de dados de um SGBD
convencional);
i l)

• uma li
linguagem para questões, em ambientes orientados
tõ bi t i t d
a objectos, com sintaxe semelhante à do SQL.

84


85

• As rápidas mudanças que se têm vindo a verificar no
ambiente das bases de dados, forçaram os defensores
das bases de dados relacionais a uma resposta ao
desafio colocado pelos ambientes orientados a objectos,
d fi l d l bi t i t d bj t
através da criação de extensões ao modelo relacional.

• Não existe um modelo relacional extendido único.

• E i
Existem sim várias propostas que dif
i ái diferem na f
forma
como as extensões são feitas.

• Em comum existem as tabelas do modelo relacional, a
linguagem para questões e a incorporação de alguns
conceitos de modelos orientados a objectos
objectos.
86

• Stonebraker`s propôs uma visualização do mundo das
Stonebraker s
bases de dados classificando-as segundo quatro
quadrantes, como apresentado na figura I.2.10.

87

• A
Apesar d esta classificação ser i t
de t l ifi ã interessante, existem
t i t
muitas aplicações de bases de dados que não se revêm
facilmente num dos quadrantes.
q

• Além disso, com o trabalho realizado pelo grupo ODMG
p g p
(Object Data Management Group) a distinção entre
extensão do modelo relacional e modelo orientando a
objectos é cada vez menos clara
clara.

88

• Actualmente existem debates entre os proponentes dos
dois modelos.

• Ambos estão de acordo em que o modelo relacional é
insuficiente para certos tipos de aplicações, diferindo, no
entanto,
entanto na sua opinião quanto à melhor solução
solução.

• É difícil prever se uma das abordagens se tornará
dominante ou se cada uma d l ocupará um nicho d
d i d delas á i h de
mercado próprio.

89

2.4
2 4 TENDÊNCIAS FUTURAS

• No final da década anterior surgiram novos
desenvolvimentos na área das bases de dados.

• Dado que se encontram numa fase inicial do seu
desenvolvimento,
desenvolvimento intitulamos esta secção de
Tendências Futuras”.

90

2.4.1
2 4 1 Data Warehouses

• U
Uma D t W h
Data Warehouse ((armazém d d d ) é uma b
é de dados) base
de dados que agrupa um grande volume de dados.

• Esses dados são optimizados para futuras análises,
servindo de base na tomada de decisão nas
organizações.

• O chamado “ i d
h d “pai das D Data W h
Warehouses”, Bill I
” Inmon,
define-as como uma colecção de dados integrados,
orientada para determinados assuntos, variável no
tempo e não volátil, que fornece apoio na tomada de
decisão.

91

2.4.1

• O
Os d d
dados di dizem-se i t
integrados pois numa D t
d i Data
Warehouse consolidam-se os dados provenientes de
diversas fontes, muitas vezes com formatos distintos.
,

• A integração dos dados implica um esforço bem
g p
organizado para definir e padronizar todos os dados, de
modo a torná-los consistentes, para que possam ser
apresentados aos utilizadores de forma centralizada
centralizada.

92

2.4.1

• A colecção de dados diz se orientada para
diz-se
determinados assuntos visto estar organizada de modo
a fornecer respostas a questões provenientes de
diversas á
di áreas f
funcionais d uma companhia (t i como,
i i de hi (tais
clientes, produtos, vendas,...).

• Na medida em que os dados, na Data Warehouse,
representam o fluxo de dados ao longo de um
determinado período (a última semana o último mês o
semana, mês,
último ano,...) diz-se que são variáveis no tempo.

93

2.4.1

• Além disso a variabilidade no tempo também está
disso,
presente na medida em que os dados são
periodicamente actualizados, provocando que todas as
agregações que d
õ dependem d variável t
d da iá l tempo, sejam
j
novamente calculadas.

• Visto que os dados, na Data Warehouse, não são
actualizados em tempo real, mas sim regularmente
recolhidos a partir dos sistemas operacionais (OLTP`s
operacionais, (OLTP s
“On Line Transaction Processing“ ou sistemas de
processamento de transacções) e visto que os dados
existentes não são nunca removidos sendo os novos
dados adicionados continuamente, diz-se que os dados
são não voláteis.

94

2.4.1

• Pela breve descrição apresentada podemos verificar
apresentada,
que estas bases de dados têm características
completamente diferentes das bases de dados dos
chamados sistemas d processamento d t
h d i t de t de transacções,
õ
que apresentámos ao longo das secções 2.1 a 2.3.

• Estas são concebidas de modo a maximizar a
capacidade de processamento de um grande número de
transacções que são previsíveis repetitivas e utilizadas
previsíveis,
muitas vezes, enquanto que aquelas são concebidas de
modo a maximizar a capacidade de resposta a um
número relativamente baixo de transacções que são de
natureza imprevisível e requerem respostas a questões
Ad hoc, não estruturadas e heurísticas.

95

2.4.1

• Naturalmente, sendo de naturezas distintas, apresentam
características distintas.

• Na figura I.2.11 apresentamos uma comparação entre
as bases de dados utilizadas nos sistemas OLTP e as
Data Warehouses, utilizadas pelos sistemas de apoio à
dec são ( SS
decisão (DSS – Decision Support Systems).
ec s o Suppo Sys e s)

96

2.4.1

• D d que a criação d
Dado i ã das D t W h
Data Warehouses envolvel
custos elevados, muito tempo despendido e um esforço
considerável por parte da gestão, muitas empresas
p p g , p
iniciam a sua incursão no mundo das Data Warehouses,
por um conjunto de dados mais manejáveis, orientados
para pequenos grupos dentro da organização – as Data
Marts.

• Numa tradução directa de Mart, obtemos mercado,
centro de comércio.

97

2.4.1

• P d
Podemos d fi i uma D t M t como um subconjunto
definir Data Mart b j t
de uma Data Warehouse que suporta as exigências de
um dado departamento ou de uma função do negócio.
p ç g

• Uma Data Mart pode estar isolada ou pode estar ligada
p p g
a uma Data Warehouse central.

98

2.4.1

99

2.4.1

• O d d armazenados numa D t W h
Os dados d Data Warehouse servirão
iã
para responder a questões sobre determinados factos
analisados de várias formas – perspectiva multi-
p p
dimensional.

• O star schema é uma técnica de modelação de dados
que gera um modelo facilmente utilizável numa
perspectiva de análise multi-dimensional dos dadosdados,
preservando, ainda assim, as estruturas relacionais.

100

2.4.1

• Até há muito pouco tempo as ferramentas disponíveis
tempo,
para aceder a grandes volumes de dados forneciam
apenas uma análise limitada e relativamente simplista
desses d d
d dados.

• O nascimento das Data Warehouses tem sido
acompanhado por uma exigência crescente por parte
dos seus utilizadores no que concerne a ferramentas de
acesso mais poderosas
poderosas.

• Como resposta, têm vindo a ser desenvolvidas
p
ferramentas tais como On-Line Analytical Processing
(OLAP`s) e Data Mining, que fornecem capacidades
ç
analíticas avançadas.
101

2.4.2 OLAP s
2 4 2 OLAP`s

• OLAP do inglês On Line Analytical Processing são
OLAP, On-Line Processing,
ferramentas que proporcionam ambientes para análise
avançada de dados, fazendo a síntese, análise e
consolidação d
lid ã de grandes volumes d
d l de d d
dados,
armazenados numa perspectiva multi-dimensional.

• A perspectiva multi-dimensional dos dados permite que
a análise dos dados do negócio seja feita sob várias
perspectivas (dimensões): vendas por cliente vendas
cliente,
por região, vendas por vendedor, etc.

102

2.4.2 OLAP`s
As técnicas de análise de dados numa perspectiva multi-
p p
dimensional podem ser ampliadas através das seguintes
funções:

• funções de representação de dados tais como gráficos
3-D;
• f
funções para agregação, consolidação e classificação f
de dados que permitem ao analista dos dados do
negócio a criação de níveis de agregação múltiplos, a
g ç g g ç p
visualização dos dados sob diferentes perspectivas e a
apresentação dos dados pormenorizados, contidos nos
dados consolidados; ;
• funções de cálculo, tais como variáveis de negócio
(margens de venda, quotas de mercado, etc.), rácios
financeiros e contabilísticos (lucro retorno etc) funções
(lucro, retorno, etc),
estatísticas, etc.;
• funções de modelação de dados tais como cenários do
tipo Se Então e programação linear
Se-Então linear.
103

2.4.2 OLAP s
2 4 2 OLAP`s

• As características dos OLAP`s tornam-se muito mais
úteis se o acesso a elas for simples.

• Assim sendo, é importante a existência de interfaces
amigáveis.
amigáveis

104

2.4.2 OLAP s
2 4 2 OLAP`s

• U
Um d dos objectivos d processamento d d d
bj ti do t de dados é
processar os dados contidos em bases de dados com
uma complexidade crescente, sem sacrificar os tempos
p , p
de resposta.

• As arquitecturas cliente/servidor permitem dividir o
sistema OLAP em vários componentes que podem ser
colocados no mesmo computador ou podem ser
distribuídos por vários computadores.

105

2.4.2 OLAP`s
As ferramentas OLAP podem ser organizadas segundo
duas categorias principais:

• MOLAP (Multidimensional OLAP) As ferramentas
MOLAP utilizam estruturas de dados apropriadas e
SGBD`s
SGBD` multi-dimensionais para organizar, navegar e
l i di i i i
analisar os dados. Exemplos de ferramentas MOLAP
incluem Analysis Server, Essbase, Express Server;
y p

• ROLAP (Relational OLAP) As ferramentas ROLAP são
a categoria de OLAP`s que se tem desenvolvido mais
OLAP s
rapidamente. As ferramentas ROLAP utilizam SGBD`s
relacionais, através da utilização de camadas de
metadados,
metadados evitando assim a criação de estruturas de
dados multidimensionais estáticos. Exemplos de
ferramentas ROLAP incluem Axsys, DSS Agent/DSS
Server, Metacube.
Server Metacube
106

2.4.2 OLAP s
2 4 2 OLAP`s

• A tendência actual é que as ferramentas MOLAP e
ROLAP convirjam, produzindo um novo tipo de SGBD`s
que utilizem as melhores capacidades de cada uma das
ferramentas.

107

2.4.3
2 4 3 Data Mining

• Só conseguimos perceber o verdadeiro valor de uma
Data Warehouse se formos capazes de extrair
características dos dados, relações, dependências ou
tendências ( d õ ) previamente d
t dê i (padrões) i t desconhecidos. A
h id As
ferramentas de Data Mining são uma das melhores
formas de o conseguir.

• As ferramentas de Data Mining são pró-activas, isto é,
em vez de ser o utilizador a definir o problema e
seleccionar os dados e as ferramentas que vão analisá-
los, as ferramentas de Data Mining pesquisam os dados
de forma automática à procura de anomalias e
automática,
relações, identificando problemas não identificados
previamente pelo utilizador final.

108

2.4.3
2 4 3 Data Mining

• As ferramentas de Data Mining são recentes e assim
sendo, não existem normas estabelecidas.

• Existem sim, famílias de ferramentas de Data Mining
dirigidas a determinados nichos de mercado (marketing,
finanças, saúde,...),
finanças saúde ) utilizando algoritmos que vão ser
aplicados a diversos dados de modo a obter
conhecimento.

• Os algoritmos tipicamente utilizados podem ser
baseados em redes neuronais, árvores de decisão,
regras de indução, algoritmos genéticos, classificação e
árvores de regressão, visualização de dados, etc.

109

2.4.3
2 4 3 Data Mining

• U exemplo d um resultado obtido pelas f
Um l de lt d btid l ferramentas
t
de Data Mining pode ser que 90% dos clientes que
compraram uma televisão têm uma apetência de 88%
p p %
de comprar um vídeo nas 4 semanas seguintes.

• Este resultado pode ser utilizado na tomada de decisão
relativa a uma campanha de marketing de vídeos.
Exemplos de ferramentas de Data Mining incluem
Clementine, Itelligent Miner, Mineset, etc.

• Para um maior aprofundamento deste tema sugerimos a
leitura de [Fayad et all,1996].

110

2.4.4
2 4 4 Integração com a Web

• A World Wide Web ou de forma abreviada a Web ou
WWW, é para muitas pessoas sinónimo de Internet.

• O pai da Web é Tim Berners-Lee, do CERN (laboratório
Europeu de Física das Partículas), que teve a ideia de
criar uma teia electrónica de informação sobre
investigação.

• H j encontramos na W b i f
Hoje Web informação sobre quase
b
tudo. Foi desenvolvida uma linguagem chamada HTML
– Hyper Text Mark-up Language – que consiste num
yp p g g q
conjunto de instruções, inseridas pelo programador, em
texto simples.

111

2.4.4

• C d uma d
Cada das páginas W b é um d
á i Web documento em
t
Hipertexto.

• O conceito de Hipertexto foi inventado nos anos 50, por
Ted Nelson, e significa que uma porção de texto num
g q p
documento pode remeter para outros pedaços de texto
dentro do mesmo documento ou de outros documentos.

• Inicialmente as páginas da Web eram baseadas apenas
em texto mas actualmente apresentam características
de multimédia.

112

2.4.4

• Nos últimos tempos,
tempos têm-se
têm se verificado o
desenvolvimento de tecnologias que permitem a
integração de sistemas de gestão de bases de dados
com a W b através d utilização d arquitecturas
Web, t é da tili ã de it t
adequadas.

• Existem páginas Web cujo conteúdo não se altera a não
ser que o próprio ficheiro (em HTML) seja alterado –
páginas estáticas
estáticas.

• É cada vez mais comum a existência de páginas Web
p g
que são geradas de cada vez que são acedidas –
páginas dinâmicas.

113

2.4.4

• As bases de dados pelas suas características
dados,
eminentemente dinâmicas, prestam-se a uma integração
na Web através da criação de páginas dinâmicas.

• Nesta situação, o hipertexto deve ser automaticamente
gerado pelos servidores através de scripts que fazem a
servidores,
conversão de diferentes formatos de dados para HTML.

• E i
Existem algumas aproximações possíveis, tais como
l i í i i
utilização da técnica CGI (Common Gateway Interface),
cookies, as linguagens JavaScript ou VBScript.
g g p p

• O Ms Access inclui algumas funcionalidades para a
Web.
Web
114

Matéria de apoio (Base de dados)

Mais conteúdo relacionado

Mais procurados

Semelhante a Matéria de apoio (Base de dados)

Mais de André Silva

Matéria de apoio (Base de dados)