Cours Merise/2 extensions

Рет қаралды 19,745

E mds

Күн бұрын

Пікірлер: 86

@sihemmansour5303 Жыл бұрын

merci pour ce précieux tuto , vous êtes géniale

@martinbrait4730 3 жыл бұрын

53:53 Ca fait peur, 5 clefs, pour composer une clef primaire élémentaire. En SQL, lorsque je cherche l'existence d'une sous-activité, pour un séjour donné, la requête à écrire est complexe ! Est-ce un cas exceptionnel ? Doit on se faire à l'idée de s'accoutumer à ce niveau de difficulté ?

@E_mds 3 жыл бұрын

Non seulement c'est un cas exceptionnel, mais il faut savoir que dans les SGBDR, on favorise les id en auto-incrément et du coup en laissant les liens uniquement en clés étrangères. Dans la logique, c'est moins propre, mais c'est pour favoriser l'efficacité. En effet, les liens relatifs supposent des triggers pour la gestion des numéros relatifs (trouver le dernier numéro pour ajouter un), ce qui représente des ralentissements, en particulier lors des accès partagés (car en plus, des verrous se mettent en place). Donc, au niveau du MCD, c'est joli et optimisé, mais ça s'arrête là.

@martinbrait4730 3 жыл бұрын

@@E_mds C'est précieux Je n'ai jamais pris d'initiative sur les index des tables du MPD, de peur de corrompre la qualité des tables résultantes du MCD . Finalement, doubler systématiquement les identifiants ,clef primaire composée de chaque association, d'une clef secondaire artificielle auto-incrémentée, est-ce aberrant, est-ce une bonne pratique ?

@E_mds 3 жыл бұрын

@@martinbrait4730 En fait, on ne crée pas une clé secondaire pour doubler une clé primaire composée : on met une clé primaire en auto-incrément, la partie de la clé primaire qui était étrangère à la fois, redevient une simple clé étrangère et l'ancien numéro séquentiel qui justifiait le lien relatif, devient un simple attribut. Par exemple : Les fiches sont numérotées par dossier. Dossier (id, titre...) id : clé primaire (auto-incrément) Fiche (id, numéro, contenu,...,iddossier) id : clé primaire (auto-incrément) iddossier : clé étrangère en ref. à id de Dossier et l'attribut numero est un attribut simple qui contiendra le numéro de la fiche dans le dossier

@martinbrait4730 3 жыл бұрын

@@E_mds Si je comprends bien, dans le cas d'une version numérotée de quelque chose, la chasse aux verrous doit nous inciter à faire passer la clé primaire qui était étrangère à la fois, en attribut simple. Voyez vous d'autres cas particuliers lors du passage du modèle conceptuel au modèle physique ?

@E_mds 3 жыл бұрын

@@martinbrait4730 On peut même supprimer le numéro simple s'il n'est pas si important. L'autre cas particulier est bien sûr l'héritage : il faut le minimiser car la multiplicité des tables alourdit le code et augmente les échanges (chronophages) avec la BDD. Donc, quand les entités filles peuvent être supprimées, il ne faut pas s'en priver (c'est souvent le cas, en particulier quand elles contiennent peu d'attributs et pas ou peu de liens). Il arrive qu'on supprime plutôt l'entité mère (si elle n'a pas de lien et peu d'attributs, et que l'on n'a pas forcément besoin de faire des traitements sur elle). Il n'y a pas de règle absolu : il faut réfléchir sur ce qui est le plus pertinent.

@tarikr5853 17 күн бұрын

Bonjour, vous remercie pour cet exposé rigoureux ! Puis-je savoir est ce que les outils de modélisation et de génération automatique de script SQL implémentent la prise en charge des contrainte d'inclusion, partions etc. .. ou est- ce que cet effort devrait être implémenté par le développeur ?

@E_mds 17 күн бұрын

Merci pour votre message ! A ma connaissance, les logiciels de modélisation ne génèrent pas automatiquement le code, mais je peux me tromper. Il faut dire qu'il peut y avoir plusieurs variantes dans l'interprétaition des contraintes et aussi, une contrainte est souvent à l'origine de plusieurs triggers.

@tarikr5853 17 күн бұрын

@@E_mds Je vous remercie, je viens de terminer le cours sur les trigger et me suis fait un idée plus précise. encore une fois vos cours sont d'une rigueur exceptionnelle. Merci et bonne continuation.

@E_mds 16 күн бұрын

@@tarikr5853 Merci et bonne continuation aussi

