Inżynieria oprogramowania

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

depozyty terminowe

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

Goumbik / Pixabay

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ę

A-r-e-s / Pixabay

 

 

 

 

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

rawpixel / Pixabay

 

 

 

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:

  1. stan z poprzedniego miesiąca
  2. zarobki
  3. 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

stevepb / Pixabay

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:

  1. szkic zadania
  2. niewykonane
  3. wykonane
  4. sprawdzone
  5. 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.

 

Tom
Latest posts by Tom (see all)
Tagi: , , , , , ,