Quelle est la différence entre le modèle de données logique et le modèle de données conceptuel?
Quelle est la différence entre le modèle de données logique et le modèle de données conceptuel?
Dans le modèle de données conceptuel, vous vous souciez uniquement de la conception de haut niveau - des tables qui doivent exister et des connexions entre elles. Dans cette phase, vous reconnaissez les entités de votre modèle et les relations entre elles.
Le modèle logique vient après la modélisation conceptuelle lorsque vous définissez explicitement ce que sont les colonnes de chaque table. Lors de l'écriture du modèle logique, vous pouvez également prendre en compte le système de base de données réel pour lequel vous concevez, mais uniquement s'il affecte la conception (c'est-à-dire, s'il n'y a pas de déclencheurs, vous souhaiterez peut-être supprimer une colonne de redondance, etc.)
Il existe également un modèle physique qui développe le modèle logique et attribue à chaque colonne son type/longueur, etc.
Ici est une bonne image qui décrit chacun des trois niveaux.
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 "trois schémas" ANSI-SPARC 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 la gestion des 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 modèle sémantique tandis 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'usage que vous rencontrerez le plus souvent sur le lieu de travail.
Cependant, dans l'utilisation académique et lors de la description des architectures de SGBD, le niveau logique désigne les objets de base de données (tables, vues, tables, clés, contraintes, etc.), distincts du niveau physique (fichiers, index, stockage). Pour confondre les choses, sur le lieu de travail, le terme modèle physique est souvent utilisé pour désigner la conception telle qu'elle est mise en œuvre ou planifiée pour être mise en œuvre dans une base de données réelle. Cela peut inclure des constructions de niveau "physiques" et "logiques" (à la fois des tables et des 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 par exemple Data Modelling Essentials de Simsion et Witt.
Modèle de base de données logique
La modélisation logique de la base de données est requise pour compiler les exigences métier et représenter les exigences sous forme de modèle. Elle est principalement associée à la collecte des besoins commerciaux plutôt qu'à la conception de la base de données. Les informations à collecter 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 créés, notamment:
Le diagramme de relation ERD – Entité montre la relation entre les différentes catégories de données et montre les différentes catégories de données nécessaires au développement d'une base de données. Diagramme de processus métier - 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 de rétroaction par les utilisateurs.
Les modèles de bases de données logiques déterminent essentiellement si toutes les exigences de l'entreprise ont été réunies. Il est examiné par les développeurs, la direction et enfin les utilisateurs finaux pour voir si davantage d'informations doivent être collectées avant le démarrage 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 économiques. Lors de 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 liés les uns aux autres dans une base de données. Les tableaux et les colonnes sont créé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 disposent d'une autre perspective une fois les tableaux créés.
La modélisation physique de la base de données dépend du logiciel déjà utilisé dans l'organisation. Il est spécifique au logiciel. La modélisation physique comprend:
Diagramme du modèle de serveur - Il comprend 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 rétroaction des utilisateurs.
Sommaire:
1.La modélisation de base de données logique sert principalement à recueillir des informations sur les besoins des entreprises et n'implique pas la conception d'une base de données; tandis que la modélisation physique de la base de données est principalement requise pour la conception réelle de 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 pour une application peut être utilisé dans divers logiciels et implémentations de base de données; tandis que la modélisation physique des bases de données est spécifique au logiciel et au matériel et comporte des index et des contraintes. 3.La modélisation de base de données logique comprend; ERD, diagrammes de processus commerciaux et documentation de rétroaction des utilisateurs; considérant que la modélisation physique des bases de données comprend; diagramme de modèle de serveur, documentation de conception de base de données et documentation de rétroaction des utilisateurs.
En savoir plus: Différence entre le modèle de base de données logique et physique | Différence entre | Modèle de base de données logique vs 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 affiché ci-dessus montre juste la différence étant qu'un modèle conceptuel est un modèle logique sans champs. Ok très bien, je ne mentionne pas le nom de la base de données. Elle semble être totalement redondante.
Je ne sais vraiment pas ce que signifie "sémantique". quelqu'un peut-il expliquer ce que je ferais différemment en utilisant "anglais" et éventuellement publier un lien vers de meilleurs exemples qu'une image qui montre une image qui a des champs et une qui n'en a pas. Les mots à la mode sont tous beaux et bons, mais c'est tellement vague qu'il n'est pas utile de les mettre en pratique.
puis-je faire 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 semblent un peu différentes, puis retirez les types de données).
D'après ce que je peux voir pratiquement (et sans mots à la mode)
modèle physique: en fait des tableaux. Les petites images contiennent des types de données et des contraintes pk/fk nommées Modèle logique: cliquez sur le petit bouton mon outil (en utilisant Oracles SQL Developer Data Modeller, je n'ai pas de licence erwin et 2010 visio ne fait plus de reverse engineering hors 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 du tableau deviennent violettes (alors maintenant je les appelle des entités).
d'accord. à quoi ressemblerait alors mon modèle conceptuel: exactement la même chose que mon modèle logique moins les champs. Je pense qu'il y a plus que cela. Réciter que sa 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.
C'est une vieille question et cela arrive peut-être beaucoup trop tard, mais je ne vois pas un aspect très important nécessaire pour répondre à la question. Autrement dit, l'audience TARGET 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 commerciale, à partir d'entretiens avec les entreprises sur leurs données. Il ne s'agit pas tant de "haut niveau" que de la compréhension par l'entreprise de leurs données, des règles métier saisies dans les relations entre les entités "candidates". À ce stade, vous capturez les choses importantes pour l'entreprise (employé, client, contrat, compte, etc.) et les relations entre elles. Le modèle de données conceptuel final peut être quelque peu abstrait - par exemple, en traitant les individus et les organisations concluant 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 sous-types d'employés et de clients de "la personne" - - mais c'est un document qu'un modeleur de données élabore à partir de discussions avec les PME de l'entreprise et présente à l'entreprise pour validation.
Le modèle de données logique n'est pas seulement "plus détaillé" - là où utile et important, un modèle de données conceptuel peut bien avoir des attributs inclus - c'est le document ARCHITECTURE, le modèle qui est présenté aux analystes/ingénieurs logiciels pour expliquer et spécifier les exigences en matière de données. Il résoudra les relations plusieurs-à-plusieurs vers les tables d'association et définira tous les attributs, avec des exemples et des contraintes, afin que le code puisse être écrit par rapport à 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 l'on vous demande de développer un modèle de données conceptuel, il vous est demandé de concevoir la solution (ou une partie de celle-ci) à partir de zéro, en obtenant vos informations de l'entreprise. Il y a plus, mais j'espère que cela répond à la question.
Schéma conceptuel - couvre les entités et les relations. Doit être créé en premier. Contrairement à certaines des autres réponses; les tables ne sont pas définies ici. Par exemple, un tableau "plusieurs vers plusieurs" n'est pas inclus dans un modèle de données conceptuel mais est défini comme une relation "plusieurs vers plusieurs" entre les 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 éléments comme les index ne sont pas définis, les types d'attributs doivent rester logiques, par exemple texte au lieu de varchar2. Doit être créé sur la base du schéma conceptuel.
Tout d'abord, un modèle de données est un outil d'abstraction et une base de données modèle (ou schéma/diagramme) est un résultat de modélisation.
Le modèle de données conceptuel est indépendant du SGBD et couvre la zone de conception fonctionnelle/domaine. Le modèle de données conceptuel le plus connu est "Entité-Relation". Normalement, vous pouvez réutiliser le schéma conceptuel pour produire différents schémas logiques non seulement relationnels.
Le modèle de données logique est destiné à être implémenté par certains SGBD et correspond principalement au niveau conceptuel de architecture ANSI/SPARC (proposé en 1975); ce point donne quelques collisions de terminologie. Zachman Framework a tenté de résoudre ce type de collision dix ans plus tard en introduisant des modèles conceptuels, logiques et physiques.
Il existe de nombreux modèles de données logiques, et le plus connu est relationnel.
Les principales différences du modèle de données conceptuel sont donc la concentration sur le domaine et l'indépendance du SGBD, tandis que le modèle de données logique est le niveau le plus abstrait de SGBD concret que vous prévoyez d'utiliser. Notez que les SGBD contemporains prennent en charge plusieurs modèles logiques en même temps.
Vous pouvez également consulter mon livre et l'article pour plus de détails.
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 d'abstraction logique. Les concepts sont plus proches des types. Habituellement, au niveau conceptuel, vous affichez les types de choses (cela ne signifie pas que vous devez utiliser le terme "type" dans votre convention de dénomination) et les relations entre ces types. Par conséquent, l'existence de relations 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. Exemples: - Les véhicules ont des roues et les roues sont utilisées dans les véhicules. Au niveau conceptuel, il s'agit d'une relation plusieurs-à-plusieurs - Un véhicule particulier (une voiture par exemple), avec un numéro d'immatriculation spécifique a 5 roues et chaque roue particulière, chacune avec un numéro de série est liée uniquement à cette voiture particulière. Au niveau logique, il s'agit d'une relation un-à-plusieurs.
Conceptuel couvre les "types/classes". La logique couvre les "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 à propos des 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, facilitant la vie de chacun. Vous pouvez décrire le paysage des données de votre organisation à tous les niveaux à l'aide des modèles conceptuel et logique et ne jamais utiliser de base de données relationnelle.
Eh bien, je suppose que c'est mes 2 cents ...