Gerelateerd project: Slaapstand (2)

Vandaag is het onze taak om het tweede project over het Hibernate-onderwerp te voltooien. De essentie is om de structuur van de database te begrijpen, de entiteit toe te wijzen aan bestaande tabellen en de minimale functionaliteit toe te voegen om te controleren of de toewijzing correct is uitgevoerd.

Nu in meer detail:

1. Download het dumpbestand en implementeer het op uw lokale computer. Als database gebruiken we een testdatabase, die als voorbeeld samen met het MySQL-installatiepakket wordt verspreid. De dump is nodig om de status van de database te herstellen, aangezien we niet kunnen garanderen dat deze niet binnen een dag, maand of jaar zal veranderen.
2. We hebben geen projectsjabloon, dus maak het project zelf aan. Het zou een maven-project moeten zijn met alle vereiste afhankelijkheden ( slaapstand-core-jakarta , mysql-connector-java , p6spy ).
3. Sluit onze lokaal geïmplementeerde database aan als gegevensbron in Idea. Plaats daarna op het tabblad Database de cursor op het filmschema en druk op de toetsencombinatie Alt+Ctrl+Shift+U(werkt alleen in de Ultimate-versie). Dit toont de structuur van het volledige filmschema (met kolomnamen, sleutels, enz.). Het lijkt hierop:

   Ik ben het ermee eens, het is niet erg comfortabel om naar te kijken. Schakel de weergave van de titel van alle kolommen en opmerkingen uit:

   Als resultaat krijgt u een databaseschema dat al kan worden geanalyseerd:

4. Het circuit ziet er ingewikkeld uit, maar niet alles is zo erg. Om de structuur van de database te analyseren, moet u weten waar u moet beginnen. Er is niet één juist antwoord, maar ik zou aanraden om met een tabel te beginnen film. Laten we een paar relaties als voorbeeld nemen:
   • De relatie tussen tabellen filmen film_textis een expliciete OneToOne- relatie , omdat de tabel film_texteen veld heeft film_iddatNIETverwijst naar een ID uit een tabel film(geen externe sleutel). Maar door naam en logica zou deze verbinding moeten zijn. Bovendien fungeert film_texthet veld in de tabel film_idals primaire sleutel, wat garandeert dat één "film" overeenkomt met niet meer dan één "filmtekst".
   • Laten we nu eens kijken naar tabellen filmen category. Logischerwijs kan een film meerdere categorieën hebben. En één categorie, misschien verschillende films. Bovendien is er een tussenliggende koppelingstabel tussen deze twee tabellen film_category. Op basis van al het bovenstaande is dit een expliciete ManyToMany- relatie .
   • We bekijken de tabellen filmen language. Vanuit logisch oogpunt kan de film een ​​vertaling in verschillende talen hebben en kunnen verschillende films in dezelfde taal zijn. Dat wil zeggen, ManyToMany suggereert zichzelf . Maar als we naar de inhoud van de tabel kijken film, kunnen we zien dat elke rij van de tabel een unieke film is. En er is slechts één language_id- veld in de regel (er is ook original_language_id, maar in alle records is het null, dus we kunnen het negeren). Dat wil zeggen, één film kan maar één taal hebben. En één taal, misschien verschillende films. De verbinding is ManyToOne (de verbinding is gericht van film naar taal).
5. Nu is de belangrijkste taak om alle benodigde entiteitsklassen te maken en deze toe te wijzen aan de schematabellen movie.
6. Voeg een methode toe die een nieuwe klant (klantentabel) kan maken met alle afhankelijke velden. Vergeet niet om de methode transactioneel te maken (om niet in de situatie te komen dat het adres van de koper wel in de database staat, maar de koper zelf niet).
7. Voeg een transactiemethode toe die de gebeurtenis 'klant ging en bracht een eerder gehuurde film terug' beschrijft. Kies een koper- en verhuurevenement naar keuze. De waardering van de film hoeft niet herberekend te worden.
8. Voeg een transactiemethode toe die de gebeurtenis beschrijft “de koper ging naar de winkel (winkel) en huurde (verhuur) inventaris (inventaris) daar. Tegelijkertijd deed hij een betaling (betaling) aan de verkoper (personeel). Film (via inventaris) naar eigen goeddunken kiezen. De enige beperking is dat de film te huur moet zijn. Dat wil zeggen, er zouden helemaal geen inventarisgegevens moeten zijn in verhuur, of de kolom Return_date van de tabel rentalvoor de laatste verhuur van deze inventaris moet zijn gevuld.
9. Voeg een transactiemethode toe die de gebeurtenis beschrijft "er is een nieuwe film opgenomen en deze is beschikbaar gesteld voor verhuur". Film, taal, acteurs, categorieën, enz., kies naar eigen goeddunken.
10. De tabelstructuur kan niet worden gewijzigd. Maar u moet suggesties voor verbetering doen. We identificeerden één problematische plaats in paragraaf 4 (afwezigheid van externe sleutel in de tabel film_textop het film_idtabelveld film). Kijk of er nog van dergelijke “blunders” in de databasestructuur zitten. Zo ja, voeg dan een leesmij-bestand toe aan de hoofdmap van het project en beschrijf deze blunders.

Projectanalyse:

• Deel 1
• Deel 2
• Deel 3