Бази на податоци, Дел 2 Спонтан • див • и • торта Модел за врска со субјект

Кој е спонтан, кој е див и пред сè: каде е тортата?

Во првиот дел од серијата, откривме дека користењето бази на податоци е добра работа, бидејќи инвеститорот веќе не мора да се занимава со основните функции на складирање на податоци. Сепак, веќе можевме да видиме дека разумното моделирање на податоци е од суштинско значење. Или со други зборови:

Пред да започне значаен дизајн на базата на податоци, клучно е да се разјасни делот од реалниот свет што треба да се мапира. За таа цел, се препорачува моделот ентитет-однос воведен од Питер Чен во 1976 година, кој ги опишува ентитетите, т.е. нештата во реалниот свет, нивните својства и односите меѓу нив. Во оваа статија, ние ќе се нурнеме во основите на овој модел. Во учебникот на Кемпер и Ајклер, моделот на односот на ентитетот се дискутира во Поглавје 2.

Бидејќи вистинското складирање на податоци во заедничкиот DBMS се заснова на релациониот модел, т.е. во табеларна форма, ние исто така треба да се справиме како да го претвориме моделот на однос на ентитетот во релационен модел. Во многу случаи, ова е прилично едноставна и доведува до добри шеми на бази на податоци кои немаат проблеми како што се вишоци, потенцирани во првиот напис во серијата.

Моделот Е/Р

За да го моделираме делот од реалниот свет што е од интерес за нас, треба да бидеме јасни во врска со следниве точки:

Какви работи има во реалниот свет?
Кои се нивните својства?
Како тие се поврзани едни со други?

Споменатите работи од реалниот свет се нарекуваат ентитети и својствата се нарекуваат атрибути во моделот на субјект-врска (или едноставно E/R-модел).

Збир на слични ентитети се означува и како тип на ентитет. Слично на тоа, исто така, се зборува за типови на врски ако се мисли на општата врска помеѓу два типа на ентитети.

За да го разјаснам ова, да се вратиме, на пример, од првиот дел: списокот со адреси.

Во однос на трите споменати прашања, можеме да ги направиме следниве опсервации: Работите во реалниот свет што припаѓаат на нашата адресна листа се пред сè луѓе. Луѓето живеат во станови, а апартманите се на места. Карактеристики на луѓето што се релевантни за нашата адресна листа се презимиња и имиња. Улицата и бројот на куќата се својства на станот и едно место има име и поштенски код.

Во номинацијата во Чен, типовите на ентитети се означени со правоаголници, а типовите на врски се означени со дијаманти. Атрибутите обично се претставени со елипси во дијаграмот за односот на ентитетот. Ако има атрибути кои се погодни за уникатно идентификување на индивидуален субјект, ова може да се означи со потцртување. Таквите атрибути се нарекуваат клучни атрибути. Во нашиот пример, поштенскиот код на едно место е клучен атрибут, бидејќи познавањето на поштенскиот код местото е уникатно одредено.

Е/Р дијаграм за список со адреси

Врските помеѓу типовите на ентитети можат да се карактеризираат уште попрецизно. Како што дискутиравме во нашиот пример во последниот дел, едно лице може да има и неколку апартмани. Неколку луѓе можат да живеат во ист стан. Тоа е таканаречена врска N: M: субјектот може да биде поврзан со кој било број на субјекти од другата страна и обратно.

Врската помеѓу домот и локацијата, од друга страна, е врска 1: N: Може да има неколку апартмани на една локација, но стан има само некогаш на една локација.

Имплементација во табели

Релациони системи за управување со бази на податоци (RDBMS) ги чуваат податоците во табели. Значи, треба соодветно да го имплементираме моделот Е/Р за практична употреба. Може да се види дека она што сакаме да го зачуваме се својствата на ентитетите. Во однос на табелите, тоа се сведува на атрибутите кои стануваат колони на табелата. Се креира посебна табела за секој тип на ентитет.

Видови субјекти

Досега имаме табела за луѓе во кои се внесуваат презимиња и имиња, табела за станови со колони за улици и куќни броеви и табела за градови со колони за поштенски код и име на место. Индивидуалните лица, станови и места, т.е. индивидуалните субјекти, одговараат на редови во табелите.

1: N врски

Сега односите треба да бидат мапирани. Во случај на станови и места, мапирањето на врската е едноставна. Бидејќи стан може да се наоѓа само на најмногу едно место, а поштенскиот код јасно го дефинира местото, доволно е да се вклучи дополнителна колона за поштенскиот код во табелата за становите. Вредноста во оваа колона потоа служи како упатување на локацијата. Името на местото, од друга страна, не треба да се копира во табелата со станови, инаку би создале вишок: Фактот дека одреден поштенски код припаѓа на одредено место, е веќе претставен во табелата Место и не треба да се повторува на друго место.

