Quelle est la différence entre le modèle de données logique et le modèle de données conceptuel?

Dans ce tableau, vous pouvez voir la différence entre chaque modèle:

Voir http://www.1keydata.com/datawarehousing/data-modeling-levels.html pour plus d'informations et quelques exemples de modèles de données.

Ces termes sont malheureusement surchargés de plusieurs définitions possibles. Selon le modèle ANSI-SPARC "three schema" par exemple, le schéma conceptuel ou modèle conceptuel consiste en l'ensemble des objets dans une base de données (tables, vues, etc.) contrairement au schéma externe qui sont les objets que les utilisateurs voient.

Dans les professions de gestion de données et en particulier chez les modélisateurs / architectes de données, le terme Modèle conceptuel est fréquemment utilisé pour désigner un sémantique modèle alors que le terme Modèle logique est utilisé pour désigner une base de données préliminaire ou virtuelle Conception . C'est probablement l'utilisation que vous êtes le plus susceptible de rencontrer dans le milieu de travail.

En usage académique et lors de la description des architectures SGBD, le niveau logique désigne les objets de base de données (tables, vues, tables, clés, contraintes, etc.), par opposition au niveau physique (fichiers, index, stockage). Pour confondre les choses plus loin, dans le lieu de travail, le terme modèle physique est souvent utilisé pour signifier la conception telle qu'elle est mise en œuvre ou prévue pour la mise en œuvre dans une base de données réelle. Cela peut inclure à la fois des constructions de niveau "physique" et "logique" (tables et Index par exemple).

Lorsque vous rencontrez l'un de ces termes, vous devez vraiment demander des éclaircissements sur ce qui est décrit, sauf si le contexte le rend évident.

Pour une discussion de ces différences, consultez data Modelling Essentials de Simsion et Witt par exemple.

Modèle De Base De Données Logique

La modélisation de base de données logique est nécessaire pour compiler les exigences métier et représenter les exigences en tant que modèle. Il est principalement associé à la collecte des besoins des entreprises plutôt qu'à la conception de la base de données. Les informations qui doivent être recueillies concernent les unités organisationnelles, les entités commerciales et les processus métier.

Une fois les informations compilées, des rapports et des diagrammes sont réalisés, y compris ceux-ci:

ERD-entité relation le diagramme montre la relation entre les différentes catégories de données et présente les différentes catégories de données requises pour l'élaboration d'une base de données. Diagramme de processus d'affaires–, Il montre les activités des individus au sein de l'entreprise. Il montre comment les données se déplacent au sein de l'organisation en fonction de l'interface d'application qui peut être conçue. Documentation des commentaires par les utilisateurs.

Les modèles de base de données logiques déterminent essentiellement si toutes les exigences de l'entreprise ont été rassemblées. Il est examiné par les développeurs, la direction et enfin les utilisateurs finaux pour voir si plus d'informations doivent être recueillies avant le début de la modélisation physique.

Modèle De Base De Données Physique La modélisation de base de données physique traite de la conception de la base de données réelle en fonction des exigences recueillies lors de la modélisation de base de données logique. Toutes les informations recueillies sont converties en modèles relationnels et modèles d'affaires. Pendant la modélisation physique, les objets sont définis à un niveau appelé niveau de schéma. Un schéma est considéré comme un groupe d'objets qui sont liés les uns aux autres dans une base de données. Les tableaux et les colonnes sont réalisés en fonction des informations fournies lors de la modélisation logique. Les clés primaires, les clés uniques et les clés étrangères sont définies afin de fournir des contraintes. Les index et les instantanés sont définis. Les données peuvent être résumées, et les utilisateurs reçoivent une autre perspective une fois que les tableaux ont été créés.

La modélisation de la base de données physique dépend du logiciel déjà utilisé dans organisation. Il est spécifique au logiciel. La modélisation physique comprend:

Diagramme de modèle de serveur-il inclut des tables et des colonnes et différentes relations qui existent dans une base de données. Documentation de conception de base de données. Documentation de commentaires des utilisateurs.

Résumé:

