Radici

Radici: Aplicação Web para
Compartilhamento de Genealogia e
Importação/Exportação de Arquivos
Gedcom
Juliana Oliveira Souza

Sonia Maria Santana Góes
Tatiana Marin
Monografia (2004)
Orientação: Prof. Dr. Paulo A. Pagliosa
Área de Concentração: Aplicação Web
Monografia apresentada ao Departamento de Computação e Estatı́stica da Universidade

Federal de Mato Grosso do Sul como parte dos requisitos para obtenção do tı́tulo de
Especialista em Engenharia de Web Sites
dct ufms
Departamento de Computação e Estatı́stica

Centro de Ciências Exatas e Tecnologia
Universidade Federal de Mato Grosso do Sul
19 de maio de 2004
Eis que eu vos envio o profeta Elias, antes que venha
o dia grande e terrı́vel do Senhor;
E converterá o coração dos pais aos filhos, e o coração
dos filhos a seus pais; para que eu não venha e fira a
terra com maldição.
Malaquias 4:5-6
Aos nossos maridos e filhos.
Agradecimentos
Ao nosso orientador que mesmo sobrecarregado encontrou tempo para nos guiar e ajudar
nos momentos cruciais.
A nossos maridos e familiares por terem nos apoiado durante todo o curso e desenvol-
vimento do projeto.
Aos genealogistas que, através dos questionários ou de qualquer outra forma, ajudaram
em muito na conclusão deste trabalho.
Enfim, a todos que se dispuseram a ajudar dispensando algum tempo em nosso be-
nefı́cio.
Resumo
Souza, J. O; Góes, S. M. S; Marin, T. Radici: Aplicação Web para Compartilhamento
Genealogia e Importação/Exportação de arquivos Gedcom. Campo Grande, 2004. Mono-
grafia (Especialização) - Universidade Federal de Mato Grosso do Sul.
Este trabalho tem como propósito o desenvolvimento de uma aplicação web destinada
a comunidade genealógica, a fim de que seus usuários tenham a oportunidade de publicar
e compartilhar seus dados genealógicos. Há dezenas de sı́tios pessoais na Internet e vários
softwares (gratuitos e não gratuitos) que são dedicados a este tema. Porém, não existe
uma aplicação web dinâmica, gratuita e em Português, que ofereça tais recursos. Um
questionário foi aplicado a genealogistas profissionais e amadores no intuito de conhecer
suas necessidades. Há muitos esforços no sentido de centralizar e compartilhar dados
genealógicos em que este trabalho pode se espelhar. Os objetivos são desenvolver meios
para gerenciamento e consulta dos dados armazenados no site. As tecnologias usadas para
isso são a linguagem script PHP e o banco de dados PostgreSQL. A aplicação reconhece
o formato de arquivos Gedcom com o propósito de possibilitar a importação e/ou ex-
portação dos dados através de tais arquivos. O modelo de dados foi baseado no Gentech
Genealogical Data Model, que utiliza o conceito entidade-relacionamento.
Palavras-chave: aplicação web, genealogia, Gedcom, Gentech Genealogical Data Model

Conteúdo
Lista de Figuras vii
Lista de Tabelas viii
1 Introdução 1
1.1 Justificativas e Motivações . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Dados Empı́ricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Questionário com Genealogistas . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Outros Trabalhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Fundamentos 8
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Fundamentos Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Modelo Conceitual da UML . . . . . . . . . . . . . . . . . . . . . . 9
2.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Gedcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Gentech Genealogical Data Model . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1 O Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.2 Considerações sobre o Modelo . . . . . . . . . . . . . . . . . . . . . 29
2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 A Aplicação 31
3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Decisões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Uso dos Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Modelos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.2 O Uso do Gedcom . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Modelo Navegacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Particularidades da Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.1 Descendência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
v
CONTEÚDO vi
3.6.2 Ascendência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.3 Importação de Arquivos Gedcom . . . . . . . . . . . . . . . . . . . 40
3.6.4 Exportação de Arquivos Gedcom . . . . . . . . . . . . . . . . . . . 43
3.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4 Conclusão 45
4.1 Análise Crı́tica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Comparações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A Questionário 48
B Diagrama - Gentech Genealogical Data Model 50
Referências Bibliográficas 53
Lista de Figuras
2.1 Parte do Sub-modelo de Administração [17]. . . . . . . . . . . . . . . . . . 24

2.4 Parte do Sub-modelo de Evidências [17]. . . . . . . . . . . . . . . . . . . . 26
2.5 Parte do Sub-modelo de Evidências [17]. . . . . . . . . . . . . . . . . . . . 26
2.6 Parte do Sub-modelo de Conclusões [17]. . . . . . . . . . . . . . . . . . . . 27
3.1 Arquitetura cliente/servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Modelo de dados desenvolvido para a aplicação. . . . . . . . . . . . . . . . 34
3.3 Modelo navegacional da aplicação — parte 1. . . . . . . . . . . . . . . . . 35
3.6 Resultado do uso da função Desc(). . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Resultado do uso da função Asc(). . . . . . . . . . . . . . . . . . . . . . . . 41
3.8 Escolhendo o arquivo Gedcom a ser carregado. . . . . . . . . . . . . . . . . 42
3.9 Salvando um arquivo Gedcom com o conteúdo da página. . . . . . . . . . . 44
B.1 Diagrama Completo da Gentech. . . . . . . . . . . . . . . . . . . . . . . . 51
vii
Lista de Tabelas
1.1 Nı́vel X Tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Fontes de Pesquisa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Forma de Publicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Software: importa/exporta Gedcom? . . . . . . . . . . . . . . . . . . . . . 3
viii
Capı́tulo 1
Introdução
1.1 Justificativas e Motivações

1.1.1 Dados Empı́ricos
Os grupos de genealogia são, a exemplo de inúmeros outros nichos da Internet, perten-
centes à categoria daqueles que ganham adeptos a cada dia. Pesquisas em sı́tios de busca,
fóruns e listas de discussão fazem perceber que este é um tópico maciçamente presente na
web. Entretanto, nota-se que, salvo algumas poucas exceções, esforços individuais e ama-
dorismo imperam em meio à diversidade de formatos de apresentação das informações,
onde, na verdade, todos deveriam unir trabalhos seguindo a mesma metodologia, pois
sendo assim, a pesquisa e troca de informações tornar-se-ia mais fácil e eficiente.
Nos mais populares sı́tios de grupos de discussão, os números de grupos de genealogia
são expressivos. No YahooGrupos [1] o tema aparece na primeira página, sob o tı́tulo
“Casa e Famı́lia”. Há, somente na categoria Genealogia, 104 grupos inscritos, dentre os
quais os 5 grupos com mais participantes possuem 331, 249, 236, 196 e 191 associados,
respectivamente. As subcategorias dentro de Genealogia são: Linhagens e Sobrenomes,
com 580 grupos, Origem Étnica que possui 22 grupos (dentro deste há a subcategoria
“Italianos” onde um dos grupos tem 445 inscritos) e com 265 grupos vem a subcategoria
Reuniões Familiares.
Estes números são referentes apenas ao Brasil. Números muito mais expressivos são
obtidos no site YahooGroups (em Inglês) [2]. São 2826 grupos sob a categoria Genealogy
e 5966 grupos nas 6 subcategorias. O grupo que encabeça a lista com mais associados
dentro da categoria Genealogy tem mais de 16 mil participantes. Fazendo-se uma procura
no sı́tio de busca Google [3] pela palavra genealogia1 , escolhendo “páginas em português”,
aparecem mais de 80 mil resultados.
Embora estes números sejam absolutos e não tenha sido feita uma análise mediante
alguma metodologia, é realmente relevante salientá-los, pois de qualquer modo fazem
concluir, mesmo empiricamente, que a genealogia é um tema bastante procurado e como
as pessoas, de um modo geral, sentem-se atraı́das por este tema. Richards [4] afirma que
homens e mulheres no mundo todo compilam e coligem dados genealógicos e realmente não
sabem explicar por quê. O autor conta algumas experiências de pessoas com a genealogia.
Uma delas dá conta de um jovem que, procurando a genealogia de sua famı́lia, encontrou
um livro, onde no prefácio estava escrito:
1
A busca foi feita excluindo-se os resultados contendo Nietzsche, que escreveu o livro A Genealogia
da Moral [F. Nietzche. A Genealogia da Moral. Companhia das Letras, 1998.].
1
1.1. JUSTIFICATIVAS E MOTIVAÇÕES 2
“Este livro foi preparado com grande custo de tempo, esforço e dinheiro
por minha esposa e por mim. Por que o fizemos não o sabemos, mas confiamos
na providência o Altı́ssimo que ele servirá para um fim proveitoso”.
O presidente da junta da Biblioteca de Los Angeles de certa época relatou que gene-
alogia era seu passatempo e, com isso, havia gasto milhares de dólares com registros e
manuscritos. Segundo ele, realmente não sabia que bem isso poderia trazer, mas não con-
seguia deixar de fazê-lo [4]. É bem provável que, através deste trabalho, algumas pessoas
venham a apreciar a genealogia. Certamente este tema cativou todas as integrantes deste
grupo de trabalho.
1.1.2 Questionário com Genealogistas

Na tentativa de justificar este projeto, foi aplicado um questionário entre os dias 23 de
março e 1 de abril de 2004. O questionário foi enviado para o email de mais de 200
genealogistas e interessados no assunto, sendo que 83 responderam. Algumas informações
quanto às rotinas e necessidades foram colhidas, bem como suas opiniões. O questionário
encontra-se no Apêndice A à página 48.
Das 83 pessoas que responderam ao questionário, 56,63% consideram-se no nı́vel in-
termediário em seus trabalhos e/ou pesquisas genealógicas, 39,76% disseram-se iniciantes
e somente 3,61% estão no nı́vel avançado. Mas em relação ao tempo em que se dedicam
à genealogia vê-se que poucos são realmente iniciantes. Somente 8,43% trabalham com
o tema há 1 ano ou menos. 46,99% dos entrevistados responderam que fazem genealogia
de 2 a 5 anos e os que informaram pesquisar genealogia são 44,58%. A tabela 1.1 mostra
um cruzamento dos dados entre em que nı́vel consideram-se na genealogia e a quantidade
de tempo que se dedicam a isso.
Nı́vel Tempo
Avançado 3,61% Mais de 10 anos 100%
Intermediário 56,33% Mais de 10 anos 31,91%
De 6 a 10 anos 29,79%
De 2 a 5 anos 39,30%
Iniciante 39,76% Mais de 10 anos 3,03%
De 6 a 10 anos 12,12%
De 2 a 5 anos 63,64%
1 ano 21,21%
Tabela 1.1: Nı́vel X Tempo.
Foram aplicadas duas questões de respostas múltiplas: “Onde normalmente você pro-
cura e/ou obtém informações?” para conhecer suas fontes e “De que forma você arma-
zena/publica suas informações?”. O resultado destas questões estão nas tabelas 1.2 e
1.3.
Os entrevistados responderam a questões quanto ao uso ou não de softwares ge-
nealógicos e se tal software exporta ou não arquivos Gedcom2 . 83,13% responderam
que usam softwares genealógicos, enquanto que 16,87% disseram que não. A tabela 1.4
2
Gedcom é um formato de arquivo reconhecido pelos softwares genealógicos, usado para troca e com-
partilhamento de informações entre genealogistas. O formato será explicado adiante na seção 2.5 do
capı́tulo 2, à página 8.
Registros Religiosos 80,72%

Registros Civis 79,52%
Sites Pessoais/Portais de Genealogia 78,31%
Informações Verbais 69,88%
Publicações de Outros Genealogistas 67,47%
Livros 66,27%
Outros Registros 53,01%
Outros 40,96%
Periódicos Antigos 38,55%
Tabela 1.2: Fontes de Pesquisa.

Software 79,52%
Manuscritos 51,81%
Site Pessoal 32,53%
Livro 21,69%
Outros 14,46%
Portal de Genealogia 12,05%
Tabela 1.3: Forma de Publicação.
refere-se somente aos questionários que tiveram a resposta “Sim” dadas a pergunta: “Este
software possui a capacidade de importar/exportar arquivos Gedcom?”.
Sim 82,61%
Não 15,94%
Não Sei 1,45%
Tabela 1.4: Software: importa/exporta Gedcom?
Quando perguntados se existe a carência de alguma ferramenta na Internet para o

compartilhamento e/ou publicação de informações genealógicas, 39,76% deles responde-
ram que não, 37,35% disseram que sim, 16,87% não souberam responder e 6,02% não
responderam. Entre as opiniões colhidas dos que responderam “sim”, 45,16% afirmaram
que desejariam que houvesse um sı́tio para armazenar e compartilhar suas informações.
Algumas opiniões que confirmam isso:
“Creio que poderia ser criado um ’mega-portal’ de genealogistas brasileiros,

onde poderiam os mesmos dispor todo seu banco de dados, sendo o dito banco
dividido por região (...).”
“Uma forma de gerenciar meus dados em um ’Banco de Dados Compar-

tilhado’ e que fique armazenado na Internet e não em meu PC, já perdi anos
de trabalho por falta de cópia de segurança (...).”
“Existe, principalmente, a falta de um grande Banco de Dados brasileiro,

onde as pessoas em geral (não só ’genealogistas’) pudessem pesquisar sobre-
nomes e nomes de antepassados (...).”
“(...) acho que [faltam] sites com informações. Bem como formulário cor-
reto para que possamos [postar] toda a árvore (...).”
“Não existe uma árvore genealógica virtual, onde as pessoas possam ir

acrescentando seus ramos em cima de troncos já existentes, mantendo os dados
no site de maneira centralizada. Hoje há muita troca de arquivos Gedcom,
mas nada que ajude a manter arquivos up to date.”
“A maioria das informações/sites disponı́veis na Internet exigem paga-

mento prévio para permitir consulta, sem a menor garantia de possuir a in-
formação que você está procurando (...).”
A outra parte clama por um sı́tio que disponibilize, de alguma forma, registros de
fontes primárias, tais como registros civis e religiosos, publicações e outras fontes.
Embora seja maior o número de genealogistas que digam não haver carência de uma
ferramenta de compartilhamento e publicação de dados genealógicos na Internet, a grande
maioria concorda em publicar suas informações em um sı́tio nestas caracterı́sticas. Sim,
foi a resposta de 79,52%, 13,24% disseram que não, enquanto que os 2,24% restantes afir-
maram não saber ou que publicariam somente com certas condições. Um dos questionados
opinou:
“Parto do princı́pio do compartilhamento para facilitar o intercâmbio das

