Aide conception et architecture Bdd

Bonjour,

avant tout je suis un véritable débutant en Mysql.
Je souhaite réaliser un site lié à la gestion de bien immobilier pour mettre en relation les proprio / les biens /les locataires. Mais pour moi c'est un vrais casse tête pour réaliser le shéma de la bdd.

Pour faire simple la bdd dois contenir 3 types d'informations :
-sur les proprio (nom, adresse etc)
-sur les biens détaillés du proprio (maison, appart) avec leurs descriptif.
-sur les locataires des proprio

Pour la partie "proprio" et "locataires" je pense que ça reste dans mes possibilités.
Mais ça se corse pour la partie "biens" car le proprio peux avoir plusieurs biens avec plusieurs locataires et chaque biens doit être détaillé de la sorte Ex.
-proprio "A" possède : 1 maison Y, type 4, 2 étages, adresse ..., la maison possède 1 cuisines au 1er, 1 salon 1er, 1wc au 1er, 1 salle bain 2eme, 2 chambre au 2eme (chambre A et B). Monsieur X, email, tel, etc. est locataire de cette maison "Y".
Bien entendu chaque "bien" est lié à un proprio et un locataire (voir + si coloc)
Chaque pièce doit être identifiée c'est pour ça que dans l'exemple je précise "2 chambre au 2eme" Chambre A et Chambre B" par exemple. Cela me sera utile par la suite.

Donc mes difficulté sont les suivantes : je ne sais pas comment organiser les tables pour détailler les biens en fonction des critères suivant :
- bien : maison ou appart ou local
- type (nbr de piece) : Type 1, Type2, type...
- adresse (Num, rue, ville, CP etc.)
- nom du/des locataires du bien
- détaille du bien : (en fonction des niveaux/étage) chambre, cuisine, terrasse, salle bain etc.


Que me conseillez vous comme architecture ? on ma parlé de table relationnelle ?

par avance merci,

n'hésitez pas à me questionner tout ne doit pas être très claire...

Salut,
Apparemment, tu pars de très loin!!
Je te conseille de lire quelques tutos pour appréhender les bases de données relationnelles.
En attendant, voici quand même quelques éléments de réponse: elles sont ainsi nommées parce que les données sont liées entre elles, les tables sont en relation les unes avec les autres.
Exemple: un proprio possède un/des biens, il y a donc une relation entre la table Bien et la table Proprio. Il existe plusieurs types de relations. Ici, 1 proprio peut posséder plusieurs biens, par contre un bien n'appartient qu'à un seul proprio. On a donc une relation "un à plusieurs" (1.*) entre le proprio et le bien (1 proprio -> plusieurs biens). Cette relation va se traduire dans ta base de la manière suivante:
puisqu'un bien n'appartient qu'à un seul proprio, on peut ajouter dans la table Bien un champ IdProprio qui permettra de remonter jusqu'à lui.
A l'inverse, pour les locataires, tu ne peux pas identifier de manière unique le locataire d'un bien (puisqu'il peut y en avoir plusieurs). Tu ne peux donc pas ajouter un IdLocataire dans la table Bien. La relation se fait ici dans l'autre sens: c'est le locataire qui te permet de remonter au bien qu'il loue => champ IdBien dans la table Locataire
etc...

Dans ton cas précis, voici une proposition qui pourrait convenir pour les biens (2 tables):
- table Bien (IdBien, IdProprio, TypeBien, NbPieces, NbNiveaux, Adresse, Commentaire)
- table Piece(IdPiece, IdBien, NomPiece, TypePiece, Surface, Niveau, Commentaire).
Avec: TypeBien= "Maison", "Garage"...
NomPiece= "Chambre A", "Chambre triangle"...
TypePiece= "Chambre",...

Une piece est identifiée de manière unique et n'appartient qu'à un seul bien. A partir de là, tu pourras faire des recherches du style: "toutes les pièces de tel bien, qui sont de type 'Chambre' et qui font + de 20m²" etc...
Bon courage!

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

Merci pour ton aide je vais regarder ça de plus pret.

encore merci de la réponse,

Bonne Fêtes à tous