Model danych organizacji ślubu

Wesela często towarzyszą wesołości i uroczystości, z licznymi gośćmi, jedzeniem, napojami, muzyką i tańcami. Ale to wszystko nie może się zdarzyć bez odpowiedniego przygotowania i koordynacji. Przyjrzyjmy się bliżej, jak modelowanie danych może pomóc nam lepiej zorganizować wesele, aby wszystko przebiegało sprawnie.

Wstępne tło

Chociaż w większości wiemy, jak wygląda typowa ceremonia ślubna, nie zaszkodzi pokrótce rozważyć kilka aspektów, które mogą potencjalnie wpłynąć na nasz model danych.

Partnerzy ślubni

Chociaż w większości tradycyjnych kultur odbywają się ceremonie między mężczyzną a kobietą, małżeństwa osób tej samej płci mają miejsce również w innych społeczeństwach. Nasz model danych powinien być zaprojektowany w taki sposób, aby uwzględniał wszystkie możliwości.

Skala i złożoność

Ceremonie ślubne różnią się znacznie pod względem wielkości, czasu trwania i złożoności. Niektóre to małe, skromne okazje, ale inne to wielkie uroczystości. Na przykład w Chorwacji można urządzić prostą ceremonię ślubną, podczas której para bierze ślub w ratuszu, wymienia przed gośćmi pierścionki i śluby, a potem albo bierze udział w kolacji po ceremonii, albo wraca do domu. W innych krajach wesela mogą być dość skomplikowane:mogą obejmować wieczory kawalerskie/panieńskie, negocjacje, kolacje, wiele ceremonii i tak dalej. W niektórych przypadkach ceremonie te mogą trwać wiele dni i odbywać się w kilku różnych miejscach! Ponownie, nasz model danych powinien być przygotowany do obsługi takich sytuacji.

Końcowy wynik i wydatki

W większości przypadków para bierze ślub po uroczystości i otrzymuje fakturę na wszystkie koszty (czynsz, jedzenie i napoje, zespół itp.). Mogą zdecydować się na wynajęcie agencji, która zajmie się wszystkimi tymi kosztami za nich, lub mogą zdecydować się na samodzielne zajęcie się tym wszystkim. Tak czy inaczej, powinniśmy uwzględnić te sytuacje.

Model danych:omówienie

Nasz model danych dla tego artykułu składa się z pięciu sekcji:

1. Lokalizacje
2. Partnerzy, produkty i usługi
3. Wesela
4. Uczestnicy
5. Faktury

Dokładnie omówimy każdy z tych obszarów w kolejności, w jakiej są wymienione powyżej. Pracując nad rozwojem naszego modelu danych, przejmiemy rolę agencji organizującej wesele.

Sekcja 1:Lokalizacje

Locations Sekcja zawiera uniwersalne tabele, które można wykorzystać w wielu innych modelach danych. Jak zauważyliśmy wcześniej, cała ceremonia ślubna może odbyć się tylko w jednym miejscu lub potencjalnie obejmować wiele lokalizacji. Omówmy tabele w tej sekcji bardziej szczegółowo.

country tabela przechowuje informacje o kraju, w którym odbywa się ślub. W większości przypadków ten kraj będzie odpowiadał lokalizacji naszej agencji, ale może to nie mieć miejsca, jeśli działamy na arenie międzynarodowej. Każdy kraj w tej tabeli jest jednoznacznie zdefiniowany przez jego country_name .

Następnie musimy zapisać listę wszystkich miast i/lub wsi, w których będzie organizowany ślub. Te informacje będą przechowywane w city stół. Dla każdego miasta przechowujemy jego nazwę i kod pocztowy, a także kraj, w którym się znajduje.

Ostatnia tabela w tym obszarze tematycznym to location . Lokalizacje są bardziej szczegółowe, takie jak ratusze, kościoły, parki i tak dalej. Dla każdej lokalizacji zapiszemy jej nazwę i odniesienie do identyfikatora miasta, w którym się znajduje. Połączenie tych dwóch atrybutów tworzy unikalny klucz dla tej tabeli.

