Bevezető

Egy olyan rendszert szeretnék írni, amely rugalmasságával megalapoz egy új módszertant. Vagyis a rendszer mellé szándékom szerint mellékelnék egy "használati utasítást" is, amely nem pusztán a fejlesztőrendszer használatát segítené elő, hanem egy új módszertan leírása is lenne.

A fejlesztőrendszer különlegessége, hogy a fejlesztőrendszer specifikációja is a rendszeren belül lenne. Éppen ezért nevezzük egyelőre Together-nek vagy magyarul Együttnek.

Alapfogalmak tisztázása

Le kell szögezni, hogy a szakirodalom sem egységes. Pl. az egyed és az egyedhalmaz mást és mást jelent különböző publikációkban. Ezért is írom le, hogy melyik szó alatt mit értek.

Egyed, egyedtípus, entitás

A valóság azon elemei (többesszám), amelyek számunkra értékes információkat hordoznak, egymástól megkülönböztethetőek. Nem konkrét egyedpéldányok halmaza. (Ld. egyedhalmaz definíció lentebb), hanem inkább egy tipust jelöl, egy elvontabb fogalom (mint programozásban az osztály). Én leginkább az egyedtípus megnevezést fogom használni. Pl. "VEVŐK" egyedtípus (csupa nagybetű, többesszám konvenciót vezetem be).

Egyedpéldány, egyed előfordulás

Az egyed egy konkrét értékét egyedpélánynak, egyed előforulásnak nevezzük. Az adatbázis megfelelő táblájában egy rekord reprezentálja. Én leginkább az egyedpéldány megnevezést fogom használni. Pl. "Vevő" egyedpéldány (nagy kezdőbetű, egyesszám konvenciót vezetem be).

Egyedhalmaz, egyedpéldányok listája

Egyedpéldányok konkrét összessége. Az adatbázisban a megfelelő tábla reprezentálja. Én leginkább az egyedhalmaz megnevezést fogom használni, Pl. "Vevők" (nagy kezdőbetű, többesszám konvenciót vezetem be).

Egyedtípus kifejtése

Az egyedtípusokat csak modellezni tudjuk, pontos valójában természetesen nem tudjuk megismerni soha és nem is akarjuk.

Tulajdonság(típus?)ok

Az egyedtípusokról tulajdonság(típus?)okat kísérelünk meg tárolni. Azért írom, hogy kísérelünk, mert ezt sem tudjuk tökéletesen (és nem is akarjuk) megvalósítani. A VEVŐK egyedtípusnak lehet pl. név, cím, elérhetőség tulajdonságai. Kicsit gáz a többesszám - egyesszám ütközés. Lehet, hogy Külön kellene az egyed és egyedtípus fogalmát használni.

Tulajdonság(típus?)ok felbontása

Az adatbázisban nem tudunk nevet, címet, elérhetőséget tárolni. Ezek még mindig túl elvontak ahhoz, hogy közvetlenül tárolni lehessen őket. Ahhoz, hogy ezt feloldjuk, a tulajdonság(típus?)okat még pontosabban kell definiálnunk primitívek segítségével.

Primitívek

A primitívek olyan tulajdonság(típus?)ok, amelyek közvetlenül lefordíthatók az adatbázis nyelvére, vagyis könnyedén bináris kóddá alakíthatóak. Ilyenenk pl. az integer, float, string, stb. Ezek olyan építőkockák, amelyből az összes többi tulajdonság(típus?) is felépül. Pl. a név tulajdonság(típus?) minimum vezetéknévből és keresztnévből épül fel, amelyek stringként tárolódnak az adatbázisban. De egy komoly rendszerben kell tudni tárolni pl. előtagokat (néhai, dr), utótagokat, amelyeket kódtár segítségével valósíthatatunk meg.

Azonosító

Az azonosító többnyire egy string, pl. "VEVŐK", de lehet egy akármilyen más bináris azonosító is, pl. egy interger, bár ez utóbbi nem célszerű, mivel nem beszédes.

Tulajdonságelőfordulások ismétlődése

Ha a tulajdonságelőfordulásokban ismétlődő értékeket találunk, akkor ezeket a tulajdonságelőfordulásokat átvihetjük egy ún. kódtárba. A kódtárban jellemzően minden tulajdonságelődforduláshoz egy intergert rendelhetünk. Így az egyedpéldányhoz már csak a hozzátartozó integer azonosítót rendeljük ezzel tárhelyet spórolunk, ezáltal gyorsabb lesz a rendszer. És nem csak gyorsabb, hanem egyúttal kevesebb hibalehetőség is.Példa: SZÍNEK kódtár: 1 - piros, 2 - fehér, stb.

Tulajdonság előfordulások közötti függőségek

Elődordulhat, hogy ki akarjuk bővíteni egy már meglevő kódtárunkat és egy újabb tulajdonságot akarunk felvenni a meglévőek mellé. Példa: a piros és a sárga vidám színek, a fekete és a barna szinek pedig nem vidámak. Ekkor megtehetjük, hogy a kódtárban helyezzük el a színek vidámságát meghatározó információt.

Súgó Még nincs hozzászólás.

Új hozzászólás Frissítés