Regularnie widu­je pyta­nia takie jak to:

I have an assi­gn­ment for deve­lo­ping a hotel rese­rva­tion sys­tem! One of tasks is to deve­lop UML class dia­gram! However, in the task descrip­tion it is writ­ten ​„Class dia­gram sho­uld repre­sent your data­ba­se”. I am a bit con­fu­sed abo­ut the rules, nota­tions and etc… becau­se I can’t find any offi­cial UML class dia­grams spe­ci­fi­cal­ly for data­ba­ses! Could you help me ple­ase? (UML class dia­gram for data­ba­se).

i regu­lar­nie piszę: uży­wa­nie dia­gra­mu klas jako repre­zen­ta­cji [rela­cyj­nej] bazy danych to świa­dec­two kom­plet­ne­go nie­zro­zu­mie­nia ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go obiek­to­wo (żeby nie powie­dzieć igno­ran­cji). Jest to tak­że świa­dec­two bra­ku zna­jo­mo­ści lite­ra­tu­ry, bo fak­tycz­nie, jak zauwa­ża autor powyż­szych słów, nie ma ofi­cjal­nych mate­ria­łów (orga­ni­za­cja stan­da­ry­zu­ją­ca UML) mówią­cych o mode­lo­wa­niu rela­cyj­nych mode­li danych dia­gra­ma­mi klas nota­cji UML. Do mode­lo­wa­nia rela­cyj­ne­go mode­lu danych uży­wa­my nota­cji ERD (ang. Entity Relationship Diagram, dia­gram związ­ków encji). Niestety takie wzmian­ki – jak sto­so­wać dia­gram klas UML do mode­lo­wa­nia RDBMS – moż­na zna­leźć w książ­kach uzna­wa­nych za war­to­ścio­we (okład­ka jed­nej z nich po pra­wej), moż­na usły­szeć na wie­lu szko­le­niach doty­czą­cych nota­cji UML, a nawet usły­szeć o tym moż­na – mode­lo­wa­nie danych w UML – z ust nie­jed­ne­go wykła­dow­cy na uczel­niach wyż­szych tech­nicz­nych (co jest smut­ne, mam na pół­ce pod­ręcz­nik aka­de­mic­ki z opi­sem sto­so­wa­nia klu­czy głów­nych i obcych na dia­gra­mach klas w mode­lo­wa­niu danych).

Przy oka­zji. Książkę tę , mam na pół­ce, prze­czy­ta­łem, i mam oba­wy przez jej pole­ca­niem, mimo, że przez wie­lu jest uwa­ża­na nie­mal­że za biblię ana­li­ty­ka biz­ne­so­we­go (ale jako ogól­ny opis mode­lu kom­pe­ten­cyj­ne­go ana­li­ty­ka moż­na ją uznać).

Krótkie przy­po­mnie­nie pojęć (sł. j. polskiego):

dane
1. ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach?
2. ?infor­ma­cje prze­twa­rza­ne przez komputer?

obiekt
1. ?przed­miot, któ­ry moż­na zoba­czyć lub dotknąć?
2. ?rzecz abs­trak­cyj­na, np. cecha lub poję­cie?
3. ?coś, cze­go doty­czą czy­jeś dzia­ła­nia, zain­te­re­so­wa­nia lub uczu­cia?
4. ?budy­nek lub zespół budyn­ków; też: urzą­dze­nia terenowe?

