est-il une pratique courante dans un schéma d'étoiles à préfixer les noms de table comme une dimension ou une table de fait? Est-il également une pratique courante d'avoir des noms de colonne préfixés avec le nom de la table?
Dans mes bases de données OLTP normales, je ne fais pas cela, mais je vois des exemples de ce type de nommage dans Star Schemas.
a-t-il de sens d'avoir un ensemble différent de normes de dénomination pour les schemas d'entrepôt de données VS OLTP Schemas?
merci Dwight
4 Réponses :
La convention de noms Tablename_column est utilisée pour vous assurer que tous les champs d'une base de données sont uniques, bien qu'il soit quelque peu excessif, il peut être utilisé pour une norme standard / requise pour une nommée unique (que certains ministères informatiques du client.) < pré> xxx
Il supprime toute ambiguïté de l'endroit où le nom viendrait.
Je préfère ne pas nommer des tables avec un préfexe (en supposant que cela ne casse pas les normes locales d'un Société), étant donné que cela pourrait être une table aujourd'hui, il pourrait être ré-mis en œuvre comme une vue de vue ou partitionnée demain, mais exposerai le même schéma, et je devrais alors accepter des objets préfixés de manière incorrecte ou mettant à jour la référence auprès du nouveau nom / Créer un synonyme.
Cohérence Bien que le gagnant a tendance à être le gagnant, si chaque DBA / DEV a mis en place sa propre version, ce serait le chaos, alors j'aurais tendance à trouver les normes de la société et à les appliquer.
Il est courant dans DWS de nommer des colonnes avec des "noms longs" car ces colonnes se retrouvent sous forme d'en-têtes de colonne dans les rapports (résultats de requête) et sont censés être conviviaux d'entreprise. Donc, au lieu d'avoir produit.name et client.name qui apparaîtrait tous les deux comme "nom" (à moins que l'alias n'est utilisé), il est courant d'utiliser le produit . Nom de produit et client.Customername afin qu'ils apparaissent comme "produitName" et "Customername" dans la première ligne d'un rapport (requête) une fois que l'étoile est aplatie via des jointures. Les traits de soulignement sont fréquemment utilisés au lieu de cas de chameau et d'ébauches, si elles sont autorisées par la DB. Les préfixes DIM et les faits sont recommandés dans les grands DWS lorsque le rôle de la table dans le schéma peut ne pas être évident; Je les aime vraiment.
Noms de table:
Noms de colonne:
Warehouse vs Nommage OLTP:
Belle réponse concise.
Pouvez-vous élaborer comment vous préfixeriez personnellement des colonnes?
@pimbrouwers - permet de dire que vous avez des tables: faits_security_vuln, dim_comm_org et dim_comm_asset. Si vous avez une colonne 'Nom' dans l'une de ces tables et utilisez-les dans des requêtes complexes (comme des CTES), il devient rapidement un fardeau de suivre à son origine. Donc, plutôt que de compter sur les alias de table, vous pouvez simplement configurer les noms de colonne comme: 'vuln_ ', 'org _ ', "Absret_ *". Ces préfixes doivent être brefs - ils ne seront probablement pas des qualificatifs anti-balles.
Ken, j'aime votre convention [Type] [Sujet] [Nom], où le type est "DIM" ou "fait" (ou "faits" (ou "faits" pour les agrégats), le problème est que lors de la création du modèle STAR SCHEMA dans l'Oracle Repository Business Intelligence, les meilleures pratiques suggèrent que nous devions créer des noms d'alias pour la dimension et les tableaux de faits avec un DIM_ (ou DIM), et des préfixes de fait (ou de faits_) pour la dimension et les tables de faits. Afin d'éviter d'avoir une dimension alias et des tables de faits pour lire Dim_dim [Nom de la table] ou faits_Fact_Fact_ [Nom de table), il est préférable de nommer les tables de dimension avec un suffixe _DM (ou _DM) et les tables de fait avec un _ft (ou _ft ) suffixe.