Potřebuji navrhnout datový model pro rezervační systém do autoškoly. Oblast předmětu vypadá docela přímočaře, ale stále s tím souvisí složitosti. Musíte sledovat všechny požadavky od klientů a sledovat zdroje (vozidlo, čas a instruktor) spotřebované během lekcí.
Úvod
Rád používám přístup založený na doménách pro návrh datového modelu. Nutí mě to odložit posedlost technologiemi a soustředit se primárně na modelování předmětné oblasti, která se točí kolem souvisejících entit a vztahů mezi nimi.
Požadavky v kostce
Dovolte mi nejprve uvést požadavek v jednoduché angličtině.
Potřebuji datový model pro autoškolu, abych umožnil zákazníkům provést rezervace pro lekce online. Autoškola může mít více instruktorů a více než jedno vozidlo . Lektor je na lekci přidělen na základě rezervace. Systém by měl zákazníkům umožnit zrušit rezervaci/y kdykoli před plánovaným dnem. Vozidlo přiřazené k lekci by mělo být také zaznamenáno, pokud se lekce koná.
Zapojené subjekty a vztahy
Když přemýšlím o předmětu, jako první mě napadnou entity „Zákazník“ , „Instruktor“ , „Lekce řízení“ , „Žádost o rezervaci“ a „Vozidlo“ . Dovolte mi začít s mým úplně prvním stolem pro tento model, a to je customer . Slouží k ukládání kmenových dat pro zákazníky. Pravděpodobně bych potřeboval další tabulku pro uložení podrobností o instruktorovi, ale místo vytvoření tabulky se jménem instruktora vytvořím obecnou tabulku s názvem staff pro podrobnosti o zaměstnancích a ponechte si „Instruktor“ jako pracovní název. Díky tomu bude můj datový model rozšiřitelný i pro další oblasti služeb, jako je administrativní a právní práce autoškoly.
Považuji „kurz řízení“ jako jednu ze služeb tak vytvořím další tabulku s názvem service . Služba, „kurz řízení“ v tomto případě může mít více lekcí. Abych tento požadavek zvládl, určitě potřebuji další hlavní tabulku, a to lesson a jednu tabulku vztahů, konkrétně service_lesson , spravovat mnoho až mnoho vztahů mezi oběma těmito hlavními entitami, tj. jedna služba může mít rozhodně více lekcí, ale na druhou stranu jedna lekce může být také součástí více než jedné služby.
Když člověk odešle žádost o rezervaci, je požádán, aby vyplnil své údaje a předběžné preference, jako je typ služby, který chce, výběr vozidla a datum zahájení. Údaje o zákazníkovi jsou uloženy v tabulce zákazníků. Následně se vytvoří jeden požadavek v request tabulky a všechny preference jsou uloženy proti požadavku ve stejné tabulce. S každou žádostí jsou spojeny určité stavy, jako je „odeslat“, „probíhá“, „zrušit“ a „dokončeno“. Vytvořím pro něj jednu podpůrnou tabulku s názvem request_status .
Při podání žádosti se upřednostňuje vozidlo, tedy typ vozidla. Vozidlo by však bylo ve skutečnosti přiřazeno k lekci, když se koná. Proto ponechávám vehicle_type_id jako jeden ze sloupců v request zatím stůl.
Když je požadavek zpracován, jsou provedeny rezervace pro každou lekci požadavku na službu. Kromě toho jsou ke každé lekci přiřazeni instruktoři a vozidla na základě dostupnosti instruktorů a preferencí zákazníků pro vozidla. Lekce jsou naplánovány na budoucí termíny se stavem „Otevřeno“. Všechny tyto podrobnosti jsou zachyceny v další tabulce transakcí s názvem reservation . Všechny tabulky transakcí jsem zvýraznil jinou barvou než všechny hlavní tabulky.
Jedna hlavní tabulka, reservation_status , je vytvořen k ukládání všech možných hodnot pro stavy rezervace, jako je „otevřeno“, „probíhá“, „zrušit“ a „dokončeno“.
Tento model umožňuje zákazníkovi zrušit jednotlivou lekci i požadavek na službu jako celek. Pokud zákazník zruší požadavek na službu, všechny zbývající lekce, které jsou pro zákazníka naplánovány, budou zrušeny v rezervační tabulce.
Podrobnosti na úrovni sloupců všech těchto tabulek naleznete v datovém modelu, který jsem vytvořil pomocí Vertabelo. Několik bodů týkajících se vytváření sloupců:
- Sloupec vlajky s názvem
is_activeje přidán do všech hlavních tabulek, aby bylo umožněno měkké mazání záznamů. Pokud tedy například některý instruktor opustí školu, překlopíme vlajku na „N“, aby byl jeho záznam neaktivní. - Určité sloupce jako
created_date,created_by,last_modified_datealast_modified_byjsou přidány do všech tabulek transakcí, aby umožnily auditní záznam pro změny v záznamech. Tabulky transakcí jsou v datovém modelu vytvořeném ve Vertabelo zvýrazněny modře. - Možná vás zajímá, co je
address_idve sloupcistaffstůl je pro. Tento sloupec jsem záměrně vložil dostafftabulky, abych mohl rozšířit svůj datový model o podporu automatizovaného procesu přiřazení instruktora k požadavku na základě jeho polohy. Předpokládejme například, že v New Yorku přijde požadavek od White Plains. Můj systém by měl nejprve vyhledat dostupného instruktora ve stejném nebo nejbližším okolí. Můj systém by nikdy neměl přidělovat instruktora pobývajícího na Manhattanu, který je téměř 50 mil daleko od místa žadatele.
Význačné vlastnosti tohoto modelu
- Tento model umožňuje zákazníkům zadávat požadavky na rezervaci podle jejich preferencí pro datum zahájení a vozidlo.
- Umožňuje jim zrušit jednu nebo více lekcí svého kurzu nebo celý kurz samotný.
- Tento model zachycuje podrobnosti o instruktorovi a vozidle pro každou lekci.
- Tento model je rozšiřitelný, aby zvládl všechny možné služby poskytované autoškolou.
- Umožňuje nám efektivně navrhovat školicí kurzy a plánovat lekce.
Databázový model
Zde je návrh databáze pro náš rezervační systém. Model byl vytvořen ve Vertabelo pro databázi Oracle, ale stejný návrh lze bez podstatných změn implementovat i pro jiné databázové stroje.
Závěr
Existují určité oblasti, které jsme v tomto článku nepokryli, například:
- Můžeme vytvořit automatizovaný přístup k přidělování vozidel a instruktorů lekcím?
- Co takhle fakturovat zákazníkům? Co když zákazník nechce platit za celý kurz, ale za několik jeho lekcí? Můžeme mu tyto lekce zpřístupnit?
Podporuje náš stávající model takové funkce? Odpověď je ne. Pravděpodobně se těmto oblastem budu věnovat ve svém příštím článku.