Generalnie dane to zapis fak­tów (infor­ma­cje, wie­dza), obiekt to abs­trak­cyj­ny bądź rze­czy­wi­sty byt, mają­cy okre­ślo­ne cechy i reagu­ją­cy na bodź­ce. To dwa róż­ne świa­ty. Tak zwa­ny para­dyg­mat obiek­to­wy to mode­lo­wa­nie (trak­to­wa­nie) sys­te­mu jako zbio­ru współ­pra­cu­ją­cych w okre­ślo­nym celu obiek­tów. Model danych zaś, to opis orga­ni­za­cji danych w ich repo­zy­to­rium. Model obiek­to­wy to struk­tu­ra współ­pra­cu­ją­cych obiek­tów mają­cych okre­ślo­ne zacho­wa­nia. Nie tyl­ko na uczel­niach nadal poku­tu­je ​„sta­re”: Algorytmy plus struk­tu­ry danych rów­na się pro­gra­my, ale to defi­ni­cja jesz­cze z cza­sów prze­twa­rza­nia wsa­do­we­go. Dzisiaj mamy wokół sie­bie współ­dzia­ła­ją­ce kom­pu­te­ry, smart­fo­ny, linie pro­duk­cyj­ne, a nawet sprzęt AGD, gdzie tu są te oddziel­ne ​„struk­tu­ry danych i algo­ryt­my”? Nie ma, są współ­dzia­ła­ją­ce obiek­ty. Owszem, każ­dy obiekt ope­ru­je okre­ślo­ny­mi dany­mi, ale są one ​„w środ­ku” i nie są ​„jed­ną wiel­ką bazą danych”.

Notacja UML bazu­je na obiek­to­wym para­dyg­ma­cie, dia­gram klas tej nota­cji słu­ży do mode­lo­wa­nia obiek­to­wej struk­tu­ry dowol­ne­go sys­te­mu (obiekt to nazwa, atry­bu­ty i ope­ra­cje jakie wyko­nu­je on na żąda­nie). Nie ma tu mowy o żad­nych danych, co naj­wy­żej obiek­ty cechu­ją się okre­ślo­ny­mi atry­bu­ta­mi, te jed­nak nie są współ­dzie­lo­ne a zamknię­te w tych obiek­tach, bo to ich ​„pry­wat­ne” cechy. Gdyby te atry­bu­ty były współ­dzie­lo­ne, sys­tem taki był­by nie­mo­dy­fi­ko­wal­ny, nie­po­dziel­ny i nie­podat­ny na zmia­ny, na wymia­nę w nim jed­ne­go obiek­tu na inny (co obser­wu­je­my nadal w sys­te­mach zin­te­gro­wa­nych meto­dą współ­dzie­le­nia danych, tak jest skon­stru­owa­ne wie­le sys­te­mów ERP!).

Owszem, na pozio­mie tech­no­lo­gicz­nym nadal korzy­sta­my z pli­ków na dys­kach i baz danych (nie zawsze rela­cyj­nych) ale to co inne­go, korzy­sta­my z nich do zapi­su (utrwa­la­nia) danych/treści, utrwa­la­nia infor­ma­cji (danych). Na sty­ku tych dwóch świa­tów korzy­sta­my (jeże­li jest taka koniecz­ność) z mapo­wa­nia mode­lu obiek­to­we­go na utrwa­la­ne dane i wte­dy korzy­sta­my z nota­cji UML do mode­lo­wa­nia obiek­to­wej archi­tek­tu­ry apli­ka­cji i np. z nota­cji ERD do mode­lo­wa­nia np. rela­cyj­nej struk­tu­ry danych, łącz­nie nazy­wa się mapo­wa­nie obiek­to­wo-rela­cyj­ne (ORM). Tak więc mode­lo­wa­nie danych nota­cją UML to pogwał­ce­nie zasad sto­so­wa­nia tej nota­cji i nie­zro­zu­mie­nie samej nota­cji, poję­cia obiekt i kla­sa. Skąd się bio­rą takie pomy­sły? Bardzo wie­lu ludzi uży­wa nota­cji tyl­ko w cha­rak­te­rze biblio­tek obrazków/symboli, zaś nota­cja to sys­tem poję­cio­wy, a to nie jest to samo. A przy oka­zji: two­rze­nie takich mode­li w nota­cji UML, jako pro­jek­ty mode­lu dzie­dzi­ny sys­te­mu (obiek­to­we­go), to kla­sycz­ny antyw­zo­rzec pro­jek­to­wy o nazwie ane­micz­ny model dzie­dzi­ny.

Bibliografia