FOLIA UNIVERSITATIS AGRICULTURAE STETINENSIS Bożena

FOLIA UNIVERSITATIS AGRICULTURAE STETINENSIS
Folia Univ. Agric. Stetin. 2007, Oeconomica 256 (48), 263–272
Bożena NADOLNA
OBIEKTOWY MODEL DANYCH DLA BUDŻETU SPRZEDAŻY
OBJECT DATA MODEL FOR BUDGET OF THE SALE
Katedra Rachunkowości, Akademia Rolnicza
Żołnierska 47, 71-210 Szczecin
Abstract. Assignation of requirement of information manager causes necessity of structure
of accountancy database at utilization of newest methods of modeling economic event. There
is solution such object database. The aim of paper is the building of object data model
for budget of sale. First it presents the essence and evolution of data model. Next it discuss
problems for modeling economic phenomenon by object approach. Present described in final
for budget of sale article part object model data with the aid of UML (Unified Modeling Language) notation.
Słowa kluczowe: budżet sprzedaży, model danych, modelowanie, paradygmat obiektowy.
Key words: budget of sale, data model, modeling, object paradigm.
WSTĘP
Warunkiem sprawnego działania przedsiębiorstwa jest posiadanie aktualnych, przydatnych, prawdziwych i istotnych informacji z różnych obszarów jego funkcjonowania. Generowaniem informacji w układach, odpowiadających potrzebom informacyjnym odbiorców
zewnętrznych i wewnętrznych, zajmuje się między innymi rachunkowość. W związku
ze stałym wzrostem tych potrzeb pojawia się konieczność budowy baz danych dla rachunkowości, przy wykorzystaniu najnowszych metodyk modelowania zdarzeń gospodarczych,
do których należy między innymi podejście obiektowe.
Celem referatu jest opracowanie obiektowego modelu danych księgowych w zakresie
budżetu sprzedaży.
MATERIAŁ I METODY
Pojęcie modelu jest interpretowane jako „[…] zbiór upraszczających założeń określonej teorii” bądź jako „[…] hipotetyczna konstrukcja myślowa będąca uproszczonym obrazem badanego fragmentu rzeczywistości” (Hall i Mosewich 1988, s. 15). Budowa każdego modelu systemu
gospodarczego rozpoczyna się od skonstruowania modelu danych. Ma on na celu organizowanie i dokumentowanie danych systemu.
Według internetowego leksykonu geomatycznego model danych to:
„1) […] abstrakcja świata realnego, która uwzględnia wybrane jego elementy i jest opisana
danymi,
2) opis danych oraz ich powiązań odzwierciedlający strukturę informacyjną w danej organizacji lub dziedzinie,
264
B. Nadolna
3) wzorzec struktury danych w bazie danych” (www.ptip.org.pl).
Według Lausena i Vossensa (2000) pojęcie modelu danych jest trudne do jednoznacznego zdefiniowania. Wieloznaczność jego interpretacji prezentują poniższe definicje. Za model
danych uznaje się:
„– […] metajęzyk (pojęcia, terminologia) do mówienia o danych, o systemach baz danych
i o przetwarzaniu danych;
– sposób rozumienia organizacji danych i ideologiczne lub techniczne ograniczenia w zakresie konstrukcji, organizacji i dostępu do danych;
– języki opisu i przetwarzania danych, w szczególności: diagramy struktur danych, języki
opisu danych i języki zapytań;
– ogólne założenia dotyczące architektury i języków systemu bazy danych;
– ograniczenia, ideologie lub teorie (matematyczne) dotyczące struktur danych i dostępu
do danych;
– pojęcia umożliwiające abstrakcyjny opis rzeczywistych aplikacji wraz z organizacją struktur danych i związaną z tym semantyką” (Lausen i Vossens, s. 17).
Model danych jest traktowany więc jako zbiór pewnych zasad, określających sposób
posługiwania się danymi, które obejmują takie elementy, jak: definicja danych (zasady mówiące o strukturze danych), operowanie danymi (reguły określające sposób operowania
danymi) i integralność (określającą, które stany bazy są do przyjęcia).
Za pomocą modelu danych można otrzymać interpretację danych i uzyskać większą
zrozumiałość i odejście od szczegółów (Tsichritzis i Lochowsky 1990).
W przypadku każdego modelu danych określane są pojęcia pierwotne odpowiadające
elementarnym jednostkom danych oraz specyficzny język służący do:
„– [...] konstruowania złożonych jednostek danych z jednostek prostszych,
– wybierania podzbiorów danych,
– formułowania warunków na wybierany podzbiór danych,
– specyfikowania warunków spójności (niezaprzeczalności, integralności) bazy danych”
(Pankowski, s. 17).
Historyczny rozwój systemów baz danych był zdeterminowany rozwiązaniami zastosowanymi w zakresie modeli danych. W latach sześćdziesiątych i siedemdziesiątych stosowano hierarchiczne i sieciowe modele danych bazujące na pojęciu grafu. Kolejna generacja to systemy relacyjne, w których dane organizuje się na zasadach relacji lub tabeli. Podejście to umożliwia lepsze rozróżnienie logicznego i fizycznego modelu danych. Szczegółową identyfikację wad i zalet poszczególnych modeli danych prezentuje tab. 1.
Wyżej wymienione modele danych wraz z systemami baz danych „[…] okazały się przydatne w rozwijaniu technologii bazodanowych mających zastosowanie w wielu powszechnie używanych aplikacjach biznesowych. Wykazują jednak pewne niedostatki przy projektowaniu i tworzeniu bardziej złożonych aplikacji” (Elmasri i Navathe 2005, s. 654). W związku
z tym powstał kolejny model danych, zwany obiektowym.
Obiektowy model danych dla budżetu sprzedaży
265
Tabela 1. Wady i zalety klasycznych modeli danych
Model danych
System plików
Hierarchiczny
model danych
Sieciowy model
danych
Relacyjny model
danych
Zalety
− łatwy sposób przechowywania danych
− tani sposób gromadzenia danych,
np. na taśmie magnetycznej
− idealny do przechowywania danych
rzadko używanych i niezmienialnych
− możliwość zastosowania w przypadku
danych, które w naturalny sposób
są hierarchiczne
− nawigacyjny charakter zapewniający
szybki dostęp do danych
− łatwość zastosowań
− bardzo duża szybkość działania
− naturalna reprezentacja rzeczywistości
− brak niepotrzebnego powielania i
ograniczenia dostępu do danych
− mogą charakteryzować się dużą szybkością działania
− umożliwiają bezpośrednią implementację relacji „wiele do wielu”
− prostota i solidne podstawy matematyczne, oparte na teorii relacji i języków pierwszego rzędu
− niezależność danych, która pozwala
na modyfikowanie wewnętrznej struktury danych bez wpływu na działające
aplikacje poprzez dodawanie kolumn,
dołączanie tabel do bazy danych, a
także tworzenie relacji bez konieczności wprowadzania dużych zmian w
strukturze
− ukryta nawigacja w bazie danych
przed końcowym użytkownikiem
− dostęp do danych poprzez określenie
właściwości zbioru końcowego, a nie
procedury uzyskania określonego
zbioru
Wady
− brak możliwości zaobserwowania relacji
między plikami
− trudność w przeszukiwaniu danych,
ich odseparowanie i rozproszenie
− powielanie danych
− utrudniona aktualizacja danych
− zależność danych od programu
− brak mechanizmów zabezpieczających
− niekompatybilność formatu plików
− ściśle określone reguły dotyczące relacji
− sztywność modelu danych
− brak bezpośredniego dostępu do danych
− tylko jeden rodzaj związku między dwoma
typami obiektów
− skomplikowane dodawanie i kasowanie
danych
− dodawanie związków (relacji) wymusza
tworzenie z dodatkowych drzew hierarchii
lub odsyłaczy do rekordów oryginału
− w związku z tym, że obiekty informacyjne,
znajdujące się na niższych poziomach,
mogą funkcjonować w ramach obiektów
na wyższych poziomach, dostęp do niższych warstw jest możliwy tylko poprzez
warstwy nadrzędne
− trudności w modelowaniu relacji typu wiele
do wielu
− może być bardzo złożony
i skomplikowany w użyciu oraz w implementacji
− relacje „wiele do wielu” zazwyczaj
są bardzo skomplikowane
i praktycznie niemożliwe do utrzymania,
a więc manipulowanie danymi jest dość
skomplikowane
− poszukiwanie informacji może doprowadzić
do „zapętlenia”
− ubogie możliwości modelowania
− niemożliwość wykorzystania atrybutów
złożonych i zbiorowych
− aplikacja jest uzależniona od struktury tabel
bazy. Aplikacja, która jest połączona z relacyjną bazą danych, musi „widzieć” strukturę
modelu fizycznego bazy danych
− ograniczony zbiór operacji
− wykorzystanie agregacji i specjalizacji
powoduje stworzenie nowych schematów
relacyjnych, co powoduje brak przejrzystości opracowanego modelu
Źródło: opracowanie na podstawie: Harrington (1997) oraz Connelly i Begg (1998).
Obiektowość jest koncepcją bazującą na wyróżnianiu rzeczywistych i abstrakcyjnych
obiektów. Obiekt jest jednostką, która zawiera dane i związany z nimi zestaw procedur
(metod i funkcji). W związku z tym ujmuje statyczne i dynamiczne aspekty systemów. Po-
266
B. Nadolna
zwala to na integralne modelowanie danych i procesów, co stanowi podstawową zaletę
podejścia obiektowego w tworzeniu systemów (Nowicki 2005). W odniesieniu do baz danych obiektowość jako paradygmat jest oparta na następujących zasadach (Laussen
i Vossen 2000; Harrington 2001):
− Złożone obiekty, tożsamość. Oprogramowanie i przechowywane dane powinny składać się ze zrozumiałych modułów zawierających struktury danych z przypisanymi
do nich operacjami, czyli z obiektów. Obiekty mogą być dowolnie duże i dowolnie złożone, ale reguły operowania obiektami nie powinny od tego zależeć. Obiekty mają przypisaną tożsamość, co oznacza, że istnieją i są identyfikowalne niezależnie od ich aktualnego stanu lub miejsca przechowywania.
− Powiązania (ang. relationships). Obiekty mogą być powiązane związkami asocjacyjnymi. Powiązania są w sposób naturalny odwzorowane w strukturze danych, np. w postaci
wskaźników prowadzących od obiektu do obiektu.
− Hermetyzacja (ang. encapsulation). Oznacza rozróżnienie pomiędzy interfejsem do obiektu opisującym, co obiekt zawiera i co robi, a implementacją definiującą, jak on jest zbudowany i jak on to robi. Hermetyzacja oznacza także ukrywanie informacji niepotrzebnej
na danym etapie projektowania lub programowania.
− Klasy, typy, interfejsy. Obiekty są klasyfikowane na podstawie podobieństwa ich charakterystyk. Cechy niezmienne dla tych obiektów, a w szczególności zestaw ich atrybutów (wraz z ich typami) oraz operacje, które można na nich wykonać (metody), są zbierane wewnątrz specjalnego bytu programistycznego, który nazywa się klasą. Typy umożliwiają statyczną i dynamiczną kontrolę poprawności budowy obiektów, poprawności ich
użycia w programach oraz poprawności użycia operacji przypisanych do obiektów.
Obiektowość zakłada oddzielenie zewnętrznej specyfikacji klasy, zwanej interfejsem,
od jej implementacji.
− Metody i komunikaty. Wszelkie operacje na obiektach wykonuje się za pomocą metod,
czyli procedur w środowisku wnętrza obiektu. Obiekt wykonuje jedną z przypisanych
dla niego operacji po wysłaniu do niego komunikatu zawierającego jej nazwę (oraz parametry). Komunikat taki nie zależy od szczegółów implementacji lub reprezentacji obiektu.
− Hierarchia klas i dziedziczenie. Klasy są organizowane w hierarchię (lub inną strukturę) zakresów znaczeniowych; klasy bardziej szczegółowe dziedziczą niezmienniki klas
bardziej ogólnych (definicje atrybutów, metody, definicje zdarzeń lub wyjątków i inne).
Konsekwencją tego założenia jest możliwość skorzystania z klas bardziej ogólnych przy
definiowaniu klasy będących ich specjalizacją – nowa klasa zawiera wszystkie wcześniej
zdefiniowane cechy plus niektóre nowe cechy.
− Przesłanianie, późne wiązanie, polimorfizm. Wybór nazwy operacji jest określony wyłącznie jej zewnętrznym pojęciowym znaczeniem, w ramach danej klasy obiektów; wybór
ten nie jest uwarunkowany jakimikolwiek własnościami lub istnieniem innych klas. Ten
sam komunikat wysłany do różnych obiektów może wywoływać różne operacje; tę własność określa się jako polimorfizm.
− Trwałość (ang. persistence). Niektóre obiekty zachowują swój stan dłużej niż trwa czas
pojedynczego uruchomienia programu (zwykle, dowolnie długo). Trwałość jest podstawową własnością obiektów przechowywanych w bazie danych.
Obiektowy model danych dla budżetu sprzedaży
−
−
−
−
−
−
−
−
−
267
Do podstawowych zalet obiektowego modelu danych zaliczamy:
przejrzyste odwzorowanie rzeczywistości;
dokładną reprezentację złożonych zależności miedzy obiektami;
łatwość działania na złożonych obiektach;
dużą podatność na zmiany;
możliwość definiowania własnych typów danych i metod;
dobrą integrację z językami programowania ogólnego przeznaczenia (np. C++, Smalltalk);
ujednolicony model pojęciowy
obiektowe podejście do analizy, projektowania i implementacji;
dane, które mają złożoną, ale zagnieżdżoną strukturę, zdefiniowaną przez użytkownika, tworzą hierarchię, są rozproszone w sieci heterogenicznej, dynamicznie zmieniają swój rozmiar.
WYNIKI
Planowanie działalności przedsiębiorstwa w gospodarce rynkowej jest jednym z podstawowych narzędzi sterowania jego rozwojem, służy zarządzającym do koordynowania
różnych działań w przyszłości. Plany działalności przedsiębiorstwa są kwantyfikowane
w postaci budżetów. Wskazują one na program działania przedsiębiorstwa oraz kontrolę
wykonania tego programu.
Zastosowanie budżetów w sterowaniu działalnością przedsiębiorstwa przejawia się
w następujących okolicznościach (Czubakowska 2003):
− zatwierdzone budżety wyznaczają przebieg realizacji zadań w przyszłości,
− koordynacja działań podmiotów wewnętrznych i kontrola ich wykonania są możliwe dzięki budżetowaniu,
− budżety ułatwiają komunikowanie się podmiotów wewnętrznych oraz pełnią funkcję motywacyjną,
− budżety stanowią podstawę oceny działalności gospodarczej,
− stała analiza i aktualizacja budżetów przyczyniają się do osiągania bardziej realnych wyników.
Aktywne wykorzystanie budżetów w zarządzaniu jednostką gospodarczą wymaga dostosowania ich do strategii tej jednostki oraz do planowanych działań do wykonywania
w przyszłości. W ten sposób są zapewnione ciągłość planowania i świadome kształtowanie
działalności jednostki gospodarczej. Cały proces przygotowywania i opracowywania zbioru
spójnych budżetów i połączenia ich w jeden główny budżet przedsiębiorstwa nazywamy
budżetowaniem. Przebieg budżetowania ma określoną procedurę, której działanie zostało
zaprezentowane na rys. 1.
Budżet przedsiębiorstwa, uwzględniający przyjęte i zatwierdzone cele jego działalności
składa się z budżetów operacyjnych, finansowych i budżetu strategicznego (inwestycyjnego). Strukturę i powiązania między tymi budżetami prezentuje rys. 2.
Spośród przedstawionych rys. 1 rodzajów budżetów na największą uwagę zasługuje
budżet sprzedaży, który uważa się „[…] za fundamentalny, gdyż wszystkie kategorie kosztów zależą w dużym stopniu od wielkości sprzedaży. Jeśli budżet ten nie jest dokładnie
sprecyzowany, wszystkie pozostałe budżety będą niewiarygodne”. (Gabrusewicz i in. 2001,
s. 215) Budżet sprzedaży przedstawia zarówno ilościowe, jak i jakościowe zestawienie produktów do sprzedaży, co pozwala na określenie planowanych przychodów ze sprzedaży.
268
B. Nadolna
A
Określenie celów jednostki gospodarczej
Analiza kluczowych zmiennych
B
C
Ilościowe wewnętrzne
Zebranie istotnych danych historycznych
Ilościowe zewnętrzne
Określenie założeń dotyczących
przewidywanych zmian podstawowych
zmiennych
ETAP
PLANOWANIA
Udział zatrudnionych
Wprowadzenie danych
do modelu
b d
i
ETAP
WDROŻENIA
BUDŻET
Monitorowanie
faktycznych
wyników
Czy zaplanowano
pożądane wyniki?
TAK
ETAP KONTROLI (STEROWANIA)
Pozytywne
sprzężenie
zwrotne
Czy osiągnięto
pożądane wyniki?
NIE
Możliwie
dostosować
budżet
Ustalenie przyczyn
A
Czy są wewnętrzne
przyczyny?
NIE
Zapewnić
sprzężenie
zwrotne
TAK
Zapewnienie sprzężenia zwrotnego
Dostosowanie
budżetu
Rys. 1. Przebieg budżetowania
Źródło: Jaruga i in. (2001).
Skorygować
problem
C
B
Obiektowy model danych dla budżetu sprzedaży
Budżet główny
269
Plan strategiczny
(długookresowy)
Budżet
operacyjny
Budżet
inwestycyjny
Budżet sprzedaży
Budżet operacyjny
Hurtownia
typ
firmy
Produkcja
Budżet zakupu towarów i płatności
Budżet
produkcji
Budżet robocizny
bezpośredniej
Budżet materiałów
bezpośrednich
Sprawozdania
finansowe
pro forma:
Budżet kosztów
zarządzania
i sprzedaży
Budżet środków
pieniężnych
Budżet kosztów
wydziałowych
Planowany
rachunek zysków
i strat
Planowany bilans
końcowy
Rys. 2. Rodzaje budżetów
Żródło: Sojak (2003).
Struktura budżetu sprzedaży musi być taka, aby można było na jej podstawie ustalić zakres odpowiedzialności dotyczący celów kontroli oraz dostarczyć informacji kierownikom
odpowiednich obszarów funkcjonalnych przedsiębiorstwa. Budżet ten jest sporządzany
przeważnie na rok, z podziałem na okresy miesięczne lub kwartalne.
Istnieje wiele czynników, które powinny być wzięte pod uwagę w procesie sporządzania
prognoz sprzedaży. Są to między innymi (Sobańska 2003):
– bieżący poziom sprzedaży i tendencje w sprzedaży w ostatnich latach,
– ogólna sytuacja na rynku i tendencje występujące w gospodarce i branży,
– działania podejmowane przez konkurencję,
– polityka cenowa,
– warunki kredytowania,
– działania promocyjne i reklamowe,
– otrzymywane do chwili obecnej zamówienia.
Warta podkreślenia jest różnica między prognozą roczną sprzedaży a budżetem sprzedaży. Prognoza roczna to liczba produktów, jaką przedsiębiorstwo spodziewa się sprzedać
w następnym roku obrotowym za określoną cenę i przy określonym poziomie działalności
270
B. Nadolna
marketingowej. Budżet przychodów ze sprzedaży stanowi ostateczny, zatwierdzony przez
odpowiednie osoby w przedsiębiorstwie, produkt tego procesu. Budżet sprzedaży, oparty
na nietrafnych predykcjach, jest niezbyt przydatny do koordynacji działań i oceny dokonań
(Wnuk-Pel 2000). Budżet sprzedaży jest budżetem pierwotnym dla innych budżetów,
na przykład budżetu produkcji czy budżetu wpływu i wydatków.
Obiektowy model danych w zakresie rachunkowości może dotyczyć zarówno modelowania systemu informacyjnego rachunkowości finansowej, jak i rachunkowości zarządczej.
Zaproponowane w referacie rozwiązanie modelu obiektowego w zakresie budżetu sprzedaży wchodzi w zakres rachunkowości zarządczej. Ogólny model danych dla budżetu
sprzedaży został wykonany z zastosowaniem notacji UML,1 co prezentuje rys. 3.
Punktem wyjścia w rys. 3 jest klasa „BudżetSprzedaży”, której atrybutami są: nr_identyfikacyjny,
okres_którego_dotyczy, plan_cena_sprzed, plan_ilość_sprzed, oraz forma_płatności. Aby
dostarczyć informacji o planowanym przychodzie ze sprzedaży, klasę tę powiązano asocjacjami z takimi klasami, jak: „Osoba”, „Dokument” oraz „Produkt” (klasa „Osoba”, o atrybutach: dane_osobowe, adres oraz telefon, których dziedziną są klasy użytkowe). Model
ten dostarcza danych o potencjalnych kontrahentach, którzy chcą kupić od firmy produkty.
W związku z wykorzystaniem generalizacji wszystkie atrybuty klasy „Osoba” są dziedziczone przez klasę „Kontrahent”, która dodatkowo charakteryzuje się takimi atrybutami, jak:
nr_kontrah, data_roz_współp, data_zak_współp oraz konto. W związku z uwzględnieniem
różnego rodzaju rabatów, otrzymywanych przez stałych klientów, klasa „Kontrahent” dodatkowo połączona jest relacją z klasą „Rabat” o atrybutach: rodzaj, termin i procent.
Klasa „Dokument” zaś związana jest asocjacją z klasą „BudżetSprzedaży” ze względu
na podejmowanie decyzji o planowanej ilości sprzedanych produktów oraz ich postulowanej cenie, w oparciu o różnego rodzaju dokumenty, analizy, sprawozdania itp.
Budżety opracowuje się głównie na podstawie zawartych kontraktów i ofert zakupu, prognoz sprzedaży czy sprawozdań ze sprzedaży. Dużą rolę odgrywają tu także informacje
o tendencjach w sprzedaży, pozycji i strategii konkurencji, polityce cenowej firmy czy analizy rynkowe.
Klasa „Dokument” o atrybutach rodzaj_dok, nr_identyfikacyjny, opis, data_sporządzenia
oraz data_do_archiwum stanowi nadklasę w procesie specjalizacji z takimi podklasami, jak:
– SprawZeSprzedaży o dodatkowych atrybutach: nr_spraw, nr_produktu oraz dot_okresu,
– AnalizaRozrachunk o dodatkowych atrybutach: nr_analizy, nr_kontrah oraz dot_okresu,
– AnalizaKonkurencji o dodatkowych atrybutach: rodz_podmiotu, ilość_kon, adres oraz
wnioski,
– KontraktyUmowy o dodatkowych atrybutach: rodzaj, data_real, nr_produktu oraz nr_kontrah,
– AnalizaZdolnProd o dodatkowych atrybutach: nr_produktu oraz wnioski,
– inne.
Ostatnią klasą jest klasa „Produkt”. Dostarcza ona informacji o potencjalnych przedmiotach
sprzedaży i opisana jest za pomocą takich atrybutów, jak: nr_produktu, rodzaj_produktu,
opis_produktu, kolor oraz rozmiar. Klasa „Produkt” jest powiązana z klasami:
1
Język UML – język prezentujący odwzorowanie rzeczywistych danych w postaci notacji i metamodelu.
Przy czym przez notację należy rozumieć zestaw znaków graficznych i reguł ich łączenia na potrzeby
metodyk obiektowych, natomiast metamodel definiuje semantykę wprowadzanych notacji.
BudżetSprzedaży
Budżet
produkcji
Budżet
wydatków
i wpływów
1...*
1
nr_identyfikacyjny: int
okres_którego_dotyczy: string
plan_cena_sprzed: float
plan_ilość_sprzed: int
termin_płtności: Date
forma_płatności: string
1...*
1...*
1
1
1...*
rodzaj_dok: string
nr_identyfikacyjny: int
opis: string
data_sporządzenia: Date
data_do_archiwum: Date
1
Osoba
0...*
dane_osobowe: DaneOsobowe
adres: Adres
telefon: Telefon
UżytyMateriał
nr_produktu: int
nr_materiału: int
jakość: string
1
0...*
0...*
Materiał
Podzespoły
nr_produktu: int
rodzaj_podzes: string
opis: string
jakość: int
1...*
1...*
Produkt
nr_produktu: int
rodzaj_produktu: string
opis_produktu: string
kolor: string
rozmiar: float
Dokument
0...*
0...*
nr_materiału: int
rodzaj_materiału: string
opis: string
jednostka: string
wartość: float
Kontrahent
nr_kontrah: int
data_roz_współp: Date
data_zak_współp: Date
konto: Konto
nr_spraw: int
nr_produktu: int
dot_okresu: Date
AnalizaKonkurencji
rodz_podmiotu: string
ilość_kon: int
adres: AdresOrganizacji
wnioski: string
AnalizaRozrachunk
nr_analizy: int
nr_kontrah: int
dot_okresu
KontraktyUmowy
rodzaj: string
data_real: Date
nr_produktu: int
nr_kontrah: int
0...*
0...*
Rabat
Rys. 3. Obiektowy model budżetu sprzedaży
Ilość asocjacji (klasy biorące udział w związku) w notacji UML:
0…* – co najmniej 0,
1…* – co najmniej 1,
1 – dokładnie 1.
SprawZeSprzedaży
rodzaj: string
termin_obow: Date
procent: int
AnalizaZdolnProd
nr_produktu: int
wnioski: string
Inne
272
B. Nadolna
− „Podzespoły” o atrybutach: nr_produktu, rodzaj_podzes, opis oraz jakość,
− „Materiał” o atrybutach: nr_materiału, rodzaj_materiału, opis, jednostka oraz wartość.
W ramach tych relacji występuje klasa asocjacyjna „UżytyMateriał” o atrybutach
nr_produktu, nr_materiału oraz wskaźnik jakość.
Na rysunku 3 przedstawiającym model „Budżetu sprzedaży” zauważyć można również
związek klasy głównej z „Budżetem produkcji” oraz „Budżetem wydatków i wpływów”.
Związki te wynikają z ustalenia wielkości produkcji na podstawie szacowanej wielkości
sprzedawanych produktów oraz wpływów pieniężnych, pochodzących z estymowanych
przychodów.
PODSUMOWANIE
Jeszcze do niedawna najbardziej popularnym modelem danych w zakresie aplikacji
z rachunkowości był model relacyjny. Jednak ten model danych ze względu na swoje
ograniczenia coraz częściej jest częściowo (modele hybrydowe) lub całkowicie zastępowany obiektową strukturą danych. Prezentowany w artykule obiektowy model danych, dotyczący budżetu sprzedaży, jest wykonany za pomocą notacji UML. Walory podejścia obiektowego pozwalają uzyskać dużą elastyczność i bezpieczeństwo informacji zawartych
w bazach danych rachunkowości. Stanowi to bowiem podstawowe wymaganie w zakresie
przydatności tych baz w procesie podejmowania decyzji.
PIŚMIENNICTWO
Connelly C., Belg J. 1998. Systemy baz danych. WNT, Warszawa, 24.
Czubakowska K. 2003.Budżetowanie jako metoda zarządzania [w: Zarządcze aspekty rachunkowości]. Red. T. Kiziukiewicz. PWE, Warszawa, 288.
Elmasaru R., Shamkand E. 2005. Wprowadzenie do systemów baz danych. Helion, Warszawa, 654.
Gabrusewicz W., Kamela-Sowińska A., Poetschke H. 2001. Rachunkowość zarządcza.
PWE, Warszawa, 215.
Harrington J.L. 2001. Obiektowe bazy danych. Modele danych i języki. Helion, Warszawa, 11–15.
Jaruga A., Nowak W., Szychta A. 2002. Rachunkowość zarządcza. Koncepcje i zastosowania. Społeczna Wyższa Szkoła Przedsiębiorczości i Zarządzania, Łodź, 661.
Lausen G., Vossen G. 2000. Obiektowe bazy danych. Modele danych i języki. WNT, Warszawa, 17.
Leksykon geomatyczny, www.ptip.org.pl, dostęp z 10 stycznia 2007 r.
Nowicki A. 2005. Metodologia tworzenia systemów informacyjnych zarządzania [w: Wstęp
do systemów informacyjnych zarządzania w przedsiębiorstwie]. Red. A. Nowicki. Wydaw.
Politechniki Częstochowskiej, Częstochowa, 224.
Pankowski L. 2000. Model bazy danych obiektów częściowo etykietowanych. Wydaw. Politechniki Poznańskiej, Poznań, 17.
Szychta A. 2000. Planowanie i kontrola kosztów, przychodów i wyników [w: Rachunek kosztów
i rachunkowość zarządcza]. Red. A. Jaruga. COSzZ, Warszawa, 238.
Sojak S. 2003. Rachunkowość zarządcza. Dom Organizatora, Toruń, 550.
Tsichritzis D.C., Lochowsky F.H. 1990. Modele danych. WNT, Warszawa, 67.
Wnuk-Pel T. 2003. Rachunek kosztów standardowych [w: Rachunek kosztów i rachunkowość
zarządcza]. Red. I. Sobańska, C.H. Beck, Warszawa, 233.