Gisbr2001 PDF

Estruturao e Modelagem de
Bancos de Dados
Jugurta Lisboa Filho
Universidade Federal de Viosa
Departamento de Informtica
36570-000 Viosa/MG Brasil
E-mail: jugurta@dpi.ufv.br
Curitiba-PR, maio de 2001

SUMRIO
1 CONCEITOS EM SISTEMAS DE BANCO DE DADOS 1

1.1 Banco de Dados (BD) 1
1.2 Sistema de Gerenciamento de Banco de Dados (SGBD) 1
1.3 Programa de Aplicao 2
1.4 Sistema de Banco de Dados (SBD) 2
1.5 Fases do Projeto de Banco de Dados 4
1.6 Modelos de Dados 5
2 NOES BSICAS DO MODELO RELACIONAL 6

2.1 Modelo Relacional 6
2.2 lgebra Relacional 7
2.3 SQL Linguagem de Consulta Estruturada 10
3 PROJETO DE BANCO DE DADOS 13

3.1 Processo de Modelagem Conceitual 13
3.2 Modelo Entidade-Relacionamento (E-R) 14
3.3 Projeto Lgico de Banco de Dados 16
3.4 Ferramentas CASE 20
4 PROJETO DE BANCOS DE DADOS GEOGRFICOS 22

4.1 Dado, Informao e Fenmeno Geogrfico 22
4.2 Requisitos de Modelagem para Aplicaes de SIG 24
4.3 Modelando Banco de Dados Geogrficos com UML-GeoFrame 27
4.4 Projeto Lgico de Banco de Dados Geogrficos 33
4.5 Estudo de Caso 36
5 BIBLIOGRAFIA 39
CURSO Estruturao e Modelagem de Bancos de Dados
1 CONCEITOS EM SISTEMAS DE BANCO DE DADOS

O componente de armazenamento de um Sistema de Informao Geogrfica (SIG),
denominado sistema de banco de dados geogrficos, estrutura e armazena os dados de forma a
possibilitar a realizao das operaes de anlise e consulta. Devido complexidade das aplicaes
que so desenvolvidas a partir de um SIG, projetar o banco de dados geogrficos tem sido um dos
grandes desafios para as organizaes usurias desses sistemas.
O desenvolvimento de aplicaes de SIG tem sido feito, normalmente, de forma no
metodolgica, tendo como resultado diversos problemas decorrentes de abordagens evolutivas
desordenadas.
O projeto de um banco de dados deve ser realizado com o apoio de um modelo de dados de
alto nvel, tambm conhecido como modelo conceitual. Durante vrios anos, as pesquisas no campo
dos modelos de dados para SIG centraram-se na busca por estruturas de dados para o
armazenamento de dados georreferenciados, o que ficou conhecido como debate raster-vector
[COU 92]. Atualmente, sabe-se que para o projeto de banco de dados geogrficos so necessrios
novos modelos conceituais. Essa necessidade foi identificada j no final da dcada de 80. Desde
ento, diversos modelos especficos para modelagem de dados em aplicaes de SIG tm sido
propostos na literatura.
O objetivo deste curso apresentar uma metodologia atual para estruturao e modelagem
conceitual de dados geogrficos, utilizando tcnicas bem consolidadas de projeto de banco de dados
(ex.: Modelo E-R) e, tambm, tcnicas mais modernas, como a linguagem UML. A fim de fornecer
uma base conceitual sobre Sistemas de Bancos de Dados, neste captulo so apresentados diversos
conceitos relacionados a Sistema de Gerenciamento de Banco de Dados (SGBD) relacional.
Esta apostila uma nova edio da apostila utilizada nos cursos Banco de Dados para GIS,
apresentado no GISBrasil`99 e Estruturao e Modelagem de Banco de Dados, apresentado no
GIS Brasil`2000.
1.1 Banco de Dados (BD)

Por banco de dados entende-se a coleo dos dados propriamente dita. Algumas definies de
banco de dados encontrada na literatura incluem: Um banco de dados uma coleo de dados
relacionados [ELM 00]; Um banco de dados uma coleo de dados operacionais armazenados,
sendo usados pelos sistemas de aplicao de uma determinada organizao [DAT 81].
Um banco de dados pode ser mantido manualmente ou por computador. Por exemplo, imagine
um banco de dados composto de fichas de publicaes em uma biblioteca. Um banco de dados
sempre povoado com dados para um propsito especfico, ou seja, ele contm informaes que
circulam pela aplicao e elementos da prpria aplicao. Numa aplicao de distribuio de energia
eltrica, por exemplo, o banco de dados armazena a descrio de cada consumidor mas tambm
contm dados sobre o consumo mensal de cada consumidor.
Os dados armazenados em um banco de dados devem respeitar as regras da aplicao,
definidas pelas restries de integridade. Por exemplo, se existe uma restrio do tipo o consumo de
energia eltrica no pode ser negativo, no pode haver nenhum registro de consumo de energia cujo
valor seja negativo.
1.2 Sistema de Gerenciamento de Banco de Dados (SGBD)

Um Sistema de Gerenciamento de Banco de Dados constitui-se de uma coleo de programas
que permite criar e manter o BD. Assim, um SGBD um software de propsito geral que facilita o
processo de definio, construo e manipulao do BD. Por software de propsito geral entende-se
que o SGBD usado no como uma ferramenta final, mas como um software atravs do qual os
programas de aplicao (descritos a seguir) so desenvolvidos.
Curitiba - PR - Brasil - 14 a 18 Maio 2001 1

As principais caractersticas de um SGBD incluem o suporte a:

Definio do BD - especificao e descrio detalhada dos tipos, estruturas e restries dos
dados a serem armazenados no BD;
Construo do BD - processo de carga inicial dos dados em um meio de armazenamento
controlado pelo SGBD;
Manipulao do BD - abrange as alteraes realizadas nos dados para refletir mudanas
ocorridas no ambiente. Isto inclui as operaes de incluso e excluso de dados;
Consulta aos dados - tipo de operao mais comum realizada por usurios que necessitam
extrair informaes armazenadas no BD.
1.3 Programa de Aplicao

Os programas de aplicao so sistemas desenvolvidos para um propsito especfico (ex.:
sistema de estoque, sistema de vendas, folha de pagamento). Todo o acesso e manipulao de
dados realizado pelo programa de aplicao feito por intermdio do SGBD. Assim, o programa de
aplicao realiza as funes da aplicao, enquanto o SGBD serve de base para o gerenciamento
dos dados manipulados pelo programa de aplicao.
Um exemplo de programa de aplicao um sistema de controle de consumo de energia
eltrica. Uma de suas funes seria executar o clculo do consumo mensal de energia eltrica, a
partir dos dados de leitura dos medidores. O algoritmo que descreve a poltica de cobrana de acordo
com a quantidade consumida e o tipo de consumidor implementado pelo programa de aplicao,
enquanto o acesso aos dados referentes ao consumo de eletricidade e aos consumidores feito
atravs do SGBD. O programa de aplicao garante restries de integridade que no podem ser
controladas pelo SGBD.
O programa de aplicao implementa interface e relatrios especficos como, por exemplo,
emisso de extrato de consumo, enquanto o SGBD pode ser usado para possibilitar ao usurio
elaborar consultas eventuais (ad hoc), no previstas / fornecidas pelo programa de aplicao. A figura
abaixo ilustra que o acesso ao BD, pelos programas de aplicao, feito atravs do SGBD.
Sistema Medio SGBD BD

Sistema Cobrana
Sistema Distribuio
1.4 Sistema de Banco de Dados (SBD)

A existncia de bancos de dados nas organizaes uma coisa muito comum hoje em dia, ou
seja, as pessoas j esto habituadas a usarem diversos termos relacionados a banco de dados de
forma bastante informal. comum se ouvir no noticirio que um determinado rgo est elaborando a
construo de um novo banco de dados. No entanto, para os profissionais que esto envolvidos com
o desenvolvimento de sistemas computacionais importante ter a compreenso dos diferentes
termos utilizados a este respeito.
Assim, Sistema de Banco de Dados (figura a seguir) um sistema composto pelos programas
de aplicao, pelo SGBD e pelo BD, para um determinado conjunto de aplicaes.
2 GIS BRASIL 2001 - 7 Show de Geotecnologias

PROGRAMADORES/USURIOS
SISTEMA
DE BD Consultas / Programas de Aplicao
SGBD Software para processar

consultas/programas
Software para acessar

dados armazenados
Definio do BD BD
(meta-dados) Armazenado
Muitos programas de aplicao so construdos sem o uso de SGBD para gerenciar os dados.
Neste caso, o prprio programa de aplicao responsvel por implementar as rotinas que realizam
o armazenamento e recuperao dos seus dados.
A seguir esto listadas uma srie de vantagens e a desvantagem do uso de SGBD no
desenvolvimento de programas de aplicao:
Vantagens
Diminui a redundncia dos dados - Em uma organizao que possui diversos programas de
aplicao comum o compartilhamento de dados entre os diversos sistemas. Quando o
nmero de sistemas aumenta, ou tambm, quando cresce a complexidade destes sistemas,
comum que alguns dados sejam repetidos a fim de simplificao da implementao e da
manuteno dos sistemas. Como conseqncia, surgem as redundncias, o que so srias
fontes de dados inconsistentes nas organizaes.
Padroniza a definio e o acesso aos dados - O SGBD fornece linguagens de definio e
acesso aos dados que devem ser utilizadas por todos os programas de aplicao, criando-se
assim, uma interface nica de acesso aos dados armazenados no BD.
Assegura independncia fsica e lgica dos dados - Uma das principais vantagens do uso de
SGBD exatamente a liberdade que o administrador do BD tem para promover alteraes nas
estruturas dos dados sem que estas mudanas provoquem uma srie de manutenes em
cascata. Independncia fsica significa que alteraes podem ser feitas no nvel fsico do BD
sem provocar mudanas no nvel lgico. Por exemplo, pode-se mudar o local onde est
armazenado o BD (troca de servidor). Independncia lgica significa que alteraes podem ser
feitas no nvel lgico do BD sem provocar alteraes nos programas de aplicao que utilizam
as estruturas do BD modificadas. Por exemplo, pode-se incluir um novo campo em uma tabela
sem ter de recompilar todos os programas que acessam aquela tabela.
Consistncia dos dados em caso de falhas - O SGBD deve dispor de dispositivos que tragam o
BD para um estado consistente mesmo aps a ocorrncia de falhas como, por exemplo, falta
de luz. Sistemas de back-ups devem ser providos para que o SBD fique imune tambm a
falhas de hardware.
Manuteno de restries de integridade da aplicao - Muitas verificaes que so realizadas
durante a obteno de dados pelos programas de aplicao podem ser transferidas para o
SGBD. Por exemplo, a verificao de valores fornecidos em uma data so validados com

relao a se ter um ms com valores entre 1 e 12, o mesmo ocorrendo com o valor do dia (que
depende do ms).
Segurana dos dados em ambiente multi-usurio - Controle de acesso e de transaes no caso
de multi acesso a um mesmo elemento de dado pode ser feito de forma confivel pelo SGBD.
Desvantagem
A grande desvantagem do uso de um SGBD est exatamente na existncia de um overhead
para prover segurana, controle de concorrncia, recuperao e funes de integridade.
1.5 Fases do Projeto de Banco de Dados

O processo de desenvolvimento de um banco de dados est intimamente relacionado com o
ciclo de vida do desenvolvimento de software onde, a cada etapa, novas informaes e detalhes so
acrescidos ao projeto do software [PRE 87]. No projeto de banco de dados as informaes que
comporo o banco de dados so especificadas utilizando-se modelos de dados em diferentes nveis
de abstrao, iniciando por modelos de alto nvel de abstrao e refinando-se o modelo at que
sejam incorporados detalhes especficos, relacionados ao armazenamento dos dados.
Segundo Elmasri [ELM 00], o projeto de banco de dados deve ser dividido em trs etapas, nas
quais so empregados diferentes tipos de modelos. A figura a seguir ilustra as trs fases de projeto
de banco de dados (conceitual, lgico e fsico) e seus respectivos produtos ( esquema conceitual,
esquema lgico e esquema fsico).
Mini-Mundo
Anlise de Requisitos
Requisitos de BD
Projeto Esquema Conceitual

Conceitual (Mod. E-R)
independente de software
Projeto Esquema Lgico
dependente de software Lgico (Mod. Relacional)
Projeto Esquema Fsico

Fsico (Mod. Implement.)
Projeto Conceitual Nesta fase elaborado o esquema conceitual do banco de dados, onde
so utilizados modelos semnticos que empregam construtores de abstrao de alto nvel para
descrever os requisitos de dados das aplicaes (ex.: modelo E-R [CHE 76]). Normalmente,
so utilizadas linguagens (modelos) bastante simples, que facilitam a comunicao e o
entendimento entre usurios e projetistas. So identificadas e definidas quais as entidades que
sero representadas no banco de dados, suas estruturas (atributos) e os relacionamentos
existentes entre elas. No projeto conceitual no so considerados aspectos sobre o sistema de
computao (software/hardware) que ser utilizado.
Projeto Lgico Nesta fase elaborado o esquema lgico do banco de dados com base no
tipo de modelo de SGBD que ser utilizado. O esquema lgico independe do software a ser
usado, mas dependente de um modelo de dados. So gerados a partir da aplicao de

regras de transformao (mapeamento) dos construtores de abstrao utilizados no esquema

