2 530
edições
(→Taxonomias Base N: add atribuicao de ID) |
|||
Linha 122: | Linha 122: | ||
==Modelagem dos níveis hierárquicos== | ==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. | |||
[[File:Biological classification L Pengo vflip.svg|thumb|160px|upright|Classificação na Biologia. De reino até espécie são estáveis.]] | |||
O "[[wikipedia:Species problem|problema das espécies]]" na [[wikipedia:Taxonomy (biology)|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 [[wikipedia:Malus domestica|''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 [[wikipedia:Data mesh|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 [[wikipedia:Rutaceae|Rutaceae]]. Entre elas a espécie [[wikipedia:Citrus reticulata|''Citrus reticulata'']], que seria sinônimo de "laranja Mandarin". Todavia, a maior parte dos cultivares de laranja são híbridos (ex. [[wikipedia:Valencia orange|laranja Valência]]), usualmente das espécies [[wikipedia:Citrus maxima|''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 [http://www.respostatecnica.org.br/dossie-tecnico/downloadsDT/MjA2 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 [https://lov.linkeddata.es/dataset/lov/ lov.linkeddata.es]. Recomenda-se o uso de no máximo 3 vocabulários para gerar as classes RDF de cada domínio: [[wikipedia:Schema.org|SchemaOrg]], [[wikipedia:Wikidata|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 [[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. | |||
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. | |||
[[Arquivo:NatCod-Taxon-UML-Customer.png|380px|miniaturadaimagem|A classificação dos clientes B2B de uma empresa, conforme SchemaOrg.]] | |||
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 | |||
* [https://schema.org/Airline Airline] | |||
* [https://schema.org/Consortium Consortium] | |||
* [https://schema.org/Corporation Corporation] | |||
* [https://schema.org/EducationalOrganization EducationalOrganization] | |||
* [https://schema.org/FundingScheme FundingScheme] | |||
* [https://schema.org/GovernmentOrganization GovernmentOrganization] | |||
* [https://schema.org/LibrarySystem LibrarySystem] | |||
* [https://schema.org/LocalBusiness LocalBusiness] | |||
** [https://schema.org/AnimalShelter AnimalShelter] | |||
** [https://schema.org/ArchiveOrganization ArchiveOrganization] | |||
** [https://schema.org/AutomotiveBusiness AutomotiveBusiness] | |||
** [https://schema.org/ChildCare ChildCare] | |||
** [https://schema.org/DryCleaningOrLaundry DryCleaningOrLaundry] | |||
** [https://schema.org/EmergencyService EmergencyService] | |||
** [https://schema.org/EmploymentAgency EmploymentAgency] | |||
** [https://schema.org/EntertainmentBusiness EntertainmentBusiness] | |||
** [https://schema.org/FinancialService FinancialService] | |||
** [https://schema.org/FoodEstablishment FoodEstablishment] | |||
** [https://schema.org/GovernmentOffice GovernmentOffice] | |||
** [https://schema.org/HealthAndBeautyBusiness HealthAndBeautyBusiness] | |||
** [https://schema.org/HomeAndConstructionBusiness HomeAndConstructionBusiness] | |||
** [https://schema.org/InternetCafe InternetCafe] | |||
** [https://schema.org/LegalService LegalService] | |||
** [https://schema.org/Library Library] | |||
** [https://schema.org/LodgingBusiness LodgingBusiness] | |||
** [https://schema.org/MedicalBusiness MedicalBusiness] | |||
** [https://schema.org/ProfessionalService ProfessionalService] | |||
** [https://schema.org/RadioStation RadioStation] | |||
** [https://schema.org/RealEstateAgent RealEstateAgent] | |||
** [https://schema.org/RecyclingCenter RecyclingCenter] | |||
** [https://schema.org/SelfStorage SelfStorage] | |||
** [https://schema.org/ShoppingCenter ShoppingCenter] | |||
** [https://schema.org/SportsActivityLocation SportsActivityLocation] | |||
** [https://schema.org/Store Store] | |||
** [https://schema.org/TelevisionStation TelevisionStation] | |||
** [https://schema.org/TouristInformationCenter TouristInformationCenter] | |||
** [https://schema.org/TravelAgency TravelAgency] | |||
* [https://schema.org/MedicalOrganization MedicalOrganization] | |||
** [https://schema.org/Dentist Dentist] | |||
** [https://schema.org/DiagnosticLab DiagnosticLab] | |||
** [https://schema.org/Hospital Hospital] | |||
** [https://schema.org/MedicalClinic MedicalClinic] | |||
** [https://schema.org/Pharmacy Pharmacy] | |||
** [https://schema.org/Physician Physician] | |||
** [https://schema.org/VeterinaryCare VeterinaryCare] | |||
* [https://schema.org/NGO NGO] | |||
* [https://schema.org/NewsMediaOrganization NewsMediaOrganization] | |||
* [https://schema.org/OnlineBusiness OnlineBusiness] | |||
** [https://schema.org/OnlineStore OnlineStore] | |||
* [https://schema.org/PerformingGroup PerformingGroup] | |||
** [https://schema.org/DanceGroup DanceGroup] | |||
** [https://schema.org/MusicGroup MusicGroup] | |||
** [https://schema.org/TheaterGroup TheaterGroup] | |||
* [https://schema.org/PoliticalParty PoliticalParty] | |||
* [https://schema.org/Project Project] | |||
** [https://schema.org/FundingAgency FundingAgency] | |||
** [https://schema.org/ResearchProject ResearchProject] | |||
* [https://schema.org/ResearchOrganization ResearchOrganization] | |||
* [https://schema.org/SearchRescueOrganization SearchRescueOrganization] | |||
* [https://schema.org/SportsOrganization SportsOrganization] | |||
** [https://schema.org/SportsTeam SportsTeam] | |||
* [https://schema.org/WorkersUnion WorkersUnion] | |||
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". | |||
[[Categoria:Código natural]] | [[Categoria:Código natural]] | ||
[[Categoria:Taxonomia]] |
edições