Tietokannassa on yksi suhde moniin suhteisiin, kun taulukossa A olevilla tietueilla voi olla useita linkitettyjä tietueita taulukossa B, mutta taulukossa B olevilla jokaisella tietueella voi olla vain yksi vastaava tietue taulukossa A. Yksittäinen suhde tietokanta on yleisin relaatiotietokannan suunnittelu ja se on hyvän suunnittelun ydin.
Tarkastellaan opettajan ja heidän opettajiensa välistä suhdetta. Opettaja voi opettaa useita kursseja, mutta kurssilla ei olisi samaa suhdetta opettajaan.
Siksi Opettajat-taulukossa jokaiselle tietueelle kursseja koskevassa taulukossa voi olla monia tietueita. Tämä on monen suhde: yksi opettaja useisiin kursseihin.
Miksi monien suhteiden luominen on tärkeää
Yksittäisen suhteen edustamiseksi tarvitset vähintään kaksi taulukkoa. Katsotaanpa miksi.
Ehkä me luotiin Teachers-taulukko, jossa halusimme tallentaa nimi ja kurssit. Voisimme suunnitella sen seuraavasti:
Teacher_ID | Opettajan nimi | kurssi |
---|---|---|
Teacher_001 | carmen | Biologia |
Teacher_002 | Veronica | Matematiikka |
Teacher_003 | Jorge | Englanti |
Entä jos Carmen opettaa kahta tai useampaa kurssia? Meillä on kaksi vaihtoehtoa tämän mallin kanssa. Voisimme vain lisätä sen Carmenin nykyiseen tietueeseen, kuten:
Teacher_ID | Opettaja _nimi | kurssi |
---|---|---|
Teacher_001 | carmen | Biologia, Matematiikka |
Teacher_002 | Veronica | Matematiikka |
Teacher_003 | Jorge | Englanti |
Yllä oleva malli on kuitenkin joustamaton ja voi aiheuttaa ongelmia myöhemmin, kun yrittää lisätä, muokata tai poistaa tietoja.
Tietojen etsiminen vaikeuttaa. Tämä malli rikkoo tietokannan normalisoinnin ensimmäistä periaatetta, First Normal Form (1NF) , jossa todetaan, että jokaisen taulukon solun tulisi sisältää yksi, erillinen tieto.
Toinen suunnitteluvaihtoehtona voisi olla yksinkertaisesti lisätä toinen levy Carmenille:
Opettaja _ID | Opettaja _nimi | kurssi |
---|---|---|
Teacher_001 | carmen | Biologia |
Teacher_001 | carmen | Matematiikka |
Teacher_002 | Veronica | Matematiikka |
Teacher_003 | Jorge | Englanti |
Tämä noudattaa 1NF mutta on edelleen huono tietokannan suunnittelu, koska se tuo redundanssia ja voi paisuttaa hyvin suurta tietokantaa tarpeettomasti. Vielä tärkeämpää on, että tiedot saattavat olla epäyhtenäisiä. Esimerkiksi, jos Carmenin nimi muuttui? Joku, joka työskentelee tietojen kanssa, saattaa päivittää nimensä yhteen tietueeseen eikä päivitä sitä toisessa tietueessa. Tämä malli rikkoo toisen normaalimuodon (2NF), joka tarttuu 1 NF: ään, ja sen on myös vältettävä useita tietueiden irtisanomisia erottamalla tietoryhmät useisiin taulukoihin ja luomalla niiden välinen suhde.
Tietokannan suunnittelu tietokannoilla, joilla on monta suhdetta
Yhden ja usean suhteen toteuttamiseksi Opettajat ja kurssit -taulukossa, ristisimme taulukoita kahteen ja linkitimme ne ulkomaisen avaimen avulla .
Tässä olemme poistaneet kurssin sarakkeen Opettajat-taulukossa:
Opettaja _ID | Opettaja _nimi |
---|---|
Teacher_001 | carmen |
Teacher_002 | Veronica |
Teacher_003 | Jorge |
Ja tässä on kursseja koskeva taulukko. Huomaa, että sen vieraan avaimen, Teacher_ID, linkittää kurssin opettajalle Teachers-taulukossa:
Course_ID | Kurssin nimi | Teacher_ID |
---|---|---|
Course_001 | Biologia | Teacher_001 |
Course_002 | Matematiikka | Teacher_001 |
Course_003 | Englanti | Teacher_003 |
Olemme kehittäneet suhdetta opettajien ja kurssit-taulukon välityksellä ulkomaisen avaimen avulla.
Tämä kertoo, että sekä Biologia että matematiikka opettaa Carmen ja että Jorge opettaa englantia.
Voimme nähdä, miten tämä muotoilu välttää mahdolliset irtisanomiset, antaa yksittäisille opettajille mahdollisuuden opettaa useita kursseja ja toteuttaa yhden suhde.
Tietokannat voivat myös toteuttaa yhden suhde ja monien suhde.