@moussabaannou4131 5 жыл бұрын

Bonjour merci pour vos vidéos. Je voulais savoir pour ce qui est de l’agrégation du mcd de merise , est il possible de le convertir dans un diagramme de classe en UML,Etant donné que en UML l’agrégation a le même nom que celui de merise mais leurs signification et leurs applications sont différentes.Navré de poser une question impliquant des éléments qui n'ont pas de rapport avec cette vidéos.

@E_mds 5 жыл бұрын

En fait, sous Merise, il est question d'une association partant d'une autre association, donc transformée en pseudo-entité. Sous UML, si votre diagramme est construit en vue de la création d'une BDD, il n'y a pas d'équivalent : vous devrez créer une classe association à partir d'un triple lien, reprenant les 2 classes constituant la 1e classe association + la nouvelle classe.

@moussabaannou4131 5 жыл бұрын

@@E_mds Merci d'avoir répondu :)

@martinbrait4730 5 жыл бұрын

Bonjour Madame, J'espère que vous allez bien. Je m'ennuie de vos cours sur youtube ! Vos vidéos sont merveilleuses, et vivement quelques nouveautés de rentrée ! Je reviens vous demander de vérifier ma compréhension pour la mise en œuvre de la contrainte d'inclusion à portée multiple. (minute 38:18) Très concrètement, dans le programme en base de données, s'agit-il de vérifier en un seul trigger before insert, que l'id catégorie de permis retournée, nécessaire à la conduite d'un véhicule choisi, est également l'id de catégorie de permis dont est titulaire le loueur de véhicule. Dans un tel cas, on accepte l'insertion du couple idpersonne, idvehicule dans la relation conduit ?

@E_mds 5 жыл бұрын

Bonjour, merci pour votre message. Il est vrai que cela fait longtemps que je n'ai pas mis en ligne de vidéo. J'ai travaillé sur la construction d'un nouveau TP pour mes étudiants et ça a pris tout mon temps. Là, je suis en train de coder un petit complément Android et je devrais faire la vidéo correspondante la semaine prochaine. En ce qui concerne votre question, vous avez effectivement correctement analysé le problème. C'est bien un trigger qui va faire ce contrôle. Cependant il faut penser à plusieurs triggers : before insert on CONDUIT, before update on CONDUIT (dans le cas d'une modification de l'identifiant), before delete on POSSEDE (on ne doit pas supprimer un permis d'une personne si elle conduit un véhicule nécessitant ce permis, ou alors on supprime aussi l'occurance dans CONDUIT : tout dépend ce que l'on veut), before update dans VEHICULE (on ne permet pas la modification de la clé étrangère si le permis concerné est utilisé dans POSSEDE, ou alors il faut mettre en place une stratégie de mise à jour ou suppression). Au final, cette contrainte se traduit donc par plusieurs triggers.

@martinbrait4730 5 жыл бұрын

Bonjour :-), 44:54 Je suis choqué par la présence de cette identification relative. Quelle est votre réelle motivation pour associer modèle et marque, avec une identification relative ? Est-ce une astuce de "programmeur" pour accéder sans requête de jointure, à toutes les clefs utiles permettant de désigner un véhicule léger, depuis la même vue ? Dans un tel cas, pourquoi ne prolongez-vous pas la clef relative, entre les entités LEGER-MODELE-MARQUE, étant donné que la description complète d'un véhicule est : renault 5 4CV, par exemple ? La relation normale 1-n était-elle fautive ? Si oui, pourquoi ?

@E_mds 5 жыл бұрын

Il n'est pas possible de faire un lien relatif entre LEGER et MODELE car LEGER est une entité fille de VEHICULE donc elle a obligatoirement la même identification que VEHICULE. Le lien relatif entre MODELE et MARQUE permet juste de montrer le lien fort entre MODELE et MARQUE : un modèle n'a pas de vie propre, il dépend de sa marque. Encore une fois, on est dans une dépendance forte, du type "lien de composition".

@martinbrait4730 5 жыл бұрын

D'accord, je n'avais pas 'vu' la forme composée 'Renault 5'. En fait, j'étais focalisé sur les abréviations familières une 307, une 504, qui nous font tout de suite penser à la marque du constructeur (peugeot). J'oubliais qu'une 5, n'évoquait pas de façon aussi naturelle, un véhicule de la marque Renault. Je comprends qu'il s'agit de réunir dans la même table, les deux informations nécessaires à la désignation claire du véhicule.

@allahakbar382 2 жыл бұрын

