11
2 REVISÃO DA LITERATURA E APRESENTAÇÃO DE DIVERSAS
TENTATIVAS
PARA SOLUCIONAR
O
PROBLEMA OBJETO
DESTA TESE
2.1
Introdução
Neste capítulo é inicialmente feita uma revisão da literatura sobre
modelagem de dados e sistemas de bancos de dados, motivada por serem os
conceitos relacionados com esse assunto importantes para o embasamento da
metodologia deste trabalho. Em seguida, é feita uma revisão da literatura
referente à importância e o uso de bancos de dados em planejamento e gestão
operacional de transportes. São também apresentadas, em ordem cronológica,
diversas iniciativas e tentativas para solucionar o problema objeto desta Tese.
2.2
Modelagem de Dados e Sistemas de Bancos de Dados
2.2.1 Níveis de abstração em análise de sistemas
Analistas de sistemas utilizam vários níveis de abstração no projeto de
sistemas computacionais.
Cada nível de abstração utilizado corresponde a uma fase do projeto e a
um tipo de modelo. Em geral, parte-se de uma especificação escrita (modelo
descritivo) para se elaborar um modelo conceitual. A partir do modelo
conceitual são derivados programas, em uma linguagem de programação
(modelo operacional) que por sua vez é, por razões de eficiência, comumente
convertida em linguagem de máquina.
A existência de níveis de abstração diferentes permite isolar a análise de
um problema do mundo real das questões de implementação física do modelo
correspondente.
12
Quando surgiram os primeiros computadores, a interação com os
usuários se dava apenas por meio da linguagem de máquina o que se
constituía em um dos fatores que limitavam a complexidade dos sistemas que
podiam ser desenvolvidos.
Com o aparecimento das linguagens de programação (e estruturas de
dados) de alto nível, ao final da década 50, a preocupação com os detalhes
internos a cada computador passou a ser responsabilidade apenas de uma
parte da comunidade de usuários. Isso permitiu que uma parcela dos recursos
fosse transferida do esforço de implantação para a solução de um problema em
si. Da mesma forma, a introdução de modelos conceituais, inicialmente
fluxogramas e diagramas de blocos e mais tarde, na década de 70, Diagramas
de Fluxos de Dados (Gane e Sarson, 1977), permitiu que sistemas de maior
complexidade fossem desenvolvidos.
Nessa época, os sistemas caracterizavam-se pelo processamento em
lotes (do inglês, batch) e pelo uso de cartões perfurados e fitas magnéticas. O
emprego de modelos com enfoque na abstração de processos (onde as
estruturas de dados eram definidas em função das necessidades de entrada e
saída dos programas) parecia adequado. Entretanto, com a evolução da
tecnologia de armazenagem de dados em meio magnético (discos magnéticos)
e do surgimento de sistemas de processamento interativo (mais complexos),
houve necessidade de uso de metodologias de análise com maior ênfase em
dados.
Acostumados ao uso de modelos de abstração de processos, mas
sensíveis à necessidade de abstração de informações, no projeto de um
sistema computacional, a equipe de analistas comumente se dividia em duas:
uma denominada “time do fluxo de dados” e a outra “time do banco de dados”.
Os modelos respectivos resultantes, comumente os Diagramas de Fluxos de
Dados (DFD) e os Diagramas de Entidades e Relacionamentos, ou DER
(Chen, 1976), resultavam incompatíveis segundo Coad e Yourdon (1991).
A análise de um sistema computacional deve compreender tanto a
abstração de processos como a abstração de informações. Diversos autores
(Parnas, 1972;
Flavin,
1981;
Setzer,
1986;
Booch,
1991;
Coad
e
13
Yourdon, 1991) defendem que, em análise de sistemas, a abstração de
informações preceda a de processos.
Setzer (1986) propõe um modelo combinado de ER e DFD modificado,
onde no lugar dos depósitos de dados estão as entidades e relacionamentos
do DER previamente definidos. Os fluxos de dados entre os processos ou
entidades externas, do DFD, e as entidades ou relacionamentos, do DER,
(originalmente depósitos de dados do DFD) são também substituídos por
operações de consulta ou atualização de instâncias das entidades ou
relacionamentos. Esta abordagem é semelhante à do DER Ampliado proposta
por Flavin (1981).
Outros, como Booch (1991) e Coad e Yourdon (1991), propõem o uso do
modelo orientado-a-objeto pelo fato deste agregar abstração de processos à
abstração de informações.
2.2.2 Níveis de abstração de informações e dados
Setzer (1986) descreve o processo de modelagem de dados, visando a
construção de um sistema de banco de dados, como sendo composto de
níveis, derivados uns dos outros conforme a seqüência descrita a seguir. Essa
classificação é mais completa do que a adotada pelo estudo ANSI/X3/SPARC
(Tsichritizis e Klug, 1978) para a mesma finalidade.
O primeiro nível é o do mundo real. O mundo real não é ainda
totalmente compreendido pelos seres humanos e, por esse motivo, não é
formalizável. Os objetos do mundo real são os seres, as coisas, os fatos e os
organismos sociais.
O segundo nível é o das informações informais, ou descritivo, e é
caracterizado pela linguagem natural. Já é um nível de abstrações onde a
descrição daquilo que interessa do mundo real deve ser totalmente inteligível
para as pessoas que interagem com ele. Os modelos correspondentes a esse
nível são denominados modelos descritivos e não há regras formais para
desenvolvê-los.
14
O terceiro nível é o das informações formais, ou conceitual, onde os
modelos desenvolvidos, denominados modelo conceituais, são caracterizados
por se basearem em símbolos dentro de uma conceituação matemática
rigorosa.
O quarto nível é o dos dados, ou operacional, e corresponde aos
símbolos que podem ser recebidos e tratados por um computador, o que é feito
por meio de linguagens de descrição e de manipulação de dados. Os modelos
correspondentes a esse nível são denominados modelos operacionais.
Os principais modelos de dados, o Modelo Hierárquico (Bleier, 1967
apud Tsichirtizis e Lochovsky, 1976), o Modelo de Redes (CODASYL, 1971) e
o Modelo Relacional (Codd, 1970), eram utilizados tanto no nível conceitual
como operacional. De fato, o nível conceitual definido pelo SPARC não
distingue entre esses dois níveis. Como conseqüência, objetos do mundo real
eram representados segundo o modelo de dados do banco de dados escolhido
para a implantação.
Essa distinção foi possível com a introdução de modelos conceituais,
como o Modelo de Entidades e Relacionamentos (Chen, 1976) - este
amplamente utilizado, segundo diversos autores, entre eles Setzer (1986) e
Date (1995), independentes dos modelos de dados dos bancos de dados
existentes.
No estudo ANSI/X3/SPARC foi definido um nível externo, que indica a
visão que cada usuário recebe dos dados. As visões dos usuários aplicam-se
tanto para o nível conceitual como para o operacional.
A derivação de um modelo operacional a partir de um modelo conceitual
pode ser feita em quase sua totalidade de maneira puramente formal. O
mapeamento não é total pois existem elementos que pertencem a cada um dos
níveis e que não ocorrem no outro, por exemplo, a definição de índices,
visando maior desempenho no acesso aos dados, é feita a partir do nível
operacional.
15
O quinto e último nível é o das representações internas dos dados e dos
programas na máquina, ou nível interno. O modelo interno contém as
estruturas de arquivos e os programas em código de máquina.
2.2.3 Sistemas Gerenciadores de Banco de Dados
A forma eficiente, rápida, precisa e econômica com que um computador
executa operações numéricas e lógicas (se comparada à do ser humano) tem
forçado a automação de muitas atividades.
Silbey (1976) lembra que nos anos cinqüenta e sessenta, a automação
consistiu de simples conversões de operações manuais, com pouca
preocupação quanto à integração de qualquer sistema resultante. Com o
passar do tempo, alguns administradores de dados perceberam que apesar
dos dados estarem armazenados no interior de uma organização, eles eram
em geral acessados apenas pelos programas escritos especificamente para
gerar ou ler aqueles dados. Qualquer outro usuário tinha dificuldade em obter,
integrar ou transformar esses dados para serem utilizados por outros
programas.
Dessa forma, para cada nova necessidade de dados, era
necessário antes escrever também um programa para extraí-los, operação
essa dificultada pelo fato da descrição da estrutura física dos dados estar
contida nos programas originais ou anteriormente utilizados para acessá-los.
Cada operação de extração duplicava as descrições e os dados já existentes.
A existência de múltiplas cópias, parciais ou totais, de arquivos dificulta a
atualização das informações de uma organização e favorece a geração de
relatórios com resultados díspares.
O valor da informação está relacionado com a tomada de decisões.
Davis (1974) define genericamente a informação como dados que foram
processados em uma forma que faça sentido para quem a recebe e seja de
valor para decisões correntes ou futuras. Se não houvesse decisões ou
escolhas,
não
haveria
necessidade
de
informação.
A
falta,
ou
a
impossibilidade de acesso à informação, assim como a existência informações
conflitantes, aumenta a incerteza de uma escolha.
16
A forma encontrada para a solução desses problemas foi a da
integração dos dados em bancos de dados, acessados, tanto pelos programas
como em consultas ad hoc, por meio de uma linguagem de alto nível. Um
banco de dados deve representar o ponto de equilíbrio entre o custo de
alimentação e armazenamento dos dados e seu custo de oportunidade, i.e., o
custo da falta de dados, quando da necessidade de se tomar uma decisão.
A integração dos dados de uma organização em um banco de dados,
visando sua maior disponibilidade, trouxe consigo também questões de
integridade e segurança. A solução desses problemas foi possível pela
incorporação
de
mecanismos
de
controle
apropriados
em
Sistemas
Gerenciadores de Bancos de Dados.
Fry e Silbey (1976), em um trabalho sobre a história e definições comuns
à tecnologia de Bancos de Dados, definem um Sistema Gerenciador de Banco
de Dados (SGBD) como uma ferramenta para manipular grandes bases de
dados e enumeram seus principais objetivos:
• disponibilidade dos dados: fazer com que uma coleção integrada de
dados seja disponibilizada para uma ampla variedade de usuários;
• qualidade dos dados: prover pela qualidade e integridade dos dados;
• privacidade: assegurar a manutenção da privacidade por meio de
medidas internas de segurança;
• controle centralizado dos dados: permitir o controle centralizado do
banco de dados, necessário para um gerenciamento de dados
eficiente;
• independência
de
dados:
permitir
que
os
programas
sejam
independentes da estrutura física (nível interno) ou lógica (nível
operacional) dos dados.
Historicamente, segundo diversos autores como Fry e Silbey (1976),
Setzer (1986) e Date (1995), a grande maioria dos bancos de dados está
dividida em três classes, segundo o modelo de dados adotado: Hierárquico,
Rede (ou CODASYL) e Relacional.
17
O critério de escolha de um Banco de Dados e seu Gerenciador, dentre
outros, deve levar em conta os objetivos acima citados. Diversos SGBDs
atendem
integralmente
os
quatro
primeiros
objetivos:
disponibilidade,
qualidade, privacidade e controle centralizado dos dados.
2.2.4 Independência de Dados
A independência de dados envolve dois níveis de abstração. No nível
interno, um sistema é dito independente dos dados se tanto os programas
quanto as consultas ad hoc independem da forma de armazenagem ou dos
métodos de acesso aos dados. Dessa forma, as alterações nesse nível não
devem requerer alterações nos programas. Para Korth e Silbershatz (1991),
modificações no nível interno são necessárias ocasionalmente para melhorar o
desempenho de um sistema.
Para Chamberlin (1976) e Khoshafian (1994), dos modelos de dados
citados anteriormente, apenas o relacional provê independência total de dados
no nível interno.
A independência de dados no nível operacional é, segundo Fry e Silbey
(1976), definida como a habilidade de se efetuar alterações no esquema lógico
de um banco de dados sem afetar significativamente os programas que os
acessam.
A independência da lógica dos dados possui dois aspectos
importantes: o suporte a diferentes visões do banco de dados e a capacidade
do sistema em permitir modificações dessas visões sem afetar a integridade
dos programas de aplicação. Date (1995), apresenta por meio de exemplos a
necessidade de suporte a diferentes visões do banco de dados. Com relação
às alterações no esquema lógico, cita que elas ocorrem em resposta às
mudanças nos requisitos de um sistema que ocorrem durante seu ciclo de vida.
Fry e Silbey (1976), observaram que a independência de dados é um
conceito muito amplo, pois a independência completa de dados é difícil, senão
impossível de se obter. Para esses autores, as soluções nesse sentido
parecem envolver a compreensão da semântica dos dados, a formalização do
significado dos dados.
18
Em 1986 Codd definiu treze regras de fidelidade (Pascal, 1989) para
determinar o quanto relacional é um SGBD.
Dentre elas, a regra da
independência da lógica dos dados determina que programas de aplicação, e
operações interativas, não devem ser modificadas quando ocorrem mudanças
nos esquemas que não envolvam perda de informação. Nenhum sistema
relacional comercial atende de forma completa essa regra. Date (1995) nota
que a independência de dados não é um absoluto, sistemas diferentes
possuem diferentes graus de independência de dados. Os sistemas modernos
tendem a ser mais independentes de dados que os antigos.
2.2.4.1
Maior independência de dados em SGBDs Orientados-a-Objeto
Objetos complexos, resultantes de abstrações do mundo real, para
poderem ser armazenados em bancos de dados relacionais, devem antes ser
decompostos em tabelas.
Para recuperá-los, posteriormente, torna-se
necessário efetuar cruzamentos ou junções (do inglês, join) entre essas
tabelas. Para acessar um dado atributo, de um objeto complexo, é necessário
saber a tabela à qual ele pertence. Isto significa que, se houver necessidade
de alterar o esquema de um banco de dados relacional (por questões de
desempenho), mesmo que não haja perda de informação, consultas de
usuários e programas de aplicação serão afetados.
Um dos princípios que caracterizam uma abordagem orientada-a-objeto
é o do encapsulamento. Um objeto esconde os detalhes de sua estrutura
interna e comunica-se com o mundo exterior por meio de mensagens. Quando
um objeto recebe uma mensagem válida ele seleciona um de seus métodos
(trecho de programa) apropriado àquela mensagem. Um método é uma função
que acessa a estrutura de dados do objeto que a contém. O resultado
devolvido por essa função é enviado para quem mandou a mensagem.
Segundo Bertino e Martino (1991) um Sistema Gerenciador de Banco de
Dados Orientado-a-Objeto (SGBDOO) provê, automaticamente ou por meio de
sua linguagem de definição de dados, métodos para cada elemento de dados
dos objetos para que eles possam ser manipulados.
19
Segundo
Bretl
et al. (1989),
Deux
et al. (1990)
e
Bertino
e
Martino (1991), as linguagens de manipulação de dados dos SGBDOO utilizam
notação de ponto substituindo as junções, típicas dos Sistemas Gerenciadores
de Bancos de Dados Relacionais (SGBDR), pela navegação por meio de
caminhos ( do inglês, path navigation). Tais caminhos podem ser constituídos
de referências a objetos, elementos de dados e métodos, não havendo
distinção entre eles, por parte dos usuários ou programas de aplicação.
Celko e Celko (1997), apontam essas diferenças ao afirmarem que os
gerenciadores de bancos de dados, baseados no modelo relacional, permitem
consultas complexas sobre dados simples (tabelas); gerenciadores de bancos
de dados baseados no modelo de objetos permitem consultas relativamente
simples sobre dados complexos.
Entretanto, segundo Embley (1998), essa abstração de um objeto do
mundo real, onde seu estado é representado por atributos e seu
comportamento é representado por meio de métodos, é uma noção
baseada-em-computador. Corresponde portanto, ao nível de abstração de
dados, ou operacional, definido por Setzer (1986) e indicado anteriormente
neste trabalho.
Embley (1998) propõe uma abordagem ontológica para o nível
conceitual e seu correspondente Modelo de Sistemas Orientado-a-Objeto
(MSO). O MSO é composto de três submodelos integrados: o Modelo de
Objetos e Relacionamentos (MOR) para representar os objetos e seus
relacionamentos com outros objetos, o Modelo de Comportamento de Objetos
(MCO) para representar o comportamento individual dos objetos, e o Modelo
de Interação entre Objetos (MIO) para representar as interações entre os
objetos.
Por meio de um modelo como o MOR, um usuário, ou programa de
aplicação, não necessita ter um conhecimento detalhado do esquema de um
banco de dados, isto é, do seu modelo operacional. Apenas o responsável
pela definição do esquema de banco de dados orientado-a-objeto necessita
conhecer os detalhes de implementação, isto é, quais as estruturas de dados,
os elementos de dados e os métodos de cada classe de objetos armazenados.
20
Por exemplo1, em um sistema hipotético de automação bancária com
uso de um SGBDOO, representado no nível conceitual por meio de um modelo
do tipo proposto por Embley (1998), parcialmente indicado por meio da
Figura 2.1, a pergunta "Quais os nomes dos primeiros titulares de contas
correntes com saldo negativo ?" pode ser expressa, utilizando a sintaxe
descrita em Deux et al. (1990), da seguinte forma:
select T.CLIENTE.NOME
from C in CONTA CORRENTE, T in C.TITULAR
where C.SALDO < 0 and T.ORDEM = 1
A expressão acima é fiel ao modelo conceitual, parcialmente
apresentado na Figura 2.1. Para escrevê-la basta saber que contas correntes
possuem número, saldo e uma lista ordenada de um ou mais titulares, que são
clientes do banco.
No MOR, um objeto que pode ser confundido com sua representação é
considerado como sendo do tipo léxico. Objetos cuja representação difere de
si próprio são classificados como não-léxicos. As Classes de objetos são
representados por retângulos e Relacionamentos Binários entre classes de
objetos são representadas por ligações. A quantidade de objetos de cada
classe que podem participar num relacionamento são indicados por meio de
intervalos numéricos.
Em
seguida
são
apresentados quatro
possíveis esquemas de
implantação (modelos operacionais), derivados da sintaxe indicada em
Deux (1990), para o modelo conceitual indicado na Figura 2.1. A expressão,
de consulta, acima é válida para todas as alternativas de implantação, pois
baseia-se no nível de abstração conceitual, do qual elas derivam. Portanto,
independe do esquema utilizado para implantação, ao contrário do que
aconteceria em um SGBDR que requer uma expressão diferente para cada
esquema alternativo.
1
extraído de Giacaglia, M. E. Bancos de Dados Orientados a Objeto (inédito).
21
CLIENTE
NOME
TITULAR
ORDEM
SALDO
CONTA
CORRENTE
NÚMERO
DATA-HORA
LANÇAMENTO
QUANTIA
TIPO DE
MOVIMENTAÇÃO
NOME
LEGENDA:
< NOME >
CONJUNTO DE OBJETOS LÉXICOS
< NOME >
CONJUNTO DE OBJETOS NÃO LÉXICOS
CONJUNTO DE RELACIONAMENTOS
etc.
INDICA QUANTAS VEZES UM OBJETO DE
UM CONJUNTO PODE PARTICIPAR NO
CONJUNTO DE RELACIONAMENTOS
Figura 2.1 – MOR parcial para o exemplo de aplicação bancária
22
• Esquema alternativo 1:
class CLIENTE with extension inherits Object public type
tuple(NOME: string, set(TITULAR:TITULAR), ... )
end;
class TIPO_DE_MOVIMENTACAO with extension inherits Object public type
tuple(NOME: string, ... )
end;
class CONTA_CORRENTE with extension inherits Object public type
tuple(NUMERO: integer, ...
LANÇAMENTO: set(tuple(DATA_HORA: integer,
TIPO_DE_MOVIMENTACAO: TIPO DE MOVIMENTACAO,
QUANTIA: float )
TITULAR: set(tuple(CLIENTE: CLIENTE,
ORDEM: integer )))
end;
method public SALDO float in class CONTA_CORRENTE;
• Esquema alternativo 2:
class CLIENTE with extension inherits Object public type
tuple(NOME: string, ... )
end;
class TIPO_DE_MOVIMENTACAO with extension inherits Object public type
tuple(NOME: string, ... )
end;
class CONTA_CORRENTE with extension inherits Object public type
tuple(NUMERO: integer, ...
SALDO: float,
LANÇAMENTO: set(tuple(DATA_HORA: integer,
TIPO_DE_MOVIMENTACAO: TIPO DE MOVIMENTACAO,
QUANTIA: float ),
TITULAR: set(tuple(CLIENTE: CLIENTE,
ORDEM: integer )))
end;
• Esquema alternativo 3:
class CLIENTE with extension inherits Object public type
tuple(NOME: string, ... )
end;
class TIPO_DE_MOVIMENTACAO with extension inherits Object public type
tuple(NOME: string, ... )
end;
23
class CONTA_CORRENTE with extension inherits Object public type
tuple(NUMERO: integer, ...
LANÇAMENTO: set(tuple(DATA_HORA: integer,
TIPO_DE_MOVIMENTACAO: TIPO DE MOVIMENTACAO,
QUANTIA: float,
SALDO: float )
TITULAR: set(tuple(CLIENTE: CLIENTE,
ORDEM: integer )))
end;
method public SALDO float in class CONTA_CORRENTE;
• Esquema alternativo 4:
class CLIENTE with extension inherits Object public type
tuple(NOME: string, ... )
end;
class TIPO_DE_MOVIMENTACAO with extension inherits Object public type
tuple(NOME: string, ... )
end;
class CONTA_CORRENTE with extension inherits Object public type
tuple(NUMERO: integer, ... )
end;
method public SALDO float in class CONTA_CORRENTE;
class LANÇAMENTO with extension inherits Object public type
tuple(CONTA_CORRENTE: CONTA_CORRENTE
DATA_HORA: integer,
TIPO_DE_MOVIMENTACAO: TIPO DE MOVIMENTACAO,
QUANTIA: float,
SALDO: float )
end;
class TITULAR with extension inherits Object public type
tuple(CONTA_CORRENTE: CONTA_CORRENTE,
CLIENTE: CLIENTE,
ORDEM: integer )
end;
Para Khoshafian (1994), apesar da superioridade dos bancos de dados
orientados-a-objeto, seu mercado é desprezível quando comparado com o
mercado
relacional.
Os
bancos
de
dados
orientados-a-objeto
estão
concentrando-se em nichos de mercado (CAD, CAM, CASE, e sistemas de
automação de escritórios), os bancos de dados relacionais continuarão a
dominar o mercado nos anos 90. Na época, Khoshafian indicou que as
24
próximas
versões
de
SGBDR
deveriam
incorporar
recursos
de
orientação-a-objeto.
Segundo Celko e Celko (1997), os recursos recém implementados
fizeram do SGBDR comercial ORACLE8 um SGBD Objeto-Relacional. O
Oracle8 permite definir tabelas de tipos de dados abstratos, compostos de
novos tipos de dados (imagens e outros tipos de arquivos binários), tabelas e
métodos. Não se trata de um SGBDOO principalmente pela incapacidade: de
navegação por meio das ligações entre os objetos (relacionamentos); de
definição de subtipos, dos tipos definidos, por herança e; de esconder colunas
nas tabelas.
2.2.5 Sistemas Gerenciadores de Dados Distribuídos
A existência de sistemas computacionais distribuídos reflete a geografia
de um mundo cada vez mais globalizado e decentralizado.
Fry e Silbey (1976), em seu trabalho sobre a evolução dos SGBDs,
afirmam que o conceito de bancos de dados distribuídos, onde um processador
acessa dados em diversos outros locais, já era realidade em alguns sistemas
homogêneos e possivelmente (com dificuldade) em sistemas não homogêneos.
A implantação de bancos de dados distribuídos ocorreu inicialmente
como uma alternativa aos bancos de dados centralizados em organizações
decentralizadas e distribuídas geograficamente. Para Fry e Silbey (1976), Ceri
e Pelagatti (1984), Ceri, Pernici e Wiederhold (1987) e Özsu e Valduriez (1991),
a principal motivação era a de reduzir os custos de comunicação ao colocar os
dados nos locais aonde eles eram (ou seriam) mais utilizados. Também,
segundo Ceri e Pelagatti (1984), era a solução natural no caso de bancos de
dados já existentes, dado que o custo de efetuar alterações necessárias nos
diversos locais era considerado menor que o de construir um sistema novo
centralizado.
Atualmente, para Bukhres et al. (1996), o processamento de dados é
caracterizado, cada vez mais, por aplicações que acessam e manipulam dados
em diversos bancos de dados pré-existentes. Esses bancos de dados são
25
tipicamente
autônomos
e
heterogêneos,
conseqüência
de
requisitos
computacionais, e de processamento de informações, diferenciados.
O termo banco de dados distribuído, para alguns, implica um tipo
particular de sistema gerenciador de dados distribuídos que provê aos usuários
acesso transparente a um conjunto integrado de banco de dados, dando a eles
a ilusão de um único banco de dados. Consultas sobre o banco de dados
global são automaticamente traduzidas em consultas sobre os bancos de
dados componentes. Esta, para Garcia-Molina e Hsu, (1995), parecia ser a
meta de todo sistema gerenciador de dados distribuídos no início (antes de
1980) e por isso o termo ficou associado à transparência e à integração.
De fato, entre as treze regras de fidelidade de Codd (Pascal, 1989) para
determinar o quanto relacional é um SGBD, a regra da independência da
distribuição dos dados determina que programas de aplicação, e operações
interativas, não devem ser modificadas quando os dados são distribuídos ou
quando ocorrem mudanças na distribuição dos dados.
Nos dias atuais, para Garcia-Molina e Hsu (1995), muitos pesquisadores
acreditam que a transparência e a integração podem ser incompatíveis com
requisitos de autonomia e diversidade de sistemas implantados. Por esse
motivo, o termo banco de dados distribuído é, muitas vezes, utilizado de forma
genérica, podendo designar também um Sistema de Multi-Bancos de Dados
(SMBD), isto é, um conjunto de SGBDs Federados ou mesmo independentes.
2.2.5.1
Autonomia
Segundo Breitbart, Garcia-Molina e Silberschatz (1995), até o momento,
foram verificados três tipos de autonomia:
• autonomia de projeto: nenhuma mudança pode ser feita nos SGBDs
locais para acomodar o SMBD;
• autonomia de execução: cada SGBD local possui controle total
sobre a execução das transações locais, podendo abortar uma
subtransação, de uma transação global, que está sendo executada
em seu local, mesmo que a transação global esteja em processo de
confirmação (commit) pelo SMBD;
26
• autonomia de comunicação: os SGBDs locais não compartilham
suas informações de controle de transações com os demais ou com o
SMBD e portanto são incapazes de coordenar transações globais.
2.2.5.2
Taxonomia
As arquiteturas possíveis para os sistemas de bancos de dados são
determinadas pelo grau de autonomia dos SGBDs componentes. Bukhres
et al. (1996) utilizam a seguinte taxonomia:
• SGBD Distribuído (ou SGBD Não Federados): integra bancos de
dados componentes que não são autônomos, mas pode ser
heterogêneo. Não há distinção entre usuários (usuários e transações)
locais e não locais.
• SGBD Federados: integra bancos de dados autônomos. A federação
possui controle limitado sobre os bancos de dados componentes e
conhecimento parcial de suas ações. Há distinção entre usuários
locais e não locais. Os usuários locais interagem diretamente com
seus bancos de dados locais e a federação não possui conhecimento
ou controle diretos sobre as transações que eles executam. As
transações de usuários locais, por outro lado, só acessam os dados
contidos em seus bancos de dados locais. Usuários não locais
executam transações, por meio do sistema federado, e estas podem
acessar mais de um banco de dados componente.
Em um banco de dados distribuído a implantação de mecanismos
globais de controle da concorrência e de transação é facilitada pelo fato de se
poder modificar cada um dos SGBDs componentes conforme a necessidade.
O mesmo não acontece com os bancos de dados federados por causa de
restrições devidas à autonomia local.
27
Em muitos casos, entretanto, a abordagem distribuída é incompatível
com o contexto. A abordagem federada deve ser utilizada nas seguintes
situações:
• na integração de sistemas já existentes, onde a substituição dos
SGBDs componentes é inviável economicamente;
• quando, por motivos econômicos, são utilizados pacotes (sistemas
comerciais de prateleira), no desenvolvimento dos novos SGBDs, que
não podem ser modificados (por não haver programa fonte, por
exemplo).
Existem duas subvariedades de SGBD Federados: Fracamente Atado
(do inglês loosely coupled) e Fortemente Atado (do inglês tightly coupled).
• SGBD Federado Fracamente Atado: os usuários são responsáveis
pela manutenção do sistema federado. Não há nenhuma autoridade
central que controle a criação de ou o acesso aos dados. Cada local
é responsável pela criação de uma visão do esquema global e pelo
processamento de consultas para acessar os bancos de dados
remotos.
• SGBD Federado Fortemente Atado: existe uma autoridade central
responsável
pela
administração
do
sistema
federado.
Essa
autoridade central possui controle sobre a(s) visão(ões) do esquema
global e pelo processamento de consultas globais.
A abordagem fracamente atada em BD Federados garante um maior
grau de autonomia para os SGBDs componentes, por não impor uma
autoridade central. Por outro lado, a manutenção da consistência é mais difícil
por não haver essa autoridade central.
2.2.5.3
Projeto de Sistemas Gerenciadores de Dados Distribuídos
Existem duas abordagens para o projeto de sistemas gerenciadores de
dados distribuídos: “de cima para baixo” (do inglês top-down) ou “de baixo para
cima” (do inglês bottom-up). A primeira é típica do caso de descentralização de
um banco de dados existente ou de um banco de dados completamente novo.
28
A outra é, segundo Ceri, Pernici e Wiederhold (1987), típica da agregação de
bancos de dados já existentes.
• Abordagem “de cima para baixo” (top-down)
O projetista possui o esquema do banco de dados centralizado existente
ou recebe uma descrição fornecida pelos usuários e a transforma em uma
especificação formal. Em ambos casos, o projeto de distribuição segue o do
esquema lógico global (no nível de abstração conceitual ou operacional) e
consiste em mapear o esquema global em diversos subesquemas, cada um
representando o subconjunto das informações associadas a cada local. Os
modelos operacionais e físicos são obtidos independentemente para cada local
quando os SGBDs desses locais forem diferentes entre si.
A distribuição dos dados requer a determinação de sua fragmentação e
de sua localização. A fragmentação é o processo de divisão de uma entidade
(nível conceitual) ou relação (nível operacional e modelo relacional) global em
diversos pedaços, denominados fragmentos (semelhante ao da determinação
das visões de usuário). A localização é o processo de mapeamento dos
fragmentos a um ou mais locais (caso em que são denominados réplicas).
•
Abordagem “de baixo para cima” (bottom-up)
O projeto de integração parte dos esquemas individuais dos bancos de
dados de cada local e consiste em obter um esquema global ao identificar os
dados comuns a eles, assim como suas diferenças.
Ceri, Pernici e Wiederhold (1987) sugerem que o esquema global seja
obtido por meio de hierarquias de generalização, em que os aspectos comuns
são representados associados a tipos de entidade genéricas, criadas para esse
fim, e as diferenças são representadas associadas aos subtipos, das entidades
genéricas, originalmente existentes.
Os passos sugeridos, por esses autores, para a integração dos
esquemas existentes em um único esquema global são:
• escolher um modelo de dados apropriado ao esquema global, nos
níveis de abstração conceitual e operacional;
29
• reconhecer as semelhanças e as diferenças (conflitos);
• resolver os conflitos.
Os tipos de diferenças incluem conflitos de nome, de escala, de domínio
ou de natureza estrutural.
• conflitos de nome: são de dois tipos: sinônimos ocorrem quando
entidades, dos diferentes esquemas locais, com nomes diferentes
representam a mesma entidade do mundo real; homônimos ocorrem
quando as entidades dos esquemas possuem o mesmo nome, mas
representam entidades diferentes no mundo real. A solução de
conflitos de nome está na construção de tabelas de correspondência
no esquema global;
• conflitos de escala: ocorrem quando existem diferentes visões sobre
os mesmos valores numéricos. A solução dos conflitos de escala está
no uso de fórmulas de conversão armazenadas como parte integrante
do esquema global;
• conflitos de domínio: ocorrem quando as entidades dos diferentes
esquemas locais representam subconjuntos diferentes de uma
entidade genérica do mundo real.
O uso de hierarquias de
generalização é a solução recomendada para esse tipo de conflito;
• diferenças estruturais: são devidas, provavelmente, ao contexto de
cada projeto; por exemplo, uma entidade do mundo real pode ter sido
modelada como um atributo em um esquema e como uma entidade
em outro, ou estar representada segundo diferentes níveis de
abstração (uma contém informação mais detalhada que a outra). O
uso de hierarquias de generalização resolve apenas alguns tipos de
diferenças estruturais; os demais casos são resolvidos pela alteração
de um ou mais esquemas locais (quando permitido) ou por meio de
procedimentos de conversão de consultas, incorporados ao esquema
global de dados.
30
1. INTEGRAÇÃO BINÁRIA EM ESCADA
SISTEMA 1
SISTEMA 2
SISTEMA
1+2
SISTEMA 3
SISTEMA
1+2+3
SISTEMA 4
SISTEMA
GLOBAL
2. INTEGRAÇÃO BINÁRIA BALANCEADA
SISTEMA 1
SISTEMA 2
SISTEMA 3
SISTEMA
1+2
SISTEMA 4
SISTEMA
3+4
SISTEMA
GLOBAL
3. INTEGRAÇÃO N-ÁRIA
SISTEMA 1
SISTEMA 2
SISTEMA 3
SISTEMA 4
SISTEMA
GLOBAL
Figura 2.2 – Seqüências de Integração de Sistemas pela Abordagem Bottom-Up
adaptada de Blaha e Premerlani (1998)
31
Segundo Blaha e Premerlani (1998), a integração de sistemas já
existentes pela abordagem bottom-up deve lidar com modelos desconjuntados,
construídos por diferentes equipes ao longo do tempo. Entretanto, ainda que a
abordagem top-down possua a vantagem de possibilitar a obtenção de
modelos globais coerentes, em casos onde há necessidade de se integrar
sistemas já existentes, ela pode resultar em um exercício teórico sem conexão
com a realidade.
Esses autores não recomendam a abordagem top-down para integrar
sistemas já existentes, mas entendem ser apropriado guiar a construção de um
sistema integrado por meio de uma visão top-down. Para tanto, citam as
diferentes seqüências de integração de sistemas indicadas por Batini (Batini,
1986 apud Blaha e Premerlani, 1998) e ilustradas por meio da Figura 2.2
(modificada, para maior clareza pelo autor desta Tese), mas recomendam a
primeira delas, ou seja, a “integração binária em escada”.
2.2.5.4
Transparência de Distribuição
Para Ceri e Pelagatti (1984), existem diferentes níveis de transparência
de distribuição cada um associado ao grau de independência dos programas
de aplicação da distribuição dos dados. Os níveis definidos por esses autores
são:
• transparência total (ou de fragmentação): as aplicações ignoram
completamente o fato do banco de dados ser distribuído. Dessa
forma, as aplicações são completamente imunes a quaisquer
mudanças que se faça na distribuição dos dados. A obtenção deste
nível de transparência pressupõe também que o SGBDD possui todos
os recursos necessários para tal;
• sem transparência de fragmentação: os usuários e programadores
de aplicação necessitam indicar o(s) fragmento(s) acessado(s)
quando da elaboração das consultas ou atualizações;
• sem transparência de fragmentação e localização: os usuários e
programadores de aplicação necessitam indicar a(s) localização(ões)
32
do(s) fragmento(s) acessado(s) quando da elaboração das consultas
ou atualizações;
• apenas transparência de mapeamento local, sem transparência
de fragmentação, localização e replicação: os usuários e
programadores de aplicação necessitam indicar a(s) localização(ões)
das réplicas do(s) fragmento(s) acessado(s) quando da elaboração
das consultas ou atualizações; as consultas e atualizações não
necessitam ser traduzidas para a linguagem e nomenclatura utilizada
em cada SGBD local;
• sem transparência alguma: as consultas e atualizações devem ser
decompostas, pelos usuários e programadores de aplicação, e
escritas segundo a linguagem e o esquema de cada local, caso em
que o SGBDD também não possui recursos para a solução dos
conflitos de esquema citados anteriormente.
2.2.6 Implantação de Sistemas Gerenciadores de Dados Distribuídos
Segundo Bukhres e Elmagarmid (1996), o rápido crescimento da
atividade econômica dos anos 50 produziu uma necessidade voraz por dados.
No início da década de 60 foram lançados os primeiros SGBDs. Em meados
da década de 70 as organizações já haviam coletado oceanos de dados
armazenados em sistemas de arquivo magnético, sistemas computacionais
com “SGBDs próprios” e/ou em um (ou mais) dos mais de 200 diferentes
SGBDs comerciais existentes. Entretanto, a visão de um banco de dados de
abrangência corporativa não havia sido alcançada.
Em meados da década de 70, começaram a ser desenvolvidos os
primeiros protótipos visando a obtenção de bancos de dados corporativos,
baseados nos conceitos de um banco de dados distribuído e um sistema
gerenciador de banco de dados distribuídos (SGBDD). Apesar da grande
quantidade de recursos investidos em pesquisa, por causa dos desafios
tecnológicos enfrentados, na década que se seguiu, poucos SGBDDs foram
criados e praticamente nenhum banco de dados distribuído corporativo foi
criado.
33
Nos anos 80, a necessidade de integração de bancos de dados ficou
cada vez mais aparente. Entretanto, as dificuldades técnicas tornaram-se
também maiores. Houve um reconhecimento cada vez maior da necessidade
de autonomia local, aliada à necessidade de integrar bancos de dados e
aplicações já existentes, ao invés de se projetar bancos de dados distribuídos
pelo método top-down. O conceito de distribuição de dados foi generalizado
para incluir multi-bancos de dados, ou seja integrar sistemas de bancos de
dados heterogêneos e autônomos. Nenhum produto comercial tinha essa
capacidade.
Ainda, segundo Bukhres e Elmagarmid (1996), pelo meio da década de
90, os dados tornaram-se um dos principais aspectos críticos e estratégicos
para as organizações. Apesar da existência de alguns SGBDDs e Sistemas
Gerenciadores de Multi-Bancos de Dados (SGMBDs), quase nenhum foi
efetivamente utilizado comercialmente, principalmente em função da falta de
mecanismos para resolver as diferenças semânticas existentes entre os
bancos de dados a serem integrados ou de controle dos tipos de transações
requeridas pelas organizações. A necessidade, entretanto, fez com que
algumas grandes organizações, que podem arcar com os enormes custos
envolvidos (como por exemplo, bancos, companhias telefônicas e grupos
industriais) desenvolvessem seus próprios sistemas de distribuição de dados.
O problema da integração de dados começa a receber cada vez maior
atenção específica na literatura (Kim, 1995; Bukhres e Elmagarmid, 1996;
Bloom, 1997; Blaha e Premerlani, 1998), impulsionada pelas tecnologias
recentemente tornadas acessíveis, em especial a micro-informática, os
sistemas cliente-servidor multi-tier, a telefonia móvel por satélite, a Internet,
potencialmente a maior rede de âmbito geográfico (wide area network)
existente, e a linguagem de programação Java.
34
2.3
Importância e Uso de Bancos de Dados em Planejamento e Gestão
Operacional de Transportes
A disponibilidade de dados para a tomada de decisões é sempre de
fundamental importância, especialmente no caso dos transportes urbanos. Em
um trabalho realizado pela CET - Companhia de Engenharia de Tráfego do
Município de São Paulo (CET 1980c) afirma-se: “os dados resumem em
números o grau de conhecimento que se tem sobre a região a ser estudada.”
Taylor et al. (1992), afirmam que a informação sobre a demanda de
viagens e o desempenho dos sistemas de transporte é essencial para a
tomada de decisão no estabelecimento de políticas, planejamento e projeto de
sistemas de transporte.
É importante também que os dados estejam atualizados. Thomson
(1983), aponta o fato de que o planejamento não deve ser uma tarefa
ocasional, mas uma atividade continuada, que necessita da coleta regular de
dados, monitoramento, atualização e alteração de planos e previsões. Para se
produzir e monitorar planos de transporte, deve-se possuir dados de qualidade,
independentemente de quem ou qual agência é responsável pela sua coleta. A
necessidade de séries históricas para monitorar previsões e progressos indica
que a coleta de dados deva ser regular.
Tradicionalmente, os dados têm sido considerados úteis para o emprego
de modelos formais matemáticos em estudos de transportes. A importância do
uso de modelos formais em planejamento de transportes é defendida por
muitos. As razões e a importância do uso desses modelos estão indicadas no
Anexo A - Uso de Modelos em Planejamento de Transportes.
Entretanto, a eficácia dos modelos produzidos depende dos dados que
estão disponíveis. Thomson (1983) observa que a sofisticação de um modelo
deve estar atrelada aos dados que estão disponíveis ou que podem ser obtidos
com facilidade.
35
Halbach (1994) reforça esta noção ao afirmar que:
“Os dados necessários para o funcionamento dos modelos devem
ser possíveis de serem coletados; caso contrário, os modelos perdem sua
utilidade...Mais do que qualquer outra causa, o esforço de modelagem
fracassa pela falta de dados adequados”.
Para Ortúzar e Willumsen (1990), que defendem o emprego de modelos
matemáticos em planejamento de transportes, em muitos casos os dados
disponíveis serão os fatores determinantes na decisão da abordagem a ser
utilizada na modelagem. Esses autores afirmam que:
“As duas abordagens clássicas de desenvolvimento de teorias são
conhecidas como dedutiva (construir um modelo e testar os prognósticos
contra as observações) e indutiva (tentar inferir leis gerais a partir de
dados). A abordagem dedutiva tem sido mais produtiva nas ciências puras
e a indutiva tem sido a preferida nas ciências sociais analíticas. É
interessante notar que os dados são centrais às duas. De fato, é de
conhecimento geral que a disponibilidade de dados deixa pouco espaço
para negociação e compromisso no balanceamento entre a relevância e
complexidade da modelagem. Em muitos casos a natureza dos dados
restringe a escolha da modelagem a uma única opção”.
O mesmo ocorre com autores que defendem o uso de modelos
matemáticos, em estudos integrados de transporte e uso do solo, como
Webster, Bly e Paulley (1988). Para eles:
“A dificuldade de obter dados adequados coloca uma restrição
prática na modelagem matemática. Não faz sentido construir um modelo
muito detalhado do comportamento humano se não há dados suficientes
disponíveis para especificar os aspectos mais importantes incluídos no
modelo, ou se o poder dos diversos mecanismos não pode ser medido
porque não há dados adequados contra os quais verificar o funcionamento
do modelo”.
Note que Webster, Bly e Paulley (1988) inclusive afirmam que:
“De certa forma, a própria base de dados é um modelo porque é
uma representação simplificada e parcial da realidade, e erros de
especificação dos dados podem resultar em erros de especificação do
modelo”.
As abordagens seguidas pelos principais estudos de transportes são
semelhantes, segundo Thomson (1983), e consistem dos seguintes estádios:
1
Metas: a apresentação das metas e dos objetivos do plano, com
indicação das prioridades;
2
Desempenho: a descrição do desempenho do sistema atual e as
formas pelas quais ele não atende às metas apresentadas em (1);
36
3
Análise: a análise do sistema de transportes e dos fatores
responsáveis pela demanda, de modo a explicar as deficiências
observadas em (2) e para servir como uma base para projeções
futuras em (4) e (8);
4
Projeção: a realização de projeções futuras da demanda de viagens
e das deficiências do sistema de transportes;
5
Restrições: a identificação de restrições à melhoria dos transportes;
6
Opções: a identificação de todas as opções para resolver as
deficiências em (2) e (4);
7
Planos: a formulação de pacotes de opções alternativas identificadas
em (6), dentro das restrições indicadas em (5);
8
Testes: previsões dos efeitos dos planos formulados em (7) com
relação ao disposto em (3) e (4);
9
Avaliação: a comparação entre os resultados das previsões em (8) e
as metas indicadas em (1) de modo a escolher o melhor plano.
Para o mesmo autor, no estádio Desempenho, os seguintes dados são
necessários para representar o estado do sistema de transporte. Esses dados
são do tipo cadastral (para descrever os componentes físicos do sistema) e
operacional (para descrever como ele funciona).
•
Dados Cadastrais:
1
um mapa de todo o viário com parâmetros de projeto para as
principais vias e cruzamentos, inclusive extensão, largura, gradiente
e curvatura;
2
um mapa de todas as linhas férreas (incluindo bonde), estações e
pátios, indicando para cada ligação: extensão, gradiente, curvatura,
cruzamentos em nível e seções em túnel;
3
um mapa de estacionamentos públicos fora do viário com
capacidade, horários de funcionamento e tarifas. Na área central, e
em outras aonde há congestionamentos, há necessidade de se
indicar, para cada zona, o número de vagas em estacionamentos
privados e o número de vagas oferecidas nas vias;
37
4
número de ônibus (por capacidade), bondes, taxis e outros veículos
de transporte público com indicação do proprietário; administração,
localização e capacidade das garagens; também o estoque de
material rodante para transporte ferroviário de passageiros;
5
número
de
automóveis
particulares,
veículos
comerciais
e
motocicletas.
•
Dados Operacionais:
1
um mapa indicando as mãos e restrições à conversão; também as
restrições ao tráfego de determinados tipos de veículos (por
exemplo,
corredores
exclusivos
de
ônibus),
cruzamentos
semaforizados (com indicação da duração de cada fase);
2
fluxos médios, por tipo de veículo, nas principais vias em horários de
pico e fora de pico; velocidades médias em algumas rotas para os
mesmos períodos. A rede deve ser dividida em diversas áreas
homogêneas (em termos das condições de tráfego) e medidas de
fluxo e velocidade devem feitas de modo a determinar médias de
fluxos e de velocidades e estabelecer relações velocidade-fluxo em
cada área;
3
taxas de ocupação e tempos de permanência em estacionamentos
no viário e fora do viário;
4
ocorrência (data, hora e localização) de acidentes com vítimas;
5
fluxo (indicando a capacidade em passageiros) e velocidade dos
trens por linha;
6
freqüência, passageiros transportados, arrecadação, horários de
pico e fora de pico para cada linha de ônibus, bonde ou trem;
número total de passageiros transportados por taxis; carregamento
das linhas e tempos de espera;
38
Thomson (1983)
características
também
prováveis
de
indica,
modelos
para
o
utilizados
estádio
em
Análise,
as
planejamento
de
transportes, diferenciando-as quanto ao nível: estratégico ou tático, a seguir.
• Para Planejamento Estratégico:
1 a região de estudo deve estar dividida em setores, no máximo 100;
2 restringir a rede viária às principais vias e cruzamentos,
aglutinando as vias em corredores, quando possível, com indicação
da direção da mão e de restrições à conversão; formar uma única
rede de transporte coletivo que incorpore as ligações de todas as
formas de transporte público, exceto taxi, e de modo que haja
apenas um método para se deslocar de um setor a outro;
3 parâmetros para planejamento, em especial para poder estimar a
posse de automóvel, por setor, como: a população, o número de
domicílios por categoria (de renda e estrutura domiciliar) e o
número de empregos por tipo de atividade;
4 dados de viagens médios diários: viagens geradas desagregadas
em motivo negócios, trabalho, outros (para passageiros) e
bens/mercadorias, distribuição de viagens baseada na população e
empregos por categoria; divisão modal entre carro e transporte
público;
5 são necessários os tempos e os custos médios diários para ambas
as redes (automóvel e transporte público) e a determinação de
curvas de velocidade-fluxo em cada setor;
• Para Planejamento Tático:
1 a região de estudo deve estar dividida nos mesmos setores
(utilizados em modelos para planejamento estratégico) mas grande
parte desses setores devem estar divididos em zonas, para as
quais são efetuadas as análises;
2 a rede viária deve incluir as principais vias e distribuidoras
importantes, com indicação da direção da mão e de restrições à
conversão; a rede de transporte público com diferenciação entre os
39
principais submodos (por exemplo, ônibus, trem e transporte para
deficientes);
3 parâmetros para planejamento, em especial para poder estimar a
posse de automóvel, por zona, como: a população, o número de
domicílios por categoria (de renda e estrutura domiciliar), o número
de empregos por tipo de atividade e a localização de escolas;
4 dados de viagens da hora pico: viagens geradas desagregadas em
motivo negócios, trabalho, educação, compras e outros (para
passageiros) e bens/mercadorias, distribuição de viagens baseada
na população e empregos por categoria; divisão modal entre carro
e transporte público e entre as diferentes formas de transporte
público;
5 são necessários os tempos e os custos médios em períodos de
pico e fora do pico, para ambas as redes (automóvel e transporte
público) e a determinação de curvas de velocidade-fluxo em cada
zona;
Para o mesmo autor, no estádio Projeção os parâmetros para
planejamento de transportes (indicados para o estádio Análise) são projetados,
de acordo com os diferentes cenários de uso do solo (apenas um, no caso do
planejamento tático) e a representação da rede de transportes deve também
ser compatível com esses cenários.
Autores como Taylor et al. (1992) e Vlahos et al. (1994) realizaram, em
tempos recentes, pesquisas sobre o processo de planejamento em diversas
organizações.
A pesquisa realizada por Taylor et al.
(1992), na Austrália, Nova
Zelândia e outros países, revelou que, em planejamento de transportes, a
modelagem não é a principal razão para a coleta de dados de viagens. O
principal uso dos dados é para obter informações sobre características de
viagens da população urbana.
40
Outros principais resultados dessa pesquisa são indicados a seguir.
1 As informações básicas requeridas em pesquisas contemporâneas de
transporte são:
• características demográficas (pessoas e domicílios);
• matrizes de viagens entre macrozonas desagregadas por modo,
motivo e hora do dia para pessoas, veículos e mercadorias, que
constituem informações básicas sobre viagens para a maioria das
aplicações atuais (por exemplo, estudos de corredores ou estudos
regionais de transportes);
• taxas de produção de viagens domiciliares (pessoas e veículos) por
classe demográfica, como indicador de viagens de pessoas;
• taxas de geração de viagens para usos do solo não residenciais,
como medida do impacto da evolução do uso do solo sobre os
transportes;
• perfis de uso modal por horário para destinos em centro comerciais
ou fora deles e ligações modais por motivo de viagem, como
indicadores da distribuição espacial e temporal das viagens entre
os modos;
• atitudes individuais relacionadas à provisão, operação e uso dos
sistemas de transportes, como indicadores da percepção da
comunidade e como subsídio à formulação de políticas.
2 A utilidade da informação para a formulação de políticas de
transportes e medida do desempenho dos sistemas de transporte
diminui rapidamente com o passar do tempo. O valor da informação
para a modelagem persiste por um tempo maior. Há portanto uma
forte necessidade da coleta regular de dados, junto com a habilidade
para comparar dados de pesquisas sobre um longo período de tempo;
3 Há necessidade de se estabelecer procedimentos para a rápida
disseminação de informações básicas (do tipo censitárias) para
planejadores de transportes e os que formulam políticas de
transportes. Dados mais detalhados, requeridos para a construção de
modelos podem ser apresentados com menor freqüência;
41
4 Bancos de Dados (com dados de pesquisas) longitudinais são
necessários para prover informações sobre impactos de iniciativas de
políticas de transporte no comportamento relativo às viagens.
A pesquisa realizada na Califórnia, por Vlahos et al. indicou que apesar
de possuírem modelos de previsão de demanda de viagens do tipo UTPS2 a
importância da análise e modelagem é secundária; os modelos são utilizados
mais como um procedimento formal do que como parte inerente ao processo
de planejamento.
De qualquer maneira, o planejamento de transportes, com ou sem o uso
de modelos formais necessita de informações, o que é enfatizado por
Taylor et al. (1992), quando estes afirmam haver necessidade de se assegurar
que as agências de planejamento de transportes possam trabalhar com bancos
de dados atualizados. Para esses autores, da mesma forma, a crescente
importância de se monitorar e medir o desempenho do sistemas de transportes
sob diferentes aspectos intensifica a necessidades de bancos de dados sempre
atualizados.
Além do planejamento e da modelagem de transportes, a pesquisa
efetuada por Taylor et al. (1992) identificou outras atividades que necessitam
de informações de transporte e de viagens, dentre as quais a operação de
sistemas de transportes.
O transporte coletivo, dado o seu caráter social, é em muitos casos
subsidiado pelo poder público. Em países desenvolvidos, há uma certa
preocupação com o destino dos impostos por parte de quem paga. Quando o
transporte coletivo é subsidiado há, por parte dessas comunidades, o desejo de
que o mesmo seja eficiente, gastando o mínimo de recursos públicos para os
níveis de serviço estabelecidos.
No caso do Brasil, para Maistro (1988) e Pietrantonio (1989), a
preocupação com a questão do transporte coletivo cresceu bastante nos
municípios brasileiros, em especial no Estado de São Paulo, a partir da
2
UTPS – Urban Transportation Planing Software, desenvolvido em 1970 pelo United States
Department of Transportation (DoT) é o precursor de diversos outros modelos computacionais
desenvolvidos desde então.
42
retomada da atribuição de fixar tarifas dos serviços urbanos (que haviam sido
assumidos pelo CIP - Conselho Interministerial de Preços entre 1976 e 1982)
dentro
do
novo
ambiente
político
de
abertura
democrática.
Como
conseqüência, houve um fortalecimento da gerência do transporte coletivo
urbano de passageiros nas grandes e médias cidades.
Pietrantonio (1989) afirma que, em diversos municípios esse processo
levou a formas aprimoradas de administração tarifária e a uma preocupação
crescente com aspectos relacionados com a qualidade e eficiência dos
serviços. Esse autor acredita que a eficiência da gestão dos transportes
coletivos depende da capacidade de coletar e processar a grande quantidade
de dados, associados ao mesmo:
“O esforço de aprimorar a gerência do transporte coletivo urbano de
passageiros tem de enfrentar como problema básico a própria
complexidade dos sistemas de transportes urbanos e a necessidade de
modernização dos métodos de atuação. Nas cidades de porte médio,
sistemas baseados somente no transporte por ônibus exigem o manuseio
de um volume considerável de informações para o planejamento,
execução e controle das ações sobre os sistemas locais.”
Para Pietrantonio (1989), em cidades de porte médio são dezenas ou
centenas de milhares de viagens transportando milhões de passageiros
mensalmente3, que precisam ser apuradas como dado diário e classificados
por tipo e período do dia, de forma a atender às necessidades de dados das
diversas atividades de administração do sistema.
Maistro (1988) cita a importância da coleta sistemática de dados e sua
armazenagem em banco de dados, de forma a mantê-lo atualizado. Para esse
autor:
“A efetiva gerência do transporte coletivo por parte dos órgãos
gestores fez destes os responsáveis pelo equilíbrio entre interesses
freqüentemente conflitantes dos elementos constituintes do sistema de
transportes, os usuários e as empresas operadoras dos serviços; para que
este equilíbrio ocorra cabe ao órgão de gerência a coleta sistemática de
dados do serviço e sua armazenagem em banco de dados no sentido de
tornar possível a orientação do sistema à posição desejada.”
3
em grandes aglomerados urbanos, como a Região Metropolitana de São Paulo, esses
números são diários.
43
2.4
Notícia de Algumas Iniciativas ou Tentativas de Construir Sistemas
Computacionais e/ou Bancos de Dados para Suporte à Integração
do Planejamento ou da Gestão Operacional de Transportes
Tem-se notícia de que houve algumas iniciativas ou tentativas de
construir Sistemas de Informação ou Bancos de Dados para suporte à
Integração do Planejamento ou da Gestão Operacional de Transportes. São
apresentados a seguir, em ordem histórica, os seguintes casos:
• Sistema de Informação do MUT – 1980;
• Comissão Especial de Informática da SEI/SECT – 1989;
• O Ato para a Eficiência para o Transporte Intermodal de Superfície
(ISTEA) – 1991;
• Tecnologias de Suporte a Aplicações e Sistemas de Informações –
Recomendações para o ISTEA – 1994;
• Sistema de Apoio ao Planejamento em Equipe PLANiTS – 1994;
• Planejamento Cooperativo na Baía de São Francisco – 1997;
• Banco de Dados do PITU – Plano Integrado de Transportes
Urbanos – 1998.
2.4.1 Sistema de Informação do MUT – 1980
O modelo de Uso do Solo e Transportes (MUT), desenvolvido
especificamente para ser aplicado na área metropolitana de São Paulo
(CET, 1980a), para simular a conformação futura do espaço urbano, e os fluxos
de atividade e transporte, em função das intervenções propostas para os
sistemas de transporte e uso do solo. O MUT é constituído de três sistemas:
Informação, Simulação e Avaliação.
O Sistema de Informação do MUT (CET, 1980c) foi inicialmente
projetado para servir como base de dados do Sistema de Simulação de Uso do
Solo do MUT (LUS). Dessa forma, o Banco de Dados original consistia de um
único arquivo (denominado Arquivo de Dados) contendo dados agregados para
44
cada zona de um (ou mais) dos zoneamentos (derivados das zonas de tráfego
da Pesquisa Origem-Destino de 1977) utilizados nos estudos. Esse arquivo
era essencialmente uma matriz. Cada linha (ou registro) corresponde a uma
versão de uma variável sócio-econômica ou físico-territorial. Cada coluna
(elemento de dado) descreve uma versão de uma variável e indica seus
valores para cada zona do zoneamento correspondente
Posteriormente, foi criado um outro arquivo, denominado String, para
armazenar dados sócio-econômicos desagregados por combinações de zona
(da Lei de Uso e Ocupação do Solo), tipo de construção e disponibilidade de
água e esgoto. As informações relativas à rede de transportes e fluxos
(matrizes de viagens) foram armazenadas em arquivos específicos.
Para visualização espacial dos dados, ao Sistema de Informação do
MUT foi acrescido de um software, desenvolvido pelo METRÔ para a EMTU4,
denominado Sistema Gráfico de Planejamento (SGP). As coordenadas dos
contornos das zonas de tráfego e das principais vias do sistema viário da área
de estudo foram digitadas a partir de mapas. O arquivo resultante da digitação
e emenda dos diversos mapas foi denominado Mapa Base, sendo utilizado
pelo SGP.
Os arquivos foram alimentados com informações obtidas de diversas
fontes: Pesquisa Origem-Destino de 1977 (OD77), Cadastro Imobiliário da
Prefeitura do Município de São Paulo, SABESP, IPT5, Secretarias de Educação
do Estado e de Municípios da RMSP, Coordenadorias do Bem Estar Social e
Prefeituras da RMSP.
A manipulação dos dados do Arquivo de Dados era feita por meio de um
programa denominado PGMANIP2. Este programa permitia:
• a entrada de dados pela leitura de cartões perfurados ou arquivos
armazenados em fitas magnéticas;
4
METRÔ – Companhia do Metropolitano de São Paulo
EMTU – Empresa Metropolitana de Transportes Urbanos (linhas intermunicipais de ônibus)
5
SABESP – Companhia do Saneamento Básico do Estado de São Paulo
IPT – Instituto de Pesquisas Tecnológicas do Estado de São Paulo
45
• a geração de novos dados por meio de operações matemáticas sobre
dados já armazenados;
• a visualização de, ou impressão de relatórios contendo, versões de
variáveis, suas descrições e valores para cada zona de tráfego do
zoneamento utilizado naquela versão;
• a exportação dos dados em arquivos para serem lidos pelo LUS.
A descrição de uma versão de uma variável, do Arquivo de Dados, era
composta dos seguintes elementos de dados:
• sigla da variável;
• número da versão;
• sigla do zoneamento;
• número de zonas;
• unidade de medida;
• formato dos dados;
• ponderação (operação matemática de agregação ou sigla da variável
utilizada na ponderação);
• responsável pelos dados;
• especificação da variável (contendo: nome da variável, fonte, ano,
etc.);
• abreviação da especificação;
• forma pela qual o registro foi gerado;
• data e hora da gravação do registro no arquivo;
• valor calculado segundo a ponderação definida.
Na época (1980), acreditava-se que esse Banco de Dados (Arquivo de
Dados) poderia ser utilizado futuramente em outras atividades de planejamento
urbano, com ou sem o uso do MUT. Havia também uma preocupação com a
uniformidade dos dados que seriam de uso comum pelas empresas envolvidas:
46
CET, COGEP, EMPLASA6 e EMTU. A estrutura de descrição das variáveis e
suas versões no Banco de Dados é resultado disso.
Entretanto, tudo leva a crer que o Banco de Dados do Sistema de
Informação do MUT possui alguns erros de concepção que colocam em dúvida
a viabilidade do uso do Banco de Dados do Sistema de Informação do MUT em
aplicações futuras.
O desejo de se utilizar futuramente o banco de dados em outros estudos
implica a necessidade de se definir explicitamente, em sua estrutura, a
dimensão tempo, para que os dados possam ser armazenados e recuperados
segundo esta dimensão. Na verdade, isso já deveria ter sido feito pois, além
da necessidade de dados (projetados) para o ano de projeto, o modelo
necessita de dados referentes a dois anos base distintos para sua calibração
segundo o relatório da CET (1980b).
As demais dimensões dos dados seriam: variável (sócio-econômica ou
físico-territorial), espaço (definido pelo zoneamento e as suas zonas), fonte dos
dados (fonte ou forma pela qual os dados foram gerados) e versão dos dados.
O elemento de dados versão, entretanto, foi utilizada para representar
simultaneamente as dimensões tempo e fonte dos dados. Além disso, a
versão é em si própria uma dimensão distinta das outras que o elemento de
dados versão representa. Tal ocorre, por exemplo, nos casos em que a
variável, o espaço, o tempo, e a fonte são as mesmas, mas os dados são
diferentes (como acontece quando se utiliza diferentes cenários projetados).
As limitações impostas ao Arquivo de Dados, de no máximo 5.000
registros, e ao número máximo de 935 zonas, para um sistema de zoneamento
adotado, é reflexo da estrutura física deste arquivo, concebida visando
eficiência computacional na armazenagem e processamento dos dados.
Entretanto, em determinado instante, durante a aplicação do modelo, já havia
3.100 registros no arquivo. Por outro lado, a restrição ao número zonas foi
devida a um limite físico, ou estabelecido como de projeto, para o tamanho de
um registro. Em ambos casos, se houvesse futuramente a necessidade do uso
6
COGEP – Coordenadoria Geral de Planejamento (da Prefeitura Municipal de São Paulo)
EMPLASA – Empresa Metropolitana de Planejamento (da Grande São Paulo)
47
de um número de zonas acima do limite imposto, o arquivo ou o banco de
dados teria de ser reestruturado. Consequentemente, o programa utilizado
para manipulá-lo teria de ser alterado para funcionar corretamente. Trata-se,
claramente, de caso de dependência de estrutura física de dados.
O Sistema de Informação do MUT é também dependente do hardware,
no caso, restrito à implantação em um único tipo de computador (IBM/157).
Outra questão problemática é a que se refere à forma pela qual o banco
de dados seria atualizado futuramente, especialmente no caso de dados
provenientes de outras entidades que não as contratantes COGEP, EMPLASA
e EMTU.
2.4.2 Comissão Especial de Informática nos Transportes da SEI / SECT 1989
A Comissão Especial no 31 – Informática nos Transportes da
SEI / SECT7 (SECT, 1989) elaborou, após diversas reuniões envolvendo
técnicos em informática e transportes, um relatório da situação da informática
nos transportes, na época, com propostas de programas visando sua melhoria.
O Relatório apontou que a inexistência de uma política de informação
explícita para o setor não inibiu o uso da informática no tratamento da
informação, pelas entidades e empresas ligadas à atividade de transporte:
“As diferentes empresas, pela necessidade de melhorar a qualidade
dos serviços prestados, elaboraram políticas de informação individuais para
atender suas necessidades específicas. Do ponto de vista sistêmico, essas
ações conduziram a sistemas herméticos, onde a troca de informações é
praticamente nula.
Como conseqüência, a informação de que o setor de transporte dispõe
é obtida por meio de um processo extremamente complexo, oneroso e de
pouca confiabilidade.”
7
SEI – Secretaria Especial de Informática e SECT – Secretaria Especial de Ciência e
Tecnologia, ambas subordinadas à esfera do Governo Federal.
48
Esta situação, resultado ou não de uma falta de política de informação,
não é exclusiva para o caso brasileiro, tendo sido apontada também por
autores de outros países como Heydecker, Small e Poulovassilis (1995).
No caso brasileiro, segundo o Relatório (SECT, 1989), as principais
causas que levaram à situação descrita acima são:
• inexistência de uma política global e de políticas específicas de
informação para as diversas modalidades ou subsetores do setor de
transporte, entre as quais o transporte urbano de passageiros;
• inexistência de um planejamento a nível governamental capaz de
integrar as informações processadas nas entidades e empresas de
um mesmo modo ou subsetor;
• a
cultura
técnica
de
informática
é
compartimentada,
pouco
disseminada internamente às entidades, e empresas do setor, e em
cada modo implantada de forma descoordenada;
• divulgação insuficiente e precário intercâmbio das aplicações
disponíveis, dos conhecimentos técnico-científicos e dos trabalhos
realizados, entre as entidades e empresas do setor;
• padronização insuficiente de termos, de conceitos e de unidades de
medida no trato do fenômeno transporte;
• inexistência de uma política de formação e desenvolvimento dos
profissionais de informática e informação, aplicada ao setor de
transporte, de forma a assegurar sua atualização quanto ao emprego
de novas tecnologias disponíveis.
O Relatório aponta, para o subsetor de transporte urbano, o uso da
informática nas atividades de planejamento do transporte e gestão operacional
(enfocadas neste trabalho), apoio à administração, controle de processos e
automação e apoio à engenharia.
No caso do planejamento de transportes urbanos as principais
aplicações da informática são: gestão de Bancos de Dados sobre transporte
urbano, análise de viabilidade técnico-econômica de projetos, planilhas de
49
avaliação sócio-econômica e utilização de modelos econométricos para
projeção de custos, distribuição de subsídios para transporte, estudos de tarifa,
estudos de regulação entre modos de transporte concorrentes e ajuste da
demanda. O cenário desejado é o da introdução da informática no processo de
planejamento de transporte urbano nas médias e pequenas cidades, apoiado
em sistemas de informação, cujos custos de implantação devem ser rateados
entre as entidades e empresas envolvidas.
A gestão operacional é dividida em governamental e empresarial. No
caso governamental as principais aplicações da informática são: manutenção
de Bancos de Dados dos sistemas de transporte urbano, cálculo de custos e de
tarifas, programação e controle operacional das linhas e controle de emissão
de bilhetes. Nas empresas as principais aplicações são: programação e
controle da manutenção, programação e controle da operação, inclusive a
escala de veículos e pessoal. O cenário desejado é o da implantação de
sistemas de informações gerenciais regionais que, por meio de indicadores,
permitam o acompanhamento da eficiência e da rentabilidade dos vários
sistemas operados na região.
Com relação ao uso de sistemas de informação em transporte urbano, o
Relatório (SECT, 1989) cita, para o caso governamental, o uso dos sistemas
SITURB como parte integrante de um primeiro sistema de informação a nível
regional, mas que abrange apenas os sistemas de ônibus. O cenário desejado
é o da elaboração de sistemas de informação regionais elaborados com
padrões mínimos de compatibilidade a fim de permitir a integração dos
mesmos a nível nacional.
Para a área empresarial, em muitos casos, os sistemas não estão
integrados ou não são compatíveis dentro da mesma empresa; a troca de
informações é feita por digitação de dados de relatórios. O cenário desejado é
o
do
desenvolvimento
de
sistemas
de
informação
contemplando
o
planejamento, operação e informação aos usuários, tornando compatíveis os
sistemas já implantados.
O Relatório (SECT, 1989) apresenta um plano de ação com diversos
programas, dentre os quais o da informatização do processo de planejamento
50
do setor de transportes urbanos (chamado Programa 2) e o da informatização
da gestão operacional do setor transporte (Programa 3). Esses dois programas
são constituídos de projetos, descritos a seguir.
No
Programa 2
tem
especial
interesse
para
esta
Tese
o
Projeto 1: Sistema de Informações para o Planejamento Estratégico dos
Transportes Urbanos, que tem como objetivo organizar uma base de dados
comum às diversas atividades de planejamento do setor de transportes
urbanos em cada aglomerado urbano ou região metropolitana contemplando a
agregação a nível nacional. As metas são: estabelecer zoneamento, codificar
a rede de transporte de cada área de estudo; levantar dados sócio-econômicos
e perfil de viagens de cada área de estudo segundo o zoneamento e a rede de
transporte propostos e; elaborar mecanismo de atualização e divulgação dos
dados.
Os demais projetos referem-se à elaboração de modelos matemáticos e
os correspondentes software, com o objetivo de desenvolver uma sistemática
para o planejamento de transportes urbanos de passageiros e auxiliar a análise
de viabilidade de alternativas de investimentos no sistema de transporte
urbano.
Para o Programa 3, tem especial interesse para esta Tese o
Projeto 1: Sistema de Informações Gerenciais e Operacionais dos Transportes
de Passageiros, que objetiva fornecer aos órgãos concedentes do poder
público informações básicas, visando o controle e acompanhamento mais
eficaz da operação dos sistemas de transporte sob sua competência e a
melhoria dos serviços prestados à população. As metas são: levantar e avaliar
os sistemas já existentes, estabelecer critérios mínimos para compatibilidade
dos sistemas e criação de mecanismos de incentivos ao desenvolvimento,
desenvolver coletores de dados sobre operação e treinar pessoal para
implantar o sistema nos órgãos de gerência.
Os demais projetos de interesse para o transporte urbano de
passageiros são de informatização de sistemas de simulação e controle de
circulação de veículos em áreas urbanas e de sistemas de controle da
operação de transporte coletivo.
51
A implantação dos Programas 2 e 3 constantes do referido Relatório,
entretanto, ainda não aconteceu.
2.4.3 O Ato para a Eficiência do Transporte Intermodal de Superfície 1991
O Ato para a Eficiência do Transporte Intermodal de Superfície, de 1991,
tradução de Intermodal Surface Transportation Act of 1991, ou ISTEA, do
inglês,
representou
segundo,
Howe e Brail (1994),
uma
mudança
nos
paradigmas de gestão de sistemas de transporte nos EUA, ao redefinir os
principais problemas de transporte. Esta redefinição deveu-se à maior ênfase
sobre questões como conectividade (integração interinstitucional e intermodal),
escolha, qualidade do ar e eficiência de custos, além de priorizar a gestão
eficiente dos sistemas de transporte sobre obras para aumento da capacidade
e de desviar o enfoque do aumento da oferta para o da manipulação da
demanda de viagens.
O ISTEA estabeleceu, segundo Halbach (1994), especificamente, seis
sistemas
de
informação
de
suporte
à
gestão:
pavimentos,
pontes,
congestionamento de tráfego, segurança nas estradas, infra estrutura pública
de transportes e instalações intermodais. Os requisitos e as expectativas para
esses seis sistemas de informação são:
• um conjunto de “procedimentos, dentro das organizações de um
estado, para coordenar o desenvolvimento, o estabelecimento e a
implantação dos sistemas de gestão”;
• a habilidade para ajustar os sistemas para “atender metas, políticas e
recursos estaduais, regionais e locais, aceitáveis por agências
federais”;
• o “uso de bancos de dados com um referencial comum ou
coordenado e métodos para o compartilhamento de dados”;
• a necessidade de “documentação que descreva cada sistema de
gestão ... para que as agências federais possam determinar se os
sistemas atendem aos propósitos propostos”; e
52
• um método para tratar as “inter-relações entre os sistemas e
problemas relacionados aos propósitos de mais de um deles”.
2.4.4 Tecnologias
de
Suporte
à
Aplicações
e
Sistemas
de
Informações - Recomendações para o ISTEA - 1994
Para Halbach (1994), a tradução de modelos de análise e decisão de
engenharia em software de suporte a decisões tem tradicionalmente enfrentado
os seguintes problemas:
• a lógica do modelo é comumente obscurecida pelo conjunto de
instruções do programas resultantes, isto é, a solução do problema de
engenharia (de alto nível) está misturada à solução de problemas de
natureza computacional (de baixo nível);
• a estrutura e a complexidade dos modelos são algumas vezes
comprometidas
por
limitações
visando
facilitar
a
lógica
de
programação.
Para superar esses problemas, Halbach (1994) sugere o uso de certas
tecnologias de suporte a aplicações (do inglês, application frameworks), como
as Interfaces Gráficas de Usuário, os Sistemas Gerenciadores de Bancos de
Dados Relacionais e a Programação Orientada-a-Objeto.
Aquele autor afirma que essas tecnologias foram empregadas, com
sucesso em uma área correlata - a logística militar, no desenvolvimento de
sistemas de informações para o exército e a força aérea americana, e que, por
esse motivo, são também aplicáveis à área de transportes.
Para Halbach (1994), um sistema de suporte à gestão é mais do que
apenas o gerenciamento de dados com a habilidade de emitir relatórios
sintéticos. Sistemas de suporte à gestão devem poder permitir a previsão de
situações futuras de modo a auxiliar o planejamento e a programação. Dessa
forma, as entradas para processo de planejamento e programação desses
sistemas de informação de suporte à gestão, compreendem seis categorias:
• recursos e suprimentos, utilizados em atividades de manutenção e
reabilitação e associados a preços unitários ou tempo despendido;
53
• bens de capital, como instalações e equipamentos de manutenção
que representam investimentos de longo prazo;
• estoques, coleções de entidades como pontes e trechos de
pavimento, que possuem características dos dois anteriores, isto é,
possuem algumas propriedades fixas e outras associadas a consumo
de recursos;
• fatores ambientais, fora do controle direto dos tomadores de decisão;
• metas definidas;
• modelos decisórios, que são os procedimentos ou algoritmos que
transformam entradas de dados em saídas.
O processo de planejamento e programação provê as seguintes
categorias gerais de saídas:
• programação de atividades, indicando: quando, por quem e a que
custo;
• lista de restrições, que representam um limite sobre a programação
ou que tenham sido violados em caso de conflito entre duas ou mais
restrições;
• lista de condições, esperadas para cada categoria de estoque (por
exemplo, segundo a função, região, ano).
Ainda, para Halbach (1994), as diferentes categorias de entradas e
saídas podem e devem ser representadas por meio de componentes ajustáveis
em uma tecnologia de suporte a aplicações para viabilizar a construção, a
operação e a manutenção dos sistemas de suporte à decisão citados
anteriormente. Para isso, o autor identifica três categorias de problemas que
afetam a viabilidade da aplicação de tecnologias de suporte a aplicações:
adequação, incerteza e qualidade, caracterizados sucintamente a seguir.
A adequação está relacionada com a granularidade dos dados
(freqüência, exatidão, precisão e volume) e a interdependência dos modelos
decisórios quando estes envolvem de ações sobre elementos comuns.
54
A natureza probabilística dos sistemas físicos e econômicos é
comumente ignorada na prática com resultados potencialmente desastrosos.
A
qualidade
é
normalmente
caracterizada
por
uma
série
de
ponderações, incluindo: eficiência contra eficácia, risco contra retorno,
restrições contra penalizações, sofisticação contra facilidade de uso e
compreensão.
Aquele autor fornece uma lista dos principais recursos que mostraram
ser úteis em sistemas de informação em geral e que auxiliam na identificação
de problemas e na elaboração de soluções:
• capacidade de atender consultas ad-hoc para criar relatórios
especializados;
• suporte a diferentes cenários (base e variações);
• habilidade de criar um subconjunto representativo dos dados dos
estoques nos quais os cenários podem ser testados;
• mecanismos de identificação de anomalias para permitir o ajuste de
restrições e a correção de algoritmos;
• suporte a decisões geradas por fatores políticos ou externos sobre as
recomendadas pelo modelo;
• relatórios gráficos para auxiliar na visualização de resultados; e
• capacidade de violar uma ou mais restrições, devido a conflitos entre
elas.
2.4.5 O Sistema de Apoio ao Planejamento em Equipe PLANiTS - 1994
Vlahos et al. (1994) ao proporem um sistema de poio ao planejamento
em equipe, denominado PLANiTS, apresentam uma preocupação que vai além
de aspectos meramente técnicos. O objeto de tal preocupação contribui para
as dificuldades e a complexidade na solução do problema da integração do
planejamento interinstitucional. Trata-se do aspecto político onde se defrontam
interesses diferentes e até antagônicos. Por esse motivo propuseram o sistema
PLANiTS, composto por: 1) uma área comum onde os problemas são
55
cadastrados, propostas de soluções são debatidas e julgamentos são
realizados e 2) áreas individuais, onde cada grupo ou indivíduo participante
desenvolve suas próprias análises e apresentações. O PLANiTS foi concebido
para ser um ambiente essencialmente colaborativo mas que permite algum
grau de antagonismo.
O PLANiTS propõe, como um de seus elementos, um Banco de Dados
com informações partilhadas entre os participantes como: cenários, estratégias
e ações propostas, medidas de desempenho para diferentes alternativas,
ferramentas utilizadas nas análises, políticas e metas estabelecidas por
consenso.
Para aqueles autores, uma característica comum no processo de
planejamento de transportes consiste no fato de que nem todos os
participantes trabalham de forma amistosa, mesmo quando visam atingir um
conjunto de metas semelhantes. A situação ideal é aquela em que todos os
times de planejamento bem como os seus membros estejam trabalhando de
forma colaborativa. Infelizmente, sabe-se que ocorrem situações onde os
times de planejamento e seus membros são, de fato, antagônicos.
O planejamento costuma estar subordinado a processos políticos e ser
conduzido de acordo com diferentes interesses que se sobrepõem àqueles do
sistema de transportes planejado.
Algumas vezes, dado o montante de recursos necessários para as
intervenções, o planejamento de transportes é orientado por oportunidades de
financiamento.
Participantes do processo político, grupos de interesse ou indivíduos
com poder político, possuem um papel importante na moldagem da percepção
de necessidades obtendo, ou não, dessa forma, suporte para determinadas
melhorias de transporte.
Vlahos et al. (1994) também chamam a atenção para o fato de que,
mesmo em casos em que de início haja um espírito colaborativo, em algumas
etapas do processo de planejamento, indivíduos ou grupos podem se tornar
56
antagônicos, especialmente quando há discordância sobre certos aspectos de
um projeto:
“Nessas situações, os participantes (grupos de interesse,
políticos e grupos de planejadores) disputam questões e seus
resultados, barganham e regateiam aspectos de projetos, negociam,
estabelecem acordos, e em alguns casos escondem informações de
seus oponentes para ganhar uma vantagem estratégica.”
Esses autores reconhecem que nos casos em que há antagonismo
excessivo, em algum instante, ele causará a ruptura de qualquer iniciativa de
planejamento interinstitucional, não importa a quantidade de elementos
computacionais de suporte utilizados.
Para aqueles autores, algumas das organizações podem apresentar
resistência à implantação de sistemas computacionais de apoio ao
planejamento, como o PLANiTS, devido principalmente a:
• falta de informação sobre sistemas de suporte a equipes: finalidade,
custos e benefícios;
• falta de recursos para sua implantação: humanos e monetários;
• receio do impacto da mudança por parte dos indivíduos.
Além das causas da resistência apontadas por Vlahos et al. (1994) e,
quiçá, até de maior importância é o fato de que, em muitos casos, essas
organizações são independentes umas das outras, principalmente se
pertencem a diferentes esferas de governo - como acontece, por exemplo, no
Município de São Paulo – o que inviabilizaria, na prática, a imposição de um
sistema computacional como o proposto por eles.
De fato, segundo Khattak e Kanafani (1997) o sistema PLANiTS ainda
não foi empregado em nenhum caso real. Como o seu desenvolvimento e
manutenção, nessas condições, requerem tempo e recursos financeiros
consideráveis, eles questionam quem iria fazê-lo, dada a natural desconfiança
que existe entre as diversas partes envolvidas.
57
2.4.6 Planejamento Cooperativo na Baía de São Francisco - 1997
A região da Baía de São Francisco (EUA) agrega nove condados
(Alameda, Contra Costa, Marin, Napa, San Francisco, San Mateo, Santa Clara,
Solano e Sonoma) constituindo-se numa estrutura institucional complexa. Na
área de transportes atuam entidades das esferas federal, estadual, regional e
local, além de diversas empresas de gestão e/ou operação de sistemas de
transporte.
A Comissão de Transportes Metropolitanos (MTC) é responsável pelo
planejamento do transporte regional e metropolitano.
Em cada condado existe uma Agência de Gestão de Congestionamento
de Tráfego (CMA), conforme determinado pela legislação do Estado da
Califórnia, em 1990. Cada CMA tornou-se responsável pela elaboração de um
Programa de Gestão de Congestionamento de Tráfego (CMP) e sua revisão a
cada dois anos, a partir de 1991. Para isso, a maioria dos CMAs da região da
Baía de São Francisco contratou consultores para desenvolver modelos
computacionais de demanda de viagens, sendo que algumas desenvolveram
seus sistemas internamente.
Dada a necessidade e a complexidade da coordenação do transporte na
região, a MTC coordenou uma parceria voluntária reunindo 35 entidades
responsáveis pela movimentação de pessoas e bens e pela proteção
ambiental. Essa parceria, segundo Knepper (1997), teve como objetivo a
melhoria da mobilidade na região pela troca de idéias, pelo estudo de
problemas comuns e pela busca de soluções inovadoras para os problemas do
congestionamento de tráfego e da poluição atmosférica.
Segundo Knepper (1997), uma pesquisa, não publicada, feita pela MTC
em 1992 constatou diferenças significativas nas entradas, metodologias de
modelagem, parâmetros, previsões e software entre os 18 modelos de previsão
de demanda de viagens, em uso na região da Baía de São Francisco.
Knepper (1997) afirma que modelos de demanda de viagens que
produzem estimativas divergentes de padrões de viagens constituem barreiras
ao estabelecimento de políticas e programas interinstitucionais. Dada a
58
necessidade de cooperação interinstitucional no processo de planejamento,
enfatizada também pelo disposto no ISTEA de 1991, passou a existir uma
preocupação maior com o problema da consistência da modelagem na região.
A estratégia escolhida para melhorar a consistência entre os modelos
utilizados pelas CMAs e aqueles utilizados pela MTC, foi a de identificar quais
as necessidades de dados e suas respectivas tolerâncias8. Para os CMPs de
1993, a ênfase foi sobre a consistência de demografias e no levantamento dos
modelos computacionais a serem desenvolvidos para que esses fossem
submetidos ao MTC.
Em 1994, o Departamento de Transportes do Estado da Califórnia –
Caltrans disponibilizou fundos para que, entre outras coisas, pudesse ser feita
uma avaliação das abordagens existentes em diferentes regiões metropolitanas
visando o aprimoramento da consistência entre os modelos computacionais
utilizados na região da Baía de São Francisco. Foi criado um subcomitê,
composto pelas principais entidades envolvidas em planejamento, para a
realização desse estudo, denominado Estudo da Coordenação da Modelagem
Regional (MCS).
O MCS buscou definir e avaliar as diferentes abordagens para a
obtenção da consistência da modelagem no nível regional e de condado. Uma
pesquisa
informal,
segundo
Knepper (1997),
constatou
que
poucas
organizações de planejamento metropolitano (MPOs) haviam tratado esta
questão. As regiões que possuíam modelos consistentes no nível regional e de
condado eram extremamente centralizadas, isto é, possuíam um único sistema
computacional mantido pela MPO e utilizado por todas as CMAs. O MCS
também não encontrou na literatura subsídios para a melhoria da consistência
entre modelos.
O MCS elaborou quatro opções para o desenvolvimento da consistência
da modelagem:
Opção 1 um único sistema de modelos computacionais mantido pela MTC e
utilizado por todas as CMAs. Esta abordagem, baseou-se em
8
Diferença entre o dado utilizado por uma CMA e o correspondente utilizado pela MTC, em
percentagem e/ou em valor absoluto, conforme o caso.
59
relacionamentos observados em outras regiões e representaria a
maior mudança institucional, pois centralizaria, na MTC, toda a
responsabilidade pela modelagem na região;
Opção 2 um
conjunto
único
de
modelos
computacionais
altamente
consistentes, disponibilizado para as CMAs para uso e refinamentos,
desenvolvido por meio da parceria existente entre a MTC e as MCAs.
Esta opção, considerada ideal, mas não encontrada em nenhuma
das regiões pesquisadas, envolvia o desenvolvimento de um
conjunto comum de modelos de demanda de viagens, incluindo
coeficientes e equações para geração e distribuição de viagens, para
posse de automóvel, para divisão modal e para atribuição de fluxos
de tráfego na rede de transportes;
Opção 3 monitoramento e controle sistemáticos da consistência de estrutura,
dos dados de entrada e o desempenho dos modelos computacionais
desenvolvidos pelas CMAs.
Esta abordagem, representava a
continuidade da abordagem de check-list que estava sendo estudada
para a região, com desenvolvimento contínuo de novos dados de
entrada e saída e seus níveis de tolerância;
Opção 4 modelos computacionais especializados para usos específicos,
talvez empregando uma check-list de hierarquia múltipla para o
monitoramento da consistência.
Esta abordagem manteria a
situação existente na região ao encorajar o emprego de diversos
modelos computacionais por cada condado, um para cada tipo de
aplicação.
O estudo concluiu que a melhor abordagem para o aprimoramento da
consistência entre modelos na região da Baía de São Francisco seria por meio
da Opção 2. Entretanto por causa de restrições de tempo, a melhor estratégia
de imediato seria pela Opção 3. Adicionalmente, foram feitas recomendações
para o desenvolvimento de um banco de dados regional (visando prover dados
de entrada consistentes para os modelos) e para a melhoria da coleta de dados
de uso do solo.
As recomendações sobre as tolerâncias para os dados de entrada e
saída, resultado da aplicação da Opção 3, foram incorporados aos CMPs de
1995, sendo posteriormente revisadas para os de 1997.
60
Paralelamente, iniciou-se o desenvolvimento de dois sistemas de
modelos computacionais, um, denominado MTCFCAST para ser utilizado pela
MTC e o outro, denominado BAYCAST (uma versão simplificada do
MTCFCAST) para uso pelas CMAs.
Segundo Knepper (1997), ambos
encontram-se em desenvolvimento, espera-se que os sistemas BAYCAST
sejam incorporados aos processos de previsão de demanda de viagens dos
CMPs de 1999.
Knepper (1997) identificou uma série de problemas não resolvidos, em
especial no caso da região da Baía de São Francisco, relativos à consistência
entre modelos, entre os quais:
• a necessidade de atualização, a cada dois anos, dos dados utilizados
pelas CMAs, em função da atualização das projeções demográficas,
produzidas pela ABAG9, e a conseqüente atualização das projeções
de demanda de viagens, pela MTC conforme regulamentação federal.
As CMAs questionam a relação custo/utilidade dessas atualizações;
• é comum não existirem dados de contagem de tráfego para
determinadas regiões em determinados espaços de tempo ou haver
falta de conhecimento sobre sua disponibilidade. Arquivos impressos
mal organizados ou bancos de dados inacessíveis contribuem para o
problema de acesso à informação. A MTC organizou uma parceria
para documentar fontes de dados disponíveis. Também espera
desenvolver um banco de dados regional contendo contagens de
tráfego observadas em vias expressas (freeways) para uso pela MTC,
Caltrans, CMAs e outras entidades;
• comparações detalhadas das múltiplas entradas e saídas dos
modelos computacionais das CMAs consomem tempo. A MCS irá, no
curto prazo, padronizar este processo e buscar o fortalecimento da
abordagem de autocertificação dos CMPs de 1997. O autor espera,
que nos anos subseqüentes, o uso do BAYCAST, juntamente com
9
ABAG - Associação dos Governos da Região da Baía de São Francisco.
61
dados de entrada consistentes, irá reduzir o trabalho envolvido nesse
processo.
2.4.7 Banco de Dados do PITU - Plano Integrado de Transportes
Urbanos - 1998
O PITU – Plano Integrado de Transportes Urbanos (Goldschmidt, 1996)
tem como característica buscar a integração institucional, coordenada pela
Secretaria dos Transportes Metropolitanos (STM), de planos que eram
desenvolvidos separadamente pela Companhia Metropolitana de São Paulo
(Metrô), Companhia Paulista de Trens Metropolitanos (CPTM) e Empresa
Metropolitana de Planejamento de São Paulo (EMPLASA). O PITU conta ainda
com a participação da Companhia de Tecnologia de Saneamento Básico do
Estado de São Paulo (CETESB), da Companhia de Engenharia de Tráfego do
Município de São Paulo (CET), das prefeituras dos 39 municípios da Região
Metropolitana de São Paulo (RMSP) e de outros órgãos gestores e/ou
operadores de transporte público da região.
Dentre os estudos que estão sendo atualizados, no PITU, está o São
Paulo Integrated Transport Study 2 (SPITS 2), realizado pela STM com a
consultoria da empresa Setepla Tecnometal Engenharia Ltda. (Setepla), por
meio do uso do modelo START - Strategic and Regional Transport Model
(Roberts e Simmonds, 1997) desenvolvido pela empresa britânica The MVA
Consultancy (MVA) e adaptado para a RMSP.
O START foi utilizado pela primeira vez (versão SPITS 1), no “Plano
Geral de Remodelação e Melhoria do Serviço de Transporte Coletivo na
Região Metropolitana de São Paulo”, desenvolvido durante o ano de 1993, na
STM, com a consultoria do Consórcio formado pela Setepla, Logit e MVA.
Um dos objetivos do plano foi o de obter, a curto prazo, um quadro de
referência para decisões governamentais e servir de base para entendimentos
com entidades de financiamento, alcançado com a elaboração do PMTI (Plano
Metropolitano Integrado de Transportes), que posteriormente deu origem ao
PITU.
62
O segundo objetivo consistiu na elaboração de uma ferramenta de
avaliação estratégica para uso dos técnicos da STM, o modelo de simulação
START.
Segundo relatório da empresa de consultoria Setepla (1997), o START
foi colocado em desuso com o passar do tempo. Um dos motivos foi a
dificuldade de uso do modelo devido à inexistência de uma interface
homem-máquina “amigável”, processos automatizados para agregação de
dados - o nível requerido por esse modelo é maior do que em outros, como o
EMME/2 (INRO, 1996) ou o Tranplan10 - além da inexistência de um banco de
dados com informações necessárias sobre a RMSP, ainda que desagregadas.
A STM identificou, antes do início do PITU, a necessidade de
monitoração e atualização desse plano, dentro de um processo permanente de
planejamento estratégico.
A estrutura da metodologia do planejamento
estratégico de transportes proposta pela Setepla (1998a) teve como base
aquela proposta e aplicada em estudos semelhantes em cidades do Reino
Unido por May (1991), e inclui o uso de um modelo de simulação apoiado no
START. Dessa forma, o START foi introduzido, novamente, em 1997, como
SPITS 2, parte integrante do PITU, por meio do contrato “Atualização e
Adaptação do Modelo Estratégico de Avaliação de Política de Transportes”,
firmado entre a STM e a Setepla.
Para viabilizar o uso continuado do modelo (SPITS 2) a STM foi
instrumentalizada com um sistema integrado automatizado, composto dos
modelos START e EFM (External Forecasting Model, para projeções de
demanda de transportes nos anos horizontes), de um conjunto de processos
para agregação de dados e do SDO (Strategy Data Organizer), um aplicativo
de organização dos dados agregados no formato requerido pelos modelos.
10
Informação sobre este modelo disponível na World Wide Web no site uag.world.com
63
Como conseqüência, tornou-se também necessária a consolidação de
um banco de dados necessário à utilização do instrumental concebido, pela
estruturação de todas as informações utilizadas no SPITS 1, ou seja, relativas
ao ano base de 1987 - incluindo as resultantes da Pesquisa O/D 87
(Metrô, 1990) - e anos horizonte de 2000 e 2020, descritas em Setepla (1998b),
além da preparação dos ambientes para a carga das informações relativas ao
ano base de 1997 (incluindo os resultantes da Pesquisa O/D 97).
A montagem de tal banco de dados foi realizada pela empresa Setepla
Tecnometal, com informações desagregadas (do ponto de vista do START),
obtidas de diversas fontes: METRÔ, CET, EMURB, SPTrans (antiga CMTC),
EMTU, .CPTM (trens de passageiros operados anteriormente pela CBTU e
FEPASA), EMPLASA e IBGE11.
O acesso ao banco de dados é feito por meio de um software aplicativo
denominado “Módulo Cadastral”, especialmente desenvolvido pela Setepla, ou
diretamente, por meio do próprio sistema gerenciador do banco de dados. O
“Módulo Cadastral” permite o gerenciamento dos dados por meio de uma
interface homem-máquina “amigável” e contém também os processos que
fazem as agregações desses dados para uso dos modelos START e EFM.
Além disso, permite a geração e a apresentação de indicadores para
comparação das diferentes estratégias analisadas.
Atualmente, o Banco de Dados utilizado para o SPITS é do tipo
centralizado e contém informações extraídas de diversas fontes, seja por meio
de disquetes ou por digitação de dados de relatórios. Por enquanto, sua
atualização está a cargo da STM ou de empresas de consultoria, contratadas
por ela, como a Setepla.
11
SPTrans – São Paulo Transporte S.A. (gestora de transporte coletivo por ônibus no Município
de São Paulo)
CMTC – Companhia Municipal de Transportes Coletivos (por ônibus)
CBTU – Companhia Brasileira de Transportes Urbanos (trens urbanos de passageiros)
FEPASA – Ferrovia Paulista S.A. (trens de passageiros e carga)
IBGE – Instituto Brasileiro de Geografia e Estatística
64
Tendo sido estabelecido que o processo de planejamento estratégico na
RMSP deva ser permanente, por meio de monitoração e atualização
periódicas, haverá a necessidade de se dispor sempre de dados atualizados.
Tudo indica que se, por exemplo, houver mudanças na rede viária do
Município de São Paulo (sob responsabilidade da CET) a SPTrans deverá ser
notificada, para efetuar as alterações em seu Banco de Dados e verificar se
produzem algum impacto sobre seu sistema (pode-se tratar inclusive de uma
oportunidade de melhoria dos serviços de ônibus), assim como a STM para
atualizar o Banco de Dados do PITU.
Da mesma forma, quaisquer alterações nas linhas de ônibus feitas pela
SPTrans deverão ser notificadas a outras entidades como a CET, EMTU e o
Metrô, para que estas atualizem seus Bancos de Dados, e também a STM para
que esta atualize o Banco de Dados do PITU.
2.5
Conclusão
A disponibilidade de dados para a tomada de decisões é sempre de
fundamental importância, especialmente no caso dos transportes urbanos. No
caso do planejamento e da gestão operacional de transportes urbanos, há
necessidade de se dispor tanto de dados históricos como atualizados,
armazenados em bancos de dados.
A falta de bancos de dados, atualizados e compartilhados, é um dos
fatores que dificulta, ou inviabiliza, a integração do planejamento e da gestão
de sistemas de transportes.
As diversas tentativas de integração de sistemas computacionais ou
mesmo de bancos de bancos, como elementos de suporte à integração do
planejamento e/ou gestão operacional de sistemas de transporte, apresentadas
neste capítulo não produziram os resultados desejados.
No caso do planejamento, é improvável que se consiga implantar e
manter um sistema centralizado, constituído de um único banco de dados,
acessado por diversas entidades politicamente independentes.
65
A construção de sistemas de dados distribuídos visando a integração
entre atividades e esferas de decisão, em uma mesma entidade, é por si só
uma tarefa complexa. Diversos problemas ainda carecem de uma solução
eficiente. Essa tarefa torna-se mais complexa quando se deseja integrar
atividades de diferentes entidades.
A concepção de sistemas de dados distribuídos, como elementos de
suporte ao planejamento e à gestão operacional de transportes, tanto no plano
interinstitucional como no plano intra-institucional, requer conhecimentos
especializados em duas áreas: ciência da computação e engenharia de
transportes.
Há necessidade de manter-se atualizado com relação aos avanços
tecnológicos da informática para que eles possam ser aplicados na solução de
problemas da engenharia de transportes.
Além disso, há necessidade de
haver um domínio conceitual que permita uma análise crítica dessas
tecnologias, que permita distinguir entre aquilo que é realmente aplicável e os
modismos, assim como levar em consideração aquilo que efetivamente
encontra-se disponível no mercado.
De posse desses conhecimentos deve-se buscar soluções para diversos
problemas ainda não resolvidos a contento, especialmente os que dizem
respeito à integração de bancos de dados, aplicados à engenharia de
transportes.