O sistema TagCenter possui dois conceitos que são fundamentais para sua compreensão, estes
conceitos são "persons" e "peoples".
A chave primária da relação entre estas duas entidades é o endereço de email utilizado
ao se cadastrar no sistema. Sendo que várias "persons" podem levar à mesma
"people" (é uma relação N:1).
Existe uma trigger no banco de dados que cria essa correlação de forma automatizada.
Isso aborda a integridade do banco de dados atrelando o people_id ao person_id.
CREATE OR REPLACE FUNCTION copy_person_to_people() RETURNS TRIGGER AS
$BODY$
DECLARE
people_id bigint;
BEGIN
IF NOT EXISTS (SELECT 1 FROM tagchat.peoples p WHERE p.email = NEW.email)
AND NEW.email IS NOT NULL THEN
INSERT INTO
tagchat.peoples(email, phone_number)
VALUES(NEW.email, NEW.phone_number)
RETURNING id INTO people_id;
new.people_id := people_id;
ELSE
people_id := (SELECT p.id FROM tagchat.peoples p WHERE p.email =
NEW.email);
new.people_id := people_id;
END IF;
RETURN NEW;
END;
$BODY$
language plpgsql;
Quando uma nova "person" é cadastrada no sistema, a API é chamada por uma rota e então gera uma mensagem Confluent Kafka para o Enrichment Node Manager que controla as mensagens enviadas para os erichment_nodes. Seguindo a estrutura geral mostrada abaixo.
O sistema possui os seguintes nós possíveis para enriquecimento de dados: basic-data, geodata, enterprise-scrapper, whatsapp, linkedin, emergencial-aid.
Esses nós são gerenciados pelo nosso Enrichment Manager que decide quando eles devem ser chamados e em que ordem. E na tabela Peoples estão os controladores de qual enriquecimento e quando essa "person" recebeu.
Cada nó é responsável por criar atividades, anotações e logs que são usados no próprio sistema.
Github: Enrichment Nodes Manager
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| name | varchar | nome completo |
| common_name | varchar | nome comum |
| gender | varchar | gênero |
| birth_date | timestamp | data em que nasceu |
| age | integer | idade da "people" |
| birth_country | varchar | o país que nasceu |
| mother_name | varchar | o nome da mãe |
| tax_id_number | varchar | o número do documento (cpf) |
| tax_id_origin | varchar | a origem do documento |
| tax_id_country | varchar | o país em que o documento foi originado |
| tax_id_fiscal_region | varchar | o estado em que o documento foi originado |
| has_obit_indication | boolean | se a pessoa tem indicação de obito ou não |
Github: Node Basic Data
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| macroregion | varchar | a macrorregião da pessoa |
| distance_capital | varchar | a distância em km da cidade da pessoa até a capital do estado |
| gentilic | varchar | como o povo daquela cidade é chamado |
| pib | varchar | o PIB per capita dessa cidade |
| idh | varchar | o IDH daquela cidade |
Github: Node GeoData
Entrepreneur:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| entrepreneur_since | varchar | o dia em que o primeiro empreendimento da pessoa foi aberto |
| number_of_enterprises | integer | o número de empresas que a pessoa tem |
| match_cpf | boolean | se o cpf do basic_data corresponde ao do site |
| partners | array of text | os nomes dos sócios da pessoa |
Enterprises:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| entrepreneur_entry_date | varchar | o dia em que o empreendedor ingressou na empresa |
| cnpj | varchar | documento principal da empresa |
| company_name | varchar | o nome da empresa |
| fantasy_name | varchar | o nome fantasia da empresa |
| register_status | varchar | a origem do documento |
| share_capital | double | o valor do capital quando a empresa abriu |
| economic_activity | varchar | em qual ramo econômico a empresa opera |
| legal_nature | varchar | a natureza jurídica da empresa |
| revenue | varchar | a receita da empresa |
| size | varchar | o tamanho da empresa |
Github: Node Enterprise Scrapper
Linkedin:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| name | varchar | o nome da pessoa no linkedin |
| bio | varchar | a bio do perfil do linkedin |
| description | varchar | a descrição do perfil do linkedin |
| location | varchar | a localização do perfil do linkedin |
Educations:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| degree_name | varchar | o nome da graduação |
| study_field | varchar | o campo de estudo |
| school_name | varchar | a entidade certificadora |
Experiences:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| title | varchar | o cargo exercido |
| company | varchar | a empresa dessa experiência |
| description | varchar | descrição dessa experiência |
Skills:
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| title | varchar | o nome da habilidade |
Github: Node Linkedin Scrapper
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| whatsapp_verified | boolean | se o telefone dessa pessoa é um whatsapp válido |
| whatsapp_profile | varchar | uma url que leva para a foto do perfil do whatsapp |
Github: Node Whatsapp Validate
| Nome da coluna | Tipo de dado | Descrição |
|---|---|---|
| name | varchar | o nome completo da pessoa no site |
| match_cpf | boolean | se o cpf do basic_data corresponde ao do site |
| nis | varchar | o documento nis |
| data | json | os dados completos que o scrapper encontrou |
Github: Node Emergencial Aid Scrapper
Existe um processo de comunicação constante entre o Nodes Manager e os nós
em sí, isso acontece porque alguns nós já terão todas as informações, estes precisam executar enquanto outros serão dependentes de outros nós para terminar a execução.
Esta é a estrutura geral do banco de dados. Há uma tabela principal chamada "Peoples" e as outras tabelas satélites com os dados enriquecidos, todas possuem uma chave estrangeira.
Observe que a estrutura abaixo é uma abstração dessas tabelas, usando um único
campo chamado data para representar todas as suas colunas. Também note que a tabela enrichment_log armazena todo processo que aconteceu com um "people", independentemente de ter sido sucesso ou fracasso.
