Esettanulmány: Autókereskedés adatbázisának megtervezése. A feladat elemzése (levezetve egy magasabb rendű fejlesztési

Adatbázis-kezelés, Adatbázis tervezése

Esettanulmány

Esettanulmány: Autókereskedés adatbázisának megtervezése Példafeladatunk megoldását a korábban meghatározott adatbázis-tervezési folyamatunk alapján készítjük el.

A feladat elemzése (levezetve egy magasabb rendű fejlesztési feladatból) A kereskedés használt autók forgalmazásával foglalkozik. Az értékesítés során • biztosítani kell a vevők számára a választást lehetővé tevő műszaki és árinformációkat, • ki kell elégíteni az adásvételi bizonylatok (szerződések, számlák) adatigényét, • lehetővé kell tenni a vevő későbbi elérését (értesítések), • támogatni kell az értékesítők érdekeltségi rendszerét. Mindezek megoldására a kereskedés egy számítógépes rendszert kíván létrehozni, amely az értékesítési adatbázisra támaszkodó, különböző célú szoftverek együtteséből áll. Pontosítsuk, rendszerezzük a feladatspecifikációt! A teljes rendszer az alábbi alrendszerekből (szolgáltatásmodulokból) áll majd: • Értékesítési alrendszer o műszaki információk biztosítása: márka, típus, szín, évjárat, hengerűrtartalom, üzemmód o árinformációk biztosítása: irányár o szerződéskötés és számlázás • Kapcsolattartási alrendszer o értesítések, felhívások készítése a vevők számára • Teljesítménykimutatási alrendszer o Az értékesítők teljesítményének kimutatása • Adatkezelési alrendszer o A többi alrendszer adatigényeinek kiszolgálása Az elemzési és tervezési szakaszokban – gondolkodásunk segítése érdekében – az eredményeket sokszor érdemes jól áttekinthető, a lényeget bemutató modellábrákon is rögzíteni, bemutatni.

Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

1


Esettanulmány

Az Autókereskedés rendszere

1. ábra A teljes rendszer és alrendszerei

A minket érintő részfeladat: az Adatkezelési alrendszer kidolgozása. A rendszerszempontú megközelítés igen hasznos a műszaki-gazdasági rendszerek modellezésénél. Esetünkben az Autókereskedési rendszer feladatokat lát el. Feladatait négy alrendszerbe szerveztük. Ez a megoldás – több más ok mellett – hatékonyan támogatja a teljes feladat áttekinthető, önállóan megoldható részfeladatokra való bontását. Az alrendszerek működése egymástól funkcionálisan független (nem „vesznek kölcsön” műveleteket egymástól), a kapcsolat köztük közvetett, és az adatok előállítása-felhasználása területére korlátozódik. Az adatok általános kezelését érdemes egy önálló alrendszerre, az adatbázist és adatbázis-kezelőt tartalmazó alrendszerre bízni, a többi alrendszer ezzel kommunikál, ha adattárolási-adatkérési feladat áll elő. A rendszerben, illetve alrendszereiben folyamatok zajlanak, események történnek, és ezekkel kapcsolatban adatok keletkeznek. A keletkezett adatok hosszú távú tárolása, illetve az egyik alrendszerben keletkezett adat másikban történő felhasználásának biztosítása az Adatkezelési alrendszer feladata. Az Adatkezelési alrendszernek nem feladata az adatok szakterületi önálló feldolgozása (pl. számla előállítása stb.), csak olyan műveleteket végez, amelyek az adatok megfelelő tárolásával kapcsolatosak, illetve az adatok mindentől független, egymás közti összefüggéseiből erednek.


2


Esettanulmány

A megoldás terve Mielőtt belekezdenénk a feladat megoldásába, előre bocsátjuk: el fogunk követni, illetve figyelmen kívül fogunk hagyni bizonyos pontatlanságokat; úgy is fogalmazhatunk, hogy az adattervezést ebben az esettanulmányban kicsit „lazábban” fogjuk fel, és a fogalmak, illetve modellek és ezek elemeinek meghatározásánál, használatánál nem törekszünk az abszolút korrektségre. Ennek oka az, hogy jelen pillanatban fontosabbnak tartjuk, hogy az olvasó az alapvető szemléletmódot és eszközöket megértse és elsajátítsa, mint azt, hogy a létrehozott eredmény minden részletében tökéletesen megfeleljen a legszigorúbb szakmai követelményeknek. A tanulmány végén azonban – amikor a tanuló már átlátja az egészet – vissza fogunk térni erre a kérdésre, és felhívjuk a figyelmet olyan részletekre, amelyekről majd a későbbiekben nem szabad megfeledkezni. Lássuk tehát a megoldást! Az Adatkezelési alrendszer biztosítja a többi alrendszer számára az adatbázist, tehát ennek megtervezését kell most elvégeznünk. Első lépésként megpróbáljuk azonosítani azokat az objektumokat, amelyek a teljes Autókereskedési rendszerre jellemzőek, és amelyekről az egyes alrendszerek feladatainak ellátásához adatokat kell tárolni.

Egyedek meghatározása A feladatleírásban követelményként megjelentek adatok: például, hogy a vevők autókat vesznek, melyekkel kapcsolatban bizonyos adatok (márka, szín, ár stb.) érdeklik őket. Mind az adatok, mind a teljes rendszer céljának vizsgálatából elég egyértelműnek tűnik, hogy az Autó objektum része a rendszernek. Milyen más objektumokat találunk még? A vevők nem csak megveszik az autókat, hanem aktív ügyfelei is maradnak a kereskedésnek, pl. később leveleznek velük. A Vevő szintén a rendszer része. Ugyanígy része az Értékesítő is, mivel teljesítményét a rendszer által szolgáltatott adatok alapján egy másik alrendszer értékelni fogja. Nagyítsuk most ki a minket érintő Adatkezelési alrendszert, és helyezzük el benne eddigi eredményeinket!


3


Esettanulmány

2. ábra Az Adatkezelési alrendszer és összetevői

Mint látható, más (adatközlő és adatkérő) alrendszerek az Adatkezelési alrendszerrel az adatbázis-kezelő alkalmazáson keresztül kommunikálnak, maga az adatbázis alrendszerünk „belügye”, mások számára közvetlenül nem hozzáférhető. Az adatbázis-kezelő program később majd választható lesz (pl. lehet majd Access), az adatbázis-tervezési feladatunknak most nem része; ezért a továbbiakban az adatbázisrészre koncentrálunk.

Kapcsolatok meghatározása Vajon azonosítottunk-e minden egyedet, amit az adatbázisban szerepeltetnünk kell majd? Ehhez vizsgáljuk meg a köztük levő lehetséges, rendszerünk szempontjából értelmes kapcsolataikat! Vevő–Autó A kapcsolat nyilvánvaló, a Vevő megvásárolja az Autót. Vehet többet is? Persze. Egy autó lehet több vevőé? Nem. A kapcsolat tehát egy-több típusú, Vevő -> Autó irányú. Vevő–Értékesítő A Vevő kapcsolatba kerül az Értékesítővel: megkeresi, beszél vele, megegyeznek, együtt lebonyolítják a vételt – mondhatnánk. De vigyázzunk! Az Autókereskedés rendszerét készítjük, nem az IWIW-et! A kereskedés szempontjából a vevő–


4


Esettanulmány

értékesítő kapcsolata közömbös, nem érdekes, hogy melyik vevőnek melyik eladó adta el az autót. Ezt a kapcsolatot tehát figyelmen kívül hagyjuk. Különösen kezdő rendszertervezőknek jelent gondot a releváns-irreleváns kapcsolatok megkülönböztetése. A hibásan vagy feleslegesen definiált kapcsolatok a rendszerben később felesleges adatok és műveletek tárolását jelenthetik, ami az adatbázis használhatóságát drasztikusan rontja.

Értékesítő–Autó Első látásra egyszerű: Az értékesítő eladja az autót. Minél több autót ad el, annál jobb lesz a teljesítménye, és ezt egy másik alrendszer mérni is fogja. A kapcsolat tehát fontos a szempontunkból. Könnyen beláthatjuk, hogy ez is egy–több kapcsolat, Értékesítő -> Autó iránnyal. Ábrázoljuk eredményeinket!

3. ábra Egyedek és kapcsolatok

Készen vagyunk az egyedek és kapcsolatok elemzésével? Sajnos nem. Bár úgy tűnik, hogy ezt a részt megoldottuk, de az eredményeket már ebben a szakaszban – gondolatban – ellenőrizni kell. Gondolkodjunk kicsit „tágabban” a feladatról: Az adatbázisban az autók nyilvántartása tulajdonképpen a kereskedés készletét jelenti. A készlet pedig változik, hisz épp erről szól a kereskedés. Mi történik, amikor egy autót eladnak? Kikerül a készletből, vagyis az autó nyilvántartásból. De az eladáskor vevő is, értékesítő is kapcsolódott hozzá, mi lesz ezekkel a kapcsolatokkal, ha az autó (a kapcsolat egyik vége) „eltűnik”? Nézhetjük a problémát más oldalról is. Tegyük fel, hogy egy értékesítő eladott autókat, majd kilép a cégtől, tehát „megszűnik”. Akkor most azokat az autókat mégsem adta el senki? Hiszen a kapcsolat egyik vége megint megszűnt…. Az is lehet, hogy egy vevő – pl. fizetésképtelenség miatt – visszahozza az autót. Akkor ezt az autót mégsem vette meg senki? Úgy értékeljük majd az értékesítőt, hogy nem csinált semmit? Láthatjuk, hogy modellünk számos problémát vet fel, illetve okoz, tehát nem jó! Tovább kell gondolkozni, elemezni. A legegyszerűbb, ha abból indulunk ki, hogy az előbb felvetett gondok mikor nem jelentkeznének? Vagy miből fakadnak? Bármelyik problémát nézzük, abban szerepel az autó. Lehet, hogy ő a gondok szülője? Bizony ő, éspedig azért, mert rosszul értékeltük szerepét a rendszerben, olyan központi szerepet tulajdonítottunk neki, amellyel a valóságban nem rendelkezik. Vagy tényleg azt hisszük, hogy az Autókereskedés életében az autó a legfontosabb? Ugyan, dehogy! A kereskedés számára nem az autó a fontos, hanem az eladása! Elfelejtettük elemezni, de legalább figyelembe venni a kereskedésben zajló folyamatokat és azok célját. Az Eladás pedig éppen hogy a legfontosabb folyamat, melynek eredményét nevezzük így: Értékesítés. Nem Vásárlás, hanem Értékesítés. Miért? Mert az Autókereskedés, és nem a Vevő számára készítünk rendszert, a rendszer elemeit pedig ebből a szempontból kell értékelni. Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

5


Esettanulmány

Ha jobban belegondolunk, van még egy pár esemény, objektum, ami szintén az Értékesítéshez köthető, például: szerződés, számla. Az Értékesítésre jellemző adatokat is tudunk mondani: ki a vevő, ki az értékesítő, mikor történt meg, mennyi volt a vételár. Módosítsuk hát első modellünket ennek megfelelően!

4. ábra A módosított modell

És valóban: hirtelen minden a helyére kerül: A vevőt és az értékesítőt az autókereskedés szempontjából az értékesítés kapcsolja össze. Egy vevő többször is vehet autót, egy értékesítő többször is értékesíthet. Az eladási folyamat értékesítési eseményéhez erre jellemző adatok kapcsolódnak. Egy adott értékesítés és az adott autó kölcsönösen meghatározzák egymást, és nem baj, ha az autó kikerül a készletből, nem volt a kereskedés szempontjából meghatározó kapcsolatfenntartó szerepe (ha az autót kihagynánk a modellből, attól az még működőképes maradna, csak átváltozna „általános értékesítési” modellé). Ez a jelenség egy újabb érdekes gondolatmenetet vet fel, melyről többet olvashat Az általános és a konkrét modellek kapcsolata című anyagban. Igazság szerint nem voltunk elég pontosak sem az előző, sem a mostani modell kialakításánál: a valóságban az autó eladáskor nem „tűnik el”, csak átkerül a készletből az értékesített termékek közé, így az adatbázisban bent marad. Ennek a „hanyagságnak” az az oka, hogy példánkban nem akartuk felvállalni a tényleges, teljes autókereskedési feladatot, túl nagy és bonyolult lenne, miközben semmi újabb ismeretet nem nyújtana.

Folytassuk a tervezést a következő lépéssel, vagyis töltsük fel az egyedeket tulajdonságokkal, majd különítsük el az azonosítókat!

Tulajdonságok meghatározása Vegyük sorra a feladatspecifikációban már megemlített adatokat, tegyük hozzá a szerintünk még szükségeseket és bővítsük a modellt! Mielőtt tovább mennénk, egyezzünk meg abban, hogy mit, mivel jelölünk majd a modell-ábrákon! Egyedek: két részre osztott téglalapok; a felső részben az egyed megnevezése, az alsóban a tulajdonságai szerepelnek. Azonosítók (kulcsok): aláhúzással jelöltek. Idegen kulcsok: dőlt.


6


Esettanulmány

5. ábra Tulajdonságokkal bővített modell

Megjegyzések az egyes tulajdonságokhoz: Vevőazonosító bevezetése: A vevőkről nem tarthatunk nyilván máshonnan származó egyedi azonosítót (pl. személyi szám), így be kell vezetni egy saját készítésű, cégen belüli kódot (a név „jellegű” tulajdonságokról pedig már tudjuk, hogy nem alkalmasak korrekt azonosításra). Értékesítés sorszáma: Egy értékesítés elvileg egyedileg azonosítható lenne pl. a Vevő azonosító + Rendszám összetett azonosítóval. Ez elméletileg teljesen megfelelő, de például egy későbbi rendszámcsere felborítaná ezt. Igazából nem is tudunk ésszerű összetételű/méretű, stabil kulcsot készíteni a már létező tulajdonságokból, ezért bevezetünk egy saját, egyszerű azonosítót. Ha egy autót csak egyszer, egy vevőnek adnának el, akkor az Értékesítésben szereplő Rendszám önmagában is elegendő lenne, a vevő azonosítója nélkül – de használtautó-kereskedésről lévén szó, előfordulhat, hogy valaki itt vesz autót, majd ide is adja el később – más vevő pedig újra megveszi.

Értékesítőazonosító: használatának oka hasonló a Vevőazonosítóéhoz. További észrevételek: Figyeljük meg, hogy a modell lehetővé teszi az autó irányárának és eladási árának megkülönböztetését, ami egyrészt megóv minket a kényszerű adatmódosítástól (alku esetén ármódosítás az autónál), és sokkal rugalmasabbá teszi az értékesítést.

Megszorítások A megszorítások az egyes tulajdonságokra vonatkoznak, és megadják azok • tartalmára, • kötelező megadására, • érték minimum-maximumra, -tartományra, Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

7


Esettanulmány

• érték képzésére vagy ellenőrzésére, • stb. vonatkozó előírásokat. A Vevő tulajdonságaira vonatkozó adattípusok és megszorítások:

6. ábra Vevőtulajdonságok megszorításai

Vevőazonosító képzési szabálya: szigorúan monoton növekvő.

Az Értékesítésre vonatkozó megszorítások:

7. ábra Értékesítés tulajdonságainak megszorításai

Értékesítés azonosító képzési szabálya: szigorúan monoton növekvő


8


Esettanulmány

Az Autó tulajdonságaira vonatkozó megszorítások:

8. ábra Autó tulajdonságok megszorításai

Rendszám-azonosító ellenőrzési szabályai: 1. Első 3 karakter: angol ábécé betűi Negyedik karakter: Utolsó 3 karakter: szám, 0-9 2. Első karakter: angol ábécé betűi Második karakter: Utolsó 5 karakter: szám, 0-9 Még csak jelezzük: Az Autó egyedre – a korábban jelzett pontatlanságok magyarázatával kapcsolatban – még visszatérünk!


9


Esettanulmány

Kapcsolatokra vonatkozó megszorítások Az egyedek közötti kapcsolatok lehetnek állandóak, kötelező jellegűek, vagy csak alkalmiak. Természetesen mindegyik esetben gondoskodnunk kell a kapcsolat realizálhatóságáról a kulcs–idegen kulcs párok kialakításával. Kötelező jellegű kapcsolat akkor fordul elő, amikor egy egyed léte értelmetlenné válik a másik egyed nélkül, például: • számla és tételei, • megrendelő és megrendelései, • épület és helyiségei, és még sorolhatnánk. Az ilyen szoros (általában egy–egy vagy egy–több) kapcsolatok esetén megszabhatjuk például, hogy a fölérendelt egyed adatbázisból való törlésekor az alárendelt egyed minden ide tartozó előfordulását is törölni kell. Ilyen kapcsolat esetén egy alárendelt egyed létrehozásakor, idegen kulcsának automatikus kitöltése is jogos elvárás. Természetesen azt is figyelembe kell venni ilyen szabályok előírásakor, hogy a szabály alkalmazásához a fölérendelt egyednek már léteznie és kijelöltnek kell lennie.

A megoldásterv ellenőrzése Mielőtt belefogunk a terv alapján az adatbázis fizikai megvalósításába, a lehetőségek szerint mindig próbáljuk meg leellenőrizni helyességét. Itt persze csak „gondolatkísérletekről” lehet még csak szó, de a hibák jelentős része ezzel már kiszűrhető. A módszer ugyanaz, mint amit a ténylegesen elkészített adatbázison, adatbáziskezelő programmal alkalmaznánk: teszteseteket készítünk, és végrehajtjuk ezeket, csak most még „fejben”. A tesztesetek a megrendelői elvárásokon alapulnak; ezeket sorra vesszük, és gondolatban megpróbáljuk teljesíteni őket adatbázis-modellünk segítségével. A példa kedvéért egy ilyet most elkészítünk, és ki is próbálunk.

Tesztpélda: Értékesítők teljesítményének értékelése Emlékezzünk vissza, hogy létezik egy olyan alrendszer a fejlesztési célok között, amelynek ez lenne a feladata. Pontosítsuk, mit értünk ez alatt a funkció alatt, majd ellenőrizzük, hogy az adatbázismodellünk képes-e az ehhez szükséges adatok szolgáltatására. A teljesítményértékelés egy adatlap, amely megadott időszakra egyenként felsorolja az értékesítőket, az adott időszakban általuk eladott autók számát és az értékesítés összértékét.


10


Esettanulmány

Készítsük el a kimutatás mintáját!

éééé.hh.nn–éééé.hh.nn időszaki teljesítmény Értékesítő azonosítója

Eladott autók száma

Értékesítés összértéke (Ft)

Kiss Lajos

13

5

14,123,000

Nagy Zoltán

6

7

12,500,000

Kövér Helga

8

3

26,321,000

15

52,944,000

Értékesítő neve

ÖSSZESEN Tegyük magunk elé a modellt is!

A „gondolatkísérlet” lépései: 1. Vizsgáljuk meg, hogy a kimutatásban szereplő adatok honnan származnak, és ha az adatbázisból kellenek, ott megvannak-e? Az Értékesítő neve és azonosítója szerepel az adatbázisban. Az eladott autók száma és az összérték számított (de nem tárolt!) adatok.


11


Esettanulmány

2. A gyűjtések, számítások elvégzéséhez rendelkezésre állnak-e a szükséges adatok? a. Tudjuk-e összegezni értékesítőnként az eladott autók számát? A rendszerben minden értékesítéshez egy értékesítési bejegyzés (Értékesítés egyed előfordulása) tartozik. Ebben szerepel az értékesítő azonosítója és a dátum, tehát egy megadott időszakra és értékesítőre kigyűjthetők az értékesítések. b. Az értékesítés összértéke adott időszakra és adott értékesítőre az eladási ár és a már említett dátum és értékesítő azonosító alapján szintén kiszámítható. 3. Az eredménytáblázat összeállításához fogalmazzuk meg a szükséges lekérdezést. Értékesítők neve szerint növekvő sorrendben, minden értékesítőre a hozzá tartozó: a. név; b. azonosító; c. az értékesítéseket sorba véve, az értékesítések darabszáma és értékesítések összértéke, ahol az értékesítések dátuma beleesik a megadott időszakba; d. Szükséges adathalmazok: Értékesítő egyed előfordulásait tartalmazó Értékesítők tábla) Értékesítés egyed előfordulásait tartalmazó Értékesítések tábla); e. Külső paraméterek: Időszak (dátumintervallum) Sok további teszteset dolgozható ki, ezekből néhány jelen fejezetünk feladatai között megtalálható, gyakorolható. Az adatbázis egy választott adatbázis-kezelővel való tényleges elkészítéséről a következő témakörben lesz szó. Fejezetünk befejező részében visszatérünk a korábban említett „pontatlanságokra, lazaságokra”.


