Discussion :

[Maeho]

Bonjour,

Je suis neophyte en création de base de donnéees. Je suis en train de créer un MCD pour modéliser une base de données d'entreprises. Ma premiere table est "entreprise" et contient tous les attribus d'une entreprise:SIREN (clef primaire) raison sociale, nombre d'employé...)

Je voudrais modéliser les liens qu'il y a entre les différentes entreprises. Par exemple l'entreprise 2 à le même gérant que l'entreprise 4 et l'entreprise 6. Je voudrais donc une table qui m'indique:l'entreprise 2,4 et 6 ont un lien (Ca serait bien également de mesurer la force de lien sur une echelle de 1 à 3 par exemple).

Comment dois-je m'y prendre?
Dois-je faire une relation reflexive?

J'utilise analyseSI (qui ne permet pas de faire des relations reflexives) mais j'ai aussi télécharger la version d'essaie de powerAMC et openModelsphere au cas où.
Je précise que ma base de donnéees sera sur Mysql via wamp une fois que tous sera ok.

Merci de votre aide

Maël

[CinePhil]

SIREN (clef primaire)

Mauvaise idée !

Par exemple l'entreprise 2 à le même gérant que l'entreprise 4 et l'entreprise 6. Je voudrais donc une table qui m'indique:l'entreprise 2,4 et 6 ont un lien (Ca serait bien également de mesurer la force de lien sur une echelle de 1 à 3 par exemple).

Nous sommes ici dans un forum sur la modélisation des bases de données donc on ne parle pas encore de table.

Règle de gestion :
Une entreprise est gérée par une personne et une personne peut gérer plusieurs entreprises.

MCD :
personne -0,n----gérer----1,1- entreprise

Quand on a fait les deux étapes précédentes, on peut passer aux tables :
te_personne_prs (prs_id, prs_nom, prs_prenom...)
te_entreprise_ent (ent_id, ent_id_gerant, ent_siren, ent_nom...)

[fsmrel]

Bonjour,

Quand on a fait les deux étapes précédentes, on peut passer aux tables :

te_personne_prs (prs_id, prs_nom, prs_prenom...)
te_entreprise_ent (ent_id, ent_id_gerant, ent_siren, ent_nom...)

Sans porter de jugement, on peut supposer que les habitués du forum interprètent sans problème les conventions que vous utilisez pour un nom de table ⁽¹⁾ ou de colonne, mais Maeho se présente comme néophyte, aussi avez-vous une référence à lui proposer qui explique ces conventions ? Dans « te_personne_prs », qu’est-ce que « te » ? « prs » ? A quoi cela sert-il ? Quelle règle conduit à établir une synonymie entre « ent_id_gerant » et » prs_id » ? Cela peut être déroutant pour un débutant qui ignore a priori les concepts de clé étrangère et de contrainte référentielle (en notant que vous vous privez de facto de la possibilité de coder FROM te_personne_prs NATURAL JOIN te_entreprise_ent).

Par ailleurs, quelle règle utilisez-vous pour renommer la colonne ent_siren puisque celle-ci participe à une clé candidate ?

_______________________
⁽¹⁾ Plus formellement : pour un nom de variable de table, car en toute logique table devrait être considéré comme l’abréviation de valeur de table , à savoir une valeur prise par une variable de type table.

[CinePhil]

Mon standard de nommage est inspiré de celui de SQLPro.

Dans "te_personne_prs" :
- te = table d'entité (issue d'une entité type du MCD) ;
- prs = acronyme mnémotechnique pour cette table des personnes et qui indique que les colonne de la table sont préfixée par cet acronyme, comme on le voit dans la composition de la table.

Je n'aime pas le NATURAL JOIN, justement parce qu'il ne précise pas sur quelles colonnes porte la condition de jointure ; je ne l'emploie jamais.

Quant à "ent_siren", c'est le même principe de nommage : cette colonne stocke le SIREN et fait partie de la table préfixée "ent" donc la table des entreprises nommée "te_entreprise_ent".

Maintenant, notre débutant fait ce qu'il veut pour nommer ses objets de BDD, tant qu'il ne s'aventure pas à utiliser comme nom un mot du langage SQL, ce que justement cette méthode de nommage empêche systématiquement.

[fsmrel]

Bonsoir,

Je voudrais modéliser les liens qu'il y a entre les différentes entreprises.

Si vous vous limitez à l’exemple que vous avez utilisé, celui des gérants, le modèle de CinePhil suffit puisque le lien entre les deux tables permet de répondre (par jointure) à la question : « Quelles entreprises ont même gérant ? »

Maintenant, si vous vous intéressez à des relations du genre : « Telle entreprise dépend de telle autre entreprise », alors il faut effectivement prévoir une association du genre (aux noms de rôles et aux cardinalités près) :

