Status nie wypożyczone przy tworzeniu tabel w projekcie bazy danych Postgresql

pytanie zadane 23 czerwca 2021 w SQL, bazy danych przez Martita Bywalec (2,470 p.)

Początkująca - Postgresql

Szukałam w google i nie znalazłam.

Robię projekt bazy danych Postgresql biblioteka. Przy tworzeniu tabel chcę mieć status wypożyczenia książek, czyli jakie książki są wypożyczone, jakie nie są wypożyczone, jakie są zarezerwowane, jakie nie są zwrócone tak samo status czytelników, czyli kto wypożyczył, kto nie wypożyczył, kto zarezerwował, kto nie zwrócił.

Jakbym nie potrzebowała ksiązek niewypożyczonych i czytelników, którzy nie wypożyczyli to połączyłabym tabele wypożyczenia z tabelą status.

Co z czym sensownie połączyć, aby przy tworzeniu bazy mieć status książek niewypożyczonych i czytelników, którzy nie wypożyczyli?

Mój jedyny pomysł to połączyć tabele czytelnik z tabelą status, tabele ksiazki z tabelą status, tabele wypozyczenia z tabelą status.

Moje tabele

Tabela logowanie_czytelnika - kolumny id, login, hasło

Tabela czytelnik - kolumny: id, nazwisko, imie, adres, kod_pocztowy, miasto, województwo, email, lo_czytelnik, ha_czytelnik
lo_czytelnik, ha_czytelnik z tabeli logowanie_czytelnika.

Tabela status - kolumny: id, nazwa, - Nazwy statusów: nie wypożyczona, wypożyczona, zarezerwowana, nie zwrócona.

Tabela kategoria - kolumny: id, nazwa

Tabela ksiazki - kolumny: id, isbn, tytuł, autor_I, autor_II, data_wydania, kat_ksiazki,
kat_ksiazki z tabeli kategoria

Tabela wypozyczenia - kolumny: id, nr_czytelnik, nr_ksiazka, data_wypozyczenia, data_zwrotu, data_przedłużenia, st_wypożyczenie
nr_czytelnik z tabeli czytelnik,
nr_ksiazka z tabeli ksiazki
st_wypożyczenie z tabeli status

Proszę o pomoc.

1 odpowiedź

odpowiedź 23 czerwca 2021 przez edutomek Dyskutant (8,380 p.)

0) Problem nie ma związku z PostgreSQL, tylko ogólnie z relacyjnymi bazami danych.

(Taka uwaga na boku.)

1) Jakie są encje?

W zasadzie każda tabela powinna odpowiadać innej encji.
(Plus tabele do relacji pomiędzy encjami.)

Tutaj w szczególności nie widzę powodu rozdzielania danych czytelnika (login + hasło, pozostałe dane - profil?) na dwie tabele w taki sposób, jak zostało to zrobione.

Zwłaszcza, że można sobie wyobrazić, że czytelnik ma kilka adresów kontaktowych, albo kilka e-maili - ale wtedy należy to potraktować jako odrębne encje. Tutaj mamy połączenie adresu fizycznego z e-mailem.

Swoją drogą, w rzeczywistym projekcie oprócz hasła przydałaby się jeszcze sól.

Dalej jest coraz gorzej pod tym względem: np. w książce mamy dane autorów (autor_i, autor_ii). Oby autorów nie było więcej ;-) Życzę powodzenia przy wyszukiwaniu książek danego autora.

A poważnie: książka, autor książki, wydanie - to są wszystko odrębne encje. (Ta sama książka może mieć wiele wydań; każde z wydań powinno mieć ten sam tytuł - tymczasem w bazie będzie można wprowadzić różne wydania tej samej książki i przy okazji zrobić literówkę w tytule.)

Swoją drogą, to w rzeczywistej bibliotece dodałbym jeszcze jedną encję - fizyczny egzemplarz książki (coś, co stoi na półce, albo może zostać wypożyczone). Kiedy robiłem taki projekt, używałem (chyba - podaję z pamięci) następujących encji:
- tytuł (np. "Hobbit"),
- autor (np. JRR Tolkien),
- wydanie
- książka (jako konkretny egzemplarz wydania, z numerem w indeksie biblioteki)

Tabel było więcej (bo encji więcej), były pomiędzy nimi powiązania, a kwerendy były bardziej złożone (ale też bez przesady), ale baza dawała sobie z tym radę, a możliwości popełnienia pomyłki było mniej - i o to mi chodziło.

Proponowałbym zacząć od rozpisania encji, wraz z ich atrybutami, a następnie powiązań (zależności, relacji) pomiędzy encjami. Bez tego nie ma sensu projektować jakiejkolwiek bazy.