12


Esettanulmány

Felülvizsgálat: pontatlanságok, amelyek később sokba kerülhetnek Autókereskedés modellünk még nincs kész – olyan „csúsztatásokat” tartalmaz, melyek már a megvalósítás, majd üzembe helyezés során kényelmetlenségeket, egy későbbi továbbfejlesztés esetén pedig akár komoly, csak költségesen javítható problémákat okozhatnak. Nézzük például a modellben az általunk definiált Autó egyedet!

9. ábra Az Autó egyed a modellben

Az Autó egyedtípus előfordulásait az adatbázisban egy Autók tábla fogja tárolni, az eddigiekből adódóan a következőképpen: Rendszám Márka

Típus

Szín

Évjárat

Hengerűr Üzemmód Irányár

… ABC-123

Opel

Astra

Fehér

2000

1.5

Benzin

2500000

DEF-456

Suzuki

Swift

Fekete

2000

1.1

Benzin

1000000

GHI-789

Opel

Astra

Kék

2001

1.6

Diesel

3000000

JKL-987

Suzuki

Swift

Fekete

2002

1.1

Benzin

1500000

MNO-654

Suzuki

Ignis

Szürke

2006

1.3

Benzin

2500000

…


13


Esettanulmány

Ha jól megnézzük a táblázat adatait, láthatjuk, hogy egy-egy autóra vonatkozóan egyedi (pirossal keretezett) és kategorizáló adatok keverednek. Hogy pontosan lássuk a problémát, játsszunk el egy autó kiválasztást! Tegyük fel, hogy konkrét elképzeléssel lépünk be az autókereskedésbe, és az alábbi kiválasztási procedúrát csináljuk végig – persze az értékesítő segítségével.

