1. Alkuperäisen asiakirjan ja yksikön välinen suhde
Se voi olla yksi yhteen, yksi moneen ja monen suhde. Yleisesti ottaen ne ovat yksi-yhteen -suhteita: eli kaksi alkuperäistä asiakirjaa
pitäisi ja vastaa vain yhtä entiteettiä. Erityistapauksissa ne voivat olla yksi-monen tai monen yhteen -suhteita, eli yksi alkuperäinen asiakirja vastaa useita todellisuuksia
runko tai useita alkuperäisiä asiakirjoja, jotka vastaavat yhtä entiteettiä. Tässä oleva entiteetti voidaan ymmärtää perustaulukkona. Kun tämä vastaavuus on selvennetty, suunnittele meille
Sisäänkäyntikäyttöliittymä on erittäin hyödyllinen.
〖Esimerkki 1〗: Työntekijän ansioluettelotiedot vastaavat kolmea perustaulukkoa henkilöstötietojärjestelmässä: työntekijän perustietotaulukko ja yhteiskunta
Parisuhdetaulukko, työansioluettelolomake. Tämä on tyypillinen esimerkki siitä, että "yksi alkuperäinen asiakirja vastaa useita entiteettejä".
2. Pää- ja vierasavaimet
Yleisesti ottaen entiteetillä ei voi olla ensisijaista eikä vierasta avainta. E-R-diagrammissa lehtiosan entiteetit voivat määritellä ensisijaisen avaimen,
On myös mahdollista, ettei ensisijaista avainta voi määritellä (koska sillä ei ole lapsia), mutta sillä täytyy olla vierasavain (koska sillä on isä).
Ensisijaisten ja vierasavainten suunnittelulla on tärkeä rooli globaalien tietokantojen suunnittelussa. Kun globaalin tietokannan suunnittelu on valmis, on
Amerikkalaiset tietokantasuunnittelun asiantuntijat sanoivat: "Avaimia, avaimia kaikkialla, pelkkiä avaimia", tämä on hänen tietokantasuunnittelukokemuksensa
Se heijastaa myös hänen erittäin abstrakteja ajatuksiaan tietojärjestelmien (datamallien) ytimestä. Koska: ensisijainen avain on hyvin abstrakti entiteetti, ja primaariavain liittyy
Pari vieraita avaimia, jotka edustavat yhteyttä entiteettien välillä.
3. Perustaulukon luonne
Perustaulukko eroaa väli- ja väliaikaisesta taulukosta, koska sillä on seuraavat neljä ominaisuutta:
(1) Atomisuus. Pohjataulukon kentät eivät ole enää hajotettavia.
(2) Alkeellisuus. Perustaulukon tietueet ovat alkuperäisten tietojen (taustalla olevan datan) tietueita.
(3) Deduktiivinen. Kaikki lähtödata voidaan johtaa perustaulukon ja kooditaulukon datasta.
(4) Vakaus. Perustaulukon rakenne on suhteellisen vakaa, ja taulukon tietueita tulisi säilyttää pitkään.
Kun perustaulujen luonne on ymmärretty, tietokantoja suunnitellessa perustaulukot voidaan erottaa välitauluista ja väliaikaisista tauluista.
4. Paradigman standardit
Perustaulukon ja sen kenttien välisen suhteen tulisi täyttää mahdollisimman paljon kolmatta paradigmaa. Kuitenkin kolmannen paradigman täyttävät tietokantasuunnitelmat eivät usein ole
Paras suunnittelu. Tietokantojen operatiivisen tehokkuuden parantamiseksi on usein tarpeen vähentää paradigman standardia: lisätä asianmukaisesti redundanssia, jotta aikatilaa saadaan
Tarkoitus.
Esimerkki 2: On olemassa perustaulukko tavaroiden säilytykseen, kuten taulukossa 1 on esitetty. "Summa"-kentän läsnäolo osoittaa, että taulukko ei ole suunniteltu täytettäväksi
Kolmas paradigma riittää, koska "määrä" voidaan saada kertomalla "yksikköhinta" "määrällä", mikä osoittaa, että "määrä" on tarpeeton kenttä. Kuitenkin, kasvu
Redundantti kenttä "määrä" voi parantaa kyselytilastojen nopeutta, eli tilan vaihtoa aikaan.
Rose 2002:ssa on kahta tyyppiä määrättyjä sarakkeita: datasarakkeita ja laskettuja sarakkeita. Saraketta kuten "summa" kutsutaan "laskentasarakkeeksi", ja
Sarakkeita kuten "Yksikköhinta" ja "Määrä" kutsutaan "datasarakkeiksi".
Taulukko 1 Hyödyketaulukon taulukkorakenne
Tuotteen nimi Tuotemalli Yksikköhinta Määrä Summa
TV 29 tuumaa 2 500 40 100 000
5. Ymmärrä kolme paradigmaa tavallisella kielellä
Kolmen paradigman ymmärtäminen yksinkertaisella kielellä on suuri etu tietokantasuunnittelulle. Tietokantasuunnittelussa, jotta kolmea paradigmaa voitaisiin soveltaa paremmin,
Kolme paradigmaa on ymmärrettävä tavallisella kielellä:
Ensimmäinen paradigma: 1NF on attribuuttien atomirajoite, joka vaatii attribuuttien olevan atomisia eikä niitä voi enää hajottaa;
Toinen paradigma: 2NF on yksilöllisyysrajoite tietueille, joka vaatii tietueilla yksilöllistä tunnistetta, eli entiteettiä;
Paradigma 3: 3NF on rajoite kenttien redundanssille, eli mikään kenttä ei voi johtaa muista kentistä, vaan vaatii, että kenttä ei ole redundantti
。
Mikään redundantti tietokantasuunnittelu ei pysty siihen. Kuitenkin tietokanta ilman redundanssia ei välttämättä ole paras tietokanta, joskus onnen parantamiseksi
Tehokkuuden saavuttamiseksi on tarpeen alentaa paradigmastandardia ja säilyttää tarpeeton data asianmukaisesti. Erityinen lähestymistapa on noudattaa kolmatta paradigmaa konseptuaalisia datamalleja suunniteltaessa
, paradigman standardin alentamista tarkastellaan fyysisen datamallin suunnittelussa. Paradigman laskeminen tarkoittaa kenttien lisäämistä, jotka mahdollistavat redundanssin.
6. Ole hyvä tunnistamaan ja käsittelemään monen suhteen oikein
Jos kahden yksikön välillä on monen-moneen -suhde, suhde tulisi poistaa. Tapa poistaa se on lisätä kolmasreaali näiden kahden väliin
Keho. Näin se, mikä ennen oli monesta moneen, on nyt muuttunut kahdeksi yksi-moneen -suhteeksi. Alkuperäisten kahden entiteettien attribuutit tulisi jakautua kohtuullisesti
Mene kolmen olennon luo. Kolmas entiteetti tässä on pohjimmiltaan monimutkaisempi suhde, joka vastaa perustaulukkoa. Yleisesti ottaen numerot
Kirjaston suunnittelutyökalu ei tunnista monen-moneen -suhteita, mutta se pystyy käsittelemään moni-moneen -suhteita.
Esimerkki 3: "Kirjaston tietojärjestelmässä" "kirja" on entiteetti, ja "lukija" on myös entiteetti. Nämä kaksi entiteettiä ovat sama asia
Kirjojen välinen suhde on tyypillinen monen-moneen -suhde: kirjan voi lainata useampi lukija eri aikoina, ja yksi lukija voi lainata lisää
Tämä kirja. Tätä varten näiden kahden väliin tulisi lisätä kolmas tahto, jota kutsutaan "lainaavaksi ja palautetuksi kirjaksi", ja sen ominaisuuksia ovat: lainausaika ja lainanotto
Siinä on myös logo (0 tarkoittaa kirjan lainaamista, 1 kirjan palauttamista), lisäksi siinä tulisi olla kaksi vierasnäppäintä (pääavain sanasta "book" ja pääavain sanasta "reader"), joten
Se yhdistyy "kirjoihin" ja "lukijoihin".
7. Ensisijaisen avaimen PK arvomenetelmä
PK on ohjelmoijille suunnattu taulukkojen välinen yhteystyökalu, joka voi olla numeromerkkijono, jolla ei ole fyysistä merkitystä ja jonka ohjelma automaattisesti lisää numeroon 1. Kyllä
on fyysisesti merkityksellinen kenttänimi tai yhdistelmä kenttänimiä. Mutta edellinen on parempi kuin jälkimmäinen. Kun PK on yhdistelmä kenttien nimiä, ehdota kenttänumeroa
Älä laske liikaa, sillä indeksi ei ainoastaan vie paljon tilaa, vaan hidastaa myös tahtia.
8. Varmista datan redundanssi oikein
Ensisijaisten ja vierasavainten toisto useissa taulukoissa ei ole datan redundanssin käsite, eikä moni ole siitä tietoinen
。 Ei-avainkenttien toistuminen on datan redundanssia! Se on matalan tason redundanssi, eli toistuva redundanssi. Edistynyt redundanssi ei ole kenttäpohjaista
Toistuvasti, mutta kenttäjohdannaisina.
Esimerkki 4: Tuotteessa kolme kenttää: "yksikköhinta, määrä ja määrä", "määrä" johdetaan "yksikköhinta" kerrottuna "määrällä"
Se on redundanssia, ja eräänlaista edistynyttä redundanssia. Redundanssin tarkoitus on lisätä prosessointinopeutta. Vain matalan tason redundanssi kasvattaa määrää
Tietojen epäjohdonmukaisuus, koska samaa dataa voidaan syöttää useita kertoja eri ajoista, paikoista ja rooleista. Siksi kannatamme edistynyttä redundanssia (piirakka
redundanssia luonteeltaan), ja vastustaa matalan tason redundanssia (toistuvaa redundanssia).
9. E--R-diagrammeille ei ole olemassa vakiintunutta vastausta
Tietojärjestelmän E--R-kaavioon ei ole olemassa vakiintunutta vastausta, koska sen suunnittelu- ja piirustusmenetelmät eivät ole ainutlaatuisia, kunhan se kattaa järjestelmän vaatiman liiketoiminnan
Laajuus ja toiminnallinen sisältö ovat toteuttamiskelpoisia. Sen sijaan on tarpeen muokata E--R-diagrammia. Vaikka sillä ei ole yhtä vakiintunutta vastausta, se ei tarkoita, että se voisi olla mielivaltainen
Suunnittelu. Hyvän E-R-diagrammin kriteerit ovat: selkeä rakenne, tiivis assosiaatio, kohtuullinen määrä entiteettejä, kohtuullinen attribuuttien allokaatio ja ei matalan tason redundanssia.
10. Näkymätekniikat ovat hyödyllisiä tietokantasuunnittelussa
Toisin kuin perustaulut, kooditaulukot ja välitaulut, näkymät ovat virtuaalisia taulukoita, jotka riippuvat tietolähteen todellisista tauluista. Näkymät ovat ohjelmoijille
Tietokantaa hyödyntävä ikkuna on perustaulukon datan synteesin muoto, tietojenkäsittelymenetelmä ja eräänlainen käyttäjätietojen luottamuksellisuus
tarkoittaa. Monimutkaisen prosessoinnin suorittamiseksi, laskentanopeuden lisäämiseksi ja tallennustilan säästämiseksi näkymän määrittelysyvyyden ei yleensä tulisi ylittää kolmea kerrosta. Kolme kerrosta
Jos näkymä ei vieläkään riitä, sinun tulisi määritellä väliaikainen taulukko näkymälle ja sitten määritellä näkymä väliaikaiseen taulukkoon. Näin näkymän syvyys määritellään toistuvasti
Ei rajoituksia.
Tietyille kansallisiin poliittisiin, taloudellisiin, teknologisiin, sotilaallisiin ja turvallisuusintresseihin, liittyvien tietojärjestelmien osalta näkemysten rooli on vieläkin tärkeämpi. Nämä
Kun järjestelmän perustaulukon fyysinen suunnittelu on valmis, ensimmäinen näkymäkerros muodostuu välittömästi perustaulukolle, ja tämän kerrosnäkymän lukumäärä ja rakenne ovat samat kuin perustaulukossa
Luku ja rakenne ovat täsmälleen samat. Ja on määrätty, että kaikki ohjelmoijat saavat toimia vain näkymällä. Vain tietokantaylläpitäjä, jolla
Useamman henkilön hallussa oleva "turvaavain" voidaan käyttää suoraan peruspöydällä. Lukijoita kutsutaan pohtimaan: miksi näin on?
11. Välitaulut, lauseet ja väliaikaiset taulukot
Välitaulukko on taulukko, joka tallentaa tilastoja, se on suunniteltu tietovarastointiin, tulosraportteihin tai kyselytuloksiin, ja joskus sillä ei ole ensisijaista avainta
vieraat avaimet (paitsi tietovarastot). Väliaikaiset taulukot suunnitellaan ohjelmoijien toimesta tallentamaan väliaikaisia tietoja henkilökohtaiseen käyttöön. Perus- ja välitaulukot ylläpitää DBA
Väliaikaisia taulukoita ylläpitää automaattisesti ohjelmoija itse.
12. Rehellisyyden rajoitteet ilmenevät kolmessa osa-alueessa
Toimialueen eheys: Käytä Checkiä rajoitteiden toteuttamiseen, ja tietokantasuunnittelutyökalussa kentän arvoalueen määrittelyssä on Ch
eck-painike, jonka kautta kentän arvokaupunki määritellään.
Referenttiaalinen eheys: Toteutettu PK-, FK- ja taulukkotason laukaisimilla.
Käyttäjän määrittelemä eheys: Se on liiketoimintasääntöjä, jotka toteutetaan tallennettujen proseduurien ja laukaisimien avulla.
13. Menetelmä tietokantasuunnittelun korjausten estämiseksi on "kolme vähemmän" periaatetta
(1) Mitä vähemmän taulukoita tietokannassa, sitä parempi. Vain jos taulujen määrää vähennetään, voidaan sanoa, että järjestelmän E-R-diagrammi on pieni ja hieno, ja se poistetaan
Kaksois- ja redundantit entiteot muodostavat korkean abstraktion objektin maailmasta, ja systemaattinen dataintegraatio toteutetaan korjausten estämiseksi;
(2) Mitä vähemmän kenttiä taulukossa, jotka yhdistävät ensisijaiset avaimet, sitä parempi. Ensisijaisen avaimen roolin vuoksi toinen on rakentaa ensisijainen avainindeksi ja toinen toimii alitaulukkona
vieraiden avainten osalta, jolloin ensisijaisten avainten yhdistelmän kenttien määrä vähenee, mikä säästää paitsi suoritusaikaa myös indeksin tallennustilaa;
(3) Mitä vähemmän kenttiä taulukossa, sitä parempi. Vain pieni määrä kenttiä osoittaa, ettei järjestelmässä ole datan päällekkäisyyttä
Datan redundanssia on vähän, ja mikä tärkeintä, lukijoita kehotetaan oppimaan "rivien vaihtaminen", mikä estää kenttien siirtymisen alitaulukon päätauluun
, jättäen monia vapaita kenttiä päätaulukkoon. Niin sanottu "sarakkeenvaihtorivi" tarkoittaa, että osa päätaulukon sisällöstä poimitaan ja rakennetaan erillinen
Alapöytä. Tämä menetelmä on hyvin yksinkertainen, jotkut eivät vain totu siihen, eivät ota sitä käyttöön eivätkä ota sitä käyttöön.
Tietokantasuunnittelun käytännön periaate on löytää oikea tasapaino datan redundanssin ja prosessointinopeuden välillä. "Kolme vähemmän" on kokonaisvaltainen yleiskatsaus
Ajattelu, kokonaisvaltaiset näkemykset, eivät voi erottaa tiettyä periaatetta. Periaate on suhteellinen, ei absoluuttinen. "Kolme lisää" -periaate on ehdottomasti väärä. Kokeile
Ajattele: Jos sama järjestelmän toiminto on katettu, E--R-diagrammi, jossa on 100 entiteettiä (yhteensä 1 000 attribuuttia) on ehdottomasti parempi kuin E--R-diagrammi, jossa on 200 entiteettiä (yhteensä 2 000 attribuuttia)
E--R-kaavio on paljon parempi.
Periaatteen "kolme vähemmän" puolustaminen antaa lukijoille mahdollisuuden oppia käyttämään tietokantasuunnitteluteknologiaa systemaattiseen datan integrointiin. Datan integraation vaiheet ovat seuraavat:
Tiedostojärjestelmä integroidaan sovellustietokantaan, sovellustietokanta on integroitu aihetietokantaan ja aihetietokanta integroidaan globaaliin kattavaan tietokantaan.
Mitä suurempi integraatioaste, sitä vahvempi tiedonjako on ja sitä vähemmän tiedon saarekkeita on
Ensisijaisten avainten ja attribuuttien määrä on pienempi.
Periaatteen "kolme vähemmän" puolustamisen tarkoituksena on estää lukijoita käyttämästä korjausteknologiaa jatkuvasti tietokannan lisäämiseen, poistamiseen ja muokkaamiseen, jotta yritysdataa saataisiin
Kirjasto on muuttunut "roskakasaksi" mielivaltaisesti suunniteltuja tietokantatauluja tai "sekasotku" tietokantatauluja, ja lopulta aiheuttaa perustaulut ja sukupolvet tietokannassa
Kooditaulukot, välilevyt ja väliaikaiset taulukot ovat täynnä ja lukemattomia, mikä johtaa yritysten ja instituutioiden tietojärjestelmien ylläpidon ja halvaannuttamisen kyvyttömyyteen.
"Kolme lisää" -periaatetta voi toteuttaa kuka tahansa, mikä on "patching-menetelmän" virhepäätelmä tietokantojen suunnittelussa. Periaate "kolme vähemmän"
Se on vähemmän mutta hieno periaate, joka vaatii korkeat tietokantasuunnittelun taidot ja taiteen, mitä kaikki eivät pysty tekemään, koska tämä periaate poistetaan
Teoreettinen perusta tietokannan suunnittelulle "patching-menetelmällä".
14. Tapoja parantaa tietokannan toiminnan tehokkuutta
Annetuissa järjestelmän laitteisto- ja ohjelmistoolosuhteissa menetelmät tietokantajärjestelmän toiminnan tehokkuuden parantamiseksi ovat:
(1) Tietokannan fyysisessä suunnittelussa vähentää paradigmaa, lisätä redundanssia, käyttää vähemmän laukaisijoita ja käyttää enemmän tallennettuja menettelyjä.
(2) Kun laskenta on hyvin monimutkainen ja tietueiden määrä on hyvin suuri (esim. 10 miljoonaa), monimutkaisen laskennan on ensin tehtävä tietokannan ulkopuolella
Kun tiedostojärjestelmämenetelmä on laskettu ja käsitelty C++-kielellä, se lisätään lopulta taulukkoon. Tämä on kokemus telekommunikaatiolaskutusjärjestelmän suunnittelusta.
(3) Jos taulukossa todetaan olevan liikaa tietueita, kuten yli 10 miljoonaa, taulukko tulisi jakaa vaakasuunnassa. Vaakasuoran segmentoinnin käytäntö on:
Jaa taulukon tietue vaakasuunnassa kahteen taulukkoon tietyn pääavaimen PK arvon perusteella. Jos taulukossa todetaan olevan liikaa kenttiä, kuten ylittäviä
Kahdeksankymmentä, taulukko on jaettu pystysuunnassa, ja alkuperäinen taulukko on jaettu kahteen taulukkoon.
(4) Tietokannan hallintajärjestelmän DBMS:n järjestelmän optimointi, eli eri järjestelmäparametrien, kuten puskurien määrän, optimointi.
(5) Kun käytät datapohjaista SQL-kieltä ohjelmoinnissa, pyri ottamaan käyttöön optimointialgoritmeja.
Lyhyesti sanottuna, tietokannan toiminnan tehokkuuden parantamiseksi on tarpeen optimoida tietokantajärjestelmä, tietokantasuunnittelu ja ohjelman toteutus
, nämä kolme tasoa tekevät kovasti töitä samaan aikaan.
Yllä mainitut neljätoista taitoa tiivistetään vähitellen monien ihmisten toimesta laajassa määrässä tietokanta-analyysi- ja suunnittelukäytäntöjä. Näistä kokemuksista
Lukijoiden ei tulisi olla jäykkiä tai ulkomaisia, vaan heidän tulisi sulattaa ja ymmärtää, etsiä totuutta faktoista ja hallita joustavasti. Ja vähitellen: lähetä hakemus
näyttely, sovellus kehityksessä.
|
Julkaistu 9.4.2015 21.00.54
|
|
|
