relatorioCISA - hidro.ufcg.edu.br

UNIVERSIDADE FEDERAL DE CAMPINA GRANDE - UFCG
Projeto CISA
Cooperação Internacional do Semi-árido
Damião Ribeiro de Almeida
Prestação de Serviços para Elaboração de
um Sistema de Informações Geográficas
Relatório Técnico dos Serviços 1, 2 e 3
Levantamento Inicial de
Escopo e Requisitos, Projeto Arquitetural
e Modelagem do Banco de Dados
© 2009 CISA – Todos os direitos reservados
Campina Grande, PB, setembro de 2009
Sumário
1.
INTRODUÇÃO ......................................................................................... 6
2.
ESCOPO DO SISTEMA ........................................................................... 7
2.1.
3.
PROJETO ARQUITETURAL ........................................................................................................ 7
REQUISITOS FUNCIONAIS .................................................................... 9
3.1
DESCRIÇÃO DOS REQUISITOS FUNCIONAIS ............................................................................... 9
3.2
REQUISITOS NÃO-FUNCIONAIS .............................................................................................. 12
3.2.1
Requisitos de Custo ...................................................................................................... 13
3.2.2
Requisitos de Segurança .............................................................................................. 13
3.2.3
Requisitos de Qualidade............................................................................................... 13
3.2.4
Requisitos de Interface ................................................................................................. 13
3.2.5
Requisitos de Confiabilidade........................................................................................ 14
3.2.6
Requisitos de Integração .............................................................................................. 14
3.2.7
Requisitos de Instalação ............................................................................................... 14
4.
ESQUEMA LÓGICO DO BANCO DE DADOS ...................................... 15
5.
HIDROGISLITE ...................................................................................... 17
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................. 19
ANEXO A – SCRIPT SQL DO BANCO DE DADOS ..................................... 20
2
Lista de Figuras
Figura 1: Arquitetura do SIGWeb ..................................................................... 8
Figura 2: Esquema lógico relacional do banco de dados ............................... 16
Figura 3: Uso da plataforma Flash em relação a outras plataformas [4] ........ 17
Figura 4: HidrogisLite com tecnologia Flex .................................................... 18
3
Lista de Tabelas
Tabela 1: Responsáveis por cada requisito funcional .................................... 11
4
Lista de Abreviaturas
CD
Compact disc
CISA
Cooperação Internacional do Semi-árido
CNPq
Conselho
Nacional
de
Desenvolvimento
Científico
e
Tecnológico
CTHIDRO
Fundo Setorial de Recursos Hídricos
DVD
Digital Video Disc
FINEP
Financiadora de Estudos e Projetos
RAM
Random Access Memory
UFCG
Universidade Federal de Campina Grande
UFPB
Universidade Federal da Paraíba
UFPE
Universidade Federal de Pernambuco
5
1. Introdução
O projeto CISA (Cooperação Internacional do Semi-árido) tem como
objetivo promover uma cooperação entre várias instituições de pesquisa para
desenvolver soluções para os problemas gerados pela escassez de água nas
regiões semi-áridas. Este projeto é financiado pelo Ministério de Ciência e
Tecnologia, com recursos do CTHIDRO - Fundo Setorial de Recursos
Hídricos, repassados através da FINEP e CNPq.
Uma das principais ações do CISA é desenvolver um sistema de
suporte a decisão em ambiente Web, o qual chamados de SIGWeb, que será
enviado à coordenação do CISA em Cabo Verde na África. Este sistema
contará com a participação de pesquisadores da UFCG, UFPB e UFPE.
O SIGWeb é a integração dos principais sistemas desenvolvidos pelas
diferentes instituições: cadastro integrado da UFPE, modelagem hidrológica
de UFPB e visualização de mapas através do Hidrogis [1] pela UFCG. Este
documento apresenta a arquitetura, os requisitos e o projeto do banco de
dados para o desenvolvimento do SIGWeb.
O restante do relatório está organizado como segue: a seção 2
descreve o escopo do sistema e sua arquitetura. A seção 3 apresenta os
requisitos funcionais e não-funcionais. A seção 4 descreve o esquema
conceitual do banco de dados. A seção 5 descreve como está sendo
desenvolvida a versão simplificada do Hidrogis. Por fim, o anexo A apresenta
o esquema lógico do banco de dados.
6
2. Escopo do Sistema
O escopo do SIGWeb engloba as necessidades básicas de cadastro
de dados de postos pluviométricos, fluviométricos e evaporimétricos; bacias e
sub-bacias hidrográficas; usuários de água; hidrografia, poços, ilhas,
municípios, etc. Alguns destes dados serão inseridos através de arquivos
shapefiles, outros terão um cadastro via Web para edição dos dados. Além
das informações cadastrais, o SIGWeb realizará a visualização de tais
informações através de mapas digitais na Web.
Os dados do SIGWeb serão armazenados e compartilhados através
de um banco de dados corporativo. Basicamente, o SIGWeb consiste na
integração de três módulos que serão detalhados a seguir.
2.1. Projeto Arquitetural
A arquitetura do sistema SIGWeb é apresentada na Figura 1. Os
módulos principais são: o cadastro integrado, a modelagem hidrológica e o
HidrogisLite.
O cadastro integrado é responsável por uma série de cadastros de
vários dados referentes à hidrologia, como dados de postos pluviométricos,
fluviométicos e evaporimétricos, dados de bacias e sub-bacias, rios e
usuários de água. Através do cadastro integrado, o usuário alimenta o banco
de dados espacial com novos dados que poderão ser exibidos no mapa
digitalizado.
O módulo HidrogisLite é uma versão simplificada do Hidrogis [1]. Este
módulo é responsável pela criação, configuração e visualização de mapas na
Web e pode ser alimentado pelos dados fornecidos pelo módulo de cadastro
integrado ou através de arquivos shapefiles, os quais terão os dados
extraídos e inseridos no banco de dados utilizando o programa shp2pgsql.
O módulo de modelagem hidrológica utiliza alguns modelos para
realizar simulações e obter comparações entre vazões observadas e
7
simuladas a e chuvas. Ele utiliza dados fornecidos pelo cadastro integrado
como entrada para os simuladores. Este módulo terá uma chamada dentro
do mapa, dessa forma, o usuário irá selecionar visualmente os postos
desejados e acionar um botão que irá invocar o módulo de modelagem
hidrológica.
Todos os módulos se integram via servidor de banco de dados
Postgresql, o qual também possui a extensão espacial Postgis para auxiliar o
módulo
HidrogisLite
nas
operações
espaciais
sobre
os
dados
georreferenciados.
O usuário terá acesso a todos esses recursos através de um portal, no
qual o usuário terá que se autenticar.
Figura 1: Arquitetura do SIGWeb
8
3. Requisitos Funcionais
Os requisitos funcionais descrevem as diversas funções que clientes e
usuários desejam que o software realize [2]. Em outras palavras, tais
requisitos definem a funcionalidade desejada do software. O termo função é
usado no sentido genérico de operação que pode ser realizada pelo sistema,
seja através de comandos dos usuários seja pela ocorrência de eventos
internos ou externos ao sistema.
A próxima seção descreve os requisitos funcionais do sistema.
3.1 Descrição dos requisitos funcionais
RF 1: [Cadastro]: Realiza a inclusão, edição, consulta e remoção dos dados
definidos no sistema.
RF 2: [Inserção de shapefiles]: para dados do tipo polígono e linhas, a
inserção no sistema se dará via shapefile. Neste caso, não haverá
edição de dados não espaciais via cadastro.
RF 3: [Atualização de dados via mapa]: o usuário poderá atualizar dados
do cadastro que estão sendo exibidos no mapa. Nesse requisito, devese verificar a permissão do usuário no acesso a esse recurso de
atualização do cadastro.
RF 4: [Gerar relatórios]: gerar relatórios contendo as séries históricas dos
postos fluviométricos, pluviométricos e informações cadastrais.
RF 5: [Gerenciamento de usuários]: o sistema deve permitir acesso apenas
aos usuários cadastrados no mesmo. Desta forma, deve-se ter
disponível um módulo que auxilie no cadastro (criação, remoção e
atualização) de usuários, definindo permissões de acesso às
funcionalidades e credenciais de acesso como login e senha.
RF 6: [Criação de mapas]: o sistema deve permitir a criação, edição e
remoção de mapas. O usuário poderá adicionar informações
9
provenientes do cadastro integrado ou de shapefiles, os quais serão
representados por camadas no mapa.
RF 7: [Visualização]: o sistema deve permitir a visualização dos mapas
criados pelo módulo HidrogisLite. A visualização dos mapas deve ser
composta por ferramentas de manipulação de mapas digitais, como,
operações de zoom in, zoom out, visão original e pan. Da mesma
forma, a visualização deve possuir ferramentas como: apresentação
de informações sobre os mapas visualizados (information), que
apresenta os dados sobre uma determinada feição e tooltip, que
apresenta dados sobre a identificação da feição ao clique do mouse.
RF 8: [Consulta textual]: a consulta textual consiste em permitir o usuário
montar consultas com base nos atributos não-espaciais e visualizar o
resultado através de tabelas ou no mapa.
RF 9: [Consulta espacial]: a consulta espacial possibilita ao usuário montar
consultas sobre as feições no mapa, como: sobreposição, buffer,
contém, se tocam, etc. Da mesma forma que na consulta textual, o
resultado da consulta espacial poderá ser visualizado através de uma
tabela ou no mapa.
RF 10: [Modelos]: o sistema deve permitir o usuário gerar dados de vazão
baseados em 3 modelos (MODHAC, SMAP, TANKMODEL) em escala
diária e mensal.
RF 11: [Polígonos de Thiessen]: Visualizar os polígonos de Thiessen com
base na influência de cada posto selecionado pelo usuário sobre uma
bacia previamente escolhida pelo mesmo.
RF 12: [Gerar gráficos dos modelos]: o sistema deve permitir o usuário
gerar gráficos a partir do resultado do cálculo dos modelos. Os poços
que servirão de entrada para os modelos serão selecionado
visualmente através do mapa.
RF 13: [Criação do Portal]: o portal do SIGWeb será responsável por
autenticar o usuário e lhe apresentar uma página inicial. Essa página
10
irá conter uma barra de ferramentas no qual o usuário irá escolher o
serviço que deseja utilizar: cadastro de bacia, cadastro de poços,
visualização de mapas, etc.
RF14: [Gerência de Usuários]: a gerência de usuários é um sub-módulo
dentro do portal do SIGWeb. Através desse sub-módulo, o
administrador do sistema poderá atribuir um perfil para cada usuário.
O perfil irá informar quais os recursos um grupo de usuários tem
permissão de acesso.
RF15: [Auditoria]: o SIGWeb deve salvar cada ação executada pelos
usuários para posterior averiguação de quem manuseou os dados do
sistema.
RF 16: [Documentação online]: o sistema irá conter um tutorial on-line para
auxiliar o usuário na utilização das diversas funcionalidades.
Cada requisito possui uma instituição responsável por implementá-la
como pode ser visto na Tabela 1.
Tabela 1: Responsáveis por cada requisito funcional
Instituições
UFCG
UFPE
UFPB
Requisitos
RF1
RF2
RF3
RF4
RF5
RF6
RF7
RF8
RF9
RF10
RF11
RF12
RF13
RF14
RF15
RF16
X
X
X
X
X
X
X
X
X
X
X
X
X (CIVIL)
X
X
X
X
X
11
No requisito funcional RF16, cada instituição irá desenvolver a
documentação on-line do módulo de sua responsabilidade. Para o
HidrogisLite, o grupo da Unidade Acadêmica de Engenharia Civil da UFCG,
sob responsabilidade da Dra. Iana Alexandra Alves Rufino, será responsável
por desenvolver a documentação on-line da parte de gerenciamento de
mapas.
3.2
Requisitos Não-Funcionais
Esta seção enumera os requisitos não-funcionais que devem ser
satisfeitos pelo sistema. Requisitos não-funcionais são as qualidades globais
de um software, como manutenibilidade, usabilidade, custos e várias outras.
Estruturamos os requisitos não funcionais da seguinte forma:

