Witam. Chciałbym poprosić Was, drogich forumowiczów, o zerknięcie na mój projekt bazy danych, której zadaniem będzie obsługa biblioteki. Za wszelkie uwagi będę niezmiernie wdzięczny.

Sporo nauki przed Tobą

• jako klucz główny stosuj każdorazowo id - nie ma sensu dodawania nazwy tabeli
• jeśli kolumna ma byc kluczem obcym to wtedy właśnie nadaj jej nazwę id_nazwatabeli czyli id_wydawnictwa
• w jakim celu utworzyłeś tabelę autorzy??
• ze struktury tabel wnioskuję, iż jeśli w bibliotece będzie więcej egzemplarzy jednego tytułu to będzie to zapisane właśnie w tabeli Egzemplarze?? Może lepiej zapisać to w tabeli książki jako osobny rekord. Jeśli będziesz miał tabelkę Egzemplarze to w 90% dane będą powtarzane, gdyż większość książek będzie zapewne w 1 egzemplarzu...
• jeśli wszystkie książki będą zapisane w tabeli [książki] to aby zapisać wypożyczenie wystarczy osobna kolumna zawierające id_czytelnika. Ewentualnie można dodać kolumnę data_wypożyczenia, data zwrotu...

Ok - to na tyle Pewnie jeszcze sporo można zmienić, ale nie chcę Cię wystraszyć

Żeby przypisać n autorów do jednej książki? W sumie nazwa tabeli jest nieco myląca, ale struktura mówi o jej roli.


Nie można. Dlaczego? Po pierwsze: wypożycza się egzemplarz książki, a nie książkę (a to jednak jest różnica). Po drugie: masz zapisaną całą historię wypożyczeń. Jeśli nagle stwierdzisz, że książka jest zniszczona można dojść do tego kto i kiedy ją wypożyczał (czyli teoretycznie można złapać "niszczyciela" ).

Fakt o tym nie pomyślałem Jednak miała na to wpływa myląca nazwa tabeli

O tym akurat nie musisz wspominać To mój pierwszy samodzielny projekt po semestrze z bazami danych... Niestety nauka ograniczała się raczej do zrozumienia danych zadań, więc muszę się dowiadywać wszystkiego niejako na własną rękę.


Tutaj chodzi jedynie o nazewnictwo?


Dokładnie tak jak napisał phpion - żeby dodawać kilku autorów do danej książki. BTW - w tabeli jest zbędne pole ID_M, którego zapomniałem usunąć - baza jest jeszcze na etapie projektowania.


No właśnie gdyby to była tylko wypożyczalnia bez żadnego archiwum to myślę, że sprawa byłaby prosta. Ogólnie rzecz biorąc baza danych będzie współpracowała z aplikacją w C++ a jednym z jej zadań będzie przygotowywanie raportów z działalności biblioteki, generowanie przypomnień o przetrzymaniach, naliczanie kar itd. Co do straszenia to nie krępuj się - wolę się przestraszyć teraz niż zobaczyć jak się wszystko sypie z powodu bazy na etapie testowania aplikacji

Dokładnie o to. Grunt to zachować spójność nazw tabel i kolumn w całej bazie, wtedy unikniesz większych problemów już na etapie pisania zapytań.

ps. Dla tabeli Autorzy proponuję nazwę Authors_Books (preferuje english ) Ogólnie jeśli tabela ma służyć do powiązania ze sobą dwóch różnych to najlepiej jej nazwę utworzyć w ten sposób, to taki mój nawyk który sprawdza się wyśmienicie.

Pozdrawiam