1.La modélisation de base de données logique est principalement destinée à recueillir des informations sur les besoins de l'entreprise et n'implique pas la conception d'une base de données; alors que la modélisation de base de données physique est principalement requise pour la conception réelle de la base de données. la base de données. 2.La modélisation de base de données logique n'inclut pas les index et les contraintes; le modèle de base de données logique d'une application peut être utilisé dans divers logiciels et implémentations de base de données; alors que la modélisation de base de données physique est spécifique au Logiciel et au matériel et comporte des index et des contraintes. 3.Modélisation de base de données logique comprend; ERD, diagrammes de processus métier, et la documentation de rétroaction des utilisateurs; tandis que la modélisation de base de données physique comprend; diagramme de modèle de serveur, documentation de conception de base de données, et Documentation des commentaires des utilisateurs.

Lire la suite: différence entre le modèle de base de données logique et physique / différence entre / logique vs modèle de base de données physique http://www.differencebetween.net/technology/software-technology/difference-between-logical-and-physical-database-model/#ixzz3AxPVhTlg

J'ai besoin de produire à la fois un modèle logique et un modèle conceptuel. Toutes les explications ici sont vraiment vagues. Le lien posté ci-dessus montre la différence étant qu'un modèle conceptuel est un modèle logique sans champs. D'accord, Je ne mentionne pas le nom de la base de données. Il semble être totalement redondant.

Je ne sais vraiment pas ce que signifie "sémantique". quelqu'un peut-il expliquer ce que je ferais différemment en utilisant 'english' et éventuellement poster un lien vers de meilleurs exemples qu'une image qui affiche une image qui a des champs et une autre qui ne le fait pas. Les mots à la mode sont tous bien, mais c'est tellement vague qu'il n'est pas utile de mettre en œuvre pratiquement.

Est-ce que je fais autre chose que de prendre mon modèle logique (qui est essentiellement mon modèle physique inversé conçu à partir de la base de données, cliquez sur un bouton dans lesdits outils et les images sont un peu différentes, puis retirez les types de données).

D'après ce que je peux pratiquement voir (et sans mots à la Mode)

