VB2008从入门到精通(PDF格式英文版)-第71部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！



　　　　　　　　　　　2000。06。10　1　3　12　23　29　33　27　

　　　　　　　　　　　2000。06。14　2　4　13　19　39　45　26　

　　　　　　　　　　　2000。06。17　3　8　17　19　21　25　35　



　　　　　　　　　　　　　　　　The　data　is　arranged　as　a　table；　and　thus　could　be　easily　converted　into　a　relational　data

　　　　　　　　　　　base　table。　In　relational　database…speak；　each　row　in　the　file　corresponds　to　a　row　of　data。　But　　

　　　　　　　　　　　to　create　a　row　of　data；　you　need　fields；　each　of　which　is　also　in　a　column。　A　relational　database　　

　　　　　　　　　　　table　is　a　grid　of　rows　and　columns。　When　working　with　a　relational　database；　you　don’t　　

　　　　　　　　　　　manipulate　columns；　you　manipulate　individual　rows。　

　　　　　　　　　　　　　　　　What　distinguishes　a　relational　database　is　that　you　can　bine　tables　and　create　more　　

　　　　　　　　　　　plicated　data　structures。　It　is　the　relationships　（called　relations）　between　pieces　of　data　　

　　　　　　　　　　　that　make　a　relational　database　so　powerful。　For　the　lottery　data；　a　relation　could　be　who　won　　

　　　　　　　　　　　the　jackpot　on　the　draw　dates。　Modifying　the　table　to　include　the　person　who　won　would　look　　

　　　　　　　　　　　this：　



　　　　　　　　　　　2000。05。31　nobody　5　6　13　23　25　37　43　

　　　　　　　　　　　2000。06。03　nobody　7　10　11　18　32　41　5　

　　　　　　　　　　　2000。06。07　nobody　15　23　24　28　38　39　45　

　　　　　　　　　　　2000。06。10　jack　1　3　12　23　29　33　27　

　　　　　　　　　　　2000。06。14　nobody　2　4　13　19　39　45　26　

　　　　　　　　　　　2000。06。17　nobody　3　8　17　19　21　25　35　



　　　　　　　　　　　　　　　　For　the　most　part；　no　one　won　the　jackpot。　But　on　June　10；　2000　（2000。06。10）；　a　person　　

　　　　　　　　　　　named　Jack　won　the　jackpot。　You　might　know　a　Jack。　I　might　know　a　Jack。　But　would　he　be　the　　

　　　　　　　　　　　same　Jack？　Probably　not。　So　to　distinguish　winner　Jack　from　another　Jack；　you　would　need　his　　

　　　　　　　　　　　full　name；　address；　and　other　details。　But　where　do　you　put　this　extra　information？　　

　　　　　　　　　　　　　　　　Do　you　put　the　information　about　Jack　into　the　lottery　data　table？　Or　do　you　create　another　　

　　　　　　　　　　　table？　The　answer　is　that　you　create　another　table。　But　since　you　are　working　with　files；　it　will　　

　　　　　　　　　　　be　a　file；　not　a　table。　The　file　will　be　called　jack。txt　because　the　winner　of　the　lottery　jackpot　　

　　　　　　　　　　was　Jack。　The　jack。txt　file　could　contain　the　following　information。　



　　　　　　　　　　　Jack　Smith　

　　　　　　　　　　　Address　

　　　　　　　　　　　City　

　　　　　　　　　　　Country　



　　　　　　　　　　　　　　　　The　information　in　jack。txt　and　the　information　in　the　lottery　data　file　have　a　relation。　The　　

　　　　　　　　　　　relation　is　the　winner　of　the　jackpot。　This　is　what　a　relational　database　is　all　about。　The　reason　you　　

　　　　　　　　　　　use　a　relational　database　and　not　files　that　cross…reference　each　other　is　because　a　relational　　

　　　　　　　　　　　database　is　extremely　efficient　at　managing　tables　and　relations。　The　techniques　demonstrated　　

　　　　　　　　　　　in　Chapter　10　are　nowhere　near　as　efficient　and　effective　as　using　a　relational　database。　