Bonjour, Je vous félicite de votre manière d'exposer le contenu, vous possédez vraiment les savoirs savants transmis intelligemment aux savoirs à enseigner. Je me demande s'il est possible d'avoir les supports de cours; Merise, Merise 2 et UML, et si j'ai le droit de les utiliser pour objectifs pédagogiques ? Bien à vous.

@E_mds 2 жыл бұрын

Merci pour votre message. Pour chaque vidéo de cours, vous trouverez, dans la description, le lien vers le pdf correspondant. Vous pouvez l'utiliser pour faire vos cours.

@allahakbar382 2 жыл бұрын

Je vous remercie infiniment.

@martinbrait4730 6 жыл бұрын

à la minute 6:53, vous expliquez un usage pertinent du lien relatif. "Les dossiers comportent des fiches, dont la numérotation redémarre à 1 pour chaque dossier." Comment se passe l'implémentation du compteur de fiches, dans le SGBD, au niveau physique ? Pour la table FICHE, quelle est la bonne pratique, pour que le numéro de fiche/dossier s'incrémente automatiquement ? Faut-il ajouter par trigger, le max+1 du décompte de fiches pour le dossier considéré, dans la colonne numfiche ? Comment met on en œuvre les précautions pour éviter un conflit, dans le cas où 2 gestionnaires différents, ouvriraient séparément, le même numéro de fiche, pour un même dossier ? Auriez-vous l'extrême gentillesse de présenter l'exemple concret du cas DOSSIER 0n-(1,1)R FICHE, dans le cours sur les triggers / verrous, le cas échéant ? MERCI BEAUCOUP !

@E_mds 6 жыл бұрын

Effectivement, la numérotation ne peut plus être en incrémentation automatique gérée par le SGBDR. La solution du trigger sur l'insert dans fiche est très bonne. Le trigger va récupérer le numéro de fiche le plus élevé pour ce dossier et l'incrémenter de 1. Le fait que 2 insert arrivent simultanément ne doit à priori pas poser de problème car, sauf erreur de ma part, un trigger place automatiquement un verrou. Mais on peut toujours mettre un verrou en écriture sur la table fiche, entre le moment où on récupère le numéro le plus haut et le moment où l'on insère la nouvelle fiche avec le nouveau numéro. En revanche, lorsque vous suggérez que 2 personnes différentes ouvrent en même temps la même fiche du même dossier, cela ne pose aucun problème puisque l'on n'est que dans le cas de la lecture.

@martinbrait4730 6 жыл бұрын

'================================== Clef primaire et/ou clef alternative ? '=================================== Posons le cas suivant : numfiche est clef primaire d'identification relative, numérotant une fiche, par rapport à un numéro de dossier donné. Le gestionnaire crée un dossier TARTEMPION. A ce dossier TARTEMPION, il décide de créer 3 fiches : TARTEMPION/1 TARTEMPION/2 TARTEMPION/3 D'un coup, le gestionnaire se décide à supprimer définitivement la fiche numéro 2. Cette démarche fausse désormais le compteur d'autoincrément, si on l'utilise, sans procéder à une renumérotation de la série de fiches par dossier. Peut on considérer la colonne numfiche, comme une clef alternative, avec compteur ? Ajoute-ton au système, une colonne RefNumFiche, clef primaire autoincrement, d'identification relative, pour garantir la référence du dossier ? Solution 1 : colonne RefNumFiche, clef primaire (autoincrement technique), et colonne numfiche facultative, clef alternative (gérée par le gestionnaire) Dans le cas d'une suppression de la fiche 2, une renumérotation de toutes les fiches restantes du dossier, serait demandée à l'utilisateur, ou géré par trigger, dans la colonne numfiche de clef alternative facultative, sans perturber la colonne RefNumFiche, qui référence la fiche. Solution 2 : colonne numfiche a le role de clef alternative vue par le gestionnaire, et le role de clef primaire technique. Lorsque le gestionnaire supprime une fiche du dossier, porteuse d'un numéro intervallaire, un trigger décrémente automatiquement d'un pas de 1, tous les numéros de fiches, supérieurs, au numéro de la fiche qui est supprimée. Pour vous, quelle est la mise en oeuvre juste, simple et efficace, de l'identification relative, dans le MCD ?@@E_mds

@E_mds 6 жыл бұрын

