tietokannan rakennuspalikoiden ymmärtäminen SQL Server

Like This Blog 3

lisätty Peter Avila marraskuu 21, 2012

jokaisessa talossa on keittiö, vähintään yksi kylpyhuone ja makuuhuone, ulko-ovi, putkisto ja muuta. Nämä asiat voidaan järjestää eri tavoin ja eri numeroin eri talojen tuottamiseksi. Niin on tietokantojen kanssa. On tiettyjä asioita, että kaikki tietokannat on yhteistä. Tässä viestissä esittelen rakennuspalikoita, jotka muodostavat kaikki tietokannat ja osoittavat, miten ne kootaan. Käsittelen myös kolmea sääntöä, joita on noudatettava rakennuspalikoita käytettäessä.

tässä viestissä esitetyn aineiston pitäisi olla arvokasta kaikille, joilla on minkäänlaista vuorovaikutusta tietokantojen kanssa, mutta se on hyvin alkeellisella tasolla. Kattavampaa keskustelua tietokannan suunnittelu, katso minun artikkeli, intuitiivinen lähestymistapa tietokannan suunnittelu.

Minimaailmat.

ennen kuin päästään rakennuspalikoihin, mietitään hetki termin Minimaailma ymmärtämistä, koska se auttaa ymmärtämään rakennuspalikoita.

tietokanta on pienoismaailman malli. Minimaailma voi olla esimerkiksi lääkäritoimisto, vähittäiskauppa, kirjasto tai monia muita asioita. Kun haluamme tietoa minimaailmasta, käännymme sitä mallintavan tietokannan puoleen.

sanotaan, että mennään lääkäriin ajanvaraukseen. Kun kerrot vastaanottovirkailijalle, että sinulla on aika, vastaanottovirkailija yrittää löytää ajanvarauksesi mallista (tietokannasta). Jos malli on pidetty minimaailmoineen ajan tasalla, sen pitäisi pystyä vahvistamaan, että sinulla on aika. Samoin, jos yritys haluaa tietää, kuka heidän korkean volyymin asiakkaat eivät ole tehneet tilauksia viimeisten 6 kuukauden aikana, he voivat kääntyä malli heidän mini-maailma, jos se on pidetty ajan tasalla, että mini-maailma.

Minimaailma voi olla kokonainen yritys, tai se voi olla osa liiketoimintaa, kuten pankkikonttori tai myyntiosasto.

ensimmäinen asia, jonka tietokantasuunnittelija tekee, on ymmärtää Minimaailma, koska suunnittelijan tehtävänä on suunnitella pienoismalli tuosta minimaailmasta. Ja ymmärtääkseen minimaailmaa, suunnittelija aloittaa tunnistamalla ne rakennuspalikat, jotka menevät tietokannan kokoamiseen.

Rakennuspalikat

1. Entiteetit

Olio on minimaailmassa olemassa oleva olio, jolla on meitä kiinnostavia ominaisuuksia. Esimerkiksi koulurekisteröinnin minimaailmassa on opiskelijakokonaisuuksia, kurssikokonaisuuksia, ohjaajakokonaisuuksia ynnä muita. Opiskelijoilla on nimet, osoitteet, GPA, ja muita ominaisuuksia, jotka kiinnostavat meitä. Kurssit ovat otsikot, opintopisteet, maksut, ja muut. Ja ohjaajilla on nimet, osoitteet, pätevyydet ja muut. Kokonaisuudet ovat ainutlaatuisia. Jokainen opiskelija on ainutlaatuinen kokonaisuus; on John ja Mary ja niin edelleen. Jokainen kurssi on ainutlaatuinen kokonaisuus ja jokainen ohjaaja on ainutlaatuinen kokonaisuus.

entiteettien ei tarvitse olla fyysisiä asioita. Vaikka et voi koskettaa, nähdä tai haistaa ilmoittautumista, se on kuitenkin olemassa koulun ilmoittautumisen minimaailmassa ja sillä on ominaisuuksia, jotka kiinnostavat meitä, kuten ilmoittautumispäivä, opiskelija, joka ilmoittautui, kurssi opiskelija ilmoittautui, ja viimeinen arvosana sai. Myynti on muita esimerkkejä yhteisöistä, joilla ei ole fyysistä komponenttia, mutta joilla on meitä kiinnostavia ominaisuuksia (myyntipäivä, asiakas, myyjä, tilauksen loppusumma, lähetystapa, maksuehdot jne.).