　　　　　　　　　　　　　　　　Relational　databases　are　quite　capable　of　handling　terabytes　of　data。　Additionally；　relational　　

　　　　　　　　　　　databases　are　capable　of　building　efficient　relations　that　span　terabytes　of　data。　


…………………………………………………………Page　395……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　C　HA　P　TE　R　　　1　4　　　■　　　　L　E　AR　N　I　N　G　　　AB　O　U　T　　R　E　L　AT　IO　N　A　L　　　D　AT　AB　A　SE　　　D　A　TA　373　



Database　Relations　



Relations　are　very　powerful；　but　they　can　also　make　things　extremely　plicated。　When　you　　

split　tables　and　create　relations　between　the　tables；　you　are　normalizing　the　data。　Database　　

normalization　is　defined　as　follows　（http：//en。wikipedia。org/wiki/Database_normalization）：　



　　　　　Database　　normalization　　is　　a　　technique　　for　　designing　　relational　　database　　tables　　to　

　　　　　minimize　　duplication　　of　　information　　and；　　in　　so　　doing；　　to　　safeguard　　the　　database　

　　　　　against　　certain　　types　　of　　logical　　or　　structural　　problems；　　namely　　data　　anomalies。　　For　

　　　　　example；　when　multiple　instances　of　a　given　piece　of　information　occur　in　a　table；　the　

　　　　　possibility　exists　that　these　instances　will　　not　be　kept　consistent　when　the　data　within　

　　　　　　the　　table　　is　　updated；　　leading　　to　　a　　loss　　of　　data　　integrity。　　A　　table　　that　　is　　sufficiently　

　　　　　normalized　is　less　vulnerable　to　problems　of　this　kind；　because　its　structure　reflects　the　

　　　　　basic　　assumptions　　for　　when　　multiple　　instances　　of　　the　　same　　information　　should　　be　

　　　　　　represented　by　a　single　instance　only。　



　　　　　For　example；　the　data　on　the　winner　and　the　data　on　the　lottery　ticket　are　kept　in　separate　　

tables；　making　the　overall　data　structure　more　efficient　from　a　maintenance　and　performance　　

point　of　view。　

　　　　　Creating　relations　between　tables　is　a　form　of　referencing；　where　one　table　says　informa

tion　here　references　information　in　another　table。　The　referencing　is　carried　out　using　columns　　

of　one　table　that　are　cross…referenced　with　columns　of　another　table。　

　　　　　The　lottery　ticket　example　is　interesting　because　of　the　relations　between　the　lottery　draws　　

and　the　winners；　which　could　be　of　two　types：　



　　　　　o　　One　draw　to　many　winners：　When　a　lottery　ticket　is　drawn；　there　can　be　many　winners。　



　　　　　o　　One　winner　to　many　draws：　Even　though　it　is　improbable；　one　winner　could　win　　

　　　　　　　　multiple　draws。　



　　　　　In　the　file　example；　you　saw　the　one…winner…to…many…draws　relation。　You　probably　did　　

not　think　it　was　that　type　of　relation；　and　more　likely　thought　it　was　a　one…draw…to…one…winner　　

relation。　But　consider　the　following　text　file；　where　jack　is　referenced　twice。　



2000。05。31　nobody　5　6　13　23　25　37　43　

2000。06。03　jack　7　10　11　18　32　41　5　

2000。06。07　nobody　15　23　24　28　38　39　45　

2000。06。10　jack　1　3　12　23　29　33　27　

2000。06。14　nobody　2　4　13　19　39　45　26　

2000。06。17　nobody　3　8　17　19　21　25　35　



　　　　　The　table　of　draws　has　the　ability　to　reference　the　same　winner　twice；　which　means　the　　

relation　of　one　winner　to　many　draws　is　possible。　To　add　the　relation　of　one　draw　to　many　　

winners；　the　table　would　need　to　be　modified　like　this：　



2000。05。31　nobody　5　6　13　23　25　37　43　

2000。06。03　jack　jill　7　10　11　18　32　41　5　

2000。06。07　nobody　15　23　24　28　38　39　45　