conceitual em elementos de representao de dados de um dos modelos de banco de dados
(ex.: relacional, hierrquico, orientado a objetos, objeto-relacional).
Projeto Fsico Define os aspectos de implementao fsica do banco de dados como, por
exemplo, estruturas de armazenamento, caminhos de acesso, particionamento e agrupamento.
Esto diretamente relacionados a um SGBD especfico e permitem, ao projetista, planejar
aspectos ligados eficincia do sistema de banco de dados.
1.6 Modelos de Dados

Para Brodie [BRO 84], um modelo de dados uma coleo de conceitos bem definidos
matematicamente, que nos auxilia a pensar e expressar as propriedades estticas e dinmicas das
aplicaes. Numa viso mais especfica de banco de dados, um modelo de dados consiste de trs
componentes: uma coleo de tipos de objetos, uma coleo de operadores e uma coleo de regras
de integridade [COD 79].
Como exemplo dos principais modelos de banco de dados pode-se citar os modelos clssicos:
Rede, Hierrquico e Relacional. Este ltimo o modelo em uso na maioria dos SGBD existentes,
estando instalados em 90% das organizaes atualmente [DBM 94].
Com a evoluo do hardware e do software, novos modelos foram desenvolvidos para atender,
principalmente, a uma srie de aplicaes ditas no convencionais (ex.: CAD, GIS, Automao de
Escritrio). Estes novos modelos so classificados como Modelos Orientados a Objetos ou Modelos
Objeto-Relacional.
Modelos Semnticos
Os modelos semnticos fornecem um conjunto de conceitos (construtores), que nos auxiliam a
pensar e expressar as propriedades estticas e dinmicas das aplicaes. A caracterstica bsica de
um modelo, como o prprio termo explicita, que ele uma abstrao da realidade [PEU 84]. A
distncia existente entre a maneira na qual as entidades existem na realidade e a maneira como
estas entidades so representadas internamente nos computadores levaram ao surgimento de
modelos de dados em diferentes nveis de abstrao. No nvel lgico esto os modelos citados
anteriormente (ex.: relacional, objeto-relacional), os quais so implementados por SGBD, incluindo
suas linguagens para definio e manipulao dos dados. No nvel conceitual, so empregados os
modelos semnticos, os quais so voltados para o entendimento por parte das pessoas (usurios e
projetistas), embora possam ser processados por ferramentas CASE.
Ullman [ULL 82] define um modelo de dados (semntico) como uma descrio geral de um
conjunto especfico de entidades e os relacionamentos existentes entre estes conjuntos de entidades.
Uma entidade pode ser qualquer coisa que seja distinguvel (ex.: um conceito, um evento, um objeto).
Um conjunto de entidades agrupa entidades que possuem caractersticas em comum (ex.: Rios,
Cidades e Pessoas). Caractersticas de entidades so descritas por meio de atributos que possuem
valores especficos de um determinado domnio (ex.: nome e populao de cidades). O exemplo mais
conhecido de modelo semntico o modelo Entidade-Relacionamento (E-R), descrito em detalhes no
captulo 3.
Um modelo de dados semntico fornece uma base formal (notacional e semntica) para
ferramentas e tcnicas usadas para suportar a modelagem semntica do BD. Modelagem semntica
o processo de abstrao no qual, somente os elementos essenciais da realidade observada so
enfatizados, descartando-se os elementos no essenciais

2 NOES BSICAS DO MODELO RELACIONAL

Neste captulo feita uma descrio resumida do modelo relacional, que o modelo utilizado
na grande maioria dos SGBD que so integrados com Sistemas de Informao Geogrfica (SIG),
constituindo os chamados modelos de arquitetura dual. Exemplos de SIG que implementam a
arquitetura dual incluem o ARC/INFO, MGE, Idrisi e Spring. Nestes sistemas, normalmente o SGBD
relacional usado para armazenar os dados descritivos, enquanto os dados geomtricos so
armazenados por meio de estruturas de dados mantidas em arquivos. Algumas estruturas de dados
geomtricos (ex.: topologia) tambm so armazenadas no SGBD relacional.
Existem SIG que so construdos com base em outras arquiteturas diferentes da arquitetura
dual. Os sistemas SIRO-DBMS e SYSTEM 9, por exemplo, so baseados em sistemas com suporte a
campos longos, enquanto os sistemas SmallWorld e GEO2 so construdos com base em modelos
orientados a objetos.
2.1 Modelo Relacional

O modelo relacional foi proposto por Ted Codd em 1970. Fundamentado em uma forte base
matemtica, possibilitou a definio precisa de operadores de consulta aos dados.
No modelo relacional, o BD composto por uma coleo de tabelas. Um nico tipo construtor,
que a tabela (ou relao), usado para estruturar todos os dados do BD. O modelo fornece um
conjunto de linguagens para definio (DDL Data Definition Language), para manipulao (DML
Data Manipulation Language), e para consulta ao BD (QL Query Language). A linguagem de
consulta SQL - Sequential Query Language, a qual engloba as funes das demais linguagens a
linguagem de consulta padro para SGBD relacionais.
A figura abaixo ilustra os principais elementos do modelo relacional. Uma relao compreende
toda a tabela incluindo sua identificao (ex.: Municpio), a definio das colunas (ou atributos da
relao) e os dados (tuplas ou linhas da relao).
Relao Municpio
Esquema CodMun NomeMun Populao
30100 S.S.Paraso 90.000 Relao

Tupla 30400 Viosa 50.000
30600 Passos 100.000 (tabela)
(linha)
Atributos (colunas)
Outros conceitos empregados no modelo relacional incluem:

Esquema do BD - Descrio textual (ou grfica) dos dados e suas estruturas. Compreende a
definio dos esquemas de todas as tabelas do BD. No altera com freqncia.
Instncias do BD - Conjunto de dados armazenados no BD em um determinado instante de
tempo, que respeita a definio de um esquema de BD. Pode alterar com freqncia.
Estado do BD - Conjunto de dados armazenados em um BD em um determinado instante. Uma
transao no BD deve levar o BD de um estado consistente a outro estado consistente. Caso
contrrio esta transao deve ser desfeita.
Em uma relao, cada coluna s pode conter valores de um determinado tipo. A definio do
tipo de valor que pode ser armazenado em uma coluna feita atravs da especificao de um
domnio. Assim, tem-se:

Domnio de atributo - Conjunto de valores possveis de um atributo. Exemplos de domnios

incluem os valores inteiros, reais, cadeias de caracteres, datas e valores lgicos ou booleanos
(verdadeiro/falso) .
Um atributo pode ser usado para identificar uma determinada tupla (linha) em uma relao. Os
conceitos abaixo descrevem os diversos tipos de atributos identificadores de uma relao:
Atributo chave - Atributo que possibilita a identificao de uma tupla na relao.
Chave primria - Atributo chave que o identificador principal de uma relao. Pode ser
composta de mais de um atributo. Isto ocorre quando um nico atributo no suficiente para
identificar uma tupla na relao.
Chave estrangeira - Atributo em uma relao cujo valor aparece como chave primria em uma
outra relao.
importante observar que o acesso a uma relao no necessita ser feito atravs de chaves,
ou seja, as tuplas de uma relao podem ser acessadas, por exemplo, de forma seqencial. Atributos
chave servem para situaes em que o usurio deseja acessar uma tupla especfica no conjunto total
das tuplas. Um exemplo o acesso ao cadastro de contribuintes da Receita Federal a partir do CPF
do contribuinte. Neste caso, CPF deve ser um atributo chave. A chave uma propriedade do
esquema da relao.
Restries de integridade - So imposies que devem ser satisfeitas pelo SGBD para uma
determinada relao. Restries so especificadas no esquema e devem ser mantidas em
todas as instncias deste esquema.
Existem diversos tipos de restries, os principais so:
Restries de domnio - O valor de cada atributo deve ser atmico e pertencer ao domnio
especificado.
Restries de chave - Todas as tuplas de uma relao devem ser distintas.
Integridade referencial - O valor de uma chave estrangeira s pode ser nulo ou igual a algum
valor da chave primria na relao correspondente.
Alm dos conceitos referentes ao esquema do BD, um segundo aspecto importante do modelo
relacional o tipo de linguagem fornecida. Conforme descrito anteriormente, o modelo relacional
prov linguagens para definio, manipulao e consulta ao BD. A possibilidade do usurio realizar
consultas ao BD que no estavam previstas inicialmente no programa de aplicao, deu ao usurio
um grande poder de uso, uma vez que ele agora independe do pessoal tcnico para implementar um
novo relatrio. A partir de um conhecimento bsico de uma linguagem de consulta, o prprio usurio
pode explorar diferentes vises dos dados armazenados.
A linguagem de consulta no modelo relacional a Linguagem SQL (Structured Query
Language), a qual baseada em um padro definido internacionalmente pela ANSI. As sees
seguintes apresentam uma breve introduo s linguagens lgebra Relacional e SQL.
2.2 lgebra Relacional

A lgebra uma linguagem de consulta procedural, consistindo de um conjunto de operaes
que permitem a extrao de dados do BD. As operaes podem ser aplicadas a uma nica relao
(unria) ou a duas relaes (binria), tendo como resultado sempre uma nova relao.
As operaes na lgebra relacional podem ser classificadas em: operaes especficas para
SGBD relacionais (seleo, juno, projeo, diviso, renomear e atribuio); e operaes da teoria
de conjuntos (unio, interseo, diferena e produto cartesiano). O objetivo da apresentao de
operaes da lgebra neste curso apenas o de facilitar o entendimento das operaes da
linguagem SQL. Assim, apenas trs operaes sero descritas (seleo, projeo e produto
cartesiano). Leitores interessados no assunto podem recorrer a vasta bibliografia de SGBD
relacionais como, por exemplo, [ELM 00].

O seguinte exemplo de BD ser usado para exemplificar o uso de operaes da lgebra

relacional.
PROPRIETRIO
idProp nomeProp ender telProp
10 Jos Carioca Av. N.S. Copa,123 99-884466
20 Francisco Bento Rua Curva, 47 99-125544
30 Mnica Aparecida Av. da Paz, 51 98-337768
FAZENDA
idFaz nomeFaz reaFaz dono
7663 Sta Rosa 300 10
4355 Rancho Fundo 350 10
8998 Cavalo Gordo 253 10
7644 Cavalo Magro 500 20
3388 Dolar Furado 640 20
7676 Vila Cristina 150 30
8444 Alba Navarra 321 30
Seleo ()
Seleciona um conjunto de tuplas (linhas) que satisfaam uma dada condio. A relao
resultante ter os mesmos atributos da relao original, ou seja, o mesmo esquema.
A sintaxe da operao de seleo a seguinte:
condio(RELAO)
Onde a clusula de condio pode conter os seguintes operadores: <, >, , , =, , (ou),
(e), () no. A consulta Selecione fazendas com mais de 300 ha deve ser expressa da seguinte
forma:
rea > 300 (FAZENDA)

O resultado est apresentado na seguinte tabela:
TABELA RESULTANTE
idFaz nomeFaz reaFaz dono
4355 Rancho Fundo 350 10
7644 Cavalo Magro 500 20
3388 Dolar Furado 640 20
8444 Alba Navarra 321 30

Projeo ( )
A operao de projeo permite ao usurio selecionar um conjunto de atributos (colunas) em
uma relao. A relao resultante tem apenas os atributos projetados, sendo que eventuais tuplas
duplicadas so eliminadas.
A sintaxe da operao de projeo a seguinte:
lista de atributos (RELAO)

Onde a lista de atributos indica as colunas a serem projetadas. A consulta Crie uma tabela
com o nome e o telefone dos proprietrios deve ser expressa como:
nomeProp,telProp (PROPRIETRIO)
Gerando a seguinte tabela resultante:
TABELA RESULTANTE
nomeProp telProp
Jos Carioca 99-884466
Francisco Bento 99-125544
Mnica Aparecida 98-337768
Produto cartesiano ( X )
As duas operaes anteriores so operaes unrias, ou seja, s podem operar sobre uma
nica tabela por vez. Algumas consultas s podem ser resolvidas a partir do cruzamento de duas ou
mais tabelas. Por exemplo, imagine a consulta Encontre o nome dos proprietrios de fazendas com
mais de 400 ha. Como o nome dos proprietrios um atributo da tabela PROPRIETRIO e a rea
da fazenda um atributo da tabela FAZENDA, necessrio consultar as duas tabelas.
Para resolver este problema, na lgebra relacional necessrio criar uma nova tabela cujo
esquema seja uma concatenao das duas tabelas desejadas. A operao produto cartesiano
possibilita esta concatenao. Sua sintaxe a seguinte:
RELAO X RELAO
O esquema da relao A X B = esquema de A concatenado ao esquema de B. Assim, para
resolver a consulta Encontre o nome dos proprietrios de fazendas com mais de 400 ha pode-se
expressar da seguinte forma:
nomeProp (reaFaz > 400 ^ idProp = dono (PROPRIETRIO X FAZENDA))

O esquema da tabela PROPRIETRIO X FAZENDA ser
idProp, nomeProp, ender, telProp, idFaz, nomeFaz, reaFaz, dono
A tabela resultante mostrada abaixo:
TABELA RESULTANTE
nomeProp
Jos Carioca
Francisco Bento

Uma forma alternativa de resolver esta consulta usando a operao de atribuio para criar
uma tabela temporria.
Temp <- Proprietrio X Fazenda
nomeProp (reaFaz > 400 ^ idProp = dono (temp))
A tabela abaixo exemplifica algumas tuplas da tabela TEMP:

