Un contrat de métrique est ce à quoi ressemble une couche sémantique une fois que quelque chose l’applique vraiment. Comment une définition est épinglée, ce qui arrive à une question nommant des champs de deux entrepôts, et pourquoi les identifiants qui atteignent le SQL viennent du contrat lui-même.
Mis à jour · 6 min de lecture
Une définition publiée et une définition épinglée ont l’air identiques dans un navigateur de catalogue. Les deux portent un nom, une expression et un propriétaire. La différence apparaît au moment où quelqu’un pose une question.
Épingler, c’est ce qui se passe quand la couche lit une fois l’objet contrat propre à la plateforme et stocke ce qu’elle a trouvé : les membres, leurs expressions, et l’objet dont ils viennent. Chaque question ensuite est résolue contre la copie stockée plutôt que contre ce que le demandeur a tapé.
La copie stockée contient des noms et des expressions, jamais des lignes. Elle est réapprise à chaque synchronisation : une mesure ajoutée dans l’entrepôt le mardi arrive avec la synchronisation du mardi, et personne n’a à penser à la ressaisir.
Un contrat appris est un document court et ennuyeux, et l’ennui est la fonctionnalité.
Un contrat est une description et une liste d’autorisation à la fois. Le document qui dit à une personne ce qui existe est le document qui dit au constructeur de requêtes ce qui peut s’exécuter. Il n’y a jamais de seconde copie à maintenir en phase.
Les quatre plateformes vous laissent définir la même chose, et les quatre ont leur propre idée de comment s’appelle un membre. Le vocabulaire vaut la peine d’être réglé avant votre première requête, parce que les premiers échecs sont presque toujours des échecs de nommage, pas de modélisation.
L’indexation se fait par entité et nom ensemble plutôt que par nom seul, et cela est sorti d’une exécution contre un compte réel plutôt que de la lecture de la documentation. Cinq semantic views y définissaient chacune le même nom de dimension sur deux entités, l’une au grain document et l’autre au grain section. Un dictionnaire indexé sur le nom seul a fusionné les jumelles en une seule entrée n’appartenant à aucune des deux. Rien n’a produit d’erreur, et chaque réponse bâtie dessus aurait été fausse d’une manière que personne ne pouvait voir.
Une question nommant des champs de deux entrepôts différents est une chose raisonnable à vouloir et une chose déraisonnable à exécuter. Deux contrats appartiennent à deux moteurs, et il n’y a pas de troisième moteur sous les deux.
La couche fait deux travaux avec les mêmes objets et les garde séparés. Pour l’inventaire, le même schéma et la même table vus dans plusieurs entrepôts deviennent un seul objet logique se souvenant de chaque source d’où il vient, ce qui est ce qui rend un rapport de comparaison possible. Pour l’exécution, un contrat appartient à l’entrepôt dont il a été appris, et la requête y est routée. Une question mêlant deux contrats revient en nommant ce qui a été mêlé, et n’est jamais résolue en silence vers le contrat qui se trouvait listé en premier.
À l’intérieur d’un seul entrepôt, la même forme apparaît un niveau plus bas. Un modèle qui ne déclare aucune relation entre deux entités ne peut pas répondre à une question qui les traverse, et l’entrepôt le dit dans ses propres mots. C’est une réponse de modélisation qui vaut la peine d’être lue : elle vous dit que la jointure que tout le monde supposait exister n’a jamais été déclarée.
Comparer entre entrepôts et calculer à l’intérieur d’un seul sont des travaux différents. Les garder séparés est ce qui permet à la même table d’apparaître une fois dans un rapport de gouvernance et d’être quand même calculée dans exactement un moteur.
Quand une question devient une instruction, les chaînes placées dans cette instruction sont les propres copies du contrat. Ce que l’appelant a tapé sert à retrouver un membre. Ce qui atteint le SQL est ce que la synchronisation a stocké.
C’est une petite distinction et elle règle trois choses à la fois.
La propriété est architecturale, pas instructionnelle. On peut dire à un modèle de n’utiliser que des noms approuvés, et une conversation suffisamment étrange finira par l’en dissuader. Un chemin de code qui n’a jamais été écrit n’a rien dont on puisse le dissuader.
Une question à laquelle le contrat ne peut pas répondre revient en nommant le problème, et cette réponse est la moitié la plus utile de la fonctionnalité. Trois formes couvrent presque tout ce que vous rencontrerez.
Ces messages arrivent de l’entrepôt mot pour mot plutôt que lissés en un code de statut. Un compilateur décrivant sa propre réponse est presque toujours plus précis qu’une paraphrase, et la paraphrase est ce qui envoie quelqu’un déboguer un hôte qui allait bien depuis le début.
Ce dernier point mérite un second regard. Garder la forme d’un résultat et jeter son contenu est ce qui rend une piste d’audit sûre à conserver pendant des années, et des années est la seule durée utile pour une piste d’audit.
Une couche sémantique donne à une métrique un seul foyer. Chaque outil qui calcule la métrique lit ce foyer unique. Tous obtiennent le même chiffre. Voici ce que cela signifie en pratique, et ce qui change quand vous exploitez plus d’un entrepôt.
L’accès dont une couche de gouvernance a besoin est étroit, précis et mérite d’être nommé exactement. Ce qui est lu dans un catalogue, ce que lecture seule veut dire quand c’est structurel et non promis, pourquoi votre propre rôle d’entrepôt reste la frontière, et ce qu’hériter d’un catalogue vous apporte.
La règle approuver pour exécuter, en mots simples. L’assistant lit, explique et propose, et une personne possède le chemin d’écriture. Ce que cela coûte, ce que cela rapporte, et trois questions à poser à toute fonctionnalité d’IA.