2000。06。10　jack　1　3　12　23　29　33　27　

2000。06。14　nobody　2　4　13　19　39　45　26　

2000。06。17　nobody　3　8　17　19　21　25　35　


…………………………………………………………Page　396……………………………………………………………

374　　　　　　　CH　AP　T　E　R　　　1　4　　　■　　　　L　E　A　R　N　I　N　G　　　A　B　OU　T　　　R　E　L　A　TI　O　N　AL　　　DA　TA　B　AS　E　　　D　AT　A　



　　　　　　　　　　　　　　　　Here；　another　field　indicates　Jill　as　the　second　winner　of　the　draw。　Adding　another　field　　

　　　　　　　　　　　throws　a　monkey　wrench　into　the　entire　table　structure　and　makes　processing　much　more　　

　　　　　　　　　　　plicated；　because　the　parsing　routines　will　need　to　verify　if　another　field　is　present。　This　　

　　　　　　　　　　　breaks　the　nice　grid　structure　and　is　plain　wrong。　

　　　　　　　　　　　　　　　　Another　approach　using　the　text　file　would　be　to　create　a　third　file　that　cross…references　the　　

　　　　　　　　　　winners　with　the　dates。　So　the　lottery　file　would　go　back　to　the　original　version：　



　　　　　　　　　　　2000。05。31　5　6　13　23　25　37　43　

　　　　　　　　　　　2000。06。03　7　10　11　18　32　41　5　

　　　　　　　　　　　2000。06。07　15　23　24　28　38　39　45　

　　　　　　　　　　　2000。06。10　1　3　12　23　29　33　27　

　　　　　　　　　　　2000。06。14　2　4　13　19　39　45　26　

　　　　　　　　　　　2000。06。17　3　8　17　19　21　25　35　



　　　　　　　　　　　　　　　　And　a　winners　table　would　be　created：　



　　　　　　　　　　　2000。06。03　jack　

　　　　　　　　　　　2000。06。03　jill　

　　　　　　　　　　　2000。06。10　jack　



　　　　　　　　　　　　　　　　The　winners　table　is　a　grid　of　draw　dates　and　winners　on　those　dates。　Notice　how　there　is　　

　　　　　　　　　　　no　entry　for　nobody；　so　only　draw　dates　with　winners　are　included。　　



　　　　　　　　　　　■Note　　These　three　tables　are　an　example　of　correctly　normalized　data。　When　the　data　is　well　normalized；　　

　　　　　　　　　　　each　table　contains　unique　data。　In　this　example；　one　table　contains　all　of　the　lottery　drawings；　but　who　the　　

　　　　　　　　　　　winners　are　is　stored　in　another　table。　Using　database　relations；　the　winners　and　lottery　data　are　related；　yet　　

　　　　　　　　　　　neither　table　needs　to　know　about　the　other　table。　



　　　　　　　　　　　　　　　　Now　what　happens　if　two　different　people　named　Jack　are　lottery　winners？　The　data　might　　

　　　　　　　　　　　look　like　this：　



　　　　　　　　　　　2000。05。31　nobody　5　6　13　23　25　37　43　

　　　　　　　　　　　2000。06。03　nobody　7　10　11　18　32　41　5　

　　　　　　　　　　　2000。06。07　nobody　15　23　24　28　38　39　45　

　　　　　　　　　　　2000。06。10　jack　1　3　12　23　29　33　27　

　　　　　　　　　　　2000。06。14　jack　2　4　13　19　39　45　26　

　　　　　　　　　　　2000。06。17　nobody　3　8　17　19　21　25　35　



　　　　　　　　　　　　　　　　We　know　the　two　jack　entries　are　not　for　the　same　Jack。　So　now　we　have　an　additional　　

　　　　　　　　　　　problem　of　uniqueness。　Uniqueness　is　not　unusual　when　dealing　with　relational　databases；　　

　　　　　　　　　　　and　the　mon　technique　is　to　identify　each　Jack　with　a　unique　key。　For　example；　a　unique　　

　　　　　　　　　　　key　could　be　jack_1　or　jack_2。　The　problem　with　using　jack_1　and　jack_2　is　that　you　need　to　　