Илустрацијата на односот 1: N помеѓу становите и местата е толку едноставна бидејќи клучот е веќе достапен со поштенскиот код на местата и овој клуч може да се користи директно како референца во табелата Апартмани, бидејќи стан може да биде само на едно место може. Колоната со поштенски код во табелата Град е позната и како примарен клуч (PK). Примарниот клуч уникатно идентификува ред во табелата. Во табелата Апартман, поштенскиот код станува странски клуч (FK). Поштенскиот код не е сопственост на самиот стан, туку на местото во кое се наоѓа станот. Ова е причината зошто поштенскиот код не е запишан како атрибут на станот во моделот Е/Р! Колона со странски клуч се користи само за да се воспостави врска помеѓу два ентитета.

Важно е дека воспоставувањето на врската преку едноставна колона странски клуч работи само ако го спакуваме странскиот клуч од страната N во случај на врски 1: N. Бидејќи има неколку апартмани на една локација, единствена колона во табелата за локациите не е доволна за да се покаже врската!

Вештачки клучеви

Во случај на врска помеѓу луѓето и становите, спроведувањето на односите во табели е малку посложено. Како прво, ние не запишавме никакви својства во моделот Е/Р што уникатно ги идентификуваат луѓето или становите. Во првиот дел веќе ја разгледавме можноста за едноставно доделување броеви за оваа намена. Потоа можеме да направиме разлика помеѓу две лица со исто име кои се уште се различни луѓе ако им доделиме различни броеви. Таквиот број е познат и како вештачки клуч или сурогат клуч. Не е недвижен имот на субјектот, но е додаден од наша страна и се користи само за јасна препознатливост.

Со поштенскиот код на местото, секако може да се тврди дека тој исто така е вештачки клуч, бидејќи поштенскиот код е исто така направен од луѓе и е доделен произволно. Сепак, генерирањето на поштенскиот код е надвор од нашата контрола, како што беше наведено од друга агенција (имено поштата). Поради оваа причина, поштенскиот код може да се види како природен клуч. Oneе се зборува само за вештачки клуч ако сами ја додадевме оваа колона за клучеви и таа евентуално не беше вклучена во оригиналниот дијаграм за радиоенергија. Патем, не е потребно да коцкаме конкретна вредност за вештачкиот клуч при вметнување на податоци. DBMS може да генерира вредност за самиот вештачки клуч. Ова има предност, на пример, дека ако има неколку операции со истовремено вметнување, тогаш двајца корисници не можат да изберат иста вредност, што би довело до грешки.

N: М односи

Назад во нашиот пример, прво додаваме колона за вештачки примарен клуч во табелата за лица и во табелата за становите, ги нарекуваме „PNr“ за бројот на личност и „WNr“ за бројот на станот . Сега можеме да ги користиме овие клучеви за да ја покажеме врската помеѓу една личност и нивните домови. Сепак, како и со односот еден на повеќе, ние не можеме едноставно да поставиме колона како странски клуч од двете страни. Едно лице може да има повеќе апартмани според нашиот идеен модел, така што не можеме да поминеме со една колона тука. Според нашиот модел, сепак, неколку луѓе можат да живеат во еден стан, така што колоната со странски клучеви не би помогнала ниту во табелата Апартман.

Решението е да се создаде посебна табела за типот на врски N: M „животи“. Во оваа таканаречена табела за односи, се создава ред за секоја врска помеѓу личност и стан. Колоните за табели за врска се колони за странски клучеви за сите типови на ентитети вклучени во типот на врска. На нашиот пример, потребна ни е табела „животи“ со колоните „PNr“ и „WNr“. На пример, ако лицето со број 2 живее во станот со број 1, оваа комбинација ја внесуваме во линија во табелата за односи.

Композитен примарен клуч

Не ни треба вештачки примарен клуч за самата табела за односи. Сепак, бидејќи комбинацијата на број на лице и број на стан во табелата за односи е единствена, таа може да се користи како композитен примарен клуч. (На крајот на краиштата, едно лице може да живее во различни станови и различни луѓе во еден стан, но фактот дека некое лице живее во ист стан неколку пати не би бил разумен факт и затоа не треба да биде дозволен во табелата.)

Табели за базата на податоци за адреси

Атрибути од типот на врска

Патем, типовите на врски исто така можат да имаат својства. Како продолжение на нашиот пример со список со адреси, ајде накратко да разгледаме Е/Р дијаграм што моделира производи и нарачки. Едно лице може да испрати неколку обрасци за нарачки, но нарачката е направена само од некое лице. Повеќе производи може да бидат вклучени во секоја нарачка. Секако, производ може да се нарача и неколку пати.

Ако одреден производ треба да биде вклучен неколку пати во нарачката - на пример, клиент нарачува пет розови четки за заби одеднаш - количината на нарачката е карактеристика на врската! Конечно, може да има и други клиенти кои сакаат да нарачаат само една четка за заби и истата нарачка што содржи пет четки за заби може да содржи и една жолта гумена дарки. Количината на нарачката, следствено, не може да биде сопственост на производот сама по себе ниту на образецот за нарачка, туку, како што веќе беше кажано, својство на односот помеѓу производот и нарачката.