TEMP
idProp nomeProp ender telProp idFaz nomeFaz reaFaz dono
10 Jos Carioca Av. N.S.Copa,123 99-884466 7663 Sta Rosa 300 10
10 Jos Carioca Av. N.S.Copa,123 99-884466 4355 Rancho Fundo 350 10
10 Jos Carioca Av. N.S.Copa,123 99-884466 8998 Cavalo Gordo 253 10
10 Jos Carioca Av. N.S.Copa,123 99-884466 7644 Cavalo Magro 500 20
........ .................. ...........
20 Francisco Bento Rua Curva, 47 99-125544 7663 Sta Rosa 300 10
20 Francisco Bento Rua Curva, 47 99-125544 4355 Rancho Fundo 350 10
20 Francisco Bento Rua Curva, 47 99-125544 8998 Cavalo Gordo 253 10
........ ................... .............
30 Mnica Aparecida Av. da Paz, 51 98-337768 7663 Sta Rosa 300 10
........ .................... ..............
Importante observar que na tabela TEMP ocorrem tuplas cujas dados no so totalmente
vlidos. Por exemplo, a quarta tupla tem como identificador do proprietrio (idProp) o valor 10 e como
dono o valor 20. Este um exemplo de tupla que deve ser desconsiderada na consulta, o que justifica
a incluso da condio que idProp deva ser igual a dono. Caso contrrio, muitas tuplas falsas seriam
includas na relao resultante. Observe que todo o segundo bloco de tuplas (idProp = 20) tem como
dono o valor 10, assim todas essas tuplas so tambm falsas.
2.3 SQL Linguagem de Consulta Estruturada

A linguagem de consulta SQL (Structured Query Language) foi desenvolvida originalmente
como a linguagem de consulta do SGBD System R, da IBM. Aps se tornar um padro de fato, foi
adotada internacionalmente como a linguagem de consulta para SGBD relacionais.
A primeira verso do padro foi estabelecida pela ANSI em 1986, sendo batizada de SQL1. Em
1992 o padro foi revisado, dando origem ao atual padro, tambm conhecido por SQL2. Uma
terceira verso (SQL3) encontra-se em desenvolvimento, devendo ser oficializada nos prximos anos.
Entre as novidades do novo padro SQL3 est a incluso de conceitos de orientao a objetos e o
suporte a objetos espaciais.
Na realidade, SQL muito mais do que uma linguagem de consulta, ela uma linguagem para
ser usada como a linguagem do banco de dados, uma vez que ela inclui:
Linguagem de consulta (QL)
Linguagem de definio de dados (DDL)
Linguagem de manipulao de dados (DML)
Interface para linguagens de manipulao de dados embutida
Autorizao de acesso
Restries de integridade
Controle de transaes

A seguir, uma viso simplificada da linguagem SQL apresentada, cujo objetivo apenas o de
permitir que o leitor possa ter uma idia de como possvel extrair dados de um BD atravs da
linguagem de consulta de um SGBD relacional.
Definio do esquema (tabelas)

Um esquema de BD composto no s de tabelas, mas tambm por definies de vises,
restries de integridade e autorizao de acesso. Todas as informaes sobre o esquema de um BD
so armazenadas no catlogo do BD, o qual gerenciado pelo SGBD.
A definio de uma tabela feita atravs do comando CREATE TABLE, exemplificada na
declarao abaixo:
CREATE TABLE FAZENDA (

idFaz INTEGER NOT NULL,
nomeFaz CHAR (30),
reaFaz INTEGER,
dono CHAR (20),
PRIMARY KEY (idFaz),
FOREIGN KEY (dono) REFERENCES PROPRIETRIO );
A clusula NOT NULL especifica que o atributo no pode conter valores nulos. A clusula
PRIMARY KEY indica qual (ou quais) atributo ser a chave primria da tabela. A especificao da
clusula FOREIGN KEY (chave estrangeira) permite ao SGBD garantir a restrio de integridade
referencial. Assim, o campo DONO na tabela FAZENDA ou ter um valor nulo, ou o valor dever ser
um valor existente na tabela PROPRIETRIO.
Consultas em SQL
Por ser uma linguagem declarativa o usurio no necessita especificar o algoritmo a ser
seguido pelo programa para a execuo da consulta, como ocorre nas linguagens de programao
procedurais (ex.: Pascal, C, Cobol). O usurio necessita apenas especificar o que ele quer e o
SGBD deve resolver a consulta. Como conseqncia, SQL no uma linguagem
computacionalmente completa, ou seja, nem tudo que possvel realizar com uma linguagem
procedural possvel realizar com SQL. Por outro lado, o banco de dados pode ser consultado de
forma exploratria pelo usurio, sem que este tenha que possuir grandes habilidades em
programao.
Em SQL, as consultas so realizadas atravs do comando SELECT-FROM-WHERE. A
estrutura bsica do comando de consulta a seguinte:
SELECT <lista de atributos>

FROM <lista de tabelas>
WHERE <condio>
Uma consulta tpica:
SELECT A1, A2, A3,...., An

FROM R1, R2, R3,...,Rn
WHERE C
equivalente, em lgebra relacional, a:

A1,A2,A3,...,An (C ( R1 x R2 x R3 x ... x Rn ))

A seguir so apresentados alguns exemplos de consulta em SQL.
Obter fazendas com mais de 400 ha

SELECT *
FROM FAZENDA
WHERE reaFaz > 400
Obter nome dos proprietrios de fazenda com menos de 200 ha

SELECT nomeProp
FROM PROPRIETRIO, FAZENDA
WHERE reaFaz < 200 and idProp = dono
O conjunto completo de clusulas do comando SELECT o seguinte:
SELECT <lista de colunas>

FROM <lista de tabelas>
[WHERE <condio>]
[GROUP BY <colunas para agrupamento>]
[HAVING <condio de agrupamento>]
[ORDER BY <lista de atributos>]
Apenas as clusulas SELECT e FROM so obrigatrias. Quando existentes, as demais

clusulas devem aparecer na ordem especificada acima.
Funes Agregadas
Funes de agregao permitem computar valores sobre grupos de linhas de uma tabela. As
funes mais utilizadas esto listadas abaixo:
COUNT : contagem de linhas ou valores
SUM : soma
MAX : mximo
MIN : mnimo
AVG : mdia
As funes agregadas podem ser aplicadas sobre toda a tabela ou sobre um grupo de linhas.
Permitem calcular valores sobre grupos de linhas, definidas pela clusula GROUP BY. Vejamos
alguns exemplos:
Obter rea total das fazendas de cada proprietrio

SELECT dono, sum(reaFaz)
FROM FAZENDA
GROUP BY dono
Listar fazendas em ordem decrescente de rea

SELECT nomeFaz, reaFaz
FROM FAZENDA
ORDER BY reaFaz DESC

3 PROJETO DE BANCO DE DADOS
3.1 Processo de Modelagem Conceitual

Um modelo de dados fornece uma base formal (notacional e semntica) para ferramentas e
tcnicas usadas para suportar a modelagem de dados. Modelagem de dados o processo de
abstrao onde somente os elementos essenciais da realidade observada so enfatizados,
descartando-se os elementos no essenciais.
O processo de modelagem conceitual compreende a descrio e definio dos contedos dos
dados, alm de suas estruturas e de regras aplicveis aos dados [EUR 96]. A modelagem conceitual
sempre feita com base em algum formalismo conceitual (ex.: Entidade-Relacionamento, Orientao
a Objetos), independente do nvel de abstrao empregado. O resultado da modelagem, denominado
esquema conceitual, apresentado atravs de uma linguagem formal de descrio, que possui uma
sintaxe e/ou uma notao grfica. A figura abaixo ilustra o processo de modelagem conceitual de
dados.
Realidade
Formalismo fornece
regras para Modelagem
Conceitual
compatibilidade
fornece
Tcnicas Formais de Descrio gramtica para
Apresentao
Linguagem Lxica
Notao Grfica
Esquema
Conceitual
Para cada formalismo conceitual existe um conjunto de linguagens de descrio de esquema

que so compatveis com o formalismo. O formalismo fornece um conjunto de regras que so usadas
no processo de modelagem da realidade, enquanto que a linguagem de descrio fornece uma
gramtica para a apresentao do esquema conceitual resultante da modelagem. A linguagem lxica
possibilita o processamento computacional do esquema, enquanto a notao grfica mais
adequada para facilitar o entendimento e a comunicao entre humanos (ex.: usurios e projetistas).
A seguir, so listadas as principais linguagens de modelagem disponveis, classificadas
segundo o formalismo empregado. A figura ao lado ilustra a notao grfica correspondente a um
relacionamento 1:N.
Formalismo E-R:
Peter Chen
1 N
James Martin (eng. informaes)

IDEF1X
Formalismo da orientao a objetos:
OOA Anlise orientada a objetos N 1
OMT Tcnica de modelagem de objetos

UML Linguagem de modelagem unificada 1 *

3.2 Modelo Entidade-Relacionamento (E-R)

O modelo Entidade-Relacionamento (E-R), proposto por Peter Chen em 1976, baseia-se na
percepo de um universo constitudo por um grupo bsico de objetos chamados entidades e por
relacionamentos entre estes objetos [CHE 76].
O modelo E-R foi desenvolvido para facilitar o projetista na tarefa de projetar bancos de dados
relacionais. um modelo semntico (ou conceitual) de alto nvel, ou seja, usa uma linguagem que
est mais prxima do usurio do que da mquina (computador). Um esquema de dados elaborado
com o modelo E-R especifica quais os dados que sero representados e no como os dados sero
armazenados. Assim, um modelo que independente do SGBD a ser utilizado na implementao
do BD.
Por possuir uma notao grfica bastante simples, de fcil aprendizado. Alm de facilitar o
entendimento da estrutura do BD por parte dos usurios leigos, melhora a comunicao entre os
projetistas e os usurios.
A seguir so apresentados os elementos construtores do modelo E-R.
Entidade
Todo fenmeno de interesse da aplicao representado, ou modelado, como uma entidade.
Uma entidade pode ter existncia fsica (ex.: rio, estrada, igreja) ou existncia conceitual (ex.:
empresa, cargo, municpio).
Entidades so modeladas atravs do mecanismo de abstrao conhecido como classificao,
no qual as entidades que so similares so descritas uma nica vez, formando um conjunto entidade.
As caractersticas de uma entidade so modeladas atravs de atributos da entidade (ex.: nome e
populao de um municpio).
Ao contrrio do modelo relacional, no qual todo atributo deve ser atmico, no modelo E-R
diversos tipos de atributos podem ser especificados. So eles:
Atmico (ex.: nome, populao)
Composto (ex.: endereo = [rua+nm+bairro+cep])
Derivado (ex.: idade = dataHoje - dataFundao)
Multivalorado (ex.: {telefones para contato})
A notao grfica para representar um conjunto entidade um retngulo, podendo os atributos
estarem dentro ou fora dos limites do retngulo, de acordo com a linguagem grfica usada. As figuras
abaixo ilustram duas alternativas de modelagem do conjunto entidade Municpio e seus atributos.
codMun nomeMun
Municpio
populao codMun
Municpio nomeMun
dataEmanc populao
dataEmanc
Chave Primria
Como na implementao de um banco de dados relacional, o conceito de chave primria de
fundamental importncia, mesmo sendo um conceito mais prximo da implementao, importante
que sejam identificadas os atributos que comporo a chave primria de um conjunto entidade.
Chave primria o atributo (ou conjunto de atributos) que identifica(m) univocamente cada
entidade em um conjunto entidade. No exemplo acima, o atributo codMun um candidato a ser
escolhido como chave primria para o conjunto entidade Municpio.

Entidade Fraca
Alguns conjuntos entidade no possuem um conjunto de atributos capaz de identificar
univocamente uma determinada entidade. Neste caso, sua existncia depende da existncia de outra
entidade. Um exemplo clssico de entidade fraca ocorre quando um sistema de pessoal possui dados
sobre os dependentes de seus funcionrios. comum que os funcionrios tenham um nmero de
matrcula na empresa que usado como atributo chave da tabela de funcionrios. Por outro lado,
normalmente os dependentes dos funcionrios no possuem uma matrcula prpria, bem como no
possuem um conjunto mnimo de atributos que possam constituir a chave primria da tabela de
dependentes. Neste caso, o conjunto entidade Dependente deve ser modelado como uma entidade
fraca. A figura abaixo ilustra a notao grfica usada para representar conjuntos de entidades fracas.
matrFunc nomeFunc IdDep nomeDep
Funcionrio possui Dependente
salrio cargo dataNasc sexo
Relacionamento
O segundo construtor do modelo E-R o construtor para representao de relacionamentos.
Um relacionamento descreve uma associao entre duas ou mais entidades. Por exemplo, as
expresses abaixo sinalizam relacionamentos importantes que devero ser representados no
esquema do BD.
Salvador capital da Bahia.
Curitiba capital do Paran.
Belo Horizonte localiza-se em MG.
Viosa localiza-se em MG.
Da mesma forma que entidades semelhantes so agrupadas em conjuntos entidade,
relacionamentos semelhantes so agrupados em conjuntos relacionamentos e modelados uma nica
vez. Assim, os relacionamentos acima poderiam ser classificados da seguinte forma:
Municpio capital de Estado.
Municpio localiza-se em Estado.
Uma notao grfica para representao desses relacionamentos exemplificada na figura
abaixo.
localiza
Municpio Estado
capital
A modelagem dos relacionamentos uma das tarefas mais importantes no projeto conceitual.
a partir dos relacionamentos que o banco de dados poder ser explorado atravs de consultas. O
projetista de uma aplicao deve ter a habilidade de escolher, dentre uma infinidade de possveis
relacionamentos, aqueles que so importantes de acordo com os objetivos do sistema.

