Az adatokat általában a programozáshoz társítják, és a modern információs világban három logikailag egyenértékű változatban jelennek meg: a programban leírt és felhasznált adatok egy programozási nyelven; adatok adatbázis-rendszerekben; adatok az elosztott információs rendszerekben. A modern programozás csak az információ formalizálásának első változatának adott viszonylagos szabadságot. A második két lehetőség többé-kevésbé megbízható formája az információszolgáltatásnak és az összetevői közötti kapcsolatoknak.
Múltbeli és jelenbeli adatok
A programozási nyelvek alapvető pozíciója az adatok és algoritmusok pontos leírása. A számítógépek nem „mutatnak” semmilyen esélyt a bizonytalanságra: van valami, amire cselekedni kell, és van egy parancs, amely végrehajtja ezt a műveletet.
A modern koncepció sokkal magasabb alapokon nyugszik: van adott, és az, hogy pontosan mi lesz, a felhasználás helyén dől el. Mindenesetre a felhasználáskor az adatok automatikusan ellenőrzésre kerülnek és a megfelelő típusra konvertálódnak. Egy modern programozó nem köteles gondoskodni azok előzetes leírásáról és a típuskompatibilitás betartásáról az algoritmusban.
Átállási folyamat:
- a gépelt adatokból és használat előtti kötelező leírásából;
- a gépelés nélküli adatokhoz, valamint a leírásuk és felhasználásuk kötelezettségének mentessége.
Valójában a formalizálási követelmények viszonylagos enyhülését ismerhetjük fel – ez csak a modern programozási eszközök környezetében érhető el. Futás közben minden nullapont típusa rögzített, a parancssor pedig jól meghatározott.
Típusok és modellezés
A matematika és fizika, a kereskedelem és a termelés, a közgazdaságtan és egyéb számokat használó területek mindig is adatokkal operáltak, és nem tulajdonítottak semmilyen jelentőséget a típus fogalmának. Az a tény, hogy a számok lehetnek egészek vagy törtek, nem igazán számított.
Minden egyes képlet vagy konkrét művelet adhat egész számot, végtelen törtszámot, valós vagy komplex számot. Mostanáig léteznek az elme olyan csodái, mint a végtelenül kicsi és a végtelenül nagy. Sőt, ezeknek a csodáknak még tulajdonságaik is vannak.
Még mindig nincs szabadság a programozásban. Mindent szigorúan formalizálni kell. Az adat fogalma mindenekelőtt egy típus:
- integer;
- boolean;
- char;
- karakterlánc és így tovább.
A típusnevek eltérhetnek a különböző programozási nyelvekben, de mindig van egész vagy valós szám, logikai érték, szimbólum,vonal. Maradtak még emlékek és konkrét ötletek: előjel nélküli egész szám, kód, bájt, szó, dupla szó, rögzített hosszúságú karakterlánc.
Az adatok fogalmának egy adatrendszerben nincs szabadsága. Az SQL - "nemzetközi" (minden modern adatbázishoz van dialektus) - nem csak az adatokban, de az sql lekérdezésekben sem tűri el a pontatlanságokat. A kérelem hibája garancia az eredmény hiányára. Egyáltalán nem kell a leírások megsértéséről beszélni.
Az információs folyamatok és adatábrázolások modellezése az egyetlen biztos módja egy olyan struktúra felépítésének, amely fejlődhet és alkalmazkodhat a változó körülményekhez.
Az eredeti dinamikája
A természetes információ folyamatos változás. Az adatmodell formális leírása és koncepciója egy adott témakörben három probléma megoldását jelenti:
- határozza meg, hogy milyen adatok legyenek itt;
- formalizálja a köztük lévő kapcsolatot;
- leírja az adatok és kapcsolatok megváltoztatásának folyamatait.
Példa egy egyszerű JavaScript-algoritmus adathalmazára – még a legszilárdabb adatbázis-kezelő rendszer modelljének kicsinyített másolata is.
Csak arról van szó, hogy a második esetben a szakértők és a szakemberek az adatstruktúrák, táblák, kapcsolatok tervezése során általában nem látják (nagy mennyiségű természetes információ lefedése valóban nehéz) a dolgok lényegét, ill. nehézkes, fejletlen adathalmazt nyerünk, miközben a tárgykörben a forrásinformáció szabadon és könnyen kering.
Statikuslehetséges
Általános JavaScript-gyakorlat, hogy egy oldalhoz csatolt kódot és az eseményekhez rendelt funkciókat helyeznek el az oldalcímkéken. Akárhogy is, az oldalcímkék meghatározzák azokat az adatokat, amelyeket egy adott webes erőforrás elfogad, módosít vagy létrehoz.
Ha a kezelőkódot nagyon óvatosan az elemeseményekre koncentrálja, nem pedig az oldal kódjának egészére, ez a legjobb kiút. Ideális esetben, ha a kód nem vezet be új adatokat, vagy nem javítja a rendelkezésre álló adatokat, hanem arra fókuszál, hogy egy adott pillanatban pontosan mit tartalmaz.
Valójában, ha az "adat" fogalmát a forrásinformáció minimálisan statikus leírásaként határozza meg, és követi azt, akkor ez azt jelenti, hogy esélye van a sikerre.
Az adatbázisokkal kapcsolatban a dolgok sokkal bonyolultabbak. Bármilyen JavaScript kód funkcióval látja el az old alt. Bármely adatbázis táblák, köztük lévő kapcsolatok, tárolt eljárások, lekérdezések és kívülről elérhető funkciók gyűjteménye.
A statikus minden algoritmus problémája. Az adatok modern fogalma statikus: egy szám, egy karakterlánc, egy karakter stb. Feldolgozáskor vagy adatbázistáblába íráskor minden gördülékenyen megy. De mikor kap az eredeti más dimenziót vagy jelentést? Első lehetőség: változtassa meg a jelet, de a kapcsolatok és a kérések azonnal bedőlhetnek.
Statika és objektumok
Az „adat” fogalmának objektumként való meghatározása drámaian megváltoztatja a helyzetet. Az objektumnak saját szerkezete van. Itt bármilyen változó leírását használhatja. A szerep nem fog játszani. Egy objektumnak vannak olyan metódusai, amelyeken keresztül az adatok elérhetők. Mivel mindenprogramozás területén használatos, vagyis három alapvető módszer: olvasás, írás, változtatás. Többet is hozzáadhat összehasonlításhoz, kereséshez, klónozáshoz stb.
A tárgyterület egy sor tulajdonságot ír elő minden egyes adathoz. Így kiderül, hogy az adatok fogalma egyfajta leírássá alakul, amely dinamikusan változtatható. Az objektumon belüli statikus dinamikát ad az objektumon kívül.
Ha megváltoztatja a statikus leírók kombinációját egy objektumon belül, akkor nem kell aggódnia a többi objektumhoz fűződő kapcsolatának dinamikája miatt.
Adatok programozása és megjelenítése
Mi az adat? A köztudat már megszokta az információs technológiát, a felhőkben dolgozik, és virtuális terekben konténerekkel rendelkezik. Ma már nemcsak a professzionális programozók és felhasználók, hanem a hétköznapi emberek is kompetensek az információk és azok felhasználása terén.
De mi is az a programozás? A közvélemény a mai napig a következő meghatározást adja erre a fogalomra és annak fogalmaira:
- Az információ és az adatok az informatika alapfogalmai.
- Az adatok egy bizonyos módon vettek és rögzítettek a környező valósághoz viszonyított megfigyelések.
- Egyszerűek és összetettek (struktúrák), elsődlegesek és másodlagosak.
- Az adatbázis független anyagok gyűjteménye, amelyeket szisztematikusan bemutatnak, hogy megtalálhatók, módosíthatók és felhasználhatók legyenek.
Mennyire objektív ez? Mérvadó szerzőkgondolom. A valódi gyakorlat arra törekszik, hogy minden tantárgy meghatározza a megfelelő adatrendszerét, és minden lehetőséget megadjon egy jó dinamikus modell felépítésére.
Nem ritka, hogy a vásárló (fogyasztó) ráerőlteti saját véleményét egy programozóra (adatbázis-tervezőre) arról, hogyan és mit tegyen. A programozás szempontjából a vevő bármely vágya a legnagyobb precizitással teljesíthető.
Szükség van az Oracle-re, hogy megoldja a vidéki vízellátás fenntartásának költségvetési problémáját (21. épület a faluban) - jó. A MySQL-re van szükség a postai küldemények nyomkövető rendszerének megszervezéséhez Oroszország összes postahivatalában – minden működni fog.
Bármilyen algoritmust állíthat össze, és hozzáférést biztosíthat az információ bármilyen megjelenítéséhez az adatfogalom definícióján belül, amelyet az adatbázis-kezelő rendszer vagy programozási nyelv fejlesztője határoz meg. A kérdés más: hogyan lehet ezt minimális költséggel, maximális dinamikában csinálni?
Adatbázisok, példák
Egy egyszerű alapot modell nélkül készítenek. Az adatok és a kommunikáció alapfogalmai kicsik, a funkcionalitás nagyon egyszerű. Például egy felsőoktatási intézményhez szüksége van:
- tanárok asztala;
- csoporttábla (kulcs és csoportszám);
- általános tanulói táblázat (a csoportkulcsokat használjuk).
A dékán tudni akarja a tanárok haladását. A tanári táblázat a következő mezőket tartalmazza:
- vezetéknév;
- név;
- patronymic;
- felügyelt csoport száma.
A tanulótáblán a következő mezők találhatók:
- vezetéknév;
- név;
- patronymic;
- születési dátum;
- GPA (minden tantárgyhoz);
- csoportszám.
Legalább két lehetőség lehet a mintavételre: a tanár nevével a csoportszámra lépve megnézheti az összes tanulót és átlagpontjaikat, vagy a tanár vezetékneve és az utolsó a tanuló nevét, láthatja az utolsó átlagos pontszámát.
Még egy ilyen egyszerű verzióban is garantált a probléma, és valamit változtatni kell. Helyzet: a tanár megbetegedett, újabb hónap helyettesíti, vagyis két csoportot irányít. A tanári táblázatban egy csoportszám alatt csak egy mező található.
A probléma megoldásához egy ismétlődő mezőt kell hozzáadnia. És ha ketten megbetegednek, adjunk hozzá három mezőt. Tehát a tanárok asztala a nulláról kezd növekedni.
Van egy másik lehetőség: cserélje ki a csoportkulcs numerikus mezőjét egy szimbolikusra. Ezután minden alkalommal, amikor kiválasztja, a karakterláncot kulcssorozattá kell konvertálnia, és egy sql lekérdezésből több lesz.
Egy ígéretesebb példa nem a táblázatok, hanem az objektumok készítése. Ekkor a tanár egy tárgy, és több felügyelt csoportja is lehet. De ez mindig egy tárgy. A tanár objektum egyedi kulccsal rendelkezik, de több felügyelt csoporttal is rendelkezhet. A csoportnak egyedi kulcsa is van. Egy diák is.
Mindhárom pozíció nem csak a feladaton belül elérhető, hanem tovább fejleszthető.
Objektumorientált alapok
Az információs iparág vezetőiklasszikus relációs adatbázisokat kínálnak. Az élet próbára tette őket, működnek, biztonságosak, megbízhatóak, és probléma esetén lehetővé teszik az információk visszaállítását.
Az objektumorientált adatbázisokat (OODB) az 1980-as évek közepén kezdték fejleszteni, és hiteles szerzők szerint a mai napig ígéretesek. De ez idáig, az alapvető elméletektől és a koncepcionális rendelkezésektől eltekintve, nincs olyan OODB, amely ugyanazt a minősítést és elosztást érte volna el, mint a MySQL, az MS SQL Server vagy az Oracle, annak minden változatos inkarnációjában.
De mi van akkor, ha a definíciót, az adatok, típusok, attribútumok, osztályok és hierarchiák fogalmát egy olyan fejlesztő javasolja, akinek a minősítése nem elegendő egy olyan programozói közösség létrehozásához, akik ennek az OODB-nek a mentalitását vallják? A saját erőnkre kell hagyatkoznunk.
Az OODB-nek több mint harminc változata készült Linux környezetben. De hol a garancia arra, hogy a létrehozott adatbázis nem igényel több funkcionalitást? A Windows környezet nem nyújt sok garanciát ezen a területen.
Objektumorientált megoldás
Azonban van megoldás. A MySQL példaként való felhasználásával megmutathatja, hogy a szabványos relációs táblák hogyan válnak a megoldandó probléma objektum-orientált modelljévé.
Itt nincs adatbázis, de van egy környezet a saját objektumrendszer kialakításához. A MySQL erejét csak relációs memóriaként használják az információs sorokból származó táblákhoz. A felhasználás logikáját maga a fejlesztő határozza meg. Különösen van egy is_cache tábla. Mindene megvantöbb alapvető mező:
- tulajdonosi_kód;
- session_code;
- h_code;
- a_surprise;
- a_contents.
A többi mező szervizfunkciókat tartalmaz. Ez a táblázat bármely kérés bemeneténél áll, és rögzíti annak érkezését. Hogy az adatbázis-modell mit fog kidolgozni, azt a fejlesztője határozza meg. Azt, hogy mi fog beleférni a tartalommezőbe (a_contents), a fejlesztő által létrehozott modell objektumai határozzák meg.
Négy dolog van ebben az ötletben: találat, találati munkamenet, lekérési előzménykód és konkrét tartalom. Mi a hívás, milyen objektumrendszert kell építeni - a fejlesztő határozza meg. A munkamenet (munkafolyamat) alatt a fejlesztő határozza meg. Az előzménykód a kérések visszaállításának lehetősége.
Az itt található táblázatoknak semmi közük a tárgykörhöz. Van hívásvezérlő (is_cache), van naplózás (is_customs), van híváslista (is_histories). A többi táblázatot a megoldandó feladat határozza meg.
Valójában ez a megoldás saját OODB létrehozását javasolja a beépített tartományi adatbázismodell és a megoldandó probléma alapján. Van itt egy hatalmas plusz - ez az Ön saját adatfogalma, a bemutatásuk saját modellje és a köztük lévő kapcsolat. Van itt egy alap – egy nagyszerű relációs adatbázis. Nem lesz probléma keresni és félreérteni valamit.
Modell: objektumrendszer + DBMS
Az információtechnológiában szinte lehetetlen bármit megváltoztatni. Az igazi információs forradalom még messze van. szakmai tudata szoftverfejlesztők nem fogják megváltoztatni a klasszikus hagyományokat. De még mindig van kiút a helyzetből.
Ha megbízható modern adatbázis-kezelő rendszereket használ a saját modellje létezésének környezetének megteremtéséhez, akkor észrevehető sikereket érhet el.
A feladat megoldásához mindenesetre nézetet vagy adatmodellt kell készíteni, de ezt helyesen kell csinálni: legyen objektumrendszer, a környezete pedig egy jó DBMS.
