Nézzük meg, milye van nagy általánosságban egy adatnak:

•  

Abból indulok ki, hogy mi is az adat. Az adat egy valós objektumról eltárolt információ. Ilyen valós objektum egy rendszerben pl. a vevők, akikkel kapcsolatban állunk. Valós objektum még a termékek, amelyeket árulunk, cégek, akikkel kapcsolatban állunk.

Teljesen nyilvánvaló, hogy csak azokat az adatokat tároljuk el, amelyekre szükségünk van. Általában nem tároljuk el az ügyfelek szeme színét, de pl. egy bűnügyi nyilvántartásban ez egy fontos adat lehet. Felmerül a kérdés, hogy el tudjuk-e tárolni az ügyfelek szeme színét. Nem tudjuk, mivel a szem egy nagyon bonyolult szerv. A szem színt legjobban egy szemgolyórol készült fényképpel tudjuk leírni, vagy inkább a szemről készült videofelvétellel. De még ez sem tökéletes. Ezek is csak modellek a szemről. Összefoglalva, ha szemszint tarolunk, akkor egy kódot tárolunk, amely kód mögött az áll, hogy "barna" vagy "kék", amely végül bekerül kódtarba és valójában azt tároljuk le, hogy 1 vagy 2.

Alap adattipusok. Itt kell megemlíteni az unásig ismételt primitiveket, mint integer, string, float, stb. Ezeken alapul minden kodtar. A kodtarnak van legtöbbször egy integer azonosítója, es egy string, amelyben eltaroljuk magat az értéket, pl. "barna". Az efféle kodtar lényegében egy származtatott adattipus, amely rendkívül gyakran használatos. A primitívek és a kodtarak nem részei az objektumoknak. Esetleg valamiképpen lenyomatai azoknak, tükrözik az összeséget.

Tehát vannak akkor létezőinknek különböző halmazai a valós világbol. Vevők, termékek, cégek. Ezeket csak modellezni lehet, valós adatokat nem tudunk tarolni. Egy ilyen halmaznak van egy neve. De akár lehet több neve is. De nem csak neve lehet, akár egy piktogrammal is lehet azonosítani, vagy bármilyen bináris adat lehet azonosító. Nevezzük őket így: "VEVŐK". Ez az azonosítója ennek a halmaznak a rendszerünkben. Ezekhez a létező típusokhoz különböző tulajdonság típusokat lehet felvenni. Pl. név, telefonszám, cím.

Ezeknek a létezőhalmazoknak egy-egy elemét nevezzük "VEVŐ"-nek. És végül a vevőnek lehetnek csak név, cím, telefonszám tulajdonságai. Vegyük pl. a cím tulajdonságot. Ez lehet egy db string, de tetszőlegesen lehet variálni. Felépülhet pl. Irányítószám, település, utca, házszám szerint. De bele lehet venni a lépcsőház, emelet, ajtót is. Ezek felbontasok gyakoriak.

Vagyis egy tulajdonságok állhatnak hierarchiában is. Egy tulajdonságnak lehet a szülője egy tulajdonság is, nemcsak egy modellezni kívánt létező. Van itt még valami. A tulajdonság típusa. Ugyebár ez lehet egy primitív is, de lehet egy kodtar is, stb. Azok a tulajdonságok, amelyeknek altulajdonsagai vannak a típusa megegyezik az altulajdonsagok halmazaval, vagyis nem lehet külön típust megadni.

Tulajdonságok közötti függőségek tárolására is kell gondolnunk. Ennek alap megvalósítása a kodtar. Ahol egy integer típushoz rendelünk egy stringet. De miert ne rendelhetnenk meg valamit es még mást is. Mondjuk színeket kodtarazunk és még mellé teszünk egy booloean-t, hogy ez egy vidám szín vagy sem. A kodtarak kibovitesenek csak a fantázia és a user igenyek szabnak határt. Természetesen ebben az esetben is a kód bármilyen bináris érték lehet, ami barmit reprezentálhat.

Ahogy növekszik az adatbázisunk felmerül a kérdés. Mi a fontosabb: az adatbázis tömörsége, hogy kis helyen is elférjen, vagy a hatékony, gyors keresés, lekérdezés, karbantartás. A válasz persze az, hogy mindkettő (vagy mindhárom) fontos. A kecske is jóllakjon és a kápszta is megmaradjon. Ezt persze tökéletesen megvalósítani lehetetlen.

Visszatérve az összefüggésekre az objektumok közötti összefüggésekre is kell gondolnunk. A tulajdonság közötti összefüggésekre ott van a kódtár. Az objektumok közötti összefüggésekre pedig ott van a kapcsolótábla.

A kapcsolótábla 2 objektum közötti összefüggést írja le vagyis kapcsolja őket össze. Legtöbbször az adatbáziskezelésben csak 2 oszlopból áll és gyakran használják több-több kapcsolatra is. De a mi esetünkben a kapcsoló tábla csak valaminek a kezdete. Ezeket a táblákat ki kell bővíteni pl. rendelésszámmal vagy fizetés módjával, fizetési határidővel, vagy rendelés stáuszával. Egy ilyen táblát el lehet nevezni pl. "Rendelések"-nek. Egy ilyen tábla is több-több kapcsolatot jelent, hiszen ugyanaz a vevő több terméket is vásárolhat és ugyanazt a terméket több vevő is megvásárolhatja. Viszont ez a kapcsolótábla még ki van bővítve egy csomó más egyéb tulajdonsággal.

---

... ha egy kódtablaban egy bizonyos adat fele nem meghatározott. Ha ez több tulajdonságra vonatkozik, akkor, és van is benne rendszer, akkor megfontolandó újabb tábla létrehozása, amelyben az értelmezett objektumok azonosítói jelennek meg.

Egy-egy entitás egy menüpontot reprezentál az alkalmazásban. Pl. Vevők.

Akkor mit reprezentál az alkalmazás maga? Nyilvánvalóan az entitások hierarchiáját. Vagyis az alkamazás építése ezzel a hierarchiával kezdődik.

Egy-egy entitás egy menüpontot reprezentál az alkalmazásban. Pl. Vevők.

Akkor mit reprezentál az alkalmazás maga? Nyilvánvalóan az entitások hierarchiáját. Vagyis az alkamazás építése ezzel a hierarchiával kezdődik, hogy az entitások hieraarchiáját felépítem.

Vannak származtatott entitások is, amelyek egy-egy kapcsolótáblán alapulnak. Pl. Vevők - Termékek entitásokból létre lehet hozni a Rendelések származtatott entitást. A kapcsoló tábla tovább bővül és ezáltal lesz belőle származtatott entitás, mivel önmagában egy