Cardinalidades
No modelo E-R, os relacionamentos devem especificar um importante tipo de restrio de
integridade que a sua cardinalidade. A cardinalidade de um relacionamento indica o nmero de
entidades s quais uma outra entidade pode estar associada via um relacionamento.
Em um relacionamento entre dois conjuntos entidade A e B, existem trs tipos bsicos de
cardinalidades:
1:1 (um para um) cada entidade no conjunto entidade A pode estar associada a no mximo
uma entidade no conjunto entidade B e vice-versa;
1:N (um para muitos) cada entidade no conjunto entidade A pode estar associada a nenhuma
ou muitas entidades no conjunto entidade B e cada entidade no conjunto entidade B s pode
estar associada a uma nica entidade no conjunto entidade A;
M:N (muitos para muitos) cada entidade no conjunto entidade A pode estar associada a
nenhum ou muitas entidades no conjunto entidade B, e vice-versa.
A figura abaixo ilustra a representao de cardinalidades nos relacionamentos:
n 1
localiza
Municpio Estado
1 (0,1)
capital
m
serve
n
Rodovia
possvel representar cardinalidades mnimas e mximas de um relacionamento, como

mostrado na figura acima. Neste exemplo, a cardinalidade 1:(0,1) significa que cada estado, no
conjunto entidade Estado, possui exatamente um municpio que sua capital e que cada municpio,
no conjunto entidade Municpio, pode no ser capital de estado, ou ser capital de no mximo um
estado.
3.3 Projeto Lgico de Banco de Dados

A fase de projeto lgico consiste em transformar, ou mapear, um esquema conceitual de
dados em um esquema lgico. Nesta fase, a primeira deciso a ser tomada a escolha do SGBD no
qual o BD ser implementado. Esta escolha determina o modelo de dados a ser utilizado (ex.: modelo
relacional, orientado a objetos, objeto-relacional). Nesta seo apresentado um conjunto de regras
a serem aplicadas para transformao de esquemas E-R em esquemas relacionais.
A seguinte figura, a qual ilustra um esquema E-R de um sistema de cana-de-aucar, usada
para exemplificar as regras de transformao.

codMun nomeMun
Municpio Esquema conceitual de um
pop
1
sistema de cana-de-aucar
seLocaliza
idTalho rea-talho
idFaz n
Fazenda divideEm Talho

1 n
m m
nomeFaz reaFaz dat-Plantio
propriedade plantao
numColheita dat-ult-colheita
1 n
telProp prodMdia
Proprietrio Variedade
ender descVar
idProp nomeProp tipoVar
Transformando Entidades
Normalmente, cada entidade d origem a uma tabela, cujas colunas correspondem aos
atributos da entidade. Duas notaes para o modelo relacional, uma textual e outra grfica, so
apresentadas abaixo. A notao grfica a notao do modelo IDEF1X, utilizada na ferramenta
CASE ERWin.
Municpio
codM un nom eM un
M u n ic p io codMun
pop nomeMun
populao
dataEmanc
A notao textual uma verso simplificada, na qual os domnios dos atributos so suprimidos
para efeitos didticos. Os atributos que fazem parte da chave so sublinhados. Inicialmente, no
esquema E-R do sistema de cana-de-aucar, as seguintes tabelas poderiam ser deduzidas a partir
desta regra:
Municpio (cod-mun, nomeMun, pop)
Proprietrio (idProp, nomeProp, ender, telProp)
Fazenda (idFaz, nomeFaz, reaFaz)
Talho (idFaz, idTalho, reaTalho)
Variedade (tipoVar, descrVar, prodMdia)
Observe que a tabela Talho possui uma chave dupla devido a entidade ser fraca. A aplicao
das demais regras provocaro mudanas em algumas destas tabelas, como ser visto a seguir.

Transformando Relacionamentos
Relacionamentos podem ser transformados de duas formas distintas: (1) atravs da incluso
do atributo chave de uma das entidades, na tabela resultante da transformao da outra entidade
envolvida no relacionamento; (2) definio de uma tabela especfica para armazenar os
relacionamentos, a qual tem como chave primria, as chaves primrias das duas tabelas envolvidas.
Portanto, a transformao de relacionamentos depende de vrios aspectos do problema
(sistema) em questo. Exemplos que influenciam na deciso de qual a melhor forma de transformar
os relacionamentos incluem, por exemplo, cardinalidade opcional, volume de entidades envolvidas
em um determinado tipo de relacionamento, volume de uso deste relacionamento em consultas
futuras, etc. Assim, embora existam regras que orientem este tipo de transformao, importante o
projetista ter em mente que aspectos da aplicao devem ser considerados para uma escolha mais
adequada em cada caso. As regras apresentadas a seguir so um resumo dos casos mais comuns
de transformao. Apenas alguns casos especiais so comentados.
Relacionamentos 1:1
Relacionamentos 1:1 normalmente so transformados atravs da incluso de um atributo extra
em umas das tabelas envolvidas. A escolha de qual entidade vai receber o atributo chave da outra
entidade merece uma anlise especial do projetista. A figura abaixo ilustra um esquema E-R e um
possvel esquema relacional equivalente.
codMun nomeMun UF nomeUF
1 (0,1)
Municpio capital Estado
pop
Municpio (cod-mun, nomeMun, pop, UF*)

*UF referencia Estado
Estado (UF, nomeUF)
A incluso de um asterisco (*) no campo UF significa que UF uma chave estrangeira para
outra tabela, no caso a tabela Estado. Uma outra alternativa para a transformao deste esquema
E-R est mostrado abaixo.
Estado (UF, nomeUF, cod-mun-capital*)
*cod-mun-capital referencia Municpio
Qual das alternativas a melhor? Analise o que ocorre com as colunas UF, da tabela Municpio
(primeira alternativa) e cod-mun-capital, da tabela Estado (segunda alternativa).
Relacionamentos 1:N
Ao contrrio dos relacionamentos 1:1, em que h a opo de escolha, em um relacionamento
1:N a entidade do lado N sempre vai receber o(s) atributo(s) chave da entidade do lado 1, a menos
que o projetista opte por transformar o relacionamento em uma tabela prpria (caso excepcional).

A figura abaixo ilustra um esquema E-R e o esquema relacional equivalente.
c o d-m u n nomeMun
Municpio
pop
1 Municpio (cod-mun, nomeMun, pop)
Fazenda (idFaz, nomeFaz, reaFaz, codMun*)
seLocaliza
*codMun referencia Municpio
id-Faz n
Qual o problema de se incluir o campo IdFaz
Fazenda na tabela Municpio?
nomeFazenda reaFaz
Relacionamentos M:N
A nica forma possvel de transformao de relacionamentos M:N atravs da definio de
uma tabela adicional, cuja chave composta pelas chaves primrias das duas entidades envolvidas.
Isto ocorre porque no modelo relacional h a restrio de domnio atmico. Dessa forma, no
possvel incluir um conjunto de rodovias na tabela Municpio e vice-versa. A figura abaixo ilustra um
esquema E-R e o esquema relacional equivalente.
codMun nomeMun idRod nomeRod
M N
Municpio serve Rodovia
pop jurisdio

Rodovia (idRod, nomeRod, jurisdio)
MunRod (cod-mun*, idRod*)
* cod-mun referencia Municpio
* idRod referencia Rodovia
Uma situao que ocorre com freqncia um relacionamento ter atributos. A figura abaixo
ilustra parte do diagrama E-R do sistema de cana-de-aucar, em que o relacionamento plantao
possui atributos prprios. O exemplo tambm ilustra a transformao de relacionamentos envolvendo
uma entidade fraca.
id-talho rea-talho
Talho Talho (id-talho, rea-talho)

m Variedade (tipoVar, descVar, prodMdia)
dat-Plantio
Plantao (idFaz*, id-talho*, tipoVar*, numColheita,
plantao dat-Plantio, dat-ult-colheita)
numColheita dat-ult-colheita
n *idFaz,id-talho referenciam Talho
prodMdia *tipoVar referencia Variedade
Variedade
descVar
tipoVar

3.4 Ferramentas CASE

As regras de transformao apresentadas anteriormente resolvem grande parte dos problemas
de transformao de esquemas conceituais em esquemas relacionais. Como se pode notar, a base
para escolha da regra a ser empregada o tipo de cardinalidade do relacionamento. Portanto, o
projetista deve reservar especial ateno modelagem dos relacionamentos e suas cardinalidades.
Estas regras tambm so empregadas pelos programas de apoio a projeto de BD, conhecidos
por ferramentas CASE. A figura abaixo ilustra o esquema completo do sistema de cana-de-aucar
elaborado atravs da ferramenta CASE ERWin.
Municpio
codMun
nomeMun
pop
Fazenda Plantacao
idFaz Talhao idFaz (FK)
idTalhao (FK)
nomeFaz idFaz (FK)
tipoVar (FK)
areaFaz idTalhao
codMun (FK) datplantio
areaTalhao
dono (FK) datUlColh
numColheita
Proprietatio
idProp Variedade
nomeProp tipoVar
ender
telProp descrVar
prodMedia
A figura ilustra o que na ferramenta ERWin chamado de Nvel Lgico, uma vez que o nvel de
detalhe apresentado est mais prximo do modelo relacional do que do modelo conceitual, mesmo
embora a figura se assemelhe bastante com um esquema E-R. Alguns detalhes podem ser
observados na figura acima. So eles:
As figuras representadas no formato retangular representam tabelas do modelo relacional e
no entidades do modelo E-R. Observe a existncia da tabela Plantao, que no modelo E-R
corresponde a um relacionamento;
Existem dois tipos de representao grfica para tabelas, retngulos com bordas retas e
abaloadas. Retngulos com bordas abaloadas sinalizam tabelas resultantes da transformao
de entidades fracas (ex.: Talho) ou tabelas resultantes da transformao de relacionamentos
(Plantao). Observe a presena de atributos que so chaves estrangeiras (FK foreign key)
fazendo parte da chave primria destas tabelas (ex.: idFaz (FK) em Talho).
A linha tracejada representa um relacionamento 1:N entre duas entidades fortes, que
transformado pela incluso de uma chave estrangeira na tabela do lado N (que no participa da
chave primria). Por exemplo, o relacionamento Fazenda Proprietrio representado por
uma linha tracejada (com um diamante na ponta que no significa nada). Neste caso, a
ferramenta inclui automaticamente na tabela Fazenda, o campo idProp, o qual foi renomeado
para dono, assinalado como (FK).
A linha contnua indica a transformao de um relacionamento 1:N, envolvendo uma de
entidade fraca, ou de um relacionamento M:N. Neste caso o sistema inclui automaticamente a
chave estrangeira como chave primria da tabela resultante.

A figura abaixo ilustra o mesmo esquema relacional do sistema de cana-de-aucar, na viso

chamada Modelo Lgico Detalhado, na qual cada atributo est associado a um domnio especfico.
Municpio
codMun: INTEGER
nomeMun: CHAR(30)
pop: LONG
Fazenda Plantacao
idFaz: INTEGER Talhao idFaz: INTEGER
idTalhao: CHAR(18)
nomeFaz: CHAR(30) idFaz: INTEGER
tipoVar: SMALLINT
areaFaz: FLOAT idTalhao: CHAR(18)
codMun: INTEGER datplantio: DATE
areaTalhao: FLOAT
dono: INTEGER datUlColh: DATE
numColheita: INTEGER
Proprietatio
idProp: INTEGER Variedade
nomeProp: CHAR(20) tipoVar: SMALLINT
ender: CHAR(30)
telProp: CHAR(12) descrVar: CHAR(20)
prodMedia: LONG
Estas informaes so suficientes para a gerao automtica do esquema do BD em um

SGBD. A ferramenta CASE ERWin, por exemplo, gera cdigo automtico para diversos SGBD (ex.:
Oracle, DB2, SQL Server).
A seguir o mesmo esquema apresentado na notao textual simplificada:
Proprietrio (idProp, nomeProp, ender, telProp)
Fazenda (idFaz, nomeFaz, reaFaz, codMun*, dono*)
*codMun referencia Municpio
*dono referencia Proprietrio
Talho (idFaz*, idTalho, reaTalho)
*idFaz referencia Fazenda
Plantao (idFaz*, id-talho*, tipoVar*, numColheita, dat-Plantio, dat-ult-colheita)
*idFaz,id-talho referenciam Talho
*tipoVar referencia Variedade
Variedade (tipoVar, descrVar, prodMdia)

4 PROJETO DE BANCOS DE DADOS GEOGRFICOS
4.1 Dado, Informao e Fenmeno Geogrfico

Uma informao obtida a partir do processamento ou da contextualizao de dados brutos.
Um dado bruto corresponde a um valor para uma medida observada. Por exemplo, a data 7/9/1822
um dado bruto. Quando este dado est associado a um contexto torna-se informao. Assim, na
expresso O Brasil tornou-se independente de Portugal em 7 de setembro de 1822, o dado
transformado em informao.
De modo equivalente, informao geogrfica resultado do processamento de dados
geogrficos. Um dado geogrfico refere-se a uma medida observada de um fenmeno que ocorre
sobre/sob a superfcie terrestre, onde a localizao da observao um componente fundamental do
dado.
O termo fenmeno geogrfico compreende, de forma abrangente, a qualquer ocorrncia que
pode ser: natural (ex.: um lago, a presso atmosfrica, uma formao geolgica); antrpica (ex.: uma
rodovia, um hospital, diviso territorial poltica); de fatos (ex.: uma epidemia, uma batalha); ou mesmo
de objetos ainda inexistentes (ex.: o planejamento de um gasoduto, projeto de uma usina
hidroeltrica).
Componentes da informao geogrfica