Jak to będzie dobrze zrobione, to dodanie statusów do książek, czytelników (czy jakiejkolwiek innej encji) nie będzie aż takim problemem.

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)

Mam na zaliczenie projekt:

Mają być 3 tabele słownikowe (tak nazwał je wykładowca) są to u mnie tabele status, kategoria, logowanie_czytelnika. Mają tylko klucz główny i będą łączone z tabelami wynikowymi.

Mają być minimum 3 tabele wynikowe (tak nazwał je wykładowca) są to u mnie tabele czytelnik, ksiazki, wypozyczenie. Mają klucze główne i obce.

Kolumny tabel mają być takie jak podałam - jest to zaakceptowane przez wykładowce. Tylko powiedział, że musze z tym statusem zrobić tak, żeby przy tworzeniu bazy były książki też niewypożyczone i osoby które nie wypożyczały.
Będą tylko wpisani do dwóch autorów, pomimo, że jest ich więcej.

Piszesz " Ta sama książka może mieć wiele wydań " dlatego mam podaną kolumne date wydania.

Piszesz "w bazie będzie można wprowadzić różne wydania tej samej książki" w bazie nie mam kolumny jakie to wydanie, bo mam date wydania.

Piszesz "przy okazji zrobić literówkę w tytule" Co mam zrobić żeby nie można było zrobić literówki? - Wykładowca uczył nas tylko żeby był typ danych i null lub not null.

Piszesz "w rzeczywistej bibliotece dodałbym jeszcze jedną encję - fizyczny egzemplarz książki (coś, co stoi na półce, albo może zostać wypożyczone)." - dlatego tabela status będzie połączona z tabelą wypożyczenia, aby było wiadomo kto i jaka książka jest wypożyczona.

Mam problem z osobami książkami, które nie są wypożyczone. Jak ich umieścić w tabelach? Jak to w encji sensownie rozpisać?

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)
przeniesione 23 czerwca 2021 przez Arkadiusz Waluk

Można jeszcze zrobić w tabeli czytelnik dodatkową kolumne aktywność czytelników i wtedy osoby, które nie wypożyczały będą mieć w kolumnie aktywność nieaktywni. Tylko jak to będzie sprawdzane czy czytelnik jest aktywny? No chyba że zaznacze, że aplikacja to pilnuje, ale nie wiem czy aplikacja może to robić.

Nie wiem jak to inaczej zrobić?

komentarz 23 czerwca 2021 przez edutomek Dyskutant (8,380 p.)

Dobra, do rzeczy. W zasadzie pomagać w taki sposób nie powinienem, ale skoro sam "wykładowca" tak podchodzi do tematu, to co ja będę z wiatrakami walczył.

W tabeli wypozyczenia mamy st_wypozyczenie. Tam ma być wartość z tabeli (tej słownikowej) status? To może zapytaj, czy "szanowny" wykładowca zgodzi się na takie rozwiązanie: z tabeli status usuwamy "nie wypożyczona", a wtedy brak rekordu danej książki w tabeli wypozyczenia oznacza, że książka po prostu nie jest wypożyczona.

Analogicznie z brakiem w tej tabeli rekordu z numerem czytelnika - jak nie ma, to znaczy, że czytelnik nie wypożyczył żadnej książki.

---

A odnośnie porządnej, fachowej wiedzy, to nieco uściślę:

Mam tabelę "ksiazki" z kolumnami: id, isbn, tytuł, autor_i, data_wydania (oraz innymi).

Mogę tam wprowadzić: "Hobbit", "JRR Tolkien", plus datę wydania.
Następnie mogę wziąć inne wydanie i wprowadzić (literówki, inny zapis): "Hobit", "J.R.R. Tolkien", plus datę wydania.

W efekcie trudno będzie skojarzyć w bazie, że to są dwa różne wydania tej samej książki, tego samego autora. Przyczyna: w bazie mamy dane nieznormalizowane.

Moja odpowiedź dotyczyła raczej pewnych ogólnych reguł stosowanych przy projektowaniu bazy - nie konkretnego projektu (który uznałem za mało czytelny i zawierający błędy - niezależnie od tego, czy jakiś wykładowca uzna go za akceptowalny).

Pytasz, co robić, żeby nie można było zrobić literówek - takie zawsze mogą się pojawić. Rzecz w tym, na ile mogą zaszkodzić.

Jeśli zrobisz literówkę w tytule encji książka (chodzi o "mój projekt", nie o Twój), to ta literówka będzie powiązana z wszystkimi innymi encjami (autorem, wydaniem, etc.). Można ją poprawić w jednym miejscu (jedna tabela, jeden wiersz) - i po sprawie. Jak zrobimy kwerendę łączącą te wszystkie encje, to otrzymamy dane bez usuniętej literówki.