Modèle physique: en fait table. Les petites images ont des types de données et des contraintes PK/fk nommées Modèle logique: cliquez sur le petit bouton de mon outil (en utilisant oracles SQL Developer Data Modeller, Je n'ai pas de licence erwin et 2010 visio ne désossent plus les ingénieurs de la base de données), puis les images à l'écran changent légèrement. Les types de données ont disparu et les noms des contraintes ont disparu, puis les couleurs des représentations de la table deviennent violettes (alors maintenant je les appelle des entités).

Ok. donc, ce que mon modèle conceptuel ressemblerait-il à un autre alors: exactement la même chose que mon modèle logique moins les champs. Je pense qu'il est plus que cela. Réciter que c'est une représentation "sémantique" des données semble vraiment agréable et fantaisiste, mais n'a pas de sens pour quelqu'un qui n'en a pas fait auparavant.

Schéma conceptuel - couvre les entités et les relations. Devrait être créé en premier. Contrairement à certaines des autres réponses; les tableaux ne sont pas définis ici. Par exemple, une table "plusieurs à plusieurs" n'est pas incluse dans un modèle de données conceptuel, mais est définie comme une relation "plusieurs à plusieurs" entre entités.

Schéma logique - couvre les tables, les attributs, les clés, les contraintes de rôle obligatoires et l'intégrité référentielle sans égard à l'implémentation physique. Des choses comme les index ne sont pas définis, les types d'attributs doivent rester logiques, par exemple text au lieu de varchar2. Devrait être créé sur la base du schéma conceptuel.

La plupart des réponses ici sont strictement liées aux notations et à la syntaxe des modèles de données à différents niveaux d'abstraction. La principale différence n'a été mentionnée par personne. Modèles conceptuels concepts de surface. Les Concepts se rapportent à d'autres concepts d'une manière différente qu'une Entité se rapporte à une autre Entité au niveau Logique de l'abstraction. Les Concepts sont plus proches des Types. Habituellement, au niveau conceptuel, vous affichez des types de choses (cela ne signifie pas que vous devez utiliser le terme "type" dans votre nommage convention) et les relations entre ces types. Par conséquent, l'existence de relations de plusieurs à plusieurs n'est pas la règle, mais plutôt la conséquence des relations entre les éléments de type. Dans les modèles logiques, les entités représentent une instance de cette chose dans le monde réel. Dans les modèles conceptuels, on ne s'attend pas à la description d'une instance d'une entité et de leurs relations, mais plutôt à la description du "type" ou de la "classe" de cette entité particulière. Exemple: - Les véhicules ont Les roues et les roues sont utilisées dans les véhicules. Au niveau Conceptuel c'est un plusieurs-à-plusieurs relations - Un Véhicule particulier (une voiture par exemple), avec un numéro d'enregistrement ont 5 roues et chaque roue, chacun avec un numéro de série est liée qu'à la voiture particulière. Au niveau logique, il s'agit D'une relation un à plusieurs.

Conceptuelle couvre "types / classes". Couvertures logiques "instances".

J'ajouterais un autre commentaire sur les bases de données. Je suis d'accord avec l'un des collègues qui ont commenté ci-dessus que les modèles conceptuels et logiques n'ont absolument rien sur les bases de données. Les modèles conceptuels et logiques décrivent le monde réel du point de vue des données en utilisant des notations telles que ER ou UML. Les fournisseurs de bases de données, intelligemment, ont conçu leurs produits pour suivre la même philosophie utilisée pour modéliser logiquement le monde et ils ont créé des bases de données relationnelles, rendant la vie de chacun plus facile. Vous pouvez décrire le paysage de données de votre organisation à tous les niveaux à L'aide de Modèle logique et ne jamais utiliser une base de données relationnelle.

Eh bien, je suppose que c'est mes 2 cents...

C'est une vieille question et peut-être que cela arrive trop tard, mais je ne vois pas un aspect très important nécessaire pour répondre à la question. Qui est le public CIBLE pour le modèle de données. Le modèle de données conceptuel est le modèle généré à partir de l'analyse de l'entreprise, des entrevues avec l'entreprise au sujet de leurs données. Ce n'est pas tant "haut niveau" que la compréhension de leurs données par l'entreprise, les règles métier capturées dans les relations entre les entités "candidates". À ce stade, vous capturent les choses importantes pour l'entreprise (employé, client, Contrat, compte, etc.) et les relations entre eux. Le modèle de données conceptuel final peut être quelque peu abstrait - par exemple, traiter les individus et les organisations qui concluent un contrat comme des sous-types d'une "partie", les entrepreneurs et les employés permanents comme des sous-types d'un employé, même les employés et les clients sous-types de "personne" - mais c'est un document qu'un modélisateur de données PME d'affaires et présente à l'entreprise pour validation.

Le modèle de données logiques n'est pas seulement "plus détaillé" - lorsqu'il est utile et important, un modèle de données conceptuel peut bien avoir des attributs inclus - c'est le document D'ARCHITECTURE, le modèle qui est présenté aux analystes/ingénieurs de logiciels pour expliquer et spécifier les besoins en données. Il résoudra les relations plusieurs-à-plusieurs aux tables d'association et définira tous les attributs, avec des exemples et des contraintes, de sorte que le code puisse être écrit contre l'architecture.

Le modèle physique est ce modèle logique généré spécifiquement pour un environnement particulier, tel que SQL Server ou Teradata ou Oracle ou autre. Il aura des clés, des index, des partitions, ou tout ce qui est nécessaire pour implémenter, en fonction du dimensionnement, de la fréquence d'accès, des contraintes de sécurité, etc.

Donc, si on vous demande de développer un modèle de données conceptuel, on vous demande de concevoir la solution (ou une partie de celle-ci) à partir de zéro, en obtenant votre l'information de l'entreprise. Il y a plus à cela, mais j'espère que cela répond à la question.

Modèle de données logiques

Un modèle de données logique décrit les données avec le plus de détails possible, sans tenir compte de la façon dont elles seront implémentées physiquement dans la base de données. Les caractéristiques d'un modèle de données logiques comprennent: * Comprend toutes les entités et les relations entre elles. * Tous les attributs pour chaque entité sont spécifiés. * La clé primaire pour chaque entité est spécifiée. * Les clés étrangères (clés identifiant la relation entre les différentes entités) sont défini. * La normalisation se produit à ce niveau. modèle de données conceptuel

Un modèle de données conceptuel identifie les relations de plus haut niveau entre les différentes entités. Les caractéristiques du modèle de données conceptuel comprennent: · Comprend les entités importantes et les relations entre eux. · Aucun attribut n'est spécifié. · Aucune clé primaire n'est spécifié.