　　　　　　　　　　　search　the　database　to　see　if　there　is　a　jack　entry；　and　then　find　out　the　last　jack　entry。　Those　　

　　　　　　　　　　　steps　are　resource…intensive　and　typically　avoided。　Another　solution　is　to　use　a　database

　　　　　　　　　　　provided　field　that　generates　a　unique　key；　which　could　be　a　row　number　or　globally　unique　　

　　　　　　　　　　　identifier　（GUID）。　If　the　unique　identifier　were　to　be　puter…generated；　the　table　might　look　　

　　　　　　　　　　　as　follows：　


…………………………………………………………Page　397……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　C　HA　P　TE　R　　　1　4　　　■　　　　L　E　AR　N　I　N　G　　　AB　O　U　T　　R　E　L　AT　IO　N　A　L　　　D　AT　AB　A　SE　　　D　A　TA　375　



2000。05。31　1877_ds　5　6　13　23　25　37　43　

2000。06。03　1877_ds　7　10　11　18　32　41　5　

2000。06。07　1877_ds　15　23　24　28　38　39　45　

2000。06。10　1023_ad　1　3　12　23　29　33　27　

2000。06。14　1022_xy　4　13　19　39　45　26　

2000。06。17　1877_ds　3　8　17　19　21　25　35　



　　　　　　In　the　modified　table；　you　would　have　no　idea　who　the　identifiers　represent。　The　way　to　　

find　out　is　to　take　a　key　and　open　its　associated　field—say　1877_ds　and　the　file　1877_ds。txt。　　

Upon　opening　the　file；　you　would　know　that　the　winner　is　nobody。　The　process　of　finding　out　　

who　the　winner　is　involves　more　steps；　but　a　relational　database　knows　how　to　manage　these　　

types　of　relations　quite　effectively。　　



　　　　　　　　　　　　　　　　　WHY　THE　THOUSANDS　OF　APIS；　LIBRARIES；　AND　TECHNIQUES？　



　　　In　the　space　of　12　years；　the　following　data…access　technologies　have　emerged：　Open　Database　Connectivity　　

　　　（ODBC）；　Remote　Data　Objects　（RDO）；　the　Jet　Database　Engine；　Data　Access　Object　（DAO）；　ActiveX　Data　Object　　

　　　（ADO）；　Object　Linking　and　Embedding；　Database　（OLE　DB）；　ADO；　and　Language　Integrated　Query　（LINQ）。　　

　　　This　means　that　every　2　years；　a　new　database　technology　is　introduced。　Each　database　technology　has　libraries　to　　

　　　make　it　easier　to　write　code。　The　result　is　an　amazing　number　of　ways　to　access　a　piece　of　technology　that　is　　

　　　nearly　40　years　old。　

　　　　　　　　　So　why　do　we　have　so　many　ways　to　access　and　manipulate　the　database？　Wouldn’t　we；　as　developers；　　

　　　get　our　act　together　and　work　toward　a　mon　approach　to　manipulating　a　relational　database？　I　can’t　give　　

　　　a　logical　and　accepted　answer　as　to　why　there　are　so　many　data…access　technologies。　But　I　can　tell　you　what　　

　　　I　think。　

　　　　　　　　　For　any　real　production　application；　it　is　not　unmon　to　have　tables　that　have　30　columns。　When　　

　　　writing　code　to　add；　delete；　and　modify　a　row　in　a　table　that　has　30　fields；　you　are；　for　the　most　part；　trying　to　　

　　　figure　out　which　field　goes　to　which　piece　of　data。　Thus；　people　try　to　automate　the　job。　After　all；　it　is　more　　

　　　interesting　to　work　through　a　threading　bug　than　an　incorrect…field…placement　bug。　

　　　　　　　　　Another　issue　is　a　technology　mismatch　between　a　programming　language　and　a　relational　database。　A　　

　　　relational　database　treats　data　as　a　set。　There　are　no　individual　pieces　of　data　in　a　relational　database。　Programming　　

