FOLIA UNIVERSITATIS AGRICULTURAE STETINENSIS Bożena
Transkrypt
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.