Generalnie poczytaj o postaciach normalnych (link w wersji polskiej, temat jest mocno skrócony) - one pozwalają takich problemów unikać.

Kolumny tabel mają być takie jak podałam - jest to zaakceptowane przez wykładowce. Tylko powiedział, że musze z tym statusem zrobić tak, żeby przy tworzeniu bazy były książki też niewypożyczone i osoby które nie wypożyczały.
Będą tylko wpisani do dwóch autorów, pomimo, że jest ich więcej.

Jest jakiś emotikon na facepalm?

Jako były (a poniekąd wciąż tymczasowy) wykładowca akademicki, z kilkunastoletnim stażem, miałbym czasami ochotę kopnąć niektórych w pewną część ciała tak mocno, żeby z uczelni na ... pysk wylecieli. Bo do nauczania studentów się nie nadają.

To ja, który ekspertem od baz danych i SQLa nie jestem, ba! nie jestem nawet (formalnie) informatykiem z wykształcenia, dostrzegam tak elementarne błędy w projekcie bazy danych, a potem dowiaduję się, że projekt został zaakceptowany.

Ciekawym, jaka będzie ocena za to.

Ale mniejsza o to. Może napisałem ostro, ale mnie to poirytowało. (I nie chodzi mi o postawę studentki, tylko o postawę wykładowcy.)

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)

@edutomek,
Piszesz "Zwłaszcza, że można sobie wyobrazić, że czytelnik ma kilka adresów kontaktowych, albo kilka e-maili" Czytelnik po zapisaniu się do biblioteki otrzymuje 1 adres email i hasło, na który przychodzą informacje biblioteczne np. o zbliżającym się terminie oddania. Więc ma jeden adres email i innego nie może wykorzystać do celów bibliotecznych.

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)
edycja 23 czerwca 2021 przez Martita

Wykładowca nie pozwolił. Mamy projektować według jego założeń i jego wymagań. Proszę o pomoc.

Przerobiliśmy

create database

create table

drop

update

null

join outer

group by

order by

widoki

aliasy

klucze

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)

@edutomek, Piszesz W tabeli wypozyczenia mamy st_wypozyczenie. Tam ma być wartość z tabeli (tej słownikowej) status? To może zapytaj, czy "szanowny" wykładowca zgodzi się na takie rozwiązanie: z tabeli status usuwamy "nie wypożyczona", a wtedy brak rekordu danej książki w tabeli wypozyczenia oznacza, że książka po prostu nie jest wypożyczona.

Wykładowca o tym nam nie mówił.

komentarz 23 czerwca 2021 przez edutomek Dyskutant (8,380 p.)

Może warto go o to zapytać?

(Swoją drogą, to ten "wykładowca" zapewne wielu rzeczy Wam nie mówił...)

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)

Pytałam czy możemy tak zrobić ale się nie zgodził. W jaki jeszcze sposób mogę to zrobić tak jak wymaga to wykładowca?

komentarz 23 czerwca 2021 przez edutomek Dyskutant (8,380 p.)

A jakie są konkretnie wymagania? Bo to nie jest dla mnie jasne.

komentarz 23 czerwca 2021 przez Martita Bywalec (2,470 p.)

To wszystko co pisałam wyżej.

A co nie jest jasne?

Muszę mieć status książek niewypożyczonych i czytelników, którzy nie wypożyczyli przy tworzeniu bazy.

komentarz 23 czerwca 2021 przez edutomek Dyskutant (8,380 p.)

Książki, które nie są wypożyczone: w tabeli wypozyczenia tworzymy rekord dla KAŻDEJ książki (z tabeli ksiazka). W miejscu czytelnika wstawiamy NULL (bo książka nie jest wypożyczona). Status ustawiamy na "nie wypożyczona".

Czytelnicy, którzy nie wypożyczyli żadnej książki? Tu może być więcej kombinowania. Bo nie widzę żadnego statusu, który by do tego pasował (w tabeli status mamy "nie wypożyczona", co nie pasuje do czytelnika).
Może "wykładowcy" chodzi o to, żeby do tabeli status wprowadzić dodatkowe statusy dla czytelników - i przypisać je na takiej samej zasadzie, jak książkom? (Tzn. dodać również kolumnę do tabeli czytelnik z odniesieniem do odpowiedniego statusu?) Albo żeby utworzyć odrębną tabelę ze statusami dla czytelników?

Jeśli to nie to, to już nie mam pojęcia, co "wykładowca" może mieć na myśli.

(Jak się nie stosuje do zasad normalizacji, to potem właśnie takie problemy się pojawiają...)