IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gestion des incidents dans une usine


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : février 2016
    Messages : 5
    Points : 9
    Points
    9
    Par défaut Gestion des incidents dans une usine
    Bonjour,

    Actuellement en dernière année d’école d’ingénieurs, je fais un stage d’une durée de 6 mois dans une usine de fonderie. Pour ce stage, on m’a mis « chef de projet » sur une application de gestion d’incidents dans l’usine (je suis tout seul sur le projet mais j’ai carte blanche sur les choix à faire pour réaliser cette application mis à part le choix du langage qui sera C#). Je m’explique :

    Je dois concevoir une application qui permet de déclarer un incident sur une machine (arrêts et pannes diverses) et réaliser un écran qui résume les incidents en cours ou résolus pour les chefs de production et les avertir dès que l’incident se produit. Ceci n’est qu’un résumé de l’application mais c’était pour que vous voyez le contexte.

    Donc, comme on me l’a appris, j’ai commencé par modéliser ma base de données à l’aide de Merise (au cours de mes études j’ai plutôt fait du UML mais là au moins ça me permet d’apprendre et ici ils préfèrent Merise)

    Nom : MCD1.jpg
Affichages : 4023
Taille : 315,8 Ko

    Donc j’ai quelques petites questions concernant surtout mes deux associations ternaires. Celle entre Incident SuivIncident et Machine pour moi est obligatoire (je peux me tromper hein), car je dois garder un historique de tous les incidents qui se sont produits. J’ai juste un problème au niveau des cardinalités est-ce bien ça ?

    Un incident donné ne peut se produire sur une et une seule machine et une machine peut n’avoir aucun incident ou plusieurs : pour ma table SuivIncident du coup je ne sais pas exactement ce qu’il faut mettre pour moi (1,1) me semble logique. Par contre pour la DateHeure de l’incident je ne sais pas si je la mets sur Se Produire ou sur la table SuivIncident ? Plutôt sur la table de suivi je pense

    Ensuite pour mon autre association ternaire j’ai dû la modéliser ainsi car un incident peut être pris en charge par un certain groupe de mainteneurs selon la nature de l’incident et son niveau (entendez par là la gravité). Ainsi différents groupes de salariés seront prévenus selon si c’est une panne mécanique ou s’il manque de la matière (etc..) et selon la gravité, des personnes plus ou moins qualifiés seront prévenus… Pour moi je dois le modéliser ainsi non ? J’ai fait le choix de ne pas mettre d’id pour la nature de l’incident car le nom sera unique et je trouve cela plus parlant. J’ai laissé les accents pour l’association « être lié à » pour bien qu’on comprenne.

    Le schéma n’est pas fini et je n’ai pas présenté l’autre partie de l’application qui sera la déclaration des pièces bonnes et mauvaises à chaque fin de poste et j’aurai d’autres questions à ce sujet mais déjà ça me paraît beaucoup ce que je demande et je m’en excuse. Donc ne regardez pas la partie SaisieProduction et ArretProduction pour l’instant. J’espère avoir été assez clair sur ma problématique.

    Merci pour votre aide !

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut Les ternaires...
    Bonsoir PanK7,



    Citation Envoyé par PanK7
    j’ai quelques petites questions concernant surtout mes deux associations ternaires. Celle entre Incident SuivIncident et Machine pour moi est obligatoire (je peux me tromper hein), car je dois garder un historique de tous les incidents qui se sont produits. J’ai juste un problème au niveau des cardinalités est-ce bien ça ?
    Selon les cardinalités portées par les pattes de l’association SeProduire, un incident participe une et une seule fois à l’association, un suivi d’incident y participe aussi une et une seule fois, tandis qu’une machine peut y participer de 0 à N fois. Ça c’est la lecture merisienne, laquelle n’est pas forcément la lecture uémélienne...

    Quoi qu’il en soit, selon la lecture merisienne (le verbe concerner est sémantiquement plutôt pauvre, mais on fera avec) :


    Un incident concerne une et une seule machine ;

    Un incident concerne un et un seul suivi ;

    Un incident concerne un et un seul moment (c'est-à-dire date et heure de l’incident) ;

    Un suivi concerne une et une seule machine ;

    Un suivi concerne un et un seul incident ;

    Un suivi concerne un et un seul moment ;

    Une machine est concernée par 0 à N incidents ;

    Une machine est concernée par 0 à N suivis ;

    Une machine est concernée par 0 à N moments ;

    Un moment concerne de 0 à N machines ;

    Un moment concerne de 0 à N incidents ;

    Un moment concerne de 0 à N suivis.


    Ces règles de gestion des données sont elles celles que vous auriez fournies ?

    Supposons que ce soit le cas. Si l’on traduit cela dans le cadre de la théorie relationnelle, on a la relvar (variable relationnelle) :


    SeProduire {IdIncident, IdSuiviIncident, IdMachine, DateHeureIncident} ;


    Et deux clés candidates, conséquences des cardinalités 1,1 merisiennes :


    K1 = {IdIncident}, K2 = {IdSuiviIncident}.


    La relvar respecte la cinquième forme normale, elle est donc valide et par conséquent votre association l’est aussi.


    Maintenant, le problème est que les AGL et outils de modélisation merisiens ne produisent pas forcément tous la même chose lors de la dérivation du MCD en MLD (donc ensuite en SQL)...


    Exemple avec DB-MAIN


    A partir du MCD suivant :





    On obtient le MLD valide :




    En effet {sid} et {iid} sont identifiants candidats de MIS (donc clés candidates).



    Exemple avec JMerise


    A partir du MCD (identique) suivant :






    On obtient le MLD non valide :





    En effet, la table MIS est seulement dotée d’une surclé {iid, sid, mid} et d’aucune clé candidate.


    Avant de poursuivre, quelle est votre position quant aux règles de gestion des données que j’ai conjecturées ? Merci de fournir les règles exhaustives concernant l’autre ternaire.


    N.B. Les cardinalités portées par les pattes de l’association AVOIR connectant les entités-types (et non pas les tables, car on est au niveau conceptuel) INCIDENT et NIVEAU_INCIDENT sont à permuter.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : février 2016
    Messages : 5
    Points : 9
    Points
    9
    Par défaut
    Bonjour fsmrel,

    Merci pour cette longue réponse détaillée. Tout d'abord, je tiens à préciser que j'ai toujours eu du mal à conceptualiser une application à l'avance. Je suis plutôt du genre à foncer tête baissée et de commencer à coder sans me demander de quoi je vais réellement avoir besoin => Ce qui est totalement idiot je vous l'accorde. C'est pourquoi je tente au cours de ce stage de faire les choses dans le respect de mon futur métier . Bref revenons à notre problématique.

    Citation Envoyé par fsmrel Voir le message
    Ces règles de gestion des données sont elles celles que vous auriez fournies ?
    Je suis tout à fait d'accord avec vos règles de gestion. J'ai juste eu du mal avec les trois suivantes mais maintenant c'est bon normalement :
    Citation Envoyé par fsmrel Voir le message
    Un moment concerne de 0 à N machines ;
    Un moment concerne de 0 à N incidents ;
    Un moment concerne de 0 à N suivis.
    Citation Envoyé par fsmrel Voir le message
    on a la relvar (variable relationnelle) :
    SeProduire {IdIncident, IdSuiviIncident, IdMachine, DateHeureIncident} ;
    Et deux clés candidates, conséquences des cardinalités 1,1 merisiennes :
    K1 = {IdIncident}, K2 = {IdSuiviIncident}.
    Je ne connaissais pas très bien ces notions mais grâce à votre cours je crois enfin comprendre.
    Ainsi avec un numéro d'incident je peux retrouver toutes les autres valeurs, pareil pour un numéro de suivi d'incident.

    Pas besoin de mettre une clef primaire de la sorte du coup si j'ai bien compris :
    SeProduire {IdIncident, IdSuiviIncident, IdMachine, DateHeureIncident}

    Alors que JMerise ferait cette traduction et cela deviendrait une "surclé" dont on n'a pas vraiment besoin compte tenu nos deux clés candidates précédentes. Dans le pire des cas je pourrai la créer moi-même la base de données en respectant strictement le schéma sauf aux endroits des associations ternaires non ?

    Citation Envoyé par fsmrel Voir le message
    La relvar respecte la cinquième forme normale, elle est donc valide et par conséquent votre association l’est aussi.
    J'avais vaguement entendu parlé de l'algorithme d'Armstrong au cours de mon cursus et des 2NF et 3NF mais pas plus loin. Je vais apprendre à l'aide de votre cours ces nouveaux concepts. Je crois déjà comprendre que c'est le fait d'aller plus loin au niveau des projections pour aller chercher d'autres dépendances fonctionnelles (mais je peux me tromper il faut que j'apprenne comme il faut).

    Citation Envoyé par fsmrel Voir le message
    Merci de fournir les règles exhaustives concernant l’autre ternaire.
    Les voici :

    Un groupe de salariés est concerné par un et un seul type d'incident (NatureIncident : d'ailleurs je vais peut-être changer le nom en TypeIncident) ; <== (Au minimum 1 type me semble logique sinon on ne formerait pas le groupe non?)

    Un groupe de salariés est concerné par un et un seul niveau d'incident ; <== (même justification que précédemment)

    Un niveau d'incident concerne 1 à N groupes de salariés ; <== (On formera par exemple 2 groupes pour les incidents très urgents/graves mais selon la nature de l'incident, l'un des groupes sera appelé plutôt que l'autre)

    Un niveau d'incident ??? "concerne" ou "est lié à" 1 à N types d'incident ; <== (un niveau d'incident peut être lié au minimum à un type forcément sinon il n'existerait pas et n'importe quel autre type)

    (Certains salariés pourront appartenir à plusieurs groupes selon leurs compétences)
    Je me rends compte que je n'ai pas du tout été assez clair au niveau de cet entité NiveauIncident.
    Il peut y avoir 3 Niveau d'incidents :
    Le premier niveau : c'est un incident qui a été déclaré très récemment
    Le deuxième niveau : c'est un incident qui a été déclaré depuis un certain temps
    Le troisième niveau : c'est un incident qui a été déclaré depuis longtemps

    Ces périodes sont paramétrables par les chefs de production c'est pourquoi j'ai l'attribut DeltaTempsNiveauIncident dans mon entité NiveauIncident.
    En fonction du niveau de l'incident différents groupes seront prévenus, de même qu'en fonction du type de l'incident différents groupes seront prévenus
    Le niveau et le type fonctionne de pair pour déterminer le groupe de salariés à prévenir (mais ça je pense que vous l'aviez déjà compris)
    Je ne sais pas du coup si c'était une bonne manière de modéliser ainsi ?

    Citation Envoyé par fsmrel Voir le message
    N.B. Les cardinalités portées par les pattes de l’association AVOIR connectant les entités-types (et non pas les tables, car on est au niveau conceptuel) INCIDENT et NIVEAU_INCIDENT sont à permuter.
    Disons que je comptais gérer ceci depuis mon application. Je m'explique : au moment de la déclaration d'un incident je fais partir un timer => dés qu'il a atteint le DeltaTempsNiveauIncident => je le fais passer en niveau 2 tout en faisant un update du niveau dans la bdd
    Du coup à l'incident n°48 (par exemple) il y aura plusieurs niveaux différents possibles selon le temps qu'il s'est passé non ? Peut être que je me mélange les pinceaux sur ce dernier point (trop d'informations d'un coup )


    Encore un grand merci pour le temps que vous me consacrez !

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut
    Bonsoir PanK7,



    Citation Envoyé par PanK7
    je tiens à préciser que j'ai toujours eu du mal à conceptualiser une application à l'avance.
    Raison de plus pour ne pas hésiter à prendre le temps de tartiner les règles de gestion des données, ad nauseam, d’autant plus que scripta manent...



    Citation Envoyé par PanK7
    Je suis tout à fait d'accord avec vos règles de gestion. J'ai juste eu du mal avec les trois suivantes mais maintenant c'est bon normalement :

    Un moment concerne de 0 à N machines ;
    Un moment concerne de 0 à N incidents ;
    Un moment concerne de 0 à N suivis.
    Evidemment, le verbe « concerner » n’est pas le plus approprié, il eut été préférable d’écrire : « au même moment plusieurs machines peuvent tomber en panne ». En fait, le but pour moi est de découvrir l’ensemble des dépendances fonctionnelles pour une relvar, donc pouvoir en inférer les clés candidates et vérifier si au moins la forme normale de Boyce-Codd est respectée. Quand c’est réglé au niveau relationnel, ça l’est aussi au niveau MCD.



    Citation Envoyé par PanK7
    Pas besoin de mettre une clef primaire de la sorte du coup si j'ai bien compris :

    SeProduire {IdIncident, IdSuiviIncident, IdMachine, DateHeureIncident}
    Si le triplet {IdIncident, IdSuiviIncident, IdMachine} était clé primaire, cela voudrait dire qu’un incident pourrait faire l’objet de plusieurs suivis, et concerner (sic !) à la fois plusieurs machines, même chose pour les suivis, chacun d’eux pouvant concerner plusieurs machines, etc... Le triplet est une surclé, laquelle ne respecte pas la règle d’irréductibilité des clés candidates, on ne le retient donc pas. En revanche, à partir des dépendances fonctionnelles, on calcule la fermeture des sous-ensembles d’attributs de l’en-tête de la relvar, afin de découvrir mécaniquement les fameuses clés candidates. Ainsi, les deux sous-ensembles singletons {IdIncident} et{IdSuiviIncident} ont pour fermeture le quadruplet {IdIncident, IdSuiviIncident, IdMachine, DateHeureIncident}, c'est-à-dire l’ensemble des attributs de l’en-tête de la relvar : ce sont donc des clés candidates (et les seules du reste). Le triplet {IdIncident, IdSuiviIncident, IdMachine} a lui aussi pour fermeture le quadruplet, mais ne respecte pas la règle d’irréductibilité des clés candidates : c’est une surclé, mais ne donnant pas lieu à clé candidate.



    Citation Envoyé par PanK7
    JMerise ferait cette traduction et cela deviendrait une "surclé" dont on n'a pas vraiment besoin compte tenu nos deux clés candidates précédentes. Dans le pire des cas je pourrai la créer moi-même la base de données en respectant strictement le schéma sauf aux endroits des associations ternaires non ?
    Que son auteur ne m’en veuille pas, mais je dos dire que je n’ai aucune confiance dans ce que produit JMerise au stade MLD, donc SQL : tout doit être minutieusement vérifié et corrigé.

    Vous pouvez continuer à utiliser cet outil pour conserver les schémas dans le dossier de conception, pour servir de support aux discussions avec la maîtrise d’œuvre ou la maîtrise d’ouvrage, mais pour produire un MLD et le code SQL, soit vous passez à DB-MAIN (gratuit et produisant des MLD conformes), soit vous reprenez la structuration cette fois-ci des tables avec MySQL Workbench. DB-MAIN est un peu déroutant quand on débute, mais c’est un outil fiable. Avec MySQL Workbench, vous n’avez pas le niveau MCD, vous êtes directement au niveau MLD, ce qui est plutôt « confortable ».



    Citation Envoyé par PanK7
    J'avais vaguement entendu parlé de l'algorithme d'Armstrong au cours de mon cursus et des 2NF et 3NF mais pas plus loin.
    Bill Armstrong n’a pas pondu un algorithme mais un ensemble d’axiomes ! Les axiomes d’Armstrong, ceux-là qui justement permettent de calculer la fermeture d’un ensemble de dépendances fonctionnelles et, au bout du compte, de vérifier par exemple la validité des ternaires merisiennes...



    Citation Envoyé par PanK7
    Le niveau et le type fonctionnent de pair pour déterminer le groupe de salariés à prévenir
    Autrement dit, un groupe de personnes ne peut intervenir que par rapport à une paire précise {type d’incident, niveau d’incident}, c'est-à-dire que les paires <Ti, Nj> sont préétablies en amont (indépendamment) des groupes de personnes. S’il en est bien ainsi, votre MCD ne rend pas compte de la chose, il permet seulement d’associer un groupe G1 au type d’incident T1 et au niveau d’incident N1 alors que la paire <T1, N1> ne fait peut-être pas partie de celles qui ont été préétablies. Suis-je en phase ?

    Si oui, on a entre NIVEAU_INCIDENT et TYPE_INCIDENT une association R1 telle que :


    [NIVEAU_INCIDENT]--1,N----------(R1)----------1,N--[TYPE_INCIDENT]


    Et il va falloir établir une association R2 entre R1 et GROUPE, mais Merise interdit la connexion entre R1 et R2... On est dans contexte de l’agrégation au sens entité-association du terme, auquel cas le plus simple est de transformer R1 en entité-type identifiée relativement à NIVEAU_INCIDENT et TYPE_INCIDENT (voyez aussi ici).



    Citation Envoyé par PanK7
    Du coup à l'incident n°48 (par exemple) il y aura plusieurs niveaux différents possibles selon le temps qu'il s'est passé non ?
    Pourquoi pas, mais comme les niveaux sont apparemment prédéfinis, un niveau donné devrait pouvoir concerner plusieurs incidents, d’où une association de plusieurs à plusieurs :


    [NIVEAU_INCIDENT]--0,N----------(AVOIR)----------1,N--[INCIDENT]


    Cela dit, a-t-on besoin de savoir quel groupe est intervenu pour un incident donné ?


    En passant, n’oubliez pas de voter pour les messages qui ont pu vous aider, et confirmer ici des médailles acquises sur différents terrains, souvent accidentés...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  5. #5
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : février 2016
    Messages : 5
    Points : 9
    Points
    9
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Vous pouvez continuer à utiliser cet outil pour conserver les schémas dans le dossier de conception, pour servir de support aux discussions avec la maîtrise d’œuvre ou la maîtrise d’ouvrage, mais pour produire un MLD et le code SQL, soit vous passez à DB-MAIN (gratuit et produisant des MLD conformes), soit vous reprenez la structuration cette fois-ci des tables avec MySQL Workbench. DB-MAIN est un peu déroutant quand on débute, mais c’est un outil fiable. Avec MySQL Workbench, vous n’avez pas le niveau MCD, vous êtes directement au niveau MLD, ce qui est plutôt « confortable ».
    J'ai pris DB-MAIN et je tente de refaire le schéma, juste une question : pour avoir une clef primaire en auto_increment il faut que mon attribut soit de type séquence ? (pour SQL Management Studio)

    Citation Envoyé par fsmrel Voir le message
    Autrement dit, un groupe de personnes ne peut intervenir que par rapport à une paire précise {type d’incident, niveau d’incident}, c'est-à-dire que les paires <Ti, Nj> sont préétablies en amont (indépendamment) des groupes de personnes. S’il en est bien ainsi, votre MCD ne rend pas compte de la chose, il permet seulement d’associer un groupe G1 au type d’incident T1 et au niveau d’incident N1 alors que la paire <T1, N1> ne fait peut-être pas partie de celles qui ont été préétablies. Suis-je en phase ?

    Si oui, on a entre NIVEAU_INCIDENT et TYPE_INCIDENT une association R1 telle que :

    [NIVEAU_INCIDENT]--1,N----------(R1)----------1,N--[TYPE_INCIDENT]

    Et il va falloir établir une association R2 entre R1 et GROUPE, mais Merise interdit la connexion entre R1 et R2...
    C'est exactement ça ! Je ne savais pas comment le modéliser sur mon schéma. Du coup j'ai tenté de le faire ainsi à l'aide de vos explications :
    Nom : MCDV3.jpg
Affichages : 1519
Taille : 223,9 Ko

    NIV_TYP_INCIDENT sera identifié par le couple (IdNiveauIncident, NomTypeIncident) du coup ? (Je vais peut être mettre un id pour l'entité TYPE_INCIDENT par soucis de lisibilité)
    Ensuite c'est ce couple qui déterminera quel groupe choisir. Cela me semble pas mal

    Je me rends compte que j'ai peut être inversé les cardinalités. (Ce doit être des restes d'UML )

    Un Niveau + un type d'incidents concerne un et un seul groupe de salariés
    Un groupe de salariés est concerné par un ou N couples (Niveau et type d'incident) différents.

    Le dernière phrase me semble fausse car je comptais vraiment spécialiser mes groupes en fonction du type et de la gravité d'un incident du coup il faudrait mettre (1,1) des deux côtés mais c'est impossible non ?
    Je suis d'accord avec vous pour les cardinalités entre NIVEAU_INCIDENT et INCIDENT je m'étais pas posé les bonnes questions

    Citation Envoyé par fsmrel Voir le message
    Cela dit, a-t-on besoin de savoir quel groupe est intervenu pour un incident donné ?
    Pas forcément, c'est surtout le nom de la personne qui est intervenue qui doit être relevé. Selon la gravité et le type d'incidents on prévient un groupe mais seule une personne répond à "l'appel" et intervient sur la machine.
    Merci encore

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut
    Bonsoir PanK7,



    Citation Envoyé par PanK7
    pour avoir une clef primaire en auto_increment il faut que mon attribut soit de type séquence ? (pour SQL Management Studio)
    Le type SEQUENCE permet effectivement l’auto-incrémentation pour un attribut. Avec la version que j’ai installée de DB-MAIN (9.2.b), c’est bon avec MySQL et PostgreSQL, et c’est tout. Quel est (sera) votre SGBD ? (SQL Management Studio ne permet pas de savoir s’il s’agit de MySQL, PostgreSQL, SQL Server, et sans doute d’autres, ils ont tous le leur...)

    En tout cas, vous pouvez faire un test d’auto-incrémentation. Dans la barre de menus : FILE > GENERATE.


    Maintenant, quel intérêt réel a-t-on à mettre en œuvre une entité-type SUIVI_INCIDENT ? Il y a bijection avec INCIDENT, autrement dit pourquoi ne pas se simplifier la vie ainsi (suivi Incident donne lieu à un identifiant alternatif, donc à une clé candidate au stade relationnel) :







    Association POSSEDER :

    L’effet Dagobert a joué, UML est encore là : les cardinalités sont à permuter pour l’association POSSEDER.


    Entité-type TYPE_INCIDENT

    Attention à l’identifiant de l’entité-type TYPE_INCIDENT : tout identifiant primaire, principal doit être artificiel, c'est-à-dire qu’il ne doit être porteur d’aucune signification, il est donc d’une stabilité absolue, parfaitement invariant. A ce sujet, voyez le billet De l’invariance des clés primaires, plus particulièrement la règle d’or de Tabourier. Si un attribut candidat à être identifiant est « naturel », sujet à modification (en l’occurrence NomTypeIncident), alors ils deviendra identifiant alternatif (il conserve sa propriété d’unicité), et il faudra définir un identifiant primaire artificiel, par exemple IdTypeIncident.


    Identification de NIV_TYPE_INCIDENT :

    Inutile de définir un identifiant supplémentaire. On utilise l’identification relative : NIV_TYPE_INCIDENT hérite de l’identifiant de NIVEAU_iNCIDENT via l’association NTI_NI et de celui de TYPE_INCIDENT via l’association NTI_TI :





    On peut par exemple considérer NIV_TYPE_INCIDENT comme associée à NIVEAU_iNCIDENT par une relation de composition à la UML.

    Pout parvenir à cela avec DB-MAIN, voyez l’exemple ici.


    Je regarderai la suite plus tard...



    Accessoirement, pour produire un MLD à partir du MCD :


    1) Dans la barre de menus, vous sélectionnez :


    Product > Copy product


    2) A la demande de DB-MAIN, vous donnez un nom au nouveau schéma. Vous affichez ce schéma, lequel est la copie du premier, et dans la barre de menus, vous sélectionnez :


    Transform > Relational Model


    Pour voir le script SQL qui en résulte :


    File > Generate > nom de votre SGBD
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  7. #7
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : février 2016
    Messages : 5
    Points : 9
    Points
    9
    Par défaut
    Bonjour,

    Mon SGBD sera SQL Server, je testerai en temps voulu si l'attribut séquence me génère bel et bien une clef primaire en auto_increment, merci.
    Citation Envoyé par fsmrel Voir le message
    Maintenant, quel intérêt réel a-t-on à mettre en œuvre une entité-type SUIVI_INCIDENT ? Il y a bijection avec INCIDENT, autrement dit pourquoi ne pas se simplifier la vie ainsi (suivi Incident donne lieu à un identifiant alternatif, donc à une clé candidate au stade relationnel) :
    Après réflexion, on pourrait carrément enlever cet entité et même ne pas la reporter dans l'entité INCIDENT car j'ai juste besoin de savoir quand un incident est survenu non ? J'étais parti sur cette modélisation car je dois garder un historique de tous les incidents qui se sont produits mais si je fais rentrer la date & l'heure d'un incident sur l'entité INCIDENT j'aurai toutes les informations dont j'ai besoin.

    Cependant on vient de me dire qu'il faudra connaitre l'état d'un incident c'est à dire s'il est simplement déclaré (donc en cours), s'il est pris en charge ou s'il est résolu, avec à chaque fois la date et l'heure des étapes de maintenance (déclaré/résolu/pris en charge) pour avoir un meilleur suivi. Du coup je dois laisser l'entité SUIVI_INCIDENT pour stocker à chaque fois l'heure à chaque changement d'étape non ? Désolé je ne suis pas très bon pour voir cela


    Citation Envoyé par fsmrel Voir le message
    Association POSSEDER :

    L’effet Dagobert a joué, UML est encore là : les cardinalités sont à permuter pour l’association POSSEDER.
    Très juste, surtout qu'elles sont justes sur mon premier schéma c'est corrigé, merci !

    Citation Envoyé par fsmrel Voir le message
    Entité-type TYPE_INCIDENT

    Attention à l’identifiant de l’entité-type TYPE_INCIDENT : tout identifiant primaire, principal doit être artificiel, c'est-à-dire qu’il ne doit être porteur d’aucune signification, il est donc d’une stabilité absolue, parfaitement invariant. A ce sujet, voyez le billet De l’invariance des clés primaires, plus particulièrement la règle d’or de Tabourier. Si un attribut candidat à être identifiant est « naturel », sujet à modification (en l’occurrence NomTypeIncident), alors ils deviendra identifiant alternatif (il conserve sa propriété d’unicité), et il faudra définir un identifiant primaire artificiel, par exemple IdTypeIncident.
    C'est ce que j'avais retenu des différents cours que j'ai eu à ce sujet, je vais le corriger.

    Citation Envoyé par fsmrel Voir le message
    Identification de NIV_TYPE_INCIDENT :

    Inutile de définir un identifiant supplémentaire. On utilise l’identification relative : NIV_TYPE_INCIDENT hérite de l’identifiant de NIVEAU_iNCIDENT via l’association NTI_NI et de celui de TYPE_INCIDENT via l’association NTI_TI :
    Oui c'est ce que j'ai voulu dire dans ma phrase "NIV_TYP_INCIDENT sera identifié par le couple (IdNiveauIncident, NomTypeIncident) du coup ?"
    Mais je dois sûrement mal m'exprimer ou du moins ne pas employer les bons termes

    Citation Envoyé par fsmrel Voir le message
    On peut par exemple considérer NIV_TYPE_INCIDENT comme associée à NIVEAU_iNCIDENT par une relation de composition à la UML.

    Pout parvenir à cela avec DB-MAIN, voyez l’exemple ici.
    Merci je m'en occupe demain
    Et merci pour l'aide sur l'utilisation de DB-MAIN
    Et un dernier merci (encore !) pour le temps que vous me consacrez

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    7 588
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 7 588
    Points : 28 997
    Points
    28 997
    Billets dans le blog
    16
    Par défaut Suivi des incidents, historisation
    Bonsoir PanK7,



    Citation Envoyé par PanK7
    Du coup je dois laisser l'entité SUIVI_INCIDENT pour stocker à chaque fois l'heure à chaque changement d'étape non ?
    Exact ! Dans l’esprit de la théorie relationnelle, on va mettre en œuvre une entité-type SUIVI_INCIDENT permettant de conserver la trace, d’historiser les incidents résolus. Par analogie avec UML, cette entité-type entretient une relation de composition avec l’entité-type MACHINE, ce qui en Merise conduit à utiliser l’identification relative, qu’on a déjà évoquée. L’entité-type SUIVI_INCIDENT est dédiée aux incidents passés, elle est donc non seulement dotée d’une date de début d’incident, mais aussi d’une date de fin (ou d’une durée, au choix). En théorie, il s’agit d’une période, mais je ne sais pas si SQL Server propose ce type. Pour sa part, l’entité-type INCIDENT est dédiée aux incidents en cours, elle est donc dotée d’une date de début, mais pas de date de fin (of course) :





    Vous pouvez bien sûr associer SUIVI_INCIDENT à d’autres entités-types, par exemple TYPE_INCIDENT.

    A noter que l’entité-type INCIDENT est ici identifiée relativement à MACHINE. EN effet, quelle serait la raison de vivre d’un incident si la machine qui l’a subi disparaissait de la base de données ? (Encore une relation de composition...) Même motif pour l’entité-type SUIVI_INCIDENT.

    Comme méditation sur le sujet de l’historisation, je vous renvoie au paragraphe « Données actives et données historisées » de l’article Bases de données relationnelles et normalisation : de la première à la sixième forme normale, dans lequel je survole le sujet, et pour aller beaucoup plus avant, voyez l’ouvrage de Date, Darwen et Lorentzos, Time and Relational Theory, Temporal Databases in the Relational Model and SQL.



    Citation Envoyé par PanK7
    c'est ce que j'ai voulu dire dans ma phrase "NIV_TYP_INCIDENT sera identifié par le couple (IdNiveauIncident, NomTypeIncident) du coup ?"
    Pas de problème, au stade SQL, la clé primaire de la table NIV_TYP_INCIDENT sera la paire {IdNiveauIncident, IdTypeIncident} (et non pas la paire {IdNiveauIncident, NomTypeIncident}, l’attribut NomTypeIncident ne convenant pas pout l’identification).


    A suivre, il y a du pain sur la planche. Je suis obligé de vous quitter, car notre biologiste est en train de faire des mélanges explosifs, il faut que je lui vienne en aide...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2016
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : février 2016
    Messages : 5
    Points : 9
    Points
    9
    Par défaut
    Bonjour,

    Citation Envoyé par fsmrel Voir le message
    L’entité-type SUIVI_INCIDENT est dédiée aux incidents passés, elle est donc non seulement dotée d’une date de début d’incident, mais aussi d’une date de fin (ou d’une durée, au choix). En théorie, il s’agit d’une période, mais je ne sais pas si SQL Server propose ce type. Pour sa part, l’entité-type INCIDENT est dédiée aux incidents en cours, elle est donc dotée d’une date de début, mais pas de date de fin (of course) :
    Il existe le type de données Time chez SQL Server mais il me semble que DB-MAIN ne le propose pas. Pour l'instant je les mets en type Date, après je pourrai toujours les modifier directement une fois la base générée non ?
    Au pire des cas je stocke que les datesDeb et datesFin d'un incident et je gère mon Timer depuis mon application !
    J'ai mis un Id pour SUIVI_INCIDENT mais c'est vrai que s'il est identifié par la date de début et l'heure d'un incident (déjà cela suffit à l'identifier de manière unique si on est au centième près en précision) + l'id de la machine c'est bon mais c'était pour rester dans la logique de toujours mettre un ID sur une clef primaire
    Voici mon schéma à l'heure actuelle :
    Nom : MCDV4.jpg
