Aujourd'hui, notre tâche consiste à terminer le deuxième projet sur le sujet Hibernate. Son essence est de comprendre la structure de la base de données, de mapper l'entité aux tables existantes et d'ajouter la fonctionnalité minimale pour vérifier que le mappage est effectué correctement.
Maintenant plus en détail :
- Téléchargez le fichier de vidage et déployez-le sur votre machine locale. En tant que base de données, nous utiliserons une base de données de test, qui est distribuée à titre d'exemple avec le package d'installation de MySQL. Le vidage est nécessaire afin de fixer l'état de la base de données, car nous ne pouvons pas garantir qu'il ne changera pas en un jour, un mois, une année.
- Nous n'aurons pas de modèle de projet, alors créez le projet vous-même. Ce devrait être un projet maven avec toutes les dépendances requises ( hibernate-core-jakarta , mysql-connector-java , p6spy ).
- Branchez notre base de données déployée locale en tant que source de données dans Idea. Après cela, dans l'onglet Base de données, placez le curseur sur le schéma du film et appuyez sur la combinaison de touches
Alt+Ctrl+Shift+U
(ne fonctionne que dans la version Ultimate). Cela montrera la structure de l'ensemble du schéma du film (avec les noms de colonne, les clés, etc.). Ressemble à ça:Je suis d'accord, ce n'est pas très agréable à regarder. Désactivez l'affichage du titre de toutes les colonnes et commentaires :
En conséquence, vous obtiendrez un schéma de base de données qui peut déjà être analysé :
- Le circuit s'annonce compliqué, mais tout n'est pas si mauvais. Pour analyser la structure de la base de données, vous devez trouver par où commencer. Il n'y a pas de bonne réponse unique, mais je recommanderais de commencer par un tableau
film
. Prenons quelques relations comme exemple :- La relation entre les tables
film
etfilm_text
est une relation OneToOne explicite , car la tablefilm_text
a un champfilm_id
quiPASfait référence à un ID d'une tablefilm
(pas de clé étrangère). Mais par son nom et sa logique, cette connexion devrait l'être. De plus, dans le tableau,film_text
le champfilm_id
fait office de clé primaire, ce qui garantit qu'à un "film" correspond au plus un "texte de film". - Examinons maintenant les tables
film
etcategory
. Logiquement, un film peut avoir plusieurs catégories. Et une catégorie, peut-être des films différents. De plus, il existe une table de liaison intermédiaire entre ces deux tablesfilm_category
. Sur la base de tout ce qui précède, il s'agit d'une relation ManyToMany explicite . - Nous regardons les tableaux
film
etlanguage
. Du point de vue de la logique, le film peut avoir une traduction dans différentes langues et différents films peuvent être dans la même langue. Autrement dit, ManyToMany se suggère . Mais si nous regardons le contenu de la tablefilm
, nous pouvons voir que chaque ligne de la table est un film unique. Et il n'y a qu'un seul champ language_id dans la ligne (il y a aussi original_language_id, mais dans tous les enregistrements, il est nul, nous pouvons donc l'ignorer). Autrement dit, un film ne peut avoir qu'une seule langue. Et une langue, peut-être des films différents. La connexion est ManyToOne (la connexion est dirigée du film vers la langue).
- La relation entre les tables
- Maintenant, la tâche principale consiste à créer toutes les classes d'entités nécessaires et à les mapper sur les tables de schéma
movie
. - Ajoutez une méthode qui peut créer un nouveau client (table client) avec tous les champs dépendants. N'oubliez pas de rendre la méthode transactionnelle (afin de ne pas vous retrouver dans la situation où l'adresse de l'acheteur est enregistrée dans la base de données, mais pas l'acheteur lui-même).
- Ajoutez une méthode transactionnelle qui décrit l'événement "le client est allé et a rendu un film précédemment loué". Choisissez l'événement acheteur et location de votre choix. La note du film n'a pas besoin d'être recalculée.
- Ajoutez une méthode transactionnelle qui décrit l'événement "l'acheteur est allé au magasin (magasin) et y a loué (location) l'inventaire (inventaire). En même temps, il a effectué un paiement (paiement) au vendeur (personnel). Film (par inventaire) choisissez à votre discrétion. La seule restriction est que le film doit être disponible à la location. Autrement dit, soit il ne doit y avoir aucun enregistrement d'inventaire dans la location, soit la colonne return_date de la table
rental
pour la dernière location de cet inventaire doit être remplie. - Ajoutez une méthode transactionnelle qui décrit l'événement "un nouveau film a été tourné et il est devenu disponible à la location". Film, langue, acteurs, catégories, etc., choisissez à votre discrétion.
- La structure du tableau ne peut pas être modifiée. Mais vous devez faire des suggestions d'amélioration. Nous avons identifié un endroit problématique au paragraphe 4 (absence de clé étrangère dans la table
film_text
sur le champfilm_id
tablefilm
). Voyez s'il y a encore de telles "erreurs" dans la structure de la base de données. Si c'est le cas, ajoutez un fichier readme à la racine du projet et décrivez ces erreurs.
Analyse du projet :
GO TO FULL VERSION