Código Natural/Identificação taxonômica: mudanças entre as edições
m (→Caso de uso ilustrativo: add Other) |
mSem resumo de edição |
||
Linha 1: | Linha 1: | ||
Identificadores únicos, tais como [https://www.postgresql.org/docs/current/functions-sequence.html contadores sequenciais em bases de dados], são fundamentais para a indexação e controle de registros. O ideal, todavia, é que esse identificador traga embutida alguma informação relativa à taxonomia da entidade identificada. Isso porque '''os identificadores de grupos taxonômicos também precisam ser únicos e padronizados'''. | Identificadores únicos, tais como [https://www.postgresql.org/docs/current/functions-sequence.html contadores sequenciais em bases de dados], são fundamentais para a indexação e controle de registros. O ideal, todavia, é que esse identificador traga embutida alguma informação relativa à taxonomia da entidade identificada. Isso porque '''os identificadores de grupos taxonômicos também precisam ser únicos e padronizados'''. | ||
Neste artigo trazemos a aprimoração e a Gestão de Registros e de Indexação com Identificadores Únicos! Imagine um mundo onde o gerenciamento eficaz de registros e a indexação em bases de dados se tornam simples e eficientes. Isso é possível através da utilização estratégica de identificadores únicos. Mas a chave real para o sucesso está na integração inteligente de informações relacionadas à taxonomia da entidade identificada, dentro desses identificadores. | |||
Elucidamos a verdadeira vantagem dessa abordagem - especialmente quando aplicada aos identificadores ligados a grupos taxonômicos. Aqui, a singularidade e a padronização emergem como imperativos. Ao enriquecer esses identificadores com um contexto taxonômico rico, não apenas a precisão da indexação se eleva, mas também a coesão de toda a estrutura de dados | |||
==Taxonomias bit a bit== | ==Taxonomias bit a bit== | ||
[[arquivo:KraEtAll2019-fig01-apples.png|thumb|280px|Códigos binários identificando frutas individuais e sua taxonomia: laranja, maçã vermelha e maçã verde.]] | [[arquivo:KraEtAll2019-fig01-apples.png|thumb|280px|Códigos binários identificando frutas individuais e sua taxonomia: laranja, maçã vermelha e maçã verde.]] | ||
A ilustração do conjunto de frutas ajuda a entender os agrupamentos ([https://schema.org/Taxon taxons]). | |||
A cada prefixo pode-se expressar uma regra. Por exemplo: | A cada prefixo pode-se expressar uma regra. Por exemplo: | ||
*Primeiro bit do ID: define se é laranja (1) ou maçã (0). <br />Os conjuntos ''L'' dos identificadores de laranjas e ''M'' das maçãs da ilustração ao lado são definidos por: <math>L=\{1, 10\}</math> e <math>M=\{0, 00, 000, 01, 010, 011\}</math>. | *Primeiro bit do ID: define se é laranja (1) ou maçã (0). <br />Os conjuntos ''L'' dos identificadores de laranjas e ''M'' das maçãs da ilustração ao lado são definidos por: <math>L=\{1, 10\}</math> e <math>M=\{0, 00, 000, 01, 010, 011\}</math>. | ||
*Primeiro bit do ID de maçã: especializa como vermelha (0) ou verde (1). Portanto IDs com prefixos "00" (maçã ''red''), "01" (maçã ''green'') e "0" para maçã genérica. Daí rotular uma maçã com ID "0" é uma falha, é um código exclusivo de taxon. <br />Os conjuntos ''R'' dos identificadores de maçãs ''red'' e ''G'' das maçãs ''green'' da ilustração ao lado são definidos por: <math>R=\{0, 00, 000\} \subset M</math> e <math>G=\{01, 010, 011\} \subset M</math>. Ambos subconjuntos de ''M'', estabelecendo portanto uma hierarquia taxonômica entre as maçãs. | *Primeiro bit do ID de maçã: especializa como vermelha (0) ou verde (1). Portanto IDs com prefixos "00" (maçã ''red''), "01" (maçã ''green'') e "0" para maçã genérica. Daí rotular uma maçã com ID "0" é uma falha, é um código exclusivo de taxon. <br />Os conjuntos ''R'' dos identificadores de maçãs ''red'' e ''G'' das maçãs ''green'' da ilustração ao lado são definidos por: <math>R=\{0, 00, 000\} \subset M</math> e <math>G=\{01, 010, 011\} \subset M</math>. Ambos subconjuntos de ''M'', estabelecendo portanto uma hierarquia taxonômica entre as maçãs. | ||
Linha 13: | Linha 17: | ||
Os identificadores de frutas são livres, podem ter qualquer quantidade de bits, podem ter tamanho fixo ou variável, e não precisam percorrer uma sequência especial. '''A taxonomia só impõe a existência de prefixos e regras de interpretação para esses prefixos'''. | Os identificadores de frutas são livres, podem ter qualquer quantidade de bits, podem ter tamanho fixo ou variável, e não precisam percorrer uma sequência especial. '''A taxonomia só impõe a existência de prefixos e regras de interpretação para esses prefixos'''. | ||
A sintaxe geral da cadeia de bits é simples: "<code>$prefixo$contador</code>". Com as variáveis ''prefixo'' e ''contador'', tendo apenas o ''prefixo'' um comprimento definido pelas regras taxonômicas. | A sintaxe geral da cadeia de bits é simples: "<code>$prefixo$contador</code>". Com as variáveis ''prefixo'' e ''contador'', tendo apenas o ''prefixo'' um comprimento definido pelas regras taxonômicas. Por exemplo no ID ilustrado da maçã verde <code>010</code>, o ''prefixo'' é <code>01</code> e o ''contador'' é <code>0</code>. | ||
[[Arquivo:NatCod-Taxons-p1.png|centro|480px]] | [[Arquivo:NatCod-Taxons-p1.png|centro|480px]] | ||
Linha 26: | Linha 30: | ||
Se a taxonomia é sujeita a modificações, podemos '''reservar mais bits para cada um dos grupos taxonômicos''' (''taxons''). | Se a taxonomia é sujeita a modificações, podemos '''reservar mais bits para cada um dos grupos taxonômicos''' (''taxons''). | ||
No exemplo poderíamos no futuro '''distinguir laranjas''', entre ''comuns'' e ''avermelhadas''. Todas elas com prefixo <code>1</code> mas reservando mais bits para futuras diferenciações: duas estratégias são possíveis: | No exemplo poderíamos no futuro '''distinguir laranjas''', entre ''comuns'' e ''avermelhadas''. Todas elas com prefixo <code>1</code> mas reservando mais bits para futuras diferenciações: duas estratégias são possíveis: | ||
*Se as existentes são comuns, batizamos elas de <code>10</code> e reservamos <code>11</code> para as avermelhadas. Não fica nenhuma reserva de segurança. | *Se as existentes são comuns, batizamos elas de <code>10</code> e reservamos <code>11</code> para as avermelhadas. Não fica nenhuma reserva de segurança. | ||
Linha 37: | Linha 41: | ||
Na sintaxe "<code>$prefixo$contador</code>", '''o prefixo é necessariamente um código''' e a contagem para identificação dos taxons é '''necessariamente lexicográfica'''. Ver função ''hsucc'' em [https://github.com/osm-codes/NaturalCodes/blob/main/src/step01def-lib_NatCod.sql step01def-lib_NatCod.sql]. Exemplos: | Na sintaxe "<code>$prefixo$contador</code>", '''o prefixo é necessariamente um código''' e a contagem para identificação dos taxons é '''necessariamente lexicográfica'''. Ver função ''hsucc'' em [https://github.com/osm-codes/NaturalCodes/blob/main/src/step01def-lib_NatCod.sql step01def-lib_NatCod.sql]. Exemplos: | ||
*Dois taxons requerem no mínimo 1 bit. O primeiro é ''hsucc''("")="0", o segundo é seu sucessor, ''hsucc''("0")="1". | * Dois taxons requerem no mínimo 1 bit. O primeiro é ''hsucc''("")="0", o segundo é seu sucessor, ''hsucc''("0")="1". | ||
*Dois taxons com reserva de 2 bits, requerindo portanto 3 bits. Com reserva balanceada: taxons "001" e "101". | *Dois taxons com reserva de 2 bits, requerindo portanto 3 bits. Com reserva balanceada: taxons "001" e "101". | ||
*Três taxons e todos com até 5 subtaxons cada. Pode-se adotar um prefixo de 2 bits fixos para os pais, mais dois variáveis para os filhos, ou balancear valores de zero a 3*5=15 entre 4 ou mais bits. | *Três taxons e todos com até 5 subtaxons cada. Pode-se adotar um prefixo de 2 bits fixos para os pais, mais dois variáveis para os filhos, ou balancear valores de zero a 3*5=15 entre 4 ou mais bits. | ||
Linha 46: | Linha 50: | ||
Sendo um número, podemos calcular o sucessor <code>succ($contador)</code> através da aritmética usual, <code>$contador+1</code>. | Sendo um número, podemos calcular o sucessor <code>succ($contador)</code> através da aritmética usual, <code>$contador+1</code>. | ||
=== Contadores lexicográficos=== | ===Contadores lexicográficos=== | ||
Na sintaxe "<code>$prefixo$contador</code>", o contador pode ser mantido como código. | Na sintaxe "<code>$prefixo$contador</code>", o contador pode ser mantido como código. | ||
Sendo um código, podemos calcular <code>succ($contador)</code> através do "sucessor lexicográfico" (também denominado "hierarchical successor"). Ver função ''hsucc'' em [https://github.com/osm-codes/NaturalCodes/blob/main/src/step01def-lib_NatCod.sql step01def-lib_NatCod.sql]. | Sendo um código, podemos calcular <code>succ($contador)</code> através do "sucessor lexicográfico" (também denominado "hierarchical successor"). Ver função ''hsucc'' em [https://github.com/osm-codes/NaturalCodes/blob/main/src/step01def-lib_NatCod.sql step01def-lib_NatCod.sql]. | ||
==Taxonomias Base N == | ==Taxonomias Base N== | ||
[[Arquivo:KraEtAll2019-fig03-new-bitsBase4.png|thumb|220px|Reserving 2 bits for all taxon-prefixes, and later representation in Base4h.]] | [[Arquivo:KraEtAll2019-fig03-new-bitsBase4.png|thumb|220px|Reserving 2 bits for all taxon-prefixes, and later representation in Base4h.]] | ||
<!-- | <!-- | ||
Linha 63: | Linha 67: | ||
[[Arquivo:KraEtAll2019-fig15-GreenApples.png|thumb|220px|''Green apples'', IDs na Base4h.]] | [[Arquivo:KraEtAll2019-fig15-GreenApples.png|thumb|220px|''Green apples'', IDs na Base4h.]] | ||
A conversão para Base4h resulta na segunda coluna da tabela abaixo, com prefixos em negrito, e conjunto "Green apples" ilustrado. | A conversão para [[Base4h]] resulta na segunda coluna da tabela abaixo, com prefixos em negrito, e conjunto "Green apples" ilustrado. | ||
:{| class="wikitable" | :{| class="wikitable" | ||
|'''Base2h''' | |'''Base2h''' | ||
|'''Base4h''' | |'''Base4h''' | ||
|'''''Taxon''''' | |'''''Taxon''''' | ||
|- | |- | ||
|00||'''0'''||Red Apple (illustrated) | |00 || '''0''' ||Red Apple (illustrated) | ||
|- | |- | ||
|000||'''0'''G|| Red Apple (illustrated) | |000||'''0'''G||Red Apple (illustrated) | ||
|- | |- | ||
|0000||'''0'''0||Red Apple (illustrated) | |0000||'''0'''0|| Red Apple (illustrated) | ||
|- | |- | ||
|0001101||'''0'''12Q||Red Apple | |0001101||'''0'''12Q||Red Apple | ||
|- | |- | ||
|0010101||'''0'''22Q||Red Apple | |0010101 || '''0'''22Q||Red Apple | ||
|- | |- | ||
|01||'''1'''||Green apple (illustrated) | |01 ||'''1'''||Green apple (illustrated) | ||
|- | |- | ||
|0101||'''1'''1||Green apple | |0101||'''1'''1 ||Green apple | ||
|- | |- | ||
|010||'''1'''G||Green apple (illustrated) | |010||'''1'''G|| Green apple (illustrated) | ||
|- | |- | ||
|011||'''1'''Q||Green apple (illustrated) | | 011 ||'''1'''Q ||Green apple (illustrated) | ||
|- | |- | ||
|10||'''2'''||Organge (illustrated) | |10||'''2'''|| Organge (illustrated) | ||
|- | |- | ||
|10101||'''2'''2Q||Organge | |10101||'''2'''2Q||Organge | ||
|- | |- | ||
|1011||'''2'''3||Organge | | 1011||'''2'''3||Organge | ||
|- | |- | ||
|101||'''2'''Q||Organge (illustrated) | | 101||'''2'''Q||Organge (illustrated) | ||
|} | |} | ||
=== Atribuição dos IDs dentro de uma taxonomia === | ===Atribuição dos IDs dentro de uma taxonomia === | ||
[[Arquivo:NatCod-taxon-ilustraSetsB4h.png|centro|semmoldura| | Supor que a partir de ''k'' bits, digamos ''k''=4, seja possível destacar prefixos válidos para conjuntos e subconjuntos alinhados. | ||
[[Arquivo:NatCod-taxon-ilustraSetsB4h.png|centro|semmoldura|480px]] | |||
Imaginemos o caso de uma pequena ''loja de departamentos'', que começou por organizar os produtos mais vendidos: frutas e roupas. Entre as frutas, as mais vendidas são as maçãs, e entre as roupas, os jeans, as camisetas e alguns tipos de roupa feminina. | Imaginemos o caso de uma pequena ''loja de departamentos'', que começou por organizar os produtos mais vendidos: frutas e roupas. Entre as frutas, as mais vendidas são as maçãs, e entre as roupas, os jeans, as camisetas e alguns tipos de roupa feminina. | ||
Linha 105: | Linha 112: | ||
Cada uma dessas ''classes de produtos'' foi destacado abaixo num diagrama de conjuntos, e os prefixos eleitos indicados no ponto interior mais à esquerda de cada conjunto. No ponto interior mais à direita, o limite superior que uma ''instância'' daquela classe de produto pode receber como identificador único. | Cada uma dessas ''classes de produtos'' foi destacado abaixo num diagrama de conjuntos, e os prefixos eleitos indicados no ponto interior mais à esquerda de cada conjunto. No ponto interior mais à direita, o limite superior que uma ''instância'' daquela classe de produto pode receber como identificador único. | ||
Maçãs vermelhas | [[Arquivo:NatCod-taxon-produtos1.png|centro|miniaturadaimagem|680px|Códigos Naturais de 11 bits na base 4h: de <code>0</code> até <code>33333Q</code>, identificando produtos.<br /> | ||
Futas: prefixo <code>0</code>. Roupas: prefixo <code>3</code>. Demais produtos: prefixos <code>1</code> e <code>2</code> disponíveis. Maçãs: prefixo <code>00</code>. Demais frutas: prefixos <code>01</code>, <code>02</code> e <code>03</code> disponíveis.<br /> Maçãs vermelhas, prefixo <code>000</code>; maçãs verdes, prefixo <code>001</code>. Roupas de mulher, prefixo <code>30</code>: vestidos <code>300</code>; camisas femininas <code>302</code>. Demais roupas: camisetas, prefixo <code>31</code>; e jeans prefixo <code>32</code>. <br />Cada maçã vermelha recebe um ID no intervalo <code>000</code> até <code>00033Q</code>; cada maçã verde de <code>001</code> até <code>00133Q</code>; ...; cada jeans de <code>32</code> até <code>32333Q</code>.]] | |||
Neste cenário, no inventário inicial foram suficientes 11 bits para identificar todos os produtos com seus prefixos. Por exemplo os IDs das maçãs vermelhas ficaram no intervalo <code>000</code> até <code>00033Q</code>, e as maçãs verdes de <code>001</code> até <code>00133Q</code>. Abaixo ilustrando ao invés das classes algumas instâncias de produtos, cada qual com seu ID, e a posição do ID na "régua base 4h". Para destacar classe e contador foi adotada a notação com ponto separador. Por exemplo a maçã verde com ID=<code>00133</code> pode ser destacada como <code>001.33</code>. Ela vem depois da maçã <code>001.0</code> e bem antes por exemplo do jeans <code>32.101</code>. Todos ficam | |||
[[Arquivo:NatCod-taxons-InstanceIntervals1.png|centro|semmoldura|580x580px]] | |||
A ampliação do banco de dados, adotando o dobro, 22 bits, acarretou a ampliação do intervalo da mesma classe, seus IDs passaram a ser de <code>000</code> até <code>00033333333</code>. '''O aumento de bits não afeta os identificadores''', apenas amplia a possibilidade de incluir mais produtos dentro da mesma classe. | |||
==Identificadores sem contador== | ==Identificadores sem contador== | ||
Linha 140: | Linha 146: | ||
*modelagem em [[wikipedia:Class diagram|diagramas de classe UML]]: onde podem ser destacadas as semânticas de relacionamento geral-específico, parte-todo e classe-instência; assim como o relacionamento entre diferentes tipos de identificador (ex. como o ID de cliente se relaciona com o ID de produto). | *modelagem em [[wikipedia:Class diagram|diagramas de classe UML]]: onde podem ser destacadas as semânticas de relacionamento geral-específico, parte-todo e classe-instência; assim como o relacionamento entre diferentes tipos de identificador (ex. como o ID de cliente se relaciona com o ID de produto). | ||
*modelos de [[wikipedia:Data lineage|linhagem dos dados]]: ''dataflows'' ou similares indicando os dados no sistema origem e no sistema onde os IDs estão sendo controlados, garantido por exemplo que [[wikipedia:Golden record (informatics)|''Golden records'']] estejam usando os IDs da forma planejada. | * modelos de [[wikipedia:Data lineage|linhagem dos dados]]: ''dataflows'' ou similares indicando os dados no sistema origem e no sistema onde os IDs estão sendo controlados, garantido por exemplo que [[wikipedia:Golden record (informatics)|''Golden records'']] estejam usando os IDs da forma planejada. | ||
Tecnicamente os IDs são [[códigos naturais]] e as classes das instâncias que os IDs representam estão codificadas como prefixos binários, seguindo o modelo prefixo-contador descrito nas seções acima. | Tecnicamente os IDs são [[códigos naturais]] e as classes das instâncias que os IDs representam estão codificadas como prefixos binários, seguindo o modelo prefixo-contador descrito nas seções acima. | ||
Linha 156: | Linha 162: | ||
O primeiro passo nesse caso é estabelecer em UML qual a estratégia semântica de unificação. Pode-se optar por exemplo por não misturar B2C com B2B, e optar por classificar os clientes B2B conforme o o primeiro e segundo níveis do padrão SchemaOrg, ou seja, conforme [https://schema.org/Organization sch:Organization]. Optou-se também por adotar, como medida de apoio à transição do ID convencional (inteiro de 32 bits) para o [[Código_natural/Representação_interna#Cache-length_strategy|hInt de 64 bits]], a classe Other. Nela os clientes com cadastro indefinido ou onde caberiam outras classificações, ficam de "quarentena". | O primeiro passo nesse caso é estabelecer em UML qual a estratégia semântica de unificação. Pode-se optar por exemplo por não misturar B2C com B2B, e optar por classificar os clientes B2B conforme o o primeiro e segundo níveis do padrão SchemaOrg, ou seja, conforme [https://schema.org/Organization sch:Organization]. Optou-se também por adotar, como medida de apoio à transição do ID convencional (inteiro de 32 bits) para o [[Código_natural/Representação_interna#Cache-length_strategy|hInt de 64 bits]], a classe Other. Nela os clientes com cadastro indefinido ou onde caberiam outras classificações, ficam de "quarentena". | ||
* [https://schema.org/Airline Airline] | *[https://schema.org/Airline Airline] | ||
* [https://schema.org/Consortium Consortium] | *[https://schema.org/Consortium Consortium] | ||
* [https://schema.org/Corporation Corporation] | *[https://schema.org/Corporation Corporation] | ||
* [https://schema.org/EducationalOrganization EducationalOrganization] | *[https://schema.org/EducationalOrganization EducationalOrganization] | ||
* [https://schema.org/FundingScheme FundingScheme] | *[https://schema.org/FundingScheme FundingScheme] | ||
* [https://schema.org/GovernmentOrganization GovernmentOrganization] | * [https://schema.org/GovernmentOrganization GovernmentOrganization] | ||
* [https://schema.org/LibrarySystem LibrarySystem] | *[https://schema.org/LibrarySystem LibrarySystem] | ||
* [https://schema.org/LocalBusiness LocalBusiness] | *[https://schema.org/LocalBusiness LocalBusiness] | ||
** [https://schema.org/AnimalShelter AnimalShelter] | **[https://schema.org/AnimalShelter AnimalShelter] | ||
** [https://schema.org/ArchiveOrganization ArchiveOrganization] | **[https://schema.org/ArchiveOrganization ArchiveOrganization] | ||
** [https://schema.org/AutomotiveBusiness AutomotiveBusiness] | **[https://schema.org/AutomotiveBusiness AutomotiveBusiness] | ||
** [https://schema.org/ChildCare ChildCare] | **[https://schema.org/ChildCare ChildCare] | ||
** [https://schema.org/DryCleaningOrLaundry DryCleaningOrLaundry] | **[https://schema.org/DryCleaningOrLaundry DryCleaningOrLaundry] | ||
** [https://schema.org/EmergencyService EmergencyService] | **[https://schema.org/EmergencyService EmergencyService] | ||
** [https://schema.org/EmploymentAgency EmploymentAgency] | **[https://schema.org/EmploymentAgency EmploymentAgency] | ||
** [https://schema.org/EntertainmentBusiness EntertainmentBusiness] | **[https://schema.org/EntertainmentBusiness EntertainmentBusiness] | ||
** [https://schema.org/FinancialService FinancialService] | **[https://schema.org/FinancialService FinancialService] | ||
** [https://schema.org/FoodEstablishment FoodEstablishment] | **[https://schema.org/FoodEstablishment FoodEstablishment] | ||
** [https://schema.org/GovernmentOffice GovernmentOffice] | **[https://schema.org/GovernmentOffice GovernmentOffice] | ||
** [https://schema.org/HealthAndBeautyBusiness HealthAndBeautyBusiness] | ** [https://schema.org/HealthAndBeautyBusiness HealthAndBeautyBusiness] | ||
** [https://schema.org/HomeAndConstructionBusiness HomeAndConstructionBusiness] | **[https://schema.org/HomeAndConstructionBusiness HomeAndConstructionBusiness] | ||
** [https://schema.org/InternetCafe InternetCafe] | **[https://schema.org/InternetCafe InternetCafe] | ||
** [https://schema.org/LegalService LegalService] | **[https://schema.org/LegalService LegalService] | ||
** [https://schema.org/Library Library] | **[https://schema.org/Library Library] | ||
** [https://schema.org/LodgingBusiness LodgingBusiness] | **[https://schema.org/LodgingBusiness LodgingBusiness] | ||
** [https://schema.org/MedicalBusiness MedicalBusiness] | **[https://schema.org/MedicalBusiness MedicalBusiness] | ||
** [https://schema.org/ProfessionalService ProfessionalService] | **[https://schema.org/ProfessionalService ProfessionalService] | ||
** [https://schema.org/RadioStation RadioStation] | **[https://schema.org/RadioStation RadioStation] | ||
** [https://schema.org/RealEstateAgent RealEstateAgent] | **[https://schema.org/RealEstateAgent RealEstateAgent] | ||
** [https://schema.org/RecyclingCenter RecyclingCenter] | **[https://schema.org/RecyclingCenter RecyclingCenter] | ||
** [https://schema.org/SelfStorage SelfStorage] | **[https://schema.org/SelfStorage SelfStorage] | ||
** [https://schema.org/ShoppingCenter ShoppingCenter] | **[https://schema.org/ShoppingCenter ShoppingCenter] | ||
** [https://schema.org/SportsActivityLocation SportsActivityLocation] | **[https://schema.org/SportsActivityLocation SportsActivityLocation] | ||
** [https://schema.org/Store Store] | **[https://schema.org/Store Store] | ||
** [https://schema.org/TelevisionStation TelevisionStation] | **[https://schema.org/TelevisionStation TelevisionStation] | ||
** [https://schema.org/TouristInformationCenter TouristInformationCenter] | **[https://schema.org/TouristInformationCenter TouristInformationCenter] | ||
** [https://schema.org/TravelAgency TravelAgency] | **[https://schema.org/TravelAgency TravelAgency] | ||
* [https://schema.org/MedicalOrganization MedicalOrganization] | *[https://schema.org/MedicalOrganization MedicalOrganization] | ||
** [https://schema.org/Dentist Dentist] | **[https://schema.org/Dentist Dentist] | ||
** [https://schema.org/DiagnosticLab DiagnosticLab] | **[https://schema.org/DiagnosticLab DiagnosticLab] | ||
** [https://schema.org/Hospital Hospital] | **[https://schema.org/Hospital Hospital] | ||
** [https://schema.org/MedicalClinic MedicalClinic] | **[https://schema.org/MedicalClinic MedicalClinic] | ||
** [https://schema.org/Pharmacy Pharmacy] | **[https://schema.org/Pharmacy Pharmacy] | ||
** [https://schema.org/Physician Physician] | **[https://schema.org/Physician Physician] | ||
** [https://schema.org/VeterinaryCare VeterinaryCare] | **[https://schema.org/VeterinaryCare VeterinaryCare] | ||
* [https://schema.org/NGO NGO] | *[https://schema.org/NGO NGO] | ||
* [https://schema.org/NewsMediaOrganization NewsMediaOrganization] | *[https://schema.org/NewsMediaOrganization NewsMediaOrganization] | ||
* [https://schema.org/OnlineBusiness OnlineBusiness] | *[https://schema.org/OnlineBusiness OnlineBusiness] | ||
** [https://schema.org/OnlineStore OnlineStore] | **[https://schema.org/OnlineStore OnlineStore] | ||
* [https://schema.org/PerformingGroup PerformingGroup] | *[https://schema.org/PerformingGroup PerformingGroup] | ||
** [https://schema.org/DanceGroup DanceGroup] | **[https://schema.org/DanceGroup DanceGroup] | ||
** [https://schema.org/MusicGroup MusicGroup] | **[https://schema.org/MusicGroup MusicGroup] | ||
** [https://schema.org/TheaterGroup TheaterGroup] | **[https://schema.org/TheaterGroup TheaterGroup] | ||
* [https://schema.org/PoliticalParty PoliticalParty] | * [https://schema.org/PoliticalParty PoliticalParty] | ||
* [https://schema.org/Project Project] | *[https://schema.org/Project Project] | ||
** [https://schema.org/FundingAgency FundingAgency] | **[https://schema.org/FundingAgency FundingAgency] | ||
** [https://schema.org/ResearchProject ResearchProject] | **[https://schema.org/ResearchProject ResearchProject] | ||
* [https://schema.org/ResearchOrganization ResearchOrganization] | *[https://schema.org/ResearchOrganization ResearchOrganization] | ||
* [https://schema.org/SearchRescueOrganization SearchRescueOrganization] | *[https://schema.org/SearchRescueOrganization SearchRescueOrganization] | ||
* [https://schema.org/SportsOrganization SportsOrganization] | *[https://schema.org/SportsOrganization SportsOrganization] | ||
** [https://schema.org/SportsTeam SportsTeam] | **[https://schema.org/SportsTeam SportsTeam] | ||
* [https://schema.org/WorkersUnion WorkersUnion] | *[https://schema.org/WorkersUnion WorkersUnion] | ||
* [https://schema.org/WorkersUnion WorkersUnion] | *[https://schema.org/WorkersUnion WorkersUnion] | ||
* ... (outras classificações, ausentes no SchemaOrg, podem ser obtidas ou criadas na Wikidata) | *... (outras classificações, ausentes no SchemaOrg, podem ser obtidas ou criadas na Wikidata) | ||
* Other (classe '''temporária''' para a gestão de cadastros incompletos) | *Other (classe '''temporária''' para a gestão de cadastros incompletos) | ||
Devido à ambiguidade nos domínios, a empresa precisa definir qual a subclasse canônica, quando o SchemaOrg oferecer mais de uma alternativa. Por exemplo "Dentist" pode ser subclasse de "LocalBusiness" ou de "MedicalOrganization", no exemplo foi adotada a classe "MedicalOrganization". | Devido à ambiguidade nos domínios, a empresa precisa definir qual a subclasse canônica, quando o SchemaOrg oferecer mais de uma alternativa. Por exemplo "Dentist" pode ser subclasse de "LocalBusiness" ou de "MedicalOrganization", no exemplo foi adotada a classe "MedicalOrganization". |
Edição das 17h12min de 7 de agosto de 2023
Identificadores únicos, tais como contadores sequenciais em bases de dados, são fundamentais para a indexação e controle de registros. O ideal, todavia, é que esse identificador traga embutida alguma informação relativa à taxonomia da entidade identificada. Isso porque os identificadores de grupos taxonômicos também precisam ser únicos e padronizados.
Neste artigo trazemos a aprimoração e a Gestão de Registros e de Indexação com Identificadores Únicos! Imagine um mundo onde o gerenciamento eficaz de registros e a indexação em bases de dados se tornam simples e eficientes. Isso é possível através da utilização estratégica de identificadores únicos. Mas a chave real para o sucesso está na integração inteligente de informações relacionadas à taxonomia da entidade identificada, dentro desses identificadores.
Elucidamos a verdadeira vantagem dessa abordagem - especialmente quando aplicada aos identificadores ligados a grupos taxonômicos. Aqui, a singularidade e a padronização emergem como imperativos. Ao enriquecer esses identificadores com um contexto taxonômico rico, não apenas a precisão da indexação se eleva, mas também a coesão de toda a estrutura de dados
Taxonomias bit a bit
A ilustração do conjunto de frutas ajuda a entender os agrupamentos (taxons). A cada prefixo pode-se expressar uma regra. Por exemplo:
- Primeiro bit do ID: define se é laranja (1) ou maçã (0).
Os conjuntos L dos identificadores de laranjas e M das maçãs da ilustração ao lado são definidos por: e .
- Primeiro bit do ID de maçã: especializa como vermelha (0) ou verde (1). Portanto IDs com prefixos "00" (maçã red), "01" (maçã green) e "0" para maçã genérica. Daí rotular uma maçã com ID "0" é uma falha, é um código exclusivo de taxon.
Os conjuntos R dos identificadores de maçãs red e G das maçãs green da ilustração ao lado são definidos por: e . Ambos subconjuntos de M, estabelecendo portanto uma hierarquia taxonômica entre as maçãs.
Os identificadores de frutas são livres, podem ter qualquer quantidade de bits, podem ter tamanho fixo ou variável, e não precisam percorrer uma sequência especial. A taxonomia só impõe a existência de prefixos e regras de interpretação para esses prefixos.
A sintaxe geral da cadeia de bits é simples: "$prefixo$contador
". Com as variáveis prefixo e contador, tendo apenas o prefixo um comprimento definido pelas regras taxonômicas. Por exemplo no ID ilustrado da maçã verde 010
, o prefixo é 01
e o contador é 0
.
Se o conjunto dos identificadores de fruta for ordenado lexicograficamente (preorder), cada taxon corresponderá a um único intervalo. Lembrando que os taxons são os "ramos da árvore taxonômica", associados aos prefixos. Na ilustração os IDs de maçã estão no intervalo 0
até 011
, o subconjunto das maçãs verdes no subintervalo 01
até 011
, e os IDs de laranja de 1
até 111
.
Como boa prática para identificação pode-se evitar IDs com contador vazio: os IDs da ilustração saltam os códigos 0
, 1
e 01
.
Reserva de bits para o prefixo do contador
No exemplo acima as laranjas fizeram uso de um prefixo de apenas 1 bit e as maçãs uso de um prefixo de 2 bits.
Se a taxonomia é sujeita a modificações, podemos reservar mais bits para cada um dos grupos taxonômicos (taxons).
No exemplo poderíamos no futuro distinguir laranjas, entre comuns e avermelhadas. Todas elas com prefixo 1
mas reservando mais bits para futuras diferenciações: duas estratégias são possíveis:
- Se as existentes são comuns, batizamos elas de
10
e reservamos11
para as avermelhadas. Não fica nenhuma reserva de segurança.
- Se as existentes são misturadas, batizamos a mistura de
100
e reservamos101
para as identificadas como comuns e110
para as avermelhadas; ficando ainda a reserva111
para outra eventual variedade de laranja.
Quanto maior o risco de uma futura diferenciação, maior a demanda por reserva.
Prefixos lexicográficos
Na sintaxe "$prefixo$contador
", o prefixo é necessariamente um código e a contagem para identificação dos taxons é necessariamente lexicográfica. Ver função hsucc em step01def-lib_NatCod.sql. Exemplos:
- Dois taxons requerem no mínimo 1 bit. O primeiro é hsucc("")="0", o segundo é seu sucessor, hsucc("0")="1".
- Dois taxons com reserva de 2 bits, requerindo portanto 3 bits. Com reserva balanceada: taxons "001" e "101".
- Três taxons e todos com até 5 subtaxons cada. Pode-se adotar um prefixo de 2 bits fixos para os pais, mais dois variáveis para os filhos, ou balancear valores de zero a 3*5=15 entre 4 ou mais bits.
Contadores numéricos
Na sintaxe "$prefixo$contador
", o contador pode ser representado como número. Computacionalmente o ID é um código, seu prefixo um código, e por fim o contador, depois de isolado (ainda como código) pode sofrer cast para um número inteiro positivo.
Sendo um número, podemos calcular o sucessor succ($contador)
através da aritmética usual, $contador+1
.
Contadores lexicográficos
Na sintaxe "$prefixo$contador
", o contador pode ser mantido como código.
Sendo um código, podemos calcular succ($contador)
através do "sucessor lexicográfico" (também denominado "hierarchical successor"). Ver função hsucc em step01def-lib_NatCod.sql.
Taxonomias Base N
O caso mais simples é a Base4, com dígitos de 2 bits. É necessário então reservar no mínimo 2 bits para a taxonomia. Aqui adotamos a estratégia de reserva de apenas um bit para a diferenciação das laranjas, e mais um bit para a diferenciação das maçãs.
A conversão para Base4h resulta na segunda coluna da tabela abaixo, com prefixos em negrito, e conjunto "Green apples" ilustrado.
Base2h Base4h Taxon 00 0 Red Apple (illustrated) 000 0G Red Apple (illustrated) 0000 00 Red Apple (illustrated) 0001101 012Q Red Apple 0010101 022Q Red Apple 01 1 Green apple (illustrated) 0101 11 Green apple 010 1G Green apple (illustrated) 011 1Q Green apple (illustrated) 10 2 Organge (illustrated) 10101 22Q Organge 1011 23 Organge 101 2Q Organge (illustrated)
Atribuição dos IDs dentro de uma taxonomia
Supor que a partir de k bits, digamos k=4, seja possível destacar prefixos válidos para conjuntos e subconjuntos alinhados.
Imaginemos o caso de uma pequena loja de departamentos, que começou por organizar os produtos mais vendidos: frutas e roupas. Entre as frutas, as mais vendidas são as maçãs, e entre as roupas, os jeans, as camisetas e alguns tipos de roupa feminina.
Olhando para a "régua base 4h" acima decidimos que frutas ficarão todas com o prefixo 0
, sendo as maçãs com 00
e as demais frutas com prefixos 01
, 02
e 03
. Os prefixos 1 e 2
ficam reservados a outros produtos, e o prefixo 3
ficou com as roupas.
Cada uma dessas classes de produtos foi destacado abaixo num diagrama de conjuntos, e os prefixos eleitos indicados no ponto interior mais à esquerda de cada conjunto. No ponto interior mais à direita, o limite superior que uma instância daquela classe de produto pode receber como identificador único.
![](/w/images/thumb/3/3d/NatCod-taxon-produtos1.png/680px-NatCod-taxon-produtos1.png)
0
até 33333Q
, identificando produtos.Futas: prefixo
0
. Roupas: prefixo 3
. Demais produtos: prefixos 1
e 2
disponíveis. Maçãs: prefixo 00
. Demais frutas: prefixos 01
, 02
e 03
disponíveis.Maçãs vermelhas, prefixo
000
; maçãs verdes, prefixo 001
. Roupas de mulher, prefixo 30
: vestidos 300
; camisas femininas 302
. Demais roupas: camisetas, prefixo 31
; e jeans prefixo 32
. Cada maçã vermelha recebe um ID no intervalo
000
até 00033Q
; cada maçã verde de 001
até 00133Q
; ...; cada jeans de 32
até 32333Q
.Neste cenário, no inventário inicial foram suficientes 11 bits para identificar todos os produtos com seus prefixos. Por exemplo os IDs das maçãs vermelhas ficaram no intervalo 000
até 00033Q
, e as maçãs verdes de 001
até 00133Q
. Abaixo ilustrando ao invés das classes algumas instâncias de produtos, cada qual com seu ID, e a posição do ID na "régua base 4h". Para destacar classe e contador foi adotada a notação com ponto separador. Por exemplo a maçã verde com ID=00133
pode ser destacada como 001.33
. Ela vem depois da maçã 001.0
e bem antes por exemplo do jeans 32.101
. Todos ficam
A ampliação do banco de dados, adotando o dobro, 22 bits, acarretou a ampliação do intervalo da mesma classe, seus IDs passaram a ser de 000
até 00033333333
. O aumento de bits não afeta os identificadores, apenas amplia a possibilidade de incluir mais produtos dentro da mesma classe.
Identificadores sem contador
A sintaxe "$prefixo$contador
" não deve ser confundida com a sintaxe interna do prefixo. Havendo necessidade de se identificar apenas os grupos taxonômicos, com sua hierarquia, podemos fazer uso do prefixo como identificador,
Prefixo e contador ao mesmo tempo
Exemplo. Ao identificar as partições recursivas de um quadrado, estamos identificando as células (como instâncias) e os taxons ao mesmo tempo. Abaixo usando a base4 para rotular. A célula "0" tem as filhas "00", "01", "02" e "03".
Modelagem dos níveis hierárquicos
A metodologia de modelagem descrita a seguir não é um consenso, mas é uma sugestão fundamentada em boas práticas.
O "problema das espécies" na taxonomia biológica descreve os diversos dilemas da classificação, assim como sua solução: dentro de uma perspectiva de médio prazo (no caso da Biologia da ordem de uma ou mais décadas) a macro-taxonomia, ou seja, os "ramos raiz" da árvore de classificação, podem ser supostos estáveis. Exemplo: as maçãs são variedades da espécie Malus domestica, portanto dentro da árvore biológica, partindo de reino, corresponde a Plantae/Tracheophytes/Angiosperms/Eudicots/Rosids/Rosales/Rosaceae/Malus/M. domestica.
A classificação dos dados de uma empresa não é muito diferente, exibe estabilidade dentro de certas condições. A disciplina que hoje garante a estabilidade dos chamados "domínios de dados" dentro de uma empresa é a governança orientada a Data Mesh. Aqui também adotaremos as diretivas de Data Mesh.
Num contexto Data Mesh não há restrição sobre a origem da classificação. No caso da classificação das frutas como produtos pode ser razoável a classificação biológica de reino até família, e em seguida uma padronização agronômica para os cultivares das frutas.
Por exemplo, as plantas cujos frutos recebem o nome vulgar de "laranja" são plantas da família Rutaceae. Entre elas a espécie Citrus reticulata, que seria sinônimo de "laranja Mandarin". Todavia, a maior parte dos cultivares de laranja são híbridos (ex. laranja Valência), usualmente das espécies Citrus maxima e Citrus reticulata. Portanto numa classificação de produtos não é possível o uso rigoroso da classificação biológica, sendo mais sensato, abaixo de família, o uso de uma classificação estável de cultivares (agronômica), como neste dossiê técnico sobre o cultivo de laranja.
Outra boa prática, tanto para se verificar a estabilidade como para se automatizar a geração das árvores de classificação, é o uso de [[wikiepdia:Resource Description Framework|vocabulários RDF], a maior parte deles catalogados em lov.linkeddata.es. Recomenda-se o uso de no máximo 3 vocabulários para gerar as classes RDF de cada domínio: SchemaOrg, Wikidata e especializado (caso exista como no caso dos cultivares agronômicos).
Por fim, para organizar os metadados, relacionamento entre diferentes classificações, e a semântica da própria classificação, convêm submeter os conjuntos de dados à modelagem de dados usual:
- modelagem em diagramas de classe UML: onde podem ser destacadas as semânticas de relacionamento geral-específico, parte-todo e classe-instência; assim como o relacionamento entre diferentes tipos de identificador (ex. como o ID de cliente se relaciona com o ID de produto).
- modelos de linhagem dos dados: dataflows ou similares indicando os dados no sistema origem e no sistema onde os IDs estão sendo controlados, garantido por exemplo que Golden records estejam usando os IDs da forma planejada.
Tecnicamente os IDs são códigos naturais e as classes das instâncias que os IDs representam estão codificadas como prefixos binários, seguindo o modelo prefixo-contador descrito nas seções acima.
Dentro da visão sociotécnica recomendada pela abordagem Data Mesh, todavia, é importante que os IDs possam ser visualizados por humanos de uma maneira padronizada pela empresa. Nas ilustrações usamos a representação em base4h mas o caso típico, para grandes volumes de dados, é a representação em base16h. Eventualmente uma sintaxe híbrida, com um separador entre prefixo base4h e contador base16h também pode ser adotado para humanos.
Outra recomendação técnico-metodológica é que antigos IDs numéricos sejam transformados em códigos naturais, tomando-se o cuidado de tratar blocos de IDs de até 32 bits, tendo em vista que outros 25 bits seriam reservados (com bastante folga) à representação dos taxons da classificação, totalizando 64 bits num típico ID Bigint de banco de dados SQL.
Por fim, importante notar que algumas classes, com previsão de maior quantidade de IDs, podem usar intervalos de prefixo, como artifício para tratar o maior volume. Tanto o prefixo de classe como seu intervalo seriam concebidos necessariamente com a base convencionada pela empresa, não podendo mais alterar essa decisão inicial de adoção de base.
Caso de uso ilustrativo
É muito comum em Big Data a adoção de uma visão unificada dos dados de uma grande empresa, que pode conter, por exemplo, mais de um sistema de CRM para a gestão dos seus clientes.
O primeiro passo nesse caso é estabelecer em UML qual a estratégia semântica de unificação. Pode-se optar por exemplo por não misturar B2C com B2B, e optar por classificar os clientes B2B conforme o o primeiro e segundo níveis do padrão SchemaOrg, ou seja, conforme sch:Organization. Optou-se também por adotar, como medida de apoio à transição do ID convencional (inteiro de 32 bits) para o hInt de 64 bits, a classe Other. Nela os clientes com cadastro indefinido ou onde caberiam outras classificações, ficam de "quarentena".
- Airline
- Consortium
- Corporation
- EducationalOrganization
- FundingScheme
- GovernmentOrganization
- LibrarySystem
- LocalBusiness
- AnimalShelter
- ArchiveOrganization
- AutomotiveBusiness
- ChildCare
- DryCleaningOrLaundry
- EmergencyService
- EmploymentAgency
- EntertainmentBusiness
- FinancialService
- FoodEstablishment
- GovernmentOffice
- HealthAndBeautyBusiness
- HomeAndConstructionBusiness
- InternetCafe
- LegalService
- Library
- LodgingBusiness
- MedicalBusiness
- ProfessionalService
- RadioStation
- RealEstateAgent
- RecyclingCenter
- SelfStorage
- ShoppingCenter
- SportsActivityLocation
- Store
- TelevisionStation
- TouristInformationCenter
- TravelAgency
- MedicalOrganization
- NGO
- NewsMediaOrganization
- OnlineBusiness
- PerformingGroup
- PoliticalParty
- Project
- ResearchOrganization
- SearchRescueOrganization
- SportsOrganization
- WorkersUnion
- WorkersUnion
- ... (outras classificações, ausentes no SchemaOrg, podem ser obtidas ou criadas na Wikidata)
- Other (classe temporária para a gestão de cadastros incompletos)
Devido à ambiguidade nos domínios, a empresa precisa definir qual a subclasse canônica, quando o SchemaOrg oferecer mais de uma alternativa. Por exemplo "Dentist" pode ser subclasse de "LocalBusiness" ou de "MedicalOrganization", no exemplo foi adotada a classe "MedicalOrganization".