Búa til gagnagrunninn
Ertu tilbúinn til að byrja að búa til gagnagrunna og töflur með uppbyggðu fyrirspurninni ? Í þessari grein skoðar við ferlið við að búa til töflur handvirkt með skipunum SKAPA DATABASE og CREATE TABLE. Ef þú ert nýr í SQL, gætirðu viljað endurskoða greinina í SQL Basics fyrst.
Viðskipti kröfur
Áður en við setjumst niður á lyklaborðinu, þurfum við að tryggja að við höfum traustan skilning á kröfum viðskiptavinarins. Hver er besta leiðin til að fá þessa innsýn? Talandi við viðskiptavininn, auðvitað! Eftir að hafa setið niður með starfsmannastjóra XYZ, höfum við lært að þeir séu búnaður fyrir búnaður fyrir búnað og eru fyrst og fremst áhuga á að rekja upplýsingar um sölufólk sitt.
XYZ Corporation skiptir sölumann sinn í Austur-og Vesturland, hver er skipt í mörg svæði sem einstakir sölumenn taka til. HR deildin vill fylgjast með yfirráðasvæðinu sem hver starfsmaður tekur til, ásamt launagögnum hverrar starfsmanns og eftirlitsskipulag. Til að uppfylla þessar kröfur höfum við hannað gagnagrunn sem samanstendur af þremur borðum, sýndar í Entity-Relationship skýringarmyndinni á þessari síðu.
Velja gagnasafn pallur
Við höfum ákveðið að nota gagnagrunnsstjórnunarkerfi (eða DBMS) sem er byggt á uppbyggðu fyrirspurninni (SQL). Þess vegna ber að skrifa allar gagnagrunns- og töflusköpunina með venjulegu ANSI SQL í huga.
Sem viðbótarbætur, með því að nota ANSI-samhæft SQL, mun þessi skipanir vinna á hvaða DBMS sem styður SQL staðalinn , þar á meðal Oracle og Microsoft SQL Server. Ef þú hefur ekki valið vettvang fyrir gagnagrunninn þinn, þá færðu greinasafnið hugbúnaðarvalkostir í gegnum valferlið.
Búa til gagnagrunninn
Fyrsta skrefið okkar er að búa til gagnagrunninn sjálfan. Margir gagnasafnsstjórnunarkerfi bjóða upp á ýmsa möguleika til að sérsníða gagnagrunnsstika við þetta skref, en gagnagrunnur okkar leyfir aðeins einföldu stofnun gagnagrunns. Eins og við öll skipanir okkar gætirðu viljað hafa samráð við skjölin fyrir DBMS til að ákvarða hvort háþróaðar breytur sem studd eru af sérstökum kerfum þínum uppfylli þarfir þínar. Við skulum nota CREATE DATABASE stjórnina til að setja upp gagnagrunninn okkar:
Búðu til DATABASE starfsfólk Taktu sérstaka athygli á hástöfum sem notuð eru í dæminu hér fyrir ofan. Það er algengt meðal SQL forritara að nota öll hástafir fyrir SQL leitarorð eins og "CREATE" og "DATABASE" meðan allir lágstafir eru notaðir til notenda sem eru skilgreindir eins og nafnið "starfsfólk". Þessar samþykktir kveða á um að auðvelt sé að lesa.
Haltu áfram að lesa þessa einkatími þegar við búum til töflur fyrir gagnagrunninn okkar.
Læra meira
Ef þú vilt læra meira um uppbyggða fyrirspurnarmálið skaltu lesa Inngangur að SQL eða skráðu þig fyrir ókeypis námskeiðið Nám SQL e-mail.
Nú þegar við höfum hannað og búið til gagnagrunninn okkar, erum við tilbúin til að byrja að búa til þrjá töflurnar sem notaðar eru til að geyma starfsmannagögn XYZ Corporation. Við munum framkvæma töflurnar sem við hönnuðum í fyrri hluta þessa kennslu.
Búa til fyrstu töflu okkar
Fyrsta borð okkar samanstendur af persónulegum gögnum fyrir hvern starfsmann fyrirtækisins. Við þurfum að innihalda nafn hvers starfsmanns, laun, auðkenni og framkvæmdastjóri. Það er gott hönnun aðferðir til að aðskilja síðasta og fyrstu nöfnin í aðskildum reitum til að einfalda gögnaleit og flokka í framtíðinni. Einnig munum við fylgjast með framkvæmdastjóri hvers starfsmanns með því að setja tilvísun í starfsmennskírteini framkvæmdastjóra í hverjum starfsmannaskrá. Skulum fyrst líta á viðkomandi starfsmannatöflu.
SkýrslanEð eiginleiki geymir kerfisstjóraauðkenni fyrir hvern starfsmann. Frá sýnishornaskrám sýndar getum við ákveðið að Sue Scampi er framkvæmdastjóri bæði Tom Kendall og John Smith. Hins vegar eru engar upplýsingar í gagnagrunninum á stjórnanda Sue, eins og fram kemur með NULL færslunni í röðinni.
Nú getum við notað SQL til að búa til töfluna í starfsfólki gagnagrunninum okkar. Áður en við gerum það, skulum við tryggja að við séum í rétta gagnagrunninum með því að gefa út USE stjórn:
Að öðrum kosti, "DATABASE starfsfólk;" stjórn myndi framkvæma sömu virkni. Nú getum við kíkið á SQL skipunina sem notuð er til að búa til starfsmannatafla okkar:
CREATE TABLE starfsmenn (employeeid INTEGER EKKI NULL, eftirnafn VARCHAR (25) EKKI NULL, fornafn VARCHAR (25) EKKI NULL, tilkynnt til INTEGER NULL);Eins og með dæmi hér að framan, athugaðu að forritunarsamningur ræður við að við notum öll hástafir fyrir SQL leitarorð og lágstafir fyrir notendahóp dálka og töflur. Stjórnin hér að ofan kann að virðast ruglingslegt í fyrstu, en það er í raun einfalt skipulag á bak við það. Hér er almennt útsýni sem gæti hreinsað hlutina svolítið:
Búðu til töflu table_name (eiginleiki nafnategundarvalkostir, ..., eiginleiki nafnategundarvalkostir);Eiginleikar og gagnategundir
Í fyrra dæmi er töfluheiti starfsmenn og við eru fjórar eiginleikar: starfsmaður, eftirnafn, fornafn og reportsto. Upplýsingategundin gefur til kynna tegund upplýsinga sem við viljum geyma á hverju sviði. Persónuskilríki er einfalt heiltala, þannig að við munum nota INTEGER gagnategundina fyrir bæði starfsmannasvæðið og skýrslusviðið. Starfsmenn nöfnin verða eðalstrengur af breytilegu lengd og við gerum ráð fyrir að allir starfsmenn hafi fyrstu eða eftirnafn lengur en 25 stafir. Þess vegna munum við nota VARCHAR (25) gerðina fyrir þessi reiti.
NULL gildi
Við getum einnig tilgreint annað hvort NULL eða EKKI NULL í valkostasvæðinu í CREATE yfirlýsingunni. Þetta segir einfaldlega gagnagrunninn hvort NULL (eða tómt) gildi eru leyfðar fyrir þá eiginleiki þegar þeir bæta við raðir í gagnagrunninn. Í okkar fordæmi krefst HR deildin að starfsmennskírteini og heill nafn verði geymt fyrir hvern starfsmann. Hins vegar hefur ekki allir starfsmenn stjórnanda - forstjóri tilkynnir enginn! - þannig að við leyfum NULL færslur á því sviði. Athugaðu að NULL er sjálfgefið gildi og sleppt þessum valkosti leyfir óbeint NULL gildi fyrir eiginleiki.
Building the remaining tables
Nú skulum kíkja á svæðið borð. Frá fljótlegu útsýni að þessum gögnum virðist sem við þurfum að geyma heiltala og tvær strengir með breytilegu lengd. Eins og með fyrri dæmi okkar, gerum við ekki ráð fyrir að svæðisnúmerið eyði meira en 25 stöfum. Hins vegar hafa sumir af yfirráðasvæðum okkar lengri nöfn, þannig að við munum auka leyfilegan lengd þess eiginleiki í 40 stafir. Skulum líta á samsvarandi SQL:
SKAPA TAFLA svæðisbundin svæði (INTIDER EKKI NULL, yfirráðasvæði Lýsing VARCHAR (40) EKKI NULL, regionid VARCHAR (25) EKKI NULL);Að lokum munum við nota EmployeeTerritories töflunni til að geyma tengsl milli starfsmanna og landsvæða. Ítarlegar upplýsingar um hvern starfsmann og yfirráðasvæði eru geymdar í fyrri tveimur töflum okkar. Þess vegna þurfum við aðeins að geyma tvö heiltala kennitölu í þessum töflu. Ef við verðum að auka þessar upplýsingar getum við notað JOIN í valmöguleikum okkar til að fá upplýsingar frá mörgum borðum. Þessi aðferð við að geyma gögn dregur úr offramboð í gagnagrunni okkar og tryggir hámarks notkun á plássi á geymslurými okkar. Við munum fylgjast með JOIN stjórninni ítarlega í framtíðinni. Hér er SQL kóða til að framkvæma lokaplötu okkar:
Búðu til töflu fyrir vinnuveitendur (starfsmaður INTEGER NOT NULL, territoryid INTEGER EKKI NULL);Kerfið SQL býður upp á að breyta uppbyggingu gagnagrunns eftir sköpun
Ef þú ert sérstaklega slæmur í dag, hefur þú kannski tekið eftir því að við "fyrir slysni" slepptu einum af hönnunarkröfum þegar við útfærum gagnagrunnstafla okkar. HR framkvæmdastjóri XYZ Corporation óskaði eftir því að gagnagrunnurinn fylgdi launagreiðslumönnum starfsmanna og við vanræktum að sjá fyrir um þetta í gagnagrunni töflunum sem við bjuggum til.
Hins vegar er allt ekki glatað. Við getum notað ALTER TABLE stjórnina til að bæta þessum eiginleiki við núverandi gagnagrunn. Við viljum geyma launin sem heiltala. Setningafræði er nokkuð svipað og í SKAPA TABLA stjórninni, hér er það:
Takið eftir að við tilgreindum að NULL gildi eru leyfðar fyrir þennan eiginleika. Í flestum tilfellum er ekki hægt að bæta við dálki við núverandi töflu. Þetta er vegna þess að töflan inniheldur þegar raðir sem eru ekki færðar fyrir þennan eiginleika. Þess vegna setur DBMS sjálfkrafa NULL gildi til að fylla ógildið.
Og það hylur útlit okkar á SQL gagnagrunninum og sköpunarferlinu. Skoðaðu oft aftur fyrir nýjar afborganir í SQL námskeiðinu okkar. Ef þú vilt hafa tölvupóst áminning þegar nýjar greinar eru bættar á síðuna Um gagnasöfn skaltu vera viss um að gerast áskrifandi að fréttabréfi okkar!