A maneira mais comum de se armazenar dados hoje em dia \u00e9 por tabelas. Usualmente, esses dados s\u00e3o armazenados de forma que cada tabela cont\u00eam um conjunto de dados de um mesmo contexto e uma coluna que permite interliga-la com outras tabelas. Esse tipo de modelo para bases de dados \u00e9 chamado de Modelo Relacional<\/strong>, termo cunhado por Edgar Frank<\/strong> Codd <\/strong>em 1970. <\/p>\n\n\n\n

O Zoho Analytics \u00e9 uma plataforma de a an\u00e1lise de dados projetada para lidar com essas bases de dados relacionais. Entretanto, antes de sair fazendo varias an\u00e1lises e m\u00e9tricas sobre os dados da base, \u00e9 necess\u00e1rio efetuar alguns processos para explicitar qual a rela\u00e7\u00e3o entre as tabelas e garantir que as colunas de pesquisa<\/strong> (lookup column<\/em>) concordam umas com as outras. <\/p>\n\n\n\n

Essas colunas de pesquisa nada mais s\u00e3o que o ponto de equival\u00eancia entre as tabelas. Elas podem ser desde rela\u00e7\u00f5es de igualdade direta ou rela\u00e7\u00f5es que exigem algum tipo de altera\u00e7\u00e3o nos dados. Seja qual for a rela\u00e7\u00e3o, a exist\u00eancia dessas colunas t\u00eam algumas vantagens para o tratamento de dados, como:<\/p>\n\n\n\n