Segundo Chrisman [CHR 97], a informao geogrfica possui trs componentes bsicos:
atributo, espao e tempo, que possibilitam responder, respectivamente, a trs perguntas: o qu?,
onde? e quando?. Segundo Worboys [WOR 95], cada um desses componentes determina uma
categoria de dimenso ao longo da qual os valores so medidos.
tempo
atributo
espao
Categorias de dimenses da informao geogrfica
Para que um dos trs componentes possa ser medido deve-se fixar um segundo componente e
usar o terceiro como controle (Sinton, 1978 Apud [CHR 97]). Por exemplo, para medir a altitude
(atributo) de uma determinada regio, fixa-se o componente tempo, faz-se variar a posio no espao
(controle) e toma-se o valor da altitude para os diversos pontos na regio. Um segundo exemplo
compreende a medio da temperatura em uma estao meteorolgica. Neste caso, a localizao da
estao fixa (espao), o perodo de tempo da observao serve de controle e a temperatura
(atributo) medida para cada unidade de tempo estabelecida. A definio de qual dimenso
pretende-se fixar, usar como controle ou medir, possibilita uma grande variedade de estruturas de
medidas da informao geogrfica.
Componente Espao
O componente espacial descreve a localizao geogrfica e a forma geomtrica do fenmeno
descrito pela informao geogrfica, alm de relacionamentos com outros fenmenos geogrficos.
Como a principal funo de um SIG possibilitar a realizao de operaes de anlise espacial, o
componente espacial o mais importante no contexto de SIG.

Um dado geogrfico , antes de mais nada, um dado espacial, isto , descreve a forma
geomtrica (coordenadas numricas) de um objeto no espao. Por exemplo, a forma de um cubo no
espao ou uma circunferncia projetada no espao so dados espaciais. Assim, uma linha
3 2
unindo dois pontos quaisquer em uma imagem de ecografia um dado espacial, mas no um dado
geogrfico.
Quando o dado espacial est relacionado com sua localizao sobre a superfcie terrestre, ou
seja, so utilizadas coordenadas geogrficas (ex.: latitude/longitude), este dado, alm de ser espacial,
um dado geogrfico, tambm conhecido por dado geo-espacial ou dado georreferenciado.
Devido a uma herana cultural no desenvolvimento de SIG, decorrente do uso de mapas em
papel, existe uma predominncia quase total no processamento de dados bidimensionais, embora
seja possvel o processamento de dados espaciais em trs dimenses.
Componente Atributo
Um fenmeno geogrfico possui caractersticas qualitativas e quantitativas que so descritas
de forma textual e/ou numrica. O componente atributo, tambm conhecido por atributo descritivo ou
atributo no-espacial, descreve as caractersticas no espaciais de um fenmeno geogrfico. Nome,
populao e oramento anual de um municpio so exemplos de atributos descritivos.
Atributos descritivos so os mais freqentes na maioria dos sistemas de informao em geral.
A maioria dos SIG utilizam um SGBD para o gerenciamento dos atributos descritivos.
Segundo Aronoff [ARO 89], existe um certo grau de incerteza que inerente ao componente
atributo. Por exemplo, uma floresta de Eucaliptos pode no ser formada por rvores 100% do tipo
Eucalipto ou um bairro residencial pode possuir algumas pequenas indstrias instaladas. Para alguns
tipos de anlises pode ser importante considerar a existncia dessas incertezas, embora
normalmente este tipo de problema seja desconsiderado pelos usurios de SIG.
Componente Tempo
Todo fenmeno geogrfico eminentemente temporal, ou seja, est associado a um instante
ou intervalo de tempo em que este ocorre ou em que observado [PEU 95]. O componente tempo
pode ser crtico para a informao geogrfica, dependendo do tipo de fenmeno e do tipo de
aplicao em que este est sendo utilizado.
O componente tempo, embora muitas vezes esteja implicitamente associado aos demais
componentes da informao geogrfica, tem sido tratado como uma simples informao
complementar. Por exemplo, todo mapa est associado ao perodo de tempo relativo sua confeco
e ao perodo de tempo relativo validade da informao apresentada. Um novo mapa retratando as
divises provinciais do Brasil no sculo XVII ilustra esta situao.
A maioria dos sistemas so projetados para fornecer informao atual sobre os fenmenos
geogrficos. Por exemplo, um sistema de rede de telefonia deve fornecer aos seus usurios, a
informao mais atualizada possvel. Desta forma, a informao que extrada do sistema tida
como verdadeira para o momento da consulta. comum a existncia de aplicaes onde os aspectos
temporais no so contemplados ou so tratados de maneira superficial. No entanto, existem
aplicaes onde o aspecto temporal fundamental. Por exemplo, em um sistema de cadastro urbano,
os limites dos lotes podem ser modificados (divididos ou unidos a outros lotes), proprietrios podem
ser trocados, edificaes so construdas. O histrico dessas modificaes no cadastro territorial
um fator importante neste tipo de aplicao.

4.2 Requisitos de Modelagem para Aplicaes de SIG

Devido necessidade de tratar as trs dimenses da informao geogrfica, as aplicaes de
SIG impem alguns requisitos especiais de modelagem que devem ser suportados pelos modelos
conceituais no projeto de banco de dados para estas aplicaes. A seguir descrito o conjunto de
requisitos mnimos que um modelo conceitual de dados para aplicaes de SIG deve suportar
[LIS 99a].
Fenmeno Geogrfico e Objeto Convencional

Em um banco de dados geogrficos existem, alm dos dados referentes aos fenmenos
geogrficos, outros objetos convencionais, presentes na maioria dos sistemas de informao. Por
exemplo, uma fazenda um fenmeno geogrfico quando suas informaes espaciais (ex.: os limites
da fazenda) esto armazenadas no banco de dados. Neste mesmo banco de dados pode-se ter
dados sobre os proprietrios de fazendas, considerados objetos convencionais por no terem
informaes espaciais associadas. Em um esquema conceitual importante que se possa diferenciar,
facilmente, entre classes (ou entidades) descrevendo esses dois tipos de objetos.
Vises de Campo e de Objetos

Segundo Goodchild [GOO 92], a realidade geogrfica pode ser observada segundo duas
vises: de campo e de objetos.
Na viso de campo a realidade modelada por variveis que possuem uma distribuio
contnua no espao. Toda posio no espao geogrfico pode ser caracterizada atravs de um
conjunto de atributos como temperatura, tipo de solo e relevo, medidos para um conjunto de
coordenadas geogrficas.
Na viso de objetos, a realidade consiste de fenmenos individuais, bem definidos e
identificveis. Cada fenmeno na viso de objetos tem suas propriedades individuais e ocupa um
determinado lugar no espao. A realidade modelada como um grande espao onde os fenmenos
esto distribudos sem que, necessariamente, todas as posies do espao estejam ocupadas.
1
A modelagem de fenmenos geogrficos na viso de objetos um processo natural e direto
(ex.: rios so descritos pela classe ou entidade Rio). No entanto, um campo geogrfico (ex.:
Altimetria) no pode ser modelado diretamente como uma classe, pois Altimetria no um objeto e,
consequentemente, no pode ser descrito diretamente por uma classe.
Um modelo conceitual de dados deve prover construtores especiais para modelar tanto os
campos quanto os objetos geogrficos. A maioria dos modelos existentes no suporta a modelagem
dos fenmenos geogrficos que so percebidos na viso de campo.
Aspectos Temticos
Os fenmenos geogrficos possuem vrios atributos, dentre os quais o que fornece sua
localizao geogrfica (atributo espacial). A localizao e a forma dos fenmenos geogrficos so
representadas atravs de objetos espaciais, associados a um sistema de coordenadas. Um objeto
representando um fenmeno geogrfico (ex.: um rio) deve estar associado a um ou mais objetos
espaciais que representam sua localizao e sua forma sobre a superfcie terrestre. Em um SIG,
esses objetos espaciais no so tratados isoladamente, mas sim, em grupos que representam
fenmenos com caractersticas e relacionamentos em comum. Diferentes termos como tema, camada
e plano de informao so encontrados na literatura, referindo-se a estes agrupamentos.
No nvel interno de um SIG, a organizao dos dados espaciais feita em camadas fsicas
(ex.: conjunto de polgonos representando os limites dos lotes urbanos). No entanto, embora o projeto
de camadas fsicas seja um problema a ser tratado nas etapas de projeto lgico ou fsico, diversos
autores afirmam que importante que camadas conceituais sejam definidas durante a fase de projeto
conceitual [WOR 95, HAD 96]. Para Hadzilacos [HAD 96], camadas conceituais no necessitam ter
1
importante ressaltar a diferena entre os conceitos de viso de objetos, em contrapartida viso de campos,
e modelos de objetos, referente orientao a objetos.

uma relao um-para-um com camadas fsicas. Por exemplo, uma nica camada conceitual, como
Hidrografia, pode dar origem a diferentes camadas fsicas, uma contendo somente os rios, outra
contendo somente os lagos, etc.
Aspectos Espaciais
A localizao geogrfica e a forma espacial dos fenmenos geogrficos podem ser
implementadas, em um SIG, atravs de objetos espaciais. Todo objeto espacial possui uma
geometria, que representa a forma espacial do fenmeno, sendo que suas coordenadas devem estar
registradas com base em um determinado sistema de coordenadas (ex.: latitude e longitude) e um
sistema de projeo (ex.: UTM).
Embora os aspectos espaciais dos fenmenos geogrficos possam parecer detalhes que no
deveriam ser tratados durante a modelagem conceitual, a sua incluso no esquema conceitual tem
sido fator fundamental na comunicao com o usurio [LIS 00].
Na viso de objetos, os fenmenos geogrficos so representados por objetos espaciais do
tipo ponto, linha, polgono ou combinaes destes, enquanto que na viso de campo uma superfcie
contnua pode ser representada, por exemplo, atravs de modelos numricos, conjuntos de isolinhas,
polgonos adjacentes e grade de clulas.
Diferentes abordagens tm sido propostas para modelagem conceitual dos aspectos espaciais
dos fenmenos geogrficos. A abordagem mais comum a que define uma associao entre a
classe que descreve o fenmeno e a classe do tipo de objeto espacial correspondente a sua
2
representao espacial. Alguns modelos, no entanto, utilizam pictogramas para substituir esta
associao.
Mltiplas Representaes
Uma das caractersticas das aplicaes geogrficas a possibilidade de existncia de mltiplas
representaes para um mesmo fenmeno geogrfico. Esta necessidade surge em resposta
complexidade da realidade a ser representada e s diferentes vises que os usurios tm de um
mesmo fenmeno. Um fenmeno geogrfico pode ser representado em diferentes escalas ou
projees, inclusive por diferentes objetos espaciais.
A existncia de mltiplas representaes pode ser modelada atravs da incluso de vrias
associaes entre o fenmeno geogrfico e os tipos de objetos espaciais correspondentes.
Relacionamentos Espaciais
Uma das tarefas mais importantes quando se est modelando os dados de uma aplicao a
identificao de quais os relacionamentos que devero ser mantidos no banco de dados, dentre os
possveis relacionamentos observveis na realidade. No domnio das aplicaes geogrficas este
problema bem complexo, uma vez que o nmero de relacionamentos possveis de serem mantidos
ainda maior, devido existncia dos relacionamentos espaciais entre os fenmenos geogrficos.
A maioria dos SIG fornece estruturas especiais para o armazenamento explcito de alguns tipos
de relacionamentos espaciais. Normalmente so mantidos somente os relacionamentos de
adjacncia ou de conectividade, deixando os demais tipos de relacionamentos espaciais (ex.:
pertinncia, cruza) para serem calculados a partir das coordenadas espaciais dos objetos. Por outro
lado, existem aplicaes nas quais alguns relacionamentos espaciais possuem significado semntico
relevante, tal como vizinhana e cruzamento de ruas. Nestes casos o projetista necessita especificar
estas informaes no modelo de dados.
As cardinalidades associadas aos relacionamentos formam um conjunto de restries de
integridade que devem ser mantidas entre as instncias dos objetos no banco de dados. Para os
relacionamentos espaciais, novos tipos de cardinalidade podem ser definidos, tais como, associao
espacial, pertinncia, etc. Um modelo conceitual de dados para SIG deve fornecer meios para que o
projetista represente os relacionamentos a serem mantidos no banco de dados geogrficos. Isto inclui
tanto os relacionamentos convencionais como os relacionamentos espaciais.
2
Pequenos smbolos grficos includos na definio das classes/entidades.

Aspectos Temporais
A maioria dos SIG disponveis atualmente considera os fenmenos como se o mundo existisse
somente no presente. Dados geogrficos so alterados ao longo do tempo, mas o histrico dessas
transformaes no mantido no banco de dados.
Para Hadzilacos [HAD 96], a necessidade de os dados geogrficos estarem qualificados com
base no tempo, se deve necessidade de se registrar estados passados de forma a possibilitar o
estudo da evoluo dos fenmenos geogrficos. Para possibilitar uma anlise de dados com base na
evoluo dos fenmenos geogrficos necessrio adicionar aos SIG as potencialidades dos
sistemas de bancos de dados temporais. Isto implica na incluso de informaes temporais
relacionadas aos fenmenos geogrficos e da extenso das linguagens de consulta disponveis para
que estas suportem clusulas de condio associadas a aspectos temporais [WOR 95].
Alguns modelos conceituais propostos na literatura estendem a notao grfica para ressaltar a
existncia dos aspectos temporais em determinadas classes. O modelo GeoOOA [KOS 97], por
exemplo, utiliza um pictograma especial (smbolo de um relgio), para diferenciar classes temporais .
Alm disso, a notao grfica do modelo estendida para representar dois tipos especiais de
relacionamentos temporais: conexo ancestral e conexo de atributo temporal. A figura abaixo ilustra
um trecho da modelagem de um sistema de cadastramento de lotes.
Classe espao-temporal Classe convencional
LOTE ESCRITURA DONO