2. Yhteisö-tyypit

samantyyppiset yhteisöt kuuluvat yhteen yhteisö-tyyppiin. Entiteettityyppi on joukko tämän tyyppisiä entiteettejä. Opiskelijayksikkö-tyyppi on kaikkien opiskelijoiden joukko. Kurssi entity-tyyppi on joukko Kaikki kurssit, ja ohjaaja entity-tyyppi on joukko kaikkien ohjaajien.

Entiteettityypit ovat tämän viran tärkein käsite. Niistä tulee taulukoita tietokannassa.

3. Attribuutit

yhteisön attribuutit ovat kyseisen yhteisön ominaisuuksia, jotka kiinnostavat meitä. Kuten jo mainittiin, opiskelijoiden ominaisuuksia ovat nimi, osoite, GPA, ja muut. Kursseilla on nimet, opintopisteet, osastot, joihin ne kuuluvat, ja muut. Ja niin edelleen muiden entiteettien kanssa.

rakennuspalikoiden kokoaminen

miten nämä rakennuspalikat esitetään tietokannassa? Jokainen entiteettityyppi esitetään tietokannassa olevalla taulukolla. Tässä taulukossa yksittäiset rivit ovat ainutlaatuisia entiteettejä ja sarakkeet attribuutteja. Tässä on esimerkki taulukosta, joka edustaa luottokortti entity-tyyppi:

Building Block Rules

building Block Rules

kun työskentelet rakennuspalikoiden kanssa, on tärkeää noudattaa tiettyjä sääntöjä, jotka eivät ainoastaan helpota työskentelyä tietokantaobjektien kanssa, vaan myös estävät tietojen poikkeavuudet (data anomalies are beyond the scope of this post but are discipled in detail in my article, an intuitiivinen Approach to Database Design).

Sääntö 1: jokaisen taulukon tulee edustaa yhtä ja vain yhtä entiteettityyppiä.

yllä olevaan kouluun ilmoittautuneiden minimaailman tietokantaan tarvitaan seuraavat taulukot: Opiskelija, kurssi, ohjaaja, Ilmoittautuminen ja muut, yksi jokaista entiteettityyppiä kohti, joka on tunnistettu tuossa minimaailmassa. Lääkäritoimiston minimaailman tietokanta tarvitsee muun muassa Lääkäripöydän, Potilaspöydän, Ajanvarauspöydän ja Lääkepöydän. Yksi taulukko kutakin entiteettityyppiä kohti.

tästä säännöstä on poikkeus. Valmistautukaa, täältä tulee pyörremyrsky.: Jos kahdella yhteisötyypillä on samat ominaisuudet ja yhteen yhteisötyyppiin kuuluva yhteisö on myös toiseen yhteisötyyppiin kuuluva yhteisö (toinen yhteisö on molempien yhteisötyyppien jäsen), nämä kaksi yhteisötyyppiä voidaan esittää yhdessä taulukossa. Tässä se taas on: professori entity-tyyppi ja neuvonantaja entity-tyyppi voidaan molemmat esittää yhdessä taulukossa, koska neuvonantajat ovat myös professoreita ja niillä on samat ominaisuudet (professori/neuvonantaja nimi, professori/neuvonantaja pätevyys, ja muut). Ja taas: Kansioyksikkö-tyyppi ja Alikansioyksikkö – tyyppi voidaan esittää yhdessä taulukossa, koska kaikki Alikansioyksiköt ovat myös Kansioyksiköitä ja niillä on samat attribuutit (kansion otsikko, kansion koko, kansion kohteiden lukumäärä, yläkansio ja muut). Vielä yksi: työntekijä-ja Esimiesyhteisötyypit voidaan esittää samassa taulukossa, koska työntekijöillä ja esimiesyhteisöillä on samat ominaisuudet ja esimiesyhteisöt ovat myös henkilöstöyhteisöjä. Tätä poikkeusta sääntöön tarkastellaan tarkemmin toisessa blogissa: SQL Server-The Self Join Query.

huomaa muuten, että tämän säännön takia oikea tapa nimetä taulukko on yksikössä. Taulukot edustavat yhtä kokonaisuutta.

Sääntö 2: kaikkien sarakkeiden on oltava atomisia.