Affichages : 1905
Taille : 259,5 Ko

    Citation Envoyé par fsmrel Voir le message
    Vous pouvez bien sûr associer SUIVI_INCIDENT à d’autres entités-types, par exemple TYPE_INCIDENT.
    Justement, à ce niveau là je ne sais plus quoi faire ! Étant donné que l'entité TYPE_INCIDENT est déjà relié à mon entité INCIDENT je pourrai toujours savoir le type d'incidents qui est survenu non ? Ou alors je dois relier l'entité SUIVI_INCIDENT à mon TYPE_INCIDENT pour garder un historique des types d'incidents qui se sont produits ? Je suis perdu mais je pense que c'est la deuxième solution

    Citation Envoyé par fsmrel Voir le message
    A noter que l’entité-type INCIDENT est ici identifiée relativement à MACHINE. EN effet, quelle serait la raison de vivre d’un incident si la machine qui l’a subi disparaissait de la base de données ? (Encore une relation de composition...) Même motif pour l’entité-type SUIVI_INCIDENT.
    Très juste

    Citation Envoyé par fsmrel Voir le message
    A suivre, il y a du pain sur la planche. Je suis obligé de vous quitter, car notre biologiste est en train de faire des mélanges explosifs, il faut que je lui vienne en aide...
    Haha
    Pas de problème merci et bonne chance

Discussions similaires

  1. [VB2005] Gestion des évenement dans une fonction
    Par arnolem dans le forum Windows Forms
    Réponses: 8
    Dernier message: 24/07/2006, 10h07
  2. Gestion des buffers dans une fonction
    Par JiJiJaco dans le forum Langage
    Réponses: 2
    Dernier message: 06/01/2006, 12h20
  3. gestion des utilisateurs dans une solution 3-tiers
    Par nadia lydia dans le forum Oracle
    Réponses: 3
    Dernier message: 26/10/2005, 13h58
  4. [Conception] Gestion des accents dans une base de données
    Par MiJack dans le forum PHP & Base de données
    Réponses: 7
    Dernier message: 07/07/2005, 12h41
  5. [VB6] Gestion des erreurs dans une dll
    Par zimba-tm dans le forum VB 6 et antérieur
    Réponses: 8
    Dernier message: 02/08/2004, 12h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo