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
film
ogfilm_text
er en eksplicit OneToOne- relation , fordi tabellenfilm_text
har et felt,film_id
derIKKErefererer til et ID fra en tabelfilm
(ingen fremmednøgle). Men ved navn og logik burde denne forbindelse være.film_text
Derudover fungerer feltet i tabellenfilm_id
som en primær nøgle, hvilket garanterer, at én "film" ikke svarer til mere end én "filmtekst". - Lad os nu se på tabeller
film
ogcategory
. Logisk set kan en film have flere kategorier. Og én kategori, måske forskellige film. Derudover er der en mellemliggende linktabel mellem disse to tabellerfilm_category
. Baseret på alt ovenstående er dette et eksplicit ManyToMany- forhold . - Vi kigger på bordene
film
oglanguage
. 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 tabellenfilm
, 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).
- Relationen mellem tabeller
- 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
rental
for 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_text
ifilm_id
tabelfeltetfilm
). 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.
Projektanalyse:
GO TO FULL VERSION