Oletko koskaan miettinyt, miksi tietokantataulukoissa voi olla sarakkeita kaupungille ja valtiolle, mutta vain yksi sarake osoitteelle? Ehkä olet miettinyt, miksi ei ole saraketta Osoitenumero, toinen osoite Street Tyyppi (Blvd., Avenue jne.), toinen asunnon numero, ja niin edelleen. Miksi nämä sarakkeet yleensä niputetaan yhteen yhteen Osoitesarakkeeseen? Vastaus kaikkiin näihin kysymyksiin on atomisuuden ymmärtäminen.

kun sanomme, että kolonni on atominen, tarkoitamme, että sitä ei voida jakaa edelleen ja säilyttää silti merkitys. Tehdään palsta ja kutsutaan sitä Megaddressiksi, joka sisältää katuosoitteen yhdessä kaupungin ja valtion kanssa.

But because we do search, lajittelee and other operations on parts of that column (search by city, sort by state, print out just the street address part, and so on), we can say that subdivisions of that column have their own meaning (StreetAddress, City, and State). Megaddress ei siis ole atomic. Parempi pöytä olisi:

now, entäs StreetAddress-sarake? Pitäisikö se jakaa edelleen Katunumeroon, Katunimeen ja Streettityyppiin? Niin kauan kuin emme tee mitään merkittävää osille—jos emme Lajittele katunumeroita, etsi kaikkia teitä tai väyliä, ja niin edelleen—niin sarake on atominen sellaisenaan. Mutta jos teemme näitä asioita, niin kolonni ei ole atominen ja sitten, Kyllä, Meidän pitäisi jakaa se kuvaillulla tavalla.

Sääntö 3: sarakkeet eivät voi olla moniarvoisia.

jotkin entiteettityypit sisältävät moniarvoisia attribuutteja eli attribuutteja, joilla voi olla useampi kuin yksi arvo. Kurssitaulukossa voi olla ominaisuus nimeltä edellytykset. Koska kurssiosuudella voi olla useampi kuin yksi edellytys, Prevention-attribuutti on moniarvoinen attribuutti. Kun luomme taulukon kurssin entiteettityypille, Emme voi esittää Edellytysattribuuttia taulukon sarakkeena. Jotta moniarvoinen ominaisuus olisi kunnolla edustettuna, meidän on luotava sille toinen taulukko ja suhteutettava se alkuperäiseen taulukkoon käyttämällä one-to-many-suhdetta (suhteita käsitellään yksityiskohtaisesti kursseissa, joita opetan Interface Tachnical Training SQL100: ssa: Johdatus Transact-SQL ja SQL250: Transact-SQL kehittäjille ja minun artikkeli, intuitiivinen lähestymistapa tietokannan suunnittelu). Muita esimerkkejä moniarvoisista ominaisuuksista ovat työntekijän huollettavat, lääkärin pätevyys ja niin edelleen.

säännön 3 mukaan tietyllä kokonaisuudella (taulukon rivillä) voi olla vain yksi arvo kussakin sarakkeessa.

Yhteenveto

tässä postauksessa esiteltiin minimaailman käsite yrityksen tai muun ympäristön osa-alueina, joita tietokanta mallintaa. Viestissä kuvailtiin myös tietokantataulukon edustavan yhtä entiteettityyppiä, jossa riveillä on samantyyppisiä yksittäisiä entiteettejä ja sarakkeet edustavat näiden entiteettien attribuutteja. Taulukoita koskevia sääntöjä otettiin käyttöön kolme. Säännön 1 mukaan taulukon olisi edustettava yhtä kokonaisuutta. Poikkeuksena sääntöön on se, että kahdella yhteisötyypillä on samat ominaisuudet ja yhden yhteisötyypin yhteisöt ovat toisen yhteisötyypin jäseniä. Tällöin molemmat entiteettityypit voidaan esittää samassa taulukossa. Säännön 2 mukaan taulukon kaikkien sarakkeiden on oltava atomisia, eli saraketta ei voi jakaa osiin ja säilyttää silti merkityksensä minimaailmassa. Säännön 3 mukaan taulukon sarakkeet eivät voi olla moniarvoisia, mikä tarkoittaa, että tietyllä kokonaisuudella (taulukon rivillä) voi olla vain yksi arvo saraketta kohti.

Enjoy!

Peter Avila

SQL Server Instructor-Interface Technical Training

Phoenix, AZ