Nmero Nmero Nome
0,N Territrio 1,N 1,N Data 1,N 0,N Endereo
Tipo de uso Relatrio Dt-nasc
Validade uso Compra
1,N
Conexo ancestral Conexo de atributo temporal
No modelo GeoOOA, um relacionamento de conexo ancestral permite a associao entre

verses de um mesmo objeto. Por exemplo, um lote pode ser dividido, em um determinado momento,
dando origem a dois novos lotes. A conexo de atributo temporal usada para destacar uma
associao decorrente da necessidade de modelar o aspecto temporal de um atributo. Na figura
acima, a classe Escritura resultado da modelagem dos dados histricos do lote. Na modelagem no
temporal, o usual que cada lote tenha uma nica associao com o proprietrio atual.
Modelos Conceituais de Dados para SIG

Os requisitos apresentados anteriormente fazem com que modelos conceituais convencionais,
como o modelo E-R, no sejam adequados para modelagem de bancos de dados geogrficos, ou
seja, para modelagem de aplicaes de SIG. Atualmente, diversas propostas de modelos conceituais
de dados especficos para bancos de dados geogrficos podem ser encontrados na literatura. Estes
modelos so, na verdade, extenses dos modelos tradicionais. Abaixo so citados os principais
modelos encontrados na literatura, classificados de acordo com o tipo de formalismo usado como
base:
Formalismo E-R: Modul-R [BED 96], GISER [SHE 97], Geo-ER [HAD 97];
Formalismo OO: GMOD [PIR 97], Geo-OMT [BOR 97], GeoOOA [KOS 97], MADS [PAR 98],
Perceptory [BED 99], UML-GeoFrame [LIS 99].
Uma anlise crtica desses modelos, feita com base nos requisitos descritos nesta seo
apresentada em [LIS 99a].

4.3 Modelando Banco de Dados Geogrficos com UML-GeoFrame

Nesta seo apresentada a abordagem UML-GeoFrame, ou seja, o uso da linguagem UML
(Unified Modeling Language) [BOO 98], com base no framework GeoFrame [LIS 99], para a
modelagem conceitual de bancos de dados geogrficos. Esta soluo possibilita a obteno de
esquemas conceituais de dados numa linguagem bastante clara e, portanto, de fcil entendimento
por parte dos usurios.
No objetivo desse material, a apresentao da linguagem UML. Para maiores detalhes o
leitor pode consultar, por exemplo, [BOO 98]. Apenas uma pequena parte dos recursos da UML so
utilizados, os quais fazem parte do modelo de classes, cujos principais construtores grficos so
mostrados na figura abaixo. Por questes, tambm de simplificao, a parte da modelagem dinmica
(mtodos) no est sendo abordada.
PACOTE
multiplicidade
Classe 1 * ClasseAgregada
atributo : domnio atributo : domnio

generalizao - associao
especializao
agregao
composio
Subclasse Subclasse ClasseComponente
atributo : domnio atributo : domnio atributo : domnio
instanciao objeto : classe
Os mecanismos de abstrao e os respectivos elementos construtores da linguagem UML, que

so utilizados na abordagem UML-GeoFrame, esto resumidos a seguir:
Classificao Nos modelos orientados a objetos, um fenmeno de interesse da aplicao
representado como um objeto, o qual possui uma estrutura, capaz de armazenar suas
caractersticas (atributos) e um comportamento, descrito pelo conjunto de operaes que
podem ser realizadas com o objeto. Objetos semelhantes so modelados atravs da definio
de uma classe, a qual especifica um conjunto de atributos que descrevem a estrutura e um
conjunto de mtodos (ou operaes) que definem o comportamento dos objetos definidos pela
classe.
Instanciao Um objeto pertencente a uma classe dito ser uma instncia desta classe.
Generalizao Classes semelhantes podem ser agrupadas e descritas de forma
generalizada. Neste caso, as propriedades da classe genrica (superclasse), ou seja, atributos,
mtodos e associaes, so herdadas pelas classes que foram generalizadas (subclasses).
Especializao A especializao o mecanismo inverso da generalizao, no qual uma
classe genrica (superclasse) pode ser especializada em uma ou mais classes especficas
(subclasses), as quais herdam as propriedades da superclasse, alm de novas propriedades
poderem ser definidas.
Associao Representa os relacionamentos que podem haver entre objetos de diferentes
classes. Multiplicidade o nome dado cardinalidade de uma associao.
Agregao Tipo especial de associao para representar relacionamentos entre objetos
compostos e suas partes.
Composio Tipo especial de agregao na qual a existncia do objeto composto (o todo)
depende da existncia dos objetos componentes (suas partes).

Alm dos mecanismos de abstrao relacionados anteriormente, a abordagem UML-GeoFrame

utiliza dois elementos prprios da linguagem UML. So eles:
Pacote Usado para particionar um diagrama de classes atravs do agrupamento de
elementos da linguagem UML.
Esteretipo Mecanismo de extenso dos construtores da linguagem UML. Permite que o
projetista defina novos construtores e o utilize na elaborao de diagramas UML.
A figura abaixo ilustra um exemplo de diagrama de classe elaborado usando a UML. Algumas
leituras que podem ser feitas neste diagrama so: uma Quadra uma agregao de Lotes; Lote
Edificado e Lote Territorial so especializaes de Lote; uma Edificao uma composio de
Unidades Edificadas, as quais esto associadas a um proprietrio cada; o diagrama de classes foi
includo em um pacote denominado Loteamento.
Loteamento
Proprietrio Quadra
1
1
* * *
Unidade
Edificada Lote
* 1 Lote Lote
Edificao
Edificado Territorial
De forma semelhante ao modelo E-R, o diagrama de classes da linguagem UML tambm no

adequado modelagem de banco de dados geogrficos, por no atender a vrios dos requisitos
impostos pelas aplicaes de SIG. A seguir descrito o GeoFrame, o qual estende os construtores
da linguagem UML atravs da definio de um conjunto simples de esteretipos para serem usados
na modelagem de banco de dados geogrficos.
GeoFrame
GeoFrame um framework conceitual que fornece um diagrama de classes bsicas para
auxiliar o projetista nos primeiros passos da modelagem conceitual de dados de uma nova aplicao
de SIG [LIS 99]. Um framework pode ser definido como um projeto genrico em um domnio que pode
ser adaptado a aplicaes especficas, servindo como um molde para a construo de aplicaes.
Esta definio fornece uma viso bem mais abrangente sobre a potencialidade de um framework do
que as definies apresentadas por autores mais ligados programao orientada a objetos. Por
exemplo, Ralph Johnson define um framework como sendo um projeto reutilizvel de um programa,
ou parte de um programa, expresso como um conjunto de classes [JOH 92].
Como instrumento de reutilizao, um framework no necessita estar implementado em uma
linguagem de programao para fornecer a soluo parcial a uma famlia de problemas. O framework
GeoFrame (figura seguinte) foi elaborado sob esse enfoque mais genrico, onde o mesmo expressa a
idia de um projeto conceitual parcial para uma famlia de aplicaes geogrficas.

* retrata 1
Tema Regiogeogrfica
nome descrio
*
* *
ObjetoNoGeogrfico FenmenoGeogrfico
CampoGeogrfico ObjetoGeogrfico
1 1
representa representa
* *
RepresentaoCampo ObjetoEspacial 2..n
Ponto Linha Polgono ObjEspComplexo
GradeClulas PolAdjacentes Isolinhas GradePontos TIN PontosIrregulares
O GeoFrame foi definido de acordo com as regras do formalismo da orientao a objetos,

utilizando a notao grfica do diagrama de classes da linguagem UML. As subsees seguintes
descrevem as classes do diagrama.
Tema e RegioGeogrfica
As classes TEMA e REGIOGEOGRFICA formam a base de qualquer aplicao geogrfica. Toda
aplicao geogrfica tem como objetivo o gerenciamento e a manipulao de um conjunto de dados
para uma determinada regio de interesse, constituindo um banco de dados geogrfico. Assim, para
cada regio geogrfica pode-se especificar uma coleo de temas.
Outra vantagem da utilizao do conceito de temas, no esquema conceitual, que ele funciona
como um mecanismo para reduo da complexidade em grandes esquemas. comum existirem
aplicaes geogrficas com centenas de entidades modeladas (ex.: SIGPROGB [LIS 97]). O uso de
temas permite ao projetista dividir o esquema em subesquemas coesos, nos quais so agrupadas
classes fortemente relacionadas entre si. Em grandes projetos, conjuntos de temas afins podem ser
agrupados em um tema mais genrico, formando uma hierarquia de temas.
ObjetoNoGeogrfico e FenmenoGeogrfico
Em um banco de dados geogrficos existem, alm dos dados referentes queles fenmenos
georreferenciados, com ou sem representao geoespacial, objetos convencionais presentes em
qualquer sistema de informao. Alguns objetos no possuem referncia com relao a uma
localizao geogrfica, sendo tratados, genericamente, como instncias de subclasses da classe
OBJETONOGEOGRFICO.
A classe abstrata FENMENOGEOGRFICO generaliza qualquer fenmeno cuja localizao em
relao superfcie terrestre seja considerada. Por exemplo, um lote de terra uma instncia de
FENMENOGEOGRFICO caso seus atributos espaciais estejam representados no banco de dados.
Fenmenos geogrficos e objetos no geogrficos podem estar relacionados entre si
(associao relacionaCom), como no caso em que todo lote pertence a um proprietrio. A
modelagem desse tipo de relacionamento permite que os dados armazenados em um SIG estejam
integrados com os demais sistemas de informao da organizao.

CampoGeogrfico e ObjetoGeogrfico
Fenmenos geogrficos so percebidos, na realidade, segundo as vises dicotmicas de
campo e de objeto [GOO 92]. Essas duas vises acarretam diferentes maneiras de modelagem dos
fenmenos geogrficos. As classes CAMPOGEOGRFICO e OBJETOGEOGRFICO especializam a classe
FENMENOGEOGRFICO, permitindo ao projetista especificar, de forma distinta porm integrada, os
campos e os objetos geogrficos, respectivamente.
A classe abstrata OBJETOGEOGRFICO uma generalizao de todas as classes do domnio
que so percebidas na viso de objetos. Neste caso esto includas aquelas classes que
representam fenmenos geogrficos que podem ser individualizados, ou seja, que possuem
identidade prpria e suas caractersticas podem ser descritas atravs de atributos.
A classe abstrata CAMPOGEOGRFICO generaliza os fenmenos que se enquadram na viso de
campo. Campos geogrficos so modelados como funes sobre uma varivel. Com base nesta
definio, um campo geogrfico pode ser modelado conceitualmente como subclasse de
CAMPOGEOGRFICO. Alguns tipos de campos geogrficos, os chamados categricos, possuem uma
associao especial com uma classe que representa a imagem da funo de mapeamento do campo,
uma subclasse de OBJETONOGEOGRFICO.
ObjetoEspacial
uma classe abstrata cujas subclasses formam o conjunto mnimo de construtores para a
especificao do componente espacial dos fenmenos geogrficos na viso de objetos. Alguns
fenmenos geogrficos podem apresentar dimenso espacial complexa, ou seja, composta por outros
objetos espaciais (ex.: um arquiplago). Assim, a classe O BJETOESPACIAL, possui as subclasses
(PONTO, LINHA, POLGONO e OBJESPACIALCOMPLEXO), que constituem o conjunto mnimo de classes
necessrias para a fase do projeto conceitual.
RepresentaoCampo
Os aspectos espaciais de um campo geogrfico so abstrados de forma diferente dos
aspectos espaciais de um objeto geogrfico. Para especificao do componente espacial de um
campo geogrfico so usadas as subclasses da classe REPRESENTAOCAMPO. So elas:
GRADECLULAS, POLADJACENTES, ISOLINHAS, GRADEPONTOS, TIN e PONTOSIRREGULARES.
Um mesmo campo geogrfico pode ter seu componente espacial abstrado de diferentes
formas, ou seja, atravs de mais de um desses modelos. Por exemplo, o campo Temperatura pode
ser abstrado por meio de um conjunto de pontos irregularmente distribudos ou por meio de isolinhas.
Problema semelhante ocorre com os objetos geogrficos cujos componentes espaciais podem ser
percebidos, ora por formas alternativas, ora por formas duplas, dependendo de aspectos como a
escala com a qual se pretende capturar a forma espacial de cada fenmeno. A possibilidade de haver
mltiplas representaes sinalizada no GeoFrame, atravs das associaes (1:n), denominadas
representa.
Processo de Modelagem UML-GeoFrame

A abordagem UML-GeoFrame permite a soluo da maioria dos requisitos de modelagem
apresentados na Seo 4.2. Um esquema conceitual de dados geogrficos construdo com base no
GeoFrame inclui, por exemplo, a modelagem dos aspectos espaciais da informao geogrfica e a
diferenciao entre objetos convencionais e objetos/campos geogrficos.
O processo de modelagem com base na abordagem UML-GeoFrame envolve trs etapas:
Passo 1: identificar temas e sub-temas para cada rea geogrfica;
Passo 2: para cada tema, elaborar o sub-diagrama de classes. Associar classes de diferentes
temas;
Passo 3: modelar o componente espacial para cada fenmeno geogrfico identificado.
A seguir, cada passo apresentado em maiores detalhes.

