dátumkezelés - címke - it-tanfolyam.hu

Táblázatos hőtérkép készítése

2023. november 6. Szerző: Kaczur Sándor

Ebben a projektben táblázatos hőtérképet készítünk Java és JS nyelveken. Java programot készítünk az adatok véletlenszerű előállításához és a sablon alapján történő HTML fájl generálásához. JavaScript program fogja a grafikont megjeleníteni a weboldalon. Tervezünk, kódolunk, tesztelünk. Lássunk hozzá!

Mi az a hőtérkép?

A hőtérkép (heatmap) olyan grafikon, amely könnyen áttekinthetővé tesz nagy mennyiségű adatot úgy, hogy kategorizál/csoportosít és az előfordulások tartományai alapján különböző színeket rendel azokhoz. A szín hozzárendelése egy intervallumból történik. Például a világosabb a ritkább, a sötétedő szín az egyre gyakoribb értékeket jelenti. A tipikus hőtérkép kétdimenziós és az előforduló adatok mennyiségét, azok arányait, eloszlását, szóródását (nem szórását), gyakoriságát jeleníti meg. A hőtérkép gyors vizuális összefoglalást, áttekintést biztosít. A projekt során sorokból és oszlopokból álló táblázatos hőtérképet készítünk.

A táblázatos hőtérkép nem összekeverendő a következő két megközelítéssel:

Ha az adatok lokációhoz kötődnek és térképen jelennek meg, akkor azt tematikus térképnek nevezzük. Erről már blogoltam korábban, lásd: Céline Dion – Courage World Tour, amikor az énekesnő USA-beli államokban előforduló koncertjeinek számát jelenítettem meg. Ehhez hasonlók az amerikai elnökválasztás során használt tematikus térképek, amelyek a(z egyes) jelöltek szavazatainak arányát ábrázolják meg szintén államonként.
Ha az adatok webergonómiához, bannervaksághoz, inkább fókuszban lévő tartalmakhoz, felhasználói élmény (UX) tervezéshez kötődnek, akkor a weboldal grafikus elemeihez (azok pozíciója) alapján rendelünk hozzá színeket attól függően, hogy mennyi ideig nézi azt a felhasználó.

Mi a feladat (koncepcionálisan)?

Adott egy konditerem, amely hétköznapokon egy megadott időintervallumban használható. Ehhez kulcsot kell felvenni és leadni. Az első belépő nyitja és az utolsó távozó zárja az ajtót. A teremhasználat offline nyilvántartott, így nehézkes bármiféle kimutatás, statisztika. A „menet közbeni” jövés-menést nem tudjuk követni. Természetesen adott számos szabály (felelősség, biztonság, balesetvédelem, létszámkorlát), amit most nem részletezek.

Elhelyezünk az ajtó mellett, belülről egy belépéshez és egy távozáshoz tartozó QR kódot. Készítünk egy egyszerű mobil alkalmazást és megkérjük a konditermek használóit, hogy belépéskor és távozáskor „csekkoljanak”. Anonim gyűjtjük a belépések és távozások időpontját (valahol egy szerveren, bármilyen fájlban, adatbázisban).

A konditermek használatára vonatkozó összesített adatokat könnyen átlátható módon szeretnénk weboldalon megjeleníteni: heti bontásban, a nyitva tartás időszakát órás blokkokra bontva az igénybevételtől függően jelenjenek meg az adatok táblázatos hőtérképen.

Ez az állapot átmeneti. Segítheti a konditermekbe tervezett – egyéni használattól független – események ütemezését. Ezeket akkor lenne célszerű időzíteni, amikor nem, alig, vagy kevésbé használt, foglalt az adott konditerem. A továbbfejlesztés következő állapotában könnyen lecserélhető a QR kód RFID alapú proximity kártyára, proxy kulcstartóra: először csak a jelenlét nyilvántartásához, később akár az ajtó nyitásához is.

Mit valósítunk meg mindebből Java nyelven?

Egyetlen konditeremre fókuszálunk. A hétköznaponként nyitva tartás legyen 16 órától 21 óráig. Aki edzésre jön, véletlenszerűen 20 és 40 perc közötti időszakot tölt a konditeremben. 16 órától lehet belépni. Az utolsó belépés 20:40-kor lehet (érdemes). 21 órakor mindenki elhagyja a konditermet. Nem fordul elő, hogy valaki nem jelzi a belépését vagy a távozását. Mivel anonim a nyilvántartás, így elegendő a dátum/időhöz, időbélyeghez egyetlen állapotot tárolni: be vagy ki. Valaki belépett nyitáskor vagy valamikor utána, majd távozott 20-40 perccel később, de legfeljebb záráskor.

A szükséges adatokat véletlenszerűen állítjuk elő. Egy hétre vonatkozó adatokat generálunk. Ezek a fenti paramétereknek megfelelő, összetartozó belépéshez és távozáshoz köthető időpontok. Kiegészítve a napok ciklusban való léptetésével hétfőtől péntekig. Az adatokat feldolgozva, összegyűjtve, csoportosítva, kategorizálva olyan (kimeneti) formátumra alakítjuk, amely kompatibilis a táblázatos hőtérkép adatmodelljével (bemenetével). Mindez Java nyelven valósul meg.

Mi történik JavaScript nyelven?

A webes megjelenítéshez szükséges egy HTML fájl, amelyben beágyazva található meg egy téglalap alakú területként megjelenő táblázatos hőtérkép. Ez sokféleképpen testre szabható: adható hozzá felirat, beállítható a sorokhoz és oszlopokhoz tartozó szöveg és a táblázat celláiban megjelenő értékek, adott a lebegő, az egér kurzor helyzetétől függő – cellánként különböző – jelmagyarázat, és persze mindennek van formátuma (betűtípus, méret, szín, igazítás, kitöltés). A fix, adatoktól nem függő beállításokat tartalmazó weboldalt sablonként elkészítjük. Mindez JavaScript nyelven történik. Ezután Java program a weboldal sablonját kiegészíti (cseréli, behelyettesíti, feltölti) a szükséges adatokkal.