Ogólnie większość jest ok, ale moim zdaniem w pewnych miejscach można poprawić i dlaczego
Autor( id, imię, nazwisko ) - Każdy autor jest w bazie tylko raz. Możesz mu dodać inne jednoznaczne pola jak choćby krótkie informacje o nim
Książka (id, tytuł, wydawnictwo, UKD, ilość, jakieś_inne_jednoznaczne_i_unikalne) - każda książka ma dokładne dane, UKD jednoznacznie identyfikuje przyporządkowanie biblioteczne i zakładanie dla niego specjalnie dodatkowej tabeli nie sądzę by było konieczne czy właściwe. Jeśli chcesz, można wyodrębnić by zrobić tabelę klucz => oznaczenie, ale moim zdaniem to nie sprawdzi się, ponieważ UKD jest zbudowane "klockowo" i powinno być analizowane "w locie". To, że jakieś książki będą miały wspólny UKD nie znaczy wiele, gdyż wielokrotnie UKD będzie usiało być suma kilku innych i co wtedy? Ilość tyczy aktualnie będących na stanie biblioteki, czyli gotowych do wypożyczenia. Ja bym jeszcze dodał pozycję "Podręczny", by było widoczne, iż taka książka jest w bibliotece, ale nie jest możliwe jej wypożyczenie, a dostępność jedynie na miejscu.
Wydawnictwo (id, nazwa, jakieś_inne_jednoznaczne_i_unikalne ) - na tyle by wydawnictwo było jednoznacznie identyfikujące
Czytelnik (id, imię, nazwisko, różne_dane_teleadresowe ) - czytelnik jest jednoznaczny i nic więcej mu nie trzeba.
Taryfikator (id, nazwa, cena) - to tylko tabela kar z nazwą tejże i jej kosztem
Wypożyczenie (id_książki, id_czytelnika, data_wypożyczenia, data_zwrotu, stan) - potrzebne by mieć historię. Kto kiedy, do kiedy i co. Najistotniejsza jest flaga, bo to ona określa, czy książka jest zwrócona czy nie. Tabela ta robi nam jednocześnie za archiwum(!). Wszystkie książki już oddane będą miały inny stan niż wypożyczone.

Tabele łączących? Jedna
Autorzy( id_książki, id_autora ) - gdy do jednej książki przypisanych kilku autorów.
Ewentualnie Kary gdy chcesz mieć je pod ręką, zamiast wyliczać w locie.
Kary(id_wypożyczenia, id_taryfikator) - tylko tyle. Ponieważ mając wypożyczenie wiemy automatycznie jakiej książki i jakiego czytelnika tyczy.

A dlaczego sugeruję w Książce statycznie ilość książek? To proste. Mając tam podaną liczbę, traktujemy rekord jako statyczną daną tycząca ilości dostępnych egzemplarzy. Jeśli bazowo mamy 5 i ktoś jakąś wypożyczy, to dodamy rekord do tabeli wypożyczeń i odejmiemy 1. Jeśli ktoś książkę odda, to zwiększymy ją o 1 a w wypożyczeniu oznaczymy, że pozycja oddana (równoznaczne z archiwum). Gdy będzie 0 to pozycja niedostępna do wypożyczenia. Kary można w locie liczyć. Wystarczy z bazy wyświetlić, te wypożyczenia, gdzie pozycja jest poza biblioteką, choć data_zwrotu jest niższa niż aktualna. To co można ewentualnie dodać jeszcze, to do wypożyczeń - Pozycja_zgubiona (jako osobna kolumna, lub lepiej jako dodatkowy stan oprócz wypożyczona i oddana). Co nam to daje? Wiemy, że dana książka została zgubiona przez konkretnego usera pomiędzy określonymi datami. Całość jest o tyle ciekawie zaprojektowana, że mamy ładny wgląd na niemal wszystko. Wiemy co kiedy ma być oddane, kto ma zaległości, ile egzemplarzy oraz u kogo są, bez większych trudności. Select z Książki pokaże ile na stanie, w Wypożyczeniach u kogo i do kiedy są, lub ewentualnie że kiedyś książka była, ale została zgubiona.

W ramach optymalizacji można z czasem tabelę Wypożyczenia partycjonować pod kątem flag oddania i zagubienia. Z czasem wszystko dzieląc na lata. A to przyspieszy tylko działanie całości i nie będzie przeszkadzało, że baza ma miliony rekordów.

