Problemformulering

AB Stångåstaden har problem med hyresgäster som missköter sina trädgårdar. För att lindra problemet vill de se till att de inte anvisar lägenheter med trädgård till kända trädgårdsmisskötare.

AB Stångåstaden vill därför ha ett register där de när de får in ett klagomål på en trädgård kan lagra det, knutit till den nuvarande hyresgästen. När de sedan anvisar lägenheter till sökande ska den informationen kunna tas fram.

AB Stångåstaden har redan en SQL-databas där infromation om lägenheterna och sökande till lägenhet lagras.

Lösning

Övergripande

En trädgårdsmisskötare kan vara hyresgäst, sökande till lägenhet, både hyresgäst och sökande eller ingendera. Därför är det inte lämpligt att lagra informationen om trädgårdsmisskötsel i någon av de existerande tabellerna för lägenheter eller sökande till lägenhet. Istället är det bättre att göra en helt ny tabell, med trädgårdsmisskötare. Relationer från både lägenhets och sökande tabellen behövs. När man får in en rapport om att en trädgård missköts måste man utifrån lägenhetstabellen kunna uppdatera trädgårtsmisskötseltabellen. När man ska avgöra vilken sökande som ska få besked om en ledig lägenhet med trädgård måste man också lätt kunna ta reda på trädgårdsmisskötselinformationen via tabellen om sökande.

I tabellen för trädgårdsmisskötare ska information om klagomål från grannar, fastighetsskötare eller borttappade lagras. Dessa klagomål lagras idag i ett pappersregister, så det räcker med att lagra registreringsnummer. Finns det överhuvudtaget några klagomål anvisar man ingen lägenhet till trädgårdsmisskötaren. I fallet en trädgårdsmisskötare explicit begär att få en lägenhet med trädgård måste man dock läsa klagomålen, för att se om de räcker för att avvisa begäran. De fallen anser man sig dock klara genom att gå igenom pappersdokumenten, som man lätt hittar utifrån registreringsnummret.

Ett ER-diagram över det hela skulle kunna se ut såsom:

				 +---------+
				 | Sökande |
				 +---------+
				      |
				      |1
				     < >
				      |1
				      |
+----------+	    1	N	 +---------------------+
| Lägenhet ¦---------< >---------| Trädgårdsmisskötare |
+----------+			 +---------------------+
				      |
				      |
				  ==========
				(( Klagomål ))
				  ==========

Attributen till lägenhet och sökande är inte utskrivna i bilden.

En sökande kan bara vara relaterad till en trädgårdsmisskötare och tvärtom. Men en lägenhet kan ha relation till flera trädgårdsmisskötare. Det kan ju finnas flera hyresgäster i en lägenheten, om de delar kontraktet.

Implementering

När vi ser hur det hela bör implementeras upptäcker vi att tabellen för lägenheter innehåller personnumren för hyresgästerna och tabellen för sökande innehåller personnumret på den sökande. Lagrar vi personnummret på trädgårdsmisskötaren i tabellen för trädgårdsmisskötsel behöver vi alltså inga speciella tabeller för relationerna.

Eftersom vi kan ha flera klagomål lagrar vi tupler av personnummer och registreringsnummret till ett klagomål i tabellen.

För att skriva ut en sökandes klagomål kan vi sedan göra:

SELECT		klagomål
FROM		sökande s, trädgårdsmisskötare t
WHERE		s.personnummer = t.personnummer

Namnen kan behöva justeras efter vilka tecken SQL-implementationen tillåter.

Buggar

Hann inte beskriva hur satellitövervakning kan lösa problemet med att identifiera misskötta trädgårdar...