Attention, le lien relatif doit fonctionner avec la même logique que l'auto-incrément proposé par le SGBDR : on avance toujours de 1 et si un tuple est supprimé, le numéro correspondant est perdu et non réutilisé. Du coup, dans l'exemple de la suppression de la fiche 2 parmi les 3 fiches, cela ne changerait pas le fait que la fiche suivante aurait le numéro 4. C'est beaucoup trop dangereux de modifier des valeurs d'identifiants, sachant qu'ils sont souvent reliés en foreign key. De toute façon, le SGBDR ne le permettrait pas (sauf sous certaines conditions. Si vous voulez vraiment pouvoir manipuler les numéros de fiches comme vous l'expliquez, alors il faut effectivement oublier la notions de lien relatif et mettre un identifiant indépendant, en auto-incrément. Le numéro de dossier sera uniquement en clé étrangère et le numéro de fiche (numéro de classement dans le dossier) sera un attribut simple.

@martinbrait4730 5 жыл бұрын

Bonjour Madame, Merci pour vos cours et vos réponses ! Des grandes questions ne sont pas traitées dans votre cours Merise2 : Comment représente-t-on les vues, avec windesign ? Les vues, doivent elles être modélisées dans le MCD ? Tables de références, ou domaine dans le SGBD Comment les représente-t-on avec windesign ? On devrait systématiquement créer des domaines, pour des valeurs invariables et générales : Civilité{M.;Mme}. On devrait au contraire systématiquement créer des tables de références, pour des valeurs variables et spécialisées, dont on anticipe les variations à l'initiative de l'utilisateur. (?)

@E_mds 5 жыл бұрын

Ce cours n'aborde que l'aspect conceptuel. Les vues ne sont pas représentées à ce niveau là, idem pour les autres outils directement liés au SGBDR. Win'design permet certainement de représenter certains de ces outils car il ne se limite pas au conceptuel, mais je n'ai pas touché à ces fonctionnalités. Votre dernière remarque me parait pertinente.

@hessamjoumail5251 6 жыл бұрын

Merci :) merci également pour le cours PDF

@martinbrait4730 5 жыл бұрын

A la minute 52:32, vous utilisez à plusieurs reprises l'identification relative. L'identification relative me semblait réservée à des dates historiques, et à des numéros de fiches. L'identification relative entre ville et pays, me semble porter sur 2 tables de référence. S'agit-il d'une identification relative de ville à pays, pour associer fortement ville et pays, au cas où un nom de ville soit le même, dans deux pays différents ? Quant à : "... mémoriser l'ordre par sous-activité...." Peut on dire qu'il faut dès que possible mémoriser un ordre de tri, via la numérotation de la clef primaire ? Peut on dire que la mémorisation de l'ordre de tri, par un attribut spécifique, n'est valable, que dans une table de référence, non impliquée dans une identification relative ? Lors des identifications relatives, est-il conseillé d'ajouter dans l'entité séjour, une clef secondaire autoincrémentée, afin de faire référence à un enregistrement unique via cette clef secondaire, plutôt que via la clef primaire composée idsejour+idville+idpays ?

@E_mds 5 жыл бұрын

Alors j'avoue, cet exercice use et abuse des identifiants relatifs. Le but est de montrer comment les repérer par rapport à un sujet : on est là surtout dans l'esprit de l'épreuve écrite du BTS SIO, ou l'étudiant doit être en mesure de repérer un identifiant relatif s'il est présenté dans le sujet. Les identifiants relatifs sont relatifs à un identifiant temporel (date, heure...) ou numérique (numéro de fiche mais pas seulement, numéro de n'importe quoi). L'identifiant relatif est "joli" au niveau conceptuel car il permet de faire ressortir des dépendances : les villes sont numérotés par pays (2e ville du 3e pays...), les sous activités sont numérotés par activité (3e sous activité de la 5e activité...) etc. Cela est indépendant des noms (2 villes peuvent avoir le même nom, mais ce n'est pas pour ça qu'on va utiliser un identifiant relatif plutôt qu'un identifiant classique, sachant que de toute façon le nom ne sera pas en identifiant). Lors du passage à la BDD, à l'heure actuelle de l'utilisation grandissante de l'ORM, on fait de plus en plus le choix d'insérer un id automatique dans toutes les tables issues d'entités (qu'elles aient un identifiant simple ou composé avec un id relatif). Rien n'empêche ensuite de garder cette numérotation secondaire en attribut simple. Cela dépend donc des choix stratégiques faits, en particulier par rapport au développement qui va exploiter la BDD.

@martinbrait4730 5 жыл бұрын