No szczerze mówiąc to nieco zdziwiony jestem - po pierwsze dlatego, że w pierwszej chwili myślałem podobnie jak Ty a w drugiej poszedłem po radę do wydziałowego mgr. inż. od baz danych Otóż po konsultacjach i przemyśleniach po nich doszedłem do wniosku, że na tej tabeli będzie za dużo "pracy". Po drugie - o ile dobrze Cię zrozumiałem thek - tabela wypożyczone może sobie nie poradzić w sytuacji jeśli dany użytkownik za jakiś czas wypożyczy drugi raz ten sam egzemplarz książki. Dlatego właśnie wg. wstępnych założeń programu wszystkie rekordy, które będą opisywały książki zwrócone będą przenoszone do tabeli archiwum, która będzie stanowiła bazę dla okresowych statystyk, które także mają być częścią projektu
Jeszcze co do UKD - sam właśnie nie wiedziałem jak to ogarnąć - gatunki literackie itd. - więc wrzuciłem wszystkie oznaczenia UKD z wikipedii do tej tabelki. W zamierzeniu mają być one wybieralne z pola kombi w aplikacji C++ podczas dodawania nowego tytułu...
Jeśli palnąłem coś to nie krzyczcie Po prostu dopiero się próbuję wgryźć w tematy BD.

Co do wypożyczeń i archiwum to kwestia dyskusyjna. Nigdy bowiem nie dojdzie w przypadku jakim podałem do dubla. Co prawda id_książki i id_czytelnika będzie identyczne, ale już daty wypożyczenia - nie. Poza tym zauważ, że właśnie bez dodatkowej archiwizacji dostrzeżesz, że ów user miał kiedyś egzemplarz owej książki, bez odnoszenia do różnych tabel. Można owszem taki podział zrobić, ale nie na poziomie skryptu/wyzwalacza/oprogramowania, ale czasowego "czyściciela", który przenosi wybrane rekordypomiędzy tabelami wedle jakichś kryteriów. Oczywiście wyzwalacz jest fajnym rozwiązaniem, ale osobiście uważam, że sensowniej jest zrzucić to w nocy na CRONa czy coś w ten deseń.

Co do UKD to w Wikipedii jest tylko i wyłącznie wybór części. Zwróć choćby uwagę na to, że tylko niektóre języki zostały tam ujęte. Oznaczeń dla UKD jest o wiele więcej niż to co w Wikipedii masz, a by całość skomplikować, są przecież jeszcze znaki łączące jak choćby / i stąd ujednolicenie jest zwyczajnie niemożliwe. Możesz jedynie pozwolić userowi na wpisanie tego z palca i ewentualnie po stronie skryptu sprawdzić poprawność, zgodność z regułami/zasadami zapisu. Próba rozbicia tego na strukturę bazodanową wymaga znajomości dobrej tego co i gdzie może się znaleźć oraz o jakich wartościach. To zaś wymaga analizy całego ciągu UKD znak po znaku. Ostatecznie jest możliwe, ale musiałbyś zaprojektować własny system zapisu tych danych (tylko zerknąłem w wikipedii na to, co to takiego owo UKD) by było możliwe dwukierunkowe działanie. Zapis powinien być możliwy do choćby wyszukiwania pozycji po kategorii określonej w tym systemie (czyli przykładowo książek z zakresu Literatury pięknej w języku polskim dla młodzieży). Nie mówię, że nie jest to możliwe, ale wymaga przemyślenia jak to w bazie zapisać by operacje nie były mordercze podczas wyszukiwań.

Jeśli nie zauważyłeś, to samo UKD jest budowaniem z klocków. Pewne są na pierwszym miejscu, inne na drugim, a inne na jeszcze dalszych. Nie można tego przekładać na bazę w taki sposób jak podałeś. A co z wspomnianymi wcześniej mieszanymi kategoriami z użyciem + lub / zrobić? Na chwilę obecną to właśnie UKD jest najbardziej zamotanym elementem. Pozostałe są dość proste w implementacji. Dodatkową kwestią dyskusyjną jest użycie ewentualnej dodatkowej tabeli jako archiwum. Moim zdaniem odpowiednie klucze na pola i wydajność przestaje być problemem. To co można jeszcze rozbudować to system tabeli przechowującej kary na podobnej zasadzie jak wypożyczenia, by można było wyłapać nie płacących.

Faktycznie jest sens w tym co mówisz... Postaram się to wprowadzić w życie... Co do UKD to faktycznie jest to zamotane "nieco" i nie wiem czy nie lepszym wyjściem byłoby zastąpienie tego normalnymi gatunkami literackimi...