Megérdemelné, de ahhoz topicírók és topiclátogatók kellenének legelébb is, hogy ne fulladjon unalomba. Mindenesetre ha valaki létrehozza és még én is tudok róla, akkor felveszem a topic-favoritok közé, mindaddig amíg szinten tudjuk művelni az eszmecserét... :o)
Topiccím javaslat lehet a Business Intelligence és/vagy Knowledge Management D(ata)W(arehouse) alapokon. Abban triviálisan benne van a DW, mégis nagyobb esélyt kaphatna az érdeklődésre.
Az adattárház építés szerintem egy nagyon érdekes téma, megérdemelné, hogy külön témában tárgyaljuk. Amúgy meg gyanítom, hogy nem csak Oracle RDBMS-el lehet megvalósítani, hanem AS-400-al és PostgreSQL-lel is.
>Bár pont a Warehouse Builder az fejlődik, mostanában jelent meg egy új verzió, amit nagyon dicsértek. Igen én is hallottam, még hajlandó is lennék bizalmat elölegezni neki... De! - Egyáltalán nem vagyok biztos, hogy tervezési (Designer) és üzemeltetési (Monitoring) feladatokra nem kell kívülről hackelni az OWB-t, hogy használható legyen, még ha el is fogadjuk, hogy a mostani verzió már legalább működőképes. - Ha migrálni kell, pláne beletúrva, pl.: OWB 2.1-ről -> azt senkinek nem kívánom. - Milyen felháborító dolog, hogy időnyomás alatt, az Oracle márkanév miatt egy félkész és hibás ám pénzes OWB-t nyomat(hat)tak ezerrel stratégiai termékként, aminek nyomán, szívott vele mindenki, mint a torkos borz... És a befolyt nemkis pénzekből évek(!) után mostanra sikerült esetleg valami használhatót az asztalra letenni...
>Discoverer Na ezt nem is kommentálom, ezt talán még jobban utálom, mint az OWB-t. ;)
>mert egy csomó helyen nem sikerül megépíteni elsőre, amit szeretnének, úgyhogy többször kell próbálkozni :-) Evvel csak az a probléma, hogy _nagy_ tételről van szó, és _eljátszott bizalmat_ kell visszaszereznie a második beszállítónak. Maradjunk abban, hogy nemtriviális...
>Én például egy olyan céget sem ismerek, aki arról lenne híres, hogy sok és jó adattárházat épített. Egyet az értés, de maximálisan... ;)
>Viszont amit a két 101%-os beszállítóról egymásról való viszonyáról írsz, az szerintem nem csak erre a területre igaz, és nem csak kis hazánkban :-)
Nem értek egyet. Szerintem bőven vannak konszenzusos területei az informatikának. Melyik informatikus fog pl.: Rdbms helyett Hálós vagy 100%pure OO adatbáziskezelőt ajánlani? Ugye, hogy egyik se. Vannak jól kitaposott ösvények meghatározott témákban. Nem azt mondom, nincs lehetőség eltérni, de egymástól függetlenül is tud ugyanarra a szakmai álláspontra jutni két vagy több szakember. Az adatbányászat noha baromira fejlődik, közel nem annyira gáz, mint a DW.
Na de az adattárház, az pont nem ilyen téma... ;) (igaz nem egyedüliként, hasonlóan gázos mint mondjuk például a Java AppServeres alkalmazásfejlesztés /szvsz/) N-dimenziós komplex tér, és csak az az opció melyik ujjadat milyen sorrendben, hogyan harapd meg. ;) Elvek csak azért vannak a témát értintően, hogy meg lehessen sérteni őket, hogy legalább egy ellentmondást fel lehessen oldani, generálva két újabb ellentmondást... ;) -> Kicsit cinikus vagyok (ami helytelen valahol), de azt gondolom még mindig nagyon sokat kell tisztulnia a DW-témának, általánosságban, teljes keresztmetszetében. Ami persze nem azt jelenti, hogy adott esetben nem lehet kielégitő DW-megoldást szállítani.
BTW: Ugye tudjátok, hogy van open source adattárházat adatbáziskezelő? És hozzá full szintén open source BI-platform?
Az egy általános vélemény az általam ismert szakmai körökben, hogy az Oraclenek egy jó terméke van az: az adatbáziskezelő. Sőt nem is csak jó, hanem kiváló.
Viszont a többi cucc (Oracle Designer, Discoverer, Warehouse Builder), azok olyan közepesek. Meg egy kicsit elavultak. Bár pont a Warehouse Builder az fejlődik, mostanában jelent meg egy új verzió, amit nagyon dicsértek. Meg most van új csodaeszköz a Discoverer helyett, amit a Siebeltől vettek.
Az adattárház építés biztos hogy bonyolult ügy, rengeteg technikai és egyéb tudás kell hozzá. A sok ilyen témájú álláshirdetés talán pont azért van, mert egy csomó helyen nem sikerül megépíteni elsőre, amit szeretnének, úgyhogy többször kell próbálkozni :-)
Amit a beszállítókról írsz, az meg nagyon igaz. Én például egy olyan céget sem ismerek, aki arról lenne híres, hogy sok és jó adattárházat épített. Viszont amit a két 101%-os beszállítóról egymásról való viszonyáról írsz, az szerintem nem csak erre a területre igaz, és nem csak kis hazánkban :-)
Néha azt érzi az ember, hogy tényleg a világ legnagyobb szélhámossága, mondom ezt én (is), aki a legutóbbi hatéves munkaviszonyomat döntően (Oracle) adattárház témában tengettem... ;)
Pillanatok alatt lehet milliók sokaságát belefeccölni, kétes megtérüléssel, mitöbb gyatra eredménnyel. A határ- és megtérülési időkről már nem is beszélve. Hányszor lehet hallani mezei felhasználóktól: az OLTP-rendszerek _hozzák_ sőt termelik a pénzt, a DW csak _viszi_ a pénzt, zabálja az erőforrásokat /másképp terheli a szervert, tehát kerülendő az OLTP-k összeházasítása DW-vel/.
És persze, ha nem jó adatok kerülnek a DW-be, akkor persze a várt eredmény is egyenes arányban nem lesz jó. Aminek következtében majd az elemzők visszatérnek a forrásrendszeri ilyen-olyan riportokhoz és majd házilagosan fognak maguknak - miben másban mint Microsoft Accessben - mini DW-t építeni, ami majd persze 'tuti' lesz. Ha két elemző két különböző szumma-totált hoz ki ily módon, annak egy konklúziója lehet csak, hogy hülyék az informatikusok. Aki azt hiszi viccelek, ki kell ábrándítsam; maximálisan komolyan beszélek. :o( Mi a bekezdés üzenete? Kulcsfontosságú, hogy a felhasználók bízzanak és lehetőleg konszenzussal bízzanak a DW adataiban. Ha oda a bizalom, a DW nem olyan műfaj, hogy kidobjuk és majd építünk egy másikat...
Na de persze az egész "DW-szélhámosság" ott kezdődik, hogy mindenki mást ért DW alatt (miközben az OLTP rendszerek esetén tulajdonképpen konszenzus van e téren). BTW: Találtunk egy neves amerikai DW-guru website-ján egy definiciót: sikítani lehetett, akkor baromság volt.
Folytatódik ott, hogy eléggé különböző DW-építési módszertanok vannak. És nem a fejlődés miatt, hanem a koncepcionális alapvetés különbözősége miatt...Kérdeztem egy architectet nem olyan régen, ő hogyan építene adattárházat. "Venném a nagy könyvet, és végigcsinálnám az ajánlott módszertant, lépésről-lépésre." - volt a válasz (utalva arra, hogy nem házilag kell hackelni DW-t) Kérdezem: "na jó, de melyiket?" Na, itt végeszakadt a beszélgetésnek.
Még abban sem tudtunk közös nevezőre jutni, hogy akkor most van-e értelme az "operatív adattárháznak" vagy nincs. (Hogy lehessen legalább némileg érteni /akinek új a téma/, hogy miről beszélek -> például bankoknál az 'ügyfél-érték' egy nagyon bonyolult adattárházas származtatási folyamat outputja, ügyfelenként, of course. Viszont mindig frissnek és online elérhetőnek kell lennie hiszen minden - banki ügyfelet érintő - üzleti folyamat ezen az ügyfélértéken alapszik /Customer Value/).
Másik ugyanilyen kritikus téma: hogy hányrétegű legyen az adattárház. Lásd még '/replikációs/ operativ store kontra stage" problémakört is. Bizonyos folyamatok miatt szükséges lehet akár három réteg is. Na most ilyen esetben, üzleti folyamatok változásakor elképzelhető a végiggörgetés nem épp triviális mivolta... Az OLTP-ket sokkal könnyebb, rugalmasabban & olcsóbban, bővíteni, változtatni. És az esetek 99%-ban senki nem gondol ott arra, hogy ebben a pillanatban akár inkonzisztens is lehet a kérdéses megújult OLTP forrásrendszer a DW-vel ;s ekkor ez vagy plusz költség-allokálást igényel vagy devalválódik a DW értéke. Ismétlődik a történelem: a raktáros is saját adatbázist akart annó, a számlázó is. Aztán lehetett intenzíven "egyeztetni"....
Mindenképpen elmondható, nagyon nehéz jó DW-adatmodellt építeni (sokkal nehezebb, mint OLTP esetében), például mert nagyon nehéz kidobálni forrásrendszeri attributumokat a DW-t kincsesbányaként használó jövőbeli adatbányász alkalmazás miatt. Nehéz téma az aggregálás és mikéntje is, a rétegezéssel összefüggésben is. Én láttam már olyat, hogy évek múltán is(!) fontos rejtett üzleti összefüggést hámoztak ki hozzáértő kollégák a DW-ből: ami alapján például termékfejlesztést lehetett csinálni...
A harmadik kritikus pont, ami így két sör között eszembejut: az egységes vállalati fogalomtár. Hogy például - kedvencem - "átlagegyenleg" c. fogalmon a kockázatkezelő és az üzletkötő ugyanazt értse.
Na és ha megyünk lejjebb a következő szintre (eszközök), akkor lehet csak igazán káromkodni, ha eddig még nem tettük. Én szeretem az Oracle Rdbms-t, jó megvalósításnak tartom, de itt az Oracle-topicban le merem írni, hogy kb.: 9i-ig az Oracle Warehouse Builderhez fogható lepratelep eszközt nagyítóval kellett keresni a nagyvilágban. Úgy mérték aranyárban, hogy eszement módon bugos volt, sok más koncepcionális hibája mellett. Egyébként jellemző, hogy wing-to-wing tekintve a különféle DW-eszközök (ETL-tool, metainfókat kezelő adatbázis stb) nagyon, de tényleg nagyon drágák (szerintem indokolatlanul). Az elrettentő példa az Informatica.
Nagyon nehéz hosszútávon működő- és fejlödőképes DW-t építeni főleg reális áron. De ha jól sikerül, óriási lehetőségek vannak benne, nagy informatikusi örömök kincsesbányája... :o) Ha valaki beszállítóval építtet DW-t, nagyon nézze meg kire bízza, és 101%-ban bízzon meg benne, ami azért nehéz ügy, mert ha talál még egy olyan beszállítót, akiben meg tudna 101%-ban bízni, akkor fogadást köthet, hogy a két beszállító két különböző szakmai álláspont mentén képzelné el a feladat abszolválását... Cinikusnak tűnik a megállapítás, de a magyar valóság ez, szerintem...
- Érdekes lenne kipróbálni, hogy a view helyet inline viewt használsz, akkor is fennáll-e a probléma..
- Következetesen fellépő Filevége.. típusú gondok 99%-ban ORA-00600-as típusú internal errorok szoktak lenni. A globálisan ajánlott javaslat: trace-generálás és, metalinkre felnyomás... Metalink hiányában, workaround fabrikálás. Meg lehet próbálni a hibabehatárolást is, de valószínűsthetően több erőforrást fog igényelni...
>a hosszú lekérdezések batch jellegű feladatok, ha előre meg lehet paraméterezni fussanak éjszaka
Az egyik klasszikus ám nagyon nehéz téma szerintem, amit felhoztál... Alap állásban ugye vannak az OLTP és DW-rendszerek, mint két teljesen másképp konfigurálandó rendszer... De ha nincs DW, akkor is szokott kelleni riportálni OLTP-rendszerekből...
Problémák:
- Egyetlen instance legyen avagy legyen plusz snapshotolt db a riportolásra. - Ha van snapshotolt riportszerver, megengedhető fogalom-e az operatív riportolás, ami mégis csak maradna az original OLTP-rendszeren...
Tapasztalataim szerint ezügyben ölre tudnak menni az emberek... ;) Ne higyjük, hogy triviális a feladat. Amikor a nagy Oracle Corp. meghírdette a Single Instance elvet és vonatkozó saját projektjét a Sziklás Hegység gyomrába (minden adatot egy adatbázisba), akkor azért a riportálásra ő is külön snapshot-szervert állított be. Még a RAC-oknál is, per a mai napig is megérezhető, ha valaki húzós aggregált riportot futtat (Oracle-sök mesélték)....
Mi a probléma, ha csak egy adatbázis van... Ugye jó az, hogy egy helyen van mindig frissen és konzisztensen az összes adat. Viszont egyetlen nagyobb aggregált riport hazavághatja a db-t OLTP-ként használó ügyintézőket (performancia oldalról). Továbbá, különösen ha van például napi zárás című fogalom, akkor a 24/7-es működést nehéz igencsak megvalósítani...
Mi a probléma, ha van snapshot... Ugye, jó, hogy a nagy riportok futása tetszés szerint futtathatók/ütemezhetők, jó az, hogy az elsődleges OLTP rendszer lehet 'asszimmetrikusan' & vertikálisan kisebb (nem 1:1-es tükör, kevesebb rekorddal, mondjuk csak az aktívan használt adatokkal). De!! A friss adatok mindig csak az origin rendszerben lesznek _biztosan_, operatív riportok ignorálása nehezen garantálhatók tehát, BCP/DR nagyságrendekkel nehezebb téma asszimmetrikus rendszerösszeomlás esetén. És lássuk be az adatkonzisztencia garantálása azért fog generálni extra feladatokat... A 24/7-es működési szempomból is vannak plusz feladatok.
PS: Én csíkpárti vagyok... Akkor is, ha tisztában vagyok ez egy plusz funkcionalitás, ami további erőforrást igényel, és sokszor merül fel úgy a kérdés, hogy legyen a futás 1mp, de csík nélkül, vagy 3mp, de csíkkal. Persze nem mindenáron... A csíkhúzásért nem feltétlen kell egy alternatív Oracle SQL-Engine-t írni... ;)
Sziasztok, a hosszú lekérdezések batch jellegű feladatok, ha előre meg lehet paraméterezni fussanak éjszaka. Az eredmény mehet munkaterületre, és agy levél, vagy feladatkiosztás, hogy a munkatárs anyaga kész van, és nézze meg. Akkor pedig pillanatok alatt ki lehet már adni. Ha pedig egy percnél tovább bámul egy növekvő csíkot, az pénzkidobás. Édesviz
>Minél nagyobb volt a sokaság, annál pontosabb letta becslés.
Ezt én is írtam: minél nagyobb az idősor annál jobb lesz a várható becslés. Persze az izgalmas kérdés; hogyan kell becsülni, ugyanis nemcsak mezei átlagolásban érdemes gondolkodni. BTW.: Épp mostanság foglalkozom igen intenzíven idősor-analízissel ( idősorokkal és predikcióikkal). Ha valaki nem ismerné a témát, annak mondom... Nem viccelek: gyönyörű tudomány, elképesztően fantasztikus lehetőségekkel... :o) Egy szimpla kopasz exponenciális símítás(smoothing) is csodákra képes, és ez csak a könnyű fegyverzet kategóriája...
Két probléma lehetséges, hogy a témánál maradjunk...
Mennyire jellemző az átlagos terheléshez képest szélsőséges működés és mekkora a - nevezzük most így - szórás. Ha tartósan rossz a performancia, ott egyéb tervezési/üzemeltetési gáz is van, így ez offtopic itt (szerintem). Tehát feltehető, hogy csak alkalmankénti kilengésekkel kell számolni. A kilengéseket viszont lehet mérni, és egy adott ponton lehet akciót is kezdeményezni...
Ha valaki tényleg nagyon sokat akar programozni az ügy érdekében, akkor a csík mellé számokat is pörgethet pluszba (pl.: blokkolvasás), előtérben is, háttérben is. Ráadásul előre tudható a nagyságrendje, persze csak adott végrehajtási tervnél (kötelező hozzá tehát a tervstabilitás. Közismert ajánlat az altémában Oracle 9i-től az outline-ok). És persze ekkor már megfogható ha a lekérdezés-végrehajtás fagyizik.
Kérdés létezik-e olyan interakció, ami megköveteli ezt a fajta rugalmas automatikus gépi intelligenciát/kiszolgálást. Nem elég-e hogy ha valakinek lassú a cucc, akkor vélhetően mindenkinek lassú a cucc, és megkérdezni a DBA-t aki már a folyamatos monitorozás+alert miatt már eleve proaktívan - ugye- képben van, hogy mikorra lesz normális állapot a szerveren....
Remélem nem vagyok túl idealista egy ilyen szöveggel... ;)
Ha valakinek tényleg komolyan kell ilyesmi, de nem akar programozni, aranyárban tud venni ilyesmi szoftokat (pl.: Patrol). Azok még működési vizuális diagramokat is felívelnek a felhasználók monitorjaira. Szerintem túl drágák, és általánosságban nem elég erősek... Adott körülmények között 80%/20% elvnek persze sokszor meg tudnak felelni... /Azaz érdemes nagyon kitesztelni őket, vásárlás elött/
Én annó szakmai kiváncsiságból elkezdtem egy ilyen wing-to-wing monitorozó rendszer adatmodelljének megtervezését, nálunk az volt a peremfeltétel/premissza, hogy a storage volt a szűk keresztmetszet, ami baromi lassú volt ugyan, de ontotta magából a lekérdezhető adatokat, amiből előre tudható volt, mikor dugul majd be a szűk keresztmetszet... Senkit nem izgatott a téma, rajtam kívül. Pedig közel nem volt annyira komplex az egész, és nem biosokat kellett volna hozzá realtime hackelni unix-vénájú assamblyben...
Anno én is próbáltam valami hasonlóval, de pár hét után beláttam, nem sok értelme van. Túl sok tényező van ami miatt az értékeket nagyon nehéz megbecsülni. Egy dolog működött egy ideig, ami tapasztalati úton számolt átlagot. Minél nagyobb volt a sokaság, annál pontosabb letta becslés. DE elég volt pár - teljesen független - performance issue, és a felhasználók fikáztak, hogy rossz az érték, akkor inkább ne is legyen semmi... A V$SESSION_LONGOPS egy nagyon hasznos dolog, de én arra használom elsősorban, hogy segítségével kiszúrom az indokolatlanul "terhes" folyamatokat
Szia tnsname.ora. Köszönöm a gyors és főleg használható választ. Szerencsére az adatbázisunk verziója 9i, úgyhogy utánanézek az Általad vázolt lehetőségeknek. Remélem a Neten találok elég infot a dologhoz. Köszi még1x. Üdv, Márk
A saját tapasztalatomra hagyatkozva gondolom, hogy a role-on keresztüli jogosultság lesz a gond. Az mondjuk nem derült ki pontosan, hogy már a procedure fordítása sem sikerült, vagy csak futtatáskor volt hibaüzenet? Utóbbi esetben valóban máshol kellene keresni a problémát.
>ha azt mondanátok, hogy létezik megoldás, mert szerintem nemigen,
Ne légy pesszimista... ;)
Ha az adatbázis verziója minimum 9i, akkor van egy speciális adatszótárnézet V$SESSION_LONGOPS és abban egy TIME_REMAINING mező... Csodákat ne várj, de az idő haladtával, a végrehajtás befejeződéséhez egyre közelebb kerülve egyre pontosabb lesz az érték... Az mondjuk hátránya a megoldásnak, hogy időközönként le kell kérdezni az értéket, ami szintén erőforrásigényes...
http://www.ss64.com/orav/V$SESSION_LONGOPS.html
Ha szeretsz sokat programozni le lehet tárolni a kritikus sqlek végrehajtási idejét és aztán azt lekérdezve tudsz csíkot húzni... Minél gazdagabb körítéssel (rekordszám, párhuzamosan aktív userek száma stb.) tárolod e segédadatokat - időben visszafele minél hosszabb idősorban; annál precizebb lesz a csíkhúzásod...
Sziasztok! A következőben kérném segítségeteket: adva van egy Linux alatt futó Oracle Application Server és ezen egy több milliós rekordszámú, pár száz táblából álló adatbázis. Weben keresztül végzünk lekérdezéseket XP-s kliensekről, és némelyik igen összetett, noha csak viszonylag egyszerű SELECT-eket tartalmaz. Ez a lekérdezés-tömeg néha a 10 percet is meghaladja. Szerintetek létezik-e arra valamilyen megoldás, hogy ha a user elindítja a lekérdezést egy FORM SUBMIT-jára kattintva, hogy egy indikátor visszajelezzen, hogy mennyi a becsült hátralévő idő a lekérdezés befejezéséig? Tehát, hogy egyértelműbb legyen a kérdés: a webböngészőben kellene valami számláló, vagy futó csík, ami viszonylag pontosan jelzi, hogy mikorra várható a böngészőben a lekérdezés eredménye. (Bocsi, ha triviális lenne a kérdés; nem értek a PL/SQL-hez, Oracle adatbázisok kezeléséhez. Webfejlesztő vagyok, de Oracle-vel eddig nem találkoztam.) Nekem az is nagy segítség lenne, ha azt mondanátok, hogy létezik megoldás, mert szerintem nemigen, vagyis eddig nem sikerült rájönnöm, hogy hogyan lehetne a böngészőt rávenni arra, hogy egy lekérdezés állapotát megjelenítse. Köszönöm a válaszotok!
Szia, 1.pontosan erre gondoltam. De ezt az xml-t, vagy bár mi mást objektumot beletehetnéd egyetlen mezőbe. De az erre a mező-re írt funkcióidat akkor se tudod, egy az egyben beilleszteni az sql lekérdezőidbe, anélkül, hogy valami sebesség problémáról nem beszélnél. Sikeres objektum kezelő DB ma még nincs. Ha mégis lenne, szóljatok, mert kipróbálnám. Édesviz
Tárolt eljárásban csak direktbe grantolt objektum hivatkozható, role-on keresztüli nem. A jelenség legalábbis erre utal, hogy "simán" lefut, eljárásból nem.
Szerintem nem annyira tuti... a proci általában nem az aktuális felhasználó, hanem a procedure tulajdonosának jogaival fut; továbbá olyat is hallottam már, hogy role-on keresztül megadott jogok néha 'kevésbé érvényesülnek', mint a direktben megadottak.
Egy olyan problémám lenne, hogy van egy adatbázisom, amihez több felhasználó tartozik, és akikhez több tábla, procedure stb. tartozik...
TOAD-ot használok, és olyan gondom lenne, hogy az egyik felhasználó alatt írtam egy procedure-t amelyik adatokat nyer ki a saját ill. egy másik felhasználó tábláiból, de valamiért nem tud lekérdezést végezni, és az alábbi hiba üzenetet küldi:
PL/SQL: ORA-00942: table or view does not exist
De ha ugyanazt a lekérdezést lefuttatom ugyanazon a felhasználó alól az SQL Editorban, akkor hiba nélkül lefut....
Tehát a jogok tuti grant-olva vannak....
Ha valakinek van valami ötlete, bármi írjon, előre is KÖSZÖNÖM
Az XML eddig még nem említett másik nagy előnye a szintaktikai (file utolsó bitje is megérkezett-e) és némi szemantikai (filekonzisztencia)ellenőrizhetőség (pl.: típusmegfelelés)
1.a kérdezőnk válaszolt, a szétbontás altáblákra tetszett neki.
2.Tranzakcionális kezelés alatt azt értettem, hogy az adathalmaz on-line sokat változik, azaz nem lekérdezésről, hanem konkurrens adat változásokról van szó. Tehát lehet, hogy más eszközzel is meg lehetett volna azt a rendszert írni. Szeretném mindenkinek a figyelmét felhívni, a sima táblázatos modellen kivül, az ORACLE ad hierarchikus hozzáférést, prefix, és postfix fa bejárásra is. Ez pl a DB2 általam használt verzióiból, és a feladatomhoz természetesen hiányzott.
2. az xml adatstrukturáról annyit, hogy egy szószátyár, objektum leíró rendszer. Előnye, hogy rengeteg kész szoftver van a kezelésére, szabványosított adatcserét tesz lehetővé rendszerek, alrendszerek között. Hátránya, hogy lassú, processzor igényes. Amiből pedig a mostani munkámban látszólag elégnek kellen lenni. Tbájt méretü rendszer, 3-5 ezer online felhasználó, nagygépek, közepes szerverek sokasága, intranet alkalmazások. Édesviz