Merci pour votre réactivité ! @--,-;-))---- ... Rien n'empêche ensuite de garder cette numérotation secondaire en attribut simple. Cela dépend donc des choix stratégiques faits, en particulier par rapport au développement qui va exploiter la BDD. ... Dans mes projets, la clef secondaire auto-incrémentée, me permet d'extraire une ligne, issue d'une table d'historiqque. Par exemple, je référence l''affectation la plus récente d'une personne, depuis une table d'historique d'affectation. Je référence le grade le plus récent d'une personne, depuis une table d'historique de grade etc... Tellement pratique ! Je ne sais pas faire autrement. Qu'en pensez-vous ?

@E_mds 5 жыл бұрын

@@martinbrait4730 Si j'ai bien compris, vous avez par exemple une table Personne, une table Grade, une table Grade_Personne (issue d'une association entre Personne et Grade) qui contient un attribut numérique que vous incrémenté (par exemple par trigger) pour garder l'ordre d'affectation des grades à la personne ? Dans cet exemple, vous pourriez remplacer ce numéro par une date : le tri serait aussi très simple à gérer. Même principe pour l'affectation.

@martinbrait4730 5 жыл бұрын

@@E_mds Dans mon modèle, je dois stocker (en vue de restituer) les historiques de 3 tables : un historique des affectations d'un personnel un historique des grades d'un personnel un historique des échelons de grade d'un personnel. Je dois en outre, restituer dans mes formulaires et mes états, la dernière affectation, le dernier grade et le dernier échelon de grade du personnel. D'où ma mise en œuvre comme suit : t_histoaffectation : idpersonne,idposte, dataffectation,ks_autoaff t_histograde : idpersonne, idgrade, datgrade, ks_autograd t_histogradechelon : idpersonne,idechelongrade, datechelongrade, ks_autogradech t_etatcivilactuel : idpersonne,nom,pren,sexe, ks_autoderaff,ks_autodergrad,ks_autodergradech La règle est que tout agent a une affectation en cours avec date de dernière affectation, a un grade en cours avec date de dernier grade et un échelon de grade avec date de dernier échelon de grade. Par mise à jour mensuelle, je récupère la clef secondaire autoincrementée, de chaque dernière affectation, de chaque dernier grade, et de chaque dernier échelon de grade du personnel. Cela m'évite de créer une jointure , avec un calcul du max date de l'affectation de chaque idpersonne, du max date de grade de chaque idpersonne et du max datéchelon-grade de chaque idpersonne. Qu'en-pensez vous ?

@E_mds 5 жыл бұрын

@@martinbrait4730 Si je ne me trompe pas, dans la 1e table, (idpersonne, idposte) représente la clé primaire. Même logique pour les 2 tables suivantes. La 4e table ressemblerait plus à une vue alimentée lorsque c'est nécessaire : son contenu est redondant et pas assez stable pour être une table (qui devrait être en permanence mise à jour par trigger). De plus, dans le cadre d'une application multi-accès à la BDD, il faudrait proprement gérer les verrous pour éviter des incohérences dans la mise à jour de t_etatcivilactuel et surtout dans la génération des numéros d'ordre dans les 3 tables (si 2 requêtes d'insert se font en même temps dans l'une des tables). Du coup il me parait plus performant et surtout plus sécurisé de ne pas créer une 4e table, d'enlever les numéros d'ordre des autres tables et de faire des requêtes avec jointure en triant sur la date pour avoir le dernier tuple inséré.

@martinbrait4730 5 жыл бұрын

9:50, LIGNE_COM, contient une clef primaire composée de 3 identifiants : idcommande,idmeuble,idcouleur. Selon vous, faut-il s'astreindre à un nombre "raisonnable", d'identifiants qui composent une clef primaire ? Alain TURBY aurait substitué, une clef secondaire autonumérotée, à la place de idcommande,idmeuble,idcouleur, clef primaire composée. La clef secondaire autonumérotée devient alors clef primaire simple de l'association LIGNE_COM. Intérêt de cette démarche ? Qu'en pensez-vous ?

@E_mds 5 жыл бұрын

Fabriquer une nouvelle clé est toujours possible : on pourrait ainsi transformer toutes les associations en entité. Mais cette clé serait un attribut supplémentaire à gérer, et de plus, non porteur d'un sens précis. Du coup je n'en vois pas l'intérêt. En ce qui concerne la limite du nombre d'attributs pour constituer un identifiant, je ne me pose pas la question : plusieurs attributs ne me semblent pas être un frein aux performances car justement, généralement les recherches se font sur ces attributs.

@martinbrait4730 3 жыл бұрын

Bonsoir Madame, Je réécoute vos cours sur les bases de données, et je réalise à quel point ils sont remarquables. Merci beaucoup pour votre expertise, votre pédagogie et votre générosité. Bonne année !

@E_mds 3 жыл бұрын

Merci pour votre message. Bonne année à vous aussi (il est encore temps, c'est officiellement le dernier jour :) ).

@olivierb.3710 3 жыл бұрын

Merci et bravo

@thomasgmz5656 6 жыл бұрын

super travail bravo !

@martinbrait4730 6 жыл бұрын

Il me semble qu'à la minute 7:40, vous pouvez utiliser le logo de relation, triangulaire de couleur noire:=agrégation, sous windesign, pour symboliser le concept d'agrégation. Reste à expérimenter comment...

@E_mds 6 жыл бұрын

On obtient bien un losange noir lorsqu'on choisit le stéréotype "agrégation", mais comme il ne peut être relié à une association, ce n'est de toute évidence pas le même type d'agrégation.

@anuarmaa4090 5 жыл бұрын

merci ❤️

@martinbrait4730 5 жыл бұрын

Selon vous, table de référence, ou type ? Auriez-vous l'extrême gentillesse de me conseiller, s'il-vous-plaît. Je conçois une application de rangement, disposant des références suivantes : [AccessibiliteObjet] : avant-plan, plan-moyen, arrière-plan [SuiviObjet] : à ranger, rangé, à vendre, à donner, à offrir, à jeter [UsageObjet] : quotidien, hebdomadaire, mensuel, trimestriel, semestriel, annuel [EtatObjet] : occasion, usé, moyen, dégradé, neuf, périmé merci de détailler vos critères de mise en œuvre, je suis perdu !

@E_mds 5 жыл бұрын

Dans ce cas je ferais 4 tables car, dans chaque table, je peux imaginer de nouveaux tuples ou des modifications de libellés de tuples existants (voire des suppressions).

@martinbrait4730 5 жыл бұрын

5:37 Une identification relative, est par nature, une composition. Ainsi, il faut plusieurs fiches pour composer un dossier. Windesign propose une représentation particulière, dans la propriété variante de style 'composition'. Le petit rond blanc peut être échangé en petit losange blanc. Qu'en pensez-vous ?

@E_mds 5 жыл бұрын

J'ai effectivement remarqué que Win'design proposait un stéréotype de composition et d'agrégation dans le modèle Merise, alors que ces notions sont spécifiques au diagramme de classe. Utiliser ce visuel, pourquoi pas, à condition qu'il permette de générer correctement le modèle physique, et là, je n'ai pas testé et je n'en suis pas sûre du tout. Peut-être qu'il est pris en compte dans la transformation MCD vers diagramme de classes. A tester.

@martinbrait4730 6 жыл бұрын

Le cours de Bernard ESPINASSE est très bon. merise.developpez.com/tutoriels/ingenierie-systemes-informations/?page=partie-2-les-raisonnements-de-la-methode-merise-conception-du-systeme-d-information-organisationnel-sio. Est-ce que je peux abuser de votre gentillesse, en vous demandant la présentation par vidéo du chapitre II-D-3, des Contraintes de stabilité liées aux propriétés et des Contraintes de stabilité liées aux relations ? Votre façon très concrète de présenter est toujours extrêmement pédagogique et complète, jusqu'au détail de mise en place des contraintes, soit par fonction, soit par trigger. Les exercices d'assimilation sont très bien choisis. Votre façon de présenter nous aide à apprendre à ne pas confondre les situations.

@E_mds 6 жыл бұрын

La notion de stabilité fait juste référence au fait que certaines données ne doivent pas être modifiées, sous peine d'aller à l'encontre de l'intégrité de la base de données. Par exemple, un identifiant doit être stable dans le temps, donc ne doit pas être modifié. Idem pour un identifiant relatif. Les notions d'identifiant et d'identifiant relatif sont abordées dans mon cours, comme d'ailleurs la majorité des notions abordées dans l'article dont vous faites référence. J'ai juste synthétisé l'information, en cherchant aussi l'optimisation. Par exemple, dans certains cas, le choix des liens qui entourent une association n'est pas judicieux, le but étant de minimiser les liens pour minimiser les attributs qui constituent l'identifiant d'une relation. Tout ceci est expliqué dans mon cours "Modèle relationnel et MCD".

@martinbrait4730 3 жыл бұрын

44:52 Votre démonstration est impeccable. Pourquoi autoriseriez-vous une saisie directe de modèle et marque, dans la table LEGER ? L'absence de table de référence MODELE, MARQUE, mène tout droit aux innombrables erreurs orthographiques, et détériore l'efficacité des recherches.

@E_mds 3 жыл бұрын

Je découvre votre message : je n'avais pas reçu de notification. Là je me remettais dans le contexte de la demande de l'exercice qui visait à contrôler que la notion d'héritage était comprise. Cependant, vous avez vu que, naturellement, j'ai sorti modele et marque, car effectivement, c'est la meilleure solution.

@martinbrait4730 5 жыл бұрын

Bonjour, et désolé de vous solliciter si souvent ! Il existe deux grandes classes de TYPES : 1) Les types conformes à la norme SQL : bigint, bit, bit varying, boolean, char, character varying, character, varchar, date, double precision, integer, interval, numeric, decimal, real, smallint, time (avec et sans fuseau horaire), timestamp (avec et sans fuseau horaire), xml. 2) Les types supplémentaires, en dehors de la norme SQL (postgres, par exemple) www.postgresql.org/docs/9.1/datatype.html 8.2. Monetary Types 8.4. Binary Data Types 8.7. Enumerated Types 8.8. Geometric Types 8.9. Network Address Types 8.10. Bit String Types 8.11. Text Search Types 8.12. UUID Type 8.13. XML Type 8.14. Arrays 8.15. Composite Types 8.16. Object Identifier Types 8.17. Pseudo-Types J'ai beau tourner mes réflexions dans tous les sens, je reste perturbé par l'arrivée du type array. Utiliser le type array, pour remplacer une table de référence , en dépendance fonctionnelle... Est-ce une hérésie ? A quel usage le type array est il réellement dédié ? Au secours !