　　　languages　treat　data　as　individuals。　Even　in　a　collection　class；　you　have　an　individual　class　managing　a　set　of　　

　　　individual　references。　This　causes　a　mismatch；　and　trying　to　bind　to　the　two　technologies　is　difficult。　

　　　　　　　　　So　when　you　are　writing　database　code；　you　are　trying　to　automate　the　fitting　of　a　square　peg　into　a　round　　

　　　hole。　You　get　many　extremely　creative　ideas　and　results；　but　at　the　end　of　the　day；　you　are　still　fitting　a　square　　

　　　peg　into　a　round　hole。　　

　　　　　　　　　The　essence　of　the　problem　when　dealing　with　sets　of　data　in　a　programming　language　is　how　to　　

　　　integrate　the　two。　There　is　light　at　the　end　of　the　tunnel；　in　the　form　of　programming　language　alterations　　

　　　such　as　LINQ。　LINQ　will　be　discussed　in　the　next　chapter。　　



Accessing　Relational　Databases　



Regardless　of　the　database　implementation　that　you　use；　a　mon　architecture　is　employed；　　

as　illustrated　in　Figure　14…1。　


…………………………………………………………Page　398……………………………………………………………

376　　　　　　　CH　AP　T　E　R　　　1　4　　　■　　　　L　E　A　R　N　I　N　G　　　A　B　OU　T　　　R　E　L　A　TI　O　N　AL　　　DA　TA　B　AS　E　　　D　AT　A　



　　　　　　　　　　　Figure　14…1。　mon　database　architecture　



　　　　　　　　　　　　　　　　Most　relational　database　servers　are　separate　applications　that　run　on　their　own。　To　interact　　

　　　　　　　　　　　with　a　running　relational　database；　the　database　vendor　provides　a　database　driver。　In　；　a　　

　　　　　　　　　　　database　driver　is　a　piece　of　proprietary　code　that　talks　to　the　relational　database　server；　but　　

　　　　　　　　　　　exposes　its　functionality　using　the　ADO　layer。　

　　　　　　　　　　　　　　　　The　ADO　layer　is　a　technology　that　abstracts　the　database　client　into　a　neutral　set　of　　

　　　　　　　　　　　interfaces。　By　itself；　ADO　does　not　implement　any　technologies；　but　it　defines　the　inter

　　　　　　　　　　　faces　that　a　database　needs　to　have　implemented。　ADO　is　similar　to　the　lighting　manager　　

　　　　　　　　　　　application　introduced　in　Chapter　8；　where　specific　lighting　implementations　need　to　imple

　　　　　　　　　　　ment　interfaces。　

　　　　　　　　　　　　　　　　The　ADO　code　can　be　accessed　directly　in　your　application　by　your　code。　However；　　

　　　　　　　　　　　doing　that　means　accessing　the　individual　rows；　columns；　and　database　tables。　It　is　not　a　difficult　　

　　　　　　　　　　　undertaking；　but　it　means　you　need　to　do　everything　manually。　With　respect　to　the　lottery　　

　　　　　　　　　　　example；　it　means　manipulating　the　lottery　winners　and　the　lottery　draws　tables。　

　　　　　　　　　　　　　　　　Visual　Basic　Express　and　other　Visual　Studio　editions　have　a　number　of　tools　that　will　　

　　　　　　　　　　　generate　code　that　automatically　binds　to　tables　and　rows；　reducing　the　amount　of　work　that　you　　

　　　　　　　　　　　need　to　do。　In　Figure　14…1；　the　user　code　has　arrows　pointing　to　both　the　Visual　Studio–generated　　

　　　　　　　　　　　code　and　the　ADO　code。　These　arrows　indicate　that　your　code　does　not　need　to　use　the　　

　　　　　　　　　　　Visual　Studio–generated　code；　it　is　optional。　But　the　advantage　of　using　the　Visual　Studio　code　　

　　　　　　　　　　　is　that　it　reduces　the　amount　of　grunt　work　that　your　code　needs　to　do。　The　Visual　Studio–　

　　　　　　　　　　　generated　code　is　a　thin　functional　layer　on　top　of　th