Свързан проект: Hibernate (2)

Днес нашата задача е да завършим втория проект по темата Hibernate. Същността му е да се разбере структурата на базата данни, да се съпостави обектът със съществуващи таблици и да се добави минималната функционалност, за да се провери дали картографирането е извършено правилно.

Сега по-подробно:

1. Изтеглете дъмп file и го разположете на вашата локална машина. Като база данни ще използваме тестова база данни, която се разпространява като пример заедно с инсталационния пакет MySQL. Дъмпът е необходим, за да се коригира състоянието на базата данни, тъй като не можем да гарантираме, че няма да се промени за ден, месец, година.
2. Няма да имаме шаблон за проект, така че създайте проекта сами. Трябва да е проект maven с всички необходими зависимости ( hibernate-core-jakarta , mysql-connector-java , p6spy ).
3. Включете нашата локална разгърната база данни като източник на данни в Idea. След това в раздела База данни поставете курсора върху схемата на филма и натиснете клавишната комбинация Alt+Ctrl+Shift+U(работи само в Ultimate versionта). Това ще покаже структурата на цялата схема на филм (с имена на колони, ключове и т.н.). Изглежда така:

   Съгласен съм, не е много удобно за гледане. Изключете показването на заглавието на всички колони и коментари:

   В резултат на това ще получите схема на база данни, която вече може да бъде анализирана:

4. Схемата изглежда сложна, но не всичко е толкова лошо. За да анализирате структурата на базата данни, трябва да намерите откъде да започнете. Няма единствен правилен отговор, но бих препоръчал да започнете с table film. Да вземем няколко връзки като пример:
   • Връзката между таблиците filmи film_textе изрична връзка OneToOne , тъй като tableта film_textима поле, film_idкоетоНЕсе отнася до идентификатор от table film(без външен ключ). Но по име и логика тази връзка трябва да бъде. Освен това в tableта film_textполето film_idиграе ролята на първичен ключ, който гарантира, че един „филм“ отговаря на не повече от един „филмов текст“.
   • Сега нека разгледаме таблиците filmи category. Логично един филм може да има няколко категории. И една категория, може би различни филми. Освен това между тези две таблици има междинна table за връзка film_category. Въз основа на всичко по-горе, това е изрична връзка ManyToMany .
   • Гледаме масите filmи language. От гледна точка на логиката, филмът може да има превод на различни езици и различни филми може да са на един и същи език. Тоест ManyToMany предлага себе си . Но ако погледнем съдържанието на tableта film, можем да видим, че всеки ред от tableта е уникален филм. И има само едно поле language_id в реда (има и original_language_id, но във всички записи е null, така че можем да го игнорираме). Тоест един филм може да има само един език. И един език, може би различни филми. Връзката е ManyToOne (връзката е насочена от филм към език).
5. Сега основната задача е да създадете всички необходими класове обекти и да ги нанесете върху таблиците на схемата movie.
6. Добавете метод, който може да създаде нов клиент (table с клиенти) с всички зависими полета. Не забравяйте да направите метода транзакционен (за да не попаднете в ситуацията, че addressът на купувача е записан в базата данни, но самият купувач не е).
7. Добавете транзакционен метод, който описва събитието „клиент отиде и върна нает преди това филм“. Изберете всяко събитие за купувач и наем по ваш избор. Рейтингът на филма не се нуждае от преизчисляване.
8. Добавете транзакционен метод, който описва събитието „купувачът отиде в магазина (магазина) и нае (под наем) инвентар (инвентар) там. В същото време той извърши плащане (плащане) на продавача (персонал). Филм (чрез инвентар) изберете по свое усмотрение. Единственото ограничение е, че филмът трябва да се дава под наем. Тоест, or изобщо не трябва да има записи за инвентар в наем, or колоната return_date на tableта rentalза последното наемане на този инвентар трябва да бъде попълнена.
9. Добавете транзакционен метод, който описва събитието „заснет е нов филм и той е достъпен за наемане“. Филм, език, актьори, категории и т.н., изберете по ваша преценка.
10. Структурата на tableта не може да се променя. Но трябва да направите предложения за подобрение. Идентифицирахме едно проблемно място в параграф 4 (липса на външен ключ в tableта film_textв полето на film_idtableта film). Вижте дали все още има такива „гафове“ в структурата на базата данни. Ако е така, добавете readme файл към корена на проекта и опишете тези грешки.

Анализ на проекта:

• Част 1
• Част 2
• Част 3