Forum d'entraide PHPFrance

Bonjour,

J'aimerais créer mes bases pour faire un site immobilier dans le genre de myspace.

- L'utilisateur est soit :

un visiteur lambda

une agence immobilière

un propriétaire

- Un utilisateur visiteur lambda peut :

déposer des logements

déposer ses critères pour recevoir des logements

choisir le design de son site (par exemple s'il propose un logement en location de vacances)

- Un utilisateur agence immobilière peut :

déposer des logements

déposer ses critères pour recevoir des logements

choisir le design de son site (toutes ses annonces sont regroupées sur son site)

Un logement peut être proposé :

à la vente

à la location

en viager

à la semaine (je n'arrive pas à imaginer ce qu'il faut faire pour ça, une table avec toutes les semaines, 1, 2, 3... et 0 ou 1 pour indiquer la disponibilité et l'id du logement)

J'ai déjà fait des bases de données, mais toujours n'importe comment. J'aimerais pour une fois essayer de faire les choses un peu plus dans les règles et surtout ne pas me trouver coincer par la suite.

J'ai ce script pour mes tables :

Code : Tout sélectionner

CREATE TABLE choixutilisateur (
  idchoix INT NOT NULL AUTO_INCREMENT,
  idutilisateur INT NULL,
  letype VARCHAR(20) NULL,
  statut VARCHAR NULL,
  prixmax NUMERIC NULL,
  prixmin NUMERIC NULL,
  loyermax NUMERIC NULL,
  loyermin NUMERIC NULL,
  terrasse BOOL NULL,
  jardin BOOL NULL,
  piscine BOOL NULL,
  chauffage VARCHAR(20) NULL,
  etage NUMERIC NULL,
  surface NUMERIC NULL,
  codepostal VARCHAR(5) NULL,
  ville VARCHAR(45) NULL,
  PRIMARY KEY(idchoix)
);

CREATE TABLE design (
  iddesign INT NOT NULL AUTO_INCREMENT,
  idutilisateur INT NULL,
  bgcolor VARCHAR(7) NULL,
  color VARCHAR(7) NULL,
  h1color VARCHAR(7) NULL,
  h2color VARCHAR(7) NULL,
  h3color VARCHAR(7) NULL,
  pbg VARCHAR(7) NULL,
  pcolor VARCHAR(7) NULL,
  PRIMARY KEY(iddesign)
);

CREATE TABLE logement (
  idlogement INT NOT NULL AUTO_INCREMENT,
  idutilisateur INT NULL,
  idproprietaire INT NULL,
  letype VARCHAR(20) NULL,
  genre VARCHAR(25) NULL,
  statut VARCHAR NULL,
  ref VARCHAR(45) NULL,
  titre VARCHAR(45) NULL,
  prix NUMERIC NULL,
  loyer NUMERIC NULL,
  chargesloc NUMERIC NULL,
  bouquet NUMERIC NULL,
  rente NUMERIC NULL,
  descriptionfr TEXT NULL,
  descriptionen TEXT NULL,
  terrasse BOOL NULL,
  jardin BOOL NULL,
  piscine BOOL NULL,
  chauffage VARCHAR(20) NULL,
  etage NUMERIC NULL,
  surface NUMERIC() NULL,
  adresse TEXT NULL,
  codepostal VARCHAR(5) NULL,
  ville VARCHAR(45) NULL,
  PRIMARY KEY(idlogement)
);

CREATE TABLE utilisateur (
  idutilisateur INT NOT NULL AUTO_INCREMENT,
  societe VARCHAR(45) NULL,
  nom VARCHAR(45) NULL,
  prenom VARCHAR(45) NULL,
  datenaissance DATE NULL,
  adresse TEXT NULL,
  codepostal VARCHAR(5) NULL,
  ville VARCHAR(45) NULL,
  tel VARCHAR(11) NULL,
  mobile VARCHAR(10) NULL,
  mail VARCHAR(45) NULL,
  pseudo VARCHAR(20) NULL,
  passe VARCHAR(20) NULL,
  statut VARCHAR NULL,
  debut DATE NULL,
  fin DATE NULL,
  avoir NUMERIC NULL,
  PRIMARY KEY(idutilisateur)
);

Mais j'ai un gros doute sur les propriétés des champs (varchar, int, etc...) et je voudrais savoir si ces tables peuvent me permettre de faire ce que je veux. J'ai lu le tuto Merise conseillé sur ce site, c'est pour ça que j'essaye de penser un peu la chose avant de me lancer, mais ce n'est pas évident. A ce sujet, que signifie la relation n:m?

Si quelqu'un peut me conseiller,

Merci

La signification des relations pourrait se traduire de la manière suivante :
- 1:n = à une ligne de cette entité peuvent correspond de 0 à n lignes de l'autre entité;
- n:m = 0 à n ligne de cette entité peuvent correspondre à 0 `m lignes de l,autre entité;
- 1:1 = à une ligne de cette entité peut correspondre une ligne de l'autre entité;

Tu noteras que je parle là d'entité et non de table. Au stade de la modélisation, on commence avec un MCD (Modèle Conceptuel de Données) : on ne commencera à parler de tebles que dans le MPD (Modèle Physique de Données).

Les règles sommaires à suivre pour modéliser une base commencent avant toute chose par la construction d'un dictionnaire de données : en clair, tu dois noter toutes les données que tu dois pouvoir manipuler. Partant de là, tu vas ensuite les regrouper en entités, chaque entité ayant un certain nombre de propriétés.

Par exemple, tu pourrais avoir une entité "logement" qui aurait comme propriétés "nombre-de-pieces", "surface", "adresse", "ville", etc.. et puis une entité "proprietaire" avec en propriété "nom", "prenom", etc.. : entre les deux entité, tu vas avoir une relation 1:n, un propriétaire pouvant avoir un ou plusieurs logement. En croquis, ça va resembler à ceci:

Code : Tout sélectionner

+-------------------+                          +--------------+
|      logement     |                          | proprietaire |
+-------------------+        _________         +--------------+
|-nombre-de-pieces  | 1:1   / possede \   1:n  |-nom          |
|-surface           |--------------------------|-prenom       |
|-adresse           |       \_________/        |-etc...       |
|-ville             |                          +--------------+
+-------------------+

Si tu ajoutes une entité pour représenter les agents immobiliers, tu auras une relation avec les propriétaires qui cette fois sera de type n:m : un propriétaire en effet peut posséder plusieurs logements et un agent peut gérer 0 ou plusieurs logements de ce propriétaire.

C'est difficile de t'expliquer ça clairement ici, la modélisation ne s'aprend pas en trois minutes, j'espère quand même que ça t'éclaire un tout petit peu.

Ce qui est très important à ce stade, c'est d'essayer pour le moment de faire complètement abstraction des tables et du code SQL de création. Travaille sur les entités : quand tu seras arrivé au stade du MPD, alors seulement tu commenceras à parler de tables et pourras songer au code de construction.

Merci pour les explications,

Tant que j'en reste au stade de la conception faut-il que je considère les propriétaires et les agents et les visiteurs (dans mon cas, voir ci-dessus) comme des entités séparées ?
Ou puis-je déjà les considérer comme une seule entité utilisateur (comme je l'avais fait)?
C'est que je pensais qu'une entité = une table, mais on dirait que ça peut changer en passant du MCD au MPD. Est-ce bien le cas?

Encore merci

Cela dépend, si une "personne" peut être en même temps propriétaire, agent ou visiteur, une seule table permet d'éviter de la redondances d'information. Si une personne ne peut faire partie que d'une catégorie alors des tables séparées sont plus simple à mettre en oeuvre.

Je pense alors garder une table unique, je vais essayer de faire le MCD, je mets résolu sur ce message.
Merci

Forum d'entraide PHPFrance

Conception de BDD

Conception de BDD