Discussion :

[free_01_binairy]

J'ai cet exercice d'un systeme d'information avec corrigé à l'appui.
Mais je ne comprends pas une des relations, donc j'aimerais que vous m'aidiez.
Voici le sujet:
GESTION DES LOGEMENTS DANS UNE AGENCE IMMOBILIERE
Une agence de location de maisons et d’appartements désire gérer sa liste de
logements. Elle voudrait en effet connaître l’implantation de chaque logement (nom de la
commune et du quartier) ainsi que les personnes qui les occupent (les signataires
uniquement). (...) [j'ai effacé les données inutiles pour l'essentiel]

Quant aux individus qui occupent les logements (les signataires du contrat uniquement), on se
contentera de leurs noms, prénoms, date de naissance et numéro de téléphone.
Pour chaque commune, on désire connaître le nombre d’habitants ainsi que la distance
séparant la commune de l’agence.
NB : on ne gérera pas l’historique de l’occupation des logements par les individus. On
considèrera de plus qu’un individu ne peut être signataire que d’un seul contrat.
Etablir le modèle conceptuel des données correspondant puis le modèle logique associé.
********
voici le modèle conceptuel des données qui a été donné par le corecteur:
Et ensuite le modèle logique des données:

Et ou est le problème alors???
Bien, ce que je ne comprends pas, c'est la relation logement <=>individu!
voici comment moi je vois les choses:
un individu peut ne pas avoir de logement. On dira donc qu'il est un candidat parce que l'agence ne lui a pas encore trouvé de logement. ou en a déjà.
De même un logement peut ne pas être habité. donc n'est rattaché à un aucun individu, cela arrive dans le cas ou l'agence vient d'enregistrer cette maison.
On sait quand même qu'un logement est attribué à une seule personne.
Pour moi c'est la relation père-fils qui me pose problème.
Si on décide qu'un individu a droit à un et un seul logement (je crois que cela est dit dans l’énoncé si j'ai bien compris en ces termes:On
considérera de plus qu’un individu ne peut être signataire que d’un seul contrat. et qu'un logement appartient à un seul individu.
Voila ce qui me semble confus.
Merci.

[SQLpro]

Tout dépend du contexte. S'il s'agit de résidence principale, alors il n'y a jamais qu'un seul logement à titre de résidence principale.
De plus ce modèle ne gère pas l'évolution des données dans le temps et n'offre qu'une vision statique des choses au présent.
Enfin, quel est l'intérêt de polluer la base avec des personnes qui ne sont pas rattachés avec un logement ? Pour gonfler artificiellement les statistiques ?

A +

[free_01_binairy]

Tout dépend du contexte. S'il s'agit de résidence principale, alors il n'y a jamais qu'un seul logement à titre de résidence principale.

Ici on gere les logements en location. je crois que cela a été noté dans le ssujet :Une agence de location de maisons et d’appartements désire gérer sa liste de
logements.

quel est l'intérêt de polluer la base avec des personnes qui ne sont pas rattachés avec un logement

Une personne qui est enregistrée peut attendre un moment avant que l'agence ne lui trouve un logement. Ceux là sont des postulants. Voici donc l’intérêt d'avoir des gens enregistrés sans logement attribué. De même que des gens peuvent confier leur appartement à l'agence pour gerer sa location. Voici en gros l'idée.

[SQLpro]

Une personne qui est enregistrée peut attendre un moment avant que l'agence ne lui trouve un logement. Ceux là sont des postulants. Voici donc l’intérêt d'avoir des gens enregistrés sans logement attribué. De même que des gens peuvent confier leur appartement à l'agence pour gerer sa location. Voici en gros l'idée.

Dans ce cas il faut effectivement une cardinalité 0,1 entre l'individu et l'association occuper.

A +

[free_01_binairy]

Bonjour,
Je m'excuse de répondre tardivement.

Dans ce cas il faut effectivement une cardinalité 0,1 entre l'individu et l'association occuper.