• Podem ser usadas para evitar dados duplicados.<\/li>
• Servem como uma forma de segregar as m\u00e9tricas e dimens\u00f5es da tabela, principalmente ao se utilizar fun\u00e7\u00f5es agregadoras.<\/li>
• Permitem a defini\u00e7\u00e3o de modelos familiares \u00e0 an\u00e1lise de dados, como o modelo Estrela e o Modelo Floco-de-neve.<\/li><\/ul>\n\n\n\n

  Cardinalidade<\/h2>\n\n\n\n

  Antes de definir as colunas de pesquisa, \u00e9 importante se ter consci\u00eancia de qual o tipo de rela\u00e7\u00e3o entre os dados. Esses tipos s\u00e3o chamados de cardinalidade<\/strong>. Existem 3 tipos de cardinalidade no contexto do tratamento de dados:<\/p>\n\n\n\n

  • Um para um:<\/strong> S\u00e3o os dados que tem uma equival\u00eancia \u00fanica entre si, isto \u00e9, para cada elemento na tabela A, existe uma \u00fanica equival\u00eancia na tabela B, e vice-versa<\/em>. Alguns exemplos do uso dessa rela\u00e7\u00e3o:
    • Cada pessoa possui um \u00fanico CPF, e cada CPF representa uma \u00fanica pessoa.<\/li>
    • Cada estado possui um \u00fanico governador, e cada governador rege um \u00fanico estado.<\/li><\/ul><\/li>
    • Um para Muitos<\/strong> e Muitos para Um<\/strong>: S\u00e3o os dados em que em uma das tabelas ele aparece sem repeti\u00e7\u00e3o, enquanto na segunda tabela eles sem repetem. Nesse caso a rela\u00e7\u00e3o \u00e9 escrita como: para cada elemento na tabela A, existe uma \u00fanica equival\u00eancia na tabela B, mas cada elemento na tabela B pode ter varias equival\u00eancias na tabela A. <\/em>Esse tipo de rela\u00e7\u00e3o \u00e9 muito utilizada em casos como:
      • Cada pessoa possui uma data de nascimento, mas em uma data podem ter nascido varias pessoas.<\/li>
      • Cada cliente \u00e9 atendido por um funcion\u00e1rio, mas um mesmo funcion\u00e1rio pode atender v\u00e1rios clientes.<\/li>
      • Cada deputado representa um estado, mas um estado \u00e9 representado por v\u00e1rios deputados.<\/li><\/ul><\/li>
      • Muitos para Muitos<\/strong>: s\u00e3o s\u00f3 dados que se repetem em ambas as tabelas, isto \u00e9, a tabela A contem varias equival\u00eancias na tabela B, e a tabela B tem vairas equival\u00eancias na tabela A.<\/em> Esse tipo de Cardinalidade gera repeti\u00e7\u00e3o dos dados, uma vez que a jun\u00e7\u00e3o feita importa cada um dos pares de equival\u00eancia, por isso, ela deve ser usada com cuidado. Alguns exemplos desse tipo de rela\u00e7\u00e3o:
        • Uma pessoa pode ter mais de um endere\u00e7o de entrega para suas encomendas, e um mesmo endere\u00e7o pode receber encomenda de v\u00e1rias pessoas.<\/li>
        • Um vendedor pode vender v\u00e1rios produtos, e um mesmo produto pode ser vendido por v\u00e1rios vendedores.<\/li>
        • Uma crian\u00e7a pode ter mais de um respons\u00e1vel legal, e uma pessoa pode ter responsabilidade sobre varias crian\u00e7as.<\/li><\/ul><\/li><\/ul>\n\n\n\n

          Auto-jun\u00e7\u00e3o<\/h2>\n\n\n\n

          O Zoho Analytics tem um sistema pr\u00f3prio para a jun\u00e7\u00e3o das colunas chamado auto-jun\u00e7\u00e3o<\/strong>. Esse tipo de jun\u00e7\u00e3o pode ser efetuada de forma simples e r\u00e1pida, como descrita aqui<\/a>. Uma vez que a rela\u00e7\u00e3o est\u00e1 estabelecida no sistema, colunas de diferentes tabelas podem ser utilizadas para an\u00e1lise nos relat\u00f3rios. Nesse tipo de jun\u00e7\u00e3o, \u00e9 importante ressaltar que se realiza uma jun\u00e7\u00e3o \u00e0 esquerda<\/strong>, isto \u00e9, mant\u00eam-se todos os dados da tabela filha (\u00e0 esquerda) e apenas os dados com equival\u00eancia da tabela m\u00e3e( \u00e0 direita)<\/strong>. A auto-jun\u00e7\u00e3o tem suporte para jun\u00e7\u00e3o \u00e0 direita tamb\u00e9m.<\/p>\n\n\n\n

          Consultas<\/h2>\n\n\n\n

          Uma outra forma de relacionar os dados de das tabelas diferentes \u00e9 utilizando as chamadas Tabelas de consulta (query tables<\/em>). Esse tipo de jun\u00e7\u00e3o \u00e9 feita usando a sintaxe SQL SELECT<\/em><\/strong>, gerando uma tabela com os dados importados de acordo com a jun\u00e7\u00e3o estabelecida. As tabelas de consultas s\u00e3o muito utilizadas dada a familiaridade dos usu\u00e1rios com a linguagem SQL SELECT e a alta versatilidade a respeito da modelagem dos dados. Um tutorial para esse tipo de processo pode ser encontrado aqui.<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"

          A maneira mais comum de se armazenar dados hoje em dia \u00e9 por tabelas. Usualmente, esses dados s\u00e3o armazenados de forma que cada tabela cont\u00eam um conjunto de dados de um mesmo contexto e uma coluna que permite interliga-la com outras tabelas. Esse tipo de modelo para bases de dados \u00e9 chamado de Modelo Relacional, […]<\/p>\n","protected":false},"author":13,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-4794","post","type-post","status-publish","format-standard","hentry","category-zoho-analytics","entry"],"_links":{"self":[{"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/posts\/4794","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/comments?post=4794"}],"version-history":[{"count":1,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/posts\/4794\/revisions"}],"predecessor-version":[{"id":4795,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/posts\/4794\/revisions\/4795"}],"wp:attachment":[{"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/media?parent=4794"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/categories?post=4794"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outsmart.com.br\/wp-json\/wp\/v2\/tags?post=4794"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}