Requisitos de Custo: estabelecem os requisitos de Hardware e
Software necessários à execução do sistema.

Requisitos de Qualidade: tratam sobre a verificação da qualidade de
projeto, bem como a conformidade, que é a medida de quão o
software produzido está seguindo as regras de projeto definidas.

Requisitos de Interface: tratam sobre o grau de usabilidade,
ergonomia e interação homem-máquina que a interface deve atender,
bem como as especificações técnicas para que a interface cumpra o
seu objetivo especificado.

Requisitos de Confiabilidade: definem e medem a capacidade que o
software possui de operar sem ocorrência de falhas durante um
período especificado de tempo em um determinado ambiente.

Requisitos de Integração: tratam da capacidade que o software deve
possuir de interagir e interoperar com outros sistemas, de acordo com
o especificado.

Requisitos de Instalação: especificam os requisitos de ambiente em
que o produto será instalado, bem como o esforço necessário para se
instalar o produto.
12
3.2.1 Requisitos de Custo
[Hardware] O sistema deve ser executável em servidor robusto, com alta
disponibilidade e vazão para suportar a carga a ser processada. A
configuração mínima recomendada Processador Quad Core Intel
Xeon, 6M Cache, 3Ghz, 4GB RAM, 2 discos de 250Gb, leitor de
CD/DVD, Adaptador de rede Ethernet.
[SoftwareBásico] O sistema deve ser executável em plataforma de software
tipo Linux, com software de apoio (Tomcat, Apache, etc.) gratuito.
3.2.2 Requisitos de Segurança
[Papéis] Os usuários do sistema deverão ser cadastrados e um papel
atribuído a cada usuário. O sistema só deve permitir o acesso a
usuários autorizados, com exceção de mapas que serão abertos ao
público conforme a escolha do usuário.
[Identificação] O login de usuários é obrigatório e a identidade do usuário
deve ser confirmada através de mecanismos de autenticação
(senha, por exemplo). Estas senhas devem ser protegidas.
[Auditoria] O sistema deverá ter um mecanismo de auditoria através do uso
de um log de logins que indica quem fez o quê e quando no sistema.
Toda informação de auditoria deve estar protegida para uso restrito
aos usuários autorizados.
3.2.3 Requisitos de Qualidade
[Documentação]
O
sistema
deve
dispor
de
documentação
de
desenvolvimento (JavaDoc); de instalação (Guia do Instalador); uso
(Guia do Usuário) e help on-line (auxílio rápido através de tooltips).
3.2.4 Requisitos de Interface
[Browser] O sistema deve ter interface amigável e ergonômica, e deve
necessariamente ser acessível via browser Web.
13
[Usabilidade] O sistema deverá ser amigável podendo ser facilmente
utilizado após um treinamento básico. Pode-se supor que o usuário
já tenha familiaridade com o uso básico de computadores,
navegação Web e sistemas de informação.
3.2.5 Requisitos de Confiabilidade
[ReinícioAutomático] O sistema deve ter capacidade de recuperação,
devendo
ser
dotado
de
mecanismo
de
reinício
automático
(watchdog) sempre que se tornar instável ou indisponível.
[Erros] O sistema deve reportar qualquer erro com mensagens explicativas.
Não se devem expor mensagens internas (do tipo “Null Pointer
Exception”) para o usuário. Toda ocorrência de erro que não seja
causada por erro remediável pelo usuário deve ser registrada em log
para posterior análise pelos desenvolvedores.
3.2.6 Requisitos de Integração
[SGBD] Para suprir necessidades de persistência de dados, o banco de
dados deverá ter suporte a geoprocessamento. Outros mecanismos
de persistência (arquivos, etc.) podem ser utilizados, desde que não
impliquem na instalação de middleware adicional.
3.2.7 Requisitos de Instalação
[Instalação] O sistema deve dispor de mídia de instalação em DVD, que
permita a instalação completa do mesmo com o mínimo de
intervenção do instalador. Os requisitos de instalação devem ser
claramente explicitados.
[InstruçõesInstalação] A mídia de instalação deve conter instruções
básicas de como proceder ao processo de instalação (arquivo
leiame.txt).
14
4. Esquema Lógico do Banco de Dados
Esta seção descreve o projeto lógico do banco de dados. Através
desse esquema é possível visualizar as tabelas que serão criadas no banco
de dados e serão alimentadas pelo módulo de cadastro integrado; visualizálas num mapa, e realizar consultas. Para cada tabela, é possível visualizar os
possíveis atributos e o tipo de cada um.
A Figura 2 mostra o esquema lógico relacional do banco de dados,
usando a notação UML [3]. É possível observar como as tabelas estão
relacionadas. A primeira tabela no esquema é a tabela “tb_usuário”. Essa
tabela armazena informações sobre os usuários do sistema. Todo usuário
deve possuir um perfil associado. Este perfil descreve que funcionalidades
um grupo de usuário pode acessar no SIGWeb.
A tabela “tb_permissao” armazena as possíveis ações do sistema, por
exemplo: cadastro de poço fluviométrico, edição de bacia, visualização de
mapas, etc. Esse conjunto de tabelas, juntamente com a tabela de auditoria,
pertence à parte do sistema responsável pela segurança.
Um segundo conjunto de tabelas é responsável por armazenar dados
cadastrais
de
hidrologia.
Essas
tabelas
correspondem
aos
postos
pluviométricos, fluviométricos e evaporimétricos, sub-bacias e bacias, rios,
ilhas, municípios e usuários de água.
O terceiro grupo de tabelas é responsável por armazenar informações
de criação dos mapas. A tabela “tb_mapa” armazena o nome do mapa e o
bounding box. Cada mapa é formado por um conjunto de categorias que por
sua vez é formado por um conjunto de camadas. A tabela “tb_projecao”
informa quais informações poderão ser exibidas no mapa para cada camada.
A tabela “tb_unit_definition” informa que tabela do banco de dados e qual a
coluna espacial a camada do mapa representa.
O script SQL do banco de dados, usando sintaxe Postgresql/Postgis
pode ser encontrado no Anexo A.
15
Figura 2: Esquema lógico relacional do banco de dados
16
5. HidrogisLite
O HidrogisLite é uma versão simplificada do Hidrogis[1] que usa o Flex
como interface de visualização do mapa. Flex é uma tecnologia criada pela
Adobe para facilitar o desenvolvimento de aplicações Web com tecnologia
Flash. Em comparação ao SVG, o Flex sofre menos com problemas de
incompatibilidades de browsers. A Figura 3 mostra como a plataforma Flash é
amplamente usada em relação às outras plataformas.
Figura 3: Uso da plataforma Flash em relação a outras plataformas [4]
O HidrogisLite se encontra em fase de desenvolvimento, mas alguns
resultados já podem ser notados na Figura 4. Na parte onde se encontra o
círculo de número 1 está a árvore de camadas. Cada camada possui uma
legenda que indica o seu tipo. O quadrado indica que a camada é do tipo
polígono, o círculo indica que a camada é do tipo ponto e o traço indica que a
camada é do tipo linha. A parte onde se encontra o círculo 2 é a área de
visualização do mapa. Ao lado do círculo 3 se encontram os botões de pan,
17
zoom e visão original. Ao lado do círculo 4 estão as operações de busca de
feição, mostrar informação e limpar o mapa. O círculo 5 mostram as
coordenadas do mapa que são atualizadas conforme o movimento do mouse.
Por fim, o círculo 6 indica a escala do mapa. Essas funcionalidades ainda
estão sendo aperfeiçoadas, principalmente o desempenho da carga das
camadas mais pesadas como o contorno das ilhas, as estradas e as linhas
de contorno. Estão sendo empregadas técnicas de pré-formatação da
camada e de carga em um nível de zoom. A primeira técnica consiste em
formatar a camada no momento da criação do mapa, o que retiraria o
processo de formatação da mesma no momento de sua requisição. A
segunda técnica consiste em exibir a camada apenas num nível de zoom em
que ela pode ser melhor analisada, por exemplo, não faz sentido mostrar
todas as estradas no nível de zoom apresentado na Figura 4. Portanto, as
estradas só seriam carregadas quando o usuário aproximar o mapa no nível
de zoom em que as estradas possam ser visualizadas de forma adequada.
2
3
1
6
4
5
Figura 4: HidrogisLite com tecnologia Flex
18
Referências Bibliográficas
[1] Hidrogis, <http://www.lsi.dsc.ufcg.edu.br/~hidrogis>, último acesso em
setembro de 2009.
[2] R. PRESSMAN. Engenharia de Software 6ª Edição. Editora McGraw-Hill,
2006.
[3] Fowler, Martin. “UML Distilled Third Edition: A Brief Guide to the Standard
Object Modeling Language", Addison-Wesley Professional, 3ª Edição, 2003.
[4] Cole, Alaric. “Learning Flex 3 Getting up to Speed With Rich Internet
Applications”, O'Reilly, 1ª Edição, 2008.
19
Anexo A – Script SQL do Banco de Dados
BEGIN;
--------------------------- Segurança do sistema --------------------------CREATE SEQUENCE SQ_USUARIOS;
CREATE TABLE TB_USUARIOS (
CD_USUARIO INT NOT NULL DEFAULT nextval('SQ_USUARIOS'),
CD_PERFIL INT,
NM_USUARIO VARCHAR(200),
DS_IDENTIDADE VARCHAR(50)
);
CREATE SEQUENCE SQ_PERFIL;
CREATE TABLE TB_PERFIL (
CD_PERFIL INT NOT NULL DEFAULT nextval('SQ_PERFIL'),
NM_PERFIL VARCHAR(50),
DS_PERFIL TEXT
);
CREATE SEQUENCE SQ_PERMISSOES;
CREATE TABLE TB_PERMISSOES (
CD_PERMISSAO
INT
NOT
NULL
DEFAULT
nextval('SQ_PERMISSOES'),
CD_PERFIL INT,
NR_CAD_POSTOS_PLU INT DEFAULT 0,
NR_CAD_POSTOS_FLU INT DEFAULT 0,
NR_CAD_POSTOS_EVP INT DEFAULT 0,
NR_CAD_ESTACOES INT DEFAULT 0,
20
NR_CAD_MUNICIPIOS INT DEFAULT 0,
NR_CAD_BACIAS INT DEFAULT 0,
NR_CAD_SUBBACIAS INT DEFAULT 0,
NR_CAD_OBRAS_HIDRICAS INT DEFAULT 0,
NR_CAD_USUARIOS_AGUA INT DEFAULT 0,
NR_CAD_POCOS INT DEFAULT 0,
NR_CAD_CISTERNAS INT DEFAULT 0,
NR_DADOS_CHUVA INT DEFAULT 0,
NR_DADOS_VAZAO INT DEFAULT 0,
NR_DADOS_EVP INT DEFAULT 0,
NR_DADOS_CLIM INT DEFAULT 0
);
CREATE SEQUENCE SQ_AUDITORIA;
CREATE TABLE TB_AUDITORIA (
CD_AUDITORIA INT NOT NULL DEFAULT nextval('SQ_AUDITORIA'),
CD_USUARIO INT NOT NULL,
DT_EVENTO DATE,
DS_ACAO TEXT
);
-- Constraints das PK
ALTER TABLE TB_USUARIOS ADD CONSTRAINT PK_USUARIOS PRIMARY
KEY(CD_USUARIO);
ALTER TABLE TB_PERFIL ADD CONSTRAINT PK_PERFIL PRIMARY
KEY(CD_PERFIL);
ALTER TABLE TB_PERMISSOES ADD CONSTRAINT PK_PERMISSOES
PRIMARY KEY(CD_PERMISSAO);
ALTER
TABLE
TB_AUDITORIA
ADD
CONSTRAINT PK_AUDITORIA
PRIMARY KEY(CD_AUDITORIA);
21
ALTER
TABLE
TB_AUDITORIA
ADD
CONSTRAINT
FK_AUDITORIA_USUARIO FOREIGN KEY(CD_AUDITORIA) REFERENCES
TB_USUARIOS(CD_USUARIO);
-- Constraints da FK
ALTER TABLE TB_USUARIOS ADD CONSTRAINT FK_USUARIOS_PERFIL
FOREIGN KEY (CD_PERFIL) REFERENCES TB_PERFIL (CD_PERFIL);
ALTER
TABLE
FK_PERMISSOES_PERFIL
TB_PERMISSOES
FOREIGN
KEY
ADD
CONSTRAINT
(CD_PERFIL)
REFERENCES
TB_PERFIL (CD_PERFIL);
--------------------------- Gerência de mapas ---------------------------
CREATE SEQUENCE SQ_MAPAS;
CREATE TABLE TB_MAPAS (
CD_MAPA INT NOT NULL DEFAULT nextval('SQ_MAPAS'),
NM_MAPA VARCHAR(50),
NR_MAX_X NUMERIC,
NR_MAX_Y NUMERIC,
NR_MIN_X NUMERIC,
NR_MIN_Y NUMERIC
);
CREATE SEQUENCE SQ_CATEGORIAS;
CREATE TABLE TB_CATEGORIA(
CD_CATEGORIA
INT
NOT
NULL
DEFAULT
nextval('SQ_CATEGORIAS'),
CD_MAPA INT NOT NULL,
NM_CATEGORIA VARCHAR(50)
);
22
CREATE SEQUENCE SQ_CAMADAS;
CREATE TABLE TB_CAMADA (
CD_CAMADA INT NOT NULL DEFAULT nextval('SQ_CAMADAS'),
CD_CATEGORIA INT NOT NULL,
CD_UNIT INT,
NM_CAMADA VARCHAR(50),
BL_VISIVEL BOOLEAN,
DS_FILLCOLOR VARCHAR(10),
DS_STROKEWIDTH VARCHAR(10),
DS_STROKECOLOR VARCHAR(10),
NR_RAIO NUMERIC
);
CREATE SEQUENCE SQ_UNIT;
CREATE TABLE TB_UNIT_DEFINITION (
CD_UNIT INT NOT NULL DEFAULT nextval('SQ_UNIT'),
NM_UNIT VARCHAR(50),
-- nome da unit
DS_GEOM VARCHAR(50),
-- nome da coluna espacial
DS_CHAVE VARCHAR(50),
-- nome da coluna da PK
DS_FONTE VARCHAR(50)
-- nome da tabela fonte
);
CREATE SEQUENCE SQ_PROJECAO;
CREATE TABLE TB_PROJECAO (
CD_PROJECAO INT NOT NULL DEFAULT nextval('SQ_PROJECAO'),
CD_CAMADA INT NOT NULL,
DS_PROJECAO VARCHAR(200),
DS_ALIAS VARCHAR(200),
DS_UNIDADE VARCHAR(10)
);
23
-- Constraint das PK
ALTER TABLE TB_MAPAS ADD CONSTRAINT PK_MAPAS PRIMARY KEY
(CD_MAPA);
ALTER TABLE TB_CATEGORIA ADD CONSTRAINT PK_CATEGORIA
PRIMARY KEY (CD_CATEGORIA);
ALTER TABLE TB_CAMADA ADD CONSTRAINT PK_CAMADA PRIMARY
KEY (CD_CAMADA);
ALTER
TABLE
TB_UNIT_DEFINITION
ADD
CONSTRAINT
PK_UNIT
PRIMARY KEY (CD_UNIT);
ALTER
TABLE
TB_PROJECAO
ADD
CONSTRAINT
PK_PROJECAO
PRIMARY KEY (CD_PROJECAO);
-- Constraint das FK
ALTER
TABLE
FK_CATEGORIA_MAPAS
TB_CATEGORIA
FOREIGN
KEY
ADD
CONSTRAINT
(CD_MAPA)
REFERENCES
TB_MAPAS (CD_MAPA);
ALTER
TABLE
TB_CAMADA
FK_CAMADAS_CATEGORIAS
FOREIGN
ADD
KEY
CONSTRAINT
(CD_CATEGORIA)
REFERENCES TB_CATEGORIA (CD_CATEGORIA);
ALTER
TABLE
TB_PROJECAO
ADD
CONSTRAINT
FK_PROJECAO_CAMADAS FOREIGN KEY (CD_CAMADA) REFERENCES
TB_CAMADA (CD_CAMADA);
--------------------------- Tabelas do Cadastro ---------------------------
CREATE SEQUENCE SQ_POSTOS_PLU;
CREATE TABLE TB_POSTOS_PLU (
CD_POSTO_PLU
INT
NOT
NULL
DEFAULT
nextval('SQ_POSTOS_PLU'),
CD_BACIA INT,
24
CD_SUBBACIA INT,
NM_POSTO_PLU VARCHAR (200)
);
CREATE SEQUENCE SQ_POSTOS_EVP;
CREATE TABLE TB_POSTOS_EVP (
CD_POSTO_EVP
INT
NOT
NULL
DEFAULT
nextval('SQ_POSTOS_EVP'),
CD_BACIA INT,
CD_SUBBACIA INT,
NM_POSTO_EVP VARCHAR (200),
NR_COEFICIENTE NUMERIC,
NR_TAXA_EVP NUMERIC
);
CREATE SEQUENCE SQ_POSTO_FLU;
CREATE TABLE TB_POSTO_FLU (
CD_POSTO_FLU INT NOT NULL DEFAULT nextval('SQ_POSTO_FLU'),
CD_BACIA INT,
CD_SUBBACIA INT,
NM_POSTO VARCHAR (200)
);
CREATE SEQUENCE SQ_BACIAS;
CREATE TABLE TB_BACIAS (
CD_BACIA INT NOT NULL DEFAULT nextval('SQ_BACIAS'),
NM_BACIA VARCHAR (200),
NR_PERC_IMPERM NUMERIC -- percentual de impermeabilidade
);
CREATE SEQUENCE SQ_SUBBACIAS;
CREATE TABLE TB_SUBBACIAS (
25
CD_SUBBACIA INT NOT NULL DEFAULT nextval('SQ_SUBBACIAS'),
CD_BACIA INT NOT NULL,
NM_SUBBACIA VARCHAR (200),
NR_PERC_IMPERM NUMERIC -- percentual de impermeabilidade
);
CREATE SEQUENCE SQ_MUNICIPIOS;
CREATE TABLE TB_MUNICIPIOS (
CD_MUNICIPIO INT NOT NULL DEFAULT nextval('SQ_MUNICIPIOS'),
NM_MUNICIPIO VARCHAR (200),
NR_POPULACAO INT
);
CREATE SEQUENCE SQ_USUARIOS_AGUA;
CREATE TABLE TB_USUARIOS_AGUA (
CD_USUARIO_AGUA
INT
NOT
NULL
DEFAULT
nextval('SQ_USUARIOS_AGUA'),
CD_MUNICIPIO INT,
NM_USUARIO VARCHAR (200),
DS_IDENTIDADE VARCHAR (50)
);
-- Criando as colunas espaciais
SELECT AddGeometryColumn('', 'public', 'TB_POSTOS_PLU', 'gm_geometria',
4326, 'POINT', 2);
SELECT AddGeometryColumn('', 'public', 'TB_POSTOS_EVP', 'gm_geometria',
4326, 'POINT', 2);
SELECT AddGeometryColumn('', 'public', 'TB_POSTOS_FLU', 'gm_geometria',
4326, 'POINT', 2);
SELECT AddGeometryColumn('', 'public', 'TB_BACIAS', 'gm_geometria', 4326,
'MULTIPOLYGON', 2);
26
SELECT AddGeometryColumn('', 'public', 'TB_SUBBACIAS', 'gm_geometria', 4326,
'MULTIPOLYGON', 2);
SELECT AddGeometryColumn('', 'public', 'TB_RIOS', 'gm_geometria', 4326,
'MULTILINESTRING', 2);
SELECT AddGeometryColumn('', 'public', 'TB_ILHAS', 'gm_geometria', 4326,
'MULTIPOLYGON', 2);
SELECT AddGeometryColumn('', 'public', 'TB_MUNICIPIOS', 'gm_geometria',
4326, 'MULTILINESTRING', 2);
SELECT
AddGeometryColumn('',
'public',
'TB_USUARIOS_AGUA',
'gm_geometria', 4326, 'POINT', 2);
-- Constraints da PK
ALTER TABLE TB_POSTOS_PLU ADD CONSTRAINT PK_POSTOS_PLU
PRIMARY KEY (CD_POSTO_PLU);
ALTER TABLE TB_POSTOS_EVP ADD CONSTRAINT PK_POSTOS_EVP
PRIMARY KEY (CD_POSTO_EVP);
ALTER TABLE TB_POSTOS_FLU ADD CONSTRAINT PK_POSTOS_FLU
PRIMARY KEY (CD_POSTO_FLU);
ALTER TABLE TB_BACIAS ADD CONSTRAINT PK_BACIAS PRIMARY KEY
(CD_BACIA);
ALTER TABLE TB_SUBBACIAS ADD CONSTRAINT PK_SUBBACIAS
PRIMARY KEY (CD_SUBBACIA);
ALTER TABLE TB_RIOS ADD CONSTRAINT PK_RIOS PRIMARY KEY
(CD_RIO);
ALTER TABLE TB_ILHAS ADD CONSTRAINT PK_ILHAS PRIMARY KEY
(CD_ILHA);
ALTER TABLE TB_MUNICIPIOS ADD CONSTRAINT PK_MUNICIPIOS
PRIMARY KEY (CD_MUNICIPIO);
ALTER
TABLE
TB_USUARIOS_AGUA
ADD
CONSTRAINT
PK_USUARIOS_AGUA PRIMARY KEY (CD_USUARIO_AGUA);
27
-- Constraints da FK
ALTER
TABLE
FK_POSTOS_PLU_BACIAS
TB_POSTOS_PLU
FOREIGN
KEY
ADD
CONSTRAINT
(CD_BACIA)
REFERENCES
ADD
CONSTRAINT
TB_BACIAS (CD_BACIA);
ALTER
TABLE
TB_POSTOS_PLU
FK_POSTOS_PLU_SUBBACIAS
FOREIGN
KEY
(CD_SUBBACIA)
REFERENCES TB_SUBBACIAS (CD_SUBBACIA);
ALTER
TABLE
FK_POSTOS_EVP_BACIAS
TB_POSTOS_EVP
FOREIGN
KEY
ADD
CONSTRAINT
(CD_BACIA)
REFERENCES
ADD
CONSTRAINT
TB_BACIAS (CD_BACIA);
ALTER
TABLE
TB_POSTOS_EVP
FK_POSTOS_EVP_SUBBACIAS
FOREIGN
KEY
(CD_SUBBACIA)
REFERENCES TB_SUBBACIA (CD_SUBBACIA);
ALTER
TABLE
FS_POSTOS_PLU_BACIAS
TB_POSTOS_PLU
FOREIGN
KEY
ADD
CONSTRAINT
(CD_BACIA)
REFERENCES
ADD
CONSTRAINT
TB_BACIAS (CD_BACIA);
ALTER
TABLE
TB_POSTOS_PLU
FK_POSTOS_FLU_SUBBACIAS
FOREIGN
KEY
(CD_SUBBACIA)
REFERENCES TB_SUBBACIAS (CD_SUBBACIA);
ALTER
TABLE
FK_SUBBACUAS_BACIA
TB_SUBBACIAS
FOREIGN
KEY
ADD
CONSTRAINT
(CD_BACIA)
REFERENCES
TB_BACIAS (CD_BACIA);
ALTER TABLE TB_RIOS ADD CONSTRAINT FK_RIOS_BACIAS FOREIGN
KEY (CD_BACIA) REFERENCES TB_BACIAS (CD_BACIA);
28
ALTER TABLE TB_RIOS ADD CONSTRAINT FK_RIOS_ILHAS FOREIGN
KEY (CD_ILHA) REFERENCES TB_ILHAS (CD_ILHA);
ALTER
TABLE
FK_MUNICIPIOS_ILHAS
TB_MUNICIPIOS
FOREIGN
KEY
ADD
CONSTRAINT
(CD_ILHA)
REFERENCES
TB_ILHAS (CD_ILHA);
ALTER
TABLE
TB_USUARIOS_AGUA
FK_USUARIOS_AGUA_MUNICIPIOS
FOREIGN
ADD
KEY
CONSTRAINT
(CD_MUNICIPIO)
REFERENCES TB_MUNICIPIOS (CD_MUNICIPIO);
END;
29