Je ne comprends pas bien l'idée.
Soyez plus explicite s'il vous plait.
Merci

[free_01_binairy]

Bonjour,
Je reviens pour dire que je ne comprends toujours pas votre explication.
En effet s'il faut une cardinalité 0,1 entre l'individu et l’association occuper, qu'en est il de la relation logement et l’association occuper ?
La cohérence de mes données dans ma BD en dépend. c'est pourquoi j'insiste. Le développement de mon application est bloquée juste parce que j'ai pas encore trouvé la réponse à ma préoccupation.
Merci.

[free_01_binairy]

Il n'est pas possible qu'un logement soit attribué à plusieurs personnes dans le même temps.
C'est ce qui me pose problème et que je cherche à contourner.
Merci

[seabs]

Bonjour,

J'ai regardé ta demande, le point qui t'inquiète et de t'assurer qu'un logement soit attribué à une seule et unique personne. Et si, j'ai bien compris une personne ne peut pas avoir plus d'un logement. Bon tout ceci est très théorique, mais faisons avec cela.

Tout d'abord la cardinalité 0,1 ne répond pas à ce point, elle permet simplement qu'un individu puisse avoir ou pas un logement. En plus, elle introduit un NULL dans la table INDIVIDU pour la personne qui ne possède pas de logement ce qui n'est pas tip-top.

Pour régler ton inquiètude, il te suffit de mettre un trigger qui contrôlera qu'un logement déjà affecté ne peut pas l'être une second fois. Il s'agit d'une solution.