W przypadku lokalizacji należy pamiętać, że przyjęliśmy tutaj konserwatywne podejście, aby uniknąć omawiania nietypowych przypadków, w których ceremonia odbywa się, powiedzmy, w pociągu lub samolocie (w takim przypadku „lokalizacja” może obejmować wiele miast). Jeśli chcielibyśmy omówić te przypadki, musielibyśmy wprowadzić pewne zmiany w naszym modelu.

Sekcja 2:Partnerzy, produkty i usługi

Zanim przejdziemy do centralnej części naszego modelu danych, musimy zapisać listę wszystkich partnerów, z którymi współpracujemy, a także oferowanych przez nich produktów i usług. Aby to osiągnąć, użyjemy pięciu tabel.

Po pierwsze, lista wszystkich partnerów, z którymi współpracujemy, jest przechowywana w partner słownik. Dla każdego partnera przechowujemy jego unikalny partner_code i partner_name .

Oczywiście nasi partnerzy zapewnią usługi związane ze ślubem, które mogą obejmować catering, organizację zespołów, ustawienie sprzętu audio i wideo, obsługę wynajmu i wiele innych. Zasadniczo wszystko, co możesz wymyślić, może być w jakiś sposób związane z weselem. Przechowamy tę listę usług w service słownik. Dla każdej usługi przechowujemy:

• service_code – wartość, której użyjemy wewnętrznie, aby jednoznacznie oznaczyć konkretną usługę.
• service_name – nazwa usługi. Pamiętaj, że różne usługi mogą mieć tę samą nazwę. Miałoby to miejsce, gdyby dwóch naszych partnerów oferowało tę samą usługę, co jest całkiem prawdopodobne. Byłoby nawet pożądane, gdyby używali tej samej nazwy dla tego samego typu usługi, ponieważ znacznie ułatwiłoby to porównywanie cen tych samych usług.
• description – opcjonalny opis tekstowy usługi.
• picture – link do lokalizacji, w której przechowywane jest powiązane zdjęcie usługi.
• price – aktualna cena za tę usługę. Może zawierać wartość NULL, jeśli nie można ustalić ceny bez uprzedniej oceny różnych czynników, takich jak liczba osób, które planuje wziąć udział w ceremonii.

provides_service tabela odnosi partnerów do listy świadczonych przez nich usług. Dla każdej unikalnej kombinacji partner_id i service_id , będziemy przechowywać szczegółowy opis tekstowy charakteru usługi świadczonej przez partnera oraz tego, czy usługa jest obecnie dostępna.

Potrzebujemy również tabel do przechowywania informacji o produktach i ich relacjach z partnerami. product tabela działa zgodnie z tą samą logiką, co service tabeli, poza tym, jak sama nazwa wskazuje, jest ona specyficzna dla produktów. W tej tabeli przechowamy wszystkie możliwe produkty, które są niezbędne podczas większości ceremonii ślubnych, takie jak pierścionki, stroje, dekoracje, kwiaty, meble i nie tylko.

Ostatnia tabela w tej sekcji to provides_product stół. Działa podobnie jak provides_service tabeli, z wyjątkiem tego, że jest ona specyficzna dla produktów, a nie usług. Określa, który z naszych partnerów oferuje dany produkt.

Sekcja 3:Wesela

W końcu dotarliśmy do sedna naszego modelu danych — Weddings Sekcja. Zawiera pięć nowych tabel, które odwołują się do tabel innych sekcji. Pamiętaj, że własne tabele z tej sekcji będą również przywoływane w kolejnych częściach naszego modelu.