Passo 1 Identificar temas por regio geogrfica

Uma das primeiras escolhas a ser realizada, no desenvolvimento de uma nova aplicao de
SIG, a escolha da rea geogrfica para a qual os dados sero coletados e analisados. A seguir,
partindo-se dos objetivos iniciais da nova aplicao, deve ser feita a identificao dos principais temas
para os quais os dados sero coletados e mantidos no banco de dados geogrfico.
Na abordagem UML-GeoFrame, temas so representados atravs do construtor Pacote da
linguagem UML. Os diversos temas identificados na aplicao so modelados atravs da elaborao
de um diagrama hierrquico de temas para cada regio geogrfica da aplicao. A figura abaixo
ilustra o diagrama de temas do sistema de gerenciamento costeiro da regio norte do litoral do estado
do Rio Grande do Sul [LIS 97].
LitoralNorteRS : RegioGeogrfica
MeioAmbiente AtividadeAntrpica
Abastecimento
Clima Hidrografia ONGs
gua
Relevo Vegetao Solos Estrada AtivIndustrial
Passo 2: Construir diagramas de classes por tema

A partir da anlise dos requisitos da aplicao, um diagrama de classe deve ser elaborado para
cada tema especificado. Com base no diagrama de classes do framework GeoFrame, as classes da
aplicao devem ser modeladas como subclasses de uma das classes OBJETOGEOGRFICO,
CAMPOGEOGRFICO ou OBJETONOGEOGRFICO.
O problema que ocorre o surgimento de um grande nmero de relacionamentos de
especializao entre as diversas classes da aplicao e estas trs classes do GeoFrame. A soluo
proposta pela abordagem UML-GeoFrame a substituio destes relacionamentos de especializao
por esteretipos. A figura abaixo ilustra o conjunto total de esteretipos utilizados na abordagem
UML-GeoFrame.
Fenmeno geogrfico e Componente espacial Componente espacial

Objeto convencional de objetos geogrficos de campos geogrficos
3 Objeto geogrfico Ponto 8 Pontos irregulares

= Campo geogrfico Linha 9 Grade de pontos
4 Objeto no geogrfico
Polgono 1 Polgonos adjacentes
Obj. espacial complexo ; Isolinhas
<<funo>> funo categrica
< Grade de clulas
: TIN
Esteretipos do framework GeoFrame
O primeiro conjunto de esteretipos (Fenmeno geogrfico e Objeto convencional) usado

para diferenciar os dois principais tipos de objetos pertencentes a um banco de dados geogrficos:
3
(1) Fenmeno geogrfico, que especializado em Objeto geogrfico ( ) e Campo geogrfico ( ), =
segundo as duas formas de percepo dos fenmenos geogrficos; (2) Objeto no geogrfico, ou
seja, objetos sem representao espacial so modelados de forma tradicional e so identificados
atravs do esteretipo ( ).4
Passo 3: Modelar o componente espacial dos fenmenos geogrficos

O terceiro passo, que pode ser executado simultaneamente ao segundo passo, implica na
especificao dos possveis tipos de representao espacial dos fenmenos geogrficos. De acordo
com o diagrama de classes do GeoFrame, o componente espacial dos campos e objetos geogrficos
modelado atravs de associaes (Representa) entre as classes da aplicao e as subclasses de
REPRESENTAOCAMPO e OBJETOESPACIAL, respectivamente. Novamente, a fim de evitar a poluio
visual do diagrama de classes, estas associaes so substitudas por esteretipos.
O segundo e o terceiro conjuntos de esteretipos apresentados na figura anterior
(Componente espacial de objetos geogrficos e Componente espacial de campos geogrficos) so
usados para a modelagem do componente espacial de fenmenos segundo as vises de objeto e de
campo, respectivamente. A existncia de mltiplas representaes modelada atravs da
combinao de dois ou mais esteretipos em uma mesma classe. Por exemplo, uma classe Municpio
pode ter duas formas de abstrao de seu componente espacial, pontual e/ou poligonal, o que
especificado pelo par de esteretipos ( ).
Por ltimo, o esteretipo <<funo>> usado para caracterizar um tipo especial de

associao que ocorre quando da modelagem de campos categricos. Segundo Chrisman [CHR 97],
numa estrutura de cobertura categrica o espao classificado em categorias mutuamente
exclusivas, ou seja, uma varivel possui um valor do tipo categoria em todos os pontos dentro de uma
regio (ex.: tipos de solos).
As figuras abaixo apresentam dois exemplos de diagrama de classes de aplicaes de SIG
nas reas de aplicao de gesto urbana e monitoramento ambiental, respectivamente, as quais
foram modeladas segundo a abordagem UML-GeoFrame.
Loteamento SistemaVirio
4 Quadra
3 4 Sistema 3
Proprietrio Logradouro
1
*
Virio

1
* * * * * *
Unidade 4 3 * 1 Trecho 3
*
Cruza- 3
Edificada Lote * *

Lograd
mento
*
UsoSolo
3 * 1 Lote Lote UsoSolo = <<funo>> 4

TipoUso
Edificao

Edificado Territorial Urbano
1
USO-SOLO
4
ATIV_CARVO
3 4 =

1
Municpio TipoUsoSolo
EmpresaCarbonfera UsoCobSolo funo
nomeMun : char 1 tipoUso : int

dataEmancip : date * nomeEmpresa : char descrTipoUso : char
produo : int
reaMun : real
numOperrios : int
= 3
histrico : char BASE_CART
produtividade : real
classFuncional : int
1
<
3*
ImagemSat RecursoHdrico
*
MinaCarvo

* 3 data : date
=
PermanIntermi : boolean
3
nome : char
tipoExplorao : int
1 Jazida
lavrado : boolean

89;
Topografia Rodovia

ativa : boolean
jurisdio : char

4.4 Projeto Lgico de Banco de Dados Geogrficos

As mesmas regras de transformao de esquema conceitual em esquema lgico, apresentadas
na Seo 3, podem ser aplicadas tambm em banco de dados geogrficos. No entanto, as regras
apresentadas anteriormente no so suficientes, devido necessidade de transformao do
componente espacial dos fenmenos geogrficos.
Ao contrrio dos SGBD relacionais, que tm como base um modelo bem definido, os softwares
de SIG no possuem um modelo de dados nico, ou seja, cada SIG tem seu prprio modelo lgico e
suas prprias estruturas de armazenamento. Isto faz com que no exista um conjunto nico de regras
de transformao para bancos de dados geogrficos.
O consrcio Open GIS (Open GIS Consortium - OGC), fundado em 1994 por fornecedores de
software, companhias de telecomunicaes, universidades, rgos governamentais, entre outros,
uma organizao internacional que est criando novas padronizaes tcnicas e comerciais para
garantir interoperabilidade em SIG [BUE 98]. O consrcio busca criar uma especificao de software
e novas estratgias empresariais, a fim de tornar os sistemas de geoprocessamento abertos e
integrar os dados geogrficos e as operaes necessrias para manipular esses dados. No momento
em que os softwares de SIG estiverem integrados ao modelo de dados Open GIS, a ser possvel a
unificao das regras de transformao.
Nesta seo apresentado um conjunto genrico de diretrizes para transformao de
esquemas conceituais, elaborados segundo a abordagem UML-GeoFrame, para um esquema lgico
espao-relacional, encontrado na maioria dos SIG que so construdos segundo uma arquitetura
dual.
Normalmente, numa viso simplificada, pode-se dizer que os SIG organizam os dados
descritivos em SGBD relacionais e os dados espaciais atravs de um conjunto de camadas, tambm
denominadas de layer, cobertura ou plano de informao, dependendo do software de SIG em
questo. Assim, um esquema conceitual UML-GeoFrame deve ser transformado em um conjunto de
tabelas e um conjunto de camadas com dados geo-espaciais. A figura seguinte ilustra esta idia.
CONCEITUAL LGICO
temas camada, categoria, diretrio
Eletricidade
Eletricidade
Hidrografia
Lagos
Cadastro
Rios
Cadastro
+ { tabelas }
Inicialmente, as regras apresentadas para transformao de esquemas E-R em esquemas

relacionais devem ser aplicadas para a transformao de classes e associaes em tabelas. A seguir,
so apresentadas as diretrizes para as diversas possibilidades de transformao do componente
espacial dos fenmenos geogrficos.

Transformando Objetos Geogrficos (3)

Existem duas possibilidades para transformar o componente espacial das classes da aplicao
modeladas como subclasses da classe OBJETOGEOGRFICO, do GeoFrame. A primeira a
transformao mais comum, na qual o objeto geogrfico possui atributos descritivos e representao
espacial. Neste caso, os atributos descritivos so transformados em colunas de uma tabela
correspondente no SGBD, enquanto cada tipo de representao espacial d origem a uma camada
(ou layer) que contm a forma, a localizao e, em alguns casos, os relacionamentos espaciais dos
fenmenos geogrficos representados pelas instncias da classe sendo transformada.
importante observar que uma camada no nvel lgico pode vir a ser implementada atravs de
mltiplas camadas fsicas, dependendo do tipo de estrutura de dados utilizada no SIG em questo.
Por exemplo, a figura abaixo ilustra a transformao da classe Municpio. Em um SIG como o MGE
da Intergraph, alm das camadas para armazenamento das formas poligonais e pontuais, seria
adicionada uma camada especfica para armazenar a localizao da toponmia, ou seja, do texto
formatado contendo o nome dos municpios.
CONCEITUAL LGICO
objeto geogrfico
com atributo e com representao espacial
Municpio
Municpios
codMun
nomeMun Municpios
pop
dtEmanc Ligao
Tabela de Municpios
codMun nomeMun pop dtEmanc
A segunda possibilidade de transformao quando o objeto geogrfico no possui atributos

descritivos, mas apenas representao espacial. Neste caso, no existem atributos descritivos para
serem transformados. A transformao do componente espacial idntica ao caso anterior. A figura
abaixo ilustra um exemplo tpico.
CONCEITUAL LGICO
objeto geogrfico
sem atributo, mas com representao espacial
rvore
3
rvores
Objeto sem tabela correspondente
Transformando Objetos No Geogrficos (4)

A transformao de objetos no geogrficos, ou seja, possui apenas atributos descritivos,
feita de forma idntica transformao de entidades apresentada na Seo 3.3. A figura seguinte
ilustra a transformao da classe Proprietrio em uma tabela do SGBD.

CONCEITUAL LGICO
objeto no geogrfico
Proprietrio
Objeto sem representao espacial
CPF
nome
endereo Tabela de Proprietrios
CPF nome endereo
Transformando Campos Geogrficos (=)

A transformao de campos geogrficos, na maioria da vezes, feita atravs da escolha de um
tipo de representao espacial para o campo sendo transformado. A figura abaixo ilustra dois
exemplos de campos geogrficos que no geram informaes no SGBD.
CONCEITUAL LGICO
campo geogrfico
Relevo=
;
Representao vetorial
UsoSolo=
<
Representao matricial
Alguns campos geogrficos, no entanto, podem estar diretamente relacionados a algum tipo de
legenda. Na abordagem UML-GeoFrame este tipo de associao feita atravs de um esteretipo
especial identificado por <<funo>>. A figura abaixo ilustra um exemplo tpico de campo geogrfico
que possui uma ligao especial com uma tabela correspondente no SGBD.
CONCEITUAL LGICO
campo geogrfico
Solos =
1 Representao vetorial com topologia
<<funo>> Ligao
TipoSolo
4 Tabela de Tipos de Solos
tipo descrio

Em alguns SIG a tabela associada a este tipo de campo geogrfico pode no estar
necessariamente armazenada no SGBD, mas sim, ser mantida junto com a estrutura dos dados
espaciais. Exemplos de SIG que trabalham desta forma incluem o Idrisi e o Spring.
Um aspecto importante a ser observado que estes exemplos servem para chamar a ateno
do leitor sobre a diferena existente entre o nvel de abstrao em que os fenmenos geogrficos so
classificados nas vises de campo e de objetos, e o nvel de abstrao mais baixo, no qual as
estruturas de dados so classificadas como sendo vetoriais ou matriciais (raster). Observe na figura
anterior que o campo geogrfico est sendo transformado em uma estrutura vetorial com topologia.
Este mesmo campo geogrfico poderia ter sido transformado para uma estrutura de dados matricial,
onde cada clula estaria associado a um determinado tipo de solo.
Da mesma forma, o componente espacial de um fenmeno geogrfico percebido na viso de
objetos (ex.: estados brasileiros) pode ser transformado em uma camada fsica implementada tanto
numa estrutura de dados matricial como numa estrutura de dados vetorial (com ou sem topologia). A
figura abaixo ilustra fenmenos geogrficos percebidos na viso de objetos (rio, estrada, etc)
podendo ser implementados atravs dos dois tipos de representao espacial.
4.5 Estudo de Caso

