Discussion :

[NicolasGrabo]

Salut à toutes et tous!

Actuellement en apprentissage dans une entreprise de contrôle technique, j'ai pour but, durant le mois de juillet, de créer une base de données des clients privés de l'entreprise, afin de pouvoir identifier quels clients travaillent avec quel architecte, quel client travaille avec quel bureau d'études, etc...

Avec les requêtes, nous pourrons donc ensuite avoir une meilleure vision des données, et identifier les acteurs qui travaillent ensemble. Cela nous nous facilitera la tâche lorsque nous répondons à des appels d'offre.

Pour répondre à ce problème, j'ai pensé à un modèle de base que je vous montre ci-après :



Qu'en pensez-vous? N'y aura-t-il pas d'erreurs? De doublons?

Merci de vos réponses!

Nicolas

[SQLpro]

1) les mêmes attributs doivent avoir les mêmes noms et ce n'est pas le cas avec vos # (clef primaire/clef étrangère)
2) lorsque vous voyez des colonnes dont le nom se termine par 1, 2, 3, c'est que c'est mal modélisé, car ces colonnes devrait être dans une table fille.
Que ferez vous si l'on vous demande quel client est domicilié "144 av des mimosas" ?
3) si les mêmes attributs sont visible dans différentes entités le modèle est faux. Par exemple pour CP/Ville il y a redondance. Vous devez faire une entité adresse pour toutes les adresses. Utilisez éventuellement l'héritage pour ce faire.
4) un client comme un archi est une personne. Ou est l'entité personne ?

A lire : http://sqlpro.developpez.com/cours/m...tion/heritage/

A +

[NicolasGrabo]

Merci pour ta réponse!

Pour les CP/ville je ne comprends pas bien ce qui cloche!

Un client est une entité, tout comme l'architecte.

Là, c'est mieux? (Au pire, si c'est faux, ce n'est pas grave, car le patron a dit que l'on pouvait faire ce genre de chose avec le logiciel Pythagore que l'entreprise a. Bref, à voir! Mais je mettrai sans doute le modèle le plus correct possible dans mon mémoire)

[CinePhil]

Un architecte et un bureau d'étude ne peuvent participer qu'à une seule affaire dans ton schéma !

Comme les trois entités d'adresse sont identiques, on peut les généraliser.
Et comme les clients, les bureaux d'études et les architectes ont les mêmes attributs, on peu aussi les généraliser en tant qu'organisme.

On pourrait avoir ainsi le MCD suivant :
Affaire -0,n----Participer----0,n- Organisme -0,n----Avoir----1,n- Adresse -1,1----Situer----0,n- Ville
Role -0,n-------------|

Affaire -1,1----Situer----0,n- Ville

Organisme -1,n----Avoir----1,1- Contact

Ce qui donnerait par exemple les tables suivantes :
Role (r_id, r_libelle)
Ville (v_id, v_nom)
Affaire (af_id, af_id_ville, af_designation, af_code_postal, af_prix)
Adresse (ad_id, ad_id_ville, ad_libelle, ad_code_postal)
Organisme (o_id, o_nom)
Contact (c_id, c_id_organisme, c_nom, c_prenom, c_tel_fixe, c_tel_mobile, c_fax, c_adrel)
Participer (p_id_affaire, p_id_organisme, p_id_role)

[NicolasGrabo]

Merci Phil! Nickel!

Et ben! J'avais vraiment oublié mes cours de terminale! Je me rappelais plus de toutes ces possibilités!!!

Merci à tous les deux pour vos réponses!

[NicolasGrabo]

D'après ce que je comprends, voici le modèle qui m'est conseillé par Phil!
J'ai besoin de le voir ainsi pour comprendre. Est-ce que c'est bien cela?

[CinePhil]

Il manque le lien entre Organisme et Adresse... mais je l'avais oublié moi aussi !

[NicolasGrabo]

Comment puis-je expliquer clairement à des gens totalement néophytes comment fonctionne cette base de données???

Faut-il expliquer toutes les relations entre chaque table? Je pense que oui.

[CinePhil]

Perso, je trouve le MCD plus parlant que le MLD pour un néophyte.

J'avais expliqué le principe à mes anciens collègues de l'INRA et ils avaient très bien compris au point qu'ils ont commencé à modéliser leurs propres données assez rapidement. Bon c'est pas des manches non plus, c'est des chercheurs mais quand même !

