Discussion :

[WhiteTigerZ]

Pour le modèle physique normalement c'est la génération des requêtes SQL
Si c'est le cas, pourquoi vous définissez le MPD comme de la théorie.

[CinePhil]

OK. Au temps pour moi. Je voyais plus le MPD comme une liste de tables avec leurs colonnes typées et leurs contraintes mais pas écrit en SQL.

Comme déjà dit, si le logiciel de modélisation peut se connecter au SGBD, il générera tout seul la BDD. Au pire, il générera le script SQL (donc le MPD ).

Je comprends maintenant pourquoi je n'avais pas eu une très bonne note à l'UE Bases de données au CNAM ! J'avais juste décrit les tables du genre Personne (id, nom, prenom)

[fsmrel]

Bonsoir,

Une question le MLD se base-t-il sur le modèle relationnel où le c'est le MCD ?

Lorsqu'on parle d'un M relationnel s'agit-il vraiment d'une théorie

Un schéma relationnel = Modèle relationnel ? (et pourquoi)

On va essayer de vous faire ressentir les différences.

Le Modèle Relationnel a été inventé en 1969 par l’Anglais Ted Codd. Son article le plus célèbre date de 1970, il est à considérer comme l’acte fondateur de la Théorie relationnelle, à l’origine de tous les langages et SGBD relationnels. Vous aurez sans doute du mal à interpréter la définition formelle qui en est donnée, mais au moins pourrez-vous subodorer de quoi il en retourne.

Aujourd’hui, le Modèle Relationnel est défini par les cinq composants suivants (pour plus de détails, voyez l’ouvrage de référence An Introduction to Database Systems de C. J. Date) :

1. Une collection non limitée de types scalaires (dont notamment le type booléen (valeur de vérité)),
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen,
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu,
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs de relations à ces variables,
5. Une collection non limitée d’opérateurs relationnels génériques (« l’algèbre relationnelle »), pour produire des valeurs de relations à partir d’autres valeurs de relations.

Manifestement, le Modèle Relationnel relève de la logique et des mathématiques appliquées.

Dix ans plus tard, en juin 1979, parut en France le document officiel suivant, ressortissant à la démarche méthodologique MERISE :

Méthode de définition d’un système d’informations, Ministère de l’Industrie, Mission à l’informatique, centre technique informatique, fascicule 4, Guide pratique pour l’élaboration des modèles de données et de traitements.

Voici les définitions qu’on y trouve :

— Le modèle conceptuel s’attache à décrire :

• pour les données, la signification de chacune d’elles et les rapports qui existent entre le sens de chacune d’elles,
• pour les traitements, la succession des actions menées par l’organisme en réponse aux sollicitations auxquelles elle doit faire face et qui justifient sa raison d’être.

— Le modèle logique consiste :

• pour les données, à définir des structures logiques de données, des hiérarchies d’accès logiques,
• pour les traitements, à les répartir entre les hommes et les machines et pour ceux qui sont automatisés, entre des modes conversationnels ou différés, centralisés ou répartis, ce qui conduit à définir des types de services ou postes de travail.

— Le modèle physique consiste :

• pour les données, à spécifier une organisation d’implantation en fichiers ou bases de données utilisant tel moniteur,
• pour les traitements automatisés, à décrire un découpage en programmes, et pour chaque programme la structure dans laquelle les traitements prévus s’intègrent.

