Agence immobilière (E-A)
[1h]
Une agence immobilière cherche à créer une base de données pour la gestion des biens immobiliers mis à sa disposition et pour l’exploitation statistique et/ou fiscale des informations accumulées.
Pour chaque logement on possède plusieurs informations comme l'adresse, le nom du propriétaire, le type (maison/appartement), le nombre de pièces, la surface habitable, l’état de l’habitation (neuf, bon état, très bon état, à rénover), l’objectif de gestion (vente, location), le prix de mise en vente ou de location mensuelle, la date de disponibilité, la ville, etc. Chaque propriété peut avoir un ou plusieurs garages. Ces derniers sont caractérisés par le type (box, emplacement numérotés, etc.) et dans certain cas peuvent avoir des adresses différentes de celle de la propriété.
Une personne, qui sera identifiée par son nom et son adresse, peut mettre en location ou en vente un de ses logements auprès de l’agence.
Un logement à vendre (resp. à louer) peut être acheté (resp. loué) par une personne. Pour chaque transaction de vente, l'agence touche une commission qui correspond à un pourcentage du prix de vente (qui est composé d’une valeur fixe à laquelle on additionne entre 3 et 5% en fonction du montant de la transaction et des négociations particulière). Un logement vendu ou loué est rendu indisponible pour d’autres éventuels clients. Un locataire peut donner son préavis, l’agence signalant alors le logement disponible dans un délai de trois mois.
L’agence organise et gère également les visites faites par ses clients (les acheteurs ou locataires potentiels).
Question
Reformuler l'énoncé du problème sous la forme de règles claires afin de poser les connaissances sous une forme littérale. Formuler des hypothèses, si nécessaire, pour compléter les informations manquantes.
Solution
Il y a des logements qui ont un type, un nombre de pièces, une surface, un état, un objectif de gestion, un prix, une disponibilité, une date de disponibilité.
Les logements sont proposés à la location ou à la vente par des propriétaires, possèdent des garages et sont situés à des adresses.
On fait l'hypothèse supplémentaire que les logements sont codifiés, ce qui permettra de les identifier facilement.
Il y a des garages, qui ont un type.
Les garages appartiennent aux logements et sont situés à une adresse.
On fait l'hypothèse que les garages ont un numéro, ce qui est indispensable pour identifier plusieurs garages d'un même logement (qui peuvent être situés à une même adresse).
Il y a des adresses, qui ont un numéro de rue, une rue et une ville.
Les adresses servent à situer un logement, un garage ou une personne.
On fait l'hypothèse que l'agence n'est pas internationale.
Il y a des personnes, qui ont un nom et un prenom.
Les personnes vivent à une adresse.
Il y a des propriétaires, qui sont des personnes.
Les propriétaires louent ou vendent des logements.
Il y a des clients, qui sont des personnes.
Les clients font des visites et louent ou achètent des propriétés.
Il y a des visites, qui ont une date.
Les visites sont faites par des clients dans des logements.
Il y a des transactions de location ou de vente, qui ont une date, une commission et un montant (le montant n'étant pas forcément égal au prix de mise en vente).
Une transaction concernent un logement, un client et un propriétaire.
Question
Réaliser le modèle E-A du problème.
Repérer le domaine de valeur des propriétés. Repérer les clés. Repérer les entités de type faible. Repérer les attributs dérivés.
Solution
Remarque :
Une des difficultés consiste à gérer la temporalité qui existent dans le système. En effet le modèle exprime la notion de propriétaire à un instant t, hors s'il y a vente, puis revente, le propriétaire entre les deux transactions sera nécessairement différent. Si l'on veut se rappeler avec quel propriétaire a été effectué une transaction, il faut créer une association Transaction ternaire entre les propriétaires, les clients et les logements. Une association binaire ne comportant que les clients et les logements ne permettrait plus, une fois le propriétaire du logement changé, de mémoriser quel était le propriétaire au moment de la transaction. Notons que, en gérant les transactions de cette manière on pourra garder l'historique des propriétaires et trouver qui était propriétaire à une date donnée.
Clés et entités identifiables
L'entité logement est identifié par la clé Code. L'entité adresse est identifiée par ses trois propriétés. Les autres entités sont non identifiées.
Entités de type faible
L'entité Garage a besoin de l'entité Logement pour être identifiée, le numéro de garage n'est pas unique dans l'absolu (notons que nous aurions aussi pu identifier Garage par rapport à Adresse). L'entité Personne (et donc Propriétaire et Client qui en héritent) a besoin de Adresse pour être identifiée, car plusieurs personnes avec le même nom et le même prénom peuvent exister (notons que dans ce modèle deux homonymes ne peuvent habiter au même endroit).
Attributs dérivés
Dans la modélisation proposée, nous n'avons aucun attribut dérivé. On aurait pu imaginer (pour l'entité Transaction) de dériver l'attribut Commission de l'attribut Montant, mais le caractère "variable" et "négociable" de cette commission rend l'intérêt de la chose très improbable.
Remarque :
Il y a toujours plusieurs façons de réaliser un modèle E-A. Par exemple dans notre cas on aurait pu représenter les adresses comme des attributs composés plutôt que comme une entité, ou encore ne pas représenter l'entité personne et les relations d'héritage, etc.
Question
Réaliser le modèle relationnel en appliquant les règles de passage E-A vers relationnel.
Indiquer les règles appliquées. Expliquer et détailler les cas particuliers.
Utiliser la notation textuelle du modèle relationnel, du type : RELATION (PROP1, PROP2, PROPn). Souligner la clé primaire (les propriétés concernées seront en premier dans la liste). Les clés étrangères seront placées en dernier dans la liste, et l'on indiquera par un "=>" à quelle relation elles font références. Indiquer dans un tableau pour chaque propriété, son domaine de valeur et les contraintes supplémentaires qui la concerne (existentielle, par rapport à d'autres propriétés du tuple, etc.),
Solution
LOGEMENT(CODE, TYPE, NBPIECES, SURFACE, ETAT, OBJECTIF, PRIX, DISPO, DATEDISPO, NORUE=>ADR, RUE=>ADR, VILLE=>ADR, NOM=>PROP, PRENOM=>PROP)
L'entité identifié Logement donne naissance à la relation LOGEMENT. Les deux associations 1:N vers Proprietaire et Adresse donnent naissance à la migration de clés étrangères.
GARAGE(NUM, CODE=>LOG, TYPE, NORUE=>ADR, RUE=>ADR, VILLE=>ADR)
L'entité de type faible Garage donne naissance à la relation GARAGE et à l'ajout de la clé de LOGEMENT (CODE) dans la clé de GARAGE (cette clé sert aussi de clé étrangère vers LOGEMENT). La relation 1:N vers Adresse donne naissance à la création de la clé étrangère composée des trois propriétés NORUE, RUE et VILLE de ADRESSE.
ADRESSE(NORUE, RUE, VILLE)
L'entité identifiée Adresse donne naissance à la relation ADRESSE. Il n'y a aucune clé étrangère, Adresse étant toujours du côté N de la relation 1:N.
PROPRIETAIRE(NOM, PRENOM, NORUE=>ADR, RUE=>ADR, VILLE=>ADR)
L'entité de type faible Proprietaire donne naissance à la relation PROPRIETAIRE et à l'ajout de la clé de ADRESSE dans sa clé. La relation 1:N vers ADRESSE est déjà assumé par la clé étrangère ajoutée pour identifer PROPRIETAIRE.
CLIENT(NOM, PRENOM, NORUE=>ADR, RUE=>ADR, VILLE=>ADR)
Idem que propriétaire.
VISITE(CODE=>LOG, NOM=>CLIENT, PRENOM=>CLIENT, NORUE=>CLIENT, RUE=>CLIENT, VILLE=>CLIENT, DATE)
La relation N:M Visite entre Logement et client donne naissance à la relation VISITE. VISITE intègre comme clés étrangères les clés de LOGEMENT et CLIENT. La clé de VISITE est la concaténation des clés étrangères. On ajoute comme propriété de la relation VISITE les propriétés de l'association Visite.
TRANSACTION(CODE=>LOG, NOMP=>PROP, PRENOMP=>PROP, NORUEP=>PROP, RUEP=>PROP, VILLEP=>PROPR NOMC=>CLIENT, PRENOMC=>CLIENT, NORUEC=>CLIENT, RUEC=>CLIENT, VILLEC=>CLIENT DATE, COMMISSION, MONTANT, TYPE)
L'association ternaire Transaction donne naissance à la relation TRANSACTION, avec comme clés étrangères les clés de toutes les relations correspondant aux entités participant à TRANSACTION, soit CLIENT, LOGEMENT et PROPRIETAIRE. La clé de TRANSACTION est la concaténation de ses clés étrangères, auquelle on ajoute DATE qui sert de clé locale (et permettra d'avoir plusieurs transactions entre le même client, le même propriétaire et le même logement, mais à des dates différentes, ce qui peut être utile par exemple si une location est suivie d'un achat). On ajoute enfin les propriétés correspondant aux propriétés de l'association Transaction.
Remarque :
Notons que pour simplifier la relation TRANSACTION il aurait été envisageable d'attribuer une clé primaire NUMERO aux relations CLIENT et PROPRIETAIRE.
Remarque :
La modélisation choisie conduit à des clés étrangères très compliquées. Notons que cela ne pose pas problème de redondance, car les contraintes d'intégrité référentielle assureront la cohérence des données recopiées. Pour simplifier le modèle relationnel, nous aurions pu identifier les relations ayant des clés composées de beaucoup d'attributs, comme la relation ADRESSE, avec des codes non identifiants servant de clés artificielles. Précisons néanmoins que le choix de conserver des clés étrangères compliquées peut simplifier certaines questions et augmenter les performances en limitant le nombre de jointures.