W wedding tabeli, przechowamy pełną listę wszystkich wesel, w których byliśmy/byliśmy zaangażowani. Każdemu weselu zostanie przypisany swój unikalny wedding_code . Będziemy również przechowywać planowane godziny rozpoczęcia i zakończenia całej ceremonii, a rzeczywiste czasy rozpoczęcia i zakończenia zaktualizujemy, gdy tylko te informacje będą dostępne. Dodatkowo przechowamy budget_planned wartość, więc mamy przynajmniej oszacowanie, ile to wszystko będzie kosztować. Wszystkie inne szczegóły związane ze ślubem są przechowywane w innych obszarach modelu danych, więc to wszystko, czego naprawdę potrzebujemy na teraz.

Ideą jest tutaj traktowanie każdego wesela jako serii wydarzeń. Zdarzenia z kolei będą związane z ofertami pożądanych produktów/usług, ofertami odrzuconymi i zaakceptowanymi oraz innymi istotnymi szczegółami. Aby lepiej zrozumieć, jak to wszystko działa, możemy podzielić cały ślub na następujące wydarzenia:faza planowania, wieczory kawalerskie/panieńskie, ceremonia i afterparty/kolacja. Oczywiście to tylko niektóre z najczęstszych wydarzeń weselnych. Wszystkie wydarzenia weselne są przechowywane w tabeli wydarzeń. event będzie miał unikalny identyfikator.

Każde wydarzenie jest powiązane z jednym ślubem i będzie związane z jedną lokalizacją lub żadną. Ten ostatni przypadek ma miejsce, gdy wydarzenie jest bardziej koncepcyjne , takich jak faza planowania (ponieważ nie ma jednej lokalizacji, w której musi się to odbyć). Podobnie jak w przypadku samej ceremonii ślubnej, wydarzenie będzie miało zaplanowane i rzeczywiste godziny rozpoczęcia/zakończenia, a także planowany budżet. Pamiętaj, że zachowaliśmy tutaj prostotę w odniesieniu do lokalizacji. Jeśli zdarzenia dotyczą wielu lokalizacji, będziemy musieli dostosować nasz model danych.

Idąc dalej, chcemy przechowywać wszystkie usługi i produkty, które są związane z wydarzeniem. Aby to zrobić, użyjemy trzech tabel:status , product_included i service_included .

status table to słownik, który śledzi wszystkie statusy związane z produktami i usługami dla danego wydarzenia. Zawiera zmienne flag, które wskazują, czy produkt/usługa została zaoferowana, zaakceptowana lub odrzucona. Dla każdego rekordu w tej tabeli będziemy przechowywać unikalną status_name .

Pozostałe dwie tabele w tej sekcji, zatytułowane product_included i service_included , przypominają się strukturalnie i koncepcyjnie. Dla każdego wydarzenia będziemy przechowywać listę oferowanych produktów i usług oraz zmieniać ich statusy, jeśli zostaną zaakceptowane lub odrzucone. Dla każdego rekordu w tych dwóch tabelach będziemy przechowywać następujące wspólne atrybuty:

• event_id – odniesienie do powiązanego wydarzenia.
• provides_product_id / provides_service_id – odniesienia do tabel z produktami/usługami, które oferują nasi partnerzy.
• price – proponowana cena za produkt/usługę. Ta cena może różnić się od standardowej ceny, którą mamy w aktach, jeśli zaproponujemy specjalną ofertę.
• current_status_id – odniesienie do status słownik oznaczający, czy ten rekord został zaoferowany, zaakceptowany lub odrzucony.

Sekcja 4:Uczestnicy

Jeśli organizujesz duże wesele, prawdopodobnie znasz większość gości, którzy planują w nim uczestniczyć. Oczywiście goście, których zaprosisz — czy to Twoi znajomi, czy krewni — prawdopodobnie przyprowadzą inne osoby, których osobiście nie znasz, na przykład ich przyjaciół lub współpracowników. W tej sekcji przechowamy pełną listę gości, którzy zostali zaproszeni na wesele, a także ich role.

