CodeGym/Java kursus/All lectures for DA purposes/Relateret projekt: Hibernate (2)

Relateret projekt: Hibernate (2)

All lectures for DA purposes

Niveau, Lektie

Ledig

I dag er vores opgave at færdiggøre det andet projekt om Hibernate-emnet. Dens essens er at forstå strukturen af databasen, kortlægge entiteten til eksisterende tabeller og tilføje minimumsfunktionaliteten for at kontrollere, at kortlægningen er udført korrekt.

Nu mere detaljeret:

Download dump-filen og implementer den på din lokale maskine. Som database vil vi bruge en testdatabase, som distribueres som eksempel sammen med MySQL installationspakken. Dumpet er nødvendigt for at rette databasens tilstand, da vi ikke kan garantere, at den ikke ændrer sig i løbet af en dag, måned, år.
Vi vil ikke have en projektskabelon, så lav selv projektet. Det burde være et maven-projekt med alle nødvendige afhængigheder ( hibernate-core-jakarta , mysql-connector-java , p6spy ).
Tilslut vores lokale implementerede database som en datakilde i Idea. Sæt derefter markøren på filmskemaet på fanen Database og tryk på tastekombinationen Alt+Ctrl+Shift+U(virker kun i Ultimate-versionen). Dette vil vise strukturen af hele filmskemaet (med kolonnenavne, nøgler osv.). Ser sådan ud:
Jeg er enig, det er ikke særlig behageligt at se. Deaktiver visningen af titlen på alle kolonner og kommentarer:

Som et resultat vil du få et databaseskema, der allerede kan analyseres:
Kredsløbet ser kompliceret ud, men ikke alt er så slemt. For at analysere strukturen af databasen skal du finde ud af, hvor du skal starte. Der er ikke et enkelt korrekt svar, men jeg vil anbefale at starte med en tabel film. Lad os tage et par forhold som eksempel:
- Relationen mellem tabeller filmog film_texter en eksplicit OneToOne- relation , fordi tabellen film_texthar et felt, film_idderIKKErefererer til et ID fra en tabel film(ingen fremmednøgle). Men ved navn og logik burde denne forbindelse være. film_textDerudover fungerer feltet i tabellen film_idsom en primær nøgle, hvilket garanterer, at én "film" ikke svarer til mere end én "filmtekst".
- Lad os nu se på tabeller filmog category. Logisk set kan en film have flere kategorier. Og én kategori, måske forskellige film. Derudover er der en mellemliggende linktabel mellem disse to tabeller film_category. Baseret på alt ovenstående er dette et eksplicit ManyToMany- forhold .
- Vi kigger på bordene filmog language. Fra et logisk synspunkt kan filmen have en oversættelse til forskellige sprog, og forskellige film kan være på samme sprog. Det vil sige, ManyToMany foreslår sig selv . Men hvis vi ser på indholdet af tabellen film, kan vi se, at hver række i tabellen er en unik film. Og der er kun ét sprog_id felt i linjen (der er også original_language_id, men i alle poster er det null, så vi kan ignorere det). Det vil sige, at én film kun kan have ét sprog. Og ét sprog, måske forskellige film. Forbindelsen er ManyToOne (forbindelsen er rettet fra film til sprog).
Nu er hovedopgaven at oprette alle de nødvendige entitetsklasser og kortlægge dem på skematabellerne movie.
Tilføj en metode, der kan oprette en ny kunde (kundetabel) med alle afhængige felter. Glem ikke at gøre metoden transaktionel (for ikke at komme i den situation, at køberens adresse er registreret i databasen, men køberen selv er det ikke).
Tilføj en transaktionsmetode, der beskriver hændelsen "kunden gik og returnerede en tidligere lejet film". Vælg enhver køber- og lejebegivenhed efter eget valg. Filmens vurdering skal ikke genberegnes.
Tilføj en transaktionsmetode, der beskriver hændelsen "køberen gik til butikken (butikken) og lejede (leje) inventar (inventar) der. Samtidig foretog han en betaling (betaling) til sælger (personale). Film (gennem inventar) vælg efter dit skøn. Den eneste begrænsning er, at filmen skal kunne lejes. Det vil sige, at der enten ikke skal være nogen lagerposter i leje overhovedet, eller også skal kolonnen return_date i tabellen rentalfor den sidste leje af denne inventar udfyldes.
Tilføj en transaktionsmetode, der beskriver begivenheden "en ny film blev optaget, og den blev tilgængelig til leje." Film, sprog, skuespillere, kategorier osv., vælg efter eget skøn.
Tabelstrukturen kan ikke ændres. Men du skal komme med forslag til forbedringer. Vi identificerede et problematisk sted i afsnit 4 (fravær af fremmednøgle i tabellen film_texti film_idtabelfeltet film). Se, om der stadig er sådanne "fejl" i databasestrukturen. Hvis ja, tilføj en readme-fil til roden af projektet og beskriv disse fejl.