Partage
  • Partager sur Facebook
  • Partager sur Twitter

Architecture bdd Mysql

    5 novembre 2010 à 1:44:30

    Bonjour,

    je me lance dans la création d'un site dédié à la gestion immobilière. J'ai consulté pas mal de tuto sur les bases Mysql mais je reste un novice en la matière.

    Pour aider à la compréhension de mon projet :

    But du site : améliorer la gestion de biens immobilier (appart, maison, commerce etc.) et la communication entre différent acteurs (proprio, locataire, agence, intervenant (artisans)etc.)

    -Le proprio s'enregistre et se crée un compte. (type de proprio, adress, tel, mail, mdp etc.)
    -Le proprio pourra enregistrer tout ses biens (bienID) ainsi que leurs descriptions (adresse, type de biens, nbr pièce, type de pièce, loué ou non etc.)
    -Le proprio pourra enregistrer ses locataires et leur créer un compte (locaID) (nom,tel,mail,MDP date_debut_bail etc.) qui sont lié à ses biens (bienID)

    -Le proprio pourra enregistrer les agences ou notaires et leurs créer un compte (agencesID) qui pourront gérer certains de ses biens (bienID) et donc de ses locataires (locaID).

    -Le proprio pourra enregistrer une liste de prestataires (artisans : peintres, elec etc.)(prestaID) qui pourront intervenir en fonction de chaque biens. Ils n'ont pas besoin de compte et n'accèderont pas au site.

    Dans un 1er temps le but est de permettre au proprio de stocker ces infos ainsi que des fichiers et de faciliter la consultation de ses infos.

    Ensuite je compte mettre en place un systeme pour que le proprio, le locataire et les agences puisse se partager ses infos (avec des restrictions pour certains) et communiquer entre eux via mon site.

    Voilà !

    J'essaie donc de concevoir l'architecture de ma base mais j'avoue, je me perd totalement dans mes tables !
    J'ai commencé par tout mettre sur papier et aujourd'hui je commence à créer les tables mais je me rend vite compte qui plein de chose m'échappe.

    Voici un 1er schéma (aidé par une âme charitable)

    Image utilisateur

    Qu'en pensez vous ? Par rapport aux infos données ci-dessus est-ce que ça vous parait correct ou manque t-il des tables, des modifs ...

    Par avance merci de votre aide, je suis dispo pour toutes questions
    • Partager sur Facebook
    • Partager sur Twitter
      5 novembre 2010 à 8:16:59

      bonjour,
      la table disponible ne me paraît pas essentielle; un indicateur sur le bien serait suffisant et une clé étrangère dans bien (agenceid) si un bien est géré par une seule agence.

      La table appartient ne peut comporter que agenceid et personneid; ces 2 champs formant la clé primaire.

      Mêmes remarques pour les tables location, intervient et détient.

      Il serait même possible de fusionner ces 3 tables avec un indicateur pour différencier locataire, propriétaire et intervenant. Certes dans ce cas certains champs seraient nuls. Donc ça se discute.


      • Partager sur Facebook
      • Partager sur Twitter
      Anonyme
        5 novembre 2010 à 8:57:26

        Citation : sicilien007


        Il serait même possible de fusionner ces 3 tables avec un indicateur pour différencier locataire, propriétaire et intervenant. Certes dans ce cas certains champs seraient nuls.


        Et ça... c'est nul !

        Il faut faire de l'héritage pour distinguer les différents types de personnes.
        • Partager sur Facebook
        • Partager sur Twitter
          5 novembre 2010 à 9:07:33

          re,

          Citation : Cintre Sournois


          Et ça... c'est nul !


          Il me semble qu'il faut arrêter avec ces réponses à l'emporte-pièce sans aucune nuance.
          Il serait même possible, j'écris. C'est le verbe être au conditionnel. Je n'est pas écrit "il faut".

          Citation : Cintre Sournois

          Il faut faire de l'héritage


          Justement il ne faut, tout simplement parce que ce n'est pas possible conceptuellement. SQL et l'héritage, c'est nouveau.
          Eventuellement on simule l'héritage en conservant les 3 tables. Et même une 4ème si l'on veut justement coller à un modèle UML ou Merise/2.
          Les règles d'optimisation (Espace/temps) sur un SGBDR nécessitent parfois de modéliser de façon moins "pure" que lors des modèles conceptuels (Dénormalisation, fusion, ...)



          • Partager sur Facebook
          • Partager sur Twitter
          Anonyme
            5 novembre 2010 à 9:15:49

            Citation : sicilien007


            Justement il ne faut, tout simplement parce que ce n'est pas possible conceptuellement.


            Ce n'est pas possible conceptuellement ?? Et ben... bien sûr que c'est possible.

            Citation : sicilien007


            SQL et l'héritage, c'est nouveau.


            "SQL et l'héritage" ça se gère très facilement et très simpelment, il n'y a rien de nouveau à ce niveau.....

            Citation : sicilien007


            Les règles d'optimisation (Espace/temps) sur un SGBDR nécessitent parfois de modéliser de façon moins "pure" que lors des modèles conceptuels (Dénormalisation, fusion, ...)


            On se place à un niveau "conceptuel" comme tu dis, ou même logique (SQL), que viennent faire les performances ici ???....
            • Partager sur Facebook
            • Partager sur Twitter
              5 novembre 2010 à 9:24:04

              Euh excusez moi de m'initier dans votre discussion lol, mais je rappel juste que je suis novice et devant vos remarques je me sent encore plus perdu !
              Une personne m'a aidé et a conçu ce schéma mais justement je bloque sur les tables : appartient, disponible et agence pourquoi avoir une table que pour "agence" ?
              Je pense être à coté de la plaque mais dans "type personne" je pensais que les agences en faisaient parties et donc pas besoin d'avoir une table "agence".

              Enfin j'ai vraiement besoin de comprendre la logique de mon schéma.

              merci de votre aide

              • Partager sur Facebook
              • Partager sur Twitter
              Anonyme
                5 novembre 2010 à 9:27:17

                Est-ce qu'une agence est une personne ?
                • Partager sur Facebook
                • Partager sur Twitter
                  5 novembre 2010 à 9:36:47

                  Dans les faits j'entend par agence une entité : agence immo, notaire, gestionnaire immo.
                  Cette entité se substitue au propriétaire.

                  ------------------------------------------------------------------

                  Le but recherché à therme : faire communiquer, partager et transmettre des infos entre le proprio, l'agence/notaire/autre (si il y en a) et le locataire.
                  Parfois le proprio passe par une agence. Dans ce cas le locataire et l' agence communique entre eux. Le locataire n'a plus besoin de communiquer en direct avac le proprio, l'agence fait tampon.
                  • Partager sur Facebook
                  • Partager sur Twitter
                  Anonyme
                    5 novembre 2010 à 9:48:28

                    C'est pas très clair.
                    Tu pourrais peut être distinguer les personnes morales des personnes physiques.
                    • Partager sur Facebook
                    • Partager sur Twitter
                      5 novembre 2010 à 10:04:55

                      oui je ne m'oppose à rien j'essaie de comprendre simplement. Dans ma tête et sur le papier sais exactement ce que je veux mais quand j'essaie d'adapter ça à MySql je bloque je n'ai pas encore les compétences pour ça.

                      Donc je reste comme ça avec ma table "agence" mais j'ajouterai une "sous table" nommé "type_agence" : avec comme champs : agence, notaire, gestionnaire.
                      • Partager sur Facebook
                      • Partager sur Twitter
                      Anonyme
                        5 novembre 2010 à 10:16:33

                        Citation : dbzh


                        Donc je reste comme ça avec ma table "agence" mais j'ajouterai une "sous table" nommé "type_agence" : avec comme champs : agence, notaire, gestionnaire.


                        Ce ne serait pas des "champs" mais des lignes.

                        Si dans la table agences, chaque colonne s'applique pour chaque type d'agence, en clair s'il n'y a pas de NULL, c'est bon.
                        Sinon, c'est de l'héritage.


                        Au fait l'héritage ça ressemble à ça :
                        http://sqlpro.developpez.com/cours/modelisation/heritage/
                        http://www.developpez.net/forums/d9413 [...] heritage-mcd/
                        • Partager sur Facebook
                        • Partager sur Twitter
                          5 novembre 2010 à 11:33:09

                          Merci pour les infos je vais regarder ça.


                          Sinon ce soir si j'ai le temps je fais un jolie plan en visio de mon projet pour aider à la compréhension ;)
                          • Partager sur Facebook
                          • Partager sur Twitter
                            5 novembre 2010 à 18:27:30

                            re,
                            si tu décides d'avoir une table agence, ton modèle étant pour faire court un schéma de BD, c'est que ton application pourra gérer plusieurs agences. Est-ce le cas?

                            Pourquoi veux-tu créer une table [type_agence]? Surtout avec les champs que tu mentionnes.
                            Si tu veux avoir des infos sur les notaires, tu dois te poser la question suivante : une agence travaille-t-elle avec un seul notaire ou plusieurs? Si la réponse est 1, tu crées un champ Notaire dans la table [Agence] sinon tu crées une table [Notaire] plus une table de liaison [agence_notaire].
                            Idem pour gestionnaire.

                            Si tu veux être plus carré sur la modélisation, tu peux lire soit Merise/2 soit UML.
                            M est plus adaptée pour la conception d'une BD. Avec des AGL à la clé.
                            Excellent livre de Matheron sur M (méthode ET démarche).
                            Tuto sur le web proche du Matheron : http://cyril-gruau.developpez.com/merise/
                            Si tu veux concevoir en UML, le livre de C. Soutou pour les bases de données est excellent.
                            • Partager sur Facebook
                            • Partager sur Twitter
                              6 novembre 2010 à 1:00:34

                              Tu as pensé à l'historique ?
                              • Partager sur Facebook
                              • Partager sur Twitter
                                6 novembre 2010 à 3:20:57

                                J'ai pensé à une architecture qui ressemble à ça :

                                Image utilisateur


                                Et effectivement, on retrouve ici l'agence comme un simple intervenant. Ensuite libre à toi d'utiliser un héritage pour stocker les différentes données relatives aux intervenants (cf. le lien donnez par Cintre Sournois), ou en créant simplement une table mère Regroupement qui sera donc un groupe d'intervenant : agence, collectif de propriétaire / locataire , entreprise de maçonnerie, etc. Attention à la relation avec la table des intervenants car un peintre peut travailler pour une agence tout en faisait partie d'une collectvitié, et être propriétaire d'un bien.

                                Fais attention à tes clés primaires qui, sur ton schéma, n'ont aucun sens. Ici j'ai fais de mon mieux avec les éléments que j'ai (revoir les PK de la table biens).

                                J'ai également créé un set de table (ahah) pour que les intervenants puissent créer des groupes de biens selon leur convenance, pratique pour les agences, les entreprises, les propriétaires ayant un patrimoine important, toussa :)

                                Ensuite, pour ce qui est des personnes représentées sur le site mais n'ayant pas de compte, c'est ici que se porte l'obligation de faire intervenir un héritage de la table intervenants , et donc de revoir l'utilité de la table types_intervenants.

                                Ici le SQL Create Script :

                                SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
                                SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
                                SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

                                CREATE SCHEMA IF NOT EXISTS `agence_immobiliere` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci ;
                                USE `agence_immobiliere` ;

                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`types_biens`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`types_biens` (
                                `type_label` TINYTEXT NOT NULL ,
                                PRIMARY KEY (`type_label`) )
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`biens`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`biens` (
                                `bien_id` INT NOT NULL AUTO_INCREMENT ,
                                `type_label` TINYTEXT NOT NULL ,
                                PRIMARY KEY (`bien_id`) ,
                                INDEX `fk_biens_types1` (`type_label` ASC) ,
                                CONSTRAINT `fk_biens_types1`
                                FOREIGN KEY (`type_label` )
                                REFERENCES `agence_immobiliere`.`types_biens` (`type_label` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE)
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`intervenants`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`intervenants` (
                                `intervenant_nom` TINYTEXT NOT NULL ,
                                `intervenant_prenom` TINYTEXT NOT NULL ,
                                `intervenant_anniversaire` DATE NOT NULL ,
                                `intervenant_id` INT NOT NULL AUTO_INCREMENT ,
                                PRIMARY KEY (`intervenant_anniversaire`, `intervenant_prenom`, `intervenant_nom`) )
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`types_intervenant`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`types_intervenant` (
                                `type_intervenant_label` TINYTEXT NOT NULL ,
                                PRIMARY KEY (`type_intervenant_label`) )
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`liens`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`liens` (
                                `intervenant_id` INT NOT NULL ,
                                `bien_id` INT NOT NULL ,
                                `type_intervenant_label` TINYTEXT NOT NULL ,
                                `lien_id` VARCHAR(45) NOT NULL ,
                                INDEX `fk_intervenants_has_biens_biens1` (`bien_id` ASC) ,
                                INDEX `fk_intervenants_has_biens_types_intervenant1` (`type_intervenant_label` ASC) ,
                                PRIMARY KEY (`bien_id`, `intervenant_id`) ,
                                CONSTRAINT `fk_intervenants_has_biens_intervenants1`
                                FOREIGN KEY (`intervenant_id` )
                                REFERENCES `agence_immobiliere`.`intervenants` (`intervenant_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,
                                CONSTRAINT `fk_intervenants_has_biens_biens1`
                                FOREIGN KEY (`bien_id` )
                                REFERENCES `agence_immobiliere`.`biens` (`bien_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,
                                CONSTRAINT `fk_intervenants_has_biens_types_intervenant1`
                                FOREIGN KEY (`type_intervenant_label` )
                                REFERENCES `agence_immobiliere`.`types_intervenant` (`type_intervenant_label` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE)
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`groupes`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`groupes` (
                                `groupe_label` TINYTEXT NOT NULL ,
                                `intervenant_id` INT NOT NULL ,
                                `groupe_id` INT NOT NULL AUTO_INCREMENT ,
                                PRIMARY KEY (`intervenant_id`, `groupe_label`) ,
                                INDEX `fk_groupes_intervenants1` (`intervenant_id` ASC) ,
                                CONSTRAINT `fk_groupes_intervenants1`
                                FOREIGN KEY (`intervenant_id` )
                                REFERENCES `agence_immobiliere`.`intervenants` (`intervenant_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE)
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`groupes_has_biens`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`groupes_has_biens` (
                                `groupe_id` INT NOT NULL ,
                                `bien_id` INT NOT NULL ,
                                PRIMARY KEY (`groupe_id`, `bien_id`) ,
                                INDEX `fk_groupes_has_biens_biens1` (`bien_id` ASC) ,
                                CONSTRAINT `fk_groupes_has_biens_groupes1`
                                FOREIGN KEY (`groupe_id` )
                                REFERENCES `agence_immobiliere`.`groupes` (`groupe_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE,
                                CONSTRAINT `fk_groupes_has_biens_biens1`
                                FOREIGN KEY (`bien_id` )
                                REFERENCES `agence_immobiliere`.`biens` (`bien_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE)
                                ENGINE = InnoDB;


                                -- -----------------------------------------------------
                                -- Table `agence_immobiliere`.`interventions`
                                -- -----------------------------------------------------
                                CREATE TABLE IF NOT EXISTS `agence_immobiliere`.`interventions` (
                                `intervention_date` DATETIME NOT NULL ,
                                `lien_id` VARCHAR(45) NOT NULL ,
                                `intervention_enonce` TEXT NULL ,
                                PRIMARY KEY (`intervention_date`, `lien_id`) ,
                                INDEX `fk_interventions_liens1` (`lien_id` ASC) ,
                                CONSTRAINT `fk_interventions_liens1`
                                FOREIGN KEY (`lien_id` )
                                REFERENCES `agence_immobiliere`.`liens` (`lien_id` )
                                ON DELETE CASCADE
                                ON UPDATE CASCADE)
                                ENGINE = InnoDB;



                                SET SQL_MODE=@OLD_SQL_MODE;
                                SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
                                SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


                                Je suggère (sans prétention) de reprendre mon schéma, et d'effectuer les héritages appropriés, puis de poster ici pour qu'on voit un peu ce que t'as fait ;)
                                • Partager sur Facebook
                                • Partager sur Twitter
                                  6 novembre 2010 à 9:01:42

                                  bonjour,
                                  @Cintre Sournois
                                  http://merise.developpez.com/faq/?page [...] D_MCDSousType
                                  4 règles de transformation d'un modèle objet (MCD version MOO) en un MLD. Pas une, quatre. Choix d'optimisation.
                                  @Feng Huang.
                                  Etrange ton schéma!
                                  Types_intervenants relié à liens et pas à intervenants?
                                  Groupes identifié par groupe_label + intervenant_id et pas par groupe_id?
                                  groupes_has_biens à juste titre identifié par groupe_id et bien_id et donc issu de la concaténation des identifiants des entités conceptuelles biens et groupes.
                                  Intervenant identifié par 3 champs alors que id_intervenant irait bien et que vous éviter des doublons sur les 3 champs on ajoute un index unique. Ainsi la clé étrangère dans intervenant_id dans lien devient logique (les clés étrangères correspondent à des clés primaires dans des tables références).
                                  Etc, etc ...



                                  • Partager sur Facebook
                                  • Partager sur Twitter
                                    7 novembre 2010 à 2:34:46

                                    Types_intervenants : non car en fonction du bien, l'intervenant peut avoir un rôle différent. Comme je l'ai expliqué, un peintre qui travaille sur un bien possédé par une agence, peut aussi être propriétaire d'un autre bien, auquel cas son type est lié au bien, et non pas à lui-même (si je puis dire ainsi).

                                    Groupes : effectivement, tu devrais revoir l'utilisation des clés primaires ( PK : primary key ), mettre un ID en PK ne sert à rien, par contre il est utile pour les relations (évitant la répétition de tous les champs de la clé composite).

                                    Intervenants: mm remarqué sur les PK
                                    • Partager sur Facebook
                                    • Partager sur Twitter
                                      10 novembre 2010 à 14:00:38

                                      Depuis 2 jours je met tout au propre sur Visio pour avoir une vue d'ensemble de mon projet et ainsi mieux décrire le fonctionnement du site et donc de la bdd. Je reviens vers vous certainement demain. merci à tous pour vos conseils et votre aide.
                                      • Partager sur Facebook
                                      • Partager sur Twitter

                                      Architecture bdd Mysql

                                      × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                                      × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                                      • Editeur
                                      • Markdown