Pour ne reprendre qu'un exemple tiré d'un de mes précédents messages :

Organisme -1,n----Avoir----1,1- Contact

Ça se lit très facilement :
"Un organisme a de 1 à plusieurs contacts et un contact n'est que dans un organisme."

[NicolasGrabo]

Moi je suis un manche dans le domaine Phil
Lol je plaisante!

Voici le début de ma partie 2, je ne sais pas vraiment comment je peux la développer pour le moment...


Pour mener à bien cette mission, il a tout d’abord fallu penser à la création d’une base de données. Mais qu’est-ce qu’une base de données ? Voici la définition qui nous est donnée par Linux-France sur son site web : « Ensemble structuré d'informations. Une base de données doit être conçue pour permettre une consultation et une modification aisée de son contenu, si possible par plusieurs utilisateurs en même temps. D'une manière plus générale, on parle aussi de base de données pour tout ensemble d'informations. Ainsi, une encyclopédie est une base de données, même si l'utilisateur ne peut pas y changer grand chose. Les données sont stockées dans des champs d'un type déterminé, et ces champs sont groupés dans des tables, reliées entre elles. »
En gros, une base de données est un regroupement d’informations pouvant tendre vers un nombre infini de ces dernières. Permettant de récupérer une information en quelques instants, une base de données se doit d’être concise et résumer l’ensemble des informations qu’elle contient.
Après mûres réflexions de ma part et des aides obtenues sur un forum informatique, voici le modèle de base de données que j’ai obtenu :

(voir ci dessus)

Ensuite j'expliquerai le modèle.

[CinePhil]

Les données sont stockées dans des champs d'un type déterminé, et ces champs sont groupés dans des tables, reliées entre elles. »

Une table est composée de lignes et de colonnes, pas de champs !

En gros, une base de données est un regroupement d’informations pouvant tendre vers un nombre infini de ces dernières.

Un peu fumeux comme phrase !

Permettant de récupérer une information en quelques instants, une base de données se doit d’être concise et résumer l’ensemble des informations qu’elle contient.

Non ! Une BDD ne contient pas des résumés d'informations mais les informations nécessaires et complètes !
Elle ne doit surtout pas être concise mais au contraire contenir la totalité des informations nécessaires !

Bref, introduction à revoir complètement !
Regarde déjà du côté de Wikipédia dont je préfère l'introduction.

Si le but est de justifier l'utilisation d'une BDD, il y a moult articles sur Internet qui en expliquent l'intérêt dès qu'on veut stocker des données de façon permanente.

[NicolasGrabo]

Merci Phil j'ai bien pris en compte tes remarques.

Apparemment nous allons finalement commander le logiciel Access.

La base de données que j'ai pu deviner est la suivante :



Est-ce que cette base de données permettra de faire des requêtes par lesquelles on pourra, par exemple, trouver quel architecte travaille avec quel bureau d'étude et quel maître d'ouvrage? Et inversement?!

Y a-t-il des choses à compléter, à modifier?

Bien à vous,

Nicolas

[CinePhil]

Dans un MCD, on ne fait pas figurer les clés étrangères. Celles-ci n'arrivent qu'au MLD.

Ton MCD n'interdit pas qu'un organisme participe plusieurs fois à la même affaire avec plusieurs rôles. Est-ce normal ?

Je redonne ci-dessous mon premier MCD :

On pourrait avoir ainsi le MCD suivant :
Affaire -0,n----Participer----0,n- Organisme -0,n----Avoir----1,n- Adresse -1,1----Situer----0,n- Ville
Role -0,n-------------|

Affaire -1,1----Situer----0,n- Ville

Organisme -1,n----Avoir----1,1- Contact

Il y avait deux associations différentes nommées Avoir. J'aurais peut-être dû les nommer différemment. Mais toi tu les as transformées en une association ternaire. Ce qui fait que chaque contact n'apparaîtra qu'une seule fois mais deux contacts du même organisme pourraient avoir des adresses différentes.

Reprenons ce morceau de MCD en changeant le nom d'une des deux associations :
Contact -1,1----Travailler----0,n- Organisme -0,n----Avoir----1,n- Adresse.

Est-ce que cette base de données permettra de faire des requêtes par lesquelles on pourra, par exemple, trouver quel architecte travaille avec quel bureau d'étude et quel maître d'ouvrage? Et inversement?!

Sous réserve des modifications données ci-dessus, je pense que oui.