informações que, muitas vezes, são de interesse de várias pessoas, permitindo-
se dessa forma uma evolução mais rápida das pesquisas desses fatos que, por
si só, já são de infinita dificuldade para descobrir.”
Esta opinião é semelhante à maioria das registradas nas respostas positivas. Os entre-
vistados que responderam negativamente afirmaram que não publicariam suas informações
genealógicas por desejarem comercializar seus dados.
Através destes resultados, pode-se concluir que um sı́tio com as caracterı́sticas que
estão sendo utilizadas no trabalho que é objeto desta monografia é realmente bem vindo.
Embora não se sinta uma necessidade tão grande quanto se esperava no inı́cio, vê-se que
as pessoas ligadas à genealogia provavelmente utilizariam da ferramenta elaborada.
É sabido que o compartilhamento de genealogia pode ser feito através de arquivos
Gedcom. Entretanto após distribuir-se um arquivo para familiares, a fim de que eles
possam ajudar na tarefa de inserirem seus próprios troncos, mesmo que haja um grande
cuidado, é muito difı́cil controlar todas as versões que o arquivo poderá ter no final.
Através da aplicação web proposta neste trabalho isto é feito mais facilmente, bas-
tando informar a senha de sua área restrita a quem desejar e assim cada um adiciona a
informação que lhe convém, mantendo a base de dados atualizada. Através da exportação
dos dados do sı́tio para um arquivo Gedcom, as informações locais também podem ser
atualizadas.
1.1.3 Outros Trabalhos

Aliado aos resultados discutidos anteriormente, este trabalho tenta se espelhar nos es-
forços feitos pela Brigham Young University (BYU) em relação à genealogia e história da
famı́lia. O Departamento de Ciência da Computação desta universidade possui o Family
History Technology Laboratory [5] que tem como objetivo criar tecnologias no sentido de
melhorar e tornar pesquisas genealógicas mais eficazes. Além disso a BYU oferece anual-
mente, desde 2000, um workshop intitulado Annual Workshop on Technology for Family
History and Genealogical Research [6], que é dedicado a novas tecnologias em história da
famı́lia e pesquisas genealógicas. Os trabalhos apresentados nas edições deste workshop

versam desde visualizações de árvores genealógicas, formas eficientes de consulta a ban-
cos de dados disjuntos a rebuscadas formas de digitalização de microfilmes e registros
manuscritos.
Em alguns dos trabalhos apresentados nos 3 anos em que o workshop aconteceu
verifica-se intenção de centralizar o conteúdo genealógico que se encontra espalhado pela
Internet.
“O compartilhamento de informações oferece grande economia para gene-
alogistas. Estes pesquisadores apreciam trabalharem juntos e compartilhar
linhagens comuns uns com os outros. Desde que todos se beneficiem com o
compartilhamento de informações genealógicas, pesquisadores estão normal-
mente mais que dispostos a enviar dados, seja enviando para web, para a Igreja
SUD ou outro repositório conhecido”[7].
Baseados nesta idéia, os autores propuseram um protocolo chamado Genealogy
Network Transfer Protocol (GNTP), que é baseado no protocolo TCP/IP. Este protocolo
permite pesquisas e transferência de informações genealógicas. “Ele provê uma interface
comum que permite aos genealogistas publicarem e pesquisarem informações comparti-
lhadas por colegas pesquisadores” [7].
O GNTP funciona através de duas redes: uma de servidores, formando um anel ponto-
a-ponto e outra formada por pesquisadores que atuam como “publicadores”. Servidores
armazenam meta-informações sobre os dados contidos nos publicadores conectados a eles.
Publicadores são pesquisadores que estão dispostos a aceitarem uploads de arquivos ge-
nealógicos. O protocolo porém não está sendo utilizado. Embora tenha sido encontrado
um software cliente GNTP na Internet [8], não existe servidor disponı́vel e não há in-
formação sobre essa ausência de servidor.
Um esforço semelhante foi empregado em outro trabalho [9], onde foi proposta uma ar-
quitetura de rede para armazenamento distribuı́do de informações genealógicas. A Rede
de Genealogia Global, proposta pelos autores, é composta de 4 camadas. A primeira,
chamada de Source Catalog (Catálogo de Fontes), contém versões digitalizadas de docu-
mentos fontes. A camada seguinte, nomeada Fact Catalog (Catálogo de Fatos), armazena
arquivos em formato Genealogy Markup Language (GML, derivado do XML). Os arqui-
vos GML “provém semântica aos fatos contidos nas fontes no Source Catalog ou fontes
offline em formato digital ou analógico” [9]. A terceira camada, chamada Individual and
Family Relations Catalog, é um mecanismo de pesquisa avançado projetado para dados
genealógicos. Tal camada indexa e armazena a informação contida nos catálogos de fon-
tes e fatos. Finalmente, a quarta camada é a Parallelized Autocompletion, a camada de
interface com o usuário.
A idéia de Barney e Lee [10] foi diferente. Estes propuseram uma ferramenta chamada
Extracting Lineage Information with Java using Automated Heuristics (ELIJAH) a qual
tem a mesma intenção de centralizar a informação, mas com meios e fins diferentes.
ELIJAH trabalha “varrendo” a web em busca de sites de dados genealógicos, coletando
tais dados e armazenando-os em um banco de dados. Segundo os autores:
“...pessoas em todo o mundo (...) postam árvores genealógicas e outras in-
formações em milhões de sı́tios pela Internet. Mesmo que os dados genealógicos
postados por indivı́duos representem um vasto tesouro de informação, isso não
pode ser encontrado tão facilmente. É necessário visitar e pesquisar cada sı́tio
individualmente” [10].
1.2. OBJETIVOS 6
O método proposto funciona através da classificação dos sı́tios pessoais de genealogia

segundo suas estruturas. Num segundo passo algumas regras são aplicadas às informações
constantes no sı́tio, extraindo seus dados e armazenando-os num banco de dados. Nos
testes realizados, 56% dos sı́tios pessoais puderam ter suas informações extraı́das.
A aplicação web desenvolvida para este trabalho não só tem a finalidade de centralizar
informações, mesmo que em longo prazo, mas também promover um meio de integrar
genealogistas e quaisquer pessoas interessadas em suas informações.
1.2 Objetivos
Este trabalho tem como objetivo geral desenvolver mecanismos de uma aplicação web que
torne possı́vel o compartilhamento e a publicação de dados genealógicos utilizando-se das
tecnologias e software livre existente no mercado atualmente.
Os objetivos especı́ficos são:
• Desenvolvimento de rotinas de consulta simples às informações contidas no banco

de dados da aplicação;
• Apresentação dos dados em 3 formatos:
– Ascendência: dado um indivı́duo, mostrar até 4 gerações de seus ancestrais em

formato de árvore genealógica;
– Descendência: dado um indivı́duo, mostrar todos seus descendentes;
– Relatório: dado um indivı́duo, mostrar todas as informações referentes a ele,
tais como nome, data e local de nascimento e óbito (se for o caso), nome dos
pais, nome do cônjuge, data e local de casamento (se for o caso) e seus filhos
(se for o caso).
• Gerenciamento: rotinas de inserção, alteração e remoção de indivı́duos e qualquer

tipo de evento associado a ele.
• Importação de arquivos Gedcom: reconhecer a arquitetura de tais arquivos, extrair

as informações fundamentais neles contidas e armazená-las no banco de dados.
• Exportação de arquivos Gedcom: selecionar informações contidas no banco de dados

e transformá-las em um arquivo Gedcom válido.
Enfim, o esforço foi empregado para apresentar as ferramentas fundamentais para um

sı́tio genealógico. Este trabalho não tem como objetivo preparar um sı́tio completo com
todos os mecanismos que este precisa ter, tais como: contato, FAQ, informações, etc.
1.3 Organização do Texto

O texto deste trabalho está disposto em um só volume, dividido em 3 capı́tulos, além deste.
Em tais capı́tulos são apresentadas as tecnologias e recursos utilizados, assim como uma
explanação do trabalho empregado no desenvolvimento da aplicação web, que é objeto
desta monografia. Cada capı́tulo contém o conteúdo como descrito a seguir.
1.3. ORGANIZAÇÃO DO TEXTO 7
Capı́tulo 2 - Fundamentos
O capı́tulo 2 mostra um resumo das tecnologias empregadas no desenvolvimento da
aplicação web: a linguagem UML, utilizada para a confecção do modelo navegacional,
a linguagem PHP e o banco de dados PostgreSQL. Além destas tecnologias, uma ex-
planação é feita sobre o Gedcom e o Gentech Genealogical Data Model, ambos recursos
utilizados no trabalho.
Capı́tulo 3 - A Aplicação
O capı́tulo 3 apresenta as decisões tomadas sobre as tecnologias empregadas — a lingua-
gem script PHP e o banco de dados PostGreSQL — no desenvolvimento da aplicação
web, bem como recursos utilizados: o arquivo Gedcom e o modelo de dados genealógico
da Gentech, além de uma breve explanação sobre a arquitetura utilizada. O modelo na-
vegacional da aplicação foi desenvolvido através da linguagem UML. O trabalho objeto
desta monografia possui algumas particularidades que são as rotinas para retornar des-
cendência e ascendência a partir de um determinado indivı́duo e importação e exportação
de arquivos Gedcom. Tais particularidades são descritas e é explicado o funcionamento
de cada uma delas.
Capı́tulo 4 - Conclusão
Finalizando, o capı́tulo 4 apresenta a conclusão deste trabalho, apontando as dificuldades
e algumas considerações relevantes. Uma análise é feita, salientando-se o que poderia ter
sido empregado e feito de maneira diferente. Comparações com ferramentas existentes e
uma abordagem quanto à extensões da aplicação são descritas neste capı́tulo.
Capı́tulo 2
Fundamentos
2.1 Introdução
Neste capı́tulo apresenta-se um resumo das tecnologias e recursos utilizados no desen-
volvimento da aplicação web proposta neste trabalho. No modelo navegacional, que será
apresentado no capı́tulo 3, foram usados os conceitos da UML (Unified Modeling Language
— Linguagem Unificada de Modelagem), uma linguagem gráfica para documentação de
artefatos de sistemas complexos de software. Por isso a seção 2.2 deste capı́tulo define
resumidamente os artifı́cios que a linguagem usa.
Na seção 2.3 é introduzida a linguagem script PHP [11], de uso livre e que por suas
caracterı́sticas, caiu no agrado dos desenvolvedores para web. Uma dessas caracterı́sticas
é seu código-fonte aberto, o que já não é visto como fator negativo. Além disso, é fácil de
usar, mesmo com recursos avançados de programação. O PHP é executado em servidor
Apache, que atualmente é considerado o mais estável. Sua estabilidade com outras tec-
nologias é também um ponto positivo e possui suporte para os mais populares bancos de
dados. São demonstradas também as funcionalidades do PHP, como sintaxe da linguagem,
variáveis, tipos de dados, estrutura de controle, saı́da de dados, como utilizar as funções e
chamadas de funções, como passar informações entre páginas utilizando os métodos GET
ou POST e finalmente sobre criação de sessões e suas utilidades em uma aplicação.
A seção 2.4 faz uma breve explanação sobre o banco de dados utilizado na aplicação
web. O PostgreSql [12] foi escolhido por ser um banco mais robusto, sendo também livre,
como o MySQL [13]. Ele é um sistema de gerenciamento de banco de dados com todas as
funcionalidades de um banco comercial, tais como: visões, restrições, seqüências, tipos,
etc.
Conforme descrito na seção 2.5, o Gedcom é um formato de arquivo que tem como
propósito a troca e compartilhamento de informações genealógicas. Sobre o conteúdo de
um arquivo Gedcom pode se dizer que nada mais é do que um banco de dados com forma
seqüencial de registros. O Gedcom adiciona sintaxe às informação através de marcações
e numeração de nı́veis da informação.
O modelo de dados utilizado neste trabalho, apresentado na seção 2.6, foi inspirado
no GDM da Gentech que é um modelo de dados genealógico. O grupo de trabalho
idealizou um conceito de modelo de dados detalhista, classificando as informações em
sentenças genealógicas. O modelo de dados é divido em três sub-modelos: Sub-modelo de
Administração Sub-modelo de Evidências e Sub-modelo de Conclusões.
8
2.2. UML 9
2.2 UML
2.2.1 Fundamentos Iniciais
UML (Unified Modeling Language) é uma linguagem padrão para elaborar projetos de
softwares. É adequada para a modelagem de sistemas complexos, sistema de informação
corporativo e até mesmo aplicações web. Segundo Booch, Rumbaugh e Jacobson [14] a
UML pode ser usada na visualização, especificação, construção e documentação de um
sistema de software. A modelagem permite a compreensão de um sistema e a UML
indica como criar e ler modelos bem-formados, mas não apontam quais modelos deverão
ser criados, nem quando é necessário criá-los. Em cada sı́mbolo empregado na notação
da UML existe uma semântica bem definida; assim, um desenvolvedor poderá usar a
UML para escrever seu modelo e qualquer outro desenvolvedor ou outra ferramenta, será
capaz de interpretá-lo. A UML não é uma linguagem visual de programação, mas seus
modelos podem ser diretamente conectados a várias linguagens de programação, como
Java, C++, Visual Basic, tabelas de bancos de dados relacionais ou armazenamentos de
dados persistentes de um banco de dados orientado a objetos [14].
“A UML é capaz de representar tudo que possa ser melhor expresso em

termos gráficos, enquanto as linguagens de programação representam o que é
melhor expresso em termos textuais”[14].
2.2.2 Modelo Conceitual da UML

A UML tem três elementos principais: os blocos de construção básicos da UML, as regras
que determinam como esses blocos poderão ser combinados e alguns mecanismos comuns
aplicados na UML. Neste trabalho serão descritos os blocos de construção, que possuem
três os tipos : itens, relacionamentos e diagramas.
Existem quatro tipos de itens.
Itens Estruturais. São os substantivos utilizados em modelos da UML, são as partes

mais estáticas do modelo tais como, classes, interfaces, colaborações e casos de uso.
As classes são descrições como conjuntos de objetos que compartilham os mesmos
atributos, operações, relacionamentos e semântica. Graficamente, as classes são
representadas por retângulos, geralmente incluindo seu nome, atributos e operações.
Interface é uma coleção de operações que especificam serviços de uma classe ou com-
ponente, ou seja, descreve o comportamento externamente visı́vel desse elemento.
Costuma aparecer anexada à classe ou componente que realiza a interface. Grafica-
mente, a interface é representada como um cı́rculo e o respectivo nome.
Colaborações definem interações e são um conjunto de papéis e outros elementos
que proporcionam um comportamento cooperativo à soma de todos os elementos.
Representam a implementação de padrões que forma um sistema. Graficamente,
são representadas como elipses com linhas tracejadas, incluindo somente seu nome.
Caso de uso é a descrição de um conjunto de seqüência de ações realizadas pelo
sistema que proporcionam resultados de valor de um certo ator. É utilizado para
estruturar o comportamento de itens em um modelo. Graficamente é representado
por uma elipse com linhas contı́nuas incluindo seu nome.
2.2. UML 10
Itens Comportamentais. São os verbos de um modelo, representando comportamen-

tos no tempo e no espaço. São a parte dinâmica dos modelos UML, ou seja, são
interações ou mensagens e máquinas de estados.
As mensagens trocadas entre um conjunto de objetos e máquina de estado que
objetos ou interações passam durante sua existência em resposta a eventos. Grafi-
camente, uma mensagem é representada como linha cheia com seta, quase sempre
incluindo o nome de suas operações.
Máquina de estados é um comportamento que especifica as seqüências de esta-
dos pelas quais objetos ou interações passam durante sua existência em reposts a
eventos. Graficamente, os estados são representados como retângulo com ângulos
arredondados, incluindo seu nome e respectivos subestados, se houver.
Itens de agrupamento. São as partes organizacionais dos modelos de UML. São os