O governo de um novo pas africano, chamado Zimbabum, enviou seus tcnicos ao Brasil para
serem treinados em geoprocessamento. Uma de suas necessidades o auxlio na estruturao do
banco de dados geogrficos. A seguinte descrio foi obtida a partir de uma conversa inicial.
O pas tem como lngua oficial o portugus, mas existem mais de 20 lnguas faladas por
diferentes tribos. Atualmente, todo o pas est dividido em 14 grandes propriedades, que pertenciam
aos antigos colonizadores. Todas as propriedades agora pertencem ao governo central, o qual deseja
dividi-las, fornecendo um pedao de terra a cada tribo, segundo os seguintes critrios:
As poucas cidades existentes sero transformadas em plos industriais e comerciais, devendo
ter os seus limites estabelecidos num raio de 20km da mancha urbana atual. Esta rea ser
denominada municpio. Cada municpio desenvolve diversos tipos de atividades. importante
manter o valor bruto da produo anual de cada municpio para cada tipo de atividade;
Cada propriedade ser dividida entre as tribos que al se encontram, bem como para grupos de
imigrantes com mais de 800 membros. Cada pedao de terra, denominado fazenda, ter entre
2
20 e 30 Km . Tribos com mais de 1000 membros podero receber mais de uma fazenda, que
devem ser adjacentes;
Cada fazenda deve ter: no mnimo 3 nascentes de rios ou 2 nascentes e um lago; 40% de mata
nativa; 50% de rea com menos de 30 graus de declividade; 50% de terras frteis, sem
considerar reas at 50m de leito de recursos hdricos para rios de categoria 1 e at 20m para
rios de categoria 2 ou 3;

As fazendas no distribudas permanecero sendo do governo para futuras partilhas ou

incentivo imigrao. As atuais propriedades sero administradas por governos regionais, que
recebero 50% das fazendas no distribudas, alm de administrar as cidades que se
encontram em seus limites. Cada governo regional ter uma cidade que ser sua capital;
Ser feito o levantamento das trilhas e caminhos existentes, com vistas a serem abertas novas
estradas, bem como o levantamento dos principais rios que serviro como meio de transporte
fluvial.
Problemas
Usando a notao UML-GeoFrame, elaborar:
1) O diagrama de temas;
2) O esquema conceitual de dados;
3) O esquema lgico descritivo (esquema relacional) e o esquema lgico espacial (planos de
informao e tipo de representao espacial).
Soluo
1) A figura abaixo apresenta o diagrama de temas elaborado.
Zimbabum : RegioGeogrfica
Meio Antrpico Meio Ambiente
Diviso Poltica Hidrografia Tipo de Solo
Meio transporte Relevo Cobertura do Solo
2) As figuras seguintes apresentam os diagramas de classes para cada tema identificado.
Diviso Poltica
Proprie- pertence * Fazenda

3
1
trio
nome
*
rea adjacente
* *
Grupo 3 3 4 1
Tribo Governo
0,1 Propriedade3
Imigrante
1
nome
origem
nome
n-membros
geral-reg
governador
admin
n-membros nome
*
*
fala
fala Prod 4 1
capital
0,1
1 1 Anual * 1
Lngua
4 Tipo 4 ano 3
Atividade Valor bruto Municpio
* *
nome descrio desenvolve nome

descrio indust-com populao

Relevo
Hidrografia
= Declivi- = 3
9:; ;
Relevo
3
dade Rio

1 * Nas-
cente
3 Lago

nome nome
Cobertura do Solo categoria
*
Cobert = <<funo>> Tipo 4 Meio transporte
Solo
< Cobertura
3

Vias
3 3

Tipo de Solo Rede * Rede
viria
Classe 4
Hidro
Tipo de = <<funo>> id-via
tipo
Solo
1 Solo
3) O esquema lgico descritivo (esquema relacional) e o esquema lgico espacial (planos de

informao e tipo de representao espacial) ficam como sugesto de exerccio para o leitor. Utilize
as regras de transformao apresentadas nas sees 3.3 e 4.4.

5 BIBLIOGRAFIA
[ARO 89] ARONOF, S. Geographic Information Systems: a management perspective. Canada:
WDL Publications, 1989.
[BED 96] BDARD, Y. et al. Adapting data models for the design of spatio-temporal databases.
Computers, Environment, and Urban Systems, Bristol-UK, v.20, n.1, 1996.
[BED 99] BDARD, Y. Visual modeling of spatial databases: towards spatial PVL and UML. To
appear in Geomatica, June, 1999.
[BUE 98] BUEHLER, K.; MCKEE, L. The OpenGIS guide. Massachusetts, USA.
Available at: <http://www.OpenGIS.org/techno/guide.html>. Jun, 1998.
[BOO 98] BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. The Unified Modeling Language User
Guide. Addison-Wesley, 1998.
[BOR 97] BORGES, K. A. V. Modelagem de Dados Geogrficos: uma extenso do modelo
OMT para aplicaes geogrficas. Belo Horizonte: Fundao Joo Pinheiro, 1997.
Dissertao de Mestrado.
[BRO 84] BRODIE, M. L. On the development of data models. In: BRODIE, M. L.; MYLOPOULOS,
J.; SCHMIDT, J.W. (Eds.). On Conceptual Modeling. New York: Springer-Verlag,
1984. p.19-48.
[CHE 76] CHEN, P.P.S. The entity-relationship model: Towards a unified view of data. ACM Trans.
Database System, New York, n.1, 1976.
[CHR 97] CHRISMAN, N. Exploring Geographic Information Systems. New York: John Wiley &
Sons, 1997.
[COD 79] CODD, E. F. Extending the database relational model to capture more meaning. ACM
Trans. Database Systems, New York, v.4, n.4, p.397-434, 1979.
[COU 92] COUCLELIS, H. People manipulate objects (but cultivate fields): beyond the raster-vector
debate in GIS. In Theories and methods of spatial-temporal reasoning in
geographic space. Berlin: Springer Verlag, 1992. p.65-77. (Lecture Notes in
Computer Science 639).
[DAT 81] DATE, C. J. An Introduction to Database Systems. 3. ed. Reading: Addison-Wesley,
1981.
[DBM 94] DBMS On Line. A new direction in DBMS: Montage Softwares Dr. Michael R.
Stonebraker takes the wraps off his new object-relational DBMS. DBMS Interview,
1994.
[ELM 94] ELMASRI, R.; NAVATHE, S. B. Fundamentals of Database Systems. 2.ed. Menlo
Park, CA: Addison-Wesley, 1994.
[EUR 96] EUROPEAN COMMITTEE FOR STANDARDIZATION. Geographic information data
description conceptual schema language. Brussels: CEN, 1996. (Report CR
287005).
[GOO 92] GOODCHILD, M. F., Geographical data modeling. Computers & Geosciences, London,
v.18, n.4, p.401-408, 1992.
[HAD 96] HADZILACOS, T.; TRYFONA, N. Logical data modelling for geographical applications.
International Journal of Geographical Information Systems, London, v.10, n.2,
p.179-203, 1996.
[HAD 97] HADZILACOS, T.; TRYFONA, N. An extended entity-relationship model for geographic
applications. SIGMOD Record, V.26, N.3, 1997.

[JOH 92] JOHNSON, R. E. Documenting frameworks using patterns. In: OBJECT-ORIENTED

PROGRAMMING SYSTEMS, LANGUAGES AND APPLICATIONS CONFERENCE -
OOPSLA, 1992, Vancouver. Proceedings... Vancouver: ACM, 1992.
[KOS 97] KSTERS, G. et al. GIS-Application Development with GeoOOA. International Journal
of Geographical Information Science, London, v.11, n.4, 1997.
[LIS 97] LISBOA FILHO, J.; IOCHPE, C.; GARAFFA, I. M. Modelos conceituais de dados para
aplicaes geogrficas: uma experincia com um SIG interinstitucional. In: SIMPSIO
BRASILEIRO DE GEOPROCESSAMENTO, 4., So Paulo, 1997. Anais... So Paulo:
UPUSP, 1997.
[LIS 99] LISBOA FILHO, J.; IOCHPE, C. Specifying analysis patterns for geographic databases
on the basis of a conceptual framework. In: ACM SYMPOSIUM ON ADVANCES IN
GEOGRAPHIC INFORMATION SYSTEMS, 7., 1999, Kansas City, USA.
Proceedings... Kansas City: ACM Press, 1999.
[LIS 99a] LISBOA FILHO, J.; IOCHPE, C. Um estudo sobre modelos conceituais de dados para
projeto de bancos de dados geogrficos. Revista IP-Informtica Pblica, Belo
Horizonte, v.1, n.2, 1999.
[LIS 00] LISBOA FILHO, J.; IOCHPE, C.; HASENACK, H.; WEBER, E. J. Modelagem conceitual
de banco de dados geogrficos: o estudo de caso do projeto PADCT/CIAMB. In:
UFRGS/CENTRO DE ECOLOGIA. Energia e Meio Ambiente. Porto Alegre: Editora
da Universidade, 2000.
[PAR 98] PARENT, C. et al. Modeling spatial data in the MADS conceptual model. In:
INTERNATIONAL SYMPOSIUM ON SPATIAL DATA HANDLING. 1998, Vancouver,
Canada. Proceedings... Vancouver, 1998.
[PEU 84] PEUQUET, D. J. A conceptual framework and comparison of spatial data models.
Cartographica, [S.l.], n.21, p66-113, 1984.
[PEU 95] PEUQUET, D. J. An event-based spatiotemporal data model (ESTDM) for temporal
analysis of geographical data. International Journal of Geographical Information
Systems, London, v.9, n.1, p.7-24, 1995.
[PIR 97] PIRES, F. Um ambiente computacional para modelagem de aplicaes geogrficas.
Campinas: Unicamp, Instituto de Computao, 1997. Tese de Doutorado.
[PRE 87] PRESSMAN, R.S. Software Engineering: a practitioners approach. 2.ed. New York:
McGraw-Hill, 1988.
[SHK 97] SHEKHAR, S. et al. Data models in geographic information systems. Communications
of the ACM, New York, v.40, n.4, 1997.
[ULL 82] ULLMAN, J. D. Principles of Database Systems. 2. ed. Rockville: Computer Science
Press, 1982.
[WOR 95] WORBOYS, M.F. GIS: A Computing Perspective. London: Taylor and Francis, 1995.

Gisbr2001 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Gisbr2001 PDF

Caricato da

Copyright:

Formati disponibili

Estruturao e Modelagem de

Curitiba-PR, maio de 2001

1 CONCEITOS EM SISTEMAS DE BANCO DE DADOS 1

2 NOES BSICAS DO MODELO RELACIONAL 6

3 PROJETO DE BANCO DE DADOS 13

4 PROJETO DE BANCOS DE DADOS GEOGRFICOS 22

1 CONCEITOS EM SISTEMAS DE BANCO DE DADOS

1.1 Banco de Dados (BD)

1.2 Sistema de Gerenciamento de Banco de Dados (SGBD)

Curitiba - PR - Brasil - 14 a 18 Maio 2001 1

As principais caractersticas de um SGBD incluem o suporte a:

1.3 Programa de Aplicao

Sistema Medio SGBD BD

1.4 Sistema de Banco de Dados (SBD)

2 GIS BRASIL 2001 - 7 Show de Geotecnologias

SGBD Software para processar

Software para acessar

Curitiba - PR - Brasil - 14 a 18 Maio 2001 3

1.5 Fases do Projeto de Banco de Dados

Projeto Esquema Conceitual

Projeto Esquema Fsico

4 GIS BRASIL 2001 - 7 Show de Geotecnologias

regras de transformao (mapeamento) dos construtores de abstrao utilizados no esquema

1.6 Modelos de Dados

Curitiba - PR - Brasil - 14 a 18 Maio 2001 5

2 NOES BSICAS DO MODELO RELACIONAL

2.1 Modelo Relacional

30100 S.S.Paraso 90.000 Relao

Outros conceitos empregados no modelo relacional incluem:

6 GIS BRASIL 2001 - 7 Show de Geotecnologias

Domnio de atributo - Conjunto de valores possveis de um atributo. Exemplos de domnios

2.2 lgebra Relacional

Curitiba - PR - Brasil - 14 a 18 Maio 2001 7

O seguinte exemplo de BD ser usado para exemplificar o uso de operaes da lgebra

rea > 300 (FAZENDA)

8 GIS BRASIL 2001 - 7 Show de Geotecnologias

lista de atributos (RELAO)

nomeProp (reaFaz > 400 ^ idProp = dono (PROPRIETRIO X FAZENDA))

Curitiba - PR - Brasil - 14 a 18 Maio 2001 9

nomeProp (reaFaz > 400 ^ idProp = dono (temp))

A tabela abaixo exemplifica algumas tuplas da tabela TEMP:

2.3 SQL Linguagem de Consulta Estruturada

10 GIS BRASIL 2001 - 7 Show de Geotecnologias

Definio do esquema (tabelas)

CREATE TABLE FAZENDA (

SELECT <lista de atributos>

Uma consulta tpica:

SELECT A1, A2, A3,...., An

equivalente, em lgebra relacional, a:

Curitiba - PR - Brasil - 14 a 18 Maio 2001 11

A seguir so apresentados alguns exemplos de consulta em SQL.

Obter fazendas com mais de 400 ha

Obter nome dos proprietrios de fazenda com menos de 200 ha

O conjunto completo de clusulas do comando SELECT o seguinte:

SELECT <lista de colunas>

Apenas as clusulas SELECT e FROM so obrigatrias. Quando existentes, as demais

Obter rea total das fazendas de cada proprietrio

Listar fazendas em ordem decrescente de rea

12 GIS BRASIL 2001 - 7 Show de Geotecnologias

3 PROJETO DE BANCO DE DADOS

3.1 Processo de Modelagem Conceitual

Para cada formalismo conceitual existe um conjunto de linguagens de descrio de esquema

James Martin (eng. informaes)