Depozyty czasowe
Witam ponownie, po kilku miesiącach!
Dziś o czasie i pieniądzach w kontekście depozytów
Sumowanie modeli depozytów określonych w czasie
Depozyty czasowe, Modele
Contents
Dziś wpadłem na pomysł modelu depozytowego czasu do zaimplementowania w prosty sposób
Idea
Pieniądze i czas są skończone w czasie i ilości
Atrybuty Modelu Depozyt
- Ograniczenie czasowe,przedział czasu (from – to), typ Date
- Ilość, jednostka skalarna, typ float
- Jednostka, typ int (Enum)
- Typ depozytu
Do konsumpcji depozytów służą zdarzenia
Atrybuty Modelu Zdarzenie
- Znacznik czasu zdarzenia, kiedy ma miejsce
- Czas jego trwania
- Typ depozytu u którego korzystamy
- Ilość zużytego depozytu
Praktyczne zastosowanie
W życiu codziennym wielu ludzi korzysta
z pieniędzy w portfelu,
rzadziej korzystają z konta oszczędnościowego lub skarbonki,
cyklicznie co miesiąc też dostają wypłatę
Co miesiąc wielu z nas robi podsumowanie wydatków z ostatniego miesiąca a na koniec roku trzeba też rozliczyć się z urzędami
Określenie specyfikacji
Wnioski z praktycznej analizy pozwalają określić specyfikację.
Zdarzenia dokonywane są w oparciu o depozyty na których można przeprowadzać operacje dodawania i odejmowania, czyli wydatki i przychody.
Są to zdarzenia cykliczne i jednorazowe określone są czasem, wartością i jednostką.
Model drugi uproszczony
Konieczne jest stworzenie kompetencji modelu, w którym każda z operacji może być zapisana w tym samym modelu bazy danych a następnie łatwo generowana w postaci raportu czasowego: tygodniowego, miesięcznego i rocznego za pomocą jednego zapytania SQL.
Atrybuty Modelu Depozyt 2
- Ograniczenie czasowe, przedział czasu (from – to), typ Date
- Ilość, jednostka skalarna, typ float
- Jednostka, typ int (Enum) [’USD’,’EUR’,’PLN’]
- Typ depozytu, typ_depozytu_id int, klucz obcy
- Operacja, typ int (Enum), [dodawanie, odejmowanie]
Przykładowe użycie
Bierzemy pod uwagę konkretny miesiąć, np Kwiecień
Określamy ID typów depozytów:
- stan z poprzedniego miesiąca
- zarobki
- wydatki
1. Depozyt, stan z poprzedniego miesiąca
- Ograniczenie czasowe = 2018.04.01 – 2018.04.30
- Ilość = 100
- Jednostka = PLN
- Typ depozytu = 1. stan z poprzedniego miesiąca
- Operacja = dodawanie
Ograniczenie czasowe dotyczy czasu w ktorym te pieniadze zostaly zarobione, w tym przypadku dwa tygodnie
2. Depozyt, pieniądze zarobione na kontrakcie
- Ograniczenie czasowe = 2018.04.01 – 2018.04.14
- Ilość = 1000
- Jednostka = EUR
- Typ depozytu = 2. zarobki
- Operacja = dodawanie
Teraz proponuję wydać te pieniądze na zakup książki w polskim sklepie internetowym,
Ograniczenie czasowe dotyczy czasu zakupu,
koszt zakupu książki to 50PLN
3. Depozyt, kupno książki
- Ograniczenie czasowe = 2018.04.02 10:50 – 2018.04.02 11:00
- Ilość = 50
- Jednostka = PLN
- Typ depozytu = 3. wydatki
- Operacja = odejmowanie
Podsumowanie
Te konkretne wydarzenia określone są przez wartości i związane w czasie, można je więc sumować, mimo, że są określone innych walutach lub dotyczą różnych typów depozytów.
- Dlatego pomocny jest atrybut operacja aby było wiadomo co się dodaje a co odejmuje.
- Do przeliczania walut w tym samym zapytaniu SQL można użyć innej tabeli
- Do definiowania różnych depozytów można stworzyć inną tabelę
Kalkulator Depozytów
Klasa Kalkulator powinna mieć wejściowe argumenty:
- Zakres czasu dla którego są sumowane wartości
- Typy depozytów jakie mają być ze sobą sumowane
W celu obliczenia różnych typów danych i otryzmania jednego wyniku, konieczna jest konwersja Walut w jednym zapytaniu.
Przykładowe miesięczne rozliczenie na podstawie wcześniej zdefiniowanych depozytów
- Ograniczenie czasowe = 2018.04.01 – 2018.04.30
Liczenie
- + 1. stan z poprzedniego miesiąca 100PLN
- + 2. zarobki, 100EUR
- – 3. wydatki, 50PLN
Wynik
- 450PLN lub 112EUR
Wnioski
Sumowanie depozytów jest możliwe w zdefiniowanym zakresie czasu, bez względu na typ waluty.
Obliczanie sum poprzez jedno zapytanie SQL
Przeliczanie walut jest możliwe w oparciu o to samo zapytanie SQL, wystarczy stworzyć tabelę przeliczników i co ważne, można to zrobić w oparciu o świeżo wygenerowane dane z konkretnej godziny.
Można ograniczyć też zakres czasowy, by obliczyć wydatki i przychody z tygodnia lub z jednego dnia.
Więcej opcji
Są jeszcze inne ważne atrybuty, które pomogą w tworzeniu większej skali projektu:
- Powiązana tranzakcja, depozyt_id, typ int, obcy klucz
- Właściciel depozytu, user_id, typ int, obcy klucz
- Projekt, project_id, typ int, obcy klucz
- Firma, Organizacja, company_id, typ int, obcy klucz
Mówi się, że nic nie ginie, tylko zmienia właściciela.
Powiązana tranzakcja
Podobnie jest tutaj, każdy depozyt wcześniej był w czyimś posiadaniu.
Stąd warto wprowadzić depozyt_id lustrzanej transakcji, która różni się tylko znakiem do wykorzystania w przypadku raportów cyklicznych, polegających na zerowaniu okresu czasu.
Jeśli otrzymałem od kontrahenta 1000EUR, to znaczy, że na jego koncie, depozyt jest z minusem.
Istnieją dwa lustrzane depozyty: na wcześniejszym z minusem a na następnym z plusem, zmiana jest w znaku i user_id właściciela, czas transakcji jest ten sam.
Na każdy depozyt mogło się wcześniej składać wiele mniejszych lub jeden duży, ilość tutaj nie gra roli.
Rozliczenia okresowe
Rozliczenia okresowe wymagają by na koniec był stan 0, alby przenieść wszystko na nowy miesiąc.
Dla przykładu, Jeśli w Marcu było saldo: 100PLN to na koniec Marca konieczne jest wyzerowanie poprzez dodanie -100PLN a w kwietniu dodanie lustrzanego +100PLN. Sumarycznie daje to 0, wiec wszystko się zgadza.
Raport roczny
Na koniec roku, w ostatnim dniu przenosimy saldo na rok następny i suma z roku powinna wyjść 0.
Zmienia się tylko czas transakcji, oraz znaki operacji.
Projekt
Jest to bardzo szerokie podejście ponieważ metodą depozytów czasowych można tworzyć:
- listę zadań, listy todo jak i dużych projektów w różnych krajach i dużych grupach
- listę płac z uwzględnieniem zaliczek
- listę urlopów z podziałem na urlopy nie wykorzystane w danym roku oraz zachorowania
Lista Zadań, praca w grupie
Jak może wyglądać zastosowanie tego modelu w rozliczaniu się z grupą?
Wystarczy stworzyć określone w czasie, miejscu i przydzielone do konkretnej osoby zadania do wykonania, dodać klucz obcy do szczegółów.
Gdy się deleguje konkretne zadania to wystarczy zrobić lustrzane, poprzez atrybut powiazane transakcje
Gdy się deleguje do grupy, to też można stworzyć lustrzane na więcej niż jednego użytkownika, kopiując to zadania i zmieniajac tylko user_id.
W ten sposób możliwe jest też monitorowanie wykonania zadania w oparciu o konkretny projekt.
Tworzę projekt_id przez user_id
Tworzę kopię do każdego user_id i określam moją tranzakcje_id dla klucza obcego powiazana tranzakcja.
W ten sposób z jednej transkacji z minusem u mnie powstaje wiele transakcji z plusem u każdego, pomiędzy każdym użytkownikiem a mną jest suma ZERO z matematcznego punktu widzenia, jednak w korelacjach zadań konieczne by było stworzenie numerycznej reprezentacji, np:
- szkic zadania
- niewykonane
- wykonane
- sprawdzone
- zamkniete
Za kazda zmiana statusu zmienia sie wlasciciel zadania i czas.
Kazda praca nad zadaniem bedzie odnotowana jako PLUS,
jesli zadanie bedzie okreslone jako wykonane, to u mnie sie ZERUJE, a u innego uzytkownika, który odbiera efekt mojej pracy pojawia sie ten czas.
W ten sposób można powiązać wykonanie pracy z wypłatą pieniędzy:
jeśli wykonywałem dla okreśłonej firmy okreśłone zadania, to można depozyty pracy wygenerować i dla tych transakcji powiązanych stworzyć depozyt lustrzany do wypłaty pieniędzy
Konieczna byłaby optymalizacja zapytań, w tworzeniu wielu powiązanych ze sobą transakcji w okreśłonym projekcie, lub określonego uzytkownika.
Poniżej kilka informacji o grafach w bazach relacyjnych.
http://www.sqlpedia.pl/implementacja-drzew-grafow-sql/
W połączeniu z wydajnym zapytaniem dla struktur hierarchicznych możliwe by było sumowanie w jednym zapytaniu wszystkich kosztów firmy niezależnie od projektu, albo sumowanie wszystkich zadań, które nie są wykonane niezależnie od projektu.
Inne zastosowanie
Na koniec też dodam, że to rozwiązanie mam zamiar zastosować do przeliczania zupełnie innych danych:
- Dni Urlopów wypoczynkowych,
- Dni Pracy oraz zadań w ciągu dnia,
- oraz czasów nieobecności z różnych powodów.
Ta sama metoda, ten sam model, inne dane!
W przyszłości pokażę żywy kod, który ujarzmi te dane i pozwoli na tworzenie przejrzystych raportów.
Od 10 roku życia jestem pasjonatem komputerów i programowania.
Moim pierwszym (mikro)komputerem był ZX-Spectrum a językiem programowania: Basic.
Od 2010 roku programuję zawodowo, objektowo i funkcjonalnie w architekturach monolitycznych i mikro-usługowych.
Obecnie tworzę architekturę ekosystemów dla liderów rynku w firmie Softreck.