@E_mds 5 жыл бұрын

Il ne faut pas oublier que dans un SGBDR, on peut aussi coder (triggers, procédures stockées). Certains types vont être utiles dans ces cas là. On ne va pas utiliser un array en remplacement d'une table. Mais dans un programme, un array peut éventuellement servir.

@martinbrait4730 5 жыл бұрын

Une réponse extrêmement claire, merci infiniment ! Comment faire pour suivre des cours avec vous ? Exercez-vous en ce moment ?

@E_mds 5 жыл бұрын

@@martinbrait4730 Comment se fait-il que votre réponse apparait 6 fois ? Je fais partie de l'équipe pédagogique du CNED pour la préparation du BTS SIO.

@martinbrait4730 5 жыл бұрын

Bonjour Madame, Voici mes relations : t_etatcivil {} t_histoaffectation {} t_histograde {} t_histoegradechelon {} Voisi mes règles de gestion : Un personnel a un état civil. Un personnel a une affectation à une date donnée. Un personnel a un grade à une date donnée Un personnel a un échelon de grade, à une date donnée. (*ksautoval = clef secondaire champ numérique autoincrémentée par sgbd index d'unicité) t_personnel contient la pk :idpersonne t_haffectation contient la pk composée : idpersonne,idaffectation,dataffectation (IR de t_personnel) + *ksautoval ksaffectation t_hgrade contient la pk composée : idpersonne,idgrade,datgrade (IR de t_personnel) + *ksautoval ksgrade t_hgradechelon contient la pk composée : idpersonne,idgrade,datgrade,idechelon,datechelon (IR de t_hgrade,t_personnel) + *ksautoval ks_gradechelon Mes besoins : retrouver l'ancienneté affectation-grade-échelon : -lister la totalité des lignes d'affectation d'une personne -lister la totalité des grades obtenus par la personne -lister la totalité des échelons de grade, obtenus par la personne historiser par ref et date de mvt de mutation le tupple etatcivil-affectation-grade-échelon : -lister l'état civil complet, A chaque ouverture d'un mouvement de mutation, j'ai besoin de l'état civil, de la dernière ligne d'affectation d'une personne, du dernier grade, et du dernier échelon de grade. Ma solution : Comment retrouver mon état civil avec affectation, grade et échelon de grade RECENTS ? A chaque ouverture de mutation, j'importe dans la vue v_personne, les valeurs de clefs secondaires uniques qui m'intéressent : idpersonne de chaque idpersonne ksaffectation la plus récente de chaque idpersonne ksgrade le plus récent de chaque idpersonne ksgradechelon le plus récent de chaque idpersonne Voici le contenu de ma table t_personnel, en compréhension : t_personnel {idpersonne,nom,prenom,datnaiss,sexe,datetitu} Voici le contenu de ma vue v_personnel, en compréhension : v_personnel {idpersonne,fks_lastaffectation,fks_lastgrade,fks_lastechelon} Avantages ? J'évite une *triple jointure sur idpersonne grâce à l'utilisation des clefs secondaires J'évite par trois fois, une jointure, avec opérateur max appliqué sur une date *triple jointure : idpersonne-idaffectation,idpersonne-idgrade,idpersonne-idechelongrade Points forts, points faibles de mon choix de conception ?

@E_mds 5 жыл бұрын

Je découvre votre message par hasard, n'ayant pas reçu d'alerte (peut-être parce que vous l'avez modifié). L'utilisation d'une vue et non d'une table me parait déjà une meilleure solution. Mais une vue n'a pas besoin d'être mise à jour à chaque modification d'une table : une vue doit juste être exécutée au moment où l'on en a besoin. Le fait de réaliser plusieurs jointures pour obtenir une information ne me parait pas être un inconvénient, si l'exécution est ponctuelle (exécution de la requête au moment où l'on a besoin d'obtenir l'information). Mais en conclusion, je dirais surtout que l'important est que votre solution vous satisfasse et réponde à vos attentes.

@nasser4383 4 жыл бұрын

qui est la pro ?

@E_mds 4 жыл бұрын

je n'ai pas compris votre question

@ayoubseg 2 жыл бұрын

La contrainte d’intégrité fonctionnelle est : A - Une dépendance fonctionnelle non modifiable dans le temps B - Une dépendance fonctionnelle modifiable dans le temps C - Une contrainte sur les fonctions d’un acteur D - Une contrainte sur des données intégrées La contrainte d’intégrité référentielle : A - Interdit des doublons dans une clé primaire B - Permet de repérer les cardinalités au niveau physique C - Assure qu’un enregistrement enfant sera supprimé après l’enregistrement parent D - Permet de vérifier la présence des données référencées dans des tables différentes ????

@E_mds 2 жыл бұрын

Je dois répondre à votre place à un quiz de question de cours ? ;-)