Il en existe une autre option, en ajoutant une clé unique sur la clé étrangère NO_LOGEMENT. Ainsi, un appartement déjà affecté ne pourra pas être affecté à une autre personne. (Cette solution fonctionne uniquement s'il n'y a pas la gestion de l'historique des occupants). Voir MPD ci-dessous.



Il existe au moins une autre possibilité avec l'ajout d'une table complémentaire, mais cela me semble inutile par rapport à la demande initiale.

Examine si cela répond à ton analyse personnelle . Sinon, expliques pourquoi.

Bon courage

[free_01_binairy]

Merci de ta réponse.

Et si, j'ai bien compris une personne ne peut pas avoir plus d'un logement. Bon tout ceci est très théorique, mais faisons avec cela.

je sais qu'il est possible qu'une personne soit liée à plusieurs logements. ce qui l'interdit c'est le sujet de l'exercice. Mais je vais y remédier dans le programme. En effet c'est pas le point focal de ma préoccupation.

Tout d'abord la cardinalité 0,1 ne répond pas à ce point, elle permet simplement qu'un individu puisse avoir ou pas un logement. En plus, elle introduit un NULL dans la table INDIVIDU pour la personne qui ne possède pas de logement ce qui n'est pas tip-top.

Comment faire de sorte qu'enregistrer une personne qui ne possède pas de logement puisse être "tip-top" selon votre propre expression? Puisque je le veux ainsi.

(Cette solution fonctionne uniquement s'il n'y a pas la gestion de l'historique des occupants)

Bien sur que je veux gérer l'historique des occupants même si l'exercice l'interdit. (NB : on ne gérera pas l’historique de l’occupation des logements par les individus.: tiré du sujet).

Il existe au moins une autre possibilité avec l'ajout d'une table complémentaire, mais cela me semble inutile par rapport à la demande initiale.

Si l'ajout d'une table complémentaire peut contourner la théorie ou le problème et approcher la pratique, pourquoi pas essayer. Je suggère donc que tu me la proposes.
Merci pour ta disponibilité.

[seabs]

Bonjour,

Je te mets rapidement le MCD et MPD avec la mise œuvre d'une entité AFFECTATION. Ainsi, il est possible pour un individu d'être titulaire de 0,n par contre un logement peut-être affecté qu'à un seul individu. Toutefois, cette approche ne correspondant pas l'énoncé mis dans ton premier message.

MCD


MPD


Ceci ne répond pas à toutes les problématiques de suivi dans le temps et notamment si nous voulons connaître l'historique des différents occupants d'un logement. Mais pour cela, il faut revoir la totalité des règles de gestion et modifier le MCD en conséquence. Ce n'est pas ce qui est demandé dans l'énoncé.
A+

A+

[free_01_binairy]

Merci,
Je vais faire la refonte totale du MCD dans le cadre d'une application pratique et non théorique et donner les règles de gestion qui l'accompagnent.
Puis je vous ferai le retour pour corriger.
Merci

A+.

[free_01_binairy]

Comme je l'avais dit dans mon poste précédent, je vous ferais le retour et voilà:

voici le MCD:

et le MPD




Règles de gestion (juste pour les deux entités en conflit)

*Un contrat peut être lié à un ou plusieurs logements.
*Un logement peut être lié à un contrat ou pas (0,1) (en effet on souhaite gérer aussi les logements inoccupés).
*Un individu peut signer plusieurs contrats (même si l’interdit, en pratique c’est possible.)

A ce titre, j’ai une préoccupation.
Comment gérer le cas d’un individu qui n’a encore trouvé de logement dans l’agence (celui que j’appelle postulant).
Autre préoccupation, comment faire pour gérer l’historique des occupations des logements.
J’attends donc votre correction pour parfaire le travail.

Merci de votre aide

[free_01_binairy]

Veuillez s'il vous plait jeter un coup sur ma proposition
Merci

[seabs]

Bonjour,

J'ai regardé tes interrogations.

Comment gérer le cas d’un individu qui n’a encore trouvé de logement dans l’agence (celui que j’appelle postulant).

Pour ce point, il convient de changer la cardinalité individu et mettre (0,n) à la place de (1,n). Ainsi, tu pourras enregistrer les personnes en recherche d'un logement.

Autre préoccupation, comment faire pour gérer l’historique des occupations des logements

Il faut ajouter une entité complémentaire pour gérer l'historique des attributions. J'ai modifié ton MCD ainsi :

Avec le MPD correspondant.


Tu remarqueras la cardinalité relative qui lie le contrat à un logement.
Ensuite, l'attribution d'un appartement ne pourra se faire que s'il est libre. Pour contrôler cette contrainte, il conviendra de mettre en place un trigger dans la table des contrats. Pour ce dernier point, nous ne sommes plus dans la modélisation. Cependant, je te joins un exemple, dont tu pourras t'inspirer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SET TERM ^ ;

CREATE OR ALTER TRIGGER CONTRAT_BI0 FOR CONTRAT
ACTIVE BEFORE INSERT POSITION 0
AS
declare VDATE DATE ;
begin
  IF (EXISTS(SELECT * FROM CONTRAT WHERE ID_LOGEMENT = NEW.ID_LOGEMENT)) THEN
  begin
    SELECT MAX(CONTRAT_DATE_FIN) FROM HISTORIQUE WHERE ID_LOGEMENT = NEW.ID_LOGEMENT INTO :VDATE;
    IF ((VDATE IS NULL) OR (VDATE > NEW.CONTRAT_DATE)) THEN
    BEGIN
      EXCEPTION "ERREUR";
    END
  end
end
^
SET TERM ; ^

Il est peut-être possible d'optimiser la modélisation pour éviter la mise en place d'un trigger. Mais, je n'ai pas trouvé. Si un intervenant à la solution, merci de la communiquer.
Maintenant à toi de mettre cela en concordance avec tes souhaits et tes règles de gestion.
A+

[free_01_binairy]

Merci seabs.
Désolé de répondre tardivement

Il est peut-être possible d'optimiser la modélisation pour éviter la mise en place d'un trigger. Mais, je n'ai pas trouvé

Un modèle n'est jamais assez parfait, il pourra être amélioré plus tard.
Je vais faire avec ce que tu m'as proposé. Cependant je suis disposé à toutes autre modification.
Merci.