Organizowanie przyjęć dla dzieci nie jest łatwym zadaniem:wszystko musi być perfekcyjnie zaplanowane i dostarczone. W przeciwnym razie dzieje się chaos. To od dorosłych – a dokładniej od organizatorów imprez – zależy, czy zadbają o wszystko i zrobią to właściwie.
Czy jest na to lepszy sposób niż organizowanie wszystkiego w bazie danych? Nie sądzimy!
Imprezy dla dzieci są bardzo zróżnicowane. Niektóre są proste, na przykład przyjęcia urodzinowe, na które składają się tylko zaproszenia, jedzenie (przekąski, napoje i ciasto), a może klaun lub magik, który zabawi dzieci. Inne imprezy są znacznie bardziej złożone. Mogą wymagać wycieczki poza miasto, miejsca do spania i wielu innych czynności. Im bardziej skomplikowana impreza, tym mniej miejsca na błędy. Chociaż klaun spóźniony 10 minut to nic wielkiego, nikt nie chce czekać z grupą znudzonych dzieciaków na autobus spóźniony o dwie godziny!
Zobaczmy, co model danych może zrobić, aby pomóc planistom imprez zachować porządek.
Czego potrzebujemy w naszym modelu danych?
Załóżmy, że prowadzimy firmę zajmującą się planowaniem imprez. Będziemy mieli listę usług, które oferujemy klientom. Te usługi moglibyśmy świadczyć my lub moglibyśmy skorzystać z partnerów (np. wynająć klauna).
Łączymy te usługi i oferujemy je klientom jako pakiet imprezowy. Każdy pakiet ma punkt początkowy i końcowy lub harmonogram. Obejmuje to nie tylko samą imprezę, ale także jej zorganizowanie i późniejsze sprzątanie. Możemy również mieć wiele lokalizacji (np. impreza zaczyna się od pizzy w restauracji, a następnie przenosi się na plażę, żeby popływać).
Będziemy również musieli powiązać działania z pracownikami, śledzić postępy stron i pobierać opłaty za nasze usługi. Zobaczmy, jak to się robi.
Model danych dla dzieci
Nasz model danych dla dzieci składa się z czterech obszarów tematycznych:
Countries & citiesPartners & servicesEmployees & rolesParty
Zaprezentujemy każdy obszar tematyczny w tej samej kolejności, w jakiej jest wymieniony.
Sekcja 1:Kraje i miasta
Ten obszar tematyczny zawiera tylko dwie tabele. Nie są one specyficzne dla tego modelu, ale użyjemy ich w innych obszarach tematycznych.
Możemy spodziewać się działalności w wielu miastach, a może nawet w kilku krajach. Dlatego będziemy musieli odnieść się do różnych miast. Pomoże nam to śledzić, gdzie znajdują się imprezy, a także jakie usługi oferujemy w każdej lokalizacji.
country słownik zawiera tylko UNIKALNY country_name wartość. Dla każdego city , będziemy przechowywać UNIKALNĄ kombinację postal_code – city_name – country_id .
Sekcja 2:Partnerzy i usługi
Następnie opiszmy szczegółowo usługi, które będziemy świadczyć dla naszych klientów.
Lista wszystkich możliwych usług jest przechowywana w service słownik. Zawiera tylko UNIKALNĄ service_name atrybut.
W tym modelu danych wszystkie usługi są świadczone przez partnerów. Nawet jeśli nasza firma faktycznie świadczy usługę, traktujemy ją jako partner serwis (a my jesteśmy partnerem). Słownik partnerów będzie przechowywać wszystkich partnerów, z którymi współpracujemy, w tym nas. Dla każdego partnera przechowujemy UNIKALNĄ partner_name . details atrybut przechowuje wszelkie dodatkowe szczegóły związane z tym partnerem przy użyciu formatu nieustrukturyzowanego lub strukturalnego (np. przy użyciu par nazwa-wartość oddzielonych predefiniowanym separatorem).
provides table to ostatnia i najważniejsza tabela w tej sekcji. Dla każdego rekordu przechowujemy:
partner_id–partnerktóry świadczy usługę.service_id–serviceten partner zapewnia.city_id– Odwołuje się docitygdzie ta usługa jest świadczona przez tego partnera.date_from– Data, w której partner zaczął oferować tę usługę.date_to– Data, w której partner przestał oferować tę usługę. Ta wartość może wynosić NULL, jeśli ta relacja serwis-partner nadal trwa.details– Wszystkie dodatkowe szczegóły związane z tą usługą, takie jak opis usługi, cena itp. Możemy spodziewać się, że wszystkie szczegóły będą miały ustrukturyzowany format tekstowy z wykorzystaniem par klucz-wartość.
Kombinacja partner_id – service_id – city_id – date_from tworzy klucz UNIKATOWY w tej tabeli. Kiedy wprowadzamy nowy rekord, powinniśmy sprawdzić, czy nie pokrywa się on z żadnymi istniejącymi rekordami.
Sekcja 3:Pracownicy i role
Zanim przejdziemy do centralnej i najważniejszej części naszego modelu, musimy przyjrzeć się tabelom związanym z naszymi pracownikami i ich rolami.
Centralną tabelą w tym obszarze tematycznym jest employee stół. Dla każdego pracownika przechowamy jego first_name , last_name , user_name i password . Użyją tych dwóch ostatnich atrybutów, aby uzyskać dostęp do naszej aplikacji.
Lista wszystkich możliwych ról jest przechowywana w role słownik. Każda rola jest JEDYNIE zdefiniowana przez swoją role_name . Role są powiązane z czynnościami, które każdy pracownik wykonuje podczas przyjęcia. Dlatego możemy spodziewać się tutaj wartości takich jak „kierownik imprezy” lub „asystent”.
Role można przypisywać pracownikom za pomocą has_role stół. employee_id – role_id para będzie oznaczać aktywne role, jakie każdy pracownik ma w danym momencie.
Sekcja 4:Impreza
Party obszar tematyczny jest centralną częścią tego modelu. Wykorzystamy go do powiązania tabel z innych obszarów tematycznych, a także będziemy mieć tutaj kilka nowych informacji.
Centralną tabelą jest tutaj party stół. Dla każdej imprezy przechowamy:
city_id–citygdzie odbędzie się impreza.client_id–clientta impreza jest organizowana.details– Szczegółowy opis tekstowy imprezy.start_time_plannediend_time_planned– Czas, który zaplanowaliśmy na tę imprezę, w tym konfigurację i sprzątanie.start_time_actualiend_time_actual– Rzeczywiste godziny, w których odbyła się impreza (i związane z nią usługi).price_offered– Cena, którą podaliśmy za zorganizowanie tej imprezy dla tego klienta.time_offered– Kiedy złożono ofertę.price_paid– Rzeczywista kwota, jaką klient zapłacił za tę imprezę.time_paid– Kiedy dokonano płatności.
Każda ze stron jest powiązana z klientem. Odnieśliśmy się już do client tabeli, ale teraz zobaczymy, co tam jest przechowywane. Poszedłem tylko z podstawowymi danymi:client_name , dane kontaktowe (address , email , phone , mobile ) oraz wszelkie dodatkowe szczegóły w formacie tekstowym.
Każda ze stron będzie również miała listę powiązanych z nią usług. Ta lista jest przechowywana w service_included stół. Dla każdego rekordu potrzebujemy:
party_id– Odwołuje się do powiązanejparty.service_id– Odwołuje się doservicezawarte w imprezie.provides_id– Odwołuje się doprovidertej usługi, jak również samej usługi. Ten atrybut może mieć wartość NULL, ponieważ zaktualizujemy go, gdy wybierzemy konkretnego dostawcę.details– Wszelkie dodatkowe szczegóły tekstowe związane z tą usługą w tej grupie.start_time_plannediend_time_planned– Planowane godziny świadczenia usługi podczas imprezy.
Będziemy też musieli śledzić postępy każdej ze stron. W tym celu użyjemy dwóch tabel.
status tabela zawiera wszystkie możliwe statusy, które można przypisać do strony. Dla każdego rekordu będziemy przechowywać UNIKALNĄ status_name oraz trzy flagi:
successful– Czy wszystko poszło dobrze? A może wystąpiły problemy z naszymi usługami?paid– Czy impreza została opłacona?final– Czy to ostateczny status tej imprezy?
Przypiszemy statusy usługom, dodając nowe rekordy do party_status stół. Dla każdego rekordu będziemy przechowywać odniesienia do party i service tabele i timestamp kiedy ten status został przydzielony.
Ostatnią tabelą w naszym modelu jest invoice stół. Nie jest to specyficzne dla tego modelu, ale potrzebujemy podstawowej struktury do przechowywania faktur. Dla każdej faktury odnotujemy:
client_name– Imię i nazwisko klienta w momencie wystawienia faktury.party_id–partyzwiązane z tą fakturą.client_id– Identyfikatorclientfakturowanie.invoice_amount,discount,vat_amount,total_amount– Szczegóły finansowe faktury.time_issued- Kiedy ta faktura została wystawiona lub dodana do bazy danych.time_paid- Kiedy ta faktura została zapłacona.
Co byś zrobił z tym modelem danych?
Ten model jest dość prosty, ale widzę kilka sposobów, w jakie możemy go ulepszyć. Jakie zmiany byś zaproponował? Czy jest coś, co moglibyśmy zorganizować inaczej? Może musimy dodać lub usunąć funkcję. Powiedz nam w komentarzach.