E/R модел преку нарачки

Како и кај типовите на ентитети, атрибутот се спроведува како колона во табела. Бидејќи типот на врска „содржи“ е тип на однос N: M, во секој случај, потребна е табела за врски, на која едноставно се додава колоната за количината на нарачката. Комбинацијата на двата странски клучеви останува примарен клуч на табелата за односи. Една нарачка не може да содржи ист производ двапати со различни количини. Концептивно, ова исто така нема да има смисла.

Табели за нарачки и производи; забележете ја колоната „износ“

метод

Па, да ги сумираме чекорите што нè одведоа од моделот Е/Р до табелите:

За секој Тип на субјект: Создадете табела
За секој атрибут: Создадете колона
За секоја маса без природно клуч: Додадете вештачки клуч
За секој 1: N тип на врска: Додадете колона странски клуч на N страна
За секој N: М врска: Додадете табела за врски со колони со странски клучеви за типовите на ентитети вклучени во врската и направете ги да бидат составен примарен клуч; забележете ги сите постојни атрибути од типот на врската

Како што подетално ќе анализираме подоцна, овој чекор-по-чекор пристап нè доведе до дизајн на база на податоци од табели што нема вишок.

Примарни и странски клучеви

Можеме да ги наведеме следниве точки за примарни и странски клучеви (PK и FK):

Вредноста на PK мора да биде единствена и да идентификува линија во табелата
Ако PK е составен од неколку колони, комбинацијата на вредностите во колоните мора да биде единствена
FK создава врска со друга табела
Колона FK во една табела се однесува на колона во друга табела (ова е обично колона PK)
Дозволени се само вредностите во колоната на која се однесува

Нивоа на дизајн

Само што работевме на две различни нивоа на дизајн во нашиот пример. На идејно ниво, го воспоставивме моделот Е/Р. Како чисто идеен модел, тој е целосно независен од базите на податоци! Можеме да го користиме моделот E/R за моделирање работи што не сакаме да ги имплементираме во базата на податоци потоа. Сепак, тоа е корисно за нашата цел бидејќи ни го отвора патот да имаме добра шема за бази на податоци.

Имплементацијата во шемата на базата на податоци во релацискиот модел се одвива на ниво на имплементација.

Сè уште постои физичко ниво на дизајнирање на базата на податоци, но бидејќи пристапот до физички податоци, како што беше дискутирано во првиот дел, е изваден од ДБМС, не треба прво да се справиме со тоа.

Релациониот модел

Бидејќи има модел на односи со ентитет и релационен модел и овие поими се слични, постои ризик од конфузија! Бидејќи моделот Е/Р и релациониот модел се две сосема различни работи. Како што штотуку видовме, тие дури се играат на различни нивоа на дизајн! Англискиот збор „однос“ не е преведен на германски како „Релација“, туку како „Однос“. Релациониот модел го носи своето име од релациите во математиката. Како што е веќе опишано во првиот дел, релациониот модел за бази на податоци се враќа на есејот на Едгар Ф. Код од 1972 година.

Односи по математика

Во математиката, релација е дефинирана како подмножество на картезијанскиот производ на n други множества D1, ... Dn, кои се нарекуваат и домени или опсези на вредности. Декартовиот производ или вкрстениот производ D1 ×… × Dn го означува множеството од сите можни комбинации во парови на елементите од D1 до Dn. Релација R е така: R ⊆ D1 ×… × Dn

Да разгледаме релација R ⊆ D1 × D2, каде што D1 е множество на сите петцифрени цели броеви и D2 е множество на сите можни низи. D1 × D2 се тогаш сите можни комбинации на петцифрени броеви и сите жици со знаци. Список на поштенски кодови со поврзани имиња на места, како нашата табела за места, е подмножество на истиот!

Значи, за наши цели можеме да разбереме релација како табела (вклучувајќи ја и нејзината содржина). (Подоцна ќе видиме дека ова е поедноставување и дека има детали во кои табелите во ДБМС и односите се разликуваат.)

Резиме

Во втората статија од серијата за бази на податоци, разгледавме дизајн на базата на податоци. Го запознавме моделот на односот на ентитетот како идеен модел со кој нештата во реалниот свет може да се мапираат со нивните својства и како тие се поврзани едни со други. Исто така, видовме како моделот на односот на ентитетот може да се претвори во релационен модел кој се состои од табели. Оваа трансформација е неопходна затоа што DBMS зачувува податоци во табели и не може да стори ништо директно со моделите E/R.

изгледи

Во следниот дел ќе го примениме релацискиот модел на база на податоци што го дизајниравме денес за нашата адресна листа во пракса во вистински ДБМС. Исто така е опишано како може да се креираат табели во DBMS со SQL. Во следниот, но во еден дел, моделот E/R се продлабочува и се дискутираат за понатамошните типови на врски и нивната имплементација во релацискиот модел.