Il s’agit donc ici de décrire un univers du discours (c'est-à-dire, pour faire court, une entreprise, un système de facturation aussi bien que des rencontres sportives ou le monde des courses hippiques), selon la méthode fournie par les pères de Merise. Un modèle est en fait ici un diagramme conforme aux conventions de représentation fournies par la méthode, diagramme que l’on incorpore dans un dossier de conception et que nous interprétons tous de la même façon (à peu de choses près), beaucoup mieux que des énoncés en français ou autre.


Pour le Larousse, un modèle est ce qui est donné pour servir de référence. En ce sens, le Modèle Relationnel de Codd est bien un modèle car il a servi de référence pour les langages tels que SQL, Quel, Square, etc. Merise elle-même peut être perçue comme un modèle (modèle Entité/Association ou Entité/Relation, peu importe) dans la mesure où elle nous sert de référence pour conceptualiser, décrire l’univers du discours, au moyen de figures géométriques (rectangles, ellipses, liens...) recensées dans son métamodèle. Exemple de métamodèle (partiel, dû à Yves Tabourier) :

Mais quand on produit un MCD (ou un MLD), ce n’est pas un modèle au sens du Larousse, c’est une image porteuse de sémantique, une représentation schématique, structurée, une abstraction des règles de gestion des données décrivant l’univers du discours, règles qu’il faut traduire en respectant la méthode de représentation, à savoir le formalisme proposé par Merise et synthétisé le métamodèle : de ces règles on infèrera des entités-types, des associations-types, des propriétés, des contraintes.

Exemple de MCD décrivant (très partiellement) les courses hippiques :

Par contraste, au sens du Modèle Relationnel, il n’y a pas de formalisme. Certains ont proposé une représentation « relationnelle » (sic) au niveau MLD, mais c’est par contraste avec une représentation précédente, dite Codasyl, que l’on utilisait beaucoup dans les années 1970-1980. Par exemple, avec l’outil Power AMC à partir du diagramme conceptuel, on produit le diagramme logique, le MLD, selon la notation « conceptuelle » :


ou selon la notation « relationnelle » (sic) :



Ou selon la notation « Codasyl » :

Pour bien percevoir la différence entre le Modèle Relationnel et le formalisme Merise, on peut se poser par exemple la question suivante : à quoi peut ressembler l’algèbre merisienne ?

[fsmrel]

Bonsoir,

OK. Au temps pour moi. Je voyais plus le MPD comme une liste de tables avec leurs colonnes typées et leurs contraintes mais pas écrit en SQL.

Comme déjà dit, si le logiciel de modélisation peut se connecter au SGBD, il générera tout seul la BDD. Au pire, il générera le script SQL (donc le MPD ).

Je comprends maintenant pourquoi je n'avais pas eu une très bonne note à l'UE Bases de données au CNAM ! J'avais juste décrit les tables du genre Personne (id, nom, prenom)

Si vous aviez suivi à l'époque mon cours DB2 (dont j’ai accouché il y a près de 20 ans, en décembre 1991...) peut-être auriez-vous eu une note encore pire , car selon moi le MPD correspond à toute la plomberie propre à un SGBD, échappant donc totalement au MLD et que le DBA doit installer en plus des tables et des vues, ajuster, faire percuter et faire évoluer au fil des versions du SGBD, afin que les développeurs puissent créer et exécuter leurs requêtes SQL de façon satisfaisante. Dans le diagramme E/R ci-dessous dont je m'étais fendu, figurent un tas de types d’objets bizarres accompagnant les objets « logiques » bien connus (les tables et les vues), sorte de brocante qui ne vous dira rien, et pour cause... L’objet de ce diagramme était qu’à la fin du cours, les élèves soient capables d’expliquer le rôle et l’intérêt de chaque type d’objet « physique ».

=> A mon sens, le MPD, c'est la partie immergée de la banquise.



Si un DBA DB2 d’aujourd’hui examine cette image, il sourira, car en vingt ans DB2 a évolué, mais en toute transparence pour les applications, eu égard au respect par DB2 de la 8e des douze règles de Codd :

Physical Data Independence

Rule 8: Application programs and terminal activities remain logically unimpaired whenever any changes are made in either storage representations or access methods.

To handle this, the DBMS must support a clear, sharp boundary between the logical and semantic aspects on the one hand and the physical and performance aspects of the base tables on the other hand; application programs must deal with the logical aspects only. Non-relational DBMS rarely provide complete support for this rule — in fact, I know of none that do.

(Les programmes d’application et les tâches interactives ne doivent pas être affectés quand il y a des changements concernant le mode de représentation [des données] en mémoire ou les méthodes d’accès.
Pour garantir cela, le SGBD doit établir une frontière claire et nette, entre d’un côté les aspects logiques et sémantiques, et de l’autre côté les aspects physiques et les performances des [accès aux] tables ; les programmes d’application ne doivent s’intéresser qu’aux seuls aspects logiques. Les SGBD non relationnels sont rarement complètement conformes à cette règle— en fait je n’en connais aucun [et vlan ! pour les SGBD Codasyl tels IDS II et IDMS/R]).

Aujourd’hui cette indépendance, cette transparence paraissent évidentes, mais ça n’était pas le cas avec les systèmes pré-relationnels. Merci Dr. Codd.

[elati]

MERCI