[NicolasGrabo]

J'ai du mal à bien comprendre ton MCD!

Je ne comprends pas bien, notamment, comment il faut corriger ma MCD pour qu'il interdise qu'un organisme participe à une affaire mais avec un unique role.

Pour ce qui est de la présentation du mcd et la présence des clés étrangères, je fais ceci parce que je présenterai comme cela dans mon rapport. Je ne pense pas que ça posera de problèmes aux examinateurs!

[CinePhil]

J'ai du mal à bien comprendre ton MCD!

Je ne comprends pas bien, notamment, comment il faut corriger ma MCD pour qu'il interdise qu'un organisme participe à une affaire mais avec un unique role.

Ta phrase est ambiguë mais je crois comprendre que tu veux interdire à un organisme de participer plusieurs fois à la même affaire avec différents rôles ?

Partons de l'association binaire entre organisme et affaire en ignorant le rôle :
Organisme -0,n----Participer----0,n- Affaire

On transforme ensuite l'association en entité :
Organisme -0,n----Effectuer----(1,1)- Participation -(1,1)----Avoir----0,n- Affaire

Les deux MCD donneront les mêmes tables du fait de l'identification relative, matérialisée par les cardinalités entre parenthèses (1,1), qui engendrera dans la table Participation une clé primaire composée des identifiants des tables Organisme et Affaire.

Maintenant, nous pouvons sans problème ajouter une association entre Participation et Rôle :
Organisme -0,n----Effectuer----(1,1)- Participation -(1,1)----Avoir----0,n- Affaire
Rôle -0,n----Assumer----1,1-----------------------|

Cette fois, la cardinalité 1,1 n'est pas entre parenthèses et l'identifiant du rôle est une simple clé étrangère dans la table Participation mais ne participe pas à la clé primaire. Il n'y aura donc toujours bien qu'une seule fois au maximum chaque couple {id_organisme, id_affaire} dans la table Participation et un seul rôle pour chaque participation d'un organisme à une affaire.

Pour ce qui est de la présentation du mcd et la présence des clés étrangères, je fais ceci parce que je présenterai comme cela dans mon rapport. Je ne pense pas que ça posera de problèmes aux examinateurs!

Si tu entends par "examinateur" celui qui va juger ton rapport en vue d'obtenir un examen, je pense au contraire qu'il pourra te retirer des points pour ce manque de rigueur dans le formalisme de ton MCD !

Sinon, présente seulement le MLD ou un schéma entités/relations à la manière de MySQL Workbench.

[NicolasGrabo]

Merci beaucoup Phil pour tes réponses. Cela va bien m'aider pour la conception de cette DB!

Mais je crois que lorsqu'ACCESS sera là, ce sera bien plus simple à comprendre pour moi, car là nous sommes restés dans le théorique qui ne m'est pas encore complètement familier.

Merci et peut être à bientôt!

[NicolasGrabo]

Léger soucis dans ma BD. Je ne sais pas d'où vient le problème.

Je souhaite chercher le nom des clients (role id : 1) pour lesquels la facture est supérieure à 900 euros (affaire prix). Pour ce faire, je crois que cette requête est juste :



Pourtant, le résultat n'est pas correct, ça trouve ces solutions ci :


Alors qu'on remarque ici qu'il y a plus de clients réglant une somme supérieure à 900 euros :


Comment faire? Est ce un problème de réglage dans les relations? Notamment, je ne sais pas comment régler l'autorisation d'avoir 1 ou plusieurs affaire pour un client...

[fsmrel]

Bonjour,

Ça manque de jointures ! Où est passé l’attribut AffaireId dans votre requête ? Par ailleurs, l’attribut RoleId peut être référencé directement dans la table Participation.



Et tant qu'à faire, n'oubliez pas de définir la clé primaire de la table Participation : {OrganismeId, AffaireId}.

[NicolasGrabo]

Salut fsmrel! Et merci pour ta réponse!

En effet j'ai un problème pour la table participation. On doit rendre Organisme Id et Affaire Id clés primaires tout en faisant respecter l'intégrité référentielle? Si oui, c'est cela que je n'avais pas bien compris.

[fsmrel]

Oui, l'attribut OrganismeId participe à la clé primaire {OrganismeId, AffaireId} de la table Participation et simultanément à la clé étrangère {OrganismeId} référençant la clé primaire {OrganismeId} de la table Organisme. Même principe pour l'attribut AffaireId.