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 :

[entité-association] modèle pour gérer les contrats d'un cabinet d'avocats


Sujet :

Schéma

  1. #1
    Membre du Club
    Inscrit en
    Avril 2008
    Messages
    199
    Détails du profil
    Informations forums :
    Inscription : Avril 2008
    Messages : 199
    Points : 58
    Points
    58
    Par défaut [entité-association] modèle pour gérer les contrats d'un cabinet d'avocats
    Bonjour,

    Je travaille sur une application qui gère les clients et les contrats d'une société.
    L'utilisateur ajoute des clients. Ces clients peuvent souscrire à des contrats auprès de notre société.
    Les factures associées à ces contrats sont stockées dans la base de données. Une facture peut-être payée par le titulaire du contrat ou par sa société.

    A chaque contrat est aussi associé un avocat, qui traitera l'affaire du client. L'avocat envoie lui aussi sa facture à ma société.
    J'ai donc créé les tables sous SQL Server 2005, et j'ai généré le schéma de cette base de données. Ce schéma résume donc la BD créée et je voudrai savoir s'il vous semble correct, ou si vous avez d'autres questions.
    Voici le schéma :
    http://www.noelshack.com/uploads/Dia...bles028111.jpg

    Une clé secondaire doit-elle obligatoirement être composée de toute la clé primaire de la table à laquelle elle fait référence ?

    Merci pour votre aide et vos remarques.

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonjour Monkey_D.Luffy,


    Table Contrat

    Selon le diagramme, les attributs Id_Client et Id_Enregistrement participent à la clé primaire de la table.

    Scénario 1 :

    Vous procédez par identification relative : Contrat est identifié relativement à Client. Très bien. Mais Au vu de votre diagramme, ces attributs apparaissent dans l’ordre suivant : Id_Enregistrement puis Id_Client. Il est généralement préférable de faire précéder Id_Enregistrement de Id_Client (performance des traitements).

    Scénario 2 :

    Vous procédez par identification absolue et {Id_Enregistrement} est clé primaire : au nom du principe de l’irréductibilité des clés, l’attribut Id_Client doit disparaître de la clé.

    Qu'en est-il ?


    Table Avocat

    Mêmes remarques concernant le système de composition des clés.
    En outre, quelle relation existe-t-il entre un avocat de cette table et un avocat de la table Contrat ?

    Autres tables

    Mêmes remarques concernant le système de composition des clés.


    Table Société

    Selon votre modélisation, une facture est déclinée en sociétés, c'est-à-dire que plusieurs sociétés sont impliquées dans une même facture. Pourriez-vous nous en dire plus ?

    Par ailleurs, vous dites " Une facture peut-être payée par le titulaire du contrat ou par sa société". Quelle est cette société parmi l’ensemble des sociétés impliquées dans une même facture ?



    Une clé secondaire doit-elle obligatoirement être composée de toute la clé primaire de la table à laquelle elle fait référence ?
    Je ne sais pas ce que vous entendez par clé secondaire : s’agit-il d’une clé alternative au sens du Modèle Relationnel de Données (c'est-à-dire faisant l’objet d’une clause UNIQUE dans l’instruction CREATE TABLE) ?

    Je suppose que vous faites allusion à la table FactureAv.

    En supposant que la clé primaire de la table Avocat soit {Id_Avocat, Id_Enregistrement, Id_Client}, vous avez par ailleurs parfaitement le droit de définir {Id_FactureAv, Id_Avocat} comme clé primaire de la table FactureAv. Seule contrainte : {Id_Avocat, Id_Enregistrement, Id_Client} doit servir de clé étrangère pour référencer la table Avocat.

    La seule contrainte est que {Id_FactureAv, Id_Avocat} respecte les contraintes d’unicité et d'irréductibilité des clés candidates.
    (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à pour ça.

Discussions similaires

  1. application pour gérer les patients d'un cabinet médicale
    Par ait zahra dans le forum Débuter avec Java
    Réponses: 3
    Dernier message: 24/03/2014, 15h39
  2. Quels modules Perl pour gérer les documents XML ?
    Par djibril dans le forum Modules
    Réponses: 8
    Dernier message: 02/12/2010, 23h54
  3. Réponses: 7
    Dernier message: 20/01/2010, 12h55
  4. Réponses: 13
    Dernier message: 07/02/2007, 12h10
  5. Méthode simple pour gérer les collisions
    Par Hyoga dans le forum OpenGL
    Réponses: 2
    Dernier message: 19/02/2005, 13h43

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