Hogyan alakul az időintervallumok átfedése?

A konditerem használatának alakulását követjük, amihez táblázatos hőtérképet készítünk. Ehhez a nyitva tartás időintervallumát órás blokkokra bontjuk. Blokkonként összesítjük a jelenlétet, azaz megszámoljuk, hogy éppen akkor hányan veszik igénybe a konditermet, hányan vannak jelen/benn.

A konkrét paraméterektől függően az alábbi képen látható 3 eset egyike fordulhat elő. A és B jelöli az órás blokk elejét és végén, tehát ez 60 perces intervallum. Tarthat például: 16:00:00-16:59:59-ig. X és Y jelöli a jelenlét intervallumát, azaz a belépés és távozás időpontjait. Ez 20 és 40 perc között alakul. Haladjunk balról jobbra az ábrán.

Az első esetben ugyanarra az órára esik a belépés és a távozás. Ez az eset egyértelmű. A másik két esetben átfedés van több órás blokk között, mert különböző órára esik a belépés és a távozás. El kell dönteni, hogy ekkor hogyan összesítjük a jelenlétet. Válasszunk az alábbi két módszer közül:

Az első módszer szerint mindkét órához – ahol átfedés van – összesítjük a jelenlétet 1-1 főként, hiszen ha nem is végig, de jelen volt mindkét órás blokkban. Például: egy 16:50:00-17:20:00 jelenlétet a 16 és 17 órás blokkban is figyelembe veszünk.
A második módszer szerint időarányosan tesszük mindezt, azaz súlyozunk aszerint, hogy milyen hosszú jelenlét esik az egymást követő órákban. Például: egy 16:50:00-17:20:00 jelenlétet a 16 órás blokk esetében egyharmad, a 17 órás blokk esetében kétharmad a jelenlét adott órára eső aránya, súlya.

Az első módszert valósítjuk meg. Ez a döntés jelentősen befolyásolja, hogyan kell értelmezni később az elkészült táblázatos hőtérképet.

Objektumorientált tervezés

A koncepcionális terv alapján modellezünk. A szükséges adatok tárolására és alapfunkcióira fókuszálunk. Az osztály tárolja az összetartozó adatokat és megvalósít rajtuk értelmezhető műveleteket. Az időintervallum/időtartam kezelését a Duration ősosztály oldja meg. Tárolja a start és stop – naptól független időpontokat tároló – adatok és a rájuk vonatkozó FORMAT – megjelenítéshez kötődő – konstanst. Biztosítja a szükséges műveleteket: konstruktor, getterek, megvalósítja az időintervallumok átfedését az isOverlapped() függvénnyel, valamint ad szöveges reprezentációt a toString() függvénnyel. Az ősosztályból öröklődik az utódosztály. A DurationMap osztály a naptól független időpontokat kibővíti a hozzájuk tartozó day nappal, valamint képes tárolni az összesített, megszámolt jelenlétet a count változóban. Részt vesz a megszámolás folyamatában azzal, hogy lépésenként meghívható az incrementCount() eljárása.

A java.time csomagbeli LocalTime osztály képes a dátumtól független, napon belüli időpont tárolására és biztosít néhány alapvető funkciót a kezelésükre. Az adattárolás a napon belül eltelt időn alapul és nekünk (bőven) elegendő a másodperc alapú megjelenítés. A DateTimeFormatter alkalmas ezen időpontok formátumának tárolására, például óó:pp:mm alakban.

A Duration osztályból annyi objektum készül, ahány jelenlét adódik véletlenszerűen. Akár több száz is lehet. A DurationMap osztályból generált objektumok száma jóval kevesebb. Heti 5 napra, napi 5 órás blokkra 25 db készül belőle.

A vezérléshez kötődő osztály tervezését nem részletezem.

Íme a Java forráskód

