Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: UML i OOAD - baza hoteli
Forum PHP.pl > Forum > PHP > Object-oriented programming
jarexx
Witam
Pracuję nad bazą danych hoteli i pomyślałem sobie, że zrobię to wykorzystując OOP.
Zrobiłem sobie diagram klas, który zamieszczam poniżej i właśnie mam prośbę byście spojrzeli na niego krytycznym okiem i ewentualnie zasugerowali swoje rozwiązanie.
Wszelka krytyka mile widziana.
Główną klasą jest klasa Hotel, która to oprócz nazwy, kategorii itd. jako atrybuty przechowuje również listę obiektów pokoi, obiekt address, obiekt osoby kontaktowej etc.
By aplikacja była "bardziej rozwojowa" wyodrębniłem klasy Address i Contacts, które w przyszłości mogą być wykorzystane w innym miejscu.
Proszę o komentarze.
thek
Popatrz na to od logicznej strony. Klasa hotel ma wiele instancji. Każdy hotel ma oczywiście swoje dane adresowe, ale są one niezmienne, więc albo są zawarte wewnątrz niej, albo tworzą związek jeden do jednego. Widziałeś kiedyś jeden hotel z wieloma adresami? winksmiley.jpg Oczywiście każdy hotel ma wiele pokoi. Dziwnie nieco według mnie ująłeś Kontakt i Osobę. Hotel ma bowiem też dane kontaktowe jedne, ale mogą one wystąpić od 0 do X razy. Tak więc przemyśl jak faktycznie ma to wyglądać wpierw jeszcze raz...
jarexx
Dzięki thek za odzew.
Moim zamysłem jest by wszystko było maksymalnie elastyczne.
Mimo, że wiem iż hotel ma jeden adres to jednak klasy Address i Contacts wyodrębniłem celowo, bo być może kiedyś będzie można ich użyć ponownie np. przy rezerwacji gościa hotelowego, który tez gdzieś mieszka i posiada dane kontaktowe.
Zachęcam do dyskusji.
thek
Skoro tak, to inaczej diagram wygląda smile.gif Jesli miało by wyglądać to tak jak mówisz, to:
Klasa Hotel posiada jedną instancję klasy Adres i jedną instancję klasy Kontakty, zawierającą listy: emaili, telefonów, faxów, stron www.
Klasa Hotel wiąże się z wieloma instancjami klasy Osoba, która posiada brak, jedną lub więcej instancji klasy Adres i brak lub jedną instancję klasy Kontakty zawierającą listy: emaili, telefonów, faxów, stron www.

Popatrz na zależności ile do ilu smile.gif
W ostatecznym rozrachunku w bazie będziesz miał:
a) X - rekordy Hoteli
cool.gif Y - rekordy Osób
c) X + (losowa ilość gości którzy podali conajmniej jeden adres) - rekordy Adresów
d) X + (losowa ilość gości którzy podali jakikolwiek kontakt) - rekordy Kontaktów
e) zmienna liczba zależna od ilości pokoi w każdym Hotelu
Zauważ, że adresy to liczba zmienna ale minimum to dane adresowe wszystkich hoteli (widzialeś hotel bez adresu lub z dwoma? ja nie) oraz adresy klientów. Oczywiście klient może podać kilka (główny, do biura lub inny kontaktowy).
Kontakty z kolei to zawsze dane kontaktowe hoteli i znów adresy klientów. Teraz z kolei klient może mieć tylko jeden taki obiekt, bo przechowuje on listę danych. Jaki z tego wniosek?
Ano taki, że... możesz Adres przesunąć do Kontaktów. Jest on bowiem tak samo tablicą danych jak email, telefon czy strona www.
Jak to może wyglądać od strony bazy danych?
Tabele:
Hotel (id, nazwa, kategoria),
Pokój (id, typ, cena) + klucz_obcy:id_hotelu
Osoba (id, imie, nazwisko)
Adres (id, tu_lista_pól, typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Fax ( numer, typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Telefon ( numer, typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Email ( adres, typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Www ( adres, typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Ale te 4 ostatnie nie różnią się niemal niczym! Więc można pchnąć do jednej tabeli jako:
Kontakt ( pole, rodzaj(www, email, telefon, fax), typ(osoba lub hotel) ) + łącznik( id_hotelu lub id_osoby)
Oczywiście to tylko jedna z możliwych implementacji. Wszystko jest kwestią przemyślenia co z czym i jak. Bez zaplanowania wszystko Ci się rozwali przy zmianach gdy coś zechcesz przerabiać.

EDIT: I zobacz co w UML oznaczają odpowiednie końcówki linii, a nie wal wszędzie romb, bo Cię ktoś kiedyś ochrzani za rysowanie głupot.
jarexx
Dzięki thek. Właśnie o takie krytyczne spojrzenie mi chodziło smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.