Modèle physique base de données

Enfin, le modèle de données physiques vous montrera exactement comment implémenter votre modèle de données dans la base de données de choix. Il affiche toutes les structures de table, y compris le nom de colonne, le type de données de colonne, les contraintes de colonne, la clé primaire, la clé étrangère et les relations entre les tables. La technologie d`implémentation cible peut être un SGBD relationnel, un document XML, une feuille de calcul ou toute autre option d`implémentation de données. Le modèle de données physiques dépend du SGBD, c`est-à-dire; Il varie en fonction du SGBD utilisé. Cela signifie que la notation des DataType varie en fonction du SGBD. Par exemple, nous avons différents types de données dans SQL Server et Oracle Server. En outre, la représentation du diagramme de modèle de données physiques peut être différente, bien qu`elle contienne les mêmes informations que décrites ci-dessus – certains peuvent représenter la clé primaire et les clés étrangères séparément à la fin de la liste des colonnes. Ce modèle de données dépend de l`utilisateur/concepteur comment il spécifie le diagramme et les serveurs SGBDR. Le diagramme ci-dessous montre différentes façons de représenter une table. Karen… Je voudrais offrir une vue alternative de la distinction entre les modèles de données conceptuelles, logiques et physiques. Peut-être une vue «contrarienne», car elle est contraire à la compréhension générale et ce que la plupart des gens de données mis en avant.

Voir par exemple, voir David Hays: http://bit.ly/QwSkOY.. Je soumets que tous les modèles de données sont des modèles «logiques» parce qu`ils sont élaborés selon les règles de la logique ou de l`argument formel; caractérisé par ou capable de raisonnement clair et solide. (Il s`agit d`une définition de dictionnaire de «logique».) Ces règles sont incorporées dans, ce que j`aime appeler, un schéma de modélisation de données. Exemples étant relationnels, dans ses nombreuses variantes (comme IE), ORM (modélisation des faits), UML, etc. Dans votre définition, vous dites qu`il y a des «attributs» dans les modèles de données logiques (tous?), mais dans les schémas de modélisation orientés vers les faits, il n`y a pas de concept d`attribut: les entités et les attributs sont appelés objets (dans ORM, à ne pas confondre avec orienté objet…). Un attribut est un objet qui joue un rôle dans une relation avec un autre objet. Nous devons d`abord définir les objets et les relations (mais pas la cardinalité ou l`optionalité). Ensuite, l`attribut est une interprétation particulière des choses dans ce modèle. .. Un modèle de données (logique) inclut tous les détails du domaine en cours de modèle, toutes les informations exogènes. Cela exclut tout ce qui est faux, artificiel ou fait à des fins de mise en œuvre. Graham Witt appelle cela un «modèle de données d`entreprise», car il souligne qu`il est d`un certain domaine de l`utilisateur, un objectif d`affaires à l`extérieur.

Ainsi, les clés étrangères ne doivent pas figurer dans le modèle, les entités d`intersection (pour résoudre une relation plusieurs à plusieurs) ne doivent pas figurer dans le modèle. Je dirais que même les tables d`entités ne doivent pas être dans le modèle de données d`entreprise car il s`agit d`une étape vers l`implémentation (dans un modèle de données relationnelles). Ceci est né dans les modèles Fact, qui peuvent fournir un modèle complet et détaillé sans regrouper les «attributs» dans les tables.