10. ábra Autó kiválasztása vásárlás céljából

Elképzelésünk az volt, hogy kis, fekete, nem túl öreg, benzinüzemű Suzuki Swiftet vegyünk. Az értékesítővel közöltük a feltételeinket, és ezek alapján a teljes autókészletből két példány maradt – ezek közül választottuk ki azt a konkrét autót, amelyet végül megvásárolunk. Figyeljük meg: példánkban az összes feltétel sem volt elég arra, hogy egy bizonyos autó-példányhoz eljussunk – ez pedig azt jelenti, hogy amíg rá nem mutattunk egy rendszámra, nem egy bizonyos autóról, hanem csak egy autó-kategóriáról (amely megfelelt feltételeinknek) beszélhettünk. Mi következik ebből? Az, hogy a Rendszámon (és az Irányáron, erre később visszatérünk) kívül nincs egy olyan tulajdonság sem, amelynek bármilyen konkrét értéke csak egy bizonyos autóra lenne jellemző (a fekete szín, az 1.1-es űrtartalom stb. sok autóra is igaz lehet). Ha a fenti táblázatot valóban ki szeretnénk tölteni – vagyis létre akarjuk hozni a kereskedés autókészletét, akkor a jelenlegi felállásban egyrészt jó sokat fogunk gépelni (újra és újra beírva mindenféle autóhoz ugyanazokat az adatokat (a „fekete” szót minden fekete autóhoz, a „2000”-es számot minden akkor gyártotthoz, és így tovább. Készítette: SZÁMALK Zrt, Szakképzési Igazgatóság

14


Esettanulmány

Másrészt persze nyilván hibázni is fogunk, és a „fekete” helyett majd néhány esetben „fekte”, „feket” stb. szavakat írunk. Ezek az autók viszont nem fognak előkerülni a nyilvántartásból, amikor egy vevő a fekete autók közül szeretne választani. Célravezetőbb lenne, ha az adatok megadásánál egy előre legyártott „cetlihalmazból”, segédtáblákból vehetnénk ki az egyes értékeket, mintegy felcímkézve ezekkel az autókat. Nézzük például az egyik autó adatait!

11. ábra Segédtáblák használata

Ebben a megoldásban a márkát, típust, színt, stb. egyedtípusoknak fogjuk fel, melyeknek azonosítójuk (pl. sor- vagy kódszámuk) és legalább egy leíró tulajdonságuk van (az évjárat saját jellegéből – természetes számok – eredően önmagát sorszámozza). Milyen előnyök származnak ebből a megoldásból? 1. A szöveges adatokat mindenhol csak egyszer vesszük fel a nyilvántartásba, az autók adatait ezekből a táblákból „importálhatjuk” - nincs hibás adatbevitel (kivéve, ha pl. rossz színt választunk); ha valamelyik szöveg-adatot véletlenül elírtuk, és ezt mondjuk, egy év múlva vesszük észre, akkor is egy mozdulattal javítható, s ettől kezdve minden autónál – visszamenőleg is! – helyesen jelenik meg az érték (megjelenítéskor, nyomtatáskor, adatbevitelkor az autónál levő kulcs-érték alapján a vonatkozó segédtábla beszédes adatát jelenítjük meg).


15


Esettanulmány

2. Az egyes kategóriák könnyen és egységesen bővíthetők. 3. Ha megvizsgáljuk a márka-típus párost, észrevehetjük, hogy közöttük lényeges összefüggés van: a típusok az egyes márkák függvényei. Ez valódi egyed-egyed kapcsolat – az autó-adatok megadásánál pedig a választás megkönnyítésére, hiba-mentesebbé tételére használható fel. Ha megadjuk a márkát, a típushoz már csak egy bizonyos típus-körből választhatunk; ha pedig még nincs megadva márka, nem lehet típust választani.

4. Az adattárolás helyigénye sokkal kevesebb lehet. 5. Ezzel a megoldással a konkrétum – kategória szétválasztását is megoldottuk. Felhívjuk a figyelmet arra, hogy a Feladatok könyvtárral kapcsolatos feladatának megoldását bemutató Megoldásoknál ennek a problémának egy újabb bemutatását, levezetését találhatjuk meg. Korábban ígértük, hogy visszatérünk az irányár kérdésére – miért tekintjük egyedinek minden autóra, miközben látható, hogy több autónak is lehet ugyanaz az ára? Nos, az árak egyezése bizonyos esetekben egyszerűen a véletlen, vagy valamilyen külső szabály eredménye. Ugyanakkor két, paramétereiben teljesen egyforma autó ára is lehet eltérő – például azért, mert az egyik sérült. Az eltérés lehetséges okai kifejezetten a konkrét autó-példánytól függenek. Hasonló okokból lehetséges az is, hogy eltérő paraméterű autók ára meg megegyezik. Egyszóval: az autók eladási árának megállapítása autónként, egyedileg történik, figyelembe véve azok egyéb jellemzőit is. Eddig csak az autók nyilvántartását vizsgáltuk; megnézve a többi egyedet, szintén észrevehetünk olyan részleteket, ahol célszerű a fentiekhez hasonló megfontolásokkal élni. Ilyet találhatunk például a vevők címadatainál (legalább a várost illetően, és összefüggésben az irányítószámmal).


16

Esettanulmány: Autókereskedés adatbázisának megtervezése. A feladat elemzése (levezetve egy magasabb rendű fejlesztési

Recommend Documents