Mon standard de nommage est inspiré de celui de SQLPro.

Ce qu’on ne pouvait pas deviner. Si ce n’est pas encore fait, vous devriez publier votre propre grammaire. Au hasard, j’ai repéré des th, tj, tr dans vos messages, je subodore le sens que l’on peut donner à ces abréviations, mais quid pour les néophytes dont j’essaie de me faire l’avocat ?

Cela dit, ce que SQLpro et vous-même proposez n’est pas adapté à la modélisation des entreprises quand un système d’urbanisation (c'est-à-dire de référentiels) est en jeu. En l’occurrence, les administrateurs de données préfèrent préfixer le nom des entités-types par le nom des domaines/sous-domaines, et qui plus est, imposer la structure du nom de ces entités-types (contrainte imposée en fait par la production informatique, qui a par exemple besoin d’établir une bijection entre le nom des tables et le nom des fichiers de sauvegarde et autres : le nom GA_DOSSIER_SINISTRE est parlant mais peut donc poser un problème à la production, alors que son pseudo GA2002 n’en posera aucun. Pour l’anecdote, près de 25 ans après j’ai toujours en mémoire ce pseudo et quelques autres, mais il faut dire que la modélisation des sinistres avait alors posé quelques problèmes sympathiques).


Exemples de préfixes dans un contexte avec référentiels :

Référentiel Personnes : préfixe = « PE », sous-référentiel chapeau : « PEC » ; sous-référentiel Entreprises : « PEE » ; sous-référentiel Individus : « PEI », etc.

=>

Entité-type Personne : PEC0001, entité-type Entreprise : PEE0001, entité-type Etablissement : PEE0002, entité-type Individu : PEI0001, signalétique de l’individu : PEI0002, situation familiale : PEI0003 : etc.

Référentiel Contrats : préfixe = « CT », sous-référentiel Contrats : « CTA », sous-référentiel Affiliations : « CTF», sous-référentiel Modalités : « CTM», etc.

Référentiel Catalogue Produits : préfixe = « PR », etc.

Référentiel Habilitation : préfixe = « HA », etc.

Référentiel Prospection : préfixe « PS », etc.

Etc.

D’expérience, avec des référentiels représentant plus de mille entités-types , ce système que j’ai vu à l’épreuve dans de grandes entreprises permet de s’y retrouver et sans lui ça pourrait bien être les écuries d’Augias, voire la débâcle...

Par ailleurs, quand je vois qu’un nom commence par « te » ou « tr », c’est qu’on est dans un univers merisien (ou E/A), peuplé de carrés et d’ovales. Toutefois tel n’est pas le dans un contexte tel qu’IEF, où il n’y a que des carrés, même chose dans un contexte UML. Mais supposons qu’au niveau du MLD les tables aient été dérivées d’un MCD merisien : est-il essentiel que l’on sache qu’une table a été dérivée d’une entité-type plutôt que d’une association-type ? Serait-ce essentiel pour effectuer une rétroconception ? Un MCD ça vit dans le temps, donc que faire, quand par le jeu des maintenances, telle entité-type devient une association-type (ou l'inverse) ? Faudra-t-il répercuter cela dans la base de données en production, c'est-à-dire renommer te_xxx en tr_xxx ? Quid des multiples avatars de cette base de données (pré-production, réception, validation, études (projet X, projet y, etc.) ? Faudra-t-il recompiler tous les programmes touchés ? Renommer les fichiers de sauvegarde ? J’en passe et des meilleures. On dira plutôt : « Surtout ne touchons à rien ! Oublions que ce préfixe ne joue aucun rôle, sauf peut-être, et encore, pour le père du MCD » (qui depuis est parti exercer ses talents sous d’autres cieux...)

Je n'aime pas le NATURAL JOIN, justement parce qu'il ne précise pas sur quelles colonnes porte la condition de jointure ; je ne l'emploie jamais.

Vous affaiblissez le degré d’abstraction et vous prenez le contrepied de Codd (RIP) et Date sans lesquels on en serait resté aux bases de données hiérarchiques, navigationnelles et autres listes inverses, s’ils n’avaient justement élevé le degré d’abstraction. En proposant l’opérateur NATURAL JOIN, la norme SQL a repris strictement les écrits de Date, à ceci près que dans le contexte de la théorie relationnelle, pour effectuer la jointure naturelle de A et B on écrit simplement A JOIN B. Ainsi, la jointure est effectuée sur les attributs ayant même nom (et même type, cela va sans dire). Si deux attributs n’ont pas même nom, pour la jointure on en renomme un au sein de la requête à l’aide de l’opérateur RENAME (comme en SQL on renomme au moyen de AS). Autrement dit, la recommandation implicite de Date est la suivante : si le même attribut (par exemple l’identifiant de la personne) figure dans des tables différentes, donnons-lui le même nom.

Quant à "ent_siren", c'est le même principe de nommage : cette colonne stocke le SIREN et fait partie de la table préfixée "ent" donc la table des entreprises nommée "te_entreprise_ent".

Vous ne m’avez pas compris. La question que je pose est la suivante : comment faire ressortir le fait que cette colonne donne lieu à clé candidate ? Pour les clés primaires SQL, vous soulignez les noms, mais pour le autres clés, comment faites-vous ?

Pour ma part, je m’inspire de la grammaire relationnelle et j’appelle un chat un chat, une clé, une clé. Ainsi, pour reprendre votre exemple des personnes et des entreprises, en altérant le moins possible vos règles de nommage :

Code D :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
VAR Personne_prs BASE RELATION
     {prs_id, prs_nom, prs_prenon, ...}
    KEY {prs_id} ;

VAR Entreprise_ent BASE RELATION
     {ent_id, ent_id_gerant, ent_siren, ent_nom, ...}
    KEY {ent_id}
    KEY {ent_siren}
    FOREIGN KEY {ent_id_gerant} REFERENCES Personne {prs_id} ;

Maintenant, notre débutant fait ce qu'il veut pour nommer ses objets de BDD, tant qu'il ne s'aventure pas à utiliser comme nom un mot du langage SQL, ce que justement cette méthode de nommage empêche systématiquement.

Jusqu’au jour où... En effet, il arrive aussi à la norme SQL d’utiliser la structure xxx_yyy pour nommer les choses.

[Maeho]

Bonjour à tous et Merci pour vos réponse!! mais c'est pas fini

effectivement je m’intéresse au cas décrit par fsmrel car le lien peut être de n'importe quel nature (même dirigeant, entente particulière, structure commune...) ici je veux juste noter le lien.

Maintenant je voudrais exporter mon MCD dans Mysql (j'utilise phpmyadmin dans wamp). J'arrive à me connecter à la base de données mais je n'arrive pas à envoyer le MCD dans phpmyadmin (chose très facile avec AnalyseSI).
Une deuxième solution serait de générer le script SQL pour le soumettre dans phpmyadmin, mais la aussi je ne trouve pas la fonction.

Je rappelle que j'utilise modelsphere.

Connaissez-vous la méthode?

[fsmrel]

Bonjour Maeho,


Comme tous les SGBD SQL, MySQL ne connaît que SQL... Avec OMS (Open ModelSphere), il faut commencer par produire un MLD (modèle logique de données) à partir du MCD (modèle conceptuel de données), puis enfin le code SQL à partir du MLD.

Exemple, MCD source :



Il faut maintenant vérifier que le MCD ne comporte pas d'erreurs :

Outils > Modèle de données > Vérifier l’intégrité

Production du MLD

Quand le MCD est agréé par OMS (pas d'erreur détectée) :

Outils > Modèle de données > Convertir en modèle relationnel

Retenir le choix « Datarun ». Après quelques interventions quant à la présentation (cf. « Format > Style du projet »), le MLD devrai ressembler à ceci :


Une fois produit ce MLD produit, les tâches pénibles arrivent. L'ouvrir (disons avec l’explorateur d'OMS).

Il faut demander explicitement la génération des clés étrangères (alors que ce c... est capable d’effectuer automatiquement cette tâche, mais bon...) :

Outils > Modèle de données > Générer les clés étrangères

Outils > Modèle de données > Générer les règles référentielles

Quand tout vous paraît bon :

Outils > Modèle de données > Vérifier l’intégrité

Si c’est en grisé, c’est que tout est bon (a priori...)

Pour générer le code SQL de création des tables (dans un fichier xxx.SQL) :

Outils > Base de données > Génération

Si au cours de la génération, au lieu de ENTREPRISE et/ou DEPENDRE vous voyez des « ? », ça sent le roussi et les emm... car en général l’outil n’est pas très causant quant à la nature des erreurs. De toute façon il faut abandonner, chercher et corriger les erreurs.

Sur ce coup-là, je m’en suis bien sorti (un coup de pot !) :


Le script de création des tables figure dans le fichier dont le nom ressemble à "Maeho.SQL".

Bon courage !

[Maeho]

Merci Fsmrel pour toute cette aide!!

Finalement j'ai utilisé les 15 jours gratuits de powerAMC pour faire mon schéma.
Open modelsphere m'a un peu énervé, surtout avec la vérification des arcs sur un modèle merise et sur sa complexité général pour finalement faire des choses assez simple.

Salut