blocos em que os modelos podem ser decompostos. Existe apenas um tipo de item
de agrupamento: os pacotes. Pacotes são mecanismos de propósito geral para a
organização de elementos em grupos. Graficamente, um pacote é representado como
diretórios com guias, geralmente incluindo somente seus nomes e, às vezes, conteúdo.
Itens Anotacionais. São as partes explicativas dos modelos de UML. São comentários,
incluı́dos para descrever, esclarecer e fazer alguma observação sobre qualquer ele-
mento do modelo. Existe um único tipo deste item, chamado nota. É graficamente
representado por um retângulo com um dos cantos como uma dobra de página,
acompanhado por texto ou comentário gráfico.
Há também quatro tipos de relacionamentos.
Dependência. É um relacionamento semântico entre dois itens, nos quais a alteração de

um (o item independente) pode afetar a semântica do outro (o item dependente),
Graficamente, é representada por linhas tracejadas, possivelmente com setas, in-
cluindo ocasionalmente um rótulo.
Associação. É um relacionamento estrutural que descreve um conjunto de ligações, em

que as ligações são conexões entre objetos. Graficamente, é representada por linhas
sólidas, possivelmente direcionadas, ocasionalmente incluindo rótulos e multiplicida-
des. A agregação é um tipo de associação, onde se tem um relacionamento estrutural
entre o todo e suas partes.
Generalização. É um relacionamento de especialização/generalização, onde os objetos

dos elementos especializados (os filhos) herdam as caracterı́sticas dos objetos do
elemento generalizado (o pai). Assim, os filhos compartilham a estrutura e o com-
portamento dos pais. Graficamente, são representadas por uma linha sólida com
uma seta fechada em branco apontando o pai.
Realização - É um relacionamento semântico entre classificadores, em que um classifica-

dor especifica um contrato que outro classificador garante executar. São encontrados
entre interfaces e as classes ou componentes que as realizam e também entre casos
de uso e as colaborações que os realizam.
Finalmente, um diagrama é a apresentação gráfica de um conjunto de elementos re-

presentado como gráficos de vértices (itens) e arcos (relacionamentos). Um diagrama
2.3. PHP 11
constitui uma projeção de um determinado sistema. O mesmo elemento pode aparecer

em todos os diagramas, em apenas alguns ou em nenhum diagrama. Existem nove tipos
de diagramas na UML: de classes, de objetos, de casos de uso, de seqüências, de gráficos
de estados, de atividades, de componentes e de implantação [14].
2.3 PHP
2.3.1 Caracterı́sticas
O Que É
O PHP (acrônimo recursivo para PHP: Hypertext Preprocessor ) é uma linguagem script
livre, baseada em marcações, largamente usada, destinada especialmente para o desenvol-
vimento de aplicações para web. Não é necessário compilá-la, basta interpretá-la. O PHP
é um módulo oficial do servidor HTTP Apache. É compatı́vel com várias plataformas,
executando em seu formato original em várias versões do UNIX e Windows[15].
Código-Fonte Aberto
Acreditava-se que softwares que não tinham nenhum custo geralmente caiam em catego-
rias como de “programas preenchendo pequenos nichos não-comerciais” ou “programas
fazendo trabalhos sujos, de baixo nı́vel”. Hoje, muitos — senão a maioria — dos mais
importantes softwares são distribuı́dos sem custo. O software para consumidor é visto,
cada vez mais, como uma maneira para se vender mais hardware de servidor, sistemas
operacionais, conectividade, anúncios publicitários, etc. Portanto, o preço total de um
software não é mais uma medida confiável de sua qualidade. Quanto ao servidor, produtos
de código-fonte aberto tornaram-se mais fortes, competindo com os melhores materiais
comerciais.
O que separa os conjuntos de softwares de fonte aberta dos seus competidores, não
é só o preço, mas o controle. Diversos softwares são distribuı́dos sobre várias condições,
sem limitar os propósitos para os quais foi criado[11].
Licença do PHP
A liberdade de código fonte aberto e software gratuito é garantida por um grupo chamado
GPL (GNU General Public License) ou copyleft. O PHP costumava ser liberado tanto
sob a licença GPL como por sua própria licença, com cada usuário livre para escolher
entre eles. Segundo Converse e Park[11], isso mudou recentemente. Agora o programa
como um todo é distribuı́do sob sua própria licença. A maioria das pessoas obtém o PHP
via downloads gratuitos, ou “pagando por ele”, por exemplo, em uma distribuição de
Linux. Usuários de código-fonte aberto podem escolher livremente a melhor equação entre
custo/benefı́cio para cada situação, ou seja, pode-se escolher nenhum custo e nenhuma
garantia, ou algo caro, mas com bom suporte, ou um meio termo.
Facilidade de Uso
“A melhor coisa em se usar PHP é que é extremamente simples para um iniciante, mas
oferece muitas caracterı́sticas avançadas para um programador profissional” [15]. Com
PHP é possı́vel executar qualquer rotina que poderia ser feita com qualquer programa
2.3. PHP 12
CGI, tais como colher informações de formulários, gerar páginas dinâmicas e enviar e
receber cookies, entre outros. Muitas das mais úteis funções especı́ficas, como abrir uma
conexão com um banco de dados ou buscar um correio eletrônico a partir de um servidor
são predefinidas[15].
PHP é Embutido
É uma linguagem usada em conjunto com HTML, ou seja, escreve-se programas PHP no
mesmo arquivo onde o HTML é colocado. O PHP tem pouca relação com leiaute, eventos
ou algo relacionado à aparência de uma página da web.
A linguagem é executada no servidor. Isso significa que o programa não fica disponı́vel
para o usuário que, ao examinar o código fonte da aplicação no navegador, verá somente
as marcações HTML, como mostra o Exemplo 2.3.1.
Exemplo 2.3.1.
<html>
<head>
<title>Meu script PHP</title>
</head>
<body>
<h1>Script em PHP</h1>
<? // Escape para o modo PHP
$texto = "Linha escrita em PHP";
echo"<p>".$texto."</p>";
// retorno para a html
?>
</body>
</html>
Quando um cliente solicita esta página, o servidor web a pré-processa. O servidor

web percorre a página de cima para baixo, procurando por seções do PHP, as quais
ele tentará resolver. Um analisador sintático identificará todas as variáveis atribuı́das
(marcadas por sinais de cifrão) e tentará conectá-las a comandos do PHP nesse caso a
função echo. Se tudo ocorrer bem, o pré-processador por fim retornará uma página HTML
normal para o navegador do cliente. Enfim, o fato do PHP estar embutido na HTML tem
várias conseqüências úteis como ser adicionado rapidamente ao código produzido pelos
editores, servindo para uma divisão de trabalho entre projetistas e aqueles que fazem
scripts aumentando a eficiência da equipe [11].
Compatibilidade com Várias Plataformas

É executado de forma nativa em cada versão popular do UNIX. É compatı́vel com os
três mais importantes servidores da web: servidor HTTP Apache para UNIX e Windows
Microsoft Internet Information Server e Netscape Enterprise Server, conhecido como iPla-
net Server. Também é suportado pelos menos conhecidos, como fhttpd de Alex Belits,
Personal web Server da Microsoft, o AOLServer e servidor de aplicativo Ommniserver da
Omnicentrix [11].
2.3. PHP 13
Compatibilidade com Outras Tecnologias

O PHP torna fácil a comunicação com outros programas e protocolos. A conectividade
com o banco de dados é forte, com suporte de unidade nativa para mais ou menos 15 dos
mais populares bancos de dados, além do ODBC. Suporta protocolos importantes como o
POP3, IMAP e LDAP. Tem suporte para Java e arquiteturas de objeto distribuı́das[11].
Estabilidade
A palavra estabilidade neste contexto significa que o servidor não precisa ser reinicializado
freqüentemente e que o software não sofre alterações e incompatibilidades radicais entre
uma versão e outra. O servidor Apache é considerado o mais estável, embora não seja
o mais rápido e o mais fácil de administrar. O PHP herdou essa confiabilidade e a
implementação é sólida, mas leve. Segundo uma pesquisa feita pelos laboratórios da
Networking Computing em 1999, por um perı́odo de dois meses e meio em um confronto
direto, o servidor Apache com PHP ganhou do IIS/Visual Studio e do Netscape Enterprise
Server/Java no quesito estabilidade de ambiente[11].
2.3.2 Funcionalidades
Sintaxe, Variáveis e Saı́da
Um script em PHP segue um conjunto básico de regras sintáticas, a maioria emprestada de
linguagens de programação como C e Perl. Os requisitos sintáticos do PHP são mı́nimos
e, quando possı́vel, tentam exibir resultados em vez de gerar um erro. Quando houver um
erro de tais regras, será visualizada na janela do browser a mensagem parse error, que
significa “erro de análise sintática”.
O código PHP não reconhece mais de um espaço em branco. Nomes de variáveis são
sensı́veis ao caso, exceto para construções básicas de linguagem (if, then, else, while e
outras) e nomes de funções. Variáveis são indicadas pelo caractere $ inicial, são atribuı́das
utilizando o operador =, não necessitam de nenhuma declaração de tipo. A variável é
global, exceto quando criada dentro de funções, a menos que seja declarado o contrário.
A saı́da para o usuário é através de echo e print. O Exemplo 2.3.2 demonstra esta
funcionalidade.
Exemplo 2.3.2.
<?php
$pais = Brasil;
print (" Valor de "pais": $pais<BR>");

print (" Valor de "pais": $PaiS<BR>");
?>
A saı́da será:
Valor de ”pais”: Brasil

Valor de ”pais”:
2.3. PHP 14
Tipos no PHP
São seis os tipos: inteiros, números de dupla precisão, booleanos, string, array e objeto.
Inteiros são números não-fracionários, números de dupla precisão (doubles) são números
de ponto flutuante, booleanos são os valores verdadeiro ou falso e strings são seqüências
de caracteres. Array é um tipo composto que armazenam outros valores do PHP, inde-
xados tanto por inteiros ou por strings. Objetos são instâncias de classes definidas pelo
programador, que podem ter tanto variáveis membros como funções membro e podem
herdar funções e tipos de dados de outras classes. Somente valores têm tipos no PHP,
variáveis não tem nenhum outro tipo inerente além da atribuição mais recente. Os tipos
de valores são convertidos automaticamente de acordo com a demanda do contexto[11].
Estruturas de Controle
O PHP tem uma estrutura de controle semelhante à linguagem C, que desvia ou faz loop
dependendo dos valores das expressões booleanas, que podem ser combinadas utilizando
operadores booleanos (and, or, !, &&, ||). As estruturas if e switch são utilizadas para
desvio simples enquanto que while, do-while e for são utilizada para loop e exit e die
terminam a execução do script[11].
Funções
PHP possui um grande número de funções predefinidas fornecidas por desenvolvedores de
código-fonte aberto do PHP. “Cada uma dessas funções deve ser documentada (mesmo que
brevemente) no manual on-line em http://www.php.net.” [11]. É possı́vel escrever funções
próprias que serão utilizadas exatamente da mesma forma que as funções predefinidas com
uma sintaxe simples como mostra o Exemplo 2.3.3.
Exemplo 2.3.3.
function my_function($arg1, $arg2, ..., $arg3)

{
statement1;
statement2;
..
return($value);
}
Funções definidas pelo usuário podem utilizar argumentos de qualquer tipo e também
podem retornar quaisquer tipos de valores. Os tipos de argumentos e o valor de re-
torno não precisam ser declarados. A ordem da definição e chamadas de funções não
faz nenhuma diferença, contanto que toda função chamada seja definida apenas uma vez.
Variáveis atribuı́das dentro de uma função são locais a essa função, a menos que especifi-
cadas com uma declaração global. O comportamento padrão para funções definidas pelo
usuário é “chamada por valor”, ou seja, funções trabalham com cópias de seus argumen-
tos e assim não podem modificar as variáveis originais na chamada de função. Caso seja
necessário forçar o comportamento de chamada por referência precede-se os parâmetros
com o caracter &, tanto no lado da definição como no lado da chamada[11].
2.3. PHP 15
Passando Informações entre Páginas

O protocolo HTTP, é do tipo “sem informações de estado” [11]. Isso significa que a própria
HTML não é capaz de trocar valores entre páginas de um site da web. O HTTP pode ser
utilizado para passar valores, mas um programa separado chamado handler deve intervir
para fazer ações com os valores passados. Talvez o PHP seja o mais fácil e mais natural
dos handlers de formulário. As informações são utilizadas através de um dos três métodos
principais: GET, POST ou um cookie. GET é utilizado, principalmente para construir com-
plexas strings de URL para utilizar com modelos em sites dinâmicos. GET é obsoleto
para utilização com formulários. POST é o método recomendado para formulários. Os
desenvolvedores tomaram uma decisão de projeto muito útil, mas ligeiramente arriscada
em PHP, ao projetar a passagem de dados entre formulários. A atribuição das variáveis
se dá de forma automática, mas invisı́vel, na nova página quando um conjunto de dados
é enviando utilizando GET ou POST. A maioria de seus competidores obriga a fazer essa
atribuição explicitamente em cada página. Portanto, o PHP é mais fácil, mais simples
menos sujeito a equı́vocos cometidos por programadores.
As afirmações feitas acima por Converse e Park [11] são verdadeiras se consideradas as
versões do PHP anteriores a 4.2.0. Nesta versão e nas posteriores, a atribuição automática
das variáveis enviadas por formulários estão desabilitadas [15].
Sessões
As sessões são úteis para monitorar o comportamento do usuário ao longo de interações que
duram mais que a execução de um script ou download de página. Se um resultado depende
de quais páginas o usuário passou ou interagiu, o código precisará armazenar ou propagar
essas informações em uma maneira que distingua um usuário de outro. Como já foi dito
anteriormente, o HTTP é do tipo sem informações de estado, isso requer algum tipo de
técnica para contornar o problema. Podem ser utilizadas variáveis ocultas que funcionam
como uma maneira de manter sessões diferentes e associar variáveis a essa sessão, ou
cookies que não são universalmente suportados pelos navegadores clientes. A primeira
etapa em um script que utiliza o recurso sessão é deixar o PHP saber que uma sessão
já pode estar em progresso, para que ele possa se conectar a ela e recuperar quaisquer
informações associadas. Isso é feito chamando a função session start(). Essa função
importa quaisquer variáveis do contexto de sessão para o script. Entretanto para exportar
para páginas posteriores utiliza-se a função session register(). Essa função coloca o
mecanismo de sessão em aviso de que a variável deve ser exportada para todas as sessões
e que páginas posteriores na mesma sessão devem receber a variável vinculada à esta. As
variáveis de sessão são registradas como superglobais. A função session unregister()
recebe um nome de variável de string como argumento e libera a variável correspondente
da sessão como demonstrado no Exemplo 2.3.4.
Exemplo 2.3.4.
<?
session_start();
session_register(’username’)
?>
<HTML>
<HEAD>
<TITLE>Teste de Sessao</TITLE>
2.4. POSTGRESQL 16
</HEAD>
<BODY>
<H3>Teste de sessao</H3>
ID de sua sessao:
<?
print(session_id());
?>
<BR>
<?
if (IsSet($posted_username))
$username = $posted_username;
if (IsSet($username))
{
print ("<P> Seu nome: \$username<BR>");
}
?>
<P>
<FORM METHOD="POST" ACTION="<? Echo \$PHP_SELF; ?>">
Nome: <INPUT TYPE="TEXT" NAME="posted_username"><BR>
<INPUT TYPE="SUBMIT" NAME="Enviar" Value="Lembre-me!">
</FORM>
</BODY>
</HTML>
2.4 PostgreSQL
Normalmente o banco de dados escolhido para ser usado em conjunto com PHP é o
popular MySQL. Porém para este trabalho optou-se por usar o PostgreSQL, um banco
de dados mais robusto e também de uso livre, o qual tem todas as funcionalidades de um
banco de dados comercial.
O PostgreSQL é um SGBDOR (sistema de gerenciamento de banco de dados objeto-
relacional) baseado na versão 4.2 do POSTGRES, que foi desenvolvido pelo Departamento
de Ciência da Computação da Universidade da Califórnia. Oferece suporte às linguagens
SQL92/SQL99 e outras funcionalidades que serão descritas adiante.
“Com mais de uma década de desenvolvimento por trás, o PostgreSQL

é o mais avançado banco de dados de código aberto disponı́vel em qualquer
lugar, oferecendo controle de concorrência multi-versão, suportando pratica-
mente todas as construções do SQL (incluindo subconsultas, transações, tipos
definidos pelo usuário e funções), e dispondo de um amplo conjunto de ligações
com linguagens procedurais (incluindo C, C++, Java, Perl, Tcl e Python)”
[12].
Porém antes de ser um SGBD (sistema de gerenciamento de banco de dados) desta

categoria, o PostgreSQL passou por muitas versões. A primeira versão do então POST-
GRES ficou operacional em 1987 e foi lançada em 1988. Várias versões foram liberadas
até que em 1994 foi adicionado um interpretador da linguagem SQL ao POSTGRES.
Surgiu então o Postgres95, como “descendente de código aberto do original POSTGRES
2.4. POSTGRESQL 17
de Berkeley” [12], que passou a ser comercializado pela Illustra Information Technologies
(empresa atualmente pertencente a IBM).
O nome Postgres95 já não era adequado quando o ano de 1996 se iniciou, então o nome
PostgreSQL foi escolhido “para refletir o relacionamento entre o POSTGRES original e
as versões mais recentes com funcionalidade SQL” [12]. Além disso algumas melhorias
foram incluidas nesta versão, principalmente com relação à funcionalidade e recursos.
Segundo The PostgreSQL Global Development Group [12], a simplicidade o modelo
relacional tornou a implementação de certas aplicações muito difı́cil. Porém recursos
adicionais incorporados ao PostgreSQl, fazem com que a extensão de sistemas seja mais
fácil. Tais recursos são: herança, tipos de dados, e funções. Restrições, gatilhos, regras e
integridade de transação dão flexibilidade e poder adicionais.
Além dos tradicionais tipos (inteiro, ponto flutuante, caracter, data/hora, etc) o Post-
greSQL tem outros tipo, dentre eles os quais:
Tipos geométricos: representam objetos no espaço bidimensional. O tipo “ponto”, que

é mais fundamental forma a base de todos os outros tipos.
Tipos de dado para endereço de rede: destinados a armazenas endereços IP e de

MAC. “É preferı́vel utilizar estes tipos em vez dos tipos de texto puro, porque
estes tipos possuem verificação de erro na entrada, além de vários operadores e
funções especializadas” [12].
Pseudotipos: utilizados para declarar tipos de argumentos e de resultados de funções.

São eles: record, any, anyarray, void, trigger, language handler, csstring,
internal e opaque.
“O PostgreSQL em sua arquitetura, utiliza o modelo cliente-servidor, ou

seja, uma de suas sessões contém dois processos cooperando entre si: Um
processo servidor, o qual gerencia os arquivos do banco de dados, aceita as
conexões dos aplicativos cliente como o banco de dados, e executa as ações no
banco de dados em nome dos clientes” [12].
O postmaster, que é o servidor de banco de dados multiusuário do PostgreSQL, fun-

ciona da seguinte maneira: o processo cliente, o chamado frontend, é o que executa
operações de banco de dados. Os aplicativos cliente podem ter naturezas muito diversas:
pode ser uma ferramenta no modo caracter, um aplicativo gráfico, um servidor web que
acessa o banco de dados para mostrar páginas da web, ou uma ferramenta especializada
para manutenção do banco de dados.
O servidor do PostgreSQL pode tratar conexões simultâneas dos clientes. Para esta
finalidade é iniciado um novo processo para cada conexão e, a partir daı́, o cliente e o novo
processo servidor passam a se comunicar sem a intervenção do processo original que
é o postmaster. “Portanto, o postmaster está sempre em execução aguardando por novas
conexões dos clientes, enquanto os processos servidores associados aos clientes surgem
e desaparecem” [12].
O PostgreSQL oferece as seguintes vantagens: independência de plataforma, velo-
cidade, confiabilidade, segurança, extensibilidade, escalabilidade, farta documentação,
exigências mı́nimas de administração, baixo custo total de propriedade (TCO) e adota o
padrão ANSI (American National Standards Institute). Também por isso, é considerado
um dos sistemas de banco de dados de código aberto mais avançados no mundo. Grandes
2.4. POSTGRESQL 18
corporações, instituições de governo, pequenas empresas de negócios on-line escolheram

este SGBD para controlar seus dados.
O PostgreSQL oferece suporte a quase todos os comandos da linguagem SQL Padrão,
incluindo subseleções, transações, tipos definidos pelo usuário e funções. Seu código fonte
está disponı́vel, além de binários pré-compilados em diversas plataformas e ainda permite
a criação de inúmeros bancos de dados em uma instalação. Os nomes dos bancos de dados
devem ter um primeiro caracter alfabético, estando limitados a um comprimento de 63
caracteres.
Uma escolha conveniente é criar o banco de dados com o nome do usuário corrente.
Muitas ferramentas assumem este nome de banco de dados como sendo o padrão, evi-
tando a necessidade de digitá-lo. Para criar este banco de dados, deve-se digitar sim-
plesmente $ createdb e para remover um banco, usa-se o seguinte comando: $ dropdb
<nome do banco de dados>. Para criar um banco de dados com um nome especı́fico,
deve-se usar o comando: $ createdb <nome do banco de dados>. Tal comando, deverá
produzir a resposta: CREATE DATABASE.
Os comandos usados para selecionar, inserir, atualizar e apagar dados nas tabelas
são respectivamente, select, insert, update e delete da linguagem SQL padrão. As
tabelas são coleções de linhas e colunas identificáveis por um nome. Cada coluna dessa
tabela tem um tipo especı́fico. A junção dessas tabelas constitui o banco de dados.
O Exemplo 2.4.1 demonstra a criação de uma tabela no PostgreSQL.
Exemplo 2.4.1.
CREATE TABLE localNasc ( cidade varchar(100), pais varchar(50) );

Usa-se o comando insert para povoar tabelas com linhas, como no Exemplo 2.4.2.
Exemplo 2.4.2.
INSERT INTO cidade VALUES (’Campo Grande’);

O comando select é usado para fazer consultas no banco de dados. O Exemplo 2.4.3
mostra como usar esse comando para consulta.
Exemplo 2.4.3.
SELECT * FROM cidade;

Ou para fazer consultas mais especı́ficas pode-se usar o comando, de acordo com o
Exemplo 2.4.4.
Exemplo 2.4.4.
SELECT * FROM cidade WHERE pais = ’Brasil’;

Pode-se ainda fazer junções entre as tabelas, ou seja, fazer o cruzamento dos dados
entre as tabelas para obter-se consultas com dados integrados. O Exemplo 2.4.5 mostra
como isto é feito.
Exemplo 2.4.5.
SELECT * FROM cidade INNER JOIN pais ON (cidade.pais = pais.nome);

2.4. POSTGRESQL 19
Para fazer atualização nos registros da tabela, usa-se o comando update, como mos-
trado no Exemplo 2.4.6.
Exemplo 2.4.6.
UPDATE pessoa SET nome_pessoa = ’$nome_pessoa’, sobr_pessoa = ’$sobr_pessoa’,

WHERE id_pessoa = ".$id_pessoa;
Finalmente, para fazer exclusão de linhas da tabela o comando usado é o delete,

demonstrado no Exemplo 2.4.7.
Exemplo 2.4.7.
DELETE FROM pessoa WHERE id_pessoa = ".$id_pessoa;
Para ter acesso ao banco de dados gerenciado pelo PostgreSQL, executa-se o programa
de terminal interativo do PostgreSQL chamado psql, que permite a entrada, edição e
execução de comandos SQL interativos. Pode-se também utilizar uma ferramenta cliente
gráfica disponı́vel ou a ferramenta de um pacote de automação de escritórios com suporte
a ODBC para criar e manusear bancos de dados ou ainda usar aplicativos personalizados.
No caso do presente trabalho foi usada a última opção, utilizando-se a linguagem script
PHP no desenvolvimento da aplicação web. A conexão com o banco de dados é feita
através da função pg connect(), reconhecida pelo PHP. O Exemplo 2.4.8 mostra como
isso é feito.
Exemplo 2.4.8.
<?
pg_connect("host=xxx.xxx.xxx.xxx dbname=<nome_do_bd>
user=<usuario> password=senha")
?>
O PostgreSQL possui ainda funcionalidades avançadas para o melhor funcionamento

do banco de dados. Algumas dessas funcionalidades são: visões, chaves estrangeiras,
transações e heranças. Estes recursos garantem a integridade dos dados além de facilitar
na manutenção do banco.
Embora o PostgreSQL tenha todos estas funcionalidades, ele ainda não permite que
um campo inteiro tenha o recurso do auto-incremento. Quando existe a necessidade de
uso deste recurso deve-se criar uma “seqüencia” e usá-la na tabela. O Exemplo 2.4.9
mostra como uma seqüencia é criada, e o Exemplo 2.4.10, como uma seqüência é usada
em uma tabela.
Exemplo 2.4.9.
CREATE SEQUENCE public.id_pais

INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 14
CACHE 1;
2.5. GEDCOM 20
Exemplo 2.4.10.
CREATE TABLE public.pais (

pais_id int4 NOT NULL DEFAULT nextval(’id_pais’::text),
pais_nome varchar(30) NOT NULL,
CONSTRAINT pais_pkey PRIMARY KEY (pais_id)
) WITH OIDS;
2.5 Gedcom
O Gedcom (GEnealogical Data COMunicator ) é um formato de arquivo para troca de
informações genealógicas. Ele foi desenvolvido pelo Departamento de História da Famı́lia
e da Igreja de A Igreja de Jesus Cristo dos Santos dos Últimos Dias. A última versão do
arquivo, que é a 5.5.1, foi distribuı́da em 2 de outubro de 1999 e é a versão que a maioria
dos softwares genealógicos lê e escreve.
O propósito do Gedcom “é promover o compartilhamento de informações genealógicas
e o desenvolvimento em larga escala de software inter-operáveis para ajudar a genealogis-
tas, historiadores, e a outros investigadores” [16]. Tanto é verdade que, entre dezenas de
softwares destinados ao gerenciamento de árvores genealógicas, a grande maioria exporta
informações para e importa informações contidas em arquivos Gedcom, além de ter seu
próprio formato de arquivo.
Este formato de arquivo foi criado para troca de informações genealógicas, entretanto
ele pode ser usado para outros fins. Considere-se a informação do Exemplo 2.5.1.
Exemplo 2.5.1.
Jose Antonio Pereira, 19 de marco de 1825, Monte Alegre, MG.
O dado acima pode ser referente a uma pessoa de nome José Antônio Pereira e sua
data e local de nascimento ou qualquer outro evento que tenha acontecido na vida deste
indivı́duo. A informação pode se referir também a um livro de tı́tulo “José Antônio
Pereira” e sua data e local de publicação.
A tarefa do Gedcom é adicionar semântica às informações. Através de nı́veis e marcas
os dados da sentença acima ganham significado. A sentença ficaria como no Exemplo
2.5.2
Exemplo 2.5.2.
0 INDI
1 NAME Jose Antonio Pereira
1 BIRT
2 DATE 19 de marco de 1825
2 PLACE Monte Alegre, MG
O código acima não é um Gedcom válido, entretanto é desta maneira que as in-
formações, marcações e nı́veis ficam dispostos no arquivo. Pelo trecho de código acima,
pode-se perceber que o conteúdo de um arquivo Gedcom nada mais é que um banco de
dados em forma seqüencial de um conjunto de registros. Estes registros são representados
através de uma seqüência de linhas hierarquicamente dispostas, seguindo um padrão de
marcação.
2.5. GEDCOM 21
Cada linha contém um número hierárquico do nı́vel (0, 1, 2, ...), uma marca (INDI,
NAME, BIRT, ...) e um valor opcional (José Antônio Pereira, 19 de março de 1825,
...). Uma linha pode ter também um identificador de referência cruzada e um apontador.
Levando-se em consideração o contexto hierárquico, a marcação de uma linha identifica a
informação nela contida, da mesma forma que o nome de um campo identifica um campo
em um banco de dados.
O código do Exemplo 2.5.3 é um Gedcom válido.
Exemplo 2.5.3.
1 0 @I321@ INDI
2 1 NAME Jose Antonio /Pereira/
3 1 SEX M
4 1 BIRT
5 2 DATE 19/03/1825
6 2 PLAC Monte Alegre, Minas Gerais, Brasil
7 1 DEAT
8 2 DATE 11/01/1900
9 2 PLAC Campo Grande, Mato Grosso do Sul, Brasil
O código foi indentado para uma melhor visualização e entendimento da estrutura
do arquivo. A linha 1 traz o nı́vel hierárquico 0, onde @I321@ é o identificador de um
indivı́duo, INDI. O próximo nı́vel, 1, na linha 2, traz a marca NAME com o valor José
Antônio /Pereira/. O sobrenome vem separado por barras (/). Na linha 3 há outra
linha com nı́vel 1, que informa o sexo do indivı́duo em questão. Nas linhas 4, 5 e 6 são
apresentadas as informações do nascimento. As linhas 5 e 6 tem o nı́vel hierárquico 2, o
que quer dizer que as informações nela contidas dizem respeito à linha de nı́vel hierárquico
1 imediatamente anterior a elas. As linhas 7, 8 e 9 mostram as informações de óbito do
indivı́duo em questão.
Algumas adições foram feitas ao código do exemplo 2.5.3, resultando no código do
exemplo 2.5.4, para mostrar outras marcações e alguns relacionamentos. Nesta segunda
versão do código, o indivı́duo de identificador @I321@ recebeu outra informação, que está
na linha 10. A marca FAMS significa que o indivı́duo participa da famı́lia de identificador
@F56@ como esposo (FAMS = Family Spouse).
Exemplo 2.5.4.
1 0 @I321@ INDI
2 1 NAME Jose Antonio /Pereira/
3 1 SEX M
4 1 BIRT
5 2 DATE 19/03/1825
6 2 PLAC Barbacena, Minas Gerais, Brasil
7 1 DEAT
8 2 DATE 11/01/1900
10 1 FAMS @F56@
11 0 @I322@ INDI
12 1 NAME Maria Carolina de /Oliveira/
13 1 SEX F
2.6. GENTECH GENEALOGICAL DATA MODEL 22
14 1 BIRT
15 2 DATE After 1825
16 2 PLAC Minas Gerais, Brasil
17 1 DEAT
19 1 FAMS @F56@
20 0 @I323@ INDI
21 1 NAME Antonio Luiz /Pereira/
22 1 SEX M
23 1 BIRT
24 2 DATE About 1845
25 2 PLAC Minas Gerais, Brasil
26 1 FAMC @F56@
27 0 @F56@ FAM
28 1 HUSB @I321@
29 1 WIFE @I322@
30 1 CHIL @I323@
31 1 MARR
32 2 PLAC Sao Joao Del-Rey, Minas Gerais, Brasil
A partir da linha 11 até a linha 25 são mostradas as informações de 2 novos indivı́duos.

O indivı́duo @I322@ também recebeu, como o @I321@, na linha 19 a marcação FAMS
contendo uma referência cruzada para @F56@, significando que este também participa da
famı́lia de identificador @F56@ como cônjuge.
Já o indivı́duo @I323@ recebeu na linha 26 a marcação FAMC e a referência cruzada
para a famı́lia @F56@. Isso significa que tal indivı́duo participa desta famı́lia como filho
(FAMC = Family Child).
A partir da linha 27, a famı́lia de identificador @F56@ é descrita. Os indivı́duos de
identificadores @I321@ e @I322@ são os cônjuges da famı́lia e o filho é o indivı́duo de
identificador @I323@. Nas linhas 31 e 32 há informações sobre o casamento.
A flexibilidade do Gedcom é demonstrada através da não obrigatoriedade das
marcações. No código apresentado acima há dois exemplos. Na linha 17 DEAT não tem
um campo DATE relacionado a ele, assim como na linha 31 não há informação da data
para a marcação MARR. Além disso, são aceitas informações imprecisas, tais como “After
1825” na linha 15 e “About 1845” na linha 24.
Há ainda inúmeras outras marcações padrões do Gedcom (referentes a outros eventos
que não nascimento, casamento e óbito) que não serão citadas aqui por não se fazer
necessário para o entendimento do arquivo e também por não entrarem no escopo do
trabalho desenvolvido, como será explicado adiante no capı́tulo 3.
2.6 Gentech Genealogical Data Model

2.6.1 O Modelo de Dados
Fundamentos Iniciais
O modelo de dados empregado neste trabalho foi inspirado no Gentech Genealogical Data
Model — Modelo de Dados Genealógico da Gentech (GDM). A Gentech é uma subdivisão
da National Genealogical Society — Sociedade Genealógica Nacional que, por sua vez,
é uma organização sem fins lucrativos fundada em 1903. Enquanto a missão da NGS
situa-se somente no âmbito da genealogia, o objetivo da Gentech é conectar genealogia e
tecnologia.
Além de organizar conferências anuais, a Gentech desenvolve projetos, dos quais um
deles é o GDM. A versão 1.1 foi distribuı́da em 29 de maio de 2000. Os membros do grupo
que desenvolveram o modelo de dados concluı́ram que “é difı́cil definir dados genealógicos
fora de um contexto por causa das várias maneiras que as pessoas interpretam os termos
genealógicos”. Partindo deste pensamento, o grupo decidiu construir o modelo de dados
dentro do contexto de um modelo de dados lógico.
“É importante perceber que nós criamos um modelo de dados lógico e

não um modelo de dados fı́sico. O modelo lógico descreve os relacionamen-
tos dos dados genealógicos, mas quando o modelo é implementado por um
desenvolvedor, ele pode metodologicamente escolher alterar o modelo usando
determinadas mudanças para criar o modelo de dados fı́sico” [17].
O grupo de trabalho da Gentech idealizou um conceito central para o modelo de

dados. Este conceito consiste em que “toda informação genealógica pode ser quebrada
em uma série de pequenas sentenças genealógicas formais”. Com esta idéia em mente,
foram classificados 3 tipos de sentenças: sobre relacionamentos, sobre eventos e sobre
caracterı́sticas.
Para entender melhor as sentenças, deve-se entender também os termos utilizados no
modelo. Place (lugar) refere-se ao nome de um lugar ou faz ligação à entidade. Date
range (intervalo de data) refere-se à data e permite datas não especı́ficas, ou seja, datas
com “aproximadamente” e “antes” ou “depois” também são consideradas datas. Events
(eventos) são quaisquer acontecimentos que podem ter ocorrido na vida de alguém, tais
como nascimento, morte, casamento, batismo, formatura, etc. O termo relationship
(relacionamento) representa a informação do relacionamento entre duas pessoas. E, final-
mente, characteristic (caracterı́stica) descreve uma pessoa.
Nas sentenças abaixo, P1 quer dizer Pessoa Número 1 e P2, Pessoa Número 2.
P1/Relationship/P2/Date Range/Place (relacionamento)

Ex.: 321 / e pai de / 323 / em aprox. 1845 / Sao Joao Del Rey, MG
P1/Event/P2/Date Range/Place (evento)

Ex.: 321 / casado / 322 / antes de 1845 / Sao Joao Del Rey, MG
P1/Characteristic/Date Range Place (caracteristica)

Ex.: 321 / fundador de Campo Grande / 26/08/1899 / Campo Grande, MS
O modelo de dados está dividido em 3 sub-modelos: Sub-modelo de Administração,

Sub-modelo de Evidências e Sub-modelo de Conclusões.
Sub-modelo de Administração
Como o modelo de dados sugerido pela Gentech propõe uma modelagem sofisticada e
detalhista, prevendo que os genealogistas tenham projetos de pesquisa, este sub-modelo
refere-se às entidades primariamente usadas para manter-se a par do projeto. O diagrama
mostrando parte do sub-modelo de administração está na figura 2.1.
Figura 2.1: Parte do Sub-modelo de Administração [17].
A entidade RESEARCHER permite que dados genealógicos sejam conectados à pes-

soa que recolheu tal dado, ou seja, qualquer informação será atribuı́da a um pesquisador.
A entidade PROJECT identifica um ou mais projetos no qual um pesquisador está inte-
ressado ou trabalhando. Cada PROJECT está associado a um SURETY-SCHEME que
expressa quão certo está o pesquisador da informação conseguida. PROJECT é ainda
associado com zero ou muitos RESEARCH-OBJECTIVEs como pode-se ver no diagrama
da figura 2.2.
Os pesquisadores podem especificar seus objetivos em RESEARCH-OBJECTIVE, ou
seja, a informação contida nesta entidade explica qual problema o genealogista está ten-
tando resolver. RESEARCH-OBJECTIVEs são conectados a especı́ficas ACTIVITYs,
que podem ser do tipo SEARCH ou ADMINISTRATIVE-TASK. A entidade SEARCH
“ocorre em um repositório particular, em uma data, usando uma SOURCE e consiste
em examinar a SOURCE por um ou mais nomes em particular, um ou mais lugares em
particular ou outra informação” [17]. Há ainda 2 entidades neste sub-modelo que dão su-
porte à entidade SOURCE no Sub-modelo de Evidências. As duas entidades constantes
na figura 2.3 permitem que SOURCEs sejam agrupadas da maneira que o pesquisador
deseje fazer.
Sub-modelo de Evidências
Este sub-modelo é destinado às informações evidenciais dentro do universo dos dados
genealógicos. Para isso o modelo possui entidades, presentes no diagrama da figura 2.4,
que completam as informações que são representadas pelas entidades do Sub-modelo de
Conclusões discutido a seguir na subseção 2.6.1.
Como mostra o diagrama da figura 2.4, a entidade SEARCH, do Sub-modelo de Admi-
nistração, está conectado ao Sub-modelo de Evidências através da ligação com a entidade

REPOSITORY-SOURCE. A entidade REPOSITORY contém as informações que identifi-
cam o repositório. A entidade associativa REPOSITORY-SOURCE está presente porque
um REPOSITORY pode ter muitas SOURCEs, assim como uma SOURCE pode ser en-
contrada em um ou mais REPOSITORYs. SOURCE possui ainda uma auto-referência,
o que quer dizer que pode haver vários nı́veis de fontes.
Ainda no Sub-modelo de Administração há a entidade SOURCE-GROUP que permite
diferentes tipos de registros serem agrupados, para que possam ser pesquisados por deter-
minados tipos de fontes. A citação associada com cada nı́vel de SOURCE é armazenada
em CITATION-PART e a entidade CITATION-PART-TYPE é o tipo de citação que tal
informação representa. Tais entidades estão presentes no diagrama da figura 2.5.
REPRESENTATION é onde o conteúdo da citação está armazenado. Como a entidade
REPRESENTATION pode ter vários tipos de conteúdo, inclusive multimı́dia, existe a
entidade REPRESENTATION-TYPE, que descreve o tipo de cada REPRESENTATION.
Figura 2.4: Parte do Sub-modelo de Evidências [17].
Figura 2.5: Parte do Sub-modelo de Evidências [17].
Sub-modelo de Conclusões
O Sub-modelo de Conclusões é o coração do modelo de dados da Gentech.
“Uma vez que um pedaço de evidência foi isolado para o nı́vel atômico
de uma simples extração de SOURCE, o RESEARCHER então usa aquela
sentença para fazer uma ASSERTION. Perceba que a extração atual está
armazenada em REPRESENTATION, mas está disponı́vel para a entidade
ASSERTION através de um registro SOURCE, (...)” [17].
A entidade ASSERTION é uma informação genealógica, uma sentença, como discutida

anteriormente. Uma instância de ASSERTION, ou seja, uma afirmação pode ser criada de
duas maneiras, convertendo-se um fragmento de SOURCE em uma ASSERTION ou fa-
zendo uma ASSERTION baseada em uma ou mais ASSERTIONs existentes. O diagrama
da figura 2.6 mostra a entidade ASSERTION e a entidade ASSERTION-ASSERTION
onde pode ser entendida a afirmação anterior.
Figura 2.6: Parte do Sub-modelo de Conclusões [17].
Agora é necessário entender como todas as sentenças genealógicas são capturadas por
ASSERTION. Tais sentenças são fragmentadas em tipos de assuntos que são as entidades
PERSONA, EVENT, GROUP e CHARACTERISTIC. Cada ASSERTION contem uma
sentença, como descrito abaixo. Na sentença, ID aponta para uma ocorrência daquele
tipo.
Subject1-Type / Subject1-ID / Subject2-Type / Subject2-ID / Value
PERSONA pode estar conectada a outra entidade PERSONA (um relacionamento),

à entidade EVENT (qualquer evento ocorrido na vida de uma pessoa, por exemplo, nas-
cimento), à entidade GROUP (sendo um membro de um grupo) ou à entidade CHARAC-
TERISTIC (representando uma caracterı́stica de uma pessoa). Para entender-se melhor,
as sentenças estão exemplificadas abaixo:
PERSONA/321 (Jose Antonio Pereira)/PERSONA/322 (Maria Carolina de Oliveira)/Marido

PERSONA/321 (Jose Antonio Pereira)/EVENT/413 (casamento)/Noivo
PERSONA/321 (Jose Antonio Pereira)/GROUP/518 (caravana)/Lider
PERSONA/321 (Jose Antonio Pereira)/CHARACTERISTIC/572 (Cor dos cabelos)/Castanho
Cada uma das entidades PERSONA, EVENT, GROUP e CHARACTERISTIC estão

interligadas através da entidade ASSERTION, como mostra o diagrama da figura 2.7.
Finalmente as entidades PLACE, PLACE-PART e PLACE-PART-TYPE, constantes
no diagrama da figura 2.8 são as que tratam dos lugares e estão conectadas através de todo
o modelo. Enquanto PLACE se refere a um local como “Campo Grande, Mato Grosso do
Sul, Brasil”, cada uma dessas partes são armazenadas em PLACE-PART. PLACE-PART-
TYPE diz se determinada PLACE-PART é uma “cidade”, “estado”, “paı́s”, “bairro”, etc.
2.7. CONSIDERAÇÕES FINAIS 29
2.6.2 Considerações sobre o Modelo

O modelo de dados é realmente detalhista, mas necessário. Genealogistas profissionais
precisam de uma ferramenta de tal sofisticação, embora este seja somente um modelo e
não haja informação sobre alguma aplicação que utiliza parte ou a totalidade deste.
O grupo de trabalho denominado Lexicon Group, reuniu-se pela primeira vez em 1996
e para seus integrantes “tornou-se aparente que, mesmo que o grupo não estivesse criando
um modelo de dados como parte da especificação para uma aplicação genealógica real a ser
construı́da, certas partes do modelo não poderiam ser criadas sem alguns entendimentos
de como os dados podiam na verdade ser usados em uma aplicação real”[17].
Com a finalização do modelo, a frase que melhor caracterizou o processo foi articulada
na última reunião em Silver Spring: “Agora que eu olho para o modelo, eu não gosto
dele” [17]. O grupo continuou o trabalho, revisando o modelo e testando novas idéias.
“O resultado foi frustrante nos momentos em que trabalhos antigos eram

reabertos, mas o resultado era para continuamente refinar o modelo, tornando
mais geral, mais poderoso e, infelizmente um tanto mais abstrato que o con-
ceito original” [17].
Porém o sentimento que os integrantes do Lexicon Group nutrem pelo modelo por eles
criado não fez com que ele fosse um fracasso. O GDM é citado em dezenas de artigos e
trabalhos apresentados em eventos de genealogia. Pode-se dizer que talvez eles tenham
sido muito crı́ticos consigo mesmos.
Foi encontrada somente a versão 1.0 do diagrama completo da Gentech, o qual está
presente no Apêndice B à página 50.
2.7 Considerações Finais

Neste capı́tulo foram apresentados as tecnologias e recursos empregados no desenvolvi-
mento da aplicação web: a linguagem de modelagem UML, a linguagem script PHP, o
banco de dados PostGreSQL, o formato de arquivo Gedcom e o modelo de dados ge-

nealógico da Gentech.
A UML é uma linguagem poderosa para modelagem orientada a objetos de sistemas.
Neste trabalho ela foi usada para a modelagem navegacional somente, pois a aplicação
não foi desenvolvida com programação orientada a objetos. Os diagramas da UML são
fundamentais para uma boa implementação.
PHP (acrônimo recursivo para PHP: Hipertext Preprocessor ) é uma linguagem script
popular entre desenvolvedores de aplicações web. É fácil de usar, de uso livre e é com-
patı́vel com a maioria dos servidores. É uma linguagem embutida, ou seja, é escrita entre
a HTML. Suas funcionalidades são semelhantes à linguagem C. Possui conexão nativa
com a maioria dos banco de dados comerciais.
O banco de dados PostgreSQL, usado para armazenar as informações da aplicação, não
é tão popular quanto ao MySQL, mas tem seu valor. Mesmo sendo de código-fonte aberto,
pode ser comparado, sem ficar em desvantagens, aos seus concorrentes comercializados.
Ele é considerado um SGBDOR (Sistema de Gerenciamento de Banco de Dados Objeto-
Relacional) por ter funcionalidades como herança e tipos que podem ser definidos pelo
usuário. Possui suporte às linguagens SQL92/99.
Um meio de fomentar a utilização da aplicação web é fazer a importação e exportação
dos dados contidos no site através de arquivos Gedcom. Este formato é amplamente
conhecido entre genealogistas, já que a grande maioria dos softwares genealógicos reco-
nhece este arquivo. O Gedcom adiciona semântica às informações através de marcações
e numeração de nı́veis hierárquicos.
A modelagem de dados feita para a aplicação web foi inspirada no Gentech Genealo-
gical Data Model. Esta modelagem é ampla e detalhista, o que não se faz necessário para
este trabalho. Algumas entidades do modelo de dados da Gentech foram adequadas para
o uso na aplicação. Uma resumida explanação do modelo foi feita.
Capı́tulo 3
A Aplicação
3.1 Introdução
Ainda tendo em mente as tecnologias e recursos citados no capı́tulo 2, são demonstradas,
neste capı́tulo, as decisões que levaram a tais escolhas e algumas particularidades da
aplicação desenvolvida, disponı́vel para acesso através da URL www.radici.com.br. A
aplicação usa a arquitetura cliente/servidor, discutida na seção 3.2.
A seção 3.3 explica o motivo da escolha da linguagem script PHP. Discorre ligeiramente
sobre o por quê de não haver sido utilizada a linguagem Java. É comentada também a
decisão pelo PostgreSQL e não pelo MySQL. Como a razão pela escolha de um pelo outro
é muito forte e ao mesmo tempo simples, isso foi tratado rapidamente.
A utilização dos recursos são abordadas na seção 3.4. É explicado o que foi usado
do modelo da Gentech e apresenta o modelo de dados desenvolvido para a aplicação
web. O uso do Gedcom na ferramenta desenvolvida é abordado somente fazendo-se uma
explicação de quais marcações do Gedcom serão reconhecidas pela aplicação.
A navegabilidade da aplicação web está definida na seção 3.5, onde é mostrado um
modelo navegacional que utiliza uma extensão do diagrama de classes da UML, no qual
são determinadas e explicadas a ligação entre as páginas e a função de cada uma delas.
A seção 3.6 discorre sobre as particularidades do sistema, ou seja, rotinas que não
são comuns à maioria dos sı́tios existentes. O script que extrai a Descendência de um
indivı́duo é feito através de uma pequena função recursiva. O retorno da Ascendência,
dado determinado indivı́duo, também é feito através de uma função recursiva, esta utiliza
conceito de árvore binária. A tarefa para importar um arquivo Gedcom não é simples e
é feita através de muitas funções. O reconhecimento das marcações e nı́veis hierárquicos
precisa ser feito, para então, extrair-se os dados. A exportação dos dados para Gedcom é
simples. As informações colhidas do banco de dados são impressas na página já mescladas
com as marcações e nı́veis através da função PHP echo().
3.2 Arquitetura
Para a aplicação web desenvolvida foi adotada uma arquitetura bastante usual: a cli-
ente/servidor [18]. No caso especı́fico da aplicação web, a camada de negócios e o banco
de dados estão localizados no lado servidor e a porção cliente é a interface visualizada
através do navegador. O cliente solicita serviços ao servidor, que atende ao pedido. A
figura 3.1 demonstra o processo.
31
3.3. DECISÕES 32
Figura 3.1: Arquitetura cliente/servidor.
A arquitetura cliente/servidor oferece vantagens sobre as tradicionais redes centra-

lizadas, pois as tarefas podem ser divididas entre a porção cliente e a porção servidor.
Normalmente as informações são processadas no servidor e os resultados são enviados ao
cliente. O cliente é responsável pela apresentação da informação através da interface [18].
3.3 Decisões
3.3.1 Linguagem
No inı́cio dos trabalhos de desenvolvimento e implementação da aplicação web havia mui-
tas possibilidades de tecnologias e recursos a serem usados. No que tange a linguagens de
programação para web, indiscutivelmente Java seria a opção mais elegante a ser usada,
onde seriam utilizados os conceitos de orientação a objetos e persistência de objetos apren-
didos durante o curso de especialiação de Engenharia de Websites.
Porém não foram detectadas necessidades da utilização dos recursos de tal linguagem.
Foi concluı́do que as funcionalidades poderiam ser implementadas utilizando-se de uma
linguagem mais fácil e, portanto, despenderia menor tempo de desenvolvimento.
Foi decidido, portanto, que a linguagem script PHP seria usada por causa de sua
portabilidade, por também ser de código-fonte aberto e muitas outras caracterı́sticas,
as quais foram abordadas na seção 2.3 do capı́tulo 2 à página 11. PHP também foi
uma linguagem aprendida durante o curso. Outro motivo relevante é que, devido sua
popularidade, há mais opções de servidores para hospedagem.
3.3.2 Banco de Dados

Normalmente quando se usa PHP como linguagem para uma aplicação web, o banco de
dados escolhido é o gratuito e popular MySQL. Porém, neste trabalho foi decidido usar o
PostgreSQL que, além de ser também de uso livre, este é realmente um SGBD. O MySQL
é somente um gerenciador de tabelas e não possui recursos de integridade referencial,
visões, procedimentos e outras funcionalidades importantes que um SGBD deve possuir.
O PostgreSQL é um SGBD robusto que oferece suporte às linguagens SQL92/SQL99
entre outras particularidades que foram demonstradas na seção 2.4, na página 16, do
capı́tulo 2.
3.4. USO DOS RECURSOS 33
3.4 Uso dos Recursos

3.4.1 Modelos de Dados
A primeira tarefa no desenvolvimento da aplicação foi a modelagem de dados que foi
inspirada no Gentech Genealogical Data Model (GDM), apresentado na seção 2.6 do
capı́tulo 2. Foi decidido não usar a totalidade do GDM por ele ser complexo e não haver
a necessidade do uso de todas as entidades sugeridas pela Gentech no sı́tio, pelo menos
para o uso inicial do mesmo. Acredita-se que a maioria dos usuários da aplicação sejam
os genealogistas amadores ou iniciantes que desejam somente criar e divulgar a árvore
genealógica de sua famı́lia. Entretanto, a aplicação também funcionará satisfatoriamente
para genealogistas avançados.
Para o modelo de dados da aplicação, mantiveram-se algumas entidades originais do
GDM e algumas foram adicionadas. Entretanto, mesmo as entidades usadas do GDM
tiveram seus atributos modificados, pois foi feita uma adequação para o contexto da
aplicação que está sendo proposta. O diagrama 3.2 demonstra isso.
Inicialmente há uma entidade chamada CADASTRO, que é algo próximo ao RESE-
ARCHER do GDM. Em CADASTRO ficam armazenadas as informações dos usuários
da aplicação. As entidades UF e PAÍS foram criadas para manter-se uma integridade de
dados, elas contém, respectivamente, os estados ou provı́ncias e os paı́ses.
PESSOA é a entidade que representa um indivı́duo no banco de dados. Possui duas
auto-referências que significam que PESSOA é pai de outra PESSOA e o mesmo com mãe.
Cada PESSOA terá pelo menos um EVENTO que é seu nascimento. Mesmo que não haja
alguma informação sobre este evento, ele irá existir pois indiscutivelmente um indivı́duo
que existe teve um nascimento. EVENTO pode ter vários tipos (TIPOEVENTO), alguns
deles são: casamento, óbito, batismo, ou qualquer outro evento que algum usuário queira
registrar.
A entidade associativa PESSOA EVENTO existe porque em alguns casos um EVENTO
especı́fico poderá pertencer a mais de uma pessoa. Um tipo de evento que sempre será
assim é o casamento, ele pertence a duas pessoas. Um EVENTO pode ter uma FONTE. A
entidade FONTE é uma simplificação de SOURCE no modelo da Gentech e ela pertence
a um CADASTRO de usuário do sı́tio.
Enfim, um EVENTO terá armazenado ou o identificador de PAÍS ou o identificador
de UF. Uma vez que o UF é conhecido, tem-se o PAÍS. Para os casos em que somente o
paı́s é conhecido, então sim, o identificador da entidade PAÍS será guardada.
3.4.2 O Uso do Gedcom

O formato Gedcom prevê a entrada de dados para inúmeros tipos informações. Ou seja,
há varias marcações reconhecidas, dentre as quais são marcações que definem eventos,
caracterı́sticas, fontes de informação, entre outros. Alguns exemplos são as marcações
BATM, ENDW, BURI que se referem a eventos ou (NICK) que refere-se ao apelido de um
indivı́duo.
Porém, para a aplicação web desenvolvida, foram considerados somente os dados fun-
damentais do indivı́duo (nome, sobrenome e sexo) e as informações de datas e locais dos
eventos que levam as marcações BIRT (nascimento), DEAT (óbito) e MARR (casamento),
tanto na importação como na exportação dos dados.
3.5. MODELO NAVEGACIONAL 34
Figura 3.2: Modelo de dados desenvolvido para a aplicação.
3.5 Modelo Navegacional

A navegabilidade da aplicação foi detalhada utilizando-se uma extensão para aplicações
web do diagrama de classes da UML. O diagrama da figura 3.3 mostra a fase inicial
da navegação, onde a entrada se dá através de HTMLHome, onde o usuário possui três
opções, fazer o cadastro (FormCadastro), abrir uma sessão de login para entrar na sua
área reservada (FormLogin) ou efetuar uma pesquisa (FormPesquisa) que será submetida
para HTMLResultado.
Tendo escolhido cadastrar-se, o usuário preencherá o formulário de cadastro e tão logo
tenha efetuado tal operação com sucesso, uma sessão de login será criada automaticamente
e será redirecionado para a área reservada (HTMLHomeRestrita). Se o usuário já estiver
Figura 3.3: Modelo navegacional da aplicação — parte 1.
cadastrado, ele poderá fazer o login. Se esta operação for sucedida, será redirecionado
para a já mencionada área reservada da aplicação.
Se o usuário desejar fazer uma pesquisa, preencherá o campo do formulário de pes-
quisa com um nome e/ou um sobrenome (a pesquisa pode ser feita através de qualquer
página da aplicação, porém, por motivos de clareza, este relacionamento não foi colo-
cado nos diagramas). O diagrama da figura 3.4 esclarece navegação a partir da pesquisa.
HTMLResultado mostrará uma relação de nomes se a busca retornar algum resultado.
Associadas a cada nome da relação há três opções a serem escolhidas:
• Relatório (HTMLRelatório): mostra informações do indivı́duo, pais, cônjuge e fi-

lhos;
• Ascendência (HTMLAscend^ encia): mostra quatro gerações de ancestrais, a pri-

meira delas sendo o próprio indivı́duo;
• Descendência (HTMLDescend^ encia): gera uma listagem de todos as pessoas ge-

radas pelo(s) casamento(s) do indivı́duo com seu(s) cônjuge(s) e casamento(s) de
seu(s) filho(s) sucessivamente.

HTMLRelatório possui ligação para a Ascendência e a Descendência do indivı́duo

escolhido. Possui ligação também para o relatório dos outros indivı́duos mostrados em tal
página. Há também o relacionamento com PHPCriaGedcom para obter o arquivo Gedcom
com as informações constantes no relatório.
Na área reservada (HTMLHomeRestrita), o usuário cadastrado tem acesso às ferra-
mentas de gerenciamento de sua árvore genealógica, podendo inserir, selecionar, alterar
e remover indivı́duos, casamentos, óbitos, outros tipos de eventos, fontes, carregar seu
arquivo Gedcom, alterar suas informações de cadastro e encerrar sua sessão de login. O
diagrama da figura 3.5 exemplifica a navegação pelas ferramentas.
O diagrama 3.5 mostra a ligação somente com a parte de gerenciamento de indivı́duos

(FormGerIndivı́duo). Através do preenchimento do formulário, pode-se fazer a inserção
dos dados pessoais e de nascimento de um indivı́duo. Estes dados serão submetidos para
a porção PHP da ferramenta em questão, denominada PHPGerIndivı́duo.
FormGerIndivı́duo tem a opção de submeter um parâmetro para FormListaIndivı́duo,
este parâmetro pode ser uma cadeia de caracteres do nome e/ou sobrenome de algum in-
divı́duo já incluı́do no banco de dados ao qual se deseja fazer alguma alteração em seus da-
dos ou removê-lo. FormListaIndivı́duo devolve para FormGerIndivı́duo as informações
necessárias para que os dados de tal indivı́duo sejam retornados para a interface.
Da mesma forma que FormGerIndivı́duo tem uma ligação com FormInserePaı́s (onde
podem ser inseridos Paı́ses não constantes no banco de dados), possui também ligação para
uma ferramenta, que não foi demonstrada no diagrama, destinada a inserir novos Estados
ou Provı́ncias. As outras áreas de gerenciamento citadas acima funcionam similarmente
à parte denominada FormGerIndivı́duo e não estão exemplificadas no diagrama.
Em sua área restrita, o usuário pode carregar um arquivo Gedcom para guardar as
informações constantes em tal arquivo para a base de dados da aplicação. O arquivo é
submetido através de FormCarregaGedcom para PHPCarregaGedcom, onde as informações
do arquivo serão extraı́das e armazenadas no banco de dados.
Finalmente, o usuário poderá desconectar-se da aplicação, findando sua sessão de login,
através de PHPLogout. Isto irá redirecioná-lo para a entrada da aplicação (HTMLHome).
3.6. PARTICULARIDADES DA APLICAÇÃO 37
3.6 Particularidades da Aplicação

3.6.1 Descendência
As rotinas de inserção, alteração, remoção, pesquisa e relação de resultados são simples e
não é relevante citá-las aqui. Uma das particularidades da aplicação web desenvolvida é
o script que relaciona a Descendência a partir de um determinado indivı́duo. Para isso,
foi desenvolvida uma função recursiva.
A função que retorna a Descendência é simples. Traz o nome de um indivı́duo, seu
cônjuge (ou seus cônjuges se for o caso), seus filhos, cônjuges dos filhos e seus filhos
assim por diante. A função recebe dois parâmetros, o identificador da pessoa que inicia a
listagem de descendência e o número que ela recebe.
1 function Desc($id, $n)

2 {
3 // inicializacao das variaveis
4 $filho = 0;
5
6 // mostra o nome da pessoa
7 echo "<ol class=lista><li><b></b>".$n.". ".PegaNome($id);
8
9 // PegaIdConjuge traz o(s) conjuge(s) da pessoa
10 $array_Conjuge = PegaIdConjuge($id, PegaIdCasamento($id));
11 for( $i = 0; $i < count($array_Conjuge); $i++ )
12 {
13 if( $array_Conjuge[$i] != 0 )
14 {
15 echo "<ol class=lista><li> <b>CC.</b>
16 ".PegaNome($array_Conjuge[$i])."</li></ol>";
17 // PegaFilho traz os filhos da pessoa com o conjuge
18 $array_Filhos = PegaFilho($id, $array_Conjuge[$i]);
19 for( $j = 0; $j < count($array_Filhos); $j++ )
20 {
21 $filho = $filho + 1;
22 $numero = $n.".".$filho;
23 if( $array_Filhos[$j] != 0 )
24 Desc($array_Filhos[$j], $numero);
25 }
26 }
27 }
28 echo "</li></ol>";
29 }
Na linha 4, a variável $filho é inicializada. Esta variável terá seu valor incremen-
tado em “1” na linha 21 e concatenada com $n, um dos parâmetros passados pela
função. O código HTML é escrito na linha 7 criando uma lista. Nesta mesma li-
nha a função PegaNome() retorna o nome do indivı́duo através do identificador passado
como parâmetro. O identificador do cônjuge é retornado em um vetor através da função
PegaIdConjuge(). Mais uma vez a função PegaNome() é usada para trazer o nome do
cônjuge na linha 16. O identificador dos filhos do indivı́duo e seu cônjuge são retorna-
dos através da função PegaFilho() na linha 18 e finalmente na linha 24 há a chamada
recursiva da função Desc(). A figura 3.6 é o resultado do uso desta função.
Figura 3.6: Resultado do uso da função Desc().
3.6.2 Ascendência
Para retornar a Ascendência a partir de um indivı́duo também foi criada uma função.
Tal função usa o conceito de árvores binárias. Isso quer dizer que se um indivı́duo ocupa
a posição n em uma árvore genealógica, seu pai ocupará a posição 2n e sua mãe, 2n+1.
Inclusive, este é um modo de registrar linhagens de ascendência em genealogia, chama-se

gráfico Ahnentafel. Um exemplo do gráfico Ahnentafel seria assim:
Gráfico Ahnentafel:
Primeira Geração
1. Filho
Segunda Geração
2. Pai
3. Mãe
Terceira Geração
4. Avô paterno
5. Avó paterna
6. Avô materno
7. Avó materna
Quarta Geração
8. ...
9. ...
10. ...
Essa mesma numeração é usada para posicionar indivı́duos dentro da estrutura de

tabela da árvore genealógica que é estática. Na aplicação somente é possı́vel mostrar 4
gerações, incluindo o indivı́duo escolhido para visualizar-se a ascendência. São passados
2 parâmetros para a função Asc(). O identificador do indivı́duo e o número referente à
posição que leva na árvore. A função retorna este vetor. O código está listado abaixo.
1 function Asc($id, $i)

2 {
3 global $ids;
4 $mae = 0;
5 $pai = 0;
6 $array_idpais = PegaPais($id);
7 $pai = $array_idpais[0];
8 $mae = $array_idpais[1];
9
10 $ids[$i] = $id;
11
12 if( $pai != 0 && $i < 8 )
13 Asc($pai, 2*$i);
14
15 if( $mae != 0 && $i < 8 )
16 Asc($mae, 2*$i+1);
17
18 return $ids;
19 }
Na linha 3, a variável $ids é declarada como global para que não perca seu valor
a cada chamada da função. As variáveis $pai e $mae recebem o valor 0 nas linhas 4 e
5. Na linha 7 a função PegaPais() retorna para um vetor os identificadores dos pais do
indivı́duo. O vetor $ids[] recebe o valor do identificador indexado pelo seu número de
posição na árvore genealógica. A verificação feita nas linhas 13 e 16 ($i < 8) asseguram
que somente serão retornados os indivı́duos até a quarta geração. Nas linhas 14 e 17 são
feitas as chamadas recursivas para o pai e a mãe do indivı́duo. A função retorna o vetor
$ids. O resultado aparece na página da maneira como mostra a figura 3.7.
3.6.3 Importação de Arquivos Gedcom

A importação dos dados contidos num arquivo Gedcom é feita através de várias funções. É
necessário fazer a leitura do arquivo, o reconhecimento das marcações, nı́veis hierárquicos
e seus valores. Além disso, tudo precisa ser validado.
Inicialmente, o usuário deve estar cadastrado na aplicação e deve ter efetuado o login.
Em sua área restrita ele escolhe a funcionalidade “Carregar GEDCOM”. Na próxima tela,
o usuário irá escolher em seu computador do qual deseja fazer a importação dos dados,
como mostrado na figura 3.8.
Após o arquivo ser escolhido é verificado se realmente se trata de um arquivo Gedcom.
Assim sendo, são aplicadas ao conteúdo do arquivo as funções que interpretam e extraem
as informações em três etapas. Primeiramente são coletados nome, sobrenome, sexo,
informações dos eventos nascimento e óbito. Tais informações são armazenadas nas tabelas
PESSOA e EVENTO do banco de dados, assim como são feitas as devidas entradas na
tabela entidade-relacional PESSOA EVENTO. Finalmente, em uma tabela temporária
são armazenados o número identificador de cada indivı́duo dentro do arquivo Gedcom,
o número identificador que o mesmo indivı́duo recebeu ao ser inserido na tabela e o
identificador do usuário que está realizando a operação.
Esta rotina e feita em 3 etapas e com a ajuda desta tabela temporária pois é necessário
que já se conheça o identificador de todos os indivı́duos contidos no arquivo Gedcom
pois eles se relacionam entre si. Por exemplo, não há como fazer a referência ao pai de
determinado indivı́duo se ele ainda não foi armazenado no banco de dados. Nem guardar
o evento casamento desse mesmo indivı́duo se seu cônjuge ainda não foi armazenado.
Após realizada a primeira etapa, guardando as informações referentes aos indivı́duos
constantes no arquivo Gedcom, as funções são aplicadas mais uma vez, procurando-se
pelos seus pais. A função primordial usada nestas etapas é chamada LeArquivoGedcom()
que retorna o número identificador do indivı́duo no arquivo. É feita então a comparação
deste número com o conteúdo inserido na tabela temporária para obterem-se os identifica-
dores que receberam ao adentrar no banco de dados. Assim, as informações do indivı́duo
são alteradas para receberem os identificadores de seus pais.
A terceira etapa é semelhante à segunda. Novamente são retornados os números iden-
tificadores contidos no arquivo e desta vez procura-se as marcações referentes às famı́lias.
Ao serem encontradas são armazenados os eventos do tipo casamento e são efetuadas as
entradas na tabela entidade-relacional PESSOA EVENTO para o indivı́duo e seu cônjuge.
Ao final desta execução, vão sendo removidos da tabela temporária os registros referen-
tes aos identificadores do indivı́duo e seu cônjuge, para que não sejam inseridos registros
duplicados quando for a vez do cônjuge do indivı́duo passar por esta etapa.
Alguém pode perguntar o motivo pelo qual o evento casamento não é armazenado no
banco de dados na primeira etapa, já que as informações do casamento e o identificador do
Figura 3.7: Resultado do uso da função Asc().
indivı́duo já é conhecido. Isto não é feito porque o modelo de dados do arquivo Gedcom
é diferente do modelo de dados desenvolvido para a aplicação web. No Gedcom há a
marcação FAM, de onde são tiradas as informações do evento do tipo casamento. Em um
arquivo onde conheça-se somente um dos pais de determinado indivı́duo irá existir uma
entrada para a marcação FAM da maneira como figura o exemplo 3.6.1, a famı́lia contem
Figura 3.8: Escolhendo o arquivo Gedcom a ser carregado.
somente o pai e 2 filhos.
Exemplo 3.6.1.
0 @F1@ FAM
1 HUSB @I1@
1 CHIL @I2@
1 CHIL @I3@
Se a entrada do casamento fosse feita na primeira etapa, onde não seria verificada a
existência de um cônjuge, seria inserido no banco de dados um evento do tipo casamento,
mesmo sem dado algum, para o indivı́duo que leva o identificador @I1@. Como na verdade
não existe um casamento, pois não há cônjuge, isso geraria inconsistência no modelo de
dados empregado para a aplicação.
3.6.4 Exportação de Arquivos Gedcom

Uma das funcionalidades da aplicação web é criar um arquivo Gedcom contendo as in-
formações constantes em uma determinada página. A criação do arquivo em si é simples.
A página web recebe um parâmetro, que é o identificador de determinada pessoa. O
programa então retorna as informações 1 relacionadas ao indivı́duo referente ao identifi-
cador.Tais informações são passadas para a função echo() do PHP, já permeadas com as
marcações e nı́veis do Gedcom. As seguintes linhas fazem com que apareça a janela de
diálogo para salvar o arquivo:
header(’Content-type: text/gedcom’);
header(’Content-Disposition: attachment; filename="info.ged"’);
A primeira linha acima diz que o conteúdo da página é um text/gedcom (mime-type

do arquivo Gedcom) e a segunda faz com que uma caixa de diálogo para o salvar o arquivo
seja aberta no navegador, como mostra a figura 3.9.
3.7 Considerações Finais

Neste capı́tulo foi discutido o emprego de cada tecnologia e recurso escolhido para o desen-
volvimento da aplicação web. É conhecido que talvez não tenham sido usadas as melhores
opções existentes, entretanto é certo que foram as melhores opções data a situação e o
tempo disponı́vel para a conclusão do trabalho.
A arquitetura adotada, a cliente/servidor, é a mais comum utilizada para a hospeda-
gem de sı́tios atualmente. Isto se deve pelas suas vantagens. Normalmente somente um
ou poucos computadores são usados para a porção servidor. Isto é uma solução de baixo
custo. Além disso, as tarefas são distribuı́das, enquanto o servidor processa os dados, a
porção cliente se encarrega de visualizar a interface.
As decisões foram detalhadas na seção 3.3. Conforme lá foi descrito, não haveria tempo
para o desenvolvimento da aplicação utilizando-se a linguagem Java, pois decididamente
levar-se-ia mais tempo programando em tal linguagem. Pelo mesmo motivo, o tempo, os
objetivos do projeto já haviam sido diminuı́dos. Não seria possı́vel suprimir ainda mais
os recursos que a aplicação deve oferecer. Por este motivo, Java foi excluı́da das opções
e, por suas caracterı́sticas, foi escolhida a linguagem PHP.
Continuando, como a quantidade de literatura acerca do uso do PHP em conjunto
com o banco de dados MySQL é maior que qualquer outra combinação, a escolha natural
em relação à forma de armazenamento das informações seria o próprio MySQL, fácil e
simples de usar, porém simplório demais. Há quem diga que o MysQL é na verdade
um gerenciador de tabelas, visto que não possui recursos mı́nimos, como integridade-
relacional, assim como não conta com as funcionalidades de visões, procedimentos, entre
outros. Por este motivo foi escolhido o PostgreSQL que realmente é um SGBD e é de uso
livre, além de todas as funcionalidades que oferece.
O diagrama de classes da UML que representa o modelo navegacional, constante na
seção 3.5, faz entender a navegação entre as várias páginas da aplicação. Como pode-se
1
Informações constantes no arquivo Gedcom: nome, sobrenome, data e local de nascimento, óbito
e casamento do indivı́duo; nome, sobrenome, data e local de nascimento e óbito do(s) cônjuge(s) do
indivı́duo; nome, sobrenome, data e local de nascimento, óbito e casamento dos pais do indivı́duo; nome,
sobrenome, data e local de nascimento e óbito do(s) filho(s) do indivı́duo com seu(s) cônjuge(s).
Figura 3.9: Salvando um arquivo Gedcom com o conteúdo da página.
perceber, cada ferramenta está acessı́vel a partir de vários pontos da navegação para dar
mais agilidade à navegabilidade.
A seção 3.4 discorreu sobre o emprego do Gedcom e do Gentech Genealogical Data
Model (GDM). Somente parte da especificação do Gedcom é reconhecida pela aplicação.
Apenas as informações referentes ao indivı́duo e os eventos do tipo nascimento, casamento
e óbito. Como o GDM é realmente detalhista somente foi usado um sub-conjunto deste,
adequando-se as entidades e relacionamentos para os objetivos da aplicação.
As particularidades da aplicação web foram descritas na seção 3.6. As funções que
retornam a Descendência e a Ascendência de determinados indivı́duos foram descritas
nesta seção. São funções recursivas simples. As rotinas para a importação de e exportação
para arquivos Gedcom foram também discutidas.
Capı́tulo 4
Conclusão
4.1 Análise Crı́tica

O objetivo geral descrito neste trabalho na seção 1.2 do capı́tulo 2 à página 6 é o de-
senvolvimento de mecanismos destinados à publicação e compartilhamento de dados ge-
nealógicos. Pode-se dizer que o objetivo foi atingido, sendo que tais funcionalidades foram
desenvolvidas e funcionam plenamente.
Mas uma análise do resultado final em relação aos objetivos especı́ficos deve ser feita.
Há algumas ressalvas e cada objetivo especı́fico está comentado abaixo.
Ascendência. Na aplicação web é o nome dado ao relatório em forma de árvore ge-

nealógica, que mostra os antecedentes de um determinado indivı́duo, ou seja, seus
pais, avós, bisavós, e assim sucessivamente.
A rotina desenvolvida para mostrar este tipo de relatório retorna somente quatro
gerações. Primeiramente há uma limitação gráfica que impossibilita o retorno de
todas as gerações existentes a partir de um indivı́duo, pois os dados são coloca-
dos dentro de tabelas em código HTML. Estas tabelas precisam ser construı́das
previamente para que tenham uma boa visualização gráfica.
Entretanto, poderia ter sido desenvolvido um mecanismo de escolha por quantas
gerações se deseja visualizar, mesmo que o número de gerações possa extrapolar o
tamanho da tela. Seria necessário então serem preparadas previamente tabelas em
código HTML para cada número de gerações possı́vel de ser escolhido.
Esta é uma funcionalidade que será adicionada em trabalhos futuros.
Descendência. É o nome dado ao relatório da aplicação que mostra todos os filhos

gerados pelo(s) casamento(s) de um determinado indivı́duo e pelo(s) casamento(s)
de seus filhos, netos, bisnetos e assim sucessivamente.
O resultado final é considerado altamente satisfatório. Todos os descendentes de
um indivı́duo são numerados e listados como pretendido. Não foram observadas
possı́veis alterações para este relatório em futuras versões do sı́tio.
Relatório. É o formato de apresentação da genealogia onde é mostrado o maior número

possı́vel de informações em uma página HTML. Os dados mostrados são: nome,
data e local de nascimento, óbito (se for o caso) e outros eventos registrados ligados
a ele; nome de seus pais (se presentes no banco de dados); nome do(s) cônjuge(s),
45
4.2. COMPARAÇÕES 46
local e data do(s) casamento(s) (se for o caso); nome do(s) filho(s) gerado pelo(s)
casamento(s).
A conclusão desta forma de apresentação da genealogia é a que apresenta o maior
número de informações, o que é considerado ideal. Para a disponibilização do sı́tio
a usuários a única mudança que poderia ser feita seria no leiaute da página.
Gerenciamento. São as rotinas de inserção, alteração e remoção de indivı́duos, eventos

e fontes. Tais rotinas foram desenvolvidas com dois objetivos em mente: o apro-
veitamento de páginas (todas as tarefas são realizadas na mesma página para cada
item) e a facilidade de uso. Talvez deva ser adicionado em cada página um texto
com uma explicação mais pormenorizada das operações.
Importação de Arquivos Gedcom. Os dados contidos em um arquivo Gedcom 1 são

importados pela aplicação através de funções que abrem o arquivo, analisam seu
conteúdo e reconhecem as marcações do Gedcom. Todas as informações a que o
sistema se propõe a reconhecer são armazenadas no Banco de Dados.
Exportação de arquivos Gedcom. A exportação dos dados genealógicos contidos no

sı́tio é feita como proposto. As informações contidas na página que mostra o relatório
de um indivı́duo são transformadas num arquivo Gedcom que, nos testes efetuados,
foi reconhecido por softwares de genealogia. Entretanto, seria mais prático se, ao
invés de criar o Gedcom a partir da página que mostra o Relatório, o usuário do
sı́tio pudesse escolher as informações de quais indivı́duos deseja obter.
A rotina não foi desenvolvida desta maneira pois essa necessidade foi percebida
tardiamente pelo grupo e não houve tempo de refazê-la, já que para assim funcio-
nar as rotinas e o processo de escolha das informações necessitariam de um maior
planejamento e desenvolvimento.
Para facilitar a navegação e acesso às informações, foi adotado um padrão na aplicação.
Sempre que o nome de um indivı́duo for citado, ele conterá uma ligação para a página
que mostra seu Relatório. E tal página possui ligação para a Ascendência, Descendência
a obtenção do arquivo Gedcom. Com isso, acredita-se que o quesito acessibilidade pode
ser considerado como satisfatório.
Enfim, pode-se afirmar que todas as funcionalidades satisfazem seu propósito. Desde
o gerenciamento, à consulta e à apresentação dos resultados, todas foram concluı́das.
Lembrando que os objetivos são apresentar as funcionalidades necessárias para um sı́tio
genealógico e não um sı́tio completo, com todos os requisitos que deveria ter.
4.2 Comparações
A aplicação web desenvolvida, que originará um sı́tio para a comunidade genealógica, é
incomparável no que diz respeito a gratuidade do uso e na existência de algo semelhante
em Português.
Há vários sı́tios dedicados à construção de árvores genealógicas, inclusive com a opção
de importação de arquivos Gedcom, porém todos eles são usados mediante pagamento
de taxas (One Great Family [19] e My Family [20]) ou permitem a inserção de algumas
gerações e, para que mais indivı́duos possam ser incluı́dos, a compra de um software
1
Formato de arquivo genealógico, descrito na seção 2.5 do capı́tulo 2 à página 20.
4.3. TRABALHOS FUTUROS 47
genealógico é necessária. Sendo estes sı́tios em Inglês e desenvolvidos nos Estados Unidos,
a maioria das informações neles contidas dizem respeito ao próprio Paı́s.
O sı́tio Family Search [21] de A Igreja de Jesus Cristo dos Santos dos Últimos Dias
pode ser comparado ao propósito desta aplicação. Este sı́tio também tem o objetivo
de compartilhar genealogia e o faz disponibilizando vários bancos de dados contendo in-
formações genealógicas: censos realizados em vários paı́ses, informações da própria igreja,
dados enviados através de arquivos Gedcom por usuários do sı́tio, entre outros.
Como o objetivo do Family Search é, por conta dos preceitos da Igreja, ajudar aos
membros a construirem sua história familiar, não existem funcionalidades de gerencia-
mento. Somente a consulta é possı́vel. Considerando-se que genealogia é um trabalho que
não tem fim, tal gerenciamento torna-se necessário, é neste ponto que a aplicação web
desenvolvida distingue-se com mais intensidade do sı́tio em questão.
Outro ponto importante a ser relevado é que no Family Search somente ficam dis-
ponı́veis as informações de indivı́duos já falecidos. Não será discutido o mérito disso, pois
tais informações são suficientes para os objetivos do sı́tio. Ou seja, o Family Search é uma
grande fonte de informações para os futuros usuários da aplicação web.
4.3 Trabalhos Futuros

Sem dúvida há muito que pode ser feito futuramente na aplicação web. Antes que o
sı́tio seja disponibilizado para o uso, serão acrescentados todos os recursos primordiais
de que necessita para o funcionamento. Forma de contato com o sitio e os usuários
cadastrados, FAQ, fórum de sobrenomes, listagem de sı́tios afins, postagem e consulta a
dicas e informações úteis e a possibilidade de inserção de fotos dos indivı́duos contidos
nas árvores genealógicas.
Num futuro próximo deve-se implementar rotinas de rastreamento de nomes para que,
ao ser inserido um novo indivı́duo, o banco de dados possa ser consultado para evitar-se
a inclusão duplicada de indivı́duos. Já existem técnicas que foram apresentadas no já
citado Annual Workshop on Thechnology for Family History and Genealogical Research
[6].
A busca existente na aplicação é feita somente através de nomes e/ou sobrenomes.
Uma busca avançada deve ser incluı́da em uma versão do sı́tio. Tal busca deve prever a
procura por indivı́duos através de datas e locais especı́ficos. Deve também ser possı́vel
buscar indivı́duos por parentesco, como por exemplo, para relacionar todos os netos de
determinado indivı́duo, ou todos os seus casamentos. Pensa-se, inclusive, no uso de Lin-
guagem Natural na formulação das perguntas para tal tipo de pesquisa.
A importação e exportação de arquivos Gedcom deve ser estendida para que todos os
eventos previstos na especificação do arquivo possam ser reconhecidos pela aplicação.
Há previsão para o uso da linguagem XML (Extended Markup Language) [22]. Seria
utilizada uma especificação beta do Gedcom que utiliza a XML, o Gedcom XML 6.0 [23].
Esta especificação do Gedcom é uma definição das marcações reconhecidas e transforma-
das para XML. A versão, até o presente momento, não está sendo usada.
Apêndice A
Questionário
Questionário aplicado a pessoas que se dedicam, profissional ou amadoramente à genea-

logia.
1. Por que você faz genealogia?
2. Você se considera um genealogista (por favor, marque somente uma alternativa):

() Iniciante (amador)
() Intermediário
() Avançado (profissional)
3. Há quanto tempo se dedica à genealogia? (por favor, marque somente uma alterna-
tiva)
() 1 ano
() De 2 anos a 5 anos
() De 6 anos a 10 anos
() Mais de 10 anos
4. Onde normalmente você procura e/ou obtém informações? (marque mais de uma
opção se necessário)
() Livros
() Registros Religiosos
() Registros Civis
() Outros registros
() Publicações de outros genealogistas
() Informações verbais
() Sites pessoais e/ou portais de genealogia
() Periódicos antigos
() Outros
5. De que forma você armazena/publica suas informações? (marque mais de uma

opção se necessário)
() Livro
() Software
() Site pessoal
() Portal de genealogia
() Manuscritos
() Outros
48
APÊNDICE A. QUESTIONÁRIO 49
6. Você utiliza algum software de genealogia?

() Sim
() Não
Qual?
7. Este software possui a capacidade de importar/exportar arquivos Gedcom?

() Sim
() Não
() Não Sei
8. Com relação à Internet, existe carência de alguma ferramenta de publicação e/ou

compartilhamento de informações genealógicas? Se sim, descreva ligeiramente como
seria esta ferramenta.
() Sim
() Não
() Não sei
Descreva, por favor:
9. Você publicaria suas informações genealógicas em um portal de genealogia a fim de

compartilhá-las com possı́veis interessados?
() Sim
() Não
() Não sei/Talvez
Por que?
Apêndice B
Diagrama - Gentech Genealogical

Data Model
Pequenas partes do diagrama de modelos de dados genealógicos da Gentech foram sendo

demonstrados ao decorrer da seção 2.6. Suas entidades foram explicadas brevemente.
Para haver um melhor entendimento de todo o diagrama, ele está sendo disponibilizado
neste apêndice.
50
APÊNDICE B. DIAGRAMA - GENTECH GENEALOGICAL DATA MODEL 51
Figura B.1: Diagrama Completo da Gentech.

Referências Bibliográficas
[1] Yahoo! Grupos Brasil. http://www.yahoogrupos.com.br. Data do acesso: 19 de

março de 2004.
[2] Yahoo! Groups. http://www.yahoogroups.com. Data do acesso: 19 de março de
2004.
[3] Google Brasil. http://www.google.com.br. Data do acesso: 19 de março de 2004.
[4] L. Richards. Uma Obra Maravilhosa e um Assombro. Deseret Book Company, 1976.
[5] Computer Science Departament/Brigham Young University. Family history techno-
logy laboratory. http://icie.cs.byu.edu/FHiTL/. Data do acesso: 27 de março de
2004.
[6] Computer Science Departament/Brigham Young University. Annual workshop on
technology for family history and genealogical research. http://www.fht.byu.edu/.
Data do acesso: 27 de março de 2004.
[7] D. Albrecth, D. Dean, R. Jackson, and R. Meservy. A peer-to-peer network protocol
for genealogical data. In Proceedings of the Workshop on Technology for Family His-
tory and Genealogical Research. Department of Computer Science - Brigham Young
University, 2001.
[8] Fine - gntp client. http://www.aldfaer.nl/fine/. Acesso em: 25 de março de 2004.
[9] E. Jarvi and N. Leippe. Global genealogy network extended abstract. In Procee-
dings of the Workshop on Technology for Family History and Genealogical Research.
Department of Computer Science - Brigham Young University, 2001.
[10] D. Barney and R. Lee. ELIJAH, extracting genealogy from the web. In Procee-
dings of the Workshop on Technology for Family History and Genealogical Research.
Department of Computer Science - Brigham Young University, 2001.
[11] T. Converse and J. Park. PHP 4: A Bı́blia. Campus, Rio de Janeiro, 2001.
[12] The PostgreSQL Global Development Group. Guia do usuário do postgresql 7.3.4.
http://www.postgresql.org.br/usuario/index.html. Data do acesso: 29 de março de
2004.
[13] Mysql documentation. http://dev.mysql.com/doc/. Data do acesso: 30 de abril de
2004.
[14] G. Booch, J. Rumbaugh, and I. Jacobson. UML, Guia do Usuário. Editora Campus,
2000.
52
REFERÊNCIAS BIBLIOGRÁFICAS 53
[15] Sı́tio Oficial do PHP. PHP manual. http://www.php.net/manual/en/preface.php.

Data do acesso: 29 de março de 2004.
[16] Departamento de História da Famı́lia e da Igreja/Igreja de Jesus

Cristo dos Santos dos Últimos Dias. GEDCOM 5.5 specification.
http://www.familysearch.org/GEDCOM/GEDCOM55.EXE. Data do acesso:
29 de março de 2004.
[17] Lexicon Work Group. The gentech genealogical data model.

http://www.gentech.org/gdm/, May 2000.
[18] Microsoft Corporation. Networking Essentials, Second Edition: Academic Learning

Series. Microsoft Press, 1997.
[19] Onegreatfamily. http://www.onegreatfamily.com. Data do acesso: 13 de abril de

2004.
[20] Myfamily. http://www.myfamily.com. Data do acesso: 13 de abril de 2004.
[21] A Igreja de Jesus Cristo dos Santos dos ltimos Dias. Familysearch internet genealogy
service. http://www.familysearch.org. Data do acesso: 13 de abril de 2004.
[22] World Wide Web Consortiun. Extensible markup language.

http://www.w3.org/XML/. Data do acesso: 30 de abril de 2004.
[23] Departamento de História da Famı́lia e da Igreja/Igreja de Jesus

Cristo dos Santos dos Últimos Dias. Gedcom xml 6.0 specification.
http://www.familysearch.org/GEDCOM/GedXML60.pdf. Data do acesso: 29
de março de 2004.

Radici

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Radici

Încărcat de

Drepturi de autor:

Formate disponibile

Radici: Aplicação Web para

Juliana Oliveira Souza

Orientação: Prof. Dr. Paulo A. Pagliosa

Área de Concentração: Aplicação Web

Monografia apresentada ao Departamento de Computação e Estatı́stica da Universidade

Departamento de Computação e Estatı́stica

Palavras-chave: aplicação web, genealogia, Gedcom, Gentech Genealogical Data Model

Lista de Figuras vii

Lista de Tabelas viii

B Diagrama - Gentech Genealogical Data Model 50

2.1 Parte do Sub-modelo de Administração [17]. . . . . . . . . . . . . . . . . . 24

3.1 Arquitetura cliente/servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

B.1 Diagrama Completo da Gentech. . . . . . . . . . . . . . . . . . . . . . . . 51

1.1 Nı́vel X Tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 Justificativas e Motivações

1.1.2 Questionário com Genealogistas

Tabela 1.1: Nı́vel X Tempo.

Registros Religiosos 80,72%

Tabela 1.2: Fontes de Pesquisa.

Tabela 1.3: Forma de Publicação.

Tabela 1.4: Software: importa/exporta Gedcom?

Quando perguntados se existe a carência de alguma ferramenta na Internet para o

“Creio que poderia ser criado um ’mega-portal’ de genealogistas brasileiros,

“Uma forma de gerenciar meus dados em um ’Banco de Dados Compar-

“Existe, principalmente, a falta de um grande Banco de Dados brasileiro,

“Não existe uma árvore genealógica virtual, onde as pessoas possam ir

“A maioria das informações/sites disponı́veis na Internet exigem paga-

“Parto do princı́pio do compartilhamento para facilitar o intercâmbio das

1.1.3 Outros Trabalhos

famı́lia e pesquisas genealógicas. Os trabalhos apresentados nas edições deste workshop

O método proposto funciona através da classificação dos sı́tios pessoais de genealogia

• Desenvolvimento de rotinas de consulta simples às informações contidas no banco

• Apresentação dos dados em 3 formatos:

– Ascendência: dado um indivı́duo, mostrar até 4 gerações de seus ancestrais em

• Gerenciamento: rotinas de inserção, alteração e remoção de indivı́duos e qualquer

• Importação de arquivos Gedcom: reconhecer a arquitetura de tais arquivos, extrair

• Exportação de arquivos Gedcom: selecionar informações contidas no banco de dados

Enfim, o esforço foi empregado para apresentar as ferramentas fundamentais para um

1.3 Organização do Texto

“A UML é capaz de representar tudo que possa ser melhor expresso em

2.2.2 Modelo Conceitual da UML

Itens Estruturais. São os substantivos utilizados em modelos da UML, são as partes

Itens Comportamentais. São os verbos de um modelo, representando comportamen-

Itens de agrupamento. São as partes organizacionais dos modelos de UML. São os

Há também quatro tipos de relacionamentos.

Dependência. É um relacionamento semântico entre dois itens, nos quais a alteração de

Associação. É um relacionamento estrutural que descreve um conjunto de ligações, em

Generalização. É um relacionamento de especialização/generalização, onde os objetos

Realização - É um relacionamento semântico entre classificadores, em que um classifica-

Finalmente, um diagrama é a apresentação gráfica de um conjunto de elementos re-

constitui uma projeção de um determinado sistema. O mesmo elemento pode aparecer

Quando um cliente solicita esta página, o servidor web a pré-processa. O servidor

Compatibilidade com Várias Plataformas

Compatibilidade com Outras Tecnologias

print (" Valor de "pais": $pais<BR>");

Valor de ”pais”: Brasil

function my_function($arg1, $arg2, ..., $arg3)

Passando Informações entre Páginas

“Com mais de uma década de desenvolvimento por trás, o PostgreSQL

Porém antes de ser um SGBD (sistema de gerenciamento de banco de dados) desta

Tipos geométricos: representam objetos no espaço bidimensional. O tipo “ponto”, que

Tipos de dado para endereço de rede: destinados a armazenas endereços IP e de

Pseudotipos: utilizados para declarar tipos de argumentos e de resultados de funções.

“O PostgreSQL em sua arquitetura, utiliza o modelo cliente-servidor, ou