public class Heatmap {

private final DayOfWeek[] WORKDAYS=new DayOfWeek[] {

DayOfWeek.MONDAY, DayOfWeek.TUESDAY, DayOfWeek.WEDNESDAY,

DayOfWeek.THURSDAY, DayOfWeek.FRIDAY};

private final LocalTime ENTER_START_TIME=LocalTime.of(16, 0, 0);

private final LocalTime ENTER_STOP_TIME=LocalTime.of(20, 40, 0);

private final LocalTime EXIT_TIME=LocalTime.of(20, 59, 59);

private final DateTimeFormatter FORMAT=

DateTimeFormatter.ISO_LOCAL_TIME;

private final Path HEATMAP_TEMPLATE_FILE=

Paths.get("./files/heatmap-template.html");

private final Path HEATMAP_FILE=Paths.get("./files/heatmap.html");

private ArrayList<DurationMap> durationMapAllList=new ArrayList<>();

public Heatmap() {

overlapTest();

createHeatmapFile();

}

private void overlapTest() {

for(DayOfWeek day: WORKDAYS) {

LocalTime intervalStart=ENTER_START_TIME;

LocalTime intervalStop=

intervalStart.plusHours(1).minusSeconds(1);

ArrayList<DurationMap> durationMapDayList=new ArrayList<>();

for(int i=1; i<=5; i++) {

DurationMap interval=

new DurationMap(day, intervalStart, intervalStop);

durationMapDayList.add(interval);

intervalStart=intervalStart.plusHours(1);

intervalStop=intervalStop.plusHours(1);

}

ArrayList<Duration> durationList=new ArrayList<>();

for(int i=1; i<=10; i++) {

int startSec=ENTER_START_TIME.toSecondOfDay(),

stopSec=ENTER_STOP_TIME.toSecondOfDay();

int randomSec=

(int)(Math.random()*(stopSec-startSec+1)+startSec);

LocalTime startTime=LocalTime.ofSecondOfDay(randomSec);

int presenceMin=(int)(Math.random()*21+20);

LocalTime stopTime=LocalTime.ofSecondOfDay(Math.min(

startTime.toSecondOfDay()+presenceMin*60,

EXIT_TIME.toSecondOfDay()));

durationList.add(new Duration(startTime, stopTime));

}

durationMapDayList.stream().forEach((durationMap) -> {

durationList.stream().

filter((duration) -> (duration.isOverlapped(durationMap))).

forEach((duration) -> {

durationMap.incrementCount();

});

durationMapAllList.addAll(durationMapDayList);

}

private void createHeatmapFile() {

String heatmapData=durationMapAllList.stream().

map(DurationMap::toString).collect(Collectors.joining(",\n"));

try {

String html=Files.readAllLines(HEATMAP_TEMPLATE_FILE).stream().

collect(Collectors.joining("\n"));

html=html.replace("##HEATMAP_DATA##", heatmapData);

Files.write(HEATMAP_FILE, html.getBytes(),

StandardOpenOption.CREATE);

}

catch(IOException e) {

e.printStackTrace();

}

public static void main(String[] args) {

new Heatmap();

}

A Java forráskód minden megtervezett funkciót megvalósít, támogatva a koncepciót. Most nem részletezem a működését.

A véletlenszerűen előállított adatok

A lista görgethető:

{x: "hétfő", y: "16:00:00-16:59:59", heat: 4},

{x: "hétfő", y: "17:00:00-17:59:59", heat: 6},

{x: "hétfő", y: "18:00:00-18:59:59", heat: 9},

{x: "hétfő", y: "19:00:00-19:59:59", heat: 6},

{x: "hétfő", y: "20:00:00-20:59:59", heat: 6},

{x: "kedd", y: "16:00:00-16:59:59", heat: 6},

{x: "kedd", y: "17:00:00-17:59:59", heat: 10},

{x: "kedd", y: "18:00:00-18:59:59", heat: 6},

{x: "kedd", y: "19:00:00-19:59:59", heat: 7},

{x: "kedd", y: "20:00:00-20:59:59", heat: 3},

{x: "szerda", y: "16:00:00-16:59:59", heat: 5},

{x: "szerda", y: "17:00:00-17:59:59", heat: 9},

{x: "szerda", y: "18:00:00-18:59:59", heat: 5},

{x: "szerda", y: "19:00:00-19:59:59", heat: 7},

{x: "szerda", y: "20:00:00-20:59:59", heat: 7},

{x: "csütörtök", y: "16:00:00-16:59:59", heat: 4},

{x: "csütörtök", y: "17:00:00-17:59:59", heat: 6},

{x: "csütörtök", y: "18:00:00-18:59:59", heat: 11},

{x: "csütörtök", y: "19:00:00-19:59:59", heat: 7},

{x: "csütörtök", y: "20:00:00-20:59:59", heat: 5},

{x: "péntek", y: "16:00:00-16:59:59", heat: 4},

{x: "péntek", y: "17:00:00-17:59:59", heat: 8},

{x: "péntek", y: "18:00:00-18:59:59", heat: 4},

{x: "péntek", y: "19:00:00-19:59:59", heat: 7},

{x: "péntek", y: "20:00:00-20:59:59", heat: 4}

A weboldal sablonja

HTML és JavaScript nyelvű forráskód vegyesen. A Java program a fájl 31. sorában lévő ##HEATMAP_DATA## szöveget cseréli le a táblázatos hőtérkép megjelenítéséhez szükséges véletlenszerűen előállított adatokra.

<html>

<head>

<title>Heatmap in JavaScript</title>

html, body, #container {

width: 80%; height: 80%; margin: 20pt; padding: 20pt;

}

</style>

</head>

<body>

anychart.onDocumentReady(function () {

let chart=anychart.heatMap(getData());

chart.title("Hogyan alakul a konditerem látogatottsága?");

chart.tooltip().useHtml(true).titleFormat(function () {

return "Látogatottság: "+this.heat;

}).format(function () {

return (

'<span style="color: #CECECE">Nap: </span>'+this.x+"<br/>"+

'<span style="color: #CECECE">Időtartam: </span>'+this.y

);

});

chart.container("container");

chart.draw();

});

function getData() {

return [

##HEATMAP_DATA##

];

}

</script>

</body>

</html>

További részletekért, beállításra vonatkozó, testre szabási lehetőségekért érdemes tanulmányozni az AnyChart dokumentáció Heat Map Chart fejezetét.

Az eredmény

Az előállított weboldalt böngészőben megjelenítve ezt kaphatjuk eredményként (vagy a véletlenszerűen generált adatoktól függően hasonlót):

A táblázatos hőtérkép hasznos eszköz. Elemezve könnyen döntéseket hozhatunk a koncepcionális tervezés során vázoltak alapján.

Továbbfejlesztési lehetőségek

Lehetne több konditerem is. Ekkor rögtön felmerül az összehasonlítás lehetősége, egyben igénye is.
Lehetne hétköznaponként eltérő a konditerem nyitva tartása.
Az időpontok kezelési precíz. Egy másodpercen múlik, hogy nem fedik át egymást. Az időpontok megjelenítése lehetne óó:pp alapú is.
Az időintervallumok jelenleg állandóak, mindig 1 órásak. Könnyen megoldható lenne, hogy dinamikusak legyenek: például a népszerűbb időszakok felbonthatók lennének két 30 perces blokkra. A népszerűség értelmezhető minden nap (héten) másképp. Egyszerű képlettel: átlag felett, medián felett.
Általánosíthatnánk a létesítménygazdálkodáshoz kötődő erőforrást nem (feltétlenül) helyhez kötött, mozgatható, kölcsönözhető eszközökre is: hangszer, projektor, stúdió felszerelés.
Másképpen valósulna meg az adatgyűjtés, ha egyetlen QR kód állna rendelkezésre és back-end helyett a „mobil alkalmazás emlékezne” a belépésre és távozásra. Ez jelentheti legalább az aznapi adatokat, de tárolható historikusan is.
Hibát is kellene, lehetne kezelni. Például a kiléptetés lehetne automatikus a nyitva tartás végén. A jelenlét igazából igaz-hamis állapot: ha eddig hamis volt és történt valami, akkor igaz lesz és fordítva. Ha van mögötte állapotmegőrző emlékezet (mivel programozunk, így nyilvánvalóan azonnal objektumra gondolunk, vagy annak valamilyen fájlba vagy adatbázisba történő leképezésére).
A nyilvántartás könnyen megvalósítható személy hozzárendelésével, azaz lehetne nem anonim is a jelenlét.
Egymást átfedő időpontok esetén (ha nincsenek a hosszukra vonatkozó korlátozó feltételek) általánosítva 6 eset fordulhat elő. Például ha a jelenlét lehetne 60 percnél hosszabb, de 120 percnél rövidebb is, akkor nem lenne elegendő a fenti 3 esetet kezelni a jelenlét összesítése során.
Valósítsuk meg az időintervallumok átfedésénél bemutatott második – időarányos – módszert!
A napi jelenlét 20 fővel valósul meg a programban. Lehetne ez a paraméter is véletlenszerű, például 15-30 fő között, vagy esetleg népszerűbb a péntek.
Jelenleg a táblázatos hőtérkép statikus. Csak a (befejezett egész heti) múltbeli adatokat tudja megjeleníteni. Az aktuális, jelenlegi állapothoz szinkronizáció, ütemezés kell. Óránként (a blokkok végén automatizáltan), de akár 5 percenként is aktualizálható a hőtérkép.
A táblázatos hőtérkép megjelenítése önálló weboldal helyett beágyazható widget felületén is történhet.
Többféleképpen is készítettünk már grafikonokat, íme néhány a szakmai blogunkból: Kockadobás kliens-szerver alkalmazás, Sankey-diagram készítése, JFreeChart grafikon készítése.

A bejegyzéshez tartozó forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A projektfeladat – attól függően, milyen szinten valósítjuk meg – kapcsolódhat több tanfolyamunk tematikájához. A fenti forráskód a Java SE szoftverfejlesztő tanfolyam 17-28. óra: Objektumorientált programozás és a 37-44. óra Fájlkezelés alkalmaihoz kötődik. Ha többrétegű, elosztott alkalmazásként valósítjuk meg, akkor a Java EE szoftverfejlesztő tanfolyam a 9-16. óra: XML és JSON feldolgozás, dinamikusan generált weboldalba beépítve a 33-40. óra: Java Server Pages alkalmaihoz kapcsolódik. Ha fájlok helyett egyszerű adatbázist használnánk, akkor a Java SE szoftverfejlesztő tanfolyam 45-52. óra: Adatbázis-kezelés JDBC alapon, ha objektumrelációs leképezéssel oldanánk meg, akkor a Java EE szoftverfejlesztő tanfolyam 25-32. óra: Adatbázis-kezelés JPA alapon alkalmakhoz kötődhet.

Születésnap-paradoxon

2023. szeptember 3.2023. szeptember 2. Szerző: Kaczur Sándor

Mennyi a valószínűsége, hogy n ember között van kettő, akiknek egy napon van a születésnapja? A meglepő a dologban az, hogy már 23 ember esetén a kérdéses valószínűség 1/2-nél nagyobb. Másképpen: már 23 ember esetén nagyobb annak az esélye, hogy megegyezik a születésnapjuk, mint az ellenkezőjének. Ez a 23 nagyon kevésnek tűnik. Ezért paradoxon.

Közismert néhány hétköznapi valószínűség. Íme néhány szabályos eset. A pénzfeldobás során 1/2 az esélye a fej és 1/2 az esélye az írás eredménynek (másképpen 50%-50%, azaz fifty-fifty). A kockadobás esetén 1/6 az esélye bármelyik számnak 1-től 6-ig. Két kocka esetén blogoltam már a dobott számok összegének alakulásáról, eloszlásáról: Kockadobás kliens-szerver alkalmazás.

Néhány egyszerűsítés

Az év 365 napból áll. Nem számítanak a 366 napos szökőévek.
A születések eloszlása egyenletes, azaz minden nap körülbelül ugyanannyian születnek. Nem számít, hogy hétköznap, hétvége, ünnepnap. Az áramszüneti városi legendák sem.
Nem vesszük figyelembe az azonos napon született ikreket. Persze ikrek születhetnek különböző napokon is.

Azonos születésnap valószínűsége grafikonon

Lássuk, hogyan alakul az azonos születésnap valószínűsége az emberek számától függően! Grafikonon ábrázolva:

A fenti grafikonhoz szükséges adatok könnyen előállíthatók az alábbi Java forráskóddal:

private static String scatterChartData() {

List<String> list=IntStream.range(1, 71).boxed().

map(n->String.format(Locale.US,

"%10c[ %d, %.4f ]", ' ', n, 1-Math.pow(364.0/365, n*(n-1)/2))).

collect(Collectors.toList());

return String.join(",\n", list);

}

A fenti Google Chart típusú szórásgrafikon (Scatter Chart, korrelációs diagram) megjelenítéséhez adatpárok sorozata szükséges. Ezek a konkrétumok (70 db adatpár), görgethető:

[ 1, 0.0000 ],

[ 2, 0.0027 ],

[ 3, 0.0082 ],

[ 4, 0.0163 ],

[ 5, 0.0271 ],

[ 6, 0.0403 ],

[ 7, 0.0560 ],

[ 8, 0.0739 ],

[ 9, 0.0940 ],

[ 10, 0.1161 ],

[ 11, 0.1401 ],

[ 12, 0.1656 ],

[ 13, 0.1926 ],

[ 14, 0.2209 ],

[ 15, 0.2503 ],

[ 16, 0.2805 ],

[ 17, 0.3114 ],

[ 18, 0.3428 ],

[ 19, 0.3745 ],

[ 20, 0.4062 ],

[ 21, 0.4379 ],

[ 22, 0.4694 ],

[ 23, 0.5005 ],

[ 24, 0.5310 ],

[ 25, 0.5609 ],

[ 26, 0.5900 ],

[ 27, 0.6182 ],

[ 28, 0.6455 ],

[ 29, 0.6717 ],

[ 30, 0.6968 ],

[ 31, 0.7208 ],

[ 32, 0.7435 ],

[ 33, 0.7651 ],

[ 34, 0.7854 ],

[ 35, 0.8045 ],

[ 36, 0.8224 ],

[ 37, 0.8391 ],

[ 38, 0.8547 ],

[ 39, 0.8690 ],

[ 40, 0.8823 ],

[ 41, 0.8946 ],

[ 42, 0.9058 ],

[ 43, 0.9160 ],

[ 44, 0.9254 ],

[ 45, 0.9339 ],

[ 46, 0.9415 ],

[ 47, 0.9485 ],

[ 48, 0.9547 ],

[ 49, 0.9603 ],

[ 50, 0.9653 ],

[ 51, 0.9697 ],

[ 52, 0.9737 ],

[ 53, 0.9772 ],

[ 54, 0.9803 ],

[ 55, 0.9830 ],

[ 56, 0.9854 ],

[ 57, 0.9875 ],

[ 58, 0.9893 ],

[ 59, 0.9909 ],

[ 60, 0.9922 ],

[ 61, 0.9934 ],

[ 62, 0.9944 ],

[ 63, 0.9953 ],

[ 64, 0.9960 ],

[ 65, 0.9967 ],

[ 66, 0.9972 ],

[ 67, 0.9977 ],

[ 68, 0.9981 ],

[ 69, 0.9984 ],

[ 70, 0.9987 ]

Hasonló grafikon készítéséről szintén blogoltam már: Céline Dion – Courage World Tour.

Párok előállítása

Az emberek születésnapjainak összehasonlítása párokban történik. 23 ember esetén 23*22/2=253 pár van. Általános esetben n ember esetén (n*(n-1))/2 pár adódik. A levezetés részletei a források között megtalálható. 59 ember esetén 1711 pár adódik és szinte garantált az előforduló azonos születésnap, hiszen már 0,99 ennek a valószínűsége.

Az alábbi Java forráskód – rekurzív módon – előállítja a 23 konkrét esetre a párokat, az embereket 1-23-ig sorszámozva. Kombinációk:

private static void combinationsInternal(

List<Integer> input, int k,

List<List<Integer>> output,

ArrayList<Integer> acc, int i) {

int needToAcc=k-acc.size(), canAcc=input.size()-i;

if(acc.size()==k)

output.add(new ArrayList<>(acc));

else if(needToAcc<=canAcc) {

combinationsInternal(input, k, output, acc, i + 1);

acc.add(input.get(i));

combinationsInternal(input, k, output, acc, i + 1);

acc.remove(acc.size()-1);

}

public static List<List<Integer>> combinations(

List<Integer> input, int k) {

List<List<Integer>> output=new ArrayList<>();

combinationsInternal(input, k, output, new ArrayList<>(), 0);

return output;

}

public static void main(String[] args) {

for(int i=23; i<=23; i++) {

List<Integer> list=IntStream.range(1, i+1).

mapToObj(x->x).collect(Collectors.toList());

List<List<Integer>> combinationList=combinations(list, 2);

Collections.reverse(combinationList);

System.out.println(

i+" db elemből:\n"+

list+"\n"+

combinationList.size()+" db pár:\n"+

combinationList);

}

A main() metódusban az i változó paraméterezhető és a konkrét eset könnyen intervallumra változtatható. Eredményül ezt írja ki a program a konzolra, görgethető:

23 db elemből:

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]

253 db pár:

[[1, 2], [1, 3], [1, 4], [1, 5], [1, 6], [1, 7], [1, 8], [1, 9], [1, 10], [1, 11], [1, 12], [1, 13], [1, 14], [1, 15], [1, 16], [1, 17], [1, 18], [1, 19], [1, 20], [1, 21], [1, 22], [1, 23],

[2, 3], [2, 4], [2, 5], [2, 6], [2, 7], [2, 8], [2, 9], [2, 10], [2, 11], [2, 12], [2, 13], [2, 14], [2, 15], [2, 16], [2, 17], [2, 18], [2, 19], [2, 20], [2, 21], [2, 22], [2, 23],

[3, 4], [3, 5], [3, 6], [3, 7], [3, 8], [3, 9], [3, 10], [3, 11], [3, 12], [3, 13], [3, 14], [3, 15], [3, 16], [3, 17], [3, 18], [3, 19], [3, 20], [3, 21], [3, 22], [3, 23],

[4, 5], [4, 6], [4, 7], [4, 8], [4, 9], [4, 10], [4, 11], [4, 12], [4, 13], [4, 14], [4, 15], [4, 16], [4, 17], [4, 18], [4, 19], [4, 20], [4, 21], [4, 22], [4, 23],

[5, 6], [5, 7], [5, 8], [5, 9], [5, 10], [5, 11], [5, 12], [5, 13], [5, 14], [5, 15], [5, 16], [5, 17], [5, 18], [5, 19], [5, 20], [5, 21], [5, 22], [5, 23],

[6, 7], [6, 8], [6, 9], [6, 10], [6, 11], [6, 12], [6, 13], [6, 14], [6, 15], [6, 16], [6, 17], [6, 18], [6, 19], [6, 20], [6, 21], [6, 22], [6, 23],

[7, 8], [7, 9], [7, 10], [7, 11], [7, 12], [7, 13], [7, 14], [7, 15], [7, 16], [7, 17], [7, 18], [7, 19], [7, 20], [7, 21], [7, 22], [7, 23],

[8, 9], [8, 10], [8, 11], [8, 12], [8, 13], [8, 14], [8, 15], [8, 16], [8, 17], [8, 18], [8, 19], [8, 20], [8, 21], [8, 22], [8, 23],

[9, 10], [9, 11], [9, 12], [9, 13], [9, 14], [9, 15], [9, 16], [9, 17], [9, 18], [9, 19], [9, 20], [9, 21], [9, 22], [9, 23],

[10, 11], [10, 12], [10, 13], [10, 14], [10, 15], [10, 16], [10, 17], [10, 18], [10, 19], [10, 20], [10, 21], [10, 22], [10, 23],

[11, 12], [11, 13], [11, 14], [11, 15], [11, 16], [11, 17], [11, 18], [11, 19], [11, 20], [11, 21], [11, 22], [11, 23],

[12, 13], [12, 14], [12, 15], [12, 16], [12, 17], [12, 18], [12, 19], [12, 20], [12, 21], [12, 22], [12, 23],

[13, 14], [13, 15], [13, 16], [13, 17], [13, 18], [13, 19], [13, 20], [13, 21], [13, 22], [13, 23],

[14, 15], [14, 16], [14, 17], [14, 18], [14, 19], [14, 20], [14, 21], [14, 22], [14, 23],

[15, 16], [15, 17], [15, 18], [15, 19], [15, 20], [15, 21], [15, 22], [15, 23],

[16, 17], [16, 18], [16, 19], [16, 20], [16, 21], [16, 22], [16, 23],

[17, 18], [17, 19], [17, 20], [17, 21], [17, 22], [17, 23],

[18, 19], [18, 20], [18, 21], [18, 22], [18, 23],

[19, 20], [19, 21], [19, 22], [19, 23],

[20, 21], [20, 22], [20, 23],

[21, 22], [21, 23],

[22, 23]]

Kísérleti ellenőrzés

Tekintsünk például 1000 esetet! Készítsünk Java programot, amely 23 db véletlen születésnapot generál! Legyen ez a születésnap sorszáma az évben (másképpen hányadik napon született az ember az évben). Ez lényegesen egyszerűsíti a megoldást, összevetve a dátumkezelésen alapuló megközelítéssel. Ajánljuk a szakmai blog dátumkezelés címkéjét az érdeklődőknek, ahol megtalálhatók a témához kapcsolódó Java forráskódrészletek részletes magyarázatokkal kiegészítve. Íme a többféle generikus listát és programozási tételt használó forráskód:

public static void main(String[] args) {

final int COUNT=1000;

ArrayList<String> list1=new ArrayList<>();

int count2=0;

for(int i=1; i<=COUNT; i++) {

ArrayList<Integer> dayList=new ArrayList<>();

for(int n=1; n<=23; n++) {

int day=(int)(Math.random()*365+1); //1-365

dayList.add(day);

}

Collections.sort(dayList);

System.out.println(dayList);

ArrayList<String> list2=new ArrayList<>();

int n=0;

while(n<dayList.size()) {

int currentDay=dayList.get(n), count1=0;

while(n<dayList.size() && dayList.get(n)==currentDay) {

count1++;

n++;

}

if(count1>1)

list2.add(i+","+currentDay+","+count1);

}

if(!list2.isEmpty()) {

list1.add(list2.toString());

count2++;

}

System.out.println("\n"+list1+"\n"+COUNT+" esetből "+

count2+" kedvező eset fordult elő");

}

Érdemes elemezni, tesztelni a fenti forráskódot: milyen lépésekben, milyen adatszerkezeteket épít. Hasznos lehet lambda kifejezésekkel kiegészíteni, módosítani a programot. Részlet a program szöveges eredményéből:

[4, 14, 31, 34, 73, 85, 88, 110, 119, 125, 132, 140, 148, 183, 241, 249, 255, 265, 272, 289, 303, 353, 355]

[7, 16, 40, 67, 72, 72, 79, 89, 96, 128, 141, 142, 203, 215, 217, 219, 230, 243, 250, 272, 273, 321, 325]

[63, 70, 70, 87, 92, 106, 112, 113, 115, 123, 124, 131, 138, 139, 164, 165, 173, 177, 179, 180, 241, 310, 357]

[45, 48, 73, 75, 94, 103, 117, 161, 168, 170, 202, 223, 231, 235, 240, 252, 254, 255, 260, 272, 274, 284, 301]

[2, 2, 3, 13, 39, 47, 66, 94, 148, 151, 153, 160, 161, 166, 179, 212, 223, 254, 280, 311, 316, 324, 340]

[5, 32, 36, 71, 74, 80, 96, 115, 120, 150, 167, 167, 169, 219, 255, 259, 283, 289, 304, 306, 317, 336, 359]

[4, 5, 17, 46, 65, 78, 78, 79, 95, 106, 116, 138, 189, 228, 251, 253, 304, 332, 332, 334, 337, 347, 362]

[12, 14, 15, 67, 76, 77, 113, 126, 154, 161, 184, 195, 204, 214, 216, 225, 225, 225, 227, 229, 235, 236, 348]

[5, 7, 18, 28, 55, 71, 83, 126, 126, 129, 150, 158, 169, 221, 224, 231, 242, 253, 267, 300, 321, 326, 329]

[19, 37, 47, 49, 80, 89, 94, 122, 145, 165, 174, 190, 211, 215, 241, 265, 286, 287, 295, 297, 325, 354, 361]

...

[[2,72,2], [3,70,2], [5,2,2], [6,167,2], [7,78,2, 7,332,2], [8,225,3], [9,126,2]...

1000 esetből 506 kedvező eset fordult elő.

A 12. sorban lévő számhármasok jelentése: esetszám 1-től, azonos nap, előfordulás száma. Például: a kísérlet során a 8. esetben az év 225. napja azonos 3 embernél. Természetesen nincs garancia arra, hogy az 1000 eset vizsgálatánál mindig 500-nál nagyobb kedvező esetet kapunk.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 17-28. óra Objektumorientált programozás alkalmaihoz kötődik.

Források

Születésnap-paradoxon – Wikipédia
Stráhl, I. (2016): Születésnap paradoxon – lesz olyan, aki osztozik a tortán?
Kasnyik, M. (2019): Harmadával kevesebb gyerek születik hétvégéken és ünnepnapokon, mint hétköznap
J. Frost (2020): Answering the Birthday Problem in Statistics
K. Azad (2018): Understanding the Birthday Paradox
Vsause2 (2019): The Birthday Paradox – YouTube
P. Com, M. Habib, T. Suresh, L. Weinstein, C. Lin, J. Khlm, E. Ross (2022): Birthday Problem | Brilliant Math & Science Wiki
Baeldung (2022): Overview of Combinatorial Problems in Java

Tankocka – Rövid válasz: Java konstansok

2023. augusztus 3.2022. november 1. Szerző: Kaczur Sándor

Folytatjuk Tankockák blog bejegyzés sorozatunkat. A feladatban 12 db Java konstans értékét kell megadni, számként. Ez a témakör főként a Java SE szoftverfejlesztő tanfolyamunkhoz kötődik. Hasznos ismerni a JDK-beli konstansokat, mert alapvetően befolyásolják egy adatszerkezet, objektum működését, viselkedését akkor is, ha külön nem adjuk meg a létrehozó konstruktorok meghívásakor minden paramétert.

A konstansok hathatnak a memóriafoglalásra, a grafikus komponensek megjelenésre, Meghatározhatják a hálózati kommunikáció időzítését, paraméterezhetik a fájlkezelés működését. Egy-egy algoritmus (például: rendezés, keverés, véletlenszám-generálás) indítását, működését is befolyásolják a konstansok. Vajon hányat tudsz az alábbi konstansok közül? Hogyan, mire hatnak ezek?

Kik vettek részt projektmunkában?

2023. január 3.2021. november 17. Szerző: Kaczur Sándor

Hasonlítsuk össze a részlegeket fókuszálva arra, hogy az alkalmazottak mennyire vettek korábban részt projektmunkákban! Hányan igen és hányan nem? Van(nak) olyan részleg(ek), amelyik vezetője egyetlen alkalmazottat sem vont be projektmunkába? Van(nak) olyan részleg(ek), ahonnan mindenki csatlakozott? Vannak a feladatkiosztásban olyan aránytalanságok, amelyek kimutathatók és így a későbbiek során korrigálhatók? Készítsünk egy kimutatást arról, hogy részlegenként hány fő vett részt projektmunkában és mi a létszám! (Persze tudjuk, hogy nem minden munkakörből vonhatók be alkalmazottak.) Milyen projektjeink szoktak lenni? Van olyan részleg, ahol érdemes bővíteni a létszámot, esetleg átcsoportosítani oda erőforrást? Ezekre a kérdésekre keressük a választ.

Tervezés

Az Oracle HR sémában három tábla kapcsolódik a feladathoz: JOB_HISTORY, EMPLOYEES, DEPARTMENTS. A kapcsolatok fokszámai láthatók az alábbi ábrán. Egy részlegben több alkalmazott is lehet. Egy alkalmazott részt vehetett korábban több projektmunkában is.

A DEPARTMENTS táblában található a részleg azonosítója ( DEPARTMENT_ID, kulcs) és neve ( DEPARTMENT_NAME). A többi adat most nem kell. 11 olyan részleg van, amihez tartozik alkalmazott.

A JOB_HISTORY tábla tárolja, hogy a már befejeződött projektekben ki ( EMPLOYEE_ID, külső kulcs) és melyik részlegből ( DEPARTMENT_ID, külső kulcs) vett részt. A dátumokat ( START_DATE, END_DATE) és a munkakör külső kulcsát ( JOB_ID) most nem használjuk. Minden projekt lezárt. 10 lezárt projekt van.

Az EMPLOYEES táblából szükséges az alkalmazott azonosítója ( EMPLOYEE_ID, kulcs), valamint részlegének azonosítója ( DEPARTMENT_ID, külső kulcs). A többi adatra most nincs szükség, de egy részletesebb – például név szerinti – kimutatáshoz már igen. 106 olyan alkalmazott van, akihez tartozik részleg (1-nek nincs).

Hozzunk létre négy oszlopból álló eredménytáblát: DEPARTMENT_ID, DEPARTMENT_NAME, COUNT_PROJECT_EMPLOYEES, COUNT_EMPLOYEES. Ennek áttekintésével választ kaphatunk a fenti kérdésekre.

1. megoldás

Induljunk ki abból, hogy a JOB_HISTORY táblában lévő DEPARTMENT_ID-hez hozzárendeljük a DEPARTMENTS táblából a DEPARTMENT_NAME-t. Ezekre csoportosítva könnyen aggregálható az adott részlegből projektmunkát végző alkalmazottak száma: COUNT_PROJECT_EMPLOYEES. Végül egy belső lekérdezés (összekapcsolva a JOB_HISTORY és az EMPLOYEES táblákat) megadja az adott részleg alkalmazotti létszámát. Az SQL lekérdezés:

A részeredmény:

Ezután állítsuk elő a hiányzó adatokat! Tudjuk, hogy azokban a részlegekben, amelyek DEPARTMENT_ID-je nem szerepel a JOB_HISTORY táblában, de szerepel az EMPLOYEES táblában, azok léteznek, de nem „adtak” projektmunkára alkalmazottat (azaz COUNT_PROJECT_EMPLOYEES=0). Nevük és alkalmazottaik száma ugyanúgy megadható, ahogyan az előbb. Az SQL lekérdezés:

A részeredmény:

A két részeredményt egyesíteni kell és egyben hasznos DEPARTMENT_NAME szerint növekvő sorrendbe rendezni az alábbi lekérdező paranccsal:

Az eredmény:

2. megoldás

Kiindulhatunk abból is, hogy a DEPARTMENTS egy szótártábla, így közvetlenül hozzáférhető a DEPARTMENT_ID és a DEPARTMENT_NAME, de össze kell kapcsolni az EMPLOYEES táblával, hogy csak olyan részlegeket adjon vissza a lekérdezés, ahol van(nak) alkalmazott(ak). Az eredményhez szükséges további két oszlop könnyen aggregálható az adott részlegre vonatkozóan: a JOB_HISTORY táblában előforduló EMPLOYEE_ID-k száma adja a COUNT_PROJECT_EMPLOYEES-t (probléma nélkül tud 0 lenni) és az EMPLOYEES táblában előforduló EMPLOYEE_ID-k száma adja a COUNT_EMPLOYEES-t. A rendezés most is szükséges. Lényegesen tömörebb lekérdező parancsot kapunk:

Az eredményül kapott táblázat megegyezik az 1. megoldás eredményével.

A két megoldás teljesen különböző gondolatmenettel született. Mindkettőben vannak olyan elemek, amelyek – konkrét feladatból általánosítva – univerzálisan használhatók. Természetesen összehasonlítjuk a két megoldás végrehajtási tervét és részletesen elemezzük is.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java adatbázis-kezelő tanfolyam 9-12. óra: Oracle HR séma elemzése, 13-16. óra: Konzolos kliensalkalmazás fejlesztése JDBC alapon, 1. rész, 33-36. óra: Grafikus kliensalkalmazás fejlesztése JDBC alapon, 2. rész alkalomhoz kapcsolódik.

Céline Dion – Courage World Tour

2023. január 1.2020. június 1. Szerző: Kaczur Sándor

A Céline Dion – Courage World Tour esettanulmányunkban a turné első részének koncerthelyszíneit jelenítjük meg Google Charts segítségével. Ebben a blog bejegyzésben a tervezés, megvalósítás lépéseit tekintjük át és megmutatjuk az eredményeket. A Java és JavaScript forráskódokat most nem részletezzük.

Háromféle grafikont használunk

idővonal (Timeline) időpontok és helyszínek Gantt diagram-szerűen,
térkép (Geo Chart) városok megjelölésével és időpontok jelmagyarázatban,
tematikus térkép az USA államaival (szintén Geo Chart), az állam területén adott koncertek száma alapján és db jelmagyarázatban.

A tervezés és megvalósítás lépései

Adatokat kell szerezni egy weboldal (https://www.celinedion.com/in-concert/) feldolgozásával ( saveHTML()). Ehhez a művelet a GET. Figyelni kell a megfelelő User-Agent paraméterezésére és a karakterkódolásra ( ISO-8859-1). A kapott bemeneti folyam feldolgozását pufferelt módon érdemes elvégezni. Célszerű az adatforgalom minimalizásása érdekében a weboldal tartalmát helyi fájlba menteni ( tour.html). Ügyelni kell a kötelező és az ajánlott kivételkezelésre.
Értelmezni kell a tour.html fájlt. A HTML tartalom végén JSON formátumban beágyazva elérhetők a koncert turné állomásainak adatai: nekünk kell a város ( city), helyszín ( venue), dátum/idő ( startDate). Érdemes külön fájlba menteni a tour.html-ből a JSON tartalmat ( tour.json), mert abból egyszerűen betölthető ( saveJSON()).
Tanulmányozni kell a Google Charts diagramok közül azt a kettőt, amiket testre kell szabni: Timeline és Geo Chart. Tudni kell: mi a diagramot tartalmazó weboldal állandónak tekinthető eleje és vége (ezeket hasznos külön interfészben konstansként tárolni: HTMLFileContent), valamint mi az adatoktól függő része (közepe). Ismerni kell a szükséges metaadatok és adatok formátumát. Érdemes átnézni a különböző testre szabási és formázási lehetőségeket a fenti diagramtípusoknál (esetleg a többi típusból is meríthetünk ötleteket).
A koncert turné állomásainak összetartozó 3 adatát le kell képezni POJO-vá ( Event). Ezt érdemes privát változókkal ( city, venue, startDate) és factory metódussal megvalósítani. Célszerű, ha az adatok visszakérésére alkalmas getter metódusok is készülnek ( getTimelineChartDataTableRow(), getGeoChartDataTableRow()), amelyek kiszolgálják a megfelelő diagramtípus igényeit.
A tour.json fájl feldolgozásával (parszolásával) Event típusú generikus listába vagy JSON tömbbe könnyen leképezhetők az adatok.
Hasznos egy vezérlőosztály létrehozása, amely a 3 diagramtípust előállító (HTML fájlt generáló) metódust ( createTimelineChart(), createGeoChartCity(), createGeoChartCountry()) valamint a belépési pontot ( main()) tartalmazza.
Generálható az idővonalat tartalmazó timelineChart.html fájl a createTimelineChart()metódussal. Ehhez 5 oszlop megadása szükséges (ebben a sorrendben): label, city, tooltip, start, end. Az első 3 adat string, az utolsó 2 adat date típusú. Egy példa Event: ['2019.09.18.', 'Québec, QC', 'Videotron Centre', new Date(2019, 09, 18, 19, 0, 0), new Date(2019, 09, 18, 21, 0, 0)].
Regisztrálni kell egy Google Cloud Platform felhasználói fiókot és tanulmányozni kell a geokódolás folyamatát és lehetőségeit, hiszen a városok nevéből (formátum pl.: 'Minneapolis, MN') szükség lesz azok térképi koordinátáira. Aktiválni kell a szolgáltatás használatához szükséges mapsApiKey-t.
Generálható a városokat tartalmazó geoChartCity.html fájl a createGeoChartCity() metódussal. Ehhez 3 oszlop megadása szükséges (ebben a sorrendben): city, dateCity, no . Egy példa Event: ['Minneapolis, MN', '2019.11.01. Minneapolis, MN', 1].
Generálható a régiókat/államokat tartalmazó geoChartCountry.html fájl a createGeoChartCountry() metódussal. Ez egy tematikus térkép: a különböző színek jelölik az egy régió/állam városaiban tartott koncertek számát. Ehhez az adatok megfelelő rendezését követően végrehajtott csoportváltás algoritmus szükséges. 2 oszlop megadása szükséges: country, concertNo. Egy példa adatsor: ['US-TX', 3].

Az eredmények

TimelineChart grafikon:

GeoChartCity grafikon:

GeoChartCountry grafikon:

Érdemes megismerni további – térképekhez kapcsolódó – grafikontípusokat is: Geomap, Intensity Map.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A példák a Java SE szoftverfejlesztő tanfolyam 37-44. óra: Fájlkezelés és a Java EE szoftverfejlesztő tanfolyam 1-4. óra: Elosztott alkalmazások, webszolgáltatások és 13-16. óra: JSON feldolgozás alkalmaihoz kötődnek.