♻️ Концептуальная модель данных ♻️

🤜 Проанализируем тип структуры

Какие аспекты нужно учесть:
▪️наличие большого количества стандартных сущностей (книги, клиенты, штрафы);
▪️необходимость обработки отношений между этими сущностями (книга связана с выдачей клиенту, выдача связана с записью о возврате);
▪️важность гарантии целостности данных при проведении различных операций.

Все это явно указывает на необходимость использования реляционной структуры. Но если бы проект предполагал большую гибкость в хранении данных или значительный рост объема данных и высокая нагрузку на систему, можно было бы рассмотреть гибридный подход, где отдельные части будут реализованы на основе нереляционных хранилищ.


🤜 Определяем атрибуты

Для нашей несложной задачи выделим следующие таблицы и поля:

📖 Books (Книги)
- title (название)
- isbn (ISBN-код)
- authors (авторы книги) – может быть > 1
- publicationyear (год издания)
- pagescount (количество страниц)
- availabilitystatus (статус доступности)
- location (местоположение/полка)
- genre (жанр). Может быть > 1)

🧑‍🎓 Authors (Авторы)
- fullname (ФИО автора)
- biography (биография)

🧞‍♂️ Genres (Жанры)
- name (жанр)

🏛 Departments (Отделы)
- name (название отдела)

🙍 Users (Читатели)
- firstname (имя)
- lastname (фамилия)
- readerticketnumber (номер читательского билета)
- phonenumber (телефон)
- email (электронная почта)
- address (адрес проживания)

🎫 Loans (Выдачи книг)
- book (Выданная книга)
- user (Пользователь, который ее взял)
- issuedate (дата выдачи)
- returndate (предполагаемая дата возврата)
- actualreturndate (фактическая дата возврата)
– loantype (тип выдачи - читальный зал или на дом)

💸 Fines (Штрафы)
- loan (Запись о выдаче)
- amount (сумма штрафа)
- reason (причина начисления штрафа)
- status (статус, оплачен или нет)

Далее займемся приведением данных к нормальным формам.