person tabela zawiera listę wszystkich osób biorących udział w weselu. Dla każdej osoby przechowujemy jej unikalny person_code oraz imiona i nazwiska. Jeśli chcemy, możemy oczywiście dodać więcej szczegółów.

Następnie określimy wszystkie możliwe role, jakie można przyjąć podczas wesela. Te role obejmują „gość”, „drużnik”, „drużnik”, „druhna”, „panna młoda”, „pan młody” i tak dalej. Dla każdej roli będziemy przechowywać tylko unikalną role_name w tej tabeli. Dana osoba może przyjąć tylko jedną rolę na konkretny ślub.

Następnie odniesiemy wesela do ich uczestników. Zauważ, że participate tabela zawiera tylko odniesienia do tabel wedding , person i role . Kombinacja wedding_id i person_id służy jako klawisz alternatywny dla tej tabeli.

Wesele będzie się składać z kilku wydarzeń, ale nie wszyscy uczestnicy będą w nie zaangażowani. Dlatego musimy przechowywać te informacje osobno. W in_event tabeli, będziemy przechowywać unikalne pary kluczy obcych odwołujące się do tabel event i participate . Wszystkie dodatkowe informacje będą przechowywane w details przypisany tekst.

Sekcja 5:Faktury

Prawie skończyliśmy! Ostatnia sekcja naszego modelu danych pozwala nam śledzić wydatki związane ze ślubem. Ekscytujące, prawda?

Zwykle generujemy jedną invoice na ślub, ale moglibyśmy też wygenerować więcej, jeśli zajdzie taka potrzeba. Miejmy nadzieję, że całkowita kwota, którą zafakturujemy parze, będzie ściśle odpowiadać naszemu planowanemu budżetowi, ale nie zawsze tak jest. W przypadku każdej faktury przechowujemy następujące informacje:

• wedding_id – wzmianka o ślubie, na który została wystawiona faktura.
• time_created – znacznik czasu, kiedy wygenerowano fakturę.
• due_date – data, do której faktura musi być zapłacona.
• invoice_amount – całkowita kwota do zapłaty.
• payment_time – znacznik czasu faktycznego wystawienia płatności. Oczywiście ten atrybut będzie zawierał wartość NULL do momentu dokonania płatności.
• paid – flaga informująca, czy faktura została zapłacona. Ten atrybut zostanie ustawiony na „True” jak tylko payment_time jest aktualizowany.

Ostatnia tabela w naszym modelu dotyczy samych pozycji fakturowanych. Przechowamy je w invoice_item stół. Dla każdego rekordu przechowujemy następujące szczegóły:

• item_name – nasza wybrana nazwa dla konkretnego przedmiotu.
• item_price – cena związana z tym konkretnym przedmiotem.
• invoice_id – identyfikator powiązanej faktury.
• service_included_id – identyfikator usługi, której dotyczy pozycja faktury. Ten atrybut może mieć wartość NULL, jeśli dany produkt nie jest w rzeczywistości związany z żadną usługą lub jest to tylko dodatkowa opłata, którą nałożyliśmy na fakturę.
• product_included_id – identyfikator produktu, którego dotyczy pozycja faktury. Ten atrybut może mieć wartość NULL, jeśli przedmiotowy produkt nie jest w rzeczywistości powiązany z żadnym produktem lub jest to tylko dodatkowa opłata, którą nałożyliśmy na fakturę.

Podsumowanie

To dość dobrze podsumowuje ten model danych! Po raz kolejny widzimy, jak przydatne jest modelowanie danych w organizacji informacji o firmie.

Jak zauważyliśmy, jest wiele rzeczy, które pominęliśmy w naszym modelu danych dla uproszczenia. Na przykład nasz model powinien idealnie śledzić historię ofert, szczegóły finansowe i nie tylko.

Daj nam znać poniżej, jeśli masz jakieś sugestie. Chętnie poznamy Twoje przemyślenia!