@ayoubseg 2 жыл бұрын

@@E_mds Non , mais justement j'ai un doute concernant mes réponses . A pour le premier et D pour la deuxième .

@E_mds 2 жыл бұрын

@@ayoubseg Ok pour la première, mais en vrai, aucune ne me convient pour la seconde. L'intégrité référentielle permet de faire en sorte que le contenu d'une BDD reste cohérent. Par exemple, elle peut interdire la suppression d'un enregistrement si d'autres pointent sur lui (interdire la suppression d'une catégorie si des articles sont classés dans cette catégorie). La mise en place d'une intégrité référentielle permet de bloquer ce genre de traitement. Après, il faut avouer qu'on trouve des tas de nuances différentes dans les définitions de ces termes.

@martinbrait4730 3 жыл бұрын

42:19 L'énoncé du sujet me semble légèrement impropre. Vous choisissez de restituer l'entité pathologie, et non l'entité type de pathologie, qui serait en relation de 1 à plusieurs avec l'entité pathologie. :-!

@E_mds 3 жыл бұрын

En fait ici, une pathologie représente bien une maladie pour laquelle on peut prescrire des médicaments précis. Si vous considérez des types de maladies, donc un classement des maladies, ce serait par exemple en fonction des spécialités médicales, comme par exemple les maladies du coeur (cardiologue), du système nerveux (neurologue), etc. Donc ici, la prescription concerne bien la pathologie précise. Vous comprenez le principe ?

@martinbrait4730 3 жыл бұрын

@@E_mds Oui, principe parfaitement compris. Je tique juste sur le texte, car l'exercice nécessite qu'on se concentre sur le texte, vu qu'il nous sert à faire le schéma. Vous avez écrit "type de pathologie", et vous avez dessiné l'entité "pathologie". Votre schéma est parfaitement logique et compréhensible, mais votre énoncé nous fourvoie un peu en évoquant "type de pathologie".

@E_mds 3 жыл бұрын

@@martinbrait4730 Vous avez totalement raison, en vous répondant, je n'avais pas relu l'énoncé : dès le début j'aurais dû préciser "suivant la pathologie". J'avoue ne savoir pourquoi j'ai parlé de type. Ceci dit, cela ne doit pas inciter à faire 2 entités : dans le schéma proposé, il suffit de remplacer le nom de l'entité.